Bitcoin Forum

There has been some discussion regarding Double Spend against a Satoshidice loss, but it seems that no one has seriously considered Finney Attack against SatoshiDice. This attack is both simple and (IMHO) very easy to mount by an attacker-miner.

The idea is simple: Suppose a miner has any percentage of the network hashing power, say 1%.
Suppose a miner has 241 BTC in an previous output X.
This miner creates a block containing ONLY a single transaction TxWhenLost that pays 241 from X to a new address he owns.

Then the attacker starts mining as normal (and updates the special block to a new parent whenever a new block is solver by the network).
After 16.6 hours on average, his solves a block. Then instead of broadcasting it, he first creates a transaction TxTest that bets the 241 BTC in X against SatoshiDice. Suppose the bet is:

TxTest bets 241 BTC against less than 6000
(address 1dice6wBxymYi3t94heUAG6MpG5eceLG1).
The winning probability is 9.1553% and the multiplier is 10.666x.
That means that approximately every 7 days the attacker wins SatoshiDice.

Now he sends TxTest to SatoshiDice. SatoshiDice replies broadcasting the result TxResult (they say this is almost instantaneously).  Now the attacker decides:

if he has won, he discards the solved block without broadcasting.
If he has lost, he broadcasts the block as soon as possible. Since the block has very few bytes, it will propagate fast. The attacker may also have many nodes in the network to propagate faster the block.

Analysis

9.1553% of the times the attacker wins 241*10.666-25=2545.506 BTC
90.8447% of the times the attacker wins 25 BTC

So the expected income PER SOLVED BLOCK is 233.04+22.71=255.75 BTC !!

That 10x more the 25 BTC a miner normally receives.

Even if 1/10 times the attack fails, the expected income is notably higher than normal.
This is not the best possible attack: if the attacker has greater hashing power or doesn't mind to wait more, he can try bets to "lessthan 1500". In this case the earnings 3 times more (750 BTC per solved block).

The only assumption I'm making is that SatoshiDice responds with TxResult within a short time interval (say 30 seconds).

The only way I think SatoshiDice can protect from this attack is by waiting for 1 confirmation from the transactions they receive or by delaying TxResult 5 minutes or so.

I haven't  contacted the owner of SatoshiDice since there is no contact information in the web page. If you know who the owner is, please tell him to follow this thread.

Disclaimer: as always, I haven't test the attack, so I may be wrong.
Think for yourself.

Best regards,
 Sergio

How can someone not know that evoorhees (https://bitcointalk.org/index.php?action=profile;u=12149) owns Satoshi Dice?

They wait for 1 confirmation on bets over a couple BTC. This has been discussed before, and a variation (that doesn't require hash power) of it performed in the past.

Ohh! It's a pity they don't said that on the web page, it would have saved me and you time. They clearly said the response is immediate, probably for  marketing.

Indeed, and I wasn't actually able to tell you what the exact threshold is— since it doesn't even appear to be documented!

One of the reasons they have to do this is that its really really easy to double spend against SD because some pools will not mine transactions paying them. So you can make a bet, if it loses, make a double spend to a non-sd address and give it to miners that ignore SD transactions. They may not solve the next block— but it still makes your expected return positive.  Another variation is to make the txn paying SD have an input that is part of a really long unconfirmed chain which will take a long time to confirm... and double spend that, giving more time for the conflict to get confirmed. etc.

Why would miners drop transactions for SD? That makes no sense. Sure they might de-prioritize them but no need to drop them, especially if they have fees (do they?)

Fees are still pretty tiny in comparison to the block reward, and some people are willing to pay that small price because they don't like Satoshidice.

Don't assume everyone is a perfectly rational economic actor, or even that perfectly rational actors are using the same set of assumptions that you are.

They have tiny fees, which likely don't pay for the marginal increase in the odds that the block gets orphaned due to its increase propagation/validation time.

Those transactions are insanely inefficient— half of them are pure messaging and not really a monetary transaction— they make it much more costly to run a Bitcoin node— they're burning up our technical startup capital without adding new users to the bitcoin economy (or at least not many). The bitdust outputs they create will likely never be rational to spend and are rapidly inflating the UTXO set— unprunable data. Across the board they're bad they're bad for the ecosystem... and they're ever so easily blocked, basically a one line patch.  So, even if it wasn't net-profitable to block them I'm sure some would.

Have you considered that maybe SatoshiDice is a government sponsored attack on Bitcoin ?  :)

And they suckered thousands of people into buying shares in the company, thus attacking themselves!

Excuse my ignorance, but please explain "...updates the special block to a new parent whenever a new block is solver by the network)."  All the subsequent blocks are not aware of this special block, how can the miner just broadcast it later and get the txwhenlost confirmed?

It was an awkward way to say that the block is disposed and a new block is created (on top of the best chain), containing the same transaction  txwhenlost. Obviously the parent block will be different.

That's the best part of the attack.. the community is sponsoring it!  :)

SatoshiDice is "burning up your technical startup capital without adding new users to the bitcoin economy?"  Are you serious?

First, SD has paid more mining fees than everyone else in the world, combined.

Second, I'll just leave these here...

http://calvinayre.com/2013/02/01/business/why-bitcoin-can-no-longer-be-ignored/ (http://calvinayre.com/2013/02/01/business/why-bitcoin-can-no-longer-be-ignored/)
http://www.businessweek.com/articles/2013-01-03/bitcoin-making-online-gambling-legal-in-the-u-dot-s-dot (http://www.businessweek.com/articles/2013-01-03/bitcoin-making-online-gambling-legal-in-the-u-dot-s-dot)
http://www.npr.org/blogs/alltechconsidered/2013/02/06/171182974/is-online-gambling-legal-if-bitcoins-not-dollars-are-at-stake (http://www.npr.org/blogs/alltechconsidered/2013/02/06/171182974/is-online-gambling-legal-if-bitcoins-not-dollars-are-at-stake) (was on national radio)
http://www.forbes.com/sites/jonmatonis/2013/01/22/bitcoin-casinos-release-2012-earnings/ (http://www.forbes.com/sites/jonmatonis/2013/01/22/bitcoin-casinos-release-2012-earnings/)
http://www.wired.co.uk/news/archive/2013-01/23/bitcoin (http://www.wired.co.uk/news/archive/2013-01/23/bitcoin)
http://arstechnica.com/business/2013/01/bitcoin-based-casino-rakes-in-over-500000-profit-in-six-months/ (http://arstechnica.com/business/2013/01/bitcoin-based-casino-rakes-in-over-500000-profit-in-six-months/)
http://www.gambling911.com/gambling-news/bitcoin-casino-satoshidice-results-raise-eyebrows-online-gambling-sector-012313.html (http://www.gambling911.com/gambling-news/bitcoin-casino-satoshidice-results-raise-eyebrows-online-gambling-sector-012313.html)
http://techcrunch.com/2013/01/23/online-casino-makes-over-500k-skirting-laws-with-legally-gray-digital-currency-bitcoin/ (http://techcrunch.com/2013/01/23/online-casino-makes-over-500k-skirting-laws-with-legally-gray-digital-currency-bitcoin/)

SatoshiDice achieves all this publicity, demonstrates the power of Bitcoin and provably fair gaming to the masses, and brings Bitcoin to the attention of casino operators around the world, and yet still people complain because it "makes too many transactions" and for their antagonism decide to block SD transactions from their mining pools  ::)

Just because you pay the fine for vandalism, does not mean it's acceptable to vandalize, or that it covers the expense in cleaning up the mess you made.
Even with the "standard" transaction fees, miners are still subsidizing transactions at their own (direct) expense in hopes of improving their (indirect) gains from the increased value of Bitcoin as adoption increases (which depends a large part on lower fees right now).

SatoshiDice does nothing beneficial for Bitcoin.
What little adoption it brings is from irrational gamblers and the casinos out to exploit them; these are not the kind of people who improve the value of Bitcoin at all, just make it more likely to be banned.
What it does do is flood the network with abusive "transactions" conveying more information than finances ("I bet x BTC", "you win", "you lose" are information), using more activity than any payment network today could handle (relative to actual usage). Other reasons aside, this alone would get your attack blocked by VISA et al. Bitcoin attempts to block this attack as well: even in the original paper, miners are expected to deal with flooding attacks. Obviously the original suggestion of using merely fees is not sufficient, since SatoshiDice uses social engineering to fool gamblers into paying 100% of the cost to bypass this anti-flood measure. While we could simply increase fees until the flood stops, the extent we would need to do so would effectively kill adoption of Bitcoin. Blocking SD directly is the only known viable method of Bitcoin surviving this attack.

Note that Bitcoin is a lot of things, but it is not meant to ever be more efficient than other processing networks like VISA. Centralized services are by nature more efficient, so that is unavoidable.

You refuse to stop flooding the network, and insist we deal with it ourselves. Blocking SD outright is how Bitcoin deals with this kind of attack. Deal with that. ;)

Of course, the best way forward is for you to stop attacking Bitcoin. There is nothing inherent in SD's design that necessitates the flooding by any means. A similar service (that I would setup myself, if it weren't illegal) could be done very easily:

• Use compressed public keys for everything. There is no need to waste 2x the space for no gain by using uncompressed keys.
• When a user visits your site, prompt for a withdrawl/cashout address immediately, so there is no opportunity to lose bitcoins. This fixes your bug whereby SD is assuming the first input's previous destination happens to be a valid return address - this bug causes bitcoins to be lost in all cases it isn't true, and creates real security problems when Bitcoin implements post-quantum cryptography upgrades (currently, post-quantum crypto requires that addresses never be used more than once).
• After users provide their cashout address, give them a deposit address. They send however many bitcoins they want to gamble with.
• Display the gambling game(s). Let the user play as much as they want, with instant feedback. RageCoin (https://ragecoin.appspot.com/) has an example of just one way to have easier and instantly-verifiable provably fair gaming.
• When the user is done (leaves the site, clicks a button, or just stops doing anything for N minutes), send whatever balance is left to their cashout address.

Edit: And in case anyone thinks SD would somehow be less "popular" with these changes, note that they could very well support both ways of using it and find out for sure. (not that there's any doubt in my mind)

I believe S.DICE is one of the top 5 services in the Bitcoin economy and it has brought a massive amount of publicity and new users. I also think it's plain wrong to somehow say it's a "lesser service" because it is gambling. It's a service that has demand and adults should be free to play with their money if they want to.

The problem it causes for the blockchain can be solved by simply smoking it out with fees. I mean, services such as S.DICE will be hurt more than anything by higher tx fees, which would be a certainty if the block size max is kept untouched. They would be the first to consider an alternative way which doesn't use the blockchain, or doesn't use the Bitcoin blockchain at least.

This is very off topic and I'm already tired that we have 100 threads in this forum about this same issue, but I'm starting to agree that we actually should smoke out certain services by not touching the block size max until it hurts them. I mean, let's see if users of S.DICE truly want to pay for it, or not.

This would most likely not be a problem for the rest of Bitcoin users since S.DICE should be much more vulnerable to higher fees than regular users. There are spammy methods (martingale bots) of playing S.DICE and a major amount of their transactions consist of these methods. The spammy methods would reduce if fees were increased, which is good. Bitcoin needs a fee structure that reduce all spammy uses of the blockchain, but still allows regular usage.

Sure, that's fine with me (though I bet not the State of New York), but he can't justify attacking the network with "publicity" that only brings a few fools and government crackdown. There is no evidence there are any "massive" amounts of new users involved of any sort.

Did you even read my post? The problem is that increasing the fees to "smoke it out" would kill Bitcoin adoption. Do you really want that? The reality is there already are alternative ways that don't use the blockchain; SD just refuses to do things efficiently.

They almost certainly will. Gamblers are psychologically inclined to tolerate a higher fee than rational transactors.

I don't think that trying to ban S.DICE is a proper solution to anything. Higher fees are a solution, even if it does affect regular usage somewhat. As far as I know, majority of S.DICE transactions come from martingale bots which would be very much affected by higher fees. For the martingale strategy even small differences make it much more suicidal. It's exactly these kinds of spammy gambling transactions that should be deincentivized.

Transaction fees are just another form of a ban, one that is suicidal to Bitcoin in this scenario.

You do understand that Bitcoin either suffers from higher fees at some point or weakens and dies completely? Those 2 options are the only possible options if we continue to use proof of work. Option 1 is achieved by limiting the block size and letting scarcity come in, with the goal of retaining sufficient hashing power, leading to higher fees. Option 2 would be achieved by removing the block size limit entirely, which would let us keep non-existent fees but that would weaken Bitcoin to the point of easy destruction.

The only question with option 1 is how much the fees will rise, not if they will rise. Debating about if they rise or not is not a debate because it's a certainty. I'm concerned about them rising in a way that still keeps Bitcoin competitive with mainstream money transfer mechanisms. If they rise beyond that, Bitcoin adoption will die, as you said.

Yes. "At some point" needs to be after Bitcoin has attained critical mass of adoption.

And when they rise. Timing is everything.

True enough. And enough of this OT. :)

As I understand it there are ways to do the same things SD does but with less harm to the network. The fact you refuse to implement them makes people question what your motives are. The fees you pay dont adequately cover the cost of the damage you do to the network which is ironically one of the major problems with capitalism today. That is to privatise profits and make the public foot the costs. Ive got no doubt if fees got raised to cover the true cost you would start screaming about needing a "bailout" because you "deserve it".

I think Satoshi Dice should mine its own transactions instead of paying fees.

That would require them actually investing in hardware and not sponging off all the other miners.

They could hire a pool to allocate some percentage of blockspace to free SatoshiDICE transactions.

Or they could improve their efficiency by doing things in a different way. You shouldnt change the underlying protocol just because they are "lazy"

Im just glad they cant lobby a politician to get them to change it  :)

What some people here do not understand that it's not SatoshiDice that is to blame for the inefficiencies of the blockchain. That service is completely following the rules of Bitcoin. It's a fee-paying, fair service, I see no problem with that. The problem is with Bitcoin, not with S.DICE. That should be very clear.

No. SatoshiDice violates the "no flooding" and "financial transactions only, no information" rules. Bitcoin's solution is to block flooders. Miners filtering out floods is part of the system.

If Satoshi Dice really is profitable on its own merits then they could afford to mine their own transactions instead of paying other miners to do it via transaction fees. If they could do that and still remain profitable then nobody could rightly complain that they were leeching off of the network.

In the long term when medium and large companies are using bitcoin that's what I expect to happen anyway - the companies doing the most transactions have the largest incentive to make sure those transactions get included in the blockchain so they mine themselves or band together with other companies to form a merchant pool.

This is a valid point and I do get it. Not sure what I think about the whole thing, but I do get this.

I fully agree on this! But for me it seems more like rulea of conduct which *should* be followed by consensus, but are not enforced in any way (unless miners really start skipping sdice transactions). Or is this somewhere defined in the protocol?

While Bitcoin software is still in development, SatoshiDice provides an invaluable service to the network by stressing those attributes of the system that would become a larger problem in the future when adoption grows.

It does it in a very careful and controlled way (centralized, easy to shut down) thus providing an incentive for developers to prototype solutions that would deal with an ever increasing volume of transactions gracefully and ahead of time.

We probably wouldn't have performance improvements that we do (in bitcoin-qt 0.8.0) if it wasn't for SatoshiDice. So it seems like a natural component of the ecosystem at this point which might get less popular as the network rebalances and changes some of its characteristics that make SD viable right now.

No. Bitcoin is not meant to scale to SD's abuse.
Also, while adoption grows, so does the overall network capacity to cope with higher (reasonable!) use.
Finally, we already know Bitcoin is harmed by SD's abuse in practice. Continuing to "stress" something after you know it harms it, is clearly hostile.

What-ifs are kinda pointless to argue, so I won't try.
But even if SD is to credit for bringing attention to some performance problems, it does not justify their continued attacking.

With the approach taken here, it might be possible to not only passively act, but actively fight SD spam by shifting the odds in your favour if you really don't want to see them continue with their business.

Edit: Since blocks are anyways small, it might even be possible to just mine "normal sized" blocks as well, to not be too obvious.

SD does very good job - It stress-tests the system. The Bitcoin programmers ought to thank instead of blaming... and do their best to resolve technical issues.

What does the State of New York have to do with anything?


Roughly 3/4 of SD transactions are financial transactions, and 1/4 is "information".  Every inbound bet is a financial transaction, and roughly half of the outbound transactions are winnings going back to the user. When a user loses a bet, the response is indeed an "information transaction" and this seems to be what you are so upset about.

So if SD played by the rules you wish to enforce upon it, 75% of the transactions would still be there.

Also, where is this "no information" rule listed??? I was not aware that Bitcoin had a Terms of Service contract.

But there is a far more important point to all this. Every transaction that occurs on the BTC network causes data to be stored in the blockchain. You, Luke-Jr, have sent transactions which cause blockchain bloat, you just haven't sent as many as SD. And if your transactions are "well and good" then how many do you need to send before you are considered "spamming"? Can SD only send 10 transactions a day before you get angry with it? Or 100? Or 10,000?  Is it because they are "evil gambling transactions" which makes them less worthy than your own?

I'm of the opinion that Bitcoin should be used as much as possible. It should be the monetary system of the world. And if the blockchain can't handle it, then the system needs to be upgraded or is doomed to failure because guess what, as Bitcoin grows, hundreds of creative systems are going to come out which use the blockchain in all sorts of strange ways. SD is but the tip of the iceberg.

Well, Satoshi's Dice seems to me like going to a casino, exchanging one USD in chips, playing a round of a game, changing back to USD, changing another USD to chips etc.

This described attack might also work with p2pool by the way, then you only attack with your own hash rate though. Still useful for people with ASICs at their hands and you can also mine a bit larger blocks there, as you will relay blocks at a lot of different places in the network as a bonus.

I think of SatoshiDice as a proof by reductio-ad-absurdum that the Bitcoin needs to be continue to evolve to be really useable, lest it turns into a permanent worldwide register of dropped pennies.

Many developers associated with the core development team have lots of self-worth staked on the assumption that the Bitcoin is already perfect.

Your business is showing them that they were wrong. This is no longer a technical/scientific/business issue, it is now an issue of respect and/or self-respect.

I remember a comment from one of the professors in my university:

Q: Why are the panel discussions in this school are always turning so nasty?
A: Because the stakes are so low.

Logical fallacy.  That logic precludes incentives that encourage block chain efficiency.

You cannot simply get stuck in the loop

     spam system -> demand system upgrades -> go to step 1

as that clearly lacks any amount of self-examination or dynamic feedback.

Satoshi Dice is a perfect example of "Tragedy of the Commons".

Reference: https://en.wikipedia.org/wiki/Tragedy_of_the_commons

They know using the blockchain as a signaling device is causing other effects, but they could care less.

Nobody is forced to mine Satoshi Dice transaction. Miners can set any fee policy they want for transactions to and from those addresses. If it is causing so much damage they could just refuse to mine those transactional at all and make Satoshi Dice either pay more or mine directly.

Erik & fireduck,

you should just offer a private betting addresses for your most demanding clientele. Basically have them login to your website and reserve a private set of betting addresses. Require a deposit, eg. 1BTC. From then on a private bet of 1.01BTC would mean than 0.01BTC is in the play and 1BTC is a conduit that you'll always return, both with the won bets and with the lost bets. A kind of a "refundable door charge." A sort of a thing that all decent casionos demand: evening attire. The casino will not strip the players from their clothes, even if they "lost their shirt" inside.

Good luck to everyone.

This probably means that Luke-Jr had already reported you to the New York state crime autorities as somebody that runs a gambling racket. That's the "bet" in the original quote and it matches the modus operandi of Luke-Jr.

So it makes more sense to integrate policy into all the mining nodes versus a single actor changing their behavior?

Mind boggling...

I don't see where I said it was better to do it that way than for Satoshi Dice to change.

If Satoshi Dice is not willing to change that would be the best way to go. If they aren't willing to be reasonable then I don't understand why miners would just complain publicly instead of doing something about it. They aren't helpless. They have options other than complaining.

Hehehe I wouldn't be surprised, he seems to be okay with using violence against peaceful people to get his way. Good thing neither SD nor myself are based in NY, or the US for that matter ;)

Miners (and the network) will not see the impact as long as the block reward far exceeds other network costs, like unspent transaction output set (UTXO) storage.

We should consider the solution using CoVar I proposed. It hurts no one, and it helps a lot with SD.

imagine you have a guy who would shoot people for parking violations.
then imagine you put him in a room with a guy who would park a tank in front of a hospital emergency entrance if they forget to put up a sign.

my guess: this is bound to be a long, fruitful discussion  ;D

The system needs to be able to handle 1000x as many transactions as it does today, else the whole project is silly.

It does not matter what those transactions are for...whether financial, or informational, or experimental, or whatever. If Bitcoin can't handle far more volume that it does today, we should move on to something that can. SatoshiDice simply makes us face this issue sooner than we otherwise would.

Why call it silly? It is just a divergence of goals.

a) You belong to a group who wants Bitcoin to become a censorship-resistant Internet transaction media.

b) Core development team wants Bitcoin to become a value-preserving investment vehicle.

Group a) benefits from rapid evolution and good integration with the existing systems of electronic commerce.

Group b) benefits from paranoidal level of conservatism and avoidance of hard forks at all possible costs.

Is there a way to somehow unify those goals?

Maybe fund a stipend for grau and his bitsofproof? I think his code and his development style would be a good counter-balance to the obsesive conservatism of Gavin Andresen. Nobody in the core development team has any meaningful experience in development of transactional financial software.

Prunable, spendable transactions, sure.

1/4 of SatoshiDICE's output is not that.

Shouldn't we just admit that Bitcoin has failed and move on to Bitcoin 2.0?

Maybe the high volume of fast transactions folk should be looking to litecoin, not bitcoin.

Litecoin already has four times as much blockchain space for transactions per ten minute period, and it has faster confirmation too. It might also be more open to hard forks.

term store of value folk can stick with bitcoin, and litecoin can be used more for the kind of stuff it was intended for.

Win-win. Well except for me, as I didn't get to stockpile millions of litecoins. But apart from that it sounds good.

-MarkM-

If you can use wikipedia, I can use urban dictionary.

http://www.urbandictionary.com/define.php?term=I%20could%20care%20less

The phrase is "I could NOT care less" meaning that I care so little there is no way for me to care any less.

Why do people not understand this... sigh.

(this is nothing personal - lots of spoons on this board make that mistake)

toodles.

(and no, I dont know why sdice shit on the block chain - and I do care that they shit on the chain, I wish they would stop. But that means they would have to have the skills to implement a better solution.)

It is simply not a good use of the available investment funds. Bitcoin has already significant costs sunk in. Expending a one-two man-years of a developer knowledgeable in finance, databases & middleware is just money better spent.
The coins are already half-way minted. Now the business question is:

a) do you want them tarnished (not necessarily with shit ;) ) in a circulation?

b) do you want to wrap each one in a plastic display wrapper and hope they rise in value? I mean Satoshi Nakamoto is like Salvador Dali, he isn't minting anymore like Salvador Dali isn't signing any canvases, even blank.

IMHO,

first step could be for SD to use compressed keys... you still have 1/4th of informational transactions, but at least they use less space.

spiccioli

I agree with the lead developers: "If it ain't broke, don't fix it."

The bitcoin network is working fine for the majority of users, even those who want to partake in activities that some people frown upon, such as gambling on the blockchain. We aren't having issues with miners not including transactions, or insisting on fees that folks aren't willing to pay, we're not getting close to the blockchain limits, etc. I'd rather wait to see if these things even become a problem, and how they are manifested. We're arguing over things that might happen years (not months) from now, there is no pressing need to change the code now, imo.

People, if u r unable to resolve the SD issue how the hell r u going to withstand pressure of the state? :facepalm:

Bitcoin doesn't need to be attacked by anyone to increase in value. Why would a state attack something that amounts to an elaborate distributed art project? It is sufficient to manage the perception of scarcity. And this is true both for pro-state and anti-state crowds.

http://en.wikipedia.org/wiki/Conservation-restoration


If you have any doubts: check out posts from eg. cypherdoc. He not only invested in Bitcoin, but also bought the first issue of Bitcoin Magazine and stored it in a protective sleve. Maybe it will reach the price of the first issue of Superman comic book?

On the other hand promoting rapid and wide adoption is scary to both crowds too, but likewise for the opposite reasons.

It really isn't clear which strategy offers higher gain. And the answer depends on the time frame in the question.

is it one or the other? :) the point I was trying to make, is that sdice is in a reasonably unique situation. I dont really care about the coins, my point is more a technical one. they could try to fix the issue, or they could keep pissing in the swimming pool.

What bitcoin really needs is people to layer services upon it, rather than embed them into it.  sdice does a bit of both at the moment, but leans more to using the block chain as an information store rather than a ledger - this is the perceived abuse of the block chain (shitting on it) they don't _have_ to act in this manner, for them it is a business decision.

sdice due to their volume could implement a robust layer on top of the chain, they would then be solving an issue that will be a problem for bitcoin in the future.  I dont understand their mentality, but then im in this for the tech, not the coins... they seem to be in it for the funny masks... (if i could get masks like that, it might change my attitude too... ;) )

but (aside from the masks) other people have made these points far more eloquently than I have.  I only got involved in this thread to correct the "i could care less" (meaning you care!) crowd and felt obliged to put something related to sdice in the post.

for the record, I do not dislike sdice, just their business practices... at the end of the day its all just boxes with frogs in.

peas, lube and untidy.

steve

This is true. But in the current state of the "Bitcoin engine" resembles a museum exponat. After 4 years of development there was no single deployment of Bitcoin in a proper transactional environment with two-phase commit (or something similar).

http://en.wikipedia.org/wiki/Transaction_processing

The blockchain and transaction information is still not stored in a database, but in a raw stdio/iostream file.

This is all because of the principle of "minimal intervention".

You can't successfully layer on top such a weak engine.

Yeah, the issues aren't really technical. They are the issues of mentality. The current prevailing mentality is "art project".

What you're describing is _not_ desirable for the processing of the Bitcoin network itself. It has nothing to do with "minimal intervention" and a lot more to do with your suggestions actually being unhelpful when they are not outright nonsense. (I am responding at all because many of the people reading this thread do not have enough of a background in technical minutia to realize that half of what you say is techno-babble)

In this case, because the blockchain is inherently read only an append only stream is a fantastic, highly robust, extremely durable, and perfectly efficient data store for it.

There are plenty of alternative clients which have stuffed the data into an SQL RDBMS and their performance and resource requirements are a joke compared to the reference client.

Something layered _on top_ of Bitcoin would by definition not be using the Bitcoin infrastructure, it might reasonably store and process its data another way and thats fine. Besides— it's not like there is some grand-mugwump prohibiting this from being done. If you have a better way to do it trolling about on the forum proves nothing. Show us the code.

Again, you are just showing how little you've understand of the problem of data integrity.

I've already posted this link couple of months ago.

http://blogs.msdn.com/b/pathelland/archive/2007/06/14/accountants-don-t-use-erasers.aspx

Accountants don't use erasers yet they store their data in database? What gives? This article is a nice introduction to the concept of financial data integrity.

Core development team had choosen to take a detour and use LevelDB, a toy database written by Google folks to showcase their BigTable technology, but without the server farms, integrity guaranties, multitasking, multiprocessing, query optimization, statistics gathering, etc. Check out the posts of etotheipi, he'd just recently learned what the raw file storage does for the blockchain on a non- ECC RAM machine. There's going to be a lots of folks following them to the bit-flip-landia, unless they switch to Xeons and Opterons.

Who am I to tell them not to do that? They work for free and scratch their own itches. It isn't like they are answerable to the business development executives, aren't they?

Actually, the joke is on all those who use the bogus statistics to make a crucial architectural choice. The statistics promulgated by the core development team are a moral equivalent of: "we run a 'chkdsk /f' on a FAT and NTFS partitions. FAT was much faster, so lets use FAT for all our future storage needs. NTFS has so much unnecessary overhead."

This project has enough code cowbell already. What it needs is probably some new architecture. Thus far I think grau's bitsofproof is the best showcase of where Bitcoin can go with the "fast transactions folk".

e I have an idea: for outgoing transactions:
1) Have miners require that any transaction originating from known flood prefixes or addresses must pay at least 0.02 BTC, which
2) may not be deducted from the payout (e.g., for a winning bet).

Yet again you manage to write at lot of words without emitting anything sensible but concentrated insult. What mystical magical storage of the blockchain will make it immune to systems without ecc ram/cache/busses?  And why does anyone care?  The blockchain is some of the most robustly replicated data ever created, and append only is the gold standard for integrity short of adding storage bloating forward error correction (which would still be undermined by unreliable hardware).

For anyone who took an introductory course to database systems there isn't anything even mildly offensive or controversial. So you either never took any database courses or took one, flunked and now you are resentful.

In regards to the bit errors: the issue is error detection not error correction. It is a well known problem since around 2000, when the database systems started to be deployed on desktops and mobiles, no longer only on the server-class systems. This was also the time when the majority of the desktop systems no longer had even the parity error detection like the original IBM PC and clones. The silent, undetected corruption is such a widespread problem that most modern commercial database systems include in software page parity error detection and torn i/o detection (a closely-related problem with non-server class i/o subsystems).

Nowadays the situation is much worse: even the brands like Apple which formerly were beyond reproach now mass-ship the machines that reproducibly suffer bit-errors under load. Some modern game engines (yes, game engines, not database engines) include on-the-fly hardware error detection for CPU/RAM/GPU.

So the question still remains: which DB engine to choose? The answer is the same as for the old choice of cars: cheap, fast, reliable; pick two. I had a similar conversation in another thread and I managed to condense to a short soundbite that doesn't require computer science education and any MBA-type could understand it.
I recall from my school days the level of frustration we had with our professor who taught database systems. He always refused to straightforwardly answer the question about any concrete specific implementations. He would always talk about "dBaseXXVI", like the folks who don't like Sylvester Stallone talk about "Rocky 26". His test problems would involve tri-sex and quad-sex personal records to force the students to actually work on the problems and not just transcribe them from a textbook.

I cannot advise everyone to take an intriductory database course. But if you have just a couple of hours of time read this article from wikipedia:

http://en.wikipedia.org/wiki/View_(database)

If you take one thing from it: thanks to views the logical storage schema can be different than physical storage schema. With this klowledge you will be ahead anyone who hawks any single database choice.

The reality of Bitcoin could be summarized as follows:

1) nobody has any reliable data describing and modeling the access patterns for Bitcoin storage systems.
2) Bitcoin developers routinely work in a way that isn't representative of normal business operation: they constantly reload the blockchain from scratch. Any problem? Delete ~/.bitcoin/* or %AppData%/Roaming/Bitcoin and redownload everything.
3) people who try to run 24*7 Bitcoin services are at a serious disadvantage: they cannot do normal livedatabase backups; the filesystem snapshots they can make are not ACID and not internally consistent; database consistency cannot be checked while online.  More and more they find themselves in the situation where the troubleshooting resembles the old MS-DOS days: press Ctrl-Alt-Del, if that doesn't work, unplug the computer and plug it back.
4) even minimal storage schema tuning will show that storing blockchain in the raw on-the-wire format is far from efficient. There are three really disjoint data subsets in the raw blockchain:
4a) block headers chain or tree/trunk/orphan-branches
4b) merle trees, each used only once
4c) heap of transactions that could be extensively garbage-collected.
5) creating a separate database-loader tool for whatever blockchain representation you use is the most crucial task for the Bitcoin business operators.