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

[YarkoL]

Regarding spoofing: how about giving an option
for user to register her blocksize preference to the
blockchain using OP_RETURN. The node would
broadcast the registering transaction hash, others
would verify it and show the preferred blocksize under that
node in getpeerinfo.

Some amount of btc would have to be burned in
registering the blocksize preference to deter spoofing.

 

[Bagatell]

@YarkoL Their preference, no?

 

[YarkoL]

@Bagatell
Sorry? I thought this as an addition to
the published preferences in subversion/useragent string as
discussed above. Something that would guarantee that the
user is serious about it, since there would be a cost associated
with it.

 

[theZerg]

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

This is a very unconventional use of this string -- the optional parameters are meant to communicate platform, os, architecture and other static parameters that might be useful in debugging.

However, there does not seem to be a good way to add a client-specific protocol extension (BIP 14 explicitly says to not use this text field to define extensions to the protocol -- typically protocols have ways to define "vendor extension" messages or fields and then periodically the most valuable of these get incorporated into the common protocol), there doesn't seem to be a configuration message defined at this point, and these are the key configuration parameters.

So I say go for it! Worst case it'll just give the core devs something else to point at and moan about.

We'll take your patch, bring up a few nodes and see if sites like bitnodes.21.co properly drop the optional field...

 

[xd1gital]

In communication: "User Agent" is also a way for a client to tell others who I am and what I am capable of (for example: Web server needs "user agent" to send client an appropriate html page). So I think it's still the right way to use it. We can implement both (p2p command), and drop it if somebody really has a strong point against it.

 

[TrevinHofmann]

Some amount of btc would have to be burned in
registering the blocksize preference to deter spoofing.

The amount burned would need to be less than the expected donations, which would not really change the incentives (other than a slight decrease in the profitability) for spoofing a node.

 

[bitcartel]

@theZerg @YarkoL I think it's best to not pollute the user-agent string, especially as over time there could be many more options e.g. relay_opt_in_rbf. Adding a new network (and JSON-RPC) command to return BU parameters as JSON makes sense. Perhaps getbuparams, or bu_getparams to namespace future commands.

 

[YarkoL]

This is a very unconventional use of this string -- the optional parameters are meant to communicate platform, os, architecture and other static parameters that might be useful in debugging.

True, and initially I thought of a node communicating
the preferences as separate variables and client putting them
to a list that can be queried via rpc call. But that would only
be available to BU nodes whereas using the version/useragent
string is visible to the entire network as Peter R said, so
it will start to shape "consensual atmosphere" right away. Also
very simple thing to do.

 

[TrevinHofmann]

It might be worth considering that publishing the same configurations in the coinbase and as a node could decrease the anonymity of miners, especially if using uncommon values.

 

[theZerg]

@bitcartel Yes I originally thought as you do. But when you look at the protocol it really has no facility for "vendor" extensions, except that unrecognized commands are ignored.

And we have to weigh expediency against perfection, especially when "perfection" in this case is likely not going to not be seen as such by the community.

Also, I'd imagine that these are the key parameters and so it would be ok to have them in the user agent string (or slowly deprecate them) even if we eventually add "vendor" extensions to the protocol.

BTW they are already reported via JSON RPC calls.

 

[YarkoL]

blocksize expressed in megabytes.

I also added a check so that strings that are longer
than 10 chars are not shown.

I'll do some tests tomorrow, then if no further objections,
will make a pull request.

 

[solex]

@YarkoL
Great work. Do you round the EB downward to 1dp?
e.g. 16.17 would be shown as 16.1

edit: also any AD>9999999 could be shown as that value (which is about 190 years of blocks).

 

[Aquent]

blocksize expressed in megabytes.

I also added a check so that strings that are longer
than 10 chars are not shown.

I'll do some tests tomorrow, then if no further objections,
will make a pull request.

Nice work. Shouldn't we be mentioning MG as well since EB can be turned off? I'm also wondering whether the MG default should not be 2mb which seems for now to be the limit everyone one agrees with.

 

[hellobitc0inworld]

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.
​

^ I can guarantee it will happen. Especially when BU adoption becomes alarmingly high in small blockist eyes. Time has already proven when they feel fear, they lash out with DDoS and node spoofing.

 

[solex]

BUIP005 has been updated to include the user-agent subversion as discussed above.

@Aquent. All nodes should have a sensible EBS setting. Only miners will have a meaningful MGS and it provides an attack vector by de-anonymizing them if they are the nodes showing a >1MB while the non-mining nodes have the 1MB default. Also, no one is interested in the MGS of a non-miner, so best to get this from the coinbase-txn only.

 

[Aquent]

@solex, that makes sense. What about having the default at 2mb though? I think that would be a huge selling point since everyone agrees with 2mb.

 

[YarkoL]

@YarkoL
Great work. Do you round the EB downward to 1dp?
e.g. 16.17 would be shown as 16.1

(edited out lots of confusing stuff...)

Didn't do, but will do

edit2, done. But still needs some tests.

edit3: committed, over to you @theZerg

 

[solex]

@Aquent

I think 2MB [edit: MGS] is sensible, but also that @theZerg chose the initial defaults very well, and there would need to be a separate BUIP for changing them. The selling point for BU is individual choice, and this is being recognized already.

The BU mining default of 1MB, even in a BU majority network is a very low hurdle compared to the real problem with mining blocks >1MB today. The high hurdles are miner dependency on the RN which makes BUIP006 all the more important, and the massive overhang of non-mining Core nodes still at 1MB. So, the urgency is dealing with those two.

BTW, I think change is happening behind the scenes. The 100 bespoke BTCC nodes for example. Isn't it possible that these have the max-block-size as a config parameter...?

 

[theZerg]

I chose 16M as the default because if you (the owner of this node) don't care then the excessive size should be moved back to being an anti-spam measure, not used as a tool to control block size.

 

[solex]

@Aquent was referring to the MGS.
@theZerg Agreed re EBS