Re: [Lightning-dev] Removing lnd's source code from the Lightning specs repository

On Tue, 12 Oct 2021 at 21:57, Olaoluwa Osuntokun wrote: > 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. I don't remember that but if

Re: [Lightning-dev] Removing lnd's source code from the Lightning specs repository

On Tue, 12 Oct 2021 at 01:14, Martin Habovštiak wrote: > > I can confirm I moved a repository few months ago and all links kept working > fine. > Yes, github makes it really easy, and you keep your issues, PRs, stars, .. depending on your dev/packaging you may need to rename packages (something

[Lightning-dev] Removing lnd's source code from the Lightning specs repository

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

Re: [Lightning-dev] Unification of feature bits?

On Mon, 21 Jan 2019 at 08:05, Rusty Russell wrote: > > Hi all, > > I have a concrete proposal for feature bits. > > 1. Rename 'local features' to 'peer features'. > 2. Rename 'global features' to 'routing features'. > 3. Have them share a number space (ie. peer and routing features don't

Re: [Lightning-dev] Quick analysis of channel_update data

ell wrote: > > Fabrice Drouin writes: > > I think there may even be a simpler case where not replacing updates > > will result in nodes not knowing that a channel has been re-enabled: > > suppose you got 3 updates U1, U2, U3 for the same channel, U2 disables > > it, U

Re: [Lightning-dev] Quick analysis of channel_update data

On Tue, 8 Jan 2019 at 17:11, Christian Decker wrote: > > Rusty Russell writes: > > Fortunately, this seems fairly easy to handle: discard the newer > > duplicate (unless > 1 week old). For future more advanced > > reconstruction schemes (eg. INV or minisketch), we could remember the > > latest

Re: [Lightning-dev] Lite client considerations for Lightning Implementations

Hi Chris, What we've learned building a lite bitcoin/LN wallet is that there are different things it must implement: - a bitcoin wallet. We started with bitcoinj, but there are known issues with Bloom Filters, which is one of the reasons why we ended up building our own wallet that connect to

Re: [Lightning-dev] Quick analysis of channel_update data

On Fri, 4 Jan 2019 at 04:43, ZmnSCPxj wrote: > > - in set reconciliation schemes: we could reconcile [channel id | > > timestamp | checksum] first > > Perhaps I misunderstand how set reconciliation works, but --- if timestamp is > changed while checksum is not, then it would still be seen

Re: [Lightning-dev] Quick analysis of channel_update data

Follow-up: here's more detailed info on the data I collected and potential savings we could achieve: I made hourly routing table backups for 12 days, and collected routing information for 17 000 channel ids. There are 130 000 different channel updates :on average each channel has been updated 8

[Lightning-dev] Quick analysis of channel_update data

Hello All, and Happy New Year! To understand why there is a steady stream of channel updates, even when fee parameters don't seem to actually change, I made hourly backups of the routing table of one of our nodes, and compared these routing tables to see what exactly was being modified. It turns

[Lightning-dev] Improving payment UX with low-latency route probing

Context == Sent payments that remain pending, i.e. payments which have not yet been failed or fulfilled, are currently a major UX challenge for LN and a common source of complaints from end-users. Why payments are not fulfilled quickly is not always easy to investigate, but we've seen

Re: [Lightning-dev] Wireshark plug-in for Lightning Network(BOLT) protocol

Nice work, thank you! On Fri, 26 Oct 2018 at 17:37, wrote: > > Hello lightning network developers. > Nayuta team is developing Wireshark plug-in for Lightning Network(BOLT) > protocol. > https://github.com/nayutaco/lightning-dissector > > It’s alpha version, but it can decode some BOLT message.

Re: [Lightning-dev] Commitment Transaction Format Update Proposals?

Hello, > 1. Rather than trying to agree on what fees will be in the future, we > should use an OP_TRUE-style output to allow CPFP (Roasbeef) We could also use SIGHASH_ANYONECANPAY|SIGHASH_SINGLE for HTLC txs, without adding the "OP_TRUE" output to the commitment transaction. We would still

Re: [Lightning-dev] Proposal for syncing channel updates

Hi Zmn, > It may be reduced to a set reconciliation problem if we consider the > timestamp and enable/disable state of channel updates as part of an item, > i.e. a channel update of 111:1:1 at 2018-10-04 state=enabled is not the same > as a channel update of 111:1:1 at 2018-10-05

[Lightning-dev] Proposal for syncing channel updates

Hi, This a a proposal for an extension of our current “channel queries” that should allow nodes to properly sync their outdated channel updates. I already opened a issue on the RFC’s github repo (https://github.com/lightningnetwork/lightning-rfc/issues/480) but decided to post here too to, to

Re: [Lightning-dev] Improving the initial gossip sync

On 20 February 2018 at 02:08, Rusty Russell wrote: > Hi all, > > This consumed much of our lightning dev interop call today! But > I think we have a way forward, which is in three parts, gated by a new > feature bitpair: We've built a prototype with a new feature

Re: [Lightning-dev] Improving the initial gossip sync

eed a good estimator for the number of differences (send min height + max height + a sample of announcements ?) - Filters become peer-specific (similar to the server-side vs client-side filtering for SPV clients) On 16 February 2018 at 13:34, Fabrice Drouin <fabrice.dro...@acinq.fr> wro

Re: [Lightning-dev] Improving the initial gossip sync

- 1 week (modulo 144) One filter per block for recent announcements > > FWIW this approach optimizes for just learning of new channels instead of > learning of the freshest state you haven't yet seen. I'd say it optimizes the case where you are connected to very few peers, and are online a fe

Re: [Lightning-dev] Improving the initial gossip sync

Hi, On 5 February 2018 at 14:02, Christian Decker wrote: > Hi everyone > > The feature bit is even, meaning that it is required from the peer, > since we extend the `init` message itself, and a peer that does not > support this feature would be unable to parse any