[Lightning-dev] [bitcoin-dev] SIGHASH_NOINPUT in Segregated Witness

[Anthony Towns]

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