<unnamed>

Public Key

npub15758wuggl6u8umupz8ellvdjad7mjcchkn2vcelrmmeg55f48euspfpqkx

Profile Code

nprofile1qqs202rhwyy0awr7d7q3rullkxewkldevvtmf4xvvl3aau522y6nu7gpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsznm94f

Publishing to

relay.snort.social

nos.lol

relay.damus.io

Last Notes

2023-06-09 15:04:29 CEST

- reply

📅 Original date posted:2021-11-24
📝 Original message:
We are talkin interoperability among impl not individual node operators
version management of chosen impl.
where Pierre of Acinq says
"So we eat our own dog food and will experience force closes before our
users do.."
hahaha made my day ...
a node operator do tests live in its continuous integration efforts would
be expected and should be able do so with a by impl assured latest stable
release version.
what is suggested for dialog is the different impl maintainers before sign
off a stable release do a extra test live on mainnet with liquidity in
channels towards the other impl versions and by doing so can catch
unforseen glitches that tests of impl in isolation can not catch.
what also suggested was a collection point where one could fetch loglines
from the instances partaking in the interoperability assurance test.
ex. impl (a) try open channel to impl (b) and fails --can then ask central
logline point for the loglines of ( a < -- > b ) at unix.ts(start) - range
- unix.ts(end).
this then would help assert a new release of a impl is interoperable and
can be recommende for install as considered be latest stable release
version.
LN a Network System Class "Finacial" need in preparation for onboarding 1B
by 2026 start to grow up *now*.
thanks
/xraid
On Wed, Nov 24, 2021 at 12:14 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning x-raid,
>
> > so You propose Acinq / Blockstream / Lightning Labs do not have funds to
> run a box or 2 ?
>
> Not at all, I am proposing that these people, who have already done the
> effort to release working Lightning Network Node implementations free of
> charge to you, are not obligated to *also* devote more hardware and
> resources.
>
> Let me tell a little story...
>
> Some years ago, during the SegWit wars, there was a sentiment "when are
> **they** going to implement Lightning??"
> Both anti-SegWit and pro-SegWit asked this:
>
> * anti-SegWit: Yeah, you need bigblocks, Lightning is vaporware, when are
> **they** going to implement Lightning?
> * pro-SegWit: Lightning is so totes kool, this is why we SegWit, when are
> **they** going to implement Lightning?
>
> After some time participating in the SegWit wars, I realized that I was,
> in fact, a programmer (LOL).
> So why should **I** be asking when **they** are going to implement
> Lightning?
> As a programmer, **I** could implement Lightning myself!
> I should be asking myself why **I** was not implementing it.
>
> Thus I started contributing to the Lightning implementation written in a
> language I could understand, C-Lightning.
>
>
> My question to you is: obviously you are a node operator as otherwise the
> issue you raise would not be relevant to you, but what can *you* do to
> advance your goal?
>
> (In any case: C-Lightning and Eclair devs have already mentioned they
> already run mainnet nodes tracking our respective master branches (i.e. we
> already eat our own dog food, because duh --- for many of us, the reason we
> are developing this is because for *other* reasons, we *have to* run
> Lightning nodes), is there any particular implementation you are concerned
> about?
> Maybe ask them directly?)
>
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211124/0f74cf48/attachment.html>

2023-06-09 15:04:28 CEST

- reply

📅 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>

2023-06-09 15:04:28 CEST

- reply

📅 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>

2023-06-09 15:04:27 CEST

- reply

📅 Original date posted:2021-11-23
📝 Original message:
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.
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?)
/xraid
On Tue, Nov 23, 2021 at 11:35 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning again x-raid,
>
> Are you proposing as well to provide the hardware and Internet connection
> for these boxes?
>
> I know of one person at least who runs a node that tracks the C-Lightning
> master (I think they do a nightly build?), and I run a node that I update
> every release of C-Lightning (and runs CLBOSS as well).
> I do not know the actual implementations of what they connect to, but LND
> is very popular on the network and LNBIG is known to be an LND shop, and
> LNBIG is so pervasive that nearly every long-lived forwarding node has at
> least one channel with *some* LNBIG node.
> I consider this "good enough" in practice to catch interop bugs, but some
> interop bugs are deeper than just direct node-to-node communications.
> For example, we had bugs in our interop with LND `keysend` before, by my
> memory.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211123/2a4afb38/attachment-0001.html>

2023-06-09 15:04:27 CEST

- reply

📅 Original date posted:2021-11-23
📝 Original message:
I propose a dialog of the below joint effort ...
thanks
/xraid
***
A decentralised integration lab where CL Eclair LDK LND (++ ?) runs each
the latest release on "one box" rBOX and master.rc on "another box" rcBOX.
The rBOX of each impl has a channels to the other impl rBOXés
same setup goes for rcBOXés.
These run on mainnet and can then be tested against from each of the impl
BOXés either in orchestration or as each impl team needs.
Each team would provide their impl of BOXés with managed channels between
all other impl.
This to ensure the biz critical nature of LN is well tested before any rc
becomes a public release and that LN is at a point in time where it is due.
***
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211123/ac659891/attachment.html>