<unnamed>

Public Key

npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpx

Profile Code

nprofile1qqsp80vvr30rkdgg5p7fykvxgutqkydtphh0f3zjpx8zy0jy8sw2gfgpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0ds3v4zuq

Publishing to

relay.damus.io

nos.lol

Last Notes

2023-07-10 19:01:44 UTC

- 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-06-09 13:06:20 UTC

- 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 13:05:55 UTC

- 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 13:05:54 UTC

- 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 13:05:54 UTC

- 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 13:05:19 UTC

- 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 13:05:18 UTC

- 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 13:05:03 UTC

- 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 13:03:01 UTC

- reply

📅 Original date posted:2021-07-06
📝 Original message:
Carla Kirk-Cohen <kirkcohenc at gmail.com> writes:
> Hi all,
Hi Carla,
I apologize for not responding to this earlier, but it was
raised again in the recent spec meeting
(https://lightningd.github.io/meetings/ln_spec_meeting/2021/ln_spec_meeting.2021-07-05-20.06.log.html).
I love the idea of more specific error codes, BTW!
Feedback interleaved:
> Since we shouldn’t have non-ascii values in the error string itself,
> this can most easily be achieved by adding TLV fields after the
> data field. In terms of supporting nodes that have not upgraded,
> we could either include the error code in the data field to cover
> our bases, or introduce a feature bit so that we know whether
> to backfill the data field. This gives upgraded nodes an improved
> quality of life, while leaving older nodes unaffected.
Older nodes should definitely ignore extra fields; it's in the spec and
we've relied on this to extend messages in the past, so this part is
easy.
Technically, all defined types are now assumed to have an optional TLV
appended, since f068dd0d (Bolt 1: Specify that extensions to existing
messages must use TLV (#754)).
> While we can’t enumerate every possible error, there are quite
> a few cases in the spec where we can introduce explicit error
> codes. For the sake of the skim-readers, I’ve left that list at
> the end of the email.
>
> Taking the example of our node receiving an invalid signature for
> a htlc, a new error would look like this:
I think this is both too much, and not enough.
Too much:
- Many of these errors are "your implementation is broken", which is
really not something actionable by the recipient.
- A lot of work to fill in all these error cases, which will (because
they're usually impossible) will be untested and broken.
Not enough:
- Look at the proposal for channel_types, where you would object to the
channel_type if you don't like it. This would be grouped under
"Funding params unacceptable", which is actually 99% of errors at this
point and does not say what the problem is with specificity.
I took a different approach with onion messages[1], where you (optionally)
specify the field number, even an optional suggested value:
1. type: 1 (`erroneous_field`)
2. data:
* [`tu64`:`tlv_fieldnum`]
1. type: 3 (`suggested_value`)
2. data:
* [`...*byte`:`value`]
1. type: 5 (`error`)
2. data:
* [`...*utf8`:`msg`]
In our case, we need to refer to which message (if any) caused the
error, and we have non-tlv fields, so it can't simply use the tlv field
number.
Here's my straw proposal:
1. `tlv_stream`: `error_tlvs`
2. types:
1. type: 1 (`erroneous_message`)
2. data:
* [`...*byte`:`message`]
1. type: 3 (`erroneous_fieldnum`)
2. data:
* [`tu64`:`fieldnum`]
1. type: 5 (`suggested_value`)
2. data:
* [`...*byte`:`value`]
erroneous_message is the message we're complaining about (including
2-byte type), which may be truncated (but must be at least 2 bytes).
fieldnum is either the 0-based field number (for fixed fields), or the
number of fixed fields + the tlv type (for tlv fields).
suggested_value is the optional value if we have an idea if what we
expected / prefer.
> This new kind of error provides us with an error code that tells us
>
> exactly what has gone wrong, and metadata pointing to the htlc
>
> with an invalid sig. This information can be logged, or stored in a
>
> more permanent error store to help diagnose issues in the future.
>
> Right now, the spec is pretty strict on error handling [13], indicating
>
> that senders/recipients of errors `MUST` fail the channel referenced
>
> in the error.
> This isn’t very practical, and I believe that the majority
> of the impls don’t abide by this instruction.
This was inevitable eventually, but c-lightning deliberately treated
errors as fatal for a long time so people would *notice* and *report*
these issues.
To be fair, *LND* didn't treat them as fatal. As so naturally your
engineers didn't *think* of them as a big deal (and testing didn't show
it up), so it would send errors for cases which it clearly didn't want
to close the channel (e.g. peer too slow to respond!).
Hence this PR, which makes these less fatal, and adds warning support:
https://github.com/lightningnetwork/lightning-rfc/pull/834
(We should similarly add this TLV to warnings?)
> Candidates for error codes:
The vast majority of these are "contact your developer, peer says we did
something illegal". Which is always nice to have more information
about, but not critital.
The exceptions are:
> Funding Process:
>
> * Funding process timeout [2]
>
> * Fees out of range [3]
>
> * Funding tx spent [11]
>
> * Funding params unacceptable (eg, channel too small)
...
> Channel State Machine:
>
> * HTLC timeout [4]
...
> Fee Updates
>
> * Update fee to low/high [9]
...
And BTW this one is misguided:
> * Feature bit required
If Alice says a feature bit is even (compulsory), and Bob doesn't offer
it, that's on Bob! Alice's behavior here is undefined: she may do a
courtesy message to Bob, but she may also *assume* it's agreed.
But it's worth noting that with the exception of timeouts, these are all
expressable in form "problem is this message, this field". Perhaps it's
worth having a special TLV case for timeouts in the message?
Thanks for starting this ball rolling!
Cheers,
Rusty.
[1] https://github.com/lightningnetwork/lightning-rfc/pull/759

2023-06-09 13:02:46 UTC

- reply

📅 Original date posted:2021-06-29
📝 Original message:
Bastien TEINTURIER <bastien at acinq.fr> writes:
> Hi Rusty,
>
> On the eclair side, we instead send `funding_locked` as soon as we
> see the funding tx in the mempool.
>
> But I think your proposal would work as well.
This would be backward compatible, I think. Eclair would send
`funding_locked`, which is perfectly legal, but a normal peer would
still wait for confirms before also sending `funding_locked`; it's
just that option_zeroconf_channels would mean it doesn't have to
wait for that before sending HTLCs?
> We may want to defer sending `announcement_signatures` until
> after the funding tx has been confirmed? What `min_depth` should
> we use here? Should we keep a non-zero value in `accept_channel`
> or should it be zero?
You can't send it before you know the channel_id, so it has to be at
least 1. Spec says:
- MUST NOT send `announcement_signatures` messages until `funding_locked`
has been sent and received AND the funding transaction has at least six confirmations.
So still compliant there?
Cheers,
Rusty.

2023-06-09 13:02:45 UTC

- reply

📅 Original date posted:2021-06-29
📝 Original message:
Hi all!
John Carvalo recently pointed out that not every implementation
accepts zero-conf channels, but they are useful. Roasbeef also recently
noted that they're not spec'd.
How do you all do it? Here's a strawman proposal:
1. Assign a new feature bit "I accept zeroconf channels".
2. If both negotiate this, you can send update_add_htlc (etc) *before*
funding_locked without the peer getting upset.
3. Nodes are advised *not* to forward HTLCs from an unconfirmed channel
unless they have explicit reason to trust that node (they can still
send *out* that channel, because that's not their problem!).
It's a pretty simple change, TBH (this zeroconf feature would also
create a new set of channel_types, altering that PR).
I can draft something this week?
Thanks!
Rusty.

2023-06-09 13:02:18 UTC

- 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 13:02:18 UTC

- 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 13:01:50 UTC

- 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 13:01:49 UTC

- reply

📅 Original date posted:2021-01-07
📝 Original message:
Lloyd Fournier <lloyd.fourn at gmail.com> writes:
> This achieves all properties except for (4 - distinguishable on-chain)
> which is why it was dismissed.
It also seems to require 2 txs per channel open? (Interestingly I
missed that post previously, thanks for the pointer!)
> I think it is possible to extend the idea to achieve (4) and therefore
> obtain all desired properties.
> Simply put peers can just use the SINGLE|ANYONECANPAY signature as back ups
> in case of abort. Here's how it could work in my mind:
>
> 1. Initiator requests dual-funding and provides a TX_temp spending their
> input set to a main output and a change output (does not sign it yet). They
> also provide a sighash SIGNLE|ANYONECANPAY signature on the main output
> spending into TX_backup-fund and a signature on the first commitment
> transaction spending from TX_backup-fund (exactly as in [6]).
> 2. Peer responds with commitment TX signature for TX_backup-fund.
> 3. Initiator responds with the signatures for TX_temp.
> *Peer now has a fully functional transaction chain with which to open the
> channel -- now they can attempt to upgrade to a SIGHASH_ALL opening*.
> 4. Peer (if possible) checks there are no existing transactions in the
> chain or mempool spending from the taker's inputs. If not it responds with
> its inputs, change and commitment tx signature for a SIGHASH_ALL TX_fund.
> 5. Initiator responds with commitment TX signature and TX_fund input
> signatures.
> 6. Peer broadcasts TX_fund.
> *If at any point after step 3 Initiator does not respond for ~2 seconds
> they broadcast TX_temp and TX_backup-funding*
2 seconds is not sufficient; as an Australian (or Tor user) you should
know this :)
But otherwise, it's kinda nice (bar breaking the interactive construction).
> We have (4) because the SINGLE|ANYONECANPAY signature only appears on-chain
> in case of abort (i.e. TX_backup-funding makes it on-chain).
> It appears to be pretty close to the ideal solution in terms of privacy and
> security.
> If the malicious initiator learns an output they will always have to spend
> one of their inputs otherwise they will quickly get hit by the TX_temp +
> TX_backup-funding.
> Note that it is possible the node is just slow in which case even if step
> TX_backup-funding makes it in both parties should just carry on with the
> channel.
>
> The downsides are that it involves six rounds of communication and cannot
> use the "interactive tx building" protocol developed for the original
> proposal
>
> # Signaling Transactions
>
> Finally I present a simple but unintuitive protocol that achieves roughly
> the same properties as the PoDLE protocol but without lightning gossip
> messages.
>
> Whenever the initiator adds an input in the interactive tx building they
> provide signatures on a "signaling" transaction spending that input (and
> any inputs they have added so far).
> The signaling transactions will typically spend the funds back to the
> initiator's wallet.
> Before revealing any of their inputs, the peer checks that none of the
> inputs added by the initiator are in their mempool/chain.
> If the initiator aborts the protocol after learning one of the peer's
> inputs the peer broadcasts one of the signaling transactions.
>
> Like the PoDLE proposal this doesn't achieve (3) since a malicious peer
> could broadcast the signaling transaction making the honest initiator pay a
> transaction fee before using the input in another session.
> To mitigate this a bit, the transactions could be RBF and have a 1
> sat-per-byte feerate to give the initiator a decent amount of time to use
> their input productively before the tx confirms (and paying a low fee if it
> ever does confirm).
>
> The advantages of signaling transactions over PoDLE is that it doesn't
> involve any wonky crypto or new gossip messages.
> The advantage of the PoDLE proposal over this is that a malicious peer can
> only blacklist the UTXO (not necessarily force you to spend it).
We only need a single UTXO for this, which is even better.
So the initiator sends a "good faith" signed tx, which spends one of its
UTXOs, to the accepter. 1sat-per-byte is probably a too low, but the
accepter can provide a feerate for it[1]. Opener aborts if that
"good-faith" feerate is too high. It's implied that this is the first
added input, too.
If the accepter screws the opener by broadcasting it, the opener can
still open a channel with someone else before it's confirmed: they just
can't use *that* utxo if they want another node to DF. Or simply take
the loss, since the feerate is presumably minimal, and use CPFP.
Cheers,
Rusty.
[1] The latest c-lightning implementation of the spec[2] already has the
accepter indicating min, max and preferred feerates (and then the
opener selects within that range). This would simply add another
feerate field, suggest implementing as ceiling(min / 2, 1).
[2] Which Lisa promises she'll publish RSN, so we can add your derived
points proposal to it.

2023-06-09 13:01:29 UTC

- 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 13:01:21 UTC

- 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 13:01:20 UTC

- 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 13:01:19 UTC

- 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 12:59:24 UTC

- reply

📅 Original date posted:2020-04-05
📝 Original message:
Hi ZmnSCPxj,
This is a rework of the old unwrap-the-onion proposal, with
some important bits missing.
> Secondly, C needs to prove that the channel it is willing to close involves the payment attempt, and is not some other channel closure that it is attempting to use to fulfill its own soft timeout.
> Since the unilateral close transaction *is* the proof-of-closure, B (and A) can inspect the transaction outputs and see (with some additional data from C) that one of the outputs is to an HTLC that matches the payment hash.
>
> Thus, B (and A) can believe that the proof-of-closure proves that whoever is presenting it is free of wrongdoing, as whoever is actually causing the delay has been punished (by someone being willing to close a channel with the culprit), and that the proof-of-closure commits to this particular payment attempt and no other (because it commits to a particular payment hash).
As you note below, the payment might be considered dust, or an
unresponsive peer has not yet acked the HTLC.
My previous proposal was to limit the damage somewhat by requiring that
C offer a signed list of some limited number of HTLCs it is claiming
were caught, alongside the closure proof (you can merkle this, but
that's a detail). That closure claim gets socialized, and if there are
multiple different claim lists for the tx then C is a bad actor and we
no longer respect its closure proof.
You also missed how the timeout would work, which is important. How
long does node N wait for a proof? In my construction, it's 30 seconds,
plus get another 30 seconds for each decryption of the onion it
receives.
Otherwise, you can't know how long you've got to provide this closure
proof, or how long to wait for it.
In addition, for closure proofs to work, nodes need to agree on what is
a valid, standard, high-enough-fee commitment transaction.
Cheers,
Rusty.

2023-06-09 12:59:16 UTC

- 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 12:59:15 UTC

- reply

📅 Original date posted:2020-03-09
📝 Original message:
I recently hit a dead-end on rendezvous routing; the single-use
requirement is a showstopper for offers (which are supposed to be static
and reusable).
Fortunately, t-bast has a scheme for blinded paths (see
https://gist.github.com/t-bast/9972bfe9523bb18395bdedb8dc691faf ) so
I've been examining that more closely. I think it can be simplified
to use more standard primitives.
The problem: Alice wants to present Mallory with a path (Carol, Bob,
Alice) for which he can create an onion, which is obscured in some way,
but can be unobscured by the various nodes. Mallory should be forced to
use the entire path.
Alice can give Mallory two ECDH blobs to place inside the per-hop
payload to establish shared secrets with Bob and Carol. But crucially,
Bob needs the secret *before* he can unwrap the onion, so the ECDH
blob for the next peer needs to be sent alongside the onion itself.
t-bast proposed using the secret to XOR the scid, but Christian
suggested it's more powerful to encrypt a general payload.
What does this leave us with?
1. A new invoice letter `b`. Encodes
1 or more pubkey/feebase/feeprop/cltvdelta/features/encblob.
2. An additional (tlv of course) field to update_add_htlc, `blinding`.
3. New `tlv_payload` field `encblob` (varlen).
4. ECDH on incoming `blinding` to get a shared secret which tells
this node how to tweak its nodeid to decrypt onion, and also how to
decrypt `encblob`. This gives a tlv, which presumably contains
`short_channel_id` as well as `blinding`.
5. Use `blinding` for the next update_add_htlc.
6. If you get an error from downstream and you sent `blinding`, turn it
into your own error for maximum obfuscation. Perhaps a new
"blinded_path_error"? Obviously does not include a channel_update :)
So, if you get an invoice `b`, with path starting at (known) Carol:
Carol/1/1/9/""/enc1
Bob'/1/1/9/""/enc2
[Optional: decoy hops...]
Payer constructs the onion to get to Carol as normal, then:
Carol: No `blinding` in incoming HTLC, but once it decrypts the
onion, she sees `encblob` (value enc1). Uses first 32
bytes of `enc1` as `blinding`: do ECDH to get SS1, uses
SS1 to decrypt rest to get next scid and `blinding`, send
`blinding` with update_add_htlc to Bob.
Bob: Gets `blinding` from update_add_htlc. ECDH -> SS2. Tweak
own key with SS2 to decode onion. Use SS2 to decrypt
`enc2` to get next scid and blinding. Send `blinding`
with update_add_htlc to Alice.
Alice: Gets `blinding` from update_add_htlc. ECDH -> SS3. Tweak
own key with SS3 to decode onion. If it put in decoy
hops, this onion won't be terminal, but otherwise it can
be treated as terminal iff `blinding` is the expected value
for this invoice.
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).
Thoughts?
Rusty.

2023-06-09 12:58:41 UTC

- 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 12:58:40 UTC

- 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 12:58:36 UTC

- 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 12:58:35 UTC

- 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 12:58:34 UTC

- 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 12:58:33 UTC

- 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 12:58:33 UTC

- 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 12:58:31 UTC

- 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 12:57:33 UTC

- 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 12:57:32 UTC

- 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 12:57:19 UTC

- 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 12:57:18 UTC

- 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 12:57:18 UTC

- reply

📅 Original date posted:2019-11-11
📝 Original message:
Yaacov Akiba Slama <ya at slamail.org> writes:
> Hi Rusty.
>
> On 08/11/2019 05:09, Rusty Russell wrote:
>> 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.
>
> In fact, using UBL in LN specification is simpler than trying to
> understand the semantic of each field needed by businesses. You are
> right that using such a standard put the burden into wallet providers
> instead of LN developers, but as a wallet (breez) provider, I can say that:
>
> 1) Most money transactions (currently in fiat) are between users and
> companies and not between two users. If we want to replace FIAT by
> bitcoin, we need to create an infrastructure which can be used by
> businesses. That means that LN needs to be able to be integrated easily
> into POS systems. So, as a wallet provider who want to help the
> transition from fiat to bitcoin, I need to be able to support standards
> even if that means that I have to implement using/parsing big and
> complicated standards.
>
> For simple user to user transaction, the wallet can decide to use only a
> subset of the fields defined by the standard.
>
> 2) From a technical point of view, it seems that there are already UBL
> libraries in java and c#. I don't think such library is hard to write in
> go, rust.., so every wallet implementation can use them.
That is not the problem. The problem is that our order flow is simple:
Seller: Offer
Buyer: Invoice Request
Seller: Invoice (or updated Offer)
Buyer/Seller: Payment & Acknowledgement (atomic)
(This could, of course, fit into a larger business flow.)
The closest UBL flow seems to be:
Seller: Quotation
Buyer: Order
Seller: (Prepayment)Invoice (or updated Quotation)
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 12:57:17 UTC

- 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 12:57:16 UTC

- 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 12:57:14 UTC

- reply

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

2023-06-09 12:57:13 UTC

- 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 12:57:12 UTC

- 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 12:57:11 UTC

- 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 12:57:10 UTC

- 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 12:57:07 UTC

- 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 12:57:07 UTC

- 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 12:57:06 UTC

- 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 12:57:05 UTC

- 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 12:57:04 UTC

- 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 12:57:04 UTC

- 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 12:57:00 UTC

- 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 12:54:29 UTC

- 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 12:54:28 UTC

- 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 12:52:54 UTC

- reply

📅 Original date posted:2018-11-16
📝 Original message:
Hi all,
I tried to simplify RBF as much as possible; it adds a *lot* of
complexity :( In particular, below we have one side pay the fees (and
thus responsible for RBF), in violation of the summit agreement,
and simplified the fee amount as much as reasonable.
RBF it implicitly requires multiple (exclusive) splices at once. This
will all require a great deal of testing...
Changes since initial proposal:
1. We add subtypes so `splice_init`/`splice_accept` etc are single
messages. These basically allow us to describe variable numbers of
variable-length fields.
2. We include both script and wscript in inputs, for p2sh-wrapping.
3. Initiator pays fees.
4. Other side gets to add the same number of inputs+outputs if they
want, minimum 2 (enough for one input, one change output).
5. If we both initiate a splice at once, *fundee*'s tiebreaker (well,
funder pays for everything else!).
6. Both sides give a max_extra_witness_len for inputs, to calc fee.
7. Every still-negotiable parameter is renegotiated.
8. We add RBF, at intiator's discretion (they're paying for it!)
9. The language "MUST fail the channel" has been made into "MUST error"
in antipation of "soft" errors.
### Initiating a splice: `splice_init`
1. type: 40 (`splice_init`) (`option_splice`)
2. data:
* [`32`:`channel_id`]
* [`4`:`feerate_per_kw`]
* [`2`:`num_inputs`]
* [`num_inputs*splice_input`]
* [`2`:`num_outputs`]
* [`num_outputs`*splice_output`]
* [`8`:`max_htlc_value_in_flight_msat`]
* [`8`:`channel_reserve_satoshis`]
* [`8`:`htlc_minimum_msat`]
* [`4`:`minimum_depth`]
* [`2`:`to_self_delay`]
1. subtype: `splice_input`
2. data:
* [`8`:`satoshis`]
* [`32`:`prevtxid`]
* [`4`:`prevtxoutnum`]
* [`2`:`scriptlen`]
* [`scriptlen`:`script`]
* [`2`:`max_extra_witness_len`]
* [`2`:`wscriptlen`]
* [`wscriptlen`:`wscript`]
1. subtype: `splice_output`
2. data:
* [`8`:`satoshis`]
* [`2`:`scriptlen`]
* [`scriptlen`:`script`]
The sender of `splice_init`:
- if a splice is already in progress
- MUST NOT send
- MUST ensure each `splice_input` refers to an existing UTXO.
- MUST ensure each `splice_output` is a standard script.
- SHOULD ensure that `feerate_per_kw` is sufficient for the splice
transaction to confirm.
- MUST set `feerate_per_kw` to 253 or more.
- MUST ensure it will have sufficient funds post-splice above its
reserve to pay for the splice transaction at the given `feerate_per_kw`
and the amount it contributes to the commitment_transaction fee
- MUST NOT have total `splice_output` `satoshis` greater than its current
balance minus reserve plus the total `splice_input` `satoshis`.
- MUST set `max_htlc_value_in_flight_msat`,
`channel_reserve_satoshis`, `htlc_minimum_msat`, `minimum_depth`,
`to_self_delay` as specified in `accept_channel`.
NOTES:
1. Are we *sure* we don't want to make channel_reserve_satoshis 1% of
capacity? That would remove a parameter here.
2. We explicitly allow a null splice to reset parameters or throw away history.
The receiver of `splice_init`:
- if it has also sent `splice_init`:
- if the receiver was the original sender of `open_channel`:
- MUST discard its own `splice_init`
- otherwise:
- MUST discard this `splice_init`.
- if a splice is in progress:
- MUST error.
- if `feerate_per_kw` is less than 253:
- SHOULD error.
- if the total post-splice balance of the sender would be
insufficient to meet its reserve plus the amount
it contributes to the commitment_transaction fee:
- MUST error.
- if both nodes advertised the `option_upfront_shutdown_script`
feature, and the receiving node received a non-zero-length
`shutdown_scriptpubkey` in `open_channel` or `accept_channel`, and
any splice_output that `shutdown_scriptpubkey` is not equal to `script`:
- MUST fail the connection.
- MUST respond to `max_htlc_value_in_flight_msat`,
`channel_reserve_satoshis`, `htlc_minimum_msat`, `minimum_depth`,
`to_self_delay` as specified in `accept_channel`.
- SHOULD reply with `splice_accept`
### Accepting a splice: `splice_accept`
1. type: 41 (`splice_accept`) (`option_splice`)
2. data:
* [`32`:`channel_id`]
* [`2`:`num_inputs`]
* [`num_inputs*splice_input`]
* [`2`:`num_outputs`]
* [`num_outputs`*splice_output`]
* [`8`:`max_htlc_value_in_flight_msat`]
* [`8`:`channel_reserve_satoshis`]
* [`8`:`htlc_minimum_msat`]
* [`4`:`minimum_depth`]
* [`2`:`to_self_delay`]
The sender of `splice_accept`:
- consider the `splice_limit` the total number of `splice_input` and
`splice_output` from `splice_init`, with minimum 2.
- MUST NOT send a number of `splice_input` and/or `splice_output`
which exceeds `splice_limit`.
- MUST ensure each `splice_input` refers to an existing UTXO.
- MUST ensure each `splice_output` is a standard script.
- MUST NOT have total `splice_output` `satoshis` greater than its current
balance minus reserve plus the total `splice_input` `satoshis`.
- MAY limit their `splice_input` and `splice_output`s to avoid
sending the sender of `splice_init` below reserve.
The receiver of `splice_accept`:
- If the number of `splice_input` and/or `splice_output` exceeds `splice_limit`:
- MUST error.
- if the total `splice_output` `satoshis` is greater than the
sender's current balance minus reserve plus the total `splice_input`
`satoshis`:
- MUST error.
- if both nodes advertised the `option_upfront_shutdown_script`
feature, and the receiving node received a non-zero-length
`shutdown_scriptpubkey` in `open_channel` or `accept_channel`, and
any splice_output that `shutdown_scriptpubkey` is not equal to `script`:
- MUST fail the connection.
- SHOULD send `splice_commitment_signature`
Both sides:
- MUST construct the resulting splice transaction as specified in <FIXME>
NOTES:
1. The receiver doesn't check transaction validity. Worst-case, it'll
never confirm, and never splice in.
2. We don't set size limits on inputs & outputs, and we probably should?
3. The initiator can be forced below their reserve by the recipient
adding their own splice in/outs. But that's OK.
1. type: 42 (`splice_commitment_signature`) (`option_splice`)
2. data:
* [`32`:`channel_id`]
* [`64`:`commitment_signature`]
* [`2`:`num_htlcs`]
* [`num_htlcs*64`:`htlc_signature`]
The sender:
- MUST set `commitment_signature` and `htlc_signature`s as done for
`commitment_signed`, but spending the funding output of the splice
transaction.
The recipient:
- if `signature` is not valid for its local splice commitment transaction:
- MUST fail the channel.
- if `num_htlcs` is not equal to the number of HTLC outputs in the local
splice commitment transaction:
- MUST fail the channel.
- if any `htlc_signature` is not valid for the corresponding HTLC transaction:
- MUST fail the channel.
- if the recipient was not the sender of `splice_init`:
- SHOULD send its own `splice_commitment_signature` in return.
- otherwise:
- SHOULD send `splice_confirm`.
### Confirming a splice: `splice_confirm`
1. type: 43 (`splice_confirm`) (`option_splice`)
2. data:
* [`32`:`channel_id`]
* [`64`:`signature`]
* [`2`:`num_witnesses`]
* [`num_witnesses*witness_stack`]
Each `witness` itself is serialized witness input stack:
1. subtype: `witness_stack`
2. data:
* [`2`:`num_input_stack`]
* [`num_input_stack`*`stack_element`]
1. subtype: `stack_element`
2. data:
* [`2`:`len`]
* [`len`:`element`]
The sender:
- MUST set `signature` to the signature for the splice transaction.
- MUST set `witness` to the marshalled witness data for each of its
inputs, in splice transaction order.
- MUST remember the details of this splice transaction.
- MUST NOT send a `witness_stack` whose length exceeds the
corresponding `max_extra_witness_len`.
The recipient:
- SHOULD check that
- SHOULD apply `signature` and `witness` to the splice transaction and
broadcast the result.
- If a `witness_stack` length exceeds the corresponding `max_extra_witness_len`:
- MAY error.
- if the recipient was the sender of `splice_init`:
- SHOULD reply with its own `splice_confirm`.
### Updating a splice: `splice_rbf`
1. type: 45 (`splice_rbf`) (`option_splice`)
2. data:
* [`32`:`channel_id`]
* [`4`:`fee_step`]
Each `fee_step` adds 1/4 (rounded down) to the initial splice
transaction fee. eg. if the initial fee was 1035 satoshi, `fee_step` 1
is 1035 + 1035 / 4 = 1293, `fee_step` 2 is 1293 + 1293 / 4 = 1616.
The sender:
- SHOULD send `splice_rbf` if the current splice transaction will not
confirm in a timely manner.
- MUST set `fee_step` greater than zero and greater than any prior `fee_step`.
- MUST be the sender of `splice_init`.
- MUST have already sent and received `splice_confirm` for the
previous splice transaction.
- MUST ensure it will have sufficient funds post-splice above its
reserve to pay for the splice transaction at the new feerate.
- MUST construct the resulting splice transaction as specified in <FIXME>
- SHOULD send `splice_commitment_signature` on the new splice
transation, and continue negotiation as before.
The recipient:
- if the sender of `splice_rbf` was not the sender of `splice_init`:
- MUST error.
- if the new fee exceeds the sender's current balance minus reserve
after it is applied to the splice transaction:
- MUST error.
- MUST construct the resulting splice transaction as specified in <FIXME>
- MUST handle `splice_commitment_signature` on the new splice
transation, and continue negotiation as before.
NOTES:
1. 1/4 is a reasonable minimal RBF, but as each one requires more
tracking by the recipient, serves to limit the number you can create.
### Completing a splice: `splice_rbf`
1. type: 45 (`splice_closed`) (`option_splice`)
2. data:
* [`32`:`channel_id`]
* [`32`:`splice_txid`]
The sender:
- MUST NOT send until the splice transaction has reached its own
`minimum_depth`.
- MUST set `splice_txid` to the txid of the splice transaction which confirmed.
Either node:
- if it has received and sent `splice_rbf`:
- MAY discard HTLCs and revocations requirements for states in
channel prior to the splice.
- MUST follow the requirements for `announcement_signatures` as if
this were a new channel.
Message Changes During Splicing
-------------------------------
Once you've sent `splice_confirm` each commitment transaction is needs
to be duplicated for every splice transaction (thanks to RBF, there can
be multiple at once). These are in rbf-received order (increasing fee
order, if initiator is spec compliant):
1. type: 39 (`closing_signed`)
2. data:
* [`32`:`channel_id`]
* [`8`:`fee_satoshis`]
* [`64`:`signature`]
* [`2`:`num_splice`] (`option_splice`)
* [`num_splice*64`:`splice_signature`] (`option_splice`)
1. subtype: `splice_signatures`
2. data:
* [`64`:`signature`]
* [`2`:`num_htlcs`]
* [`num_htlcs*64`:`htlc_signature`]
1. type: 132 (`commitment_signed`)
2. data:
* [`32`:`channel_id`]
* [`64`:`signature`]
* [`2`:`num_htlcs`]
* [`num_htlcs*64`:`htlc_signature`]
* [`2`:`num_splice`] (`option_splice`)
* [`num_splice*splice_signatures`] (`option_splice`)
If a reconnection occurs between between sending and receiving
`splice_confirm` or `splice_closed` the peer's status is uncertain. This we
have a new field in `channel_reestablish` to flag that we consider ourselves
to be splicing:
1. type: 136 (`channel_reestablish`)
2. data:
* [`32`:`channel_id`]
* [`8`:`next_local_commitment_number`]
* [`8`:`next_remote_revocation_number`]
* [`32`:`your_last_per_commitment_secret`] (`option_data_loss_protect`)
* [`33`:`my_current_per_commitment_point`] (`option_data_loss_protect`)
* [`2`:`num_splice`] (`option_splice`)
The sender:
- MUST set `num_splice` to the number of `splice_confirm` it has received for
the current splice operation, or 0 if no current splice operation.
The recipient:
- if `num_splice` is less than the number of `splice_confirm` it has sent for the current splice operation:
- MUST re-transmit the last splice_confirm.
- if `num_splice` is more than the number of `splice_confirm` it has sent for the current splice operation:
- MUST re-transmit the last splice_closed.
NOTES:
1. I suggest that the option_data_loss_protect fields MUST BE set here if
option_splice (there's no reason not to AFAICT). Or do we want to try TLV
here?

2023-06-09 12:52:50 UTC

- reply

📅 Original date posted:2018-11-15
📝 Original message:
Hi all,
I want to propose a method of having reusable BOLT11 "offers" which
provide almost-spontaneous payments as well as not requiring generating
a BOLT11 invoice for each potential sale.
An "offer" has a `p` field of 26 bytes (128 bits assuming top two are 0)
(which is ignored by existing nodes). The payer uses a new lightning
probe message using the current onion format we use for HTLCs to
retreive the complete invoice.
The format of the final-hop lightning onion would contain:
[whatever-marker-we-need?][128-bit-`p`-field][[type,len,data]+]
We would probably define a few optional types to start:
1. quantity: for ordering multiple of an item, default 1.
2. delivery-address: steal from https://www.w3.org/TR/vcard-rdf/#Delivery_Addressing_Properties ?
3. signature: basically a blob so payer can prove it was them.
The return lightning message would contain a new bolt11 invoice (perhaps
we optimize some fields by copying from the bolt11 offer if they don't
appear?), and an additional field:
`m` (27) `data_length` 52. Merkle hash of fields payer provided
in onion msg above, and the offer `p` value.
The payer checks the signature is correct, `m` is correct, and uses the
invoice to pay as normal. The bolt11 offer + fields-from-onion + bolt11
invoice + preimage is the complete proof of payment.
Refinements
-----------
We can generate alternate leaves for the merkle tree (using
SHA256(shared-secret | leafnum)) so revealing the `m` value doesn't risk
revealing your delivery-address for example.
The return needs to list the fields it *didn't* include in the merkle
because it didn't accept them (the merchant doesn't want to be bound to
conditions it doesn't understand!).
We could add a `k` field to the bolt11 offer to allow the final invoice
to delegated to a separate key.
The default `x` (expiry) field for an offer which does not have an
old-style 53-byte `p` field (ie. a "pure" offer) could be infinite.
We could merkelize the delivery-address too :)
I've handwaved a bit over the detailed format, because there are other
things we want to put in the onion padding, and because the return is
similar to the "soft-error"/"partial payment ack" proposals.
Results
-------
This gives us static invoicing, and a single static invoice (without an
amount field) can thus be used to approximate "spontaneous" donations,
while still providing proof of payment; indeed, providing
non-transferrable proof-of-payment since the invoice now commits to the
payer-provided signature.
It also provides a platform for recurring payments: while we can do this
with preimage-is-next-payment_hash, that requires pre-generation and
isn't compatible with static invoices.
I apologize that this wasn't fleshed out before the summit, but I
overestimated the power of Scriptless Scripts so had mentally deferred
this.
Thanks!
Rusty.

2023-06-09 12:52:46 UTC

- reply

📅 Original date posted:2018-11-22
📝 Original message:
Conner Fromknecht <conner at lightning.engineering> writes:
> Hi all,
>
>> But it's unnecessary for the recipient to know the total amount I meant
>> to pay; they just need to return the receipt once it exceeds the amount
>> they want.
>
> I think it’s true that the recipient doesn’t need to know necessarily, but
> sending the intended amount is more robust IMO, since it provides an order
> invariant hint for when the receiver can safely settle.
>
> If the sender does amount fuzzing (as CL does) or adds a tip, it’s possible
> for the final partial payment to be less than `amount_to_pay` -
> `invoice_amount`, causing the sender to settle prematurely. Otherwise, we
> might want to specify that no split should be less than the amount
> overpaid.
>
> Of course, if that amount never comes through yet the invoice is satisfied,
> the receiver can always choose to settle even if the remaining amount never
> arrives.
It's more code, and takes 8 more bytes out of the onion. I've started
coding up option_simplfied_commitment and it's making me terrified of
adding any additional complexity :(
The more compelling argument is that partial-payment donations might
want this, but it's marginal, IMHO. We should be aiming for static
invoices for the donate case.
Cheers,
Rusty.

2023-06-09 12:52:45 UTC

- reply

📅 Original date posted:2018-11-20
📝 Original message:
René Pickhardt via Lightning-dev <lightning-dev at lists.linuxfoundation.org> writes:
> Hey List,
>
> as this base AMP proposal seems pretty small I just started to write this
> up to make a PR for BOLT04 and BOLT11. While doing my write up I realize
> that there are smaller things that I would want to verify / double check
> and propose with you.
>
> ## Verifying:
> 1.) I understand the receiving node signals support for Base AMP by setting
> a feature bit in the BOLT11 String
Yes, this seemed a logical reason to add features to BOLT11.
> 2.) The sending node signals a multipath payment by setting a feature bit
> and by using the same `amount to forward` value in the last hop of the
> onion for all paths which will also be bigger that the incoming htlcs whose
> sum has to be at least the size of `amount_to_forward`.
Not a feature bit as such, but some signal for the final node (in the
onion). And do not play with `amount_to_forward`, as it's an important
signal to the final node that the previous node did not offer less value
for the HTLC than it was supposed to. (You could steal the top bit to
signal partial payment if you really want to).
> ## Clarifying:
> 3.) Senders MUST NOT (SHOULD NOT?) create paths which would have to be
> merged by intermediary nodes (as we don't know - and have no means of
> querying - if they support the format of the adepted onion packages for
> partial paths. Also it even seems impossible since the rest of the path for
> at least one partial path could not be stored in the onion / forwarded
> onions can't be seen)
In-path merging is overreach, let's not do it or mention it.
There's a slight preference to avoid sharing intermediary nodes to avoid
correlation. Intermediary nodes know they need to forward all of them
or not get paid for any of them, and they're already supposed to do so.
> ## Proposing:
> Should we specify an algorithm for executing a multipath payment for the
> sending node or should this be left to the implementation. An obvious Idea
> for an algorithm would be a divide and conquer scheme which should be
> obvious with the following python style pseudo code:
>
> def pay_base_amp(amount):
> success = False
> for route in get_available_routes():
> success = send_via_route(route, amount)
> if not success:
> pay_base_amp(amount/2 + 1) # the +1 is to mitigate rounding errors.
> there could be other ways to do so.
> pay_base_amp(amount/2 + 1)
I don't think this is actually useful. For example, I would suggest a
more random split, and start by using some estimate of channel capacity.
> Even if we leave the exact AMP execution to the sender we could still
> suggest this divide and conquer scheme in BOLT 04
>
> Another idea I had (which is probably a bad one as it allows for probing of
> channel balances) would be to allow nodes on a partial path to send back
> some hints of how much additional capacity they can forward if they see
> that the partial payment feature bit is set (this would require to set this
> feature bit in every onion) Also if we want to make use of this information
> every node would have to support base amp. So I guess this idea is bad for
> several reasons. Still we could have a MAY rule out of it?
I think we should adapt a convention for a lower limit at which we
disable the channel if we can't forward (eg 1% of capacity? 100
satoshis?). That gives us a better starting point for AMP, too.
Cheers,
Rusty.

2023-06-09 12:52:42 UTC

- reply

📅 Original date posted:2018-11-13
📝 Original message:
ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org> writes:
> Good morning list,
>
> I propose the below to support Base AMP.
I think the complexity outweighs the benefits for the moment. The
sender would have to make the onions identical past the merge point (so
any one of them could be used), the merge point has to now create a
many:1 map for HTLC redemption.
For the moment, I think we should stick with:
BOLT #4:
1. type: `per_hop`
2. data:
* [`8`:`short_channel_id`]
* [`8`:`amt_to_forward`]
* [`4`:`outgoing_cltv_value`]
- * [`12`:`padding`]
+ * [`1`:`flags`]
+ * [`11`:`padding`]
And define bit 0 of `flags` as `incomplete_payment`. For the moment, it
is only allowed for final nodes, and only if they put it in their BOLT11
field.
BOLT #11:
* `9` (5): `data_length` variable. Features supported for receiving
this payment. Currently only `wait_on_incomplete` (bit 1) is defined.
...
-A writer SHOULD use the minimum `data_length` possible for `x` and `c` fields.
+A writer SHOULD use the minimum `data_length` possible for `x`, `c` and
`9` fields, omitting the field entirely if possible.
...
A payer MUST ignore unknown odd bits are set in the `9` field, and
NOT try to make a payment if unknown even bits are set in the `9` field.
Cheers,
Rusty.

2023-06-09 12:52:11 UTC

- reply

📅 Original date posted:2018-11-06
📝 Original message:
Olaoluwa Osuntokun <laolu32 at gmail.com> writes:
> Hi Rusty,
>
> I'm a big fan in general of most of this! Amongst many other things, it'll:
> simplify the whole static channel backup + recovery workflow, and avoid all
> the fee related headaches we've run into over the past few months.
I certainly hope so!
>> - HTLC-timeout and HTLC-success txs sigs are
>> SIGHASH_ANYONECANPAY|SIGHASH_SINGLE, so you can Bring Your Own Fees.
>
> Would this mean that we no longer extend fees to the second-level
> transactions as well? If so, then a dusty HTLC would be determined solely by
> looking at the direct output, rather than the resulting output in the second
> layer.
Good point, yes.
>> - `localpubkey`, `remotepubkey`, `local_htlcpubkey`, `remote_htlcpubkey`,
>> `local_delayedpubkey`, and `remote_delayedpubkey` derivation now uses a
>> two-stage unhardened BIP-32 derivation based on the commitment number.
>
> It seems enough to _only_ modify the derivation for local+remote pubkey (so
> the direct "settle" keys). This constrains the change to only what's
> necessary to simplify the backup+recovery workflow with the current
> commitment design. By restricting the change to these two keys, we minimize
> the code impact to the existing implementations, and avoid unnecessary
> changes that don't make strides towards the immediate goal.
I was thinking in the long term when we drop backwards compat, then we
only have one derivation scheme?
>> - `to_remote` is now a P2WSH of:
>> `to_self_delay` OP_CSV OP_DROP <remotepubkey> OP_CHECKSIG
>
> This seems at odds with the goal of "if the remote party force closes, then
> I get my funds back immediately without requiring knowledge of any secret
> data". If it was just a plain p2wkh, then during a routine seed import and
> rescan (assuming ample look ahead as we know this is a "special" key), I
> would pick up outputs of channels that were force closed while I was down
> due to my dog eating my hard drive.
Good point; we need to weigh the benefits of symmetry (which seems to
require this) against this additional complication.
> Alternatively, since the range of CSV values can be known ahead of time, I
> can brute force a set of scripts to look for in the chain. However, this
> results in potentially a very large number of scripts (depending on how many
> channels one has, and bounds on the acceptable CSV) I need to scan for.
I don't suppose we could get everyone to agree on the same CSV values? :)
Cheers,
Rusty.

2023-06-09 12:52:06 UTC

- reply

📅 Original date posted:2018-11-05
📝 Original message:
Anthony Towns <aj at erisian.com.au> writes:
> FWIW, I don't see reddit as a particularly viable "court"; there's
> no way for reddit to tell who's actually right in a dispute, eg if I
> say blockstream didn't send stickers I paid for, and blockstream says
> they did; ie there's no need for a sock puppet in the above scenario,
> blockstream can just say "according to our records you signed for
> delivery, stop whinging".
Well, in that case they can show a tracking number and Canada Post link?
We will eventually develop systems of arbitration better than "whining
on reddit/twitter", but that's where bitcoin was in its early days, so I
use it as a useful starting point to think about receipts when we lack
an intermediary.
> I think there's maybe four sorts of "proof of payment" people might
> desire:
>
> 0) no proof: "completely" deniable payments (donations?)
>
> 1) shared secret: ability to prove directly to the payee that an
> invoice was paid (what we have now)
We also, importantly, have the ability to tie the receipt to the
invoice.
> 2) signed payment: ability to prove to a different business unit of
> the payee that payment was made, so that you can keep all the
> secrets in the payment-handling part, and have the service-delivery
> part not be at risk for losing all your money
Hmm, this requires auditing the current commitment transaction I think
("see, I'm holding the money!"). I have to think about this some
more...
> 3) third-party verifiable: so you can associate a payment with real
> world identity information, and take them to court (or reddit) as a
> contract dispute; needs PKI infrastructure so you can be confident
> the pubkey maps to the real world people you think it does, etc
Yes, we're still missing that last mile between the merchant and the
nodeid. There's a proposal to do this with DNS records, there's the
LetsEncrypt-style "serve this URL", but we also need something like
Certificate Transparency so I can reliably get old nodeids...
But the perfect is the enemy of the good, too.
Cheers,
Rusty.

2023-06-09 12:52:05 UTC

- reply

📅 Original date posted:2018-11-04
📝 Original message:
ZmnSCPxj <ZmnSCPxj at protonmail.com> writes:
> Good morning Rusty and aj and list,
>
>>
>> > > In the payer-supplied data case, I think 'm' should include a signature
>> > > for a key only the payer knows: this lets them prove they made the
>> > > payment.
>> >
>> > I don't object to that, but I think it's unnecessary; as long as there
>> > was a payment for delivery of the widget to "aj" in "Australia" does it
>> > matter if the payment was technically made by "aj" by "Visa on behalf
>> > of aj" or by "Bank of America on behalf of Mastercard on behalf of aj's
>> > friend who owed him some money" ?
>>
>> You often don't want the vendor to know anything about you, and there's
>> often no reason why they should.
>>
>> And it just doesn't work unless you give over uniquely identifying
>> information. AJ posts to r/bitcoin demonstrating payment, demanding his
>> goods. Sock puppet says "No, I'm the AJ in Australia" and cut & pastes
>> the same proof.
>>
>
> Technically speaking, all that AJ in Australia needs to show is that he or she knows, the private key behind the public key that is indicated on the invoice.
>
> Before payment, only the payee knows this private key.
>
> After payment, both AJ in Australia and the payee know this private key (since the payment is conditional on AJ in Australia learning this key).
But the merchant (payee) knows it too. So the lizard masters[1] at
Blockstream can produce this proof as well?
Cheers,
Rusty.
[1] https://twitter.com/rusty_twit/status/1057794540122206208

2023-06-09 12:52:04 UTC

- reply

📅 Original date posted:2018-11-04
📝 Original message:
Anthony Towns <aj at erisian.com.au> writes:
>> In the payer-supplied data case, I think 'm' should include a signature
>> for a key only the payer knows: this lets them prove *they* made the
>> payment.
>
> I don't object to that, but I think it's unnecessary; as long as there
> was a payment for delivery of the widget to "aj" in "Australia" does it
> matter if the payment was technically made by "aj" by "Visa on behalf
> of aj" or by "Bank of America on behalf of Mastercard on behalf of aj's
> friend who owed him some money" ?
You often don't want the vendor to know anything about you, and there's
often no reason why they should.
And it just doesn't work unless you give over uniquely identifying
information. AJ posts to r/bitcoin demonstrating payment, demanding his
goods. Sock puppet says "No, I'm the AJ in Australia" and cut & pastes
the same proof.
Even if you did, that's exactly the problem we have now. *In theory*
the invoice should be specific enough that it identifies where they
shipped the item, in practice it never is (even the Blockstream store
gets this wrong!).
Sure, in case of digital delivery there's no proof that delivery
(didn't) happen, but you can at least show you paid.
>> How does this interact with AMP, however?
>
> The way I see it is they're separate: you have a way of getting the
> preimage back over lightning (which is affected by AMP), and you have a
> way of turning a preimage into a third-party-verifiable PoP (with
> Schnorr or whatever).
>
> (That might not be true if there's a clever way of safely feeding the
> nonce R back, so that you can go straight from a generic offer to an
> accepted payment with proof of payment)
>
>> > With seckp256k1 preimages, it's easy to reduce that to sig=(R,s),
>> > and needing to communicate an R to the payer initially, who can then
>> > calculate S and send "m" along with the payment.
>> OK, I buy that.
>
> Crap, do I need to give you proof of payment for it now? :)
Please :)
>> > - just send multiple payments with the same hash:
>> > works with sha256
>> > privacy not improved much (some intermediary nodes no longer know
>> > full invoice value)
>> > can claim partial payments as soon as they arrive
>> > accepting any partial payment provides proof-of-payment
>>
>> Interestingly, if vendor takes part payment, rest can be stolen by
>> intermediaries.
>
> Or you could just see a $5 bill, send $0.50 through, and wait to see
> if the take the partial payment immediately before even trying the
> remaining $4.50.
Sure, that's true today, too?
>> > - secp256k1: ("high AMP" ?)
>> > needs secp256k1 preimages
>> > works fine with decorrelation improving privacy at every step
>> > can set it up so can only claim once all partial payments arrive
>> > accepting partial payment provides proof-of-payment
>> Yes. Though I'm not sure exactly how this works with your scheme
>> above...
>
> Vendor -> *: "I sell widgets for 0.01 BTC, my pubkey is P"
> Customer -> Vendor: "I want to buy a widget"
> Vendor -> Customer: "Here's an R value"
> Customer: calculates S = R + H(P,R,"send $me a widget at $address")*P
> Customer -> Vendor: "here's 0.01 BTC for s corresponding to S, my
> details are R, $me, $address"
> Vendor: looks up r for R=r*G, calculates s = r + H(P,R,"send $me a
> widget at $address")*p, checks S=s*G
> Vendor -> Customer: <accepts payment, revealing s>
>
> Customer -> Court: reveals the invoice ("send $me a widget...") and the
> signature by Vendor's pubkey P, (s,R)
>
> I think the way to do secp256k1 AMP with that is that when sending
> through the payment is for the customer to send three payments to the
> Vendor conditional on preimages for A,B,C calculated as:
>
> A = S + H(1,secret)*G
> B = S + H(2,secret)*G
> C = S + H(3,secret)*G
Note: I prefer the construction H(<secret>,<part-of-secret-in-that-payment>)
which doesn't require an explicit order.
> where "secret" is your xor of info from each of the three message hashes.
Note that this only works if the message "send $me a widget at $address"
includes a nonce, since it may be easily grindable otherwise.
Since I'm suggesting it include a signature in msg, we're covered here.
We could chacha20 the msg in A, and just xor the key between other
payments for a bit of space saving.
>> > In theory, both "just send multiple payments" and "secp256k1" could have
>> > splitting and joining at any hop, if we could encode the instructions
>> > on how to do that in the onion message; joining is probably easy, but
>> > splitting seems like it might be hard?
>> I don't think so. If you can join two payments, it wasn't private?
>
> Sorry, I mean "source-directed splits and joins", so rather than
> your source routing being a linear "me -> A -> B -> C -> D -> you",
> you specify a graph: "me -> A -> B,E ; B -> C ; E -> F -> G ; C,G ->
> D -> you" so you tell "A" how to split the payment into two new routes,
> and tell "D" to join two payments and continue it on. The ECC part works
> fine for that, but the onion routed messages seem difficult and probably
> not worth considering for spec v1.1.
I'm not sure I see the benefit over just treating them independently,
so I also think we should defer.
>> [1] If we're not careful we're going to implement HORNET so we can pass
>> arbitrary messages around, which means we want to start charging for
>> them to prevent spam, which means we reopen the pre-payment debate, and
>> need reliable error messages...
>
> Could leave the interactivity to the "web store" layer, eg have a BOLT
> 11 v1.1 "offer" include a url for the website where you go an enter your
> name and address and whatever other info they need, and get a personalised
> BOLT 11 v1.1 "invoice" back with payment-hash/nonce/signature/whatever?
I think that's out-of-scope, and I generally dislike including a URL
since it's an unsigned externality and in practice has horrible privacy
properties.
Cheers,
Rusty.

2023-06-09 12:52:03 UTC

- reply

📅 Original date posted:2018-11-04
📝 Original message:
Anthony Towns <aj at erisian.com.au> writes:
>> > - channel announcements: do you support secp256k1 for hashes or just
>> > sha256?
>> Worse, it becomes "I support secp256k1 with ECDSA" then a new "I support
>> secp256k1 with Schnorr". You need a continuous path of channels with
>> the same feature.
>
> I don't think that's correct: whether it's 2p-ecdsa, Schnorr or script
> magic only matters for the two nodes directly involved in the channel
> (who need to be able to understand the commitment transactions they're
> signing, and extract the private key from the on-chain tx if the channel
> gets unilaterally closed). For everyone else, they just need to know that
> they can put in a public key based HTLC, and get back the corresponding
> private key when the HTLC goes through.
I'm not sure. Jonas Nick proposed a scheme, which very much assumes
Schnorr AFAICT:
Jonas Nick wrote:
> How I thought it would work is that the invoice would contain a
> Schnorr nonce R. Then the payer would construct s*G = R +
> H(payee_pubkey,R,"I've bought 5 shirts shipped to Germany")*G. Then
> the payer builds the scriptless script payment path such that when the
> payee claims, the payer learns s and thus has a complete
> signature. However, that doesn’t work with recurrent payments because
> the payee can use the nonce only once.
I would probably enhance this to include a nonce, which allows for AMP
(you have to xor the AMP payments to get the nonce):
R + H(payee_pubkey,R,"I've bought 5 shirts shipped to Germany",NONCE)*G
> I think it makes sense to think of proof-of-payment in terms of a
> verification algorithm (that a third party court could use), that takes:
>
> m - the invoice details, eg
> "aj paid $11 for stickers to be delivered to Australia"
> P - the pubkey of the vendor
> sig - some signature
>
> With the current SHA256 preimages, you can make sig=(R,s,pre)
> where the sig is valid if:
>
> s*G = R + H(P,R,m+SHA256(pre))*P
>
> If you share R,s,SHA256(pre) beforehand, the payer can tell they'll have
> a valid signature if they pay to SHA256(pre). That's a 96B signature,
> and it requires "pre" be different for each sale, and needs pre-payment
> interactivity to agree on m and communicate R,s back to the payer.
For current-style invoices (no payer-supplied data), the payee knows
'm', so no interactivity needed, which is nice.
In the payer-supplied data case, I think 'm' should include a signature
for a key only the payer knows: this lets them prove *they* made the
payment.
How does this interact with AMP, however?
> With seckp256k1 preimages, it's easy to reduce that to sig=(R,s),
> and needing to communicate an R to the payer initially, who can then
> calculate S and send "m" along with the payment.
OK, I buy that.
> Maybe it makes sense to disambiguate the term "invoice" -- when you don't
> know who you might be giving the goods/service to, call it an "offer",
> which can be a write-once/accept-by-anyone deal that you just leave on
> a webpage or your email signature; but an "invoice" should be specific
> to each individual payment, with a "receipt" provided once an invoice
> is paid.
"offer" is a good name, since I landed on the same one while thinking
about this too :)
For an "offer" you would need a (lightning-network-carried) req/resp to
get the per-payment invoice. An offer could use a 128-bit 'p': smaller
would do, but this is too large to brute-force iterate through (hey, I
wonder if they sell other stuff?).
> Rereading through the AMP threads, Christian's post makes a lot of sense
> to me:
>
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/001023.html
>
> I'm not really seeing the benefits in complicated AMP schemes without
> decorrelation...
In practice it should increase reliability of payments through capacity
bottlenecks. But don't underestimate the benefits of PoP: we're so used
to intermediates we take it for granted, but once the middleman is
removed the ability to prove the invoice/payment cycles is vital for
usability.
> It seems to me like there are three levels that could be implemented:
>
> - laolu/conner: ("low AMP" ?)
> works with sha256
> some privacy improvement
> loses proof-of-payment
> can't claim unless all payments arrive
Yep.
> - just send multiple payments with the same hash:
> works with sha256
> privacy not improved much (some intermediary nodes no longer know
> full invoice value)
> can claim partial payments as soon as they arrive
> accepting any partial payment provides proof-of-payment
Interestingly, if vendor takes part payment, rest can be stolen by
intermediaries. This puts pressure on vendor to treat them atomically.
I haven't thought about this before, but it has desirable attributes.
(If the contract is "you will only release preimage once you've got the
payment", all this requires is a single bit to say "I know this is
partial, more are coming, please wait").
> - secp256k1: ("high AMP" ?)
> needs secp256k1 preimages
> works fine with decorrelation improving privacy at every step
> can set it up so can only claim once all partial payments arrive
> accepting partial payment provides proof-of-payment
Yes. Though I'm not sure exactly how this works with your scheme
above...
> In theory, both "just send multiple payments" and "secp256k1" could have
> splitting and joining at any hop, if we could encode the instructions
> on how to do that in the onion message; joining is probably easy, but
> splitting seems like it might be hard?
I don't think so. If you can join two payments, it wasn't private? For
splitting, in the specific case of having two channels between the same
nodes, you might be able to do something, but that's a pretty narrow
case. And as TCP discovered, you're better off failing back to sender
than trying to add fragmentation to the protocol.
Note: if we need an interaction message for BOLT11 features we want in
future[1], then it has the advantage that it decouples the bolt11
features from changing preimages to secp256k1. That makes this question
*critical* for the Summit next week.
Thanks!
Rusty.
[1] If we're not careful we're going to implement HORNET so we can pass
arbitrary messages around, which means we want to start charging for
them to prevent spam, which means we reopen the pre-payment debate, and
need reliable error messages...

2023-06-09 12:52:01 UTC

- reply

📅 Original date posted:2018-11-02
📝 Original message:
Anthony Towns <aj at erisian.com.au> writes:
> On Fri, Nov 02, 2018 at 10:20:46AM +1030, Rusty Russell wrote:
>> There's been some discussion of what the lightning payment flow
>> might look like in the future, and I thought I'd try to look forwards so
>> we can avoid painting ourselves into a corner now. I haven't spent time
>> on concrete design and implementation to be sure this is correct,
>> however.
>
> I think I'd like to see v1.1 of the lightning spec include
> experimental/optional support for using secp256k1 public/private keys
> for payment hashes/preimages. That assumes using either 2-party ECDSA
> magic or script magic until it's viable to do it via Schnorr scriptless
> scripts, but that seems like it's not totally infeasible?
Not totally infeasible, but since every intermediary needs to support
it, I think we'd need considerable buy-in before we commit to it in 1.1.
> I think the
> components would need to be:
>
> - invoices: will the preimage for the hash be a secp256k1 private key
> or a sha256 preimage? (or payer's choice?)
>From BOLT11:
The `p` field supports the current 256-bit payment hash, but future
specs could add a new variant of different length, in which case
writers could support both old and new, and old readers would ignore
the one not the correct length.
So the plan would be you provide two `p` fields in transition.
> - channel announcements: do you support secp256k1 for hashes or just
> sha256?
Worse, it becomes "I support secp256k1 with ECDSA" then a new "I support
secp256k1 with Schnorr". You need a continuous path of channels with
the same feature.
> - node features: how do you support secp256k1? not at all (default),
> via 2p-ecdsa, via script magic, (eventually) via schnorr, ...?
We could make these global feature bits, if you want to preferentually
establish channels with nodes who support a specific feature.
> I think this is (close to) a necessary precondition for payment
> decorrelation, AMP, and third-party verifiable proof-of-payment.
Yes, that's the easy part :)
...
> Even if you calculate r differently, I don't think you can do this
> without Bob and Alice interacting to get the nonce R prior to sending
> the transaction, which seems effectively the same as having dynamic
> invoice hashes, though.
I know Andrew Poelstra thought it was possible, so I'm going to leave a
response to him :)
> Maybe querying for a nonce through the lightning network would make
> sense though, which would allow the "invoice" to be static, and all the
> dynamic things would be via lightning p2p? That step could perhaps be
> combined with the 0 satoshi payment probes that Fabrice proposes in
>
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-October/001484.html
>
> but I think replying with a public nonce value would need a new message
> type of some sort?
We might eventually end up going full HORNET, for other reasons. But it
places demands on the network which need careful consideration, and the
more traffic you send the more chances for analysis. A single pass is
enough.
> I think AMP is independent, other than also using secp256k1 preimages
> rather than SHA256. I think AMP splits and joins are just:
>
> - if you're joining incoming payments, don't forward until you've
> got all the HTLCs, and ensure you can generate the secret for each
> incoming payment from the single outgoing payment
>
> - if you're splitting an incoming payment into many outgoing payments,
> ensure you can claim the incoming payment from *any* outgoing
> payments' secret
>
> Which I think in practice just means knowing x_i for each input, and
> y_j for each output other than the first, and verifying:
>
> I_i = O_1 + x_i*G
> O_j = O_1 + y_j*G
>
> (this gives I_i = O_j + (x_i-y_j)*G and the corresponding secret being
> i_i = o_j + x_i - y_j) allowing you to claim all incoming HTLCs given
> the secret from any outgoing HTLC)
I think a general scheme is: payer creates a random group-marker, sends
<group-marker><32-byte-randomness>[encrypted data...] in each payment.
Receipient collects payments by <group-marker>, xoring the
<32-byte-randomness>; if that xor successfully decrypts the data, you've
got all the pieces.
(For low-AMP, you use payment_hash as <group-marker>, and just use
SHA256(<xor-of-all-randomness><32-byte-randomness>) as the per-payment
preimage so no [encrypted data] needed).
Cheers,
Rusty.

2023-06-09 12:52:01 UTC

- reply

📅 Original date posted:2018-11-01
📝 Original message:
Hi all,
There's been some discussion of what the lightning payment flow
might look like in the future, and I thought I'd try to look forwards so
we can avoid painting ourselves into a corner now. I haven't spent time
on concrete design and implementation to be sure this is correct,
however.
Current Status
--------------
Currently, one invoice can be paid 0 or 1 times. There is no safe
invoice reuse. The payer can prove the node offered the invoice (it is
signed), and that someone paid the invoice, but not that they
specifically did: the lightning nodes along the path and the merchant
themselves also have the preimage. This implies that the invoice itself
should have enough information to make that link, eg. with a description
of "1 T-shirt to Rusty in Australia", otherwise the payer can say "here,
I paid for 1 T-shirt" and the merchant says "no, that invoice was for a
T-shirt we shipped to Austria".
Desired Status
--------------
Ideally, you could create one invoice which could be paid arbitrary many
times, by different individuals. eg. "My donation invoice is on my web
page", or "I've printed out the invoice for a widget and stuck it to the
widget", or "Pay this invoice once a month please".
Also, you should be able to prove you've paid, in a way I can't just
copy the proof and claim I paid, too, even if I'm the merchant, and that
you agreed to my terms, eg. "I'm paying for 500 widgets to be shipped to
Rusty in Australia".
Required Magic
--------------
It seems that scriptless scripts will allow this: an HTLC signature
would commit to the invoice/"payment_hash" as well as "something I sent
to you in the payment onion". That "something" has to be well-defined
in the protocol, of course, since the merchant will have to parse it and
understand the conditions it presents before accepting the payment. I
have an idea that we could merkelize the information to allow you to
partially reveal it if you wanted to.
This also enables full AMP (I think), where you receive the payment
proof despite using AMP. I call this "High AMP" vs the current proposal
("Low AMP") which trusts the merchant to deliver.
This is a subtle change in semantics: currently the lightning layer only
provides assistance metadata (eg. routing), and the entire protocol can
be played out onchain. This is no longer true: the onchain data is not
sufficient for you to accept a payment. However, this was practically
untrue anyway.
Lesser Magic
------------
It's possible to do spontaneous donations *without* proof of payment
today (I simply give you the preimage in the onion). Low-AMP relies on a
similar trick.
It's even possible to do recurring payments, if each preimage you get is
the payment_hash for the next payment.
None of this is supported in the 1.0 protocol, but I'm sure we'll have
vigorous debate over how much of this gets into 1.1 at the Summit next
week.
Cheers,
Rusty.

2023-06-09 12:51:50 UTC

- reply

📅 Original date posted:2018-10-12
📝 Original message:
ZmnSCPxj <ZmnSCPxj at protonmail.com> writes:
> Sent with ProtonMail Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Friday, October 12, 2018 2:36 PM, Rusty Russell <rusty at rustcorp.com.au> wrote:
>
>> ZmnSCPxj ZmnSCPxj at protonmail.com writes:
>>
>> > Good morning Rusty and list,
>> >
>> > > 1. Rather than trying to agree on what fees will be in the future, we
>> > > should use an OP_TRUE-style output to allow CPFP (Roasbeef)
>> > >
>> >
>> > My understanding is that this would require some base-layer changes at Bitcoin level first? At minimum IsStandard() modification, and I believe luke-jr suggested, to make a consensus rule that OP_TRUE would not be spendable beyond the block it appears in (i.e. it is used only for CPFP hooking) to reduce UTXO database size at lower layer.
>>
>> If you look further down, it's actually a P2WSH to "OP_TRUE". Wastes
>> some space, but it works today.
>
> Ah, I see. This will change again if the luke-jr proposal pushes through?
>
> Will robots arise which will attempt to claim as many OP_TRUE outputs as they can find, claiming them afterwards during very-low-fee periods?
I hope so! It's our technique to avoid polluting the UTXO set.
Cheers,
Rusty.

2023-06-09 12:51:50 UTC

- reply

📅 Original date posted:2018-10-12
📝 Original message:
ZmnSCPxj <ZmnSCPxj at protonmail.com> writes:
> Good morning Rusty and list,
>
>>
>> 1. Rather than trying to agree on what fees will be in the future, we
>> should use an OP_TRUE-style output to allow CPFP (Roasbeef)
>>
>
> My understanding is that this would require some base-layer changes at Bitcoin level first? At minimum IsStandard() modification, and I believe luke-jr suggested, to make a consensus rule that OP_TRUE would not be spendable beyond the block it appears in (i.e. it is used only for CPFP hooking) to reduce UTXO database size at lower layer.
If you look further down, it's actually a P2WSH to "OP_TRUE". Wastes
some space, but it works today.
>> 3. The CLTV timeout should be symmetrical to avoid trying to game the
>> peer into closing. (Connor IIRC?).
>
> I know this has been discussed before, but I wonder the rationale for the original asymmetric design, and the rationale for the new symmetric design.
The original design does the minimum necessary (you *must* have a
to-yourself delay to give time for the penalty tx to work). But, when
combined with fee asymmetry (funder pays), it can lead the fundee to not
care whether it forces the funder to perform a unilateral, or does a
graceful mutual close.
It's not a major issue, but aligning incentives (to mutual close) makes
sense if we're changing other things I think.
Cheers,
Rusty.

2023-06-09 12:51:49 UTC

- reply

📅 Original date posted:2018-10-12
📝 Original message:
Hi all,
There have been a number of suggested changes to the commitment
transaction format:
1. Rather than trying to agree on what fees will be in the future, we
should use an OP_TRUE-style output to allow CPFP (Roasbeef)
2. The `remotepubkey` should be a BIP-32-style, to avoid the
option_data_loss_protect "please tell me your current
per_commitment_point" problem[1]
3. The CLTV timeout should be symmetrical to avoid trying to game the
peer into closing. (Connor IIRC?).
It makes sense to combine these into a single `commitment_style2`
feature, rather than having a testing matrix of all these disabled and
enabled.
BOLT #2:
- If `commitment_style2` negotiated, update_fee is a protocol error.
This mainly changes BOLT #3:
- The feerate for commitment transactions is always 253 satoshi/Sipa.
- Commitment tx always has a P2WSH OP_TRUE output of 1000 satoshi.
- Fees, OP_TRUE are always paid by the initial funder, because it's simple,
unless they don't have funds (eg. push_msat can do this, unless we remove it?)
- HTLC-timeout and HTLC-success txs sigs are
SIGHASH_ANYONECANPAY|SIGHASH_SINGLE, so you can Bring Your Own Fees.
- `localpubkey`, `remotepubkey`, `local_htlcpubkey`,
`remote_htlcpubkey`, `local_delayedpubkey`, and `remote_delayedpubkey`
derivation now uses a two-stage unhardened BIP-32 derivation based on
the commitment number. Two-stage because we can have 2^48 txs and
BIP-32 only supports 2^31: the first 17 bits are used to derive the
parent for the next 31 bits?
- `to_self_delay` for both sides is the maximum of either the
`open_channel` or `accept_channel`.
- `to_remote` is now a P2WSH of:
`to_self_delay` OP_CSV OP_DROP <remotepubkey> OP_CHECKSIG
Cheers,
Rusty.
[1] I recently removed checking this field from c-lightning, as I
couldn't get it to reliably work under stress-test. I may just have
a bug, but we could just fix the spec instead, then we can get our
funds back even if we never talk to the peer.

2023-06-09 12:51:46 UTC

- reply

📅 Original date posted:2018-10-16
📝 Original message:
Olaoluwa Osuntokun <laolu32 at gmail.com> writes:
> Hi Rusty,
>
> Happy to get the splicing train rolling!
>
>> We've had increasing numbers of c-lightning users get upset they can't
>> open multiple channels, so I guess we're most motivated to allow splicing
> of
>> existing channels
>
> Splicing isn't a substitute for allowing multiple channels. Multiple
> channels allow nodes to:
>
> * create distinct channels with distinct acceptance policies.
> * create a mix of public and non-advertised channels with a node.
> * be able to send more than the (current) max HTLC amount
> using various flavors of AMP.
> * get past the (current) max channel size value
> * allow a link to carry more HTLCs (due to the current super low max HTLC
> values) given the additional HTLC pressure that
> AMP may produce (alternative is a commitment fan out)
These all seem marginal to me. I think if we start hitting max values,
we should discuss increasing them.
> Is there a fundamental reason that CL will never allow nodes to create
> multiple channels? It seems unnecessarily limiting.
Yeah, we have a daemon per peer. It's really simple with 1 daemon, 1
channel. My own fault: I was the one who insisted we mux multiple
connections over the same transport; if we'd gone for independent
connections our implementation would have been trivial.
>> Splice Negotiation:
>
> Any reason to now make the splicing_add_* messages allow one to add several
> inputs in a single message? Given "acceptable" constraints for how large the
> witness and pkScripts can be, we can easily enforce an upper limit on the
> number of inputs/outputs to add.
Mainly limitations of our descriptor language, TBH.
> I like that the intro messages have already been designed with the
> concurrent case in mind beyond a simpler propose/accept flow. However is
> there any reason why it doesn't also allow either side to fully re-negotiate
> _all_ the funding details? Splicing is a good opportunity to garbage collect
> the prior revocation state, and also free up obsolete space in watch towers.
I thought about restarting the revocation sequence, but it seems like
that only saves a tiny amount since we only store log(N) entries. We
can drop old HTLC info post-splice though, and (after some delay for
obscurity) tell watchtowers to drop old entries I think.
> Additionally, as the size of the channel is either expanding or contracting,
> both sides should be allowed to modify things like the CSV param, reserve,
> max accepted htlc's, max htlc size, etc. Many of these parameters like the
> CSV value should scale with the size of the channel, not allowing these
> parameters to be re-negotiated could result in odd scenarios like still
> maintain a 1 week CSV when the channel size has dipped from 1 BTC to 100k
> satoshis.
Yep, good idea! I missed that.
Brings up a side point about these values, which deserves its own
post...
>> 1. type: 40 (`splice_add_input`) (`option_splice`)
>
> In order to add nested p2sh inputs, we'll need to also expose the redeem
> script here, or add additional fields to allow sides to set a sig script as
> well as witness during the signing phase.
>
>> - scriptpubkey is empty, or of form 'HASH160 <20-byte-script-hash> EQUAL'
>
> So no P2SH? :(
Another omission, yeah, we'd want that too I think.
>> * [`4`:`feerate_per_kw`]
>
> What fee rate is this? IMO we should do commitmentv2 before splicing as then
> we can more or less do away with the initiator distinction and have most
> fees be ad hoc.
We're basically co-generating a tx here, just like shutdown, except it's
funding a new replacement channel. Do we want to CPFP this one too?
>> Splice Signing
>
> It seems that we're missing some fields here if we're to allow the splicing
> of inputs to be done in a non-blocking manner. We'll need to send two
> revocation points for the new commitment: one to allow it to be created, and
> another to allow updates to proceed right after the signing is completed. In
> this case we'll also need to update both commitments in tandem until the
> splicing transaction has been sufficiently confirmed.
I think we can use the existing revocation points for both.
> Also, what about change addresses? Are they to be explicitly specified as
> splice outs?
They'd be splice-outs, yeah.
>> 1. type: 43 (`splice_commitment_signature`) (`option_splice`)
>
> It may be worth pointing out there that we're able to transfer all existing
> HTLCs over to the new commitment as additional context.
Yeah, I think people missed that it was non-blocking like that.
>> 1. type: 45 (`splice_witness`) (`option_splice`)
>
> Should also allow either side to specify the sig script here if we're to
> allow nested p2sh (which we should IMO!).
Yep.
>> * [`2`:`len`]
>> * [`len`:`witnesses`]
>
> Is the extra length needed if all the witness elements themselves are length
> delimited?
Yes, we always length-delimit fields so we can add options later.
>
> It isn't clear in the current draft, but I take it that the splice_signature
> is for the old multi-sig?
Yes, that's the signature required to spend the old funding txout.
>> so we append to the existing `channel_update` for the original channel,
>> using a new `message_flags` field:
>
> IMO, we need to hold off on optional fields for now, until we revisit the
> formatting in order to actually get it right. As is now, all the optional
> fields are basically serial mandatory soft forks. So clients must understand
> the prior in order to understand the following fields. Instead, we
> essentially need more of a map design.
You need to add prior options to your wire parser, but that's usually
the most trivial part of handling them. And they may waste space on the
wire since we treat them as append-only, but OTOH it avoids
combinatorial testing explosion.
>> The post-splice reserve is 1% of post-splice capcacity (rounded down).
>
> This should be re-negotiated at time of splice creation, rather than a new
> hard coded value in the protocol.
>
>> In addition, you can forget everything about the old channel (including
>> old HTLCs and revocation requirements).
>
> We still have the same shachain state however (if we don't allow new state
> to be exchanged during the start of the splicing scenario), correct?
Yep.
Thanks,
Rusty.
> -- Laolu
>
> -- Laolu
PS, Damn, I always suspected there were multiple Roasbeefs, and we're simply
dealing with the output of an advanced multiplexing protocol. I present
the above as conclusive evidence of this thesis...

2023-06-09 12:51:43 UTC

- reply

📅 Original date posted:2018-10-12
📝 Original message:
ZmnSCPxj <ZmnSCPxj at protonmail.com> writes:
> Good morning Rusty,
>
> In BOLT #2 we currently impose a 2^24 satoshi limit on total channel capacity. Is splicing intended to allow violation of this limit? I do not see it mentioned in the proposal. Can I splice 21 million bitcoins on a 1-satoshi channel?
Good question! I think that's the kind of thing we should consider
carefully at the Summit.
> It may be good to start brainstorming possible failure modes during splice, and how to recover, and also to indicate the expected behavior in the proposal, as I believe these will be the points where splicing must be designed most precisely. What happens when a splice is ongoing and the communication gets disconnected? What happens when some channel failure occurs during splicing and we are forced to drop onchain? And so on.
Agreed, but we're now debating two fairly different methods for
splicing. Once we've decided on that, we can try to design the
proposals themselves.
Thanks,
Rusty.

2023-06-09 12:51:41 UTC

- reply

📅 Original date posted:2018-10-24
📝 Original message:
Conner Fromknecht <conner at lightning.engineering> writes:
> In light of this, and if I'm following along, it seems our hand is forced in
> splicing via a single on-chain transaction. In my book, this is preferable
> anyway. I'd much rather push complexity off-chain than having to do a
> mutli-stage splicing pipeline.
Agreed. As Christian pointed out, at least our design space is reduced now?
> I would propose sending a distinct message, which references the
> `active_channel_id` and a `splice_channel_id` for the pending splice:
>
> 1. type: XXX (`commitment_splice_signed`) (`option_splice`)
> 2. data:
> * [`32`:`active_channel_id`]
> * [`32`:`splice_channel_id`]
> * [`64`:`signature`]
> * [`2`:`num_htlcs`]
> * [`num_htlcs*64`:`htlc_signature`]
>
> This more directly addresses handling multiple pending splices, as well as
> preventing us from running into any size constraints. The purpose of
> including the `active_channel_id` would be to remote node locate the
> spliced channel, since it may not be populated indexes containing
> active channels. If we don't want to include this, the existing message
> can be used without modification.
Yes, I like this! I don't think the `splice_channel_id` helps us much,
since we need to wait we receive all pending commitement_splice_signed
before sending revoke_and_ack, and I think we should simply insist they
be in splice order which makes implementation easier (simple counter).
>> We shouldn't allow more than one pending splice operation anyway, as
>> stated in your proposal initially. We are already critically reliant on
> our
>> transaction being confirmed on-chain, so I don't see this as much of an
>> added issue.
>
> IMO there's no reason to limit ourselves to one pending splice at the
> message
> level. I think it'd be an oversight to not to plan ahead with RBF in mind,
> given that funding transactions have gone unconfirmed precisely because of
> improperly chosen fee rates. Arguably, funding flow should be extended to
> support this as well.
Good reminder re: RBF and funding. I've put this on the brainstorming
list with your name next to it ;)
> Adding a splice-reject message/error code should be sufficient to allow
> implementations to signal that their local tolerance for number of pending
> splices has been reached. It's likely we'd all start with getting one splice
> working, but then the messages won't need to modified if we want to
> implement
> additional pending splices via RBF.
>
> A node that wants to RBF but receives a reject can then proceed with CPFP
> as a
> last resort.
>
> Are there any downsides I'm overlooking with this approach?
No, I think you've covered it.
>> | Bit Position | Name | Field
> |
>> | ------------- | ------------------------- |
> -------------------------------- |
>> | 0 | `option_channel_htlc_max` | `htlc_maximum_msat`
> |
>> | 1 | `option_channel_moving` | `moving_txid
> |
>>
>> The `channel_update` gains the following field:
>> * [`32`: moving_txid`] (option_channel_moving)
>
> Do we actually need to send the `moving_txid` via a channel update? I think
> it's
> enough for both parties to send `channel_update`s with the
> `option_channel_moving` bit set, and continue to keep the channel in our
> routing
> table.
It helps because they can't broadcast the new channel for 6 confirms.
OTOH, that's probably not too long to wait.
> If we receive later receive two `channel_update`s whose `short_channel_id`s
> reference the spending transaction (and the node pubkeys are the same), we
> assume the splice was successful and that this channel has been
> subsumed.
So rule would be: if we've seen both channel_updates with
option_channel_moving set, we remember the txid which closed it, and
start a 100-block countdown the "real close". If we
a (valid) channel_announce for that closing tx with same node pubkeys,
we simply delete the 100-block countdown.
> I
> think this works so long as the spending transaction doesn't contain
> multiple
> funding outputs, though I think the current proposal is fallible to this as
> well.
I think variant above works even in that case?
> To me, this proposal has the benefit of not bloating gossip bandwidth with
> an
> extra field that would need to parsed indefinitely, and gracefully
> supporting
> RBF down the road. Otherwise we'd need to gossip and store each potential
> txid.
>
> With regards to forwarding, both `short_channel_id`s would be accepted by
> the
> splicers for up to 100 blocks (after splice confirm?), at which point they
> can
> both forget the prior `short_channel_id`.
Technically, the need to remember for some grace period after they
announce the block. We have a similar recommendation for old fee
values, though it's soft. 100 seems overkill.
I think we can assume gossip will propagate widely within 6 blocks and
say they should accept it at least up to 6 blocks after announcing? Or
1 hour, though I prefer using the blockchain as a clock in general.
> ## Shachain
>
>> I thought about restarting the revocation sequence, but it seems like
>> that only saves a tiny amount since we only store log(N) entries. We
>> can drop old HTLC info post-splice though, and (after some delay for
>> obscurity) tell watchtowers to drop old entries I think.
>
> I agree the additional state isn't too burdensome, and that we would still
> be
> able to drop watchtower state after some delay as you mentioned.
>
> On one hand, it does seem like the opportune time to remove such state if
> desired.
>
> OTOH, it is _really_ nice from an atomicity perspective that the current
> channel and (potentially) N pending channels can be revoked using a single
> commitment secret and message. Doing so would mean we don't have to
> modify the `revoke_and_ack` or `channel_reestablish` messages. The receiver
> would just apply the commitment secrets/points to the current channel and
> any
> pending splices.
Agreed; on balance, it's fine to avoid reset.
> ## Misc
>
>> Any reason to now make the splicing_add_* messages allow one to add
> several
>> inputs in a single message? Given "acceptable" constraints for how large
> the
>> witness and pkScripts can be, we can easily enforce an upper limit on the
>> number of inputs/outputs to add.
>
> Yes, I prefer this simplification.
Just harder to write the spec that way :) I'll come up with something.
>> Additionally, as the size of the channel is either expanding or
> contracting,
>> both sides should be allowed to modify things like the CSV param, reserve,
>> max accepted htlc's, max htlc size, etc. Many of these parameters like the
>> CSV value should scale with the size of the channel, not allowing these
>> parameters to be re-negotiated could result in odd scenarios like still
>> maintain a 1 week CSV when the channel size has dipped from 1 BTC to 100k
>> satoshis.
>
> Agreed!
"CSV should scale with value" seems like voodoo, though. It make us
feel better that we're being conservative with large amounts of money,
but it makes no sense from a time-value-of-money perspective. Sure,
bigger amounts are more important, but it's also more painful to have
them locked up.
I'd really like most of these parameters to go away, rather than
introducing YA negotiation pain point. See other post.
>> These all seem marginal to me. I think if we start hitting max values,
>> we should discuss increasing them.
>
> Doesn't this defeat the goal of firewalling funds against individual channel
> failures?
That's kind of true, but you should be more concerned about node
failure, and thus diversify your channels between different nodes.
That's better for everyone.
> Splice out,
> Conner
Nice touch :)
Cheers,
Rusty.

2023-06-09 12:51:39 UTC

- reply

📅 Original date posted:2018-10-16
📝 Original message:
Rusty Russell <rusty at rustcorp.com.au> writes:
> If we're going to do side splice-in like this, I would use a very
> different protocol: the reason for this protocol was to treat splice-in
> and splice-out the same, and inline splice-in requires wait time. Since
> splice-out doesn't, we don't need this at all.
>
> It would look much more like:
>
> 1. Prepare any output with script of specific form. eg:
> OP_DEPTH 3 OP_EQUAL OP_IF
> <funding_pubkey1> <funding_pubkey2> OP_CHECKMULTISIG
> OP_ELSE
> <blockheight> OP_CHECKLOCKTIMEVERIFY OP_DROP
> <myrescue_pubkey> OP_CHECKSIG
> OP_ENDIF
>
> 1. type: 40 (`splice_in`) (`option_splice`)
> 2. data:
> * [`32`:`channel_id`]
> * [`8`: `satoshis`]
> * [`32`: `txid`]
> * [`4`: `txoutnum`]
> * [`4`: `blockheight`]
> * [`33`: `myrescue_pubkey`]
>
> 1. type: 137 (`update_splice_in_accept`) (`option_splice`)
> data:
> * [`32`:`channel_id`]
> * [`32`: `txid`]
> * [`4`: `txoutnum`]
>
> 1. type: 138 (`update_splice_in_reject`) (`option_splice`)
> data:
> * [`32`:`channel_id`]
> * [`32`: `txid`]
> * [`2`:`len`]
> * [`len`:`errorstr`]
>
> The recipient of `splice_in` checks that it's happy with the
> `blockheight` (far enough in future). Once it sees the tx referred to
> buried to its own `minimum_depth`, it checks output is what they
> claimed, then sends `update_splice_in_accept`; it's followed up
> `commitment_signed` like normal, but from this point onwards, all
> commitment txs signatures have one extra sig.
Lisa started asking pointed questions, and so I noticed that parallel
splice doesn't work with Poon-Dryja channels.
The counterparty can spend the old funding txout with a revoked spend.
Sure, I can take all the money from that, but what about the spliced
input?
I came up with increasingly elaborate workarounds, but nothing stuck.
Back to Plan A...
Rusty.

2023-06-09 12:51:38 UTC

- reply

📅 Original date posted:2018-10-12
📝 Original message:
Christian Decker <decker.christian at gmail.com> writes:
> On Thu, Oct 11, 2018 at 3:40 AM Rusty Russell <rusty at rustcorp.com.au> wrote:
>
>> > * Once we have enough confirmations we merge the channels (either
>> > automatically or with the next channel update). A new commitment tx is
>> > being created which now spends each output of each of the two funding tx
>> > and assigns the channel balance to the channel partners accordingly to
>> the
>> > two independent channels. The old commitment txs are being invalidated.
>> > * The disadvantage is that while splicing is not completed and if the
>> > funder of the splicing tx is trying to publish an old commitment tx the
>> > node will only be punished by sending all the funds of the first funding
>> tx
>> > to the partner as the special commitment tx of the 2nd output has no
>> newer
>> > state yet.
>>
>> Yes, this is the alternative method; produce a parallel funding tx
>> (which only needs to support a single revocation, or could even be done
>> by a long timeout) and then join them when it reaches the agreed depth.
>>
>> It has some elegance; particularly because one side doesn't have to do
>> any validation or store anything until it's about to splice in. You get
>> asked for a key and signature, you produce a new one, and sign whatever
>> tx they want. They hand you back the tx and the key you used once it's
>> buried far enough, and you check the tx is indeed buried and the output
>> is the script you're expecting, then you flip the commitment tx.
>>
>> But I chose chose not to do this because every transaction commitment
>> forever will require 2 signatures, and doesn't allow us to forget old
>> revocation information.
>>
>> And it has some strange side-effects: onchain this looks like two
>> channels; do we gossip about both? We have to figure the limit on
>> splice-in to make sure the commitment tx stays under 400kSipa.
>>
>
> This is a lot closer to my original proposal for splicing, and I
> still like it a lot more since the transition from old to new
> channel is bascially atomic (not having to update state on both
> pre-splice and post-splice version). The new funds will remain
> unavailable for the same time, and since we allow only one
> concurrent splice in your proposal we don't even lose any
> additional time regarding the splice-outs.
>
> So pulling the splice_add_input and splice_add_output up to
> signal the intent of adding funds to a splice. Splice_all_added
> is then used to start moving the funds to a pre-allocated 2-of-2
> output where the funds can mature. Once the funds are
> matured (e.g., 6 confirmations) we can start the transition: both
> parties claim the funding output, and the pre-allocated funds, to
> create a new funding tx which is immediately broadcast, and we
> flip over to the new channel state. No need to keep parallel
> state and then disambiguating which one it was.
If we're going to do side splice-in like this, I would use a very
different protocol: the reason for this protocol was to treat splice-in
and splice-out the same, and inline splice-in requires wait time. Since
splice-out doesn't, we don't need this at all.
It would look much more like:
1. Prepare any output with script of specific form. eg:
OP_DEPTH 3 OP_EQUAL OP_IF
<funding_pubkey1> <funding_pubkey2> OP_CHECKMULTISIG
OP_ELSE
<blockheight> OP_CHECKLOCKTIMEVERIFY OP_DROP
<myrescue_pubkey> OP_CHECKSIG
OP_ENDIF
1. type: 40 (`splice_in`) (`option_splice`)
2. data:
* [`32`:`channel_id`]
* [`8`: `satoshis`]
* [`32`: `txid`]
* [`4`: `txoutnum`]
* [`4`: `blockheight`]
* [`33`: `myrescue_pubkey`]
1. type: 137 (`update_splice_in_accept`) (`option_splice`)
data:
* [`32`:`channel_id`]
* [`32`: `txid`]
* [`4`: `txoutnum`]
1. type: 138 (`update_splice_in_reject`) (`option_splice`)
data:
* [`32`:`channel_id`]
* [`32`: `txid`]
* [`2`:`len`]
* [`len`:`errorstr`]
The recipient of `splice_in` checks that it's happy with the
`blockheight` (far enough in future). Once it sees the tx referred to
buried to its own `minimum_depth`, it checks output is what they
claimed, then sends `update_splice_in_accept`; it's followed up
`commitment_signed` like normal, but from this point onwards, all
commitment txs signatures have one extra sig.
Similarly, splice-out:
1. type: 139 (`update_splice_out`) (`option_splice`)
* [`32`:`channel_id`]
* [`8`: `satoshis`]
* [`2`: `scriptlen`]
* [`scriptlen`: `outscript`]
The recipient checks that the output script is standard, and the amount
can be afforded by the other side. From then on, each commitment tx has
a new output.
Note this doesn't put the splice out on the blockchain!
1. type: 140 (`propose_reopen`) (`option_splice`)
* [`32`:`channel_id`]
* [`4`:`feerate_per_kw`]
* [`33`:`funding_pubkey`]
This is initiates a mutually-agreed broadcast of the current state: all
inputs (original and spliced), all spliced outputs, and a funding-style
2x2 which has all the remaining funds. Call this a 'reopen tx'.
This must be done with no outstanding commitments, like closing tx
negotiation, and it's a back-and-forth until both sides agree on
feerate. Then you send:
1. type: 141 (`reopen_accept`) (`option_splice`)
* [`32`:`channel_id`]
* [`4`:`feerate_per_kw`]
* [`64`: `new_commitment_sig`]
Once you've received and sent this, you're ready to sign the reopen tx:
1. type: 142 (`reopen`) (`option_splice`)
* [`32`:`channel_id`]
* [`64`: `reopen_commitment_sig`]
We need similar 'what happens on reconnect at various points' logic to
the previous one <handwave>.
Once you've sent and received the `reopen`, you can broadcast the reopen
tx at will and start updating again. If we recommend that public
channels reuse their old `funding_pubkey` then that means that we should
also have gossip continuity for upgraded nodes, and don't need the
previous channel_update hack.
We could add a new `reopen_locked` message which indicates that both
sides are happy with the reopen depth, if we don't want to allow reopens
back-to-back?
> This is one of the cases where a simpler solution (relatively
> speaking ^^) is to be preferred imho, allowing for future
> iterations.
Unless we can have both :)
Cheers,
Rusty.

2023-06-09 12:51:37 UTC

- reply

📅 Original date posted:2018-10-10
📝 Original message:
René Pickhardt <r.pickhardt at googlemail.com> writes:
> So let us take the example of Splicing in:
> * The situation before splicing is that we have one output in our funding
> tx that is being spent with each commitment tx. (actually if the channel
> was spliced before we have more inputs but that should not change anything)
> * Splice in would create one additional output that can be spent in future
> commitment tx.
> * I propose while splicing in this output should be spent by a special
> commitment tx which goes to the funder of the splicing operation. This
> should happen before the actual funding takes place. The other commitment
> tx spending the original output continues to operate (assuring non blocking
> splice in operation).
> * Once we have enough confirmations we merge the channels (either
> automatically or with the next channel update). A new commitment tx is
> being created which now spends each output of each of the two funding tx
> and assigns the channel balance to the channel partners accordingly to the
> two independent channels. The old commitment txs are being invalidated.
> * The disadvantage is that while splicing is not completed and if the
> funder of the splicing tx is trying to publish an old commitment tx the
> node will only be punished by sending all the funds of the first funding tx
> to the partner as the special commitment tx of the 2nd output has no newer
> state yet.
Yes, this is the alternative method; produce a parallel funding tx
(which only needs to support a single revocation, or could even be done
by a long timeout) and then join them when it reaches the agreed depth.
It has some elegance; particularly because one side doesn't have to do
any validation or store anything until it's about to splice in. You get
asked for a key and signature, you produce a new one, and sign whatever
tx they want. They hand you back the tx and the key you used once it's
buried far enough, and you check the tx is indeed buried and the output
is the script you're expecting, then you flip the commitment tx.
But I chose chose not to do this because every transaction commitment
forever will require 2 signatures, and doesn't allow us to forget old
revocation information.
And it has some strange side-effects: onchain this looks like two
channels; do we gossip about both? We have to figure the limit on
splice-in to make sure the commitment tx stays under 400kSipa.
> I believe splicing out is even safer:
> * One just creates a spent of the funding tx which has two outputs. One
> output goes to the recipient of the splice out operation and the second
> output acts as a new funding transaction for the newly spliced channel.
> Once signatures for the new commitment transaction are exchanged (basically
> following the protocol to open a channel) the splicing operation can be
> broadcasted.
>
> * The old channel MUST NOT be used anymore but the new channel can be
> operational right away without blockchain confirmation. In case someone
> tries to publish an old state of the old channel it will be a double spent
> of the splicing operation and in the worst case will be punished and the
> splicing was not successful.
>
> if one publishes an old state of the new
> channel everything will just work as normal even if the funding tx is not
> yet mined. It could only be replaced with an old state of the previous
> channel (which as we saw is not a larger risk than the usual operation of a
> lightning node)
Right, you're relying on CPFP pushing through the splice-out tx if it
gets stuck. This requires that we check carefully for standardness and
other constraints which might prevent this; for example, we can't allow
more than 20 (?) of these in a row without being sufficiently buried
since I think that's where CPFP calculations top out.
> As mentioned maybe you had this workflow already in your mind but I don't
> see why we need to send around all the messages twice with my workflow. We
> only need to maintain double state but only until it is fair / safe to do
> so. I would also believe that with my approach it should be possible (but
> not really necessary) to have multiple splicing operations in parallel.
The extra sigs are only needed in transition, though; once splicing is
over the channel looks exactly like a newly created one, which is nice.
> One other question: What happens to the short_channel_id of a channel to
> which founds have been spliced in?
In the parallel splice world, they look like two channels. In my
proposal it looks like a new channel, with a channel_update to make sure
modern nodes know that the transition is happening.
Cheers,
Rusty.

2023-06-09 12:51:35 UTC

- reply

📅 Original date posted:2018-10-10
📝 Original message:
Hi all!
We've had increasing numbers of c-lightning users get upset they
can't open multiple channels, so I guess we're most motivated to allow
splicing of existing channels. Hence this rough proposal.
For simplicity, I've chosen to only allow a single splice at a time.
It's still complex :(
Feedback welcome!
--
Splice Negotiation:
1. type: 40 (`splice_add_input`) (`option_splice`)
2. data:
* [`32`:`channel_id`]
* [`8`: `satoshis`]
* [`32`: `prevtxid`]
* [`4`: `prevtxoutnum`]
* [`2`: `scriptlen`]
* [`scriptlen`: `scriptpubkey`]
1. type: 41 (`splice_add_output`) (`option_splice`)
2. data:
* [`32`:`channel_id`]
* [`8`: `satoshis`]
* [`2`: `scriptlen`]
* [`scriptlen`: `outscript`]
1. type: 42 (`splice_all_added`) (`option_splice`)
2. data:
* [`32`:`channel_id`]
* [`4`:`feerate_per_kw`]
* [`4`:`minimum_depth`]
Each side sends 0 or more `splice_add_input` and 0 or more
`splice_add_output` followed by `spice_all_added` to complete the splice
proposal. This is done either to initiate a splice, or to respond to a
`splice_*` from the other party.
`splice_add_input` is checked for the following:
- must not be during a current splice
- scriptpubkey is empty, or of form 'HASH160 <20-byte-script-hash> EQUAL'
- `satoshis` doesn't wrap on addition.
- MAY check that it matches outpoint specified (sig will simply be
invalid if so), and that outpoint is segwit.
`splice_add_output` is checked for the following:
- must not be during a current splice
- `satoshis` is less than or equal to amount owing to proposer, minus
current reserve, and greater than or equal to `dust_limit_satoshis` we
sent in our open_channel/accept_channel ,sg.
- script is one of the approved forms as it is for `shutdown`.
FIXME: Do we disallow splice-out if they specified
option_upfront_shutdown_script?
`splice_all_added` is checked for the following:
- average of `feerate_per_kw` by both sides (round down) is sufficient.
- average of `feerate_per_kw` by both sides not grossly excessive, if we're
paying some of the fees (see below!)
- both sides can afford the fees from their post-splice funds (see
Verification Changes below)
- maximum of the two `minimum_depth` is not grossly excessive.
- There is at least one splice_add_input or splice_add_output.
Splice negotiation, like closing negotiation, does not have persistent
state. Reconnecting forgets previous negotiation.
Splice Signing
--------------
Once `splice_all_added` is both sent and received, we need to create and
sign both the splice tx itself, and the first commitment transaction
which spends it (but not in that order!).
1. One input spends the current funding tx output.
2. There is one additional input for each splice_add_input.
3. One output creates the new funding tx.
4. There is one additional output for each splice_add_output.
5. The entire transaction is sorted into BIP69 order.
6. The feerate is the sum of the two `feerate_per_kw` divided by 2,
rounded down.
1. type: 43 (`splice_commitment_signature`) (`option_splice`)
2. data:
* [`32`:`channel_id`]
* [`64`:`commitment_signature`]
* [`2`:`num_htlcs`]
* [`num_htlcs*64`:`htlc_signature`]
1. type: 44 (`splice_signature`) (`option_splice`)
2. data:
* [`32`:`channel_id`]
* [`64`:`splice_signature`]
1. type: 45 (`splice_witness`) (`option_splice`)
2. data:
* [`32`:`channel_id`]
* [`2`: `num_witness_elements`
* [`2`:`len`]
* [`len`:`witnesses`]
`witnesses` itself is serialized as `num_witness_elements` of:
* `2`:`len`
* `len`: `witness_element`
Each side sends `splice_commitment_signature` and waits to receive and
verify the other side's `splice_commitment_signature` before sending
`splice_signature` and `splice_witness` for each `splice_add_input` it
proposed, in BIP69 input order.
Once a node has sent `splice_commitment_signature` it should remember
the splice proposal across reconnects. Once it has both sent
`splice_signature`, the splice is locked in.
Splice Announcement
-------------------
We have to tell the network about the new channel, otherwise there will
be a distruption when it sees the old funding transaction spent. This
is inevitable for older nodes who won't understand splicing anyway.
We can't send out a `channel_announcement` or `channel_update` for the
new channel until after the new funding transaction has 6 confirmations,
so we append to the existing `channel_update` for the original channel,
using a new `message_flags` field:
| Bit Position | Name | Field |
| ------------- | ------------------------- | -------------------------------- |
| 0 | `option_channel_htlc_max` | `htlc_maximum_msat` |
| 1 | `option_channel_moving` | `moving_txid |
The `channel_update` gains the following field:
* [`32`: moving_txid`] (option_channel_moving)
If a current `channel_update` for a closing channel contains
`option_channel_moving` a node SHOULD ignore the channel close for at
least 100 blocks iff spent by `moving_txid`.
A node SHOULD immediately forward a `channel_update` it sees containing
`option_channel_moving` if neither previous `channel_update` for the
channel contains `option_channel_moving`.
Each side of the splice can send these unilaterally, and SHOULD allow a
few minutes for propagation (remember, average propagation from old
nodes is still 30 seconds) prior to broadcast of the splice transaction.
Message Changes During Splicing
-------------------------------
Once you've sent `splice_commitment_signature` each commitment
transaction is duplicated: one spends the old funding transaction, one
spends the splice transaction:
1. type: 39 (`closing_signed`)
2. data:
* [`32`:`channel_id`]
* [`8`:`fee_satoshis`]
* [`64`:`signature`]
* [`64`:`splice_signature`] (`option_splice`)
1. type: 132 (`commitment_signed`)
2. data:
* [`32`:`channel_id`]
* [`64`:`signature`]
* [`2`:`num_htlcs`]
* [`num_htlcs*64`:`htlc_signature`]
* [`num_htlcs*64`:`htlc_splice_signature`] (`option_splice`)
If a reconnection occurs between between sending and receiving
`splice_commitment_signature`) the peer's status is uncertain (similarly
for closing). This we have a new field in `channel_reestablish` to flag
that we consider ourselves to be splicing:
1. type: 136 (`channel_reestablish`)
2. data:
* [`32`:`channel_id`]
* [`8`:`next_local_commitment_number`]
* [`8`:`next_remote_revocation_number`]
* [`32`:`your_last_per_commitment_secret`] (`option_data_loss_protect`)
* [`33`:`my_current_per_commitment_point`] (`option_data_loss_protect`)
* [`32`:`splice_txid`] (`option_splice`)
The splice_txid field indicates that this side considers itself to be
splicing.
The sender:
- if it has sent `splice_commitment_signature` and not sent the corresponding
`splice_closed`, MUST set `splice_txid` to the txid of the splice tx.
- Otherwise MUST NOT.
The recipient:
- if it has sent `splice_commitment_signature` and not sent the corresponding
`splice_closed`:
- if `splice_txid` does not exist or does not match the current splice:
- SHOULD fail the channel
- otherwise:
- MUST retransmit `splice_signature`
- otherwise:
- if `splice_txid` field exists and is not all zeroes:
- MUST send `splice_closed`
Validation Changes During Splicing
----------------------------------
We track "post-splice" values as well as current values during
splicing.
The post-splice reserve is 1% of post-splice capcacity (rounded down).
The fees for the splicing transaction itself are divided into parts by
the number of `splice_add_input` plus `splice_add_output`, rounded up.
Each side pays as many parts as it proposed `splice_add_input` plus
`splice_add_output`.
(So if Alice proposes two and Bob proposes one, and the total fee is 1000
satoshi, each part is 334 satoshi: Alice pays 668 and Bob pays 334.)
Each side's post-splice funds are debited their `splice_add_output`
amounts, and credited their `splice_add_input` amounts, a debited the
splice tx fees. If any debiting occurs, the funds must be above the
post-splice reserve (ie. you can have below reserve, but you can't spend
if you're below reserve).
All update_add_htlc must be valid for the *both* the current and
post-splice balances.
Completing Splicing
-------------------
Once you've seen both side's `minimum_depth` confirmations of the splice
transaction (ie. the maximum of the two `minimum_depth` values), you can
complete the splice by sending:
1. type: 46 (`splice_closed`) (`option_splice`)
2. data:
* [`32`:`channel_id`]
Once you've sent and received `splice_closed` you can send
`announcement_signatures` for the new channel as per normal rules (ie. 6
confirmations, `announce_channel` bit set).
In addition, you can forget everything about the old channel (including
old HTLCs and revocation requirements).

2023-06-09 12:51:33 UTC

- reply

📅 Original date posted:2018-10-09
📝 Original message:
Pierre <pm+lists at acinq.fr> writes:
>> But there's no reason to believe that the invoicer has more knowledge about all but the last hop.
>
> I disagree: there is a good chance that the receiver is a 24/7 running
> merchant/website, with a full up-to-date view of the network, whereas
> the payer is most likely a mobile wallet with less
> accurate/partial/out of date information.
>
> At least this is what we are seeing on the current mainnet. Routing
> table sync is hard on mobile clients, and I think that it makes sense
> that receivers "help" senders, after all incentives are aligned.
Good qualification; I agree. Certainly if the payer knows its
information is less reliable it should prefer the provided route.
Cheers,
Rusty.

2023-06-09 12:51:33 UTC

- reply

📅 Original date posted:2018-10-08
📝 Original message:
Matt Corallo <lf-lists at mattcorallo.com> writes:
> On a related note, it would be nice to get some clarity on appropriate
> usage of the r= field here.
> The way I had implemented it initially was that if an invoice had an r=
> field any publicly-discovered last-hop routes would be ignored as the r=
> data is most likely more up-to-date than any public route rumor information.
> However, if it's only used as a hint and only one or two out of
> potentially many channels are included in it, that may make little sense.
There were originally two proposed uses of r=:
1. For payments via unannounced channels.
2. For routing hints for nodes which don't have a complete topology.
> Not really sure what the appropriate guidance should be, probably
> something like SHOULD prefer to use invoice-r=-provided-hints over
> publicly-discovered routes however MAY use other last-hops in case a
> substantially better route is known?
Note that r can provide zero-or-more full routes, not just a single hop
as is done here. But there's no reason to believe that the invoicer has
more knowledge about all but the last hop.
So, I'd recommend that the payer SHOULD prefer to use the final hops
specified in `r` fields over other equivalent routes it knows.
(Note the weasel word "equivalent" here: you might bias against these
due to fees, timeouts, or even privacy concerns. Also note that I
haven't implemented this yet!).
Cheers,
Rusty.

2023-06-09 12:50:36 UTC

- reply

📅 Original date posted:2018-05-09
📝 Original message:
Anthony Towns via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> writes:
> On Mon, May 07, 2018 at 09:40:46PM +0200, Christian Decker via bitcoin-dev wrote:
>> Given the general enthusiasm, and lack of major criticism, for the
>> `SIGHASH_NOINPUT` proposal, [...]
>
> So first, I'm not sure if I'm actually criticising or playing devil's
> advocate here, but either way I think criticism always helps produce
> the best proposal, so....
>
> The big concern I have with _NOINPUT is that it has a huge failure
> case: if you use the same key for multiple inputs and sign one of them
> with _NOINPUT, you've spent all of them. The current proposal kind-of
> limits the potential damage by still committing to the prevout amount,
> but it still seems a big risk for all the people that reuse addresses,
> which seems to be just about everyone.
If I can convince you to sign with SIGHASH_NONE, it's already a problem
today.
> I wonder if it wouldn't be ... I'm not sure better is the right word,
> but perhaps "more realistic" to have _NOINPUT be a flag to a signature
> for a hypothetical "OP_CHECK_SIG_FOR_SINGLE_USE_KEY" opcode instead,
> so that it's fundamentally not possible to trick someone who regularly
> reuses keys to sign something for one input that accidently authorises
> spends of other inputs as well.
That was also suggested by Mark Friedenbach, but I think we'll end up
with more "magic key" a-la Schnorr/taproot/graftroot and less script in
future.
That means we'd actually want a different Segwit version for
"NOINPUT-can-be-used", which seems super ugly.
> Maybe a different opcode maybe makes sense at a "philosophical" level:
> normal signatures are signing a spend of a particular "coin" (in the
> UTXO sense), while _NOINPUT signatures are in some sense signing a spend
> of an entire "wallet" (all the coins spendable by a particular key, or
> more accurately for the current proposal, all the coins of a particular
> value spendable by a particular key). Those are different intentions,
> so maybe it's reasonable to encode them in different addresses, which
> in turn could be done by having a new opcode for _NOINPUT.
In a world where SIGHASH_NONE didn't exist, this might be an argument :)
Cheers,
Rusty.

2023-06-09 12:50:29 UTC

- reply

📅 Original date posted:2018-05-18
📝 Original message:
ZmnSCPxj <ZmnSCPxj at protonmail.com> writes:
>>> Please describe the below:
>>>
>>> 1. Behavior if payment succeeds after T time.
>>> 2. Behavior if payment fails after T time.
>>>
>>> It seems you only described "Behavior if payment succeeds after T time".
>>
>> Ah, sorry if I didn't make that clear. The reputation is increased in the case of successful payments by the fee collected. The reputation is decreased on the downstream peer proportional to time T regardless of whether the payment succeeds or fails. If a payment succeeds quickly, the increase should outweigh the decrease, but if the payment succeeds after a long time, the change in reputation may be net negative. If the payment fails, the upstream peer's reputation does not change and the downstream peer's reputation always decreases proportional to time T.
>
> Thank you. So:
>
> 1. If payment succeeds after T time, upstream reputation is increased by fee earned, downstream reputation is increased by fee earned, downstream reputation is decreased by T * reputation_loss_rate.
> 2. If payment fails after T time, downstream reputation is decreased by T * reputation_loss_rate.
So, to be clear, there's no *financial* fee on failure, just reputation
fee?
Also, you talked about reputation_loss_rate as being a private per-node
thing, and being an explicit thing in the HTLC. I'm ignoring the
former, and assuming the latter.
OK, let's consider a 1000 satoshi HTLC, paying a 10ppm fee and with a
1ppm-per-second reputation_loss_rate.
If it succeeds in 1 second (measuring reputation in millisatoshi,
because its cute):
reputation[source] += 10
reputation[destination] += 10 - 1
If it succeeds in 10 seconds:
reputation[source] += 10
reputation[destination] += 10 - 10
If it fails in 10 seconds:
reputation[destination] -= 10
And if it falls onto the chain and fails after 144 blocks:
reputation[destination] -= 86400
In this scheme, it seems that I can destroy N reputation points in 18
nodes for cost N:
Mallory1 -> Node1 -> Node2 -> ..... -> Node18 -> Mallory2
\
Mallory3
Mallory2 pays a crapload of fees to Node18 to pay Mallory3, getting a
great reputation. Then Mallory1 sends a payment to Mallory2, which
takes a day to resolve.
Of course, this is why you want ramped reputation_loss_rate, say 1ppm
for Mallory1->Node1, 2ppm ->Node2.... 19ppm for Mallory2. That just
means Mallory can destroy 9*N total reputation points, not 18*N.
You can fix this by making it reputation_loss_rate exponential, but I
don't think Node1 could ever get the 262144x reputation to make the
payment in the first place.
What am I missing?
Thanks,
Rusty.

2023-06-09 12:50:27 UTC

- reply

📅 Original date posted:2018-05-14
📝 Original message:
Jim Posen <jim.posen at gmail.com> writes:
> Thanks for the thoughtful responses.
>
>> You missed the vital detail: that you must prove channel closure if you
>> can't unpeel the onion further. That *will* hit an unresponsive party
>> with a penalty.
>
> Ah, that is a good point. I still find the proposal overall worryingly
> complex in terms of communication overhead, time it takes to prove channel
> closure, all of your points in [1], [2], [3], etc. Furthermore, this
> mandates that immediate channel closure is the only allowed reaction to a
> party delaying an HTLC for a time period above a threshold -- the node
> reputation approach gives more discretion to the preceding hop.
> Deobfuscating the route may turn out to be the right option, but I think
> the reputation system has certain advantages over this.
Agreed, it's a tradeoff.
>> The models we tried in Milan all created an incentive to fail payments,
>> which is a non-starter.
>
> Do you mind elaborating or summarizing the reasons? The way I'm analyzing
> it, even if there's a nominal spam fee paid to routing nodes that fail
> payments, as long as it's low enough (say 2-5% for arguments sake), the
> nodes still have more to gain by forwarding the payment and earning the
> full fee on a completed payment, and possibly the reputation boost
> associated with completing a payment if that system was in effect.
You're forgetting the failure cases, where now I can profit.
If I disconnect from another node, I now have a disincentive to tell
others. At the moment we send an update disabling the channel (though
we should give a few seconds for reconnect first, but whatever).
Similarly, the rewards aren't proportional: being cheaper than other
routes gets you all the traffic, but now you profit even if you can't
service the payments. In fact, once a channel becomes hard to use (low
capacity, transient disconnect, whatever), I *should* advertize it as
cheaper route than anyone else: free money!
I'm sure there are other ways to game it, but the underlying reason is
clear: it misaligns user and node incentives.
> Moreover, a node that constantly fails payments will be blacklisted by the
> sender eventually and stop receiving HTLCs from them at all. Overall, I
> don't think this is a profitable strategy. Furthermore, I think it works
> quite well in combination with the reputation system.
If the system is sufficiently decentralized, managing to cheat everyone
once is very profitable though.
>> This seems like we'd need some serious evaluation to show that this
>> works, because the risks are very high.
>
> I agree that it needs to be evaluated. I may start working on some network
> simulations to test various DOS mitigation strategies.
>
>> I can destroy your node's reputation by routing crap through you; even
>> if it costs me marginaly more reputation than it does you, that just
>> means that the largest players can force failure upon smaller players,
>> centralizing the network. And I think trying to ensure that it costs me
>> more reputation than the sum of downstream reputation loss leaks too
>> much information
>
> I will add to ZmnSCPxj's response, which is mostly on point. The key here
> is that the only way to lose significant reputation is to delay a payment
> yourself or forward to a malicious downstream that delays -- neither of
> these can be forced by the sender alone. This amounts to a system where you
> are on the hook for any malicious behavior of your downstream peers, which
> is why you must keep a reputation score for each which they earn over time.
> This should keep all links in the network high quality and quickly
> disconnect off delaying nodes if the incentives are right.
But I can make you look like a delaying node whenever I want. The only
way to ensure that I lose more reputation than you do is to leak
information about route length for *everyone*. And even then, it's just
a matter of numbers. I can make successful payments to myself through
the same peers (but not you!) to stay above their threshold so my
reputation is intact.
So it's basically a question of how expensive is it for me to throw you
off the network? You have to tune that number carefully.
> While I agree that a lot of reputation is leaked by aggregating the losses
> along the route, this serves exactly to prevent large nodes with high
> reputation from ruining links elsewhere. There are two things a node
> looking to cause reputation loss could do. 1) Identify a node (not itself)
> it thinks will delay a payment and send to them. This locks up funds on
> their behalf, but is actually good behavior because it identifies a faulty
> node and rightfully forces a loss in their reputation, eventually resulting
> in them being booted from the network. Everyone upstream loses some
> reputation for having connectivity to them, but less because of the loss
> aggregation along the route. 2) Delay a payment oneself and force upstream
> reputation loss. This is why I think it's important that the reputation
> loss aggregate so that the malicious party loses the most.
But we're busy trying to remove all the methods of deanonymizing the
network, and you seem to be adding a new one, *and* providing an
incentive to deanonymize.
> As for the amount of information leaked, yes, it helps determine the number
> of upstream hops in a route. However, the CLTV values help determine the
> number of downstream hops in a route in exactly the same way. I see these
> as symmetric in a sense.
Yes, which is why we have mitigations in place (which are still probably
insufficient). I really don't want to add another vector.
> This is exactly the question that your local view of peer reputations helps
> solve: are the potential fees here worth the risk of forwarding this
> payment to this downstream?
So now I'll try to deanonymize all payments so I can determine this.
Those who do this best will be rewarded, and those who don't try will be
knocked off the network, probably by those who can!
So I'd like to see a real design of the reputation system. If it's
practical (which is a significant hurdle), we then need to carefully
evaluate whether we're creating significant disincentives to
neighbourliness.
Cheers,
Rusty.

2023-06-09 12:50:24 UTC

- reply

📅 Original date posted:2018-05-09
📝 Original message:
Jim Posen <jim.posen at gmail.com> writes:
> There are two directions of solutions I have heard: 1) protocol support for
> decrypting the onion route if the HTLC is kept in-flight for too long 2)
> requiring fees even if the payment fails as a cost to the attacker 3) some
> sort of reputation system for nodes.
>
> Option 1 I'm afraid may be quite complex. Say this mechanism kicks in and
> all nodes in the circuit deobfuscate the route and are able to see the
> delays at each hop. The outcome we hope for is that there is one node
> clearly to blame and the prior hop in the route fails all channels with
> them. However, the attacker can of course control multiple successive hops
> in the route, one that looks innocent in front of one that looks guilty,
> then keep the channel alive and try again. So then all nodes need to keep a
> record of the full circuits and iteratively shift blame up the chain if bad
> HTLCs keep going through those channels.
You missed the vital detail: that you must prove channel closure if you
can't unpeel the onion further. That *will* hit an unresponsive party
with a penalty.[1]
> Option 2 is also problematic because it only protects against the case
> where the sender is colluding with the receiver, and not where a routing
> node is opportunistically delaying payments. This would, however, likely be
> successful against nodes being annoying and sending tons of payments with
> randomly generated payment hashes in order to "ping" a circuit.
The models we tried in Milan all created an incentive to fail payments,
which is a non-starter.
> Option 3 has become my preferred solution. The idea is that that for each
> node that one has channels with, it only forwards payments through them if
> they have a good history, otherwise it fails the payment. Notably, we
> ignore whether the downstream hop is directly responsible for delaying a
> payment or whether they are simply willing to forward to another node that
> is intentionally delaying -- both should be considered bad behavior. In my
> opinion, this type of solution fits best into the Lightning model of
> independent, linked channels where each node has private contracts with its
> direct peers. It also is the simplest in the context of onion routing
> because if you are offered an HTLC to route, the only decision you can make
> is whether to forward it or fail it based on the amount, previous hop, and
> next hop. When I refer to "reputation" hereafter, I do not mean a global
> reputation that is gossiped about -- just a local view of a peer's history.
This seems like we'd need some serious evaluation to show that this
works, because the risks are very high.
I can destroy your node's reputation by routing crap through you; even
if it costs me marginaly more reputation than it does you, that just
means that the largest players can force failure upon smaller players,
centralizing the network. And I think trying to ensure that it costs me
more reputation than the sum of downstream reputation loss leaks too
much information
If the system doesn't work perfectly, it creates incentive to
de-anonymize payments so you can determine which are likely to fail, and
also means nodes are safest not forwarding payments, lest they ruin
their reputatation. But nodes which don't forward have much less
privacy.
But I agree, all solutions I've seen to this problem are bad in
different ways.
Cheers,
Rusty.
[1] Proving that you've committed to a particular HTLC in a channel is
difficult, because of dust HTLCs[2] and partially-committed ones[3].
[2] We could have an OP_RETURN output which was a merkle tree of trimmed
HTLCs to cover the dust case.
[3] You committed to an HTLC but the peer didn't respond; you have no
proof. So you also need to present a merkle tree of uncommitted
HTLCs (limited, say, to 16) otherwise you can create 1M HTLCs, then
claim they were all in that one channel close.

2023-06-09 12:49:01 UTC

- reply

📅 Original date posted:2018-02-07
📝 Original message:
Olaoluwa Osuntokun <laolu32 at gmail.com> writes:
> Protocol Overview
> ==================
> This design can be seen as a generalization of the single, non-interactive
> payment scheme, that uses decoding of extra onion blobs (EOBs?) to encode
> extra data for the receiver. In that design, the extra data includes a
> payment preimage that the receiver can use to settle back the payment. EOBs
> and some method of parsing them are really the only requirement for this
> protocol to work. Thus, only the sender and receiver need to implement this
> feature in order for it to function, which can be announced using a feature
> bit.
OK, so this proposal conflates two things:
1. split payments.
2. expansion of onion space.
We've got a wiki page for #2 which could probably use some love:
https://github.com/lightningnetwork/lightning-rfc/wiki/Brainstorming#using-multiple-hops_data-cells-in-the-onion
For the final hop this may not be necessary, as we have 8 unused bytes
in `next addr`, giving us 20 free bytes.
But why not simplify the proposal: the payment preimage is the XOR of
those 20 bytes (with 12 zero bytes prepended)? And the receiver gives
up to 30 seconds(?) to receive all the parts after the first one.
That means the sender gets dynamic resizing (if they want to split a
payment further, set one to randomness, and XOR that into the other),
the receive has only to remember the combination-so-far.
Cheers,
Rusty.

2023-06-09 12:49:00 UTC

- reply

📅 Original date posted:2018-02-07
📝 Original message:
Olaoluwa Osuntokun <laolu32 at gmail.com> writes:
> Hi Y'all,
>
> A common question I've seen concerning Lightning is: "I have five $2
> channels, is it possible for me to *atomically* send $6 to fulfill a
> payment?". The answer to this question is "yes", provided that the receiver
This is awesome! I'm kicking myself for not proposing it :)
Unfortunately, your proposal defines a way to make multipath donations,
not multipath payments :(
In other words, you've lost proof of payment, which IMHO is critical.
Fortunately, this can be fairly trivially fixed when we go to scriptless
scripts or other equivalent decorrelation mechanism, when I think this
mechanism becomes extremely powerful.
> - Potential fee savings for larger payments, contingent on there being a
> super-linear component to routed fees. It's possible that with
> modifications to the fee schedule, it's actually *cheaper* to send
> payments over multiple flows rather than one giant flow.
This is a stretch. I'd stick with the increased reliability/privacy
arguments which are overwhelmingly compelling IMHO.
If I have any important feedback on deeper reading (and after a sccond
coffee), I'll send a separate email.
Thanks!
Rusty.

2023-06-09 12:48:07 UTC

- reply

📅 Original date posted:2017-12-18
📝 Original message:
Andy Schroder <info at AndySchroder.com> writes:
> What's the rational for using millisatoshis as the units for lightning
> channels? Aren't you going to loose up to 1/2 of a satoshi when the
> channel is closed?
You can lose up to 0.999 satoshi per in-progress payment, yes. BOLT #3:
The amounts for each output MUST be rounded down to whole satoshis.
> Is this because it doesn't hurt and you might as well
> be open to the opportunity for these sub satoshi transactions, because
> if you aren't, you are giving up the opportunity to get accumulated
> revenue from many of those small transactions, that could end up being
> greater than 1/2 of a satoshi?
In practice, payments of less than a few thousand satoshi are
impractical, as they cost more than that to spend. Channel closing
costs dwarf the gains to be made from cheating, however.
> Since millisatoshis is used, is there a maximum channel funding size?
Yes, the upper 32 bits must be zero, from BOLT #2:
- for channels with `chain_hash` identifying the Bitcoin blockchain:
- MUST set the four most significant bytes of `amount_msat` to 0.
This gives a maximum HTLC value of .04294967295 BTC, which, back when
we started, was about $10.
> Is the optional initial push of millisatoshis during the channel
> creation there in order to motivate the other party to be willing to
> waste their time with the channel creation in the first place? If not,
> what's it for?
It's for the common case where you want to connect to someone and
make a payment immediately. I'm not sure how widely it will be used,
though. It's also the only mechanism for the payer to have *zero* funds
in channel (ie. below reserve).
> In all of the clients that I've looked at, I can't seem to find out how
> to define the timeout closing out a channel when someone does not
> cooperate. Is there a fixed value for this as part of the protocol? Or
> do most clients have a default that they enforce over all channels that
> they create?
If there's no in-progress payment, there's no reason to close a channel
to an unreachable peer, unless you want to abandon the channel and get
the funds back.
If there is, BOLT #2 has you covered:
https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#requirements-8
Hope that helps,
Rusty.

2023-06-09 12:46:38 UTC

- reply

📅 Original date posted:2016-08-12
📝 Original message:
Joseph Poon <joseph at lightning.network> writes:
> On Wed, Aug 10, 2016 at 11:33:46AM +0930, Rusty Russell wrote:
>> Unfortunately, watcher knows revocation preimage N, so it can figure out
>> some or all previous revocation preimages (and thus hashes).
>
> If you take the results then HMAC it as the final step in
> shachain/elkrem (to establish a single leaf), should be fine even if
> revocation hashes are used in lieu of a revocation pubkey.
Sure, or just SHA the leaf again. But such schemes prevent the watcher
from using the elkrem/shachain space-savings themselves, which is kind
of painful. (Though see below...)
Let's look at space & comms requirements, per new commitment tx, for
different schemes. Let's say we have N htlcs in the current HTLC.
Bytes Bytes
Communicated Stored (per tx)
Naive (whole steal tx) ~300 * (N+1) ~300 * (N+1)
rhash+sig+HTLCdata 32 + 32 + 24*N 32 + 32 + 24*N
+shachain/elkrem 32 + 32 + 24*N 32 + 24*N
+SIG_NOINPUT 32 + 24*N 24*N
+Dual-scriptpubkey MAST 32 0
The ultimate is shachain/elkrem, SIG_NOINPUT and a MAST scheme which
places two scripthashes into the scriptpubkey, either of which would
allow spending. In that case, we'd simply send a series of SIG_NOINPUT
signed steal txs with 1, 2, 3 ... inputs at the beginning, and then send
each new revocation preimage as we learned it. The storage overhead is
basically constant (technically, log(N) for the shachain).
Interestingly, MAST by itself buys us nothing (bytewise): the 32 bytes
we'd need to send for the other branch of MAST is larger than the 24
bytes for the HTLC description.
Revealing the preimages seems a win, BUT if we give them unencrypted to
the watcher we need some other way of avoiding guessable prior
commitment txs. Which implies we change at least one key in some way,
which means we need to send that key to the watcher to store, which
costs as much as they save using shachain/elkrem!
The other win is sharing HTLCs across transactions somehow (which
reduces N to the "number of new HTLCs" instead of "number of HTLCs").
I can't come up with anything very good here, though :(
>> But it rests on the assumption that there are no unknown malleability
>> issues on signatures, which I believe makes crypto people nervous. I've
>> asked some, though, as that's above my pay grade!
>>
>> It also assumes they can't set up the witness such that our sig is not
>> 2nd or 3rd in the witness element. I think that's true...
>
> Yeah, good point. Perhaps it could be better to keep it simple and just
> use an HMAC of the non-witness transaction. There shouldn't be stuff
> that's easily mutatable, and the exposure is not expanded (since that
> would break LN's child transactions anyway).
I still don't understand why use an HMAC-of-tx instead of just the txid?
What does it gain?
Thanks!
Rusty.

2023-06-09 12:46:35 UTC

- reply

📅 Original date posted:2016-08-10
📝 Original message:
Tadge Dryja <tadge at lightning.network> writes:
> The method of using a revocation key is compatible with shachain/elkrem so
> has log(n) storage; I'll describe what I developed which omits hashing in
> the commit script and uses only signature verification. If Laolu has made
> a different key revocation scheme I'm not aware, but please do post if so.
Oh, I blamed Laolu because he told me about it; sorry for misattribution.
> The script is:
>
> DUP
> [Revocable Pubkey]
> CHECKSIG
> NOTIF
> [Timeout Pubkey]
> CHECKSIGVERIFY
> [timeout period]
> CHECKSEQUENCEVERIFY
> ENDIF
OK, so far so good.
> To build the revocable pubkey, Alice takes their elkrem sender hash from
> state n, which we'll call EHn. Alice multiples EHn * G, getting a point
> EPn. (Elkrem point n) Alice sends EPn to Bob, who adds their commitment
> pubkey (BP, which is never seen raw) to EPn.
"never seen raw on-chain" I assume, since Bob will send it to Alice in
setup?
> The result, (RPub n = BP + EPn), is the revocable pubkey for state n.
> At state n+1, Alice sends Bob EHn. Bob can then compute the private
> key for Rpub n, as it's just their commitment private key plus EHn,
> modulo the order of the curve.
So, AFACIT this scheme gives us a slightly smaller script and makes
previous commit transactions underivable.
The property I was *hoping* for was the ability for Alice (and Bob) to
independently predict each others' future revocation hashes/pubkeys.
That would neatly allow an arbitrary number of commitment transactions
in flight each way at once. Naively, seems like that should be
possible.
> A similar procedure is used for the timeout key; Alice adds a point to
> their own timeout key, which seems kindof pointless because they know both
> scalars. It obscures the commitment script by making both pubkeys
> different each state, as they're all generated from the hash tree. Bob
> only needs to keep track of the most recent "elkrem points" and the hash
> tree itself.
I think changing the timeout key is harmless, but gratuitous; changing
the revocation key is sufficient for each commitment script unguessably
different from the last one, no?
> Hope this is clear and sorry if I'm describing something completely
> different than what you're asking about!
It's all good; this is a big space and sometimes I don't even know what
I don't know...
Thanks!
Rusty.

2023-06-09 12:46:35 UTC

- reply

📅 Original date posted:2016-08-10
📝 Original message:
Tadge Dryja <tadge at lightning.network> writes:
>>
>> 4. When the watcher receives a new block, they HMAC(txid+salt1) all
>> transactions and compare against the key-value store
>>
>> This method does not require significant computation upon receiving a
>> new block and checking against the datastore. I forgot to note, that the
>
> If you're only watching 1 channel, this is OK as you're just doing one HMAC
> operation per incoming tx. This works when the number of states per
> channel is high but the number of channels watched is low.
> If you're watching 1M channels with 1K states each, this requires 1M HMAC
> operations for every incoming tx.
>
> By giving the whole (or a truncated part) of the txid, the observing node
> can put all txids being watched for into the same tree and have seek access
> time independent of the number of separate channels being watched. Whether
> it's 1 channel with 1 billion states, or 100M channels with 10 states each,
> you have the same cpu and I/O cost per incoming tx.
Yes, I think I agree.
> I'm not clear on the advantages of sending encrypted state information to
> the observer. Most information the observer needs to construct a punishing
> transaction is available in the observed commitment tx; the only per-state
> information which needs to be stored is the signature (and in the case of
> HTLCs, the preimage).
Yes. To be precise, watcher needs preimage, pubkeys, a signature,
OP_CSV delay amounts for each side, and HTLCs.
If the pubkeys and OP_CSV delay amounts are fixed, you need a signature
and preimage (required to steal the to-them output as well as htlcs)
every new commit tx (ie. every new watch request). And you'll add a new
HTLC information on average every second commit tx.
But I think you're better attaching every relevant HTLC to every watch
request; otherwise, you're exposing all previous HTLCs. I recalculated:
they're only 24 bytes each (ripemd hash + expiry).
If we really want to optimize that,maybe we can come up with a cleverer
scheme, where you optionally include the key to the previous watch
request with the encrypted information, allowing the sender to control
the privacy/data tradeoff? Then the watcher would gather HTLCs from
those previous requests as well, and see which ones are required?
{Insert bikeshed here}. {No, here}.
> Reconstructing messages from hashes and / or
> signatures isn't possible as long as there's sufficient unknown data in the
> preimage or message. This is achievable by changing the pubkeys used in
> the commit tx script and pubkey hash each state, without needing additional
> data in an OP_RETURN.
FWIW, I take back the idea about using the signature as a key:
1) While the crypto people tell me it's probably OK, they can't prove it.
2) If we go to Schnorr, I think it falls apart as both sigs are combined.
OTOH, changing pubkeys every step isn't required if we go for Laolu's
key-revocation scheme instead of shachain/elkrem. I think? (Roasbeef,
this is your cue to describe it in detail!)
Cheers,
Rusty,

2023-06-09 12:46:34 UTC

- reply

📅 Original date posted:2016-08-09
📝 Original message:
Joseph Poon <joseph at lightning.network> writes:
> Hi Rusty,
>
> On Tue, Aug 09, 2016 at 03:13:57PM +0930, Rusty Russell wrote:
>> We send the observer the "steal" tx every update (not really: we only
>> need to send the to-us/to-them amounts, pubkeys, HTLCs info and sig).
>> This gets encrypted+HMAC with the txid of the commit tx (or, if that's
>> too guessable, the SHA256() of our signature on the commit tx).
>>
>> [snip]
>>
>> If we want to obscure our funding tx, we can simply use a txid qualifier
>> the same way you did (and maybe use the sha256(txid) as the encryption
>> key to avoid weakening that).
>
> I think it may be necessary to identify when the transaction occurs as
> an index for outsourcing services, so the key can't be dervied directly
> from the txid with a single HMAC/sha256. It's possible there are
> millions of transactions to compare, and an index based on txid is
> necessary. The two options I can see are:
This is fun!
Yes, I think we agree some "filter hint" is needed to avoid a crazy
amount of outsourcing work (eg. first 8/16 bytes of txid). I don't
think an HMAC check per registered commitment is quite fast enough.
But there's a problem with most naive filters, if you can guess
commitment tx N-1 from commitment tx N. If the outsourcing service sees
an old commit they can guess at previous commitment txs using that.
Probably unroll the whole channel history if they can guess enough
HTLCs.
> 2. HMAC the transaction itself (not txid) as the secret key (or anything
> part of the transaction, as long as it isn't SHA256(tx) for obvious
> reasons). I like something along these lines better than option #1.
> Whatever computational cost there is will be extremely low, as the
> operations are constrained by block size.
If we include the witness in that HMAC we risk reintroducing
malleability. If we don't, we risk txs being predictable.
I can think of a few fixes: insert some randomness in the tx (OP_RETURN?
Different addresses each time?), or try to extract the input signature
from the witness, which is unguessable, as our filter?
What's simplest?
Rusty.

2023-06-09 12:46:33 UTC

- reply

📅 Original date posted:2016-08-09
📝 Original message:
Tadge Dryja <tadge at lightning.network> writes:
> Blinded outsourcing of channel monitoring
But if we don't steal HTLCs, the lack of channel utilization is a pain:
> States with in-flight HTLCs are another issue... if you want to keep the
> data storage down, you can just not include them, and make a policy that
> the sum of all the HTLCs should be less than either non-HTLC balance in the
> channel. That way the attacker still loses money if they try to attack.
> They potentially might not lose all of it though. You could make it
> variable size and include HTLCs as well but that increases the data rate
> significantly and probably hurts anonymity in various ways.
But now they must *always* keep their balance greater than all the HTLCs
they ever previously received at once, otherwise it's worth them
cheating.
I think we really do want to capture those HTLCs, but I don't think it's
as bad as you think: an HTLC can be described in ~40 bytes. We need to
do some magic to pad it out to hide the number of HTLCs, of course.
So, my method was less ambitious. I'll describe it here:
We send the observer the "steal" tx every update (not really: we only
need to send the to-us/to-them amounts, pubkeys, HTLCs info and sig).
This gets encrypted+HMAC with the txid of the commit tx (or, if that's
too guessable, the SHA256() of our signature on the commit tx).
I had assumed we'd tell the observer our channel funding txid: when it
sees that spent, it tries to use those signatures to decrypt all the txs
we sent. If one succeeds, it spends it.
If we want to obscure our funding tx, we can simply use a txid qualifier
the same way you did (and maybe use the sha256(txid) as the encryption
key to avoid weakening that).
Whatever we do, we might want to offer our own peers to do that watching
for them (for a fee?).
Cheers!
Rusty.

2023-06-09 12:45:55 UTC

- reply

📅 Original date posted:2016-03-08
📝 Original message:
Nicolas Dorier <nicolas.dorier at gmail.com> writes:
> Great, indeed we had same idea, I don't see how it solve the hashes in
> advance.
> As Alice knows
>
> H(1000000) = <random secret seed>).
>
> If she need the hash to the first commitment she need to hash the random secret
> seed 1000000 times. I think it is exactly the same problem as it is the exact
> same idea said differently.
See:
https://github.com/rustyrussell/ccan/tree/master/ccan/crypto/shachain
Cheers,
Rusty.

2023-06-09 12:45:54 UTC

- reply

📅 Original date posted:2016-03-07
📝 Original message:
Nicolas Dorier <nicolas.dorier at gmail.com> writes:
> One way deterministic RValue Generation
Hi Nicolas,
Yes, in fact shachain is a variant of this which avoids
generating several million hashes in advance. Interesting, I suggested
using hashing in the Deployable Lightning paper but didn't actually
spell out the idea. Hmm....
Seems like it orignated from Adam Back:
https://lists.blockstream.io/pipermail/lightning-dev/2015-May/000000.html
Cheers,
Rusty.

2023-06-09 12:45:16 UTC

- reply

📅 Original date posted:2015-11-27
📝 Original message:
Anthony Towns <aj at erisian.com.au> writes:
> Hey,
>
> Suppose you have a lightning channel, with balances of exactly 2 BTC
> on your side, and 1 BTC on the other (and 1mBTC for fees). You send a
> micropayment of 42 satoshi across the channel, resulting in an updated
> commitment that looks like:
>
> in:
> anchor (3.001 BTC): [yoursig theirsig redeemscript]
>
> out:
> 1 BTC: [pay2pubkey(theirs)]
> 1.99999958 BTC: [pay2pubkey(yours)]
> 0.00000042 BTC: [pay2scripthash(htlc to them with R or you after
> timeout)]
>
> But the third output will hit the IsDust() test (less than 546 satoshi
> for a min relay fee of 0.01 mBTC) and the entire transaction will be
> rejected, so the channel can't be closed at all!
>
> This is a similar problem to sub 1-satoshi payments, but it's different
> in that while you can't represent them as an HTLC output, you can
> represent them as soon as they complete -- ie:
>
> out:
> 1.00000042 BTC: [pay2pubkey(theirs)]
> 1.99999958 BTC: [pay2pubkey(yours)]
>
> is completely legitimate (whereas an output of 1.0 + 0.042e-8 BTC
> wouldn't be).
>
> I assume treating them much the same way is the only real option --
> account for them exactly in the lightning state, but just approximate the
> results in the actual commitments. So long as you're closing channels
> infrequently, losing a few hundred satoshi here and there won't matter
> much.
Yes, unfortunately we'll have to have a rule to avoid producing those
outputs.
I've opened https://github.com/ElementsProject/lightning/issues/14
so we make sure we track this.
> Another option might be to weaken the dust protection in the network --
> eg if you made the dust output be
>
> 0.00000042 BTC: [(them && (R || revoke))
> || (you && d CSV && t CLTV)
> || (3 months CSV)]
>
> then anyone could clear the dust after 3 months if it weren't otherwise
> claimed; maybe having some dust for a finite time is okay. But it'd also
> mean paying to an actual (non-standard) script, rather than a scripthash,
> which would be annoying in its own way... And, really, adding that output
> to the txn would probably cost more in additional fees that it's going
> to pay you in any case.
Agreed, we'll just cull those outputs and let them go to fees.
Cheers,
Rusty.

2023-06-09 12:45:06 UTC

- reply

📅 Original date posted:2015-11-19
📝 Original message:
Hi all!
As you know, I designed a lightning variant which used only
non-experimental, in-planning BIPs[1]. One assumption was BIP62: in
particular, that anchor malleability wouldn't be an issue. This was
flawed; BIP62 will never be deployed.
There are several options from here:
1) Ignore it. Malleated txs are non-standard.
2) Add a timeout to the anchor. Limits the lifetime of the channel, and
still means if it does happen you have to wait for the timeout.
3) Propose a reduced BIP62 which (say) only protects P2PKH, for a
specific transaction version.
4) Take a leap of faith and assume Segregated Witness fixes all
malleability.
I was debating between #1 and #3 for a while, but eventually settled on
#4. Here's why:
1) While still pre-BIP, Pieter Wuille is working on a prototype now
(Luke Jr came up with a sanish way of softforking it in).
2) Other parts of the lightning code (in particular, watching bitcoin
transactions) become significantly simpler if malleability is
ignored.
3) It's the right thing for Bitcoin; all smart contract systems want
this.
This result is NOP for lightning in the short term; assuming SW is the
same as pretending malleability doesn't exist. But if we need to add
malleability support later, it's going to be painful, since handling it
correctly in all the places it's missing will be hard.
Cheers,
Rusty.
PS. Remember, every project has 3 major disasters. Just wait until you
see the next two!
[1] https://github.com/ElementsProject/lightning/blob/master/doc/deployable-lightning.pdf

2023-06-09 12:44:48 UTC

- reply

📅 Original date posted:2015-10-19
📝 Original message:
Mats Jerratsch <matsjj at gmail.com> writes:
>> This makes some sense (though the anchor transactions don't need to be
>> P2SH, it's nicer for bitcoin's UTXO if they are).
>
> Well, currently there is no one working on a malleability fix, so we
> should probably work forwards the next available goal. ;)
Oh, I'm pushing BIP 62, as well, in parallel with everything else :)
>>> For the current form it would be enough to have
>>> SecretAHash || KeyB' || KeyB || KeyA || TxID || SignatureB (L=231B)
>>> with KeyB being the node pubkey (lots of key reusage...)
>>> or
>>> SecretAHash || KeyB' || KeyB || KeyA || TxID || nodePubKey ||
>>> SignatureB (L=264B) with KeyB as a channel key that does not need to
>>> be equal with the nodePubKey.
>>
>> Yes, I think avoiding key reuse is good. So, to be clear, the anchor TX
>> output looks like:
>>
>> P2SH (2 KEYA KEYB 2 OP_CHECKMULTISIG)
>
> Having to deal with malleability, the only viable solution for anchor
> transactions are with escape and fast-escape?
>
>> I think we can do slightly better with Schnorr signatures (which you can
>> simply do multisig by addition, if I understand correctly) where both
>> parties cooperate to form:
>>
>> KEYA KEYB NODE-PUBKEYA NODE-PUBKEYB TXID DUAL-SIGNATURE
>>
>> That's 33+33+33+33+32+64 = 228 bytes per channel.
>
> Interesting, I kinda feel uncomfortable with Schnorr though. It feels
> like some experimental method, and at least for Java, there are very
> few implementations around (and I don't feel comfortable implementing
> it on my own either..)
>
> I like the idea of adding together one object for the channel to be
> sent by both nodes. Even without Schnorr it saves some bytes and the
> overhead of gossipping.. We can always switch the signature to Schnorr
> too..
Yes, we've not as bound to consensus, which is nice. Schnorr is
something we can decide on later, for sure.
Cheers,
Rusty.

2023-06-09 12:44:47 UTC

- reply

📅 Original date posted:2015-10-16
📝 Original message:
Mats Jerratsch <matsjj at gmail.com> writes:
> So being done with encryption and authentication, the next layer for
> me now is to figure out how exactly nodes will broadcast their
> existence and open channels and everything.
Hi Mats,
Thanks for bringing this on-list!
> (2)
> As long as the malleability issue has not been fixed, the blockchain
> can only used with additional techniques to obtain a map of the
> channels from it. As the anchor transactions are P2SH, we need to
> expose the script, such that others are able to verify we at least
> have an anchor tx on the blockchain (associated with costs after all).
This makes some sense (though the anchor transactions don't need to be
P2SH, it's nicer for bitcoin's UTXO if they are).
> For the current form it would be enough to have
> SecretAHash || KeyB' || KeyB || KeyA || TxID || SignatureB (L=231B)
> with KeyB being the node pubkey (lots of key reusage...)
> or
> SecretAHash || KeyB' || KeyB || KeyA || TxID || nodePubKey ||
> SignatureB (L=264B) with KeyB as a channel key that does not need to
> be equal with the nodePubKey.
Yes, I think avoiding key reuse is good. So, to be clear, the anchor TX
output looks like:
P2SH (2 KEYA KEYB 2 OP_CHECKMULTISIG)
To prove we control KEYA, we simply need to sign something with it (our
nodePubKey):
KEYA NODE-PUBKEY TXID SIGNATURE
I think we can do slightly better with Schnorr signatures (which you can
simply do multisig by addition, if I understand correctly) where both
parties cooperate to form:
KEYA KEYB NODE-PUBKEYA NODE-PUBKEYB TXID DUAL-SIGNATURE
That's 33+33+33+33+32+64 = 228 bytes per channel.
Later on, we can send SPV proofs for TXID.
> This is information everyone should store in case a new node joins a
> network, similar to the blockchain. New nodes can then check against
> the blockchain, whether this data is actually present there. An
> attacker can fake a complete network together with lots of
> transactions on the blockchain, but the incentive is low (vandalism)
> and the costs are high. For 100k nodes and 10 open channels per node,
> this adds up to 220MB. Not too bad, considering full nodes are highly
> incentivised to run full bitcoin nodes as well, it is actually rather
> negligible. This information is pretty static, however we want
> everyone to have a decently consistent view of the network, so we
> would probably do some rebroadcast of that every few days, just to
> ensure everyone knows about it.
Also, once a node is live, I'm not sure how much of the map it will need
to keep. It might be able to prune distant parts of the map randomly,
and get it back from the rest of the network if needed? Requires more
thought, though.
> As I'm implementing broadcast messages anyways for other purposes (see
> other ML post), I tent to like (2) the most, it is the most expensive
> to attack as well I think.
I agree. Least on-chain spam.
Thanks!
Rusty.

2023-06-09 12:44:26 UTC

- reply

📅 Original date posted:2015-09-20
📝 Original message:
Anthony Towns <aj at erisian.com.au> writes:
> On 19 September 2015 9:39:44 am AEST, Rusty Russell <rusty at rustcorp.com.au> wrote:
>> // Sum of this whole thing after decryption.
>> required sha256_hash sum = 1;
>>
>> // Where to next?
>> oneof next {
>> // Actually, this is the last one
>> bool end = 2;
>> // Next lightning node.
>> pubkey lightning = 3;
>> // Other realms go here...
>> }
>>
>> // How much fee you can take (== all, if last node)
>> required int32 fee = 4;
>>
>> // Remainder (route blob for next node).
>> required bytes route = 5;
>
>>Nodes create the route backwards, to calculate the size. Then picks a
>>total size randomly between 1024 and 4096, and pads to that size (at
>>least 32 bytes of random padding). Then walks backwards to wrap and
>>encrypt it.
>>
>>This offers some protection from guessing the route length.
> Wouldn't it be better to store the expected balance to be forwarded rather than the fee? That way if someone takes too much, the next node can immediately abort the transaction.
Yes, excellent point. I flip-flopped on that; so I flipped again.
> Shouldn't the onion blob be re-padded when forwarded? Otherwise it'd
> sometimes drop below 1024 bytes and you'd be able to tell you're near
> the end of the chain.
Yes and this applies for almost any length selection method.
> Just adding random bytes on to the end should
> work I think - they'll just be treated as extra padding and ignored.
My original plan. But it enables a probing attack where you corrupt the
packet and if it succeeds anyway you know those bytes weren't used.
> Alternatively, maybe you could just append the encrypted bytes that made up your post of the payload from your incoming message: it was encrypted to you so should be effectively random to anyone else and will be garbled further when the next node "decrypts" it. That would save on entropy/crypto ops, and a constant message size would leak minimal info I think.
So rotate the payload? I don't think that's verifiable by the
recipient, so has the same probing attack issue as above.
Hmm, what if we include a pubkey, and you use that to encrypt 0 padding?
The last hop gets the privkey (and boundary information), and she can
verify the padding.
Off the top of my head, that solves both the length problem, and the
"route replacement" problem.
But I've not had coffee yet, plus jetlag. Could be missing a flaw or
simplification!
Thanks,
Rusty.

2023-06-09 12:44:25 UTC

- reply

📅 Original date posted:2015-09-20
📝 Original message:
Anthony Towns <aj at erisian.com.au> writes:
> On 19 September 2015 9:39:44 am AEST, Rusty Russell <rusty at rustcorp.com.au> wrote:
>>Route Probing Attacks
>>=====================
>>Now, there's a weakness here: No MAC! A nosy node can't corrupt the
>>routing past the next hop, but it could replace it entirely (this is
>>fundamental to the scheme of R values). If it guesses the final
>>destination right, the HTLC will succeed, otherwise it will fail, so it
>>can use this to probe.
...
>>I can't see a fix for this in general. :(
>
> I don't think parallel probes work well - if any of your probes succeed, your neighbour knows R and can claim all of your probes. Parallelization is also limited by channel capacity, assuming the payee knows how much to expect.
Channel capacity might not be an issue for tiny micropayments, but
the reveal of R is a good point: such probing should have a real cost
on success. I'll be sure to implement that properly :)
> I'm not sure probing is really plausible given mass deployment, is it? You have to guess the eventual recipient but given randomised routing you have every person or business using lightning as a potential candidate with possibly equal probability?
If someone wants to know whether I'm sending money to you, it would
work. Get a cheap hub near you, and one near me, and probe every
payment which passes through both.
But I guess it's a fairly boutique surveillance, which doesn't scale.
> For a general solution, I think you could completely rule out probing by having two R values, one known only by the recipient, and one by the sender (call it S say). Then make the htlcs payable on presentation of both R and S and include S encrypted to the final recipient in the onion payload. Munging the payload then makes the htlc irredeemable so misrouting it gives no information.
That's clever. And I think it works. I will need more coffee to figure
out if we should revise the transaction structure to include this.
> (Please let me know if the formatting of this mail is too hopeless; trying out a new setup)
No work wrap, but it seemed to work fine.
Cheers,
Rusty.

2023-06-09 12:43:53 UTC

- reply

📅 Original date posted:2015-08-02
📝 Original message:
Christopher Jamthagen <cjamthagen at gmx.com> writes:
>>> If the timestop feature would activate only when the CLTV transaction
>>> is included in a block, it would allow for a pretty serious DoS attack
>>> vector where hubs can be forced to close channels with other hubs by
>>> having the attacker, as the receiver, never reveal R and create a
>>> block-filling attack.
>
>> I don't think so. Let's say the rule is "time doesn't pass if a block
>> is full".
>
> But it would be necessary to explicitly supply the block-height at which the transaction that includes the CLTV was signed. Otherwise miners would have no other info but the block it is included in from which to count the number of full blocks to add to the expiration time of the CLTV.
No, it would increase over time. The CLTV block time and real block
time would diverge by 1 block / ~ 10 minutes every time a block is full.
It's the only sane way to do it, as you point out.
It doesn't help that we don't have a formal BIP to point at, but it's
probably a bit premature.
Hope that helps,
Rusty.

2023-06-09 12:43:52 UTC

- reply

📅 Original date posted:2015-08-01
📝 Original message:
Christopher Jamthagen <cjamthagen at gmx.com> writes:
>> Sent: Friday, July 31, 2015 at 1:48 AM
>> From: "Rusty Russell" <rusty at rustcorp.com.au>
>> To: "Christopher Jamthagen" <cjamthagen at gmx.com>
>> Cc: "lightning-dev at lists.linuxfoundation.org" <lightning-dev at lists.linuxfoundation.org>
>> Subject: Re: [Lightning-dev] Stealing money from a hub?
>> Christopher Jamthagen <cjamthagen at gmx.com> writes:
>>> Would it be desirable/possible to implement the timestop feature for
>>> CLTV as well? That would make the difference between the number of
>>> blocks until either expiration the same in case of a block-filling
>>> attack. If I'm not mistaken Peter Todds BIP is already merged, but
>>> this feature could be implemented with another soft fork.
>
>> Yes, timestop would logically be a softfork add, and it should apply to
>> both (same logic applies).
>
> If the timestop feature would activate only when the CLTV transaction
> is included in a block, it would allow for a pretty serious DoS attack
> vector where hubs can be forced to close channels with other hubs by
> having the attacker, as the receiver, never reveal R and create a
> block-filling attack.
I don't think so. Let's say the rule is "time doesn't pass if a block
is full".
> This would force the hub connected to the receiver to broadcast the
> commitment transaction
Why? The HTLC wouldn't expire, which would be a pain, but there's no
reason to panic and dump transactions. By definition, during a block
filling attack you've got all the time in the world.
Now, preventing HTLCs from expiring is a DoS, but a lesser one.
What am I missing?
> CLTV transactions would need to include the current block-height
> immediately when a commitment transaction is signed, so that miners
> can know where to start counting full blocks from as soon as it is
> broadcast. So my question is: Is such an upgrade for CLTV, as it is
> now, soft-forkable as it requires additional arguments? I am not
> totally clear on when upgrades are soft-forkable vs. hard-forkable.
Anything which is a furthur restriction (as in "this used to be valid,
and no longer is") is soft-forkable. So delaying timeouts is a soft-fork.
>>> Speaking of being online all the time, checking the blockchain is
>>> outsourceable, right? So it seems that miners would be the perfect
>>> third party to check for cheaters in LN. By offering them a nice chunk
>>> of our counterparty's funds as fees, they should be incentiviced
>>> enough to keep an extra eye for us on the blockchain.
>
>> Outsourcability scales really well; once you're full-time monitoring the
>> blockchain, might as well get as many clients as possible. You can also
>> automate the outsourcee's fee, by including it in the "steal" tx.
>
> Does it scale that well? I guess looking up pre-images in the shachain is fast, but what about R values in HTLCs? Would the third party have to store all those values or is there a nice optimization I have missed?
Indeed, there's a separate thread where Anthony Towns points out that
remembering R values and timeouts is an issue.
I was referring to the part where you watch the chain for spends on the
anchor outputs. You only need to do work to check what happened when
one of them gets spent, should almost never happen (since the client
should tell you they're going to close the channel cooperatively).
Cheers,
Rusty.

2023-06-09 12:43:46 UTC

- reply

📅 Original date posted:2015-07-26
📝 Original message:
Christopher Jamthagen <cjamthagen at gmx.com> writes:
> When a HTLC's CLTV has expired, the receiver of the HTLC should not be
> able to use the pre-image to spend the output from a commitment
> transaction that has not been invalidated.
> Assume a circuit is established: Alice -> Bob -> Dave
Yes, I assume that the HTLC gets eliminated by a commitment transaction
update at (or before) that time.
We could add an additional delay for this case, but it seems like
overengineering?
Cheers,
Rusty.

2023-06-09 12:43:43 UTC

- reply

📅 Original date posted:2015-07-23
📝 Original message:
Anthony Towns <aj at erisian.com.au> writes:
> If Alice ever tries cheating, and publishes and old commitment:
>
> 800 Alice + DELAY | #Alice_42 + Bob
> 200 Bob
>
> Then Bob needs to work out which of the 100 Alice_N hashes he knows or can
> work out is being abused; prior to the DELAY expiring. With millions of
> transactions that could be a bunch of hash calculations or a 100MB lookup
> table. Might make more sense to have a dummy output of "0: OP_RETURN 42" to
> make that calculation trivial though? That could trivially be verified as
> part of the "forms hash chain as expect" and "txn structure" checks.
It might be millions. What happens is Bob sees the anchor being spent,
checks if it's the latest commitment transaction. It's not, so does a
backwards search to find the revocation key.
The time taken for that search is O(N), where N is the current
commitment transaction number. But measurements on my laptop show that
1M transactions takes 5.4 seconds (see benchmark below), so I don't
think it's worth optimizing this "never happens" case.
> HTLCs are harder if you assume pay2scripthash is used though. If Alice
> published:
>
> 100 Alice + Delay | #Alice_55 + Bob
> 100 Bob
> 200 R1 + Alice + DELAY | Bob + TIMEOUT1 | #Alice_55 + Bob
> 200 R2 + Alice + DELAY | Bob + TIMEOUT2 | #Alice_55 + Bob
> 200 R3 + Alice + DELAY | Bob + TIMEOUT3 | #Alice_55 + Bob
> 200 R4 + Alice + DELAY | Bob + TIMEOUT4 | #Alice_55 + Bob
>
> well after R1..R4 were known and Alice_55 was revealed in order to try
> stealing most of the channel's funds, I think Bob could only claim the
> final outputs if he could unhash the scripts, which would require having
> remembered R1..R4 even after those contracts had long been resolved. I
> guess it could be feasible in that case to have the extra output be "0:
> OP_RETURN 42 #R1 #R2 #R3 #R4"?
Good point! With p2sh you need to know the R hash values and timeouts
to spend the output (40 bytes). Since OP_RETURN is length-limited to 80
bytes, you can't fit more than 2.
And if the HTLC outputs are not P2SH, they're non-standard and won't be
relayed.
What else can we come up with?
Thanks,
Rusty.
> [2] (Unattached footnote) This project's motto is "The lightning network:
> it's off the chain!" right?
> http://www.urbandictionary.com/define.php?term=off+the+chain
Err.... Yeah. It's spelled "caching layer for bitcoin" but it's
pronounced just like that.

2023-06-09 12:43:38 UTC

- reply

📅 Original date posted:2015-07-07
📝 Original message:
Hi all,
http://ozlabs.org/~rusty/diagrams/dual-anchor.svg
Since I posted my first design of HTLC yesterday, and noted that
it doesn't seem to require new sighash modes, I went back and revisited
my discarded ideas for establishing an anchor without new sighash modes.
If we can do that (and my HTLC design stands up), then lightning network
only needs OP_CHECKSEQUENCEVERIFY and OP_CHECKLOCKTIMEVERIFY, which are
fairly low-albedo soft forks.
To recap: the draft paper and current code trade signatures on
the first commitment transaction before signing the anchor transaction.
That way you are sure to have a way to get your funds back before you
put them into the anchor. (The paper uses the term funding transaction;
I prefer anchor).
This can't be done in normal bitcoin, as you don't know the TXID
of the anchor until after its inputs are signed, so you can't sign the
commitment transaction without knowing the txid of the anchor. It works
in Elements Alpha because they have segregated witness; the txid of the
anchor doesn't hash the input scripts. It could work in bitcoin with a
softfork of a new CHECKSIG2 which has new signature modes, but there's
not even a BIP for that, and there are so many things that could be done
there that it's likely to be long delayed.
So, how can we solve this? Well, we can have two anchors
instead of one. I put my inputs into my anchor, you put your inputs
into yours: each one requires both our signatures to spend. The
commitment tx has two inputs, one for each.
We can trade anchor txids, so we can both sign the commitment
tx. But now one of could withhold our anchor, leaving us with an
unusable commitment tx and stuck output from an anchor. We need a way
to get the funds back in that "abort" case.
Thus we add an intermediary transaction (called "Escape"
transactions) which spends the 2 of 2 anchor output, but can be spent
either by 2 of 2 (ie. the commitment tx), OR back to the anchor owner
after a delay (using OP_CHECKSEQUENCEVERIFY).
The order is as follows:
1) We both trade anchor txids and amounts.
2) We both trade signatures for the escape transactions, so either one
can broadcast them.
3) Now we are sure to be able to recover our funds, we each broadcast
our anchor txs.
4) If the other side broadcasts their escape transaction, abort and
broadcast our escape transaction. After the timeout, we can spend
it.
5) If the other side doesn't broadcast their anchor tx, abort and
broadcast our escape transaction.
6) Otherwise, when the anchor txs reach the required depth, we exchange
signatures for the commitment transaction.
7) If the other side broadcasts either escape transaction, broadcast
the other escape transaction and the commitment tx as normal (this is
a unilateral close) before they can reclaim their anchor funds.
I think this works, and doesn't add any new requirements; you now need
to watch out for escape txs being broadcast instead of commitment txs.
The downside is that there are 3 extra transactions involved; 1 extra
for the channel open, and 2 for the channel close.
Feedback, optimizations, horrible holes?
Rusty.