Soft block size limit reached, action required by YOU

[SRoulette]

how about no? because I don't want encourage some gambling website to fill up my hard drive with their bets.

Then don't let sdice transactions into your solved blocks, and encourage others to do the same.  Mike didn't say you have to increase the soft limit.  Luke-Jr posted about your other options.

Personally, banning sdice outright seems like the kind of scummy meddling bitcoin is supposed to solve.  I would rather make them pay transaction fees somewhat proportional to the cost they incur on the network.  If they pay them, miners get more money for their trouble, if not, they stop spamming the chain.

It does seem like the decent thing to do, for our casino we simply pay the network requested fees on all out payouts and adjust our margins and payouts to compensate. We even modified our dice game to make losing payouts an option for the players.

We like satoshidice (we kind of have to, we modelled some of our games after them) but we would like to see them take a more active involvement in resolving this issue that affects us all.

[1714827203]

1714827203

[1714827203]

1714827203

[mrb]

BTC Guild started setting up a new server this morning running modified block rules.  Currently trying out a 500,000 byte maxblocksize.  The problem is with larger blocks, you increase the chance of orphans since it will take at least twice as long to propagate, if not more.  I've modified the fee settings to prefer fee based transactions when increasing the block size past 50 KB, so hopefully the increase in fees per block offset the orphan rate increase.

What do you mean you have modified the fee settings? Were you not doing what the Bitcoin client has always been doing? In other words: 27kB for storing high-priority transactions (regardless of the fee), and the remainder of the block always preferring fee-based transactions.

And I don't care for satoshi dice. Let them move to litecoin or ban them from spamming the network and my harddrives.

Well. I am partaged on what to think about satoshidice. On one hand they pollute the block chain, but on the other hand they do help stress-test bitcoin's technical limits in the real world relatively early in its history.

[Peter Todd]

Add an additional .001 optional fee in your client and your transaction will be in the next block. The blockchain flooders are cheapskates. Transactions are not supposed to be cheap enough that you can blast hundreds of them out an hour with your gambling bot.

This.

I'm running a timestamping service that's been making about two or three transactions an hour for the past few days, each with 0.0005BTC fees. Looks like about 90% to 95% of my transactions are confirming in the next block, and the rest within another block.

Seriously, if you can't spend a 0.001BTC - a bit less than 5 cents - to publish a transaction that thousands of computers have to verify and store for eternity in the one rock-solid high value decentralized currency known to man, stop complaining. I'm surprised the large-blocks/low-fees group hasn't been compared to the usual socialists wanting to centralize profit and decentralized costs yet... or maybe they have - following the forums with this crap is a full-time job.

You know, my timestamping thing, OpenTimestamps if you want to know,(1) has been called blockchain spam by some. For the technically inclined, no it doesn't bloat the UTXO space, but it does add blockchain space. However, it and other abuses like storing files in the blockchain will naturally be crowded out as transactions become more expensive, so the total damage will always be limited without centralized enforcement efforts like Mike's pleadings for miner's to "stop the satoshidice spam". Already TX fees would cost me $100USD/month to run the timestamper if every block had a timestamp transaction in it, so I'll soon have plenty of reasons to change the way it works, just like the price of gas gives people incentives not to waste it.

On the other hand, if we go ahead and let the maximum block size get as large as miners want, there's no reason not to use it for all sorts of BS things, and little we can do to stop abuse without centralization. Sadly, I suspect as it becomes more and more expensive to participate as a full-fledged miner, instead we'll just see the number of pools decrease, and P2Pool die off from lack of miners, until central efforts to "stop spam transactiosn" start happening, and then you're one step away from "stop silk road" being possible.

1) FWIW, it's not quite ready to be called production yet, but if you can find the software on github, go ahead and try it out.

[eleuthria]

BTC Guild started setting up a new server this morning running modified block rules.  Currently trying out a 500,000 byte maxblocksize.  The problem is with larger blocks, you increase the chance of orphans since it will take at least twice as long to propagate, if not more.  I've modified the fee settings to prefer fee based transactions when increasing the block size past 50 KB, so hopefully the increase in fees per block offset the orphan rate increase.

What do you mean you have modified the fee settings? Were you not doing what the Bitcoin client has always been doing? In other words: 27kB for storing high-priority transactions (regardless of the fee), and the remainder of the block always preferring fee-based transactions.

The old settings were default, with the 250,000 byte limit, 27k for high-priority (regardless of fee).  The new settings we're trying (subject to change, and not on all servers yet) is 500kB block max size, no reserved space for no-fee transactions with high priority, and a minimum size set to 50 kB to grab high priority/no-fee transactions if there aren't that many unconfirmed paid transactions.

[optimator]

I lost a lot of money today because of this shit. And I don't care for satoshi dice. Let them move to litecoin or ban them from spamming the network and my harddrives.

Sorry to hear about your financial loss. That sucks.

But, I must say, it rubs me wrong when I hear complaints about "spamming the blockchain" and the evil of satoshi dice. Where do you see bitcoin going? Do you want to keep it as a little pet or do you want it to become a global currency beyond the borders of governments?

Clearly, the way bitcoin was designed was to encourage the gradual adoption of transaction fees, as those fees will replace the revenue lost from the block reward halvings. However, those transaction fees will go to the miners and the nodes will still need to store the transactions.

I see the "solution" to these problems as designing ways to creatively solve the "problem". For example, implementing a parsed version of the blockchain to remove older transactions.

We shouldn't run from or discourage satoshi dice, we need to embrace it as a precursor of what is to come.

Cheers!

[Smoovious]

Personally, I see the miners who are refusing all transactions (so their blocks propagate faster, less chance of orphans), who are only mining for the reward, completely ignoring that the purpose of mining is to process transactions in the first place, as being a bigger problem than Satoshi Dice is.

As long as Satoshi Dice's transactions are following the rules, that's all that matters to me. I don't care what the purpose the transactions are for. Not my business.

Look at the block explorer from time to time. I see plenty of found blocks that have 0 transactions in it, just the reward generation.

That is the big problem.

-- Smoov

[phelix]

BTC Guild started setting up a new server this morning running modified block rules.  Currently trying out a 500,000 byte maxblocksize.  The problem is with larger blocks, you increase the chance of orphans since it will take at least twice as long to propagate, if not more.  I've modified the fee settings to prefer fee based transactions when increasing the block size past 50 KB, so hopefully the increase in fees per block offset the orphan rate increase.

this is very interesting and might actually be a good thing that leads to a balanced blocksize. Transactions actually do come at a cost for miners!

[...]
The old settings were default, with the 250,000 byte limit, 27k for high-priority (regardless of fee).  The new settings we're trying (subject to change, and not on all servers yet) is 500kB block max size, no reserved space for no-fee transactions with high priority, and a minimum size set to 50 kB to grab high priority/no-fee transactions if there aren't that many unconfirmed paid transactions.

hmmm...

https://bitcointalk.org/index.php?topic=148211   Can anybody stall Bitcoin for 72BTC per hour?

[johnyj]

I don't understand why gaming has to use the blockchain, feels like using armored money transport vehicles to transfer casino chips  

[🏰 TradeFortress 🏰]

Note this isn't really a problem if miners are responsible and filter out the SatoshiDice flooding.
My git repository contains a "block_dice" branch to do just that.
The 0.8.0.eligius branch designed specifically for miners and pools also includes this.
Gavin also wrote up some more advanced configuration option examples here.

Yes, this is a problem because 50% of TXes would never confirm.

[Luke-Jr]

As long as Satoshi Dice's transactions are following the rules, that's all that matters to me. I don't care what the purpose the transactions are for. Not my business.

SatoshiDice does not follow the rules:
The blockchain is a system for transferring value, of which the final total is specified in advance. Those are the terms of the social contract every Bitcoin holder has adopted understanding. Those are the terms every node has agreed to voluntarily participate in the network.
Nodes and miners have not unanimously agreed to have their resources/time spent inefficently processing informational messages like "you lose", "you win", or even "I bet on <this> game with <this> much". This was never part of the agreement.
Nor is the system supposed to hold up to flooding. If you go back to even the original paper by Satoshi, miners are expected to filter out flooding attacks like this. The proposed transaction fee solution works in most cases, but not SatoshiDice because they have social-engineered gamblers into covering the fees for them, and to make it worse the gamblers are willing to pay a higher fee than real users. If Bitcoin had achieved critical mass already, we might have been able to just say "too bad, deal with higher fees", but at this pre-adoption stage the response to that would almost certainly be "screw you, I'll stick with VISA".

Note this isn't really a problem if miners are responsible and filter out the SatoshiDice flooding.
My git repository contains a "block_dice" branch to do just that.
The 0.8.0.eligius branch designed specifically for miners and pools also includes this.
Gavin also wrote up some more advanced configuration option examples here.

Yes, this is a problem because 50% of TXes would never confirm.

No, filtering out flooding attacks responsibly improves confirmation time of transactions.

[K1773R]

Note this isn't really a problem if miners are responsible and filter out the SatoshiDice flooding.
My git repository contains a "block_dice" branch to do just that.
The 0.8.0.eligius branch designed specifically for miners and pools also includes this.
Gavin also wrote up some more advanced configuration option examples here.

is there a simple patchfile available to exclude SD?

[Luke-Jr]

Note this isn't really a problem if miners are responsible and filter out the SatoshiDice flooding.
My git repository contains a "block_dice" branch to do just that.
The 0.8.0.eligius branch designed specifically for miners and pools also includes this.
Gavin also wrote up some more advanced configuration option examples here.

is there a simple patchfile available to exclude SD?

$ git diff 5b98972..block_dice | wgetpaste
Your paste can be seen here: http://codepad.org/7RQZIkhd

[Akka]

Personally, I see the miners who are refusing all transactions (so their blocks propagate faster, less chance of orphans), who are only mining for the reward, completely ignoring that the purpose of mining is to process transactions in the first place, as being a bigger problem than Satoshi Dice is.

As long as Satoshi Dice's transactions are following the rules, that's all that matters to me. I don't care what the purpose the transactions are for. Not my business.

Look at the block explorer from time to time. I see plenty of found blocks that have 0 transactions in it, just the reward generation.

That is the big problem.

-- Smoov

I agree this is a point.

I know mining is a (mostly) free marked. But this guys are basically hurting the bitcoin users.

Wouldn't it be possible to thread this behavior as an attack on bitcoin, therefor not accepting this blocks, when there is a significant amount of transactions required?

Something like: if unconfirmedtransaktions >= 1000kb and blocksize <= 150kb then
reject block

Of course at least 51% of all miners would have to agree to this, otherwise miners that agree would only hurt them self.

[Luke-Jr]

Personally, I see the miners who are refusing all transactions (so their blocks propagate faster, less chance of orphans), who are only mining for the reward, completely ignoring that the purpose of mining is to process transactions in the first place, as being a bigger problem than Satoshi Dice is.

As long as Satoshi Dice's transactions are following the rules, that's all that matters to me. I don't care what the purpose the transactions are for. Not my business.

Look at the block explorer from time to time. I see plenty of found blocks that have 0 transactions in it, just the reward generation.

That is the big problem.

-- Smoov

I agree this is a point.

I know mining is a (mostly) free marked. But this guys are basically hurting the bitcoin users.

Wouldn't it be possible to thread this behavior as an attack on bitcoin, therefor not accepting this blocks, when there is a significant amount of transactions required?

Something like: if unconfirmedtransaktions >= 1000kb and blocksize <= 150kb then
reject block

Of course at least 51% of all miners would have to agree to this, otherwise miners that agree would only hurt them self.

It's not that simple. For example, it's pretty common for SD's flooding to fill more than 1000kb, so your rule would reject blocks from only the responsible miners.

[K1773R]

Note this isn't really a problem if miners are responsible and filter out the SatoshiDice flooding.
My git repository contains a "block_dice" branch to do just that.
The 0.8.0.eligius branch designed specifically for miners and pools also includes this.
Gavin also wrote up some more advanced configuration option examples here.

is there a simple patchfile available to exclude SD?

$ git diff 5b98972..block_dice | wgetpaste
Your paste can be seen here: http://codepad.org/7RQZIkhd

thanks

[dustintrammell]

I don't understand why gaming has to use the blockchain, feels like using armored money transport vehicles to transfer casino chips  

It doesn't, and in my opinion is the wrong thing to do.  My site, BitDraw (provably fair features coming soon!) of course uses the blockchain to process deposits and withdrawals, as it must, but all other transactions between players, or between the players and the site, are handled within our system and are not exposed to the blockchain.

Further, games, applications, and other sites that are integrated directly into the Bitcoin network have increased attack surface.  By being integrated, they necessarily must have direct access (or a more intricate abstraction layer) to either bitcoind or the Bitcoin network directly.  This means that they have access to one or more wallets, which increases the risk of funds in those wallets being stolen by an attacker that compromises that system.  BitDraw avoids this entirely by using an offline wallet, not having any access to it from the web application or server itself, and handling withdrawals via manual processing.  The latter won't scale, but we'll address that when it actually becomes an issue.

[dustintrammell]

The blockchain is a system for transferring value, of which the final total is specified in advance. Those are the terms of the social contract every Bitcoin holder has adopted understanding. Those are the terms every node has agreed to voluntarily participate in the network.
Nodes and miners have not unanimously agreed to have their resources/time spent inefficently processing informational messages like "you lose", "you win", or even "I bet on <this> game with <this> much". This was never part of the agreement.

Would the latter two of those "messages" not represent a transfer of value, of which you just stated that Bitcoin is a system for?  I presume (I haven't looked at exactly how Satoshi Dice works) that when you place a wager, the player is transferring value to Satoshi Dice.  Then, if they win, Satoshi Dice is transferring value back.  I see no transfer of value in the "You Lose" message as I would assume Satoshi Dice keeps the value, so I completely agree with you there, that would be a completely informational message.

[hazek]

Where is the foundation during the only moment we need it?

Where it should be - silent.

[Luke-Jr]

The blockchain is a system for transferring value, of which the final total is specified in advance. Those are the terms of the social contract every Bitcoin holder has adopted understanding. Those are the terms every node has agreed to voluntarily participate in the network.
Nodes and miners have not unanimously agreed to have their resources/time spent inefficently processing informational messages like "you lose", "you win", or even "I bet on <this> game with <this> much". This was never part of the agreement.

Would the latter two of those "messages" not represent a transfer of value, of which you just stated that Bitcoin is a system for?  I presume (I haven't looked at exactly how Satoshi Dice works) that when you place a wager, the player is transferring value to Satoshi Dice.  Then, if they win, Satoshi Dice is transferring value back.  I see no transfer of value in the "You Lose" message as I would assume Satoshi Dice keeps the value, so I completely agree with you there, that would be a completely informational message.

While there is a value attached to the latter two, it is primarily a message. Otherwise, a gamer would just transfer a deposit, play, and withdraw (as I notice your site does) - no message passing involved.

For an easy analogy, this would be like WalMart charging your credit card for every item you pick up off the shelf, and refunding you if you put it back (actually worse, since SD uses 2 transactions for every action).
Not even VISA/MC could handle that kind of abuse, and their system (being centralised) is far more efficient than Bitcoin.

[Mike Hearn]

BTC Guild started setting up a new server this morning running modified block rules.  Currently trying out a 500,000 byte maxblocksize.  The problem is with larger blocks, you increase the chance of orphans since it will take at least twice as long to propagate, if not more.  I've modified the fee settings to prefer fee based transactions when increasing the block size past 50 KB, so hopefully the increase in fees per block offset the orphan rate increase.

I'm actually hopeful that you won't notice much difference in propagation times.

We're talking about 500kb data structures here. Any mining pool worth its salt is running out of decent colo facilities in the USA or Europe with good connectivity. Transmission time is negligible at current sizes. The slow part is validation and disk IO. However Bitcoin 0.8 has two features that should make acceptance of a new block fast:

1) The signature cache means that when you see a transaction appear in a block, you are very likely to have already checked its signatures when it was previously broadcast through the memory pool (your node is "warm"), so there's little or no ECDSA computations required.
2) LevelDB means the difficult parts of managing the disk is done on a separate thread. In theory you should need only a handful of disk IOPs to accept a new block because all the compaction is done on a separate core in the background.

I think it should be quite feasible to accept and announce a new block in something like 30-40 msec.

So I'll be very interested to see if practice matches theory - if it does then you should not see a 2x propagation time, certainly not more than 2x. And if you do then we just need to fix it