Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add -datacarriernum options #6

Open
wants to merge 1 commit into
base: libre-relay-v26.0
Choose a base branch
from
Open

Add -datacarriernum options #6

wants to merge 1 commit into from

Conversation

ariard
Copy link

@ariard ariard commented Mar 7, 2024

No description provided.

@petertodd
Copy link
Owner

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 ariard force-pushed the 2024-libre-relay-datacarriernum branch from 686af03 to a190d25 Compare April 4, 2024 03:36
@ariard
Copy link
Author

ariard commented Apr 4, 2024

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().

@ariard ariard mentioned this pull request Apr 4, 2024
Open
@petertodd
Copy link
Owner

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.

petertodd added a commit that referenced this pull request Apr 9, 2024
@petertodd
Reject multiple-tx RBF with unconfirmed inputs
051ea14 
Rule #6 prevents fee-rates from being decreased for direct conflicts, and thus
transactions spending confirmed inputs. But it does not prevent fee-rates from
being decreased when unconfirmed inputs are involved as a transaction spending
confirmed inputs can be merged with a transaction spending unconfirmed inputs.
Requiring replacements with unconfirmed inputs to be done one at a time ensures
that fee-rates always increase, while still allowing for RBF of CPFP
transactions.

This is necessary because relace-by-fee-rate assumes that fee-rates can't be
decreased; if they can be you can get infinite cycles of replacements.
@ariard
Copy link
Author

ariard commented Apr 27, 2024

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.

cryptoquick
cryptoquick reviewed May 28, 2024
View reviewed changes
src/init.cpp
@@ -593,6 +593,7 @@ void SetupServerArgs(ArgsManager& argsman)
argsman.AddArg("-acceptstalefeeestimates", strprintf("Read fee estimates even if they are stale (%sdefault: %u) fee estimates are considered stale if they are %s hours old", "regtest only; ", DEFAULT_ACCEPT_STALE_FEE_ESTIMATES, Ticks<std::chrono::hours>(MAX_FILE_AGE)), ArgsManager::ALLOW_ANY | ArgsManager::DEBUG_ONLY, OptionsCategory::DEBUG_TEST);
argsman.AddArg("-bytespersigop", strprintf("Equivalent bytes per sigop in transactions for relay and mining (default: %u)", DEFAULT_BYTES_PER_SIGOP), ArgsManager::ALLOW_ANY, OptionsCategory::NODE_RELAY);
argsman.AddArg("-datacarrier", strprintf("Relay and mine data carrier transactions (default: %u)", DEFAULT_ACCEPT_DATACARRIER), ArgsManager::ALLOW_ANY, OptionsCategory::NODE_RELAY);
argsman.AddArg("-datacarriernum", strprintf("Relay and mine transacrtions with max %u data carrier outputs", MAX_DATACARRIER_OUTPUTS_SOFTLIMIT), ArgsManager::ALLOW_ANY, OptionsCategory::NODE_RELAY);
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
argsman.AddArg("-datacarriernum", strprintf("Relay and mine transacrtions with max %u data carrier outputs", MAX_DATACARRIER_OUTPUTS_SOFTLIMIT), ArgsManager::ALLOW_ANY, OptionsCategory::NODE_RELAY);
argsman.AddArg("-datacarriernum", strprintf("Relay and mine transactions with max %u data carrier outputs", MAX_DATACARRIER_OUTPUTS_SOFTLIMIT), ArgsManager::ALLOW_ANY, OptionsCategory::NODE_RELAY);

@petertodd
Copy link
Owner

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@cryptoquick cryptoquick cryptoquick left review comments

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
3 participants
@ariard @petertodd @cryptoquick