Topic: How a floating blocksize limit inevitably leads towards centralization - page 21. (Read 71590 times)

This isn't a hard problem to solve at a technical level. Have the nodes keep track of the version numbers they see on the network. When X% of the network has upgraded to a version which supports the new rules, and when Y% of the miners indicate their support via coinbase flags switch to the new rules. Until then use the old rules. Let the users decide when and if to switch.

No, it does make some sense. With this type of system in place, the security of the network would be based on a BTC based reward. This way we would always have similar security level relative to the actual value of the monetary base.

Bitcoin is bound to become less and less secure relative to the value of bitcoins, since the total reward for miners is going down. Right now it doesn't matter at all because our network, just like Mike Hearn said, is actually extremely secure relatively speaking. It will continue to be that way for a while yet, but not forever. At some point the security level might become questionable. If there was something in place in the lines of Gavin's suggestion, the security of the network is pretty much guaranteed.

I do agree with Mike again that it's a bit questionable to just set it at 50 BTC. We really don't know how much mining is "high security", we only know that what we have now is quite enough. It would be wasteful to pay more fees for more mining if we don't actually need it.

As a protocol rule?
I find that worse than an automatic adjustment of the max block size. You can't set prices like that. You can't predict what 50BTC will represent in the future.

Not to mention off chain transaction service providers will need the accuracy of 8 decimal places or even more when they eventually have to push a sum of off chain transaction onto the chain.

Maybe we could start off with a really conservative schedule of increases, like every time the mining rate halves the maximum block size must at least double?

That would give as an already-overdue doubling from last year's halving of minting, and provide that we will double the size again in less than four years if it isn't at least 4 megabytes by then.

That would give us an as soon as we can reasonably get it done doubling along with a few years in which to argue about whether we can survive until the next halving of the minting or will have to do an emergeny increase before then?

Meanwhile we can also start propagandising more the idea that bitcoins ought rightfully be worth thousands of dollars each, that it is kind of frivolous to use it for transactions of less value than that, and there are plenty of merged mined chains to choose from to start stabilising some other coin's value at some lower value per coin for smaller transactions...

-MarkM-

That effectively sets a lower limit on the fees per transaction.

Why not? They're 64-bit numbers, might as well give plenty of room for whatever the price turns out to be.

More to the point, if I'm correct and in the future we're paying miners billions of dollars a year, that implies Bitcoin is probably transfering trillions of dollars a year in value, on and off chain. In that scenario the market cap is probably tens of trillions of dollars worth, so 1BTC could easily be worth something like $10,000USD. Thus the $20 fee is 0.002BTC. That's pretty close to fees currently in terms of BTC - you might as well ask why do we have 8 decimal places now?


You know, it's not a crazy idea, but trying to figure out what's the right BTC value is a tough, tough problem, and changing it later if it turns out your estimates of what the BTC/USD/mining hardware conversions as well as the orphan rate is a tough problem. You'll also create a lot of incentives for miners to create systems to crawl through the whole Bitcoin network, discovering every single node, and then use that knowledge to connect to every node at once. Using such a system the second you find your block, you'll immediately broadcast it to every node immediately. Of course, the biggest miner who actually succeeds in doing this will have the lowest orphan rate, and thus has much more room to increase block sizes because faking tx fee's costs them a lot less than miners who haven't spent so much effort. (effort that like all this stuff diverts resources from what really keeps the network secure, hashing power)

This same system can also now be used to launch sybil attacks on the network. You could use it to launch double-spend attacks, or to monitor exactly where every transaction is coming from. Obviously this can be done already - blockchain.info already has such a network - but the last thing we need is to give incentives to build these systems. As it is we should be doing more to ensure that each peer nodes connect to comes from a unique source run by an independent entity like using P2Pool PoW's linked to IP addresses.

A soft and hard for are not comparable.

In a soft fork, it is about getting the _majority_ of _miners_ behind the rule. Every piece of old software keeps working. Depending on the change, it may be advisable for merchants to upgrade to get the extra rules enforced, but those who don't just get dropped to SPV-level security. Nothing will break as long as somewhat more than 50% of hash power enforces the new rule.

In a hard fork, it is about getting _all_ of _everyone_ to change the rule at exactly the same time. Doing a hard fork where not everyone is on the same side, is an outright disaster. Every coin that existed before the fork will be spendable once on every side of the chain. If this happens, it is economic suicide for the system. Sure it may recover after a short while, when people realize to pick the side that most others chose, but it is not something I want to see happening.

The only way a hard fork can be done, is when there is reasonable certainty that all players in the network agree.

Changing the protocol is not the same as changing the client. Software becomes so cheap and even free is just because they could always come up with a new version with new features etc... This is the view of a service provider, not a central bank

Bitcoin gained big success just because it is can be trusted, but people certainly do not want their trust to be easily changed by a group of designers at will

Before, I support the change to protocol in a carefully planned way to improve the end user experience, but recently I discovered that you can double spend on both original chain and the new chain after a hard fork, then it means the promise of prevent double-spending and limited supply is all broken, that is much severe than I thought

For this change the distinction is hardly relevant, since it won't happen unless the merchants/users who run full nodes upgrade first.

My favorite quotes from the thread:

I don't think we want magic numbers for how many fees are "required". We don't actually know how much mining is needed today, except that whatever we need, we currently have too much (I don't see any malicious re-orgs that double spend against merchants).

If speeds fall too far and people start getting systematically ripped off by malicious miners, the people who care (ie, merchants) can club together and create all-fee transactions by working together until they reach the speeds they're happy with.

That might work, but it is probably worth while not to un-cap the size limit, just raise it to something that wouldn't cause problems if someone *did* choose to blow a few hundred or thousand bitcoins on blowing up the network. Someone who hacked half a million coins some years back could easily be out there who'd love to blow up the whole shebang for just a few tens of thousands of coins...

-MarkM-

EDIT: As to eight decimals, it provides price granularity, so your transactions of at least one whole bitcoin have plenty of granularty for representing many different fractions of prime or almost-prime larger numbers. It need not mean transactions of less than a whole coin are to be encouraged.

The changes in the last year were "soft forks" -- forks that required all miners to upgrade (if they don't, their blocks are ignored), but that do not require merchants/users to upgrade.

-------

A couple of random, half-baked thoughts I had this morning:

If you think that the block size should stay at 1 megabyte forever, then you're saying the network will never support more than 7 transactions per second, and each transaction will need to be for a fairly large number of bitcoins (otherwise transaction fees will eat up the value of the transaction).

If transactions are all pretty big, why the heck do we have 8 decimal places for the transaction amount?

Don't get me wrong, I still think the bitcoin network is the wrong solution for sub-US-penny payments. But I see no reason why it can't continue to work well for small-amount (between a US $1 and $0.01) payments.

If there are a very limited number of transactions per day and billions of dollars worth of BTC being transacted (that's what we all want, yes?) then obviously each transaction must be large. So, again, why bother having 8 digits after the decimal point if each transaction is hundreds of bitcoins big?

------

Second half-baked thought:

One reasonable concern is that if there is no "block size pressure" transaction fees will not be high enough to pay for sufficient mining.

Here's an idea: Reject blocks larger than 1 megabyte that do not include a total reward (subsidy+fees) of at least 50 BTC per megabyte.

"But miners can just include a never broadcast, fee-only transactions to jack up the fees in the block!"

Yes... but if their block gets orphaned then they'll lose those "fake fees" to another miner. I would guess that the incentive to try to push low-bandwidth/CPU miners out of the network would be overwhelmed by the disincentive of losing lots of BTC if you got orphaned.

They are going to refuse to "relay" things that got into the highest difficulty blockchain?

I thought relaying only meant passing around the stuff that is not yet in the blockchain?

Miners mining blocks can pass them directly to all major pools probably without any "relaying".

-MarkM-

The decision about what blocks to relay is made by the p2p network. What percentage of the people running full nodes are also mining?

I thought I had read it. We are here dissing or discussing the fact the clients would float the limit, aren't we?

If the limit can float, who controls the things it takes into account in determining whether to float and how much to float? What is it looking at to make the decision, that is not controlled by miners?

-MarkM-

To me its obvious that the original is the real bitcoin. Of course any claim that the real bitcoin was superior to the of shoot simply because its the real bitcoin would be a fallacy. So being the real bitcoin is nothing to be proud of its just a label, if the fork is fixing real problems well, and adding awesome new features ect... than go NewCoin!