I just wanted to come back on the superlinear problem that iCEBREAKER mentioned here, because it deserves response since it's just as much a problem for other BIPs and SW.

So this is not a new problem introduced by BU, and there have been some proposals made in the context of BU to mitigate this (by moving verification into separate threads etc.)

Most of the discussion around this in BU has happened in the thread below as far as I have seen:

https://bitco.in/forum/threads/i-really-want-to-like-bitcoin-unlimited.684/page-2#post-8087

There is no mechanism to reach consensus about the blocksize limit, with BU all nodes just set there own limits.  This does not reduce the potential for debate, arguments or central planning.  The community would still need to reach consensus about the blocksize limit in the same way it is trying to now.  The core development team could still try to keep the 1MB limit and miners would still need to make a decision to change to accept larger blocks, the only difference would be the debate may be about values to set in the client, rather than which client to use, which is effectively no significant change from the current status quo.  If we want nodes to dynamically set a blocksize limit, in a way determined by the market, we should use a proposal like BIP100.  BIP100 actually allows miners to dynamically set a blocksize limit and agree with each other on a new limit, BU has no system to enable nodes to agree on the limit.

I just wanted to point out that the one comment I left in this thread has now been deleted. The idea that this place is "neutral" is silly.

All the good people are leaving.

 if so, aren't fraud proofs for SW an illusion?

A very simple attack can be done on the network.

There are really 3 parameters that can be set at each node:

1) Maximum generation size (only used by miners)

2) Maximum relay size (used to propagate to peers)

3) Maximum acceptance size and # of blocks ahead to force an automatic change of parameters (This mechanism is one I am less sure of how it works).


I'll ignore the first parameter since it's set by miners.  Suppose I want big blocks in my unlimited node.  I set a max relay size of 32MB and max acceptance size of 32MB (the maximum allowed?).  I will accept anything I see that is the longest chain and pass everything along.

Now suppose I connect to a bunch of nodes, and they have much lower limits - the max relay they have is 2MB, and max acceptance is 2MB.  I will never see any blocks bigger than 2MB!  Even if the majority of nodes were accepting large blocks, and I just got connected to a few small block nodes, I'm screwed.  I'm out of sync with everyone else, and there's nothing I can do to sync up.

The attack is simple - launch a bunch of nodes, try to connect to as many nodes as possible, and stop relaying anything big.

In a large enough network, this doesn't even need to be accidental.  Some poor sap gets unlucky and connects to all small block users, and can't ever get an update.  The end result is many chains and chaos.

Of course this is solved in an interesting mechanism - a bunch of people get together and talk and coordinate limits and upgrade together... hmmm.... sounds familiar.

There seems to be multiple different explanations of BU which is leading to some confusion.



Is this a hypothetical "unanimous agreement for a 2mb limit" of the miners or just BU nodes? So BU takes queue from a miner "BIP100 like" vote and combines that with a supermajority BU node vote to determine a new maxBlockSize limit?

  
Thus a simple majority of miners is the "BIP-100" like vote that would permit an increase if the corresponding nodes agreed?

  
My thoughts are bitcoin simply made the game theory incentive to merely discourage dishonesty by incentivizing miners at a greater degree to secure the blockchain than attack it. Why are we assuming honesty? I hold the opinion we should prepare for dishonest and malicious miners as a possible attack vector. This is why we need to focus on decentralizing mining much more.


  
Is this true? As far as I know only Luke-jr wants to keep the blocklimit or lower it. Peter Todd signed up to make an effective increase and the rest of the scaling signers want to raise maxBlockSize after all the other improvements are completed to accommodate the LN. Is this simply a misunderstanding because I repeatedly see this being repeated on that forum and on r/btc or do you acknowledge cores statements and are assuming dishonest intent?

FYI... regarding post deletions, the only posts being deleted should be offtopic or non technical related ones, which we welcome because after all this is the " Development & Technical Discussion " section. Please take a screenshot of any "technical" post if you believe there is censorship here.

It is not false with respect to any setting other than infinity (but your point is valid since infinity is a apparently a valid setting). There is never a guarantee that any Bitcoin node will converge to the longest chain in finite time, only eventually. The exact same guarantee applies to BU, though it may take longer to agree on a chain than other implementations.

I am very enthusiastic about Bitcoin Unlimited and think it is a great idea. (Disclaimer: I am a big blocker, and see BU as the mechanism that will end up bringing higher maximum block sizes that can let Bitcoin scale with on-chain transactions. Anyway, my stance on big blocks is, I think, independent of my argument below.)

As Zangelbert Bingledack has argued before, BU lets users do something that they can already do, albeit currently in a more complicated way. Let's suppose a group of miners decide that a blockchain with 2 MB blocks is acceptable to them, and want to gamble that other miners and economic actors (like exchanges) will think likewise and accept such big blocks too. They can already upgrade to a blockchain that supports larger blocks by recompiling their own custom version of Bitoin Core where they substitute a higher value for the integer constant MAX_BLOCK_SIZE. If these miners command a minority of the total hashing power, they will find that whenever they try to relay a 1.9-MB block, it gets stalled among nodes that refuse to relay it and the block gets orphaned and rejected by the longest chain. Now they could keep on trying to propagate their blocks and use human-communication channels like this forum to try to attract other miners and users to the 2-MB camp, but there is something that will probably put them off and that makes it hard for this approach to succeed: the moral aspect. Right now, the more common view is that a block that exceeds the 1-MB cap is an "invalid" block that violates the consensus rules, just as would be a block that contains, say, invalid transactions or incorrect hash values. This leads to a situation where the miners sending 1.9-MB blocks out to the open will get rejected as "malicious" or "attacking" nodes. Any reputable mining company won't want to be associated with such antics, and will understandably keep their blocks under the limit to be seen as well-behaved legit nodes.

Now the great idea behind BU is that it completely eliminates this moral aspect by taking the maximum block size out of the consensus rules. Under BU, the blockchain becomes a parameterised family of N-capped blockchains. If BU becomes the main Bitcoin implementation, miners may freely choose to decide that they can support a 2-MB-capped blockchain or a 32-MB-capped blockchain without anyone shouting at them "malicious!", "attacker!", "you filthy rascal, impostor of a node, boo, boo, boo!!!". The moral aspect vanishes as it is now just as legit to adhere to any cap. Those who only support the 1-MB-capped blockchain will reject any blocks bigger than 1 MB, while the 2-MB-capped blockchain nodes may keep on trying to build a longer chain. It's important to note that the blockchain only splits when a subset of the miners advocating for an N-capped blockchain command more hashing power than those miners that advocate for M-capped blockchains such that M < N. At that point, two things could happen: a node supporting the M-capped blockchains may accept that a longer chain now has larger blocks and raise their M parameter to match at least N, the new proof-of-work consensus, or insist that they won't support such large blocks and keep on mining a shorter chain of blocks that respect their M limit. This might lead to several alternative chains coexisting for some time, but the ensuing chaos should be very brief as the free market will rapidly settle for one of them. My feeling is that this would be the chain with the higher block sizes and the larger proof-of-work behind it.

How will the growth of the block size cap happen under this mechanism? I think the pressure on miners to increase the limit will grow as the cap starts to be hit. As more users try to send (on-chain) Bitcoin payments, the 1 MB limit will be hit more and more often and a backlog of transactions will start to grow. This will lead to users complaining about their transactions being stuck in limbo and some negative media reporting about it ("Bitcoin network collapsing" and the like). Under such strained conditions, which we may start to see pretty soon, the Bitcoin price will take a battering in the exchanges with miners starting to worry about their income and realising that they're jeopardising the Bitcoin network and their earnings by not raising the cap. I could be wrong about all this, of course, but then it would be the free market which would prove me wrong by settling on a tightly capped blockchain. In any case, thanks to the mechanism that BU provides, raising the block size limit can be a market-driven smooth transition rather than an incessant and unseemly fracas among the core developers in the mailing lists and IRC channels.

Legitimate kudos to adam for moving the discussion here:

https://www.reddit.com/r/btc/comments/3zc6qg/review_of_shelling_point_protocol_selection_ideas/

Your arguments via oprah meme and appended "tard" might get downvoted, but they won't be deleted.

I countered the criticism of Taek and so did many other people on the bitco.in forum, here is a link to my response:

https://bitco.in/forum/threads/gold-collapsing-bitcoin-up.16/page-203#post-7395
https://bitco.in/forum/threads/gold-collapsing-bitcoin-up.16/page-208#post-7550