path: root/41/a22981394cc1c3bcbe2cd84f90ce719882876e

Return-Path: <willtech@live.com.au>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 8B8FD927
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  7 Dec 2017 06:34:44 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from APC01-HK2-obe.outbound.protection.outlook.com
	(mail-oln040092255069.outbound.protection.outlook.com [40.92.255.69])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 01149A3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  7 Dec 2017 06:34:42 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=live.com; s=selector1; 
	h=From:Date:Subject:Message-ID:Content-Type:MIME-Version;
	bh=wxj5PUvLUgY4M68PEr3emNy0WIrCbpfs1b7XYqLpUjU=;
	b=rTEUV6fBhAaFsBm9f7cZRf5XKMepvXxuU23Gq0clmxdCf7hBEIIxS+Hl9n2hw8f+Zu5eHIbeVzsC+QBKhldQLP2j5NkfjHdqgVVaykJaYx4rZoNKvkViK+t9RYoFIOhFAtyNczG9uUwLbuRSg7NHMgelBK/jAiWnQhfV/DKyCeMMOLMDaYgh11fFMhWssLyKNdoW/sFHqbb9AgDhqaHbeA/WnaADLC0XVYO39CGYoHfzen/GqP54PxXZUcwMpHV4eTbCUosXolfzvWQOqBtn0x53d33v/YdHuMsb9tA/vJUJDgbk6dsqysr4U/1ShlNvegwA6j5fEhENJim1dQpEDQ==
Received: from PU1APC01FT038.eop-APC01.prod.protection.outlook.com
	(10.152.252.60) by PU1APC01HT219.eop-APC01.prod.protection.outlook.com
	(10.152.252.246) with Microsoft SMTP Server (version=TLS1_2,
	cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.282.5;
	Thu, 7 Dec 2017 06:34:40 +0000
Received: from PS2P216MB0179.KORP216.PROD.OUTLOOK.COM (10.152.252.52) by
	PU1APC01FT038.mail.protection.outlook.com (10.152.253.136) with
	Microsoft SMTP Server (version=TLS1_2,
	cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.282.5 via
	Frontend Transport; Thu, 7 Dec 2017 06:34:40 +0000
Received: from PS2P216MB0179.KORP216.PROD.OUTLOOK.COM ([10.171.225.19]) by
	PS2P216MB0179.KORP216.PROD.OUTLOOK.COM ([10.171.225.19]) with mapi id
	15.20.0282.007; Thu, 7 Dec 2017 06:34:40 +0000
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-Has-Attach: 
X-MS-TNEF-Correlator: 
x-incomingtopheadermarker: OriginalChecksum:C0E4AA6D7C411CCA13F05FA556F1C9912952CD1DD6B330373CCA20FFC3537DC2;
	UpperCasedChecksum:2BBBEEDF98B2439C87B19BD546FACC607E6ABB98229E0EFF07044A36F535095B;
	SizeAsReceived:7233; Count:46
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_--