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