Topic: bitcoin "unlimited" seeks review - page 6. (Read 16106 times)

BU will let the user select a given Core or XT BIP (this is still be worked on (BUIP002, probably not supposed to link it here)), so for example if they turned on the BIP101 option, their node would mimic an XT node as far as following BIP101, including the 75% threshold and specific starting block.

Just like today, where if XT were winning Core miners might switch to XT, and if not they wouldn't, it's the same dynamic: if XT were winning, the BU miners would likely set their blocksize settings to BIP101. They can do this even faster than Core miners can switch to XT since it's just a GUI setting, not a new client to download.

They can just follow Core. BU can be set up to default to Core behavior (it doesn't now, but it's an experimental release; anyone could fork it that way, trivially). I mean, you could say the same about XT: dumb users might try using XT. Could happen. This certainly isn't a security risk, or else Bitcoin is doomed because there's no way to stop people from releasing forks. Yeah I know XT has the 75% failsafe, so then imagine the reverse: everyone is using XT and someone dumb downloaded Core with its 1MB cap and tried to mine but kept not being able to build any blocks because their client rejected all the XT blocks.

Point is, the situation today is that miners and nodes need to pay attention to developments today. They can't just blindly trust whatever Core puts out - and if that's the expectation then we already have bigger problems.

Actually, BitUsher, I did mention this to you on page 3. It's been a fast discussion and we forget things, so no worries.

Note to small block adherents: Despite the name, Bitcoin Unlimited is not a "big blocks" implementation. It's simply an implementation that doesn't include a locked-down blocksize as part of the package. It lets the user set it. It could be 500kB if you like.

Ok, thanks for clarifying and I understand why you wanted to ignore those "differences" but they should have been revealed up front when I kept asking for clarification as this is a technical subforum where we are meant to discuss the details .

Unlimiturd: you may have any block size you want, so long as it's <16MB.

Am I wrong about ^this^?  If so, please advise on the actual maximum value.

DEFAULT_EXCESSIVE_BLOCK_SIZE = 16000000

static const unsigned int BU_MAX_BLOCK_SIZE = 32000000;  // BU: this constant is deprecated but is still used in a few areas such as allocation of memory.  Removing it is a tradeoff between being perfect and changing more code. TODO: remove this entirely

Ok, thanks for clarifying and I understand why you wanted to ignore those "differences" but they should have been revealed up front when I kept asking for clarification as this is a technical subforum where we are meant to discuss the details .

testing1567 had 2 very interesting posts.... do you disagree with any of the information therein before I start pondering them in detail?

The comments by testing1567 are showing up for me.

[...]

The comments by testing1567 are showing up for me.

BitUsher, please note that I've been focusing on one part of BU - the aspect I consider to be the major one - because I know this discussion will quickly become impossible if we talk about two many things at once (already 6 pages), but there is another aspect of BU called the "oversized block acceptance depth" or "excessive block acceptance depth" that was originally thought to be either necessary or useful to make the concept work. I personally now don't think it is necessary at all, but it may turn out to be useful. It certainly looks like it would be useful, but I'm very much aware of the difficulties in proving that to be case, so for now I consider it an experimental thing for everyone to consider.

Meanwhile, I would like to argue that - even in the absence of that setting - the BU concept of simply letting users set the blocksize cap themselves will not result in chaos, but simply a smoother version of what we have now, with the will of the market expressed more completely and granularly, without jiggering by the wall of inconvenience of having controversial consensus parameters locked down. See here for elaboration.

>Consensus rules *must* be same for all bitcoin users. It's that simple.

>...

> How to coordinate such update for a decentralized system? Peer review has worked quite well.

I agree.

However, this is no reason that this peer review process has to be centralized in Core's repo. That's the whole point of /u/anarchystar's improvement proposal. Miners and nodes can take Core's recommendations into consideration without being bound by a wall of inconvenience (self-modification of the code). Since a lot of miners already mod their code today, it is clear that all Core really does with respect to consensus parameters is set Schelling points¹ for consensus to form around.

The inconvenience/casual-user-difficulty of modding the code does strengthen the Schelling point, but it has the disadvantage of centralizing control over Schelling-point setting - thus introducing friction and a potential attack vector into the consensus process.

Today:

- Core sets the Schelling points for consensus parameters (max_blocksize=1MB, etc.) as user-unchangeable settings

- Miners and nodes are able to mod their code to change those parameters if they wish (maybe need to hire a coder), but of course they generally don't as they would lose money/functionality due to not tracking consensus

- Miners/nodes could all agree to a block where they change the parameters in sync, irrespective of Core, but it would be inconvenient (instructions for doing it would have to be circulated, etc.)

With this BIP:

- Core sets the Schelling points for consensus parameters (max_blocksize=1MB, etc.) as default settings with alternatives selectable (with warnings)

- Miners and nodes can easily change those parameters if they wish (don't need to hire a coder), but of course they generally don't as they would lose money/functionality due to not tracking consensus

- Miners/nodes could all agree to a block where they change the parameters in sync, irrespective of Core, and it wouldn't be inconvenient (except just getting everyone on board and aware, which is the same problem faced when Core would release a hardforked upgrade)

Note that all these changes are "merely" changes in convenience. I put that in quotes to be fair, because even trivial inconveniences can make a big difference in how people act. However, taking a stand against the spirit of this BIP is to fall back to the position that Bitcoin's consensus is enforced by a wall of inconvenience.

If that's the position you want to take, matters just got a lot worse for you: there are now implementations (and yes, they are properly called implementations as they don't force the user to break consensus) that already have this BIP partially included and are working on having it fully included, meaning that wall of inconvenience is about to get a whole lot thinner. With respect to blocksize it already has.

A few days ago, in order for a miner/node running Core to adjust the blocksize cap, they had to mod the code themselves and recompile, or hire a C++ programmer familiar with Bitcoin to do it for them. Today, they can simply download a piece of software. Maybe tomorrow they'll be able to just download some kind of tiny plug-in someone makes.

Thus we see that the wall of inconvenience cannot be relied on. As is argued in the case of zero-conf transactions, "We might as well break it now because it's trivially defeatable." It is inevitable that Core's recommended consensus parameters will become unbundled from the rest of its code offerings, not because centralized control over the consensus parameters is bad (though I'd argue it is), but because the inconvenience barrier cannot be maintained.

We are only now seeing this unbundling because it is only now that a sizable number of Bitcoin users have started to have a different opinion from Core and/or become wary of vesting inordinate power to set these Schelling points with a single group in a single repo. Core's recommendations will still carry tremendous weight in people's decisions about how to set their consensus parameters, but the process will no longer be centralized. People will go with Core's parameters if they want, or converge on one of the Core dev's proposals, or maybe someone else's.

Consensus will happen, not because it is enforced by a barrier of inconvenience in Core software, but because there is overwhelming economic incentive to converge on consensus parameters. To confuse this is to imagine that the tail is wagging the dog.

Moreover, the consensus will be economically rational and value-maximizing because miners and nodes are economically rational, which is a fundamental assumption for Bitcoin to work in the first place.

What annoys me and confuses a lot of people is this "emergent consensus".

Some people, Peter R in particular, make it sound as if setting individual limit on nodes somehow magically makes consensus to emerge.

When in reality it's the good old "everybody agrees first, then sets their limit to the exact same value" consensus.

Odd... is anyone else noticing that those 2 posts don't show up in the main thread accusing Adam of condoning censorship or is it just me?
Has testing1567 been shadowbanned? Ohhh, the irony.

Those posts reflect a very different version of BU than has been described by its proponents in this thread . Either they have't fully reviewed the code or testing1567 is incorrect but there is a discrepency. I suppose I will have to read the code myself one day to get to the bottom of this.

Here's the difference with Core:

1) So I fire up 2000 nodes, hire a coder to mod the Core code to set 200MB as cap.

2) I make the miners belive this is the prefered block size.

3) They all go "yayyy tons of fees!" and hire a coder to mod the Core code so they can start producing 200MB block.

4) I fill up the blocks for the next 10 days

5) Bye bye 75% of all network nodes

6) I pretty much run the network

Not that you could actually do (2) anyway, but that's just me defending Core again. As I mentioned, this is just a bit more convenient in BU. Someone with the resources to spin out 1/3 of the total number of nodes now on the network, and mining pools that are actually mining the blocks now, are going to find it trivial to do (1) and (3) right now, in Bitcoin with Core, if they wanted to. The convenience of BU is not going to be of any noticeable help, and even if you think it is, that horse has left the stable - the miners convinced can just download BU. Under that view, all that was necessary to kill Bitcoin was to release BU. That can't be right.

Here are two posts from testing1567 on reddit (says he doesnt have a bitcointalk account):

Surely this is a joke?  The only reason the other forum was created was because Bitcointalk was becoming known in the Bitcoin community as North Korea.  

When in reality it's the good old "everybody agrees first, then sets their limit to the exact same value" consensus.

The only difference is that setting the limit is now even less reliable than the soft fork.

I prefer to respond to you on here because I don't have an account on either forum. I am not a believer in Bitcoin Unlimited myself, but I do feel that I have a fair understanding of the concepts and intent behind it and they do have some good ideas.


In your example your node is set to accept 1mb + 10%. (1.1mb?) If you were to receive a 2mb block, your node would accept it, but it wouldn't relay it. It would continue to follow the <1.1mb chain but it would also monitor the 2mb fork. BU has a secondary user adjusted parameter for determining max block size. You can set a maximum fork length. Your BU client will continue to accept blocks for both forks, but will only relay transactions and blocks for your <1.1mb chain, so it is not blind to the existence of the fork and will warn you of discrepancies between the two. However, if the 2mb fork gets more than your maximum fork length ahead of your prefered chain, your client will abandon the 1.1mb chain in favor of the longer one. So if your max fork length was set to 24, then you would stick to the 1.1mb fork until another fork becomes more than 24 blocks longer. This ensures that any overriding of your max settings can only come with a majority of the hashing power behind the move. Miners, in theory, don't have complete control either. A miner would need to consider the orphan risk before creating a large block. This orphan risk is intended to be an emergent property of the network created by individual node operators setting their prefered max block size. Maybe creating a 1.3mb block is fairly safe if the included fees are high enough to risk the orphan, but risking it on an 8mb block could be an almost guaranteed orphan. Every time a miner creates a larger block, it is a calculated risk. We may even see varying mining pools emerge based on people's risk/reward tolerance levels, particularly when the block reward is minimal and the miners are relying on cramming in as many transaction fees in as possible to get paid.

It essentially turns the hard blocksize limit into a soft limit that can be overruled with enough sustained hashing power. The idea is rather than fighting to prevent fragmentation and forking by setting a hard limit, it embraces forking and attempts to manage it in an automated fashion while fragmentation exists and eventually converges on a single fork if it has sustained miner support. In theory, a wallet that is aware of multiple forks can ensure that you are not cheated.

As I said before, I don't completely agree with BU. I have some issues with the logic behind it, but it does have its merits. I'm going to reply to my own post here and talk about what I consider the negatives to BU, but I want to list the positives here. I love the concept of monitoring alternate forks and converging on one if it gets to a certain length ahead of the rest. I personally think that this feature could be very useful even in Bitcoin Core. Imagine using this method but with the variables hard coded to 1mb and a hard coded max fork length rather than being user adjustable. You would essentially be turning any future blocksize increase fork into a much less scary thing. In reality, a blocksize fork needs to happen eventually, regardless of if it is forced through by BIP101 or if is planned on and agreed to years from now. If these features could be refined and implemented into Core, it would allow for a smoother transition without all the emergency upgrades and damage control.

My main issue with Bitcoin Unlimited is how will it handle merging into a new fork? Let's say that I'm at 1mb max and a 1.01mb block is made and remains the largest block in the new fork. What does my client set it's max blocksize to? Is it 1.01mb? What if a 1.02mb block is created right after I merge into the new longest fork? Will my client be out of sync again until the fork grows longer? I'll probably be out of sync a lot unless I manually go into my client and raise the limit to give it some buffer area. I feel like it would be too easy for the miners to basically bully the node operators to push the blocksize higher, especially with a majority of the miners in one physical region. The only thing holding miners back would be the orphan risk and I'm not even sure if that can affect them. It would be trivial for mining pools to build there own block relay network (which I think they have already). My other issue with BU is it lacks a way to move the blocksize down, only up.

I personally think that they should be supported in their efforts because their attempts at automated fork management could eventually benefit everyone even if it never succeeded as a method of setting the blocksize limi

Quite right. The choice of settings effectively becomes a vote on what you support.
Just as it is now, the miners actually decide what size of blocks they want to create, based on their knowledge of the network and its participants.
As an end user, you could set your limits high enough not to worry about them for the foreseeable future.

And there are plans to make it easier for end users to track the limit growth curves of BIPs they agree with, which makes it easier for them to express their views on the policy.
To prevent them from isolating themselves from the emerging consensus, there will be a warning message issued by the BU client if the user's settings are too restrictive to continue following the longest chain.

Of course users would converge on a BIP...