Joseph Poon [ARCHIVE] on Nostr: 📅 Original date posted:2015-07-24 📝 Original message: Ah sorry, that only ...

📅 Original date posted:2015-07-24
📝 Original message:
Ah sorry, that only solves the Commitment Transactions, not the HTLC
outputs. It's also not possible to use the pubkeys as identifiers, as
Rusty said, P2SH would be used.

While it's possible to only check only recent blocks before the
Commitment Transaction for the search space (e.g. 3 days worth), since
you know when the Commitment Transaction was broadcast, the search space
limitation sort of breaks down if you permit long-dated HTLCs.

Worst-case it may be possible to have long-dated HTLCs on a seperate
hash-tree, but it's not an ideal solution.

In retrospect, this P2SH problem is somewhat exacerbated by the fact
that the timeout being different numbers as well, so ideally that should
be stored as part of the output. The tradeoff between having the entire
script in the output (which results in larger transactions), and using
P2SH (which reduces bits of entropy/identifiability) is a bit of a
problem. For some reason, I've always assumed the output would be
included (ignoring isStandard issues), but that may not be optimal.

For now, I think a reasonable stop-gap solution would be to have some
small storage of prior commitment transactions. For every commitment,
and each HTLC output, store the timeout and the original Commitment
Transaction height when the HTLC was first made. That should be enough
information to work with (you can work backwards if you know which
Commitment Transaction the HTLC was first created) and amounts to 48
bits (6 bytes) of storage per HTLC output per fully expired Commitment
Transaction. I generally dislike OP_RETURN as a solution, but it's
possible.

Thanks for bringing this up, I haven't really properly considered this!

--
Joseph Poon