The new description introduces the concept of an ephemeral private key,
which I find easier to reason about and suggests a linear instead of
quadratic construction algorithm.
Make it clear what kind of key we're talking about. We use the abbreviation
pubkey for public key (as it's quite common to use in field names), but
generally spell out 'private'.
(I generally prefer 'secret' to 'private' but we use private far more often
already, and we use 'secret' for things which don't directly derive keys).
Fixes: #368
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
I got an unexpected update_fee message after `shutdown` exchange,
which is currently legal:
A: shutdown (no htlcs)
B: receive shutdown
B: reply with shutdown & closing_signed
A: send update_fee & commitment_signed
A: receive shutdown
Simplest to ban any updates (currently, just update_fee) from adding a
new commitment tx while we're at the end of shutdown.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Fixed warnings:
.copy-edit-stylesheet-checklist.md: 49: MD030/list-marker-space Spaces after list markers [Expected: 1; Actual: 0]
.copy-edit-stylesheet-checklist.md: 1: MD041/first-line-h1 First line in file should be a top level header [Context: "Basic checklist/stylesheet use..."]
02-peer-protocol.md: 161: MD018/no-missing-space-atx No space after hash on atx style header [Context: "#7](07-routing-gossip.md#bolt-..."]
So we should use an enumeration, not an unordered list. Same applies to
encryption, decryption and key rotation algorithms.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Our 10-bit length means up to 1023 5-bit words, or 639 bytes. But `h`
is horribly underspecified since we don't have a general solution: using
a URL is a privacy problem, for example. It might make sense for a future
transport standard (eg. lightning over HTML, or lightning-over-NFC), but
it's fairly unusable at the moment.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
I'm clearly showing my age, suggesting ASCII; obviously UTF-8 makes
more sense. We also didn't have a *requirement* that it be a valid
encoding, so add that.
We already have an example ASCII description ('Please consider
supporting this project'), so just modify the other one to UTF-8
as provided by Jonathan.
Reported-by: Jonathan Underwood <junderwood@bitcoinbank.co.jp>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
As agreed at the previous meeting, we use the timestamp to prune,
so it does have to be a valid timestamp. We also suggest ignoring
if it's in the far future, too.
The minutes suggest we can prune for any reason, and that's really
true anyway; the requirements to keep it around are only SHOULD.
Note that this only applies to channel_update: node_announces
are not pruned (except, perhaps, by implication when all channels
are pruned)
Closes: #302
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
