Benjamin Mord [ARCHIVE] on Nostr: 📅 Original date posted:2018-01-30 📝 Original message: Ugh, correction - BOLTs ...
📅 Original date posted:2018-01-30
📝 Original message:
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/f330ebd6/attachment-0001.html>;
📝 Original message:
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/f330ebd6/attachment-0001.html>;