From: "Jorge Timón" <jtimon@jtimon•cc>
To: Mike Hearn <hearn@vinumeris•com>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!
Date: Thu, 1 Oct 2015 00:14:21 +0200 [thread overview]
Message-ID: <CABm2gDqAhjd1721XPjjAiev4coveLM0NUE9ng+W2tgswHiW5bg@mail.gmail.com> (raw)
In-Reply-To: <CA+w+GKTf2vnJ0WdrK1HzFwCx154e=BP=kGcZvGYY7cbcijwLSQ@mail.gmail.com>
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.
next prev parent reply other threads:[~2015-09-30 22:14 UTC|newest]
Thread overview: 101+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-27 18:50 Peter Todd
2015-09-27 20:26 ` jl2012
2015-09-27 20:27 ` Peter Todd
2015-09-27 20:27 ` Mark Friedenbach
2015-09-27 20:41 ` Btc Drak
2015-09-28 10:10 ` s7r
2015-09-28 10:48 ` Mike Hearn
2015-09-28 11:00 ` Adam Back
2015-09-28 11:40 ` Mike Hearn
2015-09-28 12:20 ` Eric Lombrozo
2015-09-28 12:26 ` Mike Hearn
2015-09-28 12:44 ` Eric Lombrozo
2015-09-28 12:54 ` Mike Hearn
2015-09-29 6:17 ` Eric Lombrozo
2015-09-29 12:02 ` Mike Hearn
2015-09-28 14:05 ` Btc Drak
2015-09-28 14:17 ` Mike Hearn
2015-09-28 21:12 ` odinn
2015-09-28 22:16 ` Dave Scotese
2015-09-28 11:04 ` Eric Lombrozo
2015-09-28 12:47 ` Tier Nolan
2015-09-28 13:01 ` Gavin Andresen
2015-09-28 13:28 ` Peter Todd
2015-09-28 13:43 ` Gavin Andresen
2015-09-28 14:14 ` Peter Todd
2015-09-28 13:21 ` Peter Todd
2015-09-28 13:41 ` Mike Hearn
2015-09-28 14:29 ` Peter Todd
2015-09-28 14:33 ` Mike Hearn
2015-09-28 14:43 ` Peter Todd
2015-09-28 14:51 ` Mike Hearn
2015-09-28 15:05 ` Peter Todd
2015-09-28 15:38 ` Mike Hearn
2015-09-28 16:52 ` jl2012
2015-09-28 17:14 ` Mike Hearn
2015-09-28 23:17 ` Jorge Timón
2015-09-29 12:07 ` Mike Hearn
2015-09-29 15:09 ` [bitcoin-dev] Why soft-forks? was: " Santino Napolitano
2015-09-29 13:30 ` [bitcoin-dev] " Jonathan Toomim (Toomim Bros)
2015-09-29 15:59 ` jl2012
2015-09-29 19:54 ` odinn
2015-09-29 18:31 ` Gregory Maxwell
2015-09-30 17:11 ` Mike Hearn
2015-09-30 17:58 ` Jorge Timón
2015-10-01 14:23 ` Tom Harding
2015-09-30 18:15 ` Adam Back
2015-09-30 19:26 ` Jeff Garzik
2015-09-30 19:56 ` Mike Hearn
2015-09-30 20:37 ` Jorge Timón
2015-09-30 21:06 ` Mike Hearn
2015-09-30 22:14 ` Jorge Timón [this message]
2015-10-01 0:11 ` Jorge Timón
2015-09-30 22:17 ` Jeff Garzik
2015-09-30 23:25 ` Gregory Maxwell
2015-09-30 20:15 ` Gregory Maxwell
2015-09-30 21:01 ` Mike Hearn
2015-09-30 22:59 ` Gregory Maxwell
2015-10-01 4:08 ` [bitcoin-dev] Crossing the line? [Was: Re: Let's deploy BIP65 CHECKLOCKTIMEVERIFY!] Tao Effect
2015-10-01 16:39 ` Jeff Garzik
2015-10-01 20:17 ` Milly Bitcoin
2015-10-02 12:23 ` Mike Hearn
2015-10-02 13:14 ` jl2012
2015-10-02 14:10 ` Marcel Jamin
2015-10-02 16:37 ` Gregory Maxwell
2015-10-07 15:00 ` [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY! Anthony Towns
2015-10-07 15:46 ` Jonathan Toomim (Toomim Bros)
2015-10-07 16:02 ` Eric Lombrozo
2015-10-07 16:25 ` Eric Lombrozo
2015-10-07 16:26 ` Jonathan Toomim (Toomim Bros)
2015-10-07 16:38 ` Anthony Towns
2015-10-10 7:23 ` Anthony Towns
2015-10-12 7:02 ` digitsu
2015-10-12 16:33 ` Anthony Towns
2015-10-12 17:06 ` Anthony Towns
2015-10-13 0:08 ` digitsu
2015-09-29 20:03 ` Wladimir J. van der Laan
2015-09-30 4:05 ` Rusty Russell
2015-09-30 6:19 ` Adam Back
2015-09-30 12:30 ` Mike Hearn
2015-09-30 15:55 ` Jorge Timón
2015-09-30 19:17 ` John Winslow
2015-10-01 0:06 ` Rusty Russell
2015-09-30 17:14 ` Adam Back
2015-10-01 0:04 ` Rusty Russell
2015-10-02 1:57 NotMike Hearn
2015-10-02 2:12 ` GC
2015-10-05 10:59 ` Mike Hearn
2015-10-05 11:23 ` Jeff Garzik
2015-10-05 11:28 ` Mike Hearn
2015-10-05 12:04 ` Jorge Timón
2015-10-05 12:08 ` Clément Elbaz
2015-10-05 12:16 ` Jorge Timón
2015-10-05 12:29 ` Clément Elbaz
2015-10-05 15:42 ` Jorge Timón
2015-10-05 12:10 ` Mike Hearn
2015-10-05 15:33 ` Jorge Timón
2015-10-05 16:46 ` Mike Hearn
2015-10-06 6:20 ` Anthony Towns
2015-10-07 6:13 ` Micha Bailey
2015-10-05 13:29 ` Jorge Timón
2015-10-05 13:24 ` Jorge Timón
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CABm2gDqAhjd1721XPjjAiev4coveLM0NUE9ng+W2tgswHiW5bg@mail.gmail.com \
--to=jtimon@jtimon$(echo .)cc \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=hearn@vinumeris$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox