Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2015-07-23 📝 Original message: Anthony Towns <aj at ...
📅 Original date posted:2015-07-23
📝 Original message:
Anthony Towns <aj at erisian.com.au> writes:
> 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.
It might be millions. What happens is Bob sees the anchor being spent,
checks if it's the latest commitment transaction. It's not, so does a
backwards search to find the revocation key.
The time taken for that search is O(N), where N is the current
commitment transaction number. But measurements on my laptop show that
1M transactions takes 5.4 seconds (see benchmark below), so I don't
think it's worth optimizing this "never happens" case.
> 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"?
Good point! With p2sh you need to know the R hash values and timeouts
to spend the output (40 bytes). Since OP_RETURN is length-limited to 80
bytes, you can't fit more than 2.
And if the HTLC outputs are not P2SH, they're non-standard and won't be
relayed.
What else can we come up with?
Thanks,
Rusty.
> [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
Err.... Yeah. It's spelled "caching layer for bitcoin" but it's
pronounced just like that.
📝 Original message:
Anthony Towns <aj at erisian.com.au> writes:
> 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.
It might be millions. What happens is Bob sees the anchor being spent,
checks if it's the latest commitment transaction. It's not, so does a
backwards search to find the revocation key.
The time taken for that search is O(N), where N is the current
commitment transaction number. But measurements on my laptop show that
1M transactions takes 5.4 seconds (see benchmark below), so I don't
think it's worth optimizing this "never happens" case.
> 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"?
Good point! With p2sh you need to know the R hash values and timeouts
to spend the output (40 bytes). Since OP_RETURN is length-limited to 80
bytes, you can't fit more than 2.
And if the HTLC outputs are not P2SH, they're non-standard and won't be
relayed.
What else can we come up with?
Thanks,
Rusty.
> [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
Err.... Yeah. It's spelled "caching layer for bitcoin" but it's
pronounced just like that.