diff options
Diffstat (limited to 'doc/cbdc-it')
| -rw-r--r-- | doc/cbdc-it/agsm-mod.bst | 1375 | ||||
| -rw-r--r-- | doc/cbdc-it/cbdc-it.bib | 561 | ||||
| -rw-r--r-- | doc/cbdc-it/cbdc-it.tex | 1304 | ||||
| -rw-r--r-- | doc/cbdc-it/cbdc.bib | 566 | ||||
| -rw-r--r-- | doc/cbdc-it/diagramma1-it.png | bin | 0 -> 108981 bytes | |||
| -rw-r--r-- | doc/cbdc-it/diagramma2-it.png | bin | 0 -> 122162 bytes | |||
| -rw-r--r-- | doc/cbdc-it/graphics-it.odp | bin | 0 -> 147461 bytes |
7 files changed, 3806 insertions, 0 deletions
diff --git a/doc/cbdc-it/agsm-mod.bst b/doc/cbdc-it/agsm-mod.bst new file mode 100644 index 000000000..ac1bbd052 --- /dev/null +++ b/doc/cbdc-it/agsm-mod.bst @@ -0,0 +1,1375 @@ +% BibTeX standard bibliography style `agsm' (one of the harvard family) + % version 0.99a for BibTeX versions 0.99a or later, LaTeX version 2.09. + % Copyright (C) 1991, all rights reserved. + % Copying of this file is authorized only if either + % (1) you make absolutely no changes to your copy, including name, or + % (2) if you do make changes, you name it something other than + % btxbst.doc, plain.bst, unsrt.bst, alpha.bst, abbrv.bst, agsm.bst, + % dcu.bst or kluwer.bst. + % This restriction helps ensure that all standard styles are identical. + % The file harvard.tex has the documentation for this style. + +% ACKNOWLEDGEMENT: +% This document is a modified version of alpha.bst to which it owes much of +% its functionality. + +% AUTHOR +% Peter Williams, Key Centre for Design Quality, Sydney University +% e-mail: peterw@archsci.arch.su.oz.au + +ENTRY + { address + author + booktitle + chapter + edition + editor + howpublished + institution + journal + key + month + note + number + organization + pages + publisher + school + series + title + type + URL + volume + year + } + { field.used etal.allowed etal.required} %%%XXX change + { extra.label sort.label list.year } + +INTEGERS { output.state before.all mid.sentence after.sentence after.block } + +FUNCTION {init.state.consts} +{ #0 'before.all := + #1 'mid.sentence := + #2 'after.sentence := + #3 'after.block := +} + +STRINGS { s t f } + +FUNCTION {output.nonnull} +{ 's := + output.state mid.sentence = + { ", " * write$ } + { output.state after.block = + { add.period$ write$ + newline$ + "\newblock " write$ + } + { output.state before.all = + 'write$ + { add.period$ " " * write$ } + if$ + } + if$ + mid.sentence 'output.state := + } + if$ + s +} + +FUNCTION {output} +{ duplicate$ empty$ + 'pop$ + 'output.nonnull + if$ +} + +FUNCTION {output.check} +{ 't := + duplicate$ empty$ + { pop$ "empty " t * " in " * cite$ * warning$ } + 'output.nonnull + if$ +} + +FUNCTION {item.check} +{ 't := + empty$ + { "empty " t * " in " * cite$ * warning$ } + { skip$ } + if$ +} + +FUNCTION {fin.entry} +{ add.period$ + write$ + newline$ +} + +FUNCTION {new.block} +{ output.state before.all = + 'skip$ + { after.block 'output.state := } + if$ +} + +FUNCTION {not} +{ { #0 } + { #1 } + if$ +} + +FUNCTION {and} +{ 'skip$ + { pop$ #0 } + if$ +} + +FUNCTION {or} +{ { pop$ #1 } + 'skip$ + if$ +} + +FUNCTION {field.or.null} +{ duplicate$ empty$ + { pop$ "" } + 'skip$ + if$ +} + +FUNCTION {emphasize} +{ duplicate$ empty$ + { pop$ "" } + { "{\em " swap$ * "}" * } + if$ +} + +FUNCTION {embolden} +{ duplicate$ empty$ + { pop$ "" } + { "{\bf " swap$ * "}" * } + if$ +} + +%%ORIGINAL KEPT HERE FOR REFERENCE: +%%FUNCTION {quote} +%%{ duplicate$ empty$ +%% { pop$ "" } +%% { "`" swap$ * "'" * } +%% if$ +%%} + +%%USE GUILLEMETS +FUNCTION {quote} +{ duplicate$ empty$ + { pop$ "" } + { "«" swap$ * "»" * } + if$ +} +%%END USE GUILLEMETS + +FUNCTION {write.url} +{ URL empty$ + { skip$ } + { "\newline\harvardurl{" URL * "}" * write$ newline$ } + if$ +} + +INTEGERS { nameptr namesleft numnames } + +FUNCTION {format.names} +{ 's := + 'f := + #1 'nameptr := + s num.names$ 'numnames := + numnames 'namesleft := + { namesleft #0 > } + { s nameptr f format.name$ 't := + nameptr #1 > + { namesleft #1 > + { ", " * t * } + { t "others" = + { " et~al." * } + { " \harvardand\ " * t * } + if$ + } + if$ + } + 't + if$ + nameptr #1 + 'nameptr := + namesleft #1 - 'namesleft := + } + while$ +} + +FUNCTION {format.authors} +{ author empty$ + { "" } + { "{vv~}{ll}{, jj}{, f.}" author format.names } + if$ +} + +FUNCTION {format.editors} +{ editor empty$ + { "" } + { "{vv~}{ll}{, jj}{, f.}" editor format.names + editor num.names$ #1 > + { ", eds" * } + { ", ed." * } + if$ + } + if$ +} + +FUNCTION {format.editors.reverse} +{ editor empty$ + { "" } + { "{f.~}{vv~}{ll}{, jj}" editor format.names + editor num.names$ #1 > + { ", eds" * } + { ", ed." * } + if$ + } + if$ +} + +%%ORIGINAL KEPT HERE FOR REFERENCE: +%%FUNCTION {format.title} +%%{ title empty$ +%% { "" } +%% { title "t" change.case$ } +%% if$ +%%} + +%%REMOVE SINGLE QUOTES +FUNCTION {format.title} +{ title empty$ + { "" } + { title "t" change.case$ quote} + if$ +} +%%END REMOVE SINGLE QUOTES + +FUNCTION {n.dashify} +{ 't := + "" + { t empty$ not } + { t #1 #1 substring$ "-" = + { t #1 #2 substring$ "--" = not + { "--" * + t #2 global.max$ substring$ 't := + } + { { t #1 #1 substring$ "-" = } + { "-" * + t #2 global.max$ substring$ 't := + } + while$ + } + if$ + } + { t #1 #1 substring$ * + t #2 global.max$ substring$ 't := + } + if$ + } + while$ +} + +FUNCTION {format.btitle} +{ title emphasize +} + +FUNCTION {tie.or.space.connect} +{ duplicate$ text.length$ #3 < + { "~" } + { " " } + if$ + swap$ * * +} + +FUNCTION {either.or.check} +{ empty$ + 'pop$ + { "can't use both " swap$ * " fields in " * cite$ * warning$ } + if$ +} + +FUNCTION {format.bvolume} +{ volume empty$ + { "" } + { "Vol." volume tie.or.space.connect + series empty$ + 'skip$ + { " of " * series emphasize * } + if$ + "volume and number" number either.or.check + } + if$ +} + +FUNCTION {format.number.series} +{ volume empty$ + { number empty$ + { series field.or.null } + { output.state mid.sentence = + { "number" } + { "Number" } + if$ + number tie.or.space.connect + series empty$ + { "there's a number but no series in " cite$ * warning$ } + { " {\em in} " * series quote * } + if$ + } + if$ + } + { "" } + if$ +} + +FUNCTION {format.edition} +{ edition empty$ + { "" } + { output.state mid.sentence = + { edition "l" change.case$ " edn" * } + { edition "t" change.case$ " edn" * } + if$ + } + if$ +} + +INTEGERS { multiresult } + +FUNCTION {multi.page.check} +{ 't := + #0 'multiresult := + { multiresult not + t empty$ not + and + } + { t #1 #1 substring$ + duplicate$ "-" = + swap$ duplicate$ "," = + swap$ "+" = + or or + { #1 'multiresult := } + { t #2 global.max$ substring$ 't := } + if$ + } + while$ + multiresult +} + +FUNCTION {format.pages} +{ pages empty$ + { "" } + { pages multi.page.check + { "pp.~" pages n.dashify * } + { "p.~" pages * } + if$ + } + if$ +} + +FUNCTION {format.vol.num.pages} +{ volume embolden field.or.null + number empty$ + 'skip$ + { "(" number * ")" * * + volume empty$ + { "there's a number but no volume in " cite$ * warning$ } + 'skip$ + if$ + } + if$ + pages empty$ + 'skip$ + { duplicate$ empty$ + { pop$ format.pages } + { ",~" * pages n.dashify * } + if$ + } + if$ +} + +FUNCTION {format.chapter.pages} +{ chapter empty$ + 'format.pages + { type empty$ + { "chapter" } + { type "l" change.case$ } + if$ + chapter tie.or.space.connect + pages empty$ + 'skip$ + { ", " * format.pages * } + if$ + } + if$ +} + +%%REMOVE ITALICS FROM WORD "IN" +FUNCTION {format.in.ed.booktitle} +{ booktitle empty$ + { "" } + { editor empty$ + %%{ "{\em in} " booktitle * } ORIGINAL + { "{in} " booktitle * } + %%{ "{\em in} " format.editors.reverse * ", " * booktitle * } ORIGINAL + { "{in} " format.editors.reverse * ", " * booktitle * } + if$ + } + if$ +} +%%END REMOVE ITALICS FROM WORD "IN" + +FUNCTION {empty.misc.check} +{ author empty$ title empty$ howpublished empty$ + month empty$ year empty$ note empty$ + and and and and and + key empty$ not and + { "all relevant fields are empty in " cite$ * warning$ } + 'skip$ + if$ +} + +FUNCTION {format.thesis.type} +{ type empty$ + 'skip$ + { pop$ + type "t" change.case$ + } + if$ +} + +FUNCTION {format.tr.number} +{ type empty$ + { "Technical Report" } + 'type + if$ + number empty$ + { "t" change.case$ } + { number tie.or.space.connect } + if$ +} + +FUNCTION {format.article.crossref} +{ key empty$ + { journal empty$ + { "need key or journal for " cite$ * " to crossref " * crossref * + warning$ + "" + } + { "in {\em " journal * "\/} \cite{" * crossref * "}" *} + if$ + } + { "{\em in} \citeasnoun{" crossref * "}" * } + if$ + +} + +FUNCTION {format.book.crossref} +{ volume empty$ + { "empty volume in " cite$ * "'s crossref of " * crossref * warning$ + "in " + } + { "Vol." volume tie.or.space.connect + " of " * + } + if$ + editor empty$ + editor field.or.null author field.or.null = + or + { key empty$ + { series empty$ + { "need editor, key, or series for " cite$ * " to crossref " * + crossref * warning$ + "" * + } + { "{\em " * series * "\/} \cite{" * crossref * "}" *} + if$ + } + { " \citeasnoun{" * crossref * "}" * } + if$ + } + { " \citeasnoun{" * crossref * "}" * } + if$ +} + +FUNCTION {format.incoll.inproc.crossref} +{ editor empty$ + editor field.or.null author field.or.null = + or + { key empty$ + { booktitle empty$ + { "need editor, key, or booktitle for " cite$ * " to crossref " * + crossref * warning$ + "" + } + { "in {\em " booktitle * "\/}" * " \cite{" * crossref * "}" *} + + if$ + } + { "{\em in} \citeasnoun{" crossref * "}" * } + if$ + } + { "{\em in} \citeasnoun{" crossref * "}" * } + if$ + +} + +INTEGERS { len } + +FUNCTION {chop.word} +{ 's := + 'len := + s #1 len substring$ = + { s len #1 + global.max$ substring$ } + 's + if$ +} + +INTEGERS { ind tsslen } + +STRINGS { tss ret rss istr } + +FUNCTION {replace.substring}{ + 'rss := + 'tss := + 'istr := + "" 'ret := + tss text.length$ 'tsslen := + #1 'ind := + { istr ind tsslen substring$ "" = not } + { istr ind tsslen substring$ tss = + { ret rss * 'ret := + ind tsslen + 'ind := + } + { ret istr ind #1 substring$ * 'ret := + ind #1 + 'ind := + } + if$ + } + while$ + ret +} + +FUNCTION {format.lab.names.abbr} +{ 's := + s num.names$ 'numnames := + numnames #1 > + { numnames #2 > + { s #1 "{vv~}{ll}" format.name$ " et~al." * } + { s #2 "{ff }{vv }{ll}{ jj}" format.name$ "others" = + { s #1 "{vv~}{ll}" format.name$ " et~al." * } + { s #1 "{vv~}{ll}" format.name$ " \harvardand\ " * + s #2 "{vv~}{ll}" format.name$ * + } + if$ + } + if$ + } + { s #1 "{vv~}{ll}" format.name$ } + if$ +} + +FUNCTION {format.lab.names.full} +{ 's := + #1 'nameptr := + s num.names$ 'numnames := + numnames 'namesleft := + { namesleft #0 > } + { s nameptr "{vv~}{ll}" format.name$ 't := + nameptr #1 > + { namesleft #1 > + { ", " * t * } + { t "others" = + { " et~al." * } + { " \harvardand\ " * t * } + if$ + } + if$ + } + 't + if$ + nameptr #1 + 'nameptr := + namesleft #1 - 'namesleft := + } + while$ +} + +INTEGERS { author.field editor.field organization.field title.field key.field } + +FUNCTION {init.field.constants} +{ #0 'author.field := + #1 'editor.field := + #2 'organization.field := + #3 'title.field := + #4 'key.field := +} + +FUNCTION {make.list.label} +{ author.field field.used = + { format.authors } + { editor.field field.used = + { format.editors } + { organization.field field.used = + { "The " #4 organization chop.word #3 text.prefix$ } + { title.field field.used = + { format.btitle } + { key.field field.used = + { key #3 text.prefix$ } + { "Internal error :001 on " cite$ * " label" * warning$ } + if$ + } + if$ + } + if$ + } + if$ + } + if$ +} + +FUNCTION {make.full.label} +{ author.field field.used = + { author format.lab.names.full } + { editor.field field.used = + { editor format.lab.names.full } + { organization.field field.used = + { "The " #4 organization chop.word #3 text.prefix$ } + { title.field field.used = + { format.btitle } + { key.field field.used = + { key #3 text.prefix$ } + { "Internal error :001 on " cite$ * " label" * warning$ } + if$ + } + if$ + } + if$ + } + if$ + } + if$ +} + +FUNCTION {make.abbr.label} %%%XXX change +{ + etal.allowed + { author.field field.used = + { author format.lab.names.abbr } + { editor.field field.used = + { editor format.lab.names.abbr } + { organization.field field.used = + { "The " #4 organization chop.word #3 text.prefix$ } + { title.field field.used = + { format.btitle } + { key.field field.used = + { key #3 text.prefix$ } + {"Internal error :001 on " cite$ * " label" * warning$ } + if$ + } + if$ + } + if$ + } + if$ + } + if$ + } + { make.full.label } + if$ +} + +FUNCTION {output.bibitem} +{ newline$ + etal.allowed %%%XXX change + etal.required + and + { + "\harvarditem[" write$ + make.abbr.label write$ + "]{" write$ + } + { + "\harvarditem{" write$ + } + if$ + make.full.label write$ + "}{" write$ + list.year write$ + "}{" write$ + cite$ write$ + "}" write$ + newline$ + "" + before.all 'output.state := +} + +FUNCTION {list.label.output} +{ make.list.label " " * write$ +} + +FUNCTION {article} +{ output.bibitem + list.label.output + " \harvardyearleft " list.year * "\harvardyearright " * output.nonnull + author "author" item.check + title.field field.used = + { skip$ } + { format.title "title" output.check } + if$ + crossref missing$ + { journal emphasize "journal" duplicate$ item.check + " " * format.vol.num.pages * output + } + { format.article.crossref output.nonnull + format.pages output + } + if$ + new.block + note output + fin.entry + write.url +} + +FUNCTION {book} +{ output.bibitem + list.label.output + " \harvardyearleft " list.year * "\harvardyearright " * output.nonnull + author empty$ + { editor "author and editor" item.check } + { crossref missing$ + { "author and editor" editor either.or.check } + 'skip$ + if$ + } + if$ + title.field field.used = + { skip$ } + { format.btitle "title" output.check } + if$ + crossref missing$ + { format.bvolume output + format.number.series output + format.edition output + publisher "publisher" output.check + address output + } + { format.book.crossref output.nonnull + format.edition output + } + if$ + new.block + note output + fin.entry + write.url +} + +FUNCTION {booklet} +{ output.bibitem + list.label.output + " \harvardyearleft " list.year * "\harvardyearright " * output.nonnull + title.field field.used = + { skip$ } + { format.title "title" output.check } + if$ + howpublished output + address output + new.block + note output + fin.entry + write.url +} + +FUNCTION {inbook} +{ output.bibitem + list.label.output + " \harvardyearleft " list.year * "\harvardyearright " * output.nonnull + author empty$ + { editor "author and editor" item.check } + { crossref missing$ + { "author and editor" editor either.or.check } + 'skip$ + if$ + } + if$ + title.field field.used = + { skip$ } + { format.btitle "title" output.check } + if$ + crossref missing$ + { format.bvolume output + format.number.series output + format.edition output + publisher "publisher" output.check + address output + } + { format.book.crossref output.nonnull + format.edition output + } + if$ + format.chapter.pages "chapter and pages" output.check + new.block + note output + fin.entry + write.url +} + +FUNCTION {incollection} +{ output.bibitem + list.label.output + " \harvardyearleft " list.year * "\harvardyearright " * output.nonnull + title.field field.used = + { skip$ } + { format.title "title" output.check } + if$ + author "author" item.check + crossref missing$ + { format.in.ed.booktitle "booktitle" output.check + format.edition output + format.bvolume output + format.number.series output + publisher "publisher" output.check + address output + } + { format.incoll.inproc.crossref output.nonnull + } + if$ + format.chapter.pages output + new.block + note output + fin.entry + write.url +} + +FUNCTION {inproceedings} +{ output.bibitem + list.label.output + " \harvardyearleft " list.year * "\harvardyearright " * output.nonnull + title.field field.used = + { skip$ } + { format.title "title" output.check } + if$ + author "author" item.check + crossref missing$ + { format.in.ed.booktitle "booktitle" output.check + format.bvolume output + format.number.series output + address empty$ + { organization output + publisher output + } + { organization output + publisher output + address output.nonnull + } + if$ + } + { format.incoll.inproc.crossref output.nonnull + } + if$ + format.pages output + new.block + note output + fin.entry + write.url +} + +FUNCTION {conference} { inproceedings } + +FUNCTION {manual} +{ output.bibitem + list.label.output + " \harvardyearleft " list.year * "\harvardyearright " * output.nonnull + title.field field.used = + { skip$ } + { format.btitle "title" output.check } + if$ + format.edition output + author empty$ + { organization empty$ + { address output } + 'skip$ + if$ + } + { organization output + address output + } + if$ + new.block + note output + fin.entry + write.url +} + +FUNCTION {mastersthesis} +{ output.bibitem + list.label.output + " \harvardyearleft " list.year * "\harvardyearright " * output.nonnull + author "author" item.check + title.field field.used = + { skip$ } + { format.title "title" output.check } + if$ + "Master's thesis" format.thesis.type output.nonnull + school "school" output.check + address output + new.block + note output + fin.entry + write.url +} + +FUNCTION {misc} +{ output.bibitem + list.label.output + " \harvardyearleft " list.year * "\harvardyearright " * output.nonnull + title.field field.used = + { skip$ } + { format.title output } + if$ + howpublished output + new.block + note output + fin.entry + write.url + empty.misc.check +} + +FUNCTION {phdthesis} +{ output.bibitem + list.label.output + " \harvardyearleft " list.year * "\harvardyearright " * output.nonnull + author "author" item.check + title.field field.used = + { skip$ } + { title "title" output.check } + if$ + "PhD thesis" format.thesis.type output.nonnull + school "school" output.check + address output + new.block + note output + fin.entry + write.url +} + +FUNCTION {proceedings} +{ output.bibitem + list.label.output + " \harvardyearleft " list.year * "\harvardyearright " * output.nonnull + title.field field.used = + { skip$ } + { format.btitle "title" output.check } + if$ + format.bvolume output + format.number.series output + address empty$ + { editor empty$ + { skip$ } + { organization output + } + if$ + publisher output + } + { editor empty$ + 'skip$ + { organization output } + if$ + publisher output + address output.nonnull + } + if$ + new.block + note output + fin.entry + write.url +} + +FUNCTION {techreport} +{ output.bibitem + list.label.output + " \harvardyearleft " list.year * "\harvardyearright " * output.nonnull + author "author" item.check + title.field field.used = + { skip$ } + { format.title "title" output.check } + if$ + format.tr.number output.nonnull + institution "institution" output.check + address output + new.block + note output + fin.entry + write.url +} + +FUNCTION {unpublished} +{ output.bibitem + list.label.output + " \harvardyearleft " list.year * "\harvardyearright " * output.nonnull + author "author" item.check + title.field field.used = + { skip$ } + { format.title "title" output.check } + if$ + new.block + note "note" output.check + fin.entry + write.url +} + +FUNCTION {default.type} { misc } + +MACRO {jan} {"January"} + +MACRO {feb} {"February"} + +MACRO {mar} {"March"} + +MACRO {apr} {"April"} + +MACRO {may} {"May"} + +MACRO {jun} {"June"} + +MACRO {jul} {"July"} + +MACRO {aug} {"August"} + +MACRO {sep} {"September"} + +MACRO {oct} {"October"} + +MACRO {nov} {"November"} + +MACRO {dec} {"December"} + +MACRO {acmcs} {"ACM Computing Surveys"} + +MACRO {acta} {"Acta Informatica"} + +MACRO {cacm} {"Communications of the ACM"} + +MACRO {ibmjrd} {"IBM Journal of Research and Development"} + +MACRO {ibmsj} {"IBM Systems Journal"} + +MACRO {ieeese} {"IEEE Transactions on Software Engineering"} + +MACRO {ieeetc} {"IEEE Transactions on Computers"} + +MACRO {ieeetcad} + {"IEEE Transactions on Computer-Aided Design of Integrated Circuits"} + +MACRO {ipl} {"Information Processing Letters"} + +MACRO {jacm} {"Journal of the ACM"} + +MACRO {jcss} {"Journal of Computer and System Sciences"} + +MACRO {scp} {"Science of Computer Programming"} + +MACRO {sicomp} {"SIAM Journal on Computing"} + +MACRO {tocs} {"ACM Transactions on Computer Systems"} + +MACRO {tods} {"ACM Transactions on Database Systems"} + +MACRO {tog} {"ACM Transactions on Graphics"} + +MACRO {toms} {"ACM Transactions on Mathematical Software"} + +MACRO {toois} {"ACM Transactions on Office Information Systems"} + +MACRO {toplas} {"ACM Transactions on Programming Languages and Systems"} + +MACRO {tcs} {"Theoretical Computer Science"} + +READ + +EXECUTE {init.field.constants} + +FUNCTION {sortify} +{ purify$ + "l" change.case$ +} + +FUNCTION {sortify.names} +{ " \harvardand\ " " " replace.substring + " et~al." " zzz" replace.substring + sortify +} + +FUNCTION {author.key.label} +{ author empty$ + { key empty$ + { title.field 'field.used := } + { key.field 'field.used := } + if$ + } + { author.field 'field.used := } + if$ +} + +FUNCTION {author.editor.key.label} +{ author empty$ + { editor empty$ + { key empty$ + { title.field 'field.used := } + { key.field 'field.used := } + if$ + } + { editor.field 'field.used := } + if$ + } + { author.field 'field.used := } + if$ +} + +FUNCTION {author.key.organization.label} +{ author empty$ + { key empty$ + { organization empty$ + { title.field 'field.used := } + { organization.field 'field.used := } + if$ + } + { key.field 'field.used := } + if$ + } + { author.field 'field.used := } + if$ +} + +FUNCTION {editor.key.organization.label} +{ editor empty$ + { key empty$ + { organization empty$ + { title.field 'field.used := } + { organization.field 'field.used := } + if$ + } + { key.field 'field.used := } + if$ + } + { editor.field 'field.used := } + if$ +} + +FUNCTION {sort.format.title} +{ 't := + "A " #2 + "An " #3 + "The " #4 t chop.word + chop.word + chop.word + sortify + #1 global.max$ substring$ +} + +FUNCTION {calc.label} %%%XXX change +{ make.abbr.label + title.field field.used = + { sort.format.title } + { sortify.names } + if$ + year field.or.null purify$ #-1 #4 substring$ sortify + * + 'sort.label := +} + +FUNCTION {preliminaries} %%%XXX change +{ type$ "book" = + type$ "inbook" = + or + 'author.editor.key.label + { type$ "proceedings" = + 'editor.key.organization.label + { type$ "manual" = + 'author.key.organization.label + 'author.key.label + if$ + } + if$ + } + if$ + author.field field.used = %%%XXX change + { + author num.names$ #2 > + { #1 } + { #0 } + if$ + 'etal.required := + } + { + editor.field field.used = + { + editor num.names$ #2 > + { #1 } + { #0 } + if$ + } + { #0 } + if$ + 'etal.required := + } + if$ + #1 'etal.allowed := +} + +FUNCTION {first.presort} +{ calc.label + sort.label + title.field field.used = + { skip$ } + { " " + * + make.list.label sortify.names + * + " " + * + title field.or.null + sort.format.title + * + } + if$ + #1 entry.max$ substring$ + 'sort.key$ := +} + +ITERATE {preliminaries} + +ITERATE {first.presort} + +SORT + +STRINGS { last.sort.label next.extra last.full.label} + +INTEGERS { last.extra.num last.etal.allowed} + +FUNCTION {initialize.confusion} +{ #0 int.to.chr$ 'last.sort.label := + #0 int.to.chr$ 'last.full.label := + #1 'last.etal.allowed := +} + +FUNCTION {confusion.pass} +{ last.sort.label sort.label = + { last.etal.allowed + { last.full.label make.full.label sortify.names = + { skip$ } + { #0 'etal.allowed := + #0 'last.etal.allowed := + } + if$ + } + { #0 'etal.allowed := } + if$ + } + { sort.label 'last.sort.label := + make.full.label sortify.names 'last.full.label := + #1 'last.etal.allowed := + } + if$ +} + +EXECUTE {initialize.confusion} + +ITERATE {confusion.pass} + +EXECUTE {initialize.confusion} + +REVERSE {confusion.pass} + +FUNCTION {initialize.last.extra.num} +{ #0 int.to.chr$ 'last.sort.label := + "" 'next.extra := + #0 'last.extra.num := +} + +FUNCTION {forward.pass} +{ last.sort.label sort.label = + { last.extra.num #1 + 'last.extra.num := + last.extra.num int.to.chr$ 'extra.label := + } + { "a" chr.to.int$ 'last.extra.num := + "" 'extra.label := + sort.label 'last.sort.label := + } + if$ +} + +FUNCTION {reverse.pass} +{ next.extra "b" = + { "a" 'extra.label := } + 'skip$ + if$ + year empty$ + { "n.d." extra.label emphasize * 'list.year := } + { year extra.label emphasize * 'list.year := } + if$ + extra.label 'next.extra := +} + +ITERATE {first.presort} + +SORT + +EXECUTE {initialize.last.extra.num} + +ITERATE {forward.pass} + +REVERSE {reverse.pass} + +FUNCTION {second.presort} +{ make.list.label + title.field field.used = + { sort.format.title } + { sortify.names } + if$ + " " + * + list.year field.or.null sortify + * + " " + * + title.field field.used = + { skip$ } + { title field.or.null + sort.format.title + * + } + if$ + #1 entry.max$ substring$ + 'sort.key$ := +} + +ITERATE {second.presort} + +SORT + +FUNCTION {begin.bib} +{ preamble$ empty$ + 'skip$ + { preamble$ write$ newline$ } + if$ + "\begin{thebibliography}{xx}" write$ newline$ +} + +EXECUTE {begin.bib} + +EXECUTE {init.state.consts} + +ITERATE {call.type$} + +FUNCTION {end.bib} +{ newline$ + "\end{thebibliography}" write$ newline$ +} + +EXECUTE {end.bib} diff --git a/doc/cbdc-it/cbdc-it.bib b/doc/cbdc-it/cbdc-it.bib new file mode 100644 index 000000000..639bb0c45 --- /dev/null +++ b/doc/cbdc-it/cbdc-it.bib @@ -0,0 +1,561 @@ +%% To be used with modified bibliography style agsm-mod + hyperref + natbib + italian babel + +@article{Adrian, + author = {Adrian, Tobias and Mancini-Griffoli}, + year = {2019}, + title = {{The Rise of Digital Money}}, + journal = {IMF Fintech Note}, + volume = {19/01}, +} + +@article{Agarwal, + author = {Agarwal, Ruchir and Miles S. Kimball}, + year = {2019}, + title = {{Enabling Deep Negative Rates to Fight Recessions: A Guide}}, + journal = {IMF Working Paper}, + volume = {19/84}, +} + + +@article{Agur, + author = {Agur, Itai and Anil Ari and Giovanni Dell'Ariccia}, + year = {2019}, + title = {{Designing Central Bank Digital Currencies}}, + journal = {IMF Working Paper}, + volume = {19/252}, +} + +@article{Allen, + author = {Allen, Sarah and Srđjan Čapkun and Ittay Eyal and Giulia Fanti and Bryan A. Ford and James Grimmelmann and Ari Juels and Kari Kostiainen and Sarah Meiklejohn and Andrew Miller and Eswar Prasad and Karl Wüst and Fan Zhang}, + year = {2020}, + title = {{Design Choices for Central Bank Digital Currency: Policy and Technical Considerations}}, + journal = {NBER Working Paper}, + volume = {27634}, +} + +@article{Alves, + author = {Alves, Tiago and Don Felton}, + year = {2004}, + title = {TrustZone: Integrated hardware and software security}, + journal = {ARM IQ}, + volume = {3}, + number = {4}, + pages = {18--24}, +} + +@article{AuerBoehme, + author = {Auer, Raphael and Rainer Böhme}, + year = {2020}, + title = {The technology of retail central bank digital currency}, + journal = {BIS Quarterly Review}, + month = {March}, + pages = {85--96}, +} + +@article{AuerCornelli, + author = {Auer, Raphael and Giulio Cornelli and Jon Frost}, + year = {2020}, + title = {{Taking stock: ongoing retail CBDC projects}}, + journal = {BIS Quarterly Review}, + month = {March}, + pages = {97--98}, +} + +@booklet{BIS, + author = {{Bank for International Settlements}}, + year = {2018}, + title = {{Central Bank Digital Currencies. Joint Report of the Committee on Payments and Market Infrastructures and Markets Committee}}, +} + +@booklet{BoE, + author = {{Bank of England}}, + year = {2020}, + title = {{Central Bank Digital Currency: Opportunities, Challenges and Design. Discussion Paper}}, + month = {March}, +} + +@article{Baiocchi, + author = {Baiocchi, Giovanni and Walter Distaso}, + year = {2003}, + title = {{GRETL: Econometric Software for the GNU Generation}}, + journal = {Journal of Applied Econometrics}, + volume = {18}, + pages = {105-110}, +} + +@article{Bech, + author = {Bech, Morten and Rodney Garratt}, + year = {2017}, + title = {Central bank cryptocurrencies}, + journal = {BIS Quarterly Review}, + month = {September}, + pages = {55--70}, +} + +@article{Berentsen, + author = {Berentsen, Aleksander and Fabian Schär}, + year = {2018}, + title = {{The Case for Central Bank Electronic Money and the Non-case for Central Bank Cryptocurrencies}}, + journal = {Federal Reserve Bank of St. Louis Review}, + volume = {100}, + number = {2}, + pages = {97--106}, +} + +@article{Bernstein2020, + author = {Bernstein, Daniel J. and Tanja Lange}, + year = {2020}, + title = {{eBACS: ECRYPT Benchmarking of Cryptographic Systems}}, + url = {\url{https://bench.cr.yp.to}, consultato il 17 marzo 2020}, +} + +@article{Bernstein2012, + author = {Bernstein, Daniel J. and Niels Duif and Tanja Lange and Peter Schwabe and Bo-Yin Yang}, + year = {2012}, + title = {High-speed high-security signatures}, + journal = {Journal of Cryptographic Engineering}, + volume = {2}, + pages = {77--89}, +} + +@InCollection{Bindseil, + author = {Bindseil, Ulrich}, + year = {2020}, + title = {{Tiered CBDC and the financial system}}, + publisher = {European Central Bank}, + series = {ECB Working Paper}, + number = {2351}, + month = {January}, +} + +@article{Boar, + author = {Boar, Codruta and Henry Holden and Amber Wadsworth}, + year = {2020}, + title = {Impending arrival - a sequel to the survey on central bank digital currency}, + journal = {BIS Papers}, + volume = {107}, +} + +@article{Boneh, + author = {Boneh, Dan}, + year = {1999}, + title = {{Twenty Years of Attacks on the RSA Cryptosystem}}, + journal = {Notices of the AMS}, + volume = {42}, + number = {2}, + pages = {202--213}, +} + +@InCollection{Bordo, + author = {Bordo, Michael D. and Andrew T. Levin}, + year = {2017}, + title = {Central bank digital currency and the future of monetary policy}, + publisher = {National Bureau of Economic Research}, + series = {NBER Working Paper Series}, + number = {23711}, +} + +@article{Brunnermeier, + author = {Brunnermeier, Markus and Dirk Niepelt}, + year = {2019}, + title = {{On the Equivalence of Private and Public Money}}, + journal = {Journal of Monetary Economics}, + volume = {106}, + pages = {27--41}, +} + +@article{Buiter, + author = {Buiter, Willem H. and Nikolaos Panigirtzoglou}, + year = {2003}, + title = {{Overcoming the Zero Bound on Nominal Interest Rates with Negative Interest on Currency: Gesell's Solution}}, + journal = {The Economic Journal}, + volume = {113}, + number = {490}, + pages = {723--746}, +} + +@InCollection{Bullmann, + author = {Bullmann, Dirk and Jonas Klemm and Andrea Pinna}, + year = {2019}, + title = {In search for stability in crypto-assets: are stablecoins the solution?}, + publisher = {European Central Bank}, + series = {ECB Occasional Paper Series}, + number = {230}, +} + +@inproceedings{Camenisch2007, + author = {Camenisch, Jan and Aanna Lysyanskaya and Mira Meyerovich}, + year = {2007}, + title = {{Endorsed E-Cash}}, + booktitle = {\textit{2007 IEEE Symposium on Security and Privacy (SP'07)}}, + month = {May}, + pages = {101--115}, +} + +@inproceedings{Camenisch2005, + author = {Camenisch, Jan and Susan Hohenberger and Anna Lysyanskaya}, + year = {2005}, + title = {{Compact E-Cash}}, + booktitle = {\textit{Advances in Cryptology -- EUROCRYPT 2005: 24th Annual International Conference on the Theory and Applications of Cryptographic Techniques}}, + address = {Aarhus, Denmark}, + month = {May}, + day = {22-26}, + editor = {Ed. di Ronald Cramer}, + publisher = {Springer-Verlag Berlin Heidelberg}, +} + + + +@inproceedings{Canard, + author = {Canard, Sébastien and Aline Gouget}, + year = {2007}, + title = {Divisible e-cash systems can be truly anonymous}, + booktitle = {\textit{Annual International Conference on the Theory and Applications of Cryptographic Techniques}}, + pages = {482--497}, +} + +@misc{CCC, + author = {{CCC e.V.}}, + year = {2017}, + title = {{Chaos Computer Club hacks e-motor charging stations}}, + howpublished = {34c3}, +} + +@article{Chapman, + author = {Chapman, James and Rodney Garratt and Scott Hendry and Andrew McCormack and Wade McMahon}, + year = {2017}, + title = {{Project Jasper: Are Distributed Wholesale Payment Systems Feasible Yet?}}, + journal = {Financial System Review}, + publisher = {Bank of Canada}, + month = {June}, + pages = {59--69}, +} + +@inproceedings{Chaum1983, + author = {Chaum, David}, + year = {1983}, + title = {Blind signatures for untraceable payments}, + booktitle = {\textit{Advances in Cryptology: Proceedings of Crypto `82}}, + pages = {199--203}, +} + +@inproceedings{Chaum1990, + author = {Chaum, David and Amos Fiat and Moni Naor}, + year = {1990}, + title = {Untraceable electronic cash}, + booktitle = {\textit{Advances in Cryptology: Proceedings of CRYPTO '88}}, + pages = {319--327}, +} + +@inproceedings{Danezis, + author = {Danezis, George and Sarah Meiklejohn}, + year = {2016}, + title = {{Centrally Banked Cryptocurrencies}}, + booktitle = {\textit{23nd Annual Network and Distributed System Security Symposium, NDSS2016}}, + address = {San Diego, California, USA}, + month = {February}, + day = {21--24}, + publisher = {The Internet Society}, +} + +@article{Diffie, + author = {Diffie, Whitfield and Martin Hellmann}, + year = {1976}, + title = {{New Directions in Cryptography}}, + journal = {IEEE Trans. on Inf. Theory, IT-22}, + pages = {644--654}, +} + +@phdthesis{Dold, + author = {Dold, Florian}, + year = {2019}, + title = {{The GNU Taler System: Practical and Provably Secure Electronic Payments. PhD Thesis}}, + school = {University of Rennes 1}, +} + +@article{ECB, + author = {{European Central Bank}}, + year = {2019}, + title = {Exploring anonymity in central bank digital currencies}, + journal = {In Focus}, + number = {4}, + month = {December}, +} + +@inproceedings{Fuchsbauer, + author = {Fuchsbauer, Georg and David Pointcheval and Damien Vergnaud}, + year = {2009}, + title = {Transferable constant-size fair e-cash}, + booktitle = {International Conference on Cryptology and Network Security}, + publisher = {Springer-Verlag Berlin Heidelberg}, + pages = {226--247}, +} + +@inproceedings{Garcia, + author = {Garcia, Flavio and Gerhard de Koning Gans and Ruben Muijrers and Peter van Rossum and Roel Verdult and Ronny Wichers Schreur and Bart Jacobs}, + year = {2008}, + title = {{Dismantling MIFARE Classic}}, + booktitle = {\textit{European Symposium on Research in Computer Security}}, +} + +@article{Garratt, + author = {Garratt, Rod and Michael Lee and Brendan Malone and Antoine Martin}, + year = {2020}, + title = {{Token- or Account-Based? A Digital Currency Can Be Both}}, + journal = {Liberty Street Economics}, + publisher = {Federal Reserve Bank of New York}, + month = {August}, + day = {12}, +} + +@article{Goodfriend, + author = {Goodfriend, Marvin}, + year = {2000}, + title = {{Overcoming the Zero Bound on Interest Rate Policy}}, + journal = {Journal of Money, Credit, and Banking}, + volume = {32}, + number = {4}, + pages = {1007--1035}, +} + +@article{Johnston, + author = {Johnston, Casey}, + year = {2010}, + title = {PS3 hacked through poor cryptography implementation}, + journal = {Ars Technica}, + month = {December}, + day = {30}, +} + +@Misc{Jordan, + note = {Discorso in occasione del 30º anniversario del Centro di scienze economiche (WWZ) e dell’Associazione degli economisti basilesi (VBÖ)}, + author = {Jordan, Thomas J.}, + year = {2019}, + title = {Valute, moneta e token digitali}, + publisher = {University of Basel}, + month = {September}, + howpublished = {\url{https://www.snb.ch/it/mmr/speeches/id/ref_20190905_tjn/source/ref_20190905_tjn.it.pdf}}, +} + +@article{Kahn2009, + author = {Kahn, Charles M. and William Roberds}, + year = {2009}, + title = {{Why Pay? An Introduction to Payments Economics}}, + journal = {Journal of Financial Intermediation}, + number = {18}, + pages = {1--23}, +} + +@article{Kahn2005, + author = {Kahn, Charles M. and James McAndrews and William Roberds}, + year = {2005}, + title = {{Money is Privacy}}, + journal = {International Economic Review}, + volume = {46}, + number = {2}, + pages = {377--399}, +} + +@article{Kasper, + author = {Kasper, Timo and Michael Silbermann and Christof Paar}, + year = {2010}, + title = {All you can eat or breaking a real-world contactless payment system}, + journal = {Financial Cryptography and Data Security, Lecture Notes in Computer Science}, + volume = {6052}, + pages = {343--50}, +} + +@inproceedings{Katzenbeisser, + author = {Katzenbeisser, Stefan and Ünal Kocabaş and Vladimir Rožić and Ahmad-Reza Sadeghi and Ingrid Verbauwhede and Christian Wachsmann}, + year = {2012}, + title = {{PUFs: Myth, Fact or Busted? A Security Evaluation of Physically Unclonable Functions (PUFs) Cast in Silicon}}, + booktitle = {\textit{Cryptographic Hardware and Embedded Systems -- CHES 2012. Lecture Notes in Computer Science}}, + volume = {7428}, + pages = {283--301}, +} + +@book{Keynes, + author = {Keynes, John Maynard}, + year = {1936}, + title = {The General Theory of Employment, Interest and Money}, + publisher = {Macmillan}, +} + +@article{Kiff, + author = {Kiff, John and Jihad Alwazir and Sonja Davidovic and Aquiles Farias and Ashraf Khan and Tanai Khiaonarong and Majid Malaika and Hunter Monroe and Nobu Sugimoto and Hervé Tourpe and Peter Zhou}, + year = {2020}, + title = {{A Survey of Research on Retail Central Bank Digital Currency}}, + journal = {IMF Working Paper}, + volume = {20/104}, +} + +@InCollection{Kumhof, + author = {Kumhof, Michael and Clare Noone}, + year = {2018}, + title = {Central bank digital currencies - design principles and balance sheet implications}, + publisher = {Bank of England}, + series = {Staff Working Paper}, + number = {725}, +} + +@inproceedings{Lapid, + author = {Lapid, Ben and Avishai Wool}, + year = {2018}, + title = {{Cache-Attacks on the ARM TrustZone Implementations of AES-256 and AES-256-GCM via GPU-Based Analysis}}, + booktitle = {\textit{International Conference on Selected Areas in Cryptography. Lecture Notes in Computer Science}}, + volume = {11349}, +} + +@article{Lerner, + author = {Lerner, Josh and Jean Tirole}, + year = {2005}, + title = {{The Scope of Open Source Licensing}}, + journal = {Journal of Law, Economics \& Organization}, + volume = {21}, + pages = {20-56}, +} + +@misc{Libra, + author = {{Libra Association}}, + year = {2020}, + title = {{Libra White Paper v2.0}}, + url = {\url{https://libra.org/en-US/white-paper}}, +} + +@inproceedings{Lim, + author = {Lim, Chae Hoon and Phil Joong Lee}, + year = {1997}, + title = {A key recovery attack on discrete log-based schemes using a prime order subgroup}, + booktitle = {\textit{CRYPTO 1997. Lecture Notes in Computer Science}}, + volume = {1294}, +} + +@InCollection{Lyons, + author = {Lyons, Richard K. and Ganesh Viswanath-Natraj}, + year = {2020}, + title = {{What Keeps Stablecoins Stable?}}, + publisher = {National Bureau of Economic Research}, + series = {NBER Working Paper Series}, + number = {27136}, + month = {May}, +} + +@article{Mancini-Griffoli, + author = {Mancini-Griffoli and Maria Soledad Martinez Peria and Itai Agur and Anil Ari and John Kiff and Adina Popescu and Celine Rochon}, + year = {2018}, + title = {{Casting Light on Central Bank Digital Currency}}, + journal = {IMF Staff Discussion Notes}, + volume = {18/08}, + publisher = {International Monetary Fund}, +} + +@misc{Nakamoto, + author = {Nakamoto, Satoshi}, + year = {2008}, + title = {{Bitcoin: A Peer-to-Peer Electronic Cash System}}, + url = {\url{https://www.bitcoin.com/bitcoin.pdf}}, +} + +@book{Narayanan, + author = {Narayanan, Arvind and Joseph Bonneau and Edward Felten and Andrew Miller and Steven Goldfeder}, + year = {2016}, + title = {Bitcoin and Cryptocurrency Technologies: A Comprehensive Introduction}, + publisher = {Princeton University Press}, +} + +@misc{Niepelt, + author = {Niepelt, Dirk}, + year = {2020}, + title = {Digital money and central bank digital currency: An executive summary for policymakers}, + howpublished = {\url{https://voxeu.org/article/digital-money-and-central-bank-digital-currency-executive-summary}}, +} + +@inproceedings{Okamoto, + author = {Okamoto, Tatsuaki}, + year = {1995}, + title = {{An Efficient Divisible Electronic Cash Scheme}}, + booktitle = {\textit{Advances in Cryptology --- CRYPT0'95: 15th Annual International Cryptology Conference Santa Barbara, California, USA, 27--31 agosto, 1995 Proceedings}}, + editor = {Ed. di Don Coppersmith}, + publisher = {Springer-Verlag Berlin Heidelberg}, + pages = {438--451}, +} + +@article{Pinto, + author = {Pinto, S. and N. Santos}, + year = {2019}, + title = {{Demystifying ARM TrustZone: A Comprehensive Survey}}, + journal = {ACM Computing Surveys}, + volume = {51}, + number = {6}, + month = {January}, + pages = {1--31} +} + +@article{Rivest, + author = {Rivest, Ronald L. and Adi Shamir and Leonard Adleman}, + year = {1978}, + title = {{A Method for Obtaining Digital Signatures and Public Key Cryptosystems}}, + journal = {Comm. ACM}, + volume = {21}, + number = {2}, +} + +@book{Solove, + author = {Solove, Daniel J.}, + year = {2011}, + title = {Nothing to Hide: The false tradeoff between privacy and security}, + publisher = {New Haven \& London: Yale University Press}, +} + +@article{Soukup, + author = {Soukup, Michael and Bruno Muff}, + year = {2007}, + title = {{Die Postcard lässt sich fälschen}}, + journal = {Sonntagszeitung}, + month = {April}, + day = {22}, +} + +@article{Stallman, + author = {Stallman, Richard}, + year = {1985}, + title = {{The GNU manifesto}}, + journal = {Dr. Dobb's Journal of Software Tools}, + volume = {10}, + number = {3}, + pages = {30--35}, +} + +@TechReport{Riksbank, + author = {{Sveriges Riksbank}}, + year = {2020}, + title = {{The Riksbank's e-krona project}}, + month = {February}, + institution = {Sveriges Riksbank}, + url = {\url{https://www.riksbank.se/globalassets/media/rapporter/e-krona/2019/the-riksbanks-e-krona-pilot.pdf}}, +} + +@misc{Wojtczuk, + author = {Wojtczuk, Rafal and Joanna Rutkowska}, + year = {2009}, + title = {{Attacking Intel Trusted Execution Technology}}, + howpublished = {BlackHat-DC 2009}, +} + +@article{Yalta2010, + author = {Yalta, A. Talha and A. Yasemin Yalta}, + year = {2010}, + title = {{Should Economists Use Open Source Software for Doing Research?}}, + journal = {Computational Economics}, + volume = {35}, + pages = {371--394}, +} + +@article{Yalta2008, + author = {Yalta, A. Talha and Riccardo Lucchetti}, + year = {2008}, + title = {{The GNU/Linux Platform and Freedom Respecting Software for Economists}}, + journal = {Journal of Applied Econometrics}, + volume = {23}, + pages = {279-286}, +} diff --git a/doc/cbdc-it/cbdc-it.tex b/doc/cbdc-it/cbdc-it.tex new file mode 100644 index 000000000..a5c939086 --- /dev/null +++ b/doc/cbdc-it/cbdc-it.tex @@ -0,0 +1,1304 @@ +\documentclass[a4paper]{article} +\usepackage[T1]{fontenc} +\usepackage[utf8]{inputenc} +\usepackage[top=2cm,bottom=2cm]{geometry} +\usepackage{url} +\usepackage{amsmath} +\usepackage{hyperref} +\usepackage{graphicx} +\usepackage{natbib} +\usepackage[italian]{babel} +\title{Come una banca centrale dovrebbe emettere una moneta digitale} +\author{David Chaum\footnote{david@chaum.com} \\ + xx Network \and + Christian Grothoff\footnote{christian.grothoff@bfh.ch} \\ + BFH\footnote{Università di Scienze Applicate di Berna} + \ e Progetto GNU \and + Thomas Moser\footnote{thomas.moser@snb.ch} \\ + Banca Nazionale Svizzera} +\date{Questa versione: febbraio 2022 \\ + Prima versione: maggio 2020} + +\setlength\parskip{5pt plus 1pt} % More space between paragraphs +\addto\captionsitalian{\renewcommand{\figurename}{Diagramma}} +\AtBeginDocument{\renewcommand{\harvardand}{\&}} +\hyphenation{CBDC} + +\begin{document} + +\maketitle + +\begin{abstract} +Con l'emergere di Bitcoin e delle criptovalute stabili (per es. Diem, +già nota come Libra) recentemente proposte dai colossi del web, le +banche centrali affrontano una crescente concorrenza da parte di +operatori privati che offrono la propria alternativa digitale al +contante fisico. Non trattiamo qui la questione normativa se una banca +centrale debba emettere o meno una moneta digitale. Contribuiamo invece +all'attuale dibattito di ricerca spiegando in che modo una banca centrale +potrebbe farlo, se lo volesse. Proponiamo un sistema basato su token +senza tecnologia di registro distribuito, e mostriamo che le monete +elettroniche emesse in passato, basate solo su software, possono essere +migliorate per tutelare la privacy nelle transazioni, soddisfare i +requisiti normativi in modo efficace e offrire un livello di protezione +resistente ai computer quantistici contro il rischio sistemico per +la privacy. Né la politica monetaria né la stabilità del sistema +finanziario sarebbero realmente interessate da questo sistema, dal +momento che una moneta emessa in questo modo replicherebbe il contante +fisico anziché i depositi bancari. \\ + +JEL: E42, E51, E52, E58, G2 +\\ + +Parole chiave: monete digitali, banca centrale, CBDC, firma cieca (\textit{blind signatures}), +criptovalute stabili, \textit{stablecoins} +\end{abstract} + +\vspace{40pt} + +\section*{Ringraziamenti} +Vorremmo ringraziare Michael Barczay, Roman Baumann, Morten Bech, +Nicolas Cuche, Florian Dold, Andreas Fuster, Stefan Kügel, Benjamin +Müller, Dirk Niepelt, Oliver Sigrist, Richard Stallman, Andreas Wehrli +e tre collaboratori anonimi per i loro commenti e suggerimenti. Le +posizioni, le opinioni, i risultati e le conclusioni o raccomandazioni +espresse in questo documento sono strettamente quelle degli autori. +Non riflettono necessariamente le posizioni della Banca nazionale +svizzera (BNS). La BNS declina ogni responsabilità per eventuali +errori, omissioni o inesattezze che dovessero comparire nel documento. + +Traduzione: Dora Scilipoti, con contributi da Luca Saiu +\newpage + +%\tableofcontents + +%\bibpunct{(}{)}{ e }{a}{}{,} + +\section{Introduzione}\label{1.-introduzione} + +Dall'avvento dei personal computer negli anni ottanta, e più +specificamente da quando nel 1991 la \textit{National Science +Foundation} revocò le restrizioni sull'uso di Internet per scopi +commerciali, c'è stata una ricerca sulla creazione di moneta digitale +per i pagamenti online. La prima proposta è stata quella +di~\cite{Chaum1983}. Sebbene tali metodi siano stati attuati, non hanno +preso piede; le carte di credito sono invece diventate il metodo più +diffuso per i pagamenti online. La proposta di~\cite{Nakamoto} per una +versione puramente \textit{peer-to-peer} di moneta digitale e il +conseguente lancio di Bitcoin avvenuto con successo hanno inaugurato +una nuova era di ricerca e sviluppo di valute digitali. La piattaforma +CoinMarketCap elenca oltre 5.000 criptovalute. Recentemente le banche +centrali hanno iniziato a considerare, o almeno a studiare, +l'emissione di monete digitali~\cite[vedi][]{AuerBoehme,AuerCornelli,Boar,Kiff,Mancini-Griffoli}. + +Attualmente, le banche centrali emettono due tipi di moneta: (i) +riserve sotto forma di conti di regolamento presso le banche centrali, +destinate solo agli operatori dei mercati finanziari, e (ii) divisa +disponibile per tutti sotto forma di banconote. Di conseguenza, la +letteratura sulla moneta digitale di banca centrale (\textit{Central Bank +Digital Currency} - CBDC) distingue tra (a) CBDC all'ingrosso ad +accesso ristretto e (b) CBDC al dettaglio disponibile per il +pubblico~\cite[si veda, ad esempio,][]{Bech}. +Una CBDC all'ingrosso sarebbe meno destabilizzante per il sistema attuale +dato che le banche e gli operatori dei mercati finanziari hanno già +accesso alla moneta digitale della banca centrale sotto forma di conti +presso questa istituzione, che utilizzano per regolare i pagamenti +interbancari. La domanda qui è se la tokenizzazione della moneta di banca +centrale e la tecnologia di registro distribuito (\textit{Distributed Ledger +Technology} - DLT) offrano vantaggi particolari rispetto ai sistemi con +regolamento lordo in tempo reale (\textit{Real-Time Gross Settlement} - RTGS) +esistenti. Finora la risposta è negativa, almeno per i pagamenti +interbancari nazionali~\cite[vedi][]{Chapman}. + +Una CBDC al dettaglio, che sarebbe una nuova forma di moneta di banca +centrale disponibile per il pubblico, potrebbe essere più destabilizzante +per il sistema attuale, a seconda di come è progettata. Più una CBDC +compete con i depositi delle banche commerciali, maggiore è la minaccia +ai finanziamenti bancari, con effetti potenzialmente negativi sul credito +bancario e sull'attività economica~\cite[vedi][]{Agur}. Tuttavia, una +CBDC al dettaglio potrebbe anche essere +vantaggiosa~\cite[vedi][]{Bordo,Berentsen,Bindseil,Niepelt,Riksbank,BoE}. +Mettere a disposizione di tutti una moneta elettronica di banca centrale +esente dal rischio di controparte potrebbe migliorare la stabilità e la +resilienza del sistema di pagamenti al dettaglio. Potrebbe inoltre fornire +un'infrastruttura di pagamento neutrale per incoraggiare la concorrenza, +l'efficienza e l'innovazione. Nel complesso, è probabile che i costi e i +benefici di una CBDC al dettaglio differiscano da un paese all'altro. Per +il punto di vista della Banca nazionale svizzera, che non ha in programma +l'emissione di una CBDC al dettaglio, si veda~\cite{Jordan}. + +Nel presente documento analizziamo la CBDC al dettaglio, ma senza +affrontare la questione se una banca centrale \emph{debba o meno} emetterla. +Ci concentriamo invece sul possibile design di una CBCD. L'interesse +per la progettazione di CBDC è recentemente aumentato +considerevolmente~\cite[si veda, ad esempio,][]{Allen,BoE}. Il design che +proponiamo differisce notevolmente da altre proposte. Il nostro sistema +si basa sulla tecnologia eCash descritta da~\cite{Chaum1983} e \cite{Chaum1990}, +migliorandola. In particolare, proponiamo una CBDC basata su token, solo +con software e senza tecnologia di registro distribuito. La DLT è +un'architettura interessante in assenza di un operatore centrale o se le +entità che interagiscono non accettano di nominare un operatore centrale +fidato. Questo non è certo il caso di una CBDC al dettaglio emessa da una +\emph{banca centrale}. Distribuire il registro delle transazioni della +banca centrale con una \textit{blockchain} non fa che aumentare i costi +di transazione; non porta alcun vantaggio tangibile nell'implementazione +da parte di una banca centrale. L'utilizzo della DLT per emettere moneta +digitale può essere utile in assenza di una banca centrale (ad esempio, +il progetto Sovereign delle Isole Marshall) o se l'intenzione esplicita +è quella di fare a meno di una banca centrale (ad esempio, +Bitcoin).\footnote{Potrebbero esserci casi opportuni di utilizzo della +DLT per le infrastrutture dei mercati finanziari, come gli scambi digitali, +dove sorge la questione di come incorporare la moneta della banca centrale +all'interno di una struttura DLT per eseguire i regolamenti. Tuttavia, +in tali situazioni i potenziali benefici della DLT, ad esempio costi +inferiori o riconciliazione automatica, non derivano da un'emissione +decentralizzata di moneta di banca centrale.} + +La CBDC basata su token che proponiamo consente anche di preservare +una caratteristica fondamentale del contante fisico: la privacy nelle +transazioni. Spesso si sostiene che l'uso della crittografia per la +tutela della privacy richieda così tanta potenza di calcolo da rendere +impraticabile la sua implementazione su dispositivi +portatili~\cite[vedi][]{Allen}. Sebbene questo possa essere vero nel +caso di una tecnologia di registro distribuito, dove la tracciabilità +delle transazioni è necessaria per prevenire la doppia spesa~\cite[][]{Narayanan}, +non lo è nel caso proposto in questo documento, dove si ha un protocollo +di firma cieca di tipo Chaum e la partecipazione di una banca centrale. +La nostra CBDC, basata su firme cieche e un'architettura a due livelli, +garantisce una tutela della privacy nelle transazioni perfetta e +quanto-resistente, fornendo al contempo protezioni sociali che sono di +fatto più potenti rispetto a quelle delle banconote per la lotta al +riciclaggio di denaro (\textit{Anti-Money Laundering} - AML) e al +finanziamento del terrorismo (\textit{Counter Terrorism Financing} - CFT). + +La privacy nelle transazioni è importante per tre motivi. In primo luogo, +protegge gli utenti dal potenziale abuso di monitoraggio e sorveglianza +da parte dei governi. Anche se si pensa di non avere nulla da nascondere, +i piani di sorveglianza di massa restano problematici, se non altro per +il rischio di errori e abusi, soprattutto se condotti senza trasparenza +e responsabilità~\cite[vedi][]{Solove}. In secondo luogo, la privacy nelle +transazioni protegge gli utenti dallo sfruttamento dei dati da parte dei +fornitori di servizi di pagamento. Infine, salvaguarda gli utenti dalla +controparte nelle transazioni in quanto esclude possibili comportamenti +opportunistici successivi o rischi per la sicurezza dovuti a negligenza +o mancata protezione dei dati dei clienti~\cite[vedi][]{Kahn2005}. + +Questo documento è strutturato come segue: nella Sezione II si spiega +la differenza tra la moneta di banca centrale e altri tipi di moneta. +Nella Sezione III si esaminano i modelli di CBDC tipici e generici prima +di proporre il nostro progetto nella Sezione IV. Si considerano poi +gli aspetti normativi e le politiche (V) e il relativo lavoro (VI). +Infine, si conclude (VII). + + +\section{Cos'è la moneta di banca centrale?} + \label{2.-cos'è-la-moneta-di-banca-centrale} + +La moneta è un attivo che può essere utilizzato per acquistare beni e +servizi. Per essere considerato moneta, l'attivo deve essere accettato +da entità diverse dall'emittente. Ecco perché i voucher, ad esempio, +non sono considerati moneta. La moneta autentica deve essere +\emph{comunemente} accettata come mezzo di scambio. Sebbene la moneta +abbia altre funzioni, ad esempio come unità di conto e riserva di valore, +la sua caratteristica distintiva è la sua funzione di mezzo di scambio. +Normalmente l'unità di conto (cioè come avvengono la fissazione dei +prezzi e la contabilizzazione dei debiti) coincide per ragioni +pratiche con il mezzo di scambio. Una separazione può tuttavia +verificarsi se il valore del mezzo di scambio manca di stabilità +rispetto ai beni e servizi scambiati.\footnote{Ciò può accadere +spontaneamente in un ambito caratterizzato da un'inflazione elevata, +ad esempio quando i prezzi sono quotati in USD ma i pagamenti vengono +effettuati in valuta locale. Lo stesso vale per i pagamenti in Bitcoin, +dove i prezzi sono solitamente fissati in USD o altre valute locali a +causa dell'elevata volatilità del Bitcoin. Una separazione può anche +essere progettata appositamente, come nel caso +dell'\textit{Unidad de Fomento} (UF) in Cile o i Diritti Speciali di +Prelievo (DSP) del Fondo Monetario Internazionale (FMI). Tuttavia, +anche in questi casi lo scopo è quello di avere un'unità di conto più +stabile.} La moneta deve anche essere una riserva di valore per fungere +da mezzo di scambio perché deve preservare il suo potere d'acquisto tra +il momento in cui si riceve e quello in cui si spende. In ogni modo, +ci sono molti altri attivi che fungono da riserva di valore, come azioni, +obbligazioni, metalli preziosi e immobili. Pertanto, la caratteristica +di riserva di valore non è distintiva della moneta. + +In un'economia moderna, il pubblico utilizza due tipi diversi di +moneta: (a) moneta statale e (b) moneta privata. La moneta statale viene +generalmente emessa dalla banca centrale, che agisce in qualità di +agente dello Stato. La moneta della banca centrale è disponibile per +alcune istituzioni finanziarie sotto forma di depositi presso la banca +centrale (riserve) e per il pubblico sotto forma di valuta (banconote e +monete), nota anche come «contante». In una economia moderna con valuta +fiat, tale moneta non ha un valore intrinseco. Legalmente è una passività +della banca centrale, sebbene non sia rimborsabile. Nella maggior parte +dei paesi, la moneta della banca centrale è definita come avente corso +legale, il che significa che deve essere accettata per il pagamento dei +debiti monetari, comprese le tasse e le sanzioni legali. Sebbene ciò +garantisca un certo valore alla moneta della banca centrale, lo status +di corso legale non è sufficiente per mantenere un valore stabile. È la +politica monetaria della banca centrale che mantiene il valore della +moneta. Mantenere la stabilità dei prezzi, vale a dire un valore stabile +della moneta rispetto a quello dei beni e dei servizi scambiati, è +infatti una delle principali responsabilità delle banche centrali. + +La maggior parte dei pagamenti in un'economia moderna vengono effettuati +con moneta privata emessa dalle banche commerciali ed è costituita da +depositi bancari a vista che le persone detengono presso queste banche. +Sono depositi che si posssono utilizzare mediante assegni, carte di +debito, carte di credito e altri mezzi di trasferimento di denaro e +costituiscono una passività della banca commerciale di riferimento. Una +caratteristica fondamentale di questi depositi è che le banche commerciali +garantiscono la convertibilità su richiesta in moneta della banca centrale +ad un prezzo fisso, vale a dire, alla pari. I depositanti possono prelevare +i propri fondi in contante o trasferirli ad un valore fisso di 1:1. Le +banche commerciali mantengono stabile il valore della propria moneta +ancorandola a quella della banca centrale. + +Tuttavia, in un sistema di riserva frazionaria, una banca commerciale, +anche se solvibile, potrebbe non avere liquidità a sufficienza per +onorare la sua promessa di convertire i depositi bancari in moneta +della banca centrale (ad esempio, nel caso di una corsa agli sportelli) +in modo tale che i clienti non possano prelevare i propri soldi. Una +banca può anche diventare insolvente e fallire, e di conseguenza i +clienti possono perdere denaro. Per questo motivo le banche commerciali +sono soggette a regolamentazioni volte a mitigare tali rischi. + +Una differenza notevole tra la moneta di una banca centrale e la +moneta privata emessa da una banca commerciale è, pertanto, che +quest'ultima comporta un rischio di controparte. Una banca centrale +può sempre adempiere ai suoi obblighi utilizzando la propria moneta +non rimborsabile. In un'economia nazionale, la moneta della banca +centrale è l'unico attivo monetario esento da rischi di credito e di +liquidità. È pertanto l'attivo tipicamente preferito per regolare i +pagamenti nelle infrastrutture dei mercati finanziari (si veda, per +esempio, \textit{CPMI-IOSCO Principles for Financial Market +Infrastructures}, 2012). Un'altra differenza risiede nella capacità +della moneta della banca centrale di sostenere il sistema monetario +nazionale fornendo un valore di riferimento con cui la moneta delle +banche commerciali mantiene la piena convertibilità. + +A parte le banche commerciali, altre entità private tentano +occasionalmente di emettere moneta; le criptovalute sono solo il +tentativo più recente. Ma a differenza dei depositi bancari, tale +moneta non è comunemente accettata come mezzo di scambio. Questo vale +anche per Bitcoin, la criptovaluta più ampiamente accettata. Un +ostacolo all'utilità delle criptovalute come mezzo di scambio è l'elevata +volatilità del loro valore. In risposta a questo problema sono emerse +le criptovalute stabili, cosiddette «stablecoins». Le +\textit{stablecoin} generalmente tentano di stabilizzare il proprio +valore in due modi: imitando le banche centrali (\textit{stablecoin} +algoritmiche) o imitando le banche commerciali e strumenti di +investimento (\textit{stablecoin} ancorate ad attivi).\footnote{Per una +tassonomia delle \textit{stablecoin}, si veda~\cite{Bullmann}.} + +Le «\textit{stablecoin} algoritmiche» si basano su algoritmi per regolare +l'offerta della moneta. In altre parole, cercano di stabilizzarne il +prezzo attraverso una «politica monetaria algoritmica». Esistono +esempi di tali \textit{stablecoin} (per esempio, Nubits), ma finora nessuna è +riuscita a stabilizzare il proprio valore per molto tempo. + +Le \textit{stablecoin} «ancorate ad attivi» differiscono in base al tipo +di attivo che utilizzano e ai diritti concessi ai possessori. I tipi di +attivi generalmente utilizzati sono: valuta (riserve di banche centrali, +banconote o depositi presso banche commerciali), materie prime (come +l'oro), titoli e talvolta altre criptovalute. La capacità di un tale +schema di stabilizzare il valore della moneta rispetto agli attivi +sottostanti dipende in modo cruciale dai diritti legali acquisiti dai +detentori della moneta. Se una \textit{stablecoin} è riscattabile ad un +prezzo fisso (per es. 1 moneta = 1 USD \\ o 1 moneta = 1 oncia d'oro), +la stabilità si può teoricamente ottenere.\footnote{Se possa stabilizzare +il valore della \textit{stablecoin} anche rispetto ai beni e servizi +scambiati dipende essenzialmente da quanto sia stabile il valore degli +attivi su cui poggia rispetto al valore dei beni e servizi.} Tale strategia +riproduce essenzialmente quella delle banche commerciali garantendo la +convertibilità nell'attivo sottostante su richiesta. Tuttavia, a differenza +dei depositi bancari, che in genere sono coperti solo parzialmente dalle +riserve della banca centrale, le \textit{stablecoin} sono spesso +completamente garantite dalle riserve di attivi sottostanti al fine di +evitare il rischio di liquidità, principalmente perché non dispongono di +tutele pubbliche tali come l'assicurazione dei depositi e il prestatore +di ultima istanza che offrono invece le banche regolamentate. + +Le \textit{stablecoin} che utilizzano le valute come attivi sono anche +dette «stablecoin a valuta fiat». Detenere il 100\% delle +garanzie sotto forma di valuta (banconote o depositi bancari) non risulta però +molto redditizio. Di conseguenza, i fornitori di \textit{stablecoin} hanno +un buon motivo per rispiarmiare sugli attivi passando ad un sistema di +riserva frazionaria, proprio come hanno fatto le banche +commerciali.\footnote{L'incertezza sulla garanzia delle +\textit{stablecoin} può essere uno dei motivi per cui vengono scambiate +al di sotto del loro valore nel mercato parallelo~\cite[vedi][]{Lyons}. +Casi simili si sono storicamente verificati anche con le banconote, quando +erano ancora emesse dalle banche commerciali. Le banconote venivano +scambiate a prezzi scontati nel mercato parallelo prima che l'emissione +fosse nazionalizzata e trasferita alle banche centrali come monopolio.} +Ciò comporta la riduzione degli attivi meno redditizi al minimo ritenuto +necessario per soddisfare il requisito di convertibilità e l'aumento +degli attivi liquidi a rendimento più elevato come i titoli di stato. +Questo migliora la redditività ma aumenta nel contempo il livello +di rischio. Tuttavia, anche se una \textit{stablecoin} fosse garantita +interamente da depositi presso le banche commerciali, rimarrebbe comunque +vulnerabile ai rischi di insolvenza del credito e di liquidità della +relativa banca. Tale rischio può essere evitato effettuando i depositi +presso la banca centrale in modo che siano le riserve di quest'ultima a +garantire la \textit{stablecoin}. Tali \textit{stablecoin} sono state +chiamate «CBDC sintetiche»~\cite[][]{Adrian}. È importante sottolineare che +queste \textit{stablecoin} non sono moneta di banca centrale e quindi +non costituiscono una CBDC in quanto non sono registrate come passività +della banca centrale e, pertanto, rimangono soggette al rischio di +controparte, ovvero al rischio di fallimento dell'emittente. + +Se una \textit{stablecoin} non è rimborsabile ad un prezzo fisso, la sua +stabilità rispetto all'attivo sottostante non è garantita. Se la +\textit{stablecoin} rappresenta comunque una quota di proprietà +dell'attivo sottostante, lo schema ricorda quello di un fondo comune di +investimento chiuso o di un fondo indicizzato quotato (\textit{Exchange-Traded +Fund} - ETF) e si applicano i relativi rischi. Il valore +della moneta dipenderà dal valore patrimoniale netto del fondo, ma il +suo valore effettivo può variare. Se ci sono partecipanti autorizzati +a creare e riscattare \textit{stablecoin} e quindi ad agire come +arbitraggisti, come nel caso degli ETF e come previsto per la +Diem~\cite[][]{Libra}, la deviazione si presume minima. + +Nel complesso, le \textit{stablecoin} hanno maggiori possibilità di +diventare moneta rispetto alle criptovalute, soprattutto se +adeguatamente regolamentate, anche se la disponibilità di CBDC +limiterebbe notevolmente la loro utilità. + +\section{Modelli generici di CBDC} \label{3.-modelli-generici-di-cbdc} + +Come abbiamo visto, la CBDC sarebbe una passività della banca +centrale. Due modelli possibili che si trovano nella letteratura +sull'argomento sono (a) CBDC basata su conti e (b) CBDC basata su +token (o sul valore). Questi modelli corrispondono ai due tipi +esistenti di moneta delle banche centrali e ai relativi sistemi di +pagamento~\cite[][]{Kahn2009}: riserve delle banche centrali +(sistema basato su conti) e banconote (sistema basato su token). Un +pagamento si verifica quando un'attivo monetario viene trasferito da un +pagatore a un beneficiario. In un sistema basato su conti, il +trasferimento avviene addebitando sul conto del pagatore e +accreditando sul conto del beneficiario. In un sistema basato su +token, il trasferimento avviene trasferendo il valore stesso o il +token, ovvero un oggetto che rappresenta l'attivo monetario. Il miglior +esempio di token è il contante (monete o banconote). Pagare in contanti +equivale a consegnare una moneta o una banconota. Non è necessario +registrare il trasferimento, il semplice possesso del token è +sufficiente. Pertanto, le parti non sono tenute a rivelare la propria +identità in nessun momento durante la transazione, entrambe possono +rimanere anonime. Ciononostante, il beneficiario deve essere in grado di +verificare l'autenticità del token. Questo è il motivo per cui le +banche centrali investono notevoli risorse nelle caratteristiche di +sicurezza delle banconote. + +È stato suggerito che la distinzione tra sistemi basati su conti e +quelli basati su token non sia applicabile alle monete digitali~\cite[][]{Garratt}. +Noi al contrario riteniamo che ci sia una differenza significativa. La +differenza essenziale risiede nelle informazioni contenute nell'attivo. +In un sistema basato su conti, gli attivi (i conti) sono riconducìbili +ad una cronologia delle transazioni che include tutte le operazioni di +credito e addebito dei conti. In un sistema basato su token, gli attivi +(i token) contengono solo informazioni sul valore del token e +sull'entità che lo ha emesso. I sistemi basati su token sono quindi +l'unica possibilità per ottenere la stessa privacy nelle transazioni che +offre il contante.\footnote{Sebbene il termine «Bitcoin» suggerisca +l'uso di token, Bitcoin è un sistema basato su conti. L'unica differenza +tra un sistema tradizionale basato su conti e una \textit{blockchain} è +che i conti non sono conservati in un database centrale ma in un +database decentralizzato di solo accodamento.} + +\subsection{CBDC basata su conti}\label{cbdc-basata-su-conti} + +Il modo più semplice per avviare una CBDC sarebbe consentire al +pubblico di detenere conti deposito presso la banca centrale. Ciò +comporta che la banca centrale si facesse responsabile dei controlli per +conoscere i propri clienti (\textit{Know-Your-Customer} - KYC) e di +garantire la conformità con i requisiti per la lotta al riciclaggio di +denaro e al finanziamento del terrorismo. Ciò includerebbe non solo la +gestione del processo iniziale di conoscenza del cliente, ma anche +l'autenticazione dei clienti per le transazioni bancarie, la gestione +delle frodi e delle autenticazioni false positive e false negative. +Data la scarsa presenza fisica delle banche centrali nella società e il +fatto che probabilmente oggi non siano disposte ad eseguire l'autenticazione +dei cittadini su larga scala, qualsiasi CBDC basata su conti richiederebbe +alla banca centrale di delegare questi compiti. Tutti i servizi di +assistenza e manutenzione di tali conti potrebbero essere affidati ad +operatori esterni~\cite[][]{Bindseil}, oppure le banche commerciali potrebbero +essere obbligate per legge ad aprire conti presso la banca centrale per i +propri clienti~\cite[][]{Berentsen}. + +Una CBDC basata su conti darebbe potenzialmente alla banca centrale +l'accesso a molti dati aggiuntivi. Uno dei motivi di preoccupazione è +che i governi potrebbero facilmente mettere in atto una sorveglianza +di massa e imporre sanzioni ai singoli titolari dei conti. La natura +centralizzata di tali interventi li rende poco costosi e facili da +applicare nei confronti di persone o gruppi. Ci sono molti esempi di +sorveglianza abusiva contro critici e oppositori politici, anche nelle +democrazie. Si potrebbe argomentare che le banche centrali indipendenti +siano in grado di salvaguardare tali informazioni dall'intrusione del +governo e dagli abusi politici, ma ciò aprirebbe comunque una nuova +strada alle pressioni politiche che minacciano l'indipendenza delle +banche centrali. Inoltre, un database centrale sarebbe un obiettivo +cospicuo per gli attacchi: anche l'accesso in sola lettura ad una parte +del database potrebbe creare rischi significativi per le persone i cui +dati sarebbero esposti. + +Se dovessero fornire conti bancari per il pubblico, le banche centrali +entrerebbero in diretta concorrenza con le banche commerciali, competizione +che comporterebbe due rischi. In primo luogo, potrebbe minacciare la base +dei depositi delle banche e, all'estremo, portare alla disintermediazione +bancaria. Ciò potrebbe influire negativamente sulla disponibilità di +credito per il settore privato e, di conseguenza, sull'attività +economica~\cite[][]{Agur}. La disintermediazione delle banche potrebbe anche +condurre alla centralizzazione dell'allocazione del credito all'interno +della banca centrale, con ripercussioni negative sulla produttività e +sulla crescita economica. In secondo luogo, la possibilità per le persone +di trasferire i propri depositi nel porto sicuro di una banca centrale +potrebbe accelerare le corse agli sportelli nei periodi di crisi economica. + +Vi sono però argomentazioni contrarie. \cite{Brunnermeier} +sostengono che i trasferimenti di fondi dai depositi ai conti +CBDC porterebbero alla sostituzione automatica del finanziamento +mediante depositi con il finanziamento tramite la banca centrale, il +che andrebbe ad esplicitare la garanzia finora implicita di prestatore +di ultima istanza delle banche centrali. \cite{Berentsen} +sostengono che la concorrenza delle banche centrali potrebbe persino +avere un effetto disciplinare sulle banche commerciali e quindi +aumentare la stabilità del sistema finanziario, dato che queste ultime +sarebbero costrette a consolidare la sicurezza dei propri modelli +economici per eviatare corse agli sportelli. + +% References to Kumhof, Bindseil below should render like this: +% valore (Kumhof &amp; Noone, 2018 e Bindseil, 2020). +% This was fixed by replacing "," with "and" to separate authors in the bib file. +% It also fixed {Kumhof} to render as "Kumhof & Noone". + +Esistono anche proposte per ridurre il rischio di disintermediazione +restringendo o scoraggiando l'uso della CBDC come riserva di valore. Una +delle proposte è di limitare la quantità di CBDC che si può possedere. +Una seconda proposta consiste nell'applicare un tasso di interesse +variabile ai conti in CBDC, in modo che il rendimento sia sempre +sufficientemente inferiore a quello dei conti nelle banche commerciali, +arrivando eventualmente fino a tassi negativi, in modo da rendere la CBDC +meno attraente come riserva di valore~\cite[][]{Kumhof,Bindseil}. Oltre a ciò, +per evitare le corse agli sportelli \citet{Kumhof} suggeriscono che la +CBDC non dovrebbe essere emessa a fronte di depositi bancari ma solo a +fronte di obbligazioni come i titoli di stato. Nel complesso, una CBDC +basata su conti richiederebbe un'analisi più approfondita di queste +problematiche. + +% Back to default style. +%\bibpunct{(}{)}{ e }{,}{}{,} + + +\subsection{CBDC Basata su token e legata al hardware} +\label{cbdc-basata-su-token-e-legata-al-hardware} + +% References to Wojtczuk,Johnston,Lapid below do not render correctly in pdf. Should be: +% compromesse (si veda, ad esempio, Wojtczuk &amp; Rutkowska 2009, Johnston 2010 e Lapid &amp; Wool 2018). +% but we can only either use "," or "e", but not switch AFAIK. +% This was fixed by replacing "," with "and" to separate authors in the bib file. +% It also fixed {Katzenbeisser} to render as "Katzenbeisser et al." + +In alternativa ai conti deposito, una banca centrale potrebbe emettere +token elettronici. Tecnicamente ciò richiede un sistema per garantire che +i token elettronici non possano essere copiati facilmente. Le funzioni +fisicamente non clonabili~\cite[vedi][]{Katzenbeisser} e le aree +sicure nell'hardware~\cite[vedi][]{Alves,Pinto} sono due tecnologie +possibili per la prevenzione della copia digitale. Le funzioni +fisicamente non clonabili, tuttavia, non possono essere scambiate su +Internet (eliminando di fatto l'uso principale delle CBDC) e le precedenti +funzionalità di sicurezza nell'hardware per la prevenzione della copia +sono state ripetutamente +compromesse~\cite[si veda, ad esempio,][]{Wojtczuk,Johnston,Lapid}. + +Un vantaggio fondamentale delle CBDC basate su token rispetto a quelle +basate su conti è che i sistemi tokenizzati funzionerebbero offline, +ovvero, gli utenti potrebbero scambiare token (\textit{peer-to-peer}) +senza coinvolgere la banca centrale, proteggendo così la privacy e la +libertà delle persone. Tuttavia, la disintermediazione che si verifica +quando gli utenti possono scambiare token elettronici senza +intermediari bancari che eseguano i controlli per la conoscenza dei +clienti e le procedure per la lotta al riciclaggio di denaro e al +finanziamento del terrorismo renderebbe difficile la lotta alla +criminalità. + +% References to Soukup,Garcia,Kasper,CCC below do not render correctly in pdf. Should be: +% L’esperienza (si veda, ad esempio, Soukup &amp; Muff 2007, Garcia et al. 2008, Kasper et al. 2010 e CCC e.V. 2017) suggerisce +% but we can only either use "," or "e", but not switch AFAIK. +% This was fixed by replacing "," with "and" to separate authors in the bib file. + +Le schede SIM sono oggi il mezzo più ampiamente disponibile per un +sistema di pagamento sicuro basato su hardware, ma comportano anche +dei rischi. L'esperienza~\cite[si veda, ad esempio,][]{Soukup,Garcia,Kasper,CCC} +suggerisce che qualsiasi dispositivo economicamente riproducibile in grado +di memorizzare token con valore monetario, che una persona possa possedere +e che consenta transazioni offline --- e quindi il furto mediante +clonazione delle informazioni in esso contenute --- sarà l'obiettivo di +attacchi di contraffazione riusciti non appena il valore economico +dell'attacco risulti sostanziale. Tali attacchi provengono anche da +utenti che forzano il proprio hardware~\cite[vedi][]{Allen}. Per +limitare l'impatto di una compromissione, i sistemi con carte di pagamento +che sono stati precedentemente implementati dipendono dalla resistenza +alle manomissioni in combinazione con il rilevamento delle frodi. +Tuttavia, il rilevamento delle frodi richiede la capacità di identificare +i pagatori e tenere traccia dei clienti, il che non è compatibile con la +privacy nelle transazioni. + +\section{Una CBDC basata su token progettata per tutelare la privacy} +\label{4.-una-cbdc-basata-su-token-progettata-per-tutelare-la-privacy} + +La CBDC qui proposta è di tipo «solo software», semplicemente +un'applicazione per smartphone che non richiede alcun hardware aggiuntivo. +Il design fa affidamento su eCash e GNU Taler. Taler fa parte del progetto +GNU, il cui fondatore, Richard Stallman, ha coniato il termine +«\emph{Software Libero}», ora spesso indicato come \textit{Free/Libre +and Open Source Software} (FLOSS).\footnote{Per ulteriori informazioni +su GNU, si veda \url{https://www.gnu.org} e \cite{Stallman}. GNU Taler +è rilasciato sotto la licenza libera \textit{GNU Affero General Public +License} del Progetto GNU. Altri programmi del progetto GNU noti tra gli +economisti sono \textit{R} e \textit{GNU Regression, Econometrics and +Time-series Library} (GRETL). Per un'analisi dei vantaggi del FLOSS +rispetto al software proprietario nel campo della ricerca, si +veda~\cite{Baiocchi}, \cite{Yalta2008} e \cite{Yalta2010}. +Sulle licenze libere e open source, si veda~\cite{Lerner}.} Il software +è considerato libero se la sua licenza concede agli utenti quattro libertà +essenziali: la libertà di eseguire il programma come si desidera, la +libertà di studiare il programma e modificarlo, la libertà di ridistribuire +copie del programma e la libertà di distribuire copie delle versioni +modificate del programma. Il software libero non impedisce la +commercializzazione; fornire supporto tecnico per il software è un modello +di business standard per il FLOSS. + +Dato il gran numero di parti interessate coinvolte in una CBDC al +dettaglio (la banca centrale, il settore finanziario, i venditori e +i clienti) e l'importanza critica dell'infrastruttura, una CBDC al +dettaglio deve essere basata sul FLOSS. Imporre una soluzione +proprietaria, che comporta la dipendenza da un fornitore specifico, +sarebbe probabilmente un ostacolo all'adozione fin dall'inizio. Con il +FLOSS, tutte le parti interessate hanno accesso a ogni dettaglio della +soluzione e il diritto di adattare il software alle proprie esigenze. +Ciò facilita l'integrazione e migliora l'interoperabilità e la +concorrenza tra i fornitori.\footnote{Tuttavia, l'hardware privato +potrebbe avere un ruolo da svolgere. La protezione degli archivi delle +chiavi e di alcune funzioni di controllo, ad esempio, può essere un'area +dove l'hardware dedicato valutato solo da un numero limitato di esperti +può presentare dei vantaggi, nella misura in cui tale sicurezza sia solo +additiva.} Consente inoltre alla banca centrale di soddisfare i requisiti +di trasparenza e responsabilità. I vantaggi del FLOSS riguardo la +sicurezza sono anche ampiamente riconosciuti. La disponibilità del codice +sorgente e la libertà di modificarlo facilitano l'identificazione degli +errori e la loro rapida correzione. \footnote{Ad esempio, un bollettino +sulla sicurezza informatica emesso dall'Agenzia per la sicurezza nazionale +degli Stati Uniti (NSA) nell'aprile 2020 esorta gli utenti a dare la +priorità al software libero nella scelta e nell'utilizzo dei servizi +collaborativi per le comunicazioni su Internet: «Lo sviluppo open source +garantisce trasparenza sulla robustezza del codice e la sua conformità +alle migliori pratiche di programmazione, evitando l'introduzione di +vulnerabilità o punti deboli che potrebbero mettere a rischio utenti e +dati» (U/OO/134598-20).} + +Nell'architettura che proponiamo, tutte le interazioni tra consumatori +e venditori si fanno con le banche commerciali, ma la creazione di moneta +e il database sono forniti esclusivamente dalla banca centrale. Le banche +commerciali autenticano i clienti quando ritirano CBDC così come i +venditori o beneficiari quando le ricevono. Quando spendono CBDC, +invece, i clienti o pagatori devono solo autorizzare le transazioni senza +bisogno di identificarsi. I pagamenti risultano più economici, più facili +e più veloci, evitando al contempo interferenze con la privacy~\cite[][]{Dold}. +L'autenticazione dei clienti quando ritirano CBDC, nonché dei venditori +o beneficiari quando le ricevono, consente altresì di adempire alle +normative sulla conoscenza dei clienti e sulla lotta al riciclaggio di +denaro e al finanziamento del terrorismo. + +La CBDC che si propone in questo documento è un vero e proprio +strumento digitale al portatore perché quando l'utente preleva una +somma di denaro sotto forma di numero, tale numero viene «accecato» o +nascosto dallo smartphone con un'apposita crittografia. Nel sistema +stesso, una moneta è una coppia di chiavi pubblica-privata dove la +chiave privata è nota solo al proprietario della moneta.\footnote{In +Bitcoin, un sistema basato su conti, la coppia di chiavi è un conto +dove la chiave pubblica rappresenta l'«indirizzo» e quindi una sorta di +«identità», anche se pseudonimo.} La moneta trae il suo valore +finanziario dalla firma della banca centrale apposta sulla chiave +pubblica della moneta. La banca centrale firma con la propria chiave +privata e detiene più coppie di chiavi di valore per apporre la firma +cieca su monete di diverso valore unitario. Il venditore può utilizzare +la corrispondente «chiave pubblica» della banca centrale per verificare +la firma. Tuttavia, al fine di garantire che la moneta non sia stata +copiata e già ritirata da un altro beneficiario (cioè che non sia stata +«spesa due volte»), il venditore deve depositare la moneta affinché la +banca centrale possa confrontarla con un archivio di monete ritirate. +Poiché né la banca commerciale né la banca centrale vedono il numero +della moneta durante il prelievo, in seguito, quando il venditore +deposita la moneta, non si sa quale utente l'abbia ritirata. L'accecamento +e la privacy che ne deriva fanno di questa tipologia di CBDC un vero e +proprio strumento digitale al portatore. + +Nell'analisi che segue forniamo una panoramica approfondita della +tecnologia e mostriamo come si può integrare con il sistema bancario +esistente per creare una CBDC. \citet{Dold} fornisce ulteriori +dettagli. + +\subsection{Componenti fondamentali}\label{componenti-fondamentali} + +Di seguito si descrivono i componenti principali del protocollo, comprese +le basi matematiche per una delle possibili rappresentazioni delle +primitive crittografiche utilizzate, allo scopo di illustrare in +che modo potrebbe funzionare un'implementazione. Considerando che +esistono altri modelli matematici equivalenti per ciascun componente, +presentiamo solo la più semplice delle soluzioni sicure a noi note. + +\emph{Firme digitali.} L'idea che sta alla base delle firme digitali in +uno schema di firma a chiave pubblica è quella di garantire che il +titolare della chiave privata sia l'unico in grado di firmare un +messaggio, mentre la chiave pubblica consente a chiunque di verificare +la validità della firma.\footnote{La crittografia a chiave pubblica è +stata introdotta da~\cite{Diffie} e le prime implementazioni di firme +digitali sono state quelle di~\cite{Rivest}.} Il risultato della funzione +di verifica della firma è la dichiarazione binaria «vero» o «falso». Se +il messaggio è firmato con la chiave privata che appartiene alla chiave +pubblica di verifica, il risultato è «vero», altrimenti è «falso». +Nella nostra proposta il messaggio è una moneta o una banconota con un +numero di serie, e la firma della banca centrale ne attesta la +validità. Sebbene GNU Taler utilizzi per impostazione predefinita le +moderne firme EdDSA~\cite[vedi][]{Bernstein2012}, qui presentiamo un +semplice schema di firma crittografica basato su RSA~\cite[][]{Rivest}, un +sistema crittografico ben studiato.\footnote{Per un'analisi della +lunga storia del crittosistema RSA e uno studio degli attacchi a questo +sistema, si veda~\cite{Boneh}.} Tuttavia, in linea di principio, è +possibile utilizzare qualsiasi tecnologia di firma crittografica +(DSA, ECDSA, EdDSA, RSA, ecc.) + + +Per generare una chiave RSA, il firmatario prende prima due grandi +numeri primi indipendenti $p$ e $q$ e calcola $n = \emph{pq}$, +nonché la funzione phi di Eulero +$\phi(n) = (p - 1)(q - 1)$. +Quindi, si può utilizzare qualsiasi $e$ con $1 < e < \phi(n)$ e +$\gcd(e, \phi(n)) = 1$ per definire una chiave pubblica $(e,n)$. +La condizione che il massimo comune denominatore ($\texttt{MCD}$) di $e$ e +$\phi(n)$ debba essere 1 (cioè, che devono essere +primi tra loro) assicura che l'inverso di +$e \mod \phi(n)$ esista. +Questo inverso è la +corrispondente chiave privata $d$. Data $\phi(n)$, la chiave +privata $d$ può essere calcolata mediante l'algoritmo esteso +di Euclide tale che +$d \cdot e \equiv 1 \mod \phi(n)$. + +Data la chiave privata $d$ e la chiave pubblica $(e, n)$, una semplice +firma RSA +$s$ su un messaggio $m$ è +$s \equiv m^{d} \mod n$. +Per verificare la firma si calcola +$m' \equiv s^{e} \mod n$. +Se $m'$ e $m$ corrispondono, la firma è valida e dimostra che il +messaggio è stato firmato con la chiave privata che corrisponde alla +chiave pubblica di verifica (autenticazione del messaggio) e che il +messaggio non è stato modificato durante il transito (integrità del +messaggio). In pratica, le firme vengono poste sull'hash dei messaggi +piuttosto che sui messaggi stessi. Le funzioni di hash calcolano le +impronte digitali dei messaggi (\textit{digest}), che sono identificatori +univoci e brevi per i messaggi. Firmare un hash breve è molto più veloce +che firmare un messaggio di grandi dimensioni, e la maggior parte degli +algoritmi di firma funzionano solo su input relativamente brevi.\footnote{Nel +caso del crittosistema RSA, il limite di lunghezza è di +$\log_{2}n$ bit.} + +\emph{Firme cieche.} Utilizziamo le firme cieche introdotte +da~\cite{Chaum1983} per tutelare la privacy degli acquirenti. Una firma +cieca viene utilizzata per creare una firma crittografica per un messaggio +senza rivelare al firmatario il contenuto del messaggio. Nella nostra proposta, +ciò impedisce alle banche commerciali e alla banca centrale di poter risalire +all'acquirente tracciando gli acquisti. In linea di principio, la nostra +proposta funziona con qualsiasi sistema di firma cieca, ma la soluzione migliore +rimane la variante basata su RSA descritta da~\cite{Chaum1983}. + +L'accecamento viene eseguito dai clienti, che accecano le proprie +monete prima di trasmetterle alla banca centrale per la firma. I +clienti non devono quindi affidare alla banca centrale la tutela della +propria privacy. Inoltre, l'accecamento con RSA fornirebbe protezione +della privacy anche contro gli attacchi informatici quantistici. La +banca centrale, dal canto suo, predispone più coppie di chiavi di +valore per apporre la firma cieca su monete di diverso valore +unitario, e fornisce le corrispondenti chiavi pubbliche +$(e, n)$ per tali valori. + +Sia $f$ il valore di hash di una moneta e quindi l'identificatore +univoco per questa moneta. Il cliente che preleva la moneta prima +genera un fattore di accecamento casuale $b$ e calcola +$f' \equiv fb^{e} \mod n$ +con la chiave pubblica della banca centrale per quel valore. +La moneta accecata $f'$ viene quindi trasmessa alla banca centrale per +la firma. La banca centrale firma $f'$ con la sua chiave +privata $d$ calcolando la firma cieca +$s' \equiv \left(f' \right)^{d} \mod n$, appone +la firma $s'$ alla moneta accecata $f'$ e restituisce la coppia +$(s',f')$ al cliente. Il cliente può quindi rimuovere l'accecamento +della firma calcolando +$s \equiv s'b^{- 1} \mod n$. +Ciò è possibile perché +$\left( f' \right)^d = f^db^{ed} = f^db$, e quindi +moltiplicando $s'$ con $b^{- 1}$ si ottiene $f^d$, che è una firma RSA +valida su $f$ come prima: +$s^e \equiv f^{de} \equiv f \mod n$. + +Nella proposta originale di Chaum, le monete erano dei semplici +gettoni. Quel che vogliamo, invece, è che i consumatori possano +utilizzare le firme digitali per stipulare contratti. A tal fine, ogni +volta che un portafoglio digitale preleva una moneta, in primo luogo +crea per la moneta una chiave privata casuale $c$ e calcola la +corrispondente chiave pubblica $C$ per creare firme digitali con i +normali sistemi di firma crittografica (come DSA, ECDSA, EdDSA e +RSA). Quindi si deriva $f$ mediante una funzione di hash crittografica +dalla chiave pubblica $C$, prima che la banca centrale ne apponga la +firma cieca (utilizzando un nuovo fattore di accecamento casuale per +ciascuna moneta). Ora il cliente può utilizzare $c$ per firmare +elettronicamente gli acquisti, spendendo così la moneta. + +Come visto sopra, la banca centrale andrebbe a predisporre coppie di +chiavi diverse per ogni valore unitario di moneta e pubblicherebbe le +chiavi pubbliche che i clienti userebbero per prelevare denaro. Queste +chiavi di valore, e quindi le monete, avrebbero una data di scadenza +prima della quale dovrebbero essere spese o scambiate con monete +nuove. Ai clienti verrebbe concesso un certo periodo di tempo per +scambiare le monete. Un processo simile esiste per le banconote +fisiche, dove le serie di banconote vengono regolarmente rinnovate per +essere dotate delle più recenti caratteristiche di sicurezza, tranne +per il fatto che le banconote generalmente rimangono in circolazione +per decenni anziché per pochi anni o mesi.\footnote{In Svizzera, +ad esempio, la Banca nazionale svizzera ha iniziato a ritirare dalla +circolazione l'ottava serie di banconote nell'aprile 2016. Questa serie +era stata messa in circolazione alla fine degli anni novanta. Dal 1 +gennaio 2020, tuttavia, tutte le banconote a partire dalla sesta serie +(emesse nel 1976) fino alle serie future restano valide e possono essere +scambiate a tempo indeterminato con banconote correnti.} + +Da un punto di vista tecnico, una data di scadenza offre due vantaggi. +In primo luogo, migliora l'efficienza del sistema perché la banca +centrale può cancellare i dati scaduti, evitando così di dover +archiviare e poi cercare in un elenco sempre crescente di monete +(spese) per rilevare una doppia spesa. In secondo luogo, riduce i +rischi per la sicurezza dato che la banca centrale non deve +preoccuparsi di attacchi alle proprie chiavi (private) di valore ($d$) +scadute. Inoltre, anche se una chiave privata venisse compromessa, il +periodo durante il quale l'attaccante può utilizzarla è breve. In aggiunta, +l'addebito di una commissione di cambio consentirebbe alla banca centrale di +applicare tassi di interesse negativi, se ritenuto necessario. La banca centrale +potrebbe anche, se lo desidera, fissare un limite di conversione per cliente in +considerazione dell'antiriciclaggio e l'antiterrorismo (soglia di «contante») o +per motivi di stabilità finanziaria (per prevenire accaparramenti e corse agli +sportelli). + +\emph{Protocollo di scambio di chiavi.} GNU Taler utilizza un protocollo +di scambio di chiavi in un modo particolare per fornire un collegamento +tra la moneta originale e il resto reso per quella stessa moneta. Ciò +garantisce che il resto possa sempre essere reso senza compromettere +la trasparenza del reddito e la privacy dei consumatori. Lo stesso +meccanismo si può utilizzare per i rimborsi anonimi ai clienti. Il +protocollo gestisce anche i guasti alla rete e ai componenti, +assicurando che i pagamenti siano andati a buon fine o siano stati +definitivamente annullati e che tutte le parti abbiano una prova +crittografica dell'esito. Questo corrisponde all'incirca agli scambi +atomici nei protocolli \textit{interledger} o allo scambio equo nei +tradizionali sistemi \textit{e-cash}. + +La costruzione matematica più comune per un protocollo di scambio di +chiavi è la costruzione~\cite{Diffie}, che +consente a due parti di derivare una chiave segreta condivisa. A tale +scopo, condividono due parametri di dominio $p$ e $g$, che possono +essere pubblici, dove $p$ è un numero primo grande e $g$ è una radice +primitiva modulo $p$.\footnote{Un intero $g$ è una radice primitiva +modulo $p$ se per ogni intero $a$ coprimo a $p$ esiste un intero $k$ +per il quale +$g^k \equiv a \mod p$. +In pratica, $g$ dovrebbe essere una radice primitiva $(p-1)$-esima, detta +anche generatore, al fine di prevenire attacchi a sottogruppi come quelli +Pohlig-Hellman~\cite[vedi][]{Lim}.} Ora, le due parti scelgono le loro +chiavi private \emph{a} e \emph{b}, che sono due numeri interi grandi. +Con queste chiavi private e i parametri di dominio, generano le +rispettive chiavi pubbliche +$A \equiv g^{a} \mod p$ e $B \equiv g^{b} \mod p$. +Ciascuna parte può ora utilizzare la propria chiave privata e la chiave +pubblica dell'altra parte per calcolare la chiave segreta condivisa +$k \equiv \left( g^b \right)^{a} \equiv \left( g^{a} \right)^{b} \equiv g^{\text{ab}} \mod p$.\footnote{ +Lo stesso meccanismo potrebbe essere utilizzato per garantire +che le monete non vengano trasferite a terzi durante il prelievo. A +questo scopo, gli utenti devono salvaguardare una chiave di identità a +lungo termine. Il processo di prelievo potrebbe quindi essere +costruito allo stesso modo di quello utilizzato da GNU Taler per dare +il resto, tranne per il fatto che quando si preleva dal conto bancario +del cliente verrebbe utilizzata la chiave d'identità a lungo termine +del cliente al posto della moneta originale. Tuttavia, le garanzie +sulla privacy potrebbero decadere se il cliente non protegge la chiave +d'identità a lungo termine, con il conseguente rischio di furto di +tutte le monete residue. Dato che il rischio nei trasferimenti a terzi +quando si prelevano monete è basso, non è chiaro se questa riduzione +del rischio possa essere un buon compromesso.} + +Per ottenere il resto, il cliente parte dalla chiave privata della +moneta parzialmente spesa $c$. Sia $C$ la chiave pubblica corrispondente, +per esempio +$C = g^{c} \mod p$. +Quando la moneta fu parzialmente spesa in precedenza, la banca centrale +registrò la transazione relativa a $C$ nel proprio database. Per +semplicità, assumiamo che esista un valore unitario che corrisponda +esattamente a questo valore residuo. In caso contrario, il protocollo si +riavvia finché non viene reso tutto il resto. Sia $(e,n)$ la +chiave di valore per il resto da rendere. + +Per ottenere il resto, l'acquirente crea prima $\kappa$ chiavi di +trasferimento private $t_{i}$ per \\ +$i \in \left\{ 1,\ldots,\kappa \right\}$ e calcola le +corrispondenti chiavi pubbliche $T_{i}$. Queste chiavi di +trasferimento $\kappa$ sono semplicemente coppie di chiavi +pubbliche-private che consentono al cliente di eseguire localmente il +protocollo di scambio di chiavi, con il cliente che gioca su entrambi +i lati del processo, $\kappa$ volte tra $c$ e ogni $t_{i}$. +Se si usa Diffie-Hellman come protocollo per lo scambio di chiavi, si +ottiene +$T_{i} \equiv g^{t_{i}} \mod p$. + +Il risultato è composto da tre trasferimenti +$K_{i} \equiv \emph{KX}(c,t_{i})$. Il protocollo di scambio di chiavi +può essere utilizzato in diversi modi per ottenere lo stesso valore +$K_{i} \equiv \emph{KX}(C,t_{i}) = \emph{KX}(c,T_{i})$. +Data $K_{i}$, il cliente utilizza una funzione crittografica hash $H$ +per ricavare i valori +$(b_{i},c_{i}) \equiv H(K_{i})$, dove +$b_{i}$ è un fattore di accecamento valido per la chiave di valore +$(e,n)$ e $c_{i}$ +è una chiave privata per la nuova moneta da ottenere come resto. +$c_{i}$ deve essere adatta sia per creare firme crittografiche sia per +un uso futuro con il protocollo di scambio di chiavi +(come $c$, per ottenere resto a partire dal resto). +Sia $C_{i}$ la chiave pubblica corrispondente a $c_{i}$. +Il cliente chiede quindi alla banca centrale di creare una firma cieca su +$C_{i}$ per $i \in \{ 1,\ldots,\kappa\}$.\footnote{Se dovesse essere +utilizzato il crittosistema RSA per le firme cieche, useremmo +$f \equiv \emph{FDH}_{n}(C_{i})$, dove +$\emph{FDH}_{n}()$ +è l'hash del dominio completo sul dominio $n$.} In questa richiesta, il +cliente si impegna anche con le chiavi pubbliche +$T_{i}$. +La richiesta è autorizzata mediante una firma effettuata con la chiave +privata $c$. + +Invece di restituire direttamente la firma cieca, la banca centrale +chiede prima al cliente di dimostrare che ha utilizzato correttamente la +costruzione di cui sopra fornendo +$\gamma \in \left\{ 1,\ldots,\kappa \right\}$. +Il cliente deve quindi mostrare alla banca centrale la +$t_{i}$ per $i \neq \gamma$. +La banca centrale può quindi calcolare +$K_{i} \equiv \emph{KX}(C,t_{i})$ e ricavare i valori +$(b_{i},c_{i})$. Se per tutte le +$i \neq \gamma$ la $t_{i}$ fornita dimostra che il cliente ha utilizzato +correttamente la costruzione, la banca centrale restituisce la firma +cieca su $C_{\gamma}$. +Se il cliente non fornisce una prova corretta, il valore residuo della +moneta originale viene perso. Questo penalizza efficacemente coloro che +tentano di eludere la trasparenza del reddito con un'aliquota fiscale +stimata di $1 - \frac{1}{\kappa}$. + +Per evitare che un cliente cospiri con un venditore che sta tentando di +evadere il fisco, la banca centrale consente a chiunque +conosca $C$ di ottenere, in qualsiasi momento, i valori di +$T_{\gamma}$ +e le firme cieche di tutte le monete collegate alla moneta originaria $C$. +Ciò permette al possessore della moneta originaria, che conosce $c$, di +calcolare +$K_{\gamma} \equiv \emph{KX}( c,T_{\gamma})$ +e da lì ricavare +$(b_{i},c_{i})$ +per, infine, rimuovere la firma cieca. Di conseguenza, un venditore che +nasconde il proprio reddito in questo modo formerebbe solo un'accordo +economico limitato con il cliente invece di ottenere il controllo esclusivo. + +\hypertarget{architettura-del-sistema}{% +\subsection{Architettura del sistema}\label{architettura-del-sistema}} + +Uno degli obiettivi principali della nostra architettura è garantire +che le banche centrali non debbano interagire direttamente con i +clienti né conservare alcuna informazione su di loro, ma solo tenere +un elenco delle monete spese. L'autenticazione è delegata alle banche +commerciali, che dispongono già dell'infrastruttura necessaria. I +protocolli di prelievo e deposito raggiungono la banca centrale +tramite una banca commerciale in qualità di intermediaria. Dal punto +di vista del cliente, il processo è analogo al prelievo di contanti da +un bancomat. La transazione tra la banca commerciale dell'utente e la +banca centrale avviene in background. La procedura per il prelievo di +CBDC è illustrata nel diagramma~\ref{fig:fig1}. + +\begin{figure}[h!] + \includegraphics[width=\textwidth]{diagramma1-it.png} + \caption{Prelievo di CBDC} + \label{fig:fig1} +\end{figure} + +Il cliente (1) invia i dati di accesso alla propria banca commerciale +utilizzando le relative procedure di autenticazione e autorizzazione. +Quindi il telefono (o il computer) del cliente ottiene la chiave di +valore pubblica $(e, n)$ fornita dalla banca centrale per quel valore; (2) +calcola quindi una coppia di chiavi per la moneta, con una chiave +privata $c$ e una chiave pubblica $C$, e sceglie un fattore di accecamento +$b$. La chiave pubblica della moneta viene quindi sottoposta a hash \\ +($\to$ $f$) e accecata ($\to$ $f'$). Quindi il dispositivo del cliente (3) +invia $f'$ insieme all'autorizzazione a prelevare la moneta e ad +addebitarla dal conto del cliente presso la banca commerciale tramite un +canale sicuro stabilito. La banca commerciale (4) addebita quindi +l'importo dal conto deposito del cliente, (5) autorizza digitalmente la +richiesta utilizzando la firma digitale specifica della propria filiale +e inoltra la richiesta e la moneta accecata alla banca centrale per la +firma. La banca centrale (6) sottrae il valore della moneta dal conto +della banca commerciale, appone la firma cieca sulla moneta +utilizzando la chiave privata che detiene per il relativo valore e (7) +restituisce la firma cieca $s'$ alla banca commerciale. La banca +commerciale (8) inoltra la firma cieca $s'$ al portafoglio elettronico +del cliente. Infine, il dispositivo del cliente (9) utilizza $b$ per +rimuovere l'accecamento dalla firma ($\to$ $f$) e salva la moneta appena +coniata $(c, s)$. + +Per spendere CBDC, la procedura è analoga al pagamento in contanti. +Tuttavia, per consolidare la transazione, il venditore deve depositare +la moneta. La procedura per spendere CBDC è illustrata nel diagramma 2. + +\begin{figure}[h!] + \includegraphics[width=\textwidth]{diagramma2-it.png} + \caption{Spendere e depositare CBDC} + \label{fig:fig2} +\end{figure} + +Un cliente e un venditore negoziano un contratto commerciale. Il +cliente (1) utilizza una moneta elettronica per firmare il contratto o +l'atto di vendita con la chiave privata $c$ della moneta e trasmette la +firma al venditore. La firma di una moneta su un contratto con una +moneta valida è l'istruzione del cliente di pagare il venditore, che è +identificato dal conto bancario nel contratto. Se una singola moneta +non fosse sufficiente per coprire l'importo totale, i clienti possono +firmare il contratto con più monete. Il venditore (2) convalida quindi +la firma della moneta sul contratto e la firma $s$ della banca centrale +su $f$, che corrisponde a quella della moneta $C$ con le rispettive +chiavi pubbliche, e inoltra la moneta firmata (insieme alle +informazioni sul conto del venditore) alla banca commerciale del +venditore. La banca commerciale del venditore (3) conferma che il +venditore è un suo cliente e inoltra la moneta firmata alla banca +centrale. La banca centrale (4) verifica le firme e controlla il +proprio database per accertarsi che la moneta non sia già stata spesa. +Se tutto è in ordine, la banca centrale (5) aggiunge la moneta +all'elenco delle monete spese, l'accredita sul conto della banca +commerciale presso la banca centrale e (6) invia una conferma in tal +senso alla banca commerciale. Quindi la banca commerciale (7) +accredita la moneta sul conto del venditore e (8) gli invia una +notifica. Il venditore (9) consegna il prodotto o servizio al cliente. +L'intera operazione richiede poche centinaia di millisecondi. + +\hypertarget{considerazioni-sulla-sicurezza}{% +\subsection{Considerazioni sulla sicurezza} +\label{considerazioni-sulla-sicurezza}} + +Nella nostra proposta, occorre che la banca centrale gestisca un +database e un servizio online ad alta disponibilità. Poiché le monete +elettroniche possono essere copiate dagli utenti, solo con i controlli +online si può prevenire in modo efficace la doppia spesa. Sebbene +nella teoria esistano soluzioni per identificare a posteriori gli +utenti che effettuano una doppia spesa~\cite[vedi][]{Chaum1990}, +queste soluzioni creano rischi economici sia per gli utenti che per la +banca centrale a causa del ritardo nell'identificazione di +transazioni fraudolente. Il rilevamento online della doppia spesa +elimina questo rischio, ma significa anche che sarà impossibile +effettuare le transazioni se la connessione Internet alla banca +centrale non è disponibile. + +La banca centrale dovrà anche proteggere la riservatezza delle chiavi +private che utilizza per firmare le monete e altri messaggi di +protocollo. Se le chiavi di firma della banca centrale dovessero +essere compromesse, ad esempio da un computer quantistico, da un +attacco fisico ai \textit{datacenter} o anche da qualche nuovo algoritmo +% FIXME: +% forme alternative: +% 1) "rimborsare AGLI utenti ... tutte le monete non spese" +% 2) "rimborsare gli utenti ... DI tutte le monete non spese" +%FIXED +imprevisto, è possibile rimborsare agli utenti --- in tutta sicurezza e +senza compromettere la privacy --- tutte le monete non spese. La banca +centrale annuncerebbe la revoca della chiave tramite l'\textit{Application +Programming Interface} (API), che verrebbe rilevata dai portafogli, +avviando quindi il seguente protocollo di aggiornamento: l'utente +svela alla banca centrale la chiave pubblica $C$ della moneta, la firma +$s$ della banca centrale e il fattore di accecamento $b$, consentendo così +alla banca centrale di verificare il legittimo prelievo dell'utente e +di rimborsare il valore della moneta non spesa. Per rilevare una +possibile compromissione della propria chiave, la banca centrale può +monitorare il database in cerca di depositi che eccedano i prelievi. + +\subsection{Scalabilità e costi}\label{scalabilità-e-costi} + +Lo schema che proponiamo sarebbe efficiente ed economico quanto i +moderni sistemi RTGS attualmente utilizzati dalle banche centrali. + +La scalabilità si riferisce al costo di aumentare la potenza di +calcolo in modo che si possa concludere un numero crescente di +transazioni in tempi adeguati. Il costo complessivo del sistema può +essere basso in quanto la CBDC qui proposta si basa interamente su +software. Le monete spese devono essere conservate fino alla scadenza +della coppia di chiavi di valore utilizzata per firmare le monete, ad +esempio tramite un ciclo annuale continuo, che mantiene limitata la +dimensione del database. La potenza di calcolo e la larghezza di banda +necessarie aumentano della stessa quantità per ogni transazione, spesa +o deposito addizionali, dato che le transazioni sono intrinsecamente +indipendenti l'una dall'altra. Questa ulteriore potenza si ottiene +semplicemente aggiungendo più hardware, una pratica spesso conosciuta +come partizionamento o \textit{sharding}. Grazie al cosiddetto +\textit{consistent hashing}, le aggiunte di hardware non risultano +dirompenti. Si può anche utilizzare qualsiasi tipo di database. + +Più nello specifico, la logica del \textit{front-end} presso la banca +centrale deve solo eseguire poche operazioni di firma, e un singolo +processore può eseguirne alcune migliaia al secondo~\cite[vedi][]{Bernstein2020}. +Se un unico sistema non fosse sufficiente, è facile aggiungere altri +server \textit{front-end} e invitare le varie banche commerciali a +bilanciare le loro richieste nella \textit{server farm} o +utilizzare un sistema di bilanciamento del carico per distribuire le +richieste all'interno dell'infrastruttura della banca centrale. + +I server \textit{front-end} devono comunicare con un database per +effettuare le transazioni e prevenire la doppia spesa. Un unico server +di database moderno dovrebbe essere in grado di gestire in modo +affidabile decine di migliaia di operazioni al secondo. Le operazioni +possono essere facilmente distribuite su più server di database +semplicemente assegnando a ciascuno un intervallo di valori da +gestire. Tale configurazione garantisce che le singole transazioni non +incrocino mai le partizioni. Pertanto, anche i sistemi \textit{back-end} +dovrebbero scalare in modo lineare con le risorse di calcolo messe a +disposizione, partendo sempre da una solida base di riferimento per un +singolo sistema. + +I \textit{front-end} devono anche comunicare con i \textit{back-end} per +mezzo di un'interconnessione. Queste interconnessioni possono +supportare un gran numero di transazioni al secondo. La dimensione di +una singola transazione è in genere di circa 1–10 kilobyte. Pertanto, +i \textit{datacenter} di oggi, che scambiano informazioni a 400 Gbit/s, +possono supportare milioni di transazioni al secondo. + +%FIXME: +% +% Sotto appare "Probabilmente + congiuntivo". Suggerirei +% di cambiarlo con una forma all'indicativo. Qui si trova +% una discussione a riguardo: +% https://italian.stackexchange.com/questions/3653/probabilmente-indicativo-o-congiuntivo +% Not incorrect but FIXED anyway. + +Infine, il costo totale del sistema è basso. Il costo principale è +rappresentato dall'archiviazione a lungo termine di 1–10 kilobyte +per transazione. Gli esperimenti su un prototipo di GNU Taler che +utilizzava i prezzi di \textit{Amazon Web Service} hanno stabilito +che il costo del sistema (archiviazione, larghezza di banda e capacità +di calcolo) su larga scala sarebbe inferiore a 0,0001 USD per +transazione~\cite[per i dettagli sui dati, si veda][]{Dold}. + +\section{Considerazioni normative e politiche} + \label{5.-considerazioni-normative-e-politiche} + +Nella soluzione che proponiamo, la banca centrale non conosce +l'identità dei consumatori o dei venditori né l'importo totale delle +transazioni, ma vede solo il momento in cui le monete elettroniche vengono +rilasciate e quando vengono riscattate. Le banche commerciali continuano a +fornire l'autenticazione cruciale di consumatori e venditori e, in particolare, +custodiscono le informazioni che acquisiscono per la conoscenza dei clienti +(KYC). Le banche commerciali osservano quando i venditori ricevono fondi e, se +necessario, possono limitare la quantità di CBDC per transazione che +un singolo venditore può ricevere. Inoltre, le transazioni sono +collegate ai relativi contratti con i clienti. La conseguente +trasparenza del reddito consente al sistema di soddisfare i requisiti +delle normative sulla lotta al riciclaggio di denaro e al +finanziamento del terrorismo (AML e CFT). In caso vengano rilevate +anomalie nei redditi dei venditori, la banca commerciale e +l'autorità fiscale o giudiziaria possono ottenere e ispezionare i +contratti relativi ai pagamenti sospetti al fine di verificarne la +legittimità. La trasparenza del reddito risultante è anche una forte +misura contro l'evasione fiscale perché i venditori non possono +sottodichiarare il proprio reddito o evadere le tasse sulle vendite. +Nel complesso, il sistema implementa gli approcci~\textit{privacy-by-design} +e \textit{privacy-by-default} (come richiesto, ad esempio, +dal Regolamento generale sulla protezione dei dati dell'UE, GDPR). I +venditori non apprendono necessariamente l'identità dei propri clienti, +le banche possiedono solo le informazioni necessarie sulle attività dei +propri clienti e la banca centrale non ha accesso ai dettagli sulle +attività dei cittadini. + +In alcuni paesi le normative impongono limiti per i prelievi e i +pagamenti in contanti. Tali restrizioni possono essere implementate +anche per la CBDC nel progetto proposto. Ad esempio, è possibile +stabilire una soglia per l'importo giornaliero che i consumatori possono +prelevare, oppure limitare l'importo totale di CBDC che le banche +commerciali possono convertire. + +La disintermediazione del settore bancario è uno dei rischi di +instabilità finanziaria spesso sollevato per quanto riguarda la CBDC +al dettaglio. In particolare, una CBDC al dettaglio potrebbe +facilitare l'accumulo di ingenti somme di denaro della banca +centrale, il che potrebbe avere un impatto negativo sul finanziamento +alle banche mediante depositi perché il pubblico deterrebbe meno +denaro sotto forma di depositi bancari. Per i paesi le cui valute +fungono da valute rifugio, ciò potrebbe anche portare ad un aumento +degli afflussi di capitali durante i periodi globali di avversione al +rischio, dando luogo ad ulteriori pressioni sui tassi di cambio. +Quello che quindi potrebbe rappresentare un serio problema nel caso di +una CBDC basata su conti, lo sarebbe molto meno con una CBDC basata +su token. Innanzitutto, l'accumulo di una CBDC basata su token comporta +rischi di furto o perdita simili a quelli legati all'accumulo di +contanti. Tenere poche centinaia di dollari su uno smartphone è +probabilmente un rischio accettabile per molti, ma detenere una somma +molto alta è probabilmente un rischio meno accettabile. Pertanto, non +ci aspettiamo un accaparramento significativamente maggiore rispetto a +quello del denaro fisico. + +Tuttavia, se l'accumulo o la massiccia conversione dei depositi +bancari in CBDC dovessero destare preoccupazione, la banca centrale +avrebbe diverse opzioni. Come si è spiegato, secondo il progetto +proposto le banche centrali fissano una data di scadenza per tutte le +chiavi di firma, il che implica che in una data prestabilita le monete +firmate con quelle chiavi diventano non valide. Alla scadenza delle +chiavi di valore, i consumatori devono scambiare con monete nuove le +monete che erano state firmate con le vecchie chiavi; l'autorità di +regolamentazione può facilmente fissare una soglia di conversione per +cliente per creare un limite rigido alla quantità di CBDC che ogni +individuo può accumulare. Inoltre, la banca centrale potrebbe addebitare +commissioni, se necessario. Una commissione di aggiornamento quando le monete +stanno per scadere significherebbe nella pratica tassi di interesse negativi +sulla CBDC per limitare il suo fascino come riserva di valore, come +suggerisce~\cite{Bindseil}. Si tratterebbe infatti della diretta attuazione +dell'idea di Silvio Gesell di applicare una tassa di possesso sulla moneta, +notoriamente citata da~\cite{Keynes} e ripresa da~\cite{Goodfriend}, +\cite{Buiter} e~\cite{Agarwal}. + +Per quanto riguarda le implicazioni in termini di politica monetaria, +non dovrebbero esserci cambiamenti reali perché la nostra CBDC è +progettata per replicare il contante piuttosto che i depositi bancari. +L'emissione, il prelievo e il deposito della nostra CBDC corrispondono +esattamente all'emissione, al prelievo e al deposito di banconote. È +possibile che la velocità di circolazione di una CBDC al dettaglio sia +diversa da quella del contante fisico, ma questo non dovrebbe +rappresentare un problema significativo per la politica monetaria. + +\hypertarget{lavori-correlati}{% +\section{Lavori correlati}\label{6.-lavori-correlati}} + +Come segnalato in precedenza, la CBDC che si propone in questo documento +si basa su eCash e GNU Taler.\footnote{L'implementazione di eCash +da parte della società DigiCash negli anni novanta è documentata su \\ +\url{https://www.chaum.com/ecash}.} A partire dalla proposta originale +e-Cash di Chaum, la ricerca si è concentrata su tre questioni principali. +In primo luogo, nella proposta originale di Chaum le monete avevano un +valore fisso e potevano essere spese solo nella loro totalità. Pagare +grandi somme con monete denominate in centesimi sarebbe stato poco +efficiente; quindi~\cite{Okamoto}, \cite{Camenisch2005}, \cite{Canard} +e~\cite{Dold} idearono modi per affrontare il problema. Queste soluzioni +comprendono protocolli per dare il resto o rendere divisibili le monete. + +Un secondo problema riguarda gli errori nelle transazioni dovuti ad +interruzioni della rete. In questo caso, il sistema deve garantire che +i fondi rimangano in possesso del consumatore senza pregiudicare la +privacy. L'\textit{Endorsed E-Cash} proposto da~\cite{Camenisch2007}, +così come da~\cite{Dold}, affrontano entrambi questo problema. Molte +delle soluzioni violano le garanzie sulla privacy per i clienti che +utilizzano queste funzionalità e tutte, tranne Taler, violano il +requisito della trasparenza del reddito. + +La terza questione importante, spesso trascurata, è la trasparenza del +reddito e quindi la conformità con i requisiti AML e KYC. \cite{Fuchsbauer} +hanno deliberatamente progettato il loro sistema di disintermediazione +per fornire una semantica più simile al contante. Tuttavia, la +disintermediazione totale è in genere difficile da concialiare con le +normative AML e KYC dato che diventa impossibile raggiungere qualsiasi +livello di responsabilità. Un esempio di tale architettura è ZCash, un +registro distribuito (\textit{ledger}) che nasconde dalla rete le +informazioni sul pagatore, sul beneficiario e sull'importo della +transazione, rendendolo quindi il sistema di pagamento perfetto per la +criminalità online. Solo Taler offre sia una privacy costante per i +clienti che la trasparenza del reddito, fornendo al contempo un sistema +di resto efficiente, scambi atomici~\cite[vedi][]{Camenisch2007} e la +possibilità di ripristinare i portafogli dal backup. + +Per quanto riguarda i sistemi di pagamento per le CBDC, \cite{Danezis} +hanno progettato un \textit{ledger} scalabile per RSCoin. Si tratta +fondamentalmente di un sistema RTGS che viene protetto utilizzando la +stessa crittografia che si usa in Bitcoin. Come Taler, il design utilizza +lo \textit{sharding} del database per consentire la scalabilità lineare. +Tuttavia, la soluzione di Danezis e Meiklejohn non prevede alcuna +disposizione per la privacy e manca di elementi per l'integrazione +pratica del design con i sistemi e i processi bancari esistenti. + +L'EUROchain della Banca Centrale Europea\cite[vedi][]{ECB} è un altro +prototipo di CBDC con registro distribuito. Simile all'architettura +proposta in questo documento, EUROchain utilizza un'architettura a due +livelli in cui le banche commerciali agiscono come intermediari. Una +differenza cruciale è il modo in cui i sistemi cercano di combinare +privacy e conformità con la normativa antiriciclaggio (AML). Mentre nel +nostro progetto l'autorità di regolamentazione può imporre un limite +alla somma di denaro elettronico che un titolare di conto bancario può +prelevare in un determinato periodo di tempo, EUROchain emette un numero +limitato di «voucher di anonimato» che garantiscono al destinatario un +numero limitato di transazioni senza controlli AML. Poiché questi voucher +sembrano essere privi di qualsiasi token di valore, non è chiaro come +il design possa impedire l'emergere di un mercato nero per i «voucher +di anonimato». Inoltre, la nozione di anonimato di EUROchain è molto +diversa, in quanto i loro «voucher di anonimato» eliminano solo alcuni +controlli AML, preservando la capacità delle banche commerciali di +sapere in che modo i clienti spendono il denaro elettronico. Laddove chi +paga utilizzando Taler interagisce direttamente con i venditori per +spendere il proprio contante elettronico, il sistema EUROchain chiede +ai pagatori di istruire le proprie banche commerciali per accedere alle +CBDC. Pertanto, EUROchain non emette direttamente token di valore ai +consumatori, affida invece ai consumatori il compito di autenticarsi +presso la propria banca commerciale per accedere alle CBDC che la +banca centrale detiene effettivamente in deposito a garanzia. Non è +quindi evidente quali siano i vantaggi di EUROchain in termini di +privacy, prestazioni o sicurezza rispetto all'attuale denaro in deposito. + +\section{Conclusione}\label{7.-conclusione} + +Con l'emergere di Bitcoin e valute digitali come Diem (già nota come +Libra) recentemente proposte dai colossi del web, le banche centrali +affrontano una crescente concorrenza da parte di operatori privati che +offrono la propria alternativa digitale al contante fisico. Le decisioni +delle banche centrali sull'emissione o meno di una CBDC dipendono dalla +loro valutazione dei benefici e dei rischi di una CBDC. È probabile che +questi vantaggi e rischi, nonché le circostanze giurisdizionali +specifiche che definiscono l'ambito di applicazione di una CBDC al +dettaglio, differiscano da un paese all'altro. + +Se una banca centrale decide di emettere una CBDC al dettaglio, +proponiamo una CBDC basata su token che combina la privacy delle +transazioni con la conformità alle normative KYC, AML e CFT. Tale CBDC +non sarebbe in concorrenza con i depositi presso le banche commerciali, +replicherebbe piuttosto il contante fisico, limitando quindi i rischi di +stabilità finanziaria e di perturbazione della politica monetaria. + +Abbiamo dimostrato che lo schema qui proposto sarebbe efficiente ed +economico quanto i moderni sistemi RTGS gestiti dalle banche centrali. +I pagamenti elettronici con la nostra CBDC richiederebbero solo un +semplice database e minuscole quantità di larghezza di banda per le +transazioni. L'efficienza e l'economicità di questa soluzione, insieme +alla maggiore facilità d'uso da parte del consumatore determinata dal +passaggio dall'autenticazione all'autorizzazione, rendono questo schema +probabilmente il primo a supportare l'annoso obiettivo dei micropagamenti +online. Inoltre, l'uso di monete per firmare crittograficamente contratti +elettronici consente anche l'impiego di contratti intelligenti. Ciò +potrebbe anche portare all'emergere di applicazioni completamente nuove +per i sistemi di pagamento. Sebbene il nostro sistema non sia basato su +DLT, può essere facilmente integrato con tali tecnologie se richiesto +dalle future infrastrutture del mercato finanziario. + +Altrettanto importante, una CBDC al dettaglio deve rimanere, come il +contante fisico, un bene rispettoso della privacy sotto il controllo +individuale dei cittadini. Lo schema proposto in questo studio soddisfa +questo criterio e consente alle banche centrali di evitare gravi sfide +alla loro politica monetaria e alla stabilità finanziaria sfruttando al +contempo i vantaggi del passaggio al digitale. + +\newpage +\bibliographystyle{agsm-mod} +\bibliography{cbdc-it} +\end{document} diff --git a/doc/cbdc-it/cbdc.bib b/doc/cbdc-it/cbdc.bib new file mode 100644 index 000000000..fe0ea6265 --- /dev/null +++ b/doc/cbdc-it/cbdc.bib @@ -0,0 +1,566 @@ +@article{Adrian, + author = {Adrian, Tobias and Tommaso Mancini-Griffoli}, + year = {2019}, + title = {The Rise of Digital Money}, + journal = {IMF Fintech Note}, + volume = {19/01}, +} + +@article{Agarwal, + author = {Agarwal, Ruchir and Miles S. Kimball}, + year = {2019}, + title = {Enabling Deep Negative Rates to Fight Recessions: A Guide}, + journal = {IMF Working Paper}, + volume = {19/84}, +} + + +@article{Agur, + author = {Agur, Itai and Anil Ari and Giovanni Dell'Ariccia}, + year = {2019}, + title = {Designing Central Bank Digital Currencies}, + journal = {IMF Working Paper}, + volume = {19/252}, +} + +@article{Allen, + author = {Allen, Sarah and Srđjan Čapkun and Ittay Eyal and Giulia Fanti and Bryan A. Ford and James Grimmelmann and Ari Juels and Kari Kostiainen and Sarah Meiklejohn and Andrew Miller and Eswar Prasad and Karl Wüst and Fan Zhang}, + year = {2020}, + title = {Design Choices for Central Bank Digital Currency: Policy and Technical Considerations}, + journal = {NBER Working Paper}, + volume = {27634}, +} + +@article{Alves, + author = {Alves, Tiago and Don Felton}, + year = {2004}, + title = {TrustZone: Integrated hardware and software security}, + journal = {ARM IQ}, + volume = {3}, + number = {4}, + pages = {18--24}, +} + +@article{AuerBoehme, + author = {Auer, Raphael and Rainer Böhme}, + year = {2020}, + title = {The technology of retail central bank digital currency}, + journal = {BIS Quarterly Review}, + month = {March}, + pages = {85--96}, +} + +@article{AuerCornelli, + author = {Auer, Raphael and Giulio Cornelli and Jon Frost}, + year = {2020}, + title = {Taking stock: ongoing retail {CBDC} projects}, + journal = {BIS Quarterly Review}, + month = {March}, + pages = {97--98}, +} + +@booklet{BIS, + author = {{Bank for International Settlements}}, + year = {2018}, + title = {Central Bank Digital Currencies. Joint Report of the Committee on Payments and Market Infrastructures and Markets Committee}, +} + +@booklet{BoE, + author = {{Bank of England}}, + year = {2020}, + title = {Central Bank Digital Currency: Opportunities, Challenges and Design. Discussion Paper}, + month = {March}, +} + +@article{Baiocchi, + author = {Baiocchi, Giovanni and Walter Distaso}, + year = {2003}, + title = {{GRETL}: Econometric Software for the {GNU} Generation}, + journal = {Journal of Applied Econometrics}, + volume = {18}, + pages = {105-110}, +} + +@article{Bech, + author = {Bech, Morten and Rodney Garratt}, + year = {2017}, + title = {Central bank cryptocurrencies}, + journal = {BIS Quarterly Review}, + month = {September}, + pages = {55--70}, +} + +@article{Berentsen, + author = {Berentsen, Aleksander and Fabian Schär}, + year = {2018}, + title = {The Case for Central Bank Electronic Money and the Non-case for Central Bank Cryptocurrencies}, + journal = {Federal Reserve Bank of St. Louis Review}, + volume = {100}, + number = {2}, + pages = {97--106}, +} + +@article{Bernstein2020, + author = {Bernstein, Daniel J. and Tanja Lange}, + year = {2020}, + title = {{eBACS}: {ECRYPT} Benchmarking of Cryptographic Systems}, + url = {\url{https://bench.cr.yp.to}, accessed 17 March 2020}, +} + +@article{Bernstein2012, + author = {Bernstein, Daniel J. and Niels Duif and Tanja Lange and Peter Schwabe and Bo-Yin Yang}, + year = {2012}, + title = {High-speed high-security signatures}, + journal = {Journal of Cryptographic Engineering}, + volume = {2}, + pages = {77--89}, +} + +@InCollection{Bindseil, + author = {Bindseil, Ulrich}, + year = {2020}, + title = {Tiered {CBDC} and the financial system}, + publisher = {European Central Bank}, + series = {ECB Working Paper}, + number = {2351}, + month = {January}, +} + +@article{Boar, + author = {Boar, Codruta and Henry Holden and Amber Wadsworth}, + year = {2020}, + title = {Impending arrival - a sequel to the survey on central bank digital currency}, + journal = {BIS Papers}, + volume = {107}, +} + +@article{Boneh, + author = {Boneh, Dan}, + year = {1999}, + title = {Twenty Years of Attacks on the {RSA} Cryptosystem}, + journal = {Notices of the AMS}, + volume = {42}, + number = {2}, + pages = {202--213}, +} + + +@InCollection{Bordo, + author = {Bordo, Michael D. and Andrew T. Levin}, + year = {2017}, + title = {Central bank digital currency and the future of monetary policy}, + publisher = {National Bureau of Economic Research}, + series = {NBER Working Paper Series}, + number = {23711}, +} + +@article{Brunnermeier, + author = {Brunnermeier, Markus and Dirk Niepelt}, + year = {2019}, + title = {On the Equivalence of Private and Public Money}, + journal = {Journal of Monetary Economics}, + volume = {106}, + pages = {27--41}, +} + +@article{Buiter, + author = {Buiter, Willem H. and Nikolaos Panigirtzoglou}, + year = {2003}, + title = {Overcoming the Zero Bound on Nominal Interest Rates with Negative Interest on Currency: Gesell's Solution}, + journal = {The Economic Journal}, + volume = {113}, + number = {490}, + pages = {723--746}, +} + +@InCollection{Bullmann, + author = {Bullmann, Dirk and Jonas Klemm and Andrea Pinna}, + year = {2019}, + title = {In search for stability in crypto-assets: are stablecoins the solution?}, + publisher = {European Central Bank}, + series = {ECB Occasional Paper Series}, + number = {230}, +} + +@inproceedings{Camenisch2007, + author = {Camenisch, Jan and Aanna Lysyanskaya and Mira Meyerovich}, + year = {2007}, + title = {Endorsed E-Cash}, + booktitle = {2007 IEEE Symposium on Security and Privacy (SP'07)}, + month = {May}, + pages = {101--115}, +} + +@inproceedings{Camenisch2005, + author = {Camenisch, Jan and Susan Hohenberger and Anna Lysyanskaya}, + year = {2005}, + title = {Compact E-Cash}, + booktitle = {Advances in Cryptology -- EUROCRYPT 2005: 24th Annual International Conference on the Theory and Applications of Cryptographic Techniques}, + address = {Aarhus, Denmark}, + month = {May}, + day = {22-26}, + editor = {Ed. by Ronald Cramer}, + publisher = {Springer-Verlag Berlin Heidelberg}, +} + + + +@inproceedings{Canard, + author = {Canard, Sébastien and Aline Gouget}, + year = {2007}, + title = {Divisible e-cash systems can be truly anonymous}, + booktitle = {Annual International Conference on the Theory and Applications of Cryptographic Techniques}, + pages = {482--497}, +} + + + +@misc{CCC, + author = {{CCC e.V.}}, + year = {2017}, + title = {Chaos Computer Club hacks e-motor charging stations}, + howpublished = {34c3}, +} + +@article{Chapman, + author = {Chapman, James and Rodney Garratt and Scott Hendry and Andrew McCormack and Wade McMahon}, + year = {2017}, + title = {Project {J}asper: Are Distributed Wholesale Payment Systems Feasible Yet?}, + journal = {Financial System Review}, + publisher = {Bank of Canada}, + month = {June}, + pages = {59--69}, +} + +@inproceedings{Chaum1983, + author = {Chaum, David}, + year = {1983}, + title = {Blind signatures for untraceable payments}, + booktitle = {Advances in Cryptology: Proceedings of Crypto `82}, + pages = {199--203}, +} + +@inproceedings{Chaum1990, + author = {Chaum, David and Amos Fiat and Moni Naor}, + year = {1990}, + title = {Untraceable electronic cash}, + booktitle = {Advances in Cryptology: Proceedings of CRYPTO '88}, + pages = {319--327}, +} + +@inproceedings{Danezis, + author = {Danezis, George and Sarah Meiklejohn}, + year = {2016}, + title = {Centrally Banked Cryptocurrencies}, + booktitle = {23nd Annual Network and Distributed System Security Symposium, NDSS2016}, + address = {San Diego, California, USA}, + month = {February}, + day = {21--24}, + publisher = {The Internet Society}, +} + +@article{Diffie, + author = {Diffie, Whitfield and Martin Hellmann}, + year = {1976}, + title = {New Directions in Cryptography}, + journal = {IEEE Trans. on Inf. Theory, IT-22}, + pages = {644--654}, +} + +@phdthesis{Dold, + author = {Dold, Florian}, + year = {2019}, + title = {The {GNU} {T}aler System: Practical and Provably Secure Electronic Payments. PhD Thesis}, + school = {University of Rennes 1}, +} + +@article{ECB, + author = {{European Central Bank}}, + year = {2019}, + title = {Exploring anonymity in central bank digital currencies}, + journal = {In Focus}, + number = {4}, + month = {December}, +} + +@inproceedings{Fuchsbauer, + author = {Fuchsbauer, Georg and David Pointcheval and Damien Vergnaud}, + year = {2009}, + title = {Transferable constant-size fair e-cash}, + booktitle = {International Conference on Cryptology and Network Security}, + publisher = {Springer-Verlag Berlin Heidelberg}, + pages = {226--247}, +} + +@inproceedings{Garcia, + author = {Garcia, Flavio and Gerhard de Koning Gans and Ruben Muijrers and Peter van Rossum and Roel Verdult and Ronny Wichers Schreur and Bart Jacobs}, + year = {2008}, + title = {Dismantling MIFARE Classic}, + booktitle = {European Symposium on Research in Computer Security}, +} + +@article{Garratt, + author = {Garratt, Rod and Michael Lee and Brendan Malone and Antoine Martin}, + year = {2020}, + title = {Token- or Account-Based? A Digital Currency Can Be Both}, + journal = {Liberty Street Economics}, + publisher = {Federal Reserve Bank of New York}, + month = {August}, + day = {12}, +} + +@article{Goodfriend, + author = {Goodfriend, Marvin}, + year = {2000}, + title = {Overcoming the Zero Bound on Interest Rate Policy}, + journal = {Journal of Money, Credit, and Banking}, + volume = {32}, + number = {4}, + pages = {1007--1035}, +} + +@article{Johnston, + author = {Johnston, Casey}, + year = {2010}, + title = {PS3 hacked through poor cryptography implementation}, + journal = {Ars Technica}, + month = {December}, + day = {30}, +} + + + +@Misc{Jordan, + note = {Speech given at the 30th anniversary of the WWZ and VBÖ}, + author = {Jordan, Thomas J.}, + year = {2019}, + title = {Currencies, money and digital tokens}, + publisher = {University of Basel}, + month = {September}, + howpublished = {\url{https://www.snb.ch/en/mmr/speeches/id/ref\_20190905\_tjn/source/ref\_20190905\_tjn.en.pdf}}, +} + + +@article{Kahn2009, + author = {Kahn, Charles M. and William Roberds}, + year = {2009}, + title = {Why Pay? An Introduction to Payments Economics}, + journal = {Journal of Financial Intermediation}, + number = {18}, + pages = {1--23}, +} + +@article{Kahn2005, + author = {Kahn, Charles M. and James McAndrews and William Roberds}, + year = {2005}, + title = {Money is Privacy}, + journal = {International Economic Review}, + volume = {46}, + number = {2}, + pages = {377--399}, +} + +@article{Kasper, + author = {Kasper, Timo and Michael Silbermann and Christof Paar}, + year = {2010}, + title = {All you can eat or breaking a real-world contactless payment system}, + journal = {Financial Cryptography and Data Security, Lecture Notes in Computer Science}, + volume = {6052}, + pages = {343--50}, +} + +@inproceedings{Katzenbeisser, + author = {Katzenbeisser, Stefan and Ünal Kocabaş and Vladimir Rožić and Ahmad-Reza Sadeghi and Ingrid Verbauwhede and Christian Wachsmann}, + year = {2012}, + title = {{PUF}s: Myth, Fact or Busted? A Security Evaluation of Physically Unclonable Functions ({PUF}s) Cast in Silicon}, + booktitle = {Cryptographic Hardware and Embedded Systems -- CHES 2012. Lecture Notes in Computer Science}, + volume = {7428}, + pages = {283--301}, +} + +@book{Keynes, + author = {Keynes, John Maynard}, + year = {1936}, + title = {The General Theory of Employment, Interest and Money}, + publisher = {Macmillan}, +} + +@article{Kiff, + author = {Kiff, John and Jihad Alwazir and Sonja Davidovic and Aquiles Farias and Ashraf Khan and Tanai Khiaonarong and Majid Malaika and Hunter Monroe and Nobu Sugimoto and Hervé Tourpe and Peter Zhou}, + year = {2020}, + title = {A Survey of Research on Retail Central Bank Digital Currency}, + journal = {IMF Working Paper}, + volume = {20/104}, +} + +@InCollection{Kumhof, + author = {Kumhof, Michael and Clare Noone}, + year = {2018}, + title = {Central bank digital currencies - design principles and balance sheet implications}, + publisher = {Bank of England}, + series = {Staff Working Paper}, + number = {725}, +} + +@inproceedings{Lapid, + author = {Lapid, Ben and Avishai Wool}, + year = {2018}, + title = {Cache-Attacks on the {ARM} TrustZone Implementations of {AES}-256 and {AES}-256-{GCM} via {GPU}-Based Analysis}, + booktitle = {International Conference on Selected Areas in Cryptography. Lecture Notes in Computer Science}, + volume = {11349}, +} + +@article{Lerner, + author = {Lerner, Josh and Jean Tirole}, + year = {2005}, + title = {The Scope of Open Source Licensing}, + journal = {Journal of Law, Economics \& Organization}, + volume = {21}, + pages = {20-56}, +} + +@misc{Libra, + author = {{Libra Association}}, + year = {2020}, + title = {Libra White Paper v2.0}, + url = {\url{https://libra.org/en-US/white-paper}}, +} + +@inproceedings{Lim, + author = {Lim, Chae Hoon and Phil Joong Lee}, + year = {1997}, + title = {A key recovery attack on discrete log-based schemes using a prime order subgroup}, + booktitle = {CRYPTO 1997. Lecture Notes in Computer Science}, + volume = {1294}, +} + +@InCollection{Lyons, + author = {Lyons, Richard K. and Ganesh Viswanath-Natraj}, + year = {2020}, + title = {What Keeps Stablecoins Stable?}, + publisher = {National Bureau of Economic Research}, + series = {NBER Working Paper Series}, + number = {27136}, + month = {May}, +} + +@article{Mancini-Griffoli, + author = {Mancini-Griffoli, Tommaso and Maria Soledad Martinez Peria and Itai Agur and Anil Ari and John Kiff and Adina Popescu and Celine Rochon}, + year = {2018}, + title = {Casting Light on Central Bank Digital Currency}, + journal = {IMF Staff Discussion Notes}, + volume = {18/08}, + publisher = {International Monetary Fund}, +} + +@misc{Nakamoto, + author = {Nakamoto, Satoshi}, + year = {2008}, + title = {Bitcoin: A Peer-to-Peer Electronic Cash System}, + url = {\url{https://www.bitcoin.com/bitcoin.pdf}}, +} + +@book{Narayanan, + author = {Narayanan, Arvind and Joseph Bonneau and Edward Felten and Andrew Miller and Steven Goldfeder}, + year = {2016}, + title = {Bitcoin and Cryptocurrency Technologies: A Comprehensive Introduction}, + publisher = {Princeton University Press}, +} + +@misc{Niepelt, + author = {Niepelt, Dirk}, + year = {2020}, + title = {Digital money and central bank digital currency: An executive summary for policymakers}, + url = {https://voxeu.org/article/digital-money-and-central-bank-digital-currency-executive-summary}, +} + +@inproceedings{Okamoto, + author = {Okamoto, Tatsuaki}, + year = {1995}, + title = {An Efficient Divisible Electronic Cash Scheme}, + booktitle = {Advances in Cryptology --- CRYPT0'95: 15th Annual International Cryptology Conference Santa Barbara, California, USA, August 27--31, 1995 Proceedings}, + editor = {Ed. by Don Coppersmith}, + publisher = {Springer-Verlag Berlin Heidelberg}, + pages = {438--451}, +} + +@article{Pinto, + author = {Pinto, S. and N. Santos}, + year = {2019}, + title = {Demystifying {ARM} TrustZone: A Comprehensive Survey}, + journal = {ACM Computing Surveys}, + volume = {51}, + number = {6}, + month = {January}, + pages = {1--31} +} + +@article{Rivest, + author = {Rivest, Ronald L. and Adi Shamir and Leonard Adleman}, + year = {1978}, + title = {A Method for Obtaining Digital Signatures and Public Key Cryptosystems}, + journal = {Comm. ACM}, + volume = {21}, + number = {2}, +} + +@book{Solove, + author = {Solove, Daniel J.}, + year = {2011}, + title = {Nothing to Hide: The false tradeoff between privacy and security}, + publisher = {New Haven \& London: Yale University Press}, +} + +@article{Soukup, + author = {Soukup, Michael and Bruno Muff}, + year = {2007}, + title = {Die {P}ostcard lässt sich fälschen}, + journal = {Sonntagszeitung}, + month = {April}, + day = {22}, +} + +@article{Stallman, + author = {Stallman, Richard}, + year = {1985}, + title = {The {GNU} manifesto}, + journal = {Dr. Dobb's Journal of Software Tools}, + volume = {10}, + number = {3}, + pages = {30--35}, +} + + +@TechReport{Riksbank, + author = {{Sveriges Riksbank}}, + year = {2020}, + title = {The {R}iksbank's e-krona project}, + month = {Feb}, + institution = {Sveriges Riksbank}, + url = {\url{https://www.riksbank.se/globalassets/media/rapporter/e-krona/2019/the-riksbanks-e-krona-pilot.pdf}}, +} + +@misc{Wojtczuk, + author = {Wojtczuk, Rafal and Joanna Rutkowska}, + year = {2009}, + title = {Attacking {I}ntel Trusted Execution Technology}, + howpublished = {BlackHat-DC 2009}, +} + +@article{Yalta2010, + author = {Yalta, A. Talha and A. Yasemin Yalta}, + year = {2010}, + title = {Should Economists Use Open Source Software for Doing Research?}, + journal = {Computational Economics}, + volume = {35}, + pages = {371--394}, +} + +@article{Yalta2008, + author = {Yalta, A. Talha and Riccardo Lucchetti}, + year = {2008}, + title = {The {GNU/L}inux Platform and Freedom Respecting Software for Economists}, + journal = {Journal of Applied Econometrics}, + volume = {23}, + pages = {279-286}, +} diff --git a/doc/cbdc-it/diagramma1-it.png b/doc/cbdc-it/diagramma1-it.png Binary files differnew file mode 100644 index 000000000..bd38d1df0 --- /dev/null +++ b/doc/cbdc-it/diagramma1-it.png diff --git a/doc/cbdc-it/diagramma2-it.png b/doc/cbdc-it/diagramma2-it.png Binary files differnew file mode 100644 index 000000000..171cb1045 --- /dev/null +++ b/doc/cbdc-it/diagramma2-it.png diff --git a/doc/cbdc-it/graphics-it.odp b/doc/cbdc-it/graphics-it.odp Binary files differnew file mode 100644 index 000000000..4c165ad5e --- /dev/null +++ b/doc/cbdc-it/graphics-it.odp |
