Benjamin Mord [ARCHIVE] on Nostr: 📅 Original date posted:2018-01-30 📝 Original message: Oh wait - I think we're ...
📅 Original date posted:2018-01-30
📝 Original message:
Oh wait - I think we're covered. Any node "B" which follows the "wrong"
fork (according to judgement of node "A"), will at worst be
indistinguishable from a fraudulent node that attempts to mimic the
lightning protocol while failing to transmit the expected blockchain
transactions during channel funding or closure. But the protocol is already
designed to be robust against nodes failing to broadcast expected
blockchain transactions, so we get fork protection as byproduct. Correct?
If so, this point might be worth advertising in either BOLT 2 or 5. In some
ways, this might even strengthen consensus of the underlying blockchain.
Perhaps the only caveat is we must not get carried away with excessive
penalties against nodes who fail to broadcast blockchain transactions, if
those penalties are given to others. In aggregate, such penalties could
turn needless forking into a profit opportunity for
disingenuous-yet-sophisticated nodes at expense of sincere nodes, which in
turn might motivate forking.
On Tue, Jan 30, 2018 at 11:55 AM, Greg Sanders <gsanders87 at gmail.com> wrote:
> 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/cd1d60d9/attachment-0001.html>;
📝 Original message:
Oh wait - I think we're covered. Any node "B" which follows the "wrong"
fork (according to judgement of node "A"), will at worst be
indistinguishable from a fraudulent node that attempts to mimic the
lightning protocol while failing to transmit the expected blockchain
transactions during channel funding or closure. But the protocol is already
designed to be robust against nodes failing to broadcast expected
blockchain transactions, so we get fork protection as byproduct. Correct?
If so, this point might be worth advertising in either BOLT 2 or 5. In some
ways, this might even strengthen consensus of the underlying blockchain.
Perhaps the only caveat is we must not get carried away with excessive
penalties against nodes who fail to broadcast blockchain transactions, if
those penalties are given to others. In aggregate, such penalties could
turn needless forking into a profit opportunity for
disingenuous-yet-sophisticated nodes at expense of sincere nodes, which in
turn might motivate forking.
On Tue, Jan 30, 2018 at 11:55 AM, Greg Sanders <gsanders87 at gmail.com> wrote:
> 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/cd1d60d9/attachment-0001.html>;