Topic: A new approach to the block size debate: Let's address the spam! (Read 752 times)
September 06, 2015, 07:09:28 PM
I totally support anything which could help reduce spam transactions. If I were a miner, I would reject any transaction below 0.001 BTC, I mean below a quarter. Hey, that's nothing!
September 06, 2015, 06:09:01 PM
if we can convincingly mitigate spam issues, does that mean we can remove blocksize limit from consensus rules?
No. Bitcoin can be spammed with seemingly legitimate transactions (coinwallet.eu for example)
September 06, 2015, 06:04:03 PM
takin away my 5500 satoshi faucet payments? 
Well, AFAIK, that is ~10x the current definition of dust. I suppose it depends on the economic situation for faucet owners, and how we choose to address dust as a community. After all, this is ultimately configurable and decided by nodes; it isn't a protocol issue.
How about wallet clients act as aggregators, collating dust payments into larger transactions so miners never see spam?
How would this be done in practice?
For those dust payments to exist in the first place, they were relayed across the network as outputs and remain in the UXTO. More importantly the issue is eliminating outputs worth fractions of a cent, as they place unnecessary stress on a) block size and b) UXTO bloat, while providing little or no value to the network.
if we can convincingly mitigate spam issues, does that mean we can remove blocksize limit from consensus rules?
Unfortunately, this is only one way to address spam, and I'm not even convinced at how effective it might be. This is just a brainstorm for now. Ultimately, I think it's naive to think we can plan for all future incentives to spam. Rather, I think a more responsible way is to deal with capacity on a need basis, with the approach that dealing with spam is one of many ways to approach the issue, outside of simply raising or eliminating the block size limit.
September 05, 2015, 02:20:26 PM
if we can convincingly mitigate spam issues, does that mean we can remove blocksize limit from consensus rules?
Yes and we can theoretically have free transactions again (although miners will resist now they have been spoilt). legendary
Activity: 1302
Merit: 1008
Core dev leaves me neg feedback #abuse #political
September 05, 2015, 07:59:15 AM
if we can convincingly mitigate spam issues, does that mean we can remove blocksize limit from consensus rules?
September 05, 2015, 06:26:27 AM
I like your idea OP. Not that this can change my mind about bigger blocks that I think we do need, but I think that we need to address these spam attacks that are happening periodically. I was reading somewhere though, I don't remember where since u read quite a lot, that there are already, some anti-spam measures that are worked on. Later in one of the threads, one of the users has confirmed this and posted that anti-spam measures are being worked on.
I will try and dig through my post history and through my Chrome history to find what I am talking about.
I will try and dig through my post history and through my Chrome history to find what I am talking about.
September 05, 2015, 05:26:40 AM
Quote
One idea would be to increase the client-coded threshold that defines an output as dust, which would increase the aggregate amount of bitcoins required to push large spam transactions with dust outputs. Another idea would be to require an additional fee to push transactions on a per-dust-output basis.
I like both these ideas. Either of them could help solve the spam attack problem. I can't see any reason to process transactions worth a fraction of a cent, but because of Bitcoin's volatile price the number of sats at which a transaction becomes spam is constantly changing. That makes it difficult to agree on a threshold number of sats below which is regarded as dust because a fresh agreement would need to be reached after each time Bitcoin's price made a big move.
Getting everyone to agree to charging an additional fee to push transactions on a per-dust-output basis would be easier because it would only need to be decided by everyone once.
September 05, 2015, 03:44:25 AM
How about wallet clients act as aggregators, collating dust payments into larger transactions so miners never see spam?
September 05, 2015, 01:09:51 AM
takin away my 5500 satoshi faucet payments?
September 04, 2015, 09:00:52 PM
Forcing the Tx fee to go up to prevent spam might not be a good idea.
This is not what I am suggesting.
Why not just start over with a new account? Why'd you have to buy an account to get your point across? Your words would be taken with more sincerity if you just started over instead of buying an account.
Excuse me? Thanks for derailing the thread. Go back through the last year or so of posts. Does it appear my writing style has changed?
Quote
https://bitcointalksearch.org/topic/m.3610040
1D2vzaHSedPqRuwMaHQHGsdgBgMQoyeshd
Yeah. Still my account. September 05, 2015.
HKXPXidD5XOV5RTwM5yMWwLJPy9Wl0F6SMApJe0AcPPICw91gaQNRSW4jXkpljmVnF1ohOLT2bemBaM ML03aA9o=
1D2vzaHSedPqRuwMaHQHGsdgBgMQoyeshd
Yeah. Still my account. September 05, 2015.
HKXPXidD5XOV5RTwM5yMWwLJPy9Wl0F6SMApJe0AcPPICw91gaQNRSW4jXkpljmVnF1ohOLT2bemBaM ML03aA9o=
I'd love to hear some thoughts that aren't simple ad hominem.
September 04, 2015, 08:40:23 PM
Forcing the Tx fee to go up to prevent spam might not be a good idea.
This is not what I am suggesting.
Why not just start over with a new account? Why'd you have to buy an account to get your point across? Your words would be taken with more sincerity if you just started over instead of buying an account.
September 04, 2015, 07:41:18 PM
Forcing the Tx fee to go up to prevent spam might not be a good idea.
This is not what I am suggesting.
September 04, 2015, 07:40:32 PM
Forcing the Tx fee to go up to prevent spam might not be a good idea.
September 04, 2015, 07:37:55 PM
Although on average, we are nowhere near the 1MB block size limit, intermittent stress tests -- spam attacks -- are moving the block size debate forward. Being that the catalyst for this is not average growth in transactions, but rather a specific spam attack, perhaps we should explore the idea of addressing these spam attacks directly.
I brought up this idea in another thread. Since these discussions tend to move so quickly, I thought it would be appropriate to start a new topic to explore ways that we can address dust transactions.
Important question to consider: If one of the objects of bitcoin is to store and transfer value, how do we define value? If it is economically unfeasible to spend dust outputs (these outputs basically represent nothing but UXTO bloat), at what point do we consider those outputs not worthy of being relayed across the network? For now, that threshold is ~550 satoshis. Perhaps we should rethink it. Perhaps we can also consider an additional fee on a per-dust-output basis, so that those pushing these spam transactions are penalized, rather than typical end users who otherwise might have to pay higher fees if blocks are at capacity.
Please poke as many holes in this idea as possible.
I'll admit that I'm not entirely familiar with the issue. Can you give an example?
I thought there is a dust limit of 5500 Satoshis. is that set by the miners by consensus or is part of the protocol?
AFAIK, the minimum is slightly less than 550 satoshis, or < $0.0013. I believe the last Coinwallet stress test involved outputs of 0.00001 -- approximately double the current definition of dust.
In theory, nodes could observe the standard output of stress test transactions, then simply alter their conf files to not relay transactions with outputs of that size (or smaller). The only loss here is that people cannot quickly send $0.002 transactions. The gain is that above the agreed upon dust thresholds, the standard fee should be adequate (unless I am approaching this incorrectly).
It's not a protocol issue. It affects which transactions an unmodified bitcoind/bitcoin-qt client will relay on the network. Miners can put as many non-standard transaction in their blocks as they want, but without further modification the reference client will not broadcast or relay those transactions to the miners. It's completely configurable. If the current definition of dust is not economical, miners/nodes can just change their conf files.
One idea would be to increase the client-coded threshold that defines an output as dust, which would increase the aggregate amount of bitcoins required to push large spam transactions with dust outputs. Another idea would be to require an additional fee to push transactions on a per-dust-output basis.
The issue has other implications in regards to bloat.
I brought up this idea in another thread. Since these discussions tend to move so quickly, I thought it would be appropriate to start a new topic to explore ways that we can address dust transactions.
Important question to consider: If one of the objects of bitcoin is to store and transfer value, how do we define value? If it is economically unfeasible to spend dust outputs (these outputs basically represent nothing but UXTO bloat), at what point do we consider those outputs not worthy of being relayed across the network? For now, that threshold is ~550 satoshis. Perhaps we should rethink it. Perhaps we can also consider an additional fee on a per-dust-output basis, so that those pushing these spam transactions are penalized, rather than typical end users who otherwise might have to pay higher fees if blocks are at capacity.
Please poke as many holes in this idea as possible.
I'm disappointed that no one is taking this opportunity to discuss solutions to spam attacks (dust transactions w/ maximum outputs). That's actually the issue that is forcing this debate -- not organic growth in transaction volume, which on average, is nowhere near the limit.
I'll admit that I'm not entirely familiar with the issue. Can you give an example?
I thought there is a dust limit of 5500 Satoshis. is that set by the miners by consensus or is part of the protocol?
AFAIK, the minimum is slightly less than 550 satoshis, or < $0.0013. I believe the last Coinwallet stress test involved outputs of 0.00001 -- approximately double the current definition of dust.
In theory, nodes could observe the standard output of stress test transactions, then simply alter their conf files to not relay transactions with outputs of that size (or smaller). The only loss here is that people cannot quickly send $0.002 transactions. The gain is that above the agreed upon dust thresholds, the standard fee should be adequate (unless I am approaching this incorrectly).
It's not a protocol issue. It affects which transactions an unmodified bitcoind/bitcoin-qt client will relay on the network. Miners can put as many non-standard transaction in their blocks as they want, but without further modification the reference client will not broadcast or relay those transactions to the miners. It's completely configurable. If the current definition of dust is not economical, miners/nodes can just change their conf files.
One idea would be to increase the client-coded threshold that defines an output as dust, which would increase the aggregate amount of bitcoins required to push large spam transactions with dust outputs. Another idea would be to require an additional fee to push transactions on a per-dust-output basis.
The issue has other implications in regards to bloat.
Well no you already know that dust has nothing to do with blockchain size but EVERYTHING to do with UXTO bloat. Dust (or a very high probability of dust approaching 1) won't be spent thus it remains in the UXTO. For normal economic transactions the UXTO only grows linearly (related more to the number of discrete entities not total transactions over time). This is good because the UXTO is a far more critical resource than the unpruned blockchain. It is highly likely that in the future most full nodes won't even maintain the full blockchain but they will need the entire UXTO.
Having tiny worthless transactions which last forever in the UXTO lowers the efficiency of every node, forever.
Having tiny worthless transactions which last forever in the UXTO lowers the efficiency of every node, forever.
Dust outputs won't get spent. 100BTC outputs will get spent and pruned.
Moore's Law isn't magic. It reflects that people push back against wastes of CPU time, disk storage, and other limitations to push technology to its physical limits. Processor speeds don't just magically increase. Disk storage doesn't just magically increase. The assumptions underlying Moore's Law (which isn't a real law) involve bean-counters identifying and eliminating wastes of resources that slow down systems and break them, just as much as they involve people inventing new technologies.
The threat from dust transactions may be on the un-glamorous, bean-counting side of technological improvement, but that doesn't mean it doesn't exist.
The threat from dust transactions may be on the un-glamorous, bean-counting side of technological improvement, but that doesn't mean it doesn't exist.
Jump to: