don't be evil vs can't be evil

I think the priority of many implementers is complying with the protocol. Rather than fingerprinting on purpose, it's just a matter of putting something together that works. If 'what works' reduces the possibilities to fingerprint, that's progress in my book. Fingerprinting should be a very intentional process, instead of the default.

Maybe I'm missing something here, but it should work out of the box. If they added some custom data, it's because they actually worked to do it.

there is some possibility of some custom data that might not be fingerprintable

so in that sense i would tend to agree that making it easy to avoid unnecessary fingerprinting could be helpful

in a lot of cases, though, extra data is going to be a fingerprint period, and making it easi to include on chain is inviting it

Yes, but that would be taken care of by making the format that but not enforcing it.

i dont really know how you do that besides enforcing

Prevent fingerprinting ? Remove extra I guess. Put tx keys and other things we need in strict fields.

isn't it the same as sorting keys. if everyone just did it, you wouldn't have to enforce, but demonstrated that some wont, not for any particular reason

I think it's not the same: that's something you have to have. People don't have to have custom extra data, and yet some added it.

sorting vs. not sorting is the same imo

That fingerprints in itsel, whether in a format or another.

the point being that it is easy to sort, but you can't really get people to sort without enforving

enforcing is basically how you coordinate

I get that. But if you enforce a particular framing for extra, the custom data is still there, that framing format did not get rid of the fingerprint, whereas enforcing sorting did.

some custom data is not going to be a fingerprint

but it could unnecessarily become one due to custom framing

I either do not agree or do not understand your point.

The main point for me is that NON-custom data will no longer be fingerprintable

is it now?

Yes, the sorting vs nonsorting distinction for normal tx, and the random implementation of extra nonce for pools (which I consider non-custom since all pools use the extra nonce).

moneromooo: lets say the custom data is an encrypted message. there is nothing fingerprintable about that, it is just random data

The fact that your tx includes this field is the fingerprint.

it could be, depends how widely used

Then a bettr thing to do it add a "custom data encrypted with the receiver key" field, whether or not the framing changes.

i think you are basically saying get rid of tx extra

So all people who want to include an opaque blob can use that (though there is still a question of message length).

This is essentially the Zcash "encrypted memo"

which is a fixed 512-byte blob that's required

if the max is short enough you could make it fixed length

pretty much what we do with payment id

I was planning on quantizing to mutliple of N bytes.

that's still "anonymity puddles" in Isthmus's language

you want every multiple of N to be either widely used or not at all

Yes, but it's better, and there's no perfect here.

so that pretty much means a small cap in practice, maybe not N*1 but N*some small integer

True. Then maybe well known sizes, like 0, 32, 256, 4096.

(examples)

512 bytes per tx seems a bit heavy. It does away with the puddles though, so it's tempting.

thats plausible

This would be in addition to separating out key fields?

so truly arbitrary data?

might get rid of 0

In my mind, it'd be a new extra field, yes. Independent of any others.

I think that's a much better idea

still not enforceable to be actually encrypted, of course

<joke>You could make the fee inversely proportional to the exponential of its entropy</joke>

im not really sure how we got to this point. the earlier discussion was about reducing fingerprinting, and we just added another one, although hopefully done in a way that minimizes the fingerprint. but it is still one

*confused as well*

Well, either there's room for some kind of arbitrary-ish data, or there isn't

moneromooo: would you mind adding your proposal to the git issue on this topic?

I think there is one already. Old.

But as smooth said it's really a different thing.

Can you add a reference/link? It seems like a counter proposal

Is the underlying question whether having _any_ allowances for arbitrary data is a good idea?

(beyond required fields and pID)

It's more about the scope of the protocol

It is certainly related. I've always been in favour of allowing it, but we've not seen any stupendous use so far, and the ones I've seen are more spam than innovative :(

So I'm slowly losing my support for it I think.

Nixing arbitrary extra in favor of fixed fields makes me happy from a protocol perspective, but who knows what applciations would break

I think killing the extra field presupposes indefinite hard forks, which is an unrealistic assumption

i dont think thats the case

Doesn't seem to be an issue about it, I only found monero-project/monero #1518 which is related but not that.

Or "Extra" did not grep it anyway.

Well if improvements to the protocol slow down, which is reasonable as there are diminishing returns, then hard forks will become more spread out. As adoption rises, coordinating those hard forks will also become harder. At some point they will probably become infeasible for anything except groundbreaking improvements.

They are also useful for client software upgrades

Protocol requirements are a good incentive to upgrade your software :)

How much adoption can be sustained by the core team? I feel like either Monero will grow beyond the primary implementation, at which point questions of 'default configuration' for non-protocol features like the extra field will be out of control (I agree with moneromooo that if implementers just take what core team ships, then fingerprinting is caused by 'messing with it'; of course, this falls apart if a project

tries to maintain itself without constantly rebasing, for example I'm guessing the existence of non-sorting extra fields is an implementation that forked BEFORE the core implementation started sorting, and they just didn't realize the field should be sorted now [a plausible explanation, other teams can't be expected to keep up with everything the core team does]), or the dominance of that implementation will lead to

an upper limit on infrastructure growth.

My proposal is especially to prepare for a future where core team has less influence. Now is the time to tie down loose ends.

Question, I want to make a test that makes it where connecting nodes reject blocks that do not accept the full block reward. Do i have to change the block template?

or do i have the change the base_reward in the cryptonote_basic_impl file?

getmonero.org/resources/developer-g…pc.html#set_account_tag_description says both inputs for describe_transfer are optional, but calling it without without params: {:error {:code -1 :message "no txset provided"} :id 0 :jsonrpc "2.0"}

so I was thinking earlier today, in custodial[-like] cases where a site has multiple users and ultimately each user is assigned its own wallet on the server (and get their address books, accounts, etc as a result), wouldn't it make sense to add 2FA support to the api? this way monero-wallet-rpc would work as a last line of defense by refusing to make transfers without being presented with a valid auth token. it would be completely optional

would it be opt in or opt out in terms of being optional

My testnet node is now running vtnerd 's Dandelion++ code - see monero-project/monero #6314

I just don't know how much sense that makes, given the current very, very small size of testnet: My daemon is currently connected to only 4 other nodes

And how can I watch whether Dandelion++ does or does not do its magic? A quick glance over the code did not show me a new log category that would give info

Normal, "downward-compatible" tx propagation seems to work, at least did for a test tx between two of my own daemons

Insight: as I imagine it, opt in

just throwing the idea out there, i don't have the c++ skills to make it happen. if someone finds the idea interesting, that'd be a good addition imo