rich1.0npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgydhttps://nostr.ae/npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgydnjumphttps://nostr.ae📅 Original date posted:2015-09-28 📝 Original message:> > 2. As for SPV wallets need to handle awareness of the new blocks. > There is simply no need for any wallets to change. Making the spec a hard fork instead of a soft fork means all existing software does the right thing automatically. To repeat, please bear in mind that bitcoinj is no longer the only SPV wallet implementation. BreadWallet has its own code in Objective-C and is the second most popular SPV implementation (and growing). Additionally, bitcoinj is incorporated into lots of apps that'd have to have new versions released, some of which don't have any way to force a user to update. So it's not just my time you'd waste: it's lots of different people's. One thing I haven't seen yet is the justification for why a soft fork should be used here. There's no requirement that it be so, and there are real downsides. As Eric said, the fact that the mechanism has issues is not under dispute. The normal justification for this it's that it's forwards compatible. But that's not a justification, that's a description. Re: XT, I already addressed this above. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150928/be6a8d45/attachment.html>