Huge increase in satoshidice spam over the past day

[Matt Corallo]

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

[1715057638]

1715057638

[1715057638]

1715057638

[nimda]

Why are you all so eager to get the network comprised of only "trusted nodes"(trusted by whom?) and "lightweight clients"?

Way to kill decentralization, IMO.

Exactly. What's that Satoshi quote? That governments are good at cutting off the heads of things like Napster? Well... how many trusted nodes are we talking about, who's going to protect their heads, and how do I apply to be a trusted node so that I can mess with the blockchain later on?

[Sergio_Demian_Lerner]

This should be a non-issue in the long term:  If the network can't handle 50k tx per day, Bitcoin was never meant to succeed.  The only reason it's such a big issue right now is because it's a single entity producing the volume -- and thus there's somewhere to point the finger when it was really our lack of preparation to handle it.
...
In my mind, the only reason this is an issue is because the community was not prepared to handle the rapid increase in size -- and it will work itself out once users/dev figures out the way to accommodate it.  There just may be some turbulence in the short-term.  

EXCELENT post etotheipi! At least there is some self-criticism in the community!

This is what I've been saying in so many posts: we are not prepared.

If just one single entity made such a mess, then think about 10 more satoshidices beginning to operate tomorrow.

That's why I designed MAVEPAY. I'n not saying that MAVEPAY is the only solution, but people should start accepting there is a scalability problem.

[interlagos]

SatoshiDice seems to be a great way for core devs to get a taste of what it's like to handle a volume like this when bitcoin network starts to scale up and think of the solutions in advance.

And what is the solution they came up with? Kill the volume maker!
Doesn't sound good to me...

[Matt Corallo]

SatoshiDice seems to be a great way for core devs to get a taste of what it's like to handle a volume like this when bitcoin network starts to scale up and think of the solutions in advance.

And what is the solution they came up with? Kill the volume maker!
Doesn't sound good to me...

Stop.  Thats not what I am suggesting, nor is this something that is being extensively discussed, I started this thread to see what the community would say in response. 
The goal is not to kill anyone or prevent them from using bitcoin for their use-case.  Read the thread please.

[justusranvier]

So what's going to happen when BitInstant gets rapid bitcoin->cash conversion working and somebody gets the idea of making a mobile frontend to SatoshiDice that acts as a lightweight wallet and interface to BitInstant behind the scenes? How would something like that affect the Bitcoin network if it became popular?

[Matt Corallo]

So what's going to happen when BitInstant gets rapid bitcoin->cash conversion working and somebody gets the idea of making a mobile frontend to SatoshiDice that acts as a lightweight wallet and interface to BitInstant behind the scenes? How would something like that affect the Bitcoin network if it became popular?

If its done right and uses multisend, it would be a perfectly manageable load on the network.

[Raoul Duke]

More than complainting about SatoshiDice people should be complainting about the biggest pool not using sendmany and only processing around 100 transactions each block, sometimes even less, which I wouldn't be too surprised if they are comprised mostly of it's own transactions to pay miners, even when there are thousands of transactions on the memory pool.

[SgtSpike]

More than complainting about SatoshiDice people should be complainting about the biggest pool not using sendmany and only processing around 100 transactions each block, sometimes even less, which I wouldn't be too surprised if are comprised mostly of it's own transactions to pay miners, even when there are thousands of transactions on the memory pool.

That's the free market at work.  Deepbit can choose to confirm or not confirm whatever transactions it likes.  If you need your transactions to go through quickly, then send it with a fee.  If you are just trying to bring awareness to the issue, then that's probably a good thing - knowledge helps people make better decisions.

[Bitsky]

My opinions about this so far:

- SatoshiDice is legitimate. It may not try its hardest to make the most efficient transactions, but you will always have clients who aren't perfect. SD just does what might happen in 2-3 years anyway, but by lots of different users. SD can use the system only within the given limits; if it would do something wrong, transactions would get rejected. Basically it boils down to the underlying protocol restrictions: spammers for example are really hated, but they operate fine within the SMTP-RFC.

- Someone mentioned "trusted nodes": that's what SolidCoin advertised so heavily. And what failed. Giving control to few nodes might blow everything up.

- Restricting the heavy users won't help either. That's similar to the ISP who advertises with "unlimited downloads" but later throttles you when you download >1GB/month.

What about changing the way the blockchain is stored? Instead of having everybody store the full chain, they could store only 1-2% of it. 50-100 users then would have the entire chain, and with tens of thousands of active users, there would still be hundreds of sources for each block.

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 as long as every single block is at least on one seeder's machine. You'd only need a small index file (think of blockchain.torrent) which handles the checksums of blocks (note that I'm not talking about bitcoin-blocks, but data-blocks, eg 10MB chunks). Add an option to let users decide how many % they want to store and voila, someone can decide to provide a full copy.

[TangibleCryptography]

That's the free market at work.  Deepbit can choose to confirm or not confirm whatever transactions it likes.  If you need your transactions to go through quickly, then send it with a fee.  If you are just trying to bring awareness to the issue, then that's probably a good thing - knowledge helps people make better decisions.

+1.  SD could even partner with DeepBit sending them all their tx and paying a monthly fee for priority service.   The market is wide open.  The days of every pool accepting every tx on every block is likely coming to an end but honestly I find it interesting.

[Raoul Duke]

More than complainting about SatoshiDice people should be complainting about the biggest pool not using sendmany and only processing around 100 transactions each block, sometimes even less, which I wouldn't be too surprised if are comprised mostly of it's own transactions to pay miners, even when there are thousands of transactions on the memory pool.

That's the free market at work.  Deepbit can choose to confirm or not confirm whatever transactions it likes.  If you need your transactions to go through quickly, then send it with a fee.  If you are just trying to bring awareness to the issue, then that's probably a good thing - knowledge helps people make better decisions.

SatoshiDice is the free market at work also. They chose to use the blockchain to make a game following the Bitcoin protocol and paying fees for each and every transaction they send. What was your point again?

And, no, I'm not happy that I'll probably have to take out my bitcoin client from my main laptop and put it in it's own dedicated machine, but what must be done, must be done.
I will not trust you or anyone else to run a "trusted node".

[interlagos]

SatoshiDice seems to be a great way for core devs to get a taste of what it's like to handle a volume like this when bitcoin network starts to scale up and think of the solutions in advance.

And what is the solution they came up with? Kill the volume maker!
Doesn't sound good to me...

Stop.  Thats not what I am suggesting, nor is this something that is being extensively discussed, I started this thread to see what the community would say in response. 
The goal is not to kill anyone or prevent them from using bitcoin for their use-case.  Read the thread please.

Sorry, but that's the impression I got because you also called them stupid and braindead.

From the quote below it's seems they are also suffering from the same issue you mentioned,
if "use transactions in a more conservative way" means avoiding multisend.
They are a young service and hopefully they will work this out.

I realize satoshidice is sometimes slow... but for the past few days I always had to wait at least five minutes before I even know if I won or not. Often times it's even longer.

Is this just me? Or that happens to others too?

Sorry, that was a database change I made.  I make it use transactions in a more conservative way which ended up being a good bit slower so it was having trouble keeping up with people's bets.  It should be much better now.  I really need to track some metrics of bet to result time so that this sort of issue is more obvious to us.

[TangibleCryptography]

SatoshiDice is the free market at work also. They chose to use the blockchain to make a game following the Bitcoin protocol and paying fees for it. What was your point again?

I agree.  The market is made up of suppliers (miners) and consumers (tx creators).   No reason to complain.   If you don't like their tx spam require higher fees.  If enough miners do it then their business model will need to change.

The current situation is like having an all you can eat buffet and complaining people are going back for seconds.

I think the point is a free market is made up of both parties.  If SD is free to spam the market then DB is free to ignore those txs.  One can be wrong without the other one being wrong.  Personally I think neither are.

[SgtSpike]

More than complainting about SatoshiDice people should be complainting about the biggest pool not using sendmany and only processing around 100 transactions each block, sometimes even less, which I wouldn't be too surprised if are comprised mostly of it's own transactions to pay miners, even when there are thousands of transactions on the memory pool.

That's the free market at work.  Deepbit can choose to confirm or not confirm whatever transactions it likes.  If you need your transactions to go through quickly, then send it with a fee.  If you are just trying to bring awareness to the issue, then that's probably a good thing - knowledge helps people make better decisions.

SatoshiDice is the free market at work also. They chose to use the blockchain to make a game following the Bitcoin protocol and paying fees for it. What was your point again?

And, no, I'm not happy that I'll probably have to take out my bitcoin client from my main laptop and put it in it's own dedicated machine, but what must be done, must be done.
I will not trust you or anyone else to run a "trusted node".

I was responding to your original point, which was "people should be complaining about the biggest pool not using sendmany and only processing around 100 transactions each block."

My point was, no they shouldn't.

[Matt Corallo]

- SatoshiDice is legitimate. It may not try its hardest to make the most efficient transactions, but you will always have clients who aren't perfect. SD just does what might happen in 2-3 years anyway, but by lots of different users. SD can use the system only within the given limits; if it would do something wrong, transactions would get rejected. Basically it boils down to the underlying protocol restrictions: spammers for example are really hated, but they operate fine within the SMTP-RFC.

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.

- Restricting the heavy users won't help either. That's similar to the ISP who advertises with "unlimited downloads" but later throttles you when you download >1GB/month.

Again, the point isnt to restrict, its to encourage them to think twice about what they are doing and encourage them to do simple things like sendmulti which make a huge difference to the load they create across the network.

What about changing the way the blockchain is stored? Instead of having everybody store the full chain, they could store only 1-2% of it. 50-100 users then would have the entire chain, and with tens of thousands of active users, there would still be hundreds of sources for each block.

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 as long as every single block is at least on one seeder's machine. You'd only need a small index file (think of blockchain.torrent) which handles the checksums of blocks (note that I'm not talking about bitcoin-blocks, but data-blocks, eg 10MB chunks). Add an option to let users decide how many % they want to store and voila, someone can decide to provide a full copy.

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

[fireduck]

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

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.

[Matt Corallo]

Sorry, but that's the impression I got because you also called them stupid and braindead.

From the quote below it's seems they are also suffering from the same issue you mentioned,
if "use transactions in a more conservative way" means avoiding multisend.
They are a young service and hopefully they will work this out.

I realize satoshidice is sometimes slow... but for the past few days I always had to wait at least five minutes before I even know if I won or not. Often times it's even longer.

Is this just me? Or that happens to others too?

Sorry, that was a database change I made.  I make it use transactions in a more conservative way which ended up being a good bit slower so it was having trouble keeping up with people's bets.  It should be much better now.  I really need to track some metrics of bet to result time so that this sort of issue is more obvious to us.

Guessing from their website that is not whats happening.  AFAICT, their site posts the result of a bet before sending the coins.  Implementing multisend is really dead-simple and would have little effect on payout times if done even close to remotely properly.  Doing multisend is a simple as queuing outputs and running a cronjob to send coins, even if they did it every minute, their total transaction volume would decrease by something like 500-1000%

[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?

[Stephen Gornick]

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.

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 for wagering on SatoshiDICE reportedly being developed) to switch over to that.

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