Topic: Huge increase in satoshidice spam over the past day - page 3. (Read 8855 times)

It might be worth considering transactions that self-identify into certain traffic classes, similar to the hints provided by IP ToS / DSCP.

Not true.  The 50k to sd txes are very easily pruned, whereas the 24 from sd txes are not.  In fact, because many of them are int he same block, those transactions never need to be added to the tx index at all, speeding up block download significantly.

Even if satoshidice used a single sendmany each hour to pay out all bets, they would less than halve the number of SD transactions on the network.

Currently 50k bets per day = 100k transactions per day.

With sendmany, 50k bets per dat = 50024 transactions per day.

"Encouraging" them to use sendmany just to gain a factor of less than 2 reduction in the number of transactions doesn't seem very useful, given the rate they're growing.  It's only a week since their volume last doubled, so by switching to sendmany you're maybe gaining a week until the network can no longer handle their volume (assuming continued exponential growth until the network explodes).

They have "no incentive" because they're earning money with SatoshiDice. No harm is being done to the network. Only those that want to store and validate the chain "for nothing" are having to wait a little more to get up to date.


That's relative. For example, I honestly think that what SatoshiDice is doing is rather positive to the network security, as they're paying fees for their transactions.


What does please me is that they (being a loose term not just for SatoshiDice) choose to implement very simple technologies that hugely increase their donations to Bitcoin as a whole.

See how this is relative?


Illegitimate implies "cheating". They are not cheating. They are perfectly playing by the rules.


You sound like those who are fearful of ASICs.
Define "drastic change", or "switch over quickly"...
I'm still running my full node on my primitive laptop. And I'll probably remain for a while. I am not sure this migration is going that fast. Bitcoin evolution as a whole is even faster.


But they are being payed for it. If what they're earning as fees is not enough, maybe the devs of p2ppool should change the fee policy of the protocol to require an amount in fees that pays off the inclusion of a transaction by the average p2ppool miner.

Or perhaps there should be centralized pools operating as nodes in p2ppool, allowing miners not to have the full chain. The advantage of such is that, by operating in p2ppool, the pool operator clearly shows that he's willing to follow p2ppool rules, and thus cannot "go rogue".

That's probably a bigger issue than the one we are trying to solve. Relying on the fact that people out there are always ready for any changes and announcements is a mistake.


You mentioned that the idea is to prevent these transactions to get to the miners in the first place. So I'm afraid that more transactions will get lost/stuck.
Also discouraging certain behavior by making certain transaction to get stuck/lost doesn't seem right. We already have complaints from users who have their transactions lost due to incorrect fees, this will only add to the problem.

The proposed change does not impact all transactions, only a small subset of users and anyone who is in that subset can easily change, and does not consider fees. 


The proposed change will not force any sites to make any major user-facing changes.  It only effects Bitcoin-site programmers, and only in a fairly minor way, but hopefully a meaningful one.

That topic was discussed earlier in this very thread.  Also keep in mind this is not regulation, this offers users of Bitcoin-Qt/bitcoind the option to more directly impact the transactions mine, (really) as satoshi originally intended.

Because the rule requires people to upgrade their nodes, it would take a significant amount of time to begin effecting transactions.  Thus there will be plenty of time for people to change off of their previous payment designs.  Obviously such a change would be heavily announced.

The proposed rules do not block any transactions, they only effect the time it takes for transactions using the same address repeatedly to confirm.

By proposing to take measures in reducing transaction volume as a long term strategy you get in the middle of transaction fee versus block reward as incentive to mine. Do have more details of how it would work?


We can only measure usefulness in how many people using it, if the change in how a site operates, not just SatoshiDice but any, would decrease it's user base, e.g. because half of potential users won't go through the hassle of creating account, then it would a detriment to Bitcoin Network usefulness.


Some day Bitcoin will face a problem that could only be solved by introducing regulations, I am just not convinced that SatoshiDice and its high transaction volume is that kind of problem since there viable alternative solution: Special blockchain pruning method by etotheipi

Wouldn't this create more trouble for users/services who are unaware of this change?
They will have one more head ache to figure out why on Earth their transactions are not being propagated.

Would it be easy to follow these rules in a reliable way?
Say if I'm trying to play by the rules and the timing is a bit off my transaction will get stuck somewhere and I will have to use wallet tools to remove it.

Uhhh...no.

The protocol remains agnostic, again this is not a hard rule.  It is entirely configurable, not all clients have to implement it, and it is just a discourage rule, not a hard rule.

The reasonable way (and really the only way) to punish users who are DoSing you, is to simply disconnect from them.  If you make it configurable how much "single address spam" transactions you relay, punishing the relaying nodes would mean disconnecting from users who chose to relay more and reject the discouraging of such transactions, which largely removes the choice in the matter.


The point is that miners have no incentive to do so.  The harm is done to the network as a whole, so the goal is to provide the individuals in the network a chance to effect the incentive structure of transaction generators.

There are many disadvantages to users when single addresses are used, but it makes programming a bitcoin site simpler.  Thus, by discouraging such behavior, we can discourage both the behavior itself and hopefully make people designing bitcoin sites put in a bit more effort, in the hope that that effort results in them putting in the effort to do things like multisend as well.

It being configurable I can't really argue with, but the possibility of hordes of people disabling the fee rules without fully understanding what they are doing is what, I believe, many people are scared of, and I think could become a big issue.

Its actually not bothering me at all.  I usually run bitcoin on tmpfs, it takes me no more than an hour to sync fully from 0, and I have plenty of memory left to keep it up.  What does bother me is that they (being a loose term not just for SatoshiDice) refuse to implement very simple technologies that hugely decrease their impact on Bitcoin as a whole.  This, I do call illegitimate.  Refusing to "play by the rules" should be punished, even if its just discouraging them a bit.

Again, a drastic change to a SPV-heavy network overnight is by far not a good thing.  Though end-users do not, by any means, need to run full nodes, for now, they do, and putting heavy load on all of them to essentially make them switch over quickly is not good.  Also, users who use p2pool or other getmemorypool-based mining (which is something that should be very, very, very heavily encouraged) have to deal with the increased load and often do not have the large hardware resources to handle such huge transaction volumes.  You can clearly see the result with the very high orphan rate in p2pool users.

That is fine by me, but we shouldnt make it very, very difficult for people to do so overnight.  Also keep in mind that pool miners (not operators) should be very, very heavily encouraged to use getmemorypool-based mining which requires using a full node.

Whether its the "reference implementation" or not, it is one of the most popular clients, and putting rules in it that are good for the users running it makes sense.  It is entirely up to other nodes whether they want to implement such rules.  Keep in mind that the propose rule here is really a very soft rule, in that it only discourages transactions, there are a ton of workarounds to it and if you happen to get peered with a path to a pool on which this "rule" is not implemented, it will entirely not effect you.

My HD jumped off my computer and went to talk with his lawyers.

See? These are your personal preferences.

I agree with item 2, but I don't want to see a "network rule" of some kind forcing people to do so.
The protocol should be agnostic.

Other results of such a scheme:
1) Green Addresses: users who are using green addresses a) are usually generating significantly more transactions than they otherwise would, so discouraging green addresses (which this does) is quite nice. b) those who insist on using green addresses are using a different trust model entirely and dont care about transaction confirmation time, so using green addresses would be opting into slower transaction confirmations (which is entirely fair).
2) Forcing users to use non-rotating addresses is already poor for user privacy as it makes it clear what you are using your coins for, so discouraging such usage would help user privacy, in the end.

I already did.  What did I miss?

Why does the network need to rely on "trusted nodes"
What's wrong with just "nodes"? Anyone can be a node, that's part of the point. Once we get to the point where people mostly use lightweight clients, a client which wants the whole blockchain can keep connecting to nodes and asking for a list of peers until it finds one with the whole blockchain, or half, or whatever. It starts downloading from that one while looking for more peers to verify against. The concept of a "trusted node" is antithetical to Bitcoin's goals.

Didn't understand this.


It doesn't make sense punishing someone for using the same address multiple times. If you're a solo miner or pool operator and want to apply this rule to your blocks, be my guest. But as a network policy, it doesn't make sense. You're just picking on a particular way of spending bitcoins that you consider "braindead" and trying to punish people who don't do as you like.
bitcoind should not contain personal preferences like that.


I don't see a problem in forcing fees per se, I just don't like that it's implemented in bitcoind. A particular fee policy should not be a "implementation reference". At most, it should be configurable.


Please, of course is legit. They're not attacking the network, nor trying to cheat, double-spend, >50% or anything. They're just spending money in a way that's bothering you and making it harder for non-miners to do what they don't need to do (have a full node running).


They are paying for it. I repeat: end-users do not need to run full nodes. Only solo-miners and pool operators need. They are the only ones who should care about SatoshiDice load of transactions, and apply their arbitrary rules if they feel like.

If an user which is not solo-mining nor operating a pool is using a full node, that's his choice. His choosing to dedicate his resources to the network, charitably. He'll handle the load in exchange of no monetary incentive. He should know all that.

Wanting to embed such an arbitrary rule in the reference implementation is really not appropriate. The Bitcoin protocol per se should be totally agnostic of whether people use multiple addresses or the same address every time.

Please read the thread.

Then SD would just start using unique addresses for each bet.

The idea suggested is this:
Each user of bitcoin has the option to limit transactions involving a particular address to n/memory pool.  ie I may say "I only want to ever have 1 transaction with any given address in my memory pool at any time."  Thus, I would be rate-limiting each individual address  to n per block, assuming they propagate through the network instantly faster than it takes to create a new block.  The idea here is to keep high-volume address transactions from reaching miners in the first place, making them impossible to mine.  Obviously people who wish to continue to use such volume addresses could peer directly with miners who accept such things but, again, that would require a level of effort much higher than simply using something like multisend.