require a TX-level PoW nonce to inhibit spam?

[sdbrown]

Sorry if this is something that has been discussed ad nauseum already. I'm mostly seeking to get informed myself here.

IIRC, bitcoin implemented a block size limit because of spam transactions. It seems to me like this is a little backwards, creating a bottleneck for legitimate transactions while allowing spam creation to continue unabated. I'm wondering if there's a way to create a bottleneck at the point of transaction creation to limit the appearance of spam in the first place. I think this was done with email to limited effect in the past.

My thinking is that there could be a PoW requirement built into the transaction itself, like the byte-size of the transaction sets a difficulty and the transaction must include a nonce which hashes the entire transaction to some result below some threshold.

I'm already accustomed to waiting a few seconds every time I swipe/insert my credit card into a point-of-sale terminal, so adding a short PoW requirement there seems reasonable to me, but maybe this wouldn't be enough to reduce/eliminate TX spam?

All thoughts(/criticisms) welcomed! :-)

[1714048857]

1714048857

[1714048857]

1714048857

[achow101]

It wouldn't work. If the PoW for transactions was SHA256d, you could just buy an ASIC and spam transactions. If it were something else, you can use GPUs and it would be just as effective. Making the difficulty adjust to transaction size would be completely pointless since spam transactions are typically not large. Furthermore, you couldn't just make it based on the person who is sending it since Bitcoin does not use an accounts based system. It is difficult (nearly impossible) to know whether two transactions were created by the same person, so you can't make the difficulty adjust to the person. So this idea of adding a PoW to each transaction is pointless and wouldn't reduce anything, at least with Bitcoin's design and security model.

[sdbrown]

It wouldn't work. If the PoW for transactions was SHA256d, you could just buy an ASIC and spam transactions. If it were something else, you can use GPUs and it would be just as effective. Making the difficulty adjust to transaction size would be completely pointless since spam transactions are typically not large. Furthermore, you couldn't just make it based on the person who is sending it since Bitcoin does not use an accounts based system. It is difficult (nearly impossible) to know whether two transactions were created by the same person, so you can't make the difficulty adjust to the person. So this idea of adding a PoW to each transaction is pointless and wouldn't reduce anything, at least with Bitcoin's design and security model.

Do I understand correctly that you mean spam transactions no longer exist in the mempool as they once did to crowd the bottom of the TX fee levels, and that the occasional surges in unconfirmed TX seen in the mempool over the last 12 months are all 'end user' transactions?

I'm not proposing that individual people would have to submit PoW, but instead that individual transactions would. Thus, a single transaction with many hundreds of outputs or inputs would require a relatively large PoW, but a transaction where the entire balance of one address is transferred to another address would not. (This has been my working definition of spam: transactions of the former type rather than the latter.)

[ranochigo]

Do I understand correctly that you mean spam transactions no longer exist in the mempool as they once did to crowd the bottom of the TX fee levels, and that the occasional surges in unconfirmed TX seen in the mempool over the last 12 months are all 'end user' transactions?

I can't see how he meant that. There is definitely a surge in the amount of transactions that were not intended for malicious purposes, if thats what you mean.

I'm not proposing that individual people would have to submit PoW, but instead that individual transactions would. Thus, a single transaction with many hundreds of outputs or inputs would require a relatively large PoW, but a transaction where the entire balance of one address is transferred to another address would not. (This has been my working definition of spam: transactions of the former type rather than the latter.)

I can't see how it would be solving the problem with the spam but rather it would be inducing spam. Batch payments are actually beneficial for the network in general with the reduced size by creating numerous outputs from one inputs at once, as opposed to creating them one by one. By discouraging batch payments, you are effectively forcing many service to do things differently and there would be even lesser space than what we have now.

Batch payment is a more responsible way for service to manage payments and it should not be discouraged. By trying to penalise spammers, you are also penalising various services.

[sdbrown]

Batch payment is a more responsible way for service to manage payments and it should not be discouraged. By trying to penalise spammers, you are also penalising various services.

That is exactly the best argument against myself which I could come up with before posting.

I'm trying to think of how some of the ideas from more recent crypto developments (e.g. Iota, RaiBlocks) could be incorporated into bitcoin to improve upon bitcoin, but maybe that is what achow101 was referring to by 'Bitcoin's design and security model'.

[achow101]

I'm not proposing that individual people would have to submit PoW, but instead that individual transactions would. Thus, a single transaction with many hundreds of outputs or inputs would require a relatively large PoW, but a transaction where the entire balance of one address is transferred to another address would not. (This has been my working definition of spam: transactions of the former type rather than the latter.)

I don't think spam transactions have been large transactions, rather they are small ones and there are lots of them. So this wouldn't help. Perhaps if you inverted it, smaller transactions have a higher PoW. But then spammers would just make large transactions. And if you penalized large transactions, they'll make smaller transactions.

Furthermore, as I said earlier, getting an ASIC or a GPU or two would basically make this completely useless unless you can somehow adjust the difficulty to the volume of transactions a person is creating. If I were a spammer, I could get an ASIC and just churn out spam anyways because the ASIC is going to blow through whatever difficulty you set unless that difficulty is specifically being adjusted for my spam.

Now you might say that getting an ASIC or GPU is costly and thus prohibitive, but it has been theorized that many of these spam attacks are coming from miners who want to increase the fee rate and thus increase their mining profits. So if a miner is mounting a spam attack, they can take a single ASIC machine that is being used for mining and repurpose it to get around the PoW limitation. They would still be able to churn out spam transactions as quickly as before.

Lastly, as ranochigo said, your proposal would have a detrimental effect on the UTXO set. You would be encouraging the creation of UTXOs when what we want to do is encourage the consumption of UTXOs. By making large transactions costly, people will make smaller transactions and likely with change (so likely 1 input and 2 output transactions) which will result in a net increase of UTXOs. This is not very good for Bitcoin, and it has the effect of grinding down one's UTXOs into dust thus making it hard to spend any Bitcoin later.

[hatshepsut93]

Sorry if this is something that has been discussed ad nauseum already. I'm mostly seeking to get informed myself here.

IIRC, bitcoin implemented a block size limit because of spam transactions. It seems to me like this is a little backwards, creating a bottleneck for legitimate transactions while allowing spam creation to continue unabated. I'm wondering if there's a way to create a bottleneck at the point of transaction creation to limit the appearance of spam in the first place. I think this was done with email to limited effect in the past.

My thinking is that there could be a PoW requirement built into the transaction itself, like the byte-size of the transaction sets a difficulty and the transaction must include a nonce which hashes the entire transaction to some result below some threshold.

I'm already accustomed to waiting a few seconds every time I swipe/insert my credit card into a point-of-sale terminal, so adding a short PoW requirement there seems reasonable to me, but maybe this wouldn't be enough to reduce/eliminate TX spam?

All thoughts(/criticisms) welcomed! :-)

Satoshi haven't clearly explained the reason for 1 MB blocksize limit, the statement that it was introduced to prevent spam transactions is kinda speculative.

In his original vision the scaling model was based on assumption that the network will move onto more powerful hardware, from home computers to servers and they will be able to process bigger blocks to fit all the transactions, while users will run SPV clients. There are some problems with this vision, because there are no economic incentives to run full node, so the network would become quite small and centralized. This system is would still be a bit different from traditional payment processors because consensus is still required, but when there's only little amount of nodes and miners, chances of them colluding for whatever reason is pretty high.

So, in the current vision of Bitcoin developers blocksize in limited to allow users to run full nodes from their home computers, so the network can be decentralized and impossible to take down, while scaling will be achieved through other means. Spam is not a problem because it just sits in mempool and nodes can customize it to keep it small by evicting transactions from the bottom. So, adding PoW to transactions is not needed, as fees became high recently not because of spam.

[Quickseller]

Transactions already require Proof of "work" however not in the exact way you are proposing. In order to get accepted into most nodes' mempools, and more importantly, in order to get confirmed, transactions must include a transaction fee relative to the size of said transaction. A transaction fee is, in effect a payment of money, and users must "work" in order to obtain said money to pay for the transaction to get confirmed.