Rusty Russell [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2014-06-03 to 2023-03-22
💬 Posted a total of 648 messages
📚 Participated in the following categories: Bitcoin-development, softfork proposal, RFC, bitcoin-dev, BIP-draft, BIP Proposal, patch, BIP Draft, Lightning-dev, PROPOSAL, PATCH v3, BOLT RFC#1, BOLT RFC#2, BOLT Draft, PATCH, MINUTES, RELEASE, META, DRAFT, VERY ROUGH DRAFT, MODERATION
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpx

Profile Code

nprofile1qqsp80vvr30rkdgg5p7fykvxgutqkydtphh0f3zjpx8zy0jy8sw2gfgpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0ds3v4zuq

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpx

Show more details

Last Notes

2023-09-12 10:59:58

- reply

📅 Original date posted:2023-09-10
🗒️ Summary of this message: Runes are often bound to the BOLT8 nodeid for protection. The model requires two-way communication for setup but allows for experimentation and extension.
📝 Original message:
Runes today are often bound to the BOLT8 nodeid, giving both (otherwise
you need to protect your rune from being read).
I like this model *but* it requires two-way comms for setup (the HSM
tells the node its id, the node gives the HSM the rune).
Fortunately, it's trivial to support runes as an extension, and set what
the default is if they don't present one. Allows nice experimentation.
Further discussion on the gist...
Cheers!
Rusty.
Bastien TEINTURIER <bastien at acinq.fr> writes:
> 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
>>>
>>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-07-19 04:08:02

- reply

📅 Original date posted:2023-07-17
🗒️ Summary of this message: This is a proposal for a close protocol in the Lightning Network, allowing each side to indicate whether they want to omit their own output.
📝 Original message:
https://github.com/lightning/bolts/pull/1096
This is a "can't fail!" close protocol, as discussed at the NY Summit, and on @Roasbeef's wishlist. It's about as simple as I could make it: the only complexity comes from allowing each side to indicate whether they want to omit their own output.
It's "taproot ready"(TM) in the sense that shutdown is always sent to trigger it, so that can contain the nonces without any persistence requirement.
I split it into three commits for cleanliness:
1 Introduce the new protocol
2. Remove the requirement that shutdown not be sent multiple times (which was already nonsensical)
3. Remove the older protocols
The first commit is inline here, for easy review:
diff --git a/02-peer-protocol.md b/02-peer-protocol.md
index f43c686..ce859f2 100644
--- a/02-peer-protocol.md
+++ b/02-peer-protocol.md
@@ -16,6 +16,7 @@ operation, and closing.
* [Channel Close](#channel-close)
* [Closing Initiation: `shutdown`](#closing-initiation-shutdown)
* [Closing Negotiation: `closing_signed`](#closing-negotiation-closing_signed)
+ * [Closing Negotiation: `closing_complete` and `closing_sig`](#closing-negotiation-closing_complete-and-closing_sig)
* [Normal Operation](#normal-operation)
* [Forwarding HTLCs](#forwarding-htlcs)
* [`cltv_expiry_delta` Selection](#cltv_expiry_delta-selection)
@@ -584,6 +585,17 @@ Closing happens in two stages:
| |<-(?)-- closing_signed Fn----| |
+-------+ +-------+
+ +-------+ +-------+
+ | |--(1)----- shutdown ------->| |
+ | |<-(2)----- shutdown --------| |
+ | | | |
+ | | <complete all pending HTLCs> | |
+ | A | ... | B |
+ | | | |
+ | |--(3)-- closing_complete Fee->| |
+ | |<-(4)-- closing_sig ----------| |
+ +-------+ +-------+
+
### Closing Initiation: `shutdown`
Either node (or both) can send a `shutdown` message to initiate closing,
@@ -776,6 +788,83 @@ satoshis, which is possible if `dust_limit_satoshis` is below 546 satoshis).
No funds are at risk when that happens, but the channel must be force-closed as
the closing transaction will likely never reach miners.
+### Closing Negotiation: `closing_complete` and `closing_sig`
+
+Once shutdown is complete, the channel is empty of HTLCs, there are no commitments
+for which a revocation is owed, and all updates are included on both commitments,
+the final current commitment transactions will have no HTLCs.
+
+Each peer says what fee it will pay, and the other side simply signs that transaction. The only complexity comes from allowing each side to omit its own output should it be uneconomic.
+
+This process will be repeated every time a `shutdown` message is received, which allows re-negotiation.
+
+1. type: 40 (`closing_complete`)
+2. data:
+ * [`channel_id`:`channel_id`]
+ * [`u64`:`fee_satoshis`]
+ * [`u8`: `has_closer_output`]
+ * [`signature`:`signature_with_closee_output`]
+ * [`signature`:`signature_without_closee_output`]
+
+1. type: 41 (`closing_sig`)
+2. data:
+ * [`channel_id`:`channel_id`]
+ * [`u8`: `closee_output`]
+ * [`signature`:`signature`]
+
+#### Requirements
+
+Note: the details and requirements for the transaction being signed are in [BOLT 3](03-transactions.md#closing-transaction)).
+
+Both nodes:
+ - After a `shutdown` has been received, AND no HTLCs remain in either commitment transaction:
+ - SHOULD send a `closing_complete` message.
+
+The sender of `closing_complete` (aka. "the closer"):
+ - MUST set `fee_satoshis` to a fee less than or equal to its outstanding balance, rounded down to whole satoshis.
+ - SHOULD set `has_closer_output` to 0 if it considers its own remaining balance to be uneconomic.
+ - Otherwise MUST set `has_closer_output` to 1.
+ - If it sets `has_closer_output` to 1:
+ - MUST set `signature_with_closee_output` to a valid signature of a transaction with both closer and closee outputs.
+ - MUST set `signature_without_closee_output` to a valid signature of a transaction with only a closer output.
+ - Otherwise: (`has_closer_output` is 0):
+ - MUST set `signature_with_closee_output` to a valid signature of a transaction with only the closee output.
+ - MUST set `signature_without_closee_output` to a valid signature of a transaction with only the null output.
+
+The receiver of `closing_complete` (aka. "the closee"):
+ - if either `signature_with_closee_output` or `signature_without_closee_output` is not valid for the closing transactions specified in [BOLT #3](03-transactions.md#closing-transaction) OR non-compliant with LOW-S-standard rule<sup>[LOWS](https://github.com/bitcoin/bitcoin/pull/6769)</sup>:
+ - SHOULD send a `warning` and close the connection, or send an
+ `error` and fail the channel.
+ - Otherwise:
+ - MUST select one of the signatures (and thus, transactions) to respond to.
+ - SHOULD sign and broadcast that transaction.
+ - SHOULD send `closing_sig`.
+
+The sender of `closing_sig`:
+ - if it selected `signature_with_closee_output` to broadcast:
+ - MUST set `closee_output` to 1.
+ - MUST set `signature` to a valid signature on that transaction.
+ - otherwise (it selected `signature_without_closee_output`):
+ - MUST set `closee_output` to 0.
+ - MUST set `signature` to a valid signature on that transaction.
+
+The receiver of `closing_sig`:
+ - SHOULD broadcast the transaction indicated by `closee_output`.
+
+### Rationale
+
+The close protocol is designed to avoid any failure scenarios caused by fee disagreement, since each side offers to pay its own desired fee.
+
+Multiple signatures are given, so each side can choose whether it wants to include its own output. In the case of large fees and tiny channels, where neither side wants its output, the use of an OP_RETURN simply cleans up the dangling unspent transaction output. This is expected to be extremely rare.
+
+Note that there is usually no reason to pay a high fee for rapid processing, since an urgent child could pay the fee on the closing transactions' behalf.
+
+If the closer proposes a transaction which will not relay (either its own output is dust, or the fee rate it proposes is too low), it doesn't harm the closee to sign the transaction.
+
+Similarly, if the closer proposes a high fee, it doesn't harm the closee to sign the transaction, as the closer is paying.
+
+There's a slight game where each side would prefer the other side pay the fee, and proposes a minimal fee. If neither side proposes a fee which will relay, the negotiation can occur again, or the final commitment transaction can be spent. In practice, the opener has an incentive to offer a reasonable closing fee, as they would pay the fee for the commitment transaction, which also costs more to spend.
+
## Normal Operation
Once both nodes have exchanged `channel_ready` (and optionally [`announcement_signatures`](07-routing-gossip.md#the-announcement_signatures-message)), the channel can be used to make payments via Hashed Time Locked Contracts.
diff --git a/03-transactions.md b/03-transactions.md
index a8e843f..d9d194e 100644
--- a/03-transactions.md
+++ b/03-transactions.md
@@ -347,7 +347,9 @@ The witness script for the output is:
To spend this via penalty, the remote node uses a witness stack `<revocationsig> 1`, and to collect the output, the local node uses an input with nSequence `to_self_delay` and a witness stack `<local_delayedsig> 0`.
-## Closing Transaction
+## Classic Closing Transaction
+
+This variant is used for `closing_signed` messages (i.e. where `option_simple_close` is not negotiated).
Note that there are two possible variants for each node.
@@ -388,6 +390,40 @@ has been used.
There will be at least one output, if the funding amount is greater
than twice `dust_limit_satoshis`.
+## Closing Transaction
+
+This variant is used for `closing_complete` and `closing_sig` messages (i.e. where `option_simple_close` is negotiated).
+
+In this case, the node sending `closing_complete` ("the closer") pays the fees, and the sequence is set to 0xFFFFFFFD to allow RBF. The outputs are ordered as detailed in [Transaction Output Ordering](#transaction-output-ordering).
+
+Two closing transactions are always produced: one `with_closee_output` one `without_closee_output` (the non-closer chooses which to accept). `closing_complete` contains `has_closer_output` to indicate whether the closer's output is in the transactions.
+
+* version: 2
+* locktime: 0
+* txin count: 1
+ * `txin[0]` outpoint: `txid` and `output_index` from `funding_created` message
+ * `txin[0]` sequence: 0xFFFFFFFD
+ * `txin[0]` script bytes: 0
+ * `txin[0]` witness: `0 <signature_for_pubkey1> <signature_for_pubkey2>`
+
+* txout count: 1 or 2 of the following
+ * The closer output:
+ * `txout` amount: the final balance for the closer, minus `closing_complete` `fee_satoshis`, rounded down to whole satoshis.
+ * `txout` script: as specified in that closer's `scriptpubkey` in its `shutdown` message
+ * The closee output:
+ * `txout` amount: the final balance for the closer, rounded down to whole satoshis.
+ * `txout` script: as specified in that closee's `scriptpubkey` in its `shutdown` message
+ * The null output:
+ * `txout` amount: 0
+ * `txout` script: `OP_RETURN` (106).
+
+### Requirements
+
+Each node offering a signature:
+ - MUST round each output down to whole satoshis.
+ - MUST subtract the fee given by `fee_satoshis` from the closer output.
+
+
## Fees
### Fee Calculation
diff --git a/09-features.md b/09-features.md
index ba0a0c5..a4fe9c3 100644
--- a/09-features.md
+++ b/09-features.md
@@ -48,6 +48,7 @@ The Context column decodes as follows:
| 46/47 | `option_scid_alias` | Supply channel aliases for routing | IN | | [BOLT #2][bolt02-channel-ready] |
| 48/49 | `option_payment_metadata` | Payment metadata in tlv record | 9 | | [BOLT #11](11-payment-encoding.md#tagged-fields) |
| 50/51 | `option_zeroconf` | Understands zeroconf channel types | IN | `option_scid_alias` | [BOLT #2][bolt02-channel-ready] |
+| 60/61 | `option_simple_close` | Simplified closing negotiation | IN | `option_shutdown_anysegwit` | [BOLT #2][bolt02-simple-close] |
## Definitions
@@ -96,6 +97,7 @@ This work is licensed under a [Creative Commons Attribution 4.0 International Li
[bolt02-retransmit]: 02-peer-protocol.md#message-retransmission
[bolt02-open]: 02-peer-protocol.md#the-open_channel-message
+[bolt02-simple-close]: 02-peer-protocol.md#closing-negotiation-closing_complete-and-closing_sig
[bolt03-htlc-tx]: 03-transactions.md#htlc-timeout-and-htlc-success-transactions
[bolt02-shutdown]: 02-peer-protocol.md#closing-initiation-shutdown
[bolt02-channel-ready]: 02-peer-protocol.md#the-channel_ready-message

2023-07-10 21:01:44

- reply

📅 Original date posted:2023-07-06
🗒️ Summary of this message: LNbits discovered an exploit that allowed attackers to create fake balances by manipulating invoices, urging users to update their software.
📝 Original message:
Um, this is a super-weird setup AFAICT.
You generate an invoice, but you don't remember anything about it? Um,
OK, stateless invoices are a thing, but there's a metadata field for
that?
Someone pays an invoice, you don't check the place it's going (which,
y'know, signed it), you check some other field?
I've never used lnbits and I'm clearly missing something...
Thanks!
Rusty.
callebtc via Lightning-dev <lightning-dev at lists.linuxfoundation.org>
writes:
> Dear list,
>
> earlier last month, our team at LNbits discovered a rather interesting exploit which wich would enable an attacker to create balances out of thin air by abusing a quirk in how invoices are handled internally. We've patched this in LNbits version 0.10.5 and urge anyone to update ASAP if you haven't done so already. I want to describe the attack here, since my gut feeling is that carrying out the same exploit is possible in other Lightning applications. If you're working on custodial wallets, payment processors, account management software, etc. you probably want to read this.
>
> In short, the attacker was able to insert a bolt-11 payment hash of payment A into a different payment, creating a malicious invoice B that can trick the backend into believing that B == A.
>
> Here is how it goes:
>
> - Attacker creates invoice A of amount 1000 sat in LNbits
> - Attacker creates invoice B' of amount 1 sat on her own node
> - Attacker deserializes B', inserts payment_hash(A) into payment_hash(B), re-signs the invoice, and serializes it again, producing malicious invoice B
> - Attacker creates a new account in LNbits and pays B
>
> - LNbits backend uses payment_hash(B) to check whether this is an internal payment or a payment via LN
> - Backend finds A in its database since we implicitly assume that payment_hash(A) commits to A
>
> ** This is the critical part! Payment hashes do *NOT* commit to any payment details (like amount) but only to the preimage! **
>
> - Backend settles payment internally by crediting A debiting B
> - Attacker has "created" 999 sats
>
> Mitigation:
>
> The mitigation is quite simple. Backends should either use self-generated unique "checking id's" for looking up internal payments or use additional checks to make sure that the invoice details have not been messed around with (e.g., asserting amount(A) == amount(B)).
>
> Lessons:
>
> I think there are two lessons here. First, it's good to realize the level of sophistication of LN-savvy attackers. This attack clearly involves a fundamental understanding of bolt-11 and requires custom tooling to produce the malicious invoice.
>
> The second lesson is more valuable: The "payment hash" of an invoice is not a "payment" hash but merely a "preimage" hash – and nothing else. Naming this field as such increases the chance of developers implicitly assuming that the hash commits to payment details like amount, pubkey, etc. I will from now on call this simply the "preimage hash" and invite you to do so too.
>
> Best
>
> Calle
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-07-03 11:29:50

- reply

📅 Original date posted:2023-06-30
🗒️ Summary of this message: This pull request proposes to remove certain features from the code based on recent releases and node announcements, simplifying the code.
📝 Original message:
https://github.com/lightning/bolts/pull/1092
02-peer-protocol.md | 74 ++-------
03-transactions.md | 389 ---------------------------------------------------
05-onchain.md | 17 --
07-routing-gossip.md | 52 +-----
09-features.md | 30 +--
5 files changed, 48 insertions(+), 514 deletions(-)
Simplicity FTW. This PR proposes to start ignoring
(and thus, simply assuming) various features, based on recent releases
and scanning node announcments:
Removed:
* initial_routing_sync (only had an effect if gossip_queries not supported)
* option_anchor_outputs (only supported by older experimental-only CLN builds)
I looked at all node_announcements on my node. There are 449 nodes apparently running a 4-year-old LND version (features hex 2200), which have 3+ year old channels. @Roasbeef points out that they already will have their channel_updates ignored due to lack of htlc_maximum_msat which is now required by LND and CLN, at least).
Features you can now assume (you should probably still set it for now, but you can stop checking it).
* var_onion_optin (all but 6 nodes)
* gossip_queries (all but 11 nodes)
* option_data_loss_protect (all but 11 nodes)
* option_static_remotekey (all but 16 nodes)
Cheers!
Rusty.

2023-06-09 15:12:54

- reply

📅 Original date posted:2023-03-22
🗒️ Summary of this message: Posts not related to Lightning development will not be approved by the moderator. The decision will be reviewed next week.
📝 Original message:
Hi all,
All posts will be reviewed by a moderator, and I will not be
approving posts which are not directly concerned with Lightning
development.[1]
I'll review this decision sometime next week.[2]
Sorry for the inevitable latency!
Rusty.
[1] Except this one.
[2] Yeah, and I guess that one too?

2023-06-09 15:07:08

- reply

📅 Original date posted:2022-10-24
📝 Original message:
Joost Jager <joost.jager at gmail.com> writes:
> Hi list,
>
> I wanted to get back to a long-standing issue in Lightning: gaps in error
> attribution. I've posted about this before back in 2019 [1].
Hi Joost!
Thanks for writing this up fully. Core lightning also doesn't
penalize properly, because of the attribution problem: solving this lets
us penalize a channel, at least.
I want to implement this too, to make sure I understand it
correctly, but having read it twice it seems reasonable.
How about 16 hops? It's the closest power of 2 to the legacy hop
limit, and makes this 4.5k for payloads and hmacs.
There is, however, a completely different possibility if we want
to use a pre-pay scheme, which I think I've described previously. You
send N sats and a secp point; every chained secret returned earns the
forwarder 1 sat[1]. The answers of course are placed in each layer of
the onion. You know how far the onion got based on how much money you
got back on failure[2], though the error message may be corrupted.
Cheers,
Rusty.
[1] Simplest is truncate the point to a new secret key. Each node would
apply a tweak for decorrelation ofc.
[2] The best scheme is that you don't get paid unless the next node
decrypts, actually, but that needs more thought.

2023-06-09 15:06:22

- reply

📅 Original date posted:2022-06-29
📝 Original message:
Olaoluwa Osuntokun <laolu32 at gmail.com> writes:
> Hi Rusty,
>
> Thanks for the feedback!
>
>> This is over-design: if you fail to get reliable gossip, your routing will
>> suffer anyway. Nothing new here.
>
> Idk, it's pretty simple: you're already watching for closes, so if a close
> looks a certain way, it's a splice. When you see that, you can even take
> note of the _new_ channel size (funds added/removed) and update your
> pathfinding/blindedpaths/hophints accordingly.
Why spam the chain?
> If this is an over-designed solution, that I'd categorize _only_ waiting N
> blocks as wishful thinking, given we have effectively no guarantees w.r.t
> how long it'll take a message to propagate.
Sure, it's a simplification on "wait 6 blocks plus 30 minutes".
> If by routing you mean a sender, then imo still no: you don't necessarily
> need _all_ gossip, just the latest policies of the nodes you route most
> frequently to. On top of that, since you can get the latest policy each time
> you incur a routing failure, as you make payments, you'll get the latest
> policies of the nodes you care about over time. Also consider that you might
> fail to get "reliable" gossip, simply just due to your peer neighborhood
> aggressively rate limiting gossip (they only allow 1 update a day for a
> node, you updated your fee, oops, no splice msg for you).
There's no ratelimiting on new channel announcements?
> So it appears you don't agree that the "wait N blocks before you close your
> channels" isn't a fool proof solution? Why 12 blocks, why not 15? Or 144?
Because it's simple.
>>From my PoV, the whole point of even signalling that a splice is on going,
> is for the sender's/receivers: they can continue to send/recv payments over
> the channel while the splice is in process. It isn't that a node isn't
> getting any gossip, it's that if the node fails to obtain the gossip message
> within the N block period of time, then the channel has effectively closed
> from their PoV, and it may be an hour+ until it's seen as a usable (new)
> channel again.
Sure. If you want to not forget channels at all on close, that works too.
> If there isn't a 100% reliable way to signal that a splice is in progress,
> then this disincentives its usage, as routers can lose out on potential fee
> revenue, and sends/receivers may grow to favor only very long lived
> channels. IMO _only_ having a gossip message simply isn't enough: there're
> no real guarantees w.r.t _when_ all relevant parties will get your gossip
> message. So why not give them a 100% reliable on chain signal that:
> something is in progress here, stay tuned for the gossip message, whenever
> you receive that.
That's not 100% reliable at all. How long to you want for the new
gossip?
Just treat every close as signalling "stay tuned for the gossip
message". That's reliable. And simple.
Cheers,
Rusty.

2023-06-09 15:06:20

- reply

📅 Original date posted:2022-06-28
📝 Original message:
Hi Roasbeef,
This is over-design: if you fail to get reliable gossip, your routing
will suffer anyway. Nothing new here.
And if you *know* you're missing gossip, you can simply delay onchain
closures for longer: since nodes should respect the old channel ids for
a while anyway.
Matt's proposal to simply defer treating onchain closes is elegant and
minimal. We could go further and relax requirements to detect onchain
closes at all, and optionally add a perm close message.
Cheers,
Rusty.
Olaoluwa Osuntokun <laolu32 at gmail.com> writes:
> Hi y'all,
>
> This mail was inspired by this [1] spec PR from Lisa. At a high level, it
> proposes the nodes add a delay between the time they see a channel closed on
> chain, to when they remove it from their local channel graph. The motive
> here is to give the gossip message that indicates a splice is in process,
> "enough" time to propagate through the network. If a node can see this
> message before/during the splicing operation, then they'll be able relate
> the old and the new channels, meaning it's usable again by senders/receiver
> _before_ the entire chain of transactions confirms on chain.
>
> IMO, this sort of arbitrary delay (expressed in blocks) won't actually
> address the issue in practice. The proposal suffers from the following
> issues:
>
> 1. 12 blocks is chosen arbitrarily. If for w/e reason an announcement
> takes longer than 2 hours to reach the "economic majority" of
> senders/receivers, then the channel won't be able to mask the splicing
> downtime.
>
> 2. Gossip propagation delay and offline peers. These days most nodes
> throttle gossip pretty aggressively. As a result, a pair of nodes doing
> several in-flight splices (inputs become double spent or something, so
> they need to try a bunch) might end up being rate limited within the
> network, causing the splice update msg to be lost or delayed significantly
> (IIRC CLN resets these values after 24 hours). On top of that, if a peer
> is offline for too long (think mobile senders), then they may miss the
> update all together as most nodes don't do a full historical
> _channel_update_ dump anymore.
>
> In order to resolve these issues, I think instead we need to rely on the
> primary splicing signal being sourced from the chain itself. In other words,
> if I see a channel close, and a closing transaction "looks" a certain way,
> then I know it's a splice. This would be used in concert w/ any new gossip
> messages, as the chain signal is a 100% foolproof way of letting an aware
> peer know that a splice is actually happening (not a normal close). A chain
> signal doesn't suffer from any of the gossip/time related issues above, as
> the signal is revealed at the same time a peer learns of a channel
> close/splice.
>
> Assuming, we agree that a chain signal has some sort of role in the ultimate
> plans for splicing, we'd need to decide on exactly _what_ such a signal
> looks like. Off the top, a few options are:
>
> 1. Stuff something in the annex. Works in theory, but not in practice, as
> bitcoind (being the dominant full node implementation on the p2p network,
> as well as what all the miners use) treats annexes as non-standard. Also
> the annex itself might have some fundamental issues that get in the way of
> its use all together [2].
>
> 2. Re-use the anchors for this purpose. Anchor are nice as they allow for
> 1st/2nd/3rd party CPFP. As a splice might have several inputs and outputs,
> both sides will want to make sure it gets confirmed in a timely manner.
> Ofc, RBF can be used here, but that requires both sides to be online to
> make adjustments. Pre-signing can work too, but the effectiveness
> (minimizing chain cost while expediting confirmation) would be dependent
> on the fee step size.
>
> In this case, we'd use a different multi-sig output (both sides can rotate
> keys if they want to), and then roll the anchors into this splicing
> transaction. Given that all nodes on the network know what the anchor size
> is (assuming feature bit understanding), they're able to realize that it's
> actually a splice, and they don't need to remove it from the channel graph
> (yet).
>
> 3. Related to the above: just re-use the same multi-sig output. If nodes
> don't care all that much about rotating these keys, then they can just use
> the same output. This is trivially recognizable by nodes, as they already
> know the funding keys used, as they're in the channel_announcement.
>
> 4. OP_RETURN (yeh, I had to list it). Self explanatory, push some bytes in
> an OP_RETURN and use that as the marker.
>
> 5. Fiddle w/ the locktime+sequence somehow to make it identifiable to
> verifiers. This might run into some unintended interactions if the inputs
> provided have either relative or absolute lock times. There might also be
> some interaction w/ the main constructing for eltoo (uses the locktime).
>
> Of all the options, I think #2 makes the most sense: we already use anchors
> to be able to do fee bumping after-the-fact for closing transactions, so why
> not inherit them here. They make the splicing transaction slightly larger,
> so maybe #3 (or something else) is a better choice.
>
> The design space for spicing is preeetty large, so I figure the most
> productive route might be discussing isolated aspects of it at a time.
> Personally, I'm not suuuper caught up w/ what the latest design drafts are
> (aside from convos at the recent LN Dev Summit), but from my PoV, how to
> communicate the splice to other peers has been an outstanding design
> question.
>
> [1]: https://github.com/lightning/bolts/pull/1004
> [2]:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020045.html
>
> -- Laolu
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 15:06:05

- reply

📅 Original date posted:2022-05-26
📝 Original message:
Matt Corallo <lf-lists at mattcorallo.com> writes:
>>> I agree there should be *some* rough consensus, but rate-limits are a locally-enforced thing, not a
>>> global one. There will always be races and updates you reject that your peers dont, no matter the
>>> rate-limit, and while I agree we should have guidelines, we can't "just make them the same" - it
>>> both doesn't solve the problem and means we can't change them in the future.
>>
>> Sure it does! It severly limits the set divergence to race conditions
>> (down to block height divergence, in practice).
>
> Huh? There's always some line you draw, if an update happens right on the line (which they almost
> certainly often will because people want to update, and they'll update every X hours to whatever the
> rate limit is), then ~half the network will accept the update and half won't. I don't see how you
> solve this problem.
The update contains a block number. Let's say we allow an update every
100 blocks. This must be <= current block height (and presumably, newer
than height - 2016).
If you send an update number 600000, and then 600100, it will propagate.
600099 will not.
If some nodes have 600000 and others have 600099 (because you broke the
ratelimiting recommendation, *and* propagated both approx the same
time), then the network will split, sure.
We could be fascist and penalize nodes which do this, but that's
overkill unless it actually happens a lot.
Nodes which want to keep an potential update "up their sleeve" will
backdate updates by 101 blocks (everyone should do this, in fact).
As I said, this has a problem with block height differences, but that's
explicitly included in the messages so you can ignore and wait if you
want. Again, may not be a problem in practice.
>> Maybe. What's a "non-update" based sketch? Some huge percentage of
>> gossip is channel_update, so it's kind of the thing we want?
>
> Oops, maybe we're on *very* different pages, here - I mean doing sketches based on "the things that
> I received since the last sync, ie all the gossip updates from the last hour" vs doing sketches
> based on "the things I have, ie my full gossip store".
But that requires state. Full store requires none, keeping it
super-simple
Though Alex has a idea for a "include even the expired entries" then
"regenerate every N blocks" which avoids the problem that each change is
two deltas (one remove, one add), at cost of some complexity.
Cheers,
Rusty.

2023-06-09 15:05:57

- reply

📅 Original date posted:2022-04-26
📝 Original message:
We're pleased to announce the 0.11.0 release of c-lightning, named on
behalf of @SimonVrouwe.
This release is the first under the rebranded "Core Lightning" name.
(Note: binaries are labelled v0.11.0.1 due to a minor bugfix required
for reproducible builds).
Highlights for Users
====================
* We now finally support multiple live channels to the same peer!
* If we detect rust support, we'll build the cln-grpc plugin for full
native GRPC support.
* We advertize an external IP address if it's reported by two or more
peers (disable-ip-discovery or always-use-proxy disables).
* You can specify two databases with --wallet, and we'll write to both
at once (sqlite3 only).
* pay supports BOLT 11 payment metadata: we'll send it if it's in the invoice.
* New setchannel command (deprecates setchannelfee) allows setting max
and min HTLC amounts. Try lightning-cli setchannel all 0 for #zerobasefee.
* pay can be forced to exclude channels or nodes with the exclude
* Significant speedup in start times for old nodes with many historical HTLCs.
Highlights for the Network
==========================
* We send the remote node's IP address in the init message, so they can
tell what it is. (lightning/bolts#917)
* We are more aggressive in sending our own gossip to peers, to help propagation.
* Default port is set by network, so regtest and testnet defaults are
different. (lightning/bolts#968)
* We never generate legacy onions, it's always TLV.
We still forward legacy onions for now.
* We flush sockets before closing, so errors are more likely to reach the peer.
* Experimental support for announcing DNS addresses in node_announcement
(lightning/bolts#911)
Highlights for Developers
=========================
* pay has a maxfee parameter, which sets a simple LND-style upper fee
(vs using maxfeepercent and exemptfee)
* You can create invoices with only a description hash, using
deschashonly. We still store the full description, so use restraint!
* pay has deprecated paying solely by description hash: you should
provide the full description, too.
* delinvoice has a new desconly parameter to simply trim the
descriptions, but leave the rest intact.
* We have a rust crate cln-rpc to easily interact with our JSON-RPC.
* msggen tool allows easy generation of language bindings for our JSON
RPC interface.
More details can be found in the CHANGELOG.md.
Thanks to everyone for their contributions and bug reports; please keep
them coming.
Since 0.10.2, we've had 712 commits from 37 different authors over 170 days.
A special thanks goes to the 18 first time contributors (a new record!):
Aaron Dewes
Tim W
manreo
Gregory Sanders
zero fee routing
Stephen Webel
Michael Dance
Marnix
lightning-developer
kiwiidb
Jules Comte
JohnOnGit
GoofyAF
Denis Ahrens
Clay Shoaf
benthecarman
azuchi
Anand Suresh
Cheers,
Christian, Rusty, Lisa.

2023-06-09 15:05:56

- reply

📅 Original date posted:2022-04-28
📝 Original message:
Matt Corallo <lf-lists at mattcorallo.com> writes:
> On 4/26/22 11:53 PM, Rusty Russell wrote:
>> Matt Corallo <lf-lists at mattcorallo.com> writes:
>>>> This same problem will occur if *anyone* does ratelimiting, unless
>>>> *everyone* does. And with minisketch, there's a good reason to do so.
>>>
>>> None of this seems like a good argument for *not* taking the "send updates since the last sync in
>>> the minisketch" approach to reduce the damage inconsistent policies
>>> cause, though?
>>
>> You can't do this, with minisketch. You end up having to keep all the
>> ratelimited differences you're ignoring *per peer*, and then cancelling
>> them out of the minisketch on every receive or send.
>
> Hmm? I'm a bit confused, let me attempt to restate to make sure we're on the same page. What I
> *think* you said here is: "If you have a node which is rejecting a large percentage *channel*'s
> updates (on a per-channel, not per-update basis), and it tries to sync, you'll end up having to keep
> some huge set of 'I dont want any more updates for that channel' on a per-peer basis"? Or maybe you
> might have said "When you rate-limit, you have to tell your peer that you rate-limited a channel
> update and that it shouldn't add that update to its next sketch"?
OK, let's step back. Unlike Bitcoin, we can use a single sketch for
*all* peers. This is because we *can* encode enough information that
you can get useful info from the 64 bit id, and because it's expensive
to create them so you can't spam.
The more boutique per-peer handling we need, the further it gets from
this ideal;.
> The second potential thing I think you might have meant here I don't see as an issue at all? You can
> simply...let the sketch include one channel update that you ignored? See above discussion of similar
> rate-limits.
No, you need to get all the ignored ones somehow? There's so much cruft
in the sketch you can't decode it. Now you need to remember the ones
you ratelimited, and try to match other's ratelimiting.
>> So you end up doing that LND and core-lightning do, which is "pick 3
>> peers to gossip with" and tell everyone else to shut up.
>>
>> Yet the point of minisketch is robustness; you can (at cost of 1 message
>> per minute) keep in sync with an arbitrary number of peers.
>>
>> So, we might as well define a preferred ratelimit, so nodes know that
>> spamming past a certain point is not going to propagate. At the moment,
>> LND has no effective ratelimit at all, so it's a race to the bottom.
>
> I agree there should be *some* rough consensus, but rate-limits are a locally-enforced thing, not a
> global one. There will always be races and updates you reject that your peers dont, no matter the
> rate-limit, and while I agree we should have guidelines, we can't "just make them the same" - it
> both doesn't solve the problem and means we can't change them in the future.
Sure it does! It severly limits the set divergence to race conditions
(down to block height divergence, in practice).
> Ultimately, a updates-based sync is more robust in such a case - if there's some race and your peer
> accepts something you don't it may mean one more entry in the sketch one time, but it won't hang
> around forever.
>
>> We need that limit eventually, this just makes it more of a priority.
>>
>>> I'm not really
>>> sure in a world where you do "update-based-sketch" gossip sync you're any worse off than today even
>>> with different rate-limit policies, though I obviously agree there are substantial issues with the
>>> massively inconsistent rate-limit policies we see today.
>>
>> You can't really do it, since rate-limited junk overwhelms the sketch
>> really fast :(
>
> How is this any better in a non-update-based-sketch? The only way to address it is to have a bigger
> sketch, which you can do no matter the thing you're building the sketch over.
>
> Maybe lets schedule a call to get on the same page, throwing text at each other will likely not move
> very quickly.
Maybe. What's a "non-update" based sketch? Some huge percentage of
gossip is channel_update, so it's kind of the thing we want?
Cheers,
Rusty.

2023-06-09 15:05:55

- reply

📅 Original date posted:2022-04-27
📝 Original message:
Matt Corallo <lf-lists at mattcorallo.com> writes:
>> This same problem will occur if *anyone* does ratelimiting, unless
>> *everyone* does. And with minisketch, there's a good reason to do so.
>
> None of this seems like a good argument for *not* taking the "send updates since the last sync in
> the minisketch" approach to reduce the damage inconsistent policies
> cause, though?
You can't do this, with minisketch. You end up having to keep all the
ratelimited differences you're ignoring *per peer*, and then cancelling
them out of the minisketch on every receive or send.
So you end up doing that LND and core-lightning do, which is "pick 3
peers to gossip with" and tell everyone else to shut up.
Yet the point of minisketch is robustness; you can (at cost of 1 message
per minute) keep in sync with an arbitrary number of peers.
So, we might as well define a preferred ratelimit, so nodes know that
spamming past a certain point is not going to propagate. At the moment,
LND has no effective ratelimit at all, so it's a race to the bottom.
We need that limit eventually, this just makes it more of a priority.
> I'm not really
> sure in a world where you do "update-based-sketch" gossip sync you're any worse off than today even
> with different rate-limit policies, though I obviously agree there are substantial issues with the
> massively inconsistent rate-limit policies we see today.
You can't really do it, since rate-limited junk overwhelms the sketch
really fast :(
Note, we *can* actually change the ratelimit in future, either by
running two sketches (feature bit!), or by changing the rate slowly
enough that they can handle the small differences.
Cheers,
Rusty.

2023-06-09 15:05:54

- reply

📅 Original date posted:2022-04-21
📝 Original message:
Matt Corallo <lf-lists at mattcorallo.com> writes:
> Sure, if you’re rejecting a large % of channel updates in total
> you’re gonna end up hitting degenerate cases, but we can consider
> tuning the sync frequency if that becomes an issue.
Let's be clear: it's a problem.
Allowing only 1 a day, ended up with 18% of channels hitting the spam
limit. We cannot fit that many channel differences inside a set!
Perhaps Alex should post his more detailed results, but it's pretty
clear that we can't stay in sync with this many differences :(
> gossip queries is broken in at least five ways.
Naah, it's perfect if you simply want to ask "give me updates since XXX"
to get you close enough on reconnect to start using set reconciliation.
This might allow us to remove some of the other features?
But we might end up with a gossip2 if we want to enable taproot, and use
blockheight as timestamps, in which case we could probably just support
that one operation (and maybe a direct query op).
> Like eclair, we don’t bother to rate limit and don’t see any issues with it, though we will skip relaying outbound updates if we’re saturating outbound connections.
Yeah, we did as a trial, and in some cases it's become limiting. In
particular, people restarting their LND nodes once a day resulting in 2
updates per day (which, in 0.11.0, we now allow).
Cheers,
Rusty.

2023-06-09 15:05:54

- reply

📅 Original date posted:2022-04-22
📝 Original message:
Matt Corallo <lf-lists at mattcorallo.com> writes:
>> Allowing only 1 a day, ended up with 18% of channels hitting the spam
>> limit. We cannot fit that many channel differences inside a set!
>>
>> Perhaps Alex should post his more detailed results, but it's pretty
>> clear that we can't stay in sync with this many differences :(
>
> Right, the fact that most nodes don't do any limiting at all and y'all have a *very* aggressive (by
> comparison) limit is going to be an issue in any context.
I'm unable to find the post years ago where I proposed this limit
and nobody had major objections. I just volunteered to go first :)
> We could set some guidelines and improve
> things, but luckily regular-update-sync bypasses some of these issues anyway - if we sync once per
> block and your limit is once per block, getting 1000 updates per block for some channel doesn't
> result in multiple failures in the sync. Sure, multiple peers sending different updates for that
> channel can still cause some failures, but its still much better.
Nodes will want to aggressively spam as much as they can, so I think we
need a widely-agreed limit. I don't really care what it is, but
somewhere between per 1 and 1000 blocks makes sense?
Normally I'd suggest a burst, but that's bad for consensus: better to
say "just create your update N-6 blocks behind so you can always create a
new one 6 blocks behind".
>>> gossip queries is broken in at least five ways.
>>
>> Naah, it's perfect if you simply want to ask "give me updates since XXX"
>> to get you close enough on reconnect to start using set reconciliation.
>> This might allow us to remove some of the other features?
>
> Sure, but that's *just* the "gossip_timestamp_filter" message, there's several other messages and a
> whole query system that we can throw away if we just want that message :)
I agree. Removing features would be nice :)
>> But we might end up with a gossip2 if we want to enable taproot, and use
>> blockheight as timestamps, in which case we could probably just support
>> that one operation (and maybe a direct query op).
>>
>>> Like eclair, we don’t bother to rate limit and don’t see any issues with it, though we will skip relaying outbound updates if we’re saturating outbound connections.
>>
>> Yeah, we did as a trial, and in some cases it's become limiting. In
>> particular, people restarting their LND nodes once a day resulting in 2
>> updates per day (which, in 0.11.0, we now allow).
>
> What do you mean "its become limiting"? As in you hit some reasonably-low CPU/disk/bandwidth limit
> in doing this? We have a pretty aggressive bandwidth limit for this kinda stuff (well, indirect
> bandwidth limit) and it very rarely hits in my experience (unless the peer is very overloaded and
> not responding to pings, which is a somewhat separate thing...)
By rejecting more than 1 per day, some LND nodes had 50% of their
channels left disabled :(
This same problem will occur if *anyone* does ratelimiting, unless
*everyone* does. And with minisketch, there's a good reason to do so.
Cheers,
Rusty.

2023-06-09 15:05:37

- reply

📅 Original date posted:2022-03-23
📝 Original message:
Olaoluwa Osuntokun <laolu32 at gmail.com> writes:
> Hi Rusty,
>
>> Timestamps are replaced with block heights.
>
> This is a conceptually small change, but would actually make things like
> rate limiting updates for implementations easier and more uniform. A simple
> rule would be only allowing an update per block, which cuts down a lot on
> potential chatter traffic, but maybe it's _too_ restrictive? Based on my
> network observations, these days some many power user nodes more
> aggressively
> update their fee schedules in response to liquidity imbalances or as an
> attempt to incentive usage of some channels vs others.
As an aside, Alex Myers is looking at using minisketch for gossip
reconciliation, and there's enough spam in the network that it probably
requires some consensus on filtering. When he's got some better
analysis I expect a post here...
>> 1. Nodes send out weekly node_announcement_v2, proving they own some
>> UTXOs.
>
> If a node doesn't send out this announcement, then will others start to
> ignore their "channels"?
Yes, this would be the anchor (reverse of now, ignore node_announcement
unless you've seen a channel_announcement).
>> 3. This uses UTXOs for anti-spam, but doesn't tie them to channels
>> directly.
>
> As I hinted a bit in prior discussion, and also my recent ML [1] post
> outlining a possible "do most of the same things" stop gap, this has the
> potentially undesirable effect of allowing parties on the network to utilize
> _existing_ outputs to advertise false channels and inflate the "total
> network capacity" metric. We'd effectively be moving away from "Alice and
> Bob have N BTC of bound capacity between them to", "Bob has N BTC he can use
> for signing these proofs".
Since the aim is to defeat onchain analysis, this seems inevitable in
almost any non-zero-knowledge scheme?
> Also while we're at it, why not add a merkle proof here (independent of
> which direction we go with) which makes it possible for constrained/mobile
> nodes to more easily verify gossip data (could be an optional query flag).
Yeah, we should do that anyway (the merkle proof doesn't need to be
signed, so can be added by anyone).
>> FIXME: what about tapscripts?
>
> Yeah, one side effect of moving to nodes advertising how much BTC they can
> sign w/ vs the _actual_ BTC they have in "channels", is that to extend
> validation here, the verifiers would need to fully verify possible script
> path spends (assuming a scenario where a NUMs point is used as the internal
> key).
Yech, you're right :(
>> Legacy proofs are two signatures, similar to the existing
>> channel_announcement.
>
> Why not musig2? We'd be able to get away with just a single sig with this
> modified `node_announcement_v2` and if we go the `channel_announcement2`
> route, we'd be able to compress those 4 sigs into one.
Good point: I was thinking this would allow nodes to advertize v2 even
if their peer doesn't support it, but it doesn't.
>> - If two node_announcement_v2 claim the same UTXO, use the first seen,
>> discard any others.
>
> So then this would mean that nodes that _actually_ have a channel between
> them can't _individually_ claim the capacity?
Yeah, it's kind of arbitrary who gets the UTXO in that case, but for
simplicitly I think we need to enforce uniqueness. They can flip a coin?
>> - node_announcement_v2 are discarded after a week (1000 blocks). - Nodes
>> do not need to monitor existence of UTXOs after initial check (since they
>> will automatically prune them after a week).
>
> A side effect of this would be _continual_ gossip churn in order to keep
> channels alive. Today we do have the 2 week `channel_update` heart beat, but
> channel updates are relatively small compared to this `node_announcement_v2`
> message.
We could increase this to 2000 blocks, but #nodes << #channels, so it's
still probably a win? I'd have to run some real numbers though...
>> - The total proved utxo value (not counting any utxos which are spent) is
>> multiplied by 10 to give the "announcable_channel_capacity" for that node.
>
> I don't see how this is at all useful in practice. We'd end up with inflated
> numbers for the total node capacity, and path finding would be more
> difficult as it isn't clear exactly how large an HTLC I can send over the
> "channel". Sure there's the existence of max_htlc, but in that case why add
> this "leverage" factor in the first place?
Because not every node will have enough onchain funds, they'll end up
revealing some channels' UTXOs. The larger the leverage, the less
revealed...
>> 1. type: 273 (`channel_update_v2`)
>
> This seems to allow the advertisement of channels which aren't actually
> anchored in the chain, which I *think* is a cool thing to have? On the other
> hand, the graph at the _edge_ level would be far more dynamic than it is
> today (Bob can advertise an entirely distinct topology from one day to
> another). Would need to think about the implications here for path finding
> algorithms and nodes that want to maintain an update to date view of the
> network...
>
>> - `channel_id_and_claimant` is a 31-bit per-node channel_id which can be
>> used in onion_messages, and a one bit stolen for the `claim` flag.
>
> Where would this `channel_id` be derived from? FWIW, using this value in the
> onion means we get a form of pubkey based routing [3] depending on how these
> are derived.
Yeah, we could drop this altogether if we wanted; its just a unique
identifier for that specific node to refer to a peer. It saves space in
the onion, that is all.
>> This simplifies gossip, requiring only two messages instead of three,
>> and reducing the UTXO validation requirements to per-node instead of
>> per-channel.
>
> I'm not sure this would actually _simplify_ gossip in practice, given that
> we'd be moving to a channel graph that isn't entirely based in the reality
> of what's routable, and would be far more dynamic than it is today.
>
>> We can use a convention that a channel_update_v2 with no `capacity` is a
>> permanent close.
>
> On the neutrino side, we tried to do something where if we see both channels
> be disabled, then we'd mark the channel as closed. But in practice if you're
> not syncing _every_ channel update every transmitted, then you'll end up
> actually missing them.
Yeah, we may also want the 2week / 2000 block refresh here as well?
>> It also allows "leasing" of UTXOs: you could pay someone to sign their
>> UTXO for your node_announcement, with some level of trust.
>
> I'm not sure this is entirely a *good* thing, as the graph becomes more
> decoupled with the _actual_ on-chain relationships...
Which is the aim (though not sure how many ppl would do it in
practice?).
Cheers,
Rusty.
> -- Laolu
>
> [1]:
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-March/003526.html
> [2]: https://github.com/lightning/bolts/pull/814
>
>
> On Tue, Feb 15, 2022 at 12:46 AM Rusty Russell <rusty at blockstream.com>
> wrote:
>
>> Hi all,
>>
>> I've floated this idea before, but this is a more concrete
>> proposal for a "v2" gossip protocol.
>>
>> It assumes x-only pubkeys (aka point32) and BIP-340 signatures, and uses
>> modern TLVs for all optional or extensible fields. Timestamps are
>> replaced with block heights.
>>
>> 1. Nodes send out weekly node_announcement_v2, proving they own some
>> UTXOs.
>> 2. This entitles them to broadcast channels, using channel_update_v2; a
>> channel_update_v2 from both peers means the channel exists.
>> 3. This uses UTXOs for anti-spam, but doesn't tie them to channels
>> directly.
>> 4. Future ZKP proofs are could be added.
>>
>> 1. type: 271 (`node_announcement_v2`)
>> 2. data:
>> * [`bip340sig`:`signature`]
>> * [`point32`:`node_id`]
>> * [`u32`:`blockheight`]
>> * [`node_announcement_v2_tlvs`:`tlvs`]
>>
>> 1. `tlv_stream`: `node_announcement_v2_tlvs`
>> 2. types:
>> 1. type: 2 (`features`)
>> 2. data:
>> * [`...*byte`:`featurebits`]
>> 1. type: 3 (`chain_hash`)
>> 2. data:
>> * [`chain_hash`:`chain`]
>> 1. type: 4 (`taproot_utxo_proofs`)
>> 2. data:
>> * [`...*taproot_utxo_proof`:`proofs`]
>> 1. type: 6 (`legacy_utxo_proofs`)
>> 2. data:
>> * [`...*legacy_utxo_proof`:`proofs`]
>> 1. type: 127 (`ipv4_addresses`)
>> 2. data:
>> * [`...*ipv4`:`addresses`]
>> 1. type: 129 (`ipv6_addresses`)
>> 2. data:
>> * [`...*ipv6`:`addresses`]
>> 1. type: 131 (`torv3_addresses`)
>> 2. data:
>> * [`...*torv3`:`addr`]
>> # Maybe alias, color, etc?
>>
>> Taproot proofs are a signature of the v1 output over the `node_id`,
>> `utxo` and `blockheight` with prefix "lightingtaproot_utxo_proofsig"
>> (using the tagged signatures as per BOLT12). (FIXME: what about
>> tapscripts?).
>>
>> Legacy proofs are two signatures, similar to the existing
>> channel_announcement.
>>
>> 1. subtype: `taproot_utxo_proof`
>> 2. data:
>> * [`short_channel_id`:`utxo`]
>> * [`signature`:`sig`]
>>
>> 1. subtype: `legacy_utxo_proof`
>> 2. data:
>> * [`short_channel_id`:`utxo`]
>> * [`point`:`bitcoin_key_1`]
>> * [`point`:`bitcoin_key_2`]
>> * [`signature`:`sig_1`]
>> * [`signature`:`sig_2`]
>>
>> - node_announcement_v2 are discarded after a week (1000 blocks).
>> - If two node_announcement_v2 claim the same UTXO, use the first seen,
>> discard any others.
>> - Nodes do not need to monitor existence of UTXOs after initial check
>> (since
>> they will automatically prune them after a week).
>> - The total proved utxo value (not counting any utxos which are spent)
>> is multiplied by 10 to give the "announcable_channel_capacity" for that
>> node.
>>
>> 1. type: 273 (`channel_update_v2`)
>> 2. data:
>> * [`bip340sig`:`signature`]
>> * [`point32`:`local_node_id`]
>> * [`point32`:`remote_node_id`]
>> * [`u32`:`blockheight`]
>> * [`u32`:`channel_id_and_claimant`]
>> * [`channel_update_v2_tlvs`:`tlvs`]
>>
>> 1. `tlv_stream`: `channel_update_v2_tlvs`
>> 2. types:
>> 1. type: 2 (`features`)
>> 2. data:
>> * [`...*byte`:`featurebits`]
>> 1. type: 3 (`chain_hash`)
>> 2. data:
>> * [`chain_hash`:`chain`]
>> 1. type: 4 (`capacity`)
>> 2. data:
>> * [`tu64`:`satoshis`]
>> 1. type: 5 (`cost`)
>> 2. data:
>> * [`u16`:`cltv_expiry_delta`]
>> * [`u32`:`fee_proportional_millionths`]
>> * [`tu32`:`fee_base_msat`]
>> 1. type: 6 (`min_msat`)
>> 2. data:
>> * [`tu64`:`min_htlc_sats`]
>>
>> - `channel_id_and_claimant` is a 31-bit per-node channel_id which can be
>> used in onion_messages, and a one bit stolen for the `claim` flag.
>> - A channel is not considered to exist until both peers have sent a
>> channel_update_v2, at least one of which must set the `claim` flag.
>> - If a node sets `claim`, the capacity of the channel is subtracted from
>> the remaining announcable_channel_capacity for that node (minimum
>> 10,000 sats).
>> - If there is insufficient total `announcable_channel_capacity` for a
>> node, it is used by the lower `channel_id`s first.
>>
>> Implications
>> ------------
>>
>> This simplifies gossip, requiring only two messages instead of three,
>> and reducing the UTXO validation requirements to per-node instead of
>> per-channel. We can use a convention that a channel_update_v2 with no
>> `capacity` is a permanent close.
>>
>> We might want to add a taproot_utxo_delegated_proof where UTXOs can
>> sign over to another key, so cold storage only needs to sign once, and
>> the other key can sign weekly.
>>
>> It also allows "leasing" of UTXOs: you could pay someone to sign their
>> UTXO for your node_announcement, with some level of trust. They could
>> spend the UTXO, which gives you a slow degredation as new nodes don't
>> accept your channels but existing nodes don't check until it's due for a
>> refresh). Or they could sign one UTXO for multiple node_announcements,
>> which is why preference is given to the first-seen. But it's a weekly
>> business so there's incentive for them not to.
>>
>> Between nodes there's the question of "who claims this new channel?",
>> which I didn't address here. Opener claims is logical, but leaks
>> information (though you could definitely pay for the peer to claim it).
>> With dual-funding, it's more complex (some kind of proportional coinflip
>> protocol is possible), but basically you can always wait for your peer,
>> and if they don't set the claim bit you can.
>>
>> Cheers!
>> Rusty.
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>

2023-06-09 15:05:19

- reply

📅 Original date posted:2022-02-20
📝 Original message:
ZmnSCPxj <ZmnSCPxj at protonmail.com> writes:
> Good morning rusty,
>
> If we are going to switch to a new gossip version, should we prepare now for published channels that are backed by channel factories?
This is already true with the new proposal: channels don't have to be
"real". It's possible to raise the required ratio later, so less UTXO
proof is required (since channels are prioritized by their id, you can
choose which ones older nodes will see.
Cheers,
Rusty.

2023-06-09 15:05:19

- reply

📅 Original date posted:2022-02-16
📝 Original message:
Joost Jager <joost.jager at gmail.com> writes:
> Hi Rusty,
>
> Nice to see the proposal in more concrete terms. Few questions:
>
> - The total proved utxo value (not counting any utxos which are spent)
>> is multiplied by 10 to give the "announcable_channel_capacity" for that
>> node.
>>
>
> Could this work as a dynamic value too, similar to the minimum relay fee on
> L1?
I made the number up, so I'm not very attached to it. How would we
choose to scale it though? If nodes don't use the same value it makes
for wasted gossip (and minisketch-based gossip much harder).
>> 1. `tlv_stream`: `channel_update_v2_tlvs`
>>
> 2. types:
>> 1. type: 4 (`capacity`)
>> 2. data:
>> * [`tu64`:`satoshis`]
>>
>
> What does capacity mean exactly outside the context of a real channel? Will
> this be reduced to that maximum htlc amount that the nodes want to route,
> to save as much of the announceable budget as possible?
Yes, it's the old htlc_maximum_msat, but expressed in satoshis because
msat seems to finegrained?
> It is also the question of whether 10 x 10k channels should weigh as much
> on the budget as a 1 x 100k channel. A spammer may be able to do more harm
> with multiple smaller channels because there is more for the sender's
> pathfinding algorithms to explore. Maybe it doesn't matter as long as there
> is some mechanism to discourage spam.
Yes, I suggested a minimum cost to avoid 100k 1sat channels, I don't
know if we should be more sophisticated.
>> 1. type: 5 (`cost`)
>> 2. data:
>> * [`u16`:`cltv_expiry_delta`]
>> * [`u32`:`fee_proportional_millionths`]
>> * [`tu32`:`fee_base_msat`]
>> 1. type: 6 (`min_msat`)
>> 2. data:
>> * [`tu64`:`min_htlc_sats`]
>>
>> - `channel_id_and_claimant` is a 31-bit per-node channel_id which can be
>> used in onion_messages, and a one bit stolen for the `claim` flag.
>
> If you'd increase the budget multiplier from 10 to 20, couldn't this be
> simplified to always applying the cost to both nodes?
Yes! I forgot that capacity doesn't have to be symmetrical; if I open a
giant channel with you, and you don't want to expose more UTXOs, you
just set your capacity to some lower value.
>> - A channel is not considered to exist until both peers have sent a
>> channel_update_v2, at least one of which must set the `claim` flag.
>> - If a node sets `claim`, the capacity of the channel is subtracted from
>> the remaining announcable_channel_capacity for that node (minimum
>> 10,000 sats).
>
> Same question about magic value and whether it can be dynamic.
Yes, 10ksat might be giant one day? We can change it naively with a
feature bit ("I use v2 capacity calcs"), or in some more finegrained
way, but what do we base it on?
Cheers!
Rusty.

2023-06-09 15:05:18

- reply

📅 Original date posted:2022-02-13
📝 Original message:
Hi all,
I've floated this idea before, but this is a more concrete
proposal for a "v2" gossip protocol.
It assumes x-only pubkeys (aka point32) and BIP-340 signatures, and uses
modern TLVs for all optional or extensible fields. Timestamps are
replaced with block heights.
1. Nodes send out weekly node_announcement_v2, proving they own some
UTXOs.
2. This entitles them to broadcast channels, using channel_update_v2; a
channel_update_v2 from both peers means the channel exists.
3. This uses UTXOs for anti-spam, but doesn't tie them to channels
directly.
4. Future ZKP proofs are could be added.
1. type: 271 (`node_announcement_v2`)
2. data:
* [`bip340sig`:`signature`]
* [`point32`:`node_id`]
* [`u32`:`blockheight`]
* [`node_announcement_v2_tlvs`:`tlvs`]
1. `tlv_stream`: `node_announcement_v2_tlvs`
2. types:
1. type: 2 (`features`)
2. data:
* [`...*byte`:`featurebits`]
1. type: 3 (`chain_hash`)
2. data:
* [`chain_hash`:`chain`]
1. type: 4 (`taproot_utxo_proofs`)
2. data:
* [`...*taproot_utxo_proof`:`proofs`]
1. type: 6 (`legacy_utxo_proofs`)
2. data:
* [`...*legacy_utxo_proof`:`proofs`]
1. type: 127 (`ipv4_addresses`)
2. data:
* [`...*ipv4`:`addresses`]
1. type: 129 (`ipv6_addresses`)
2. data:
* [`...*ipv6`:`addresses`]
1. type: 131 (`torv3_addresses`)
2. data:
* [`...*torv3`:`addr`]
# Maybe alias, color, etc?
Taproot proofs are a signature of the v1 output over the `node_id`,
`utxo` and `blockheight` with prefix "lightingtaproot_utxo_proofsig"
(using the tagged signatures as per BOLT12). (FIXME: what about
tapscripts?).
Legacy proofs are two signatures, similar to the existing
channel_announcement.
1. subtype: `taproot_utxo_proof`
2. data:
* [`short_channel_id`:`utxo`]
* [`signature`:`sig`]
1. subtype: `legacy_utxo_proof`
2. data:
* [`short_channel_id`:`utxo`]
* [`point`:`bitcoin_key_1`]
* [`point`:`bitcoin_key_2`]
* [`signature`:`sig_1`]
* [`signature`:`sig_2`]
- node_announcement_v2 are discarded after a week (1000 blocks).
- If two node_announcement_v2 claim the same UTXO, use the first seen,
discard any others.
- Nodes do not need to monitor existence of UTXOs after initial check (since
they will automatically prune them after a week).
- The total proved utxo value (not counting any utxos which are spent)
is multiplied by 10 to give the "announcable_channel_capacity" for that node.
1. type: 273 (`channel_update_v2`)
2. data:
* [`bip340sig`:`signature`]
* [`point32`:`local_node_id`]
* [`point32`:`remote_node_id`]
* [`u32`:`blockheight`]
* [`u32`:`channel_id_and_claimant`]
* [`channel_update_v2_tlvs`:`tlvs`]
1. `tlv_stream`: `channel_update_v2_tlvs`
2. types:
1. type: 2 (`features`)
2. data:
* [`...*byte`:`featurebits`]
1. type: 3 (`chain_hash`)
2. data:
* [`chain_hash`:`chain`]
1. type: 4 (`capacity`)
2. data:
* [`tu64`:`satoshis`]
1. type: 5 (`cost`)
2. data:
* [`u16`:`cltv_expiry_delta`]
* [`u32`:`fee_proportional_millionths`]
* [`tu32`:`fee_base_msat`]
1. type: 6 (`min_msat`)
2. data:
* [`tu64`:`min_htlc_sats`]
- `channel_id_and_claimant` is a 31-bit per-node channel_id which can be
used in onion_messages, and a one bit stolen for the `claim` flag.
- A channel is not considered to exist until both peers have sent a
channel_update_v2, at least one of which must set the `claim` flag.
- If a node sets `claim`, the capacity of the channel is subtracted from
the remaining announcable_channel_capacity for that node (minimum
10,000 sats).
- If there is insufficient total `announcable_channel_capacity` for a
node, it is used by the lower `channel_id`s first.
Implications
------------
This simplifies gossip, requiring only two messages instead of three,
and reducing the UTXO validation requirements to per-node instead of
per-channel. We can use a convention that a channel_update_v2 with no
`capacity` is a permanent close.
We might want to add a taproot_utxo_delegated_proof where UTXOs can
sign over to another key, so cold storage only needs to sign once, and
the other key can sign weekly.
It also allows "leasing" of UTXOs: you could pay someone to sign their
UTXO for your node_announcement, with some level of trust. They could
spend the UTXO, which gives you a slow degredation as new nodes don't
accept your channels but existing nodes don't check until it's due for a
refresh). Or they could sign one UTXO for multiple node_announcements,
which is why preference is given to the first-seen. But it's a weekly
business so there's incentive for them not to.
Between nodes there's the question of "who claims this new channel?",
which I didn't address here. Opener claims is logical, but leaks
information (though you could definitely pay for the peer to claim it).
With dual-funding, it's more complex (some kind of proportional coinflip
protocol is possible), but basically you can always wait for your peer,
and if they don't set the claim bit you can.
Cheers!
Rusty.

2023-06-09 15:05:03

- reply

📅 Original date posted:2022-01-24
📝 Original message:
Christian Decker <decker.christian at gmail.com> writes:
>> I noticed the commando c-lightning plugin just uses the JSON-RPC
>> payload, but perhaps something more compact and rpc-friendly like grpc
>> would be better... which is why this cln-grpc PR peaked my curiosity.
>
> Yep, JSON-RPC is rather bad with binary data, and doesn't have any
> concept of streaming. I personally like grpc because it ticks a lot of
> boxes: secure transport over TLS, mutual authentication via mTLS,
> possibility to add metadata to calls (technically prohibited by the
> JSON-RPC spec) which can help us use macaroons/runes in future,
> streaming support and compact binary format.
The rest is true, but spec doesn't disallow extra fields that I can
find?
> Having an IDL to describe the interface is also rather nice, even though
> for cln-grpc we actually generate that from the JSON-RPC schemas, so
> it's a bit less expressive than .proto files.
>
>> I think the end goal of an RPC bolt would be super powerful, so that
>> lnsocket could talk to any lightning node, but that could be further
>> down the line. Choosing the right data format seemed like an important
>> step in that direction. Would love to hear your thoughts on this!
>
> I agree. Exchanging the transport layer underneath grpc doesn't change
> semantics, but does unlock a number of potential use-cases. I think
> either the JSON-RPC or grpc can serve as a basis for a common RPC
> definition that can have any number of bindings, since we generate
> conversion code to/from JSON-RPC and grpc we can transparently map them
> back and forth.
Yeah, I don't think we'll end up with a control standard. But I've been
pleasantly surprised before: certainly a common subset would be nice!
Cheers!
Rusty.

2023-06-09 15:03:00

- reply

📅 Original date posted:2021-07-05
📝 Original message:
ZmnSCPxj <ZmnSCPxj at protonmail.com> writes:
> Mostly nitpick on terminology below, but I think text substantially like the above should exist in some kind of "rationale" section in the BOLT, so ---
>
> In light of dual-funding we should avoid "funder" and "fundee" in favor of "initiator" and "acceptor".
Yes, Lisa has a patch for this in her spec PR :)
> So what matters for the above rationale is the "sender" of an HTLC and the "receiver" of an HTLC, not really who is acceptor or initiator.
>
> * Risks for HTLC sender is that the channel never confirms, but it probably ignores the risk because it can close onchain (annoying, and fee-heavy, but not loss of funds caused by peer).
> * Risks for HTLC receiver is that the channel never confirms, so HTLC must not be routed out to others or resolved locally if the receiver already knows the preimage, UNLESS the HTLC receiver has some *other* reason to trust the peer.
This misses an important case: even with the dual-funding prototol,
single-sided funding is more common.
So:
- if your peer hasn't contributed funds:
- You are in control, channel is safe (modulo your own conf issues)
- if the peer has contributed funds:
- You can send, since cancellation just gives you a free refund (if
you contributed anything at all).
- You should not route an incoming HTLCs (unless you trust peer)
Cheers,
Rusty.

2023-06-09 15:03:00

- reply

📅 Original date posted:2021-07-04
📝 Original message:
Matt Corallo <lf-lists at mattcorallo.com> writes:
> Thanks!
>
> On 6/29/21 01:34, Rusty Russell wrote:
>> Hi all!
>>
>> John Carvalo recently pointed out that not every implementation
>> accepts zero-conf channels, but they are useful. Roasbeef also recently
>> noted that they're not spec'd.
>>
>> How do you all do it? Here's a strawman proposal:
>>
>> 1. Assign a new feature bit "I accept zeroconf channels".
>> 2. If both negotiate this, you can send update_add_htlc (etc) *before*
>> funding_locked without the peer getting upset.
>
> Does it make sense to negotiate this per-direction in the channel init message(s)? There's a pretty different threat
> model between someone spending a dual-funded or push_msat balance vs someone spending a classic channel-funding balance.
channel_types fixes this :)
Until then, I'd say keep it simple. I would think that c-lightning will
implement the "don't route from non-locked-in channels" and always
advertize this option. That means we're always offering zero-conf
channels, but that seems harmless:
- Risks for funder is that channel never confirms, but it probably ignores
the risk because it can close onchain (annoying, and fee-heavy, but not
loss of funds caused by peer).
- Risks for fundee (or DF channels where peer contributes any funds) is
that funder doublespends, so HTLCs must not be routed out to others
(unless you have other reason to trust peer).
Cheers,
Rusty.

2023-06-09 15:02:27

- reply

📅 Original date posted:2021-05-09
📝 Original message:
Just a quick note that I have a signficant simplification of this,
because I started implementing and I hated it.
This time I'll finish implementing it before I post the spec :)
Cheers,
Rusty.

2023-06-09 15:02:26

- reply

📅 Original date posted:2021-05-04
📝 Original message:
Matt Corallo <lf-lists at mattcorallo.com> writes:
> On 4/27/21 01:04, Rusty Russell wrote:
>> Matt Corallo <lf-lists at mattcorallo.com> writes:
>>>> On Apr 24, 2021, at 01:56, Rusty Russell <rusty at rustcorp.com.au> wrote:
>>>>
>>>> Matt Corallo <lf-lists at mattcorallo.com> writes:
>>> I promise it’s much less work than it sounds like, and avoids having to debug these things based on logs, which is a huge pain :). Definitely less work than a new state machine:).
>>
>> But the entire point of this proposal is that it's a subset of the
>> existing state machine?
>
> Compared to today, its a good chunk of additional state machine logic to enforce when a message can or can not be sent,
> and additional logic for when we can (or can not) flush any pending
> changes buffer(s)
Kind of. I mean, we can add a "update_noop" message which simply
requests your turn and has no other effects.
>> The only "twist" is that if it's your turn and you receive an update,
>> you can either reply with a "yield" message, or ignore it.
>
> How do you handle the "no changes to make" case - do you send yields back and forth ever Nms all day long or is there
> some protocol by which you resolve it when both parties try to claim turn at once?
You don't do anything?
If you want to send an update:
1. If it is your turn, send it.
2. If it is not your turn, send it and wait for either a `yield`, or a
different update. In the former case, it's now your turn, in the
latter case it's not and your update was ignored.
If you receive an update when it's your turn:
1. If you've sent an update already, ignore it.
2. Otherwise, send `yield`.
>>> Isn’t that pretty similar? Discard one splice proposal deterministically (ok that’s new) and the loser has to store their proposal in a holding cell for later (which they have to do in turn-based anyway). Logic to check if there’s unsettled things in RAA handling is pretty similar to turn-based, and logic to reject other messages is the same as shutdown handling today.
>>
>> Nope, with the simplified protocol you can `update_splice` at any time
>> instead of your normal update, since both sides are already in sync.
>
> Hmm, I'm somewhat failing to understand why its that different - you can only update_splice if its your turn, which is
> about exactly the same amount of additional logic to check turn conditions as just flag "want to do splice". Either way
> you have the same pending splice buffer.
No, for turn-taking, this case is exactly like any other update.
For non-turn taking, we need an explicit quiescence protocol, and to
handle simultanous splicing.
>>>> - MUST use the higher of the two `funding_feerate_perkw` as the feerate for
>>>> the splice.
>>>
>>> If we like turn based, why not just deterministic throw out one slice? :)
>>
>> Because while I am going to implement turn-based, I'm not sure if anyone
>> else is. I guess we'll see?
>
> My point was more that its similar in logic - if you throw out the splice deterministically and just keep it in some
> "pending slice" buffer on the sending side, you've just done basically what you'd do to implement turns, while keeping
> the non-turn slice protocol a bit easier :).
No, you really haven't. Right now you can have Alice propose a splice
while Bob proposes at the same time, so we have a tiebreak protocol.
And you can have Alice propose a splice while Bob proposes a different
update which needs to be completely resolved before the splice can
continue.
Whereas in turn taking, when someone proposes a splice, that's what
you're doing, as soon as it is received. And when someone wants to
propose a splice, they can do it as soon as it's their turn. If it's
not their turn and the other side proposes a splice, they can jump onto
that (happy days, since the splice proposer pays for 1 input 1 output
and the core of the tx!).
Cheers,
Rusty.

2023-06-09 15:02:24

- reply

📅 Original date posted:2021-04-24
📝 Original message:
Joost Jager <joost.jager at gmail.com> writes:
>>
>> But Joost pointed out that you need to know the node_id of the next node
>> though: this isn't quite true, since if the node_id is wrong the spec
>> says you should send an `update_fail_malformed_htlc` with failure code
>> invalid_onion_hmac, which node N turns into its own failure message.
>> Perhaps it should convert it to `unknown_next_peer` instead? This isn't
>> a common error on the modern network; I think our onion implementations
>> have been rock solid.
>>
>
> Isn't this what I am suggesting here?
> https://twitter.com/joostjgr/status/1385150318959341569
Oops, I didn't read the second part of your tweet properly.
Sorry: this was right there indeed.
Thanks!
Rusty.

2023-06-09 15:02:24

- reply

📅 Original date posted:2021-04-24
📝 Original message:
Hi all,
You can currently probe for a channel id attached to node N by
sending an HTLC, and seeing whether the error reply comes from the N or
the next hop. The real answer is to get back to blinded paths, BTW.
But Joost pointed out that you need to know the node_id of the next node
though: this isn't quite true, since if the node_id is wrong the spec
says you should send an `update_fail_malformed_htlc` with failure code
invalid_onion_hmac, which node N turns into its own failure message.
Perhaps it should convert it to `unknown_next_peer` instead? This isn't
a common error on the modern network; I think our onion implementations
have been rock solid.
This doesn't help if you've revealed your node id in other ways
ofc. i.e. you offer me an invoice, now I probe the rest of the network
to find all unannounced channels you have. For that, implementations
*could* choose to return `update_fail_malformed_htlc`
failure_code=invalid_onion_hmac as above on anything which comes through
an unannounced channel but is not a successful payment (or part thereof,
i.e. correct payment_hash for outstanding invoice with correct
payment_secret field?).
Cheers,
Rusty.
PS. https://twitter.com/cycryptr/status/1384355046381473792 contains exploration.

2023-06-09 15:02:19

- reply

📅 Original date posted:2021-04-27
📝 Original message:
Matt Corallo <lf-lists at mattcorallo.com> writes:
>> On Apr 24, 2021, at 01:56, Rusty Russell <rusty at rustcorp.com.au> wrote:
>>
>> Matt Corallo <lf-lists at mattcorallo.com> writes:
>>> Somehow I missed this thread, but I did note in a previous meeting - these issues are great fodder for fuzzing. We’ve had a fuzzer which aggressively tests for precisely these types of message-non-delivery-and-resending production desync bugs for several years. When it initially landed it forced several rewrites of parts of the state machine, but quickly exhausted the bug fruit (though catches other classes of bugs occasionally as well). The state machine here is really not that big - while I agree simplifying it where possible is nice, ripping things out to replace them with fresh code (which would need similar testing) is probably not the most obvious decrease in complexity.
>>
>> It's historically had more bugs than anything else in the protocol. We
>> literally found another one in feerate negotiation since the last
>> c-lightning release :(
>>
>> I'd rather not have bugs than try to catch them all.
>
> I promise it’s much less work than it sounds like, and avoids having to debug these things based on logs, which is a huge pain :). Definitely less work than a new state machine:).
But the entire point of this proposal is that it's a subset of the
existing state machine?
>> You could propose a splice (or update to anchors, or whatever) any time
>> when it's your turn, as long as you haven't proposed any other updates.
>> That's simple!
>
> I presume you’d need to take it a few steps further - if the last
> message received required a response CS/RAA, you must still wait until
> things have settled down. I guess it also depends on the exact
> semantics of a “turn based” message protocol - if you received some
> updates and a signature, are you allowed to add more updates after you
> send your CS/RAA (then you have a good chunk of today’s complexity),
> or do you have to wait until they send you back their last RAA (in
> which case presumably they aren’t allowed to include anything else as
> then they’d be able to monopolize update windows). In the first case
> you still have the same issues of today, in the second less so, but
> you’re doing a similar “ok, just pause updates and wait for things to
> settle “, I think.
Yes, as the original proposal stated: you propose changes, send
commitment_signed, receive revoke_and_ack and commitment_signed, then
send revoke_and_ack. Then both sides are in sync, and the other side
has a turn.
The only "twist" is that if it's your turn and you receive an update,
you can either reply with a "yield" message, or ignore it.
>> Instead, *both* sides have to send a splice message to synchronize, and
>> they can only do so once all in-flight changes have cleared. You have
>> to resolve simultaneous splice attempts (we use "highest feerate"
>> tiebreak by node_id), and keep track of this stage while you clear
>> in-flight changes.
>
> Isn’t that pretty similar? Discard one splice proposal deterministically (ok that’s new) and the loser has to store their proposal in a holding cell for later (which they have to do in turn-based anyway). Logic to check if there’s unsettled things in RAA handling is pretty similar to turn-based, and logic to reject other messages is the same as shutdown handling today.
Nope, with the simplified protocol you can `update_splice` at any time
instead of your normal update, since both sides are already in sync.
>> Here's the subset of requirements from the draft which relate to this:
>>
>> The sender:
>> - MUST NOT send another splice message while a splice is being negotiated.
>> - MUST NOT send a splice message after sending uncommitted changes.
>> - MUST NOT send other channel updates until splice negotiation has completed.
>>
>> The receiver:
>> - MUST respond with a `splice` message of its own if it has not already.
>> - MUST NOT reply with `splice` until all commitment updates are resolved by both peers.
>
> Probably use “committed” not “resolved”. “Resolved” sounds like “no pending HTLCs left”.
Yes, and in fact this protocol was flawed and had to be revised, as it
did not actually mean both sides were committed in the case of
simultaneous splice proposals :(
>> - MUST use the higher of the two `funding_feerate_perkw` as the feerate for
>> the splice.
>
> If we like turn based, why not just deterministic throw out one slice? :)
Because while I am going to implement turn-based, I'm not sure if anyone
else is. I guess we'll see?
Cheers,
Rusty.

2023-06-09 15:02:19

- reply

📅 Original date posted:2021-04-27
📝 Original message:
OK, draft is up:
https://github.com/lightningnetwork/lightning-rfc/pull/867
I have to actually implement it now (though the real win comes from
making it compulsory, but that's a fair way away).
Notably, I added the requirement that update_fee messages be on their
own. This means there's no debate on the state of the channel when
this is being applied.
Cheers,
Rusty.
Rusty Russell <rusty at rustcorp.com.au> writes:
> Matt Corallo <lf-lists at mattcorallo.com> writes:
>>> On Apr 24, 2021, at 01:56, Rusty Russell <rusty at rustcorp.com.au> wrote:
>>>
>>> Matt Corallo <lf-lists at mattcorallo.com> writes:
>>>> Somehow I missed this thread, but I did note in a previous meeting - these issues are great fodder for fuzzing. We’ve had a fuzzer which aggressively tests for precisely these types of message-non-delivery-and-resending production desync bugs for several years. When it initially landed it forced several rewrites of parts of the state machine, but quickly exhausted the bug fruit (though catches other classes of bugs occasionally as well). The state machine here is really not that big - while I agree simplifying it where possible is nice, ripping things out to replace them with fresh code (which would need similar testing) is probably not the most obvious decrease in complexity.
>>>
>>> It's historically had more bugs than anything else in the protocol. We
>>> literally found another one in feerate negotiation since the last
>>> c-lightning release :(
>>>
>>> I'd rather not have bugs than try to catch them all.
>>
>> I promise it’s much less work than it sounds like, and avoids having to debug these things based on logs, which is a huge pain :). Definitely less work than a new state machine:).
>
> But the entire point of this proposal is that it's a subset of the
> existing state machine?
>
>>> You could propose a splice (or update to anchors, or whatever) any time
>>> when it's your turn, as long as you haven't proposed any other updates.
>>> That's simple!
>>
>> I presume you’d need to take it a few steps further - if the last
>> message received required a response CS/RAA, you must still wait until
>> things have settled down. I guess it also depends on the exact
>> semantics of a “turn based” message protocol - if you received some
>> updates and a signature, are you allowed to add more updates after you
>> send your CS/RAA (then you have a good chunk of today’s complexity),
>> or do you have to wait until they send you back their last RAA (in
>> which case presumably they aren’t allowed to include anything else as
>> then they’d be able to monopolize update windows). In the first case
>> you still have the same issues of today, in the second less so, but
>> you’re doing a similar “ok, just pause updates and wait for things to
>> settle “, I think.
>
> Yes, as the original proposal stated: you propose changes, send
> commitment_signed, receive revoke_and_ack and commitment_signed, then
> send revoke_and_ack. Then both sides are in sync, and the other side
> has a turn.
>
> The only "twist" is that if it's your turn and you receive an update,
> you can either reply with a "yield" message, or ignore it.
>
>>> Instead, *both* sides have to send a splice message to synchronize, and
>>> they can only do so once all in-flight changes have cleared. You have
>>> to resolve simultaneous splice attempts (we use "highest feerate"
>>> tiebreak by node_id), and keep track of this stage while you clear
>>> in-flight changes.
>>
>> Isn’t that pretty similar? Discard one splice proposal deterministically (ok that’s new) and the loser has to store their proposal in a holding cell for later (which they have to do in turn-based anyway). Logic to check if there’s unsettled things in RAA handling is pretty similar to turn-based, and logic to reject other messages is the same as shutdown handling today.
>
> Nope, with the simplified protocol you can `update_splice` at any time
> instead of your normal update, since both sides are already in sync.
>
>>> Here's the subset of requirements from the draft which relate to this:
>>>
>>> The sender:
>>> - MUST NOT send another splice message while a splice is being negotiated.
>>> - MUST NOT send a splice message after sending uncommitted changes.
>>> - MUST NOT send other channel updates until splice negotiation has completed.
>>>
>>> The receiver:
>>> - MUST respond with a `splice` message of its own if it has not already.
>>> - MUST NOT reply with `splice` until all commitment updates are resolved by both peers.
>>
>> Probably use “committed” not “resolved”. “Resolved” sounds like “no pending HTLCs left”.
>
> Yes, and in fact this protocol was flawed and had to be revised, as it
> did not actually mean both sides were committed in the case of
> simultaneous splice proposals :(
>
>>> - MUST use the higher of the two `funding_feerate_perkw` as the feerate for
>>> the splice.
>>
>> If we like turn based, why not just deterministic throw out one slice? :)
>
> Because while I am going to implement turn-based, I'm not sure if anyone
> else is. I guess we'll see?
>
> Cheers,
> Rusty.

2023-06-09 15:02:18

- reply

📅 Original date posted:2021-04-20
📝 Original message:
Christian Decker <decker.christian at gmail.com> writes:
> Rusty Russell <rusty at rustcorp.com.au> writes:
>>> This is in stark contrast to the leader-based approach, where both
>>> parties can just keep queuing updates without silent times to
>>> transferring the token from one end to the other.
>>
>> You've swayed me, but it needs new wire msgs to indicate "these are
>> your proposals I'm reflecting to you".
>>
>> OTOH they don't need to carry data, so we can probably just have:
>>
>> update_htlcs_ack:
>> * [`channel_id`:`channel_id`]
>> * [`u16`:`num_added`]
>> * [`num_added*u64`:`added`]
>> * [`u16`:`num_removed`]
>> * [`num_removed*u64`:`removed`]
>>
>> update_fee can stay the same.
>>
>> Thoughts?
>
> So this would pretty much be a batch-ack, sent after a whole series of
> changes were proposed to the leader, and referenced by their `htlc_id`,
> correct? This is one optimization step further than what I was thinking,
> but it can work. My proposal would have been to either reflect the whole
> message (nodes need to remember proposals they've sent anyway in case of
> disconnects, so matching incoming changes with the pending ones should
> not be too hard), or send back individual acks, containing the hash of
> the message if we want to safe on bytes transferred. Alternatively we
> could also use reference the change by its htlc_id.
[ Following up on an old thread ]
After consideration, I prefer alternation. It fits better with the
existing implementations, and it is more optimal than reflection for
optimized implementations.
In particular, you have a rule that says you can send updates and
commitment_signed when it's not your turn, and the leader either
responds with a "giving way" message, or ignores your changes and sends
its own.
A simple implementation *never* sends a commitment_signed until it
receives "giving way" so it doesn't have to deal with orphaned
commitments. A more complex implementation sends opportunistically and
then has to remember that it's committed if it loses the race. Such an
implementation is only slower than the current system if that race
happens.
I've been revisiting this because it makes things like splicing easier:
the current draft requires stopping changes while splicing is being
negotiated, which is not entirely trivial. With the simplified method,
you don't have to wait at all.
Cheers,
Rusty.

2023-06-09 15:02:18

- reply

📅 Original date posted:2021-04-24
📝 Original message:
Matt Corallo <lf-lists at mattcorallo.com> writes:
> Somehow I missed this thread, but I did note in a previous meeting - these issues are great fodder for fuzzing. We’ve had a fuzzer which aggressively tests for precisely these types of message-non-delivery-and-resending production desync bugs for several years. When it initially landed it forced several rewrites of parts of the state machine, but quickly exhausted the bug fruit (though catches other classes of bugs occasionally as well). The state machine here is really not that big - while I agree simplifying it where possible is nice, ripping things out to replace them with fresh code (which would need similar testing) is probably not the most obvious decrease in complexity.
It's historically had more bugs than anything else in the protocol. We
literally found another one in feerate negotiation since the last
c-lightning release :(
I'd rather not have bugs than try to catch them all.
>> I've been revisiting this because it makes things like splicing easier:
>> the current draft requires stopping changes while splicing is being
>> negotiated, which is not entirely trivial. With the simplified method,
>> you don't have to wait at all.
>
> Hmm, what’s nontrivial about this? How much more complicated is this than having an alternation to updates and pausing HTLC updates for a cycle or two while splicing is negotiated (I assume it would still need a similar requirement, as otherwise you have the same complexity)? We already have a similar update-stopping process for shutdown, though of course it doesn’t include restarting.
You could propose a splice (or update to anchors, or whatever) any time
when it's your turn, as long as you haven't proposed any other updates.
That's simple!
Instead, *both* sides have to send a splice message to synchronize, and
they can only do so once all in-flight changes have cleared. You have
to resolve simultaneous splice attempts (we use "highest feerate"
tiebreak by node_id), and keep track of this stage while you clear
in-flight changes.
Here's the subset of requirements from the draft which relate to this:
The sender:
- MUST NOT send another splice message while a splice is being negotiated.
- MUST NOT send a splice message after sending uncommitted changes.
- MUST NOT send other channel updates until splice negotiation has completed.
The receiver:
- MUST respond with a `splice` message of its own if it has not already.
- MUST NOT reply with `splice` until all commitment updates are resolved by both peers.
- MUST use the higher of the two `funding_feerate_perkw` as the feerate for
the splice.
- MUST NOT send other channel updates until splice negotiation has completed.
Similar requirements exist for other major channel changes.
Cheers,
Rusty.

2023-06-09 15:02:16

- reply

📅 Original date posted:2021-04-23
📝 Original message:
OK, I'm now leaning *against* this method.
1. It removes the ability to update a channel without access to the node's
secret key. At the moment the node secret key is only needed for
gossip and to DH to set up a new peer connection. c-lightning does
not use this for now (we keep the per-channel keys in the HSM too),
but it would be a perfectly acceptable tradeoff not to do this.
2. It doesn't get rid of temporary_channel_id, since we don't know
the generation_number until both sides have sent it. We have a
workaround for this already in dual-funding anyway.
3. Because we need a generation counter, it's not quite as easily
scannable as you'd hope (the "gap" problem).
I think the "encrypted blob served by peers", even in a very naive way,
offers another way to do this, though it requires the assumption that at
least one peer is honest.
Damn, because it was so clever!
Thoughts?
Rusty.
Rusty Russell <rusty at rustcorp.com.au> writes:
> Lloyd Fournier <lloyd.fourn at gmail.com> writes:
>> Hi Rusty,
>>
>> On Tue, 20 Apr 2021 at 10:55, Rusty Russell <rusty at rustcorp.com.au> wrote:
>>
>>> Lloyd Fournier <lloyd.fourn at gmail.com> writes:
>>> > On Wed, Dec 9, 2020 at 4:26 PM Rusty Russell <rusty at rustcorp.com.au>
>>> wrote:
>>> >
>>> >>
>>> >> Say r1=SHA256(ss || counter || 0), r2 = SHA256(ss || counter || 1)?
>>> >>
>>> >> Nice work. This would be a definite recovery win. We should add this
>>> >> to the DF spec, because Lisa was almost finished implmenting it, so it's
>>> >> clearly due for a change!
>>> >>
>>> >
>>> > Yes that's certainly a fine way to do it.
>>> > I was also thinking you could eliminate all "basepoints" (not just
>>> funding
>>> > pubkey) using something like this. i.e. just use the node pubkey as the
>>> > "basepoint" for everything and randomize it using the shared secret for
>>> > each purpose.
>>>
>>> OK, I tried to spec this out, to implement it. One issue is that you
>>> now can't sign the commitment_tx (or htlc_tx) without knowing the node's
>>> secret key (or, equivalently, knowing the tweaked key and being able to
>>> use the derivation scheme to untweak it).
>>>
>>
>> Using node secret key to sign the commitment_tx seems like something you
>> will have to accept to introduce this feature. For the idea to work it has
>> to be some public key that is known by others and gossiped through the
>> network. Of course you could extend the information that is gossiped about
>> a node to include a "commit_tx_point" but the nodeid seems the more natural
>> choice.
>
> Duh, yes, of course you need the funding_key secret to sign the
> commitment tx.
>
> But you really don't want to access the `remote_pubkey` (which in a
> modern option_static_remotekey world is simply the payment_basepoint).
> It's generally considered good practice *not* to have this accessible to
> your lightning node at all.
>
>>> c-lightning currently does a round-trip to the signing daemon for this
>>> already, but it'd be nice to avoid requiring it.
>>>
>>> So I somewhat reluctantly added `commit_basepoint` from which the others
>>> are derived: an implementation can use some hardened derivation from its
>>> privkey (e.g. SHA256(node_privkey || ss || counter)) to create
>>> this in a deterministic but still private manner.
>>>
>>> Or we could just leave all the other points in and just replace
>>> funding_pubkey.
>>>
>>
>> Another approach is to do things in "soft-fork" like manner.
>> Each node that wants to offer this feature sets their funding_pubkey to a
>> specified DH tweak of the nodeid. Nodes that want backup-free channel
>> recovery can just refuse to carry on the funding protocol if the
>> funding_pubkey is not set the way it wanted.
>
> Yeah, you can totally do this in an opt-in manner, except it doesn't
> work unless your peer does it too. Since we expect everyone to want to
> do this, it's clearer to force everyone to calculate this and not have
> redundant and confusing fields in the message.
>
>>>From my pruisit crypto point of view having only one public key is nice but
>> I'm not sure how it impacts things architecturally and other protocols like
>> watchtowers.
>
> They can operate exactly like the existing scheme, AFAICT.
>
> Here's the spec diff (based on dual-funding, since it's easier to simply
> hard change). Please check my EC math! :)
>
> diff --git a/02-peer-protocol.md b/02-peer-protocol.md
> index fbc56c8..1114068 100644
> --- a/02-peer-protocol.md
> +++ b/02-peer-protocol.md
> @@ -867,11 +867,9 @@ This message initiates the v2 channel establishment workflow.
> * [`u16`:`to_self_delay`]
> * [`u16`:`max_accepted_htlcs`]
> * [`u32`:`locktime`]
> - * [`point`:`funding_pubkey`]
> + * [`u64`:`generation`]
> * [`point`:`revocation_basepoint`]
> * [`point`:`payment_basepoint`]
> - * [`point`:`delayed_payment_basepoint`]
> - * [`point`:`htlc_basepoint`]
> * [`point`:`first_per_commitment_point`]
> * [`byte`:`channel_flags`]
> * [`opening_tlvs`:`tlvs`]
> @@ -895,13 +893,16 @@ If nodes have negotiated `option_dual_fund`:
>
> The sending node:
> - MUST set `funding_feerate_perkw` to the feerate for this transaction
> - - MUST ensure `temporary_channel_id` is unique from any
> - other channel ID with the same peer.
> + - MUST set `generation` to a number greater than any previous
> + `generation` it has sent to this receiving node which has reached
> + `commitment_signed`.
> + - SHOULD set `generation` to the lowest number which meets this requirement.
>
> The receiving node:
> - MAY fail the negotiation if:
> - the `locktime` is unacceptable
> - the `funding_feerate_per_kw` is unacceptable
> + - the `generation` exceeds expectation by more than the maximum it would scan for recovery.
>
> #### Rationale
> `channel_id` for the `open_channel2` MUST be derived using a zero-d out
> @@ -926,6 +927,13 @@ Instead, the channel reserve is fixed at 1% of the total channel balance
> rounded down to the nearest whole satoshi or the `dust_limit_satoshis`,
> whichever is greater.
>
> +`generation` is a number which is used to generate the points used for
> +this pair of peers, with the aim of allowing automatic onchain
> +scanning for channels if all other information is lost. Since this
> +scan would presumably only try a limited number of generations, it is
> +best if this number is low, but it also needs to change for each
> +successive channel between the peers, to avoid obvious fingerprinting.
> +
> Note that `push_msat` has been omitted.
>
> ### The `accept_channel2` Message
> @@ -943,11 +951,9 @@ acceptance of the new channel.
> * [`u32`:`minimum_depth`]
> * [`u16`:`to_self_delay`]
> * [`u16`:`max_accepted_htlcs`]
> - * [`point`:`funding_pubkey`]
> + * [`u64`:`generation`]
> * [`point`:`revocation_basepoint`]
> * [`point`:`payment_basepoint`]
> - * [`point`:`delayed_payment_basepoint`]
> - * [`point`:`htlc_basepoint`]
> * [`point`:`first_per_commitment_point`]
> * [`accept_tlvs`:`tlvs`]
>
> @@ -967,6 +973,10 @@ additions.
>
> The accepting node:
> - MAY respond with a `funding_satoshis` value of zero.
> + - MUST set `generation` to a number greater than any previous
> + `generation` it has sent to this receiving node which has reached
> + `commitment_signed`.
> + - SHOULD set `generation` to the lowest number which meets this requirement.
>
> #### Rationale
>
> @@ -985,6 +995,31 @@ Funding composition for channel establishment v2 makes use of the
> [Interactive Transaction Construction](#interactive-transaction-construction)
> protocol, with the following additional caveats.
>
> +#### Point Derivation
> +
> +The `funding_pubkey` and basepoints are derived from the two
> +`node_id`s and the higher of the two `generation` values; the
> +`payment_basepoint` is supplied directly.
> +
> +Derivation is done as follows:
> +
> +1. Start with two node ids, `N1` and `N2` (`N1` is the lesser of the
> + two SEC1-encoded compressed public keys, `N2` the greater).
> +2. Derive a shared secret, `SS`, using ECDH on `N1` and `N2`.
> +3. Define tweaks `T` for each peer, using `SHA256(SS || generation || node_id || name)`, where:
> + 1. `generation` is the `u64` larger of the two `generation` fields from `open_channel2` and `accept_channel2`.
> + 2. `node_id` is the SEC1-encoded compressed public key of the peer.
> + 3. `name` is a non-terminated ASCII string, e.g. `htlc` is the four bytes
> + `0x68 0x74 0x6C 0x63`
> +4. The `funding_pubkey` is defined as the `node_id` + G*T(`funding`).
> +5. The `delayed_payment_basepoint` is defined as `node_id` + G*T(`delayed_payment`).
> +6. The `htlc_basepoint` is defined as the `node_id` + G*T(`htlc`).
> +
> +If the secret for `payment_basepoint` is derived in a similar manner,
> +it too can be easily recovered from just the `generation`, node key
> +and peer `node_id`. However, it may also point to an address for a
> +completely separate system (e.g. cold storage), so it is specified
> +explicitly in the protocol.
>
> #### The `tx_add_input` Message
>

2023-06-09 15:02:15

- reply

📅 Original date posted:2021-04-16
📝 Original message:
Hi all,
https://github.com/lightningnetwork/lightning-rfc/pull/798/commits/fc8aab72ccdd616301dc200fc124824efe4fbb58
I've just added a simple addition to the proposed BOLT 12 offers spec,
where invoice requests can ask to obsolete old invoices. This allows a
simple workaround in the case where a payment is stuck: the vendor
commits to a new invoice which obsoletes the old one, using the
already-existing invoice_request message.
If the vendor cheats and accepts both old and new payments, you
can prove they lied. Or they can return an error which indicates
they've already received the payment and it's simply the return which is
stuck.
Either way, it's now simple to implement, and gives wallets another
option for handling these cases.
Cheers!
Rusty.

2023-06-09 15:02:13

- reply

📅 Original date posted:2021-03-31
📝 Original message:
We're pleased to announce the 0.10.0 release of c-lightning, named by @jsarenik.
https://github.com/ElementsProject/lightning/releases/tag/v0.10.0
This is a major release, consolidating a number of features, fixes and
experimental extensions.
Highlights for Users
* pay has been refined and much improved across various less-common scenarios.
* listpeers shows the current feerate and unilateral close fee.
* listforwards can now filter by channel status, and in our out channel.
* fundpsbt and utxopsbt have a new excess_as_change parameter if you
don't want to add it yourself.
* connect returns the address we actually connected to (and direction
tells you if they actually connected to us instead).
* fundchannel_complete takes a PSBT, removing a common cause of tragic
opening failures: txprepare and withdraw now provide a PSBT for convenience too.
* In regtest mode, we don't care that bitcoind doesn't give any fee
estimates, but use the minimum.
Highlights for the Network
* We now send warning messages if an error condition is possibly
recoverable, rather than closing the channel and sending error.
* We now implement sync_complete for gossip_range queries as per latest
spec, with backwards compatibility for older nodes.
* `experimental-dual-fund` config option enables the draft dual funding
option for compatible nodes, which includes RBF upgrades for opening
transactions.
Highlights for Developers
* All hooks are now registerable by multiple plugins at once.
* `experimental-shutdown-wrong-funding` allows remote nodes to close
incorrectly opened channels using the new wrong_funding option to
close.
More details can be found in the changelog.
Thanks to everyone for their contributions and bug reports; please keep them coming.
Since 0.9.3, we've had 339 commits from 14 different authors over 69 days.
A special thanks goes to the 3 first time contributors:
Matthias Debernardini
Luke Childs
Alexey Zagarin
Cheers,
Rusty, Lisa, Christian, ZmnSCPxj

2023-06-09 15:01:51

- reply

📅 Original date posted:2021-01-28
📝 Original message:
Lloyd Fournier <lloyd.fourn at gmail.com> writes:
> I think immediate broadcast of signaling TX is a bad idea even if it's done
> over lightning since it leaks that the UTXO associated with the signaling
> TX is creating a channel (even if the channel was meant to be private).
> You could argue that the signaling TX need not be associated with a UTXO
> but I find this awkward.
> Lazily broadcast, signaling txs are a good way to protect against
> sequential attacks but are weak against parallel attacks. Unfortunately I
> think protection of the former means very little without the latter.
Agreed. Let's PoDLE!
> Let H0 and H1 be 32-byte output hash functions.
>
> 1. In any of the `tx_add_input` messages the initiator may attach a PoDLE
> which contains the public key for an input as well as a P2 (the public key
> projected onto a different generator).
> 2. Upon receiving the PoDLE, the peer checks its validity and creates a
> "claim" message claiming the UTXO which contains.
> i) H0(P2)
> ii) A MAC (e.g. Poly1305) produced with the H1(P2) as the key and
> claimer_node_id as the message -- required so conflicting claim messages
> can only be produced by someone who actually knows P2.
> iii) The claimer_node_id and a BIP340 signature under it over the rest
> of the message data -- required to stop spam: only accept and re-broadcast
> these messages from nodes who have real channels.
Note: we can avoid leaking claimer_node_id (Hey, look at me, someone's
opening a channel with me now!). The purpose of claimer_node_id is to
restrict spam (you need to have broadcasted a valid open channel to be
recognized by the network as a valid node_id), but we can make this
direct: require a utxo + the script needed to spend it, and any key in
that script will serve in place of claimer_node_id (for v1
segwit, the output itself may serve as key).
Since we're headed to an anchor (or Eltoo) world where nodes have to
keep a few UTXOs around for emergencies anyway, this may have better
privacy. At worst, they use a key from an existing, public channel
UTXO, which is no worse than using their node_id.
> Now I'd like to make the strongest possible argument against it in favor of
> just doing nothing (for now) at the protocol level about this problem.
>
> Consider the following propositions:
> 1. The public nodes that will offer dual funding and are susceptible to
> this attack will be the kind that have a lot of churn i.e. they dual fund a
> channel, when that closes they use the remaining funds to fund another
> channel.
> 2. Chainalysis already works very well at identifying the UTXOs these kinds
> of nodes. If the change output of a funding or the closing output are
> reused in another public channel it is easy to identify which node was
> funding what with the techniques in [1,2].
Less true after taproot though?
> 3. It is therefore rather redundant to do this type of active UTXO probing
> since all you need to do is wait and be patient. Churning public nodes will
> eventually use their UTXO to do a dual or single funding. Then by
> cross-layer de-anonymization techniques you will be able to determine that
> they owned that UTXO without ever interacting with the node.
> 4. These techniques can even be applied to private channels at least while
> they are identifiable on the blockchain (in [2] using chainalysis they can
> identify one node involved in a private channel 79% of the time).
> 5. There is of course some extra advantage in doing this attack but looking
> at the effectiveness of techniques in [1,2] and my intuition about how
> churning nodes are most susceptible to these techniques I *guess* it
> wouldn't be much. If this is the case then chainalysis companies may not be
> able to justify doing active attacks when passive attacks work almost as
> well.
> 6. It may be more effective to deal with UTXO probing outside of the
> protocol. For example, a group of dual-funders could maintain a shared UTXO
> blacklist and use chainalysis on it to not only ban single UTXOs but entire
> clusters of outputs. i.e. do chainalysis on the chainalyzers! There are
> some efforts to create open tools to do Chainalysis [3] that could be
> leveraged against this attack. This might be much more effective than
> PoDLEs as just spending the output somewhere else would not be enough to
> use it again in the attack.
> 7. The above PoDLE proposal actually creates a new extra bit of data that
> can be used for chainalysis -- when you broadcast the claim message you are
> saying you're going to make a dual funded channel sometime soon. So
> Chainalysis can look in the next block for something that looks like a dual
> funding and know you participated. This could be quite valuable for them
> and I would hesitate to give it to them in the anticipation of them doing
> an attack they may never actually do.
> 8. If all of the above points are not enough to prevent this attack from
> being widespread and the above PoDLE proposal is still the best idea I
> guess it wouldn't be too hard to shoehorn it into the protocol later.
>
> At the moment my bias is towards doing nothing and keeping things simple.
> It seems chainalysis techniques are effective at associating funding UTXOs
> to nodes for the most common usage patterns. Taproot will change the game
> for private channels but won't do much for public channels.
> Having said that -- it was a thing in JoinMarket so I might be wrong. I can
> offer some conjecture as to why JoinMarket had this issue: if you can find
> all the maker UTXOs before and after a join then you have removed a lot of
> the anonymity set. Since CoinJoin is a UTXO privacy technology this makes
> sense.
I also agree; it's fairly easy to add later with a feature bit, and I
think we now have a roadmap on how it should be done. Let's not boil
the ocean.
> [1] https://arxiv.org/abs/2007.00764
> [2] https://arxiv.org/pdf/2003.12470.pdf
> [3] https://graphsense.info/
>
> I am told there is a new revision of [1] coming out any day now that will
> present a few more tricks and have contributions directly from a scientist
> at Chainalsysis (the company).
I'll add to my reading list (or wait for one of my colleagues to provide
the TL;DR!).
Cheers!
Rusty.

2023-06-09 15:01:51

- reply

📅 Original date posted:2021-01-19
📝 Original message:
Lloyd Fournier <lloyd.fourn at gmail.com> writes:
> I think PoDLE might actually have an advantage in parallel attacks if the
> scheme was changed a bit. A weakness of the lightning proposal as compared
> to the joinmarket idea is that the `h2` point is not broadcast immediately
> -- rather you wait for failure and then broadcast it. Instead, a peer
> should broadcast h2 as soon as they have agreed to create a transaction
> with the initiator. Then if at any time during the tx creation protocol
> they receive the same h2 from someone else, they cancel and don't reveal
> their UTXOs (let's say they wait ~10s after broadcasting before revealing
> any utxos). Note that here you don't have to randomly select the time you
> wait.
Yes, sorry. I assumed immediate broadcast + 60 second wait for
conflicts. It's this scheme I was trying to shoehorn into the mempool
(broadcast signalling tx, wait, try to RBF it with a real open). But
there are three problems with doing that:
1. Everyone knows what you're doing, as they see the signalling tx (and
it needs to commit to a challenge, such as using OP_RETURN, so you
can't simply reuse the same tx).
2. Bitcoind doesn't tell you if it encounters a conflicting tx from a
peer, so we'd probably need to gossip this via lightning instead.
3. If tx fees are low, the signalling tx might get mined.
> There are several (perhaps addressable) downsides to this scheme but it at
> least has better protection against parallel attacks than the others.
> Since it is effective it would also break the "middleman" idea unless Alice
> funds with two utxos (a different h2 for each party) or there is some way
> for all parties involved in the funding to distinguish gossiped h2s from
> their funding session from others.
Yes, every initiator needs to provide an h2, and it has to be their own.
But you don't care (and can't know) that there's an h2 for another
input, too. If Alice wants to initialte an open with Carol while Bob is
initiating an opening with her, she's got to provide her own UTXO &
PoDLE.
Another point: the idea was that the accepting node would sign the
gossip msg, and only known nodes (i.e. ones with a public channel) would
be allowed to do so. This gives easy anti-spam: if Alice starts
spamming a giant pile of h2s, we start randomly dropping them. That
doesn't degrade the protection much: a single UTXO reuse might slip
through, but a larger number would still be detected with P approaching
1.
Cheers,
Rusty.

2023-06-09 15:01:50

- reply

📅 Original date posted:2021-01-12
📝 Original message:
Lloyd Fournier <lloyd.fourn at gmail.com> writes:
> Rusty, Zman,
>
> A concern I have with only doing one signaling transaction out of the whole
> group of inputs is that it means you don't prove ownership of the other
> inputs.
But that's by design. You can contact two peers and middleman between
them to produce a single tx.
The practical problem with a signalling tx is that it's hard to tell if
it's conflicting. Mallory uses a single UTXO to probe for everyone's
UTXO at once. Poor Bob wants to both wait 60 seconds to see if a
conflicting tx ends up in his mempool, *and* broadcast it ASAP to signal
to others. He wants to do both of these *before* revealing his own
UTXOs.
Not sure how to square this, but I do prefer this approach over PoDLE.
Cheers,
Rusty.

2023-06-09 15:01:42

- reply

📅 Original date posted:2020-12-09
📝 Original message:
Lloyd Fournier <lloyd.fourn at gmail.com> writes:
> Hi list,
>
> I've been considering the problem of recovering lightning channels after
> losing channel state in a boating accident. The modern way of doing this
> seems to be "static channel backups" -- these are essentially lists of
> channel ids and the nodes you had the channels with.
>
> The idea is that with this backup you can remember who you had channels
> with, connect to them and ask them to force close the channel (can someone
> link me the concrete protocol messages you send to do this?).
It's in BOLT #2:
1. type: 136 (`channel_reestablish`)
2. data:
* [`channel_id`:`channel_id`]
* [`u64`:`next_commitment_number`]
* [`u64`:`next_revocation_number`]
* [`32*byte`:`your_last_per_commitment_secret`]
* [`point`:`my_current_per_commitment_point`]
The `your_last_per_commitment_secret` lets Bob prove to Alice that he's
from The Future, and prior to `option_static_remotekey`
my_current_per_commitment_point allowed Alice to derive the script used
for her output.
> It occurred to me that if the lightning protocol were changed slightly you
> could do this without the channel backup at all. Consider the open channel
> message and its two fields `funding_pubkey` and `temporary_channel_id`.
Hmm, we had a proposal (for DF) to get rid of the temporary_channel_id
by using 'SHA256(lesser-revocation-basepoint ||
greater-revocation-basepoint)' as the channel_id, which is known
from the start. I don't see it in the DF spec PR, but it's in
c-lightning.
> https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#the-open_channel-message
>
> The reason `temporary_channel_id` is necessarily "temporary" is because we
> don't know the other party's `funding_pubkey`. Instead I propose using
> deterministically randomized version of the node's static public key as the
> `funding_pubkey` so we know it up front. Specifically, when opening a
> channel with a remote node, do a Diffie-Hellman operation with their public
> key and use the resulting shared secret to deterministically produce
> scalars r1 and r2 and use 2-of-2(r1*G + P_local, r2*P_remote) as the script
> pubkey of funding output. Now we know what the funding output would look
> like with any node without interacting with them. Of course, to open
> multiple channels with the same node we would have to generate a new shared
> secret from each one by hashing a counter.
Say r1=SHA256(ss || counter || 0), r2 = SHA256(ss || counter || 1)?
Nice work. This would be a definite recovery win. We should add this
to the DF spec, because Lisa was almost finished implmenting it, so it's
clearly due for a change!
> Now that we can figure out what our funding outputs with each node look
> like non-interactively, when we lose our channel state we can find them in
> the UTXO set as long as we can recreate a list of node's we may have had
> channels with. For most non-enterprise users (such as myself) this can be
> done automatically because we exclusively have channels with well known
> reliable public nodes whose public keys can be discovered through routing
> gossip or from public indexes. Therefore if I can just restore my node's
> keypair from my seed I should be able to scan the network for nodes and
> figure out if I have channels open with them and then carry out the
> recovery process. From my perspective this seems to be a rather nice
> improvement in user experience.
Note that in practice you can have nodes reconnecting to you.
We've long thought about peers supplying some storage for each other, so
you can spray out (encrypted) backups that way. It's actually a fairly
trivial addition; your scheme makes for much less data to store.
Cheers!
Rusty.

2023-06-09 15:01:29

- reply

📅 Original date posted:2020-11-18
📝 Original message:
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.

2023-06-09 15:01:29

- reply

📅 Original date posted:2020-11-21
📝 Original message:
Bastien TEINTURIER <bastien at acinq.fr> writes:
> 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).
I agree. I'll ask a real crypto person to review it, though.
> 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.
I'll try and report back; I think it's trivial (I converted offers, and
indeed it was trivial except needing a way to lookup a x-only node_id,
which simply required two lookups).
Cheers,
Rusty.

2023-06-09 15:01:21

- reply

📅 Original date posted:2020-10-20
📝 Original message:
Christian Decker <decker.christian at gmail.com> writes:
>> And you don't get the benefit of the turn-taking approach, which is that
>> you can have a known state for fee changes. Even if you change it to
>> have opener always the leader, it still has to handle the case where
>> incoming changes are not allowed under the new fee regime (and similar
>> issues for other dynamic updates).
>
> Good point, I hadn't considered that a change from one side might become
> invalid due to a change from the other side. I think however this can only
> affect changes that result in other changes no longer being applicable,
> e.g., changing the number of HTLCs you'll allow on a channel making the
> HTLC we just added and whose update_add is still in flight invalid.
To make dynamic changes in the current system, you need to make them the
same way we make feechanges: first remote, then local (once they ack).
This means you have to handle the cases where this causes the the commit
tx to not meet the new restrictions. It's all possible, it's just
messy.
> I don't think fee changes are impacted here, since the non-leader only
> applies the change to its commitment once it gets back its own change.
> The leader will have inserted your update_add into its stream after the
> fee update, and so you'll first apply the fee update, and then use the
> correct fee to add the HTLC to your commitment, resulting in the same
> state.
Sure, but we still have the (existing) problem where you propose a fee
change you can no longer afford, because the other side is also adding
things.
They can just refuse to reflect the fee in that case, though.
> The remaining edgecases where changes can become invalid if they are in
> flight, can be addressed by bouncing the change through the non-leader,
> telling him that "hey, I'd like to propose this change, if you're good
> with it send it back to me and I'll add it to my stream". This can be
> seen as draining the queue of in-flight changes, however the non-leader
> may pipeline its own changes after it and take the updated parameters
> into consideration. Think of it as a two-phase commit, alerting the peer
> with a proposal, before committing it by adding it to the stream. It
> adds latency (about 1/2RTT over the token-passing approach since we can
> emulate it with the token-passing approach) but these synchronization
> points are rare and not on the critical path when forwarding payments.
You can create a protocol to reject changes, but now we're more complex
than the simply-alternate-leader approach.
> With the leader-based approach, we add 1RTT latency to the updates from
> one side, but the other never has to wait for the token, resulting in
> 1/2RTT per direction as well, since messages are well-balanced.
Good point.
>> Yes, but it alternates because that's optimal for a non-busy channel
>> (since it's usually "Alice adds htlc, Bob completes the htlc").
>
> What's bothering me more about the turn-based approach is that while the
> token is in flight, neither endpoint can make any progress, since the
> one reliquishing the token promised not to say anything and the other
> one hasn't gotten the token yet. This might result in rather a lot of
> dead-air if both sides have a constant stream of changes to add. So we'd
> likely have to add a timeout to defer giving up the token, to counter
> dead-air, further adding delay to the changes from the other end, and
> adding yet another parameter.
I originally allowed optimistically sending commitment_signed. But it
means there can be more than one commitment tx for any given height (you
have to assume they received the sig and might broadcast it), which
seemed to complicate things. OTOH this is only true if you choose to do
this.
> This is in stark contrast to the leader-based approach, where both
> parties can just keep queuing updates without silent times to
> transferring the token from one end to the other.
You've swayed me, but it needs new wire msgs to indicate "these are your
proposals I'm reflecting to you".
OTOH they don't need to carry data, so we can probably just have:
update_htlcs_ack:
* [`channel_id`:`channel_id`]
* [`u16`:`num_added`]
* [`num_added*u64`:`added`]
* [`u16`:`num_removed`]
* [`num_removed*u64`:`removed`]
update_fee can stay the same.
Thoughts?
Rusty.

2023-06-09 15:01:21

- reply

📅 Original date posted:2020-10-14
📝 Original message:
Christian Decker <decker.christian at gmail.com> writes:
> 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).
But now you need to be able to propose two kinds of things, which is
actually harder to implement; update-from-you and update-from-me. This
is a deeper protocol change.
And you don't get the benefit of the turn-taking approach, which is that
you can have a known state for fee changes. Even if you change it to
have opener always the leader, it still has to handle the case where
incoming changes are not allowed under the new fee regime (and similar
issues for other dynamic updates).
> 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.
Yeah, it adds 1RTT to every hop on the network, vs my proposal which
adds just over 1/2 RTT on average.
> 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 :-)
Yes, but it alternates because that's optimal for a non-busy channel
(since it's usually "Alice adds htlc, Bob completes the htlc").
Cheers,
Rusty.

2023-06-09 15:01:20

- reply

📅 Original date posted:2020-10-14
📝 Original message:
Bastien TEINTURIER <bastien at acinq.fr> writes:
> 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?
Well, if you've implemented a state-based approach then this is simply a
subset of that so it's simple to implement (I believe, I haven't done it
yet!).
But with a synchronous approach like this, we can do dynamic protocol
updates at any time without having a special "stop and drain" step.
For example, you can decrease the amount of HTLCs you accept, without
worrying about the case where there HTLCs being added right now. This
solves a similar outstanding problem with update_fee.
Cheers,
Rusty.

2023-06-09 15:01:19

- reply

📅 Original date posted:2020-10-12
📝 Original message:
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

2023-06-09 15:01:12

- reply

📅 Original date posted:2020-10-14
📝 Original message:
Joost Jager <joost.jager at gmail.com> writes:
>>
>> > A crucial thing is that these hold fees don't need to be symmetric. A new
>> > node for example that opens a channel to a well-known, established
>> routing
>> > node will be forced to pay a hold fee, but won't see any traffic coming
>> in
>> > anymore if it announces a hold fee itself. Nodes will need to build a
>> > reputation before they're able to command hold fees. Similarly, routing
>> > nodes that have a strong relation may decide to not charge hold fees to
>> > each other at all.
>>
>> I can still establish channels to various low-reputation nodes, and then
>> use them to grief a high-reputation node. Not only do I get to jam up
>> the high-reputation channels, as a bonus I get the low-reputation nodes
>> to pay for it!
>
> So you're saying:
>
> ATTACKER --(no hold fee)--> LOW-REP --(hold fee)--> HIGH-REP
>
> If I were LOW-REP, I'd still charge an unknown node a hold fee. I would
> only waive the hold fee for high-reputation nodes. In that case, the
> attacker is still paying for the attack. I may be forced to take a small
> loss on the difference, but at least the larger part of the pain is felt by
> the attacker. The assumption is that this is sufficient enough to deter the
> attacker from even trying.
No, because HIGH-REP == ATTACKER and LOW-REP pays.
> I guess your concern is with trying to become a routing node? If nobody
> knows you, you'll be forced to pay hold fees but can't attract traffic if
> you charge hold fees yourself. That indeed means that you'll need to be
> selective with whom you accept htlcs from. Put limits in place to control
> the expenditure. Successful forwards will earn a routing fee which could
> compensate for the loss in hold fees too.
"Be selectinve with whom you accept HTLCs from"... it always comes back
to incentives to de-anonymize the network :(
> I think this mechanism can create interesting dynamics on the network and
> eventually reach an equilibrium that is still healthy in terms of
> decentralization and privacy.
I suspect that if you try to create a set of actual rules for nodes
using actual numbers, I think you'll find you enter a complexity spiral
as you try to play whack-a-mole on all the different ways you can
exploit it.
(This is what happened every time I tried to design a peer-penalty
system).
Cheers,
Rusty.

2023-06-09 15:01:10

- reply

📅 Original date posted:2020-10-13
📝 Original message:
Joost Jager <joost.jager at gmail.com> writes:
> This hold fee could be: lock_time * (fee_base + fee_rate * htlc_value).
> fee_base is in there to compensate for the usage of an htlc slot, which is
> a scarce resource too.
...
>
> In both cases the sender needs to trust its peer to not steal the payment
> and/or artificially delay the forwarding to inflate the hold fee. I think
> that is acceptable given that there is a trust relation between peers
> already anyway.
>
> A crucial thing is that these hold fees don't need to be symmetric. A new
> node for example that opens a channel to a well-known, established routing
> node will be forced to pay a hold fee, but won't see any traffic coming in
> anymore if it announces a hold fee itself. Nodes will need to build a
> reputation before they're able to command hold fees. Similarly, routing
> nodes that have a strong relation may decide to not charge hold fees to
> each other at all.
I can still establish channels to various low-reputation nodes, and then
use them to grief a high-reputation node. Not only do I get to jam up
the high-reputation channels, as a bonus I get the low-reputation nodes
to pay for it!
Operators of high reputation nodes can even make this profitable; doubly
so, since they eliminate the chance of any of those low-reputation nodes
every getting to be high reputation (and thus competing).
AFAICT any scheme which penalizes the direct peer creates a bias against
forwarding unknown payments, thus is deanonymizing.
> I'd also like to encourage everyone to prioritize this spam/jam issue and
> dedicate more time to solving it. Obviously there is a lot more to do in
> Lightning, but I am not sure if we can afford to wait for the real
> adversaries to show up on this one.
Agreed. It's a classic "it's not actually on fire *right now*" problem,
so it does keep getting pushed back.
Cheers,
Rusty.

2023-06-09 14:59:46

- reply

📅 Original date posted:2020-04-27
📝 Original message:
"David A. Harding via bitcoin-dev" <bitcoin-dev at lists.linuxfoundation.org> writes:
> To avoid the excessive wasting of bandwidth. Bitcoin Core's defaults
> require each replacement pay a feerate of 10 nBTC/vbyte over an existing
> transaction or package, and the defaults also allow transactions or
> packages up to 100,000 vbytes in size (~400,000 bytes). So, without
> enforcement of BIP125 rule 3, an attacker starting at the minimum
> default relay fee also of 10 nBTC/vbyte could do the following:
>
> - Create a ~400,000 bytes tx with feerate of 10 nBTC/vbyte (1 mBTC total
> fee)
>
> - Replace that transaction with 400,000 new bytes at a feerate of 20
> nBTC/vbyte (2 mBTC total fee)
>
> - Perform 998 additional replacements, each increasing the feerate by 10
> nBTC/vbyte and the total fee by 1 mBTC, using a total of 400 megabytes
> (including the original transaction and first replacement) to
> ultimately produce a transaction with a feerate of 10,000 nBTC/vbyte
> (1 BTC total fee)
>
> - Perform one final replacement of the latest 400,000 byte transaction
> with a ~200-byte (~150 vbyte) 1-in, 1-out P2WPKH transaction that pays
> a feerate of 10,010 nBTC/vbyte (1.5 mBTC total fee)
To be fair, if the feerate you want is 100x the minimum permitted, you
can always use 100x as much bandwidth as necessary without extra cost.
If everyone (or some major tx producers) were to do that, it would suck.
To fix this properly, you really need to agressively delay processing
(thus propagation) of transactions which aren't likely to be in the next
(few?) blocks. This is a more miner incentive compatible scheme.
However, I realize this is a complete rewrite of bitcoind's logic, and
I'm not volunteering to do it!
Cheers,
Rusty,

2023-06-09 14:59:16

- reply

📅 Original date posted:2020-03-10
📝 Original message:
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.

2023-06-09 14:59:03

- reply

📅 Original date posted:2020-02-24
📝 Original message:
Christian Decker <decker.christian at gmail.com> writes:
> Rusty Russell <rusty at rustcorp.com.au> writes:
>
>> I like it! The lack of "reply" function eliminates all storage
>> requirements for the intermediaries. Unfortunately it's not currently
>> possible to fit the reply onion inside the existing onion, but I know
>> Christian has a rabbit in his hat for this?
>
> I think circular payment really means an onion that is
>
>> A -> ... -> B -> ... -> A
>
> and not a reply onion inside of a forward onion.
>
> The problem with the circular path is that the "recipient" cannot add
> any reply without invalidating the HMACs on the return leg of the
> onion. The onion is fully predetermined by the sender, any malleability
> introduced in order to allow the recipient to reply poses a threat to
> the integrity of the onion routing, e.g., it opens us up to probing by
> fiddling with parts of the onion until the attacker identifies the
> location the recipient is supposed to put his reply into.
>
> As Rusty mentioned I have a construction of the onion routing packet
> that allows us to compress it in such a way that it fits inside of the
> payload itself.
I think this has the same problem though, that there's no way Alice can
send Bob an onion to use with an arbitrary message?
> Another advantage is that the end-to-end payload is not covered by the
> HMACs in the header, meaning that the recipient can construct a reply
> without having to modify (and invalidate) the routing onion. I guess
> this is going back to the roots of the Sphinx paper :-)
Good point, and it's trivial. The paper suggests the payload be "final
key" followed by the desired data, providing a simple validation scheme.
We could potentially generalize the HTLC messages like this, but it's
unnecessary at this point.
Thanks,
Rusty.

2023-06-09 14:59:01

- reply

📅 Original date posted:2020-02-20
📝 Original message:
ZmnSCPxj <ZmnSCPxj at protonmail.com> writes:
> Good morning Rusty,
>
> A concern I have brought up in the past is that if this is more than just a single request-response, i.e. if this is a conversation where Alice sends to Bob, Bob sends back to Alice, Alice sends back to Bob, and so on, then if the same path is used each time Alice sends to Bob, the timing from Bob response to Alice to the next Alice sends to Bob can help an intermediate node guess how far away Alice is from itself.
> Obviously the timing from Alice sending to Bob and Bob replying gives a hint as well as to the distance the intermediate node is to Bob already.
>
> It may be good to at least recommend that direct messages use different paths if they are part of a larger conversation between the two parties.
This already applies to HTLCs, no?
> Would it not be better to create a circular path?
> By this I mean, Alice constructs an onion that overall creates a path from herself to Bob and back, ensuring different nodes on the forward and return directions.
> The onion hop at Bob reveals that Bob is the chosen conversation partner, and Bob forwards its reply via the onion return path (that Alice prepared herself to get back to her via another path).
I like it! The lack of "reply" function eliminates all storage
requirements for the intermediaries. Unfortunately it's not currently
possible to fit the reply onion inside the existing onion, but I know
Christian has a rabbit in his hat for this?
> After Alice receives the first message from Bob the circular "circuit" is established and they can continue to communicate using the same circuit: timing attacks are now "impossible" since Alice and Bob can be anywhere along the circle, even if two of the nodes in the circuit are surveillors cooperating with each other, the timing information they get is the distance between the surveillor nodes.
>
> Of course, if a node in the circular path drops the circuit is disrupted, so any higher-level protocols on top of that should probably be willing to resume the conversation on another circular circuit.
My immediate purpose for this is for "offers" which cause a invoice
request, followed by an invoice reply. This will probably be reused
once for the payment itself. 2 uses is not sufficient to justify
setting up a circuit, AFAICT.
> I believe I even tied this to an HTLC in an attempt to provide a
> spam-limit as well:
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-November/002294.html
This part was deeply unclear. Eventually we will have to charge
up-front for forwarding HTLCs (say 5% of existing fee, plus 1msat), and
then we could use the same scheme with lesser amounts (say, 1msat) for
forwarding messages.
But I have been unable to come up with an upfront scheme which doesn't
leak information badly.
The best I can do is some hashcash scheme, combined with the ability to
buy a single-use token to weaken it. Under load, a node would raise
their hashcash difficulty, and you could either find another route,
grind your onion more to meet it, or send a payment for a token from
that node which would let your HTLC through: the preimage could even be
the XOR of some secret you send with the HTLC, and a shachain key which
gives you 1000 tokens, and you can use them in order, etc.
(Really want to use some kind of Chaumian token here, but it's probably
overkill).
> Finally: what does this improve over, say, requiring that all
> Lightning nodes have a Tor .onion address and just doing direct
> messaging over Tor?
That would be far better! But that's not happening: lnurl over https is
happening. Using lightning to tunnel messages is a strict improvement
over that, at least.
Cheers!
Rusty.

2023-06-09 14:59:00

- reply

📅 Original date posted:2020-02-20
📝 Original message:
René Pickhardt <r.pickhardt at googlemail.com> writes:
> Hey Rusty,
>
> I was very delighted to read your proposal. But I don't see how you prevent
> message spam. If I understand you correctly you suggest that I can
> communicate to any node along a path of peer connections (not necessarily
> backed by payment channels but kind of only known through channel
> announcements of gossip) via onions and these onions which are send within
> a new gossip message are not bound to any fees or payments.
It doesn't handle spam, but OTOH it's far cheaper than the HTLC system
(which also doesn't handle spam). I'd be delighted to add an up-front
1msat payment, as soon as we can figure out how to do that.
The non-persistent storage costs for remembering how to forward the
reply are the 200 bytes in my implementation (one pointer to the source
peer, two SHA256s, and the shared secret).
> Let's assume I just missed some spam prevention mechanism or that we can
> fix them. Do I understand the impact of your suggestion correctly that I
> could use this protocol to
>
> 1.) create a fee free rebalancing protocol? Because I could also attach a
> new lightning message inside the onions that would allow nodes without
> direct peer connection to set up a circular rebalancing path.
> 2.) have the ability to communicate with nodes further away than just my
> peers - for example to exchange information for pathfinding and / or
> autopilots?
Indeed. I haven't prevented it, precisely because we *can't*. This
proposal merely gives a more efficient method than encoding via HTLCs.
Cheers,
Rusty.

2023-06-09 14:58:59

- reply

📅 Original date posted:2020-02-28
📝 Original message:
Anthony Towns <aj at erisian.com.au> writes:
> Aside from those philosophical complaints, seems to me the simplest
> attack would be:
>
> * route 1000s of HTLCs from your node A1 to your node A2 via different,
> long paths, using up the total channel capacity of your A1/A2 nodes,
> with long timeouts
> * have A2 offer up a transaction claiming that was the channel
> close to A3; make it a real thing if necessary, but it's probably
> fake-able
> * then leave the HTLCs open until they time out, using up capacity
> from all the nodes in your 1000s of routes. For every satoshi of
> yours that's tied up, you should be able to tie up 10-20sat of other
> people's funds
>
> That increases the cost of the attack by one on-chain transaction per
> timeout period, and limits the attack surface by how many transactions
> you can get started/completed within whatever the grace period is, but
> it doesn't seem a lot better than what we have today, unless onchain
> fees go up a lot.
Interestingly, I think your "reverse commitment signing" proposal would
mean the close tx will have the HTLC within it, so this attack is not
possible? (Modulo handling dust HTLCs, which won't show up in the
commitment tx).
Previously I suggested the node simply send a (signed) list of up to N
additional HTLCs (this reduces batching to N, so make it at least 16).
This is gossiped, and if you get conflicting versions, the channel break
is considered invalid, so (as always) the previous channel has to break.
>> > A->B: here's a HTLC, locked in
>> > B->C: HTLC proposal
>> > C->B: sure: updated commitment with HTLC locked in
>> > B->C: great, corresponding updated commitment, plus revocation
>> > C->B: revocation
>> Interesting; this adds a trip, but not in latency (since C can still
>> count on the HTLC being locked in at step 3).
>> I don't see how it helps B though? It still ends up paying A, and C
>> doesn't pay anything?
>
> The updated commitment has C paying B onchain; if B doesn't receive that
> by the time the grace period's about over, B can cancel the HTLC with A,
> and then there's statemachine complexity for B to cancel it with C if
> C comes alive again a little later.
I thought C paid per unit time, so it wouldn't pay up-front? You're
suggesting it pays the max in the commitment, and then it gets some back
in the normal case of things going right?
>> It forces a liveness check of C, but TBH I dread rewriting the state
>> machine for this when we can just ping like we do now.
>
> I'd be surprised if making musig work doesn't require a dread rewrite
> of the state machine as well, and then there's PTLCs and eltoo...
Hmm, PTLCs and eltoo don't. Musig requires some mods to the protocol,
but the state machine changes are trivial.
>> >> There's an old proposal to fast-fail HTLCs: Bob sends an new message "I
>> >> would fail this HTLC once it's committed, here's the error"
>> > Yeah, you could do "B->C: proposal, C->B: no way!" instead of "sure" to
>> > fast fail the above too.
>> > And I think something like that's necessary (at least with my view of how
>> > this "keep the HTLC open" payment would work), otherwise B could send C a
>> > "1 microsecond grace period, rate of 3e11 msat/minute, HTLC for 100 sat,
>> > timeout of 2016 blocks" and if C couldn't reject it immediately would
>> > owe B 50c per millisecond it took to cancel.
>> Well, surely grace period (and penalty rate) are either fixed in the
>> protocol or negotiated up-front, not per-HTLC.
>
> I think the "keep open rate" should depend on how many nodes have
> already been in the route (the more hops it's gone through, the more
> funds/channels you're tying up by holding onto the HTLC, so the more
> you should pay), while the grace period should depend on how many nodes
> there are still to go in the route (it needs to be higher to let each of
> those nodes deduct their delta from it). So I think you *should* expect
> those to change per HTLC than you're forwarding, as those factors will
> be different for different HTLCs.
In theory, but I could lie about both, and it's very undesirable to
communicate these things anyway. I think it might make it worse, not
better, than having a fixed (per-msat?) rate.
Cheers,
Rusty.

2023-06-09 14:58:59

- reply

📅 Original date posted:2020-02-20
📝 Original message:
Hi all!
It seems that messaging over lightning is A Thing, and I want to
use it for the offers protocol anyway. So I've come up with the
simplest proposal I can, and even implemented it.
Importantly, it's unreliable. Our implementation doesn't
remember across restarts, limits us to 1000 total remembered forwards
with random drop, and the protocol doesn't (yet?) include a method for
errors.
This is much friendlier on nodes than using an HTLC (which
requires 2 round trips, signature calculations and db commits), so is an
obvious candidate for much more than just invoice requests.
The WIP patch is small enough I've pasted it below, but it's
also at https://github.com/lightningnetwork/lightning-rfc/pull/748
diff --git a/01-messaging.md b/01-messaging.md
index 40d1909..faa5b18 100644
--- a/01-messaging.md
+++ b/01-messaging.md
@@ -56,7 +56,7 @@ The messages are grouped logically into five groups, ordered by the most signifi
- Setup & Control (types `0`-`31`): messages related to connection setup, control, supported features, and error reporting (described below)
- Channel (types `32`-`127`): messages used to setup and tear down micropayment channels (described in [BOLT #2](02-peer-protocol.md))
- Commitment (types `128`-`255`): messages related to updating the current commitment transaction, which includes adding, revoking, and settling HTLCs as well as updating fees and exchanging signatures (described in [BOLT #2](02-peer-protocol.md))
- - Routing (types `256`-`511`): messages containing node and channel announcements, as well as any active route exploration (described in [BOLT #7](07-routing-gossip.md))
+ - Routing (types `256`-`511`): messages containing node and channel announcements, as well as any active route exploration or forwarding (described in [BOLT #7](07-routing-gossip.md))
- Custom (types `32768`-`65535`): experimental and application-specific messages
The size of the message is required by the transport layer to fit into a 2-byte unsigned int; therefore, the maximum possible size is 65535 bytes.
diff --git a/04-onion-routing.md b/04-onion-routing.md
index 8d0f343..84eff9a 100644
--- a/04-onion-routing.md
+++ b/04-onion-routing.md
@@ -51,6 +51,7 @@ A node:
* [Legacy HopData Payload Format](#legacy-hop_data-payload-format)
* [TLV Payload Format](#tlv_payload-format)
* [Basic Multi-Part Payments](#basic-multi-part-payments)
+ * [Directed Messages](#directed-messages)
* [Accepting and Forwarding a Payment](#accepting-and-forwarding-a-payment)
* [Payload for the Last Node](#payload-for-the-last-node)
* [Non-strict Forwarding](#non-strict-forwarding)
@@ -62,6 +63,7 @@ A node:
* [Returning Errors](#returning-errors)
* [Failure Messages](#failure-messages)
* [Receiving Failure Codes](#receiving-failure-codes)
+ * [Directed Message Replies](#directed-message-replies)
* [Test Vector](#test-vector)
* [Returning Errors](#returning-errors)
* [References](#references)
@@ -366,6 +368,13 @@ otherwise meets the amount criterion (eg. some other failure, or
invoice timeout), however if it were to fulfill only some of them,
intermediary nodes could simply claim the remaining ones.
+### Directed Messages
+
+Directed messages have an onion with an alternate `hop_payload`
+format. If this node is not the intended recipient, the payload is
+simply a 33-byte pubkey indicating the next recipient. Otherwise, the
+payload is the message for this node.
+
# Accepting and Forwarding a Payment
Once a node has decoded the payload it either accepts the payment locally, or forwards it to the peer indicated as the next hop in the payload.
@@ -1142,6 +1151,11 @@ The _origin node_:
- MAY use the data specified in the various failure types for debugging
purposes.
+## Directed Message Replies
+
+Directed message replies are encoded the same way as failure messages,
+except the contents is a directed message for the originator.
+
# Test Vector
## Returning Errors
diff --git a/07-routing-gossip.md b/07-routing-gossip.md
index ec1a8f0..4c2b836 100644
--- a/07-routing-gossip.md
+++ b/07-routing-gossip.md
@@ -1,4 +1,4 @@
-# BOLT #7: P2P Node and Channel Discovery
+# BOLT #7: P2P Node and Channel Discovery and Directed Messages
This specification describes simple node discovery, channel discovery, and channel update mechanisms that do not rely on a third-party to disseminate the information.
@@ -31,6 +31,7 @@ multiple `node_announcement` messages, in order to update the node information.
* [HTLC Fees](#htlc-fees)
* [Pruning the Network View](#pruning-the-network-view)
* [Recommendations for Routing](#recommendations-for-routing)
+ * [Directed Messages](#directed-messages)
* [References](#references)
## Definition of `short_channel_id`
@@ -1103,6 +1104,37 @@ A->D's `update_add_htlc` message would be:
And D->C's `update_add_htlc` would again be the same as B->C's direct payment
above.
+# Directed Messages
+
+Directed messages allow peers to use existing connections to query for
+invoices (see [BOLT 12](12-offer-encoding.md)). Like gossip messages,
+they are not associated with a particular local channel. Like HTLCs,
+they use [BOLT 4](04-onion-routing.md#directed-messages) protocol for
+end-to-end encryption.
+
+Directed messages are unreliable: in particular, they are designed to
+be cheap and not to need to be committed to a database (though an
+implementation may choose to). Each one has an optional reply, which
+is [onion encoded](04-onion-routing.md#directed-message-replies) 0just
+like HTLC errors.
+
+## The `directed` and `directed_reply` Messages
+
+1. type: 385 (`directed`) (`option_directed_messages`)
+2. data:
+ * [`1366*byte`:`onion_routing_packet`]
+
+1. type: 386 (`directed_reply`) (`option_directed_messages`)
+2. data:
+ * [`sha256`:`onion_routing_packet_hash`]
+ * [`u16`:`len`]
+ * [`len*byte`:`reply`]
+
+## Requirements
+
+FIXME: similar to update_add_htlc and update_fail_htlc.
+FIXME: define reasonable timeout after which you can forget if not replied?
+
## References
1. <a id="reference-1">[RFC 1950 "ZLIB Compressed Data Format Specification version 3.3](https://www.ietf.org/rfc/rfc1950.txt)</a>

2023-06-09 14:58:58

- reply

📅 Original date posted:2020-02-24
📝 Original message:
Anthony Towns <aj at erisian.com.au> writes:
> On Fri, Feb 21, 2020 at 12:35:20PM +1030, Rusty Russell wrote:
>> And if there is a grace period, I can just gum up the network with lots
>> of slow-but-not-slow-enough HTLCs.
>
> Well, it reduces the "gum up the network for <timeout> blocks" to "gum
> up the network for <grace period> seconds", which seems like a pretty
> big win. I think if you had 20 hops each with a 1 minute grace period,
> and each channel had a max_accepted_htlcs of 30, you'd need 25 HTLCs per
> second to block 1000 channels (so 2.7% of the 36k channels 1ml reports),
> so at the very least, successfully performing this attack would be
> demonstrating lightning's solved bitcoin's transactions-per-second
> limitation?
But the comparison here is not with the current state, but with the
"best previous proposal we have", which is:
1. Charge an up-front fee for accepting any HTLC.
2. Will hang-up after grace period unless you either prove a channel
close, or gain another grace period by decrypting onion.
(There was is an obvious extension to this, where you pay another HTLC
first which covers the (larger) up-front fee for the "I know the next
HTLC is going to take a long time").
That proposal is simpler, and covers this case quite nicely.
> at which point the best B can do is unilaterally close the B/C channel
> with their pre-HTLC commitment, but they still have to wait for that to
> confirm before they can safely cancel the HTLC with A, and that will
> likely take more than whatever the grace period is, so B will be losing
> money on holding fees.
>
> Whereas:
>
> A->B: here's a HTLC, locked in
>
> B->C: HTLC proposal
> C->B: sure: updated commitment with HTLC locked in
> B->C: great, corresponding updated commitment, plus revocation
> C->B: revocation
>
> means that if C goes silent before B receives a new commitment, B can
> cancel the HTLC with A with no risk (B can publish the old commitment
> still even if the new arrives later, and C can only publish the pre-HTLC
> commitment), and if C goes silent after B receives the new commitment, B
> can drop the new commitment to the blockchain and pay A's fees out of it.
Interesting; this adds a trip, but not in latency (since C can still
count on the HTLC being locked in at step 3).
I don't see how it helps B though? It still ends up paying A, and C
doesn't pay anything?
It forces a liveness check of C, but TBH I dread rewriting the state
machine for this when we can just ping like we do now.
>> There's an old proposal to fast-fail HTLCs: Bob sends an new message "I
>> would fail this HTLC once it's committed, here's the error"
>
> Yeah, you could do "B->C: proposal, C->B: no way!" instead of "sure" to
> fast fail the above too.
>
> And I think something like that's necessary (at least with my view of how
> this "keep the HTLC open" payment would work), otherwise B could send C a
> "1 microsecond grace period, rate of 3e11 msat/minute, HTLC for 100 sat,
> timeout of 2016 blocks" and if C couldn't reject it immediately would
> owe B 50c per millisecond it took to cancel.
Well, surely grace period (and penalty rate) are either fixed in the
protocol or negotiated up-front, not per-HTLC.
Cheers,
Rusty.

2023-06-09 14:58:57

- reply

📅 Original date posted:2020-02-21
📝 Original message:
Anthony Towns <aj at erisian.com.au> writes:
> On Tue, Feb 18, 2020 at 10:23:29AM +0100, Joost Jager wrote:
>> A different way of mitigating this is to reverse the direction in which the
>> bond is paid. So instead of paying to offer an htlc, nodes need to pay to
>> receive an htlc. This sounds counterintuitive, but for the described jamming
>> attack there is also an attacker node at the end of the route. The attacker
>> still pays.
>
> I think this makes a lot of sense. I think the way it would end up working
> is that the further the route extends, the greater the payments are, so:
>
> A -> B : B sends A 1msat per minute
> A -> B -> C : C sends B 2msat per minute, B forwards 1msat/min to A
> A -> B -> C -> D : D sends C 3 msat, etc
> A -> B -> C -> D -> E : E sends D 4 msat, etc
>
> so each node is receiving +1 msat/minute, except for the last one, who's
> paying n msat/minute, where n is the number of hops to have gotten up to
> the last one. There's the obvious privacy issue there, with fairly
> obvious ways to fudge around it, I think.
Yes, it needs to scale with distance to work at all. However, it has
the same problems with other upfront schemes: how does E know to send
4msat per minute?
> I think it might make sense for the payments to have a grace period --
> ie, "if you keep this payment open longer than 20 seconds, you have to
> start paying me x msat/minute, but if it fulfills or cancels before
> then, it's all good".
But whatever the grace period, I can just rely on knowing that B is in
Australia (with a 1 second HTLC commit time) to make that node bleed
satoshis. I can send A->B->C, and have C fail the htlc after 19
seconds for free. But B has to send 1msat to A. B can't blame A or C,
since this attack could come from further away, too.
This attack always seems possible. Are you supposed to pay immediately
to fail an HTLC? That makes for a trivial attack, so I guess not.
And if there is a grace period, I can just gum up the network with lots
of slow-but-not-slow-enough HTLCs.
> Maybe this also implies a different protocol for HTLC forwarding,
> something like:
>
> 1. A sends the HTLC onion packet to B
> 2. B decrypts it, makes sure it makes sense
> 3. B sends a half-signed updated channel state back to A
> 4. A accepts it, and forwards the other half-signed channel update to B
>
> so that at any point before (4) Alice can say "this is taking too long,
> I'll start losing money" and safely abort the HTLC she was forwarding to
> Bob to avoid paying fees; while only after (4) can she start the time on
> expecting Bob to start paying fees that she'll forward back. That means
> 1.5 round-trips before Bob can really forward the HTLC on to Carol;
> but maybe it's parallelisable, so Bob/Carol could start at (1) as soon
> as Alice/Bob has finished (2).
We added a ping-before-commit[1] to avoid the case where B has disconnected
and we don't know yet; we have to assume an HTLC is stuck once we send
commitment_signed. This would be a formalization of that, but I don't
think it's any better?
There's an old proposal to fast-fail HTLCs: Bob sends an new message "I
would fail this HTLC once it's committed, here's the error" and if Alice
gets it before she sends the commitment_signed, she sends a new
"unadd_htlc" message first. This theoretically allows Bob to do the
same: optimistically forward it, and unadd it if Alice doesn't commit
with it in time.[2]
Cheers,
Rusty.
[1] Technically, if we haven't seen any traffic from the peer in the
last 30 seconds, we send a ping and wait.
[2] This seems like a speedup, but it only is if someone fails the HTLC.
We still need to send the commitment_signed back and forth (w/
revoke and ack) before committing to it in the next hop.

2023-06-09 14:58:55

- reply

📅 Original date posted:2020-02-20
📝 Original message:
Bastien TEINTURIER <bastien at acinq.fr> writes:
> Exactly what Matt said.
>
> I would also add that libp2p aims to be a kind of swiss-army knife for p2p
> networking: that's nice for many use-cases, but when security is your main
> focus, it's not.
> Look at TLS: most attacks are downgrade attacks because the protocol offers
> way too many options.
> Protocols like Wireguard have perfectly understood this. No options, not
> many configuration hooks -> small, auditable codebase.
>
> For lightning it's the same: we prefer a very simple transport that has no
> options whatsoever.
> Simple to implement, simple to test, and works great in practice.
To add to this: at Milan we chose a raw protocol instead of using
protobufs. At the time I was unsure, but being able to specify each
message down to the bit level has meant we've never really had problems
at that level.
But it did mean we wasted time arguing over endianness, etc!
Cheers,
Rusty.

2023-06-09 14:58:41

- reply

📅 Original date posted:2020-02-20
📝 Original message:
lisa neigut <niftynei at gmail.com> writes:
>> With PoDLE this would not be possible I think, as you would not be able
> to open the PoDLE commitment with the other node as the target (if we go
> with the modified PoDLE which also commits to which node an opening is for,
> to prevent the pouncing venus flytrap attack).
>
> Good question. It should be possible to do multi-channel open even with the
> PoDLE signature committing to a node_id.
>
> - An initiator can use the same utxo (h2) as their proof for multiple
> peers; the signatures passed to each peer will have to commit to that
> specific peer's node_id, however.
> - The revised PoDLE signature commitment requires every initiator to
> include at least one of their own inputs in the tx. Attempting to initiate
> an additional open etc using someone else's utxo's won't work (this is the
> pouncing venus flytrap attack which we're preventing). The initiator
> including at least one input is expected behavior, at least in the open
> case, since the opener has to cover the fees for the funding output.
> - Ideally, a node would remove the PoDLE TLV data from any 'forwarded'
> `tx_add_inputs` that isn't the input they're proving for, to prevent
> leaking information about which inputs belong to other parties. I say
> ideally here because even if you fail to do this, the peer can iterate
> through all the provided commitment proofs until one of them
> matches/verifies with the upfront provided PoDLE.
Yes, you need to PoDLE your own contribution I think, which means you
need one UTXO per contributor in the N-way-open who you want to
contribute a UTXO.
Consider Alice trying to create a single-tx to open a channel with both
Bob and Carol, and wants *both* of them to also contribute.
Alice sends her own UTXO1 with proof to Bob, he shares his UTXO back.
Alice sends her own UTXO2 with proof to Carol, she shares a UTXO back.
Alice sets the lower bit on the serial_id from Bob and sends to Carol,
and sets the lower on the serial_id from Carol and sends to Bob. She
similarly reflects everything from Carol to Bob and vice-versa, and
sends both of them the two "channel opening" outputs.
Now all parties have the same tx; unless Bob and Carol chose the same
serial_ids (spec says random, but Bob and Carol don't get along). But
this is trivially identifiable, and you give up on mutual opening.
Cheers,
Rusty.

2023-06-09 14:58:40

- reply

📅 Original date posted:2020-02-13
📝 Original message:
ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org> writes:
> Good morning niftynei,
>
>
>> Rusty had some suggestions about how to improve the protocol messages for this, namely adding a serial_id to the inputs and outputs, which can then be reused for deletions.
>>
>> The serial id can then also be used as the ordering heuristic for transaction inputs during construction (replacing current usage of BIP69). Inputs can be shared amongst peers by flipping the bottom bit of the serial_id before relaying them to another peer (as your own).
>
> What happens if the initiator deliberately provides serial IDs 0x1, 0x3, .... while the acceptor naively provides serial IDs from `/dev/urandom`?
This is a feature, and one you might need to use if you have some
SIGHASH_SINGLE or other weirdness for one input.
> Then the balance of probability is that the initiator inputs and outputs are sorted before the acceptor.
> Now, this is probably not an issue, since the initiator and acceptor both know which inputs and outputs are theirs and not theirs, so they could just reveal this information to anyone, so an actor providing such lousy serial IDs is just hurting its own privacy relative to blockchain analysts, so probably will not happen in practice.
>
> My initial reaction was to propose adding a secret-sharing round where the resulting key is XORed to each serial ID before sorting by the XORed serial ID, but this might be too overweight, and again the initiator is only hurting its own privacy, and the two participants already know whose money is whose anyway....
>> > - nLocktime is always set to 0x00000000
>>
>> - If a blockheight to be used as nLocktime is communicated in the initiation step, is set to blockheight-6; otherwise set to zero-
>
> I am unsure what is the purpose of this minus 6.
>
> If you fear blockheight disagreements, this is probably a good time to introduce block headers.
> So for example if the acceptor thinks the initiator blockheight is too high, it could challenge the initiator to give block headers from its known blockheight to the initiator blockheight.
> If the acceptor thinks the initiator blockheight is too low, it could provide block headers itself as proof.
> This could be limited so that gross differences in blockheight are outright rejected by the acceptor (it could `error` the temporary channel ID rather than accept it).
Yes, I would just have the initiator specify nLocktime directly, just
like feerate. If you don't like it, don't contribute to the tx
construction.
> This is SPV, but neither side is actually making or accepting a payment *yet*, just synchronizing clocks, so maybe not as bad as normal SPV.
>
> Massive chain reorgs cannot reduce blockheight, only increase it (else
> the reorg attempt fails in the first place)
This is not quite true, due to difficulty adjustments. It's true in
practice, however, and not relevant since you'd just have to wait one
more block.
>> - Serial ids should be chosen at random
>> - For multiparty constructions, the initiator MUST flip the bottom bit of any received inputs before relaying them to a peer.
>>
>> - Collisions of serial ids between peers is a protocol error
>
> I suppose we should define collision to mean "equal in all bits except the lowest bit".
No, literally equal. i.e. you can only make this error by clashing with
yourself.
Cheers,
Rusty.

2023-06-09 14:58:36

- reply

📅 Original date posted:2020-02-13
📝 Original message:
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.

2023-06-09 14:58:35

- reply

📅 Original date posted:2020-02-10
📝 Original message:
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.

2023-06-09 14:58:34

- reply

📅 Original date posted:2020-02-04
📝 Original message:
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.

2023-06-09 14:58:33

- reply

📅 Original date posted:2020-02-04
📝 Original message:
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.
And then I realized that Alice can't do this properly without Bob
telling her what the scid he used to route was.
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.
Now Mallory uses Bob->C2 to pay to N1 for Inv1. If it works, he knows
it's the same node issuing both invoices.
So, update_add_htlc needs a new scid field.
At this point, I think we should just add a new channel_flag, which if
you set it (and feature flag is offered) you get assigned random SCID
from the peer in funding_locked. This overrides your
funding-transaction-based SCID.
That gets the first case for new channels, without adding much
complexity at all.[1]
Thoughts?
Rusty.
[1] If we want to cover existing channels, we need a new "give me a
replacement scid" msg and reply. But it can be idempotent (you
only ever get one replacement).

2023-06-09 14:58:33

- reply

📅 Original date posted:2020-02-04
📝 Original message:
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.

2023-06-09 14:58:31

- reply

📅 Original date posted:2020-02-03
📝 Original message:
Bastien TEINTURIER <bastien at acinq.fr> writes:
> We can easily get rid of (1.) by leveraging the `payment_secret`. The
> improved scheme is:
>
> * Alice draws a random `decoy_key`
> * Alice computes the corresponding `decoy_node_id = decoy_key * G`
> * Alice draws a random `payment_secret`
> * Alice computes `decoy_short_channel_id = H(payment_secret * decoy_key *
> bob_node_id) xor short_channel_id`
> * Alice uses the `decoy_key` to sign the invoice
> * Carol recovers `decoy_node_id` from the invoice signature
> * Carol includes `P_I = payment_secret * decoy_node_id` in the onion
> payload for Bob
> * Bob can compute `short_channel_id = H(bob_private_key * P_I) xor
> decoy_short_channel_id`
>
> But I don't see how to get rid of (2.). If anyone has a clever idea on how
> to do that, I'd love to hear it!
I really don't want a special marker on Carol; she needs to just pay
like normal. Not just because it's simple, but because it means that
Carol can use a custodial wallet without having to flag the payment as
somehow special.
AFAICT, having Bob assign scids is the only viable way to do this. The
current proposal limits to one scid at a time, but it could be extended
to allow multiple scids.
(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?).
I've updated and somewhat simplified the PR now.
Cheers,
Rusty.

2023-06-09 14:57:33

- reply

📅 Original date posted:2019-12-03
📝 Original message:
ZmnSCPxj <ZmnSCPxj at protonmail.com> writes:
> Good morning Rusty,
>
>> > Hi all,
>> > I recently revisited the eltoo paper and noticed some things related
>> > watchtowers that might affect channel construction.
>> > Due to NOINPUT, any update transaction can spend from any other, so
>> > in theory the tower only needs the most recent update txn to resolve
>> > any dispute.
>> > In order to spend, however, the tower must also produce a witness
>> > script which when hashed matches the witness program of the input. To
>> > ensure settlement txns can only spend from exactly one update txn,
>> > each update txn uses unique keys for the settlement clause, meaning
>> > that each state has a unique witness program.
>>
>> I didn't think this was the design. The update transaction can spend
>> any prior, with a fixed script, due to NOINPUT.
>>
>> The settlement transaction does not use NOINPUT, and thus can only
>> spend the matching update.
>
> My understanding is that this is not logically possible?
You're right, no wonder I missed this problem :(
OK, so we need to change the key(s) every time. Can we tweak it based
on something the watchtower will know, i.e. something in the update tx
itself? Obviously not the output, as that would create a circular
dependency. Is there some taproot thing we can use to insert some
noise in the input?
Cheers,
Rusty.

2023-06-09 14:57:32

- reply

📅 Original date posted:2019-12-02
📝 Original message:
Conner Fromknecht <conner at lightning.engineering> writes:
> Hi all,
>
> I recently revisited the eltoo paper and noticed some things related
> watchtowers that might affect channel construction.
>
> Due to NOINPUT, any update transaction _can_ spend from any other, so
> in theory the tower only needs the most recent update txn to resolve
> any dispute.
>
> In order to spend, however, the tower must also produce a witness
> script which when hashed matches the witness program of the input. To
> ensure settlement txns can only spend from exactly one update txn,
> each update txn uses unique keys for the settlement clause, meaning
> that each state has a _unique_ witness program.
I didn't think this was the design. The update transaction can spend
any prior, with a fixed script, due to NOINPUT.
The settlement transaction does *not* use NOINPUT, and thus can only
spend the matching update.
Cheers,
Rusty.

2023-06-09 14:57:21

- reply

📅 Original date posted:2019-11-05
📝 Original message:
It was pointed out to me[1] at thelightningconference.com that it's often
a legal requirement to list the vendor on a receipt. It also makes
perfect sense.
It can be done in the description field, but that's really supposed to
be a description of the *items*. Dividing it also lets wallets have
much better UX.
The spec change itself is genuinely trivial:
* `v` (12): `data_length` variable. Optional name of vendor/supplier (UTF-8).
Feedback from wallets and vendors appreciatedg!
Rusty.
PS. Pull req at https://github.com/lightningnetwork/lightning-rfc/pull/694,
but I realize that can be intimidating, hence this mail.
[1] I'd like to credit this properly, but I was jetlagged and having way
too much fun. Please claim if this was your idea :)

2023-06-09 14:57:20

- reply

📅 Original date posted:2019-11-13
📝 Original message:
Yaacov Akiba Slama <ya at slamail.org> writes:
> So we can integrate between them without intermixing the semantics of
> the protocols but we need only to define the interaction points between
> them.
>
> In the previous worflow, the seller can for instance add in the LN
> invoice H(Quotation (UBL)||Order(UBL)||Prepayment Invoice(UBL)), and use
> H(Receipt(UBL)) as preimage. With such a workflow, the UBL documents are
> cryptographically tied to the LN payment.
>
> So the property of UBL of not being machine *handlable* is not altered
> but the LN cryptographic properties are still used to tie the workflow.
>
> Am I missing something?
Sure, people can do this today: simply set your `d` field to "UBL:
<hash>".
But it provide what we want from offers:
1. Does not provide a "static invoice" flow.
2. Does not provide a donation flow.
3. Does not provide a method for wallets to do recurrence.
4. Does not provide end-to-end over LN (i.e. no HTTP(s) requests).
Cheers,
Rusty.

2023-06-09 14:57:19

- reply

📅 Original date posted:2019-11-13
📝 Original message:
Yaacov Akiba Slama <ya at slamail.org> writes:
> Seller: Quotation (UBL)
>
> Buyer: Order (UBL)
>
> Seller: Prepayment Invoice (UBL)
>
> Seller: Invoice (LN)
>
> Buyer/Seller: Payment & Ack (LN)
>
> Buyer: Receipt (UBL)
>
>
> The advantage of such workflow are that we don't need to add any fields
> to the current invoice structure, nor to define in the LN protocol new
> messages like offer or invoice request, nor to intervene in the semantic
> of the business workflow and in the required/optional fields in these
> messages.
This would be UBL treating Lightning as a dumb payment layer, which is a
little like faxing email, and not a use case I'd be promoting for
Lightning.
To be clear: the full UBL spec is machine *parsable* but definitely not
designed to be machine *handlable*. This makes sense, since a machine
cannot generally choose between quotations or interpret general contract
terms.
However, for the simpler (but very common!) case of an offer->purchase
flow, we can define a subset of UBL for which this *can* be done, and a
further-limited subset which must be examined by the user
(e.g. description of goods, price details, shipping info).
In addition, the atomic nature of LN needs to be baked into the
protocol; in LN taking the payment *requires* a cryptographic receipt,
and neutering this property would be horribly short-sighted.
We need to define UBL extensions for the LN fields to tie them all
together (e.g. payment_hash, node_id). We also need to define a
transport mechanism for these over the Lightning Network.
This is all quite possible! But it will take time and is a signficant
amount of work: I need to be sure that others feel the same way before I
embark on this project.
Cheers,
Rusty.
>> It's also worth noting that, even compressed, none of the UBL examples
>> fit into the 1023 byte limit of the existing invoice format:
>>
>> UBL-Quotation-2.1-Example.xml: 1864 bytes (gz)
>> UBL-Order-2.1-Example.xml: 2515 bytes (gz)
>> UBL-Invoice-2.1-Example.xml: 3163 bytes (gz)
>>
>> Indeed, that Quotation alone requires a 32x32 QR code.
>>
>>>> However, since invoices/offers and UBL are both structures, we
>>>> should have an explicit mapping between the two. What fields should
>>>> have their own existence in the invoice/offer and what should be in a
>>>> general UBL field is a question we have to think on further.
>>> I agree that we don't want duplication. This is the reason, I propose to
>>> use only ubl structure and add in the ln standard invoice an ubl
>>> "opaque" field which will be self-contained and only add in the
>>> invoice/offer/.. the fields specific to ln.
>> Except we need to go through the UBL spec and indicate exactly what
>> fields are permitted, and which are required.
>>
>> Many UBI fields are not amenable to machine interpretation (eg. note
>> fields). These must be either explicitly exposed to the buyer (in case
>> the seller uses them) such as shipping conditions, or explicitly
>> forbidden/ignored.
>>
>> This is not a small task, and required intimiate knowledge of the UBL
>> spec. It's not enough just to make something *look* like UBL.
>>
>> Does anyone have expertise in this area? Shall we form a sub-group to
>> investigate this properly?
>>
>> Thanks!
>> Rusty.
>>

2023-06-09 14:57:18

- reply

📅 Original date posted:2019-11-11
📝 Original message:
Ross Dyson <me at rossdyson.com> writes:
> Hi Rusty,
>
> We spoke in detail about this after your presentation at LNconf. I'm one of
> the contributors to LNURL so I am a little familiar with what you're trying
> to achieve and am very grateful you're considering implementing something
> similar to the mainnet protocol.
>
> I can only see delivery address being a nightmare for the network or wallet
> providers. If you take a quick look at any Shopify website right now and
> try to buy something to be delivered you will see validation of address
> inputs before accepting payment.
>
> This is the 'expected' UX of consumer applications in 2019. If offers were
> to not validate address inputs correctly the user will not receive the
> product, lose money, and have a [very] negative review of both the
> wallet-providing and the offer-providing businesses.
>
> Handling these UX expectations will require either the wallet provider or
> the offer provider to validate the inputs before proceeding with the sale.
>
> 1. If the offer provider handles validation then the network will have
> to accommodate potentially infinite validation attempts (big no no I assume)
> 2. If the wallet provider were to provide the UX for input validation
> they are taking on significant workload to develop a robust address input
> UI, but more importantly the responsibility to correctly validate. There is
> plenty of room to screw up and create a catastrophic user experience.
>
> So I think address validation input is only possible via 2. but I think it
> is too much workload and responsibility to expect from wallet providers.
This is not the area I worry about, TBH, since every shopping website in
existence has implemented address input (and some form of validation).
I'm sure it'll be primitive to start with.
Of course, UBL has a standard 'AddressType' too:
http://docs.oasis-open.org/ubl/os-UBL-2.2/xsd/common/UBL-CommonAggregateComponents-2.2.xsd
>>From what I can see, it would not be impossible to bring delivery address
> functionality into offers retroactively after offers was already in prod.
> Perhaps icebox it?
Quite possibly something we can delay; most current goods are virtual
anyway. However, delivery address standardization would greatly improve
the UX for such things.
Cheers,
Rusty.

2023-06-09 14:57:17

- reply

📅 Original date posted:2019-11-08
📝 Original message:
Yaacov Akiba Slama <ya at slamail.org> writes:
> Hi Rusty,
>
> It seems that there are two kind of TLV fields in your proposition:
> 1) LN specific fields like `num_paths` and `payment_preimage`.
> 2) "Business" fields like `address1` and `currency`.
> I understand the need to define and include the first category, but I
> don't think that we need or can define the second category. These fields
> already exists in software like crm, erp, etc.. and are well defined by
> standard body.
> My suggestion is to have a generic field containing well defined
> structured and standardized data. See for instance
> https://en.wikipedia.org/wiki/EDIFACT and/or
> https://en.wikipedia.org/wiki/Universal_Business_Language.
Hi Yaacov,
I've been pondering this since reading your comment on the PR!
As a fan of standards, I am attracted to UBL (I've chaired an
OASIS TC in the past and have great respect for them); as a fan of
simplicity I am not. Forcing UBL implementation on wallet providers is
simply not going to happen, whatever I were to propose.
We also don't want duplication; what if the "UBL field" were to
say I were selling you a bridge for $1 and the description and amount
fields actually said I was selling you a coffee for $3?
However, since invoices/offers and UBL are both structures, we
should have an explicit mapping between the two. What fields should
have their own existence in the invoice/offer and what should be in a
general UBL field is a question we have to think on further.
Anyway, you'll have to bear with me as I read this 172 page
standard...
Cheers,
Rusty.
> What do you think?
> PS: Sorry for crossposting here and in
> https://github.com/lightningnetwork/lightning-rfc/pull/694
> --yas
>
> On 05/11/2019 06:23, Rusty Russell wrote:
>> Hi all,
>>
>> This took longer than I'd indicated; for that I'm sorry.
>> However, this should give us all something to chew on. I've started
>> with a draft "BOLT 12" (it might be BOLT 13 by the time it's finalized
>> though!).
>>
>> I've also appended indications where we touch other BOLTs:
>> 1. BOLT 7 gains a message/reply system, encoded like htlc onions and
>> failure messages.
>> 2. BOLT 11 gains a `q` field for quantity; this avoids changing the
>> description when the user requests an invoice for more than one of something
>> (since changing the description between offer and invoice requires user
>> interaction: it's the *invoice* which you are committing to).
>>
>> There's definite handwaving in here; let's see if you can find it!
>>
>> Cheers,
>> Rusty.
>>
>> # BOLT #12: Offer Protocols for Lightning Payments
>>
>> An higher-level, QR-code-ready protocol for dealing with invoices over
>> Lightning. There are two simple flows supported: in one, a user gets
>> an offer (`lno...`) and requests an invoice over the lightning
>> network, obtaining one (or an error) in reply. In the other, a user
>> gets an invoice request (`lni...`), and sends the invoice over the
>> lightning network, retreiving an empty reply.
>>
>> # Table of Contents
>>
>> * [Offers](#offers)
>> * [Encoding](#encoding)
>> * [TLV Fields](#tlv-fields)
>> * [Invrequests](#invrequests)
>> * [Encoding](#encoding)
>> * [TLV Fields](#tlv-fields)
>>
>> # Offers
>>
>> Offers supply a reader with enough information to request one or more
>> invoices via the lightning network itself.
>>
>> ## Encoding
>>
>> The human-readable part of a Lightning offer is `lno`. The data part
>> consists of three parts:
>>
>> 1. 0 or more [TLV](01-messaging.md#type-length-value-format) encoded fields.
>> 2. A 32-byte nodeid[1]
>> 3. 64-byte signature of SHA256(hrp-as-utf8 | tlv | nodeid).
>>
>> ## TLV Fields
>>
>> The TLV fields define how to get the invoice, and what it's for.
>> Each offer has a unique `offer_idenfitier` so the offering node can
>> distinguish different invoice requests.
>>
>> Offers can request recurring payments of various kinds, and specify
>> what base currency they are calculated in (the actual amount will be
>> in the invoice).
>>
>> `additional_data` is a bitfield which indicates what information the
>> invoice requester should (odd) or must (even) supply:
>> 1. Bits `0/1`: include `delivery_address`
>> 2. Bits `2/3`: include `delivery_telephone_number`
>> 3. Bits `4/5`: include `voucher_code`
>> 4. Bits `6/7`: include `refund_proof`
>>
>> `refund_for` indicates an offer for a (whole or part) refund for a
>> previous invoice, as indicated by the `payment_hash`.
>>
>> 1. tlvs: `offer`
>> 2. types:
>> 1. type: 1 (`paths`)
>> 2. data:
>> * [`u16`:`num_paths`]
>> * [`num_paths*path`:`path`]
>> 1. type: 2 (`description`)
>> 2. data:
>> * [`...*byte`:`description`]
>> 1. type: 3 (`expiry`)
>> 2. data:
>> * [`tu64`:`seconds_from_epoch`]
>> 1. type: 4 (`offer_identifier`)
>> 2. data:
>> * [`...*byte`:`id`]
>> 1. type: 5 (`amount`)
>> 2. data:
>> * [`4*byte`:`currency`]
>> * [`tu64`:`amount`]
>> 1. type: 6 (`additional_data`)
>> 2. data:
>> * [`...*byte`:`rbits`]
>> 1. type: 7 (`recurrance`)
>> 2. data:
>> * [`byte`:`time_unit`]
>> * [`u32`:`period`]
>> * [`tu32`:`number`]
>> 1. type: 8 (`recurrance_base`)
>> 2. data:
>> * [`u32`:`basetime`]
>> * [`tu32`:`paywindow`]
>> 1. type: 9 (`quantity`)
>> 2. data:
>> * [`tu64`:`max`]
>> 1. type: 10 (`refund_for`)
>> 2. data:
>> * [`32*byte`:`payment_hash`]
>>
>> 1. subtype: `path`
>> 2. data:
>> * [`u16`:`num_hops`]
>> * [`num_hops*hop`:`hops`]
>>
>> 1. subtype: `hop`
>> 2. data:
>> * [`pubkey`:`nodeid`]
>> * [`short_channel_id`:`short_channel_id`]
>> * [`u16`:`flen`]
>> * [`flen*byte`:`features`]
>>
>> ## Requirements For Offers And Invrequests
>>
>> A writer of an offer or an invrequest:
>> - if it is connected only by private channels:
>> - MUST include `paths` containing a path to the node.
>> - otherwise:
>> - MAY include `paths` containing a path to the node.
>> - MUST describe the item(s) being offered or purpose of invoice in `description`.
>> - MUST include `expiry` if the offer/invrequest will not be valid after some time.
>> - if it includes `expiry`:
>> - MUST set `seconds_from_epoch` to the expiry time in seconds since 1970 UTC.
>>
>> ## Requirements For Offers
>>
>> A writer of an offer:
>> - MUST use a unique `offer_idenfitier` for each offer.
>> - MAY include `recurrence` to indicate offer should trigger time-spaced
>> invoices.
>> - MUST include `amount` if it includes `recurrence`.
>> - if it includes `amount`:
>> - MUST specify `currency` as the ISO 4712 or BIP-0173, padded with zero bytes if required
>> - MUST specify `amount` to the amount expected for the invoice, as the ISO 4712 currency unit multiplied by exponent, OR the BIP-0173 minimum unit (eg. `satoshis`).
>> - if it requires specific fields in the invoice:
>> - MUST set the corresponding even bits in the `additional_data` field
>>
>> A reader of an offer:
>> - SHOULD gain user consent for recurring payments.
>> - SHOULD allow user to view and cancel recurring payments.
>> - SHOULD gain user consent to send `delivery_` fields.
>> - if it uses `amount` to provide the user with a cost estimate:
>> - MUST warn user if amount of actual invoice differs significantly
>> from that expectation.
>> - FIXME: more!
>>
>> ## Recurrance
>>
>> Some offers are *periodic*, such as a subscription service or monthly
>> dues, in that payment is expected to be repeated. There are many
>> different flavors of repetition, consider:
>>
>> * Payments due on the first of every month, for 6 months.
>> * Payments due on every Monday, 1pm Pacific Standard Time.
>> * Payments due once a year:
>> * which must be made on January 1st, or
>> * which are only valid if started January 1st 2020, or
>> * which if paid after January 1st you (over) pay the full rate first year, or
>> * which if paid after January 1st are paid pro-rata for the first year, or
>> * which repeat from whenever you made the first payment
>>
>> Thus, each payment has:
>> 1. A `time_unit` defining 0 (seconds), 1 (days), 2 (months), 3 (years).
>> 2. A `period`, defining how often (in `time_unit`) it has to be paid.
>> 3. An optional `number` of total payments to be paid.
>> 4. An optional `basetime`, defining when the first payment applies
>> in seconds since 1970-01-01 UTC.
>> 5. An optional `paywindow`, defining how many seconds into the period
>> a payment will be accepted: 0xFFFFFFFF being a special value meaning
>> "any time during the period, but you will have to pay proportionally
>> to the remaining time in the period".
>>
>> Note that the `expiry` field covers the case where an offer is no longer
>> valid after January 1st 2020.
>>
>> ## Default Offer
>>
>> The "default offer" of a node is a nominal offer used to send
>> unsolicited payments. It is generally not actually sent, but can be
>> used by any other node as if it has been. It has the following
>> fields:
>>
>> * `offer_idenfitier`: zero-length
>> * `d`: any
>> * `n`: the node id of the recipient.
>>
>> ## Invoice Request Encoding
>>
>> Once it has an offer, the node can request an actual invoice using the
>> `invoice_req` message inside `directed`'s `onion_routing_packet`. It
>> would expect an `invoice_or_error_tlv` inside the `directed_reply`
>> message.
>>
>> This includes a `tag` it can use to identify replies, the
>> `offer_idenfitier` from the offer, a `key` it can use to prove it was
>> the requester of this invoice, a `recurrence` number if this
>> is a payment in a recurring series, and other codes as required.
>>
>> The `refund_proof` refers to a previous invoice paid by the sender for
>> the specific case of a `refund_for` offer. It provides proof of
>> payment (the `payment_preimage` and also a signature of the
>> `payment_hash` from the `key` which requested the being-refunded
>> invoice (which does *not* have to be the same as this `key`!).
>>
>> 1. tlvs: `invoice_request_tlv`
>> 2. types:
>> 1. type: 1 (`tag`)
>> 2. data:
>> * [`...*byte`:`tag`]
>> 1. type: 2 (`offer_identifier`)
>> 2. data:
>> * [`...*byte`:`id`]
>> 1. type: 3 (`key`)
>> 2. data:
>> * [`32`:`key`]
>> 1. type: 4 (`recurrence`)
>> 2. data:
>> * [`tu64`:`number`]
>> 1. type: 5 (`quantity`)
>> 2. data:
>> * [`tu64`:`n`]
>> 1. type: 6 (`delivery_address_name`)
>> 2. data:
>> * [`...*byte`:`name`]
>> 1. type: 7 (`delivery_address1`)
>> 2. data:
>> * [`...*byte`:`address1`]
>> 1. type: 8 (`delivery_address2`)
>> 2. data:
>> * [`...*byte`:`address2`]
>> 1. type: 9 (`delivery_city`)
>> 2. data:
>> * [`...*byte`:`city`]
>> 1. type: 10 (`delivery_state_province_or_region`)
>> 2. data:
>> * [`...*byte`:`state_province_or_region`]
>> 1. type: 11 (`delivery_zip_or_postal_code`)
>> 2. data:
>> * [`...*byte`:`zip_or_postal_code`]
>> 1. type: 12 (`delivery_country`)
>> 2. data:
>> * [`2*byte`:`country_code`]
>> 1. type: 13 (`delivery_telephone_number`)
>> 2. data:
>> * [`...*byte`:`tel`]
>> 1. type: 14 (`voucher_code`)
>> 2. data:
>> * [`...*byte`:`code`]
>> 1. type: 15 (`refund_proof`)
>> 2. data:
>> * [`32*byte`:`payment_preimage`]
>> * [`signature`:`signature`]
>>
>> ## Requirements
>>
>> FIXME: many more
>> Sender MUST use ISO 3166 alpha-2 code for `delivery_country`.
>> Sender MUST set offer_identifier to match offer.
>> Sender MUST include `key`
>> - SHOULD use a transient unpredictable key
>> - MUST reuse key for successive recurring invoices.
>> Sender MUST set `recurrence` for recurring invoices.
>>
>> Receiver MUST check `offer_identifier`
>> Receiver MUST check `delivery_` fields.
>> Receiver MUST check `recurrence`.
>> Receiver MUST check `amount`.
>>
>> 1. tlvs: `invoice_or_error_tlv`
>> 2. types:
>> 1. type: 1 (`tag`)
>> 2. data:
>> * [`...*byte`:`tag`]
>> 1. type: 3 (`omitted`)
>> 2. data:
>> * [`...*u64`:`omitted_fields`]
>> 1. type: 4 (`invoice`)
>> 2. data:
>> * [`...*byte`:`invoice`]
>> 1. type: 5 (`message`)
>> * [`...*byte`:`message`]
>> 1. type: 6 (`replacement`)
>> 2. data:
>> * [`signature`:`signature`]
>> * [`...*byte`:`offer`]
>>
>> Sender:
>> - MUST copy `tag` from sender.
>> - MUST omit fields it does not use, and place number in order in `omitted_fields`.
>> - if it includes `invoice`:
>> - MUST not include `message`
>> - MUST not include `replacement`
>> - MUST [merkle fields it used](#merkle-calculation) and place that in invoice `s` field.
>> - otherwise, if it includes `replacement`:
>> - MAY include `message`
>> - otherwise:
>> - MUST include `message` describing the error.
>>
>> Receiver:
>> - MUST check that `tag` matches req.
>> - if `replacement`:
>> - MUST fail if `signature` does not sign `offer` with same key as original.
>> - MUST only fetch once (no double-redirects!)
>> - if description or amount significantly changes, must re-ask user.
>> - SHOULD note if description simply has something appended (eg "+ postage").
>> - within invoice:
>> - MUST check that `s` matches merkle of fields, minus `omitted`.
>> - MUST check that no vital fields are in `omitted`.
>> - MUST check that `d` matches `description`
>> - MUST check that `q` DNE if `quantity` DNE, otherwise is equal.
>> - Must check valid signature, etc.
>>
>> ## Merkle Calculation
>>
>> 1. For each `invoice_req_tlv` field in ascending `tlv` type order:
>> 1. If the field was omitted, it is added to `omitted_fields`.
>> 2. Otherwise, the immediate parent merkle is:
>>
>> SHA256(SHA256(`tag` | `be64-n`) | SHA256(`tlv-value`))
>>
>> Where `be64-n` is a 64-bit big-endian counter starting at 0 and
>> incrementing for each leaf.
>>
>> 3. Order these nodes in increasing SHA256(`tag` | `be64-n`) order.
>>
>> 2. Create additional leaves until `be64-n` is the next power of 2:
>>
>> SHA256(`tag` | `be64-n`)
>>
>> 3. Combine adjacent leaves using SHA256(leaf1 | leaf2) until none remain.
>>
>> By creating adjacent leaves using the `tag` field and a counter, and
>> sorting the leaves, the only significant information revealed by a
>> merkle proof on a node is the depth of tree (which implies the total
>> number of TLV fields).
>>
>> # InvRequests
>>
>> There are times when it makes sense to request an invoice over another
>> medium, such as HTTP or a QR code.
>>
>> ## Encoding
>>
>> The human-readable part of a Lightning invrequest is `lni`. The data part
>> consists of three parts:
>>
>> 1. 0 or more [TLV](01-messaging.md#type-length-value-format) encoded fields.
>> 2. A 32-byte nodeid[1]
>> 3. 64-byte signature of SHA256(hrp-as-utf8 | tlv | nodeid).
>>
>> ## TLV Fields
>>
>> 1. tlvs: `invreq`
>> 2. types:
>> 1. type: 1 (`paths`)
>> 2. data:
>> * [`u16`:`num_paths`]
>> * [`num_paths*path`:`path`]
>> 1. type: 2 (`description`)
>> 2. data:
>> * [`...*byte`:`description`]
>> 1. type: 3 (`expiry`)
>> 2. data:
>> * [`tu64`:`seconds_from_epoch`]
>> 1. type: 4 (`amount`)
>> 2. data:
>> * [`tu64`:`millisatoshis`]
>>
>> The fields `paths`, `description`, and `expiry` fields are the
>> same as those for offers; the optional `amount` field describes the
>> amount an invoice will be accepted for.
>>
>> Upon parsing and accepting an `invreq`, the node sends an
>> `invoice_or_error_tlv` within an onion. The reply is empty.
>>
>> ## Requirements
>>
>> The requirements for `paths`, `description` and `expiry` are
>> [described above](#requirements-for-offers-and-invrequests).
>>
>> FIXME: More.
>>
>> [1] Assuming we go for Schnorr sigs and 32-byte pubkeys.
>> ----
>> Addendum: BOLT #7: P2P Node and Channel Discovery and Directed Messages
>> ...
>> # Directed Messages
>>
>> Directed messages allow peers to use existing connections to query for
>> invoices (see [BOLT 12](12-offer-encoding.md)). Like gossip messages,
>> they are not associated with a particular local channel.
>>
>> The `id` is a unique, transient identifier between the peers, used to
>> identify match messages and replies.
>>
>> ## The `directed` and `directed_reply` Messages
>>
>> 1. type: 384 (`directed`) (`option_directed_messages`)
>> 2. data:
>> * [`chain_hash`:`chain_hash`]
>> * [`u64`:`id`]
>> * [`1366*byte`:`onion_routing_packet`]
>>
>> 1. type: 384 (`directed_reply`) (`option_directed_messages`)
>> 2. data:
>> * [`chain_hash`:`chain_hash`]
>> * [`u64`:`id`]
>> * [`u16`:`len`]
>> * [`len*byte`:`reply`]
>>
>> ## Requirements
>>
>> FIXME: similar to update_add_htlc and update_fail_htlc.
>> FIXME: define reasonable timeout after which you can forget if not replied?
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 14:57:16

- reply

📅 Original date posted:2019-11-08
📝 Original message:
ZmnSCPxj <ZmnSCPxj at protonmail.com> writes:
> First, please confirm my understanding of the message flow.
> Suppose I have a donation offer on my website and Rusty wants to donate to me.
> Then:
>
> ZmnSCPxj Rusty
> | |
> +---------- `lno` ---------->+ (via non-Lightning communication channel e.g. https)
> | |
> +<---- `invoice_request` ----+ (via a normal Rusty->ZmnSCPxj payment)
> | |
> +---- `invoice_or_error` --->| (by failing the above payment and embedding in the failure blob)
> | |
> +<------- `sendpay` ---------+ (via a normal Rusty->ZmnSCPxj payment)
>
> Is it approximately correct?
Sorry for delayed response; yes, this is correct.
>> gets an invoice request (`lni...`), and sends the invoice over the
>> lightning network, retreiving an empty reply.
>
> Here are completely pointless counterproposals for the offer and invoice-request HRPs:
>
> * Offers:
> * `lnpayme`
> * `lnbuyit`
> * `lnforsale`
> * Invoice Requests:
> * `lnpaying`
> * `lnbuying`
> * `lnshutupandtakemymoney`
>
> `lno` and `lni` feel wrong to me.
> Their juxtaposition implies `lno` == output and `lni` == input to me, due to the use of `o` and `i`, though `lno` is where you get money in exchange for product and `lni` is the request-for-service.
lnx and lny? Nobody can interpret them at all, that way :)
>> 3. type: 2 (`description`)
>> 4. data:
>> - [`...*byte`:`description`]
>
> UTF-8?
> Null-terminated?
I was thinking UTF-8 like current field.
>> - MUST include `amount` if it includes `recurrence`.
>> - if it includes `amount`:
>> - MUST specify `currency` as the ISO 4712 or BIP-0173, padded with zero bytes if required
>
> I cannot find ISO 4712, but could find ISO 4217.
Oops, I fixed my typo wrong. Thanks.
> BIP-173 does not have a list of currencies, but refers to SLIP-0173.
> Some of the listed currencies there seem to have more than 4 characters.
Oh, I'd never seen SLIP-0173. Cool, I increased it to 5; SLIP-0173 has
no limit but I find it hard to care about any of them anyway.
> Should I assume encoding is ASCII?
> We will "never" see a non-ASCII currency code?
Not really, but if you don't understand it you can't do much, ASCII or
no.
>> The "default offer" of a node is a nominal offer used to send
>> unsolicited payments. It is generally not actually sent, but can be
>> used by any other node as if it has been. It has the following
>> fields:
>>
>> - `offer_idenfitier`: zero-length
>> - `d`: any
>> - `n`: the node id of the recipient.
>
> In essence, this is an implicitly-existing offer that never expires, and which can be used by any node at any time to construct an invoice request?
Yep!
>> The `refund_proof` refers to a previous invoice paid by the sender for
>> the specific case of a `refund_for` offer. It provides proof of
>> payment (the `payment_preimage` and also a signature of the
>> `payment_hash` from the `key` which requested the being-refunded
>> invoice (which does not have to be the same as this `key`!).
>
> An earlier requirement mentions that writers of offers or invoice request MUST have `paths` in some condition.
> The below does not have `paths`, but there is a "human-readable" alternate encoding which *does* have `paths`.
> It might be better to clarify this point.
The in-wire one doesn't have paths, since you respond by reply; you
don't need (and should not be able to) find the sender.
The non-wire one needs a path, since you need to initiate a reply.
>> The `directed` and `directed_reply` Messages
>>
>> ---------------------------------------------
>>
>> 1. type: 384 (`directed`) (`option_directed_messages`)
>> 2. data:
>> - [`chain_hash`:`chain_hash`]
>> - [`u64`:`id`]
>> - [`1366*byte`:`onion_routing_packet`]
>> 3. type: 384 (`directed_reply`) (`option_directed_messages`)
>> 4. data:
>> - [`chain_hash`:`chain_hash`]
>> - [`u64`:`id`]
>> - [`u16`:`len`]
>> - [`len*byte`:`reply`]
>
> This new `directed` message will be the mechanism for sending invoice requests and receiving invoice request responses?
Yes.
> What incentive is there for a forwarding node to actually forward a `directed` message?
It's a strong liveness indicator to the sender, so they're likely to use
the same path for the actual payment.
Cheers,
Rusty.

2023-06-09 14:57:13

- reply

📅 Original date posted:2019-11-08
📝 Original message:
Joost Jager <joost.jager at gmail.com> writes:
>>
>> > Isn't spam something that can also be addressed by using rate limits for
>> > failures? If all relevant nodes on the network employ rate limits, they
>> can
>> > isolate the spammer and diminish their disruptive abilities.
>>
>> Sure, once the spammer has jammed up the network, he'll be stopped. So
>> will everyone else. Conner had a proposal like this which didn't work,
>> IIRC.
>
> Do you have ref to this proposal?
>
> Imagine the following setup: a network of nodes that trust each other (as
> far as spam is concerned) applies a 100 htlc/sec rate limit to the channels
> between themselves. Channels to untrusted nodes get a rate of only 1
> htlc/sec. Assuming the spammer isn't a trusted node, they can only spam at
> 1 htlc/s and won't jam up the network?
Damn, I searched for it but all the obvious keywords turned up blank.
Conner CC'd in case he remembers the discussion and I'm not imagining it?
Anyway, if there are 100 nodes in the network I can still open a channel
to each one and jam it up immediately. And that's not even assuming I
play nice until you trust me, then attack or get taken over.
Cheers,
Rusty.

2023-06-09 14:57:12

- reply

📅 Original date posted:2019-11-07
📝 Original message:
Joost Jager <joost.jager at gmail.com> writes:
> In my opinion, the prepayment should be a last resort. It does take away
> some of the attractiveness of the Lightning Network. Especially if you need
> to make many payment attempts over long routes, the tiny prepays do add up.
> For a $10 payment, it's probably nothing to worry about. But for
> micro-payments this can become prohibitively expensive. And it is exactly
> the micro-payment use case where Lightning outshines other payment systems.
> A not yet imagined micro-payment based service could even be the launchpad
> to world domination. So I think we should be very careful with interfering
> with that potential.
I completely agree, yeah. And maybe we'll never need it, but it's one
of my main concerns for the network.
> Isn't spam something that can also be addressed by using rate limits for
> failures? If all relevant nodes on the network employ rate limits, they can
> isolate the spammer and diminish their disruptive abilities.
Sure, once the spammer has jammed up the network, he'll be stopped. So
will everyone else. Conner had a proposal like this which didn't work,
IIRC.
> If a node sees that its outgoing htlc packets stack up, it can reduce
> the incoming flow on the channels where the htlcs originate
> from. Large routing nodes could agree with their peers on service
> levels that define these rate limits.
Unfortunately, if we *don't* address this, then the network will defend
itself with the simple tactic of deanonymizing payments.
And every other solution I've seen ends up the same way :(
Cheers,
Rusty.

2023-06-09 14:57:11

- reply

📅 Original date posted:2019-11-06
📝 Original message:
Olaoluwa Osuntokun <laolu32 at gmail.com> writes:
> Hi Rusty,
>
> Agreed w.r.t the need for prepaid HTLCS, I've been mulling over other
> alternatives for a few years now, and none of them seems to resolve the
> series of routing related incentive issues that prepaid HTLCs would.
>
>> Since both Offers and Joost's WhatSat are looking at sending messages,
>> it's time to float actual proposals.
>
> IMO both should just be done over HORNET, so we don't need introduce a new
> set of internal protocol level messages whenever we have some new
> control/signalling need. Instead, we'd have a control/signal channel (give
> me
> routes, invoices, sign this, etc), and a payment channel (HTLCs as used
> today).
I'm not so sure, as I don't think we're going to actually use each one
more than once or twice?
I mean, we could stream movies through LN, but I think that's an added
service, which would be best done by HORNET.
>> 2. Adding an HTLC causes a *push* of a number of msat on commitment_signed
>> (new field), and a hash.
>
> The prepay amount should be signalled in the update add message instead.
> This lets HTLCs carry a heterogeneous set of prepay amounts. In addition, we
> need a new onion field as well to signal the incoming amount the node
> _should_ have received (allows them to detect deviations in the sender's
> intended route).
Sorry, brain fart: it's a new field in the update_add_htlc of course.
I just, um, added that to make sure you were all reading carefully! :_
>> 3. Failing/succeeding an HTLC returns some of those msat, and a count and
>> preimage (new fields).
>
> Failing shouldn't return the prepay amount, otherwise extending long lived
> HTLCs then cancelling them at the last minute is still costless. This
> costlessness of _adding_ an HTLC to a _remote_ commitment is IMO, the
> biggest incentive flaw that exists today in the greater routing network.
No, that's type (liquidity) 3 spam, which needs a completely different
solution.
Definitely needs fixing, but up-front fees don't do it (except in the
case where you might want to indicate you're *going* to have a long-held
HTLC, where you'd pay additional up-front, but that's future work).
>> You get to keep 50 msat[1] per preimage you present[2].
>
> We should avoid introducing any new constants to the protocol, as they're
> typically dreamed up independent of any empirical lessons learned from
> deployment.
OTOH, we should avoid creating more complex knobs for users, since the
complexity of the protocol is becoming unmanagable. I think we did this
too much with v1, so instead of getting empirical data we got defaults
which in practice are unspecified specifications.
I like a flat value to start, since it's easy to implement and deploy.
> On the topic of the prepay cost, the channel update message should be
> extended to allow nodes to signal prepay costs similar to the way we handle
> regular payment success fees. In order to eliminate a number of costless
> attacks possible today on the routing network, nodes should also be able to
> signal a new coefficient used to _scale_ the prepay fee as a function of the
> CLTV value of the incoming HTLC.
... and HTLC amount, surely? That becomes a pretty complex tuning
parameter.
I think we should directly target type 3 spam through a separate
mechanism (as discussed previously). This is just to prevent quantity
of messages.
> With this addition, senders need to pay to
> _add_ an HTLC to a remote commitment transaction (fixed base cost), then
> also need to pay a variable rate that scales with the duration of the
> proposed outgoing CLTV value (senders ofc don't prepay to themselves). Once
> we introduce this, loop attacks and the like are no longer free to launch,
> and nodes can dynamically respond to congestion in the network by raising
> their prepay prices.
I disagree; you should signal with normal fees, not prepay. Otherwise
we're increasing fees at a time that success rates are lowering, which
makes the incentive misalightment far more promiment :(
Cheers,
Rusty.

2023-06-09 14:57:10

- reply

📅 Original date posted:2019-11-22
📝 Original message:
Bastien TEINTURIER <bastien at acinq.fr> writes:
> 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?
If we can't come up with an untracable scheme, this is what we'll have
to do (i.e. remove the sats component).
Unfortunately botnets are really good at generating these. That was
always the hashcash flaw (which is why it was never actually used).
Using a dynamic level is possible, too, so it gets harder in case we're
being spam attacked.
Cheers,
Rusty.
> 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
>>

2023-06-09 14:57:07

- reply

📅 Original date posted:2019-11-08
📝 Original message:
Anthony Towns <aj at erisian.com.au> writes:
> On Thu, Nov 07, 2019 at 02:56:51PM +1030, Rusty Russell wrote:
>> > What you wrote to Zmn says "Rusty decrypts the onion, reads the prepay
>> > field: it says 14, LLLL." but Alice doesn't know anything other than
>> > ZZZZ so can't put LLLL in the onion?
>> Alice created the onion. Alice knows all the preimages, since she
>> created the chain AAAAA....ZZZZZ.
>
> In your reply to Zmn, it was Rusty (Bob) preparing the nonce and creating
> the chain AAAA...ZZZZ -- so I was lost as to what you were proposing...
Oops. Don't trust that Rusty guy, let's stick with Alice.
[ Snip summary, which is correct ]
> As far as the "fair price" goes, the spitballed formula is "16 - X/4"
> where X is number of zero bits in some PoW-y thing. The proposal is
> the thing is SHA256(blockhash|revealedonion) which works, and (I think)
> means each step is individually grindable.
>
> I think an alternative would be to use the prepayment hashes themselves,
> so you generate the nonce AAAA as the value you'll send to Dave then
> hash it repeatedly to get BBBB..QQQQ, then check if pow(AAAA,BBBB) has
> 60 leading zero bits or pow(AAAA,CCCC) has 56 leading zero bits etc.
> If you made pow(a,b) be SHA256(a,b,shared-onion-key) I think it'd
> preserve privacy, but also mean you can't meaningfully grind unfairly
> cheap routing except for very short paths?
>
> If you don't grind and just go by luck, the average number of hashes
> per hop is ~15.93 (if I got my maths right), so you should be able to
> estimate path length pretty accurate by dividing claimed prepaid funds by
> 15.93*25msat or whatever. If everyone grinds at each level independently,
> I think you'd just subtract maybe 6 hops from that, but the maths would
> mostly stay the same?
>
> Though I think you could obfusticate that pretty well by moving
> some of the value from the HTLC into the prepayment -- you'd risk losing
> that extra value if the payment made it all the way to the recipient but
> they declined the HTLC that way though.
Yeah, and doesn't help obscure in the in-the-middle failure case unf.
Which is really bad with current payment_hash since you can spot
multiple attempts so easily. Hence my attempt to roll in some PoW to
obscure the amounts.
The ideal prepay range would be wider, so you can believably have
payments between 16 and 4 per hop, say. But if I can grind it I'll
naturally restrict the range to the lower end, and if it's ungrindable
(eg. based on nodeid and payment_hash or recent block hash) then
everyone on the path knows what it so too.
So, hashcash here is better than nothing, but still not very good.
>> >> Does Alice lose everything on any routing failure?
>> > That was my thought yeah; it seems weird to pay upfront but expect a
>> > refund on failure -- the HTLC funds are already committed upfront and
>> > refunded on failure.
>> AFAICT you have to overpay, since anything else is very revealing of
>> path length. Which kind of implies a refund, I think.
>
> I guess you'd want to pay for a path length of about 20 whether the
> path is actually 17, 2, 10 or 5. But a path length of 20 is just paying
> for bandwidth for maybe 200kB of total traffic which at $1/GB is 2% of
> 1 cent, which doesn't seem that worth refunding (except for really tiny
> micropayments, where paying for payment bandwidth might not be feasible
> at all).
>
> If you're buying a $2 coffee and paying 500ppm in regular fees per hop
> with 5 hops, then each routing attempt increases your fees by 4%, which
> seems pretty easy to ignore to me.
True, but ideally we'd have lots of noise even if people are trying to
minimize fees (which, if they're sending messages rather than payments,
they might).
Cheers,
Rusty.

2023-06-09 14:57:07

- reply

📅 Original date posted:2019-11-10
📝 Original message:
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.

2023-06-09 14:57:06

- reply

📅 Original date posted:2019-11-07
📝 Original message:
Anthony Towns <aj at erisian.com.au> writes:
> On Wed, Nov 06, 2019 at 10:43:23AM +1030, Rusty Russell wrote:
>> >> Rusty prepares a nonce, AAAAA and hashes it 25 times = ZZZZZ.
>> >> ZmnSCPxj prepares the onion, but adds extra fields (see below).
>> > It would have made more sense to me for Alice (Zmn) to generate
>> > the nonce, hash it, and prepare the onion, so that the nonce is
>> > revealed to Dave (Rusty) if/when the message ever actually reaches its
>> > destination. Otherwise Rusty has to send AAAAA to Zmn already so that
>> > Zmn can prepare the onion?
>> The entire point is to pay *up-front*, though, to prevent spam.
>
> Hmm, I'm not sure I see the point of paying upfront but not
> unconditionally -- you already commit the funds as part of the HTLC,
> and if you're refunding some of them, you kind-of have to keep them
> reserved or you risk finalising the HTLC causing a failure because you
> don't have enough msats spare to do the refund?
? These are upfront an unconditional. I'm confused. You pay per
HTLC added (or, in future, to send a message).
What part was unclear here?
Alice pays X to Bob. Bob gives X-<num-preimages> back to Alice. Bob
gets preimages from the onion, and from Carol etc.
This happens independent of HTLC success or failure.
>> Bob/ZmnSCPxj doesn't prepare anything in the onion. They get handed the
>> last hash directly: Alice is saying "I'll pay you 50msat for each
>> preimage you can give me leading to this hash".
>
> So my example was Alice paying Dave via Bob and Carol (so Alice/Bob,
> Bob/Carol, Carol/Dave being the individual channels).
>
> What you wrote to Zmn says "Rusty decrypts the onion, reads the prepay
> field: it says 14, LLLL." but Alice doesn't know anything other than
> ZZZZ so can't put LLLL in the onion?
Alice created the onion. Alice knows all the preimages, since she
created the chain AAAAA....ZZZZZ.
>> > I'm not sure why lucky hashing should result in a discount?
>> Because the PoW adds noise to the amounts, otherwise the path length is
>> trivially exposed, esp in the failure case. It's weak protection
>> though.
>
> With a linear/exponential relationship you just get "half the time it's
> 1 unit, 25% of the time it's 2 units, 12% of the time it's 3 units", so
> I don't think that's adding much noise?
It depends how much people are prepared to grind, doesn't it?
>> > You've only got two nonce choices -- the initial AAAA and the depth
>> > that you tell Bob and Carol to hash to as steps in the route;
>> No, the sphinx construction allows for grinding, that was my intent
>> here. The prepay hashes are independent.
>
> Oh, because you're also xoring with the onion packet, right, I see.
>
>> > I think you could just make the scheme be:
>> > Alice sends HTLC(k,v) + 1250 msat to Bob
>> > Bob unwraps the onion and forwards HTLC(k,v) + 500 msat to Carol
>> > Carol unwraps the onion and forwards HTLC(k,v) + 250 msat to Dave
>> > Dave redeems the HTLC, claims an extra 300 msat and refunds 200 msat to Carol
>
> The math here doesn't add up. Let's assume I meant:
>
> Bob keeps 500 sat, forwards 750 sat
> Carol keeps 250 sat, forwards 500 sat
> Dave keeps 300 sat, refunds 200 sat
>
>> > Carol redeems the HTLC and refunds 200 msat to Bob
>> > Bob redeems the HTLC and refunds 200 msat to Alice
>> >
>> > If there's a failure, Alice loses the 1250 msat, and someone in the
>> > path steals the funds.
>> This example confuses me.
>
> Well, that makes us even at least? :)
>
>> So, you're charging 250msat per hop? Why is Bob taking 750? Does Carol
>> now know Dave is the last hop?
>
> No, Alice is choosing to pay 500, 250 and 300 msat to Bob, Carol and
> Dave respectively, as part of setting up the onion, and picks those
> numbers via some magic algo trading off privacy and cost.
OK.
>> Does Alice lose everything on any routing failure?
>
> That was my thought yeah; it seems weird to pay upfront but expect a
> refund on failure -- the HTLC funds are already committed upfront and
> refunded on failure.
AFAICT you have to overpay, since anything else is very revealing of
path length. Which kind of implies a refund, I think.
>> If so, that is strong incentive for Alice to reduce path-length privacy
>> by keeping payments minimal, which I was really trying to avoid.
>
> Assuming v is much larger than 1250msat, and 1250 msat is much lower than
> the cost to Bob of losing the channel with Alice, I don't think that's
> a problem. 1250msat pays for 125kB of bandwdith under your assumptions
> I think?
That's irrelevant? Since retries are common, it's natural for Alice to
want to minimize losses. If she's going to lose everything on any
failure, she'll pay the minimum amount, which exposes her path length
trivially.
Thus my attempt to try to reduce the lossage. I think.
>> > Does that miss anything that all the hashing achieves?
>> It does nothing if Carol is the one who can't route.
>
> If Carol can't route, then ideally she just refunds all the money and
> everyone's happy.
That tells Bob clearly that Carol failed. If Carol claims a variable
amount, it's less obvious (though still pretty bad).
> If Carol tries to steal, then she can keep 750 msat instead of 250 msat.
> This doesn't give any way for Bob to prove Carol cheated on him though;
> but Bob could just refund the 1250 msat and write the 750 msat off as a
> loss of dealing with cheaters like Carol.
What actually happens is that Carol sends a signature on a commitment
which Bob does't agree with (since he expected his money back). They go
onchain.
Now Bob is out the total he fwd to Carol, but he's probably more annoyed
at losing the channel.
Cheers,
Rusty.

2023-06-09 14:57:05

- reply

📅 Original date posted:2019-11-05
📝 Original message:
Anthony Towns <aj at erisian.com.au> writes:
> On Tue, Nov 05, 2019 at 07:56:45PM +1030, Rusty Russell wrote:
>> Sure: for simplicity I'm sending a 0-value HTLC.
>> ZmnSCPxj has balance 10000msat in channel with Rusty, who has 1000msat
>> in the channel with YAIjbOJa.
>
> Alice, Bob and Carol sure seem simpler than Zmn YAI and Rusty...
Agreed, I should not have directly answered the q.
>> Rusty prepares a nonce, AAAAA and hashes it 25 times = ZZZZZ.
>> ZmnSCPxj prepares the onion, but adds extra fields (see below).
>
> It would have made more sense to me for Alice (Zmn) to generate
> the nonce, hash it, and prepare the onion, so that the nonce is
> revealed to Dave (Rusty) if/when the message ever actually reaches its
> destination. Otherwise Rusty has to send AAAAA to Zmn already so that
> Zmn can prepare the onion?
The entire point is to pay *up-front*, though, to prevent spam.
Bob/ZmnSCPxj doesn't prepare anything in the onion. They get handed the
last hash directly: Alice is saying "I'll pay you 50msat for each
preimage you can give me leading to this hash".
>> He then
>> sends the HTLC to Rusty, but also sends ZZZZZ, and 25x50 msat (ie. those
>> fields are in the update_add_htlc msg). His balance with Rusty is now
>> 8750msat (ie. 25x50 to Rusty).
>>
>> Rusty decrypts the onion, reads the prepay field: it says 14, LLLLL.
>> Rusty checks: the hash of the onion & block (or something) does indeed
>> have the top 8 bits clear, so the cost is in fact 16 - 8/2 == 14. He
>> then hashes LLLLL 14 times, and yes, it's ZZZZZ as ZmnSCPxj said it
>> should be.
>
> I'm not sure why lucky hashing should result in a discount?
Because the PoW adds noise to the amounts, otherwise the path length is
trivially exposed, esp in the failure case. It's weak protection
though.
> You're giving a linear discount for exponentially more luck in hashing
> which also seems odd.
Because you really want some actual payment, not just PoW. Botnets are
really good at PoW, less good at sending msats. And the PoW is hard to
calibrate (I guessed: real numbers will be necessary)/
> You've only got two nonce choices -- the initial AAAA and the depth
> that you tell Bob and Carol to hash to as steps in the route;
No, the sphinx construction allows for grinding, that was my intent
here. The prepay hashes are independent.
> I think you could just make the scheme be:
>
> Alice sends HTLC(k,v) + 1250 msat to Bob
> Bob unwraps the onion and forwards HTLC(k,v) + 500 msat to Carol
> Carol unwraps the onion and forwards HTLC(k,v) + 250 msat to Dave
> Dave redeems the HTLC, claims an extra 300 msat and refunds 200 msat to Carol
> Carol redeems the HTLC and refunds 200 msat to Bob
> Bob redeems the HTLC and refunds 200 msat to Alice
>
> If there's a failure, Alice loses the 1250 msat, and someone in the
> path steals the funds.
This example confuses me.
So, you're charging 250msat per hop? Why is Bob taking 750? Does Carol
now know Dave is the last hop?
Does Alice lose everything on any routing failure?
If so, that is strong incentive for Alice to reduce path-length privacy
by keeping payments minimal, which I was really trying to avoid.
> You could make the accountable by having Alice
> also provide "Hash(AAAA, refund=200)" to everyone, encoding AAAA in the
> onion to Dave, and then each hop reveals AAAA and refunds 200msat to
> demonstrate their honesty.
>
> Does that miss anything that all the hashing achieves?
It does nothing if Carol is the one who can't route.
> I think the idea here is that you're paying tiny amounts for the
> bandwidth, which when it's successful does in fact pay for the bandwidth;
> and when it's unsuccessful results in a channel closure, which makes it
> unprofitable to cheat the system, but doesn't change the economics of
> lightning much overall because channel closures can happen anytime anyway.
Not at all. You can still fail to route, and still get paid. You can't
steal *more* money without channel closure though.
> I think that approach makes sense.
>
> Cheers,
> aj
Cheers,
Rusty.

2023-06-09 14:57:04

- reply

📅 Original date posted:2019-11-05
📝 Original message:
Hi all,
It's been widely known that we're going to have to have up-front
payments for msgs eventually, to avoid Type 2 spam (I think of Type 1
link-local, Type 2 though multiple nodes, and Type 3 liquidity-using
spam).
Since both Offers and Joost's WhatSat are looking at sending
messages, it's time to float actual proposals. I've been trying to come
up with something for several years now, so thought I'd present the best
I've got in the hope that others can improve on it.
1. New feature bit, extended messages, etc.
2. Adding an HTLC causes a *push* of a number of msat on
commitment_signed (new field), and a hash.
3. Failing/succeeding an HTLC returns some of those msat, and a count
and preimage (new fields).
How many msat can you take for forwarding? That depends on you
presenting a series of preimages (which chain into a final hash given in
the HTLC add), which you get by decoding the onion. You get to keep 50
msat[1] per preimage you present[2].
So, how many preimages does the user have to give to have you forward
the payment? That depends. The base rate is 16 preimages, but subtract
one for each leading 4 zero bits of the SHA256(blockhash | hmac) of the
onion. The blockhash is the hash of the block specified in the onion:
reject if it's not in the last 3 blocks[3].
This simply adds some payment noise, while allowing a hashcash style
tradeoff of sats for work.
The final node gets some variable number of preimages, which adds noise.
It should take all and subtract from the minimum required invoice amount
on success, or take some random number on failure.
This leaks some forward information, and makes an explicit tradeoff for
the sender between amount spent and privacy, but it's the best I've been
able to come up with.
Thoughts?
Rusty.
[1] If we assume $1 per GB, $10k per BTC and 64k messages, we get about
655msat per message. Flat pricing for simplicity; we're trying to
prevent spam, not create a spam market.
[2] Actually, a number and a single preimage; you can check this is
indeed the n'th preimage.
[3] This reduces incentive to grind the damn things in advance, though
maybe that's dumb? We can also use a shorter hash (siphash?), or
even truncated SHA256 (128 bits).

2023-06-09 14:57:04

- reply

📅 Original date posted:2019-11-05
📝 Original message:
ZmnSCPxj <ZmnSCPxj at protonmail.com> writes:
> Good morning Rusty,
Hi ZmnSCPxj!
> Is this intended to be enforceable onchain if a channel is dropped onchain while a message is being routed?
> By a vague sense of the description, it seems to me, it would require a complicated SCRIPT (or multiple tiny 50-msatoshi UTXOs) to enforce onchain.
No, it's done as a simple subtraction from direct to-local and to-remote
payments. Enforcement is by peer closing the channel, which you
wouldn't do over a few msat.
> Also, it is not exactly clear to me, the mechanism you are proposing in detail.
> Can you give a motivating example, for example in a route from
> ZmnSCPxj, through Rusty, to my imaginary friend YAIjbOJa (who is not
> in fact me)?
Sure: for simplicity I'm sending a 0-value HTLC.
ZmnSCPxj has balance 10000msat in channel with Rusty, who has 1000msat
in the channel with YAIjbOJa.
Rusty prepares a nonce, AAAAA and hashes it 25 times = ZZZZZ.
ZmnSCPxj prepares the onion, but adds extra fields (see below). He then
sends the HTLC to Rusty, but also sends ZZZZZ, and 25x50 msat (ie. those
fields are in the update_add_htlc msg). His balance with Rusty is now
8750msat (ie. 25x50 to Rusty).
Rusty decrypts the onion, reads the prepay field: it says 14, LLLLL.
Rusty checks: the hash of the onion & block (or something) does indeed
have the top 8 bits clear, so the cost is in fact 16 - 8/2 == 14. He
then hashes LLLLL 14 times, and yes, it's ZZZZZ as ZmnSCPxj said it
should be.
So Rusty takes the 14x50 as prepayment, and forwards the HTLC as
normal to YAIjbOJa, along with LLLLL and 11x50msat. His balance with
YAIjbOJa is now 450msat.
YAIjbOJa decrypts the onion. And it says 10,BBBBB. YAIjbOJa checks
that hashing BBBBB 10 times does indeed give LLLLL. Now it takes the
11x50 msat, and fulfils the HTLC. It replies to Rusty with 10,BBBBB
in the update_fulfill_htlc message, returning the (implicit) 1x50msat;
Rusty's balance with YAIjbOJa is now 500msat.
Rusty checks that BBBBB hashed 10 times gives LLLLL. Now it returns
24,BBBBB to ZmnSCPxj with the update_fulfill_htlc, demonstrating to
ZmnSCPxj that he's entitled to it, and (implicity) returning 1x50msat to
ZmnSCPxj, so their balance is now 8800msat.
Now let's look at attacks:
1. Rusty steals the funds and doesn't return them. ZmnSCPxj closes
channel, having lost 26x50msat.
2, YAIjbOJa steals the funds and doesn't return them. Rusty closes
the channel, having lost 11x50msat.
3. ZmnSCPxj doesn't put correct preimages in, or too few, or other
malformation. If it's Rusty's onion, he won't forward it and will
give an error. If it's YAIjbOJa who rejects it, Rusty returns all
but the 14x50msat he has preimages for.
Obviously Rusty needs some upper limit on how much he'll pay out, to
avoid infinite exposure (say limit the total exposure to 10,000 sats).
A reasonable limit for each HTLC would be 20 hops x 16 x 50msat ==
16sat. Even with no other limits, with 486 HTLCs in flight each way,
that's only 15456 satoshis. You'll probably lament the channel closure
more.
Hope that helps!
Rusty.
>> Hi all,
>>
>> It's been widely known that we're going to have to have up-front
>> payments for msgs eventually, to avoid Type 2 spam (I think of Type 1
>> link-local, Type 2 though multiple nodes, and Type 3 liquidity-using
>> spam).
>>
>> Since both Offers and Joost's WhatSat are looking at sending
>> messages, it's time to float actual proposals. I've been trying to come
>> up with something for several years now, so thought I'd present the best
>> I've got in the hope that others can improve on it.
>>
>> 1. New feature bit, extended messages, etc.
>> 2. Adding an HTLC causes a push of a number of msat on
>> commitment_signed (new field), and a hash.
>>
>> 3. Failing/succeeding an HTLC returns some of those msat, and a count
>> and preimage (new fields).
>>
>> How many msat can you take for forwarding? That depends on you
>> presenting a series of preimages (which chain into a final hash given in
>> the HTLC add), which you get by decoding the onion. You get to keep 50
>> msat[1] per preimage you present[2].
>>
>> So, how many preimages does the user have to give to have you forward
>> the payment? That depends. The base rate is 16 preimages, but subtract
>> one for each leading 4 zero bits of the SHA256(blockhash | hmac) of the
>> onion. The blockhash is the hash of the block specified in the onion:
>> reject if it's not in the last 3 blocks[3].
>>
>> This simply adds some payment noise, while allowing a hashcash style
>> tradeoff of sats for work.
>>
>> The final node gets some variable number of preimages, which adds noise.
>> It should take all and subtract from the minimum required invoice amount
>> on success, or take some random number on failure.
>>
>> This leaks some forward information, and makes an explicit tradeoff for
>> the sender between amount spent and privacy, but it's the best I've been
>> able to come up with.
>>
>> Thoughts?
>> Rusty.
>>
>> [1] If we assume $1 per GB, $10k per BTC and 64k messages, we get about
>> 655msat per message. Flat pricing for simplicity; we're trying to
>> prevent spam, not create a spam market.
>> [2] Actually, a number and a single preimage; you can check this is
>> indeed the n'th preimage.
>> [3] This reduces incentive to grind the damn things in advance, though
>> maybe that's dumb? We can also use a shorter hash (siphash?), or
>> even truncated SHA256 (128 bits).
>>
>>
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 14:57:01

- reply

📅 Original date posted:2019-11-11
📝 Original message:
Joost Jager <joost.jager at gmail.com> writes:
>>
>> > We could
>> > simplify this to a single to_self_delay that is proposed by the
>> initiator,
>> > but what was the original reason to allow distinct values?
>>
>> Because I didn't fight hard enough for simplicity :(
>>
>
> But the people you were fighting with, what reason did they have? Just
> flexibility in general, or was there an actual use case? Maybe these people
> are reading this email and can comment?
Compromise among the committee meant adding everything to the spec if
there was a conceivable reason for it; the simplicity argument was less
strong then (maybe because we hadn't implemented it all yet!).
> So then because unilateral close is the only way to resolve atm, it is
> correct also in theory that there will never be a commitment tx where the
> non-initiator pays fees? But the point is clear, channels can get stuck.
Yeah. Generally, it doesn't happen because we insist on a reasonable
balance in the channel, but it's theoretically possible.
>> > If we hard-code a constant, we won't be able to adapt to changes of
>> > `dustRelayFee` in the bitcoin network. And we'd also need to deal with a
>> > peer picking a value higher than that constant for its regular funding
>> flow
>> > dust limit parameter.
>>
>> Note that we can't adapt to dustRelayFee *today*, since we can't change
>> it after funding (another thing we probably need to fix).
>>
>
> You can't for an existing channel, but at least for a new channel you can
> pick a different value. Which wouldn't be possible if we'd put a fixed
> (anchor) amount in the spec.
That's not really much consolation though for the existing network.
Still Matt assures me that the relay dust limit is not going to change,
so I think we're best off cutting down our test matrix by choosing a
value and putting it directly into the spec.
By my calculations, at minfee it will cost you ~94 satoshis to spend.
Dust limit is 294 for Segwit outputs (basically assuming 3x minfee).
So I'm actually happy to say "anchor outputs are 294 satoshi". These
are simply spendable, and still only $3 each if BTC is $1M. Lower is
better (as long as we stick with funder-pays), as long as they do
eventually get spent.
>> If we really want to make it adjustable, could we make each side pay for
>> its own; if you can't afford it, you don't get one? There's no point
>> the funder paying for a fundee-anchor if the fundee has no skin in the
>> game.
>>
>> That reduces the pressure somewhat, I think?
>>
>
> If you can't afford you don't get one, not sure about that. I could open a
> channel, send out the total capacity an in htlc to myself via some other
> hops, force close with a very low commit fee, then pull in the htlc (one
> time the money). The victim then needs to get the commit confirmed to claim
> the money, but there is no anchor unfortunately. I wait for the htlc to
> expire, then anchor down the commit tx and time out the htlc (twice the
> money).
Excellent point. And the complexity of some "you can only use a little
bit of capacity until I have an anchor too" is worse, so let's stick
with your proposal as the simplest: funder pays for two, always.
>> Or what about we rotate the anchors and nothing else, which (assuming we
>> make it anyone-can-spend-after-N-blocks) reduces the amount of onchain
>> spam if someone completely loses their keys?
>>
>> That's a bigger change, but maybe it's worth it?
> We now have David's great proposal to reuse the funding keys for the anchor
> output. That allows us to always let anyone spend after confirmation,
> because they can reconstruct the spend script. But I think this also means
> that we cannot do rotation on the anchor keys. We need to use the funding
> pubkey as is.
I missed that proposal, thanks!
It's stronger than my scheme, in that it works even if neither anchor is
spent; which, if we keep update_fee, is a distinct possibility. And
makes the script shorter (my fee calc above assume this).
We *could* tweak both anchors by the same amount, but then you'd still
need to see one of them to spend the other.
Cheers,
Rusty.

2023-06-09 14:57:00

- reply

📅 Original date posted:2019-11-05
📝 Original message:
Joost Jager <joost.jager at gmail.com> writes:
>>
>> > * Add `to_remote_delay OP_CHECKSEQUENCEVERIFY OP_DROP` to the `to_remote`
>> > output. `to_remote_delay` is the csv delay that the remote party accepted
>> > in the funding flow for their outputs. This not only ensures that the
>> > carve-out works as intended, but also removes the incentive to game the
>> > other party into force-closing. If desired, both parties can still agree
>> =
>> to
>> > have different `to_self_delay` values.
>>
>> I think we should unify to_self_delay if we're doing this. Otherwise
>> the game returns.
>
> The game returns, but both parties will be aware of the game they are
> playing. They agreed to their peer's to_self_delay up front. (This is
> different from the current situation where both peers are forced to accept
> a remote_to_self_delay of 0.) With validation on the open/accept_channel
> message, a node can still enforce both to_self_delays to be equal. We could
> simplify this to a single to_self_delay that is proposed by the initiator,
> but what was the original reason to allow distinct values?
Because I didn't fight hard enough for simplicity :(
There is no "negotiation" on opening; it's accept or error. That leads
to a situation where every implementation MUST accept what every
implementation offers.
The unification proposal was to use the max of the two settings. That's
fair; if you want me to suffer a 2 week delay, you should too.
>> Agreed, this doesn't really work. We actually needed a bitcoin rule
>> that allowed a single anyone-can-spend output. Seems like we didn't get
>> that.
>
> With the mempool acceptance carve-out in bitcoind 0.19, we indeed won't be
> able to safely produce a single OP_TRUE output for anyone to spend. An
> attacker could attach low fee child transactions, reach the limits and
> block further fee bumping.
Indeed :(
>> This is horribly spammy. At the moment we see ~ one unilateral close
>> every 3 blocks. Hopefully that will reduce, but there'll always be
>> some.
>
> It seems there isn't another way to do the anchor outputs given the mempool
> limitations that exist? Each party needs to have their own anchor,
> protected by a key. Otherwise it would open up these attack scenarios where
> an attacker blocks the commitment tx confirmation until htlcs time out.
> Even with the script OP_DEPTH OP_IF <pubkey> OP_CHECKSIG OP_ELSE 10 OP_CSV
> OP_ENDIF, the "anyones" don't know the pubkey and still can't sweep after
> 10 blocks.
I think you're right, but I don't *like* it...
>> * Within each version of the commitment transaction, both anchors always
>> > have equal values and are paid for by the initiator.
>>
>> Who pays if they can't afford it? What if they push_msat everything to
>> the other side?
>
> Similar to how it currently works. There should never be a commitment
> transaction in which the initiator cannot pay the fee.
Unfortunately, this is not correct (in theory).
We can always get into a case where fees are insufficient (simultanous
HTLC adds), but it's unusual. We used to specify that the non-funder
would pay the remaining fee, but we dropped this in favor of allow
unilateral close if this ever happened.
> With anchor outputs
> there should never be a commitment tx in which the initiator cannot pay the
> fee and the anchors.
There can be, but I think we can simply modify this so you have to pay
the anchors *first* before fees.
> Also currently you cannot push everything to the other
> side with push_msat. The initiator still needs to have enough balance to
> pay for the on-chain costs (miner fee and anchors).
This is true; I forgot we fixed that, sorry. push_msat is a red herring.
>> The value of the
>> > anchors is the dust limit that was negotiated in the `open_channel` or
>> > `accept_channel` message of the party that publishes the transaction.
>>
>> Now initiator has to care about the other side's dust limit, which is
>> bad. And as accepter I now want this much higher, since I get those
>> funds instantly. I don't think we gain anything by making this
>> configurable at all; just pick a number and be done.
>>
>> Somewhere between 1000 and 10,000 sat is a good idea.
>>
>
> Yes, it is free money. Therefore we need to validate the dust limit in the
> funding flow. Check whether it is reasonable. That should also be done in
> the current implementation. Otherwise your peer can set a really high dust
> limit that lets your htlc disappear on-chain (although that is only free
> money for the miner).
True, and spec should note this BTW! I've added an issue.
https://github.com/lightningnetwork/lightning-rfc/issues/696
> If we hard-code a constant, we won't be able to adapt to changes of
> `dustRelayFee` in the bitcoin network. And we'd also need to deal with a
> peer picking a value higher than that constant for its regular funding flow
> dust limit parameter.
Note that we can't adapt to dustRelayFee *today*, since we can't change
it after funding (another thing we probably need to fix).
If we really want to make it adjustable, could we make each side pay for
its own; if you can't afford it, you don't get one? There's no point
the funder paying for a fundee-anchor if the fundee has no skin in the
game.
That reduces the pressure somewhat, I think?
> Interesting. I wasn't aware of the brute-force method that watchtowers
> could potentially use. I wanted to bring up the removal of key rotation
> just in case everyone would agree we don't need it anymore. It isn't
> required for the anchor outputs, but it would have been one (future)
> commitment format less. But it seems we do need it.
I hate it, too. The original design was *so* much simpler :(
> In the light of this forgotten insight, is there a reason why the anchor
> output would need key rotation? Having no rotation makes it easier to let
> those anchors go straight into the wallet, which may mitigate the dust utxo
> problem a bit. At least then they can be easily coin-selected for any
> on-chain spent, if the market fees are low enough.
Or what about we rotate the anchors and nothing else, which (assuming we
make it anyone-can-spend-after-N-blocks) reduces the amount of onchain
spam if someone completely loses their keys?
That's a bigger change, but maybe it's worth it?
Cheers!
Rusty.

2023-06-09 14:56:59

- reply

📅 Original date posted:2019-11-04
📝 Original message:
Rusty Russell <rusty at rustcorp.com.au> writes:
> Olaoluwa Osuntokun <laolu32 at gmail.com> writes:
>> Defaults don't necessarily indicate higher/lower reliability. Issuing a
>> single CLI command to raise/lower the fees on one's node doesn't magically
>> make the owner of said node a _better_ routing node operator.
>
> No, but those who put effort into their node presumably have more
> reliable nodes, and this is a signal of that.
>
> Anyone have data on channel reliability that they can correlate with
> channel fees?
Actually, since lnd sends out a disable update for nodes which are
offline for > 20 minutes, we can simply look at the current gossip:
half-channels online: 45157
percentage using 1000/1 fees: 56%
half-channels offline: 10225
percentage using 1000/1 fees: 51%
So my assumption seems completely wrong here; if there's any
correlation, it's negative.
Cheers,
Rusty.

2023-06-09 14:56:55

- reply

📅 Original date posted:2019-10-30
📝 Original message:
Matt Corallo <lf-lists at mattcorallo.com> writes:
> Why not stick with the original design from Adelaide with a spending path with a 1CSV that is anyone can spend (or that is revealed by spending another output).
The original design IIRC was a single anyone-can-spend anchor output.
If we need two anchor outputs, and want the other to turn into an
anyone-can-spend after it's mined, it's possible by gratuitously
mentioning the other key in the script, I think:
# If they provide a signature, they can push this:
OP_DEPTH OP_IF
<key1> OP_CHECKSIG
OP_ELSE
# Reveal the other key so you can spend the other anchor, too.
<key2> OP_DROP
# Now, anyone can spend after 1 block.
1 OP_CHECKSEQUENCEVERIFY
OP_TRUE
OP_ENDIF
The other anchor output reverses <key1> and <key2>.
Cheers,
Rusty.

2023-06-09 14:56:53

- reply

📅 Original date posted:2019-10-30
📝 Original message:
Joost Jager <joost.jager at gmail.com> writes:
> We started to look at the `push_me` outputs again. Will refer to them as
> `anchor` outputs from now on, to prevent confusion with `push_msat` on the
> `open_channel` message.
>
> The cpfp carve-out https://github.com/bitcoin/bitcoin/pull/15681 has been
> merged and for reasons described earlier in this thread, we now need to a=
dd
> a csv time lock to every non-anchor output on the commitment transaction.
>
> To realize this, we are currently considering the following changes:
>
> * Add `to_remote_delay OP_CHECKSEQUENCEVERIFY OP_DROP` to the `to_remote`
> output. `to_remote_delay` is the csv delay that the remote party accepted
> in the funding flow for their outputs. This not only ensures that the
> carve-out works as intended, but also removes the incentive to game the
> other party into force-closing. If desired, both parties can still agree =
to
> have different `to_self_delay` values.
I think we should unify to_self_delay if we're doing this. Otherwise
the game returns.
> * Add `1 OP_CHECKSEQUENCEVERIFY OP_DROP` to the non-revocation clause of
> the HTLC outputs.
> For the anchor outputs we consider:
>
> * Output type: normal P2WKH. At one point, an additional spending path was
> proposed that was unconditional except for a 10 block csv lock. The
> intention of this was to prevent utxo set pollution by allowing anyone to
> clean up. This however also opens up the possibility for an attacker to
> 'use up' the cpfp carve-out after those 10 blocks. If the user A is offli=
ne
> for that period of time, a malicious peer B may already have broadcasted
> the commitment tx and pinned down user A's anchor output with a low fee
> child. That way, the commitment tx could still remain unconfirmed while an
> important htlc expires.
Agreed, this doesn't really work. We actually needed a bitcoin rule
that allowed a single anyone-can-spend output. Seems like we didn't get
that.
> * For the keys to use for `to_remote_anchor` and `to_local_anchor`, we=E2=
=80=99d
> like to introduce new addresses that both parties communicate in the
> `open_channel` and `accept_channel` messages. We don=E2=80=99t want to re=
use the
> main commitment output addresses, because those may (at some point) be co=
ld
> storage addresses and the cpfp is likely to happen from a hot wallet.
This is horribly spammy. At the moment we see ~ one unilateral close
every 3 blocks. Hopefully that will reduce, but there'll always be
some.
> * Within each version of the commitment transaction, both anchors always
> have equal values and are paid for by the initiator.
Who pays if they can't afford it? What if they push_msat everything to
the other side?
> The value of the
> anchors is the dust limit that was negotiated in the `open_channel` or
> `accept_channel` message of the party that publishes the transaction.
Now initiator has to care about the other side's dust limit, which is
bad. And as accepter I now want this much higher, since I get those
funds instantly. I don't think we gain anything by making this
configurable at all; just pick a number and be done.
Somewhere between 1000 and 10,000 sat is a good idea.
> Furthermore, there doesn=E2=80=99t seem to be a compelling reason anymore=
for
> tweaking the keys (new insights into watchtower designs, encrypt by txid).
That's not correct. This seems more like "forgotten insights" than "new
insights", which isn't surprising how long ago Tadge and I did the
watchtower design (BTW: I was the one who came up with encrypt by
txid for that!).
There are several design constraints in the original watchtowers:
1. A watchtower shouldn't be able to guess the channel history.
2. ... even if it sees a unilateral tx.
3. ... even if it sees a revoked unilateral tx it has a penalty for.
4. A watchtower shouldn't be able to tell if it's being used for both
parties in the same channel.
If you don't rotate keys, a watchtower can brute-force the HTLCs for all
previous transactions it was told about, and previous channel balances.
We removed key rotation on the to-remote output because you can simply
not tell the watchtower about txs which don't have anything but an
output to you.
Here are the options I see:
1. Abandon privacy from watchtowers and don't rotate keys. Watchtowers
will be able to brute-force your history if they see a unilateral
close.
2. Remove HTLC output key rotation, and assume watchtowers don't handle
HTLCs (so you don't tell them about early txs where the peer has no
output but there are HTLCs pending). This seems less useful, since
HTLC txs require metadata anyway.
3. Change to-local key rotation to use BIP32 (unhardened). We could
also take some of the 48 bits (maybe 24?) we currently use to encode
the commitment number, to encode a BIP32 sub-path for this channel.
This would make it easier for hardware wallets to reconstruct.
Cheers,
Rusty.

2023-06-09 14:56:41

- reply

📅 Original date posted:2019-10-13
📝 Original message:
Olaoluwa Osuntokun <laolu32 at gmail.com> writes:
> Hi Rusty,
>
> I think this change may be a bit misguided, and we should be careful about
> making sweeping changes to default values like this such as fees. I'm
> worried that this post (and the subsequent LGTMs by some developers)
> promotes the notion that somehow in Lightning, developers decide on fees
> (fees are too low, let's raise them!).
Phew, I'm glad someone else is uncomfortable! Yes, I held off this
kind of proposal for a long time for exactly this reason. However,
the truth seems to be that defaults have that power, whether we want
it or not :(
If we make defaults more awkward, it will encourage people to change
them. In the end, I settled on a simple number because I want to to
be easy to filter out these defaults from further analysis.
> IMO, there're a number of flaws in the reasoning behind this proposal:
>
>> defaults actually indicate lower reliability, and routing gets tarpitted
>> trying them all
>
> Defaults don't necessarily indicate higher/lower reliability. Issuing a
> single CLI command to raise/lower the fees on one's node doesn't magically
> make the owner of said node a _better_ routing node operator.
No, but those who put effort into their node presumably have more
reliable nodes, and this is a signal of that.
Anyone have data on channel reliability that they can correlate with
channel fees?
> If a node has
> many channels, with all of them poorly managed, then path finding algorithms
> can move extrapolate the overall reliability of a node based on failures of
> a sample of channels connected to that node. We've start to experiment with
> such an approach here, so far the results are promising[1].
That's great if you're making many payments, but then you have many
heuristics at your disposal. Most people won't be making many
payments, so such techniques are not useful.
>> There's no meaningful market signal in fees, since you can't drop much
>> below 1ppm.
>
> The market signal one should be extracting from the current state is: a true
> market hasn't yet emerged as routing node operators are mostly hands off (as
> they're used to being with their exiting bitcoin node) and have yet to begin
> to factor in the various costs of operating a node into their fees schedule.
> Only a handful of routing node operators have started to experiment with
> distinct fee settings in an attempt to feel out the level of elasticity in
> the forwarding market today (if I double by fees, by how much do my daily
> forwards and fee revenue drop off?).
>
> Ken Sedgwick had a pretty good talk on this topic as the most recent SF
> Lightning Devs meet up[2]. The talk itself unfortunately wasn't recorded,
> but there're a ton of cool graphs really digging into the various parameters
> in the current market. He draws a similar conclusion stating that: "Many
> current lightning channels are not charging enough fees to cover on-chain
> replacement".
This is all true, too.
> Developers raising the default fees (on their various implementations) won't
> address this as it shows that the majority of participants today (routing
> node operators) aren't yet thinking about their break even costs. IMO
> generally this is due to a lack of education, which we're working to address
> with our blog post series (eventually to be a fully fledged standalone
> guide) on routing node operation[3]. Tooling also needs to improve to give
> routing node operators better insight into their current level of
> performance and efficacy of their capital allocation decisions.
Assuming a network in which many people are running nodes for their
own use and only forwarding as a side-effect, the biggest factor will
*always* be the default settings.
BTW, a quick look at the percentiles (ignoring "default setting" channels):
Percentile Min Capacity Max Capacity Median Base Median PPM
(sats) (sats) (msat)
0-10 1100 100000 0 10
10-20 100000 200000 1 10
20-30 200000 358517 1 8
30-40 358517 546639 1 10
40-50 546639 1000000 1 42
50-60 1000000 2000000 106 10
60-70 2000000 3143170 2 35
70-80 3145265 5550000 1 800
80-90 5561878 16000000 0 800
90-100 1600000 200000000 0 1
Overall: 1 10
>> Compare lightningpowerusers.com which charges (10000 msat + 5000 ppm),
>> and seems to have significant usage, so there clearly is market tolerance
>> for higher fees.
>
> IIRC, the fees on that node are only that high due to user error by the
> operator when setting their fees.
No; fiatjaf measured incorrectly and thought he was charging 5% and
there was much confusion. It was always 0.5%, as it was supposed to be.
> Independent of that, I don't think you can draw the conclusion that they
> have "significant" usage, based on solely the number of channels they have.
> That node has many channels due to the operator campaigning for users to
> open channels with them on Twitter, as they provided an easy way to package
> lnd for desktop users. A node having numerous channels doesn't necessarily
> mean that they have significant usage, as it's easy to "paint the tape" with
> on-chain transactions. What really matters is how effectively the node is
> managed.
Can Pierre weigh in with some usage information?
> In terms of market signals, IMO the gradual rise of fees _above_ the current
> widely used default is a strong signal as it will indicate a level of
> maturation in the market.
Those conditions are met, it seems?
> Preemptively raising defaults only adds noise as
> then the advertised fees are less indicative of the actual market
> conditions.
Preemptively? How do you decide when to that is? I agree low defaults
were great for testing, but they're probably distorting the market now.
> Instead, we should (to promote a healthier network) educate
> prospective routing node operators on best practices, provide analysis
> tools t
> hey can use to make channel management and liquidity allocation decisions,
> and leave it up to the market participants to converge on steady state
> economically rational fees!
If there's no anchoring effect of the defaults, then there's no harm in
changing them; at least increasing them would serve as a reliability signal
(assuming that's true).
If they are distorting the market, we should change them so the market
can be more efficient.
Cheers,
Rusty.
"We just need to educate everyone" is not really going to get us there,
is it? We want almost all users running nodes, and the benefit of them
to tweak things is so small they're just going to stick with the
defaults.
In the long run, "defaults" will get smarter (eg. based on a comparison
of other similar channels), but I suspect we'll see anchoring around
*todays* defaults.

2023-06-09 14:56:39

- reply

📅 Original date posted:2019-10-10
📝 Original message:
Hi all,
I've been looking at the current lightning network fees, and it
shows that 2/3 are sitting on the default (1000 msat + 1 ppm).
This has two problems:
1. Low fees are now a negative signal: defaults actually indicate
lower reliability, and routing gets tarpitted trying them all.
2. There's no meaningful market signal in fees, since you can't
drop much below 1ppm.
Compare lightningpowerusers.com which charges (10000 msat + 5000 ppm),
and seems to have significant usage, so there clearly is market
tolerance for higher fees.
I am proposing that as of next release of c-lighting, we change defaults
on new channels to 5000 msat + 500ppm, and I'd like the other
implementations to join me.
Over time, that should move the noise floor up. I picked 500ppm because
that's still 1% at 20 hops, so minimally centralizing. I picked 5000
msat base for less quantifiable reasons.
Here's default fee a rate table in USD (@10k per BTC):
Amount Before After
0.1c 0.0100001c 0.05005c
1c 0.010001c 0.0505c
10c 0.01001c 0.055c
$1 0.0101c 0.1c
$10 0.011c 0.55c
$100 0.02c 5.05c
$1000 0.11c 50.05c
Thoughts?
Rusty.

2023-06-09 14:56:14

- reply

📅 Original date posted:2019-09-27
📝 Original message:
Problem
-------
A lightning node accepting a channel must check that the funding transaction
output does indeed open the channel proposed. Otherwise an attacker can claim
to open a channel but either not pay to the peer, or not pay the full amount.
Once that transaction reaches the minimum depth, it can spend funds from the
channel. The victim will only notice when it tries to close the channel and none
of the commitment or mutual close transactions it has are valid.
Implementations did not always do this check:
c-lightning: v0.7.1 and above do this correctly, prior versions never did.
(CVE-2019-12998)
- This can be exploited by a connecting peer and claiming to open a channel
with any transaction id.
lnd: v0.7.1 and above do this correctly, prior versions did not check the
amount. v0.7.0 and above properly check for the scriptpubkey, v0.6.x
partially enforces the funding scriptpubkey, but pre-v0.6.0 did not verify
at all. (CVE-2019-12999)
- Exploiting via incorrect amount is possible against all prior versions. In
v0.7.0, the attacker must use the correct scriptpubkey, which burns the
coins in the funding output.
- Exploiting via incorrect scriptpubkey is possible on all versions prior to
v0.6.0. This exploit is also possible in v0.6.x if the node is offline
when the funding transaction reached the required number of confirmations
and running with -txindex=0 on either full node backend.
- Exploiting neutrino users (usually mobile or laptop) with an incorrect
outpoint would require the attacker to collide their fake outpoint with
the script of the real outpoint in the BIP 158 filter. The siphash key
used to create the filters is derived from the blockhash. As a result, the
attacker cannot directly grind outpoints without also knowing the block
hash ahead of time. In addition, neutrino nodes are typically either
non-listening or do not have an advertised address, which means an
attacker would have to wait until receiving an inbound connection to
perform either exploit.
eclair: v0.3.1 and above do this correctly, prior versions did not if using
the bitcoin core backend; electrum users only check the script, not the
amount. (CVE-2019-13000)
- Exploiting Electrum users (on mobile) requires the user to actively
connect to a malicious Lightning node, and the attacker to use the correct
scriptpubkey, which burns the coins in the funding output. Since Eclair
Mobile doesn’t relay payments, the attacker can’t cash out without an
offband interaction (e.g. selling something to the user and paying with
the funds in the fake channel).
Solution
--------
Once the funding transaction is seen, peers MUST check that the outpoint as
described in `funding_created`[1] is a funding transaction output[2] with
the amount described in `open_channel`[3].
Background
----------
To open a channel, the funding peer sends `open_channel` with the proposed
`funding_satoshis`. The fundee replies with `accept_channel` providing the
keys it wants to use for the funding transaction.
Then the funder creates the funding transaction, and sends the transaction id
and output number in a `funding_created` message.
```
+-------+ +-------+
| |--(1)--- open_channel ----->| |
| |<-(2)-- accept_channel -----| |
| | | |
| A |--(3)-- funding_created --->| B |
| |<-(4)-- funding_signed -----| |
| | | |
| |--(5)--- funding_locked ---->| |
| |<-(6)--- funding_locked -----| |
+-------+ +-------+
- where node A is 'funder' and node B is 'fundee'
```
With this information, the fundee can create the signatures on the first
"commitment transaction" and sends it in a `funding_signed` message so the
funder can retrieve their funds should something go wrong. It is then safe
for the funder to sign and broadcast the opening transaction. After some
number of confirmations (set by the fundee), the channel is operational
(`funding_locked`).
The specification describes clearly the requirement to check that the various
signatures exchanged indeed allow creation of a valid commitment transaction[4],
and describes the requirement to wait for confirmations[5].
It did NOT, however, require the receiver to actually check that the
transaction is the one promised by the funder: both the amount and the actual
scriptpubkey.
Discovery
---------
Rusty Russell (Blockstream) discovered this while working on protocol
tests for the specification itself, as part of an ongoing effort to
test multiple new proposed features add new complexities.[6]
The discovery occurred while writing tests for channel opening
negotiation, in particular that invalid variants were rejected; while
writing a test where the opener supplied an incorrect
`funding_output_index` in the `funding_created` message, he realized
that it would not be rejected by the c-lightning implementation, which
only checked the confirmation count of the `funding_txid`, and not
even whether the `funding_output_index` even existed!
This requirement was not mentioned in the specification, so Rusty
immediately disclosed the problem the authors of the other most widely
used implementations (eclair and lnd). Their own investigations
revealed that they were similarly vulnerable in limited circumstances.
Together the teams made the decision to fix this quietly for pending
releases, then reveal the existence of a problem 8 weeks later, once
most users had already upgraded. Four weeks after that, the full
disclosure would be made.
While this long-standing bug had not been independently discovered, and thus
was unlikely to be discovered by a malicious party before being fixed, it did
provide an opportunity to test communications and methods of upgrade across
the entire lightning ecosystem.
Timeline
--------
2019-06-27: Bug discovered, LND and Eclair notified.
2019-06-28: CVEs assigned.
2019-07-02: lnd v0.7.0-beta released.
2019-07-03: Eclair 0.3.1 released.
2019-07-04: c-lightning 0.7.1 released.
2019-07-06: disclosure to other projects begins (rust-lightning, ptarmigan, BLW).
2019-07-30: lnd v0.7.1-beta released.
2019-08-17: [Review next dates based on deployment stats/problems]
2019-08-30: Reveal existence of CVEs, encourage laggards to upgrade.
2019-09-07: First conclusive evidence of exploit attempt in the wild.
2019-09-27: Full disclosure of CVEs.
2019-09-27: Submit PR to spec to require this.
[1] https://github.com/lightningnetwork/lightning-rfc/blob/v1.0/02-peer-protocol.md#the-funding_created-message
[2] https://github.com/lightningnetwork/lightning-rfc/blob/v1.0/03-transactions.md#funding-transaction-output
[3] https://github.com/lightningnetwork/lightning-rfc/blob/v1.0/02-peer-protocol.md#the-open_channel-message
[4] https://github.com/lightningnetwork/lightning-rfc/blob/v1.0/02-peer-protocol.md#requirements-2
[5] https://github.com/lightningnetwork/lightning-rfc/blob/v1.0/02-peer-protocol.md#the-funding_locked-message
[6] https://github.com/ElementsProject/lightning-rfc-protocol-test

2023-06-09 14:56:00

- reply

📅 Original date posted:2019-09-05
📝 Original message:
Hi all,
The next release of c-lightning will start suppressing gossip
which comes too fast. I have implemented a simple filter which allows
each message (node_announcement or channel_update) ONCE PER DAY on
average, with a burst up to 4 times per day. We will also discard
identical gossip messages (except timestamp and signature of course).
If people have a reason to want more frequent updates, please tell me
now! If this is tolerable, it will avoid some of the more obvious
scaling issues in future.
With 40,000 channels and 10,000 nodes, that caps us at about 90,000
12 MB per day. In practice much less.
As an aside, we're implementing other gossip reductions:
1. We'll start using gossip_queries for backfilling, rather than
asking three peers for a complete copy if we think we've missed
something.[1]
2. We will no longer ask for the last 24 hours of gossip on startup.[1]
3. We already suppressed our own duplicate gossip, and only generated
"disable" updates if we had to return an error.
4. My current code has us *never* generating two channel_update or
node_announcement less than 300 seconds apart.
5. We have a PR to suppress reply gossip: if you send us a msg, we won't
return it to you.
6. My current code has us issuing "refresh" updates only once every
13 days instead of the current 7.
The main motivation is one user who has a rPi on a 4G plan. It's
painful for him to restart his node at the moment, but I am determined
to make it reasonable!
Cheers,
Rusty.
[1] Not yet coded, but RSN.

2023-06-09 14:55:53

- reply

📅 Original date posted:2019-08-12
📝 Original message:
Ecurrencyhodler Blockchains <ecurrencyhodler at gmail.com> writes:
> 1. Bob wants to send me 100,000 sats.
> 2. My node just came online and has 0 inbound liquidity.
> 3. I create an invoice for 100,000 sats. My LN node recognizes I have 0
> inbound liquidity so my wallet also embeds my URI in the invoice.
> 4. Bob’s wallet sees an invoice + uri. Maybe even tries to route. When
> it doesn’t see anything, it auto opens a channel + pushes 100,000 sat
> payment.
> 5. I now own and can spend 100,000 sats instantly.
If you publish your node address, Bob can already get this from the
gossip network, or the DNS seed as a last resort (and I expect
implementations to start doing this: I did it manually to buy a
thelightningconference.com ticket recently, for example).
So this proposal is mainly useful where you have no channels at all
(thus cannot advertize your node), or don't want to publish it
generally. And in both those cases, Bob probably doesn't want a channel
with you because it wouldn't be useful for paying anyone else.
Cheers,
Rusty.

2023-06-09 14:55:36

- reply

📅 Original date posted:2019-07-19
📝 Original message:
Pierre <pm+lists at acinq.fr> writes:
> Hi Rusty,
>
> How would bruteforcing on the CSV delay be different from a BIP32
> wallet with look ahead keys? Especially given that we could try with
> most probable values first.
It's a big multiplier, given that CSV can be specified by the
counterparty. If you accept up to 1024 and offer 144, that's 880
variants to look for, per key.
It also can't be done with a normal bitcoin wallet, which is unfortunate
too.
Cheers,
Rusty.

2023-06-09 14:55:36

- reply

📅 Original date posted:2019-07-16
📝 Original message:
Hi all,
In Adelaide we proposed that CSV delays be symmetric; that the
to-self output would be delayed to avoid weird "no, you close!" games.
Unfortunately, Roasbeef points out that this undermines the
great strength of the option_static_remotekey, which allows a
disaster-recovery scenario to easily discover any unknown unilateral
closes using only a master seed. Turns out, this "I deleted everything
but I kept my seed!" is a real thing.
We could still use the max of the two sides' CSV, but that's
already a choice that sides can make (if accepting, simply offer the
same value, and if opening, error and retry if their accept contains a
larger value).
So I think this proposal should be abandoned.
Thoughts?
Rusty.

2023-06-09 14:54:37

- reply

📅 Original date posted:2019-03-18
📝 Original message:
Yes, you shouldn't notice anything, and don't need to do anything.
Cheers,
Rusty.
On Mon, Mar 18, 2019, 17:53 ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Is there anything I need to do if I want to remain on lightning-dev?
> Or is this automatic as long as I do not unsubscribe?
>
> Regards,
> ZmnSCPxj
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Saturday, March 16, 2019 12:45 PM, Rusty Russell <rusty at blockstream.com>
> wrote:
>
> > Hi all,
> >
> > Linux Foundation (who graciously host this list for us) is
> > deprecating their mailing list infrastructure (mailman2 is unmaintained,
> > apparently v3 is a mess), and migrating lists to groups.io. Apparently
> > this is the direction that bitcoin-dev is heading.
> >
> > Unless people raise concerns, I expect this list to follow, within the
> > week. If you want to unsubscribe before then, please do so.
> >
> > 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/20190319/1667a404/attachment.html>

2023-06-09 14:54:36

- reply

📅 Original date posted:2019-03-16
📝 Original message:
Hi all,
Linux Foundation (who graciously host this list for us) is
deprecating their mailing list infrastructure (mailman2 is unmaintained,
apparently v3 is a mess), and migrating lists to groups.io. Apparently
this is the direction that bitcoin-dev is heading.
Unless people raise concerns, I expect this list to follow, within the
week. If you want to unsubscribe before then, please do so.
Cheers,
Rusty.

2023-06-09 14:54:29

- reply

📅 Original date posted:2019-03-20
📝 Original message:
Sorry AJ, my prior email was not constructive :(
I consider the "my software reused my keys" the most reasonable attack
scenario, though still small compared to other lightning attack surfaces.
But I understand the general wariness of third-parties reusing
SIGHASH_NOINPUT signatures.
Since "must have a non-SIGHASH_NOINPUT" rule addresses the first reuse
scenario (as well as the second), I'd be content with that proposal.
Future segwit versions may choose to relax it.[1]
Cheers,
Rusty.
[1] Must be consensus, not standardness; my prev suggestion was bogus.
Rusty Russell <rusty at rustcorp.com.au> writes:
> Anthony Towns <aj at erisian.com.au> writes:
>> If you publish to the blockchain:
> ...
>> 4 can be dropped, state 5 and finish can be altered). Since the CSV delay
>> is chosen by the participants, the above is still a possible scenario
>> in eltoo, though, and it means there's some risk for someone accepting
>> bitcoins that result from a non-cooperative close of an eltoo channel.
>
> AJ, this was a meandering random walk which shed very little light.
>
> I don't find the differentiation between malicious and non-malicious
> double-spends convincing. Even if you trust A, you already have to
> worry about person-who-sent-the-coins-to-A. This expands that set to be
> "miner who mined coins sent-to-A", but it's very hard to see what
> difference that makes to how you'd handle coins from A.
>
>> Beyond that, I think NOINPUT has two fundamental ways to cause problems
>> for the people doing NOINPUT sigs:
>>
>> 1) your signature gets applied to a unexpectedly different
>> script, perhaps making it look like you've being dealing
>> with some blacklisted entity. OP_MASK and similar solves
>> this.
>
> ... followed by two paragraphs describing how it's not a "fundamental
> way to cause problems" that you (or I) can see.
>
>> For the second case, that seems a little more concerning. The nightmare
>> scenario is maybe something like:
>>
>> * naive users do silly things with NOINPUT signatures, and end up
>> losing funds due to replays like the above
>
> As we've never seen with SIGHASH_NONE?
>
>> * initial source of funds was some major exchange, who decide it's
>> cheaper to refund the lost funds than deal with the customer complaints
>>
>> * the lost funds end up costing enough that major exchanges just outright
>> ban sending funds to any address capable of NOINPUT, which also bans
>> all taproot/schnorr addresses
>
> I don't find this remotely credible.
>
>> FWIW, I don't have a strong opinion here yet, but:
>>
>> - I'm still inclined to err on the side of putting more safety
>> measures in for NOINPUT, rather than fewer
>
> In theory, sure. But not feel-good and complex "safety measures" which
> don't actually help in practical failure scenarios.
>
>> - the "must have a sig that commits to the input tx" seems like it
>> should be pretty safe, not too expensive, and keeps taproot's privacy
>> benefits in the cases where you end up needing to use NOINPUT
>
> If this is considered necessary, can it be a standardness rule rather
> than consensus?
>
> Thanks,
> Rusty.

2023-06-09 14:54:28

- reply

📅 Original date posted:2019-03-19
📝 Original message:
Anthony Towns <aj at erisian.com.au> writes:
> If you publish to the blockchain:
...
> 4 can be dropped, state 5 and finish can be altered). Since the CSV delay
> is chosen by the participants, the above is still a possible scenario
> in eltoo, though, and it means there's some risk for someone accepting
> bitcoins that result from a non-cooperative close of an eltoo channel.
AJ, this was a meandering random walk which shed very little light.
I don't find the differentiation between malicious and non-malicious
double-spends convincing. Even if you trust A, you already have to
worry about person-who-sent-the-coins-to-A. This expands that set to be
"miner who mined coins sent-to-A", but it's very hard to see what
difference that makes to how you'd handle coins from A.
> Beyond that, I think NOINPUT has two fundamental ways to cause problems
> for the people doing NOINPUT sigs:
>
> 1) your signature gets applied to a unexpectedly different
> script, perhaps making it look like you've being dealing
> with some blacklisted entity. OP_MASK and similar solves
> this.
... followed by two paragraphs describing how it's not a "fundamental
way to cause problems" that you (or I) can see.
> For the second case, that seems a little more concerning. The nightmare
> scenario is maybe something like:
>
> * naive users do silly things with NOINPUT signatures, and end up
> losing funds due to replays like the above
As we've never seen with SIGHASH_NONE?
> * initial source of funds was some major exchange, who decide it's
> cheaper to refund the lost funds than deal with the customer complaints
>
> * the lost funds end up costing enough that major exchanges just outright
> ban sending funds to any address capable of NOINPUT, which also bans
> all taproot/schnorr addresses
I don't find this remotely credible.
> FWIW, I don't have a strong opinion here yet, but:
>
> - I'm still inclined to err on the side of putting more safety
> measures in for NOINPUT, rather than fewer
In theory, sure. But not feel-good and complex "safety measures" which
don't actually help in practical failure scenarios.
> - the "must have a sig that commits to the input tx" seems like it
> should be pretty safe, not too expensive, and keeps taproot's privacy
> benefits in the cases where you end up needing to use NOINPUT
If this is considered necessary, can it be a standardness rule rather
than consensus?
Thanks,
Rusty.

2023-06-09 14:54:20

- reply

📅 Original date posted:2019-03-01
📝 Original message:
We're pleased to announce c-lightning 0.7, named by Mark Beckwith.
https://github.com/ElementsProject/lightning/releases/tag/v0.7.0
Highlights for Users
--------------------
* Plugins are here, with frameworks for C, Python and Go! Write your own
cool extensions!
* Much better pay implementation (a plugin!) will folllow route hints,
give ongoing paystatus.
* All amount parameters take 'msat', 'sat', or 'btc' to avoid
satoshi/millisatoshi confusion.
* If your node ran out of memory with gossipd consuming 100% CPU, that
and several other crashes are fixed!
* Reproducible builds for Ubuntu, based on Ubuntu 18.04.1.
Highlights for the network
--------------------------
* option_dataloss_protect fixed and reenabled for everyone.
* We accept some known lnd protocol oddities rather than spitting the dummy and closing the channel.
* You can no longer make unpayable "wumbo" invoices.
More details can be found in the
https://github.com/ElementsProject/lightning/blob/v0.7.0/CHANGELOG.md
Contributions
-------------
We're grateful for all the bug reports and suggestions and your patience
as we sometimes struggled to address them: please keep them coming!
Since 0.6.3 we've had 284 commits from 16 different authors, 5 of whom
were first-time c-lightning contributors:
Alekos Filini
fanquake
Michael Schmoock
Rene Pickhardt
@wailo
That's comparable with the last release, but in 7 weeks instead of 10: kudos!
Cheers,
Rusty, Christian and ZmnSCPxj.
ad4b60dde249692d0fbf446436427528cb91f1acbb03a052928714d0d0037493 release/clightning-v0.7.0-Fedora-28-amd64.tar.gz
302aad864ba48be1d41a4787e32be4759b1a44985be20da868a3e25fe412061f release/clightning-v0.7.0-Ubuntu-16.04-i386.tar.gz
2da679f55cbe1cec6fee9b32c0943ddde3a19c6605d81e52807921bbca6d2fe1 release/clightning-v0.7.0-Ubuntu-18.04.tar.xz
448022c2433cbf19bbd0f726344b0500c0c21ee5cc2291edf6b622f094cb3a15 release/clightning-v0.7.0.zip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190302/6a95cc0e/attachment.sig>

2023-06-09 14:54:19

- reply

📅 Original date posted:2019-02-22
📝 Original message:
Subnote on this, there's a query on TLV format (1 byte type, 1 byte+
len).
There are two ways to add TLV to the onion:
1. Leave the existing fields and put TLV in the padding:
* [`8`:`short_channel_id`]
* [`8`:`amt_to_forward`]
* [`4`:`outgoing_cltv_value`]
* [`12`:`padding`]
2. Replace existing fields with TLV (eg. 2=short_channel_id,
4=amt_to_forward, 6=outgoing_cltv_value) and use realm > 0
to flag the new TLV format.
The length turns out about the same for intermediary hops, since:
TLV of short_channel_id => 10 bytes
TLV of amt_to_forward => probably 5-6 bytes.
TLV of outgoing_cltv_value => probably 3-4 bytes.
For final hop, we don't use short_channel_id, so we save significantly
there. That's also where many proposals to add information go (eg. a
special "app-level" value), so it sways me in the direction of making
TLV take the entire room.
Cheers,
Rusty.
Christian Decker <decker.christian at gmail.com> writes:
> Heya everybody,
>
> during the spec meeting in Adelaide we decided that we'd like to extend
> our current onion-routing capabilities with a couple of new features,
> such as rendez-vous routing, spontaneous payments, multi-part payments,
> etc. These features rely on two changes to the current onion format:
> bigger per-hop payloads (in the form of multi-frame payloads) and a more
> modern encoding (given by the TLV encoding).
>
> In the following I will explain my proposal on how to extend the per-hop
> payload from the current 65 bytes (which include realm and HMAC) to
> multiples.
>
> Until now we had a 1-to-1 relationship between a 65 byte segment of
> payload and a hop in the route. Since this is no longer the case, I
> propose we call the 65 byte segment a frame, to differentiate it from a
> hop in the route, hence the name multi-frame onion. The creation and
> decoding process doesn't really change at all, only some of the
> parameters.
>
> When constructing the onion, the sender currently always right-shifts by
> a single 65 byte frame, serializes the payload, and encrypts using the
> ChaCha20 stream. In parallel it also generates the fillers (basically 0s
> that get appended and encrypted by the processing nodes, in order to get
> matching HMACs), these are also shifted by a single 65 byte frame on
> each hop. The change in the generation comes in the form of variable
> shifts for both the payload serialization and filler generation,
> depending on the payload size. So if the payload fits into 32 bytes
> nothing changes, if the payload is bigger, we just use additional frames
> until it fits. The payload is padded with 0s, the HMAC remains as the
> last 32 bytes of the payload, and the realm stays at the first
> byte. This gives us
>
>> payload_size = num_frames * 65 byte - 1 byte (realm) - 32 bytes (hmac)
>
> The realm byte encodes both the payload format as well as how many
> additional frames were used to encode the payload. The MSB 4 bits encode
> the number of frames used, while the 4 LSB bits encode the realm/payload
> format.
>
> The decoding of an onion packet pretty much stays the same, the
> receiving node generates the shared secret, then generates the ChaCha20
> stream, and decrypts the packet (and additional padding that matches the
> filler the sender generated for HMACs). It can then read the realm byte,
> and knows how many frames to read, and how many frames it needs to left-
> shift in order to derive the next onion.
>
> This is a competing proposal with the proposal by roasbeef on the
> lightning-onion repo [1], but I think it is superior in a number of
> ways. The major advantage of this proposal is that the payload is in one
> contiguous memory region after the decryption, avoiding re-assembly of
> multiple parts and allowing zero-copy processing of the data. It also
> avoids multiple decryption steps, and does not waste space on multiple,
> useless, HMACs. I also believe that this proposal is simpler than [1],
> since it doesn't require re-assembly, and creates a clear distinction
> between payload units and hops.
>
> To show that this proposal actually works, and is rather simple, I went
> ahead and implemented it for c-lightning [2] and lnd [3] (sorry ACINQ,
> my scala is not sufficient to implement if for eclair). Most of the code
> changes are preparation for variable size payloads alongside the legacy
> v0 payloads we used so far, the relevant commits that actually change
> the generation of the onion are [4] and [5] for c-lightning and lnd
> respectively.
>
> I'm hoping that this proposal proves to be useful, and that you agree
> about the advantages I outlined above. I'd also like to mention that,
> while this is working, I'm open to suggestions :-)
>
> Cheers,
> Christian
>
> [1] https://github.com/lightningnetwork/lightning-onion/pull/31
> [2] https://github.com/ElementsProject/lightning/pull/2363
> [3] https://github.com/lightningnetwork/lightning-onion/pull/33
> [4] https://github.com/ElementsProject/lightning/pull/2363/commits/aac29daeeb5965ae407b9588cd599f38291c0c1f
> [5] https://github.com/lightningnetwork/lightning-onion/pull/33/commits/216c09c257d1a342c27c1e85ef6653559ef39314
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 14:54:17

- reply

📅 Original date posted:2019-02-23
📝 Original message:
ZmnSCPxj <ZmnSCPxj at protonmail.com> writes:
> Good morning Rusty,
>
>> So we need a web way of asking a client to send an invoice or offer over
>> HTTPS. Is this a new URI scheme? How would this work?
>
> I thought that offers would work over LN alone?
>
> When you first proposed the offers, I thought it was this way:
>
> 1. Payee gives BOLT12 offer to Payer.
> 2. Payer generates a completely new random preimage and computes its hash.
> 3. Payer issues a payment along an LN route from Payer to Payee using its random hash.
> 4. At the payee hop, the onion packet contains some identifying information from the BOLT12 offer.
> 5. Payee generates a BOLT11 invoice.
> 6. Payee sends back an error packet, which includes the BOLT11 invoice.
> 7. Payer receives the error packet that includes the BOLT11 invoice.
> 8. Payer pays using the BOLT11 invoice.
Yes. But how does the payee know to give the bolt12 offer to the payer?
That's the piece that's missing here, which is actually independent.
> Intermediate nodes remain unaware of this new feature and do not require upgrades.
That works if we use a fake "payment" like this to get the real invoice.
Be nicer to use a real message format though, as it's less overhead for
everyone and faster.
> A node issuing a BOLT12 offer would implicitly signal its support for this feature by the simple fact of being able to issue the BOLT12 offer.
> A node that can understand a BOLT12 offer implicitly means it supports this feature.
Yes; I think it's early enough that we don't need to cram offers into
bolt11 in some backwards compat way, they can be a new thing.
Cheers,
Rusty.

2023-06-09 14:54:17

- reply

📅 Original date posted:2019-02-26
📝 Original message:
ZmnSCPxj <ZmnSCPxj at protonmail.com> writes:
> Might it be possible to use SURBs as in the other thread?
It's possible, but you still don't want it for all the same reasons: you
have a nicely anonymized path you know works, so why use something else?
Cheers,
Rusty.