until very recently bitcoin has effectively had no block size limit, as blocks near the protocol limit were almost non-existent.
|
|
|
What if you are a day trader and need to keep your coins on the exchange to benefit from market movements?
You could always reconsider your choice of hobbies/occupations.
|
|
|
By the way, part 2 will be out... soonish. Great! I'm waiting for it eagerly. Monday. I'm going to let a proofreader go over this one rather than simply publishing the moment I finished writing the draft.
|
|
|
Of course if there were no block limit, miners would be able to maximize their transaction fee intake whether that mean 2 MB blocks, 5 MB, whatever... market forces will determine the fee per byte that is needed to get a transaction into the blockchain in a timely fashion. Whether that fee makes it economical to purchase a cup of coffee with bitcoin, that remains to be seen (and may very well vary from person to person). I should actually correct myself here since I overlooked the potential tragedy of the commons situation when it comes to miners including transations- a blockchain with no block size limit would not necessarily generate the most fees or be the most secure for that reason. However, it's still entirely possible (and in my opinion quite likely) that increasing the block size limit from 1 MB would increase the total fees per block in the long run. For the entirety of Bitcoin's history, it has produced blocks smaller than the protocol limit. Why didn't the average size of blocks shoot up to 1 MB and stay there the instant Satoshi added a block size limit to the protocol?
|
|
|
What if he's wrong? without MPEx no fork of this network can succeed
|
|
|
I'll repeat what I said on Reddit: https://www.reddit.com/r/Bitcoin/comments/2uiyb3/you_want_to_see_mainstream_adoption_get_more/coakzc9Bitcoin's effect on gender relationships is going to be very interesting.
In certain parts of the developing world, it's going to give women the ability to gain far greater degree of financial independence from their husbands and fathers than they currently enjoy.
In the developed world, it's going to give men the ability to gain far greater financial independence from their (ex-)wives than they currently enjoy.
Once the men in the developing countries and the women in the developed countries figure this out, then the anti-Bitcoin hate machine will really kick into high gear.
|
|
|
Question to the folks who've been testing 0.93 the most: what are your biggest remaining concerns with this release? If I told you I was going to release the software after fixing the tx export problem (which will be in a .6 release in the next 24 hours), what would you complain about the most? No version of Armory is perfect, and at some point we have to say "pencils down", as long as there's no security or major usability issues.
I'm welcome to take feedback from anyone, but in particular I'm inviting:
helgabutters, TimS, zombieslayer9099, justusranvier, bitpop, and Carlton Banks
My apologies if you have been participating actively and I missed your name: I haven't been following this thread too closely myself, and I just picked out names at a glance that had multiple feedback posts. Ideally, I'd at least get a few thoughts back from everyone who has been involved in this the last few weeks.
(EDIT: OSX doesn't count... I'm hoping OSX is relatively stable, but at this point we can't dump too much more in terms of resources into it for the 0.93 release) One caveat: the extent of my testing has been: - Does it compile?
- Will it load and show my balance
Other than generating a few new deposit addresses, I haven't used it for anything beyond that. That being said, I'm extremely happy with the improvements in blockchain scanning and load times and haven't noticed any unfixed regressions.
|
|
|
I was already assuming a perfectly idealized p2p network that had no overhead or sub-linear scaling. I've done as much to explore the space of efficiency gains in this kind of system as any two other people combined here, come on. Please don't try to play off that I don't know how the system works. What I mean is that your perfectly idealized p2p network is still wrong. A more detained explaination is forthcoming. Decentralization has inherent costs. You're not saying anything to escape that. That's exactly true, and I'm not trying to escape it. Everything that any network does has inherent costs, and every one of them in existence of which I am aware either fails to recognize this fact or else does so and does the wrong thing in response.
|
|
|
I believe you're making a false comparison. None of the market participants have a way to express their preference for a decentralized network except by defining Bitcoin to be one though the rules of the system. Absent that someone who doesn't care and just wants to maximize their short term income can turn the decentralization knob all the way down (as we've seen with the enormous amount of centralization in mining pools) and maximize their income-- regardless of what the owners of bitcoins or the people making the transactions prefer. You could just as well argue that miners should be able to freely print more Bitcoins without limit and magically if the invisible pink hand decides it doesn't want inflation it will somehow market-prevent it (in a way that doesn't involve just defining it out of the system). All you've done here is reinforce the fact that the design of the P2P network is broken and should be fixed, which is indeed an argument I am making, with a side order of red herring regarding the issuance schedule. The difference between us is that I don't accept a permanently broken P2P network as a given and conclude that we should employ broken economics as a work around. The broken economics of having a block size limit, and the broken P2P network should both be fixed.
|
|
|
This is a bit unhinged. Typical central planner hubris. So effectively one can replace the fee market with a market that favors the most centralization they have the lowest costs (as thats all network income would pay for). This may be true, but it's not interesting-- since if a highly centralized system were desirable there are more efficient and secure ways to achieve one. You're making assumptions about the preferences of current and future Bitcoin users which are not warranted. If the world wants a system which can conduct transactions at the lowest possible price, then the world will not choose to use Bitcoin, regardless of what you try to shape their behaviour with arbitrary protocol rules. If, on the other hand, there is any demand for censorship resistance and money with a predictable supply, then that demand will express itself as a willingness to pay some price to obtain it. If Bitcoin is going to fail because there is not enough demand for what it provides that people are willing to pay what it costs to obtain it, then Bitcoin is going to fail. If that's what's going to happen, then no amount of tampering with the price discovery process can change that outcome, and indeed will only be counterproductive to any chances at success Bitcoin does have.
|
|
|
what is misused and what can not be calculated?
A non-scarce good is one that does not require allocation because the available supply at a price of zero exceeds the maximum achievable demand at that price. No good that requires time or energy to deliver can be non-scarce. Including transactions in a block will always require both time and energy, therefore the space in a block will be scarce. Because space in a block is scarce, miners will need to allocate the inclusion of transactions into a block, and there exists a price below which they will not do so. We can't calculate ahead of time what the equilibrium price of a transaction will be in the future, because that depends on the future actions and preferences of millions of other people.
|
|
|
What you describe is less than rational limit in 2. First you start out by grossly misusing economic terms. Then, when this is pointed out, you reply by making assumptions about theological price levels which you can't possibly calculate because they are not calculable.
|
|
|
1) the space is scarce Misinformation. Space in a block is always scarce, regardless of whether or not there's a protocol limit. The only to make space in a block non-scarce is to invent a way of transmitting data that requires zero energy, zero time, and exceeds the shannon limit. Whether or not space in a block is scare depends on physics, not on software design.
|
|
|
Conclusion The blockchain permanently restricted to 1MB is great if you are a major bank looking to co-opt the network for a next generation limited trust settlement network between major banks, financial service providers, and payment processors. It is a horrible idea if you even want to keep open the possibility that individuals will be able to participate in that network without using a trusted third party as an intermediary. I agree 100%. There will probably be a role for settlement networks in the future, but even if they do exist those settlement networks should not be artificially subsidized by a block size limit.
|
|
|
By the way, part 2 will be out... soonish.
|
|
|
|