Topic: Soft block size limit reached, action required by YOU - page 14. (Read 64257 times)

You're forgetting that every node needs to receive, then process (incl signature checks) each block before it even begins relaying it to its next peers.

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

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.

Where it should be - silent.

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.

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.

thanks

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.

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.

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

is there a simple patchfile available to exclude SD?

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 game with 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".

Quote from: 🏰 TradeFortress 🏰 on March 07, 2013, 03:53:27 AM

Quote from: Luke-Jr on March 06, 2013, 09:48:14 AM

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.

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

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

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!

hmmm...

https://bitcointalksearch.org/topic/can-anybody-stall-bitcoin-for-72btc-per-hour-answer-no-148211   Can anybody stall Bitcoin for 72BTC per hour?

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

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!

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.

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.

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.


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.