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
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
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.
"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
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
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