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,071 Commits 18 Branches 1 Tag 16 MiB
f23f55c12b
Commit Graph

1071 Commits

This Branch
This Branch
All Branches
Author SHA1 Message Date
Carla Kirk-Cohen
78e5a6b066
04-onion-routing: strict validation of scid for blinded payments (#1147) 
This commit updates bolt04 to more strictly enforce that encrypted_data
that is part of a blinded payment only has short_channel_id set. On
the reader side, we disallow setting of both short_channel_id and
next_node_id (which is intended for use in the context of onion
messages), and on the writer side we specify that next_node_id should
not be included by recipients.
 2024-03-12 09:56:54 +01:00
Trigger
60de4a0972
BOLT 7: correct the default min_final_cltv_expiry_delta in routing example (#1143) 2024-02-22 10:01:47 +01:00
Rusty Russell
8fc3ba9f0c
BOLT 4: It's Check Lock Time Verify not Check Time Lock Verify. (#1141) 
I always get this wrong too, so CLN actually has a source check for this, and it triggered when importing the latest spec!

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
 2024-02-19 09:34:00 +01:00
jrakibi
ec525cc418 Update Signet port to correct hex value in BOLT #1 spec 2024-02-16 08:57:36 +10:30
niftynei
0bdaa8b9f6 dual-fund: add require_confirmed_inputs to RBF messages 
Make `require_confirmed_inputs` explicit for RBF regnegotiation.

Requested-By: @t-bast
 2024-02-13 11:55:23 -06:00
niftynei
6018a4d43b dual-fund, verbiage: clarify situation for closing a underfunded channel 
Moved up some rationale from the Rationale section and added a
bit of clarification to when you'd want to close/cancel an open.

Reported-By: @morehouse
 2024-02-13 11:55:23 -06:00
niftynei
bd1460d8cf dual-fund, wording: move sighash_all into existing verbiage 
Suggested-By: @morehouse
 2024-02-13 11:55:23 -06:00
niftynei
d9c571d25d dual-fund, nit: change wording on common input heuristic 
Suggested-By: @devrandom
 2024-02-13 11:55:23 -06:00
niftynei
f0c9ff732f tx-signatures: address comments regarding underpyament of fees 
Reported-By: @morehouse
 2024-02-13 11:55:23 -06:00
niftynei
076f21d65e nit: verbiage + wording 
Suggested-By: @morehouse
 2024-02-13 11:55:23 -06:00
niftynei
fa879e325c tx-complete: clarify that the total input/total output incl funding 
Found-by: @morehouse
 2024-02-13 11:55:23 -06:00
niftynei
11dea59504 tx-abort: port over meaning of the data field from warning 
`tx_abort`'s structure comes from the `warning`/`error` messages,
but we failed to port over the rationale/rules for the `data` field.

Suggested-By: @morehouse
 2024-02-13 11:55:23 -06:00
Dustin Dettmer
71e67e6d46 Bolt 2: Make interactive-tx explicitly use SIGHASH_ALL 
This was previously assumed but adding it to the spec makes it explicit, should we ever want to change it in the future.

Suggested-By: @morehouse
 2024-02-13 11:55:23 -06:00
niftynei
c51ef43fee interactive-tx: highlight MUST of serial_id sorting 
Suggested-By: @dunxen
 2024-02-13 11:55:23 -06:00
Duncan Dean
2ddddbd7c2 Use bitcoin wire encoding for witnesses 2024-02-13 11:55:23 -06:00
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