x raid [ARCHIVE] on Nostr: 📅 Original date posted:2021-11-23 📝 Original message: Each dev does tests on a ...
📅 Original date posted:2021-11-23
📝 Original message:
Each dev does tests on a local machine before push to repo, repo
maintainers do tests and when satisfied do an acceptance test in the
proposed system to verify against all other implementations partaking
before public release. Has not anything to do with You relly, not Your
private machine but dedicated test machines that do have nano granularity
in that request against runs can specify unix.ts(start)-range-unix.ts(end)
of box xyz and independently se if others and own impl behaves as it is
expected to.
On Tue, Nov 23, 2021 at 5:31 PM x raid <xraid at iprobot.com> wrote:
> 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/63d5b741/attachment-0001.html>;
📝 Original message:
Each dev does tests on a local machine before push to repo, repo
maintainers do tests and when satisfied do an acceptance test in the
proposed system to verify against all other implementations partaking
before public release. Has not anything to do with You relly, not Your
private machine but dedicated test machines that do have nano granularity
in that request against runs can specify unix.ts(start)-range-unix.ts(end)
of box xyz and independently se if others and own impl behaves as it is
expected to.
On Tue, Nov 23, 2021 at 5:31 PM x raid <xraid at iprobot.com> wrote:
> 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/63d5b741/attachment-0001.html>;