17:02:45 Meeting in 1 hour 18:00:01 Meeting time. Hello! https://github.com/monero-project/meta/issues/1241 18:00:09 hi 18:00:12 *waves* 18:00:14 hi 18:01:30 On to the reports from last week already! 18:02:24 mainly testing and bug fixes related to `[en/de]crypt_keys()` 18:02:31 In the Wallet API we default wallet2s `m_unattended = true` (src: [last argument here]](https://github.com/monero-project/monero/blob/fbc242d52d89d9c8021194cd4faae657c94d5a31/src/wallet/api/wallet.cpp#L438), [wallet2 constructor](https://github.com/monero-project/monero/blob/fbc242d52d89d9c8021194cd4faae657c94d5a31/src/wallet/wallet2.cpp#L1188)), so for the CLI I added `bool unatt ended = true` as optional argument to `WalletImpl()`. 18:02:35 From reading the backlog I see that kaya had fun with optimizations 18:03:10 and "m_wallet" 288 times left 18:03:38 You have to ask Ruck for a nice plot, and an estimate when you will hit zero :) 18:04:30 lol, probably will have some tail emission because of bugs 18:05:26 me: opened PR's from the contest to the fcmp-plus-plus repo, leder's helioselene is merged in and kayaba has been improving on top of it. fabrizio's divisors currently has an internal test failure fabrizio is continuing to help out with (it won't impact their contest payout). Handled compiler warnings for fcmp++/carrot with some help from jeffro too, set up core tests testing cons tructing a FCMP++/Carrot tx spending from a pre-rct tx., tests went smooth. I also continued on PoWER (proof-of-work enabled relay) setting up a design doc 18:06:06 Still working on the latter design doc, but mostly just drafting what we discussed in a past MRL meeting 18:06:22 Did you come up with *PoWER* as an acronym? 18:06:37 that was actually @SyntheticBird 18:06:44 Ah, ok 18:06:51 good name 18:07:11 Yeah, has the potential to go even beyond Monero, I would say 18:07:43 Yep agreed 18:08:47 If we are through with the reports, I have a question that I think you will be able to answer 18:09:19 On Reddit there was a mention about "offline transactions" for Monero, as a hypothetical possibility 18:09:52 Taken literally, I would that means that a wallet builds a Monero transaction all on its own, without connection to any daemon 18:10:10 I am pretty sure that's not viable to do properly with our current protocols 18:10:48 Sure, you could grab some transactions as decoys and store them somewhere for later tx building, but the distribution would of course be off 18:10:57 So now my question: How will that look with FCMP++? 18:13:04 Before: the ring signature *signs* the decoys selected in the transaction, i.e. you need a spend key, your prior outputs you want to spend in the next tx, and decoys to construct a signed tx ready for submission to the network. Decoys require a connection to a daemon to select. You *could* select decoys at an early point in time and then sit on them, although yes this causes your tx to stick out because your decoys would be "old" 18:16:31 After FCMP++/Carrot: we "sign" the components necessary to authorize a set of outputs you want to spend (spend key and prior outputs are necessary for this), and separately, construct the membership proof (which only needs the output path in the tree). You can "sign" with spend key at a point in time A, and then at a later point in time B, construct the membership proof and tack it onto the tx without the spend key. The "output path in the tree" requires a connection to the daemon to determine its latest state 18:16:45 Some txs have actually done this "cached ring members" behavior. Nonstandard and very bad for privacy, of course. 18:17:39 I have a TODO on our TODO list to more clearly document the design decisions necessary to achieve this 18:17:41 maybe there should be a way to expire transactions 18:18:03 > The "output path in the tree" requires a connection to the daemon to determine its latest state 18:18:26 I can't do that with an old state of the trees that I downloaded from a daemon while still connected earlier? 18:19:13 Spending is one way to expire txs, although ya, a way to prevent a future tx from being able to be spent after a certain point without requiring an on-hcain tx is interesting (and I believe is part of the idea behind LN's HTLC's IIRC) 18:20:16 You can, but if you use an old path, your tx would stick out as referencing an older state of the tree (tx's include a "referenceBlock" which is the block idx used to construct the path and refers to the state of the tree when that block is tip) 18:20:36 Most txs would include the current chain tip when they enter the pool 18:21:31 And well, won't there be "gaps in the proof", so to say, for the time between the cached tree state and the tree state at time of tx submission? What if somebody manages to spend one of the enotes just in this time intervall? 18:22:32 Ya it's possible that some txs will honestly reference an older block than chain tip by the time they hit the chain tip 18:22:35 on solana you have to fetch a recent blockhash and sign the transaction against it. so by default it will expire in a minute or so. to sign transactions offline there is a method they call durable nounces. (it comes with caveats and UX pitfalls, that can lead to transactions looking like they were invalid, but still going through later on) 18:22:39 by the time they hit the chain* 18:22:42 Maybe I mix now membership proofs and double-spend protection 18:24:15 Interesting 18:24:47 The legit case of pointing to an older tree tip, or however you call this, is probably multisig transactions? 18:25:12 yes and dealing with hardware wallets 18:26:35 Neither multisig nor hw wallets are expected to be different from normal txs. For multisig, you have multisig participants do the signing, and then once the tx is signed and ready, just have one participant (the submitter) construct and tack on the membership proof righr before submitting 18:26:57 would it be an option to make it the default to reject transaction that reference an older one at the pool / node level? 18:27:25 For hw wallets, hw wallet signs, then online wallet with view/ful lbalance key constructs the membership proof right before submitting the tx 18:27:28 would it be an option to make it the default to reject transactions that reference an older one at the pool / node level? 18:29:03 Yes, theoretically could do that sort of thing for ring sigs too. Might have downstream unintended negative consequences / UX pains that some might not expect (even though they're doing an anti-pattern) 18:29:32 Say again, what exactly do you need for building the membership proof? Any secrets? 18:29:48 Ah, you mention the view/full balance key there 18:30:20 Howdy sorry I'm late 18:30:41 howdy 18:30:45 You need the output path in the tree (and technically you need matching blinds to SAL signature too). Sorry, we'll have clearer docs on it 18:30:55 Alright :) 18:31:10 You don't need the full balance key , but you do reveal which inputs you're spending to the prover 18:31:13 Main point is you don't need the spend key 18:31:29 For the memberhsp proof 18:32:18 Ah, that would be the compromise if anybody had the idea to "outsource" proof construction to some third-party, to be able to work offline for tx construction itself 18:32:38 BTW, the hot/cold wallet code I'm working on at the moment will support exactly this scheme of "sign now, compete later" 18:33:01 btw is there work on accumulating this similar to the scaling work by ebfull ? ... maybe you saw the effort posts in the community workgroup recently .,.. 18:33:43 personally not familiar with ebfull's effort there, got a link? 18:34:11 https://seanbowe.com/blog/tachyaction-at-a-distance/ 18:34:13 that was actually not me 18:34:45 at least i don't remember 18:34:47 whoops, I thought "POWER" was you in the MRL meeting that day 18:35:43 Ah, I'm familiar with tachyon but I guess I'm not sure what you mean regarding its relationship to the above 18:36:19 Oh, that "Tachyon" thing that may develop into the new "Zcash is better than Monero because X" argument 18:37:07 I see what you're getting at a bit, reading this now 18:37:22 At first glance, it looks interesting, even for a crypto noob like me. Maybe it really is interesting and novel. 18:37:26 (@spirobel) 18:37:29 Zcash actually will still have one theoretical privacy benefit over Monero after FCMP++: the transaction input/output counts are hidden 18:38:45 Well, there is always something, right 18:39:24 They are hidden? 18:39:53 Yes they are now AFAIK , regardless of Tachyon 18:41:27 https://forum.zcashcommunity.com/t/are-numbers-of-shielded-inputs-and-outputs-hidden-in-pre-sapling-versions-of-zcash/43758 18:41:27 > Orchard merged spend and output proofs back together for performance reasons, which means each Action corresponds to 1-in 1-out. It is therefore more similar to Sprout again, in that if you create a 1-in 5-out Orchard transaction, the network can’t distinguish it from a 5-in 1-out Orchard transaction. 18:41:35 Maybe semi-hidden 18:42:12 Regarding accumulating proofs into one single proof for many proofs, @kayabanerve wrote this up a while back and can probably speak to further effort/focus on this front as it relates to FCMP++: https://github.com/monero-project/research-lab/issues/110 18:42:57 If we had dummy inputs w/ FCMP++, then we more or less can achieve parity , especially if >= 2 input count is enforced by consensus 18:43:44 That issue is mentioning Seraphis quite a lot ... 18:44:01 But maybe it transfers to current FCMP++ 18:44:22 One of my immediate comments on Tachyon is the comparison to tevador's proposal for off-chain communication of output recipience. 18:45:32 jeffro256: No, they aren't. They reveal how many 'actions' are in an Orchard bundle, each action representing one input and one output, both either potentially unused. 18:46:11 So you learn the max(inputs.len(), outputs.len()) due to the lack of explicit padding. 18:46:55 Still a bit less than with the explicite numbers of FCMP++? 18:47:49 Correct, their methodology isn't amenable to our current modular design and we should distinctly employ dummy inputs and then add a consensus rule for the amount of ins/outs. 18:49:13 Yes, thank you for clarifying . You learn a possible number combinations , but its not guaranteed in all cases (except perhaps in 1-in, 1-out? Unless they ban that case) 18:50:05 But with FCMP++ as-is, if you only own one enote, you can only ever create a 1-in tx 18:50:52 I support this as long as dummies can be done semi-performantly 18:51:49 We will see how people will think about dummies and the still-larger tx sizes they would bring after the network digested the considerable jump in tx size for FCMP++ as planned now 18:51:51 tevador proposed a trivial solution: each input tuple is extended with a key. We ad-hoc extend the tree with that key and do the FCMP proof off the extended tree. 18:52:47 We don't have to communicate an amount commitment (we can just use `1G + 0H`) and the key image generator would still be `H(O)`. This also prevents burning another user's outputs (as the key image generator binds to the private spend key as well). 18:53:19 So it's trivially cheap. The issue is ad-hoc extending trees _including arbitrary historical trees_. 18:54:13 We'd have to be able to efficiently pull up the entire edge for any historical height, and perform a tree grow with every TX verification. While it's only adding a single leaf, it's still ~8 scalar multiplications _outside of the multiexp_. 18:54:41 Ugh. Depends on if we save the intermediates and can solely delta hash or not. 18:55:02 I do support that upgrade. i'm just noting jberman will be annoyed. 18:55:14 As jberman is not me, and as we love privacy, I fully support it. 18:55:15 :p 18:55:35 Ah I see. This also has the "downside" that you can't create more dummies than enotes you own, yeah? Which doing so is of questionable utility , but... 18:55:46 No? 18:56:24 Even someone with no inputs on-chain would be able to produce fully valid FCMPs for no amount. If we accepted 0-fee TXs, people without any Monero could get full TXs on-chain. 18:56:59 That sounds funny 18:57:11 @SyntheticBird good news!!! https://libera.monerologs.net/monero-research-lab/20250430#c522744 18:57:50 Oh you're saying add a key at time of input alongside the rerandomized input ? Not provide it when adding outputs to the tree ? 18:58:01 rbrunner7: Inability to distinguish a real input from a dummy input implies inability to distinguish if a TX has any real inputs or is entirely dummies 18:58:05 Let's go. Thanks for reminding 18:58:18 jeffro256: Correct. "each input tuple is extended" 18:58:56 Yeah, makes sense, only dummies would be trivially possible. 18:59:30 Well, they wouldn't be able to pay a fee :) So it would require no-fee TXs be allowed. I assume they technically are right now? But I would have to check. 19:00:26 Maybe no relay, but tx would be valid, so you have to find somebody who mines it? 19:01:01 correct, sech1 could confirm 19:01:06 Presumably but boog900 would know better than me, and I don't care to find the relevant rules myself right now 19:01:11 Yeah if Helios-Selene is fast, then doing an extra right-hand-side hash grow might not be so bad. Do you know off the top of your head about how many scalar-point multiplications are done for FCMP verification for a 1-in, 7-layer right now? 19:02:09 510 in a multiexp for the FCMP alone? 19:03:10 Okay so ~2% slower ? 19:03:13 an extra 8 sounds fine to me 19:03:36 "in a multiexp" is the key-word. They're probably only as expensive as 300 individual point multiplications. Tree growing would be 8 scalar muls + 8 point compressions (in effect), where one point compression is several times more expensive than a traditional multiplication. It'd also probably re-instate performant random reads as a requirement to run a Monero node. 19:04:06 Thanks I hate it 19:04:15 How much worse are point compressions again? 19:04:48 You could remove the random read requirement by caching the right edge , which I think we already do in the current DB impl 19:04:56 We just ran extensive benchmarks on this 19:05:09 jeffro256: We support arbitrary historical trees, so no, we can't. 19:05:10 Lol 19:05:14 We can just optimize for the popular case. 19:05:57 So probably 3% slower before we discuss the impact caused by point compressions. 19:06:07 No I mean we cache the right edge for all historical FCMP trees to handle rollbacks 19:06:15 We do do this^ 19:06:26 ... but we'd still randomly read them. 19:06:44 Random reads per tx sounds a lot better than random reads per ring member to be fair 19:07:00 There's no practical distinction between randomly reading the RingCT out DB and the historical tree edge DB other than quantity. 19:07:21 That argument can even be made for historical tree root hashes, those are just soooo smalllllll 19:07:45 Anyways, I support it as a post-FCMP++ hardfork, y'all can figure out the implementation details. 19:07:49 Oh yeah well I mean its just as many random reads as pulling just the FCMP root, but yeah its more data, which may have a concrete effect 19:08:24 The bigger topic is if we plan to do that, we should keep in mind now how we _plan_ to enforce an IO count under consensus, which means we should start a migration path now. 19:08:32 There is a difference for rings in that the number of jumps around in memory space is higher for rings 19:08:44 Sorry, have to leave now, but I will come back later and pack the whole rest of the discussion into the log. Thanks for attending everybody, read you again next week! 19:08:59 One way we can start migrating now: Limit all TXs to 8 inputs and force people who weren't ready for that (people who were unprepared for life and how it occurs) to handle it. 19:09:37 I'll take my leave now before I start getting hate mail again :p 19:09:55 Lol 19:09:57 thanks everyone, very interesting meeting 19:10:45 if state is accumulated later similar to tachy action it shouldnt be a big deal in any case 19:11:22 Thanks everybody ! 19:43:48 Learned a lot today, really interesting meeting 20:05:14 no-fee tx are valid, but they can't be broadcasted in a normal way. There is a min fee for a tx to be added to mempool (and broadcasted after) 20:05:32 But you can mine them yourself using a modified Monero node.