From ben at mord.io Tue Jan 30 16:42:59 2018 From: ben at mord.io (Benjamin Mord) Date: Tue, 30 Jan 2018 11:42:59 -0500 Subject: [Lightning-dev] lightning operation during / following a chain fork (e.g. BIP 50) In-Reply-To: References: <6Q40l0m3BQ68EQcQ26nDVz-NeQcA-ycp5N-GdO6CPCcWkESMR-ZRM86365AgRwBEieRrAzgDX8-cTfSkWxYP9RqGP6zxoWNn0naEAAD0iUo=@protonmail.com> Message-ID: Ugh, correction - BOLTs are presently written explicitly require segwit (not segwit2x! need more coffee...). Sorry for the 'typo' On Tue, Jan 30, 2018 at 11:41 AM, Benjamin Mord wrote: > > Greg, I think you are confusing two different topics: adversarial forks, > versus segwit as fix to transaction malleability. > > If you remove segwit, i.e. if you reintroduce the txid malleability bug, > then lightning becomes unsafe - any nodes which attempt to follow such a > fork would suffer. Incentives strongly motivate maintenance of consensus, > so that scenario (I think?) is automatically covered and of no concern. (So > actually, BCH is presently of no concern.) BOLTs as presently written > explicitly require segwit2x anyhow, and for this reason. > > I understand an "adversarial fork" is one which lacks replay protection, . > This is very much something worth addressing, as that is the case by > default with a BIP 50-style accidental fork, and also appeared likely with > the failed (and poorly named) "segwit2x". But I'm thinking out loud, will > stop spamming people on the list unless / until I have a usefully concrete > solution to offer. (Or until someone else comes up with something.) > > > On Tue, Jan 30, 2018 at 11:31 AM, Greg Sanders > wrote: > >> "Adversarial" forks that rip out segwit, or maliciously do not change >> their signature algorithm, are basically impossible to defend against. May >> be best to focus energies on forks that use strong replay protection in the >> form of FORKID. >> >> On Tue, Jan 30, 2018 at 11:26 AM, Benjamin Mord wrote: >> >>> >>> Thank you, ZmnSCPxj. BCH is a warmup question for several reasons, I >>> believe they don't even support segwit (!) so lightning would be unsafe due >>> to their txid mutability bug. I agree altcoin support should be lower >>> priority, whenever it is obvious which is the altcoin (as indeed, is >>> abundantly clear wrt BTC vs BCH). But it might one day become unclear. >>> >>> I remain concerned about safety despite BIP 50 scenarios, forks with >>> more legitimate contention than so far seen, and also system stability in >>> face of increasingly unsophisticated / gullible user base. As a >>> cryptocurrency is little more than a trustless consensus mechanism, it >>> seems circular to assume consensus in its design, especially if there are >>> entities financially motivated to fracture that consensus. Resilience >>> against forks would seem core to safety. If I think of a concrete solution, >>> I'll send it first to this list for discussion - as I believe that is the >>> preferred process? >>> >>> Thanks, >>> Ben >>> >>> >>> On Tue, Jan 30, 2018 at 1:16 AM, ZmnSCPxj >>> wrote: >>> >>>> Good morning Ben, >>>> >>>> Hi, >>>> >>>> One topic I can't seem to find in the BOLTs is how lightning nodes >>>> maintain consensus during or after a fork of the underlying blockchain(s). >>>> For example, channel_announcement messages use a chain_hash, defined as >>>> hash of underlying block chain's genesis block, to identify the currency in >>>> use. Today, one might ask which hash identifies BTC as opposed to BCH? >>>> >>>> >>>> I believe the rough consensus among most Lightning developers is that >>>> BTC is "the real BTC" and gets the Satoshi genesis hash, while BCH is an >>>> altcoin that was forked off BTC and gets as hash the branching-off point. >>>> You could try to convince people developing and using Lightning software to >>>> do the reverse, but I think it is unlikely that many people would agree to >>>> that. >>>> >>>> >>>> A more difficult question arises in how existing channels handle >>>> intentional forks which arise after funding of a payment channel. >>>> >>>> An even more difficult question arises in the handling of unintentional >>>> forks, as documented for example in BIP 50. >>>> >>>> Have these scenarios been analyzed / designed yet, or does that work >>>> remain? >>>> >>>> >>>> The work remains. For the most part, the priority is to get >>>> implementations to a state, where we can safely deploy on Bitcoin Mainnet. >>>> Then optimize further by adding RBF and multi-channel funding, then >>>> integrate Burchert-Decker-Wattenhofer channel factories, splicing, and so >>>> on. Greater support for altcoins can be done later. >>>> >>>> For forked altcoins, short channel IDs contain the block height at >>>> which the funding transaction confirmed. This might be used to judge if a >>>> channel contains forked coins or not. >>>> >>>> Regards, >>>> ZmnSCPxj >>>> >>>> >>>> Thanks! >>>> Ben >>>> >>>> >>>> >>> >>> _______________________________________________ >>> Lightning-dev mailing list >>> Lightning-dev at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: