Mike Hearn [ARCHIVE] on Nostr: 📅 Original date posted:2015-09-28 📝 Original message:> > 2. As for SPV wallets ...
📅 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>
📝 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>