Hashcash for dealing with dust spam?

[TiagoTiago]

What if instead of enforcing a fixed transaction fee for transfers bellow a certain amount, the system would require transaction requests to be signed with a proof of work, with difficulty inversely proportional to the transaction size by a factor decided by miners; any transaction requests signed with less difficulty than miners expect gets ignored?


Ideally there would be a way for miners to report to the network the difficulty factor they demand for signing transactions, so the client can calculate a consensus as well as know the min and maximum that has a chance of being accepted.

[DamienBlack]

Then in order to send money you would have to be a miner. The network is designed so that a majority or working don't have to be miners.

And besides, transactions already have to be signed with a proof of work, that is what miners do. Gather transactions, and pair them with a proof of work. If you have enough mining capability to make your own block, you can include any small transactions you want, and they don't need a transaction fee. So people can already do what your suggesting. But as you can imagine, the difficulty of mining a block is impossible for most and only going to get harder.

[davout]

Then in order to send money you would have to be a miner. The network is designed so that a majority or working don't have to be miners.

You don't understand the proposal.

And besides, transactions already have to be signed with a proof of work, that is what miners do.

They don't sign them, they timestamp them.

I like this proposal a lot, it would require an extra field in transactions (a large nonce) and a little change to the isStandard check.
Make the target inversely proportional to the amount and it's all good.

The problem isn't so much with having them in a block but have them relayed by the network.

[TiagoTiago]

The idea with having the difficulty be based not only on the smallness of the amount but also on a factor determined by miners is to be prepared for the moment in the future when common values get closer to 1 Satoshi, so even then transactions that aren't spammy in nature would still have little to no difficulty getting thru.

[davout]

The idea with having the difficulty be based not only on the smallness of the amount but also on a factor determined by miners is to be prepared for the moment in the future when common values get closer to 1 Satoshi, so even then transactions that aren't spammy in nature would still have little to no difficulty getting thru.

You mean that the current diff should be taken into account to compute a target that would be necessary to reach to pass isStandard ?

[julz]

the system would require transaction requests to be signed with a proof of work

It had better be a proof of *recent* work - or people will generate these in advance and horde and trade them.. and it'll be a parasitic currency

[TiagoTiago]

I was thinking more somthing along the lines of the difficulty being a setting miners decide on. Somthing like (1/Amount) * X, with X being set by miners themselves (i'm not sure on the exact formula, i just wrote it like that to try to make what i mean clear)

[davout]

I was thinking more somthing along the lines of the difficulty being a setting miners decide on. Somthing like (1/Amount) * X, with X being set by miners themselves (i'm not sure on the exact formula, i just wrote it like that to try to make what i mean clear)

Miners already decide the fees they require. I'm not sure I see your point.

It had better be a proof of *recent* work - or people will generate these in advance and horde and trade them.. and it'll be a parasitic currency

haha yea, hadn't thought about that, maybe add an extra timestamp field then.

nonce and timestamp could be discarded before inclusion in a block, umm wait a second, actually no.

[TiagoTiago]

Miners are the decentralized authority that enforce the rules for transactions, right? That's why i thought it would be them that would control the throttle (or should i call it the brake?) for small transactions

[julz]

It had better be a proof of *recent* work - or people will generate these in advance and horde and trade them.. and it'll be a parasitic currency

haha yea, hadn't thought about that, maybe add an extra timestamp field then.

I guess just a hash of a recent block in the chain would be a good enough form of 'timestamp' for this.

[davout]

It had better be a proof of *recent* work - or people will generate these in advance and horde and trade them.. and it'll be a parasitic currency

haha yea, hadn't thought about that, maybe add an extra timestamp field then.

I guess just a hash of a recent block in the chain would be a good enough form of 'timestamp' for this.

timestamps are smaller, and i can see other uses for a timestamp in a transaction, actually there already is a lock_time field, i have no idea what it's used for though

[julz]

I guess just a hash of a recent block in the chain would be a good enough form of 'timestamp' for this.

timestamps are smaller, and i can see other uses for a timestamp in a transaction, actually there already is a lock_time field, i have no idea what it's used for though

But how is putting in a timestamp proof that the time it was done was actually anywhere near the time claimed?
Hashing a recent block proves approximately when you did your work.  What are you going to put in a timestamp that can't be forged?

[davout]

is putting in a timestamp proof that the time it was done was actually anywhere near the time claimed?
Hashing a recent block proves approximately when you did your work.  What are you going to put in a timestamp that can't be forged?

I feel a little stupid, you're right, the hash of one of the last X blocks could do the trick