x raid [ARCHIVE] on Nostr: 📅 Original date posted:2021-11-23 📝 Original message: so You propose Acinq / ...
📅 Original date posted:2021-11-23
📝 Original message:
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 <ZmnSCPxj at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211123/d7d693cb/attachment.html>;
📝 Original message:
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 <ZmnSCPxj at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211123/d7d693cb/attachment.html>;