-
chch3003[m]
> <@hanshan:monero.social> Oh, I am aware of the ability to generate keys at
-
chch3003[m]
-
chch3003[m]
> however, using that site, the generated main address and mistaken "Priv view key" combination is not accepted by --generate-from-keys
-
chch3003[m]
This is for testnet. mainnet is
xmr.llcoins.net
-
ofrnxmr[m]
chch3003: the link you sent is to generate addresses.
-
ofrnxmr[m]
Both links let you select testnet, mainet, or even aeon etc.
-
ofrnxmr[m]
The first link lets you test addresses
-
ofrnxmr[m]
(See: upper left corner.)
-
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
-
boog900[m]
-
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.
-
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 <
libera.ems.host/_matrix/media/v3/do…b16535c1a97df6788fdf9a92a10a558d1ef>)
-
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:
xmrchain.net/tx/f49b6bf1c05e6814707…4762163fb5b89564b420d5b7c8680b79d9d
-
sech1
I think the next hardfork made it mandatory
-
sech1
and Monero hardforked often back then
-
Rucknium[m]
Can I use the version field in the RPC reply to strictly identify which coinbase outputs are RingCT compatible?
-
Rucknium[m]
With no false positives or false negatives?
-
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?
-
sech1
99.9% chance that yes
-
moneromooo
v1 coinbase outputs are rct compatible after v5 or v6.
-
moneromooo
By "rct compatible" I mean they can be used as inputs in a rct tx, despite having their amount in cleartext.
-
sech1
makes sense
-
moneromooo
It seemed like a good idea.
-
Rucknium[m]
I'm having problems with the output offset indices
-
moneromooo
In this context, it means those coinbase oututs are stored in the rct table, and use rct offset indices,
-
Rucknium[m]
-
Rucknium[m]
-
Rucknium[m]
226595
-
Rucknium[m]
I am trying to differentiate them
-
Rucknium[m]
Of course, the first one has the index on the "cleartext" amount
-
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.
-
moneromooo
And is it from a coinbase tx after v5 or v6 ?
-
Rucknium[m]
This coinbase (mentioned above, too) is after the RingCT enabling hard fork, but before v5:
xmrchain.net/tx/f49b6bf1c05e6814707…4762163fb5b89564b420d5b7c8680b79d9d
-
moneromooo
Looking at the code, those "pseudo rct" coinbase txes are v2. Makes it easy to spot them.
-
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?
-
moneromooo
I think so.
-
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
xmrchain.net/tx/f49b6bf1c05e6814707…4762163fb5b89564b420d5b7c8680b79d9d 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.
-
Rucknium[m]
Ok. It is a very rare edge case. But better to be as precise as possible
-
Rucknium[m]
Thank you!!!
-
moneromooo
An output cannot be usable in a ringct and a non ringct ring.
-
Rucknium[m]
Ok great. That clears that up
-
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.
-
ofrnxmr[m]
Taxing was in discussion
-
ofrnxmr[m]
Lot of reading to do for those who havent kept up 👍
-
ofrnxmr[m]
#monero:monero.social btw
-
chch3003[m]
Would be nice to have a webpage that sums up all proposals and pros/cons
-
ofrnxmr[m]
No, this isnt a "community democracy vote".
-
ofrnxmr[m]
Its a technical hurdle
-
chch3003[m]
well..
-
ofrnxmr[m]
(You're free to make the website)
-
ofrnxmr[m]
Off topic for dev.
-
plowsof11
moneromooo thank you for 8355 --no-initial-sync for wallet rpc server
-
Rucknium[m]
chch3003: Did you just sign up to read and summarize
monero-project/monero #6668 ? Thank you :)
-
chch3003[m]
Yes I have seen this issue but need to read more thoroughly. Thank you :)
-
selsta
rbrunner: can you open 8076 against release?
-
rbrunner
Yup, probably tomorrow. My git fu is a bit rusty, I will have to concentrate :)
-
rbrunner
Doesn't go into the tx_extra size limit express point release, right?
-
selsta
yes
-
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.
-
moneromooo
Because parsing blocks all the time will be excruciatingly slow.
-
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
-
moneromooo
You'll have to be clearer there.
-
-
-
someoneelse49549
the block ID is the height, as explained in blockchain_db.h
-
someoneelse49549
and we store the height in mdb_block_info_4 so its redundant
-
moneromooo
Do you think block ID is a height ? If so, this is wrong. It is a 32 bit hash.
-
moneromooo
Sorry, 32 byte.
-
boog900[m]
it uses a dummy key - the "key" is actually the first bit of data in the value
-
moneromooo
You might be right, looking...
-
someoneelse49549
boog900[m]: Alright it make sense
-
moneromooo
Some of the lmdb stuff is a bit confusing.
-
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.
-
anonimauzanto[m]
moneromooo: I made this a while ago to help understand the database. Not sure if it helps.
github.com/AnonimaUzanto/py-monerod…ain/docs/images/monerodb_schema.png
-
someoneelse49549
anonimauzanto[m]: its perfect 👌
-
moneromooo
It does :)
-
selsta
.merges
-
xmr-pr
8770 8785 8787
-
xmrlover[m]
What is this
-
tobtoht[m]1
A list of pull requests that are ready to be merged