Hello, sorry for disturbing the discussion but anyone has a python implementation of the code (current or previous versions) that allows me to verify that there is no inflation bug in the blockchain? My goal is to understand and prove that for every transaction ever occurred there were no xmr created out of nothing using python.

don't think that exists in python

oh u made it from the reddits. i think perhaps pieces of some of the newer stuff (the math parts) exists in python? it's somewhere to start.

There's good stuff in Sarang's Skunkworks repo, like bulletproofs: github.com/SarangNoether/skunkworks/tree/pybullet-plus/pybullet

Clsag: github.com/SarangNoether/skunkworks/blob/clsag/clsag/clsag.py

<jberman[m]> "There's good stuff in Sarang's..." <- Thank you jberman . I believe that is what I was looking for. It would be valuable to reimplement this part of the code in Python.

<selsta> "don't think that exists in..." <- Thank you selsta . Do you believe that there is a specific binding or snippet in C++ that integrates with the blockchain to verify only that the transactions are not generating inflation? I mean to verify that 1+1=2 for every transaction?

Technically there's a piece of code in monerod that does that automatically every time a new block is added to the chain

You can also invoke it manually from inside monerod (though I don't remember the command name, but it's 100% there)

Oh, and I think I remember there was also an external piece of code written that did this exact verification back when the missing ec point check was discovered, and iirc it was published in a repo somewhere

But it was years ago, so it would probably need some updating to include the new tx proofs

Having such a second impl check would be really nice. sarang's code will contain some, but not all, building blocks.

The tool would also have to be updated to deal with, eg, seraphis, in the future, but one step at a time I guess.

<merope> "You can also invoke it manually..." <- Thank you endor00 . I believe it might exist but if there are implementation errors (I doubt that) then using this tool would be biased. My goal is to understand the code using another tool so I can compare my understanding of the code (logic) with another tool and be happy that everything is fine regarding the inflation if the results of both implementations match.

There might be some information about this in "Zero to Monero 2"

<moneromooo> "Having such a second impl..." <- Ok. I will try to work on that. Thanks for the feedback. I will work according my pace and just focus on answering about the inflation stuff. If I achieve something, than I would be happy to share it as educational purposes as I believe that this question disturbs a lot of people :p

I mean, technically this question has already been answered several times - but an extra set of eyes never hurts

merope: Yeah, I read it and I believe that is the best guide. I understand the math behind but I am not an expert. I have some background in cryptography and coding but not much. Lets see how it goes, thanks ;)

Unfortunately a lot of people can't shake off the mistrust in numbers they can't simply add in their heads (even though the very cryptography they use with their private and public keys is just as complex)

merope: Exactly. But that's natural I guess. If you dont boil down things to the point that people can relate and understand then people would mistrust. I do that all the time. In all fields.

<merope> "Unfortunately a lot of people..." <- Even math they can do, sometimes. Ask someome if 0.999... is less than or exactly equal to 1. Show them that it is equal. Give them a month and most have gone back to thinking it is at least a little less than 1. People are funny.

dangerousfreedom: Do you have an outline of what your end product would look like?

i mean i just think a python implemention of monerod would do it

Wouldn't you have to implement both Borromean ring sigs and Bulletproofs verifiers in python?

i think of all the languages its probably the most noob friendly. python plus good comments and that could finally seal the deal on ppl goin "muh verify"

Plus you need MLSAG/CLSAG verifiers in order to check that pseudo-output commitments are valid.

And also to verify there are no double-spends... you'd need to verify all old cryptonote-style signatures.

You basically need the entire verifier to check balance

gingeropolous: I think presentation also matters. It sounds like dangerousfreedom may have some skill there? If he frequently "boils things down".

<UkoeHB> "You basically need the entire..." <- However, I think it can be tackled in bite sized pieces. E.g. merely summing the coinbase transactions. Then checking key images for group order and uniqueness...etc

dangerousfreedom: I am pretty interested to see what you come up with. Please share your progress.

I remember when I was new to monero, most of the stack exchange answers about this were pretty unsatisfying.

yes, you need to be implement all of the old/historical txn formats since the beginning of the blockchain

and you can't just verify up to the hardfork date and checkpoint it there, since old-format outputs can still be spent in contemporary txns.

Cool. I guess that is the discussion I wanted to have and thank you for the comments. It looks like it is worth doing it.

<wernervasquez[m]> "I think presentation also..." <- I mean I like to understand the principles of everything the maximum as I can according to my curiosity. Of course I can't with most things otherwise I wouldn't be able to live in society and enjoy its goods but I do what I can / am interested. My idea is purely educational. I really want to answer this question in a way that I understand it. I do have some skills with

teaching, websites and presenting ideas.

I will work on formulating what should be done and how it should be presented trying to structure tasks and workpackages. I will present you guys next weekend and ask for your feedbacks. Would that be fine?

From a personal point of view, I am really curious and willing to take up to the middle of the year working on that in my free time. I think it would be amazing if I can make a website for example showing the progress of monero and its privacy proving that for all the transactions that ever happened, one can proves that 1+1=2 and no extra xmr was created.

sounds good to me :)

I just want to focus on this particular question and implement it as simple as possible using a dumb language like python as gingeropolous . It suits me :)

said*

UkoeHB: Cool. I will need your feedback for sure.

#monero-dev might be more appropriate as well, though historically -lab has a lot of non research stuff anyway.

I think even a piecemeal approach would be useful (eg, only checking range proofs).

<moneromooo> "I think even a piecemeal..." <- Thank you moneromooo . Yeah, the first task is to figure out how deep I would need to go to answer that. Maybe checking range proofs and the commitments to hide amounts would be easier first (dont know if it would be enough). I am not am expert on all the code and the hardforks that happened but yeah, definitely it is the first question to answer.

You'll have to do something first anyway. So keeping a (growing) list of what you've done so far will be enough to be valuable in its own right, ie: "X and Y were checked by an independent implementation". Then you can add Z later.

I'd start with something easy so you get encouragement from getting somehting that works fairly quick :)

Yeah, I think so too. Thanks :)

I was planning on starting chronologically. I believe that when the code was released there were no ring signatures right? So there I would only need to check the range proofs, right?

Whatever order you prefer's fine of course. Ring signatures were there from the start. There were no range proofs at the start.

I am just thinking about starting from the beginning of the code and also give some importance on the presentation. If I can do that for next week than I believe I can continue with the rest of the code step by step.

The thing that get people nervous are ringct things though. With pre-ringct ring sigs, you still see amounts and can add them yourself.

moneromooo: Ah okay, only the commitments? The amounts were hidden from the beginning, right?

Amounts were not hidden, though coins were mostly split by standard amounts (ie, 9743.3 was 9000 + 700 + 40 + 3 + .3)

So you could not quite tell how much was sent due to the combinatorics (if that's a word), but you can still sum ins and outs.

Okay. I will start from the beginning, I want to understand what was happening and I dont even know haha. So there were no ringct and the amounts were not hidden but you could not tell how much someone sent, right? So there were some kind of mixing the inputs and outputs?

I believe that for my purpose it would be enough to tell that a transaction did not generate any new xmr. It seems it would be easy for the beginning of the blockchain.

There were ring rigs (for inputs).

To start with there were optional ring signatures and no hidden amounts (you could select a ring size of 1)

Good video by Justin and Sarang on bulletproofs

* youtu.be/6lEWqIMLzUU

Good video by Justin and Sarang on bulletproofs.

Answers a few questions

The amount sent was only hidden in the sense that if there was a ring signature you couldn't be sure which of the visible amounts was being spent

> <@w:monero.social> youtu.be/6lEWqIMLzUU... (full message at libera.ems.host/_matrix/media/r0/do…94f4f336fdcaccd558d30541e63ab9983fb)

You could have a ringsize=1 though? Or I guess that still counts as having ring sigs

Ok, I see. There were always ring signatures but they were not confidential.

You can't tell amounts in hte general case because it's like this if you send 3 monero: ins [2, 0.5, 5], outs [3, 4, 0.5] (ignoring fee for the sake of argument).

So you could have sent 3, 4, 3.5, 4.5, 7 or 7.5. Or 0.5.

Well, not 0.5 since you'd have end up with [0.5, 7] unless you modified the code.

And not 7 either for the same reason.

And maybe not some others, but you get the idea :)

It feels gross to even think of clear text amounts

or using the denominated outputs

My understanding of what would need to be done for the final product, may be some mistakes in here:

1. no output can be spent twice (no double spends) and only the owner of an output can spend an output, which means verifying ring sigs since genesis + all key images in the chain are unique. Ring sig evolution over lifetime of Monero = bLSAG-variant (?) -> then MLSAG -> then CLSAG)

2. For every tx, sum of inputs == sum of outputs + fee (before RingCT this is trivial since amounts are in plaintext, after RingCT sum pedersen commitments)

3. After RingCT, output amounts are between 0 and 2^64 by verifying range proofs (borromean ring sigs -> now bulletproofs -> soon to be bulletproofs+)

4. After Ring CT, need to make sure amounts used in pedersen commitments correspond to outputs. Still working on my understanding of what exactly needs to be verified to verify this. Chapter 6 of Zero to Monero covers it

5. Coinbase outputs (miner reward) follow the emission curve

and I would guess starting with 2 or 3 is probably easiest

Note regarding coinbase outputs: prior to a specific hardfork (don't recall which one, but one of the latest) miners were free to claim less than the full block reward - and there are lots of blocks in which this happened, especially at the beginning

After that hardfork, the protocol now dictates that the full reward must be claimed by the miner

true good point

jberman[m]: the original ring sig scheme was one from the cryptonote whitepaper; I briefly described it in section 8.1.3 of ztm2

8.1.2*

got it

"only the owner of an output can spend an output" is not needed for checking unwanted creation.

true :)

<jberman[m]> "1. no output can be spent twice..." <- Awesome. Thats a good start point. Thank you!

jberman: If one was merely trying to prove no inflation, they wouldnt need to show that only the owner could spend an output, right? Ownership is separate from inflation.

<merope> "Note regarding coinbase outputs:..." <- Okay the algorithm should read the reward instead of only considering the expected reward. Thanks.

yep yep, unnecessary to include proving output ownership there on my part

Strictly speaking it isn't necessary to prove output ownership, but in practice ownership is inseparable from double-spend-proof.

The technical meaning of 'ownership' is 'ability to spend an output', and double-spend resistance is based on 'was an output spent?'.

but if someone was able to spend an output they didn't own, that would certainly be interesting to report

You'd still have to prove an output being spent is one that exists in the chain, that's what I was thinking gets proven by that when I wrote it

But ownership = posession of the private keys required to sign the tx. How the tx author came into posession of the keys is outside of the scope of the data written on chain

yes, in a valid txn

is there a way to construct a ringsig such that none of the outputs is the real one?

inputs*

<hyc> "but if someone was able to spend..." <- Well, I really dont care in this case. If it does not generate inflation, I'm fine. I dont know if it is possible to dissociate though.

I will try the simplest thing I can do.

Depending on your audience "proving" and "convincing" are sometimes different.

ok, I suppose you could imagine a tx that provably spends funds, but the tx author doesn't know the private keys of the inputs; in that case, balance is preserved without ownership being satisfied

however, that thought experiment is pretty confusing in practice lol

I think showing that all key images are valid (correct order) and unique along with inputs = outputs would be convincing for semi technical users

And range proofs

UkoeHB: Yeah, I dont even know how someone could create that. Someone has to have the private key in a transaction, right?

UkoeHB Wait, how would you create create a valid tx signature without knowing the private keys associated with the inputs? (Other than randomly stumbling on the correct sequence of bits by accident/bruteforce)

yeah it's an esoteric question that goes into choosing useful signature schemes

it's not a question you can answer with a PoC; you need a security model/proofs

for your purpose, you can 'assume' the schemes are all valid if implemented correctly

wernervasquez[m]: Yeah, something like that well explained maybe would do for me as well. But I want to be sure about the whole blockchain and present in a nice way.

Isn't there a tx database with that already checks for the correct ordering? (Or maybe it was just a database of extracted tx data)

merope: That's a good question. I don't know yet how I will extract things from the database (blockchain).

I guess there are some pythonbindings to that

dangerousfreedom: I am most interested your presentation of the information. I look forward to it.

Monerod has an rpc api, and there are two nice python libraries to work with that

wernervasquez[m]: Yeah, me too :p

You can also find lots of other useful resources here: github.com/monero-ecosystem/meta

Thanks