01:56:31 <m-relay> <e​longated:matrix.org> Does fcmp++ allow spending if unconfirmed outputs ?
01:57:49 <m-relay> <e​longated:matrix.org> Does fcmp++ allow spending of unconfirmed outputs ?
12:39:26 <m-relay> <j​effro256:monero.social> It allows one to sign a transaction spending an unconfirmed output and do membership proofs at a later step , yes
12:40:23 <m-relay> <j​effro256:monero.social> You can technically spend an unconfirmed output in RingCT if you guess exactly which decoys are going to be where in the chain in the future lol
12:41:08 <m-relay> <j​effro256:monero.social> But FCMP++ breaks it into 2 separate steps which means the signer doesn't need to care about chain context
13:08:48 <m-relay> <r​ottenwheel:unredacted.org> what is this bozo on about? 🤔 https://primal.net/e/nevent1qqsx4frs6qkpdpzxf0yflfqt89swr0xqcuqvx4luf5r7sxf0vvegj6s888zl9
13:32:46 <m-relay> <v​tnerd:monero.social> Looks like he used the view key to prove that you can see incoming transactions? It's basically just pure dribble
13:35:34 <m-relay> <s​pirobel:kernal.eu> https://xmrchain.net/search?value=b2cac8247451cfb4f666c3b10f5da4f6ea2a48c63955b18c870bb581397d59eb he doesn't understand stealth addresses i think
13:35:38 <m-relay> <s​pirobel:kernal.eu> https://matrix.monero.social/_matrix/media/v1/download/kernal.eu/DvpljBDdJrdNvinkcQcCUPgG
13:50:37 <m-relay> <s​pirobel:kernal.eu> sent him an explanatory video and welcomed him to the community  🫡  https://x.com/spirobel/status/1930985317399699556
14:28:09 <m-relay> <e​longated:matrix.org> So can we remove 10block confirmation needed currently with ringct ?
14:32:02 <m-relay> <j​effro256:monero.social> No
14:34:32 <m-relay> <j​effro256:monero.social> The 10-block lock has nothing to do with transaction chaining or detached signing. It has to do with chainstate stability, protection against reorg privacy attacks, and DoS attacks
14:35:19 <m-relay> <s​yntheticbird:monero.social> there are privacy concerns when it comes to reorg ?
14:38:32 <m-relay> <e​longated:matrix.org> Any research on removing or reducing it 3/4 blocks at least to increase velocity ?
14:38:37 <m-relay> <j​effro256:monero.social> With ring signatures, definitely. Say a reorger thinks that the true spend is output A. The ring also contains members B-P. The reorger could create a new block top with just A and exclude B-P. If a new ring signatures pops up with the same key image containing A and nothing else, then the reorger knows for absolute certain that that key image corresponds with spending output A.
14:39:27 <m-relay> <s​yntheticbird:monero.social> iirc the MRL issue the deepest reorg was 7 blocks
14:40:35 <m-relay> <s​yntheticbird:monero.social> https://github.com/monero-project/research-lab/issues/102#issuecomment-1129711324
14:40:37 <m-relay> <s​yntheticbird:monero.social> nevermind
14:40:39 <m-relay> <s​yntheticbird:monero.social> 3 blocks deep
14:42:27 <m-relay> <j​effro256:monero.social> You can also do this this FCMPs to a lesser extent. To assume the result is usable, you must assume that the output being spent is relatively new, you will never get a 100% accurate result unless you do a >3,200,000 block reorg ;)
14:42:51 <m-relay> <j​effro256:monero.social> Actually even then, I think the vast majority of people are running nodes with checkpoints on so that's impossible
14:43:25 <m-relay> <j​effro256:monero.social> But it's good enough to rollback to the last checkpoint if you want >99% confidence
14:44:50 <m-relay> <j​effro256:monero.social> But the MRL isn't just looking at what reorgs happened in the past by pure happenstance, but also how much $$$ it would cost if an active attacker tried rolling back the chain.
14:45:22 <m-relay> <s​yntheticbird:monero.social> I feel like that's a side quest for Rucknium
14:46:18 <m-relay> <j​effro256:monero.social> I mean.... https://github.com/monero-project/research-lab/issues/102#issuecomment-2402750881
14:46:32 <m-relay> <j​effro256:monero.social> Look at "strategy 2"
14:47:20 <m-relay> <j​effro256:monero.social> Then you would just convert "duration of possessed hashpower" into $$$ based on the market rate of general-purpose compute power
17:56:22 <slave_blocker> where can i read moar about fcmp? Like the most up to date code for monero on the topic? For the purpose of reading it only?
18:07:38 <slave_blocker> so its this right? 
18:07:43 <slave_blocker> https://github.com/kayabaNerve/fcmp-plus-plus
18:11:39 <slave_blocker> so i guess its this: 
18:11:41 <slave_blocker> https://github.com/kayabaNerve/fcmp-plus-plus/tree/develop/crypto/fcmps
18:13:09 <slave_blocker> or is there other code i can also read about it?
18:39:40 <m-relay> <j​effro256:monero.social> Yeah that is the bulk of the FCMP and SA/L cryptographic code. If you want to see FCMP++ integration code and/or Carrot code, you can look here: https://github.com/seraphis-migration/monero/tree/fcmp%2B%2B-stage
18:40:24 <m-relay> <j​effro256:monero.social> This directory in the fcmp++-stage branch contains a lot of usage of FCMP++: https://github.com/seraphis-migration/monero/tree/fcmp%2B%2B-stage/src/fcmp_pp
18:41:20 <m-relay> <j​effro256:monero.social> This method in `BlockchainLMDB` does a lot of the FCMP tree building business logic: https://github.com/seraphis-migration/monero/blob/4f4b1af50661500f21699a154306a6bf83fd84e0/src/blockchain_db/lmdb/db_lmdb.cpp#L1426
18:42:34 <m-relay> <j​effro256:monero.social> This directory contains Carrot crypto code: https://github.com/seraphis-migration/monero/tree/fcmp%2B%2B-stage/src/carrot_core
18:43:30 <m-relay> <j​effro256:monero.social> This "tree cache" is how wallets keep track of the FCMP tree on the client side: https://github.com/seraphis-migration/monero/blob/fcmp%2B%2B-stage/src/fcmp_pp/tree_cache.h
18:43:34 <slave_blocker> I have so far build curve trees in mathematica code (.nb), but was bumping on the r1cs part. Thanks for your answers
18:45:49 <m-relay> <j​effro256:monero.social> Hopefully those are some decent starting points ;) But yeah R1CS stuff is pretty dang tough IMO, but it should all be in that fcmp_plus_plus repo that you linked originally
18:50:07 <slave_blocker> my hope was to throw ai at it and expectfor it to be so self contained and minimal that i would understand it
18:52:30 <m-relay> <j​effro256:monero.social> Lol I wouldn't recommend that route. LLMs are still terrible at explaining cryptography or any higher-level mathematical concepts in my experience. It can give you general gists about the vague ideas of some topics it already is trained for, but it can't input new material and output anything remotely sensible
18:53:17 <m-relay> <j​effro256:monero.social> There's humans around that know about R1CS and there are blogs/videos/textbooks they have posted. I would start there
18:53:23 <slave_blocker> another thing jeffro256, since you helped to recognize that tagged keys thing in the past for me in the mining pool https://github.com/jtgrassie/monero-pool, yesterday i was compiling the last version of monero. Then i compiled that pool against it. Then my miners that are running xmrig using self select were giving errors
18:53:42 <slave_blocker> "invalid blob something i dont know
18:54:12 <slave_blocker> so i just reverted the changes and am still running the version 18.3.4 monerod
18:54:51 <slave_blocker> (in the case a single look from your side says again ah thats it ;)
18:55:19 <slave_blocker> ok
18:55:21 <slave_blocker> thx
18:57:45 <m-relay> <j​effro256:monero.social> Do you have the real error message? Might be a different error ...
19:00:18 <slave_blocker> i dont have the error message, i know that the following line was being thrown : 
19:00:20 <slave_blocker> https://github.com/jtgrassie/monero-pool/blob/master/src/pool.c#L1369
19:00:55 <slave_blocker> if you compile 18.4 version and that pool against it
19:01:35 <slave_blocker> and xmrig miner pulling templates from the same monerod, then it says that the block templates "blob" is invalid
19:03:19 <slave_blocker> also when using the rpc call, getblocktemplate, where do i find a description on what these two things are exactly : blocktemplate_blob - string; Blob on which to try to mine a new block.
19:03:20 <slave_blocker> blockhashing_blob - string; Blob on which to try to find a valid nonce.
19:03:59 <slave_blocker> "like they both are called blobs, same to me ?"
19:11:05 <m-relay> <j​effro256:monero.social> The "block hashing blob" is basically a compressed version of the blocktemplate_blob. All you need to verify PoW is the "block hashing blob" which can be around 64 bytes. But to actually construct a miner transaction to yourself and compress down to the "block hashing blob", you need the "block template" first
19:11:30 <m-relay> <j​effro256:monero.social> IDK why that point in the code would fail specifically
19:16:22 <slave_blocker> wow learned something today ;)
19:17:27 <slave_blocker> and the blocktemplate blob is just = {txid1, txid2, txid3, ... txidn} ? where is this specified beyond blob for a monerian?
19:23:01 <slave_blocker> https://github.com/jtgrassie/monero-pool/blob/master/src/pool.c#L1369, this line in the code is called not thrown perhaps i mispoke there, the blocktemplate blob fails somewhere dont know what
19:38:41 <slave_blocker> https://rfc.tari.com/RFC-0132_Merge_Mining_Monero
19:39:12 <slave_blocker> This returns a blocktemplate_blob, that is, a serialized Monero block containing the Monero block header, coinbase and a list of hashes referencing the transactions included in the block. Additionally, a blockhashing_blob is a fixed size blob containing serialized_monero_header, merkle_tree_root and txn_count concatenated together. 
19:45:30 <m-relay> <j​effro256:monero.social> I'm pretty sure the code you linked is just a general-purpose error-handling function that is used to report all errors
20:12:54 <slave_blocker> hum i would bet on some major minor version thingy of the block header. so the block template blob is being rejected by the pool
20:14:37 <slave_blocker> wich is fetched by the xmrig software first from the monerod, perhaps since its a point release, there is this issue where a new major version is set in the serialized version of the block, wich is then not accepted by the pool?
20:15:05 <slave_blocker> which then throws that error? sending that error to the hasher ie xmrig.
20:15:10 <slave_blocker> :D
20:31:51 <slave_blocker> i remember it was this error :     XMR_MISMATCH_ERROR   = -6