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.
Topic: Message to devs from merchant - page 2. (Read 5301 times)
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.
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.
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. 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.
Relevant: https://bitcointalk.org/index.php?topic=197810.5 (proposed solution from another nickname).
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).
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.
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?
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?
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
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
maybe some about news this?
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'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.
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's weaker in a few other ways too, but the above is the main one.
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)
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
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 ...
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 ...
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.
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.
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.
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.
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.
If you can't run bitcoind then yes, a bitcoinj based solution would work, although there isn't any program that's a drop-in compatible replacement that exports the same JSON-RPC API. It would be nice if there was.
But, you get weaker security. 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.
But, you get weaker security. 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.
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. You can't shrink the blockchain size. Its idiotic of the devs to force everybody to download the entire thing as part of Bitcoin QT, it makes it sound like if you're not downloading it all you're somehow using a 3rd party service to store your coins. No, you're not. 99.99% of people will never need the whole chain and there's no point to having it. Just use electrum; its not a 3rd party API, its a superior client.
*facepalm* someone needs to read why the bitcoin-qt client needs the entire blockchain. This allows it to be trustless, that means it relies on nothing and can validate transactions and blocks. Electrum uses a 3rd party server, which if you connect to a cancer server, then you can be fooled to think you have bitcoins you really may not.
Except only recent blocks matter for this to be a problem. Sure, you can be "tricked" into thinking that 1000 blocks ago you got a transaction, except nobody really cares as everybody's going to be looking at recent blocks for recent payments which is what 99.99% of people are checking for anyway.
And also, yea, as someone else on this thread has already said, BitcoinJ is much better for OP's purposes than electrum. But both of them share the same advantage of not needing the whole blockchain.
Regular merchant functions:
- Create address
- Get notified about incoming TX
- Get TX info, number of confirmations
- Send coins
- Sendmany
- Create address
- Get notified about incoming TX
- Get TX info, number of confirmations
- Send coins
- Sendmany
BitcoinJ should do everything you need, keeping only the relevant part of blockchain: https://code.google.com/p/bitcoinj/
edit: we have a whole BitcoinJ forum at https://bitcointalk.org/index.php?board=138.0
Jump to: