So are we going to use statistical tests and other more obvious strategies within wallets to better select outputs that are not NFTs/poisoned? Fungibility doesn't need to be entirely compromised just because people are pooping on the chain. Looking at the Mordinals on chain, they're pretty easy to filter out, no?

You don't want to make it harder to put custom data in, or people will make it harder to spot. You want to try and spot it and blackball it. That way you get more of the bad data, rather than make it harder for you to spot, while an adversary might find better ways to spot it and keep it to themselves.

(in this particular case anyway)

if they keep it to themselves, that's fine. mordinals are only a problem because their outputs are being published.

I was just assuming that wallets could avoid choosing those outputs easily enough. I'll have to check out some of the output selection code to understand why not.

I remember we had a blacklist database of known spent outputs, and we could even feed it to the CLI wallet. Will it make sense to update the database with known Mordinals outputs (they have a specific tag in tx_extra)?

It's being removed. Though if there some newfound use for it, it's its job, yes.

It does require people to download and update it though.

sech1: I think it would be a good idea to add this feature, we could even go further and define an API so anyone could provide an "output validator" service and the wallets could connect to such services, because maybe some people have dedicated blacklists they don't want to share, or some services could gather output intelligence from multiple sources. Whether you trust or not those services would be up to each one to decide

though.

There we go.

wallets connecting to anything centralized for something as sensitive as decoy selection is a no-go

this feature already exists, it's a matter of updating the blacklist database

I did not imply that such services would be centralized, just that an API would be more flexible than a file

Yeah, not centralized, but something you could run yourself.

Anyway, repurposing the blacklist database is a useful first step.

The UX for a user having to use a tool like the blackball one is horrible.

If we keep tx_extra, instead of blackballing we could just ignore txs that have tx_extra in decoy selection.

Meeting 1.5hr

jtgrassie: you mean which have padding in tx_extra? That will not work if we go with B3.256 though

kgsphinx: hbs: That idea could be considered, but it's not simple. There's a whack-a-mole problem. You could avoid outputs with the Mordinal tag in tx_extra. Then a change in Mordinals or something new would require a change to the criteria. And then again. And how to keep user wallets updated? Or nodes? You would have several different decoy selection algorithms being used to construct txs on chain.

The different algorithms could be used to narrow down which software version was used.

I would start with excluding coinbase outputs, personally: monero-project/research-lab #109

Would constraining tags simplify things? i.e. reject transactions which have unknown tags in tx_extra?

There is no whack-a-mole there since coinbases are special and identifiable at the protocol level. Even with the p2pool upgrade, coinbase outputs are about 8 percent of on-chain outputs now

yes, coinbase outputs appear in most of the rings these days, with the amplification of p2pool pre HF

They would just change the tags. Whack. A. Mole.

jeffro256 said he would consider writing code to exclude coinbase outputs

It does not seem very practical to use blackballing to exclude mordinals outputs. Instead, the daemon could mark outputs that meet certain criteria in the get_outs call during tx construction. No need for users to manually keep lists updated then.

It should be default behavior, otherwise you're just fingerprinting your own transactions by specifically excluding mordinals outputs.

If we have to start building chainanalysis tools into the wallet, I think we've already lost :- P

Nicely put.

meeting time monero-project/meta #818

1. greetings

hello

hi

Hi I have to leave early today

Hello

Hello

Hey

hi

2. updates, what's everyone working on?

The authors of the paper “Range Proofs with Constant Size and Trustless Setup" are here leonardo.mostarda emsczkp to discuss their paper and answer any questions we may have

Hi nice to meet you all

Hi

we are the authors of the range paper proof paper

I am monitoring Mordinals. The mint rate has seemed to slow down over the past 48 hours. As of about 24 hours ago, total number of Mordinal txs were 24,222. Sum of Mordinal tx sizes was 202 Megabytes. Total fees to mint Mordinals was 4.05 XMR.

Good to have you on watch :) Interesting numbers.

Thanks for coming emsczkp and leonardo.mostarda!

xmrack[m]: You are welcome we are happy to clarify any doubts

xmrack[m]: is it just chat or some kind of videocall ?

Old school chat only

It is worth mentioning that the monero community has recently raised approx 130 XMR towards peer review/audit of bulletproofs++

Oh, that's filled already?

great!!

1.x xmr away

128.67 of 130

leonardo.mostarda: we are not committed to bp++, and is why we have invited you here today. Would like to hear more about your solutions

re: the constant size range proof, is there a comprehensive security analysis in the works?

The paper compares propf sizes with bulletproofs. I’d be curious to see how it compares to BP++

<ofrnxmr[m]> "leonardo.mostarda: we are not..." <- Our work is at preliminary stage. Our work seems to be sound and correct the deep analysis is ongoing work in progress. However we were inspired by other works which have been proved

bp++ author aims to have a new draft ready for April 14th, which is going to be re-looked at by CypherStack. adjusting the scope/price (as it will come with missing security proofs according to the author)

The paper seems to jump from security properties of the Halo2 design to conclusions about range proof security. Do you intend to extent the security proofs to cover this?

On an initial read of the paper, it was not immediately clear if/why this jump should be valid

leonardomostarda: do you have an estimate of the relative performance for proving/verification compared to BP? e.g. as a function of crypto operations

<xmrack[m]> "The paper compares propf sizes..." <- We do not know BP+ but we can compare our approach with it.

That is, if the Halo2 construction is sound and ZK, and if the original BP paper relied on certain IPP properties (like WEE), do these necessarily play nicely together?

It's already BP double plus :)

s/extent/extend

<AaronFeickert[m]> "The paper seems to jump from..." <- Yes, exactly. This is our ongoing work, we now have assumed the IPA argument relation of Halo as secure in our design. However, we need to prove the whole range proof when the new IPA relation is integrated.

Context for BP++ moneroresearch.info/index.php?actio…SOURCEVIEW_CORE&id=83&browserTabID=

Incidentally you might be interested in presenting your work at monerokon.com in Prague 23rd-25th June

The last sentence of the conclusion states "As future work, we will validate our approach in real case studies involving streams of sensor data" What do you mean by this?

blankpage[m]: Nice we are very interested. We will submit.

Hi, sorry I’m late. Thanks so much emsczkp and leonardomostarda for taking the time to join us.

I’m on a call that is taking most of my attention, so apologies in advance if I’m not very responsive. Will try to catch up.

<AaronFeickert[m]> "That is, if the Halo2 constructi..." <- Referring to Halo and BP, they share the same security properties (WEE, HVZK) and hardness assumptions. I think they can play nicely together.

hmm are there any other topics to discuss, otherwise we can end it early? I'm not feeling great today

<xmrack[m]> "The last sentence of the..." <- We are trying to develop private multi transfer payments in an IoT scenario. This involves a continuos stream of sensor data.

<isthmus> "I’m on a call that is taking..." <- Thanks your interest

<emsczkp[m]> "Yes, exactly. This is our..." <- Do you have any rough timelines for your ongoing work? Or is it too early to say.

Yes, this work has high priority since is part of my PhD

You're of course free not to say, but did the reviewers have any particular notes on the security model or analysis?

<leonardomostarda> "Nice we are very interested..." <- if you have event specific questions you're welcome to join us in #monero-events:monero.social

<AaronFeickert[m]> "You're of course free not to say..." <- The paper was published in a workshop. The number of pages were very very limited. We could not write a lot. A reviewer was asking about validation.

Yeah, page limits can be pretty brutal :/

Anyway, we are very happy to collaborate with anyone interested in completing the work with the needed proofs.

Can you remind me if the construction supports efficient batch verification? I don't have the paper handy

And unfortunately don't recall if this was the case

BP and BP+ verify linearly-ish, but shared generators mean pretty big savings in batch

ah, are there any plans to publish the paper outside springer? the paywall makes things difficult outside academia

Yeah, posting the submission version (if allowed) to ePrint would be great

I'd be very surprised if you weren't allowed

AaronFeickert[m]: Yes the work support batch verification and aggregation of range values. In fact the evaluation shows a constant proof size when the number of range values increase.

Nice

I'll need to review the details on this later

<AaronFeickert[m]> "Yeah, posting the submission..." <- yes by extending the work we could publish on a different journal

Oh I just meant posting the original preprint to the archive for open access

Great way to get extra eyes on it

yes for the preprint is fine, there should't be any problems

we are well past the hour, so in case anyone was wondering the meeting is over

next week we will return to the tx_extra discussion

thanks for attending everyone

thanks for inviting us to the meeting, should we join next week ?

leonardo.mostarda: emsczkp Thanks again for coming. You're free to come any week you'd like :) but don't feel obligated. This room is open 24/7 to discuss Monero related research.

Thanks, for sure we keep you updated with the progress of our work.