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>
This commit adds a `chain-hash` field to message that commences a
funding workflow. This field is used to specify a _target_ chain for the
proposed channel. In order to uniquely identity blockchains in a manner
that doesn't require strict coordination between developers, the genesis
hash of the target chain is used. For channels opened on the Bitcoin
blockchain, the `chain-hash` field should _always_ be set to:
000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f.
Introducing this new field _immediately_ allows nodes within the network
to open a channel within any Satoshi-derived blockchain. Nodes can have
channels open across different blockchains globally, but also have many
channels open across distinct blockchains with the same peer.
As per discussion in #115, we now allow `shutdown` immediately following
`commitment_signed`.
This means that revoke-and-ack doesn't *always* ack the shutdown. Rather
than specify that a revoke-and-ack which is caused by an update-commit
following the shutdown acknowledges, we leave this unacknowledged until
we actually start closing.
This means we will retransmit it on every reconnect until then. But
that's not all that wasteful, and fairly robust.
Suggested-by: Pierre-Marie Padiou <pm.padiou@gmail.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Using the receiver's dust limit implies a naive node can be fooled
(by a peer with massive dust limit) into not getting its own output.
Using our own opens the possibility of creating different transactions,
so we explicitly allow the tractable case, while accepting failure on
the case where disagreement is real.
Closes: #128
Reported-by: Pierre-Marie Padiou
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We can no longer allow 511 each way; reduce it to match our calculations
so we can always create a single standard penalty transaction.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
At cost of a few extra bytes between peers, this avoids the whole "oops, we were on a chain fork" problem, and simplifies generation of temporary channel-ids (just pick a random one).
Now we move the announcement_signature exchange to at least 6 confirms, which makes re-xmit tricky; I resolved that by insisting on reconnect that we send if we haven't received, and reply to the first one.
The term "channel shortid" wasn't used anywhere, so I removed it; it's now a gossip-only thing anyway.
One subtle change: pkt_error on unknown channels is now "MUST ignore"; this section was reworked anyway, and we'll want this if the #120 goes through, where one side might have forgotten unformed channels).
Closes: #114
Suggested-by: Olaoluwa Osuntokun <laolu32@gmail.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
* FIXUP! Two bytes for funding-output-index.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
* FIXUP! Channel-id rework, temp ids, 32 bits only.
Re-add the idea of temporary channel ids: far simpler since they're now
big enough we can just fill with noise.
Remove the alignment issues by combining txid and outnum using XOR; we
could reduce to 128 bit if we really wanted to, but we don't.
Error handling is now simple again, but while editing I changed the
behaviour for unknown channels to MUST ignore (this is important for
Change the 8-byte gossip channel id to `short-channel-id`.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
* FIXUP! Minor text tweaks from Pierre-Marie and Christian
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
* BOLT 2&7: Cleaner separation of concerns wrt announcement signatures
So far we did not have any indication on what to do if a node does not
allow announcing the channel and we had a mix of concerns in the
`funding_locked` message, which would also transfer the signatures
needed for the announcement. This is a proposal about splitting the
signatures into their own message, so that simple omission is an
opt-out of announcements, and it does not mix announcement/gossip
stuff into the peer-protocol.
(It also ended up adding a localfeatures flag to opt-into the channel-announcement, and thus creating BOLT 9)
Olaoluwa pointed out that peers can make work for us by starting to open
connections then disconnecting: we need to allow timeouts, since it's
the simplest solution.
The comment about remembering `r` values (ie. `payment-preimage`) from
update_fulfill_htlc was also vague: it was meant to simply note that
it's not completely reversible, since the knowledge is (and probably
should be!) used to fulfill an incoming HTLC.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
1) Make it clear that `init` needs to be sent every time.
- This means if you upgrade and no longer support an old connection, it's
clear, plus it simplifies the question of re-transmission of `init`.
2) Spell out the retransmission requirements for reconnection.
- We agreed in Milan to simply use retransmit and ignore-dups.
- This needs actual testing by implementations, but this is my best guess
on exactly how far back to retransmit.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
