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

Yep, the people complaining that their chain sync is taking too long are all wrong, they should be happy its slow.  Don't get me wrong, I like natural growth, and I think it would be great if bitcoin's huge recent increase in chain size was all because we were getting new users or having increased liquidity in the market.  But, sadly, thats not true.  

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.  

I'm not trying to flame but what I've been thinking since this thread began is: lazy Bitcoin dev is lazy.
If developers think blockchain  size is turning into a problem maybe the answer is you should start thinking about how to prune it, not how to reduce the amount of transactions.

It's in times like this that I wish I was smarter and could help, but unfortunately that's not the case.

PS:  I'm very thankful to all the developers. If it wasn't for them I wouldn't be able to take part on a movement that will change how we perceive money forever.

Enough said. Delaying transactions for high-volume addresses will only cause cascading delays for senders/receivers to those addresses. This then has an adverse affect on user experience, potentially for the very service or cause new users came to bitcoin for. Additionally, we want to support an increasing velocity of money in the bitcoin economy, which currently is moving at a glacial pace, even with SD. Blockchain's cost per transaction shows that at current USD exchange rates, even with SD volume each transaction is costing the network $.75. Why are we spending so much time complaining about a growth that is truly moderate compared to what the network will need to support? Hell, I hope that within a few years there will be 100+ bitcoiners in every major city, and potentially even a few towns that use bitcoins for market day... If we can't restructure to handle the minor load of satoshi dice, how are we going to support that large but STILL MINOR increase in volume?

Less *oh noes! lets keep us the bandwidths and disk spaces* and more preparing for the future.... we need a roadmap with a defined timeline and approach for blockchain pruning. We may even need a longer term plan for sharding, possibly via a tiered blockchain approach. I'm not sure what the solution is, but I am sure that one will be needed.

-bgc

I think the only reasonable way to encourage sendmulti is to make it cost less in terms of fees compared to doing it separately, which as I understand how it works already, no?

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. Last year at the same time
there was even talks about how the block limit was way too large,
resulting in almost non-existent fees.

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.

The userbase for SD seems to be proportional to the load they generate.
Also will it affect MtGox if many users happen to withdraw from a single address in MtGox wallet?

The point of this thread is to get the same result entirely without fucking them.

Not at all.  Im trying to discourage high transaction load generated by sites with low userbase compared to that load.

So fuck 'em. 0 fees were never sustainable.

That being said, one option is for miners to offer a webpage where you have to enter a captcha and a transaction id and it'll let that transaction through into that miner's next block for free. Even better, this could be installed into clients and any miner who wishes to trust that the captcha server isn't lying about the captcha being entered successfully can subscribe to that feed.

It seems that the thing we're trying to discourage is automated transfers, and that would do that.

Don't do anything. When the system is failing (I doubt it will) miners will start to require ever increasing fees (hopefully proportional to the amount of the transaction, I have always hated minimum fees and still hope that will be removed) until a stable equilibrium is reached.

* In brackets are my personal opinions which are really quite irrelevant

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

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.

AFAIK SD only pays fees because of limitations in bitcoinj, not because they have to or want to.

I'm still concerned this will have more impact on legitimate users or small businesses who process their transactions manually than on high volume makers.

New rules do not discourage the volume itself but using the same address in that volume.
So the change seems to be targeted to the current implementation of SatoshiDice rather than being a more generic solution.

Under new rules SatoshiDice will have to change that's for sure and there are two ways:
1) use sendmulti which is benevolent
2) use new addresses for each bet which is basically bypassing the new rule.
They have already admitted that they want to be a good citizens and they will put efforts to implement sendmulti, so introducing new rules just for them (or rather against them) doesn't make much sense. On the other hand players which choose to be malevolent will simply bypass the new rule by using new addresses if they wish to.

So is it really worth the time and effort, which otherwise could be spent on thinking about proper pruning solutions?

It is actually max(0.0005, (ins + outs) * 0.000075) so is fairly stupid but is higher for larger transactions.

Code is here: http://code.google.com/r/fireduck-magicpony/source/browse/core/src/main/java/com/google/bitcoin/core/FeeFinderCounting.java

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.

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.

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

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.

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

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

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.