Topic: Finney Attack against SatoshiDice or how to get 250 BTC per solved block. (Read 6147 times)

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.

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

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

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

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.

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

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

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.

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

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.

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

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.

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

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-

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

Prunable, spendable transactions, sure.

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

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.

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.

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 

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