Gold collapsing. Bitcoin UP.

[Peter R]

Imagine Bitcoin adoption occurs and 1BTC = $1,000,000. This means the smallest transaction fee is 1 cent. Now imagine 2 billion people making 5 transactions per day. That's $100,000,000 of security!

Ok ok fees could be paid out-of-band or Bitcoin could be modified to add more digits. But even still, and even if you assume the marginal cost of adding another transaction is _exactly_ zero, equilibrium transaction fees would still not be zero when the block reward runs out. If fees were zero then no one would mine, and transactions would never confirm! So fees at least have to be infinitesimal.

So now imagine everyone paying infinitesimal fees and some miners are making an infinitesimal profit with their infinitesimal hash power. Someone who actually understands economics will come along and say "I can mine 99% of the blocks for next to nothing since difficulty is so low. And I won't include any transaction that pay less than $0.02." So now you either pay $0.02 or wait 990 minutes to be included for a lower fee. Most people pay $0.02.

Voila: equilibrium fees are neither zero nor approaching zero.

(You can keep iterating saying that the other miners increase their hash power too to take advantage of the higher fees, but the point is that a market will still exist and fees won't fall to the marginal cost.)

 

[jonny1000]

I think what's driving the complaints in this thread is that you're not distinguishing between a low block size, a high but fixed block size, and an uncapped block size. Although some people here disagree with you about mining incentives in an uncapped situation, I think you're right about that. Transaction fees will equal the marginal cost to include a transaction, which might result in fees that are too low to pay for adequate security.

Thankyou

However, this is a very different issue than whether we should have a low fixed cap or a high fixed cap. This "tragedy of the commons" situation can be avoided with a high fixed cap, and we can get the benefits of more throughput.

I totally agree. As I have repeated many times:

• Small blocks (e.g. 1MB) - I do not want this
• Large blocks (e.g. over 20MB, or a dynamic limit) - I do want this
• No limit or a limit so large fee market dynamics break down - I want to avoid this

The above means that blocks are eventually always full. I often hear rhetoric from the "large blockers" saying thinks like "full blocks are bad" or "we must avoid full blocks". In my view, full blocks are absolutely necessary. I am pleased you hopefully agree with me that we need full blocks. But do you not see why it is so important for the "small blockers" to win this war, from their point of view? if we lose, people like Roger Ver who want to stop full blocks could be in control. The blocksize would then get larger and larger and fee markets may not work. We have to show we can successfully defend a blocksize limit, then increase it.

If you read my why I support BIP100 post, I talk about a technical limitation of 1TB blocks and miners imposing an economic restriction of 2GB blocks (in 2035). I doubt this type of vision is any less aggressive than you guys. But many have been fearful buy the non full block rhetoric, which means we must show we can keep blocks full, as at some point this will be necessary.

I think the main issue with your site is that you don't distinguish between a high fixed block size cap, vs. no cap. To be fair, it's hard to make this distinction with only two axis. Still, I'd remove the 'robustness' labels since I think they're misleading.

Agreed. Label removed

What you should be saying is "if there is no block size cap", not "if the mining industry is competitive."

I reworded. I said if there is "no economically relevant blocksize cap". I kept the competitive comment in there, if the mining industry has a cartel like structure, they can keep fees high.

"there will be no fee subsidy" to "fees might not be enough to pay for adequate security." It's very unlikely that fee income would actually be zero with no block size limit.

By subsidy, I mean a kind of cross payment from what fees are being paid for, to network security. As a "small blocker", I see a mismatch here. I see fees paying for space in blocks, while this is a different thing to hashing. Many here, do not see this mismatch, and think its like paying for any other service and a free market will work.

I know small blockers see rule by the market as "mob rule", but as I describe here, market governance is very different from mob rule.

I do not see market = mob rule. The mob rule was put in as a trigger word, to try and get peoples political views

You can keep iterating saying that the other miners increase their hash power too to take advantage of the higher fees, but the point is that a market will still exist and fees won't fall to the marginal cost.

Who is saying that?

 

[AdrianX]

• No limit or a limit so large fee market dynamics break down - I want to avoid this

@jonny1000

You need to explain how the market breaks down while we have a security subsidy?

Do you believe the research data that says the network can handle 4MB to be wrong and the network could handle a limit above your 20MB preference?

Do we need centralized planners to enforce limits why not trust the market?

You're compass is promoting a limit and favoring the 1MB limit.

I'm not convinced you understand the impact of the UASF.

You need to explain to me how BIP148 tokens are or will be fungible with BTC on the existing network today?

How is it you're more tolerate of a UASF that moving the limit a UASF use an address format that bitcoin nodes dont recognize as a bitcoin address?

In contrast BU always follow the longest bitcoin chain and you've devised unlikely cenarios that will fork it and here we have a UASF a hard fork that's somehow acceptable. What am I missingn?

 

[Peter R]

Peter R said:

"You can keep iterating saying that the other miners increase their hash power too to take advantage of the higher fees, but the point is that a market will still exist and fees won't fall to the marginal cost.

Who is saying that?

I'm saying it. After the miner deploys sufficient hash power to mine 99% of all blocks and raise transaction fees, the other miners will then deploy more hash power to benefit from these fees, and so on and so forth.

The "perfect competition" model will never apply to Bitcoin mining when the block reward runs out (and probably doesn't apply ever). This is really easy to see too:

• For perfect competition, you need a large number of producers.
• If you have perfect competition, fees will fall close to zero.
• If fees fall close to zero, difficultly will be very low.
• If difficulty is very low, it will be inexpensive for an entity to corner the block-space market.
• The "large number of producers" assumption breaks.
• An entity that corners the market can raise fees by demanding a minimum fee for next-block service.
• This increases profits for the remaining 1% small producers, who then increase their hash power thereby further increasing network difficulty.

The bottom line is that if network difficulty were ever extremely low, then it would be easy to corner the block space market and drive up fees. The equilibrium that emerges then is not one of perfect competition, but of some curious balance of "enough competition."

 

[jonny1000]

You need to explain how the market breaks down while we have a security subsidy?

This logic only applies when the fee subsidy is low. It will be 3.125 BTC in a few years, so we are almost there

Do you believe the research data that says the network can handle 4MB to be wrong and the network could handle a limit above your 20MB preference?

I think, technically speaking, if we solve various issues like the quadratic scaling of sighash operations, we can safely get well over 4MB blocks. For example 20MB seems ok to me. This is why SegWit is very important, as the faster we can switch people over to transaction formats with the linear scaling of sighash operations, the faster we can get much larger blocks.

Do we need centralized planners to enforce limits why not trust the market?

Markets are certainly way better than central planners. I really hope we do not have central planners. As for the blocksize limit, I prefer a dynamic solution. Although, if we regularly allow markets to change the consensus rules, in an uncertain period, by having two coins trade side by side, Bitcoin may not function as effective money. Therefore in the future we should avoid this. Of course, if there are two coins, one with an asymmetric advantage, I think the coin with the asymmetric advantage will resoundingly win, and the "market" would barely have a chance. This is why I keep asking BU to remove the asymmetric advantage for Core, and give markets a chance. At the moment, Core's advantage is so strong, markets do not have a choice to chose BU.

You're compass is promoting a limit and favoring the 1MB limit.

No it is not. Over 95% of respondents want a higher limit

You need to explain to me how BIP148 tokens are or will be fungible with BTC on the existing network today?

I do not support BIP148

However, with BIP148, if there is greater c51% miner support, then there will not be a chansplit. In contrast, with BU, if there is 51% to c98% support, there will be two chains.

How is it you're more tolerate of a UASF that moving the limit a UASF use an address format that bitcoin nodes dont recognize as a bitcoin address?

Sorry. I do not understand this question

In contrast BU always follow the longest bitcoin chain and you've devised unlikely cenarios that will fork it and here we have a UASF a hard fork that's somehow acceptable. What am I missingn?

BU does NOT always follow the longest chain. Perhaps you mean always follows the longest chain with respect to the blocksize? Even that is false, as it only applies if AD thresholds are breached.

Jihan has recently proposed a BU upgrade, which I strongly support, which would mean BU nodes require a certian block to be over 1MB. Therefore BU nodes will not always follow the longest chain with respect to the blocksize. This is what I mean by this upgrade is inconsistent with the BU philosophy

The UASF is not a hardfork, it has something a HF can never have, which is the asymmetric advantage.

Do you see now why I am being pragmatic and not ideological? I may feel compelled to support BIP148 if it gets enough momentum, just because it will win. I do not want to back a losing side.

 

[Peter R]

"I do not support BIP148. However, with BIP148, if there is greater c51% miner support, then there will not be a chansplit. In contrast, with BU, if there is 51% to c98% support, there will be two chains." -- @jonny1000

This if false. A minority hash power can cause a chain split at any time. The difference is that with larger blocks, the minority must act to avoid a split, while with segwit the minority must act to cause a split.
[doublepost=1495381610][/doublepost]"Jihan has recently proposed a BU upgrade, which I strongly support, which would mean BU nodes require a certian block to be over 1MB. Therefore BU nodes will not always follow the longest chain with respect to the blocksize. This is what I mean by this upgrade is inconsistent with the BU philosophy" -- @jonny1000

The BU philosophy is to give node operators and miners the tools they want, without forcing others to use them. If miners want a tool to prevent a re-org back to the small-block chain, I'm sure BU members will vote in favour.

Personally, I think such a tool makes sense in contentious times like this. The probability of a re-org back to the small block chain is:

P_lose = (q / p)^2

where q is the small-block hash power and p is the large-block hash power. Even with p = 75%, the probability of a reorg is 11%:

P_lose = (25% / 75%)^2 = 11%

If a re-org did happen, it might hurt miners' will to try again. It is better to ensure success on the first attempt.

 

[jonny1000]

This if false. A minority hash power can cause a chain split at any time.

Not with BU they can't... (Well at least until the AD thresholds are met)

where q is the small-block hash power and p is the large-block hash power. Even with p = 75%, the probability of a reorg is 11%:

Without the protection, with 75% hashrate, the probability of a re-org back to the smaller block chain is c33.3%. Not 11%. Your maths is simply wrong. You seem to ignore the asymmetric advantage in your maths.

See: https://www.reddit.com/r/Bitcoin/comments/5gevnc/why_a_75_threshold_may_not_be_sufficient_for_a/

This c33.3% figure, this is just a pure mathematical figure assuming the hashrate remains flat at 75% vs 25%. This is not realistic. In reality the miners cant switch. Miners will follow the market, the market will follow day traders and speculators. Speculators will back the asymmetric advantage.

This is why, I think c95% is necessary to be sure of ensuring no re-org occurs.

If a re-org did happen, it might hurt miners' will to try again. It is better to ensure success on the first attempt.

What is the point of going through this pain, when ordinary users could see their Bitcoin vanish from their wallets, damaging the reputation of the system, when it is not necessary?

It seems you agree with me now? Or am I still hated as a troll?

Lets make the hardfork decisive and resounding!! Lets stop this uncertain narrow victory nonsense.

 

[freetrader]

Do you see now why I am being pragmatic and not ideological? I may feel compelled to support BIP148 if it gets enough momentum, just because it will win. I do not want to back a losing side.

LOL yeah.


That political enough for you?

 

[Peter R]

Without the protection, with 75% hashrate, the probability of a re-org back to the smaller block chain is c33.3%. Not 11%. Your maths is simply wrong. You seem to ignore the asymmetric advantage in your maths.

See: https://www.reddit.com/r/Bitcoin/comments/5gevnc/why_a_75_threshold_may_not_be_sufficient_for_a/

This c33.3% figure, this is just a pure mathematical figure assuming the hashrate remains flat at 75% vs 25%.

I'm sorry @jonny1000 but my math is correct; it is yours that is wrong. The probability of a reorg back to the small block chain is:

P_lose = (q/p)^2

Upon the first big block mined, the big-block chain will be ahead by 1 block. To cause a re-org, the small block chain needs to not only catch-up, but to pull ahead by 1 block. This means they need to gain 2 blocks over the big-block chain, not 1. The equation that describes this is in the Bitcoin white paper:

P_lose = (q/p)^z

where z is the number of blocks the minority chain needs to "gain" over the majority chain. For our case, z=2.

If you don't believe me, simulate it. You'll confirm that the probability is 11% for p=75% (not 33%).

 

[Mengerian]

This logic only applies when the fee subsidy is low. It will be 3.125 BTC in a few years, so we are almost there

A subsidy of $3.125 Million per block doesn't seem low to me.

(presuming price rises to roughly $1 Million per coin with widespread adoption facilitated by massive on-chain scaling)

 

[jonny1000]

The equation that describes this is in the Bitcoin white paper:
P_lose = (q/p)^z

• 33% is the probability of the 25% catching up, starting from the creation of the larger block chain (In my view, the actual thing we are talking about)
• Using the approximate Satoshi formula in the whitepaper, when z=2, the probability of 25% overcoming a 2 block deficit is 31.5% (of course in this scenario the chain is secret, which makes it a bit different)
• 11% is the probability of the 25% catching up, given the 75% already has a two block lead.

(presuming price rises to roughly $1 Million per coin with widespread adoption facilitated by massive on-chain scaling)

One way of looking at security, is in proportion to system value, a higher Bitcoin price cannot help with that one

 

[lunar]

UASF bip 148

​

 

[Peter R]

33% is the probability of the 25% catching up, starting from the creation of the larger block chain (In my view, the actual thing we are talking about)

We are talking about the risk of the large-block chain re-orging back to the small block chain. For this to happen, the small block chain must become longer. This is not rocket science, @jonny1000.

11% is the probability of the 25% catching up, given the 75% already has a two block lead.

Yes. Which is the same as the probability of the 25% pulling one block ahead and causing a re-org when starting from 1 block behind. In other words, the precise conditions we're talking about.

Would you like to continue to argue that the probability of a re-org back to the small block chain is 33% when the big-block chain holds 75% of the hash power? Or would you like to shift the goal post and pretend that you were never talking about the large block chain re-orging back to the small block chain even though you clearly were (see below)?

 

[bluemoon]

Edit: Peter just covered this!

 

[jonny1000]

Would you like to continue to argue that the probability of a re-org back to the small block chain is 33% when the big-block chain holds 75% of the hash power?

No, its only 33% if the hashrate remains the same, as I have tried to explain many times, when you include the impact of the financial markets, I think even 95% is insufficient to do the hardfork. But this doesn't matter now right? Because after Jihan's comments I have won this stupid argument?

If you assume the smaller block chain need to be in the lead, and not just catch up, and the hashrate does not move, then sure the 33% becomes 11%.

The whitepaper talks about catching up/breakeven:

The probability of an attacker catching up from a given deficit is analogous to a Gambler's Ruin problem. Suppose a gambler with unlimited credit starts at a deficit and plays potentially an infinite number of trials to try to reach breakeven. We can calculate the probability he ever reaches breakeven, or that an attacker ever catches up with the honest chain, as follows

Lots of well known "smaller blockers" like theymos, Luke-Jr and Gmaxwell did the survey. Are any well known "large blockers" willing to do it?

 

[freetrader]

I am raising the issue of the "sticky gate" again by way of BUIP059 which proposes to make it optional and disable it by default.

The sticky gate was IMHO a feature which did not inspire confidence in the Emergent Consensus algorithm proposed by BU, and its mandated effect was included to amplify the theorized 'Median EB attack'.

While I lean toward the opinion that the Median EB attack is indeed speculative and would not work out as described in the real world, I would prefer that the BU client offers an easier to understand and harder-to-attack mode (while keeping the sticky gate as an optional feature for those who think their use cases might benefit from it).

 

[satoshis_sockpuppet]

Anybody in the mood to write a pull request for core to allow users to freely set the blocksize limit for values < 1 MB?

Apparently giving users a choice is the new core paradigma (as long as it is a soft fork!!) and we all know that ~300 kB should be the current blocksize limit, so the users will force the miners to react on this pressing issue.

 

[awemany]

With the huge community consensus behind UASF, I wonder why no-one has made SegWit transactions yet. Given the economic incentives, the miners will surely refrain from "stealing" SegWit money.

Why are all the UASFers waiting for flag day, by the way? That's so centralized. Much more decentralized is to just go and activate it. You are the majority of the users, with miners and ecosystem and everyone behind you, so go ahead and do it!


/s

 

[satoshis_sockpuppet]

Maybe there actually is a chance to find enough idiots to do (at least timelocked for after uasf-flagday) SW transactions now to
1. show the big economic majority behind UASF
2. show confidence in the viability of the UASF chain and that miners will be forced to the UASF chain.

Ironically, each of these SW transactions would make it more interesting for a miner to not mine SW blocks and just get a higher block reward for themselves...

If there was a solution for decentralized consensus we might not have that problem!

 

[Mengerian]

One way of looking at security, is in proportion to system value, a higher Bitcoin price cannot help with that one

A better way of measuring security is relative to the transaction throughput that particular businesses or individuals wish to conduct.

In other words, if a business conducts $1 Million worth Bitcoin transactions per day, they would want network security to be some factor higher (such as $10 Million per day for example).

The best way (and I would argue the only plausible way) to achieve high network security relative to individual transactors, absent block subsidy, is to have a very high number of such transactors on the network, each paying a relatively small fee per transaction.