Topic: Huge increase in satoshidice spam over the past day (Read 8789 times)

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. 

Good point.


And good analogy as well.


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)

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.

+ 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!

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

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

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.

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.

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.

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

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

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

 

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.

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


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.

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.

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.


So was my idea with SPV nodes keeping balances documented with input/outputs viable or not?

That way they store a fraction of the chain, but can do everything a full node network can in swarm fashion?

That's easier when you are talking about 3 or 4 GB. When you think it will be 50 or 100 GB soon it makes sense to order an HDD with it.
And as far as I know the client will check the blockchain validity when starting, no?
Also, I'm not jealous. Any other guy is free to grab the idea and do it. I don't wish to be the only one doing it. It can get tiresome for almost no reward.

Even if we prevent the blockchain from growing completely right now, it won't make the experience of those users any better, they would still need to download 180000+ blocks.

Any attempts to "improve" things a little bit in the current design would probably be a waste of time.

EDIT: If there are more efficient ways to download and parse the existing blockchain I'm all for that!

Any there goes all the excellent decentralized aspects of bitcoin.  Its also easier to point people to eg. tcatm's chain snapshots (see below) and have them use -loadblock (only available in 0.6.99/0.7).

OK. I will solve the first time users problem downloading the blockchain...
In the next 2 weeks I'll work on a page where everybody can order the blockchain in a medium of their preference and get it in the mail paying only 2% markup on the chosen medium price+shipping(Worldwide). DvD, HDD,USB flash disk, their choice. I'll get it and send it to them with the most recent blockchain snapshot possible.

This was something I've been thinking about for the last couple of months. Now is the time to do it, I guess.

The issue is less of "there is a huge volume of transactions, oh no!!!" and more of "there are people in the community who, for whatever reason, are doing actions that are forcing other transactions into long confirmation time when their transactions dont really need confirmed immediately" so the solution is "lets give transaction-creators a way to say that their transactions are really lower priority than other 0-fee transactions and thus dont let their transactions force people who want to send money without paying not suffer as a result" additionally "lets tweak the incentive structure so that we further discourage bad actors in the community."  Im not saying pruning isnt going to eventually be implemented, it probably will (in the form of shipping pruned chain snapshots), but in addition to that, there are things we can do to make it not as rough a transition right now.