[Cryptography] GNU's "anonymous-but-taxable electronic payments system" Heh.

Jeff Burdges burdges at gnunet.org
Fri Jun 10 16:48:03 EDT 2016

On Fri, 2016-06-10 at 09:47 -0400, Robert Hettinga wrote:
> So, now a question. Can Thaler work in such a model? Could it just
> be hooked up, modulo the odd twiddle and the approval of your
> friendly local force monopoly, to somebody like CREST, or DTC?  

I'm not sure I understand.

Taler should work well for handling most fungible assets. 

Taler would not necessarily be suitable for assets that incorporate an
obligation.  I suppose the financial world has invented assets that,
while still fungible, either entitle obligations themselves or have
legal obligations imposed on them.  

As an aside, I once sketched out a bi-directional system where employers
pay employees using something like Taler while employees obtain a tax
receipt coin upon depositing wages that they return to their employers.
In this scenario, the employees and employers are not anonymous to one
another, but their relationship is hidden from their banks.  I'd think
such bi-directional schemes could handle many legally encumbered assets

In any case, I'm concerned that you might not be talking about
non-fungible assets based on : 
> Sticking a nonce or something out of band was probably how we were
> going to know how to match certificate deposits/withdrawals with 
> certificates.

I'm dubious if anonymity makes any sense for non-fungible assets
anyways, so I'm going to ignore that bit and continue.  :) 

I have not quite understood what you mean by m-to-n, but..

Taler has an auditor party that helps determine what exchanges (mints)
the customers and merchants will use.  Auditors sign the denomination
keys issued by exchanges.  At most one exchange should be involved in
any given transaction, but it's okay if your wallet has coins issued by
many exchanges, even if they are both issuing Euros or whatever. 

A Taler exchange issues a separate denomination key for every value of
each asset type it handles.  If your exchange handles BTC, then it might
for example select a small array (x_i) of values such that x_{i+1} = 3
x_i and x_i BTC lies between $0.01 and $200 at exchange rates when the
denomination is issued.  It'd issue an "x_i BTC" denomination key for
each x_i.  We allow partial spending through the refresh protocol. 

If you're doing fancy financial instruments, then at some point I'd
think the anonymity set would become too small to be worth it.  

If the assets are fungible but not divisible, then you'd never partially
spend, but the refresh protocol would still be used when either (a) the
coin's anonymity was tainted by failed a transaction, or (b) the coin's
denomination key is about to expire.  We've several dates attached to
denomination keys, issuing range, spendable range, refreshable range,
and maybe another.  After all that records no longer kept, at least not

It's important that denomination keys eventually expire, not just for
the database, but also so that the exchange knows it was not defrauded,
by say an employee who stole the denomination key.  I suppose
denomination keys expiration might allow assets with some classes of
obligations, including some forms of taxes.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20160610/81409aa1/attachment.sig>

More information about the cryptography mailing list