When at least one output is to a subaddress, and all recipients aren't oneself (currently), there are multiple transaction public keys in the tx extra field. Are these keys sorted or are they associated 1:1 with their corresponding outputs (e.g. the one-time addresses)?

The latter IIRC.

Sorting would require O(N^2) ops to check.

Im just thinking about MoJoin, where sorting would be better for Janus mitigation

and normal subaddress indistinguishability, since those two kinds of transactions would be blended together

@koe working on getting answer for you from the blockchin data

not at the protocol level, just for constructing tx

sweet!

it actually doesn't need to be sorted, just randomized

@koe since bulletproofs activated at height 1686275, there have been 42157 transactions with 16-outputs, out of 2731126 total transactions

1.5%

Shoutout @n3ptune for the data & SQL troubleshooting help

1.8% of non-coinbase tx

this suggests higher max number of outputs would have minimal impact on overall verification times

thanks Isthmus :D

Ill be sure to bring it up again at the MRL meeting this wednesday; list of future developments is up to 16 (most need discussion or are things I made up)

btw it sounded like time locks would only appear in late 2020 at earliest (perhaps v14+), was there a reason they wouldn't be ready this summer (v13+)?

hidden timelocks*

Isthmus would it be possible to see the number of >=16 output tx (RingCT type only, e.g. type 2) from block 1220516 (RingCT implemented) to block 1686275 (bulletproofs added, limit of 16 outputs added)?

note that from 1220516 to 1400000 RingCT was not mandatory for new transactions afaik

fun fact, bulletproofs have been around about as many blocks as borromean range proofs were around

AIUI it was not mandatory but in reality all txs were RingCT

there's a good metric: how many tx were not ringCT during the optional period?

Hidden timelocks require CLSAG as a practical prerequisite

ah right

They work with MLSAG, but scale very poorly

is the expectation to wait one hardfork after CLSAG before adding hidden timelocks?

I don't think there is clear consensus to add hidden timelocks at this point

ok

It would also require playing nicely with existing bulletproofs, and therefore some additional engineering work there

koe> note that from 1220516 to 1400000 RingCT was not mandatory for new transactions afaik

^ technically true but ringct input forced ringct output so almost all txs were quickly ringct

ah so the metric would be 'how many post-v4 tx took non-ringct as input, and had non-ringct as output?'

Mixable non ringct. If unmixable inputs, you get non rct outputs.

Was wondering about this, why did going unmixable -> mixable not change the transaction era version? E.g. now is RingCT == 2, but clearly there are 3 eras (unmixable v1, mixable v2-v4/6, RingCT v4/6-present)

Just since the actual tx format remained the same?

unmixable doesn't have anything to do with version (besides non-rct of course)

fair enough, the history is just difficult to discern

I'm not opposed to increasing from 16 to 32 max ouputs if it can be shown to be a useful tradeoff given expected use (and the possibility of misuse for DoS)

This would also leave room for hidden timelock range proofs, if they were implemented

(each input requires a range proof for its timelock commitment)

Because rct txes do not work with ring size 1.

Or at least the code we have.

We could have made the mixin 1 to 4 do this, but meh. Corner case.

could treat them like coinbase

has it been discussed (or did I miss it in this epic scrollback) whether if we can achieve the same goal as coinjoin if we, instead, create fake outputs?

has not been discussed

e.g., every transaction (even if being sent to one real user) appears on the chain as 16 outputs

or 32, etc

if the goal is "more privacy" then maybe

but they are not the same at all

i thought it was related to the distinguishabality between different txs types

i mean, its possible to imagine a monero dystopia where your transaction won't be accepted because its a tx by itself and not part of an aggregate tx, because all the "good" members of society use Monero Bank of America (which would obviously batch transactions)

or similar third parties that have identifiable tx construction

but then again its possible to imagine pufflefrump womboots

I think the point of aggregate tx is they are indistinguishable from normal tx

aside from their sheer uncommon size

the new aggregate tx scheme being talked about?

well aggregate schemes in general

oh. i thought coinjoin works such that there are multiple outputs

oh do you mean normal 2-output tx?

yeah

sarang says "Such a construction is useful because it breaks an important heuristic: common control. Under this heuristic, an adversary can reasonably assume that in a transaction spending multiple inputs, all such inputs are controlled by a single entity. While ring signatures obscure the identity of the spent outputs, other heuristics may provide

the adversary an advantage in this determination. MoJoin trades this heuristic for a particular level of trust in a dealer, who may or may not also be a player in the transaction. Specifically, the dealer learns which subsets of input rings are linked to which subsets of outputs. However, we stress that the dealer does not learn which inputs in a

player's rings are actually spent. Therefore, the ability to link inputs is shifted from any observer (in the current transaction model) to a single entity of the player's choice."

well i guess the same question applies there as well. could we use fake inputs. 1024 inputs and 1024 outputs for everyone!

finished MoJoin chapter first draft pdf-archive.com/2020/01/27/zerotomo…rotomoneromaster-v1-0-21-mojoin.pdf

<gingeropolous> but then again its possible to imagine pufflefrump womboots <= I'm trying, but I never scored high marks in creativity

Oh you're describing your method, not mine

And stole the name!

eh is that a problem? not looking for credit

I can call it JoinMo if you want ;)

as in 'join mo tx yo!'

ok done, it's JoinMo now no takebacks!

Ring Sigs and Stealth Addresses mentioned in the final text for publication of ISO/TR 23244: Privacy and Personally Identifiable Information protection considerations

cool midipoet! thanks for letting us know!

midipoet: how can we get a copy of that draft? I can't seem to find it on the ISO website.

i don't think its public info

it's coming from the ISO TC 307-JWG4

i only got access to it recently, so am still trying to figure out what the fuck is going on

the joys

heh koe I was just joking

sarang: time off on linkability was a good idea

so here's the current state of my thoughts

assume our current definition of unforgeability

sure

due to our structure of the unforgeability definition, unforgeability is a property which implies Backes' linkability

so I started thinking about what we really want out of a linkability definition

(you know all this but I'm bringing the audience up to speed so to speak)

(well not all)

so, these ring signatures can be seen as ZK arguments of knowledge of discrete logarithms, and ZK proofs usually have two properties of interest, correctness and soundness

(and zk)

yeah, other than the zk part

soundness is the analog of unforgeability, but soundness, strictly speaking, means that if an algorithm A can produce valid proofs, then an algorithm E can extract the witness

so, we were struggling with linkability, in part, for a few reasons. you may recall my thinking of some condition to capture linkability like like Link(Sign(m, R, x), Sign(m', R', x)) = 1 for any messages m and m' and any rings R and R' such that the public key for x is in their intersection

you pointed out that we can't assume valid signatures come from Sign, which led us down the rabbit hole of unforgeability

and recall that the Link condition in Backes' is comparing against some signing oracle generated signature

Right, and in particular the original LSAG work assumed for linkability and unframeability that we're looking at valid signature from Sign

Not for Backes

Backes just assumes you output a claimed signature

right, my bad

but the earlier work assumes valid sigs from the oracle

now, late last week, I wrote a proof that the key image for a valid ring signature must, except with negl probability, correspond to a ring member, and since our definition of unforgeability demands it, this means that a valid signature (assuming signatures are unforgeable) will either be honestly generated or will come equipped with a key image that corresponds to a ring member known by the signer

right

now, the trouble was asking ourselves whether the key image corresponded to the "right" signer

but both of us sort of scratched our heads about how to deal with formalizing the signer; one thing I was concerned about was demonstrating that you can't publish a key image for one linking key but open the commitments for some other key

the solution is in the extractor that must exist if soundness/unforgeability holds

that is: since valid signatures definitely produce good key images corresponding to a ring member (assuming the signature scheme is unforgeable), the rest of linkability ensures that you can't extract a witness that is not consistent with the key image!

does this make sense?

i'm still trying to formalize both the statement and the proof

but this is basically what linkability in linkable ring signatures is: if link(sig1, sig2) = 1, then the witnesses extracted from each signature have to be mutually consistent

What does "mutually consistent" mean in this case?

you cant' extract two distinct witnesses if link = 1

i think

but it's delicate, and that's the remainder of the work i have on this definition

:P

bonus points, though: our definition of unforgeability demonstrates that basically every definition of linkability so far is useless * although i really want to caveat this to say it'd be impossible for me, a single person, to read every linkable ring signature paper that's ever been published and check

but we knew that last week

Well, the definitions that assume honest signatures are not very practical

Backes is interesting but also covers only the case where you can produce "too many" valid non-linking signatures

However, it does away with the honest-signature requirement

It's a really tricky thing to manage

backes' is actually fine for cryptocurrency if each key = 1 atomic unit of money and to send 100,000 units, you need to construct a batch signature from 100,000 signatuers.

However, what's useful is that our current construction is _at least_ as good as that used for LSAG/MLSAG, and I argue a bit better because of Backes

but if keys are not equivalently valued, then backes' definition allows someone to pull a switcheroo that is unacceptable for double spend protectin

(note: this means the proof would not catch this, not that it's practically possible with the construction)

So it sounds like what you want to do is assert that two claimed signatures with identical key images must yield the same extracted secret key

well, we can only claim they have the same extracted aggregate secret key

i... made a diagram

hey kid

wanna...

wanna see a diagram?

Sure, but claiming the same extracted aggregate secret key is fine

since that implies knowledge of the underlying constituent keys with high probability

the proof isn't completed yet, but this is the basic idea, yeah

SK = secret key space, PK = public key space, KI = key image space, A*K = aggregated * key space

ya

I think we'll be able to use the fact that mu depends on I

We can force mu to depend on the individual round indices (we don't right now)

it's a computation cost, but not too bad given the ring sizes

It's a trivial change in the code

But that may not be necessary, since the unforge proof rewinds already use the round indexing

(it'd be nice to avoid it, to speed up the operations)

what do you mean round indices?

I mean that for each public key set input into the hash to obtain challenges, the aggregation coefficient `mu` can be indexed

We originally looked into this as an option

ohhhh i see what you mean

Yeah, very early on, we looked at two constructions: one with fixed mu, and one with indexed mu

Current proofs work with a fixed mu, which is good for efficiency

I couldn't find the timing differences in the C++ implementation, so I'm running them again now for fun

but if indexed mu is helpful for this extraction (versus using only the indices you get from the rewinding process), we could use it

Is koe here?

yo

The part of your MoJoin construction surrounding range proofs is a bit unclear

Yes since idk about bulletproofs yet

based on your doc it will take extra rounds

The way it works is that each output to be aggregated into the range proof is indexed

Each player generates the first round partial proof and send the partial proof elements to other players (or to a dealer)

They all generate an aggregate challenge and send it to each other

Then they use the challenge to generate the second round partial proofs and distribute those

Generate another set of aggregate challenges, distribute those

and finally perform the last part of the proof (which can then be compressed using the logarithmic inner product technique by any player)

It's a necessarily multi-round interactive process that isn't as simple as generating individual range proofs and then smushing them together

You don't strictly need a dealer, but do need a way to index the outputs and get partial proofs and challenges back and forth

Ok ill put together the most efficient way to do that

In my writeup, you could remove the dealer but still need the bulletproof stages to be present

thanks :)

I wonder if the BP rounds could be done simultaneously with other rounds safely

The challenges include the output commitments themselves, so those need to be communicated along with the first partial proof elements

since you can generate a new transaction public key for each attempted MoJoin, there is no risk to sending output commitments early on, so it should be able to do range proofs with only 1 or 2 extra rounds

And only player needs to do the final inner product compression (there's no secret data at that point)

*only one player

It's possible, but more complex, to have players do it themselves individually

if you already have a communication channel and want to minimize complexity, having a designated player do it is far easier

"It's possible, but more complex, to have players do it themselves individually" is it not deterministic?

It is, but means there's way more communication

And for this use case there's really no need to do it that way

yeah pretty low risk

No, zero risk

The designated player can't extract any information from the non-compressed data

since all players must be actively communicating anyway, if the designated player disconnects then the whole thing is borked anyway

The "downside" is the players communicate more data, but since that isn't stored on chain, it's not really relevant

the designated player would probably act as the indexer anyway

The indices determine where in the aggregated proof each output "lives" (in terms of particular exponent choices when computing the partial proofs)

nah just index based on lexicographic sorting of public keys (interpret as integers), and lowest index is automagically the designated player

Sure, it can be done however you want

There's no way to do it maliciously (the resulting proof simply wouldn't verify, and players would catch this)

how does the normal implementation choose indices? is there a risk of leaking the prover's nature via index selection?

You mean with the current single-player aggregation?

yeah

I'm not sure if it's lexicographical or based on some other on-chain appearance ordering

the proving system doesn't care, FWIW

are verifiers aware of the indices?

They're aware of the ordering of commitments into the verification routine, yes

which corresponds to indexing

ok so that needs to match between all implementations to avoid fingerprinting

Yes, it should

Aside from sorting, there isn't a good reason not to use lexicographic

It might already be done this way; I don't recall

sorted or random are both good

Sorted is nice because it's globally deterministic

Here's a simple example of the partial proof and aggregation methods: github.com/SarangNoether/skunkworks/tree/pybullet-mpc/pybullet

It shows how the final inner product compression works with the partial proof rounds

and how the aggregate challenges are formed (it's via simple addition, necessarily)

but this particular test doesn't assume any particular ordering (it'd be offloaded to the tx protocol)

ok I see these test cases

Hopefully it's clear how the dealer could be replaced by many-to-many communication

(in this example, the test suite is the dealer, who is not necessarily a player)

But notably, the trust in the dealer also arises because unless all players receive all partial proof shares, they can't independently verify the F-S challenges provided by the dealer

This technically breaks SHVZK, but still retains witness indistinguishability even if the dealer attempts to generate a malicious challenge

Or rather, it doesn't break SHVZK, but means it can't strictly apply anymore

so long as the dealer can't extract the committed amounts

they can't

but it's an irritating technicality

And again, this doesn't come up at all if every partial proof element is many-to-many communicated and each player builds the challenges themselves

Having read the original MoJoin idea from that markdown, did you come across any particular issues with it, aside from the dealer learning the input-output mapping?

(that mapping leak is obviously not ideal)

^ koe

iirc there are some transaction details missing

for example fees

cant make output commitments without knowing fees

Yes, that wasn't addressed

but is easy to include

also your construction seems to assume output commitment masks will be encoded and put in tx-extra like they used to be; now they are a hash of the shared secret

thats why I was using the pseudo output commitment

Yeah, I specifically assumed separate tx keys per output

Since there had been discussion about whether that would be worth it (beyond MoJoin specifically)

oh maybe I misunderstood; the output index is just for the hash like normally

I think one particular meta-issue to address (which in part is why MoJoin never really took off after the first informal write-up) was what should be considered the maximum communication complexity that should be reasonably considered

At some point, a particular join protocol could be so complex as to be almost unusable unless fully automated in near-real-time

MLSAG can only be signed after bulletproof is complete, since the message includes the bulletproof

well all join protocols should be automated, since what kind of UX is manual joining?

goes for multisig as well

For sure, but it's a design consideration

rather than verifying the masks are zero, dave just needs to verify amounts balance

If some tool requires you to paste in stuff from other channels for every round, it's unworkable :)

yes for sure

If you can work on the assumption that communication is fully automated and interactive in near-real-time, then design choices like removing the BP dealer go away

Dave needs to send each player all the MLSAG ring offset lists, and the key images, since MLSAG signs those as well

Replace it by global ordering and per-player challenge computation, and bam, you get full SHVZK etc.

basically everything in a tx except the MLSAG itself is signed by the MLSAG, so each player must learn everything

I see what you mean about complexity, since the dealer reduces how much work it is to implement

Let's play around with this for a second... suppose the bulletproofs themselves are removed entirely from the signature; what happens then

you get what I sent you

or the draft*

No, I mean from a security perspective, considering two versions of MLSAG signing

one that includes the proofs, and the other that doesn't

They aren't part of the MLSAG public statement

oh ok

This is just a thought experiment

can you tamper with a bulletproof such that it still verifies? that's the real question I think

It does mean that pruning them removes the ability to verify signatures, of course

No

Not without knowledge of the commitment data, and even then not in a way that breaks soundness

and correctness

if they are not signed, then pruning them will not affect signature verification ^

exactly, that's what I meant

The only things that _must_ be included in MLSAG hash messages are those elements that are part of the MLSAG public statement

of which the range proof is obviously not

you can prune bulletproofs anyway, since the message is m = H(H(tx pref ix), H(ss), H(range proofs))

what do you mean by public statement?

A minor misuse of language... in the language of protocols using challenges, proof statements (for which you want to prove knowledge of a corresponding secret witness) must be included as inputs to challenge generation

to avoid the prover substituting a new part of the statement without affecting the challenge

Roughly speaking, if it's not a secret and it goes into the proof, it should go into the challenge hash

ah ok, we do use key prefixing

If you're picky, you also should include public parameters like fixed generators... but if those are already globally fixed and unchangeable, you can in practice get away with not including them

(e.g. generator G, BP generators, etc.)

Yeah, and auxiliary non-proof data (like a range proof) can be safely excluded (but maybe you need it for some higher-level protocol)

btw I have a citation and note that says 'recent research suggests key prefixing isn't necessary'; should I remove this? "Optimal security proofs for signatures from identification schemes" is the paper cited

Let me find the source on that

I think it's safe to note "isn't necessary when considering standard Schnorr signatures"

I would not be comfortable removing prefixing

and it would be tough to justify

would be even safer to say "may not be necessary" since the context is important there

FWIW the standards all still require prefixing

This issue in fact arose with another project that was working on large anon sets and was concerned about the efficiency of large prefixes

A way around that (if you use fixed sets) is to cache a hash of them in some global ordering and then prefix the single hash

I assume that Monero would do this if switching protocols someday

ok :)

anyway, sidetrack lol

I suppose that's a bit of a sidetrack

heh yep

It just popped into my head since it's a practical concern

from what Im aware, most of the MLSAG message is there to prevent tampering; my guess is it's 'all the data' since that is most straightforward, and there is no obvious reason to exclude some

Any public data used by the verifier

and any identifying data from another higher-level protocol if there's a need to tie the signature to something else

also the tx_extra

Right, that's what I mean

ah

The whole public-parameter F-S thing assumes the protocol is used on its own

You typically pass in other data if you embed it elsewhere

right

Anyway, I'm glad you've taken up the MoJoin stuff since it didn't go anywhere

It was certainly deprioritized for other research (and hence very incomplete)

it's pretty interesting, especially since it can leverage LSAG and SAG

and there aren't many other options for the horrible heuristics around miners, pools, exchanges, and so on

I could see any implementation leading to misunderstanding about the nature of "mixing" in Monero (which already exists)

I wonder if SAG is used in the wild anywhere else

(the misunderstanding exists, not mixing...)

i put on my list to deprecate the word 'mixing' :p

There are some 1-of-many proofs used elsewhere

Groth built a Zerocoin implementation out of it that Zcoin uses

it's not the Liu style construction, though

but rather the one used by Lelantus and Triptych

One meta-issue that came to mind was to consider the case that any join construction simply isn't used in practice due to incentives around ease of use

since it's opt-in and necessarily has some level of interaction (several rounds of it...)

An incentive could be fees. Smaller tx, good batching, so fees could be made to be cheaper for those.

Or dearer for others :)

You mean by their construction, right? Not because the network could identify them, of course

(that would ruin the purpose)

They have loads of inputs and outputs.

yes

I expect initial versions wouldn't have much use since it takes a while to build up fully automated versions

Right, but I think it's an important design consideration not to base system-wide privacy on an assumption about an opt-in solution

First the basic capability, then semi-automated, then fully automated

(plenty of examples where that's a bad idea)

I see what you mean, and agree that join solution should only supplement, and research should continue into improving the situation at a protocol level

Yeah

If there are better ways to address pools, exchanges, etc. than currently exist, and can be handled at the protocol level, that's probably a better place to devote attention initially

But I'm glad there's still interest in the other stuff (like MoJoin) too

and improvements to it (the dealer requirement was always considered suboptimal)

it would really help to know just how bad the heuristics are as a function of ring size, so it's great suraeNoether is working on this

for sure

At least to address the types of heuristics we can conceive of

What's the Schneier line? Attacks never get worse; they only get better

(from the adversarial perspective!)

based on what you told me regarding aggregate proofs, players need to send 5 messages (with one additional message from the compressing member): partial proof A, aggregate challenge component A, partial proof B, aggregate challenge component B, proof completion C. Is that accurate, or are the aggregate challenges things they may compute privately?

If all players receive each others' partial proofs, they can use the collection to compute the challenges

Otherwise this is done by the dealer if there is one

There would also need to be an initial message step to determine the indices each player will use

right, so then just 3 messages prior to compression in the n-way channel protocol

Yep, A-proofs, B-proofs, C-proofs

and then the designated player can do the compression

(as can any player who has the same information)

There's no particular reason other players need to do the compression to test anything, once the challenge phases are done

Either the compressed final proof will verify, or it won't

Any successful attempt to game the compression would be either a failed verification or a break in the security model

ok to reiterate one last time, is the compression something that MUST be communicated to other players? i.e. it's not something they may compute privately and never send a message about?

or if it is something that can be computed privately, is it with prerequisite of more additional prior information (random scalars?)

I don't follow

The final proof consists of aggregated versions of the A-, B-, C-proofs, some of which are compressed via the inner product method

Im trying to minimize how much information gets sent to the channel, so if things can be done privately then they should be

Once the compression happens, that produces the final proof

If players need to use that proof in some kind of signature, they'd need to have it

But it's a valid proof on its own

No secret data is used to compress

What it does mean is that the C-proofs could be sent only to the compressing player

Is that what you meant?

Because the only reason all players need partial proofs is to compute aggregate challenges

Im a bit confused on the necessity for a compressing player, which seems to imply they are doing something the other players cant do without additional communication

I'll give some background on the compression that might help

It's possible to do a non-compressed Bulletproof with the same security properties

the size scaling is linear and therefore poor

But you can take some of the proof and apply a particular kind of inner product compression... what's clever about it is that the compression doesn't use secret data

Since we require the compressed bulletproofs (for the size scaling), some entity with access to the uncompressed version must do this before using the proof in a transaction

If you already have a single player putting the transaction together (in an untrusted way) for submission to the chain, this player might as well do the bulletproof compression

This turns a many-to-many round (of the C-proofs) into a many-to-one round (to the desig. player)

ah ok, in my version all players are constructing the transaction in parallel, which is even less trust than assuming some individual will properly submit it; since the channel is n-way it's always a many-to-one communication for each round (all n players can decrypt the same data using the n-way shared secret)

OK, in that case they can do many-to-many C-proof communication, and each do the compression

it's deterministic

great! means only 5 total rounds are necessary once the channel is set up

This doesn't assume any challenge communication, right? Just to be clear

Players locally compute challenges once they get all partial proofs for a round

and those are of course deterministic since they're F-S hashes

right

roger

and the commitments themselves need to be communicated at some point before or with the A-proof, of course

as part of the public statement, they're included in the first challenge computation

yeah the messages all seem random but it fits together sort of nicely

Heh, as long as all the data get to the right place in the right order...

It's kinda fun to build efficient round communication like that, trying to piece things together

a cool problem

whew n-channel is done, on to dealer section!

neat

Let me know when done; I'm excited to read it

suraeNoether: FWIW the difference in CLSAG 11-ring verification between a fixed `mu` and indexed `mu` (median timings) is 463 us

that's about a 5% increase overall

(2.1 GHz Opteron test machine)

I don't think we will need it

Good; I didn't either!

But was curious nonetheless :D

koe: on page 29 you say "addresses are sent money", which I'm not a fan of

You do clarify about addresses vs outputs

But I wonder if a better way is to say addresses are used to derive one-time addresses associated to outputs

it's a concept progression

since readers start out with a more physical understanding

fair enough

As long as they don't think that addresses are the things that appear on-chain (it's a key difference from other assets as you know)

Also, the whole document could have a single "except with negligible probability" footnote =p

not sure putting it on page 29 is particularly useful compared to elsewhere

true lol, suraeNoether made some comments on the first version about making sure everything was negligible probability 8)

Not a fan of the line talking about notes are like saying "Address C now owns 5.3 XMR"

I think that introduction muddies the waters about the relationship between addresses and outputs

even for beginners

The one-way relationship between addresses and outputs is a key (pun intended) component of recipient ambiguity

I think it's important to frame cryptocurrency in the language of ownership, since that directly parallels how physical money works

the technological aspect merely underpins that narrative

rather than takes the center stage

Right, and I like you mention the idea of spend authority

I think that's the way to look at Monero's address-output relationship

Knowledge of private address information yields spend authority for the outputs generated from those addresses

Perhaps a diagram showing the relationship between public address info, private address info, output one-time address, and spend authority

?

the problem is you have to start the story without knowledge of what addresses literally are

or at least that's how I went about it

hmm

by the end of section 4.2 the meaning is fully developed

Is there a good real-world analogy?

(to the address-output idea, I mean)

sure, like a safe deposit box

whoever has the key can open it

I could just say the 'address-holder' owns the output, rather than the address itself owning them

and 'the holder of address C may now spend 5.3 XMR'

FWIW I don't know a great way to explain this using simple analogies... and you can of course explain however you like

but I like thinking that the address itself owns outputs, and whoever has the key is just accessing that spend-right

Or maybe even finding some way to state that the intent of the note is to say "address C controls 5.3 XMR" while not publicly listing C or 5.3

and then explaining, as you do, how the hiding works

well the essential message of a transaction is explicitly address C and 5.3 XMR, while the cryptographic techniques hide this information from certain kinds of observers

Yeah, you can link from the original idea of note to saying that the goal of the protocol is to obscure the address and the amount... that's building from the existing Bitcoin-like structure to the Monero-like structure

Right, so perhaps being clear at the start that the Monero protocol goal is specifically to hide these things, making notes more indistinguishable

Otherwise the wording sort of makes it sound like plaintext notes is how Monero works

and I think it's best to dispel that notion right away

well that concept is introduced in the abstract and first chapter, so readers will already know what they are aiming at

the final paragraph of pg29 ties in with that previous concept

it's fine if readers go 'wait a minute, what about amount hiding' and then 'ah here we go'