> I'm frankly still very confused why we're having these conversations now
This entire conversation strikes me as extremely premature and backwards
tbh. Someone experimenting with a new approach shouldn't prompt us to
immediately modify the protocol to better "fit" the
ory instead. I don't see the value in having both bLIPs and
>> BIPs since AFAICT they seem to be functionally equivalent and BIPs are
>> not restricted to exclude lightning, and never have been.
>> I believe the reason this move to BIPs hasn't happened organically is
> strongly encouraged to write specs for new lightning features
> elsewhere (like the BIP repo) then you would see this issue of growing
> BOLTs resolved.
> Ariel Lorenzo-Luaces
> On Wed, Jun 30, 2021 at 1:16 PM Olaoluwa Osuntokun
> That being said I think all the points that are addressed in Ryan's mail
> could very well be formalized into BOLTs but maybe we just need to rethink
> the current process of the BOLTs to make it more accessible for new ideas
> to find their way into the BOLTs?
I think part of what bLIPs are
> I think the problem of accidental channel closure is getting ignored by
> If we think any anti-DoS fee will be "insignificant" compared to the cost
> of closing and reopening a channel, maybe dev attention should be on
> fixing accidental channel closure costs than any anti-DoS fee
Thanks for such kind words!
> Is there a documentation for the client/server intercommunications
Long form documentation on the client/server protocol hasn't yet been
written. However, just like Loop, the Pool client uses a fully-featured gRPC
protocol to communicate with the
We've recently released a new system which may be of interest to this list,
Lightning Pool . Alongside a working client , we've also released a
white paper which goes deeper into the architecture of the system.
Pool builds on some earlier ideas that were tossed around the ML
> I suggest adding tlv records in `commitment_signed` to tell our channel >
> peer that we're changing the values of these fields.
I think this fits in nicely with the "parameter re-negotiation" portion of
loose Dynamic commitments proposal. Note that in that paradigm, something
> It seems to me that the "funder pays all the commit tx fees" rule exists
> solely for simplicity (which was totally reasonable).
At this stage, I've learned that simplicity (when doing anything that
involves multi-party on-chain fee negotiating/verification/enforcement can
really go a long
I think an even simpler mitigation is just for the non-initiator to _reject_
update_fee proposals that are "unreasonable". The non-initiator can run a
"fee leak calculation" to compute the worst-case leakage of fees in the
revocation case. This can be done to day
> Probably arguably off-topic, but this post triggered me into thinking
> about an insane idea: offchain update from existing Poon-Dryja to newer
> Decker-Russell-Osuntokun ("eltoo") mechanism.
Ooo, yeh I don't see why this would be possible assuming at that point
no_input has been
queue these un-acked
> and replay them after the commitment format update completes (or just drop
> and cancel corresponding upstream HTLCs if needed).
> Regarding initiating the commitment format update, how do you see this
> The funder activate
On Mon, Jul 20, 2020 at 6:18 PM Olaoluwa Osuntokun
> Hi y'all,
> In this post, I'd like to share an early version of an extension to the
> and channel state machine that would allow for on-the-fly commitment
> _format/type_ changes. Notably, this wou
In this post, I'd like to share an early version of an extension to the spec
and channel state machine that would allow for on-the-fly commitment
_format/type_ changes. Notably, this would allow for us to _upgrade_
commitment types without any on-chain activity, executed in a
The up-front costs can be further mitigated even without something like CTV
(which makes things more efficient) by adding a layer of in-direction w.r.t
HTLCs are manifested within the commitment transactions. To do this, we add
new 2-of-2 multi-sig output (an HTLC indirect block)
IMO this is mostly mitigated by anchor commitments. The impact of this
attack is predicated on the "victim" paying 5x on-chain fees (for their
confirmation target) to sweep all their HTLCs. Anchor commitments let the
initiator of the channel select a very low starting fee (just enough
> Even with cheaper, more efficient protocols like BIP 157, you may have a
> huge discrepancy between what is asked and what is offered. Assuming 10M
> light clients  each of them consuming ~100MB/month for filters/headers,
> that means you're asking 1PB/month of traffic to the
BOLTs, which does actually seem relatively
> minimal (although as you mention, these minimal changes to the BOLTs do
> trigger large changes in many implementations). Also, good point on how
> BOLT 11 (invoicing) will have to be altered as well, must've slipped my
Thanks for the updates! Super cool to see this concept continue to evolve
and integrate new technologies as they pop up.
> I believe this would only require a few changes to existing nodes:
Rather than a "few changes", this would to date be the largest network-level
fee increase, it's likely that the war terminates
with _one_ of them getting into the block, which seems to resolve
On Wed, Apr 22, 2020 at 4:20 PM Matt Corallo
> On Apr 22, 2020, at 16:13, Olaoluwa Osuntokun wrote:
> > Hmm, maybe the prop
en everyone is
On Wed, Apr 22, 2020 at 9:50 AM Matt Corallo
> A few replies inline.
> On 4/22/20 12:13 AM, Olaoluwa Osuntokun wrote:
> > Hi Matt,
> >> While this is somewha
, Apr 22, 2020 at 4:05 PM Olaoluwa Osuntokun
> Hi Z,
> > It seems to me that, if my cached understanding that `<0>
> > OP_CHECKSEQUENCEVERIFY` is sufficient to require RBF-flagging, then
> > that to the hashlock branch (2 witness bytes, 0.5 weight) w
> It seems to me that, if my cached understanding that `<0>
> OP_CHECKSEQUENCEVERIFY` is sufficient to require RBF-flagging, then adding
> that to the hashlock branch (2 witness bytes, 0.5 weight) would be a
> low-weight mitigation against this attack.
I think this works...so
> So what is needed is to allow B to add fees to HTLC-Timeout:
Indeed, anchors as defined in #lightning-rfc/688 allows this.
> * With `SIGHASH_NOINPUT` we can make the C-side signature
> `SIGHASH_NOINPUT|SIGHASH_SINGLE` and allow B to re-sign the B-side
> signature for a higher-fee version of
> While this is somewhat unintuitive, there are any number of good anti-DoS
> reasons for this, eg:
None of these really strikes me as "good" reasons for this limitation, which
is at the root of this issue, and will also plague any more complex Bitcoin
contracts which rely on nested
We've been discussing the current state of the spec and implementation
readiness of anchor outputs for a few week now on IRC. As detailed
conversations are at times difficult to have on IRC, and there's no true
history, I figured I'd start a new discussion thread where we can hammer out
A new paper analyzing the security of the Sphinx mix-net packet format 
(and also HORNET) has recently caught my attention. The paper is rather long
and very theory heavy, but the TL;DR is this:
* The OG Sphinx paper proved various aspects of its security using a
Agreed w.r.t the need for prepaid HTLCS, I've been mulling over other
alternatives for a few years now, and none of them seems to resolve the
series of routing related incentive issues that prepaid HTLCs would.
> Since both Offers and Joost's WhatSat are looking at sending messages,
> She creates a Bolt 11 invoice containing that pre-encrypted onion.
This seem insufficient, as if the prescribed route that Alice selects fails,
then the sender has no further information to go off of (let's say Teddy is
offline, but there're other pats). cdecker's rendezvous sketch
I think this change may be a bit misguided, and we should be careful about
making sweeping changes to default values like this such as fees. I'm
worried that this post (and the subsequent LGTMs by some developers)
promotes the notion that somehow in Lightning, developers decide on fees
-BEGIN PGP SIGNED MESSAGE-
We've confirmed instances of the CVE being exploited in the wild. If you’re
not on the following versions of either of these implementations (these
versions are fully patched), then you need to upgrade now to avoid risk of
> I found out recently (mid-2019) that mainnet Lightning nodes take an
> inordinate amount of time to find a route between themselves and an
> arbitrary payee node.
> Typical quotes suggested that commodity hardware would take 2 seconds to
> find a route
Can you provide a reproducible benchmark
I'm not sure how good defenses are on implementations other than lnd, but
all implementations *should* be keeping a Sphinx reply cache of the past
shared secrets they know of . If a node comes across an identical shared
secret of that in the cache, then they should reject that
Recently we've started to do more design work related to the Sphinx packet
(EOB format, rendezvous protocol). This prompted me to re-visit the original
Sphinx paper to refresh my memory w.r.t some of the finer details of the
protocol. While I was re-reading the paper, I realized that
> This saves the receiving node from doing a database lookup
Nodes can and eventually should start using bloom filters to avoid most
database lookups for incoming payment hashes. The false positive rate can be
set to a very low value as the bloom filter doesn't need to transmitted,
It isn't mandatory. It can be left blank, none of the existing wallets
require users to input a description when they make an invoice.
On Mon, Jan 14, 2019, 3:28 PM Francis Pouliot I'm currently in the process of building the Lightning Network payout
> feature which will allow users to purchase
> OG AMP is inherently spontaneous in nature, therefore invoice might not
> to put the feature on.
That is incorrect. One can use an invoice along with AMP as is, in order to
a payment. As an example, I want to deposit to an exhcange, so I get an
from them. I note that the
I realized the other day that the wumbo bit should also likely encompass
payments. What good is a wumbo channel that doesn't also allow wumbo
Naturally if the bit is signalled globally, then this should also signal the
willingness of the node to forward larger payments up to their
> If I'm not mistaken it'll not be possible for us to have spontaneous
> ephemeral key switches while forwarding a payment
If this _was_ possible, then it seems that it would allow nodes to create
unbounded path lengths (looks to other nodes as a normal packet), possibly
by controlling multiple
Was approaching more so from the angle of a node new node with no existing
channels seeking to bootstrap connections to the network.
-- Sent from my Spaceship
On Fri, Nov 9, 2018, 9:10 AM Anthony Towns On Thu, Nov 08, 2018 at 05:32:01PM +1030, Olaoluwa Osuntokun wrote:
> > > A
> A node, via their node_announcement,
Most implementations today will ignore node announcements from nodes that
don't have any channels, in order to maintain the smallest routing set
possible (no zombies, etc). It seems for this to work, we would need to undo
this at a global scale to ensure
I think HORNET would address this rather nicely!
During the set up phase (which uses Sphinx), the sender is able to get a
of if the route is actually "lively" or not, as the circuit can't be
if all the nodes aren't available. Additionally, during the set up phase,
r operation up
On Wed, Oct 17, 2018 at 9:31 AM Rusty Russell wrote:
> Olaoluwa Osuntokun writes:
> > Hi Rusty,
> > Happy to get the splicing train rolling!
> >> We've had increasing numbers of c-lightning users get upset the
This is so dope! We've long discussed creating canned protocol transcripts
other implementations to assert their responses again, and I think this is a
great first step towards that.
> Our proposal:
> Every implementation has compile option which enable output key
> However personally I do not really see the need to create multiple
> to a single peer, or increase the capacity with a specific peer (via
> or dual-funding). As Christian says in the other mail, this
> is that it becomes less a network and more of some channels to
> This seems at odds with the goal of "if the remote party force closes,
> I get my funds back immediately without requiring knowledge of any secret
Scratch that: the static back ups just need to include this CSV value!
On Tue, Nov 6, 2018 at 3:29 PM
I'm a big fan in general of most of this! Amongst many other things, it'll:
simplify the whole static channel backup + recovery workflow, and avoid all
the fee related headaches we've run into over the past few months.
> - HTLC-timeout and HTLC-success txs sigs are
> I would suggest more to consider the simpler method, despite its larger
> onchain footprint (which is galling),
The on-chain footprint is a shame, and also it gets worse if we start to
allow multiple pending splices. Also the lack of a non-blocking splice in is
a big draw back IMO.
you cancel back, then they know that you had enough
bandwidth to _accept_ the HTLC in the first place.
On Wed, Sep 26, 2018 at 5:54 PM Rusty Russell wrote:
> Olaoluwa Osuntokun writes:
> >> That might not be so desirable, since it leaks the current channel
> >> cap
> message from BOLT #1
>* If the error is not specific to any channel: set channel_id to 0.
> A receiving node
>* If experiment_name_hash is unknown:
> - MUST fail the channel.
>* If channel_id is 0
> - MUST fail all the channels
n was not about creating another place
> but more about making the process more transparent or kind of filling the
> gap that I felt was there.
> I am sorry for spaming mailboxes with my suggestion just because I didn't
> understand the current process.
We already have the equiv of improvement proposals: BOLTs. Historically new
standardization documents are proposed initially as issues or PR's when
ultimately accepted. Why do we need another repo?
On Sun, Jul 22, 2018, 6:45 AM René Pickhardt via Lightning-dev <
> #1 lets us leave out double-funded channels. #2 and #3 lets us leave out
> For myself, I would rather leave out AMP and double-funding and splicing
> than remove ZKCP.
It isn't one or the other. ZKCPs are compatible with various flavors of AMP.
All of these technologies can be
like everything else does.
Also, everything we can do with Schnorr, we can also do with ECDSA, but
On Wed, Jul 4, 2018 at 7:12 PM Rusty Russell wrote:
> Olaoluwa Osuntokun writes:
> > What's the nasty compromise?
> > Let's also not under
What's the nasty compromise?
Let's also not underestimate how big of an update switching to dlog based
HTLCs will be.
On Wed, Jul 4, 2018, 4:21 PM Rusty Russell wrote:
> Christian Decker writes:
> > ZmnSCPxj via Lightning-dev
> >> For myself, I think splice is less priority than
> Yet the question remains — are there obvious advantages of cycle
> transactions over a smart fee/routing system?
That's a good question, it may be the case that by modifying the fee
structure to punish flows that unbalance channels further, then this can
simplify the problem as
Speaking at a high level, the main differ between modifying autopilot
strategies (channel bootstrapping, and maintenance) vs something like
splicing, is that the former is purely policy while the latter is actually a
protocol modifications. With respect to difficulty, the first option
FWIW, Conner pointed out that the initial ZK Proof for the correctness of
Paillier params (even w/ usage of bulletproofs) has multiple rounds of
iirc up to 5+ (with additional pipelining) rounds of interaction.
On Mon, May 7, 2018 at 5:14 PM Olaoluwa Osuntokun <l
Very cool stuff! When I originally discovered the Lindell's technique, my
immediate thought was the we could phase this in as a way to _immediately_
additional Script upgrades required), replace the regular 2-of-2 mulit-sig
a single p2wkh. The immediate advantages of this
AFAIK, all the other implementations already do this (lnd does at least
). As otherwise, it wouldn't be possible to properly utilize routing
> I want to ask the other LN implementations (lnd, eclair, ucoin, lit)
As an side, what's "ucoin"? Searched for a bit and didn't find anything
> It seems to me, that the only safe way to implement a trustless
> is for the node to generate a fully-signed justice transaction,
> after every commitment transaction is revoked, and transmit it to the
No, one doesn't need to transmit the
date link policy
state is for optimization/analysis, or to minimize payment latency at the
cost of additional load.
On Fri, Feb 23, 2018 at 4:45 PM Olaoluwa Osuntokun <laol...@gmail.com>
> Hi Rusty,
> > 1. query_short_channel_id
> > IMPLEMENTATION
> 1. query_short_channel_id
> IMPLEMENTATION: trivial
> 2. query_channel_range/reply_channel_range
> IMPLEMENTATION: requires channel index by block number, zlib
For the sake of expediency of deployment, if we add a byte (or two) to
denote the encoding/compression scheme,
> This is excellent work!
> I think, a `globalfeatures` odd bit could be used for this. As it is
> end-ot-end, `localfeatures` is not appropriate.
Yep, it would need to be a global feature bit. In the case that we're
sending to a destination which isn't publicly
Segwit has been merged into btcd for for sometime now. It's also possible to
run with bitcoind. I encourage you to check out the documentation:
In lnd, the chain backend has already been abstracted. This is what
in some of your comments and the answers to
> your questions in the last email. And of course, I would be happy to
> further discuss with you.
> On 11/25/17 2:16 PM, Olaoluwa Osuntokun wrote:
> > (final try as the prior mail hit the size limit, sorry for the spam!)
I came across this paper a few weeks ago, skimmed it lightly, and noted a
few interesting aspects I wanted to dig into later. Your email reminded me
to re-read the paper, so thanks for that! Before reading the paper, I
wasn't aware of the concept of coordinate embedding, nor how that
> I think it does already:
Yep! An oversight on my part.
> So, you're suggesting SIGHASH_SINGLE|SIGHASH_ANYONECANPAY?
Precisely. The code modifications required to switch to this signing mode
> though it's a pretty obscure case where we want to close out many HTLCs at
> once; this
Mail list logo