Olaoluwa Osuntokun [ARCHIVE] on Nostr: 📅 Original date posted:2016-09-09 📝 Original message: Rusty Russell <rusty at ...

📅 Original date posted:2016-09-09
📝 Original message:
Rusty Russell <rusty at rustcorp.com.au> wrote:

> Each node ID is 33 bytes (pubkey) each channel is 6 bytes (blocknum +
txnum).

Using blocknum+txnum to identify a channel doesn't account for the
possibility of a single transaction which opens multiple channels
concurrently. A possible use-case for such a transaction are coin-joined
channel openings which obfuscate the relationships being creating with a
channel opening. You'd need to tack on an extra byte (maybe two) to also
encode the output index of the channel within the transaction. Additionally,
identifying channels based solely from blockheight+offsets conjures up some
re-org safety concerns. It's also a bit less "verifiable" than referring via
the full outpoint.

> The proofs are larger: to prove which IDs owns a channel, each one needs a
> merkle proof (12 x 32 bytes) plus the funding tx (227 bytes, we can skip
> some though), the two pubkeys (66 bytes), and a signature of the ID using
> those pubkeys (128 bytes, schnorr would be 64?).

Are those two pub keys the multi-sig pub keys, or the identity pub keys? In
either case, only requiring two pub keys to attest-to/authenticate the state
of a channel is insufficient. With only two signatures, then nodes can
advertise the same channel several times creating a non-canonical graphs
resulting in differing network views. If we'd like to eliminate such a
possibility, then we also need to cryptographically bind the two identities
to the proof. Using a schnorr multi-signature generated by the four pubkeys
would remedy this. Validators can use pubkey recovery to extract the "group
pubkey" from the single signature, ensure it's the result of point addition
of the four public keys, check the channel isn't closed, then verify the
signature over the advertisement as normal.


Christian Decker <decker.christian at gmail.com> wrote:

> I forgot that we have two potential key-rotations:
> - Rotating the key used in transactions that hit the Bitcoin network

If you mean the key included within the 2-of-2 multi-sig, I assume all
implementations will be using a fresh key with each channel either way, so
we don't need any explicit rotations here?

I've only been thinking of rotations for the onion pubkeys used for the DH
shared secret derivation for the onion packets. Identity keys could also
possibly either be rotated/revoked, or delegated with some sort of
"certificate".

> Another case we could consider is having passive rotations: when an
> endpoint announces a channel's existence it also sends its rotation
> interval along.

IMO a passive rotation scheme is superior due to the bandwidth savings of
pushing the onion key rotations to the edges themselves. As you said an
active rotation might be used in the emergency case of a forced key rotation
due to key compromise.


Rusty Russell <rusty at rustcorp.com.au> wrote:

> Hmm, do we lose forward secrecy if we use a BIP32 chain? But we may be
> able to use another derivation method where we derive key N from key
> N-1. I'm looking at Laolu...

Well, sorta. If the master pubkey is published, and nodes use public
derivation on the edges to do passive key rotations, then if one of the
non-hardened child private keys is leaked, an adversary can derive the
master private key thereby gaining the ability to decrypt any
saved/intercepted onion packets to the compromised node.

Earlier in this email chain I suggested a scheme to regain forward secrecy
in the case of such a private key leak by requiring nodes to do some upfront
pre-computation involving an intermediate derivation point. This would still
allow passive rotation by the edges. However, in practice those
pre-generated would likely be stored in the same location? So that kinda
puts us back at the original exploit scenario.

If we were to involve some pairing crypto (IBE style), we would use say
block hashes to allow nodes to passively derive keys the "source" node is
able to generate the corresponding private key to...

IMO we need to more clearly state our security model/assumptions here to
reason about the attack scenarios we'll try to guard against.


-- Laolu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160909/486374b1/attachment.html>;