Daira-Emma Hopwood

It can be implemented by: - changing the address construction so that an address contains and commits to an expiry point (e.g. let apk = PRFaddrask(expiry) and let addrpk =...

@ebfull We implicitly assume the integrity of addresses even in the existing protocol (that is, we assume that addresses are communicated securely and payments are sent to the intended address)....

@maaku In the case of expiry and assuming that both transactions and addresses have an expiry expressed as block height (as I suggested on #716), a transaction creator would know...

See also #754 (maximum transaction lifetime).

Note that in the context of a protocol with diversified addresses (#570), the expiration date/height leaks information that might be used to link addresses. For example, if a user chooses...

@nuttycom suggested that instead of associating expiry with addresses, we could add it to [ZIP 321](https://zips.z.cash/zip-0321) Payment Request URIs. That would get around the diversified address linkability problem (because Payment...

Suggestions for how to migrate issues etc. as well as the repo: https://stackoverflow.com/a/54420348/393146

I'm interested in this and will make an attempt.

I prototyped this in https://github.com/zcash/zcash/pull/6554 . That PR makes assumptions specific to zcashd but I can easily disentangle it (and port the tests from `Google Test` to `Catch2`) if I...

I opened this mainly to check what it did for the purpose of https://github.com/dependabot/dependabot-core/issues/9210. It appears to do the right thing, i.e. the equivalent of `cargo update -p mio`. It's...