summaryrefslogtreecommitdiff
path: root/03/c2e5cff8127d8c576c68b0f12bc4bdbc83e051
diff options
context:
space:
mode:
authorJorge Timón <jtimon@jtimon.cc>2015-10-01 00:14:21 +0200
committerbitcoindev <bitcoindev@gnusha.org>2015-09-30 22:14:24 +0000
commit5123965de530ad0a7864eb56c5e5ae277aa5878e (patch)
tree5523b9cd5b84c168e7fe2c19eef7a688916e3cc1 /03/c2e5cff8127d8c576c68b0f12bc4bdbc83e051
parent0e9ad23489d907e9e19d514832f7534eda2320d8 (diff)
downloadpi-bitcoindev-5123965de530ad0a7864eb56c5e5ae277aa5878e.tar.gz
pi-bitcoindev-5123965de530ad0a7864eb56c5e5ae277aa5878e.zip
Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!
Diffstat (limited to '03/c2e5cff8127d8c576c68b0f12bc4bdbc83e051')
-rw-r--r--03/c2e5cff8127d8c576c68b0f12bc4bdbc83e051154
1 files changed, 154 insertions, 0 deletions
diff --git a/03/c2e5cff8127d8c576c68b0f12bc4bdbc83e051 b/03/c2e5cff8127d8c576c68b0f12bc4bdbc83e051
new file mode 100644
index 000000000..647fa89f2
--- /dev/null
+++ b/03/c2e5cff8127d8c576c68b0f12bc4bdbc83e051
@@ -0,0 +1,154 @@
+Return-Path: <jtimon@jtimon.cc>
+Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
+ [172.17.192.35])
+ by mail.linuxfoundation.org (Postfix) with ESMTPS id C70A71E8F
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Wed, 30 Sep 2015 22:14:24 +0000 (UTC)
+X-Greylist: whitelisted by SQLgrey-1.7.6
+Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com
+ [209.85.212.172])
+ by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C5B3A203
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Wed, 30 Sep 2015 22:14:23 +0000 (UTC)
+Received: by wiclk2 with SMTP id lk2so3134989wic.1
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Wed, 30 Sep 2015 15:14:22 -0700 (PDT)
+X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
+ d=1e100.net; s=20130820;
+ h=x-gm-message-state:mime-version:in-reply-to:references:date
+ :message-id:subject:from:to:cc:content-type;
+ bh=ls/uOSZDnlljR6PA2YD0df54NQiHCemzFgGwaT4ZlAU=;
+ b=LADxV2jCf2WJQ+kLa3Bn5nai5gf3i4OqWf/Ikxu6vFI/5N4nzvF02eJQZXCYHnlcF0
+ I3o2I2UPchr8nSsJ+H/zmiezVIlj7PlVr7kfdvOC4VE9sReV3flHLH5l/JsfU5vWBxhr
+ 9FuB3Lk8xu9CnBCQFf2PDlhTEGCoHtV/EEjSNDH2X0tpbK7IAN0sjUuoY469eedU+uxO
+ DRFE1/B4yvMRSnlbr88QpZfygOwuGuyFNmjQvyOmfbu7SnGRnsY9XP2uGl8RYOJ++Qkt
+ AW5VjWX/nAdlAKti4uKkutXQMDXzr+SaOrO1NPwWdZ0kc4gUNDinSDqti891TBKqO6HC
+ U0lA==
+X-Gm-Message-State: ALoCoQkB/6UqTeIAYF+jDNbZMEwyhgef65z4cYeHtW2A2liW/k46x2qgb1RI31vtlnFDm71vusVY
+MIME-Version: 1.0
+X-Received: by 10.180.103.72 with SMTP id fu8mr34458741wib.7.1443651262226;
+ Wed, 30 Sep 2015 15:14:22 -0700 (PDT)
+Received: by 10.194.114.199 with HTTP; Wed, 30 Sep 2015 15:14:21 -0700 (PDT)
+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
+X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW
+ autolearn=ham version=3.3.1
+X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
+ smtp1.linux-foundation.org
+Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
+Subject: Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!
+X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
+X-Mailman-Version: 2.1.12
+Precedence: list
+List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
+List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
+ <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
+List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
+List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
+List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
+List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
+ <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
+X-List-Received-Date: Wed, 30 Sep 2015 22:14:24 -0000
+
+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.
+