Daira-Emma Hopwood

@ebfull wrote: > @daira wrote: > > > In the circuit, prove in zero knowledge that the revocation tokens for each output address are not in the revocation tree corresponding...

@nathan-at-least wrote: > Note, during a meeting just now we were exploring the potential of a more naive, less private, less perfect potential implementation that's very roughly "publish revoked addresses...

It seems to me that the fact that revocation entries are linkable with receiving addresses is actually quite a severe privacy loss. Suppose that we were not using Tor; then,...

The zero-knowledge scheme I proposed in the first comment above doesn't work. The creator of the Pour only has apk, 1..Nnew, so they don't know what the revocation tokens for...

@zookozcash wrote: > Another way having a revocation ability could help is that people might get into habits of rotating their spending-keys more often, since they can cleanly shut down...

I'm not sure I see the problem with reorgs. From the receiver's point of view, if they have just revoked their address and receive a payment to it, or if...

Note that the transaction time-to-live idea would interact positively with making mempools [*] persistent; currently nodes rely on being reset to clear out old transactions, but this would expire them...

@ebfull wrote: > There are two concrete choices, regardless of the protocol: > 1. Do we want a system that allows the posessor of a spending key to, with authentication,...

Here's the mermaid-js feature request: https://github.com/mermaidjs/mermaid-live-editor/issues/36 Doesn't seem to be any active work on it.

> Is it our intention to deprecate zcashd before NU6 activation? No. The current plan is to deprecate it before NU7 activation.