[bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use Transaction Priority For Ordering Transactions In Blocks

[ZmnSCPxj]

Good morning Damian,

I see you have modified your proposal to be purely driven by miners, with fullnodes not actually being able to create a strict "yes-or-no" answer as to block validity under your rules.  This implies that your rules cannot be enforced and that rational miners will ignore your proposal unless it brings in more money for them.  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 "dust size" threshhold whatever that threshhold may be -- and remember, miners get at least 12.5 BTC per block, so they can make a lot of little falsified transactions to justify every block size increase) until the block size increase 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 work 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, 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 was running in reverse or not.  It seems at some level, time does not exist.

And yet time exists.

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

Indeed, all measures of time are, directly or indirectly, measures of increases 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, 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), 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 known 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.  If a transaction exists in this mempool-view, then you know that the transaction 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 valid, 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 that your transaction is old and therefore priority and therefore will simply fill their blocks with transactions that have high feerates rather than high priority.  Thus feerate will still be the ultimate measure.

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

Regards,
ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171226/61caf1d1/attachment.html>