No it doesn't. Read the other threads to understand why. The other threads are full of unsubstantiated irrational assertions, and short on data. They rely on the observed relationship between transaction volume and fee revenue to magically reverse for no reason. |
|
|
|
Ideally we want mining to be supported by transaction fees rather than the block subsidy so that mining capacity will scale with demand. So the question to answer is when that will happen. Right now with the blocks about 25% full we are seeing about 50 BTC of transaction fees per day. This means that with 1 MB blocks the network will earn 200 BTC/day in transaction fees or 1.4 BTC/block. That's obviously not much of an incentive. At 18 MB blocks, however, transaction fees should equal the block reward. With twice the effective income the incentive to mine will double, so we should expect double the investment in ASICs. Since there will be multiple suppliers in the market soon this should result in an increase in the number of miners. If the block size is allowed to increase to meet demand then every increase will result in more economic incentive to mine and this more miners. |
|
|
|
Although I don't believe the BLS's numbers are exact, they probably aren't too far off.[/url]Look into the details sometime about how they calculate their inflation numbers. |
|
|
|
Do I need to overwrite the operating system on netbooks with some linux variant to install the offline armory wallet?
You don't have to but it's probably a good idea. The Armory installation instructions recommend a specific version of Ubuntu. |
|
|
|
There is still the question of what the default behavior should be. Here is a proposal:
Ignore blocks that take your node longer than N seconds to verify.
I'd propose that N be: 60 seconds if you are catching up with the blockchain. 5 seconds if you are all caught-up. But allow miners/merchants/users to easily change those defaults.
Rationale: we should use time-to-verify as the metric, because everything revolves around the 10-minutes-per-block constant.
Time-to-verify has the nice property of scaling as hardware gets more powerful. Miners will want to create blocks that take a reasonable amount of time to propagate through the network and verify, and will have to weigh "add more transactions to blocks" versus "if I add too many, my block will be ignored by more than half the network."
Time-to-verify also has the nice property of incentivizing miners to broadcast transactions instead of 'hoarding' them, because transactions that are broadcast before they are in a block make the block faster to verify (because of the signature cache). That is good for lots of reasons (early detection of potential double-spends and spreading out the verification work over time so there isn't a blizzard of CPU work that needs to be done every time a block is found, for example). Using this proposal all nodes could select for themselves what block size they are willing to accept. The only part that is missing is to communicate this information to the rest of the network somehow. Each node could keep track of the ratio of transaction size to verification time averaged over a suitable interval. Using that number it could calculate the maximum block size likely to meet the time constraint, and include that maximum block size in the version string it reports to other nodes. Then miners could make educated decisions about what size of blocks the rest of the network will accept. |
|
|
|
Except it isn't just me, there are hundreds of users (and owners of bitcoin) like me, who signed on to a system that we thought would have LOWER relative costs to verify in the future. That one day every, even the cheapest computer, could become a full-node. That expectation is insane, unless you expect Bitcoin to remain a tiny niche currency that a statistically insignificant fraction of a tiny minority of the population use, or you just want it to die on the vine. There are a lot of optimizations which could be put in place that would allow regular users to process much higher transaction rates. Maybe we'd need to require users to have a computer purchased within the last 2 or 3 years with a broadband connection instead of a dial up modem, is that really too much to ask? Instead of complaining about how higher transaction rates will make it harder to run a full node, why not support some of the people trying to implement optimizations to make that less of a problem? |
|
|
|
We are not working in a democracy here. We are working with a "do what the you want, but I'm not going to change my code mkay."
For this change to be successful, the bar isn't 50%, or 90%, or 99%, but rather closer to 99.9%.
All you're saying is that to be successful the userbase just needs to grow by an order of magnitude, which is exactly what one would predict if the demand for transactions is exceeding what 1 MB blocks can provide. |
|
|
|
I'm part of that sticky group of people that WILL NOT accept a larger block size. I doesn't matter what other people say; or the reasons that they give. Frankly, I would reject (with my full node, and SPV nodes) any non-bitcoin chain. Any block breaking the 1mb/10min avg limit will not be a bitcoin for me. If they developers commit to scaling the network as far as the demand for transaction requires so that it can be the replacement for PayPal, and for Visa, and maybe even national currencies that we've all been promised, then I'll start up an extra full node to replace yours. |
|
|
|
|
If this change makes it possible for US customers to send funds directly to the exchange via ACH there's be no more need for Dwolla any more. What percentage of their userbase would they lose in that case?
|
|
|
|
CoinLab is going to take over servicing those accounts, and move them to Silicon Valley Bank in the US. Future news article: 'US Government seizes $100 million from CoinLab's bank account.' That's why I don't trade on the exchanges. I send dollars in, sell them for bitcoins, and withdraw those bitcoins to an address under my control. |
|
|
|
Don't worry about the operating system it comes with - install the version of Ubuntu mentioned in the instructions. As far as the laptop goes: Ubuntu 10.04-32bit (Lucid Lynx) was chosen because it will work on just about any computer built in the last 10 years. |
|
|
|
Interesting post. However, I myself have also looked into this, and noted that
1) The current rally started around January the 15th
2) All news posts you link in your article are from February, some of which are only 1 day old:
Hosting.co.uk : Feb 15
Btc ATM: Feb 25
Internet Archive: Feb 21
Mega: Feb 13
Reddit: Feb 16
Namecheap: Feb 20
HumbleBundle (saying they WON'T accept BTC): Feb 26
FrankDomains: Feb 26
3) Setting up an account on MtGox and transfering money there so you can start buying BTCs takes from 2 to 3 weeks.
Therefore, we can safely say that this rally was not caused by the "widespread bitcoin adoption". Maybe the reverse is true, but who knows. What is true is that given the big influx of BTC news this february, we should expect more players to enter the market around next month, but who knows if that will drive the price up or down.
2013-01-10: Coinbase raises bitcoin buying limit to 100 BTC per day for verified customers. 2013-01-15: The approximate start of the rally as noted above. 2013-02-08: Coinbase announces that customers are buying $1 million worth of bitcoins per month. 2013-02-26: Coinbase announces that customers are buying $3 million worth of bitcoins per month. Coinbase tapped into a a large reservoir of previously unmet demand by allowing people in the US to buy bitcoins in significant quantities via ACH. |
|
|
|
Hell, we have enough money that we could hire their whole freaking team full-time for at least a few months.
That would probably be of great benefit to both projects. |
|
|
|
|
Remember when Computer Shopper used to be the size of a phone book in a major metro area?
|
|
|
|
So it makes more sense to integrate policy into all the mining nodes versus a single actor changing their behavior? I don't see where I said it was better to do it that way than for Satoshi Dice to change. If Satoshi Dice is not willing to change that would be the best way to go. If they aren't willing to be reasonable then I don't understand why miners would just complain publicly instead of doing something about it. They aren't helpless. They have options other than complaining. |
|
|
|
|
Nobody is forced to mine Satoshi Dice transaction. Miners can set any fee policy they want for transactions to and from those addresses. If it is causing so much damage they could just refuse to mine those transactional at all and make Satoshi Dice either pay more or mine directly.
|
|
|
|
By the time the exchange rate rises to the levels you are thinking of all the private keys will be forgotten, lost or abandoned.
By the time the exchange rate rises to those levels the amount of space those outputs require would be insignificant. |
|
|
|
Exactly, they whine about auditing and ending the Fed. Why not just ignore the Fed? Because they all want jobs there. How many "Austrian economists" work in academia, one of the most government-dependent industries in the world? |
|
|
|
There is economic incentive to leave them unspent forever. Not forever. Only until the exchange rate is such that they have non-negligible purchasing power. |
|
|
|
|
Show Posts
