Author of Bp++ has just got back in contact, stating that they want to get a new draft ready before the paid review starts. CypherStack are aware and of course are fine with holding off. Liam feels we should wait and get a "review of the security proofs, which are not in the current eprint version." and they've uncovered "issues with the current eprint version". I will follow up and get an estimate of his time to complete this new

draft (now that communication lines are open).

If MRL now wants to wait for the new paper (to get these mysterious security proofs) then this would change the scope of the review and increase the price (unknown how much until the new draft is looked at)

plowsof11: thanks, if Liam says it's best to wait then we should wait

Ok so we cant stop arb data storage

we want a little bit of tx_extra to prevent the more harmful way of data storage that is using outputs

I would guess that the mempool isn't clearing because the larger relative size of the morbs causes a sorting problem meaning something is being left behind more often when a block is formed

you can still chain a lot of transactions with a smol tx_extra

what is the only "real" reason to use more than the limited tx_extra and instead use more than 1 tx? nfts

or data storage

so that just needs to be as unatractive as possible

I don't see how we can prevent chaining txns

for now it looks like we won against asics with forking around a bit and settling with randomx

hyc: we dont

we just need to make nfts themselves as unattractive as possible

aka break the transfering of them as often as it takes

steganography in outputs, afaik, is only feasible because there are so many spare bits in rangeproofs/bulletproofs to begin with

nobody will flood the chain with massive nft "collections" if they dont have the prospect of profiting of selling the collection to others

The solution is deterministic decoy selection

why can't we eliminate "spare" bits from outputs, thus leaving nowhere for steg to operate?

Because they "transfer" the morbs by making a custom decoy selection of burnt outputs

I thought steg could live anywhere by definition, not just in spare bits? Like you make a zero-amount output and hide it in the nonsense receiving address

not necessarily. I don't believe so anyway.

ASN.1 and Unicode had similar problems - there are multiple possible bit encodings for the same character

so additional rules were added to e.g. ASN.1 DER and UTF-8 to require that only the shortest possible encoding is used, and any others are rules invalid.

if we define a set of canonical encoding rules, then toggling spare bits of valid inputs will make them invalid.

steg only "works" because there are bits in the stream that are too insignifcant to affect the output when they're toggled.

tighten up the encoding rules, and that goes away.

After seeing an argument that arb data can be stored in outputs (32 bytes per output), I'm more inclined to saving tx_extra as an optional and encrypted 256-byte chunk of data

and make it pay higher fee, but not higher than "output storage" would need

hyc you can store 32 bytes per output by overwriting the stealth address of receiver

so you can generate 16 outputs of 1 piconero each

or even 0 XMR each

16*32 = 512 arbitrary bytes per transaction

well, one of the outputs must be real

or there will be no way to "prove NFT ownership"

so 480 bytes per transaction

almost 1 whole disk sector ;)

and if the fee is something like 0.0000001 per byte (5x the usual), it will cost 0.000048 XMR to store 480 bytes, or ~0.1 XMR per MB

no, it will cost more because it will be 1 in/16 out transaction

so if X = fee for 256 byte tx_extra field, A = fee for 1in/2out regular tx, B = fee for 1in/16out regular tx, than X = B-A - maximum fee we can charge for this field

*then X

yes, my quick calculations show we can charge 5x more per byte for this 256-byte field

isn't tx_extra currently used in merge mining?

that's in coinbase

yes, but no one is talking about removing it from coinbase

ok. presumaby then this 5x should not apply to coinbase txn either

coinbase tx doesn't pay fee at all

it "pays" the fee by occupying block space and not letting other transactions into the block, if mempool is full

yeah. sorry, been up all night, a bit fuzzy headed now

maybe it will be better to always have encrypted tx_extra, for better transaction uniformity

but can we realistically enforce that

in a hardfork, yes

I'm talking about post-Seraphis

limit it to 1060 bytes before hardfork, make it encrypted and mandatory 256-byte field after hardfork

i thought detecting if something is encrypted or not is hard

there are statistical tests for random sequences

They are flawed. Lots of false postives

we can crank up their sensitivity - even if tests fail for 1% of real encrypted messages, wallet can just try different encryption key to pass the test

1% extra work for the wallet, but it will detect unencrypted data quite easily

so false positives (<1%) are even desired

i assume the tests require really little ressources for nodes right

we can pick only those tests which require little CPU time, there are plenty to choose from

An NFT protocol could simply XOR the jpeg with some other part of the transaction, making it trivial to decrypt the blob which otherwise passes the statistical test

in other words, NFT protocol can just publish their encryption keys

Yes

true, encryption would only help on the very surface

It's up to them, we just want transaction uniformity on blockchain level, without offchain data to decode it

So statistical tests for encryption are simply a waste of time

not a waste if all default wallet implementations use encryption

they would help against people storing arb data outside of public nft protocols

because if we make the "default" way (encryption) the easiest way, everyone will use it

we lost every matrix user

Arbitrary data storage will always be limited by the path of least resistance. The true cost of arbitrary data storage of X bytes will be however much you permit cheap storage (with tx_x) + steg. The more expensive arbitrary data storage is the less of it will be used. The true price limit will always be steg, so the way to limit arbitrary data storage is to remove all the paths of least resistance and enforce stricter

validation on steg as hyc suggested.

<monerobull[m]> "we want a little bit of tx_extra..." <- keeping tx_extra in a restrained form does not *prevent* an individual from using outputs for data storage, but it may *disincentivize* use of outputs for that purpose

<blankpage[m]> "That cost analysis also applies..." <- would tightening the dynamic block algorithm help mitigate a flood attack?

fr33_yourself[m]: the algorithm is already designed to do that

alrighty thanks :) I figured there were probably tweaks made after the 2021 flood

I agree with Alex and HYC's ideas, but those solutions sound pretty hard to get right and implement, so perhaps they are likely to be longer term solutions as opposed to actions that can be deployed quickly

There's no output spam at the moment.

UkoeHB: bp++ author has set a target to complete new draft for April 14th

Sweet

I don't see a way to prevent steg (when used in pub keys) because we have to allow any valid pub key (which we know can easily be brute forced in just a few bits of any 32 byte key).

We cetainly can (and cheaply) do a statistical test on tx_extra.

The simplest is an entropy test (github.com/jtgrassie/cent) whereby we enforce entropy of something like ~7 bits per byte.

Sure, there will be several files/types which will pass, but that's ok as many unencrypted will fail.

jtgrassie: Does an entropy test have a p-value?

An entropy test we just define the level of bits per byte we deem distibuted enough. Any valid encryption should be approaching 8.

My skepticism is that you don't set a false positive rate with an ad hoc test like this

To say nothing of the false negative rate

Most encryption algos have high entropy on output, that's a goal. We can even suggest algo people use to ensure pass rate.

Remember, our goal here is to reduce unencrypted data, and high entropy does that.

But if something unencrypted random passes our test, fine.

If there is a better test, should we use it?

There are other distibution tests (chi-sq comes to mind), we should use the fastest

The desired outcomes should be determined. What is the false positive and false negative rates we want? And the computational speed?

Indeed

This is Shannon Entropy, right?

yes

any bit distribution test can be trivially avoided

it is pointless to play whack-a-mole with people who don't want privacy, all we can do is design to support the people who do

Hi all. My name is Dimitri. I am a researcher on elliptic cryptography. I read monero documentation. That is why I asked the following question on the site crypto.stackexchange.com/questions/…-a-set-for-an-elliptic-curve-e-over

Let me know please if you have any comments on my question.

Your hash function E(Fq) -> E(Fq) on the curve Ed25519 raises many questions on the Internet. I think that it is necessary to conduct research on this topic. I am ready to do that.

Shannon Entropy of tx_extra of 07c818d91365ea0959dcae1fc45c47477e4ea0b7be3bf5df7368c8dea01d1e21: 7.947646

Shannon Entropy of tx_extra of 1bef5d92e56076a80c4b72089617f92698edfce77cae4ce2ad998761759943d0: 7.969315

UkoeHB: "trivially avoided" yes, encrypt and publish the encryption key, but our goal would be a quick test to prevent easily readable data.

The former tx is not a Mordinal. The latter is a Mordinal. Are my calculations incorrect?

Dimitri[m]: web.getmonero.org/resources/research-lab/pubs/ge_fromfe.pdf arxiv.org/pdf/0706.1448.pdf

jtgrassie: much more trivial than that, just XOR in some fixed string or even another part of the tx

Dimitri[m]: there is another mapping called Elligator2 that has similar properties

<UkoeHB> "Dimitri: web.getmonero...." <- I took a look earlier at these sources. The first is not published. The second is obsolete.

Obsolete?

There is the draft datatracker.ietf.org/doc/draft-irtf-cfrg-hash-to-curve

not to mention recent research like link.springer.com/chapter/10.1007/978-3-031-22963-3_3

^ I may have messed up the labels above. One moment....

Obsolete as in, there are better functions now? In order to change the hash to point function we’d need a major hard fork on a similar magnitude to seraphis.

Rucknium[m]: those are only over 32 bytes (and your results are off)

We would be testing over 255 bytes (not 32)

UkoeHB: Yes, there are faster hash functions to elliptic curves. Nevertheless, your approach is still safe of course.

07c818.. has 4.8125 (over it's 32 bytes) and 1bef.. has 4.9375. But a test over only 32 bytes is not the same over 255. The more bytes the better the test.

I think I misidentified the txs. I am using the JSON response, which gives tx_extra as 0-255 integers

I also misunderstood your msg. I thought you posted the actual tx_extra, not a txid!

Technically, how do you deal with a "sample" that is missing one or more of the possible 0-255 integers when calculating entropy? Just putting it into the formula gives to NaN.

You enforce 255 bytes

I accidentally chose two Mordinals 😅

The sample probability of the "missing" integers/bytes is 0. log(0) = NaN

It's also pointless doing tests on the existing blockchain as we use tx_extra for other purposes. Tests have to be independent

It isn't necessarily completely pointless if you strip away the "regular" bits of into from tx_extra and test the entropy of what's left

*of info

Presumably in the future, if a randomness test were to be enforced, it wouldn't happen over needed bits of information like encrypted payment IDs and additional pubkeys

That would leave the majority of transactions with a tx_extra entropy of effectively 0

At a minimum, those things should have a high probability of passing the test. That's an example of encrypted content or public keys that should pass the test.

True

I'm not super familiar, but aren't there tests that measure entropy changes over parts of the string, sort of like a local entropy. We wouldn't want someone to "hide" low entropy by putting them next to truely random bits

I made that point about a month ago: more powerful tests would consider the sequence of bytes instead of just the set of bytes.

Yes, and other tests should be considered vs just using an entropy test.

Many images would pass an entropy test of say 7 bits per byte (over 255 bytes) but many would also fail. But, using most enc algos would almost always be higher than 7.

I agree we need to define and test, but we should remember our goal is not to enforce encrypption, just to have a simple, fast test to pluck out low hanging fruit.

("low hanging fruit" being obviously not encrypted)

Yes I thought the idea was that anyone designing to use tx_extra would get too many dropped txns unless they default encrypt. Which solves maybe 99% of the problem, even if you can individually find ways of passing non-random data in tx_extra.

I pinged the authors of the constant-size range proof paper, as a reminder, and they confirmed they will be at tomorrows meeting. Looking online I found another constant-size range proof paper from 2022 called Cuproof. UkoeHB kayabanerve Have you read this before? moneroresearch.info/index.php?actio…OURCEVIEW_CORE&id=179&browserTabID=

I believe Cuproof has a prior discussion

The name sounded familiar, but I don't think I looked at it until now

Trusted setup RSA group

ew, nevermind

what's wrong with a lil' rsa in our protocol

*I continued to be horrified by the continued usage of RSA, even if I understand their practicality.

BawdyAnarchist[m: "Which solves maybe 99% of the problem..." < Exactly this