1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <tier.nolan@gmail.com>) id 1YtaHQ-0005m6-Gs
for bitcoin-development@lists.sourceforge.net;
Sat, 16 May 2015 11:29:20 +0000
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;
Received: from mail-qk0-f180.google.com ([209.85.220.180])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YtaHP-0004D1-Ha
for bitcoin-development@lists.sourceforge.net;
Sat, 16 May 2015 11:29:20 +0000
Received: by qkgx75 with SMTP id x75so85561404qkg.1
for <bitcoin-development@lists.sourceforge.net>;
Sat, 16 May 2015 04:29:14 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.55.49.12 with SMTP id x12mr8642964qkx.21.1431775754134; Sat,
16 May 2015 04:29:14 -0700 (PDT)
Received: by 10.140.85.241 with HTTP; Sat, 16 May 2015 04:29:14 -0700 (PDT)
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
X-Spam-Score: 2.4 (++)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(tier.nolan[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.2 MISSING_HEADERS Missing To: header
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
1.9 MALFORMED_FREEMAIL Bad headers on message from free email service
-0.1 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1YtaHP-0004D1-Ha
Subject: Re: [Bitcoin-development] Block Size Increase Requirements
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Sat, 16 May 2015 11:29:20 -0000
--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"><<a href=3D"mailt=
o:stephencalebmorse@gmail.com" target=3D"_blank">stephencalebmorse@gmail.co=
m</a>></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' 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', 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'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'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 -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>"Why are my transac=
tions taking longer to confirm?"<br><br></div><div>"There was a s=
oft fork to make the block size larger and your client is being careful.=C2=
=A0 You need to add "minermaxblocksize=3D4MB" to your bitcoin.con=
f file."<br><br></div><div>Hah, it could be called a "semi-hard f=
ork"?<br></div></div></div></div>
--001a11477b6e3929c3051631450b--
|
