From aj at erisian.com.au Mon Jan 16 22:12:25 2017 From: aj at erisian.com.au (Anthony Towns) Date: Tue, 17 Jan 2017 08:12:25 +1000 Subject: [Lightning-dev] LN without SegWit: less efficient or less secure? In-Reply-To: References: <87inpfag87.fsf@rustcorp.com.au> <20170116063138.GA1897@erisian.com.au> <20170116073243.GA2927@erisian.com.au> Message-ID: <20170116221225.GA3677@erisian.com.au> On Mon, Jan 16, 2017 at 04:26:15PM +0800, Andr?s G. Aragoneses wrote: > Ok but I also read the last paragraph of the last version of the Lightning > paper which I quote: > "A further stop-gap solution using OP CHECKSEQUENCEVERIFY > 57or a less-optimal use of OP CHECKLOCKTIMEVERIFY will be described > in a future paper by Rusty Russell. An updated version of this paper will > also include these constructions." > > So I guess I was confused by thinking that Lightning Level1 and Level2 was > referring to this, and maybe someone forgot to update the paper to include L1& > L2. The three levels from the Scaling Bitcoin Hong Kong talk aren't really tightly defined/analysed; it's not worth reading *too* much into them. The third level in particular conflates segwit and the SIGHASH_NOINPUT idea; the former fixes malleability, but the latter would fix malleability and allow much better trustless outsourcing. So: level 1 -- CLTV only, no CSV; channels have a fixed end date, and every commitment has a fixed must-spend/obsolete-by date as well. no longer relevant. level 2 -- CLTV and CSV, but second and third party malleability still possible. the current state of affairs. can only fund channels on one side or second party malleability messes you over, and may need to do something clever to avoid third party malleability (like introduce a time limit on the channel), but otherwise works great. level 3(a) -- CLTV, CSV and segwit -- malleability isn't relevant. outsourcing of channel monitoring is inelegant (effectively infeasible?), because you need to provide whoever does the monitor with signed penalty txns for every possible transaction level 3(b) -- CLTV, CSV and SIGHASH_NOINPUT (with or without segwit) -- all the benefits of 3(a) and you can cheaply get someone else to monitor the blockchain for you, making a "lite" lightning node feasible The lightning paper itself is mostly designed around "level 0" when there wasn't even an OP_CLTV and you had to have intermediate layers of transactions using nLockTime to enforce the delay. (No doubt there will be "level 4" down the line when MAST/signature aggregation or something that makes things even more amazing) > But no, we're talking about using CLTV (or CSV, I guess?) for the refund > transaction instead of for the HTLC. Would we be able to call this an > hypothetical Level2.5 of LN? (Level 3 being the one requiring SeqWit). I think everyone's been focussed on 3(a) because getting rid of malleability is obviously a great thing for everyone in bitcoin, and segwit makes that actually possible. I'm not sure if there are actually variations of level 2 to justify a 2(a)/2(b) or 2.5 or similar. Cheers, aj