00:43:32 I thought we got these messages because you are a rude self-important man-child. 06:29:52 twitter.com/hyc_symas/status/1203709575226183683 06:29:52 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 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 Are there any CCS proposals for researching into reducing transaction confirmation time? 12:14:17 Not to my knowledge. 12:23:16 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 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 so maybe 5 block limit is still safe? 12:26:48 I've seen longer reorgs in the past, fwiw 12:28:26 yeah, I found one alternative blockchain size: 9 on 1580196 (2018-05-27) 12:29:06 and two more big reorgs (6 and 7 blocks) in June 2018, but after that everything is smooth 12:29:32 Oh. I had an idea. So it's probably stupid: 12:29:54 I think in the past it has been discussed to replace the reference to the global index with something else 12:29:59 Pubkeys maybe? Does anyone remember? 12:30:05 Allow txes to use any recent output, *but* unlock them based on the most recent input. 12:30:12 Yes. 12:30:20 it'll increase TX size 12:30:36 Yes, but you can swap for their index when storing. 12:30:46 that'll work 12:31:02 You do get more steady state traffic though, granted. 12:31:58 it'll increase TX size <= Any idea by how much? 12:32:10 index is 4 bytes, pubkey is what, 32 bytes? 12:32:14 The 'ten block lock time' is a common complaint and storage is fairly cheap 12:32:17 30 bytes per input. So... 30 * 2 * 11 typically. 12:32:19 multiply it by the ring size 12:32:50 Hmm 12:32:55 How does it affect verification time? 12:32:56 Index at 4 seems high. But maybe 2 is low. 12:33:08 quite noticeable, but if it's stored as index it's not a problem 12:33:15 Mostly irrelevant I expect. 12:33:52 For protocols such as Triptych this will add quite a lot of size 12:33:56 we have almost 30 million tx on the blockchain, so it has to be 4 bytes per index 12:34:02 Perhaps there is some magic in there that can be utilized 12:34:40 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 (deltas and varints) 12:35:13 ah I see, some clever bit shuffling here and there 12:35:50 Using pubkeys is also incompatible with deterministic ring selection. 12:36:06 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 (AFAICT) 12:36:24 Dunno yet. 12:36:29 Likely. 12:36:44 Well, O(n), but yes. 12:36:56 "deterministic ring selection" that's what I meant by O(1) 12:37:20 if you have your RNG seed stored, you can run deterministic from that seed to get all N ring members 12:37:45 Oh, O(1) in space you mean, not time to generate ? 12:37:50 but send pubkeys to the mempool still, right? If we want to use all recent inputs without limits 12:37:57 O(1) in space, yes 12:38:24 I don't understand the "but send..." line. 12:39:02 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 Yes. 12:39:34 but, hmm... It will not work with deterministic ring selection after a reorg 12:39:48 even if pubkeys stay the same, their indices might change 12:40:02 Right. 12:40:43 So, to go back to what I was thinking: 12:40:49 - continue using indices 12:41:04 - allow usage as soon as inputs are on the chain 12:41:35 "deterministic ring selection" that's what I meant by O(1) <= Wouldn't that also be enforceable on the protocol level? 12:41:36 - 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 Then we can prevent custom software from hurting users with custom ring selection 12:42:08 dEBRUYNE yes, that's one of the points apart from space savings 12:42:11 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 so 10 block limit is counted from the youngest input in the ring instead of output? 12:43:52 Well, it's more like the lock becomes advisory really. 12:44:50 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 Though this'd also be the case with double spends anyway. 12:45:25 So if the recipient waits 10 blocks (or whatever), they're safe as now. 12:45:54 The annoyance is for the sender, since they might have to resend if the tx does become invalid. 12:46:08 But presumably it's less annoying that now for those people who do want to send early. 12:46:52 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 It does read more like an argument for removing the 10 blocks limit than changing anything, doesn't it... 12:48:38 This 10 block limit is only because of tx indexing, right? 12:48:56 So maybe switch to pubkeys and repack to indices after 10 blocks? 12:49:00 Yes, because if it reorgs, all later txes using a younger input get invalidated. 12:49:19 What does "repack to indices" mean ? 12:49:26 it means rubbish :D 12:49:37 you can't repack because it'll break block hashes 12:49:47 I was thinking every single tx would be sent wiht pubkeys, and stored with indices. 12:49:55 Block hashes would be made based on pubkeys. 12:50:29 ie, indices would become only a LMDB internal thing. All the rest would see a list of pubkeys. 12:50:30 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 Yes. 12:51:36 " 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 Removing 10 block limitation would be big in the community, I guarantee that :D 12:53:14 Now we just need to come up with a fancy name for this change and shill it everywhere :D 12:53:41 BitcoinTech(tm) 12:59:03 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 128*2*32 == 8 kB for a Triptych tx just for ring description. 12:59:42 (assuming 2 in and 128 rings) 13:00:53 Actually, the problem remains to some extent: 13:01:06 Alice spends output A, creating output B. 13:01:22 Bob spends output C, using output B in his ring. 13:01:39 Alice double spends A, creating D (and invalidating B in the process). 13:01:43 Bob's tx is then invalid. 13:01:49 So it's not just Alice's. 13:02:37 well yes, any reorg can potentially invalidate TXs in orphaned blocks 13:02:38 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 double spends invalidate some TXs by definition, 10 block limit only makes it harder to do 13:04:39 It's up to the merchant how many confirmations to require 13:22:50 in addition to the benefits mentioned, this also hardens monero against seriously massive attacks 13:23:36 like, netsplits could become not a big deal, because they chain would resolve and absorb the fully valid but independent fork 13:24:27 the txpool would get massive for a while... 13:25:14 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 to preserve rings 13:26:26 "this also hardens" this meaning the pubkey references instead of indices 16:29:34 10 block lock times is really bad UX though, I'm for anything we can do to sensibly lower that 16:31:04 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 that would throw age-based selection out the window 16:32:02 Why h? 16:32:18 the smallest appropriate output could be anywhere in age 16:32:23 ? 16:32:29 The others would also be. 16:32:51 Age selection is for fake outs, not real ones. Currently real ones are random-ish, but without age bias. 16:33:07 ah ok 16:33:44 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 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 maybe I'm overthinking things though 16:40:41 it does seem to give a lot more knowledge to senders. 19:43:45 When Tari finally comes out, will you dump your Monero to buy it? Will others?