Gold collapsing. Bitcoin UP.

[cypherdoc]

@rocks

this shows it better. plus, note the 200DMA has turned UP after the classic double bottom flush as price has crossed back up over the top:

 

[theZerg]

@rocks if LukeJr or any other half competent coder wanted to not relay blocks > X MB it would take about 10 minutes to make the changes in the code to do so. Its literally a constant defined in some header file. Whether they choose a 1 MB limit sybil attack has nothing to with the existence of BU. It is awkward that people can Sybil attack the node network, just like it is awkward that miners can artificially inflate blocks to arbitrary size by adding dust self-transactions. But pretending that those problems don't exist by hiding them is burying your head in the sand.

In your messages, I am hearing you say "Let's force users to do it this way because we know best." But how does that make you any different than Bitcoin Core devs? Just like them, you know best and feel perfectly comfortable making these decisions on behalf of the users and ramming them down their throats "for the good of the network".

I see the "Unlimited" name in Bitcoin Unlimited very differently than you do. BU does not LIMIT the users choices. Instead we believe that the protocol itself is (and needs to be) robust enough to handle user choice. Because if its not some hacker will abuse it anyway (as we see with the malleability attacks). But we can do even better than just tolerating -- we can design it so that the larger system benefits from the user's choices.

Its simply unbelievable how many people extol the benefits of the free market but when it comes down to a particular decision they are incapable of actually trusting in the free market, instead preferring their own "enlightened" view.

 

[cypherdoc]

wow. okaaaay:

 

[Peter R]

Yes, the rules in purple were added over time after Satoshi left. My question continues to be why add a new purple blocksize rule for individual nodes? Nodes reject blocks by not passing them on. Adding a new relay limit is in effect making it possible for nodes to reject blocks over some level. That is not unlimited.

If the concern is network limitations for non-mining nodes, then add upload/download parameter limits. But don't enable what is essentially a new block rejection rule based on size.

I also continue to believe that non-mining nodes should either "keep up" with the longest valid chain or drop off. Rejecting larger blocks (which is what not relaying is), is counter productive to the BU concept IMHO. Non-mining nodes simply should not be able to influence what is consensus over size, they do not participate in the POW work mechanism and thus are Sybil attack vectors.

This will be my last post on the topic. I understand you guys see it differently, but I continue to be concerned over adding what looks to be a new path to reject large blocks and see adverse effects, effects we probably won't see in the next few years, but will see over time.

Edit: Remember, guys like LukeJr have stated they think 1MB is too large. What if a bunch of them spin up 10,000 BU nodes with a relay limit of 100K? We just made it easy to hold things back.

Thanks for the response, @rocks.

Although I see a system with a sort of "meta-consensus" like we're proposing as the eventual future, I think you have a point that it represents a big step in thought. The question is what would win more popular support?

 

[rocks]

In your messages, I am hearing you say "Let's force users to do it this way because we know best." [B] But how does that make you any different than Bitcoin Core devs?[/B] Just like them, you know best and feel perfectly comfortable making these decisions on behalf of the users and ramming them down their throats "for the good of the network".

If you're going to make that claim then I could also say you are forcing people to vote for bip101 and bip100 since BU automatically votes for those. Both statements are equally absurd.

BU is suppose to be about having the choice of a client that removes all constraints on block size at the consensus layer, so that the market can find a clearing price and volume for transactions. Not relaying blocks is in effect the same as rejecting them, which is in fact adding a new consensus layer constraint on block sizes, opposite of BU's stated goals.

Its absurd to attack me and say I'm trying to force anything on anyone. I'm trying to show you that you are creating a new consensus layer constraint opposite of BU's stated goals.

 

[cypherdoc]

i think with the price going up, we'd be lucky to get just the unlimited part of the proposal accepted by the community.

it also could be the last change we might need/get so we need to make it as uncontroversial as possible. a single change would certainly be simpler from a coding standpoint. i'd hate to repeat what appears to be the mistakes that Mike made; inserting other changes (as good as they might be) to 101 that the small blockists tore apart.

one step at at time.

 

[Mengerian]

Edit: Remember, guys like LukeJr have stated they think 1MB is too large. What if a bunch of them spin up 10,000 BU nodes with a relay limit of 100K? We just made it easy to hold things back.

This is a good thought experiment to think through how the network could respond to nodes trying to be disruptive.

It seems to me that you would still have 6000 nodes relaying large blocks, so they would still propagate through the network, and the disruption would be minimal. But from a node operator's point of view, you probably want to make sure to connect to nodes that relay the large blocks. So you would want to monitor the behavior of nodes you're connected to, and preferentially connect to certain well behaved nodes.

In general, over time, nodes should develop ways of dealing with other nodes that may be "misbehaving". If Bitcoin as a system is going to be successful, it needs to be resilient to anti-social behaviors by some. Hopefully if most nodes just act in their self interest, and can defend against disruptive behavior, then the network as a whole can be resilient destructive actors.

 

[Zangelbert Bingledack]

@rocks and @theZerg

No time to post at length right now, but I'm very much enjoying your discussion around the question of what we really mean or should mean by "unlimited." It's an interesting question in that a multiplicity of implementations already potentially gives the user a choice of blocksize policy at the point when they choose an implementation, but should choosing BU itself constitute a vote against a hardcoded blocksize cap, or should it offer a further choice within itself?

In other words, would we have a better result (i.e., lower chance of a restrictive hard blockzise cap) if the market equilibrium on blocksize were determined by the balance among user choices of implementations as per @Peter R's animated pie chart, or by choices users specify within BU (and other implementations, if they offer a choice)?

In a world where BU becomes the dominant implementation, theZerg's view makes sense: why say we know what's best for the user, especially when it is trivial to change? In a world where BU becomes the "kill the damn cap" implementation, though, rocks' view makes sense: it should do what it says on the label.

Do we want to attract the most users by giving them complete choice, or do we want to make it a matter of attracting all the "no hard cap" users without dilution of the pure vision? Do we want the "voting" to happen within implementations or between them? Do we gain more (in terms of removing/allieviating hard caps) by big-tentism or by purity? Is "leaving it to the market" best understood to include the meta-idea of also leaving the choice of whether to leave it to the market to the market (i.e., not just letting blocksize be chosen economically, but letting users decide how much economic freedom they want to vote for; in other words laissez faire or "laissez faire on the matter of laissez faire")?

I must say I'm finding it hard to conceptualize the whole scope of what we're really looking at here without some kind of visual map of the arguments.

 

[cypherdoc]

@rocks has a point when he says we are being inconsistent when we say block size should be confined to the transport layer while at the same time wanting to push a degree of consensus/control out to the nodes.
[doublepost=1445577148,1445576498][/doublepost]If we simply remove the cap, all we have to say to justify our decision is that we've returned the code back to its original state that satoshi envisioned. Period. End of discussion.

If the market can't accept that, then they'll never accept anything in addition.

 

[cypherdoc]

Bitcoin on the move!

 

[AdrianX]

@rocks and @theZerg

No time to post at length right now, but I'm very much enjoying your discussion around the question of what we really mean or should mean by "unlimited." It's an interesting question in that a multiplicity of implementations already potentially gives the user a choice of blocksize policy at the point when they choose an implementation, but should choosing BU itself constitute a vote against a hardcoded blocksize cap, or should it offer a further choice within itself?

In other words, would we have a better result (i.e., lower chance of a restrictive hard blockzise cap) if the market equilibrium on blocksize were determined by the balance among user choices of implementations as per @Peter R's animated pie chart, or by choices users specify within BU (and other implementations, if they offer a choice)?

In a world where BU becomes the dominant implementation, theZerg's view makes sense: why say we know what's best for the user, especially when it is trivial to change? In a world where BU becomes the "kill the damn cap" implementation, though, rocks' view makes sense: it should do what it says on the label.

Do we want to attract the most users by giving them complete choice, or do we want to make it a matter of attracting all the "no hard cap" users without dilution of the pure vision? Do we want the "voting" to happen within implementations or between them? Do we gain more (in terms of removing/allieviating hard caps) by big-tentism or by purity? Is "leaving it to the market" best understood to include the meta-idea of also leaving the choice of whether to leave it to the market to the market (i.e., not just letting blocksize be chosen economically, but letting users decide how much economic freedom they want to vote for; in other words laissez faire or "laissez faire on the matter of laissez faire")?

I must say I'm finding it hard to conceptualize the whole scope of what we're really looking at here without some kind of visual map of the arguments.

I read laissez faireit and wanted to say I'm in support of as liberal and free market as is possibly viable. and to put it in context with my understanding.

Collectively the nodes control miners by validating the blocks they mine. Collectively nodes already have the most control in the network. That control comes at a cost; first nodes have to host and keep the blockchain up to date and secondly they have to stay in sync with and represent the collective consensus.

Control is not up to individual node but all nodes collectively. The blockchain is the collective consensus of all nodes. The way I understand it, consensus is laissez faireit it is an emergent property, represented by the longest chain.

We have what seems like a bit of a control issue and gridlock when it comes to larger blocks at the moment. I think it’s temporary, I’m optimistic BIP 101 is going to make it into Bitcoin and I’m sure BU is going to help make it happen. I am not yet convinced we need to give more power to nodes, I think giving them more power over block size is encroaching too far and threatening the few liberties available to miners.

@Peter R I still owe you a response to my non nonsensical post on page 65. @rocks has been largely representing my concerns.

 

[cypherdoc]

The way users can express their dissatisfaction with the BU block size is to stop running the software altogether.

 

[cbeast]

I still don't get side-chains. They are altcoins you are trusting someone to exchange arbitrarily even if they become worthless. Seems altruistic or just naive.

 

[theZerg]

If you're going to make that claim then I could also say you are forcing people to vote for bip101 and bip100 since BU automatically votes for those. Both statements are equally absurd.

BU is suppose to be about having the choice of a client that removes all constraints on block size at the consensus layer, so that the market can find a clearing price and volume for transactions. Not relaying blocks is in effect the same as rejecting them, which is in fact adding a new consensus layer constraint on block sizes, opposite of BU's stated goals.

Its absurd to attack me and say I'm trying to force anything on anyone. I'm trying to show you that you are creating a new consensus layer constraint opposite of BU's stated goals.

@rocks First of all, noone has discussed the details of whether bip100/101 tagging would be configurable. I would probably add options to turn on/off bip100/101 tagging for the simple reason of "what if one of the BIPs is retracted or a user likes 101 but not 100"? Yet at the same time, if we choose not to make these optional the reason could not be to remove choice from the user (after all, he can always use another client to get that functionality) but simple expediency.

@cypherdoc you might have a point about public opinion which can be swayed irrespective of facts. However if these features are optional it is very difficult to claim we are forcing them on anyone which is I think more what hamstrung XT.

To all of you, I am arguing the BU return consensus back to how Satoshi envisioned it. And that BU enable the utilization of power that nodes have always had. All that I'm suggesting be added are graphical buttons and dials to access functionality that a developer can already easily tweak. Do some of you want to level the playing field between devs and the rest? This is how to do it.

 

[yrral86]

BI should just eliminate the cap. If you want to add configuration options to limit resource usage, fine. But make the default unlimited. To do otherwise is disingenuous.

 

[theZerg]

I support unlimited defaults.

 

[Zangelbert Bingledack]

It sounds like "default is unlimited but even unsophisticated users can easily adjust the settings" might be the sweet spot. No matter how much we want BU to be the "no hard cap" implementation, giving users the choice to change the default is going to be an overwhelming PR win.

There should probably be a little blurb when the user goes to change the default, saying something like, "Warning: Setting a blocksize limit may impair your client's ability to track longest-chain consensus. Bitcoin Unlimited's philosophy is that the blocksize limit should emerge as a natural property of the real-world economic constraints and incentives in Bitcoin. Thus we strongly recommend leaving this setting unlimited for normal usage. However, feel free to experiment with artificial blocksize limiting or alternative economic philosophies at your own risk."

(With the setting already only accessible in a tab marked "Advanced" or similar.)

 

[Peter R]

It sounds like "default is unlimited but even unsophisticated users can easily adjust the settings" might be the sweet spot. No matter how much we want BU to be the "no hard cap" implementation, giving users the choice to change the default is going to be an overwhelming PR win.

I'm good with this and I also agree that is would be a PR win. @rocks, @AdrianX : what do you think?

There should probably be a little blurb when the user goes to change the default, saying something like, "Warning: Setting a blocksize limit may impair your client's ability to track longest-chain consensus.

But with the meta-cognition stuff, we wouldn't need this warning (or at least it could be phrased much differently) because it still would track consensus.

Decisions, decisions...I guess I'm of the opinion that any time a decision is needed it should be possible for an educated node operator (who doesn't code) to over-rule Bitcoin Unlimited's default decision. But now we're back to BU representing a "big change in thinking" that @rocks was worried about.

 

[rocks]

@rocks First of all, noone has discussed the details of whether bip100/101 tagging would be configurable. I would probably add options to turn on/off bip100/101 tagging for the simple reason of "what if one of the BIPs is retracted or a user likes 101 but not 100"? Yet at the same time, if we choose not to make these optional the reason could not be to remove choice from the user (after all, he can always use another client to get that functionality) but simple expediency.

@cypherdoc you might have a point about public opinion which can be swayed irrespective of facts. However if these features are optional it is very difficult to claim we are forcing them on anyone which is I think more what hamstrung XT.

To all of you, I am arguing the BU return consensus back to how Satoshi envisioned it. And that BU enable the utilization of power that nodes have always had. All that I'm suggesting be added are graphical buttons and dials to access functionality that a developer can already easily tweak. Do some of you want to level the playing field between devs and the rest? This is how to do it.

@theZerg

I get that you want to return more decision making control to users and that is a good thing overall and I agree with the sentiment. But this would matter more if BU was the default used by 90% of people.

I've always seen BU as a client people can opt-into that 100% supports large blocks. When users run it they are announcing that support. When the market looks at node count, every BU node is clearly a vote for larger block sizes. i.e. the client is a single issue voter. It makes it simple clean and uncontroversial if you agree with large blocks. I am worried about other issues being introduced that muddy that message.

In general, over time, nodes should develop ways of dealing with other nodes that may be "misbehaving". If Bitcoin as a system is going to be successful, it needs to be resilient to anti-social behaviors by some. Hopefully if most nodes just act in their self interest, and can defend against disruptive behavior, then the network as a whole can be resilient destructive actors.

In computer science this is a "hard problem", which means that it is unsolved. Until Satoshi invented the POW method that tied the destruction of real world resources to the digital world, there were no methods to 100% protect a P2P network against attacks.

POW is the only method known to strongly protect a P2P network trying to maintain consensus. It is why so many CS types latched onto it in the early days, they saw what it meant and what it solved.

This is also why I worry about providing too much control to non-mining nodes. There are no good methods to protect the P2P network in a manner you can be strongly confident of outside of POW mining. Miners are the source of security, and decisions should stick with them. Otherwise we are reintroducing problems for which the CS community does not have answers....

 

[AdrianX]

I'm good with this and I also agree that is would be a PR win. @rocks, @AdrianX : what do you think?



But with the meta-cognition stuff, we wouldn't need this warning (or at least it could be phrased much differently) because it still would track consensus.

Decisions, decisions...I guess I'm of the opinion that any time a decision is needed it should be possible for an educated node operator (who doesn't code) to over-rule Bitcoin Unlimited's default decision. But now we're back to BU representing a "big change in thinking" that @rocks was worried about.

I think it is a PR win I also like the warning. I'm not concerned about the short and medium term implications. I'm worried about node operators a decade from now. How will they vote. Just reflecting on my personal position I'll be opposed to taking my node from a service rack to bigger capital investment. (I'm thinking I'll run a node like I run my miners)

I feel confident enough that many node operators will feel the same. I can envision a political battle much like we have now.

We need more nodes and less centralization. only this time it's the same political posturing all over again.

I'd rather force the issue now and get rid of all the limited blockers and move on.