[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[taler-donau] 01/02: Initial commit including the layout of the conferen
From: |
gnunet |
Subject: |
[taler-donau] 01/02: Initial commit including the layout of the conference (from the Deliverable 3.4) |
Date: |
Wed, 08 Jan 2025 15:53:21 +0100 |
This is an automated email from the git hooks/post-receive script.
emmanuel-benoist pushed a commit to branch master
in repository donau.
commit 4ab19a98d17be14437b95f2fe5d7bd767ffd0b2c
Author: Emmanuel Benoist <emmanuel.benoist@bfh.ch>
AuthorDate: Wed Jan 8 15:49:37 2025 +0100
Initial commit including the layout of the conference (from the Deliverable
3.4)
---
doc/usenix-security-2025/paper/.#donau-paper.tex | 1 +
.../paper/D3.4-NGI_TALER-deliverabledonations.txt | 274 ++++++++++++
doc/usenix-security-2025/paper/bibliography.bib | 123 ++++++
doc/usenix-security-2025/paper/blue_wax.png | Bin 0 -> 90911 bytes
doc/usenix-security-2025/paper/charity.jpg | Bin 0 -> 591300 bytes
doc/usenix-security-2025/paper/coins.png | Bin 0 -> 34394 bytes
.../paper/db_physical_model.png | Bin 0 -> 154375 bytes
doc/usenix-security-2025/paper/discussion.tex | 296 +++++++++++++
doc/usenix-security-2025/paper/donau-paper.bib | 70 ++++
doc/usenix-security-2025/paper/donau-paper.pdf | Bin 0 -> 855212 bytes
doc/usenix-security-2025/paper/donau-paper.tex | 85 ++++
doc/usenix-security-2025/paper/donau.png | Bin 0 -> 35454 bytes
.../paper/donau_flow_issue_receipt.png | Bin 0 -> 628707 bytes
.../paper/donau_flow_register_charity.png | Bin 0 -> 169939 bytes
.../paper/donau_flow_submit_receipt.png | Bin 0 -> 237068 bytes
.../paper/donau_system_arch.png | Bin 0 -> 42792 bytes
doc/usenix-security-2025/paper/ethic.tex | 7 +
doc/usenix-security-2025/paper/gold_wax.png | Bin 0 -> 104603 bytes
doc/usenix-security-2025/paper/golden_stamp.jpg | Bin 0 -> 21643 bytes
doc/usenix-security-2025/paper/green_wax.png | Bin 0 -> 94938 bytes
.../paper/images/TalerDiagram.svg | 361 ++++++++++++++++
doc/usenix-security-2025/paper/images/stock1s.jpg | Bin 0 -> 75595 bytes
doc/usenix-security-2025/paper/implementation.tex | 354 ++++++++++++++++
doc/usenix-security-2025/paper/intro.tex | 168 ++++++++
doc/usenix-security-2025/paper/letter.png | Bin 0 -> 126596 bytes
doc/usenix-security-2025/paper/qr-donau.png | Bin 0 -> 1941 bytes
doc/usenix-security-2025/paper/receipt.png | Bin 0 -> 14567 bytes
doc/usenix-security-2025/paper/red_wax.png | Bin 0 -> 99837 bytes
doc/usenix-security-2025/paper/requirements.tex | 460 +++++++++++++++++++++
doc/usenix-security-2025/paper/servers.png | Bin 0 -> 18421 bytes
doc/usenix-security-2025/paper/stickman.png | Bin 0 -> 36989 bytes
doc/usenix-security-2025/paper/taler-short.cls | 317 ++++++++++++++
doc/usenix-security-2025/paper/taler.cls | 322 +++++++++++++++
doc/usenix-security-2025/paper/tax-authority.png | Bin 0 -> 7977 bytes
doc/usenix-security-2025/paper/technicaldesign.tex | 452 ++++++++++++++++++++
doc/usenix-security-2025/paper/usenix-2020-09.sty | 129 ++++++
36 files changed, 3419 insertions(+)
diff --git a/doc/usenix-security-2025/paper/.#donau-paper.tex
b/doc/usenix-security-2025/paper/.#donau-paper.tex
new file mode 120000
index 0000000..89a877b
--- /dev/null
+++ b/doc/usenix-security-2025/paper/.#donau-paper.tex
@@ -0,0 +1 @@
+bie1@macbook-pro-7.lan.15177
\ No newline at end of file
diff --git
a/doc/usenix-security-2025/paper/D3.4-NGI_TALER-deliverabledonations.txt
b/doc/usenix-security-2025/paper/D3.4-NGI_TALER-deliverabledonations.txt
new file mode 100644
index 0000000..db59785
--- /dev/null
+++ b/doc/usenix-security-2025/paper/D3.4-NGI_TALER-deliverabledonations.txt
@@ -0,0 +1,274 @@
+# 3.4 Requirements for donation flow
+
+## Introduction
+
+### Scope
+
+The scope of this document is to provide an overview of potential technical
requirements for donation systems that wish to collaborate with tax authorities
to grant tax benefits to donors to recognised public benefit efforts.
+
+This document is written in the context of the [NGI
TALER](https://ngi.taler.net) project, which is based around the electronic
payment system GNU Taler. As may be obvious from the underlying acronym
"Taxable Anonymous Libre Electronic Resources", GNU TALER bridges two seemingly
opposite requirements: providing privacy to citizens with regards to how they
spend their money in the digital realm that has the same properties we are used
to with traditional cash payments, while at the same t [...]
+
+GNU Taler is a *digital commons*, based on free software and advanced
cryptography. This means that - unlike proprietary products - the software can
be adjusted by all stakeholders to carry the properties it should have.
+
+There are two types of donations we will consider. The first is **ad hoc** or
**informal donations**, which are made from individual to individual as **one
time gifts** typically in appreciation of the work being done by an individual
or collective. The second category is **regulated donations** involving at
least one *recognised* philanthropic organisation. Both involve voluntary
transferral of some financial assets for which no products or services are
rendered in return.
+
+In the design requirements we will try to address both types of donations,
obviously with the complexity expected to be with compliance with fiscal
instruments that stimulate donations to philanthropies triggers.
+
+### Donations in a human rights perspective
+
+Donating is an important way for people to empower causes they believe in, and
facilitate collective action. In many countries, there is explicit recognition
of the public benefit of such generosity: a friendly tax treatment of
donations. It makes sense: money you immediately give away to a recognised good
cause is not income that will be converted by you into private consumption. So
conceptually it deserves a different tax treatment.
+
+Donations have many causes, but quite often they are an obvious expression of
the human right towards the freedom of thought, conscience and religion.
Individual spending can be very intimate and personal, and even aggregate
spending habits can reveal a great deal about people. This holds even more so
for donating.
+
+Protecting donation confidentiality is therefore important to protect those
freedoms. We have to recognise that in some situations the mere fact hat
someone has - in private - donated to some cause at some point in their life,
can put them at risk in another context. The right to privacy is another
critical aspect of donating. International human rights law provides a
non-ambiguous responsibility to promote and protect the right to privacy.
+
+Both these righs are anchored in key international treaties and covenants such
as the Universal Declaration on Human Rights (Article 12), the European
Convention for the Protection of Human Rights and Fundamental Freedoms (Article
8) and many more.
+
+As part of their regular operations as well as their recognition as public
benefit organisations, philanthropies are already subject to a variety of
audits as well as strict regulatory and fiscal scrutiny. Good causes that don't
adhere to these rules, are stripped from any fiscal benefits. At least
donations to recognised public benefit organisations may therefore be
confidential: donors should be able to freely choose whichever of the approved
philanthropies they donate to, without disc [...]
+
+In cases where donation confidentiality is not (yet) feasible, we will try and
provide fallbacks that best serve the interest of donors, gives them choice and
respects their privacy as least as good as the current system in place.
+
+### Protection towards all sides
+
+Privacy threats not only exist on the outside. Not many people are aware that
while the causes they support may be worthwhile, not all philanthropies play as
nice as one would expect them to towards donors. This happens in particular
when such organisations employ third party (often commercial) agencies to help
"yield" more donations on a commission basis or as 'fund raisers'. Especially
for-profit fund raising agencies tend to resort to questionable social
engineering approaches. One co [...]
+
+In the era of data driven donations and corporate social media surveillance,
this kind of behaviour has unfortunately become so easy that there are not just
pro bono but even paid services (source: [Stichting
Donateursbelangen](https://www.donateursbelangen.nl/opzegservice) to deregister
and exercise the 'right to be forgotten' after donating.
+
+Even without such excesses, there are many circumstances when people like to
donate something to their preferred causes without revealing their identity.
Some people just prefer to stay anonymous because of personal beliefs or even
religious requirements, or simply don't want to have publicity which might lead
to a cascade of begging efforts from fund raisers.
+
+### Donation confidentiality
+
+Making a financial donation is a deeply personal choice to share part of ones
wealth in order to benefit a cause one cares about. Some traditional ways of
donating (for instance passing around baskets or even plates in a religious
gathering) are vulnerable to group pressure, and door to door fundraising is
also confrontational and puts people on the spot.
+
+When donations are devoid of such pressures and there is no need for e.g.
virtue signalling, donation confidentiality comes into play. Historically,
people wanting to make an anonymous donation might have an envelope with cash
or a box of goods delivered. Obviously, this was never compatible with
providing tax benefits. Alternatively, they might arrange for an expensive
intermediary like a notary (although technically that would not be fully
anonymous, depending on the discretion of the [...]
+
+Technically guaranteed donation confidentiality is certainly non-trivial to
implement in the digital payment era. What you donate to and why may be
strictly personal, but due to the nature of the banking system along the
financial pipeline there are an uncomfortable amount of actors handling
sensitive data that allows for profiling and targeted discrimination on
grounds. And there are even more that later on may have access to it. Digital
payments are logged and made accessible to many d [...]
+
+### What this document is not
+
+This document is not in any way a overview of current legal requirements
across the world on how taxation on donations work. Taxation is predictably
unpopular despite its clear essential function in how modern societies work,
and therefore a very political topic that is subject to frequent change.
Whether it is taxation on labour and profits, on property, on inheritance, on
income from investment or gambling, or on consumption of products or services -
there is no global universally agr [...]
+
+Instead the focus of this document is on providing an overview of generic
requirements that could be made to a donation flow in order to comply with
regulation.
+
+One should note that in many legislations, recipients of donations do not
necessarily have the same protections. Donations should be given without return
consideration, but of course there are many financial transactions (such as
gifts or donations from business or lobby groups to political parties) that are
not as clean in this respect.
+
+
+## Requirements
+
+The starting point of this document is to create an initial overview of
requirements to provide donors with donation privacy and tax authorities with
adequate proof that a donation was indeed clean and made according to the rules
for donations in their region of operation.
+
+Tax authorities are creative, and taxation is an ever evolving area of
complexity. We will therefore not claim to provide the definitive overview, but
to provide a good start for bootstrapping a donation ecosystem in the full
knowledge that this will need to be updated
+
+### Assumptions
+
+The basic assumptions when defining requirements for a donation flow are as
follows:
+
+- a donor donates from their **own assets**, and is willing to go on record
(by means of a self-declaration) as acting on their own accord. Violation of
this principle would then constitute fraud at their end.
+- a tax authority wants to assert that a donation comes from the legitimate
donor, and is not made by some third party on their behalf
+- there is no inverse relationship between the donor and donee, where the
donor stands to receive money back from the donee in some concrete (in)direct
way as result of the donation.
+- donors are willing and able to provide privacy-preserving attestation of
some unique and non-falsifiable personal or organisational property (such as a
tax identification number) *at the time of donation* in order to be able to add
up multiple donations within a single tax reporting period and validate that
these don't pass beyond a threshold set by the tax authority or other regulators
+- we deal with philanthropies that are subject to *regulatory oversight*,
*proper governance* and *regular audits*, so that money laundering is not
relevant
+- it is acceptable for some third party to be involved, but only based on open
source technology and on a zero knowledge basis
+- philanthropies are able to provide valid digital signatures
+
+A possible threat model should include donations to be used for laundering
criminal assets. This does not mean that we expect charities themselves to play
foul, but tax benefits that could be transfered to someone else would
indirectly represent actual value (even commercially tradeable): donations
from someone paying lower tax rates could be used to artificially lower the
income of a person paying a higher rate. The money going to the charity would
essentially be used to trigger a laun [...]
+
+### Design goals
+
+The following design goals hold:
+
+- the donor wishes to remain fully anonymous, also towards the organisation(s)
donated to
+- the donor should be able to claim the tax benefits they are entitled to
without having to disclose any of the organisation(s) donated to to the tax
authority
+- the donor may accumulate any number of smaller or larger donations towards
different eligible organisations (ideally even cross-border, in the presence of
suitable fiscal arrangements such as within the European Union)
+- since donations are cumulative and often spontaneous, a donor should not
have to decide upfront whether they will request tax benefits for their
donations later on.
+- while at the same time, the wallet of a donor should offer plausible
deniablity of donations
+- charities and tax authorities are willing and able to run basic
infrastructure to achieve the above
+
+### Capabilities
+
+The following capabilities are needed to enable a maximum fit with as many
fiscal regimes as possible for both informal and regulated donations, while at
the same time serving the interest of the donors in question in the best
possible manner:
+
+- Provide fiscal statement
+- Proof of registration
+- Providing a configurable self-testimony from the donor that they comply with
specific legislation or regulation related to donations
+- Cumulative donation counter from same donor to same cause
+- Providing a notarised affidavit asserting uniqueness
+- Unique ID for voting/Donor Advised Choices
+- Making a compound weighted donation
+- Cost transparency
+- Staged donation
+- Bandwidth donations
+- Codes of conduct
+- Restricted access mechanism
+
+We will elaborate on each of these capabilities below.
+
+#### Capability: Provide fiscal statement
+
+The ability to providing a fiscal statement from the donee linked to the
donation is the starting point for most regulated donations, in order to comply
to current practices.
+With a time-stamped and printable fiscal statement of the amount, digitally
signed by the philanthropy, a donor can prove their donations in person to a
tax authority.
+
+It should be possible to obtain this statement at the time of donation, and
ideally within a reasonable period afterwards - in both cases without having to
expose any additional information to anyone (such as an IP address which is
typically visible when downloading a document via the web).
+
+There might be a need to include personal data/attributes in the attestion
(e.g. a name, password ID, etc). There is no need for the charity itself to
have any knowledge about such information, so it may be included encrypted with
a key accessible exclusively to the donor/the tax authority/an auditor or other
suitable independent third party.
+
+The information should be configurable, and it should be clear which
information is somehow independently validated.
+
+#### Capability: Proof of registration
+
+In some countries (e.g. Belgium) donors are required to register themselves
with the tax authority before making a donation. While we believe that to be an
anti-feature, it should be possible to include a checksummed code provided by
the tax authority or a philanthropy that makes sure that only registered donors
can donate.
+
+#### Capability: Configurable pledge
+
+It may be necessary for the donor to testify (prior to the donation) that they
comply with some legislative or regulatory requirement, or agree with a policy
set by the philanthropy in question.
+
+As a generic requirement, this translates to a configurable pledge (e.g. "I am
not an employee or grantee of the organisation I am donating to, and am acting
on my own accord. I stand to make no direct financial gains from making this
donation").
+
+The potential for abuse of donations to regulated charities is very limited.
Such a self-testimony will allow the default to be to treat donations in a
"good faith" manner rather than with a top-heavy and restrictive
one-size-fits-all method.
+
+#### Capability: Cumulative donation counter from same donor to same cause
+
+One way to bypass restrictions in terms of allowed donation sizes before "Know
Your Donor" requirements kick in, is to split donations up. It is therefore
necessary to be able to assert that cumulative donations from a donor stay
below a periodical threshold.
+
+#### Capability: Notarized affidavit
+
+More generically, for instance when there is a minimum age for donations to
certain class of causes, a privacy-preserving solution might be to have a
notarized affidavit independently asserting the requirements have been met to
be included in the metadata of the payment.
+
+Such an affidavit is likely to contain a unique uuid which is not traceable
back to any underlying private information of the donor or to the philanthropy
in question, plus a counter or append-only record, and a date stamp with an
accuracy no higher than a calendar week (to avoid correlation attacks).
+
+It is better for this affidavit not to be provided by individual
philanthropies but by trusted third parties otherwise ignorant of the
transactions in questions: it involves an isolated task which can easily be
outsourced to an independent service. That independent service only needs to
perform this singular task based on having access to the proof/attribute(s) in
question, does not need to have any further knowledge of any of the actors.
+
+As long as the affidavit is non-falsifiable and irrevocable, it should suffice
to assert uniqueness and allow to prove that the required conditions were met.
+
+#### Capability: Unique ID for donor advised decisions
+
+Also from the side of a donor, there might be a need for having a unique ID
for voting. In the same vein as Donor Advised Funds, a crowd-sourced version
could be Donor Advised Choices where donors can vote on specific options
("Shall we prioritize stretch goal A or B", or "We see a new opportunity, is it
okay to replace some stated work with something else") - either on a weighted
variant (larger donation gives more weight) or on a one person, one vote (all
unique donors get the same vote).
+
+Alternatively, a preference vote encoded inside the payment (based on e.g.
Condorset voting) could provide a one-time donor advised voting mechanism.
+
+#### Capability: Compound weighted donation
+
+The general idea is that donors can make a single donation, but this exists of
multiple payments to multiple recipients. This is particularly relevant for
informal donations to the developers of free and open source projects that do
not make use of a fiscal host. In such a situation, the donations may be
divided across the individual developers with a certain weight. Each of the
recipients receives a direct donation from the donor, which typically will be
far below the threshold for taxation.
+
+There can be a suggested/default weight, but the donor should be able to tweak
the relative weights and/or block specific recipients.
+
+#### Capability: Cost transparency
+
+It should be easy and transarent to the donor what percentage of their
donation is actually used for the effort for which funds are being raised. In
particular it should be possible for the **cost for fundraising** to be made
explicit, especially if this involves third parties. It should be possible to
choose to donate without paying for fundraising.
+
+(This might use the features from compound weighted donation)
+
+#### Capability: Staged donation
+
+This is a feature that works along the lines of so called smart contracts. As
goals are incrementally met by the project, donations are made. If the goals
are not met according to the preset stages, the part of the money that is
concerned with work that is not delivered is not paid and ultimately restored
to its rightful owner - the donor.
+
+#### Capability: Bandwidth donations
+
+When people are pooling together resources to make some goal possible, in
order to stimulate the broadest possible donations, the amount donated can be
made flexible (within a certain **donation bandwidth**). Instead of stretching
goals (which donors might not agree with) and promoting freeloading, the size
of individual donations could shrink as well. This would stimulate to share the
collective load.
+
+#### Capability: Code of conduct
+
+Donors transfer part of their (sometimes scarce) eartly possessions to support
the good work of a cause they believe in, and it is only logical that this
altruism comes with certain expectations in terms of how the organisation
receiving that money will subsequently spend it.
+
+A **Code of Conduct** is the equivalent of the product warranty, where
philanthropies declare themselves accountable and promise to uphold certain
best practices and adhere to public scrutiny - and are subsequently held to
their promise by stakeholder organisations like Donateursbelangen.
+
+An example of such a Code of Conduct public benefit organisations can
subscribe to is the [Donor
Pledge](https://www.donateursbelangen.nl/de-donateursbelofte)
("Donateursbelofte"). It should be possible to adhere to multiple such Code of
Conducts.
+
+Similarly, there are certification schemes for public benefit organisations.
These offer a reverse link from the certifying organisation to the
philanthropy. It should be possible to include the certification conditions and
this reverse link alongside the payment.
+
+#### Capability: Restricted access mechanism
+
+In order to engage donors with the work being done, philanthropies might want
to give 'behind the scenes' access to ongoing work to their donors. In order
for that to happen, it should be possible to provide (limited) access to
restricted materials. For instance this could be handing out *One Time
Passwords* or other forms of proof of donation that will allow donors to get
access to restricted areas.
+
+#### Capability: Unlock thank you artwork
+
+Making a donation is not just a clinical financial transaction where money is
transfered from A to B, but something that also has emotional weight: the donor
has taken a step they may have pondered about for a long time.. Celebrating
this altruistic win is part of the donation experience. Thank you artwork
consists of images, video and/or audio used to enliven the financial
transaction.
+
+In some cases artists or other creatives might donate a work to the
philanthropy in question for this purpose, in other cases a charity might use
photos of their day to day work.
+
+#### Capability: Donation matching with a reference
+
+In some cases, a benefactor will want to incentivise others contemplating a
donation to a specific good cause to go ahead. That is not necessarily
something that needs privacy: some people and organisations use donations to
publicly profile themselves. A common mechanism to incentivise others is to
promise to match their donations to the organisation in question, which is
frequently done by announcing a period in which other peoples donations will be
"matched" (as in: donor A promises to [...]
+
+However, this is obviously a very crude mechanism, only suitable for
benefactors with very deep pockets. It also doesn't give much opportunity for
the benefactor to explain why they do this (and, let's be realistic, get some
PR out of it as well).
+
+By allowing the donor to include a reference to e.g. a social media post or
blog post announcing the matching, the donor can 'see' that they are being
heard/are getting PR mileage out of their donation.
+
+#### Capability: Donation matching with a reference
+
+Quite a few large employers do donation matching as part of their corporate
responsibility or HRM efforts. This is typically not tied to a single cause.
Many larger employers sponsor such matching gift programs, either by themselves
(such as the U.S. Office of Personnel Management's [Give
CFC](https://givecfc.org)) or via (expensive) third party organisations such as
Benevity, Submittable, WeSpire, Goodera, etc.
+
+In many cases, this practice is rather privacy-invasive. If you donate to e.g.
a reproductive rights organisation, an NGO promoting climate justice or a
digital rights organisation, an employer might have some opinion about this. It
would be better if this could be done via GNU Taler. This would require a
mechanism similar to DONAU where charities could prove to an employer that some
eligible person (typically an employee or retiree) has donated money which
needs to be doubled - obvously [...]
+
+## General background information
+
+This chapter contains general background information pertaining donations.
+
+### General Regulatory Framework
+
+European Union (EU) member states regulate donations through a blend of
EU-wide directives and country-specific laws. While there isn’t a uniform
regulation that applies to all donations in Europe, certain EU directives and
principles affect donation practices, particularly those related to
transparency, anti-money laundering (AML), tax compliance, and donor data
protection.
+
+### Transparency and Accountability
+
+Transparency in charitable donations is crucial to maintain public trust and
deter financial misuse. European countries typically require organizations that
receive donations to adhere to transparency measures, including:
+
+ - **Public Financial Reporting:** Most European countries mandate that
charities, nonprofits, and similar organizations publish annual financial
reports. These reports generally include detailed breakdowns of income sources,
donation amounts, and expenditures.
+ - **Disclosures for Large Donations:** In some countries, large donations
must be reported to regulatory authorities. This threshold and the specific
requirements vary by country. For example, Germany requires registration for
organizations receiving public donations, while the UK mandates certain
reporting for donations above a particular threshold.
+ - **Third-Party Audit Requirements:** To verify the financial integrity of
charitable organizations, many countries mandate independent audits for
organizations surpassing specific revenue thresholds.
+
+### Anti-Money Laundering (AML) and Counter-Terrorism Financing (CTF)
+Given the potential for abuse of charitable donations for money laundering and
financing illegal activities, EU-wide Anti-Money Laundering Directives (such as
the AMLD5) require organizations to implement stringent controls.
+
+ - **Know Your Donor (KYD):** Similar to the Know Your Customer (KYC)
practices in the financial sector, some countries require organizations to
verify the identity of donors making significant contributions. This
requirement is typically tied to AML laws.
+ - **Transaction Monitoring and Reporting:** Charitable organizations must
monitor donation transactions and report any suspicious activities to relevant
national authorities.
+ - **Registration with Financial Intelligence Units (FIUs):** Nonprofits are
encouraged, and sometimes required, to register with FIUs in certain EU
countries to facilitate AML compliance.
+
+### Taxation and Deductibility
+
+The tax treatment of donations varies across Europe, but many countries
provide tax incentives to encourage charitable giving. Donations to qualifying
nonprofit organizations are often tax-deductible, either partially or fully,
depending on local laws.
+
+ - **Eligibility of Donors and Organizations:** Both the donor and the
recipient organization usually need to meet specific criteria. For instance,
donations to accredited charities registered with national authorities are
often eligible for tax relief.
+ - **Limits on Deductions:** Most countries place caps on deductible
donations, typically as a percentage of the donor’s income. For example, France
allows deductions up to 20% of taxable income, whereas Germany permits
deductions up to 20% of annual income or corporate profits.
+ - **Cross-Border Donations and Tax Relief:** The EU's "Stauffer doctrine"
principle requires member states to treat cross-border donations similarly to
domestic donations if the recipient organization meets equivalent standards,
which facilitates cross-border charitable giving across the EU.
+
+### Data Protection and Privacy (GDPR)
+
+The General Data Protection Regulation (GDPR) is a significant EU law that
affects how personal data is collected, stored, and managed, including for
donations.
+
+ - **Consent for Data Collection:** Donors must be informed of how their
personal data will be used, and organizations must obtain explicit consent if
data will be used for purposes beyond the donation transaction itself, such as
marketing.
+ - **Data Minimization and Retention:** Organizations are expected to
collect only the data necessary for processing the donation, retain it only as
long as necessary, and ensure proper data deletion practices.
+ - **Right to Access and Erasure:** Donors have the right to request access
to their personal data held by an organization and can request deletion of
their data under specific circumstances.
+
+### Corporate Donations and Sponsorships
+Corporate donations are also regulated, particularly when related to tax
deductibility, disclosures, and compliance requirements.
+
+ - **Transparency in Corporate Sponsorships:** European countries may
require public disclosure of corporate donations or sponsorship arrangements,
especially when public funds are involved. Many countries also enforce rules
against donations that may appear to be intended for influencing legislation or
government actions.
+ - **Limits on Corporate Donations:** Some countries impose caps on
corporate donations eligible for tax relief to prevent excessive deductions and
potential misuse.
+
+### Cross-Border Giving and EU Philanthropy Initiatives
+The European Union encourages philanthropy across borders within Europe, but
the process is still complex due to varying national tax and legal frameworks.
+
+ - **European Foundation Statute and the European Philanthropy Manifesto:**
These initiatives aim to harmonize cross-border philanthropy regulations. The
proposed European Foundation Statute, for instance, would create a legal form
of a foundation operating across the EU.
+ - **Transnational Requirements for Nonprofits:** Nonprofits must navigate
both the tax and regulatory requirements of each country in which they operate
or fundraise, including any special registrations, tax filings, or
documentation for cross-border transactions.
+
+### Ethical Standards and Codes of Conduct
+
+Some European countries have established or encouraged adoption of ethical
standards or codes of conduct for fundraising activities. Examples include:
+
+ - **Code of Conduct for Fundraising:** Many countries have adopted codes of
conduct, which may govern methods for soliciting donations, advertising
practices, and donor interaction protocols. There are also private initiatives
such as the Donor Pledge from the Dutch foundation Donateursbelangen ("Donor
Interest Foundation").
+ - **Charity Commissions and Regulatory Bodies:** Several European countries
have independent regulatory bodies that oversee charitable organizations, such
as the Charity Commission in the UK, to ensure compliance and ethical conduct
in donations.
+
+### Country-Specific Considerations
+
+While EU-wide directives provide a framework, each country has unique laws.
Here are a few examples:
+
+ - **Germany:** Nonprofit organizations must register with local authorities
to receive tax exemptions, and donations exceeding €10,000 must be reported.
+ - **France:** Nonprofits must adhere to the "Loi de 1901" and comply with
annual reporting requirements to remain eligible for public donations.
+ - **Italy:** Nonprofits are eligible for tax incentives if they register as
ONLUS (Organizzazione Non Lucrativa di Utilità Sociale) or a similar
designation under Italian law.
+
+### Conclusion
+
+Navigating donation regulations in Europe involves adhering to EU directives
on transparency, AML, tax compliance, and data protection while also meeting
specific requirements in individual countries. Compliance ensures trust in the
philanthropic sector, promoting ethical giving practices and cross-border
donations within the EU’s regulatory landscape.
+
+---------------------------
+
diff --git a/doc/usenix-security-2025/paper/bibliography.bib
b/doc/usenix-security-2025/paper/bibliography.bib
new file mode 100644
index 0000000..687fafb
--- /dev/null
+++ b/doc/usenix-security-2025/paper/bibliography.bib
@@ -0,0 +1,123 @@
+@inproceedings{DBLP:conf/eurocrypt/FuchsbauerPS20,
+ author = {Georg Fuchsbauer and
+ Antoine Plouviez and
+ Yannick Seurin},
+ editor = {Anne Canteaut and
+ Yuval Ishai},
+ title = {Blind {Schnorr} Signatures and Signed {ElGamal}
Encryption in the Algebraic
+ Group Model},
+ booktitle = {Advances in Cryptology - {EUROCRYPT} 2020 - 39th Annual
International
+ Conference on the Theory and Applications of
Cryptographic Techniques,
+ Zagreb, Croatia, May 10-14, 2020, Proceedings, Part
{II}},
+ series = {Lecture Notes in Computer Science},
+ volume = {12106},
+ pages = {63--95},
+ publisher = {Springer},
+ year = {2020},
+ url = {https://doi.org/10.1007/978-3-030-45724-2\_3},
+ doi = {10.1007/978-3-030-45724-2\_3},
+ timestamp = {Mon, 04 May 2020 14:35:02 +0200},
+ biburl = {https://dblp.org/rec/conf/eurocrypt/FuchsbauerPS20.bib},
+ bibsource = {dblp computer science bibliography, https://dblp.org}
+}
+
+
+@online{qrcodedensowavewebsite,
+ author = "DENSO WAVE",
+ title = "Information capacity and versions of the {QR} Code",
+ howpublished = {\url{https://www.qrcode.com/en/about/version.html}},
+ addendum = "(accessed: 29.05.2024)",
+ keywords = "qrcode,DENSOWAVE"
+}
+@misc{cryptoeprint:2019/877,
+ author = {Georg Fuchsbauer and Antoine Plouviez and Yannick Seurin},
+ title = {Blind {Schnorr} Signatures and Signed {ElGamal} Encryption in
the Algebraic Group Model},
+ year = {2019},
+ howpublished = {\url{https://eprint.iacr.org/2019/877}}
+}
+
+@misc{Taler,
+ title = {{GNU Taler: Features}},
+ addendum = {accessed: 05.06.2024},
+ howpublished = {\url{https://taler.net/en/features.html}}
+}
+
+@book{nigelcrypto:2016,
+ language = {eng},
+ publisher = {Springer},
+ series = {Information security and cryptography},
+ title = {Cryptography made simple},
+ year = {2016},
+ author = {Smart, Nigel Paul},
+ keywords = {Cryptography},
+}
+
+@misc{DemHeuz2022,
+ author = {Gian Demarmels, Lucien Heuzeveld},
+ title = {Adding {Schnorr’s} Blind Signature in {Taler}},
+ year = {2022},
+ addendum = {accessed: 02.06.2024},
+ howpublished = {\url{https://taler.net/papers/cs-thesis.pdf}}
+}
+
+@inproceedings{BernsteinEd25519,
+ author = {Daniel J. Bernstein and
+ Niels Duif and
+ Tanja Lange and
+ Peter Schwabe and
+ Bo{-}Yin Yang},
+ editor = {Bart Preneel and
+ Tsuyoshi Takagi},
+ title = {High-Speed High-Security Signatures},
+ booktitle = {Cryptographic Hardware and Embedded Systems - {CHES}
2011 - 13th Internat
+ Workshop, Nara, Japan, September 28 - October 1, 2011.
Proceedings},
+ series = {Lecture Notes in Computer Science},
+ volume = {6917},
+ pages = {124--142},
+ publisher = {Springer},
+ year = {2011},
+ url = {https://doi.org/10.1007/978-3-642-23951-9\_9},
+ doi = {10.1007/978-3-642-23951-9\_9},
+ note = {\url{https://ed25519.cr.yp.to/ed25519-20110926.pdf}}
+}
+
+@article{hash2012,
+ author = {Sobti, Rajeev and Ganesan, Geetha},
+ year = {2012},
+ month = {03},
+ pages = {461 - 479},
+ title = {Cryptographic Hash Functions: A Review},
+ volume = {Vol 9},
+ journal = {International Journal of Computer Science Issues, ISSN
(Online): 1694-0814}
+}
+
+@online{hash-nist,
+ author = "NIST",
+ title = "Hash Functions",
+ howpublished =
{\url{https://csrc.nist.gov/projects/hash-functions#approved-algorithms}},
+ addendum = "(accessed: 06.06.2024)",
+ keywords = "hash,sha-512"
+}
+
+@misc{eulaw,
+ author={{The Parliament of Australia}},
+ title={CONSOLIDATED VERSION OF THE TREATY ON THE FUNCTIONING OF THE
{E}UROPEAN {U}NION},
+ year={2012},
+ howpublished =
{\url{https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:12012E/TXT}},
+}
+
+@misc{taler-sub,
+ author={{Christian Blättler}},
+ title={Privacy-preserving Subscriptions and Discounts},
+ year={2024},
+ howpublished =
{\url{https://taler.net/papers/subscription-discounts-thesis.pdf}},
+}
+
+@misc{taler-cs,
+ author={{Gian Demarmels, Lucien Heuzeveldt}},
+ title={Adding {Schnorr's} Blind Signature in {Taler}},
+ year={2022},
+ howpublished = {\url{https://taler.net/papers/cs-thesis.pdf}},
+}
+
+
diff --git a/doc/usenix-security-2025/paper/blue_wax.png
b/doc/usenix-security-2025/paper/blue_wax.png
new file mode 100644
index 0000000..8e737d7
Binary files /dev/null and b/doc/usenix-security-2025/paper/blue_wax.png differ
diff --git a/doc/usenix-security-2025/paper/charity.jpg
b/doc/usenix-security-2025/paper/charity.jpg
new file mode 100644
index 0000000..5bca2c5
Binary files /dev/null and b/doc/usenix-security-2025/paper/charity.jpg differ
diff --git a/doc/usenix-security-2025/paper/coins.png
b/doc/usenix-security-2025/paper/coins.png
new file mode 100644
index 0000000..dfff2c6
Binary files /dev/null and b/doc/usenix-security-2025/paper/coins.png differ
diff --git a/doc/usenix-security-2025/paper/db_physical_model.png
b/doc/usenix-security-2025/paper/db_physical_model.png
new file mode 100644
index 0000000..b71fb00
Binary files /dev/null and
b/doc/usenix-security-2025/paper/db_physical_model.png differ
diff --git a/doc/usenix-security-2025/paper/discussion.tex
b/doc/usenix-security-2025/paper/discussion.tex
new file mode 100644
index 0000000..efd5eb4
--- /dev/null
+++ b/doc/usenix-security-2025/paper/discussion.tex
@@ -0,0 +1,296 @@
+\section{Discussion}
+
+This chapter compares the Donau design with the requirements and desired
+optional features and discusses threat models.
+
+\subsection{Optional features and the Donau design}
\label{sec:discussionfeatures}
+
+Sections~\ref{technical} and \ref{implementation} presented a complete
+design and implementation of a donation system that achieves confidentiality of
+donations while permitting donors to prove how much they donated to registered
+charities.
+
+In this section we first show how the presented design and
+implementation could be made to fit the other features discussed in
+section~\ref{sec:optionalfeatures} and which ones it addresses already.
+
+
+
+\subsubsection{Feature: Provide fiscal statement}
+
+Both the individual donation receipts and the annual donation statement
+provided by Donau satisfy the requirement of providing a fiscal statement.
+In general, the annual donation statement is more user-friendly and more
+privacy-friendly as it only contains the total amount and is more compact.
+
+\subsubsection{Feature: Proof of registration}\label{discussion:registration}
+
+In the Donau protocol, the donor is identified using a unique donor
+identifier. The format of the identifier is not fixed by the protocol,
+and could easily be replaced by the (hash over) donor registration
+data. While in this case the charity and Donau cannot check the validity of the
+donor's registration due to blinding, the tax authority would be
+assured that only donors who properly registered prior to their donation get a
+donation receipt that is valid for them. This enforces registration for tax
+deductable donations.
+
+If the purpose of the registration is to limit charities to only accept money
+from registered donors additional components need to be added. The
+cryptographic concept of attribute-based credentials can be used to build a
+suitable functionality.
+When a donor registers, they are provided a credential to prove that they are
+registered. When donating to a
+charity, the donor uses their credential to sign their donation. The charity
checks
+that the signature is valid
+and is thus obtains proof that they are interacting with a registered donor as
+nobody else could make a valid signature. There are different approaches to
+attribute-based credentials and features differ between them. To keep the
+privacy guarantees of the Donau protocol and only add donor registration, the
+system should be unlinkable and anonymous.
+
+We acknowledge that this design does not provide a link between the donor
+identity $\DI$ used in the BKP and the donor registration as that is
+incompatible with the property of providing anonymity to the donor. A
registered
+donor with a valid credential may choose to submit BKPs that
+include invalid $\DI$s or somebody else's $\DI$. However, the design gives a
+proof to the charity that the payment they receive comes from a registered
+donor. See section~\ref{sec:discussion:threats} later for a discussion of
+threats.
+
+Given that only few countries require donor registration and we
+consider this a requirement that hampers charities, we chose not to include
+this feature in our design.
+
+
+
+\subsubsection{Feature: Configurable pledge}
+
+The Donau protocol is expected to be integrated with a payment process,
+such as the GNU Taler payment protocol. Here, the actual payment would
+sign over contract terms between the donor and the charity. The pledge
+can be easily integrated into these contract terms.
+
+\subsubsection{Feature: Cumulative donation counter from same donor to same
+cause}\label{discussion:limit}
+
+Limiting donations per donor is difficult when donations are supposed
+to be anonymous and adding this feature to the Donau protocol requires
+additional components.
+
+Donors could be issued some credentials, to be used in an attribute-based
+credential scheme which is anonymous but linkable. This could be set up
+to have one credential per charity and requiring a signature under a valid
+credential for each donation. This would mean that donations to the same
+charity by the same donor are linked, and the charity would be required to
check
+the signature and to keep all donations and signatures, in order to decline
further
+donation attempts by donors who have reached their limit.
+
+As a practical instantiation it is conceivable to combine the Donau
+protocol with an EID solution that provides some unlinkable
+pseudonym derived from the donor's main identity. The unlinkable
+pseudonym could be unique to the donor, charity and time period.
+By signing the donation process with such an unlinkable pseudonym
+it is possible to prevent smurfing donations, alas at the expense
+of reducing anonymity to pseudonymity.
+
+As discussed above in section~\ref{discussion:registration}, the signature on
+the donation does not guarantee that the $\DI$ hidden in the BKPs matches that
+of the signer.
+
+\subsubsection{Feature: Notarized affidavit}
+
+GNU Taler already supports privacy-preserving age-restrictions on
+payments, thus it would be trivial to prove that the donor is of
+legal age as part of the payment process (without disclosing any
+further information). In general, including other attestations may
+be possible, but is likely to be highly problematic from a privacy
+point of view. Not to mention that birthrates are commonly recorded
+and thus age can be easily attested by the payment service provider,
+other types of attestations would require building the corresponding
+certification infrastructure.
+
+
+\subsubsection{Feature: Unique ID for donor advised decisions}
+
+Issuing tokens to advise decisions would be part of the donation contract.
+The donation process could return such a token in addition to the donation
+receipt to enable the donor to vote, similar to the discount and subscription
+tokens already proposed for GNU Taler.
+
+An inherent feature of the Donau protocol is that the
+donor has the private keys of the coins used to make a donation,
+and thus inherently a feature that could be used to advise
+decisions.
+
+Limiting decisions to one per donor
+instead of proportional to the amount donated is more complex,
+as it would require a solution similarly to enforcing cumulative limits per
+donor as discussed in section~\ref{discussion:limit}.
+
+The main challenge in both scenarios would be to find a way to inform
+the anonymous donors when their input is solicited.
+
+\subsubsection{Feature: Compound weighted donation}
+
+In general, the simplest way to do a compound weighted donation
+would be to break up the donation into multiple donations at
+the time when the donation is made. Given GNU Taler's ability
+to handle micropayments, doing multiple smaller payments is
+generally not an issue. Alternatively, the payment system could
+be enhanced with escrow functionalities that would allow the
+donation to be split up according to a given set of weights
+which is only provided after the donation was made.
+
+\subsubsection{Feature: Cost transparency}
+
+Fees in the GNU Taler system are given as part of the protocol
+and always shown to the payer, ensuring cost transparency. The
+design does not require the use of additional parties beyond
+the payment system, donor and charity. If fundraising parties
+are involved as well, their cuts could be easily made transparent
+in the GNU Taler contract terms used in the donation payment.
+
+\subsubsection{Feature: Staged donation}\label{discussion:staged}
+
+Staged donations would require the payment service to hold funds in
+escrow until certain conditions are met (or refund them). GNU Taler
+can already do refunds, and escrow of funds is a feature planned for
+the future.
+%TL: that is always a problem and not changed by using our solution.
+% One difficulty would be to establish an authority
+% that decides whether the conditions are met.
+
+The blinded donation receipts could similarly be held in escrow, released only
+when the next stage of funding is reached and the donation is released. A
+problem, however, is that the donor is anonymous and thus cannot be reached
+at the time that later goals are met.
+
+A solution is for the charity to further blind or encrypt the Donau signatures
+and to publicly post the keys when the next stage of funding is reached and the
+donation becomes effective. In the following we assume that the donation is
+split up by funding stage and that the donor submitted an array of BKPs per
+funding stage, so
+$\vec{\mu_j} = (\bar{\mu}_{j1}, \bar{\mu}_{j2}, \ldots)$ is the array of BKPs
for
+funding stage $j$.
+To make the multitude of keys manageable, the charity uses a random string
+$t_j$ per funding stage and {\em encrypts} the Donau response
+$(\beta_{j1}, \beta_{j2}, \ldots)$ for the stage $j$ payments
+with $H(t_j, \vec{\mu_j})$. The encrypted Donau responses (one per stage) are
+returned to the donor at the time of donation instead of the plaintext Donau
+response.
+
+When work progresses to reach
+stage $j$ and the donation payments are collected, the charity posts $t_j$
+publicly. Every donor can then compute the key $H(t_j, \vec{\mu_j})$ and
decrypt
+their donation receipts for stage $j$. This requires the donor to store the
BKPs along with
+the encrypted donation receipts until stage $j$ is reached and $t_j$ is
+released. It requires the charity to have a bulletin board for posting $t_j$
+but charities soliciting staged donations typically post extensive progress
+reports justifying them declaring success on the previous stage and this report
+should then link to the key $t_j$.
+
+\subsubsection{Feature: Bandwidth donations}
+
+If the donated amount is to shrink based on certain conditions the design
+discussed in section~\ref{discussion:staged} can be adopted. Here is a simple
+example where the final contribution of each donor is proportional to their
+maximum pledge: Each
+donation is composed of some fixed number $N$ of equal shares. During the
+period that the charity is soliciting funding all donations are held in
escrow.
+Donors receive $N$ encrypted Donau responses (one per share). Once the funding
+period ends, the total sum of pledges is known. Let the fraction $a/N$ of the
+total suffice for the funding goal of the charity. The charity then posts the
+first $a$ keys $t_j$, unlocking the Donau responses for the effectively
+donated part, and receives the share of $a/N$ of the pledged donations from
+escrow. The remaining $(N-a)/N$ shares of the donations are returned to the
+donors, e.g., by voiding the contracts that spent them.
+
+\subsubsection{Feature: Code of conduct}
+
+A code of conduct could easily be integrated into the contract
+terms for of the payment process.
+
+\subsubsection{Feature: Restricted access mechanism}
+
+The envisioned discount token and subscription extensions of the
+GNU Taler protocol could be used to return to the donor a token that
+would grant them access to additional information.
+
+\subsubsection{Feature: Unlock thank you artwork}
+
+The GNU Taler protocol can already be used to buy digital goods.
+While we are usually thinking about newspaper articles or videos,
+this can of course also include images or audio resources. Thus,
+this can easily be done by using the payment process to authorize
+bypassing what in a commercial setting would be called a paywall.
+
+Sending physical gifts requires having an address of the donor and thus is not
+compatible with the anonymity feature. However, there is nothing in the design
+that stops the charity and donor from exchanging address information during the
+donation process.
+
+\subsubsection{Feature: Donation matching with a reference}
+
+Donation matching is an agreement between the charity and a matching donor.
+The charity can show proof of the payments received; if these are done using
+GNU Taler then the charity can show the deposit confirmations issued
+by the GNU Taler exchange to the charity. This way, the
+charity can prove to the match funder that they received a
+certain amount of donations, and they can even include the
+contract terms to show that the donors intended to participate
+in the match funding project.
+This requires that the match funder is not active in the considered donation
+period or that they subtract their own donations from the total.
+
+Both donor and match funder can in principle share their
+donation receipts publicly to advertise their good deed, but they then of
course
+void their anonymity.
+
+\subsubsection{Feature: Anonymous donation matching by employer}
+
+Technical solutions can be similar to what is discussed in
+section~\ref{discussion:registration}.
+
+A simple solution if the match funder is a company with a taxpayer ID known to
+their employees and the match funder knows the donors' taxpayer IDs (as is
+common in an employment scenario) is to use that donations in the Donau system
+do not prove that the donation is made by the taxpayer with {\tt TAXID} as
+follows: The donor donates
+the full amount (their contribution as well as the match
+funding) to the charities of their choice, where they include their own $\DI$
in
+half of the amount and one derived from the {\tt TAXID} of their employer in
+the other half. Then they show the donation receipts for both halves to the
match
+funder. The match funder can verify validity of both receipts and that the
+proportion of their match is correct. They then refund the amount that was
donated
+on their behalf to the employee and use the donation receipt for their {\tt
+TAXID} when filing their tax statement.
+
+\subsection{Threats}\label{sec:discussion:threats}
+
+The presented protocol is using similar cryptographic constructions
+as the GNU Taler payment system itself, primarily blind signatures
+and regular signatures. However, it does not use the ``refresh''
+protocol of GNU Taler, as there is no need to render change.
+As a result, the Donau protocol suffers from a subset of
+the threats from quantum computing detailed in deliverable D5.3
~\cite{pqtaler2024}
+on the impact of quantum computers on GNU Taler.
+
+A new Donau-specific threat is that donations could be used for
+laundering criminal assets. This does not mean that we expect
+charities themselves to play foul, but tax benefits that could be
+transferred to someone else would indirectly represent actual value
+(even commercially tradeable): donations from someone paying lower tax
+rates could be used to artificially lower the income of a person
+paying a higher rate. The money going to the charity would essentially
+be used to trigger a laundered partial payout in the legitimate world.
+The Donau protocol does not prove that the donor identification $\DI$ used in
+the $\UDI$s inside the BKPs is that of the actual donor, as that is
+incompatible with the anonymity and confidentiality guarantees of the system.
+In practice, we expect this threat to be largely theoretical:
+the hypothetical money launderer would need to take a significant
+loss (depending on the tax rate, but generally probably more than
+half, given that common effective tax rates are rarely above 50\%).
+Thus, the costs of laundering money with this method would most
+likely substantially exceed the cost of other methods to launder
+criminal assets.
+
diff --git a/doc/usenix-security-2025/paper/donau-paper.bib
b/doc/usenix-security-2025/paper/donau-paper.bib
new file mode 100644
index 0000000..7acf540
--- /dev/null
+++ b/doc/usenix-security-2025/paper/donau-paper.bib
@@ -0,0 +1,70 @@
+
+
+@TechReport{pqtaler2024,
+ author = {Tanja Lange and Jonathan Levin},
+ title = {Impact of Quantum Computers on {GNU Taler}},
+ institution = {NGI TALER},
+ year = {2024},
+ month = {December},
+}
+
+@misc{donau,
+ author = {Johannes Casaburi, Lukas Matyja},
+ title = {{Donau: Donation Authority. Tax-deductible
Privacy-Preserving Donations}},
+ howpublished = {Bachelor Thesis},
+ year = {2024},
+ doi = {},
+ note = {\url{https://taler.net/papers/donau-thesis.pdf}},
+ url = {https://taler.net/papers/donau-thesis.pdf}
+}
+@article{DBLP:journals/jce/BernsteinDLSY12,
+ author = {Daniel J. Bernstein and
+ Niels Duif and
+ Tanja Lange and
+ Peter Schwabe and
+ Bo{-}Yin Yang},
+ title = {High-speed high-security signatures},
+ journal = {J. Cryptogr. Eng.},
+ volume = {2},
+ number = {2},
+ pages = {77--89},
+ year = {2012},
+ url = {https://doi.org/10.1007/s13389-012-0027-1},
+ doi = {10.1007/S13389-012-0027-1},
+ timestamp = {Thu, 09 Jul 2020 23:00:32 +0200},
+ biburl = {https://dblp.org/rec/journals/jce/BernsteinDLSY12.bib},
+ bibsource = {dblp computer science bibliography, https://dblp.org}
+}
+@inproceedings{DBLP:conf/crypto/Chaum82,
+ author = {David Chaum},
+ editor = {David Chaum and
+ Ronald L. Rivest and
+ Alan T. Sherman},
+ title = {Blind Signatures for Untraceable Payments},
+ booktitle = {Advances in Cryptology: Proceedings of {CRYPTO} '82, Santa
Barbara,
+ California, USA, August 23-25, 1982},
+ pages = {199--203},
+ publisher = {Plenum Press, New York},
+ year = {1982},
+ url = {https://doi.org/10.1007/978-1-4757-0602-4\_18},
+ doi = {10.1007/978-1-4757-0602-4\_18},
+ timestamp = {Mon, 29 Jul 2019 16:00:10 +0200},
+ biburl = {https://dblp.org/rec/conf/crypto/Chaum82.bib},
+ bibsource = {dblp computer science bibliography, https://dblp.org}
+}
+@article{DBLP:journals/cacm/RivestSA78,
+ author = {Ronald L. Rivest and
+ Adi Shamir and
+ Leonard M. Adleman},
+ title = {A Method for Obtaining Digital Signatures and Public-Key
Cryptosystems},
+ journal = {Commun. {ACM}},
+ volume = {21},
+ number = {2},
+ pages = {120--126},
+ year = {1978},
+ url = {https://doi.org/10.1145/359340.359342},
+ doi = {10.1145/359340.359342},
+ timestamp = {Fri, 24 Mar 2023 16:31:07 +0100},
+ biburl = {https://dblp.org/rec/journals/cacm/RivestSA78.bib},
+ bibsource = {dblp computer science bibliography, https://dblp.org}
+}
\ No newline at end of file
diff --git a/doc/usenix-security-2025/paper/donau-paper.pdf
b/doc/usenix-security-2025/paper/donau-paper.pdf
new file mode 100644
index 0000000..68e656e
Binary files /dev/null and b/doc/usenix-security-2025/paper/donau-paper.pdf
differ
diff --git a/doc/usenix-security-2025/paper/donau-paper.tex
b/doc/usenix-security-2025/paper/donau-paper.tex
new file mode 100644
index 0000000..e1717e8
--- /dev/null
+++ b/doc/usenix-security-2025/paper/donau-paper.tex
@@ -0,0 +1,85 @@
+%\documentclass{taler} % full lenth boiler plate
+%\documentclass{taler-short} % for short deliverables with less boiler plate
+\documentclass[letterpaper,twocolumn,10pt]{article}
+\usepackage{usenix-2020-09}
+
+\usepackage{xcolor}
+\usepackage{amsmath}
+%\definecolor{linkcolor}{rgb}{0.65,0,0}
+%\definecolor{citecolor}{rgb}{0,0.4,0}
+%\definecolor{urlcolor}{rgb}{0,0,0.65}
+%\usepackage[colorlinks=true, linkcolor=linkcolor, urlcolor=urlcolor,
citecolor=citecolor]{hyperref}
+
+\usepackage{listings}
+\usepackage{graphicx}
+\begin{document}
+%\doccode{D3.4}
+%\wpcontrib{WP3}
+%don't want date printed
+\date{}
+\title{\Large \bf Design for Donations}
+%\duedate{30 November 2024}
+%\actualdate{\today}
+%\version{Revision 1.0}
+%\dissemination{PU}
+
+% \author{Bob Goudriaan, Christian Grothoff, Tanja Lange, Michiel
+% Leenaars, Jonathan Levin}
+
+\author{
+{\rm Bob Goudriaan}\\
+NLnet Foundation
+\and
+{\rm Chrsitian Grothoff}\\
+Bern University of Applied Sciences
+\and
+{\rm Tanja Lange}\\
+Technical University of Eindhoven
+\and
+{\rm Michiel Leenaars}\\
+NLnet Foundation
+\and
+{\rm Jonathan Levin}\\
+XXXXX
+% copy the following lines to add more authors
+% \and
+% {\rm Name}\\
+%Name Institution
+} % end author
+
+
+%\changetable{ % use 3 colum format as in these examples
+%0.1 & 31 July 2024& Donau design completed and implemented\\\hline %XXX
Change when finished with draft
+%0.2 & 29 November 2024& Complete version with requirements and
capabilities\\\hline %XXX Change when finished with draft
+%1.0 & 30 November 2024 & Minor edits following intnernal review\\\hline
+% }
+\input{ethic}
+\clearpage
+
+\maketitle
+
+\begin{abstract}
+ This report provides an overview of functional requirements for
+ privacy-preserving donations, keeping in mind the need for tax authorities to
+ verify the proper source of donations prior to granting tax benefits. As a
+ second contribution it provides a technical design to realize
+ privacy-preserving and yet tax-deductable donations in GNU Taler, for which
+ it presents the protocol specification and implementation details for the
+ Donation Authority (Donau).
+\end{abstract}
+
+%\reportkeywords{GNU Taler, Tax-deductible Donations. Donau, Donation
Authority,
+%Privacy-Preserving Payments}
+
+
+
+\input{intro}
+\input{requirements} % Michiel's part can go in this file
+\input{technicaldesign}
+\input{implementation}
+\input{discussion}
+
+\bibliographystyle{plain}
+\bibliography{donau-paper,bibliography}
+
+\end{document}
diff --git a/doc/usenix-security-2025/paper/donau.png
b/doc/usenix-security-2025/paper/donau.png
new file mode 100644
index 0000000..4288686
Binary files /dev/null and b/doc/usenix-security-2025/paper/donau.png differ
diff --git a/doc/usenix-security-2025/paper/donau_flow_issue_receipt.png
b/doc/usenix-security-2025/paper/donau_flow_issue_receipt.png
new file mode 100644
index 0000000..ede4d31
Binary files /dev/null and
b/doc/usenix-security-2025/paper/donau_flow_issue_receipt.png differ
diff --git a/doc/usenix-security-2025/paper/donau_flow_register_charity.png
b/doc/usenix-security-2025/paper/donau_flow_register_charity.png
new file mode 100644
index 0000000..1308114
Binary files /dev/null and
b/doc/usenix-security-2025/paper/donau_flow_register_charity.png differ
diff --git a/doc/usenix-security-2025/paper/donau_flow_submit_receipt.png
b/doc/usenix-security-2025/paper/donau_flow_submit_receipt.png
new file mode 100644
index 0000000..a337e76
Binary files /dev/null and
b/doc/usenix-security-2025/paper/donau_flow_submit_receipt.png differ
diff --git a/doc/usenix-security-2025/paper/donau_system_arch.png
b/doc/usenix-security-2025/paper/donau_system_arch.png
new file mode 100644
index 0000000..9421dc1
Binary files /dev/null and
b/doc/usenix-security-2025/paper/donau_system_arch.png differ
diff --git a/doc/usenix-security-2025/paper/ethic.tex
b/doc/usenix-security-2025/paper/ethic.tex
new file mode 100644
index 0000000..c4e2f90
--- /dev/null
+++ b/doc/usenix-security-2025/paper/ethic.tex
@@ -0,0 +1,7 @@
+\section*{Ethics considerations and compliance with the open science policy}
+
+This project is a free and open source software project. The program presented
in this project is available under GNU V3.0 license in the repository
git.taler.net/donau.git . Reviewers, and later readers, will be able to
download, compile and install the software as they wish.
+
+Ethical considerations were at the root of this project. Current systems
oblige people making donations to charities to reveal to the tax authorities
the donations made and the institutions supported. This encroaches on the
private sphere of some people, who do not wish it to be known who they support.
Support for certain organizations can lead to stigmatization of the donor.
+
+The aim of this project is to offer greater protection of privacy, leading to
greater tax justice. Indeed, some people prefer not to claim the tax reduction
to which they are entitled in order to protect their privacy.
diff --git a/doc/usenix-security-2025/paper/gold_wax.png
b/doc/usenix-security-2025/paper/gold_wax.png
new file mode 100644
index 0000000..5c3441f
Binary files /dev/null and b/doc/usenix-security-2025/paper/gold_wax.png differ
diff --git a/doc/usenix-security-2025/paper/golden_stamp.jpg
b/doc/usenix-security-2025/paper/golden_stamp.jpg
new file mode 100644
index 0000000..51ae62b
Binary files /dev/null and b/doc/usenix-security-2025/paper/golden_stamp.jpg
differ
diff --git a/doc/usenix-security-2025/paper/green_wax.png
b/doc/usenix-security-2025/paper/green_wax.png
new file mode 100644
index 0000000..592292d
Binary files /dev/null and b/doc/usenix-security-2025/paper/green_wax.png differ
diff --git a/doc/usenix-security-2025/paper/images/TalerDiagram.svg
b/doc/usenix-security-2025/paper/images/TalerDiagram.svg
new file mode 100644
index 0000000..c28d430
--- /dev/null
+++ b/doc/usenix-security-2025/paper/images/TalerDiagram.svg
@@ -0,0 +1,361 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+
+<svg
+ width="297mm"
+ height="210mm"
+ viewBox="0 0 297 210"
+ version="1.1"
+ id="svg13075"
+ xml:space="preserve"
+ inkscape:version="1.2.2 (b0a8486541, 2022-12-01)"
+ sodipodi:docname="TalerDiagram2p1.svg"
+ inkscape:export-filename="TalerDiagram2.png"
+ inkscape:export-xdpi="96"
+ inkscape:export-ydpi="96"
+ xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+ xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+ xmlns="http://www.w3.org/2000/svg"
+ xmlns:svg="http://www.w3.org/2000/svg"><sodipodi:namedview
+ id="namedview13077"
+ pagecolor="#ffffff"
+ bordercolor="#000000"
+ borderopacity="0.25"
+ inkscape:showpageshadow="2"
+ inkscape:pageopacity="0.0"
+ inkscape:pagecheckerboard="0"
+ inkscape:deskcolor="#d1d1d1"
+ inkscape:document-units="mm"
+ showgrid="false"
+ inkscape:zoom="1.279"
+ inkscape:cx="137.60751"
+ inkscape:cy="-19.546521"
+ inkscape:window-width="1366"
+ inkscape:window-height="717"
+ inkscape:window-x="0"
+ inkscape:window-y="27"
+ inkscape:window-maximized="1"
+ inkscape:current-layer="layer1"
+ showguides="true"><inkscape:grid
+ type="xygrid"
+ id="grid30279" /><sodipodi:guide
+ position="149.97883,79.673571"
+ orientation="1,0"
+ id="guide9513"
+ inkscape:locked="false" /></sodipodi:namedview><defs
+ id="defs13072"><rect
+ x="474.55942"
+ y="597.35254"
+ width="381.69031"
+ height="31.333269"
+ id="rect7060" /><rect
+ x="469.39636"
+ y="595.17432"
+ width="237.5827"
+ height="40.265274"
+ id="rect7024" /><rect
+ x="480.44522"
+ y="587.41803"
+ width="188.95509"
+ height="44.193748"
+ id="rect6988" /><marker
+ style="overflow:visible"
+ id="TriangleStart"
+ refX="0"
+ refY="0"
+ orient="auto-start-reverse"
+ inkscape:stockid="TriangleStart"
+ markerWidth="1.324"
+ markerHeight="1.5306358"
+ viewBox="0 0 5.3244081 6.1553851"
+ inkscape:isstock="true"
+ inkscape:collect="always"
+ preserveAspectRatio="xMidYMid"
+ markerUnits="strokeWidth"><path
+ transform="scale(0.5)"
+
style="fill:context-stroke;fill-rule:evenodd;stroke:context-stroke;stroke-width:1pt"
+ d="M 5.77,0 -2.88,5 V -5 Z"
+ id="path135" /></marker><marker
+ style="overflow:visible"
+ id="TriangleStart-1"
+ refX="0"
+ refY="0"
+ orient="auto-start-reverse"
+ inkscape:stockid="TriangleStart"
+ markerWidth="1.324"
+ markerHeight="1.5306358"
+ viewBox="0 0 5.3244081 6.1553851"
+ inkscape:isstock="true"
+ inkscape:collect="always"
+ preserveAspectRatio="xMidYMid"
+ markerUnits="strokeWidth"><path
+ transform="scale(0.5)"
+
style="fill:context-stroke;fill-rule:evenodd;stroke:context-stroke;stroke-width:1pt"
+ d="M 5.77,0 -2.88,5 V -5 Z"
+ id="path135-8" /></marker><marker
+ style="overflow:visible"
+ id="TriangleStart-3-7"
+ refX="0"
+ refY="0"
+ orient="auto-start-reverse"
+ inkscape:stockid="TriangleStart"
+ markerWidth="1.324"
+ markerHeight="1.5306358"
+ viewBox="0 0 5.3244081 6.1553851"
+ inkscape:isstock="true"
+ inkscape:collect="always"
+ preserveAspectRatio="xMidYMid"
+ markerUnits="strokeWidth"><path
+ transform="scale(0.5)"
+
style="fill:context-stroke;fill-rule:evenodd;stroke:context-stroke;stroke-width:1pt"
+ d="M 5.77,0 -2.88,5 V -5 Z"
+ id="path135-7-8" /></marker><marker
+ style="overflow:visible"
+ id="TriangleStart-36"
+ refX="0"
+ refY="0"
+ orient="auto-start-reverse"
+ inkscape:stockid="TriangleStart"
+ markerWidth="1.324"
+ markerHeight="1.5306358"
+ viewBox="0 0 5.3244081 6.1553851"
+ inkscape:isstock="true"
+ inkscape:collect="always"
+ preserveAspectRatio="xMidYMid"
+ markerUnits="strokeWidth"><path
+ transform="scale(0.5)"
+
style="fill:context-stroke;fill-rule:evenodd;stroke:context-stroke;stroke-width:1pt"
+ d="M 5.77,0 -2.88,5 V -5 Z"
+ id="path135-1" /></marker><marker
+ style="overflow:visible"
+ id="TriangleStart-3-5"
+ refX="0"
+ refY="0"
+ orient="auto-start-reverse"
+ inkscape:stockid="TriangleStart"
+ markerWidth="1.324"
+ markerHeight="1.5306358"
+ viewBox="0 0 5.3244081 6.1553851"
+ inkscape:isstock="true"
+ inkscape:collect="always"
+ preserveAspectRatio="xMidYMid"
+ markerUnits="strokeWidth"><path
+ transform="scale(0.5)"
+
style="fill:context-stroke;fill-rule:evenodd;stroke:context-stroke;stroke-width:1pt"
+ d="M 5.77,0 -2.88,5 V -5 Z"
+ id="path135-7-5" /></marker><rect
+ x="287.7149"
+ y="727.8783"
+ width="825.97021"
+ height="85.463478"
+ id="rect26485" /></defs><g
+ inkscape:label="Calque 1"
+ inkscape:groupmode="layer"
+ id="layer1"><g
+ style="fill:none"
+ id="g372"
+ transform="matrix(1.7297433,0,0,1.6435026,11.074573,60.992125)"><path
+ d="m 3,24.0001 h 18 m -17,-3 h 16 m -14,0 v -8 m 4,8 v -8 m 4,8 v -8
m 4,8 v -8 m 3,-3 -6.874,-6.11024 C 13.3737,3.2212 12.9976,2.88688
12.5732,2.75991 c -0.374,-0.11185 -0.7724,-0.11185 -1.1464,0 C 11.0024,2.88688
10.6263,3.2212 9.87404,3.88986 L 3,10.0001 Z"
+ stroke="#000000"
+ stroke-width="2"
+ stroke-linecap="round"
+ stroke-linejoin="round"
+ id="path363"
+ sodipodi:nodetypes="ccccccccccccccccccc" /></g><path
+ d="m 250.19258,100.43636 h 31.13538 m -29.40564,-4.930515 h 27.6759 m
-24.21641,0 v -13.14802 m 6.91897,13.14802 v -13.14802 m 6.91898,13.14802 v
-13.14802 m 6.91897,13.14802 v -13.14802 m 5.18923,-4.93051 -11.89026,-10.04219
c -1.30128,-1.09895 -1.95184,-1.64841 -2.68594,-1.85708 -0.64693,-0.18383
-1.33606,-0.18383 -1.98298,0 -0.7341,0.20867 -1.38466,0.75813 -2.68588,1.85708
l -11.89032,10.04219 z"
+ stroke="#000000"
+ stroke-width="3.37214"
+ stroke-linecap="round"
+ stroke-linejoin="round"
+ id="path363-3"
+ sodipodi:nodetypes="ccccccccccccccccccc"
+ style="fill:none" /><path
+ d="m 229.97559,30.596955 -3.9747,-2.929208 -4.00233,2.924602 a
0.21876947,0.21876947 0 0 1 -0.34543,-0.177318 v -5.093875 a
0.21646667,0.21646667 0 0 1 0.28325,-0.207256 l 0.80139,0.467476 c
0.0921,0.02763 0.1612,0.112838 0.1612,0.209558 v 2.717348 l 2.97756,-2.242963 a
0.22107231,0.22107231 0 0 1 0.25792,0 l 2.98448,2.15085 -0.0553,-2.625235 c
0,-0.09211 0.0599,-0.175015 0.14738,-0.207255 l 0.81981,-0.490505 a
0.21876947,0.21876947 0 0 1 0.29016,0.207256 v 5.119207 c 0,0.0829 -0. [...]
+ fill="#000000"
+ id="path385"
+ style="fill:#808080;stroke:#808080;stroke-width:0.0314841" /><text
+ xml:space="preserve"
+
style="font-size:5.5097px;line-height:0.75;font-family:Blacksword;-inkscape-font-specification:Blacksword;text-align:center;text-decoration:none;text-decoration-line:none;text-decoration-color:#000000;letter-spacing:-0.128978px;word-spacing:0px;text-anchor:middle;fill:#808080;stroke:#808080;stroke-width:0.124709;stroke-dasharray:none;stroke-opacity:1;paint-order:stroke
fill markers;stop-color:#000000"
+ x="215.64868"
+ y="36.320969"
+ id="text719-3-5-6-2"><tspan
+ sodipodi:role="line"
+ id="tspan717-6-3-2-7"
+
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-family:Helvetica;-inkscape-font-specification:Helvetica;fill:#808080;stroke:#808080;stroke-width:0.124709;stroke-dasharray:none;stroke-opacity:1"
+ x="215.5842"
+ y="36.320969">AUDITOR</tspan></text><circle
+
style="fill:#0042b3;fill-opacity:1;stroke:none;stroke-width:0.0984245;stroke-dasharray:none;stroke-opacity:1;paint-order:stroke
fill markers;stop-color:#000000"
+ id="path1389-7"
+ cx="66.248222"
+ cy="166.47389"
+ r="17.65719" /><path
+ class="st0"
+ d="m 75.71284,172.12266 c -0.886258,-1.57542 -2.337791,-3.35983
-4.70091,-4.37423 -1.351531,0.94553 -2.993425,1.50224 -4.763459,1.50224
-1.771017,0 -3.412911,-0.55666 -4.764489,-1.50224 -2.363072,1.0144
-3.814653,2.79885 -4.700395,4.37423 -1.175544,2.08957 -0.253892,5.04618
1.779163,5.04618 2.033102,0 7.685768,0 7.685768,0 0,0 5.652104,0 7.685252,0
2.033009,0 2.95466,-2.95661 1.77907,-5.04618 z"
+ id="path396"
+ style="fill:#ffffff;stroke-width:0.0468176" /><g
+ id="g9511"><path
+ class="st0"
+ d="m 66.248471,167.27352 c 3.471245,0 6.284376,-2.81412
6.284376,-6.28488 v -1.50557 c 0,-3.47074 -2.813131,-6.28485 -6.284376,-6.28485
-3.471761,0 -6.285359,2.81411 -6.285359,6.28489 v 1.50556 c 0,3.47073
2.813645,6.28485 6.285359,6.28485 z"
+ id="path398"
+ style="fill:#ffffff;stroke-width:0.0468176" /></g><circle
+
style="fill:#0042b3;fill-opacity:1;stroke:none;stroke-width:0.0984245;stroke-dasharray:none;stroke-opacity:1;paint-order:stroke
fill markers;stop-color:#000000"
+ id="path1389-7-5"
+ cx="233.67947"
+ cy="166.47389"
+ r="17.65719" /><path
+ d="m 226.32112,156.07244 a 1.462894,1.462894 0 0 1 1.11179,-0.51202 h
12.49312 a 1.462894,1.462894 0 0 1 1.1118,0.51202 l 3.81669,4.45305 a
2.194341,2.194341 0 0 1 0.5281,1.42778 v 0.37304 a 3.4743732,3.4743732 0 0 1
-6.2173,2.1329 3.4685217,3.4685217 0 0 1 -2.74292,1.34147 3.4670588,3.4670588 0
0 1 -2.74293,-1.34147 3.4670588,3.4670588 0 0 1 -2.74292,1.34147
3.4670588,3.4670588 0 0 1 -2.74293,-1.34147 3.4743732,3.4743732 0 0 1
-6.2173,-2.1329 v -0.37304 a 2.194341,2.194341 0 0 1 [...]
+ id="path374"
+ style="fill:#ffffff;stroke-width:1.46289" /><path
+
style="font-variation-settings:normal;vector-effect:none;fill:none;fill-opacity:1;stroke:#000000;stroke-width:8.92;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4.1;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;-inkscape-stroke:none;marker-end:url(#TriangleStart);stop-color:#000000"
+ d="M 53.893229,83.595815 H 117.59002"
+ id="path5211" /><path
+
style="fill:none;stroke:#000000;stroke-width:8.92;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4.1;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#TriangleStart-1)"
+ d="m 171.50266,83.595815 h 65.77087"
+ id="path5211-7" /><text
+ xml:space="preserve"
+
style="font-size:5.1965px;line-height:0.75;font-family:Blacksword;-inkscape-font-specification:Blacksword;text-align:center;text-decoration:none;text-decoration-line:none;text-decoration-color:#000000;letter-spacing:-0.121647px;word-spacing:0px;text-anchor:middle;fill:#ffffff;stroke:#ffffff;stroke-width:0.117619;stroke-dasharray:none;stroke-opacity:1;paint-order:stroke
fill markers;stop-color:#000000"
+ x="85.076645"
+ y="85.522163"
+ id="text719-3-5-6-9-9"><tspan
+ sodipodi:role="line"
+ id="tspan717-6-3-2-1-2"
+
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-family:Helvetica;-inkscape-font-specification:Helvetica;fill:#ffffff;stroke:#ffffff;stroke-width:0.117619;stroke-dasharray:none;stroke-opacity:1"
+ x="85.015823"
+ y="85.522163">WIRE MONEY</tspan></text><text
+ xml:space="preserve"
+
style="font-size:4.20348px;line-height:0.75;font-family:Blacksword;-inkscape-font-specification:Blacksword;text-align:center;text-decoration:none;text-decoration-line:none;text-decoration-color:#000000;letter-spacing:-0.098401px;word-spacing:0px;text-anchor:middle;fill:#000000;stroke:#ffffff;stroke-width:0.117619;stroke-dasharray:none;stroke-opacity:1;paint-order:stroke
fill markers;stop-color:#000000"
+ x="31.646997"
+ y="107.75956"
+ id="text719-3-5-6-9-9-2"
+ transform="scale(1.0031623,0.99684766)"><tspan
+ sodipodi:role="line"
+ id="tspan717-6-3-2-1-2-0"
+
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-family:Helvetica;-inkscape-font-specification:Helvetica;fill:#000000;stroke:#ffffff;stroke-width:0.117619;stroke-dasharray:none;stroke-opacity:1"
+ x="31.597797"
+ y="107.75956">CUSTOMER BANK</tspan></text><text
+ xml:space="preserve"
+
style="font-size:4.20348px;line-height:0.75;font-family:Blacksword;-inkscape-font-specification:Blacksword;text-align:center;text-decoration:none;text-decoration-line:none;text-decoration-color:#000000;letter-spacing:-0.098401px;word-spacing:0px;text-anchor:middle;fill:#000000;stroke:#ffffff;stroke-width:0.117619;stroke-dasharray:none;stroke-opacity:1;paint-order:stroke
fill markers;stop-color:#000000"
+ x="264.77576"
+ y="107.62406"
+ id="text719-3-5-6-9-9-2-6"
+ transform="scale(1.0031623,0.99684766)"><tspan
+ sodipodi:role="line"
+ id="tspan717-6-3-2-1-2-0-1"
+
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-family:Helvetica;-inkscape-font-specification:Helvetica;fill:#000000;stroke:#ffffff;stroke-width:0.117619;stroke-dasharray:none;stroke-opacity:1"
+ x="264.72656"
+ y="107.62406">MERCHANT BANK</tspan></text><path
+
style="font-variation-settings:normal;vector-effect:none;fill:#000000;fill-opacity:0;stroke:#0042b3;stroke-width:8.91999;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4.1;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;-inkscape-stroke:none;marker-end:url(#TriangleStart-36);stop-color:#000000"
+ d="M 88.55281,166.47374 H 203.82873"
+ id="path5211-0" /><path
+
style="font-variation-settings:normal;fill:#ffffff;fill-opacity:0;stroke:#ffffff;stroke-width:9.32;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4.1;stroke-dasharray:1.86401,
1.86401;stroke-dashoffset:0;stroke-opacity:1;stop-color:#000000"
+ d="m 185.36927,166.6042 h 12.99924"
+ id="path5211-0-6" /><path
+
style="font-variation-settings:normal;fill:#ffffff;fill-opacity:0;stroke:#ffffff;stroke-width:9.32;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4.1;stroke-dasharray:1.86401,
1.86401;stroke-dashoffset:0;stroke-opacity:1;stop-color:#000000"
+ d="M 90.648379,166.6042 H 103.64762"
+ id="path5211-0-6-9" /><text
+ xml:space="preserve"
+
style="font-size:5.1965px;line-height:0.75;font-family:Blacksword;-inkscape-font-specification:Blacksword;text-align:center;text-decoration:none;text-decoration-line:none;text-decoration-color:#000000;letter-spacing:-0.121647px;word-spacing:0px;text-anchor:middle;fill:#ffffff;stroke:#ffffff;stroke-width:0.117619;stroke-dasharray:none;stroke-opacity:1;paint-order:stroke
fill markers;stop-color:#000000"
+ x="143.86769"
+ y="168.40016"
+ id="text719-3-5-6-9-9-6"><tspan
+ sodipodi:role="line"
+ id="tspan717-6-3-2-1-2-3"
+
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-family:Helvetica;-inkscape-font-specification:Helvetica;fill:#ffffff;stroke:#ffffff;stroke-width:0.117619;stroke-dasharray:none;stroke-opacity:1"
+ x="143.80687"
+ y="168.40016">PAY ANONYMOUSLY</tspan></text><path
+
style="font-variation-settings:normal;vector-effect:none;fill:#000000;fill-opacity:0;stroke:#0042b3;stroke-width:8.92;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4.1;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;-inkscape-stroke:none;marker-start:url(#TriangleStart);stop-color:#000000"
+ d="M 85.287358,146.16742 131.40776,100.04706"
+ id="path5211-5" /><path
+
style="font-variation-settings:normal;fill:#808080;fill-opacity:1;stroke:#808080;stroke-width:4;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4.1;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;marker-end:url(#TriangleStart-3-5);stop-color:#000000"
+ d="M 196.92451,36.303452 169.81092,63.417035"
+ id="path5211-5-47" /><path
+
style="font-variation-settings:normal;vector-effect:none;fill:#000000;fill-opacity:0;stroke:#0042b3;stroke-width:8.92;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4.1;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;-inkscape-stroke:none;marker-end:url(#TriangleStart-3-7);stop-color:#000000"
+ d="M 217.82977,150.34275 171.71984,104.23284"
+ id="path5211-5-4" /><text
+ xml:space="preserve"
+
style="font-size:5.1965px;line-height:0.75;font-family:Blacksword;-inkscape-font-specification:Blacksword;text-align:center;text-decoration:none;text-decoration-line:none;text-decoration-color:#000000;letter-spacing:-0.121647px;word-spacing:0px;text-anchor:middle;fill:#ffffff;stroke:#ffffff;stroke-width:0.117619;stroke-dasharray:none;stroke-opacity:1;paint-order:stroke
fill markers;stop-color:#000000"
+ x="-9.5148182"
+ y="165.21541"
+ id="text719-3-5-6-9-9-9"
+ transform="rotate(-45)"><tspan
+ sodipodi:role="line"
+ id="tspan717-6-3-2-1-2-22"
+
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-family:Helvetica;-inkscape-font-specification:Helvetica;fill:#ffffff;stroke:#ffffff;stroke-width:0.117619;stroke-dasharray:none;stroke-opacity:1"
+ x="-9.5756397"
+ y="165.21541">WITHDRAW COINS</tspan></text><text
+ xml:space="preserve"
+
style="font-size:5.1965px;line-height:0.75;font-family:Blacksword;-inkscape-font-specification:Blacksword;text-align:center;text-decoration:none;text-decoration-line:none;text-decoration-color:#000000;letter-spacing:-0.121647px;word-spacing:0px;text-anchor:middle;fill:#ffffff;stroke:#ffffff;stroke-width:0.117619;stroke-dasharray:none;stroke-opacity:1;paint-order:stroke
fill markers;stop-color:#000000"
+ x="226.08978"
+ y="-46.072773"
+ id="text719-3-5-6-9-9-9-5"
+ transform="rotate(45)"><tspan
+ sodipodi:role="line"
+ id="tspan717-6-3-2-1-2-22-0"
+
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-family:Helvetica;-inkscape-font-specification:Helvetica;fill:#ffffff;stroke:#ffffff;stroke-width:0.117619;stroke-dasharray:none;stroke-opacity:1"
+ x="226.02896"
+ y="-46.072773">DEPOSIT COINS</tspan></text><text
+ xml:space="preserve"
+
style="font-size:5.1965px;line-height:0.75;font-family:Blacksword;-inkscape-font-specification:Blacksword;text-align:center;text-decoration:none;text-decoration-line:none;text-decoration-color:#000000;letter-spacing:-0.121647px;word-spacing:0px;text-anchor:middle;fill:#ffffff;stroke:#ffffff;stroke-width:0.117619;stroke-dasharray:none;stroke-opacity:1;paint-order:stroke
fill markers;stop-color:#000000"
+ x="201.49336"
+ y="85.522163"
+ id="text719-3-5-6-9-9-0"><tspan
+ sodipodi:role="line"
+ id="tspan717-6-3-2-1-2-2"
+
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-family:Helvetica;-inkscape-font-specification:Helvetica;fill:#ffffff;stroke:#ffffff;stroke-width:0.117619;stroke-dasharray:none;stroke-opacity:1"
+ x="201.43254"
+ y="85.522163">WIRE MONEY</tspan></text><text
+ xml:space="preserve"
+ transform="matrix(0.2646,0,0,0.2646,0.2959,-14.23)"
+ id="text6986"
+
style="font-size:13.3333px;white-space:pre;shape-inside:url(#rect6988);display:inline;fill:#000000"
/><text
+ xml:space="preserve"
+ transform="matrix(0.2646,0,0,0.2646,0.2959,-14.23)"
+ id="text7022"
+
style="font-size:13.3333px;white-space:pre;shape-inside:url(#rect7024);display:inline;fill:#000000"
/><text
+ xml:space="preserve"
+
style="font-size:4.58611px;line-height:0.75;font-family:Blacksword;-inkscape-font-specification:Blacksword;text-align:center;text-decoration:none;text-decoration-line:none;text-decoration-color:#000000;letter-spacing:-0.103682px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:#ffffff;stroke-width:0.100249;stroke-dasharray:none;stroke-opacity:1;paint-order:stroke
fill markers;stop-color:#000000"
+ x="66.025627"
+ y="189.61301"
+ id="text719-3-5-6-9"><tspan
+ sodipodi:role="line"
+ id="tspan717-6-3-2-1"
+
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:4.58611px;font-family:Helvetica;-inkscape-font-specification:Helvetica;fill:#000000;fill-opacity:1;stroke:#ffffff;stroke-width:0.100249;stroke-dasharray:none;stroke-opacity:1"
+ x="65.973785"
+ y="189.61301">CUSTOMER</tspan></text><text
+ xml:space="preserve"
+
style="font-size:4.58611px;line-height:0.75;font-family:Blacksword;-inkscape-font-specification:Blacksword;text-align:center;text-decoration:none;text-decoration-line:none;text-decoration-color:#000000;letter-spacing:-0.0905252px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:#ffffff;stroke-width:0.0875285;stroke-dasharray:none;stroke-opacity:1;paint-order:stroke
fill markers;stop-color:#000000"
+ x="148.89816"
+ y="107.10488"
+ id="text719-3"><tspan
+ sodipodi:role="line"
+ id="tspan717-6"
+
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:4.58611px;font-family:Helvetica;-inkscape-font-specification:Helvetica;fill:#000000;fill-opacity:1;stroke:#ffffff;stroke-width:0.0875285;stroke-dasharray:none;stroke-opacity:1"
+ x="148.85291"
+ y="107.10488">EXCHANGE</tspan></text><text
+ xml:space="preserve"
+
style="font-size:4.58611px;line-height:0.75;font-family:Blacksword;-inkscape-font-specification:Blacksword;text-align:center;text-decoration:none;text-decoration-line:none;text-decoration-color:#000000;letter-spacing:-0.103682px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:#ffffff;stroke-width:0.100249;stroke-dasharray:none;stroke-opacity:1;paint-order:stroke
fill markers;stop-color:#000000"
+ x="233.75691"
+ y="189.48888"
+ id="text719-3-5-6"><tspan
+ sodipodi:role="line"
+ id="tspan717-6-3-2"
+
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:4.58611px;font-family:Helvetica;-inkscape-font-specification:Helvetica;fill:#000000;fill-opacity:1;stroke:#ffffff;stroke-width:0.100249;stroke-dasharray:none;stroke-opacity:1"
+ x="233.70508"
+ y="189.48888">MERCHANT</tspan></text><text
+ xml:space="preserve"
+ transform="matrix(0.2646,0,0,0.2646,-18.279167,2.565)"
+ id="text26483"
+
style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:42.6667px;font-family:sans-serif;-inkscape-font-specification:'sans-serif
Bold';white-space:pre;shape-inside:url(#rect26485);display:inline;fill:#241f1c;fill-opacity:1"><tspan
+ x="287.71484"
+ y="766.70028"
+ id="tspan11410">ANONYMOUS PAYMENT PROCESS</tspan></text><path
+
style="fill:#0042b3;fill-opacity:1;fill-rule:evenodd;stroke-width:1.41046"
+ d="m 130.2,85.635 c -0.966,1.421 -0.56,2.6999 0.91,2.6999 h 2.268 c
1.134,7.2471 7.462,13.2153 15.484,13.2153 3.36,0 6.58,-1.2789 8.96,-2.9841
1.4,-1.1368 1.54,-2.6999 0.98,-3.6946 -0.7,-1.2789 -2.24,-1.8473 -4.06,-0.5684
-1.68,1.1368 -3.78,1.8473 -5.88,1.8473 -5.124,0 -9.072,-3.5525 -10.136,-7.8155
h 2.254 c 1.428,0 1.904,-1.2789 0.91,-2.6999 l -4.41,-5.9682 c -0.784,-1.1368
-2.086,-1.1368 -2.842,0 z"
+ id="path298" /><path
+ style="fill:#000000;fill-rule:evenodd;stroke-width:1.41046"
+ d="m 140,68.583 c -1.386,0.9947 -1.512,2.5578 -0.896,3.6946
0.672,1.1368 2.24,1.8473 4.032,0.5684 1.652,-1.2789 3.71,-1.9894 5.936,-1.9894
5.04,0 8.96,3.5525 10.08,7.8155 h -2.38 c -1.4,0 -1.82,1.421 -0.84,2.6999 l
4.34,6.1103 c 0.84,1.1368 2.1,0.9947 2.8,0 l 4.48,-6.1103 c 0.98,-1.2789
0.56,-2.6999 -0.84,-2.6999 h -2.24 c -1.12,-7.105 -7.42,-13.0732 -15.4,-13.0732
-3.5,0 -6.664,1.1368 -9.072,2.9841 z"
+ id="path300" /></g><style
+ type="text/css"
+ id="style394">
+ .st0{fill:#000000;}
+</style></svg>
diff --git a/doc/usenix-security-2025/paper/images/stock1s.jpg
b/doc/usenix-security-2025/paper/images/stock1s.jpg
new file mode 100644
index 0000000..8a1ec04
Binary files /dev/null and b/doc/usenix-security-2025/paper/images/stock1s.jpg
differ
diff --git a/doc/usenix-security-2025/paper/implementation.tex
b/doc/usenix-security-2025/paper/implementation.tex
new file mode 100644
index 0000000..887d38f
--- /dev/null
+++ b/doc/usenix-security-2025/paper/implementation.tex
@@ -0,0 +1,354 @@
+\section{Implementation}\label{implementation}
+
+This section is also heavily based on (and often a verbatim
+reproduction of) the thesis~\cite{donau} by Johannes Casaba and Lukas
+Matyja supervised by Emmanuel Benoist and Christian Grothoff. We
+thank Johannes Casaba and Lukas Matyja for their significant
+contributions.
+
+This section describes the current implementation of the Donau,
+which consists of a REST API, an Android verification app, and the Donau
database.
+The Donau is written in C, as it reuses parts of the codebase from the
exchange of GNU Taler.
+The Donau has a similar architecture and uses
+cryptographic blinded signatures in a similar way as the exchange does.
+
+On the user side, donation receipts are collected in a wallet; the wallet takes
+the users taxpayer ID and picks its own salt to create the Donor Identifier
\DI.
+
+\subsection{REST API} \label{rest_api}
+The detailed REST API specification of the Donau back-end is publicly available
+under the following URL: \url{https://docs.taler.net/core/api-donau.html}. The
+following are the main API endpoints:
+
+\subsubsection{\texttt{/keys}}
+The \texttt{GET /keys} request returns all valid donation unit public keys
+offered by the Donau, as well as the Donau's current EdDSA public signing key.
+The following is an example response of a \texttt{curl 127.0.0.1:8080/keys}
+command. Some parts of the following example responses are truncated (denoted
by
+the three dots '\texttt{...}') to make them more readable.
+
+\begin{verbatim}
+{
+ "version": "0:0:0",
+ "base_url": "http://localhost:8080/",
+ "currency": "EUR",
+ "signkeys": [
+ {
+ "stamp_start": {
+ "t_s": 1717069556
+ },
+ "stamp_expire": {
+ "t_s": 1718279156
+ },
+ "key": "CFV2PY8164E231XZSQK30K8R6CBQ..."
+ },
+ {
+ ...
+ }
+ ],
+ "donation_units": [
+ {
+ "donation_unit_pub": {
+ "cipher": "RSA",
+ "rsa_public_key": "020000YC7XK99S..."
+ },
+ "year": 2024,
+ "lost": false,
+ "value": "EUR:5"
+ },
+ {
+ "donation_unit_pub": {
+ "cipher": "CS",
+ "cs_public_key": "7SKRQGBSEPBG24..."
+ },
+ "year": 2024,
+ "lost": false,
+ "value": "EUR:1"
+ },
+ {
+ ...
+ }
+ ]
+}
+\end{verbatim}
+
+\subsubsection{\texttt{/charities}}
+In order for a charity to be able to issue receipts by a specific Donau it
must be registered by this Donau.
+The Donau provides an API to manage charities.
+By default only the Donau administrator can change the list of registered
charities.
+The charity itself is able to request a donation report to keep track of their
total donations in the current year.
+The response includes the maximum donation amount and the current donated
amount for the charity of the current year.
+
+\begin{figure}[ht]
+\includegraphics[width=0.5\textwidth]{donau_flow_register_charity}
+\caption{The tax authority registers a new charity in the Donau.
+ A charity first requests to be added to the Donau, including its Charity
EdDSA public key in its request.
+ The tax authority them adds the charity by sending a POST request to the {\tt
+/charities} endpoint with the relevant data on the charity
+}\label{fig:donau_flow_register_charity}
+\end{figure}
+
+The following is an example response of a \texttt{curl
127.0.0.1:8080/charities} command.
+There is only one charity named \texttt{example} registered with a donation
limit of 10 euros.
+
+\begin{verbatim}
+{
+ "charities": [
+ {
+ "charity_pub": "ABETNXT9ZF606FRF3WD5...",
+ "url": "example.com",
+ "name": "example",
+ "max_per_year": "EUR:10",
+ "receipts_to_date": "EUR:0",
+ "current_year": 2024
+ }
+ ]
+}
+\end{verbatim}
+
+To insert a charity a \texttt{POST} request can be sent using
+\texttt{curl -d @charity.json -X POST http://127.0.0.1:8080/charities}.
+
+The following is an example of a
+\texttt{charity.json} entry
+
+\begin{verbatim}
+{
+ "charity_pub": "ABETNXT9ZF606FRF3WD5...",
+ "charity_name": "mycharity",
+ "charity_url": "mycharity.example.com",
+ "max_per_year": "EUR:1000",
+ "receipts_to_date": "EUR:0",
+ "current_year": 2024
+}
+\end{verbatim}
+
+The response consists of the charity ID generated by the database.
+\begin{verbatim}
+{
+ "charity-id": 1
+}
+\end{verbatim}
+
+
+\subsubsection{\texttt{/batch-issue}}
+Only recognized charities are allowed to issue receipts for their donors.
+A \texttt{POST} issue receipt request includes an array of \texttt{BKP}s. A
+\texttt{BKP} consists of a \texttt{BUDI} and a hash of a public donation unit
+key (see section~\ref{notation_and_definitions}).
+The charity signs the request with its own EdDSA private key. The
+corresponding public key was given to the Donau in the registration process of
+the charity.
+After the Donau checks the signature from the charity it signs the
+\texttt{BUDI}s with the corresponding donation unit private key. Before the
+signatures are returned to the charity the Donau saves a hash of the request
+and all donation unit signatures to detect replays (see
section~\ref{donau_database}).
+
+\begin{figure}[ht]
+\includegraphics[width=0.5\textwidth]{donau_flow_issue_receipt}
+\caption{Flow of the issue receipt process}
\label{fig:donau_flow_issue_receipt}
+\end{figure}
+
+The following is an example response of a \\
+\texttt{curl -d @issue.json -X POST http://127.0.0.1:8080/batch-issue/1}
+request showing a \texttt{issue.json} entry.
+The number at the end of the URL is the charity ID.
+
+
+
+\begin{verbatim}
+{
+ "budikeypairs": [
+ {
+ "h_donaton_unit_pub": "130C2KDHTAFDQFB8XED...",
+ "blinded_udi": {
+ "cipher": "RSA",
+ "rsa_blinded_identifier": "AXPTEE24W28S9XN..."
+ }
+ }
+ ],
+ "charity_sig": "JEJ0QMDXD416XKSK1SG0DETJEH...",
+ "year": 2024
+}
+\end{verbatim}
+
+\begin{verbatim}
+{
+ "blind_signatures": [
+ {
+ "blinded_signature": {
+ "cipher": "RSA",
+ "blinded_rsa_signature": "16XHNWSCDRVKHF..."
+ }
+ }
+ ],
+ "issued_amount: "EUR:15"
+}
+\end{verbatim}
+
+\subsubsection{\texttt{/batch-submit}}
+The batch-submit route is used by the donor to summarize their donation
+receipts into one donation statement, which then gets signed by the Donau with
+their EdDSA signature.
+The request is composed of the donation receipts (see
section~\ref{donau_creates_donation_receipt}),
+the corresponding year and the Donor Identification \DI, which is the salted
hash of the donor's taxpayer ID.
+When processing the request, the Donau checks the validity of the donation
+receipts and searches its database for other saved donation receipts made in
the requested
+year.
+The Donau computes
+a donation statement, consisting of a signature over
+the total value of the donation units of all donation receipts of the year,
+the salted hash of the taxpayer ID, and the current year,
+and stores this in its database along with the submitted receipts (see
section~\ref{donau_database}).
+
+In our implementation the Donau does not return this donation statement under
+this call but under the {\tt donation-statement} request, see below.
+
+The following is an example of a \\
+\texttt{curl -d @submit.json -X POST http://127.0.0.1:8080/batch-submit}
+request. If successful, the Donau returns the \texttt{HTTP 201} status code
+with an empty response.
+The following record would be stored.
+
+\begin{verbatim}
+{
+ "h_donor_tax_id": "N2NYR2SFNGZSS388R2SB0VK...",
+ "donation_year": 2024,
+ "donation_receipts": [
+ {
+ "h_donaton_unit_pub": "130C2KDHTAFDQFB8X...",
+ "nonce": "JEQC39G",
+ "donation_unit_sig":
+ {
+ "cipher": "RSA",
+ "rsa_signature": "GQBXPNE4JT5W53T3CVP6E..."
+ }
+ }
+ ]
+}
+\end{verbatim}
+
+\subsubsection{\texttt{/donation-statement}}
+To obtain the donation statement, the donor submits a GET request for a
specified year and taxpayer ID.
+
+The following is an example response of a \\
+\texttt{curl
http://127.0.0.1:8080/donation-statement/2024/N2NYR2SFNGZSS388R2SB...} \\
+request.
+
+The last parameter of the URL is the \DI.
+
+\begin{verbatim}
+{
+ "total": "EUR:15",
+ "donation_statement": "C1JVDP25AR001W5AHMAZ...",
+ "donau_pub": "63f62b7901311c2187bfcde6304d1..."
+}
+\end{verbatim}
+
+\begin{figure}[ht]
+\includegraphics[width=0.5\textwidth]{donau_flow_submit_receipt}
+\caption{Donor requests a donation statement from the Donau}
\label{fig:donau_flow_submit_receipt}
+\end{figure}
+
+\subsection{Donau client}
+The REST client removes some of the complexity of sending requests to the Donau
+server. It converts request parameters into JSON and parses JSON responses into
+a usable format.
+
+\subsection{Donau database}\label{donau_database}
+The Donau database contains five tables as shown in
figure~\ref{fig:db_physical_model}.
+The \texttt{donation\_units} and
+\texttt{donau\_sign\_keys} table store the keys necessary for signing and
+creating donation receipts. Donation receipts that are issued to be signed by
+the donau are stored in the \texttt{receipts\_issued} table while the receipts
+that are already signed are stored in the \texttt{receipts\_submitted} table.
+The \texttt{history} table keeps the donation records of the past years.
+
+\begin{figure}[ht]
+\includegraphics[width=0.5\textwidth]{db_physical_model}
+\caption{Donau database model (generated by \url{https://dbdiagram.io/})}
\label{fig:db_physical_model}
+\end{figure}
+\subsubsection{\tt charities}
+Each registered charity has an entry in this table. There may be a donation
+limit imposed by local law which prevents further donations if the limit is
+reached.
+
+\begin{itemize}
+ \item \texttt{charity\_id:} Unique ID generated by the database.
+ \item \texttt{charity\_pub:} Charity EdDSA public key
+ \item \texttt{charity\_name:} Name of the charity
+ \item \texttt{charity\_url:} Charity URL
+ \item \texttt{max\_per\_year:} The annual donation limit according to
local law.
+ \item \texttt{receipts\_to\_date:} The current amount of donations in the
current year. Reset to 0 when incrementing the \texttt{current\_year}.
+ \item \texttt{current\_year:} Current year
+\end{itemize}
+
+\subsubsection{\tt donation\_units}
+Table containing all the valid donation units the Donau knows about.
+\begin{itemize}
+ \item \texttt{donation\_unit\_serial:} Unique ID generated by the database.
+ \item \texttt{h\_donation\_unit\_pub:} Hash value of the donation unit
public key \texttt{donation\_unit\_pub}
+ \item \texttt{donation\_unit\_pub:} The donation unit public key. Is
either an RSA or Schnorr public key.
+ \item \texttt{validity\_year:} The year, for which the donation unit is
valid.
+ \item \texttt{value:} The amount and currency that this donation unit
represents.
+\end{itemize}
+
+\subsubsection{\tt donau\_sign\_keys}
+Contains all Donau EdDSA signing keys.
+\begin{itemize}
+ \item \texttt{dsk\_serial:} Unique ID generated by the database.
+ \item \texttt{donau\_pub:} Donau EdDSA public key.
+ \item \texttt{valid\_from:} Year the signing key becomes valid.
+ \item \texttt{expire\_sign:} Year the signing key becomes invalid.
+ \item \texttt{expire\_legal:} Year the signing key legally expires.
+\end{itemize}
+
+\subsubsection{\tt receipts\_issued}
+Contains all issued donation receipts sent to the Donau.
+\begin{itemize}
+ \item \texttt{receipt\_id:} Unique ID generated by the database.
+ \item \texttt{blinded\_sig:} Array of blinded signatures. These are the
\texttt{BKP}'s the Donau blind signed.
+ \item \texttt{charity\_id:} The ID of the charity that received the
donation.
+ \item \texttt{receipt\_hash:} Hash value over all the blinded donation
receipt received plus the hash of the donation units public key.
+ \item \texttt{amount:} The amount and currency this donation receipt
contains.
+\end{itemize}
+
+\subsubsection{\tt receipts\_submitted}
+Contains all submitted donation receipts sent to the Donor. By storing the
+signature \texttt{donation\_unit\_sig}, the idempotence of the API is kept in
+case the private key is replaced.
+\begin{itemize}
+ \item \texttt{receipt\_id:} Unique ID generated by the database.
+ \item \texttt{h\_tax\_number:} The hash of the tax number and salt (called
+$\DI$ in Section~\ref{technical}).
+ \item \texttt{nonce:} The nonce used in the \texttt{Unique Donor
Identifier}
+ \item \texttt{donation\_unit\_pub:} Reference to public key used to sign.
+ \item \texttt{donation\_unit\_sig:} The unblinded signature the Donau made.
+ \item \texttt{donation\_year:} The year the donation was made.
+\end{itemize}
+
+\subsubsection{\tt history}
+History of the yearly donations for each charity. This data provides a record
+of donations each year. It could also provide valuable information that could
+be used in statistics to analyze general donations over the year.
+\begin{itemize}
+ \item \texttt{charity\_id:} Unique ID generated by the database.
+ \item \texttt{final\_amount:} The final amount that was donated to the
charity
+ \item \texttt{donation\_year:} The year in which the donations where made.
+\end{itemize}
+
+\subsection{Android Verification App}\label{android_verification_app}
+The Android app is part of the verification process used by the tax authority
+to check the donation statement (see
+section~\ref{donor_sends_final_statement_to_a_validator}).
+The app decodes the submitted QR code from the donor,
+parses the signed values and the signature,
+and uses them to verify the signature.
+The arguments of the QR code are defined in
section~\ref{donor_sends_final_statement_to_a_validator}
+and encoded as colon-delimited base64 values:
+
+\begin{verbatim}
+ YEAR:TOTALAMOUNT:TAXID:TAXIDSALT:ED25519SIGNATURE
+\end{verbatim}
+
+Finally, the values and the verification result are displayed.
diff --git a/doc/usenix-security-2025/paper/intro.tex
b/doc/usenix-security-2025/paper/intro.tex
new file mode 100644
index 0000000..045550e
--- /dev/null
+++ b/doc/usenix-security-2025/paper/intro.tex
@@ -0,0 +1,168 @@
+\section{Introduction}\label{intro}
+
+The scope of this document is to provide an overview of potential technical
+requirements and desiderata for donation systems that wish to offer a
+technical solution in which donors can make donations to registered charities
+and then receive a tax benefit from the tax authorities when filing their tax
+statement. The document also provides a detailed technical design and
+implementation for privacy-preserving donations, developed in the
+thesis~\cite{donau} by Johannes Casaba and Lukas Matyja supervised by
+Emmanuel Benoist and Christian Grothoff.
+The design provides a solution for a relevant subset of the requirements.
+We also discuss extensions and adaptations for covering other requirements.
+
+This document is written in the context of the \href{https://ngi.taler.net}{NGI
+TALER} project, which is based around the electronic payment system GNU Taler.
+As may be obvious from the underlying acronym "Taxable Anonymous Libre
+Electronic Resources", GNU TALER bridges two seemingly opposite requirements:
+providing privacy to citizens with regards to how they spend their money in the
+digital realm, while at the same time creating a system for organizations which
+handle financial transactions that is transparent and auditable. The latter
prevents
+fraud and keeps taxation as a basic mechanism to take action in the common
+interest and fund public services. To the citizens it offers the same
+privacy properties we are used to with traditional cash payments.
+
+GNU Taler is a {\em digital commons}, based on free software and advanced
+cryptography. This means that -- unlike proprietary products -- the software
+can be adjusted by all stakeholders to carry the properties it should have.
+
+\subsection{Donations in a human rights perspective}
+
+Donating is an important way for people to empower causes they believe in, and
facilitate collective action. In many countries, there is explicit recognition
of the public benefit of such generosity: a friendly tax treatment of
donations. It makes sense: money you immediately give away to a recognized good
cause is not income that will be converted by you into private consumption. So
conceptually it deserves a different tax treatment.
+
+Donations have many causes, but quite often they are an obvious expression of
the human right towards the freedom of thought, conscience and religion.
Individual spending can be very intimate and personal, and even aggregate
spending habits can reveal a great deal about people. This holds even more so
for donating.
+
+Protecting donation confidentiality is therefore important to protect those
freedoms. We have to recognize that in some situations the mere fact hat
someone has -- in private -- donated to some cause at some point in their life,
can put them at risk in another context. The right to privacy is another
critical aspect of donating. International human rights law provides a
non-ambiguous responsibility to promote and protect the right to privacy.
+
+Both these rights---towards freedom of thought and to privacy---are anchored
in key international treaties and covenants such as the Universal Declaration
on Human Rights (Article 12), the European Convention for the Protection of
Human Rights and Fundamental Freedoms (Article 8) and many more.
+
+\subsection{Protection towards all sides}
+
+Privacy threats not only exist on the outside. Not many people are aware that
+while the causes they support may be worthwhile, not all philanthropies play as
+nice as one would expect them to towards donors. This happens in particular
+when such organizations employ third party (often commercial) agencies to help
+``yield'' more donations on a commission basis or as ``fund raisers''.
+Especially for-profit fund raising agencies tend to resort to questionable
+social engineering approaches. One common scenario is that after a first
+donation, such bad actors start to aggressively pressure a particular donor for
+more -- with personalized emails, letters, phone calls and even in person
+visits. This may happen beyond a single good cause: people that donate are
+known to be susceptible to a certain proposition, resulting in an avalanche of
+follow up demanding requests.
+
+In the era of data driven donations and corporate social media surveillance,
+this kind of behavior has unfortunately become so easy that there are not just
+pro bono but even paid services (source in the Netherlands:
+\href{https://www.donateursbelangen.nl/opzegservice}{Stichting
+Donateursbelangen}) to de-register and exercise the ``right to be forgotten''
+after donating.
+
+Even without such excesses, there are many circumstances when people like to
+donate something to their preferred causes without revealing their identity.
+Some people just prefer to stay anonymous because of personal beliefs or even
+religious requirements, or simply do not want to have publicity which might
+lead to a cascade of efforts from fund raisers.
+
+\subsection{Donation confidentiality}
+
+Making a financial donation is a deeply personal choice to share part of one's
wealth in order to benefit a cause one cares about. Some traditional ways of
donating (for instance passing around baskets or even plates in a religious
gathering) are vulnerable to group pressure, and door to door fundraising is
also confrontational and puts people on the spot.
+
+When donations are devoid of such pressures and there is no need for, e.g.,
virtue signaling, donation confidentiality comes into play. Historically,
people wanting to make an anonymous donation might have an envelope with cash
or a box of goods delivered. Obviously, this was never compatible with
providing tax benefits. Alternatively, they might arrange for an expensive
intermediary like a notary (although that would not be fully anonymous, and
depend on the discretion of the notary).
+
+Technically guaranteed donation confidentiality is certainly non-trivial to
+implement in the digital payment era. What you donate to and why may be
+strictly personal, but due to the nature of the banking system along the
+financial pipeline there is an uncomfortable number of actors handling
+sensitive data that allows for profiling and targeted discrimination on
+grounds. And there are even more that later on may have access to it. Digital
+payments are logged and made accessible to many different actors, and reporting
+donations to tax authorities adds yet (at least) one more actor to the
pipeline.
+It is the scope of this document to try and solve this issue and finally
+introduce donation confidentiality which adheres to ``privacy by design''.
+
+
+\subsection{Overview of the requirements analysis}
+There are two types of donations we will consider. The first is {\em ad hoc} or
+{\em informal donations}, which are made from individual to individual as {\em
+one time gifts} typically in appreciation of the work being done by an
+individual or collective. The second category is {\em regulated donations}
+involving at least one {\em recognized} philanthropic organization or charity.
+Both involve voluntary transferal of some financial assets for which no
+products or services are rendered in return.
+% NOTE[oec]: what types of donations are _not_ considered, and why?
+
+In the design requirements we will mostly cover donations to charities that
+offer a tax benefit as that triggers the most complex requirements.
+
+As part of their regular operations as well as their recognition as public
+benefit organizations, registered charities are already subject to a variety of
+audits as well as strict regulatory and fiscal scrutiny. Good causes that do
not adhere to these rules are stripped from any fiscal benefits. At least
donations to recognized public benefit organizations may therefore be
confidential: donors should be able to freely choose whichever of the approved
philanthropies they donate to, without disclosing which.
+
+In cases where donation confidentiality is not (yet) feasible, we will try and
provide fallbacks that best serve the interest of donors, give them choice and
respect their privacy as least as well as the current system in place.
+
+\subsection{Overview of the technical solution and implementation}
+On the technical side, this report presents the Donau protocol~\cite{donau}
+for making privacy-preserving donations.
+
+In the current way that donations are handled, the charities are in charge of
+issuing donation receipts to the donor and thus must know the donor's identity
+and address. The donor has to include the donation receipts in their tax
+declaration; this means the tax authority not only learns the amount that the
+tax payer donated to charitable organizations but also how much they gave to
+which.
+
+The Donau protocol makes it possible for the donor to give an unforgeable proof
+of the combined amount they donated to registered charities, without the
+charities or the tax authorities learning who donated to whom. The privacy
+features obviously require that there is more than one charity and more than
+one donor. The Donau protocol is oblivious to how the donation payment
+happens. If the donor chooses to donate by credit card or bank transfer then
+their identity becomes known to the charity through the payment.
+%
+However, a relevant feature of the protocol is that the charity does not need
+to learn the identity of the donor. Hence, payments can be made with GNU Taler
+keeping full anonymity of the donor.
+
+The design requires the creation of a Donation Authority (Donau), an
+additional service separate from the charities and the payment system.
+The Donau is responsible for recognizing charitable organizations and
+tracking the total amount of donation receipts each charity is issuing
+for the charitable contributions the charity is receiving. It is
+typically be expected that the tax authority would operate it. We
+note that the Donau does not receive sensitive private information
+about donors: privacy is achieved using cryptography to unlink proofs
+of donations from the actual donation process.
+
+
+\subsection{Structure of this report}
+The next section reflects on the requirements that donations need to satisfy.
+There are many aspects to donations and for the technical design and
+implementation we chose to focus on a design that provides privacy for
+donations.
+Section~\ref{technical} shows the technical details of the design including
+the cryptographic building blocks used in the system. The following section
reports
+on the implementation. Finally we consider various extensions of the
+presented approach that could be added to satisfy requirements currently
+not met by the core design. Many of these extensions are simply a matter
+of proper integration and user interface design, while a few presume the
+existence of a widely available digital identity system providing a single
+unlinkable pseudonym for each citizen per charity.
+
+\subsection{What this document is not}
+
+This document is not in any way an overview of current legal requirements
across
+the world on how taxation on donations work. Taxation is predictably unpopular
+despite its clear essential function in how modern societies work, and
+therefore a very political topic that is subject to frequent change. Whether it
+is taxation on labor and profits, on property, on inheritance, on income from
+investment or gambling, or on consumption of products or services -- there is
+no global universally agreed standard on whether these should be taxed and how
+that is to be done. Ad hoc regulation as part of political shifts makes
+taxation very context-specific and temporal. We are unaware of any attempt at
+creating such an overview as a public resource, and the cost of creating and
+subsequently maintaining such an effort would be prohibitive.
+
+Instead the focus of this document is on providing an overview of generic
requirements that could be made to a donation flow in order to comply with
regulation.
+
+One should note that, in many jurisdictions, recipients of donations do not
necessarily have the same protections. Donations should be given without return
consideration, but of course there are many financial transactions (such as
gifts or donations from business or lobby groups to political parties) that are
not as clean in this respect.
diff --git a/doc/usenix-security-2025/paper/letter.png
b/doc/usenix-security-2025/paper/letter.png
new file mode 100644
index 0000000..4116c6f
Binary files /dev/null and b/doc/usenix-security-2025/paper/letter.png differ
diff --git a/doc/usenix-security-2025/paper/qr-donau.png
b/doc/usenix-security-2025/paper/qr-donau.png
new file mode 100644
index 0000000..989751a
Binary files /dev/null and b/doc/usenix-security-2025/paper/qr-donau.png differ
diff --git a/doc/usenix-security-2025/paper/receipt.png
b/doc/usenix-security-2025/paper/receipt.png
new file mode 100644
index 0000000..edc3c38
Binary files /dev/null and b/doc/usenix-security-2025/paper/receipt.png differ
diff --git a/doc/usenix-security-2025/paper/red_wax.png
b/doc/usenix-security-2025/paper/red_wax.png
new file mode 100644
index 0000000..b7b7c6d
Binary files /dev/null and b/doc/usenix-security-2025/paper/red_wax.png differ
diff --git a/doc/usenix-security-2025/paper/requirements.tex
b/doc/usenix-security-2025/paper/requirements.tex
new file mode 100644
index 0000000..e07d47e
--- /dev/null
+++ b/doc/usenix-security-2025/paper/requirements.tex
@@ -0,0 +1,460 @@
+\section{Requirements Analysis}\label{requirements}
+
+The starting point of this document is to create an initial overview of
requirements to provide donors with donation privacy and tax authorities with
adequate proof that a donation was indeed clean and made according to the rules
for donations in their region of operation.
+
+Tax authorities are creative, and taxation is an ever evolving area of
complexity. We will therefore not claim to provide the definitive overview, but
to provide a good start for bootstrapping a donation ecosystem in the full
knowledge that this will need to be updated.
+
+Subsequent deliverables (D3.5 and D3.6) may prioritize different properties and
+features or add further requirements on the design.
+
+\subsection{Assumptions}
+
+The basic assumptions when defining requirements for a donation flow are as
follows:
+
+\begin{itemize}
+\item A donor donates from their {\em own assets}, and is willing to go on
record (by means of a self-declaration) as acting on their own accord.
Violation of this principle would then constitute fraud at their end.
+\item A tax authority wants to assert that a donation comes from the legitimate
+donor, and is not made by some third party on their behalf.
+\item There is no inverse relationship between the donor and donee, where the
donor stands to receive money back from the donee in some concrete (in)direct
way as result of the donation.
+\item Donors are willing and able to provide privacy-preserving attestation of
+some unique and non-falsifiable personal or organizational property (such as a
+tax identification number) {\em at the time of donation} in order to be able to
+add up multiple donations within a single tax reporting period and validate
+that these do not extend beyond a threshold set by the tax authority or other
regulators
+\item The philanthropies or charities are subject to {\em regulatory
+oversight}, {\em proper governance} and {\em regular audits}, so that money
+laundering is not relevant
+\item It is acceptable for some third party to be involved, but only based on
+ Free/Libre Open Source software (FLOSS) and on a zero knowledge basis
+%- philanthropies are able to provide valid digital signatures
+\item All parties involved own and can operate digital devices so that they can
+store digital identifiers, cryptographic keys, and donation receipts or
+records
+\item Donors are expected to have a device that can hold a wallet for
permanent
+storage of donation receipts.
+\item Charities and tax authorities are willing and able to run basic
+infrastructure.
+\end{itemize}
+
+\subsection{Design goals} \label{sec:designgoals}
+
+The following design goals hold:
+
+\begin{itemize}
+\item Accommodate a donor's wish to remain fully anonymous, also towards the
+organization(s) donated to.
+\item The donor should be able to claim the tax benefits they are entitled to
+without having to disclose any of the organization(s) donated to to the tax
+authority.
+\item The donor may accumulate any number of smaller or larger donations
+towards different eligible organizations (ideally even cross-border, in the
+presence of suitable fiscal arrangements such as within the European Union).
+\item Since donations are cumulative and often spontaneous, a donor should not
+have to decide upfront whether they will request tax benefits for their
+donations later on. Hence, all donations to suitable registered charities
+should result in a form of donation receipt.
+\item At the same time, the wallet of a donor should offer plausible
deniability
+of any specific donations.
+\end{itemize}
+
+\subsection{Optional Features} \label{sec:optionalfeatures}
+
+The following list of optional features of a donation system would allow for a
+maximum fit with as many fiscal regimes as possible for both informal and
+regulated donations, while at the same time serving the interest of the donors
+in question in the best possible manner. Specific realizations may weigh these
+differently based on local regulations and capabilities, but most need to be be
+provided in some form.
+
+\begin{itemize}
+\item Provide fiscal statement
+\item Proof of registration
+\item Providing a configurable self-testimony from the donor that they comply
with specific legislation or regulation related to donations
+\item Cumulative donation counter from same donor to same cause
+\item Providing a notarized affidavit asserting uniqueness
+\item Unique ID for voting/Donor Advised Choices
+\item Making a compound weighted donation
+\item Cost transparency
+\item Staged donation
+\item Bandwidth donations
+\item Codes of conduct
+\item Restricted access mechanism
+\item Donation matching with a reference
+\item Anonymous donation matching by employer
+\end{itemize}
+
+\noindent
+We will elaborate on each of these features below.
+
+\subsubsection{Feature: Provide fiscal statement}
+
+The ability to provide a fiscal statement from the receiving charity linked to
the donation is the starting point for most regulated donations, in order to
comply to current practices.
+For example, with a time-stamped and printable fiscal statement of the amount,
digitally
+signed by the charity, a donor can prove their donations in person to a tax
authority.
+
+It should be possible to obtain this statement at the time of donation, and
+ideally within a reasonable period afterwards -- in both cases without having
to expose any additional information to anyone (such as an IP address which is
typically visible when downloading a document via the web).
+
+There might be a need to include personal data/attributes in the attestation
(e.g. a name, password ID, etc). There is no need for the charity itself to
have any knowledge about such information, so it may be included encrypted with
a key accessible exclusively to the donor/the tax authority/an auditor or other
suitable independent third party.
+
+The information should be configurable, and it should be clear which
information is somehow independently validated.
+
+\subsubsection{Feature: Proof of registration}
+
+In some countries (e.g. Belgium) donors are required to register themselves
+with the tax authority before making a donation. While we believe that to be an
+anti-feature, it should be possible to include a checksummed code provided by
+the tax authority or a charity that makes sure that only registered donors can
donate.
+
+\subsubsection{Feature: Configurable pledge}
+
+It may be necessary for the donor to testify (prior to the donation) that they
+comply with some legislative or regulatory requirement, or agree with a policy
+set by the charity in question.
+
+As a generic requirement, this translates to a configurable pledge by the donor
+(e.g. ``I am not an employee or grantee of the organization I am donating to,
+and am acting on my own accord. I stand to make no direct financial gains from
+making this donation'').
+
+The potential for abuse of donations to regulated charities is very limited.
+Such a self-testimony will allow the default to be to treat donations in a
+``good faith'' manner rather than with a top-heavy and restrictive
+one-size-fits-all method.
+
+\subsubsection{Feature: Cumulative donation counter from same donor to same
+cause}
+
+One way to bypass restrictions in terms of allowed donation sizes before
+possible ``Know Your Donor'' requirements kick in, is to split up donations. If
+limits per donor are in place it becomes necessary to be able to assert that
+cumulative donations from a donor stay below a set threshold, where the
+threshold might have a temporal aspect (per year, per quarter, per two years).
+
+\subsubsection{Feature: Notarized affidavit}
+
+More generically---for instance when there is a minimum age for donations to
certain class of causes---a privacy-preserving solution might be to have a
notarized affidavit independently asserting the requirements have been met to
be included in the metadata of the payment.
+
+Such a privacy-preserving affidavit would not be traceable back to any
+underlying private information of the donor or to the charity in question.
+It might contain a counter or append-only record, and a date stamp with an
+accuracy no more precise than a calendar week (to avoid correlation attacks).
+
+It is better for this affidavit not to be provided by individual charities but
+by trusted third parties otherwise ignorant of the transactions in questions:
+it involves an isolated task which can easily be outsourced to an independent
+service. That independent service only needs to perform this singular task
+based on having access to the proof/attribute(s) in question and does not need
+to have any further knowledge of any of the actors. The latter assumes that any
+unique identifier in the affidavit is uniquely linked to the donor so that they
+cannot circumvent limits by going via different third parties.
+
+As long as the affidavit is non-falsifiable and irrevocable, it should suffice
to assert uniqueness and allow to prove that the required conditions were met.
+
+\subsubsection{Feature: Unique ID for donor advised decisions}
+
+Also from the side of a donor, there might be a need for having a unique ID for
+voting. In the same vein as Donor Advised Funds, a crowd-sourced version could
+be Donor Advised Choices where donors can vote on specific options (``Shall we
+prioritize stretch goal A or B'', or ``We see a new opportunity, is it okay to
+replace some stated work with something else'') -- either on a weighted variant
+(larger donation gives more weight) or on a one person, one vote (all unique
+donors get the same one vote each).
+
+Alternatively, a preference vote encoded inside the payment (based on e.g.
Condorcet voting) could provide a one-time donor advised voting mechanism.
+
+\subsubsection{Feature: Compound weighted donation}
+
+The general idea is that donors can make a single donation, but this consists
of multiple payments to multiple recipients. This is particularly relevant for
informal donations to the developers of free and open source projects that do
not make use of a fiscal host. In such a situation, the donations may be
divided across the individual developers with a certain weight. Each of the
recipients receives a direct donation from the donor, which typically will be
far below the threshold for taxation.
+
+There can be a suggested/default weight, but the donor should be able to tweak
the relative weights and/or block specific recipients.
+
+\subsubsection{Feature: Cost transparency}
+
+It should be transparent to the donor what percentage of their donation
+is actually used for the effort for which funds are being raised. In particular
+it should be possible for the {\em cost for fundraising} to be made explicit,
+especially if this involves third parties. It should be possible to choose to
+donate without paying for fundraising.
+
+(This might use the features from compound weighted donation)
+
+\subsubsection{Feature: Staged donation}
+
+This is a feature that works along the lines of so-called smart contracts. As
+goals are incrementally met by the project, donated funds are released. If the
+goals are not met according to the preset stages, the part of the money that is
+concerned with work that is not delivered is not paid and may ultimately be
+restored to its rightful owner, the donor.
+
+\subsubsection{Feature: Bandwidth donations}
+
+When people are pooling together resources to make some goal possible, in order
+to stimulate the broadest possible donations, the amount donated can be made
+flexible (within a certain {\em donation bandwidth}). Instead of stretching
+goals (which donors might not agree with) and promoting freeloading, the size
+of individual donations could shrink as well. This would stimulate to share the
+collective load.
+
+\subsubsection{Feature: Code of conduct}
+
+Donors transfer part of their (sometimes scarce) earthly possessions to
support the good work of a cause they believe in, and it is only logical that
this altruism comes with certain expectations in terms of how the organization
receiving that money will subsequently spend it.
+
+A {\em Code of Conduct} is the equivalent of the product warranty, where
+charities declare themselves accountable and promise to uphold certain best
+practices and adhere to public scrutiny -- and are subsequently held to their
+promise by stakeholder organizations like Donateursbelangen.
+
+An example of such a Code of Conduct public benefit organizations can subscribe
+to is the \href{https://www.donateursbelangen.nl/de-donateursbelofte}{Donor
Pledge}
+(``Donateursbelofte'' in Dutch). It should be possible for a charity to adhere
+to multiple such Code of Conducts and offer them as part of their donation
+portal.
+
+Similarly, there are certification schemes for charities qualifying as public
+benefit organizations. These offer a reverse link from the certifying
+organization to the charity. It should be possible to include the certification
+conditions and this reverse link alongside the payment.
+
+\subsubsection{Feature: Restricted access mechanism}
+
+In order to engage donors with the work being done, philanthropies might want
+to give ``behind the scenes'' access to ongoing work to their donors. In order
+for that to happen, it should be possible to provide (limited) access to
+restricted materials for donors only. On a technical level, this could be
+handing out {\em One Time Passwords} or other forms of proof of donation that
+will allow donors to get access to restricted areas.
+
+\subsubsection{Feature: Unlock thank you artwork}
+
+Making a donation is not just a clinical financial transaction where money is
transferred from A to B, but something that also has emotional weight: the
donor has taken a step they may have pondered about for a long time.
Celebrating this altruistic win is part of the donation experience. ``Thank
you'' artwork consists of images, video and/or audio used to enliven the
financial transaction.
+
+In some cases artists or other creatives might donate a work to the charity in
+question for this purpose, in other cases a charity might use photos of their
+day to day work or other personal tokens.
+
+For transferring physical objects, the donor would need to be identifiable as
+such. At the same time, it should be possible for a donor to decline receiving
+such gifts and retain their anonymity, to the extent that this does not
+conflict with other regulations.
+
+\subsubsection{Feature: Donation matching with a reference}
+
+In some cases, a benefactor will want to incentivize others contemplating a
+donation to a specific good cause to go ahead. That is not necessarily
+something that needs privacy: some people and organizations use donations to
+publicly profile themselves. A common mechanism to incentivize others is to
+promise to match their donations to the organization in question, which is
+frequently done by announcing a period in which other people's donations will
be
+``matched'' (as in: donor A promises to donate as much as all other donations
in that
+time period combined).
+
+However, this is obviously a very crude mechanism, only suitable for
+benefactors with very deep pockets. It also does not give much opportunity for
+the benefactor to explain why they do this (and, let us be realistic, get some
PR out of it as well).
+
+By allowing the donor to include a reference to e.g. a social media post or
+blog post announcing the matching and requesting other donors to include that
+reference when making their donations, the donor providing the matching can
+`see' that they are being heard/are getting PR mileage out of their donation.
+
+\subsubsection{Feature: Anonymous donation matching by employer }
+
+Quite a few large employers do donation matching as part of their corporate
+responsibility or human resource management (HRM) efforts. This is typically
+not tied to a single cause. Many larger employers sponsor such matching gift
+programs, either by themselves (such as the U.S. Office of Personnel
+Management's \href{https://givecfc.org}{Give CFC}) or via (currently expensive)
+third party organizations such as Benevity, Submittable, WeSpire, Goodera, etc.
+
+In many cases, this practice is rather privacy-invasive. If you donate to,
+e.g., a reproductive rights organization, an NGO promoting climate justice, or
a
+digital rights organization, an employer might want to find out from whom that
+donation originated. This makes it attractive for the donor to have a
+chance to stay anonymous while nevertheless ensuring that their donation is
+matched as one done by an employee of the company.
+This would require a mechanism where charities could prove to an employer that
+some eligible person (typically an employee or retiree) has donated money which
+needs to be matched -- obviously, without disclosing anything else.
+
+
+\subsection{General background information}
+
+This section contains general background information pertaining donations.
+
+\subsubsection{General Regulatory Framework}
+
+European Union (EU) member states regulate donations through a blend of EU-wide
+directives and country-specific laws. While there is no uniform regulation that
+applies to all donations in Europe, certain EU directives and principles affect
+donation practices, particularly those related to transparency, anti-money
+laundering (AML), tax compliance, and donor data protection.
+
+\subsubsection{Transparency and Accountability}
+
+Transparency in charitable donations is crucial to maintain public trust and
deter financial misuse. European countries typically require organizations that
receive donations to adhere to transparency measures, including:
+
+\begin{itemize}
+\item {\bf Public Financial Reporting:} Most European countries mandate that
+charities, nonprofits, and similar organizations publish annual financial
+reports. These reports generally include detailed breakdowns of income sources,
+donation amounts, and expenditures.
+\item {\bf Disclosures for Large Donations:} In some countries, large donations
+must be reported to regulatory authorities. This threshold and the specific
+requirements vary by country. For example, Germany requires registration for
+organizations receiving public donations, while the UK mandates certain
+reporting for donations above a particular threshold.
+\item {\bf Third-Party Audit Requirements:} To verify the financial integrity
+of charitable organizations, many countries mandate independent audits for
+organizations surpassing specific revenue thresholds.
+\end{itemize}
+
+\subsubsection{Anti-Money Laundering (AML) and Counter-Terrorism Financing
(CTF)}
+Given the potential for abuse of charitable donations for money laundering and
+financing illegal activities, EU-wide Anti-Money Laundering Directives (such as
+the AMLD5) require organizations to implement stringent controls.
+
+\begin{itemize}
+\item {\bf Know Your Donor (KYD):} Similar to the Know Your Customer (KYC)
+practices in the financial sector, some countries require organizations to
+verify the identity of donors making significant contributions. This
+requirement is typically tied to AML laws.
+\item {\bf Transaction Monitoring and Reporting:} Charitable organizations must
+monitor donation transactions and report any suspicious activities to relevant
+national authorities.
+\item {\bf Registration with Financial Intelligence Units (FIUs):} Nonprofits
+are encouraged, and sometimes required, to register with FIUs in certain EU
+countries to facilitate AML compliance.
+\end{itemize}
+
+\subsubsection{Taxation and Deductibility}
+
+The tax treatment of donations varies across Europe, but many countries provide
+tax incentives to encourage charitable giving. Donations to qualifying
+nonprofit organizations are often tax-deductible, either partially or fully,
+depending on local laws.
+
+\begin{itemize}
+\item {\bf Eligibility of Donors and Organizations:} Both the donor and the
+recipient organization usually need to meet specific criteria. For instance,
+only donations to accredited charities registered with national authorities are
+often eligible for tax relief.
+
+\item {\bf Limits on Deductions:} Most countries place caps on deductible
+donations, typically as a percentage of the donor’s income. For example, France
+allows deductions up to 20\% of taxable income, whereas Germany permits
+deductions up to 20\% of annual income or corporate profits.
+\item {\bf Cross-Border Donations and Tax Relief:} The EU's ``Stauffer
+doctrine'' principle requires member states to treat cross-border donations
+similarly to domestic donations if the recipient organization meets equivalent
+standards, which facilitates cross-border charitable giving across the EU.
+\end{itemize}
+
+\subsubsection{Data Protection and Privacy (GDPR)}
+
+The General Data Protection Regulation (GDPR) is a significant EU law that
+affects how personal data is collected, stored, and managed, including for
+donations.
+
+\begin{itemize}
+\item {\bf Consent for Data Collection:} Donors must be informed of how their
+personal data will be used, and organizations must obtain explicit consent if
+data will be used for purposes beyond the donation transaction itself, such as
+marketing.
+\item {\bf Data Minimization and Retention:} Organizations are expected to
+collect only the data necessary for processing the donation, retain it only as
+long as necessary, and ensure proper data deletion practices.
+\item {\bf Right to Access and Erasure:} Donors have the right to request
+access to their personal data held by an organization and can request deletion
+or correction of their data under specific circumstances.
+\end{itemize}
+
+\subsubsection{Corporate Donations and Sponsorships}
+Corporate donations are also regulated, particularly when related to tax
+deductibility, disclosures, and compliance requirements.
+
+\begin{itemize}
+\item {\bf Transparency in Corporate Sponsorships:} European countries may
+require public disclosure of corporate donations or sponsorship arrangements,
+especially when public funds are involved. Many countries also enforce rules
+against donations that may appear to be intended for influencing legislation or
+government actions.
+\item {\bf Limits on Corporate Donations:} Some countries impose caps on
+corporate donations eligible for tax relief to prevent excessive deductions and
+potential misuse.
+\end{itemize}
+
+\subsubsection{Cross-Border Giving and EU Philanthropy Initiatives}
+The European Union encourages philanthropy across borders within Europe, but
+the process is still complex due to varying national tax and legal frameworks.
+
+\begin{itemize}
+\item {\bf European Foundation Statute and the European Philanthropy
Manifesto:}
+These initiatives aim to harmonize cross-border philanthropy regulations. The
+proposed European Foundation Statute, for instance, would create a legal form
+of a foundation operating across the EU.
+\item {\bf Transnational Requirements for Nonprofits:} Nonprofits must navigate
+both the tax and regulatory requirements of each country in which they operate
+or fundraise, including any special registrations, tax filings, or
+documentation for cross-border transactions.
+\end{itemize}
+
+\subsubsection{Ethical Standards and Codes of Conduct}
+
+Some European countries have established or encouraged adoption of ethical
+standards or codes of conduct for fundraising activities. Examples include:
+
+\begin{itemize}
+\item {\bf Code of Conduct for Fundraising:} Many countries have adopted codes
+of conduct, which may govern methods for soliciting donations, advertising
+practices, and donor interaction protocols. There are also private initiatives
+such as the Donor Pledge from the Dutch foundation Donateursbelangen (``Donor
+Interest Foundation'').
+\item {\bf Charity Commissions and Regulatory Bodies:} Several European
+countries have independent regulatory bodies that oversee charitable
+organizations, such as the Charity Commission in the UK, to ensure compliance
+and ethical conduct in donations.
+\end{itemize}
+
+\subsection{Country-Specific Considerations}
+
+While EU-wide directives provide a framework, each country has unique laws.
+Here are a few examples:
+
+\begin{itemize}
+\item {\bf Germany:} Nonprofit organizations must register with local
+authorities to receive tax exemptions, and donations exceeding 10\,000 EUR
must be
+reported.
+\item {\bf France:} Nonprofits must adhere to the ``Loi de 1901'' and comply
+with annual reporting requirements to remain eligible for public donations.
+\item {\bf Italy:} Nonprofits are eligible for tax incentives if they register
+as ONLUS (Organizzazione Non Lucrativa di Utilità Sociale) or a similar
+designation under Italian law.
+\end{itemize}
+
+\subsection{Conclusion}
+
+Navigating donation regulations in Europe involves adhering to EU directives on
+transparency, AML, tax compliance, and data protection while also meeting
+specific requirements in individual countries. Compliance ensures trust in the
+philanthropic sector, promoting ethical giving practices and cross-border
+donations within the EU’s regulatory landscape.
+
+
+\ifodd0
+Some bits of thoughts
+
+Article 56 TFEU guarantees free movement of services throughout the EU.
+In particular, this obliges each EU country to recognize the charitable
+organizations that are registered in other countries, as confirmed by
+the following decision of the Court of Justice of the European Union:
+
+\url{https://op.europa.eu/en/publication-detail/-/publication/d3892f27-39b1-4a26-98b3-451a7ffb101d/language-en}
+
+
+
+\subsection{Yearly Donation Limit}
+In some tax jurisdictions, the tax authority may set a limit on the total
amount of donations
+that a charity may receive in a given tax year. %XXX ~\cite{?}
+A Donation Authority must enable tracking and enforcement of such a limit.
+\fi
diff --git a/doc/usenix-security-2025/paper/servers.png
b/doc/usenix-security-2025/paper/servers.png
new file mode 100644
index 0000000..97d512d
Binary files /dev/null and b/doc/usenix-security-2025/paper/servers.png differ
diff --git a/doc/usenix-security-2025/paper/stickman.png
b/doc/usenix-security-2025/paper/stickman.png
new file mode 100644
index 0000000..a4c8900
Binary files /dev/null and b/doc/usenix-security-2025/paper/stickman.png differ
diff --git a/doc/usenix-security-2025/paper/taler-short.cls
b/doc/usenix-security-2025/paper/taler-short.cls
new file mode 100644
index 0000000..4b21507
--- /dev/null
+++ b/doc/usenix-security-2025/paper/taler-short.cls
@@ -0,0 +1,317 @@
+\def\fileversion{1.7}
+\def\filedate{2015/03/31}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%
+% CLASS pqcrypto.cls
+%
+%---------------------------------------------------------------------
+%
+% LaTeX class for TALER deliverable in LaTeX report/article style
+% (based on the ECRYPT and CACE and ... deliverable templates)
+%
+% \documentclass{taler-short}
+%
+% uses a report style without tale of contents & list of figures etc.
+%
+% \documentclass[article]{taler}
+%
+% uses an article style.
+%
+% version 1.8, 2023.12.01, T. Lange (converted from PQCRYPTO to TALER)
+% version 1.7, 2015.03.31, T. Lange (converted from PUFFIN to PQCRYPTO)
+% version 1.6, 2012.06.11, D. J. Bernstein (converted from CACE to PUFFIN)
+% version 1.5, 21-2-08, Guido Blady (added \wpcontrib and \cacekeywords
commands)
+% version 1.4, 20-2-08, Guido Blady (converted to CACE deliverable template)
+% version 1.3, 5-12-07, Christian Cachin (removed broken PDF graphics opt)
+% version 1.2, 2-2-06, Christian Cachin (added \ecryptabstract command)
+% version 1.1, 14-2-05, Marc Joye
+% version 1.0, 27-1-05, Antoon Bosselaers & Christian Cachin
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\NeedsTeXFormat{LaTeX2e}
+\typeout{^^J *** TALER Class \fileversion\space for LaTeX2e ***^^J}
+\ProvidesClass{taler}[\filedate]
+
+%%------------------------ (class options) ----------------------------
+\newcommand\mj@class{}
+\newif\ifmj@report\mj@reporttrue
+\DeclareOption{article}{\mj@reportfalse\renewcommand\mj@class{article}}
+\DeclareOption{report}{\renewcommand\mj@class{report}}
+
+\newcommand\mj@papersize{}
+\DeclareOption{a4paper}{\renewcommand\mj@papersize{a4}}
+\DeclareOption{a5paper}{\renewcommand\mj@papersize{a5}}
+\DeclareOption{b5paper}{\renewcommand\mj@papersize{b5}}
+\DeclareOption{letterpaper}{\renewcommand\mj@papersize{letter}}
+\DeclareOption{legalpaper}{\renewcommand\mj@papersize{legal}}
+\DeclareOption{executivepaper}{\renewcommand\mj@papersize{executive}}
+
+\newcommand\mj@ptsize{}
+\DeclareOption{10pt}{\renewcommand\mj@ptsize{0}}
+\DeclareOption{11pt}{\renewcommand\mj@ptsize{1}}
+\DeclareOption{12pt}{\renewcommand\mj@ptsize{2}}
+
+\newcommand\mj@titlep@ge{}
+\DeclareOption{titlepage}{\renewcommand\mj@titlep@ge{titlepage}}
+\DeclareOption{notitlepage}{\renewcommand\mj@titlep@ge{notitlepage}}
+
+\newcommand\mj@twoside{}
+\DeclareOption{twoside}{\renewcommand\mj@twoside{twoside}}
+\DeclareOption{oneside}{\renewcommand\mj@twoside{oneside}}
+
+\ExecuteOptions{report,a4paper,11pt,titlepage,twoside}
+\DeclareOption*{\PassOptionsToClass{\CurrentOption}{\mj@class}}
+\ProcessOptions
+\LoadClass[\mj@papersize paper,1\mj@ptsize
pt,\mj@titlep@ge,\mj@twoside]{\mj@class}
+%---Chapters automatically start on a new right-hand page
+\ifmj@report\@openrighttrue\fi
+%%---------------------- (end class options) --------------------------
+
+
+
+%%------------------------ (page settings) ----------------------------
+\IfFileExists{a4wide.sty}{\RequirePackage{a4wide}}{}
+\IfFileExists{url.sty}{\RequirePackage{a4wide}}{\let\url\texttt}
+\setlength\arraycolsep{1.4\p@}
+\setlength\tabcolsep{1.4\p@}
+\def\vtopx{\hsize9cm\vtop}
+\def\marginnote#1{\marginpar{\footnotesize #1}}
+\pagestyle{myheadings}
+%%---------------------- (end page settings) --------------------------
+
+
+
+%%---------------------------- (macros) -------------------------------
+\newcommand{\F}{{\bfseries F}}
+\newcommand{\complet}{{\bfseries TO BE COMPLETED}}
+\renewcommand{\pmod}[1]{\allowbreak \mkern 10mu({\operator@font mod}\,\,#1)}
+%%-------------------------- (end macros) -----------------------------
+
+
+
+%%------------------------- (user options) ----------------------------
+%% \title[...]{...} (mandatory!!!)
+%% \author{...}
+%% \doccode{...}
+%% \leadcontractor{...}
+%% \duedate{...}
+%% \actualdate{...}
+%% \version{...}
+%% \dissemination{...}
+%% \reportabstract{...}
+
+\long\def\title{\@ifnextchar [{\mj@title}{\mj@title[]}}
+\def\mj@title[#1]#2{\gdef\@shorttitle{#1}\gdef\@title{#2}}
+\newcommand{\doccode}[1]{\gdef\thedoccode{#1}}
+\newcommand{\leadcontractor}[1]{\gdef\theleadcontractor{#1}}
+\newcommand{\duedate}[1]{\gdef\theduedate{#1}}
+\newcommand{\wpcontrib}[1]{\gdef\thewpcontrib{#1}}
+\newcommand{\actualdate}[1]{\gdef\theactualdate{#1}}
+\newcommand{\version}[1]{\gdef\theversion{#1}}
+\newcommand{\dissemination}[1]{\gdef\thedissemination{#1}}
+\renewcommand{\date}[1]{\gdef\@date{\let\today\mjtoday #1}}
+\newcommand{\reportabstract}[1]{\gdef\thereportabstract{#1}}
+\newcommand{\reportkeywords}[1]{\gdef\thereportkeywords{#1}}
+\newcommand{\changetable}[1]{\gdef\thechangetable{#1}}
+
+\edef\mjtoday{%
+ \number \day.\space%
+ \ifcase \month \or January\or February\or March \or April\or May\or
+ June\or July\or August\or September\or October\or November\or
+ December\fi\space \number \year}
+\global\let\today\mjtoday
+
+\def\@title{\@empty}
+\def\@author{\@empty}
+\def\@shorttitle{\@empty}
+\def\thedoccode{D.XXX.Y}
+\def\theleadcontractor{\\Eindhoven University of Technology\\
+{\tt www.taler.net/eurotaler}}
+\def\theduedate{\@empty}
+\def\theactualdate{\mjtoday}
+\def\thewpcontrib{\@empty}
+\def\theversion{Revision 1.0}
+\def\thedissemination{PU}
+\def\@date{\theactualdate\\ \theversion}
+\def\thereportabstract{\@empty}
+\def\thereportkeywords{\@empty}
+\def\thechangetable{\@empty}
+%%----------------------- (end user options) --------------------------
+
+
+
+%%---------------------- (warnings and errors) ------------------------
+\newcommand{\mj@warning}[1]{%
+ \GenericWarning {\space \space \space \@spaces \@spaces \@spaces }%
+ {TALER Warning: #1}}
+%--- Warning without line number
+\newcommand{\mj@warning@no@line}[1]{%
+ \GenericWarning {\space \space \space \@spaces \@spaces \@spaces }%
+ {TALER Warning: #1\@gobble}}
+\newcommand{\mj@error}[2]{%
+ \GenericError {\space \space \space \@spaces \@spaces \@spaces }%
+ {TALER Error: #1}{See the documentation for explanation.}{#2^^J}}
+%%-------------------- (end warnings and errors) ----------------------
+
+
+
+%%------------------- (maketitle and titlepage) -----------------------
+
+\if@titlepage
+ \renewcommand{\maketitle}{%
+ \ifx\thetitle\undefined
+ \if!\@title!\mj@error{No title is given}{Give a title by
+ \string\title{...}\space in the preamble of the document.}
+ \fi
+ \fi
+ \if!\@author!\mj@warning@no@line{No \noexpand\author given}\fi
+ \begin{titlepage}%
+ \mj@titlepage
+ \end{titlepage}
+ \newpage
+ \pagestyle{empty}
+
+\begin{center}
+\begin{tabular}{|c|c|p{10cm}|}\hline
+\multicolumn{3}{|c|}{HISTORY OF CHANGES}\\\hline
+VERSION&
+PUBLICATION &
+\multicolumn{1}{c|}{CHANGE}\\
+ &
+DATE&\\\hline
+\thechangetable
+\end{tabular}
+\end{center}
+
+
+
+ \begin{titlepage}
+ \def\thanks##1{\unskip{}}
+ \let\footnoterule\relax \let\footnote\thanks
+ \null\vfil \vskip 60\p@
+ \begin{center}
+ {\LARGE\bfseries \ifx\thetitle\undefined\@title\else\thetitle\fi\par}
+ \vskip 3em
+ \if!\@author!\relax\else
+ {\large \lineskip .75em%
+ \begin{tabular}[t]{c}\@author\end{tabular}\par}
+ \fi
+ \vskip 1.5em
+ {\large \@date\par}
+ \end{center}
+ \renewcommand{\thefootnote}{\fnsymbol{footnote}}
+ \footnotetext[0]{The work described in this report has been funded (in
+part) by the European Union and by the Swiss State Secretariat for Education,
+Research and Innovation in the HORIZON-CL4-2023-HUMAN-01-CNECT call in
+project 101135475 TALER. Views and opinions expressed are however those of the
author(s) only and do not necessarily reflect those of the European Union.
Neither the European Union nor the granting authority can be held responsible
for them.}
+ \vfil\null
+ \end{titlepage}
+ \newpage{\pagestyle{empty}\cleardoublepage}
+ \pagenumbering{roman}
+ \begin{abstract}
+ \thereportabstract\\[1em]
+ {\bf Keywords: }\thereportkeywords
+ \end{abstract}
+ \cleardoublepage
+ \pagenumbering{arabic}
+ \raggedbottom
+ \if!\@shorttitle!\let\@shorttitle\@title\fi
+ \markboth{TALER --- Taxable Anonymous Libre Electronic
Reserves}{\thedoccode\ ---
+ \ifx\thetitle\undefined \@shorttitle\else\thetitle\fi}}
+\else
+ \renewcommand{\maketitle}{%
+ \if!\@title!\mj@error{No title is given}{Give a title by
+ \string\title{...}\space in the preamble of the document.}
+ \fi
+ \if!\@author!\mj@warning@no@line{No \noexpand\author given}\fi
+ \@maketitle}
+\fi
+
+%---Title page for a report/article
+\newcommand{\mj@titlepage}{%
+ \begin{center}
+ \includegraphics[width=0.3\textwidth]{../logo-NGI_TALER_Bold.png}
+% \hfill
+% \includegraphics[width=80pt]{flag-with-h2020.jpg}
+ \end{center}
+
+ \vspace*{0.3cm}
+
+ \begin{center}
+ \Large {\bf TALER}\\[0.2cm]
+ \Large {\bf Taxable Anonymous Libre Electronic Reserves}\\
+ \end{center}
+
+ \vspace*{0.2cm}
+
+ \begin{flushleft}
+ Project number: Horizon Europe 101135475\\
+ \end{flushleft}
+
+ \vspace*{0.5cm}
+
+ \begin{center}
+ {\bfseries\Large \thedoccode\\[3mm]
+ \ifx\thetitle\undefined\@title\else\thetitle\fi}
+ \end{center}
+
+ \vspace*{1cm}
+
+ \begin{center}
+ \begin{tabular}{ll}
+ \if!\theduedate!\else Due date of deliverable: \theduedate & \\\fi
+ Actual submission date: \theactualdate & \\[1em]
+ \if!\thewpcontrib!\else WP contributing to the deliverable:
\thewpcontrib & \\\fi
+ \end{tabular}
+ \end{center}
+
+ \vspace*{0.5cm}
+
+ \begin{flushleft}
+ Start date of project: 1.\ December 2023 \hfill Duration: 3 years\\[1cm]
+ Coordinator: \theleadcontractor
+ \end{flushleft}
+
+ \vspace*{0.2cm}
+ \begin{flushright}
+ \theversion
+ \end{flushright}
+
+ \vspace*{0.5cm}
+
+%%% disemination level %%%
+%
+% put an X next to the dissemination level,
+% if it is public (PU), no modification is needed
+%
+ {\footnotesize
+ \begin{center}
+ \begin{tabular}{|l|l|c|}\hline
+ \multicolumn{3}{|c|}{\bf Project co-funded by the European
+ Commission within Horizon Europe}\\ \hline
+ \multicolumn{3}{|c|}{\bf Dissemination Level}\\ \hline
+ {\bfseries PU} & Public &
+ \def\mj@tmp{PU}\ifx\thedissemination\mj@tmp X\fi\\ \hline
+ {\bfseries PP} & Restricted to other programme participants
+ (including the Commission services) &
+ \def\mj@tmp{PP}\ifx\thedissemination\mj@tmp X\fi\\ \hline
+ {\bfseries RE} & Restricted to a group specified by the consortium
+ (including the Commission services) &
+ \def\mj@tmp{RE}\ifx\thedissemination\mj@tmp X\fi\\ \hline
+ {\bfseries CO} & Confidential, only for members of the consortium
+ (including the Commission services) &
+ \def\mj@tmp{CO}\ifx\thedissemination\mj@tmp X\fi\\ \hline
+ \end{tabular}
+ \end{center}}}
+%%----------------- (end maketitle and titlepage) ---------------------
+
+
+\RequirePackage{graphicx}
+\RequirePackage{amsmath}
+\numberwithin{table}{section}
+\numberwithin{figure}{section}
+
+\endinput
+%%
+%% End of file 'taler.cls'.
diff --git a/doc/usenix-security-2025/paper/taler.cls
b/doc/usenix-security-2025/paper/taler.cls
new file mode 100644
index 0000000..c183d04
--- /dev/null
+++ b/doc/usenix-security-2025/paper/taler.cls
@@ -0,0 +1,322 @@
+\def\fileversion{1.7}
+\def\filedate{2015/03/31}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%
+% CLASS pqcrypto.cls
+%
+%---------------------------------------------------------------------
+%
+% LaTeX class for TALER deliverable in LaTeX report/article style
+% (based on the ECRYPT and CACE and ... deliverable templates)
+%
+% \documentclass{taler}
+%
+% uses a report style.
+%
+% \documentclass[article]{taler}
+%
+% uses an article style.
+%
+% version 1.8, 2023.12.01, T. Lange (converted from PQCRYPTO to TALER)
+% version 1.7, 2015.03.31, T. Lange (converted from PUFFIN to PQCRYPTO)
+% version 1.6, 2012.06.11, D. J. Bernstein (converted from CACE to PUFFIN)
+% version 1.5, 21-2-08, Guido Blady (added \wpcontrib and \cacekeywords
commands)
+% version 1.4, 20-2-08, Guido Blady (converted to CACE deliverable template)
+% version 1.3, 5-12-07, Christian Cachin (removed broken PDF graphics opt)
+% version 1.2, 2-2-06, Christian Cachin (added \ecryptabstract command)
+% version 1.1, 14-2-05, Marc Joye
+% version 1.0, 27-1-05, Antoon Bosselaers & Christian Cachin
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\NeedsTeXFormat{LaTeX2e}
+\typeout{^^J *** TALER Class \fileversion\space for LaTeX2e ***^^J}
+\ProvidesClass{taler}[\filedate]
+
+%%------------------------ (class options) ----------------------------
+\newcommand\mj@class{}
+\newif\ifmj@report\mj@reporttrue
+\DeclareOption{article}{\mj@reportfalse\renewcommand\mj@class{article}}
+\DeclareOption{report}{\renewcommand\mj@class{report}}
+
+\newcommand\mj@papersize{}
+\DeclareOption{a4paper}{\renewcommand\mj@papersize{a4}}
+\DeclareOption{a5paper}{\renewcommand\mj@papersize{a5}}
+\DeclareOption{b5paper}{\renewcommand\mj@papersize{b5}}
+\DeclareOption{letterpaper}{\renewcommand\mj@papersize{letter}}
+\DeclareOption{legalpaper}{\renewcommand\mj@papersize{legal}}
+\DeclareOption{executivepaper}{\renewcommand\mj@papersize{executive}}
+
+\newcommand\mj@ptsize{}
+\DeclareOption{10pt}{\renewcommand\mj@ptsize{0}}
+\DeclareOption{11pt}{\renewcommand\mj@ptsize{1}}
+\DeclareOption{12pt}{\renewcommand\mj@ptsize{2}}
+
+\newcommand\mj@titlep@ge{}
+\DeclareOption{titlepage}{\renewcommand\mj@titlep@ge{titlepage}}
+\DeclareOption{notitlepage}{\renewcommand\mj@titlep@ge{notitlepage}}
+
+\newcommand\mj@twoside{}
+\DeclareOption{twoside}{\renewcommand\mj@twoside{twoside}}
+\DeclareOption{oneside}{\renewcommand\mj@twoside{oneside}}
+
+\ExecuteOptions{report,a4paper,11pt,titlepage,twoside}
+\DeclareOption*{\PassOptionsToClass{\CurrentOption}{\mj@class}}
+\ProcessOptions
+\LoadClass[\mj@papersize paper,1\mj@ptsize
pt,\mj@titlep@ge,\mj@twoside]{\mj@class}
+%---Chapters automatically start on a new right-hand page
+\ifmj@report\@openrighttrue\fi
+%%---------------------- (end class options) --------------------------
+
+
+
+%%------------------------ (page settings) ----------------------------
+\IfFileExists{a4wide.sty}{\RequirePackage{a4wide}}{}
+\IfFileExists{url.sty}{\RequirePackage{a4wide}}{\let\url\texttt}
+\setlength\arraycolsep{1.4\p@}
+\setlength\tabcolsep{1.4\p@}
+\def\vtopx{\hsize9cm\vtop}
+\def\marginnote#1{\marginpar{\footnotesize #1}}
+\pagestyle{myheadings}
+%%---------------------- (end page settings) --------------------------
+
+
+
+%%---------------------------- (macros) -------------------------------
+\newcommand{\F}{{\bfseries F}}
+\newcommand{\complet}{{\bfseries TO BE COMPLETED}}
+\renewcommand{\pmod}[1]{\allowbreak \mkern 10mu({\operator@font mod}\,\,#1)}
+%%-------------------------- (end macros) -----------------------------
+
+
+
+%%------------------------- (user options) ----------------------------
+%% \title[...]{...} (mandatory!!!)
+%% \author{...}
+%% \doccode{...}
+%% \leadcontractor{...}
+%% \duedate{...}
+%% \actualdate{...}
+%% \version{...}
+%% \dissemination{...}
+%% \reportabstract{...}
+
+\long\def\title{\@ifnextchar [{\mj@title}{\mj@title[]}}
+\def\mj@title[#1]#2{\gdef\@shorttitle{#1}\gdef\@title{#2}}
+\newcommand{\doccode}[1]{\gdef\thedoccode{#1}}
+\newcommand{\leadcontractor}[1]{\gdef\theleadcontractor{#1}}
+\newcommand{\duedate}[1]{\gdef\theduedate{#1}}
+\newcommand{\wpcontrib}[1]{\gdef\thewpcontrib{#1}}
+\newcommand{\actualdate}[1]{\gdef\theactualdate{#1}}
+\newcommand{\version}[1]{\gdef\theversion{#1}}
+\newcommand{\dissemination}[1]{\gdef\thedissemination{#1}}
+\renewcommand{\date}[1]{\gdef\@date{\let\today\mjtoday #1}}
+\newcommand{\reportabstract}[1]{\gdef\thereportabstract{#1}}
+\newcommand{\reportkeywords}[1]{\gdef\thereportkeywords{#1}}
+\newcommand{\changetable}[1]{\gdef\thechangetable{#1}}
+
+
+\edef\mjtoday{%
+ \number \day.\space%
+ \ifcase \month \or January\or February\or March \or April\or May\or
+ June\or July\or August\or September\or October\or November\or
+ December\fi\space \number \year}
+\global\let\today\mjtoday
+
+\def\@title{\@empty}
+\def\@author{\@empty}
+\def\@shorttitle{\@empty}
+\def\thedoccode{D.XXX.Y}
+\def\theleadcontractor{\\Eindhoven University of Technology\\
+{\tt www.taler.net/eurotaler}}
+\def\theduedate{\@empty}
+\def\theactualdate{\mjtoday}
+\def\thewpcontrib{\@empty}
+\def\theversion{Revision 1.0}
+\def\thedissemination{PU}
+\def\@date{\theactualdate\\ \theversion}
+\def\thereportabstract{\@empty}
+\def\thereportkeywords{\@empty}
+\def\thechangetable{\@empty}
+%%----------------------- (end user options) --------------------------
+
+
+
+%%---------------------- (warnings and errors) ------------------------
+\newcommand{\mj@warning}[1]{%
+ \GenericWarning {\space \space \space \@spaces \@spaces \@spaces }%
+ {TALER Warning: #1}}
+%--- Warning without line number
+\newcommand{\mj@warning@no@line}[1]{%
+ \GenericWarning {\space \space \space \@spaces \@spaces \@spaces }%
+ {TALER Warning: #1\@gobble}}
+\newcommand{\mj@error}[2]{%
+ \GenericError {\space \space \space \@spaces \@spaces \@spaces }%
+ {TALER Error: #1}{See the documentation for explanation.}{#2^^J}}
+%%-------------------- (end warnings and errors) ----------------------
+
+
+
+%%------------------- (maketitle and titlepage) -----------------------
+
+\if@titlepage
+ \renewcommand{\maketitle}{%
+ \ifx\thetitle\undefined
+ \if!\@title!\mj@error{No title is given}{Give a title by
+ \string\title{...}\space in the preamble of the document.}
+ \fi
+ \fi
+ \if!\@author!\mj@warning@no@line{No \noexpand\author given}\fi
+ \begin{titlepage}%
+ \mj@titlepage
+ \end{titlepage}
+ \newpage{\pagestyle{empty}\cleardoublepage}
+ \begin{titlepage}
+ \def\thanks##1{\unskip{}}
+ \let\footnoterule\relax \let\footnote\thanks
+ \null\vfil \vskip 60\p@
+ \begin{center}
+ {\LARGE\bfseries \ifx\thetitle\undefined\@title\else\thetitle\fi\par}
+ \vskip 3em
+ \if!\@author!\relax\else
+ {\large \lineskip .75em%
+ \begin{tabular}[t]{c}\@author\end{tabular}\par}
+ \fi
+ \vskip 1.5em
+ {\large \@date\par}
+ \end{center}
+ \renewcommand{\thefootnote}{\fnsymbol{footnote}}
+ \footnotetext[0]{The work described in this report has been funded (in
+part) by the European Union in the HORIZON-CL4-2023-HUMAN-01-CNECT call in
+project 101135475 TALER. Views and opinions expressed are however those of the
author(s) only and do not necessarily reflect those of the European Union.
Neither the European Union nor the granting authority can be held responsible
for them.}
+ \vfil\null
+ \end{titlepage}
+ \newpage
+ \pagestyle{empty}
+
+\begin{center}
+\begin{tabular}{|c|c|p{12cm}|}\hline
+\multicolumn{3}{|c|}{HISTORY OF CHANGES}\\\hline
+VERSION&
+PUBLICATION &
+\multicolumn{1}{c|}{CHANGE}\\
+ &
+DATiE&\\\hline
+\thechangetable
+\end{tabular}
+\end{center}
+
+\newpage
+
+ \pagenumbering{roman}
+ \begin{abstract}
+ \thereportabstract\\[1em]
+ {\bf Keywords: }\thereportkeywords
+ \end{abstract}
+ \cleardoublepage
+ \tableofcontents
+ \listoffigures
+ \listoftables
+ \global\let\tableofcontents\relax
+ \cleardoublepage
+ \pagenumbering{arabic}
+ \raggedbottom
+ \if!\@shorttitle!\let\@shorttitle\@title\fi
+ \markboth{TALER --- Taxable Anonymous Libre Electronic
Reserves}{\thedoccode\ ---
+ \ifx\thetitle\undefined \@shorttitle\else\thetitle\fi}}
+\else
+ \renewcommand{\maketitle}{%
+ \if!\@title!\mj@error{No title is given}{Give a title by
+ \string\title{...}\space in the preamble of the document.}
+ \fi
+ \if!\@author!\mj@warning@no@line{No \noexpand\author given}\fi
+ \@maketitle}
+\fi
+
+%---Title page for a report/article
+\newcommand{\mj@titlepage}{%
+ \begin{center}
+ \includegraphics[width=0.3\textwidth]{../logo-NGI_TALER_Bold.png}
+% \hfill
+% \includegraphics[width=80pt]{flag-with-h2020.jpg}
+ \end{center}
+
+ \vspace*{0.3cm}
+
+ \begin{center}
+ \Large {\bf TALER}\\[0.2cm]
+ \Large {\bf Taxable Anonymous Libre Electronic Reserves}\\
+ \end{center}
+
+ \vspace*{0.2cm}
+
+ \begin{flushleft}
+ Project number: Horizon Europe 101135475\\
+ \end{flushleft}
+
+ \vspace*{0.5cm}
+
+ \begin{center}
+ {\bfseries\Large \thedoccode\\[3mm]
+ \ifx\thetitle\undefined\@title\else\thetitle\fi}
+ \end{center}
+
+ \vspace*{1cm}
+
+ \begin{center}
+ \begin{tabular}{ll}
+ \if!\theduedate!\else Due date of deliverable: \theduedate & \\\fi
+ Actual submission date: \theactualdate & \\[1em]
+ \if!\thewpcontrib!\else WP contributing to the deliverable:
\thewpcontrib & \\\fi
+ \end{tabular}
+ \end{center}
+
+ \vspace*{0.5cm}
+
+ \begin{flushleft}
+ Start date of project: 1.\ December 2023 \hfill Duration: 3 years\\[1cm]
+ Coordinator: \theleadcontractor
+ \end{flushleft}
+
+ \vspace*{0.2cm}
+ \begin{flushright}
+ \theversion
+ \end{flushright}
+
+ \vspace*{0.5cm}
+
+%%% disemination level %%%
+%
+% put an X next to the dissemination level,
+% if it is public (PU), no modification is needed
+%
+ {\footnotesize
+ \begin{center}
+ \begin{tabular}{|l|l|c|}\hline
+ \multicolumn{3}{|c|}{\bf Project co-funded by the European
+ Commission within Horizon Europe}\\ \hline
+ \multicolumn{3}{|c|}{\bf Dissemination Level}\\ \hline
+ {\bfseries PU} & Public &
+ \def\mj@tmp{PU}\ifx\thedissemination\mj@tmp X\fi\\ \hline
+ {\bfseries PP} & Restricted to other programme participants
+ (including the Commission services) &
+ \def\mj@tmp{PP}\ifx\thedissemination\mj@tmp X\fi\\ \hline
+ {\bfseries RE} & Restricted to a group specified by the consortium
+ (including the Commission services) &
+ \def\mj@tmp{RE}\ifx\thedissemination\mj@tmp X\fi\\ \hline
+ {\bfseries CO} & Confidential, only for members of the consortium
+ (including the Commission services) &
+ \def\mj@tmp{CO}\ifx\thedissemination\mj@tmp X\fi\\ \hline
+ \end{tabular}
+ \end{center}}}
+%%----------------- (end maketitle and titlepage) ---------------------
+
+
+\RequirePackage{graphicx}
+\RequirePackage{amsmath}
+\numberwithin{table}{section}
+\numberwithin{figure}{section}
+
+\endinput
+%%
+%% End of file 'taler.cls'.
diff --git a/doc/usenix-security-2025/paper/tax-authority.png
b/doc/usenix-security-2025/paper/tax-authority.png
new file mode 100644
index 0000000..8d4343e
Binary files /dev/null and b/doc/usenix-security-2025/paper/tax-authority.png
differ
diff --git a/doc/usenix-security-2025/paper/technicaldesign.tex
b/doc/usenix-security-2025/paper/technicaldesign.tex
new file mode 100644
index 0000000..7c771bb
--- /dev/null
+++ b/doc/usenix-security-2025/paper/technicaldesign.tex
@@ -0,0 +1,452 @@
+\newcommand{{\pub}}{{\sf pub}}
+\newcommand{{\priv}}{{\sf priv}}
+\newcommand{{\DI}}{{\sf DI}}
+\newcommand{{\UDI}}{{\sf UDI}}
+\newcommand{{\sign}}{{\sf sign}}
+\newcommand{{\verify}}{{\sf verify}}
+\newcommand{{\blind}}{{\sf blind}}
+\newcommand{{\unblind}}{{\sf unblind}}
+
+\section{Protocol Description}\label{technical}
+
+The previous section identified several requirements and desired features
+that a donation system must or should satisfy.
+The technically most challenging part is to permit donors
+to stay anonymous towards the charity they are donating to and to keep private
+from the tax authorities which charities they donated to.
+The protocol presented in this section addresses this
+challenge and all of the design goals from
+Section~\ref{sec:designgoals}. In
+Section~\ref{sec:discussionfeatures} we discuss how
+the various optional capabilities could be achieved on
+top of this core protocol design.
+
+%Some of these are
+%contradictory and any deployment needs to prioritize compliance with local
+%laws and regulations.
+% CG: not sure they are actually contradictory, modulo if
+% you are strict on pseudonymity vs. anonymity; but even
+% here you're only linkable across donations to the same
+% charity, which is probably OK.
+
+The Donau protocol, developed for this project by Johannes Casaba and Lukas
+Matyja under the supervision of Emmanuel Benoist and Christian Grothoff,
+provides a solution for both of these challenges.
+This section follows closely and often is a verbatim reproduction of the
+thesis~\cite{donau} by Casaba and Matyja. We thank them for their significant
+contributions.
+
+This section provides a technical overview of the Donau protocol, starting with
+some cryptographic background followed by the setup and usage.
+
+% The first section introduces some notation and definitions used later on in
the protocol description.
+% Concepts from cryptography are also explained when necessary.
+%
+ \subsection{Background \& Terminology}\label{notation_and_definitions}
+ This section gives an informal introduction to some concepts from cryptography
+which are used later in the report.
+
+ \begin{itemize}
+ \item \textbf{Cryptographic Hash Function}
+ A cryptographic hash function $H$ is a function that takes as input an
arbitrarily
+long bit string
+ and returns a fixed-length output string, which satisfies some security
+requirements. In formulas
+$$H: \{0,1\}^* \rightarrow \{0,1\}^n, m \mapsto h = H(m).$$
+The function $H$ should provide preimage resistance, that means that
+it should be infeasible to find an input that hashes to a given output. It
+should also provide second-preimage resistance, that means that it should be
+infeasible to find a second input that maps to the same output as a given
input.
+Even more restricting, it should provide collision resistance, meaning that it
+should be infeasible to find two inputs that hash to the same output (without
+any other restriction).
+
+ Sometimes a hash function gets used in a scenario where the natural input
+values come from a small, easily guessable set, like passwords or PINs.
+In this scenario an attacker could break preimage resistance by just iterating
+through all possible inputs to find the matching one and, worse, could even
+store all resulting hash values in a big table for instant preimage lookups for
+all users. One partial fix is to {\bf salt} the hash, i.e., to add a random
+suffix or prefix to the input before hashing it. Applications then need to
+store the salt as well. If the salt can be kept private this stops the simple
+preimage attacks, otherwise it at least requires the attacker to try all inputs
+{\em per targeted hash}. We write a {\bf salted hash} as $h = H(m, s)$, where
+$s$ is the salt value.
+
+ \item \textbf{Digital Signatures}
+
+ A digital signature is a cryptographic scheme for authenticating a
message or document, analogous to a handwritten signature.
+ A signer creates a public/private keypair.
+ The private signing key is used to generate a signature on a message.
+ The public key is distributed, and can be used by anybody to verify the
authenticity of the signature.
+ A signature scheme is secure if, among other things, the private key
cannot be computed from the public key and if
+ nobody can generate a signature that verifies for some message under a
+public key if they do not have access to the matching private key.
+
+ \item \textbf{Blind Signature}
+
+ A \textbf{blind signature} is a type of digital signature where the
+signing party signs a so-called blinded message. The party requesting the
signature
+hides the true message with a {\bf blinding factor}, which only they know.
+Signature schemes that support blind signatures are constructed in such a way
+that one can compute a signature that is valid on the original (not blinded)
+message from the blind signature and the blinding factor.
+Requirements on the blind signature scheme are that the
+signer does not learn anything about the message they are signing and cannot
+link the unblinded signature to the blind one they signed.
+
+ The {\bf blinding} operation requires the message $m$ to blind, the
+blinding factor $b$ and the public key $K_x^{\pub}$ of the party issuing the
+blind signature, written as $\overline{m} = \blind(m, b, K_x^{\pub})$.
+We write the {\bf unblinding} operation as
+$\beta = \unblind(\overline{\beta}, b, K_x^{\pub})$,
+where $\overline{\beta}$ is the value to unblind, $b$ the blinding factor to
+apply and $K_x^{\pub}$ the public key that was used for signing.
+
+ \end{itemize}
+
+\subsection{Key generation and initial
setup}\label{key_generation_and_initial_setup}
+
+Taler makes heavy use of blind signatures to issue coins; in the context of
+donations, blind signatures are issued by the donation authority Donau.
+
+\subsubsection{Donau key generation}\label{donau_key_generation}
+\begin{enumerate}
+\item The Donau generates an Ed25519~\cite{DBLP:journals/jce/BernsteinDLSY12}
keypair
+ $(D^{\pub}$, $D^{\priv})$, called the {\bf Donau Key}, for digital
signatures.
+ \item The Donau also generates a set of \textbf{Donation Unit} keypairs
+$(K_x^{\pub}, K_x^{\priv})$ for blind signatures, corresponding to different
+currency denominations $x$ that a donation can be composed of.
+The blind signature scheme used is either blind
+RSA~\cite{DBLP:conf/crypto/Chaum82} or blind
+Schnorr~\cite{DBLP:conf/eurocrypt/FuchsbauerPS20}.
+\end{enumerate}
+
+\subsubsection{Charity key generation}\label{charity_key_generation}
+\begin{enumerate}
+ \item Each charity generates its own Ed25519 charity key $( C^{\pub},
+C^{\priv} )$.
+ \item The charity also fetches the Donation Unit public keys from the Donau.
+ \item The charity transmits its public key $C^{\pub}$ and its requested
+yearly donation limit (if any) to the party controlling the Donau (e.g the
+local tax authority) using a authenticated channel.
+ \item The party in charge of Donau administration (usually the relevant tax
+authority) ensures that the charity is authentic and a legally recognized
+charitable organization. After successful verification, the charity public key
+$C^{\pub}$ together with its requested yearly donation limit (if any)
+are registered in the Donau database.
+\end{enumerate}
+
+\subsubsection{Donor Identifier generation}
+Each donor generates a personal \textbf{Donor Identifier} by computing a
+salted hash of their taxpayer ID.
+They use this Donor Identifier value for each donation they make and later to
+receive a donation receipt from the Donau.
+
+The donor computes their Donor Identifier $\DI$ as
+\begin{align*}
+ \DI = H(\texttt{TAXID}, S)
+\end{align*}
+where $S$ is a random salt and {\tt TAXID} is their taxpayer ID.
+The donor stores the salt $S$ along with their $\DI$.
+They need to use the salt to link the Donation Identifier to their tax ID and
claim
+the tax benefits for their donation. The use of the salt means the $\DI$ cannot
+be linked to the donor by anybody without $S$, even if they know {\tt TAXID}.
+
+
+\subsection{Donating to a charity}\label{donating_to_a_charity}
+% \subsection{Donor donates to charity and transmits \textbf{Unique Donor
identifiers} (future donation receipts)}
+When a donor wishes to donate to a charity, they first retrieve the Donau's
Donation Unit
+public keys $K_x^{\pub}$ for the current year.
+The donor then represents their donation as a sum of the Donation Units
offered by the Donau.
+
+\emph{Example: Assuming the Donau publishes the Donation units $\{1,2,4,8\}$,
a donation of $7$ would be split into 1 unit each of the values $4$, $2$ and
$1$.}
+
+For each necessary Donation Unit the donor generates a \textbf{Unique Donor
+Identifier (UDI)} by appending a random nonce to the value $\DI$.
+If multiple instances of the same Donation Unit are needed to represent the
target sum, the donor creates a different nonce for each instance of that
Donation Unit.
+The donor must remember all UDIs.
+
+\emph{In our example, there are $3$ Unique Donor Identifiers needed to
represent the donated value of $7$. We can write them as:}
+\begin{align*}
+ u_1 &= ( \DI, N_1) \\
+ u_2 &= ( \DI, N_2) \\
+ u_3 &= ( \DI, N_3)
+\end{align*}
+{\em where $\DI$ is the Donor Identifier from above, and the $N_i$s are
nonces.}
+
+Next the donor blinds the Unique Donor Identifiers using a unique blinding
factor for each one.
+This hides the information in the UDIs from third parties, including the Donau
+and charity, and protects against linkability. The result is a set of {\bf
Blinded Unique Donor Identifiers (BUDIs)}.
+
+{\em In our example, the Blinded Unique Donor Identifiers would be}
+\begin{align*}
+ \overline u_1 &= \blind (u_1, b_1, K_1^{\pub}) \\
+ \overline u_2 &= \blind (u_2, b_2, K_2^{\pub}) \\
+ \overline u_3 &= \blind (u_3, b_3, K_4^{\pub})
+\end{align*}
+{\em with random blinding factors $b_1$, $b_2$, and $b_3$}.
+
+So far, the \textbf{Blinded Unique Donor Identifiers} do not carry information
about their monetary values.
+The \emph{intended effective value is indicated} by grouping each Unique Donor
Identifier with
+the hash of its respective Donation Unit public key $K^{\pub}_x$.
+We call this pair a \textbf{Blinded Unique Donor Identifier Key Pair}
(\textbf{BKP}).
+It is only the \emph{intended effective} value because their value is zero
until they are signed by the Donau.
+Note that they must be signed with the matching Donation Unit key as the
+blinding and unblinding operations rely strongly on the public key.
+
+
+{\em The BKPs for our example are:}
+\begin{align*}
+ \overline \mu_1 &= ( \overline u_1, h({K^{\pub}_1}) ) \\
+ \overline \mu_2 &= ( \overline u_2, h({K^{\pub}_2}) ) \\
+ \overline \mu_3 &= ( \overline u_3, h({K^{\pub}_4}) )
+\end{align*}
+
+
+These individual BKPs are then put in an array $\vec{\mu}$ of BKPs.
+
+{\em Here }
+\begin{align*}
+ \vec{\mu} &= ( \overline \mu_1,
+ \overline \mu_2,\overline \mu_3
+ )
+\end{align*}
+
+The donor sends this array to the charity along with the corresponding
+payment.
+As stated in the introduction, the payment mechanism is irrelevant for the
+donation protocol.
+
+\subsection{Charity receives donation}\label{charity_receives_donation}
+Upon receiving the array $\vec{\mu}$ of BKPs and the corresponding payment
from the donor,
+the charity verifies that the total amount claimed in the BKPs
+(based on the Donation Unit public key hashes $h(K_x^{\pub})$) is less than or
+equal to the amount they received in the payment.
+The charity then signs the array of BKPs with its Ed25519 Charity Key.
+That is, it computes
+\begin{align*}
+ \sigma_c = \sign(\vec{\mu}, C^{\priv})
+\end{align*}
+The charity sends the array $\vec{\mu}$ of BKPs and their signature $\sigma_c$
to the Donau to generate a receipt.
+
+\subsection{Donau generates donation
receipt}\label{donau_creates_donation_receipt}
+When the Donau receives a signed set of BKPs from a charity, it verifies the
charity's signature.
+It then checks that no legal restrictions, such as a possible yearly donation
limit for the charity, is being violated.
+If not, the Donau increments its record of the charity's total receipts by the
+total amount of the donation, i.e., the sum of the denominations used in the
+BKPs.
+The Donau then blindly signs all BUDIs using the Donation Unit private keys
+$K_x^{\priv}$
+that correspond to the public keys hashed in the BKPs.
+
+{\em In our example, the Donau blindly signs the three BUDIs submitted by the
charity}
+\begin{align*}
+ \overline{\beta_1} = \blind\_\sign(\overline u_1, K_1^{\priv}) \\
+ \overline{\beta_2} = \blind\_\sign(\overline u_2, K_2^{\priv}) \\
+ \overline{\beta_3} = \blind\_\sign(\overline u_3, K_4^{\priv})
+\end{align*}
+
+These signatures constitute a blinded donation receipt from the Donau, and the
Donau sends these back to the charity,
+which in turn forwards them to the donor.
+
+\subsection{Donor receives donation
receipt}\label{donor_receives_donation_receipt}
+Upon receiving the blinded donation receipt from the Donau via the charity,
+the donor verifies the blind signatures over the BUDIs.
+If they verify, the donor then unblinds them to obtain signatures over the
original UDIs.
+These UDIs, their unblinded signatures, and their respective hashed Donation
Unit public keys
+constitute a collection of donation receipts.
+These donation receipts are stored on the donor's device.
+
+{\em In our example: the donor unblinds the Donau signatures
$\overline{\beta_1}, \overline{\beta_2}, \overline{\beta_3}$, obtaining:}
+\begin{align*}
+ \beta_1 &= \unblind(\overline{\beta_1}, b_1, K_1^{\pub}) \\
+ \beta_2 &= \unblind(\overline{\beta_2}, b_2, K_2^{\pub}) \\
+ \beta_3 &= \unblind(\overline{\beta_3}, b_3, K_4^{\pub})
+\end{align*}
+{\em The donor then creates the final Donation Receipts:}
+\begin{align*}
+ r_1 &= ( \UDI_1, \beta_1, h(K_1^{\pub}) ) \\
+ r_2 &= ( \UDI_2, \beta_2, h(K_2^{\pub}) ) \\
+ r_3 &= ( \UDI_3, \beta_3, h(K_4^{\pub}) )
+\end{align*}
+
+\subsection{Donor requests an annual donation statement from
Donau}\label{donor_requests_a_donation_statement_from_the_donau}
+In order for the donor to claim a tax deduction,
+the donor needs to obtain a final \textbf{Donation Statement} which can be
sent to the tax authority.
+The donor sends their saved donation receipts $\{r_1, \ldots, r_k\}$,
accumulated throughout the year, to the Donau.
+This can be done multiple times during the year, but the receipts are not
automatically in order to achieve
+\emph{unlinkability} between the \emph{issuance} of the receipts (which
happens at the time of donation) and their \emph{submission} for the Donation
Statement.
+
+Remember that each $\UDI$ is the concatenation of the donor identifier $\DI$
and
+a random nonce, i.e., they all start with the same $\DI$.
+
+Once the Donau receives the donor's donation receipts, it checks that for each
receipt:
+\begin{itemize}
+ \item the public key $K_x^{\pub}$ is known.
+ \item the signature $\beta$ is correct using the corresponding public key
+$K_x^{\pub}$.
+ \item the Donor Identifier $\DI$ is the same in all receipts.
+% (With multiple wallets each wallet must simply obtain a separate Donation
Statement)
+ \item the nonces are unique and were not submitted before by the same donor,
+identified as $\DI$.
+\end{itemize}
+
+Importantly, the Donau does not see signatures of the charities the donor
+donated to, so it does not know where the donor spent money.
+They also only see a collection of common denominations, so they are unable to
correlate total donation amounts per charity.
+Finally, the receipts are unblinded, so the Donau has never seen these
signatures before.
+This makes the receipts unlinkable from when they were originally signed by
the Donau.
+
+The Donau then generates a signature over the total \texttt{amount} of all
receipts, the current \texttt{year} and the Donor Identifier.
+This results in a final signature called the \textbf{Donation Statement},
which the Donau returns to the donor:
+\begin{align*}
+ \sigma_s = \sign(( \DI, \textsf{amount}_{\sf Total}, \textsf{year}) ),
+D^{\priv})
+\end{align*}
+
+\subsection{Donor sends final statement to a
validator}\label{donor_sends_final_statement_to_a_validator}
+Finally, to claim their deduction, the donor includes their donation statement
+in their tax declaration. The implementation detailed in the next section
+chooses to represent this information as a QR-Code
+\begin{align*}
+ \texttt{QR} = (\texttt{TAXID}, S, \textsf{year}, \textsf{amount}_{\sf
+Total}, \sigma_s).
+\end{align*}
+Other representations and integration into software for filing tax returns are
+possible. It is relevant that {\tt TAXID} and salt $S$ are included to
+recompute the donation identifier $\DI$ while linking the donation receipt to
+the tax ID.
+
+The validator at the tax office verifies the \textbf{Donation Statement
Signature} $\sigma_s$.
+\begin{align*}
+ \verify((H({\tt TAXID},S), \textsf{amount}_{\sf Total}, \textsf{year})
),\sigma_s,
+D^{\pub})
+\end{align*}
+
+
+% Putting unused defs from the thesis here in case they're needed for some
reason later. don't want to recopy
+
+% \item \textbf{Donation Unit Key generation}
+% \begin{displaymath}
+% ( K_x^{\pub}, K_x^{\priv} ) := Keygen^B(\omega)
+% \end{displaymath}
+% where $\omega$ is a source of entropy. The resulting key pair represents
+% a \textbf{Donation Unit}. The result is a public key $K_x^{\pub}$ and
+% private key $K_x^{\priv}$. The equivalent used in Taler system is a
\texttt{Denomination}.
+%
+% \item \textbf{Donau Key generation}
+% \begin{displaymath}
+% ( D^{\pub}, D^{\priv} ) := Keygen^D(\omega)
+% \end{displaymath}
+% where $D^{\pub}$ and $D^{\priv}$ are the respective public and private
Donau keys.
+%
+% \item \textbf{Charity Key generation}
+% \begin{displaymath}
+% ( C^{\pub}, C^{\priv} ) := Keygen^C(\omega)
+% \end{displaymath}
+% where $C^{\pub}$ and $C^{\priv}$ are the respective public and private
Charity keys.
+%
+% \item \textbf{Donation Unit (DU)}
+% \begin{displaymath}
+% ( K_x^{\pub}, K_x^{\priv} )
+% \end{displaymath}
+% A Donation Unit consists of a public and private key where $x$ is the
associated value (e.g. 2 EUR).
+%
+% \item \textbf{Donor Identifier (DI)}
+% \begin{displaymath}
+% i := H(\texttt{TAXID}, S)
+% \end{displaymath}
+% where $S$ is a random salt with sufficient entropy to prevent guessing
attacks to invert the hash function.
+%
+% \item \textbf{Unique Donor Identifier (UDI)}
+% \begin{displaymath}
+% u := ( i, N )
+% \end{displaymath}
+% where $N$ is a high-entropy nonce to make the resulting hash
\textbf{unique} per donation.
+%
+% \item \textbf{Blinded Unique Donor Identifier (BUDI)}
+% \begin{displaymath}
+% \overline{u} := \blind( u, b, K_x^{\pub} )
+% \end{displaymath}
+% A \textbf{BUDI} is the result of blinding a Unique Donor Identifier $u$
+% where $b$ is the blinding factor and $K_x^{\pub}$ the associated Key.
The blinding is done to protect the privacy of the donor.
+%
+% \item \textbf{Blinded Unique Donor Identifier Key Pair (BKP)}
+% \begin{displaymath}
+% p := ( \overline{u}, H(K_x^{\pub}) )
+% \end{displaymath}
+% A \textbf{Blinded Unique Donor Identifier Key Pair} is the result of
+% adding the corresponding hash of the \textbf{Donation Unit} public key to
+% the \textbf{Blinded Unique Donor Identifier} $\overline{u}$ where
+% $H(K_x^{\pub})$ is the hash of the \textbf{Donation Unit} public key.
+
+% \item \textbf{Digital Signatures}
+% A digital signature
+% \begin{itemize}
+% \item \textbf{Normal signing (e.g. EdDSA):}
+% \begin{align}
+% \fbox{$s := sign(m,k^{\priv})$}
+% \end{align}
+% where $m$ is a message and $k^{\priv}$ is the private key used to sign
+% the message, for example the Donau private key $D^{\priv}$ or the
+% Charity private key $C^{\priv}$.\\
+
+% Applications:
+% \begin{itemize}
+% \item Signatures over a \textbf{Blinded Unique Donor Identifier Key
Pair}:
+% \begin{align}
+% \fbox{$\vec{\mu}_s := sign(\vec{p},C^{\priv})$}
+% \end{align}
+% where $H(K_x^{\pub})$ indicates which \textbf{Donation Unit} key
should be used by the Donau to sign the resulting \textbf{Donation Receipt}.
Thus, this hash carries the information about the exact value, the final
Donation Receipt should carry.
+%
+% A charity signs a collection of \textbf{Blinded Unique Donor
Identifier Key Pairs} before transferring them to the Donau to issue the
\textbf{Donation Receipts}
+%
+% \item Generation of the \textbf{Donation Statement}
+% \end{itemize}
+%
+% \item \textbf{Blind signing(e.g. RSA/CS):}
+% \begin{align}
+% \fbox{$\overline{\beta} := \blind\_sign(\overline{u},K_x^{\priv})$}
+% \end{align}
+% where $\overline{u}$ is a blinded value and $K_x^{\priv}$ is the
private key used to blind sign the message.\\
+%
+% Application:
+% \begin{itemize}
+% \item The Donau blind signs \textbf{Blinded Unique Donor
Identifiers} received from the Charity with the private key matching the public
key in the received \textbf{Blinded Unique Donor Identifier Key Pair}
+% \end{itemize}
+% \end{itemize}
+%
+% \item \textbf{Verify Functions}
+%
+% To verify the signatures $m$ corresponds to the message and $s$ to the
signature:
+%
+% \begin{itemize}
+% \item \textbf{normal verify}
+% \begin{displaymath}
+% verify(m,s, P^{\pub})
+% \end{displaymath}
+% where $P^{\pub}$ can be the Donau public key $D^{\pub}$ or Charity public
+% key $C^{\pub}$.
+%
+% \item \textbf{blind verify}
+% \begin{displaymath}
+% verify\_blind(m,s,K_x^{\pub})
+% \end{displaymath}
+% verify a signature that was made blind and made with a Donation Unit
+% private key $K_x^{\priv}$.
+% \end{itemize}
+%
+% \item \textbf{Donation Receipt}
+% \begin{displaymath}
+% r := ( u, \beta, H(K_x^{\pub}) )
+% \end{displaymath}
+% where $\beta$ is the unblinded signature sent to the Donau to get the
\textbf{Donation Statement}.
+%
+% \item \textbf{Donation Statement Signature}
+% \begin{displaymath}
+% \sigma := sign(( i, \Sigma{\vec{r}}, \texttt{Year}), D^{\priv})
+% \end{displaymath}
+% The \textbf{Donation Statement Signature} is the signature over the sum
(amount donated) of all the \textbf{Donation Receipts} $\Sigma{\vec{r}}$, that
a donor has received from donating throughout the year where $i$ is the
\textbf{Donor Identifier}. The \textbf{Donation Statement} itself includes all
sign values and the signature itself.
+%
+% These \textbf{Donation Statement Signatures} attest the amount donated
in a particular year by a specific donor.
diff --git a/doc/usenix-security-2025/paper/usenix-2020-09.sty
b/doc/usenix-security-2025/paper/usenix-2020-09.sty
new file mode 100644
index 0000000..435d296
--- /dev/null
+++ b/doc/usenix-security-2025/paper/usenix-2020-09.sty
@@ -0,0 +1,129 @@
+% usenix.sty - to be used with latex2e for USENIX.
+% To use this style file, look at the template usenix2019_v3.1.tex
+%
+% $Id: usenix.sty,v 1.2 2005/02/16 22:30:47 maniatis Exp $
+%
+% The following definitions are modifications of standard article.sty
+% definitions, arranged to do a better job of matching the USENIX
+% guidelines.
+% It will automatically select two-column mode and the Times-Roman
+% font.
+%
+% 2018-12-19 [for ATC'19]: add packages to help embed all fonts in
+% pdf; to improve appearance (hopefully); to make refs and citations
+% clickable in pdf
+%
+% 2020-09-21 file updated to comment out flushend and make it optional
+
+%
+% USENIX papers are two-column.
+% Times-Roman font is nice if you can get it (requires NFSS,
+% which is in latex2e.
+
+\if@twocolumn\else\input twocolumn.sty\fi
+\usepackage{mathptmx} % times roman, including math (where possible)
+
+% hopefully embeds all fonts in pdf
+\usepackage[T1]{fontenc}
+\usepackage[utf8]{inputenc}
+\usepackage{pslatex}
+
+% appearance
+\usepackage[kerning,spacing]{microtype} % more compact and arguably nicer
+
+% Uncomment the following line if you want the columns of the last page
+% equal in size. But note that doing so may cause issues with some
+% document-generating tools.
+% \usepackage{flushend}
+
+% refs and bib
+\usepackage{cite} % order multiple entries in \cite{...}
+\usepackage{breakurl} % break too-long urls in refs
+\usepackage{url} % allow \url in bibtex for clickable links
+\usepackage{xcolor} % color definitions, to be use for...
+\usepackage[]{hyperref} % ...clickable refs within pdf...
+\hypersetup{ % ...like so
+ colorlinks,
+ linkcolor={green!80!black},
+ citecolor={red!70!black},
+ urlcolor={blue!70!black}
+}
+
+%
+% USENIX wants margins of: 0.75" sides, 1" bottom, and 1" top.
+% 0.33" gutter between columns.
+% Gives active areas of 7" x 9"
+%
+\setlength{\textheight}{9.0in}
+\setlength{\columnsep}{0.33in}
+\setlength{\textwidth}{7.00in}
+
+\setlength{\topmargin}{0.0in}
+
+\setlength{\headheight}{0.0in}
+
+\setlength{\headsep}{0.0in}
+
+\addtolength{\oddsidemargin}{-0.25in}
+\addtolength{\evensidemargin}{-0.25in}
+
+% USENIX wants no page numbers for camera-ready papers, so that they can
+% number them themselves. But submitted papers should have page numbers
+% for the reviewers' convenience.
+%
+%
+% \pagestyle{empty}
+
+%
+% USENIX titles are in 14-point bold type, with no date, and with no
+% change in the empty page headers. The whole author section is 12 point
+% italic--- you must use {\rm } around the actual author names to get
+% them in roman.
+%
+\def\maketitle{\par
+ \begingroup
+ \renewcommand\thefootnote{\fnsymbol{footnote}}%
+ \def\@makefnmark{\hbox to\z@{$\m@th^{\@thefnmark}$\hss}}%
+ \long\def\@makefntext##1{\parindent 1em\noindent
+ \hbox to1.8em{\hss$\m@th^{\@thefnmark}$}##1}%
+ \if@twocolumn
+ \twocolumn[\@maketitle]%
+ \else \newpage
+ \global\@topnum\z@
+ \@maketitle \fi\@thanks
+ \endgroup
+ \setcounter{footnote}{0}%
+ \let\maketitle\relax
+ \let\@maketitle\relax
+ \gdef\@thanks{}\gdef\@author{}\gdef\@title{}\let\thanks\relax}
+
+\def\@maketitle{\newpage
+ \vbox to 2.5in{
+ \vspace*{\fill}
+ \vskip 2em
+ \begin{center}%
+ {\Large\bf \@title \par}%
+ \vskip 0.375in minus 0.300in
+ {\large\it
+ \lineskip .5em
+ \begin{tabular}[t]{c}\@author
+ \end{tabular}\par}%
+ \end{center}%
+ \par
+ \vspace*{\fill}
+% \vskip 1.5em
+ }
+}
+
+%
+% The abstract is preceded by a 12-pt bold centered heading
+\def\abstract{\begin{center}%
+{\large\bf \abstractname\vspace{-.5em}\vspace{\z@}}%
+\end{center}}
+\def\endabstract{}
+
+%
+% Main section titles are 12-pt bold. Others can be same or smaller.
+%
+\def\section{\@startsection {section}{1}{\z@}{-3.5ex plus-1ex minus
+ -.2ex}{2.3ex plus.2ex}{\reset@font\large\bf}}
\ No newline at end of file
--
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.