Fork off

[tvbcof]

Also, the miners need it to be able to make any profit once the block reward is too low.

It's actually the other way around.

I read through some of it before my eyes glazed over completely.  The reason Gavin spanked your hiney is that at the end of the day all you seem to have is the same simplistic and tedious free-markets chant as rest of the crew who only know Ayn Rand juvi econo-porn and are incapable of moving outside of that box.  Alas, the physical world is more complicated (and the ideas are mostly broken to boot.)

Such a shame because Gavin is similarly confused about a lot of shit.  Thanks for all your work in documenting the game of blind-man's-buff anyway.

[1715023758]

1715023758

[1715023758]

1715023758

[1715023758]

1715023758

[phillipsjk]

I may be a silly socialist, but asking for the block-size to be increased is hardly asking for a "free ride".

First, Bitcoin is still new. Coins are still being distributed through the block-subsidy. As has been pointed out, transaction fees are currently insignificant compared to the block subsidy. Artificially inflating fees to match the currentl block subsidy will only discourage Bitcoin usage (which would make the block-chain smaller).

Second, even with an "infinite" block-size, there are still practical limits to the size of blocks. For example, my full node (with idle token hash-power) is currently set to broadcast 500kB blocks. The reason is that my (ADSL) Bandwidth is limited to 5Mbps up. If I want to send a newly found block to 16 hosts at once, we are talking a delay of about 12.8 Seconds. With a 600 second block-time, that corresponds to an orphan rate of at least 2.1% (one hop). If I had a 1Gbps connection, and wanted to limit my orphan rate to 5%: 600x.05=30 seconds. 1Gbps*30s/(say)64 connections*8bits/byte=58.6MB Block-size (again assuming one hop). At about 300 bytes per transaction (many transactions are larger), that works out to about 195 thousand transactions per block.

Third, Bitcoin can not even replace the SWIFT network with a block-size of 1MB.

With 24.62 million messages per day, December 2014 is the best traffic month ever for SWIFT, beating previous months’ record with more than 1.2 million messages per day. During the last three months of the year, growth versus the previous year was above 12%, further improving the YTD growth and ending the year with a growth of 11.0%, which is the greatest increase in traffic recorded since 2007. Over 5.6 billion FIN messages were recorded in 2014. On top of being the month in which a new total SWIFT FIN traffic record was reached, December is also a new best month for Payments (+8.6% vs November) and Securities (+1.8% vs June).

- Monthly FIN traffic evolution

Taking the yearly average: 5.6 Billion messages/(365.25 days/year)/(24 hours/day)/(3600 seconds/hour)= 177 messages per second.
I am not completely sure if 1 FIN message==1 Bitcoin transaction, but 177 sounds a lot higher than the common 7tps figure thrown around.

(195k transactions/block)/(600 seconds/block)= 325 Transactions/second for the 56MB block figure.
For the 20MB block being debated: (20MB/block)/(300Bytes/transaction)/(600 seconds/block)= 111 Transactions/second.

So, even with the proposed larger block-size, Bitcoin would still not be able to match the SWIFT network. If Bitcoin even attempted it, the value per coin would be so high that even 100µBTC fees would be comparable to SWIFT transaction costs. In other words, people will naturally stop using Bitcoin to buy snacks/coffee.

Edit: Fees with different block-sizes (assuming 100µBTC/kB)
1MB=100mBTC
20MB=2BTC
56MB=5.6BTC

Those figures imply the fees won't be be significant until the block reward drops to 12.5 or 6.25 BTC/block. Note that the 2BTC figure is almost 10% at the current block subsidy (but the block-size is limited).

[solex]

Edit: Fees with different block-sizes (assuming 100µBTC/kB)
1MB=100mBTC
20MB=2BTC
56MB=5.6BTC

Those figures imply the fees won't be be significant until the block reward drops to 12.5 or 6.25 BTC/block. Note that the 2BTC figure is almost 10% at the current block subsidy (but the block-size is limited).

Nice to see your estimates. I have long thought about where the reward/fee crossover point is. Obviously it depends upon rate of tx growth, but 30-60MB seems likely to be the block size range.
Agreed also that the block reward is still in the subsidize-to-grow-usage phase, tx fees are really useful just as an anti-spam measure. Beyond that, trying to force tx fees higher at this point only risks driving ecosystem business to alternative cryptocurrencies.

[davout]

I wasn't following it closely (and was a little disgusted) but as I recall, all lukedashjr did was mine for a while then quite and it had a devastating impact on whatever coin it was.  Hell, the same thing could happen to Bitcoin without any attack if the price drops steeply or suddenly (but that could never happen, right?) and/or a few large clusters were molested.  I'll call this an 'Invisible hand of Adam Smith lukedashjr Attack.'  Maybe the adjustment algorithms have been patched up to preclude this, but I doubt it...such things occurring proactively seem rare in Bitcoinland.

No, that's possible. It's just incredibly harder to pull-off.
Double-spends would become a concern before this gets anywhere near serious.

Second, even with an "infinite" block-size, there are still practical limits to the size of blocks. For example, my full node (with idle token hash-power) is currently set to broadcast 500kB blocks. The reason is that my (ADSL) Bandwidth is limited to 5Mbps up. If I want to send a newly found block to 16 hosts at once, we are talking a delay of about 12.8 Seconds. With a 600 second block-time, that corresponds to an orphan rate of at least 2.1% (one hop). If I had a 1Gbps connection, and wanted to limit my orphan rate to 5%: 600x.05=30 seconds. 1Gbps*30s/(say)64 connections*8bits/byte=58.6MB Block-size (again assuming one hop). At about 300 bytes per transaction (many transactions are larger), that works out to about 195 thousand transactions per block.

Ever heard of "headers first" ?

In other words, people will naturally stop using Bitcoin to buy snacks/coffee.

Fine with me.

[WindMaster]

I wasn't following it closely (and was a little disgusted) but as I recall, all lukedashjr did was mine for a while then quite and it had a devastating impact on whatever coin it was.  Hell, the same thing could happen to Bitcoin without any attack if the price drops steeply or suddenly (but that could never happen, right?) and/or a few large clusters were molested.  I'll call this an 'Invisible hand of Adam Smith lukedashjr Attack.'  Maybe the adjustment algorithms have been patched up to preclude this, but I doubt it...such things occurring proactively seem rare in Bitcoinland.

Well, perhaps if by "mine for a while", you mean "51% the coin while excluding anyone's transactions from the mined blocks", then that would be pretty close to what happened (if I remember correctly).

[hack_]

Ever heard of "headers first" ?

Can you explain that please i don't really get the concept.

[waaat?]

Can someone explain again why it's not a free market selfregulating process? And why we need a bigger blockchain before we need it?

By doing this you end up with central control over txfees and will have to make them fixed and rising later. I don't see the point in responding to things that aren't even an issue yet.

Can someone also please explain to me why something needs to be done before something needs to be done?

[davout]

Well, perhaps if by "mine for a while", you mean "51% the coin while excluding anyone's transactions from the mined blocks", then that would be pretty close to what happened (if I remember correctly).

Totally not.
With a 51% attack you can at most make half the blocks empty, not "exclude anyone's toes from mined blocks".
What he did was perform a 10000% attack, had the difficulty adjust, and then left. What that does, and why that's hardly possible with Bitcoin is left as an exercise for the reader.

Can you explain that please i don't really get the concept.

You send the headers first, and the actual contents of the block later.

[WindMaster]

Well, perhaps if by "mine for a while", you mean "51% the coin while excluding anyone's transactions from the mined blocks", then that would be pretty close to what happened (if I remember correctly).

Totally not.
With a 51% attack you can at most make half the blocks empty, not "exclude anyone's toes from mined blocks".

Nonsense.  If you simply ignore everyone else's blocks, you can make *every* block empty as long as you have at least slightly more hashrate than everyone else, by mining your own blockchain in isolation from the network and leaking it out to the other nodes.  If you have at least slightly more hashrate than everyone else, eventually your blockchain (with every block empty) will win.

Mining on top of other blocks found by other miners would pretty much defeat the purpose of a 51% attack.  That would certainly be "amateur night at the 51% party."  A correctly executed 51% attack mines on top of the attacker's own blocks, so they can override everyone else's blocks when their alternative blockchain with a higher chain trust is introduced to the network.

[davout]

Nonsense.  If you simply ignore everyone else's blocks, you can make *every* block empty as long as you have at least slightly more hashrate than everyone else, by mining your own blockchain in isolation from the network and leaking it out to the other nodes.  If you have at least slightly more hashrate than everyone else, eventually your blockchain (with every block empty) will win.

Mining on top of other blocks found by other miners would pretty much defeat the purpose of a 51% attack.  That would certainly be "amateur night at the 51% party."  A correctly executed 51% attack mines on top of the attacker's own blocks, so they can override everyone else's blocks when their alternative blockchain with a higher chain trust is introduced to the network.

Hah. You're right.

[xDan]

Is there any good unbiased and reasonable (HAHAHA!) summary of the arguments for and against?

MPex's modus operandi seems to be having a high opinion of himself, calling people names, and wailing. If he has a point to make, he hides it very well behind a lot of bluster.

Having a single, open, payment network that can do everything (including small transactions) is the idealistic Bitcoin dream.

[cellard]

Can someone explain again why it's not a free market selfregulating process? And why we need a bigger blockchain before we need it?

By doing this you end up with central control over txfees and will have to make them fixed and rising later. I don't see the point in responding to things that aren't even an issue yet.

Can someone also please explain to me why something needs to be done before something needs to be done?

Just do the math. if Bitcoin goes mainstream (as mainstream as say, credit cards) it will not be able to deal with so many transactions per second without bad consequences such as bloat, slowness and whatnot. So we need to think before the problem actually happens.

[Rampion]

I'm really puzzled/shocked by Gavin's new blog post:

People want to maximize the price paid to miners as fees when the block reward drops to zero-- or, at least, have some assurance that there is enough diverse mining to protect the chain against potential attackers.

And people believe the way to accomplish that is to artificially limit the number of transactions below the technical capabilities of the network.

But production quotas don't work. Limit the number of transactions that can happen on the Bitcoin blockchain, and instead of paying higher fees people will perform their transactions somewhere else. I have no idea whether that would be Western Union, an alt-coin, a sidechain, or good old fashioned SWIFT wire transfers, but I do know that nobody besides a central government can force people to use product with higher costs, if there is a lower-cost option available.

So how will blockchain security get paid for in the future?

I honestly don't know.

For the uneducated: a production quota is just a limit to production used to control the supply of a certain good.

So, Gavin: isn't the hard limit to 21M bitcoins a production quota? YES IT IS. So now "production quotas" do not work?

What's next, will you argue in the future that we should increase the Bitcoin supply to 210M simply because "production quotas don't work"?

Wow. Just wow.

[Flashman]

Thoughts from 2013 (Outside the current emo-drama) ...

http://blog.oleganza.com/post/43677417318/economics-of-block-size-limit

Can any members of the self appointed Plutocratic League for Ending Bitcoins Servicability please provide references to any post of Satoshi's that emphatically states that the block size is intended to be a hard limit? ... annnnd don't do a cut and paste cherry pick, link it so we see it in context.

[davout]

Thoughts from 2013 (Outside the current emo-drama) ...

http://blog.oleganza.com/post/43677417318/economics-of-block-size-limit

Can any members of the self appointed Plutocratic League for Ending Bitcoins Servicability please provide references to any post of Satoshi's that emphatically states that the block size is intended to be a hard limit? ... annnnd don't do a cut and paste cherry pick, link it so we see it in context.

He put the limit in the source code.
It's up to you to find a quote of him suggesting it'd have to be removed.

[Rampion]

He put the limit in the source code.
It's up to you to find a quote of him suggesting it'd have to be removed.

This.

Furthermore, I think this is the most interesting part of Oleg's post:

If the miners hit the block limit, it would only mean one thing: there is a desire to process more transactions, but historical untested agreement does not allow it. Then miners and other full nodes will either raise the limit (the smaller the increment, the bigger support it will have), or transaction fees will go up as people compete for the space in blocks. As transaction fees go up, not only miners, but also regular users and service companies using the full blockchain would desire increment of the limit. So it will be even easier to achieve a consensus about raising the limit.

My prediction is that the block size limit will probably never be abolished, but will be constantly pushed up by a factor of two as amount of transactions approaches the limit.

In other words, there's no need to fix what is not broken. When and if the block size limit is hit and transactions start competing for block space, resulting in transaction fees going up, we can discuss about doubling the block size limit just because, probably, the market will ask for it. The key word here is *probably*: you need to hit such limit to see if the market prefers bigger blocks or higher fees. On that matter I agree with Oleg and I think the market will push for biggers blocks and more transactions, but anyhow it is something that has to be seen when such limit is hit.

What is completely ridiculous is to arbitrarily decide to increase the block size limit by a factor of 20 (!!!!!) just because "production quotas do not work", as Gavin suggests in his last blog post.

I'd really like to hear his position about the main "production quota" in bitcoin: the hard limit in the money supply (max. 21M Bitcoin). Maybe his next proposal is to increase it to 210 million bitcoin because, you know, "production quotas do not work".

[thelibertycap]

does anybody think bitcoin has high fees?

this for would bring even more centralization to bitcoin. larger storage requirements, bigger node network traffic because microtransactions will be possible with ultra low fees - any other changes?

does anybody think bitcoin is too centralized already?
I do.

well, I don't think that we can agree on one solution to fit us all. Thus until there is not a real need and consensus to do the change, why bother?

if you believe a change is necessary, fork it hard and put a catchy name like Gavincoin FTW on it!

[Flashman]

Evidence for the intention of Satoshi not to regard block size as a hard limit...

Currently, paying a fee is controlled manually with the -paytxfee switch.  It would be very easy to make the software automatically check the size of recent blocks to see if it should pay a fee.  We're so far from reaching the threshold, we don't need that yet.  It's a good idea to see how things go with controlling it manually first anyway.

It's not a big deal if we reach the threshold.  Free transactions would just take longer to get into a block.

I did a rough tally of 4000 blocks from around 74000-78000.  This is excluding the block reward transactions:

There were average 2 transactions per block, 17 transactions per hour, 400 transactions per day.

Average transaction bytes per block was 428 bytes, or 214 bytes per transaction.

The current threshold is 200KB per block, or about 1000 transactions per block.  I think it should be lowered to 50KB per block.  That would still be more than 100 times the average transactions per block.

The threshold can easily be changed in the future.  We can decide to increase it when the time comes.  It's a good idea to keep it lower as a circuit breaker and increase it as needed.  If we hit the threshold now, it would almost certainly be some kind of flood and not actual use.  Keeping the threshold lower would help limit the amount of wasted disk space in that event.

My bold highlighting

[waaat?]

Can someone explain again why it's not a free market selfregulating process? And why we need a bigger blockchain before we need it?

By doing this you end up with central control over txfees and will have to make them fixed and rising later. I don't see the point in responding to things that aren't even an issue yet.

Can someone also please explain to me why something needs to be done before something needs to be done?

Just do the math. if Bitcoin goes mainstream (as mainstream as say, credit cards) it will not be able to deal with so many transactions per second without bad consequences such as bloat, slowness and whatnot. So we need to think before the problem actually happens.

IF bitcoin goes mainsteam. It didn't do that so far ... it's all hypothetical pipedream dancing in the sky.

How about Mr. Andresen gets his stuff ready and tested and worked out nicely and has it ready when there is an actual demand for it instead of fucking around like that?

Did he adress the difficulty retargeting which is actually the more popular topic in the community right now? Did he?

What is his take on the exponential growth not holding up? Did he make a statement? It's relevant too because it makes bitcoin look clownish (ponzi-like) with the current price, high inflation and collapsing hashrate. It looks pretty dead to me, disintegrating. Like a fundamental fail tbh. Reward curve was shit. Inflation was never good because it's destructive for the market. I think the evidence is in the charts!

In case it doesn't rebound, the point was correct, this fork was bogus to propose because: no fully justified demand currently

In case you hardfork it, you hardfork it ONCE and when you have to, not twice a year when you feel like it and it appears to be 'maybe useful in the future'. Hardforking ahead of demand and for future planning opens doors for abuse!
Sometimes these mega brains need to be told the simple stuff!

[Rampion]

collapsing hashrate

Collapsing hashrate? The hash-rate at the last difficulty re-target (12/01) was 314,761,417 GH/s - the higher hashrate we ever had. Please point out some hard numbers (taking into account variance) that supports your "collapsing hashrate" theory.