<b​asses:matrix.org> does this need to change?

<b​asses:matrix.org> matrix.monero.social/_matrix/media/…matrix.org/UpgXmwkQjiAeKOUNKiutBKLC

<b​asses:matrix.org> xcancel.com/mattjamesbtc/status/1816617395865419951#m

can't pander to maxis trying to 1 up someone on twitter. monero is renowned for being open about its strengths/flaws

if there is an error in bulletproofs security audits / proofs then monero can be printed from thin air, so you have to trust that this is not the case (Rucknium knows more about that). the entire context of selectively highlighted screenshot is just telling people that there is more involved than looking at a pile of coins on a table and saying

look, there's 10 coins on this table , i proved the supply

<d​ave.jp:matrix.org> We don’t need to appease them by having such a text on getmonero

<o​frnxmr:monero.social> That was written by sarang.

<o​frnxmr:monero.social> bitcoin can (and was) printed from thin air

<o​frnxmr:monero.social> Its just easier to notice on a transparent chain

<d​ave.jp:matrix.org> Yes and if we are not confident about monero math, we should just outright shutdown monero project 😂

<o​frnxmr:monero.social> Ringct has been implemented improperly by other chains, like haven or shadowcash, that both suffered inflation bugs

<o​frnxmr:monero.social> Cryptography != monero math

<d​ave.jp:matrix.org> Just get more audits done ? Instead of hoping there are no bugs or saying hey don’t use it there might be bugs

<o​frnxmr:monero.social> Bitcoin relies on cryptography as well. both rely on complex math to ensure the creation of supply is limited to consensus rules

<o​frnxmr:monero.social> bp has been exploited, but monero's implementation was not

<o​frnxmr:monero.social> A few big companies and other blockchains learned the hard way what happens when you dont listen to the neothers

<o​frnxmr:monero.social> Noethers

the only problem i see would be making people think transparent do not also "rely on complex math to ensure the creation of supply" ^ but i still see no issue with monero being based as usual

we are getting more audits done.. on bp++ .. fcmp++ and such lol

we cant control how other people interoperate the same text either, relax

i came out of my death bed because of the ctrl+f "the the" pull request editing chat logs

<o​frnxmr:monero.social> :D lololol

stating "then you need a transparent asset" is not correct

<o​frnxmr:xmr.mx> I think that text is a transcript of sarang speaking 🧐

yeah we're saying that transparent assets are physical coins on a table

does btc actually have a 100 guarantee of supply?

*100%

<o​frnxmr:xmr.mx> no

then the statement is wrong

that's what it is predicated on

<o​frnxmr:xmr.mx> Especially since they dont hard fork.

<o​frnxmr:xmr.mx> cointelegraph.com/news/inflation-bu…than-half-of-all-bitcoin-full-nodes

getmonero.org/2020/01/17/auditability.html yes its sarang

<o​frnxmr:xmr.mx> "In trying to fix the problem, the next released update, 0.15.0, included features that inadvertently allowed a malicious attacker to double spend the same UTXO in one transaction. Instead of causing a system crash, this new bug caused older software clients to recognize such double-spend transactions as valid."

was that btc or montero? ( ͡° ͜ʖ ͡°)

the preceding paragraphs leading into the incorrect statement "You can choose to represent amounts in the clear, like Bitcoin does; you can be sure that the supply is what you expect it to be"

<3​21bob321:monero.social> I have cement…

<o​frnxmr:monero.social> Btx

<o​frnxmr:monero.social> Btc

i can look at btc blockchain and add up to/from amounts and see the amount being created/moved around , but monero not

dangerous freedom has a website. I believe he recently said it is still not completely finished

if we are stating things about supply on the site, should we link to that?

thx plowsof, I just woke up from my afternoon nap lol

probably in misc. on this page moneroinflation.com (and maybe also in that blog, depends what the proposed changes are)

this page* getmonero.org/resources/tools

<o​frnxmr:monero.social> Hey, the website also says to take everything with a grain of salt

opened an issue about it, thanks for sharing rando monero-project/monero-site #2339

<b​asses:matrix.org> anytime!

<j​effro256:monero.social> This bug made me look into the Monero codebase to see if the consensus code checked that key images were unique within a transaction

<j​effro256:monero.social> Maybe I'm not looking in the right place, but it seems like there wasn't a check for key image duplicates until fork v7

<o​frnxmr:monero.social> Do dangerousfreedoms investigations cover that period adequately?

<o​frnxmr:monero.social> and do you know off-hand the date of v7 hardfork

<j​effro256:monero.social> Approx April 6th 2018

<j​effro256:monero.social> Literally just sent him a PM lol

<j​effro256:monero.social> I could write a Python script for this too

<o​frnxmr:xmr.mx> Looks like btc might have found it because of us, or vice versa

<b​oog900:monero.social> jeffro256: here: github.com/monero-project/monero/bl…note_core/cryptonote_core.cpp#L1297 ?

<j​effro256:monero.social> Oh that's right, I forgot about that function

<j​effro256:monero.social> I was looking at the other key image checks in `check_tx_input`

<b​oog900:monero.social> Our DB will also throw an error for duplicate KIs

<b​oog900:monero.social> when adding to the chain. That other check covers the txpool

<b​oog900:monero.social> Well not just the txpool but it means txpool txs are also checked

<j​effro256:monero.social> Right, since they get added one-by-one and checked in between

<j​effro256:monero.social> Technically, we could prob skip the `check_tx_inputs_keyimages_diff` check for txs of hf >= 7 because of the strictly ordered check in `check_tx_input` later and save ourselves a small set population/allocation per tx

<j​effro256:monero.social> Not worth the effort though IMO

<b​oog900:monero.social> Yeah, it would probably be a good idea to try consolidate as much of the consensus rules as we can into a single location, right now they are all over the place, but it would be a lot of effort and probably not worth the risk.

<b​oog900:monero.social> as IIRC there are quite a few checks which are duplicated like this

<r​ucknium:monero.social> boog900: Maybe we can start with documenting them. Then we would have more info about expected resource consumption under load, what shortcuts are safe and which unsafe, etc.

<b​oog900:monero.social> monero-book.cuprate.org

<b​oog900:monero.social> monero-book.cuprate.org/consensus_r…ctions/inputs.html#unique-key-image

<b​oog900:monero.social> Like that :)

<r​ucknium:monero.social> Thanks. Does it document what happens in the txpool?

<r​ucknium:monero.social> For example, what checking does monerod do when it gets a tx from a peer that it allegedly has already seen before. Does it just do a couple of Kekkack (sp?) hashes to check the txid or does it do verification of the cryptography again?

<b​oog900:monero.social> It documents the consensus checks, not the exact verification process

<r​ucknium:monero.social> And do nodes check tx validity before relaying them to peers, etc

<r​ucknium:monero.social> Keccak is the correct spelling :D

<j​effro256:monero.social> boog900: A small note: In the "definitions" section, it defines the "Block Hash" as "the keccak hash of the block". This isn't *quite* true, if you're referring to the block ID or the PoW hash. The Block ID is the keccak hash of the "block hashing blob", which is the block header concatenated with the "tx tree hash" and a varint of the number of txs. And the PoW hash is the Rando<clipped message>

<j​effro256:monero.social> mX hash of this same "hashing blob". github.com/monero-project/monero/bl…c/cryptonote_format_utils.cpp#L1466

<j​effro256:monero.social> github.com/monero-project/monero/bl…c/cryptonote_format_utils.cpp#L1446

<r​ucknium:monero.social> FCMP is going to put a lot more load on the nodes. It would be good to know where the efficiency improvements may be.

<b​oog900:monero.social> I did have Block PoW Hash in the definitions at some point, I don't know why I removed it, I'll add it back.

<b​oog900:monero.social> I used Block Hash for what you would call Block ID.

<b​oog900:monero.social> I don't really want to describe the exact process to arrive at a block hash in the definitions, I do want to expand the book with type formats, tx, blocks etc. I think it will be better suited there.

<b​oog900:monero.social> FWIW the block ID is calculated using a different blob to the PoW hash

<b​oog900:monero.social> I'll change the definition to include block hashing blob

<b​oog900:monero.social> and leave the processes for getting the block hashing blob out for now

<j​effro256:monero.social> > FWIW the block ID is calculated using a different blob to the PoW hash

<j​effro256:monero.social> Well, it's the same block hashing blob (IIUC), but the RandomX cache is initialized with the "seed" block hash, so it's not *just* a function of the block hashing blob. Is that correct?

<j​effro256:monero.social> I think that's a good idea

<b​oog900:monero.social> slightly different blob: github.com/serai-dex/serai/blob/3de…a/networks/monero/src/block.rs#L129

<b​oog900:monero.social> this was the definition I had before:

<b​oog900:monero.social> `POW Hash: the hash calculated by using the active proof of work function.`

<b​oog900:monero.social> I'll change it to this and add it back:

<b​oog900:monero.social> `Block PoW Hash: the hash calculated from the block hashing blob by using the active proof of work function.`

<j​effro256:monero.social> Oh you're right ! TIL

<j​effro256:monero.social> The `t_serializable_object_to_blob` call in `get_object_hash` in `calculate_block_hash` causes an extra varint to get prepended

<j​effro256:monero.social> Doesn't seem intentional ......

<j​effro256:monero.social> Too late now though lol. That's interesting !

<b​oog900:monero.social> I spent quite a long time debugging that ngl

<b​oog900:monero.social> I agree it's defiantly not intentional, we are stuck with it now though :P

<j​effro256:monero.social> That sounds good. Only thing is "Block PoW Hash" vs just "PoW Hash" seems a little redundant IMHO

<0​xfffc:monero.social> Very interesting discussion imho 🙏🏻

<b​oog900:monero.social> Rucknium to answer your questions:

<b​oog900:monero.social> > what checking does monerod do when it gets a tx from a peer that it allegedly has already seen before. Does it just do a couple of Kekkack (sp?) hashes to check the txid or does it do verification of the cryptography again

<b​oog900:monero.social> When receiving a tx-pool we check if we have it before doing the cryptography checks, although we do do some smaller checks first, like version and tx size.

<b​oog900:monero.social> > And do nodes check tx validity before relaying them to peers

<b​oog900:monero.social> yes

<b​oog900:monero.social> *When receiving a tx-pool transaction

<b​oog900:monero.social> Ah `POW Hash` is still there, the formatting is just messed up.