{"type":"rich","version":"1.0","author_name":"npub15758wuggl6u8umupz8ellvdjad7mjcchkn2vcelrmmeg55f48euspfpqkx","author_url":"https://nostr.ae/npub15758wuggl6u8umupz8ellvdjad7mjcchkn2vcelrmmeg55f48euspfpqkx","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2021-11-23\n📝 Original message:\nEach dev does tests on a local machine before push to repo, repo\nmaintainers do tests and when satisfied do an acceptance test in the\nproposed system to verify against all other implementations partaking\nbefore public release. Has not anything to do with You relly, not Your\nprivate machine but dedicated test machines that do have nano granularity\nin that request against runs can specify unix.ts(start)-range-unix.ts(end)\nof box xyz and independently se if others and own impl behaves as it is\nexpected to.\n\nOn Tue, Nov 23, 2021 at 5:31 PM x raid \u003cxraid at iprobot.com\u003e wrote:\n\n\u003e so You propose Acinq / Blockstream / Lightning Labs do not have funds to\n\u003e run a box or 2 ?\n\u003e\n\u003e contributions can be made towards each impl by ppl while the project still\n\u003e do need put liquidity on mainnet to be a viable test before a public\n\u003e sanctioned release.\n\u003e\n\u003e I find You choose misread what the text is supposed to convey - those with\n\u003e the write credentials to repo, when do a public release could have been\n\u003e tested, before, against the network, and that in no way hinders PR toward\n\u003e said repo.\n\u003e\n\u003e On Tue, Nov 23, 2021 at 1:44 PM ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e wrote:\n\u003e\n\u003e\u003e Good morning x-raid,\n\u003e\u003e\n\u003e\u003e \u003e what i can imagine is each team should provide boxes and channel\n\u003e\u003e liquidity as stake on mainnet for tests before announce a public realise as\n\u003e\u003e to feel the pain first hand instead of having several K´s of plebs confused\n\u003e\u003e and at worst have funds in channelclosed etc. but mostly for helping in\n\u003e\u003e smooth transitioning into future envisioned mass.\n\u003e\u003e\n\u003e\u003e Not all members of all teams are independently wealthy, and cannot afford\n\u003e\u003e significant liquidity on mainnet, or can afford good Internet connection\n\u003e\u003e and keeping a device operational 24/7.\n\u003e\u003e For example, for some time I was a C-Lightning core developer, yet did\n\u003e\u003e not run a C-Lightning node myself, relying on sheer code review, because I\n\u003e\u003e could not afford to run a node.\n\u003e\u003e What you imagine would raise the barrier towards contribution (i.e. I\n\u003e\u003e might not have been able to start contributing to C-Lightning in the first\n\u003e\u003e place, for example).\n\u003e\u003e\n\u003e\u003e I think you misunderstand the open-source model.\n\u003e\u003e If you have the skill, but not the money, you can contribute directly.\n\u003e\u003e If you do not have the skill, but do have the money, you can contribute\n\u003e\u003e that by hiring developers to work on the project you want.\n\u003e\u003e\n\u003e\u003e So, if you are using a particular open-source implementation and storing\n\u003e\u003e your funds with it, either:\n\u003e\u003e\n\u003e\u003e * You have the 1337 skillz0rs: you contribute review and actual code.\n\u003e\u003e * You do not have the 1337 skillz0rs: you contribute hardware and testing\n\u003e\u003e reports and possibly money.\n\u003e\u003e\n\u003e\u003e If the several Ks of plebs are confused, they can aggregate their\n\u003e\u003e resources and fund one or two developers to review and contribute to the\n\u003e\u003e project they are using, and maybe some hardware and coins for boxes they\n\u003e\u003e keep running.\n\u003e\u003e\n\u003e\u003e At my point of view, the Real Issue (TM) here is how to aggregate the\n\u003e\u003e will of a group of people, without risking that some centralized \"manager\"\n\u003e\u003e of resources gets incentives that diverge from the group of people and\n\u003e\u003e starts allocating resources in ways that the group of people would, in\n\u003e\u003e aggregate, disagree with.\n\u003e\u003e\n\u003e\u003e \u003e\n\u003e\u003e \u003e If teams rather outsource the running of boxes with channels on mainnet\n\u003e\u003e for impl release and rc versions they would of course be able to, but close\n\u003e\u003e to home for managing analysis of the team impl themselves is what I would\n\u003e\u003e recommend.\n\u003e\u003e \u003e\n\u003e\u003e \u003e Can also see that each box loglines are collected at one central point\n\u003e\u003e whereby requests can be made for comparing interoperability per unix.ts\n\u003e\u003e identified by box.\n\u003e\u003e \u003e (thats alot of data You say --not really in Big Data terms, question is\n\u003e\u003e where to set a proper cap in time for collections ? a week ? a month ?)\n\u003e\u003e \u003e I think i might have a solution for the central point collector that\n\u003e\u003e could be run by an outside of impl teams perimeter. (sponsored?)\n\u003e\u003e\n\u003e\u003e See, if the money on the node is my own, and not contributed by the group\n\u003e\u003e that is going to receive the logs, I am not going to send the logs verbatim\n\u003e\u003e to them, nope not nada.\n\u003e\u003e I do not want to become a target, because logs leak information like who\n\u003e\u003e my channel counterparties are and how often I forward HTLCs and exact dates\n\u003e\u003e and times of each event, and thus can be used to locate my node, and\n\u003e\u003e location is the first step to targeted attack.\n\u003e\u003e I mean I use a frikkin set of 8 random letters, come on.\n\u003e\u003e Possibly if the logs had sensitive information redacted (even dates and\n\u003e\u003e times??), but we need to automate that redaction, and in particular, if the\n\u003e\u003e implementation changes log messages, we need to ensure that changed log\n\u003e\u003e messages do not leak information that gets past the automated redaction.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e Regards,\n\u003e\u003e ZmnSCPxj\n\u003e\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211123/63d5b741/attachment-0001.html\u003e"}