UkoeHB: along the lines of not being able to hide transferring a special asset, have you seen the tx_out_to_script etc that linger in the monero codebase?

we've done a little thinking about it internally after asking around (few to no people even know about them). i figure one argument against enabling other tx_outs than _to_key in the validators etc is that would produce a segmentable set of txs.. but i suspect it's not a sound argument anyway since all to_script txs would be new traffic

anyway, to_script would have other privacy problems than that

probably

but i find it interesting that they're in there from 'before' 2014

endogenic: no that didn't really register for me (a lot of the old cryptonote stuff is still pretty opaque in my mind)

it's like the cosmic microwave background

although i guess technically that is what is left just *after* the era of opacity...

lol

oh don't mind me, just gonna chuck a uint8 vector on the chain..

op codes? what are those

Oooooh op codes 👀

Yea NRL / Monero Archival Project nodes should have reorg records since 2018

A while ago I wrote up some notes about how to quantitatively approach / evaluate changing the lock time

However I now believe that only 2/3 of it is correct

I published that framework on 2019-10-05, and less than a week later Hasu, James Prestwich, and Brandon Curtis published a paper token economics and security

Intro medium article: medium.com/@hasufly/research-paper-…eclining-block-subsidy-11a21f600e33

Full writeup text: uncommoncore.co/wp-content/uploads/…e-declining-block-subsidy-v1.02.pdf

I highly highly recommend their paper, it is a captivating read

Anyways, after reading their paper, I think that the portion of my framework pertaining to a 51% attack is not quite on the mark

However that's only 1 of the 3 considerations that I articulated, and I think(?) the other two are still correct and relevant

Hmm, at some point I wrote up a bunch of notes about how to extend the Hasu et al paper but I can't find them now

Basically, the paper is in the context of bitcoin and special-purpose mining equipment (ASICs), and naturally the dynamics are a little it different for a coin that can be mined on general-purpose equipment (CPUs)

But it's pretty straightforward to imagine how to generalize it to where the miner commitment isn't a dominant term

oh for lock time, you mean the 10 block lock

I just saw @gingeropolous mentioned "I think noncesense may have reorg #s, although as blocks get bigger those #s could change"

I haven't caught up on backlog or context

Sorry, I've been super busy with work stuff, haven't been able to keep up on IRC for a bit : (

Hoping to circle back to some more research around cached rings and the transaction flood soon

Flood talk wasn't accepted for the conference, alas

I want to return to that, and use the fingerprint filter + timing to deanonymize the flood transactions

s/transactions/ring signatures

Based on what we saw a few months ago, I'm guessing we can hit >100k rings matched with confidence with ease, but we'll see...

isthmus: Recently for BCH chain analysis I've been working with a fast graph analysis library called igraph. Have you heard of it? It's available in both Python and R.

Sad to hear that the paper didn't get into the conference. They don't know what they're missing.

yah know that idea to use the bitcoin blockchain as a ground truth and then create synthetic ring-sigs on top of it and then analyze the synthetic ring sig blockchain to see if the ground truth can be uncovered again?

i wonder if we'd have to filter out coinjoins

ugh, might need to actually suss out all obfuscation attempts on the bitcoin blockchain.. coinjoin, whatever that auto-hopper is,

and most (all?) of that tech is proprietary to those companies, so it'd be building from scratch.

well, at least we'd get a bitcoin fungibility tool out of it

i wonder what other considerations may lurk that could tank it.

Have the application of PIR schemes for Monero been studied?

no