Your bets for 2014

[grondilu]

I know a future market where people put money where their mouth is would be a better indicator, but for those who would like to speculate without actually risking to lose anything: here you go, you can bet about the exchange rate for next year here!

[myself]

between 1 and 10 $/BTC    

[smoothie]

I say between $20 and $100 by end of 2014. That doesn't mean the price can't go down from here though.

[knight22]

My guess is around 25$

[Chalkbot]

I think Bitcoin will be stable and in the low $17.xx range by the end of 2013.

[lucif]

I think Bitcoin database size will make it totally unusable on regular hardware. GPU miners will quit biz and sell their stuff.
Bitpay will continue to get ppl Bitcoin reserves and sell them on market.

All this will bring single digits or less Bitcoin price.

[zoinky]

I think Bitcoin database size will make it totally unusable on regular hardware. GPU miners will quit biz and sell their stuff.
Bitpay will continue to get ppl Bitcoin reserves and sell them on market.

All this will bring single digits or less Bitcoin price.

But the database still fits on a thumb drive?   

[lucif]

But causes total hang of system IO scheduler on open, close, sync.

You ppl do not have brains? When DB will reach size of RAM of common computer - customers will better shut themselves rather than use vanilla client.

[notme]

But causes total hang of system IO scheduler on open, close, sync.

You ppl do not have brains? When DB will reach size of RAM of common computer - customers will better shut themselves rather than use vanilla client.

Have you tried the 0.8 prerelease?  It reduces the working set (the part needed in memory) to around 150 MB with the current blockchain.  It synced on my machine in under four hours without even keeping one core busy and mostly idle disk (it was network bound, which is the next area targeted for speed up).  Someone ran it on an old pentium 4 machine and it synced in under 6 hours (easily done overnight).

In other words, I know you love Satan, but there are enough truths to strike fear in people's hearts.  You don't need to make up lies.

[lucif]

There is no matter, how much data it loads to memory.

They key is index size, which is growing. Another key is number of broadcasted new transactions per time, which require database lookup to verify them.

As index size will run out of ~double avg RAM size of common computer - clients will start goxxxxxing on each incoming unspent trans. Because any disk caching mechanism will not be effective with such data and RAM sizes.

So every client on every incoming unspent trans will perform uncached disk lookup through gigabytes of data.


Hehe.

[lucif]

I mean no software optimizations will be effective on such conditions.

Gavin will have to publish minimum hardware req to run client. And those req will include good amount of RAM and good ssd disk.

[grondilu]

They key is index size, which is growing. Another key is number of broadcasted new transactions per time, which require database lookup to verify them.

As index size will run out of ~double avg RAM size of common computer - clients will start goxxxxxing on each incoming unspent trans. Because any disk caching mechanism will not be effective with such data and RAM sizes.

So every client on every incoming unspent trans will perform uncached disk lookup through gigabytes of data.

Hehe.

I'm no expert in databases but it seems to me you don't know what you're talking about.  Can someone confirm or infirm?

[lucif]

I'm some kind of expert on high load servers maintenance. Including high load databases. I see future bottlenecks when they don't even exists. Project owners pay me good money for my skills.

[lucif]

Growing unspent transactions number mean growing key lookup load on database.

And when index size do not fit in RAM - software will perform key lookup reading whole index from HDD (gigabytes of data on single lookup).

It is obvious that such conditions will require good SCSI or SSD backing array.

[chmod755]

above 100$/BTC    - 17 (15.9%)
between 20 and 100 $/BTC    - 67 (62.6%)

Nice bets for 2014 - you guys should buy those cheap coins now, right?

[lucif]

I'm not big expert in Berkeley DB, but it is obvious that one index record takes about 300 bytes in space. It's a sha256 hash + some index data. Remind me true number if you please.

So... To get index size greater than 4G we need only 13m transactions in whole chain. This is nothing for widely used payment system. For Bitcoin it is a 180 days of blocks containing 500 transactions each.

So Bitcoin is about to grow? Hehe.

[grondilu]

I'm not big expert in Berkeley DB, but it is obvious that one index record takes about 300 bytes in space. It's a sha256 hash + some index data. Remind me true number if you please.

So... To get index size greater than 4G we need only 13m transactions in whole chain. This is nothing for widely used payment system. For Bitcoin it is a 180 days of blocks containing 500 transactions each.

So Bitcoin is about to grow? Hehe.

You know that spent transactions can be ignored, don't you?

[pent]

You know that spent transactions can be burried, don't you?

With the cost of security, don't you know?

If client receive bcast block/transaction from network it must check its prev outputs in full block chain to know whether its a valid transaction for futher broadcast.

If client burn old transaction - it will not be able to check new transactions for validity.

If it broadcast not valid transaction - it will be banned by vanilla clients.

So burning old block bodies makes client vulnerable to Sybill and DoS attacks, coz he unable to check what is true and what is false comming from network.

[grondilu]

You know that spent transactions can be burried, don't you?

With the cost of security, don't you know?

If client receive bcast block/transaction from network it must check its prev outputs in full block chain to know whether its a valid transaction for futher broadcast.

If client burn old transaction - it will not be able to check new transactions for validity.

If it broadcast not valid transaction - it will be banned by vanilla clients.

So burning old block bodies makes client vulnerable to Sybill and DoS attacks.

There is no security flaw in this.  New transactions are not supposed to try to spend an already spent transaction.  So it makes sense to remove spent transactions (only once buried under a few blocks though) from the index.  They will still be in the database, but accessing to them will take more time.

Though I'm no database expert, I'm pretty sure an index does not have to be exhaustive.

[pent]

Allright. The client with DB consisting only with block headers receives the transaction. What next he must do with it?

Store? No. It must be sure transaction is valid to store it, but he can not check its validity as he dont have full chain.
Broadcast? No. Same reason. If trx isnt valid, he will be banned as DoS source by vanilla clients.

If network will consist of huge part of such light clients - it will be paralyzed.