sarang: new paper title is "Non-slanderability is unforgeability for linkable ring signatures."

*grumbles*

freaking equivalency

Ready for a read?

sarang: just shared it with you on overleaf; it's a frankenstein copypasta at this point, but there are probably around 12 pages of solid narrative that i thinkyoiu should read

that was ... a long day

i'm logging off for now

i have doctor's appointments again in the afternoon tomorrow so i'll only be on in the morning

There are probably all sorts of variations in spend times. Time of day, seasonal, market conditions, etc.

btw i'm late to the party on sarang's janus mitigation idea: just read it and it's very elegant and nice saving vs the older schnorr proof idea. fyi minor typo where you wrote b_j = H(a,j)*G + b instead of b_j = H(a,j) + b

ooh actually how about this

for a couple years, people have observed that there was a shared secret between sender and receiver (when a subaddress is involved) calculated as rG == txpubkey * d^-1

(where txpubkey is called R)

first observation: this shared secret can be preserved as a secret by instead of publishing R'==rG, publishing H(R') and checking if H(R') == H(Rd^-1)

second observation: save 16 bytes by publishing only the first 16 bytes of the hash, which I think should be more than enough

so the janus check would be lower_16_bytes(H(R')) == lower_16_bytes(H(Rd^-1))

where d is b_j in your notation.

where where H in this case would be keccak256 and not Hs

so in your notation, for each txpubkey R, publish janus proof j = lower_16_bytes(keccak256(r*G)), then janus proof verification is j == lower_16_bytes(H(R*b_j^-1))

maybe i shouldn't have used the symbol j for the janus proof :)

for a couple years, people have observed that there was a shared secret between sender and receiver (when a subaddress is involved) calculated as rG == txpubkey * d^-1 <-- not sure I understand this, subaddresses have never used d^-1 afaik

UkoeHB_ maybe i didn't state the point clearly. When funds are sent to a subaddress, the txpubkey rB_i is published, and since rB_i==r*b_i*G, the recipient can calculate (b_i^-1)*txpubkey to get R'==rG

and R' is thus a shared secret between the sender and receiver

ah

that's actually a really interesting point, a way to recover the other person's pub key from a shared secret if it's forgotten (or in this case unknown)

could that be useful?

🤔

it's an interesting shared secret, because it's a shared secret between the sender and the full-wallet owner, but not known to a view-only wallet holder (since b_j needs to be known, which requires knowledge of the wallet private spend key b)

ah i see i see it might work

oh doh. i just realized the implication that sarang's scheme will not allow a view-only wallet to avoid a janus attack

it only helps full-wallet holders

saving 16 bytes is nice though

although this method does not harmonize well with any kind of join protocol

well both sarang's scheme and my modification of it both fail to work for view-only wallets

yes, view only is not possible afaik

without more bytes

right yeah, the 48-byte half-hash schnorr proof

can you write it up and add a comment to the repo issue? :)

sure

did you mean the 16-byte variation, or the thing about it only working for full wallets?

16-byte variation

cool ok, i might as well write up both

UkoeHB_ oh i only just read your comment underneath in the github issue, looks like you reduced the overhead to 32 bytes per transaction instead of 32 bytes per txpubkey?

and and i see you already commented about the view-only thing

yes it's been through some iterations, sarang always finds a way to break my ideas but I come back strong :p

haha

in my opinion, there isn't much point addressing the janus attack if it only works for full wallets

because the automated "i received your tx!" reply is going to come from view-only wallets in so many instances

it doesn't feel right to me, to not address it

users who may be vulnerable will never be able to detect the attack, creating a fundamental uncertainty about the currency's robustness

i'm saying we should address it, but in a way that fixes it for view-only wallets too

UkoeHB_ i'm confused about your variant on the scheme: if r_i := r + H(R,i), and if R is published, then r_i is now public for the whole world, which is a showstopper, surely?

nope, since r is unknown

ohhh right, i see :)

the basic problem is any shared secret between a subaddress and a tx author must necessarily depend on the spend key, so even if you communicate the tx private key to the recipient using another shared secret, the recipient still needs his spend key to validate THAT shared secret was for the right spend key

anything involving the view key gives the game away

"the basic problem is any shared secret between a subaddress and a tx author must necessarily depend on the spend key" -> i'm not sure if you were overly narrow in that statement because of its context, or if i'm missing something

because of course there is the shared secret r*A_i

which the view-only wallet uses for scanning

since the tx author doesn't know the true view key, as subaddress view pub key is (true view)*(subaddy spend)*G

right yeah i see what you mean

i'm confused in the github thread too, not sure if you made a typo there when you say: checks that the equality b_i*(R + H(R,i)*G) - R_i == 0 holds

that implies b_i*(R + H(R,i)*G) == R_i

you could make the subaddress have 3 components, and somehow leverage that to preventing Janus; I havn't thought abt it

but it doesn't

i mean that equality doesn't hold

b_i*(R + H(R,i)*G) == b_i*R_i though, if that's what you meant

i think you must have meant that

R_i is the tx pub key for our subaddress at output index i, and R is the base pub key

R_i = b_i*(r + H(R,i))*G, and R = r*G

oh sorry yes i see

i'm getting algrebra blindness here

anyway, so the 16 byte saving would be to check lower_16(keccak256(b_i*(R + H(R,i)*G))) == lower_16(keccak256(R_i)) right?

and to publish lower_16(keccak256(R_i)) instead of publishing R_i

no need to include my indexing dealio

publish tx pub key R_i, and H(R'_i) where R'_i = r_i*G, and R_i = r_i*A_i

heh ok i think i'm falling asleep, i'd better revisit this when my brain starts working again... or feel free to fill in the comment on my behalf, if you feel like it :)

Ill let you explain your idea :p

heh ok cool, i'll comment when my brain is reset

:) im heading to bed soon aswell, but Ill leave an extra comment for sarang's morning; put some thought toward high ringsize decoy selection; what follows is instinctual concepts not backed by hard reasoning

double layer binning: generate initial set of ring members for a ring (use standard gamma distribution or whatever is base distribution, equal in size to square root of ringsize), for each of those ring members generate a wide bin (width scales with generator age, number of wide bin members is sqrt(sqrt(ringsize))), for each of those wide bin members generate a tight bin (~1 block width, number of tight bin

members is sqrt(sqrt(ringsize))). For 128 ring size, there are 11 wide bins with 3 tight bins each containing 3 or 4 members.

it also might be fun to: randomly mix up the decoys between all the rings, and make some proportion of ring members be duplicated in other rings of the same tx

of course, these concepts may give moneromooo nightmares :)

UkoeHB_ a few lines above, when you wrote "and R_i = r_i*A_i", did you mean to write R_i = R_i*B where B is from a subaddress?

ah yes

cool ok thanks

and yeah i meant to say r_i*B there of course

hmm maybe i'm just not lucid, but i'm not sure if my 16-byte saving works at all with your proposed variant, UkoeHB_

i think it only helps when used with sarang's original scheme

Ah I think I see what you mean

Since all outputs need a unique tx private key in case of multiple outs to the same address

oh good point, i didn't think about that bit

i don't think it affects things when all of the ||i bits are added in

knaccc: the non-Schnorr Janus mitigation was UkoeHB_'s idea, not mine :)

sarang ah thanks for letting me know

I just wrote it up with some sample code etc.

good morning everyone

sarang: the overleaf doc i shared with you last night - it's still just a draft. the proofs are copied from the previous draft, etc; what i need your feedback on is the narrative on security definitions before i go fine-toothed through the proofs (most of them still hold)

also, i must have missed sarang's new janus mitigation idea

er... koe's

UkoeHB_ and knaccc: if r_i := r + H(R,i) is published and if R is published anyone can compute r easily with subtraction. am I missing something? nothing's secret there if all of it is revealed.

3rd day in a row feeling good

so far that's my record for 2020. :(

but also :D

suraeNoether: will review that overleaf doc

when i described it as a frankenstein last night, i'm not kidding

Finishing up a quick tx proof unit test first

feel free to take a machete to it

awesome, i'm working on fixing my last matching unit test

r is unknown

As is r_i

oh i thought r_i was a public piece of info; nevermind

<cankerwort> The one big bad bug or a lowly unrelated bug?

WIP... updated transaction proofs: github.com/SarangNoether/monero/tree/txproof

tests are still incomplete

Replaces {In,Out}ProofV1 with {In,Out}ProofV2, with better Schnorr challenges

and, by extension, replaces ReserveProofV1 with ReserveProofV2

A question: should attempts to verify V1 proofs succeed (as they do with this code), or should they produce an error?

Right now, it will only produce V2 proofs, but verification is backwards-compatible (needs a test for this)