From gsanders87 at gmail.com Tue Jan 30 16:55:58 2018 From: gsanders87 at gmail.com (Greg Sanders) Date: Tue, 30 Jan 2018 11:55:58 -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: Not sure there is much to be done in simple consensus failures. Agreed it's a bit floaty unless there's an actual proposal. On Tue, Jan 30, 2018 at 11:42 AM, Benjamin Mord wrote: > > 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: