📅 Original date posted:2016-08-13
📝 Original message:
Joseph Poon <joseph at lightning.network> writes:
> Hi Rusty,
>
> Yeah, interesting thoughts!
>
> On Fri, Aug 12, 2016 at 01:17:52PM +0930, Rusty Russell wrote:
>> I still don't understand why use an HMAC-of-tx instead of just the txid?
>> What does it gain?
>
> I'm presuming you need to index by txid to see if there needs to be a
> penalty transaction broadcast, so you can't use that as a secret key.
But SHA256(txid) would be sufficent, no?
(Unless we're happy with 128 bit keys, then just use the upper bits for
hint and lower bits for key).
So, here's a strawman spec (written in cat > style, so includes bugs):
1) We change the protocol slightly to use shachain/elkrem with an
additional SHA256() to get the preimage. On-wire we reveal the leaf
node, which you SHA256() to get the preimage. This makes commit
N-1 unguessable even if you know commit N.
2) Format of message-to-watcher is:
[8-byte-txid-prefix-hint]
[chacha20poly1305 blob, key is SHA256(txid):
[txid-of-previous-commit-or-zero]
[bitcoin signature]
[revocation preimage]
[htlc #1 H-hash ripemd160]
[htlc #1 expiry]
[htlc #2 H-hash ripemd160]
[htlc #2 expiry]
...
[arbitrary zero padding]
]
3) Implementations should pad this out to some reasonable amount to
cover expected HTLCs and avoid revealing too much using size.
Handwave.
4) Implementations should set the txid-of-previous-commit field
sparingly: it saves space for HTLCs which are in multiple commits,
but leaks information. Handwave.
5) Initially watcher would be given commit and timeout keys for both
sides (which I'm assuming are static).
6) Upon seeing a txid prefix match, watcher tries to decrypt. If
success, decrypts previous message-to-watchers as possible using
txid-of-previous-commit-or-zero fields and walking back. Accumulates
all the HTLCs, calculates the wscripts for them, sees which match
outputs. Also look for the one the cheater paid to-self. Generates
transaction that spends all the outputs it can match, checks [bitcoin
signature] is valid, sends tx.
What have I missed?
Rusty.
Rusty Russell [ARCHIVE] /
npub1zw…hkhpx
2023-06-09 12:46:38
in reply to nevent1q…n45l
Author Public Key
npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxPublished at
2023-06-09 12:46:38Event JSON
{
"id": "07a443d0d9156dc62903e9390fc643523763c94a2aee8f93cf174f14f8058bef",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686314798,
"kind": 1,
"tags": [
[
"e",
"ccc2d459792b926854b04bc74e6ea324d2314fff88991806647cc195016ae9ae",
"",
"root"
],
[
"e",
"9140b11092e89aff9cb6c92b1491e8860d70559629fc0f1981aff6831d20763f",
"",
"reply"
],
[
"p",
"ccb4cc87c455b74febaee5929cfd0726421b2eea64ad2b16440b68e8c7433211"
]
],
"content": "📅 Original date posted:2016-08-13\n📝 Original message:\nJoseph Poon \u003cjoseph at lightning.network\u003e writes:\n\u003e Hi Rusty,\n\u003e\n\u003e Yeah, interesting thoughts!\n\u003e\n\u003e On Fri, Aug 12, 2016 at 01:17:52PM +0930, Rusty Russell wrote:\n\u003e\u003e I still don't understand why use an HMAC-of-tx instead of just the txid?\n\u003e\u003e What does it gain?\n\u003e\n\u003e I'm presuming you need to index by txid to see if there needs to be a\n\u003e penalty transaction broadcast, so you can't use that as a secret key.\n\nBut SHA256(txid) would be sufficent, no?\n\n(Unless we're happy with 128 bit keys, then just use the upper bits for\nhint and lower bits for key).\n\nSo, here's a strawman spec (written in cat \u003e style, so includes bugs):\n\n1) We change the protocol slightly to use shachain/elkrem with an\n additional SHA256() to get the preimage. On-wire we reveal the leaf\n node, which you SHA256() to get the preimage. This makes commit\n N-1 unguessable even if you know commit N.\n\n2) Format of message-to-watcher is:\n [8-byte-txid-prefix-hint]\n [chacha20poly1305 blob, key is SHA256(txid):\n [txid-of-previous-commit-or-zero]\n [bitcoin signature]\n [revocation preimage]\n [htlc #1 H-hash ripemd160]\n [htlc #1 expiry]\n [htlc #2 H-hash ripemd160]\n [htlc #2 expiry]\n ...\n [arbitrary zero padding]\n ]\n\n3) Implementations should pad this out to some reasonable amount to\n cover expected HTLCs and avoid revealing too much using size.\n Handwave.\n\n4) Implementations should set the txid-of-previous-commit field\n sparingly: it saves space for HTLCs which are in multiple commits,\n but leaks information. Handwave.\n\n5) Initially watcher would be given commit and timeout keys for both\n sides (which I'm assuming are static).\n\n6) Upon seeing a txid prefix match, watcher tries to decrypt. If\n success, decrypts previous message-to-watchers as possible using\n txid-of-previous-commit-or-zero fields and walking back. Accumulates\n all the HTLCs, calculates the wscripts for them, sees which match\n outputs. Also look for the one the cheater paid to-self. Generates\n transaction that spends all the outputs it can match, checks [bitcoin\n signature] is valid, sends tx.\n\nWhat have I missed?\nRusty.",
"sig": "07f10f54d352adc1faf8da6935bce7468384d2ac173394dc76489ef3bbfdc3db9790baa4261bc3b5fce62b75ab3da97e2629b79bb1bae2cae8f0fe2a0efe6d6c"
}