mirrors/lightning-bolts
1
0
Fork 0
mirror of https://github.com/lightning/bolts.git synced 2024-11-19 01:50:03 +01:00
Code Issues Projects Releases Wiki Activity
1,056 Commits 18 Branches 1 Tag 16 MiB
22b9c87453
Commit Graph

1056 Commits

This Branch
This Branch
All Branches
Author SHA1 Message Date
t-bast
c7af874f3d Store state when sending commitment_signed 
If we only store state when sending `tx_signatures`, there are cases where
we cannot reconcile states if a disconnection occurs during the signing
steps: one side will have sent `tx_signatures` and thus must wait for the
transaction to be spent or double-spent, while the other side has already
forgotten that channel because they haven't sent `tx_signatures`.

This is fixed by storing state when sending `commitment_signed`, and
adding a `next_funding_txid` field to `channel_reestablish` to ask our
peer to retransmit signatures that we haven't received.
 2024-02-13 11:55:23 -06:00
t-bast
1e48543ff1 Add section about liquidity griefing 
This issue is non-trivial and worth mentioning, otherwise implementations
may forget to handle this which would result in an easy way of attacking
node's on-chain liquidity, creating a large opportunity cost.
 2024-02-13 11:55:23 -06:00
t-bast
03a0eab139 Add require_confirmed_inputs TLV 
This lets any side of the protocol require the other side to use confirmed
inputs, to avoid paying the fees of a low feerate unconfirmed ancestor.
 2024-02-13 11:55:23 -06:00
niftynei
0bc22790ea v2 opens: proposal to get rid of the minimum estimated fee 
Prior versions of the v2 dual-funding protocol assumed a 'minimum fee'
payment for any witness stack of any input, as a way to simplify fee
checks.

The suggested min feerate didn't make sense for taproot spend paths etc;
instead we remove this check entirely.
 2024-02-13 11:55:23 -06:00
niftynei
cf9a5fcfe5 peer-protocol: send first+second commit point in openchanv2 + accept 
Repeat the second commit point in the initial openchannel2 +
acceptchannel2 messages.

Suggested-By: @pm47
 2024-02-13 11:55:23 -06:00
t-bast
811e55cd9e Use signed amounts in RBF messages 
While dual funding only needs unsigned funding amounts, other protocols
that leverage interactive-tx may use signed funding amounts, for example
to take funds out of an existing channel (splice-out).

It is thus more future-proof to use signed amounts in `tx_init_rbf` and
`tx_ack_rbf`.
 2024-02-13 11:55:23 -06:00
t-bast
180e4764ce Clarify RBF funding requirements 2024-02-13 11:55:23 -06:00
niftynei
3f1d142471 v2 opens: add a tx_abort message 
Requested-by: @t-bast
 2024-02-13 11:55:23 -06:00
niftynei
c00c0dd7bc interactive-tx: Add dual-funding flow, using the interactive tx protocol 
This commit adds the interactive transaction construction protcol, as
well as the first practical example of using it, v2 of channel
establishment.

Note that for v2 we also update the channel_id, which now uses the hash
of the revocation_basepoints. We move away from using the funding
transaction id, as the introduction of RBF* makes it such that a single
channel may have many funding transaction id's over the course of
its lifetime.

*Later, also splicing
 2024-02-13 11:55:23 -06:00
niftynei
15fb2df63a spelling: fix spelling mistakes + add new words to ignore spelling 2024-02-13 11:55:23 -06:00
xiaolou86
9f55ccdfee
Fix typos (#1130) 
* BOLT 04: fix typos
* proposals: fix typos
 2024-01-30 06:54:54 +01:00
Bastien Teinturier
a4b6357bad
Add min_final_expiry_delta to blinded route example (#1131) 
Payment recipients must ensure that they have a few blocks
before fulfilling the payment, in case the inbound channel
force-closes.
 2024-01-30 06:52:29 +01:00
Olaoluwa Osuntokun
8a64c6a1ce
Merge pull request #1086 from ariard/2023-06-specify-max-cltv-expiry-delta 
BOLT4: Specify max HTLC nLocktime for expiry_too_far
 2023-10-23 12:08:39 -07:00
Olaoluwa Osuntokun
7620072cef
Merge pull request #1109 from rustyrussell/define-negotiated 
BOLT 1: define what `offered` and `negotiated` mean.
 2023-10-23 12:07:48 -07:00
Antoine Riard
bccab9afc2 Specify max HTLC nLocktime for expiry_too_far 2023-09-25 21:26:16 +01:00
Keagan McClelland
4dcc377209 Clarify the semantics of max_htlc_value_in_flight_msat 
Prior wording of the description of this parameter left room for
ambiguity around whether it capped the total value offered by both
channel peers combined or if it was solely capping the total value
of HTLCs offered by the remote.
 2023-09-26 05:50:01 +09:30
Rusty Russell
6649f51228 CONTRIBUTING.md: modern feature bit assignment. 
1. Put it in the PR title so everyone can see.
2. Deploy with +100 while it's still unratified, in case it changes.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
 2023-09-26 05:42:35 +09:30
Rusty Russell
95f2bbf2e2 BOLT 1: define what offered and negotiated mean. 
i.e. it was present in the init feature bits.  We use this in several places, but assume everyone knows what it means.

It's particularly fraught with required features: it's explicitly legitimate to assume these are accepted if
the node keeps talking to you after init!

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
 2023-09-13 12:02:14 +09:30
ProofOfKeags
6e85df448b
BOLT2: change "reject" to "fail" in channel opening requirements (#1104) 
Since "reject" isn't defined anywhere in the spec and "fail" does
have a definition laid out in BOLT1 that includes special
provisions for channels that have not yet been established, BOLT2
is amended to clarify the requirements for the receiver of
`accept_channel`
 2023-08-28 14:13:59 +02:00
Antoine Riard
a1870e136e
Add a max_dust_htlc_exposure_msat (#919) 
* Bound exposure to trimmed in-flight HTLCs
* Reject update_fee beyond max_dust_htlc_exposure_msat

Co-authored-by: t-bast <bastuc@hotmail.fr>
 2023-08-14 23:08:10 +02:00
Olaoluwa Osuntokun
8cb9b890cc
Merge pull request #1095 from vincenzopalazzo/macros/specify-multiple-fields 
bol09: Specify behavior when a node specifies both optional and required features
 2023-08-14 13:18:07 -07:00
Vincenzo Palazzo
ec59f7c1ca
bol09: Specify behavior when a node specifies both optional and required features 
While reviewing a patch on lnprototest, I encountered a scenario
where the BOLT 9 specification needed to provide clear guidance.

As a result, this commit adds specific requirements to
determine the appropriate behaviour when a node specifies
both optional and required features.

Additionally, if this situation appears to be an
implementation bug, it will be taken care of accordingly.

Reported-by: lnprototest
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
 2023-08-14 22:04:10 +02:00
valentinewallace
fbd19efe1f
Clarify computation of final outgoing_expiry in route blinding (#1069) 
BOLT 12 invoices do not include a max_cltv_expiry field, so it's good to
clarify how senders can compute the final outgoing cltv expiry.
 2023-08-11 17:29:37 +02:00
dni âš¡
7dda8f84ed
Bolt11: min_final_cltv_expiry_delta is optional, not required (#1100) 2023-08-09 11:35:28 +02:00
Rusty Russell
803a532c49 fixup! BOLT 4: onion message support. 
@thomash-acinq points out:

1. We absolutely can put other fields in `encrypted_data_tlv`, esp. padding, and test vectors do this.
2. Presumably it was supposed to refer to onionmsg_tlv, so fix that.
3. And of course we need to allow payload fields!
 2023-08-01 06:20:16 +09:30
Rusty Russell
f0f35ec73b fixup! BOLT 4: onion message support. 
Typo fixes from @t-bast, @thomash-acinq and @remyers.
 2023-08-01 06:20:16 +09:30
Rusty Russell
17ceba42dc BOLT 4: onion message support. 
These use onion encoding for simple one-way messaging: there are no error returns.
However, every onion uses route blinding *even if it doesn't need to*.

You can prove what path was used to reach you by including `path_id` in the
encrypted_data_tlv.

Note that this doesn't actually define the payload we're transporting:
that's explictly defined to be payloads in the 64-255 range.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
 2023-08-01 06:20:16 +09:30
Matt Corallo
9ab3c87a28 Correct final_cltv handling in blinded paths 
When paying a blinded path, we don't have a CLTV delta at each hop
available, but rather only a total CLTV delta for the entire
blinded path.

However, the onion format currently still requires that we specify
an `outgoing_cltv_value` for the final hop. As the sender, we don't
have a sensible value to put there, as we don't know which part of
the total CLTV delta belongs to the recipient.

The sender is instructed to use the values that are known to them
when setting `outgoing_cltv_value` for the final hop:
- The current block height.
- Any additional delta added to account for block propagation and
  improve privacy.

This change reflects the behavior of some implementations at the time
of writing.
 2023-07-31 15:40:05 -05:00
Matt Corallo
cded2df1fd Fix undeclared reference in onion-routing 2023-07-31 15:40:05 -05:00
Bastien Teinturier
7d3ef5a6b2
Allow unset onion_hash in invalid_onion_blinding (#1093) 
In most cases the `onion_hash` isn't actionable in the case of blinded
payments and it's wasteful to keep track of the incoming onion, so we
allow setting it to an all zero value.
 2023-07-27 11:31:40 +02:00
Rusty Russell
7f53a3e46e BOLT 8: make it clear that there are *two* chaining keys. 
lnmessage got this wrong!  It would pass our test vectors, but actually fail
in real usage, since it used the same `ck`.

Also, nonce rotation happens after 1000 encryptions, which is when the nonce
reaches 1000 (since it's zero based!), not when it *exceeds* 1000.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
 2023-07-18 05:38:27 +09:30
Carla Kirk-Cohen
e0995c9b84
bolt07: enforce htlc_maximum_msat >= htlc_minimum_msat (#1089) 2023-06-25 14:35:18 +02:00
Elias Rohrer
25a383af98
Fix short_chanel_id typos (#1087) 2023-06-12 13:23:17 +02:00
Rusty Russell
aad959a297 tools: remove option handling now last optional field was removed. 
6fee63fc34 made `htlc_maximum_msat`
compulsory, which was the last "optional" field.  All future options
will be TLVs, so we never need to parse the "] (optionxxx)" format
for fields again.

We allow options for messages, but only for documentation (we have
some messages which are only for `gossip_queries`), so we don't
put it in the output.

Here's the before/after diff of the output for all the spec files:

```diff
--- /tmp/before	2023-04-27 14:21:07.417170213 +0930
+++ /tmp/after	2023-04-27 14:19:39.184573086 +0930
@@ -273,7 +273,7 @@
 msgdata,channel_update,fee_base_msat,u32,
 msgdata,channel_update,fee_proportional_millionths,u32,
 msgdata,channel_update,htlc_maximum_msat,u64,
-msgtype,query_short_channel_ids,261,gossip_queries
+msgtype,query_short_channel_ids,261
 msgdata,query_short_channel_ids,chain_hash,chain_hash,
 msgdata,query_short_channel_ids,len,u16,
 msgdata,query_short_channel_ids,encoded_short_ids,byte,len
@@ -281,17 +281,17 @@
 tlvtype,query_short_channel_ids_tlvs,query_flags,1
 tlvdata,query_short_channel_ids_tlvs,query_flags,encoding_type,byte,
 tlvdata,query_short_channel_ids_tlvs,query_flags,encoded_query_flags,byte,...
-msgtype,reply_short_channel_ids_end,262,gossip_queries
+msgtype,reply_short_channel_ids_end,262
 msgdata,reply_short_channel_ids_end,chain_hash,chain_hash,
 msgdata,reply_short_channel_ids_end,full_information,byte,
-msgtype,query_channel_range,263,gossip_queries
+msgtype,query_channel_range,263
 msgdata,query_channel_range,chain_hash,chain_hash,
 msgdata,query_channel_range,first_blocknum,u32,
 msgdata,query_channel_range,number_of_blocks,u32,
 msgdata,query_channel_range,tlvs,query_channel_range_tlvs,
 tlvtype,query_channel_range_tlvs,query_option,1
 tlvdata,query_channel_range_tlvs,query_option,query_option_flags,bigsize,
-msgtype,reply_channel_range,264,gossip_queries
+msgtype,reply_channel_range,264
 msgdata,reply_channel_range,chain_hash,chain_hash,
 msgdata,reply_channel_range,first_blocknum,u32,
 msgdata,reply_channel_range,number_of_blocks,u32,
@@ -310,7 +310,7 @@
 subtype,channel_update_checksums
 subtypedata,channel_update_checksums,checksum_node_id_1,u32,
 subtypedata,channel_update_checksums,checksum_node_id_2,u32,
-msgtype,gossip_timestamp_filter,265,gossip_queries
+msgtype,gossip_timestamp_filter,265
 msgdata,gossip_timestamp_filter,chain_hash,chain_hash,
 msgdata,gossip_timestamp_filter,first_timestamp,u32,
 msgdata,gossip_timestamp_filter,timestamp_range,u32,
```

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
 2023-05-11 12:01:38 +09:30
Elle
1c1eda08a3
Bolt 4: clarify onion test payload contents (#1077) 
Adds a comment to the `onion-test.json` file to clarify that the
payloads specified for each hop in the test already include the variable
length encodings.
 2023-05-10 15:06:19 +02:00
Matt Corallo
2bf041f382
Merge pull request #1075 from t-bast/remove-disconnect-warning 
Remove requirements to disconnect on warnings
 2023-05-09 18:06:53 +00:00
Peter Neuroth
5635a3657e
Bolt 1: Clarify the definition of tu fields (#1073) 
Truncated integer fields, e.g. tu16 cannot have leading zeros
judging by the implementations of the parsers, which are used
across the different ln implementations.
The `can` imposed that it is not necessary to truncate the fields
to values of information.

Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
 2023-05-08 22:57:46 +02:00
t-bast
3747ba8302
Remove requirements to disconnect on warnings 
We generally shouldn't disconnect when sending or receiving warning
messages. Whenever disconnecting after a warning makes sense, it should
be specified in the requirements linked to that specific scenario.

Fixes #1072
 2023-05-05 09:37:48 +02:00
Matt Corallo
50b2df24a2 Update onion errors since we allow overpaying or under-CLTVing 
In #1032 we allowed overshooting the final amount and expiry, but
forgot to update the onion error descriptions which make reference
thereto.
 2023-04-11 09:56:22 +02:00
Antoni Spaanderman
29c14c6e12 fix typos 2023-03-29 09:09:19 +02:00
t-bast
c4c5a8e5fb Bolt 4: add blinded payments 
Add specification requirements for using route blinding to make payments
while preserving recipient anonymity. Implementers must ensure they
understand all those requirements, there are subtle attacks that could let
malicious senders deanonymize the route if incompletely implemented.
 2023-03-28 08:44:14 +02:00
t-bast
58d80473e0 Bolt 4: add route blinding construction 
Add specification requirements for creating and using blinded routes.
This commit contains the low-level details of the route blinding scheme,
decoupled from how it can be used by high-level components such as onion
messages or payments.
 2023-03-28 08:44:14 +02:00
t-bast
ebd0659fc9 Route Blinding 
Route blinding allows a recipient to provide a blinded route to
potential payers. Each node_id in the route is tweaked, and dummy
hops may be included.

This is an alternative to rendezvous to preserve recipient anonymity.
It has a different set of trade-offs: onions are re-usable, but the
privacy guarantees are a bit weaker and require more work (e.g. when
handling payment fees and errors).
 2023-03-28 08:44:14 +02:00
Elle Mouton
33098ad37a BOLT 03: fix anchors same amt and pre-image test vector 
The `commitment tx with 3 htlc outputs, 2 offered having the same amount
and preimage` test was not correctly updated after the value of test
htlc 6 was changed to 5000001 and the cltv expiry of test htlc 5 was
changed to 506. This commit updates the anchors test accordingly.
 2023-02-28 10:51:45 +01:00
Elle Mouton
20066dc2ab BOLT 03: fix static-remote same amt and pre-image test vector 
The `commitment tx with 3 htlc outputs, 2 offered having the same amount
and preimage` test was not correctly updated after the value of test
htlc 6 was changed to 5000001 and the cltv expiry of test htlc 5 was
changed to 506. This commit updates the static-remote test accordingly.
 2023-02-28 10:51:45 +01:00
Elle Mouton
7f7ee7ffe6 BOLT 03: fix legacy same amt and pre-image test vector 
The `commitment tx with 3 htlc outputs, 2 offered having the same amount
and preimage` test was not correctly updated after the value of test
htlc 6 was changed to 5000001 and the cltv expiry of test htlc 5 was
changed to 506. This commit updates the legacy test accordingly.
 2023-02-28 10:51:45 +01:00
Elle Mouton
2be691e19d BOLT 03: fix no htlc single anchor test 
The commitment transaction tests are all meant to use the same funding
transaction which has an amount of 10000000000 msat. The LocalBalance
and RemoteBalance along with the value of any htlcs should always add up
to this amount.

This commit updates the `simple commitment tx with no HTLCs and single
anchor` anchors test to comply with the above.
 2023-02-28 10:51:45 +01:00
Wilmer Paulino
b02bb6b0ed
Add test vectors for option_anchors_zero_fee_htlc_tx (#1018) 
These are the same test vectors as those found under Appendix F, except
that each HTLC has a zero fee transaction instead, resulting in a
signature change.
 2023-02-28 09:30:50 +01:00
Jesse de Wit
f7dcc32694
A note on the maximum size of Tagged Fields (#1042) 
Make it more obvious to readers of bolt 11 that the maximum length of a Tagged
Field is 639 bytes.
 2022-12-22 13:27:15 +01:00
Olaoluwa Osuntokun
a0bbe47b02
Merge pull request #1021 from joostjager/failure-message-tlv 
TLV failure message and recommended length to 1024
 2022-12-05 11:11:14 -08:00