[Cryptography] cryptography Digest, Vol 93, Issue 1

[John Tromp]

> > Ring signatures take up more space, and worse, require full nodes to
> > maintain some data of all past outputs, which negatively affects
> > scalability.
>
> A Monero transaction takes a lot less space than all of the coinjoins and other
> nonsense that would be required to give even a fraction of privacy to a Bitcoin
> user.

I'm comparing Monero tx with plain, non-private Bitcoin txs. We agree
that Monero pays a large size price for its hiding of the sender among
decoys.

> These days the average Monero transaction (2in/2out) is about 4x larger than
> the average Bitcoin transaction. The total volume is nowhere near the
> limits of current network bandwidth or storage capabilities, so the 4x
> difference is moot. In Big-O terms, both chains are equal here.

Constants matter. A 4 day IBD (initial block download) is way worse
than a 1 day IBD.
Compared with Mimblewimble, a Monero tx is nearly 30x larger than a MW
one with spent outputs.

> The requirement to store all outputs has already been mitigated by the use
> of pruning; individual nodes can get away with storing only 1/8th of the
> total output set. As the chain grows in the future this fraction can be
> reduced even further.

You can never prune outputs completely because you never know when an
output is spent.
You keep some data, similar to Zcash' nullifiers, that allow you to
detect double spending.
So there's some fraction that can never be reduced. Worse yet, this
data must always remain on-hand, and randomly accessible when
verifying new txs.

> This point of auditability
> keeps being brought up but it doesn't hold water. In either case it comes down
> to getting the math right, not whether the inputs are transparent or not.

If someone, somehow, finds the discrete log of generator H, then
Monero suffers undetectable inflation. Bitcoin would be unaffected.

If ECDLP breaks, and finding discrete logs over elliptic curves is
computationally feasible,
then one can spend any bitcoin output with known public key (of which
there are tons), but this will be likely be detected.

Unlike Bitcoin, Monero also relies on having gotten the
Bulletproof{,+} math right. And to have no implementation bugs in
there. Any slip up here will again cause undetected inflation.

So overall, transparent amounts give a lot more confidence in the
supply being as intended.

> > Monero has a history of different PoWs that were each supposed to
> > prevent ASICs for many years.

My apologies for this falsehood; this only applies to the original
Cryptonight and to RandomX.
I should have known that the Cryptonight tweaks were only supposed to
prevent ASICs for 6 months. But I believe that not all tweaks were
successful at this.

> > There is also a significant downside to these PoWs. First, they are
> > very complex. With RandomX the biggest offender by far. Second, they
> > are very costly to verify, requiring lots of memory and cycles,
> > whereas a good PoW is very easy to verify.
> >
> > So again this choice of ASIC resistance is a trade-off at best.
>
> RandomX was tuned to take no longer to verify than CryptoNight, so you're way
> off base here.

I never claimed it did. I only claimed that all of Monero's PoWs are
very costly to verify.

> Disinfo. MinbleWimble only delivers privacy if nobody chooses to operate an
> archival node. - but anyone can do so, and unwind all transaction history.

Did you look at the chart? It shows exactly what privacy MW provides.
No amounts and no addresses. The input-output links (i.e. transaction
graph) are almost entirely visible in the mempool (nothing to do with
archival nodes, which just store all blocks). Btw, it's easy to add
decoys to MW transactions as well, as BEAM has done, with no lasting
impact on IBD size.

> Speaking of tradeoffs - what good is a system that requires sender and
> receiver to both be online simultaneously. You need only look at email to
> understand the value of sender and recipient operating asynchronously.

I fully understand the value of email. Which is exactly how Mimblewimble works,
by asynchronous exchange of transaction slates.

regards,
-John