Scaling Bitcoin. Is consensus achievable?

[stdset]

At the time of this post there are about 60000/50MB unconfirmed transactions, total fees are about 100 BTC/24h. Meanwhile average Segwit support per last 144 blocks is around 20%.
We've heard arguments from both sides. Isn't it time now to listen to each other, understand and come to a compromise?
All of us want the same: growth of Bitcoin adoption.

Core team, your opinion, decisions have the heaviest weight. You are the smartest among opposing groups (I indeed think so). But don't you think that if you concede that Bitcoin needs bigger blocks, and that at least one hardfork is inevitable, it will lead to reconciliation and perhaps even acceptance of segwit as a softfork, do you?

Bigger blocks group, it's in your power to block segwit. But don't you think that if you indeed do so, you will strangle Bitcoin and all your investments in mining hardware and in Bitcoin will become worthless?

Currently segwit is the shortest path to increasing Bitcoin throughput. A hardfork needs to be well thought over and announced several months before taking effect. Let's be honest, it won't happen sooner than a year from now.

IMO:
1) There is no way of scaling Bitcoin short term except adopting segwit. Contentious hardfork isn't an option it would be disastrous.
2) Whether or not Segwit will be adopted in it's current form, Bitcoin needs bigger blocks. If we aim at going mainstream, 1MB isn't enough in spite of Segwit, LN, whatever. I beleive even 8MB would still be handleable for Bitcoin enthusiasts running full nodes, not to mention bigger entities such mining pools. I however hope that a solution for dynamic blocksize will be found, which will satisfy all parties.
3) Average total fees per block must remain much lower than block subsidy for more than a decade from now, because of mining energy consumption:

However, we can estimate Bitcoin mining power consumption in 12 years, provided that Bitcoin replaced all M1 money supply in the world, what is very unrealistic, but we want to make a conservative estimate. As of 2009 M1 was about 20*10¹²USD http://dont-tread-on.me/wp-content/uploads/2011/02/SmallGlobalMoneySupply.png
In 12 years block reward will be 8 times less than now, let's assume that fees still constitute a minor part of block reward, i.e. block reward is 3.125 BTC, that means 18.75 BTC created per hour. Value of 1 BTC equals roughly 1 million USD of 2009 purchasing power (in 2027 USD doesn't exist already, since BTC completely replaced it). Let's now assume, that miners spend half of their revenue to pay for electricity (that's rather unrealistic, but we want to make a conservative estimation), so we have 9.4*10⁶ USD per hour to pay for electricity. If we take a reasonable price of 0.07 USD/kWt*h, that results in 1.3*10¹¹ Watts of total power consumption by all miners in the world. In 2007 the world produced about 20*10¹⁵ Wt*h of electric power, or 2.3*10¹² Watts on the average. We can see that under such unrealistic conditions bitcoin mining consumes less than 6% of total world electric power.
Hope I didn't make a mistake in calculations.

BTW, we can conclude that even in 12 years Bitcoin is unlikely to replace all money in the world, since 6% of total electric power produced in the world is a bit much, I'd say that bitcoin will need not less than 16 years to achieve that  

And again, all of us want the same: Bitcoin adoption growth.

[1714615917]

1714615917

[kiklo]

Actually SegWit needs 95% of the Miner's Hash to be accepted ,
1 Mining Pool with 8% said they will block it in favor of a hard fork with larger block size.

You only need ~70% of the hash to have a successful hard fork, so it is odd SegWit is pushed for more.
(The Devs will probably make more money off of LN, which is why they prefer segwit.)
A Hard Fork is no Big Deal, Schedule the update a few weeks later after the software is ready .

BTC Transactions Congestion Problems   

Simulation Example
each block has 1 MB of transactions with a theoretical Limit of 4200 transactions per block with a 10 minute BlockSpeed , [] is a block
One Hour of Blocks
[1] 10 minutes [1] 10 minutes [1] 10 minutes [1] 10 minutes [1] 10 minutes [1] 10 minutes
6 Blocks * 4200 Transactions =  25200 Maximum Theoretical Transactions per Hour

BTC Transactions Congestion Solutions   

Simulation Example Updated with Larger BlockSize and Shorter BlockSpeed
each block has 2 MB of transactions with a theoretical Limit of 8400 transactions per block with a 2½ minute BlockSpeed , [] is a block
One Hour of Blocks
[2] 2½ minutes [2] 2½ minutes [2] 2½ minutes [2] 2½ minutes
[2] 2½ minutes [2] 2½ minutes [2] 2½ minutes [2] 2½ minutes
[2] 2½ minutes [2] 2½ minutes [2] 2½ minutes [2] 2½ minutes
[2] 2½ minutes [2] 2½ minutes [2] 2½ minutes [2] 2½ minutes
[2] 2½ minutes [2] 2½ minutes [2] 2½ minutes [2] 2½ minutes
[2] 2½ minutes [2] 2½ minutes [2] 2½ minutes [2] 2½ minutes

24 Blocks * 8400 Transactions = 201600 Maximum Theoretical Transactions per Hour

Compare Updated Simulation with Original
201600 / 25200  = 8
Updated Version can handle 8X the Transaction Capacity. 

Now the educated asshats that live in these forums will tell you it can't work or it is a security risk, (They are Lying!)
Real World Examples.
PoW coin LTC has a 2½ minute block time with no problems whatsoever from it.
In Fact Chinese Mining Pools are over 51% of the BTC Hash rate , and are also over 51% of the LTC Hashrate.
In Fact some alts run at a 30 second blockspeed.
Oh, they also will complain, it will affect the Block Reward and Halving Dates,
(All of that are Variables that can be modified to compensate for the changes)

If they lower the Blockspeed,
then they will have to increase the Final Supply Number of Bitcoins or allow it to get to the Final Supply Number 4X faster than it would have.

If they only increase the BlockSize ,
then the Block rewards and halving dates are not affected, and will not need modification.
But Transactions grow will be directly proportional to the increase in BlockSize.
IE: 2 MB Block only Double the Transaction Capacity
     8 MB Blocks would increase by 8X also   

 

FYI: Reference Links

https://bitcoinmagazine.com/articles/why-viabtc-rejects-segwit-soft-fork-in-favor-of-block-size-hard-fork-interview-with-haipo-yang-1479409475

Instead, the mining pool favors a hard fork to remove the one megabyte block size limit, as proposed by Bitcoin Core fork Bitcoin Unlimited.

http://www.coindesk.com/lower-bitcoin-block-time-scale/

Using data pulled from their open source simulator of a proof-of-work blockchain (bitcoin and ethereum are two such blockchains), researchers from ETH Zürich argued that bitcoin could securely reduce its block time from 10 to 1 minute.

[Carlton Banks]

Yes, but Segwit increases the blocksize anyway. Which appears to be your point "blocksize needs an increase". Seems like a circular argument to me.

[Senor.Bla]

i guess there are different people with different aims involved. many have invested a large sum of money and they want to make money with bitcoin so they push in the most profitable direction and that is not what is best for the technology. i would prefer to see a good solution so that bitcoin is technological in a solid position. even if this means a huge price fall. easy for me to say as i am not invested to much in it. but i think it would be the smart thing to do if you have the long perspective in mind. i do not see this happening, so a crooked compromise that still works will probably be it. still better then a couple of different bitcoin version due to forks.

[stdset]

You only need ~70% of the hash to have a successful hard fork, so it is odd SegWit is pushed for more.

Hardforks don't depend on hashpower, you can hardfork off Bitcoin with 1% of hashpower, provided that your hardfork will include difficulty adjustment algo change (otherwise it will take forever to mine several hundreds of blocks for next difficulty adjustment).

If you don't care about users, who can miss your announcement, forget to upgrade their software, then indeed

A Hard Fork is no Big Deal, Schedule the update a few weeks later after the software is ready .

[kiklo]

Yes, but Segwit increases the blocksize anyway. Which appears to be your point "blocksize needs an increase". Seems like a circular argument to me.

One of its many technical improvements is the ability to fit almost 2MB of transactions per block. Many estimates put the total block size, with SegWit, at about 1.7mb.

1.  2mb is higher the 1.7mb (And that is only a doubling of current transaction limits)

2. The Mining Pools have stated they are blocking segwit.
After 1 year if 95% have not updated Segwit Officially Fails

(Unless you can force the Mining Pools to update, segwit is probably not going to happen.)

Hard fork does not require 95% , only ~70% would be enough and the pools are already wanting to increase the size.
Plus Segwit and LN will fail, if the underlying BTC network can not keep up with transactions.

https://bitcoinmagazine.com/articles/here-s-how-bitcoin-s-lightning-network-could-fail-1467736127

The Lightning Network’s Failure Mode

The Lightning Network failure scenario described by Todd, takes place when a large number of people on the Bitcoin network need to settle their Lightning Network disputes on the blockchain in a relatively short period of time.

https://bitcoinmagazine.com/articles/here-s-how-bitcoin-s-lightning-network-could-fail-1467736127
“We do have a failure mode which is: Imagine a whole bunch of these [settlements] have to happen at once,” Todd explained. “There’s only so much data that can go through the bitcoin network and if we had a large number of Lightning channels get closed out very rapidly, how are we going to get them all confirmed? At some point, you run out of capacity.”

In a scenario where a large number of people need to settle their Lightning contracts on the blockchain, the price for doing so could increase substantially as the available space in bitcoin blocks becomes sparse. “At some point some people start losing out because the cost is just higher than what they can afford,” Todd said. “If you have a very large percentage of the network using Lightning, potentially this cost is very high. Potentially, we could get this mass outbreak of failure.”

No matter if SegWit & LN is activated next week, segwit will not give a 8X increase like my example, so it will likely crash within a year or two, unless the underlying structure is able to handle the load.

Example:
BTC is the Foundation of Building
SegWit , the 1st floor, and LN the Skyscraper on top of it,
If BTC crumbles because it can't handle the stress, SegWit & LN are going to come crashing down on top of it. 

 

[kiklo]

You only need ~70% of the hash to have a successful hard fork, so it is odd SegWit is pushed for more.

Hardforks don't depend on hashpower, you can hardfork off Bitcoin with 1% of hashpower, provided that your hardfork will include difficulty adjustment algo change (otherwise it will take forever to mine several hundreds of blocks for next difficulty adjustment).

If you don't care about users, who can miss your announcement, forget to upgrade their software, then indeed

A Hard Fork is no Big Deal, Schedule the update a few weeks later after the software is ready .

Nope,
Reason:
It has to be close to 70% to make sure your network is still secure, otherwise the other group can 51% attack you all day and block all transactions.

Make a Big Press Release , Call the Largest Mining Pools by Phone to confirm they are ready.
Trying to make out like a hard fork is so hard is BS, it is not.
Make some phone calls, send some email, or even broadcast a alert message out to all wallets, it ain't hard.
https://bitcointalk.org/index.php?topic=898.0;all

 

[stdset]

Example:
BTC is the Foundation of Building
SegWit , the 1st floor, and LN the Skyscraper on top of it,
If BTC crumbles because it can't handle the stress, SegWit & LN are going to come crashing down on top of it. 

That's why it's better to ponder the bigger blocks hardfork very well before implementing it. Bitcoin needs dynamic blocksize to be able to handle LN failure mode described in the article. There are some solutions proposed, for instance Meni Rosenfeld's.

[stdset]

Nope,
Reason:
It has to be close to 70% to make sure your network is still secure, otherwise the other group can 51% attack you all day and block all transactions.

ETC is still alive despite they had maybe 10% of the prefork hashpower. Also, if your hardfork is such a minority fork, you can change PoW algo.

Make a Big Press Release , Call the Largest Mining Pools by Phone to confirm they are ready.
Trying to make out like a hard fork is so hard is BS, it is not.
Make some phone calls, send some email, or even broadcast a alert message out to all wallets, it ain't hard.

Imagine a user who doesn't follow all this mess. He turns on his client say a month after the fork to receive a payment but receives worthless original chain coins. He won't be able to spend them, unless he finds somebody as unaware as he is.

[kiklo]

Nope,
Reason:
It has to be close to 70% to make sure your network is still secure, otherwise the other group can 51% attack you all day and block all transactions.

ETC is still alive despite they had maybe 10% of the prefork hashpower. Also, if your hardfork is such a minority fork, you can change PoW algo.

I doubt anyone wants to have wasted all of the money spent on ASICS.
Also for all you know they have more mining capacity of the other Algo too.
FYI: Message on Poloniex   (Safer with 70%)  
ETC withdrawal and deposits are disabled due to network issues.
Posted by OldManKidd at 2016-11-24 02:04:11

Make a Big Press Release , Call the Largest Mining Pools by Phone to confirm they are ready.
Trying to make out like a hard fork is so hard is BS, it is not.
Make some phone calls, send some email, or even broadcast a alert message out to all wallets, it ain't hard.

Imagine a user who doesn't follow all this mess. He turns on his client say a month after the fork to receive a payment but receives worthless original chain coins. He won't be able to spend them, unless he finds somebody as unaware as he is.

If Miners don't keep up with the updates , that is on them, you can not hold back an entire community because one guy won't watch the news or check an email.
Otherwise we all still be living in caves.

 

[franky1]

firstly although segwit increases the amount of possible future BLOAT (megabytes of data) to 4mb.. the UTILITY!!!! of that bloat is not 4x capacity/scalability

what has been asked by the community is the UTILITY of the blocksize to increase.

so while core thinks 4mb is safe bloat.. then the obvious action is
2mb base 4mb weight to get proper UTILITY of the blocksize and segwit both at same time

we all know that core want 1.8mb for complete transaction data, and call that the compromise. but that 2.2mb of spare buffer will be used for arbitrary data for other features, and not lean clean transactions.

core havnt even bothered to put in rules to stop people writing messages in the transactions. meaning that 2.2mb a block could end up being filled up with crappy messages.

if core stopped with the "it takes months to announce a consensus" yet they themselves made an october announcement for a mid november pool consensus with hopes for activation by christmas!!!

now here is the trick..
go back to last years "promises" made at the scaling bitcoin. where dynamic blocks were part of the segwit plan.

that way everyone is happy
not this bait and switch
here have 4mb ... but have it as:
Xmb base Xmb weight dynamically adaptable via consensus
beginning with default of 2mb base 4mb weight for clean, lean transactions and only 0.4mb for arbitrary bloat

NOT

1mb base(limit scaling)+0.8mb witness(move signatures as 'compromise' side effect one time increase)+2.2mb arbitrary data(bloat)=4mb weight

that way everyone is happy

[kiklo]

Example:
BTC is the Foundation of Building
SegWit , the 1st floor, and LN the Skyscraper on top of it,
If BTC crumbles because it can't handle the stress, SegWit & LN are going to come crashing down on top of it. 

That's why it's better to ponder the bigger blocks hardfork very well before implementing it. Bitcoin needs dynamic blocksize to be able to handle LN failure mode described in the article. There are some solutions proposed, for instance Meni Rosenfeld's.

Problem is not enough transactions capacity, personally I would not penalize the Miner that used the Larger Blocks, he is actually doing the network a better service.
If anyone had to be penalized , it should be the miner that only adds a few transactions , because he basically wasted the capacity of that block when the queue transactions are over 2000.

Just put a limit on the max size of the blocks, because internet bandwith and communications with other nodes is going to be a limiting factor on block size.
(Unlimited block size without unlimited Bandwith, is not going to work well.)

It is not like BTC core can't set up a testnet and test which block sizes work best with nodes of varying bandwidth to determine a maximum size limit.
(As the internet improves and demands increase , they can reevaluate at those times)

 

[stdset]

I would not penalize the Miner that used the Larger Blocks, he is actually doing the network a better service.

It's easy to DoS your Bitcoin then, especially if you are a miner. Just send tons of transactions to yourself, pay fees to yourself, make 20 GB blocks. Bloat the chain.

it should be the miner that only adds a few transactions , because he basically wasted the capacity of that block when the queue transactions are over 2000.

What if there are just few unconfirmed transactions around? Are you going to penalize a miner who includes them in a block?

[stdset]

Also for all you know they have more mining capacity of the other Algo too.

What do you mean by "the other Algo"? I know many other algos, and much more could be "invented".

If Miners don't keep up with the updates , that is on them, you can not hold back an entire community because one guy won't watch the news or check an email.
Otherwise we all still be living in caves.[/color]

I guess you mentioned miners because the original chain needs to be mined, in order for our unaware user to receive the payment. You don't need many of them however, 1 block in several hours could be enough, users need not to be technical savvy.

[kiklo]

I would not penalize the Miner that used the Larger Blocks, he is actually doing the network a better service.

It's easy to DoS your Bitcoin then, especially if you are a miner. Just send tons of transactions to yourself, pay fees to yourself, make 20 GB blocks. Bloat the chain.

it should be the miner that only adds a few transactions , because he basically wasted the capacity of that block when the queue transactions are over 2000.

What if there are just few unconfirmed transactions around? Are you going to penalize a miner who includes them in a block?

That is why there should be a max cap on the size of the Block.
They need to pick a size between 2MB & 8MB for the Block size.
(You can get the same 8X increase, if you increase the block size to 8MB or increase the block size to 2 MB and decrease the Block Speed to 2.5 minutes.)
https://bitcointalk.org/index.php?topic=1691802.msg16975239#msg16975239

Chain Bloat is actually a separate issue and needs to have a separate answer.
More Transactions will take more space , no way around that.
Pruning was 1 option, for that issue. However a Running Genesis Block that dropped off the transactions that are over 7 years old would be my choice.

I think if their are over 2000 transactions in a queue and the miner only mines a block with 1 transaction, yes I would penalize him for wasting capacity,
but that is not my call and just my personal opinion.

 

[kiklo]

Also for all you know they have more mining capacity of the other Algo too.

What do you mean by "the other Algo"? I know many other algos, and much more could be "invented".

If Miners don't keep up with the updates , that is on them, you can not hold back an entire community because one guy won't watch the news or check an email.
Otherwise we all still be living in caves.[/color]

I guess you mentioned miners because the original chain needs to be mined, in order for our unaware user to receive the payment. You don't need many of them however, 1 block in several hours could be enough, users need not to be technical savvy.

Whatever Algo you come up with Scrypt, or X15 , odds are the Chinese (Largest Manufacturing Industry in the world) will be able to make more cheaper.
The only thing they can't dominate is Proof of Stake, which is why Theymos was trying to get a DPoS added to BTC PoW.

Majority of BTC users are letting someone else maintain their BTC wallets, the few that don't , will not lose anything if they are not mining.
(They will update when their old wallet does not work.)
If they are mining they should be keeping up with Github and BTC core.

 

FYI:
One Point to be clear on, if the Chinese Mining Pools refuse to update, since they have over 51% of the BTC mining,
No Changes can happen unless they agree to it. So no mater what we or BTC core decides , the final decision will be theirs to make.
Which is why Segwit will most likely fail unless they change their minds to support it.

Correction: There is one way to take the Choice away from the Mining Pools,
a Hard Fork to a completely 100% Proof of Stake coin, this puts the power directly in the hands of the coin owners and not the ASICS Owners.
Doubtful a PoW mining coin community would do that.

[stdset]

I think if their are over 2000 transactions in a queue and the miner only mines a block with 1 transaction, yes I would penalize him for wasting capacity,
but that is not my call and just my personal opinion.

You need to prove blockchainwise that the transactions were broadcasted before the block was mined. Additionally, what if our miner had network outage and didn't receive some transactions? I can't see how such penalizing system could be set up.

Majority of BTC users are letting someone else maintain their BTC wallets, the few that don't , will not lose anything if they are not mining.
(They will update when their old wallet does not work.)

How technical unsavvy user can tell whether his wallet works or not? Also, in the case of hardfork it's likely that there will remain at least several old nodes running worldwide, they will still function as if there was no fork, except new blocks will be very rarely found. Also, given present degree of discord, I would expect that there will remain may be small but frenetic group of original chain supporters.

[stdset]

More Transactions will take more space , no way around that.

LN

That is why there should be a max cap on the size of the Block.

With a hard cap and LN running over your chain, your coin is always prone to scenario described in the article you mentioned. Doesn't matter how big your blocks are: 2, 8 or even 20 MB, if Bitcoin goes mainstream, there could be an equilibrium when blocks are mostly full, say they are 90% full on average. Then, if too many LN channels will need to be closed simultaneously It will lead to failure, as described in the article. Blocksize needs to be dynamic. Blocks need to be stretchable, so that the chain is able to digest such sudden influx of transactions.
That's unless you imply there is a mechanism to keep your hard capped blocks half-empty most of time, in which case we are talking about more or less the same thing.

[Kprawn]

Have you considered that the " 60000/50MB unconfirmed transactions " have been artificially been created by someone to rush the

decision? We have seen this before, with the Core/XT battle. People spam the Blockchain over time, to create the perception that there

are a congestion problem. It costs them a ton of money, but they do these supposed "stress tests" any way.  ... Smoke & Mirrors

.. 

[DannyHamilton]

This stopped being a technical battle (and became a political battle) long ago.  At this point, it sure seems like consensus is impossible, at least until someone comes along that can change the conversation.  As long as there are a significant number of people on either side that feel like they've "failed" if the "other side gets what they want", consensus will be impossible (as there will be a significant number of people that will try to outlast the "other side" and force them to give up).

"Do it my way, or I'll destroy us both" can be a very effective strategy if one side is significantly more committed to their beliefs and would rather have the whole thing come tumbling down than let "the other guy win".  But if both sides have enough people that feel that way, the end result can be stagnation for a VERY long time.

For that matter, it is entirely possible that there is an influential group of individuals that want bitcoin to fail and believe they can eventually crash the value of bitcoin by holding out against BOTH sides.