summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorSteven Pine <steven.pine@gmail.com>2016-02-07 17:25:40 -0500
committerbitcoindev <bitcoindev@gnusha.org>2016-02-07 22:25:42 +0000
commit2dde18bb8418ba00678cccf87dd97e8e34be24ce (patch)
treed018796e2291f351ef5c4112bdcdd6b5ab36c333
parent7d9dd1c8c2c77e83fd4aa3a2b89227506f68d407 (diff)
downloadpi-bitcoindev-2dde18bb8418ba00678cccf87dd97e8e34be24ce.tar.gz
pi-bitcoindev-2dde18bb8418ba00678cccf87dd97e8e34be24ce.zip
Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes
-rw-r--r--25/eae7d4bc7b3ad61e99617197b56a086d2b8bb3410
1 files changed, 410 insertions, 0 deletions
diff --git a/25/eae7d4bc7b3ad61e99617197b56a086d2b8bb3 b/25/eae7d4bc7b3ad61e99617197b56a086d2b8bb3
new file mode 100644
index 000000000..6c8c9ec63
--- /dev/null
+++ b/25/eae7d4bc7b3ad61e99617197b56a086d2b8bb3
@@ -0,0 +1,410 @@
+Return-Path: <steven.pine@gmail.com>
+Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
+ [172.17.192.35])
+ by mail.linuxfoundation.org (Postfix) with ESMTPS id 8139AB14
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Sun, 7 Feb 2016 22:25:42 +0000 (UTC)
+X-Greylist: whitelisted by SQLgrey-1.7.6
+Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com
+ [209.85.214.181])
+ by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3B3F0100
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Sun, 7 Feb 2016 22:25:41 +0000 (UTC)
+Received: by mail-ob0-f181.google.com with SMTP id wb13so133715988obb.1
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Sun, 07 Feb 2016 14:25:41 -0800 (PST)
+DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
+ h=mime-version:in-reply-to:references:date:message-id:subject:from:to
+ :cc:content-type;
+ bh=rwwVs6gDo+mxWRbB1suBK7xYDZXC4+vdT4Ig2VMUp/k=;
+ b=x0d0z9KtB+Lh434dbYmJXYqwGkcdSOvssENC8vuwQ00WrJjLGZqXEV2+QZvCLIKQ6o
+ yqGs74GLWcR38V/rXHdxabICkN5teef2IXcxXQVsvmjkjET+qIJiM2m3TC7NE+AYB+J5
+ cnvLzBb2To1HkaT1X0HrmH9mD4c6LOhNH6c2YFCqOv3/7pWB6/ODnx24eUsCh9KFYotY
+ OtRAbpG613eykwKQPGLnc+3E1Vgb2/hGj+81ZIXE5rKR2s7G/pWCrgFwQYdmR860/oPU
+ IbQca8tiB/SUNywYpgm37YpMjs9Kj8Iq9HRrS+aJletnzj04dfAXy/QVlhUfmIotZckv
+ Sb0g==
+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=rwwVs6gDo+mxWRbB1suBK7xYDZXC4+vdT4Ig2VMUp/k=;
+ b=NuB/j0vjiDZe7DHEd+mb2SkxhBCkpIyFOAwCvrPF65yOvJLcSWKrAI3yz9ObhcWogt
+ tWyEhq/QpUKI5tmumP8LOIoN/UbX50ehDc58FIfrU4VvQe1LvBNVWLX/RrKOQeTONtOR
+ CCvAuxtPzQt+vOMpWvjT0Z3FCvqhc58TQog1JFOISicCcGBi6waQOhN3riFgpmgMAxv4
+ 8Zaivg442/4r+dDBNxtt6Ajv8RI+aUxNRtMMmxf4ytQChdWjwQpl2jsA/mnDb7FAgfhi
+ BozswnmTz2aJ3uwTy2qpxzNfN09J+MX/Fob0GKvc3+r7AVoLhF9maOwpQqCaGgXVBON+
+ 2r8A==
+X-Gm-Message-State: AG10YOS/cI4Dd6CLMdEax3+0ZRNJJ8yW2vbwCC/IqOyhssV1KmIfyNiaK4G4T9Hec9xMBfQGS0SDc11ysFad8A==
+MIME-Version: 1.0
+X-Received: by 10.182.131.194 with SMTP id oo2mr21137715obb.84.1454883940632;
+ Sun, 07 Feb 2016 14:25:40 -0800 (PST)
+Received: by 10.182.246.33 with HTTP; Sun, 7 Feb 2016 14:25:40 -0800 (PST)
+In-Reply-To: <CAK_HAC-YDObNzgVYvrYYRPSEpa6CrLadqV+HSYggNZOtjAZGpA@mail.gmail.com>
+References: <CABsx9T1Bd0-aQg-9uRa4u3dGA5fKxaj8-mEkxVzX8mhdj4Gt2g@mail.gmail.com>
+ <201602062046.40193.luke@dashjr.org>
+ <CABsx9T0N_TBbmy3xr-mqNDdKVF_3_QHYA1W2ttsZBQnt4dWxgw@mail.gmail.com>
+ <201602072101.15142.luke@dashjr.org>
+ <CAAjy6kDd_1wY=Zrwnp4FZ_b0C0C06ThTLSPZq06Yjh178DuOkA@mail.gmail.com>
+ <CAK_HAC-YDObNzgVYvrYYRPSEpa6CrLadqV+HSYggNZOtjAZGpA@mail.gmail.com>
+Date: Sun, 7 Feb 2016 17:25:40 -0500
+Message-ID: <CAAjy6kD4BDo+k0MMGEMiRd7p7=4_v4C84NXahcQR7kACgp24_w@mail.gmail.com>
+From: Steven Pine <steven.pine@gmail.com>
+To: Corey Haddad <corey3@gmail.com>
+Content-Type: multipart/alternative; boundary=089e01634b8a788f9a052b3590a8
+X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
+ DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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
+X-Mailman-Approved-At: Mon, 08 Feb 2016 00:48:13 +0000
+Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
+Subject: Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2
+ megabytes
+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: Sun, 07 Feb 2016 22:25:42 -0000
+
+--089e01634b8a788f9a052b3590a8
+Content-Type: text/plain; charset=UTF-8
+
+I agree that it seems like a safe assumption that adoption would be faster,
+whether it is "very safe" and "significantly faster", whether it will be 6
+times faster, all of those assumptions seems significantly less safe and
+robust to me.
+
+The nature of the bitcoin protocol, that it is a decentralized census based
+protocol involving currency, suggests to me that roll out schedules ought
+to be conservative with a minimum of assumptions. In light of the most
+recent protocol upgrade, 6 months for this hard fork seems to me to be the
+most conservative time frame with the fewest assumptions.
+
+As for why it needs to be so fast, ie what are the dangers of it being as
+slow as 6 months?
+
+Gavin writes:
+
+"I strongly disagree with the statement that there is no cost to a longer
+grace period. There is broad agreement that a capacity increase is needed
+NOW."
+
+~~
+"Broad agreement", that really seems to be another assumption, the fact
+that the debate has been as long and acrimonious as it has been suggests
+that there isn't broad agreement. Also, resorting to "SHOUTING" doesn't win
+any favors when it comes to engaging in reasonable discussion om the
+technical merits of a proposal.
+
+
+
+On Sun, Feb 7, 2016 at 5:04 PM, Corey Haddad <corey3@gmail.com> wrote:
+
+> We don't have any evidence of how fast nodes will upgrade when faced with
+> an impending hard fork, but it seems like a very safe assumption that the
+> upgrade pace will be significantly faster. The hard fork case it is:
+> "upgrade or be kicked off the network". In the previous cases it has been,
+> "here's the latest and greatest, give it a go!". Also, there will be
+> alerts sent out warning people of the situation, prompting them to take
+> action.
+>
+> It is unclear if this will translate into more or less than 6x the
+> adoption speed of previous instances, but the idea that it would be faster
+> is solid. 28 days is aggressive, but again, it is only 28 days from when
+> the fork triggers. Compatible software is already available for anyone who
+> wants to prepare.
+>
+> It is also of significance that this proposed fork, and this debate, has
+> been going on for many, many months. If someone proposed a forking concept
+> today, wrote the BIP tomorrow, deployed it next week, miners adopted it
+> instantly, and 28 days later it was the flag day, those 28 days would be in
+> a different context. There is no surprise here.
+>
+> On Sun, Feb 7, 2016 at 1:33 PM, Steven Pine via bitcoin-dev <
+> bitcoin-dev@lists.linuxfoundation.org> wrote:
+>
+>> Is it me or did Gavin ignore Yifu's direct questions? In case you missed
+>> it Gavin --
+>>
+>> ~
+>> "We can look at the adoption of the last major Bitcoin core release to
+>> guess how long it might take people to upgrade. 0.11.0 was released on 12
+>> July, 2015. Twenty eight days later, about 38% of full nodes were
+>> running that release. Three months later, about 50% of the network was
+>> running that release, and six months later about 66% of the network was
+>> running some flavor of 0.11."
+>>
+>> On what grounds do you think it is reasonable to assume that this update
+>> will roll out 6x faster than previous data suggested, as oppose to your own
+>> observation of 66% adoption in 6 month. or do you believe 38% node
+>> upgrade-coverage (in 28 days ) on the network for a hard fork is good
+>> enough?
+>>
+>> There are no harm in choosing a longer grace period but picking one short
+>> as 28 days you risk on alienating the nodes who do not upgrade with the
+>> aggressive upgrade timeline you proposed.
+>> ~~
+>>
+>> When Gavin writes "Responding to "28 days is not long enough" :
+>>
+>> I keep seeing this claim made with no evidence to back it up. As I said,
+>> I surveyed several of the biggest infrastructure providers and the btcd
+>> lead developer and they all agree "28 days is plenty of time."
+>>
+>> For individuals... why would it take somebody longer than 28 days to
+>> either download and restart their bitcoind, or to patch and then re-run
+>> (the patch can be a one-line change MAX_BLOCK_SIZE from 1000000 to
+>> 2000000)?"
+>>
+>> ~~
+>>
+>> Isn't Yifu's comment, evidence, the very best sort of evidence, it isn't
+>> propositional a priori logic, but empirical evidence that. As for why
+>> people take longer, who knows, we simply know from passed experience that
+>> it in fact does take longer.
+>>
+>> It's extremely frustrating to read Gavin's comments, it's hard to believe
+>> he is engaging in earnest discussion.
+>>
+>> On Sun, Feb 7, 2016 at 4:01 PM, Luke Dashjr via bitcoin-dev <
+>> bitcoin-dev@lists.linuxfoundation.org> wrote:
+>>
+>>> On Sunday, February 07, 2016 2:16:02 PM Gavin Andresen wrote:
+>>> > On Sat, Feb 6, 2016 at 3:46 PM, Luke Dashjr via bitcoin-dev <
+>>> > bitcoin-dev@lists.linuxfoundation.org> wrote:
+>>> > > On Saturday, February 06, 2016 5:25:21 PM Tom Zander via bitcoin-dev
+>>> wrote:
+>>> > > > If you have a node that is "old" your node will stop getting new
+>>> > > > blocks. The node will essentially just say "x-hours behind" with
+>>> "x"
+>>> > > > getting larger every hour. Funds don't get confirmed. etc.
+>>> > >
+>>> > > Until someone decides to attack you. Then you'll get 6, 10, maybe
+>>> more
+>>> > > blocks confirming a large 10000 BTC payment. If you're just a normal
+>>> end
+>>> > > user (or perhaps an automated system), you'll figure that payment is
+>>> good
+>>> > > and irreversibly hand over the title to the house.
+>>> >
+>>> > There will be approximately zero percentage of hash power left on the
+>>> > weaker branch of the fork, based on past soft-fork adoption by miners
+>>> (they
+>>> > upgrade VERY quickly from 75% to over 95%).
+>>>
+>>> I'm assuming there are literally ZERO miners left on the weaker branch.
+>>> The attacker in this scenario simply rents hashing for a few days in
+>>> advance
+>>> to build his fake chain, then broadcasts the blocks to the unsuspecting
+>>> merchant at ~10 block intervals so it looks like everything is working
+>>> normal
+>>> again. There are lots of mining rental services out there, and miners
+>>> quite
+>>> often do not care to avoid selling hashrate to the highest bidder
+>>> regardless
+>>> of what they're mining. 10 blocks worth costs a little more than 250 BTC
+>>> -
+>>> soon, that will be 125 BTC.
+>>>
+>>> Luke
+>>> _______________________________________________
+>>> bitcoin-dev mailing list
+>>> bitcoin-dev@lists.linuxfoundation.org
+>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
+>>>
+>>
+>>
+>>
+>> --
+>> Steven Pine
+>> (510) 517-7075
+>>
+>> _______________________________________________
+>> bitcoin-dev mailing list
+>> bitcoin-dev@lists.linuxfoundation.org
+>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
+>>
+>>
+>
+
+
+--
+Steven Pine
+(510) 517-7075
+
+--089e01634b8a788f9a052b3590a8
+Content-Type: text/html; charset=UTF-8
+Content-Transfer-Encoding: quoted-printable
+
+<div dir=3D"ltr">I agree that it seems like a safe assumption that adoption=
+ would be faster, whether it is &quot;very safe&quot; and &quot;significant=
+ly faster&quot;, whether it will be 6 times faster, all of those assumption=
+s seems significantly less safe and robust to me.<div><br></div><div>The na=
+ture of the bitcoin protocol, that it is a decentralized census based proto=
+col involving currency, suggests to me that roll out schedules ought to be =
+conservative with a minimum of assumptions. In light of the most recent pro=
+tocol upgrade, 6 months for this hard fork seems to me to be the most conse=
+rvative time frame with the fewest assumptions.</div><div><br></div><div>As=
+ for why it needs to be so fast, ie what are the dangers of it being as slo=
+w as 6 months?</div><div><br></div><div>Gavin writes:</div><div><br></div><=
+div>&quot;<span style=3D"font-size:12.8px">I strongly disagree with the sta=
+tement that there is no cost to a longer grace period. There is broad agree=
+ment that a capacity increase is needed NOW.&quot;</span></div><div><span s=
+tyle=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size:12=
+.8px">~~</span></div><div><span style=3D"font-size:12.8px">&quot;Broad agre=
+ement&quot;, that really seems to be another assumption, the fact that the =
+debate has been as long and=C2=A0acrimonious as it has been suggests that t=
+here isn&#39;t broad agreement. Also, resorting to &quot;SHOUTING&quot; doe=
+sn&#39;t win any favors when it comes to engaging in reasonable discussion =
+om the technical merits of a proposal.</span></div><div><span style=3D"font=
+-size:12.8px">=C2=A0</span></div><div><br></div></div><div class=3D"gmail_e=
+xtra"><br><div class=3D"gmail_quote">On Sun, Feb 7, 2016 at 5:04 PM, Corey =
+Haddad <span dir=3D"ltr">&lt;<a href=3D"mailto:corey3@gmail.com" target=3D"=
+_blank">corey3@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmai=
+l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
+:1ex"><div dir=3D"ltr"><div>We don&#39;t have any evidence of how fast node=
+s will upgrade when faced with an impending hard fork, but it seems like a =
+very safe assumption that the upgrade pace will be significantly faster.=C2=
+=A0 The hard fork case it is: &quot;upgrade or be kicked off the network&qu=
+ot;.=C2=A0 In the previous cases it has been, &quot;here&#39;s the latest a=
+nd greatest, give it a go!&quot;.=C2=A0 Also, there will be alerts sent out=
+ warning people of the situation, prompting them to take action.<br><br></d=
+iv><div>It is unclear if this will translate into more or less than 6x the =
+adoption speed of previous instances, but the idea that it would be faster =
+is solid.=C2=A0 28 days is aggressive, but again, it is only 28 days from w=
+hen the fork triggers.=C2=A0 Compatible software is already available for a=
+nyone who wants to prepare.<br><br></div><div>It is also of significance th=
+at this proposed fork, and this debate, has been going on for many, many mo=
+nths.=C2=A0 If someone proposed a forking concept today, wrote the BIP tomo=
+rrow, deployed it next week, miners adopted it instantly, and 28 days later=
+ it was the flag day, those 28 days would be in a different context.=C2=A0 =
+There is no surprise here. <br></div></div><div class=3D"HOEnZb"><div class=
+=3D"h5"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sun, F=
+eb 7, 2016 at 1:33 PM, Steven Pine via bitcoin-dev <span dir=3D"ltr">&lt;<a=
+ href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bi=
+tcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote cl=
+ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
+adding-left:1ex"><div dir=3D"ltr"><div>Is it me or did Gavin ignore Yifu&#3=
+9;s direct questions? In case you missed it Gavin --</div><div><br></div><d=
+iv>~</div><span><span style=3D"font-size:12.8px">&quot;We can look at the a=
+doption of the last major Bitcoin core release to guess how long it might t=
+ake people to upgrade. 0.11.0 was released on 12 July, 2015. Twenty=C2=A0</=
+span><span style=3D"font-size:12.8px"><span>eight days later</span></span><=
+span style=3D"font-size:12.8px">, about 38% of full nodes were running that=
+ release.=C2=A0</span><span style=3D"font-size:12.8px"><span>Three months l=
+ater</span></span><span style=3D"font-size:12.8px">, about 50% of the netwo=
+rk was running that release, and=C2=A0</span><span style=3D"font-size:12.8p=
+x"><span>six months later</span></span><span style=3D"font-size:12.8px">=C2=
+=A0about 66% of the network was running some flavor of 0.11.&quot;</span><d=
+iv style=3D"font-size:12.8px"><br></div></span><div style=3D"font-size:12.8=
+px">On what grounds do you think it is reasonable to assume that this updat=
+e will roll out 6x faster than previous data suggested, as oppose to your o=
+wn observation of 66% adoption=C2=A0<span><span>in 6 month</span></span>. o=
+r do you believe 38% node upgrade-coverage (<span><span>in 28 days</span></=
+span>=C2=A0) on the network for a hard fork is good enough?</div><span><div=
+ style=3D"font-size:12.8px"><br></div><div style=3D"font-size:12.8px">There=
+ are no harm in choosing a longer grace period but picking one short as 28 =
+days you risk on alienating the nodes who do not upgrade with the aggressiv=
+e upgrade timeline you proposed.</div></span><div>~~</div><div><br></div><d=
+iv>When Gavin writes &quot;<span style=3D"font-size:12.8px">Responding to &=
+quot;28 days is not long enough&quot; :</span></div><span><div style=3D"fon=
+t-size:12.8px"><br></div><div style=3D"font-size:12.8px">I keep seeing this=
+ claim made with no evidence to back it up.=C2=A0 As I said, I surveyed sev=
+eral of the biggest infrastructure providers and the btcd lead developer an=
+d they all agree &quot;28 days is plenty of time.&quot;</div><div style=3D"=
+font-size:12.8px"><br></div></span><span><div style=3D"font-size:12.8px">Fo=
+r individuals... why would it take somebody longer than 28 days to either d=
+ownload and restart their bitcoind, or to patch and then re-run (the patch =
+can be a one-line change MAX_BLOCK_SIZE from 1000000 to 2000000)?&quot;</di=
+v><div style=3D"font-size:12.8px"><br></div></span><div style=3D"font-size:=
+12.8px">~~</div><div style=3D"font-size:12.8px"><br></div><div style=3D"fon=
+t-size:12.8px">Isn&#39;t Yifu&#39;s comment, evidence, the very best sort o=
+f evidence, it isn&#39;t propositional a priori logic, but empirical eviden=
+ce that. As for why people take longer, who knows, we simply know from pass=
+ed experience that it in fact does take longer.</div><div style=3D"font-siz=
+e:12.8px"><br></div><div style=3D"font-size:12.8px">It&#39;s extremely frus=
+trating to read Gavin&#39;s comments, it&#39;s hard to believe he is engagi=
+ng in earnest discussion.</div></div><div class=3D"gmail_extra"><div><div><=
+br><div class=3D"gmail_quote">On Sun, Feb 7, 2016 at 4:01 PM, Luke Dashjr v=
+ia bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.li=
+nuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org<=
+/a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:=
+0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Sunday, Fe=
+bruary 07, 2016 2:16:02 PM Gavin Andresen wrote:<br>
+&gt; On Sat, Feb 6, 2016 at 3:46 PM, Luke Dashjr via bitcoin-dev &lt;<br>
+&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
+ank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
+&gt; &gt; On Saturday, February 06, 2016 5:25:21 PM Tom Zander via bitcoin-=
+dev<br>
+wrote:<br>
+</span><span>&gt; &gt; &gt; If you have a node that is &quot;old&quot; your=
+ node will stop getting new<br>
+&gt; &gt; &gt; blocks. The node will essentially just say &quot;x-hours beh=
+ind&quot; with &quot;x&quot;<br>
+&gt; &gt; &gt; getting larger every hour. Funds don&#39;t get confirmed. et=
+c.<br>
+&gt; &gt;<br>
+&gt; &gt; Until someone decides to attack you. Then you&#39;ll get 6, 10, m=
+aybe more<br>
+&gt; &gt; blocks confirming a large 10000 BTC payment. If you&#39;re just a=
+ normal end<br>
+&gt; &gt; user (or perhaps an automated system), you&#39;ll figure that pay=
+ment is good<br>
+&gt; &gt; and irreversibly hand over the title to the house.<br>
+&gt;<br>
+&gt; There will be approximately zero percentage of hash power left on the<=
+br>
+&gt; weaker branch of the fork, based on past soft-fork adoption by miners =
+(they<br>
+&gt; upgrade VERY quickly from 75% to over 95%).<br>
+<br>
+</span>I&#39;m assuming there are literally ZERO miners left on the weaker =
+branch.<br>
+The attacker in this scenario simply rents hashing for a few days in advanc=
+e<br>
+to build his fake chain, then broadcasts the blocks to the unsuspecting<br>
+merchant at ~10 block intervals so it looks like everything is working norm=
+al<br>
+again. There are lots of mining rental services out there, and miners quite=
+<br>
+often do not care to avoid selling hashrate to the highest bidder regardles=
+s<br>
+of what they&#39;re mining. 10 blocks worth costs a little more than 250 BT=
+C -<br>
+soon, that will be 125 BTC.<br>
+<div><div><br>
+Luke<br>
+_______________________________________________<br>
+bitcoin-dev mailing list<br>
+<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
+bitcoin-dev@lists.linuxfoundation.org</a><br>
+<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
+rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
+man/listinfo/bitcoin-dev</a><br>
+</div></div></blockquote></div><br><br clear=3D"all"><div><br></div></div><=
+/div><span><font color=3D"#888888">-- <br><div><div dir=3D"ltr"><div>Steven=
+ Pine<div><a href=3D"tel:%28510%29%20517-7075" value=3D"+15105177075" targe=
+t=3D"_blank">(510) 517-7075</a></div></div></div></div>
+</font></span></div>
+<br>_______________________________________________<br>
+bitcoin-dev mailing list<br>
+<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
+bitcoin-dev@lists.linuxfoundation.org</a><br>
+<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
+rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
+man/listinfo/bitcoin-dev</a><br>
+<br></blockquote></div><br></div>
+</div></div></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>=
+<div class=3D"gmail_signature"><div dir=3D"ltr"><div>Steven Pine<div>(510) =
+517-7075</div></div></div></div>
+</div>
+
+--089e01634b8a788f9a052b3590a8--
+