Quote from: Syke on February 27, 2013, 06:08:06 AM

S.Dice is essentially micro-transactions. Increasing the block size to support micro-transactions is absolutely the wrong idea. Bitcoin cannot be built around micro-transactions.

what you are really saying here is:

Quote

S.Dice are transactions. Increasing the block size to support transactions is absolutely the wrong idea. Bitcoin cannot be built around transactions.

Most people around here are thinking about transactions incorrectly. I'm going to single out Jeff in passing because he is a core-dev that has only gone from one extreme to another. Bitcoin is not built to support micro-transactions and this is evident from the way transactions must propagate and all the economic incentives that support the auditing of transactions. What is not evident is what a "micro" transaction really is in the context of Bitcoin.

I think fundamentally a micro transaction in Bitcoin is a transaction or perhaps a tx out that is not worth propagating or auditing. Technically it is very hard to argue S.Dice is a micro transaction otherwise it would be impossible to propagate or audit. Economically it is not so clear cut, but there is a market for auditing S.Dice transactions, so I would say economically it is not a micro transaction. You can say that S.Dice is subsidized by the block reward, but take the reward away and it almost the only incentive to audit other transactions. Thus, S. Dice will not truly be a micro transaction in the context of Bitcoin until it is impossible to transact on the Bitcoin network. When that will happen will be determined entirely on network management.

Bitcoin never promises to support micro transactions as I've outlined it nor is it built for that. Bitcoin is a payment network. From a network management point of view S.Dice is a problem because of the spammy messaging, but otherwise the transactions are just as valid as any other on the network.

My network management suggestion to S.Dice would be to include the messaging component as part of the bet so the messaging output would be limited to the size of the minimum bet, which should follow whatever the network can support. Integrations with wallets such as blockchain.info could just hide the messaging component of the bet to make it user friendly, done correctly it could even be used to collect any dust it has already created. Perhaps it is also worth considering not using a messaging component for most S.Dice bets as it has already established a reputation and messaging could be implemented as an optional value-added service rather than a default operating mode.