From knocte at gmail.com Mon Jan 16 04:57:49 2017 From: knocte at gmail.com (=?UTF-8?Q?Andr=C3=A9s_G=2E_Aragoneses_?=) Date: Mon, 16 Jan 2017 12:57:49 +0800 Subject: [Lightning-dev] LN without SegWit: less efficient or less secure? In-Reply-To: <87inpfag87.fsf@rustcorp.com.au> References: <87inpfag87.fsf@rustcorp.com.au> Message-ID: On 16 January 2017 at 10:30, Rusty Russell wrote: > "Andr?s G. Aragoneses " writes: > > Hi there, > > > > Seems like the list is a bit dormant these days. > > Yes, most of the activity has been on the github repository: > > https://github.com/lightningnetwork/lightning-rfc > > That's good! I will ask some question about that, bu in a different thread... > > Is it because of the low chances of SegWit activation given that it > stalled > > at ~26%? > > > > On this topic, I would like to ask about the feasibility of LN without > > SegWit, given these circumstances. > > > > Some has been said in the past, I've been reading through the archives. > But > > in them, everybody seemed overly enthusiastic about the activation of > > SegWit (maybe given that OP_CLTV and OP_CSV activated without hassle). > > If segwit doesn't activate, something is badly broken in Bitcoin. This > is not really a lightning issue; there's been no significant technical > objection to segwit, and it really does make Bitcoin work better. > True. But I guess we're learning that it can happen that technical improvements get non-technical impediments. In this case, my rough guess is that miners are afraid of losing their fee-gathering monopoly for moving money to layer2-actors (payment hubs), given that it will be much easier to spawn paymenthub nodes than mining nodes. Given this, IMHO the only way to move forward would be to start running layer2 solutions in production in spite of the technical difficulties that SegWit non-activation implies. Then, when miners realize they cannot halt progress on layer2 development, they will probably start assuming they need to give up blocking, for the sake of not stagnating the currency (which would lead to the rise of usage of other chains I suppose). > > I'm glad that miners are cautious with their upgrades, and segwit > adoption will take time to roll out across products anyway. Let's look > again in 6 months. > > > Which one is more accurate? Is the security problems only related to > having > > to watch the blockchain? If yes, why cannot one outsource this job to a > > server (e.g. the hypothetical server of your light-wallet) in level2? > > Yes, the problem is outsourcing. You can't hand the outsourcer a > penalty transaction signature if you don't know what the bad transaction > will look like. And if the signatures are part of the transaction ID, > you don't. > Can you elaborate on this? From my limited understanding, I guess you're referring to detecting a broadcast of a transaction of a previous state of the payment channel. In this case, the HTLC-clock of the revocation transaction starts ticking, and the transaction to revoke this malicious move would need the ID of the transaction used to broadcast the bad state. Right? If my assumption was correct, wouldn't it be possible to have an alternative Lightning-Level2? That is: without SegWit, but still with CSV. And, instead of using revocation, use shorter locktimes like the Spillman-style payment channels do (everytime there's a need to change direction)? I know that Spillman-style channels use nLockTime, which is vulnerable to malleability; so my question is: is there a way to create OP_CLTV/OP_CSV-style channels (instead of nLockTime-based, so malleability resistant) without using revocation methods? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: