00:43:32 <UkoeHB> I thought we got these messages because you are a rude self-important man-child.
06:29:52 <sxhkskit> twitter.com/hyc_symas/status/1203709575226183683
06:29:52 <sxhkskit> Last time I got an award like that was in a primary school football team. It had three stars too and said that I'm special :')
06:29:52 <sxhkskit> I just binned it though instead of showing it off to naive groupies. What kind of preson takes a group achievement award and presents it as a proof of their individual prowess anyway?
12:07:28 <DisBotXMR> <Angad Mutha> Are there any CCS proposals for researching into reducing transaction confirmation time?
12:14:17 <moneromooo> Not to my knowledge.
12:23:16 <dEBRUYNE> Angad Mutha: Might be interesting to have some formal research on this -> https://old.reddit.com/r/Monero/comments/m2qcw7/work_in_progress_triptych_code_integration/gqmoft0/?context=3
12:25:29 <sech1> I couldn't find reorgs deeper than 4 blocks in my node's logs and my node is running 24/7 since 2018
12:25:45 <sech1> so maybe 5 block limit is still safe?
12:26:48 <dEBRUYNE> I've seen longer reorgs in the past, fwiw
12:28:26 <sech1> yeah, I found one alternative blockchain size: 9 on 1580196 (2018-05-27)
12:29:06 <sech1> and two more big reorgs (6 and 7 blocks) in June 2018, but after that everything is smooth
12:29:32 <moneromooo> Oh. I had an idea. So it's probably stupid:
12:29:54 <dEBRUYNE> I think in the past it has been discussed to replace the reference to the global index with something else
12:29:59 <dEBRUYNE> Pubkeys maybe? Does anyone remember?
12:30:05 <moneromooo> Allow txes to use any recent output, *but* unlock them based on the most recent input.
12:30:12 <moneromooo> Yes.
12:30:20 <sech1> it'll increase TX size
12:30:36 <moneromooo> Yes, but you can swap for their index when storing.
12:30:46 <sech1> that'll work
12:31:02 <moneromooo> You do get more steady state traffic though, granted.
12:31:58 <dEBRUYNE> <sech1> it'll increase TX size <= Any idea by how much?
12:32:10 <sech1> index is 4 bytes, pubkey is what, 32 bytes?
12:32:14 <dEBRUYNE> The 'ten block lock time' is a common complaint and storage is fairly cheap
12:32:17 <moneromooo> 30 bytes per input. So... 30 * 2 * 11 typically.
12:32:19 <sech1> multiply it by the ring size
12:32:50 <dEBRUYNE> Hmm
12:32:55 <dEBRUYNE> How does it affect verification time?
12:32:56 <moneromooo> Index at 4 seems high. But maybe 2 is low.
12:33:08 <sech1> quite noticeable, but if it's stored as index it's not a problem
12:33:15 <moneromooo> Mostly irrelevant I expect.
12:33:52 <dEBRUYNE> For protocols such as Triptych this will add quite a lot of size
12:33:56 <sech1> we have almost 30 million tx on the blockchain, so it has to be 4 bytes per index
12:34:02 <dEBRUYNE> Perhaps there is some magic in there that can be utilized
12:34:40 <moneromooo> They're deltas, and heavily tail biased, so 4 bytes for the first, 3 bytes for the next 2, 2 bytes for most, one byte for the last.
12:34:53 <moneromooo> (deltas and varints)
12:35:13 <sech1> ah I see, some clever bit shuffling here and there
12:35:50 <moneromooo> Using pubkeys is also incompatible with deterministic ring selection.
12:36:06 <sech1> will we use some O(1) ring selection algorithms for Triptych? So that we don't need to store N indices on the blockchain?
12:36:12 <moneromooo> (AFAICT)
12:36:24 <moneromooo> Dunno yet.
12:36:29 <moneromooo> Likely.
12:36:44 <moneromooo> Well, O(n), but yes.
12:36:56 <sech1> "deterministic ring selection" that's what I meant by O(1)
12:37:20 <sech1> if you have your RNG seed stored, you can run deterministic from that seed to get all N ring members
12:37:45 <moneromooo> Oh, O(1) in space you mean, not time to generate ?
12:37:50 <sech1> but send pubkeys to the mempool still, right? If we want to use all recent inputs without limits
12:37:57 <sech1> O(1) in space, yes
12:38:24 <moneromooo> I don't understand the "but send..." line.
12:39:02 <sech1> if we want to use inputs without 10 block limit, we have to use pubkeys, so TXs in mempool will index ring members by pubkeys
12:39:33 <moneromooo> Yes.
12:39:34 <sech1> but, hmm... It will not work with deterministic ring selection after a reorg
12:39:48 <sech1> even if pubkeys stay the same, their indices might change
12:40:02 <moneromooo> Right.
12:40:43 <moneromooo> So, to go back to what I was thinking:
12:40:49 <moneromooo> - continue using indices
12:41:04 <moneromooo> - allow usage as soon as inputs are on the chain
12:41:35 <dEBRUYNE> <sech1> "deterministic ring selection" that's what I meant by O(1) <= Wouldn't that also be enforceable on the protocol level?
12:41:36 <moneromooo> - a recipient receiving a tx checks the youngest input, and considers the tx locked till it's >= 10 or so before acting on it
12:41:46 <dEBRUYNE> Then we can prevent custom software from hurting users with custom ring selection
12:42:08 <sech1> dEBRUYNE yes, that's one of the points apart from space savings
12:42:11 <moneromooo> This means a user can spend early, but the recipient will wait before doing whatever they want to do - should htey choose to.
12:43:29 <sech1> so 10 block limit is counted from the youngest input in the ring instead of output?
12:43:52 <moneromooo> Well, it's more like the lock becomes advisory really.
12:44:50 <moneromooo> Receiving a tx with a young input says "not only can this be maybe reorg'd and double spend, but this can also become invalid and never be minable again".
12:45:01 <moneromooo> Though this'd also be the case with double spends anyway.
12:45:25 <moneromooo> So if the recipient waits 10 blocks (or whatever), they're safe as now.
12:45:54 <moneromooo> The annoyance is for the sender, since they might have to resend if the tx does become invalid.
12:46:08 <moneromooo> But presumably it's less annoying that now for those people who do want to send early.
12:46:52 <moneromooo> However, it means it splits spenders in two groups: those who don't mind the possibility they'd have to resend, and those who do. So creation of an anonymity puddle of sorts.
12:47:50 <moneromooo> It does read more like an argument for removing the 10 blocks limit than changing anything, doesn't it...
12:48:38 <sech1> This 10 block limit is only because of tx indexing, right?
12:48:56 <sech1> So maybe switch to pubkeys and repack to indices after 10 blocks?
12:49:00 <moneromooo> Yes, because if it reorgs, all later txes using a younger input get invalidated.
12:49:19 <moneromooo> What does "repack to indices" mean ?
12:49:26 <sech1> it means rubbish :D
12:49:37 <sech1> you can't repack because it'll break block hashes
12:49:47 <moneromooo> I was thinking every single tx would be sent wiht pubkeys, and stored with indices.
12:49:55 <moneromooo> Block hashes would be made based on pubkeys.
12:50:29 <moneromooo> ie, indices would become only a LMDB internal thing. All the rest would see a list of pubkeys.
12:50:30 <sech1> you can store them with indices, and in case of a reorg, you pull all affected tx back into mempool and change indices to pubkeys again, right?
12:50:41 <moneromooo> Yes.
12:51:36 <sech1> " indices would become only a LMDB internal thing. All the rest would see a list of pubkeys." This is the best way
12:52:22 <sech1> Removing 10 block limitation would be big in the community, I guarantee that :D
12:53:14 <sech1> Now we just need to come up with a fancy name for this change and shill it everywhere :D
12:53:41 <moneromooo> BitcoinTech(tm)
12:59:03 <sech1> I think this change is more important than we think. It'll increase the money velocity cap 10x in a potential all-Monero economy, making it much better as money
12:59:14 <moneromooo> 128*2*32 == 8 kB for a Triptych tx just for ring description.
12:59:42 <moneromooo> (assuming 2 in and 128 rings)
13:00:53 <moneromooo> Actually, the problem remains to some extent:
13:01:06 <moneromooo> Alice spends output A, creating output B.
13:01:22 <moneromooo> Bob spends output C, using output B in his ring.
13:01:39 <moneromooo> Alice double spends A, creating D (and invalidating B in the process).
13:01:43 <moneromooo> Bob's tx is then invalid.
13:01:49 <moneromooo> So it's not just Alice's.
13:02:37 <sech1> well yes, any reorg can potentially invalidate TXs in orphaned blocks
13:02:38 <moneromooo> It doesn't annoy Carol since the numbering change doesn't affect other newer outputs though, so much better, but still not transparent to others.
13:04:11 <sech1> double spends invalidate some TXs by definition, 10 block limit only makes it harder to do
13:04:39 <sech1> It's up to the merchant how many confirmations to require
13:22:50 <gingeropolous> in addition to the benefits mentioned, this also hardens monero against seriously massive attacks
13:23:36 <gingeropolous> like, netsplits could become not a big deal, because they chain would resolve and absorb the fully valid but independent fork
13:24:27 <gingeropolous> the txpool would get massive for a while...
13:25:14 <gingeropolous> and txs would have to get mined in using some kind of magic where the protocol knows what order they need to be mined into the chain
13:25:29 <gingeropolous> to preserve rings
13:26:26 <gingeropolous> "this also hardens" this meaning the pubkey references instead of indices
16:29:34 <sgp_[m]> 10 block lock times is really bad UX though, I'm for anything we can do to sensibly lower that
16:31:04 <moneromooo> One thing that'd not change that but make it less annoying is to auto select the smallest output that fits the amount needed.
16:31:49 <hyc> that would throw age-based selection out the window
16:32:02 <moneromooo> Why h?
16:32:18 <hyc> the smallest appropriate output could be anywhere in age
16:32:23 <hyc> ?
16:32:29 <moneromooo> The others would also be.
16:32:51 <moneromooo> Age selection is for fake outs, not real ones. Currently real ones are random-ish, but without age bias.
16:33:07 <hyc> ah ok
16:33:44 <sgp_[m]> I'm somewhat worried that selection by amount would open up some nasty targeted attacks, but maybe that's considered out of scope without churning anyway
16:34:23 <sgp_[m]> eg: if you know someone will eventually spend 1 XMR, send them exactly 1 XMR to try and get close to that activity
16:34:30 <sgp_[m]> maybe I'm overthinking things though
16:40:41 <hyc> it does seem to give a lot more knowledge to senders.
19:43:45 <yqjhabypvcin> When Tari finally comes out, will you dump your Monero to buy it? Will others?