Peter Todd [ARCHIVE] on Nostr: š Original date posted:2015-09-28 š Original message:On Mon, Sep 28, 2015 at ...
š
Original date posted:2015-09-28
š Original message:On Mon, Sep 28, 2015 at 03:41:56PM +0200, Mike Hearn wrote:
> >
> > 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.
Good!
> > 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).
Could you elaborate on what exatly you mean by this.
> > 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.
SPV wallets can't detect hard-forks, so in both cases you will have
invalid blocks be accepted by SPV clients; there's no deployment
scenario for either hard or soft forks that guarantees all miners adopt
a fork.
What does prevent invalid blocks being accepted by SPV clients is
checking the block nVersion field and applying forking logic. Of course,
that only works for advertised forks, but again, that's equally true for
soft and hard forks.
> 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.
Again, in neither case do you get the "correct outcome" of SPV clients
accepting no invalid blocks without nVersion field checking.
However, in the hard-fork case, because the non-adopting miners reject
the fork, they build a chain which could be used to attack SPV clients
with false confirmations by sybil attacking those clients. In the
soft-fork case, the non-adopting miners keep accepting the longer chain
built by the adopting miners, preventing the creation of a chain that
could be used to attack SPV miners.
BTW, what's the other widely used SPV implementation you're thinking of?
I'll contact them directly and help them implement proper SPV fork
protections if they haven't already; if bitcoinj is unwilling to do this
at least we could have an alternative implementation that does.
(equally, if anyone wants to fork bitcoinj and correct this flaw I'd be
happy to help advise)
--
'peter'[:-1]@petertodd.org
00000000000000000ca626374f25dadbbb9245e60563a4d876f3c73070ad3849
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150928/f7a49dbf/attachment.sig>;
š Original message:On Mon, Sep 28, 2015 at 03:41:56PM +0200, Mike Hearn wrote:
> >
> > 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.
Good!
> > 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).
Could you elaborate on what exatly you mean by this.
> > 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.
SPV wallets can't detect hard-forks, so in both cases you will have
invalid blocks be accepted by SPV clients; there's no deployment
scenario for either hard or soft forks that guarantees all miners adopt
a fork.
What does prevent invalid blocks being accepted by SPV clients is
checking the block nVersion field and applying forking logic. Of course,
that only works for advertised forks, but again, that's equally true for
soft and hard forks.
> 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.
Again, in neither case do you get the "correct outcome" of SPV clients
accepting no invalid blocks without nVersion field checking.
However, in the hard-fork case, because the non-adopting miners reject
the fork, they build a chain which could be used to attack SPV clients
with false confirmations by sybil attacking those clients. In the
soft-fork case, the non-adopting miners keep accepting the longer chain
built by the adopting miners, preventing the creation of a chain that
could be used to attack SPV miners.
BTW, what's the other widely used SPV implementation you're thinking of?
I'll contact them directly and help them implement proper SPV fork
protections if they haven't already; if bitcoinj is unwilling to do this
at least we could have an alternative implementation that does.
(equally, if anyone wants to fork bitcoinj and correct this flaw I'd be
happy to help advise)
--
'peter'[:-1]@petertodd.org
00000000000000000ca626374f25dadbbb9245e60563a4d876f3c73070ad3849
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150928/f7a49dbf/attachment.sig>;