ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2018-01-30 📝 Original message: Good morning Ben, > Hi, > ...
📅 Original date posted:2018-01-30
📝 Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180130/6b952288/attachment.html>
📝 Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180130/6b952288/attachment.html>