Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2016-08-09 📝 Original message: Joseph Poon <joseph at ...
📅 Original date posted:2016-08-09
📝 Original message:
Joseph Poon <joseph at lightning.network> writes:
> On Wed, Aug 10, 2016 at 06:36:11AM +0930, Rusty Russell wrote:
>> Yes, I think we agree some "filter hint" is needed to avoid a crazy
>> amount of outsourcing work (eg. first 8/16 bytes of txid). I don't
>> think an HMAC check per registered commitment is quite fast enough.
>
> For #1, the HMAC would be pre-computed by the outsourcer. So the flow
> looks like:
>
> 1. The outsourcer takes the txid, HMAC(txid+salt1) and encrypts the blob
> 2. The outsourcer gives the 32-byte hmac and blob to the watcher
> 3. The watcher adds the 32-byte hmac and the blob to a key-value store
> (the watcher can optionally truncate or whatever)
> 4. When the watcher receives a new block, they HMAC(txid+salt1) all
> transactions and compare against the key-value store
Ah OK! I am in sync now, sorry for the noise!
>> If we include the witness in that HMAC we risk reintroducing
>> malleability. If we don't, we risk txs being predictable.
>
> I was referring to the non-witness txid when making that comment, but
> there should be sufficient entropy from the revocation hash (whose P2WSH
> is part of the Commitment outputs).
Unfortunately, watcher knows revocation preimage N, so it can figure out
some or all previous revocation preimages (and thus hashes). That's
true with shachain, and I think elkrem has similar properties (it's kind
of what we were after!).
>> I can think of a few fixes: insert some randomness in the tx (OP_RETURN?
>> Different addresses each time?), or try to extract the input signature
>> from the witness, which is unguessable, as our filter?
>
> Yeah! I like this idea to use one's own input sig as the key for the
> encrypted blob too. If Alice is the one outsourcing the Commitment which
> Bob can broadcast, Bob can only broadcast it using the sig Alice gave
> Bob as it's spending from a 2-of-2. If Alice is outsourcing Bob's
> Commitment broadcasts, a hash of her input signature is a solid way to
> derive a key as well without malleability concerns.
But it rests on the assumption that there are no unknown malleability
issues on signatures, which I believe makes crypto people nervous. I've
asked some, though, as that's above my pay grade!
It also assumes they can't set up the witness such that our sig is not
2nd or 3rd in the witness element. I think that's true...
> I also like that it "encourages" more nodes to download witness data;
> ignoring witnesses is a concern of mine which this helps with :^)
Good point!
Cheers,
Rusty.
Published at
2023-06-09 12:46:37Event JSON
{
"id": "4ecfe21b16d35c7fcb536acf629f0c7c7b804a1e5c3b803846fecdffc2e49bde",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686314797,
"kind": 1,
"tags": [
[
"e",
"ccc2d459792b926854b04bc74e6ea324d2314fff88991806647cc195016ae9ae",
"",
"root"
],
[
"e",
"2518faa829a52853038346e414f3f9dd10b6aae14e54a188f4d186cf600fd4b8",
"",
"reply"
],
[
"p",
"ccb4cc87c455b74febaee5929cfd0726421b2eea64ad2b16440b68e8c7433211"
]
],
"content": "📅 Original date posted:2016-08-09\n📝 Original message:\nJoseph Poon \u003cjoseph at lightning.network\u003e writes:\n\u003e On Wed, Aug 10, 2016 at 06:36:11AM +0930, Rusty Russell wrote:\n\u003e\u003e Yes, I think we agree some \"filter hint\" is needed to avoid a crazy\n\u003e\u003e amount of outsourcing work (eg. first 8/16 bytes of txid). I don't\n\u003e\u003e think an HMAC check per registered commitment is quite fast enough.\n\u003e\n\u003e For #1, the HMAC would be pre-computed by the outsourcer. So the flow\n\u003e looks like:\n\u003e\n\u003e 1. The outsourcer takes the txid, HMAC(txid+salt1) and encrypts the blob\n\u003e 2. The outsourcer gives the 32-byte hmac and blob to the watcher\n\u003e 3. The watcher adds the 32-byte hmac and the blob to a key-value store\n\u003e \t(the watcher can optionally truncate or whatever)\n\u003e 4. When the watcher receives a new block, they HMAC(txid+salt1) all\n\u003e transactions and compare against the key-value store\n\nAh OK! I am in sync now, sorry for the noise!\n\n\u003e\u003e If we include the witness in that HMAC we risk reintroducing\n\u003e\u003e malleability. If we don't, we risk txs being predictable.\n\u003e\n\u003e I was referring to the non-witness txid when making that comment, but\n\u003e there should be sufficient entropy from the revocation hash (whose P2WSH\n\u003e is part of the Commitment outputs).\n\nUnfortunately, watcher knows revocation preimage N, so it can figure out\nsome or all previous revocation preimages (and thus hashes). That's\ntrue with shachain, and I think elkrem has similar properties (it's kind\nof what we were after!).\n\n\u003e\u003e I can think of a few fixes: insert some randomness in the tx (OP_RETURN?\n\u003e\u003e Different addresses each time?), or try to extract the input signature\n\u003e\u003e from the witness, which is unguessable, as our filter?\n\u003e\n\u003e Yeah! I like this idea to use one's own input sig as the key for the\n\u003e encrypted blob too. If Alice is the one outsourcing the Commitment which\n\u003e Bob can broadcast, Bob can only broadcast it using the sig Alice gave\n\u003e Bob as it's spending from a 2-of-2. If Alice is outsourcing Bob's\n\u003e Commitment broadcasts, a hash of her input signature is a solid way to\n\u003e derive a key as well without malleability concerns.\n\nBut it rests on the assumption that there are no unknown malleability\nissues on signatures, which I believe makes crypto people nervous. I've\nasked some, though, as that's above my pay grade!\n\nIt also assumes they can't set up the witness such that our sig is not\n2nd or 3rd in the witness element. I think that's true...\n\n\u003e I also like that it \"encourages\" more nodes to download witness data;\n\u003e ignoring witnesses is a concern of mine which this helps with :^)\n\nGood point!\n\nCheers,\nRusty.",
"sig": "b1ce0d8c82f8c93a158c73d3c133df92da6583b6e8af1a407df43651a2e3bf5fbf2a18a0a22d5447b0fb6a06ef131e2fcba95d1f3f9f9bfa0c5644c206536dd2"
}