Skip to content

Refactor - Addresses (usages) #52

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.

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

Open
wants to merge 38 commits into
base: develop
Choose a base branch
from

Conversation

DaMatrix
Copy link

@DaMatrix DaMatrix commented Aug 2, 2024

Description

This PR depends on #49 (addresses), #44 (disable-p2sh), and #51 (no-address-version).

This changes most of the existing transaction-related structs and code to use the dedicated address structs added in #49 instead of raw strings.

Changelog

  • Changed TxOut's script_public_key from String to AnyAddress
    • This required removing the Default trait from TxOut, with minor associated changes
  • Changed DruidExpectation's to from String to AnyAddress
    • This required removing the Default trait from DruidExpectation and DdeValues, with no side effects
  • Changed DruidExpectation's from from String to TxInsAddress
  • Changed ReceiverInfo's address from String to AnyAddress
  • Updated a number of functions to accept/return the specific address types instead of String/&str

Type of Change

Please mark the appropriate option by putting an "x" inside the brackets:

  • Bug fix
  • New feature
  • Enhancement or optimization
  • Documentation update
  • Other (please specify)

Checklist

Put an "x" in the boxes that apply. If you're unsure about any of these, don't hesitate to ask. We're here to help!

  • I have tested the changes locally and they work as expected.
  • I have added necessary documentation or updated existing documentation.
  • My code follows the project's coding standards and style guidelines.
  • I have added/updated relevant tests to ensure the changes are properly covered.
  • I have checked for and resolved any merge conflicts.
  • My commits have clear and descriptive messages.

Screenshots (if applicable)

If the changes affect the UI or have visual effects, please provide screenshots or GIFs showcasing the changes.

Additional Context (if applicable)

Add any additional context or information about the changes that may be helpful in understanding the pull request.

Related Issues (if applicable)

If this pull request is related to any existing issues, please list them here.

Requested Reviewers

Mention any specific individuals or teams you would like to request a review from.

DaMatrix added 30 commits May 29, 2024 13:51
This will be useful when I go through and add descriptive errors to everything everywhere
This allows other structs which wrap a fixed-length byte array to simply use it as a field, and not have to deal with any of the details of formatting or JSON hex (de)serialization.
this makes it clear which serialization format is being used where, as we are going to be changing this up soon
This will enable us to keep JSON serialization separate from the binary encoding, and also be much more explicit about the exact binary representation of objects.
Also implemented PlaceholderIndexed for all crypto structs
P2SH doesn't work yet, I don't want it to exist at all for the time being
# Conflicts:
#	src/utils/transaction_utils.rs
…ages

# Conflicts:
#	src/script/interface_ops.rs
#	src/script/lang.rs
#	src/utils/transaction_utils.rs
@DaMatrix DaMatrix requested a review from a team as a code owner August 2, 2024 13:08
…ess-version

# Conflicts:
#	src/utils/transaction_utils.rs
…ages

# Conflicts:
#	src/utils/script_utils.rs
#	src/utils/transaction_utils.rs
@BHouwens
Copy link
Contributor

BHouwens commented Aug 4, 2024

Okay this one is on the scarier side in terms of breaking changes. These will be the edge cases that need to be fully verified before we can merge in:

  1. Legacy transaction handling, both on legacy DB start up and also on-spending
  2. API backwards compatibility (or just regular compatibility with string input)

Number 1 is a must. Number 2 would be ideal, bordering on a must as well

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants