Mats Jerratsch [ARCHIVE] on Nostr: 📅 Original date posted:2016-01-27 📝 Original message: -----BEGIN PGP SIGNED ...

📅 Original date posted:2016-01-27
📝 Original message:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Great point Rusty, given how many implementations are emerging, we
should press more for compatibility.

Before making comments, just a quick reminder that everyone is invited
in cloning

https://github.com/lightning-core/lightning

and writing up their specifications so others do not have to search
through code, plus separating code from design is good practice. It
will also be easier to commit to them once the discussion is done.



> For this email I'll simply list the changes or proposals I'm aware
> of, then we can dissect and comment on each one: defer, accept or
> close.
I am so free and add changes from TN :)

>
> Direct wire format stuff ------------------------
>
> - Protobufs vs open-coded structures - lnd open-coded their own
> protocol; I haven't finished reading their code though. - protobufs
> are easy to extend with new fields; with an open-coded proto we
> simply need a rule that too-long packets are valid. - protobufs are
> annoying for fixed-length blobs which we use a lot (keys,
> signatures, hashes). - The protocol is currently simple with very
> few variable-length
fields.
- - TN currently is using JSON encoded objects. It is by no standard
efficient, but allows for easy integration of other systems and
it's easy to extend/modify.

Right now I think the open-coded messaging is a bit too much. You
don't get the efficiency of protobufs, nor the readibility of JSON,
but still have to manually code each serialisation/deserialisation,
and each change to the messages has to be carefully inserted into
these functions.

I still don't think JSON is a bad choice for the beginning. If it
actually turns out to be a bottleneck it is a very low-hanging fruit.

I would rather adapt something like protobufs if it comes to it. (I
heard there are other *bufs, maybe some of these serve us better?)


> - Length prefix for initial key exchange - Both lnd and c-lightning
> begin by exchanging a 33-byte EC key
for DH.
> - We should prefix with a length word, so we can extend this later
> (eg. for new crypto)
Agree, same on TN.

Won't new crypto be non-compatibily anyways?

> - Length prefix for other packets - lightning-c sends an 8 byte
> prefix indicating the offset of the
end of
> the current packet: this effectively encodes both length and
ordering.
> - lnd uses a 4 byte network ID, 4 byte type, 4 byte length.
- - TN uses 4 byte length, type is JSON encoded (message types are
completely taken care of of GSON)

I agree that a network ID prefix might make sense. Probably worth
designing for an equivalent of testnet (and they should not just
differ by the standard port they run on... )

>
> - HTLC pipelining - lnd's protocol supports multiple in-flight HTLC
> negotiations; this would allow much greater throughput, with some
> complexity. - lightning-c uses a simple one-at-a-time scheme, with
> alternating priority in case of simultaneous sends.
- - TN allows for adding / settling / refunding arbitrary amount of
HTLCs at the same time.

Agree with lnd here, the complexity is worth it IMO.

> - HTLC abort stage - Setting up a new HTLC involves both sides
> accepting, then revocation message exchange. Currently there's no
> way to abort this process. - Allow the initator to abort any time
> before the revocation exchange, for weird corner cases such as
> timeouts.
- - TN allows for any party to start a new exchange to abort the
current one. I adapted the dice-rolling from CJP, in case both
initiate at the same time.
- - It is important be careful with revocation hashes when aborting.
You don't want the other party to hold on to an unrevoked tx...
>
> - Version bits - If we use an open-coded protocol, initial
> handshake after key setup should exchange two sets of version bits:
> one for compulsory features, one for optional features. You hang
> up if there's a compulsory feature you don't grok.

Good point, agree here.

> Wire protocol crypto -------------------- - Crypto AES/HMAC-SHA256
> or Chacha20/Poly1305 - AES has the word Standard in the name, but
> chacha20 is faster w/o accel (ie. ARM) and almost as widely
> supported.
>
> - Use separate encoding stream for packet lengths - Laolu's
> suggestion; encode the packet lengths as well which makes traffic
> analysis a bit harder. - Makes it a bit harder to detect
> re-transmissions (required on node restart), but probably not
> enough to kill the idea?
>
> Misc ---- - shachain vs elkrem - We use this to generate the
> revocation secrets, to minimize storage and computation for a huge
> number of old commitment txs. - They're actually very similar, but
> elkrem is much easier to grok.[6]

TBD on TN, they both sound solid, I agree with elkrem being easier to
implement.

>
> - Anchor tx renegotiation - We should allow re-anchoring of
> channels, to add or remove funds. - This would allow easy payment
> from lightning channel to normal bitcoin addresses, for example. -
> During transition, signatures for both commit txs must be
> exchanged.

This sounds like a 1.1 feature. Agree that we should allow it, but
does not seem urgent right now.

> - R value vs keypair - Using a simple secret "redeemhash" allows
> easy tracing of transactions through the network. - Mats Jeratsch
> proposed a keypair scheme which decorrelates them[3], Greg Maxwell
> optimized it slightly, and Anthony Towns[4] and Andrew Poelstra
> independently came up with a way to do it without any bitcoin
> mods.

Currently I am using R value, I am still a bit afraid of the lengthy
scripts when doing it without bitcoin mods. Might make sense to just
design the system in a way that it's easy to change later than to
implement it already.

> - Multi-sig txs - Joseph pointed out that by simply allowing more
> than one
signature on
> commit txs[5], we can enable escrow-style services (including
> things like GreenAddress.it which does this for normal wallets).
>
> I'm sure I've missed things; what are they?

Would be great to discuss connection/node failures. TN currently does
not support 'picking up' a lost connection again. I feel like anything
that MUST be finished on resume should rather be saved on hard disk in
advance, designing for various node failure modes.
Restarting a fresh connection seems to be much cleaner for me?

Cheers
- --
Mats Jerratsch
Backend Engineer, Blockchain
e: mats.jerratsch at blockchain.com
PGP: https://pgp.mit.edu/pks/lookup?op=get&search=0x7F3EC6CA
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJWqGslAAoJEAYZmwZ/PsbK5kkP/Rp1tANr8BDVBLRW6VftoEFr
6loMF49SUDvOoc21chem+y/eimnazRWzu6Kvcz19jHPZlDJLz3O+YLL//8QY+9Rc
1ufhNzqy4lQ42Kxqo7wxLQbvaJCL0tlFk/fPjO5pCZY60+FmZQ8MxHemBxRWtNc9
0BpMq5vUlcxC6AcsGtSaFNWVaoP5Y5FLi1InFVDUTfu9Fpko6hczjCu1MRMDk4DO
N6db6MOGyi4NTb2sdEGW89deBzuK/hne9CGw+OH3Fi/+gTIWjmYO6OcSA8mCfqhp
GvSS5CIBn5hzBY0IGd4Y3/KrivSRDfqnBOPUv1Sk9RIdqF+1tePB5u0vlsktM2EN
ZTz/0Ps3pn4PGzKJ76HRE3Qm994rymC9+ulW7f5xLON5ME53owT+GalTJ4oQfhL8
9k9U0gOKbQFdSj1tQbJPsVhK0MbHdj2FQPv+Ky0dkeuO4n9lsrrNOPEfIayyVtis
f9yVJ9dhKLU+U9oqE7pBOAVeYX+eqwJlKeqtsTQLGKuG60KjJav/LanPR8u1kkEX
jZN0hWToMfe9Sgu2dhMXl4L6lMn8KOXQTFNcGr+DDw+OVNc9X4YaaYHzIYLz+uTV
sVL0VTe5ftALGMSYdhYt/i98REQ2+Kd3fzYFUF4QoeepRKdR0HPPaWmtB0XSN4Qi
GrsltMsYqc/a3Zk59Hli
=ODl1
-----END PGP SIGNATURE-----