The FUD..?

Mind if I ask what in the world that is?

Im still asking myself why I clicked on this thead..

The star trek one has always had me laughin, a classic.

Ahahahah I love it!

No ones going to buy this, not only is it illegal to ship gun parts its stupid when you can go to a gunstore and buy a clip for much cheaper.

Lol we can only hope

Not a prediction its a fact, give it 1-2 years and people buying and selling a whole bitcoin will be very rare.

Isreal is kind of the finance capital of the world, Its no surprise its taking off there as much as it has.

Thanks great watch, very informative.

Wow pretty awesome stuff!!

Encryption 4 lyfe 

Wow surprised to see this turn around in Mathew, your doing the right thing. But like others said, that move still makes you an ass, for eternity..

this

Hi

The annoying huge real time to build up the blkindex.dat with the bitcoin-client is the trigger why I finally wrote this posting.
Sadly nowhere is explained neither which exact structure blkindex.dat has, nor
why we need this Berkley-DB-B-tree structure at all and it is extremly slow in
rebuild/updating in our case of bitcoin client.
Indeed I needed more than 23 h to build it from scratch with my 2 GHz Athlon-64 and 4 GB Ram. :-( and almost always the real time is spent by wait-for IO, not
CPU or network-band with limited if you want to catch up to the current blockchain.
Looking at the new bitcoin-client 0.7.99 test-release it looks still similar
slow, see benchmarks at [https://bitcointalk.org/index.php?topic=129861.0].
Thus I totaly agree in "We need to stabilize 0.8 as quickly as is reasonably possible, because people are beginning to avoid 0.7.x due to slowness, choosing instead less secure but faster bitcoin clients." stated by jgarzik in this thread.

I wonder why we need all this overhead-full and version-depending DB-stuff for
using/manipulating the blockchain in the bitcoin client. :-/

Here is an alternative for "blkindex.dat":

Hold the blockchain-indexing data always in memory and organize, it as follows:
Let there be TA-many transactions and DEP-many deposits (response-scripts/out-channels) in all the (valid) blocks in the blockchain.

On 2012-12-27 11:45 UTC we had #blocks= 213849, #TA =  10388275, #DEP = 24173524

The needed data structure consists of 2 tables and 1 heap:

1) A hashtable: we have TA many transactions and this number is steadily growing.
It is not decisive but I choose a hashtable which can store up to 2^26 many
 entries (so current fill-factor is < 1/6). Each transaction gets a 4 byte index, e.g.
made up of the lowest 4 bytes of a transaction-hash (or made by xoring the 32 bytes into 4
bytes) anded with 2^26-1 , ==> this is a 2^28 byte sized table, which each entry is either 0 or
indexs a further table, called transaction table for simplicity.

2) The transaction table has #TA*(32+2+8) bytes = #TA*42 bytes.
   Each entry of this transaction table holds ITS 256 bit doubled SHA-hashed hash = 32 bytes (back-check to the hashtable for index-collision-detection), a 2 byte counter (could be also 4 byte) for number of deposits and an 8-byte pointer into a heap for a specific transaction of a block of the blockchain.

3) the heap of deposit addresses and deposit values has size #DEP*(2*8+8) bytes
   Here the explicit value in Satoshis, the address of the script, and the
   address of the redeemed script is stored (null address if the deposit is
  still availible).
  The value of the deposits are pure luxury and could be saved. This value could
  also be goten from the address of the script decreased by 8. But I liked to
  store this value explicitly (in 8 bytes) and not looked it up each time in the
  blockchain.

The size of these 3 structures sum up to about 1285 Mbytes compared to 1481 Mbytes of the current blkindex.dat. The heap and the transaction table grows simply
by appending new data if new blocks are mined and published.
Searching for a transaction given by its 256-bit hashindex happens in constant time (depends only on the fill-factor of the hashtable) -- in contrast any B-tree needs log_2(#TA). Adding a new transaction with its deposits is of course proportional to the number of deposits involved.

Thus the real time needed to access a deposit is constant. There are the rare
events when we want to delete a orphan block and thus removing transactions with their deposits from our data structure. In this case, the needed real time is
at most proportional to the age of the orphan block respectively number of blocks in the part of the forked chain measured in number of deposits containing in the end part of the forked chain.
The average real-time behavior should be at least as fast as the old
"blkindex.dat"-logic, but probably much faster because we need no log_2-searching factor from the B-trees involved.

I implemented this logic/data structure already as part of a blockchain parser
and a total build up of this new "block-index structure" needed 242 sec real
time and 71 sec CPU-time - most time was spend in reading the blockchain from
disc. BTW: I did not optimize the source-code, already the 2nd program version
needs only these 4 minutes. I recall: Compared to more than 23 hours real time of the
bitcoin-client 0.7.1 needed to rebuild the blkindex.dat via "-loadblock" options. :-(

So the only draw back I currently see is a need of 1.28 GB Ram compared to at most 1/5-th (or less?) Ram in the bitcoin-client + 1.5 GB of blkindex.dat disc-space.
Omitting the Satoshi value of each deposit in the data structure and using only
a 2^25 sized hashtable (currently means a factor of 3.23 of total to used entries)
would result in 0.96 (0.13+0.44+0.39) GB Ram. Of course this data structure could be stored also on disk to avoid rebuilding each time the client starts.

The win is a real-time factor decrease of 350 -- and in absolute units from
many, many hours to a few minutes when building up the index data from scratch
in a bitcoin-client or whatever.  :-)

I like to hear your thoughts/critics.

BTW: If this is not too much nonsense perhaps a member could make a pointer to this posting in the thread/topic "Experimental pre-0.8 builds for testing" in the "Development & Technical Discussion"-board which is forbidden for newbies like me.

Thanks,
smtp

how are we going to help you get it back..?

Interesting, guess its kind of a good thing who knows how much 1 bitcoin may be worth in 5-10 years.

God this is stupid I hate governments/companies who dont allow bitcoins.

+1

I've heard bad things about Bitinstant lately, I suggest you stay away for now. People claim they are selective scamming.