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
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
|
Return-Path: <jim.renkel@comcast.net>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id DC136130B
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 6 Dec 2017 05:18:09 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from resqmta-ch2-09v.sys.comcast.net
(resqmta-ch2-09v.sys.comcast.net [69.252.207.41])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1E74CF4
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 6 Dec 2017 05:18:08 +0000 (UTC)
Received: from resomta-ch2-17v.sys.comcast.net ([69.252.207.113])
by resqmta-ch2-09v.sys.comcast.net with ESMTP
id MS5necdm7WQ3xMS5weppcL; Wed, 06 Dec 2017 05:18:08 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net;
s=q20161114; t=1512537488;
bh=4ABqbPNdNdk3qrWfPsHkOeasYrUzuNQSbGs4PdyIwVM=;
h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version:
Content-Type;
b=kxPrFrqLmHbJKKdfhouoJ8HUQDnbQAZo6sg/CQJUcFX2qMl+siSxPIZOSTXPbXnlj
31+4PD5qzxFPmvoelzxcVeIXAfoeU7JAFd6GsQp1kmOvSuPCeN4iGgE+qSK3Vm9ciM
url74wYZE/hFF06/agvBMNj9kAGbftUzZ6K+ZSdABGS/fKX/LHZtmA5Usuog3nUuqu
6kr19VV1kchJzgktcKO4braaxgCAMl3kKwyc05Z40R8A5jWfrJFGpG2tH8F4RwUrdK
ZHaDbMFJP7azUeCM2PVSzutf8xOvdNdpUHAvoqShXDCH37XjlgTXx5eVL/CJqOmCDO
d0mOvkEddFmsw==
Received: from [192.168.1.50] ([67.167.116.239])
by resomta-ch2-17v.sys.comcast.net with SMTP
id MS5veN63nRomNMS5vewHwK; Wed, 06 Dec 2017 05:18:08 +0000
To: bitcoin-dev@lists.linuxfoundation.org
References: <PS2P216MB01791F54380CD03B3936399E9D3F0@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
From: Jim Renkel <jim.renkel@comcast.net>
Message-ID: <52700305-585d-4239-134e-ac8c5b6c4165@comcast.net>
Date: Tue, 5 Dec 2017 23:18:11 -0600
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <PS2P216MB01791F54380CD03B3936399E9D3F0@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
Content-Type: multipart/alternative;
boundary="------------C5DAE4AB670F179367B42B7E"
Content-Language: en-US
X-CMAE-Envelope: MS4wfJAJOoG/0PnNo/ciJURBtL/4S4KSOdQHVsj8ZSxs+TM9nGVS41bsm/gZF6UpVvB18/HodWgr3C4wR5ted/m5mi9V5K908fD2oEDjLivEOSg5+LwgK/u9
KCSsk74jItTK54CNyXMmt8GsHGd4ChSPjJAgiFDfG59bJr0pgmxzFigTAJivemH7qX0kyft7ajDtToTkYajfjd22whPyHcncC+KMmsNIzx/Gs//2Rmc5RDbU
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE,
T_RP_MATCHES_RCVD 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: Wed, 06 Dec 2017 14:51:30 +0000
Subject: Re: [bitcoin-dev] BIP Proposal: UTWFOTIB - Use Transaction Weight
For Ordering Transactions In Blocks
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol 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, 06 Dec 2017 05:18:10 -0000
This is a multi-part message in MIME format.
--------------C5DAE4AB670F179367B42B7E
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
As i understand it, the transactions to be included in a block are
entirely up to the miner of that block.
What prevents a miner from implementing the proposal on their own?
If this is adopted as some kind of "policy", what forces a miner to
follow it?
Jim Renkel
On 12/2/2017 10:07 PM, Damian Williamson via bitcoin-dev wrote:
>
> # BIP Proposal: UTWFOTIB - Use Transaction Weight For Ordering
> Transactions In Blocks
>
>
> I admit, with my limited experience in the operation of the protocol,
> the section entitled 'Solution operation' may not be entirely correct
> but you will get the idea. If I have it wrong, please correct it back
> to the list.
>
> ## The problem:
>
>
> Everybody wants value. Miners want to maximize revenue from fees.
> Consumers want transaction reliability and, (we presume) low fees.
>
>
> Current transaction bandwidth limit is a limiting factor for both.
>
> ## Solution summary:
>
>
> Provide each transaction with a transaction weight, being a function
> of the fee paid (on a curve), and the time waiting in the transaction
> pool (also on a curve) out to n days (n=30 ?); the transaction weight
> serving as the likelihood of a transaction being included in the
> current block, and then use a target block size.
>
>
> Protocol enforcement to prevent high or low blocksize cheating to be
> handled by having the protocol determine the target size for the
> current block using; current transaction pool size x ( 1 / (144 x n
> days ) ) = transactions to be included in the current block.
>
> The curves used for the weight of transactions would have to be
> appropriate.
>
> ## Pros:
>
>
> * Maximizes transaction reliability.
> * Maximizes possibility for consumer and business uptake.
> * Maximizes total fees paid per block without reducing reliability;
> because of reliability, confidence and uptake are greater; therefore,
> more transactions and more transactions total at priority fees.
> * Market determines fee paid for transaction priority.
>
> * Fee recommendations work all the way out to 30 days or greater.
>
> * Provides additional block entropy and greater security since there
> is less probability of predicting the next block.
>
> ## Cons:
>
>
> * ?
> * Must be first be programmed.
> * Anything else?
>
> ## Solution operation:
>
>
> As I have said, my simplistic view of the operation. If I have this
> wrong, please correct it back to the list.
>
>
> 1. The protocol determines the target block size.
>
> 2. Assign each transaction in the pool a transaction weight based on
> fee and time waiting in the transaction pool.
>
> 3. Begin selecting transactions to include in the current block using
> transaction weight as the likelihood of inclusion until target block
> size is met.
>
> 4. Solve block.
>
> Regards,
>
> Damian Williamson
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--------------C5DAE4AB670F179367B42B7E
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>As i understand it, the transactions to be included in a block
are entirely up to the miner of that block.</p>
<p><br>
</p>
<p>What prevents a miner from implementing the proposal on their
own?</p>
<p><br>
</p>
<p>If this is adopted as some kind of "policy", what forces a miner
to follow it?<br>
</p>
<pre class="moz-signature" cols="72">Jim Renkel
</pre>
<div class="moz-cite-prefix">On 12/2/2017 10:07 PM, Damian
Williamson via bitcoin-dev wrote:<br>
</div>
<blockquote type="cite"
cite="mid:PS2P216MB01791F54380CD03B3936399E9D3F0@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
<div id="divtagdefaultwrapper"
style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif;"
dir="ltr">
<p style="margin-top:0;margin-bottom:0"># BIP Proposal: UTWFOTIB
- Use Transaction Weight For Ordering Transactions In Blocks<br>
</p>
<br>
I admit, with my limited experience in the operation of the
protocol, the section entitled 'Solution operation' may not be
entirely correct but you will get the idea. If I have it wrong,
please correct it back to the list.<br>
<br>
<p style="margin-top:0;margin-bottom:0">## The problem:<br>
</p>
<br>
<p style="margin-top:0;margin-bottom:0">Everybody wants value.
Miners want to maximize revenue from fees. Consumers want
transaction reliability and, (we presume) low fees.<br>
</p>
<br>
Current transaction bandwidth limit is a limiting factor for
both.<br>
<br>
<p style="margin-top:0;margin-bottom:0">## Solution summary:<br>
</p>
<br>
<p style="margin-top:0;margin-bottom:0">Provide each transaction
with a transaction weight, being a function of the fee paid
(on a curve), and the time waiting in the transaction pool
(also on a curve) out to n days (n=30 ?); the transaction
weight serving as the likelihood of a transaction being
included in the current block, and then use a target block
size.
<br>
</p>
<br>
Protocol enforcement to prevent high or low blocksize cheating
to be handled by having the protocol determine the target size
for the current block using; current transaction pool size x ( 1
/ (144 x n days ) ) = transactions to be included in the current
block.<br>
<br>
The curves used for the weight of transactions would have to be
appropriate.<br>
<br>
<p style="margin-top:0;margin-bottom:0">## Pros:<br>
</p>
<br>
* Maximizes transaction reliability.<br>
* Maximizes possibility for consumer and business uptake.<br>
* Maximizes total fees paid per block without reducing
reliability; because of reliability, confidence and uptake are
greater; therefore, more transactions and more transactions
total at priority fees.<br>
* Market determines fee paid for transaction priority.<br>
<p style="margin-top:0;margin-bottom:0">* Fee recommendations
work all the way out to 30 days or greater.<br>
</p>
* Provides additional block entropy and greater security since
there is less probability of predicting the next block.<br>
<br>
<p style="margin-top:0;margin-bottom:0">## Cons:<br>
</p>
<br>
* ?<br>
* Must be first be programmed.<br>
* Anything else?<br>
<br>
<p style="margin-top:0;margin-bottom:0">## Solution operation:<br>
</p>
<br>
<p style="margin-top:0;margin-bottom:0">As I have said, my
simplistic view of the operation. If I have this wrong, please
correct it back to the list.<br>
</p>
<br>
1. The protocol determines the target block size.<br>
<p style="margin-top:0;margin-bottom:0">2. Assign each
transaction in the pool a transaction weight based on fee and
time waiting in the transaction pool.<br>
</p>
<p style="margin-top:0;margin-bottom:0">3. Begin selecting
transactions to include in the current block using transaction
weight as the likelihood of inclusion until target block size
is met.<br>
</p>
4. Solve block.<br>
<br>
<p style="margin-top:0;margin-bottom:0">Regards,</p>
<p style="margin-top:0;margin-bottom:0">Damian Williamson<br>
</p>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
bitcoin-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>
<a class="moz-txt-link-freetext" href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>
--------------C5DAE4AB670F179367B42B7E--
|
