TPS, Blockchain bloat and Confirmation speed - Are they a problem?

[stuartcharles]

The three main arguments against bitcoin which seem to hold ground are TPS (transactions per second) are not quick enough, the block chain will get too big (I'm not so worried about this as moore's law and lite wallets will sort it out). Lastly confirmation speeds.

Can any one point me to the current solutions for these problems that does not require a hard fork?

[stuartcharles]

The three main arguments against bitcoin which seem to hold ground are TPS (transactions per second) are not quick enough, the block chain will get too big (I'm not so worried about this as moore's law and lite wallets will sort it out). Lastly confirmation speeds.

Can any one point me to the current solutions for these problems that does not require a hard fork?

Anyone?

[oakpacific]

The problem is that it is not a problem yet.

While we all hope to see Bitcoin becomes a busy and bustling network like VISA or Paypal, the reality is that we are still quite some way from the current hardlimit 7 tps, the transaction rate now stands at about 1 tps https://blockchain.info/charts/n-transactions, nobody is feeling the urge to increase the blocksize so there is no way to field test it, not yet.

[stuartcharles]

The problem is that it is not a problem yet.

While we all hope to see Bitcoin becomes a busy and bustling network like VISA or Paypal, the reality is that we are still quite some way from the current hardlimit 7 tps, the transaction rate now stands at about 1 tps https://blockchain.info/charts/n-transactions, nobody is feeling the urge to increase the blocksize so there is no way to field test it, not yet.

So does that mean that if you increase the blocksize you will get over 7 tps?

[oakpacific]

The problem is that it is not a problem yet.

While we all hope to see Bitcoin becomes a busy and bustling network like VISA or Paypal, the reality is that we are still quite some way from the current hardlimit 7 tps, the transaction rate now stands at about 1 tps https://blockchain.info/charts/n-transactions, nobody is feeling the urge to increase the blocksize so there is no way to field test it, not yet.

So does that mean that if you increase the blocksize you will get over 7 tps?

Principally yes but all transactions still get confirmed only when a new block is released, so I'm not sure if it's a good idea to use "tps" here.

[stuartcharles]

The problem is that it is not a problem yet.

While we all hope to see Bitcoin becomes a busy and bustling network like VISA or Paypal, the reality is that we are still quite some way from the current hardlimit 7 tps, the transaction rate now stands at about 1 tps https://blockchain.info/charts/n-transactions, nobody is feeling the urge to increase the blocksize so there is no way to field test it, not yet.

So does that mean that if you increase the blocksize you will get over 7 tps?

Principally yes but all transactions still get confirmed only when a new block is released, so I'm not sure if it's a good idea to use "tps" here.

Thanks for the reply, my concern is that, i read that visa runs at about 2000 transactions per second. So i guess what i am really asking is. Is there current answers from the core development team that can reassure me as an investor that Bitcoin and not an altcoin has the ability to meet that kind of demand?

[maaku]

Use the search tool, this has been discussed to death already...

[oakpacific]

Use the search tool, this has been discussed to death already...

Now we are onto this maaku, do you have an estimate about the reduction in size the "ultimate blockchain compression"(is it actually a utxo set compression) can bring about?

[maaku]

It can bring the required state for a fully validating node down to few measly kilobytes of working state, forever. Provided you have access to one or more archival nodes willing to serve untrusted data, that is.

"Ultimate blockchain compression" is a bit of a misnomer these days. Pieter Wuille aka "sipa" implemented the compression the name was referring to in his "ultraprune" branch of bitcoind, which was merged with the 0.8 release of the reference client, prior to my getting involved with UBC. That release and all releases since maintain a separate structure containing all data necessary for validating future blocks, stored in a database which at the time I am writing this is about 305MB (vs. about 18GB, so about 94% compression). The reference client still keeps the historical block chain data around, because there are not adequate features in place yet to protect the health of the network once a significant number of nodes start pruning old chain state. But that is something both I and others intend to fix in the near future, thereby allowing people to benefit from these space saving features already deployed. Nodes will still need to retain all of this data however, as they would have no way of retrieving it from untrusted peers in a safe manner.

That is the problem that UBC solves: safely querying a peer for data extracted out of the validation structure. If you assume that there will be at least one reachable peer with the information you need and appropriate bandwidth, then it becomes possible to "compress" (sic) the block chain further by offloading this data onto the network, down to a minimal size of 28 bytes - the hash of the current best block, minus the 4 bytes that are always zero. In reality you'd have to have a few (10's of?) kilobytes to store and process the network messages, and much more than that in cached data to be reasonably performant. But you could probably, for example, make a hardware wallet device with only about 512kb of storage, that nevertheless operates as a full node by querying bitcoind over an untrusted USB connection.

[oakpacific]

It can bring the required state for a fully validating node down to few measly kilobytes of working state, forever. Provided you have access to one or more archival nodes willing to serve untrusted data, that is.

"Ultimate blockchain compression" is a bit of a misnomer these days. Pieter Wuille aka "sipa" implemented the compression the name was referring to in his "ultraprune" branch of bitcoind, which was merged with the 0.8 release of the reference client, prior to my getting involved with UBC. That release and all releases since maintain a separate structure containing all data necessary for validating future blocks, stored in a database which at the time I am writing this is about 305MB (vs. about 18GB, so about 94% compression). The reference client still keeps the historical block chain data around, because there are not adequate features in place yet to protect the health of the network once a significant number of nodes start pruning old chain state. But that is something both I and others intend to fix in the near future, thereby allowing people to benefit from these space saving features already deployed. Nodes will still need to retain all of this data however, as they would have no way of retrieving it from untrusted peers in a safe manner.

That is the problem that UBC solves: safely querying a peer for data extracted out of the validation structure. If you assume that there will be at least one reachable peer with the information you need and appropriate bandwidth, then it becomes possible to "compress" (sic) the block chain further by offloading this data onto the network, down to a minimal size of 28 bytes - the hash of the current best block, minus the 4 bytes that are always zero. In reality you'd have to have a few (10's of?) kilobytes to store and process the network messages, and much more than that in cached data to be reasonably performant. But you could probably, for example, make a hardware wallet device with only about 512kb of storage, that nevertheless operates as a full node by querying bitcoind over an untrusted USB connection.

Thanks, it's probably the first time I get a clue about this.

Still it may make it easier for the law enforcement to close in on the network as people tend to offload the burden of keeping the validation data to others, the decentralization effort requires us to keep the validation structure, which is, I assume, mostly the UTXO set? If 10% of global population adopts Bitcoin, and each of them create something like 50-100 outputs, the set will be dozens of terabytes big, and I guess there is no way to compress it much further?

[maaku]

Ultraprune (0.8+) already packs the validation state as small as it can reasonably get. It's correct that pruning makes the network less secure. This is ultimately about tradeoffs, and lightweight clients. Right now if you can't run a full node you are basically force to put your trust in those who do. UBC makes this a gradual loss of security (for you and for the network) instead of a sharp dropoff, so you have the ability to choose how much is appropriate for you.