Bitcoin Unlimited - Ideas, arguments, and proposals

[solex]

I see that the next available BUIP is 002 http://www.bitcoinunlimited.info/proposals
Is anyone drafting another BUIP? Can I have a reference number for the following which I will draft up properly?:

BUIP00x Multi-BIP Scaling Enabler

The purpose of this BUIP is to accelerate the take-up of BU, at the time of writing, now 60 nodes.

The idea is to add a dropdown box with all the much discussed and recognised BIPs which enable scalability:

• 2-4-8 (Adam Back) [dates to be determined]
• BIP100 (Jeff Garzik) Miner voting [to be detailed]
• BIP101 (Gavin Andresen) 8MB doubling bi-annually for 20 years from 1st Aug 2015, smoothed
• BIP102 (Jeff Garzik) 1MB then 2MB at a flag date[?]
• BIP103 (Pieter Wuille) 1MB increasing at 17.5% per annum for 20[?] years from 1st Jan 2017, smoothed
• BIP202 (Jeff Garzik) 2MB at a flag date[?] then +20 bytes per 10 minutes

There are likely many Core node owners who do not like BIP101/XT but will be attracted to BU if they can set their block size limit to match their preferred BIP.

The mining thresholds are not relevant in this Multi-BIP, and an acceptance depth will be required, but otherwise the software could be easily coded to match the BIPs above.

Clearly, all these BIPs are fine in parallel on different BU nodes and only serve to feed into the consensus max block limit. The important goal is to break the log-jam at 1MB. Once people are comfortable with user defined limits then they may well increase their settings beyond the original BIPs which are somewhat conservative, except for BIP100 which could accelerate to 32MB in a couple of years, and BIP101.

 

[Zangelbert Bingledack]

@solex

I think that's a great idea. I can imagine a scenario where there is a series of jumps from one Schelling-point consensus to the next. For example, first everyone warily converges on Pieter's very conservative BIP, then as capacity increases faster than expected people jump to Adam's 2-4-8, then an unforeseen adoption surge induces a jump to BIP101, and finally people see where this is going and miners - as the foremost experts on the network - move independently of the devs to create their own Schelling points.

an acceptance depth will be required

Not sure what you mean here. If the point is to mimic a given BIP, I think the acceptance depth function should be off by default for the obvious PR reasons even if it would be useful. (People can always turn it on it they want it.)

 

[solex]

@Zangelbert Bingledack
Thanks for the comments! I agree that there could be a series of jumps. We know the miners like BIP100 so this might actually draw in some serious hashing power which XT never received.

I am leaning towards the acceptance depth being on by default but OK to go with other opinion, considering the PR angle. Mainly because this is a key feature which maintains convergence, especially if, say, a lot of users have a 2MB limit, but the emergent network limit might be 2.2MB and occasional blocks occur larger than 2MB, the default acceptance depth keeps everyone on one fork and nodes functioning usefully. Maybe @theZerg (and others of course!) would have a view on that.

 

[Zangelbert Bingledack]

@solex

My concern is that objections like @jonny1000's would be raised ("acceptance depth enables doublespends"). Whether he is correct or just misunderstanding something, it suggests that such misunderstandings could be prevalent. Also, I didn't immediately see a knockdown response to his points, so I can imagine a lot of other people won't either.

It could kick up a lot of dust rightly or wrongly, and to me it seems that "default off but have a little message explaining what it does" would be just as good since the idea is to have users become more expert about their choices, which would include looking into the case for acceptance depths.

Note: IIRC, the acceptance depth was initially deemed to be necessary because of the way BU was conceptualized. However, I think our understanding of how consensus would be formed in BU has advanced since then; is it possible that it really wouldn't be necessary? I tend to think it would be helpful, but I mention that possibility just in case, since it's a classic pitfall to assume something decided on a while ago is still needed when other aspects have changed in the meantime.

 

[solex]

@Zangelbert Bingledack
Yeah. I see what you are saying. It probably is important not to have a default "back-door" in the BIP implementations. If people see their node is stuck then they are incentivized to learn about acceptance depth, and changing their BIP choice.

 

[Zangelbert Bingledack]

@solex

 

[solex]

@Zangelbert Bingledack
Fantastic! We are cooking with gas now

 

[Zangelbert Bingledack]

@theZerg Maybe I still don't understand.

 

[VeritasSapere]

@solex Yes, I love this idea!

 

[Zangelbert Bingledack]

@solex's proposal indeed make it fully clear that what BU does is *deny developers the sole power to set Schelling consensus*, as Core is now setting the Schelling points like blocksize cap in a centralized fashion that attempts to lock the user behind a wall of inconvenience.

Core's way *is* a powerful way of establishing a Schelling point, but it has the drawback of being centralized. ("What's next, checkpoints?") Eventually such an approach will be vesting too much power in a central group, and there is mounting evidence that this it already is.

The proposal would make it clear that BU is nothing more than that; it's not unlimited blocksize. It's really not about blocksize at all. It's merely an unbundling of "security code provision" from "Schelling-point setting." We hire Core/etc. for its secure code, not for its setting of consensus parameter Schelling points. Their recommendations can be taken into account without those recommendations being entangled with its software offerings. The entanglement is merely *inconvenient* to disentangle anyway.

This way we don't have to fight the blocksize debate. It's a one-two punch:

1) Get Schelling consensus points unbundled from software offerings, so that miners and nodes have full autonomy to allow consensus to emerge among themselves (or follow Core's recommendations, but this time without being goaded to by inconvenience)

2) Let miners and nodes, with now unfettered ability to converge on market-favored Schelling consensus parameters, raise the blocksize when they see fit, in the manner they see fit, without Core putting its finger on the scale. It just happens that *we* think this would result in much bigger blocks than Core in control would. There's no reason a small blockist couldn't get behind this proposal as well. Because *he* should think it will keep blocks small. No need to fight anymore.

BU is neutrality. BU is non-intervention in the consensus process.

 

[theZerg]

I'm confused... does the Articles say anything about having to ask for permission to get a number to post a BUIP?

EDIT: I don't want to pull discussion away from this BUIP but WRT accept depth, check out the last question on the FAQ. http://www.bitcoinunlimited.info/faq. Its a little rough I think. If you can clean it up or other FAQ questions post a separate topic or create a pull github pull req.

 

[Zangelbert Bingledack]

What about what /u/goldcakes is saying? Does the GFC having >50% of the hashing power invalidate the short blocks technique, or is this a matter of Core using "blocksize cap" to mean both max generate size and max accept size, and setting Schelling consensus from on high? In other words, small miners could just reject the bloat blocks, but then people would ask which fork is Bitcoin. With Core, the answer is provided from authority, and so the big miners can do bad things. With BU, though, the answer to what the Schelling consensus is is emergent; but this may require a new dynamic in exchanges, etc?? (How do they decide which fork is valid?)

 

[solex]

@theZerg
Haha indeed. I just didn't want to self-assign a number that someone else was about to use.

Thanks to all for the feedback, please continue to post any random thoughts which are relevant. I'll get moving on the BUIP "Multi-BIP Scaling Enabler"

 

[Aquent]

Hey. Was just reading the articles of federation and came across this:

"Formal interaction between members, including but not limited to BUIP submission and voting must occur via cryptographically verified identities. Members shall supply a Bitcoin public key when applying for membership and sign all formal communications with the corresponding private key."

Presumably this is to stop someone from creating many accounts and skewing the voting, so then we'd want the address to have a bitcoin balance otherwise anyone can create a new bitcoin address together with a new account.

I am not sure individuals would be comfortable with linking their bitcoin address to their real name or even nickname. The address may be in cold storage etc but even outside of practical considerations it would in effect amount to publishing your bank statements which many, for privacy reasons, would be very reluctant to do thus unnecessarily limiting membership and voting.

If the bitcoin address balance can be just 0 then we can instead ask for an e-mail address and require confirmation as it would set the same sort of effort barrier.

For identity verification then just a pgp key can be fine, but that should in my view be optional as there may be many members who are not highly technical and therefore may not be familiar with pgp keys.

Perhaps there should simply be a vetting process whereby new members, if providing their real name, are taken at face value, if providing a nickname are asked to show it's long standing use (defined as one year perhaps with constant activity), in both cases their nick email or real name email confirmation is required. This avoids any privacy concerns and further makes sockpupetting very difficult and a nick sybil attack probably impossible or requiring very high effort, time and money while being inclusive to every real individual who wants to take part.

By the way, I understand that voting is meant to happen by 15th of January 2016? I intend to run as Secretary so that I can maintain the website, but not sure if elections are officially open?

 

[theZerg]

I did not intend that members put a balance in their bitcoin address. Its not specified in the Articles. However that might be an anti-sockpuppet measure that we could adopt for anonymous members.

The purpose of the bitcoin address is to sign your communications like pgp does. Why not pgp? Because BU is supposed to be open to all and most non-coders/non-libertarians have trouble with it.

I think that it would be a lot easier for one of us to add a feature to BU that computes the SHA256 of a message and signs it with your BU address (it could even remember what that is), then it will be to teach every member to use gpg.

Elections are always open. Just create a BUIP, give it the next number and post it. The contents of the BUIP should contain your real name and the position you are running for. But other than that can be whatever you want them to be. (I would explain why you are qualified, your prior experience, and your vision (what you want to accomplish) in the position).

 

[TrevinHofmann]

Hi, everyone!

I am a big fan of the concept behind Bitcoin Unlimited. I've been looking at different node implementations and trying to decide how I would like to begin contributing to Bitcoin development, particularly with regards to the block size issue.

Instead of using GPG should we associate a bitcoin address with a member and sign using it?

I prefer PGP. Associating a Bitcoin address with an individual and repeatedly using it for message signatures seems to encourage misconceptions about addresses. Addresses are best treated like individual invoice numbers associated with a payment request. Reusing addresses and publicly linking them to an identity decreases security and privacy. A reused address is more vulnerable to quantum computing attacks and leaking information with a poor PRNG.

Also, I don't quite agree that PGP is exclusive or any more difficult to use than signing with Bitcoin addresses. I have a fairly short introductory tutorial, if anyone would like to try PGP.

This is why I brought it up, the word blockchain should indeed not be spelled with a capital when not at the start of a sentence, since it is not a name, unlike Bitcoin. Curious to see what everyone thinks though.

I made the decision to capitalize the B in Blockchain because that is the convention we decided upon for articles in Ledger. The logic was that if the word "blockchain" was acting as a proper noun it should be capitalized, and if it was acting as a regular noun it should not be.

I still prefer the use of "block chain" from the original Satoshi white paper. It seems to emphasize the meaning (a chain of blocks) over its use as a buzzword.

 

[Aquent]

I have nothing against individuals who want to fortify their identity by adding a pgp or bitcoin address signed key to their voting, but I think such additional security should be optional. The only reason why we may not want it to be optional is, from what I can see, two fold, hacking and Sybil attacks.

In regards to hacking, the same can be said for posting in this forum. That is @Peter__R for example can have his forum account here hacked and someone pretend it is him. It is unlikely such deception would last for more than a few hours however as we can expect the real Peter_R to let everyone know he was hacked. Moreover, such event is so unlikely as to make his constant pgp signing of messages unnecessary. That is different from binary releases of course which are rare and therefore the effort of signing is minimal and the security benefits very high.

The second is Sybil attack. If the member can simply sign a 0 balance bitcoin address though, then that is no protection from a Sybil attack. To create a new bitcoin address is very easy, as is to create a thousand of them. I think it is far more effective to simply ask for true name email confirmation or long standing nick confirmation with known members here of course taken at face value and new members asked to show long standing nick use and of course everyone free to fortify their identity by pgp or signed address if they wish.

The members logged in nick and password would then be their unique fingerprint and they would have the choice to fortify their identity if they wished by pgp or address signing so being inclusive to all while balancing against potential attacks.

I don't know what everyone thinks? We not there yet though in systematizing membership and voting in my opinion as we have to get the graphics and basic design of the site up first and prob the initial voting would have to be by forum members here saying yay or nay in threads, but, I thought to ask what you guys think about that article procedure in regards to voting.

 

[TrevinHofmann]

I agree that it is unnecessary to sign casual messages.

 

[theZerg]

Absolutely, I agree no need to sign casual messages. I was talking about your vote on a BUIP. If someone hacks the forum they could look for a bunch of inactive accounts and use them to swing a vote.

 

[TrevinHofmann]

Is anyone interested in using Slack for communication? I've created https://bitcoinunlimited.slack.com in case we want to use it.

Other options include IRC, email lists, Reddit, and obviously https://bitco.in/forum/.

Also, here is my PGP key: https://gist.github.com/thofmann/fc645404e45feb1f1944

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: SKS 1.1.5
Comment: Hostname: pgp.mit.edu
mQENBFXwhKUBCADiEpy6CuJdQ7+f1wHGPaXENji/BuakNMkQsyvDciKAVmmCEuD96oGHyITr
nxh2DTkrzBLWotKYy6VcTUXwTehu20MCvZuIFMEgPJq/kEgzKAuqK7K7STJXytF+24dHMhzi
9h2i8gtFqiSnhD8DASmPe4Ed0dpXeeeRHrrPUVX+TQjkw6MJeHxvusJTU856pmSGeWDQNLPf
KChpch0Eb+KqUPPMes6vW84EqXyVqonpt6rcZLh/+12X6jPh4HOLj4udkkUPtEJ7ShZpxi+F
HCm2AYrsvf5X9cWKNhv7Lv7d3Mw6STE8asVppZlbUJubR9dO/cKbyaqGI2J7RAmQBoV3ABEB
AAG0KFRyZXZpbiBIb2ZtYW5uIDx0cmV2aW5ob2ZtYW5uQGdtYWlsLmNvbT6JATkEEwEIACMF
AlXwhKUCGwMHCwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRBzffo9i1h4nhCwB/46pQ25
Nj+BA3TEpZ8ulJVLuIKgu56CDp842h3SY12wnTU4GfowhMoyqbN5edGdx8zx0sVmAP5GQzph
p7DgOSaJAtdj6SbaFHo1bn20+Bj9lLUgRMLVmfsC57XveWVS0YVLqdKOnVSmMNCWqO1QDjfk
nMa37IZebvwr6uAD2q3gPPoxBJmQk5BYlu/AKGYHHZCZbAdhALfx8V2Ako/5Wk/2vMeF88q+
C3M9I2olXoa6lhTx0F75FVBCG8O29p0wNNxfmM5Q34949+0rrXy1Mb2z8TXIWc+bN9ndIT3w
Zt3y1GBoFfyQh65dm7fUSHyWLXdCiEbRQFUfzc+JrFkSqNnfuQENBFXwhKUBCACyyN4SMwq1
/73pTkqrklOpfe6THfLUQb4icq1y04yWFmdT9PUQ4xEMpEGhJAvm7ve8SPCI7Jjd3Ts28M5k
Pe11i9EjvFWw3AzgTSD7Dv/JuzGCyW7CouWluf82QEGuBcv0xUUQmPKXHCe2y3KmMnh8VJQs
nKTPXlucStS3lOpeYGRokUuZLFSNXTDOlHNeebSogILc6wlHu+mUXEaYtwNAMiXeXDTCTZZW
7iKw7KCzhy9NoOA53F6HjPGufwnX5gHhbY5jMzXFul3Nlnu150FKGzEnwkuhcNsD37jclvpX
9AzmMLGltgQCr3YoU1tdIjThfhM6z64Ji+4YlWTXRDmRABEBAAGJAR8EGAEIAAkFAlXwhKUC
GwwACgkQc336PYtYeJ5yZggAlAsYQtPp5+t4claicXCpX2XfcTNwB0WJo2+DHts3aBSA8/5l
2T9OWjFUoakrL1scVo3TlewhghBRncgc+nLY9nz1jH9uCqfh+3mCmWJKJ5wAsWY+sRAvZwm6
865Ej355sF+W4p5tQxy5NqLLvBxx+BqdXxGLNN7LzKMcwG4bZTSgxozF8S70c7WrkePxBo80
3DuHfzdxMhiVs8TsEcpkYI09TfV0d2F4JdzcSemQGeIu2AICoaEDAFUzI19WPPPyfsOFZmUA
exWCddoSkZD0Bnh8PgTW4PH7dHqNv/Ue591wh2YLSNqbg4xJ8itgvGCrU2V53e4lXabZmb0b
NHDx1A==
=Kk0Y
-----END PGP PUBLIC KEY BLOCK-----