<e​longated:matrix.org> Does fcmp++ allow spending if unconfirmed outputs ?

<e​longated:matrix.org> Does fcmp++ allow spending of unconfirmed outputs ?

<j​effro256:monero.social> It allows one to sign a transaction spending an unconfirmed output and do membership proofs at a later step , yes

<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

<j​effro256:monero.social> But FCMP++ breaks it into 2 separate steps which means the signer doesn't need to care about chain context

<r​ottenwheel:unredacted.org> what is this bozo on about? 🤔 primal.net/e/nevent1qqsx4frs6qkpdpz…swr0xqcuqvx4luf5r7sxf0vvegj6s888zl9

<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

<s​pirobel:kernal.eu> xmrchain.net/search?value=b2cac8247…4f6ea2a48c63955b18c870bb581397d59eb he doesn't understand stealth addresses i think

<s​pirobel:kernal.eu> matrix.monero.social/_matrix/media/…/kernal.eu/DvpljBDdJrdNvinkcQcCUPgG

<s​pirobel:kernal.eu> sent him an explanatory video and welcomed him to the community 🫡 x.com/spirobel/status/1930985317399699556

<e​longated:matrix.org> So can we remove 10block confirmation needed currently with ringct ?

<j​effro256:monero.social> No

<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

<s​yntheticbird:monero.social> there are privacy concerns when it comes to reorg ?

<e​longated:matrix.org> Any research on removing or reducing it 3/4 blocks at least to increase velocity ?

<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.

<s​yntheticbird:monero.social> iirc the MRL issue the deepest reorg was 7 blocks

<s​yntheticbird:monero.social> monero-project/research-lab #102#issuecomment-1129711324

<s​yntheticbird:monero.social> nevermind

<s​yntheticbird:monero.social> 3 blocks deep

<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 ;)

<j​effro256:monero.social> Actually even then, I think the vast majority of people are running nodes with checkpoints on so that's impossible

<j​effro256:monero.social> But it's good enough to rollback to the last checkpoint if you want >99% confidence

<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.

<s​yntheticbird:monero.social> I feel like that's a side quest for Rucknium

<j​effro256:monero.social> I mean.... monero-project/research-lab #102#issuecomment-2402750881

<j​effro256:monero.social> Look at "strategy 2"

<j​effro256:monero.social> Then you would just convert "duration of possessed hashpower" into $$$ based on the market rate of general-purpose compute power

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?

so its this right?

so i guess its this:

or is there other code i can also read about it?

<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: github.com/seraphis-migration/monero/tree/fcmp%2B%2B-stage

<j​effro256:monero.social> This directory in the fcmp++-stage branch contains a lot of usage of FCMP++: github.com/seraphis-migration/moner…o/tree/fcmp%2B%2B-stage/src/fcmp_pp

<j​effro256:monero.social> This method in `BlockchainLMDB` does a lot of the FCMP tree building business logic: github.com/seraphis-migration/moner…lockchain_db/lmdb/db_lmdb.cpp#L1426

<j​effro256:monero.social> This directory contains Carrot crypto code: github.com/seraphis-migration/moner…ee/fcmp%2B%2B-stage/src/carrot_core

<j​effro256:monero.social> This "tree cache" is how wallets keep track of the FCMP tree on the client side: github.com/seraphis-migration/moner…B%2B-stage/src/fcmp_pp/tree_cache.h

I have so far build curve trees in mathematica code (.nb), but was bumping on the r1cs part. Thanks for your answers

<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

my hope was to throw ai at it and expectfor it to be so self contained and minimal that i would understand it

<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

<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

another thing jeffro256, since you helped to recognize that tagged keys thing in the past for me in the mining pool 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

"invalid blob something i dont know

so i just reverted the changes and am still running the version 18.3.4 monerod

(in the case a single look from your side says again ah thats it ;)

ok

thx

<j​effro256:monero.social> Do you have the real error message? Might be a different error ...

i dont have the error message, i know that the following line was being thrown :

if you compile 18.4 version and that pool against it

and xmrig miner pulling templates from the same monerod, then it says that the block templates "blob" is invalid

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.

blockhashing_blob - string; Blob on which to try to find a valid nonce.

"like they both are called blobs, same to me ?"

<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

<j​effro256:monero.social> IDK why that point in the code would fail specifically

wow learned something today ;)

and the blocktemplate blob is just = {txid1, txid2, txid3, ... txidn} ? where is this specified beyond blob for a monerian?

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

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.

<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

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

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?

which then throws that error? sending that error to the hasher ie xmrig.

:D

i remember it was this error : XMR_MISMATCH_ERROR = -6