@ -10,7 +10,7 @@ The obvious advantage of the original implementation was avoiding structural cha
## Goals
* We should take this opportunity to understand the implementation better, and build on top of a more recent version of Bitcoin. Upstream has made a number of changes to critical components and has begun to refactor consensus-critical code into a `libconsensus` library.
* We should rigorously practice our [design policy](https://github.com/Electric-Coin-Company/zerocashd/wiki/design). This includes avoiding changes to upstream's scripting system wherever possible, and only modifying structures with proper versioning plans.
* We should rigorously practice our [design policy](https://github.com/zcash/zcash/wiki/design/43500230370684f74c53366f4f8a5094dcb2951a). This includes avoiding changes to upstream's scripting system wherever possible, and only modifying structures with proper versioning plans.
* We should strive to preserve the semantics of our private alpha implementation such that the `zc-raw-*` RPC commands still work properly.
## Scope
@ -20,10 +20,10 @@ The obvious advantage of the original implementation was avoiding structural cha
* **Versioning semantics** ([#114] [ticket114]) require us to avoid breaking upstream tests whenever possible. We need to anticipate both changes to our own structures after launch to support new features (such as circuit changes, see #152) and potential changes to upstream transaction structures we will eventually need to rebase on top of.
* **Cryptographic binding of pours** ([#366] [ticket366]) is necessary to ensure that (in the most common situation) it is not possible to move a pour from one transaction to another, or replace pours in a transaction without the authorization of its inputs.
Daira Hopwood
8 years ago