Anthony Towns [ARCHIVE] on Nostr: 📅 Original date posted:2015-07-23 📝 Original message: Hi *, For my own ...
📅 Original date posted:2015-07-23
📝 Original message:
Hi *,
For my own understanding I've been trying to work out what the lightning
protocol looks like at a network-protocol level. I think the following
works, maybe it's interesting for others:
For notational convenience I'm going to just list the secrets that need to
be known to use to spend an output. "Alice" and "Bob" are Alice and Bob's
respective keys, Alice_N and Bob_N are the Nth numbers in shachain
sequences [0]. I'm using TIMEOUT for the checktimelockverify construction;
DELAY for the checksequenceverify construction.
Assume Alice and Bob already have a channel setup. Then their current
commitments might be:
Alice's commitment txn: (fully signed)
500 Alice + DELAY | #Alice_101 + Bob
500 Bob
Bob's commitment txn: (fully signed)
500 Alice
500 Bob + DELAY | #Bob_101 + Alice
Alice knows the hash of #Bob_101 and Bob knows the hash of #Alice_101
(because they've respectively seen the full txns to sign them).
If Alice wants to update the channel to reflect a conditional payment from
Bob once R is revealed, they can follow the following steps:
1) Alice proposes: (unsigned)
500 Alice + DELAY | #Alice_102 + Bob
400 Bob
100 R + Alice + DELAY | Bob + TIMEOUT | #Alice_102 + Bob
[1]
Bob checks: txn structure, amounts, R, Bob key is correct
Bob stores the hash of #Alice_102
2a) Bob declines; proposal never happened
2b) Bob approves, replies:
signing Alice's proposal
requesting sig of:
500 Alice
400 Bob + DELAY | #Bob_102 + Alice
100 R + Alice | Bob + TIMEOUT + DELAY | #Bob_102 + Alice
Alice checks: signature, txn structure, amounts, R, Alice key is correct
Alice signs and stores new txn.
Alice stores the hash of #Bob_102
3) Alice discards old commitment txn.
Alice replies:
signing Bob's transaction
revealing Alice_101
Bob checks: signature,
Alice_101 hashes correctly (ie matches the hash of #Alice_101, stored
previously),
Alice_101 forms hash chain with prior secrets (Alice_100, Alice_99..)
as expected
Bob signs and stores his new commitment txn
Bob discards the hash of #Alice_101.
4) Bob discards old commitment txn
Bob replies:
revealing Bob_101
Alice checks:
Bob_101 hashes correctly (ie #Bob_101 does clear the old txn),
Bob_101 forms hash chain with prior secrets (Bob_100, Alice_99..) as
expected
Alice discards the hash of #Bob_101
If the protocol follows through to completion, then they each have
matching, updated, signed commitment transactions; along with the secrets
necessary to void attempts to use older commitments. If the protocol goes
off track (checks fail, or no response from partner within a protocol
timeout), then either party can safely close the channel after any step:
Alice can close at (500/500) up until step (3)
Alice can close at (500/400/100) after step (2b)
Bob can close at (500/500) up until step (4)
Bob can close at (500/400/100) after step (3)
If Alice ever tries cheating, and publishes and old commitment:
800 Alice + DELAY | #Alice_42 + Bob
200 Bob
Then Bob needs to work out which of the 100 Alice_N hashes he knows or can
work out is being abused; prior to the DELAY expiring. With millions of
transactions that could be a bunch of hash calculations or a 100MB lookup
table. Might make more sense to have a dummy output of "0: OP_RETURN 42" to
make that calculation trivial though? That could trivially be verified as
part of the "forms hash chain as expect" and "txn structure" checks.
HTLCs are harder if you assume pay2scripthash is used though. If Alice
published:
100 Alice + Delay | #Alice_55 + Bob
100 Bob
200 R1 + Alice + DELAY | Bob + TIMEOUT1 | #Alice_55 + Bob
200 R2 + Alice + DELAY | Bob + TIMEOUT2 | #Alice_55 + Bob
200 R3 + Alice + DELAY | Bob + TIMEOUT3 | #Alice_55 + Bob
200 R4 + Alice + DELAY | Bob + TIMEOUT4 | #Alice_55 + Bob
well after R1..R4 were known and Alice_55 was revealed in order to try
stealing most of the channel's funds, I think Bob could only claim the
final outputs if he could unhash the scripts, which would require having
remembered R1..R4 even after those contracts had long been resolved. I
guess it could be feasible in that case to have the extra output be "0:
OP_RETURN 42 #R1 #R2 #R3 #R4"?
Cheers,
aj
[0] It's easy to calculate Alice_N given Alice_M for some M > N, but
unfeasible for any M < N.
[1] I don't understand the construction for HTLCs in 0.5.9 of the
lightning paper; what I'm doing instead is taking an underlying output of
"Alice + R | Bob + TIMEOUT" and mapping it through "my key becomes my key +
DELAY" + "they get everything with my secret sequence and their key". I'll
post about that separately so it can get shot down :)
[2] (Unattached footnote) This project's motto is "The lightning network:
it's off the chain!" right?
http://www.urbandictionary.com/define.php?term=off+the+chain
--
Anthony Towns <aj at erisian.com.au>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150723/b330b01a/attachment.html>;
📝 Original message:
Hi *,
For my own understanding I've been trying to work out what the lightning
protocol looks like at a network-protocol level. I think the following
works, maybe it's interesting for others:
For notational convenience I'm going to just list the secrets that need to
be known to use to spend an output. "Alice" and "Bob" are Alice and Bob's
respective keys, Alice_N and Bob_N are the Nth numbers in shachain
sequences [0]. I'm using TIMEOUT for the checktimelockverify construction;
DELAY for the checksequenceverify construction.
Assume Alice and Bob already have a channel setup. Then their current
commitments might be:
Alice's commitment txn: (fully signed)
500 Alice + DELAY | #Alice_101 + Bob
500 Bob
Bob's commitment txn: (fully signed)
500 Alice
500 Bob + DELAY | #Bob_101 + Alice
Alice knows the hash of #Bob_101 and Bob knows the hash of #Alice_101
(because they've respectively seen the full txns to sign them).
If Alice wants to update the channel to reflect a conditional payment from
Bob once R is revealed, they can follow the following steps:
1) Alice proposes: (unsigned)
500 Alice + DELAY | #Alice_102 + Bob
400 Bob
100 R + Alice + DELAY | Bob + TIMEOUT | #Alice_102 + Bob
[1]
Bob checks: txn structure, amounts, R, Bob key is correct
Bob stores the hash of #Alice_102
2a) Bob declines; proposal never happened
2b) Bob approves, replies:
signing Alice's proposal
requesting sig of:
500 Alice
400 Bob + DELAY | #Bob_102 + Alice
100 R + Alice | Bob + TIMEOUT + DELAY | #Bob_102 + Alice
Alice checks: signature, txn structure, amounts, R, Alice key is correct
Alice signs and stores new txn.
Alice stores the hash of #Bob_102
3) Alice discards old commitment txn.
Alice replies:
signing Bob's transaction
revealing Alice_101
Bob checks: signature,
Alice_101 hashes correctly (ie matches the hash of #Alice_101, stored
previously),
Alice_101 forms hash chain with prior secrets (Alice_100, Alice_99..)
as expected
Bob signs and stores his new commitment txn
Bob discards the hash of #Alice_101.
4) Bob discards old commitment txn
Bob replies:
revealing Bob_101
Alice checks:
Bob_101 hashes correctly (ie #Bob_101 does clear the old txn),
Bob_101 forms hash chain with prior secrets (Bob_100, Alice_99..) as
expected
Alice discards the hash of #Bob_101
If the protocol follows through to completion, then they each have
matching, updated, signed commitment transactions; along with the secrets
necessary to void attempts to use older commitments. If the protocol goes
off track (checks fail, or no response from partner within a protocol
timeout), then either party can safely close the channel after any step:
Alice can close at (500/500) up until step (3)
Alice can close at (500/400/100) after step (2b)
Bob can close at (500/500) up until step (4)
Bob can close at (500/400/100) after step (3)
If Alice ever tries cheating, and publishes and old commitment:
800 Alice + DELAY | #Alice_42 + Bob
200 Bob
Then Bob needs to work out which of the 100 Alice_N hashes he knows or can
work out is being abused; prior to the DELAY expiring. With millions of
transactions that could be a bunch of hash calculations or a 100MB lookup
table. Might make more sense to have a dummy output of "0: OP_RETURN 42" to
make that calculation trivial though? That could trivially be verified as
part of the "forms hash chain as expect" and "txn structure" checks.
HTLCs are harder if you assume pay2scripthash is used though. If Alice
published:
100 Alice + Delay | #Alice_55 + Bob
100 Bob
200 R1 + Alice + DELAY | Bob + TIMEOUT1 | #Alice_55 + Bob
200 R2 + Alice + DELAY | Bob + TIMEOUT2 | #Alice_55 + Bob
200 R3 + Alice + DELAY | Bob + TIMEOUT3 | #Alice_55 + Bob
200 R4 + Alice + DELAY | Bob + TIMEOUT4 | #Alice_55 + Bob
well after R1..R4 were known and Alice_55 was revealed in order to try
stealing most of the channel's funds, I think Bob could only claim the
final outputs if he could unhash the scripts, which would require having
remembered R1..R4 even after those contracts had long been resolved. I
guess it could be feasible in that case to have the extra output be "0:
OP_RETURN 42 #R1 #R2 #R3 #R4"?
Cheers,
aj
[0] It's easy to calculate Alice_N given Alice_M for some M > N, but
unfeasible for any M < N.
[1] I don't understand the construction for HTLCs in 0.5.9 of the
lightning paper; what I'm doing instead is taking an underlying output of
"Alice + R | Bob + TIMEOUT" and mapping it through "my key becomes my key +
DELAY" + "they get everything with my secret sequence and their key". I'll
post about that separately so it can get shot down :)
[2] (Unattached footnote) This project's motto is "The lightning network:
it's off the chain!" right?
http://www.urbandictionary.com/define.php?term=off+the+chain
--
Anthony Towns <aj at erisian.com.au>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150723/b330b01a/attachment.html>;