* 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.
It turns out everyone does `P[B / 8] ^= (1 << (P % 8))`,
which is not what the spec says to do (it implies you
would treat P as a bitstring numbered 255 to 0).
See this stackoverflow question:
https://stackoverflow.com/questions/49928131/lightning-secret-generation-from-seed
Reported-by: Janus Troelsen @ysangkok (on Twitter)
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
* 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>
We added a requirement on the writer, not the reader. We can't really add
a test vector without a new requirement, though.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
One for uppercase, and one with should-be-ignored fields.
The first of these addresses #659 (#677 directly changes the text
to make it clear this is allowed, and should also be applied).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The introductory paragraph describes node discovery and channel
discovery, but changes the ordering. Keep the same ordering throughout
the paragraph for readability.
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.
* Rename `complete` flag to `full_information` and provide rationale
This was confusing: the flag name made implementers *think* they
knew what it was for.
* Insist that reply_channel_range be adjacent and ordered
The current loose constraints causes confusion (and now all major
implementations meet the stricter requirements anyway).
You are allowed to provide more blocks than requested, but you have
to be complete and in order, and each reply has to have some overlap
with the requested range.
Its not uncommon to be multi-homed with different addresses, so we should probably allow nodes to do this. Also, it seems like this is pretty much universally not actually enforced on the network.
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
