One minor change to refer to field name:
preserves `to_self` delay
to:
preserves `to_self_delay` requirement.
Typo fixes:
1. revocation -> revoke_and_ack
2. ctlv_expiry -> cltv_expiry.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This also converts data structures to the same format used elsewhere.
One other minor change, from:
In addition, every _(address, HMAC)_-pair is incrementally obfuscated at each hop.
to:
In addition, `hops_data` is incrementally obfuscated at each hop.
The old wording was left over from the previous format.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
`channel_update` does not make sense as it does not have fields
with either addresses or ports.
Moved it to `node_announcement` on the assumption that the text
was just inserted in the wrong place, since `node_announcement`
is described before `channel_update` and does have addresses
and ports.
This is a multi-part message in MIME format.
This patch should apply to http://github.com/lightningnetwork/lightning-rfc
Nonidealities:
Aspell triggers spelling errors on the hexadecimal strings in
the test vectors. I don't have enough aspell-fu to figure
out how to make Aspell ignore these.
There are 2 possible pluralizations of `HTLC`: `HTLCs` and
`HTLC's`. I'd prefer the latter, but for now I support both.
We should standardize pluralization; we can edit the
`.aspell.en.pws` file to remove the pluralization we won't
choose.
These test vectors should match BOLT04 after the change to merge
per-hop payloads and routing info into a single `hop_data` field. They
were generated by the golang version and crosschecked with the
`lightningd` version.
The per-hop `hop_data` were changed to be initialized by byte-filling
the `short_channel_id` matching their position in the route, and by
setting the `amt_to_forward` and `outgoing_cltv` fields to the same
value, i.e., for hop 3 the values are:
short_channel_id = 0x0303030303030303
amt_to_forward = 0x0000003
outgoing_cltv = 0x0000003
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>
We didn't note the actual requirements: we MUST reject replays we have forwarded
or paid to avoid replay attacks. The details are difficult however; we have
to clean them out at some stage, and restrict the size somehow. Suggest some
ways we could do that.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
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>
