path: root/79/be5196ad1ec2eaaa7dfb113409a81b94efe9b9

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 9B5B498C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 27 Dec 2017 12:29:46 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from APC01-PU1-obe.outbound.protection.outlook.com
	(mail-oln040092254032.outbound.protection.outlook.com [40.92.254.32])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5DF4E411
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 27 Dec 2017 12:29:44 +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=TYuGjalYdfjSYgEi6ZdvUqSb2EiXU20aqTIVHiwe5Uo=;
	b=nK9ETXABTyghoCo8CNZbqJfUA/eHLJ8Z5QEgBRTmiqMHGqr5Ra1sOQp1a98Mo1bHzwFtmQoyeSPlDIudv0tNeyOwoYI7cB7fzQBlit/MGTxYzdc1n8w+Xjxw6MESwwHZyrzv2YplNnkA/jc/d/xB4j2n8l0/EwSkqQPh1I5UN/3NpYIluu5YL2PhrsTeSNgNdxYRuW6y+dkgkOHKtgemCqccN8sxGu/1r6RufSW4fWCDh7JqnYzaqYGuVlUoZW8t+rdo8SeE4wba4+vidSDxI0bzqUBHYLt2OwZjDdlOvQizSCThQ85Cjci3XpjJWYvv4UsVq3JIow59FSfEiQDrMg==
Received: from HK2APC01FT032.eop-APC01.prod.protection.outlook.com
	(10.152.248.55) by HK2APC01HT217.eop-APC01.prod.protection.outlook.com
	(10.152.249.140) with Microsoft SMTP Server (version=TLS1_2,
	cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.302.6;
	Wed, 27 Dec 2017 12:29:42 +0000
Received: from PS2P216MB0179.KORP216.PROD.OUTLOOK.COM (10.152.248.51) by
	HK2APC01FT032.mail.protection.outlook.com (10.152.248.188) with
	Microsoft SMTP Server (version=TLS1_2,
	cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.302.6 via
	Frontend Transport; Wed, 27 Dec 2017 12:29:41 +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.0345.017; Wed, 27 Dec 2017 12:29:41 +0000
From: Damian Williamson <willtech@live.com.au>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Thread-Topic: [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use Transaction
	Priority For Ordering Transactions In Blocks
Thread-Index: AQHTfghff7TDaA+xpUy7nXNeJMBNLKNWkRGAgACMCXc=
Date: Wed, 27 Dec 2017 12:29:41 +0000
Message-ID: <PS2P216MB0179B1A36650D63AA04566029D070@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
References: <PS2P216MB01797C7635C98C5CEF1015529D060@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>,
	<ONt0j-_38AOpm9ldDOakEZXEmS-psPbkKn2NFscLYYZ8Q_VEMdbrmQBeSXlqmg2C_O8BmniVTY-CVrh-AzhSv8x7UXuuzvziqPQH8mM_fpA=@protonmail.com>
In-Reply-To: <ONt0j-_38AOpm9ldDOakEZXEmS-psPbkKn2NFscLYYZ8Q_VEMdbrmQBeSXlqmg2C_O8BmniVTY-CVrh-AzhSv8x7UXuuzvziqPQH8mM_fpA=@protonmail.com>
Accept-Language: en-AU, en-US
Content-Language: en-AU
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-incomingtopheadermarker: OriginalChecksum:72F92507A4DA71665496ED823AC2551F3E2AE422AF026C695DFC7645F5EBF7F0;
	UpperCasedChecksum:1F3843C345CA56F60822C57B441EC093ACC6EAEBB1A261E7571E94A39B921550;
	SizeAsReceived:7444; Count:47
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [ybGpK/HtJNk2ob3T+TnQcO8r5ZlrFoGa]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; HK2APC01HT217;
	6:Pn89zOr2QW3HnhJquyF4Fcm0pWQ9OQprRai6zmwYjfb+J8FFy13qWkCvGHuqnT+QaFpPmCu+rg8ZQDFAwns1xaw/YRBVAon6EA5wVfEw7/waHTaASub4G3hgoxeZrikMQdi2Z/uOKj4lGe03cMKL9HqHuUwr9Y1BDBIcyU/rV9EvZFnA5hIbhx/+Yn7JR4x6iTyPNnQNnYjLNprJuirSWeKOrdClSX2TuqvkLWwHgPgYPNxkSWiM594LLbKv+gs8pmev878u7kP0bgx1cnUKMr5ltizllSJaGeX1q0YHh0h1bvv3mZGW6WwypG1ft8YRHGsZHprMd4YbrmsN+WoMEHtjyCtny47G+T7tcg6UeZc=;
	5:VLvFUql8700RfrDXCIMIwN6+P4mLtw8hLalqW/x3htnesPdwSZeJ3W6KEdCYhtjM+zpTsqFGBAp2Vlt4EizFkNPLj4m/ymWZR92gselLcyJHoxLY8jYbw9EPbBEgjYrnrEjyx7FVa76OErTlVfHFplGw9sGxRziD5g0iRqG92Yc=;
	24:sKN3bOZWsuoUwDD/1m+O4cbVwarm3L0Hy/R+OWoN86eI9uIJeYjizYLmu2PEURvrcXksbQigkq+iQ78HQCO6vstXiYm+B7h5fNhIDo2FWgQ=;
	7:U+D7IpkWWnZMqVoUSMwrGZGJJfgujmMO9yxe02uNWUFo3S0mjFKv91MR4lEqgobX8UMa+dno/49KoX0swx7FyWcrnBMFbp1qMKWeUABL8m6U509iShIKa4Ka+Jm/KUmvwzToaz7TfawhR4Ot+EWd0x3KWpyMfdreymhN1EGcbdVUc45iP/gtfy1k9TFSJqRUNPRFJYf/cF0XpX0nSLcdz18jpuH9MkRxK2ZG8oldjv+uIoqP7T7FtsBUzBwRxH/T
x-incomingheadercount: 47
x-eopattributedmessage: 0
x-microsoft-antispam: UriScan:; BCL:0; PCL:0;
	RULEID:(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125374)(1603101448)(1701031045);
	SRVR:HK2APC01HT217; 
x-ms-traffictypediagnostic: HK2APC01HT217:
x-ms-office365-filtering-correlation-id: 70a3bf36-0a13-461b-4773-08d54d2580de
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031);
	SRVR:HK2APC01HT217; BCL:0; PCL:0;
	RULEID:(100000803101)(100110400095); SRVR:HK2APC01HT217; 
x-forefront-prvs: 0534947130
x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT;
	SFP:1901; SCL:1; SRVR:HK2APC01HT217;
	H:PS2P216MB0179.KORP216.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative;
	boundary="_000_PS2P216MB0179B1A36650D63AA04566029D070PS2P216MB0179KORP_"
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 70a3bf36-0a13-461b-4773-08d54d2580de
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Dec 2017 12:29:41.1160 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HK2APC01HT217
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: Fri, 29 Dec 2017 01:31:20 +0000
Cc: "bitcoin-dev@lists.linuxfoundation.org"
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use Transaction
 Priority 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, 27 Dec 2017 12:29:46 -0000

--_000_PS2P216MB0179B1A36650D63AA04566029D070PS2P216MB0179KORP_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Good evening ZmnSCPxj,


That you for your considered discussion.


Am I wrong to think that any fullnode can validate blocks conform to a prob=
ability distribution? In my understanding after adoption of the proposal, a=
ny full node could validate all properties that a block has that they now v=
alidate, apart from block size, and additionally that the block conforms to=
 a probability distribution. It seems a yes-no result. Let us assume that s=
uch a probability distribution exists since the input is a probability.

Before or after the proposal, miners could falsify transactions if there is=
 a feasible way for them to do this. The introduction of the proposal does =
not change that fact. At the moment the incentive to falsify transactions i=
s to fill blocks so that real transactions must pay the highest possible fe=
es in the auction for limited transaction bandwidth resulting in a net gain=
 for miners. Simply making bigger blocks serves no economic purpose in itse=
lf, since the miners we presume must pay the fees for their falsified trans=
actions, there is no net gain, the fee will be distributed through the pool=
. Unless, by miners, I may presume we mostly mean mining pools and collusio=
n. Still, where is the gain? It is only the blocks that will be larger with=
 no economic advantage.

In a fee for priority service auction, there is always limited space in eac=
h new block since it represents only a small fraction of the size of the me=
mpool. Presenting fraudulent transactions at the bottom end of the scale ha=
s limited effect on the cost of being near the front of the queue, at prior=
ity. As the fraudulent transactions age they would be included in blocks pr=
esuming the fee is above dust level, but the block size would grow to accom=
modate them since the valid mempool is larger. The auction for priority sti=
ll continues uninterrupted at the top of the priority curve. There is nothi=
ng stopping a motivated individual now from writing a script to create a mi=
llion pointless dust transactions per day, flooding the mempool. Even if th=
e fee is above dust level the proposal does not change this but, ensures tr=
ansactional reliability for valid transactions.

In an idealist world, all nodes could agree on the state of the mempool. I =
agree, there is no feasible way currently to hold the mempool to consensus =
without a network of dedicated mempool servers. As it is, it has been sugge=
sted that all long-running nodes will have approximately a similar view of =
the mempool. Sweeping the entire mempool contents per block would achieve w=
hat is required if there was a mempool consensus but since it will just be =
one node's view of the mempool that will not be the result.

My speculation is that as a result of the proposal, through increased adopt=
ion of Bitcoin over time there would, in fact, be more transactions and gre=
ater net fees paid per day. An increased value of BTC that we suppose would=
 follow from increased usage would augment this fee value increase. It sure=
ly follows that a more stable and reliable service will have greater consum=
er and business acceptance, and there it follows that this is in miners fin=
ancial interest.

I have not considered a maxblocksize since I consider that the mempool can =
eventually grow infinitely in size just in valid transactions, without even=
 any fraudulent transactions. I suppose that in time it will become necessa=
ry to start all new nodes in pruned mode by default due to the onerous stor=
age requirements of the full blockchain. I do not think that the proposed c=
hanges alter this.

I am sure that there is much more to write.

Regards,
Damian Williamson



________________________________
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Sent: Wednesday, 27 December 2017 2:55 PM
To: Damian Williamson
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use Transactio=
n Priority For Ordering Transactions In Blocks

Good morning Damian,

I see you have modified your proposal to be purely driven by miners, with f=
ullnodes not actually being able to create a strict "yes-or-no" answer as t=
o block validity under your rules.  This implies that your rules cannot be =
enforced and that rational miners will ignore your proposal unless it bring=
s in more money for them.  The fact that your proposal provides some mechan=
ism to increase block size means that miners will be incentivized to falsif=
y data (by making up their own transactions just above your fixed "dust siz=
e" threshhold whatever that threshhold may be -- and remember, miners get a=
t least 12.5 BTC per block, so they can make a lot of little falsified tran=
sactions to justify every block size increase) until the block size increas=
e per block is the maximum possible block size increase.



--

Let me then explain proof-of-work and the arrow of time in Physics.  It may=
 seem a digression, but please, bear with me.

Proof-of-work proves that work was performed, and (crucially) that this wor=
k was done in the past.

This is important because of the arrow of time.

In principle, every physical interaction is reversible.  Visualize a video =
of two indivisible particles.  The two particles move towards each other, c=
ollide, and because of the collision, fly apart. If you ran this video in r=
everse, or in forward, it would not be distinguishable to you, as an outsid=
e observer, whether the video was running in reverse or not.  It seems at s=
ome level, time does not exist.

And yet time exists.

Consider another video, that of a vase being dropped on a hard surface.  Th=
e vase hits the surface and shatters.  Played in reverse, we can judge it a=
s nonsensical: scattered pieces of ceramic spontaneously forming a vase and=
 then flying upwards.  This orients our arrow of time: the arrow of time po=
ints from states of the universe where lesser entropy exists (the vase is w=
hole) to where greater entropy exists (the vase is in many pieces).

Indeed, all measures of time are, directly or indirectly, measures of incre=
ases in entropy.  Consider a simple hourglass: you place it into a state of=
 low entropy and high energy with most of the sand is in the upper part of =
the hourglass.  As sand falls, and more of that energy is lost into entropy=
, you judge that time passes.

Consider a proof-of-work algorithm: you place electrons into a state of low=
 entropy and high energy.  As electrons go through the mining hardware, pro=
ducing hashes that pass the difficulty requirement, the energy in those ele=
ctrons is lost into entropy (heat), and from the hashes produced (which pro=
ves not only that work was done, but in particular, that entropy increased =
due to work being done), you judge that time passes.

--

Thus, the blockchain itself is already a service that provides a measure of=
 time.  When a block commits to a transaction, then that transaction is kno=
wn to have existed at that block height, at the latest.

Thus one idea, is to have each block commit to some view of the mempool.  I=
f a transaction exists in this mempool-view, then you know that the transac=
tion is at least that old, and can judge the age from this and use this to =
compute the "transaction priority".

Unfortunately, transferring the data to prove that the mempool-view is vali=
d, is equivalent to always sweeping the entire mempool contents per block. =
 In that case you might as well not have a block size limit.

In addition, miners may still commit to a falsely-empty mempool and deny th=
at your transaction is old and therefore priority and therefore will simply=
 fill their blocks with transactions that have high feerates rather than hi=
gh priority.  Thus feerate will still be the ultimate measure.

Rather than attempt this, perhaps developers should be encouraged to make u=
se of existing mechanisms, RBF and CPFP, to allow transactions to be sped u=
p by directly manipulating feerates, as priority (by your measure) is not p=
ractically computable.

Regards,
ZmnSCPxj

--_000_PS2P216MB0179B1A36650D63AA04566029D070PS2P216MB0179KORP_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<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: rgb(0, 0,=
 0); font-family: Calibri,Helvetica,sans-serif,&quot;EmojiFont&quot;,&quot;=
Apple Color Emoji&quot;,&quot;Segoe UI Emoji&quot;,NotoColorEmoji,&quot;Seg=
oe UI Symbol&quot;,&quot;Android Emoji&quot;,EmojiSymbols;" dir=3D"ltr">
<p style=3D"margin-top:0;margin-bottom:0">Good evening ZmnSCPxj,</p>
<p style=3D"margin-top:0;margin-bottom:0"><br>
</p>
<p style=3D"margin-top:0;margin-bottom:0">That you for your considered disc=
ussion.</p>
<p style=3D"margin-top:0;margin-bottom:0"><br>
</p>
<p style=3D"margin-top:0;margin-bottom:0"></p>
<div>Am I wrong to think that any fullnode can validate blocks conform to a=
 probability distribution? In my understanding after adoption of the propos=
al, any full node could validate all properties that a block has that they =
now validate, apart from block size,
 and additionally that the block conforms to a probability distribution. It=
 seems a yes-no result. Let us assume that such a probability distribution =
exists since the input is a probability.<br>
<br>
Before or after the proposal, miners could falsify transactions if there is=
 a feasible way for them to do this. The introduction of the proposal does =
not change that fact. At the moment the incentive to falsify transactions i=
s to fill blocks so that real transactions
 must pay the highest possible fees in the auction for limited transaction =
bandwidth resulting in a net gain for miners. Simply making bigger blocks s=
erves no economic purpose in itself, since the miners we presume must pay t=
he fees for their falsified transactions,
 there is no net gain, the fee will be distributed through the pool. Unless=
, by miners, I may presume we mostly mean mining pools and collusion. Still=
, where is the gain? It is only the blocks that will be larger with no econ=
omic advantage.<br>
<br>
In a fee for priority service auction, there is always limited space in eac=
h new block since it represents only a small fraction of the size of the me=
mpool. Presenting fraudulent transactions at the bottom end of the scale ha=
s limited effect on the cost of
 being near the front of the queue, at priority. As the fraudulent transact=
ions age they would be included in blocks presuming the fee is above dust l=
evel, but the block size would grow to accommodate them since the valid mem=
pool is larger. The auction for
 priority still continues uninterrupted at the top of the priority curve. T=
here is nothing stopping a motivated individual now from writing a script t=
o create a million pointless dust transactions per day, flooding the mempoo=
l. Even if the fee is above dust
 level the proposal does not change this but, ensures transactional reliabi=
lity for valid transactions.<br>
<br>
In an idealist world, all nodes could agree on the state of the mempool. I =
agree, there is no feasible way currently to hold the mempool to consensus =
without a network of dedicated mempool servers. As it is, it has been sugge=
sted that all long-running nodes
 will have approximately a similar view of the mempool. Sweeping the entire=
 mempool contents per block would achieve what is required if there was a m=
empool consensus but since it will just be one node's view of the mempool t=
hat will not be the result.<br>
<br>
My speculation is that as a result of the proposal, through increased adopt=
ion of Bitcoin over time there would, in fact, be more transactions and gre=
ater net fees paid per day. An increased value of BTC that we suppose would=
 follow from increased usage would
 augment this fee value increase. It surely follows that a more stable and =
reliable service will have greater consumer and business acceptance, and th=
ere it follows that this is in miners financial interest.<br>
<br>
I have not considered a maxblocksize since I consider that the mempool can =
eventually grow infinitely in size just in valid transactions, without even=
 any fraudulent transactions. I suppose that in time it will become necessa=
ry to start all new nodes in pruned
 mode by default due to the onerous storage requirements of the full blockc=
hain. I do not think that the proposed changes alter this.<br>
<br>
I am sure that there is much more to write.<br>
<br>
Regards,<br>
Damian Williamson<br>
</div>
<br>
<p></p>
<br>
<br>
<div style=3D"color: rgb(0, 0, 0);">
<hr style=3D"display:inline-block;width:98%" tabindex=3D"-1">
<div id=3D"divRplyFwdMsg" dir=3D"ltr"><font style=3D"font-size:11pt" face=
=3D"Calibri, sans-serif" color=3D"#000000"><b>From:</b> ZmnSCPxj &lt;ZmnSCP=
xj@protonmail.com&gt;<br>
<b>Sent:</b> Wednesday, 27 December 2017 2:55 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: Revised: UTPFOTIB - Use Tra=
nsaction Priority For Ordering Transactions In Blocks</font>
<div>&nbsp;</div>
</div>
<div>
<div>Good morning Damian,<br>
</div>
<div><br>
</div>
<div>I see you have modified your proposal to be purely driven by miners, w=
ith fullnodes not actually being able to create a strict &quot;yes-or-no&qu=
ot; answer as to block validity under your rules.&nbsp; This implies that y=
our rules cannot be enforced and that rational
 miners will ignore your proposal unless it brings in more money for them.&=
nbsp; The fact that your proposal provides some mechanism to increase block=
 size means that miners will be incentivized to falsify data (by making up =
their own transactions just above your
 fixed &quot;dust size&quot; threshhold whatever that threshhold may be -- =
and remember, miners get at least 12.5 BTC per block, so they can make a lo=
t of little falsified transactions to justify every block size increase) un=
til the block size increase per block is the
 maximum possible block size increase.<br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>--<br>
</div>
<div><br>
</div>
<div>Let me then explain proof-of-work and the arrow of time in Physics.&nb=
sp; It may seem a digression, but please, bear with me.<br>
</div>
<div><br>
</div>
<div>Proof-of-work proves that work was performed, and (crucially) that thi=
s work was done in the past.<br>
</div>
<div><br>
</div>
<div>This is important because of the arrow of time.<br>
</div>
<div><br>
</div>
<div>In principle, every physical interaction is reversible.&nbsp; Visualiz=
e a video of two indivisible particles.&nbsp; The two particles move toward=
s each other, collide, and because of the collision, fly apart. If you ran =
this video in reverse, or in forward, it would
 not be distinguishable to you, as an outside observer, whether the video w=
as running in reverse or not.&nbsp; It seems at some level, time does not e=
xist.<br>
</div>
<div><br>
</div>
<div>And yet time exists.<br>
</div>
<div><br>
</div>
<div>Consider another video, that of a vase being dropped on a hard surface=
.&nbsp; The vase hits the surface and shatters.&nbsp; Played in reverse, we=
 can judge it as nonsensical: scattered pieces of ceramic spontaneously for=
ming a vase and then flying upwards.&nbsp; This
 orients our arrow of time: the arrow of time points from states of the uni=
verse where lesser entropy exists (the vase is whole) to where greater entr=
opy exists (the vase is in many pieces).<br>
</div>
<div><br>
</div>
<div>Indeed, all measures of time are, directly or indirectly, measures of =
increases in entropy.&nbsp; Consider a simple hourglass: you place it into =
a state of low entropy and high energy with most of the sand is in the uppe=
r part of the hourglass.&nbsp; As sand falls,
 and more of that energy is lost into entropy, you judge that time passes.<=
br>
</div>
<div><br>
</div>
<div>Consider a proof-of-work algorithm: you place electrons into a state o=
f low entropy and high energy.&nbsp; As electrons go through the mining har=
dware, producing hashes that pass the difficulty requirement, the energy in=
 those electrons is lost into entropy
 (heat), and from the hashes produced (which proves not only that work was =
done, but in particular, that entropy increased due to work being done), yo=
u judge that time passes.<br>
</div>
<div><br>
</div>
<div>--<br>
</div>
<div><br>
</div>
<div>Thus, the blockchain itself is already a service that provides a measu=
re of time.&nbsp; When a block commits to a transaction, then that transact=
ion is known to have existed at that block height, at the latest.<br>
</div>
<div><br>
</div>
<div>Thus one idea, is to have each block commit to some view of the mempoo=
l.&nbsp; If a transaction exists in this mempool-view, then you know that t=
he transaction is at least that old, and can judge the age from this and us=
e this to compute the &quot;transaction priority&quot;.<br>
</div>
<div><br>
</div>
<div>Unfortunately, transferring the data to prove that the mempool-view is=
 valid, is equivalent to always sweeping the entire mempool contents per bl=
ock.&nbsp; In that case you might as well not have a block size limit.<br>
</div>
<div><br>
</div>
<div>In addition, miners may still commit to a falsely-empty mempool and de=
ny that your transaction is old and therefore priority and therefore will s=
imply fill their blocks with transactions that have high feerates rather th=
an high priority.&nbsp; Thus feerate
 will still be the ultimate measure.<br>
</div>
<div><br>
</div>
<div>Rather than attempt this, perhaps developers should be encouraged to m=
ake use of existing mechanisms, RBF and CPFP, to allow transactions to be s=
ped up by directly manipulating feerates, as priority (by your measure) is =
not practically computable.<br>
</div>
<div><br>
</div>
<div>Regards,<br>
</div>
<div>ZmnSCPxj<br>
</div>
</div>
</div>
</div>
</body>
</html>

--_000_PS2P216MB0179B1A36650D63AA04566029D070PS2P216MB0179KORP_--