[ZIPs 207, 214, 251] Consensus ZIPs for Zcash Development Fund #332
Conversation
|
@str4d all your comments should have been addressed, please re-review. We also need a reviewer from ZF. |
daira
force-pushed
the
zip-0251
branch
3 times, most recently
from
4f94882
to
ab5e7ef
Compare
|
Waiting on @acityinohio to decide whether ZF objects to the SHALL requirement for independent addresses. |
Thanks for the mention @daira; I agree with @gtank and based on the discussion here I'd definitely prefer SHOULD instead of SHALL; it would give us more leeway given the Foundation's current custody arrangements, which lend themselves to using the same address. I'm perhaps not the best person to talk about the trade-offs here but I can say that we feel comfortable using the same address for the time being, given the environment in which it was generated, the insurance against it, and how it's stored. |
daira
force-pushed
the
zip-0251
branch
2 times, most recently
from
be53e79
to
8b143d7
Compare
| \mathsf{AddressChangeInterval} &=& \mathsf{PostBlossomHalvingInterval} / 48 \\ | ||
| \mathsf{AddressPeriod}(\mathsf{height}) &=& | ||
| \mathsf{floor}\left( | ||
| {\small\frac{\mathsf{height} + \mathsf{PostBlossomHalvingInterval} - \mathsf{HeightForHalving}(1)}{\mathsf{AddressChangeInterval}}} |
There was a problem hiding this comment.
Why is PostBlossomHalvingInterval added in the numerator, doesn't that just add 48 to the result?
There was a problem hiding this comment.
Yeah I don't see why that's necessary. It doesn't change the specified behaviour, because only differences between two outputs of AddressPeriod are used in the computation of FundingStream[Fund].AddressIndex(height). I guess a C++ implementation would have to be more careful to implement floor correctly, since without the addition of PostBlossomHalvingInterval, the AddressPeriod could be negative before the first halving. (This cannot happen on mainnet with the planned activation height, but can happen on testnet.)
There was a problem hiding this comment.
@str4d, do you think we should change this, or not?
daira
force-pushed
the
zip-0251
branch
2 times, most recently
from
c4c4037
to
90ab3de
Compare
|
This still needs an ACK from a ZF reviewer. |
Signed-off-by: Daira Hopwood <[email protected]>
Signed-off-by: Daira Hopwood <[email protected]>
Signed-off-by: Daira Hopwood <[email protected]>
Signed-off-by: Daira Hopwood <[email protected]>
Signed-off-by: Daira Hopwood <[email protected]>
Signed-off-by: Daira Hopwood <[email protected]>
Signed-off-by: Daira Hopwood <[email protected]>
Signed-off-by: Daira Hopwood <[email protected]>
…ht is exclusive. Signed-off-by: Daira Hopwood <[email protected]>
Signed-off-by: Daira Hopwood <[email protected]>
Signed-off-by: Daira Hopwood <[email protected]>
Signed-off-by: Daira Hopwood <[email protected]>
Signed-off-by: Daira Hopwood <[email protected]>
Signed-off-by: Daira Hopwood <[email protected]>
Signed-off-by: Daira Hopwood <[email protected]>
… the numerator won't overflow. Signed-off-by: Daira Hopwood <[email protected]>
…ive after NU4 activation. Signed-off-by: Daira Hopwood <[email protected]>
Signed-off-by: Daira Hopwood <[email protected]>
…tRoot. Signed-off-by: Daira Hopwood <[email protected]>
Signed-off-by: Daira Hopwood <[email protected]>
Co-Authored-By: str4d <[email protected]>
Remove definitions of unused RFC 2119 keywords. Signed-off-by: Daira Hopwood <[email protected]>
Signed-off-by: Daira Hopwood <[email protected]>
…RIOD` the same in terms of blocks, but it represents 1.5 days for the Heartwood upgrade onward. Signed-off-by: Daira Hopwood <[email protected]>
Signed-off-by: Daira Hopwood <[email protected]>
daira
requested review from
acityinohio
and removed request for
defuse and
str4d
closes #328 and #330