I thought we got these messages because you are a rude self-important man-child.

twitter.com/hyc_symas/status/1203709575226183683

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 :')

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?

<Angad Mutha> Are there any CCS proposals for researching into reducing transaction confirmation time?

Not to my knowledge.

Angad Mutha: Might be interesting to have some formal research on this -> old.reddit.com/r/Monero/comments/m2…code_integration/gqmoft0/?context=3

I couldn't find reorgs deeper than 4 blocks in my node's logs and my node is running 24/7 since 2018

so maybe 5 block limit is still safe?

I've seen longer reorgs in the past, fwiw

yeah, I found one alternative blockchain size: 9 on 1580196 (2018-05-27)

and two more big reorgs (6 and 7 blocks) in June 2018, but after that everything is smooth

Oh. I had an idea. So it's probably stupid:

I think in the past it has been discussed to replace the reference to the global index with something else

Pubkeys maybe? Does anyone remember?

Allow txes to use any recent output, *but* unlock them based on the most recent input.

Yes.

it'll increase TX size

Yes, but you can swap for their index when storing.

that'll work

You do get more steady state traffic though, granted.

<sech1> it'll increase TX size <= Any idea by how much?

index is 4 bytes, pubkey is what, 32 bytes?

The 'ten block lock time' is a common complaint and storage is fairly cheap

30 bytes per input. So... 30 * 2 * 11 typically.

multiply it by the ring size

Hmm

How does it affect verification time?

Index at 4 seems high. But maybe 2 is low.

quite noticeable, but if it's stored as index it's not a problem

Mostly irrelevant I expect.

For protocols such as Triptych this will add quite a lot of size

we have almost 30 million tx on the blockchain, so it has to be 4 bytes per index

Perhaps there is some magic in there that can be utilized

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.

(deltas and varints)

ah I see, some clever bit shuffling here and there

Using pubkeys is also incompatible with deterministic ring selection.

will we use some O(1) ring selection algorithms for Triptych? So that we don't need to store N indices on the blockchain?

(AFAICT)

Dunno yet.

Likely.

Well, O(n), but yes.

"deterministic ring selection" that's what I meant by O(1)

if you have your RNG seed stored, you can run deterministic from that seed to get all N ring members

Oh, O(1) in space you mean, not time to generate ?

but send pubkeys to the mempool still, right? If we want to use all recent inputs without limits

O(1) in space, yes

I don't understand the "but send..." line.

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

Yes.

but, hmm... It will not work with deterministic ring selection after a reorg

even if pubkeys stay the same, their indices might change

Right.

So, to go back to what I was thinking:

- continue using indices

- allow usage as soon as inputs are on the chain

<sech1> "deterministic ring selection" that's what I meant by O(1) <= Wouldn't that also be enforceable on the protocol level?

- a recipient receiving a tx checks the youngest input, and considers the tx locked till it's >= 10 or so before acting on it

Then we can prevent custom software from hurting users with custom ring selection

dEBRUYNE yes, that's one of the points apart from space savings

This means a user can spend early, but the recipient will wait before doing whatever they want to do - should htey choose to.

so 10 block limit is counted from the youngest input in the ring instead of output?

Well, it's more like the lock becomes advisory really.

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".

Though this'd also be the case with double spends anyway.

So if the recipient waits 10 blocks (or whatever), they're safe as now.

The annoyance is for the sender, since they might have to resend if the tx does become invalid.

But presumably it's less annoying that now for those people who do want to send early.

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.

It does read more like an argument for removing the 10 blocks limit than changing anything, doesn't it...

This 10 block limit is only because of tx indexing, right?

So maybe switch to pubkeys and repack to indices after 10 blocks?

Yes, because if it reorgs, all later txes using a younger input get invalidated.

What does "repack to indices" mean ?

it means rubbish :D

you can't repack because it'll break block hashes

I was thinking every single tx would be sent wiht pubkeys, and stored with indices.

Block hashes would be made based on pubkeys.

ie, indices would become only a LMDB internal thing. All the rest would see a list of pubkeys.

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?

Yes.

" indices would become only a LMDB internal thing. All the rest would see a list of pubkeys." This is the best way

Removing 10 block limitation would be big in the community, I guarantee that :D

Now we just need to come up with a fancy name for this change and shill it everywhere :D

BitcoinTech(tm)

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

128*2*32 == 8 kB for a Triptych tx just for ring description.

(assuming 2 in and 128 rings)

Actually, the problem remains to some extent:

Alice spends output A, creating output B.

Bob spends output C, using output B in his ring.

Alice double spends A, creating D (and invalidating B in the process).

Bob's tx is then invalid.

So it's not just Alice's.

well yes, any reorg can potentially invalidate TXs in orphaned blocks

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.

double spends invalidate some TXs by definition, 10 block limit only makes it harder to do

It's up to the merchant how many confirmations to require

in addition to the benefits mentioned, this also hardens monero against seriously massive attacks

like, netsplits could become not a big deal, because they chain would resolve and absorb the fully valid but independent fork

the txpool would get massive for a while...

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

to preserve rings

"this also hardens" this meaning the pubkey references instead of indices

10 block lock times is really bad UX though, I'm for anything we can do to sensibly lower that

One thing that'd not change that but make it less annoying is to auto select the smallest output that fits the amount needed.

that would throw age-based selection out the window

Why h?

the smallest appropriate output could be anywhere in age

?

The others would also be.

Age selection is for fake outs, not real ones. Currently real ones are random-ish, but without age bias.

ah ok

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

eg: if you know someone will eventually spend 1 XMR, send them exactly 1 XMR to try and get close to that activity

maybe I'm overthinking things though

it does seem to give a lot more knowledge to senders.

When Tari finally comes out, will you dump your Monero to buy it? Will others?