Before this change, repository gets detected as:
Python 51.1%
Shell 48.9%
After this change, repository gets detected as:
Markdown 98.0%
Other 2.0%
This change was added for a cosmetic effect on GitHub, and the line
this change adds can go away if needed.
None of the project maintainers have access to that website.
It is completely outdated and could be modified without our consent,
so we shouldn't link to it anymore.
Since HTLCs below this amount will not appear in the commitment tx, they
are effectively converted to miner fees. The peer could use this to grief
you by broadcasting its commitment once it contains a lot of dust HTLCs.
Add network dust thresholds computation details, as implemented in Bitcoin
Core's default relay policy.
Drop non-segwit support in shutdown: this allows dust limit to go as low
as 354 sats without creating relay issues with default node policies.
We add a requirement that dust limit cannot be lower than 354 sats.
This ensures implementers don't have to figure this subtlety on their own.
Fixes#696 and #905
Bolt 11 invoices must contain a `payment_secret`, which means that the
`features` field must set the `payment_secret` feature (and its dependency,
`var_onion_optin`).
Fixes#897
With anchor outputs, we can keep the commit tx feerate lower than the real
on-chain feerate. That means that when closing the channel, the resulting
fee will not necessarily be lower than the current commit tx fee, this
requirement doesn't make sense to be strict.
Both sides can optionally include a preferred fee range in their
`closing_signed`. This lets their peer know what fees they find acceptable
and simplifies the closing negotiation.
This is extracted from channel_upgrade (#868), but used for opening
negotiation as suggested by @roasbeef on the last spec meeting.
It's a trivial change, fully backwards compatible, but now each channel
has a channel_type, which defines its behavior, rather than an ad-hoc
set of "sticky" feature bits. It also means both peers can *support* a
feature without endorsing it.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Update Bolt 11 test vectors to always include a payment secret.
We want to make it mandatory in invoices which would make the existing
test vectors invalid.
We previously had a restriction on HTLC amounts to avoid big losses during
the early phases of the network, but it shouldn't be necessary anymore.
As long as we honor `max_htlc_value_in_flight_msat` and implementations
provide safe defaults for that parameter, we don't need that additional
restriction.
In bitcoin 0.19.0, standardness rules are going to be relaxed to allow
future witness versions. Once this is widely deployed, it will be safe
to accept them, smoothing use of future segwit versions.
See: https://github.com/bitcoin/bitcoin/pull/15846
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit is intended to fix an ambiguity in the spec that led to a
divergence in the sorting tie breaker between implementations, that can
lead to force closed transaction in practice. BIP 69 operates on the
output level, therefore it examines the _satoshi_ amount of a output
when sorting. The spec however, references BIP 69, but states that an
"identical" HTLC output may have the same `amount_msat` value.
In the wild this led to some implementations checking the _sat_ value of
an HTLC while others checked the _msat_ value. In the scenario where an
pair HTLC has the same _sat_ value, but differing _msat_ values, then
one will fall through to the tie-breaker, while the other while sort
them according to their _msat_ values.
In this commit, we attempt to make this requirement more explicit by
removing the reference to `msat`, and more explicitly describing when an
HTLC pair is to be considered identical.
This is the only one, so I simply removed it. We'd notice if a new field
was introduced which didn't change the output these days, but this has been
here since 2017.
Here's the difference in extract-formats.py's output:
```diff
@@ -177,6 +177,9 @@
msgtype,final_incorrect_htlc_amount,19
msgdata,final_incorrect_htlc_amount,incoming_htlc_amt,u64,
msgtype,channel_disabled,UPDATE|20
+msgdata,channel_disabled,flags,u16,
+msgdata,channel_disabled,len,u16,
+msgdata,channel_disabled,channel_update,byte,len
msgtype,expiry_too_far,21
msgtype,invalid_onion_payload,PERM|22
msgdata,invalid_onion_payload,type,bigsize,
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx
when there are multiple offered htlc with the same amount and preimage.
The test vector reuses previous preimages and creates a case scenario with 1 received htlc
and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value.
It is asserted the order in which the htlc transactions should be kept internally
and we assume the same order is used to construct the commitment_signed message.
This complements #491 .
Judging from the comment
https://github.com/bitcoin/bitcoin/pull/18267/files#r491150895 in the
Signet PR all test networks should have the same bech32_hrp prefix (even
regtest). That's why 'tb' was chosen for Signet as well.
This is not optimal for LN as invoices shouldn't be vague in
what network they were issued for.
Therefore we add the explicit prefix 'lntbs' for Signet invoices.
Routing nodes have an incentive to use low fees when opening channels to
ensure their activity is economically viable.
However, when a funding transaction takes too long to confirm, the fundee
may have forgotten the channel. In that case the funder is forced to
broadcast the first commit tx to get his funds back and then open a new
channel, which is costly.
We can avoid this issue by simply knowing how long the fundee will wait,
and ensuring the funding tx confirms before that period ends. We set this
timeout to 2016 blocks (2 weeks).
Some ChaCha20 implementations API's support both 64- and 96-bit nonces, while
others only support a single one.
Functionally, both nonce sizes are equivalent for LN usage, since the
nonce is always zeroed. However, while evaluating spec compliance of
ChaCha20 libraries, the fact that some do not support the 8 byte nonce
variant prompted a closer investigation about the nonce requirement.
Since RFC8439 is the one linked to in the current BOLT0004 spec and that
RFC only specifies the 96-bit nonce variant, that requirement is made
more explicit by this commit.
We previously insisted that `reply_channel_range` messages were not
overlapping: blocks content could not be split across multiple messages.
This made it possible to implicitly figure out when sync was complete, so we
re-purposed the previous `complete` field to a `full_information` field.
We now revert that change to allow blocks to be split across multiple
messages. An explicit flag is thus needed to signal that sync is complete.
Fixes#804
* BOLT#3: use 4 bytes for cltv_expiry in accepted_htlc_script
* BOLT#3: correct success_witness size
* BOLT#3: note HTLC tx weights differ a bit from actual weights
If `option_anchor_outputs` applies, the cheating node can pin spends of its
HTLC-timeout/HTLC-success outputs thanks to SIGHASH_SINGLE malleability.
Using a single penalty transaction for all revoked outputs is thus unsafe as it
could be blocked to propagate long enough for the `_local node's main output_ 's
relative timelock to expire and the cheating party escaping the penalty on this
output.
The existing requirements were not specifying the case where both a
`commitment_signed` and `revoke_and_ack` need to be retransmitted.
This is an important case to specify because if the relative order is not
preserved, the channel will close.
Fixes#794
This script was previously used in Electrum but no more.
So since this script doesn't even parse the output of
extract-formats.py any more, just remove it.
Many channels use a value below 6, which is really insecure (there are
more than 2k such channels on mainnet).
While less risky, there are more than 7k channels with a value below 12.
This indicates that the spec should probably make the risks a bit more
clear to help guide node operators.
This commit extends the specification with a new commitment format that
adds two anchor outputs to the commitment transaction. Anchor outputs
are a safety feature that allows a channel party to unilaterally increase
the fee of the commitment transaction using CPFP and ensure timely
confirmation on the chain. There is no cooperation required from the
remote party.
