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