Bitcoin Forum
August 20, 2018, 12:59:06 PM *
News: Latest stable version of Bitcoin Core: 0.16.2  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 [4]  All
  Print  
Author Topic: Finney Attack against SatoshiDice or how to get 250 BTC per solved block.  (Read 5830 times)
2112
Legendary
*
Offline Offline

Activity: 2114
Merit: 1027



View Profile
February 27, 2013, 10:13:15 PM
 #61

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

Quote
The conservator applies some simple ethical guidelines, such as:
* Minimal intervention.

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.

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
mistfpga
Member
**
Offline Offline

Activity: 86
Merit: 13


View Profile
February 27, 2013, 10:22:44 PM
 #62

The coins are already half-way minted. Now the business question is:

a) do you want them tarnished (not necessarily with shit Wink ) 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.

is it one or the other? Smiley 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... Wink )

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
2112
Legendary
*
Offline Offline

Activity: 2114
Merit: 1027



View Profile
February 27, 2013, 10:37:36 PM
 #63

What bitcoin really needs is people to layer services upon it, rather than embed them into it.
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".

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2478
Merit: 1383



View Profile
February 27, 2013, 11:23:39 PM
 #64

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

Bitcoin will not be compromised
2112
Legendary
*
Offline Offline

Activity: 2114
Merit: 1027



View Profile
February 28, 2013, 12:42:30 AM
 #65

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

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

Show us the code.
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".

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
bootmii
Member
**
Offline Offline

Activity: 64
Merit: 10


Bitcoin Fanatic


View Profile
February 28, 2013, 01:10:19 AM
 #66

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

gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2478
Merit: 1383



View Profile
February 28, 2013, 03:59:57 AM
 #67

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

Bitcoin will not be compromised
2112
Legendary
*
Offline Offline

Activity: 2114
Merit: 1027



View Profile
March 08, 2013, 07:57:32 PM
 #68

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.
etotheipi:  Hey, I've choosen Intel GMA for Armory display engine. Any comments?
2112: Dude, prototype first, then make a choice.
etotheipi: Die in a fire! AMD, NVidia, Intel or GTFO?
2112: No really, there are abstraction layers that will allow you to make that selection last, once you exactly know and can measure your needs.
etotheipi: OK, I hear ya. Qt looks like a decent layer that will isolate me from the vagaries of graphic display market. It looks like pain it the neck, but I need to learn some way of not painting myself into the corner.
2112: Hurray!
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.

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
Pages: « 1 2 3 [4]  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!