And weaken it: the opener doesn't need to respect it.
Note also that the `funding_locked`-can-change-alias refers to the same peer.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This lets you add your brand new channel to routehints, and also
means you can use a routehinted channel even if you (later?) have a
real channel.
This supports both trusted and untrusted zero-conf channels: in the
trusted case you can use it immediately like any other channel,
and for the untrusted case you simply use any push_msat they gave you
for outgoing payments, but fail incoming.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
If a node has to fail a channel but knows that its latest commitment transaction is outdated it should not be required to send it but rather wait for the peer to unilaterally close the channel.
The proposed solution is not so clean because it might produce a deadlock in which two peers assume they have outdated state and send `error` back and forth without actually force closing. Maybe in such a scenario we could create a protocol that mutually closes with split balance?
Also replaced the word use with broadcast as it seems more accurate.
Co-authored-by: t-bast <bastuc@hotmail.fr>
Prior to the addition of `warning` messages, BOLT 5 specified a
few cases where users should be warned that funds may have been
lost. However, it used the phrasing "send a warning" which can now
be confused with `warning` messages. Nodes should not generally
inform their counterparty that they have been robbed.
This adds the option to report an remote IP address back to a connecting
peer using the `init` message. A node can decide to use that information
to discover a potential update to its public IPv4 address (NAT) and use
that for a `node_announcement` update message containing the new address.
The proposal includes reporting the IPv4 and IPv6 address,
however in IPv6 there are likely no NAT issues. TOR is skipped for
obvious reasons.
Certain approaches to check and use this information are thinkable:
- Wait for multiple peers or a certain fraction to report the
same new address.
- Check some random node known via gossip to also report the new
address.
- Verify this information by making a test connection to itself.
There were valid uses for "I don't want to talk to you anymore" apparently!
Also fixed some tabs -> spaces.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
And make most places warn or error. Places where we're operating
on a channel tend to be "warn and close connection" since we want to
forget the mistake they just sent, and closing the connection does that.
We now use the same words everywhere:
1. "fail channel" means to go onchain (if necessary).
2. "send `error`" means to send an error message.
3. "send `warning`" means to send a warning message.
4. "close connection" means close the connection.
These are all spelled out explicitly, rather than having "fail channel"
imply sending an error packet, for example.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Under this spec, an error with an all-zero channel id is ignored.
Warnings, being odd, will be ignored by older nodes too.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
In this commit, we add a new feature bit to gate the new explicit
channel type funding via the new `channel_type` TLV. The addition of
this new bit allows peers to seek out other peers that understand the
new explicit channel negotiation. This is useful in practice, as it
allows peers to avoid needing to "downgrade" the feature bits advertised
at the connection level due to one peer not understanding a new
required feature bit while it has a channel with a connecting peer.
Such a workaround is already deployed on the network between lnd peers
and certain eclair peers, as the `lnd` peers require static key, but the
feature bit is unknown to eclair peers. This situation (forced
downgrade) is undesirable, as until the connected peer updates (or the
channel is closed) and "worst" feature bit set must always be advertised
in order to maintain connectivity.
The other benefit of adding this feature bit is that it allows
implementations to simplify their code by ensuring that the new feature
will be used before sending any messages that include or reference that
feature. Without a feature bit, peers are instead forced to essentially
guess if a peer understands that feature, with logic to be able to "bail
out" of an invalid state.
The addition of this feature bit matches the prior precedent of adding
feature bits when new fields in the channel negotiation message (last
one was upfront shutdown) are added.
The test vectors for invalid `init` messages were invalid since we added
the `networks` tlv extension.
They are now fixed and made more future-proof by using tlvs with high
values.
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
There's not a lot of reason to explicitly rate-limit ping messages
on the sending side, hosts on the internet can *always* send you
as much traffic as they want, its up to you whether you want to
talk back to them.
This seems to have been intended as a cutoff where nodes can skip
responding to pings below a certain rate, but in practice 30
seconds is much too long a time to learn that your peer has
disconnected.
We could reduce the threshold, but its not like this is the only
place in the spec where a peer can request a message response, and
that is unlikely to change, making it of highly dubious value.
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).
