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>
It *is* 2R+G+S, which is 7, not six. It's also identical to the previous one,
so just say that.
Reported-by: Shannon Appelcline <shannona@skotos.net>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
update stylesheet to reflect appropriate structure of Requirement sub-items and format of digits, numerations, and quantities;
copy edit BOLTs 0,1,2 to adhere to these changes;
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>
This is the best I could come up with. You can't know future
revocation secrets, so if you send onw I know you're ahead of me
somehow. That means I *MUST NOT* broadcast my latest commitment
transaction, but at least if you're not malicious I'll salvage
something.
We adapt BOLT 5 in a fairly trivial way to specify to say you should
try to handle as much as you can (in fact, you should always be able
to collect their commitment transaction's direct-to-you output).
Fixes: #209
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Complete rewrite, including a routing example and the new
min_final_cltv expirt. I hope this makes it clear.
(Thanks to everyone who reviewed and gave feedback; you rock!)
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
1. We say you can't fail an HTLC until it's removed outgoing; make it clear
that this could also be on-chain.
2. Insist that you fail an expired HTLC (we never actually said this!)
3. You MUST fulfill an incoming HTLC for which the output was fulfilled
(otherwise you'll lose money), and of course, even if fulfilled on-chain.
Add an explanation paragraph to BOLT 5 as well, where it discusses on-chain
HTLC output cases (though the requirements about what to do about incoming
HTLCs is actually in BOLT 2).
[ Extra wording clarification thanks to roasbeef ]
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit modifies the glossary to add a new entry which defines the
usage of `chain_hash` throughout the remainder of the documents.
Additionally, we now also specify which chain hash we expect for
Bitcoin within the glossary.
This commit also modifies BOLT #2 and #7 to omit the definition of the
expected `chain_hash` value for Bitcoin.
1. Change descriptions of closing tx construction to references to BOLT 3.
2. Recipient *should* check the fee offer has improved in closing_signed.
3. Therefore, sender *must* improve closing offer.
4. Offers do not persist across reconnection, so no state req'd, and
also helps if fee has changed.
5. You don't need to re-send `shutdown` if you received `closing_signed`
(implicit acknowledgement).
6. You don't have to accept a `channel_reestablish` which requests the last
revoke_and_ack be retransmitted if you've already received `closing_signed`
(which is an implicit acknowledgement).
Closes: #201Closes: #199
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The actual fee of the final tx may include eliminated outputs, which can
differ between one side and the other (since they have different thresholds).
Simplify this corner case by using our base fee calculation as the upper bound;
it should be close enough we don't care, but disagreement here could cause
negotiation breakdown.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
You can't eliminate an output and also guarantee a certain fee, so
we need to define exactly how to do this.
Since the output is (presumably) dust, we might as well just discard it
(effectively increasing the fee). This avoids the peer directly benefiting
from the elimination as well.
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>
We can't do that, so allow "write, then send". That fails on the side of
timing out, rather than having a channel which can't be used.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit gives peers the ability to signal their intent to make a
channel private in the `open_channel` message. This differs from the
current method as now peers are able to create multiple channels with
heterogeneous announcement policies _without_ disconnecting and
re-connecting in-between each channel funding. The prior requirement
for the nodes to re-connect was burdensome and unnecessary.
[ Minor tweaks from feedback folded in -- RR ]
This commit modifies the “Normal Operation” summarization by including
a link to BOLT #7 when mentioning the `announcement_signature` message.
Previously a reader would need to search other documents to figure out
what an `announcement_signature` was, and its purpose.
We had 4 byte fields for amounts because people have no ability to assess
risk, and this limited the damage to $70 at a time.
But then that means $1 maximum HTLCs on Litecoin, which isn't enough
for a cup of (decent) coffee.
Rather than have boutique hacks for Litecoin we enlarge the fields now,
and simply have a bitcoin-specific restriction that the upper 4 bytes be 0.
The ctlv_expiry field is moved down in update_add_htlc, to preserve alignment.
Suggested-by: Olaoluwa Osuntokun <laolu32@gmail.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
1. Tell the node when to broadcast the funding tx (we didn't do this!).
2. Allow timeouts generally if no progress is made (originally this
was just when waiting for funding_locked, but it applies generally).
3. Use `funding_signed` as the commitment point: before this, we forget,
after this, we remember. If lost, we'll timeout.
4. The core of the retransmission requirements now only applies to
the normal and shutdown states, and will be revised separately
depending on #172
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit fixes an advisory error in the current spec draft. We
currently use `fee-per-kw` where `kw = 1000` weight to determine the
proper fee to pay for commitment transactions. Currently, the spec
advises implementer to take the typical sat/Kb at _multiply_ by 4. This
will result in implementations overpaying for commitment transactions
as the scaling should actually be in the _opposite_ direction. As the
weight is scaled up by 4, for fee-per-kw should be scaled down by 4.
So: sat/Kb * 1/4, instead of sat/Kb * 4.
[Minor fixup: "1/4th" to "1/4", better english, and doesn't trip spellcheck. -- RR]
Plus a few more missing ones, and some consistency fixes in names
as pointed out by Roasbeed and Fabrice.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
1. Only one per-hop thing, called `per-hop`, or `hops_data` when in aggregate.
2. Move HMAC to the end of stuff it covers, both of the packet itself, and the per-hop.
3. Use `channel-id` instead of RIPEMD(nodepubkey).
4. Use 4 byte amounts.
5. This is all for realm "0", we can have future realms. We also have 16
bytes of unused padding.
6. No longer need the `gamma` key, but document the `_um_` key used for
errors.
7. Use normal 32-byte HMAC, not truncated 20-bytes, which more than eats
up the room we saved.
The result is that the onion is now 1366 not 1254 bytes, but simpler.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
`channel-id` which identifies , which is derived
=>
`channel-id` to identify the channel, which is derived
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
It was never mentioned, but fulfilling a timedout HTLC means a race
between timing out and fulfilling, which is bad.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
