diff options
author | Jorge Timón <jtimon@jtimon.cc> | 2015-10-01 00:14:21 +0200 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2015-09-30 22:14:24 +0000 |
commit | 5123965de530ad0a7864eb56c5e5ae277aa5878e (patch) | |
tree | 5523b9cd5b84c168e7fe2c19eef7a688916e3cc1 /03/c2e5cff8127d8c576c68b0f12bc4bdbc83e051 | |
parent | 0e9ad23489d907e9e19d514832f7534eda2320d8 (diff) | |
download | pi-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/c2e5cff8127d8c576c68b0f12bc4bdbc83e051 | 154 |
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. + |