From: Damian Williamson <willtech@live.com.au>
To: Jim Renkel <jim.renkel@comcast.net>, Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Thread-Topic: [bitcoin-dev] BIP Proposal: UTWFOTIB - Use Transaction Weight
	For Ordering Transactions In Blocks
Thread-Index: AQHTa+TfjIfbrac6DkW4WL8VVZ5YaaM1y22AgAGl2xg=
Date: Thu, 7 Dec 2017 06:34:39 +0000
Message-ID: <PS2P216MB0179FC2174F0F9BFAA324F169D330@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
References: <PS2P216MB01791F54380CD03B3936399E9D3F0@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>,
	<52700305-585d-4239-134e-ac8c5b6c4165@comcast.net>
In-Reply-To: <52700305-585d-4239-134e-ac8c5b6c4165@comcast.net>
Accept-Language: en-AU, en-US
Content-Language: en-AU
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [7C7ju4tnZr+34gUZ9QlSGng8Im8wxzXb]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; PU1APC01HT219;
	6:sVtwABNuqdSEZC+TCP7MYYMsKCaZJT8cXvaCwmjaDUm+Apt+/wCCk/Eb0lPMGJidXu4t2MyeSOTlyvN1xiQmmXsBO1iHQ4i/aB+I8ljJ740jDeGeeiw3R5PusfZ2lDmdH5MLXc2moAFftnGPUmF39g5Y+mDb8joIfDFrNNLn4JlNGlX0EJLnWu2CH3eaa6O8J5kPl1W3Jzgqmp2gSACoypb9uysvB66XGHz/u2F0QXqIqlqhS/v6plPRo6xkf8QP9eRk/wck6H+0hDSDhf05tMtIvemtsVky5/rMLPOcMLBH/kn6H7zvomV+SCnjnpgEBZf6JlYRXb0JNJHu6S/hXQa6X2WA2xUe49OcXZqqUqw=;
	5:/4j9ZidS6u0mDozf28qWCR+0kd6pj4qAWMTzRWi1x+ZeKOrL+96RMYD1RUQ7wmACTWnuR7RHBPrVX1RgYneifpv9+C6luIs2+N9EXkbUCWiQ7CcpAxjb2fdSrwPpHv+bC8/RlvfHuhDaDmlICI2VpVh3m35Eu81JyzpG6GE7uak=;
	24:U/HUOY9N4fsBrjiDYVEgRyxWhCLr+Z2tMWnCszlKgXvcT/sYK3FdKTyFvwJbAZWpoSNpZnrjNRz0rAko7FCx7tIITfjsy9sXDrB9HgrN6WQ=;
	7:NnERPq48bcpBxTS9bBZKF+vhDvEYsnYwAlQLxa/fmhP1LEjWvm3342NuPcif5pDNRBYr0qy+CLKi8cYhjnjuvL4eGtb4SlN9lhqn6cKHf3+sIICoPWm+aSQHvwbMFn0DZa4kwSLILWc+ibr04ORvsqelEp1lB2Lgylykj9v+RFxjoKGge7fsjKE+kMFDRNEFbqYxZxFmbvOeBdqvh/hNWIxZGDPk1GfgttjCtStIMQ0BYMo71u6ktjxPuRrJlDXz
x-incomingheadercount: 46
x-eopattributedmessage: 0
x-microsoft-antispam: UriScan:; BCL:0; PCL:0;
	RULEID:(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125374)(1603101448)(1701031045);
	SRVR:PU1APC01HT219; 
x-ms-traffictypediagnostic: PU1APC01HT219:
x-ms-office365-filtering-correlation-id: 25301a40-ebd3-44cb-c055-08d53d3c984b
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031);
	SRVR:PU1APC01HT219; BCL:0; PCL:0;
	RULEID:(100000803101)(100110400095); SRVR:PU1APC01HT219; 
x-forefront-prvs: 05143A8241
x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT;
	SFP:1901; SCL:1; SRVR:PU1APC01HT219;
	H:PS2P216MB0179.KORP216.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative;
	boundary="_000_PS2P216MB0179FC2174F0F9BFAA324F169D330PS2P216MB0179KORP_"
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 25301a40-ebd3-44cb-c055-08d53d3c984b
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Dec 2017 06:34:39.8351 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PU1APC01HT219
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, HTML_MESSAGE, RCVD_IN_DNSWL_NONE 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, 07 Dec 2017 13:49:33 +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: Thu, 07 Dec 2017 06:34:44 -0000

--_000_PS2P216MB0179FC2174F0F9BFAA324F169D330PS2P216MB0179KORP_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hello Jim,


The variable block sizes would not, as I understand it, be easily implement=
ed by a solo miner.


You are right, there is presently nothing stopping a miner from ordering th=
e transactions included by a priority that is not entirely based on the fee=
.


It may be possible to verify blocks conform to the proposal by showing that=
 the probability for all transactions included in the block statistically c=
onform to a probability distribution curve, if that is necessary and,  *if*=
 the individual transaction priority can be recreated. I am not that deep i=
nto the mathematics, however, it may also be possible to use a similar meth=
od to do this just based on the fee, that statistically, the blocks conform=
 to a fee distribution. Needs a clever mathematician.


It is certainly possible to verify that blocks conform to the expected size=
.


Honour is why people follow policy without enforcement. I may be in the wro=
ng group. (sic)


Regards,

Damian Williamson

________________________________
From: bitcoin-dev-bounces@lists.linuxfoundation.org <bitcoin-dev-bounces@li=
sts.linuxfoundation.org> on behalf of Jim Renkel via bitcoin-dev <bitcoin-d=
ev@lists.linuxfoundation.org>
Sent: Wednesday, 6 December 2017 4:18:11 PM
To: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP Proposal: UTWFOTIB - Use Transaction Weight =
For Ordering Transactions In Blocks


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 s=
ection entitled 'Solution operation' may not be entirely correct but you wi=
ll 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=3D30 ?); 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 handle=
d by having the protocol determine the target size for the current block us=
ing; current transaction pool size x ( 1 / (144 x n days ) ) =3D transactio=
ns 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 transac=
tions 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 les=
s 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 an=
d time waiting in the transaction pool.

3. Begin selecting transactions to include in the current block using trans=
action 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<mailto:bitcoin-dev@lists.linuxfoundat=
ion.org>
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev



--_000_PS2P216MB0179FC2174F0F9BFAA324F169D330PS2P216MB0179KORP_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<style type=3D"text/css" style=3D"display:none;"><!-- P {margin-top:0;margi=
n-bottom:0;} --></style>
</head>
<body dir=3D"ltr">
<div id=3D"divtagdefaultwrapper" style=3D"font-size:12pt;color:#000000;font=
-family:Calibri,Helvetica,sans-serif;" dir=3D"ltr">
<p style=3D"margin-top:0;margin-bottom:0">Hello Jim,</p>
<p style=3D"margin-top:0;margin-bottom:0"><br>
</p>
<p style=3D"margin-top:0;margin-bottom:0">The variable block sizes would no=
t, as I understand it, be easily implemented by a solo miner.</p>
<p style=3D"margin-top:0;margin-bottom:0"><br>
</p>
<p style=3D"margin-top:0;margin-bottom:0">You are right, there is presently=
 nothing stopping a miner from ordering the transactions included by a prio=
rity that is not entirely based on the fee.<br>
</p>
<p style=3D"margin-top:0;margin-bottom:0"><br>
</p>
<p style=3D"margin-top:0;margin-bottom:0"><span>It may be possible to verif=
y blocks conform to the proposal by showing that the probability for all tr=
ansactions included in the block statistically conform to a probability dis=
tribution curve, if that is necessary
 and,&nbsp; *if* the individual transaction priority can be recreated. I am=
 not that deep into the mathematics, however, it may also be possible to us=
e a similar method to do this just based on the fee, that statistically, th=
e blocks conform to a fee distribution.
 Needs a clever mathematician.</span></p>
<p style=3D"margin-top:0;margin-bottom:0"><span><br>
</span></p>
<p style=3D"margin-top:0;margin-bottom:0"><span>It is certainly possible to=
 verify that blocks conform to the expected size.<br>
</span></p>
<p style=3D"margin-top:0;margin-bottom:0"><span><br>
</span></p>
<p style=3D"margin-top:0;margin-bottom:0"><span>Honour is why people follow=
 policy without enforcement. I may be in the wrong group. (sic)</span></p>
<p style=3D"margin-top:0;margin-bottom:0"><span><br>
</span></p>
<p style=3D"margin-top:0;margin-bottom:0"><span>Regards,</span></p>
<p style=3D"margin-top:0;margin-bottom:0"><span>Damian Williamson</span><br=
>
</p>
</div>
<hr style=3D"display:inline-block;width:98%" tabindex=3D"-1">
<div id=3D"divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" st=
yle=3D"font-size:11pt" color=3D"#000000"><b>From:</b> bitcoin-dev-bounces@l=
ists.linuxfoundation.org &lt;bitcoin-dev-bounces@lists.linuxfoundation.org&=
gt; on behalf of Jim Renkel via bitcoin-dev &lt;bitcoin-dev@lists.linuxfoun=
dation.org&gt;<br>
<b>Sent:</b> Wednesday, 6 December 2017 4:18:11 PM<br>
<b>To:</b> bitcoin-dev@lists.linuxfoundation.org<br>
<b>Subject:</b> Re: [bitcoin-dev] BIP Proposal: UTWFOTIB - Use Transaction =
Weight For Ordering Transactions In Blocks</font>
<div>&nbsp;</div>
</div>
<div style=3D"background-color:#FFFFFF">
<p>As i understand it, the transactions to be included in a block are entir=
ely 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 &quot;policy&quot;, what forces a min=
er to follow it?<br>
</p>
<pre class=3D"x_moz-signature" cols=3D"72">Jim Renkel
</pre>
<div class=3D"x_moz-cite-prefix">On 12/2/2017 10:07 PM, Damian Williamson v=
ia bitcoin-dev wrote:<br>
</div>
<blockquote type=3D"cite"><style type=3D"text/css" style=3D"display:none">
<!--
p
	{margin-top:0;
	margin-bottom:0}
-->
</style>
<div id=3D"x_divtagdefaultwrapper" dir=3D"ltr" style=3D"font-size:12pt; col=
or:#000000; font-family:Calibri,Helvetica,sans-serif">
<p style=3D"margin-top:0; margin-bottom:0"># BIP Proposal: UTWFOTIB - Use T=
ransaction Weight For Ordering Transactions In Blocks<br>
</p>
<br>
I admit, with my limited experience in the operation of the protocol, the s=
ection entitled 'Solution operation' may not be entirely correct but you wi=
ll get the idea. If I have it wrong, please correct it back to the list.<br=
>
<br>
<p style=3D"margin-top:0; margin-bottom:0">## The problem:<br>
</p>
<br>
<p style=3D"margin-top:0; margin-bottom:0">Everybody wants value. Miners wa=
nt to maximize revenue from fees. Consumers want transaction reliability an=
d, (we presume) low fees.<br>
</p>
<br>
Current transaction bandwidth limit is a limiting factor for both.<br>
<br>
<p style=3D"margin-top:0; margin-bottom:0">## Solution summary:<br>
</p>
<br>
<p style=3D"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=3D3=
0 ?); the transaction weight serving
 as the likelihood of a transaction being included in the current block, an=
d then use a target block size.
<br>
</p>
<br>
Protocol enforcement to prevent high or low blocksize cheating to be handle=
d by having the protocol determine the target size for the current block us=
ing; current transaction pool size x ( 1 / (144 x n days ) ) =3D transactio=
ns 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=3D"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 transac=
tions and more transactions total at priority fees.<br>
* Market determines fee paid for transaction priority.<br>
<p style=3D"margin-top:0; margin-bottom:0">* Fee recommendations work all t=
he way out to 30 days or greater.<br>
</p>
* Provides additional block entropy and greater security since there is les=
s probability of predicting the next block.<br>
<br>
<p style=3D"margin-top:0; margin-bottom:0">## Cons:<br>
</p>
<br>
* ?<br>
* Must be first be programmed.<br>
* Anything else?<br>
<br>
<p style=3D"margin-top:0; margin-bottom:0">## Solution operation:<br>
</p>
<br>
<p style=3D"margin-top:0; margin-bottom:0">As I have said, my simplistic vi=
ew of the operation. If I have this wrong, please correct it back to the li=
st.<br>
</p>
<br>
1. The protocol determines the target block size.<br>
<p style=3D"margin-top:0; margin-bottom:0">2. Assign each transaction in th=
e pool a transaction weight based on fee and time waiting in the transactio=
n pool.<br>
</p>
<p style=3D"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=3D"margin-top:0; margin-bottom:0">Regards,</p>
<p style=3D"margin-top:0; margin-bottom:0">Damian Williamson<br>
</p>
</div>
<br>
<fieldset class=3D"x_mimeAttachmentHeader"></fieldset> <br>
<pre>_______________________________________________
bitcoin-dev mailing list
<a class=3D"x_moz-txt-link-abbreviated" href=3D"mailto:bitcoin-dev@lists.li=
nuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>
<a class=3D"x_moz-txt-link-freetext" href=3D"https://lists.linuxfoundation.=
org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman=
/listinfo/bitcoin-dev</a>
</pre>
</blockquote>
<br>
</div>
</body>
</html>

--_000_PS2P216MB0179FC2174F0F9BFAA324F169D330PS2P216MB0179KORP_--