Damian Mee [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2019-11-08 to 2021-10-12
💬 Posted a total of 2 messages
📚 Participated in the following categories:
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-09 13:04:04

- reply

📅 Original date posted:2021-10-12
📝 Original message:
While I don't partake in the conversations too often, I just want to say I
strongly support Olaoluwa suggestion. AFAIAA there's a lot of automations,
dependencies, dockerfiles, or direct links to files that rely on the
location of lnd github repo, and I'm sure not all of it would be able to
handle Github redirect gracefully. While accessing spec is mostly a
human/browser activity, where dealing with redirects is much easier.
Plus, github.com/lightning/spec, github.com/lightning/bolts, and/or
github.com/lightning/rfc would all be trivial to remember, and quick to
type.
On Tue, Oct 12, 2021 at 2:57 PM Olaoluwa Osuntokun <laolu32 at gmail.com>
wrote:
> Hi Fabrice,
>
> > I believe that was a mistake: a few days ago, Arcane Research published a
> > fairly detailed report on the state of the Lightning Network:
> > https://twitter.com/ArcaneResearch/status/1445442967582302213. They
> > obviously did some real work there, and seem to imply that their report
> > was vetted by Open Node and Lightning Labs.
>
> Appreciate the hard work from Arcane on putting together this report. That
> said, our role wasn't to review the entire report, but instead to provide
> feedback on questions they had. Had we reviewed the section in question, we
> would have spotted those errors and told the authors to fix them. Mistakes
> happen, and we're glad it got corrected.
>
> Also note that lnd has _never_ referred to itself as the "reference"
> implementation. A few years ago some other implementations adopted that
> title themselves, but have since adopted softer language.
>
> > So I'm proposing that lnd's source code be removed from
> > https://github.com/lightningnetwork/ (and moved to
> > https://github.com/lightninglabs for example, with the rest of their
> > Lightning tools, but it's up to Lightning Labs).
>
> I think it's worth briefly revisiting a bit of history here w.r.t the
> github
> org in question. In the beginning, the lightningnetwork github org was
> created by Joseph, and the lightningnetwork/paper repo was added, the
> manuscript that kicked off this entire thing. Later lightningnetwork/lnd
> was
> created where we started to work on an initial implementation (before the
> BOLTs in their current form existed), and we were added as owners.
> Eventually we (devs of current impls) all met up in Milan and decided to
> converge on a single specification, thus we added the BOLTs to the same
> repo, despite it being used for lnd and knowingly so.
>
> We purposefully made a _new_ lightninglabs github org as we wanted to keep
> lnd, the implementation distinct from any of our future commercial
> products/services. To this day, we've architected all our paid products to
> be built _on top_ of lnd, rather than within it. As a result, users always
> opt into these services.
>
> As it seems the primary grievance here is collocating an implementation of
> Lightning along with the _specification_ of the protocol, and given that
> the
> spec was added last, how about we move the spec to an independent repo
> owned
> by the community? I currently have github.com/lightning, and would be
> happy
> to donate it to the community, or we could create a new org like
> "lightning-specs" or something similar. We could then move the spec (the
> BOLTs and also potentially the bLIPs since some devs want it to be within
> its own repo) there, and have it be the home for any other
> community-backed/owned projects. I think the creation of a new github
> organization would also be a good opportunity to further formalize the set
> of stakeholders and the general process related to the evolution of
> Lightning the protocol.
>
> Thoughts?
>
> -- Laolu
>
> On Fri, Oct 8, 2021 at 5:25 PM Fabrice Drouin <fabrice.drouin at acinq.fr>
> wrote:
>
>> Hello,
>>
>> When you navigate to https://github.com/lightningnetwork/ you find
>> - the Lightning Network white paper
>> - the Lightning Network specifications
>> - and ... the source code for lnd!
>>
>> This has been an anomaly for years, which has created some confusion
>> between Lightning the open-source protocol and Lightning Labs, one of
>> the companies specifying and implementing this protocol, but we didn't
>> do anything about it.
>>
>> I believe that was a mistake: a few days ago, Arcane Research
>> published a fairly detailed report on the state of the Lightning
>> Network: https://twitter.com/ArcaneResearch/status/1445442967582302213.
>> They obviously did some real work there, and seem to imply that their
>> report was vetted by Open Node and Lightning Labs.
>>
>> Yet in the first version that they published you’ll find this:
>>
>> "Lightning Labs, founded in 2016, has developed the reference client
>> for the Lightning Network called Lightning Network Daemon (LND)....
>> They also maintain the network standards documents (BOLTs)
>> repository."
>>
>> They changed it because we told them that it was wrong, but the fact
>> that in 2021 people who took time do do proper research, interviews,
>> ... can still misunderstand that badly how the Lightning developers
>> community works means that we ourselves badly underestimated how
>> confusing mixing the open-source specs for Lightning and the source
>> code for one of its implementations can be.
>>
>> To be clear, I'm not blaming Arcane Research that much for thinking
>> that an implementation of an open-source protocol that is hosted with
>> the white paper and specs for that protocol is a "reference"
>> implementation, and thinking that since Lightning Labs maintains lnd
>> then they probably maintain the other stuff too. The problem is how
>> that information is published.
>>
>> So I'm proposing that lnd's source code be removed from
>> https://github.com/lightningnetwork/ (and moved to
>> https://github.com/lightninglabs for example, with the rest of their
>> Lightning tools, but it's up to Lightning Labs).
>>
>> Thanks,
>>
>> Fabrice
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211012/ec257326/attachment-0001.html>

2023-06-09 13:04:04

- reply

2023-06-07 18:21:39

- reply

📅 Original date posted:2019-11-08
📝 Original message:> a new human-readable-prefix for length prefixed bitcoin witness
programs. "btc1" anyone?
Yes, please!
On Fri, Nov 8, 2019 at 2:04 PM Russell O'Connor via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I do like the idea of length prefixing the witness program. I will note
> that the 1 byte witness version is really more like a 1 character witness
> version. There are 17 different segwit versions and there are 32
> characters in the bech32 alphabet. That leaves 15 unused characters that
> we can use for assigning new meanings too.
>
> That said, it is probably most sensible to define a new
> human-readable-prefix for length prefixed bitcoin witness programs. "btc1"
> anyone?
>
> On Fri, Nov 8, 2019 at 12:12 AM ZmnSCPxj via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Good morning Pieter, and all,
>>
>> Can we modify Bech32 SegWit address format for version 1 and above as
>> below?
>>
>> * The data-part values:
>> ** 1 byte: the witness version
>> + ** If the witness version is non-zero, 1 byte: the length of the
>> witness program.
>> ** A conversion of the 2-to-40-byte witness program (as defined by [
>> https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP141])
>> to base32:
>> *** Start with the bits of the witness program, most significant
>> bit per byte first.
>> *** Re-arrange those bits into groups of 5, and pad with zeroes at
>> the end if needed.
>> *** Translate those bits to characters using the table above.
>>
>> This retains the ability of a bech32 address to specify any valid witness
>> length and allows future version 1 addresses with lengths other than 32,
>> while closing this malleation.
>>
>> Older software being given the modified v1 address format would mis-send
>> it to the wrong witness program, however.
>>
>> Alternately we could just keep using version 0 in the address format
>> forever.
>> The requirement would be to ensure that SegWit vN (N >= 1) output witness
>> programs would have a data-part value encoded as below:
>>
>> * The data-part values:
>> ** 1 byte: legacy witness version, which must always be 0.
>> ** 1 byte: actual witness version, which must be non-zero.
>> ** 1 byte: padding length: 0 or 1.
>> ** If padding length is 1, 1 byte: padding, which must be 0.
>> ** 1 byte: witness program length.
>> ** variable: witness program.
>>
>> A writer for a v1 or later address would initially set an empty padding,
>> then compute:
>>
>> 1 // actual witness version
>> + 1 // padding length
>> + 1 // witness length
>> + witness_length
>>
>> If the above sum is 20 or 32, then the writer selects a non-zero padding
>> and inserts the padding byte so that the above sum is now 21 or 33.
>>
>> To a reader that understands only bech32 v0, such an encoding would look
>> like a SegWit v0 invalid-program-length, and be rejected.
>> A reader which understands the above protocol would, instead of rejecting
>> a SegWit v0 invalid-program-length, instead attempt to parse it as above
>> first, and consider it as SegWit v1 or higher if it was parsed correctly as
>> above.
>>
>> The above proposal is of course ridiculous and I am now currently running
>> diagnostics on my processing units to see if further glitches occur in test
>> reasoning skills.
>>
>> Regards,
>> ZmnSCPxj
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191108/e3ee321a/attachment.html>