Bastien TEINTURIER [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2019-05-15 to 2023-06-07
💬 Posted a total of 124 messages
📚 Participated in the following categories: bitcoin-dev, Lightning-dev, RFC
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0s

Profile Code

nprofile1qqs0yetf5y8c8a5n27tm3df6s7t5lhxpme4t6v0rkx36rx76akqrrjc0u4zeu

Author Public Key

npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0s

Show more details

Last Notes

2023-10-18 13:02:10

- reply

📅 Original date posted:2023-10-17
🗒️ Summary of this message: A protocol is being designed to allow users to withdraw funds from exchanges directly into their lightning wallet with minimal on-chain activity. This requires the use of covenants to batch multiple transactions into one.
📝 Original message:
Good morning list,
I've been trying to design a protocol to let users withdraw funds from
exchanges directly into their lightning wallet in an efficient way
(with the smallest on-chain footprint possible).
I've come to the conclusion that this is only possible with some form of
covenants (e.g. `SIGHASH_ANYPREVOUT` would work fine in this case). The
goal of this post is to explain why, and add this usecase to the list of
useful things we could do if we had covenants (insert "wen APO?" meme).
The naive way of enabling lightning withdrawals is to make the user
provide a lightning invoice that the exchange pays over lightning. The
issue is that in most cases, this simply shifts the burden of making an
on-chain transaction to the user's wallet provider: if the user doesn't
have enough inbound liquidity (which is likely), a splice transaction
will be necessary. If N users withdraw funds from an exchange, we most
likely will end up with N separate splice transactions.
Hence the idea of batching those into a single transaction. Since we
don't want to introduce any intermediate transaction, we must be able
to create one transaction that splices multiple channels at once. The
issue is that for each of these channels, we need a signature from the
corresponding wallet user, because we're spending the current funding
output, which is a 2-of-2 multisig between the wallet user and the
wallet provider. So we run into the usual availability problem: we need
signatures from N users who may not be online at the same time, and if
one of those users never comes online or doesn't complete the protocol,
we must discard the whole batch.
There is a workaround though: each wallet user can provide a signature
using `SIGHASH_SINGLE | SIGHASH_ANYONECANPAY` that spends their current
funding output to create a new funding output with the expected amount.
This lets users sign *before* knowing the final transaction, which the
exchange can create by batching pairs of inputs/outputs. But this has
a fatal issue: at that point the wallet user has no way of spending the
new funding output (since it is also a 2-of-2 between the wallet user
and the wallet provider). The wallet provider can now blackmail the user
and force them to pay to get their funds back.
Lightning normally fixes this by exchanging signatures for a commitment
transaction that sends the funds back to their owners *before* signing
the parent funding/splice transaction. But here that is impossible,
because we don't know yet the `txid` of the batch transaction (that's
the whole point, we want to be able to sign before creating the batch)
so we don't know the new `prevout` we should spend from. I couldn't find
a clever way to work around that, and I don't think there is one (but
I would be happy to be wrong).
With `SIGHASH_ANYPREVOUT`, this is immediately fixed: we can exchange
anyprevout signatures for the commitment transaction, and they will be
valid to spend from the batch transaction. We are safe from signature
reuse, because funding keys are rotated at each splice so we will never
create another output that uses the same 2-of-2 script.
I haven't looked at other forms of covenants, but most of them likely
address this problem as well.
Cheers,
Bastien
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20231017/8902099c/attachment.html>

2023-09-12 08:59:58

- reply

📅 Original date posted:2023-09-08
🗒️ Summary of this message: The discussion is about implementing security measures for RPC calls in a lightning node, either using Bolt 8 or managing runes inside a hardware security module (HSM). The configuration of access control on the lightning node side is also mentioned.
📝 Original message:
Hey Christian,
You're right, if we create runes inside the HSM then we end up with the
same security model.
It then boils down to whether we'd rather implement Bolt 8 or rune
management inside an HSM!
I'd prefer Bolt 8, as I think it has more universality (and is simpler),
but it could be worth experimenting with both approaches.
It will also be interesting to see how we actually configure rights (access
control) on the lightning node side.
That really deserves some implementation work to flesh out that kind of
details.
Cheers,
Bastien
Le ven. 8 sept. 2023 à 16:51, Christian Decker <decker.christian at gmail.com>
a écrit :
> Very interesting proposal, though as Will points out we could implement
> the same using runes: have the rune be managed by the hardware wallet, and
> commit the rune used to authenticate the RPC call commit to the call's
> payload. That way a potentially compromised client cannot authenticate
> arbitrary calls, since the hardware wallet is required to associate a rune
> with it, giving it a chance for review.
>
> This is similar to how authentication of RPC calls works in greenlight,
> where the node host is not trusted, and we need to pass the authenticated
> commands forward to the signer for verification before processing any
> signature request from the node. We chose to authenticate the payload
> rather than the transport (which is what partonnere does) because it
> removes the need for a direct connection, and adds flexibility to how we
> can deliver the commands. Functionally they are very similar however.
>
> Cheers,
> Christian
>
> On Thu, Sep 7, 2023, 15:06 Bastien TEINTURIER <bastien at acinq.fr> wrote:
>
>> Hi William,
>>
>> > What is wrong with runes/macaroons for validating and authenticating
>> > commands?
>>
>> Runes/macaroons don't provide any protection if the machine you are
>> issuing the RPCs from is compromised. The attacker can change the
>> parameters of your RPC call and your lightning node will still gladly
>> execute it.
>>
>> > I can't imagine validating every RPC request with a hardware
>> > device and trusted display, unless you have some specific use case in
>> > mind.
>>
>> I think that this is because you have the wrong idea of which RPCs
>> this is supposed to protect. This is useful for the RPCs that actually
>> involve paying something (channel open, channel close, pay invoice).
>> This isn't useful for "read" RPCs (listing channels).
>>
>> Making an on-chain operation or paying an invoice is something that is
>> infrequent enough for the vast majority of nodes that it makes sense
>> to validate it manually. Also, this is fully configurable: you can
>> choose which RPCs you want to protect that way and which RPCs you want
>> to keep open.
>>
>> Thanks,
>> Bastien
>>
>> Le mer. 6 sept. 2023 à 17:42, William Casarin <jb55 at jb55.com> a écrit :
>> >
>> > On Wed, Sep 06, 2023 at 03:32:50AM +0200, Bastien TEINTURIER wrote:
>> > >Hey Zman,
>> > >
>> > >I saw the announcement about the commando plugin, and it was actually
>> > >one of the reasons I wanted to write up what I had in mind, because
>> > >while commando also uses a lightning connection to send commands to a
>> > >lightning node, it was missing what in my opinion is the most important
>> > >part: having all of Bolt 8 handled by the HSM and validating commands
>> > >using a trusted display.
>> >
>> > What is wrong with runes/macaroons for validating and authenticating
>> > commands? I can't imagine validating every RPC request with a hardware
>> > device and trusted display, unless you have some specific use case in
>> > mind.
>> >
>> > Will
>> _______________________________________________
>> 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/20230909/3408f167/attachment.html>

2023-09-12 08:59:58

- reply

📅 Original date posted:2023-09-07
🗒️ Summary of this message: Runes/macaroons don't protect against compromised machines. Validating RPCs manually is useful for payment-related operations, not for "read" RPCs.
📝 Original message:
Hi William,
> What is wrong with runes/macaroons for validating and authenticating
> commands?
Runes/macaroons don't provide any protection if the machine you are
issuing the RPCs from is compromised. The attacker can change the
parameters of your RPC call and your lightning node will still gladly
execute it.
> I can't imagine validating every RPC request with a hardware
> device and trusted display, unless you have some specific use case in
> mind.
I think that this is because you have the wrong idea of which RPCs
this is supposed to protect. This is useful for the RPCs that actually
involve paying something (channel open, channel close, pay invoice).
This isn't useful for "read" RPCs (listing channels).
Making an on-chain operation or paying an invoice is something that is
infrequent enough for the vast majority of nodes that it makes sense
to validate it manually. Also, this is fully configurable: you can
choose which RPCs you want to protect that way and which RPCs you want
to keep open.
Thanks,
Bastien
Le mer. 6 sept. 2023 à 17:42, William Casarin <jb55 at jb55.com> a écrit :
>
> On Wed, Sep 06, 2023 at 03:32:50AM +0200, Bastien TEINTURIER wrote:
> >Hey Zman,
> >
> >I saw the announcement about the commando plugin, and it was actually
> >one of the reasons I wanted to write up what I had in mind, because
> >while commando also uses a lightning connection to send commands to a
> >lightning node, it was missing what in my opinion is the most important
> >part: having all of Bolt 8 handled by the HSM and validating commands
> >using a trusted display.
>
> What is wrong with runes/macaroons for validating and authenticating
> commands? I can't imagine validating every RPC request with a hardware
> device and trusted display, unless you have some specific use case in
> mind.
>
> Will
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230907/eaf3421b/attachment.html>

2023-08-21 09:48:48

- reply

📅 Original date posted:2023-08-16
🗒️ Summary of this message: The author argues that fraud proofs for Lightning channels are unnecessary and dangerous, suggesting that mobile wallets can check the state of returned backups to prevent cheating. They also mention a BOLT PR for backups.
📝 Original message:
Hi Thomas,
I don't think those fraud proofs are necessary at all. They're also
dangerous, because they impose a hard penalty on LSPs for something
that should be best effort (and could get desynchronized by connection
issues, especially with flaky mobile connections).
I agree with Peter Todd that since the mobile wallet can check the state
of the returned backup at every connection request, this makes it highly
unlikely that the LSP can cheat: that's the approach we've taken for
Phoenix.
I'm surprised that you don't mention the BOLT PR we created for those
backups in [1], I believe that is sufficient. It should probably be
moved to a blip instead of a BOLT once we've implemented this version
(the approach we use in Phoenix currently is slightly different), but
apart from that it contains all the mechanisms necessary to achieve
this today.
Cheers,
Bastien
[1] https://github.com/lightning/bolts/pull/881
Le mar. 15 août 2023 à 05:52, Thomas Voegtlin <thomasv at electrum.org> a
écrit :
> Hello list,
>
> Here is an idea to make lightning channels resumable from wallet seed.
> I have not implemented it yet, and there might be issues I am not
> seeing. Thus, I would be grateful for feedback.
>
> Thanks to SomberNight and Peter Todd for reviewing earlier versions of
> this proposal.
>
> Thomas
>
>
> -----------------------------------------------
>
> Resumable channels using OP_CHECKSIGFROMSTACK
> =============================================
>
>
> In order to resume the activity of a Lightning channel, one needs a
> backup that contains all the information about the current channel
> state. The need to perform channel backups has plagued user
> experience, with many implementations reverting to static backups,
> which can be used to recover funds, but not to resume channel
> operations.
>
> Asking your channel counterparty to store your channel state has the
> advantage to make backup operations atomic. However, there is no
> guarantee that this is safe. Indeed, if the other party suspects that
> you have lost your state (for example, because you have been offline
> for a long time, or if they can see that you requested blockchain
> information following a certain pattern), they can try to send you a
> revoked state, and there is no way to punish them for doing that.
>
> Here is a proposal for a new type of channel funding transaction,
> where the redeem script has an additional spending path, that accepts
> a fraud proof: a proof that the channel counterparty has lied about
> the current state. This proposal requires two opcodes that are
> currently not available in Bitcoin: OP_CAT and OP_CHECKSIGFROMSTACK.
>
> Roles are asymmetric in this channel: Alice is a client, and Bob is a
> server, who stores Alice's state. Thus, this proposal is mostly suited
> for private channels with Lightning service providers. During channel
> reestablishment, Bob will send her latest state to Alice, using an
> extra field in the channel_reestablish message. Since Alice cannot
> punish Bob if she has lost her state, she must not let Bob learn
> whether she still has her state. Thus, Alice will never send
> channel_reestablish first.
>
> This proposal assumes that Alice and Bob each have a clock, and that
> these clocks do not drift too much relative to each other. The channel
> may become unusable if clocks differ too much, as discussed below.
>
>
> Simplified description
> ----------------------
>
> The *state* of the channel refers to everything Alice needs in order
> to resume channel operations. With every new commitment, Alice sends
> her current state, with her signature of that state:
>
> - if Alice sends commitment_signed, the state and signature are
> included in that message.
>
> - if Alice receives commitment_signed, the state and signature will
> be included in the next revoke_and_ack sent by Alice.
>
> With every new commitment, Bob sends a signed tuple (ctn, timestamp),
> where ctn is the current commitment number (for the moment, forget
> about the distinction between local and remote ctns), and timestamp is
> the current time for Bob.
>
> - if Bob sends commitment_signed, the signed tuple is included in
> that message.
>
> - if Bob receives commitment_signed, the signed tuple will be
> included in the next revoke_and_ack sent by Bob.
>
> The private key used by Bob to sign the tuples is constant over the
> lifetime of the channel, and it must not be reused in other
> channels. The corresponding public key will be used in the fraud proof
> spending path of the redeem script.
>
> Alice verifies Bob's signature. She also checks that the received
> timestamps are reasonable (see below) and strictly monotonic.
>
> With every channel_reestablish message, Bob will send two extra fields:
> - (ctn, timestamp, bob_signature)
> - (alice_state, alice_signature).
>
> Alice verifies that the state she received was signed by her, and that
> the (ctn, timestamp) tuple was signed by Bob. She also checks that the
> timestamp is reasonable.
>
> Fraud Proofs
> ------------
>
> Let us assume that Bob tries to send a revoked state to Alice in
> channel_reestablish. The channel_reestablish received by Alice
> contains a signed tuple (ctn1, t1), with t1 current timestamp.
>
> However, another signed tuple (ctn2, t2) has been received in the
> past, with ctn1 < ctn2 and t1 > t2.
>
> If Alice has not lost her state, she will now hold two signed tuples
> (ctn1, t1) and (ctn2, t2), that satisfy ctn1 < ctn2 and t1 > t2.
>
> This constitutes a fraud proof. With OP_CAT and OP_CHECKSIGFROMSTACK,
> we can build a script that verifies the fraud proof, and allows Alice
> to unilaterally spend the channel funding output.
>
> Here is an example of such a script:
>
> witness:
> [
> alice_signature(transaction)
> bob_signature((ctn1,timestamp1))
> ctn1
> timestamp1
> bob_signature((ctn2,timestamp2))
> ctn2
> timestamp2
> ]
>
> witness_script:
> OP_PICK 1
> OP_PICK 4
> OP_LESSTHAN # verify ctn1 < ctn2
> OP_VERIFY
> OP_PICK 0
> OP_PICK 3
> OP_GREATERTHANOREQUAL # verify timestamp1 >= timestamp2
> OP_VERIFY
> # check signatures
> OP_CAT
> OP_PUSHDATA bob_pubkey # we may use Bob's funding_pubkey
> OP_CHECKSIGFROMSTACK
> OP_VERIFY
> OP_CAT
> OP_PUSHDATA bob_pubkey
> OP_CHECKSIGFROMSTACK
> OP_VERIFY
> OP_PUSHDATA alice_pubkey # we may use Alice's funding_pubkey
> OP_CHECKSIGVERIFY
>
>
> In order to keep things simple, a few details have been omitted in the
> description:
>
> - Bob actually needs to send both the local and the remote ctns in
> his signed tuples. A pair of tuples is a fraud proof if the order
> is violated for either local or remote ctns. Thus, the actual
> script will be more complex than what has been drafted above.
>
> - Integers pushed on the Bitcoin stack are maximum 4 bytes (31 bits +
> 1 bit for the sign). Since commitment numbers are 48 bits long,
> they will need to be split into two integers. Timestamps might
> require a similar decomposition. This adds further complexity to
> the redeem script.
>
> - Note that Bob must strictly increase his timestamp on each
> ctn. This puts a lower bound on the precision used for timestamps.
>
>
> Reasonable Timestamps
> ---------------------
>
> Since Alice and Bob do not have the same clock, Bob may legitimately
> send a timestamp that is in Alice's past or future. Every time Alice
> receives a timestamp from Bob, she compares it to her current time.
>
> - If Alice receives a timestamp that is in her future, instead of
> closing the channel, she may wait it out before she accepts to
> resume operations.
>
> - If Alice receives a timestamp that is too far in her past, she
> should disconnect. Indeed, Bob may be sending an old state and
> replaying old timestamps, which is not punishable. In that case,
> Alice should not automatically force close the channel, because she
> can only do that if she has not lost her state; if force-closing
> was automatic, not force-closing would reveal to Bob that she
> has lost her state.
>
> A delay needs to be tolerated by Alice, because Bob does not have the
> same clock; that delay should be chosen so that it is always smaller
> than the interval between two sessions.
>
>
> Saving Bandwidth
> ----------------
>
> Alice's channel state does not need to be sent with every commitment,
> if it is made of information that is known by both parties. In that
> case, it is sufficient for Alice to send her signature of the current
> state. Both Alice and Bob must be able to serialize the state, so that
> Alice can verify her own signature against a serialization of the
> state created by Bob. The state only needs to be sent by Bob once, in
> channel_reestablish.
>
> For this to work, the channel state cannot include information that is
> private to Alice. If the private keys used by Alice in the channel are
> derived deterministically from her wallet seed, they do not need to be
> part of the state. Alternatively, private keys may be included in an
> encrypted blob that is included in the state. Since that encrypted
> blob is constant, it only needs to be sent once by Alice, during the
> channel opening negotiation. Bob will save it and add it to the state
> sent in channel_reestablish.
>
> In addition, the state must not include any payment_hash preimage
> known by Alice; thus, Alice will have to fail incoming payments for
> those preimages, if she has lost her state.
>
> The channel state should include the compact storage of per-commitment
> secrets sent by Bob.
>
>
> Concluding remarks
> ------------------
>
> - Obviously, this proposal assumes that Alice remembers with whom she
> has an open channel.
>
> - Alice may restore her wallet from seed on a new device, while the
> initial wallet is still active. In that case, Alice must stop using
> the channels on her old device. Thus, Alice should disconnect if
> she has not lost her state and receives a state with a ctn that is
> in her future. This ensures that only one device uses the channels.
>
> - Without waiting for OP_CHECKSIGFROMSTACK to be available in
> Bitcoin, it would be possible for Bob to lockup funds on another
> blockchain such as Liquid. It is also possible to create fraud
> proofs that are not used in a redeem script, but that are tied to
> Bob's public identity and reputation. In that case, Bob should sign
> with his node pubkey, and fraud proofs will need to include a short
> channel id.
> _______________________________________________
> 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/20230816/558b9a6e/attachment-0001.html>

2023-08-21 09:48:48

- reply

📅 Original date posted:2023-08-17
🗒️ Summary of this message: The sender is disappointed that the recipient is not interested in fraud proofs for a mobile wallet. They discuss the dangers and complexities involved in implementing this feature.
📝 Original message:
Hi Thomas,
> That's a pity. I would have expected you to be interested, given that
> Phoenix could benefit from that feature.
I don't think this is an attack wallet providers can reasonably attempt.
The mobile wallet can check at every connection that the provider isn't
trying to cheat, and the provider doesn't have any way of knowing when
the mobile wallet has lost data: it would thus be a very risky move to
try to cheat, because it is very unlikely to succeed and will result in
reputation loss for the provider.
So for this specific backup use case, I think it would simply be adding
complexity to solve an issue that doesn't matter in practice.
> How are the fraud proofs I described more dangerous than revoked states?
> There is no "toxic data" in here.
I didn't say they were more dangerous than revoked states?
What I meant is that signing those "commitments" by the wallet provider
is dangerous for their reputation if that service is only best-effort,
because there are race conditions in the lightning protocol for which
the wallet provider may not have the mobile wallet's latest state (it
is not entirely trivial to keep track of that state).
> Perhaps that PR could benefit from my idea of sending backup data as new
> fields of existing messages? I see that update_channel_backup needs to be
> sent *before* the corresponding change of state. I think using the
existing
> messages would be more elegant, because it makes things atomic.
That was the main thing discussed in that PR. See [1] for the end of
that discussion (the earlier comments contain a lot of details on that
design choice). Sending data in existing messages has a length issue,
because `commitment_signed` for example may already fill up the message
which doesn't leave any room for an additional backup.
Cheers,
Bastien
[1] https://github.com/lightning/bolts/pull/881#issuecomment-1132698926
Le jeu. 17 août 2023 à 12:52, Thomas Voegtlin <thomasv at electrum.org> a
écrit :
>
> Hello Bastien
>
> > I don't think those fraud proofs are necessary at all.
>
> That's a pity. I would have expected you to be interested, given that
> Phoenix could benefit from that feature.
>
> Anyway, since my proposal requires new opcodes, I think of it more as
> a theoretical discussion, rather than a concrete proposal.
>
> > They're also
> > dangerous, because they impose a hard penalty on LSPs for something
> > that should be best effort (and could get desynchronized by connection
> > issues, especially with flaky mobile connections).
> >
>
> How are the fraud proofs I described more dangerous than revoked states?
> There is no "toxic data" in here.
>
> The server must not sign (ctn1, t1), (ctn2, t2) with ctn1>ctn2 and t1<t2.
> That is the only constraint, and it does not depend on flaky connections.
>
> All the server needs to do is remember the value of the highest timestamp
> signed so far. And, if they need to subtract leap seconds to their clock,
> wait a little bit before resuming the channel. That does not sound too
hard...
>
>
> > I'm surprised that you don't mention the BOLT PR we created for those
> > backups in [1], I believe that is sufficient. It should probably be
> > moved to a blip instead of a BOLT once we've implemented this version
> > (the approach we use in Phoenix currently is slightly different), but
> > apart from that it contains all the mechanisms necessary to achieve
> > this today.
> >
>
> Sorry, I had seen that PR a few years ago, but in the meantime I had
> forgotten about it. I just had a new look at it now.
>
> Perhaps that PR could benefit from my idea of sending backup data as new
> fields of existing messages? I see that update_channel_backup needs to be
> sent *before* the corresponding change of state. I think using the
existing
> messages would be more elegant, because it makes things atomic.
>
> Note that in practice, the client would only need to send his signature
> of the backup, and not the backup itself, which should be reconstructed
> by the server on each new state (see section 'saving bandwidth').
>
> cheers
>
> Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230817/09860a94/attachment.html>

2023-08-21 09:48:48

- reply

📅 Original date posted:2023-08-17
🗒️ Summary of this message: A hard penalty may be appropriate for a paid service, but designing payment for it is not easy and users may not be willing to pay. Phoenix should inform users if something goes wrong.
📝 Original message:
Hi Peter,
> Note that a hard penalty might be more appropriate for a paid service,
where
there's a clear expectation that the service works.
Agreed, and in that case we'd have to design payment for this service,
which isn't completely trivial and I'm not sure users are ready to pay
for it (the free version that mostly works is likely a better fit for
the majority of users).
> Does Phoenix tell the user this has happened? Phoenix being a centralized
entity, a useful outcome would be people finding out something is wrong and
saying so on, eg, social media.
We made sure that the code clearly distinguishes that case: we currently
handle it by simply ignoring the stale server backup, but it should be
easy to surface this to the user (which would also help us figure out
some edge cases where disconnections lead to a desynchronization between
the wallet and the wallet provider). The non-trivial part is to design
the proof that the user could share publicly, without revealing its
private data or leaking its backup encryption keys.
Thanks,
Bastien
Le mer. 16 août 2023 à 15:16, Peter Todd <pete at petertodd.org> a écrit :
> On Wed, Aug 16, 2023 at 09:56:21AM +0200, Bastien TEINTURIER wrote:
> > Hi Thomas,
> >
> > I don't think those fraud proofs are necessary at all. They're also
> > dangerous, because they impose a hard penalty on LSPs for something
> > that should be best effort (and could get desynchronized by connection
> > issues, especially with flaky mobile connections).
>
> Note that a hard pentalty might be more appropriate for a paid service,
> where
> there's a clear expectation that the service works.
>
> Also I'll point out to Thomas, that he's actually come up with a generic
> "latest state backup" oracle scheme that might be useful for applications
> outside of Lightning. It might be wortwhile to forward it to bitcoin-dev,
> pointing that out, so it sees a wider audience. I can't recall anyone else
> coming up with that precise mechanism before.
>
> > I agree with Peter Todd that since the mobile wallet can check the state
> > of the returned backup at every connection request, this makes it highly
> > unlikely that the LSP can cheat: that's the approach we've taken for
> > Phoenix.
>
> Does Phoenix tell the user this has happened? Phoenix being a centralized
> entity, a useful outcome would be people finding out something is wrong and
> saying so on, eg, social media.
>
> Similarly, the most likely reason why that would be triggered is Phoenix
> making
> a mistake, not malice. Having clients loudly shutdown probably protects
> Phoenix
> overall from their own mistakes in that scenario, by quickly getting
> people to
> stop using Phoenix wallet temporarily until the situation is fixed. Bad for
> reputation in the short term. But IMO better in the long term.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230817/ac792817/attachment.html>

2023-07-27 00:22:35

- reply

📅 Original date posted:2023-07-26
🗒️ Summary of this message: Blinded paths in the Lightning Network can potentially lead to a loss of privacy and decentralization. They could enforce that payments only go through "compliant" nodes, bypassing smaller routing nodes. This could also compromise sender-side privacy.
📝 Original message:
Hey Ben,
I'm not sure why it would be dramatically different from today. If I
understand your scenario correctly, the recipient would only provide
blinded paths that go through "regulated" nodes so that they can
witness the payment. Since the recipient agrees on doing that, the
recipient could simply share data with those "regulated" nodes without
forcing payments to go through them? And they can do that today without
blinded paths?
Even if the payments go through such "regulated" nodes, what preserves
the sender's privacy are the hops before the introduction point, that
they can choose freely. This is exactly the same model as freely chosing
the hops to the recipient directly (when not using blinded paths). Apart
from the loss of potential payment routes for the recipient, it doesn't
look like the sender's privacy is very different?
Cheers,
Bastien
Le mer. 26 juil. 2023 à 16:56, Ben Carman <benthecarman at live.com> a écrit :
> Hi list,
>
> This is an idea I had the other week about a potential downside of blinded
> paths that people should be aware of.
>
> Blinded paths work by encrypting specific paths to reach the destination
> node, and each of these paths have an introduction point.
> This has big privacy benefits for the receiving node as they can hide
> among an anon set of anyone within X hops of the introduction node (X being
> the size of the blinded path).
>
> However, this can have a potential downside for privacy and
> decentralization on the network as a whole.
> With blinded paths since you do not know the destination node the only way
> to pay them is through one of the given paths.
> Because of this, they can be used to enforce that "compliant" nodes are
> the only ways to reach a given destination.
>
> In my experience today you can get away with telling your compliance
> officer you will only open channels with people you trust, and we see this
> with some regulated businesses today (Cash App & River only open to
> sepcific peers).
> However with blinded paths we could have a world where not only do they
> only open channels to specific peers but they enforce that when paying
> them, the payment must go through at least N "compliant" nodes first.
> This would make it so the pleb routing nodes of today would be completely
> circumvented and users would be forced to route only through large
> regulated hubs.
> The receiver would be hurting their payment reliability as they are
> removing potential paths they can receive from, but this is already the
> case for all blinded paths.
>
> This could hurt sender side privacy as well, since payment reliability
> rapidly falls off the more hops that are needed it is likely the sender
> would need to be very closely connected the introduction node or any of the
> nodes along the blinded path, and if all these compliant nodes are data
> sharing they'll be able to track a payment as it happens through the
> network just through basic timing analysis.
>
> My concern is lightning "chain analysis" companies could strong arm
> businesses into doing things like this under the guise of making sure you
> don't receieve OFAC coins. However, I am not sure if this is a "fixable"
> problem and just a trade off we'll have to make to get receiver privacy in
> lightning but wanted to put out there for people's opinions/awareness.
>
> Best,
>
> benthecarman
>
> _______________________________________________
> 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/20230726/cc12ed84/attachment-0001.html>

2023-07-03 12:53:35

- reply

📅 Original date posted:2023-07-03
🗒️ Summary of this message: The sender is confused about the use of a different mechanism in the schnorr multi-hop locks proposal. They suggest using trampoline nodes without impacting the protocol.
📝 Original message:
Hey Zman,
I'm a bit confused because you use a different mechanism than the one
specified in the latest schnorr multi-hop locks proposal that I know of,
which can be found in [1].
If we use the construction from [1], it seems straightforward that using
trampoline doesn't have any impact on the protocol: the sender follows
the exact steps of that protocol and sends the left/right locks in the
trampoline onion.
Then intermediate trampoline nodes can draw their blinding factors
randomly, using the exact same steps, but using the right lock they
received as the secret they're trying to learn (from their point of
view, they're simply doing a normal session of this protocol with a
different secret - and don't learn anything about the "real" secret).
If this doesn't seem straightforward, I can create the same kind of
diagram as the one in [1] but for a trampoline scenario to show that
the maths checks out, let me know if that would be useful.
Cheers,
Bastien
[1]
https://github.com/BlockstreamResearch/scriptless-scripts/blob/master/md/multi-hop-locks.md
Le jeu. 29 juin 2023 à 16:49, ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> a écrit :
> Good morning list,
>
> Here is a simple mathematical demonstration of a particular way to compute
> blinding factors such that:
>
> * All non-Trampoline intermediate nodes only need to know one blinding
> factor.
> * The receiver only needs to know one blinding factor.
> * Trampoline nodes can provide the nodes on the sub-routes they decide the
> blinding factors without the non-Trampoline intermediate nodes knowing they
> are on a trampoline and not a "direct" source-to-dest route.
>
> First, let us start with:
>
> * The ultimate receiver has a secret `r`.
> * The ultimate receiver gives the ultimate sender the point `R`, such that
> `R = r * G`.
>
> Now, suppose the ultimate sender is directly channeled with the ultimate
> receiver.
>
> The ultimate sender chooses a fresh random scalar `e`, the "error"
> blinding factor that reaches the ultimate receiver.
> It then constructs an onion with `e` decryptable by the ultimate receiver.
> Together with that onion, the ultimate sender offers a PTLC with the point
> `e * G + R`.
>
> The ultimate receiver can claim that PTLC by revealing `e + r`, as it
> learns `e` from the onion, and knows `r` and the contract is to give `r` in
> exchange for payment.
>
> That is the simplest case.
>
> --
>
> Now let us suppose that the ultimate receiver needs to got through an
> intermediate node, Carol.
> The ultimate sender still needs to choose a final error scalar, `e`, by
> random.
> However, it also needs to generate two scalars, `c` and `d`, such that `c
> + d = e`.
> This can be done by selecting a random `d` and computing `c = e - d` (by
> algebra).
> By algebra, `d = e - c`.
> The ultimate sender then encrypts the onion:
>
> * `e` encrypted to the ultimate receiver.
> * The above ciphertext, and `d` encrypted to intermediate node Carol.
>
> The ultimate sender then sends the PTLC with point `c * G + R` to Carol.
>
> Each intermediate non-Trampoline node --- such as Carol --- then gets the
> input point, adds its per-hop blinding factor times `G`, and uses the
> result as the output point to the next hop.
>
> So Carol receives `c * G + R`.
> Carol then adds `d * G` (which is the `d` error it got from the onion).
> Carol then sends a PTLC (with one less onion hop layer as well) with the
> point `c * G + R + d * G`.
>
> Note that `e = c + d`, so we can re-arrange the PTLC sent by Carol to the
> ultimate sender as `(c + d) * G + R`.
> This is equal to `e * G + R`, the exact same as in the case where the
> ultimate sender is directly channeled with ultimate receiver.
>
> The ultimate receiver therefore cannot know whether it received from
> Carol, or from a further node, as in both the direct case and the indirect
> case, the ultimate receiver sees `e * G + R`.
>
> When the ultimate receiver releases `e + r`, Carol can compute `c + r` by
> taking `e + r - d`, and since `c = e - d`, `e + r - d = e - d + r = c + r`.
> It can then claim the incoming `c * G + R` with scalar `c + r`.
> Carol does not know `c`, it only knows `d`, and thus it cannot compute `r`.
>
> --
>
> Now let us instead suppose that Carol is a Trampoline node, and that the
> ultimate sender does not provide a detailed route from Carol to the next
> Trampoline hop.
> In this next example, the ultimate receiver is actually the final
> Trampoline hop after Carol, but Carol does not know this fact (and should
> not be able to learn this fact).
>
> The ultimate sender learns `R`, then selects a random `e`.
> It then selects `c` and `d` such that `c + d = e`, using the same
> technique as above (i.e. random-pick `d` and compute `c = e - d`).
>
> Now the ultimate sender computes a Trampoline-level onion, with the
> following:
>
> * `e` encrypted to the ultimate receiver.
> * the above ciphertext, `d`, and the next Trampoline hop (i.e. the node ID
> of ultimate receiver), encrypted to Carol.
>
> The ultimate sender then sends a PTLC with the above onion, with point `c
> * G + R`, to Carol.
>
> Carol then decrypts the onion, and gets `d`.
> It then has to search for a route from Carol to the ultimate receiver (the
> next Trampoline hop).
>
> Let us suppose that Carol finds a route Carol -> Alice -> ultimate
> receiver.
> Carol now needs to make `c * G + d * G + R` reach the ultimate receiver.
> It can do that by selecting two scalars, `a` and `b`, such that `a + b =
> d`.
> It knows `d`, and can random-pick` b` and then compute `a = d - b`.
>
> Carol then creates the onion:
>
> * It copies the ciphertext from ultimate sender: `e` encrypted to the
> ultimate receiver.
> * The above ciphertext, and `b`, encrypted to Alice.
>
> Carol then sends the PTLC with point `c * G + R + a * G` to Alice.
>
> Alice decrypts the onion and learns `b`.
> Forwarding, it gives the PTLC with point `c * G + R + a * G + b * G` to
> the next hop, the ultimate receiver.
>
> Now, `a + b = d` therefore `a * G + b * G = d * G`.
> And `c + d = e`, therefore `c * G + d * G = e * G`.
> Thus:
>
> c * G + R + a * G + b * G
> = c * G + a * G + b * G + R; commutative property
> = c * G + (a + b) * G + R; associative property
> = c * G + d * G + R; d = a + b by construction
> = (c + d) * G + R; associative property
> = e * G + R; e = c + d by construction
>
> Thus, again, the ultimate receiver gets the same `e * G + R` and cannot
> differentiate whether it was reached via a Trampoline, via a non-Trampoline
> intermediate, or directly.
>
> Similarly, on claiming, every intermediate (Trampoline and non-Trampoline)
> node has enough data to claim its incoming PTLC.
> And only the ultimate sender knows `c`, which allows it to recover the `r`.
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> 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/20230703/35ae1f9d/attachment.html>

2023-06-20 23:25:30

- reply

📅 Original date posted:2023-06-20
🗒️ Summary of this message: Bastien argues for a prepayment solution based on Bolt 12 for Lightning service providers, but Thomas questions the need to rush and suggests a feature bit for optional prepayment.
📝 Original message:
Hi Thomas,
> I believe pre-payment of the mining fee can be combined with 0-conf;
> I am not sure why you picture them as opposed? Even with BOLT-12, I
> don't see 0-conf going away.
Sorry if that was unclear, that's not at all what I meant. What I meant
is that if we *stopped* using 0-conf for some reason, the solution I
described wouldn't work anymore and we would have to use a prepayment.
> Would you care to describe whether bundled payments already would
> work with the current specification, or whether they would require
> changes to BOLT-12?
That would require adding a TLV field to Bolt 12 invoices, or a TLV
field to onion messages. The design space for a prepayment solution
based on Bolt 12 is larger than with Bolt 11: I believe we can come
up with a more satisfying protocol.
> I believe that it will take years *after it is merged*, until BOLT-12
> actually becomes the dominant payment method on Lightning. OTOH, if
> this feature was adopted in BOLT-11, I think it could be deployed much
> faster.
I'm not sure why you think it would be faster using Bolt 11? It does
require all sender and receiver software to be updated, and implementers
are currently focused on Bolt 12 so I find it less likely that they
will prioritize work on extensions to Bolt 11 (but I could be wrong).
> The goal of my proposal is to level the field of competition between
> Lightning service providers
I agree that it would be great to have a more satisfying solution than
what currently exists, but this is not a reason to rush it. I think
it's worth trying to build this on top of Bolt 12, where we can
probably do something cleaner since invoices are delivered on-the-fly
and short-lived.
Thanks,
Bastien
Le mar. 20 juin 2023 à 10:47, Thomas Voegtlin <thomasv at electrum.org> a
écrit :
> Hello Dave,
>
> That is an interesting idea; it would indeed save space for the prepayment
> hash.
> I think the invoice would still need a feature bit, so that the receiver
> can
> decide to make prepayment optional or required.
>
> Note that for the feature to be optional, we need to subtract the
> prepayment
> amount from the main payment amount. Thus, in your example, Alice would
> expect
> to receive either:
> (1 BTC, invoice payment_hash)
> or:
> (1 BTC - minus 10k sats, invoice payment_hash) + (10k sats,
> prepayment_hash via keysend)
>
> cheers
>
> Thomas
>
>
>
>
> On 19.06.23 22:29, David A. Harding wrote:
> > On 2023-06-12 22:10, Thomas Voegtlin wrote:
> >> The semantics of bundled payments is as follows:
> >> - 1. the BOLT-11 invoice contains two preimages and two amounts:
> >> prepayment and main payment.
> >> - 2. the receiver should wait until all the HTLCs of both payments
> >> have arrived, before they fulfill the HTLCs of the pre-payment. If the
> >> main payment does not arrive, they should fail the pre-payment with a
> >> MPP timeout.
> >> - 3. once the HTLCs of both payments have arrived, the receiver
> >> fulfills the HTLCs of the prepayment, and they broadcast their
> >> on-chain transaction. Note that the main payment can still fail if the
> >> sender never reveal the preimage of the main payment.
> >
> > Hi Thomas,
> >
> > Do you actually require a BOLT11 invoice to contain a payment hash for
> > the prepayment, or would it be acceptable for the prepayment to use a
> > keysend payment with the onion message payload for the receiver
> > indicating what payment hash to associate with the prepayment (e.g.,
> > Alice wants to receive 1 BTC to hash 0123...cdef with a prepayment of
> > 10k sats, so the 10k sats is sent via keysend with metadata indicating
> > the receiver shouldn't claim it until they receive the 1 BTC HTLC to
> > 0123...cdef).
> >
> > If so, I think then you'd only need BOLT11 invoices to be extended with
> > an extra_fee_via_keysend field. That would be significantly smaller and
> > it also allows encoding the extra_fee_via_keysend field in an existing
> > BOLT11 field like (d) description or the relatively new (m) metadata
> > field, which may allow immediate implementation until an updated version
> > of BOLT11 (or an alternative using offers) becomes widely deployed.
> >
> > Thanks,
> >
> > -Dave
>
> --
> Electrum Technologies GmbH / Paul-Lincke-Ufer 8d / 10999 Berlin / Germany
> Sitz, Registergericht: Berlin, Amtsgericht Charlottenburg, HRB 164636
> Geschäftsführer: Thomas Voegtlin
> _______________________________________________
> 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/20230620/9d8f0c4f/attachment-0001.html>

2023-06-19 17:42:39

- reply

📅 Original date posted:2023-06-15
🗒️ Summary of this message: The proposal to add a new feature to BOLT-11 requires senders to be aware of payment leading to channel creation on the receiver end. Extending Bolt 12 makes more sense than updating Bolt 11. There are three strategies to provide JIT liquidity, and the currently deployed strategies are 1) and 2). Solution 2) works fine as long as the mempool isn't empty, but pre-paying fees would make more sense if 0-conf is not used anymore. It is more reasonable to include this new feature in Bolt 12 rather than Bolt 11.
📝 Original message:
Hi Thomas,
First of all, I'd like to highlight something that may not be obvious
from your email, and is actually pretty important: your proposal
requires *senders* to be aware that the payment will lead to a channel
creation (or a splice) on the *receiver* end. In particular, it requires
all existing software used by senders to be updated. For this reason, I
think extending Bolt 12 (which requires new sender code anyway) makes
more sense than updating Bolt 11.
I see only three strategies to provide JIT liquidity (by opening a new
channel or making a splice, I'll only use the open channel case below
for simplicity):
1. Ask receiver for the preimage and a fee, then open a channel and
push the HTLC amount minus the fee
2. Open a channel, then forward the HTLC amount minus a fee
3. Pre-pay fee, then open a channel and forward the whole HTLC amount
on that channel
What is currently deployed on the network is 1) and 2), while you're
proposing 3). Both 1) and 2) have the advantages that the sender doesn't
need to be aware that JIT liquidity is happening, and doesn't need to do
anything special for that payment, which is the main reason those
strategies were chosen.
If all you're concerned about is trust and regulation, solution 2) works
fine as long as the mempool isn't empty: if the user doesn't release the
preimage after you've opened the channel, you should just blacklist that
channel, reject payments made to it, and double-spend it whenever you
have another on-chain transaction to make (and use 1 sat/byte for JIT
liquidity transactions). Even if the mempool is empty, if your LSP has
transactions to make at every block, it's likely that it will succeed
at double-spending the faulty channel, and thus won't lose anything.
But I agree that this only works when coupled with 0-conf. If we're not
using 0-conf anymore, pre-paying fees would make more sense. But we will
likely keep on using 0-conf at least until Bolt 12 is deployed, so it
seems more reasonable to include this new feature in Bolt 12 rather than
Bolt 11, since all implementations are actively working on this?
Cheers,
Bastien
Le jeu. 15 juin 2023 à 10:52, Thomas Voegtlin <thomasv at electrum.org> a
écrit :
> Hello Matt,
>
> I think it is not too late to add a new feature to BOLT-11. In any
> case, the belief that BOLT-11 is ossified should not be a reason to
> make interactive something that fundamentally does not require more
> interactivity than what BOLT-11 already offers. Technical decisions
> should be dictated by technical needs, and I am a minimalist when it
> comes to adding new messages to protocols.
>
> I believe that two major implementations have an incentive to support
> this proposal (although I cannot speak for them):
> - Lightning Labs could potentially offer their Loop service to
> non-LND users.
> - ACINQ would be able to open channels to Phoenix users without
> requesting the preimage first. This would put them on the safe side
> of the upcoming MICA regulation; I cannot emphasize enough how
> important that is.
>
> In addition, you could certainly decide to support that feature in
> LDK, and I can speak for Electrum :-)
>
> It is the first time I suggest a change to the Lightning protocol, and
> what I am proposing is really a tiny change. All we need is a new
> invoice feature, that describes the prepayment of a fee using a
> different preimage. This feature does not need to be set on all
> invoices, and it could be made optional during a transition period.
>
> Here is how that feature could possibly made optional:
> - a new feature bit is defined, BUNDLE_PREPAYMENT
> - two extra fields are defined: prepayment_amount, prepayment_hash
> - if the sender does not support BUNDLE_PREPAYMENT and the feature is
> optional, it ignores the new fields
> - if the sender support BUNDLE_PREPAYMENT:
> - sender sends (amount - prepayment_amount) with payment_hash
> - sender sends prepayment_amount with prepayment_hash
>
> The decision to make this feature required or optional remains with
> the service provider. I can see how submarine swap providers who are
> already exposed to the mining fee griefing attack could decide to make
> it optional for a transition period.
>
> cheers,
> Thomas
>
>
> Regarding your question (a) about the distinction between splice-out
> and submarine swaps: Submarine swaps make it possible to add receiving
> capacity to a channel.
>
>
>
>
> On 14.06.23 19:28, Matt Corallo wrote:
> > I think the ship has probably sailed on getting any kind of new
> interoperable change in to BOLT-11.
> >
> > We already can't get amount-less BOLT-11 invoices broadly supported,
> rolling out yet another new incompatible version of BOLT-11 and expecting
> the entire ecosystem to support it doesn't seem all that likely.
> >
> > If we're working towards specifying some "standard" way of doing swaps,
> (a) I'd be curious to understand why the need isn't obviated by splice-out,
> and (b) why it shouldn't be built on OMs so you can do it more privately.
> >
> > Matt
> >
> > On 6/13/23 1:10 AM, Thomas Voegtlin wrote:
> >> Good morning list,
> >>
> >> I would like to propose an extension to BOLT-11, where an invoice can
> contain two bundled payments, with distinct preimages and amounts.
> >>
> >> The use case is for services that require the prepayment of a mining
> fee in order for a non-custodian exchange to take place:
> >> - Submarine swaps
> >> - JIT channels
> >>
> >> In both cases, the service provider receives a HTLC for which they do
> not have the preimage, have to send funds on-chain (to the channel or
> submarine swap funding address), and wait for the client to reveal the
> preimage when they claim the payment. Because there is no guarantee that
> the client will actually claim the payment, the service providers need to
> ask prepayment of mining fees.
> >>
> >> In the case of submarine swaps, services that use dedicated client
> software, such as Loop by Lightning Labs, can ask for a prepayment, because
> their software can handle it (this is called "no show penalty" on the Loop
> website). However, competitors who do require a dedicated wallet, not such
> as the Boltz exchange, cannot do that. Their website shows an invoice to
> the user, whose wallet that is agnostic about the swap, and it would be
> unpractical for them to show two invoices to be paid simultaneously. This
> creates a situation where Boltz is vulnerable to DoS attacks, where the
> attacker forces them to pay on-chain fees.
> >>
> >> In the case of JIT channels, providers who want to protect themselves
> against this mining fee attack need to ask the preimage of the main payment
> before they open the channel. I believe this is what Phoenix does (although
> their pay-to-open service is not open-source, so I cannot really check).
> The issue is that a service that asks for the preimage first becomes
> custodian. From a legal perspective, it does not matter whether they open
> the channel immediately after receiving the preimage, the ordering of
> events makes their service custodian. In Europe, such a service will fall
> within the European MICA regulation. Competitors who refuse to offer
> custodian services, such as Electrum, are excluded from that game.
> >>
> >> In order to solve that, it would be beneficial to bundle the prepayment
> and the main payment in the same BOLT-11 invoice.
> >>
> >> The semantics of bundled payments is as follows:
> >> - 1. the BOLT-11 invoice contains two preimages and two amounts:
> prepayment and main payment.
> >> - 2. the receiver should wait until all the HTLCs of both payments
> have arrived, before they fulfill the HTLCs of the pre-payment. If the main
> payment does not arrive, they should fail the pre-payment with a MPP
> timeout.
> >> - 3. once the HTLCs of both payments have arrived, the receiver
> fulfills the HTLCs of the prepayment, and they broadcast their on-chain
> transaction. Note that the main payment can still fail if the sender never
> reveal the preimage of the main payment.
> >>
> >> Of course, nothing in my proposal prevents the service provider from
> stealing the pre-payment, but that is already the case today.
> >>
> >> I believe this proposal would level the field in terms of competition
> between lightning service providers. Currently, you need to use a dedicated
> client in order to use Loop, and competitors who do not have an established
> user base running a dedicated client are exposed to the mining fee attack.
> I also believe that ACINQ would benefit from this, because it would make it
> possible for them to make their pay-to-open service fully non-custodian. My
> understanding is that in its current form, the 'pay-to-open' service used
> by Phoenix will fall into the scope of the European MICA regulation, which
> they should consider as a serious issue.
> >>
> >> Finally, I believe that such a change should be implemented in BOLT-11,
> and not using BOLT-12 or onion messages. Indeed, my proposal does not
> require the exchange of new messages. Some of the initial feedback I
> received was that this is a use case for BOLT-12 or OM, but I think that
> this is making things unnecessarily complicated. We should not add new
> messages when things can be done in a non-interactive way.
> >>
> >> Cheers,
> >> ThomasV
> >> _______________________________________________
> >> Lightning-dev mailing list
> >> Lightning-dev at lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
> --
> Electrum Technologies GmbH / Paul-Lincke-Ufer 8d / 10999 Berlin / Germany
> Sitz, Registergericht: Berlin, Amtsgericht Charlottenburg, HRB 164636
> Geschäftsführer: Thomas Voegtlin
> _______________________________________________
> 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/20230615/121ed57a/attachment-0001.html>

2023-06-19 17:42:20

- reply

📅 Original date posted:2023-05-10
🗒️ Summary of this message: A proposal to lock UTXOs after tx_completes have been exchanged to prevent double-spending in 0-conf channels, but it may not work for splicing.
📝 Original message:
Hey Matt, Zman,
> I propose that we DO lock our UTXOs after tx_completes have been
> exchanged IF we are the only contributor. We don't have to worry
> about liquidity griefing in this case, since the peer has no
> tx_signatures to withhold from us.
While this is true for dual funding, this isn't true for splicing, where
we need the remote `tx_signatures` to spend the channel's current
funding output. But it's not an issue, the untrusted peer will send
their `tx_signatures` first (since they're not contributing to the
transaction) and we can `TryLock()` once we receive that.
> Your proposal basically means "do not dual-fund 0-conf".
> You might as well use the much simpler openv1 flow in that case, just
> because it is simpler.
I also thought that this was the easy way out, but I was hoping we could
do better. The issue with that option (using v1 with locks for 0-conf,
and v2 with soft locks for non 0-conf) is that we need to implement that
soft lock mechanism (we cannot simply rely on bitcoin core, which only
supports hard locks) or use separate bitcoin core wallets for 0-conf and
non 0-conf.
But there is probably no free lunch here! And anyway, this post was also
made to raise awareness for implementers to make sure they don't end up
accidentally double-spending 0-conf channels when implementing dual
funding.
Thanks,
Bastien
Le mer. 10 mai 2023 à 02:07, ZmnSCPxj <ZmnSCPxj at protonmail.com> a écrit :
> Good morning Matt, and t-bast,
>
> Your proposal basically means "do not dual-fund 0-conf".
> You might as well use the much simpler openv1 flow in that case, just
> because it is simpler.
>
> Regards,
> ZmnSCPxj
>
>
>
>
> Sent with Proton Mail secure email.
>
> ------- Original Message -------
> On Tuesday, May 9th, 2023 at 5:38 PM, Matt Morehouse <
> mattmorehouse at gmail.com> wrote:
>
>
> > Hi Bastien,
> >
> > In general, 0-conf is only safe when WE are the only contributor to
> > the channel, otherwise the peer could double spend us.
> >
> > The problem you seem to be describing is that we might double-spend
> > ourselves if we don't lock our 0-conf UTXOs at some point. I propose
> > that we DO lock our UTXOs after tx_completes have been exchanged IF we
> > are the only contributor. We don't have to worry about liquidity
> > griefing in this case, since the peer has no tx_signatures to withhold
> > from us. Of course, the opportunistic upgrade of a regular channel to
> > 0-conf won't work -- we need a way to differentiate 0-conf channels
> > prior to UTXO selection, so that we don't reuse soft-locked UTXOs.
> >
> > All together, what I propose is:
> >
> > 1) If the channel type has option_zeroconf, select UTXOs that are not
> > soft locked.
> > 2) If the peer adds any inputs to the funding transaction, abort
> > (0-conf is unsafe for us in this case).
> > 3) After tx_complete exchange, TryLock() our UTXO inputs and abort if
> > already locked.
> > 4) Broadcast funding transaction and begin using the 0-conf channel.
> >
> > I think this at least enables the common use case for 0-conf: LSPs can
> > use their own funds to open 0-conf channels for clients.
> >
> > - Matt
> >
> >
> >
> >
> > On Sat, May 6, 2023 at 3:16 AM Bastien TEINTURIER bastien at acinq.fr
> wrote:
> >
> > > Good morning list,
> > >
> > > One of the challenges created by the introduction of dual funded
> > > transactions [1] in lightning is how to protect against liquidity
> > > griefing attacks from malicious peers [2].
> > >
> > > Let's start by reviewing this liquidity griefing issue. The dual
> funding
> > > protocol starts by exchanging data about the utxos each peer adds to
> the
> > > shared transaction, then exchange signatures and broadcast the
> resulting
> > > transaction. If peers lock their utxos as soon as they've decided to
> add
> > > them to the shared transaction, the remote node may go silent. If that
> > > happens, the honest node has some liquidity that is locked and
> unusable.
> > >
> > > This cannot easily be fixed by simply unlocking utxos after detecting
> > > that the remote node is fishy, because the remote node would still have
> > > succeeded at locking your liquidity for a (small) duration, and could
> > > start other instances of that attack with different node_ids.
> > >
> > > An elegant solution to this issue is to never lock utxos used in dual
> > > funded transactions. If a remote node goes silent in the middle of an
> > > instance of the protocol, your utxos will automatically be re-used in
> > > another instance of the protocol. The only drawback with that approach
> > > is that when you have multiple concurrent instances of dual funding
> with
> > > honest peers, some of them may fail because they are double-spent by
> one
> > > of the concurrent instances. This is acceptable, since the protocol
> > > should complete fairly quickly when peers are honest, and at worst, it
> > > can simply be restarted when failure is detected.
> > >
> > > But that solution falls short when using 0-conf, because accidentally
> > > double-spending a 0-conf channel (because of concurrent instances) can
> > > result in loss of funds for one of the peers (if payments were made on
> > > that channel before detecting the double-spend). It seems like using
> > > 0-conf forces us to lock utxos to avoid this issue, which means that
> > > nodes offering 0-conf services expose themselves to liquidity griefing.
> > >
> > > Another related issue is that nodes that want to offer 0-conf channels
> > > must ensure that the utxos they use for 0-conf are isolated from the
> > > utxos they use for non 0-conf, otherwise it is not possible to properly
> > > lock utxos, because of the following race scenario:
> > >
> > > - utxoA is selected for a non 0-conf funding attempt and not locked
> > > (to protect against liquidity griefing)
> > > - utxoA is also selected for a 0-conf funding attempt (because it is
> > > found unlocked in the wallet) and then locked
> > > - the funding transaction for the 0-conf channel is successfully
> > > published first and that channel is instantly used for payments
> > > - the funding transaction for the non 0-conf channel is then published
> > > and confirms, accidentally double-spending the 0-conf channel
> > >
> > > This can be fixed by using a "soft lock" when selecting utxos for a non
> > > 0-conf funding attempt. 0-conf funding attempts must ignore soft locked
> > > utxos while non 0-conf funding attempts can (should) reuse soft locked
> > > utxos.
> > >
> > > In eclair, we are currently doing "opportunistic" 0-conf:
> > >
> > > - if we receive `channel_ready` immediately (which means that our peer
> > > trusts us to use 0-conf)
> > > - and we're the only contributor to the funding transaction (our peer
> > > doesn't have any input that they could use to double-spend)
> > > - and the transaction hasn't been RBF-ed yet
> > >
> > > Then we immediately send `channel_ready` as well and start using that
> > > channel (because we know we won't double spend ourselves). This is nice
> > > because it lets us use 0-conf in a way where only one side of the
> > > channel needs to trust the other side (instead of both sides trusting
> > > each other).
> > >
> > > Unfortunately, we cannot do that anymore when mixing 0-conf and non
> > > 0-conf funding attempts, because the utxos may be soft locked,
> > > preventing us from "upgrading" to 0-conf.
> > >
> > > You have successfully reached the end of this quite technical post,
> > > congrats! My goal with this post is to gather ideas on how we could
> > > improve that situation and offer good enough protections against
> > > liquidity griefing for nodes offering 0-conf services. Please share
> > > your ideas! And yes, I know, 0-conf is a massive implementation pain
> > > point that we would all like to remove from our codebases, but hey,
> > > users like it ¯\(ツ)/¯
> > >
> > > Cheers,
> > > Bastien
> > >
> > > [1] https://github.com/lightning/bolts/pull/851
> > > [2] https://github.com/lightning/bolts/pull/851#discussion_r997537630
> > > _______________________________________________
> > > 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/20230510/1e7a1a83/attachment.html>

2023-06-19 17:42:17

- reply

📅 Original date posted:2023-05-05
🗒️ Summary of this message: The introduction of dual funded transactions in lightning has created challenges in protecting against liquidity griefing attacks from malicious peers. An elegant solution is to never lock utxos used in dual funded transactions, but this falls short when using 0-conf. Nodes offering 0-conf services expose themselves to liquidity griefing. Another related issue is that nodes that want to offer 0-conf channels must ensure that the utxos they use for 0-conf are isolated from the utxos they use for non 0-conf.
📝 Original message:
Good morning list,
One of the challenges created by the introduction of dual funded
transactions [1] in lightning is how to protect against liquidity
griefing attacks from malicious peers [2].
Let's start by reviewing this liquidity griefing issue. The dual funding
protocol starts by exchanging data about the utxos each peer adds to the
shared transaction, then exchange signatures and broadcast the resulting
transaction. If peers lock their utxos as soon as they've decided to add
them to the shared transaction, the remote node may go silent. If that
happens, the honest node has some liquidity that is locked and unusable.
This cannot easily be fixed by simply unlocking utxos *after* detecting
that the remote node is fishy, because the remote node would still have
succeeded at locking your liquidity for a (small) duration, and could
start other instances of that attack with different node_ids.
An elegant solution to this issue is to never lock utxos used in dual
funded transactions. If a remote node goes silent in the middle of an
instance of the protocol, your utxos will automatically be re-used in
another instance of the protocol. The only drawback with that approach
is that when you have multiple concurrent instances of dual funding with
honest peers, some of them may fail because they are double-spent by one
of the concurrent instances. This is acceptable, since the protocol
should complete fairly quickly when peers are honest, and at worst, it
can simply be restarted when failure is detected.
But that solution falls short when using 0-conf, because accidentally
double-spending a 0-conf channel (because of concurrent instances) can
result in loss of funds for one of the peers (if payments were made on
that channel before detecting the double-spend). It seems like using
0-conf forces us to lock utxos to avoid this issue, which means that
nodes offering 0-conf services expose themselves to liquidity griefing.
Another related issue is that nodes that want to offer 0-conf channels
must ensure that the utxos they use for 0-conf are isolated from the
utxos they use for non 0-conf, otherwise it is not possible to properly
lock utxos, because of the following race scenario:
- utxoA is selected for a non 0-conf funding attempt and not locked
(to protect against liquidity griefing)
- utxoA is also selected for a 0-conf funding attempt (because it is
found unlocked in the wallet) and then locked
- the funding transaction for the 0-conf channel is successfully
published first and that channel is instantly used for payments
- the funding transaction for the non 0-conf channel is then published
and confirms, accidentally double-spending the 0-conf channel
This can be fixed by using a "soft lock" when selecting utxos for a non
0-conf funding attempt. 0-conf funding attempts must ignore soft locked
utxos while non 0-conf funding attempts can (should) reuse soft locked
utxos.
In eclair, we are currently doing "opportunistic" 0-conf:
- if we receive `channel_ready` immediately (which means that our peer
trusts us to use 0-conf)
- and we're the only contributor to the funding transaction (our peer
doesn't have any input that they could use to double-spend)
- and the transaction hasn't been RBF-ed yet
Then we immediately send `channel_ready` as well and start using that
channel (because we know we won't double spend ourselves). This is nice
because it lets us use 0-conf in a way where only one side of the
channel needs to trust the other side (instead of both sides trusting
each other).
Unfortunately, we cannot do that anymore when mixing 0-conf and non
0-conf funding attempts, because the utxos may be soft locked,
preventing us from "upgrading" to 0-conf.
You have successfully reached the end of this quite technical post,
congrats! My goal with this post is to gather ideas on how we could
improve that situation and offer good enough protections against
liquidity griefing for nodes offering 0-conf services. Please share
your ideas! And yes, I know, 0-conf is a massive implementation pain
point that we would all like to remove from our codebases, but hey,
users like it ¯\_(ツ)_/¯
Cheers,
Bastien
[1] https://github.com/lightning/bolts/pull/851
[2] https://github.com/lightning/bolts/pull/851#discussion_r997537630
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230505/9638cc46/attachment-0001.html>

2023-06-09 13:13:28

- reply

📅 Original date posted:2023-06-07
🗒️ Summary of this message: The use of v3 transactions for channel funding and splicing could be a mid-term solution to mempool pinning issues. In the longer term, an anti-DoS token may be needed. Disabling inbound payments or using longer `cltv_expiry_delta` can also be implemented as a policy.
📝 Original message:
Hey Antoine,
Sure, I agree with you, the usual mempool pinning issues still apply
regardless of whether we use 0-conf or not. And we must solve them
all at some point!
I think a reasonable mid-term solution is to use v3 transactions for
channel funding and splicing, with the obvious caveat that it makes
them identifiable on-chain (unless in the longer term, everyone moves
to v3 transactions for everything, which doesn't seem crazy to me?).
In the longer term, we know that some kind of anti-DoS token will need
to be exchanged to avoid this whole class of issue, but as we've often
discussed this isn't an easy thing to design and analyze...
> it can still be valuable to disable inbound payments, or requires a
> longer `cltv_expiry_delta` than usual, in case of mempool fee spikes
> delaying the 0-conf chain confirmation.
Sure, that's a policy that nodes can decide to apply if they want to,
and it should be simple enough to implement (no protocol changes are
needed).
Thanks,
Bastien
Le mer. 7 juin 2023 à 02:41, Antoine Riard <antoine.riard at gmail.com> a
écrit :
> Hi Bastien,
>
> > This can be fixed by using a "soft lock" when selecting utxos for a non
> > 0-conf funding attempt. 0-conf funding attempts must ignore soft locked
> > utxos while non 0-conf funding attempts can (should) reuse soft locked
> > utxos.
>
> If my understanding of the "soft lock" strategy is correct - Only locking
> UTXO when it's a non 0-conf funding attempt - I think you're still exposed
> to liquidity griefing with dual-funding or splicing.
>
> The vector of griefing you're mentioning is the lack of signature release
> for a shared input by your counterparty. However, in the context of
> dual-funding where the counterparty can add any output with
> `tx_add_output`, the transaction can be pinned in the mempool in a very
> sneaky way e.g abuse of replacement rule 3.
>
> This latter pinning vector is advantageous to the malicious counterparty
> as I think you can batch your pinning against unrelated dual-funding, only
> linked in the mempool by a malicious pinning CPFP.
>
> It is left as an exercise to the reader to find other vectors of pinnings
> that can be played out in the dual-funding flow.
>
> In terms of (quick) solution to prevent liquidity griefing related to
> mempool vectors, the (honest) counterparty can enforce that any contributed
> outputs must be encumbered by a 1 CSV, unless being a 2-of-2 funding.
> Still, this mitigation can be limited as I think the initial commitment
> transaction must have anchor outputs on each-side, for each party to
> recover its contributed UTXOs in any case.
>
> > Then we immediately send `channel_ready` as well and start using that
> > channel (because we know we won't double spend ourselves). This is nice
> > because it lets us use 0-conf in a way where only one side of the
> > channel needs to trust the other side (instead of both sides trusting
> > each other).
>
> From the 0-conf initiator viewpoint (the one contributing the UTXO(s)), it
> can still be valuable to disable inbound payments, or requires a longer
> `cltv_expiry_delta` than usual, in case of mempool fee spikes delaying the
> 0-conf chain confirmation.
>
> Beyond, it sounds liquidity griefing provoked by a lack of signature
> release or mempool funny games will always be there ? Even for the second
> with package relay/nVersion deployment, there is still the duration between
> the pinning happening among network mempools and your replacement broadcast
> kickstarts.
>
> As a more long-term solution, we might reuse solutions worked out to
> mitigate channel jamming, as the abstract problem is the same, namely your
> counterparty can lock up scarce resources without (on-chain/off-chain
> whatever) fees paid.
>
> E.g the Staking Credentials framework could be deployed by dual-funding
> market-makers beyond routing hops [0]. The dual-funding initiator should
> pay to the maker a fee scale up on the amount of UTXOs contributed, and
> some worst-case liquidity griefing scenario. A privacy-preserving
> credential can be introduced between the payment of the fee and the redeem
> of the service to unlink dual-funding initiators (if the maker has enough
> volume to constitute a reasonable anonymity set).
>
> Best,
> Antoine
>
> [0]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-May/003964.html
>
>
> Le sam. 6 mai 2023 à 04:15, Bastien TEINTURIER <bastien at acinq.fr> a
> écrit :
>
>> Good morning list,
>>
>> One of the challenges created by the introduction of dual funded
>> transactions [1] in lightning is how to protect against liquidity
>> griefing attacks from malicious peers [2].
>>
>> Let's start by reviewing this liquidity griefing issue. The dual funding
>> protocol starts by exchanging data about the utxos each peer adds to the
>> shared transaction, then exchange signatures and broadcast the resulting
>> transaction. If peers lock their utxos as soon as they've decided to add
>> them to the shared transaction, the remote node may go silent. If that
>> happens, the honest node has some liquidity that is locked and unusable.
>>
>> This cannot easily be fixed by simply unlocking utxos *after* detecting
>> that the remote node is fishy, because the remote node would still have
>> succeeded at locking your liquidity for a (small) duration, and could
>> start other instances of that attack with different node_ids.
>>
>> An elegant solution to this issue is to never lock utxos used in dual
>> funded transactions. If a remote node goes silent in the middle of an
>> instance of the protocol, your utxos will automatically be re-used in
>> another instance of the protocol. The only drawback with that approach
>> is that when you have multiple concurrent instances of dual funding with
>> honest peers, some of them may fail because they are double-spent by one
>> of the concurrent instances. This is acceptable, since the protocol
>> should complete fairly quickly when peers are honest, and at worst, it
>> can simply be restarted when failure is detected.
>>
>> But that solution falls short when using 0-conf, because accidentally
>> double-spending a 0-conf channel (because of concurrent instances) can
>> result in loss of funds for one of the peers (if payments were made on
>> that channel before detecting the double-spend). It seems like using
>> 0-conf forces us to lock utxos to avoid this issue, which means that
>> nodes offering 0-conf services expose themselves to liquidity griefing.
>>
>> Another related issue is that nodes that want to offer 0-conf channels
>> must ensure that the utxos they use for 0-conf are isolated from the
>> utxos they use for non 0-conf, otherwise it is not possible to properly
>> lock utxos, because of the following race scenario:
>>
>> - utxoA is selected for a non 0-conf funding attempt and not locked
>> (to protect against liquidity griefing)
>> - utxoA is also selected for a 0-conf funding attempt (because it is
>> found unlocked in the wallet) and then locked
>> - the funding transaction for the 0-conf channel is successfully
>> published first and that channel is instantly used for payments
>> - the funding transaction for the non 0-conf channel is then published
>> and confirms, accidentally double-spending the 0-conf channel
>>
>> This can be fixed by using a "soft lock" when selecting utxos for a non
>> 0-conf funding attempt. 0-conf funding attempts must ignore soft locked
>> utxos while non 0-conf funding attempts can (should) reuse soft locked
>> utxos.
>>
>> In eclair, we are currently doing "opportunistic" 0-conf:
>>
>> - if we receive `channel_ready` immediately (which means that our peer
>> trusts us to use 0-conf)
>> - and we're the only contributor to the funding transaction (our peer
>> doesn't have any input that they could use to double-spend)
>> - and the transaction hasn't been RBF-ed yet
>>
>> Then we immediately send `channel_ready` as well and start using that
>> channel (because we know we won't double spend ourselves). This is nice
>> because it lets us use 0-conf in a way where only one side of the
>> channel needs to trust the other side (instead of both sides trusting
>> each other).
>>
>> Unfortunately, we cannot do that anymore when mixing 0-conf and non
>> 0-conf funding attempts, because the utxos may be soft locked,
>> preventing us from "upgrading" to 0-conf.
>>
>> You have successfully reached the end of this quite technical post,
>> congrats! My goal with this post is to gather ideas on how we could
>> improve that situation and offer good enough protections against
>> liquidity griefing for nodes offering 0-conf services. Please share
>> your ideas! And yes, I know, 0-conf is a massive implementation pain
>> point that we would all like to remove from our codebases, but hey,
>> users like it ¯\_(ツ)_/¯
>>
>> Cheers,
>> Bastien
>>
>> [1] https://github.com/lightning/bolts/pull/851
>> [2] https://github.com/lightning/bolts/pull/851#discussion_r997537630
>> _______________________________________________
>> 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/20230607/e913019a/attachment.html>

2023-06-09 13:13:16

- reply

2023-06-09 13:13:15

- reply

2023-06-09 13:13:02

- reply

📅 Original date posted:2023-04-06
🗒️ Summary of this message: A race condition has been discovered in the `splice_locked` workflow, affecting `commitment_signed` and `announcement_signatures` messages. Implementations need to handle this edge case correctly.
📝 Original message:
Hi Dustin,
I believe this is the scenario I described in [1]?
I haven't looked at the `announcement_signatures` case yet, but at least
for the `commit_sig` case this should never be an issue. It only means
that sometimes, after sending `splice_locked`, you will receive some
`commit_sig` messages that are for commitments that you don't care about
anymore. You should be able to safely ignore those `commit_sig`. I have
provided more details in the gist linked.
Let me know if I'm missing something, but I believe this is simply an
edge case that implementations need to correctly handle, not a protocol
issue? Or maybe I'm not understanding the scenario correctly?
By the way, I find your notation a bit hard to follow...I think that we
really need to detail the exact message flow (like I did in the linked
gist) to be able to explain protocol issues, otherwise there's always
a risk that people think about a slightly different message flow, which
means we'll just talk past each other...
Cheers,
Bastien
[1]
https://gist.github.com/t-bast/1ac31f4e27734a10c5b9847d06db8d86#multiple-splices-with-racy-splice_locked
Le jeu. 6 avr. 2023 à 02:40, Dustin Dettmer <dustin at koinkeep.com> a écrit :
> Hey,
>
> In testing the `splice_locked` workflow I discovered a race condition
> which is critical we solve correctly. The core problem happens if any
> channel activity occurs in the time after `splice_locked` is sent and
> before `splice_locked` is received.
>
> `splice_locked` is defined as being locked once it is both sent and
> received. It is fairly trivial to build a test case for this -- have a node
> continually spamming payments while `splice_lock`ing is occurring and the
> race condition will trigger relatively often.
>
> The race condition effects two messages in particular: `commitment_signed`
> and `announcement_signatures`. Below is an example of how it occurs with
> commitment but the flow is essentially the same for announcement:
>
> Legend:
> Item -> means sent
> Item <- means received
> Chan X (implies a channel at block height X)
> (Since these happen at different times)
> Splice locked race condition example
> Node A. Node B.
> * Channel starts at block height 100
> splice_locked ->
> <- splice_locked
> <- commitments_signed (Chan 100)
> -> splice_locked
> Node B now considers splice locked (Chan 106)
> <- commitments_signed (Chan 106)
> splice_locked <-
> Node A now considers splice locked (Chan 106)
> commitments_signed <- (Chan 100)
> commitments_signed <- (Chan 106)
> Node A considers the commitments_signed for Chan 100 invalid.
> The commitments_signed for Chan 106 is, however, valid.
> This example uses commitments_signed but remains a problem for any message
> that depends on channel state.
>
> The solution requires the temporary storing of two items:
> * [scid] last_short_channel_id (the pre-splice short channel id)
> * [bool] splice_await_commitment_succcess
>
> After sending & receiving `splice_locked` (so called 'mutual splice lock),
> the last_short_channel_id should be set to the pre-splice short channel id
> and splice_await_commitment_succcess should be flagged to true.
>
> If an `announcement_signatures` is received with an scid matching
> `last_short_channel_id` the message should be ignored and the channel
> connection should not be aborted (as it normally would).
>
> If a `commitment_signed` message is received with the
> tlv splice_info->splice_channel_id set to something other than the
> successfully confirmed splice channel_id, the message should be ignored.
>
> Once a revoke_and_ack is successfully sent OR received,
> `last_short_channel_id` and `splice_await_commitment_succcess` should be
> reset and normal validation of `announcement_signatures` and
> `commitment_signed` should be resumed.
>
> This solves the race condition while preserving as strict a validation of
> messages as possible and removes the need to add new fields to these
> messages.
>
> Cheers,
> Dusty
> _______________________________________________
> 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/20230406/058383a0/attachment-0001.html>

2023-06-09 13:12:57

- reply

📅 Original date posted:2023-03-31
🗒️ Summary of this message: The Lightning Network team has shared changes to simplify and improve the splicing protocol, including the use of "active commitments" and sending one `commitment_signed` message per active commitment.
📝 Original message:
Good morning list,
As some of you may know, we've been hard at work experimenting with
splicing [1]. Splicing is a complex feature with a large design space.
It was interesting to iterate on two separate implementations (eclair
and cln) and discover the pain points, edge cases and things that could
be improved in the protocol specification.
After a few months trying out different approaches, we'd like to share
changes that we believe make the splicing protocol simpler and more
robust.
We call "active commitments" the set of valid commitment transactions to
which updates must be applied. While one (or more) splices are ongoing,
there is more than one active commitment. When signing updates, we send
one `commitment_signed` message per active commitment. We send those
messages in the order in which the corresponding funding transactions
have been created, which lets the receiver implicitly match every
`commitment_signed` to their respective funding transaction.
Once we've negotiated a new splice and reached the signing steps of the
interactive-tx protocol, we send a single `commitment_signed` for that
new commitment. We don't revoke the previous commitment(s), as this adds
an unnecessary step. Conceptually, we're simply adding a new commitment
to our active commitments set.
A sample flow will look like this:
Alice Bob
| stfu |
|----------------------------->|
| stfu |
|<-----------------------------|
| splice_init |
|----------------------------->|
| splice_ack |
|<-----------------------------|
| |
| <interactive-tx> |
|<---------------------------->|
| |
| tx_complete |
|----------------------------->|
| tx_complete |
|<-----------------------------|
| commit_sig | Sign the new commitment.
|----------------------------->|
| commit_sig | Sign the new commitment.
|<-----------------------------|
| tx_signatures |
|----------------------------->|
| tx_signatures |
|<-----------------------------|
| |
| update_add_htlc | Alice and Bob use the channel while
the splice transaction is unconfirmed.
|----------------------------->|
| update_add_htlc |
|----------------------------->|
| commit_sig | Sign the old commitment.
|----------------------------->|
| commit_sig | Sign the new commitment.
|----------------------------->|
| revoke_and_ack |
|<-----------------------------|
| commit_sig | Sign the old commitment.
|<-----------------------------|
| commit_sig | Sign the new commitment.
|<-----------------------------|
| revoke_and_ack |
|----------------------------->|
| |
| splice_locked | The splice transaction confirms.
|----------------------------->|
| splice_locked |
|<-----------------------------|
| |
| update_add_htlc | Alice and Bob can use the channel and
forget the old commitment.
|----------------------------->|
| commit_sig | Sign the new commitment.
|----------------------------->|
| revoke_and_ack |
|<-----------------------------|
| commit_sig | Sign the new commitment.
|<-----------------------------|
| revoke_and_ack |
|----------------------------->|
| |
You can find many more details and sample flows in [2].
We require nodes to store data about the funding transaction as soon as
they send their `commitment_signed` message. This lets us handle every
disconnection scenario safely, allowing us to either resume the signing
steps on reconnection or forget the funding attempt. This is important
because if peers disagree on the set of active commitments, this will
lead to a force-close. In order to achieve that, we only need to add
the `next_funding_txid` to the `channel_reestablish` message, and fill
it when we're missing signatures from our peer. Again, you can find more
details and sample flows in [2].
Finally, after trying various approaches, we believe that the funding
amounts that peer exchange in `splice_init` and `splice_ack` should be
relative amounts based on each peer's current channel balance.
If Alice sends `funding_amount = 200_000 sats`, it means she will be
adding 200 000 sats to the channel's capacity (splice-in).
If she sends `funding_amount = -50_000 sats`, it means she will be
removing 50 000 sats from the channel's capacity (splice-out).
This makes it easier to compute the new channel balances (otherwise we
have to deal with millisatoshi to satoshi truncation) and better matches
the UX that node operators are expecting, which means there is less need
to glue code between the RPC exposed to the node operator and the actual
underlying protocol.
We've also discovered that implementing 0-conf splicing is tricky: you
need to be very careful about scenarios where your peer force-closes
using an *inactive* commitment that ends up double-spending what you
think is the only *active* commitment but is unconfirmed. We'd be happy
to discuss that in more details with other implementers to reduce the
risk of introducing new vulnerabilities when shipping that feature.
Cheers,
Bastien
[1] https://github.com/lightning/bolts/pull/863
[2] https://gist.github.com/t-bast/1ac31f4e27734a10c5b9847d06db8d86
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230331/9188b5fb/attachment.html>

2023-06-09 13:08:59

- reply

📅 Original date posted:2023-06-07
📝 Original message:
Hey Antoine,
Sure, I agree with you, the usual mempool pinning issues still apply
regardless of whether we use 0-conf or not. And we must solve them
all at some point!
I think a reasonable mid-term solution is to use v3 transactions for
channel funding and splicing, with the obvious caveat that it makes
them identifiable on-chain (unless in the longer term, everyone moves
to v3 transactions for everything, which doesn't seem crazy to me?).
In the longer term, we know that some kind of anti-DoS token will need
to be exchanged to avoid this whole class of issue, but as we've often
discussed this isn't an easy thing to design and analyze...
> it can still be valuable to disable inbound payments, or requires a
> longer `cltv_expiry_delta` than usual, in case of mempool fee spikes
> delaying the 0-conf chain confirmation.
Sure, that's a policy that nodes can decide to apply if they want to,
and it should be simple enough to implement (no protocol changes are
needed).
Thanks,
Bastien
Le mer. 7 juin 2023 à 02:41, Antoine Riard <antoine.riard at gmail.com> a
écrit :
> Hi Bastien,
>
> > This can be fixed by using a "soft lock" when selecting utxos for a non
> > 0-conf funding attempt. 0-conf funding attempts must ignore soft locked
> > utxos while non 0-conf funding attempts can (should) reuse soft locked
> > utxos.
>
> If my understanding of the "soft lock" strategy is correct - Only locking
> UTXO when it's a non 0-conf funding attempt - I think you're still exposed
> to liquidity griefing with dual-funding or splicing.
>
> The vector of griefing you're mentioning is the lack of signature release
> for a shared input by your counterparty. However, in the context of
> dual-funding where the counterparty can add any output with
> `tx_add_output`, the transaction can be pinned in the mempool in a very
> sneaky way e.g abuse of replacement rule 3.
>
> This latter pinning vector is advantageous to the malicious counterparty
> as I think you can batch your pinning against unrelated dual-funding, only
> linked in the mempool by a malicious pinning CPFP.
>
> It is left as an exercise to the reader to find other vectors of pinnings
> that can be played out in the dual-funding flow.
>
> In terms of (quick) solution to prevent liquidity griefing related to
> mempool vectors, the (honest) counterparty can enforce that any contributed
> outputs must be encumbered by a 1 CSV, unless being a 2-of-2 funding.
> Still, this mitigation can be limited as I think the initial commitment
> transaction must have anchor outputs on each-side, for each party to
> recover its contributed UTXOs in any case.
>
> > Then we immediately send `channel_ready` as well and start using that
> > channel (because we know we won't double spend ourselves). This is nice
> > because it lets us use 0-conf in a way where only one side of the
> > channel needs to trust the other side (instead of both sides trusting
> > each other).
>
> From the 0-conf initiator viewpoint (the one contributing the UTXO(s)), it
> can still be valuable to disable inbound payments, or requires a longer
> `cltv_expiry_delta` than usual, in case of mempool fee spikes delaying the
> 0-conf chain confirmation.
>
> Beyond, it sounds liquidity griefing provoked by a lack of signature
> release or mempool funny games will always be there ? Even for the second
> with package relay/nVersion deployment, there is still the duration between
> the pinning happening among network mempools and your replacement broadcast
> kickstarts.
>
> As a more long-term solution, we might reuse solutions worked out to
> mitigate channel jamming, as the abstract problem is the same, namely your
> counterparty can lock up scarce resources without (on-chain/off-chain
> whatever) fees paid.
>
> E.g the Staking Credentials framework could be deployed by dual-funding
> market-makers beyond routing hops [0]. The dual-funding initiator should
> pay to the maker a fee scale up on the amount of UTXOs contributed, and
> some worst-case liquidity griefing scenario. A privacy-preserving
> credential can be introduced between the payment of the fee and the redeem
> of the service to unlink dual-funding initiators (if the maker has enough
> volume to constitute a reasonable anonymity set).
>
> Best,
> Antoine
>
> [0]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-May/003964.html
>
>
> Le sam. 6 mai 2023 à 04:15, Bastien TEINTURIER <bastien at acinq.fr> a
> écrit :
>
>> Good morning list,
>>
>> One of the challenges created by the introduction of dual funded
>> transactions [1] in lightning is how to protect against liquidity
>> griefing attacks from malicious peers [2].
>>
>> Let's start by reviewing this liquidity griefing issue. The dual funding
>> protocol starts by exchanging data about the utxos each peer adds to the
>> shared transaction, then exchange signatures and broadcast the resulting
>> transaction. If peers lock their utxos as soon as they've decided to add
>> them to the shared transaction, the remote node may go silent. If that
>> happens, the honest node has some liquidity that is locked and unusable.
>>
>> This cannot easily be fixed by simply unlocking utxos *after* detecting
>> that the remote node is fishy, because the remote node would still have
>> succeeded at locking your liquidity for a (small) duration, and could
>> start other instances of that attack with different node_ids.
>>
>> An elegant solution to this issue is to never lock utxos used in dual
>> funded transactions. If a remote node goes silent in the middle of an
>> instance of the protocol, your utxos will automatically be re-used in
>> another instance of the protocol. The only drawback with that approach
>> is that when you have multiple concurrent instances of dual funding with
>> honest peers, some of them may fail because they are double-spent by one
>> of the concurrent instances. This is acceptable, since the protocol
>> should complete fairly quickly when peers are honest, and at worst, it
>> can simply be restarted when failure is detected.
>>
>> But that solution falls short when using 0-conf, because accidentally
>> double-spending a 0-conf channel (because of concurrent instances) can
>> result in loss of funds for one of the peers (if payments were made on
>> that channel before detecting the double-spend). It seems like using
>> 0-conf forces us to lock utxos to avoid this issue, which means that
>> nodes offering 0-conf services expose themselves to liquidity griefing.
>>
>> Another related issue is that nodes that want to offer 0-conf channels
>> must ensure that the utxos they use for 0-conf are isolated from the
>> utxos they use for non 0-conf, otherwise it is not possible to properly
>> lock utxos, because of the following race scenario:
>>
>> - utxoA is selected for a non 0-conf funding attempt and not locked
>> (to protect against liquidity griefing)
>> - utxoA is also selected for a 0-conf funding attempt (because it is
>> found unlocked in the wallet) and then locked
>> - the funding transaction for the 0-conf channel is successfully
>> published first and that channel is instantly used for payments
>> - the funding transaction for the non 0-conf channel is then published
>> and confirms, accidentally double-spending the 0-conf channel
>>
>> This can be fixed by using a "soft lock" when selecting utxos for a non
>> 0-conf funding attempt. 0-conf funding attempts must ignore soft locked
>> utxos while non 0-conf funding attempts can (should) reuse soft locked
>> utxos.
>>
>> In eclair, we are currently doing "opportunistic" 0-conf:
>>
>> - if we receive `channel_ready` immediately (which means that our peer
>> trusts us to use 0-conf)
>> - and we're the only contributor to the funding transaction (our peer
>> doesn't have any input that they could use to double-spend)
>> - and the transaction hasn't been RBF-ed yet
>>
>> Then we immediately send `channel_ready` as well and start using that
>> channel (because we know we won't double spend ourselves). This is nice
>> because it lets us use 0-conf in a way where only one side of the
>> channel needs to trust the other side (instead of both sides trusting
>> each other).
>>
>> Unfortunately, we cannot do that anymore when mixing 0-conf and non
>> 0-conf funding attempts, because the utxos may be soft locked,
>> preventing us from "upgrading" to 0-conf.
>>
>> You have successfully reached the end of this quite technical post,
>> congrats! My goal with this post is to gather ideas on how we could
>> improve that situation and offer good enough protections against
>> liquidity griefing for nodes offering 0-conf services. Please share
>> your ideas! And yes, I know, 0-conf is a massive implementation pain
>> point that we would all like to remove from our codebases, but hey,
>> users like it ¯\_(ツ)_/¯
>>
>> Cheers,
>> Bastien
>>
>> [1] https://github.com/lightning/bolts/pull/851
>> [2] https://github.com/lightning/bolts/pull/851#discussion_r997537630
>> _______________________________________________
>> 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/20230607/e913019a/attachment.html>

2023-06-09 13:08:47

- reply

📅 Original date posted:2023-05-10
📝 Original message:
Hey Matt, Zman,
> I propose that we DO lock our UTXOs after tx_completes have been
> exchanged IF we are the only contributor. We don't have to worry
> about liquidity griefing in this case, since the peer has no
> tx_signatures to withhold from us.
While this is true for dual funding, this isn't true for splicing, where
we need the remote `tx_signatures` to spend the channel's current
funding output. But it's not an issue, the untrusted peer will send
their `tx_signatures` first (since they're not contributing to the
transaction) and we can `TryLock()` once we receive that.
> Your proposal basically means "do not dual-fund 0-conf".
> You might as well use the much simpler openv1 flow in that case, just
> because it is simpler.
I also thought that this was the easy way out, but I was hoping we could
do better. The issue with that option (using v1 with locks for 0-conf,
and v2 with soft locks for non 0-conf) is that we need to implement that
soft lock mechanism (we cannot simply rely on bitcoin core, which only
supports hard locks) or use separate bitcoin core wallets for 0-conf and
non 0-conf.
But there is probably no free lunch here! And anyway, this post was also
made to raise awareness for implementers to make sure they don't end up
accidentally double-spending 0-conf channels when implementing dual
funding.
Thanks,
Bastien
Le mer. 10 mai 2023 à 02:07, ZmnSCPxj <ZmnSCPxj at protonmail.com> a écrit :
> Good morning Matt, and t-bast,
>
> Your proposal basically means "do not dual-fund 0-conf".
> You might as well use the much simpler openv1 flow in that case, just
> because it is simpler.
>
> Regards,
> ZmnSCPxj
>
>
>
>
> Sent with Proton Mail secure email.
>
> ------- Original Message -------
> On Tuesday, May 9th, 2023 at 5:38 PM, Matt Morehouse <
> mattmorehouse at gmail.com> wrote:
>
>
> > Hi Bastien,
> >
> > In general, 0-conf is only safe when WE are the only contributor to
> > the channel, otherwise the peer could double spend us.
> >
> > The problem you seem to be describing is that we might double-spend
> > ourselves if we don't lock our 0-conf UTXOs at some point. I propose
> > that we DO lock our UTXOs after tx_completes have been exchanged IF we
> > are the only contributor. We don't have to worry about liquidity
> > griefing in this case, since the peer has no tx_signatures to withhold
> > from us. Of course, the opportunistic upgrade of a regular channel to
> > 0-conf won't work -- we need a way to differentiate 0-conf channels
> > prior to UTXO selection, so that we don't reuse soft-locked UTXOs.
> >
> > All together, what I propose is:
> >
> > 1) If the channel type has option_zeroconf, select UTXOs that are not
> > soft locked.
> > 2) If the peer adds any inputs to the funding transaction, abort
> > (0-conf is unsafe for us in this case).
> > 3) After tx_complete exchange, TryLock() our UTXO inputs and abort if
> > already locked.
> > 4) Broadcast funding transaction and begin using the 0-conf channel.
> >
> > I think this at least enables the common use case for 0-conf: LSPs can
> > use their own funds to open 0-conf channels for clients.
> >
> > - Matt
> >
> >
> >
> >
> > On Sat, May 6, 2023 at 3:16 AM Bastien TEINTURIER bastien at acinq.fr
> wrote:
> >
> > > Good morning list,
> > >
> > > One of the challenges created by the introduction of dual funded
> > > transactions [1] in lightning is how to protect against liquidity
> > > griefing attacks from malicious peers [2].
> > >
> > > Let's start by reviewing this liquidity griefing issue. The dual
> funding
> > > protocol starts by exchanging data about the utxos each peer adds to
> the
> > > shared transaction, then exchange signatures and broadcast the
> resulting
> > > transaction. If peers lock their utxos as soon as they've decided to
> add
> > > them to the shared transaction, the remote node may go silent. If that
> > > happens, the honest node has some liquidity that is locked and
> unusable.
> > >
> > > This cannot easily be fixed by simply unlocking utxos after detecting
> > > that the remote node is fishy, because the remote node would still have
> > > succeeded at locking your liquidity for a (small) duration, and could
> > > start other instances of that attack with different node_ids.
> > >
> > > An elegant solution to this issue is to never lock utxos used in dual
> > > funded transactions. If a remote node goes silent in the middle of an
> > > instance of the protocol, your utxos will automatically be re-used in
> > > another instance of the protocol. The only drawback with that approach
> > > is that when you have multiple concurrent instances of dual funding
> with
> > > honest peers, some of them may fail because they are double-spent by
> one
> > > of the concurrent instances. This is acceptable, since the protocol
> > > should complete fairly quickly when peers are honest, and at worst, it
> > > can simply be restarted when failure is detected.
> > >
> > > But that solution falls short when using 0-conf, because accidentally
> > > double-spending a 0-conf channel (because of concurrent instances) can
> > > result in loss of funds for one of the peers (if payments were made on
> > > that channel before detecting the double-spend). It seems like using
> > > 0-conf forces us to lock utxos to avoid this issue, which means that
> > > nodes offering 0-conf services expose themselves to liquidity griefing.
> > >
> > > Another related issue is that nodes that want to offer 0-conf channels
> > > must ensure that the utxos they use for 0-conf are isolated from the
> > > utxos they use for non 0-conf, otherwise it is not possible to properly
> > > lock utxos, because of the following race scenario:
> > >
> > > - utxoA is selected for a non 0-conf funding attempt and not locked
> > > (to protect against liquidity griefing)
> > > - utxoA is also selected for a 0-conf funding attempt (because it is
> > > found unlocked in the wallet) and then locked
> > > - the funding transaction for the 0-conf channel is successfully
> > > published first and that channel is instantly used for payments
> > > - the funding transaction for the non 0-conf channel is then published
> > > and confirms, accidentally double-spending the 0-conf channel
> > >
> > > This can be fixed by using a "soft lock" when selecting utxos for a non
> > > 0-conf funding attempt. 0-conf funding attempts must ignore soft locked
> > > utxos while non 0-conf funding attempts can (should) reuse soft locked
> > > utxos.
> > >
> > > In eclair, we are currently doing "opportunistic" 0-conf:
> > >
> > > - if we receive `channel_ready` immediately (which means that our peer
> > > trusts us to use 0-conf)
> > > - and we're the only contributor to the funding transaction (our peer
> > > doesn't have any input that they could use to double-spend)
> > > - and the transaction hasn't been RBF-ed yet
> > >
> > > Then we immediately send `channel_ready` as well and start using that
> > > channel (because we know we won't double spend ourselves). This is nice
> > > because it lets us use 0-conf in a way where only one side of the
> > > channel needs to trust the other side (instead of both sides trusting
> > > each other).
> > >
> > > Unfortunately, we cannot do that anymore when mixing 0-conf and non
> > > 0-conf funding attempts, because the utxos may be soft locked,
> > > preventing us from "upgrading" to 0-conf.
> > >
> > > You have successfully reached the end of this quite technical post,
> > > congrats! My goal with this post is to gather ideas on how we could
> > > improve that situation and offer good enough protections against
> > > liquidity griefing for nodes offering 0-conf services. Please share
> > > your ideas! And yes, I know, 0-conf is a massive implementation pain
> > > point that we would all like to remove from our codebases, but hey,
> > > users like it ¯\(ツ)/¯
> > >
> > > Cheers,
> > > Bastien
> > >
> > > [1] https://github.com/lightning/bolts/pull/851
> > > [2] https://github.com/lightning/bolts/pull/851#discussion_r997537630
> > > _______________________________________________
> > > 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/20230510/1e7a1a83/attachment.html>

2023-06-09 13:08:45

- reply

📅 Original date posted:2023-05-05
📝 Original message:
Good morning list,
One of the challenges created by the introduction of dual funded
transactions [1] in lightning is how to protect against liquidity
griefing attacks from malicious peers [2].
Let's start by reviewing this liquidity griefing issue. The dual funding
protocol starts by exchanging data about the utxos each peer adds to the
shared transaction, then exchange signatures and broadcast the resulting
transaction. If peers lock their utxos as soon as they've decided to add
them to the shared transaction, the remote node may go silent. If that
happens, the honest node has some liquidity that is locked and unusable.
This cannot easily be fixed by simply unlocking utxos *after* detecting
that the remote node is fishy, because the remote node would still have
succeeded at locking your liquidity for a (small) duration, and could
start other instances of that attack with different node_ids.
An elegant solution to this issue is to never lock utxos used in dual
funded transactions. If a remote node goes silent in the middle of an
instance of the protocol, your utxos will automatically be re-used in
another instance of the protocol. The only drawback with that approach
is that when you have multiple concurrent instances of dual funding with
honest peers, some of them may fail because they are double-spent by one
of the concurrent instances. This is acceptable, since the protocol
should complete fairly quickly when peers are honest, and at worst, it
can simply be restarted when failure is detected.
But that solution falls short when using 0-conf, because accidentally
double-spending a 0-conf channel (because of concurrent instances) can
result in loss of funds for one of the peers (if payments were made on
that channel before detecting the double-spend). It seems like using
0-conf forces us to lock utxos to avoid this issue, which means that
nodes offering 0-conf services expose themselves to liquidity griefing.
Another related issue is that nodes that want to offer 0-conf channels
must ensure that the utxos they use for 0-conf are isolated from the
utxos they use for non 0-conf, otherwise it is not possible to properly
lock utxos, because of the following race scenario:
- utxoA is selected for a non 0-conf funding attempt and not locked
(to protect against liquidity griefing)
- utxoA is also selected for a 0-conf funding attempt (because it is
found unlocked in the wallet) and then locked
- the funding transaction for the 0-conf channel is successfully
published first and that channel is instantly used for payments
- the funding transaction for the non 0-conf channel is then published
and confirms, accidentally double-spending the 0-conf channel
This can be fixed by using a "soft lock" when selecting utxos for a non
0-conf funding attempt. 0-conf funding attempts must ignore soft locked
utxos while non 0-conf funding attempts can (should) reuse soft locked
utxos.
In eclair, we are currently doing "opportunistic" 0-conf:
- if we receive `channel_ready` immediately (which means that our peer
trusts us to use 0-conf)
- and we're the only contributor to the funding transaction (our peer
doesn't have any input that they could use to double-spend)
- and the transaction hasn't been RBF-ed yet
Then we immediately send `channel_ready` as well and start using that
channel (because we know we won't double spend ourselves). This is nice
because it lets us use 0-conf in a way where only one side of the
channel needs to trust the other side (instead of both sides trusting
each other).
Unfortunately, we cannot do that anymore when mixing 0-conf and non
0-conf funding attempts, because the utxos may be soft locked,
preventing us from "upgrading" to 0-conf.
You have successfully reached the end of this quite technical post,
congrats! My goal with this post is to gather ideas on how we could
improve that situation and offer good enough protections against
liquidity griefing for nodes offering 0-conf services. Please share
your ideas! And yes, I know, 0-conf is a massive implementation pain
point that we would all like to remove from our codebases, but hey,
users like it ¯\_(ツ)_/¯
Cheers,
Bastien
[1] https://github.com/lightning/bolts/pull/851
[2] https://github.com/lightning/bolts/pull/851#discussion_r997537630
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230505/9638cc46/attachment-0001.html>

2023-06-09 13:08:32

- reply

📅 Original date posted:2023-04-06
📝 Original message:
Hi Dustin,
I believe this is the scenario I described in [1]?
I haven't looked at the `announcement_signatures` case yet, but at least
for the `commit_sig` case this should never be an issue. It only means
that sometimes, after sending `splice_locked`, you will receive some
`commit_sig` messages that are for commitments that you don't care about
anymore. You should be able to safely ignore those `commit_sig`. I have
provided more details in the gist linked.
Let me know if I'm missing something, but I believe this is simply an
edge case that implementations need to correctly handle, not a protocol
issue? Or maybe I'm not understanding the scenario correctly?
By the way, I find your notation a bit hard to follow...I think that we
really need to detail the exact message flow (like I did in the linked
gist) to be able to explain protocol issues, otherwise there's always
a risk that people think about a slightly different message flow, which
means we'll just talk past each other...
Cheers,
Bastien
[1]
https://gist.github.com/t-bast/1ac31f4e27734a10c5b9847d06db8d86#multiple-splices-with-racy-splice_locked
Le jeu. 6 avr. 2023 à 02:40, Dustin Dettmer <dustin at koinkeep.com> a écrit :
> Hey,
>
> In testing the `splice_locked` workflow I discovered a race condition
> which is critical we solve correctly. The core problem happens if any
> channel activity occurs in the time after `splice_locked` is sent and
> before `splice_locked` is received.
>
> `splice_locked` is defined as being locked once it is both sent and
> received. It is fairly trivial to build a test case for this -- have a node
> continually spamming payments while `splice_lock`ing is occurring and the
> race condition will trigger relatively often.
>
> The race condition effects two messages in particular: `commitment_signed`
> and `announcement_signatures`. Below is an example of how it occurs with
> commitment but the flow is essentially the same for announcement:
>
> Legend:
> Item -> means sent
> Item <- means received
> Chan X (implies a channel at block height X)
> (Since these happen at different times)
> Splice locked race condition example
> Node A. Node B.
> * Channel starts at block height 100
> splice_locked ->
> <- splice_locked
> <- commitments_signed (Chan 100)
> -> splice_locked
> Node B now considers splice locked (Chan 106)
> <- commitments_signed (Chan 106)
> splice_locked <-
> Node A now considers splice locked (Chan 106)
> commitments_signed <- (Chan 100)
> commitments_signed <- (Chan 106)
> Node A considers the commitments_signed for Chan 100 invalid.
> The commitments_signed for Chan 106 is, however, valid.
> This example uses commitments_signed but remains a problem for any message
> that depends on channel state.
>
> The solution requires the temporary storing of two items:
> * [scid] last_short_channel_id (the pre-splice short channel id)
> * [bool] splice_await_commitment_succcess
>
> After sending & receiving `splice_locked` (so called 'mutual splice lock),
> the last_short_channel_id should be set to the pre-splice short channel id
> and splice_await_commitment_succcess should be flagged to true.
>
> If an `announcement_signatures` is received with an scid matching
> `last_short_channel_id` the message should be ignored and the channel
> connection should not be aborted (as it normally would).
>
> If a `commitment_signed` message is received with the
> tlv splice_info->splice_channel_id set to something other than the
> successfully confirmed splice channel_id, the message should be ignored.
>
> Once a revoke_and_ack is successfully sent OR received,
> `last_short_channel_id` and `splice_await_commitment_succcess` should be
> reset and normal validation of `announcement_signatures` and
> `commitment_signed` should be resumed.
>
> This solves the race condition while preserving as strict a validation of
> messages as possible and removes the need to add new fields to these
> messages.
>
> Cheers,
> Dusty
> _______________________________________________
> 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/20230406/058383a0/attachment-0001.html>

2023-06-09 13:08:25

- reply

📅 Original date posted:2023-03-31
📝 Original message:
Good morning list,
As some of you may know, we've been hard at work experimenting with
splicing [1]. Splicing is a complex feature with a large design space.
It was interesting to iterate on two separate implementations (eclair
and cln) and discover the pain points, edge cases and things that could
be improved in the protocol specification.
After a few months trying out different approaches, we'd like to share
changes that we believe make the splicing protocol simpler and more
robust.
We call "active commitments" the set of valid commitment transactions to
which updates must be applied. While one (or more) splices are ongoing,
there is more than one active commitment. When signing updates, we send
one `commitment_signed` message per active commitment. We send those
messages in the order in which the corresponding funding transactions
have been created, which lets the receiver implicitly match every
`commitment_signed` to their respective funding transaction.
Once we've negotiated a new splice and reached the signing steps of the
interactive-tx protocol, we send a single `commitment_signed` for that
new commitment. We don't revoke the previous commitment(s), as this adds
an unnecessary step. Conceptually, we're simply adding a new commitment
to our active commitments set.
A sample flow will look like this:
Alice Bob
| stfu |
|----------------------------->|
| stfu |
|<-----------------------------|
| splice_init |
|----------------------------->|
| splice_ack |
|<-----------------------------|
| |
| <interactive-tx> |
|<---------------------------->|
| |
| tx_complete |
|----------------------------->|
| tx_complete |
|<-----------------------------|
| commit_sig | Sign the new commitment.
|----------------------------->|
| commit_sig | Sign the new commitment.
|<-----------------------------|
| tx_signatures |
|----------------------------->|
| tx_signatures |
|<-----------------------------|
| |
| update_add_htlc | Alice and Bob use the channel while
the splice transaction is unconfirmed.
|----------------------------->|
| update_add_htlc |
|----------------------------->|
| commit_sig | Sign the old commitment.
|----------------------------->|
| commit_sig | Sign the new commitment.
|----------------------------->|
| revoke_and_ack |
|<-----------------------------|
| commit_sig | Sign the old commitment.
|<-----------------------------|
| commit_sig | Sign the new commitment.
|<-----------------------------|
| revoke_and_ack |
|----------------------------->|
| |
| splice_locked | The splice transaction confirms.
|----------------------------->|
| splice_locked |
|<-----------------------------|
| |
| update_add_htlc | Alice and Bob can use the channel and
forget the old commitment.
|----------------------------->|
| commit_sig | Sign the new commitment.
|----------------------------->|
| revoke_and_ack |
|<-----------------------------|
| commit_sig | Sign the new commitment.
|<-----------------------------|
| revoke_and_ack |
|----------------------------->|
| |
You can find many more details and sample flows in [2].
We require nodes to store data about the funding transaction as soon as
they send their `commitment_signed` message. This lets us handle every
disconnection scenario safely, allowing us to either resume the signing
steps on reconnection or forget the funding attempt. This is important
because if peers disagree on the set of active commitments, this will
lead to a force-close. In order to achieve that, we only need to add
the `next_funding_txid` to the `channel_reestablish` message, and fill
it when we're missing signatures from our peer. Again, you can find more
details and sample flows in [2].
Finally, after trying various approaches, we believe that the funding
amounts that peer exchange in `splice_init` and `splice_ack` should be
relative amounts based on each peer's current channel balance.
If Alice sends `funding_amount = 200_000 sats`, it means she will be
adding 200 000 sats to the channel's capacity (splice-in).
If she sends `funding_amount = -50_000 sats`, it means she will be
removing 50 000 sats from the channel's capacity (splice-out).
This makes it easier to compute the new channel balances (otherwise we
have to deal with millisatoshi to satoshi truncation) and better matches
the UX that node operators are expecting, which means there is less need
to glue code between the RPC exposed to the node operator and the actual
underlying protocol.
We've also discovered that implementing 0-conf splicing is tricky: you
need to be very careful about scenarios where your peer force-closes
using an *inactive* commitment that ends up double-spending what you
think is the only *active* commitment but is unconfirmed. We'd be happy
to discuss that in more details with other implementers to reduce the
risk of introducing new vulnerabilities when shipping that feature.
Cheers,
Bastien
[1] https://github.com/lightning/bolts/pull/863
[2] https://gist.github.com/t-bast/1ac31f4e27734a10c5b9847d06db8d86
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230331/9188b5fb/attachment.html>

2023-06-09 13:07:21

- reply

📅 Original date posted:2022-11-07
📝 Original message:
Hey laolu,
Thanks for your feedback.
> However, I can imagine that if an implementation doesn't have its own
> wallet, then things can be a bit more difficult, as stuff like the
bitcoind
> wallet may not expose the APIs one needs to do things like CPFP properly.
I don't think this is only an issue of wallet management though. I would
bet that most node operators today don't have a good enough utxo reserve
to actually provide safety against a malicious attacker once mempool
backlog starts filling up. Eclair isn't really limited by bitcoind APIs
here, but rather by BIP 125 rules, which creates the same issues for
lnd's internal wallet.
The reason we're not seeing issues today is only because there is no
malicious behavior on the network, but when that happens, there will
be issues (remember, the turkey thinks everything is fine and really
likes that guy who comes everyday to feed it, until Thanksgiving comes).
The issue I'm most concerned with is an attacker filling your outgoing
HTLC slots with HTLCs that timeout at blocks N+1, N+2, ..., N+483. It's
not trivial to batch those HTLCs because they all have different cltv
expiries. If you're low on utxo count, you only have two choices:
1. Re-create a batched transaction at every block to include more utxos
2. Create trees of unconfirmed transactions where the change output of
one HTLC tx is the funding input of another HTLC tx
With option 1, you'll need to increase the overall feerate at every
block to match RBF rules, which means you'll end up greatly overpaying
the fees once you've RBF-ed a hundred times or more...
With option 2, it's even worse, because HTLCs that timeout earlier end
up closer to the root of tree. It will be prohibitively costly to RBF
them because BIP 125 will force you to pay a huge fee for replacing a
high number of unconfirmed descendants. Your only option is to CPFP at
one of the leaves of the tree, which is going to be very costly as well
because it requires setting a high feerate to the *whole* tree, even
though it could contain many HTLCs that still have time available before
the cltv-expiry-delta ends.
The attacker may also regularly claim HTLCs one-by-one by revealing the
preimage just to invalidate your whole batched transaction or tree of
unconfirmed transactions, requiring you to rebuild it at every block and
wait one more block before getting transactions confirmed (until you
reach the point where the attacker can also claim all HTLC outputs and
your only solution is a scorched-earth strategy).
Both options end up with the node operator greatly overpaying fees when
fighting a relatively smart attacker (which means the node operator is
actually losing money).
Also, this is a fairly complex bit of logic to implement, which depends
on bitcoin node's relaying policies and is really hard to test against
enough malicious scenarios. It's thus very likely to have subtle bugs.
This class of attacks are why eclair's default are very conservative:
* 30 accepted HTLCs instead of 483
* 144 blocks of cltv-expiry-delta
I'm afraid this is the only way to tip the odds in the favor of the
honest node operators with the current protocol. It's very frustrating
though!
As for Taproot compatibility, this is perfectly doable: if we're able
to share one nonce, we can just share multiple every time. If we're
able to watch one transaction, we're able to watch multiple. It's more
costly, but it's not a fundamental limitation.
I'm more concerned about limitations of this proposal to tackle dusty
HTLCs kind of attacks and the complexity it introduces, as was raised
in the comments of the spec PR [1]. Granted, this isn't a very *good*
proposal, but it's an attempt at raising awareness that we probably
need to do *something* to get slightly better funds safety.
Thanks,
Bastien
[1] https://github.com/lightning/bolts/pull/1036
Le sam. 5 nov. 2022 à 01:52, Olaoluwa Osuntokun <laolu32 at gmail.com> a écrit
:
>
> Hi tbast,
>
> FWIW, we haven't had _too_ many issues with the additional constraints
> anchor channels bring. Initially users had to deal w/ the UTXO reserve,
but
> then sort of accepted the trade-off for the safety that actually being
able
> to dynamically bump the fee on your commitment transaction and HTLCs.
We're
> also able to re-target the fee level of second level spends on the fly,
and
> even aggregate them into distinct fee buckets.
>
> However, I can imagine that if an implementation doesn't have its own
> wallet, then things can be a bit more difficult, as stuff like the
bitcoind
> wallet may not expose the APIs one needs to do things like CPFP properly.
> lnd has its own wallet (btcwallet), which is what has allowed us to adopt
> default P2TR addresses everywhere so quickly (tho ofc we inherit
additional
> maintenance costs).
>
> > Correctly managing this fee-bumping reserve involves a lot of complex
> > decisions and dynamic risk assessment, because in worst-case scenarios,
a
> > node may need to fee-bump thousands of HTLC transactions in a short
period
> > of time.
>
> IMO these new considerations aren't any worse than needing to predict the
> future fee schedule of the chain to ensure that you can force close in a
> timely manner when you need to. Re fee bumping thousands of HTLCs: anchor
> lets them all be batched in the same transaction, which reduces fees and
> also the worst-case on-chain force close footprint.
>
> > each node can simply sign multiple versions of the HTLC transactions at
> > various feerates
>
> I'm not sure this can be mapped super cleanly to taproot channels that use
> musig2. Today in the spec draft/impl, both sides maintain a pair of nonces
> (one for each commitment transaction). If they need to sign N different
> versions, then they also need to exchange N nonces, both during the
initial
> funding process, and also each time a new commitment transaction is
created.
> Mo signatures means mo transaction latency. Also how would retransmitting
be
> handled? By sending distinct valid signatures for a given fee rate, you're
> effectively creating _even more_ commitments one needs to watch to be able
> to play once they potentially hit the chain.
>
> Ultimately, I'm not sure why implementations that have already rolled out
> anchors by default, and have a satisfactory policy for ensuring fee
bumping
> UTXOs are available at all times would implement this. It's just yet
another
> option defined in the spec, and prescribes a more restrictive solution to
> what's already possible: being able to dynamically fee bump commitment
> transactions, and aggregate second level spends.
>
> -- Laolu
>
> On Thu, Oct 27, 2022 at 6:51 AM Bastien TEINTURIER <bastien at acinq.fr>
wrote:
>>
>> Good morning list,
>>
>> The lightning network transaction format was updated to leverage CPFP
>> carve-out and allow nodes to set fees at broadcast time, using a feature
>> called anchor outputs [1].
>>
>> While desirable, this change brought a whole new set of challenges, by
>> requiring nodes to maintain a reserve of available utxos for fee-bumping.
>> Correctly managing this fee-bumping reserve involves a lot of complex
>> decisions and dynamic risk assessment, because in worst-case scenarios,
>> a node may need to fee-bump thousands of HTLC transactions in a short
>> period of time.
>>
>> This is especially frustrating because HTLC transactions should not need
>> external inputs, as the whole value of the HTLC is already provided in
>> its input, which means we could in theory "simply" decrease the amount of
>> the corresponding output to set the fees to any desired value. However,
>> we can't do this safely because it doesn't work well with the revocation
>> mechanism, unless we find fancy new sighash flags to add to bitcoin.
>> See [2] for a longer rant on this issue.
>>
>> A very low tech and unsatisfying solution exists, which is what I'm
>> proposing today: each node can simply sign multiple versions of the
>> HTLC transactions at various feerates, and at broadcast time if you're
>> lucky you'll have a pre-signed transaction that approximately matches
>> the feerate you want, so you don't need to add inputs from your fee
>> bumping reserve. This reduces the requirements on your on-chain wallet
>> and simplifies transaction management logic. I believe that it's a
>> pragmatic approach, even though not very elegant, to increase funds
>> safety for existing node operators and wallets. I opened a spec PR
>> that is currently chasing concept ACKs before I refine it [3].
>>
>> Please let me know what you think, and if this is something that you
>> would like your implementation to provide.
>>
>> Thanks,
>> Bastien
>>
>> [1] https://github.com/lightning/bolts/pull/688
>> [2] https://github.com/lightning/bolts/issues/845
>> [3] https://github.com/lightning/bolts/pull/1036
>> _______________________________________________
>> 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/20221107/890d4429/attachment.html>

2023-06-09 13:07:14

- reply

📅 Original date posted:2022-11-02
📝 Original message:
Good morning John,
> As a result, once the dedicated user decides to splice out some channel
funds, the dedicated user cannot access those funds until some time *after*
the casual user has been online (provided the protocol is trust-free).
The trick here is that the dedicated user *always* has a splice-out tx
available, they don't need to to wait for the casual user to reconnect.
At every update of the channel, the casual user will sign a splice tx
that lets the dedicated user get some of their funds back in case the
casual user goes offline for a long duration. But that splice tx will
indeed be csv-delayed.
Most of the time those splice-out txs will simply be discarded the next
time the channel is updated, but it gives the dedicated user a guarantee
that they're able to get some funds back easily without closing the
channel if they need it.
> Given this observation, what if the protocol were changed so that,
instead of pre-signing a splice transaction, the casual user always checks
in with the dedicated user whenever they check the blockchain? At such a
check-in, if the dedicated user wants to splice out some channel funds,
they send the casual user a splice transaction which splices out some of
the funds to the dedicated user without requiring a to_self delay. The
casual user then signs the splice transaction and returns the signature as
part of the check-in.
Yes, that is something we'll have as well. On the LSP side, we'll most
likely try to get the mobile user to connect and negotiate a splice-out
without any delays. If the mobile user doesn't connect, then we'll use
the pre-signed delayed splice-out we have from the latest channel state
update.
Sorry if this is very hand-wavy, we haven't worked on the details yet,
but at a high-level, this is the kind of flexibility we'd like to have.
> However, if we eventually get to the point where the blockchain is
highly-contested and fees are high, it may no longer be worth paying the
fees to put a splice transaction on-chain unless a large amount of capital
is at stake for a long period of time.
That's true, we're currently using the assumption that fees will be high
but there will be regular opportunities to get txs confirmed at a lower
feerate because of random fluctuations in mempool congestion. If that
doesn't happen, funds will most likely be idle and we won't use those
splices very often.
Cheers,
Bastien
Le lun. 31 oct. 2022 à 01:20, jlspc <jlspc at protonmail.com> a écrit :
> Hi Bastien,
>
> Thanks for your detailed response.
>
> I see how the use of a pre-signed "splice" transaction that allows the dedicated user to obtain some of their capital creates an inherent trade-off between the dedicated user's capital efficiency and the casual user's ability to be offline for an extended period of time.
>
> In order for the use of a pre-signed splice transaction to be safe, the casual user has to check the blockchain and see the splice transaction before it can be spent by the dedicated user (in order to revoke it if needed). As a result, once the dedicated user decides to splice out some channel funds, the dedicated user cannot access those funds until some time *after* the casual user has been online (provided the protocol is trust-free).
>
> Given this observation, what if the protocol were changed so that, instead of pre-signing a splice transaction, the casual user always checks in with the dedicated user whenever they check the blockchain? At such a check-in, if the dedicated user wants to splice out some channel funds, they send the casual user a splice transaction which splices out some of the funds to the dedicated user without requiring a to_self delay. The casual user then signs the splice transaction and returns the signature as part of the check-in.
>
> This approach has a couple potential advantages:
> 1) It allows the dedicated user to splice out funds as soon as the casual user comes online (rather than sometime after the casual user comes online, as shown above). Therefore, the use of capital is made more efficient.
> 2) It allows the splice transaction to pay fees based on the current fee rate, rather than a pre-calculated fee rate.
>
> It does have some potential disadvantages:
> 1) It requires the casual user to stay online long enough to complete the roundtrip of sending a check-in message to the dedicated user, getting the splice message to sign, signing it, and sending the signature back to the dedicated user.
> 2) It assumes that the casual user checks the blockchain themselves, rather than using a watchtower service.
> 3) It requires the dedicated user to decide at the time of the check-in whether or not to perform the splice, as the splice transaction cannot be revoked.
>
> In any case, using a check-in and a non-revokable splice transaction appears to have some advantages in terms of capital efficiency. It's also somewhat more compatible with the WF protocol, as the delay for the dedicated user to obtain spliced-out funds is dependent on the actual time until the casual user next comes online, rather than the worst-case delay until the casual user comes online. This could be a big difference if the casual user is typically online every day, but doesn't want the burden of having to be online every day (or every week). I'm interested in your thoughts on this.
>
> Finally, I understand that the ability to quickly splice out channel funds to improve capital efficiency is critical in the current environment. However, if we eventually get to the point where the blockchain is highly-contested and fees are high, it may no longer be worth paying the fees to put a splice transaction on-chain unless a large amount of capital is at stake for a long period of time.
>
> Regards,
> John
>
>
>
>
> Sent with Proton Mail <https://proton.me/> secure email.
>
> ------- Original Message -------
> On Monday, October 24th, 2022 at 2:50 AM, Bastien TEINTURIER <
> bastien at acinq.fr> wrote:
>
> Hi John,
>
> > My understanding of the current Lightning protocol is that users specify
> a to_self_delay safety parameter which is typically about 2 weeks and that
> they pay for routing, but not for their partner's cost-of-capital. Is that
> correct?
> >
> > If it is, then when a dedicated user (DLU) partners with a casual user
> (CLU), the DLU can only move liquidity to another Lightning channel by
> either:
> > 1) getting the CLU to sign a cooperative close transaction that enables
> (or directly implements) the desired movement of funds, or
> > 2) putting a non-cooperative close transaction on-chain and waiting
> approximately 2 weeks (based on the to_self_delay parameter set by the CLU)
> before moving the liquidity.
>
> That's correct, but that's something we intend to change to let LSPs
> re-allocate their liquidity more frequently and more efficiently.
>
> We don't have a fully specified proposal yet, but by leveraging a
> mechanism similar to splicing [1], mobile users would pre-sign a
> transaction that keeps the channel open, but lets the LSP get their
> balance (or part of it) out non-interactively. This would be used by
> LSPs if the user isn't using their channel actively enough and the LSP
> is low on available liquidity for other, more active users.
>
> This transaction would need to be revokable and must be delayed, since
> we still need the user to be able to punish malicious LSPs, but ideally
> (from the LSP's point of view) that delay should be at most 1 week, which
> forces users to regularly check the blockchain (which isn't ideal).
>
> It really is a trade-off to be able to lower the fees LSPs make users
> pay for liquidity, because LSPs know they can move it cheaply when it
> becomes necessary. I can see a future where users chose their trade-off:
> pay more to be able to go offline for longer periods or pay less but
> check the blockchain regularly. The same LSP could offer both features,
> if they're able to price them correctly (which isn't trivial).
>
> > My intuition is that in the long run, the cost of bitcoin capital will
> be very low, as it is an inherently deflationary monetary unit (and thus
> its value should increase with time). If this is correct, the long term
> cost-of-capital charges should be very low.
>
> I'm not convinced by that...even though the value of capital increases
> with time, liquidity providers will compete to earn more return on their
> locked capital. If one liquidity provider is able to use their capital
> more efficiently than another, they will be able to offer lower prices
> to their customers to a point that isn't economically viable for the
> other, less efficient liquidity provider?
>
> Since lightning doesn't allow any form of fractional reserve, the total
> available capital needs to be split between all existing users of the
> system, which is very inconvenient when trying to onboard a high number
> of new users.
>
> This is very theoretical though, I have absolutely no idea how those
> dynamics will actually play out, but it will be interesting to watch it
> unfold.
>
> Cheers,
> Bastien
>
> [1] https://github.com/lightning/bolts/pull/863
>
> Le mer. 12 oct. 2022 à 02:11, jlspc <jlspc at protonmail.com> a écrit :
>
>>
>> Hey Bastien,
>>
>> Thanks for your reply.
>>
>> Responses are in-line below:
>>
>> > Hey John,
>> >
>> > Thanks for sharing, this is very interesting.
>> >
>> > There is a good insight here that we can remove the intermediate
>> > HTLC-timeout transaction for outgoing payments because we are the
>> > origin of that payment (and thus don't need to quickly claim the
>> > HTLC on-chain to then relay that failure to a matching incoming HTLC).
>> >
>> > More generally, you have perfectly identified that most of the
>> > complexity of today's transactions come from the need to ensure that
>> > a failing/malicious downstream channel doesn't negatively impact
>> > honest upstream channels when relaying payments, and that some of this
>> > complexity can be lifted when nodes don't relay payments.
>>
>> Thanks!
>>
>> > However, my main criticism of your proposal is that liquidity isn't free.
>> > While your improvements are great from the CLU's point of view, I'm not
>> > sure they're acceptable for the DLU. The main (probably only) job of an
>> > LSP (DLU in your terminology) is to efficiently allocate their liquidity.
>> > In order to do so, they must be able to quickly move liquidity from where
>> > it's unused to where it may be better used. That means closely watching
>> > the demand for block space and doing on-chain transactions when fees are
>> > low (to open/close channels, splice funds in/out [1], make peer swaps [2],
>> > etc). With your proposal, DLUs won't be able to quickly move liquidity
>> > around, so the only way to make up for this is to charge the CLU for the
>> > loss of expected revenue. I'm afraid that the amount DLUs would need to
>> > charge CLUs will be prohibitively expensive for most CLUs.
>> >
>> > I'm curious to get your feedback on that point.
>>
>> I really appreciate your insight here. I'm just an interested observer who doesn't have experience with creating and deploying Lightning nodes, so I'm sure you have a better understanding of the current costs and trade-offs than I do.
>>
>> My understanding of the current Lightning protocol is that users specify a to_self_delay safety parameter which is typically about 2 weeks and that they pay for routing, but not for their partner's cost-of-capital. Is that correct?
>>
>> If it is, then when a dedicated user (DLU) partners with a casual user (CLU), the DLU can only move liquidity to another Lightning channel by either:
>> 1) getting the CLU to sign a cooperative close transaction that enables (or directly implements) the desired movement of funds, or
>> 2) putting a non-cooperative close transaction on-chain and waiting approximately 2 weeks (based on the to_self_delay parameter set by the CLU) before moving the liquidity.
>>
>> In contrast, with the Watchtower-Free (WF) protocol, the DLU could only move liquidity to another Lightning channel by either:
>> 1) getting the CLU to sign a cooperative close transaction that enables (or directly implements), the desired movement of funds, or
>> 2) putting a non-cooperative close transaction on-chain and waiting approximately 1-3 months (based on the I_L parameter set by the CLU) before moving the liquidity.
>> In case 1), it would make sense for the DLU to refund the remaining portion of CLU's cost-of-capital pre-payment to the CLU, as that capital is now being made available to the DLU. This was not proposed in the paper, but it should probably be added.
>>
>> With this change (namely refunding the remainder of the cost-of-capital pre-payment), it seems like the only disadvantage of the WF protocol to the DLU is the larger delay (1-3 months vs. 2 weeks). Do you feel increasing the delay from 2 weeks to 1 month is prohibitive?
>>
>> My intuition is that in the long run, the cost of bitcoin capital will be very low, as it is an inherently deflationary monetary unit (and thus its value should increase with time). If this is correct, the long term cost-of-capital charges should be very low.
>>
>> What are your thoughts on this?
>>
>> Thanks,
>> John
>>
>> > Thanks again for sharing, and for the inherited IDs [3] proposal as well!
>> >
>> > Bastien
>> >
>> > [1] <a href="https://github.com/lightning/bolts/pull/863">https://github.com/lightning/bolts/pull/863</a>
>> > [2] <a href="https://www.peerswap.dev/">https://www.peerswap.dev/</a>
>> > [3] <a href="https://github.com/JohnLaw2/btc-iids">https://github.com/JohnLaw2/btc-iids</a>
>>
>>
>> Sent with Proton Mail <https://proton.me/> secure email.
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221102/854dbdd6/attachment-0001.html>

2023-06-09 13:07:10

- reply

📅 Original date posted:2022-10-27
📝 Original message:
Good morning list,
The lightning network transaction format was updated to leverage CPFP
carve-out and allow nodes to set fees at broadcast time, using a feature
called anchor outputs [1].
While desirable, this change brought a whole new set of challenges, by
requiring nodes to maintain a reserve of available utxos for fee-bumping.
Correctly managing this fee-bumping reserve involves a lot of complex
decisions and dynamic risk assessment, because in worst-case scenarios,
a node may need to fee-bump thousands of HTLC transactions in a short
period of time.
This is especially frustrating because HTLC transactions should not need
external inputs, as the whole value of the HTLC is already provided in
its input, which means we could in theory "simply" decrease the amount of
the corresponding output to set the fees to any desired value. However,
we can't do this safely because it doesn't work well with the revocation
mechanism, unless we find fancy new sighash flags to add to bitcoin.
See [2] for a longer rant on this issue.
A very low tech and unsatisfying solution exists, which is what I'm
proposing today: each node can simply sign multiple versions of the
HTLC transactions at various feerates, and at broadcast time if you're
lucky you'll have a pre-signed transaction that approximately matches
the feerate you want, so you don't need to add inputs from your fee
bumping reserve. This reduces the requirements on your on-chain wallet
and simplifies transaction management logic. I believe that it's a
pragmatic approach, even though not very elegant, to increase funds
safety for existing node operators and wallets. I opened a spec PR
that is currently chasing concept ACKs before I refine it [3].
Please let me know what you think, and if this is something that you
would like your implementation to provide.
Thanks,
Bastien
[1] https://github.com/lightning/bolts/pull/688
[2] https://github.com/lightning/bolts/issues/845
[3] https://github.com/lightning/bolts/pull/1036
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221027/df1e8ff5/attachment.html>

2023-06-09 13:07:07

- reply

📅 Original date posted:2022-10-20
📝 Original message:
Hi Joost,
I need more time to review your proposed change, but I wanted to quickly
correct a misunderstanding you had in quoting eclair's code:
> Unfortunately it is possible for nodes on the route to hide themselves.
> If they return random data as the failure message, the sender won't know
> where the failure happened. Some senders then penalize all nodes that
> were part of the route [4][5]. This may exclude perfectly reliable nodes
> from being used for future payments.
Eclair's code does not penalize nodes for future payment attempts in this
case. It only ignores them for the retries of that particular payment.
Cheers,
Bastien
Le mer. 19 oct. 2022 à 13:13, Joost Jager <joost.jager at gmail.com> a écrit :
> Hi list,
>
> I wanted to get back to a long-standing issue in Lightning: gaps in error
> attribution. I've posted about this before back in 2019 [1].
>
> Error attribution is important to properly penalize nodes after a payment
> failure occurs. The goal of the penalty is to give the next attempt a
> better chance at succeeding. In the happy failure flow, the sender is able
> to determine the origin of the failure and penalizes a single node or pair
> of nodes.
>
> Unfortunately it is possible for nodes on the route to hide themselves. If
> they return random data as the failure message, the sender won't know where
> the failure happened. Some senders then penalize all nodes that were part
> of the route [4][5]. This may exclude perfectly reliable nodes from being
> used for future payments. Other senders penalize no nodes at all [6][7],
> which allows the offending node to keep the disruption going.
>
> A special case of this is a final node sending back random data. Senders
> that penalize all nodes will keep looking for alternative routes. But
> because each alternative route still ends with that same final node, the
> sender will ultimately penalize all of its peers and possibly a lot of the
> rest of the network too.
>
> I can think of various reasons for exploiting this weakness. One is just
> plain grievance for whatever reason. Another one is to attract more traffic
> by getting competing routing nodes penalized. Or the goal could be to
> sufficiently mess up reputation tracking of a specific sender node to make
> it hard for that node to make further payments.
>
> Related to this are delays in the path. A node can delay propagating back
> a failure message and the sender won't be able to determine which node did
> it.
>
> The link at the top of this post [1] describes a way to address both
> unreadable failure messages as well as delays by letting each node on the
> route append a timestamp and hmac to the failure message. The great
> challenge is to do this in such a way that nodes don’t learn their position
> in the path.
>
> I'm revisiting this idea, and have prototyped various ways to implement
> it. In the remainder of this post, I will describe the variant that I
> thought works best (so far).
>
> # Failure message format
>
> The basic idea of the new format is to let each node (not just the error
> source) commit to the failure message when it passes it back by adding an
> hmac. The sender verifies all hmacs upon receipt of the failure message.
> This makes it impossible for any of the nodes to modify the failure message
> without revealing that they might have played a part in the modification.
> It won’t be possible for the sender to pinpoint an exact node, because
> either end of a communication channel may have modified the message.
> Pinpointing a pair of nodes however is good enough, and is commonly done
> for regular onion failures too.
>
> On the highest level, the new failure message consists of three parts:
>
> `message` (var len) | `payloads` (fixed len) | `hmacs` (fixed len)
>
> * `message` is the standard onion failure message as described in [2], but
> without the hmac. The hmac is now part of `hmacs` and doesn't need to be
> repeated.
>
> * `payloads` is a fixed length array that contains space for each node
> (`hop_payload`) on the route to add data to return to the sender. Ideally
> the contents and size of `hop_payload` is signaled so that future
> extensions don’t require all nodes to upgrade. For now, we’ll assume the
> following 9-byte format:
>
> `is_final` (1 byte) | `duration` (8 bytes)
>
> `is_final` indicates whether this node is the failure source. The sender
> uses `is_final` to determine when to stop the decryption/verification
> process.
>
> `duration` is the time in milliseconds that the node held the htlc. By
> observing the series of reported durations, the sender is able to pinpoint
> a delay down to a pair of nodes.
>
> The `hop_payload` is repeated 27 times (the maximum route length).
>
> Every hop shifts `payloads` 9 bytes to the right and puts its own
> `hop_payload` in the 9 left-most bytes.
>
> * `hmacs` is a fixed length array where nodes add their hmacs as the
> failure message travels back to the sender.
>
> To keep things simple, I'll describe the format as if the maximum route
> length was only three hops (instead of 27):
>
> `hmac_0_2` | `hmac_0_1`| `hmac_0_0`| `hmac_1_1`| `hmac_1_0`| `hmac_2_0`
>
> Because nodes don't know their position in the path, it's unclear to
> them what part of the failure message they are supposed to include in the
> hmac. They can't just include everything, because if part of that data is
> deleted later (to keep the message size fixed) it opens up the possibility
> for nodes to blame others.
>
> The solution here is to provide hmacs for all possible positions. The
> last node that updated `hmacs` added `hmac_0_2`, `hmac_0_1` and `hmac_0_0`
> to the block. Each hmac corresponds to a presumed position in the path,
> where `hmac_0_2` is for the longest path (2 downstream hops) and `hmac_0_0`
> for the shortest (node is the error source).
>
> `hmac_x_y` is the hmac added by node x (counted from the node that is
> currently handling the failure message) assuming that this node is y hops
> away from the final node.
>
> Before an hop adds its hmacs, it first deletes some of the previous hmacs.
> This keeps the failure message at a fixed length. The removed hmacs are the
> ones that cannot be useful anymore. If node 0 adds itself, the former node
> 0 (now node 1) cannot be at the first position anymore. The former node 1
> (now node 2) cannot be at the second position anymore. The former node 2
> cannot be the source of the error anymore and isn’t represented in the
> failure message any longer. The corresponding hmacs (the now non-existent
> `hmac_0_2`, `hmac_1_1` and `hmac_2_0`) are deleted by node 0.
>
> Deleting the useless data reduces the number of hmacs (and roughly the
> total failure message size) to half.
>
> The delete operation transform the fields above to:
>
> <empty> | <empty> | <empty> | `hmac_0_1`| `hmac_0_0`| `hmac_1_0`
>
> The exact data that is included in each hmac is:
> * `message`
> * the node’s own `hop_payload` and a set of downstream `hop_payload`s,
> depending on assumed position
> * a set of downstream node hmacs, depending on assumed position
>
> For example `hmac_0_1` is based on:
>
> `message` | `hop_payload[0]` | `hop_payload[1]` | `hmac_1_0`
>
> If the node that is currently handling the failure message is one hop away
> from the final node, it needs to cover its own `hop_payload[0]`, the final
> node `hop_payload[1]` and the final node hmac `hmac_1_0`.
>
> A longer path is committed to in `hmac_0_2`:
>
> `message` | `hop_payload[0]` | `hop_payload[1]` | `hop_payload[2]` |
> `hmac_1_1` | `hmac_2_0`
>
> The current node is two hops away from the final node. It needs to cover
> its own `hop_payload[0]` as well as `hop_payload[1]` and `hop_payload[2]`
> for the next and final hops. Additionally it covers the next hop `hmac_1_1`
> and final hop `hmac_2_0`, which correspond to the positions of those nodes
> in the path that is assumed for `hmac_0_2`.
>
> With this information, the sender is able to verify the longest chain of
> hmacs until it encounters a `hop_payload` with `is_final` set.
>
> If any of the nodes messes with any byte in the failure message, the
> sender is always able to determine a pair of nodes that the offending node
> is part of. This statement can be verified through reasoning, but to be
> sure I also tested it with code. I’ve simulated a malicious node that
> modifies a byte of the failure message at index x and observed the error
> source as determined by the sender. For every x, the sender reports the
> same correct pair.
>
> # Size
>
> The obvious downside of the scheme above is the size. Given a maximum of
> 27 hops, the `hmacs` block contains 27+26+25+...+1=378 hmacs of 32 bytes
> each. This makes for a total size of 12 KB.
>
> It could be the case though that it is not possible to devise a more
> compact scheme that also preserves the existing privacy guarantees. I know
> that smart people have spent time on this problem, but nonetheless no
> better solution has come up in the past years. A proof of its non-existence
> would be interesting for sure.
>
> I personally think the size increase is justified to fix this
> vulnerability in Lightning. Also if failures are expected to become more
> rare going forward, size becomes less relevant to the overall operation of
> the network.
>
> Another option is to reduce the maximum number of hops. It is questionable
> whether 27 hops are really needed in practice, and such long routes also
> contribute to latency and capital lock up. If for example the new failure
> message could only be used with routes up to 10 hops, the total number of
> hmacs would drop from 378 to 55. This makes for a total message size of
> about 2 KB.
>
> # Signaling
>
> For backwards compatibility nodes need to know what algorithm they should
> run to generate or transform the failure message. This can be signaled by
> the sender via a tlv onion field. A failure message format signaling
> mechanism is also discussed in the context of long failure messages [3].
> The failure message described in this post could be just another version.
>
> Additionally, intermediate nodes need to advertise their capability to
> transform the new format through a feature bit.
>
> # Delayed successes
>
> It’s not just failures that can be delayed. Successes can too. In that
> case, there is no failure message to improve. It could be an option to add
> the same `payloads` and `hmacs` blocks to the `update_fulfill_htlc` message.
>
> [1]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-June/002015.html
> [2]
> https://github.com/lightning/bolts/blob/master/04-onion-routing.md#returning-errors
> [3] https://github.com/lightning/bolts/pull/1021
> [4]
> https://github.com/lightningnetwork/lnd/blob/4fbd608b734f348d7e79fbfc7feaecc5c6c33a90/routing/result_interpretation.go#L419
> [5]
>
> https://github.com/ACINQ/eclair/blob/a0433aa0c027c9be618c5afe18e7f91642a7f372/eclair-core/src/main/scala/fr/acinq/eclair/payment/PaymentEvents.scala#L221
> [6]
> https://github.com/ElementsProject/lightning/blob/62bfed9a8df8731be44ba4e86afb08a5d28a4442/plugins/libplugin-pay.c#L1461
> [7]
> https://github.com/lightningdevkit/rust-lightning/blob/e61f3a238a70cbac87209e223b7c396108a49b97/lightning-invoice/src/payment.rs#L682
>
> _______________________________________________
> 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/20221020/fd913402/attachment.html>

2023-06-09 13:07:01

- reply

📅 Original date posted:2022-10-24
📝 Original message:
Hi John,
> My understanding of the current Lightning protocol is that users specify
a to_self_delay safety parameter which is typically about 2 weeks and that
they pay for routing, but not for their partner's cost-of-capital. Is that
correct?
>
> If it is, then when a dedicated user (DLU) partners with a casual user
(CLU), the DLU can only move liquidity to another Lightning channel by
either:
> 1) getting the CLU to sign a cooperative close transaction that enables
(or directly implements) the desired movement of funds, or
> 2) putting a non-cooperative close transaction on-chain and waiting
approximately 2 weeks (based on the to_self_delay parameter set by the CLU)
before moving the liquidity.
That's correct, but that's something we intend to change to let LSPs
re-allocate their liquidity more frequently and more efficiently.
We don't have a fully specified proposal yet, but by leveraging a
mechanism similar to splicing [1], mobile users would pre-sign a
transaction that keeps the channel open, but lets the LSP get their
balance (or part of it) out non-interactively. This would be used by
LSPs if the user isn't using their channel actively enough and the LSP
is low on available liquidity for other, more active users.
This transaction would need to be revokable and must be delayed, since
we still need the user to be able to punish malicious LSPs, but ideally
(from the LSP's point of view) that delay should be at most 1 week, which
forces users to regularly check the blockchain (which isn't ideal).
It really is a trade-off to be able to lower the fees LSPs make users
pay for liquidity, because LSPs know they can move it cheaply when it
becomes necessary. I can see a future where users chose their trade-off:
pay more to be able to go offline for longer periods or pay less but
check the blockchain regularly. The same LSP could offer both features,
if they're able to price them correctly (which isn't trivial).
> My intuition is that in the long run, the cost of bitcoin capital will be
very low, as it is an inherently deflationary monetary unit (and thus its
value should increase with time). If this is correct, the long term
cost-of-capital charges should be very low.
I'm not convinced by that...even though the value of capital increases
with time, liquidity providers will compete to earn more return on their
locked capital. If one liquidity provider is able to use their capital
more efficiently than another, they will be able to offer lower prices
to their customers to a point that isn't economically viable for the
other, less efficient liquidity provider?
Since lightning doesn't allow any form of fractional reserve, the total
available capital needs to be split between all existing users of the
system, which is very inconvenient when trying to onboard a high number
of new users.
This is very theoretical though, I have absolutely no idea how those
dynamics will actually play out, but it will be interesting to watch it
unfold.
Cheers,
Bastien
[1] https://github.com/lightning/bolts/pull/863
Le mer. 12 oct. 2022 à 02:11, jlspc <jlspc at protonmail.com> a écrit :
>
> Hey Bastien,
>
> Thanks for your reply.
>
> Responses are in-line below:
>
> > Hey John,
> >
> > Thanks for sharing, this is very interesting.
> >
> > There is a good insight here that we can remove the intermediate
> > HTLC-timeout transaction for outgoing payments because we are the
> > origin of that payment (and thus don't need to quickly claim the
> > HTLC on-chain to then relay that failure to a matching incoming HTLC).
> >
> > More generally, you have perfectly identified that most of the
> > complexity of today's transactions come from the need to ensure that
> > a failing/malicious downstream channel doesn't negatively impact
> > honest upstream channels when relaying payments, and that some of this
> > complexity can be lifted when nodes don't relay payments.
>
> Thanks!
>
> > However, my main criticism of your proposal is that liquidity isn't free.
> > While your improvements are great from the CLU's point of view, I'm not
> > sure they're acceptable for the DLU. The main (probably only) job of an
> > LSP (DLU in your terminology) is to efficiently allocate their liquidity.
> > In order to do so, they must be able to quickly move liquidity from where
> > it's unused to where it may be better used. That means closely watching
> > the demand for block space and doing on-chain transactions when fees are
> > low (to open/close channels, splice funds in/out [1], make peer swaps [2],
> > etc). With your proposal, DLUs won't be able to quickly move liquidity
> > around, so the only way to make up for this is to charge the CLU for the
> > loss of expected revenue. I'm afraid that the amount DLUs would need to
> > charge CLUs will be prohibitively expensive for most CLUs.
> >
> > I'm curious to get your feedback on that point.
>
> I really appreciate your insight here. I'm just an interested observer who doesn't have experience with creating and deploying Lightning nodes, so I'm sure you have a better understanding of the current costs and trade-offs than I do.
>
> My understanding of the current Lightning protocol is that users specify a to_self_delay safety parameter which is typically about 2 weeks and that they pay for routing, but not for their partner's cost-of-capital. Is that correct?
>
> If it is, then when a dedicated user (DLU) partners with a casual user (CLU), the DLU can only move liquidity to another Lightning channel by either:
> 1) getting the CLU to sign a cooperative close transaction that enables (or directly implements) the desired movement of funds, or
> 2) putting a non-cooperative close transaction on-chain and waiting approximately 2 weeks (based on the to_self_delay parameter set by the CLU) before moving the liquidity.
>
> In contrast, with the Watchtower-Free (WF) protocol, the DLU could only move liquidity to another Lightning channel by either:
> 1) getting the CLU to sign a cooperative close transaction that enables (or directly implements), the desired movement of funds, or
> 2) putting a non-cooperative close transaction on-chain and waiting approximately 1-3 months (based on the I_L parameter set by the CLU) before moving the liquidity.
> In case 1), it would make sense for the DLU to refund the remaining portion of CLU's cost-of-capital pre-payment to the CLU, as that capital is now being made available to the DLU. This was not proposed in the paper, but it should probably be added.
>
> With this change (namely refunding the remainder of the cost-of-capital pre-payment), it seems like the only disadvantage of the WF protocol to the DLU is the larger delay (1-3 months vs. 2 weeks). Do you feel increasing the delay from 2 weeks to 1 month is prohibitive?
>
> My intuition is that in the long run, the cost of bitcoin capital will be very low, as it is an inherently deflationary monetary unit (and thus its value should increase with time). If this is correct, the long term cost-of-capital charges should be very low.
>
> What are your thoughts on this?
>
> Thanks,
> John
>
> > Thanks again for sharing, and for the inherited IDs [3] proposal as well!
> >
> > Bastien
> >
> > [1] <a href="https://github.com/lightning/bolts/pull/863">https://github.com/lightning/bolts/pull/863</a>
> > [2] <a href="https://www.peerswap.dev/">https://www.peerswap.dev/</a>
> > [3] <a href="https://github.com/JohnLaw2/btc-iids">https://github.com/JohnLaw2/btc-iids</a>
>
>
> Sent with Proton Mail <https://proton.me/> secure email.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221024/c1713a2e/attachment.html>

2023-06-09 13:06:59

- reply

📅 Original date posted:2022-10-10
📝 Original message:
Hey John,
Thanks for sharing, this is very interesting.
There is a good insight here that we can remove the intermediate
HTLC-timeout transaction for outgoing payments because we are the
origin of that payment (and thus don't need to quickly claim the
HTLC on-chain to then relay that failure to a matching incoming HTLC).
More generally, you have perfectly identified that most of the
complexity of today's transactions come from the need to ensure that
a failing/malicious downstream channel doesn't negatively impact
honest upstream channels when relaying payments, and that some of this
complexity can be lifted when nodes don't relay payments.
However, my main criticism of your proposal is that liquidity isn't free.
While your improvements are great from the CLU's point of view, I'm not
sure they're acceptable for the DLU. The main (probably only) job of an
LSP (DLU in your terminology) is to efficiently allocate their liquidity.
In order to do so, they must be able to quickly move liquidity from where
it's unused to where it may be better used. That means closely watching
the demand for block space and doing on-chain transactions when fees are
low (to open/close channels, splice funds in/out [1], make peer swaps [2],
etc). With your proposal, DLUs won't be able to quickly move liquidity
around, so the only way to make up for this is to charge the CLU for the
loss of expected revenue. I'm afraid that the amount DLUs would need to
charge CLUs will be prohibitively expensive for most CLUs.
I'm curious to get your feedback on that point.
Thanks again for sharing, and for the inherited IDs [3] proposal as well!
Bastien
[1] https://github.com/lightning/bolts/pull/863
[2] https://www.peerswap.dev/
[3] https://github.com/JohnLaw2/btc-iids
Le lun. 3 oct. 2022 à 18:55, jlspc via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> a écrit :
>
> This is the first in a series of posts on ideas to improve the usability
> and scalability of the Lightning Network. This post presents a new channel
> protocol that allows casual users to send and receive Lightning payments
> without having to meet onerous availability requirements or use a
> watchtower service. This new Watchtower-Free (WF) protocol can also be
> used to simplify the reception of Lightning payments for casual users. No
> change to the underlying Bitcoin protocol is required.
>
> A paper with a more complete description of the protocol, including
> figures, is available [5].
>
> Properties
> ==========
>
> The user-visible properties of the WF protocol can be expressed using
> two parameters:
> * I_S: a short time interval (e.g., 10 minutes) for communicating with
> peers, checking the blockchain, and submitting transactions to the
> blockchain, and
> * I_L: a long time interval (e.g., 1-3 months).
>
> The casual user must be online for up to:
> * I_S every I_L (e.g., 10 minutes every 1-3 months) to safeguard the funds
> in their Lightning channel.
>
> With the WF protocol, the latency for payments is unchanged from the
> current protocol, but the latency for getting a payment receipt from an
> uncooperative channel partner is increased. In addition, the casual user
> may have to pay their channel partner for the partner's cost of capital
> (which depends on I_L). If the casual user and their channel partner
> follow the protocol, the channel can remain off-chain arbitrarily long.
>
> First Attempt: Use The Current Lightning Protocol
> =================================================
>
> In order to motivate the new protocol, first consider what would happen if
> a casual user attempted to achieve the above properties with the current
> Lightning channel protocol. The casual user would set their
> "to_self_delay" (which controls how quickly their channel partner can
> receive funds from a transaction they put on-chain) and
> "cltv_expiry_delta" (which controls the staggering of timeouts between
> successive hops) parameters to values approaching I_L (because the casual
> user could be unavailable for nearly that long). This would create three
> problems:
>
> * Problem 1: The casual user's proposed channel partner would likely
> reject the creation of the channel due to the excessive "to_self_delay"
> value.
>
> * Problem 2: If a channel were created with these parameters, Lightning
> payments would not be routed through it due to the excessive
> "cltv_expiry_delta" value.
>
> * Problem 3: If a channel were created with these parameters and if the
> casual user sent a payment on that channel, their partner could have to
> go on-chain in order to pull the payment from the casual user. In
> particular, the casual user could be offline for nearly I_L (e.g., 1-3
> months) when their partner receives the receipt, thus forcing their
> partner to go on-chain to receive payment before the expiry of the
> associated HTLC.
>
> The WF Protocol
> ===============
>
> The WF protocol solves these problems by modifying the Lightning protocol
> as follows:
>
> * Problem 1 is solved by having the casual user pre-pay their channel
> partner for the cost of the partner's capital that's tied up in the
> channel due to the very large "to_self_delay" value. This pre-payment is
> included in the initial channel state and is updated at least once every
> I_L to reflect the additional cost of capital due to the partner not yet
> going on-chain.
>
> * Problem 2 is solved by allowing casual users to designate themselves as
> Casual-Lightning-Users (CLUs), while the remaining users are
> Dedicated-Lightning-Users (DLUs). CLUs can only partner with DLUs to
> open channels, such channels must be unannounced, and CLUs must not
> route (as opposed to send or receive) payments. These constraints fit
> naturally with the desires of casual users who want to send and receive
> their Lightning payments, but not route payments for others. Support for
> CLUs is analogous to support for SPV (Simplified-Payment-Verification)
> nodes in Bitcoin.
>
> * Problem 3 is solved by modifying both users' Commitment transactions in
> the channel that sends the payment so the CLU can be offline for nearly
> I_L without forcing their DLU partner to go on-chain. A simple approach
> would be to delay the expiry of the HTLC for each payment in the sending
> channel by I_L. This approach works, but it has the downside of delaying
> (by I_L) the CLU's ability to force production of a payment receipt. A
> better approach is to add a relative delay before the CLU can time out
> the HTLC output of a Commitment transaction, thus enabling the DLU to
> safely stay off-chain even after the expiry of the HTLC. That's the
> approach taken here.
>
> Let Alice be a CLU who shares a channel with DLU Bob. Bob sets his channel
> parameters as he would in the current Lightning protocol, while Alice sets
> her "to_self_delay" parameter (controlling Bob's payments to himself) to
> I_L greater than it would be in the current Lightning protocol. Consider
> the case where Alice sends a Lightning payment on the channel she shares
> with Bob.
>
> Let:
> - eAB denote the expiry for this payment in the channel shared by Alice
> and Bob,
> - tsdA denote the "to_self_delay" parameter set by Alice, and
> - tsdB denote the "to_self_delay" parameter set by Bob.
>
> Three changes are made relative to the current Lightning protocol:
> - a relative delay of tsdB is enforced before Alice can spend the HTLC
> output for this payment in either Commitment transaction,
> - after eAB, only Alice's (rather than both parties') signature is
> required to spend the HTLC output in Alice's Commitment transaction,
> and that output doesn't need to be spent using an HTLC-timeout
> transaction that can be revoked (because the relative delay added
> above guarantees Bob can prevent Alice from spending the HTLC output
> in a revoked Commitment transaction that she puts on-chain), and
> - both parties update the channel state off-chain at least once every
> I_L to reflect Bob's cost of capital, as described above.
>
> The resulting protocol, with a single payment from Alice outstanding, is
> shown below:
>
> +-+ AB +----+ A
> |F|----+--->| CC |--->
> +-+ | | |
> . | | B
> . | |--->
> . +----+
> |
> |
> | revkeyBi
> | +---------->
> | |
> | +----+ | tsdB & A
> +--->|C_Ai|--+---------->
> | | |
> | | | B
> | | |------------->
> | | |
> | | | revkeyBi
> | | | +---------->
> | | | |
> | | | | tsdB & (eAB) & A
> | | |--+------------------->
> | +----+ |
> | | Preimage(X) & B
> | +------------------->
> |
> |
> |
> | revkeyAi
> | +---------->
> | |
> | +----+ | tsdA & B
> +--->|C_Bi|--+---------->
> | | |
> | | | A
> | | |------------->
> | | |
> | | | revkeyAi
> | | | +---------->
> . | | |
> . | | | tsdB & (eAB) & A revkeyAi
> . | |--+-------------------> +---------->
> | +----+ | |
> | | Preimage(X) & AB +-----+ | tsdA & B
> V +------------------->|Hs_Bi|--+---------->
> +-----+
>
> where:
> F is the Funding transaction,
> CC is the Cooperative Close transaction,
> C_Ai is Alice's Commitment transaction for state i,
> C_Bi is Bob's Commitment transaction for state i, and
> Hs_Bi is Bob's HTLC-success transaction for state i.
>
> The F transaction is on-chain, while the remaining transactions are
> off-chain during normal protocol operation.
>
> Requirements for output cases are as follows:
> A: Alice's signature,
> B: Bob's signature,
> AB: Alice's and Bob's signatures,
> revkeyAi: a signature using a revocation key that Alice can use to revoke
> Bob's state i transaction,
> revkeyBi: a signature using a revocation key that Bob can use to revoke
> Alice's state i transaction,
> tsdA: a relative delay equal to Alice's to_self_delay parameter,
> tsdB: a relative delay equal to Bob's to_self_delay parameter,
> (eAB): an absolute timelock equal to the expiry of the outstanding HTLC
> offered by Alice, and
> Preimage(X): the hash preimage of X.
>
> Once Bob knows Preimage(X), he sends Preimage(X) to Alice and attempts to
> update both parties' Commitment transactions to show payment of the HTLC.
> If he has spent I_L time unsuccessfully trying to update those Commitment
> transactions, he can submit his Commitment and HTLC-success transactions
> to the blockchain. If at any point he sees Alice's Commitment transaction
> on-chain, he stops trying to update the Commitment transactions off-chain
> and he puts his transaction that reveals Preimage(X) and spends the HTLC
> output in her Commitment transaction on-chain as soon as possible.
>
> Alice implements the WF channel protocol as she would the current
> Lightning channel protocol, except:
> - she can choose to be intentionally unavailable, provided she is
> available (or at least not intentionally unavailable) for at least I_S
> every I_L (to update her pre-payment for Bob's cost of capital and to
> revoke any old transactions put on-chain by Bob), and
> - she does not put her Commitment transaction on-chain until she has
> been available (or at least not intentionally unavailable) for at least
> a grace period of G following the expiry of her offered HTLC (where G
> is the same grace period as is used in the current Lightning protocol
> and G <= I_S).
>
> Correctness
> ===========
>
> When Alice sends a payment on the channel she shares with Bob, the WF
> protocol matches the Lightning protocol except the parties stay off-chain
> longer with the WF protocol (to accommodate Alice's intentional
> unavailability). Staying off-chain longer is safe for Alice, as she
> originated the payment and thus does not have to time out the HTLC at any
> specific time in order receive payment in an earlier hop. Staying
> off-chain longer is also safe for Bob, because whenever Alice's (or Bob's)
> Commitment transaction is put on-chain, the tsdB relative delay before
> Alice can time out the HTLC output is long enough to allow Bob to put his
> transaction on-chain that takes payment for the HTLC.
>
> Finally, the WF protocol requires that Alice and Bob stay off-chain long
> enough to guarantee that Alice will be available (or at least not
> intentionally unavailable) for at least G, which is sufficient for both
> parties to update the channel state off-chain. As a result, if both
> parties follow the protocol, the channel will remain off-chain despite
> Alice's intentional unavailability.
>
> A more detailed proof of correctness is given in the paper [5].
>
> One-Shot Receives
> =================
>
> While eliminating watchtowers is helpful for casual users, the protocol
> for receiving Lightning payments could still be awkward for such users.
> With the current Lightning protocol, when a user receives a payment and
> their channel partner is unresponsive, the user must submit their
> Commitment and HTLC-success transactions to the blockchain. However, if
> their partner's conflicting Commitment transaction wins the race and is
> included in the blockchain, the user then has to submit a different
> transaction that reveals the HTLC's secret and spends the HTLC output in
> their partner's Commitment transaction. The requirement to wait and check
> the blockchain for the winning Commitment transaction (which might not be
> determined until multiple blocks have been added to the blockchain) is
> awkward for a casual user. It would be far preferable if the casual user
> could always receive a payment by performing a sequence of off-chain
> message exchanges and at most one submission to the blockchain. A protocol
> that has this property will be said to support "one-shot receives".
>
> The WF protocol can be made to support one-short receives (and to simplify
> the process of getting a receipt) for CLU Alice by making the following
> change whenever a new Commitment transaction for DLU Bob is signed by
> Alice:
> - if Bob has one or more outstanding HTLCs offered to Alice, the
> nLocktime field of Bob's Commitment transaction is set to the expiry of
> the earliest such HTLC,
> - otherwise, the nLocktime field of Bob's Commitment transaction is set
> to I_L in the future (relative to when Bob's Commitment transaction is
> signed by Alice).
>
> Before examining how this change supports one-shot receives, it's
> important to resolve a technical issue. In the current Lightning protocol,
> the nLocktime field in the Commitment transaction provides 24 bits of the
> channel's state number in order to allow efficient revocation of old
> on-chain Commitments (with the remaining 24 bits being provided by the
> nSequence field of the Commitment transaction's sole input). Because we're
> now using the nLocktime field to enforce an absolute timelock, those 24
> bits of state number can no longer be encoded in the nLocktime field.
> There are two solutions to this problem:
> - add a second input to Bob's Commitment transaction that spends a UTXO
> owned by Bob (the value of which is arbitrary and is refunded to Bob in
> the Commitment transaction) and use the nSequence field of that input
> to encode 24 bits of state number, or
> - support only 24-bit state numbers, as 16 million channel states are
> likely sufficient for most casual users.
>
> In addition, the following constraints are added in order to guarantee
> one-shot receives:
> 1. Whenever a new HTLC is offered to Alice, its expiry is set to exactly
> her min_final_cltv_expiry parameter in the future. This constraint
> guarantees that new HTLCs have expiries that are monotonically
> nondecreasing.
> 2. Whenever Alice gives Bob a secret for an HTLC, that HTLC has the
> earliest expiry of all the HTLCs in Alice's current Commitment
> transaction.
> 3. Whenever a new channel state i+1 is created, Alice's partial signature
> for Bob's Commitment transaction for state i+1 is given to Bob, and the
> revocation key for Bob's Commitment transaction for state i is given to
> Alice, before Bob's partial signature for Alice's Commitment
> transaction for state i+1 is given to Alice.
>
> Given these constraints and the setting of the nLocktime field in Bob's
> Commitment transaction, Alice can always put her Commitment transaction
> on-chain before Bob can put a conflicting current Commitment transaction
> on-chain, thus providing one-shot receives. The details are provided in
> the paper [5].
>
> Finally, it's important to verify that the delay of Bob's Commitment
> transaction (caused by the setting of its nLocktime field) does not create
> any problems for Bob. First, for HTLCs offered to Alice (that is, payments
> received by Alice), the current Lightning protocol requires that Bob wait
> until after the expiry of his offered HTLC before he goes on-chain with
> his Commitment and HTLC-timeout transactions. Therefore, the nLocktime
> field has no impact on Bob's actions regarding HTLCs offered to Alice.
> Second, for HTLCs offered by Alice (that is, payments sent by Alice), the
> WF protocol does not force Bob to put his Commitment and associated
> HTLC-success transactions on-chain before any specific time in order
> guarantee the success of any HTLCs. As a result, Bob's ability to force
> payment for HTLCs offered by Alice is unaffected by the nLocktime field in
> his Commitment transactions. Note that the Lightning protocol does
> require Bob to put his Commitment and associated HTLC-success transactions
> on-chain by a specific time, which is why the changes described here
> cannot be made to the Lightning protocol to support one-shot receives.
>
> Getting A Payment Receipt
> =========================
>
> Consider again the case where casual user Alice has offered an HTLC to
> Bob. At any time after the expiry of the HTLC, if Alice needs to get a
> payment receipt and Bob is uncooperative, Alice can put her Commitment
> transaction on-chain and then attempt to spend the HTLC output of her
> Commitment transaction tsdB later. As was shown above, she is guaranteed
> to win the race in putting her Commitment transaction on-chain due to the
> nLocktime field in Bob's Commitment transaction. Therefore, she will
> either get her receipt before she is able to spend the HTLC output or she
> will not have to make her payment (because she succeeded in spending the
> HTLC output). This procedure for getting a payment receipt isn't one-shot
> and may be awkward for casual users. Fortunately, it's only required when
> there's both a payment dispute (or other need to get a receipt quickly)
> and an uncooperative channel partner.
>
> Asynchronous Payments
> =====================
>
> The WF protocol gives significant flexibility to when CLUs have to be
> online, but it still requires that the sender and receiver are both online
> simultaneously. This requirement can be eliminated by keeping the relative
> delay but removing the absolute delay in Alice's transaction that times
> out an HTLC for a payment that she initiates. The details are given in the
> paper [5].
>
> Related Work
> ============
>
> The protocol presented here is based extensively on previously-published
> work, namely the Poon-Dryja Lightning channel protocol [1] and the BOLT
> specifications [2]. The asynchronous payments protocol is based on
> Corallo's proposal for sending tips to an offline receiver [3], but
> differs by using only a relative delay in the sender's HTLC.
>
> The idea of eliminating watchtowers for a casual user by delaying their
> partner's ability to put transactions on-chain was described by Law [4],
> but the interaction of that delay with HTLCs was not analyzed and that
> paper assumed modifications to the underlying Bitcoin protocol.
>
> Conclusions
> ===========
>
> This post presents the idea of dividing users into Casual-Lightning-Users
> (CLUs) that only send and receive payments, and Dedicated-Lightning-Users
> (DLUs) that can also route payments. It gives a new protocol that allows
> casual users to send and receive Lightning payments in a trust-free manner
> without requiring a watchtower service. It also allows CLUs to receive
> payments in a one-shot manner (that is, without having to wait for blocks
> to be added to the blockchain). No changes to the Bitcoin protocol are
> required.
>
> The new protocol does have some disadvantages, such as increasing the cost
> of capital for DLUs that partner with CLUs and increasing the latency for
> CLUs to get payment receipts from uncooperative partners. Hopefully, the
> elimination of watchtowers for casual users, and their ability to do
> one-shot receives, will more than make up for these drawbacks.
>
> I'm not an expert in the area, so I might have missed something.
>
> Corrections and comments are greatly appreciated.
>
> Regards,
> John
>
> References
> ==========
>
> [1] Poon and Dryja, The Bitcoin Lightning Network, available at
> https://lightning.network/lightning-network-paper.pdf.
> [2] BOLT specifications, available at
> https://github.com/lightningnetwork/lightning-rfc.
> [3] Corallo, A Mobile Lightning User Goes to Pay a Mobile Lightning
> User..., available at
https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-October/003307.html
.
> [4] Law, Section 3.6 of Scaling Bitcoin With Inherited IDs, available at
> https://github.com/JohnLaw2/btc-iids.
> [5] Law, Watchtower-Free Lightning Channels For Casual Users, available at
> https://github.com/JohnLaw2/ln-watchtower-free.
>
>
>
>
> Sent with Proton Mail secure email.
> _______________________________________________
> 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/20221010/f0698834/attachment-0001.html>

2023-06-09 13:06:38

- reply

📅 Original date posted:2022-07-26
📝 Original message:
Hey all,
Thanks for the comments!
Here are a few answers inline to some points that aren't fully addressed
yet.
@laolu
> Another question on my mind is: if this works really well for rate
limiting of
> onion messages, then why can't we use it for HTLCs as well?
Because HTLC DoS is fundamentally different: the culprit isn't always
upstream, most of the time it's downstream (holding an HTLC), so back
pressure cannot work.
Onion messages don't have this issue at all because there's no
equivalent to holding an onion message downstream, it doesn't have
any impact on previous intermediate nodes.
@ariard
> as the onion messages routing is source-based, an attacker could
> exhaust or reduce targeted onion communication channels to prevent
> invoices exchanges between LN peers
Can you detail how? That's exactly what this scheme is trying to prevent.
This looks similar to Joost's early comment, but I think it's based on a
misunderstanding of the proposal (as Joost then acknowledged). Spammers
will be statistically penalized, which will allow honest messages to go
through. As Joost details below, attackers with perfect information about
the state of rate-limits can in theory saturate links, but in practice I
believe this cannot work for an extended period of time.
@joost
Cool work with the simulation, thanks!
Let us know if that yields other interesting results.
Cheers,
Bastien
Le lun. 11 juil. 2022 à 11:09, Joost Jager <joost.jager at gmail.com> a écrit :
> On Sun, Jul 10, 2022 at 9:14 PM Matt Corallo <lf-lists at mattcorallo.com>
> wrote:
>
>> > It can also be considered a bad thing that DoS ability is not based on
>> a number of messages. It
>> > means that for the one time cost of channel open/close, the attacker
>> can generate spam forever if
>> > they stay right below the rate limit.
>>
>> I don't see why this is a problem? This seems to assume some kind of
>> per-message cost that nodes
>> have to bear, but there is simply no such thing. Indeed, if message spam
>> causes denial of service to
>> other network participants, this would be an issue, but an attacker
>> generating spam from one
>> specific location within the network should not cause that, given some
>> form of backpressure within
>> the network.
>>
>
> It's more a general observation that an attacker can open a set of
> channels in multiple locations once and can use them forever to support
> potential attacks. That is assuming attacks aren't entirely thwarted with
> backpressure.
>
>
>> > Suppose the attacker has enough channels to hit the rate limit on an
>> important connection some hops
>> > away from themselves. They can then sustain that attack indefinitely,
>> assuming that they stay below
>> > the rate limit on the routes towards the target connection. What will
>> the response be in that case?
>> > Will node operators work together to try to trace back to the source
>> and take down the attacker?
>> > That requires operators to know each other.
>>
>> No it doesn't, backpressure works totally fine and automatically applies
>> pressure backwards until
>> nodes, in an automated fashion, are appropriately ratelimiting the source
>> of the traffic.
>>
>
> Turns out I did not actually fully understand the proposal. This version
> of backpressure is nice indeed.
>
> To get a better feel for how it works, I've coded up a simple single node
> simulation (
> https://gist.github.com/joostjager/bca727bdd4fc806e4c0050e12838ffa3),
> which produces output like this:
> https://gist.github.com/joostjager/682c4232c69f3c19ec41d7dd4643bb27.
> There are a few spammers and one real user. You can see that after some
> time, the spammers are all throttled down and the user packets keep being
> handled.
>
> If you add enough spammers, they are obviously still able to hit the next
> hop rate limit and affect the user. But because their incoming limits have
> been throttled down, you need a lot of them - depending on the minimum rate
> that the node goes down to.
>
> I am wondering about that spiraling-down effect for legitimate users. Once
> you hit the limit, it is decreased and it becomes easier to hit it again.
> If you don't adapt, you'll end up with a very low rate. You need to take a
> break to recover from that. I guess the assumption is that legitimate users
> never end up there, because the rate limits are much much higher than what
> they need. Even if they'd occasionally hit a limit on a busy connection,
> they can go through a lot of halvings before they'll get close to the rate
> that they require and it becomes a problem.
>
> But how would that work if the user only has a single channel and wants to
> retry? I suppose they need to be careful to use a long enough delay to not
> get into that down-spiral. But how do they determine what is long enough?
> Probably not a real problem in practice with network latency etc, even
> though a concrete value does need to be picked.
>
> Spammers are probably also not going to spam at max speed. They'd want to
> avoid their rate limit being slashed. In the simulation, I've added a
> `perfectSpammers` mode that creates spammers that have complete information
> on the state of the rate limiter. Not possible in reality of course. If you
> enable this mode, it does get hard for the user. Spammers keep pushing the
> limiter to right below the tripping point and an unknowing user trips it
> and spirals down. (
> https://gist.github.com/joostjager/6eef1de0cf53b5314f5336acf2b2a48a)
>
> I don't know to what extent spammers without perfect information can still
> be smart and optimize their spam rate. They can probably do better than
> keep sending at max speed.
>
> > Maybe this is a difference between lightning network and the internet
>> that is relevant for this
>> > discussion. That routers on the internet know each other and have
>> physical links between them, where
>> > as in lightning ties can be much looser.
>>
>> No? The internet does not work by ISPs calling each other up on the phone
>> to apply backpressure
>> manually whenever someone sends a lot of traffic? If anything lightning
>> ties between nodes are much,
>> much stronger than ISPs on the internet - you generally are at least
>> loosely trusting your peer with
>> your money, not just your customer's customer's bits.
>>
>
> Haha, okay, yes, I actually don't know what ISPs do in case of DoS
> attacks. Just trying to find differences between lightning and the internet
> that could be relevant for this discussion.
>
> Seems to me that lightning's onion routing makes it hard to trace back to
> the source without node operators calling each other up. Harder than it is
> on the internet. Of course if backpressure works, you don't need to trace
> nothing so it all doesn't matter.
>
> > Another question on my mind is: if this works really well for rate
>> limiting of
>> > onion messages, then why can't we use it for HTLCs as well?
>
>
>
> We do? 400-some-odd HTLCs in flight at once is a *really* tight rate
>> limit, even! Order of
>> magnitudes tighter than onion message rate limits need to be :)
>
>
> What we don't yet do is create backpressure on the incoming channels by
> lowering the `max_pending_htlc` limit dynamically.
>
> The idea could also be extended to htlc forwarding rate limiters, to
> combat short-lived htlc spam.
>
> Joost
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220726/c52eaf33/attachment.html>

2023-06-09 13:06:32

- reply

📅 Original date posted:2022-07-01
📝 Original message:
Hi Joost,
> isn't it the case that it is always possible to DoS your peer by just
rejecting any forward that comes in from them?
Yes, this is a good point. But there is a difference though. If you do that
with inbound fees, the "malicious" peer is able to prevent _everyone_ from
even trying to route through you (because it's advertised).
Whereas if they selectively fail HTLCs you forward to them, only the payer
for
that HTLC knows about it, and they can attribute the failure to the
malicious
node, not to you.
Of course, that malicious node could also withhold the HTLC or return a
malformed error, but unfortunately we cannot easily protect against this.
My point is that this is bad behavior, and we shouldn't be giving more
tools for nodes to misbehave, and inbound fees are a very powerful tool
to help misbehaving nodes.
> Or indirectly affecting them negatively by setting high fees on all
outbound channels?
This case is completely different, because the "malicious" node can't
selectively
advertise that, it will affect traffic coming from all of their peers so
they
would really be shooting themselves in the foot if they did that.
> My thinking is that if I accept an incoming htlc, my local balance
increases
> on that incoming channel. My money gets locked up in a channel that may or
> may not be interesting to me. Wouldn't it be fair to be compensated for
that?
If that channel isn't interesting to you, then by all means you should fail
that HTLC or close the channel? Or you shouldn't have accepted it in the
first place?
I understand the will to optimize revenue here, but I fear this concrete
proposal leads to many kinds of unhealthy incentives. I agree that there is
a
risk in accepting channels from unknown nodes, but I think it should be
addressed differently: you could for example make the opener pay a fee when
they open a channel to you to compensate that risk (some kind of reversed
liquidity ads).
Cheers,
Bastien
Le ven. 1 juil. 2022 à 14:17, Thomas HUET <thomas.huet at acinq.fr> a écrit :
> Hi Joost,
>
> It was discussed in this issue:
> https://github.com/lightning/bolts/issues/835
>
> On the network, the traffic is not balanced. Some nodes tend to receive
> more than they send, merchants for instance. For the lightning network to
> be reliable, we need to incentivise people to open channels to such nodes,
> or else there won't be enough liquidity available and payments will fail.
> The current fee structure provides this incentive: You pay some onchain
> fees and lock some funds and in exchange you will earn routing fees. My
> concern is that your proposed change would break that incentive and make
> the network less reliable.
>
> Thomas
>
> Le ven. 1 juil. 2022 à 14:02, Joost Jager <joost.jager at gmail.com> a
> écrit :
>
>> Hi Bastien,
>>
>> I vaguely remembered that the idea of inbound fees had been discussed
>> before. Before writing my post, I scanned through old ML posts and bolts
>> issues but couldn't find the discussion. Maybe it was part of a different
>> but related email or a bolts pr?
>>
>> With regards to your objections, isn't it the case that it is always
>> possible to DoS your peer by just rejecting any forward that comes in from
>> them? Or indirectly affecting them negatively by setting high fees on all
>> outbound channels? To me it seems that there is nothing to lose by adding
>> inbound fees.
>>
>> My thinking is that if I accept an incoming htlc, my local balance
>> increases on that incoming channel. My money gets locked up in a channel
>> that may or may not be interesting to me. Wouldn't it be fair to be
>> compensated for that?
>>
>> Any thoughts from routing node operators would be welcome too (or links
>> to previous threads).
>>
>> Joost
>>
>> On Fri, Jul 1, 2022 at 1:19 PM Bastien TEINTURIER <bastien at acinq.fr>
>> wrote:
>>
>>> Hi Joost,
>>>
>>> As I've already stated every time this has been previously discussed, I
>>> believe
>>> this doesn't make any sense. The funds that are on the other side of the
>>> channel belong to your peer, not you, so they're free to use it however
>>> they
>>> want. If you're not happy with the way your peer is managing their fees,
>>> then
>>> don't open channels to them and let the network decide whether you're
>>> right or
>>> not.
>>>
>>> Moreover, you shouldn't care at all. If all the funds are on your peer's
>>> side,
>>> this isn't your problem, you used up all the money that was yours. As
>>> long as
>>> the channel is open, this is free inbound liquidity for you, so you're
>>> even
>>> benefiting from this.
>>>
>>> If Alice could set fees for Bob's side of the channel, Alice could
>>> arbitrarily
>>> DoS Bob's payments by setting a high fee. This is just one example of
>>> the many
>>> ways this idea completely breaks the routing incentives.
>>>
>>> Cheers,
>>> Bastien
>>>
>>> Le ven. 1 juil. 2022 à 13:10, Joost Jager <joost.jager at gmail.com> a
>>> écrit :
>>>
>>>> Path-finding algorithms that are currently in use generally don’t
>>>>> support negative fees. But in this case, the sum of inbound and outbound
>>>>> fees is still positive and therefore not a problem. If routing nodes set
>>>>> their policies accidentally or intentionally so that the sum of fees turns
>>>>> out negative, senders can just round up to zero and find a path as normal.
>>>>>
>>>>
>>>> Correction to this:
>>>>
>>>> The sum of inbound and outbound are not the fees set by one single
>>>> routing node. When path-finding considers a candidate hop, this adds the
>>>> outbound fee of the "from" node and the inbound fee of the "to" node.
>>>> Because those nodes don't necessarily coordinate fees, it may happen more
>>>> often that the fee goes negative. Rounding up to zero is still a quick fix
>>>> and better than ignoring inbound fees completely.
>>>> _______________________________________________
>>>> 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/20220701/c3c96202/attachment-0001.html>

2023-06-09 13:06:31

- reply

📅 Original date posted:2022-07-01
📝 Original message:
Hi Joost,
As I've already stated every time this has been previously discussed, I
believe
this doesn't make any sense. The funds that are on the other side of the
channel belong to your peer, not you, so they're free to use it however they
want. If you're not happy with the way your peer is managing their fees,
then
don't open channels to them and let the network decide whether you're right
or
not.
Moreover, you shouldn't care at all. If all the funds are on your peer's
side,
this isn't your problem, you used up all the money that was yours. As long
as
the channel is open, this is free inbound liquidity for you, so you're even
benefiting from this.
If Alice could set fees for Bob's side of the channel, Alice could
arbitrarily
DoS Bob's payments by setting a high fee. This is just one example of the
many
ways this idea completely breaks the routing incentives.
Cheers,
Bastien
Le ven. 1 juil. 2022 à 13:10, Joost Jager <joost.jager at gmail.com> a écrit :
> Path-finding algorithms that are currently in use generally don’t support
>> negative fees. But in this case, the sum of inbound and outbound fees is
>> still positive and therefore not a problem. If routing nodes set their
>> policies accidentally or intentionally so that the sum of fees turns out
>> negative, senders can just round up to zero and find a path as normal.
>>
>
> Correction to this:
>
> The sum of inbound and outbound are not the fees set by one single routing
> node. When path-finding considers a candidate hop, this adds the outbound
> fee of the "from" node and the inbound fee of the "to" node. Because those
> nodes don't necessarily coordinate fees, it may happen more often that the
> fee goes negative. Rounding up to zero is still a quick fix and better than
> ignoring inbound fees completely.
> _______________________________________________
> 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/20220701/6b0313dc/attachment.html>

2023-06-09 13:06:27

- reply

📅 Original date posted:2022-06-30
📝 Original message:
Thanks for your inputs!
One issue I see w/ the first category is that a single party can flood the
> network and cause nodes to trigger their rate limits, which then affects
> the
> usability of the onion messages for all other well-behaving parties.
>
But that's exactly what this proposal addresses? That single party can
only flood for a very small amount of time before being rate-limited for
a while, so it cannot disrupt other parties that much (to be properly
quantified by research, but it seems quite intuitive).
W.r.t this topic, one event that imo is worth pointing out is that a very
> popular onion routing system, Tor, has been facing a severe DDoS attack
> that
> has lasted weeks, and isn't yet fully resolved [2].
>
I don't think we can compare lightning to Tor, the only common design
is that there is onion encryption, but the networking parts are very
different (and the attack vectors on Tor are mostly on components that
don't exist in lightning).
I can only assume that the desire to add a cost to onion messages
ultimately stems from a desire to ensure every possible avenue for
value extraction is given to routing nodes
>
I think that Matt is pointing out the main distinction here between the
two proposals. While I can sympathize with that goal, I agree with
Matt that it's probably misplaced here (and that proposal is orders of
magnitude more complex than a simple rate-limit).
I do think any spec for this shouldn't make any recommendations about
> willingness to relay onion
> messages for anonymous no-channel third parties, if anything deliberately
> staying mum on it and
> allowing nodes to adapt policy (and probably rate-limit no-channel
> third-parties before they rate
> limit any peer they have a channel with). Ultimately, we have to assume
> that nodes will attempt to
> send onion messages by routing through the existing channel graph, so
> there's little reason to worry
> too much about ensuring ability to relay for anonymous parties.
>
Sounds good, I'll do that when actually specifying this in a bolt.
> Better yet, as Val points out, requiring a channel to relay onion
> messages puts a very real,
nontrivial (in a world of msats) cost to getting an onion messaging
> channel.
Yes, this is the main component that does efficiently protect against DoS.
At some point if a peer keeps exceeding their onion rate-limits and isn't
providing you with enough HTLCs to relay, you can force-close on them,
which makes that cost real and stops the spamming attempts for a while.
Cheers,
Bastien
Le jeu. 30 juin 2022 à 04:19, Matt Corallo <lf-lists at mattcorallo.com> a
écrit :
> Thanks Bastien for writing this up! This is a pretty trivial and
> straightforward way to rate-limit
> onion messages in a way that allows legitimate users to continue using the
> system in spite of some
> bad actors trying (and failing, due to being rate-limited) to DoS the
> network.
>
> I do think any spec for this shouldn't make any recommendations about
> willingness to relay onion
> messages for anonymous no-channel third parties, if anything deliberately
> staying mum on it and
> allowing nodes to adapt policy (and probably rate-limit no-channel
> third-parties before they rate
> limit any peer they have a channel with). Ultimately, we have to assume
> that nodes will attempt to
> send onion messages by routing through the existing channel graph, so
> there's little reason to worry
> too much about ensuring ability to relay for anonymous parties.
>
> Better yet, as Val points out, requiring a channel to relay onion messages
> puts a very real,
> nontrivial (in a world of msats) cost to getting an onion messaging
> channel. Better yet, with
> backpressure ability to DoS onion message links isn't denominated in
> number of messages, but instead
> in number of channels you are able to create, making the backpressure
> system equivalent to today's
> HTLC DoS considerations, whereas explicit payment allows an attacker to
> pay much less to break the
> system.
>
> As for the proposal to charge for onion messages, I'm still not at all
> sure where its coming from.
> It seems to flow from a classic "have a hammer (a system to make
> micropayments for things), better
> turn this problem into a nail (by making users pay for it)" approach, but
> it doesn't actually solve
> the problem at hand.
>
> Even if you charge for onion messages, users may legitimately want to send
> a bunch of payments in
> bulk, and trivially overflow a home or Tor nodes' bandwidth. The only
> response to that, whether its
> a DoS attack or a legitimate user, is to rate-limit, and to rate-limit in
> a way that tells the user
> sending the messages to back off! Sure, you could do that by failing onion
> messages with an error
> that updates the fee you charge, but you're ultimately doing a poor-man's
> (or, I suppose,
> rich-man's) version of what Bastien proposes, not adding some fundamental
> difference.
>
> Ultimately, paying suffers from the standard PoW-for-spam issue - you
> cannot assign a reasonable
> cost that an attacker cares about without impacting the system's usability
> due to said cost. Indeed,
> making it expensive enough to mount a months-long DDoS without impacting
> legitimate users be pretty
> easy - at 1msat per relay of a 1366 byte onion message you can only
> saturate an average home users'
> 30Mbps connection for 30 minutes before you rack up a dollar in costs, but
> if your concern is
> whether someone can reasonably trivially take out the network for minutes
> at a time to make it have
> perceptibly high failure rates, no reasonable cost scheme will work. Quite
> the opposite - the only
> reasonable way to respond is to respond to a spike in traffic while
> maintaining QoS is to rate-limit
> by inbound edge!
>
> Ultimately, what we have here is a networking problem, that has to be
> solved with networking
> solutions, not a costing problem, which can be solved with payment. I can
> only assume that the
> desire to add a cost to onion messages ultimately stems from a desire to
> ensure every possible
> avenue for value extraction is given to routing nodes, but I think that
> desire is misplaced in this
> case - the cost of bandwidth is diminutive compared to other costs of
> routing node operation,
> especially when you consider sensible rate-limits as proposed in Bastien's
> email.
>
> Indeed, if anyone were proposing rate-limits which would allow anything
> close to enough bandwidth
> usage to cause "lightning is turning into Tor and has Tor's problems" to
> be a legitimate concern I'd
> totally agree we should charge for its use. But no one is, nor has anyone
> ever seriously, to my
> knowledge, proposed such a thing. If lightning messages get deployed and
> start eating up even single
> Mbps's on a consistent basis on nodes, we can totally revisit this, its
> not like we are shutting the
> door to any possible costing system if it becomes necessary, but
> rate-limiting has to happen either
> way, so we should start there and see if we need costing, not jump to
> costing on day one, hampering
> utility.
>
> Matt
>
> On 6/29/22 8:22 PM, Olaoluwa Osuntokun wrote:
> > Hi t-bast,
> >
> > Happy to see this finally written up! With this, we have two classes of
> > proposals for rate limiting onion messaging:
> >
> > 1. Back propagation based rate limiting as described here.
> >
> > 2. Allowing nodes to express a per-message cost for their forwarding
> > services, which is described here [1].
> >
> > I still need to digest everything proposed here, but personally I'm more
> > optimistic about the 2nd category than the 1st.
> >
> > One issue I see w/ the first category is that a single party can flood
> the
> > network and cause nodes to trigger their rate limits, which then affects
> the
> > usability of the onion messages for all other well-behaving parties. An
> > example, this might mean I can't fetch invoices, give up after a period
> of
> > time (how long?), then result to a direct connection (perceived payment
> > latency accumulated along the way).
> >
> > With the 2nd route, if an attacker floods the network, they need to
> directly
> > pay for the forwarding usage themselves, though they may also directly
> cause
> > nodes to adjust their forwarding rate accordingly. However in this case,
> the
> > attacker has incurred a concrete cost, and even if the rates rise, then
> > those that really need the service (notifying an LSP that a user is
> online
> > or w/e) can continue to pay that new rate. In other words, by _pricing_
> the
> > resource utilization, demand preferences can be exchanged, leading to
> more
> > efficient long term resource allocation.
> >
> > W.r.t this topic, one event that imo is worth pointing out is that a very
> > popular onion routing system, Tor, has been facing a severe DDoS attack
> that
> > has lasted weeks, and isn't yet fully resolved [2]. The on going flooding
> > attack on Tor has actually started to affect LN (iirc over half of all
> > public routing nodes w/ an advertised address are tor-only), and other
> > related systems like Umbrel that 100% rely on tor for networking
> traversal.
> > Funnily enough, Tor developers have actually suggested adding some PoW to
> > attempt to mitigate DDoS attacks [3]. In that same post they throw around
> > the idea of using anonymous tokens to allow nodes to give them to "good"
> > clients, which is pretty similar to my lofty Forwarding Pass idea as
> relates
> > to onion messaging, and also general HTLC jamming mitigation.
> >
> > In summary, we're not the first to attempt to tackle the problem of rate
> > limiting relayed message spam in an anonymous/pseudonymous network, and
> we
> > can probably learn a lot from what is and isn't working w.r.t how Tor
> > handles things. As you note near the end of your post, this might just be
> > the first avenue in a long line of research to best figure out how to
> handle
> > the spam concerns introduced by onion messaging. From my PoV, it still
> seems
> > to be an open question if the same network can be _both_ a reliable
> > micro-payment system _and_ also a reliable arbitrary message transport
> > layer. I guess only time will tell...
> >
> > > The `shared_secret_hash` field contains a BIP 340 tagged hash
> >
> > Any reason to use the tagged hash here vs just a plain ol HMAC? Under the
> > hood, they have a pretty similar construction [4].
> >
> > [1]:
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-February/003498.html
> > <
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-February/003498.html
> >
> > [2]: https://status.torproject.org/issues/2022-06-09-network-ddos/
> > <https://status.torproject.org/issues/2022-06-09-network-ddos/>
> > [3]: https://blog.torproject.org/stop-the-onion-denial/
> > <https://blog.torproject.org/stop-the-onion-denial/>
> > [4]: https://datatracker.ietf.org/doc/html/rfc2104 <
> https://datatracker.ietf.org/doc/html/rfc2104>
> >
> > -- Laolu
> >
> >
> >
> > On Wed, Jun 29, 2022 at 1:28 AM Bastien TEINTURIER <bastien at acinq.fr
> <mailto:bastien at acinq.fr>> wrote:
> >
> > During the recent Oakland Dev Summit, some lightning engineers got
> together to discuss DoS
> > protection for onion messages. Rusty proposed a very simple
> rate-limiting scheme that
> > statistically propagates back to the correct sender, which we
> describe in details below.
> >
> > You can also read this in gist format if that works better for you
> [1].
> >
> > Nodes apply per-peer rate limits on _incoming_ onion messages that
> should be relayed (e.g.
> > N/seconds with some burst tolerance). It is recommended to allow
> more onion messages from
> > peers with whom you have channels, for example 10/seconds when you
> have a channel and 1/second
> > when you don't.
> >
> > When relaying an onion message, nodes keep track of where it came
> from (by using the `node_id` of
> > the peer who sent that message). Nodes only need the last such
> `node_id` per outgoing connection,
> > which ensures the memory footprint is very small. Also, this data
> doesn't need to be persisted.
> >
> > Let's walk through an example to illustrate this mechanism:
> >
> > * Bob receives an onion message from Alice that should be relayed to
> Carol
> > * After relaying that message, Bob stores Alice's `node_id` in its
> per-connection state with Carol
> > * Bob receives an onion message from Eve that should be relayed to
> Carol
> > * After relaying that message, Bob replaces Alice's `node_id` with
> Eve's `node_id` in its
> > per-connection state with Carol
> > * Bob receives an onion message from Alice that should be relayed to
> Dave
> > * After relaying that message, Bob stores Alice's `node_id` in its
> per-connection state with Dave
> > * ...
> >
> > We introduce a new message that will be sent when dropping an
> incoming onion message because it
> > reached rate limits:
> >
> > 1. type: 515 (`onion_message_drop`)
> > 2. data:
> > * [`rate_limited`:`u8`]
> > * [`shared_secret_hash`:`32*byte`]
> >
> > Whenever an incoming onion message reaches the rate limit, the
> receiver sends `onion_message_drop`
> > to the sender. The sender looks at its per-connection state to find
> where the message was coming
> > from and relays `onion_message_drop` to the last sender, halving
> their rate limits with that peer.
> >
> > If the sender doesn't overflow the rate limit again, the receiver
> should double the rate limit
> > after 30 seconds, until it reaches the default rate limit again.
> >
> > The flow will look like:
> >
> > Alice Bob Carol
> > | | |
> > | onion_message | |
> > |------------------------>| |
> > | | onion_message |
> > | |------------------------>|
> > | | onion_message_drop |
> > | |<------------------------|
> > | onion_message_drop | |
> > |<------------------------| |
> >
> > The `shared_secret_hash` field contains a BIP 340 tagged hash of the
> Sphinx shared secret of the
> > rate limiting peer (in the example above, Carol):
> >
> > * `shared_secret_hash = SHA256(SHA256("onion_message_drop") ||
> SHA256("onion_message_drop") || sphinx_shared_secret)`
> >
> > This value is known by the node that created the onion message: if
> `onion_message_drop` propagates
> > all the way back to them, it lets them know which part of the route
> is congested, allowing them
> > to retry through a different path.
> >
> > Whenever there is some latency between nodes and many onion
> messages, `onion_message_drop` may
> > be relayed to the incorrect incoming peer (since we only store the
> `node_id` of the _last_ incoming
> > peer in our outgoing connection state). The following example
> highlights this:
> >
> > Eve Bob Carol
> > | onion_message | |
> > |------------------------>| onion_message |
> > | onion_message |------------------------>|
> > |------------------------>| onion_message |
> > | onion_message |------------------------>|
> > |------------------------>| onion_message |
> > |------------------------>|
> > Alice | onion_message_drop |
> > | onion_message | +----|
> > |------------------------>| onion_message | |
> > | |--------------------|--->|
> > | | | |
> > | | | |
> > | | | |
> > | onion_message_drop |<-------------------+ |
> > |<------------------------| |
> >
> > In this example, Eve is spamming but `onion_message_drop` is
> propagated back to Alice instead.
> > However, this scheme will _statistically_ penalize the right
> incoming peer (with a probability
> > depending on the volume of onion messages that the spamming peer is
> generating compared to the
> > volume of legitimate onion messages).
> >
> > It is an interesting research problem to find formulas for those
> probabilities to evaluate how
> > efficient this will be against various types of spam. We hope
> researchers on this list will be
> > interested in looking into it and will come up with a good model to
> evaluate that scheme.
> >
> > To increase the accuracy of attributing `onion_message_drop`, more
> data could be stored in the
> > future if it becomes necessary. We need more research to quantify
> how much accuracy would be
> > gained by storing more data and making the protocol more complex.
> >
> > Cheers,
> > Bastien
> >
> > [1]https://gist.github.com/t-bast/e37ee9249d9825e51d260335c94f0fcf
> <https://gist.github.com/t-bast/e37ee9249d9825e51d260335c94f0fcf>
> >
> > _______________________________________________
> > Lightning-dev mailing list
> > Lightning-dev at lists.linuxfoundation.org <mailto:
> Lightning-dev at lists.linuxfoundation.org>
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> > <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/20220630/d5d6c5d5/attachment-0001.html>

2023-06-09 13:06:24

- reply

📅 Original date posted:2022-06-29
📝 Original message:
During the recent Oakland Dev Summit, some lightning engineers got
together to discuss DoS
protection for onion messages. Rusty proposed a very simple
rate-limiting scheme that
statistically propagates back to the correct sender, which we describe
in details below.
You can also read this in gist format if that works better for you [1].
Nodes apply per-peer rate limits on _incoming_ onion messages that
should be relayed (e.g.
N/seconds with some burst tolerance). It is recommended to allow more
onion messages from
peers with whom you have channels, for example 10/seconds when you
have a channel and 1/second
when you don't.
When relaying an onion message, nodes keep track of where it came from
(by using the `node_id` of
the peer who sent that message). Nodes only need the last such
`node_id` per outgoing connection,
which ensures the memory footprint is very small. Also, this data
doesn't need to be persisted.
Let's walk through an example to illustrate this mechanism:
* Bob receives an onion message from Alice that should be relayed to Carol
* After relaying that message, Bob stores Alice's `node_id` in its
per-connection state with Carol
* Bob receives an onion message from Eve that should be relayed to Carol
* After relaying that message, Bob replaces Alice's `node_id` with
Eve's `node_id` in its
per-connection state with Carol
* Bob receives an onion message from Alice that should be relayed to Dave
* After relaying that message, Bob stores Alice's `node_id` in its
per-connection state with Dave
* ...
We introduce a new message that will be sent when dropping an incoming
onion message because it
reached rate limits:
1. type: 515 (`onion_message_drop`)
2. data:
* [`rate_limited`:`u8`]
* [`shared_secret_hash`:`32*byte`]
Whenever an incoming onion message reaches the rate limit, the
receiver sends `onion_message_drop`
to the sender. The sender looks at its per-connection state to find
where the message was coming
from and relays `onion_message_drop` to the last sender, halving their
rate limits with that peer.
If the sender doesn't overflow the rate limit again, the receiver
should double the rate limit
after 30 seconds, until it reaches the default rate limit again.
The flow will look like:
Alice Bob Carol
| | |
| onion_message | |
|------------------------>| |
| | onion_message |
| |------------------------>|
| | onion_message_drop |
| |<------------------------|
| onion_message_drop | |
|<------------------------| |
The `shared_secret_hash` field contains a BIP 340 tagged hash of the
Sphinx shared secret of the
rate limiting peer (in the example above, Carol):
* `shared_secret_hash = SHA256(SHA256("onion_message_drop") ||
SHA256("onion_message_drop") || sphinx_shared_secret)`
This value is known by the node that created the onion message: if
`onion_message_drop` propagates
all the way back to them, it lets them know which part of the route is
congested, allowing them
to retry through a different path.
Whenever there is some latency between nodes and many onion messages,
`onion_message_drop` may
be relayed to the incorrect incoming peer (since we only store the
`node_id` of the _last_ incoming
peer in our outgoing connection state). The following example highlights this:
Eve Bob Carol
| onion_message | |
|------------------------>| onion_message |
| onion_message |------------------------>|
|------------------------>| onion_message |
| onion_message |------------------------>|
|------------------------>| onion_message |
|------------------------>|
Alice | onion_message_drop |
| onion_message | +----|
|------------------------>| onion_message | |
| |--------------------|--->|
| | | |
| | | |
| | | |
| onion_message_drop |<-------------------+ |
|<------------------------| |
In this example, Eve is spamming but `onion_message_drop` is
propagated back to Alice instead.
However, this scheme will _statistically_ penalize the right incoming
peer (with a probability
depending on the volume of onion messages that the spamming peer is
generating compared to the
volume of legitimate onion messages).
It is an interesting research problem to find formulas for those
probabilities to evaluate how
efficient this will be against various types of spam. We hope
researchers on this list will be
interested in looking into it and will come up with a good model to
evaluate that scheme.
To increase the accuracy of attributing `onion_message_drop`, more
data could be stored in the
future if it becomes necessary. We need more research to quantify how
much accuracy would be
gained by storing more data and making the protocol more complex.
Cheers,
Bastien
[1] https://gist.github.com/t-bast/e37ee9249d9825e51d260335c94f0fcf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220629/513b6829/attachment.html>

2023-06-09 13:06:14

- reply

📅 Original date posted:2022-06-15
📝 Original message:
Hey Zman and list,
I don't think waxwing's proposal will help us for private gossip.
The rate-limiting it provides doesn't seem to be enough in our case.
The proposal rate-limits token issuance to once every N blocks where
N is the age of the utxo to which we prove ownership of. Once the token
is issued and verified, the attacker can spend that utxo, and after N
blocks he's able to get a new token with this new utxo.
That is a good enough rate-limit for some scenarios, but in our case
it means that every N blocks people are able to double the capacity
they advertise without actually having more funds.
We can probably borrow ideas from this proposal, but OTOH I don't
see how to apply it to lightning gossip, what we want isn't really rate
limiting, we want a stronger link between advertised capacity and
real on-chain capacity.
Cheers,
Bastien
Le mer. 15 juin 2022 à 00:01, ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> a écrit :
>
> > ## Lightning Gossip
> >
> > # Gossip V2: Now Or Later?
>
> <snip>
>
> > A proposal for the "re-design the entire thing" was floated in the past
> by
> > Rusty [6]. It does away with the strict coupling of channels to channel
> > announcements, and instead moves them to the _node_ level. Each node
> would
> > then advertise the set of "outputs" they have control of, which would
> then
> > be mapped to the total capacity of a node, without requiring that these
> > outputs self identify themselves on-chain as Lightning Channels. This
> also
> > opens up the door to different, potentially more privacy preserving
> > proofs-of-channel-ownership (something something zkp).
>
> waxwing recently posted something interesting over in bitcoin-dev, which
> seems to match the proof-of-channel-ownereship.
>
> https://gist.github.com/AdamISZ/51349418be08be22aa2b4b469e3be92f
>
> I confess to not understanding the mathy bits but it seems to me, naively,
> that the feature set waxwing points out match well with the issues we want
> to have:
>
> * We want to rate-limit gossip somehow.
> * We want to keep the mapping of UTXOs to channels private.
>
> It requires a global network that cuts across all uses of the same
> mechanism (similar to defiads, but more private --- basically this means
> that it cannot be just Lightning which uses this mechanism, at least to
> acquire tokens-to-broadcast-my-channels) to prevent a UTXO from being
> reused across services, a property I believe is vital to the expected
> spam-resistance.
>
> > # Friend-of-a-friend Balance Sharing & Probing
> >
> > A presentation was given on friend-of-a-friend balance sharing [16]. The
> > high level idea is that if we share _some_ information within a local
> > radius, then this gives the sender more information to choose a path
> that's
> > potentially more reliable. The tradeoff here ofc is that nodes will be
> > giving away more information that can potentially be used to ascertain
> > payment flows. In an attempt to minimize the amount of information
> shared,
> > the presenter proposed that just 2 bits of information be shared. Some
> > initial simulations showed that sharing local information actually
> performed
> > better than sharing global information (?). Some were puzzled w.r.t how
> > that's possible, but assuming the slides+methods are published others can
> > dig further into the model/parameter used to signal the inclusion.
> >
> > Arguably, information like this is already available via probing, so one
> > line of thinking is something like: "why not just share _some_ of it"
> that
> > may actually lead to less internal failures? This is related to a sort of
> > tension between probing as a tool to increase payment reliability and
> also
> > as a tool to degrade privacy in the network. On the other hand, others
> > argued that probing provides natural cover traffic, since they actually
> > _are_ payments, though they may not be intended to succeed.
> >
> > On the topic of channel probing, a sort of makeshift protocol was
> devised to
> > make it harder in practice, sacrificing too much on the axis of payment
> > reliability. At a high level it proposes that:
> >
> > * nodes more diligently set both their max_htlc amount, as well as the
> > max_htlc_value_in_flight amount
> >
> > * a 50ms (or select other value) timer should be used when sending out
> > commitment signatures, independent of HTLC arrival
> >
> > * nodes leverage the max_htlc value to set a false ceiling on the max in
> > flight parameter
> >
> > * for each HTLC sent/forwarded, select 2 other channels at random and
> > reduce the "fake" in-flight ceiling for a period of time
> >
> > Some more details still need to be worked out, but some felt that this
> would
> > kick start more research into this area, and also make balance mapping
> > _slightly_ more difficult. From afar, it may be the case that achieving
> > balance privacy while also achieving acceptable levels of payment
> > reliability might be at odds with each other.
>
> A point that was brought up is that nodes can lie about their capacity,
> and there would be no way to counteract this.
>
> Even given the above, it would be trivial for a lying node to randomly lie
> about their `max_htlc` to still be noticed by nodes who try to filter out
> nodes who do not update their `max_htlc`s.
> (maximal lying is to always say 50% of your capacity is in `max_htlc`,
> your node can lie by setting `max_htlc` from 35%->65%, you can coordinate
> this with another lying peer node too by use of an odd message number to
> set up the lying protocol so both of you can lie about the channel capacity
> consistently)
>
> I think your best bet is really to utilize feerates, as lying with those
> is expected to lead to economic loss.
>
> <snip>
>
> > # Node Fee Optimization & Fee Rate Cards
> >
> > Over the past few years, a common thread we've seen across successful
> > routing nodes is dynamic fee setting as a way to encourage/discourage
> > traffic. A routing nodes can utilize the set of fees of a channel to
> either
> > make it too expensive for other nodes to route through (it's already
> > depleted don't try unless you'll give be 10 mil sats, which no one
> would) or
> > very cheap, which'll incentivize flows in the other direction. If all
> nodes
> > are constantly sending out updates of this nature, then it can generate a
> > lot of traffic, and also sort of leak more balance information overtime
> > (which some nodes are already doing: using fees/max_htlc to communicate
> > available balances).
> >
> > One attendee proposed allowing nodes to express a sort of fee gradient
> via a
> > static curve/bucket/function, instead of dynamically communicating what
> the
> > latest state of the fee+liquidity distribution looks like. A possible
> > manifestation could be a series of buckets, each of which with varying
> fee
> > rates. If your payment consumes 50% of channel balance, then you pay this
> > rate, otherwise if it's 5% you pay this rate, etc, etc.
>
> I think this is not what was actually proposed?
>
> As I understood it, the percent range is not how much the payment consumes
> of the channel balance but instead the percent range is the
> probability-of-success given a uniform distribution of channel balance.
>
> For instance if the current channel balance is currently 67%, then the
> forwarding node will succeed all payments that pay a fee from the 33% fee
> card or higher, otherwise fail the payment with "not enough fees".
>
> The intent is that payers will treat 100% - fee_card_percent as the
> probability-of-failure of that channel, and can select which fee card
> maximizes both its probability-of-failure and max-fee in some kind of
> reasonable exchange rate.
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> 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/20220615/56c7bcf8/attachment-0001.html>

2023-06-09 13:06:02

- reply

📅 Original date posted:2022-05-17
📝 Original message:
I completely agree with Matt, these two components are completely
independent
and too often conflated. Scoring channels and estimating liquidity is
something
that has been regularly discussed by implementations for the last few years,
where every implementation did its own experiments over time.
Eclair has quite a large, configurable set of heuristics around channel
scoring,
along with an A/B testing system that we've been using for a while on
mainnet
(see [1] for details). We've also been toying with channel liquidity
estimation for
more than half a year, which you can follow in [2] and [3].
These are heuristics, and it's impossible to judge whether they work or not
until
you've tried them on mainnet with real payments, so I strongly encourage
people
to run such experiments. But when you do, you should have enough volume for
the result data to be statistically meaningful and you should do A/B
testing,
otherwise you can make the data say pretty much everything you want. What
I believe is mostly missing is the volume, the network doesn't have enough
real
payments yet IMHO for this data to accurately say that one heuristic is
better
than another.
Using an MCF algorithm instead of dijkstra is useful when relaying large
payments
that will need to be split aggressively to reach the destination. It does
make a lot
of sense in that scenario. However, it's important to also take a step back
and
look at whether it is economical to make such payments on lightning.
For a route with an aggregated proportional fee of 1000ppm, here is a rough
comparison of the fees between on-chain and lightning:
* At 1 sat/byte on-chain, payments above 2mBTC cost less on-chain than
off-chain
* At 10 sat/byte on-chain, payments above 20mBTC cost less on-chain than
off-chain
* At 25 sat/byte on-chain, payments above 50mBTC cost less on-chain than
off-chain
* And so on (just keep multiplying)
Of course, making payments on lightning has more benefits than just fees,
they
also confirm faster than on-chain payments, but I think it's important to
keep these
figures in mind.
It would be also useful to think about the shape of the network. Using an
MCF
algorithm makes sense when payments are saturating channels. But if channels
are much bigger than your payment size, this is probably overkill. If
channels are
small "at the edges of the network" and bigger than payments at the "core
of the
network", and we're using trampoline routing [4], it makes sense to run
different
path-finding algorithms depending on where we are (e.g. MCF at the edges on
a small subset of the graph and dijkstra inside the core).
I'm very happy that all this research is happening and helping lightning
payments
become more reliable, thanks for everyone involved! I think the design
space is
still quite large when we take everything into account, so I expect that
we'll see
even more innovation in the coming years.
Cheers,
Bastien
[1]
https://github.com/ACINQ/eclair/blob/10eb9e932f9c0de06cc8926230d8ad4e2d1d9e2c/eclair-core/src/main/resources/reference.conf#L237
[2] https://github.com/ACINQ/eclair/pull/2263
[3] https://github.com/ACINQ/eclair/pull/2071
[4] https://github.com/lightning/bolts/pull/829
Le lun. 16 mai 2022 à 22:59, Matt Corallo <lf-lists at mattcorallo.com> a
écrit :
> Its probably worth somewhat disentangling the concept of switching to a
> minimum-cost flow routing
> algorithm from the concept of "scoring based on channel value and
> estimated available liquidity".
>
> These are two largely-unrelated concepts that are being mashed into one in
> this description - the
> first concept needs zero-base-fee to be exact, though its not clear to me
> that a heuristics-based
> approach won't give equivalent results in practice, given the noise in
> success rate compared to
> theory here.
>
> The second concept is something that LDK (and I believe CLN and maybe even
> eclair now) do already,
> though lnd does not last I checked. For payments where MPP does not add
> much to success rate (i.e.
> payments where the amount is relatively "low" compared to available
> network liquidity) dijkstra's
> with a liquidity/channel-size based scoring will give you the exact same
> result.
>
> For cases where you're sending an amount which is "high" compared to
> available network liquidity,
> taking a minimum-cost-flow algorithm becomes important, as you point out.
> Of course you're always
> going to suffer really slow payment and many retires in this case anyway.
>
> Matt
>
> On 5/15/22 1:01 PM, Carsten Otto via Lightning-dev wrote:
> > Dear all,
> >
> > the most recent version of lnd-manageJ [1] now includes basic, but
> usable,
> > support for #PickhardtPayments. I kindly invite you to check out the
> code, give
> > it a try, and use this work for upcoming experiments.
> >
> > Teaser with video:
> https://twitter.com/c_otto83/status/1525879972786749453
> >
> > The problem, heavily summarized:
> >
> > - Sending payments in the LN often fails, especially with larger amounts.
> > - Splitting a large payment into smaller shards (using MPP) is helpful,
> > as in general the smaller shards don't fail as often as a single large
> > payment would. However, the success probability also drops
> > exponentially with the number of channels included [2].
> > - Finding routes through the LN is tricky, as the channels' liquidity is
> > uncertain at the time of computing the routes and a simple "trial and
> > error" approach might take too long.
> > - There are several implementations using various heuristics, taking
> > aspects like fees, previous failures, HTLC deltas, channel age, ...
> > into account. Comparing these approaches is very hard.
> >
> > The gist of #PickhardtPayments:
> >
> > - The issue of finding MPP routes in the LN corresponds to the
> > well-known minimum-cost flow problem in computer science (graph
> > theory) with lots of related research, results, algorithms, ...
> > - As shown in the paper [3] the results are optimal, no matter which
> > "cost" function is used to reason about routing costs (fees) and/or
> > reliability. However, depending on the characteristics of the
> > function, actually finding optimal results can be extremely hard
> > (NP-complete in some cases). By imposing the zero base fee limitation
> > and assuming a uniform distribution of funds, fast implementations
> > (polynomial time with sub-second runtimes) can be used.
> > - Assuming (!) a uniform distribution of funds in each channel and zero
> > base fee only, #PickhardtPayments offers an approach that is optimal,
> > i.e. proven perfect and computationally feasible.
> > - The most basic version only considers uncertainty costs for
> > reliability, but it is possible (and implemented in lnd-manageJ) to
> > also consider routing costs (fee rates) and optimize for both features
> > to come up with reliable and cheap-ish MPPs.
> > - The implementation of #PickhardtPayments in lnd-manageJ needs to
> > ignore non-zero base fee channels to avoid extremely slow
> > (NP-complete) computations. Furthermore, certain aspects are
> > approximated [4]. As such, optimality claims are limited to the zero
> > base fee subset of the LN, and real-world experiments might be tricky
> > to interpret. However, as also shown in the testnet videos [5][6],
> > first results are very promising!
> >
> > The real strength of #PickhardtPayments:
> >
> > - Liquidity information, for example obtained by previous failures, is
> > taken into account. For each attempt, the relevant bits of information
> > are obtained and will be used to guide the following attempts.
> > - As the underlying algorithm is proven to be optimal, we do not need to
> > rely on heuristics. Instead, the algorithm happily finds routes that
> > may be very long (but very probable/cheap, for whatever reason), have
> > a surprising number of shards, or rather odd amounts.
> > - The underlying algorithm also deals with shared segments, i.e.
> > individual channels that are used for more than one shard of the MPP,
> > without oversaturating it.
> >
> > The code in lnd-manageJ:
> >
> > - Highly experimental, but it's a start!
> > - lnd + gRPC middleware + Java/Spring + PostgreSQL is a bit more complex
> > than necessary.
> > - Only works with lnd.
> > - Doesn't really work with lnd until issue #5746 [7] is fixed. I'd be
> > very happy for someone to have a look at my proposal (PR #6543 [8])!
> > - The code doesn't handle all corner cases, especially the
> > less-than-usual failure codes. For example, if a node decides to raise
> > the fee rate, the corresponding channel will be ignored for a while as
> > I'm too lazy to think about how to update the information in the data
> > structure used to compute the MPP.
> > - Pending shards (neither failed nor settled) just cause the whole MPP
> > to hang until something times out. Most likely this can't be fixed
> > without stuckless payments?
> >
> > I'd be very happy to discuss implementation details (not on this list, I
> > guess?) and help with upcoming (mainnet?) benchmarks and experiments
> > (René Pickhardt is also interested in helping with this). Given a fix
> > for the blocking lnd issue, I'd be happy to let my node c-otto.de take
> > part in some experiments.
> >
> > Last but not least, a huge thank you to René Pickhardt for lots of
> > insightful discussions, proof reading, and of course (together with
> > Stefan Richter) the actual work of coming up with #PickhardtPayments!
> >
> > Best regards,
> > Carsten
> >
> > 1: https://github.com/C-Otto/lnd-manageJ/blob/main/PickhardtPayments.md
> > 2: https://arxiv.org/abs/2103.08576
> > 3: https://arxiv.org/abs/2107.05322
> > 4:
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-March/003510.html
> > 5: https://c-otto.de/pp/pp.mp4
> > 6: https://c-otto.de/pp/lnd.mp4
> > 7: https://github.com/lightningnetwork/lnd/issues/5746
> > 8: https://github.com/lightningnetwork/lnd/pull/6543
> >
> >
> > _______________________________________________
> > 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/20220517/0a3105b6/attachment-0001.html>

2023-06-09 13:05:56

- reply

📅 Original date posted:2022-04-22
📝 Original message:
Good morning list,
I will describe here a vulnerability found in older versions of some
lightning implementations of anchor outputs. As most implementations
have not yet released support for anchor outputs, they should verify
that they are not impacted by this type of vulnerability while they
implement this feature.
I want to thank the impacted implementations for their reactivity in
fixing this issue, which hasn't impacted any user (as far as I know).
## Timeline
- March 23 2021: I discovered an interesting edge case while
implementing anchor outputs in eclair ([1]).
- August 2021: while I was finalizing support for the 0-htlc-fees
variant of anchor outputs in eclair, I was able to do in-depth
interoperability tests with other implementations that supported
anchor outputs (only lnd and c-lightning at that time). These tests
revealed that both implementations were impacted by the edge case
discovered in March and that it could be exploited to steal funds.
- September 2 2021: I notified both development teams.
- October 11 2021: I disclosed the vulnerability to Electrum and LDK
to ensure they would not ship a version of anchor outputs containing
the same issue (anchor outputs wasn't shipped in their software yet).
- November 2021: a fix for this vulnerability was released in lnd 0.14.0
and c-lightning 0.10.2.
## Impacted users
- Users running versions of lnd prior to 0.14.0
- Users running versions of c-lightning prior to 0.10.2 if they have
activated experimental features (and have anchor outputs channels)
## Description of the vulnerability
With anchor outputs, your lightning node doesn't use `SIGHASH_ALL` when
sending its signatures for htlc transactions in `commitment_signed`.
It uses `SIGHASH_SINGLE | SIGHASH_ANYONECANPAY` instead and the other
node is supposed to add a `SIGHASH_ALL` signature when they broadcast
the htlc transaction.
Interestingly, this lets the other node combine multiple htlcs in a
single transaction without invalidating your signatures, as long as the
`nLockTime` of all htlcs match. This has been a known fact for a long
time, which can be used to batch transactions and save on fees.
The vulnerability lies in how *revoked* htlc transactions were handled.
Because we historically used `SIGHASH_ALL`, we could assume that htlc
transactions had a single output. For example, older eclair versions
used that fact, and when presented with a revoked htlc transaction,
would claim a single output of that transaction via a penalty/justice
transaction (see [2]). This was completely ok before anchor outputs.
But after anchor outputs, if the revoked htlc transaction actually
contained many htlcs, your node should claim *all* of the revoked
outputs with penalty/justice transactions.
When presented with a transaction containing multiple revoked htlcs,
both impacted implementations would fail to claim any output. This means
the attacker could publish a revoked commitment with htlcs that have
been settled since then, and claim these htlcs a second time on-chain,
thus stealing funds.
Let's take a concrete example, where Bob is under attack.
Bob has channels with Alice and Carol: Alice ---> Bob ---> Carol.
Alice sends N htlcs to Carol spending all of her channel balance, which
Carol then fulfills.
Carol has then irrevocably received the funds from Bob.
Then Alice publishes her old commitment where all the htlcs were pending
and aggregates all of her htlc-timeouts in a single transaction.
Bob will fail to claim the revoked htlc outputs which will go back to
Alice's on-chain wallet. Bob has thus lost the full channel amount.
## Caveat
An important caveat is that this attack will not work all the time, so
it can carry a risk for the attacker. The reason for that is that the
htlc transactions have a relative delay of 1 block. If the node under
attack is able to make his penalty/justice transactions confirm
immediately after the revoked commitment (by claiming outputs directly
from the commitment transaction with a high enough feerate) the
attacker won't be able to broadcast the aggregated htlc transaction
(and loses their channel reserve).
The success of the attack depends on what block target implementations
use for penalty/justice transactions and how congested the mempool is
(unless the attacker notices that their peer is offline, in which case
they can use this opportunity to carry out the attack).
I'm pretty confident all users have already upgraded to newer versions
(particularly since there have been important bug fixes on unrelated
issues since then), but if your node still hasn't upgraded, you should
consider doing it as soon as possible.
Cheers,
Bastien
[1] https://github.com/ACINQ/eclair/pull/1738
[2]
https://github.com/ACINQ/eclair/blob/35b070ee5de2ea3847cf64b86f7e47abcca10b95/eclair-core/src/main/scala/fr/acinq/eclair/transactions/Transactions.scala#L613
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220422/62503f9e/attachment.html>

2023-06-09 13:05:51

- reply

📅 Original date posted:2022-04-15
📝 Original message:
Good morning Alex,
I’ve been investigating set reconciliation as a means to reduce bandwidth
and redundancy of gossip message propagation.
>
Cool project, glad to see someone working on it! The main difficulty here
will
indeed be to ensure that the number of differences between sets is bounded.
We will need to maintain a mechanism to sync the whole graph from scratch
for new nodes, so the minisketch diff must be efficient enough otherwise
nodes
will just fall back to a full sync way too often (which would waste a lot of
bandwidth).
Picking several offending channel ids, and digging further, the majority of
> these
appear to be flapping due to Tor or otherwise intermittent connections.
>
One thing that may help here from an implementation's point of view is to
avoid
sending a disabled channel update every time a channel goes offline. What
eclair does to avoid spamming is to only send a disabled channel update when
someone actually tries to use that channel. Of course, if people choose this
offline node in their route, you don't have a choice and will need to send a
disabled channel update, but we've observed that many channels come back
online before we actually need to use them, so we're saving two channel
updates
(one to disable the channel and one to re-enable it). I think all
implementations
should do this. Is that the case today?
We could go even further, and when we receive an htlc that should be relayed
to an offline node, wait a bit to give them an opportunity to come online
instead
of failing the htlc and sending a disabled channel update. Eclair currently
doesn't
do that, but it would be very easy to add.
- A common listing of current default rate limits across lightning network
> implementations.
>
Eclair doesn't do any rate-limiting. We wanted to "feel the pain" before
adding
anything, and to be honest we haven't really felt it yet.
which will use a common, simple heuristic to accept or reject a gossip
> message.
(Think one channel update per block, or perhaps one per block_height << 5.)
>
I think it would be easy to come to agreement between implementations and
restrict channel updates to at most one every N blocks. We simply need to
add
the `block_height` in a tlv in `channel_update` and then we'll be able to
actually
rate-limit based on it. Given how much time it takes to upgrade most of the
network, it may be a good idea to add the `block_height` tlv now in the
spec,
and act on it later? Unless your work requires bigger changes in channel
update
in which case it will probably be a new message.
Note that it will never be completely accurate though, as different nodes
can
have different blockchain tips. My nodes may be one or two blocks late
compared
to the node that emits the channel update. We need to allow a bit of leeway
there.
Cheers,
Bastien
Le jeu. 14 avr. 2022 à 23:06, Alex Myers <alex at endothermic.dev> a écrit :
> Hello lightning developers,
>
>
> I’ve been investigating set reconciliation as a means to reduce bandwidth
> and redundancy of gossip message propagation. This builds on some earlier work
> from Rusty using the minisketch library [1]. The idea is that each node
> will build a sketch representing it’s own gossip set. Alice’s node will
> encode and transmit this sketch to Bob’s node, where it will be merged with
> his own sketch, and the differences produced. These differences should
> ideally be exactly the latest missing gossip of both nodes. Due to size
> constraints, the set differences will necessarily be encoded, but Bob’s
> node will be able to identify which gossip Alice is missing, and may then
> transmit exactly those messages.
>
>
> This process is relatively straightforward, with the caveat that the sets
> must otherwise match very closely (each sketch has a maximum capacity for
> differences.) The difficulty here is that each node and lightning
> implementation may have its own rules for gossip acceptance and
> propagation. Depending on their gossip partners, not all gossip may
> propagate to the entire network.
>
>
> Core-lightning implements rate limiting for incoming channel updates and
> node announcements. The default rate limit is 1 per day, with a burst of
> 4. I analyzed my node’s gossip over a 14 day period, and found that, of
> all publicly broadcasting half-channels, 18% of them fell afoul of our
> spam-limiting rules at least once. [2]
>
>
> Picking several offending channel ids, and digging further, the majority
> of these appear to be flapping due to Tor or otherwise intermittent
> connections. Well connected nodes may be more susceptible to this due to more
> frequent routing attempts, and failures resulting in a returned channel
> update (which otherwise might not have been broadcast.) A slight
> relaxation of the rate limit resolves the majority of these cases.
>
>
> A smaller subset of channels broadcast frequent channel updates with minor
> adjustments to htlc_maximum_msat and fee_proportional_millionths
> parameters. These nodes appear to be power users, with many channels and
> large balances. I assume this is automated channel management at work.
>
>
> Core-Lightning has updated rate-limiting in the upcoming release to
> achieve a higher acceptance of incoming gossip, however, it seems that a
> broader discussion of rate limits may now be worthwhile. A few immediate
> ideas:
>
> - A common listing of current default rate limits across lightning
> network implementations.
>
> - Internal checks of RPC input to limit or warn of network propagation
> issues if certain rates are exceeded.
>
> - A commonly adopted rate-limit standard.
>
>
> My aim is a set reconciliation gossip type, which will use a common,
> simple heuristic to accept or reject a gossip message. (Think one channel
> update per block, or perhaps one per block_height << 5.) See my github
> for my current draft. [3] This solution allows tighter consensus, yet suffers
> from the same problem as original anti-spam measures – it remains
> somewhat arbitrary. I would like to start a conversation regarding gossip
> propagation, channel_update and node_announcement usage, and perhaps even
> bandwidth goals for syncing gossip in the future (how about a million
> channels?) This would aid in the development of gossip set
> reconciliation, but could also benefit current node connection and
> routing reliability more generally.
>
>
> Thanks,
>
> Alex
>
>
> [1] https://github.com/sipa/minisketch
>
> [2]
> https://github.com/endothermicdev/lnspammityspam/blob/main/sampleoutput.txt
>
> [3]
> https://github.com/endothermicdev/lightning-rfc/blob/gossip-minisketch/07-routing-gossip.md#set-reconciliation
>
> _______________________________________________
> 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/20220415/98a7eca4/attachment-0001.html>

2023-06-09 13:05:41

- reply

📅 Original date posted:2022-04-01
📝 Original message:
Good morning list,
In the last couple of months, @thomash-acinq and I have spent a lot of time
working on route blinding for payments [1]. As you may know, route blinding
is a prerequisite for onion messages [2] and Bolt 12 offers [3].
Using route blinding to provide anonymity for onion messages is quite
simple, but it is harder to use safely for payments. The reason for that is
that the lightning network is a very heterogeneous channels network.
The parameters used to relay payments vary widely from one channel to the
other, and can dynamically vary over time: if not accounted for, this can
provide an easy fingerprint to let malicious actors guess what channels are
actually used inside a blinded route. The ideas behind these probing attacks
are described in more details in the route blinding proposals [4].
To protect against such attacks, the latest version of the route blinding
specification lets the recipient impose what parameters will be used by
intermediate blinded nodes to relay payments (instead of using the values
they advertise in their `channel_update`). The parameters that matter are:
* `fee_base_msat`
* `fee_proportional_millionths`
* `cltv_expiry_delta`
* `htlc_minimum_msat`
* `features` that impact payment relaying behavior
We'd like help from this list to figure out whether these are the only
parameters that an attacker can use to fingerprint channels, or if there
are others that we need to take into account to guarantee user privacy.
Note that these attacks only work against public channels: wallet users
relying on unannounced channels are not at risk and will more easily
benefit from route blinding.
I spent a lot of time re-working the specification PR to make it as clear
as possible: please have a look at it and let me know if I can do anything
to make it better. Don't hesitate to reach out directly with questions and
feedback. I strongly recommend to start with the high-level design doc [5],
as natural language and detailed examples will help grasp the main ideas
and subtleties of the proposal.
Cheers,
Bastien
[1] https://github.com/lightning/bolts/pull/765
[2] https://github.com/lightning/bolts/pull/759
[3] https://github.com/lightning/bolts/pull/798
[4]
https://github.com/lightning/bolts/blob/route-blinding/proposals/route-blinding.md#attacks
[5]
https://github.com/lightning/bolts/blob/route-blinding/proposals/route-blinding.md
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220401/6f0347cd/attachment.html>

2023-06-09 13:04:48

- reply

📅 Original date posted:2021-12-16
📝 Original message:
Good morning,
I agree, this onion message trick could let us work around this kind of
cheating
attempt. However, it becomes quite a complex protocol, and it's likely that
the more we progress towards specifying it, the more subtle issues we will
find that will require making it even more complex.
I'm more hopeful that we'll find channel jamming mitigations that work for
both
fast spam and slow spam, and will remove the need for this protocol (which
doesn't protect against fast spam, only against slow spam).
`D` can present to `B` its own `revoke_and_ack` in the above mentioned
> onion message reply.
>
A few high-level notes on why I think this is still harder than it looks:
* even if `D` shows B its `revoke_and_ack`, it doesn't prove that D sent it
to C
* it's impossible for a node to prove that it did *not* receive a message:
you can prove knowledge,
but proving lack of knowledge is much harder (impossible?)
Cheers,
Bastien
Le jeu. 16 déc. 2021 à 01:50, lightning developer <
lightning-developer at protonmail.com> a écrit :
> Good Morning Bastien,
>
> I believe there is another limitation that you're not mentioning: it's
> easy for a malicious node to blame an honest node. I'm afraid this is a
> serious limitation of the proposal.
>
>
> Thank you very much for your review and comments. I have just updated the
> proposal on github with a section "Security Considerations" that is
> equivalent to what I will send in this mail as I believe that the "serious
> limitation" that you pointed out can be resolved with the help of onion
> messages similar to what I tried to communicate in the already existing
> "Extensions" section. BTW before I sent my initial mail I was thinking
> exactly about the example that you mentioned! I elected to not include it
> to keep the text concise and short. Of course I might have back then and
> still a mistake in my thinking and in that case I apologize for asking you
> to review the proposal and my rebuttal.
>
> If we have a payment: A -> B -> C -> D and C is malicious.
> C can forward the payment to D, and even wait for D to correctly settle it
> (with `update_fulfill_htlc` or `update_fail_htlc`), but then withhold that
> message instead of forwarding it to B. Then C blames D, everyone agrees
> that
> D is bad node that must be avoided. Later, C unblocks the `update_*_htlc`
> and everyone thinks that D hodled the HTLC for a long time, which is bad.
>
>
> The above issue can be addressed by `B` verifying the proof it received
> from `C`. This can be done by presenting the proof to `D` via an onion
> message along a different node than `C`. If `D` cannot refute the proof by
> presenting a newer state to `B` then `B` knows that `D` was indeed
> dishonest. Otherwise `D` and `B` have discovered that `C` was misbehaving
> and tried to frame `D`.
>
> `B` indicates to `D` that it is allowed to ask such verification question
> by include the received proof from `C`. Note that `B` could never own such
> proof if `C` has not communicated with `B`. Of course if `C` has never
> talked to `B` in the first place `B` would have send a
> `TEMPORARY_CHANNEL_FAILURE` and if `C` stopped during the update of the
> statemachine to communicate to `B` then `B` can blame `C` via the above
> mechanism and `A` can verify the claim it received from `B`.
>
> Also `B` cannot just send garbage to `D` and try to frame `C` because as
> soon as `B` would frame `C` the upstream node `A` would talk to `C` and
> recognize that it was `B` who was dishonest.
>
> Going back to the situation assuming that `C` and `D` have indeed already
> successfully resolved the HTLC then the node `D` could in the reply to `B`
> even securely include the preimage allowing `B` to reclaim the funds from
> `A` and settle the HTLC in the A->B channel. Only the HTLC in the B->C
> channel would be locked which doesn't have to bother `B` as `B` expects
> that `C` is pulling / settling the HTLC anyway. Only `C` would have the
> disadvantage as it is not pulling its liquidity as soon as it can.
>
> So far - besides a rather complicated flow of information - I do not see
> why the principles of my suggestion would not be possible to work at any
> other point of the channel state machine. So when queried by `B` the node
> `D` could always replay with the latest state it has in the C->D channel
> indicating to `B` that `C` was dishonest.
>
> Of course we could ask now what is if `B` is also malicious? In this case
> `B` could propagate the `blame_channel` back but `A` could again use the
> onion trick to verify and discover that `B` and `C` are not following the
> protocol.
>
>
> Apart from this, I think the blame proof isn't that easy to build.
> It cannot simply use `commitment_signed`, because HTLCs are relayed only
> once the previous commitment has been revoked (through `revoke_and_ack`).
> So the proof should contain data from `commitment_signed` and a proof that
> the previous commitment was revoked (and that it was indeed the previous
> commitment) which is likely very hard to do securely without disclosing
> too much about your channel.
>
>
> I agree the details for the construction of the blame proofs might be more
> tricky than in my naive and high level description. Never the less I think
> they should be possible to construct. I didn't work them out on purpose yet
> given the current state of the proposal to make it easy to understand and
> discuss the concept without getting distracted by details at this stage. I
> think the details of the blame proofs and the communication flow can be
> worked out if we believe that such a mechanism is an overall improvement
> for the protocol.
>
> Also on a side note: I chose `commitment_signed `as the example as this
> would be sufficient to see that the `HTLC` was being processed. If `D` does
> not send `revoke_and_ack` D cannot forward / settle the HTLC and will be
> the malicious node and it is fair for `C` to blame `D`. If on the other
> hand `C` does not move the state forward by not sending `revoke_and_ack`
> and preventing `D` from relaying the HTLC the node `D` can present to `B`
> its own `revoke_and_ack` in the above mentioned onion message reply. This
> would indicate yet again that `C` is dishonest.
>
> Sincerely Lightning Developer
>
> Le mer. 15 déc. 2021 à 02:08, lightning developer via Lightning-dev <
> lightning-dev at lists.linuxfoundation.org> a écrit :
>
>> Good morning list,
>>
>> I have just published a proposal to address (but unfortunately not solve)
>> the old issue of HTLC spam via onions:
>> https://github.com/lightning-developer/lightning-network-documents/blob/main/A%20blame%20ascribing%20protocol%20to%20mitigate%20HTLC%20spam.md
>>
>> The proposal picks up the early idea by Rusty, AJ and others to ascribe
>> blame to a malicious actor but hopefully in a cheaper way than providing
>> proof of a channel close by making use of a new lightning message
>> `blame_channel` in combination with the proposed onion messages. I guess
>> similar ideas and follow ups are already community knowledge (for example
>> the local reputation tracking by Jim Posen at:
>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-May/001232.html)
>> However I had the feeling that the current write up might provide some
>> additional value to the community.
>>
>> The proposal also ensures that blame can be ascribed quickly by requiring
>> a reply from the downstream onion that is proportional to the `cltv delta`
>> at the hop. In this way a sending node will quickly know that a (and more
>> importantly which) downstream channel is not working properly.
>>
>> I will be delighted to read your feedback, thoughts and criticism. For
>> your convenience and archiving I also copied the raw markdown file of the
>> proposal to the end of this Mail.
>>
>> Sincerely Lighting Developer
>>
>>
>> --------- Begin Proposal ----------
>>
>> # A blame ascribing protocol towards ensuring time limitation of stuck
>> HTLCs in flight.
>>
>> I was reviewing the [HOLD fee proposal by Joost](
>> https://github.com/lightning/bolts/pull/843) and the [excellent summary
>> of known mitigation techniques by t-bast](
>> https://github.com/t-bast/lightning-docs/blob/master/spam-prevention.md)
>> when I revisited the very [first idea to mitigate HTLC spam via onions](
>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2015-August/000135.html)
>> that was discussed back in 2015 by Rusty, AJ and a few others. At that time
>> the idea was to ascribe blame to a malicious actor by triggering a force
>> close and proofing ones own honesty by providing the force close
>> transaction. I think there is a lot of merit to the idea of ascribing blame
>> and I think it might be possible with the help of [onion messages](
>> https://github.com/lightning/bolts/pull/759) without the necessity to
>> trigger full force closes.
>>
>> As I am not entirely sure if this suggestion is a reasonable improvement
>> (it certainly does not resolve all the issues we have) I did not spec out
>> the details and message formats and fields but only described the high
>> level idea. I hope this is sufficient to discuss the principles and get the
>> feedback from you if you consider this to be of use and if you think we
>> should work on the details.
>>
>> Idea / Obervation:
>> =============
>> The key idea is to set a fixed time in seconds (the `reply_interval`)
>> after successfully negotiating an HTLC until when a node requires a
>> resultion or reply from its peer to which it previously has forwarded a
>> downstream onion. If the HTLC is not resolved and no reply was sent the
>> downstream peer is considered to be acting maliciously.
>>
>> The amount in seconds can be proportional to the `cltv_delta` of that
>> hop. To me the arbitrary choice of translating 10 blocks of `cltv_delta` to
>> `1` second of expected reply time seems reasonable for now but could be
>> chosen differently as long as the entire network (or at least every node
>> included to the payment attempt) agrees upon the same conversion rate from
>> `cltv_delta` to expected response time from downstream nodes.
>>
>> There are three cases for the reply:
>>
>> The Good reply case (HTLC resolution):
>> ==============================
>> The good case is if the payment will succesfully settle or fail within
>> the `reply_interval`. Thus the reply comes in the form of either an
>> `update_fulfill_htlc` or an `update_fail_htlc`. In any case the HTLC will
>> be removed quickly and the reply can propagate back to the upstream peers.
>>
>> The bad reply case:
>> ===============
>> If a node `N` is not able to send one of those two `update_` messages
>> because the HTLC was not resolved from the downstream channels it MUST send
>> back a new message called `blame_channel`.
>>
>> The `blame_channel` includes a proof that `N` has previously successfully
>> set up the HTLC with the next peer. This may for example be done by
>> including the `commitment_signed` message that the node has received from
>> the next peer as this commits to this (and potentially other) HTLCs.
>> (Alternatively one could extract the relevant `htlc_signature` or adopt
>> `commitment_signed` to include a signature to the `payment_hash` that can
>> be verified with the node's pubkey)
>>
>> The propagated bad reply case:
>> ========================
>> A node might have received an `blame_channel` message from a downstream
>> channel and can propagate this back. To disallow spoofing, nodes might
>> always have to extend the message with their own signature. (I have not
>> thought about this extensively yet). This will make the downstream path of
>> the payment transparent to every node on the upstream path (until the slow
>> /misbehaving node). Nodes SHOULD propagate the `blame_channel` back in a
>> timely manner unless they want to be blamed for the delay themselves.
>>
>> Extensions:
>> =========
>> Of course a malicious node `M` might after receiving an `update_add_htlc`
>> from a node `N` interrupt the channel state machine at various moments
>> before the state successfully moved forward. This would prevent the honest
>> node `N` to ascribe blame to the malicious node `M` as it cannot include
>> proof that it forwarded the HTLC successfully. Thus instead of including
>> the proof of successfully having set up the HTLC the node `N` ascribing
>> blame to `M` might include to the `blame_channel` the last messages it sent
>> to the downstream peer that have not been acknowledged to be able to proof
>> that it tried to move the state machine forward and set up the HTLC.
>>
>> A node on an upstream channel could verify that `N` was indeed honest and
>> has also delivered these messages to `M` by sending these messages via a
>> different path as an onion message to `M`.
>>
>> Now if `M` was indeed dishonest `M` would not respond to the onion
>> message indicating to the upstream node that `N` was honestly ascribing
>> blame to `M`. Otherwise `M` could try to move the state forward and proof
>> this to the upstream node in the onion reply indicating that it was
>> actually `N` who tried to act malicious. In any case if there was a
>> disagreement the upstream nodes would in any case learn that there is a
>> problem on the channel between `N` and `M`.
>>
>>
>> Limitations:
>> =========
>> There are two limitations that I am currently aware of:
>>
>> 1. Being able to ascribe blame does not directly prevent spam via HTLCs
>> 2. With MPP the short `reply_interval` might be an issue as the honest
>> recipient of a partial payment might just not have received enough parts of
>> the entire payment and just can't fulfill the payment yet. In this case the
>> blame is being ascribed to the recipient and nodes would learn the
>> recipient. I hope we could resolve such issues by selecting a higher grace
>> period until we ascribe blame. For example if all the times above are are
>> added to the 60 seconds of timeout that recipients of MPP payments
>> currently have this would not trigger if the sender just needs more time to
>> send partial payments.
>>
>> Advantages:
>> ==========
>> 1. Through the mechanism to ascribe blame several nodes will learn about
>> an malicious or slow actor on the network and can take other preventive
>> measures especially if they also have direct channels with that peer
>> 2. Once we have PTLCs and a protocol for stuckless payments an honest
>> sender of the payment may quickly discard this stuck HTLC (PTLC) and try
>> another path without including the malicious node.
>>
>> Conclusion:
>> =========
>> I am not sure if the suggestions in this proposal are as secure as we
>> need them to be but I wasn't able to detect any obvious flaws which is why
>> I would like to kindly ask you to review and criticize them. What I propose
>> is not the full solution to nodes abusing the possibilities of onion
>> routing and HTLCs spam but I believe it is a step in the right direction
>> towards mitigation by presenting a collection of a few observations which
>> are hopefully useful to bring us a step closer towards guaranteeing fast
>> settlement of payments.
>>
>>
>>
>>
>>
>> Sent with ProtonMail <https://protonmail.com/> Secure Email.
>>
>> _______________________________________________
>> 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/20211216/e0da1706/attachment-0001.html>

2023-06-09 13:04:47

- reply

📅 Original date posted:2021-12-15
📝 Original message:
Good morning,
Thanks for looking into this!
I believe there is another limitation that you're not mentioning: it's
easy for a malicious node to blame an honest node. I'm afraid this is a
serious limitation of the proposal.
If we have a payment: A -> B -> C -> D and C is malicious.
C can forward the payment to D, and even wait for D to correctly settle it
(with `update_fulfill_htlc` or `update_fail_htlc`), but then withhold that
message instead of forwarding it to B. Then C blames D, everyone agrees that
D is bad node that must be avoided. Later, C unblocks the `update_*_htlc`
and everyone thinks that D hodled the HTLC for a long time, which is bad.
Apart from this, I think the blame proof isn't that easy to build.
It cannot simply use `commitment_signed`, because HTLCs are relayed only
once the previous commitment has been revoked (through `revoke_and_ack`).
So the proof should contain data from `commitment_signed` and a proof that
the previous commitment was revoked (and that it was indeed the previous
commitment) which is likely very hard to do securely without disclosing
too much about your channel.
Cheers,
Bastien
Le mer. 15 déc. 2021 à 02:08, lightning developer via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> a écrit :
> Good morning list,
>
> I have just published a proposal to address (but unfortunately not solve)
> the old issue of HTLC spam via onions:
> https://github.com/lightning-developer/lightning-network-documents/blob/main/A%20blame%20ascribing%20protocol%20to%20mitigate%20HTLC%20spam.md
>
> The proposal picks up the early idea by Rusty, AJ and others to ascribe
> blame to a malicious actor but hopefully in a cheaper way than providing
> proof of a channel close by making use of a new lightning message
> `blame_channel` in combination with the proposed onion messages. I guess
> similar ideas and follow ups are already community knowledge (for example
> the local reputation tracking by Jim Posen at:
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-May/001232.html)
> However I had the feeling that the current write up might provide some
> additional value to the community.
>
> The proposal also ensures that blame can be ascribed quickly by requiring
> a reply from the downstream onion that is proportional to the `cltv delta`
> at the hop. In this way a sending node will quickly know that a (and more
> importantly which) downstream channel is not working properly.
>
> I will be delighted to read your feedback, thoughts and criticism. For
> your convenience and archiving I also copied the raw markdown file of the
> proposal to the end of this Mail.
>
> Sincerely Lighting Developer
>
>
> --------- Begin Proposal ----------
>
> # A blame ascribing protocol towards ensuring time limitation of stuck
> HTLCs in flight.
>
> I was reviewing the [HOLD fee proposal by Joost](
> https://github.com/lightning/bolts/pull/843) and the [excellent summary
> of known mitigation techniques by t-bast](
> https://github.com/t-bast/lightning-docs/blob/master/spam-prevention.md)
> when I revisited the very [first idea to mitigate HTLC spam via onions](
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2015-August/000135.html)
> that was discussed back in 2015 by Rusty, AJ and a few others. At that time
> the idea was to ascribe blame to a malicious actor by triggering a force
> close and proofing ones own honesty by providing the force close
> transaction. I think there is a lot of merit to the idea of ascribing blame
> and I think it might be possible with the help of [onion messages](
> https://github.com/lightning/bolts/pull/759) without the necessity to
> trigger full force closes.
>
> As I am not entirely sure if this suggestion is a reasonable improvement
> (it certainly does not resolve all the issues we have) I did not spec out
> the details and message formats and fields but only described the high
> level idea. I hope this is sufficient to discuss the principles and get the
> feedback from you if you consider this to be of use and if you think we
> should work on the details.
>
> Idea / Obervation:
> =============
> The key idea is to set a fixed time in seconds (the `reply_interval`)
> after successfully negotiating an HTLC until when a node requires a
> resultion or reply from its peer to which it previously has forwarded a
> downstream onion. If the HTLC is not resolved and no reply was sent the
> downstream peer is considered to be acting maliciously.
>
> The amount in seconds can be proportional to the `cltv_delta` of that hop.
> To me the arbitrary choice of translating 10 blocks of `cltv_delta` to `1`
> second of expected reply time seems reasonable for now but could be chosen
> differently as long as the entire network (or at least every node included
> to the payment attempt) agrees upon the same conversion rate from
> `cltv_delta` to expected response time from downstream nodes.
>
> There are three cases for the reply:
>
> The Good reply case (HTLC resolution):
> ==============================
> The good case is if the payment will succesfully settle or fail within the
> `reply_interval`. Thus the reply comes in the form of either an
> `update_fulfill_htlc` or an `update_fail_htlc`. In any case the HTLC will
> be removed quickly and the reply can propagate back to the upstream peers.
>
> The bad reply case:
> ===============
> If a node `N` is not able to send one of those two `update_` messages
> because the HTLC was not resolved from the downstream channels it MUST send
> back a new message called `blame_channel`.
>
> The `blame_channel` includes a proof that `N` has previously successfully
> set up the HTLC with the next peer. This may for example be done by
> including the `commitment_signed` message that the node has received from
> the next peer as this commits to this (and potentially other) HTLCs.
> (Alternatively one could extract the relevant `htlc_signature` or adopt
> `commitment_signed` to include a signature to the `payment_hash` that can
> be verified with the node's pubkey)
>
> The propagated bad reply case:
> ========================
> A node might have received an `blame_channel` message from a downstream
> channel and can propagate this back. To disallow spoofing, nodes might
> always have to extend the message with their own signature. (I have not
> thought about this extensively yet). This will make the downstream path of
> the payment transparent to every node on the upstream path (until the slow
> /misbehaving node). Nodes SHOULD propagate the `blame_channel` back in a
> timely manner unless they want to be blamed for the delay themselves.
>
> Extensions:
> =========
> Of course a malicious node `M` might after receiving an `update_add_htlc`
> from a node `N` interrupt the channel state machine at various moments
> before the state successfully moved forward. This would prevent the honest
> node `N` to ascribe blame to the malicious node `M` as it cannot include
> proof that it forwarded the HTLC successfully. Thus instead of including
> the proof of successfully having set up the HTLC the node `N` ascribing
> blame to `M` might include to the `blame_channel` the last messages it sent
> to the downstream peer that have not been acknowledged to be able to proof
> that it tried to move the state machine forward and set up the HTLC.
>
> A node on an upstream channel could verify that `N` was indeed honest and
> has also delivered these messages to `M` by sending these messages via a
> different path as an onion message to `M`.
>
> Now if `M` was indeed dishonest `M` would not respond to the onion message
> indicating to the upstream node that `N` was honestly ascribing blame to
> `M`. Otherwise `M` could try to move the state forward and proof this to
> the upstream node in the onion reply indicating that it was actually `N`
> who tried to act malicious. In any case if there was a disagreement the
> upstream nodes would in any case learn that there is a problem on the
> channel between `N` and `M`.
>
>
> Limitations:
> =========
> There are two limitations that I am currently aware of:
>
> 1. Being able to ascribe blame does not directly prevent spam via HTLCs
> 2. With MPP the short `reply_interval` might be an issue as the honest
> recipient of a partial payment might just not have received enough parts of
> the entire payment and just can't fulfill the payment yet. In this case the
> blame is being ascribed to the recipient and nodes would learn the
> recipient. I hope we could resolve such issues by selecting a higher grace
> period until we ascribe blame. For example if all the times above are are
> added to the 60 seconds of timeout that recipients of MPP payments
> currently have this would not trigger if the sender just needs more time to
> send partial payments.
>
> Advantages:
> ==========
> 1. Through the mechanism to ascribe blame several nodes will learn about
> an malicious or slow actor on the network and can take other preventive
> measures especially if they also have direct channels with that peer
> 2. Once we have PTLCs and a protocol for stuckless payments an honest
> sender of the payment may quickly discard this stuck HTLC (PTLC) and try
> another path without including the malicious node.
>
> Conclusion:
> =========
> I am not sure if the suggestions in this proposal are as secure as we need
> them to be but I wasn't able to detect any obvious flaws which is why I
> would like to kindly ask you to review and criticize them. What I propose
> is not the full solution to nodes abusing the possibilities of onion
> routing and HTLCs spam but I believe it is a step in the right direction
> towards mitigation by presenting a collection of a few observations which
> are hopefully useful to bring us a step closer towards guaranteeing fast
> settlement of payments.
>
>
>
>
> Sent with ProtonMail <https://protonmail.com/> Secure Email.
>
> _______________________________________________
> 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/20211215/67451838/attachment-0001.html>

2023-06-09 13:04:43

- reply

📅 Original date posted:2021-12-08
📝 Original message:
Hi Jeremy,
Right now, lightning anchor outputs use a 330 sats amount. Each commitment
transaction has two such outputs, and only one of them is spent to help the
transaction get confirmed, so the other stays there and bloats the utxo set.
We allow anyone to spend them after a csv of 16 blocks, in the hope that
someone will claim a batch of them when the fees are low and remove them
from the utxo set. However, that trick wouldn't work with 0-value outputs,
as
no-one would ever claim them (doesn't make economical sense).
We actually need to have two of them to avoid pinning: each participant is
able to spend only one of these outputs while the parent tx is unconfirmed.
I believe N-party protocols would likely need N such outputs (not sure).
You mention a change to the carve-out rule, can you explain it further?
I believe it would be a necessary step, otherwise 0-value outputs for
CPFP actually seem worse than low-value ones...
Thanks,
Bastien
Le mer. 8 déc. 2021 à 02:29, Jeremy via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> a écrit :
> Bitcoin Devs (+cc lightning-dev),
>
> Earlier this year I proposed allowing 0 value outputs and that was shot
> down for various reasons, see
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-August/019307.html
>
> I think that there can be a simple carve out now that package relay is
> being launched based on my research into covenants from 2017
> https://rubin.io/public/pdfs/multi-txn-contracts.pdf.
>
> Essentially, if we allow 0 value outputs BUT require as a matter of policy
> (or consensus, but policy has major advantages) that the output be used as
> an Intermediate Output (that is, in order for the transaction to be
> creating it to be in the mempool it must be spent by another tx) with the
> additional rule that the parent must have a higher feerate after CPFP'ing
> the parent than the parent alone we can both:
>
> 1) Allow 0 value outputs for things like Anchor Outputs (very good for not
> getting your eltoo/Decker channels pinned by junk witness data using Anchor
> Inputs, very good for not getting your channels drained by at-dust outputs)
> 2) Not allow 0 value utxos to proliferate long
> 3) It still being valid for a 0 value that somehow gets created to be
> spent by the fee paying txn later
>
> Just doing this as a mempool policy also has the benefits of not
> introducing any new validation rules. Although in general the IUTXO concept
> is very attractive, it complicates mempool :(
>
> I understand this may also be really helpful for CTV based contracts (like
> vault continuation hooks) as well as things like spacechains.
>
> Such a rule -- if it's not clear -- presupposes a fully working package
> relay system.
>
> I believe that this addresses all the issues with allowing 0 value outputs
> to be created for the narrow case of immediately spendable outputs.
>
> Cheers,
>
> Jeremy
>
> p.s. why another post today? Thank Greg
> https://twitter.com/JeremyRubin/status/1468390561417547780
>
>
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>
> <https://twitter.com/JeremyRubin>
> _______________________________________________
> 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/lightning-dev/attachments/20211208/58427839/attachment.html>

2023-06-09 13:04:42

- reply

📅 Original date posted:2021-12-22
📝 Original message:
Hey AJ,
Right, I was probably confused between local/remote, especially when
we're talking about our anchor in the remote commitment (should it be
called local anchor, which is from our point of view, or remote?).
Let's call them Alice and Bob, and Bob is publishing a commitment.
Correct me if I'm wrong there, what you're suggesting is that:
* Bob's anchor on Bob's commitment can be spent with revkey
* Alice's anchor on Bob's commitment can be spent with Alice's pubkey
This does ensure that each participant is able to claim their anchor in
the latest commitment, and Alice is able to claim both anchors in any of
Bob's outdated commitments.
But I think it defeats the `OP_16 OP_CHECKSEQUENCEVERIFY` script branch.
We have that branch to allow anyone to spend anchor outputs *after* the
commitment is confirmed, to avoid keeping them around in the utxo set
forever. However, the trick is that the internal pubkey must be set to
something that is publicly revealed when the channel closes. Now that we
put the revkey in internal pubkeys everywhere instead of script branches,
that revkey is *not* revealed when channels close with the latest commit.
So it would prevent people from using that script branch to clean up the
utxo set...
I have currently used <local_delayedpubkey> and <remote_pubkey> because
they're revealed whenever main outputs are claimed, but there is probably
a smarter solution (maybe one that would let us use revkey here as you
suggest), this will be worth thinking about a bit more.
Thanks,
Bastien
Le mar. 21 déc. 2021 à 17:04, Anthony Towns <aj at erisian.com.au> a écrit :
> On Tue, Dec 21, 2021 at 04:25:41PM +0100, Bastien TEINTURIER wrote:
> > The reason we have "toxic waste" with HTLCs is because we commit to the
> > payment_hash directly inside the transaction scripts, so we need to
> > remember all the payment_hash we've seen to be able to recreate the
> > scripts (and spend the outputs, even if they are revoked).
>
> I think "toxic waste" refers to having old data around that, if used,
> could cause you to lose all the funds in your channel -- that's why it's
> toxic. This is more just regular landfill :)
>
> > *_anchor: dust, who cares -- might be better if local_anchor used key =
> > > revkey
> > I don't think we can use revkey,
>
> musig(revkey, remote_key)
> --> allows them to spend after you've revealed the secret for revkey
> you can never spend because you'll never know the secret for
> remote_key
>
> but if you just say:
>
> (revkey)
>
> then you can spend (because you know revkey) immediately (because it's
> an anchor output, so intended to be immediately spent) or they can spend
> if it's an obsolete commitment and you've revealed the revkey secret.
>
> > this would prevent us from bumping the
> > current remote commitment if it appears on-chain (because we don't know
> > the private revkey yet if this is the latest commitment). Usually the
> > remote peer should bump it, but if they don't, we may want to bump it
> > ourselves instead of publishing our own commitment (where our main
> > output has a long CSV).
>
> If we're going to bump someone else's commitment, we'll use the
> remote_anchor they provided, not the local_anchor, so I think this is
> fine (as long as I haven't gotten local/remote confused somewhere along
> the way).
>
> Cheers,
> aj
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211222/84da9f4a/attachment-0001.html>

2023-06-09 13:04:41

- reply

📅 Original date posted:2021-12-21
📝 Original message:
Hey AJ and list,
That's a very good point, it's really worth highlighting!
The reason we have "toxic waste" with HTLCs is because we commit to the
payment_hash directly inside the transaction scripts, so we need to
remember all the payment_hash we've seen to be able to recreate the
scripts (and spend the outputs, even if they are revoked).
But with PTLCs, we commit to a payment_point outside of the scripts (in
the adaptor signature that is exchanged), so we're able to recreate the
scripts independently of the payment details! This also means that the
payment_point never appears on-chain (which is good for privacy) whereas
the payment_hash does appear on-chain for HTLCs.
*_anchor: dust, who cares -- might be better if local_anchor used key =
> revkey
I don't think we can use revkey, this would prevent us from bumping the
current remote commitment if it appears on-chain (because we don't know
the private revkey yet if this is the latest commitment). Usually the
remote peer should bump it, but if they don't, we may want to bump it
ourselves instead of publishing our own commitment (where our main
output has a long CSV).
But as you already mentioned, who cares, it's dust and we don't even need
it to CPFP the revoked commitment, we can use any other output since the
revocation path isn't encumbered with a CSV 1.
Cheers,
Bastien
Le dim. 19 déc. 2021 à 23:23, Anthony Towns <aj at erisian.com.au> a écrit :
> On Wed, Dec 08, 2021 at 04:02:02PM +0100, Bastien TEINTURIER wrote:
> > I updated my article [0], people jumping on the thread now may find it
> > helpful to better understand this discussion.
> > [0] https://github.com/t-bast/lightning-docs/pull/16
>
> Since merged, so
> https://github.com/t-bast/lightning-docs/blob/master/taproot-updates.md
>
> So imagine that this proposal is finished and widely adopted/deployed
> and someone adds an additional feature bit that allows a channel to
> forward PTLCs only, no HTLCs.
>
> Then suppose that you forget every old PTLC, because you don't like
> having your channel state grow without bound. What happens if your
> counterparty broadcasts an old state?
>
> * the musig2 channel funding is irrelevant -- the funding tx has been
> spend at this point
>
> * the unspent commitment outputs pay to:
> to_local: ipk = musig(revkey, mykey) -- known ; scripts also known
> to_remote: claimable in 1 block, would be better if ipk was also musig
> *_anchor: dust, who cares -- might be better if local_anchor used
> key = revkey
> *_htlc: irrelevant by definition
> local_ptlc: ipk = musig(revkey, mykey) -- known; scripts also known
>
> * commitment outputs may be immediately spent via layered txs. if so,
> their outputs are: ipk = musig(revkey, mykey); with fixed scripts,
> that include a relative timelock
>
> So provided you know the revocation key (which you do, because it's an
> old transaction and that only requires log(states) data to reconstruct)
> and your own private key, you can reconstruct all the scripts and use
> key path spends for every output immediately (excepting the local_anchor,
> and to_remote is delayed by a block).
>
> So while this doesn't achieve eltoo's goal of "no toxic waste", I believe
> it does achieve the goal of "state information is bounded no matter
> how long you leave the channel open / how many transactions travel over
> the channel".
>
> (Provided you're willing to wait for the other party to attempt to claim
> a htlc via their layered transaction, you can use this strategy for
> htlcs as well as ptlcs -- however this leaves you the risk that they
> never attempt to claim the funds, which may leave you out of pocket,
> and may give them the opportunity to do an attack along the lines of
> "you don't get access to the $10,000 locked in old HTLCs unless you pay
> me $1,000". So I don't think that's really a smart thing to do)
>
> Cheers,
> aj
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211221/471cbd0d/attachment.html>

2023-06-09 13:04:39

- reply

📅 Original date posted:2021-12-08
📝 Original message:
Hi again AJ and list,
I have slightly re-worked your proposal, and came up with the following
(I also added the musig2 nonces for completeness):
Alice -> Bob: commitment_proposed
channel id
adaptor sigs for PTLCs to Bob in Alice's next commitment
musig nonces for Alice to spend funding tx
musig nonces for Bob to spend funding tx
Bob -> Alice: commitment_proposed
channel id
adaptor sigs for PTLCs to Alice in Bob's next commitment
musig nonces for Alice to spend funding tx
musig nonces for Bob to spend funding tx
Bob -> Alice: commitment_signed
channel id
signature for Alice to spend funding tx
sigs for Alice to spend HTLCs and PTLCs from her next commitment
Alice -> Bob: revoke_and_ack
channel id
reveal previous commitment secret
next commitment point
Alice -> Bob: commitment_signed
channel id
signature for Bob to spend funding tx
sigs for Bob to spend HTLCs and PTLCs from his next commitment
Bob -> Alice: revoke_and_ack
channel id
reveal previous commitment secret
next commitment point
I believe it's exactly the same flow of data between peers as your
proposal, but I simply split the data into several messages. Let me
know if that's incorrect or if I missed a subtlety in your proposal.
This has some small advantages:
* commitment_signed and revoke_and_ack are mostly unchanged, we just
add a new message before the commit / revoke dance. The only change
happens in commitment_signed, where the signatures for PTLC-success
transactions will actually become adaptor signatures.
* the new adaptor signatures are in commitment_proposed instead of being
in commitment_signed, which ensures that we can still have 2*483
pending (H|P)TLCs: since the message size is limited to 65kB, we would
otherwise decrease our maximum to ~2*335 with your proposal (very rough
calculation)
* the messages are now symmetrical, which may be easier to reason about
One thing to note is that we reversed the order in which participants
sign new commitments. We previously had Alice sign first, whereas now
if Alice initiates, Bob will sign the updated commitment first. This is
why we add only 0.5 RTT instead of 1 RTT compared to the current protocol.
I don't think this is an issue, but if someone sees a way to maliciously
exploit this, please share it!
I updated my article [0], people jumping on the thread now may find it
helpful to better understand this discussion.
Thanks,
Bastien
[0] https://github.com/t-bast/lightning-docs/pull/16
Le mer. 8 déc. 2021 à 11:00, Bastien TEINTURIER <bastien at acinq.fr> a écrit :
> Hi AJ,
>
> I think the problem t-bast describes comes up here as well when you
>> collapse the fast-forwards (or, anytime you update the commitment
>> transaction even if you don't collapse them).
>
>
> Yes, exactly.
>
> I think doing a synchronous update of commitments to the channel state,
>> something like:
>
>
>
> Alice -> Bob: propose_new_commitment
>> channel id
>> adaptor sigs for PTLCs to Bob
>
>
>> Bob -> Alice: agree_new_commitment
>> channel id
>> adaptor sigs for PTLCs to Alice
>> sigs for Alice to spend HTLCs and PTLCs to Bob from her own
>> commitment tx
>> signature for Alice to spend funding tx
>>
>> Alice -> Bob: finish_new_commitment_1
>> channel id
>> sigs for Bob to spend HTLCs and PTLCs to Alice from his own
>> commitment tx
>> signature for Bob to spend funding tx
>> reveal old prior commitment secret
>> new commitment nonce
>>
>> Bob -> Alice: finish_new_commitment_2
>> reveal old prior commitment secret
>> new commitment nonce
>>
>> would work pretty well.
>
>
> I agree, this is better than my naive addition of a `remote_ptlcs_signed`
> message in both directions, and even though it changes the protocol
> messages
> it stays very close to the mechanisms we currently have.
>
> I'll spend some time specifying this in more details, to verify that we're
> not missing anything. What I really like about this proposal is that we
> can probably bundle that protocol change with `option_simplified_update`
> [0]
> without the adaptor sigs, and simply add the adaptor sigs as tlvs when we
> do PTLCs. That lets us deploy this new update protocol separately from
> PTLCs
> and ensure it also simplifies the state machine and makes other features
> such as splicing [1] and dynamic channel upgrades [2] easier.
>
> Thanks,
> Bastien
>
> [0] https://github.com/lightning/bolts/pull/867
> [1] https://github.com/lightning/bolts/pull/863
> [2] https://github.com/lightning/bolts/pull/868
>
> Le mer. 8 déc. 2021 à 10:29, Anthony Towns <aj at erisian.com.au> a écrit :
>
>> On Tue, Dec 07, 2021 at 11:52:04PM +0000, ZmnSCPxj via Lightning-dev
>> wrote:
>> > Alternately, fast-forwards, which avoid this because it does not change
>> commitment transactions on the payment-forwarding path.
>> > You only change commitment transactions once you have enough changes to
>> justify collapsing them.
>>
>> I think the problem t-bast describes comes up here as well when you
>> collapse the fast-forwards (or, anytime you update the commitment
>> transaction even if you don't collapse them).
>>
>> That is, if you have two PTLCs, one from A->B conditional on X, one
>> from B->A conditional on Y. Then if A wants to update the commitment tx,
>> she needs to
>>
>> 1) produce a signature to give to B to spend the funding tx
>> 2) produce an adaptor signature to authorise B to spend via X from his
>> commitment tx
>> 3) produce a signature to allow B to recover Y after timeout from his
>> commitment tx spending to an output she can claim if he cheats
>> 4) *receive* an adaptor signature from B to be able to spend the Y
>> output
>> if B posts his commitment tx using A's signature in (1)
>>
>> The problem is, she can't give B the result of (1) until she's received
>> (4) from B.
>>
>> It doesn't matter if the B->A PTLC conditional on Y is in the commitment
>> tx itself or within a fast-forward child-transaction -- any previous
>> adaptor sig will be invalidated because there's a new commitment
>> transaction, and if you allowed any way of spending without an adaptor
>> sig, B wouldn't be able to recover the secret and would lose funds.
>>
>> It also doesn't matter if the commitment transaction that A and B will
>> publish is the same or different, only that it's different from the
>> commitment tx that previous adaptor sigs committed to. (So ANYPREVOUT
>> would fix this if it were available)
>>
>> So I think this is still a relevant question, even if fast-forwards
>> make it a rare problem, that perhaps is only applicable to very heavily
>> used channels.
>>
>> (I said the following in email to t-bast already)
>>
>> I think doing a synchronous update of commitments to the channel state,
>> something like:
>>
>> Alice -> Bob: propose_new_commitment
>> channel id
>> adaptor sigs for PTLCs to Bob
>>
>> Bob -> Alice: agree_new_commitment
>> channel id
>> adaptor sigs for PTLCs to Alice
>> sigs for Alice to spend HTLCs and PTLCs to Bob from her own
>> commitment tx
>> signature for Alice to spend funding tx
>>
>> Alice -> Bob: finish_new_commitment_1
>> channel id
>> sigs for Bob to spend HTLCs and PTLCs to Alice from his own
>> commitment tx
>> signature for Bob to spend funding tx
>> reveal old prior commitment secret
>> new commitment nonce
>>
>> Bob -> Alice: finish_new_commitment_2
>> reveal old prior commitment secret
>> new commitment nonce
>>
>> would work pretty well.
>>
>> This adds half a round-trip compared to now:
>>
>> Alice -> Bob: commitment_signed
>> Bob -> Alice: revoke_and_ack, commitment_signed
>> Alice -> Bob: revoke_and_ack
>>
>> The timings change like so:
>>
>> Bob can use the new commitment after 1.5 round-trips (previously 0.5)
>>
>> Alice can be sure Bob won't use the old commitment after 2 round-trips
>> (previously 1)
>>
>> Alice can use the new commitment after 1 round-trip (unchanged)
>>
>> Bob can be sure Alice won't use the old commitment after 1.5 round-trips
>> (unchanged -- note: this is what's relevant for forwarding)
>>
>> Making the funding tx a musig setup would mean also supplying 64B
>> of musig2 nonces along with the "adaptor sigs" in one direction,
>> and providing the other side's 64B of musig2 nonces back along with the
>> (now partial) signature for spending the funding tx (a total of 256B of
>> nonce data, not 128B).
>>
>> Because it keeps both peers' commitments synchronised to a single channel
>> state, I think the same protocol should work fine with the revocable
>> signatures on a single tx approach too, though I haven't tried working
>> through the details.
>>
>> Fast forwards would then be reducing the 2 round-trip protocol to
>> update the state commitment to a 0.5 round-trip update, to reduce
>> latency when forwarding by the same amount as before (1.5 round-trips
>> to 0.5 round-trips).
>>
>> Cheers,
>> aj
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211208/3072a12d/attachment.html>

2023-06-09 13:04:39

- reply

📅 Original date posted:2021-12-08
📝 Original message:
Hi AJ,
I think the problem t-bast describes comes up here as well when you
> collapse the fast-forwards (or, anytime you update the commitment
> transaction even if you don't collapse them).
Yes, exactly.
I think doing a synchronous update of commitments to the channel state,
> something like:
Alice -> Bob: propose_new_commitment
> channel id
> adaptor sigs for PTLCs to Bob
> Bob -> Alice: agree_new_commitment
> channel id
> adaptor sigs for PTLCs to Alice
> sigs for Alice to spend HTLCs and PTLCs to Bob from her own
> commitment tx
> signature for Alice to spend funding tx
>
> Alice -> Bob: finish_new_commitment_1
> channel id
> sigs for Bob to spend HTLCs and PTLCs to Alice from his own
> commitment tx
> signature for Bob to spend funding tx
> reveal old prior commitment secret
> new commitment nonce
>
> Bob -> Alice: finish_new_commitment_2
> reveal old prior commitment secret
> new commitment nonce
>
> would work pretty well.
I agree, this is better than my naive addition of a `remote_ptlcs_signed`
message in both directions, and even though it changes the protocol messages
it stays very close to the mechanisms we currently have.
I'll spend some time specifying this in more details, to verify that we're
not missing anything. What I really like about this proposal is that we
can probably bundle that protocol change with `option_simplified_update` [0]
without the adaptor sigs, and simply add the adaptor sigs as tlvs when we
do PTLCs. That lets us deploy this new update protocol separately from PTLCs
and ensure it also simplifies the state machine and makes other features
such as splicing [1] and dynamic channel upgrades [2] easier.
Thanks,
Bastien
[0] https://github.com/lightning/bolts/pull/867
[1] https://github.com/lightning/bolts/pull/863
[2] https://github.com/lightning/bolts/pull/868
Le mer. 8 déc. 2021 à 10:29, Anthony Towns <aj at erisian.com.au> a écrit :
> On Tue, Dec 07, 2021 at 11:52:04PM +0000, ZmnSCPxj via Lightning-dev wrote:
> > Alternately, fast-forwards, which avoid this because it does not change
> commitment transactions on the payment-forwarding path.
> > You only change commitment transactions once you have enough changes to
> justify collapsing them.
>
> I think the problem t-bast describes comes up here as well when you
> collapse the fast-forwards (or, anytime you update the commitment
> transaction even if you don't collapse them).
>
> That is, if you have two PTLCs, one from A->B conditional on X, one
> from B->A conditional on Y. Then if A wants to update the commitment tx,
> she needs to
>
> 1) produce a signature to give to B to spend the funding tx
> 2) produce an adaptor signature to authorise B to spend via X from his
> commitment tx
> 3) produce a signature to allow B to recover Y after timeout from his
> commitment tx spending to an output she can claim if he cheats
> 4) *receive* an adaptor signature from B to be able to spend the Y output
> if B posts his commitment tx using A's signature in (1)
>
> The problem is, she can't give B the result of (1) until she's received
> (4) from B.
>
> It doesn't matter if the B->A PTLC conditional on Y is in the commitment
> tx itself or within a fast-forward child-transaction -- any previous
> adaptor sig will be invalidated because there's a new commitment
> transaction, and if you allowed any way of spending without an adaptor
> sig, B wouldn't be able to recover the secret and would lose funds.
>
> It also doesn't matter if the commitment transaction that A and B will
> publish is the same or different, only that it's different from the
> commitment tx that previous adaptor sigs committed to. (So ANYPREVOUT
> would fix this if it were available)
>
> So I think this is still a relevant question, even if fast-forwards
> make it a rare problem, that perhaps is only applicable to very heavily
> used channels.
>
> (I said the following in email to t-bast already)
>
> I think doing a synchronous update of commitments to the channel state,
> something like:
>
> Alice -> Bob: propose_new_commitment
> channel id
> adaptor sigs for PTLCs to Bob
>
> Bob -> Alice: agree_new_commitment
> channel id
> adaptor sigs for PTLCs to Alice
> sigs for Alice to spend HTLCs and PTLCs to Bob from her own
> commitment tx
> signature for Alice to spend funding tx
>
> Alice -> Bob: finish_new_commitment_1
> channel id
> sigs for Bob to spend HTLCs and PTLCs to Alice from his own
> commitment tx
> signature for Bob to spend funding tx
> reveal old prior commitment secret
> new commitment nonce
>
> Bob -> Alice: finish_new_commitment_2
> reveal old prior commitment secret
> new commitment nonce
>
> would work pretty well.
>
> This adds half a round-trip compared to now:
>
> Alice -> Bob: commitment_signed
> Bob -> Alice: revoke_and_ack, commitment_signed
> Alice -> Bob: revoke_and_ack
>
> The timings change like so:
>
> Bob can use the new commitment after 1.5 round-trips (previously 0.5)
>
> Alice can be sure Bob won't use the old commitment after 2 round-trips
> (previously 1)
>
> Alice can use the new commitment after 1 round-trip (unchanged)
>
> Bob can be sure Alice won't use the old commitment after 1.5 round-trips
> (unchanged -- note: this is what's relevant for forwarding)
>
> Making the funding tx a musig setup would mean also supplying 64B
> of musig2 nonces along with the "adaptor sigs" in one direction,
> and providing the other side's 64B of musig2 nonces back along with the
> (now partial) signature for spending the funding tx (a total of 256B of
> nonce data, not 128B).
>
> Because it keeps both peers' commitments synchronised to a single channel
> state, I think the same protocol should work fine with the revocable
> signatures on a single tx approach too, though I haven't tried working
> through the details.
>
> Fast forwards would then be reducing the 2 round-trip protocol to
> update the state commitment to a 0.5 round-trip update, to reduce
> latency when forwarding by the same amount as before (1.5 round-trips
> to 0.5 round-trips).
>
> Cheers,
> aj
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211208/e5173822/attachment.html>

2023-06-09 13:04:38

- reply

📅 Original date posted:2021-12-08
📝 Original message:
Hi Z,
`SIGHASH_NONE | SIGHASH_NOINPUT` (which will take another what, four
> years?) or a similar "covenant" opcode,
such as `OP_CHECKTEMPLATEVERIFY` without any commitments or an
> `OP_CHECKSIGFROMSTACK` on an empty message.
> All you really need is a signature for an empty message, really...
>
That fails my requirement of "deployable in 2022" :)
Same thing applies to fast-forwards: I do see their value, but I'd like to
focus on a first version with minimal changes to the transaction structure
and the update protocol, to ensure we can actually get agreement on it
somewhat quickly and ship it in 2022. Then we can start working on a
more ambitious rework of the protocol that adds a lot of cool features,
such as what AJ proposed recently.
Cheers,
Bastien
Le mer. 8 déc. 2021 à 00:52, ZmnSCPxj <ZmnSCPxj at protonmail.com> a écrit :
> Good morning t-bast,
>
>
> > I believe these new transactions may require an additional round-trip.
> > Let's take a very simple example, where we have one pending PTLC in each
> > direction: PTLC_AB was offered by A to B and PTLC_BA was offered by B to
> A.
> >
> > Now A makes some unrelated updates and wants to sign a new commitment.
> > A cannot immediately send her `commitment_signed` to B.
> > If she did, B would be able to broadcast this new commitment, and A would
> > not be able to claim PTLC_BA from B's new commitment (even if she knew
> > the payment secret) because she wouldn't have B's signature for the new
> > PTLC-remote-success transaction.
> >
> > So we first need B to send a new message `remote_ptlcs_signed` to A that
> > contains B's adaptor signatures for the PTLC-remote-success transactions
> > that would spend B's future commitment. After that A can safely send her
> > `commitment_signed`. Similarly, A must send `remote_ptlcs_signed` to B
> > before B can send its `commitment_signed`.
> >
> > It's actually not that bad, we're only adding one message in each
> direction,
> > and we're not adding more data (apart from nonces) to existing messages.
> >
> > If you have ideas on how to avoid this new message, I'd be glad to hear
> > them, hopefully I missed something again and we can make it better!
>
> `SIGHASH_NONE | SIGHASH_NOINPUT` (which will take another what, four
> years?) or a similar "covenant" opcode, such as `OP_CHECKTEMPLATEVERIFY`
> without any commitments or an `OP_CHECKSIGFROMSTACK` on an empty message.
> All you really need is a signature for an empty message, really...
>
> Alternately, fast-forwards, which avoid this because it does not change
> commitment transactions on the payment-forwarding path.
> You only change commitment transactions once you have enough changes to
> justify collapsing them.
> Even in the aj formulation, when A adds a PTLC it only changes the
> transaction that hosts **only** A->B PTLCs as well as the A main output,
> all of which can be sent outright by A without changing any B->A PTLCs.
>
> Basically... instead of a commitment tx like this:
>
> +-------+
> funding outpoint -->| |--> A main
> | |--> B main
> | |--> A->B PTLC
> | |--> B->A PTLC
> +-------+
>
> We could do this instead:
>
> +-------+2of2 +-----+
> funding outpoint -->| |----->| |--> A main
> | | | |--> A->B PTLC
> | | +-----+
> | |2or2 +-----+
> | |----->| |--> B main
> | | | |--> B->A PTLC
> +-------+ +-----+
>
> Then whenever A wants to add a new A->B PTLC it only changes the tx inputs
> of the *other* A->B PTLCs without affecting the B->A PTLCs.
> Payment forwarding is fast, and you only change the "big" commitment tx
> rarely to clean up claimed and failed PTLCs, moving the extra messages out
> of the forwarding hot path.
>
> But this is basically highly similar to what aj designed anyway, so...
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211208/531e3f1e/attachment-0001.html>

2023-06-09 13:04:37

- reply

📅 Original date posted:2021-12-07
📝 Original message:
Hi Z, Lloyd,
Let's ignore the musig nonce exchanges for now. I believe these can be
easily included in existing messages: they probably aren't the reason we
need more round-trips (at least not the one I'm concerned about for now).
Basically, if my memory and understanding are accurate, in the above,
> it is the *PTLC-offerrer* which provides an adaptor signature.
> That adaptor signature would be included in the `update_add_ptlc` message.
Neat, you're completely right, I didn't realize that the adaptor signature
could be completed by the other party, this is a great property I had
missed.
Thanks for pointing it out, it does simplify the protocol a lot!
I don't think you can include it in `update_add_ptlc` though, it has to
be in `commitment_signed`, because if you do a batch of updates before
signing, you would immediately invalidate the adaptor signatures you
previously sent.
But it would be a simple change, where the signatures in `commitment_signed`
would actually be adaptor signatures for PTLC-success transactions and
normal signatures for PTLC-timeout transactions.
Isn't it the case that all previous PTLC adaptor signatures need to be
> re-sent for each update_add_ptlc message because the signatures would
> no longer be valid once the commit tx changes
Yes indeed, whenever the commitment changes, peers need to create new
signatures and adaptor signatures for all pending PTLCs.
This is completely fine for PTLC-success and PTLC-timeout transactions,
but we also need to exchange signatures for the new pre-signed transactions
that spend a PTLC from the remote commitment. Let's call this new pre-signed
transaction PTLC-remote-success (not a great name).
I believe these new transactions may require an additional round-trip.
Let's take a very simple example, where we have one pending PTLC in each
direction: PTLC_AB was offered by A to B and PTLC_BA was offered by B to A.
Now A makes some unrelated updates and wants to sign a new commitment.
A cannot immediately send her `commitment_signed` to B.
If she did, B would be able to broadcast this new commitment, and A would
not be able to claim PTLC_BA from B's new commitment (even if she knew
the payment secret) because she wouldn't have B's signature for the new
PTLC-remote-success transaction.
So we first need B to send a new message `remote_ptlcs_signed` to A that
contains B's adaptor signatures for the PTLC-remote-success transactions
that would spend B's future commitment. After that A can safely send her
`commitment_signed`. Similarly, A must send `remote_ptlcs_signed` to B
before B can send its `commitment_signed`.
It's actually not that bad, we're only adding one message in each direction,
and we're not adding more data (apart from nonces) to existing messages.
If you have ideas on how to avoid this new message, I'd be glad to hear
them, hopefully I missed something again and we can make it better!
Thanks,
Bastien
Le mar. 7 déc. 2021 à 09:04, ZmnSCPxj <ZmnSCPxj at protonmail.com> a écrit :
> Good morning LL, and t-bast,
>
> > > Basically, if my memory and understanding are accurate, in the above,
> it is the *PTLC-offerrer* which provides an adaptor signature.
> > > That adaptor signature would be included in the `update_add_ptlc`
> message.
> >
> > Isn't it the case that all previous PTLC adaptor signatures need to be
> re-sent for each update_add_ptlc message because the signatures would no
> longer be valid once the commit tx changes. I think it's better to put it
> in `commitment_signed` if possible. This is what is done with pre-signed
> HTLC signatures at the moment anyway.
>
> Agreed.
>
> This is also avoided by fast-forwards, BTW, simply because fast-forwards
> delay the change of the commitment tx.
> It is another reason to consider fast-forwards, too....
>
> Regards,
> ZmnSCPxj
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211207/55feef47/attachment.html>

2023-06-09 13:04:36

- reply

📅 Original date posted:2021-12-06
📝 Original message:
Good morning list,
There was a great recent post on the mailing list detailing how we could
do PTLCs on lightning with a lot of other goodies [0]. This proposal
contained heavy changes to the transaction structure and the update
protocol. While it's certainly something we'll want to do in the long
run, I wanted to explore the minimal set of changes we would need to be
able to deploy PTLCs as soon as possible.
The current result is a somewhat high-level article, where each section
could be a separate update of the lightning protocol [1].
I tried to make PTLCs work with minimal changes to the transaction
structure and the update protocol, but they introduce a fundamental
change which forces us to make more changes than I'd like.
With HTLCs, the payment secret (the preimage of the payment hash) was
directly revealed in the witness of a spending transaction.
With PTLCs, this isn't the case anymore. The payment secret is a private
key, and a spending transaction only reveals that key if you have a
matching adaptor signature. This forces us to make two changes:
1. We must obtain adaptor signatures before sending our commit_sig
2. We must use a pre-signed HTLC-success transaction not only with our
local commit, but also with the remote commit
This means that we will need more round-trips whenever we update our
commitment. I'd like to find the right design trade-off where we don't
introduce too many changes in the protocol while minimizing the number
of additional round-trips.
We currently exchange the following messages:
Alice Bob
update_add_htlc
--------------------------->
update_add_htlc
--------------------------->
update_add_htlc
--------------------------->
commit_sig
--------------------------->
revoke_and_ack
<---------------------------
commit_sig
<---------------------------
revoke_and_ack
--------------------------->
It works well because the commit_sig sent by Alice only contains signatures
for Bob's transactions (commit and htlc transactions), and the commit_sig
sent by Bob only contains signatures for Alice's transactions, and Alice
and Bob don't need anything else to spend outputs from either commitment.
But with PTLCs, Bob needs a signature from Alice to be able to fulfill a
PTLC from Alice's commitment. And Alice needs Bob to provide an adaptor
signature for that transaction before she can give him her signature.
We don't have the clean ordering that we had before.
The designs I came up with that keep the current messages and just insert
new ones are either too costly (too many additional round-trips) or too
complex (most likely broken in some edge cases).
I believe we need to change the commit_sig / revoke_and_ack protocol if
we want to find the sweet spot I'm looking for. I'd like to collect ideas
from this list's participants on how we could do that. This is probably
something that should be bundled with option_simplified_commitment [2]
(or at least we must ensure that option_simplified_commitment is a first
step towards the protocol we'll need for PTLCs). It's also important to
note that the protocol changes must work for both HTLCs and PTLCs, and
shouldn't change the structure of the transactions (not more than the
simple addition of PTLC outputs done in [1]).
Cheers,
Bastien
[0]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-October/003278.html
[1] https://github.com/t-bast/lightning-docs/pull/16
[2] https://github.com/lightning/bolts/pull/867
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211206/c474a332/attachment-0001.html>

2023-06-09 13:04:15

- reply

📅 Original date posted:2021-10-19
📝 Original message:
Hi Matt,
I like this proposal, it's a net improvement compared to hodling HTLCs
at the recipient's LSP. With onion messages, we do have all the tools we
need to build this. I don't think we can do much better than that anyway
if we want to keep payments fully non-custodial. This will be combined
with notifications to try to get the recipient to go online asap.
One thing to note is that the senders also need to come online while
the payment isn't settled, otherwise there is a risk they'll lose their
channels. If the sender's LSP receives the preimage but the sender does
not come online, the sender's LSP will have to force-close to claim the
HTLC on-chain when it gets close to the timeout.
Definitely not a show-stopper, just an implementation detail to keep in
mind.
Bastien
Le jeu. 14 oct. 2021 à 02:20, ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> a écrit :
> Good morning Matt,
>
> > On 10/13/21 02:58, ZmnSCPxj wrote:
> >
> > > Good morning Matt,
> > >
> > > > The Obvious (tm) solution here is PTLCs - just have the sender
> always add some random nonce * G to
> > > > the PTLC they're paying and send the recipient a random nonce
> in the onion. I'd generally suggest we
> > > > just go ahead and do this for every PTLC payment, cause why
> not? Now the sender and the lnurl
> > > > endpoint have to collude to steal the funds, but, like, the
> sender could always just give the lnurl
> > > > endpoint the money. I'd love suggestions for fixing this short
> of PTLCs, but its not immediately
> > > > obvious to me that this is possible.
> > > >
> > >
> > > Use two hashes in an HTLC instead of one, where the second hash is
> from a preimage the sender generates, and which the sender sends (encrypted
> via onion) to the receiver.
> > > You might want to do this anyway in HTLC-land, consider that we have a
> `payment_secret` in invoices, the second hash could replace that, and
> provide similar protection to what `payment_secret` provides (i.e.
> resistance against forwarding nodes probing; the information in both cases
> is private to the ultimate sender and ultimate reeceiver).
> >
> > Yes, you could create a construction which does this, sure, but I'm not
> sure how you'd do this
> > without informing every hop along the path that this is going on, and
> adapting each hop to handle
> > this as well. I suppose I should have been more clear with the
> requirements, or can you clarify
> > somewhat what your proposed construction is?
>
> Just that: two hashes instead of one.
> Make *every* HTLC on LN use two hashes, even for current "online RPi user
> pays online RPi user" --- just use the `payment_secret` for the preimage of
> the second hash, the sender needs to send it anyway.
>
> >
> > If you're gonna adapt every node in the path, you might as well just use
> PTLC.
>
> Correct, we should just do PTLCs now.
> (Basically, my proposal was just a strawman to say "we should just do
> PTLCs now")
>
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> 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/20211019/8844e3dc/attachment.html>

2023-06-09 13:03:52

- reply

📅 Original date posted:2021-09-22
📝 Original message:
Hi,
This is exactly what the dual funding proposal provides:
https://github.com/lightningnetwork/lightning-rfc/pull/851
Cheers,
Bastien
Le mer. 22 sept. 2021 à 07:29, Ole Henrik Skogstrøm <oleskogstrom at gmail.com>
a écrit :
> Hi
>
> I have found a way of opening balanced channels using LND's psbt option
> when opening channels. What I'm doing is essentially just joining funded
> PSBTs before signing and submitting them. This makes it possible to open a
> balanced channel between two nodes or open a ring of balanced channels
> between multiple nodes (ROF).
>
> I found this interesting, however I don't know if this is somehow unsafe
> or for some other reason a bad idea. If not, then it could be an
> interesting alternative to only being able to open unbalanced channels.
>
> To do this efficiently, nodes need to collaborate by sending PSBTs back
> and forth to each other and doing this manually is a pain, so if this makes
> sense to do, it would be best to automate it through a client.
>
> ----------------------
> --- Here is an example of the complete flow for a single channel:
> ----------------------
>
> ** Node A: generates a new address and sends address to Node B *(lncli
> newaddress p2wkh)
>
> ** Node A starts an Interactive channel **open** to Node B* *using psbt*
> (lncli openchannel --psbt <node_b_pubkey> 2000000 1000000)
>
> ** Node A funds the channel address *(bitcoin-cli walletcreatefundedpsbt
> [] '[{"<channel_address>":0.02}]')
>
> ** Node B funds the refund transaction to Node A and sends PSBT back to
> Node A (*bitcoin-cli walletcreatefundedpsbt []
> '[{"<node_a_return_address>":0.01}]')
>
> * *Node A joins the two PSBTs and sends it back to Node B (*bitcoin-cli
> joinpsbts '["<channel_open_psbt>", "<node_b_return_to_node_a_psbt>"]')
>
> ** Node B verifies the content and signs the joined PSBT before sending it
> back to Node A *(bitcoin-cli walletprocesspsbt <joined_psbt>)
>
> ** Node A: Verifies the content and signs the joined PSBT *(bitcoin-cli
> walletprocesspsbt <joined_psbt>)
>
> ** Node A: Completes channel open by publishing the fully signed PSBT*
>
>
> ----------------------
> --- Here is an example of the complete flow for a ring of channels between
> multiple nodes:
> ----------------------
>
> ** Node A starts an Interactive open channel to Node B using psbt* (lncli
> openchannel --psbt --no_publish <node_b_pubkey> 2000000 1000000)
> ** Node A funds the channel address* (bitcoin-cli walletcreatefundedpsbt
> [] '[{"<channel_address>":0.02}]')
>
> ** Node B starts an Interactive open channel to Node C using psbt* (lncli
> openchannel --psbt --no_publish <node_b_pubkey> 2000000 1000000)
> ** Node B funds the channel address* (bitcoin-cli walletcreatefundedpsbt
> [] '[{"<channel_address>":0.02}]')
>
> ** Node C starts an Interactive open channel to Node A using psbt* (lncli
> openchannel --psbt <node_b_pubkey> 2000000 1000000)
> ** Node C funds the channel address *(bitcoin-cli walletcreatefundedpsbt
> [] '[{"<channel_address>":0.02}]')
>
> ** Node B and C sends Node A their PSBTs*
>
> ** Node A joins all the PSBTs* (bitcoin-cli joinpsbts
> '["<A_funded_channel_psbt>", "<B_funded_channel_psbt>",
> "<C_funded_channel_psbt>"]')
>
> Using (bitcoin-cli walletprocesspsbt <joined_psbt>):
>
>
>
> ** Node A verifies and signs the PSBT and sends it to Node B (1/3
> signatures)* Node B verifies and signs the PSBT and sends it to Node C (2/3
> signatures)* Node C verifies and signs the PSBT (3/3 signatures) before
> sending it to Node A and B.*
>
>
> ** Node A completes channel open (no_publish)* Node B completes channel
> open (no_publish)* Node C completes channel open and publishes the
> transaction.*
>
> --
> Ole Henrik Skogstrøm
>
> _______________________________________________
> 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/20210922/7eca3d87/attachment.html>

2023-06-09 13:03:50

- reply

📅 Original date posted:2021-09-21
📝 Original message:
Hi Joost,
Concept ACK, I had toyed with something similar a while ago, but I hadn't
realized
that invoice storage was such a DoS vector for merchants/hubs and wasn't
sure it
would be useful.
Do you have an example of what information you would usually put in your
`encoded_order_details`?
I'd imagine that it would usually be simply a skuID from the merchant's
product
database, but it could also be fully self-contained data to identify a
"transaction"
(probably encrypted with a key belonging to the payee).
We'd want to ensure that this field is reasonably small, to ensure it can
fit in
onions without forcing the sender to use shorter routes or disable other
features.
Cheers,
Bastien
Le mar. 21 sept. 2021 à 15:17, Joost Jager <joost.jager at gmail.com> a écrit :
> On Tue, Sep 21, 2021 at 3:06 PM fiatjaf <fiatjaf at gmail.com> wrote:
>
>> I would say, however, that these are two separate proposals:
>>
>> 1. implementations should expose a "stateless invoice" API for
>> receiving using the payment_secret;
>> 2. when sending, implementations should attach a TLV record with
>> encoded order details.
>>
>> Of these, 1 is very simple to do and do not require anyone to cooperate,
>> it just works.
>>
>> 2 requires full network compatibility, so it's harder. But 2 is also very
>> much needed otherwise the payee has to keep track of all the invoice ids
>> related to the orders they refer to, right?
>>
>
> Not completely sure what you mean by full network compatibility, but a
> network-wide upgrade including all routing nodes isn't needed. I think to
> do it cleanly we need a new tag for bolt11 and node implementations that
> carry over the contents of this field to a tlv record. So senders do need
> to support this.
>
>
>> But I think just having 1 already improves the situation a lot, and there
>> are application-specific workarounds that can be applied for 2 (having a
>> fixed, hardcoded set of possible orders, encoding the order very minimally
>> in the payment secret or route hint, storing order details on redis for
>> only 3 minutes and using lnurlpay to reduce the delay between invoice
>> issuance and user confirmation to zero, and so on).
>>
>
> A stateless invoice API would be a great thing to have. I've prototyped
> this in lnd and if you implement it so that a regular invoice is inserted
> 'just in time', it isn't too involved as you say.
>
> Joost
> _______________________________________________
> 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/20210921/f31a309c/attachment.html>

2023-06-09 13:03:04

- reply

📅 Original date posted:2021-07-08
📝 Original message:
Good morning list,
I've been mulling over some limitations of our feature bits mechanism and
I'm interested in your ideas and comments.
Our feature bits mechanism works well for symmetric features (where both
peers play the same role) but not so well for asymmetric features (where
there is a client and a service provider). Here is a hypothetical example to
illustrate that. Any similarity to existing wallet features is entirely
coincidental.
Alice has a mobile lightning wallet that can be woken up via push
notifications.
Bob runs a lightning node that can send push notifications to mobile
wallets to
wake them up on important events (e.g. incoming htlcs).
We can't use a single feature bit to model that, because what Alice supports
is actually "I can be woken up via push notifications", but she can't send
push
notifications to other nodes (and similarly, Bob only supports waking up
other
nodes, not receiving push notifications).
So we must use two feature bits: `wake_me_up_plz` and `i_say_wake_up`.
Alice activates `wake_me_up_plz`, Bob activates `i_say_wake_up` and it's
now clear what part of the protocol each node can handle.
But how does Alice require her peers to support `i_say_wake_up`?
She can't turn on the feature with the mandatory bit because then her peers
would be confused and think she can wake up other devices.
I see two potential solutions:
1. Re-purpose the meaning of `optional` and `mandatory` bits for
asymmetric feature: the odd bit would mean "I support this feature"
and the even bit would mean "I require my peer to support this feature"
2. Add a requirement to send a warning and disconnect when a client
connects to a provider that hasn't activated the provider-side feature
Thoughts?
Cheers,
Bastien
Note: I opened an issue for that for those who prefer github:
https://github.com/lightningnetwork/lightning-rfc/issues/885
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210708/d523308b/attachment.html>

2023-06-09 13:02:53

- reply

📅 Original date posted:2021-07-02
📝 Original message:
>
> Will it actually add any more fragmentation that already exists? Due to all
> the extensibility we've added in the protocol, it's already possible for
> any
> implementation to start to work on their own sub-protocols. This just gives
> them a new venue to at least _describe_ what they're using.
>
It's only my 2 cents, but I'm afraid it will indeed add more fragmentation,
because
the fact that there exists a bLIP for feature XXX will likely act as a
green light to
deploy it faster instead of spending more time talking about it with the
community
and thinking about potential issues, forward-compatibility, etc.
But I agree with you that it also gives more freedom to experiment in the
real world,
which helps find issues and correct them, paving the way for better
features for
end users.
It's also likely the case that already implementations, or typically forks
> of implementations are already using "undocumented" TLVs or feature bits in
> the wild today.
>
But today we're usually very careful when we do that, and use numbers in
high ranges
for these use-cases. In our case for example we use message type 35007 for
our
swap-in and we expect that to change once standardized, so we did extra
work to
ensure we wouldn't paint ourselves into a corner when switching to a
standard version.
I think that if we have a centralized bLIP repo, we can take this
opportunity to safely
assign "final" values for types and feature bits that are used by each
bLIP, and stronger
guarantees that they will not conflict with another bLIP or BOLT. Of course
that doesn't
stop anyone from deploying a conflict, but their use of the same bits won't
be documented
so it shouldn't be widely deployed, and browsing the BOLTs and bLIPs should
let anyone
see what the "correct" meaning of those bits should be.
Cheers,
Bastien
Le jeu. 1 juil. 2021 à 22:43, Olaoluwa Osuntokun <laolu32 at gmail.com> a
écrit :
> > But they don't address the first point at all, they instead work around
> > it. To be fair, I don't think we can completely address that first
> point:
> > properly reviewing spec proposals takes a lot of effort and accepting
> > complex changes to the BOLTs shouldn't be done lightly.
>
> I think this is a fair characterization that I agree with. I also agree
> that
> there isn't really a way to fundamentally address it. The issue of scarce
> review resources is something just about any large open source project
> needs
> to deal with: everyone wants to make a PR, but no one wants to review the
> PRs of others, unless it scratches some tangential itch they may have. IMO
> it's also the case that the problem/solution space of LN is so large, that
> it's hard to expect every developer to review each new proposal that comes
> in, as they themselves have their own set of priorities (product,
> businesses, protocol, personal, etc).
>
> In the end though, I think when there've been critical items that affect
> all
> implementations and/or the existence of the protocol itself, developers
> typically band together to commit resources to help a proposal move
> forward.
> One upcoming example of this will be the "base" taproot channel type (the
> design space is pretty large in that it even permits a new type of
> symmetric
> state revocation-based channel).
>
> > it will add fragmentation to the network, it will add maintenance costs
> > and backwards-compatibility issues
>
> Will it actually add any more fragmentation that already exists? Due to all
> the extensibility we've added in the protocol, it's already possible for
> any
> implementation to start to work on their own sub-protocols. This just gives
> them a new venue to at least _describe_ what they're using. As usual, it's
> up to other implementations if they want to adopt it or not, or advise
> against its use.
>
> > many bLIPs will be sub-optimal solutions to the problem they try to
> solve
> > and some bLIPs will be simply insecure and may put users' funds at risk
> > (L2 protocols are hard and have subtle issues that can be easily missed)
>
> This may be the case, but I guess at times it's hard to know if something
> is
> objectively sub-optimal without further exploration of the design space,
> which usually means either more people involved, or more time examining the
> problem. Ultimately, different wallets/implementations may also be willing
> to make different usability/security trade-offs. One example here is zero
> conf channels: they assume a greater degree of trust with the party you're
> _accepting_ the channel from, as if you receive funds over the channel,
> they
> can be double spent away. However it's undeniable that they improve the UX
> by reducing the amount of time a user needs to wait around before they can
> actually jump in and use LN.
>
> In the end though, there's no grand global committee that prevents people
> from deploying software they think is interesting or useful. In the long
> run, I guess one simply needs to hope that bad ideas die out, or speak out
> against them to the public. As LN sits a layer above the base protocol,
> widespread global consensus isn't really required to make certain classes
> of
> changes, and you can't stop people from experimenting on their own.
>
> > We can't have collisions on any of these three things.
>
> Yeah, collisions are def possible. IMO, this is where the interplay with
> BOLTs comes in: BOLTs are the global feature bit/tlv/message namespace. A
> bLIP might come with the amendment of BOLT 9 to define feature bits they
> used. Of course, this should be done on a best effort basis, as even if you
> assign a bit for your idea, someone can just go ahead and deploy something
> else w/ that same bit, and they may never really intersect depending on the
> nature or how widespread the new feature is.
>
> It's also likely the case that already implementations, or typically forks
> of implementations are already using "undocumented" TLVs or feature bits in
> the wild today. I don't know exactly which TLV type things like
> applications
> that tunnel messages over the network use, but afaik so far there haven't
> been any disastrous collisions in the wild.
>
> -- Laolu
>
> On Thu, Jul 1, 2021 at 2:19 AM Bastien TEINTURIER <bastien at acinq.fr>
> wrote:
>
>> Thanks for starting that discussion.
>>
>> In my opinion, what we're really trying to address here are the two
>> following
>> points (at least from the point of view of someone who works on the spec
>> and
>> an implementation):
>>
>> - Implementers get frustrated when they've worked on something that they
>> think
>> is useful and they can't get it into the BOLTs (the spec PR isn't
>> reviewed,
>> it progresses too slowly or there isn't enough agreement to merge it)
>> - Implementers expect other implementers to specify the optional features
>> they
>> ship: we don't want to have to reverse-engineer a sub-protocol when users
>> want our implementation to provide support for feature XXX
>>
>> Note that these are two very different concerns.
>>
>> bLIPs/SPARKS/BIPs clearly address the second point, which is good.
>> But they don't address the first point at all, they instead work around
>> it.
>> To be fair, I don't think we can completely address that first point:
>> properly
>> reviewing spec proposals takes a lot of effort and accepting complex
>> changes
>> to the BOLTs shouldn't be done lightly.
>>
>> I am mostly in favor of this solution, but I want to highlight that it
>> isn't
>> only rainbows and unicorns: it will add fragmentation to the network, it
>> will
>> add maintenance costs and backwards-compatibility issues, many bLIPs will
>> be
>> sub-optimal solutions to the problem they try to solve and some bLIPs
>> will be
>> simply insecure and may put users' funds at risk (L2 protocols are hard
>> and have
>> subtle issues that can be easily missed). On the other hand, it allows
>> for real
>> world experimentation and iteration, and it's easier to amend a bLIP than
>> the
>> BOLTs.
>>
>> On the nuts-and-bolts (see the pun?) side, bLIPs cannot embrace a fully
>> bazaar
>> style of evolution. Most of them will need:
>>
>> - to assign feature bit(s)
>> - to insert new tlv fields in existing messages
>> - to create new messages
>>
>> We can't have collisions on any of these three things. bLIP XXX cannot
>> use the
>> same tlv types as bLIP YYY otherwise we're creating network
>> incompatibilities.
>> So they really need to be centralized, and we need a process to assign
>> these
>> and ensure they don't collide. It's not a hard problem, but we need to be
>> clear
>> about the process around those.
>>
>> Regarding the details of where they live, I don't have a strong opinion,
>> but I
>> think they must be easy to find and browse, and I think it's easier for
>> readers
>> if they're inside the spec repository. We already have PRs that use a
>> dedicated
>> "proposals" folder (e.g. [1], [2]).
>>
>> Cheers,
>> Bastien
>>
>> [1] https://github.com/lightningnetwork/lightning-rfc/pull/829
>> [2] https://github.com/lightningnetwork/lightning-rfc/pull/854
>>
>> Le jeu. 1 juil. 2021 à 02:31, Ariel Luaces <arielluaces at gmail.com> a
>> écrit :
>>
>>> BIPs are already the Bazaar style of evolution that simultaneously
>>> allows flexibility and coordination/interoperability (since anyone can
>>> create a BIP and they create an environment of discussion).
>>>
>>> BOLTs are essentially one big BIP in the sense that they started as a
>>> place for discussion but are now more rigid. BOLTs must be followed
>>> strictly to ensure a node is interoperable with the network. And BOLTs
>>> should be rigid, as rigid as any widely used BIP like 32 for example.
>>> Even though BOLTs were flexible when being drafted their purpose has
>>> changed from descriptive to prescriptive.
>>> Any alternatives, or optional features should be extracted out of
>>> BOLTs, written as BIPs. The BIP should then reference the BOLT and the
>>> required flags set, messages sent, or alterations made to signal that
>>> the BIP's feature is enabled.
>>>
>>> A BOLT may at some point organically change to reference a BIP. For
>>> example if a BIP was drafted as an optional feature but then becomes
>>> more widespread and then turns out to be crucial for the proper
>>> operation of the network then a BOLT can be changed to just reference
>>> the BIP as mandatory. There isn't anything wrong with this.
>>>
>>> All of the above would work exactly the same if there was a bLIP
>>> repository 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
>>> because many still perceive the BOLTs available for editing, so
>>> changes continue to be made. If instead BOLTs were perceived as more
>>> "consensus critical", not subject to change, and more people were
>>> strongly encouraged to write specs for new lightning features
>>> elsewhere (like the BIP repo) then you would see this issue of growing
>>> BOLTs resolved.
>>>
>>> Cheers
>>> Ariel Lorenzo-Luaces
>>>
>>> On Wed, Jun 30, 2021 at 1:16 PM Olaoluwa Osuntokun <laolu32 at gmail.com>
>>> wrote:
>>> >
>>> > > 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 trying to solve here is promoting more
>>> loosely
>>> > coupled evolution of the network. I think the BOLTs do a good job
>>> currently of
>>> > specifying what _base_ functionality is required for a routing node in
>>> a
>>> > prescriptive manner (you must forward an HTLC like this, etc). However
>>> there's
>>> > a rather large gap in describing functionality that has emerged over
>>> time due
>>> > to progressive evolution, and aren't absolutely necessary, but enhance
>>> > node/wallet operation.
>>> >
>>> > Examples of include things like: path finding heuristics (BOLTs just
>>> say you
>>> > should get from Alice to Bob, but provides no recommendations w.r.t
>>> _how_ to do
>>> > so), fee bumping heuristics, breach retribution handling, channel
>>> management,
>>> > rebalancing, custom records usage (like the podcast index meta-data,
>>> messaging,
>>> > etc), JIT channel opening, hosted channels, randomized channel IDs, fee
>>> > optimization, initial channel boostrapping, etc.
>>> >
>>> > All these examples are effectively optional as they aren't required
>>> for base
>>> > node operation, but they've organically evolved over time as node
>>> > implementations and wallet seek to solve UX and operational problems
>>> for
>>> > their users. bLIPs can be a _descriptive_ (this is how things can be
>>> done)
>>> > home for these types of standards, while BOLTs can be reserved for
>>> > _prescriptive_ measures (an HTLC looks like this, etc).
>>> >
>>> > The protocol as implemented today has a number of extensions (TLVs,
>>> message
>>> > types, feature bits, etc) that allow implementations to spin out their
>>> own
>>> > sub-protocols, many of which won't be considered absolutely necessary
>>> for node
>>> > operation. IMO we should embrace more of a "bazaar" style of
>>> evolution, and
>>> > acknowledge that loosely coupled evolution allows participants to more
>>> broadly
>>> > explore the design space, without the constraints of "it isn't a thing
>>> until N
>>> > of us start to do it".
>>> >
>>> > Historically, BOLTs have also had a rather monolithic structure. We've
>>> used
>>> > the same 11 or so documents for the past few years with the size of the
>>> > documents swelling over time with new exceptions, features,
>>> requirements,
>>> > etc. If you were hired to work on a new codebase and saw that
>>> everything is
>>> > defined in 11 "functions" that have been growing linearly over time,
>>> you'd
>>> > probably declare the codebase as being unmaintainable. By having
>>> distinct
>>> > documents for proposals/standards, bLIPs (author documents really),
>>> each new
>>> > standard/proposal is able to be more effectively explained, motivated,
>>> versionsed,
>>> > etc.
>>> >
>>> > -- Laolu
>>> >
>>> >
>>> > On Wed, Jun 30, 2021 at 7:35 AM René Pickhardt via Lightning-dev <
>>> lightning-dev at lists.linuxfoundation.org> wrote:
>>> >>
>>> >> Hey everyone,
>>> >>
>>> >> just for reference when I was new here (and did not understand the
>>> processes well enough) I proposed a similar idea (called LIP) in 2018 c.f.:
>>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-July/001367.html
>>> >>
>>> >> I wonder what exactly has changed in the reasoning by roasbeef which
>>> I will repeat here:
>>> >>
>>> >> > 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?
>>> >>
>>> >>
>>> >> As far as I can tell there was always some form of (invisible?)
>>> barrier to participate in the BOLTs but there are also new BOLTs being
>>> offered:
>>> >> * BOLT 12: https://github.com/lightningnetwork/lightning-rfc/pull/798
>>> >> * BOLT 14: https://github.com/lightningnetwork/lightning-rfc/pull/780
>>> >> and topics to be included like:
>>> >> * dual funding
>>> >> * splicing
>>> >> * the examples given by Ryan
>>> >>
>>> >> I don't see how a new repo would reduce that barrier - Actually I
>>> think it would even create more confusion as I for example would not know
>>> where something belongs. 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? One thing that I
>>> can say from answering lightning-network questions on stackexchange is that
>>> it would certainly help if the BOLTs where referenced on lightning.network
>>> web page and in the whitepaper as the place to be if one wants to learn
>>> about the Lightning Network
>>> >>
>>> >> with kind regards Rene
>>> >>
>>> >> On Wed, Jun 30, 2021 at 4:10 PM Ryan Gentry via Lightning-dev <
>>> lightning-dev at lists.linuxfoundation.org> wrote:
>>> >>>
>>> >>> Hi all,
>>> >>>
>>> >>>
>>> >>> The recent thread around zero-conf channels [1] provides an
>>> opportunity to discuss how the BOLT process handles features and best
>>> practices that arise in the wild vs. originating within the process itself.
>>> Zero-conf channels are one of many LN innovations on the app layer that
>>> have struggled to make their way into the spec. John Carvalho and Bitrefill
>>> launched Turbo channels in April 2019 [2], Breez posted their solution to
>>> the mailing list for feedback in August 2020 [3], and we know at least
>>> ACINQ and Muun (amongst others) have their own implementations. In an ideal
>>> world there would be a descriptive design document that the app layer
>>> implementers had collaborated on over the years that the spec group could
>>> then pick up and merge into the BOLTs now that the feature is deemed
>>> spec-worthy.
>>> >>>
>>> >>>
>>> >>> Over the last couple of months, we have discussed the idea of adding
>>> a BIP-style process (bLIPs? SPARKs? [4]) on top of the BOLTs with various
>>> members of the community, and have received positive feedback from both app
>>> layer and protocol devs. This would not affect the existing BOLT process at
>>> all, but simply add a place for app layer best practices to be succinctly
>>> described and organized, especially those that require coordination. These
>>> features are being built outside of the BOLT process today anyways, so
>>> ideally a bLIP process would bring them into the fold instead of leaving
>>> them buried in old ML posts or not documented at all.
>>> >>>
>>> >>>
>>> >>> Some potential bLIP ideas that people have mentioned include: each
>>> lnurl variant, on-the-fly channel opens, AMP, dynamic commitments, podcast
>>> payment metadata, p2p messaging formats, new pathfinding heuristics, remote
>>> node connection standards, etc.
>>> >>>
>>> >>>
>>> >>> If the community is interested in moving forward, we've started a
>>> branch [5] describing such a process. It's based on BIP-0002, so not trying
>>> to reinvent any wheels. It would be great to have developers from various
>>> implementations and from the broader app layer ecosystem volunteer to be
>>> listed as editors (basically the same role as in the BIPs).
>>> >>>
>>> >>>
>>> >>> Looking forward to hearing your thoughts!
>>> >>>
>>> >>>
>>> >>> Best,
>>> >>> Ryan
>>> >>>
>>> >>>
>>> >>> [1]
>>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-June/003074.html
>>> >>>
>>> >>> [2]
>>> https://www.coindesk.com/bitrefills-thor-turbo-lets-you-get-started-with-bitcoins-lightning-faster
>>> >>>
>>> >>> [3]
>>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-August/002780.html
>>> >>>
>>> >>> [4] bLIP = Bitcoin Lightning Improvement Proposal and SPARK =
>>> Standardization of Protocols at the Request of the Kommunity (h/t fiatjaf)
>>> >>>
>>> >>> [5]
>>> https://github.com/ryanthegentry/lightning-rfc/blob/blip-0001/blips/blip-0001.mediawiki
>>> >>>
>>> >>> _______________________________________________
>>> >>> Lightning-dev mailing list
>>> >>> Lightning-dev at lists.linuxfoundation.org
>>> >>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> https://www.rene-pickhardt.de
>>> >> _______________________________________________
>>> >> 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
>>> _______________________________________________
>>> 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/20210702/8b6fcefe/attachment-0001.html>

2023-06-09 13:02:51

- reply

📅 Original date posted:2021-07-01
📝 Original message:
Thanks for starting that discussion.
In my opinion, what we're really trying to address here are the two
following
points (at least from the point of view of someone who works on the spec and
an implementation):
- Implementers get frustrated when they've worked on something that they
think
is useful and they can't get it into the BOLTs (the spec PR isn't reviewed,
it progresses too slowly or there isn't enough agreement to merge it)
- Implementers expect other implementers to specify the optional features
they
ship: we don't want to have to reverse-engineer a sub-protocol when users
want our implementation to provide support for feature XXX
Note that these are two very different concerns.
bLIPs/SPARKS/BIPs clearly address the second point, which is good.
But they don't address the first point at all, they instead work around it.
To be fair, I don't think we can completely address that first point:
properly
reviewing spec proposals takes a lot of effort and accepting complex changes
to the BOLTs shouldn't be done lightly.
I am mostly in favor of this solution, but I want to highlight that it isn't
only rainbows and unicorns: it will add fragmentation to the network, it
will
add maintenance costs and backwards-compatibility issues, many bLIPs will be
sub-optimal solutions to the problem they try to solve and some bLIPs will
be
simply insecure and may put users' funds at risk (L2 protocols are hard and
have
subtle issues that can be easily missed). On the other hand, it allows for
real
world experimentation and iteration, and it's easier to amend a bLIP than
the
BOLTs.
On the nuts-and-bolts (see the pun?) side, bLIPs cannot embrace a fully
bazaar
style of evolution. Most of them will need:
- to assign feature bit(s)
- to insert new tlv fields in existing messages
- to create new messages
We can't have collisions on any of these three things. bLIP XXX cannot use
the
same tlv types as bLIP YYY otherwise we're creating network
incompatibilities.
So they really need to be centralized, and we need a process to assign these
and ensure they don't collide. It's not a hard problem, but we need to be
clear
about the process around those.
Regarding the details of where they live, I don't have a strong opinion,
but I
think they must be easy to find and browse, and I think it's easier for
readers
if they're inside the spec repository. We already have PRs that use a
dedicated
"proposals" folder (e.g. [1], [2]).
Cheers,
Bastien
[1] https://github.com/lightningnetwork/lightning-rfc/pull/829
[2] https://github.com/lightningnetwork/lightning-rfc/pull/854
Le jeu. 1 juil. 2021 à 02:31, Ariel Luaces <arielluaces at gmail.com> a écrit :
> BIPs are already the Bazaar style of evolution that simultaneously
> allows flexibility and coordination/interoperability (since anyone can
> create a BIP and they create an environment of discussion).
>
> BOLTs are essentially one big BIP in the sense that they started as a
> place for discussion but are now more rigid. BOLTs must be followed
> strictly to ensure a node is interoperable with the network. And BOLTs
> should be rigid, as rigid as any widely used BIP like 32 for example.
> Even though BOLTs were flexible when being drafted their purpose has
> changed from descriptive to prescriptive.
> Any alternatives, or optional features should be extracted out of
> BOLTs, written as BIPs. The BIP should then reference the BOLT and the
> required flags set, messages sent, or alterations made to signal that
> the BIP's feature is enabled.
>
> A BOLT may at some point organically change to reference a BIP. For
> example if a BIP was drafted as an optional feature but then becomes
> more widespread and then turns out to be crucial for the proper
> operation of the network then a BOLT can be changed to just reference
> the BIP as mandatory. There isn't anything wrong with this.
>
> All of the above would work exactly the same if there was a bLIP
> repository 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
> because many still perceive the BOLTs available for editing, so
> changes continue to be made. If instead BOLTs were perceived as more
> "consensus critical", not subject to change, and more people were
> strongly encouraged to write specs for new lightning features
> elsewhere (like the BIP repo) then you would see this issue of growing
> BOLTs resolved.
>
> Cheers
> Ariel Lorenzo-Luaces
>
> On Wed, Jun 30, 2021 at 1:16 PM Olaoluwa Osuntokun <laolu32 at gmail.com>
> wrote:
> >
> > > 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 trying to solve here is promoting more
> loosely
> > coupled evolution of the network. I think the BOLTs do a good job
> currently of
> > specifying what _base_ functionality is required for a routing node in a
> > prescriptive manner (you must forward an HTLC like this, etc). However
> there's
> > a rather large gap in describing functionality that has emerged over
> time due
> > to progressive evolution, and aren't absolutely necessary, but enhance
> > node/wallet operation.
> >
> > Examples of include things like: path finding heuristics (BOLTs just
> say you
> > should get from Alice to Bob, but provides no recommendations w.r.t
> _how_ to do
> > so), fee bumping heuristics, breach retribution handling, channel
> management,
> > rebalancing, custom records usage (like the podcast index meta-data,
> messaging,
> > etc), JIT channel opening, hosted channels, randomized channel IDs, fee
> > optimization, initial channel boostrapping, etc.
> >
> > All these examples are effectively optional as they aren't required for
> base
> > node operation, but they've organically evolved over time as node
> > implementations and wallet seek to solve UX and operational problems for
> > their users. bLIPs can be a _descriptive_ (this is how things can be
> done)
> > home for these types of standards, while BOLTs can be reserved for
> > _prescriptive_ measures (an HTLC looks like this, etc).
> >
> > The protocol as implemented today has a number of extensions (TLVs,
> message
> > types, feature bits, etc) that allow implementations to spin out their
> own
> > sub-protocols, many of which won't be considered absolutely necessary
> for node
> > operation. IMO we should embrace more of a "bazaar" style of evolution,
> and
> > acknowledge that loosely coupled evolution allows participants to more
> broadly
> > explore the design space, without the constraints of "it isn't a thing
> until N
> > of us start to do it".
> >
> > Historically, BOLTs have also had a rather monolithic structure. We've
> used
> > the same 11 or so documents for the past few years with the size of the
> > documents swelling over time with new exceptions, features, requirements,
> > etc. If you were hired to work on a new codebase and saw that everything
> is
> > defined in 11 "functions" that have been growing linearly over time,
> you'd
> > probably declare the codebase as being unmaintainable. By having distinct
> > documents for proposals/standards, bLIPs (author documents really), each
> new
> > standard/proposal is able to be more effectively explained, motivated,
> versionsed,
> > etc.
> >
> > -- Laolu
> >
> >
> > On Wed, Jun 30, 2021 at 7:35 AM René Pickhardt via Lightning-dev <
> lightning-dev at lists.linuxfoundation.org> wrote:
> >>
> >> Hey everyone,
> >>
> >> just for reference when I was new here (and did not understand the
> processes well enough) I proposed a similar idea (called LIP) in 2018 c.f.:
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-July/001367.html
> >>
> >> I wonder what exactly has changed in the reasoning by roasbeef which I
> will repeat here:
> >>
> >> > 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?
> >>
> >>
> >> As far as I can tell there was always some form of (invisible?) barrier
> to participate in the BOLTs but there are also new BOLTs being offered:
> >> * BOLT 12: https://github.com/lightningnetwork/lightning-rfc/pull/798
> >> * BOLT 14: https://github.com/lightningnetwork/lightning-rfc/pull/780
> >> and topics to be included like:
> >> * dual funding
> >> * splicing
> >> * the examples given by Ryan
> >>
> >> I don't see how a new repo would reduce that barrier - Actually I think
> it would even create more confusion as I for example would not know where
> something belongs. 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? One thing that I
> can say from answering lightning-network questions on stackexchange is that
> it would certainly help if the BOLTs where referenced on lightning.network
> web page and in the whitepaper as the place to be if one wants to learn
> about the Lightning Network
> >>
> >> with kind regards Rene
> >>
> >> On Wed, Jun 30, 2021 at 4:10 PM Ryan Gentry via Lightning-dev <
> lightning-dev at lists.linuxfoundation.org> wrote:
> >>>
> >>> Hi all,
> >>>
> >>>
> >>> The recent thread around zero-conf channels [1] provides an
> opportunity to discuss how the BOLT process handles features and best
> practices that arise in the wild vs. originating within the process itself.
> Zero-conf channels are one of many LN innovations on the app layer that
> have struggled to make their way into the spec. John Carvalho and Bitrefill
> launched Turbo channels in April 2019 [2], Breez posted their solution to
> the mailing list for feedback in August 2020 [3], and we know at least
> ACINQ and Muun (amongst others) have their own implementations. In an ideal
> world there would be a descriptive design document that the app layer
> implementers had collaborated on over the years that the spec group could
> then pick up and merge into the BOLTs now that the feature is deemed
> spec-worthy.
> >>>
> >>>
> >>> Over the last couple of months, we have discussed the idea of adding a
> BIP-style process (bLIPs? SPARKs? [4]) on top of the BOLTs with various
> members of the community, and have received positive feedback from both app
> layer and protocol devs. This would not affect the existing BOLT process at
> all, but simply add a place for app layer best practices to be succinctly
> described and organized, especially those that require coordination. These
> features are being built outside of the BOLT process today anyways, so
> ideally a bLIP process would bring them into the fold instead of leaving
> them buried in old ML posts or not documented at all.
> >>>
> >>>
> >>> Some potential bLIP ideas that people have mentioned include: each
> lnurl variant, on-the-fly channel opens, AMP, dynamic commitments, podcast
> payment metadata, p2p messaging formats, new pathfinding heuristics, remote
> node connection standards, etc.
> >>>
> >>>
> >>> If the community is interested in moving forward, we've started a
> branch [5] describing such a process. It's based on BIP-0002, so not trying
> to reinvent any wheels. It would be great to have developers from various
> implementations and from the broader app layer ecosystem volunteer to be
> listed as editors (basically the same role as in the BIPs).
> >>>
> >>>
> >>> Looking forward to hearing your thoughts!
> >>>
> >>>
> >>> Best,
> >>> Ryan
> >>>
> >>>
> >>> [1]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-June/003074.html
> >>>
> >>> [2]
> https://www.coindesk.com/bitrefills-thor-turbo-lets-you-get-started-with-bitcoins-lightning-faster
> >>>
> >>> [3]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-August/002780.html
> >>>
> >>> [4] bLIP = Bitcoin Lightning Improvement Proposal and SPARK =
> Standardization of Protocols at the Request of the Kommunity (h/t fiatjaf)
> >>>
> >>> [5]
> https://github.com/ryanthegentry/lightning-rfc/blob/blip-0001/blips/blip-0001.mediawiki
> >>>
> >>> _______________________________________________
> >>> Lightning-dev mailing list
> >>> Lightning-dev at lists.linuxfoundation.org
> >>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> >>
> >>
> >>
> >> --
> >> https://www.rene-pickhardt.de
> >> _______________________________________________
> >> 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
> _______________________________________________
> 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/20210701/db735010/attachment-0001.html>

2023-06-09 13:02:46

- reply

📅 Original date posted:2021-06-30
📝 Original message:
>
> - MUST NOT send `announcement_signatures` messages until `funding_locked`
> has been sent and received AND the funding transaction has at least
> six confirmations.
>
> So still compliant there?
>
Great, I hadn't spotted that one, so we're good on the
`announcement_signatures` side.
I'm wondering if `option_zeroconf` implies that we should set `min_depth =
0` in
`accept_channel`, since that's the number of confirmations before we can
send
`funding_locked`.
We need a signal that this channel uses zero-conf, and the two obvious
choices are:
- set `min_depth = 0`
- use a `channel_type` that sets `option_zeroconf`
I think the second option is better, this way we can keep a "normal"
`min_depth` set
and when we send `funding_locked`, we know that the channel is now
perfectly safe
to use (out of the zero-conf zone).
Cheers,
Bastien
Le mer. 30 juin 2021 à 02:09, Rusty Russell <rusty at rustcorp.com.au> a
écrit :
> Bastien TEINTURIER <bastien at acinq.fr> writes:
> > Hi Rusty,
> >
> > On the eclair side, we instead send `funding_locked` as soon as we
> > see the funding tx in the mempool.
> >
> > But I think your proposal would work as well.
>
> This would be backward compatible, I think. Eclair would send
> `funding_locked`, which is perfectly legal, but a normal peer would
> still wait for confirms before also sending `funding_locked`; it's
> just that option_zeroconf_channels would mean it doesn't have to
> wait for that before sending HTLCs?
>
> > We may want to defer sending `announcement_signatures` until
> > after the funding tx has been confirmed? What `min_depth` should
> > we use here? Should we keep a non-zero value in `accept_channel`
> > or should it be zero?
>
> You can't send it before you know the channel_id, so it has to be at
> least 1. Spec says:
>
> - MUST NOT send `announcement_signatures` messages until
> `funding_locked`
> has been sent and received AND the funding transaction has at least
> six confirmations.
>
> So still compliant there?
>
> Cheers,
> Rusty.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210630/f022c575/attachment.html>

2023-06-09 13:02:46

- reply

📅 Original date posted:2021-06-29
📝 Original message:
Hi Rusty,
On the eclair side, we instead send `funding_locked` as soon as we
see the funding tx in the mempool.
But I think your proposal would work as well.
We may want to defer sending `announcement_signatures` until
after the funding tx has been confirmed? What `min_depth` should
we use here? Should we keep a non-zero value in `accept_channel`
or should it be zero?
Cheers,
Bastien
Le mar. 29 juin 2021 à 07:34, Rusty Russell <rusty at rustcorp.com.au> a
écrit :
> Hi all!
>
> John Carvalo recently pointed out that not every implementation
> accepts zero-conf channels, but they are useful. Roasbeef also recently
> noted that they're not spec'd.
>
> How do you all do it? Here's a strawman proposal:
>
> 1. Assign a new feature bit "I accept zeroconf channels".
> 2. If both negotiate this, you can send update_add_htlc (etc) *before*
> funding_locked without the peer getting upset.
> 3. Nodes are advised *not* to forward HTLCs from an unconfirmed channel
> unless they have explicit reason to trust that node (they can still
> send *out* that channel, because that's not their problem!).
>
> It's a pretty simple change, TBH (this zeroconf feature would also
> create a new set of channel_types, altering that PR).
>
> I can draft something this week?
>
> Thanks!
> Rusty.
> _______________________________________________
> 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/20210629/a9f7eb76/attachment.html>

2023-06-09 13:02:23

- reply

📅 Original date posted:2021-04-24
📝 Original message:
You're right, I was thinking about trimmed HTLCs (which can re-appear in
the commit tx
if you lower the feerate via update_fee).
Dust HTLCs will never appear in the commit tx regardless of subsequent
update_fees,
so Eugene's suggestion could make sense!
Le sam. 24 avr. 2021 à 06:02, Matt Corallo <lf-lists at mattcorallo.com> a
écrit :
> The update_fee message does not, as far as I recall, change the dust limit
> for outputs in a channel (though I’ve suggested making such a change).
>
> On Apr 23, 2021, at 12:24, Bastien TEINTURIER <bastien at acinq.fr> wrote:
>
>
> Hi Eugene,
>
> The reason dust HTLCs count for the 483 HTLC limit is because of
> `update_fee`.
> If you don't count them and exceed the 483 HTLC limit, you can't lower the
> fee anymore
> because some HTLCs that were previously dust won't be dust anymore and you
> may end
> up with more than 483 HTLC outputs in your commitment, which opens the
> door to other
> kinds of attacks.
>
> This is the first issue that comes to mind, but there may be other
> drawbacks if we dig into
> this enough with an attacker's mindset.
>
> Bastien
>
> Le ven. 23 avr. 2021 à 17:58, Eugene Siegel <elzeigel at gmail.com> a écrit :
>
>> I propose a simple mitigation to increase the capital requirement of
>> channel-jamming attacks. This would prevent an unsophisticated attacker
>> with low capital from jamming a target channel. It seems to me that this
>> is a *free* mitigation without any downsides (besides code-writing), so I'd
>> like to hear other opinions.
>>
>> In a commitment transaction, we trim dust HTLC outputs. I believe that
>> the reason for the 483 HTLC limit each side has in the spec is to prevent
>> commitment tx's from growing unreasonably large, and to ensure they are
>> still valid tx's that can be included in a block. If we don't include dust
>> HTLCs in this calculation, since they are not on the commitment tx, we
>> still allow 483 (x2) non-dust HTLCs to be included on the commitment tx.
>> There could be a configurable limit on the number of outstanding dust
>> HTLCs, but the point is that it doesn't affect the non-dust throughput of
>> the channel. This raises the capital requirement of channel-jamming so
>> that each HTLC must be non-dust, rather than spamming 1 sat payments.
>>
>> Interested in others' thoughts.
>>
>> Eugene (Crypt-iQ)
>> _______________________________________________
>> 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/20210424/e0afd2d9/attachment.html>

2023-06-09 13:02:23

- reply

📅 Original date posted:2021-04-26
📝 Original message:
I looked into this more closely, and as far as I understand it, the spec
already states that you should not count dust HTLCs:
*if result would be offering more than the remote's max_accepted_htlcs
HTLCs, in the remote commitment transaction: *
- *MUST NOT add an HTLC.*
Note that it clearly says "in the remote commitment transaction", which
means
you don't count HTLCs that are dust or trimmed.
That matches eclair's behavior: we don't count dust HTLCs towards that
limit.
Is lnd including them in that count? What about other implementations?
If that's the case, that can simply be fixed in lnd without any spec change
IMHO.
Note that this also excludes trimmed HTLCs from the count, which means that
nodes that set `max_accepted_htlcs` to 483 may be exposed to the issue I
described earlier (impossible to lower the feerate because the HTLC count
would
become greater than the limit).
Bastien
Le sam. 24 avr. 2021 à 10:01, Bastien TEINTURIER <bastien at acinq.fr> a
écrit :
> You're right, I was thinking about trimmed HTLCs (which can re-appear in
> the commit tx
> if you lower the feerate via update_fee).
>
> Dust HTLCs will never appear in the commit tx regardless of subsequent
> update_fees,
> so Eugene's suggestion could make sense!
>
> Le sam. 24 avr. 2021 à 06:02, Matt Corallo <lf-lists at mattcorallo.com> a
> écrit :
>
>> The update_fee message does not, as far as I recall, change the dust
>> limit for outputs in a channel (though I’ve suggested making such a change).
>>
>> On Apr 23, 2021, at 12:24, Bastien TEINTURIER <bastien at acinq.fr> wrote:
>>
>>
>> Hi Eugene,
>>
>> The reason dust HTLCs count for the 483 HTLC limit is because of
>> `update_fee`.
>> If you don't count them and exceed the 483 HTLC limit, you can't lower
>> the fee anymore
>> because some HTLCs that were previously dust won't be dust anymore and
>> you may end
>> up with more than 483 HTLC outputs in your commitment, which opens the
>> door to other
>> kinds of attacks.
>>
>> This is the first issue that comes to mind, but there may be other
>> drawbacks if we dig into
>> this enough with an attacker's mindset.
>>
>> Bastien
>>
>> Le ven. 23 avr. 2021 à 17:58, Eugene Siegel <elzeigel at gmail.com> a
>> écrit :
>>
>>> I propose a simple mitigation to increase the capital requirement of
>>> channel-jamming attacks. This would prevent an unsophisticated attacker
>>> with low capital from jamming a target channel. It seems to me that this
>>> is a *free* mitigation without any downsides (besides code-writing), so I'd
>>> like to hear other opinions.
>>>
>>> In a commitment transaction, we trim dust HTLC outputs. I believe that
>>> the reason for the 483 HTLC limit each side has in the spec is to prevent
>>> commitment tx's from growing unreasonably large, and to ensure they are
>>> still valid tx's that can be included in a block. If we don't include dust
>>> HTLCs in this calculation, since they are not on the commitment tx, we
>>> still allow 483 (x2) non-dust HTLCs to be included on the commitment tx.
>>> There could be a configurable limit on the number of outstanding dust
>>> HTLCs, but the point is that it doesn't affect the non-dust throughput of
>>> the channel. This raises the capital requirement of channel-jamming so
>>> that each HTLC must be non-dust, rather than spamming 1 sat payments.
>>>
>>> Interested in others' thoughts.
>>>
>>> Eugene (Crypt-iQ)
>>> _______________________________________________
>>> 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/20210426/a59c0007/attachment.html>

2023-06-09 13:02:22

- reply

📅 Original date posted:2021-04-23
📝 Original message:
Hi Eugene,
The reason dust HTLCs count for the 483 HTLC limit is because of
`update_fee`.
If you don't count them and exceed the 483 HTLC limit, you can't lower the
fee anymore
because some HTLCs that were previously dust won't be dust anymore and you
may end
up with more than 483 HTLC outputs in your commitment, which opens the door
to other
kinds of attacks.
This is the first issue that comes to mind, but there may be other
drawbacks if we dig into
this enough with an attacker's mindset.
Bastien
Le ven. 23 avr. 2021 à 17:58, Eugene Siegel <elzeigel at gmail.com> a écrit :
> I propose a simple mitigation to increase the capital requirement of
> channel-jamming attacks. This would prevent an unsophisticated attacker
> with low capital from jamming a target channel. It seems to me that this
> is a *free* mitigation without any downsides (besides code-writing), so I'd
> like to hear other opinions.
>
> In a commitment transaction, we trim dust HTLC outputs. I believe that
> the reason for the 483 HTLC limit each side has in the spec is to prevent
> commitment tx's from growing unreasonably large, and to ensure they are
> still valid tx's that can be included in a block. If we don't include dust
> HTLCs in this calculation, since they are not on the commitment tx, we
> still allow 483 (x2) non-dust HTLCs to be included on the commitment tx.
> There could be a configurable limit on the number of outstanding dust
> HTLCs, but the point is that it doesn't affect the non-dust throughput of
> the channel. This raises the capital requirement of channel-jamming so
> that each HTLC must be non-dust, rather than spamming 1 sat payments.
>
> Interested in others' thoughts.
>
> Eugene (Crypt-iQ)
> _______________________________________________
> 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/20210423/9068d4e9/attachment-0001.html>

2023-06-09 13:02:21

- reply

📅 Original date posted:2021-04-23
📝 Original message:
Great idea, I'll join as well.
Thanks for setting this in motion.
Le ven. 23 avr. 2021 à 17:39, Antoine Riard <antoine.riard at gmail.com> a
écrit :
> Hi Jeremy,
>
> Yes dates are floating for now. After Bitcoin 2021, sounds a good idea.
>
> Awesome, I'll be really interested to review again an improved version of
> sponsorship. And I'll try to sketch out the sighash_no-input fee-bumping
> idea which was floating around last year during pinnings discussions. Yet
> another set of trade-offs :)
>
> Le ven. 23 avr. 2021 à 11:25, Jeremy <jlrubin at mit.edu> a écrit :
>
>> I'd be excited to join. Recommend bumping the date to mid June, if
>> that's ok, as many Americans will be at Bitcoin 2021.
>>
>> I was thinking about reviving the sponsors proposal with a 100 block lock
>> on spending a sponsoring tx which would hopefully make less controversial,
>> this would be a great place to discuss those tradeoffs.
>>
>> On Fri, Apr 23, 2021, 8:17 AM Antoine Riard <antoine.riard at gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> During the lastest years, tx-relay and mempool acceptances rules of the
>>> base layer have been sources of major security and operational concerns for
>>> Lightning and other Bitcoin second-layers [0]. I think those areas require
>>> significant improvements to ease design and deployment of higher Bitcoin
>>> layers and I believe this opinion is shared among the L2 dev community. In
>>> order to make advancements, it has been discussed a few times in the last
>>> months to organize in-person workshops to discuss those issues with the
>>> presence of both L1/L2 devs to make exchange fruitful.
>>>
>>> Unfortunately, I don't think we'll be able to organize such in-person
>>> workshops this year (because you know travel is hard those days...) As a
>>> substitution, I'm proposing a series of one or more irc meetings. That
>>> said, this substitution has the happy benefit to gather far more folks
>>> interested by those issues that you can fit in a room.
>>>
>>> # Scope
>>>
>>> I would like to propose the following 4 items as topics of discussion.
>>>
>>> 1) Package relay design or another generic L2 fee-bumping primitive like
>>> sponsorship [0]. IMHO, this primitive should at least solve mempools spikes
>>> making obsolete propagation of transactions with pre-signed feerate, solve
>>> pinning attacks compromising Lightning/multi-party contract protocol
>>> safety, offer an usable and stable API to L2 software stack, stay
>>> compatible with miner and full-node operators incentives and obviously
>>> minimize CPU/memory DoS vectors.
>>>
>>> 2) Deprecation of opt-in RBF toward full-rbf. Opt-in RBF makes it
>>> trivial for an attacker to partition network mempools in divergent subsets
>>> and from then launch advanced security or privacy attacks against a
>>> Lightning node. Note, it might also be a concern for bandwidth bleeding
>>> attacks against L1 nodes.
>>>
>>> 3) Guidelines about coordinated cross-layers security disclosures.
>>> Mitigating a security issue around tx-relay or the mempool in Core might
>>> have harmful implications for downstream projects. Ideally, L2 projects
>>> maintainers should be ready to upgrade their protocols in emergency in
>>> coordination with base layers developers.
>>>
>>> 4) Guidelines about L2 protocols onchain security design. Currently
>>> deployed like Lightning are making a bunch of assumptions on tx-relay and
>>> mempool acceptances rules. Those rules are non-normative, non-reliable and
>>> lack documentation. Further, they're devoid of tooling to enforce them at
>>> runtime [2]. IMHO, it could be preferable to identify a subset of them on
>>> which second-layers protocols can do assumptions without encroaching too
>>> much on nodes's policy realm or making the base layer development in those
>>> areas too cumbersome.
>>>
>>> I'm aware that some folks are interested in other topics such as
>>> extension of Core's mempools package limits or better pricing of RBF
>>> replacement. So l propose a 2-week concertation period to submit other
>>> topics related to tx-relay or mempools improvements towards L2s before to
>>> propose a finalized scope and agenda.
>>>
>>> # Goals
>>>
>>> 1) Reaching technical consensus.
>>> 2) Reaching technical consensus, before seeking community consensus as
>>> it likely has ecosystem-wide implications.
>>> 3) Establishing a security incident response policy which can be applied
>>> by dev teams in the future.
>>> 4) Establishing a philosophy design and associated documentations (BIPs,
>>> best practices, ...)
>>>
>>> # Timeline
>>>
>>> 2021-04-23: Start of concertation period
>>> 2021-05-07: End of concertation period
>>> 2021-05-10: Proposition of workshop agenda and schedule
>>> late 2021-05/2021-06: IRC meetings
>>>
>>> As the problem space is savagely wide, I've started a collection of
>>> documents to assist this workshop : https://github.com/ariard/L2-zoology
>>> Still wip, but I'll have them in a good shape at agenda publication,
>>> with reading suggestions and open questions to structure discussions.
>>> Also working on transaction pinning and mempool partitions attacks
>>> simulations.
>>>
>>> If L2s security/p2p/mempool is your jam, feel free to get involved :)
>>>
>>> Cheers,
>>> Antoine
>>>
>>> [0] For e.g see optech section on transaction pinning attacks :
>>> https://bitcoinops.org/en/topics/transaction-pinning/
>>> [1]
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html
>>> [2] Lack of reference tooling make it easier to have bug slip in like
>>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-October/002858.html
>>> _______________________________________________
>>> 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/20210423/09108adc/attachment.html>

2023-06-09 13:01:48

- reply

📅 Original date posted:2020-12-28
📝 Original message:
Good morning list,
Before we close this amazing year, I wanted to give you an update and reboot
excitement around trampoline routing for 2021.
Acinq has been running a trampoline node for more than a year to provide
simple
and reliable payments for tens of thousands of Phoenix [1] users. We've
learned
a lot and I just opened a new trampoline routing spec PR to reflect that
[2].
The TL;DR is:
* it's simpler than the previous proposal and more flexible
* it makes MPP more cost-efficient and reliable
* it works nicely with rendezvous or route blinding
* it's as private as normal payments (likely more private) if used properly
(details in the PR)
I strongly believe the current state of trampoline routing can provide great
benefits in terms of wallet UX and reliability, but we need more reviews for
the spec to converge before it can be broadly deployed without fear of
moving
parts or breaking changes. Please have a look at the proposal without
preconceived ideas; you may be surprised by how simple and natural it feels.
I also want to stress that the code changes are very reasonable as it
re-uses
a lot of components that are already part of every lightning implementation
and
doesn't introduce new assumptions.
As a matter of fact, an independent implementation has been completed by the
Electrum team and has been recently tested E2E on mainnet! Having a spec
agreement on feature bits, invoice hints format and onion error codes would
allow their wallet to fully interoperate with Phoenix and future trampoline
wallets, as well as unblock development of even more improvements.
Happy end of year to all and stay #reckless in 2021!
Bastien
[1] https://phoenix.acinq.co/
[2] https://github.com/lightningnetwork/lightning-rfc/pull/829
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201228/3e357e16/attachment.html>

2023-06-09 13:01:37

- reply

📅 Original date posted:2020-11-30
📝 Original message:
Hi Joao,
Thanks for the time you spent on this, the paper is clear on the trade-offs
(sacrificing some privacy for
efficiency).
My main negative feedback here is that you seem to assume that nodes will
honestly cooperate.
It feels to me that nodes can cheat and gossip biased or invalid
information to their peers in order to
attract more payments through their nodes (and collect more fees or put
honest routing nodes out of
business).
Is that something you've thought about?
Cheers,
Bastien
Le dim. 29 nov. 2020 à 00:46, João Valente <jvalente96 at gmail.com> a écrit :
> Hey!
>
> I've been working on this new concept for routing in the lightning
> network. It leverages the use of the information nodes have on the
> distribution of funds in their channels to try and maximize the probability
> of success for a payment.
> Each node shares with his neighbours the information it has about the
> distribution of funds in its own neighbourhood through the form of a
> routing table. As nodes receive new tables they'll be updating their own
> locally maintained tables with the new information, periodically sharing
> them with their neighbours.
> Routing tables associate destination addresses (representing nodes in the
> network) to the next hop in the maximum capacity path to these nodes.
> If a new payment is to be made a payment probe is forwarded by the payer
> and through every node in the path, collects the path information along the
> way, and reaches the payee who returns it to the payer. The payer can then
> use this knowledge and confidently use the discovered path to route LN
> payments through.
>
> I wrote a 10 page paper about the subject and would love to get some
> feedback:
>
> https://drive.google.com/file/d/1dahW0X-N59138ZbY-4odpXjpDnX4Gb7Z/view?usp=sharing
>
> Cheers,
> João Valente
> _______________________________________________
> 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/20201130/83c558c8/attachment.html>

2023-06-09 13:01:33

- reply

📅 Original date posted:2020-11-27
📝 Original message:
Good morning list,
This is an interesting approach to solve this problem, I really like the
idea.
It definitely deserves digging more into it: the fact that it doesn't add
an additional
payment makes it largely superior to upfront payment schemes in terms of UX.
If we restrict these stake certificates to LN funding txs, which have a
very specific format
(multisig 2-of-2) there are probably smart ways to achieve this.
If for example we're able to do it easily with Schnorr-based funding txs,
it may be worth
waiting for that to happen.
I'm a bit afraid of having to use ZKPs for general statements, I'd prefer
something tailored
to that specific case (it would likely be more efficient and have less new
assumptions - even
though you're right to point out that this is a non-critical system, so
we're freer to experiment
with hot new stuff).
I completely agree with Z that it should be added to the requirements that
a node cannot
reuse a stake certificate from another node for himself.
Another constraint is that the proof has to be small, since we have to fit
> it all in a small onion...
>
I'm not sure that's necessary. If I understand correctly, you're saying
that because in your
model, the sender (Alice) creates one stake certificate for each node in
the route (Bob, Carol)
and puts them in the onion.
But instead it could be a point-to-point property: each node provides its
own stake certificate
to the next node (and only to that node). Alice provides a stake
certificate to Bob, then Bob
provides a stake certificate to Carol, and so on. If that's the case, it
can be in a tlv field in the
`update_add_htlc` message and doesn't need to be inside the onion. This
also makes it less
likely that Alice is exposing herself to remote nodes in the route (payer
privacy).
Of course, this depends on the implementation details we choose, but I
think it's worth stressing
that these two models exist and are quite different.
Thanks,
Bastien
Le ven. 27 nov. 2020 à 07:46, ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> a écrit :
> Good morning Gleb,
>
> > Thank you for your interest :)
> >
> > > Quick question: if I am a routing node and receive a valid stake
> certificate, can I reuse this stake certificate on my own outgoing payments?
> >
> > That probably should be avoided, otherwise a mediocre routing node gets
> a lot of jamming opportunities for no good.
> >
> > You are right, that’s a strong argument for proof “interactivity”: every
> Certificate should probably commit to *at least* public key of the routing
> node it is generated for.
>
> Right, it would be better to have the certificate commit to a specific
> routing node rather than the payment hash/point as I proposed.
> Committing to a payment hash/point allows a random forwarding node to
> probe the rest of the network using the same certificate, lowering the
> score for that certificate on much of the network.
>
> Another constraint is that the proof has to be small, since we have to fit
> it all in a small onion...
>
> Presumably we also want the score to eventually "settle to 0" over time.
>
> Regards,
> ZmnSCPxj
>
> >
> > – gleb
> > On Nov 27, 2020, 2:16 AM +0200, ZmnSCPxj <ZmnSCPxj at protonmail.com>,
> wrote:
> >
> > > Good morning Gleb and Antoine,
> > >
> > > This is certainly interesting!
> > >
> > > Quick question: if I am a routing node and receive a valid stake
> certificate, can I reuse this stake certificate on my own outgoing payments?
> > >
> > > It seems to me that the proof-of-stake-certificate should also somehow
> integrate a detail of the current payment (such as payment hash/point) so
> it cannot be reused by routing nodes for their own outgoing payments.
> > >
> > > For example, looking only at your naive privacy-broken proposal, the
> signature must use a `sign-to-contract` where the `R` in the signature is
> actually `R' + h(R' | payment_hash)` with the `R'` also revealed.
> > >
> > > Regards,
> > > ZmnSCPxj
> > >
> > > > Hello list,
> > > >
> > > > In this post, we explore a different approach to channel jamming
> mitigation.
> > > > We won’t talk about the background here, for the problem description
> as well as some proposed solutions (mainly upfront payment schemes), see
> [1].
> > > >
> > > > We’re suggesting using UTXO ownership proofs (a.k.a. Stake
> Certificates) to solve this problem. Previously, these proofs were only
> used in the Lightning Network at channel announcement time to prevent
> malicious actors from announcing channels they don’t control. One can think
> of it as a “fidelity bond” (as a scarce resource) as a requirement for
> sending HTLCs.
> > > >
> > > > We start by overviewing issues with other solutions, and then
> present a naive, privacy-broken Stake Certificates. Then we examine
> designing a privacy-preserving version, evaluating them. At the end, we
> talk about non-trivial design decisions and open questions.
> > > >
> > > > ## Issues with other proposals
> > > >
> > > > We find unsatisfying that upfront payment schemes come at a cost of
> new fees (forward and/or backward), thus inflating payment cost for *any*
> payment.
> > > > In the future, the upfront base fee might even make “micropayments”
> economically infeasible by exceeding the value they transfer. Thus, a good
> solution should not inflate payment cost while still requiring “burning” a
> scarce resource (so that the attack is not free).
> > > >
> > > > Another issue with upfront payments is a circular trust dependency.
> Ideally, we shouldn’t introduce anything less trust-minimized than the
> Lightning Network itself.
> > > > Upfront payment schemes are not like that, because they in one way
> or another rely on the honest behavior of route participants.
> > > >
> > > > We believe Stake Certificates we are going to introduce are
> satisfactory in both of these directions: they don’t inflate payment costs
> for honest users and don’t require trust. The main disadvantage of Stake
> Certificates seems to be the novel cryptography required.
> > > > See more details in the “Evaluation” section.
> > > >
> > > > ## Channel Ownership Proofs as Routing Credit Balance
> > > >
> > > > Let’s say Alice wants to relay an HTLC to Carol through Bob. Per the
> Stake Certificates scheme, she has to commit to a particular channel UTXO
> by embedding an ownership proof in the onion packet while sending an HTLC
> to Bob.
> > > >
> > > > Bob then unwraps the onion and verifies:
> > > > 1) the channel identifier is pointing unambiguously to an on-chain
> UTXO;
> > > > 2) the ownership proof (e.g., a signature) is valid against the
> previously disclosed UTXO witness script.
> > > >
> > > > If all those checks succeed, Bob should see if Alice hasn’t exceeded
> her credit balance. In case she hasn’t, Bob has to “decrement Alice’s
> credit balance” and relay the HTLC to Carol.
> > > > Decrementing credit balance unconditionally of packet success or
> failure bounds liquidity abuse by malicious HTLC senders.
> > > > Since there is no credit assigned initially, “decrementing the
> credit balance” means just remembering that “Alice spent X out of Y of the
> credit she received for her Stake Certificates”.
> > > >
> > > > Unfortunately, this naive protocol is a privacy nightmare, because
> routing nodes can now easily assign every HTLC they forward to the sender’s
> UTXO.
> > > >
> > > > Let’s first define the terms here one more time, and then proceed to
> the non-naive, private Stake Certificates.
> > > >
> > > > - Stake Certificate. Either means a solution we’re proposing or the
> primitive it is based on, namely proof of UTXO ownership. As we will argue
> later, it actually makes sense to use proof of LN channel UTXO ownership
> specifically rather than any funds ownership.
> > > > - Stake Certificate value. An amount of the corresponding UTXO or a
> ballpark this amount provably belongs to.
> > > > - Credit balance. When Alice provides a routing node Bob with a
> Stake Certificate, Bob should increase Alice’s routing credit balance.
> Alice is then limited in her payments by this balance, and this rule is
> enforced by routing nodes to prevent free channel jamming in the network.
> Note that ideally “Alice’s credit balance“ should be virtual and only known
> to Alice, while routing nodes should only observe per-UTXO credit balance.
> We currently assume that each routing node keeps track of per-UTXO credit
> balance separately, see “Design decisions” for more details.
> > > > - Stake-to-credit function defines how much credit balance is given
> per a Stake Certificate of a given value. This function is a policy of a
> routing node, and it should be announced.
> > > > - Credit-to-value-transferred function defines how much value a
> sender can transfer along a given channel considering how much credit they
> might claim. The function may also consider different factors (e.g., the
> available capacity of a channel being used) to provide extra robustness.
> > > >
> > > > ## Privacy-preserving Stake Certificates
> > > >
> > > > The presented scheme could preserve privacy if it relied on
> zero-knowledge proofs of UTXO ownership by avoiding pointing to a
> particular UTXO.
> > > > More specifically, the verifier should be able to check that:
> > > > a) The staked UTXO is an element of the current UTXO set
> > > > b) The prover knows the witness script committed by the UTXO witness
> program
> > > > c) The prover knows a valid witness for the witness script
> > > > d) The staked UTXO was not used to produce a different Stake
> Certificate which is currently in use as well.
> > > >
> > > > The verifier should also have a way to see a Stake Certificate value
> to properly account for the credit. This can be achieved by restricting the
> UTXO set being proved upon to only those UTXOs with a specific range of
> values: “I will prove that I own a UTXO among all UTXOs between 0.5 BTC and
> 1 BTC”.
> > > >
> > > > Unfortunately, steps (b) and (c) require zero-knowledge protocols
> for general statements, which are more experimental primitives than most of
> the stuff we have in Bitcoin protocols,
> > > > although we assume it’s feasible to consider them for non-consensus
> stuff.
> > > >
> > > > ## Evaluation
> > > >
> > > > Stake Certificates, upfront payment schemes, and other potential
> solutions (given a particular configuration) may be compared along the
> following axis:
> > > > 1) Economic feasibility
> > > > 1a) What is the cost of overcoming the protection for an attacker?
> Likely a non-linear function: sats_spent =f(channels_to_jam, […])
> > > > 1b) How does this solution limit honest users?
> > > > 2) How sophisticated is this solution in terms of integration and
> making good UX?
> > > > 3) How complex is this solution in terms of protocol
> design/implementation?
> > > >
> > > > When it comes to (1a), both Stake Certificates and upfront payments
> are probably equal, in a way that they’re just best-effort ideas to
> increase the attack cost. Unfortunately, we currently don’t know how to
> design something as economically powerful as PoW in Bitcoin [3].
> > > > This aspect can be properly evaluated by applying these ideas to
> different hypothetical kinds of LN in a simulation and observing the
> resulting trade-off between (1a) and (1b) considering different attack
> strategies.
> > > >
> > > > In the previous sections of this post, we have argued that Stake
> Certificates may provide a much better (1b) for the cost of (3) because it
> relies on zero-knowledge.
> > > > When it comes to (2), the design of Stake Certificates may vary in
> terms of UX burden, from completely automatic to requiring custom actions
> with private keys from users.
> > > >
> > > > Some of these trade-offs along with other interesting questions are
> discussed in the following section.
> > > >
> > > > ## Design decisions and questions
> > > >
> > > > #### Should the credit spending be gossipped across the entire
> network, or should only the routing nodes involved in the payment know?
> > > >
> > > > Economically, these two approaches are likely to be equivalent, and
> it’s just a matter of stake-to-credit ratio.
> > > > However, announcing credit spending to the network results in a
> privacy leak. It also imposes bandwidth and CPU overhead on the routing
> nodes.
> > > >
> > > > #### Which zero-knowledge system should be used for Stake
> Certificates?
> > > >
> > > > Choosing a ZK system boils down to picking the right trade-offs of
> proving and verifying time, and assumptions. As we mentioned previously, we
> would need proving general statements.
> > > > At the same time, we need something cheap in both proving and
> verification, because Lightning is supposed to be fast.
> > > > At the same time, the setup probably doesn’t matter, because proofs
> are supposed to be verified only by one participant, a routing node this
> proof is generated for.
> > > > Perhaps we can also pick any cryptographic assumptions we want since
> this stuff is not mission-critical and can be easily updated if someone
> breaks a cryptographic assumption and we observe an attack.
> > > >
> > > > #### Should we allow holding *any* Bitcoins (not just LN channels)
> for Stake Certificates?
> > > >
> > > > This idea might make sense if we’re worried that some LN users might
> want to send more payments than they can afford per their credit. However,
> we believe that allowing any UTXO would give an attacker more opportunities
> to use their cold funds for this attack, or even have a secondary market
> where holders sell their proofs (they have nothing to loose).
> > > > Instead, we should a) design the credit-to-stake-functions better;
> b) encourage users send payments across different routing nodes (since
> credits are not tracked globally) [4].
> > > >
> > > > #### What’s the best credit-to-value-transferred function?
> > > >
> > > > We reckon that this function should be not just linear to provide
> maximum security against malicious channel jammers. For example, we can
> charge more credit for the last 20% of the capacity of the *channel used
> for routing*. Alternatively, we could discourage making too many payments
> from the same UTXO within a short period of time by charging more credit in
> this case.
> > > >
> > > > #### What about the interactivity and lifetime of Stake Certificates?
> > > >
> > > > Interactive proofs mean that they are constructed on demand of a
> routing node, non-interactive means constructed by a payment sender ahead
> of time.
> > > > Both interactivity and lifetime have something to do with the ease
> of producing proof and accessing keys.
> > > > We will omit the details of the trade-off we consider, but it
> remains an open question.
> > > >
> > > > #### If Stake Certificates are valid for N blocks after proof
> generation, does it mean that if the UTXO is spent during those N blocks,
> new proof can be generated from the same coins without invalidating the old
> proof?
> > > >
> > > > Yes, but an attacker would, first of all, have to pay an on-chain
> fee for this. If we’re still worried about this problem, there are
> workaround ideas.
> > > > For example, we could have epochs of 100 blocks (every epoch starts
> at #XYZXYZ00 block). If at the start of an epoch, a channel wasn’t in the
> UTXO set, it provides very little credit.
> > > > Alternatively, we could expand the zero-knowledge part to proving
> that the coins were not yet spent.
> > > >
> > > > #### Should spending a UTXO reveal all Stake Certificates generated
> from it?
> > > >
> > > > This would also solve the problem in the previous question, but it
> would mean a retrospective privacy leak again. To avoid a privacy leak, we
> should prevent this.
> > > >
> > > > #### What if malicious Sybil *routing* nodes failing payments
> causing other honest routing nodes to reduce the credit of an honest
> payment sender?
> > > >
> > > > Both Stake Certificates and upfront payment schemes suffer from
> malicious routing nodes failing the payments and “wasting” the sender’s
> credit or fees. This problem even applies out of the channel jamming
> context, when considering payment failure rate.
> > > > This problem can be addressed by reducing the reputation of faulty
> links and routing nodes on the payment sender node. When payment routing
> becomes a for-profit activity, this would encourage routing nodes to
> sanitize their links.
> > > > The mitigation can be even stronger by using “provable blaming”
> introduced in [2].
> > > >
> > > > ## Conclusion
> > > >
> > > > We propose Stake Certificates, a new solution to channel jamming.
> Perhaps, it might not be the best near-term solution due to the complexity,
> but the zero satoshi overhead for honest payments is an appealing argument
> to switch to it in the future.
> > > > This proposal also illustrates how stake-based protocols can solve
> Sybil challenges in the Bitcoin ecosystem. Since this might be useful in
> other contexts (Sybil-resistance of many kinds, proof-of-ownership),
> discussing Stake Certificates is even more useful.
> > > > The next step is a discussion of Stake Certificates. If the
> community finds it interesting, then we should discuss the design questions
> mentioned above, and choose a cryptosystem.
> > > >
> > > > Cheers,
> > > > Gleb Naumenko and Antoine Riard
> > > >
> > > > ———
> > > >
> > > > References and footnotes:
> > > > 1.
> https://github.com/t-bast/lightning-docs/blob/master/spam-prevention.md
> > > > 2.
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2015-August/000135.html
> > > > 3. We don’t actually suggest PoW to solve these issues, because a)
> the trade-off between honest user cost and attacker cost is misaligned due
> to specialized hardware and b) smartphones would die too fast if they have
> to compute PoW; PoW is just an unreachable example of system robustness due
> to well-aligned game theory.
> > > > 4. Secondary markets are still possible even if we restrict
> acceptable proofs to only LN channels, but supply would be much smaller,
> and markets would work much worse for an attacker.
>
>
> _______________________________________________
> 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/20201127/89af90d4/attachment-0001.html>

2023-06-09 13:01:29

- reply

📅 Original date posted:2020-11-19
📝 Original message:
Hey Rusty,
Good questions.
I think we could use additive tweaks, and they are indeed faster so it can
be worth doing.
We would replace `B(i) = HMAC256("blinded_node_id", ss(i)) * P(i)` by `B(i)
= HMAC256("blinded_node_id", ss(i)) * G + P(i)`.
Intuitively since the private key of the tweak comes from a hash function,
it should offer the same security.
But there may be dragons lurking there, I don't know how to properly
evaluate whether it's as secure (whereas the multiplicative
version is really just Sphinx, so we know it should be secure).
If we're able to use additive tweaks, we can probably indeed use x-only
pubkeys.
Even though we're not storing these on-chain, so the 1 byte saved isn't
worth much.
I'd say that if it's trivial to use them, let's do it, otherwise it's not
worth any additional effort.
Cheers,
Bastien
Le mer. 18 nov. 2020 à 06:18, Rusty Russell <rusty at rustcorp.com.au> a
écrit :
>
> See:
>
> https://github.com/lightningnetwork/lightning-rfc/blob/route-blinding/proposals/route-blinding.md
>
> 1. Can we use additive tweaks instead of multiplicative?
> They're slightly faster, and supported by the x-only secp API.
> 2. Can we use x-only pubkeys? It's generally trivial, and a byte
> shorter. I'm using them in offers to great effect.
>
> Thanks!
> Rusty.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201119/90ab3153/attachment.html>

2023-06-09 13:01:26

- reply

📅 Original date posted:2020-11-02
📝 Original message:
Good morning Joost and Z,
So in your proposal, an htlc that is received by a routing node has the
> following properties:
> * htlc amount
> * forward up-front payment (anti-spam)
> * backward up-front payment (anti-hold)
> * grace period
> The routing node forwards this to the next hop with
> * lower htlc amount (to earn routing fees when the htlc settles)
> * lower forward up-front payment (to make sure that an attacker at the
> other end loses money when failing quickly)
> * higher backward up-front payment (to make sure that an attacker at the
> other end loses money when holding)
> * shorter grace period (so that there is time to fail back and not lose
> the backward up-front payment)
That's exactly it, this is a good summary.
An issue with the bidirectional upfront/hold fees is related to trustless
> offchain-to-onchain swaps, like Boltz and Lightning Loop.
> As the claiming of the offchain side is dependent on claiming of the
> onchain side of the trustless swap mechanism, which is *definitely* slow,
> the swap service will in general be forced to pay up the hold fees.
Yes, that is a good observation.
But shouldn't the swap service take that into account in the fee it
collects to
perform the swap? That way it is in fact the user who pays for that fee.
Cheers,
Bastien
Le mer. 28 oct. 2020 à 02:13, ZmnSCPxj <ZmnSCPxj at protonmail.com> a écrit :
> Good morning Bastien, Joost, and all,
>
> An issue with the bidirectional upfront/hold fees is related to trustless
> offchain-to-onchain swaps, like Boltz and Lightning Loop.
>
> As the claiming of the offchain side is dependent on claiming of the
> onchain side of the trustless swap mechanism, which is *definitely* slow,
> the swap service will in general be forced to pay up the hold fees.
>
> It seems to me that the hold-fees mechanism cannot be ported over in the
> onchain side, so even if you set a "reasonable" grace period at the swap
> service of say 1 hour (and assuming forwarding nodes are OK with that
> humongous grace period!), the onchain side of the swap can delay the
> release of onchain.
>
> To mitigate against this, the swap service would need to issue a separate
> invoice to pay for the hold fee for the "real" swap payment.
> The Boltz protocol supports a separate mining-fee invoice (disabled on the
> Boltz production servers) that is issued after the invoice is "locked in"
> at the swap service, but I think that in view of the use of hold fee, a
> combined mining-fee+hold-fee invoice would have to be issued at the same
> time as the "real" swap invoice.
>
> Regards,
> ZmnSCPxj
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201102/35e0cd03/attachment.html>

2023-06-09 13:01:20

- reply

📅 Original date posted:2020-10-14
📝 Original message:
To be honest the current protocol can be hard to grasp at first (mostly
because it's hard to reason
about two commit txs being constantly out of sync), but from an
implementation's point of view I'm
not sure your proposals are simpler.
One of the benefits of the current HTLC state machine is that once you
describe your state as a set
of local changes (proposed by you) plus a set of remote changes (proposed
by them), where each of
these is split between proposed, signed and acked updates, the flow is
straightforward to implement
and deterministic.
The only tricky part (where we've seen recurring compatibility issues) is
what happens on
reconnections. But it seems to me that the only missing requirement in the
spec is on the order of
messages sent, and more specifically that if you are supposed to send a
`revoke_and_ack`, you must
send that first (or at least before sending any `commit_sig`). Adding test
scenarios in the spec
could help implementers get this right.
It's a bit tricky to get it right at first, but once you get it right you
don't need to touch that
code again and everything runs smoothly. We're pretty close to that state,
so why would we want to
start from scratch? Or am I missing something?
Cheers,
Bastien
Le mar. 13 oct. 2020 à 13:58, Christian Decker <decker.christian at gmail.com>
a écrit :
> I wonder if we should just go the tried-and-tested leader-based
> mechanism:
>
> 1. The node with the lexicographically lower node_id is determined to
> be the leader.
> 2. The leader receives proposals for changes from itself and the peer
> and orders them into a logical sequence of changes
> 3. The leader applies the changes locally and streams them to the peer.
> 4. Either node can initiate a commitment by proposing a `flush` change.
> 5. Upon receiving a `flush` the nodes compute the commitment
> transaction and exchange signatures.
>
> This is similar to your proposal, but does away with turn changes (it's
> always the leader's turn), and therefore reduces the state we need to
> keep track of (and re-negotiate on reconnect).
>
> The downside is that we add a constant overhead to one side's
> operations, but since we pipeline changes, and are mostly synchronous
> during the signing of the commitment tx today anyway, this comes out to
> 1 RTT for each commitment.
>
> On the other hand a token-passing approach (which I think is what you
> propose) require a synchronous token handover whenever a the direction
> of the updates changes. This is assuming I didn't misunderstand the turn
> mechanics of your proposal :-)
>
> Cheers,
> Christian
>
> Rusty Russell <rusty at rustcorp.com.au> writes:
> > Hi all,
> >
> > Our HTLC state machine is optimal, but complex[1]; the Lightning
> > Labs team recently did some excellent work finding another place the spec
> > is insufficient[2]. Also, the suggestion for more dynamic changes makes
> it
> > more difficult, usually requiring forced quiescence.
> >
> > The following protocol returns to my earlier thoughts, with cost of
> > latency in some cases.
> >
> > 1. The protocol is half-duplex, with each side taking turns; opener
> first.
> > 2. It's still the same form, but it's always one-direction so both sides
> > stay in sync.
> > update+-> commitsig-> <-revocation <-commitsig revocation->
> > 3. A new message pair "turn_request" and "turn_reply" let you request
> > when it's not your turn.
> > 4. If you get an update in reply to your turn_request, you lost the race
> > and have to defer your own updates until after peer is finished.
> > 5. On reconnect, you send two flags: send-in-progress (if you have
> > sent the initial commitsig but not the final revocation) and
> > receive-in-progress (if you have received the initial commitsig
> > not not received the final revocation). If either is set,
> > the sender (as indicated by the flags) retransmits the entire
> > sequence.
> > Otherwise, (arbitrarily) opener goes first again.
> >
> > Pros:
> > 1. Way simpler. There is only ever one pair of commitment txs for any
> > given commitment index.
> > 2. Fee changes are now deterministic. No worrying about the case where
> > the peer's changes are also in flight.
> > 3. Dynamic changes can probably happen more simply, since we always
> > negotiate both sides at once.
> >
> > Cons:
> > 1. If it's not your turn, it adds 1 RTT latency.
> >
> > Unchanged:
> > 1. Database accesses are unchanged; you need to commit when you send or
> > receive a commitsig.
> > 2. You can use the same state machine as before, but one day (when
> > this would be compulsory) you'll be able signficantly simplify;
> > you'll need to record the index at which HTLCs were changed
> > (added/removed) in case peer wants you to rexmit though.
> >
> > Cheers,
> > Rusty.
> >
> > [1] This is my fault; I was persuaded early on that optimality was more
> > important than simplicity in a classic nerd-snipe.
> > [2] https://github.com/lightningnetwork/lightning-rfc/issues/794
> > _______________________________________________
> > 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/20201014/dcec5288/attachment.html>

2023-06-09 13:01:17

- reply

📅 Original date posted:2020-10-23
📝 Original message:
Hey Joost and Z,
I brought up the question about the amounts because it could be that
> amounts high enough to thwart attacks are too high for honest users or
> certain uses.
I don't think this is a concern for this proposal, unless there's an attack
vector I missed.
The reason I claim that is that the backwards upfront payment can be made
somewhat big without any
negative impact on honest nodes. If you're an honest intermediate node,
only two cases are possible:
* your downstream peer settled the HTLC quickly (before the grace period
ends): in that case you
refund him his upfront fee, and you have time to settle the HTLC upstream
while still honoring
the grace period, so it will be refunded to you as well (unless you delay
the settlement upstream
for whatever reason, in which case you deserve to pay the hold_fee)
* your grace period has expired, so you can't get a refund upstream: if
that happens, the grace
period with your downstream node has also expired, so you're earning money
downstream and paying
money upstream, and you'll usually even take a small positive spread so
everything's good
The only node that can end up loosing money on the backwards upfront
payment is the last node in
the route. But that node should always settle the HTLC quickly (or decide
to hodl it, but in that
case it's normal that it pays the hold_fee).
But what happens if the attacker is also on the other end of the
> uncontrolled spam payment? Not holding the payment, but still collecting
> the forward payments?
That's what I call short-lived `controlled spam`. In that case the attacker
pays the forward fee at
the beginning of the route but has it refunded at the end of the route. If
the attacker doesn't
want to lose any money, he has to release the HTLC before the grace period
ends (which is going to
be short-lived - at least compared to block times). This gives an
opportunity for legitimate payments
to use the HTLC slots (but it's a race between the attacker and the
legitimate users).
It's not ideal, because the attacker isn't penalized...the only way I think
we can penalize this
kind of attack is if the forward fee decrements at each hop, but in that
case it needs to be in the
onion (to avoid probing) and the delta needs to be high enough to actually
penalize the attacker.
Time to bikeshed some numbers!
C can trivially grief D here, making it look like D is delaying, by
> delaying its own `commitment_signed` containing the *removal* of the HTLC.
You're right to dive into these, there may be something here.
But I think your example doesn't work, let me know if I'm mistaken.
D is the one who decides whether he'll be refunded or not, because D is the
first to send the
`commit_sig` that removes the HTLC. I think we would extend `commit_sig`
with a tlv field that
indicates "I refunded myself for HTLC N" to help C compute the same commit
tx and verify sigs.
I agree with you that the details of how we'll implement the grace period
may have griefing attacks
depending on how we do it, it's worth exploring further.
Cheers,
Bastien
Le ven. 23 oct. 2020 à 12:50, ZmnSCPxj <ZmnSCPxj at protonmail.com> a écrit :
> Good morning t-bast,
>
>
> > > And in this case C earns.
> >
> > > Can C delay the refund to D to after the grace period even if D
> settled the HTLC quickly?
> >
> > Yes C earns, but D has misbehaved. As a final recipient, D isn't
> dependent on anyone downstream.
> > An honest D should settle the HTLC before the `grace_period` ends. If D
> chooses to hold the HTLC
> > for a while, then it's fair that he pays C for this.
>
>
> Okay, now let us consider the case where the supposedly-delaying party is
> not the final destination.
>
> So, suppose D indicates to C that it should fail the HTLC.
> In this case, C cannot immediately propagate the `update_fail_htlc`
> upstream, since the latest commitment transaction for the C<->D channel
> still contains the HTLC.
>
> In addition, our state machine is hand-over-hand, i.e. there is a small
> window where there are two valid commitment transactions.
> What happens is we sign the next commitment transaction and *then* revoke
> the previous one.
>
> So I think C can only safely propagate its own upstream `update_fail_htlc`
> once it receives the `revoke_and_ack` from D.
>
> So the time measured for the grace period between C and D should be from C
> sending `update_add_htlc` to C receiving `revoke_and_ack` from D, in case
> the HTLC fails.
> This is the time period that D is allowed to consume, and if it exceeds
> the grace period, it is penalized.
>
> (In this situation, it is immaterial if D is the destination: C cannot
> know this fact.)
>
> So let us diagram this better:
>
> C D
> |----update_add_htlc--->| ---
> |---commitment_signed-->| ^
> |<----revoke_and_ack----| |
> |<--commitment_signed---| |
> |-----revoke_and_ack--->| |
> | | grace period
> |<--update_fail_htlc----| |
> |<--commitment_signed---| |
> |-----revoke_and_ack--->| |
> |---commitment_signed-->| v <--- grief point!
> |<----revoke_and_ack----| ---
>
> (somebody *else* better make sure my understanding of the state machine is
> correct!)
>
> C can trivially grief D here, making it look like D is delaying, by
> delaying its own `commitment_signed` containing the *removal* of the HTLC.
> D cannot send its own `revoke_and_ack` until it receives the signature for
> its own next commitment, as if it did so, it would lose the ability to
> close the channel unilaterally; it has to wait for C to send the
> `commitment_signed`.
>
> Thus, it seems to me that C can grief D here.
>
> The question is: does the above C-can-grief-D matter?
>
> I think D does have a defense against C griefing in the above case:
>
> * If the time between D->`update_fail_htlc`->C and the corresponding
> C->`commitment_signed`->D becomes too long:
> * D drops the channel onchain.
> * The dropped commitment tx still contains the HTLC, since it is the
> "previous" commitment that D happens to hold that has not yet had the
> `update_fail_htlc` committed.
>
> If D performs the above, then C is forced to wait *even longer* (it has to
> wait out the HTLC timelock) before it can safely propagate the
> `update_fail_htlc`: D could be fooling with it and actually knows the
> preimage and claim it onchain, so C for its own safety *must* wait out the
> onchain timelock.
>
> Does that make sense?
> Does it sensibly protect against this griefing?
> Is it too much of a punishment and could potentially hurt D more than it
> hurts C if C is a heavily-connected node that will not miss the channel
> while D has fewer channels and opened the C<->D channel in the first place?
>
> --
>
> For success case `update_fulfill_htlc`, I believe C can immediately
> propagate this back to its upstream since it can now.
> Thus, in that case, we can stop the timer at the `update_fulfill_htlc`.
>
> So at least for the *end point* of the grace period, I think the end point
> should be:
>
> * If the HTLC failed:
> * When both participants have sent `revoke_and_ack`.
> * If the HTLC succeeded:
> * When the downstream participant has sent `update_fulfill_htlc`.
>
> For the *start point*, it seems the C->`commitment_signed`->D containing
> the HTLC would work as the start point.
> In particular, it seems to me that C can also deliberately defer its own
> C->`revoke_and_ack`->D:
>
> C D
> |----update_add_htlc--->|
> |---commitment_signed-->| ---
> |<----revoke_and_ack----| ^
> |<--commitment_signed---| |
> |-----revoke_and_ack--->| | <--- grief point!
> | | grace period
> |<--update_fail_htlc----| |
> |<--commitment_signed---| |
> |-----revoke_and_ack--->| |
> |---commitment_signed-->| v
> |<----revoke_and_ack----| ---
>
> (If D deliberately delays, then it is penalized, so we should consider the
> case where C attempts to trigger the reverse case).
> D cannot safely fulfill the HTLC until after the previous commitment
> transactions of *both* sides have been revoked ("irrevocably committed"
> state).
> So D can use the same defense, I think: if C is taking too long to send
> the `revoke_and_ack` pointed at above, it drops the channel onchain with
> the HTLC instantiated (which is why the *start time* has to be the
> C->`commitment_signed`->D that contains the new HTLC).
>
> Thus the D grace period has two smaller grace periods that D imposes on C,
> using the threat of channel drop to protect against the C-side griefing.
>
>
>
> Sorry for dropping into details already but so far this is the only
> griefing attack I can think of right now.
>
>
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201023/87e456f4/attachment.html>

2023-06-09 13:01:16

- reply

📅 Original date posted:2020-10-23
📝 Original message:
Thanks for your answers,
My first instinct is that additional complications are worse in general.
> However, it looks like simpler solutions are truly not enough, so adding
> the complication may very well be necessary.
I agree with both these statements ;). I'd love to find a simpler solution,
but this is the simplest
I've been able to come up with for now that seems to work without adding
griefing vectors...
The succeeding text refers to HTLCs "settling".
As you noted, settling means getting the HTLC removed from the commitment
transaction.
It includes both fulfills and fails, otherwise the proposal indeed doesn't
penalize spam.
If we also require that the hold fee be funded from the main output, then
> we cannot use single-funded channels, except perhaps with `push_msat`.
I see what you mean, the first payment cannot require a hold fee since the
fundee doesn't have a
main output. I think it's ok, it's the same thing as the reserve not being
met initially.
But you're right that there are potentially other mechanisms to enforce the
fee (like your suggestion
of subtracting from the HTLC output), I chose the simplest for now but we
can (and will) revisit
that choice if we think that the overall mechanisms work!
And in this case C earns.
Can C delay the refund to D to after the grace period even if D settled the
> HTLC quickly?
Yes C earns, but D has misbehaved. As a final recipient, D isn't dependent
on anyone downstream.
An honest D should settle the HTLC before the `grace_period` ends. If D
chooses to hold the HTLC
for a while, then it's fair that he pays C for this.
it is the fault of the peer for getting disconnected and having a delay in
> reconnecting, possibly forfeiting the hold fee because of that.
I think I agree with that, but we'll need to think about the pros and cons
when we get to details.
Is 1msat going to even deter anyone?
I am wondering though what the values for the fwd and bwd fees should be. I
> agree with ZmnSCPxj that 1 msat for the fwd is probably not going to be
> enough.
These values are only chosen for the simplicity of the example's sake. If
we agree the proposal works
to fight spam, we will do some calculations to figure a good value for
this. But I think finding the
right base values will not be the hard part, so we'll focus on this if
we're convinced the proposal
is worth exploring in full details.
It is interesting that the forward and backward payments are relatively
> independent of each other
To explain this further, I think it's important to highlight that the
forward fee is meant to fight
`uncontrolled spam` (where the recipient is an honest node) while the
backward fee is meant to fight
`controlled spam` (where the recipient also belongs to the attacker).
The reason it works is because the `uncontrolled spam` requires the
attacker to send a large volume
of HTLCs, so a very small forward fee gets magnified. The backward fee will
be much bigger because
in `controlled spam`, the attacker doesn't need a large volume of HTLCs but
holds them for a long
time. What I think is nice is that this proposal has only a tiny cost for
honest senders (the
forward fee).
What I'd really like to explore is whether there is a type of spam that I
missed or griefing attacks
that appear because of the mechanisms I introduce. TBH I think the
implementation details (amounts,
grace periods and their deltas, when to start counting, etc) are things
we'll be able to figure out
collectively later.
Thanks again for your time!
Bastien
Le ven. 23 oct. 2020 à 07:58, Joost Jager <joost.jager at gmail.com> a écrit :
> Hi Bastien,
>
> We add a forward upfront payment of 1 msat (fixed) that is paid
>> unconditionally when offering an HTLC.
>> We add a backwards upfront payment of `hold_fees` that is paid when
>> receiving an HTLC, but refunded
>> if the HTLC is settled before the `hold_grace_period` ends (see footnotes
>> about this).
>>
>
> It is interesting that the forward and backward payments are relatively
> independent of each other. In particular the forward anti-spam payment
> could quite easily be implemented to help protect the network. As you said,
> just transfer that fixed fee for every `update_add_htlc` message from the
> offerer to the receiver.
>
> I am wondering though what the values for the fwd and bwd fees should be.
> I agree with ZmnSCPxj that 1 msat for the fwd is probably not going to be
> enough.
>
> Maybe a way to approach it is this: suppose routing nodes are able to make
> 5% per year on their committed capital. An aggressive routing node could be
> willing to spend up to that amount to take down a competitor.
>
> Suppose the network consists only of 1 BTC, 483 slot channels. What should
> the fwd and bwd fees be so that even an attacked routing node will still
> earn that 5% (not through forwarding fees, but through hold fees) in both
> the controlled and the uncontrolled spam scenario?
>
> - Joost
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201023/7d252577/attachment-0001.html>

2023-06-09 13:01:15

- reply

📅 Original date posted:2020-10-22
📝 Original message:
Good morning list,
Sorry in advance for the lengthy email, but I think it's worth detailing my
hybrid proposal
(bidirectional upfront payments), it feels to me like a workable solution
that builds on
previous proposals. You can safely ignore the details at the end of the
email and focus only on
the high-level mechanism at first.
Let's consider the following route: A -----> B -----> C -----> D
We add a `hold_grace_period_delta` field to `channel_update` (in seconds).
We add two new fields in the tlv extension of `update_add_htlc`:
* `hold_grace_period` (seconds)
* `hold_fees` (msat)
We add an `outgoing_hold_grace_period` field in the onion per-hop payload.
When nodes receive an `update_add_htlc`, they verify that:
* `hold_fees` is not unreasonable large
* `hold_grace_period` is not unreasonably small or large
* `hold_grace_period` - `outgoing_hold_grace_period` >=
`hold_grace_period_delta`
Otherwise they immediately fail the HTLC instead of relaying it.
For the example we assume all nodes use `hold_grace_period_delta = 10`.
We add a forward upfront payment of 1 msat (fixed) that is paid
unconditionally when offering an HTLC.
We add a backwards upfront payment of `hold_fees` that is paid when
receiving an HTLC, but refunded
if the HTLC is settled before the `hold_grace_period` ends (see footnotes
about this).
* A sends an HTLC to B:
* `hold_grace_period = 100 sec`
* `hold_fees = 5 msat`
* `next_hold_grace_period = 90 sec`
* forward upfront payment: 1 msat is deduced from A's main output and added
to B's main output
* backwards upfront payment: 5 msat are deduced from B's main output and
added to A's main output
* B forwards the HTLC to C:
* `hold_grace_period = 90 sec`
* `hold_fees = 6 msat`
* `next_hold_grace_period = 80 sec`
* forward upfront payment: 1 msat is deduced from B's main output and added
to C's main output
* backwards upfront payment: 6 msat are deduced from C's main output and
added to B's main output
* C forwards the HTLC to D:
* `hold_grace_period = 80 sec`
* `hold_fees = 7 msat`
* `next_hold_grace_period = 70 sec`
* forward upfront payment: 1 msat is deduced from C's main output and added
to D's main output
* backwards upfront payment: 7 msat are deduced from D's main output and
added to C's main output
* Scenario 1: D settles the HTLC quickly:
* all backwards upfront payments are refunded (returned to the respective
main outputs)
* only the forward upfront payments have been paid (to protect against
`uncontrolled spam`)
* Scenario 2: D settles the HTLC after the grace period:
* D's backwards upfront payment is not refunded
* If C and B relay the settlement upstream quickly (before
`hold_grace_period_delta`) their backwards
upfront payments are refunded
* all the forward upfront payments have been paid (to protect against
`uncontrolled spam`)
* Scenario 3: C delays the HTLC:
* D settles before its `grace_period`, so its backwards upfront payment is
refunded by C
* C delays before settling upstream: it can ensure B will not get refunded,
but C will not get
refunded either so B gains the difference in backwards upfront payments
(which protects against
`controlled spam`)
* all the forward upfront payments have been paid (to protect against
`uncontrolled spam`)
* Scenario 4: the channel B <-> C closes:
* D settles before its `grace_period`, so its backwards upfront payment is
refunded by C
* for whatever reason (malicious or not) the B <-> C channel closes
* this ensures that C's backwards upfront payment is paid to B
* if C publishes an HTLC-fulfill quickly, B may have his backwards upfront
payment refunded by A
* if B is forced to wait for his HTLC-timeout, his backwards upfront
payment will not be refunded
but it's ok because B got C's backwards upfront payment
* all the forward upfront payments have been paid (to protect against
`uncontrolled spam`)
If done naively, this mechanism may allow intermediate nodes to deanonymize
sender/recipient.
If the base `grace_period` and `hold_fees` are randomized, I believe this
attack vector disappears,
but it's worth exploring in more details.
The most painful part of this proposal will be handling the `grace_period`:
* when do you start counting: when you send/receive `update_add_htlc`,
`commit_sig` or
`revoke_and_ack`?
* what happens if there is a disconnection (how do you account for the
delay of reconnecting)?
* what happens if the remote settles after the `grace_period`, but refunds
himself when sending his
`commit_sig` (making it look like from his point of view he settled before
the `grace_period`)?
I think in that case the behavior should be to give your peers some leeway
and let them get away
with it, but record it. If they're doing it too often, close channels and
ban them; stealing
upfront fees should never be worth losing channels.
I chose to make the backwards upfront payment fixed instead of scaling it
based on the time an HTLC
is left pending; it's slightly less penalizing for spammers, but is less
complex and introduces less
potential griefing against honest nodes. With the scaling approach, an
honest node that has its
channel unilaterally closed is too heavily penalized IMHO (because it has
to pay for the maximum
hold duration).
I also chose to make the forward upfront payment constant (1 msat). Is it
going to be a pain to
bikeshed this constant? Do we need to add a mechanism to upgrade it? We
don't want to make this
more complex than it should.
Before we dive into the specifics (addressing the implementation concerns),
can you all please take
a bit of time to figure out whether the proposed mechanisms would mitigate
spam or not, and whether
it introduces griefing attacks against honest nodes. I think it would be a
waste of your time to
bikeshed the nuts and bolts details if the proposal is fundamentally
broken...
Answering to previous emails below.
Your proposal to add a small upfront payment, wouldn't that allow the
> (arbitrary) grace period to be removed?
I think we need a `grace_period` for the backwards upfront payment, to
encourage nodes to settle
quickly (otherwise I believe it's too easy to grief honest nodes because
the backwards upfront payment
will be bigger than the forward one - because `uncontrolled spam` is based
on volume so it doesn't
need a huge fee to mitigate).
Would my inane incremental routing idea also be in scope here?
It could potentially be easier to integrate spam mitigation inside
incremental routing, indeed.
But I think this proposal is unfortunately very costly in terms of
latency...
Thanks everyone,
Bastien
Le mer. 21 oct. 2020 à 05:21, ZmnSCPxj <ZmnSCPxj at protonmail.com> a écrit :
> Good morning t-bast,
>
> >
> > I've started summarizing proposals, attacks and threat models on github
> [1].
> > I'm hoping it will help readers get up-to-speed and avoid falling in the
> same pitfalls we already
> > fell into with previous proposals.
>
> Would my inane incremental routing idea also be in scope here?
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-October/002811.html
>
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201022/4a7c0856/attachment.html>

2023-06-09 13:01:13

- reply

📅 Original date posted:2020-10-19
📝 Original message:
Good morning list,
I've started summarizing proposals, attacks and threat models on github [1].
I'm hoping it will help readers get up-to-speed and avoid falling in the
same pitfalls we already
fell into with previous proposals.
I've kept it very high-level for now; we can add nitty-gritty technical
details as we slowly
converge towards acceptable solutions. I have probably missed subtleties
from previous proposals;
feel free to contribute to correct my mistakes. I have omitted for examples
the details of Rusty's
previous proposal since he mentioned a new, better one that will be
described soon.
While doing this exercise, I couldn't find a reason why the `reverse
upfront payment` proposal
would be broken (notice that I described it using a flat amount after a
grace period, not an amount
based on the time HTLCs are held). Can someone point me to the most obvious
attacks on it?
It feels to me that its only issue is that it still allows spamming for
durations smaller than the
grace period; my gut feeling is that if we add a smaller forward direction
upfront payment to
complement it it could be a working solution.
Pasting it here for completeness:
### Reverse upfront payment
This proposal builds on the previous one, but reverses the flow. Nodes pay
a fee for *receiving*
HTLCs instead of *sending* them.
```text
A -----> B -----> C -----> D
B pays A to receive the HTLC.
Then C pays B to receive the forwarded HTLC.
Then D pays C to receive the forwarded HTLC.
```
There must be a grace period during which no fees are paid; otherwise the
`uncontrolled spam` attack
allows the attacker to force all nodes in the route to pay fees while he's
not paying anything.
The fee cannot be the same at each hop, otherwise it's free for the
attacker when he is at both
ends of the payment route.
This fee must increase as the HTLC travels downstream: this ensures that
nodes that hold HTLCs
longer are penalized more than nodes that fail them fast, and if a node has
to hold an HTLC for a
long time because it's stuck downstream, they will receive more fees than
what they have to pay.
The grace period cannot be the same at each hop either, otherwise the
attacker can force Bob to be
the only one to pay fees. Similarly to how we have `cltv_expiry_delta`,
nodes must have a
`grace_period_delta` and the `grace_period` must be bigger upstream than
downstream.
Drawbacks:
* The attacker can still lock HTLCs for the duration of the `grace_period`
and repeat the attack
continuously
Open questions:
* Does the fee need to be based on the time the HTLC is held?
* What happens when a channel closes and HTLC-timeout has to be redeemed
on-chain?
* Can we implement this without exposing the route length to intermediate
nodes?
Cheers,
Bastien
[1] https://github.com/t-bast/lightning-docs/blob/master/spam-prevention.md
Le dim. 18 oct. 2020 à 09:25, Joost Jager <joost.jager at gmail.com> a écrit :
> > We've looked at all kinds of trustless payment schemes to keep users
>>
>> > honest, but it appears that none of them is satisfactory. Maybe it is
>> even
>> > theoretically impossible to create a scheme that is trustless and has
>> all
>> > the properties that we're looking for. (A proof of that would also be
>>
>> > useful information to have.)
>>
>> I don't think anyone has drawn yet a formal proof of this, but roughly a
>> routing peer Bob, aiming to prevent resource abuse at HTLC relay is seeking
>> to answer the following question "Is this payment coming from Alice and
>> going to Caroll will compensate for my resources consumption ?". With the
>> current LN system, the compensation is conditional on payment settlement
>> success and both Alice and Caroll are distrusted yet discretionary on
>> failure/success. Thus the underscored question is undecidable for a routing
>> peer making relay decisions only on packet observation.
>>
>> One way to mitigate this, is to introduce statistical observation of
>> sender/receiver, namely a reputation system. It can be achieved through a
>> scoring system, web-of-trust, or whatever other solution with the same
>> properties.
>> But still it must be underscored that statistical observations are only
>> probabilistic and don't provide resource consumption security to Bob, the
>> routing peer, in a deterministic way. A well-scored peer may start to
>> suddenly misbehave.
>>
>> In that sense, the efficiency evaluation of a reputation-based solution
>> to deter DoS must be evaluated based based on the loss of the reputation
>> bearer related to the potential damage which can be inflicted. It's just
>> reputation sounds harder to compute accurately than a pure payment-based
>> DoS protection system.
>>
>
> I can totally see the issues and complexity of a reputation-based system.
> With 'trustless payment scheme' I meant indeed a trustless pure
> payment-based DoS protection system and the question whether such a system
> can be proven to not exist. A sender would pay an up-front amount to cover
> the maximum cost, but with the guarantee that nodes can only take a fair
> part of the deposit (based on actual lock time). Perhaps the taproot
> upgrade offers new possibilities with adaptor signatures to atomically swap
> part of the up-front payment with htlc-received-in-time-signatures from
> nodes downstream (random wild idea).
>
>
>> > What I can see working is a system where peers charge each other a hold
>> fee
>> > for forwarded HTLCs based on the actual lock time (not the maximum lock
>>
>> > time) and the htlc value. This is just for the cost of holding and
>> separate
>> > from the routing fee that is earned when the payment settles
>>
>> Yes I guess any solution will work as long as it enforces an asymmetry
>> between the liquidity requester and a honest routing peer. This asymmetry
>> can be defined as guaranteeing that the routing peer's incoming/outgoing
>> balance is always increasing, independently of payment success. Obviously
>> this increase should be materialized by a payment, while minding it might
>> be discounted based on requester reputation ("pay-with-your-reputation").
>> This reputation evaluation can be fully delegated to the routing node
>> policy, without network-wise guidance.
>>
>> That said, where I'm skeptical on any reputation-heavy system is on the
>> long-term implications.
>>
>> Either, due to the wants of a subset of actors deliberately willingly to
>> trade satoshis against discounted payment flow by buying well-scored
>> pubkeys, we see the emergence of a reputation market. Thus enabling
>> reputation to be fungible to satoshis, but with now a weird "reputation"
>> token to care about.
>>
>> Or, reputation is too hard to make liquid (e.g hard to disentangle
>> pubkeys from channel ownership or export your score across routing peers)
>> and thus you now have reputation scarcity which is introducing a bias from
>> a "purer" market, where agents are only routing based on advertised fees.
>> IMO, we should strive for the more liquid Lightning market we can, as it
>> avoids bias towards past actors and thus may contain centralization
>> inertia. I'm curious about your opinion on this last point.
>>
>
> I am in favor of more liquidity and less centralization, but as far as I
> know the reality is that we don't have a good solution yet to achieve this
> without being vulnerable to DoS attacks. If those attacks would happen on a
> large scale today, what would we do?
>
> Also peers can implement these trusted upfront payments without protocol
> changes. Just stop forwarding when the prepaid forwarding budget is used up
> and require a top-up. It may have been implemented already in parts of the
> network, I don't think there is a way to know. I've experimented a bit with
> the fee model myself (
> https://twitter.com/joostjgr/status/1317546071984427009). Node operators
> don't need to wait for permission.
>
> To me it seems that the longer it takes to come up with a good anti-DoS
> system for Lightning, the further the outside world will have developed
> their trust-based systems and established that potential bias towards
> centralization.
>
> That might be another reason to prioritize this issue. Not just because we
> want the network to be safe, but also to be able to implement the preferred
> solution while the opportunity window is still open.
>
> - Joost
> _______________________________________________
> 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/20201019/93818bf0/attachment.html>

2023-06-09 13:01:04

- reply

📅 Original date posted:2020-10-08
📝 Original message:
If I remember correctly, it looks very similar to how I2P establishes
tunnels, it may be worth
diving in their documentation to fish for ideas.
However in their case the goal is to establish a long-lived tunnel, which
is why it's ok to have
a slow and costly protocol. It feels to me that for payments, this is a lot
of messages and delays,
I'm not sure this is feasible at a reasonable scale...
Cheers,
Bastien
Le mer. 7 oct. 2020 à 19:34, ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> a écrit :
> Good morning Antoine, Bastien, and list,
>
> > > Instead of relying on reputation, the other alternative is just to
> have an upfront payment system, where a relay node doesn't have to account
> for a HTLC issuer reputation to decide acceptance and can just forward a
> HTLC as long it paid enough. More, I think it's better to mitigate jamming
> with a fees-based system than a web-of-trust one, less burden on network
> newcomers.
> >
> > Let us consider some of the complications here.
> >
> > A newcomer wants to make an outgoing payment.
> > Speculatively, it connects to some existing nodes based on some policy.
> >
> > Now, since forwarding is upfront, the newcomer fears that the node it
> connected to might not even bother forwarding the payment, and instead just
> fail it and claim the upfront fees.
> >
> > In particular: how would the newcomer offer upfront fees to a node it is
> not directly channeled with?
> > In order to do that, we would have to offer the upfront fees for that
> node, to the node we are channeled with, so it can forward this as well.
> >
> > - We can give the upfront fee outright to the first hop, and trust
> that if it forwards, it will also forward the upfront fee for the next hop.
> > - The first hop would then prefer to just fail the HTLC then and
> there and steal all the upfront fees.
> > - After all, the offerrer is a newcomer, and might be the
> sybil of a hacker that is trying to tie up its liquidity.
> > The first hop would (1) avoid this risk and (2) earn more
> upfront fees because it does not forward those fees to later hops.
> >
> > - This is arguably custodial and not your keys not your coins
> applies.
> > Thus, it returns us back to tr\*st anyway.
> >
> > - We can require that the first hop prove where along the route
> errored.
> > If it provably failed at a later hop, then the first hop can claim
> more as upfront fees, since it will forward the upfront fees to the later
> hop as well.
> > - This has to be enforcable onchain in case the channel gets
> dropped onchain.
> > Is there a proposal SCRIPT which can enforce this?
> >
> > - If not enforcable onchain, then there may be onchain shenanigans
> possible and thus this solution might introduce an attack vector even as it
> fixes another.
> > - On the other hand, sub-satoshi amounts are not enforcable
> onchain too, and nobody cares, so...
>
> One thing I have been thinking about, but have not proposed seriously yet,
> would be "incremental routing".
>
> Basically, the route of pending HTLCs also doubles as an encrypted
> bidirectional tunnel.
>
> Let me first describe how I imagine this "incremental routing" would look
> like.
>
> First, you offer an HTLC with a direct peer.
> The data with this HTLC includes a point, which the peer will ECDH with
> its own privkey, to form a shared secret.
> You can then send additional messages to that node, which it will decrypt
> using the shared secret as the symmetric encryption key.
> The node can also reply to those messages, by encrypting it with the same
> symmetric encryption key.
> Typically this will be via a stream cipher which is XORed with the real
> data.
>
> One of the messages you can send to that node (your direct peer) would be
> "please send out an HTLC to this peer of yours".
> Together with that message, you could also bump up the value of the HTLC,
> and possibly the CLTV delta, you have with that node.
> This bumping up is the forwarding fee and resolution time you have to give
> to that node in order to have it safely put an HTLC to the next hop.
>
> If there is a problem on the next hop, the node replies back, saying it
> cannot forward the HTLC further.
> Your node can then respond by giving an alternative next hop, which that
> node can reply back is also not available, etc. until you say "give up" and
> that node will just fail the HTLC.
>
> However, suppose the next hop is online and there is enough space in the
> channel.
> That node then establishes the HTLC with the next hop.
>
> At this point, you can then send a message to the direct peer which is
> nothing more than "send the rest of this message as the message to the next
> hop on the same HTLC, then wait for a reply and wrap it and reply to me".
> This is effectively onion-wrapping the message to the peer of your peer,
> and waiting for an onion-wrapped reply from the peer of your peer.
>
> You can then talk to the peer of your peer (of your peer...) to
> incrementally build the rest of the route, until you reach the destination.
>
> How is this related to upfront payments?
> Well, in upfront payments, on the timelock branch, instead of the entire
> fund value returning to the offerer of the HTLC, part of the fund value is
> given forward to the next peer.
> For onchain enforcement the upfront payment is simply added to the miner
> fees, so at least the one offerring it does not have incentive to drop it
> onchain to play onchain shenanigans.
>
> Now, suppose your direct peer requires an upfront payment before it will
> even bother make an outgoing HTLC on the strength of your incoming one.
> So, you bump up your HTLC, and arrange to have the timelock branch give
> the upfront payment to the direct peer.
>
> Then, you can now ask the peer to open an HTLC to the next peer, on the
> basis of that upfront payment.
>
> Of course, if the peer of the peer is not the destination, you still have
> to increment further.
> You then bump up the upfront payment of the direct peer, with a message to
> offer an equivalent amount of upfront payment to the peer of the peer.
> Your direct peer can then pretend that communication with the peer of the
> peer failed, so it should get the bumped-up upfront payment, equivalent to
> the upfront payments of itself plus the next peer.
>
> However, at any one time, the upfront payment that can be stolen by your
> direct peer can only amount to the upfront fee of a single hop, the one
> that is being built out next in the incremental routing.
> This is because it has already offered the upfront payment to the next hop.
>
> Some numbers may make this easier to understand.
> For example, suppose all nodes require 1msat prepaid to send out to the
> next hop.
> At the start, you are just offering the HTLC amount with 0 msat in upfront
> payment.
> Then you increase the upfront payment by 1msat, then tell the direct peer
> to create an HTLC to the peer of the peer, of equal HTLC value, but with 0
> msats in upfront payment.
> Next, you increase the upfront payment to the direct peer to 2msat, then
> tell the direct peer to bump up the upfront payment of its outgoing HTLC by
> 1 msat as well.
>
> Then next, you increase the upfront payment to the direct peer to 3 msat.
> The direct peer is giving out 1 msat upfront payment to the outgoing HTLC,
> which it is now supposed to increase to 2msat.
> After doing that, it sends a message to the peer of the peer.
> The peer of the peer is giving out 0 msat upfront payment, which it is now
> supposed to increase to 1 msat.
> After doing that, it sends a message to the peer of the peer of the peer.
> The peer of the peer of the peer has no outgoing HTLC yet, but since it is
> now being offered 1msat in upfront fee, it is now wlling to be instructed
> to send out an outgoing HTLC to another channel.
>
> And so on.
>
> At any one time, an intermediate node can pretend communications to the
> next node in the route failed, and claim 2msat in upfront fee instead of
> 1msat.
> But it cannot steal more than the equivalent of the upfront fee of one
> node.
>
> (I elide the fact that in this scheme, you would *also* offer a fee
> conditional on the HTLC actually pushing through; sort of like a "pay half
> now, pay half later on completion" deal; your imagination can fill in the
> rest.)
>
> This is in contrast with upfront payments where you have to offer the
> upfront payment of all the nodes along the route to the direct peer.
> The direct peer can, then and there, claim the entire upfront payment
> earmarked for the entire route.
>
> A nice thing about incremental routing is that the time risk of your money
> being locked up can be managed a little easier.
> You can start with an HTLC with the minimum time, then also bump up the
> time of the first HTLC (with time bumps rippling out along the incremental
> route) as you build up the incremental route until you reach the
> destination.
>
> --
>
> Against incremental routing, however, is that:
>
> * It requires a lot more communication rounds and (symmetric, at least)
> cryptographic operations.
> * Intermediate nodes can guess the distance from the source by measuring
> timing of a previous response to the next message from the payer.
> * In particular, current LN can allow an intermediate node to guess the
> distance to the destination of a payment (by CLTV delta bounds) but *not*
> the distance to the source of the payment, with incremental routing the
> distance to the source of the payment is guessable as well from message
> timings.
> * The idea is completely imaginary as of now with no peer review, and
> there may be actual cryptographic or practical problems with the idea.
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> 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/20201008/ce30e0c4/attachment.html>

2023-06-09 13:01:02

- reply

📅 Original date posted:2020-10-14
📝 Original message:
I totally agree with the simplicity argument, I wanted to raise this
because it's (IMO) an issue
today because of the way we deal with on-chain fees, but it's less
impactful once update_fee is
scoped to some min_relay_fee.
Let's put this aside for now then and we can revisit later if needed.
Thanks for the feedback everyone!
Bastien
Le lun. 12 oct. 2020 à 20:49, Olaoluwa Osuntokun <laolu32 at gmail.com> a
écrit :
> > 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 way). Just think about all the edge cases w.r.t
> _allocating
> enough funds to pay for fees_ we've discovered over the past few years in
> the state machine. I fear adding a more elaborate fee splitting mechanism
> would only blow up the number of obscure edge cases that may lead to a
> channel temporarily or permanently being "borked".
>
> If we're going to add a "fairer" way of splitting fees, we'll really need
> to
> dig down pre-deployment to ensure that we've explored any resulting edge
> cases within our solution space, as we'll only be _adding_ complexity to
> fee
> splitting.
>
> IMO, anchor commitments in their "final form" (fixed fee rate on commitment
> transaction, only "emergency" use of update_fee) significantly simplifies
> things as it shifts from "funding pay fees", to "broadcaster/confirmer pays
> fees". However, as you note this doesn't fully distribute the worst-case
> cost of needing to go to chain with a "fully loaded" commitment
> transaction.
> Even with HTLCs, they could only be signed at 1 sat/byte from the funder's
> perspective, once again putting the burden on the broadcaster/confirmer to
> make up the difference.
>
> -- Laolu
>
>
> On Mon, Oct 5, 2020 at 6:13 AM Bastien TEINTURIER via Lightning-dev <
> lightning-dev at lists.linuxfoundation.org> wrote:
>
>> Good morning list,
>>
>> It seems to me that the "funder pays all the commit tx fees" rule exists
>> solely for simplicity
>> (which was totally reasonable). I haven't been able to find much
>> discussion about this decision
>> on the mailing list nor in the spec commits.
>>
>> At first glance, it's true that at the beginning of the channel lifetime,
>> the funder should be
>> responsible for the fee (it's his decision to open a channel after all).
>> But as time goes by and
>> both peers earn value from this channel, this rule becomes questionable.
>> We've discovered since
>> then that there is some risk associated with having pending HTLCs
>> (flood-and-loot type of attacks,
>> pinning, channel jamming, etc).
>>
>> I think that *in some cases*, fundees should be paying a portion of the
>> commit-tx on-chain fees,
>> otherwise we may end up with a web-of-trust network where channels would
>> only exist between peers
>> that trust each other, which is quite limiting (I'm hoping we can do
>> better).
>>
>> Routing nodes may be at risk when they *receive* HTLCs. All the attacks
>> that steal funds come from
>> the fact that a routing node has paid downstream but cannot claim the
>> upstream HTLCs (correct me
>> if that's incorrect). Thus I'd like nodes to pay for the on-chain fees of
>> the HTLCs they offer
>> while they're pending in the commit-tx, regardless of whether they're
>> funder or fundee.
>>
>> The simplest way to do this would be to deduce the HTLC cost (172 *
>> feerate) from the offerer's
>> main output (instead of the funder's main output, while keeping the base
>> commit tx weight paid
>> by the funder).
>>
>> A more extreme proposal would be to tie the *total* commit-tx fee to the
>> channel usage:
>>
>> * if there are no pending HTLCs, the funder pays all the fee
>> * if there are pending HTLCs, each node pays a proportion of the fee
>> proportional to the number of
>> HTLCs they offered. If Alice offered 1 HTLC and Bob offered 3 HTLCs, Bob
>> pays 75% of the
>> commit-tx fee and Alice pays 25%. When the HTLCs settle, the fee is
>> redistributed.
>>
>> This model uses the on-chain fee as collateral for usage of the channel.
>> If Alice wants to forward
>> HTLCs through this channel (because she has something to gain - routing
>> fees), she should be taking
>> on some of the associated risk, not Bob. Bob will be taking the same risk
>> downstream if he chooses
>> to forward.
>>
>> I believe it also forces the fundee to care about on-chain feerates,
>> which is a healthy incentive.
>> It may create a feedback loop between on-chain feerates and routing fees,
>> which I believe is also
>> a good long-term thing (but it's hard to predict as there may be negative
>> side-effects as well).
>>
>> What do you all think? Is this a terrible idea? Is it okay-ish, but not
>> worth the additional
>> complexity? Is it an amazing idea worth a lightning nobel? Please don't
>> take any of my claims
>> for granted and challenge them, there may be negative side-effects I'm
>> completely missing, this is
>> a fragile game of incentives...
>>
>> Side-note: don't forget to take into account that the fees for HTLC
>> transactions (second-level txs)
>> are always paid by the party that broadcasts them (which makes sense). I
>> still think this is not
>> enough and can even be abused by fundees in some setups.
>>
>> Thanks,
>> Bastien
>> _______________________________________________
>> 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/20201014/faaa0eeb/attachment-0001.html>

2023-06-09 13:01:01

- reply

📅 Original date posted:2020-10-08
📝 Original message:
Thanks (again) Antoine and Zman for your answers,
On the other hand, a quick skim of your proposal suggests that it still
> respects the "initiator pays" principle.
> Basically, the fundee only pays fees for HTLCs they initiated, which is
> not relevant to the above attack (since in the above attack, my node is a
> dead end, you will never send out an HTLC through my channel to rebalance).
> So it should still be acceptable.
I agree, my proposal would have the same result as today's behavior in that
case.
Unless your throw-away node waited for me to add an HTLC in its channel, in
that case I would pay a
part of the fee (since I'm adding that HTLC). That leans towards the first
of my two proposals,
where the funder always pays the "base" fee and htlc fees are split
depending on who proposed the HTLC.
The channel initiator shouldn't have to pay for channel-closing as it's
> somehow a liquidity allocation decision
I agree 100%. Especially since mutual closing should be preferred most of
the time.
That said, a channel closing might be triggered due to a security
> mechanism, like a HTLC to timeout onchain. Thus a malicious counterparty
> can easily loop a HTLC forwarding on an honest peer. Then not cancel it
> on-time to force the honest counterparty to pay onchain fees to avoid a
> offered HTLC not being claimed back on time.
Yes, this is an issue, but the only way to fix it today is to never be the
funder, always be fundee
and I think that creates unhealthy, assymetric incentives.
This is a scenario where the other node will only burn you once; if you
notice that behavior you'll
be forced to pay on-chain fees, but you'll ban this peer. And if he opened
the channel to you, he'll
still be paying the "base" fee. I don't think there's a silver bullet here
where you can completely
avoid being bitten by such malicious nodes, but you can reduce exposure and
ban them after the fact.
Another note on using a minimal relay fee; in a potential future where
on-chain fees are always
high and layer 1 is consistently busy, even that minimal relay fee will be
costly. You'll want your
peer to pay for the HTLCs it's responsible for to split the on-chain fee
more fairly. So I believe
moving (slightly) away from the "funder pays all" model is desirable (or at
least it's worth
exploring seriously in order to have a better reason to dismiss it than
"it's simpler").
Does that make sense?
Thanks,
Bastien
Le mar. 6 oct. 2020 à 18:30, Antoine Riard <antoine.riard at gmail.com> a
écrit :
> Hello Bastien,
>
> I'm all in for a model where channel transactions are pre-signed with a
> reasonable minimal relay fee and the adjustment is done by the closer. The
> channel initiator shouldn't have to pay for channel-closing as it's somehow
> a liquidity allocation decision ("My balance could be better allocated
> elsewhere than in this channel").
>
> That said, a channel closing might be triggered due to a security
> mechanism, like a HTLC to timeout onchain. Thus a malicious counterparty
> can easily loop a HTLC forwarding on an honest peer. Then not cancel it
> on-time to force the honest counterparty to pay onchain fees to avoid a
> offered HTLC not being claimed back on time.
>
> AFAICT, this issue is not solved by anchor outputs. A way to decentivize
> this kind of behavior from a malicious counterparty is an upfront payment
> where the upholding HTLC fee * HTLC block-buffer-before-onchain is higher
> than the cost of going onchain. It should cost higher for the counterparty
> to withhold a HTLC than paying onchain-fees to close the channel.
>
> Or can you think about another mitigation for the issue raised above ?
>
> Antoine
>
> Le lun. 5 oct. 2020 à 09:13, Bastien TEINTURIER via Lightning-dev <
> lightning-dev at lists.linuxfoundation.org> a écrit :
>
>> Good morning list,
>>
>> It seems to me that the "funder pays all the commit tx fees" rule exists
>> solely for simplicity
>> (which was totally reasonable). I haven't been able to find much
>> discussion about this decision
>> on the mailing list nor in the spec commits.
>>
>> At first glance, it's true that at the beginning of the channel lifetime,
>> the funder should be
>> responsible for the fee (it's his decision to open a channel after all).
>> But as time goes by and
>> both peers earn value from this channel, this rule becomes questionable.
>> We've discovered since
>> then that there is some risk associated with having pending HTLCs
>> (flood-and-loot type of attacks,
>> pinning, channel jamming, etc).
>>
>> I think that *in some cases*, fundees should be paying a portion of the
>> commit-tx on-chain fees,
>> otherwise we may end up with a web-of-trust network where channels would
>> only exist between peers
>> that trust each other, which is quite limiting (I'm hoping we can do
>> better).
>>
>> Routing nodes may be at risk when they *receive* HTLCs. All the attacks
>> that steal funds come from
>> the fact that a routing node has paid downstream but cannot claim the
>> upstream HTLCs (correct me
>> if that's incorrect). Thus I'd like nodes to pay for the on-chain fees of
>> the HTLCs they offer
>> while they're pending in the commit-tx, regardless of whether they're
>> funder or fundee.
>>
>> The simplest way to do this would be to deduce the HTLC cost (172 *
>> feerate) from the offerer's
>> main output (instead of the funder's main output, while keeping the base
>> commit tx weight paid
>> by the funder).
>>
>> A more extreme proposal would be to tie the *total* commit-tx fee to the
>> channel usage:
>>
>> * if there are no pending HTLCs, the funder pays all the fee
>> * if there are pending HTLCs, each node pays a proportion of the fee
>> proportional to the number of
>> HTLCs they offered. If Alice offered 1 HTLC and Bob offered 3 HTLCs, Bob
>> pays 75% of the
>> commit-tx fee and Alice pays 25%. When the HTLCs settle, the fee is
>> redistributed.
>>
>> This model uses the on-chain fee as collateral for usage of the channel.
>> If Alice wants to forward
>> HTLCs through this channel (because she has something to gain - routing
>> fees), she should be taking
>> on some of the associated risk, not Bob. Bob will be taking the same risk
>> downstream if he chooses
>> to forward.
>>
>> I believe it also forces the fundee to care about on-chain feerates,
>> which is a healthy incentive.
>> It may create a feedback loop between on-chain feerates and routing fees,
>> which I believe is also
>> a good long-term thing (but it's hard to predict as there may be negative
>> side-effects as well).
>>
>> What do you all think? Is this a terrible idea? Is it okay-ish, but not
>> worth the additional
>> complexity? Is it an amazing idea worth a lightning nobel? Please don't
>> take any of my claims
>> for granted and challenge them, there may be negative side-effects I'm
>> completely missing, this is
>> a fragile game of incentives...
>>
>> Side-note: don't forget to take into account that the fees for HTLC
>> transactions (second-level txs)
>> are always paid by the party that broadcasts them (which makes sense). I
>> still think this is not
>> enough and can even be abused by fundees in some setups.
>>
>> Thanks,
>> Bastien
>> _______________________________________________
>> 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/20201008/45ed00b7/attachment.html>

2023-06-09 13:00:59

- reply

📅 Original date posted:2020-10-05
📝 Original message:
Hi darosior,
This is true, but we haven't solved yet how to estimate a good enough
`min_relay_fee` that works
for end-to-end tx propagation over the network.
We've discussed this during the last two spec meetings, but it's still
unclear whether we'll be able to solve
this before package-relay lands in bitcoin, so I wanted to explore this as
a potential more short-term
solution. But maybe it's not worth the effort and we should focus more on
anchors and `min_relay_fee`,
we'll see ;)
Bastien
Le lun. 5 oct. 2020 à 15:25, darosior <darosior at protonmail.com> a écrit :
> Hi Bastien,
>
>
> I think that *in some cases*, fundees should be paying a portion of the
> commit-tx on-chain fees,
> otherwise we may end up with a web-of-trust network where channels would
> only exist between peers
> that trust each other, which is quite limiting (I'm hoping we can do
> better).
>
>
> Agreed.
> However in an anchor outputs future the funder only pays for the
> "backbone" fees of the channel and the fees necessary to secure the
> confirmation of transactions is paid in second stage by each interested
> party (*). It seems to me to be a reasonable middle-ground.
>
> (*) Credits to ZmnSCPxj for pointing this out to me on IRC.
>
> Darosior
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201005/b987b4a9/attachment.html>

2023-06-09 13:00:59

- reply

📅 Original date posted:2020-10-05
📝 Original message:
Good morning list,
It seems to me that the "funder pays all the commit tx fees" rule exists
solely for simplicity
(which was totally reasonable). I haven't been able to find much discussion
about this decision
on the mailing list nor in the spec commits.
At first glance, it's true that at the beginning of the channel lifetime,
the funder should be
responsible for the fee (it's his decision to open a channel after all).
But as time goes by and
both peers earn value from this channel, this rule becomes questionable.
We've discovered since
then that there is some risk associated with having pending HTLCs
(flood-and-loot type of attacks,
pinning, channel jamming, etc).
I think that *in some cases*, fundees should be paying a portion of the
commit-tx on-chain fees,
otherwise we may end up with a web-of-trust network where channels would
only exist between peers
that trust each other, which is quite limiting (I'm hoping we can do
better).
Routing nodes may be at risk when they *receive* HTLCs. All the attacks
that steal funds come from
the fact that a routing node has paid downstream but cannot claim the
upstream HTLCs (correct me
if that's incorrect). Thus I'd like nodes to pay for the on-chain fees of
the HTLCs they offer
while they're pending in the commit-tx, regardless of whether they're
funder or fundee.
The simplest way to do this would be to deduce the HTLC cost (172 *
feerate) from the offerer's
main output (instead of the funder's main output, while keeping the base
commit tx weight paid
by the funder).
A more extreme proposal would be to tie the *total* commit-tx fee to the
channel usage:
* if there are no pending HTLCs, the funder pays all the fee
* if there are pending HTLCs, each node pays a proportion of the fee
proportional to the number of
HTLCs they offered. If Alice offered 1 HTLC and Bob offered 3 HTLCs, Bob
pays 75% of the
commit-tx fee and Alice pays 25%. When the HTLCs settle, the fee is
redistributed.
This model uses the on-chain fee as collateral for usage of the channel. If
Alice wants to forward
HTLCs through this channel (because she has something to gain - routing
fees), she should be taking
on some of the associated risk, not Bob. Bob will be taking the same risk
downstream if he chooses
to forward.
I believe it also forces the fundee to care about on-chain feerates, which
is a healthy incentive.
It may create a feedback loop between on-chain feerates and routing fees,
which I believe is also
a good long-term thing (but it's hard to predict as there may be negative
side-effects as well).
What do you all think? Is this a terrible idea? Is it okay-ish, but not
worth the additional
complexity? Is it an amazing idea worth a lightning nobel? Please don't
take any of my claims
for granted and challenge them, there may be negative side-effects I'm
completely missing, this is
a fragile game of incentives...
Side-note: don't forget to take into account that the fees for HTLC
transactions (second-level txs)
are always paid by the party that broadcasts them (which makes sense). I
still think this is not
enough and can even be abused by fundees in some setups.
Thanks,
Bastien
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201005/521584fe/attachment.html>

2023-06-09 13:00:58

- reply

📅 Original date posted:2020-10-12
📝 Original message:
Good morning,
For instance, Tor is basically two-layer: there is a lower-level TCP/IP
> layer where packets are sent out to specific nodes on the network and this
> layer is completely open about where the packet should go, but there is a
> higher layer where onion routing between nodes is used.
> We could imitate this, with HTLC packets that openly show the next
> destination node, but once all parts reach the destination node, it decodes
> and turns out to be an onion to be sent to the next destination node, and
> the current destination node is just another forwarder.
That's an interesting comment, it may be worth exploring.
IIUC you're suggesting that payments may look like this:
* Alice wants to reach Dave by going through Bob and Carol
* An onion encodes the route Alice -> Bob -> Carol -> Dave
* When Bob receives that onion and discovers that Carol is the next node,
he finds a route to Carol
and sends it along that route, but it's not an onion, it's "clear-text"
routing
* When Carol receives that message, she unwraps the Alice -> Bob -> Carol
-> Dave onion to discover
that Dave is the next hop and applies the same steps as Bob
It looks a lot like Trampoline, but Trampoline does onion routing between
intermediate nodes.
Your proposal would replace that with a potentially more efficient but less
private routing scheme.
As long as the Trampoline route does use onion routing, it could make
sense...
For your proposal, how sure is the receiver that the input end of the
> trampoline node is "nearer" to the payer than itself?
Invoices to the rescue!
Since lightning payments are invoice-based, recipients would add to the
invoice a few nodes that
are close to them (or a partial route, which would probably be better for
privacy).
Thanks,
Bastien
Le dim. 11 oct. 2020 à 10:50, ZmnSCPxj <ZmnSCPxj at protonmail.com> a écrit :
> Good morning t-bast,
>
> > Hey Zman,
> >
> > > raising the minimum payment size is another headache
> >
> > It's true that it may (depending on the algorithm) lower the success
> rate of MPP-split.
> > But it's already a parameter that node operators can configure at will
> (at channel creation time),
> > so IMO it's a complexity we have to deal with anyway. Making it dynamic
> shouldn't have a high
> > impact on MPP algorithms (apart from failures while `channel_update`s
> are propagating).
>
> Right, it should not have much impact.
>
> For the most part, when considering the possibility of splicing in the
> future, we should consider that such parameters must be made changeable
> largely.
>
>
> >
> > To be fully honest, my (maybe unpopular) opinion about MPP is that it's
> not necessary on the
> > network's backbone, only at its edges. Once the network matures, I
> expect channels between
> > "serious" routing nodes to be way bigger than the size of individual
> payments. The only places
> > where there may be small or almost-empty channels are between end-users
> (wallets) and
> > routing nodes.
> > If something like Trampoline were to be implemented, MPP would only be
> needed to reach a
> > first routing node (short route), that routing node would aggregate the
> parts and forward as a
> > single HTLC to the next routing node. It would be split again once it
> reaches the other edge
> > of the network (for a short route as well). In a network like this, the
> MPP routes would only have
> > to be computed on a small subset of the network, which makes brute-force
> algorithms completely
> > reasonable and the success rate higher.
>
> This makes me wonder if we really need the onions-per-channel model we
> currently use.
>
> For instance, Tor is basically two-layer: there is a lower-level TCP/IP
> layer where packets are sent out to specific nodes on the network and this
> layer is completely open about where the packet should go, but there is a
> higher layer where onion routing between nodes is used.
>
> We could imitate this, with HTLC packets that openly show the next
> destination node, but once all parts reach the destination node, it decodes
> and turns out to be an onion to be sent to the next destination node, and
> the current destination node is just another forwarder.
>
> HTLC packets could be split arbitrarily, and later nodes could potentially
> merge with the lower CLTV used in subsequent hops.
>
> Or not, *shrug*.
> It has the bad problem of being more expensive on average than purely
> source-based routing, and probably having worse payment latency.
>
>
> For your proposal, how sure is the receiver that the input end of the
> trampoline node is "nearer" to the payer than itself?
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201012/8dcb280a/attachment.html>

2023-06-09 13:00:58

- reply

📅 Original date posted:2020-10-14
📝 Original message:
Hey laolu,
I think this fits in nicely with the "parameter re-negotiation" portion of
> my
> loose Dynamic commitments proposal.
Yes, maybe it's better to not offer two mechanisms and wait for dynamic
commitments to offer that
flexibility.
Instead, you may
> want to only allow them to utilize say 10% of the available HTLC bandwidth,
> slowly increasing based on successful payments, and drastically
> (multiplicatively) decreasing when you encounter very long lived HTLCs, or
> an excessive number of failures.
Exactly, that's the kind of heuristic I had in mind. Peers need to slowly
build trust before you
give them access to more resources.
This is
> possible to some degree today (by using an implicit value lower than
> the negotiated values), but the implicit route doesn't give the other party
> any information
Agreed, it's easy to implement locally but it's not going to be very nice
to your peer, who has
no way of knowing why you're rejecting HTLCs and may end up closing the
channel because it sees
weird behavior. That's why we need to offer an explicit re-negotiation of
these parameters, let's
keep this use-case in mind when designing dynamic commitments!
Cheers,
Bastien
Le lun. 12 oct. 2020 à 20:59, Olaoluwa Osuntokun <laolu32 at gmail.com> a
écrit :
>
> > 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
> my
> loose Dynamic commitments proposal. Note that in that paradigm, something
> like this would be a distinct message, and also only be allowed with a
> "clean commitment" (as otherwise what if I reduce the number of slots to a
> value that is lower than the number of active slots?). With this, both
> sides
> would be able to propose/accept/deny updates to the flow control parameters
> that can be used to either increase the security of a channel, or implement
> a sort of "slow start" protocol for any new peers that connect to you.
>
> Similar to congestion window expansion/contraction in TCP, when a new peer
> connects to you, you likely don't want to allow them to be able to consume
> all the newly allocated bandwidth in an outgoing direction. Instead, you
> may
> want to only allow them to utilize say 10% of the available HTLC bandwidth,
> slowly increasing based on successful payments, and drastically
> (multiplicatively) decreasing when you encounter very long lived HTLCs, or
> an excessive number of failures.
>
> A dynamic HTLC bandwidth allocation mechanism would serve to mitigate
> several classes of attacks (supplementing any mitigations by "channel
> acceptor" hooks), and also give forwarding nodes more _control_ of exactly
> how their allocated bandwidth is utilized by all connected peers. This is
> possible to some degree today (by using an implicit value lower than
> the negotiated values), but the implicit route doesn't give the other party
> any information, and may end up in weird re-send loops (as they _why_ an
> HTLC was rejected) wasn't communicated. Also if you end up in a half-sign
> state, since we don't have any sort of "unadd", then the channel may end up
> borked if the violating party keeps retransmitting the same update upon
> reconnection.
>
> > Are there other fields you think would need to become dynamic as well?
>
> One other value that IMO should be dynamic to protect against future
> unexpected events is the dust limit. "It Is Known", that this value
> "doesn't
> really change", but we should be able to upgrade _all_ channels on the fly
> if it does for w/e reason.
>
> -- Laolu
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201014/87b3dc5d/attachment.html>

2023-06-09 13:00:57

- reply

📅 Original date posted:2020-10-09
📝 Original message:
Hey Zman,
raising the minimum payment size is another headache
>
It's true that it may (depending on the algorithm) lower the success rate
of MPP-split.
But it's already a parameter that node operators can configure at will (at
channel creation time),
so IMO it's a complexity we have to deal with anyway. Making it dynamic
shouldn't have a high
impact on MPP algorithms (apart from failures while `channel_update`s are
propagating).
To be fully honest, my (maybe unpopular) opinion about MPP is that it's not
necessary on the
network's backbone, only at its edges. Once the network matures, I expect
channels between
"serious" routing nodes to be way bigger than the size of individual
payments. The only places
where there may be small or almost-empty channels are between end-users
(wallets) and
routing nodes.
If something like Trampoline were to be implemented, MPP would only be
needed to reach a
first routing node (short route), that routing node would aggregate the
parts and forward as a
single HTLC to the next routing node. It would be split again once it
reaches the other edge
of the network (for a short route as well). In a network like this, the MPP
routes would only have
to be computed on a small subset of the network, which makes brute-force
algorithms completely
reasonable and the success rate higher.
This is an interesting fork of the discussion, but I don't think it's a
good reason to prevent these
parameters from being updated on live channels, what do you think?
Bastien
Le jeu. 8 oct. 2020 à 22:05, ZmnSCPxj <ZmnSCPxj at protonmail.com> a écrit :
> Good morning t-bast,
>
> > Please forget about channel jamming, upfront fees et al and simply
> consider the parameters I'm
> > mentioning. It feels to me that these are by nature dynamic channel
> parameters (some of them are
> > even present in `channel_update`, but no-one updates them yet because
> direct peers don't take the
> > update into account anyway). I'd like to raise `htlc_minimum_msat` on
> some big channels because
> > I'd like these channels to be used only for big-ish payments. Today I
> can't, I have to close that
> > channel and open a new one for such a trivial configuration update,
> which is sad.
>
> At the risk of once more derailing the conversation: from the MPP
> trenches, raising the minimum payment size is another headache.
> The general assumption with MPP is that smaller amounts are more likely to
> get through, but if anyone is making a significant bump up in
> `htlc_minimum_msat`, that assumption is upended and we have to reconsider
> if we may actually want to merge multiple failing splits into one, as well
> as considering asymmetric splits (in particular asymmetric presplits)
> because maybe the smaller splits will be unable to pass through the bigger
> channels but the bigger-side split *might*.
>
> On the other hand: one can consider that the use of big payments as an
> aggregation.
> For example: a forwarding node might support smaller `htlc_minimum_msat`,
> then after making multiple such forwards, find that a channel is now
> heavily balanced towards one side or another.
> It can then make a single large rebalance via one of the
> high-`htlc_minimum_msat` channels t-bast is running.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201009/cdca8cc5/attachment-0001.html>

2023-06-09 13:00:56

- reply

📅 Original date posted:2020-10-08
📝 Original message:
Good morning Antoine and Zman,
Thanks for your answers!
I was thinking dynamic policy adjustment would be covered by the dynamic
> commitment mechanism proposed by Laolu
I didn't mention this as I think we still have a long-ish way to go before
dynamic commitments
are spec-ed, implemented and deployed, and I think the parameters I'm
interested in don't require
that complexity to be updated.
Please forget about channel jamming, upfront fees et al and simply consider
the parameters I'm
mentioning. It feels to me that these are by nature dynamic channel
parameters (some of them are
even present in `channel_update`, but no-one updates them yet because
direct peers don't take the
update into account anyway). I'd like to raise `htlc_minimum_msat` on some
big channels because
I'd like these channels to be used only for big-ish payments. Today I
can't, I have to close that
channel and open a new one for such a trivial configuration update, which
is sad.
There is no need to stop the channel's operations while you're updating
these parameters, since
they can be updated unilaterally anyway. The only downside is that if you
make your policy stricter,
your peer may send you some HTLCs that you will immediately fail
afterwards; it's only a minor
inconvenience that won't trigger a channel closure.
I'd like to know if other implementations than eclair have specificities
that would make this
feature particularly hard to implement or undesirable.
Thanks,
Bastien
Le mar. 6 oct. 2020 à 18:43, ZmnSCPxj <ZmnSCPxj at protonmail.com> a écrit :
> Good morning Antoine, and Bastien,
>
>
> > Instead of relying on reputation, the other alternative is just to have
> an upfront payment system, where a relay node doesn't have to account for a
> HTLC issuer reputation to decide acceptance and can just forward a HTLC as
> long it paid enough. More, I think it's better to mitigate jamming with a
> fees-based system than a web-of-trust one, less burden on network newcomers.
>
> Let us consider some of the complications here.
>
> A newcomer wants to make an outgoing payment.
> Speculatively, it connects to some existing nodes based on some policy.
>
> Now, since forwarding is upfront, the newcomer fears that the node it
> connected to might not even bother forwarding the payment, and instead just
> fail it and claim the upfront fees.
>
> In particular: how would the newcomer offer upfront fees to a node it is
> not directly channeled with?
> In order to do that, we would have to offer the upfront fees for that
> node, to the node we *are* channeled with, so it can forward this as well.
>
> * We can give the upfront fee outright to the first hop, and trust that if
> it forwards, it will also forward the upfront fee for the next hop.
> * The first hop would then prefer to just fail the HTLC then and there
> and steal all the upfront fees.
> * After all, the offerrer is a newcomer, and might be the sybil of a
> hacker that is trying to tie up its liquidity.
> The first hop would (1) avoid this risk and (2) earn more upfront
> fees because it does not forward those fees to later hops.
> * This is arguably custodial and not your keys not your coins applies.
> Thus, it returns us back to tr\*st anyway.
> * We can require that the first hop prove *where* along the route errored.
> If it provably failed at a later hop, then the first hop can claim more
> as upfront fees, since it will forward the upfront fees to the later hop as
> well.
> * This has to be enforcable onchain in case the channel gets dropped
> onchain.
> Is there a proposal SCRIPT which can enforce this?
> * If not enforcable onchain, then there may be onchain shenanigans
> possible and thus this solution might introduce an attack vector even as it
> fixes another.
> * On the other hand, sub-satoshi amounts are not enforcable onchain
> too, and nobody cares, so...
>
> On the other hand, a web-of-tr\*st might not be *that* bad.
>
> One can say that "tr\*st is risk", and consider that the size and age of a
> channel to a peer represents your tr\*st that that peer will behave
> correctly for fast and timely resolution of payments.
> And anyone can look at the blockchain and the network gossip to get an
> idea of who is generally considered tr\*stworthy, and since that
> information is backed by Bitcoins locked in channels, this is reasonably
> hard to fake.
>
> On the other hand, this risks centralization around existing, long-lived
> nodes.
> *Sigh*.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201008/22e78ab2/attachment-0001.html>

2023-06-09 13:00:55

- reply

📅 Original date posted:2020-10-05
📝 Original message:
Good evening list,
Recent discussions around channel jamming [1] have highlighted again the
need to think twice when
configuring your channels parameters. There are currently parameters that
are set once at channel
creation that would benefit a lot from being configurable throughout the
lifetime of the channel
to avoid closing channels when we just want to reconfigure them:
* max_htlc_value_in_flight_msat
* max_accepted_htlcs
* htlc_minimum_msat
* htlc_maximum_msat
Nodes can currently unilaterally udpate these by applying forwarding
heuristics, but it would be
better to tell our peer about the limits we want to put in place (otherwise
we're wasting a whole
cycle of add/commit/revoke/fail messages for no good reason).
I suggest adding tlv records in `commitment_signed` to tell our channel
peer that we're changing
the values of these fields.
Is someone opposed to that?
Are there other fields you think would need to become dynamic as well?
Do you think that needs a new message instead of using extensions of
`commitment_signed`?
Cheers,
Bastien
[1] https://twitter.com/joostjgr/status/1308414364911841281
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201005/f98befeb/attachment.html>

2023-06-09 13:00:37

- reply

📅 Original date posted:2020-07-21
📝 Original message:
Thanks for sharing this, I think it's the right time to start experimenting
with
that kind of feature (especially in the light of Taproot and the package
relay
work / pinning transactions issue).
we can start to experiment with flow-control like
> ideas such as limiting a new channel peer to only a handful of HTLC slots,
> which is then progressively increased based on "good behavior" (or the
> other
> way around as well)
Note that this is already possible today, a node can unilaterally decide its
internal rules for accepting channels/HTLCs. But it's true that it would be
nicer to communicate these rules with your peer to reduce inefficiencies
(e.g. proposing HTLCs that we know will be rejected).
* `open_channel` and `accept_channel` gain a new `channel_type` TLV field.
> * retroactively the OG commitment format is numbered as `channel_type=0`,
> `static_remote_key`, as `channel_type=1`, and anchors as
> `channel_type=2`
ACK! Internally eclair (and I believe lnd as well) has exactly that field in
its DB, with exactly those values.
* an empty `commit_sig` message (one that covers no updates) is
> disallowed, unless the `commit_sig` has a `channel_type`, `c_n` that
> differs from the channel type of the prior commitment, `c_n-1`.
That sounds reasonable, as changing the `channel_type` is actually an update
(it results in changes in the commit tx and/or htlc txs).
An alternative to attaching the `channel_type` message to the `commit_sig`
> and having _that_ kick off the commitment upgrade, we could instead
> possibly
> add a _new_ update message (like `update_fee`) to make the process more
> explicit. In either case, we may want to restrict things a bit by only
> allowing the initiator to trigger a commitment format update.
I prefer that alternative. I think it's better to explicitly signal that we
want to pause the channel while we upgrade the commitment format (and stop
accepting HTLCs while we're updating, like we do once we've exchanged the
`shutdown` message). Otherwise the asynchronocity of the protocol is likely
to
create months (years?) of tracking unwanted force-closes because of races
between `commig_sig`s with the new and old commitment format.
Updating the commitment format should be a rare enough operation that we can
afford to synchronize with a two-way `update_commitment_format` handshake,
then
temporarily freeze the channel.
The tricky part will be how we handle "dangling" operations that were sent
by
the remote peer *after* we sent our `update_commitment_format` but *before*
they received it. The simplest choice is probably to have the initiator just
ignore these messages, and the non-initiator enqueue these un-acked messages
and replay them after the commitment format update completes (or just drop
them
and cancel corresponding upstream HTLCs if needed).
Regarding initiating the commitment format update, how do you see this
happen?
The funder activates a new feature on his (e.g. `option_anchor_outputs`),
and
broadcasts it in `init` and `node_announcement`, then waits until the remote
also activates it in its `init` message and then reacts to this by
triggering
the update process?
Thanks,
Bastien
Le mar. 21 juil. 2020 à 03:18, Olaoluwa Osuntokun <laolu32 at gmail.com> a
écrit :
> Hi y'all,
>
> 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
> de-synchronized and distributed manner. The core realization these proposal
> is based on the fact that the funding output is the _only_ component of a
> channel that's actually set in stone (requires an on-chain transaction to
> modify).
>
>
> # Motivation
>
> (you can skip this section if you already know why something like this is
> important)
>
> First, some motivation. As y'all are likely aware, the current deployed
> commitment format has changed once so far: to introduce the
> `static_remote_key` variant which makes channels safer by sending the funds
> of the party that was force closed on to a plain pubkey w/o any extra
> tweaks
> or derivation. This makes channel recovery safer, as the party that may
> have
> lost data (or can't continue the channel), no longer needs to learn of a
> secret value sent to them by the other party to be able to claim their
> funds. However, as this new format was introduced sometime after the
> initial
> bootstrapping phase of the network, most channels in the wild today _are
> not_ using this safer format. Transitioning _all_ the existing channels to
> this new format as is, would require closing them _all_, generating tens of
> thousands of on-chain transactions (to close, then re-open), not to mention
> chain fees.
>
> With dynamic commitments, users will be able to upgrade their _existing_
> channels to new safer types, without any new on-chain transactions!
>
> Anchor output based commitments represent another step forward in making
> channels safer as they allow users/software to no longer have to predict
> chain fees ahead of time, and also bump up the fee of a
> commitment/2nd-level-htlc-transaction, which is extremely important when it
> comes to timely on-chain resolution of HTLC contracts. This upgrade process
> (as touched on below) can either be manually triggered, or automatically
> triggered once the software updates and finds a new preferable default
> commitment format is available.
>
> As many of us are aware, the addition of schnorr and taproot to the Bitcoin
> protocol dramatically increases the design space for channels as a whole.
> It
> may take some time to explore this design space, particularly as entirely
> new channel/commitment formats [1] continue to be discovered. The roll out
> of dynamic commitments allows us to defer the concrete design of the future
> commitment formats, yet still benefit from the immediate improvement that
> comes with morphing the funding output to be a single-key (non-p2wsh,
> though
> the line starts to blur w/ taproot) output. With this new funding output
> format in place, users/software will then be able to update to the latest
> and greatest commitment format that starts to utilize all the new tools
> available (scriptless script based htlcs, etc) at a later date.
>
> Finally, the ability to update the commitment format itself will also allow
> us to re-parametrize portions of the channels which are currently set in
> stone. As an example, right now the # of max allowed outstanding HTLCs is
> set in stone once the channel has opened. With the ability to also swap out
> commitment _parameters_, we can start to experiment with flow-control like
> ideas such as limiting a new channel peer to only a handful of HTLC slots,
> which is then progressively increased based on "good behavior" (or the
> other
> way around as well). Beyond just updating the channel parameters, it's also
> possible to "change the rules" of a channel on the fly. An example of this
> variant would be creating a new psuedo-type that implements a fee policy
> other than "the initiator pays all fees".
>
>
> # Protocol Changes
>
> With the motivation/background set up, let's dig into some potential ways
> the protocol can be modified to support this new meta-feature. As this
> change is more of a meta-change, AFAICT, the amount of protocol changes
> doesn't appear to be _too_ invasive ;). Most of the heavy lifting is done
> by
> the wondrous TLV message field extensions.
>
> ## Explicit Channel Type Negotiation
>
> Right now in the protocol, as new channel types are introduced (static key,
> and now anchors) we add a new feature bit. If both nodes have the feature
> bit set, then that new channel type is to be used. Notice how this is an
> _implicit_ upgrade: there's no explicit signalling during the _funding_
> process that a new channel type is to be used. This works OK, if there's
> one
> major accepted "official" channel type, but not as new types are introduced
> for specific use cases or applications. The implicit negotiation also makes
> things a bit ambiguous at times. As an example, if both nodes have the
> `static_remote_key` _and_ anchor outputs feature bit set, which channel
> type
> should they open?
>
> To resolve this existing ambiguity in the channel type negotiation, we'll
> need to make the channel type used for funding _explicit_. Thankfully, we
> recently modified the message format to be forwarding looking in order to
> allow _TLV extensions_ to be added for all existing message types. A new
> `channel_type` (type #???) TLV would be added which makes the channel type
> used in funding explicit, with the existing feature bit advertisement
> system
> being kept in place.
>
> A draft of the changes in this area would be something like:
>
> * `open_channel` and `accept_channel` gain a new `channel_type` TLV
> field.
> * retroactively the OG commitment format is numbered as `channel_type=0`,
> `static_remote_key`, as `channel_type=1`, and anchors as
> `channel_type=2`
> * if one receives an `open_channel`, or `accept_channel` message with an
> unknown `channel_type`, they're to fail the funding flow
> * nodes MUST NOT send an `open_channel` or `accept_channel` message with
> a
> `channel_type` that isn't covered by their existing advertise feature
> bits
> * a mapping between feature bits and expected `channel_type` values would
> then be added
> * during funding negotiation, the _commitment_ type itself is
> parametrized
> based on the `channel_type` value
> * as we've all implemented `static_remote_key` commitments at this
> point, I assume the necessary code-level abstractions are already
> in-place
>
> ## Commitment State Machine Changes
>
> With the changes described in the above section, we're now able to
> explicitly identify _which_ channel type we want to enter a funding flow
> for. As we add more types, there may not be a "default" type, so making
> this
> process explicit is important to future exploration and extensibility. In
> this section, we'll introduce a series of small changes to the
> `commit_sig`,
> and `revoke_and_ack` messages which'll allow us to implement the "dynamic"
> portion of this proposal.
>
> Relying once again on the wondrous power of TLV message extensions we'll
> carry over the `channel_type` TLV (just the name, # may be diff since this
> is a diff message context) to the `commit_sig`, and `revoke_and_ack`
> messages. The following guidelines on inclusion and interpretation would
> then be applied:
>
> * the `channel_type` specified on a given `commit_sig` message should be
> the `channel_type` of the _new_ commitment being _created_
> * when receiving a `commit_sig` with a `channel_type` that differs from
> the `channel_type` of one's on revoked commitment:
> * if the `channel_type` is unknown (or the `channel_type` transition
> isn't allowed or defined), then the _p2p_ connection should be
> aborted
> * otherwise, using the `channel_type` as a parameter for commitment
> transaction construction, a new commitment adhering to the rules of
> the `channel_type` should be constructed
> * the `channel_type` sent in the `revoke_and_ack` message should be the
> `channel_type` of the commitment that's being _revoked_
>
> With the above new rules, let's say Alice and Bob upgrade to new versions
> of
> their LN software that support a new channel type `1`, while they're on
> channel type `0`. Either triggered automatically, or manually (by either
> side), the commitment flow would look something like:
>
> 1. sig_c_1 ->
> 2. <- revoke_c_0
> 3. <- sig_c_1
> 4. revoke_c_0 ->
>
> By exchanging 4 messages, both sides are able to upgrade to a new
> commitment
> format. However, one issue with the above flow is that it currently isn't
> allowed by the spec, since we disallow sending a `commit_sig` message that
> doesn't cover any updates. If we end up going with this route, then we'd
> have to relax that constraint to something like:
>
> * an empty `commit_sig` message (one that covers no updates) is
> disallowed, unless the `commit_sig` has a `channel_type`, `c_n` that
> differs from the channel type of the prior commitment, `c_n-1`.
>
> It would then be up to _new protocol extension documents_ to define _how_
> to
> construct those new channel types, and also any changes to the on-chain
> handling that are required by those channel types. Also certain transitions
> may be disallowed. As an example, implementations may want to prevent a
> user
> from going back to the non-static remote key channels from the
> `static_remote_key` format.
>
> In order to prepare for these changes, implementations need to be able to
> handle "holding" unrevoked commitments of heterogeneous types, as if either
> of them hit the chain, they'll need to be able to resolve all contracts
> properly.
>
> An alternative to attaching the `channel_type` message to the `commit_sig`
> and having _that_ kick off the commitment upgrade, we could instead
> possibly
> add a _new_ update message (like `update_fee`) to make the process more
> explicit. In either case, we may want to restrict things a bit by only
> allowing the initiator to trigger a commitment format update.
>
> ## Further Channel Type Parameterization
>
> With the above protocol sketch, we're able to handle "simple" upgrades,
> where some/all of the parameters of the channel are hard coded and/or have
> been negotiated out of band. More complex channel types may require the
> exchange of additional keys or parameters which need to be known in order
> to
> reconstruct the _new_ commitment format and verify the new signature. This
> additional information can possibly be piggy-backed on the `commit_sig`
> message in the form of a _nested TLV_ type:
>
> * a msg-local TLV type `channel_params` is added
> * the value of this TLV type is a nested TLV blob, that contains all the
> necessary fields and values needed to properly handle the channel
> switch
> over
>
> Returning to the flow control example earlier in this post, the new limits
> for `max_allowed_htlcs`, can be included in this blob. More complex channel
> types could send information such as new keys to be used, or other
> parameters
> that govern how a commitment is to be constructed (like the size of the
> anchor outputs).
>
> # Conclusion
>
> Summarizing, in this post we've proposed a series of protocol modifications
> (with TLV fields doing most of the heavy lifting) that allows LN nodes to
> upgrade their commitments _without any on-chain_ transactions. Depending on
> the architecture of a node, new types may even be added/removed without
> actual downtime.
>
> The ability to upgrade commitments after the fact lessens the pressure of
> newer possibly experimental channel types to get all the details (and
> explore the rather large design space) correct up front. Once Taproot rolls
> around, we can simply update the funding output, roll that out, then
> continue to hash out the details on the possibly new channel type(s) that
> take advantage of all the new tools.
>
> Allowing channel types to be upgraded on the fly let's us update the
> network
> to the new _safer_ channel types in a de-synchronized, distributed manner
> that doesn't require any on-chain transactions! Dynamic commitments as a
> whole also creates another point of extensibility in the protocol so we can
> start to explore all the variants on channels as we know them that exist.
>
> I'm keen to gather feedback, as internally for `lnd` we've committed to
> exploring this direction so we can start to upgrade _all_ the existing
> lnd-involved channels to the new anchor commitment format, which is the
> safest format yet.
>
> [1]: https://eprint.iacr.org/2020/476
>
> -- Laolu
> _______________________________________________
> 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/20200721/9afe2378/attachment-0001.html>

2023-06-09 13:00:32

- reply

📅 Original date posted:2020-06-22
📝 Original message:
Hey ZmnSCPxj,
I agree that in theory this looks possible, but doing it in practice with
accurate control
of what parts of the network get what tx feels impractical to me (but maybe
I'm wrong!).
It feels to me that an attacker who would be able to do this would break
*any* off-chain
construction that relies on absolute timeouts, so I'm hoping this is
insanely hard to
achieve without cooperation from a miners subset. Let me know if I'm too
optimistic on
this!
Cheers,
Bastien
Le lun. 22 juin 2020 à 10:15, ZmnSCPxj <ZmnSCPxj at protonmail.com> a écrit :
> Good morning Bastien,
>
> > Thanks for the detailed write-up on how it affects incentives and
> centralization,
> > these are good points. I need to spend more time thinking about them.
> >
> > > This is one reason I suggested using independent pay-to-preimage
> > > transactions[1]
> >
> > While this works as a technical solution, I think it has some incentives
> issues too.
> > In this attack, I believe the miners that hide the preimage tx in their
> mempool have
> > to be accomplice with the attacker, otherwise they would share that tx
> with some of
> > their peers, and some non-miner nodes would get that preimage tx and be
> able to
> > gossip them off-chain (and even relay them to other mempools).
>
> I believe this is technically possible with current mempool rules, without
> miners cooperating with the attacker.
>
> Basically, the attacker releases two transactions with near-equal fees, so
> that neither can RBF the other.
> It releases the preimage tx near miners, and the timelock tx near
> non-miners.
>
> Nodes at the boundaries between those that receive the preimage tx and the
> timelock tx will receive both.
> However, they will receive one or the other first.
> Which one they receive first will be what they keep, and they will reject
> the other (and *not* propagate the other), because the difference in fees
> is not enough to get past the RBF rules (which requires not just a feerate
> increase, but also an increase in absolute fee, of at least the minimum
> relay feerate times transaction size).
>
> Because they reject the other tx, they do not propagate the other tx, so
> the boundary between the two txes is inviolate, neither can get past that
> boundary, this occurs even if everyone is running 100% unmodified Bitcoin
> Core code.
>
> I am not a mempool expert and my understanding may be incorrect.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200622/67840048/attachment.html>

2023-06-09 13:00:31

- reply

📅 Original date posted:2020-06-22
📝 Original message:
Thanks for the detailed write-up on how it affects incentives and
centralization,
these are good points. I need to spend more time thinking about them.
This is one reason I suggested using independent pay-to-preimage
> transactions[1]
>
While this works as a technical solution, I think it has some incentives
issues too.
In this attack, I believe the miners that hide the preimage tx in their
mempool have
to be accomplice with the attacker, otherwise they would share that tx with
some of
their peers, and some non-miner nodes would get that preimage tx and be
able to
gossip them off-chain (and even relay them to other mempools).
If they are actively helping the attacker, they wouldn't spend the
pay-to-preimage tx,
unless they gain more from it than the share the attacker gives them. This
becomes
a simple bidding war, and the honest user will always be the losing party
here (the
attacker has nothing to lose). For this reason I'm afraid it wouldn't work
out in practice
as well as we'd hope...what do you think? And even if the honest user wins
the bidding
war, the attack still steals money from that user; it just goes into the
miner's pocket.
But from the perspective of a single LN node, it
> might make more sense to get the information and *not* share it
>
I think it depends. If this attack becomes doable in practice and we see it
happening,
LN routing nodes and service providers have a very high incentive to thwart
these attacks,
because otherwise they'd lose their business as people would leave the
lightning network.
As long as enough nodes think that way (with "enough" being a very hard to
define quantity),
this should mitigate the attack. The only risk would be a big "exit scam"
scenario, but the
coordination cost between all these nodes makes that scenario unlikely
(IMHO).
Thanks,
Bastien
Le sam. 20 juin 2020 à 12:37, David A. Harding <dave at dtrt.org> a écrit :
> On Sat, Jun 20, 2020 at 10:54:03AM +0200, Bastien TEINTURIER wrote:
> > We're simply missing information, so it looks like the only good
> > solution is to avoid being in that situation by having a foot in
> > miners' mempools.
>
> The problem I have with that approach is that the incentive is to
> connect to the highest hashrate pools and ignore the long tail of
> smaller pools and solo miners. If miners realize people are doing this,
> they may begin to charge for information about their mempool and the
> largest miners will likely be able to charge more money per hashrate
> than smaller miners, creating a centralization force by increasing
> existing economies of scale.
>
> Worse, information about a node's mempool is partly trusted. A node can
> easily prove what transactions it has, but it can't prove that it
> doesn't have a certain transaction. This implies incumbent pools with a
> long record of trustworthy behavior may be able to charge more per
> hashrate than a newer pools, creating a reputation-based centralizing
> force that pushes individual miners towards well-established pools.
>
> This is one reason I suggested using independent pay-to-preimage
> transactions[1]. Anyone who knows the preimage can mine the
> transaction, so it doesn't provide reputational advantage or direct
> economies of scale---pay-to-preimage is incentive equivalent to paying
> normal onchain transaction fees. There is an indirect economy of
> scale---attackers are most likely to send the low-feerate
> preimage-containing transaction to just the largest pools, so small
> miners are unlikely to learn the preimage and thus unlikely to be able
> to claim the payment. However, if the defense is effective, the attack
> should rarely happen and so this should not have a significant effect on
> mining profitability---unlike monitoring miner mempools which would have
> to be done continuously and forever.
>
> ZmnSCPxj noted that pay-to-preimage doesn't work with PTLCs.[2] I was
> hoping one of Bitcoin's several inventive cryptographers would come
> along and describe how someone with an adaptor signature could use that
> information to create a pubkey that could be put into a transaction with
> a second output that OP_RETURN included the serialized adaptor
> signature. The pubkey would be designed to be spendable by anyone with
> the final signature in a way that revealed the hidden value to the
> pubkey's creator, allowing them to resolve the PTLC. But if that's
> fundamentally not possible, I think we could advocate for making
> pay-to-revealed-adaptor-signature possible using something like
> OP_CHECKSIGFROMSTACK.[3]
>
> [1]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002664.html
> [2]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002667.html
> [3] https://bitcoinops.org/en/topics/op_checksigfromstack/
>
> > Do you think it's unreasonable to expect at least some LN nodes to
> > also invest in running nodes in mining pools, ensuring that they learn
> > about attackers' txs and can potentially share discovered preimages
> > with the network off-chain (by gossiping preimages found in the
> > mempool over LN)?
>
> Ignoring my concerns about mining centralization and from the
> perspective of just the Lightning Network, that doesn't sound
> unreasonable to me. But from the perspective of a single LN node, it
> might make more sense to get the information and *not* share it,
> increasing your security and allowing you to charge lower routing fees
> compared to your competitors. This effect would only be enhanced if
> miners charged for their mempool contents (indeed, to maximize their
> revenue, miners might require that their mempool subscribers don't share
> the information---which they could trivially enforce by occasionally
> sending subscribers a preimage specific to the subscriber and seeing if
> it propagated to the public network).
>
> > I think that these recent attacks show that we need (at least some)
> > off-chain nodes to be somewhat heavily invested in on-chain operations
> > (layers can't be fully decoupled with the current security assumptions
> > - maybe Eltoo will help change that in the future?).
>
> I don't see how eltoo helps. Eltoo helps ensure you reach the final
> channel state, but this problem involves an abuse of that final state.
>
> -Dave
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200622/09e39b02/attachment-0001.html>

2023-06-09 13:00:30

- reply

📅 Original date posted:2020-06-20
📝 Original message:
Hello Dave and list,
Thanks for your quick answers!
The attacker would be broadcasting the latest
> state, so the honest counterparty would only need to send one blind
> child.
>
Exactly, if the attacker submits an outdated transaction he would be
shooting himself in the foot,
as we could claim the revocation paths when seeing the transaction in a
block and get all the
channel funds (since the attacker's outputs will be CSV-locked).
The only way your Bitcoin peer will relay your blind child
> is if it already has the parent transaction.
>
That's an excellent point that I missed in the blind CPFP carve-out trick!
I think this makes the
blind CPFP carve-out quite hard in practice (even using getdata - thanks
for detailing that option)...
In the worst case scenario where most miners' mempools contain the
attacker's tx and the rest of
the network's mempools contains the honest participant's tx, I think there
isn't much we can do.
We're simply missing information, so it looks like the only good solution
is to avoid being in that
situation by having a foot in miners' mempools. Do you think it's
unreasonable to expect at least
some LN nodes to also invest in running nodes in mining pools, ensuring
that they learn about
attackers' txs and can potentially share discovered preimages with the
network off-chain (by
gossiping preimages found in the mempool over LN)? I think that these
recent attacks show that
we need (at least some) off-chain nodes to be somewhat heavily invested in
on-chain operations
(layers can't be fully decoupled with the current security assumptions -
maybe Eltoo will help
change that in the future?).
Thank you for your time!
Bastien
Le ven. 19 juin 2020 à 22:53, David A. Harding <dave at dtrt.org> a écrit :
> On Fri, Jun 19, 2020 at 03:58:46PM -0400, David A. Harding via bitcoin-dev
> wrote:
> > I think you're assuming here that the attacker broadcast a particular
> > state.
>
> Whoops, I managed to confuse myself despite looking at Bastien's
> excellent explainer. The attacker would be broadcasting the latest
> state, so the honest counterparty would only need to send one blind
> child. However, the blind child will only be relayed by a Bitcoin peer
> if the peer also has the parent transaction (the latest state) and, if
> it has the parent transaction, you should be able to just getdata('tx',
> $txid) that transaction from the peer without CPFPing anything. That
> will give you the preimage and so you can immediately resolve the HTLC
> with the upstream channel.
>
> Revising my conclusion from the previous post:
>
> I think the strongman argument for the attack would be that the attacker
> will be able to perform a targeted relay of the low-feerate
> preimage-containing transaction to just miners---everyone else on the
> network will receive the honest user's higher-feerate expired-timelock
> transaction. Unless the honest user happens to have a connection to a
> miner's node, the user will neither be able to CPFP fee bump nor use
> getdata to retrieve the preimage.
>
> Sorry for the confusion.
>
> -Dave
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200620/6caf18ec/attachment.html>

2023-06-09 13:00:29

- reply

📅 Original date posted:2020-06-19
📝 Original message:
Good morning list,
Sorry for being (very) late to the party on that subject, but better late
than never.
A lot of ideas have been thrown at the problem and are scattered across
emails, IRC discussions,
and github issues. I've spent some time putting it all together in one
gist, hoping that it will
help stir the discussion forward as well as give newcomers all the
background they need to ramp up
on this issue and join the discussion, bringing new ideas to the table.
The gist is here, and I'd appreciate your feedback if I have wrongly
interpreted some of the ideas:
https://gist.github.com/t-bast/22320336e0816ca5578fdca4ad824d12
Readers of this list can probably directly skip to the "Future work"
section. I believe my
"alternative proposal" should loosely reflect Matt's proposal from the very
first mail of this
thread; note that I included anchors and new txs only in some places, as I
think they aren't
necessary everywhere.
My current state-of-mind (subject to change as I discover more potential
attacks) is that:
* The proposal to add more anchors and pre-signed txs adds non-negligible
complexity and hurts
small HTLCs, so it would be better if we didn't need it
* The blind CPFP carve-out trick is a one shot, so you'll likely need to
pay a lot of fees for it
to work which still makes you lose money in case an attacker targets you
(but the money goes to
miners, not to the attacker - unless he is the miner). It's potentially
hard to estimate what fee
you should put into that blind CPFP carve-out because you have no idea what
the current fee of the
pinned success transaction package is, so it's unsure if that solution will
really work in practice
* If we take a step back, the only attack we need to protect against is an
attacker pinning a
preimage transaction while preventing us from learning that preimage for at
least `N` blocks
(see the gist for the complete explanation). Please correct me if that
claim is incorrect as it
will invalidate my conclusion! Thus if we have:
* a high enough `cltv_expiry_delta`
* [off-chain preimage broadcast](
https://github.com/lightningnetwork/lightning-rfc/issues/783)
(or David's proposal to do it by sending txs that can be redeemed via only
the preimage)
* LN hubs (or any party commercially investing in running a lightning node)
participating in
various mining pools to help discover preimages
* decent mitigations for eclipse attacks
* then the official anchor outputs proposal should be safe enough and is
much simpler?
Thank you for reading, I hope the work I put into this gist will be useful
for some of you.
Bastien
Le ven. 24 avr. 2020 à 00:47, Matt Corallo via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> a écrit :
>
>
> On 4/23/20 8:46 AM, ZmnSCPxj wrote:
> >>> - Miners, being economically rational, accept this proposal and
> include this in a block.
> >>>
> >>> The proposal by Matt is then:
> >>>
> >>> - The hashlock branch should instead be:
> >>> - B and C must agree, and show the preimage of some hash H (hashlock
> branch).
> >>> - Then B and C agree that B provides a signature spending the
> hashlock branch, to a transaction with the outputs:
> >>> - Normal payment to C.
> >>> - Hook output to B, which B can use to CPFP this transaction.
> >>> - Hook output to C, which C can use to CPFP this transaction.
> >>> - B can still (somehow) not maintain a mempool, by:
> >>> - B broadcasts its timelock transaction.
> >>> - B tries to CPFP the above hashlock transaction.
> >>> - If CPFP succeeds, it means the above hashlock transaction exists
> and B queries the peer for this transaction, extracting the preimage and
> claiming the A->B HTLC.
> >>
> >> Note that no query is required. The problem has been solved and the
> preimage-containing transaction should now confirm just fine.
> >
> > Ah, right, so it gets confirmed and the `blocksonly` B sees it in a
> block.
> >
> > Even if C hooks a tree of low-fee transactions on its hook output or
> normal payment, miners will still be willing to confirm this and the B hook
> CPFP transaction without, right?
>
> Correct, once it makes it into the mempool we can CPFP it and all the
> regular sub-package CPFP calculation will pick it
> and its descendants up. Of course this relies on it not spending any other
> unconfirmed inputs.
> _______________________________________________
> 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/lightning-dev/attachments/20200619/70e88f70/attachment.html>

2023-06-09 12:59:43

- reply

📅 Original date posted:2020-04-22
📝 Original message:
Hi Antoine and list,
Thanks for raising this. There's one step I'd like to understand further:
* Mallory can broadcast its Pinning Preimage Tx on offered HTLC #2 output
> on Alice's transaction,
> feerate is maliciously chosen to get in network mempools but never to
> confirm. Absolute fee must
> be higher than HTLC-timeout #2, a fact known to Mallory. There is no p2p
> race.
>
Can you detail how the "absolute fee" is computed here?
Doesn't that mean that if this had a higher fee than the htlc-timeout, and
the htlc-timeout fee was
chosen to confirm quickly (that's why we have an annoying `update_fee`),
the htlc-success will confirm
quickly (which makes the problem disappear)?
Because once the commit tx is confirmed, the "package" consists of only the
htlc-success, doesn't it?
I think the devil will be in the details here, so it's worth expanding on
the fee calculation imho.
Thanks!
Bastien
Le mer. 22 avr. 2020 à 10:01, Antoine Riard <antoine.riard at gmail.com> a
écrit :
> Personally, I would have wait a bit before to go public on this, like
> letting some implementations
> increasing their CLTV deltas, but anyway, it's here now.
>
> Mempool-pinning attacks were already discussed on this list [0], but what
> we found is you
> can _reverse_ the scenario, where it's not the malicious party delaying
> confirmation of honest
> party transactions but malicious deliberately stucking its own
> transactions in the mempool to avoid
> confirmation of timeout. And therefore gaming inter-link timelock to
> provoke an unbalanced
> settlement for the victim ("aka you pay forward, but don't get pay
> backward").
>
> How much attacks are practical is based on how you can leverage mempool
> rules to pin your own
> transaction. What you're looking for is a _mempool-obstruction_ trick,
> i.e a way to get honest party
> transaction being bounce off due to your transaction being already there.
>
> Beyond disabling RBF on your transaction (with current protocol, not
> anchor proposal), there is
> two likely candidates:
> * BIP 125 rule 3: "The replacement transaction pays an absolute fee of at
> least the sum paid by the original transactions."
> * BIP 125 rule 5: "The number of original transactions to be replaced and
> their descendant transactions which will be evicted from the mempool must
> not exceed a total of 100 transactions."
>
> Let's go through whole scenario:
> * Mallory and Eve are colluding
> * Eve and Mallory are opening channels with Alice, Mallory do a bit of
> rebalancing
> to get full incoming capacity, like receiving funds on an onchain address
> through another Alice
> link
> * Eve send a HTLC #1 to Mallory through Alice expirying at block 100
> * Eve send a second HTLC #2 to Mallory through Alice, expirying at block
> 110 on outgoing link
> (A<->M), 120 on incoming link (E<->A)
> * Before block 100, without cancellation from Mallory, Alice will
> force-close channel and broadcast
> her local commitment and HTLC-timeout to get back HTLC #1
> * Alice can't broadcast HTLC-timeout for HTLC #2 as it's only expires at
> 110
> * Mallory can broadcast its Pinning Preimage Tx on offered HTLC #2 output
> on Alice's transaction,
> feerate is maliciously chosen to get in network mempools but never to
> confirm. Absolute fee must
> be higher than HTLC-timeout #2, a fact known to Mallory. There is no p2p
> race.
> * As Alice doesn't watch the mempool, she is never going to learn the
> preimage to redeeem incoming
> HTLC #2
> * At block 110, Alice is going to broadcast HTLC-timeout #2, feerate may
> be higher but as absolute
> fee is lower, it's going to be rejected from network mempools as
> replacement for Pinning Preimage
> Tx (BIP 125 rule 3)
> * At block 120, Eve closes channel and HTLC-timeout HTLC #2
> * Mallory can RBF its Pinning Preimage Tx by a high-feerate one and get it
> confirmed
>
> New anchor_output proposal, by disabling RBF, forces attacker to bid on
> the absolute fee. It may
> be now a risk to loose the fee if Pinning Tx is confirming. You may extend
> your "pinning
> lease" by ejecting your malicious tx, like conflicting or trimming out of
> the mempool one of its
> parents. And then reannounce your preimage tx with a
> lower-feerate-but-still-high-fee before a
> new block and a honest HTLC-timeout rebroadcast.
>
> AFAICT, even with anchor_output deployed, even assuming empty mempools,
> success rate and economic
> rationality of attacks is finding such cheap, reliable "pinning lease
> extension" trick.
>
> I think any mempool watching mitigation is at best a cat-and-mouse hack.
> Contrary to node
> advancing towards a global blockchain view thanks to PoW, network mempools
> don't have a convergence
> guarantee. This means, in a distributed system like bitcoin, node don't
> see events in the same
> order, Alice may observe tx X, tx Y, tx Z and Bob may observe tx Z, tx X,
> tx Y. And order of events
> affects if a future event is going to be rejected or not, like if tx Z
> disable-RBF and tx X try to
> replace Z, Alice accepts X and Bob rejects it. And this divergence may
> perserve until a new block.
>
> Practically, it means an attacker can provoke a local conflict to bounce
> off HTLC preimage tx out
> of your mempool while broadcasting preimage tx without conflict to the
> rest of the network by
> tweaking tx-relay protocol and so easily manipulating order of events for
> every node. A local
> conflict is easy to provoke, just make tx A double-spent by both
> HTLC-preimage-tx and non-RBF-tx-B.
> Announce txA+txB to mempool victim and txA+HTLC-preimage-tx to rest of
> network. When rest of
> network announce HTLC-preimage-tx, it's going to rejected by your mempool.
>
> Provoking local conflict assumes of course _interlayer_ mapping by an
> attacker, i.e mapping your LN
> node to your full-node(s). Last time, we check, there was 982 match by IP
> for 4,500 LN/52,000
> full-node. Mapping heuristics is an ongoing research subject and sadly
> seems affordable.
>
> Yes a) you can enable full-RBF on your local node but blinding conflicting
> may still be with higher
> feerate as everything is attacker malleable b) you may want to catch tx
> and extract preimage
> on the p2p wire, but processing raw transaction would be such a DoS
> vector...
>
> Overall, I think we all agree on the long term direction to get a
> Contracting-Protocols-Enhanced
> mempool with a multiparty-safe-API, bundled with package relay deployment.
> Even if there is current
> move toward this direction, this may take longer than expected as with any
> critical-safety
> component in Core.
>
> A temporary fix could be to resuscitate old work to ensure peering through
> a full-RBF propagation path,
> but p2p implications are hard to gauge, like wouldn't guarantee p2p
> censorship resistance of this...
>
> It's quite a tangled issue, with a good deal of both bitcoin and lightning
> knowledge so feel free
> to verify and double-check more than usual
>
> Cheers
>
> [0]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-October/002240.html
>
> Le mer. 22 avr. 2020 à 02:08, ZmnSCPxj via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> a écrit :
>
>> Good morning Laolu, Matt, and list,
>>
>>
>> > > * 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 HTLC-Timeout (assuming my
>> cached
>> > > understanding of `SIGHASH_NOINPUT` still holds).
>> >
>> > no_input isn't needed. With simply single+anyone can pay, then B can
>> attach
>> > a new input+output pair to increase the fees on their HTLC redemption
>> > transaction. As you mention, they now enter into a race against this
>> > malicious ndoe to bump up their fees in order to win over the other
>> party.
>>
>> Right, right, that works as well.
>>
>> >
>> > If the malicious node uses a non-RBF signalled transaction to sweep
>> their
>> > HTLC, then we enter into another level of race, but this time on the
>> mempool
>> > propagation level. However, if there exists a relay path to a miner
>> running
>> > full RBF, then B's higher fee rate spend will win over.
>>
>> Hmm.
>>
>> So basically:
>>
>> * B has no mempool, because it wants to reduce its costs and etc.
>> * C broadcasts a non-RBF claim tx with low fee before A->B locktime (L+1).
>> * B does not notice this tx because:
>> 1. The tx is too low fee to be put in a block.
>> 2. B has no mempool so it cannot see the tx being propagated over the
>> P2P network.
>> * B tries to broadcast higher-fee HTLC-timeout, but fails because it
>> cannot replace a non-RBF tx.
>> * After L+1, C contacts the miners off-band and offers fee payment by
>> other means.
>>
>> 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 pretty
>> low-weight mitigation against this attack.
>>
>> So I think the combination below gives us good size:
>>
>> * The HTLC-Timeout signature from C is flagged with
>> `OP_SINGLE|OP_ANYONECANPAY`.
>> * Normally, the HTLC-Timeout still deducts the fee from the value of
>> the UTXO being spent.
>> * However, if B notices that the L+1 timeout is approaching, it can
>> fee-bump HTLC-Timeout with some onchain funds, recreating its own signature
>> but reusing the (still valid) C signature.
>> * The hashlock branch in this case includes `<0> OP_CHECKSEQUENCEVERIFY`,
>> preventing C from broadcasting a low-fee claim tx.
>>
>> This has the advantages:
>>
>> * B does not need a mempool still and can run in `blocksonly`.
>> * The normal path is still the same as current behavior, we "only" add a
>> new path where if the L+1 timeout is approaching we fee-bump the
>> HTLC-Timeout.
>> * Costs are pretty low:
>> * No need for extra RBF carve-out txo.
>> * Just two additional witness bytes in the hashlock branch.
>> * No mempool rule changes needed, can be done with the P2P network of
>> today.
>> * Probably still resilient even with future changes in mempool rules,
>> as long as typical RBF behaviors still remain.
>>
>> Is my understanding correct?
>>
>> Regards,
>> ZmnSCPxj
>>
>> >
>> > -- Laolu
>> >
>> > On Tue, Apr 21, 2020 at 9:13 PM ZmnSCPxj via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >
>> > > Good morning Matt, and list,
>> > >
>> > > > RBF Pinning HTLC Transactions (aka "Oh, wait, I can steal
>> funds, how, now?")
>> > > > =============================
>> > > >
>> > > > You'll note that in the discussion of RBF pinning we were
>> pretty broad, and that that discussion seems to in fact cover
>> > > > our HTLC outputs, at least when spent via (3) or (4). It does,
>> and in fact this is a pretty severe issue in today's
>> > > > lightning protocol [2]. A lightning counterparty (C, who
>> received the HTLC from B, who received it from A) today could,
>> > > > if B broadcasts the commitment transaction, spend an HTLC using
>> the preimage with a low-fee, RBF-disabled transaction.
>> > > > After a few blocks, A could claim the HTLC from B via the
>> timeout mechanism, and then after a few days, C could get the
>> > > > HTLC-claiming transaction mined via some out-of-band agreement
>> with a small miner. This leaves B short the HTLC value.
>> > >
>> > > My (cached) understanding is that, since RBF is signalled using
>> `nSequence`, any `OP_CHECKSEQUENCEVERIFY` also automatically imposes the
>> requirement "must be RBF-enabled", including `<0> OP_CHECKSEQUENCEVERIFY`.
>> > > Adding that clause (2 bytes in witness if my math is correct) to the
>> hashlock branch may be sufficient to prevent C from making an RBF-disabled
>> transaction.
>> > >
>> > > But then you mention out-of-band agreements with miners, which
>> basically means the transaction might not be in the mempool at all, in
>> which case the vulnerability is not really about RBF or relay, but sheer
>> economics.
>> > >
>> > > The payment is A->B->C, and the HTLC A->B must have a larger timeout
>> (L + 1) than the HTLC B->C (L), in abstract non-block units.
>> > > The vulnerability you are describing means that the current time must
>> now be L + 1 or greater ("A could claim the HTLC from B via the timeout
>> mechanism", meaning the A->B HTLC has timed out already).
>> > >
>> > > If so, then the B->C transaction has already timed out in the past
>> and can be claimed in two ways, either via B timeout branch or C hashlock
>> branch.
>> > > This sets up a game where B and C bid to miners to get their version
>> of reality committed onchain.
>> > > (We can neglect out-of-band agreements here; miners have the
>> incentive to publicly leak such agreements so that other potential bidders
>> can offer even higher fees for their versions of that transaction.)
>> > >
>> > > Before L+1, C has no incentive to bid, since placing any bid at all
>> will leak the preimage, which B can then turn around and use to spend from
>> A, and A and C cannot steal from B.
>> > >
>> > > Thus, B should ensure that *before* L+1, the HTLC-Timeout has been
>> committed onchain, which outright prevents this bidding war from even
>> starting.
>> > >
>> > > The issue then is that B is using a pre-signed HTLC-timeout, which is
>> needed since it is its commitment tx that was broadcast.
>> > > This prevents B from RBF-ing the HTLC-Timeout transaction.
>> > >
>> > > So what is needed is to allow B to add fees to HTLC-Timeout:
>> > >
>> > > * We can add an RBF carve-out output to HTLC-Timeout, at the cost of
>> more blockspace.
>> > > * 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 HTLC-Timeout (assuming my cached
>> understanding of `SIGHASH_NOINPUT` still holds).
>> > >
>> > > With this, B can exponentially increase the fee as L+1 approaches.
>> > > If B can get HTLC-Timeout confirmed before L+1, then C cannot steal
>> the HTLC value at all, since the UTXO it could steal from has already been
>> spent.
>> > >
>> > > In particular, it does not seem to me that it is necessary to change
>> the hashlock-branch transaction of C at all, since this mechanism is enough
>> to sidestep the issue (as I understand it).
>> > > But it does point to a need to make HTLC-Timeout (and possibly
>> symmetrically, HTLC-Success) also fee-bumpable.
>> > >
>> > > Note as well that this does not require a mempool: B can run in
>> `blocksonly` mode and as each block comes in from L to L+1, if HTLC-Timeout
>> is not confirmed, feebump HTLC-Timeout.
>> > > In particular, HTLC-Timeout comes into play only if B broadcast its
>> own commitment transaction, and B *should* be aware that it did so ---
>> there is still no need for mempool monitoring here.
>> > >
>> > > Now, of course this only delays the war.
>> > > Let us now consider what C can do to ensure that the bidding war will
>> happen eventually.
>> > >
>> > > * C can bribe a miner to prevent HTLC-Timeout from confirming between
>> L and L+1.
>> > > * Or in other words, this is a censorship attack.
>> > > * The Bitcoin censorship-resistance model is that censored
>> transactions can be fee-bumped, which attracts non-censoring miners to try
>> their luck at mining and evict the censoring miner.
>> > > * Thus, letting B bump the fee on HTLC-Timeout is precisely the
>> mechanism we need.
>> > > * This sets up a bidding war between C requesting miners to
>> censor, vs. B requesting miners to confirm, but that only sets the stage
>> for a second bidding war later between C and B, thus C is at a
>> disadvantage: it has to bribe miners to censor continuously from L to L+1
>> *and* additional bribe miners to confirm its transaction after L+1, whereas
>> B can offer its bribe as being something that miners can claim now without
>> waiting after L+1.
>> > >
>> > > The issue of course is the additional output that bloats the UTXO set
>> and requires another transaction to claim later.
>> > > And if we have `SIGHASH_NOINPUT`, it seems to me that
>> Decker-Russell-Osuntokun sidesteps this issue as well, as any timed-out
>> HTLC can be claimed with a fee-bumpable transaction directly without
>> RBF-carve-out.
>> > > (As well, it seems to me that, if both nodes support doing so, a
>> Poon-Dryja channel can be upgraded, without onchain activity, to a
>> Decker-Russell-Osuntokun channel: sign a transaction spending the funding
>> tx to a txo that has been set up as Decker-Russell-Osuntokun, do not
>> broadcast that transaction, then revoke the latest Poon-Dryja commitment
>> transactions, then switch the mechanism over to Decker-Russell-Osuntokun;
>> you still need to monitor for previous Poon-Dryja commitment transactions,
>> but HTLCs now sidestep the issue under discussion here.)
>> > >
>> > > 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
>>
> _______________________________________________
> 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/20200422/cdacdb19/attachment-0001.html>

2023-06-09 12:59:31

- reply

📅 Original date posted:2020-04-01
📝 Original message:
Good morning list,
In Bolt 11 we decided to use bech32 to encode lightning invoices.
While bech32 has some nice properties, it isn't well suited for invoices.
The main drawback of Bolt 11 invoices is their size: when you start adding
routing hints or rendezvous onions, invoices become huge and hard to share.
Empirical evidence shows that most lightning transactions are done over
Twitter
(73,41% of all lightning payments in 2019 were made via tweets).
Since Twitter only allows up to 280 characters per tweet, this has severely
impacted
the development of new features for lightning. Anything that made an
invoice bigger
ended up being unused as users were left without any option to share those
invoices.
After several months of research and experimentation at Acinq Research, we
have come
up with a highly efficient invoice encoding, optimized primarily for
Twitter. This has
caused further delays in the development of our iOS wallet, but we felt
this was a
much higher priority.
Our encoding uses an AI-optimized mapping from 11-bit words to Twitter
emojis.
Early results show that emoji invoices are more than 2 times smaller than
legacy invoices.
Reckless users are already using this in production:
https://twitter.com/realtbast/status/1245258812279398400?s=20
https://twitter.com/acinq_co/status/1245258815597096960
There is a spec PR available at [1], along with reference eclair code [2].
We plan to release this feature in the next update of our Phoenix wallet
[3].
We'd like feedback from this list on how to improve this further. We
believe the
same encoding could be used to compress the bitcoin blockchain. With more
training
data, we believe our AI-optimized mapping could allow bitcoin blocks to fit
in a
single tweet; we would then be able to use Twitter feeds to store the whole
blockchain.
Cheers,
Bastien
[1] https://github.com/lightningnetwork/lightning-rfc/pull/762
[2] https://github.com/ACINQ/eclair/tree/emoji-encoding
[3] https://phoenix.acinq.co/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200401/57b78392/attachment-0001.html>

2023-06-09 12:59:17

- reply

📅 Original date posted:2020-03-13
📝 Original message:
Good morning ZmnSCPxj,
Ok I see what you mean. In that case it would be slightly different from
the current path blinding proposal.
The recipient would need to give the sender all the blinding points for
each hop in the blinded path.
Currently the recipient only gives one blinding point and then each node in
the blinded path is able to
compute the next blinding point and send it to the next node.
This may work, but I think it deserves a closer look. The security
assumptions in multi-hop locks is that
the sender can choose every secret from a random distribution. If instead
these secrets are provided by
the recipient, this may open up some attack vectors on the sender. Maybe
the sender can tweak each
recipient secret with a secret of its own, but one would need to write the
exact maths down to verify that
it works end-to-end.
I'm not saying it's impossible, I'm just saying that it's not trivial at
all and the devil is in the details ;)
Cheers,
Bastien
Le ven. 13 mars 2020 à 01:42, ZmnSCPxj <ZmnSCPxj at protonmail.com> a écrit :
> Good morning tbast, rusty, and list,
>
>
> > As for ZmnSCPxj's suggestion, I think there is the same kind of issue.
> > The secrets we establish with anonymous multi-hops locks are between the
> *sender*
> > and each of the hops. In the route blinding case, what we're adding are
> secrets
> > between the *recipient* and the hops, and we don't want the sender to be
> able to
> > influence those. It's a kind of reverse Sphinx. So I'm not sure yet the
> recipient
> > could safely contribute to those secrets, but maybe we'll find a nice
> trick in
> > the future!
>
> Not quite?
>
> The recipient knows the secrets from the first recipient-selected-hop to
> itself, and, if it knows the payment scalar, can subtract those secrets
> from the receiver scalar.
> Thus the sender only has to arrange to deliver the payment point to the
> first recipient-selected-hop, the rest of the recipient-selected-hops will
> add their blinding scalars (which come from the recipient), and the final
> recipient can linearly deduct those.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200313/4f7865b8/attachment.html>

2023-06-09 12:59:16

- reply

📅 Original date posted:2020-03-11
📝 Original message:
Good morning list,
Thanks Rusty for following up on this, I'm glad it may be useful for offers!
I certainly want this as well for wallet users' privacy.
I have gathered my proposal in a better format than my previous gist here:
https://github.com/lightningnetwork/lightning-rfc/blob/route-blinding/proposals/route-blinding.md
You will note that I've been able to simplify the scheme a bit compared to
my
gist. It's now very clear that this is exactly the same kind of secrets
derivation than what Sphinx does. I still have things I want to add to the
proposal, but at least the crypto part should be ready to review (and I
think
it does need more eyes on it).
Feel free to add comments directly on the branch commits, it may be easier
to
review that way. Let me know if you think I should turn it into a draft PR
to
facilitate discussions. It kept it vague on some specific parts on purpose
(such as invoice fields, encrypted blob format); we will learn from early
prototype implementations and enrich the proposal as we go.
A few comments on your previous mails. I have removed the (ab)use of
`payment_secret`, but I think your comment on using the `blinding` to
replace
it would not work because that blinding is known by the next-to-last node
(which computes it and forwards it to the final node).
The goal of `payment_secret` is explicitly to avoid having the next-to-last
node
discover it to prevent him from probing. But I think that you didn't plan on
doing the blinding the same way I'm doing it, which may explain the
difference.
As for ZmnSCPxj's suggestion, I think there is the same kind of issue.
The secrets we establish with anonymous multi-hops locks are between the
*sender*
and each of the hops. In the route blinding case, what we're adding are
secrets
between the *recipient* and the hops, and we don't want the sender to be
able to
influence those. It's a kind of reverse Sphinx. So I'm not sure yet the
recipient
could safely contribute to those secrets, but maybe we'll find a nice trick
in
the future!
Cheers,
Bastien
Le mer. 11 mars 2020 à 00:22, Rusty Russell <rusty at rustcorp.com.au> a
écrit :
> ZmnSCPxj <ZmnSCPxj at protonmail.com> writes:
> > Good morning Rusty, et al.,
> >
> >
> >> Note that this means no payment secret is necessary, since the incoming
> >> `blinding` serves the same purpose. If we wanted to, we could (ab)use
> >> payment_secret as the first 32-bytes to put in Carol's enc1 (i.e. it's
> >> the ECDH for Carol to decrypt enc1).
> >
> > I confess to not reading everything in detail, but it seems to me that,
> with payment point + scalar and path decorrelation, we need to establish a
> secret with each hop anyway (the blinding scalar for path decorrelation),
> so if you need a secret per hop, possibly this could be reused as well?
>
> Indeed, this could be used the same way, though for that secret it can
> simply be placed inside the onion rather than passed alongside.
>
> Cheers,
> Rusty.
> _______________________________________________
> 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/20200311/959e4614/attachment.html>

2023-06-09 12:59:05

- reply

📅 Original date posted:2020-02-25
📝 Original message:
Hi Christian,
This is great, thanks for sharing!
What's really nice with your proposal is that there is effectively no onion
payload for `RV` in the partial onion, which frees up more space than mine.
I believe this makes it quite usable in Bolt 11 invoices, without blowing up
the size of the QR code (but more experimentation is needed on that).
As an example such an onion, with 5 legacy hops (65 byte each) results
> in a 325 + 66 bytes onion, and we save 975 bytes.
While having flexibility when choosing the length of the prefill stream
feels nice,
wouldn't it be safer to impose a fixed size to avoid any kind of heuristic
at `RV`
to try to guess how many hops there are between him and the recipient?
Compute a shared secret using a random ephemeral private key and
> `RV`s public key, and then generate a prefill-key
While implementing, I felt that the part about the shared secret used to
generate
the prefill stream is a bit blurry (your proposal on Github doesn't phrase
it the
same way). I think it's important to stress that this secret is derived
from both
`ephkey` and `RV`'s private key, so that `RV+1` can't compute the same
stream.
Another thing that may be worth mentioning is error forwarding. Since the
recipient generated the onion, `RV` won't have the shared secrets (that's by
design). So it's expected that payment errors won't be readable by `RV`, but
it's probably a good idea if `RV` returns an indication to the sender that
the
payment failed *after* the rendezvous point.
An important side-note is that your proposal is really quick and simple to
implement
from the existing Sphinx code. I have made ASCII diagrams of the scheme
(see [1]).
This may help readers visualize it more easily.
It still has the issue that each hop's amount/cltv is fixed at invoice
generation
time by the recipient. That means MPP cannot be used, and if any channel
along the
path updates their fee the partial onion becomes invalid (unless you
overpay the fees).
Trampoline should be able to address that since it provides more freedom to
each
trampoline node to find an efficient way to forward to the next trampoline.
It's not yet obvious to me how I can mix these two proposals to make it
work though.
I'll spend more time experimenting with that.
Thanks,
Bastien
[1]
https://gist.github.com/t-bast/ab42a7f52eb2e73105557957c8359601#Christian
Le lun. 24 févr. 2020 à 19:22, Christian Decker <decker.christian at gmail.com>
a écrit :
> Hi Bastien,
>
> seems you were a bit quicker than I was with my writeup of my
> proposal. I came up with a scheme that allows us to drop a large part of
> the partial onion, so that it can indeed fit into an outer onion, and
> the rendez-vous node RV can re-construct the original packet from the
> included data [1].
>
> The construction comes down to initializing the part of the routing info
> string that is not going to be used, in such a way that the incremental
> unwrappings at the nodes in the partial onion cancels out. Like you
> mentioned in your mail it comes down extending the filler generation to
> also cover the unused part and then applying all the encryption streams
> xored to the unused space. By doing this we get the middle part of the
> onion consisting of only 0x00 bytes.
>
> I then decided to apply an additional ChaCha20 stream to this prefill,
> such that the onion will not consist of mostly 0x00 bytes which would be
> a dead giveaway to `RV+1` that `RV` was a rendez-vous node.
>
> The process for the partial onion creator boils down to:
>
> - Compute a path from `RV` of its choice to recipient `R`.
> - Compute a shared secret using a random ephemeral private key and
> `RV`s public key, and then generate a prefill-key
> - Compute the prefill by combining the correct substrings of the
> encryption streams for the nodes along the path, then add the
> ChaCha20 stream keyed with the prefill-key.
> - Wrap the onion, including payloads for each of the nodes along path
> `RV` to `R`
> - Trim out the unused space, which now will match the obfuscation
> stream generated with the prefill-key
>
> As an example such an onion, with 5 legacy hops (65 byte each) results
> in a 325 + 66 bytes onion, and we save 975 bytes. See [2] for an example
> of how this looks like.
>
> The sender `S` then just does the following:
>
> - Compute a route from `S` to `RV`
> - Build an onion with the route, specifying the trimmed partial onion
> as payload, along with the usual parameters, for `RV`
> - Initiate payment with the constructed onion
>
> Upon receiving an incoming HTLC with a partial onion the rendez-vous
> node `RV` then just does the following:
>
> - Verify all parameters as usual
> - Extract the partial onion
> - Use the ephemeral key from the partial onion to generate the shared
> secret and the prefill key
> - Generate the prefill stream and insert it in the correct place,
> before the HMAC. This reconstitutes the original routing packet
> - Swap out the original onion with the reconstituted onion and forward.
>
> My writeup [1] is an early draft, but I wanted to get it out early to
> give the discussion a basis to work off. I'll revisit it a couple of
> times before opening a PR, but feel free to shout at me if I have
> forgotten to consider something :-)
>
> Cheers,
> Christian
>
> [1]
> https://github.com/lightningnetwork/lightning-rfc/blob/rendez-vous/proposals/0001-rendez-vous.md
> [2] https://gist.github.com/cdecker/ec06452bc470749d9f6d2de73651c5fd
>
> Bastien TEINTURIER via Lightning-dev
> <lightning-dev at lists.linuxfoundation.org> writes:
> > Good morning list,
> >
> > After exploring decoys [1], which is a cheap way of doing route blinding,
> > I'm turning back to exploring rendezvous.
> > The previous mails on the mailing list mentioned that there was a
> > technicality
> > to make the HMACs check out, but didn't provide a lot of details.
> > The issue is that the filler generation needs to take into account some
> hops
> > that will be added *later*, by the payer.
> >
> > However it is quite easy to work-around, with a few space trade-offs.
> > Let's consider a typical rendezvous setup, where Alice wants to be paid
> via
> > rendezvous Bob, and Carol wants to pay that invoice:
> >
> > Carol -> ... -> Bob -> ... -> Alice
> >
> > If Alice knows how many bytes Carol is going to use for her part of the
> > onion
> > payloads, Alice can easily take them into account when generating her
> > filler by
> > pre-pending the same amount of `0` bytes. It seems reasonable to impose a
> > fixed
> > number of onion bytes for each side of the rendezvous (650 each?) so
> Alice
> > would
> > know that amount.
> >
> > When Carol completes the onion with her part of the route, she simply
> needs
> > to
> > generate filler data for her part of the route following the normal
> Sphinx
> > protocol
> > and apply it to the onion she found in the invoice.
> >
> > But the tricky part is that she needs to give Bob a way of generating the
> > same
> > filler data to unapply it. Then all HMACs correctly check out.
> >
> > I see two ways of doing that:
> >
> > * Carol simply sends that filler (650 bytes), probably via a TLV in
> > `update_add_htlc`.
> > This means every intermediate hop needs to forward that, which is painful
> > and
> > potentially leaking too much data.
> > * Carol provides Bob with the rho keys used to generate her filler, and
> the
> > length
> > used by each hop. This leaks to Bob an upper bound on the number of hops
> > and the
> > number of bytes sent to each hop.
> >
> > Since shift-and-xor kind of crypto is hard to read as equations, but very
> > easy to
> > read as diagrams, I spent a bit of time doing beautiful ASCII art [2].
> > Don't hesitate
> > to have a look at it to find more details about how that works. You can
> > also print
> > that on t-shirts to look fancy at conferences. I also have some sample
> code
> > working
> > in eclair [3] for those who can read Scala without getting headaches.
> >
> > Are there other tricks we can use to reconcile both sides of the onion at
> > Bob's?
> > Maybe cdecker (or someone else) has an ace up his sleeve for me there? :)
> >
> > One important thing to note is that rendezvous on normal onions will be
> > costly to
> > integrate into invoices: it takes 1366 bytes to include one onion, and if
> > we want
> > to handle route failures or let the sender use multi-part, we will need
> to
> > have a
> > handful of pre-encrypted onions in the invoice (hence a few kB, which may
> > not be
> > practical for QR codes).
> >
> > But I did mention before that doing rendezvous on the trampoline onion
> > could have
> > better properties [4]. When doing that, having Carol transmit her filler
> > data only
> > to Bob, via the outer onion payload becomes practical and doesn't leak
> > information.
> > Multi-part would work with a single trampoline onion in the invoice (~500
> > bytes),
> > because nodes can do MPP between trampoline nodes thanks to the
> > onion-in-onion
> > construction. We simply need to decide the size of the trampoline onion
> to
> > allow
> > each side of the rendezvous to be able to insert a number of hops we're
> > comfortable
> > with. You can find more details in the "Rendezvous on a trampoline"
> section
> > of [2].
> >
> > I'm really interested in other approaches to making rendezvous work with
> > the HMACs
> > correctly checking out. If people on this list have drafts, intuitions or
> > random
> > thoughts about possible constructions, please share them, I'd be happy to
> > dive into
> > them to explore alternatives to the one I found, hoping we can make this
> > work and
> > provide this feature to our users in the near future.
> >
> > A small side-note on Hornet. Hornet does offer many features that I
> believe
> > we will
> > want in Lightning in the future. It may seem that doing a custom
> rendezvous
> > scheme
> > is a waste of time since we'll ditch it once/if we implement Hornet.
> While
> > that is
> > true in the long run, I believe that if we're able to find a rendezvous
> > scheme that
> > isn't too much work to implement, it makes sense to have something
> > available soon-ish.
> > Hornet will likely be a longer-term effort that we won't get as soon as
> > we'd like
> > (especially since it will probably require a network-wide update). But
> who
> > knows, maybe
> > we may see that we are trying to create many features that are already
> > built into Hornet
> > (rendezvous, directed message support, etc) and will decide to implement
> > Hornet sooner
> > than expected?
> >
> > Cheers,
> > Bastien
> >
> > [1]
> >
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/002435.html
> > [2] https://gist.github.com/t-bast/ab42a7f52eb2e73105557957c8359601
> > [3] https://github.com/ACINQ/eclair/tree/sphinx-rendezvous
> > [4]
> >
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-October/002237.html
> > _______________________________________________
> > 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/20200225/8301e226/attachment.html>

2023-06-09 12:59:04

- reply

📅 Original date posted:2020-02-24
📝 Original message:
Good morning list,
After exploring decoys [1], which is a cheap way of doing route blinding,
I'm turning back to exploring rendezvous.
The previous mails on the mailing list mentioned that there was a
technicality
to make the HMACs check out, but didn't provide a lot of details.
The issue is that the filler generation needs to take into account some hops
that will be added *later*, by the payer.
However it is quite easy to work-around, with a few space trade-offs.
Let's consider a typical rendezvous setup, where Alice wants to be paid via
rendezvous Bob, and Carol wants to pay that invoice:
Carol -> ... -> Bob -> ... -> Alice
If Alice knows how many bytes Carol is going to use for her part of the
onion
payloads, Alice can easily take them into account when generating her
filler by
pre-pending the same amount of `0` bytes. It seems reasonable to impose a
fixed
number of onion bytes for each side of the rendezvous (650 each?) so Alice
would
know that amount.
When Carol completes the onion with her part of the route, she simply needs
to
generate filler data for her part of the route following the normal Sphinx
protocol
and apply it to the onion she found in the invoice.
But the tricky part is that she needs to give Bob a way of generating the
same
filler data to unapply it. Then all HMACs correctly check out.
I see two ways of doing that:
* Carol simply sends that filler (650 bytes), probably via a TLV in
`update_add_htlc`.
This means every intermediate hop needs to forward that, which is painful
and
potentially leaking too much data.
* Carol provides Bob with the rho keys used to generate her filler, and the
length
used by each hop. This leaks to Bob an upper bound on the number of hops
and the
number of bytes sent to each hop.
Since shift-and-xor kind of crypto is hard to read as equations, but very
easy to
read as diagrams, I spent a bit of time doing beautiful ASCII art [2].
Don't hesitate
to have a look at it to find more details about how that works. You can
also print
that on t-shirts to look fancy at conferences. I also have some sample code
working
in eclair [3] for those who can read Scala without getting headaches.
Are there other tricks we can use to reconcile both sides of the onion at
Bob's?
Maybe cdecker (or someone else) has an ace up his sleeve for me there? :)
One important thing to note is that rendezvous on normal onions will be
costly to
integrate into invoices: it takes 1366 bytes to include one onion, and if
we want
to handle route failures or let the sender use multi-part, we will need to
have a
handful of pre-encrypted onions in the invoice (hence a few kB, which may
not be
practical for QR codes).
But I did mention before that doing rendezvous on the trampoline onion
could have
better properties [4]. When doing that, having Carol transmit her filler
data only
to Bob, via the outer onion payload becomes practical and doesn't leak
information.
Multi-part would work with a single trampoline onion in the invoice (~500
bytes),
because nodes can do MPP between trampoline nodes thanks to the
onion-in-onion
construction. We simply need to decide the size of the trampoline onion to
allow
each side of the rendezvous to be able to insert a number of hops we're
comfortable
with. You can find more details in the "Rendezvous on a trampoline" section
of [2].
I'm really interested in other approaches to making rendezvous work with
the HMACs
correctly checking out. If people on this list have drafts, intuitions or
random
thoughts about possible constructions, please share them, I'd be happy to
dive into
them to explore alternatives to the one I found, hoping we can make this
work and
provide this feature to our users in the near future.
A small side-note on Hornet. Hornet does offer many features that I believe
we will
want in Lightning in the future. It may seem that doing a custom rendezvous
scheme
is a waste of time since we'll ditch it once/if we implement Hornet. While
that is
true in the long run, I believe that if we're able to find a rendezvous
scheme that
isn't too much work to implement, it makes sense to have something
available soon-ish.
Hornet will likely be a longer-term effort that we won't get as soon as
we'd like
(especially since it will probably require a network-wide update). But who
knows, maybe
we may see that we are trying to create many features that are already
built into Hornet
(rendezvous, directed message support, etc) and will decide to implement
Hornet sooner
than expected?
Cheers,
Bastien
[1]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/002435.html
[2] https://gist.github.com/t-bast/ab42a7f52eb2e73105557957c8359601
[3] https://github.com/ACINQ/eclair/tree/sphinx-rendezvous
[4]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-October/002237.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200224/02d2cd82/attachment-0001.html>

2023-06-09 12:58:55

- reply

📅 Original date posted:2020-02-17
📝 Original message:
Exactly what Matt said.
I would also add that libp2p aims to be a kind of swiss-army knife for p2p
networking: that's nice for many use-cases, but when security is your main
focus, it's not.
Look at TLS: most attacks are downgrade attacks because the protocol offers
way too many options.
Protocols like Wireguard have perfectly understood this. No options, not
many configuration hooks -> small, auditable codebase.
For lightning it's the same: we prefer a very simple transport that has no
options whatsoever.
Simple to implement, simple to test, and works great in practice.
Bastien
Le lun. 17 févr. 2020 à 18:00, Matt Corallo <lf-lists at mattcorallo.com> a
écrit :
> Because writing connection logic and peer management is really not that
> complicated compared to HTLC state machines and the rest of lightning. For
> crypto, lighting does use the noise framework, though the resulting code is
> so simple (in a good way) that its super easy to just write it yourself
> instead of fighting with a dependency.
>
> Lastly, for self-respecting cryptocurrency developers,
> not-carefully-audited dependencies are security vulnerabilities that will
> expose your users’ funds. By pulling simple connection logic into a
> lighting implementation, it’s easier to test/fuzz/etc with the rest of a
> project.
>
> Matt
>
> On Feb 17, 2020, at 06:12, Alexandr Burdiyan <burdiyan at gmail.com> wrote:
>
>
> Hi everyone!
>
> Since I recently started digging into all-things-peer-to-peer, I found
> that there’s a lot of fragmentation between many different projects that
> seemingly have a lot of things in common, like networking, encoding
> standards, and etc. I suppose there’re lots of historical reasons for that.
>
> More concretely for Lightning, I wonder why it couldn’t use some existing
> open source technologies and standards, like libp2p [1] for communication,
> or various multiformats [2] standards for addresses, hashes and encodings?
>
> I do think that building and evolving common toolkits and standards for
> decentralized system like libp2p, or multiformats, or IPLD [3] could be
> something very useful for the whole community. Currently, it feels like
> everyone wants to go so fast, so there’s no time for coordination and
> consensus to build these kinds of specs. That is understandable. But I
> wonder if Lightning community ever looked at projects like libp2p and
> multiformats, or maybe is considering to implement them in lightning. Or
> maybe there was a decision of not using them for some reason that I might
> be missing.
>
> [1]: https://libp2p.io
> [2]: https://multiformats.io
> [3]: https://ipld.io
>
> Thanks!
>
> Alexandr Burdiyan
> _______________________________________________
> 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/20200217/3f44b0fb/attachment.html>

2023-06-09 12:58:36

- reply

📅 Original date posted:2020-02-13
📝 Original message:
Hey Rusty and list,
I was starting to think this whole thing was of marginal benefit: note
> that solving "private channels need a temp scid" is far simpler[1].
That's true, the simpler solution does break the on-chain / off-chain link
but
I think we can take this opportunity to also improve payee privacy to make
sure
two invoices can't leak that they are from the same payee.
Even better, this would be a replacement for current route hints
Definitely, this is clearly a good opportunity to re-work route hints to
something that can fix all the short-comings of current route hints, thanks
for
your suggestions on that. And if anyone on this list has other fields that
may
be useful in these new route hints, please do say it.
Propose we take the `z` to use as bolt11 letter, because even the French
> don't pronounce it in "rendez-vous"!)
As long as Z-man didn't want to claim this bolt11 letter for himself or his
puppet army, that sounds good :).
I'll get started on an implementation, and will start working on a spec PR
as
well. I'm hoping to get more reviews from anyone experienced with both
lightning and cryptography to verify that the scheme isn't broken. I'm still
offering beers and cocktails to anyone who cracks it [1]!
Thanks!
Bastien
[1] https://twitter.com/realtbast/status/1227233654503505925
Le jeu. 13 févr. 2020 à 05:49, Rusty Russell <rusty at rustcorp.com.au> a
écrit :
>
> Bastien TEINTURIER <bastien at acinq.fr> writes:
> > Hi Rusty,
> >
> > Thanks for the answer, and good luck with c-lightning 0.8.1-rc1 ;)
>
> ... Now -rc2. I actually had a RL use for lightning (OMG!), and sure
> enough found a bug.
>
> > I've been thinking more about improving my scheme to not require any
sender
> > change, but I don't think that's possible at the moment. As with all
> > Lightning
> > tricks though, once we have Schnorr then it's really easy to do.
> > Alice simply needs to use `s * d_a` as her "preimage" (and the payment
point
> > becomes the P_I Bob needs). That may depend on the exact multi-hop locks
> > construction we end up using though, so I'm not 100% sure about that
yet.
>
> I was starting to think this whole thing was of marginal benefit: note
> that solving "private channels need a temp scid" is far simpler[1].
>
> But since your scheme extends to rendevous, it's much more tempting!
>
> We would use this for normal private channels as well as private routes
> aka new rendezvous. Even better, this would be a replacement for
> current route hints (which lack ability to specify feature bits, which
> we would add here, and is also grossly inefficient if you just want to
> use it for Routeboost[2]).
>
> Propose we take the `z` to use as bolt11 letter, because even the French
> don't pronounce it in "rendez-vous"!)
>
> Then use TLV inside:[3]
>
> * `z` (2): `data_length` variable. One or more entries containing extra
> routing information; there may be more than one `z` field. Each entry
> looks like:
> * `tlv_len` (8 bits)
> * `rendezvous_tlv` (tlv_len bytes)
>
> 1. tlvs: `rendezvous_tlv`
> 2. types:
> 1. type: 1 (`pubkey`)
> 2. data:
> * [`point`:`nodeid`]
> 1. type: 2 (`short_channel_id`)
> 2. data:
> * [`short_channel_id`:`short_channel_id`]
> 1. type: 3 (`fee_base_msat`)
> 2. data:
> * [`tu32`:`fee_base_msat`]
> 1. type: 4 (`fee_proportional_millionths`)
> 2. data:
> * [`tu32`:`fee_proportional_millionths`]
> 1. type: 5 (`cltv_expiry_delta`)
> 2. data:
> * [`tu16`:`cltv_expiry_delta`]
> 1. type: 6 (`features`)
> 2. data:
> * [`...*byte`:`features`]
>
> That probably adds 6 bytes entry, but worth it I think.
>
> Cheers,
> Rusty.
>
> [1] Add a new field to 'funding_locked': "private_scid". If both sides
> support 'option_private_scid' (?) then the "real" scid is no longer
> valid for routing, and we use the private scid.
>
> [2] It's enough to give the scid(s) in this case indicating where you
> have incoming capacity.
>
> [3] I'm really starting to dislike my bolt11 format. We should probably
> start afresh with a TLV-based one, where signature covers the hash
> of each entry (so they can be easily externalized!), but that's a
> big, unrelated task.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200213/5939bbb3/attachment-0001.html>

2023-06-09 12:58:36

- reply

📅 Original date posted:2020-02-13
📝 Original message:
Damn you're good.
Le jeu. 13 févr. 2020 à 11:44, ZmnSCPxj <ZmnSCPxj at protonmail.com> a écrit :
> Good morning t-bast,
>
> > > Propose we take the `z` to use as bolt11 letter, because even the
> French
> > > don't pronounce it in "rendez-vous"!)
> >
> > As long as Z-man didn't want to claim this bolt11 letter for himself or
> his
> > puppet army, that sounds good :).
>
> That would be too obvious.
> What I *am* claiming is `8` for my own use and for my non-existent army of
> city-marching robots, because it does not appear in my public alias at all,
> thus actively misleading surveillors.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200213/dfaa1dea/attachment.html>

2023-06-09 12:58:35

- reply

📅 Original date posted:2020-02-11
📝 Original message:
Hi Rusty,
Thanks for the answer, and good luck with c-lightning 0.8.1-rc1 ;)
(I think we should probably ban forwarding to private channels,
> too, for similar reasons).
Can you detail why? I believe that forwarding through private channels can
actually be pretty useful in the future for payee privacy (more on that
later).
Note that with any self-assigned SCID schemes, Alice has to respond to
> unknown scids in update_add_htlc with some BADONION code (which makes
> *Bob* give Carol an error response, since Alice can't without revealing
> her identity).
I believe the difference is that in your scheme, Bob would answer with
`unknown_next_peer`. When instead Alice responds with a `BADONION`, the only
thing it reveals is that Alice does use the decoy feature (which Mallory
already knows because she has seen an invoice from Alice). As long as this
behavior is consistent throughout the network, I think both options offer
the
same privacy (unless I'm missing something).
I expect such payments to become
> significant, and as long as paying to a temporary id and paying to a
> private channel looks identical, it's too draconian to ban.
True, that must become the default flow for receiving payments on mobile
wallets.
Granted, my solution would take longer to deploy because it needs to be
added to
sender wallets before receivers can require it.
I've been thinking more about improving my scheme to not require any sender
change, but I don't think that's possible at the moment. As with all
Lightning
tricks though, once we have Schnorr then it's really easy to do.
Alice simply needs to use `s * d_a` as her "preimage" (and the payment point
becomes the P_I Bob needs). That may depend on the exact multi-hop locks
construction we end up using though, so I'm not 100% sure about that yet.
But I did come up with what could be an interesting development.
Nothing prevents the decoy scheme to be used for public channels too, and
for
multiple hops: that enables a cheap form of rendezvous that only costs a few
hundred bytes in the invoice.
Alice would select multiple hops to a rendezvous node, and would apply some
blinding to those hops' `node_id` and `scid`. Alice would include these
decoy
hops in the invoice `routing_hints` (only costs 51 bytes per hop instead of
a
full onion). Mallory would only learn an upper bound on the distance between
Alice and the rendezvous.
I have a detailed version of the scheme in a gist [1] if people want to
take a
deeper look and break it (beer on me to the first one who breaks the
scheme).
[1] https://gist.github.com/t-bast/9972bfe9523bb18395bdedb8dc691faf
Cheers,
Bastien
Le lun. 10 févr. 2020 à 04:40, Rusty Russell <rusty at rustcorp.com.au> a
écrit :
>
> Bastien TEINTURIER <bastien at acinq.fr> writes:
> >> But Mallory can do the same attack, I think. Just include the P_I from
> >> the wrong invoice for Bob.
> >
> > Good catch, that's true, thanks for keeping me honest there! In that
case
> > my proposal
> > would need the same mitigation as yours, Bob will need to include the
> > `scid` he received
> > in `update_add_htlc` (this is in fact not that hard once we allow TLV
> > extensions on every
> > message).
>
> Yes, I've added this to the PR. Which gives a new validation path, I
> think:
>
> ## Figuring out what nodeid to use to decode onion
>
> 1. Look up scid from HTLC; if it didn't include one, use default.
> 2. Look up payment_hash; if no invoice is found, use default.
> 3. If invoice specified this scid, get nodeid and use that.
> 4. ... and refuse to forward the HTLC (it must terminate here).
>
> My plan is to add an argument to `invoice` which is an array of one or
> more scids: we get a temporary scids for each peer and use them in the
> routehints. We also assign a random temporary nodeid to that invoice.
>
> The above algo is designed to ensure we behave like any other node which
> has no idea about this nodeid if Mallory:
>
> 1. tries to use a temporary node id on a normal channel to us.
> 2. tries to pay another invoice using this temporary node id.
> 3. tries to probe our outgoing channels using this routing hint
> (I think we should probably ban forwarding to private channels,
> too, for similar reasons).
>
> ---
>
> Note that with any self-assigned SCID schemes, Alice has to respond to
> unknown scids in update_add_htlc with some BADONION code (which makes
> *Bob* give Carol an error response, since Alice can't without revealing
> her identity).
>
> With Bob-assigned SCIDs, Alice simply needs to make him unallocate
> it before forgetting the invoice, so she will simply never see old
> invoices.
>
> (All these schemes give limited privacy, of course: Bob knows who Alice
> is, and fingerprinting and liveness attacks are always possible).
>
> > I'm extremely nervous about custodial lightning services restricting
> >> what they will pay to. This is not theoretical: they will come under
> >> immense KYC pressure in the near future, which means they cannot pay
> >> arbitrary invoices.
> 1>>
> >
> > That's a very good point, thanks for raising this. However I believe
that
> > there are (and will be) enough
> > non-custodial wallets to let motivated users pay whatever they want.
Users
> > can even run their own
> > node to pay such invoices if needed.
>
> Not if ln_strike (no, the other one!) is the future.
>
> > If you are using a custodial wallet and KYC pressure kicks in, then
> > regardless of that feature law may
> > require users to completely reveal who they are paying, so even normal
> > payments wouldn't protect
> > them, don't you think? Regulation could for example disallow paying via
> > unannounced channels entirely
> > (or require you to show the funding tx associated to your unannounced
> > channel).
>
> Actually, as long as the same method is required for both normal private
> channels (which will all use non-tx-based short_channel_ids in the near
> future I hope!), I don't really mind. I expect such payments to become
> significant, and as long as paying to a temporary id and paying to a
> private channel looks identical, it's too draconian to ban. A business
> would probably meet any KYC requirements by simply asking the user
> (perhaps over a certain amount, etc).
>
> (I've put my implementation on hold for a moment while I'm supposed to
> be releasing 0.8.1-rc1 RSN!)
>
> Cheers,
> Rusty.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200211/41e5aa47/attachment.html>

2023-06-09 12:58:34

- reply

📅 Original date posted:2020-02-05
📝 Original message:
>
> But Mallory can do the same attack, I think. Just include the P_I from
> the wrong invoice for Bob.
>
Good catch, that's true, thanks for keeping me honest there! In that case
my proposal
would need the same mitigation as yours, Bob will need to include the
`scid` he received
in `update_add_htlc` (this is in fact not that hard once we allow TLV
extensions on every
message).
I'm extremely nervous about custodial lightning services restricting
> what they will pay to. This is not theoretical: they will come under
> immense KYC pressure in the near future, which means they cannot pay
> arbitrary invoices.
>
That's a very good point, thanks for raising this. However I believe that
there are (and will be) enough
non-custodial wallets to let motivated users pay whatever they want. Users
can even run their own
node to pay such invoices if needed.
If you are using a custodial wallet and KYC pressure kicks in, then
regardless of that feature law may
require users to completely reveal who they are paying, so even normal
payments wouldn't protect
them, don't you think? Regulation could for example disallow paying via
unannounced channels entirely
(or require you to show the funding tx associated to your unannounced
channel).
If we're taking into account such KYC pressure, then I believe none of the
solutions we can provide will
be useful. It will be up to the recipient to decide whether he thus wants
to use a normal invoice and
reveal his identity or pass on that payment.
What do you think? Do you believe `option_scid_assign` can do a better job
in such situations?
Cheers,
Bastien
Le mer. 5 févr. 2020 à 02:44, Rusty Russell <rusty at rustcorp.com.au> a
écrit :
> Bastien TEINTURIER <bastien at acinq.fr> writes:
> > Hey again,
> >
> > Otherwise Mallory gets two invoices, and wants to know if they're
> >> actually the same node. Inv1 has nodeid N1, routehint Bob->C1, Inv2 has
> >> nodeid N2, routehint Bob->C2.
> >
> > I think this attack is interesting. AFAICT my proposal defends against
> this
> > because of the way
> > `payment_secret` and `decoy_key` are both used to derive the `decoy_scid`
> > (but don't trust me, do
> > verify that I'm not missing something).
> >
> > If Mallory doesn't use both the right `decoy_node_id` and
> `payment_secret`
> > to compute `P_I`, Bob
> > will not decode that to a valid real `scid` and will return an
> > `unknown_next_peer` which is good
> > for privacy.
>
> But Mallory can do the same attack, I think. Just include the P_I from
> the wrong invoice for Bob.
>
> > It seems to me that
> > https://github.com/lightningnetwork/lightning-rfc/pull/681 cannot defend
> > against this attack. If both invoices are currently valid, Bob will
> forward
> > an HTLC that uses N1
> > with C2 (because Bob has no way of knowing N1 from the onion, for privacy
> > reasons).
> > The only way I'd see to avoid is would be that Alice needs to share her
> > `decoy_node_id`s with
> > Bob (and the mapping to a `decoy_scid`) which means more state to
> > manage...but maybe I'm just
> > missing a better mitigation?
>
> No, Bob can include the scid he used in the update_add_htlc message, so
> Alice can check.
>
> I'm extremely nervous about custodial lightning services restricting
> what they will pay to. This is not theoretical: they will come under
> immense KYC pressure in the near future, which means they cannot pay
> arbitrary invoices.
>
> Thus my preference for a system which doesn't add any requirements on
> the payer.
>
> Cheers,
> Rusty.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200205/08571a4f/attachment.html>

2023-06-09 12:58:34

- reply

📅 Original date posted:2020-02-04
📝 Original message:
Hey again,
Otherwise Mallory gets two invoices, and wants to know if they're
> actually the same node. Inv1 has nodeid N1, routehint Bob->C1, Inv2 has
> nodeid N2, routehint Bob->C2.
>
I think this attack is interesting. AFAICT my proposal defends against this
because of the way
`payment_secret` and `decoy_key` are both used to derive the `decoy_scid`
(but don't trust me, do
verify that I'm not missing something).
If Mallory doesn't use both the right `decoy_node_id` and `payment_secret`
to compute `P_I`, Bob
will not decode that to a valid real `scid` and will return an
`unknown_next_peer` which is good
for privacy.
It seems to me that
https://github.com/lightningnetwork/lightning-rfc/pull/681 cannot defend
against this attack. If both invoices are currently valid, Bob will forward
an HTLC that uses N1
with C2 (because Bob has no way of knowing N1 from the onion, for privacy
reasons).
The only way I'd see to avoid is would be that Alice needs to share her
`decoy_node_id`s with
Bob (and the mapping to a `decoy_scid`) which means more state to
manage...but maybe I'm just
missing a better mitigation?
Cheers,
Bastien
Le mar. 4 févr. 2020 à 15:09, Bastien TEINTURIER <bastien at acinq.fr> a
écrit :
> I'm a bit confused, I don't know if the implementation work you're
> mentioning refers to my proposal
> or yours :).
>
> When you say `temporary id`, could you clarify whether you mean a
> temporary `node_id` or `scid`?
>
> Firstly, need to brute-force the onion against your N keys.
>
>
> This is probably the part that confuses me. Are you talking about Bob or
> Alice there?
> Alice can easily have her `decoy_node_id` be derived from her real
> `node_id`'s privacy key and the
> `payment_hash` or `payment_preimage`. When she receives a payment, she
> knows which `decoy_node_id`
> should have been used so she doesn't need to brute-force.
>
> That means Alice doesn't even have to change how she stores invoices. When
> Alice retrieves the
> invoice from her DB, if it has the `decoy_node_id` feature bit set, she
> knows she needs to derive
> the correct `node_id`. If it doesn't have that feature bit set, it's a
> "legacy" invoice and she has
> to use her real `node_id`.
>
> Now Mallory uses Bob->C2 to pay to N1 for Inv1. If it works, he knows it's
>> the same node issuing both invoices.
>
>
> Same, that wouldn't work because Alice can easily detect the mismatch and
> pretend she can't decrypt
> the onion (the code doesn't even have to pretend: it will use the expected
> `node_id` and use the
> existing error paths).
>
> Actually, that was too hasty.
>
>
> Ok I think your second email came to the same conclusions and clarifies it
> a bit :).
>
> It's true that this is code where the developer may easily get confused
> between keys (but it's a
> lot simpler than the Sphinx or Noise implementation).
>
> However in my opinion it's still simpler than the `scid` state management
> that needs to happen at
> Alice and Bob in
> https://github.com/lightningnetwork/lightning-rfc/pull/681 (but I would
> need to
> implement both E2E to be able to fairly judge that).
>
> Thanks for the feedback, I'll keep working on improving the proposal.
> Bastien
>
> Le mar. 4 févr. 2020 à 05:29, Rusty Russell <rusty at rustcorp.com.au> a
> écrit :
> >
> > Rusty Russell <rusty at rustcorp.com.au> writes:
> > > Bastien TEINTURIER <bastien at acinq.fr> writes:
> > >> That's of course a solution as well. Even with that though, if Alice
> opens
> > >> multiple channels to each of her Bobs,
> > >> she should use Tor and a different node_id each time for better
> privacy.
> > >
> > > There are two uses for this feature (both of which I started
> implementing):
> > >
> > > 1. Simply always use a temporary id when you have a private channel, to
> > > obscure your onchain footprint. This is a nobrainer.
> > >
> > > 2. For an extra layer of transience, apply a new temporary id and new
> > > nodeid on every invoice *which applies only for that invoice*.
> > >
> > > But implementing the latter securely is fraught!
> > >
> > > Firstly, need to brute-force the onion against your N keys. Secondly,
> > > if you use a temporary key, then you *don't* end up using the HTLC to
> > > pay an invoice matching that key, you *MUST* pretend you couldn't
> > > decrypt the onion! This applies to all code paths between the two,
> > > including parsing the TLV, etc: they must ALL return
> > > WIRE_INVALID_ONION_HMAC.
> > >
> > > Otherwise, Mallory can get an invoice, then send malformed payments to
> > > Alice using the transient key in the invoice and see if she decrypts
> it.
> >
> > Actually, that was too hasty. You can use the payment_hash as a
> > fastpath:
> >
> > 1. Look up invoice using payment_hash.
> >
> > 2. If there is an invoice, and it has a temporary id associated with it,
> > try using that to decrypt the onion. If that works, and the onion is
> > on the final hop, and the TLV decodes, and the payment_secret is
> > correct, you can go back and use this temporary key to decrypt the
> onion.
> > Otherwise, go back and use the normal node key.
> >
> > That's still quite a bit of tricky code though...
> >
> > Cheers,
> > Rusty.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200204/41cc31da/attachment-0001.html>

2023-06-09 12:58:33

- reply

📅 Original date posted:2020-02-04
📝 Original message:
I'm a bit confused, I don't know if the implementation work you're
mentioning refers to my proposal
or yours :).
When you say `temporary id`, could you clarify whether you mean a temporary
`node_id` or `scid`?
Firstly, need to brute-force the onion against your N keys.
This is probably the part that confuses me. Are you talking about Bob or
Alice there?
Alice can easily have her `decoy_node_id` be derived from her real
`node_id`'s privacy key and the
`payment_hash` or `payment_preimage`. When she receives a payment, she
knows which `decoy_node_id`
should have been used so she doesn't need to brute-force.
That means Alice doesn't even have to change how she stores invoices. When
Alice retrieves the
invoice from her DB, if it has the `decoy_node_id` feature bit set, she
knows she needs to derive
the correct `node_id`. If it doesn't have that feature bit set, it's a
"legacy" invoice and she has
to use her real `node_id`.
Now Mallory uses Bob->C2 to pay to N1 for Inv1. If it works, he knows it's
> the same node issuing both invoices.
Same, that wouldn't work because Alice can easily detect the mismatch and
pretend she can't decrypt
the onion (the code doesn't even have to pretend: it will use the expected
`node_id` and use the
existing error paths).
Actually, that was too hasty.
Ok I think your second email came to the same conclusions and clarifies it
a bit :).
It's true that this is code where the developer may easily get confused
between keys (but it's a
lot simpler than the Sphinx or Noise implementation).
However in my opinion it's still simpler than the `scid` state management
that needs to happen at
Alice and Bob in https://github.com/lightningnetwork/lightning-rfc/pull/681
(but I would need to
implement both E2E to be able to fairly judge that).
Thanks for the feedback, I'll keep working on improving the proposal.
Bastien
Le mar. 4 févr. 2020 à 05:29, Rusty Russell <rusty at rustcorp.com.au> a écrit
:
>
> Rusty Russell <rusty at rustcorp.com.au> writes:
> > Bastien TEINTURIER <bastien at acinq.fr> writes:
> >> That's of course a solution as well. Even with that though, if Alice
opens
> >> multiple channels to each of her Bobs,
> >> she should use Tor and a different node_id each time for better
privacy.
> >
> > There are two uses for this feature (both of which I started
implementing):
> >
> > 1. Simply always use a temporary id when you have a private channel, to
> > obscure your onchain footprint. This is a nobrainer.
> >
> > 2. For an extra layer of transience, apply a new temporary id and new
> > nodeid on every invoice *which applies only for that invoice*.
> >
> > But implementing the latter securely is fraught!
> >
> > Firstly, need to brute-force the onion against your N keys. Secondly,
> > if you use a temporary key, then you *don't* end up using the HTLC to
> > pay an invoice matching that key, you *MUST* pretend you couldn't
> > decrypt the onion! This applies to all code paths between the two,
> > including parsing the TLV, etc: they must ALL return
> > WIRE_INVALID_ONION_HMAC.
> >
> > Otherwise, Mallory can get an invoice, then send malformed payments to
> > Alice using the transient key in the invoice and see if she decrypts it.
>
> Actually, that was too hasty. You can use the payment_hash as a
> fastpath:
>
> 1. Look up invoice using payment_hash.
>
> 2. If there is an invoice, and it has a temporary id associated with it,
> try using that to decrypt the onion. If that works, and the onion is
> on the final hop, and the TLV decodes, and the payment_secret is
> correct, you can go back and use this temporary key to decrypt the
onion.
> Otherwise, go back and use the normal node key.
>
> That's still quite a bit of tricky code though...
>
> Cheers,
> Rusty.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200204/f31934c0/attachment.html>

2023-06-09 12:58:32

- reply

📅 Original date posted:2020-02-03
📝 Original message:
Thanks for the feedback and discussion. Here are some more comments.
This is relevant if we ever want to hide the node id of the last node: Bob
> could provide a symmetric
> encryption key to all its peers with unpublished channels, which the peer
> can XOR with its own true
> node id and use the lowest 40 bits (or 46 bits or 58 bits) in the SCID.
I don't understand your point here. Alice cannot hide her node_id from Bob
since the `node_id` is
tied to the (unannounced) channel creation.
But this is not an issue. What Alice wants to break is the ability to link
multiple HTLCs together
because they use the same `node_id`. Since Alice can use a different
`node_id` in every invoice,
it's easy for her to make sure Carol cannot tie those HTLCs together.
In order to hide from Bob, the best Alice can do is use a different
`node_id` for each channel she
opens to Bob and use Tor. This way Bob cannot know that node_id_1 and
node_id_2 both belong to Alice.
I don't think we can do better than that.
I really don't want a special marker on Carol; she needs to just pay like
> normal.
I agree that this would be the ideal outcome (and my current proposal
doesn't achieve that, but I'm
hoping I can improve it to achieve that). Do note that even though my
current proposal requires
a code update from Carol, the code-change would be very small. Adding
support for `payment_secret`
did require a change on Carol to improve security; I'm hoping that a small
enough code-change with
a big enough privacy improvement would eventually be supported by all three
implementations (and
then find its way inside wallets).
I must admit I'm a bit turned off by the state management required by your
proposal. I'm afraid it
may be complex to get right, or be subject to fingerprinting and wouldn't
result in the privacy
gain we're hoping.
I think this really needs to be cheap for Bob; if Bob can be DoS-ed by
offering this feature, I
don't think the Bobs out there will activate it.
I really feel some cryptography trick can allow us to find a solution that
requires no more than a
shared secret to be kept between Alice and Bob, and no
synchronization/state management.
I'd like to explore this option further.
Cheers,
Bastien
Le lun. 3 févr. 2020 à 07:51, m.a.holden via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> a écrit :
> > (I'm seeking a clever way that Bob can assign them and trivially tell
> > which ID is assigned to which peer, but I can't figure it out, so I
> > guess Bob keeps a mapping and restricts each peer to 256 live scids?).
>
> Hi Rusty.
>
> Here's a potential way for Alice and Bob to agree a set of 256 scids
> without any additional messages or changes to existing messages beyond a
> feature flag and a flag in open_channel, but comes with a computational
> cost.
>
> Alice and Bob agree on a random integer `r`. This could be negotiated on
> `open_channel`, but we shouldn't need to send additional information
> because we already have a random integer we can use: the
> `temporary_channel_id`. This is not known to anybody besides Alice and Bob.
>
> When a channel is locked, Bob computes n=256 scids, using something
> approximating `concat(n, trunc_bytes(sha256(ec_mult(2^n*r, Q)), 7))`, where
> `Q` is Alice's public key for the channel funding transaction.
>
> The chance of scid collisions between channels is 2^56, which is probably
> no cause for concern.
>
> Instead of keeping a map of 256 scids for each channel, Bob can use a
> cuckoo filter for efficiency. The filter can be used for a quick membership
> test and also as an associative map from scids to channels. It can also
> support scid deletion in the event of channel closure (at the cost of
> recomputing 256 ec_mults again).
>
> So when Bob receives a new HTLC to forward, he tests it against his cuckoo
> filter and retreives a candidate set of possible channels to which it may
> refer. For each channel, he takes the most significant byte of the scid as
> `m` and performs `trunc_bytes(sha256(ec_mult(2^m*r, Q)), 7)` and tests the
> least-significant 7 bytes of the result against the scid.
>
> Alice does not need to keep all of the scids she may use for invoices
> because they can be computed on the fly, but she will need to keep a copy
> of the `temporary_channel_id`.
>
> In the reverse direction of Alice forwarding HTLCs to Bob, Bob's public
> key for the funding transaction is used instead.
>
> Regards,
> Mark Holden
> _______________________________________________
> 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/20200203/46cc458b/attachment.html>

2023-06-09 12:58:32

- reply

📅 Original date posted:2020-02-03
📝 Original message:
Hi ZmnSCPxj,
That is precisely what I am referring to, the lowest bits of the node ID
> are embedded in the SCID, which we do not want to openly reveal to Carol.
>
Got it, I wasn't understanding your point correctly. We totally agree on
that.
Though if the point is to prevent Carol from correlating different invoices
> as arising from the same payee, then my scheme fails against that.
>
IMO we should prevent Carol from correlating different invoices by using a
different node_id for each invoice.
This requires minimal changes and happens entirely payee-side (see my
initial mail).
Alice would do better to use multiple Bobs in that case.
>
That's of course a solution as well. Even with that though, if Alice opens
multiple channels to each of her Bobs,
she should use Tor and a different node_id each time for better privacy.
Cheers,
Bastien
Le lun. 3 févr. 2020 à 15:51, ZmnSCPxj <ZmnSCPxj at protonmail.com> a écrit :
> Good morning t-bast,
>
>
> > > This is relevant if we ever want to hide the node id of the last node:
> Bob could provide a symmetric
> > > encryption key to all its peers with unpublished channels, which the
> peer can XOR with its own true
> > > node id and use the lowest 40 bits (or 46 bits or 58 bits) in the SCID.
> >
> > I don't understand your point here. Alice cannot hide her node_id from
> Bob since the `node_id` is
> > tied to the (unannounced) channel creation.
> >
> > But this is not an issue. What Alice wants to break is the ability to
> link multiple HTLCs together
> > because they use the same `node_id`. Since Alice can use a different
> `node_id` in every invoice,
> > it's easy for her to make sure Carol cannot tie those HTLCs together.
>
> That is precisely what I am referring to, the lowest bits of the node ID
> are embedded in the SCID, which we do not want to openly reveal to Carol.
> Though if the point is to prevent Carol from correlating different
> invoices as arising from the same payee, then my scheme fails against that.
>
> >
> > In order to hide from Bob, the best Alice can do is use a different
> `node_id` for each channel she
> > opens to Bob and use Tor. This way Bob cannot know that node_id_1 and
> node_id_2 both belong to Alice.
> > I don't think we can do better than that.
>
> Alice would do better to use multiple Bobs in that case.
>
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200203/acea682e/attachment-0001.html>