From aj at erisian.com.au Wed Mar 2 22:36:27 2016 From: aj at erisian.com.au (Anthony Towns) Date: Thu, 3 Mar 2016 08:36:27 +1000 Subject: [Lightning-dev] [bitcoin-dev] SIGHASH_NOINPUT in Segregated Witness In-Reply-To: <87lh61n1x8.fsf@rustcorp.com.au> References: <20160226010746.GB10295@lightning.network> <87oab0e50u.fsf@rustcorp.com.au> <20160301232252.GA18985@sapphire.erisian.com.au> <87lh61n1x8.fsf@rustcorp.com.au> Message-ID: <20160302223627.GA4322@sapphire.erisian.com.au> 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+), 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