Namecoin Forum

As I've just found out (somewhat "the hard way"), Bitcoin recently introduced a maximum size for P2P messages: https://github.com/bitcoin/bitcoin/comm ... c3626eb7a7

For Namecoin Core, this needs to be changed. 2 MiB is too little for 2,000 block headers with auxpow. We can either increase this message size limit (or remove the check again), or decrease the maximum number of block headers sent. I have to admit that I don't really feel experienced enough about the networking side of things to decide which one is "better". Any opinions?

No opinions? I think this should be fixed quickly, since it currently prevents a fresh syncing with Namecoin Core (staying up-to-date is not affected).

Let me quickly estimate how large a block header with auxpow can be:

Block header itself: 80 bytes
Auxpow coinbase tx: 1 KiB (guessing a probable upper bound)
Merkle Tx block hash: 32 bytes
Tx Merkle branch: 1 KiB (roughly; 1 + 30 * 32 + 4 = 965 bytes - assuming max. 2^30 tx per Bitcoin block which seems more than future-proof)
Auxpow Merkle branch: 1 KiB (roughly the same, 30 is hard upper limit for length of auxpow Merkle branch)
Parent header: 80 bytes

So in total, if we assume 4 KiB for the block header plus auxpow, we should have a very conservative estimate. (It is however not a strict upper bound, as the Bitcoin coinbase tx could have lots of outputs - think P2Pool.) Does this sound reasonable?

So we would need to increase the maximum message size to 8 MiB (currently set by the Bitcoin devs to 2 MiB). While I agree that it makes sense to not allow very large messages, 8 MiB seems fine to me. Particularly since Bitcoin is playing with the idea of increasing the block size to 20 MiB anyway. I suggest to simply set the maximum message size to 8 MiB and not reduce the number of block headers sent. Any objections to that? I'll check that this indeed allows to sync against the existing chain, and I'll also check how large the real 2,000-block headers-messages are.

Some more information: All 2,000 block header messages sent by syncing to main net are below 3 MiB. However, on testnet there appear some messages of almost 32 MiB size. Possibly someone experimented there with artificially large coinbase transactions in auxpows or something. I'll take a further look.

In order to get a hard limit for the maximum size of a block header (which would be useful), should we propose a softfork that restricts the maximum size of an auxpow coinbase tx to some reasonable value? (Like 1 KiB or 2 KiB, which should be more than enough unless someone does fishy stuff.) This would, however, restrict merge-mining pools also in how they construct their Bitcoin coinbase. Not sure if this would generate opposition to such a proposal.

Do you know why they introduced the limit in Bitcoin? I can ask sipa.

Besides that, increasing the maximum message size to 8 MiB sounds fine to me.

Also I agree that limiting the auxpow coinbase tx size would make things easier.

domob wrote:Some more information: All 2,000 block header messages sent by syncing to main net are below 3 MiB. However, on testnet there appear some messages of almost 32 MiB size. Possibly someone experimented there with artificially large coinbase transactions in auxpows or something. I'll take a further look.

In order to get a hard limit for the maximum size of a block header (which would be useful), should we propose a softfork that restricts the maximum size of an auxpow coinbase tx to some reasonable value? (Like 1 KiB or 2 KiB, which should be more than enough unless someone does fishy stuff.) This would, however, restrict merge-mining pools also in how they construct their Bitcoin coinbase. Not sure if this would generate opposition to such a proposal.

If it affects pools, I think we should check with the major pool operators and see if this would cause problems for them.

domob wrote:All 2,000 block header messages sent by syncing to main net are below 3 MiB.

Same findings here.

domob wrote:(It is however not a strict upper bound,

Does this mean 2000 headers could theoretically be larger than 8 MiB in the future? In this case we'd have to make sure the sender, too, limits the message size to 8 MiB, i.e. sends less than 2000 messages in this situation. Otherwise synchronizing would come to a halt. With sipa's commit a sender gets disconnected if it violates MAX_PROTOCOL_MESSAGE_LENGTH. However, if there is a 2000 header's message > 8 MiB to be sent then a synchronising client disconnects all peers, doesn't it?

biolizard89 wrote:If it affects pools, I think we should check with the major pool operators and see if this would cause problems for them.

From an irc namecoin-dev meeting:
Luke-Jr notes BTCGuild mines empty blocks and wouldn't go along with a softfork or hardfork

cassini wrote:

domob wrote:All 2,000 block header messages sent by syncing to main net are below 3 MiB.

Same findings here.

domob wrote:(It is however not a strict upper bound,

Does this mean 2000 headers could theoretically be larger than 8 MiB in the future? In this case we'd have to make sure the sender, too, limits the message size to 8 MiB, i.e. sends less than 2000 messages in this situation. Otherwise synchronizing would come to a halt. With sipa's commit a sender gets disconnected if it violates MAX_PROTOCOL_MESSAGE_LENGTH. However, if there is a 2000 header's message > 8 MiB to be sent then a synchronising client disconnects all peers, doesn't it?

Sending fewer than 2000 headers when 2000 exceeds the limit seems like a decent workaround. Would this be a particularly invasive change?

cassini wrote:

biolizard89 wrote:If it affects pools, I think we should check with the major pool operators and see if this would cause problems for them.

From an irc namecoin-dev meeting:
Luke-Jr notes BTCGuild mines empty blocks and wouldn't go along with a softfork or hardfork

Is BTCGuild still a major pool?

biolizard89 wrote: If it affects pools, I think we should check with the major pool operators and see if this would cause problems for them.

+1 In any case we should not set the limits too tight.

biolizard89 wrote: Is BTCGuild still a major pool?

4% for Bitcoin, probably twice that much or so for Namecoin. https://blockchain.info/de/pools?timespan=4days

IMHO we should not wait for them and their nasty business practice (not including Namecoin transactions).

I've committed a temporary patch that increases the size to 32 MiB. This is necessary to sync testnet, and is (AFAIK) what we had before. 32 MiB is/was the maximum size for serialising anything (or at least something like that).

The client uses the number of returned headers as a criterion whether or not to ask the peer for more. (I. e., if 2,000 headers are returned, more are requested. Otherwise not.) So this probably needs some change if we want to allow returning less headers. (We could do something like: Ask for more if 2,000 headers are returned or the size is >50% the maximum message size. If possible I would prefer to mess as little as possible with the Bitcoin code, though.)

I think that, in theory, the auxpow size is not restricted at all. The coinbase tx can be whatever the miner decides (no need for it to be valid as Bitcoin tx, BTW, just have a valid serialisation format), and also the Merkle branch can be arbitrarily large if the auxblock is not actually a valid Bitcoin block. I guess this is what someone tried out on testnet - but I'll investigate further. (I have already the scripts ready, they just need some time to run.)

Of course, it is not economical for a miner to work on an auxblock that is not a valid Bitcoin block - but it is a possible source of disruption nevertheless. I think that there should be at least some limit imposed - even if it is, say, length 30 for the Merkle branch (with corresponds to 2^30 tx in a Bitcoin block) and 10 KiB for the coinbase tx. (Which should be more than plenty, probably even for things like P2Pool. Does anyone know how large their coinbases are usually?)

Ok, here are some stats. If you want to recreate them, use "contrib/auxpow-sizes/auxpow-sizes.py" in the Namecoin Core Github. Main net: Testnet: So it seems that the issue is not the Merkle branch length (although it makes sense to restrict it as well, IMHO) but excessively large coinbase tx with hundreds of outputs. Not sure where they come from. At least on testnet, it seems that someone was experimenting with them on purpose. Based on these numbers, it seems reasonable to restrict the coinbase tx size to 5 KiB or even 1 KiB. The vast majority of miners would not be affected. If anyone has contact to P2Pool miners, it would be interesting to hear their thoughts on the issue!