BUIPxxx: Extending PoW to transactions as an alternative to the Fee Market (proposal)

[DeftNerd]

Problem

I postulate that the fee market concept has become a detriment to Bitcoin. Proof-of-Work has been invaluable to determine the validity of blocks and the same concept can be used to determine the suitability and priority of transactions.


History

Transaction suitability used to be determined through a formula that took into account the age of the coins, the size of the amount being transferred, the size of the transaction, and the transaction fee. As of Bitcoin Core 12.0, this was grossly over-simplified so now the only way to determine transaction priority and suitability is by increasing transaction fees.


Solution Summary

The goal is to allow wallets and services to craft transactions and use CPU cycles coupled with a small standard miners fee to prove that the transaction is not spam. This will allow miners to prioritize TxPoW enabled transactions for inclusion in blocks before prioritizing transaction fees. The result will be the crippling of the fee market concept.


Solution Details

There are a few ways to accomplish PoW within transactions but I think the simplest soft-fork method is to use OP_RETURN. This allows TxPow to be used to prioritize transactions in the mempool and the TxPoW can be pruned in the future.

1. Concat all the vin txid's into one string
2. Create the txin-hash by SHA256'ing the string
3. Add a random 8 character hex nonce to the txin-hash, hash again with RIPEMD-160, and count the number of prepending 0's.
4. Adjust the nonce and repeat until there are a significant number of prepending 0's in the resulting TxPow
5. When the client is satisfied that the TxPoW is significant enough to ensure priority processing, publish the nonce in OP_RETURN in a specific format for easy analysis and verification

OP_RETURN format

TxPoW:ripemd160:a45bc201:1

Where 'TxPoW' indicates what data the OP_RETURN is holding
Where 'ripemd160' indicates what hashing algorithm is used. This allows for future changes to the hash method. An integer indicating the method is also acceptable (0 could be RIPEMD160)
Where 'a45bc201' is an example 8 character hex nonce to add to the txin-hash
Where '1' is the number of prepending 0’s the resulting hash will have (which will be verified, but included for ease of processing and analysis)​

Full nodes and mining nodes can verify the TxPoW by concatting all the txid’s and SHA256’ing them and adding the OP_RETURN published nonce and running it through RIPEMD-160 to determine the number of prepending 0’s. If the TxPoW hash is prepended by at least one 0 and has a fee of at least 0.000001 BTC/byte (for example), then the transaction will be accepted and placed in the mempool.

The mempool will be sorted first by PoW score (number of prepending 0’s) and then by tx fee, so transaction A paying 0.000001 BTC/byte with a TxPoW starting with 00[...] will have higher priority than transaction B paying 0.00001 BTC/byte with a TxPoW starting with 0[...] even though transaction B is paying 10 times the transaction fee.

Only after all transactions with TxPoW functions are processed will transactions with fees but no TxPoW be included, in the regular order of "highest fee first".


Repercussions

Overtime, a “difficulty market” will develop where developers pay attention to the PoW used in mempools to determine how much work they should do in order to prioritize transactions.

If PoW transactions have priority by a significant percentage of miners, end users will want to use compatible wallets to keep their transaction fees low. If Core refuses to implement TxPoW and if node implementations that support it have enough hash power, it’ll encourage users and businesses to support TxPoW node implementations. This will prevent the success of any USAF attempts.

This will bring back viability of small value transactions if the sender is willing to do work to prove that it’s not spam.


Future Work

If such a proposal is accepted, new features will be desired in wallets such as the ability to track what TxPoW is necessary to have a transaction likely to be included in the next block, ability to set TxPoW calculation timeouts (i.e. give me the best TxPoW possible in 1 second of CPU time), ability to set TxPoW calculation goals (i.e. work until TxPow starts with 000[...]), etc.

Conclusion
BU and other full node implementations that consider BUIPs have enough hash power to stop the growth of the destructive fee market. If implemented, using TxPoW coupled with reasonable but small transaction fees instead of transaction fees alone will cause companies with large economic stakes to want to implement BU.

Your thoughts? Suggestions?

 

[DeftNerd]

I believe that if TxPoW data is added as an optional OP_RETURN value and if it's respected and prioritized by the miners that represent the almost 40% of hashpower behind EC, the majority of large businesses that perform Bitcoin transactions (Coinbase, exchanges, Bitpay, etc) would rather use CPU power to craft transactions than pay outrageous transaction fees.

Core has a major problem with "not invented here" syndrome and they're really into using transaction fees to push people onto sidechains in the future. The only option for people to send BTC without paying outrageous fees will be to upgrade their wallets or nodes to one that supports TxPoW. More specifically, they'll upgrade to an implementation that would never go along with a USAF.

If the current hashpower split remains, transactions with TxPoW and low fees will be processed very quickly by the 40% of hashpower that prioritizes them. Regular transactions will have to pay 30x higher fees in order to be processed quickly by the other 60% of the miners.

It will result in smaller transaction fees for the miners, but the belief that "miners are selfish" doesn't necessarily mean that they want the most transaction fees for every block they find. It's also plausible that they would rather have fewer fees but valued at a higher Bitcoin exchange rate.

This also opens the opportunity for the usage of small-value UTXO's (and dust consolidation) again. Have a wallet full of dust? You might be able to let your computer churn away for 5 minutes to craft the TxPoW to have it all consolidated for 10 satoshi/byte!

I need technically literate eyes on this to help me spot any problems, improvements, or optimizations. I'll also need a BUIP number assignment once the proposal is solidified, and a partner to help me craft the changes in the BU codebase to submit as a merge proposal.

 

[yrral86]

What will you call your altcoin?

 

[DeftNerd]

I should know better than feeding the trolls, but that was just rude and inconsiderate. You embarrass yourself Larry. The Bitcoin community deserves better.

 

[Christoph Bergmann]

Interesting idea. But it is hard to assess, how much complexity such a txPoW adds and how much risk there is that it is too easy to difficult. In this case it might be a good idea to find an altcoin to implement. But as no altcoin suffers from spam, they might be not so interested. Which gets me to the question if there is really a problem to solve?

 

[Zangelbert Bingledack]

Interesting idea. My thought is that this will turn into fees, by hook or crook. It seems like we may as well just increase the blocksize cap, as it's perhaps a less invasive change (and maybe equally likely to be opposed by Core).

 

[DeftNerd]

I agree that we need more transaction capacity. What I'm proposing isn't a solution for that, it's a way of trading transaction fees for proof of work. Normally if you want your transaction processed quickly, you pay a higher fee than everyone else. This is a way to do more work to get your transaction processed quickly.

It's entirely optional, doesn't require a fork, doesn't impact anything written into a block, and it'll be super popular with the economic majority that uses Bitcoin transactions for business purposes.

If this was in Bitcoin Unlimited and if half the miners respected it, I assure you that the economic majority would rather use CPU power to prepare transactions than spend several dollars to send transactions. That would mean that the economic majority would support Bitcoin Unlimited and a USAF would become impossible.

 

[Zangelbert Bingledack]

I'm not seeing how a $2 fee won't turn into nearly $2 of CPU wear + power costs, pretty soon. (Assuming miners wouldn't mind the pay cut.)

 

[yrral86]

I should know better than feeding the trolls, but that was just rude and inconsiderate. You embarrass yourself Larry. The Bitcoin community deserves better.

You want to replace market pricing with a fixed fee combined with proof of work. How is that compatible with the incentive structures inherent to bitcoin?

Besides, what incentive do miners have to prioritize a transaction with more proof of work over one without? They earn nothing more from you doing more N + 1 work than they earn when someone else does N work. I'm not sure why you think I'm embarrassed or that I don't belong in this community, but maybe you should spend more time thinking through your idea and learning basic economics/game theory.

 

[xhiggy]

http://satoshi.nakamotoinstitute.org/

Somewhere in there, Satoshi had a similar discussion with the message board about this exact idea. The conclusion was that the Bitcoin fee is the POW.