Is it only me, or are signatures for view-only wallets on Monero GUI do not self-verify within the same wallet?

irc.gammaspectra.live/0e84fc47478462b0/image.png

from inspection and verifying the signature externally such signatures are generated this way:

get_message_hash mode=1

valid spend/view public keys

BUT the signature then uses the spend view public key in the "comm" struct

then signs using all zero bytes private key

when verified using custom code against these parameters, it passes

s_comm.key = spend_pub, but secret_key &sec = spend_zero

nvm, it's mode=0 so less weird, the rest still applies

on Monero GUI, QString Wallet::signMessage(const QString &message, bool filename) const within libwalletqt/Wallet.cpp uses m_walletImpl->signMessage()

signMessage() just takes the message

which then calls m_wallet->sign(message, tools::wallet2::sign_with_spend_key);

hardcoding to always use the spend key, even for view wallets

Signatures use spend key

The fact it's enabled for view-only wallets, is probably a bug

The signature method can explicitly do view key signatures and detect which (spend or view) signed it

The verify return value also has that

So it can display if it was signed with a spend private key or view private key

Proving ownership of the view only keys still has value, and maybe useful in cases like hardware wallets where they expose the view private key but not the spend one

that way limited set of signatures can be made

(however it would be best to have such hardware implement full message signatures within)

The wallet RPC also allows for selecting either spend or view signatures

Seems it is just a missing feature within GUI that is well supported within Monero code and RPC, and the method to sign/verify for both is documented

Additionally signing for subaddresses which is also supported elsewhere but the GUI

Monero-wallet-CLI does it properly, just checked

Interesting

#monero-gui is probably better suited for this topic

<c​ompdec:matrix.org> Are the outputs on Monero similar to Bitcoin with one output going to the recipient and one going back to the sender as a change address, or am I misunderstanding something?

No, on this fundamental level Monero and Bitcoin work the same way.

The second output (change) goes to the same address you send from

<r​ucknium:monero.social> compdec: One difference: If you spent all of the amount to a single address in in bitcoin transaction, the bitcoin tx has only one output. In Monero, since version <Y>, the minimum number of outputs allowed by blockchain consensus is 2. Spending everything to a single XMR address will still create two outputs. One of the outputs will have 0 XMR in it.

<r​ucknium:monero.social> This prevents these types of rare transactions from appearing different to observers of the blockchain data.

<r​ucknium:monero.social> Since 2019 I think.

IIRC the 0 XMR output will go to some random address, not back to you

<r​ucknium:monero.social> So it would be "unspendable"? Not that a rational user would ever try to spend a zero XMR output. Just wondering.

<g​orillaquest:matrix.org> that's a waste I need that 0 xmr

yes, it would be unspendable and not even appear in the wallet

<c​ompdec:matrix.org> that's good to hear there are 0 XMR transactions already, I was just writing about the added entropy (aka # paths) that provides.

I've noticed github.com/monero-project/monero-gu…apk-with-docker-any-os-experimental

so far I haven't found a monero android wallet with reproducible builds. Is this reproducible? Is there a plan for it to be?

I don't know anything about it.

I wouldn't want my wallet on an Android phone though. That seems as hackable as it comes.

well, it has its risks that limit its use case, but it still fills an important use case despite that

Sorry I can't help you either way.

It's all good

My current problem is I'm trying to figure out a faster way to download the blockchain. Oh... is your download of the blockchain with the monero GUI limited by your hashrate?

That would make sense why this thing is so darn slow...

it has nothing to do with if you're mining or not at all. it just takes a long time

I run monerod as a service so it's always up to date for me

I just installed monerod last night. My initial download on this OS

I've downloaded 100,000 blocks. 2,700,000 to go....

At this rate it looks like it will take 15 days

it shouldn't take that long!

I don't understand the bottleneck

Go figure

Anyone mining with older servers?