Gregory Maxwell [ARCHIVE] on Nostr: 📅 Original date posted:2017-11-14 📝 Original message:On Tue, Nov 14, 2017 at ...
📅 Original date posted:2017-11-14
📝 Original message:On Tue, Nov 14, 2017 at 10:38 AM, Gregory Maxwell <greg at 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.
📝 Original message:On Tue, Nov 14, 2017 at 10:38 AM, Gregory Maxwell <greg at 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.