How does a full node tell the network its blocksize limit?

[xd1gital]

Sorry, if this has been answered before (I searched but found nothing) and BUIP005 is only for miners.
I know this number can be fake, but miner should have a general idea what the best size that majority of nodes will accept.

 

[Wary]

AFAIK, currently it doesn't. That's one of things to be done.

 

[Erdogan]

I think there should not be a requirement to publish anything. The miners should, if they want to make a larger blocks (due to fees perhaps), make one, and consider the risk of being run over by a chain that grows from a sibling. They should use all the information they can get (out of band, not relying only on the software versions and blockchain votes) to guess whether a sufficient majority of miners and nodes will accept it as valid and build on it.

As demand for space in the blockchain increases, fees will rise and miners will want to make bigger blocks, especially if others do. Being a few weeks too late in preparing may be a noticable loss on the bottom line. As a minimum they should be ready to extend a branch that contains a bigblock (or their mining income will effectively evaporate until they upgrade).

Currently a 1000001 byte block will probably be orphaned, but after a block of say 1500000 bytes has been buried 20 blocks deep in the chain, probably any size up to 2000000 will be ok (being a recognizable, round, sensible number). Collusion between a set of miners is allowed, either "we agree to build on each others' block", or "If you make a largeblock, and it is rejected, we will make up for a part of your reward/fee loss" (just to get the increase started).

If the miners don't want bigger blocks, I will have to buy a majority of them. There is always a way.

 

[xd1gital]

If miners don't know what size that most nodes will accept and relay, they probably won't gamble to increase their limit.
It's actually very simple for node to show their blocksize limit value: just put it in the "user agent" field.
Again, this number can't be fake but there is no incentive to do so

Running a full node does cost money, what in it for you to fake it?
And If one runs thousand of fake nodes: It should be easy to identify it by IP address and exclude it.

 

[Peter R]

@xd1gital

That is a great idea!

For some reason I thought we'd have to define a new P2P command to allow nodes to poll other nodes for their settings. Your proposed solution is very simple and convenient as XTnodes (@hellobitc0inworld) and bitnodes are already reading these strings from all the network nodes on a regular basis.

@theZerg; @sickpig: do either of you know how long the user-agent string can be?

 

[theZerg]

Is adding a new command such a hardship? Seems easy enough to me; no reason to clutter up the user agent field and force weird parsing behavior.

 

[Peter R]

@theZerg: I don't know. We should ask someone like @hellobitc0inworld who currently has a webservice that uses this string. It would be really cool if XTnodes also made a histogram of all the Bitcoin Unlimited nodes' block size limit settings. Would he be more likely to do this if the data was in the version string? I'm not really sure...

Anyways, after reading the BIP where the user-agent string was proposed (BIP 14), it says that agent-specific comments can be optionally included, so perhaps this is actually a good place for it:

https://github.com/bitcoin/bips/blob/master/bip-0014.mediawiki

 

[TrevinHofmann]

@Peter R - The maximum length is 256 bytes/characters.

https://github.com/bitcoin/bitcoin/blob/master/src/net.h#L49

static const unsigned int MAX_SUBVERSION_LENGTH = 256;

 

[solex]

Kudos to @xd1gital for this lateral thinking.
I think it's great to hear unconventional proposals that are fundamentally sound. IMHO, it deserves some debate to see whether it can be done effectively and cleanly.

 

[Peter R]

Perhaps we could append the coinbase string from @solex's BUIP005 verbatim to the user-agent string:

/BitcoinUnlimited:0.11.2/MG2.0/EB3.5/AD4/

EDIT: should probably be:

/BitcoinUnlimited:0.11.2(MG2.0;EB3.5;AD4)/

to adhere to the BIP14 comment spec.

I agree that this is worth considering.

 

[solex]

Indeed it would be good to adhere to BUIP005 formatting for consistency.

Question whether the MG value is needed for non-mining nodes. A lot of nodes will just leave the 1MB default as they never mine. In fact, maybe just BUIP005 should be relied upon for MG (and FG info) as these come with PoW.

Edit: the trick will be ensuring that the BitcoinUnlimited:0.11.2 count is not splintered on xtnodes, bitnodes etc.

Re-edit:
So,
/BitcoinUnlimited:0.11.2(EB3.5;AD4)/

 

[Peter R]

Precedence for adding extra info as a comment to user-agent string:

Done according to BIP14:

Done ad-hoc:

 

[hellobitc0inworld]

Hi Peter,

This idea sounds cool and useful. This data would allow the visualization of the global block size choices.

Right now I actually use the phrase "BitcoinUnlimited" to search out all the BU nodes.

This makes it easy because then I only need to search for 1 thing. As long as that portion of the user agent remained the same, and the block vote information was appended onto the end, this would work.

Your formatting is good, when you proposed this:

/BitcoinUnlimited:0.11.2(MG2.0;EB3.5;AD4)/

By the way, what does MG, EB and AD stand for? I'm guessing the numbers that follow are in megabytes.

I would have to write some new code to gather this data. It might take a little work, but I am certain I could do it if the information was simply added to the user-agent as above.

By the way, it's best to contact me on reddit like you did, as I check there daily

 

[TrevinHofmann]

@hellobitc0inworld

https://bitco.in/forum/threads/buip005-settings-information-via-coinbase-txn.696/

MG: Maximum Generate Size (MB)
EB: Excessive Block Size (MB)
AD: Excessive Acceptance Depth (blocks)

 

[Peter R]

Thanks for chiming in, @hellobitc0inworld!

I think what @solex suggested makes the most sense:

/BitcoinUnlimited:0.11.2(EB3.5;AD4)/

Like @TrevinHofmann pointed out, the number after "EB" is the block size limit (for regular blocks) in MB and the number after AD is the depth that a block larger than this limit would need to be buried in order to be accepted by the node.

I suppose if the "ADx" term was omitted, it would be assumed that AD = infinity?
[doublepost=1452063273][/doublepost]Another benefit of adding this information to the user-agent string (rather than creating a new command) is that non-BU nodes would also be able to read it without requiring an update (e.g., I doubt bitnodes.21.co would go out of there way to run a BU node just to read this information, but they would automatically read it and make it publicly accessible if we stick it in the user-agent string).

 

[solex]

@Peter R
Agreed with your last observation.

Note about AD, it is an integer so the max value should be 2,147,483,647
Of course anything over 100 is being very dogmatic about an excessive block. It will be interesting to see just how many nodes want to use a high AD value.
----------------------------------------

Does anyone have a firm opinion on whether this should be a separate BUIP or could be included with BUIP005, but as a separate commit?

 

[YarkoL]

@theZerg: if you like I can already implement this
feature, to be included if so desired.

 

[xd1gital]

There is one drawback when using "User Agent" string. If AD or EB is changed after a connection is made, the connected peer won't know the change. This is only my guess, because I don't know how often the user-agent string is sent to peers. But I think the drawback is very small, since these information is optional and rarely needed to be changed.

 

[freetrader]

I suppose if the "ADx" term was omitted, it would be assumed that AD = infinity?

You mean "it would be specified" ?

The BUIP should be very clear about what it officially means.

I would still like to point out that in the BCT discussion ("review") thread, a very valid argument was made that this information can be easily spoofed, and should only be processed with large grains of NaCl.

Again, this number can't be fake but there is no incentive to do so

We should not dismiss the spoofing argument on the grounds of "no incentive".

During the rollout of XT we saw the emergence of large numbers of node with spoofed identification. It didn't much affect XT because it's the mining nodes that matter for that, but it made a strong point, leading to the idea (and practice) of stealth nodes to avoid the accompanying DDOS.

There are good grounds to assume that Bitcoin has moved into the sights of people with large pockets who could mount very good spoofing attacks with ease. In fact, the non-mining full node network as a whole seems to be gaining importance as an area of attack in fighting for/against the status quo.

I am not trying to say that passing on the configuration stats is a bad idea. I am saying that, at least in the initial phase as BU and others gain traction, decisions by miners will clearly need to be based on more careful analysis.

 

[xd1gital]

Totally agree! Before using this information, one has to filter out bad actors by rating them for how long these nodes have been online and checking duplicate IP addresses (or in a same range x.x.x.1 to x.x.x.254, similar for IPv6..)