On 5 February 2018 at 14:02, Christian Decker
> 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
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
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
eed a good estimator for
the number of differences (send min height + max height + a sample of
- 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
> 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
> 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
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
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)
> It’s alpha version, but it can decode some BOLT message.
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
decided to post here too to, to
> 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
On Tue, 8 Jan 2019 at 17:11, Christian Decker
> 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
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
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
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.
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
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
On Tue, 12 Oct 2021 at 01:14, Martin Habovštiak
> I can confirm I moved a repository few months ago and all links kept working
Yes, github makes it really easy, and you keep your issues, PRs,
stars, .. depending on your dev/packaging you may need to rename
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
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
Mail list logo