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.
Add an additional "reserve" for funders on top of the real reserve to
avoid getting in a state where the channel is unusable because
of the increased commit tx cost of a new HTLC.
Requirements are only added for the funder sending an HTLC.
Fundee receiving HTLCs may choose to verify that funders apply
this, but it may lead to an unusable UX.
Fixes#728.
The spec already prepared a hook to add additional information to existing
messages (additional bytes at the end of a message must be ignored).
Since we're using TLV in many places, it makes sense to use that optional
additional space at the end of each message to allow an optional tlv stream.
This requires making a few previously optional fields mandatory:
- channel_reestablish commitment points: it makes sense to always include those
regardless of whether `option_dataloss_protect` or `option_static_remotekey` are set.
- option_upfront_shutdown_script: if you're not using one, just set the length to 0.
That field is moved to a TLV record because luckily, the resulting bytes are the same.
This provides more flexibility to later remove the requirement of making this field mandatory.
No need to change the `channel_update`'s `htlc_maximum_msat` because
the `message_flags` encode its presence/absence.
It can still be either included or omitted without causing issues to the extension stream.
The spec already prepared a hook to add additional information to existing
messages (additional bytes at the end of a message must be ignored).
Since we're using TLV in many places, it makes sense to use that optional
additional space at the end of each message to allow an optional tlv stream.
This requires making a few previously optional fields mandatory:
- channel_reestablish commitment points: it makes sense to always include those
regardless of whether `option_dataloss_protect` or `option_static_remotekey` are set.
- option_upfront_shutdown_script: if you're not using one, just set the length to 0.
That field is moved to a TLV record because luckily, the resulting bytes are the same.
This provides more flexibility to later remove the requirement of making this field mandatory.
No need to change the `channel_update`'s `htlc_maximum_msat` because
the `message_flags` encode its presence/absence.
It can still be either included or omitted without causing issues to the extension stream.
ECDSA signatures in Bitcoin are DER-encoded but public keys are not.
The compressed format for public keys is for example standardized in
Sections 2.3.3 and 2.3.4 of
Standards for Efficient Cryptography, SEC 1: Elliptic Curve
Cryptography, Certicom Research, Version 2, 2009,
https://www.secg.org/sec1-v2.pdf
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>
We might argue this does not apply if you set `minimum_depth` to 0, since
you're assuming trust (TurboChannels-style), but it needs to be specified.
See: CVE-2019-12998 / CVE-2019-12999 / CVE-2019-13000
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
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>
* Added descriptions of how a 2-of-2 multisignature verification is used for enforcing timelocks when timing out on-chain offered HTLCs as well as spending on-chain received HTLCs in the success case.
(No spec change, just wording)
The "local" and "remote" here are just *confusing*. Each side says
where it's at, and the other side retransmits based on that.
We could call it 'number_of_next_commitment_i_expect_to_receive' and
'number_of_next_revocation_i_expect_to_receive' but that's getting
silly.
These names were a major source of confusion while writing tests!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
It's trivial to make types->lengths, but not so much the other way.
The types I used here are the ones I found useful in implementation, and
I think add some clarity, though we can certainly argue about them.
There's no normative changes to the spec in here.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Saying "the risk is only to the node *accepting* the HTLC" is confusing
because merely accepting an HTLC is risk-free. The risk comes from
accepting *responsibility to route the payment*, i.e. offering an HTLC
of your own in the next channel on the path, where a too-small
difference in the HTLC values could end up with you cheated out of a
payment.
This revised paragraph hopefully makes that clearer.
Uses more specific and consistent language ("the"/"that" instead of "an"
where possible). Also helps avoid confusion with unrelated HTLCs that
serve other payments but are shared by the same two nodes.
We express it has how the outputs are ordered, but the only way you can
detect that is by the htlc_signatures order, which is the part which really
matters.
I finally reproduced this, BTW, which is why I'm digging it up!
Closes: #448
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This seems to be a cause of stuck HTLCs on the network: c-lightning has
done this for a while now (since 0.6.1).
[ Minor wording clarification merged --RR ]
Decided-at: Adelaide Summit 2018
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Although commitment numbers are explained in the
[glossary](00-introduction.md#glossary-and-terminology-guide),
it's helpful to re-iterate at the place that it's first used.
To 'fail a channel' is mentioned multiple places in this
BOLT without any mention or definition of what that means.
This adds a link to the relevant text in BOLT 05 in the
first place that we mention 'fail the channel'.
