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