This is particularly important if people start overpaying: a hop
may try to deduct 1 extra millisatoshi, which would be rejected by the
next unless the next is the final hop, enabling detection.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Not doing this check means an inconsistency in behaviour, which could
theoretically allow a hop to probe: if the next hop is the last, it might
not care, but if it's not it will return an error.
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>
Connections between nodes within the network may be very long lived as
payment channels have an indefinite lifetime. However, it’s likely that
for a significant portion of the life-time of a connection, no new data
will be exchanged. Additionally, on several platforms it’s possible that
Lightning clients will be put to sleep without prior warning. As a
result, we use a distinct ping message in order to probe for the
liveness of the connection on the other side, and also to keep the
established connection active.
This commit adds two new control messages to the protocol: `ping` and
`pong`. Their usage within the network is similar to the usage of such
message within other established protocols: `ping` messages specify a
number of bytes to be contained in the payload of a `pong` message, and
`pong` messages are to be sent in response to receiving a `ping` message.
Additionally, the ability for a sender to request that the receiver send
a response with a particular number of bytes enables nodes on the
network to create synthetic traffic. Such traffic can be used to
partially defend against packet and timing analysis as nodes can fake
the traffic patterns of typical exchanges, without applying any true
updates to their respective channels.
When combined with the onion routing protocol defined in BOLT#4, careful
statistically driven synthetic traffic can serve to further bolster the
privacy of participants within the network.
As a bonus, the usage of periodic `ping` message ensures frequent key
rotation between connected nodes.
[ The result is a bikeshed of every possible color! -- RR ]
The idea of the "SHOULD fail if amount is too much" was courtesy against
overpaying, but that's a bad idea of you value privacy and some vendor has
well-known prices. Allow a factor of two, at least.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
As per ElementsProject/lightning#134 Fabrice points out that to calculate
our own commitment tx, we use the *other* side's revocation basepoint:
The revocationkey is a blinded key: the remote node provides the base,
and the local node provides the blinding factor which it later
reveals
Thus, we fix the test vectors by renaming "local_revocation_basepoint"
to "remote_revocation_basepoint", which is what we should be using.
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 didn't update it for 394da29189
"BOLT 3: fix test vector derivation."
This doesn't actually change any results, just fixes an intermediate
calculation.
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>
This means more bytes if we need to create a penalty tx, but less for
normal operation:
Witness script for offered htlcs: 139 bytes -> 133 bytes.
Witness script for accepted htlcs: 156 bytes -> 139 bytes.
It's also a little simpler; it's just an OP_IF around the old scripts
to test for the revocation key being the top arg.
Suggested-by: Joseph Poon <joseph@lightning.network>
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>
The weights of HTLCs were corrected by Pierre in "fixed htlc weight
calculation": this adjusts the test vectors to match.
This also means that the feerate thresholds change.
In addition, this fixes feerate on "maximum feerate" tests,
and corrects the fee for the htlc-timeout tx.
Reported-by: Fabrice Drouin <fabrice.drouin@acinq.fr>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The test vectors themselves were fine, but they're supposed to be derived
from known basepoints (and I was actually testing this with some new code).
I accidentally used the *remote* per-commitment-point, instead of the *local*
per-commitment-point to derive the remotekey/remote_privkey; since we are
generating the local transaction, this is wrong. We don't need to know
the remote per-commitment-point at all, in fact.
Thus, the remotekey (and signatures) in the test vectors change.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Christian assumed first bit was 1, I assumed 0. And we should generally
assign in pairs (so an optional understanding can later become compulsory),
though for the initial draft it's unnecessary.
By giving names we avoid smearing values over the spec, containing them in
BOLT 9.
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)
This is a smerge of Fabrice Drouin and my work: he update them, I updated them and enhanced them, he found bugs, I re-derived them, etc.
- rename keys properly
- fix fees
- sign all transactions
- Derive test transaction vectors from minimal subset of parameters.
- rewrite test vectors to test edge cases for trimming.
- add funding tx test vector, make testable on regtest.
This adds a funding transaction test (really, we only specify the output), but importantly adds enough information to duplicate a blockchain with that particular funding tx:
$ rm -rf ~/.bitcoin/regtest/
$ bitcoind -regtest=1 &
$ bitcoin-cli -regtest=1 submitblock 0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910fadbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fdc30f9858ffff7f20000000000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0100f2052a010000001976a9143ca33c2e4446f4a305f23c80df8ad1afdcf652f988ac00000000
$ bitcoin-cli -regtest=1 generate 431
$ bitcoin-cli -regtest=1 sendrawtransaction 0200000001adbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fd000000006b48304502210090587b6201e166ad6af0227d3036a9454223d49a1f11839c1a362184340ef0240220577f7cd5cca78719405cbf1de7414ac027f0239ef6e214c90fcaab0454d84b3b012103535b32d5eb0a6ed0982a0479bbadc9868d9836f6ba94dd5a63be16d875069184ffffffff028096980000000000220020c015c4a6be010e21657068fc2e6a9d02b27ebe4d490a25846f7237f104d1a3cd20256d29010000001600143ca33c2e4446f4a305f23c80df8ad1afdcf652f900000000
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
