Topic: Gavin Andresen Proposes Bitcoin Hard Fork to Address Network Scalability - page 8. (Read 18413 times)

Will this cause any disruptions to existing Joe users coins or transactions?

I somehow doubt he is going to provide that - there seems to be a few divided opinions about *what is best* for the future but certainly I think nearly all of us can agree that 7tps is not what we want to be saying about Bitcoin in a few years time.

I would like to hear Satoshi's opinion on this proposal.

"Only invest what you can afford to lose" applies just as well to any complete technology as it does to something that's still in beta. 

Remember, Bitcoin is the initial implementation of a protocol.  Even if Bitcoin is a mature technology and no longer experimental, you should still invest only what you can afford to lose, because some other implementation of the protocol (yes, an altcoin) may eventually be the one that businesses settle on as being friendlier to their interests. 

Are we, or should I say, is the lead scientist ready to say Bitcoin is no longer expermental and retract the statement, "only risk what you can afford to lose"? I wouldn't pretend to know all of the shortcomings of the system that the lead scientist knows. Just the ones I know about have nearly made me exchange my investment in several times. I usually blindly follow the recommendations and word of the "experts" but the group that controls the experts have made me question their ability. I do, however, still trust the word of Mr. Andresen. If he tells me that I can trust the system explicitly and no longer have to be concerned that even more money from the great unformed masses can be lost in the event of a failure I will believe him. Again, this isn't about my ability to make changes. It's about trusting the group making them.

You know what the proper rate is? Looking forward to seeing your paper demonstrating your solution to the economic calculation problem.

Sure, I accept this as a possibility.

What's the best way to combat it?

Spoiler alert: it's not demanding a halt to progress.

There is one valid concern regarding allowing the transaction rate to increase - bandwidth in the network is donated, not paid for. More transactions on the network increase the resource consumption of volunteers who operate relay nodes without providing them with any corresponding revenue.

So if you want Bitcoin to grow sustainably fix that problem instead of demanding the transaction rationing problem remain unfixed.

Of course I agree with increased adoption at the proper rate. I also don't believe Mr. Andresen is a bad person. I just believe big business has the ability to move projects in a direction they see as favorable to them before its ready and present ideas for implementation to intelligent people in a convincing manner.  

I don't trust Bitcoin Foundation, and I also want Bitcoin to scale up because that's the only way it can survive.

There are 7 billion people in the world, and with a 1 MB block size limit, it means everybody on the planet is allowed to use Bitcoin once every 33 years.

That's never going to happen - if Bitcoin transactions stay rationed, then it will die because everybody will switch to a better currency.

I'm not trolling that's what I really believe. You are being paid by an organization that has proven its not responsive to the people and it makes really bad decisions.

I don't think your motivated by greed I think your controlled by business.

Increasing the block size allows an increase in the number of transactions. Do you disagree that this favors increased business adoption? Aren't you the one that continuously calls Bitcoin expermental and advises people to only invest what they can afford to lose? How will increasing adoption favor a system in Beta that shouldn't be trusted?

Please stop trolling. I think what I think and do what I do because I want the Bitcoin Project to be even more wildly successful.

If I was motivated by greed I would have a much higher salary. And lots of stock options.

The majority of Bitcoin users here want transaction fees less than a penny; I want them to be as low as practical. The only way to get there is to increase the block size.

For anyone wanting to know more:










Scalability targets

VISA handles on average around 2,000 transactions per second (tps), so call it a daily peak rate of 47,000 tps. [1]

PayPal, in contrast, handles around 4 million transactions per day for an average of 46 tps or a probably peak rate of 100 tps.

Let's take 4,000 tps as starting goal. Obviously if we want Bitcoin to scale to all economic transactions worldwide, including cash, it'd be a lot higher than that, perhaps more in the region of a few hundred thousand tps. And the need to be able to withstand DoS attacks (which VISA does not have to deal with) implies we would want to scale far beyond the standard peak rates. Still, picking a target let us do some basic calculations even if it's a little arbitrary.

Current bottlenecks

Today the Bitcoin network is restricted to a sustained rate of 7 tps due to the bitcoin protocol restricting block sizes to 1MB.

CPU

The protocol has two parts. Nodes send "inv" messages to other nodes telling them they have a new transaction. If the receiving node doesn't have that transaction it requests it with a getdata.

The big cost is the crypto and block chain lookups involved with verifying the transaction. Verifying a transaction means some hashing and some ECDSA signature verifications. RIPEMD-160 runs at 106 megabytes/sec (call it 100 for simplicity) and SHA256 is about the same. So hashing 1 megabyte should take around 10 milliseconds and hashing 1 kilobyte would take 0.01 milliseconds - fast enough that we can ignore it.

Bitcoin is currently able (with a couple of simple optimizations that are prototyped but not merged yet) to perform around 8000 signature verifications per second on an quad core Intel Core i7-2670QM 2.2Ghz processor. The average number of inputs per transaction is around 2, so we must halve the rate. This means 4000 tps is easily achievable CPU-wise with a single fairly mainstream CPU.

As we can see, this means as long as Bitcoin nodes are allowed to max out at least 4 cores of the machines they run on, we will not run out of CPU capacity for signature checking unless Bitcoin is handling 100 times as much traffic as PayPal. As of late 2012 the network is handling 0.5 transactions/second, so even assuming enormous growth in popularity we will not reach this level for a long time.

Of course Bitcoin does other things beyond signature checking, most obviously, managing the database. We use LevelDB which does the bulk of the heavy lifting on a separate thread, and is capable of very high read/write loads. Overall Bitcoin's CPU usage is dominated by ECDSA.

Network

Let's assume an average rate of 2000tps, so just VISA. Transactions vary in size from about 0.2 kilobytes to over 1 kilobyte, but it's averaging half a kilobyte today.

That means that you need to keep up with around 8 megabits/second of transaction data (2000tps * 512 bytes) / 1024 bytes in a kilobyte / 1024 kilobytes in a megabyte = 0.97 megabytes per second * 8 = 7.8 megabits/second.

This sort of bandwidth is already common for even residential connections today, and is certainly at the low end of what colocation providers would expect to provide you with.

When blocks are solved, the current protocol will send the transactions again, even if a peer has already seen it at broadcast time. Fixing this to make blocks just list of hashes would resolve the issue and make the bandwidth needed for block broadcast negligable. So whilst this optimization isn't fully implemented today, we do not consider block transmission bandwidth here.

Storage

At very high transaction rates each block can be over half a gigabyte in size.

It is not required for most fully validating nodes to store the entire chain. In Satoshi's paper he describes "pruning", a way to delete unnecessary data about transactions that are fully spent. This reduces the amount of data that is needed for a fully validating node to be only the size of the current unspent output size, plus some additional data that is needed to handle re-orgs. As of October 2012 (block 203258) there have been 7,979,231 transactions, however the size of the unspent output set is less than 100MiB, which is small enough to easily fit in RAM for even quite old computers.

Only a small number of archival nodes need to store the full chain going back to the genesis block. These nodes can be used to bootstrap new fully validating nodes from scratch but are otherwise unnecessary.

The primary limiting factor in Bitcoin's performance is disk seeks once the unspent transaction output set stops fitting in memory. It is quite possible that the set will always fit in memory on dedicated server class machines, if hardware advances faster than Bitcoin usage does.

Optimizations

The description above applies to the current software with only minor optimizations assumed (the type that can and have been done by one man in a few weeks).

However there is potential for even greater optimizations to be made in future, at the cost of some additional complexity.

CPU

Pieter Wuille has implemented a custom verifier tuned for secp256k1 that can go beyond 20,000 signature verifications per second. It would require careful review by professional cryptographers to gain as much confidence as OpenSSL, but this can easily halve CPU load.

Algorithms exist to accelerate batch verification over elliptic curve signatures. This means if there are several inputs that are signing with the same key, it's possible to check their signatures simultaneously for another 9x speedup. This is a somewhat more complex implementation, however, it can work with existing signatures (clients don't need upgrading).

Newly developed digital signature algorithms, like ed25519 have extremely efficient software implementations that can reach speeds of nearly 80,000 verifications per second, even on an old Westmere CPU. That is a 10x improvement over secp256k1, and most likely is even higher on more modern CPUs. Supporting this in Bitcoin would mean a chain fork. This ECC algorithm has also been shown to be easily accelerated using GPUs, yielding scalar point multiplication times of less than a microsecond (i.e. a million point multiplications per second).

At these speeds it is likely that disk and memory bandwidth would become the primary limiting factor, rather than signature checking.

Simplified payment verification

It's possible to build a Bitcoin implementation that does not verify everything, but instead relies on either connecting to a trusted node, or puts its faith in high difficulty as a proxy for proof of validity. bitcoinj is an implementation of this mode.

In Simplified Payment Verification (SPV) mode, named after the section of Satoshi's paper that describes it, clients connect to an arbitrary full node and download only the block headers. They verify the chain headers connect together correctly and that the difficulty is high enough. They then request transactions matching particular patterns from the remote node (ie, payments to your addresses), which provides copies of those transactions along with a Merkle branch linking them to the block in which they appeared. This exploits the Merkle tree structure to allow proof of inclusion without needing the full contents of the block.

As a further optimization, block headers that are buried sufficiently deep can be thrown away after some time (eg, you only really need to store say 5000 blocks).

The level of difficulty required to obtain confidence the remote node is not feeding you fictional transactions depends on your threat model. If you are connecting to a node that is known to be reliable, the difficulty doesn't matter. If you want to pick a random node, the cost for an attacker to mine a block sequence containing a bogus transaction should be higher than the value to be obtained by defrauding you. By changing how deeply buried the block must be, you can trade off confirmation time vs cost of an attack.

Programs implementing this approach can have fixed storage/network overhead in the null case of no usage, and resource usage proportional to received/sent transactions.

What I am always wondering, when I read about what the transaction fees should be:
Are you guys proposing a standard fee, that is mandatory?

It would be quite easy to get a 'cash back' for using Bitcoin.  The intel value coming off of the solution probably exceeds the value of being able to scan people's 'private' e-mail and spy on their surfing habits.  I don't doubt for a minute that a majority of people would 'jump eeen it.'  Especially now in the late 2014 makeup of the community.

I'll go check out the link now.

Exchanges are a totally different thing than Bitcoin, and all of the (many) problems I've had in exchange-land have been 100% on the fiat side while the Bitcoin aspect of things has been flawless.

It's not Bitcoin's place to correct hassles with fiat systems, but it is distinctly the place of those steering the Bitcoin solution and network in such a way that such problems will be avoided.  Laying prone on ones back and exposing the jugular in hopes that the regulators will feel pity or be shamed into leaving the solution alone or whatever is a stupid strategy.  At least for those who believe as I do that Bitcoin's strength lays with it's ability to avoid some of these hassles.  OTOH, if one believes that the lack of oversight and control by the authorities is dangerous and a negative, or a potential threat to other important and valued systems then forming Bitcoin into a solution which makes it likely that it will be able to be more controlled does make sense.  These arguments are 100% valid ones, but I don't happen to agree with them.

I do see it as inevitable that if/when the solution grows to a point where most of the infrastructure is provided by corporate entities then control by the authorities will be relatively easy.  Also, of course, that if Bitcoin can grow into a broadly used solution for buying trinkets on the global and persistent blockchain it will be very unlikely that smaller and independent entities will be represented as infrastructure providers.  'Capturing a large user base' is, to me, not a good thing unless the user base is carefully chosen to be people who are less likely to aggravate problems I foresee.

If I were devising an attack on Bitcoin, I would lull the solution into outgrowing it's capacity to operate in the ways it did in the early days then put the hammer down with vigor and with good coordination (since we still have a multi-polar world.)  I think I outlined this strategy nearly three years ago.  What has happened, and what I did not predict, is that it has been damned difficult to NOT form off-chain solutions, and the appeal has been weighted toward those who have money (and want more of it) rather than those with a sweet-tooth for Skittles.  So, pressure on the transaction rate is much less than I would have anticipated at the current valuations and popularity.  Delightful to me, but much to the chagrin of other's in the community I'm sure

I don't know that it's fair to say Bitcoin is unencumbered by regulatory issues. Bitcoin exchanges must be compliant or we will end up with another BitInstant issue. Exchanging for fiat will be necessary for the foreseeable future. Bitcoin is the worlds first personal transfer agent. That's the beauty of it. I can send money to my uncle across the ocean in Germany as easily as if he were across the street and the records are maintained by an enormous very secure system. Of course I can do that without Bitcoin but it's not as fast and it's not as cheap. Bitcoin needs to stay cheap at least for now. It must capture a large user base before any associated big increases in costs occur. That was the original plan after all. Reward subsidies slowly taper off and fees take over. That process should happen naturally per the original design, not overnight.

Got a poll going and early results are interesting. https://bitcointalksearch.org/topic/just-what-is-a-fair-fee-to-send-a-bitcoin-transaction-827209
So far, $2 is not a popular fee for a transaction, and over half the respondents think transactions should cost 1 cent or less.

For my business I pay around $10 for a Bitcoin transaction and am happy to do it (else I'd set my bitcoind more normally.)  This value is less than half what I would pay for a wire and Bitcoin is vastly less hassle and more reliable because so far it is unencumbered by regulatory issues and bank cartels, and not dependent on those who are by necessity under the thumb of said regulators (e.g., Google, etc.)

If I could pay transfer agents I would be happy to do so, and would be very inclined to run one myself full time for my own use if nothing else, and probably off-shore.  If I could break even on it I'd run a dedicated transfer server to do it...and configure a router to actually make the deployment a thing of value to the ecosystem which I only did in the very early days due to security issues.  When I first read up on Bitcoin I was sure I saw reference to transfer fees, and thought found it again some time later.  Last I looked I could find no reference.  Sucked down the memory hole perhaps, or I'm remembering wrong.  The reason I thought I read it is because I considered transfers (bitcoin full) much more important than transaction fees (mining.)  And the reason for this is that I figured that mining could easily shift jurisdictionally while transfer agents would have to be more available to the end-user who may be trying to operate in an environment where controls might be more tight.

You can't get too crazy increasing fees for large transactions. People using a system for large transactions will simply use another system. The money transfer business is huge and competitive. If you make the fee proportional to the amount you're sending someone will figure out a way to be cheaper. TransferWise is a good example of a competitor that is undercutting the market right now by only charging 0.5% to send any amount and will exchange to different currencies at no additional cost. You give Bitcoin a large transfer fee and top it off with an exchange fee you will watch big transfers move elsewhere.

Within the last year I sensed a recognition among the more informed people trying to have Bitcoin support the world's exchange economy was fairly incompatible with having it serve as a reliable monetary medium free of external controls.  Such people may be a 'small minority' at this point, but I don't think it's fair to weigh everyone's opinion equally or if it is fair, it is doomed to failure.  I'd call your attention to the number of relatively new people who will authoritatively produce utterly wrong information on the Multibit sticky thread for instance.

I like your exponential trickery actually.  It will give me plenty of time to execute my exit strategy.