<unnamed>

Public Key

npub1c6ytpr5fshkjp2hptfqrvfxy6qkkcgre9fv9va8qyq7h4fs03ehs4fz7ln

Profile Code

nprofile1qqsvdz9s36yctmfq4ts45spkynzdqttvypuj5kzkwnszq0t65c8cumcprpmhxue69uhhyetvv9ujuumwdae8gtnnda3kjctvqy28wumn8ghj7un9d3shjtnyv9kh2uewd9hszrthwden5te0dehhxtnvdakqtc7470

Publishing to

relay.snort.social

relay.damus.io

nos.lol

Last Notes

2023-06-09 12:47:27 UTC

- reply

📅 Original date posted:2017-08-17
📝 Original message:
Dear all,
currently the chain_id allows to distinguish blockchains by the hash of
their genesis block.
With hardforks branching off of the Bitcoin blockchain, how can Lightning
work on (or across)
distinct, permanent forks of a parent blockchain that share the same
genesis block?
I suppose changing the definition of chain_id to the hash of the first
block of the new
branch and requiring replay and wipe-out protection should be sufficient.
But can we
relax these requirements? Are slow block times an issue? Can we use
Lightning to transact
on "almost frozen" block chains suffering from a sudden loss of hashpower?
Has there been any previous discussion or study of Lightning in the setting
of hardforks?
(Is this the right place to discuss this? If not, where would be the right
place?)
thanks,
Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20170817/6f4f0ddc/attachment.html>

2023-06-09 12:47:27 UTC

- reply

2023-06-07 15:39:40 UTC

- reply

📅 Original date posted:2015-06-22
📝 Original message:Gavin,
in 2022 your proposal (BIP as well as code) crosses the 32MB maximum
message size limit. In order to avoid deployment of code that deterministically
fails fatally in 2022, I'd propose to stop the doublings at 32MB for now and fix
the message size limit in the mean time. Since the message size fix requires
a 2nd hard fork anyway, your current 8GB limit could be re-instateted in that
2nd fork as well. Even if you disagree, I'd suggest to address the topic in the BIP.
best regards,
Martin