The current code for handling standard addresses implemented in dcrutil
was written many years ago prior a wide variety of changes and several
new features added by Decred. As a result, it entirely lacks support
for some features and supports others in a roundabout and non-intuitive
way.
Specifically, it does not support or provide a clean path to enable
support for different script versions and the way they are handled in
stake transactions is entirely non-intuitive.
Further, back when the original address code was implemented, it was
necessary to implement script creation in the txscript package which led
to the current design of providing methods such as
txscript.PayTo{AddrScript,SStx,SStxChange}, and others, which need to
type assert the specific concrete types of addresses in order to produce
the necessary scripts. This, unfortunately, effectively negates the use
of an interface to support generic addresses because it means callers,
such as dcrwallet, are not able to implement their own types without
somewhat invisibly breaking the script creation.
Finally, the aforementioned blending of the address code into txscript
has led to confusion regarding what is considered standard and what is
considered consensus which has tripped up several contributors over the
years.
This is part of a series of commits that aims to resolve all of the
aforementioned issues by introducing a new package named stdaddr which
entirely reworks the way addresses are handled.
For the time being, the package is introduced into the internal staging
area for initial review.
The following provides an overview of some of the key features of the
new design:
- Supports versioned addresses
- Produces scripts directly via methods implemented on underlying types
- Provides direct support for creation of the scripts necessary for the
staking system
- Uses a capabilities-based approach via interfaces so callers can
cleanly and generically determine under what circumstances addresses
can be used
- Allows callers to create their own concrete address types without
worrying about breaking the existing ones
- Clearly denotes that addresses are a standardized construction that
must not be used directly in consensus code
In order to help ease the review process, this commit only contains the
overall generic infrastructure without adding support for any specific
address types. Each supported version 0 address type will be added in
future commits.
2b4557f56e