Message to devs from merchant

[masterluc]

I used to post some constructive threads here, but was fucked off ))

I am a merchant. And bitcoind becomes really asspain. It is usable, but as time comes, it becomes not.

So devs, Bitcoin Foundation or whoever there... Please...

Do something with blockchain size

I mean size and performance of ~/.bitcoin folder. Decentralize, shrink or what we may do with it? We near to times when not every mortal will have ability to accept vanilla Bitcoin payments.

I don't need to hear about Bitpay, Coinbase, electrum or whatever 3rd party service. If I ever want to use middleman - I will sure use bank API.

Thank you!

[1714911830]

1714911830

[1714911830]

1714911830

[1714911830]

1714911830

[1714911830]

1714911830

[1714911830]

1714911830

[gmaxwell]

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.

[masterluc]

Problems:
- Enter to (pure) bitcoin game without super-duper hardware (initializing a client)
- Maintenance. ~/.bitcoind size is not limited in no way. There is no guarantee you run out of space/iops/cpu

I proposed some kind of decentralization of consumed resources. To move some load from disk/cpu into network (DHT).

[masterluc]

Sounds like you just need to buy more space on your server for bitcoind, but you should also clean out your wallet.dat, by backing it up *first* then delete it, allowing bitcoind to stop then start and create a fresh wallet.

Crunch. Some time after i will sure need to rent super node at AWS for that with this dynamic. This makes bitcoin unusable for mortals (in future)

[gmaxwell]

Crunch. Some time after i will sure need to rent super node at AWS for that with this dynamic. This makes bitcoin unusable for mortals (in future)

AWS nodes, especially smaller ones have horrific IO that is slower than a 4200 rpm laptop drive.  You may be better off looking for other options.

Reducing the blockchain storage will not change the ongoing IO load which you seem to be expressing problems with.  At least from what you're telling me here the size is actually not a problem for you. Am I misunderstanding?

[theonewhowaskazu]

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.

[gweedo]

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.

[masterluc]

AWS nodes, especially smaller ones have horrific IO that is slower than a 4200 rpm laptop drive.  You may be better off looking for other options.

Reducing the blockchain storage will not change the ongoing IO load which you seem to be expressing problems with.  At least from what you're telling me here the size is actually not a problem for you. Am I misunderstanding?

to electrum advices: I am merchant and need server software. However electrum servers will expirence same issue. AFAIK, they must store bitcoind's blockchain plus they store blockchain in database back end. So they expirence doubled issue.

I told about AWS just for example. gmaxwell, why don't try to distribute blockchain around all nodes, so nodes will have an option to store full chain or only its part? Just forget about my ask about transaction id lookup in prev topic.

I see it with bitcoind option - how much max full blocks to store locally. I sure if everyone will store even 10k blocks - it will be fine for chain integrity. If node needs to obtain a block not being local - it queries network. Of course block headers should be stored in full locally to not let network give a wrong answer.

[jl2012]

so nodes will have an option to store full chain or only its part?

So SPV client like MultiBit is what you need

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

[masterluc]

so nodes will have an option to store full chain or only its part?

So SPV client like MultiBit is what you need

Do you read me? SERVER SOFTWARE

[masterluc]

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

How much time did you spent on initializing?

How much time will you spend on restore corrupted DB?

How much time will you spend for sync if your bitcoind will go down?

[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

How much time did you spent on initializing?

How much time will you spend on restore corrupted DB?

How much time will you spend for sync if your bitcoind will go down?

Initializing: about 36 hours. But remember it's only a ARM board, like your cell phone. It could be much faster if I copy the blockchain files from another full node to the board

Restore: It has been running for 14 days without any problem and is still keeping up with the latest block.


and........... how about my SPV suggestion?

[jl2012]

so nodes will have an option to store full chain or only its part?

So SPV client like MultiBit is what you need

Do you read me? SERVER SOFTWARE

So that's for your online casino? SPV mode should be good enough. I think even SatoshiDice is running on SPV mode with BitcoinJ

[masterluc]

What is spv? No matter casino or online store - just merchant.

[jl2012]

What is spv? No matter casino or online store - just merchant.

https://en.bitcoin.it/wiki/Thin_Client_Security#Header-Only_Clients

What would you think you need a bitcoin "server". What functions do you actually need?

[masterluc]

Regular merchant functions:
- Create address
- Get notified about incoming TX
- Get TX info, number of confirmations
- Send coins
- Sendmany

[jl2012]

Regular merchant functions:
- 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

[theonewhowaskazu]

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.

[masterluc]

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.

[Mike Hearn]

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.