Bitcoin Forum
December 14, 2017, 08:10:21 PM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: TPS, Blockchain bloat and Confirmation speed - Are they a problem?  (Read 1140 times)
stuartcharles
Jr. Member
*
Offline Offline

Activity: 51


View Profile
January 28, 2014, 02:35:22 PM
 #1

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?
Each block is stacked on top of the previous one. Adding another block to the top makes all lower blocks more difficult to remove: there is more "weight" above each block. A transaction in a block 6 blocks deep (6 confirmations) will be very difficult to remove.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1513282221
Hero Member
*
Offline Offline

Posts: 1513282221

View Profile Personal Message (Offline)

Ignore
1513282221
Reply with quote  #2

1513282221
Report to moderator
1513282221
Hero Member
*
Offline Offline

Posts: 1513282221

View Profile Personal Message (Offline)

Ignore
1513282221
Reply with quote  #2

1513282221
Report to moderator
1513282221
Hero Member
*
Offline Offline

Posts: 1513282221

View Profile Personal Message (Offline)

Ignore
1513282221
Reply with quote  #2

1513282221
Report to moderator
stuartcharles
Jr. Member
*
Offline Offline

Activity: 51


View Profile
January 29, 2014, 10:36:10 AM
 #2

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
Hero Member
*****
Offline Offline

Activity: 798


View Profile
January 29, 2014, 11:05:28 AM
 #3

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.

https://tlsnotary.org/ Fraud proofing decentralized fiat-Bitcoin trading.
stuartcharles
Jr. Member
*
Offline Offline

Activity: 51


View Profile
February 03, 2014, 04:56:27 PM
 #4

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
Hero Member
*****
Offline Offline

Activity: 798


View Profile
February 04, 2014, 03:50:19 AM
 #5

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.

https://tlsnotary.org/ Fraud proofing decentralized fiat-Bitcoin trading.
stuartcharles
Jr. Member
*
Offline Offline

Activity: 51


View Profile
February 04, 2014, 04:13:15 PM
 #6

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
Legendary
*
expert
Offline Offline

Activity: 905


View Profile
February 04, 2014, 04:35:23 PM
 #7

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

I'm an independent developer working on bitcoin-core, making my living off community donations.
If you like my work, please consider donating yourself: 13snZ4ZyCzaL7358SmgvHGC9AxskqumNxP
oakpacific
Hero Member
*****
Offline Offline

Activity: 798


View Profile
February 05, 2014, 03:24:21 AM
 #8

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?

https://tlsnotary.org/ Fraud proofing decentralized fiat-Bitcoin trading.
maaku
Legendary
*
expert
Offline Offline

Activity: 905


View Profile
February 05, 2014, 07:55:10 AM
 #9

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.

I'm an independent developer working on bitcoin-core, making my living off community donations.
If you like my work, please consider donating yourself: 13snZ4ZyCzaL7358SmgvHGC9AxskqumNxP
oakpacific
Hero Member
*****
Offline Offline

Activity: 798


View Profile
February 05, 2014, 10:08:03 AM
 #10

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?

https://tlsnotary.org/ Fraud proofing decentralized fiat-Bitcoin trading.
maaku
Legendary
*
expert
Offline Offline

Activity: 905


View Profile
February 05, 2014, 04:34:22 PM
 #11

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.

I'm an independent developer working on bitcoin-core, making my living off community donations.
If you like my work, please consider donating yourself: 13snZ4ZyCzaL7358SmgvHGC9AxskqumNxP
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!