Huge increase in satoshidice spam over the past day

[Matt Corallo]

Hi, I am the programmer working on SatoshiDice.

We are absolutely interested in being good bitcoin citizens and doing things in a good and efficient way.  However, changing to handling many bets with a single transaction is a complicated change for us.  It is certainly doable but has to be done carefully because making sure people get paid properly and accountably is our business.  It will also make it confusing for our users.  Right now seeing that they payment was correct is simple.  They see one output to their address of the correct amount and one output to one of our change addresses.  If we combine transactions, they will see a ton of outputs to various addresses.

I understand that people may see more outputs in their transactions, however in most (sane) clients, they only show the single output to the user in the transaction history.  Thus, though the amount paid back to satoshidice may be harder to determine directly, I dont see any reason why users care much at all about that amount.  If Im betting, its not hard to figure out the amount satoshidice kept by subtracting the amount I gave SatoshiDice from the amount I got back.

It gets even more confusing is the same address is getting payments from multiple bets in the same transaction (which will be a common use case, people bet a bunch at once often).

This admittedly complicates things, but if you really wanna keep it simple and more verifyable, you can simply not combine to-user payouts and keep those in separate transactions.

Of course none of that is a deal breaker.  We can do it, but it will likely be a little while before I can get the code in and tested.  I'll also have to think about making improvements to our UI to help users make sense of what they will see in these big transactions.

Somehow I dont see how throwing payouts in a cronjob and changing the existing payout functions to just put them in a list of to-be-sent takes more than a few hours to implement.

[1715563512]

1715563512

[1715563512]

1715563512

[1715563512]

1715563512

[Serith]

So far what I gathered from this thread.

a) Transactions volume increased dramatically because of a single website, SatoshiDice. Transactions volume size was suppose to reach that level sooner or later, but in decentralized manner. The proposal is a short term solution to the problem, that utilizes the centralized manner of generated transactions, and proposing to discourage a website from generating high volume of transactions. The reasoning is that such behavior is abusive and does more harm then good to bitcoin network as a whole.

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

Any short term solution implies that something it has to be done right now rather then later. Is the situation so dare that the proposal has to be implemented despite all the negatives? And do you think that the current problem is worth getting into regulating of how Bitcoin Network used?

[Matt Corallo]

Incidentally, SatoshiDICE only employs high-traffic addresses (1diceN*) because that is convenient (no need to get a new address for each wager).  But there is no dependency on using those addresses.  The service can provide a unique Bitcoin address for each wager and it would technically function just as well.  If an API for obtaining a wagering address were made available it would be trivial for automated wagering (e.g., martingale bots) and the new user interfaces (e.g., mobile apps reportedly being developed) to switch over to that.

So punshing high-traffic addresses won't necessarily have much of the expected effect.

Agreed, but, again its something that will make people think twice about their system-design.  Also, thats why such transactions would be rate-limited and discouraged and not blocked, which allows people to opt into being low-prio.  Someone like satoshidice should be perfectly willing to do this as their users are using unconfirmed transactions anyway and it would let them give other users who are using one-off transactions higher priority and have less of an effect on confirmation times for end-users.

[Realpra]

Yes except they DO store part of the chain AND they do verify against those parts.

Alone none of the nodes are full, but together they act as a network of full nodes.

You can't verify against part of the chain.  You can say "this transaction's signature is invalid" but you can't say "this transaction's input doesnt exist".  Also, even if you have a few full nodes to check for this case, they cant prove it unless they send the full chain...

Hmm.. forgot that...

Clients could join a swarm when connecting which sort of represents the entire chain. Although clients would only store fractions of it, the entire blockchain is always available. Pretty much like a Bittorrent swarm is still fully functional

Similar to "my idea", but see other guy above.

Basically your idea would work, but to verify the inputs of transaction existed you would have to go through the entire chain in the cloud = huge bandwidth usage.

So: "Houston we have a problem"?

Hiding behind TOR or something becomes hard with "trusted" super nodes and VISA volumes so unless we solve this, BTC will remain a small network forever and/or get busted up by governments.


Could we change the nature of blocks so that payments are not made up of only transactions, but also balances?

We know the block chain is trustworthy due to work proofs -> Just put address balances in it?

Could we do this without forking? "BIP 34" or something?

That way I could store the balances of maybe 1000 addresses and I simply verify transactions going out from them? IE verifying inputs against a partial chain?

[TangibleCryptography]

Could we change the nature of blocks so that payments are not made up of only transactions, but also balances?

Bad idea.  The power of a 51% attack is limited to only tx denial and double spends.  If balances are updated based on tx in most recent block without back validation a 51% attack (or even a minority attacker which can generate multiple blocks in a row) could mint an unlimited amount of fake coins.

[fireduck]

Of course none of that is a deal breaker.  We can do it, but it will likely be a little while before I can get the code in and tested.  I'll also have to think about making improvements to our UI to help users make sense of what they will see in these big transactions.

Somehow I dont see how throwing payouts in a cronjob and changing the existing payout functions to just put them in a list of to-be-sent takes more than a few hours to implement.

Thank you for your careful and considered estimation of the time it will take to implement a feature in my code, which I am almost certain you have never seen.  I will treasure it always.  

[SgtSpike]

I am curious. Has anyone checked how much more fees are paid to the network because of Satoshi dice (so both the fees they pay themselves and the fees their clients pay). Fees starting torise is a good an healthy thing and Sathosidice could be a catalyst.

So anyone that can show me some numbers?

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.

[Matt Corallo]

a) Transactions volume increased dramatically because of a single website, SatoshiDice. Transactions volume size was suppose to reach that level sooner or later, but in decentralized manner. The proposal is a short term solution to the problem, that utilizes the centralized manner of generated transactions, and proposing to discourage a website from generating high volume of transactions. The reasoning is that such behavior is abusive and does more harm then good to bitcoin network as a whole.

Essentially.

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.

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.

Any short term solution implies that something it has to be done right now rather then later. Is the situation so dare that the proposal has to be implemented despite all the negatives?

No, but starting a discussion is required to ever move forward .

And do you think that the current problem is worth getting into regulating of how Bitcoin Network used?

This isnt regulating how bitcoin is used, its another incentive change.  Or, more simply, yes.

[wachtwoord]

I am curious. Has anyone checked how much more fees are paid to the network because of Satoshi dice (so both the fees they pay themselves and the fees their clients pay). Fees starting torise is a good an healthy thing and Sathosidice could be a catalyst.

So anyone that can show me some numbers?

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.

Yes but the first two I checked manually were 0.0005 and 0.0001 so I was curious anyone has a programmatic solution to automate the process and come up with non-estimated numbers.

[Matt Corallo]

Thank you for your careful and considered estimation of the time it will take to implement a feature in my code, which I am almost certain you have never seen.  I will treasure it always.  

I understand your code may be complicated and it may take time to implement a change to payout methods, but, again, multisend is a very simple change.  In any case, I would argue it is a very important change as well that should be very heavily prioritized.

[Realpra]

Any short term solution implies that something it has to be done right now rather then later. Is the situation so dare that the proposal has to be implemented despite all the negatives? And do you think that the current problem is worth getting into regulating of how Bitcoin Network used?

I don't think it is that dire no.

If it was, fee rates would have shot through the roof and killed satoshidice.

What is needed is a long term and scalable solution to higher BTC volumes. Fees will kill spam just fine until then.

Could we change the nature of blocks so that payments are not made up of only transactions, but also balances?

Bad idea.  The power of a 51% attack is limited to only tx denial and double spends.  If balances are updated based on tx in most recent block without back validation a 51% attack (or even a minority attacker which can generate multiple blocks in a row) could mint an unlimited amount of fake coins.

Okay, how about this then:
1. The blockchain stays as is.
2. SPV nodes maintain knowledge of the balance of some addresses. They also maintain the documenting tx/block trail leading to this balance.
3. Invalid transactions can then be reported using this information (inputs).

Basically rather than storing chain links you would store chain strands?

The full block chain could then be constructed using strands, SPV nodes can verify and we have a 1-tier network!

[interlagos]

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.

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?

[Bitsky]

Read my response to Realpra, who suggested the same thing.

Basically your idea would work, but to verify the inputs of transaction existed you would have to go through the entire chain in the cloud = huge bandwidth usage.

What if the blockchain itself gets changed? As in, not only changing how parts/all of it are stored, but also its format.
If a client needs to verify an input, it shouldn't have to scan the entire cloud-chain. Instead it sends off a request for input validation to the network, and e.g. the clients who store those blocks which prove the inputs will reply with an udp-ACK. With enough ACK's from different clients, it's safe to assume that the input indeed exists. Kinda like DNS.

[TangibleCryptography]

What if the blockchain itself gets changed? As in, not only changing how parts/all of it are stored, but also its format.
If a client needs to verify an input, it shouldn't have to scan the entire cloud-chain. Instead it sends off a request for input validation to the network, and e.g. the clients who store those blocks which prove the inputs will reply with an udp-ACK. With enough ACK's from different clients, it's safe to assume that the input indeed exists. Kinda like DNS.

Isolation attack?

DNS isn't anonymous.  It is a poor model to use as a comparison.

[Matt Corallo]

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.

[SgtSpike]

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.

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

[Matt Corallo]

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

Please read the thread.

[caveden]

You are the one who insists it be configurable as to how much you forward (and I, mostly, agree with you).  You cant have it both ways or you end up punishing everyone and dropping connections.

Didn't understand this.

But then the flooder just generates more addresses. What's the point?

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.

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.

Doing so via download limits removes the possibility of users using Bitcoin for some things that may be very desirable.  Forcing fees before forwarding transactions that we otherwise wouldnt forward at all allows those transactions to exist.

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.

a) they arent making a legitimate use.  Arguing that it works under the current rules is not a reason to not change the rules to make it not possible.

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

b) they aren't paying for it.  Paying miners does not help or help the high load it inflicts on end-users.

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.

[nimda]

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.

[SgtSpike]

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

Please read the thread.

I already did.  What did I miss?