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
