Huge increase in satoshidice spam over the past day

[Matt Corallo]

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.

[1714951233]

1714951233

[1714951233]

1714951233

[1714951233]

1714951233

[caveden]

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.

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.

[kr105]

Over the past ~24 hours, the number of satoshidice transactions has increased hugely, leading to transaction memory pools (currently) at around 9000 transactions.  Satoshidice spam is already a huge % of current transactions, but now its just ridiculous.  Is it time to start deprioritizing transactions which use very common addresses?

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

[Matt Corallo]

Didn't understand this.

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.

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.

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.

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.

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.

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.

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.

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).

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.

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.

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.

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.

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.

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.

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.

I already did.  What did I miss?

As stated above, punishing high-traffic addresses by no means will remove the potential for the problem to occur.  The goal is really because people who do use one address usually dont care about confirmation times, so they can gladly still use them and some might.  Really its to make people think twice before designing their site in an entirely braindead way.

[Matt Corallo]

See? These are your personal preferences.

Uhhh...no.

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.

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.

[interlagos]

After thinking about this for a while I actually now believe it might be a good idea even long term. Since there is only as many transactions than can be put in the block, the rules might need to be in place for which transaction to include.

The question is do you Matt have a good understanding how to implement this prioritization and how to enforce these rules. I get the impression that miners are the ones deciding what transactions to mine. Can the rules be enforced in the protocol?

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.

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.

[Serith]

b) First, by definition short term solution is bad because the work to implement it would have to be thrown out the window soon enough.

The proposal isnt really that much of a short-term solution.  It is designed to encourage users to not use more transactions than they need to.  Though this is short-term for capping the chain, it should continue to drastically decrease overall chain volume even as that volume increases greatly.

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?

Second, it limits the usefulness of Bitcoin Network. SatoshiDice, or any website with simular behavior, is useful because people who uses it find it so.

Again, no.  It doesnt prevent satoshidice from existing, it encourages them to be more friendly to the bitcoin network as a whole.

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.

After thinking about this for a while I actually now believe it might be a good idea even long term. Since there is only as many transactions than can be put in the block, the rules might need to be in place for which transaction to include.

The question is do you Matt have a good understanding how to implement this prioritization and how to enforce these rules. I get the impression that miners are the ones deciding what transactions to mine. Can the rules be enforced in the protocol?

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.

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

[Matt Corallo]

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.

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.

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.

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

[Matt Corallo]

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?

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. 

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.

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.

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

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.

[interlagos]

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.

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.

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.

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.

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

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.

[caveden]

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.

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.

There are many disadvantages to users when single addresses are used

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 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.

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?

This, I do call illegitimate.  Refusing to "play by the rules" should be punished, even if its just discouraging them a bit.

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

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.  

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.

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.

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".

[dooglus]

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).

[Matt Corallo]

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).

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.

[jgarzik]

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

[Matt Corallo]

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.

Yea, the complete apathy towards upgrading in the Bitcoin community is really quite sad and quite bad for the network's overall security.

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.

You dont prevent it, you slow it.  If you (as all existing nodes I know of do) reannounce your transactions, they will eventually get there.

[Matt Corallo]

@caveden I think we are going to have to agree to disagree.  In the long term, yea of course the network is going to transition to SPV nodes a ton, and things like satoshidice wont make as big a problem for users, OTOH, we want to encourage getmemorypool-style pool miners, so we really want to keep it as easy as possible for people to run full nodes.  In any case I think the many, many people who come to #bitcoin and #bitcoin-dev and complain about how long it takes for them to sync the chain would disagree that SatoshiDice is causing no harm to the system.

[Matt Corallo]

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

Im torn as to whether or not such a system would work for Bitcoin.  It works for IP (IMHO) because application programmers get to set the flags, not end-users, or, at least its something that is well outside of the effort for end-users to increase their own ToS.  For Bitcoin, what would make sense (IMO) (as stated by gmaxwell recently on IRC) would be to have a ToS which is lower than 0 fee, and then let fees do the rest.  Thus the only users who would set such a flag, would be large firms who have some incentive to make their transactions confirm as fast as or faster than their competitors.  OTOH, they also have some incentive to make sure Bitcoin operates well for end-users and those who want fast-confirming transactions.  I could see a scenario where users complain to such services about how long it is taking them to get their money, encouraging these firms to disable this flag and potentially pay fees to crowd out 0-fee transactions.

[interlagos]

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.

You dont prevent it, you slow it.  If you (as all existing nodes I know of do) reannounce your transactions, they will eventually get there.

Ok that's the crucial part that I misunderstood. So indeed this will only slow but not prevent the transactions from propagating.

However for the end user it might create certain complications under specific circumstances.
Imagine Alice accumulated some amount of coins from her signature address on this forum.
She then decided to make a few payments and go to the party, so she sent a few transactions all from the same address in a short amount of time: one to bitmit, one to her friend and one to her mother she promised long time ago, then she shut down her computer and went partying.

Now with these rules in place (considering 1 tx from 1 address per block) her last two transactions were lost and she wouldn't figure this out until after she starts her computer again to re-broadcast them, which might take a few days or until her mother calls and asks where is the money

[Matt Corallo]

However for the end user it might create certain complications under specific circumstances.
Imagine Alice accumulated some amount of coins from her signature address on this forum.
She then decided to make a few payments and go to the party, so she sent a few transactions all from the same address in a short amount of time: one to bitmit, one to her friend and one to her mother she promised long time ago, then she shut down her computer and went partying.

Now with these rules in place (considering 1 tx from 1 address per block) her last two transactions were lost and she wouldn't figure this out until after she starts her computer again to re-broadcast them, which might take a few days or until her mother calls and asks where is the money

Yep.  But thats why the actual tx/mempool is variable.  I think 1 is probably too low for the reason you point out here.  But I dont see many people needing more than 2-3 at maximum for any given use-case.  A sane default, IMHO, would probably be around 3.

[dlasher]

Well, if SD is doing 30k transactions a day, and paying a 0.0005 BTC fee on each one, that'd be an additional 15 BTC of fees for the network each day.

They seem to be using a % fee.. bigger transactions take bigger fees.  This bet  as an example.. 0.01 on the bet, > 1btc on the payout.