Message to devs from merchant

[masterluc]

I am very skeptical that masterluc has a real problem here. He seems to be worried about hypothetical future problems he didn't actually encounter yet. I wouldn't encourage merchants to use SPV over bitcoind, it's always better to do the latter if you can afford it, and right now it's just not that expensive.

Yes, current problems are solvable. Yes I am worry about Bitcoin future. I am in business since 2011 and I see progress of problems. I see future where killer feature "no middleman" is not usable.

[Sukrim]

It really depends on which features you need - if you need "Get TX info, number of confirmations" only for recent blocks or would be OK with waiting a bit until your client has fetched the respective data via bloom filters, you just need to prune the block chain to operate on a set that is maybe a few 100 MB large instead of 20 GB+...

The solutions the OP suggests are actually not really usable without trust but he is free to sponsor implementation of a DHT block storage if he thinks that's what is going to solve bitcoind's storage problems.

All his requirements can be fulfilled by bitcoinj today and it requires only to ensure you are not under a sybil attack, which might be a bit harder to detect than on a bitcoin-qt node.

[FlappySocks]

I thought there was already work going on to solve the blockchain size problem?

If its not a problem now, it sure will be if Bitcoin overtook Paypal & the credit card companies.  Just imagine every financial traction in the world being logged on my PC in real time forever.

[Mike Hearn]

If the issue is disk space, pruning (when implemented) will solve that problem for nodes that don't wish to support the network with archives.

If the issue is IOPs then it's unlikely we will see significant improvements, however, because of how LevelDB works you're not likely to see significant worsening either, even with large increases in traffic.

At the moment it doesn't seem like there's actually any problem. All good things come with time ...

[jl2012]

BTW, I am running a full bitcoind on a 80USD ARM baord: http://cubieboard.org/ without any problem. So are we facing a big problem? I would say not yet

Besides, this mini-PC uses flash disk right? The max flash card size is 32GB right? If so, you will not be able to run bitcoind there soon because out of disk space.

It supports SATA and USB hard drive so this is not a concern at all

[jl2012]

But, you get weaker security.

How much weaker (with SPV)? I think this is only weaker in academic sense, especially for low value transactions (relative to block reward)

[Mike Hearn]

It's weaker in the sense that it increases the possibility miners might try and change the rules of the system, like by changing the inflation schedule. We need as many people with economic heft (especially merchants) to validate all the rules, to make them harder to change.

It's weaker in a few other ways too, but the above is the main one.

[jl2012]

It's weaker in the sense that it increases the possibility miners might try and change the rules of the system, like by changing the inflation schedule. We need as many people with economic heft (especially merchants) to validate all the rules, to make them harder to change.

It's weaker in a few other ways too, but the above is the main one.

It is trivial for a merchant to run several copies of bitcoind at different locations with cheap internet connection and storage (e.g. at home), and force his bitcoinj (on a server with very limited bandwidth and storage) to connect to the trusted bitcoind.

By the way, the one you mentioned is well known (but I think it's mostly an academic issue as many non-miner, such as early adopter, would have enough incentive to run a full node.) I would like to learn what are the other ways.

[inform]

maybe some about news this?

[Mike Hearn]

A miner could mine a block that contains garbage transactions (like, transactions that spend non-existent money). If it was presented to an SPV client, that client would accept the nonsense tx as legitimate because it appeared in a block on the best chain. Of course, if you didn't keep up the attack, it would quickly re-org back onto the main chain (assuming it's visible) and the bogus tx would go pending forever. But if you're purchase already cleared, by then it may be too late.

Currently the cost of mining an invalid block and losing the reward is so high that you'd need to find a merchant selling something extremely valuable almost immediately, like an exchange, and I don't think any exchange would be stupid enough to not use full nodes. So this attack is somewhat theoretical. It's certainly possible though.

For more info, see here:

https://code.google.com/p/bitcoinj/wiki/SecurityModel

[riplin]

Hey Mike, quick question.

Other than the block reward not being validated, does bitcoinj also not validate if the block difficulty is correct in relation to the previous block? When reading the code, I kind of got that impression.

In other words, would it be possible to fool bitcoinj by sending it a difficulty 1 block?

[Mike Hearn]

It does check the difficulty, so you cannot just mine a diff-1 block. Please review the SecurityModel doc to learn exactly what it does or does not do.

[riplin]

Ah sorry, after digging around a bit more I see this check is done in AbstractBlockChain.java. I was initially looking at Block.java (where most of the other checks are done).

[masterluc]

Can you explain better what limitations you're facing. In other words, "Please explain the problem you're having / trying to solve, and not what you think the solution is".

The current blockchain size is a fraction of a modern commercial _game_ and it stores the whole bitcoin economy. Better understanding the nature and origins of your limitations you're facing avoids thinking we have a solution for you which isn't a solution.

Please also be sure to explain what you expect to do with a node. For example, if you need to be able to add new keys at will and go find their transactions ... there is no way thats going to happen with reduced storage.

Returning after 1 year. How's chain size going? Probably,  exponential.

Relevant: https://bitcointalk.org/index.php?topic=197810.5 (proposed solution from another nickname).

[deepceleron]

Even with fast SSDs in RAID1 to store it on, the blockchain costs less than $1 per month in storage media. That is a miniscule cost compared to the Internet connection or dedicated phone line that any business running customer bank transactions would use, or the cost of leasing a credit card terminal from a merchant services provider. One credit card chargeback avoided by using Bitcoin can pay for decades of blockchain storage.

A merchant using Bitcoin for point-of-sale will not have a copy of the blockchain at every cash register. The point-of-sale terminal only needs to show a pay-to Bitcoin address, and a message to the cashier that the payment has been accepted. Everything else will be done in the server room of corporate headquarters or at an outsourced payment processing company.

[masterluc]

I don't mind about merchant anymore. I do mind about Bitcoin itself. I remember times when everyone was able to launch full node, even on raspberry. That was ONLY 1-2 years ago! How about 10 years prediction?

Now I see more and more posts where launching full node is kinda unbelievable heroic doing.

Ppl said earlier like you - not a problem. No, it's a problem!  Look at chain size growth in time - it's parabolic! Will we loose full chain eventually? Because nobody cares.

[Newar]

I don't mind about merchant anymore. I do mind about Bitcoin itself. I remember times when everyone was able to launch full node, even on raspberry. That was ONLY 1-2 years ago! How about 10 years prediction?

Now I see more and more posts where launching full node is kinda unbelievable heroic doing.

Ppl said earlier like you - not a problem. No, it's a problem!  Look at chain size growth in time - it's parabolic! Will we loose full chain eventually? Because nobody cares.

I still run a full node on a RPi, external hard drives are cheap. I expect they will get cheaper per GB/year in the future. I bought a 3 TB the other day for 130.- USD.

[cr1776]

I don't mind about merchant anymore. I do mind about Bitcoin itself. I remember times when everyone was able to launch full node, even on raspberry. That was ONLY 1-2 years ago! How about 10 years prediction?

Now I see more and more posts where launching full node is kinda unbelievable heroic doing.

Ppl said earlier like you - not a problem. No, it's a problem!  Look at chain size growth in time - it's parabolic! Will we loose full chain eventually? Because nobody cares.

I still run a full node on a RPi, external hard drives are cheap. I expect they will get cheaper per GB/year in the future. I bought a 3 TB the other day for 130.- USD.

And then there are the 8TB and 10TB drives from WD (and others).   http://arstechnica.com/information-technology/2014/09/western-digital-readies-first-10tb-hard-drive-ships-new-8tb-drive/

6TB is about $250 and about 270 times the current block chain.  Even growing at 20 GB/year, that is a long time before it is full.  Even IF it grew at 100GB/year (~10 times last year) that is still many, many years to fill it.  And then there are the 8TB and 10TB drives and that is just what is available now.

[hhanh00]

You guys say that hard drives are cheap but you still have to scan the block chain at first. It takes a very long time to do but is the only trust less solution, isn't it?

As a merchant, the only way I see things going is to keep the block chain whatever its size becomes, and sync.

It would be good if there was a way to drop the used transactions from the requirement. Last time I checked, there was 27 gb of block data but less than 1 gb worth of active tx.

[JohnDorien]

You could use bitcore as far as I understand it - let's you execute all commands on the chain without the need to download the chain.
Open source and fairly easy to use, shall meet your requirement.