The proof-readers rightly noted how confusing the current treatment of
HTLCs is. There are four different cases, but I tried to address them
in two separate sections, with conditionals.
This expands it out, separating sections for Our Commitment Tx and
Their Commitment Tx, then subsections for our HTLCs and their HTLCs
in each one.
It means some duplicated requirements and rationales, but it should now
be very clear.
As a side effect, we no longer refer to A and B at all: it's all US and THEM.
This needs further clearing up, but for now makes it clear what *we* need to do
for all cases.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
second pass copy edit to line 253, according to stylesheet
update node terminology to remove ambiguity; update conventions section and implement consistent usage of terms: origin node, final node, processing node, hop, sending peer, and receiving peer
Some slightly larger scale revisions for BOLT-2, notably including a reorganization of the "open_channel" function with the introduction of two missing arguments.
Also, the addition of MSAT to the glossary in BOLT-0.
I named the first option `option209` but that was too ugly to live.
Nonetheless, this wording lived on.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
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>
It was always going to break when we started adding options, unless we
add padding. As no implementation requires alignment, let's skip it.
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>
