https://nostr.ae https://nostr.ae/npub1c6ytpr5fshkjp2hptfqrvfxy6qkkcgre9fv9va8qyq7h4fs03ehs4fz7ln https://nostr.ae/nevent1qqsy8gv9804nyxm3j3jl5km9hgzhp4tmln8kcsd94gkhslc3ql7xpwqzyrrg3vyw3xz76g92u9dyqd3ycngz6mpq0y49s4n5uqsr674xp78x74754x8 In reply to <a href='/nevent1qqsd24dwhc3d9zw7nntqmcutw40lcguhdyrnldmm6gezsdejpj4zngsa50ta3'>nevent1q…0ta3</a><br/>_________________________<br/><br/>📅 Original date posted:2017-08-17<br/>📝 Original message:<br/>Dear all,<br/><br/>currently the chain_id allows to distinguish blockchains by the hash of<br/>their genesis block.<br/><br/>With hardforks branching off of the Bitcoin blockchain, how can Lightning<br/>work on (or across)<br/>distinct, permanent forks of a parent blockchain that share the same<br/>genesis block?<br/><br/>I suppose changing the definition of chain_id to the hash of the first<br/>block of the new<br/>branch and requiring replay and wipe-out protection should be sufficient.<br/>But can we<br/>relax these requirements? Are slow block times an issue? Can we use<br/>Lightning to transact<br/>on &#34;almost frozen&#34; block chains suffering from a sudden loss of hashpower?<br/><br/>Has there been any previous discussion or study of Lightning in the setting<br/>of hardforks?<br/>(Is this the right place to discuss this? If not, where would be the right<br/>place?)<br/><br/>thanks,<br/>Martin<br/>-------------- next part --------------<br/>An HTML attachment was scrubbed...<br/>URL: &lt;<a href="http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20170817/6f4f0ddc/attachment.html&gt">http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20170817/6f4f0ddc/attachment.html&gt</a>; 2023-06-09T12:47:27Z https://nostr.ae/nevent1qqsyye2e3ursuqcmycncjm6vaevu2vsfs5hlx6hxxchgjcazcem3ccszyrrg3vyw3xz76g92u9dyqd3ycngz6mpq0y49s4n5uqsr674xp78x733j48q In reply to <a href='/nevent1qqsy8gv9804nyxm3j3jl5km9hgzhp4tmln8kcsd94gkhslc3ql7xpwqhn84xz'>nevent1q…84xz</a><br/>_________________________<br/><br/>📅 Original date posted:2017-08-17<br/>📝 Original message:<br/>Dear all,<br/><br/>currently the chain_id allows to distinguish blockchains by the hash of<br/>their genesis block.<br/><br/>With hardforks branching off of the Bitcoin blockchain, how can Lightning<br/>work on (or across)<br/>distinct, permanent forks of a parent blockchain that share the same<br/>genesis block?<br/><br/>I suppose changing the definition of chain_id to the hash of the first<br/>block of the new<br/>branch and requiring replay and wipe-out protection should be sufficient.<br/>But can we<br/>relax these requirements? Are slow block times an issue? Can we use<br/>Lightning to transact<br/>on &#34;almost frozen&#34; block chains suffering from a sudden loss of hashpower?<br/><br/>Has there been any previous discussion or study of Lightning in the setting<br/>of hardforks?<br/>(Is this the right place to discuss this? If not, where would be the right<br/>place?)<br/><br/>thanks,<br/>Martin<br/>-------------- next part --------------<br/>An HTML attachment was scrubbed...<br/>URL: &lt;<a href="http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20170817/a68ca5d6/attachment.html&gt">http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20170817/a68ca5d6/attachment.html&gt</a>; 2023-06-09T12:47:27Z https://nostr.ae/nevent1qqs85q4rufgeutly5meda6l82faz8kvhsskuhd0qtmy4z6z52wzde0qzyrrg3vyw3xz76g92u9dyqd3ycngz6mpq0y49s4n5uqsr674xp78x72kvw24 In reply to <a href='/nevent1qqsqk5ckrarz5yhjuykqavn8c8sn7jkdze3z04jluwswhy7ms2q2wpqu2pjmv'>nevent1q…pjmv</a><br/>_________________________<br/><br/>📅 Original date posted:2015-06-22<br/>📝 Original message:Gavin,<br/><br/>in 2022 your proposal (BIP as well as code) crosses the 32MB maximum<br/>message size limit. In order to avoid deployment of code that deterministically<br/>fails fatally in 2022, I&#39;d propose to stop the doublings at 32MB for now and fix<br/>the message size limit in the mean time. Since the message size fix requires<br/>a 2nd hard fork anyway, your current 8GB limit could be re-instateted in that<br/>2nd fork as well. Even if you disagree, I&#39;d suggest to address the topic in the BIP.<br/><br/>best regards,<br/>Martin 2023-06-07T15:39:40Z