gmaxwell

Legendary





Offline



Activity: 3178

Merit: 4298









ModeratorLegendaryActivity: 3178Merit: 4298 Re: The MAX_BLOCK_SIZE fork January 31, 2013, 11:56:22 AM #21 Quote from: solex on January 31, 2013, 09:53:14 AM Couldn't the block versioning be used as already described below regarding the introduction of version 2?

[...]

The result is close to a "soft fork" with minimum risk and disruption. This would prevent some of worst blockchain forking scenarios described above. In our normal language a softforking change is one which is fully reverse compatible. They are changes which never produce behavior which an original bitcoin node would recognize as a violation of the rules which make bitcoin ... bitcoin. What you're trying to describe is a coordinated hardfork, which is what you'd need to do to change any of the system fundamentals, e.g. change the supply of coins or the time between blocks something we've never done and something that isn't easily made safe.



Softforking changes are safe so long as a sufficient super-majority of mining is on... to older nodes they just look like some txn are indefinitely delayed and some blocks are surprisingly orphaned, but no violations.



A hardforking change requires almost universal adoption by bitcoin users (note: not miners, miners are irrelevant for a hardforking change: a miner that doesn' follow one that is followed by all the users simply isn't a miner anymore) so taking a count of miners is not a good or safe way to go about it. The obvious way to implement one would be to achieve sufficient consensus, and then strike a fixed switchover time at some point in the future. ... though the savvy analyst is asking themselves what happens when the next revision of the rules is prejudicial to their interests?...



When Bitcoin's behavior is merely a system of computer rules you can trust it because you (or people you trust who read code) can point to the rules and say "it is so because of cryptographic proof, the mathematics of the program make it thusly". If the rules are up for revision by popularity contest or whatever system you like then you have a much more complicated trust equation where you have to ask if that process will make decisions which are not only wise but also respect your needs. Who will cast the ballots, who will count them? Even if the process is democratically fair is it something that lets the wolves vote to eat the sheep or does the process somehow respect personal liberty and autonomy? All the blockchain distributed consensus stuff starts sounding easy by comparison.



An alternative theory I present is: if some hardforking change is so valuable, why couldn't an altcoin prove that value and earn its place in the free market and eventually supplant the inferior alternative? Why is that inferior to changing the immutable (within the context of the system) rules when doing so is against the will of any of its users[1]? Or to use the language of libertarian dogma: Must change only come by force? Can any blockchain cryptocurrency survive if it becomes a practice and perception that the underlying software contract will be changed?



Hardforks: There be technological and philosophical dragons.





[1] if the rules are subtly broken and ~everyone agrees that they /must/ be changed that is another matter and not the subject I'm talking about.

In our normal language a softforking change is one which is fully reverse compatible. They are changes which never produce behavior which an original bitcoin node would recognize as a violation of the rules which make bitcoin ... bitcoin. What you're trying to describe is a coordinated hardfork, which is what you'd need to do to change any of the system fundamentals, e.g. change the supply of coins or the time between blocks something we've never done and something that isn't easily made safe.Softforking changes are safe so long as a sufficient super-majority of mining is on... to older nodes they just look like some txn are indefinitely delayed and some blocks are surprisingly orphaned, but no violations.A hardforking change requires almost universal adoption by bitcoin users (note: not miners, miners are irrelevant for a hardforking change: a miner that doesn' follow one that is followed by all the users simply isn't a miner anymore) so taking a count of miners is not a good or safe way to go about it. The obvious way to implement one would be to achieve sufficient consensus, and then strike a fixed switchover time at some point in the future. ... though the savvy analyst is asking themselves what happens when the next revision of the rules is prejudicial to their interests?...When Bitcoin's behavior is merely a system of computer rules you can trust it because you (or people you trust who read code) can point to the rules and say "it is so because of cryptographic proof, the mathematics of the program make it thusly". If the rules are up for revision by popularity contest or whatever system you like then you have a much more complicated trust equation where you have to ask if that process will make decisions which are not only wise but also respect your needs. Who will cast the ballots, who will count them? Even if the process is democratically fair is it something that lets the wolves vote to eat the sheep or does the process somehow respect personal liberty and autonomy? All the blockchain distributed consensus stuff starts sounding easy by comparison.An alternative theory I present is: if some hardforking change is so valuable, why couldn't an altcoin prove that value and earn its place in the free market and eventually supplant the inferior alternative? Why is that inferior to changing the immutable (within the context of the system) rules when doing so is against the will of any of its users[1]? Or to use the language of libertarian dogma: Must change only come by force? Can any blockchain cryptocurrency survive if it becomes a practice and perception that the underlying software contract will be changed?Hardforks: There be technological and philosophical dragons.[1] if the rules are subtly broken and ~everyone agrees that they /must/ be changed that is another matter and not the subject I'm talking about.

AWARD-WINNING

CASINO CRYPTO EXCLUSIVE

CLUBHOUSE 1500+

GAMES 2 MIN

CASH-OUTS 24/7

SUPPORT 100s OF

FREE SPINS PLAY NOW vertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthyor illegal in your jurisdiction. Advertise here.

Jeweller



Offline



Activity: 24

Merit: 0







NewbieActivity: 24Merit: 0 Re: The MAX_BLOCK_SIZE fork January 31, 2013, 12:13:41 PM #22 caveden - Thanks for the link to the thread from 2010. It's interesting that many people, including Satoshi, were discussing this long before the limit was approached. And I definitely agree that having it hard-coded in will make it much harder to change in 2014 than in 2010.



da2ce7 - I understand your opposition to any protocol change. Makes sense; we signed up for 1MB blocks, so that's what we stay with. What I'd like to know is, what would your response be if there was a widespread protocol change? If version 0.9 of the qt-client had some type of increased, or floating max block size (presumably with something like solex proposes), would you:



- refuse the change and go with a small-block client

- grudgingly accept it and upgrade to a big-block client

- give up on bitcoin all together?



I worry about this scenario from a store-of-value point of view. Bitcoins are worth something because of the decentralized consensus of the block chain. To me, anything that threatens that consensus threatens the value of my bitcoins. So in my case, whether I'm on the big-block side or the small-block side, I'm actually just going to side with whichever side is bigger, because I feel the maintenance of consensus is more valuable than any benefits / problems based on the details of the protocol. Saying you reject it on "moral" terms though makes me think you might not be willing to make that kind of pragmatic compromise.



That said, 1MB is really small. I'm trying to envision a world-finance-dominating network with 1MB blocks every 10 minutes and it's tough. While there are lots of great ideas, it does seem to defeat the purpose a little bit to have the vast majority of transactions taking place outside the blockchain.

And if the 1MB limit does stay, it calls in to question the need for client improvements in terms efficiency and so on. If the blocks never get appreciably bigger than they do now, well any half-decent laptop made in the past few years can handle being a full node with no problem.



Perhaps a better question then I'd like to ask people here is: The year is 2015. Every block is a megabyte. Someone wrote a new big-block client fork, and people are switching. What will you do?

justusranvier



Offline



Activity: 1400

Merit: 1006









LegendaryActivity: 1400Merit: 1006 Re: The MAX_BLOCK_SIZE fork January 31, 2013, 12:31:44 PM #23 I don't remember who proposed it but the best proposal I've heard is to make the maximum block size scale based on the difficulty.



The transition to ASIC mining should represent the last step increase in hashing power, so after that's done would be a good time to establish a baseline for whatever formula gets used.

Mike Hearn





Offline



Activity: 1526

Merit: 1008







LegendaryActivity: 1526Merit: 1008 Re: The MAX_BLOCK_SIZE fork January 31, 2013, 02:36:10 PM #25 You could argue against any change to Bitcoin ever based on "those are the protocol rules that were signed up for", but obviously, the protocol has changed many times since its first creation.



All this thread says to me is we need a better FAQ page. The topic comes up repeatedly and no new insight is gained by doing it 11 times rather than 10.

Jeweller



Offline



Activity: 24

Merit: 0







NewbieActivity: 24Merit: 0 Re: The MAX_BLOCK_SIZE fork January 31, 2013, 03:20:15 PM #26 Mike Hearn - Sorry if this feels like a redundant question, or that it's decreasing the signal to noise ratio here in any way. I suppose at it's base it's not really an answerable question: what's the future of bitcoin? We'll have to see.



What's interesting is that there seem to be two fairly strongly divergent viewpoints on this matter: some people assume the transaction network will continue to grow to rival paypal or even credit cards, and see the block size limit as an unimportant detail that will be quickly changed when needed. Others see the limit as a fundamental requirement, or even dogma, of the bitcoin project, and view the long term network as mainly an international high-value payment system, or the backing of derivative currencies. Both views seem reasonable, yet mutually exclusive.



I don't see this kind of disagreement with other often-brought up and redundant issues, such as "satoshi's aren't small enough", "people losing coins means eventually there won't be anything left" and so on. Those aren't real problems. I'm not saying the 1MB limit is a "problem" though, I just want to know what people are going to do, and what's going to happen. Regardless of anyone's opinion on the issue, given the large number of people using bitcoin, the ease with which the change can be made, and the impending demand for more transactions, someone will compile a client with a larger block limit. What if people want to start using it?



I can see this issue limit bitcoin acceptance as a payment for websites: why go to all the trouble of implementing high a high security bitcoin processing system for your e-commerce site if in a couple years bitcoin won't be usable for small transactions? Maybe it will in fact scale up, but without any clear path for how that would happen, many will choose to wait on bitcoin and see what evolves rather than adopt it for their organization.



Sorry if I'm being dense -- from the wiki this is indeed classified as "Probably not a problem", and if some developers come on here and told me, "Quiet, you, it's being worked on," I would concede the point to them. To me though the uncertainty itself of whether the 1MB limit will remain gives me pause. The threads from 3 years ago debating the same topic perhaps make this conversation redundant, but don't settle the issue for me: this was a tricky problem 3 years ago, and is still. The only thing that's changed with regard to the block size is that we're getting ever closer to hitting the limit.



Perhaps this is a conversation we'll just need to have in a year or so when the blocks are saturated.

Mike Hearn





Offline



Activity: 1526

Merit: 1008







LegendaryActivity: 1526Merit: 1008 Re: The MAX_BLOCK_SIZE fork January 31, 2013, 05:23:28 PM #28 Quote from: Jeweller on January 31, 2013, 03:20:15 PM What's interesting is that there seem to be two fairly strongly divergent viewpoints on this matter: some people assume the transaction network will continue to grow to rival paypal or even credit cards, and see the block size limit as an unimportant detail that will be quickly changed when needed. Others see the limit as a fundamental requirement, or even dogma, of the bitcoin project, and view the long term network as mainly an international high-value payment system, or the backing of derivative currencies. Both views seem reasonable, yet mutually exclusive.



It's an issue that will become clearer with time, I think.



By the way, I'm not assuming that Bitcoin will grow to rival PayPal or credit cards. That would be a wild, runaway success that would mark a major turning point in the history of money itself. And the internet is littered with the carcasses of dead attempts to revolutionize payments. It'd be presumptuous to presume future success.



However, if transaction volumes do grow to reach the block size limits, I would (for now) be advocating for a move to a floating limit based on chain history.



To recap: the primary arguments against are



1) Rising requirements for running a node make Bitcoin more centralized

2) The economics of providing for network security when block inclusion is free and inflation has dwindled



For (1), Satoshi always took the position that Moores law would accomodate us. I wrote the Scalability page on the wiki to flesh out his belief with real numbers. As you can see, even with no improvements to todays technology at all Bitcoin can scale beyond PayPal .... by orders of magnitude. It requires nodes to run on server-class machines rather than laptops, but many already do, so I don't see that as a big deal. If Bitcoin ever reaches high traffic levels, CPU time, bandwidth, storage capacity ... all very likely to be cheaper than today. I don't think the "only banks and megacorps run full nodes" scenario will ever happen.



For (2) I have proposed building a separate p2p network on which participants take part in automatically negotiated assurance contracts. I think it would work, but it won't be possible to be truly convincing until it's tried out for real. That in turn requires:



a) That there be some real incentive to boost network security, like semi-frequent re-orgs leading to spends being reversed and merchants/exchanges losing money. Inflation will likely provide us enough security for the medium-term future.

b) Somebody actually build the tool and get people using it.



Then you have to wait and see if community participants step up and use it.



In short, I can't see this question being resolved before we actually run up against the limit, which is unfortunate. I wish Satoshi had put a floating limit in place right from the start. But unfortunately there were many issues for him to consider and only limited time to consider each one, a fixed size limit probably didn't seem like a big deal when he wrote it. It's an issue that will become clearer with time, I think.By the way, I'm not assuming that Bitcoin will grow to rival PayPal or credit cards. That would be a wild, runaway success that would mark a major turning point in the history of money itself. And the internet is littered with the carcasses of dead attempts to revolutionize payments. It'd be presumptuous to presume future success.However,transaction volumes do grow to reach the block size limits, I would (for now) be advocating for a move to a floating limit based on chain history.To recap: the primary arguments against are1) Rising requirements for running a node make Bitcoin more centralized2) The economics of providing for network security when block inclusion is free and inflation has dwindledFor (1), Satoshi always took the position that Moores law would accomodate us. I wrote the Scalability page on the wiki to flesh out his belief with real numbers. As you can see, even with no improvements to todays technology at all Bitcoin can scale beyond PayPal .... by orders of magnitude. It requires nodes to run on server-class machines rather than laptops, but many already do, so I don't see that as a big deal.Bitcoin ever reaches high traffic levels, CPU time, bandwidth, storage capacity ... all very likely to be cheaper than today. I don't think the "only banks and megacorps run full nodes" scenario will ever happen.For (2) I have proposed building a separate p2p network on which participants take part in automatically negotiated assurance contracts. I think it would work, but it won't be possible to be truly convincing until it's tried out for real. That in turn requires:a) That there be some real incentive to boost network security, like semi-frequent re-orgs leading to spends being reversed and merchants/exchanges losing money. Inflation will likely provide us enough security for the medium-term future.b) Somebody actually build the tool and get people using it.Then you have to wait and see if community participants step up and use it.In short, I can't see this question being resolved before we actually run up against the limit, which is unfortunate. I wish Satoshi had put a floating limit in place right from the start. But unfortunately there were many issues for him to consider and only limited time to consider each one, a fixed size limit probably didn't seem like a big deal when he wrote it.

bpd



Offline



Activity: 114

Merit: 10







MemberActivity: 114Merit: 10 Re: The MAX_BLOCK_SIZE fork January 31, 2013, 06:02:39 PM #29 Quote from: Mike Hearn on January 31, 2013, 05:23:28 PM

It's an issue that will become clearer with time, I think.



By the way, I'm not assuming that Bitcoin will grow to rival PayPal or credit cards. That would be a wild, runaway success that would mark a major turning point in the history of money itself. And the internet is littered with the carcasses of dead attempts to revolutionize payments. It'd be presumptuous to presume future success.



However, if transaction volumes do grow to reach the block size limits, I would (for now) be advocating for a move to a floating limit based on chain history.



To recap: the primary arguments against are



1) Rising requirements for running a node make Bitcoin more centralized

2) The economics of providing for network security when block inclusion is free and inflation has dwindled



For (1), Satoshi always took the position that Moores law would accomodate us. I wrote the Scalability page on the wiki to flesh out his belief with real numbers. As you can see, even with no improvements to todays technology at all Bitcoin can scale beyond PayPal .... by orders of magnitude. It requires nodes to run on server-class machines rather than laptops, but many already do, so I don't see that as a big deal. If Bitcoin ever reaches high traffic levels, CPU time, bandwidth, storage capacity ... all very likely to be cheaper than today. I don't think the "only banks and megacorps run full nodes" scenario will ever happen.



For (2) I have proposed building a separate p2p network on which participants take part in automatically negotiated assurance contracts. I think it would work, but it won't be possible to be truly convincing until it's tried out for real. That in turn requires:



a) That there be some real incentive to boost network security, like semi-frequent re-orgs leading to spends being reversed and merchants/exchanges losing money. Inflation will likely provide us enough security for the medium-term future.

b) Somebody actually build the tool and get people using it.



Then you have to wait and see if community participants step up and use it.



In short, I can't see this question being resolved before we actually run up against the limit, which is unfortunate. I wish Satoshi had put a floating limit in place right from the start. But unfortunately there were many issues for him to consider and only limited time to consider each one, a fixed size limit probably didn't seem like a big deal when he wrote it.



Agree, (1) is not a huge issue. Moore's law will prevail. Plenty of people will run full nodes, and those that can't will run header-only or blockchain-less clients.



For (2), I feel like there's a factor I never see mentioned. In the short run (12+ years), the block rewards are more than enough to incentivize mining, especially as we're moving to a world where the variable cost (electricity) of mining is plummeting. Over that same timeframe, the cost of ASICs should also plummet to the marginal cost of production at the same time Moore's law is increasing their power. Hashing power is going to be cheap. Very cheap. I actually hypothesize that even in the case where transaction fees are negligible, if bitcoin has "succeeded", i.e. the value is much much higher than it is today, then we will have de facto proof of stake. Those people and entities with large holdings of bitcoin will have both the resources and the incentive to mine or to pay for hashing power to secure the network. Similar to how those with lots of gold tend to build massive expensive vaults and pay for large amounts of security.



I think it's a mistake to project one's vision of what bitcoin SHOULD be (high-value international transaction network) while ignoring what bitcoin IS becoming in the present. To choke off the growth in the payment network at this stage would be completely counterproductive to getting the value of bitcoin to where we all want it to be longer term. The block size limit MUST be addressed, and most likely within the next year and a half. Agree, (1) is not a huge issue. Moore's law will prevail. Plenty of people will run full nodes, and those that can't will run header-only or blockchain-less clients.For (2), I feel like there's a factor I never see mentioned. In the short run (12+ years), the block rewards are more than enough to incentivize mining, especially as we're moving to a world where the variable cost (electricity) of mining is plummeting. Over that same timeframe, the cost of ASICs should also plummet to the marginal cost of production at the same time Moore's law is increasing their power. Hashing power is going to be cheap. Very cheap. I actually hypothesize that even in the case where transaction fees are negligible, if bitcoin has "succeeded", i.e. the value is much much higher than it is today, then we will have de facto proof of stake. Those people and entities with large holdings of bitcoin will have both the resources and the incentive to mine or to pay for hashing power to secure the network. Similar to how those with lots of gold tend to build massive expensive vaults and pay for large amounts of security.I think it's a mistake to project one's vision of what bitcoin SHOULD be (high-value international transaction network) while ignoring what bitcoin IS becoming in the present. To choke off the growth in the payment network at this stage would be completely counterproductive to getting the value of bitcoin to where we all want it to be longer term. The block size limit MUST be addressed, and most likely within the next year and a half.

jtimon



Offline



Activity: 1372

Merit: 1000







LegendaryActivity: 1372Merit: 1000 Re: The MAX_BLOCK_SIZE fork January 31, 2013, 06:25:45 PM #30

The bitcoin protocol as it is needs a block size limit (not necessarily the one we have today) to avoid a tragedy of the commons on mining when subsidies are gone.

I remember some people advocating for proof of stake (I think that's how that concept started) and me alone advocating for



And now sorry for the free advertising...

Fortunately we have

Freicoin has perpetual reward for miners financed through demurrage fees on holdings.

Before everybody starts complaining about savings and demanding mercy for their grandma's: freicoin is purposely designed to be a medium of exchange and NOT a store of value.

That's the beauty of a free monetary market: different monies can have different qualities and purposes.

About Mike's problem two, this has been discussed many times.The bitcoin protocol as it is needs a block size limit (not necessarily the one we have today) to avoid a tragedy of the commons on mining when subsidies are gone.I remember some people advocating for proof of stake (I think that's how that concept started) and me alone advocating for demurrage And now sorry for the free advertising...Fortunately we have Freicoin which doesn't suffers from this potential problem even if there's no block limit at all.Freicoin has perpetual reward for miners financed through demurrage fees on holdings.Before everybody starts complaining about savings and demanding mercy for their grandma's: freicoin is purposely designed to be a medium of exchange and NOT a store of value.That's the beauty of a free monetary market: different monies can have different qualities and purposes. perishable), abundant) 2 different forms of free-money Freicoin (free of basic interest because it's), Mutual credit (no interest because it's

MatthewLM



Offline



Activity: 1092

Merit: 1000









LegendaryActivity: 1092Merit: 1000 Re: The MAX_BLOCK_SIZE fork January 31, 2013, 07:08:57 PM #31 I disagree with those that say this is bad since it breaks the trust of bitcoin. People who use bitcoin want to retain ownership and usability of their money and to be assured that the inflation rate wont differ. More space in blocks would be a benefit due to lower transaction fees. The integrity of people's bitcoins remains as was ever.



The problem is that the fork may not go seamlessly. If a fork is to be made as many issues as possible should be resolved. For instance, the block timestamp can be made a 64 bit integer as should always have been, so that this disturbance would be as seldom as possible.



Considerations must be made for how bitcoin can scale to much larger block sizes. I have mentioned before that when block sizes reach a point it will be beneficial to relay blocks in separated parts. Bitcoin Extra Wallet | Peercoin Android Wallet

BTC: 1D5A1q5d192j5gYuWiP3CSE5fcaaZxe6E9 PPC: PH7fVn1Xs7nkUFmdwCX2ZRYfLPCSwGxAq9 BTC: 1D5A1q5d192j5gYuWiP3CSE5fcaaZxe6E9 PPC: PH7fVn1Xs7nkUFmdwCX2ZRYfLPCSwGxAq9

caveden



Offline



Activity: 1106

Merit: 1002









LegendaryActivity: 1106Merit: 1002 Re: The MAX_BLOCK_SIZE fork January 31, 2013, 07:52:49 PM #32 Quote from: bpd on January 31, 2013, 06:02:39 PM Quote from: Mike Hearn on January 31, 2013, 05:23:28 PM 2) The economics of providing for network security when block inclusion is free and inflation has dwindled



For (2), I feel like there's a factor I never see mentioned. In the short run (12+ years), the block rewards are more than enough to incentivize mining, especially as we're moving to a world where the variable cost (electricity) of mining is plummeting. Over that same timeframe, the cost of ASICs should also plummet to the marginal cost of production at the same time Moore's law is increasing their power. Hashing power is going to be cheap. Very cheap.

For (2), I feel like there's a factor I never see mentioned. In the short run (12+ years), the block rewards are more than enough to incentivize mining, especially as we're moving to a world where the variable cost (electricity) of mining is plummeting. Over that same timeframe, the cost of ASICs should also plummet to the marginal cost of production at the same time Moore's law is increasing their power. Hashing power is going to be cheap. Very cheap.

Hashing power being cheap is not relevant to the security of the network since it would be equally cheap to an attacker. It's the total amount of resources employed by honest miners relative to those of an eventual attacker that actually matter. Hashing power being cheap is not relevant to the security of the network since it would be equally cheap to an attacker. It's the total amount of resources employed by honest miners relative to those of an eventual attacker that actually matter.

d'aniel



Offline



Activity: 461

Merit: 250







Sr. MemberActivity: 461Merit: 250 Re: The MAX_BLOCK_SIZE fork January 31, 2013, 10:32:23 PM #34 Quote from: MPOE-PR on January 31, 2013, 09:02:34 PM To recap, this is my issue with Hearn: he makes a false claim (quoted above) to prop a false generalization of his. If that doesn't work, he just ignores the point. Intellectual dishonesty at its finest, and not quite the first time either.



Any hard forks in that list of many changes you weasel you!



IIRC, a couple years ago there was a buffer overflow bug that required an emergency hard forking change to fix. I think there was one more that was rolled out gradually over a couple years, but I don't care enough to look it up for you.



Perhaps Mike didn't notice your demand that he address your point because he (understandably) has you on his ignore list. IIRC, a couple years ago there was a buffer overflow bug that required an emergency hard forking change to fix. I think there was one more that was rolled out gradually over a couple years, but I don't care enough to look it up for you.Perhaps Mike didn't notice your demand that he address your point because he (understandably) has you on his ignore list.

bpd



Offline



Activity: 114

Merit: 10







MemberActivity: 114Merit: 10 Re: The MAX_BLOCK_SIZE fork January 31, 2013, 10:46:59 PM #35 Quote from: caveden on January 31, 2013, 07:52:49 PM Quote from: bpd on January 31, 2013, 06:02:39 PM Quote from: Mike Hearn on January 31, 2013, 05:23:28 PM 2) The economics of providing for network security when block inclusion is free and inflation has dwindled



For (2), I feel like there's a factor I never see mentioned. In the short run (12+ years), the block rewards are more than enough to incentivize mining, especially as we're moving to a world where the variable cost (electricity) of mining is plummeting. Over that same timeframe, the cost of ASICs should also plummet to the marginal cost of production at the same time Moore's law is increasing their power. Hashing power is going to be cheap. Very cheap.

For (2), I feel like there's a factor I never see mentioned. In the short run (12+ years), the block rewards are more than enough to incentivize mining, especially as we're moving to a world where the variable cost (electricity) of mining is plummeting. Over that same timeframe, the cost of ASICs should also plummet to the marginal cost of production at the same time Moore's law is increasing their power. Hashing power is going to be cheap. Very cheap.

Hashing power being cheap is not relevant to the security of the network since it would be equally cheap to an attacker. It's the total amount of resources employed by honest miners relative to those of an eventual attacker that actually matter.

Hashing power being cheap is not relevant to the security of the network since it would be equally cheap to an attacker. It's the total amount of resources employed by honest miners relative to those of an eventual attacker that actually matter.

Sorry, I said this badly. My point is, even if transaction fees amount to tens of thousands of dollars daily, as the current block reward does, who has more incentive to run mining equipment? People going after a fraction of those fees, or people trying to protect their billions of dollars of savings? Transaction fees are not the only incentive to run mining equipment.



Sorry, I said this badly. My point is, even if transaction fees amount to tens of thousands of dollars daily, as the current block reward does, who has more incentive to run mining equipment? People going after a fraction of those fees, or people trying to protect their billions of dollars of savings? Transaction fees are not the only incentive to run mining equipment.

da2ce7



Offline



Activity: 1220

Merit: 1000





Live and Let Live







LegendaryActivity: 1220Merit: 1000Live and Let Live Re: The MAX_BLOCK_SIZE fork February 01, 2013, 12:05:26 AM #36



First I wish to point out that that I believe that a bitcoin-like protocol that has no block-size limit. Where the miners choose the best block based upon two factors: block size and difficulty, would be still economically secure. I suggest miners would orphan blocks that are too-large (thus too-expensive to maintain). (The network would find some sort of equilibrium).



If I was to pull out the continuous issue here:

Max_Block_Size is both a network and economic issue.



Changing the max block size has real economic consequences that can be split into two areas: Fees and Uses.



Fees:

While I dont think that the network needs a low Max_Block_Size to remain secure, that shouldnt be up to my own analysis. People may have invested into Bitcoin because they believe the 1MB limit to be the value required to maintain a secure network.



We don't know if Bitcoin had a different limit if they would have invested in the first place OR NOT.



Uses:

In 10-years, a modern smartphone/computer will be able to run the full processing node if the Max_Block_Size remains 1MB. This is a clear economic benefit for Bitcoin: Decentralized Bitcoin verification. In fact in a few years, virtually every computer will be able to process the entire blockchain without issue thus making Bitcoin extremely unique in the realm of payments.



We don't know if Bitcoin had a different limit if they would have invested in the first place OR NOT.





So I believe that the Max_Block_Size is clearly a moral issue, more than a practical issue. Just like the Maximum Bitcoins, or Generation Rates.









Quote from: Jeweller on January 31, 2013, 12:13:41 PM - refuse the change and go with a small-block client

- grudgingly accept it and upgrade to a big-block client

- give up on bitcoin all together?

Keep on using the smaller chain. Although I could double spend my coins in the larger chain for my own benefit.





Quote from: Jeweller on January 31, 2013, 12:13:41 PM Saying you reject it on "moral" terms though makes me think you might not be willing to make that kind of pragmatic compromise.

Yes.



Quote from: Jeweller on January 31, 2013, 12:13:41 PM Perhaps a better question then I'd like to ask people here is: The year is 2015. Every block is a megabyte. Someone wrote a new big-block client fork, and people are switching. What will you do?

If it is better for my purposes than Bitcoin I would move over. However I believe that the network effect will be that bitcoin is always my first store of value.

Jeweller, thank you for your great questions, Ill endeavour to answer them.First I wish to point out that that I believe that a bitcoin-like protocol that has no block-size limit. Where the miners choose the best block based upon two factors: block size and difficulty, would be still economically secure. I suggest miners would orphan blocks that are too-large (thus too-expensive to maintain). (The network would find some sort of equilibrium).If I was to pull out the continuous issue here:Changing the max block size has real economic consequences that can be split into two areas: Fees and Uses.While I dont think that the network needs a low Max_Block_Size to remain secure, that shouldnt be up to my own analysis. People may have invested into Bitcoin because they believe the 1MB limit to be the value required to maintain a secure network.We don't know if Bitcoin had a different limit if they would have invested in the first place OR NOT.In 10-years, a modern smartphone/computer will be able to run theif the Max_Block_Size remains 1MB. This is a clear economic benefit for Bitcoin: Decentralized Bitcoin verification. In fact in a few years, virtually every computer will be able to process the entire blockchain without issue thus making Bitcoin extremely unique in the realm of payments.We don't know if Bitcoin had a different limit if they would have invested in the first place OR NOT.Keep on using the smaller chain. Although I could double spend my coins in the larger chain for my own benefit.Yes.If it is better for my purposes than Bitcoin I would move over. However I believe that the network effect will be that bitcoin is always my first store of value. One off NP-Hard.

BradZimdack



Offline



Activity: 87

Merit: 10







MemberActivity: 87Merit: 10 Re: The MAX_BLOCK_SIZE fork February 01, 2013, 06:19:43 AM #37 I'm becoming very, very concerned about this 1MB block limit, especially since we're already seeing blocks that put us more than 25% of the way there. A mere 7 transactions per second is nothing. One particularly large online retailer does more than that alone. If this limit is not increased somehow, and it sounds like it's not going to be possible, then I'm really afraid this will have a very negative impact on Bitcoin's ultimate value, utility, and security.



Just speaking hypothetically, suppose that:



* We're constantly capping out on the 1MB limit;

* We're at a point where the majority of miner's fees come from transaction fees;

* Mining has become optimally efficient such that marginal profit approaches zero.



In this scenario, competition for block space would be so fierce as to push transaction fees into the range of several dollars per KB. It could also then take several hours to get some available block space, even with high fees. I can't foresee it ever costing more than what a bank charges for a wire transfer, which at my bank is $30. A wire is also pretty fast, so it's doubtful someone is going to pay more than $30 for a Bitcoin transfer and put up with waiting longer than it would take to do a bank wire.



At 7 tps, that's 604,800 transactions per day maximum. At a maximum average fee of $30 per transaction, that's about $18.1 million per day in fees. If we're assuming that mining will approach zero profit, including electricity, hardware depreciation, and R&D -- meaning that 100% of fees paid are going directly to the services needed to secure the network -- then the total annual investment in mining work will not exceed $6.6 billion. As has been mentioned before, network strength should be measured in currency, not hash rate, because that's the actual cost an attacker would have to incur to break it. So, in this scenario, we have a maximum network strength of $6.6 billion and it could never, ever be stronger than that without a lot of money being spent to run at a loss. Pulling off a 51% attack would mean only slightly exceeding that. If there's enough value being transacted to demand $30 transaction fees, then banks and governments will probably be somewhat irked that so much value is changing hands without them getting their cut. $6.6 billion is pocket change for a bank or a government, especially because they'd see such a big return on investment from blocking all these direct transfers.



That's just from the security side of things. From a utility point of view, once fees start to cost a few bucks, Bitcoin is going to look like a pretty lousy way to pay for most everyday items, and credit cards will look cheap again -- even with their massive fraud rate.



I don't know enough about how all the pieces work, but it sure seems to me like we need a lot more than a 1MB limit...and quick. Can someone tell me what I'm missing here or reassure me that I have no idea what I'm talking about and that everything will be fine?

Atruk



Offline



Activity: 700

Merit: 500









Hero MemberActivity: 700Merit: 500 Re: The MAX_BLOCK_SIZE fork February 01, 2013, 07:03:06 AM #38 Quote from: MPOE-PR on January 31, 2013, 09:02:34 PM



Any hard forks in that list of many changes you weasel you!



Quote from: jtimon on January 31, 2013, 06:25:45 PM And now sorry for the free advertising...

Fortunately we have Freicoin which doesn't suffers from this potential problem even if there's no block limit at all.

Freicoin has perpetual reward for miners financed through demurrage fees on holdings.

Before everybody starts complaining about savings and demanding mercy for their grandma's: freicoin is purposely designed to be a medium of exchange and NOT a store of value.

That's the beauty of a free monetary market: different monies can have different qualities and purposes.



Nothing to be sorry about (I had no idea it existed, for one) and good luck with it.

To recap, this is my issue with Hearn: he makes a false claim (quoted above) to prop a false generalization of his. If that doesn't work, he just ignores the point. Intellectual dishonesty at its finest, and not quite the first time either.Nothing to be sorry about (I had no idea it existed, for one) and good luck with it.

I don't blame you for not slumming it up with us little people who watch the altchain discussion. Freicoin was big news about a month ago until people realized it was just the lewest, pumpingest, and dumpingest of the altcoins. A full 80% of the initially issued goings flowing into a hardcoded developer controlled foundation which would take a hard fork (not quite sure if it is irony) to remove.



Apologies for the quality of the following linked thread



Subsidizing mining by demurrage may or may not be a good idea in a future cryptocurrency (probably a bad idea), but bitcoin's momentum and prestige by having substantial value is why these discussions over single technical issues inspire a lot of passion. This same affinity for the majority of bitcoin's traits and features means that any fork or altchain Joe Idea that incorporates their entire wish list of changes isn't going to be adopted by many people beyond Joe Idea, because for a majority Joe Idea's "improvements" are going to seem like a step backwards, if they don't think the changes broke everything they liked about the system. I don't blame you for not slumming it up with us little people who watch the altchain discussion. Freicoin was big news about a month ago until people realized it was just the lewest, pumpingest, and dumpingest of the altcoins. A full 80% of the initially issued goings flowing into a hardcoded developer controlled foundation which would take a hard fork (not quite sure if it is irony) to remove.Apologies for the quality of the following linked thread https://bitcointalk.org/index.php?topic=134665.0 Subsidizing mining by demurrage may or may not be a good idea in a future cryptocurrency (probably a bad idea), but bitcoin's momentum and prestige by having substantial value is why these discussions over single technical issues inspire a lot of passion. This same affinity for the majority of bitcoin's traits and features means that any fork or altchain Joe Idea that incorporates their entire wish list of changes isn't going to be adopted by many people beyond Joe Idea, because for a majority Joe Idea's "improvements" are going to seem like a step backwards, if they don't think the changes broke everything they liked about the system. Bingo Blog - A Blog of Bitcoin and Boingo

qntra - Bitcoin News