meeting 2hr

Greetings, everyone :)

Hello

Hi

Hello

Hi

hello

oh hi meeting time lol

here's the agenda: monero-project/meta #722

2. updates, what has everyone been working on?

me: I've been updating my seraphis library to support scanning for legacy enotes.

Which is required in order to make a wallet that's independent of wallet2

Me: OSPEAD

I implemented BP and BP+ in Rust, which I don't believe has been done before. It offers another point of reference towards it while overall providing more commentary on the algorithm. While an audit did say they would do a Rust impl, they ended up identifying a non-Monero-compliant Rust impl as 'similar' and left it at this. This is confirmed to be compliant.

*specifically proving, so only half of the problem

I have been rescanning the Borromean signatures as I thought it was a bug on my software or a connection problem when I found the frist wrong signature stored and I found three more. So 6 in total so far. I didnt debug the addKeys2 (ge_double_scalarmult_base_vartime) to find exactly what is happening but as I far as I could see, half the bits are correct and half are wrong (therefore the interpretation of the wrong

Scalar). I could not find the exact mapping yet though.

And I started looking how to implement the verification_bp function in Rust as I believe I wont be able to scan the whole BP era with my accurate and slow python tools :p

kayabanerve: is helping me with that :)

dangerousfreedom: Referring to the "malleability" issues, what is the approximate date of the most recent transaction that has had this issue?

Rucknium[m]: So far the last I found is this one:https://xmrchain.net/search?value=e4b7982b081a17892525f1b1d3011ec06a0820cbf451d3a64f8ea998104a753c

2018-02-04

3. discussion

dangerousfreedom: Security of this should be prove-able so long as we can provide a scalar transformation, globally applied, as an alternative for the normal deserialization process.

kayabanerve[m]: Yes. I think so. I just didnt find the mapping yet. (Didnt try hard either)

How did those transactions get mined? Lack of certain tests in the daemon?

People specified scalars > l. The daemon didn't care.

rbrunner: I think so. There were not enough enforcement on the scalars and Points stored in the blockchain

The Zcash blockchain is being spammed and most of their wallets are struggling with tx scanning. The only wallet that seems to be handling the spam is one that has "Warp Sync". We probably can't use anything from the Warp Sync method, but I wanted to bring it up just in case we can incorporate something into Monero:

So that could be phrased as lack of tests, it could be phrased as indifference, or could be phrased as a bug.

Isn't Warp Sync syncing in reverse in order to not need to scan old notes you've already spent?

Oh. No, sorry. That's a different thing of theirs.

Warp Sync does more than that.

Warp Sync is calculating the Merkle tree, which they use for their membership proofs (close enough), at the end so they only calculate it once.

Instead of calculating it for [] and then constantly updating.

*and yes, other improvements, yet that's the primary one

So indeed no inspiration for Monero to get there, probably, because wholly different?

Don't know much about Merkle trees, but never saw one in Monero :)

it's a good reference for if we ever go to a zk proof relying on a merkle tree

rbrunner: someone hasn't looked :p

we use them in blocks lol

but no, we don't use a merkle tree to store output indexes... yet 👀

So Warp Sync isn't notably relevant now

You mean also a chain is a tree?

Merkle trees are used all the way back in Bitcoin

rbrunner: there's a merkle tree for tx ids in blocks iirc

Monero block headers contain a tree root of TXs

Interesting. Will have a look. Saw blocks as mere linear arrays so far, in my mind.

Same thing BTC does. ETH has merkle patricia trees they use for storage, and they also include a few different roots for different parts of the codebase.

there was actually an ancient bug in the merkle tree code that led to a hardfork to handle a broken block

512 transactions bug

While processing is linear, merkle trees are used for logarithmic membership proofs. Bitcoin light clients can prove TX inclusion without sending the entire block. Same with Monero

It's why they're discussed here as well, for transaction membership. They're log 2. We can verify membership within 2^64 TXs with just 64 ops.

The difficulty is in a ZK transformation of that proof, hence circuits, yet that does get a bit off topic for now

Not that this isn't the place. Just that we've sufficiently discussed merkles :p

"elaborates upon exactly what the offending blcok did to the network." I can tell they wrote this quickly :)

I will need to correct "out-of-order" timestamps on XMR blocks (and other blockchains, but that's less important.) I have not tried to read existing work on block time stamp correction. Anyone know a reference implementation/method? And what are the main hypotheses about why timestamps are sometimes out of order?

that was an 8-day paper lol, not too shabby

... i despise blockchain NTP

The hypotheses are important since it is good to do a statistical correction based on some understanding of the "data generating process".

Bit of an off topic. Rucknium the algorithm is sufficiently simple, you can read it quickly, yet it's expensive/annoying to calculate on the spot when we shouldn't even track time.

Timestamps can be out of order because we don't enforce they're sequential, which is an opinionated discussion.

So it's whatever your local view on time is. When blocks are mined in close proximity, that drift can be especially notable.

Rucknium[m]: the main reason I can think of is unsychronized clocks

I never saw anything else mentioned.

There's also a variety of discussions on historic NTP. I've read posts saying a few minutes is acceptable, posts saying ~30 seconds, and now I'd be horrified to hear >10s tbh

As I can't remember a reason why somebody would stamp wrongly on purpose

kayabanerve[m]: how about you define NTP for us.....

Which is relevant when you remember BTC isn't from the last ten years

I think gingeropolous mentioned a "time warp" attack as a possible motivation by a set of coordinated miners

Network Time Protocol

It's an actual protocol. Monero has its own NTP... algorithm? though

Where it's the median of the last 15 blocks IIRC, which is used for TX timestamp acceptance

And then I assume we also require new blocks have a timestamp past the median.

*past whatever Monero's clock says it is.

I believe it's a median, yet I don't remember off the top of my head.

So the clock does effect difficulty. Lowering it, by claiming to be in the future, will hit a future time limit. Raising it, by claiming to be in the past, is possible.

Ideally what a block timestamp would tell me is that all txs in the block were broadcast before that real-life time. (Even better, for blocks that are not full, is that all txs were broadcast between the previous block and the block that the tx was confirmed in.)

It's just also a 51% attack lowering distribution.

kayabanerve[m]: Rucknium[m] asked about block timestamps, not how the difficulty algo works

UkoeHB: I'm saying there is no attack based on time manipulation except via difficulty.

If I understand correctly, there are timestamp rules to "bound" difficulty adjustments, as a consensus rule.

My next comment was going to be there are ways you can spike/drop difficulty, mine, then leave and come back.

It was frequent in the BTC fork scene for small coins. Miners mine 3 at a time, or however many, screw with one, then screw with the next. By the end of the line, the original corrects itself and you can come back. That's the only attack I remember as making sense

kayabanerve[m]: and yet... he is asking about tx timing, not the difficulty algo...

I suppose one thing I could look for is timestamps that are at the boundary of what the consensus rules would accept

I don't see it as an active concern to Monero given our size

... oh. Sorry then.

Alternatively, if someone(s) had reliable logs on the time that blocks have been received by their node for the last year or two...that could be a good replacement for the timestamp in the blocks. Obviously, those logs would be dependent on that particular node's position in the network.

It's all perspective, besides the definition used for TX timelocks. I'd suggest whatever we used as seeds for the relevant years if you want higher-accuracy timestamps.

"I will need to correct "out-of-order" timestamps on XMR blocks" I am a bit surprised this should be somehow important. After all you have the block numbers.

Whatever we used as seeds?

rbrunner: I expect that the necessary correction would be minor. But it's good to be more precise.

Rucknium[m]: we added deterministic unlock_times here, which is probably the best way to estimate each block's timestamp monero-project/monero #6745

if you don't trust the block timestamp

Seed nodes. Nodes people first connect to when we join the network. If you get logs from those nodes, not only are they presumed reliable with high bandwidth and connections, they'll be epicenters (assuming the network isn't perfect at distributing itself in this whole p2p thing, yet p2p isn't my specialty)

Put another way, human behavior is based on real-life time, not on Monero's "NTP". So having the real life time is important.

I'm not even sure we have "seed nodes" versus a list of nodes usable as seeds, which would be my assumption...

kayabanerve: I see what you mean. I think position in the network is not extremely important as long as its position doesn't change much. The positioning that matters is, I suppose, network distance to the mining nodes.

Would anyone have those logs though?

neptune has some code on GitHub to have an archiving node, complete with mempool data. I'm not sure if that is being actively run now.

any other topics to discuss in this meeting?

there has been some discussion about the tx_extra...

I felt sgp_'s response was reasonble

<3

This, right? monero-project/monero #6668

yeah

You mean some more recent discussion :)

I would agree that the issue with tx_extra and similar issues is not "spam" from on-chain "data storage", but rather privacy implications from tx non-uniformity.

The toxic content attack

With a break since start of May until recently

I personally most prefer steganography

Oh, May last year :)

Allowing it only for miners is reasonable

Encrypted steganography would be completely indistinguishable, maintaining privacy.

what do you mean by allow?

Only for coinbase

Tx extra

If we don't care to encourage steganography, and its computational cost, then my suggestion would be a 255 byte limited field, as it is now.

UkoeHB: suggested enforcing TLV. I don't believe that's valuable in any way. If we're removing all wallet data from it, so it's just arbitrary data, any users will solely waste bytes define PADDING + re-defining length imo

steganography seems.... prone to mistakes

we can specify a protocol and a reference

for reference, the encrypted memo for zcash is 512 bytes, which seems super long

Also, ArticMine[m], do you have any reason to allow it in coinbase? Merge mining, I'd guess?

sgp[m]: do they have much larger txs? maybe it's proportionally small

For most uses case, 128 should be enough. I noted a case relevant to Monero when you'd want 256 though

(2 JAMTIS addresses, one for a return address, one for... whatever would exceed 128 bytes yet not exceed 255, while leaving room in said 255 for additional messages)

Merge mining

I would also like to see the removal of tx_extra in favor of better uniformity. Not trying to give anyone ideas but from a redteaming perspective, you could possibly abuse the blockchain and put signed commands within the field to control a botnet.

I see tx_extra as a possible attack vector

ok we are at the end of the hour so I'll call it here; thanks for attending everyone

Some research on using XMR txs to send messages:

Guo, Z., Shi, L., Xu, M., & Yin, H. (2021). MRCC: A practical covert channel over Monero with provable security

I believe they do not use tx_extra

They embed it I'm the ring signatures

We'll never stop messages. The sole question if we prefer storage, computation, or transaction quantity.

is there a way the payload could be sent to the miner to be included in the block, that is somehow tied to a particular tx? so the tx doesn't contain the data, just a pointer to whatevers stored in the block..

This valid EC point from tevador on the GitHub issue is an instant classic: Hex: 5468697320697320612076616c6964206564323535313920706f696e742e2e2e ASCII: This is a valid ed25519 point...

Steganography in outputs, my preference, is computationally expensive while being less efficient as storage yet uniform.

i lean towards having some sort of thing, but its uniform. i.e., all txs have one, but most of them are just dummies

Tx extra is solely storage

im tryin to find a good understanding of your steganography thing here

Ring signatures and change outputs, if we ever limit to just 2, requires multiple transactions

gingeropolous: Every output lets you specify two keys, R and K

You can safely get 30 bytes from each

So every added output gives you 60. There's also the view tag and enc amount

You can further improve it by encrypting it before hand. Then it'll be uniform and won't be distinguishable

ah ok. so the new outputs end up being the data, instead of there be some data space available in a tx

So it's a computational extra when it happens, but it's only for the transactions requiring it and doesn't require an addendum to every tx

It is 3-4 output txs though. Those aren't the most common

So that is still notable

So, in other words, systematic abuse of outputs? Makes me shudder, to be honest.

You can also use clsag signature responses, ring public keys...

rbrunner: It removes tx extra and creates fully uniform txs, even with messages, without requiring every tx include an extra quarter kb of random data

*ignoring output quantity, assuming sane implementation

Yes, I think I see, but I can't come around yet to like that tradeoff

What's next? Completely fake transactions? Just to exagerate a bit.

... we also have keeping tx extra and keeping tx extra with a fixed size

Do you want to come around to those instead? :p

The question isn't what do we all love. It's what's best for our reality

Which is that anyone who wants to do this, will do this, and we can't successfully avoid it.

rbrunner: Completely fake txs already happened last year :P

So what way is optimal for monero

Yeah, right, that spam attack

Rucknium[m]: Clearly you haven't checked for data overlap with the bee movie script yet /s

... wait do we already have the bee movie script on chain?

I try to stay realistic. If I can say: "These transactions here are done by app x", or "done by service x", how big a dent this makes into privacy? If everything *else* is in order, and that's the *only* problem

We have a ton of stuff already. I believe someone uploaded the full ZtM PDF

And the trade-off with making every tx say 100 bytes bigger than today, because uniformity

rbrunner: I think it depends on the proportion of transactions that have the uniformity defect and how persistently it shows up in the txs, i.e. does the defect appear each and every time the service creates the tx?

I rise you this classic: xkcd.com/538 The attack, if and when it comes, does not break in through tx_extra non-uniformity, I believe

The main issue is they take up a decoy slot from what I understand

On the one hand, if there are very few txs that have a defect, then tracing is almost guaranteed. Yet it affects a very small proportion of users, so it would maybe be negligible. If so 5% of txs have the defect, then the txs would be less traceable but it would be affecting a much larger share of users

This details the ZtM inclusion

Yeah, that's why I would agree to an uper size limit any day, personally

rbrunner: 255 bytes was my initial proposal :D

Which is something else entirely than dropping it outright and driving people "underground" and making each and every tx bigger than today

I'd say if the defect were in exactly 50% of transactions, then effective ring size would be about cut in half.

For uniformity

But when that was contested on uniformity and we discussed removal, I suggested a uniform option

Which wasn't adding a quarter kb to EVERY TX when only a fraction legitimately use it

Tbc, 255 just means we can use a single byte to encode its length while being sufficiently comprehensive

Maybe we should not worry too much and enjoy the nice weather because I don't see a new consensus arrive here anytime soon. My prediction is tx_extra will stay as it is, our little variant of Bitcoins block size limit :)

<Rucknium[m]> "I'd say if the defect were in..." <- ^ This conclusion may be too sweeping. I would say that txs with change outputs would be easier to trace.

And the "fake" change output mitigate the issue. Not sure to what extent. Anyway, the effect of defects in tx uniformity is an an area of active research.

<kayabanerve[m]> "... wait do we already have..." <- you bet :D paste.debian.net/plainh/deb2f33d

how about a video? paste.debian.net/plainh/a8b024f8

tx_extra is a pr nightmare waiting to happen

sooner or later it will be abused for illegal material

it is too cheap to store content on the blockchain forever

<tx_extra[m]> "you bet :D paste.debian..." <- Thank you <3

If we're against the computational requirements, I suggest 255b limited extra, as we know it, purely arb with no official connotation, potentially with a weight multiplier.

So yes, you can add messages, but they cost 2x. Please note the weight cannot exceed the cost of steganography

So 2x is probably all we can reasonably discuss...

what about an exponential cost on the tx extra?

whats the "computational requirements"?

computers get faster. trails of breadcrumbs are on the chain forever.

<UkoeHB> "what about an exponential cost..." <- > cannot exceed the cost of steganography

<gingeropolous> "whats the "computational..." <- Everyone has additional outputs to scan and we have to verify the bps

They are aggregated bps, great, but they're not perfect. When the amount of outputs exceeds the next power of two, additional cost is added, and that cost applies to all proofs in the batch.

So if we discuss ~80 bytes per output, it'd be +3 to get close to 256. For a 2 output base, we exceed 2^1 and 2^2 and move the entire block to 2^3

just sprinkle some more optimizations on there

besides, as you said, it's not possible to prevent this steganography from happening. so if we leave tx_extra open, and people naturally gravitate to the mechanism providing greater privacy, then all we've done is left tx_extra open *and* added computational bloat

i think the effect would have been greater in this order: then all we've done is added computational bloat *and* kept tx_extra open