Gold collapsing. Bitcoin UP.

[Zangelbert Bingledack]

@VeritasSapere

I think /u/Taek42 was just arguing about what could allow for monopoly, not that monopoly itself would destroy Bitcoin. Also, there is government coercion to consider, since government may be non-econo-rational, but of course then we have the counterargument that govs won't touch Bitcoin if allowed to grow so that they benefit from it, which naturally means faster scaling is better so that we can grow before govs get vicious.

 

[cypherdoc]

I address this in http://www.bitcoinunlimited.info/1txn "Effect on Block Size" and find that you are right. In the case of a miner whose transaction validation significantly exceeds the rest of the network, the optimum strategy (for miners to optimize their profitability) is for the rest of the network to ignore that miner's blocks -- effectively kicking him out of the main blockchain.

what about miners continuing to do what they do today? that is, use SPV mining to avoid validating, while still accepting the exablock?

 

[Peter R]

Holy shit! I think you got it:


@all

Doesn't this completely invalidate the big block attack?

YES!!! And this is why @theZerg's paper is so important! I completely missed it when doing my fee market analysis--I considered that miners would try in good faith to process all blocks regardless of their size and calculated what would happen. What Andrew has shown is that a rational miner will orphan a block that is expected to take more than 10 minutes to propagate across (and thus be validated by) the network. The miner does this because he expects all other miners to do this too!

What is super cool [because it further backs up Andrew's work] is that right around the time I was reviewing @theZerg's first draft, I also went through this paper by Dr. Nicolas Houy on "The Bitcoin Mining Game." In Houy's intermediate calculations, he actually had a result that proved the same thing, although the significance of it must not have hit him (it was sort of burried in math) as he didn't explicitly point out the discovery. Here are the notes I made at the time:

So now we have two investigators (Andrew and Nicolas) showing the same thing, but approaching the problem from different angles.

 

[VeritasSapere]

@VeritasSapere

I think /u/Taek42 was just arguing about what could allow for monopoly, not that monopoly itself would destroy Bitcoin. Also, there is government coercion to consider, since government may be non-econo-rational, but of course then we have the counterargument that govs won't touch Bitcoin if allowed to grow so that they benefit from it, which naturally means faster scaling is better so that we can grow before govs get vicious.

The idea is that a mining monopoly would not form in the first place because it would undermine the value proposition of Bitcoin. In the case of government attempting to do this, it is indeed an exception to this rule. In this case however faster scaling and increased adoption is still the best defense against such a government backed attack. An increased blocksize still supports this in all cases.

 

[cypherdoc]

@Zangelbert Bingledack, @Peter R, @VeritasSapere:

The block propagation/orphaning arguments also fail to take into account the large miners can have orphaning within their operations. Block propagation is never "0 seconds". Large miners like BitFury are geographically dispersed, as there are diseconomies that come with over-concentration. Large mining firms have to invest in reducing communication latency within their operations, just as pools also need to strive to reduce latency with their hashers, and all miners have incentives to reduce communication latency amongst each other.

It is not obvious a-priori what the optimal level of consolidation within the Bitcoin mining industry will be. Will it be like car manufacturing which is concentrated in large industrial facilities, or like the hair cutting industry which is highly decentralized? However it turns out, it is virtually unheard of that an entire industry sector on the free market gets entirely concentrated in one firm, and I think it highly unlikely that bitcoin mining would be unique in this regard.

precisely.

and this is a result of Bitcoin's fixed currency supply which essentially means the value of a single Bitcoin can Moon as a direct result of central bank printing (which Moon's continuously). all miners have a huge, vested interest in seeing the price skyrocket and becoming the new accountants/banks of the new system. this Dream, as i've recently called it, is enough to continuously bring in new competitors to the mining industry. we've seen this decentralization in the pie charts that is *better* than in prior years. it's not perfect, as we still have 60% of mining in China, which is why i argue it should be improved with bigger blocks which will allow an expansion of Western mining leveraging it's superior bandwidth.

 

[VeritasSapere]

I still think you can replace the word "miner" with the word "pool" in some of your writing cypherdoc, specifically in the last sentence of that last post for example.

This difference in semantics can be rather significant as I pointed out earlier.

 

[cypherdoc]

@VeritasSapere

yes. i've actually commented on this before, promising once that i'd be more precise on that distinction, pool vs miner. i need to tighten that up again as i totally agree that ppl use those terms interchangeably in a careless fashion. there's a difference.

 

[Peter R]

what about miners continuing to do what they do today? that is, use SPV mining to avoid validating, while still accepting the exablock?

A similar assumption to that is how you get the results from my paper. Andrew has shown from a game-theory perspective that at a certain block size they shouldn't even bother to try. In other words, there exists a natural game-theoretic block size limit.

 

[solex]

@_mr_e
Taek42 says:

For example, subchains do not increase 0-conf security, and actually make it easier to engage in RBF-type behavior - one needs only find a weak block (and put larger txn fees in it) to have all miners switch to the chain with the double spend.

The subchains software could include a form of Gavin's double-spend relay for informational purposes. Plus, a new subchain block gets rejected if an earlier subchain block had the first spend. The subchains paper covers this in detail, and the double-spend quickly gets an expensive process when substituting a whole new chain.

 

[Zangelbert Bingledack]

@theZerg @Peter R


Wait, this is still confusing me. Say you mine a bunch of "short blocks" in the meantime while the huge blocks are trying to be propagated, effectively orphaning them. Aren't those huge blocks still backed by more hashing power, though? That is, even if you have more blocks in your chain thanks to the short blocks, the longest-chain-by-hashing-power still wins, no? In other words, from the reddit comment above:

If you raise the block size substantially (however substantially you need), China, who has >50% of the hashrate, will fork off into their own network, being unable to communicate efficiently the blocks they are finding. But, having >50% of the hashrate, their fork is the fork that will be selected when the network rejoins.

 

[Peter R]

@theZerg @Zangelbert Bingledack

The Blockchain would only diverge if miners were consistently producing blocks larger than the Stone capacity Q_c = T/z. But from a game-theory perspective, there is no reason for miners to accept even a single block greater than Q_c even if the block size limit were completely removed. Right now, it looks like Q_c ~= 33 MB.

It would be nice to do more research surrounding fork divergence, but there is certainly no problem up to the 8 MB proposed by Gavin, and very likely no problem at all assuming the majority of miners act rationally.

 

[Zangelbert Bingledack]

@Peter R If longest-chain-by-hashpower wins, why is this

if a single mining pool chooses to ignore the large block and is able to find a short competing block while other pools are still validating a large block, it is in the other pools best interest to switch to this new sibling.

true even though

If you raise the block size substantially (however substantially you need), China, who has >50% of the hashrate, will fork off into their own network, being unable to communicate efficiently the blocks they are finding. But, having >50% of the hashrate, their fork is the fork that will be selected when the network rejoins.

??

 

[cypherdoc]

@Zangelbert Bingledack @Peter R @theZerg

the way i understand it, is that miners don't actually measure hashpower directly. all they do when a new block solution comes along is verify that the solution is less than the target. if it is, they drop the block they're working on and start building on this just received block. IOW, they simply follow the longest chain. that *solution* will be valid irrespective of whether the block tied to it was large or small.

 

[Peter R]

@Zangelbert Bingledack

I think more research is required until we have a good handle on all these questions. For example, we just learned something new in these last few days about the game-theoretic block size limit. The reality is, however, that none of this is much of a concern until blocks are significantly bigger than they are today (like ~30 MB).

In the meantime, if people are running Bitcoin Unlimited, they can help by setting their block size limits less than Q_c (the 16 MB default is a good choice to stick with).

 

[cypherdoc]

@Peter R If longest-chain-by-hashpower wins, why is this


true even though


??

 

[theZerg]

guys I've got to do christmas stuff! But this conversation is awesome hope to join in again later.

BUT ZB note that the 30MB result is the asymptotic limit -- TX fees per MB have to be 3BTC or higher (currently at .1 to .4). I find actually that txns reduce profitability at current network metrics (look at one of the figures)... ofc this reduction only matters in practice when blocks get so big that other miners notice and start deliberately orphaning sooo... we can get a lot bigger before it matters.

 

[Zangelbert Bingledack]

@cypherdoc

So there is even some more nuance than "longest chain by work"? Because I thought that was the sticklerishly correct version. If it's that subtle, perhaps we are still learning parts of what Bitcoin is, as you say.

 

[cypherdoc]

@Zangelbert Bingledack

all miners/pools do when deciding to accept a block is verify that the nonce provided along with the other elements of the header produce the solution hash which has to be less than the current target. there is no direct measure of how much hashrate the submitting miner possesses. it could've come from a small solo miner or from a huge pool. doesn't matter except that it's correct.

 

[Peter R]

@cypherdoc

So there is even some more nuance than "longest chain by work"? Because I thought that was the sticklerishly correct version. If it's that subtle, perhaps we are still learning parts of what Bitcoin is, as you say.

Yes, we are still learning.

At the risk of sounding profound, the subtly regarding the longest chain is that we can only know what the state of the Ledger was; we can never know what it is. I suspect there is an analog to the energy-time uncertainty principle from quantum mechanics (@awemany and @Mengerian have made similar insights).

A miner wants to mine on a block that will be included in the longest chain--but he can't know with certainty what that chain will be. If the longest chain the miner is aware of includes--at its tip--a stupidly-big block that would hinder the chances of that chain persisting as the longest, then why should the miner bother with it?

 

[Inca]

That RBF thread seems to have been modded.

Shame.