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
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
