Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.220.180 as permitted sender)
	client-ip=209.85.220.180; envelope-from=tier.nolan@gmail.com;
	helo=mail-qk0-f180.google.com; 
MIME-Version: 1.0
In-Reply-To: <9BBD3F51-2FE0-4861-B045-6ACFC48AA21D@gmail.com>
References: <554BE0E1.5030001@bluematt.me>
	<CANEZrP3uKLvzKi-wXBJWL=pwqB+eAe3FbPjyESD52y5TGkg+Rg@mail.gmail.com>
	<20150508163701.GA27417@savin.petertodd.org>
	<CAE-z3OV8zyUyYiGNRZZbTkUZz70KK7P-ENyhsKe+yhZmNnqRuQ@mail.gmail.com>
	<20150509030833.GA28871@savin.petertodd.org>
	<9BBD3F51-2FE0-4861-B045-6ACFC48AA21D@gmail.com>
Date: Sat, 16 May 2015 12:29:14 +0100
Message-ID: <CAE-z3OURNR1rAkKR1L9B9VRjTLNCP8xaa1hW4V8D-KWhWycRdA@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a11477b6e3929c3051631450b
Subject: Re: [Bitcoin-development] Block Size Increase Requirements
Precedence: list

--001a11477b6e3929c3051631450b
Content-Type: text/plain; charset=UTF-8

On Sat, May 16, 2015 at 5:39 AM, Stephen <stephencalebmorse@gmail.com>
wrote:

> I think this could be mitigated by counting confirmations differently. We
> should think of confirmations as only coming from blocks following the
> miners' more strict rule set. So if a merchant were to see payment for the
> first time in a block that met their own size restrictions but not the
> miners', then they would simply count it as unconfirmed.
>

In effect, there is a confirm penalty for less strict blocks.  Confirms =
max(miner_confirms, merchant_confirms - 3, 0)

Merchants who don't upgrade end up having to wait longer to hit
confirmations.

If they get deep enough in the chain, though, the client should probably
> count them as being confirmed anyway, even if they don't meet the client
> nodes' expectation of the miners' block size limit. This happening probably
> just means that the client has not updated their software (or
> -minermaxblocksize configuration, depending on how it is implemented) in a
> long time.
>

That is a good idea.  Any parameters that have miner/merchant differences
should be modifiable (but only upwards) in the command line.

"Why are my transactions taking longer to confirm?"

"There was a soft fork to make the block size larger and your client is
being careful.  You need to add "minermaxblocksize=4MB" to your
bitcoin.conf file."

Hah, it could be called a "semi-hard fork"?

--001a11477b6e3929c3051631450b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
at, May 16, 2015 at 5:39 AM, Stephen <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:stephencalebmorse@gmail.com" target=3D"_blank">stephencalebmorse@gmail.co=
m</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
"><span class=3D"">
</span>I think this could be mitigated by counting confirmations differentl=
y. We should think of confirmations as only coming from blocks following th=
e miners&#39; more strict rule set. So if a merchant were to see payment fo=
r the first time in a block that met their own size restrictions but not th=
e miners&#39;, then they would simply count it as unconfirmed.<br></blockqu=
ote><div><br></div><div>In effect, there is a confirm penalty for less stri=
ct blocks.=C2=A0 Confirms =3D max(miner_confirms, merchant_confirms - 3, 0)=
<br></div><div>=C2=A0<br></div><div>Merchants who don&#39;t upgrade end up =
having to wait longer to hit confirmations.<br></div><div><br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex">
If they get deep enough in the chain, though, the client should probably co=
unt them as being confirmed anyway, even if they don&#39;t meet the client =
nodes&#39; expectation of the miners&#39; block size limit. This happening =
probably just means that the client has not updated their software (or -min=
ermaxblocksize configuration, depending on how it is implemented) in a long=
 time.<br></blockquote><div><br></div><div>That is a good idea.=C2=A0 Any p=
arameters that have miner/merchant differences should be modifiable (but on=
ly upwards) in the command line.<br><br></div><div>&quot;Why are my transac=
tions taking longer to confirm?&quot;<br><br></div><div>&quot;There was a s=
oft fork to make the block size larger and your client is being careful.=C2=
=A0 You need to add &quot;minermaxblocksize=3D4MB&quot; to your bitcoin.con=
f file.&quot;<br><br></div><div>Hah, it could be called a &quot;semi-hard f=
ork&quot;?<br></div></div></div></div>

--001a11477b6e3929c3051631450b--