Problems with the Articles of Federation

[go1111111]

I am a big supporter of the view of emergent consensus expressed by BU supporters Justus Ranvier and Zanglebert Bingledack (ForkiusMaximus on reddit). Unfortunately, I think the Articles of Federation is too strict regarding the definition of block validity. I also believe that BU's governance model is unnecessarily bureaucratic and democratic.

The validity problem

Regarding block validity: imagine that as a software developer, I decided to modify the BU full node software that I run. I add an additional parameter: the block size at which I would leave the network represented by the longest proof of work chain rather than join it. Basically, I never accept blocks above this limit no matter how deep they are. If blocks are above this level I assume something is seriously wrong and that I don't want to partake in the new network. Because I agree with the Articles of Federation I set this limit much higher than the limit used to designate which blocks are only accepted after N confirmations. Suppose my parameters are such that I accept any blocks up to 8 MB immediately, I accept any blocks up to 32 MB after 4 confirmations, but I never accept blocks above 128 MB regardless of how many confirmations they have. As technology improves, I'll manually adjust these numbers of course.

Now the question: do we really want the BU Articles of Federation to state that I am in violation of their core philosophy? Am I doing something against the spirit of Satoshi's vision when I adopt such an upper limit? I would argue that my 128 MB limit is my personal "spam limit", just like Satoshi initially designated 1 MB as the spam limit back when block sizes were far below 1 MB. Satoshi never intended the 1 MB limit to be used to artificially squeeze our real transactions, and I never intend my 128 MB limit to artificially squeeze out real transactions. I'll adjust it upward as the network legitimately grows. The question is: what do I want my software to do automatically if tomorrow miners decide to mine 10 consecutive 200 MB blocks? I don't want to eventually accept them because they're deep in the longest PoW chain. I know that tomorrow there's no real user demand for blocks that big.

Is it so wrong for me to freely choose that I don't want to partake in a chain fork with 200 MB blocks at this time, and I'd rather stick with the smaller block chain? Do we not want to give users this option? IMO the UI should offer users an absolute 'spam limit' that they can either leave blank or configure how they see fit. The size of blocks that users will never accept is best governed by emergent consensus.

The governance problem

The BU governance structure (everything in the Articles of Federation after section 1) is unnecessarily complex and bureaucratic. The problem with Core is not that they don't allow democratic voting. The problem with Core is that they don't care much about what users want, and their vision of Bitcoin is different than Satoshi's. If BU was run by a benevolent dictator or just a small group who cared about user desires and agreed with section 1 of the Articles of Federation, everything would probably work fine. If they went off in a direction that people disagreed with, other people would create their own fork.

The reason why democracy and incredibly formal rules are used in government is that if government goes wrong, really really bad things can happen. Those in power can impose their will on people. Because Bitcoin is governed by code people run, those in control of a Bitcoin fork can't actually do anything bad with the minimal power they have, so the overly formal rules aren't really protecting against anything. They just slow things down and make things more complex.

A benevolent dictator of BU would want to know what the economic majority wanted. Probably the best source of this information in the future will be prediction markets on the price of a coin on each side of a fork, or futures markets for coins if a certain event / protocol change occurs. Until then, we can just use less formal ways of allowing users to express their opinions.

 

[theZerg]

U can fork BU and do whatever you want. The Articles aren't stopping you. But you cant call your fork Bitcoin unlimited and I think that that is fair and keeps things unambiguous to users.

Core has a benevolent dictator model and look what has happened. I chose another path for BU which may end up too formal but at least it is not repeating a failed organizational model in the hopes that this time it will be different. I think that benevolent dictator works great for many FOSS projects but wonder if the fact that bitcoin is about money makes it very different. Certainly we dont have any users running GIMP or SVN to implement schemes to defraud other users.

 

[go1111111]

Fair enough. I'm surprised that you think a separate hard cap is against the spirit of BU though. It simply gives users more options to express under what conditions they choose to remain part of the network. They're free to leave the hard cap blank if they prefer. I assume some users of BU would not stay on the longest chain if tomorrow every single block was suddenly 200 MB of spam for hundreds of blocks in a row. The question is: if that ever happens do you want their choice to not stay on that longest chain to be technically difficult for them, or do you want it to be easy for them to express that choice?

 

[YarkoL]

@go1111111
How about these settings for now -
excessive block : 128
accept depth : 18446744073709551615 (the max uint64)

That won't entirely solve your problem, but it would give us a little extra time to implement a "never accept" option. And welcome to Unlimited!

 

[go1111111]

@YarkoL thanks. So basically if BU simply offered the ability to specify two levels of excessiveness, I could use it to implement exactly the feature I want. Something like:

excessive block: 8
excessive depth: 4
majorly excessive block: 128
majorly excessive depth: 18446744073709551615

....this might be better than an explicit "never accept" because it also gives more flexibility to people who want both of the levels to be achievable. Not sure if other people would find two levels useful. If people like that, maybe it should be fully general so the user can specify as many levels as they want

 

[Zangelbert Bingledack]

There was a lot of motivation to make the initial settings fairly simple so as to minimize FUD. There are a lot more complex options being proposed in one of the BUIPs.

I do agree that there is some self-contradiction in the idea of forking being the governance mechanism but also having a governance mechanism in the Articles; one could see this as a reflection of the fact that BU wants to get the biggest userbase possible, which includes people who won't have seen the insight about emergent consensus as fully.

It also could be a reflection of the degree of friction associated with forking, though I think this friction is mostly temporary. Any friction means that governance mechanism has a bit of room to be aided, potentially, by such a redundant governance mechanism within a given fork. I am personally not sure it's worth it, but for experimentation's sake I can't really object too much - especially since we can just fork if it goes wrong.

 

[YarkoL]

@YarkoL thanks. So basically if BU simply offered the ability to specify two levels of excessiveness, I could use it to implement exactly the feature I want. Something like:

excessive block: 8
excessive depth: 4
majorly excessive block: 128
majorly excessive depth: 18446744073709551615

....this might be better than an explicit "never accept" because it also gives more flexibility to people who want both of the levels to be achievable. Not sure if other people would find two levels useful. If people like that, maybe it should be fully general so the user can specify as many levels as they want

Yes, why not. For power users I imagine you could have a graphical panel similar to adjusting EQ in audio software; with excessive block size on X axis and accept depth on Y axis, then you drag and drop control points to shape out whatever curve you want...

However, in my understanding the idea of making the settings user configurable is predicated on the assumption that the actual block sizes will not vary wildly from day to day. If anything, it will help the entire community of network users to arrive at consensus what the useful block size limit is. If this works out we would expect the limit to change very slowly and never without considerable discussion. Because of this, I think there is an ample opportunity for users to adjust their settings one step at the time. My view only, I think others exist.

 

[theZerg]

Fair enough. I'm surprised that you think a separate hard cap is against the spirit of BU though.

Please don't put words in my mouth like that. I will stop responding if you do so because I don't want others to get the wrong impression.

What part of the articles makes you think that BU is against an block size limit? (pls quote)

 

[TrevinHofmann]

Core has a benevolent dictator model and look what has happened. I chose another path for BU which may end up too formal but at least it is not repeating a failed organizational model in the hopes that this time it will be different.

I wouldn't agree. The model of benevolent dictator(s) / meritocracy worked fairly well for several years.

There might not be a development model that can last indefinitely. Maybe the best "meta" model is to have multiple teams of benevolent dictators, where forking is celebrated.

We'll see, though. It doesn't hurt to try democratic Bitcoin development, especially since nobody is forced to adopt the product.

 

[go1111111]

What part of the articles makes you think that BU is against an block size limit? (pls quote)

I may have misunderstood, but here's the quote:

"A block cannot be invalid because of its size." Article 1, section 3.

Here's how I view the emergent consensus / fork maximalist philosophy: a block can be invalid based on any criteria I want, including size, or whether some part of the block's data can be rendered as a JPG of an ostrich, etc. The usefulness of my validity definition corresponds to what sort of network I can recruit to join me in using it.

 

[Peter R]

@go1111111

What you quoted were my words.

At the time when I wrote them, people like Greg Maxwell and Adam Back called me crazy to even suggest that the block size limit could be removed from the consensus layer. So I was trying to be as simple and straightforward as possible. I had hoped to slowly rip apart the idea that all nodes need to agree on the exact same block size limit.

I think we've made great progress on this and it seems that most people now agree. Today, words similar to what you've written above might resonate with users better than what I originally wrote. Anyways, I think what you're saying is perfectly inline with the BitcoinUnlimited philosophy, which is just that consensus should emerge based on the code people freely choose to run.