Bitcoin Forum
June 22, 2024, 08:27:28 AM *
News: Voting for pizza day contest
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 3 4 [5] 6 7 »
81  Bitcoin / Bitcoin Discussion / Re: Title: Near Zero Bitcoin Transaction Fees Cannot Last Forever on: October 26, 2014, 02:56:10 PM
Bitcoin high frequency trading:   

47,000 tps (around the peak rate of VISA) = 28,200,000 transactions per ~10 minute block

Fee of 0.000000017 = 5 bitcoins per block transactions reward for miners. Easily sustaining the network at a high price. If Bitcoin is going to be a global cash system we'd probably have hundreds of thousands of transactions per second. But having more transactions per second than VISA is a good initial.


In short: Fee is sustainable.

82  Bitcoin / Bitcoin Discussion / Re: Gavin Andresen Proposes Bitcoin Hard Fork to Address Network Scalability on: October 26, 2014, 02:51:43 PM
I think raising the fees for scalability would be too much. For a fee of 0.02, imagine if 1 Bitcoin was worth $1000. That would result in a fee of $20 for any transaction, regardless of how much is being sent! That's not very ideal. I think what can be done is to support a larger number transactions per block. More transactions processed = more fees collected.

But this won't solve the problem over time.  See the response by kkaskal in this thread: https://bitcointalk.org/index.php?topic=668704.0

And the graphic at URL in this thread:

<img class="userimg" src="https://ip.bitcointalk.org/?u=http%3A%2F%2Fi.imgur.com%2FMCWO0tH.png&amp;t=545&amp;c=8_MsRYuvimAWfQ" alt="" border="0"></img>

Note block reward is decreasing over time, a well known problem since the number of bitcoins is fixed and it gets progressively harder to mine bitcoins over time, all things being equal.

I made a fairly reasonable calculation on future fee costs that shows it actually is sustainable.
83  Bitcoin / Bitcoin Discussion / Re: Gavin Andresen Proposes Bitcoin Hard Fork to Address Network Scalability on: October 26, 2014, 12:04:07 PM

Actually combining blockchain pruning (i.e, the "main" blockchain only storing UNSPEND addresses), and some of the new emerging technologies like ed25519 that even on an old 2010 CPU we're already capable of 80,000 verifications per second. Seeing how we have a HUGE HUGE way to go before we actually reaching that amount of transactions per second, when we actually do reach it would likely be way post 2020, where we will have even faster hardware and likely better algorithms, which should technically be able to sustain the guidelines I mentioned.

Not to mention that most people would be running light clients anyway around that time, just as described in satoshi's original paper.

In the end there is no reason not to have everything running on the main blockchain since technological difficulties can be overcome.

I've heard all this kind of things ad-nauseam for the 3+ years that I've been following things.  Simultaneously I've seen both the hardware and network improvements which have been made realistically available over that time period, and also the struggles Bitcoin has had just to make the original 7 TPS number kinda work.  Many of them were not pretty.  Some of these rosy predictions about how technology will swoop in to save the day (and let us go from 7 TPS to 200,000 TPS which is enthusiastic even for your type) would be more convincing if there were a few more signs of it actually occurring.



One of the main reasons these things haven't been implemented before is that Bitcoin as a whole was still in a massive alpha stage, having more transactions per second simply wasn't needed up until now. And now especially so that we can continue to grow.

Commercial profit driven companies attempting centralized solutions (like blockstream) to problems can be solved with decentralized and open solutions are honestly very terrifying, and I hope that technological advances on Bitcoin deploy fast enough to prevent any side-chaining or centralized solution having to take its place so we can continue this open concept revolution for everyone to continue spreading. 

What is also important is sidechains are useless if you want to receive your remainder of tokens back in bitcoins. All this will do is switch value away from an open decentralized solution to a closed centralized "solution".
84  Bitcoin / Bitcoin Discussion / Re: Gavin Andresen Proposes Bitcoin Hard Fork to Address Network Scalability on: October 25, 2014, 02:57:24 PM
...
In order to prevent high transaction fees we need to increase blocksize and remove the 7tps limit. It appears that the majority of community is in "pro" of this so it should be done quickly to prevent the inevitable high transaction fee explosion. When transaction fees become important hopefully miners will make their fees by high volume of transactions (all at a low fee).

Example:

Bitcoin high frequency trading:   

47,000 tps (around the peak rate of VISA) = 28,200,000 transactions per ~10 minute block

Fee of 0.000000017 = 5 bitcoins per block transactions reward for miners. Easily sustaining the network at a high price. If Bitcoin is going to be a global cash system we'd probably have hundreds of thousands of transactions per second. But having more transactions per second than VISA is a good initial.

High transaction fees:


7 tps limit:

5 bitcoins (transaction reward) / 4200 (tranactions per block) = 0.001190 transaction fee. Way too high for the consumer paying his hamburger at a restaurant.

=====================

Combining pruning + near no limit of transactions = low transactions fee.

Why artificially limit a open concept market? The market will take care of the fee, we shouldn't impose limits on it except to prevent massive blockchain spam or otherwise malicious activities.


That should make it pretty clear why I (and quite a few others) don't believe that Bitcoin in anything remotely resembling it's original and described implementation (distributed persistent decentralized ledger) is applicable as a solution to the described problem.  Bitcoin won't scale just because people would think it's cool if it did.  A handful of large organizations probably could run Bitcoin at these rates but realistically that's about it, and at that point they may as well do away with the blockchain itself and make it a real-time system like VISA.  That's why clued in folks like the blockstrream guys are looking around for a solution which will let Bitcoin scale to these levels without abandoning the very desirable aspects of the solution that it has today.



Actually combining blockchain pruning (i.e, the "main" blockchain only storing UNSPEND addresses), and some of the new emerging technologies like ed25519 that even on an old 2010 CPU we're already capable of 80,000 verifications per second. Seeing how we have a HUGE HUGE way to go before we actually reaching that amount of transactions per second, when we actually do reach it would likely be way post 2020, where we will have even faster hardware and likely better algorithms, which should technically be able to sustain the guidelines I mentioned.

Not to mention that most people would be running light clients anyway around that time, just as described in satoshi's original paper.

In the end there is no reason not to have everything running on the main blockchain since technological difficulties can be overcome.
85  Bitcoin / Bitcoin Discussion / Re: Gavin Andresen Proposes Bitcoin Hard Fork to Address Network Scalability on: October 25, 2014, 09:28:14 AM
I think raising the fees for scalability would be too much. For a fee of 0.02, imagine if 1 Bitcoin was worth $1000. That would result in a fee of $20 for any transaction, regardless of how much is being sent! That's not very ideal. I think what can be done is to support a larger number transactions per block. More transactions processed = more fees collected.

Indeed, even if no more mining rigs were built between now and 2040-ish it would require very large transaction fees just to keep the existing rigs powered up unless BTC valuations expand by a bunch.  And if the miners cannot make a dime helping Bitcoin then we better hope and pray that they cannot do so by harming it either.  Of course 'hope and prayer' are often fairly ineffective engineering strategies.


Transaction fees only exists for 2 reasons currently;

1. To prevent massive blockchain spam
2. To keep the miners going after block reward is either extremely low or non existent

If no more miners would be build it would actually be more profitable for current miners because the difficulty would stop increasing exponentially, current miners would be celebrating on the streets since they will keep making the same amount of bitcoins per month.

On the counterpart, old mining equipment simply goes into retirement when they become obsolete (too slow, too much power draw, etc)

I don't see the average consumer dealing with sidechains and everything. If we remove the limit of 7tps soon, we might be in time to prevent massive transaction fees when the next price/transaction spike happens. In the end Bitcoin is advertised as a low fee system, if each transaction starts costing dollars personally I would loose interest.

Also creating sidechains would destroy Bitcoin when the block reward gets extremely low or when we stop having block rewards, since miners on the main chain would either stop mining since the transaction fee is so low (making the network extremely insecure), or make transactions on the main chain insupportably expensive to maintain their mining.

In order to prevent high transaction fees we need to increase blocksize and remove the 7tps limit. It appears that the majority of community is in "pro" of this so it should be done quickly to prevent the inevitable high transaction fee explosion. When transaction fees become important hopefully miners will make their fees by high volume of transactions (all at a low fee).


Example:

Bitcoin high frequency trading:   

47,000 tps (around the peak rate of VISA) = 28,200,000 transactions per ~10 minute block

Fee of 0.000000017 = 5 bitcoins per block transactions reward for miners. Easily sustaining the network at a high price. If Bitcoin is going to be a global cash system we'd probably have hundreds of thousands of transactions per second. But having more transactions per second than VISA is a good initial.

High transaction fees:


7 tps limit:

5 bitcoins (transaction reward) / 4200 (tranactions per block) = 0.001190 transaction fee. Way too high for the consumer paying his hamburger at a restaurant.

=====================

Combining pruning + near no limit of transactions = low transactions fee.

Why artificially limit a open concept market? The market will take care of the fee, we shouldn't impose limits on it except to prevent massive blockchain spam or otherwise malicious activities.
86  Bitcoin / Bitcoin Discussion / Re: Gavin Andresen does an IAmA on reddit on: October 22, 2014, 08:05:55 AM
Great to see him connecting with the community.

87  Bitcoin / Bitcoin Discussion / Re: Lost Bitcoins on: October 21, 2014, 02:34:38 PM
https://docs.google.com/a/ij.hk/spreadsheet/ccc?key=0Ahdy3Je_nYdOdFVocm4yTzhZOW1waWd6SFJIVHUwYUE#gid=0
88  Bitcoin / Bitcoin Discussion / Re: BTC is better than Apple Pay? on: October 21, 2014, 11:32:43 AM
A Bitcoin debit card with NFC chip will do the same as apple pay but even quicker.

I've had a NFC chip in my card for over a year now and have been wirelessly paying up to 50 euros without having to sign or introduce any pin code. Much quicker, just tab the terminal with your card and it's paid. Once again Apple pretends like they invented something that has been around for a very long time.
89  Bitcoin / Bitcoin Discussion / Re: Gavin Andresen Proposes Bitcoin Hard Fork to Address Network Scalability on: October 21, 2014, 08:44:22 AM

A lot of the motivation for the 1MB limit was a fear that if it weren't limited we'd have people building gigantic blocks just to clog up the system.  If someone with major hashing power started building giant blocks every time he got a block, he  could DoS the system just by making the block chain too large for most people to store.  


How exactly would this be done? Where are these transactions coming from? Could this "bloating" attack be detected and these blocks rejected?

It would be better to prevent this some other way and remove the limit entirely.


This has already been addressed by Gavins original post. Maximum Block size would for example grow 50% per year to allow for more transactions in each block, per year, while still keeping storage costs relatively low. A totally unrestricted block size has never been spoken about.

90  Bitcoin / Bitcoin Discussion / Re: Gavin Andresen Proposes Bitcoin Hard Fork to Address Network Scalability on: October 21, 2014, 08:42:38 AM
The lead dev works exclusively for big business.

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.



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?

This is absolutely ridiculous, your logic is that making bitcoin more widely available for business in general is a bad thing? Supporting more transactions is a bad thing? A growing community is a bad thing? Having bitcoin successful is a bad thing?

As long as the protocol maintains it's decentralization no external businesses can influence the protocol in any bad way. Read up how all this works and then get back and reply.
91  Bitcoin / Bitcoin Discussion / Re: Gavin Andresen Proposes Bitcoin Hard Fork to Address Network Scalability on: October 20, 2014, 09:26:55 AM
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.
92  Bitcoin / Bitcoin Discussion / Re: The Rise and Rise of Bitcoin - Full Movie | Download | Watch Online for Free on: October 18, 2014, 10:24:02 AM
Nicely done, congratulations!

I enjoyed every minute of it, a very interesting watch.
93  Bitcoin / Bitcoin Discussion / Re: Gavin Andresen Proposes Bitcoin Hard Fork to Address Network Scalability on: October 18, 2014, 09:25:48 AM
Can someone post a non technical dummies guide to what the changes will be?

Do the changes mean less miners reward?



Explain it like I'm 5 version:


The size of the "closet" (block) that is "created" (mined) every 10 minutes will be increased so that more "clothes" (transactions) can fit in each "closet" (block).

Of course bigger "closets" (blocks) also need more space to "store" (MB's per block) all those created closets.

This does not necessarily mean that miners will get paid less, but it will be easier for them to include more "clothes" (transactions) into each "closet" (block). Miners will always charge what they want for a transaction, the market will take care of the rest.
=====================================================================

Each block will still reward 25 bitcoins to the miner that generates the block (that continues to lower per halvening as scheduled). The only thing can MIGHT change is how much transaction fee is paid per transaction.
94  Bitcoin / Bitcoin Discussion / Re: Gavin Andresen Proposes Bitcoin Hard Fork to Address Network Scalability on: October 18, 2014, 08:56:46 AM
The real question is do you think it is feasible to do this before the "hard-fork"?

It is already being done, so yes. Optimizations to how transactions or blocks are communicated between peers don't require any sort of fork.

Hi Gavin,

Is there a time schedule for future updates/upgrades or a list with the high priority items for future updates?

95  Bitcoin / Bitcoin Discussion / Re: Gavin Andresen Proposes Bitcoin Hard Fork to Address Network Scalability on: October 17, 2014, 08:37:15 AM
Great decision, enabling more transactions over the network is one of Bitcoins core necessities as the project grows. Especially removing the stupid 7tps limit imposed right now.

Don't forget that as more transactions would be allowed per block it's very likely that if these changes are implemented right now would mean that all broadcast transactions would be immediately included into the very next mined block, this would in turn also SIGNIFICANTLY lower mining fees since miners will want to include as many as possible transactions per block.

Also, it would be easy to hard fork this since you can technically give nodes time to update, for example the new Bitcoin-QT/bitcoind is rolled out and the block change doesn't go into effect for another 6000 blocks. This way there would be time for everyone to update their clients.

And scaling all this at half of Moore's law looks more fair as well to keep the costs of storage down. This would however be even better if combined with a more compressed version of the blockchain.

Perfect change, here's to hoping they will implement it soon.
96  Bitcoin / Bitcoin Discussion / Re: Tor+Blockchain wallet hacked? 633 btc loss on: October 14, 2014, 09:18:53 AM
His browser either got hijacked with spyware or his OS. Then the second option would be that the tor exit node falsified the http/ssl certificate to be able to sniff on the password, the last is very unlikely.


If you're storing that much bitcoins one would be wise to store them offline.... Or at least on a separate Linux pc only used to store bitcoins running a good secure wallet.
97  Bitcoin / Bitcoin Discussion / Re: What Do People Buy With There Bitcoin? on: October 11, 2014, 09:50:07 PM
Just booked another hotel at expedia, worked like a charm  Smiley

What site did you book your hotel in?

expedia.com , they accept bitcoins directly using coinbase
98  Economy / Speculation / Re: Thats it! I'm out! :@ on: October 06, 2014, 11:44:08 AM
there is zero chance I will sell at these levels. I am being careful though before buying to much at these lvls' I want to make sure we are going to get support here and push back towards 400+

Like I said, my absolute lowest logical low would be pre-willy levels. Seeing how much market adoption we've secured over the last year tough it's very doubtful that would happen. A more logical bottom would be around 200-220$, regardless if it does hit that price it wouldn't be for very long. All in all it's a perfect moment to buy some. If we do stable out at this price we could be up to the 400's by the end of next week again.
99  Economy / Trading Discussion / Re: How can I deposit money through CC to these services as a US resident? on: October 06, 2014, 12:18:58 AM
I want to purchase BTC on btc-e.com, but I obviously need to deposit some money/crypto currency (which I don't have) to my account. I want to deposit some USD via my credit card, and it's possible through these services:
Perfect
Money
OKPAY
Payeer
Ecoin
Epese

I've tried, but on each site I get some sort of an error. What can I do? If I use a German (for example) proxy, will my American credit card still work?
Thanks.

https://www.circle.com/en

and

https://www.coinbase.com/

Both support directly buying bitcoins with your creditcard or linking them to your bank account to buy directly. Much easier.
Thank you, I know of the 2 sites, however I do not have a bank account.

Doesn't a creditcard always get linked to a bank account?

Regardless of that answer, with Circle you can buy bitcoins directly using your creditcard, will take less than 5 minutes Smiley.
100  Economy / Trading Discussion / Re: How can I deposit money through CC to these services as a US resident? on: October 06, 2014, 12:03:18 AM
I want to purchase BTC on btc-e.com, but I obviously need to deposit some money/crypto currency (which I don't have) to my account. I want to deposit some USD via my credit card, and it's possible through these services:
Perfect
Money
OKPAY
Payeer
Ecoin
Epese

I've tried, but on each site I get some sort of an error. What can I do? If I use a German (for example) proxy, will my American credit card still work?
Thanks.

https://www.circle.com/en

and

https://www.coinbase.com/

Both support directly buying bitcoins with your creditcard or linking them to your bank account to buy directly. Much easier.
Pages: « 1 2 3 4 [5] 6 7 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!