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
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
|
Return-Path: <morcos@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id D167A98B
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 12 Nov 2015 21:21:58 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f177.google.com (mail-ig0-f177.google.com
[209.85.213.177])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 300D4AA
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 12 Nov 2015 21:21:58 +0000 (UTC)
Received: by igbxm8 with SMTP id xm8so2552811igb.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 12 Nov 2015 13:21:57 -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=0YWRL7hA6LBQO6SU3xW3liAQBRT9+YEbXpjxSuQLaKY=;
b=OZePCIK6iPKyL7x7f/DMcXUAIEBN7V2+lEuifNPXWS96FdMbo1lMsH9yel/YDl+oH3
9mlhdVW0q1+0bvODeujDAhyhgFuRFvD5t9bkNEI6QKNwZEWTaapykDNQDwXS31zMnu0p
DKvXxf06osZ6J+tvQYPoWijXG5u3/uNqRge0WFnHsf30BiFWHnhzFpicLNL6IfB1017+
Dr8iSPsdA6qDyneOV+JM9IPmZ3FQwYFgsirURdywr+wb6X5sAvdV9y0XCpTrmjxhKrg7
Vue00QogylDLMEQxwM63ZFZbCyNeKoKvA+SuxB9fwIJig4p00dtz8rKblKyxP4sDj+jA
G/yg==
MIME-Version: 1.0
X-Received: by 10.50.30.101 with SMTP id r5mr17914477igh.35.1447363317609;
Thu, 12 Nov 2015 13:21:57 -0800 (PST)
Received: by 10.64.25.18 with HTTP; Thu, 12 Nov 2015 13:21:57 -0800 (PST)
In-Reply-To: <201511122110.47665.luke@dashjr.org>
References: <5644ECE6.9090304@mattcorallo.com>
<201511122012.29966.luke@dashjr.org>
<CABm2gDqnmR5eAEZj_CRJ6Q5gi8LM_chb3tBCt2=L9ojr+Ziadw@mail.gmail.com>
<201511122110.47665.luke@dashjr.org>
Date: Thu, 12 Nov 2015 16:21:57 -0500
Message-ID: <CAPWm=eXNFimrG1A7bxJ3i=w_iWm57r93bjfiGZwq9y8KbZ8+Qg@mail.gmail.com>
From: Alex Morcos <morcos@gmail.com>
To: Luke Dashjr <luke@dashjr.org>
Content-Type: multipart/alternative; boundary=047d7bdca97e683d6305245e8841
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: Thu, 12 Nov 2015 21:23:35 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Upcoming Transaction Priority Changes
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: Thu, 12 Nov 2015 21:21:58 -0000
--047d7bdca97e683d6305245e8841
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
To be clear Luke, its not THAT complicated to maintain the mining policy,
but preserving the ability of people to place priority based transactions
in a limited mempool world is quite complicated. See recently closed
#6992.
I think the biggest issue with #6357 is being sure the logic doesn't break
in future changes. There are a lot of things that need to be updated in
the right order when blocks are connected or disconnected.
And whats the point of having even that added extra complication if its not
easy to place free transactions and starting priority is a decent
approximation for mining anyway (txs can just be rebroadcast in the worst
case).
On Thu, Nov 12, 2015 at 4:10 PM, Luke Dashjr via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Thursday, November 12, 2015 8:43:17 PM Jorge Tim=C3=B3n wrote:
> > On Thu, Nov 12, 2015 at 9:12 PM, Luke Dashjr via bitcoin-dev
> > <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > > On Thursday, November 12, 2015 7:47:50 PM Matt Corallo via bitcoin-de=
v
> > > wrote:
> > >> * Mining code will use starting priority for ease of implementation
> > >
> > > This should be optional, at least for 0.12.
> >
> > The ease of implementation is not gained if it's maintained optionally.
>
> It has come to my attention maintaining the current priority algorithm is
> not
> even expensive, so I think I'm inclined to NACK using starting priority
> altogether. Since I am the mining maintainer for Core, I believe it's
> reasonable for me to decide on maintenance tradeoffs...
>
> Therefore, my goal in this matter will be to review #6357 in depth to be
> merged, and follow up with #6898 based on the current default policies.
>
> > >> * Default block priority size will be 0
> > >
> > > We should not be influencing miner policy by changing defaults.
> >
> > I agree changing policy defaults is meaningless, but in this case it
> > is supposed to signal deprecation of the policy option.
>
> This is a bad idea anyway, since priority is the best metric we have righ=
t
> now
> for ensuring legitimate transactions get mined despite spam attacks.
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--047d7bdca97e683d6305245e8841
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">To be clear Luke, its not THAT complicated to maintain the=
mining policy, but preserving the ability of people to place priority base=
d transactions in a limited mempool world is quite complicated.=C2=A0 See r=
ecently closed #6992.=C2=A0<div>I think the biggest issue with #6357 is bei=
ng sure the logic doesn't break in future changes.=C2=A0 There are a lo=
t of things that need to be updated in the right order when blocks are conn=
ected or disconnected.<div>And whats the point of having even that added ex=
tra complication if its not easy to place free transactions and starting pr=
iority is a decent approximation for mining anyway (txs can just be rebroad=
cast in the worst case).<br><div><br></div></div></div></div><div class=3D"=
gmail_extra"><br><div class=3D"gmail_quote">On Thu, Nov 12, 2015 at 4:10 PM=
, Luke Dashjr via bitcoin-dev <span dir=3D"ltr"><<a href=3D"mailto:bitco=
in-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linux=
foundation.org</a>></span> wrote:<br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><spa=
n class=3D"">On Thursday, November 12, 2015 8:43:17 PM Jorge Tim=C3=B3n wro=
te:<br>
> On Thu, Nov 12, 2015 at 9:12 PM, Luke Dashjr via bitcoin-dev<br>
> <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-d=
ev@lists.linuxfoundation.org</a>> wrote:<br>
> > On Thursday, November 12, 2015 7:47:50 PM Matt Corallo via bitcoi=
n-dev<br>
> > wrote:<br>
> >>=C2=A0 * Mining code will use starting priority for ease of im=
plementation<br>
> ><br>
> > This should be optional, at least for 0.12.<br>
><br>
> The ease of implementation is not gained if it's maintained option=
ally.<br>
<br>
</span>It has come to my attention maintaining the current priority algorit=
hm is not<br>
even expensive, so I think I'm inclined to NACK using starting priority=
<br>
altogether. Since I am the mining maintainer for Core, I believe it's<b=
r>
reasonable for me to decide on maintenance tradeoffs...<br>
<br>
Therefore, my goal in this matter will be to review #6357 in depth to be<br=
>
merged, and follow up with #6898 based on the current default policies.<br>
<span class=3D""><br>
> >>=C2=A0 * Default block priority size will be 0<br>
> ><br>
> > We should not be influencing miner policy by changing defaults.<b=
r>
><br>
> I agree changing policy defaults is meaningless, but in this case it<b=
r>
> is supposed to signal deprecation of the policy option.<br>
<br>
</span>This is a bad idea anyway, since priority is the best metric we have=
right now<br>
for ensuring legitimate transactions get mined despite spam attacks.<br>
<br>
Luke<br>
<div class=3D"HOEnZb"><div class=3D"h5">___________________________________=
____________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">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></div>
--047d7bdca97e683d6305245e8841--
|
