{"type":"rich","version":"1.0","author_name":"npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd","author_url":"https://nostr.ae/npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-09-28\n📝 Original message:\u003e\n\u003e 2. As for SPV wallets need to handle awareness of the new blocks.\n\u003e\n\nThere is simply no need for any wallets to change. Making the spec a hard\nfork instead of a soft fork means all existing software does the right\nthing automatically.\n\nTo repeat, please bear in mind that bitcoinj is no longer the only SPV\nwallet implementation. BreadWallet has its own code in Objective-C and is\nthe second most popular SPV implementation (and growing). Additionally,\nbitcoinj is incorporated into lots of apps that'd have to have new versions\nreleased, some of which don't have any way to force a user to update.\n\nSo it's not just my time you'd waste: it's lots of different people's.\n\nOne thing I haven't seen yet is the justification for why a soft fork\nshould be used here. There's no requirement that it be so, and there are\nreal downsides. As Eric said, the fact that the mechanism has issues is not\nunder dispute.\n\nThe normal justification for this it's that it's forwards compatible. But\nthat's not a justification, that's a description.\n\nRe: XT, I already addressed this above.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150928/be6a8d45/attachment.html\u003e"}