Gold collapsing. Bitcoin UP.

VeritasSapere

Active Member
Nov 16, 2015
511
1,266
Someone here keeps posting that I'm confusing miners with mining pools, and that this is significant because a small miner can join a pool and then have an orphan rate that is shared with the whole pool.
I suspect you are probably referring to me, I do tend to stress the definition between miners and pools. Your description of my argument is accurate.

The first is that if the miner has joined a pool, they are no longer in control of the transactions they are mining. Even with GBT, the pool is a centralized source of power, and can always choose to implement something different, forcing the miner to either accept the change or switch pools.
More then seventy percent of the hashpower is currently in public pools, if we want there to be more decentralization we would want the pools to have more of this hashpower, since the other thirty percent is represented by companies like Bitfury, KNC, 21inc, which are the only type of mining operations that do not need to pool their hashpower in order to counter variance.

It is true that a pool is a centralized form of power, however when the hashpower is represented by 10-20 pools like it is today then that power is in effect distributed. I have even said that I think that the relationship between the pools and the miners are like a representative democracy, the important difference being to state democracies, is that the miners can switch pools in a matter of seconds, and there is a high degree of transparency. Furthermore the incentive mechanism acts upon the miners as well so that they will keep the best interests of the network in mind, after all this is the premise based on game theory that Bitcoin depends on for its continued operation. So in many ways this form of proof of work representative democracy is superior when compared to the state democracies of today, solving several of the key problems related to governance.

It is true that pools can act maliciously and it may take some time for the word to spread and miners to leave, this does happen though, the incentive mechanism works. Ghash is actually a great example of this, they approached fifty percent of the hashpower and acted maliciously, look at where they are now, they have less then one percent of the hashpower and their reputation has been ruined. I do not think that miners would presently allow any one pool to grow larger then thirty percent because of the advancements in our understanding of these dangers. This is important because of the introduction of pools, the new game theory dynamics of Bitcoin actually depends on it.

Since these pools will not grow above this size it does make the attack vector that you mention implausible, since other pools would not mine on top of such large blocks effectively blocking this attack, such an attack would also be very expensive and with everything considered irrational. Unless the majority of the hashpower was controlled by a singular malicious entity, that would be a form of dangerous mining centralization, however if that did happen it would in effect break Bitcoin, if that did happen some of the underlying concepts will have proven itself to be flawed. However the proof of work, game theory and incentive mechanism are all designed to prevent this from happening in the first place.

And if blocks are larger than you can process quickly, you spend much of your time mining a template that you haven't confirmed or chosen because you are still figuring out the block that you are mining on top of.
This news of the pools acting maliciously will most likely spread through media channels, we also have block explorers as well, which will also have connections to capable full nodes. I also think that these 10-30 pools will be able to play on a relatively even playing field for the most part in terms of connection, since they will all be capable of hosting full nodes in datacenters anywhere in the world. I used Slush as an example previously, I doubt that pools like Slush will not be able to compete with the other pools in terms of connection, not that I think that this would matter for the reasons I already explained, but for the sake of argument this is another point that does go against your theory.

The second, and bigger problem, is that miners on pools experience higher orphan rates than miners not on pools. This is because all of the miners inside the pool still have to communicate to the central server, and the central server still needs to communicate to all the connected miners every block, and this takes time. At a single giant datacenter, this isn't the case. Propagation within a datacenter is going to be single digit milliseconds at worst.
This would not happen for the reasons that I have already explained. Miners would not completely undermine the value proposition of Bitcoin by centralizing all hashpower in one pool. This could also not happen through this attack vector you mention because miners would not allow any one pool to grow to that large in the first place.

The relay network can move blocks around in something like 300ms on the current network. But the average stratum pool does not get the first block template to its miners for something closer to 5 seconds. A massive disparity, and one that means that mining on a pool is significantly slower than mining from the relay network.
I do not think it is accurate that solo mining is more profitable compared to pooled mining, as far as I understand it should be exactly the same not including the pool fee of course, though someone please correct me if I am wrong, I did look it up again and the results did seem to confirm this. These 5 seconds are not actually a big deal for the individual miners that are connected to the pool, this is why it is possible to do pooled mining with a very slow internet connection as long as it is reliable. Since actually solving this cryptographic puzzle is very rare for the individual miners, and their hashes during these five seconds still get counted by the pool, so for the individual miners this would not make any difference at all in terms of profit.

You cannot assume that large pools will be able to compete with large datacenters.
Large pools are obviously all already in datacentres or datacentre type structures. If I understand you correctly you think that BU would lead to the hashrate all becoming concentrated into one pool or that all pools will be concentrated into a single datacentre? This as I have already explained would not happen, and this is not an assumption. Bitcoin has proven this over the last six years, that the incentive mechanism works. This is the premise that Bitcoins very existence relies on, of course this premise could prove itself flawed, but until it does I would like this aspect of the experiment to run its course, if we did not believe in the validity of this presumption, I would question the interest we have in Bitcoin. The incentive mechanism acts upon the miners, it is the miners that have all of the power in this relationship, the pools serve the miners by acting as the representatives for the miners and as soon as they misbehave we can change our votes.

I think that we are all still in the process of discovering what the governance mechanism of Bitcoin is. This blocksize debate has brought it above the surface and we are going through somewhat of a political awakening at this time, I could even draw analogies to civil war and revolution. I think the ability to hard fork is important, it is the right to self determination. I can see that you do have the principles of decentralization and financial freedom at heart. I also would not want Bitcoin to become like paypall.

I suspect that the incentive mechanisms are acting on us in ways that we do not even understand yet. Some things are more clear then others however. I think that Bitcoin will change the world in profound ways, it will solve many problems, I suspect it will also introduce some new problems as well, and we might need to learn some of these things the hard way. Overall however I think that Bitcoin will do much more good compared to harm.

Thank you for your great constructive criticism, even though I might not agree, it is through this process that we can both reach a better understanding.
 
Last edited:

Mengerian

Moderator
Staff member
Aug 29, 2015
536
2,597
On Coffee and Houses

A meme that occasionally gets tossed around in the block size debate is that Bitcoin should not be used for “buying coffee”, but should instead be used for large transactions, like “buying houses”. I believe this dichotomy is mistaken. It seems generally understood that restricting block size will have the effect of removing the utility of transacting small amounts on the blockchain. But what is less widely appreciated is that smaller block sizes also reduce the ability to safely transact larger volumes of bitcoin.

The framework for this analysis is to consider a few parameters, and how they impact the cost and security of making Bitcoin transactions. At the low end, a practical minimum transaction value will be determined by transaction fees needed per transaction, and the transactor’s acceptable fee percentage (eg max 1% fee per transaction). At the high end, maximum practical value throughput per block will be limited by total miner revenue per block (block reward and the total transaction fees per block), and the transactor’s desired security level.

For example, currently block reward is 25 BTC per block, how much value would a given entity be comfortable transacting in Bitcoin on an ongoing basis? If a company is willing to trust Bitcoin for 25 BTC worth of value transferred per block, that works out to about $1.5 million in value per day. So a company that has cash flows greater than $1.5 million per day may not be comfortable using Bitcoin for this purpose.

But let’s consider the future scenario where block reward is negligible. Now all miner revenue has to come from transaction fees. What I will show is that limits on block size restrict the ratio between the smallest practical transaction, and maximum safe value throughput.

Variables:

Qt_max: block size limit in transactions per block
Ft: transaction fee per transaction
S: security ratio.
F_lim: maximum acceptable transaction fee percentage

Vt_max: Maximum value that an entity can transfer through the bitcoin network, in bitcoin per unit time
Vt_max = (Qt_max * Ft) / S

Vt_min: minimum value that an entity can transfer through the bitcoin network.
Vt_min = Ft / F_lim

B_v: Value bandwidth, this is the ratio between largest transaction throughput and smallest practical transaction
B_v = Vt_max / Vt_min = Qt_max * (F_lim / S)

In words: The range of values that can be practically transacted over the Bitcoin network will be limited by the block size limit, the percentage transaction fees the people are willing to pay, and the security level desired.

Let’s try an example and see what would happen with the current block size limit, and no block reward. Today block sizes are limited to 1MB, or roughly 2000 transaction per block, and the market transaction fee is about 0.0001 BTC per transaction. Value of bitcoin is about $400/BTC. If people are willing to accept a 1% transaction fee, and a security ratio of 1 then:

Vt_min = 0.0001 / 1% = 0.01

So the minimum practical transaction is currently 0.01 BTC, or $4 at current market price.

Vt_max = (2000 * 0.0001) / 1 = 0.2

So the maximum value throughput anyone would want to trust to the Bitcoin network is 0.2 BTC ($80) per block, or 28.8 BTC ($11,520) per day. To buy a $500,000 house, you would need to wait 43 days until the cost to double-spend your transaction is more than the value of the transaction.

B_v = Vt_max / Vt_min = 20

This means that with 1MB blocks, no block reward, and the parameters assumed above, the maximum amount of monetary value that can be effectively transferred through the Bitcoin network per block is about twenty time the minimum practical transaction.

If we imagine a scenario where transaction fees are higher, or bitcoin prices are higher, then the maximum secure throughput could be higher, but this would cut off low-value transaction. Conversely, another possible future with 1MB block size limit would be low transaction fees, low bitcoin value, and insufficient network security to secure large value flows.

Caveat: The framework presented here is very simplified. In reality there is a range of transaction sizes, fees, and other parameters. I also glossed over the concept of security ratio. It seems reasonable that the value that any entity would be willing to transact through the blockchain is related to the value of the proof-of-work that goes into securing it, but this concept could be expanded in a more comprehensive analysis.
 

Peter R

Well-Known Member
Aug 28, 2015
1,398
5,595
@Mengerian

You might have something here! I think the idea of "value bandwidth" could be very useful. For example, we could calculate a value bandwidth for various currencies and payment methods. A debit card (in Canada) might be useful from about $0.50 to $2500, a credit card from perhaps a few dollars to thousands of tens of thousands, bank wires from $10,000 to several million, and I have no idea how people make larger payments than that.

You could create a chart with a log-axis for value and plot the value ranges where each of these payment types are optimal (since your measuring bandwidth, the "width" of your band is constant regardless of where on the axis you move it to on a log axis).

For bitcoin to be as useful as possible, obviously we want its "value bandwidth" to cover as large a domain as practical, which you've shown means that it necessarily must have a large block size.

What I like about your formulation is that it applies whether we have a block size limit or not. Sure a block size limit might drive up fees, but that doesn't increase the value bandwidth...instead it just translates the "band" upwards towards the bigger-ticket items.

Need to think more about this...
 

Mengerian

Moderator
Staff member
Aug 29, 2015
536
2,597
@Peter R, Thanks! Yeah, it's a concept I've been mulling for a while.

In the long run, it has always seemed to me that Bitcoin needs to have low fees per transaction, but high total fees per block. This situation requires high transaction throughput per block.

The part I'm still trying to think through more is the relationship between the blockchain proof-of-work per time, and the secure transaction throughput. Should this throughput be measured per transaction, per customer you're dealing, or for a businesses total cash flow overall? I guess it depends on the threat model.

I also have a feeling that maximizing this "value bandwidth" is one of the key competitive advantages that Bitcoin can potentially have against alternatives. There is just so much utility in having a system that allows us to seamlessly transact a few dollars, or millions.
 

Windowly

Active Member
Dec 10, 2015
157
385
I've been tweeting to a few exchanges, wallet providers, developers etc asking them for their thoughts on bitcoin unlimited and pointing them to the faq page over at the website. I think (perhaps because of the rampant censorship and bullying) there isn't a lot of knowledge that this solution exists.
 

Mengerian

Moderator
Staff member
Aug 29, 2015
536
2,597
@theZerg
Oh, I meant to add a description for that, but I see I forgot. "Security ratio" is defined as the total miner fees per unit time divided by the amount you can safely transact over the blockchain per unit time.

So for example, say I'm paying you $100 per day, but the total miner fees on the whole network are $50 per day. In this case the "security ratio" is 0.5. So that means presumably that the cost of proof of work is something less than $50 per day. In this situation, I could wait an arbitrary amount of time, say 100 days, spend $5000 to generate a proof of work for a new longer chain where I double-spend all those transactions back to myself to steal back the $10,000 I paid you.

I'm not sure what a reasonable number for the security ratio is. In my post above I just used 1 as a placeholder.
 

theZerg

Moderator
Staff member
Aug 28, 2015
1,012
2,327
@Mengerian luckily if you did that the value of the coins you double spent would be 0 due to the massive flash crash such behavior would cause. Otherwise (and I haven't done the math) it seems like you might have shown the non-viability of mining without a coinbase reward.
 

theZerg

Moderator
Staff member
Aug 28, 2015
1,012
2,327
So I guess its critical that mining revenue exceed the maximum available coins for borrowing.
 
  • Like
Reactions: AdrianX

Melbustus

Active Member
Aug 28, 2015
237
884
...
In the long run, it has always seemed to me that Bitcoin needs to have low fees per transaction, but high total fees per block. This situation requires high transaction throughput per block.
...
Yes, completely agree. The alternative, low number of txns but high-fees, just seems like a crazy pipe-dream, even leaving aside all the other network-effect arguments as to how and why bitcoin could gain serious market-cap in the first place.

But a small-blocker will often make some gold analogy saying that gold is rarely transacted, and when that happens, it's done at high cost, and that's ok. Well, it's not ok! Gold has no direct connection to the real (transactional) economy anymore exactly because of this fact that it currently makes a bad (high friction) money. Humans still hold gold only out of inertia from a time when it *was* actually used as money, and it *did* provide low friction relative to alternatives; eg, a time before humanity needed global electronic exchange.

But now we *do* need a money that can do that, and Bitcoin *can be* ideal money for our times. The first ideal money that humanity has had in a couple hundred years; finally no friction due to "pegs" or "backing", no portability issues, cheap, global, fast, and no friction due to opaque supply and central management.

And because of all that it can also be destined for "Gold 2.0" status as people end up using and holding Bitcoin due to its transactional utility (of which censorship resistance is an important part).

It should be clear that all value stems from utility, and with bitcoin, we have a template for something of incredible global utility, so we should be doing everything we can to unlock that potential, rather than strangle it in the cradle over obtuse far-off hand-wavy 3rd-order concerns.

But I'm getting sick of saying this. We hashed all this out in 2011/12 in the original, now censored, thread. So at this point, my feeling is becoming:
If you don't believe me or don't get it, I don't have time to try to convince you, sorry.
- satoshi, https://bitcointalk.org/index.php?topic=532.msg6306#msg6306

[edit: typos]
 
Last edited:

Norway

Well-Known Member
Sep 29, 2015
2,424
6,410
@Peter R
I tried to post your paper on how transaction fees could/would behave without a block size limit in the comments sections below your own article about the top 10 papers on Coindesk. Two times. But it was deleted. I think they probably have a no link policy in comments :(
 
  • Like
Reactions: steffen

solex

Moderator
Staff member
Aug 22, 2015
1,558
4,694
@Melbustus

I can't upvote your post enough. It needs to be stickied somewhere!
ideally it needs to be tattooed on small-blockers' and settlement-layer's foreheads, in reverse, so that they can read it every time they look in a mirror.
 

Roger_Murdock

Active Member
Dec 17, 2015
223
1,453
These thoughts are a little half-formed so apologies for that, but here's what I've been kicking around today and would be interested in getting some feedback on.

  1. There's the claim that if the block size limit were removed entirely, there would still be an emergent limit on block size based on orphan risk. This limit exists even in a world where all miners are acting in their narrowly-defined / short-term self-interest and simply attempting to extend the most-likely-to-win chain in a way that maximizes their expected return. In other words, in this world, miners are not attempting to constrain the block size based on some broader desire to "protect the health of the network" / "prevent dangerous centralization." Let's call the limit that emerges in this world L1.
  2. There's also the idea that L1 is "too high" because it doesn't take into account the centralization risk of "too-big" blocks. So presumably there's a lower optimal block size limit (L2) that would balance the dangers of bigger blocks against their obvious benefits. Thus, miners who care about the long-term value of the Bitcoin network should seek to enforce this lower limit. (I'm specifically curious what people here think about this claim.)
  3. So it seems to me that you can support a Bitcoin Unlimited-type approach either because you accept claim 1 (and reject claim 2) OR because you accept claim 2 but are confident that a BU-type approach would most effectively allow the network to determine and enforce a block size limit that approximates L2, the theoretically optimal one.
  4. I'm assuming that skeptics of a BU-type approach accept claim 2, but do not believe that such an approach would be successful at determining and enforcing a limit close to L2. I'm further assuming that they think the limit that would emerge in practice would be too high.
  5. Here's what I'm having trouble with. If you think that "miners can't be trusted to set their own block size limit because they'll set it 'too high' in a selfish but ultimately short-sighted 'race to the bottom' as they seek to drive their competition out of business, destroying Bitcoin's entire value proposition -- decentralization -- in the process," then I don't see how you can think that Bitcoin isn't already irreparably broken. Because miners do set their own block size limit. It's just that, for the time being, the limit set by Core is a convenient and (again, at least for now) acceptable Schelling point. If you're convinced that the emergent limit of a BU-type approach would "run away" in some profoundly unhealthy manner, then why do you expect Core to be able to hold the line? In other words, if miners' incentives, once BU is widely-adopted, would be to ratchet up the block size to "unhealthy" levels, why isn't their incentive right now to abandon Core and move to an implementation like BU that would allow them to pursue that strategy?
 

Mengerian

Moderator
Staff member
Aug 29, 2015
536
2,597
@theZerg There are some other issues with mining in the absence of a coinbase reward, but I think the "security ratio" concept is unrelated.

I not sure it's possible to determine analytically what value of security ratio would be sufficient. It is something that would be determined on the market based on how trusting the transactors are of their counterparties, and what their threat model is.

I do think, though, that the concept of "security ratio" is coherent, and exists even if we can't know its value. It follows directly from the concept of security based on proof-of-work.

I'm sure there is lots more analysis that could be done on this concept.
[doublepost=1451275582][/doublepost]@Roger_Murdock Your reasoning seems impeccable to me!
 

Peter R

Well-Known Member
Aug 28, 2015
1,398
5,595
These thoughts are a little half-formed so apologies for that, but here's what I've been kicking around today and would be interested in getting some feedback on.

  1. There's the claim that if the block size limit were removed entirely, there would still be an emergent limit on block size based on orphan risk. This limit exists even in a world where all miners are acting in their narrowly-defined / short-term self-interest and simply attempting to extend the most-likely-to-win chain in a way that maximizes their expected return. In other words, in this world, miners are not attempting to constrain the block size based on some broader desire to "protect the health of the network" / "prevent dangerous centralization." Let's call the limit that emerges in this world L1.
  2. There's also the idea that L1 is "too high" because it doesn't take into account the centralization risk of "too-big" blocks. So presumably there's a lower optimal block size limit (L2) that would balance the dangers of bigger blocks against their obvious benefits. Thus, miners who care about the long-term value of the Bitcoin network should seek to enforce this lower limit. (I'm specifically curious what people here think about this claim.)
  3. So it seems to me that you can support a Bitcoin Unlimited-type approach either because you accept claim 1 (and reject claim 2) OR because you accept claim 2 but are confident that a BU-type approach would most effectively allow the network to determine and enforce a block size limit that approximates L2, the theoretically optimal one.
  4. I'm assuming that skeptics of a BU-type approach accept claim 2, but do not believe that such an approach would be successful at determining and enforcing a limit close to L2. I'm further assuming that they think the limit that would emerge in practice would be too high.
  5. Here's what I'm having trouble with. If you think that "miners can't be trusted to set their own block size limit because they'll set it 'too high' in a selfish but ultimately short-sighted 'race to the bottom' as they seek to drive their competition out of business, destroying Bitcoin's entire value proposition -- decentralization -- in the process," then I don't see how you can think that Bitcoin isn't already irreparably broken. Because miners do set their own block size limit. It's just that, for the time being, the limit set by Core is a convenient and (again, at least for now) acceptable Schelling point. If you're convinced that the emergent limit of a BU-type approach would "run away" in some profoundly unhealthy manner, then why do you expect Core to be able to hold the line? In other words, if miners' incentives, once BU is widely-adopted, would be to ratchet up the block size to "unhealthy" levels, why isn't their incentive right now to abandon Core and move to an implementation like BU that would allow them to pursue that strategy?
Yes!

If Bitcoin is ultimately controlled by the market, then how can the market enforce a limit that the market itself wants to exceed?

In this diagram, the market wants to be at Q*, but the block size limit is forcing it to be at Qmax. How can we hold back the invisible hand of the market?



This is exactly why I've been saying that there is no block size limit. It's just a figment of our collective imagination.