ZIP 320: Specify alternatives for transparent-source addresses. #760
Conversation
nuttycom
force-pushed
the
zip-316/t_source_addrs
branch
from
2a9074c
to
fc57533
Compare
This provides two alternatives for how to implement transparent-source-only addresses: * A new, separate `bech32m` encoding with the `tex` human-readable part * A modification to Unified Addresses to support the transparent-source requirement.
nuttycom
force-pushed
the
zip-316/t_source_addrs
branch
from
fc57533
to
ae1e49f
Compare
Co-authored-by: Daira Emma Hopwood <daira@jacaranda.org>
nuttycom
force-pushed
the
zip-316/t_source_addrs
branch
from
c1af0f9
to
2e10362
Compare
|
|
||
| A Unified Viewing Key MUST contain at least one shielded Item (Typecodes | ||
| :math:`\mathtt{0x02}` and :math:`\mathtt{0x03}`). | ||
|
|
There was a problem hiding this comment.
I think it's also necessary to add "Traceable P2PKH Receiver" to the ZIP 316 priority list. You might think that (after applying the suggestion above) it's not necessary to define its priority, because for any UA that has a Traceable P2PKH Receiver, it will be the only Receiver. However, ZIP 316 defines the "preferred" ordering like this:
We say that a Receiver Type is “preferred” over another when it appears earlier in this Priority List (as potentially modified by experiments).
which means that it is not well-defined to specify that the most-preferred Receiver is used unless all Receiver types have a priority. Also, implementations will in practice give all types a priority because that's the simplest way to implement it — so it might as well be specified that way.
There was a problem hiding this comment.
Hm. So does that mean that a Traceable P2PKH Receiver has the highest priority? I think that I would prefer to mention Traceable P2PKH Receivers in the section where priorities are defined, but instead of assigning a priority clarify that the priority of a Traceable P2PKH Receiver is undefined as it must never be present in an address with any other receivers.
Sum type, rather than picking an "unused" element of the domain, you know?
There was a problem hiding this comment.
I don't think it matters as long as the Receiver selection is well-defined.
Co-authored-by: Daira Emma Hopwood <daira@jacaranda.org>
nuttycom
force-pushed
the
zip-316/t_source_addrs
branch
from
d080c07
to
e11ddc4
Compare
Co-authored-by: Daira Emma Hopwood <daira@jacaranda.org>
|
|
||
| The Binance cryptocurrency exchange requires that funds sent to their deposit | ||
| addresses come from source addresses that are readily identifiable using | ||
| on-chain information, such that if necessary funds may be rejected by sending |
There was a problem hiding this comment.
Could we add commas before/after "if necessary" here for clarity?
|
Post-hoc review, looks good |
This provides two alternatives for how to implement transparent-source-only addresses:
texhuman-readable partcloses #757