Greg Sanders [ARCHIVE] on Nostr: 📅 Original date posted:2018-01-30 📝 Original message: Not sure there is much to ...
📅 Original date posted:2018-01-30
📝 Original message:
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 <ben at mord.io> 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 <ben at mord.io> 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 <gsanders87 at gmail.com>
>> 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 <ben at mord.io> 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 <ZmnSCPxj at protonmail.com>
>>>> 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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180130/bef20077/attachment.html>;
📝 Original message:
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 <ben at mord.io> 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 <ben at mord.io> 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 <gsanders87 at gmail.com>
>> 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 <ben at mord.io> 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 <ZmnSCPxj at protonmail.com>
>>>> 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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180130/bef20077/attachment.html>;