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>
