Gold collapsing. Bitcoin UP.

[cypherdoc]

@Peter R

ok, so the flags are just labels while the BU code would relay big blocks both inside and outside the parameters of 100 or 101, correct?

sounds good to me.

 

[Peter R]

Let us be very clear about the max block size logic. How about this:

The max block size will be user configurable. Let's call a block that exceeds this user-configurable size an "excessive block".

The node can receive excessive blocks. But it will not relay them (or mine on top of them) until the chain containing the excessive block is N blocks longer than the best alternate chain which has not had an excessive block for M blocks. N (and maybe M) is user configurable.

This is what is meant by block size being part of the protocol layer not the consensus layer.

@awemany gave these sorts of ideas a lot of thought, so he's probably the best person to comment. For my perspective, I would do whatever would be most appealing to the greatest number of people. Which is probably something like what you just suggested so long as the user can set N = infinity.

My hunch is that users who set reasonable block size limits and pay attention to the network will rarely if ever receive an "excessive block." Nevertheless, it's a nice option if you can implement it.

@cypherdoc

"ok, so the flags are just labels while the BU code would relay big blocks both inside and outside the parameters of 100 or 101, correct?"

Right, BU would relay whatever blocks are permitted according to its own rules. The flags are just labels to help the other nodes activate their BIPs.

@theZerg : would BU relay "excessive blocks" at the tip of the chain?

 

[cypherdoc]

@Peter R

uh, on second thought, maybe the flags are not such a good idea afterall? why confuse ppl? doesn't BU want to attract as many users of it's full node implementation as fast as possible? even if it means taking converts away from the other proposals? the advantage of a clean break like BU is that it's so drastic, yet so simple, and according to Satoshi's Original Vision.

wouldn't it be cleaner to let it stand on it's own?

 

[theZerg]

@cypherdoc The flags indicate that the node can accept BIP101 or BIP100 blocks, so wouldn't it set them?

@Peter_R "would BU relay "excessive blocks" at the tip of the chain?" No. It only starts relaying them if they become part of the "main" blockchain, as defined by that chain being N block longer than the competition. In this manner it discourages excessive blocks, and does not engage in behavior that the user believes is outside of the capabilities of his personal network.

 

[Peter R]

@cypherdoc

My concern is that this would further fragment the community across multiple BIPs when we really all want the same things: bigger blocks.

I'm not married to the idea of flagging BIP101 and BIP100 support, however. I'd like to know what others think.

@theZerg

OK, makes sense.

 

[cypherdoc]

@Peter R

isn't there a chance that 100 blocks can get smaller? would you exclude those? i'm not wedded to either/or for flags. i too want to know what others think.

 

[Peter R]

@cypherdoc "isn't there a chance that 100 blocks can get smaller?"

Yes, but by actively voting for larger blocks wouldn't we make this less likely to happen than if BU didn't vote? Or is your concern that BU's involvement might activate BIP100 when it otherwise wouldn't be activated? Would activating BIP100 be bad in your opinion?

Also remember, BU still operates according to its user-configurable rules regardless of the voting.

 

[cypherdoc]

@Peter R

not sure i follow. any "voting" going on in 100 is done by it's own miners, not nodes. so if 100 miners decide for some inexplicable reason to start mining smaller blocks than they have to date, would BU be obligated to include them, which it shouldn't want to do?

 

[Peter R]

@cypherdoc

BU could be used for mining nodes too. These are the only nodes that could flag support for BIP100.

BU miners/nodes wouldn't be obligated to follow anyone; however, if miners running BU were convinced that blocks over X MB would not be accepted by the majority of the hash power due to some crazy vote by miners, then probably the miners running BU would adjust the max size of the blocks that their nodes produced so as not to fork away from the longest chain. This wouldn't affect the max block size they would accept, however.

 

[theZerg]

I think that BU should apply the similar rules for small blocks as large ones -- you can configure a block size (or maybe a ratio) that is "too small" relative to the # of unconfirmed txns. Similar to "excessive blocks", these "tiny blocks" would not be relayed but would eventually be accepted if their blockchain grows large enough.

This may discourage the zero length blocks that we see. Of course, none of this will help if miners are using an independent block relay protocol. So while these changes may start a philosophical shift, we won't see actual differences until efficient block propagation changes occur.

 

[cypherdoc]

@cypherdoc "isn't there a chance that 100 blocks can get smaller?"

Yes, but by actively voting for larger blocks wouldn't we make this less likely to happen than if BU didn't vote?

how can BU miners "vote" on BIP100 block sizes when they're running different BU software once it's forked away from Core?

 

[Peter R]

@cypherdoc :

I'm assuming there is still only one Blockchain and by "fork" we're talking about multiple forked implementations of the protocol. If that is the case, then a BU miner can write whatever he wants into the coinbase TX--including his "vote" for BIP100 (even though the BU node will ignore the results of this vote).
[doublepost=1444969204,1444968267][/doublepost]

You'd feel worst if you happen to come across some of the posts on their bitco.in forum. The cargo cult delusion over there has truly reached manic levels.

It really is a sad sight to observe some posters who used to be reasonably sane on here (ZB) seemingly afraid to speak up against some of the downright outrageous things frappucino & his cohort propose over there.

Their latest obsession, Bitcoin Unlimited is some of the most stupid stuff I've witnessed in my time in this community.

Since you're following this thread anyways, brg444, why don't you come join the discussion? What exactly is stupid about Bitcoin Unlimited? It won't fork from the longest chain, but I believe it will reduce the friction against raising the block size limit.

 

[cypherdoc]

@Peter R

Seems to me you're talking about pre-activation whereas I've been talking post. Once the switch is flipped to activate BU, there becomes 2 separate chains with their own rules.

 

[rocks]

The max block size will be user configurable. Let's call a block that exceeds this user-configurable size an "excessive block".

The node can receive excessive blocks. But it will not relay them (or mine on top of them) until the chain containing the excessive block is N blocks longer than the best alternate chain which has not had an excessive block for M blocks. N (and maybe M) is user configurable.

This is what is meant by block size being part of the protocol layer not the consensus layer.

I would be concerned about this for the following reason. Miners want to be sure that a block they mine will be propagated through the network efficiently. If there are any concerns a block won't be propagated, they will reduce block size to make absolutely sure. They will do this even if the network would have propagated their block.

This is why I think the blocksize is part of the consensus layer. Miners need to have a clear view on what is a valid block. A block where enough nodes will not transmit it, although valid if built on, in a sense is not valid because it runs a higher risk of being orphaned.

Ideally miners are the only ones who should limit blocksize, driven by an economic balance between a desire for more fees and cost to run their nodes. Non-mining nodes on the P2P network should accept and be capable of handling whatever size the miners find most profitable. Another way to look at it is if 8 major pools are capable of very large blocks, why should the blockchain be held back because 1000 out of 6000 P2P nodes can't keep up.

 

[Zangelbert Bingledack]

@rocks

Even assuming blocksize should be in the consensus layer, must the consensus (of the non-monetary consensus layer) really be solid and predictable? A miner simply cares about profit, and orphan risk is just another element in that calculation. They can have predictable enough consensus if they stick to conservative blocksizes. If they want to try to maximize profits, they may take on substantial orphan risk, but they still have the predictability of being able to calculate their expected profit on each block.

It seems we are talking always about two different kinds of consensus:

1) complete agreement among all the nodes (whatever group "the nodes" are taken to be, they are chosen in advance)

2) a result among a subset of nodes at any given time (the group that is in consensus is considered after the fact, and that group is by definition in consensus)

In 1, consensus only exists if every node in a predetermined group is in agreement. In 2, consensus exists among whatever group of nodes actually end up in agreement with each other.

In 1 the group of "all the Bitcoin nodes" is fixed; in 2 it is fluid: whatever nodes come to a prevailing consensus at this time are the nodes that constitute the de facto Bitcoin nodes at this time (any nodes not in consensus are temporarily not participating, or perhaps if the fork they were on enjoyed investor support it could potentially become its own thing or even take over as the dominant Bitcoin ledger maintenance protocol later).

Even in the more amorphous situation, a miner still just has to calculate profit and loss estimates. "Valid block" becomes similarly a fluid concept, but I don't see that this is necessarily bad. In fact it may be absolutely necessary as the endpoint of enabling the total market control that will be needed to defend against all attacks.

An analogy:

In English, the concept of a "valid term" or "valid spelling" is fluid in a similar way: consensus is reached among English users by the process of people pushing the envelope on terms and spellings, knowing that their statement or meme or spelling may get orphaned (not propagate) if they push it too far.

Consider for example people who try to make gender-neutral pronouns like "zhe" (meaning "he or she") a thing.

The end result of this trial and error by speakers is that a consensus forms among a usefully large-enough group, but there is no need for enforcement of consensus among a preset group. If you get too out there you simply fall out of consensus temporarily and suffer some consequences (in both cases, wasted effort). Consensus forms constantly by a market process that values conservatism but will adapt when a change is truly beneficial.

 

[solex]

@Melbustus excellent idea about a big-blocks oriented pool, and governance built in.

@cypherdoc

My concern is that this would further fragment the community across multiple BIPs when we really all want the same things: bigger blocks.

I'm not married to the idea of flagging BIP101 and BIP100 support, however. I'd like to know what others think.

@theZerg

OK, makes sense.

I'm really liking the BU concept as a "meta" proposal that encompasses BIPs like 100 & 101 while building in the option of user-choice through a GUI setting / command-line parameter. Those BIPs might become redundant, however:

Node environment determined block limit

Why can't BU recognise that Bitcoin is a finite system with finite capacity? The trick is not to choose some arbitrary dev-defined limit (like Satoshi's fixed 1MB), but to let the software determine the capacity for each node it runs on and the effective block limit becomes an emergent property of the functioning network. The "real" block size limit for Bitcoin at any moment will actually be unknown and only able to be approximated!

It would require a fairly simple mathematical formula where the Bitcoin-BU software takes metrics for its environment at run-time: the available disk-storage, memory, broadband speed (send/receive) and calculates a block limit to serve as a default which suits the particular node capacity. The calculated limit can be flexible, varying up or down based upon changing conditions, unless the user manually overrides it. This makes the transaction handling capacity of the network much more closely aligned to the computing technology used by all the nodes that comprise it, especially the non-mining nodes.

Let us be very clear about the max block size logic. How about this:

The max block size will be user configurable. Let's call a block that exceeds this user-configurable size an "excessive block".

The node can receive excessive blocks. But it will not relay them (or mine on top of them) until the chain containing the excessive block is N blocks longer than the best alternate chain which has not had an excessive block for M blocks. N (and maybe M) is user configurable.

This is what is meant by block size being part of the protocol layer not the consensus layer.

The idea where a node does not relay blocks above its limit, but keeps larger blocks it receives for determining the best chain, is interesting. It does seem to achieve removing the limit from the consensus layer.

 

[cypherdoc]

OK, this is how I'm envisioning his this is going to work once the code gets activated.

Node code ships with no limit default. This is where we would hope node operators would eventuality leave this setting but they're free to change it. Why? Because we really want to encourage miner competition based on users willingness to pay tx fees and the miners ability to provide block space. Yes, they will have to worry that if they produce too large a block, there might be enough nodes out there that have lowered the default limit downwards to a level that won't relay their block.

Meanwhile, miners can be monitoring average block size of the network real-time for feedback as to what size blocks are currently being produced. They can choose to construct blocks at that average for maximum safety for acceptance. Newer, smaller pools might want to creep up to slightly larger blocks enabling them to advertise slightly higher payouts because of the extra fees they would be mining. This comes at a higher risk of orphaning however. But it pushes the system higher in terms of growth as they push the average block size higher. This is what we want: risk takers. Plus, pools/miners need bigger blocks in the long run to replace profits with fees instead of rewards.

Other more risk averse pools /miners can make slightly smaller blocks from the average if they want so as to be able to advertise that their emphasis is faster propagation and assurance of node relay. That's OK too.

I envision a distribution of block size around an average that everyone can monitor. The natural tendency will be for growth and bigger blocks because of the need to transition from a rewards incentive to that of a fees only incentive. Also, this dovetails nicely with the never ending fiat printing world where Bitcoin continues to suck in that fiat money because of its fixed supply which will be leveling off its issuance curve.

We ideally wouldn't want node only operators interfering in this miner/user negotiation necessarily unless they have some compelling insight into a certain block size that we aren't aware of or in case of an emergency where the network as a whole needs to clamp down on block size for some reason.

The point is nodes only/users would have a choice.

Note: I am talking about how the system will be working after activation. The process leading up to that {gaining consensus to adopt the code in the first place} is a separate process.

 

[cypherdoc]

In case I hadn't made it clear above: the full node definable block size settng encourages miners to respect full node operators willingness and resource capabilities to validate and relay their blocks. This is what LukeJr should want and desire since these nodes are donating their services essentially.

 

[Erdogan]

My take on the bitcoin unlimited idea:

It is best to have just an unlimited blocksize, and a parameter limiting the max block size to produce, information about what to do, shared outside of the blockchain.

In this case, the miners always are the ones to choose the actual block size. They will choose according to their best interest, which is basically the cost and the advantage, but remember that in the market, it is the long time psychical advantage and cost we talk about, which includes considerations of what is best for the system in the long run, or if you take it all the way, humanity. It is not required to take into account other things but your self interest, but it is allowed (and if you ask me, it is not an insignificant part of the free market).

So to spell out the most important factors, the advantage of making a large block is obviously the collection of fees, but also the future value of the miner's own coins an his business, because large capacity is needed to make the system to be sound money for as many people as possible.

The cost is the relatively small but not zero added cost of a large block in hardware, power, network and administration (thinking about the size), but maybe the largest cost is the risk of the block getting orphaned. For a business, risk transforms directly into cost that goes into the bottom line, the business problem is to manage that risk.

So an "unlimited" miner will have to consider which is the largest block he can make without risking too much on his bottom line. Voting with version numbers and comments in the blockchain can be of some help, but he can never fully trust it. In the end he must take all available information into account, which includes what is talked about in the social arena.

To explain this with an example, if a limit of 8MB is the current relative consensus, diverse sizes appears, in general increasing, and when the first 6MB block appears, there will be a need for a new consensus. Things that can be of importance, are:

Have some nodes crashed at 6MB? Have some nodes given up? Have we had miner centralization of importance? Have users been hurt? Have some wallet software or servers met problems. Have businesses had problems. Do we have lots of microtransactions that are not worth carrying? If there is not an apparent consensus, the risk of orphaning is bigger, and the miners will have to take baby steps going forward. I am sure hundreds of other more or less relevant questions will come up, so don't take this example too serious.

The important part is unlimited size on verification, miners decide block size at creation, and out of band information exchange.

 

[Zarathustra]

Ethereum collapsing - Bitcoin up ...