Nostr notes by

📅 Original date posted:2023-09-08 🗒️ Summary of this ...

2023-09-12T10:59:58+02:00

In reply to nevent1q…u46k
_________________________

📅 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>;

📅 Original date posted:2023-09-07 🗒️ Summary of this ...

2023-09-12T10:59:58+02:00

In reply to nevent1q…f0hc
_________________________

📅 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>;

📅 Original date posted:2023-08-16 🗒️ Summary of this ...

2023-08-21T11:48:48+02:00

In reply to nevent1q…9gpc
_________________________

📅 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>;

📅 Original date posted:2023-05-05 🗒️ Summary of this ...

2023-06-09T15:13:15+02:00

In reply to nevent1q…m33t
_________________________

📅 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>;

📅 Original date posted:2023-04-06 📝 Original message: Hi ...

2023-06-09T15:08:32+02:00

In reply to nevent1q…qm7t
_________________________

📅 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>;

📅 Original date posted:2022-10-24 📝 Original message: Hi ...

2023-06-09T15:07:01+02:00

In reply to nevent1q…5h92
_________________________

📅 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>;

📅 Original date posted:2022-10-10 📝 Original message: Hey ...

2023-06-09T15:06:59+02:00

In reply to nevent1q…p74p
_________________________

📅 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>;

📅 Original date posted:2022-07-01 📝 Original message: Hi ...

2023-06-09T15:06:32+02:00

In reply to nevent1q…r50t
_________________________

📅 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>;

📅 Original date posted:2022-07-01 📝 Original message: Hi ...

2023-06-09T15:06:31+02:00

In reply to nevent1q…8cwy
_________________________

📅 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>;

📅 Original date posted:2022-06-15 📝 Original message: Hey ...

2023-06-09T15:06:14+02:00

In reply to nevent1q…f0nm
_________________________

📅 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>;

📅 Original date posted:2021-12-15 📝 Original message: Good ...

2023-06-09T15:04:47+02:00

In reply to nevent1q…wrws
_________________________

📅 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>;

📅 Original date posted:2021-12-22 📝 Original message: Hey ...

2023-06-09T15:04:42+02:00

In reply to nevent1q…al56
_________________________

📅 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>;

📅 Original date posted:2021-12-21 📝 Original message: Hey ...

2023-06-09T15:04:41+02:00

In reply to nevent1q…4452
_________________________

📅 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>;

📅 Original date posted:2021-12-08 📝 Original message: Hi ...

2023-06-09T15:04:39+02:00

In reply to nevent1q…fylu
_________________________

📅 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>;

📅 Original date posted:2021-12-08 📝 Original message: Hi Z, ...

2023-06-09T15:04:38+02:00

In reply to nevent1q…h396
_________________________

📅 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>;

📅 Original date posted:2021-12-07 📝 Original message: Hi Z, ...

2023-06-09T15:04:37+02:00

In reply to nevent1q…yp83
_________________________

📅 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>;

📅 Original date posted:2021-12-06 📝 Original message: Good ...

2023-06-09T15:04:36+02:00

In reply to nevent1q…mste
_________________________

📅 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>;

📅 Original date posted:2021-04-24 📝 Original message: ...

2023-06-09T15:02:23+02:00

In reply to nevent1q…5j4z
_________________________

📅 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>;

📅 Original date posted:2021-04-26 📝 Original message: I ...

2023-06-09T15:02:23+02:00

In reply to nevent1q…r6vw
_________________________

📅 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>;

📅 Original date posted:2020-11-30 📝 Original message: Hi ...

2023-06-09T15:01:37+02:00

In reply to nevent1q…k843
_________________________

📅 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>;

📅 Original date posted:2020-11-27 📝 Original message: Good ...

2023-06-09T15:01:33+02:00

In reply to nevent1q…muvg
_________________________

📅 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>;

📅 Original date posted:2020-11-19 📝 Original message: Hey ...

2023-06-09T15:01:29+02:00

In reply to nevent1q…zlsd
_________________________

📅 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>;

📅 Original date posted:2020-10-14 📝 Original message: To be ...

2023-06-09T15:01:20+02:00

In reply to nevent1q…hjnx
_________________________

📅 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>;

📅 Original date posted:2020-10-08 📝 Original message: ...

2023-06-09T15:01:01+02:00

In reply to nevent1q…k7nk
_________________________

📅 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>;

📅 Original date posted:2020-10-05 📝 Original message: Hi ...

2023-06-09T15:00:59+02:00

In reply to nevent1q…2ejv
_________________________

📅 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>;

📅 Original date posted:2020-10-09 📝 Original message: Hey ...

2023-06-09T15:00:57+02:00

In reply to nevent1q…pp6l
_________________________

📅 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>;

📅 Original date posted:2020-10-08 📝 Original message: Good ...

2023-06-09T15:00:56+02:00

In reply to nevent1q…3zmv
_________________________

📅 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>;

📅 Original date posted:2020-10-05 📝 Original message: Good ...

2023-06-09T15:00:55+02:00

In reply to nevent1q…2d5g
_________________________

📅 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>;

📅 Original date posted:2020-06-22 📝 Original message: ...

2023-06-09T15:00:31+02:00

In reply to nevent1q…wh62
_________________________

📅 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>;

📅 Original date posted:2020-06-20 📝 Original message: Hello ...

2023-06-09T15:00:30+02:00

In reply to nevent1q…fppq
_________________________

📅 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>;

📅 Original date posted:2020-06-19 📝 Original message: Good ...

2023-06-09T15:00:29+02:00

In reply to nevent1q…pcxh
_________________________

📅 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>;

📅 Original date posted:2020-04-01 📝 Original message: Good ...

2023-06-09T14:59:31+02:00

In reply to nevent1q…8sc0
_________________________

📅 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>;

📅 Original date posted:2020-03-11 📝 Original message: Good ...

2023-06-09T14:59:16+02:00

In reply to nevent1q…pnu7
_________________________

📅 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>;

📅 Original date posted:2020-02-25 📝 Original message: Hi ...

2023-06-09T14:59:05+02:00

In reply to nevent1q…3w3x
_________________________

📅 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>;

📅 Original date posted:2020-02-24 📝 Original message: Good ...

2023-06-09T14:59:04+02:00

In reply to nevent1q…6wwc
_________________________

📅 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>;

📅 Original date posted:2020-02-13 📝 Original message: Hey ...

2023-06-09T14:58:36+02:00

In reply to nevent1q…c055
_________________________

📅 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>;

📅 Original date posted:2020-02-11 📝 Original message: Hi ...

2023-06-09T14:58:35+02:00

In reply to nevent1q…ztam
_________________________

📅 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>;

📅 Original date posted:2020-02-04 📝 Original message: Hey ...

2023-06-09T14:58:34+02:00

In reply to nevent1q…9kze
_________________________

📅 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>;

📅 Original date posted:2020-02-05 📝 Original message: > ...

2023-06-09T14:58:34+02:00

In reply to nevent1q…k24y
_________________________

📅 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>;

📅 Original date posted:2020-02-04 📝 Original message: ...

2023-06-09T14:58:33+02:00

In reply to nevent1q…g6qf
_________________________

📅 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>;

📅 Original date posted:2020-02-03 📝 Original message: Hi ...

2023-06-09T14:58:32+02:00

In reply to nevent1q…70cg
_________________________

📅 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>;

📅 Original date posted:2020-02-03 📝 Original message: ...

2023-06-09T14:58:32+02:00

In reply to nevent1q…ydr4
_________________________

📅 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>;

📅 Original date posted:2019-12-18 📝 Original message: Good ...

2023-06-09T14:57:49+02:00

In reply to nevent1q…r2ms
_________________________

📅 Original date posted:2019-12-18
📝 Original message:
Good morning list,

Thanks again for all the good suggestions, this is awesome.
David and ZmnSCPxj's proposals got me thinking (and I still need to dive
into
Antoine's suggestion as well), and I may have found a very interesting
construction. It's either great or completely dumb. I hope you can help me
figure out which of the two it's going to be.

The core idea is to modify Tapscript's `OP_CHECKSIG`. Instead of reading the
signature as a single 64-bytes stack argument, let's add a small change to
read
the signature as two 32-bytes stack arguments: `R` first then `s`.
Since Taproot already makes changes to this opcode, adding this small change
seems to be quite simple and harmless (and this is the right time to propose
such a change as we're still in the Taproot review process).

This effectively lets us leverage nonce reuse as a feature to prevent double
spending once a signature has been shared off-chain.

Let's set the scene for this usecase. We have a service provider Patrick
that
wants to offer layer 2 services. Patrick prepares some of his UTXOs to have
the
following spending condition:

* A provably unspendable key-path spend
* A script-path spend with the following script (and only that script):
OP_SWAP OP_DUP <R> OP_EQUALVERIFY OP_SWAP <P> OP_CHECKSIG
* Notes:
* The script could be more fancy (maybe we want to use hash(R) instead of R
directly) but you get the idea
* The OP_SWAP are needed because the spending stack will be <P> <R> <s>
* P is of course different for every UTXO

This means that Patrick is committing to the nonce he'll be using to spend
that
output.

Now comes our friend Alice. Patrick wants to open a channel to Alice and
wants
to start using this channel without waiting for on-chain confirmation.
Alice and Patrick build the funding transaction as usual; once Alice sees
the
transaction in the mempool, she can verify that the inputs have the right
format.
Now Alice can be sure that Patrick will not double-spend the funding
transaction's inputs: if he does, he will be signing a different message
with
the same nonce. That would allow Alice to extract the private key for `P`
and
spend the UTXO to herself. She has nothing to lose there because it's
Patrick's
UTXO so she has an incentive to use much higher fees than Patrick.

It seems to me that this construction can be generalized for many off-chain
protocols that don't want to wait for confirmation. I may be overly
optimistic,
but I think this could enable a whole lot of new use-cases and remove many
pain points in Lightning.

This is only a first draft, and there are things that can be improved. Let's
list what comes to mind (you will probably identify other issues):

* Patrick can't use RBF on transactions that spend this kind of UTXO
because it
would reveal his private key: that's probably ok in practice (we can add an
output for CPFP instead like we're doing for anchor outputs [1])
* These UTXOs are easy to recognize on-chain once spent, which may indicate
that this is spent for an off-chain protocol
* It would be great to have a way to allow key-path spend, but revoke this
capability once the script has been revealed (off-chain): that would allow
Patrick to encumber all his UTXOs with such a script and only use it when
needed for an off-chain scenario (and use normal key-path spend otherwise)

Please let me know if this is completely broken, completely dumb or worth
sharing to the bitcoin-dev mailing list to consider including this
`OP_CHECKSIG`
change in the Taproot soft-fork.

Cheers,
Bastien

[1] https://github.com/lightningnetwork/lightning-rfc/pull/688

Le mer. 18 déc. 2019 à 05:49, Antoine Riard <antoine.riard at gmail.com> a
écrit :
>
> Hi Bastien,
>
> The use case you're describing strikes me as similar to a slashing
protocol for a LN node and a watchtower, i.e punishing
> a lazy watchtower for not broadcasting a penalty tx on remote revoked
state. In both case you want "if A don't do X
> unlock some funds for B".
>
> Here a rough slashing protocol I've sketched out to someone else
off-list, it may work for you use case if you replace the penalty tx
> by the funding transaction as a way for the trusted channel funder to
clear his liability. Though you will need onchain interactivity
> before the fact but you may be able to reuse slashing outpoint for
multiple channel funding.
>
> Slashing Protocol
> ----------------------
>
> Alice and Bob lock fund in channel outpoint X. They issue commitment tx
N. Will the accountable watchtower locks fund
> in a 2-of-2 slashing outpoint Y with Bob the client.
>
> When Alice and Bob update channels to N', Bob and Will use some output
from commitment N (like upcoming anchor output)
> to create an accountable tx M. M is paying to Bob after timelock+Bob sig
or is paying to transaction success_penalty P
> with Will sig + Bob sig. Success_penalty P will have 2 inputs, one from M
and from J the justice tx than Bob has given
> to Will. J is spending Alice's revoked commitment N.
>
> So this slashing protocol should avoid Bob making false claim, because
you need a revoked broadcast to enable the claim
> and at same time we use a justice tx output as a proof than Will have
done its monitoring+punishment job. Will shouldn't
> learn commitment balance if there is no channel breach and Alice and Bob
wouldn't be able to collude against Will, if
> watchtower have a penalty tx on Alice non-revoked commitment tx, that's
her concern.
>
> So topology would be:
>
> to_Bob
> /
> X <---------- N <--------- J
> ^ ^
> \ \
> Y <--------------- M <---------- P - to_Will
> \
> to_Bob
>
>
> Main idea of the protocol is to use transactions topology of a first
contract as proofs for a subsidiary contract.
>
> I'm quite sure it's insecure, just quick ideas, any thoughts ?
>
> (but would be really cool to have one accountable protocol to both
watchtower and pay-to-open use cases to save
> engineering costs)
>
> Cheers,
>
> Antoine
>
>
> Le mar. 17 déc. 2019 à 16:08, Ethan Heilman <eth3rs at gmail.com> a écrit :
>>
>> From where I'm sitting the fact that OP_CAT allows people to build
>> more powerful constructions in Bitcoin without introducing additional
>> complexity at the consensus layer is a positive not a negative. Using
>> OP_CAT or OP_SUBSTRING to enforce ECDSA nonce reuse is a very powerful
>> protocol tool for enforcing fairness in layer two protocols.
>>
>> On Tue, Dec 17, 2019 at 11:27 AM ZmnSCPxj via Lightning-dev
>> <lightning-dev at lists.linuxfoundation.org> wrote:
>> >
>> > Good morning t-bast,
>> >
>> > Further, we can enforce that RBF is signalled for every spend of the
output by:
>> >
>> > <0> OP_CHECKSEQUENCEVERIFY OP_DROP <R> OP_SWAP OP_CAT <ACINQ>
OP_CHECKSIG
>> >
>> > Requiring that RBF is signalled gives a little more assurance.
>> > Suppose ACINQ becomes evil and double-spends the output.
>> > The transaction that is posted in the mempool must be marked by RBF
due to the `OP_CHECKSEQUENCEVERIFY` opcode, since `nSequence` also doubles
as RBF opt-in.
>> > Then anyone who notices the double-spend can RBF the double-spending
transaction to themselves rather than ACINQ.
>> > This also further publishes ACINQ private key, until the winning
transaction has an `OP_RETURN` output that pays the entire value as fees
and nobody can RBF it further.
>> >
>> > This is a minor increase in the assurability of the construction, by
making any output that is double-spent directly revocable in favor of the
miners.
>> > Again, it requires `OP_CAT`, which is a very dangerous opcode,
allowing such powerful constructions.
>> >
>> > Regards,
>> > ZmnSCPxj
>> >
>> >
>> > > Thanks a lot David for the suggestion and pointers, that's a really
interesting solution.
>> > > I will dive into that in-depth, it could be very useful for many
layer-2 constructions.
>> > >
>> > > Thanks ZmnSCPxj as well for the quick feedback and the `OP_CAT`
construction,
>> > > a lot of cool tricks coming up once (if?) we have such tools in the
future ;)
>> > >
>> > > Le mar. 17 déc. 2019 à 16:14, ZmnSCPxj <ZmnSCPxj at protonmail.com> a
écrit :
>> > >
>> > > > Good morning David, t-bast, and all,
>> > > >
>> > > > > I'm not aware of any way to currently force single-show
signatures in
>> > > > > Bitcoin, so this is pretty theoretical. Also, single-show
signatures
>> > > > > add a lot of fragility to any setup and make useful features
like RBF
>> > > > > fee bumping unavailable.
>> > > >
>> > > > With `OP_CAT`, we can enforce that a particular `R` is used, which
allows to implement single-show signatures.
>> > > >
>> > > > # Assuming signatures are the concatenation of (R,s)
>> > > > <R> OP_SWAP OP_CAT <ACINQ> OP_CHECKSIG
>> > > >
>> > > > The above would then feed `s` only on the witness stack.
>> > > >
>> > > > Regards,
>> > > > ZmnSCPxj
>> >
>> >
>> > _______________________________________________
>> > 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/20191218/723025ac/attachment-0001.html>;

📅 Original date posted:2019-12-17 📝 Original message: Good ...

2023-06-09T14:57:45+02:00

In reply to nevent1q…08yk
_________________________

📅 Original date posted:2019-12-17
📝 Original message:
Good morning list,

As everyone who has ever used a Lightning wallet is well aware, the
onboarding process could be
made smoother. With Phoenix [1], we've been experimenting with pay-to-open
[2].

That works well in practice and provides a great UX for newcomers, but it
requires temporary trust
between the user and our node (until the funding tx confirms).

That trust relationship appears in two places:

a. The user releases the preimage, then we fund the channel [2]
b. The user trusts that we won't double-spend the funding transaction

We currently need (a) because we can't ensure that the user will reveal the
preimage once we've
funded the channel.

It's (somewhat) easy to fix that once Bitcoin supports Schnorr.
Let's assume that we're using PTLCs (where the secret is a private key) and
MuSig for channel
funding transactions.
When Alice receives a PTLC to forward to Bob, if she doesn't have a channel
to Bob and Bob supports
pay-to-open, she can initiate a tweaked channel opening flow. She can use
tlv extensions in the
`open_channel` message to tell Bob that this channel is linked to a PTLC
with point `X=x*G`.
Bob will tweak the MuSig nonce with `X` and provide Alice with a partial
signature for that nonce.
When Bob then provides the adaptor signature to finalize the funding
transaction, it reveals `x` to
Alice who can now fulfill the PTLC downstream.

Note that in this simple version, Alice knows the nonce tweak beforehand.
This may (or may not,
that will need to be investigated thoroughly) be a security issue.
Even if it turns out to be an issue, I'm pretty sure we can find a secure
protocol that will allow
this atomicity (let's just add another round of communication, that's
usually how we fix broken
cryptographic protocols).

I'm more concerned about fixing (b). As long as the funding transaction is
unconfirmed, there's a
risk of double-spending by the funder. I'm shamelessly trying to use this
mailing list's brainpower
to figure out possible solutions for that. Does someone have ideas that
could help? Can we setup
the incentives so that it's never rational for the funder to double-spend?

Cheers,
Bastien

[1] https://phoenix.acinq.co/
[2] https://medium.com/@ACINQ/phoenix-part-2-pay-to-open-4a8a482dd4d
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191217/9529e2b6/attachment.html>;

📅 Original date posted:2019-11-22 📝 Original message: While ...

2023-06-09T14:57:08+02:00

In reply to nevent1q…xn86
_________________________

📅 Original date posted:2019-11-22
📝 Original message:
While I agree with most of your points, I think there are subtleties to
explore before
completely rejecting the idea.

every use of proof-of-work today (other than to power Bitcoin itself, as
> Bitcoin cannot support itself) can instead be done by using Bitcoins to
> impose this economic cost.
>

That is philosophically true, but the complexity of integrating that small
PoW into Lightning
is much lower than the complexity of integrating **fair, un-gameable**
upfront payments.
And not all PoW is born equal: there are a lot of PoW schemes that have
different trade-offs
than Bitcoin mining (think ASIC-resistance such as variants of Cuckoo
Cycle).

Another key point is that creating ASICs for this PoW is fundamentally
different from creating
ASICs for mining a crypto-currency. Solving this PoW doesn't earn you any
money: it merely
allows you to spam to temporarily disrupt the network.
Since this PoW isn't used in any consensus, we can change the spam PoW
algorithm anytime
we want, making all previous ASICs obsolete.
So it's not obvious to me that anyone would find it viable to invest in
creating such ASICs.

As hardware specialization for the specific Lightning-Network-proof-of-work
> arises, we will find that to practically limit spam, intermediate nodes
> will have to increase and increase the threshold for accepting
> proof-of-work, as spammers are going to switch to the more-specialized
> hardware.
>

That's where I think it can be more subtle than what you describe (I may be
wrong though as
predicting future behavior is hard).

Since I'm ruling out ASICs, we're only dealing with "normal" hardware
bottlenecks (cpu/ram).
That means attackers are not playing at a completely different scale than
normal users.
The cost for attackers to generate an amount of spam mimicking N normal
users will then be
somewhat linear in N (to be investigated further).
That's exactly the same result as upfront payments, where an attacker can
still spam like
he's N users if he's ready to pay a cost linear in N.

I'm slightly playing devil's advocate for the PoW proposal because I think
it's worth exploring
more, even if we eventually abandon it. Maybe you're right and it won't be
as effective to
fight spam as upfront payments: but right now with the arguments I've seen
on this thread,
I'm not yet convinced of that.

Cheers,
Bastien
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191122/32cc41a8/attachment.html>;

📅 Original date posted:2019-11-22 📝 Original message: I ...

2023-06-09T14:57:07+02:00

In reply to nevent1q…smf4
_________________________

📅 Original date posted:2019-11-22
📝 Original message:
I think there's another alternative than upfront payments to prevent spam,
which is maybe less
controversial (but potentially less effective as well - to be investigated).

Why not adapt what has been done with email spam and PoW/merkle puzzles?
The high-level idea would be that the sender must solve a small PoW puzzle *for
each intermediate *
*node *and communicate the solution in the onion.
There are many ways we could do that (a new field in each intermediate hop,
grinding an HMAC
prefix, etc) so before going into specifics I only wanted to submit the
high-level idea.
What's neat with this is that it's simple, doesn't leak any privacy, and
avoids having to create a
node reputation system.

We fight spam by forcing the sender to use some resources (instead of sats).
Maybe this idea has already been proposed and broken, if that's the case
I'd love to see the
discussion if someone can surface it.

Cheers,
Bastien

Le lun. 11 nov. 2019 à 00:32, Rusty Russell <rusty at rustcorp.com.au> a
écrit :

> Anthony Towns <aj at erisian.com.au> writes:
> > On Fri, Nov 08, 2019 at 01:08:04PM +1030, Rusty Russell wrote:
> >> Anthony Towns <aj at erisian.com.au> writes:
> >> [ Snip summary, which is correct ]
> >
> > Huzzah!
> >
> > This correlates all the hops in a payment when the route reaches its end
> > (due to the final preimage getting propogated back for everyone to
> justify
> > the funds they claim). Maybe solvable by converting from hashes to ECC
> > as the trapdoor function?
>
> I hadn't thought of this, but yes, once we've eliminated the trivial
> preimage correlation w/scriptless scripts it'd be a shame to reintroduce
> it here.
>
> We need an accumulator with some strange properties though:
>
> 1. Alice provides tokens and a base accumulator.
> 2. Bob et. al can add these tokens to the accumulator.
> 3. They can tell if invalid tokens have been added to the accumulator.
> 4. They can tell how many tokens (alt: each token has a value and they
> can tell the value sum) have been added.
> 5. They can't tell what tokens have been added (unless they know all
> the tokens, which is trivial).
>
> Any ideas?
>
> > The refund amount propogating back also reveals the path, probably.
> > Could that be obfusticated by somehow paying each intermediate node
> > both as the funds go out and come back, so the refund decreases on the
> > way back?
> >
> > Oh, can we make the amounts work like the onion, where it stays constant?
> > So:
> >
> > Alice wants to pay Dave via Bob, Carol. Bob gets 700 msat, Carol gets
> > 400 msat, Dave gets 300 msat, and Alice gets 100 msat refunded.
> >
> > Success:
> > Alice forwards 1500 msat to Bob (-1500, +1500, 0, 0)
> > Bob forwards 1500 msat to Carol (-1500, 0, +1500, 0)
> > Carol forwards 1500 msat to Dave (-1500, 0, 0, +1500)
> > Dave refunds 1200 msat to Carol (-1500, 0, +1200, +300)
> > Carol refunds 800 msat to Bob (-1500, +800, +400, +300)
> > Bob refunds 100 msat to Alice (-1400, +700, +400, +300)
>
> Or, on success, upfront payment is fully refunded or not refunded at all
> (since they get paid by normal fees)? Either way, no data leak for that
> case.
>
> > Clean routing failure at Carol/Dave:
> > Alice forwards 1500 msat to Bob (-1500, +1500, 0, 0)
> > Bob forwards 1500 msat to Carol (-1500, 0, +1500, 0)
> > Carol says Dave's not talking
> > Carol refunds 1100 msat to Bob (-1500, +1100, +400, 0)
> > Bob refunds 400 msat to Alice (-1100, +700, +400, 0)
> >
> > I think that breaks the correlation pretty well, so you just need a
> > decent way of obscuring path length?
>
> I don't see how this breaks correlation?
>
> > In the uncooperative routing failure case, I wonder if using an ECC
> > trapdoor and perhaps scriptless scripts, you could make it so Carol
> > doesn't even get an updated state without revealing the preimage...
>
> I'm not sure. We can make it so Carol has Bob's preimage(s), etc, so
> that the node which fails doesn't get paid. I initially thought this
> would just make people pair up (fake) nodes, but it's probably not worth
> it since their path would be less-selected in that case.
>
> 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/20191122/c0045b8d/attachment.html>;

📅 Original date posted:2019-08-05 📝 Original message: Good ...

2023-06-09T14:55:48+02:00

In reply to nevent1q…lxsk
_________________________

📅 Original date posted:2019-08-05
📝 Original message:
Good morning fiatjaf,

This is a good question, I'm glad you asked.

As ZmnSCPxj points out, Alice doesn't know. By not syncing the full network
graph, Alice has to accept
"being in the dark" for some decisions. She is merely hoping that RT2 *can
find a route* to Bob. Note that
it's quite easy to help Alice make informed decision by proving routing
hints in the invoice and in gossip
messages (which we already do for "normal" routing).

The graph today is strongly connected, so it's quite a reasonable
assumption (and Alice can easily retry
with another choice of trampoline node if the first one fails - just like
we do today with normal payments).

I fully agree with ZmnSCPxj though that in the future this might not be
true anymore. When/if the network
becomes too large we will likely lose its strongly connected nature. When
that happens, the Lightning
Network will need some kind of hierarchical / packet switched routing
architecture and we won't require
trampoline nodes to know the whole network graph and be able to route to
mostly anyone.
I argue that trampoline routing is a first step towards enabling that. It's
a good engineering trade-off between
ease of implementation and deployment, fixing a problem we have today and
enabling future scaling for
problems we'll have tomorrow. It's somewhat easy once we have trampoline
payments to evolve that to a
system closer to the internet's packet switching infrastructure, so we'll
deal with that once the need for it
becomes obvious.

Does that answer your question?

Cheers,
Bastien

Le sam. 3 août 2019 à 05:48, ZmnSCPxj <ZmnSCPxj at protonmail.com> a écrit :

> Good morning fiatjaf,
>
> I proposed before that we could institute a rule where nodes are mapped to
> some virtual space, and nodes should preferably retain the part of the
> network graph that connects itself to those nodes near to it in this
> virtual space (and possibly prefer to channel to those nodes).
>
>
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-April/001959.html
>
> Thus Alice might **not** know that some route exists between T1 and T2.
>
> T1 itself might not know of a route from itself to T2.
> But if T1 knows a route to T1.5, and it knows that T1.5 is nearer to T2
> than to itself in the virtual space, it can **try** to route through T1.5
> in the hope T1.5 knows a route from itself to T2.
> This can be done if T1 can remove itself from the trampoline route and
> replace itself with T1.5, offerring in exchange some of the fee to T1.5.
>
> Other ways of knowing some distillation of the public network without
> remembering the channel level details are also possible.
> My recent pointlessly long spam email for example has a section on
> Hierarchical Maps.
>
>
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-August/002095.html
>
> Regards,
> ZmnSCPxj
>
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Saturday, August 3, 2019 12:29 AM, fiatjaf <fiatjaf at alhur.es> wrote:
>
> > Ok, since you seem to imply each question is valuable, here's mine: how
> does Alice know RT2 has a route to Bob? If she knows that, can she also
> know T1 has a route to Bob? In any case, why can't she just build her small
> onion with Alice -> T1 -> Bob? I would expect that to be the most common
> case, am I right?
> >
> > On Friday, August 2, 2019, Bastien TEINTURIER <bastien at acinq.fr> wrote:
> >
> > > Good morning list,
> > >
> > > I realized that trampoline routing has only been briefly described to
> this list (credits to cdecker and pm47 for laying
> > > out the foundations). I just published an updated PR [1] and want to
> take this opportunity to present the high level
> > > view here and the parts that need a concept ACK and more feedback.
> > >
> > > Trampoline routing is conceptually quite simple. Alice wants to send a
> payment to Bob, but she doesn't know a
> > > route to get there because Alice only keeps a small area of the
> routing table locally (Alice has a crappy phone,
> > > damn it Alice sell some satoshis and buy a real phone). However, Alice
> has a few trampoline nodes in her
> > > friends-of-friends and knows some trampoline nodes outside of her
> local area (but she doesn't know how to reach
> > > them). Alice would like to send a payment to a trampoline node she can
> reach and defer calculation of the rest of
> > > the route to that node.
> > >
> > > The onion routing part is very simple now that we have variable-length
> onion payloads (thanks again cdecker!).
> > > Just like russian dolls, we simply put a small onion inside a big
> onion. And the HTLC management forwards very
> > > naturally.
> > >
> > > It's always simpler with an example. Let's imagine that Alice can
> reach three trampoline nodes: T1, T2 and T3.
> > > She also knows the details of many remote trampoline nodes that she
> cannot reach: RT1, RT2, RT3 and RT4.
> > > Alice selects T1 and RT2 to use as trampoline hops. She builds a small
> onion that describes the following route:
> > >
> > > Alice -> T1 -> RT2 -> Bob
> > >
> > > She finds a route to T1 and builds a normal onion to send a payment to
> T1:
> > >
> > > Alice -> N1 -> N2 -> T1
> > >
> > > In the payload for T1, Alice puts the small trampoline onion.
> > > When T1 receives the payment, he is able to peel one layer of the
> trampoline onion and discover that he must
> > > forward the payment to RT2. T1 finds a route to RT2 and builds a
> normal onion to send a payment to RT2:
> > >
> > > T1 -> N3 -> RT2
> > >
> > > In the payload for RT2, T1 puts the peeled small trampoline onion.
> > > When RT2 receives the payment, he is able to peel one layer of the
> trampoline onion and discover that he must
> > > forward the payment to Bob. RT2 finds a route to Bob and builds a
> normal onion to send a payment:
> > >
> > > RT2 -> N4 -> N5 -> Bob
> > >
> > > In the payload for Bob, RT2 puts the peeled small trampoline onion.
> > > When Bob receives the payment, he is able to peel the last layer of
> the trampoline onion and discover that he is
> > > the final recipient, and fulfills the payment.
> > >
> > > Alice has successfully sent a payment to Bob deferring route
> calculation to some chosen trampoline nodes.
> > > That part was simple and (hopefully) not controversial, but it left
> out some important details:
> > >
> > > 1. How do trampoline nodes specify their fees and cltv requirements?
> > > 2. How does Alice sync the fees and cltv requirements for her remote
> trampoline nodes?
> > >
> > > To answer 1., trampoline nodes needs to estimate a fee and cltv that
> allows them to route to (almost) any other
> > > trampoline node. This is likely going to increase the fees paid by
> end-users, but they can't eat their cake and
> > > have it too: by not syncing the whole network, users are trading fees
> for ease of use and payment reliability.
> > >
> > > To answer 2., we can re-use the existing gossip infrastructure to
> exchange a new node_update message that
> > > contains the trampoline fees and cltv. However Alice doesn't want to
> receive every network update because she
> > > doesn't have the bandwidth to support it (damn it again Alice, upgrade
> your mobile plan). My suggestion is to
> > > create a filter system (similiar to BIP37) where Alice sends gossip
> filters to her peers, and peers only forward to
> > > Alice updates that match these filters. This doesn't have the issues
> BIP37 has for Bitcoin because it has a cost
> > > for Alice: she has to open a channel (and thus lock funds) to get a
> connection to a peer. Peers can refuse to serve
> > > filters if they are too expensive to compute, but the filters I
> propose in the PR are very cheap (a simple xor or a
> > > node distance comparison).
> > >
> > > If you're interested in the technical details, head over to [1].
> > > I would really like to get feedback from this list on the concept
> itself, and especially on the gossip and fee estimation
> > > parts. If you made it that far, I'm sure you have many questions and
> suggestions ;).
> > >
> > > Cheers,
> > > Bastien
> > >
> > > [1] https://github.com/lightningnetwork/lightning-rfc/pull/654
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190805/b9f66da2/attachment.html>;

📅 Original date posted:2019-05-15 📝 Original message: Good ...

2023-06-09T14:54:59+02:00

In reply to nevent1q…8fkd
_________________________

📅 Original date posted:2019-05-15
📝 Original message:
Good morning list,

I have been digging into Anthony Towns' anyprevout BIP
<https://github.com/ajtowns/bips/blob/bip-anyprevout/bip-anyprevout.mediawiki>;
proposal
to verify that it has everything we need for Eltoo
<https://blockstream.com/eltoo.pdf>;.

The separation between anyprevout and anyprevoutanyscript is very handy
(compared to the previous noinput proposal).
Unless I'm missing something, it would simplify the funding tx (to a simple
multisig without cltv/csv) and remove the need for the trigger tx.

The more tricky part to integrate is the chaperone signature.
If I understand it correctly (which I'm not guaranteeing), we would need to
modify the update transactions to something like:

OP_IF

10 OP_CSV

1 A(s,i) B(s,i) 2 OP_CHECKMULTISIGVERIFY <- public keys' first
> byte in this line is 0x02 or 0x03

2 A(s,i) B(s,i) 2 OP_CHECKMULTISIGVERIFY <- public keys' first
> byte in this line is 0x00 or 0x01

OP_ELSE

<S(i) + 1> OP_CLTV

1 A(u) B(u) 2 OP_CHECKMULTISIGVERIFY <- public keys' first
> byte in this line is 0x02 or 0x03

2 A(u) B(u) 2 OP_CHECKMULTISIGVERIFY <- public keys' first
> byte in this line is 0x00 or 0x01

OP_END

(I ommitted the tapscript changes, ie moving to OP_CHECKSIGADD, to
highlight only the chaperone changes)

When updating the channel, Alice and Bob would exchange their
anyprevoutanyscript signatures (for the 2-of-2 multisig).
The chaperone signature can be provided by either Alice or Bob at
transaction broadcast time (so that it commits to a specific input
transaction).

It seems to me that using the same key for both signatures (the chaperone
one and the anyprevoutanyscript one) is safe here, but if someone knows
better I'm interested.
If that's unsafe, we simply need to introduce another key-pair (chaperone
key).

Is that how you guys understand it too? Do you have other ideas on how to
comply with the need for a chaperone signature?

Note that as Anthony said himself, the BIP isn't final and we don't know
yet if chaperone signatures will eventually be needed, but I think it's
useful to make sure that Eltoo could support it.

Cheers,
Bastien
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190515/ce50601f/attachment.html>;

📅 Original date posted:2022-09-29 📝 Original message:Hi ...

2023-06-08T01:13:48+02:00

In reply to nevent1q…lujc
_________________________

📅 Original date posted:2022-09-29
📝 Original message:Hi Gloria, Greg,

> I interpret most of the discussion around limitations as ideas for
> future improvements rather than criticisms of the proposal

As far as I'm concerned, definitely!

My current understanding is that the main change/improvement that would
make sense here is restricting the whole v3 package's size (instead of
just the child) via committing to a specific value in the taproot annex
(also note that it's probably not just the v3 package's size, it should
be the whole unconfirmed package including potential v2 unconfirmed
ancestors).

While I think this would be very valuable and would like to see this
happen, I believe that can be done in a second, separate step since this
would make relay policy stricter (some v3 transactions that previously
propagated wouldn't propagate under this new rule). As long as you are
able to find a path to miners through upgraded peers that use this annex
approach, you should be able to resolve ACP pinning issues?

I'm curious to know how other people feel about that: is it ok to do
later or should we try to implement this for the first release of v3
transactions?

The other change mentioned (making OP_TRUE standard and allowing outputs
that are below dust) can be added later, as those won't be standard until
we start allowing them, so there shouldn't be any backwards-compatibility
issue with postponing this change. But maybe it's still worth having from
the get-go, even though it may take a bit more time? Again, I'm curious to
have other people's opinion here, I'd be happy to get all of those directly
in the first release of v3 transactions, but I don't know how much
implementation will have to go into that.

> For clarification, package RBF is ParentTx*s*(plural), and
ChildTx(singular),
> so it might be a bit more complicated than we're thinking

Right, good catch, this does require new logic to handle this case.
As Gloria points out, this should be doable, and is definitely worth
adding (those CSV 1 on every other output are really hacky, glad to
find a way to get rid of them).

Thanks,
Bastien

Le lun. 26 sept. 2022 à 18:48, Gloria Zhao <gloriajzhao at gmail.com> a écrit :

> Hi Greg, Antoine, Bastien,
>
> Thanks very much for the feedback! I interpret most of the discussion
> around limitations as ideas for future improvements rather than criticisms
> of the proposal (please correct me if I'm wrong). I'll try to respond to as
> much as possible.
>
> Also I realize that I didn't contextualize this proposal clearly enough;
> it is very tailored for LN Penalty and definitely doesn't close all pinning
> attacks possible (sorry for confusing anyone). I also agree that some bits
> can be a little ugly or tack-on; I would definitely prefer a comprehensive
> RBF revamp to fix all our problems and enable other fee-bumping strategies
> such as
> sign-ANYONECANPAY-then-bring-your-own-fees-by-adding-inputs-at-broadcast. I
> was hoping to get some ideas with the "RBF Improvements" post in January,
> but it doesn't seem like we're much closer to a workable proposal. I think
> this is a minimally-invasive step that works for Lightning today, a small
> fix similar to CPFP carve out.
>
> > As you likely know from previous discussions the biggest scenario this
> does not fix in my estimation is ANYONECANPAY situations. If the parent
> transaction can be "inflated" by tacking on additional inputs, this means
> the total weight of the parent tx lowers the effective feerate of the
> package.
>
> (For more context to other readers I wrote an explanation for this in
> "SIGHASH_ANYONECANPAY Pinning" section of RBF ML post). Yes, this
> unfortunately doesn't fix any of the existing pinning attacks for single
> transaction RBF but also doesn't make them worse. This boils down to adding
> an incentive compatibility rule that ensures you can't replace a
> transaction with something that will confirm slower. Package RBF has an
> ancestor feerate-based rule for this (note it is quite conservative and not
> perfect).
>
> So in the scenario above with the "inflated" parent that was signed ACP,
> the replacement would be rejected because the package ancestor feerate is
> lower than the feerate of what is being replaced. But it is imperfect
> (explained below) and thus I wouldn't recommend it for single transaction
> replacement. So that attack still exists for single transactions, yes.
>
> The strategy of using ACP to bring-your-own-fees has its own challenges
> but hopefully has no current use cases as you say. AFAIK LN Penalty is not
> affected by this since it doesn't use ACP, though obviously I agree we
> should fix it for the future.
>
> So when I said "this is intended for fee-bumping presigned txns in
> contracting protocols," I should have said "this is intended for
> fee-bumping presigned txns specifically using CPFP and anchor outputs."
> Apologies for forgetting to contextualize, I've been sitting on this for
> too long.
>
> > The other scenario it doesn't really fix is where HTLC/commitment-like
> transactions are being resolved in a batch, but due to relative time
> constraints, you may want to accelerate some and not others. Now you must
> pay higher rates to replace all of the transaction bumps. This is a
> "self-pin" and "get good at utxos noob" type problem, but it's something
> that axing rule#3 in favor of a Replace-by-ancestor-feerate system would
> get us.
>
> I understand you to mean "if you don't have enough UTXOs and you're forced
> to batch-bump, you over-pay because you need to bring them all to the
> highest target feerate." Isn't this kind of separate, wallet-related
> problem? Contracting or not, surely every wallet needs to have enough UTXOs
> to not batch transactions that shouldn't be batched... I don't see how a
> replace-by-ancestor-feerate policy would make any difference for this?
>
> Also in general I'd like to reiterate that ancestor feerate is not a
> panacea to all our RBF incentive compatibility concerns. Like individual
> feerate, unless we run the mining algorithm, it cannot tell us exactly how
> quickly this transaction would be mined.
>
> We're estimating the incentive compatibility of the original
> transaction(s) and replacement transaction(s), with the goal of not letting
> a transaction replace something that would have been more incentive
> compatible to mine. As such, we don't want to overestimate how good the
> replacement is, and we don't want to underestimate how good the original
> transactions are. This rule "The minimum between package feerate and
> ancestor feerate of the child is not lower than the individual feerates of
> all directly conflicting transactions and the ancestor feerates of all
> original transactions" is a conservative estimate.
>
> > Would kind of be nice if package RBF would detect a "sibling output
> spend" conflict, and knock it out of the mempool via the other replacement
> rules? Getting rid of the requirement to 1 block csv lock every output
> would be quite nice from a smart contracting composability point of view.
>
> Interesting, so when a transaction hits a mempool tx's descendant limit,
> we consider evicting one of its descendants in favor of this transaction,
> based on the RBF rules.
> Cool idea! After chewing on this for a bit, I think this *also* just boils
> down to the fact that RBF should require replacements to be better mining
> candidates. As in, if we added this policy and it can make us evict the
> sibling and accept a transaction with a bunch of low-feerate ancestor junk,
> it would be a new pinning vector.
>
> > If you're a miner and you receive a non-V3, second descendant of an
> unconfirmed V3 transaction, if the offered fee is in the top mempool
> backlog, I think you would have an interest to accept such a transaction.
>
> > So I'm not sure if those two rules are compatible with miners
> incentives...
>
> The same argument can be made for the 26th descendant of a mempool
> transaction; it's also not entirely incentive-compatible to reject it, but
> that is not the *only* design goal in mempool policy. Of course, the
> difference here is that the 25-descendant limit rule is a sensible DoS
> protection, while this 1-descendant limit rule is more of a "help the
> Bitcoin ecosystem" policy, just like CPFP carve-out, dust limit, etc. I can
> of course understand why not everyone would be in favor of this, but I do
> think it's worth it.
>
> > > 4. A V3 transaction that has an unconfirmed V3 ancestor cannot be
> > > larger than 1000 virtual bytes.
>
> > If I understand correctly the 1000 vb upper bound rational, it would be
> to constraint the pinning counterparty to attach a high fee to a child due
> to the limited size, if they would like this transaction to be stuck in the
> network mempools. By doing so this child has high odds to confirm.
>
> Yeah exactly, the "Rule 3 pin" is done by adding a child that's high-fee
> (so you have to pay that much to evict it). Because they *don't* want this
> tx to confirm, normally, this child would be really large. If they only
> have 1000vB for the child, they can't increase the replacement cost without
> also fee-bumping the transaction to make it confirm faster.
>
> > As of today, I think yes you can already fingerprint LN transactions on
> the spec-defined amount value of the anchor outputs, 330 sats. There is
> always one of them on post-anchor commitment transactions. And sadly I
> would say we'll always have tricky fingerprints leaking from unilateral LN
> closures such as HTLC/PTLC timelocks...
>
> > I agree with you, this isn't worse than today, unilateral closes will
> probably always be identifiable on-chain.
>
> Great to hear that there is no privacy worsening!
>
> Best,
> Gloria
>
> On Mon, Sep 26, 2022 at 5:02 PM Greg Sanders <gsanders87 at gmail.com> wrote:
>
>> Bastien,
>>
>> > This may be already covered by the current package RBF logic, in that
>> scenario we are simply replacing [ParentTx, ChildTx1] with
>> [ParentTx, ChildTx2] that pays more fees, right?
>>
>> For clarification, package RBF is ParentTx*s*(plural), and
>> ChildTx(singular), so it might be a bit more complicated than we're
>> thinking, and currently the V3 proposal would first de-duplicate the
>> ParentTx based on what is in the mempool, then look at the "rest" of the
>> transactions as a package, then individually. Not the same, not sure how
>> different. I'll defer to experts.
>>
>> Best,
>> Greg
>>
>> On Mon, Sep 26, 2022 at 11:48 AM Bastien TEINTURIER via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> Thanks Gloria for this great post.
>>>
>>> This is very valuable work for L2 contracts, and will greatly improve
>>> their security model.
>>>
>>> > "Only 1 anchor output? What if I need to bump counterparty's
>>> commitment tx in mempool?"
>>> > You won't need to fee-bump a counterparty's commitment tx using CPFP.
>>> > You would just package RBF it by attaching a high-feerate child to
>>> > your commitment tx.
>>>
>>> Note that we can also very easily make that single anchor spendable by
>>> both participants (or even anyone), so if you see your counterparty's
>>> commitment in your mempool, you can bump it without publishing your
>>> own commitment, which is quite desirable (your own commitment tx has
>>> CSV delays on your outputs, whereas your counterparty's commitment tx
>>> doesn't).
>>>
>>> > "Is this a privacy issue, i.e. doesn't it allow fingerprinting LN
>>> transactions based on nVersion?"
>>>
>>> I agree with you, this isn't worse than today, unilateral closes will
>>> probably always be identifiable on-chain.
>>>
>>> > Would kind of be nice if package RBF would detect a "sibling output
>>> spend"
>>> > conflict, and knock it out of the mempool via the other replacement
>>> rules?
>>> > Getting rid of the requirement to 1 block csv lock every output would
>>> be
>>> > quite nice from a smart contracting composability point of view.
>>>
>>> +1, that would be very neat!
>>>
>>> This may be already covered by the current package RBF logic, in that
>>> scenario we are simply replacing [ParentTx, ChildTx1] with
>>> [ParentTx, ChildTx2] that pays more fees, right?
>>>
>>> > 1) I do think that we should seriously consider allowing OP_TRUE to
>>> become
>>> > a standard script type as part of this policy update. If pinning is
>>> solved,
>>> > then there's no reason to require all those extra bytes for "binding"
>>> an
>>> > anchor to a specific wallet/user. We can save quite a few bytes by
>>> having
>>> > the input be empty of witness data.
>>> > 2) If we allow for a single dust-value(0 on up) output which is
>>> immediately
>>> > spent by the package, anchors become even easier to to design. No
>>> value has
>>> > to be "sapped" from contract participants to make an anchor output.
>>> There's
>>> > more complications for this, such as making sure the parent
>>> transaction is
>>> > dropped if the child spend is dropped, but maybe it's worth the
>>> squeeze.
>>>
>>> I also think both of these could be quite useful. This would probably
>>> always
>>> be used in combination with a parent transaction that pays 0 fees, so the
>>> 0-value output would always be spent in the same block.
>>>
>>> But this means we could end up with 0-value outputs in the utxo set, if
>>> for
>>> some reason the parent tx is CPFP-ed via another output than the 0-value
>>> one,
>>> which would be a utxo set bloat issue. But I'd argue that we're probably
>>> already creating utxo set bloat with the 330 sat anchor outputs
>>> (especially
>>> since we use two of them, but only one is usually spent), so it would
>>> probably be *better* than what we're doing today.
>>>
>>> Thanks,
>>> Bastien
>>>
>>> Le lun. 26 sept. 2022 à 03:22, Antoine Riard via bitcoin-dev <
>>> bitcoin-dev at lists.linuxfoundation.org> a écrit :
>>>
>>>> Hi Gloria,
>>>>
>>>> Thanks for the progress on package RBF, few early questions.
>>>>
>>>> > 2. Any descendant of an unconfirmed V3 transaction must also be V3.
>>>>
>>>> > 3. An unconfirmed V3 transaction cannot have more than 1 descendant.
>>>>
>>>> If you're a miner and you receive a non-V3, second descendant of an
>>>> unconfirmed V3 transaction, if the offered fee is in the top mempool
>>>> backlog, I think you would have an interest to accept such a transaction.
>>>>
>>>> So I'm not sure if those two rules are compatible with miners
>>>> incentives...
>>>>
>>>> > 4. A V3 transaction that has an unconfirmed V3 ancestor cannot be
>>>> > larger than 1000 virtual bytes.
>>>>
>>>> If I understand correctly the 1000 vb upper bound rational, it would be
>>>> to constraint the pinning counterparty to attach a high fee to a child due
>>>> to the limited size, if they would like this transaction to be stuck in the
>>>> network mempools. By doing so this child has high odds to confirm.
>>>>
>>>> I still wonder if this compatible with miner incentives in period of
>>>> empty mempools, in the sense that if you've already a V3 transaction of
>>>> size 100Kvb offering 2 sat/vb, it's more interesting than a V3 replacement
>>>> candidate of size 1000 vb offering 10 sat/vb. It could be argued the former
>>>> should be conserved.
>>>>
>>>> (That said, the hard thing with any replacement strategy we might evict
>>>> a parent transaction *now* to which is attached a high-feerate child
>>>> *latter* making for a utxo considered the best ancestor set. Maybe in the
>>>> long-term miners should keep every transaction ever accepted...)
>>>>
>>>> > (Lower bound) the smaller this limit, the fewer UTXOs a child may use
>>>> > to fund this fee-bump. For example, only allowing the V3 child to have
>>>> > 2 inputs would require L2 protocols to manage a wallet with high-value
>>>> > UTXOs and make batched fee-bumping impossible. However, as the
>>>> > fee-bumping child only needs to fund fees (as opposed to payments),
>>>> > just a few UTXOs should suffice.
>>>>
>>>> Reminder for L2 devs, batched fee-bumping of time-sensitive
>>>> confirmations of commitment transactions is unsafe, as the counterparty
>>>> could enter in a "cat-and-mouse" game to replace one of the batch element
>>>> at each block to delay confirmation of the remaining elements in the batch,
>>>> I think.
>>>>
>>>> On the other hand, I wonder if we wouldn't want a higher bound. LN
>>>> wallets are likely to have one big UTXO in their fee-bumping reserve pool,
>>>> as the cost of acquiring UTXO is non-null and in the optimistic case, you
>>>> don't need to do unilateral closure. Let's say you close dozens of channels
>>>> at the same time, a UTXO pool management strategy might be to fan-out the
>>>> first spends UTXOs in N fan-out outputs ready to feed the remaining
>>>> in-flight channels.
>>>>
>>>> > 1. The rule around unconfirmed inputs was
>>>> > originally "A package may include new unconfirmed inputs, but the
>>>> > ancestor feerate of the child must be at least as high as the ancestor
>>>> > feerates of every transaction being replaced."
>>>>
>>>> Note, I think we would like this new RBF rule to also apply to single
>>>> transaction package, e.g second-stage HTLC transactions, where a
>>>> counterparty pins a HTLC-preimage by abusing rule 3. In that case, the
>>>> honest LN node should be able to broadcast a "at least as high ancestor
>>>> feerate" HTLC-timeout transaction. With `option_anchor_outputs" there is no
>>>> unconfirmed ancestor to replace, as the commitment transaction, whatever
>>>> the party it is originating from, should already be confirmed.
>>>>
>>>> > "Is this a privacy issue, i.e. doesn't it allow fingerprinting LN
>>>> transactions based on nVersion?"
>>>>
>>>> As of today, I think yes you can already fingerprint LN transactions on
>>>> the spec-defined amount value of the anchor outputs, 330 sats. There is
>>>> always one of them on post-anchor commitment transactions. And sadly I
>>>> would say we'll always have tricky fingerprints leaking from unilateral LN
>>>> closures such as HTLC/PTLC timelocks...
>>>>
>>>> > "Can a V2 transaction replace a V3 transaction and vice versa?"
>>>>
>>>> IIUC, a V3 package could replace a V2 package, with the benefit of the
>>>> new package RBF rules applied. I think this would be a significant
>>>> advantage for LN, as for the current ~85k of opened channels, the old V2
>>>> states shouldn't be pinning vectors. Currently, commitment transactions
>>>> signal replaceability.
>>>>
>>>> Le ven. 23 sept. 2022 à 11:26, Gloria Zhao via bitcoin-dev <
>>>> bitcoin-dev at lists.linuxfoundation.org> a écrit :
>>>>
>>>>> Hi everyone,
>>>>>
>>>>> I'm writing to propose a very simple set of mempool/transaction relay
>>>>> policies intended to aid L2/contract protocols. I realized that
>>>>> the previously proposed Package Mempool Accept package RBF [1]
>>>>> had a few remaining problems after digging into the RBF logic more [2].
>>>>> This additional set of policies solves them without requiring a huge
>>>>> RBF overhaul.
>>>>>
>>>>> I've written an implementation (and docs) for Bitcoin Core:
>>>>> https://github.com/bitcoin/bitcoin/pull/25038
>>>>>
>>>>> (You may notice that this proposal incorporates feedback on the PR -
>>>>> thanks Suhas Daftuar, Gregory Sanders, Bastien Teinturier, Anthony Towns,
>>>>> and others.)
>>>>>
>>>>> If you are interested in using package RBF/relay to bump presigned
>>>>> transactions, I think you may be interested in reviewing this proposal.
>>>>> This should solve Rule 3 pinning and perhaps allow us
>>>>> to get rid of CPFP carve-out (yay!). I'm keen to hear if people find
>>>>> the 1-anchor-output, 1000vB child limit too restrictive. Also, if you
>>>>> find a
>>>>> pinning attack or something that makes it unusable for you, I would
>>>>> really really like to know.
>>>>>
>>>>> Note that transactions with nVersion=3 ("V3 transactions") are
>>>>> currently non-standard in Bitcoin Core. That means **anything that was
>>>>> standard before this policy change would still be standard
>>>>> afterwards.** If you don't want your transactions to be subject to
>>>>> these rules, just continue whatever you're doing and don't use
>>>>> nVersion=3. AFAICT this shouldn't break anything, but let me know if
>>>>> this would be disruptive for you?
>>>>>
>>>>> **New Policies:**
>>>>>
>>>>> This includes:
>>>>> - a set of additional policy rules applying to V3 transactions
>>>>> - modifications to package RBF rules
>>>>>
>>>>> **V3 transactions:**
>>>>>
>>>>> Existing standardness rules apply to V3 (e.g. min/max tx weight,
>>>>> standard output types, cleanstack, etc.). The following additional
>>>>> rules apply to V3:
>>>>>
>>>>> 1. A V3 transaction can be replaced, even if it does not signal BIP125
>>>>> replaceability. (It must also meet the other RBF rules around fees,
>>>>> etc. for replacement to happen).
>>>>>
>>>>> 2. Any descendant of an unconfirmed V3 transaction must also be V3.
>>>>>
>>>>> *Rationale*: Combined with Rule 1, this gives us the property of
>>>>> "inherited" replaceability signaling when descendants of unconfirmed
>>>>> transactions are created. Additionally, checking whether a transaction
>>>>> signals replaceability this way does not require mempool traversal,
>>>>> and does not change based on what transactions are mined. It also
>>>>> makes subsequent rules about descendant limits much easier to check.
>>>>>
>>>>> *Note*: The descendant of a *confirmed* V3 transaction does not need
>>>>> to be V3.
>>>>>
>>>>> 3. An unconfirmed V3 transaction cannot have more than 1 descendant.
>>>>>
>>>>> *Rationale*: (Upper bound) the larger the descendant limit, the more
>>>>> transactions may need to be replaced. This is a problematic pinning
>>>>> attack, i.e., a malicious counterparty prevents the transaction from
>>>>> being replaced by adding many descendant transactions that aren't
>>>>> fee-bumping.
>>>>>
>>>>> (Lower bound) at least 1 descendant is required to allow CPFP of the
>>>>> presigned transaction. The contract protocol can create presigned
>>>>> transactions paying 0 fees and 1 output for attaching a CPFP at
>>>>> broadcast time ("anchor output"). Without package RBF, multiple anchor
>>>>> outputs would be required to allow each counterparty to fee-bump any
>>>>> presigned transaction. With package RBF, since the presigned
>>>>> transactions can replace each other, 1 anchor output is sufficient.
>>>>>
>>>>> 4. A V3 transaction that has an unconfirmed V3 ancestor cannot be
>>>>> larger than 1000 virtual bytes.
>>>>>
>>>>> *Rationale*: (Upper bound) the larger the descendant size limit, the
>>>>> more vbytes may need to be replaced. With default limits, if the child
>>>>> is e.g. 100,000vB, that might be an additional 100,000sats (at
>>>>> 1sat/vbyte) or more, depending on the feerate.
>>>>>
>>>>> (Lower bound) the smaller this limit, the fewer UTXOs a child may use
>>>>> to fund this fee-bump. For example, only allowing the V3 child to have
>>>>> 2 inputs would require L2 protocols to manage a wallet with high-value
>>>>> UTXOs and make batched fee-bumping impossible. However, as the
>>>>> fee-bumping child only needs to fund fees (as opposed to payments),
>>>>> just a few UTXOs should suffice.
>>>>>
>>>>> With a limit of 1000 virtual bytes, depending on the output types, the
>>>>> child can have 6-15 UTXOs, which should be enough to fund a fee-bump
>>>>> without requiring a carefully-managed UTXO pool. With 1000 virtual
>>>>> bytes as the descendant limit, the cost to replace a V3 transaction
>>>>> has much lower variance.
>>>>>
>>>>> *Rationale*: This makes the rule very easily "tacked on" to existing
>>>>> logic for policy and wallets. A transaction may be up to 100KvB on its
>>>>> own (`MAX_STANDARD_TX_WEIGHT`) and 101KvB with descendants
>>>>> (`DEFAULT_DESCENDANT_SIZE_LIMIT_KVB`). If an existing V3 transaction
>>>>> in the mempool is 100KvB, its descendant can only be 1000vB, even if
>>>>> the policy is 10KvB.
>>>>>
>>>>> **Package RBF modifications:**
>>>>>
>>>>> 1. The rule around unconfirmed inputs was
>>>>> originally "A package may include new unconfirmed inputs, but the
>>>>> ancestor feerate of the child must be at least as high as the ancestor
>>>>> feerates of every transaction being replaced."
>>>>>
>>>>> The package may still include new unconfirmed inputs. However,
>>>>> the new rule is modified to be "The minimum between package feerate
>>>>> and ancestor feerate of the child is not lower than the individual
>>>>> feerates of all directly conflicting transactions and the ancestor
>>>>> feerates of all original transactions."
>>>>>
>>>>> *Rationale*: We are attempting to ensure that the replacement
>>>>> transactions are not less incentive-compatible to mine. However, a
>>>>> package/transaction's ancestor feerate is not perfectly representative
>>>>> of its incentive compatibility; it may overestimate (some subset of
>>>>> the ancestors could be included by itself if it has other high-feerate
>>>>> descendants or are themselves higher feerate than this
>>>>> package/transaction). Instead, we use the minimum between the package
>>>>> feerate and ancestor feerate of the child as a more conservative value
>>>>> than what was proposed originally.
>>>>>
>>>>> 2. A new rule is added, requiring that all package transactions with
>>>>> mempool conflicts to be V3. This also means the "sponsoring"
>>>>> child transaction must be V3.
>>>>>
>>>>> *Note*: Combined with the V3 rules, this means the package must be
>>>>> a child-with-parents package. Since package validation is only
>>>>> attempted if the transactions do not pay sufficient fees to be
>>>>> accepted on their own, this effectively means that only V3
>>>>> transactions can pay to replace their ancestors' conflicts, and only
>>>>> V3 transactions' replacements may be paid for by a descendant.
>>>>>
>>>>> *Rationale*: The fee-related rules are economically rational for
>>>>> ancestor packages, but not necessarily other types of packages.
>>>>> A child-with-parents package is a type of ancestor package. It
>>>>> may be fine to allow any ancestor package, but it's more difficult
>>>>> to account for all of the possibilities. For example, it gets much
>>>>> harder to see that we're applying the descendant limits correctly if
>>>>> the package has a gnarly, many-generation, non-tree shape. I'm also
>>>>> not sure if this policy is 100% incentive-compatible if the sponsor
>>>>> is not a direct descendant of the sponsee.
>>>>>
>>>>> Please see doc/policy/version3_transactions.md and
>>>>> doc/policy/packages.md in the PR for the full set of rules.
>>>>>
>>>>> **Intended usage for LN:**
>>>>>
>>>>> Commitment transactions should be V3 and have 1 anchor output. They
>>>>> can be signed with 0 fees (or 1sat/vbyte) once package relay is
>>>>> deployed
>>>>> on a significant portion of the network. If the commitment tx must
>>>>> be broadcast, determine the desired feerate at broadcast time and
>>>>> spend the anchor output in a high feerate transaction. I'm going to
>>>>> call the broadcasted commitment tx "the parent" and the attached
>>>>> fee-bumping tx "the child."
>>>>>
>>>>> - This child must be V3.
>>>>> - This child must be at most 1000vB. Note this restricts the
>>>>> number of inputs you can use to fund the fee bump. Depending
>>>>> on the output types, this is around 6-15.
>>>>> - One child may fund fees for multiple commitment tx ("batched
>>>>> fee-bumping").
>>>>> - To do a second fee-bump to add more fees, replace the
>>>>> *child* with a higher-feerate tx. Do not try to attach a grandchild.
>>>>>
>>>>> Otherwise, never try to spend from an unconfirmed V3 transaction. The
>>>>> descendant limits for V3 transactions are very restrictive.
>>>>>
>>>>> **Expected Questions:**
>>>>>
>>>>> "Does this fix Rule 3 Pinning?"
>>>>> Yes. The V3 descendant limit restricts both you and your counterparty.
>>>>> Assuming nodes adopted this policy, you may reasonably assume that you
>>>>> only need to replace the commitment transaction + up to 1000vB.
>>>>>
>>>>> "Only 1 anchor output? What if I need to bump counterparty's
>>>>> commitment tx in mempool?"
>>>>> You won't need to fee-bump a counterparty's commitment tx using CPFP.
>>>>> You would just package RBF it by attaching a high-feerate child to
>>>>> your commitment tx.
>>>>>
>>>>> "Is this a privacy issue, i.e. doesn't it allow fingerprinting LN
>>>>> transactions based on nVersion?"
>>>>> Indeed it may be unrealistic to assume V3 transactions will be in
>>>>> widespread use outside of L2. IIUC, unilateral closes are already
>>>>> obvious LN transactions because of the HTLC inputs. For e.g.
>>>>> cooperative closes and opens, I think it makes sense to continue using
>>>>> V2. So, unless I'm missing something, this shouldn't make it worse.
>>>>>
>>>>> "So a V3 transaction that doesn't signal BIP125 replaceability is
>>>>> replaceable? Is that a backward compatibility issue?"
>>>>> Yes it's replaceable. It's not an issue AFAICT because,
>>>>> under previous policy, the V3 transaction wouldn't have been
>>>>> in the mempool in the first place.
>>>>>
>>>>> "Can a V2 transaction replace a V3 transaction and vice versa?"
>>>>> Yes, otherwise someone can use V3 transactions to censor V2
>>>>> transactions spending shared inputs. Note if the
>>>>> original V3 transaction has an unconfirmed V3 parent, this would
>>>>> violate the "inherited V3" rule and would be rejected.
>>>>>
>>>>> Thanks for reading! Feedback and review would be much appreciated.
>>>>>
>>>>> [1]:
>>>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019464.html
>>>>> [2]:
>>>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019817.html
>>>>>
>>>>> Best,
>>>>> Gloria
>>>>> _______________________________________________
>>>>> 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
>>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220929/dba37dc7/attachment-0001.html>;

📅 Original date posted:2021-09-20 📝 Original message:Hi ...

2023-06-08T00:59:25+02:00

In reply to nevent1q…743p
_________________________

📅 Original date posted:2021-09-20
📝 Original message:Hi Gloria,

Thanks for this detailed post!

The illustrations you provided are very useful for this kind of graph
topology problems.

The rules you lay out for package RBF look good to me at first glance
as there are some subtle improvements compared to BIP 125.

> 1. A package cannot exceed `MAX_PACKAGE_COUNT=25` count and
> `MAX_PACKAGE_SIZE=101KvB` total size [8]

I have a question regarding this rule, as your example 2C could be
concerning for LN (unless I didn't understand it correctly).

This also touches on the package RBF rule 5 ("The package cannot
replace more than 100 mempool transactions.")

In your example we have a parent transaction A already in the mempool
and an unrelated child B. We submit a package C + D where C spends
another of A's inputs. You're highlighting that this package may be
rejected because of the unrelated transaction(s) B.

The way I see this, an attacker can abuse this rule to ensure
transaction A stays pinned in the mempool without confirming by
broadcasting a set of child transactions that reach these limits
and pay low fees (where A would be a commit tx in LN).

We had to create the CPFP carve-out rule explicitly to work around
this limitation, and I think it would be necessary for package RBF
as well, because in such cases we do want to be able to submit a
package A + C where C pays high fees to speed up A's confirmation,
regardless of unrelated unconfirmed children of A...

We could submit only C to benefit from the existing CPFP carve-out
rule, but that wouldn't work if our local mempool doesn't have A yet,
but other remote mempools do.

Is my concern justified? Is this something that we should dig into a
bit deeper?

Thanks,
Bastien

Le jeu. 16 sept. 2021 à 09:55, Gloria Zhao via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> a écrit :

> Hi there,
>
> I'm writing to propose a set of mempool policy changes to enable package
> validation (in preparation for package relay) in Bitcoin Core. These would
> not
> be consensus or P2P protocol changes. However, since mempool policy
> significantly affects transaction propagation, I believe this is relevant
> for
> the mailing list.
>
> My proposal enables packages consisting of multiple parents and 1 child.
> If you
> develop software that relies on specific transaction relay assumptions
> and/or
> are interested in using package relay in the future, I'm very interested
> to hear
> your feedback on the utility or restrictiveness of these package policies
> for
> your use cases.
>
> A draft implementation of this proposal can be found in [Bitcoin Core
> PR#22290][1].
>
> An illustrated version of this post can be found at
> https://gist.github.com/glozow/dc4e9d5c5b14ade7cdfac40f43adb18a.
> I have also linked the images below.
>
> ## Background
>
> Feel free to skip this section if you are already familiar with mempool
> policy
> and package relay terminology.
>
> ### Terminology Clarifications
>
> * Package = an ordered list of related transactions, representable by a
> Directed
> Acyclic Graph.
> * Package Feerate = the total modified fees divided by the total virtual
> size of
> all transactions in the package.
> - Modified fees = a transaction's base fees + fee delta applied by the
> user
> with `prioritisetransaction`. As such, we expect this to vary across
> mempools.
> - Virtual Size = the maximum of virtual sizes calculated using [BIP141
> virtual size][2] and sigop weight. [Implemented here in Bitcoin
> Core][3].
> - Note that feerate is not necessarily based on the base fees and
> serialized
> size.
>
> * Fee-Bumping = user/wallet actions that take advantage of miner
> incentives to
> boost a transaction's candidacy for inclusion in a block, including
> Child Pays
> for Parent (CPFP) and [BIP125][12] Replace-by-Fee (RBF). Our intention in
> mempool policy is to recognize when the new transaction is more economical
> to
> mine than the original one(s) but not open DoS vectors, so there are some
> limitations.
>
> ### Policy
>
> The purpose of the mempool is to store the best (to be most
> incentive-compatible
> with miners, highest feerate) candidates for inclusion in a block. Miners
> use
> the mempool to build block templates. The mempool is also useful as a
> cache for
> boosting block relay and validation performance, aiding transaction relay,
> and
> generating feerate estimations.
>
> Ideally, all consensus-valid transactions paying reasonable fees should
> make it
> to miners through normal transaction relay, without any special
> connectivity or
> relationships with miners. On the other hand, nodes do not have unlimited
> resources, and a P2P network designed to let any honest node broadcast
> their
> transactions also exposes the transaction validation engine to DoS attacks
> from
> malicious peers.
>
> As such, for unconfirmed transactions we are considering for our mempool,
> we
> apply a set of validation rules in addition to consensus, primarily to
> protect
> us from resource exhaustion and aid our efforts to keep the highest fee
> transactions. We call this mempool _policy_: a set of (configurable,
> node-specific) rules that transactions must abide by in order to be
> accepted
> into our mempool. Transaction "Standardness" rules and mempool
> restrictions such
> as "too-long-mempool-chain" are both examples of policy.
>
> ### Package Relay and Package Mempool Accept
>
> In transaction relay, we currently consider transactions one at a time for
> submission to the mempool. This creates a limitation in the node's ability
> to
> determine which transactions have the highest feerates, since we cannot
> take
> into account descendants (i.e. cannot use CPFP) until all the transactions
> are
> in the mempool. Similarly, we cannot use a transaction's descendants when
> considering it for RBF. When an individual transaction does not meet the
> mempool
> minimum feerate and the user isn't able to create a replacement transaction
> directly, it will not be accepted by mempools.
>
> This limitation presents a security issue for applications and users
> relying on
> time-sensitive transactions. For example, Lightning and other protocols
> create
> UTXOs with multiple spending paths, where one counterparty's spending path
> opens
> up after a timelock, and users are protected from cheating scenarios as
> long as
> they redeem on-chain in time. A key security assumption is that all
> parties'
> transactions will propagate and confirm in a timely manner. This
> assumption can
> be broken if fee-bumping does not work as intended.
>
> The end goal for Package Relay is to consider multiple transactions at the
> same
> time, e.g. a transaction with its high-fee child. This may help us better
> determine whether transactions should be accepted to our mempool,
> especially if
> they don't meet fee requirements individually or are better RBF candidates
> as a
> package. A combination of changes to mempool validation logic, policy, and
> transaction relay allows us to better propagate the transactions with the
> highest package feerates to miners, and makes fee-bumping tools more
> powerful
> for users.
>
> The "relay" part of Package Relay suggests P2P messaging changes, but a
> large
> part of the changes are in the mempool's package validation logic. We call
> this
> *Package Mempool Accept*.
>
> ### Previous Work
>
> * Given that mempool validation is DoS-sensitive and complex, it would be
> dangerous to haphazardly tack on package validation logic. Many efforts
> have
> been made to make mempool validation less opaque (see [#16400][4],
> [#21062][5],
> [#22675][6], [#22796][7]).
> * [#20833][8] Added basic capabilities for package validation, test
> accepts only
> (no submission to mempool).
> * [#21800][9] Implemented package ancestor/descendant limit checks for
> arbitrary
> packages. Still test accepts only.
> * Previous package relay proposals (see [#16401][10], [#19621][11]).
>
> ### Existing Package Rules
>
> These are in master as introduced in [#20833][8] and [#21800][9]. I'll
> consider
> them as "given" in the rest of this document, though they can be changed,
> since
> package validation is test-accept only right now.
>
> 1. A package cannot exceed `MAX_PACKAGE_COUNT=25` count and
> `MAX_PACKAGE_SIZE=101KvB` total size [8]
>
> *Rationale*: This is already enforced as mempool ancestor/descendant
> limits.
> Presumably, transactions in a package are all related, so exceeding this
> limit
> would mean that the package can either be split up or it wouldn't pass this
> mempool policy.
>
> 2. Packages must be topologically sorted: if any dependencies exist between
> transactions, parents must appear somewhere before children. [8]
>
> 3. A package cannot have conflicting transactions, i.e. none of them can
> spend
> the same inputs. This also means there cannot be duplicate transactions.
> [8]
>
> 4. When packages are evaluated against ancestor/descendant limits in a test
> accept, the union of all of their descendants and ancestors is considered.
> This
> is essentially a "worst case" heuristic where every transaction in the
> package
> is treated as each other's ancestor and descendant. [8]
> Packages for which ancestor/descendant limits are accurately captured by
> this
> heuristic: [19]
>
> There are also limitations such as the fact that CPFP carve out is not
> applied
> to package transactions. #20833 also disables RBF in package validation;
> this
> proposal overrides that to allow packages to use RBF.
>
> ## Proposed Changes
>
> The next step in the Package Mempool Accept project is to implement
> submission
> to mempool, initially through RPC only. This allows us to test the
> submission
> logic before exposing it on P2P.
>
> ### Summary
>
> - Packages may contain already-in-mempool transactions.
> - Packages are 2 generations, Multi-Parent-1-Child.
> - Fee-related checks use the package feerate. This means that wallets can
> create a package that utilizes CPFP.
> - Parents are allowed to RBF mempool transactions with a set of rules
> similar
> to BIP125. This enables a combination of CPFP and RBF, where a
> transaction's descendant fees pay for replacing mempool conflicts.
>
> There is a draft implementation in [#22290][1]. It is WIP, but feedback is
> always welcome.
>
> ### Details
>
> #### Packages May Contain Already-in-Mempool Transactions
>
> A package may contain transactions that are already in the mempool. We
> remove
> ("deduplicate") those transactions from the package for the purposes of
> package
> mempool acceptance. If a package is empty after deduplication, we do
> nothing.
>
> *Rationale*: Mempools vary across the network. It's possible for a parent
> to be
> accepted to the mempool of a peer on its own due to differences in policy
> and
> fee market fluctuations. We should not reject or penalize the entire
> package for
> an individual transaction as that could be a censorship vector.
>
> #### Packages Are Multi-Parent-1-Child
>
> Only packages of a specific topology are permitted. Namely, a package is
> exactly
> 1 child with all of its unconfirmed parents. After deduplication, the
> package
> may be exactly the same, empty, 1 child, 1 child with just some of its
> unconfirmed parents, etc. Note that it's possible for the parents to be
> indirect
> descendants/ancestors of one another, or for parent and child to share a
> parent,
> so we cannot make any other topology assumptions.
>
> *Rationale*: This allows for fee-bumping by CPFP. Allowing multiple parents
> makes it possible to fee-bump a batch of transactions. Restricting
> packages to a
> defined topology is also easier to reason about and simplifies the
> validation
> logic greatly. Multi-parent-1-child allows us to think of the package as
> one big
> transaction, where:
>
> - Inputs = all the inputs of parents + inputs of the child that come from
> confirmed UTXOs
> - Outputs = all the outputs of the child + all outputs of the parents that
> aren't spent by other transactions in the package
>
> Examples of packages that follow this rule (variations of example A show
> some
> possibilities after deduplication): ![image][15]
>
> #### Fee-Related Checks Use Package Feerate
>
> Package Feerate = the total modified fees divided by the total virtual
> size of
> all transactions in the package.
>
> To meet the two feerate requirements of a mempool, i.e., the pre-configured
> minimum relay feerate (`minRelayTxFee`) and dynamic mempool minimum
> feerate, the
> total package feerate is used instead of the individual feerate. The
> individual
> transactions are allowed to be below feerate requirements if the package
> meets
> the feerate requirements. For example, the parent(s) in the package can
> have 0
> fees but be paid for by the child.
>
> *Rationale*: This can be thought of as "CPFP within a package," solving the
> issue of a parent not meeting minimum fees on its own. This allows L2
> applications to adjust their fees at broadcast time instead of
> overshooting or
> risking getting stuck/pinned.
>
> We use the package feerate of the package *after deduplication*.
>
> *Rationale*: It would be incorrect to use the fees of transactions that
> are
> already in the mempool, as we do not want a transaction's fees to be
> double-counted for both its individual RBF and package RBF.
>
> Examples F and G [14] show the same package, but P1 is submitted
> individually before
> the package in example G. In example F, we can see that the 300vB package
> pays
> an additional 200sat in fees, which is not enough to pay for its own
> bandwidth
> (BIP125#4). In example G, we can see that P1 pays enough to replace M1, but
> using P1's fees again during package submission would make it look like a
> 300sat
> increase for a 200vB package. Even including its fees and size would not be
> sufficient in this example, since the 300sat looks like enough for the
> 300vB
> package. The calculcation after deduplication is 100sat increase for a
> package
> of size 200vB, which correctly fails BIP125#4. Assume all transactions
> have a
> size of 100vB.
>
> #### Package RBF
>
> If a package meets feerate requirements as a package, the parents in the
> transaction are allowed to replace-by-fee mempool transactions. The child
> cannot
> replace mempool transactions. Multiple transactions can replace the same
> transaction, but in order to be valid, none of the transactions can try to
> replace an ancestor of another transaction in the same package (which
> would thus
> make its inputs unavailable).
>
> *Rationale*: Even if we are using package feerate, a package will not
> propagate
> as intended if RBF still requires each individual transaction to meet the
> feerate requirements.
>
> We use a set of rules slightly modified from BIP125 as follows:
>
> ##### Signaling (Rule #1)
>
> All mempool transactions to be replaced must signal replaceability.
>
> *Rationale*: Package RBF signaling logic should be the same for package
> RBF and
> single transaction acceptance. This would be updated if single transaction
> validation moves to full RBF.
>
> ##### New Unconfirmed Inputs (Rule #2)
>
> A package may include new unconfirmed inputs, but the ancestor feerate of
> the
> child must be at least as high as the ancestor feerates of every
> transaction
> being replaced. This is contrary to BIP125#2, which states "The replacement
> transaction may only include an unconfirmed input if that input was
> included in
> one of the original transactions. (An unconfirmed input spends an output
> from a
> currently-unconfirmed transaction.)"
>
> *Rationale*: The purpose of BIP125#2 is to ensure that the replacement
> transaction has a higher ancestor score than the original transaction(s)
> (see
> [comment][13]). Example H [16] shows how adding a new unconfirmed input
> can lower the
> ancestor score of the replacement transaction. P1 is trying to replace M1,
> and
> spends an unconfirmed output of M2. P1 pays 800sat, M1 pays 600sat, and M2
> pays
> 100sat. Assume all transactions have a size of 100vB. While, in isolation,
> P1
> looks like a better mining candidate than M1, it must be mined with M2, so
> its
> ancestor feerate is actually 4.5sat/vB. This is lower than M1's ancestor
> feerate, which is 6sat/vB.
>
> In package RBF, the rule analogous to BIP125#2 would be "none of the
> transactions in the package can spend new unconfirmed inputs." Example J
> [17] shows
> why, if any of the package transactions have ancestors, package feerate is
> no
> longer accurate. Even though M2 and M3 are not ancestors of P1 (which is
> the
> replacement transaction in an RBF), we're actually interested in the entire
> package. A miner should mine M1 which is 5sat/vB instead of M2, M3, P1,
> P2, and
> P3, which is only 4sat/vB. The Package RBF rule cannot be loosened to only
> allow
> the child to have new unconfirmed inputs, either, because it can still
> cause us
> to overestimate the package's ancestor score.
>
> However, enforcing a rule analogous to BIP125#2 would not only make
> Package RBF
> less useful, but would also break Package RBF for packages with parents
> already
> in the mempool: if a package parent has already been submitted, it would
> look
> like the child is spending a "new" unconfirmed input. In example K [18],
> we're
> looking to replace M1 with the entire package including P1, P2, and P3. We
> must
> consider the case where one of the parents is already in the mempool (in
> this
> case, P2), which means we must allow P3 to have new unconfirmed inputs.
> However,
> M2 lowers the ancestor score of P3 to 4.3sat/vB, so we should not replace
> M1
> with this package.
>
> Thus, the package RBF rule regarding new unconfirmed inputs is less strict
> than
> BIP125#2. However, we still achieve the same goal of requiring the
> replacement
> transactions to have a ancestor score at least as high as the original
> ones. As
> a result, the entire package is required to be a higher feerate mining
> candidate
> than each of the replaced transactions.
>
> Another note: the [comment][13] above the BIP125#2 code in the original RBF
> implementation suggests that the rule was intended to be temporary.
>
> ##### Absolute Fee (Rule #3)
>
> The package must increase the absolute fee of the mempool, i.e. the total
> fees
> of the package must be higher than the absolute fees of the mempool
> transactions
> it replaces. Combined with the CPFP rule above, this differs from BIP125
> Rule #3
> - an individual transaction in the package may have lower fees than the
> transaction(s) it is replacing. In fact, it may have 0 fees, and the
> child
> pays for RBF.
>
> ##### Feerate (Rule #4)
>
> The package must pay for its own bandwidth; the package feerate must be
> higher
> than the replaced transactions by at least minimum relay feerate
> (`incrementalRelayFee`). Combined with the CPFP rule above, this differs
> from
> BIP125 Rule #4 - an individual transaction in the package can have a lower
> feerate than the transaction(s) it is replacing. In fact, it may have 0
> fees,
> and the child pays for RBF.
>
> ##### Total Number of Replaced Transactions (Rule #5)
>
> The package cannot replace more than 100 mempool transactions. This is
> identical
> to BIP125 Rule #5.
>
> ### Expected FAQs
>
> 1. Is it possible for only some of the package to make it into the mempool?
>
> Yes, it is. However, since we evict transactions from the mempool by
> descendant score and the package child is supposed to be sponsoring the
> fees of
> its parents, the most common scenario would be all-or-nothing. This is
> incentive-compatible. In fact, to be conservative, package validation
> should
> begin by trying to submit all of the transactions individually, and only
> use the
> package mempool acceptance logic if the parents fail due to low feerate.
>
> 2. Should we allow packages to contain already-confirmed transactions?
>
> No, for practical reasons. In mempool validation, we actually aren't
> able to
> tell with 100% confidence if we are looking at a transaction that has
> already
> confirmed, because we look up inputs using a UTXO set. If we have
> historical
> block data, it's possible to look for it, but this is inefficient, not
> always
> possible for pruning nodes, and unnecessary because we're not going to do
> anything with the transaction anyway. As such, we already have the
> expectation
> that transaction relay is somewhat "stateful" i.e. nobody should be
> relaying
> transactions that have already been confirmed. Similarly, we shouldn't be
> relaying packages that contain already-confirmed transactions.
>
> [1]: https://github.com/bitcoin/bitcoin/pull/22290
> [2]:
> https://github.com/bitcoin/bips/blob/1f0b563738199ca60d32b4ba779797fc97d040fe/bip-0141.mediawiki#transaction-size-calculations
> [3]:
> https://github.com/bitcoin/bitcoin/blob/94f83534e4b771944af7d9ed0f40746f392eb75e/src/policy/policy.cpp#L282
> [4]: https://github.com/bitcoin/bitcoin/pull/16400
> [5]: https://github.com/bitcoin/bitcoin/pull/21062
> [6]: https://github.com/bitcoin/bitcoin/pull/22675
> [7]: https://github.com/bitcoin/bitcoin/pull/22796
> [8]: https://github.com/bitcoin/bitcoin/pull/20833
> [9]: https://github.com/bitcoin/bitcoin/pull/21800
> [10]: https://github.com/bitcoin/bitcoin/pull/16401
> [11]: https://github.com/bitcoin/bitcoin/pull/19621
> [12]: https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki
> [13]:
> https://github.com/bitcoin/bitcoin/pull/6871/files#diff-34d21af3c614ea3cee120df276c9c4ae95053830d7f1d3deaf009a4625409ad2R1101-R1104
> [14]:
>
> [15]:
>
> [16]:
>
> [17]:
>
> [18]:
>
> [19]:
>
> [20]:
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210920/adec3501/attachment-0001.html>;