Yuval Kogman

with the more interesting building blocks we've been exploring it should be possible to realize this similar to or more simply than what i suggested in my first original draft:...

Some notes following today's call: - Fee amount and output registration amounts must be accounted separately in order to ensure that conversion is one way. This means there are both...

For this to be viable, we might need stronger security proofs for the unfogeability of MACs (perhaps we could consider Anonymous Credentials Light scheme as a drop in replacement, where...

In order for the coordinator to know the total outstanding prepaid fee token amounts, conversions between different long lived credential epochs need to have cleartext amounts. This matters both for...

i don't think that a percentage change in the value is the right way of framing it, if the difference is small enough to be negligible to the payer/merchant, then...

I think "stable base" doesn't quite capture it, since this is a straw man. To me our conversation was more about about defining the boundaries of the design space, using...

So tor circuits are less robust than say a mixnet, a global passive adversary colluding with the coordinator, as well as just things like timing information (although as I described...

A slightly more concrete explanation of how this helps from client perspective: Suppose all inputs have been registered, and clients now provide an ownership proof, which is a signature (the...

For the approach we discussed fetching of the tx is required between outptut transaction signing, or for the alternative approach Alices should fetch the tx. The round param signatures should...

also i don't think we should list SumProof here, unless we also want to break down everything else (initial credentials, and for each registration including inputs, the list of requested...