[Lightning-dev] [bitcoin-dev] SIGHASH_NOINPUT in Segregated Witness
aj at erisian.com.au
Tue Mar 1 23:22:52 UTC 2016
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, 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
outputs: Alice balance ; Bob balance ; HTLC 1 ; HTLC 2 ; HTLC 3 ; ...
tx 1235: (HTLC 2 cleared)
outputs: Alice balance ; Bob balance ; HTLC 1 ; HTLC 3 ; HTLC 4 ; ...
tx 1235: (HTLC 4 cleared)
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
> 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:
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?)
More information about the Lightning-dev