Add `-datacarriernum` options

[ariard]

[petertodd]

Two issues with this:

1. The MAX_DATACARRIER_OUTPUTS = 100 limit is much too low for the spirit of libre relay. The default limit should be sufficiently high to be impossible to actually reach; put another way, it should be unlimited.
2. Every feature we add is a future maintenance burden. In my discussions with miners, what they want most from Libre Relay is good unit tests and a reasonable libre policy that is unlikely to cause them any issues. If they wanted a more limited OP_Return policy, they could just run core.

With that in mind, I'd suggest taking this pull-req and proposing it as a pull-req for Bitcoin Core.

[ariard]

Pushed an update, addressing the 2 concerns.

The MAX_DATACARRIER_OUTPUTS = 100 limit is much too low for the spirit of libre relay. The default limit should be > sufficiently high to be impossible to actually reach; put another way, it should be unlimited.

Added a new MAX_DATACARRIER_OUTPUTS_HARDLIMIT=3_999_833 which means one minimal size transaction + 3_999_833 1-byte OP_RETURN. Current transaction issuers can at most make a transaction no bigger than MAX_BLOCK_WEIGHT. MAX_DATACARRIER_OUTPUTS_HARDLIMIT when we see network-level consensus upgrade in matters of block size.

Every feature we add is a future maintenance burden. In my discussions with miners, what they want most from Libre Relay is good unit tests and a reasonable libre policy that is unlikely to cause them any issues. If they wanted a more limited OP_Return policy, they could just run core.

Added a new MAX_DATACARRIER_OUTPUTS_SOFTLIMIT=1 which is matching the max number of OP_RETURN outputs accepted by Bitcoin Core as a transaction-relay policy since release v0.10.0. There is a new check in src/node/mempool_args.cpp verifying that node setting datacarriernum is no strictly superior than MAX_DATACARRIER_OUTPTUS_HARDLIMIT.

Distinction between hard and soft full-node resources limits for denial-of-service mitigation while allowing more flexibility for use-cases experimentations, including accepting transactions yielding higher-income block template is coming from my kernel hacking experience, e.g getrlimit().

[petertodd]

Pushed an update, addressing the 2 concerns.

Thing is, you haven't really addressed the second concern. Every bit of code added to Libre Relay is code that needs to be cherry-picked and updated every time Bitcoin Core makes a release; I'm working on that for v27.0rc1 right now. I just don't see a good reason to make the # of OP_Return outputs configurable. What person would want to relay/mine more than 1, but less than ∞? Simply commenting out that check is much simpler, and less work to maintain.

[ariard]

What person would want to relay/mine more than 1, but less than ∞? Simply commenting out that check is much simpler, and less work to maintain.

Any person wishing to operate transaction-relay traffic shaping, where you would like to apply quantitative segments over global transaction-relay traffic (e.g 1/3 third lightning, 1/3 third datacarrier-using colored coins, 1/3 usual transactions). As each segment can have it’s own time-sensitive constraints / liquidity preferences and you wish to optimize income.

As of today, I’m not aware of any mining pools / block template constructors doing so, this is true it sounds very too much flexibility for now. If libre relay focus on maintenance, correct -datacarrierenum might be superfluous for now. Going further, why not removing max OP_RETURN check completely rather than commenting out ? Always easy to re-insert it in mempool’s PreChecks() code path.

[petertodd]

Going further, why not removing max OP_RETURN check completely rather than commenting out ?

IIRC I wanted it to be clear what was there for reference for future rebases. But I don't think I've followed that consistently anyway...