Bitcoin Unlimited - Ideas, arguments, and proposals

[solex]

Nice work on the doc.
I would however, steer clear of specifically mentioning other organizations, because it gives the appearance of a 1:1 fight, a polemic stance, and the oxygen of publicity for what is named.

This might be better:

Instead we see a conflict of interest in the Bitcoin Core developers employed by mainstream finance, and the emergence of Corporation products (Lightning network, Side-chains) which would benefit from a Bitcoin network that is incapable of handling the transaction demand. Whether Corporation developers are intentionally acting against the long term success of Bitcoin is irrelevant. In cases of potential conflict of interest, the moral and socially accepted behavior is to recuse onself from a position of determination. Instead, Corporation developers have stated [need reference] that they will block any commit that raises the maximum block size.

 

[theZerg]

I like your changes and applied them. Honestly I am a bit uncomfortable contextualizing the Bitcoin Unlimited Articles of Confederation at all. Typically you want to present an organization that stands on its own, not one that is primarily defined as a counter-movement (the "occupy Wall Street" movement is a great example of this mistake). However several other people felt that an intro/context-setting preface would be valuable...

 

[solex]

Thanks.
I think an intro helps, but also agree that BU is a movement, not a counter-movement. In fact, keeping the block limit small and forcing the bulk of tx off-chain is effectively, a counter-movement, therefore BU is simply reasserting the original vision which is being otherwise lost.

 

[Zangelbert Bingledack]

Perhaps reference to market-set consensus as per @rocks recent comment would be a good way to keep it neutral and make Core dev's position look like the counter-movement by default. Rip Rowan's point that the whitepaper says consensus is to be controlled by miners voting with their CPU power kind of says it all.

 

[theZerg]

@Zangelbert Bingledack: He's basically getting that from us. Please see the "Governed by the code we run" secton. However I've expanded it with a paragraph of his (and asked for permission). See Article 1 section II

 

[awemany]

Hey @theZerg, here's some more feedback from me:

The Bitcoin Unlimited project seeks to provide a new voice, in terms of
code and hashpower, to all stakeholders in the Bitcoin ecosystem.

It rather makes a very old voice (that of the early adopter user base) heard
again. I don't know how to write that in a good way, though.

In the Bitcoin Core client, we do NOT see a venue for these actors to
formally express their desires in regards to the evolution of the network.

I'd say: In the so-called Bitcoin/Core client (I would emphasize that it is just
another implementation by Bitcoin/Core instead of Bitcoin Core and with
so-called I think one underlines that Bitcoin/Core is not at all the *core*
of Bitcoin...)

I think we dethrone Bitcoin/Core by not even acknowledging it as the root reference
implementation, just one among several. There is no throne or pedestal.

We should present our alternative, but not put ourselves into the position as the underdog in the battle.

@Zangelbert Bingledack you surely have something to say along the lines of 'inner
game' here... ;-)

Instead, these developers have stated [need reference] that they will block
any commit that raises the maximum block size.

What is the best quote we can get here? @cypherdoc, you usually seem to have a nice
quote history of gmax & co, do you have something that fits?

Bitcoin Unlimited adheres to Satoshi Nakamoto’s vision for a system
that could scale up to a worldwide payment network and a decentralized
monetary system. Transactions are grouped into blocks and recorded on an
unforgeable global ledger known as the Bitcoin blockchain. The Blockchain is
accessible to anyone in the world, secured by cryptography, and maintained
by the most powerful single-purpose computing network ever created.

I like this part, especially the latter - I tried to define the Bitcoin
blockchain as the one that expends the most energy (in Joules) to secure the
network. That definition would also fit should the hashing algorithm ever
need to be replaced.

Pool Operator

I really like to see a BU pool, but I also think this is optional in the
early stages. Maybe say that this position is allowed to be vacant?

VIII

That section ends abruptly. Something must be missing.

The Github repository administrative account shall be held by the
President. But the President may only add and remove committers on the
recommendation of the Developer. The President may not commit software to
the Github repository directly.

I would make it 'code web site' or 'code repository web site'. Although
github is very widespread nowadays, I think it is not a good idea to refer
to a single company for this. Things may change quickly, and we don't want
to refer to the MySpace of source control. Maybe refer to github as the
current default or something?


Overall: I like it.
[doublepost=1446582711][/doublepost]Let me add - @theZerg, did you implement configuration options yet? If not, I'll start writing a patch on the WE.

 

[theZerg]

I removed github. Can you suggest some specific language for some of your top comments?
thx!

 

[theZerg]

We should work to get something quickly that coinbase can use. They may like our model (where they can be participants) over the "benevolent" dictator model Core and XT are using.

I know that the Articles are not perfect but any objections to kicking off on Monday next week?

That is, on monday we explicitly start inviting people to join and open up for formal BUIP proposals for the different roles and technical proposals...

What do we need to get done by then?

@awemany: Thanks for helping! I'll check in and point you to what I've done by the weekend (that's what WE means right?)

 

[awemany]

@theZerg, yes, WE == weekend. I tried to be more specific with my suggestions, here they are:

The Bitcoin Unlimited project seeks to provide a new voice, in terms
of code and hashpower, to all stakeholders in the Bitcoin ecosystem.

Suggestion: Just remove the word 'new'.

In the Bitcoin Core client, we do NOT see a venue for these actors to
formally express their desires in regards to the evolution of the
network.

Suggestion:
Replace client with 'variant': In the Bitcoin/Core (BC from here on) variant, ...

Instead, these developers have stated [need reference] that they will
block any commit that raises the maximum block size.

I believe they never really actually stated that they will block anything.
Of course, that's what they intend, but I think they've been careful to
never state an outright blocking of the blocksize - so we should also be
careful to not misrepresent anything - that would be a huge attack surface!

Remember that they hide behind 'we need consensus'. So my suggestion here
would be to reword that to something like this:

The BC developers insist on an ill-defined consensus (@cypherdoc, do you
have some nice quotes/links from gmax/ptodd here?) for determining the
development of their code base. This stalled all improvements on the blocksize
issue in BC.

Pool Operator: a publicly identified BU member who is responsible for
running the BU Mining pool as specified in Article 4.

Suggestion:

Pool Operator: a publicly identified BU member who is responsible for
running the BU Mining pool as specified in Article 4. The position of pool
operator might be vacant and pool operation is optional, as ressources
permit.

VIII. The President, Secretary, Developer or Pool Operator may
voluntarily resign before term completion, via a signed public message
posted to the BU public forum. In this situation, elections occur
prematurely via the process outlined in VII. In the case of abrupt
departure, an interim person may be

It ends just abruptly like this. Does it show on your google docs? Something
is missing here.

Last but not least, you wrote sth. along the lines of 'the president is not permitted to submit code directly'. I could imagine this creates an odd and cumbersome situtation should the president also be
a developer? (As in, any developer, not having the developer position)
[doublepost=1446700641][/doublepost]Oh, and here's the list of users I collected from @cypherdoc's gold thread until the point where I wrote the post suggesting the initial user base. Double checking by someone else encouraged:

@AdrianX @Aquent @awemany @Bagatell @bitsko @BldSwtTrs @blockchain-db @Bloomie @bucktotal @BuildTheFuture @catlasshrugged @cbeast @Cconvert2G36 @chmod755 @chriswilmer @CryptoScalper @cypherdoc @DDDGGG @dill @elehal @Emperor Bob @Erdogan @Fatman3002 @Flailing Junk @frankenmint @humanitee @Inca @Ivanhoe @Jose Perez @Justus Ranvier @JVWVU @Kupsi @kyuupichan @ladoga @lunarboy @macsga @majamalu @Mashuri @Melbustus @Mengerian @molecular @_mr_e @nby @NewLiberty @Peter R @platinum_rhodium @RenegadeMan @rocks @seweso @sgornick @sickpig @Smoothie @solex @Stereotype @tabnloz @theZerg @throwaway @trizma @Voktar @yrral86 @Zangelbert Bingledack @Zarathustra @zveda
[doublepost=1446700761][/doublepost]

We should work to get something quickly that coinbase can use. They may like our model (where they can be participants) over the "benevolent" dictator model Core and XT are using.

I think we should first have code and so forth in a repo and a website, before anything else

In any case, I do think that it would be great if BU is 'officially' started before the next scaling Bitcoin, because it will allow people to point to this effort. @Peter R., are you going to the second conference?

 

[theZerg]

@awemany Ok I have applied all of your suggestions.

The only one I reworded a bit is this:

Instead the these developers insist on a poorly defined consensus [REFERENCE: (@cypherdoc, do you have some nice quotes/links from gmax/ptodd here?)] for determining the development of their code base. This tactic has had the exact opposite effect of recusal, instead giving themselves veto power over any changes. This has stalled all improvements on the block size issue in the Bitcoin Core variant.

I wanted to change ill-defined because I think it might be slang. Also I wanted to link this thought explicitly with the recusal concept introduce in the prior few sentences


there were a few sentences missing:

In this situation, elections occur prematurely via the process outlined in VII starting from the date of resignation. In the case of abrupt departure, an interim person may be appointed by the President, including someone currently holding another role. In that case s/he will not vacate the originally elected role.

List looks good. We don't have to get everybody; we'll also just open it up to anyone to apply who has a real posting history somewhere (to eliminate sock puppets) that espouses large blocks.

I absolutely agree that we need code and repo before putting this before Coinbase or other industry people. However, that won't be that hard; a lot of what we need can be pulled from XT and other patches (and I have Cypherdoc's "base" idea running already -- but need to actually generate some large blocks ). What distinguishes us from these other forks is the human process we are solidifying now.

 

[awemany]

Yes, perfect, thank you! @cypherdoc, could you provide us with a nice good set of references to show the stalling? If you're too busy, let me know and I'll start digging through my and Greg's/Adam's reddit history...

I absolutely agree that we need code and repo before putting this before Coinbase or other industry people. However, that won't be that hard; a lot of what we need can be pulled from XT and other patches (and I have Cypherdoc's "base" idea running already -- but need to actually generate some large blocks ). What distinguishes us from these other forks is the human process we are solidifying now.

Indeed. We're currently low on dev capacity, I guess, but the change we want isn't that big. More to the point, I really want to see tests of various blocksize between two differently configured nodes and see that bigger blocks make it or don't make it through depending on the setting or patch applied/not-applied, before I'd ever vote 'publish this' on the BU-patch-BUIP. And a week or so of a full node with patch applied running w/o problems

I agree that this process of organizing this 'movement' is absolutely important to this effort, but we should still remember to not eventually present the attack surface of us being 'all talk, no code'.

BU does not come a single bit too early - I feel we have quite some urgency now with the recent price movements and potential influx of new people.

I also want to add that what I'd like about this upcoming BU organization is this one key aspect: Yes, it is a special interest group, but with its interests completely in the open.

 

[cypherdoc]

here's one. there's just so many over the months:

[doublepost=1446739541][/doublepost]there's also that long winded dev mail post from gmax a few months ago where he goes on about being "surprised" at 101 and that he in fact thought "smaller" blocks would be helpful.

there's no clearcut "stalling" post. it's just a cumulative set of postings and arguments from the other side that make it clear, to me at least, that's there's stalling going on. like sipa's 2017 BIP and Adam's 2,4,8 nonsense.
[doublepost=1446739784][/doublepost]and then there's the flat out wrong assessment of the situation like the "large miner, large block attack vs small miners". when gmax found out about the SPV mining going on in China that Wung Chen explained, he said he was surprised to hear that, which directly undermined the above FUD they had been promoting and using to try and debunk @Peter_R's paper.

 

[theZerg]

@awemany Yes. Ofc they will certainly push at our (lack of) Bitcoin dev experience unless we can eventually sign up a dev who has been active for a long time.

One thing that you said that is not as intended "before I'd ever vote 'publish this' on the BU-patch-BUIP": A BUIP majority vote does not mean that the code is committed. The BUIP can be passed saying "let's do X" with or without code. If a patch for X does not exist, then some interested party can submit it later and then work with the Developer to ensure that it is correct. If the patch does exist, the Developer now has the opportunity to work with the submitter.
But if the Developer seems to be blocking a perfectly good patch, members can vote to commit "AS IS", AFTER a certain interval -- I think it was 2 weeks.

Reasons:

1. I don't want everyone voting on the BUIP to be involved in verifying that the code is correct -- this is a massive duplication of effort and many voters will not have the skills required to do that validation.

2. I think that is is very important for an organization to commit to include a feature before it is written. Personally, I am busy enough to not want to waste my time. The Bitcoin Core project philosophy of "code and test the whole thing and only then we'll consider it for inclusion" (and the horrible social dynamics I would have to wade through if the patch ended up being controversial) was a big reason why I never contributed.
[doublepost=1446740642][/doublepost]@cypherdoc we either need something a lot clearer, about 15 references like the above (give me actual URLs so I don't have to hunt them down), or just choose to leave it unreferenced. Any place where they say that BIP100 is not being developed now. Or any secondary source blogging about that "trick"?

 

[awemany]

@theZerg: Good point at development model - I should have known, you laid it out clearly in the very document we're discussing right here

So let me rephrase: I'd consider it good practice to have at least the above tests done before
making a release.

 

[theZerg]

yes, absolutely!

 

[solex]

This is Adam Back explaining extension blocks where he has a clear view that the 1MB would remain for a very long time, at least to the point where user tx can fill up 100MB extension blocks. His starting point is that 1MB is optimum and that all Bitcoin volume scaling is not to be done on the main-chain in the way Satoshi initiated.

Perhaps the best quote is: Adam Back on block sizes "Choice is good."
Which is exactly within the BU overview. What about the miner today who wants to make a 1.1MB block and users willing to pay for it right now? That is their choice yet Adam is happy to disallow it. If he really believed "Choice is good." then big-blocks should be allowed at least until his extension block software is built, tested and ready to use.

https://www.reddit.com/r/bitcoin_devlist/comments/3d32zm/softfork_block_size_increase_extension_blocks_re/

Adam Back on May 30 2015:

I discussed the extension block idea on wizards a while back and it is a way to soft-fork an opt-in block-size increase. Like everything here there are pros and cons.

The security is better than Raylstonn inferred from Tier's explanation I think.. It works as Tier described - there is an extension block (say 10MB) and the existing 1MB block. The extension block is committed to in the 1MB chain. Users can transfer bitcoin into the extension block, and they can transfer them out.

The interesting thing is this makes block sizes changes opt-in and gives users choice. Choice is good. Bitcoin has a one-size-fits-all blocksize at present hence the block size debate. If a bigger block-size were an opt-in choice, and some people wanted 10MB or even 100MB blocks for low value transactions I expect it would be far easier a discussion - people who think 100MB blocks are dangerously centralising, would not opt to use them (or would put only small values they can afford to lose in them). There are some security implications though, so this also is nuanced, and more on that in a bit.

Fee pressure still exists for blocks of difference size as the security assurances are not the same. It is plausible that some people would pay more for transactions in the 1MB block. Now there are three choices of validation level, rather than the normal 2-levels of SPV or full-node, with extension blocks we get a choice: A) a user could run a full node for both 1MB and 10MB blocks, and get full security for both 1MB and 10MB block transactions (but at higher bandwidth cost), or B) a user could run a full node on the 1MB block, but operate as an SPV node for the 10MB block, or C) run in SPV mode for both 1MB and 10MB blocks.

 

[Peter R]

@theZerg :

I'm not really up-to-speed on BU at the moment. Two questions:

1. Was a decision made regarding whether to make the block size limit adjustable via an optional command line parameter (with infinity as default), or was some other decision made?

2. Does any working code exists (beyond what @seweso had already done)?

 

[theZerg]

1. No. I've hammered out a structure for making those decisions.

2. seweso's code is based on XT and only rebrands. It does not actually do anything. Same with that guy who posted to BitcoinXT. I don't think he was an engineer. His just changed 4 lines of documentation .

A. I have a small patch that just removes the block limit (Cypherdoc's minimalistic proposal)

There is one proviso to it right now which is:

in one case a file buffer class is created that allocates a 2*BLOCK_SIZE memory. We need decide whether we should do something simple that adds an implicit block limit (create a 64MB buffer for example) or rewrite this class (its very isolated) to be a "better" buffered file.

Right now I'm temporarily just going to go with a big buffer -- a rewrite would introduce a much bigger patch.

B. We need to actually TEST A with big blocks. To do so, it makes sense to create the "configurable" version. I'm working on that now...

 

[theZerg]

Peter (or anyone else), if you have any suggestions in the Bitcoin Unlimited Articles of Federation please send them soon. I wanted to kick the organization off early next week... https://docs.google.com/document/d/1TpzpjV4ShpitjQ5NfrVS2C9qPQAKWRg-qjAb1_pmN-0/edit?usp=sharing

 

[Peter R]

@theZerg:

OK, reading now...

Well done! I was initially questioning the value of the Constitution, but now that I see what you've done here I think it was a great idea! I think your proposed structure of President, Secretary, Developer and Member(s) is perfect and should work to balance power effectively and transparently. I particularly like it that the President holds the highest-level access to the GitHub account but is not permitted to make changes to the code.

I think the document could still use some polishing before it's published in a way that would be expected to attract LOTS of eyes (I think @Zangelbert Bingledack is probably the best writer here wink wink)

I mostly just made minor corrections and a few comments. Feel free to ignore anything you don't like:

p1, par 2: "whatever it’s users" -> "its"

p1, par 2: "with hashpower" -> "with their hashpower"

p1, par 3: "We see the mining industry and the necessity to increase transaction revenue to support its growth as the block subsidy decreases." Isn't really a proper sentence. Maybe: "Furthermore, we recognize the necessity to increase transaction fee revenue to support the growth of the mining sector as the block subsidy decreases."

p1, par 5: "Instead we see a conflict of interest in the Bitcoin Core variant developers employed by finance-oriented for-profit startup companies, and the emergence of corporate products (Lightning network, Side-chains) which would benefit from a Bitcoin network that is incapable of handling the transaction demand." I would combine this with paragraph 4 (which is only 1 sentence) and re-write perhaps as: "Instead we see a project controlled by a small group of developers employed by finance-oriented for-profit startup companies, and the emergence of corporate products (Lightning network, Side-chains) that would benefit from a Bitcoin network that is incapable of handling the transactional demand."

p1, par 5: "moral and socially accepted" should be toned down a bit IMO

p1, par 5: "position of determination" --> "position of influence"?

p1, par 5: "Instead the these" --> remove the "the"

p1, par 5: "exact opposite" --> "opposite"

p2, par 1: " at its core" --> re-write without using the word "core" to avoid confusion.

Art 1-II: the formatting of the quote looks funny.

Art 1-II: " ip ranges" -> "IP ranges"

Art 1-III: "Bitcoin Unlimited nodes can accept a chain with an excessive block, when needed, in order to track consensus." -> Will this be true for the first release? Rocks and Cypher wanted to avoid this for now; however, I do like having it in this document.

Art 2-IV: 2 weeks doesn't seem like enough time to me.

Art 2-V: In addition to writing the proposed code, shouldn't the Proposer also be required (when necessary) to provide evidence of testing, etc.? I'm thinking that we want to make it as easy as possible for the Developer to ensure that the proposed code is sound.

Art 3-VIII: "created my members" -> "by"

Art 4-I: "US-based mining pool" --> Melbustus was concerned regarding money-transmitter rules. I think we could run the pool out of the Isle of Man or Canada, for instance.

In many places: "etc" -> "etc." and "hashpower" -> "hash power" (at least that's what we're doing for articles in Ledger)