There will be some large change in output selection "density" when we switch to triptych.

Since I think you can't mix triptych and non triptych outputs in a ring, pre-triptych outputs will decrease in number as triptych outputs grow.

So this may mess up the gamma picking system.

Wait, if you can't mix them then how do you send the very first triptych transaction?

With only pre-triptych outputs :)

I *think* you can't mix them. The reasoning I had is:

a Triptych signature yields a differnt key image than a pre-triptych signature.

Therefore you cannot allow spending an output with either, it has to be deterministic which one is allowed, or you could double spend.

If you can mix pre/post in a ring, since you know which is is true true spend, you cannot enforce this.

So you can't mix them in a ring.

Am I wrong ?

I don't know, let's wait for someone qualified

(of course I meant since you *don't* know which is *the* true spend)

Also, for a similar reasoning, pre-triptych rct txes would need to be allowed indefinitely.

That is a bit unfortunate.

But anyway, my point is that we might need to monkey with the selection algorithm.

wasn't it the same with transition to ringct?

The need to keep pre-rct txes, yes. The key image difference, no.

On an UI/UX level this is fairly easy to solve I guess by simply constructing two transactions

It's correct that you can't "mix" outputs because of the key image change

You'd have a transition transaction that puts old outputs into the new pool (delineated by block height), and then can start using new-pool outputs generated after that height

if you have some old and some new, you just "churn" your old outputs into new outputs and are good to go?

so technically one would not be able to send a Triptych transaction until at least [Triptych ring size] outputs have been converted, right?

sounds like a catch-22?

Yes. Same as rct.

but that would easily be solved by some volunteers making a few hundred transactions initially?

You make it sound dangerous now :D

I don't think you'd even need "volunteers" for that, there's enough daily usage to be done with it in under an hour

wait, if someone lives under the rock and tries to spend pre-triptych outputs 3 years later, it will work right?

it has happened with pre-ringct to ringct, so I think it should

Yes.

I had a question about Arcturus/Triptych-- well, more about sub-linear ring signature schemes and their applications to cryptocurrency altogether.

I know that the proofs/signatures scale logarithmically in size with the anonymity set ((w+3)lgN+w+7 for w signing keys and N members for Arcturus). But what about transaction size?

Do we need to explicitly include references to all included outputs in the anonymity set in the transaction? Does this make it scale linearly?

I'm probably just being dumb tbh

(to @sarang)

I think we do, correct me if I'm wrong

but references are 4-byte integers right now, they reference outputs by IDs

That's what I figured

I'll still wait for a response from Dr. Noether or collaborator. Just wanna get this hammered out because I've been hung up on it for a while :/

Because if we don't, even block explorer won't be able to show all 64 (or 128) ring members for a tx

If binning is used, we can include references to bins instead of outputs, provided the binning is deterministic

IIRC tevador created an O(1) deterministic scheme for output selection

O(1) as in transaction size usage

And there's been similar work to that by one of Matt Green's students too

I got a response from Dr. Noether on reddit. Question answered, thank you everyone

that required inverse transform sampling

There were initially some questions about efficiency and flexibility

All useful stuff

If all goes well, this channel will be bridged to the Discord tonight. It was bridged before, but if you have concerns lmk

<sgp_ "If all goes well, this channel w"> Im concerned it will be too awesome

childofthecorn[m: valid concern, thank you! :D

heya, i posted this in #gui and didn't get any comments. im trying to save the remote node network from complete useless due to presence of assholes. came up with this. if someone can tell me it won't work, that'd be cool.

so i think this repeater thing will work. [W]allet connects to [RPC] node for refresh. [W] then begins to craft a TX, requires data for outputs [1-11]. Requests [1-11] from node [A]. [A] sends data to [W]. [A] sends request to node [B] for same outputs [1-11]. Node [B] sends data to [A] and requests same data from [C]. etc etc

thought of some attacks / weaknesses: paste.debian.net/hidden/c35777e9

s/useless/uselessness