📅 Original date posted:2016-03-01
📝 Original message:
bitcoin-dev dropped, just lightning-dev
On Mon, Feb 29, 2016 at 10:55:53AM +1030, Rusty Russell wrote:
> If each HTLC output is a p2sh[1], you need the timeout and rhash for
> each one to build the script to redeem it. In practice, there's not
> much difference between sending a watcher a tx for every commit tx and
> sending it information for every new HTLC (roughly a factor of 2).
There's a bigger saving if you've got a very active channel with
comparatively long lived HTLCs. With pre-signed transactions you have
to send:
tx 1234:
input: anchor
outputs: Alice balance ; Bob balance ; HTLC 1 ; HTLC 2 ; HTLC 3 ; ...
tx 1235: (HTLC 2 cleared)
input: anchor
outputs: Alice balance ; Bob balance ; HTLC 1 ; HTLC 3 ; HTLC 4 ; ...
tx 1235: (HTLC 4 cleared)
input: anchor
outputs: Alice balance ; Bob balance ; HTLC 1 ; HTLC 3 ; HTLC 5 ; ...
...
So if you do, say 30 HTLCs per minute, but each HTLC lasts for 20 seconds,
then each HTLC appears in ~10 transactions, and you've correspondingly
got to supply 10 signatures to your outsourced claimant for each HTLC
you deal with. Comparatively, you only have to supply the R/timeout
values once per HTLC.
With SIGHASH_NOINPUT you'd still have to send all the R/timeout values
for each HTLC, but you'd only need to send a single signature for the
channel.
> So we also need to put more in the scriptPubKey for this to work; either
> the entire redeemscript, or possibly some kind of multiple-choice P2SH
> where any one of the hashes will redeem the payment.
We discussed how to recover the timeout/R values recoverable last
year fwiw, see the thread surrounding:
http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-July/000058.html
I don't think there's a big problem with sending that info to a third
party who's doing transaction reclaiming; it might hurt privacy a bit.
Note that with segwit, having a visible scriptPubKey so that R is
trivially obvious isn't even possible anymore...
(If by "multiple-choice p2sh" you mean merkelized abstract syntax trees
that would let you exchange 20+4 / 32+4 bytes of R+timeout for 32 bytes
of a merkle path, which would be an improvement, but not huge. Otherwise
I think you'd have to have a new double-length script hash type; which
might not be friendly to UTXO? Though maybe two 160 bit hashes wouldn't
be out of the question, at 40 bytes versus 32 or 64?)
Cheers,
aj
Anthony Towns [ARCHIVE] /
npub17r…x9l2h
2023-06-09 12:45:46
in reply to nevent1q…8fka
Author Public Key
npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2hPublished at
2023-06-09 12:45:46Event JSON
{
"id": "14a3019cf8515266fb8343b01478855e06d9c72af1c12e031bce430ccd5e3096",
"pubkey": "f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab",
"created_at": 1686314746,
"kind": 1,
"tags": [
[
"e",
"40251c75e65c4d1916718383c441fc60046852f4b128b1c17364753ddffc910c",
"",
"reply"
],
[
"p",
"9456f7acb763eaab2e02bd8e60cf17df74f352c2ae579dce1f1dd25c95dd611c"
]
],
"content": "📅 Original date posted:2016-03-01\n📝 Original message:\nbitcoin-dev dropped, just lightning-dev\n\nOn Mon, Feb 29, 2016 at 10:55:53AM +1030, Rusty Russell wrote:\n\u003e If each HTLC output is a p2sh[1], you need the timeout and rhash for\n\u003e each one to build the script to redeem it. In practice, there's not\n\u003e much difference between sending a watcher a tx for every commit tx and\n\u003e sending it information for every new HTLC (roughly a factor of 2).\n\nThere's a bigger saving if you've got a very active channel with\ncomparatively long lived HTLCs. With pre-signed transactions you have\nto send:\n\ntx 1234:\n input: anchor\n outputs: Alice balance ; Bob balance ; HTLC 1 ; HTLC 2 ; HTLC 3 ; ...\n\ntx 1235: (HTLC 2 cleared)\n input: anchor\n outputs: Alice balance ; Bob balance ; HTLC 1 ; HTLC 3 ; HTLC 4 ; ...\n\ntx 1235: (HTLC 4 cleared)\n input: anchor\n outputs: Alice balance ; Bob balance ; HTLC 1 ; HTLC 3 ; HTLC 5 ; ...\n\n...\n\nSo if you do, say 30 HTLCs per minute, but each HTLC lasts for 20 seconds,\nthen each HTLC appears in ~10 transactions, and you've correspondingly\ngot to supply 10 signatures to your outsourced claimant for each HTLC\nyou deal with. Comparatively, you only have to supply the R/timeout\nvalues once per HTLC.\n\nWith SIGHASH_NOINPUT you'd still have to send all the R/timeout values\nfor each HTLC, but you'd only need to send a single signature for the\nchannel.\n\n\u003e So we also need to put more in the scriptPubKey for this to work; either\n\u003e the entire redeemscript, or possibly some kind of multiple-choice P2SH\n\u003e where any one of the hashes will redeem the payment.\n\nWe discussed how to recover the timeout/R values recoverable last\nyear fwiw, see the thread surrounding:\n\nhttp://lists.linuxfoundation.org/pipermail/lightning-dev/2015-July/000058.html\n\nI don't think there's a big problem with sending that info to a third\nparty who's doing transaction reclaiming; it might hurt privacy a bit.\n\nNote that with segwit, having a visible scriptPubKey so that R is\ntrivially obvious isn't even possible anymore...\n\n(If by \"multiple-choice p2sh\" you mean merkelized abstract syntax trees\nthat would let you exchange 20+4 / 32+4 bytes of R+timeout for 32 bytes\nof a merkle path, which would be an improvement, but not huge. Otherwise\nI think you'd have to have a new double-length script hash type; which\nmight not be friendly to UTXO? Though maybe two 160 bit hashes wouldn't\nbe out of the question, at 40 bytes versus 32 or 64?)\n\nCheers,\naj",
"sig": "2688b205b1d6e49fda26fd6196fe2c17a361fb91d8b9e95660388c001e897eed9803cf40e10377bb3f24ddbd4042e36f2ade5a38580c0e99f27bbe9b3751cafe"
}