10:03:24 <chch3003[m]> > <@hanshan:monero.social> Oh, I am aware of the ability to generate keys at
10:03:24 <chch3003[m]> > https://xmr.llcoins.net/addresstests.html
10:03:24 <chch3003[m]> > however, using that site, the generated main address and mistaken "Priv view key" combination is not accepted by --generate-from-keys
10:03:24 <chch3003[m]> This is for testnet. mainnet is https://xmr.llcoins.net/
11:20:57 <ofrnxmr[m]> chch3003: the link you sent is to generate addresses.
11:20:58 <ofrnxmr[m]> Both links let you select testnet, mainet, or even aeon etc.
11:20:58 <ofrnxmr[m]> The first link lets you test addresses
11:21:58 <ofrnxmr[m]> (See: upper left corner.)
12:25:57 <boog900[m]> Hi hanshan: I think I have found out what Bisq is doing. Bisq is taking the bytes of your view key and putting that straight into this function unreduced
12:25:57 <boog900[m]>  https://github.com/bisq-network/bisq/blob/7319156c463f591642e5fb7d0debd7072bf79b02/core/src/main/java/bisq/core/xmr/knaccc/monero/address/WalletAddress.java#L93
12:25:57 <boog900[m]> It then reduces the key and generates the rest of the sub address, if you are willing to send me the view key and address you entered into bisq I would be happy to see if I can generate a view only wallet.
12:38:09 <hanshan[m]> > <@boog900:monero.social> Hi hanshan: I think I have found out what Bisq is doing. Bisq is taking the bytes of your view key and putting that straight into this function unreduced... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/a96ddb16535c1a97df6788fdf9a92a10a558d1ef>)
13:04:28 <Rucknium[m]> I want to make sure I have this correct. After the January 2017 enabling RingCT, miners could create RingCT-compatible coinbase outputs. But it wasn't mandatory. For example, this transaction is after the RingCT hard fork yet has non-RingCT-compatible outputs: https://xmrchain.net/tx/f49b6bf1c05e6814707266df5af794762163fb5b89564b420d5b7c8680b79d9d
13:05:13 <sech1> I think the next hardfork made it mandatory
13:05:28 <sech1> and Monero hardforked often back then
13:05:48 <Rucknium[m]> Can I use the version field in the RPC reply to strictly identify which coinbase outputs are RingCT compatible?
13:05:58 <Rucknium[m]> With no false positives or false negatives?
13:06:45 <Rucknium[m]> So version == 1 for a coinbase tx means non-RingCT compatible outputs. And version == 2 for a coinbase tx means RingCT compatible outputs?
13:06:57 <sech1> 99.9% chance that yes
13:07:23 <moneromooo> v1 coinbase outputs are rct compatible after v5 or v6.
13:07:54 <moneromooo> By "rct compatible" I mean they can be used as inputs in a rct tx, despite having their amount in cleartext.
13:08:10 <sech1> makes sense
13:08:14 <moneromooo> It seemed like a good idea.
13:08:39 <Rucknium[m]> I'm having problems with the output offset indices
13:09:25 <moneromooo> In this context, it means those coinbase oututs are stored in the rct table, and use rct offset indices,
13:09:34 <Rucknium[m]> For example the last output of this coinbase tx: https://xmrchain.net/tx/f49b6bf1c05e6814707266df5af794762163fb5b89564b420d5b7c8680b79d9d
13:09:41 <Rucknium[m]> has the same index as this one: https://xmrchain.net/tx/5478a8345c4113edba9a8b3092e62befc70c40fd6d0830488db4bcecee5bc8c1
13:09:48 <Rucknium[m]> 226595
13:09:56 <Rucknium[m]> I am trying to differentiate them
13:10:12 <Rucknium[m]> Of course, the first one has the index on the "cleartext" amount
13:12:10 <Rucknium[m]> In my WIP code to associate each ring with its output, a naive implementation causes some recent rings to have "17" ring members.
13:12:12 <moneromooo> And is it from a coinbase tx after v5 or v6 ?
13:14:31 <Rucknium[m]> This coinbase (mentioned above, too) is after the RingCT enabling hard fork, but before v5: https://xmrchain.net/tx/f49b6bf1c05e6814707266df5af794762163fb5b89564b420d5b7c8680b79d9d
13:17:28 <moneromooo> Looking at the code, those "pseudo rct" coinbase txes are v2. Makes it easy to spot them.
13:19:15 <Rucknium[m]> Does that mean that I can actually use the version field in the RPC reply to strictly identify which coinbase outputs are RingCT compatible?
13:22:58 <moneromooo> I think so.
13:23:01 <Rucknium[m]> When I get the JSON format of a tx from RPC, it identifies ring members by amount and offset index. If a coinbase output like https://xmrchain.net/tx/f49b6bf1c05e6814707266df5af794762163fb5b89564b420d5b7c8680b79d9d is usable for _both_ RingCT and non-RingCT rings, then the JSON format would not tell me which output was the intended one: The "zero-value" output with index 226595 or the "cleartext 8 XMR" output with index 226595.
13:23:31 <Rucknium[m]> Ok. It is a very rare edge case. But better to be as precise as possible
13:23:36 <Rucknium[m]> Thank you!!!
13:23:55 <moneromooo> An output cannot be usable in a ringct and a non ringct ring.
13:24:15 <Rucknium[m]> Ok great. That clears that up
14:51:13 <chch3003[m]> Regarding the tx_extra debate, could we have, similar to Bitcoin Segwit, bytes that cost more in fees than other? I see discussion about should we remove or cap extra data, but haven't seen proposal about taxing those data. 
14:53:00 <ofrnxmr[m]> Taxing was in discussion 
14:53:22 <ofrnxmr[m]> Lot of reading to do for those who havent kept up 👍
14:53:45 <ofrnxmr[m]> #monero:monero.social  btw
14:53:51 <chch3003[m]> Would be nice to have a webpage that sums up all proposals and pros/cons
14:54:13 <ofrnxmr[m]> No, this isnt a "community democracy vote".
14:54:13 <ofrnxmr[m]> Its a technical hurdle 
14:54:46 <chch3003[m]> well..
14:55:26 <ofrnxmr[m]> (You're free to make the website)
14:55:27 <ofrnxmr[m]> Off topic for dev.
15:01:44 <plowsof11> moneromooo thank you for 8355 --no-initial-sync for wallet rpc server
15:04:02 <Rucknium[m]> chch3003: Did you just sign up to read and summarize https://github.com/monero-project/monero/issues/6668 ? Thank you :)
15:05:37 <chch3003[m]> Yes I have seen this issue but need to read more thoroughly. Thank you :)
18:37:58 <selsta> rbrunner: can you open 8076 against release?
18:38:39 <rbrunner> Yup, probably tomorrow. My git fu is a bit rusty, I will have to concentrate :)
18:40:50 <rbrunner> Doesn't go into the tx_extra size limit express point release, right?
18:45:34 <selsta> yes
20:23:16 <someoneelse49549> Hi, why is monerod storing timestamp in blocks metadata when they're already in the block headers anyway? blocks metadata also contains blocks' height, which is exactly the key to access it in the db.
20:26:09 <moneromooo> Because parsing blocks all the time will be excruciatingly slow.
20:29:40 <someoneelse49549> moneromooo: Alright, I don't know why it didn't cross my mind. but for the height? I mean why puting it as the value if it is already the key
20:29:57 <moneromooo> You'll have to be clearer there.
20:33:14 * someoneelse49549 uploaded an image: (32KiB) < https://libera.ems.host/_matrix/media/v3/download/matrix.org/xDeGJwtxJrLmqeOvbECuqPjX/Screenshot%20from%202023-03-23%2021-31-42.png >
20:33:15 * someoneelse49549 uploaded an image: (13KiB) < https://libera.ems.host/_matrix/media/v3/download/matrix.org/mrpfLaRbHoNSKHgCckhNXYAH/Screenshot%20from%202023-03-23%2021-30-52.png >
20:33:35 <someoneelse49549> the block ID is the height, as explained in blockchain_db.h
20:34:11 <someoneelse49549> and we store the height in mdb_block_info_4 so its redundant
20:34:47 <moneromooo> Do you think block ID is a height ? If so, this is wrong. It is a 32 bit hash.
20:35:01 <moneromooo> Sorry, 32 byte.
20:35:14 <boog900[m]> it uses a dummy key - the "key" is actually the first bit of data in the value  
20:36:28 <moneromooo> You might be right, looking...
20:36:40 <someoneelse49549> boog900[m]: Alright it make sense
20:37:08 <moneromooo> Some of the lmdb stuff is a bit confusing.
20:38:41 <moneromooo> Alright, "Do you think block ID is a height ? If so, this is wrong. It is a 32 bit hash." was wrong (and not just about hte size). Ignore me.
20:39:42 <anonimauzanto[m]> moneromooo: I made this a while ago to help understand the database. Not sure if it helps. https://github.com/AnonimaUzanto/py-monerodb/blob/main/docs/images/monerodb_schema.png
20:41:00 <someoneelse49549> anonimauzanto[m]: its perfect 👌
20:42:04 <moneromooo> It does :)
23:13:48 <selsta> .merges
23:13:48 -xmr-pr- 8770 8785 8787
23:18:32 <xmrlover[m]> What is this 
23:19:01 <tobtoht[m]1> A list of pull requests that are ready to be merged