STR 754: Support Addresses and OP_RETURNs as withdrawal destinations

[storopoli]

Description

Right now the bridge supports withdraws only to P2TR. The user passes an X-only PK to the bridge withdrawal precompile address.

However we need to support any arbitrary address, along with OP_RETURNs as valid withdrawal destinations.

TODO

• functional tests for different BOSD.
• fix EVM issues
• pin bitcoin-bosd to a version in crates.io.

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature/Enhancement (non-breaking change which adds functionality or enhances an existing one)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Refactor
• New or updated tests
• Dependency Update

Notes to Reviewers

Checklist

• I have performed a self-review of my code.
• I have commented my code where necessary.
• I have updated the documentation if needed.
• My changes do not introduce new warnings.
• I have added tests that prove my changes are effective or that my feature works.
• New and existing tests pass with my changes.

Related Issues

STR-754

[codecov]

Codecov Report

Attention: Patch coverage is 0% with 8 lines in your changes missing coverage. Please review.

Project coverage is 56.82%. Comparing base (ce29ffc) to head (a9e7fce).

Files with missing lines	Patch %	Lines
crates/primitives/src/l1.rs	0.00%	8 Missing ⚠️

@@            Coverage Diff             @@
##             main     #600      +/-   ##
==========================================
- Coverage   56.85%   56.82%   -0.04%     
==========================================
  Files         308      308              
  Lines       32372    32379       +7     
==========================================
- Hits        18405    18398       -7     
- Misses      13967    13981      +14     

Files with missing lines	Coverage Δ
crates/primitives/src/l1.rs	77.76% <0.00%> (-0.66%)	⬇️

... and 3 files with indirect coverage changes

[github-actions]

Commit: 44cccc7

SP1 Performance Test Results

program	cycles	success
BTC_BLOCKSPACE	7,239,526	✅
EL_BLOCK	102,449	✅
CL_BLOCK	55,484	✅
L1_BATCH	12,460,156	✅
L2_BATCH	5,448	✅
CHECKPOINT	15,322	✅

[delbonis]

Tweaks to representation.

[delbonis]

I would still probably pass it around as plain bytes instead of the encoded representation. Once we've validated it we don't have to introspect it again until the operator gets it. (Although we'd probably validate it once more when we have a cleaner break between the EVM EE and the Strata chain, still keeping it as bytes though.)

[delbonis]

bytes, unfortunately

This kinda still is messy, we shouldn't be using logs for this imo.

[delbonis]

Vec<u8> still, we can avoid validating it until we actually use it and take advantage of the simpler representation elsewhere.