tevador: re this: monero-project/monero #7889#issuecomment-1002803963

we need some way to pass along a message with thorchain, and we are currently planning to use the encrypted pid for thios

s/thios/this/

it says 16 bytes but it's actually 16 characters (8 bytes)

we need a non-interactive way to pass along a small string at least

that sounds like (not encrypted) payment ids

tevador: U = x126582dfc357b10ecb0ce0f12c26359f53c64d4900b7696c2c4b3f7dcab7f730 X = x4017a126181c34b0774d590523a08346be4f42348eddd50eb7a441b571b2b613

Hey everyone! I have a big favor to ask. I'm constructing a deanonymized dataset of transactions on Testnet to research the plausibility of deep learning attacks against the Monero blockchain. I currently have an automated system in place to collect new transactions but I really need older transactions using inputs over a long period of time. If you have a Monero Testnet wallet that has made transactions in the past, please PM me

the seed! You can transfer any funds out of the wallet before giving it to me since I only need the transaction metadata.

Due to my automated system performing transactions as fast as possible ( once every 20 mins ) Most often, the output in the ring signature is the most recent UTXO. To construct a balanced dataset to prevent neural networks from overfitting, you want an even number of transactional outputs from each position in the ring signature ( 1 - 11 ).

Thanks :)

* balanced dataset and to prevent, * to prevent the neural networks

* Hey everyone! I have a big favor to ask. I'm constructing a deanonymized dataset of transactions on Testnet to research the plausibility of deep learning attacks against the Monero blockchain. I currently have an automated system in place to collect new transactions but I really need older transactions... (full message at libera.ems.host/_matrix/media/r0/do…409a350808ade9d1a8e300c91937ac2bd5c)

My impression reading this xmr-ack is to make sure your model is effective against arbitrary transactions, for which the spend behavior isn't necessarily known. If you're testing by sending transactions ASAP, obviously a guess-newest is going to be effective against those. But not everyone does that in practice, hence why it's potentially unreliable in practice

the largest set of monero transactions for which ground truth exists are for pre-RingCT outputs

you can look at average numbers when comparing the real distribution against the expected average decoy distribution, but this has limited specific impact because there isn't ground truth to verify

<sgp_> "My impression reading this xmr-..." <- Yea I agree, having my script wait hours or days before transacting will take forever, thats why I’m looking to crowd source a lot of the transactions. Supervised learning problems need a ton of data and I’d really like to try and avoid oversampling/undersampling a small incomplete dataset. This is only one use case for the dataset as well, other models not classifying the true

spend will not care if they are all back to back.

So, Jamtis saves 9 bytes from 2/out TX size and 33 bytes from 3+/out tx size: gist.github.com/tevador/50160d160d2…52ae02eb3d17024#45-transaction-size

xmr-ack: why not run your own custom testnet, with a single node and a 5 second block time

That way you can set up several wallets and mine all your transactions whenever you want

Your model doesn't actually depend on timestamps, does it? It should only depend on block height

tevador: "These public keys can use the existing TX_EXTRA_TAG_ADDITIONAL_PUBKEYS field." Seraphis will completely re-do most of the existing tx structure. Txo pubkeys will go in a `tx_supplement` field.

UkoeHB: is this documented somewhere?

my PoC models the end result I am aiming for

here is the lib I am working on: github.com/UkoeHB/monero/tree/seraphis_lib

Btw, it might be worth considering the removal of tx_extra when we're at it...

my favorite quote: "An arbitrary plaintext data payload in a system whose privacy relies on indistinguishably is like a screen door on a submarine."

but leave tx_extra for coinbase transactions

I still think removing tx_extra is a mistake. For example, thorchain is planning to use tx_extra. What other use-cases would we prevent by removing the field? It is unknowable. It also creates an unhealthy dependency on core development, if core needs to evaluate and implement every new thing the ecosystem wants to do.

UkoeHB: They are using encrypted payment IDs afaik

<sgp_> we need some way to pass along a message with thorchain, and we are currently planning to use the encrypted pid for thios

^ UkoeHB

sure, the epids are in the tx extra field, and people want to deprecate epids anyway - so thorchain would have to add their own tx extra field to get the result they want

the main point is that we should not add a dummy field to all transactions just because of a thorchain feature

AMEN <tevador> my favorite quote: "An arbitrary plaintext data payload in a system whose privacy relies on indistinguishably is like a screen door on a submarine."

<tevador> "the main point is that we should..." <- you shouldn't think of this as just a "thorchain feature"; you would potentially be removing the ability to express transaction intent in an encrypted way

subaddresses work when you can have the recipient cooperate, but they don't seem to work nearly as well if the sender needs to express intent non-cooperatively

you can still express intent and encrypt it with the shared secret using a custom tx_extra field

isn't that worse for privacy? I explicity tries to push them away from using a custom tx_extra implementation

in any case, the thorchain feature will need more than 8 bytes

s/explicity/explicitly/, s/tries/tried/

tevador: did you see the gitlab issue?

the intent is NOT to store the whole string in tx_extra

s/string/command/

I read it, it's supposed to be a hash value

yes a hash value

but a 64-bit hash is not sufficient

that gives you mere 32 bits of collision resistance

I can find collisions on my laptop in a few minutes

why was 8 bytes chosen for payment IDs initially?

the difference is that a payment ID is not a hash value

the original 3

32-byte PID could be

if you want real security, you probably need a 32-byte hash and store it in tx_extra in a custom field

I specifically pushed thorchain away from using tx_extra because it seemed people wanted to remove tx_extra (that risk seems to remain), and I felt it was best to work within the existing framework if possible for transaction indistinguishability (at least on the monero side)

Are people actually that concerned about having a small memo for each transaction? Zcash has that for a huge 512 byte one, and Firo will probably go with 32 bytes

If you want to throw distinguishability out the door, thorchain can just chuck the whole message in tx_extra and they'll be happier. I had figured for the sake of privacy people wouldn't want it done this way

we have this PR: monero-project/monero #6410

I think a fixed memo of 32 bytes would be possible if we wanted to go this route

tevador: did you get the U/X hex strings working?

tevador: I generally agree with Sarang here: "For optimal uniformity, the field should be required and of a fixed size. But at that point, you effectively have a larger encrypted payment ID field, and the functionality overlaps. Allowing even a quantized variable size opens the door to multiple anonymity pools and fingerprinting."

We will happily use a memo instead of a payment ID if it wants to be renamed and redone, and if it's large enough (which 32 bytes definitely is)

s/wants to be renamed and redone, and if it//

I just need a decision to be made on what you want thorchain to use

tevador: while I definitely accept your point about collisions (you know a lot more than me), keep in mind that for one to be effective, you would need to pass a RUNE transaction with a request string that matches the expected format. So if you were trying to, say, receive the traded funds in another address, you would need to pass your malicious destination address properly in this string in the correct format such that it hashed to the

same value

UkoeHB: yes, thanks. I still need to make some modification to Polyseed and then I'll add the test vectors.

sgp_: the collisions can be in arbitrary format, e.g. I can just generate random addresses until the hash matches

yeah I see, you're right

in any case, the tx_extra memo field is orthogonal to the addressing scheme, so for now I'm just assuming that encrypted PIDs will be removed

32 bit collisions means collisions within the generated pool in 2^32 steps. If you want to collide with a preexisting set of 2^N size, it'd take 2^(64-N) steps or so.

ie, you might get collisions in your brute force set first, but they don't "count".

the thorchain issue doesn't really explain how the hash will be used, so I can't commend on specific attack scenarios

(just being pedantic, I don't know which one applies to that particular use)

comment*

Btw, since we are talking about generously increasing the tx size with encrypted memos, it would also be possible for the sender to include the encrypted 64-bit index of the account+subaddress. That would eliminate hashtable lookups and issues like "subaddress lookahead".

The tuple (i,j) would be encrypted twice: once in the address (using a block cipher), and second time by the sender of the tx (using a stream cipher). The recipient would decrypt (i,j) and check if K_s+(q+H(k_vb,i,j))G matches the tx key (the same number of EC ops). No need to cache any addresses in advance.

that would add 64 bits?

tevador: I think it can be done without loss of privacy for Tier 1s. Tier 1s can already link outputs sent to the same subaddress, so it is fine if the Tier 1 can open the stream cipher. Then, Tier 2 can open the block cipher. If the block cipher has a 2-byte MAC, then Tier 2s won't have to compute test spend keys for most unowned outputs.

Change and self-spends would have a dummy address ID

sgp_: 8 bytes per output and 8 bytes per address

UkoeHB: the MAC could be just 1 bytes, it's basically a level 2 view tag

hmm ok it might be fine; for every 10mill outputs and 1-byte MAC, you'd only need to compute a test spend key for 151 unowned outputs

> No need to cache any addresses in advance.

I think caching would still be useful for high-volume users.

yes, but this time it would be really just a cache and not a database

Blowfish seems like the best candidate block cipher, the permutation conveniently accepts two 32-bit integers: en.wikipedia.org/wiki/Blowfish_(cipher)#Blowfish_in_pseudocode

<UkoeHB> "tevador: I think it can be..." <- "tier 1s can already link outputs sent to the same subaddress" This was actually unknown to me, that definitely sucks

Yes, we talked about this and settled on hiding change outputs from Tier 1.

It's still an obvious privacy improvement over the status quo but in practice a lot of users will reveal what outputs they receive then

IMO it's the fundamental cost of offloading most computations to a third party.

even if subaddresses are reused, Tier 1 still won't learn amounts and when exactly outputs are spent

for the MAC we could use Siphash :p

it can work, but the question is if it's worth the 8 bytes per output

tevador: what are the values for X and U in jamtis?

tevador: nevermind, i just saw the hex in the above conversation

My goal with the interface -> impl relationships is to allow flexible composition. A MasterKey could be a local C++ object, or an interface for a hardware/cold wallet. An ENoteFinder could be a local C++ object, or an interface for a third-party scanning service. An AddressBook could be shared between multiple wallets. And so on

I also really want normal wallets and multisig wallets to be separate, hence most of FullWallet is encapsulated by modular sub-components.