Here's a comment from my reddit relevant to BU. [/u/ForkiusMaximus in reply to /u/kanzure.] >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 points1 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." I t 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. Not sure whether I'm allowed to link to reddit, but it was in the thread titled "I just submitted a BIP that would allow users to decide which features to enable. Btcdrak rejected it (he's also controlling the dev mailing list). So I'm posting it here." by /u/anarchystar. |
|
|
|
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. |
|
|
|
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#msg1503099Many points likely to be raised here were addressed back then as well. |
|
|
|
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. |
|
|
|
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. |
|
|
|
|
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.
|
|
|
|
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? |
|
|
|
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  Some BU proponents don't understand BU and have a lot of odd ideas about it. The main feature is that it lets the user select what the biggest block they will accept and the biggest block they will mine, instead of these being fixed at 1MB (or whatever). In practice, right now, any miner would be foolish to mine with settings besides 1MB. The idea is simply that users can basically choose their BIP rather than having it bundled in with Core/XT. Perhaps that makes more sense? Of course users would converge on a BIP (something BIP-like proposed by someone else) - just like they converge on Core or XT based on what they see others are doing. |
|
|
|
Actually, my Sybil attack can go something like this:
1) Vote for 1.5 MB blocks
2) Check how many nodes I have killed with the increase
3) Vote for 2MB blocks
4) Check how many nodes I have killed with the increase
X) Keep doing until I am the network of nodes. Fill up the blocks and start pushing out the Chinese miners as well.
Incremental Sybil attack, cheap and easy to pull off.
You can do the same with Core by modding it. Unless you're making assumptions about how people would configure their settings. Sure, if you think people will do unprofitable things without Core supervision, then yeah that could happen. I tend to think people with skin in the game will not do anything silly. A few may try, lose money, end of story - in fact this happened at the halving in November 2012 when a few miners modded their Core clients to keep getting 50 BTC per block. They lost $500 per pop, then "we never did that again." |
|
|
|
"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. |
|
|
|
Current situation: blocksize cap for the network is set by miners/nodes converging on either Core, XT or something else by downloading and running Core, XT, etc. ... and making the decision not to modify this code. Yeah, and it's worth noting the reasons people don't usually mod the blocksize in Core: because there are overwhelming economic incentives for a miner not to mine or build on a block that will likely be orphaned, and overwhelming economic incentives for node operators doing business not to accept such blocks. The same incentives apply to BU. There are [repeating the above verbatim] "overwhelming economic incentives for a miner not to mine or build on a block that will likely be orphaned, and overwhelming economic incentives for node operators doing business not to accept such blocks." As far as I understand it, BU merely removes the artificial authoritative "oomph" of the blocksize cap setting being hardwired in Core (and XT). It can be made to default to Core's blocksize cap settings (it doesn't now, but it would be trivial to make a fork that does), and there can be scary warnings about changing it away from Core's settings. It just takes away the inconvenience barrier, with the hope that people would follow a different Schelling point than the one set by Core. Failure of BU probably means just "everyone sets their settings to mimic Core." That's about the worst it could go, provided there are no coding errors (community definitely should vet it carefully; better yet, Core could just make the blocksize cap user-selectable). |
|
|
|
I still am curious as to what the difference is besides the nodes being able to signal to the ecosystem in a slightly easier way through a GUI that they wish larger blocks. Is this it?
I think there are a lot of misunderstandings about BU. The main idea is dirt simple: - Current situation: blocksize cap for the network is set by miners/nodes converging on either Core, XT or something else by downloading and running Core, XT, etc.
- With user-selectable blocksize cap: blocksize cap for the network is set by miners/nodes converging on either Core settings, XT settings (BIP101), or some other Schelling point by adjusting their settings to do so (BU can be made to default to Core settings, if you want)
There's another "oversized block acceptance depth" feature LovelyDay mentioned that is envisioned may come in handy, but it can be turned off anyway so I'll focus on just the "user-selectable blocksize cap" aspect. This is all it is. |
|
|
|
I am amiss to what that "1%" cited difference actually is. Any hints?
I just meant, if you are spending a ton of money to set up 1000 nodes, the cost of hiring a C++ coder to mod your Core code is going to be negligible ("1%" of your dough might be spent on hiring the coder). That's why it has nothing to do with BU, as in that case the convenience barrier is irrelevant. |
|
|
|
If I setup 2000 nodes, each voting for a 200MB block, thus overtaking consensus, what prevents a step 2 scenario from happening, where a miner that gets lucky starts mining 200MB blocks and propagating those. Longest chain is mine, as I run the most nodes. This is not unique to BU, which is why I say it seems to have little to do with the OP. Again, a simple modding of the code is not going to stop someone that motivated, nor a miner willing to risk 25 BTC a block to try this. I'd love to see a hard question for BU, but this sounds to me like a hard question for Core, at best (I think incentives would prevent this, but again that's just me defending Core, not on topic). |
|
|
|
Yes, I would rather move onto other topics, but can you explain to me the "1% easier" difference in 1 post assuming future possibility of a majority of miners support BU and relegate the blocksize to nodes instead of themselves ? There's no such thing as "majority of miners support BU," other than "majority of miners run BU." The majority of miners can run BU with Core settings, for example. So I'm really not sure what you're asking here, especially by saying "relegate blocksize to nodes." |
|
|
|
|
BitUsher, so you're saying an attacker spinning up all those nodes would encourage a bunch of other people to raise their limits to 200MB? Similar to what I said above, any miner wishing to take advantage of the situation and mine 200MB blocks is not going to be deterred by having to mod the code a bit. Miners already do that, in fact. Again, BU is only a change in convenience; if convenience is the different between Bitcoin being secure and insecure, we have bigger problems already (soon enough someone's just gonna make a patch, then it will be dirt simple to mod any consensus setting). It won't likely be fruitful to critique BU along those lines.
I'm pretty sure continued discussion on this point would clutter the thread quite a bit and not really be related to what Adam is asking about. Maybe make a new thread?
|
|
|
|
|
Not sure what you mean. I'm just saying if someone wanted to create a fork of Core with a 200MB blocksize cap now, it's not difficult. Then if they had the resources to deploy 1000 nodes, we'd be at your scenario.
Point is, this has nothing to do with BU.
|
|
|
|
|
I would say a Sybil attacker with the resources to cook up 1000 nodes will have no trouble modding a bit of C++ code or hiring a coder to do that. That's the least of the barriers, and even if it were to be relied on, that would be a losing battle. If inconvenience were all that is keeping Bitcoin secure, we would have a problem. Also see my edit to the post immediately above yours.
|
|
|
|
Isn't the difference being that BU will allow maxBlockSize to be determined by nodes and core/xt/ect... insures that miners make that decision, or am I missing something? Well, that is already the case. BU just makes it more convenient. And granular: you don't just have a choice between Core@1MB and XT@8MB+, but rather anything - but the increased number of options doesn't mean users can't converge on a Schelling point; more options doesn't mean more viable options. I imagine a series of jumps from one Schelling-point consensus to the next. For example, first everyone warily converges on Pieter's very conservative BIP (+17%/year), 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 nodes/miners - as the foremost experts on the network - move independently of the devs to create their own Schelling points. A specialization and division of labor would occur as it should in any mature industry, with consensus-parameter-setting unbundled from the software offerings of Core/etc. People would "hire" the Core/etc. devs for their secure code, not for their determining of consensus parameters. Those would be set by the larger market, reacting dynamically to market conditions. To do otherwise is arguably a security risk as it concentrates power in one team of devs. |
|
|
|
|
There's nothing stopping an attacker from modding the Core client themselves and setting up 2000 nodes with 200MB blocks. Or at least, it's not the little bit of C++ coding that's likely going to be what stops them.
Bitcoin Unlimited is NOT a big blocks client, let alone an "unlimited blocksize" client. The "unlimited" only refers to unlimited options. At this time, BU is simply Core + a few options. They can all be turned off to mimic Core exactly.
|
|
|
|
|
Show Posts
