Huge increase in satoshidice spam over the past day

[kjj]

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.

This is not trivial.  Winnings are paid with transactions that redeem the bet that won them so that it can safely operate with zero confirmations.

[1714598245]

1714598245

[1714598245]

1714598245

[1714598245]

1714598245

[1714598245]

1714598245

[dooglus]

Sadly the fees SatoshiDice pays are essentially nothing, so they dont really care.  In fact, AFAIK, the only reason they pay the fees they do is because bitcoinj doesnt (yet) support calculating minimum relay fees the way the satoshi client does.  

Apparently the fees they pay are significant.  According to etotheipi's analysis:

Code:

Total Bets Made:                350920
Cumulative Wagers:             146956.50238462 BTC
Cumulative Rewards:            147354.43403819 BTC
Cumulative Fees Paid:             176.23022500 BTC
Cumulative Unreturned:            121.09935596 BTC
----
SD Profit on Completed Bets :    -695.26123453 BTC

Fees make up around 25% of their cumulative losses so far.  And make up more than 0.1% of payouts.  Since the house edge is 1.5%, these fees correspond to about 8% of theoretical profits.

[caveden]

How to solve this in 48 hours: release a client that requires a mandatory .01 BTC fee/transaction and get the major pools to use it. SD would be forced to change to sendmany, or fail within 2 days. It would also be a completely generic solution.

And it would also alienate a huge user-base which like bitcoin because of its 0 fees.

So fuck 'em. 0 fees were never sustainable.

 

What about, instead of releasing a client with built-in transaction fee policy, you release a client where the fee policy can be easily configured in a text file? You make the "default" text file provided with the executable have the same configuration the current embed fee policy has, in order not to change things abruptly.

I find it better this way.

[caveden]

Clear you mind. Return to the point when you discovered Bitcoin with a
fresh mind. Got it? No more minor BIP-x or anything, just Bitcoin.

Now, what would be better for the network? 100 transactions a day, or
100 000 000?

How about 10 transactions?

Bitcoin needs *more* transactions, not less. (...)

I agree we can want to find better ways to store the data, but getting
less transactions is not the goal. In fact, if Bitcoin is to be even
mildly successful, there will be a lot more.

+1. Well said.
Pruning, storing the chain in raw format without verifying it, and SPVs, these are the ways to go IMHO. Not trying to "punish" a particular way of doing transactions, specially when the sender of these transactions is paying more than the average bitcoin user pays for them.

[caveden]

This is all so wrong:

1. The current network is larger than what 5 super computers?
2. You can't handle an absolutely small amount of transactions?
3. Solution: Throttle BTC with fees/blocking/self-prioritizing txs?!?!

NONONONONONO!


This is a serious issue: The BTC network is not scaling AT ALL due to horrible design.

+1 to that also.

I feel there's something wrong with the block download process. It seems it does everything too synchronously, but I don't know. That's why I liked to hear that you, Matt Corallo, was working on a patch trying to improve that. This is the way to go. Make the system more efficient, without trying to censor users which are donating more to the network than the average user is.

[localhost]

Note that it also makes it very, very difficult for people to run old nodes (they wont sync properly), which in light of recent node statistic generation by luke, is looking like a very, very poor idea for network security.

Security = Confidentiality, Integrity, Availability. When the blockchain doesn't fit on a 1TB hard drive anymore (or probably sooner ), we'll have an issue with the 2 last points...

[Mageant]

It's better that we are confronted *now* with the problem of a lot more transactions with satoshidice than later with a large influx of new users.

This forces the issue now and this gives us more time to solve it before Bitcoin becomes more popular.

My suggestion is solutions that will work on the long-term, i.e. scalability.

[jgarzik]

I think the responses from a few thread participants have been a bit more... strident and heated than is productive.

The main apparent fact is that SatoshiDice transactions are crowding out and slowing other bitcoin transactions. 

Thus, ignoring all other technical arguments, we can show that SatoshiDice is hurting other bitcoin users' confirmation times.

[DeathAndTaxes]

I think the responses from a few thread participants have been a bit more... strident and heated than is productive.

The main apparent fact is that SatoshiDice transactions are crowding out and slowing other bitcoin transactions. 

Thus, ignoring all other technical arguments, we can show that SatoshiDice is hurting other bitcoin users' confirmation times.

Well no.  If anything Satoshi Dice is delaying tx which pay less or nothing.  Oh noes.  They paying customer gets to go first.  If you pay more per KB than Satoshi Dice your tx will never be delayed.  SD pays 0.0005 BTC per tx.   Simple experiment.  Add 0.002 BTC tx fee to all your tx.  Yes it will cost you a "whole" US penny.  Your tx will have higher priority.  Problem solved.

[localhost]

I think the responses from a few thread participants have been a bit more... strident and heated than is productive.

Well, worrying about scalability seems legitimate as long as we want BTC to become more mainstream, which necessarily means lots more transactions (and lots more wallets and addresses, too).

The main apparent fact is that SatoshiDice transactions are crowding out and slowing other bitcoin transactions. 
Thus, ignoring all other technical arguments, we can show that SatoshiDice is hurting other bitcoin users' confirmation times.

Well, yes but I think one of the points of a cryptocurrency is to remain reliable/usable no matter how hostile the environment is. SatoshiDice is a nice "attacker" who simply uses the system a bit much, and pays for it. Bitcoin really has to be able to deal with that nicely... with a better solution than just blocking this usage (or asking SatoshiDice to stop...)

[Realpra]

Well no.  If anything Satoshi Dice is delaying tx which pay less or nothing.  Oh noes.  They paying customer gets to go first.  If you pay more per KB than Satoshi Dice your tx will never be delayed.  SD pays 0.0005 BTC per tx.   Simple experiment.  Add 0.002 BTC tx fee to all your tx.  Yes it will cost you a "whole" US penny.  Your tx will have higher priority.  Problem solved.

+ 1

I cannot believe that someone thinks blocking a profiting business is MORE productive than discussing (if heated) a software update.

REALLY?

That would be like Google blocking its biggest advertisers because they dare generate so much traffic!

[2112]

I don't want to be mean, but some peoples' brains just don't work right.

Their brains probably do "work right". They simply do not disclose all of the results of their work. For many Bitcoin is an opportunity to make money off of the "how much per month" crowd, the people for whom long-term thinking means "who's going to win the next Superbowl or the next UEFA games".

To me it seems like you think on the far further time-horizon than the majority of the members of this forum.

[caveden]

Well no.  If anything Satoshi Dice is delaying tx which pay less or nothing.  Oh noes.  They paying customer gets to go first.  If you pay more per KB than Satoshi Dice your tx will never be delayed.  SD pays 0.0005 BTC per tx.   Simple experiment.  Add 0.002 BTC tx fee to all your tx.  Yes it will cost you a "whole" US penny.  Your tx will have higher priority.  Problem solved.

Good point.

That would be like Google blocking its biggest advertisers because they dare generate so much traffic!

And good analogy as well.

I don't want to be mean, but some peoples' brains just don't work right.

I'm pretty sure Matt Corallo's brain works very well, though.
The debate here is more fundamental. Some people are all angry with SatoshiDice because they've finally increased Bitcoin's transaction volume, making it harder for people that do not have to store and validate  the blockchain to keep storing and validating the blockchain. They believe it would be nice if such unnecessary and unscalable behavior could go on for longer, and want to punish those that are making this difficult.

I don't agree with it, as my messages in this topic make it clear. But my greatest worry here is that such kind of "punishment" should never be part of the protocol. Pool operators and solo-miners are the only ones who should be taking arbitrary decisions concerning which transactions get included or not. End-users should have no say. And, mostly important, the protocol should be neutral. As the "reference implementation", bitciond should remain neutral too.

If Matt wants this so badly, then, well, I guess he's skilled enough to make a patch and provide it to those who agree with them. I just sincerely hope such patch doesn't get included in the main branch of bitcoind. (and I'd find it a pity that he stops to work on this much more important branch he's working on, about making the blockchain update process more efficient, to work on a thing like this.. but well, that's his choice)

[Matt Corallo]

Im going to close this thread because I think most of what can be said has been said.  I fully understand that a number of people disagree about how much of a problem satoshidice is, and thats fair.  In any case, there is a discussion about actually implementing it on the mailing list, however I doubt it will be implemented purely because it is so controversial.