4 ms·

You can read up on it all over. But the short answer is Bitcoin Cash forked Bitcoin and has 8MB blocks, which would have eliminated congestion and lowered fees

You can read up on it all over. But the short answer is Bitcoin Cash forked Bitcoin and has 8MB blocks, which would have eliminated congestion and lowered fees on Bitcoin during the past year. Both sides (small Vs big) have economic incentives behind them, making the argument extra vitriolic. But larger blocks allow on chain growth, keeping it peer to peer without requiring any 3rd parties. (And the answer that 8x more bandwidth and storage makes it infeasible for enough people to run nodes rings false.)

yebyen 9y ago
It doesn't make anything infeasible today. But if you think both Bitcoin and Bitcoin Cash are going to be around in 20 years, and you want to support both, now you've just added 800% to your annual storage growth rate. (Assuming that BCC always mines full blocks, which I will admit seems unlikely) I have to be honest, I was keeping a cold wallet with some ~1-2 BTC in it until the price reached record high territory in the last few months, and it took me several days to download the entire blockchain against my wallet.dat. I had to free up well over 100GB to get the coins out. If I hadn't done this dozens of times already (when the blockchain was smaller) and had some degree of confidence that it was going to succeed and grant me access to the coins, I probably would have been freaking out as I reached about the 36 hour mark into the process. I can't imagine it's going to get better in the next couple of years. Maybe "Moore's law for storage" will outpace economic growth in the Cryptocurrency sector, and in 20 years my mobile phone will be so powerful that it will no longer be a concern. That sounds like a bit of a gamble, doesn't it?
- PretzelPirate 9y ago
  Syncing the blockchain is optional, unless you store your coins in a wallet generated by a full node. Even then, things such as UTXO commitments would make syncing the current state almost instantaneous, though it would either requiring pulling the commitment from multiple third parties or having the protocol updated to require a UTXO commitment every Nth block.
  - yebyen 9y ago
    I thought the protocol required you to have the keys in hand while scanning the block chain, in order to be sure that all addresses that were generated with your keys can be recovered. I don't know how I reconcile that with clients like electrum, is that using an implementation of UTXO? Does this just keep a record of any unspent transaction outputs at any given time, scan them, and try your keys on all of them? I think you can do a similar trick with bitcoin core if you have all of the blocks, but you have a new wallet.dat. You can delete the index and it will regenerate it with the new wallet in mind, recovering all of your unspent transactions. (You do not need to literally download all of the blocks again, unless you actually don't have them anymore. It is sufficient to rescan them. But this takes time too, and it does require that you must store a copy of the chain somewhere on an ongoing basis.)
- MichaelGG 9y ago
  What was your goal in downloading the entire chain versus using a light client? Or why didn't you just download the last few blocks plus UTXOs? Either way you need a trust anchor, so starting from something recent makes sense if you don't want to wait days to verify the entire chain. And if you need to view specific blocks or transactions, use an online viewer or download that specific block and check the hash of the block. 10 years of 10 minute blocks is only 16MB of hashes (32 bytes per block). So it's trivial to get all block hashes and then freely use other sources to check specific parts. Storage is cheap. 2TB drives are a bit over $50.
  - yebyen 9y ago
    I had a wallet.dat from a regular Core client, full node. I wasn't able to find a client that seemed to be able to import that wallet.dat. If you know a way to handle that, great! I don't know if I'd trust some arbitrary client to still be around and maintained when I need to retrieve my funds from the latest version of the block chain. I'm marginally afraid of what will happen if the person maintaining Electrum died, or disappeared, and protocol changes made a need for some mandatory code updates. Because the appearance to me is that private keys may be technically portable, but wallets are basically not transferrable between different clients. I have a 14TB array that I bought with those Bitcoin I cashed in. It was cheap. But the next time I want to sync the whole chain, I'm really sure I'm gonna have to use it... Thanks for your comments though, I will look up UTXO as it's another one I have not heard of before!
    - MichaelGG 9y ago
      https://en.bitcoin.it/wiki/Transferring_coins_from_Bitcoin-Qt_to_Electrum https://en.bitcoin.it/wiki/Transferring_coins_from_Bitcoin-Q...
      - yebyen 9y ago
        Yep. > Before reading this page, users should note that directly manipulating ECDSA private keys is dangerous and can result in losing bitcoins[1][2]. Hmm. > Use the dumpprivkey command to get the private key. Repeat for as many bitcoin addresses as have money in them. OK, so how many bitcoin addresses do I have with money in them? examining 3.5 year old wallet.dat, checking Oh, THAT Many? And are you sure that is all of them? (It was quite a lot of addresses, and not sure how I would know if the listing was complete.) So, is there some way to safely automate this? Try it... the command outputs are all in JSON (configurable?), so you most likely won't be solving this with just pipes, awk, and grep. I tried exporting a few private keys this way and they are not exaggerating when they say: > This guide is [not] for the impatient or time-stressed, it is recommended that users of Bitcoin Core simply wait out the blockchain synchronization. There are many benefits to running a Full node including trustlessness, security and privacy which lightweight wallets cannot match. I have to use Bitcoin-Qt to get the keys out, and it does not appear to be fool-proof at all. Might as well just sync the whole blockchain then.
gruez 9y ago
8 MB blocks = 1.15GB per day, or 420GB per year. Sure it might be feasible to run a node if you're in a first world country with fast internet and cheap storage (cost of living wise), but even in rural america, 34.5GB is a significant chunk of bandwidth. Not to mention they eventually plan to raise it to 32MB, which works out to 4.6GB a day or 1.63TB/year.
- smokeyj 9y ago
  As if people in the third world have money for transaction fees, opening and closing lightning channels, and of course locking up funds to use the channel. The idea that bitcoin can exist only as a settlement layer is a dream. It was pitched as something you can buy a cup of coffee with. Now the core team wants to call that a "spam transaction". Yeah right. Time to fire Core.
  - gruez 9y ago
    >Time to fire Core it's open source, there's no one to "fire". if you're not happy with it, fork it like bitcoin cash did.
- JustinAiken 9y ago
  You don't need to run a full node to send/receive Bitcoin/BCC though.
  - gruez 9y ago
    see my reply to MichaelGG.
    - SAI_Peregrinus 9y ago
      The second line of that reply is incomplete, FYI.
- e12e 9y ago
  1 gb ~ 2 hours 15 minutes of 1 mbps. 1 tb ~ 3 "mbps months". You need ~ 100mbit to do 1 tb in 24h. (These number are probably underestimating protocol overhead a bit).

yebyen 9y ago

It doesn't make anything infeasible today. But if you think both Bitcoin and Bitcoin Cash are going to be around in 20 years, and you want to support both, now you've just added 800% to your annual storage growth rate. (Assuming that BCC always mines full blocks, which I will admit seems unlikely) I have to be honest, I was keeping a cold wallet with some ~1-2 BTC in it until the price reached record high territory in the last few months, and it took me several days to download the entire blockchain against my wallet.dat. I had to free up well over 100GB to get the coins out. If I hadn't done this dozens of times already (when the blockchain was smaller) and had some degree of confidence that it was going to succeed and grant me access to the coins, I probably would have been freaking out as I reached about the 36 hour mark into the process. I can't imagine it's going to get better in the next couple of years. Maybe "Moore's law for storage" will outpace economic growth in the Cryptocurrency sector, and in 20 years my mobile phone will be so powerful that it will no longer be a concern. That sounds like a bit of a gamble, doesn't it?

PretzelPirate 9y ago
Syncing the blockchain is optional, unless you store your coins in a wallet generated by a full node. Even then, things such as UTXO commitments would make syncing the current state almost instantaneous, though it would either requiring pulling the commitment from multiple third parties or having the protocol updated to require a UTXO commitment every Nth block.
- yebyen 9y ago
  I thought the protocol required you to have the keys in hand while scanning the block chain, in order to be sure that all addresses that were generated with your keys can be recovered. I don't know how I reconcile that with clients like electrum, is that using an implementation of UTXO? Does this just keep a record of any unspent transaction outputs at any given time, scan them, and try your keys on all of them? I think you can do a similar trick with bitcoin core if you have all of the blocks, but you have a new wallet.dat. You can delete the index and it will regenerate it with the new wallet in mind, recovering all of your unspent transactions. (You do not need to literally download all of the blocks again, unless you actually don't have them anymore. It is sufficient to rescan them. But this takes time too, and it does require that you must store a copy of the chain somewhere on an ongoing basis.)
MichaelGG 9y ago
What was your goal in downloading the entire chain versus using a light client? Or why didn't you just download the last few blocks plus UTXOs? Either way you need a trust anchor, so starting from something recent makes sense if you don't want to wait days to verify the entire chain. And if you need to view specific blocks or transactions, use an online viewer or download that specific block and check the hash of the block. 10 years of 10 minute blocks is only 16MB of hashes (32 bytes per block). So it's trivial to get all block hashes and then freely use other sources to check specific parts. Storage is cheap. 2TB drives are a bit over $50.
- yebyen 9y ago
  I had a wallet.dat from a regular Core client, full node. I wasn't able to find a client that seemed to be able to import that wallet.dat. If you know a way to handle that, great! I don't know if I'd trust some arbitrary client to still be around and maintained when I need to retrieve my funds from the latest version of the block chain. I'm marginally afraid of what will happen if the person maintaining Electrum died, or disappeared, and protocol changes made a need for some mandatory code updates. Because the appearance to me is that private keys may be technically portable, but wallets are basically not transferrable between different clients. I have a 14TB array that I bought with those Bitcoin I cashed in. It was cheap. But the next time I want to sync the whole chain, I'm really sure I'm gonna have to use it... Thanks for your comments though, I will look up UTXO as it's another one I have not heard of before!
  - MichaelGG 9y ago
    https://en.bitcoin.it/wiki/Transferring_coins_from_Bitcoin-Qt_to_Electrum https://en.bitcoin.it/wiki/Transferring_coins_from_Bitcoin-Q...
    - yebyen 9y ago
      Yep. > Before reading this page, users should note that directly manipulating ECDSA private keys is dangerous and can result in losing bitcoins[1][2]. Hmm. > Use the dumpprivkey command to get the private key. Repeat for as many bitcoin addresses as have money in them. OK, so how many bitcoin addresses do I have with money in them? examining 3.5 year old wallet.dat, checking Oh, THAT Many? And are you sure that is all of them? (It was quite a lot of addresses, and not sure how I would know if the listing was complete.) So, is there some way to safely automate this? Try it... the command outputs are all in JSON (configurable?), so you most likely won't be solving this with just pipes, awk, and grep. I tried exporting a few private keys this way and they are not exaggerating when they say: > This guide is [not] for the impatient or time-stressed, it is recommended that users of Bitcoin Core simply wait out the blockchain synchronization. There are many benefits to running a Full node including trustlessness, security and privacy which lightweight wallets cannot match. I have to use Bitcoin-Qt to get the keys out, and it does not appear to be fool-proof at all. Might as well just sync the whole blockchain then.

gruez 9y ago

8 MB blocks = 1.15GB per day, or 420GB per year. Sure it might be feasible to run a node if you're in a first world country with fast internet and cheap storage (cost of living wise), but even in rural america, 34.5GB is a significant chunk of bandwidth. Not to mention they eventually plan to raise it to 32MB, which works out to 4.6GB a day or 1.63TB/year.

smokeyj 9y ago
As if people in the third world have money for transaction fees, opening and closing lightning channels, and of course locking up funds to use the channel. The idea that bitcoin can exist only as a settlement layer is a dream. It was pitched as something you can buy a cup of coffee with. Now the core team wants to call that a "spam transaction". Yeah right. Time to fire Core.
- gruez 9y ago
  >Time to fire Core it's open source, there's no one to "fire". if you're not happy with it, fork it like bitcoin cash did.
JustinAiken 9y ago
You don't need to run a full node to send/receive Bitcoin/BCC though.
- gruez 9y ago
  see my reply to MichaelGG.
  - SAI_Peregrinus 9y ago
    The second line of that reply is incomplete, FYI.
e12e 9y ago
1 gb ~ 2 hours 15 minutes of 1 mbps. 1 tb ~ 3 "mbps months". You need ~ 100mbit to do 1 tb in 24h. (These number are probably underestimating protocol overhead a bit).