📅 Original date posted:2019-12-03
📝 Original message:
Good morning Rusty,
> ZmnSCPxj ZmnSCPxj at protonmail.com writes:
>
> > Good morning Rusty,
> >
> > > > Hi all,
> > > > I recently revisited the eltoo paper and noticed some things related
> > > > watchtowers that might affect channel construction.
> > > > Due to NOINPUT, any update transaction can spend from any other, so
> > > > in theory the tower only needs the most recent update txn to resolve
> > > > any dispute.
> > > > In order to spend, however, the tower must also produce a witness
> > > > script which when hashed matches the witness program of the input. To
> > > > ensure settlement txns can only spend from exactly one update txn,
> > > > each update txn uses unique keys for the settlement clause, meaning
> > > > that each state has a unique witness program.
> > >
> > > I didn't think this was the design. The update transaction can spend
> > > any prior, with a fixed script, due to NOINPUT.
> > > The settlement transaction does not use NOINPUT, and thus can only
> > > spend the matching update.
> >
> > My understanding is that this is not logically possible?
>
> You're right, no wonder I missed this problem :(
>
> OK, so we need to change the key(s) every time. Can we tweak it based
> on something the watchtower will know, i.e. something in the update tx
> itself? Obviously not the output, as that would create a circular
> dependency. Is there some taproot thing we can use to insert some
> noise in the input?
You could always add a taproot branch with a `OP_RETURN <randomness>` tapscript, which can never be used (thus has no effect on the overall security), but can inject randomness to the outer taproot key.
This *is* secure, since bip-schnorr indicates that `e` is `h(R | P | m)`, with `P` being the pubkey itself, so that should be enough.
Or why not BIP32 derivation?
This should be just as secure.
Regards,
ZmnSCPxj
ZmnSCPxj [ARCHIVE] /
npub1g5…3ms3l
2023-06-09 12:57:33
in reply to nevent1q…shuu
Author Public Key
npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lSeen on
wss://relay.nostr.bandPublished at
2023-06-09 12:57:33Event JSON
{
"id": "b008c8773870a660d829f1732f5eb59d0530f1477fddb805564da115743e35bc",
"pubkey": "4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861",
"created_at": 1686315453,
"kind": 1,
"tags": [
[
"e",
"4c9eebfb07afa82296aae9348e1049e58998072c2cbd84edcebce5b362e0df8f",
"",
"root"
],
[
"e",
"6ac73a0a2e538b4e9fa4be7b3cd7edf98e3f0a6e354d6dfba811ae0e34e2a02b",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2019-12-03\n📝 Original message:\nGood morning Rusty,\n\n\u003e ZmnSCPxj ZmnSCPxj at protonmail.com writes:\n\u003e\n\u003e \u003e Good morning Rusty,\n\u003e \u003e\n\u003e \u003e \u003e \u003e Hi all,\n\u003e \u003e \u003e \u003e I recently revisited the eltoo paper and noticed some things related\n\u003e \u003e \u003e \u003e watchtowers that might affect channel construction.\n\u003e \u003e \u003e \u003e Due to NOINPUT, any update transaction can spend from any other, so\n\u003e \u003e \u003e \u003e in theory the tower only needs the most recent update txn to resolve\n\u003e \u003e \u003e \u003e any dispute.\n\u003e \u003e \u003e \u003e In order to spend, however, the tower must also produce a witness\n\u003e \u003e \u003e \u003e script which when hashed matches the witness program of the input. To\n\u003e \u003e \u003e \u003e ensure settlement txns can only spend from exactly one update txn,\n\u003e \u003e \u003e \u003e each update txn uses unique keys for the settlement clause, meaning\n\u003e \u003e \u003e \u003e that each state has a unique witness program.\n\u003e \u003e \u003e\n\u003e \u003e \u003e I didn't think this was the design. The update transaction can spend\n\u003e \u003e \u003e any prior, with a fixed script, due to NOINPUT.\n\u003e \u003e \u003e The settlement transaction does not use NOINPUT, and thus can only\n\u003e \u003e \u003e spend the matching update.\n\u003e \u003e\n\u003e \u003e My understanding is that this is not logically possible?\n\u003e\n\u003e You're right, no wonder I missed this problem :(\n\u003e\n\u003e OK, so we need to change the key(s) every time. Can we tweak it based\n\u003e on something the watchtower will know, i.e. something in the update tx\n\u003e itself? Obviously not the output, as that would create a circular\n\u003e dependency. Is there some taproot thing we can use to insert some\n\u003e noise in the input?\n\nYou could always add a taproot branch with a `OP_RETURN \u003crandomness\u003e` tapscript, which can never be used (thus has no effect on the overall security), but can inject randomness to the outer taproot key.\nThis *is* secure, since bip-schnorr indicates that `e` is `h(R | P | m)`, with `P` being the pubkey itself, so that should be enough.\n\nOr why not BIP32 derivation?\nThis should be just as secure.\n\nRegards,\nZmnSCPxj",
"sig": "9984421b8708788c7620987feaf8568ce08930dbbea739470598ef89ecbfc5ba8ffec26ff1ccec04f335bef78594afac5b1956bd05adba8ca755ffde5cdff8c5"
}