mirror of
https://github.com/monero-project/research-lab.git
synced 2024-12-23 20:19:22 +00:00
1501 lines
68 KiB
TeX
1501 lines
68 KiB
TeX
|
\documentclass[12pt,english]{mrl}
|
||
|
|
\usepackage{graphicx}
|
||
|
|
\usepackage{listings}
|
||
|
|
\usepackage{cite}
|
||
|
|
\usepackage{amsthm}
|
||
|
|
\newtheorem*{example}{Example}
|
||
|
|
|
||
|
|
\usepackage[toc,page]{appendix}
|
||
|
|
|
||
|
|
\renewcommand{\familydefault}{\rmdefault}
|
||
|
|
\usepackage[T1]{fontenc}
|
||
|
|
\usepackage[latin9]{inputenc}
|
||
|
|
\usepackage{color}
|
||
|
|
\usepackage{babel}
|
||
|
|
\usepackage{verbatim}
|
||
|
|
\usepackage{float}
|
||
|
|
\usepackage{url}
|
||
|
|
\usepackage{amsthm}
|
||
|
|
\usepackage{amsmath}
|
||
|
|
\usepackage{amssymb}
|
||
|
|
\usepackage[unicode=true,pdfusetitle, bookmarks=true,bookmarksnumbered=false,bookmarksopen=false, breaklinks=false,pdfborder={0 0 1},backref=false,colorlinks=true]{hyperref}
|
||
|
|
\usepackage{breakurl}
|
||
|
|
|
||
|
|
|
||
|
|
\usepackage{amsmath}
|
||
|
|
\usepackage{amsfonts}
|
||
|
|
\usepackage{amssymb,enumerate}
|
||
|
|
\usepackage{amsthm}
|
||
|
|
\usepackage{cite}
|
||
|
|
\usepackage{comment}
|
||
|
|
\usepackage[all]{xy}
|
||
|
|
%\usepackage[notref,notcite]{showkeys}
|
||
|
|
\usepackage{hyperref}
|
||
|
|
\usepackage{todonotes}
|
||
|
|
|
||
|
|
|
||
|
|
\usepackage{mathtools}
|
||
|
|
\usepackage{mathrsfs}
|
||
|
|
% THEOREM ENVIRONMENTS
|
||
|
|
|
||
|
|
\theoremstyle{definition}
|
||
|
|
\newtheorem{lem}{Lemma}[section]
|
||
|
|
\newtheorem{cor}[lem]{Corollary}
|
||
|
|
\newtheorem{prop}[lem]{Proposition}
|
||
|
|
\newtheorem{thm}[lem]{Theorem}
|
||
|
|
\newtheorem{soln}[]{Solution}
|
||
|
|
\newtheorem{conj}[lem]{Conjecture}
|
||
|
|
\newtheorem{Defn}[lem]{Definition}
|
||
|
|
\newtheorem{Ex}[lem]{Example}
|
||
|
|
\newtheorem{Question}[lem]{Question}
|
||
|
|
\newtheorem{Property}[lem]{Property}
|
||
|
|
\newtheorem{Properties}[lem]{Properties}
|
||
|
|
\newtheorem{Discussion}[lem]{Remark}
|
||
|
|
\newtheorem{Construction}[lem]{Construction}
|
||
|
|
\newtheorem{Notation}[lem]{Notation}
|
||
|
|
\newtheorem{Fact}[lem]{Fact}
|
||
|
|
\newtheorem{Notationdefinition}[lem]{Definition/Notation}
|
||
|
|
\newtheorem{Remarkdefinition}[lem]{Remark/Definition}
|
||
|
|
\newtheorem{rem}[lem]{Remark}
|
||
|
|
\newtheorem{Subprops}{}[lem]
|
||
|
|
\newtheorem{Para}[lem]{}
|
||
|
|
\newtheorem{Exer}[lem]{Exercise}
|
||
|
|
\newtheorem{Exerc}{Exercise}
|
||
|
|
|
||
|
|
\newenvironment{defn}{\begin{Defn}\rm}{\end{Defn}}
|
||
|
|
\newenvironment{ex}{\begin{Ex}\rm}{\end{Ex}}
|
||
|
|
\newenvironment{question}{\begin{Question}\rm}{\end{Question}}
|
||
|
|
\newenvironment{property}{\begin{Property}\rm}{\end{Property}}
|
||
|
|
\newenvironment{properties}{\begin{Properties}\rm}{\end{Properties}}
|
||
|
|
\newenvironment{notation}{\begin{Notation}\rm}{\end{Notation}}
|
||
|
|
\newenvironment{fact}{\begin{Fact}\rm}{\end{Fact}}
|
||
|
|
\newenvironment{notationdefinition}{\begin{Notationdefinition}\rm}{\end{Notationdefinition}}
|
||
|
|
\newenvironment{remarkdefinition}{\begin{Remarkdefinition}\rm}{\end{Remarkdefinition}}
|
||
|
|
\newenvironment{subprops}{\begin{Subprops}\rm}{\end{Subprops}}
|
||
|
|
\newenvironment{para}{\begin{Para}\rm}{\end{Para}}
|
||
|
|
\newenvironment{disc}{\begin{Discussion}\rm}{\end{Discussion}}
|
||
|
|
\newenvironment{construction}{\begin{Construction}\rm}{\end{Construction}}
|
||
|
|
\newenvironment{exer}{\begin{Exer}\rm}{\end{Exer}}
|
||
|
|
\newenvironment{exerc}{\begin{Exerc}\rm}{\end{Exerc}}
|
||
|
|
|
||
|
|
\newtheorem{intthm}{Theorem}
|
||
|
|
\renewcommand{\theintthm}{\Alph{intthm}}
|
||
|
|
|
||
|
|
% COMENTS
|
||
|
|
|
||
|
|
%\newcommand{\ssw}[1]{\footnote{#1}}
|
||
|
|
\newcommand{\nt}[2][$^\spadesuit$]{\hspace{0pt}#1\marginpar{\tt\raggedleft
|
||
|
|
#1 #2}}
|
||
|
|
\newcommand{\dw}[2][$^\spadesuit$]{\nt[#1]{DW:#2}}
|
||
|
|
\newcommand{\ssw}[2][$^\spadesuit$]{\nt[#1]{SSW:#2}}
|
||
|
|
\newcommand{\ts}[2][$^\spadesuit$]{\nt[#1]{TS:#2}}
|
||
|
|
|
||
|
|
\newcommand{\ds}{\displaystyle}
|
||
|
|
|
||
|
|
% CATEGORIES
|
||
|
|
|
||
|
|
\newcommand{\A}{\mathcal{A}}
|
||
|
|
\newcommand{\D}{\mathcal{D}}
|
||
|
|
\newcommand{\R}{\mathcal{R}}
|
||
|
|
\newcommand{\cat}[1]{\mathcal{#1}}
|
||
|
|
\newcommand{\catx}{\cat{X}}
|
||
|
|
\newcommand{\caty}{\cat{Y}}
|
||
|
|
\newcommand{\catm}{\cat{M}}
|
||
|
|
\newcommand{\catv}{\cat{V}}
|
||
|
|
\newcommand{\catw}{\cat{W}}
|
||
|
|
\newcommand{\catg}{\cat{G}}
|
||
|
|
\newcommand{\catp}{\cat{P}}
|
||
|
|
\newcommand{\catf}{\cat{F}}
|
||
|
|
\newcommand{\cati}{\cat{I}}
|
||
|
|
\newcommand{\cata}{\cat{A}}
|
||
|
|
\newcommand{\catabel}{\mathcal{A}b}
|
||
|
|
\newcommand{\catc}{\cat{C}}
|
||
|
|
\newcommand{\catb}{\cat{B}}
|
||
|
|
\newcommand{\catgi}{\cat{GI}}
|
||
|
|
\newcommand{\catgp}{\cat{GP}}
|
||
|
|
\newcommand{\catgf}{\cat{GF}}
|
||
|
|
\newcommand{\catgic}{\cat{GI}_C}
|
||
|
|
\newcommand{\catgib}{\cat{GI}_B}
|
||
|
|
\newcommand{\catib}{\cat{I}_B}
|
||
|
|
\newcommand{\catgibdc}{\cat{GI}_{\bdc}}
|
||
|
|
\newcommand{\catgicd}{\cat{GI}_{C^{\dagger}}}
|
||
|
|
\newcommand{\caticd}{\cat{I}_{C^{\dagger}}}
|
||
|
|
\newcommand{\catgc}{\cat{G}_C}
|
||
|
|
\newcommand{\catgpc}{\cat{GP}_C}
|
||
|
|
\newcommand{\catgpb}{\cat{GP}_B}
|
||
|
|
\newcommand{\catgpcd}{\cat{GP}_{C^{\dagger}}}
|
||
|
|
\newcommand{\catpcd}{\cat{P}_{C^{\dagger}}}
|
||
|
|
\newcommand{\catac}{\cat{A}_C}
|
||
|
|
\newcommand{\catab}{\cat{A}_B}
|
||
|
|
\newcommand{\catbc}{\cat{B}_C}
|
||
|
|
\newcommand{\catabdc}{\cat{A}_{\bdc}}
|
||
|
|
\newcommand{\catbbdc}{\cat{B}_{\bdc}}
|
||
|
|
\newcommand{\catbb}{\cat{B}_B}
|
||
|
|
\newcommand{\catacd}{\cat{A}_{\da{C}}}
|
||
|
|
\newcommand{\catbcd}{\cat{B}_{\da{C}}}
|
||
|
|
\newcommand{\catgfc}{\cat{GF}_C}
|
||
|
|
\newcommand{\catic}{\cat{I}_C}
|
||
|
|
\newcommand{\catibdc}{\cat{I}_{\bdc}}
|
||
|
|
\newcommand{\catpb}{\cat{P}_B}
|
||
|
|
\newcommand{\catpc}{\cat{P}_C}
|
||
|
|
\newcommand{\catfc}{\cat{F}'}
|
||
|
|
\newcommand{\opg}{\cat{G}}
|
||
|
|
\newcommand{\finrescat}[1]{\operatorname{res}\comp{\cat{#1}}}
|
||
|
|
\newcommand{\proprescat}[1]{\operatorname{res}\wti{\cat{#1}}}
|
||
|
|
\newcommand{\finrescatx}{\finrescat{X}}
|
||
|
|
\newcommand{\finrescaty}{\finrescat{Y}}
|
||
|
|
\newcommand{\finrescatv}{\finrescat{V}}
|
||
|
|
\newcommand{\fincorescatggicd}{\operatorname{cores}\comp{\catg(\caticd)}}
|
||
|
|
\newcommand{\finrescatw}{\finrescat{W}}
|
||
|
|
\newcommand{\finrescatpc}{\operatorname{res}\comp{\catpc}}
|
||
|
|
\newcommand{\finrescatpcr}{\operatorname{res}\comp{\catpc(R)}}
|
||
|
|
\newcommand{\finrescatpb}{\operatorname{res}\comp{\catpb}}
|
||
|
|
\newcommand{\finrescatpbr}{\operatorname{res}\comp{\catpb(R)}}
|
||
|
|
\newcommand{\finrescatgpb}{\operatorname{res}\comp{\catgpb}}
|
||
|
|
\newcommand{\finrescatgpbr}{\operatorname{res}\comp{\catgpb(R)}}
|
||
|
|
\newcommand{\propcorescatic}{\operatorname{cores}\wti{\catic}}
|
||
|
|
\newcommand{\propcorescatgic}{\operatorname{cores}\wti{\catgic}}
|
||
|
|
\newcommand{\fincorescatic}{\operatorname{cores}\comp{\catic}}
|
||
|
|
\newcommand{\fincorescaticr}{\operatorname{cores}\comp{\catic(R)}}
|
||
|
|
\newcommand{\fincorescatir}{\operatorname{cores}\comp{\cati(R)}}
|
||
|
|
\newcommand{\finrescatp}{\finrescat{P}}
|
||
|
|
\newcommand{\proprescatgpc}{\operatorname{res}\wti{\catgpc}}
|
||
|
|
\newcommand{\fincorescaticd}{\operatorname{cores}\comp{\caticd}}
|
||
|
|
\newcommand{\finrescatgp}{\finrescat{GP}}
|
||
|
|
\newcommand{\finrescatpcd}{\operatorname{res}\comp{\catp_{\da{C}}}}
|
||
|
|
\newcommand{\fincorescatggic}{\operatorname{cores}\comp{\catg(\catic)}}
|
||
|
|
\newcommand{\fincorescatibdc}{\operatorname{cores}\comp{\catibdc}}
|
||
|
|
\newcommand{\fincorescatibdcr}{\operatorname{cores}\comp{\catibdc(R)}}
|
||
|
|
\newcommand{\fincorescatgibdc}{\operatorname{cores}\comp{\catgibdc}}
|
||
|
|
\newcommand{\fincorescatgibdcr}{\operatorname{cores}\comp{\catgibdc(R)}}
|
||
|
|
\newcommand{\fincorescatibr}{\operatorname{cores}\comp{\catib(R)}}
|
||
|
|
\newcommand{\finrescatggpc}{\operatorname{res}\comp{\catg(\catpc)}}
|
||
|
|
\newcommand{\finrescatg}{\operatorname{res}\comp{\cat{G}}(R)}
|
||
|
|
\newcommand{\finrescatgpr}{\operatorname{res}\comp{\cat{GP}(R)}}
|
||
|
|
\newcommand{\finrescatpr}{\operatorname{res}\comp{\cat{P}(R)}}
|
||
|
|
\newcommand{\finrescatgpc}{\operatorname{res}\comp{\catgp_C(R)}}
|
||
|
|
\newcommand{\proprescatpc}{\operatorname{res}\wti{\catp_C(R)}}
|
||
|
|
\newcommand{\propcorescatpc}{\operatorname{cores}\wti{\catp_C(R)}}
|
||
|
|
\newcommand{\finrescatgpcd}{\operatorname{res}\comp{\catgp_{C^{\dagger}}(R)}}
|
||
|
|
\newcommand{\proprescatp}{\proprescat{P}}
|
||
|
|
\newcommand{\proprescatgp}{\proprescat{GP}}
|
||
|
|
\newcommand{\proprescatx}{\proprescat{X}}
|
||
|
|
\newcommand{\proprescaty}{\proprescat{Y}}
|
||
|
|
\newcommand{\proprescatv}{\proprescat{V}}
|
||
|
|
\newcommand{\proprescatw}{\proprescat{W}}
|
||
|
|
\newcommand{\fincorescat}[1]{\operatorname{cores}\comp{\cat{#1}}}
|
||
|
|
\newcommand{\propcorescat}[1]{\operatorname{cores}\wti{\cat{#1}}}
|
||
|
|
\newcommand{\fincorescatx}{\fincorescat{X}}
|
||
|
|
\newcommand{\fincorescati}{\fincorescat{I}}
|
||
|
|
\newcommand{\fincorescatgi}{\fincorescat{GI}}
|
||
|
|
\newcommand{\fincorescatgir}{\fincorescat{GI(R)}}
|
||
|
|
\newcommand{\fincorescatgic}{\operatorname{cores}\comp{\catgi_C(R)}}
|
||
|
|
\newcommand{\fincorescatgicd}{\operatorname{cores}\comp{\catgi_{C^{\dagger}}(R)}}
|
||
|
|
\newcommand{\propcorescati}{\propcorescat{I}}
|
||
|
|
\newcommand{\propcorescatgi}{\propcorescat{GI}}
|
||
|
|
\newcommand{\fincorescaty}{\fincorescat{Y}}
|
||
|
|
\newcommand{\fincorescatv}{\fincorescat{V}}
|
||
|
|
\newcommand{\fincorescatw}{\fincorescat{W}}
|
||
|
|
\newcommand{\propcorescatx}{\propcorescat{X}}
|
||
|
|
\newcommand{\propcorescaty}{\propcorescat{Y}}
|
||
|
|
\newcommand{\propcorescatv}{\propcorescat{V}}
|
||
|
|
\newcommand{\propcorescatw}{\propcorescat{W}}
|
||
|
|
\newcommand{\cpltrescat}[1]{\operatorname{res}\ol{\cat{#1}}}
|
||
|
|
\newcommand{\cpltcorescat}[1]{\operatorname{cores}\ol{\cat{#1}}}
|
||
|
|
\newcommand{\cpltrescatw}{\cpltrescat{W}}
|
||
|
|
\newcommand{\cpltcorescatw}{\cpltcorescat{W}}
|
||
|
|
\newcommand{\gw}{\opg(\catw)}
|
||
|
|
\newcommand{\gnw}[1]{\opg^{#1}(\catw)}
|
||
|
|
\newcommand{\gnx}[1]{\opg^{#1}(\catx)}
|
||
|
|
\newcommand{\gx}{\opg(\catx)}
|
||
|
|
\newcommand{\catao}{\cata^o}
|
||
|
|
\newcommand{\catxo}{\catx^o}
|
||
|
|
\newcommand{\catyo}{\caty^o}
|
||
|
|
\newcommand{\catwo}{\catw^o}
|
||
|
|
\newcommand{\catvo}{\catv^o}
|
||
|
|
|
||
|
|
|
||
|
|
% DIMENSIONS
|
||
|
|
|
||
|
|
\newcommand{\pdim}{\operatorname{pd}}
|
||
|
|
\newcommand{\pd}{\operatorname{pd}}
|
||
|
|
\newcommand{\gdim}{\mathrm{G}\text{-}\!\dim}
|
||
|
|
\newcommand{\gkdim}[1]{\mathrm{G}_{#1}\text{-}\!\dim}
|
||
|
|
\newcommand{\gcdim}{\gkdim{C}}
|
||
|
|
\newcommand{\injdim}{\operatorname{id}}
|
||
|
|
\newcommand{\id}{\operatorname{id}}
|
||
|
|
\newcommand{\fd}{\operatorname{fd}}
|
||
|
|
\newcommand{\fdim}{\operatorname{fd}}
|
||
|
|
\newcommand{\catpd}[1]{\cat{#1}\text{-}\pd}
|
||
|
|
\newcommand{\xpd}{\catpd{X}}
|
||
|
|
\newcommand{\xopd}{\catxo\text{-}\pd}
|
||
|
|
\newcommand{\xid}{\catid{X}}
|
||
|
|
\newcommand{\wpd}{\catpd{W}}
|
||
|
|
\newcommand{\ypd}{\catpd{Y}}
|
||
|
|
\newcommand{\gpd}{\catpd{G}}
|
||
|
|
\newcommand{\gid}{\catid{G}}
|
||
|
|
\newcommand{\catid}[1]{\cat{#1}\text{-}\id}
|
||
|
|
\newcommand{\yid}{\catid{Y}}
|
||
|
|
\newcommand{\vid}{\catid{V}}
|
||
|
|
\newcommand{\wid}{\catid{W}}
|
||
|
|
\newcommand{\pdpd}{\catpd\text{-}\pd}
|
||
|
|
\newcommand{\idid}{\catid\text{-}\id}
|
||
|
|
\newcommand{\pcpd}{\catpc\text{-}\pd}
|
||
|
|
\newcommand{\pbpd}{\catpb\text{-}\pd}
|
||
|
|
\newcommand{\icdagdim}{\caticd\text{-}\id}
|
||
|
|
\newcommand{\icdid}{\caticd\text{-}\id}
|
||
|
|
\newcommand{\ibdcid}{\catibdc\text{-}\id}
|
||
|
|
\newcommand{\icdim}{\catic\text{-}\id}
|
||
|
|
\newcommand{\icid}{\catic\text{-}\id}
|
||
|
|
\newcommand{\ibid}{\catib\text{-}\id}
|
||
|
|
\newcommand{\pcdim}{\catpc\text{-}\pd}
|
||
|
|
\newcommand{\gpcpd}{\catgpc\text{-}\pd}
|
||
|
|
\newcommand{\gfpd}{\catgf\text{-}\pd}
|
||
|
|
\newcommand{\gppd}{\catgp\text{-}\pd}
|
||
|
|
\newcommand{\gfcpd}{\catgfc\text{-}\pd}
|
||
|
|
\newcommand{\gpbpd}{\catgpb\text{-}\pd}
|
||
|
|
\newcommand{\gicid}{\catgic\text{-}\id}
|
||
|
|
\newcommand{\gibid}{\catgib\text{-}\id}
|
||
|
|
\newcommand{\gicdagdim}{\catgicd\text{-}\id}
|
||
|
|
\newcommand{\gicdid}{\catgicd\text{-}\id}
|
||
|
|
\newcommand{\ggpcpd}{\catg(\catpc)\text{-}\pd}
|
||
|
|
\newcommand{\ggicdid}{\catg(\caticd)\text{-}\id}
|
||
|
|
\newcommand{\ggicid}{\catg(\catic)\text{-}\id}
|
||
|
|
\newcommand{\cmdim}{\mathrm{CM}\text{-}\dim}
|
||
|
|
\newcommand{\cidim}{\mathrm{CI}\text{-}\!\dim}
|
||
|
|
\newcommand{\cipd}{\mathrm{CI}\text{-}\!\pd}
|
||
|
|
\newcommand{\cifd}{\mathrm{CI}\text{-}\!\fd}
|
||
|
|
\newcommand{\ciid}{\mathrm{CI}\text{-}\!\id}
|
||
|
|
|
||
|
|
|
||
|
|
% OTHER INVARIANTS
|
||
|
|
|
||
|
|
\newcommand{\Ht}{\operatorname{ht}}
|
||
|
|
\newcommand{\col}{\operatorname{col}}
|
||
|
|
\newcommand{\depth}{\operatorname{depth}}
|
||
|
|
\newcommand{\rank}{\operatorname{rank}}
|
||
|
|
\newcommand{\amp}{\operatorname{amp}}
|
||
|
|
\newcommand{\edim}{\operatorname{edim}}
|
||
|
|
\newcommand{\crs}{\operatorname{crs}}
|
||
|
|
\newcommand{\rfd}{\operatorname{Rfd}}
|
||
|
|
\newcommand{\ann}{\operatorname{Ann}}
|
||
|
|
\newcommand{\mspec}{\mathrm{m}\text{\spec}}
|
||
|
|
\newcommand{\soc}{\operatorname{Soc}}
|
||
|
|
\newcommand{\len}{\operatorname{length}}
|
||
|
|
\newcommand{\type}{\operatorname{type}}
|
||
|
|
\newcommand{\dist}{\operatorname{dist}}
|
||
|
|
\newcommand{\prox}{\operatorname{\sigma}}
|
||
|
|
\newcommand{\curv}{\operatorname{curv}}
|
||
|
|
\newcommand{\icurv}{\operatorname{inj\,curv}}
|
||
|
|
\newcommand{\grade}{\operatorname{grade}}
|
||
|
|
\newcommand{\card}{\operatorname{card}}
|
||
|
|
\newcommand{\cx}{\operatorname{cx}}
|
||
|
|
\newcommand{\cmd}{\operatorname{cmd}}
|
||
|
|
\newcommand{\Span}{\operatorname{Span}}
|
||
|
|
\newcommand{\CM}{\operatorname{CM}}
|
||
|
|
|
||
|
|
% FUNCTORS
|
||
|
|
|
||
|
|
\newcommand{\cbc}[2]{#1(#2)}
|
||
|
|
\newcommand{\ext}{\operatorname{Ext}}
|
||
|
|
\newcommand{\rhom}{\mathbf{R}\!\operatorname{Hom}}
|
||
|
|
\newcommand{\lotimes}{\otimes^{\mathbf{L}}}
|
||
|
|
\newcommand{\HH}{\operatorname{H}}
|
||
|
|
\newcommand{\Hom}{\operatorname{Hom}}
|
||
|
|
\newcommand{\coker}{\operatorname{Coker}}
|
||
|
|
\newcommand{\spec}{\operatorname{Spec}}
|
||
|
|
\newcommand{\s}{\mathfrak{S}}
|
||
|
|
\newcommand{\tor}{\operatorname{Tor}}
|
||
|
|
\newcommand{\im}{\operatorname{Im}}
|
||
|
|
\newcommand{\shift}{\mathsf{\Sigma}}
|
||
|
|
\newcommand{\othershift}{\mathsf{\Sigma}}
|
||
|
|
\newcommand{\da}[1]{#1^{\dagger}}
|
||
|
|
\newcommand{\Cl}{\operatorname{Cl}}
|
||
|
|
\newcommand{\Pic}{\operatorname{Pic}}
|
||
|
|
\newcommand{\proj}{\operatorname{Proj}}
|
||
|
|
\newcommand{\End}{\operatorname{End}}
|
||
|
|
\newcommand{\cone}{\operatorname{Cone}}
|
||
|
|
\newcommand{\Ker}{\operatorname{Ker}}
|
||
|
|
\newcommand{\xext}{\ext_{\catx}}
|
||
|
|
\newcommand{\yext}{\ext_{\caty}}
|
||
|
|
\newcommand{\vext}{\ext_{\catv}}
|
||
|
|
\newcommand{\wext}{\ext_{\catw}}
|
||
|
|
\newcommand{\aext}{\ext_{\cata}}
|
||
|
|
\newcommand{\ahom}{\Hom_{\cata}}
|
||
|
|
\newcommand{\aoext}{\ext_{\catao}}
|
||
|
|
\newcommand{\aohom}{\Hom_{\catao}}
|
||
|
|
\newcommand{\xaext}{\ext_{\catx\!\cata}}
|
||
|
|
\newcommand{\axext}{\ext_{\cata\catx}}
|
||
|
|
\newcommand{\ayext}{\ext_{\cata\caty}}
|
||
|
|
\newcommand{\avext}{\ext_{\cata\catv}}
|
||
|
|
\newcommand{\awext}{\ext_{\cata\catw}}
|
||
|
|
\newcommand{\Qext}{\ext_{\catw \cata}}
|
||
|
|
\newcommand{\pmext}{\ext_{\catp(R)\catm(R)}}
|
||
|
|
\newcommand{\miext}{\ext_{\catm(R)\cati(R)}}
|
||
|
|
\newcommand{\Qtate}{\comp{\ext}_{\catw \cata}}
|
||
|
|
\newcommand{\awtate}{\comp{\ext}_{\cata \catw}}
|
||
|
|
\newcommand{\avtate}{\comp{\ext}_{\cata \catv}}
|
||
|
|
\newcommand{\pmtate}{\comp{\ext}_{\catp(R) \catm(R)}}
|
||
|
|
\newcommand{\mitate}{\comp{\ext}_{\catm(R) \cati(R)}}
|
||
|
|
\newcommand{\pcext}{\ext_{\catpc}}
|
||
|
|
\newcommand{\pbext}{\ext_{\catpb}}
|
||
|
|
\newcommand{\gpcext}{\ext_{\catgpc}}
|
||
|
|
\newcommand{\icext}{\ext_{\catic}}
|
||
|
|
\newcommand{\gpbext}{\ext_{\catgpb}}
|
||
|
|
\newcommand{\gibdcext}{\ext_{\catgibdc}}
|
||
|
|
\newcommand{\ibdcext}{\ext_{\catibdc}}
|
||
|
|
\newcommand{\gicext}{\ext_{\catgic}}
|
||
|
|
\newcommand{\gpext}{\ext_{\catgp}}
|
||
|
|
\newcommand{\giext}{\ext_{\catgi}}
|
||
|
|
\newcommand{\gicdext}{\ext_{\catgicd}}
|
||
|
|
|
||
|
|
% IDEALS
|
||
|
|
|
||
|
|
\newcommand{\ideal}[1]{\mathfrak{#1}}
|
||
|
|
\newcommand{\m}{\ideal{m}}
|
||
|
|
\newcommand{\n}{\ideal{n}}
|
||
|
|
\newcommand{\p}{\ideal{p}}
|
||
|
|
\newcommand{\q}{\ideal{q}}
|
||
|
|
\newcommand{\fa}{\ideal{a}}
|
||
|
|
\newcommand{\fb}{\ideal{b}}
|
||
|
|
\newcommand{\fN}{\ideal{N}}
|
||
|
|
\newcommand{\fs}{\ideal{s}}
|
||
|
|
\newcommand{\fr}{\ideal{r}}
|
||
|
|
|
||
|
|
% OPERATIONS AND ACCENTS
|
||
|
|
|
||
|
|
\newcommand{\wt}{\widetilde}
|
||
|
|
\newcommand{\ti}{\tilde}
|
||
|
|
\newcommand{\comp}[1]{\widehat{#1}}
|
||
|
|
\newcommand{\ol}{\overline}
|
||
|
|
\newcommand{\wti}{\widetilde}
|
||
|
|
|
||
|
|
% OPERATORS
|
||
|
|
|
||
|
|
\newcommand{\ass}{\operatorname{Ass}}
|
||
|
|
\newcommand{\supp}{\operatorname{Supp}}
|
||
|
|
\newcommand{\minh}{\operatorname{Minh}}
|
||
|
|
\newcommand{\Min}{\operatorname{Min}}
|
||
|
|
|
||
|
|
% MATHBB
|
||
|
|
|
||
|
|
\newcommand{\bbz}{\mathbb{Z}}
|
||
|
|
\newcommand{\bbn}{\mathbb{N}}
|
||
|
|
\newcommand{\bbq}{\mathbb{Q}}
|
||
|
|
\newcommand{\bbr}{\mathbb{R}}
|
||
|
|
\newcommand{\bbc}{\mathbb{C}}
|
||
|
|
|
||
|
|
% ARROWS
|
||
|
|
|
||
|
|
\newcommand{\from}{\leftarrow}
|
||
|
|
\newcommand{\xra}{\xrightarrow}
|
||
|
|
\newcommand{\xla}{\xleftarrow}
|
||
|
|
\newcommand{\onto}{\twoheadrightarrow}
|
||
|
|
\newcommand{\res}{\xra{\simeq}}
|
||
|
|
|
||
|
|
|
||
|
|
% MAPS
|
||
|
|
|
||
|
|
\newcommand{\vf}{\varphi}
|
||
|
|
\newcommand{\ve}{\varepsilon}
|
||
|
|
\newcommand{\Qcomp}{\varepsilon_{\catw \cata}}
|
||
|
|
\newcommand{\awcomp}{\varepsilon_{\cata \catw}}
|
||
|
|
\newcommand{\avcomp}{\varepsilon_{\cata \catv}}
|
||
|
|
\newcommand{\xQcomp}{\vartheta_{\catx \catw \cata}}
|
||
|
|
\newcommand{\ayvcomp}{\vartheta_{\cata \caty \catv}}
|
||
|
|
\newcommand{\Qacomp}{\varkappa_{\catw \cata}}
|
||
|
|
\newcommand{\xaacomp}{\varkappa_{\catx \cata}}
|
||
|
|
\newcommand{\aaycomp}{\varkappa_{\cata\caty}}
|
||
|
|
\newcommand{\aavcomp}{\varkappa_{\cata\catv}}
|
||
|
|
\newcommand{\gpcpccomp}{\vartheta_{\catgpc\catpc}}
|
||
|
|
\newcommand{\gpcpbcomp}{\vartheta_{\catgpc\catpb}}
|
||
|
|
\newcommand{\gpcgpbcomp}{\vartheta_{\catgpc\catgpb}}
|
||
|
|
\newcommand{\gicibcomp}{\vartheta_{\catgic\catib}}
|
||
|
|
\newcommand{\gicgibcomp}{\vartheta_{\catgic\catgib}}
|
||
|
|
\newcommand{\giciccomp}{\vartheta_{\catgic\catic}}
|
||
|
|
\newcommand{\pccomp}{\varkappa_{\catpc}}
|
||
|
|
\newcommand{\gpccomp}{\varkappa_{\catgpc}}
|
||
|
|
\newcommand{\iccomp}{\varkappa_{\catic}}
|
||
|
|
\newcommand{\ibdccomp}{\varkappa_{\catibdc}}
|
||
|
|
\newcommand{\icdcomp}{\varkappa_{\caticd}}
|
||
|
|
\newcommand{\giccomp}{\varkappa_{\catgic}}
|
||
|
|
|
||
|
|
% MISCELLANEOUS
|
||
|
|
|
||
|
|
\newcommand{\y}{\mathbf{y}}
|
||
|
|
\newcommand{\te}{\theta}
|
||
|
|
\newcommand{\x}{\mathbf{x}}
|
||
|
|
\newcommand{\opi}{\operatorname{i}}
|
||
|
|
\newcommand{\route}{\gamma}
|
||
|
|
\newcommand{\sdc}[1]{\mathsf{#1}}
|
||
|
|
\newcommand{\nls}[1]{\mathsf{#1}}
|
||
|
|
\newcommand{\cl}{\operatorname{cl}}
|
||
|
|
\newcommand{\cls}{\operatorname{cls}}
|
||
|
|
\newcommand{\pic}{\operatorname{pic}}
|
||
|
|
\newcommand{\pics}{\operatorname{pics}}
|
||
|
|
\newcommand{\tri}{\trianglelefteq}
|
||
|
|
\newcommand{\Mod}{\operatorname{Mod}}
|
||
|
|
\newcommand{\bdc}{B^{\dagger_C}}
|
||
|
|
\newcommand{\e}{\mathbf{e}}
|
||
|
|
\newcommand{\f}{\mathbf{f}}
|
||
|
|
|
||
|
|
|
||
|
|
% RENEWED COMMANDS
|
||
|
|
|
||
|
|
\renewcommand{\geq}{\geqslant}
|
||
|
|
\renewcommand{\leq}{\leqslant}
|
||
|
|
\renewcommand{\ker}{\Ker}
|
||
|
|
\renewcommand{\hom}{\Hom}
|
||
|
|
|
||
|
|
|
||
|
|
\newcommand{\normal}{\lhd}
|
||
|
|
\newcommand{\normaleq}{\trianglelefteqslant}
|
||
|
|
\newcommand{\homrm}[1]{\hom_{_{#1}\catm}}
|
||
|
|
\newcommand{\hommr}[1]{\hom_{\catm_{#1}}}
|
||
|
|
\newcommand{\cplx}[1]{{#1}_{\bullet}}
|
||
|
|
\newcommand{\pext}{\mathrm{P}\!\ext}
|
||
|
|
\newcommand{\pextrm}[1]{\pext_{_{#1}\catm}}
|
||
|
|
\newcommand{\pextmr}[1]{\pext_{\catm_{#1}}}
|
||
|
|
\newcommand{\iext}{\mathrm{I}\!\ext}
|
||
|
|
\newcommand{\iextrm}[1]{\iext_{_{#1}\catm}}
|
||
|
|
\newcommand{\iextmr}[1]{\iext_{\catm_{#1}}}
|
||
|
|
\newcommand{\catmod}[1]{#1\text{-mod}}
|
||
|
|
\newcommand{\modcat}[1]{\text{mod-}#1}
|
||
|
|
|
||
|
|
|
||
|
|
\newcommand{\lcm}{\textnormal{lcm}}
|
||
|
|
\newcommand{\diff}{\backslash}
|
||
|
|
%\setlength{\parindent}{0mm}
|
||
|
|
|
||
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% LyX specific LaTeX commands.
|
||
|
|
\floatstyle{ruled}
|
||
|
|
\newfloat{algorithm}{tbp}{loa}
|
||
|
|
\providecommand{\algorithmname}{Algorithm}
|
||
|
|
\floatname{algorithm}{\protect\algorithmname}
|
||
|
|
|
||
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Textclass specific LaTeX commands.
|
||
|
|
\numberwithin{equation}{section}
|
||
|
|
\numberwithin{figure}{section}
|
||
|
|
|
||
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% User specified LaTeX commands.
|
||
|
|
\usepackage{algpseudocode}
|
||
|
|
|
||
|
|
\usepackage{subcaption}
|
||
|
|
|
||
|
|
\numberwithin{equation}{section}
|
||
|
|
|
||
|
|
|
||
|
|
\makeatletter
|
||
|
|
|
||
|
|
|
||
|
|
\makeatletter
|
||
|
|
|
||
|
|
\newcommand{\h}{\mathcal{H}}
|
||
|
|
|
||
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% LyX specific LaTeX commands.
|
||
|
|
\floatstyle{ruled}
|
||
|
|
\newfloat{algorithm}{tbp}{loa}
|
||
|
|
\providecommand{\algorithmname}{Algorithm}
|
||
|
|
\floatname{algorithm}{\protect\algorithmname}
|
||
|
|
|
||
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Textclass specific LaTeX commands.
|
||
|
|
\numberwithin{equation}{section}
|
||
|
|
\numberwithin{figure}{section}
|
||
|
|
|
||
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% User specified LaTeX commands.
|
||
|
|
\usepackage{algpseudocode}
|
||
|
|
|
||
|
|
\makeatother
|
||
|
|
|
||
|
|
\begin{document}
|
||
|
|
\begin{frontmatter}
|
||
|
|
|
||
|
|
\begin{fmbox}
|
||
|
|
\hfill\setlength{\fboxrule}{0px}\setlength{\fboxsep}{5px}\fbox{\includegraphics[width=2in]{moneroLogo.png}}
|
||
|
|
\dochead{Research bulletin \hfill MRL-0005}
|
||
|
|
\title{Ring Confidential Transactions}
|
||
|
|
\date{February 2016}
|
||
|
|
\author[
|
||
|
|
addressref={mrl},
|
||
|
|
email={lab@getmonero.org shen.noether@gmx.com}
|
||
|
|
]{\fnm{Shen} \snm{Noether}}
|
||
|
|
\author[
|
||
|
|
addressref={mrl},
|
||
|
|
email={lab@getmonero.org}
|
||
|
|
]{\fnm{Adam} \snm{Mackenzie}}
|
||
|
|
\author[
|
||
|
|
addressref={mrl},
|
||
|
|
email={lab@getmonero.org}
|
||
|
|
]{\snm{Monero Core Team}}
|
||
|
|
|
||
|
|
\address[id=mrl]{
|
||
|
|
\orgname{Monero Research Lab}
|
||
|
|
}\end{fmbox}
|
||
|
|
|
||
|
|
|
||
|
|
\begin{abstractbox}
|
||
|
|
\begin{abstract}
|
||
|
|
This article introduces a method of hiding transaction amounts in
|
||
|
|
the strongly decentralized anonymous cryptocurrency Monero. Similar
|
||
|
|
to Bitcoin, Monero is a cryptocurrency which is distributed through
|
||
|
|
a proof of work ``mining'' process. The original Monero protocol
|
||
|
|
was based on CryptoNote, which uses ring signatures and one-time keys
|
||
|
|
to hide the destination and origin of transactions. Recently the technique
|
||
|
|
of using a commitment scheme to hide the amount of a transaction has
|
||
|
|
been discussed and implemented by Bitcoin Core Developer Gregory Maxwell.
|
||
|
|
In this article, a new type of ring signature, A Multi-layered Linkable
|
||
|
|
Spontaneous Anonymous Group signature is described which allows for hidden
|
||
|
|
amounts, origins and destinations of transactions with reasonable
|
||
|
|
efficiency and verifiable, trustless coin generation. Some extensions of the protocol are provided, such as Aggregate Schnorr Range Proofs, and Ring Multisignature. The author would like to note that early drafts of this were publicized in the Monero Community and on the bitcoin research irc channel. Blockchain hashed drafts are available in \cite{Snoe} showing that this work was started in Summer 2015, and completed in early October 2015. An eprint is also available at \url{http://eprint.iacr.org/2015/1098}.
|
||
|
|
\end{abstract}
|
||
|
|
\end{abstractbox}
|
||
|
|
|
||
|
|
\end{frontmatter}
|
||
|
|
|
||
|
|
%\maketitle
|
||
|
|
|
||
|
|
%\tableofcontents
|
||
|
|
\section{Introduction}
|
||
|
|
|
||
|
|
|
||
|
|
\subsection{Spontaneous (Ad Hoc) Ring Signatures in CryptoCurrencies}
|
||
|
|
|
||
|
|
Recall that in Bitcoin each transaction is signed by the owner of
|
||
|
|
the coins being sent and these signatures verify that the owner is
|
||
|
|
allowed to send the coins. This is entirely analogous to the signing
|
||
|
|
of a check from your bank.
|
||
|
|
|
||
|
|
CryptoNote \cite{CN} and Ring Coin
|
||
|
|
\cite{B2} advanced this idea by using ``ring signatures'' which were originally described
|
||
|
|
in \cite{RST} as a ``digital signature that specifies a group of
|
||
|
|
possible signers such that the verifier can't tell which member actually
|
||
|
|
produced the signature.'' The idea therefore is to have the origin
|
||
|
|
pubkey of a transaction hidden in a group of pubkeys all of which contain
|
||
|
|
the same amount of coins, so that no one can tell which user actually
|
||
|
|
sent the coins.
|
||
|
|
|
||
|
|
The original CryptoNote protocol as described in \cite{CN}
|
||
|
|
implements a slight modification of this to prevent double spends.
|
||
|
|
Namely in \cite{CN} a ``traceable ring signature,'' which is a slight modification of those described in
|
||
|
|
\cite{FS} is employed. This type of ring signature has the benefit of not allowing the owner of a coin to
|
||
|
|
sign two different ring signatures with the same pubkey without being
|
||
|
|
noticed on the blockchain. The obvious reason for this is to prevent
|
||
|
|
``double-spending'' which, in Bitcoin, refers to
|
||
|
|
spending a coin twice. Ring coin \cite{B2,B} uses a more efficient linkable
|
||
|
|
ring signature which is a slight modification of the Linkable Spontaneous
|
||
|
|
Anonymous Group signatures described in \cite{LWW}.
|
||
|
|
|
||
|
|
One benefit of using the above types of ring signatures over other anonymizing techniques, such as CoinJoin \cite{GMc} or using coin mixing services,
|
||
|
|
is that they allow for ``spontaneous'' mixing. With CoinJoin or coin mixers, it is
|
||
|
|
similarly possible to hide the originator of a given transaction,
|
||
|
|
however these techniques in practice need some sort of centralized group manager, such as a centralized CoinJoin server, where transactions
|
||
|
|
are combined by a trusted party. In the case that the trusted party is compromised,
|
||
|
|
the anonymity of the transaction is also compromised.
|
||
|
|
|
||
|
|
Some coins such
|
||
|
|
as Dash (originally called Darkcoin) \cite{DASH}, attempt to negate this by using a larger number
|
||
|
|
of trusted mixers (in this case masternodes) but this number is still
|
||
|
|
much smaller than the users of the coin. In contrast, with a spontaneous
|
||
|
|
ring signature, transactions can be created by the owner of a given
|
||
|
|
pubkey (this is the spontaneous, or ``ad-hoc'' property) without relying
|
||
|
|
on any trusted server, and thus providing for safer anonymity.
|
||
|
|
|
||
|
|
One possible attack against the original CryptoNote or ring-coin protocol \cite{CN,B2}
|
||
|
|
is blockchain analysis based on the amounts sent in a given transaction.
|
||
|
|
For example, if an adversary knows that $.9$ coins have been sent
|
||
|
|
at a certain time, then they may be able to narrow down the possibilities
|
||
|
|
of the sender by looking for transactions containing $.9$ coins.
|
||
|
|
This is somewhat negated by the use of the one-time keys used in \cite{CN}
|
||
|
|
since the sender can include a number of change addresses in a transaction,
|
||
|
|
thus obfuscating the amount which has been sent with a type of ``knapsack mixing.'' However this technique
|
||
|
|
has the downside that it can create a large amount of ``dust'' transactions
|
||
|
|
on the blockchain, i.e. transactions of small amounts that take up
|
||
|
|
proportionately more space than their importance. Additionally, the
|
||
|
|
receiver of the coins may have to ``sweep'' all this dust when they
|
||
|
|
want to send it, possibly allowing for a smart adversary to keep track
|
||
|
|
of which keys go together in some manner. Furthermore, it is easy to establish an upper and lower bound on the amounts sent.
|
||
|
|
|
||
|
|
Another downside to the original CryptoNote set-up is that it requires a given
|
||
|
|
pair of $\left(P,A\right)$ of pubkey $P$ and amount $A$ to be used in a ring
|
||
|
|
signature with other pubkeys having the same amount. For less common
|
||
|
|
amounts, this means there may be a smaller number of potential pairs
|
||
|
|
$\left(P^{\prime},A^{\prime}\right)$ available on the blockchain
|
||
|
|
with $A^{\prime}=A$ to ring signature with. Thus, in the original CryptoNote protocol, the potential anonymity set is perhaps smaller than may be desired.
|
||
|
|
Analysis of the above weaknesses is covered in \cite{mrl4}.
|
||
|
|
|
||
|
|
|
||
|
|
\subsection{Ring CT for Monero}
|
||
|
|
|
||
|
|
An obvious way to negate the downsides of the CryptNote protocol, as described in the previous section, would be to implement hidden amounts for any transaction.
|
||
|
|
In this
|
||
|
|
paper, I describe a modification to the Monero protocol, a proof-of-work
|
||
|
|
cryptocurrency extending the original CryptoNote protocol, which allows the amounts sent in
|
||
|
|
a transaction to be hidden. This modification is based on the Confidential
|
||
|
|
Transactions \cite{GM} which are used on the Elements side-chain
|
||
|
|
in Bitcoin, except it allows for their use in ring signatures. Therefore,
|
||
|
|
the modification is given the obvious name of Ring Confidential Transactions for Monero.
|
||
|
|
|
||
|
|
In order to preserve the property that coins cannot be double spent,
|
||
|
|
a generalization of the LSAG's of \cite{LWW} is described, a Multilayered Linkable
|
||
|
|
Spontaneous Anonymous Group Signature (MLSAG) which allows for combining
|
||
|
|
Confidential Transactions with a ring signature in such a way that
|
||
|
|
using multiple inputs and outputs is possible, anonymity is preserved,
|
||
|
|
and double-spending is prevented. The author notes that an essentially similar protocol was proposed by Connor Frenkenecht about a month after the second drafts of this were originally publicized.
|
||
|
|
\subsection{Strongly Decentralized Anonymous Payment Schemes}
|
||
|
|
The Ring CT protocol allows hidden amounts, origins, and destinations
|
||
|
|
for transactions which is somewhat similar to Zerocash \cite{Z}.
|
||
|
|
One possible differentiator is that the use of proof of work for coin generation
|
||
|
|
is possible with Ring CT as opposed to in ZeroCash, where it seems all coins
|
||
|
|
must be pregenerated by a trusted group.
|
||
|
|
|
||
|
|
Note that one of the biggest innovations in Bitcoin \cite{SN}, was
|
||
|
|
the decentralized distribution model allowing anyone willing to put
|
||
|
|
their computing power to work to participate in the generation of
|
||
|
|
the currency. Some of the benefits of this type of proof-of-work include
|
||
|
|
trustless incentives for securing the network and stronger decentralization (for example, to protect against poison-pill type attacks).
|
||
|
|
|
||
|
|
One final obvious benefit of the proof-of-work coin generation is
|
||
|
|
it makes Ring CT immune to a powerful actor somehow acquiring all the
|
||
|
|
pieces of the master key used in coin generation. Since there is an
|
||
|
|
obvious large incentive (the ability to generate free money \footnote{The author previously had assumed this would allow the unmasking of transactions as well, but the newer ZeroCash paper claims this is not possible.}) to acquire all pieces of the trusted generation
|
||
|
|
key, this is fairly important.
|
||
|
|
|
||
|
|
|
||
|
|
\subsection{Acknowledgements}
|
||
|
|
|
||
|
|
I would like to thank Monero team for lots of help and discussion
|
||
|
|
in the creation of this paper and the Monero and Bitcoin Community
|
||
|
|
for support and discussion. With respect to disclosure, the author received several donations totalling between 2 and 3 bitcoins from the Monero community in gratitude for his work on this research.
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
\section{Multilayered Linkable
|
||
|
|
Spontaneous Anonymous Group Signatures}
|
||
|
|
\label{MLSAGsection}
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
In this section, I define the Multilayered Linkable Spontaneous Anonymous
|
||
|
|
Group signatures (MLSAG) used by the the Ring CT protocol. Note that
|
||
|
|
I define these as a general signature, and not necessarily in their
|
||
|
|
use case for Ring Confidential Transactions. An MLSAG is essentially similar to
|
||
|
|
the LSAG's described in \cite{LWW}, but rather than having a ring
|
||
|
|
signature on a set of $n$ keys, instead, an MLSAG is a ring signature
|
||
|
|
on a set of $n$ key-vectors.
|
||
|
|
\begin{defn}
|
||
|
|
\label{def:A-key-vector-is}A \textbf{key-vector} is just a collection
|
||
|
|
$\overline{y}=\left(y_{1},...,y_{r}\right)$ of public keys with corresponding
|
||
|
|
private keys $\overline{x}=\left(x_{1},...,x_{r}\right)$.
|
||
|
|
\end{defn}
|
||
|
|
|
||
|
|
\subsection{\label{sub:BackLSAG}LWW signatures vs FS signatures}
|
||
|
|
|
||
|
|
The ring signatures used in Monero and the original CryptoNote protocol are
|
||
|
|
derived from the traceable ring signatures of \cite{FS}. The CryptoNote \cite{CN}
|
||
|
|
ring signatures come with a ``key-image'' which means that a signer
|
||
|
|
can only sign one ring on the block-chain with a given public and
|
||
|
|
private key pair or else their transaction will be marked as invalid. Because of this, one-time keys are used in CryptoNote,
|
||
|
|
which further helps anonymity.
|
||
|
|
|
||
|
|
In \cite{B}, Adam Back noticed that the Linkable Spontaneous Anonymous
|
||
|
|
Group (LSAG) signatures of \cite{LWW} can be modified to give a more efficient
|
||
|
|
linkable ring signature producing the same effect as the \cite{FS}
|
||
|
|
ring signatures. This modification reduces the storage cost on the
|
||
|
|
blockchain essentially in half.
|
||
|
|
|
||
|
|
First I recall almost verbatim the modification given in \cite{B}:
|
||
|
|
|
||
|
|
\textbf{Keygen}: Find a number of public keys $P_{i},i=0,1,...,n$
|
||
|
|
and a secret index $j$ such that $xG=P_{j}$ where $G$ is the ed25519
|
||
|
|
base-point and $x$ is the signers spend key. Let $I=xH_p\left(P_{j}\right)$
|
||
|
|
where $H_p$ is a hash function returning a point \footnote{In practice $H_p(P) = Keccak(P)\cdot G$ where $G$ is the ed25519 basepoint, although note that for the commitment scheme I will use $toPoint(Keccak(P))$, hashing successively until $Keccak(P)$ returns a multiple of the basepoint.}
|
||
|
|
Let $\mathfrak{m}$ be a given message.
|
||
|
|
|
||
|
|
\textbf{SIGN}: Let $\alpha,s_{i},\ i\neq j,\ i\in\left\{ 1,...,n\right\} $
|
||
|
|
be random values in $\mathbb{Z}_{q}$ (the ed25519 base field).
|
||
|
|
|
||
|
|
Compute
|
||
|
|
\[
|
||
|
|
L_{j}=\alpha G
|
||
|
|
\]
|
||
|
|
\[
|
||
|
|
R_{j}=\alpha H_p\left(P_{j}\right)
|
||
|
|
\]
|
||
|
|
\[
|
||
|
|
c_{j+1}=h\left(\mathfrak{m},L_{j},R_{j}\right)
|
||
|
|
\]
|
||
|
|
where $h$ is a hash function returning a value in $\mathbb{Z}_{q}$.
|
||
|
|
Now, working successively in $j$ modulo $n$, define
|
||
|
|
\[
|
||
|
|
L_{j+1}=s_{j+1}G+c_{j+1}P_{j+1}
|
||
|
|
\]
|
||
|
|
\[
|
||
|
|
R_{j+1}=s_{j+1}H_p\left(P_{j+1}\right)+c_{j+1}\cdot I
|
||
|
|
\]
|
||
|
|
\[
|
||
|
|
c_{j+2}=h\left(\mathfrak{m},\ L_{j+1},\ R_{j+1}\right)
|
||
|
|
\]
|
||
|
|
\[
|
||
|
|
\cdots
|
||
|
|
\]
|
||
|
|
\[
|
||
|
|
L_{j-1}=s_{j-1}G+c_{j-1}P_{j-1}
|
||
|
|
\]
|
||
|
|
\[
|
||
|
|
R_{j-1}=s_{j-1}H_p\left(P_{j-1}\right)+c_{j-1}\cdot I
|
||
|
|
\]
|
||
|
|
\[
|
||
|
|
c_{j}=h\left(\mathfrak{m},L_{j-1},\ R_{j-1}\right)
|
||
|
|
\]
|
||
|
|
so that $c_{1},...,c_{n}$ are defined.
|
||
|
|
|
||
|
|
Let $s_{j}=\alpha-c_{j}\cdot x_j\ mod\ l$, ($l$ being the ed25519
|
||
|
|
curve order) hence $\alpha=s_{j}+c_{j}x_j\ mod\ l$ so that
|
||
|
|
\[
|
||
|
|
L_{j}=\alpha G=s_{j}G+c_{j}x_jG=s_{j}G+c_{j}P_{j}
|
||
|
|
\]
|
||
|
|
\[
|
||
|
|
R_{j}=\alpha
|
||
|
|
H_p\left(P_{j}\right)=s_{j}H_p\left(P_{j}\right)+c_{j}I
|
||
|
|
\]
|
||
|
|
and
|
||
|
|
\[
|
||
|
|
c_{j+1}=h\left(\mathfrak{m},\ L_{j},\ R_{j}\right)
|
||
|
|
\]
|
||
|
|
and thus, given a single $c_{i}$ value, the $P_{j}$ values, the
|
||
|
|
key image $I$, and all the $s_{j}$ values, all the other $c_{k},\ k\neq i$
|
||
|
|
can be recovered by an observer. The signature therefore becomes:
|
||
|
|
\[
|
||
|
|
\sigma=\left(I,c_{1},s_{1},...,s_{n}\right)
|
||
|
|
\]
|
||
|
|
which represents a space savings over \cite[4.4]{CN} where the ring signature would instead look like:
|
||
|
|
\[
|
||
|
|
\sigma=\left(I,c_{1}, ..., c_{n},s_{1},...,s_{n}\right)
|
||
|
|
\]
|
||
|
|
\textbf{Verification }proceeds as follows. An observer computes $L_{i},R_{i},$
|
||
|
|
and $c_{i}$ for all $i$ and checks that $c_{n+1}=c_{1}$. Then the
|
||
|
|
verifier checks that
|
||
|
|
\[
|
||
|
|
c_{i+1}=h\left(\mathfrak{m},L_{i},R_{i}\right)
|
||
|
|
\]
|
||
|
|
for all $i\mod n$
|
||
|
|
|
||
|
|
\textbf{LINK}: Signatures with duplicate key images $I$ are rejected.
|
||
|
|
|
||
|
|
Note that proofs of unforgeability, anonymity, and linkability
|
||
|
|
hold for the above protocol which are only insignificant modifications to the proofs
|
||
|
|
given in \cite{LWW}. I will give a more generalized version of these
|
||
|
|
proofs for the MLSAG's.
|
||
|
|
\subsection{\label{sub:MLSAG-Description}MLSAG Description}
|
||
|
|
|
||
|
|
|
||
|
|
For the Ring CT protocol, which will be described in section
|
||
|
|
\ref{sec:Ring-CT-ForMonero}, I require a generalization of the Back
|
||
|
|
LSAG signatures described in the previous section which allows for key-vectors (Definition
|
||
|
|
\ref{def:A-key-vector-is}) rather than just keys.
|
||
|
|
|
||
|
|
|
||
|
|
Suppose that each signer of a (generalized) ring containing $n$
|
||
|
|
members has exactly $m$ keys $\left\{ P_{i}^{j}\right\} _{j=1,...,m}^{i=1,...,n}$.
|
||
|
|
The intent of the MLSAG ring signature is the following:
|
||
|
|
\begin{itemize}
|
||
|
|
\item To prove that one of the $n$ signers knows the secret keys to their entire key vector.
|
||
|
|
\item To enforce that if the signer uses any one of their $m$ signing keys in another MLSAG
|
||
|
|
signature, then the two rings are linked, and the second such MLSAG signature (ordered by the Monero block chain) is discarded.
|
||
|
|
\end{itemize}
|
||
|
|
|
||
|
|
The algorithm proceeds as follows: Let $\mathfrak{m}$ be a given
|
||
|
|
message. Let $\pi$ be a secret index corresponding to the signer
|
||
|
|
of the generalized ring. For $j=1,...,m$, let $I_{j}=x_{j}H\left(P_{\pi}^{j}\right)$,
|
||
|
|
and for $j=1,...,m$, $i=1,...,\hat{\pi},...n$ (where $\hat{\pi}$
|
||
|
|
means omit the index $\pi$) let $s_{i}^{j}$ be some random scalars (elements of $\mathbb{Z}_q$).
|
||
|
|
Now, in a manner analogous to subsection \ref{sub:BackLSAG},
|
||
|
|
define
|
||
|
|
\[
|
||
|
|
L_{\pi}^{j}=\alpha_{j}G
|
||
|
|
\]
|
||
|
|
\[
|
||
|
|
R_{\pi}^{j}=\alpha_{j}H\left(P_{\pi}^{j}\right)
|
||
|
|
\]
|
||
|
|
for random scalars $\alpha_j$ and $j=1,...,m$. Now, again analogously
|
||
|
|
to section \ref{sub:BackLSAG}, set:
|
||
|
|
\[
|
||
|
|
c_{\pi+1}=H\left(\mathfrak{m},L_{\pi}^{1},R_{\pi}^{1},...,L_{\pi}^{m},R_{\pi}^{m}\right).
|
||
|
|
\]
|
||
|
|
\[
|
||
|
|
L_{\pi+1}^{j}=s_{\pi+1}^{j}G+c_{\pi+1}P_{\pi+1}^{j}
|
||
|
|
\]
|
||
|
|
\[
|
||
|
|
R_{\pi+1}^{j}=s_{\pi+1}^{j}H\left(P_{\pi+1}^{j}\right)+c_{\pi+1}I_{j}
|
||
|
|
\]
|
||
|
|
and repeat this, incrementing $i$ modulo $n$ until we arrive at
|
||
|
|
\[
|
||
|
|
L_{\pi-1}^{j}=s_{i-1}^{j}G+c_{i-1}P_{i-1}^{j}
|
||
|
|
\]
|
||
|
|
\[
|
||
|
|
R_{\pi-1}^{j}=s_{i-1}^{j}H\left(P_{i-1}^{j}\right)+c_{i-1}\cdot I_{j}
|
||
|
|
\]
|
||
|
|
\[
|
||
|
|
c_{\pi}=H\left(\mathfrak{m},L_{\pi-1}^{1},R_{\pi-1}^{1},...,L_{\pi-1}^{m},R_{\pi-1}^{m}\right).
|
||
|
|
\]
|
||
|
|
Finally, solve for each $s_{\pi}^{j}$ using $\alpha_{j}=s_{\pi}^{j}+c_{\pi}x_{j} \mod \ell$.
|
||
|
|
The signature is then given as $\left(I_{1},...,I_{m},c_{1},s_{1}^{1},...,s_{1}^{m},s_{2}^{1},...,s_{2}^{m},...,s_{n}^{1},...,s_{n}^{m}\right)$,
|
||
|
|
so the complexity is $O\left(m\left(n+1\right)\right).$
|
||
|
|
Verification
|
||
|
|
proceeds by regenerating all the $L_{i}^{j},R_{i}^{j}$ starting from
|
||
|
|
$i=1$ as in section \ref{sub:BackLSAG} (which is the special case that $m=1$) and verifying
|
||
|
|
the hash $c_{n+1}=c_{1}.$
|
||
|
|
If these are being used in a blockchain setting such as Monero, signatures with key images $I_j$ which have already appeared are then rejected.
|
||
|
|
One can easily show, in a manner similar to \cite{LWW}:
|
||
|
|
\begin{itemize}
|
||
|
|
\item The probability of a signer generating a valid signature without knowing
|
||
|
|
all ``$m$'' private keys belonging to their key vector for index $\pi$ is negligible.
|
||
|
|
\item The probability of a signer not signing for any key of index $\pi$
|
||
|
|
is negligible. (In other words, the key images in the signature necessarily
|
||
|
|
all come from index $\pi$.)
|
||
|
|
\item If a signer signs two rings using at least one of the same public keys, then the two rings are linked.
|
||
|
|
\end{itemize}
|
||
|
|
I expand on these points below with security proofs.
|
||
|
|
|
||
|
|
|
||
|
|
\subsection{MLSAG Security Model}
|
||
|
|
|
||
|
|
An MLSAG will satisfy the following three properties of Unforgeability,
|
||
|
|
Linkability, and Signer Ambiguity which are very similar to the definitions
|
||
|
|
given in \cite{LWW}.
|
||
|
|
\begin{defn}
|
||
|
|
\label{def:(Unforgeability)--An}(Unforgeability) %
|
||
|
|
{} An MLSAG signature scheme is unforgeable if for any probabilistic polynomial time (PPT) algorithm
|
||
|
|
$\mathcal{A}$ with signing oracle $\mathcal{SO}$ producing valid
|
||
|
|
signatures, given a list of $n$ public key vectors chosen by $\mathcal{A}$,
|
||
|
|
then $\mathcal{A}$ can only with negligible probability produce a
|
||
|
|
valid signature when $\mathcal{A}$ does not know one of the corresponding
|
||
|
|
private key vectors.
|
||
|
|
\end{defn}
|
||
|
|
\begin{rem}
|
||
|
|
In the following definition, note that I include rejecting duplicate
|
||
|
|
key images as part of the verification criteria for the MLSAG, which gives a slightly different Linkability definition than the one in \cite{LWW}.
|
||
|
|
\end{rem}
|
||
|
|
\begin{defn}
|
||
|
|
\label{def:(Linkability)}(Linkability) Let $L$ be the set of all
|
||
|
|
public keys in a given setting (e.g. in a given blockchain). An MLSAG signature scheme on $L$ is key-image
|
||
|
|
linked if the probability of a PPT adversary $\mathcal{A}$ creating
|
||
|
|
two signatures $\sigma,\sigma^{\prime}$ signed with respect to key-vectors
|
||
|
|
$\overline{y}$ and $\overline{y}^{\prime}$ each containing the same
|
||
|
|
public key $y_{i}=y$$_{i}^{\prime}$ in $L$ and each verifying without being marked duplicate,
|
||
|
|
is negligible. %
|
||
|
|
\end{defn}
|
||
|
|
\begin{defn}
|
||
|
|
\label{def:(Signer-Ambiguity-)}(Signer Ambiguity %
|
||
|
|
) An MLSAG signature scheme is said to be signer ambiguous if given
|
||
|
|
any verifying signature $\sigma$ on key-vectors $\left(\overline{y}_{1},...,\overline{y}_{n}\right)$
|
||
|
|
and any set of $t$ private keys, none of the same index, nor of the
|
||
|
|
secret index, then the probability of guessing the secret key is less
|
||
|
|
than $\frac{1}{n-t}+\frac{1}{Q\left(k\right)}$
|
||
|
|
\end{defn}
|
||
|
|
Proofs of the above definitions for the MLSAG signatures are given in the appendix.
|
||
|
|
|
||
|
|
\section{\label{sec:Background-on-ConfidentialT}Background on Confidential
|
||
|
|
Transactions}
|
||
|
|
|
||
|
|
|
||
|
|
\subsection{Confidential Transactions in Bitcoin}
|
||
|
|
|
||
|
|
In \cite{GM}, Greg Maxwell describes Confidential Transactions which
|
||
|
|
are a way to send Bitcoin transactions with the amounts hidden. The
|
||
|
|
basic idea is to use a Pedersen Commitment and the method is well
|
||
|
|
described in the cited source. In this paper I make a slight modification
|
||
|
|
the the Confidential Transactions machinery in that rather than taking
|
||
|
|
the commitments to sum to zero, I instead sign for the commitment,
|
||
|
|
to prove I know a private key. This is described in more detail in
|
||
|
|
the next section.
|
||
|
|
|
||
|
|
|
||
|
|
\subsection{Modification for Ring Signatures}
|
||
|
|
|
||
|
|
Let $G$ be the ed25519 basepoint. Let\footnote{$H=MiniNero.getHForCT()$ in terms of the code at \cite{Snoe}}
|
||
|
|
\[
|
||
|
|
H=toPoint\left(cn\_fast\_hash\left(G\right)\right)
|
||
|
|
\]
|
||
|
|
Note that not every hash gives a point in the group of the basepoint (i.e. $H=\psi G$ for some unknown $\psi$) (which is contrary to what happens in secp256k1, the curve used by Bitcoin). However, it seems that choosing the basepoint itself works (I previously used H(123456G) which seemed more secure to me, but the basepoint is certainly a more natural choice).
|
||
|
|
Choosing $H = \gamma G$ for some unknown $\gamma$ is necessary so that all the usual elliptic curve math holds.
|
||
|
|
|
||
|
|
Under the discrete
|
||
|
|
logarithm assumption on ed25519, the probability of an adversary discovering $\gamma$
|
||
|
|
is negligible.
|
||
|
|
Define $C\left(a,x\right)=xG+aH$, the commitment to the value $a$
|
||
|
|
with mask $x$. Note that as long as $log_{G}H$ is unknown, and if
|
||
|
|
$a\neq0$, then $log_{G}C\left(a,x\right)$ is unknown. On the other
|
||
|
|
hand, if $a=0$, then $log_{G}C\left(a,x\right)=x$, so it is possible
|
||
|
|
to sign with sk-pk keypair $\left(x,C\left(0,x\right)\right).$
|
||
|
|
|
||
|
|
In \cite{GM}, there are input commitments, output commitments, and
|
||
|
|
the network checks that
|
||
|
|
\[
|
||
|
|
\sum Inputs=\sum Outputs.
|
||
|
|
\]
|
||
|
|
However, this does not suffice in Monero: Since a given transaction
|
||
|
|
contains multiple possible inputs $P_{i},i=1,...,n$, only one of
|
||
|
|
which belong to the sender, (see \cite[4.4]{CN}), then if we are
|
||
|
|
able to check the above equality, it must be possible for the network
|
||
|
|
to see which $P_{i}$ belongs to the sender of the transaction. This
|
||
|
|
is undesirable, since it removes the anonymity provided by the ring
|
||
|
|
signatures. Thus instead, commitments for the inputs and outputs are
|
||
|
|
created as follows (suppose first that there is only one input)
|
||
|
|
|
||
|
|
\[
|
||
|
|
C_{in}=x_{c}G+aH
|
||
|
|
\]
|
||
|
|
\[
|
||
|
|
C_{out-1}=y_{1}G+b_{1}H
|
||
|
|
\]
|
||
|
|
\[
|
||
|
|
C_{out-2}=y_{2}G+b_{2}H
|
||
|
|
\]
|
||
|
|
such that $x_{c}=y_{1}+y_{2}+z$, $x_{c}-y_{1}-y_{2}=z$, $y_{i}$
|
||
|
|
are mask values, $z>0$ and $a=b_{1}+b_{2}.$ Here $x_{c}$ is a special
|
||
|
|
private key the ``amount key'' known only to the sender, and to
|
||
|
|
the person who sent them their coins, and must be different than their
|
||
|
|
usual private key. In this case,
|
||
|
|
\[
|
||
|
|
C_{in}-\sum_{i=1}^{2}C_{out-i}
|
||
|
|
\]
|
||
|
|
\[
|
||
|
|
=x_{c}G+aH-y_{1}G-b_{1}H-y_{2}G-b_{2}H
|
||
|
|
\]
|
||
|
|
\[
|
||
|
|
=zG.
|
||
|
|
\]
|
||
|
|
Thus, the above summation becomes a commitment to $0$, with $sk=z$,
|
||
|
|
and $pk=zG$, rather than an actual equation summing to zero. Note
|
||
|
|
that $z$ is not computable to the originator of $x_{c}$'s coins,
|
||
|
|
unless they know both of the $y_{1},y_{2}$, but even this can be simply mitigated by including an additional change address (the usual case is that the second commitment, with $y_2$ as mask, is sent to yourself as change).
|
||
|
|
|
||
|
|
Since it is undesirable to show which input belongs to the sender,
|
||
|
|
a ring signature consisting of all the input commitments $C_{i},i=1,...,s,...,n$
|
||
|
|
(where $s$ is the secret index of the commitment of the sender),
|
||
|
|
adding the corresponding pubkey (so commitments and pubkeys are paired
|
||
|
|
$\left(C_{i},P_{i}\right)$ only being allowed to be spent together)
|
||
|
|
and subtracting $\sum C_{out}$ is created:
|
||
|
|
\[
|
||
|
|
\left\{ P_{1}+C_{1,in}-\sum_{j}C_{j,out},...,P_{s}+C_{s,in}-\sum_{j}C_{j,out},...,P_{n}+C_{n,in}-\sum_{j}C_{j,out}\right\} .
|
||
|
|
\]
|
||
|
|
This is a ring signature which can be signed since we know one of
|
||
|
|
the private keys (namely $z+x^{\prime}$ with $z$
|
||
|
|
as above and $x^{\prime}G=P_{s}$). In fact, since we know, for each $i$, both the private key for $P_{i}$ and the private key for $P_{i}+C_{i,in}-\sum_{j}C_{j,out}$,
|
||
|
|
we can perform a signature as in section \ref{sub:MLSAG-Description}. This precise details are described in Definition \ref{RCTProtocol}.
|
||
|
|
|
||
|
|
As noted in \cite{GM}, it is important to prove that the output amounts\footnote{Since input commitments could potentially be just inherited from the
|
||
|
|
previous transaction, it suffices to consider the output amounts.}
|
||
|
|
$b_{1},...b_{n}$ all lie in a range of positive values, e.g. $(0,2^{16}).$
|
||
|
|
This can be accomplished essentially the same way as in \cite{GM} and is described in more detail in section \ref{AgSchnorr}.
|
||
|
|
|
||
|
|
Finally, note that in the above, I have not made any mention of the tag-linkability property which is used in Monero and Cryptonote to prevent double-spends. The tag-linkability property here will result from combining the above discussion with the MLSAG signatures as described in Definition \ref{RCTProtocol}.
|
||
|
|
|
||
|
|
|
||
|
|
\section{\label{sec:Ring-CT-ForMonero}Ring CT For Monero Protocol}
|
||
|
|
|
||
|
|
|
||
|
|
\subsection{Protocol Description}
|
||
|
|
\begin{defn}
|
||
|
|
\label{RCTProtocol}(Tag-Linkable Ring-CT with
|
||
|
|
Multiple Inputs and One-time Keys) \end{defn}
|
||
|
|
\begin{itemize}
|
||
|
|
\item Let $\left\{ \left(P_{\pi}^{1},C_{\pi}^{1}\right),...,\left(P_{\pi}^{m},C_{\pi}^{m}\right)\right\} $
|
||
|
|
be a collection of addresses / commitments with corresponding secret
|
||
|
|
keys $x_{j},\ j=1,...,m$.
|
||
|
|
\item Find $q+1$ collections $\left\{ \left(P_{i}^{1},C_{i}^{1}\right),...,\left(P_{i}^{m},C_{i}^{m}\right)\right\} ,i=1,...,q+1$
|
||
|
|
which are not already tag linked in the sense of \cite[page 6]{FS}.
|
||
|
|
\item Decide on a set of output addresses $\left(Q_{i},C_{i,out}\right)$
|
||
|
|
such that $\sum_{j=1}^{m}C_{\pi}^{j}-\sum_{i}C_{i,out}$ is a commitment
|
||
|
|
to zero.
|
||
|
|
\item Let
|
||
|
|
\[
|
||
|
|
\mbox{\ensuremath{\mathfrak{R}}}\coloneqq\left\{ \left\{ \left(P_{1}^{1},C_{1}^{1}\right),...,\left(P_{1}^{m},C_{1}^{m}\right),\left(\sum_{j}P_{1}^{j}+\sum_{j=1}^{m}C_{1}^{j}-\sum_{i}C_{i,out}\right)\right\} ,\right.
|
||
|
|
\]
|
||
|
|
\[
|
||
|
|
...,
|
||
|
|
\]
|
||
|
|
\[
|
||
|
|
\left.\left\{ \left(P_{q+1}^{1},C_{q+1}^{1}\right),...,\left(P_{q+1}^{m},C_{q+1}^{m}\right),\left(\sum_{j}P_{q+1}^{j}+\sum_{j=1}^{m}C_{q+1}^{j}-\sum_{i}C_{i,out}\right)\right\} \right\} .
|
||
|
|
\]
|
||
|
|
be the generalized ring which we wish to sign. Note that the last
|
||
|
|
column is a Ring-CT ring in the sense of section \ref{sec:Ring-CT-ForMonero}.
|
||
|
|
\item Compute the MLSAG signature $\Sigma$ on $\mathfrak{R}.$
|
||
|
|
\end{itemize}
|
||
|
|
In this case, by Theorem \ref{thm:Unforgeability}, $P_{\pi}^{j},j=1,...,m$ cannot be the signer of any
|
||
|
|
additional non-linked Ring Signatures in the given superset $\mathcal{P}$
|
||
|
|
of all such pairs $\mathcal{P}=\left\{ \left(P,C\right)\right\} $
|
||
|
|
after signing $\Sigma$.
|
||
|
|
\begin{rem}
|
||
|
|
Space complexity of the above protocol. Note that the size of the
|
||
|
|
signature $\Sigma$ on $\mathfrak{R}$ according to definition \ref{RCTProtocol}
|
||
|
|
is actually smaller, for $m>1$, than a current CryptoNote \cite{CN}
|
||
|
|
ring signature based transaction which includes multiple inputs. This
|
||
|
|
is because of the size improvements, given by \cite{LWW}, to each
|
||
|
|
column. Note also, it is probably not necessary to include the key-image
|
||
|
|
of the commitment entry of the above signature. Further size optimizations
|
||
|
|
are likely possible.\end{rem}
|
||
|
|
|
||
|
|
\subsection{Conversion from Visible Denominations to Commitments}
|
||
|
|
\label{conversion}
|
||
|
|
|
||
|
|
As Monero currently uses Blockchain visible scalars to represent amounts, it is important that there is a way to convert from visible amounts to commitments while preserving anonymity. In fact, this is not difficult. Given a pair $(P, a)$ where $P$ is a public key and $a$ represents an amount, this may be used as the input to a transaction as $(P, aH)$, and it must be checked by the verifier that the input amount $a$ multiplied by the masking point $H$, indeed gives $aH$. Thus at the first step, the input amounts will not be hidden, but the outputs of this transaction can be hidden, and all the necessary relations outlined in section \ref{sec:Ring-CT-ForMonero} hold. Note that a range proof is not necessary for such an input.
|
||
|
|
\begin{rem}
|
||
|
|
The obvious benefit of this method of converting from visible amounts to commitments is that the amount of coins generated by the mining process is trustlessly verifiable. This is an advantage of the Ring CT protocol over payment schemes such as \cite{Z} which rely on a trusted setup phase.
|
||
|
|
\end{rem}
|
||
|
|
\subsection{Transaction Fees}
|
||
|
|
As Monero is strongly decentralized (i.e. proof of work) it is necessary to pay miners a transaction fee for each transaction. This helps with the network security to prevent blockchain bloat. These fees must be paid "unmasked" i.e. just as $bH$, rather than $xG+bH$, and for some standardized amount $b$ so that the miner can verify that $b\cdot H = bH$ and thus there is enough money for the transaction fee while still having the equations in terms of $H$ so the necessary relations of section \ref{sec:Ring-CT-ForMonero} hold.
|
||
|
|
\subsection{Ring Multisignature}
|
||
|
|
Note that a simple version of a $t$ of $m$ of $n$ ring- multisignature can be done with the MLSAG signatures. This allows a group of $m$ participants to create a multi-signature such that $t$ out of $m$ must sign for the signature to be accepted as valid, and in addition, it is signer ambiguous which $m$ keys are the participants out of the $n$ keys.
|
||
|
|
\begin{itemize}
|
||
|
|
\item The $n$ participants in the multisignature create a shared secret $x_e$ and public key $P_e$ and share multisig key-images
|
||
|
|
\[
|
||
|
|
I_j = x_e H(P_e | P_j)
|
||
|
|
\]
|
||
|
|
with $P_j$ the public key of the participant.
|
||
|
|
\item Any participant of the multisignature selects $n-m$ additional public keys on the block-chain and creates an MLSAG signature with the first row the total $n$ keys, and the second row having each entry the shared key $P_e$.
|
||
|
|
\item Each signer transmitting part of the multisignature provides the initial $I_j,\ j=1,...,m$ so that the signature is accepted after $t$ verifying signatures have been transmitted on the blockchain, each corresponding to one of the key images $I_j$.
|
||
|
|
\end{itemize}
|
||
|
|
|
||
|
|
An expanded writeup of the ring-multisignature is in the works.
|
||
|
|
|
||
|
|
\section{Aggregate Schnorr Range Proofs}
|
||
|
|
\label{AgSchnorr}
|
||
|
|
In \cite{GM}, the confidential transactions without ring signatures uses a type of ring signature based on \cite{abe} called a Borromean ring signature, which helps to prove a committed value lies within a certain range. In this article, I will outline an alternative method, inspired by \cite{herranz}, which has the same space savings, but perhaps simpler security proofs. The motivation for this is as follows: Suppose that a given transaction has input commitments
|
||
|
|
\[
|
||
|
|
C_{in} = a_{in} G + 10 H
|
||
|
|
\]
|
||
|
|
and output commitments
|
||
|
|
\[
|
||
|
|
C_{out,1} = a_{out,1} G + 5 H,\ C_{out,2} = a_{out,2} G + 5 H
|
||
|
|
\]
|
||
|
|
this scenario is valid as it is possible to sign for
|
||
|
|
\[
|
||
|
|
C_{in} - C_{out,1} - C_{out,2} = \left(a_{in} - a_{out,1} - a_{out,2} \right) G
|
||
|
|
\]
|
||
|
|
However, note that (without range proofs) it would be possible to alternatively set output commitments
|
||
|
|
\[
|
||
|
|
C_{out,1} = a_{out,1} G - H,\ C_{out,2} = a_{out,2} G + 11 H
|
||
|
|
\]
|
||
|
|
as $-1$ is a very large number modulo the curve group order, free money has been created. It is therefore necessary to prove that the $C_{out,i}$ are commitments to values which are positive and lie in a restricted range $[0,2^n]$ for some $n$.
|
||
|
|
To do this, one decomposes each output value into binary:
|
||
|
|
\[
|
||
|
|
b = b_0 2^0 + b_1 2^1 + b_2 2^2 + \cdots + b_n 2^n
|
||
|
|
\]
|
||
|
|
and computes commitments $C_{out,i}^j$ to $b_j \cdot 2^j $ and such that
|
||
|
|
\[
|
||
|
|
C_{out,i}^1 + C_{out,i}^2 + \cdots + C_{out,i}^n = C_{out,i}
|
||
|
|
\]
|
||
|
|
Finally, using secret key $b_j$, one computes a ring signature on
|
||
|
|
\[
|
||
|
|
(C_{out,i}^j, C_{out,i}^j - 2^j H)
|
||
|
|
\]
|
||
|
|
for all $j$ and provides the $C_{out,i}^j$ to the verifying parties (in this case, the miners).
|
||
|
|
|
||
|
|
For space savings, one can either use a Borromean ring signature (as in \cite{GM}) to combine all of these simple ring signatures, or a type of aggregate ring signature defined as follows:
|
||
|
|
\subsubsection{ Aggregate Schnorr Non-linkable Ring Signature (ASNL) Generation}
|
||
|
|
Let $(x_i^j, P_1^j, P_2^j)$ be a set of keys, $j=1,...,n$ with $x_i^j$ the secret key of $P_i^j$
|
||
|
|
\begin{itemize}
|
||
|
|
\item For each $j$, let $i^\prime := i+1\ mod\ 2$, set $\alpha_j$ a random scalar, and compute $L_i^j = \alpha_j G$.
|
||
|
|
\item Set $c_{i^\prime}^j= H_s(L_i^j)$, where $H_s$ is a cryptographic hash function returning a scalar, and after choosing $s_{i^\prime}^j$ random, compute
|
||
|
|
\[
|
||
|
|
L_{i^\prime}^j = s_{i^\prime} G + c_{i^\prime} H.
|
||
|
|
\]
|
||
|
|
\item Set $c_i = H_s(L_{i^\prime}^j)$ and compute
|
||
|
|
\[
|
||
|
|
s_i^j = \alpha - c_i^j x_i \ mod\ \ell
|
||
|
|
\]
|
||
|
|
\item Return $(L_1^j, s_2^j)$ for all $j$ and $s = \sum_j s_1^j$.
|
||
|
|
\end{itemize}
|
||
|
|
|
||
|
|
\subsubsection{ Aggregate Schnorr Non-linkable Ring Signature (ASNL) Verification}
|
||
|
|
Start with $(P_1^j, P_2^j, L_1^j, s_2^j)$ for $j=1,...,n$ and $s$.
|
||
|
|
\begin{itemize}
|
||
|
|
\item For all $j$, compute $c_2^j = H_s (L_1^j)$, $L_2^j = s_2^j G + c_2^j H$, and $c_1^j = H_s(L_2^j)$.
|
||
|
|
\item If $\sum_{j=1}^n L_1^j = s G + (c_1^j + \cdots + c_n^j) H$ then return $0$ for a valid signature. Otherwise return $-1$.
|
||
|
|
\end{itemize}
|
||
|
|
\begin{thm}
|
||
|
|
The Aggregate Schnorr Non-linkable ring signature is unforgeable under the discrete logarithm assumption.
|
||
|
|
\end{thm}
|
||
|
|
\begin{proof}
|
||
|
|
I sketch a proof in the case $n=2$. The general case is similar. Suppose that an adversary $\mathcal{A}$ is able to forge an ASNL signature on
|
||
|
|
\[
|
||
|
|
\left\{ (x_i^1, P_1^1, P_2^1), (x_i^2, P_1^2, P_2^2) \right\}
|
||
|
|
\]
|
||
|
|
with non-negligible probability while knowing at most one of the $x_i^j$ (suppose without loss of generality that $\mathcal{A}$ knows $x_i^1$). For any given such forgery:
|
||
|
|
\[
|
||
|
|
\{s,(P_1^j, P_2^j, L_1^j, s_2^j)\},\ j=1,2,
|
||
|
|
\]
|
||
|
|
I solve the discrete logarithm of $P_1^2$ with non-negligible probability. Following the verification algorithm, let $c_1^j = H_s\left(s_2^j G + H_s(L_1^j)H\right)$. It must then be true that
|
||
|
|
\[
|
||
|
|
L_1^1 + L_1^2 = sG + \left(c_1^1 P_1^1 + c_1^2 P_1^2\right).
|
||
|
|
\]
|
||
|
|
Supposing that $L_1^1 = a G$ and $L_1^2 = bG$ with $a,b$ known to $\mathcal{A}$, then
|
||
|
|
\[
|
||
|
|
aG + bG - sG - c_1^1 P_1^1 = c_1^2 P_1^2
|
||
|
|
\]
|
||
|
|
so, as $c_1^2$ is determined by the verification protocol, it must be the case that $\mathcal{A}$ knows the private key of $P_1^2$,
|
||
|
|
\[
|
||
|
|
x_1^2 := \frac{a+b-s-c_1^1 x_1^1}{c_1^2} \mod \ell
|
||
|
|
\]
|
||
|
|
This contradicts the discrete logarithm assumption for the given group.
|
||
|
|
\end{proof}
|
||
|
|
\subsection{Representing Amounts }
|
||
|
|
Amounts in the Ring CT protocol be represented in a similar manner as in \cite{GM}, however modified slightly to fit Monero.
|
||
|
|
CryptoNote coins organize denominations of coins into a databases of indices, so that they may be referenced in order of their appearance as inputs for ring signatures. As all values in CryptoNote coins are represented as 64-bit unsigned integers, we can use a range proof over the entire register to encode the output amount to the recipient. Beneficially, this also allows all outputs to be mixed with each other, so only a single index of outputs in order of appearance is required. A range proof of this is approximately 5 kilobytes. Ring signatures for inputs then become much more resilient to analysis, as the anonymity set is widely expanded.
|
||
|
|
|
||
|
|
While the range proofs are large, using a transaction hashing scheme that signs the transaction "prefix" (both input indices and outputs) and stores the range proof, along with ring signatures, separately enables large amounts of space saving when syncing to a checkpoint or operating as an SPV node. Similar to Sidechains Elements \cite{El}, we would store
|
||
|
|
$H(H(prefix) || H(signatures))$ in the merkle tree. Then, nodes syncing to and trusting a checkpoint need only download the prefix and a hash of the signatures, effectively reducing the amount of bandwidth require to sync dramatically. Because the transaction prefix uses a varint for the outputs it references in its ring signatures and outputs funds to single public keys, they are miniscule in comparison to the ring signature data1in the inputs and range proofs. Later, the ring signatures may even be pruned from the database by some nodes to further save space, storing instead only the comparatively small UTXO set.
|
||
|
|
\subsubsection{Passing Amounts to Receiver}
|
||
|
|
Now, given any output amount, $b = b_0 2^0 + b_1 2^1 + \cdots b_n 2^n $, a sender computes a new private /public key pair and corresponding shared ECDH secret $ss$ and makes the following information available in their transaction:
|
||
|
|
\begin{itemize}
|
||
|
|
\item $C_j = a_j G + (b_j 2^j) H$ where $a_i$ are some random numbers for $j=0,...,n$.
|
||
|
|
\item The data $\left\{(L_1^i, s_2^j),s\right\}$.
|
||
|
|
\item ECDH public key and $a + ss\ mod\ \ell$ where $a = a_0 + \cdots + a_n$.
|
||
|
|
\end{itemize}
|
||
|
|
The receiver then:
|
||
|
|
\begin{itemize}
|
||
|
|
\item Computes their shared secret $ss$ and computes $a$ from $a + ss\ mod\ \ell$.
|
||
|
|
\item Computes $C = \sum C_i$, computes $C - aG = bH$, and finds $b$ by comparing to all $bH$ in the given range $[0, 2^n]$. (In practice this will be a quick 500 kilobyte lookup with $n = 14$ as in the previous section. If on the other hand $2^{32}$ were to be chosen as the upper limit value, as in \cite{GM}, the search would become computationally intensive).
|
||
|
|
\end{itemize}
|
||
|
|
|
||
|
|
|
||
|
|
\section{Conclusion}
|
||
|
|
The Ring Confidential Transactions protocol provides a strongly decentralized cryptocurrency (i.e. there is no privileged party) which has provable security estimates regarding the hiding of amounts, origins and destinations. In addition, coin generation in the Ring Confidential Transactions protocol is trustless and verifiably secure. These five factors are a necessity of a cash-like crypto-currency such as Monero.
|
||
|
|
|
||
|
|
\bibliographystyle{plain}
|
||
|
|
\bibliography{biblio}
|
||
|
|
|
||
|
|
\appendix
|
||
|
|
|
||
|
|
\section{Appendix: Security Proofs}
|
||
|
|
|
||
|
|
\subsection{MLSAG Unforgeability}
|
||
|
|
|
||
|
|
This follows similarly to \cite[Theorem 1]{LWW}. Let $H_{1}$ and
|
||
|
|
$H_{2}$ random oracles, and $\mathcal{SO}$ be a signing oracle which
|
||
|
|
returns valid MLSAG signatures. Assume there is a probabilistic polynomial
|
||
|
|
time (PPT) adversary $\mathcal{A}$ with the ability to forge an MLSAG
|
||
|
|
from a list of key vectors $L$ with non-negligible probability
|
||
|
|
\[
|
||
|
|
Pr\left(\mathcal{A}\left(\mathcal{L}\right)\to\left(m,\sigma\right):Ver\left(L,m,\sigma\right)=True\right)>\frac{1}{Q_{1}\left(k\right)}
|
||
|
|
\]
|
||
|
|
where $Q_{1}$ is a polynomial inputting a security parameter $k$
|
||
|
|
and where $\left(m,\sigma\right)$ is not one of the signatures returned
|
||
|
|
by $\mathcal{S}\mathcal{O}$. Assume that $\mathcal{A}$ makes no
|
||
|
|
more than $q_{H}+nq_{S}$ (with $n$ the number of keys in $\mathcal{L}$)
|
||
|
|
queries to the signing oracles $H_{1},H_{2}$ and $\mathcal{SO}$
|
||
|
|
respectively. The oracles $H_{1}$ and $H_{2}$ are assumed independent
|
||
|
|
and random and are consistent given duplicate queries. The signing
|
||
|
|
oracle $\mathcal{SO}$ is also allowed to query $H_{1}$ and $H_{2}$.
|
||
|
|
Given $\mathcal{A}$, I will show it is possible to create a PPT adversary
|
||
|
|
$\mathcal{M}$ which uses $\mathcal{A}$ to find the discrete logarithm
|
||
|
|
of one of the keys in $\mathcal{L}$.
|
||
|
|
|
||
|
|
If $L$ is a set of key vectors $\left\{ \overline{y_{1}},...,\overline{y_{n}}\right\} $
|
||
|
|
each of size $r$, (i.e. $\overline{y_{i}}=\left(y_{1}^{i},...,y_{r}^{i}\right)$
|
||
|
|
with $y_{1},...,y_{r}$ public keys) then a forged signature
|
||
|
|
\[
|
||
|
|
\sigma=\left(c_{1},s_{1},...,s_{n},y_{0}\right)
|
||
|
|
\]
|
||
|
|
produced by $\mathcal{A}$ must satisfy
|
||
|
|
\[
|
||
|
|
c_{i+1}=H\left(\mathfrak{m},L_{i}^{1},R_{i}^{1},...,L_{i}^{m},R_{i}^{m}\right)
|
||
|
|
\]
|
||
|
|
where the $i$ are taken mod $n$, and the $L_{i}^{j}$, $R_{i}^{j}$
|
||
|
|
are defined as in section \ref{sub:MLSAG-Description}. The new adversary $\mathcal{M}$
|
||
|
|
may call $\mathcal{A}$ to forge signatures a polynomial number of
|
||
|
|
times and will record each Turing script $\mathcal{T}$ whether
|
||
|
|
or not the forgery is successful.
|
||
|
|
\begin{lem}
|
||
|
|
\label{lem:RewindingLemma}\cite[Lemma 1]{LWW} %
|
||
|
|
{} Let $\mathcal{M}$ invoke $\mathcal{A}$ to obtain a transcript $\mathcal{T}.$
|
||
|
|
If $\mathcal{T}$ is successful, then $\mathcal{M}$ rewinds $\mathcal{T}$
|
||
|
|
to a header $H$ and re-simulates $\mathcal{A}$ to obtain transcript
|
||
|
|
$\mathcal{T}^{\prime}$ . If $Pr\left(\mathcal{T}\ \mbox{succeeds}\right)=\epsilon$
|
||
|
|
, then $Pr\left(\mathcal{T}^{\prime}\mbox{ succeeds}\right)=\epsilon.$ \end{lem}
|
||
|
|
\begin{proof}
|
||
|
|
Follows easily from the cited Theorem. \end{proof}
|
||
|
|
\begin{thm}
|
||
|
|
\label{thm:Unforgeability}The probability that an adversary $\mathcal{A}$
|
||
|
|
forges a verifying MLSAG signature is negligible under the discrete
|
||
|
|
logarithm assumption.
|
||
|
|
\end{thm}
|
||
|
|
\begin{proof}
|
||
|
|
I follow the notation introduced above. Similarly to \cite[Theorem 1]{LWW},
|
||
|
|
since the probability of guessing the output of a random oracle is
|
||
|
|
negligible, therefore, for each successful forgery $\mathcal{A}$ completes
|
||
|
|
with transcript $\mathcal{T}$, there are $m_{\mathcal{T}}$ queries
|
||
|
|
to $H_{1}$ matching the $n$ queries used to verify the signature.
|
||
|
|
Thus let $X_{i_{1}},...,X_{i_{m}}$ denote these queries used
|
||
|
|
in verification for the $i^{th}$ such forgery and let $\pi$ be the
|
||
|
|
index corresponding to the last such verification query for a given
|
||
|
|
forgery
|
||
|
|
\[
|
||
|
|
X_{i_{m}}=H_{1}\left(m,L_{\pi-1}^{1},R_{\pi-1}^{1},...,L_{\pi-1}^{m_{\mathcal{T}}},R_{\pi-1}^{m_{\mathcal{T}}}\right).
|
||
|
|
\]
|
||
|
|
(Intuitively, $\pi$ corresponds to what would be the secret index
|
||
|
|
of the forged signature, since it corresponds to the last call to
|
||
|
|
the random oracle for the given signature).
|
||
|
|
|
||
|
|
An attempted forgery $\sigma$ produced by $\mathcal{A}$ is an $\left(\ell,\pi\right)$-forgery
|
||
|
|
if $i_{1}=\ell$ and $\pi$ is as above (so this forgery corresponds
|
||
|
|
to queries $\ell$ through $\ell+\pi$). By assumption, there exists
|
||
|
|
a pair $\left(\ell,\pi\right)$ such that the probability that the
|
||
|
|
corresponding transcript $\mathcal{T}$ gives a successful forgery,
|
||
|
|
$\epsilon_{\ell,\pi}\left(\mathcal{T}\right)$, satisfies
|
||
|
|
\[
|
||
|
|
\epsilon_{\ell,\pi}\ge\frac{1}{m_{\mathcal{T}}\left(q_{H}+m_{\mathcal{T}}q_{S}\right)}\cdot\frac{1}{Q_{1}\left(k\right)}\ge\frac{1}{n\left(q_{H}+nq_{S}\right)}\cdot\frac{1}{Q_{1}\left(k\right)}.
|
||
|
|
\]
|
||
|
|
Now, rewinding $\mathcal{T}$ to just before the $\ell^{th}$ query,
|
||
|
|
and again attempting a forgery on the same set of keys, (and letting
|
||
|
|
$H_{1}$ compute new coin flips for all of it's succeeding queries)
|
||
|
|
then by Lemma \ref{lem:RewindingLemma}, it follows that the probability
|
||
|
|
that $\mathcal{\mathcal{T}^{\prime}}$ is also a successful forgery
|
||
|
|
satisfies
|
||
|
|
\[
|
||
|
|
\epsilon_{\ell,\pi}\left(\mathcal{T}^{\prime}\right)\ge\frac{1}{n\left(q_{H}+nq_{S}\right)}\cdot\frac{1}{Q_{1}\left(k\right)}.
|
||
|
|
\]
|
||
|
|
Therefore, the probability that both $\mathcal{T}$ and $\mathcal{T}^{\prime}$
|
||
|
|
correspond to verifying forgeries $\sigma$ and $\sigma^{\prime}$
|
||
|
|
is non-negligible:
|
||
|
|
\[
|
||
|
|
\epsilon_{l,\pi}\left(\mathcal{T\ }and\ \mathcal{T}^{\prime}\right)\ge\left(\epsilon_{l,\pi}\left(\mathcal{T}\right)\right)^{2}.
|
||
|
|
\]
|
||
|
|
|
||
|
|
|
||
|
|
As new coin-flips have been computed for the random oracle outputs
|
||
|
|
of $H_{1},$ it follows that with overwhelming probability there is
|
||
|
|
$j$ such that $s_{\pi}^{j}\neq s_{\pi}^{\prime j}$ and $c_{\pi}\neq c_{\pi+1}$.
|
||
|
|
Thus we can solve for the private key of index $\pi$:
|
||
|
|
\[
|
||
|
|
x_{\pi}^{j}=\frac{s_{\pi}^{\prime j}-s_{\pi}^{j}}{c_{\pi}-c_{\pi}^{\prime}}\ mod\ q
|
||
|
|
\]
|
||
|
|
which contradicts the discrete logarithm assumption.
|
||
|
|
\end{proof}
|
||
|
|
|
||
|
|
\subsection{MLSAG Linkability}
|
||
|
|
\begin{thm}
|
||
|
|
(Key-Image Linkability) The probability that a PPT adversary $\mathcal{A}$
|
||
|
|
can create two verifying (and unlinked in the given setting) signatures $\sigma,\sigma^{\prime}$ signed
|
||
|
|
with respect to key vectors $\overline{y}$ and $\overline{y}^{\prime}$respectively
|
||
|
|
such that there exists a public key $y$ in both $\overline{y}$ and
|
||
|
|
$\overline{y}^{\prime}$ is negligible. \end{thm}
|
||
|
|
\begin{proof}
|
||
|
|
Suppose to the contrary that $\mathcal{A}$ has created two verifying
|
||
|
|
signatures $\sigma$ and $\sigma^{\prime}$ both signed with respect to key
|
||
|
|
vectors $\overline{y}$ and $\overline{y}^{\prime}$ respectively such
|
||
|
|
that there exists a public key $y$ in both $\overline{y}$ and $\overline{y}^{\prime}.$
|
||
|
|
Let $y$ appear as element $j$ of $\overline{y}$, and as element
|
||
|
|
$j^{\prime}$ element of $\overline{y}^{\prime}.$ By Theorem \ref{thm:Unforgeability},
|
||
|
|
it holds with overwhelming probability that there exists indices $\pi$
|
||
|
|
and $\pi^{\prime}$ for the public keys in $\sigma$ and $\sigma^{\prime}$
|
||
|
|
respectively such that
|
||
|
|
\[
|
||
|
|
L_{\pi}^{j}=s_{\pi}^{j}G+c_{\pi}y_{\pi}^{j}
|
||
|
|
\]
|
||
|
|
\[
|
||
|
|
R_{\pi}^{j}=s_{\pi}^{j}H\left(y_{\pi}^{j}\right)+c_{\pi}I_{j}
|
||
|
|
\]
|
||
|
|
and
|
||
|
|
|
||
|
|
\[
|
||
|
|
L_{\pi^{\prime}}^{j\prime}=s_{\pi^{\prime}}^{j^{\prime}}G+c_{\pi^{\prime}}y_{\pi^{\prime}}^{j^{\prime}}
|
||
|
|
\]
|
||
|
|
\[
|
||
|
|
R_{\pi^{\prime}}^{j^{\prime}}=s_{\pi^{\prime}}^{j^{\prime}}H\left(y_{\pi^{\prime}}^{j^{\prime}}\right)+c_{\pi^{\prime}}I_{j^{\prime}}
|
||
|
|
\]
|
||
|
|
with
|
||
|
|
\[
|
||
|
|
log_{G}L_{\pi}^{j}=log_{H\left(y_{\pi}^{j}\right)}R_{\pi}^{j}
|
||
|
|
\]
|
||
|
|
and
|
||
|
|
\[
|
||
|
|
log_{G}L_{\pi^{\prime}}^{j^{\prime}}=log_{H\left(y_{\pi^{\prime}}^{j^{\prime}}\right)}R_{\pi^{\prime}}^{j^{\prime}}
|
||
|
|
\]
|
||
|
|
Letting $x$ denote the private key of $y,$ $y=xG$, then after solving
|
||
|
|
the above for $I_{j}$ and $I_{j^{\prime}}$ it follows that $I_{j}=xH\left(y_{\pi}^{j}\right)=xH\left(y\right)$
|
||
|
|
and similarly $I_{j^{\prime}}=xH\left(y\right).$ Thus the two signatures
|
||
|
|
include $I_{j}=I_{j^{\prime}}$, and therefore, since duplicate key images are rejected, one of them must not verify.
|
||
|
|
\end{proof}
|
||
|
|
\subsection{MLSAG Anonymity}
|
||
|
|
To prove the anonymity of the above protocol in the random oracle
|
||
|
|
model, let $H_{1},H_{2}$ be random oracles modeling discrete hash
|
||
|
|
functions. Let $\mathcal{A}$ be an adversary against anonymity. I
|
||
|
|
construct an adversary $\mathcal{M}$ against the Decisional Diffie Helman
|
||
|
|
(DDH) assumption as follows.
|
||
|
|
The DDH asumption says that given a
|
||
|
|
tuple $\left(G,aG,bG,\gamma G\right)$, the probability of determining
|
||
|
|
whether $\gamma G=abG$ is negligible.
|
||
|
|
\begin{thm}
|
||
|
|
\label{thm:Ring-CT-protocol}Ring CT protocol is signer-ambiguous
|
||
|
|
under the Decisional Diffie-Helman assumption. \end{thm}
|
||
|
|
%asdf stopped editing here
|
||
|
|
\begin{proof}
|
||
|
|
(Similar proof to \cite[Theorem 2]{LWW}) Assume that the Decisional Diffie-Helman problem is hard in the cyclic group generated by $G$ and suppose there exists a PPT
|
||
|
|
adversary $\mathcal{A}$ against signer ambiguity. Thus given a list
|
||
|
|
$L$ of $n$ public key-vectors of length $m$, a set of $t$ private
|
||
|
|
keys $\mathcal{D}_{t}=\left\{ x_{1},...,x_{t}\right\} $, a valid
|
||
|
|
signature $\sigma$ on $L$ signed by a user with respect to a key-vector
|
||
|
|
$\overline{y}$ such that the corresponding private key-vector $\overline{x}=\left(x_{1}^{\pi},...,x_{m}^{\pi}\right)$
|
||
|
|
satisfies $x_{j}^{\pi}\notin\mathcal{D}_{t}$, then $\mathcal{A}$
|
||
|
|
can decide $\pi$ with probability
|
||
|
|
\[
|
||
|
|
Pr\left(\mathcal{A}\to\pi\right)>\frac{1}{n-t}+\frac{1}{Q\left(k\right)}
|
||
|
|
\]
|
||
|
|
for some polynomial $Q\left(k\right)$. I construct a PPT adversary
|
||
|
|
$\mathcal{M}$ which takes as inputs a tuple
|
||
|
|
$\left(G,aG,bG,c_{i}G\right)$ where $i\in \{0,1\}$ is randomly chosen (and not a priori known to $\mathcal{M}$), $c_{1}=ab$, and $c_{0}$ is a random scalar, and outputs $i$ with probability
|
||
|
|
\[
|
||
|
|
Pr\left(\mathcal{M}\left(G, aG,bG,c_{i}G\right)\to i\right)\ge\frac{1}{2}+\frac{1}{Q_{2}\left(k\right)}
|
||
|
|
\]
|
||
|
|
for some polynomial $Q_{2}\left(k\right)$.
|
||
|
|
|
||
|
|
Consider an algorithm SIMNIZKP (similar to the one defined in \cite{FS}) which takes
|
||
|
|
as input scalars $a$, $c$ , a private key vector $\overline{x}$,
|
||
|
|
a set of public key-vectors $\overline{y}_{i},i=1,...,m$, an index
|
||
|
|
$\pi$, and a message $\mathfrak{m}$ and acts on these as follows:
|
||
|
|
|
||
|
|
1. Generate random scalars $s_{1},...,s_{m}$ and, a random scalar
|
||
|
|
$c_{\pi}\leftarrow H$.
|
||
|
|
|
||
|
|
2. For $j$ indexing $\overline{x}$, set
|
||
|
|
\[
|
||
|
|
L_{\pi}^{1}=aG
|
||
|
|
\]
|
||
|
|
\[
|
||
|
|
R_{\pi}^{1}=cG
|
||
|
|
\]
|
||
|
|
and for all other $j$
|
||
|
|
\[
|
||
|
|
L_{\pi}^{j}=s_{\pi}^{j}G+c_{\pi}y_{\pi}^{j}
|
||
|
|
\]
|
||
|
|
\[
|
||
|
|
R_{\pi}^{j}=s_{\pi}^{j}H\left(y_{\pi}^{j}\right)+c_{\pi}x^{j}H\left(y_{\pi}^{j}\right)
|
||
|
|
\]
|
||
|
|
|
||
|
|
3. Compute a random output from the random oracle
|
||
|
|
\[
|
||
|
|
c_{\pi+1}\leftarrow H\left(\mathfrak{m},L_{\pi}^{1},R_{\pi}^{1},...,L_{\pi}^{m},R_{\pi}^{m}\right).
|
||
|
|
\]
|
||
|
|
|
||
|
|
4. For each $i$, working mod $m$, compute
|
||
|
|
\[
|
||
|
|
L_{i}^{j}=s_{i}^{j}G+c_{i}y_{\pi}^{j}
|
||
|
|
\]
|
||
|
|
\[
|
||
|
|
R_{i}^{j}=s_{i}^{j}H\left(y_{i}^{j}\right)+c_{i}x^{j}H\left(y_{i}^{j}\right)
|
||
|
|
\]
|
||
|
|
\[
|
||
|
|
c_{i+1}\leftarrow H\left(\mathfrak{m},L_{i}^{1},R_{i}^{1},...,L_{i}^{m}+R_{i}^{m}\right).
|
||
|
|
\]
|
||
|
|
and note that at the last step when $i=\pi-1$, then $c_{i+1}$
|
||
|
|
is already determined, to maintain consistency with the random oracle
|
||
|
|
output.
|
||
|
|
|
||
|
|
Note that regardless of whether $\overline{x}$ is the actual private
|
||
|
|
key corresponding to $\overline{y},$ due to the fact that consistency
|
||
|
|
is maintained by the random oracles in subsequent calls, the above
|
||
|
|
signature verifies. If $\overline{x}$ is actually the private key-vector
|
||
|
|
of $\overline{y}$ , then there is no difference between SIMNIZKP
|
||
|
|
and an actual signature.
|
||
|
|
|
||
|
|
Finally, given a tuple $\left(G,aG,bG,c_{i}G\right)$ where $a,b$
|
||
|
|
are randomly selected scalars, with $c_{1}=ab$, $c_{0}$ a random
|
||
|
|
element, $i\in\left\{ 0,1\right\} $, $\mathcal{M}$ takes the following steps to solve the Decisional Diffie
|
||
|
|
Helman Problem with non-negligible probability.
|
||
|
|
$\mathcal{M}$ grabs
|
||
|
|
a random $\gamma\leftarrow H$ from the random oracle and takes a
|
||
|
|
private / public key-vector pair $\left(\overline{x},\overline{y}\right)$,
|
||
|
|
and then computes $s$ such that $a=s+\gamma x$. Now $\mathcal{M}$
|
||
|
|
performs SIMNIZKP with arbitrarily selected key-vectors $\left\{ \overline{y_{i}}\right\} _{i=1,...,n}$
|
||
|
|
such that $\overline{y}=\overline{y}_{\pi},$ $a\to a$, $c_{i}\to c$
|
||
|
|
some message $\mathfrak{m}$, and $\overline{x}\to\overline{x}$.
|
||
|
|
|
||
|
|
If it is the case that $i=1$, then $c=ab$, then
|
||
|
|
\[
|
||
|
|
log_{G}aG=log_{bG}cG=a
|
||
|
|
\]
|
||
|
|
and due to the fact that $\mathcal{A}$ is assumed to be able to
|
||
|
|
find $\pi$ with non-negligible probability, then there is a non-negligible
|
||
|
|
probability over $\frac{1}{2}$ that $\mathcal{A}$ returns $1$ (upon
|
||
|
|
which $\mathcal{M}$ returns $1$). If $i=0$, then $\mathcal{A}$
|
||
|
|
returns $1$ only with probability $\frac{1}{2}$, and so for some
|
||
|
|
non-negligible probability over $\frac{1}{2}$, $\mathcal{M}$ returns
|
||
|
|
the same value as $\mathcal{A}$, and thus solves the Decisional Diffie-Helman problem for randomly chosen scalars with non-negligible probability
|
||
|
|
over $\frac{1}{2}$, which is a contradiction.
|
||
|
|
\end{proof}
|
||
|
|
|
||
|
|
\section{Ring CT Demo Code}
|
||
|
|
In the repository at \cite{Snoe} I have created a simple demonstration of the Ring Confidential Transactions protocol utilizing the MLSAG signatures of section \ref{MLSAGsection} and the ASNL signatures of section \ref{AgSchnorr}:
|
||
|
|
\begin{verbatim}
|
||
|
|
H_ct = RingCT.getHForCT()
|
||
|
|
print("H", H_ct)
|
||
|
|
sr, Pr = PaperWallet.skpkGen() #receivers private/ public
|
||
|
|
se, pe, ss = ecdh.ecdhgen(Pr) #compute shared secret ss
|
||
|
|
digits = 14 #in practice it will be 14
|
||
|
|
print("inputs")
|
||
|
|
Cia, L1a, s2a, sa, ska = RingCT.genRangeProof(10000, digits)
|
||
|
|
print("outputs")
|
||
|
|
Cib, L1b, s2b, sb, skb = RingCT.genRangeProof(7000, digits)
|
||
|
|
Cic, L1c, s2c, sc, skc = RingCT.genRangeProof(3000, digits)
|
||
|
|
print("verifying range proofs of outputs")
|
||
|
|
RingCT.verRangeProof(Cib, L1b, s2b, sb)
|
||
|
|
RingCT.verRangeProof(Cic, L1c, s2c, sc)
|
||
|
|
x, P1 = PaperWallet.skpkGen()
|
||
|
|
P2 = PaperWallet.pkGen()
|
||
|
|
C2 = PaperWallet.pkGen()
|
||
|
|
#some random commitment grabbed from the blockchain
|
||
|
|
ind = 0
|
||
|
|
Ca = RingCT.sumCi(Cia)
|
||
|
|
Cb = RingCT.sumCi(Cib)
|
||
|
|
Cc = RingCT.sumCi(Cic)
|
||
|
|
sk = [x, MiniNero.sc_sub_keys(ska, MiniNero.sc_add_keys(skb, skc))]
|
||
|
|
pk = [[P1, P2], [MiniNero.subKeys(Ca, MiniNero.addKeys(Cb, Cc)), \
|
||
|
|
MiniNero.subKeys(C2, MiniNero.addKeys(Cb, Cc)) ] ]
|
||
|
|
II, cc, ssVal = MLSAG.MLSAG_Sign(pk, sk, ind)
|
||
|
|
print("Sig verified?", MLSAG.MLSAG_Ver(pk, II, cc, ssVal) )
|
||
|
|
print("Finding received amount corresponding to Cib")
|
||
|
|
RingCT.ComputeReceivedAmount(pe, sr, MiniNero.addScalars(ss, skb), Cib)
|
||
|
|
print("Finding received amount corresponding to Cic")
|
||
|
|
RingCT.ComputeReceivedAmount(pe, sr, MiniNero.addScalars(ss, skc), Cic)
|
||
|
|
|
||
|
|
\end{verbatim}
|
||
|
|
Here is an example transaction with input $10,000$ and outputs $3,000$ and $7,000$.
|
||
|
|
\begin{verbatim}
|
||
|
|
('H', '61fe7f0f5a607a33427d01dd1fded5ffa03fae2e9df9ebccf2e0a2f5bd77a204')
|
||
|
|
inputs
|
||
|
|
('b, b in binary', 10000, [0, 0, 0, 0, 1, 0, 0, 0, 1, 1, 1, 0, 0, 1])
|
||
|
|
Generating Aggregate Schnorr Non-linkable Ring Signature
|
||
|
|
outputs
|
||
|
|
('b, b in binary', 7000, [0, 0, 0, 1, 1, 0, 1, 0, 1, 1, 0, 1, 1, 0])
|
||
|
|
Generating Aggregate Schnorr Non-linkable Ring Signature
|
||
|
|
('b, b in binary', 3000, [0, 0, 0, 1, 1, 1, 0, 1, 1, 1, 0, 1, 0, 0])
|
||
|
|
Generating Aggregate Schnorr Non-linkable Ring Signature
|
||
|
|
verifying range proofs of outputs
|
||
|
|
Verifying Aggregate Schnorr Non-linkable Ring Signature
|
||
|
|
Verified
|
||
|
|
Verifying Aggregate Schnorr Non-linkable Ring Signature
|
||
|
|
Verified
|
||
|
|
('Generating MLSAG sig of dimensions ', 2, 'x ', 2)
|
||
|
|
('verifying MLSAG sig of dimensions ', 2, 'x ', 2)
|
||
|
|
('c',
|
||
|
|
['80a3cfd06dd2862307cd75c2a1566f20cd743dbb0b9feb22d79dcbecb9023f42',
|
||
|
|
'a9b7342ba7bf2f102505ca19dab734fde638916c0a29f5b30e49833ab51393ea',
|
||
|
|
'80a3cfd06dd2862307cd75c2a1566f20cd743dbb0b9feb22d79dcbecb9023f42'])
|
||
|
|
('sig verifies?', True)
|
||
|
|
('Sig verified?', True)
|
||
|
|
Finding received amount corresponding to Cib
|
||
|
|
('received ', 7000,
|
||
|
|
'a488ec68732fb551841c2c6dcc7ffac895d98ec7e9378275ed20ea12805fc18e')
|
||
|
|
Finding received amount corresponding to Cic
|
||
|
|
('received ',3000,
|
||
|
|
'1b46626858e130a0f3884c74c9fdeabc4d812c519103ea16a35a3f82a3d0ed6d')
|
||
|
|
\end{verbatim}
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
\end{document}
|