MIME-Version: 1.0
Sender: gmaxwell@gmail.com
In-Reply-To: <CAAS2fgQVJU659NsX054YTTB1MCDWtSk9PXJo5+EgrBRRG+VDsw@mail.gmail.com>
References: <CAAS2fgQ0Cb2B=Ye2TnpfQqP4=kpZCxMWRXYB0CcFa71sQJaGuw@mail.gmail.com>
	<20171114091123.GA29286@savin.petertodd.org>
	<CAAS2fgQVJU659NsX054YTTB1MCDWtSk9PXJo5+EgrBRRG+VDsw@mail.gmail.com>
From: Gregory Maxwell <greg@xiph.org>
Date: Tue, 14 Nov 2017 10:51:13 +0000
Message-ID: <CAAS2fgQSyzZ_1Cf+DQ4Vrs4wUHKe7Kk93p0ixq1xXXbFY8YXGQ@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: text/plain; charset="UTF-8"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Updates on Confidential Transactions efficiency
Precedence: list

On Tue, Nov 14, 2017 at 10:38 AM, Gregory Maxwell <greg@xiph.org> wrote:
> I think it's still fair to say that ring-in and tree-in approaches
> (monero, and zcash) are fundamentally less scalable than
> CT+valueshuffle, but more private-- though given observations of Zcash

While I'm enumerating private transaction topologies there is fourth
one I'm aware of (most closely related to ring-in):

take N inputs,  write >= N outputs,  where some coins are spent and
replaced with a new output, or an encrypted dummy... and other coins
are simply reencrypted in a way that their owner can still decode.
Provide a proof that shows you did this faithfully. So this one avoids
the spent coins list by being able to malleiate the inputs.

We never previously found an efficient way to construct that one in a
plain DL setting, but it's probably possible w/ bulletproofs, at least
for some definition of efficient.