📅 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.
Rusty Russell [ARCHIVE] /
npub1zw…hkhpx
2023-06-09 12:43:43
in reply to nevent1q…m064
Author Public Key
npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxPublished at
2023-06-09 12:43:43Event JSON
{
"id": "b30f0716ae2bc0d91b71ed73d1578429b2eaa25d10a34b9a3631f599e470b514",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686314623,
"kind": 1,
"tags": [
[
"e",
"70bc73032209813d1efbd8c41b490ea29a02fc5941bbed8bed53cf49c33f8564",
"",
"root"
],
[
"e",
"76291144870c97fa127c467f86d9aed52f8e5713bf53ffc091167c4b1232f675",
"",
"reply"
],
[
"p",
"f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab"
]
],
"content": "📅 Original date posted:2015-07-23\n📝 Original message:\nAnthony Towns \u003caj at erisian.com.au\u003e writes:\n\u003e If Alice ever tries cheating, and publishes and old commitment:\n\u003e\n\u003e 800 Alice + DELAY | #Alice_42 + Bob\n\u003e 200 Bob\n\u003e\n\u003e Then Bob needs to work out which of the 100 Alice_N hashes he knows or can\n\u003e work out is being abused; prior to the DELAY expiring. With millions of\n\u003e transactions that could be a bunch of hash calculations or a 100MB lookup\n\u003e table. Might make more sense to have a dummy output of \"0: OP_RETURN 42\" to\n\u003e make that calculation trivial though? That could trivially be verified as\n\u003e part of the \"forms hash chain as expect\" and \"txn structure\" checks.\n\nIt might be millions. What happens is Bob sees the anchor being spent,\nchecks if it's the latest commitment transaction. It's not, so does a\nbackwards search to find the revocation key.\n\nThe time taken for that search is O(N), where N is the current\ncommitment transaction number. But measurements on my laptop show that\n1M transactions takes 5.4 seconds (see benchmark below), so I don't\nthink it's worth optimizing this \"never happens\" case.\n\n\u003e HTLCs are harder if you assume pay2scripthash is used though. If Alice\n\u003e published:\n\u003e\n\u003e 100 Alice + Delay | #Alice_55 + Bob\n\u003e 100 Bob\n\u003e 200 R1 + Alice + DELAY | Bob + TIMEOUT1 | #Alice_55 + Bob\n\u003e 200 R2 + Alice + DELAY | Bob + TIMEOUT2 | #Alice_55 + Bob\n\u003e 200 R3 + Alice + DELAY | Bob + TIMEOUT3 | #Alice_55 + Bob\n\u003e 200 R4 + Alice + DELAY | Bob + TIMEOUT4 | #Alice_55 + Bob\n\u003e\n\u003e well after R1..R4 were known and Alice_55 was revealed in order to try\n\u003e stealing most of the channel's funds, I think Bob could only claim the\n\u003e final outputs if he could unhash the scripts, which would require having\n\u003e remembered R1..R4 even after those contracts had long been resolved. I\n\u003e guess it could be feasible in that case to have the extra output be \"0:\n\u003e OP_RETURN 42 #R1 #R2 #R3 #R4\"?\n\nGood point! With p2sh you need to know the R hash values and timeouts\nto spend the output (40 bytes). Since OP_RETURN is length-limited to 80\nbytes, you can't fit more than 2.\n\nAnd if the HTLC outputs are not P2SH, they're non-standard and won't be\nrelayed.\n\nWhat else can we come up with?\n\nThanks,\nRusty.\n\n\u003e [2] (Unattached footnote) This project's motto is \"The lightning network:\n\u003e it's off the chain!\" right?\n\u003e http://www.urbandictionary.com/define.php?term=off+the+chain\n\nErr.... Yeah. It's spelled \"caching layer for bitcoin\" but it's\npronounced just like that.",
"sig": "e90067efa2d02f233fa64c7c8367e278bdfc6e3e2475973454a744057846f1e31c8557044c3d9f3f00c1e08000445ed0398531ef8ed62ac6f033181f4668fe63"
}