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>
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.
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 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.
This commit:
- Adds a new Dependencies column to the BOLT 9 feature table
populated with existing feature dependencies.
- Requires that all valid feature vectors set transitive dependencies.
- Requires checking transitive dependencies when validating init
messages and payment request.
- Removes transitive feature requiremetns from the BOLT 11 writer, now
that they are implicit by needing to comply with the BOLT 9 origin
requirements.
This appears to have been an oversight in the flat features spec,
and is somewhat implicitly relied on for several new feature bits -
if var_onion_optin is set on a node_announcement (its not allowed
on a channel_announcement), then trying to route through that node
using the pre-tlv formt is somewhat nonsensical, and should be
forbidden.
BOLT 4 explicitly indicates var_onion_optin may appear in a BOLT 11
invoice, however, BOLT 9 only indicates it is available in init and
node_announcement contextx. Resolve this conflict in favor of BOLT 4
as there doesn't seem to be much reason to *not* allow it in BOLT
11 invoices.
We simply specify, in each case, where they will appear ("Context").
Because `globalfeatures` is already in use, we fold that into the
renamed `localfeatures` field to unify them (now called `features`),
but dissuade further use.
Note also: we REQUIRE minimal `features` field in
channel_announcement, since otherwise both sides of channel will not
agree and not be able to create their signatures!
Consider these theoretical future features:
`opt_dlog_chan`: a new channel type which uses a new discrete log HTLC
type, but can't support traditional HTLC:
* `init`: presents as odd (optional) or even (if traditional channels
not supported)
* `node_announcement`: the same as above, so you can seek suitable peers.
* `channel_announcement`: presents as even (compulsory), since users need
to use the new HTLCs.
`opt_wumbochan`: a node which allows channels > 2^24 satoshis:
* `init`: presents as odd (optional), or maybe even (if you only want
giant channels)
* `node_announcement`: the same as above, so you can seek suitable peers.
* `channel_announcement`: not present, since size of channel indicates
capacity.
`opt_wumbohtlc`: a channel which allows HTLCs > 2^32 millisatoshis:
* `init`: presents as odd (optional), or even (compulsory)
* `node_announcement`: the same as above, so you can seek suitable peers.
* `channel_announcement`: odd (optional) since you can use the channel
without understanding what this option means.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Co-Authored-By: Bastien Teinturier <31281497+t-bast@users.noreply.github.com>
This separates out the static remotekey changes from the more ambitious
option_simplified_commitment (which also included pushme outputs and
bring-your-own-fee for HTLC outputs).
As per http://www.erisian.com.au/meetbot/lightning-dev/2019/lightning-dev.2019-09-02-20.06.html
Thanks to everyone for feedback: @araspitzu @roasbeef @bitconner
Suggested-by: @roasbeef
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The tables were a bit unreadable in the source view, and the globalfeatures
table was not rendering correctly. This is just a minor cleanup pass.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
Suggested-by: Janus Troelsen <@ysangkok>
[ This was a joint effort by many people, with iterations not
indicated in this final commit: thanks to all who reviewed and
polished! Particularly: @jimpo @cdecker @sstone @ZmnSCPxj ]
This enables three new functions:
1. query_short_channel_ids: they will send channel_announcement /
channel_update / node_announcement followed by reply_short_channel_ids_done.
2. query_channel_range: they will send one or more reply_channel_range
with the short_channel_ids in these blocks.
3. gossip_timestamp_filter: filters what gossip they send.
It also changes behavior: we no longer send a `channel_announcement`
until we have at least one `channel_update`. The announcement is
fairly useless without an update already, but this in particular
enables reasonable timestamp filtering (channel_announcement does not
have an explicit timestamp).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
I regularized the descriptions in the localfeatures table, so keep a careful eye on the accuracy of those. Otherwise, fairly standard editing in this very short section.
Added text for lack of globalfeatures flags.
Somehow this got lost in merging; pre-approved at meeting 2017-11-27.
Reported-by: Pierre-Marie Padiou
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is Fabrice's #243 "BOLT2, BOLT3: reduce attack surface", split
out with minor polishing:
- Made it an optional feature (we can insist on it if we choose even bit).
- Rename from "final_scriptpubkey" to "shutdown_scriptpubkey".
- Make requirements the same as shutdown's scriptpubkey, or zero-len.
- Leave shutdown's scriptpubkey, just make sure it's the same or fail.
- Add to accept_channel as well as open_channel.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit removes the feature bit for channels_public as they have
been deprecated by the addition of the `announce_channel` field in the
`open_channel` message.
This is based on a series of patches from @EmelyanenkoK which makes the treatment of feature bits clearer and adds rationale so that future extensions can be made wisely.
Thanks to all involved!
Closes: #156
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Christian assumed first bit was 1, I assumed 0. And we should generally
assign in pairs (so an optional understanding can later become compulsory),
though for the initial draft it's unnecessary.
By giving names we avoid smearing values over the spec, containing them in
BOLT 9.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
* BOLT 2&7: Cleaner separation of concerns wrt announcement signatures
So far we did not have any indication on what to do if a node does not
allow announcing the channel and we had a mix of concerns in the
`funding_locked` message, which would also transfer the signatures
needed for the announcement. This is a proposal about splitting the
signatures into their own message, so that simple omission is an
opt-out of announcements, and it does not mix announcement/gossip
stuff into the peer-protocol.
(It also ended up adding a localfeatures flag to opt-into the channel-announcement, and thus creating BOLT 9)
