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

[Anthony Towns]

On Wed, Mar 02, 2016 at 11:14:51AM +1030, Rusty Russell wrote:
> 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.

Assuming "batching" refers to combining multiple changes in a single
commitment update, yeah. (I was thinking batching multiple commitment
updates in a single packet when updating your blockchain contracter)

> 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.

You're adding 70 bytes of signature data for every HTLC for every
commitment it appears in, all of which have to be stored until the
channel's closed. That's a 70% increase in storage requirements.

As it turns out, I'm confused as to what size a "TCP packet" actually
is these days; is it 65kB or 1500B or somewhere in between? 1500 bytes
only gives you about 14 HTLCs open on a channel simultaneously.

But maybe anyone doing high volume/rate (ie, forwarding other people's
transactions, or doing many transactions per minute) should just run
their own bitcoin node anyway. For low volume channels where you only
do five transactions an hour, every hour, a whole six months of full
transactions is only 21MB.

Yeah; I think that persuades me: "end users" can outsource just by
generating a new payment tx and sending that off; high volume users can
run a bitcoin node themselves and only do the signatures if/when someone
actually cheats, so SIGHASH_NOINPUT isn't very useful in either case.

That only works because I don't think people running lightning on their
phone will be forwarding many transactions though :)

> > 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
> timeout.

You can avoid sending the 4 byte commitment index (ie, what you need
to recover your shachain seed) by encoding that in the commitment
transaction's locktime, but you still need to store/send the HTLC
timeouts aiui.

> > (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.

Yeah, MAST just lets you trade the 32+4 bytes of R+timeout for 32 bytes
of unknown-AST-hash.

> 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.

Yeah. Of course, an upside is it wouldn't bloat the UTXO set for very
long -- lightning transactions should get spent pretty quickly, in case
the other side's CTLV timeout expires.

Cheers,
aj