14:55:14 <UkoeHB> meeting 2hr
17:00:17 <kayabanerve[m]> Greetings, everyone :)
17:01:23 <rbrunner> Hello
17:01:43 <Rucknium[m]> Hi
17:01:49 <dangerousfreedom> Hello
17:02:08 <ArticMine[m]> Hi
17:02:28 <jberman[m]> hello
17:02:46 <UkoeHB> oh hi meeting time lol 
17:03:08 <UkoeHB> here's the agenda: https://github.com/monero-project/meta/issues/722
17:03:40 <UkoeHB> 2. updates, what has everyone been working on?
17:04:31 <UkoeHB> me: I've been updating my seraphis library to support scanning for legacy enotes.
17:05:01 <UkoeHB> Which is required in order to make a wallet that's independent of wallet2
17:05:02 <Rucknium[m]> Me: OSPEAD
17:05:32 <kayabanerve[m]> 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.
17:05:45 <kayabanerve[m]> *specifically proving, so only half of the problem
17:07:50 <dangerousfreedom> 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
17:07:50 <dangerousfreedom> Scalar). I could not find the exact mapping yet though.
17:09:17 <dangerousfreedom> 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
17:09:32 <dangerousfreedom> kayabanerve: is helping me with that :)
17:09:35 <Rucknium[m]> dangerousfreedom: Referring to the "malleability" issues, what is the approximate date of the most recent transaction that has had this issue?
17:10:39 <dangerousfreedom> Rucknium[m]: So far the last I found is this one:https://xmrchain.net/search?value=e4b7982b081a17892525f1b1d3011ec06a0820cbf451d3a64f8ea998104a753c
17:10:48 <dangerousfreedom> 2018-02-04
17:11:15 <UkoeHB> 3. discussion
17:11:19 <kayabanerve[m]> 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.
17:13:26 <dangerousfreedom> kayabanerve[m]: Yes. I think so. I just didnt find the mapping yet. (Didnt try hard either)
17:14:57 <rbrunner> How did those transactions get mined? Lack of certain tests in the daemon?
17:15:29 <kayabanerve[m]> People specified scalars > l. The daemon didn't care.
17:15:36 <dangerousfreedom> rbrunner: I think so. There were not enough enforcement on the scalars and Points stored in the blockchain
17:15:40 <Rucknium[m]> 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:
17:15:42 <kayabanerve[m]> So that could be phrased as lack of tests, it could be phrased as indifference, or could be phrased as a bug.
17:15:43 <Rucknium[m]> https://forum.zcashcommunity.com/t/warp-sync-a-full-scan-method/39462
17:16:09 <kayabanerve[m]> Isn't Warp Sync syncing in reverse in order to not need to scan old notes you've already spent?
17:17:13 <kayabanerve[m]> Oh. No, sorry. That's a different thing of theirs.
17:17:29 <Rucknium[m]> Warp Sync does more than that.
17:17:35 <kayabanerve[m]> 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.
17:17:48 <kayabanerve[m]> Instead of calculating it for [] and then constantly updating.
17:18:02 <kayabanerve[m]> *and yes, other improvements, yet that's the primary one
17:18:42 <rbrunner> So indeed no inspiration for Monero to get there, probably, because wholly different?
17:19:14 <rbrunner> Don't know much about Merkle trees, but never saw one in Monero :)
17:20:29 <UkoeHB> it's a good reference for if we ever go to a zk proof relying on a merkle tree
17:21:08 <kayabanerve[m]> rbrunner: someone hasn't looked :p
17:21:11 <kayabanerve[m]> we use them in blocks lol
17:21:26 <kayabanerve[m]> but no, we don't use a merkle tree to store output indexes... yet 👀
17:21:38 <kayabanerve[m]> So Warp Sync isn't notably relevant now
17:22:16 <rbrunner> You mean also a chain is a tree?
17:22:57 <kayabanerve[m]> Merkle trees are used all the way back in Bitcoin
17:23:08 <UkoeHB> rbrunner: there's a merkle tree for tx ids in blocks iirc
17:23:12 <kayabanerve[m]> Monero block headers contain a tree root of TXs
17:23:34 <rbrunner> Interesting. Will have a look. Saw blocks as mere linear arrays so far, in my mind.
17:23:51 <kayabanerve[m]> 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.
17:23:55 <UkoeHB> there was actually an ancient bug in the merkle tree code that led to a hardfork to handle a broken block
17:24:22 <sech1> 512 transactions bug
17:24:24 <kayabanerve[m]> 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
17:24:26 <UkoeHB> https://web.getmonero.org/resources/research-lab/pubs/MRL-0002.pdf
17:24:58 <kayabanerve[m]> 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.
17:25:19 <kayabanerve[m]> The difficulty is in a ZK transformation of that proof, hence circuits, yet that does get a bit off topic for now
17:25:31 <kayabanerve[m]> Not that this isn't the place. Just that we've sufficiently discussed merkles :p
17:26:23 <Rucknium[m]> "elaborates upon exactly what the offending blcok did to the network." I can tell they wrote this quickly :)
17:27:27 <Rucknium[m]> 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?
17:27:45 <UkoeHB> that was an 8-day paper lol, not too shabby
17:28:02 <kayabanerve[m]> ... i despise blockchain NTP
17:28:28 <Rucknium[m]> The hypotheses are important since it is good to do a statistical correction based on some understanding of the "data generating process".
17:28:35 <kayabanerve[m]> 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.
17:29:04 <kayabanerve[m]> Timestamps can be out of order because we don't enforce they're sequential, which is an opinionated discussion.
17:29:20 <kayabanerve[m]> So it's whatever your local view on time is. When blocks are mined in close proximity, that drift can be especially notable.
17:29:22 <UkoeHB> Rucknium[m]: the main reason I can think of is unsychronized clocks
17:29:37 <rbrunner> I never saw anything else mentioned.
17:29:55 <kayabanerve[m]> 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
17:29:57 <rbrunner> As I can't remember a reason why somebody would stamp wrongly on purpose
17:30:10 <UkoeHB> kayabanerve[m]: how about you define NTP for us.....
17:30:16 <kayabanerve[m]> Which is relevant when you remember BTC isn't from the last ten years
17:30:31 <Rucknium[m]> I think gingeropolous mentioned a "time warp" attack as a possible motivation by a set of coordinated miners
17:30:31 <kayabanerve[m]> Network Time Protocol
17:30:42 <kayabanerve[m]> It's an actual protocol. Monero has its own NTP... algorithm? though
17:31:00 <kayabanerve[m]> Where it's the median of the last 15 blocks IIRC, which is used for TX timestamp acceptance
17:31:14 <kayabanerve[m]> And then I assume we also require new blocks have a timestamp past the median.
17:31:19 <kayabanerve[m]> *past whatever Monero's clock says it is.
17:31:53 <kayabanerve[m]> I believe it's a median, yet I don't remember off the top of my head.
17:32:36 <kayabanerve[m]> 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.
17:32:42 <Rucknium[m]> 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.)
17:32:50 <kayabanerve[m]> It's just also a 51% attack lowering distribution.
17:32:54 <UkoeHB> kayabanerve[m]: Rucknium[m] asked about block timestamps, not how the difficulty algo works
17:33:18 <kayabanerve[m]> UkoeHB: I'm saying there is no attack based on time manipulation except via difficulty.
17:33:47 <Rucknium[m]> If I understand correctly, there are timestamp rules to "bound" difficulty adjustments, as a consensus rule.
17:33:57 <kayabanerve[m]> My next comment was going to be there are ways you can spike/drop difficulty, mine, then leave and come back.
17:34:48 <kayabanerve[m]> 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
17:34:55 <UkoeHB> kayabanerve[m]: and yet... he is asking about tx timing, not the difficulty algo...
17:34:58 <Rucknium[m]> I suppose one thing I could look for is timestamps that are at the boundary of what the consensus rules would accept
17:35:04 <kayabanerve[m]> I don't see it as an active concern to Monero given our size
17:36:27 <kayabanerve[m]> ... oh. Sorry then.
17:36:37 <Rucknium[m]> 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.
17:37:29 <kayabanerve[m]> 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.
17:37:52 <rbrunner> "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.
17:38:03 <Rucknium[m]> Whatever we used as seeds?
17:38:51 <Rucknium[m]> rbrunner: I expect that the necessary correction would be minor. But it's good to be more precise.
17:38:56 <UkoeHB> Rucknium[m]: we added deterministic unlock_times here, which is probably the best way to estimate each block's timestamp https://github.com/monero-project/monero/pull/6745
17:39:06 <UkoeHB> if you don't trust the block timestamp
17:40:02 <kayabanerve[m]> 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)
17:40:27 <Rucknium[m]> Put another way, human behavior is based on real-life time, not on Monero's "NTP". So having the real life time is important.
17:40:30 <kayabanerve[m]> I'm not even sure we have "seed nodes" versus a list of nodes usable as seeds, which would be my assumption...
17:41:59 <Rucknium[m]> 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. 
17:42:32 <Rucknium[m]> Would anyone have those logs though?
17:43:12 <Rucknium[m]> 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.
17:43:44 <Rucknium[m]> https://github.com/neptuneresearch/monerod-archive
17:46:24 <UkoeHB> any other topics to discuss in this meeting?
17:46:32 <UkoeHB> there has been some discussion about the tx_extra...
17:46:45 <UkoeHB> I felt sgp_'s response was reasonble
17:47:16 <sgp[m]> <3
17:48:08 <Rucknium[m]> This, right? https://github.com/monero-project/monero/issues/6668
17:48:17 <UkoeHB> yeah
17:49:48 <rbrunner> You mean some more recent discussion :)
17:50:28 <Rucknium[m]> 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.
17:50:37 <ArticMine[m]> The toxic content attack 
17:51:07 <rbrunner> With a break since start of May until recently
17:51:25 <kayabaNerve> I personally most prefer steganography
17:51:27 <rbrunner> Oh, May last year :)
17:51:32 <ArticMine[m]> Allowing it only for miners is reasonable 
17:51:52 <kayabaNerve> Encrypted steganography would be completely indistinguishable, maintaining privacy.
17:51:52 <sgp[m]> what do you mean by allow?
17:52:16 <ArticMine[m]> Only for coinbase 
17:52:25 <ArticMine[m]> Tx extra 
17:52:45 <kayabaNerve> 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.
17:53:22 <kayabaNerve> 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
17:53:28 <sgp[m]> steganography seems.... prone to mistakes
17:54:02 <kayabaNerve> we can specify a protocol and a reference
17:54:12 <sgp[m]> for reference, the encrypted memo for zcash is 512 bytes, which seems super long
17:54:22 <kayabaNerve> Also, ArticMine[m], do you have any reason to allow it in coinbase? Merge mining, I'd guess?
17:54:50 <UkoeHB> sgp[m]: do they have much larger txs? maybe it's proportionally small
17:54:58 <kayabaNerve> For most uses case, 128 should be enough. I noted a case relevant to Monero when you'd want 256 though
17:55:47 <kayabaNerve> (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)
17:55:58 <ArticMine[m]> Merge mining 
17:55:58 <xmrack[m]> 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.
17:59:11 <ArticMine[m]> I see tx_extra as a possible attack vector 
18:00:59 <UkoeHB> ok we are at the end of the hour so I'll call it here; thanks for attending everyone
18:01:17 <Rucknium[m]> Some research on using XMR txs to send messages:
18:01:17 <Rucknium[m]> https://moneroresearch.info/index.php?action=resource_RESOURCEVIEW_CORE&id=33
18:01:40 <Rucknium[m]> Guo, Z., Shi, L., Xu, M., & Yin, H. (2021). MRCC: A practical covert channel over Monero with provable security
18:01:50 <Rucknium[m]> I believe they do not use tx_extra
18:03:39 <kayabanerve[m]> They embed it I'm the ring signatures
18:04:01 <kayabanerve[m]> We'll never stop messages. The sole question if we prefer storage, computation, or transaction quantity.
18:04:06 <gingeropolous> 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..
18:04:10 <rbrunner> This valid EC point from tevador on the GitHub issue is an instant classic: Hex: 5468697320697320612076616c6964206564323535313920706f696e742e2e2e  ASCII: This is a valid ed25519 point...
18:05:01 <kayabanerve[m]> Steganography in outputs, my preference, is computationally expensive while being less efficient as storage yet uniform.
18:05:08 <gingeropolous> i lean towards having some sort of thing, but its uniform. i.e., all txs have one, but most of them are just dummies
18:05:14 <kayabanerve[m]> Tx extra is solely storage
18:05:37 <gingeropolous> im tryin to find a good understanding of your steganography thing here
18:05:45 <kayabanerve[m]> Ring signatures and change outputs, if we ever limit to just 2, requires multiple transactions
18:05:56 <kayabanerve[m]> gingeropolous: Every output lets you specify two keys, R and K
18:06:05 <kayabanerve[m]> You can safely get 30 bytes from each
18:06:23 <kayabanerve[m]> So every added output gives you 60. There's also the view tag and enc amount 
18:06:58 <kayabanerve[m]> You can further improve it by encrypting it before hand. Then it'll be uniform and won't be distinguishable
18:07:27 <gingeropolous> ah ok. so the new outputs end up being the data, instead of there be some data space available in a tx
18:07:44 <kayabanerve[m]> 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
18:08:08 <kayabanerve[m]> It is 3-4 output txs though. Those aren't the most common
18:08:12 <kayabanerve[m]> So that is still notable
18:08:24 <rbrunner> So, in other words, systematic abuse of outputs? Makes me shudder, to be honest.
18:08:31 <kayabanerve[m]> You can also use clsag signature responses, ring public keys...
18:08:57 <kayabanerve[m]> 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
18:09:17 <kayabanerve[m]> *ignoring output quantity, assuming sane implementation
18:09:24 <rbrunner> Yes, I think I see, but I can't come around yet to like that tradeoff
18:09:55 <rbrunner> What's next? Completely fake transactions? Just to exagerate a bit.
18:10:27 <kayabanerve[m]> ... we also have keeping tx extra and keeping tx extra with a fixed size
18:10:39 <kayabanerve[m]> Do you want to come around to those instead? :p
18:10:51 <kayabanerve[m]> The question isn't what do we all love. It's what's best for our reality
18:11:10 <kayabanerve[m]> Which is that anyone who wants to do this, will do this, and we can't successfully avoid it.
18:11:23 <Rucknium[m]> rbrunner: Completely fake txs already happened last year :P
18:11:31 <kayabanerve[m]> So what way is optimal for monero
18:11:37 <rbrunner> Yeah, right, that spam attack
18:11:47 <kayabanerve[m]> Rucknium[m]: Clearly you haven't checked for data overlap with the bee movie script yet /s
18:12:39 <kayabanerve[m]> ... wait do we already have the bee movie script on chain?
18:13:00 <rbrunner> 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
18:13:01 <kayabanerve[m]> We have a ton of stuff already. I believe someone uploaded the full ZtM PDF
18:13:36 <rbrunner> And the trade-off with making every tx say 100 bytes bigger than today, because uniformity
18:14:40 <Rucknium[m]> 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?
18:15:40 <rbrunner> I rise you this classic: https://xkcd.com/538/   The attack, if and when it comes, does not break in through tx_extra non-uniformity, I believe
18:16:04 <kayabanerve[m]> The main issue is they take up a decoy slot from what I understand
18:16:15 <Rucknium[m]> 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
18:16:26 <kayabanerve[m]> https://forum.monero.space/d/38-should-we-remove-tx-extra/4
18:16:26 <kayabanerve[m]> This details the ZtM inclusion 
18:17:18 <rbrunner> Yeah, that's why I would agree to an uper size limit any day, personally
18:17:58 <kayabanerve[m]> rbrunner: 255 bytes was my initial proposal :D
18:18:02 <rbrunner> Which is something else entirely than dropping it outright and driving people "underground" and making each and every tx bigger than today
18:18:12 <Rucknium[m]> I'd say if the defect were in exactly 50% of transactions, then effective ring size would be about cut in half.
18:18:13 <rbrunner> For uniformity
18:18:21 <kayabanerve[m]> But when that was contested on uniformity and we discussed removal, I suggested a uniform option
18:18:41 <kayabanerve[m]> Which wasn't adding a quarter kb to EVERY TX when only a fraction legitimately use it
18:20:19 <kayabanerve[m]> Tbc, 255 just means we can use a single byte to encode its length while being sufficiently comprehensive
18:21:06 <rbrunner> 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 :)
18:25:17 <Rucknium[m]> <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.
18:26:38 <Rucknium[m]> 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.
18:56:50 <tx_extra[m]> <kayabanerve[m]> "... wait do we already have..." <- you bet :D https://paste.debian.net/plainh/deb2f33d
19:00:49 <tx_extra[m]> how about a video? https://paste.debian.net/plainh/a8b024f8
19:15:26 <tx_extra[m]> tx_extra is a pr nightmare waiting to happen
19:15:34 <tx_extra[m]> sooner or later it will be abused for illegal material
19:15:41 <tx_extra[m]> it is too cheap to store content on the blockchain forever
21:07:01 <kayabanerve[m]> <tx_extra[m]> "you bet :D https://paste.debian..." <- Thank you <3
21:07:13 <kayabanerve[m]> 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.
21:07:40 <kayabanerve[m]> So yes, you can add messages, but they cost 2x. Please note the weight cannot exceed the cost of steganography 
21:07:57 <kayabanerve[m]> So 2x is probably all we can reasonably discuss...
21:18:48 <UkoeHB> what about an exponential cost on the tx extra?
21:42:26 <gingeropolous> whats the "computational requirements"?
21:43:20 <gingeropolous> computers get faster. trails of breadcrumbs are on the chain forever. 
22:32:06 <kayabanerve[m]> <UkoeHB> "what about an exponential cost..." <- > cannot exceed the cost of steganography 
22:32:41 <kayabanerve[m]> <gingeropolous> "whats the "computational..." <- Everyone has additional outputs to scan and we have to verify the bps
22:38:42 <kayabanerve[m]> 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.
22:39:43 <kayabanerve[m]> 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
23:33:52 <gingeropolous> just sprinkle some more optimizations on there
23:36:38 <gingeropolous> 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
23:42:10 <gingeropolous> 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