Port of BIP-110 UASF code from Knots#2
Open
v72t wants to merge 81 commits into
Open
Conversation
…to reduce data push size limit to 256 bytes (except for P2SH redeemScript push)
…TA (still unused)
…DUCED_DATA (still unused)
…ATA is active (still never)
…o cap output scripts at 83 bytes
…l never), limit non-OP_RETURN scripts to 34 bytes
…to expected memory usage
…r than exceed MAX_OP_RETURN_RELAY
…T_REDUCED_DATA is active (never yet)
v72t
changed the title
…AM,UPGRADABLE_TAPROOT_VERSION,OP_SUCCESS} on blocks when DEPLOYMENT_REDUCED_DATA is active (never yet)
Github-Pull: bitcoin#10532 Rebased-From: cd74a23fcf9588199e196ab31bc64972400c2027
… risk Github-Pull: bitcoin#10532 Rebased-From: e42a2f6beb61df3e3a201804cf3bcce6b00c88ba
…imit; add reduced_data deployment name to allow regtest RPC access for testing
…hout_usage helper for testmempoolaccept results
…eviction threshold The test was failing because commit 58a329b changed gen_return_txouts() from using 1 large OP_RETURN output to 734 small OP_RETURN outputs (to comply with the new MAX_OUTPUT_SCRIPT_SIZE=34 consensus rule in bip444). This change altered how fill_mempool() fills the mempool, raising the eviction threshold from ~0.68 sat/vB to ~1.10 sat/vB. The test's create_package_2p1c() was using hardcoded feerates (1.0 and 2.0 sat/vB), causing parent1 to be below the new eviction threshold and get rejected. Solution: Calculate parent feerates dynamically based on the actual mempoolminfee after fill_mempool() runs. This makes the test robust to future changes in mempool dynamics. - Store mempoolminfee in raise_network_minfee() - Use 2x and 4x mempoolminfee for parent1 and parent2 feerates - Add logging to show the calculated feerates Test results with fix: - mempoolminfee: 1.101 sat/vB - parent1: 2.202 sat/vB (2x threshold) → accepted ✓ - parent2: 4.404 sat/vB (4x threshold) → accepted ✓
…lags_per_input is used (and avoid using it when unnecessary)
…ning via activation-boundary reorg Co-Authored-By: Lőrinc <pap.lorinc@gmail.com>
v72t
force-pushed
the
29.3+UASF-BIP110
branch
2 times, most recently
from
c916f62 to
65b9c10
Compare
Without this, the build can potentially pick up on our own tags as if they determine its own version
… push size limit The tapscript/pushmaxlimit spender uses a leaf script with a 520-byte push (MAX_SCRIPT_ELEMENT_SIZE). Since SCRIPT_VERIFY_REDUCED_DATA is included in STANDARD_SCRIPT_VERIFY_FLAGS, the 256-byte reduced push limit (MAX_SCRIPT_ELEMENT_SIZE_REDUCED) is enforced as mempool policy. This causes the 520-byte push to be rejected as non-standard. Without standard=False, the test intermittently tries to submit this spender to the mempool expecting acceptance, depending on whether the randomly chosen tx version and co-inputs happen to all be standard. On the upstream Knots-based branch (bip110-v0.3), this fix was introduced by the match_more_datacarrier merge (Bitcoin Core PR 28408), which independently made large tapscript pushes non-standard via datacarrier size filtering. On this Core-based branch, the same fix is needed because SCRIPT_VERIFY_REDUCED_DATA has the same effect. Reproduces with: --randomseed=823027376919141336
|
Hello, we wanted to use this client to send RDTS templates to SV2 pools, but we were informed that it requires an update. Would it be possible to update it as soon as possible so we can implement it in PyBLOCK - Pool? Thanks in advance. |
|
Hello @PyBLOCK-Bitcoin - have you tried building the port of BIP-110 to Core's master branch? It's sitting a few dozen commits before Core v31 and all tests are passing, so it should work. I may update it to be based on v31 if there is demand and I have time. It most likely has the SV2 compatibility code you need. |
No, in the end we bypassed the restriction with your client, and we are already signaling BIP-110 on SV2. |
|
@PyBLOCK-Bitcoin Magnificent news! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
7 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR ports the UASF BIP-110 code from Knots to Bitcoin Core v29.3.
Specifically Dathon Ohm's 29.3.knots20260210+UASF-BIP110 branch has been rebased on top of the Bitcoin Core v29.3 release.