Mike Hearn [ARCHIVE] on Nostr: 📅 Original date posted:2015-09-28 📝 Original message:> > 1) Do you agree that ...
📅 Original date posted:2015-09-28
📝 Original message:>
> 1) Do you agree that CLTV should be added to the Bitcoin protocol?
>
> Ignoring the question how exactly it is added, hard-fork or soft-fork.
>
The opcode definition seems OK.
> 2) Will you add a IsSuperMajority() CLTV soft-fork to Bitcoin XT if it
> is added to Bitcoin Core?
>
Yes. It might be worth putting the version bit change behind a command line
flag though: the BIP, as written, has problems (with deployment).
> 3) Will you add soft-fork detection to bitcoinj, to allow SPV clients to
detect advertised soft-forks and correctly handle them?
>
I'd really hate to do that. It'd be a Rube Goldberg machine:
There's no really good way to do what you propose, and we already have a
perfectly workable mechanism to tell SPV clients about chain forks: the
block chain itself. This has the advantage of being already implemented,
already deployed, and it works correctly.
Attempting to strap a different mechanism on top to try and make soft forks
more like hard forks would be a large and pointless waste of people's time
and effort, not just mine (bitcoinj is not the only widely used SPV
implementation nowadays). You may as well go straight to the correct
outcome instead of trying to simulate it with ever more complex mechanisms.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150928/2f74bd22/attachment.html>
📝 Original message:>
> 1) Do you agree that CLTV should be added to the Bitcoin protocol?
>
> Ignoring the question how exactly it is added, hard-fork or soft-fork.
>
The opcode definition seems OK.
> 2) Will you add a IsSuperMajority() CLTV soft-fork to Bitcoin XT if it
> is added to Bitcoin Core?
>
Yes. It might be worth putting the version bit change behind a command line
flag though: the BIP, as written, has problems (with deployment).
> 3) Will you add soft-fork detection to bitcoinj, to allow SPV clients to
detect advertised soft-forks and correctly handle them?
>
I'd really hate to do that. It'd be a Rube Goldberg machine:
There's no really good way to do what you propose, and we already have a
perfectly workable mechanism to tell SPV clients about chain forks: the
block chain itself. This has the advantage of being already implemented,
already deployed, and it works correctly.
Attempting to strap a different mechanism on top to try and make soft forks
more like hard forks would be a large and pointless waste of people's time
and effort, not just mine (bitcoinj is not the only widely used SPV
implementation nowadays). You may as well go straight to the correct
outcome instead of trying to simulate it with ever more complex mechanisms.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150928/2f74bd22/attachment.html>