mirror of https://github.com/zcash/zips.git
ZIP 320: Add a note about user experience downsides to Alternative 1
This commit is contained in:
parent
2e103629a6
commit
e1f43c6760
|
@ -186,6 +186,7 @@ impl TryFromAddress for TraceableReceiver {
|
||||||
</section>
|
</section>
|
||||||
<section id="cons-to-alternative-1"><h3><span class="section-heading">Cons to Alternative 1</span><span class="section-anchor"> <a rel="bookmark" href="#cons-to-alternative-1"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
<section id="cons-to-alternative-1"><h3><span class="section-heading">Cons to Alternative 1</span><span class="section-anchor"> <a rel="bookmark" href="#cons-to-alternative-1"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||||
<ul>
|
<ul>
|
||||||
|
<li>Existing wallets and other Consumers will regard the new address type as entirely invalid, and will not automatically prompt their users that they need to upgrade in order to send to this type of address.</li>
|
||||||
<li>Creation of a new fully-distinct address type further fragments the Zcash address ecosystem. Avoiding such fragmentation and providing smooth upgrade paths and good error messages to users is exactly the problem that Unifed Addresses <a id="footnote-reference-17" class="footnote_reference" href="#zip-0316-unified-addresses">5</a> were intended to avoid.</li>
|
<li>Creation of a new fully-distinct address type further fragments the Zcash address ecosystem. Avoiding such fragmentation and providing smooth upgrade paths and good error messages to users is exactly the problem that Unifed Addresses <a id="footnote-reference-17" class="footnote_reference" href="#zip-0316-unified-addresses">5</a> were intended to avoid.</li>
|
||||||
<li>The TEX address type does not provide any mechanism for address expiration. One of the questions Binance has asked has been what to do about users who have stored their existing transparent deposit address in their wallets, or as a withdrawal address for other exchanges or services. This is a challenging problem to mitigate now because address expiration was not previously implemented. We should not further compound this problem by defining a new distinct address type that does not provide a mechanism for address expiry.</li>
|
<li>The TEX address type does not provide any mechanism for address expiration. One of the questions Binance has asked has been what to do about users who have stored their existing transparent deposit address in their wallets, or as a withdrawal address for other exchanges or services. This is a challenging problem to mitigate now because address expiration was not previously implemented. We should not further compound this problem by defining a new distinct address type that does not provide a mechanism for address expiry.</li>
|
||||||
</ul>
|
</ul>
|
||||||
|
|
|
@ -299,6 +299,9 @@ Pros to Alternative 1
|
||||||
Cons to Alternative 1
|
Cons to Alternative 1
|
||||||
---------------------
|
---------------------
|
||||||
|
|
||||||
|
- Existing wallets and other Consumers will regard the new address type as
|
||||||
|
entirely invalid, and will not automatically prompt their users that they
|
||||||
|
need to upgrade in order to send to this type of address.
|
||||||
- Creation of a new fully-distinct address type further fragments the Zcash
|
- Creation of a new fully-distinct address type further fragments the Zcash
|
||||||
address ecosystem. Avoiding such fragmentation and providing smooth upgrade
|
address ecosystem. Avoiding such fragmentation and providing smooth upgrade
|
||||||
paths and good error messages to users is exactly the problem that Unifed
|
paths and good error messages to users is exactly the problem that Unifed
|
||||||
|
|
Loading…
Reference in New Issue