Damian Williamson [ARCHIVE] on Nostr: 📅 Original date posted:2017-12-27 📝 Original message:Good evening ZmnSCPxj, ...

📅 Original date posted:2017-12-27
📝 Original message:Good evening ZmnSCPxj,


That you for your considered discussion.


Am I wrong to think that any fullnode can validate blocks conform to a probability distribution? In my understanding after adoption of the proposal, 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.

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 is 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 serves no economic purpose in itself, since the miners we presume must pay the 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 economic advantage.

In a fee for priority service auction, there is always limited space in each new block since it represents only a small fraction of the size of the mempool. Presenting fraudulent transactions at the bottom end of the scale has limited effect on the cost of being near the front of the queue, at priority. As the fraudulent transactions age they would be included in blocks presuming the fee is above dust level, but the block size would grow to accommodate them since the valid mempool is larger. The auction for priority still continues uninterrupted at the top of the priority curve. There is nothing stopping a motivated individual now from writing a script to create a million pointless dust transactions per day, flooding the mempool. Even if the fee is above dust level the proposal does not change this but, ensures transactional 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 suggested 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 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 adoption of Bitcoin over time there would, in fact, be more transactions and greater 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 there it follows that this is in miners financial 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 necessary to start all new nodes in pruned mode by default due to the onerous storage requirements of the full blockchain. I do not think that the proposed changes alter this.

I am sure that there is much more to write.

Regards,
Damian Williamson



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

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/20171227/9f8f65b4/attachment-0001.html>;