path: root/35/fcfa21291737d9d8a94e8d9ba8834a53172a2b

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 8ED87BAA
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  6 Dec 2017 09:27:35 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from APC01-SG2-obe.outbound.protection.outlook.com
	(mail-oln040092253095.outbound.protection.outlook.com [40.92.253.95])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 775AE1B4
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  6 Dec 2017 09:27:33 +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=RWEJ/yEYUttejwOmFz0VQ2TMhpsw6TxFKj7t2DWV0fM=;
	b=RIzfkvTXn9EBIYpWF5m61w8d152C6L9Vfh4RT5F2lbatTpavTFTS4EFXP+xLw+O+aZY5rXiPYmWNhF3wXLuyIU28bBr4zw3l3dVCFAdBSoVDDamXWvMz5CuJZ1E5JkhwQWstjnvA0k4X3FBTvCdxRjYDWolgNqGlIkatxw/kNnhphU5+PDMlIYBShUBD2AEXj1oGueSjOcKN6sqOMxPHRItHEK40DXUZ485SlRoOweCEeGYncgi2boJ2w4RV3zWpAzfzX5nBGwp7LmCNh+RG99d4C1GS8ibpmMbNiHLb/D76VlWuMmslu0Pjmew3fULF19qBTWbJWB3Wc9MPR500Ig==
Received: from PU1APC01FT020.eop-APC01.prod.protection.outlook.com
	(10.152.252.57) by PU1APC01HT085.eop-APC01.prod.protection.outlook.com
	(10.152.253.150) with Microsoft SMTP Server (version=TLS1_2,
	cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.239.4;
	Wed, 6 Dec 2017 09:27:31 +0000
Received: from PS2P216MB0179.KORP216.PROD.OUTLOOK.COM (10.152.252.53) by
	PU1APC01FT020.mail.protection.outlook.com (10.152.252.217) 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; Wed, 6 Dec 2017 09:27:30 +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; Wed, 6 Dec 2017 09:27:30 +0000
From: Damian Williamson <willtech@live.com.au>
CC: "bitcoin-dev@lists.linuxfoundation.org"
	<bitcoin-dev@lists.linuxfoundation.org>
Thread-Topic: [bitcoin-dev] BIP Proposal: UTWFOTIB - Use Transaction Weight
	For Ordering Transactions In Blocks
Thread-Index: AQHTa+TfjIfbrac6DkW4WL8VVZ5YaaM102mAgAA9mEY=
Date: Wed, 6 Dec 2017 09:27:30 +0000
Message-ID: <PS2P216MB0179BC1CDE30F00D73DAA10F9D320@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
References: <PS2P216MB01791F54380CD03B3936399E9D3F0@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>,
	<TUV8ZuUkjBRWx-C9y-MOdLBBzWKRLd9TalfSPE1qN6oEvup6uAeGVUUlabCDDHKvWh1GZXTPgj6eOjPngN4ACLX2vIoXcjICy2s8tZfh7JQ=@protonmail.com>
In-Reply-To: <TUV8ZuUkjBRWx-C9y-MOdLBBzWKRLd9TalfSPE1qN6oEvup6uAeGVUUlabCDDHKvWh1GZXTPgj6eOjPngN4ACLX2vIoXcjICy2s8tZfh7JQ=@protonmail.com>
Accept-Language: en-AU, en-US
Content-Language: en-AU
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-incomingtopheadermarker: OriginalChecksum:D5A11834DD5DC81BCD44F9DB366C8816CFFA61E1EA001C0AF03443B70DB73453;
	UpperCasedChecksum:B96FC165A3BCA4176D17CC31B620DAB8D089F7BF1626FE04E1A84FA2D609BC78;
	SizeAsReceived:7373; Count:46
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [/DNQeZW5jH/RMpzxfK3+XMrheoDGr+Uk]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; PU1APC01HT085;
	6:fuursmESKTUhA29rFJspJciWsGMDmszH9UlBrPqcX8QHuT4RGGKi8pl0N8snCvwIi9G7siMsIWn0qNYkCUS/Xof5HaOrm03m1sb98rST9MhmhPqI6mOvbn0SZSDhWVFUonBb6gspN2L9KavGeHPvFER/3KYFBNDkpWFD/sY0UQjxNRYTqivk2XEY1JLBONVfNnCy2sBx3zHZhFbhEiKhvxWmYA1pHKdm7LCpqVNgNv1mpZiALQBdccZkytAxrx196agpwu7z5HynOkNu1FSWuRmEW/7ZwOfFfQcE/ayyN3cHsat6qO+mGfmoruDNK2CS69Ah80jWim55mYTapSobsqJ+YMlzgKEwCbzgRQNc1pw=;
	5:zVAqxTscgOgSx5k6BNjuFA4r0x4/iNW5oKryx4IHnCIebqGkahzcN9xzyQ4whAbQfoL0vcJOYtqFoFZdSlaTPaKe+KldYyaj3HKMFufeOK7KgQ9MfhKMZC85EezfZIazI6hrMBa+no8lXSxccIpygjpaa7WZdUDTk8+hVHWCDmY=;
	24:CCB6QYJfixprGCZxL4JxiwWhFHxMuSaZo+MxpGX2qAKBsRQDoEjdQbrkyZrxjUpmrMu30gC+xWb88iNl/dyMeaXYD7nxFbM6RFjHDgY0zMk=;
	7:VzzHCuVMzcqYRiNFxHZzDYA95MbqO9Z1sT8bP6Z1VfDxTazCu7FviX11nsSexuAOJDnrbPYqIDO3/0xTYVjtv2hUuDzrAWnCD40qnJNb9QrC0UfART5gFYxYdd2QLaN7HBvIMHfx4yJd6bcUMkzyRj9MXiMKyRX7GeezYwlJpGga1pTY4WPYFuTsL7E57I4riDAh4L7QYKx3Itxxpfzf62ZnunJkxhGmGcnIg51336sear/qZbKIacYhZeaS2CsN
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:PU1APC01HT085; 
x-ms-traffictypediagnostic: PU1APC01HT085:
x-ms-office365-filtering-correlation-id: 7f38f3ab-2c3b-4d74-c4ef-08d53c8b9323
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031);
	SRVR:PU1APC01HT085; BCL:0; PCL:0;
	RULEID:(100000803101)(100110400095); SRVR:PU1APC01HT085; 
x-forefront-prvs: 05134F8B4F
x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT;
	SFP:1901; SCL:1; SRVR:PU1APC01HT085;
	H:PS2P216MB0179.KORP216.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative;
	boundary="_000_PS2P216MB0179BC1CDE30F00D73DAA10F9D320PS2P216MB0179KORP_"
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7f38f3ab-2c3b-4d74-c4ef-08d53c8b9323
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Dec 2017 09:27:30.7165 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PU1APC01HT085
X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, HTML_MESSAGE, MISSING_HEADERS,
	RCVD_IN_DNSWL_NONE autolearn=no 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:12 +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 09:27:35 -0000

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

Good afternoon ZmnSCPxj,


I have posted some discussion on the need for this proposal and, some refin=
ements to the proposal explanation (not changes to the intended operation) =
to the bitcoin-discuss list. I didn't exactly mean to double post but thoug=
ht it could use the discussion and, not to post it again, I will link to it=
 when (if) it turns up, or will post it back here as an update on request. =
Currently, that post is awaiting moderator approval. I have also rewritten =
the solution operation section a bit in that post, not the idea that is bei=
ng conveyed. I have added an additional step, reject blocks that do not mee=
t the target block size for the current block.

I suggest it still should be added to the solution operation, to broadcast =
the next target block size with the current block when it is solved. Using =
that method may answer a part of your concern.

As I understand it, each node would be aware independently of x transaction=
s waiting for confirmation, the transaction pool. Each node would no doubt =
have its own idea about how many waiting transactions there are and which p=
articular transactions exist. I do not see why each node could not just wor=
k with the information at hand, it is my understanding that is what happens=
 now, even with solved blocks vs the longest chain. I have not followed why=
 you foresee from my proposal the need for fullnodes to back confirm the pr=
evious blocks in that manner.

If next blocksize is broadcast with the completed block it would be a simpl=
e matter to back confirm that. With transaction weight (transaction priorit=
y) I am suggesting that value gives the likelihood of a transaction being i=
ncluded, presuming an element of randomness as to whether any particular tr=
ansaction is then included or not. Back confirmations on a transaction basi=
s would be impossible anyway, all that could be confirmed is that a particu=
lar block has transactions that conform to a probability curve, if the vari=
ables are known, fee amount and time waiting in the pool, then the transact=
ion priority can be recreated to establish that the probability of a partic=
ular block conforms. I certainly do not foresee including the full transact=
ion pool in each block.

I am also presuming blocksize as a number of transactions rather than KB.

My suggestion, if adopted, is to directly make the operation of transaction=
 priority a part of the operational standard - even without verification th=
at it is being followed. The result of full transactional reliability is ac=
tually in the interests of miners as much as anyone.

The benefit of the proposal, not directly stated, is variable sized blocks =
(uncapped block size).

Yes, I have learned not to recycle terminology. My apologies, I had not bee=
n made aware that terminology already had use. Perhaps it would be simpler =
to call the proposal that I am putting forward here Transaction Priority.

Regards,
Damian Williamson


________________________________
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Sent: Wednesday, 6 December 2017 4:46:45 PM
To: Damian Williamson
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP Proposal: UTWFOTIB - Use Transaction Weight =
For Ordering Transactions In Blocks

Good morning Damian,

The primary problem in your proposal, as I understand it, is that the "tran=
saction pool" is never committed to and is not part of consensus currently.=
  It is unlikely that the transaction pool will ever be part of consensus, =
as putting the transaction pool into consensus is effectively lifting the b=
lock size to include the entire transaction pool into each block.  The issu=
e is that the transaction pool is transient and future fullnodes cannot fin=
d the contents of the transaction pool at the time blocks were made and can=
not verify the correctness of historical blocks.  Also, fullnodes using -bl=
ocksonly mode have no transaction pool and cannot verify incoming blocks fo=
r these new rules.

Applying a patch that follows this policy into Bitcoin Core without enforci=
ng it in all fullnodes will simply lead to miners removing the patch in sof=
tware they run, making it an exercise in futility to write, review, and tes=
t this code in the first place.

In addition, you reuse the term "weight" for something different than its c=
urrent use.  Current use, is that the "weight" of a transaction, is the com=
puted weight from the SegWit weight equation, measured in virtual units cal=
led "sipa", using the equation (4sipa / non-witness byte + 1sipa/witness by=
te).

Regards,
ZmnSCPxj




Sent with ProtonMail<https://protonmail.com> Secure Email.

-------- Original Message --------
Subject: [bitcoin-dev] BIP Proposal: UTWFOTIB - Use Transaction Weight For =
Ordering Transactions In Blocks
Local Time: December 6, 2017 3:38 AM
UTC Time: December 5, 2017 7:38 PM
From: bitcoin-dev@lists.linuxfoundation.org
To: bitcoin-dev@lists.linuxfoundation.org <bitcoin-dev@lists.linuxfoundatio=
n.org>



# 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


--_000_PS2P216MB0179BC1CDE30F00D73DAA10F9D320PS2P216MB0179KORP_
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"><span style=3D"font-size:12pt;" i=
d=3D"divtagdefaultwrapper"></p>
<div style=3D"margin-top:0;margin-bottom:0;">Good afternoon ZmnSCPxj,</div>
<div style=3D"margin-top:0;margin-bottom:0;"><br>
</div>
<div style=3D"margin-top:0;margin-bottom:0;">&nbsp;</div>
<div>I have posted some discussion on the need for this proposal and, some =
refinements to the proposal explanation (not changes to the intended operat=
ion) to the bitcoin-discuss list. I didn't exactly mean to double post but =
thought it could use the discussion
 and, not to post it again, I will link to it when (if) it turns up, or wil=
l post it back here as an update on request. Currently, that post is awaiti=
ng moderator approval. I have also rewritten the solution operation section=
 a bit in that post, not the idea
 that is being conveyed. I have added an additional step, reject blocks tha=
t do not meet the target block size for the current block.<br>
<br>
I suggest it still should be added to the solution operation, to broadcast =
the next target block size with the current block when it is solved. Using =
that method may answer a part of your concern.<br>
<br>
As I understand it, each node would be aware independently of x transaction=
s waiting for confirmation, the transaction pool. Each node would no doubt =
have its own idea about how many waiting transactions there are and which p=
articular transactions exist. I
 do not see why each node could not just work with the information at hand,=
 it is my understanding that is what happens now, even with solved blocks v=
s the longest chain. I have not followed why you foresee from my proposal t=
he need for fullnodes to back confirm
 the previous blocks in that manner. <br>
<br>
If next blocksize is broadcast with the completed block it would be a simpl=
e matter to back confirm that. With transaction weight (transaction priorit=
y) I am suggesting that value gives the likelihood of a transaction being i=
ncluded, presuming an element of
 randomness as to whether any particular transaction is then included or no=
t. Back confirmations on a transaction basis would be impossible anyway, al=
l that could be confirmed is that a particular block has transactions that =
conform to a probability curve,
 if the variables are known, fee amount and time waiting in the pool, then =
the transaction priority can be recreated to establish that the probability=
 of a particular block conforms. I certainly do not foresee including the f=
ull transaction pool in each block.<br>
<br>
I am also presuming blocksize as a number of transactions rather than KB.<b=
r>
<br>
My suggestion, if adopted, is to directly make the operation of transaction=
 priority a part of the operational standard - even without verification th=
at it is being followed. The result of full transactional reliability is ac=
tually in the interests of miners
 as much as anyone.<br>
<br>
The benefit of the proposal, not directly stated, is variable sized blocks =
(uncapped block size).<br>
<br>
Yes, I have learned not to recycle terminology. My apologies, I had not bee=
n made aware that terminology already had use. Perhaps it would be simpler =
to call the proposal that I am putting forward here Transaction Priority.<b=
r>
<br>
Regards,<br>
Damian Williamson</div>
</span><br>
<p></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> ZmnSCPxj &lt;ZmnSCPxj=
@protonmail.com&gt;<br>
<b>Sent:</b> Wednesday, 6 December 2017 4:46:45 PM<br>
<b>To:</b> Damian Williamson<br>
<b>Cc:</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>
<div>Good morning Damian,<br>
</div>
<div><br>
</div>
<div>The primary problem in your proposal, as I understand it, is that the =
&quot;transaction pool&quot; is never committed to and is not part of conse=
nsus currently.&nbsp; It is unlikely that the transaction pool will ever be=
 part of consensus, as putting the transaction
 pool into consensus is effectively lifting the block size to include the e=
ntire transaction pool into each block.&nbsp; The issue is that the transac=
tion pool is transient and future fullnodes cannot find the contents of the=
 transaction pool at the time blocks
 were made and cannot verify the correctness of historical blocks.&nbsp; Al=
so, fullnodes using -blocksonly mode have no transaction pool and cannot ve=
rify incoming blocks for these new rules.<br>
</div>
<div><br>
</div>
<div>Applying a patch that follows this policy into Bitcoin Core without en=
forcing it in all fullnodes will simply lead to miners removing the patch i=
n software they run, making it an exercise in futility to write, review, an=
d test this code in the first place.<br>
</div>
<div><br>
</div>
<div>In addition, you reuse the term &quot;weight&quot; for something diffe=
rent than its current use.&nbsp; Current use, is that the &quot;weight&quot=
; of a transaction, is the computed weight from the SegWit weight equation,=
 measured in virtual units called &quot;sipa&quot;, using the equation
 (4sipa / non-witness byte &#43; 1sipa/witness byte).<br>
</div>
<div><br>
</div>
<div>Regards,<br>
</div>
<div>ZmnSCPxj<br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div class=3D"x_protonmail_signature_block">
<div class=3D"x_protonmail_signature_block-user x_protonmail_signature_bloc=
k-empty">
<br>
</div>
<div class=3D"x_protonmail_signature_block-proton">Sent with <a href=3D"htt=
ps://protonmail.com">
ProtonMail</a> Secure Email.<br>
</div>
</div>
<div><br>
</div>
<blockquote class=3D"x_protonmail_quote" type=3D"cite">
<div>-------- Original Message --------<br>
</div>
<div>Subject: [bitcoin-dev] BIP Proposal: UTWFOTIB - Use Transaction Weight=
 For Ordering Transactions In Blocks<br>
</div>
<div>Local Time: December 6, 2017 3:38 AM<br>
</div>
<div>UTC Time: December 5, 2017 7:38 PM<br>
</div>
<div>From: bitcoin-dev@lists.linuxfoundation.org<br>
</div>
<div>To: bitcoin-dev@lists.linuxfoundation.org &lt;bitcoin-dev@lists.linuxf=
oundation.org&gt;<br>
</div>
<div><br>
</div>
<div><br>
</div>
<div dir=3D"ltr" style=3D"font-size:12pt; color:#000000; font-family:Calibr=
i,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>
<div><br>
</div>
<div>I admit, with my limited experience in the operation of the protocol, =
the section entitled 'Solution operation' may not be entirely correct but y=
ou will get the idea. If I have it wrong, please correct it back to the lis=
t.<br>
</div>
<div><br>
</div>
<div><br>
</div>
<p style=3D"margin-top:0; margin-bottom:0">## The problem:<br>
</p>
<div><br>
</div>
<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>
<div><br>
</div>
<div>Current transaction bandwidth limit is a limiting factor for both.<br>
</div>
<div><br>
</div>
<div><br>
</div>
<p style=3D"margin-top:0; margin-bottom:0">## Solution summary:<br>
</p>
<div><br>
</div>
<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>
<div><br>
</div>
<div>Protocol enforcement to prevent high or low blocksize cheating to be h=
andled by having the protocol determine the target size for the current blo=
ck using; current transaction pool size x ( 1 / (144 x n days ) ) =3D trans=
actions to be included in the current
 block.<br>
</div>
<div><br>
</div>
<div>The curves used for the weight of transactions would have to be approp=
riate.<br>
</div>
<div><br>
</div>
<div><br>
</div>
<p style=3D"margin-top:0; margin-bottom:0">## Pros:<br>
</p>
<div><br>
</div>
<div>* Maximizes transaction reliability.<br>
</div>
<div>* Maximizes possibility for consumer and business uptake.<br>
</div>
<div>* Maximizes total fees paid per block without reducing reliability; be=
cause of reliability, confidence and uptake are greater; therefore, more tr=
ansactions and more transactions total at priority fees.<br>
</div>
<div>* Market determines fee paid for transaction priority.<br>
</div>
<div><br>
</div>
<p style=3D"margin-top:0; margin-bottom:0">* Fee recommendations work all t=
he way out to 30 days or greater.<br>
</p>
<div>* Provides additional block entropy and greater security since there i=
s less probability of predicting the next block.<br>
</div>
<div><br>
</div>
<div><br>
</div>
<p style=3D"margin-top:0; margin-bottom:0">## Cons:<br>
</p>
<div><br>
</div>
<div>* ?<br>
</div>
<div>* Must be first be programmed.<br>
</div>
<div>* Anything else?<br>
</div>
<div><br>
</div>
<div><br>
</div>
<p style=3D"margin-top:0; margin-bottom:0">## Solution operation:<br>
</p>
<div><br>
</div>
<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>
<div><br>
</div>
<div>1. The protocol determines the target block size.<br>
</div>
<div><br>
</div>
<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>
<div>4. Solve block.<br>
</div>
<div><br>
</div>
<div><br>
</div>
<p style=3D"margin-top:0; margin-bottom:0">Regards,<br>
</p>
<p style=3D"margin-top:0; margin-bottom:0">Damian Williamson<br>
</p>
</div>
</blockquote>
<div><br>
</div>
</div>
</body>
</html>

--_000_PS2P216MB0179BC1CDE30F00D73DAA10F9D320PS2P216MB0179KORP_--