bitcoin "unlimited" seeks review

[JackH]

Your limit is a function of the resources you want your node to consume. Above that limit, your node either rejects large blocks that are spam (not accepted by the longest chain), or drops off the network because it can't keep up.

So does BU follow the longest chain or not?

If not, than it obviously can't work, as it was pointed out a million times already - everybody will fork off randomly according to their limit.

If it follows the longest chain, then your limit doesn't matter, as eventually you will have to switch (otherwise, again, you will be forked off).

Since BU can only work if it follows miners, your personal limit becomes irrelevant: if you insist on setting it, you will just hurt yourself and will still have to eventually switch if you plan to continue using Bitcoin.

This limit cannot be used as a signal to miners because of Sybil attacks, so it's pointless.

Yet BU proponents push it as the main feature of BU

It follows the longest chain as long as it can (based on your resources), and if it can no longer follow, it drops out.

The personal limit can be of value as a signal, since there is no automatism between your "vote" and increased block size.
There is little basis for the assumption that miners will be foolish enough to fall for a simple Sybil attack through this channel.
And BU proponents do not think this signal information is the main feature, that's a silly assumption to make.

My personal limit can mimic 2000 limits. Thus I can spoof the network to behave as if it is ready for 1.5MB. If the miners believe that, its only a matter of time.

We have covered this 10 times in the thread now, yet we are given no answer to how you would prevent an incremental Sybil attack like brg444 posted.

[LovelyDay]

Plus, the need for BU review stands regardless.

Gavin at least has already looked at the code, and while he found code smells in places, his comments were not immediately dismissive.

So I think anyone willing to further review the BU code is welcome to, given that it's openly published.

It might make sense to take such review to where the Bitcoin Unlimited developers are, just like Gavin did.

[Zangelbert Bingledack]

If I modify core it is no longer core consensus rules. No I cannot do the SAME sybil attack on core.

Correct me if I'm wrong, but it sounds like you're making the point that there are lot of dumb people out there, so some miners and nodes will likely be dumb and set BU in ways that are unprofitable. Could be, but those same people might run XT or mod their Core foolishly.

For example, any smart miner running BU right now would want to mimic Core settings - unless they didn't mind losing money to make a point. If dumb people are the worry, set the defaults to mimic Core behavior exactly and include a scary warning not to change the settings or lose money. If they're dumb enough to still do it, they're dumb enough to send their coins to the wrong address, etc. I don't see dumb people as a big issue - do you?

[Bergmann_Christoph]

If you are a miner, and you know a block of size X can be processed by 85% of the network, but not 100%, do you mine it? If by 'network', we mean hashrate, then definitely! 85% is high enough that you'll be able to build the longest chain. The miners that can't keep up will be pruned, and then the target for '85% fastest' moves - now a smaller set of miners represents 85% and you can move the block size up, pruning another set of miners.

If by 'network', you mean all nodes... today we already have nodes that can't keep up. So by necessity you are picking a subset of nodes that can keep up, and a subset that cannot. So, now you are deciding who is safe to prune. Raspi's? Probably safe. Single merchants that run their own nodes on desktop hardware? Probably safe. All desktop hardware, but none of the exchanges? Maybe not safe today. But if you've been near desktop levels for a while, and slowly driving off the slower desktops, at some point you might only be driving away 10 nodes to jump up to 'small datacenter' levels.

And so it continues anyway. You get perpetual centralization pressure because there will always be that temptation to drive off that slowest subset of the network since by doing so you can claim more transaction fees.

This is indeed a headspinning attack and should be considered carefully. While Satoshi was able to publish Bitcoin with many opportunities to attack, today such an option is no longer reasonable since the value of the network did explode.

I don't feel comfortable to argue with you on this as you obviously know more about bitcoin (technically) than me. But since the envirenment here seems a bit more hostile against BU than healthy-critical and the persons knowing most about BU are not willing to attempt this discussion in this forum for reasons I can understand, let me give a try to be the "angel's advocate": I think this attack is based on strange assumptions:

- you assume a correlation between miner's hashrate and miner's capability to deal with large blocks. I don't see this. In fact the great firewall indicates the opposite.
- you assume that a small increase of the blocklimit can prune miners out. I don't see this, since miners are free to not fill up blocks, download capacity is no issue and miners can easily set an upload-limit for their node. Or am I missing something?
- you assume that miners will blindly follow the pruning and unknowingly support the 85%-attack while the number of nodes and miners are dwarfing. This is assuming they act against their own financial incentive.
- you assume the honest miners will not detect the 2,000-nodes-sybill-attack, which can easily to detected by using some basic statistics like median, average and standard deviation. Miners can decrease the blocklimit if they feel something going on.

Sure, an blocksize increase will lead to the pruning of some nodes. For example, my excessive poor internet connection will force me to limit the upload of my node (which is easily possible with BU's gui) when blocks reach 2 MB, so that I will no longer be able to propagate blocks to 8 peers in 30 seconds. Maybe to 4 or 5. But I think this will be inevitable since blocks have to increase in size.

But after all I feel far from being comfortable with this attack possibility and regard it as a serious concern for Bitcoin Unlimited.

[achow101]

How exactly does setting the block size limit constitute as a vote for that block size? How would anyone else know that you set your node to accept a certain maximum block size? If there is no mechanism for this (and I couldn't find any in the code), then a lot of things said here are wrong.

If there is no mechanism that tells everyone else what they are accepting as the max block size, then there is no voting happening. A sybil attack wouldn't work since there is no voting.

Additionally, miners wouldn't know when to increase the block size as the safe method of deploying the block size limit as a hard fork is no longer there. It could result in either nothing happening as miners want to play it safe, or the blockchain forking in multiple ways as miners test out different block sizes. Either way could be catastrophic.

Lastly, why would it be a good idea for users (especially non-technical users) to decide what their block size limit is? Not everyone is smart enough to know all of the implications of why a certain block size limit should be accepted or not.

[Zangelbert Bingledack]

To make it as clear as possible regarding Sybil attacks, any miner now running BU would be a fool to deviate from 1MB settings. Any node now running BU for business purposes would be a fool to deviate from 1MB settings. (Unless to make a point, experiment, etc.)

That is why a Sybil attack won't work and has nothing to do with BU. The reason people think it has something to do with BU is, people think consensus comes from everyone trusting the Core devs to set it. It doesn't. It comes from everyone having skin in the game and knowing if they deviate from the prevailing consensus in the network - no matter how it arose - they lose money. Yes, Core's approach does guard against the occasional careless miner who would accidentally or just foolishly mess with their settings, but that can be handled with warnings, etc. in the GUI. Careless users can lose money in a lot of ways already.

Changing the settings happens on market timing, probably with several months of debate and planning as consensus coalesces. Just like now except the options are not just Core vs. XT.

[LovelyDay]

We have covered this 10 times in the thread now, yet we are given no answer to how you would prevent an incremental Sybil attack like brg444 posted.

I think you've just not understood the answers you've been given multiple times:

BU does not by itself open up a new Sybil attack vector - anything you've described can be used against Core just as easily.

This will be my last post on this "Sybil attack" hobby horse. Over and out.

P.S. So far since joining this thread, I've been kicked off by the forum software once, denied login for 45s, and now throttled for posting within a 360s cool-off period.
You may find these settings useful on your forum, but they do not contribute to my good experience as a new user trying to participate in this thread.
FWIW I've never run into such limits on the other forum proposed to hold this discussion.

[BldSwtTrs]

So still not one person on the BU side is willing to tackle the faulty assumption that user defined parameters is somehow a good way to signal the economic majority's preferred blocksize to miners, making its one distinctive aspect pretty much worthless.

Maybe you should care to explain why it's a faulty assumption for starters.

Keep up with the thread please.

Two words: sybil attack

A signal can be more or less reliable, miners will analyze their environment like every intelligent human beings are able to do so.

For example :
- transactions are slow because blocksize limit is often hit + nothing suspicous in the nodes activity + a majority of nodes signals their wish to increase the blocksize => miners will choose to increase the blocksize according to the nodes
- blocks are way below the limit + suspicious nodes activity + a majority of nodes signal their wish to increase the blocksize => miners will choose to no increase the blocksize

Basically it's likely that the blocksize will only be increased when it's needed.

[Zangelbert Bingledack]

Additionally, miners wouldn't know when to increase the block size as the safe method of deploying the block size limit as a hard fork is no longer there. It could result in either nothing happening as miners want to play it safe, or the blockchain forking in multiple ways as miners test out different block sizes. Either way could be catastrophic.

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. 

Lastly, why would it be a good idea for users (especially non-technical users) to decide what their block size limit is? Not everyone is smart enough to know all of the implications of why a certain block size limit should be accepted or not.

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.

[LovelyDay]

A signal can be more a less reliable, miners will analyze their environment like every intelligent human beings are able to do so.

For example :
- transactions are slow because blocksize limit is often hit + nothing suspicous in the nodes activity + a majority of nodes signals their wish to increase the blocksize => miners will choose to increase the blocksize according to the nodes
- blocks are way below the limit + suspicious nodes activity + a majority of nodes signal their wish to increase the blocksize => miners will choose to no increase the blocksize

Basically it's likely that the blocksize will only be increased when it's needed.

As I understand it, miners would presumably communicate with each other, since other forms of ostracization of uncooperative fellows are entirely within their realm of possibility.

From the somewhat unified appearance of the Chinese miners at the last conference, a conservative approach seems to strongly match their behaviour.

And they would want node operators, businesses and end users supporting their move, so they would indicate a serious desire to raise the limit to the other stakeholders in advance and in plain language so that preparations could be made.

This is what I actually expect to happen, whether BU receives wider adoption or not - if there is no Economic Change Event beforehand. Or perhaps there has to be one for all to learn a lesson.

[NxtChg]

Of course users would converge on a BIP...

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.

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

[BitUsher]

My initial reaction is that I don't think its a good idea to empower non-technical people with the ability to control such an important variable with a click of a button. I suppose they would be held into account by the miners and this would essentially be a node vote which would allow individual nodes to confirm larger blocks easier. The difference may not be significant as an attacker isn't going to be limited by the code and this could be a signal to allow users to vote. This change appears to me to have more political implications than anything.  

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.

This clarifies a lot. This indicates that BU is more of a political difference than technical one. Re-flexibly I am drawn to this idea as it represents empowering the users with more of a voice where they have more of a stake in the decision process and this could be a method of incentivizing full nodes. On the flip side this does take away some of the power from developers and this can have some negative consequences as technical decisions based upon meritocracy now become political decisions based upon node vote for BIPs. Another concern is that many of these very talented developers are donating their time on a volunteer basis and one of the primary things that incentivizes their contributions is them having a say in the direction of this open source project.

 I am not so naive to believe there are no personal motivations behind some of the developers steering code to favor their side business as one of their motivations, but have more of a nuanced view and believe developers have multiple motivations from securing the code and peoples investments (including their own) , to philosophical motivations for what bitcoin represents and its impact upon society, to enjoying the challenge of the project and fun of learning.

BU brings up many complex issues about governance which I will have to reflect upon more.

[adam3us]

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

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.

So what happens if I left my node at 1MB +10% user threshold and a 1.2MB block comes - does my node reject it? How will the network not split into a myriad little shards which diverge following accidental and/or intentional double-spends without manual human coordination?

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.

and another one:

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

_{Mod note: fixed quote links}

[Zangelbert Bingledack]

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

Yep, you got. EDIT: At least that's how I see it. There are many ideas about how it might go. I prefer to focus on the user-selectable blocksize limit only, because that is a simpler issue. Besides, the other features can be turned off easily until they have more theoretical and experimental vetting. Or a forked client can be offered without those other options if people think that's too dangerous an option to give to the user. So I don't see it as material to the main question of whether it's a good idea to allow users to set the blocksize themselves.

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

I mentioned this above, but things like BIP101, BIP102, etc. will be selectable as options. Consider a scenario where XT/BIP101 were adopted. The difference between the current situation and a scenario where BU is dominant:

• Current situation: People notice the majority is moving to XT, flagging support for BIP101, so even the Core users switch to XT. On the flag day some stragglers might remain and cause a fork.
• If BU is the dominant implementation: People notice the majority is moving to BIP101, flagging support for BIP101, so even people that prefer 1MB or 2MB or whatever switch to BIP101. On the flag day some stragglers might remain and cause a fork.

Doesn't seem that different, right? The only real difference is that options aren't just Core's chosen blocksize cap and BIP101. There would be BIP102, etc. to choose from, as well as other options not given by Core or XT. It'd be very much like there weren't just Core and XT, but Core, XT, and a bunch more to choose from, and we see who wins - just like now except with BU the consensus-parameter-setting is unbundled from the secure-code-providing service of the Core/XT/etc. devs.

Rather than being spoonfed consensus options from an ivory tower (or two ivory towers), there are many options. Convergence on one options happens the same way, for the same reasons - just smoother.

[iCEBREAKER]

If you want info about Bitcoin Unlimited you should check out their forum (https://bitco.in/forum/forums/bitcoin-unlimited.15/). Most of their discussions is there, including technical and not.

The idea was to have some technical focussed constructive discourse and this is a more neutral forum and also where more Bitcoin experts hang out.

Adam

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.  

Very nice to see Dr. Backamoto drolly trolling the F*CK out of the Gavinistas, albeit in his studiously academic Sword of Logic idiom!   

Weak blocks, etc. are great ideas....for an altcoin.  Because Bitcoin's social contract is at this point, for better or worse, ossified and absent a crisis basically carved in stone.

Here's all the info you need to know about Unlimiturd: you may have any block size you want, so long as it's <16MB.   

Never mind the hilarity of "Bitcoin" "Unlimited" selecting a max_block_size LIMITED to 20% less than GavinCoin's original ill-conceived 20MB proposal.

Ignore the obvious problem of Sybil attacks, especially those exploiting BTC's current crummy P2P code and superlinear vulnerability to maliciously construed (ie very slow to verify) blocks.

The important thing is to distill our hatred of Thermos/Core/Blockstream/MPEX into a singular frame, such as the currently popular "North Korea" canard.

Only when Hearn's Redditard Army is unified around a common theme can the next stage of his puppet masters' Manufacturing Dissent strategem be enacted....

Too bad for them sunlight is the best disinfectant, and this thread is the functional equivalent of a coronal mass ejection right onto the Coinbase Pointy-headed CEO, Bitcoin Judas, Frap.doc, and Peter R's stupid faces!   

[BitUsher]

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

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.

[cr1776]

This.

Right now the only difference is a nice front end to change a parameter (ignoring again other issues to keep the network secure).  Even a non programmer can edit it easily.

"user-selectable blocksize cap" aspect -

1) So I fire up 2000 nodes, all selecting 200MB as cap.

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

3) They all 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

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.

[Zangelbert Bingledack]

In case anyone was wondering if letting users select their own blocksize cap is a total wacko idea that some Bitcoin newbs came up with, note that Gavin supported that idea in 2013:



Doesn't mean it's not a wacko idea! It could well be. But it should give an idea that it's not totally out of left field. I encourage everyone to read the thread from back then:

https://bitcointalk.org/index.php?topic=140233.msg1503099#msg1503099

Many points likely to be raised here were addressed back then as well.

[Zangelbert Bingledack]

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.

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.

[iCEBREAKER]

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.

Peter R is using shopworn 1990s chaos theory rhetoric to sell Unlimiturd.   

Specifically, he's invoking the 'spontaneous/emergent order' frame to bedazzle and persuade the drooling masses.

But his hand-waving about chaotic dynamic systems does not apply to Bitcoin, because although Bitcoin is certainly chaotic (and thus gratifyingly dramatic  ) it is *NOT* dynamic, as the social contract (SHA256 PoW, 10 minute solution target, 21e6 emission, 1MB max block, pay-for-priority) cannot change one iota without alienating a dominant plurality of the socioeconomic majority's critical mass.