[Lightning-dev] [bitcoin-dev] SIGHASH_NOINPUT in Segregated Witness
rusty at rustcorp.com.au
Wed Mar 2 00:44:51 UTC 2016
Anthony Towns <aj at erisian.com.au> writes:
> 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
> to send:
Yes, with SIGHASH_NOINPUT you only need to send timeout/rval per new
HTLC, plus new revocation preimage per new commit tx. Assuming no
batching, so every second new commit tx adds a new HTLC, that's (4 + 32)
/ 2 + 32 = 50 bytes per commit tx.
Without SIGHASH_NOINPUT, add 64 bytes per commit tx output
(2+<num-htlcs>), plus you have to generate those signatures. That's
probably going to be less than 1 TCP packet, though.
I'm not convinced it's qualitatively different.
>> 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.
Thanks for the reminder, re-reading... the result was that all the
clever tricks don't win much; you can avoid sending/storing the 4 byte
> 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?)
No, MAST doesn't do it for you, since you still need the hash of the
unknown part. We'd need a "script is one of these hashes" form, which
as you point out, bloats the UTXO set.
So not likely to be acceptable until lightning is the main bitcoin user.
More information about the Lightning-dev