01:51:55 <DataHoarder> Is it only me, or are signatures for view-only wallets on Monero GUI do not self-verify within the same wallet?
01:52:37 <DataHoarder> https://irc.gammaspectra.live/0e84fc47478462b0/image.png 
01:53:06 <DataHoarder> from inspection and verifying the signature externally such signatures are generated this way:
01:53:17 <DataHoarder> get_message_hash mode=1
01:53:24 <DataHoarder> valid spend/view public keys
01:53:58 <DataHoarder> BUT the signature then uses the spend view public key in the "comm" struct
01:54:15 <DataHoarder> then signs using all zero bytes private key
01:54:34 <DataHoarder> when verified using custom code against these parameters, it passes
01:56:03 <DataHoarder> s_comm.key = spend_pub, but secret_key &sec = spend_zero
01:57:39 <DataHoarder> nvm, it's mode=0 so less weird, the rest still applies
02:11:17 <DataHoarder> on Monero GUI, QString Wallet::signMessage(const QString &message, bool filename) const within libwalletqt/Wallet.cpp uses m_walletImpl->signMessage()
02:11:27 <DataHoarder> signMessage() just takes the message
02:11:37 <DataHoarder> which then calls m_wallet->sign(message, tools::wallet2::sign_with_spend_key);
02:11:51 <DataHoarder> hardcoding to always use the spend key, even for view wallets
05:30:37 <sech1> Signatures use spend key
05:30:57 <sech1> The fact it's enabled for view-only wallets, is probably a bug
06:21:06 <DataHoarder> The signature method can explicitly do view key signatures and detect which (spend or view) signed it
06:21:44 <DataHoarder> The verify return value also has that
06:22:22 <DataHoarder> So it can display if it was signed with a spend private key or view private key
06:24:11 <DataHoarder> 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
06:24:24 <DataHoarder> that way limited set of signatures can be made
06:24:51 <DataHoarder> (however it would be best to have such hardware implement full message signatures within)
06:26:36 <DataHoarder> The wallet RPC also allows for selecting either spend or view signatures 
06:27:58 <DataHoarder> 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
06:29:54 <DataHoarder> Additionally signing for subaddresses which is also supported elsewhere but the GUI
06:30:43 <DataHoarder> Monero-wallet-CLI does it properly, just checked
07:10:34 <sech1> Interesting
07:11:06 <sech1> #monero-gui is probably better suited for this topic
14:05:39 <m-relay> <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?
14:20:29 <rbrunner> No, on this fundamental level Monero and Bitcoin work the same way.
14:20:56 <sech1> The second output (change) goes to the same address you send from
14:24:34 <m-relay> <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.
14:25:31 <m-relay> <r​ucknium:monero.social> This prevents these types of rare transactions from appearing different to observers of the blockchain data.
14:26:17 <m-relay> <r​ucknium:monero.social> Since 2019 I think.
14:28:48 <sech1> IIRC the 0 XMR output will go to some random address, not back to you
14:30:19 <m-relay> <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.
14:30:45 <m-relay> <g​orillaquest:matrix.org> that's a waste I need that 0 xmr
14:33:32 <sech1> yes, it would be unspendable and not even appear in the wallet
16:55:51 <m-relay> <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.
23:18:28 <dMartian> I've noticed https://github.com/monero-project/monero-gui#building-android-apk-with-docker-any-os-experimental
23:19:02 <dMartian> so far I haven't found a monero android wallet with reproducible builds. Is this reproducible? Is there a plan for it to be?
23:19:35 <jeff_> I don't know anything about it.
23:20:12 <jeff_> I wouldn't want my wallet on an Android phone though.  That seems as hackable as it comes.
23:21:04 <dMartian> well, it has its risks that limit its use case, but it still fills an important use case despite that
23:21:37 <jeff_> Sorry I can't help you either way.
23:22:33 <dMartian> It's all good
23:22:37 <jeff_> 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?
23:22:53 <jeff_> That would make sense why this thing is so darn slow...
23:24:03 <dMartian> it has nothing to do with if you're mining or not at all. it just takes a long time
23:24:42 <dMartian> I run monerod as a service so it's always up to date for me
23:25:15 <jeff_> I just installed monerod last night.  My initial download on this OS
23:26:21 <jeff_> I've downloaded 100,000 blocks.  2,700,000 to go....
23:26:34 <jeff_> At this rate it looks like it will take 15 days
23:27:26 <dMartian> it shouldn't take that long!
23:40:26 <jeff_> I don't understand the bottleneck
23:48:37 <jeff_> Go figure
23:55:04 <jeff_> Anyone mining with older servers?