12:43:08 <moneromooo> There will be some large change in output selection "density" when we switch to triptych.
12:44:04 <moneromooo> 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.
12:44:29 <moneromooo> So this may mess up the gamma picking system.
12:49:49 <sech1> Wait, if you can't mix them then how do you send the very first triptych transaction?
12:51:36 <moneromooo> With only pre-triptych outputs :)
12:52:34 <moneromooo> I *think* you can't mix them. The reasoning I had is:
12:53:02 <moneromooo> a Triptych signature yields a differnt key image than a pre-triptych signature.
12:53:30 <moneromooo> Therefore you cannot allow spending an output with either, it has to be deterministic which one is allowed, or you could double spend.
12:54:07 <moneromooo> If you can mix pre/post in a ring, since you know which is is true true spend, you cannot enforce this.
12:54:14 <moneromooo> So you can't mix them in a ring.
12:54:58 <moneromooo> Am I wrong ?
13:05:40 <sech1> I don't know, let's wait for someone qualified
13:06:50 <moneromooo> (of course I meant since you *don't* know which is *the* true spend)
13:08:23 <moneromooo> Also, for a similar reasoning, pre-triptych rct txes would need to be allowed indefinitely.
13:08:43 <moneromooo> That is a bit unfortunate.
13:09:32 <moneromooo> But anyway, my point is that we might need to monkey with the selection algorithm.
13:28:26 <binaryFate> wasn't it the same with transition to ringct?
13:30:55 <moneromooo> The need to keep pre-rct txes, yes. The key image difference, no.
13:51:16 <dEBRUYNE> On an UI/UX level this is fairly easy to solve I guess by simply constructing two transactions
14:54:44 <sarang> It's correct that you can't "mix" outputs because of the key image change
14:55:27 <sarang> 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
14:58:12 <Inge-> if you have some old and some new, you just "churn" your old outputs into new outputs and are good to go?
15:12:34 <endor00[m]> so technically one would not be able to send a Triptych transaction until at least [Triptych ring size] outputs have been converted, right?
15:13:12 <Inge-> sounds like a catch-22?
15:13:25 <moneromooo> Yes. Same as rct.
15:14:11 <Inge-> but that would easily be solved by some volunteers making a few hundred transactions initially?
15:15:04 <moneromooo> You make it sound dangerous now :D
15:15:12 <endor00[m]> 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
15:34:07 <sech1> wait, if someone lives under the rock and tries to spend pre-triptych outputs 3 years later, it will work right?
15:35:34 <endor00[m]> it has happened with pre-ringct to ringct, so I think it should
15:41:14 <moneromooo> Yes.
16:48:10 <AnonymousUser182> I had a question about Arcturus/Triptych-- well, more about sub-linear ring signature schemes and their applications to cryptocurrency altogether.
16:48:10 <AnonymousUser182> 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?
16:48:11 <AnonymousUser182> Do we need to explicitly include references to all included outputs in the anonymity set in the transaction? Does this make it scale linearly?
16:48:11 <AnonymousUser182>  I'm probably just being dumb tbh
16:50:40 <AnonymousUser182> (to @sarang)
16:50:45 <sech1> I think we do, correct me if I'm wrong
16:51:06 <sech1> but references are 4-byte integers right now, they reference outputs by IDs
16:51:13 <AnonymousUser182> That's what I figured
16:52:01 <AnonymousUser182> 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 :/
16:52:44 <sech1> Because if we don't, even block explorer won't be able to show all 64 (or 128) ring members for a tx
16:54:15 <sarang> If binning is used, we can include references to bins instead of outputs, provided the binning is deterministic
16:54:27 <sech1> IIRC tevador created an O(1) deterministic scheme for output selection
16:54:51 <sech1> https://github.com/tevador/igamma
16:55:05 <sech1> O(1) as in transaction size usage
16:55:23 <sarang> And there's been similar work to that by one of Matt Green's students too
16:55:25 <AnonymousUser182> I got a response from Dr. Noether on reddit. Question answered, thank you everyone
16:55:27 <sarang> that required inverse transform sampling
16:55:40 <sarang> There were initially some questions about efficiency and flexibility
16:55:46 <AnonymousUser182> All useful stuff
21:19:43 <sgp_> If all goes well, this channel will be bridged to the Discord tonight. It was bridged before, but if you have concerns lmk
21:34:55 <childofthecorn[m> <sgp_ "If all goes well, this channel w"> Im concerned it will be too awesome
21:41:44 <sgp_> childofthecorn[m: valid concern, thank you! :D
23:37:50 <gingeropolous> 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.
23:37:51 <gingeropolous> 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
23:38:53 <gingeropolous> thought of some attacks / weaknesses: https://paste.debian.net/hidden/c35777e9/
23:39:08 <gingeropolous> s/useless/uselessness