Im fine with moving transaction public keys and encrypted payment IDs out of the extra field, since we already have the precedent of putting the 'encrypted amount' in the tx structure (it's currently the only non-extra piece of a tx that is unverified aside from being part of the MLSAG messages; and I wonder if the encrypted amount length is even verified hmm). It still feels important to give non-standard

'freeform' usecases some kind of expectations so there is less variability for each in-the-wild feature. Implementers are less likely to be careless if they must keep track of a precise ruleset.

dumb question: how does Monero check that value is balanced between input and output Pedersen commitments?

does it also have a notion of blinding factor excess?

please check chapter 5 and section 6.2.1 pdf-archive.com/2020/02/12/zerotomo…0-25/zerotomoneromaster-v1-0-25.pdf

thanks for the pointer

page 43 says "If P = (x, y), −P = (−x, y)". shouldn't that be (x, -y) ?

the citation is Bernstein's twisted edwards curve paper

Bernstein section 2 "The inverse of a point (x1,y1) on E is (−x1,y1). "

unless am I misunderstanding something ?

sounds like the x and y coordinate got swapped in that curve

Hence, she would be able to use this value as a commitment to zero, since she can make a signature

with the private key (xj − x

0

j

) = zj and prove there is no H component to the sum

hmm that paste came out weird

Anyway, right there is the essence of of Mimblewimble

RingCT might as well be called RingMimblewimble?!

confidential transaction started with Maxwell's paper iirc

so I imagine mimblewimble comes later

that paper lacks a date. curious to know when Greg first published on CT

well this has a date :) web.getmonero.org/resources/research-lab/pubs/MRL-0005.pdf

accessed June 1, 2015

close to June 9 date of bitcointalk.org/index.php?topic=1085273.0

in any case it was an important innovation for everyone

tromp_: you need something like a leveled homomorphic trapdoor function for non-interactive tx with cut-through on mw

you can add non-interactive tx to MW by adding a bitcoin-style pubkey to every utxo as an extra spending condition

yes, but not without changing concensus

weird; line i just typed disappeared?

oh, sorry, IRC client quirk; it appeared on small bottom section

you change consensus for recent tx; beyond the horizon you ignore the pubkeys. (it's a slightly different security model, assuming no deep reorgs)

i assume you saw the proposal by David Burkett?

adding extra spending conditions is a slippery slope and its uncertain how it affects future attempts of breaking the tx graph

yes, saw the proposal

i'm not in favor of adding it to Grin

Initial work for hash function domain separation: monero-project/monero #6338

(no changes to format, only a common location for domain separation strings/chars/etc.)

Adding extra spending conditions, if not reusing public keys, should not have any affect on tx graph

Thanks to n3ptune, I'm running some chain growth estimates for all the various tx protocols that are currently under study

The goal is to examine the I/O distribution of the actual chain, and determine what the resulting total growth would be under each proposal (since different protocols have different I/O scaling that's tricky to directly compare)

Very interesting initial results :D

(I'm doing double-checks now)

I'm looking at MLSAG, CLSAG, Triptych-1, Triptych-multi, RCT3-1, and RCT3-multi

Right now I'm excluding Omniring due to issues with batching and (possibly) some problems with the algebra

I'm also excluding Lelantus due to the issues with sender tracing and one-time addressing that have not been worked out yet

(also note: the RCT3-1 numbers include a soundness fix not in the preprint that I backported myself from their RCT3-multi update)

tromp: the original mimblewimble white paper cites Maxwell's CT ^.^

right. the interesting quote from that CT paper is "If the author of a transaction takes care in picking their blinding factors so that they add up correctly". MW follows from not taking such care and realizing that he tx can be signed with the difference.

it also takes a mental leap to have the sender and recipient interact in constructing that signature

Monero's RCTTypeFull transaction type (deprecated, as it meant all inputs were at the same ring index) took the same approach. Section 5.6.1 web.getmonero.org/library/Zero-to-Monero-1-0-0.pdf