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.
* Rename all the 'varint' to 'bigsize'.
Having both is confusing; we chose the name bigsize, so use it
explicitly.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
* BOLT 7: use `byte` instead of `u8`.
`u8` isn't a type; see BOLT #1 "Fundamental Types".
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
* BOLT 1: promote bigsize to a Fundamental Type.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
In this commit, we modify the existing instructions to create the Sphinx
packet to no longer start out with a zero initialize set of 1366 bytes.
Instead, we now instruct the sender to use _random_ bytes derived from a
CSPRG. This fixes a recently discovered privacy leak that allows an
adversarial exit hop to ascertain a lower bound on the true path length.
Note that this doesn't affect packet processing, so this is a backwards
compatible change. Only clients need to update in order to avoid this
privacy leak.
After this change is applied, the test vectors as is don't match the
spec, as they're created using the original all zero starting bytes. We
can either update these with our specified set of random bytes, or leave
them as is, as they're fully deterministic as is.
An alternative path would be to generate more random bytes from the
shared secret as we do elsewhere (the chacha based CSPRNG).
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>
Nodes can append additional data to their `query_short_channel_ids`
messages, which consists in one flag per short channel id and
specifies what they would like to receive (`node_announcement`,
`channel_announcement`, or/and one `channel_update` or both).
This commit modifies the varint encoding used for TLV types and lengths
to use a custom format called BigSize. The format is identical to
bitcoin's CompactSize, except it replaces the use of little-endian
encodings for multi-byte values with big-endian. This is done to prevent
mixing endianness within the protocol, since otherwise CompactSize would
be the first introduction of little-endian encodings.
[ Note: in retrospect, adding this in the initial draft without its
own feature bit was a mistake. It was a premature optimization,
adds complexity and removes the ability to disable it if a problem
is found without disabling gossip_queries entirely. However, it
is already deployed as-is. --RR ]
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
[ 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>
The description now suggests the use of an ephemeral private key, so
the reference code is simplified by using that concept. The reference
code is also updated to make fewer calls to undefined functions.
The new description introduces the concept of an ephemeral private key,
which I find easier to reason about and suggests a linear instead of
quadratic construction algorithm.
This got a little messy as some changes now needed to be applied in
two places, and other wording has been completely removed. Another
pass on top will be required.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is stolen from @sstone's #243 "reduce attack surface".
This breaks compatibility, as agreed at the 2017-11-13 meeting.
Note also that it does not update the test vectors.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Added an optional `c` field in the payment request specifying the
minimum `cltv_expiry` to use for the last htlc in the route. If
not provided, default value is 9.
This commit also clarifies how `channel_update` messages are only
to be used in the context of relaying payments, and how both htlc
amounts and expiries are to be calculated backwards from the values
provided in the payment request.
Not needing the `channel_update` for the first channel in a route also
means that it is possible to make a payment through a channel which
hasn't had any announcements yet.
This is unofficial, since we don't have IANA tag, but it doesn't
clash with any existing one. We'll see if this turns out to be something
people want.
Closes: #206
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This adds a message for each channel reconnect (after we've
sent/received `funding_signed`, ie. when we rememeber the channel),
which says exactly how many `commitment_signed` and `revoke_and_ack`
we've received. Really, we could use one bit for each (they could
only be missing the last one), but better to be clear.
This leaves the "rollback if didn't get commitment_signed"
requirement, but avoids any need to handle update duplicates or wonder
what update number a `commitment_signed` applies to after reconnect.
Many thanks to pm47 and roasbeef especially for constructive feedback
which made this far better than I originally had.
Closes: #172
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
