MIME-Version: 1.0
In-Reply-To: <CA+w+GKTf2vnJ0WdrK1HzFwCx154e=BP=kGcZvGYY7cbcijwLSQ@mail.gmail.com>
References: <20150927185031.GA20599@savin.petertodd.org>
	<CA+w+GKRCVr-9TVk66utp7xLRgTxNpxYoj3XQE-6y_N8JS6eO6Q@mail.gmail.com>
	<CAAS2fgSEDGBd67m7i8zCgNRqtmQrZyZMj7a5TsYo41Dh=tdhHQ@mail.gmail.com>
	<CA+w+GKRKGS=KZrLtiW8Zbn4EQH_TELfQR+TfrADCMXLR22Q+tw@mail.gmail.com>
	<CADm_WcbJoH27H9ckr5sfmE0gh7YbSjKr1uLse0s3b4GTT+jEAA@mail.gmail.com>
	<CA+w+GKS01sVXqNY6a39EjqL8NVO6k1Vq6sd0VZjeqF_tsx7OAA@mail.gmail.com>
	<CABm2gDpojk4Sb9eVVcFiaQng+mKs+3iWFu_Ep0h7VC1ip7US5Q@mail.gmail.com>
	<CA+w+GKTf2vnJ0WdrK1HzFwCx154e=BP=kGcZvGYY7cbcijwLSQ@mail.gmail.com>
Date: Thu, 1 Oct 2015 00:14:21 +0200
Message-ID: <CABm2gDqAhjd1721XPjjAiev4coveLM0NUE9ng+W2tgswHiW5bg@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Mike Hearn <hearn@vinumeris.com>
Content-Type: text/plain; charset=UTF-8
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!
Precedence: list

On Wed, Sep 30, 2015 at 11:06 PM, Mike Hearn <hearn@vinumeris.com> wrote:
>> Exactly, all those "mini divergences" eventually disappear
>
> A miner that has accepted a newly invalid transaction into its memory pool
> and is trying to mine it, will keep producing invalid blocks forever until
> the owner shuts it down and upgrades. This was happening for weeks after
> P2SH triggered.
>
> For instance, any miner that has modified/bypassed IsStandard() can do this,
> or any miner that accepts direct transaction submission, or any miner that
> runs an old node from before OP_NOPs were made non-standard.

That is correct. But doesn't seem to contradict anything I said.

>> On the other hand, the "single divergence" in the hardfork keeps growing
>> forever (unless all miners evetually upgrade.
>
> Which they do, because they will eventually notice they are burning money.

Assuming it is an uncontroversial hardfork (unlike bip101 in its
current form), miners will eventually upgrade because all users will
eventually upgrade as well.
Softfork-caused forks will live shortly because non-upgraded miners
will build on top of the longest upgraded chain.
In contrast, non-upgraded miners will not build on top of the longest
chain (the upgraded one assuming hashrate majority) and a parallel
chain will be built for some time. This chain can be used to defraud
non-upgraded or SPV users by isolating them and showing them only the
non-upgraded chain, which keeps growing but will eventually be
abandoned.
In the case of a Schism hardfork, some users may never want to
"upgrade" and if there's demand for the "old coins" there will be
miners for the "old chain".

> Sorry Jorge, but I don't think your argument makes sense.

I think my argument makes a lot of sense, it's just that for some
reason you don't think guaranteed eventual consistency has any value
because you are ok with miners abandoning the old rules chain only
eventually (and you don't believe that "eventually" can be far in the
future in practice).

On Wed, Sep 30, 2015 at 9:56 PM, Mike Hearn via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> Adam has said "there is actually consensus", although I just said there
> isn't. Feel free to say what you really mean here Adam - there's consensus
> if you ignore people who don't agree, i.e. the concept of "developer
> consensus" doesn't actually mean anything. This would contradict your prior
> statements about how Bitcoin Core makes decisions, but alright ....

BIP99 doesn't talk about "developer consensus", but rather
"uncontroversial consensus rule changes".
Obviously a patch in which developers steal everybody else's coins
wouldn't be "uncontroversial" even if "developer consensus" is
reached.
We don't need to ignore anyone to consider BIP65 an uncontroversial
softfork: we just need to ignore fallacious and unreasonable
arguments.
As far as I can tell, you are the only person opposing BIP65 (even if
you keep talking about "several people") and I would like to think
that you are aren't being obstinate on purpose only to make your point
about "developer consensus not meaning anything", but you are making
it very hard.

On Wed, Sep 30, 2015 at 11:01 PM, Mike Hearn via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> I coined the term SPV so I know exactly what it means, and bitcoinj
> implements it, as does BreadWallet (the other big SPV implementation).

No, you didn't. "Simplified Payment Verification" is section 8 in the
Bitcoin whitepaper that you like to cite so much.

> I'm going to ignore the rest of the stuff you wrote about "design decisions
> to lack security" or "cheaply avoidable lack of validation". When you have
> sat down and written an SPV implementation by yourself, then shipped it to a
> couple of million users, you might have better insight into basic
> engineering costs. Until then, I find your criticisms of code you think was
> missing due to "stonewalling" and so on to be seriously lacking real world
> experience.

Please study this page carefully and hopefully one day you will stop
using logical fallacies as often as you currently do:
https://en.wikipedia.org/wiki/List_of_fallacies
In this case you manage to combine ad hominem and appeal to authority
(maybe false authority is more accurate?).
Once again, please, stop using fallacies to try to convince people
that you are right. No offense, but being warned publicly about the
use of logical fallacies so often would be extremely embarrassing to
me.