00:13:45 <yanmaani> hyc: What about something like Banana Pi?
00:14:33 <yanmaani> What would a PCI card full of Cortex-A53s earn you? What about A72s?
03:14:43 <hyc> I haven't used banana pi, haven't looked at its specs
03:15:06 <hyc> "a PCI card full of Cortex-A53s" is easier said than done
03:15:39 <hyc> Cortex-A53 is very efficient, but I'd be worried about the efficiency of the power supplies and chassis it's attached to
03:16:09 <hyc> Cortex-A72 is less efficient. while you could get a higher overall hash rate, I don't know how well it would do in terms of ROI
09:29:30 <yanmaani> hyc: What's the break-even point in $/CPU acquisition cost?
12:19:50 <hyc> I can' answer that for you, look up your own price of electricity and calculate it yourself
12:20:21 <yanmaani> no I mean if electricity were free
15:17:53 <Fort1> Hi, the hash file is signed with "binaryFate <binaryfate⊙go>". Is this correct? Previous version were signed with another key.
15:21:35 <moneromooo> It is expected that binaryFate now signs.
15:22:54 <Fort1> Oki, thanks
16:58:28 <Henry151> hi. Is there an electrum-like desktop wallet software for monero that is recommended here?
16:58:58 <Henry151> by "electrum-like" i guess i mean, one that does not require running your own full monero node
16:59:29 <Henry151> which co-incidentally i am already running two monero nodes, but that's not relevant to my inquiry
17:02:27 <selsta> Henry151: mymonero is the closest thing we have
17:05:51 <Henry151> interesting
17:05:55 <Henry151> thank you.
17:27:53 <yanmaani> Henry151: You can run standard monero client in 'thin client' mode
17:37:47 <Henry151> yanmaani: interesting
17:38:39 <Henry151> i am relatively inexperienced with monero. If I am running a monero instance, and I reveal to someone the wallet address for my monero wallet, can they from that piece of information, determine the IP address of my monero node?
17:39:22 <moneromooo> No.
17:40:03 <Henry151> cool. And, if I reveal a wallet address, and you send some monero there, when I send it out to another address, you can't see what address I'm sending to, or my IP address, at that time either, right?
17:40:13 <Henry151> very nice.
17:40:57 <moneromooo> If you assume just "the adversary knows your wallet address" as in the first question, then the you're correct.
17:41:19 <Henry151> excellent nice strong default security, i like it. I've long thought monero is the only cryptocurrency that offers any worthwhile differences from bitcoin
17:41:58 <Henry151> so, if the adversary knows the IP address of my running monero node, can they find out from that, where I'm sending monero to? or my wallet address?
17:42:48 <moneromooo> Neither.
17:42:56 <Henry151> great!
17:43:08 <moneromooo> A bit of a caveat:
17:44:26 <moneromooo> If they know the IP address of your running monero node, and if they're connected to it, they will get transactions from you relayed to them. If they have sent you several outputs already, and your transaction happens to spend more than one of those outputs the adversary had sent you before, then there is a very good chance you're the author of that tx.
17:44:34 <moneromooo> They can't see where to though.
17:44:52 <Henry151> my initial line of inquiry was because, in the past when using bitcoin, if I wanted to create a bitcoin wallet address not associated with my real IP address or real identity, I would start up a live OS like tails, and use electrum to create a wallet while connected through TOR, for example. So, I thought, is that kind of stuff necessary for monero? Or can I safely use my already existing monero node,
17:44:58 <Henry151> that is connected to the internet through my primary home connection and without a VPN
17:45:24 <moneromooo> More layers of security is never a bad thing (assuming you don't use them badly).
17:45:57 <moneromooo> But monero addresses are never on the chain so the in yor face bitcoin trivial traceability does not apply to monero.
17:46:11 <Henry151> sure. But it sounds like I could safely use my pre-existing monero node with very little risk of exposure.
17:46:27 <Henry151> sorry the "sure" was in reply to the "more layers of security never a bad thing" bit.
17:46:38 <moneromooo> You can infer *some* things though. Just a lot less, and typically probabilistic.
17:47:52 <Henry151> cool. I'm not doing "anything bad" anyway so I have little to fear, but thank you for confirming what levels of privacy are "included" when you use monero
17:49:09 <moneromooo> Jews were not doing anything bad either when they got hunted using the databases governments kept on their population before WW2.
17:49:28 <Henry151> right on.
17:50:07 <Henry151> if you don't have anything to hide, well you still have a right to privacy.
17:58:47 <Henry151> ok, so i opened my monero wallet with "monero-wallet-cli --wallet-file /path/to/my/walletfile" .. it said "Opened wallet: ..." and then said "Starting refresh" and says "Height 1936228 / 1978442" ... I want to know, does this mean my monero node has not been running/keeping up to date with the blockchain of monero?
17:59:18 <Henry151> I would have thought it would be fully up to date as monerod has been running in the background on this machine for months
18:00:14 <selsta> what does it say if your type in status?
18:00:35 <Henry151> i tried typing "help" and "status" and got nothing from either
18:00:40 <Henry151> the height is increasing
18:00:46 <Henry151> it's up to 1950466 now.
18:01:09 <selsta> Henry151: what version are you using?
18:01:20 <Henry151> v0.14.0.2
18:01:29 <selsta> you missed the hardfork :)
18:01:30 <Henry151> am i out of date?
18:01:44 <selsta> stop monerod, download the new version and it should resolve itself
18:01:45 <Henry151> oh! we had a hard fork?
18:01:53 <Henry151> wowza
18:01:56 <selsta> but it will need a bit of time to sync up
18:02:15 <Henry151> what was the hard fork about?
18:02:39 <selsta> https://web.getmonero.org/2019/11/12/monero-0.15-released.html
18:02:56 <Henry151> dang it now i have to figure out how i installed it all over again
18:03:01 <Henry151> woohoo
18:03:08 <asymptotically> Henry151: hard forks every 6 months (ish) for now :D
18:03:13 <Henry151> thanks for the link
18:03:14 <selsta> what operating system?
18:03:34 <Henry151> debian
18:03:36 <selsta> but make sure to download the latest version from here: https://web.getmonero.org/downloads/#cli
18:03:46 <selsta> installing = downloading, extracting and starting
18:03:52 <selsta> no difficult process involved
18:03:55 <Henry151> ok i think i had got it from github last time
18:04:30 <Henry151> oh nope
18:05:30 <Henry151> i look at my bash history and can see, I downloaded a tar.bz2 archive from downloads.monero.org and then unpacked it and installed it with a command like "sudo install -m 0755 -o root -g root -t /usr/local/bin/ monero-v0.14.0.2/monero*"
18:05:45 <Henry151> then i made a systemd service to run it that way
18:05:57 <asymptotically> you can reuse your systemd service
18:06:10 <Henry151> yep i got it
18:06:39 <Henry151> i'll download the new archive, remove monero* from /usr/local/bin, and unpack the new archive and 'install' it with same command
18:07:13 <Henry151> selsta: you provided that link of where to get the latest version; is there some ambiguity or disagreement about "what's the official version" or something?
18:07:29 <Henry151> just because you said "make sure to download from here"
18:07:56 <selsta> no, you can also download from github
18:08:13 <Henry151> ok, just curious.
18:08:14 <selsta> make sure to check hashes
18:09:32 <Henry151> so is https://monero.org/downloads/ this the same software?
18:09:46 <moneromooo> I'm sure some people will put compromised binaries somewhere. And... that site's not ours.
18:10:28 <moneromooo> It's possibly waiting till it gets used a lot, then puts up comprimised binaries. Who knows. You don't want to be the one who tries :)
18:10:38 <Henry151> oh dear
18:10:50 <Henry151> how did "not us" wind up owning monero.org? that's unfortunate
18:11:04 <moneromooo> Then again, someone pwned the monero download site to put up compromised binaries there too.
18:11:21 <moneromooo> They bought it.
18:11:36 <Henry151> i could just build from source i suppose, but then again, i haven't got the technical proficiency to check the source code anyway
18:12:15 <Henry151> shoot barely got the proficiency to build from source, let alone to read through the source code and spot something malicious in it
18:12:50 <moneromooo> It's typically enough to download gitian binaries and check the hash against the hashes claimed by > 1 "trusted" person.
18:13:44 <moneromooo> There's a tool which does this, but then you'd have to build that one first :)
18:14:09 <Henry151> the only thing i am not liking about https://web.getmonero.org/downloads/#cli is the link for linux 64 bit is pointing at https://downloads.getmonero.org/cli/linux64 which is not a file, so it makes it clumsy for me to use wget to grab it on the machine i want to install on :/
18:14:37 <asymptotically> wget should follow the redirect
18:14:59 <Henry151> oh, i didn't even try i just saw "that's not a tar.gz file" and figured it was not the link i needed
18:15:57 <Henry151> nah, "wget https://downloads.getmonero.org/cli/linux64" results in a binary file called "linux64"
18:17:01 <asymptotically> tar xf linux64
18:18:36 <Henry151> that just seems odd. But i'll try it; it just seems weird that it didn't give me monero-linux-x64-v0.15.0.5.tar.bz2
18:21:40 <hyc> your client isn't set to use the name of the redirect target
18:21:54 <hyc> most GUI browsers will, CLI http clients won't by default
18:22:04 <Henry151> ah, i understand.
18:22:05 <Henry151> thanks
18:22:18 <Henry151> i'm already done installing the new version, about to start it up
18:23:22 <Henry151> where does monero look for a wallet file by default? I have always specified the full path to mine
18:23:50 <asymptotically> relative to the current working directory
18:24:12 <Henry151> hm
18:24:39 <Henry151> would that end up being /usr/local/bin if that's where the bin files are?
18:24:44 <asymptotically> so if you're in your home you can do something like --wallet-file Documents/Monero/MiningWallet
18:25:11 <Henry151> hm
18:25:42 <Henry151> i just noticed that if i run "monero-wallet-cli" with no arguments, then it says "Specify wallet name" and if i type my wallet name, it doesn't find it; so i'm wondering, where i might put the wallet file so that monero would find it that way
18:26:57 <asymptotically> the current working directory is the one you've cd'd into. you can see it in the prompt (before every command) or by running the pwd command
18:27:03 <asymptotically> so it just depends where you are when you start monero-wallet-cli
18:27:42 <Henry151> thank you
18:27:47 <Henry151> i am getting Error: Daemon uses a different RPC major version (2) than the wallet (3): http://localhost:18081. Either update one of them, or use --allow-mismatched-daemon-version.
18:28:11 <Henry151> i wonder what i screwed up on
18:28:26 <asymptotically> did you update both the monerod and wallet binaries? and also restart monerod after updating the binary?
18:28:35 <Henry151> yes and yes
18:29:00 <asymptotically> is your systemd service looking in the right place? maybe the old one wasn't in /usr/local/bin
18:29:46 <Henry151> aha, you are correct
18:29:48 <Henry151> thank you
18:29:58 <Henry151> it was looking for the file elsewhere
18:32:16 <Henry151> well, now i am getting Error: wallet failed to connect to daemon: http://localhost:18081. Daemon either is not started or wrong port was passed. Please make sure daemon is running or change the daemon address using the 'set_daemon' command.
18:32:20 <Henry151> Background refresh thread started
18:32:30 <Henry151> it *looks* like it's running
18:32:40 <Henry151> systemctl status monerod shows "active (running"
18:33:54 <asymptotically> you can try running `monerod status` to get some info on what it's doing
18:34:12 <asymptotically> and depending on how you wrote your systemd unit you might be able to do journalctl -u monerod :D
18:36:54 <Henry151> https://bpaste.net/raw/R5HA journalctl seems to show that it has not made any log entries since I changed the systemd service file to point to the new binary. monerod status shows the same couldn't connect to daemon message, and also says "generating ssl certificate"... https://bpaste.net/raw/R5HA
18:37:01 <Henry151> oops doublepasted the link sorry.
18:38:09 <Henry151> this is my systemd service definition: https://termbin.com/3b9h
18:39:45 <Henry151> oh what i said was inaccurate, if you look at the bpaste link there, you can see the journalctl logs are showing the most recent monerod version
18:40:41 <Henry151> well seems to have fixed itself
18:40:53 <Henry151> nevermind entirely, thank you for the help, it's working now properly
19:24:04 <Infinity8> .xmr
19:24:09 <Infinity8> wrong channel
21:11:10 <vinicius> hi
21:11:30 <yanmaani> hey
21:12:09 <vinicius> there's a long time I'm out of the loop, where can I get information about a reliable home mining software? (:
23:07:08 <cannon-c[m]> the official monero command line client has a mining option
23:07:25 <cannon-c[m]> I dont know if it is solo mine or pool mining, I dont have much experience with mining
23:07:35 <cannon-c[m]> @vin
23:07:44 <yanmaani> Is there something like P2Pool for Monero?
23:07:54 <cannon-c[m]>  * vinicius:
23:08:19 <yanmaani> useful behavioural nudge could be to implement it and have mining by default use P2pool
23:08:25 <yanmaani> so it'd be more work to use a centralized pool
23:12:16 <jtgrassie> the official monero cli mining is solo mining, not pool.
23:14:08 <jtgrassie> there is no p2pool implmentation for monero. It's something I spent a great deal of time on and settled on the fact the overhead is not worth it.
23:14:52 <jtgrassie> consensus is the rub
23:15:05 <yanmaani> What did go wrong?
23:16:29 <jtgrassie> monero block time is 2 minutes
23:17:33 <yanmaani> ohh
23:17:47 <jtgrassie> thus the side chain consensus needs to be even shorter
23:17:49 <yanmaani> and 20s block time is unfeasible?
23:17:58 <jtgrassie> exactly
23:18:14 <moneromooo> Why does it need to be shorter ?
23:18:15 <yanmaani> Is it, though? If there would be consensus on which transactions to include, then there shouldn't be a problem
23:18:31 <yanmaani> moneromooo: Because you want to submit shares.
23:18:39 <jtgrassie> ^
23:18:41 <cannon-c[m]> with blocktime of 2 minutes vs. 10 minutes like in btc, are orphaned blocks or temp chain forkes more likely/common?
23:19:08 <cannon-c[m]> thus needing say 5 confirmations in xmr to = same security of 1 btc confirmation?
23:19:15 <cannon-c[m]> or is this not an issue?
23:19:27 <yanmaani> Intuitively: pooled mining works by breaking up the 50 BTC reward into 1000 mini-blocks of 0.05 BTC.
23:19:49 <yanmaani> To post a block to the sidechain, you post a share. The consensus rule is that it has to pay the preceding miners.
23:20:25 <moneromooo> You submit shares to a separate chain. I'm pretty sure it'd work with, say, 5 minute block time on that chain, unless evidence supplied.
23:20:48 <yanmaani> No, if you have a side chain block time longer than the main chain, then you'll have less than one share per block
23:21:26 <yanmaani> mainchain_time/sidechain_time = block_reward/share_reward
23:21:41 <moneromooo> The p2pool chain will find much fewer than all blocks. So, beyond variance, it would not be a problem, would it ?
23:22:00 <yanmaani> But avoiding variance is the whole point of pools
23:22:05 <yanmaani> and also, that's betting against your own success
23:22:25 <yanmaani> "oh yes our goal is for 100% of the miners to use a sidechain which can only handle up to 10% of the total load"
23:22:29 <moneromooo> So your point was not that it would not work, but that variance would make it less appealing ?
23:22:30 <yanmaani> hmm this gives rise to an idea
23:22:44 <yanmaani> say you'd have ten p2pool-esque side-chains
23:22:46 <yanmaani> would that work?
23:22:47 <moneromooo> There can be several of these fwiw.
23:22:57 <yanmaani> moneromooo: Well, what's the purpose of a pool?
23:23:10 <moneromooo> Make money off miners.
23:23:14 <yanmaani> Here, try out my 100% decentralized 0% fee pool. We call it solo-mine.com
23:24:11 <yanmaani> Multiple p2pool chains would be a problem somehow, I think intuitively.
23:24:20 <yanmaani> could be wrong though
23:24:51 <yanmaani> But if you'd have very strict rules for how to build the blocks, including which transactions to include, couldn't you get something then?
23:24:54 <moneromooo> I should not, since one of these chains does not need to know whether other blocks are found bu another p2pool chain, or solor, or centralized pool, etc.
23:25:36 <yanmaani> so, all miners make sure to have the exact synced mempool, at least with respect to their immediate peers
23:26:00 <yanmaani> then whenever a block is found, it will just be a few kilobytes up until the synchronization boundary
23:26:09 <yanmaani> That's true
23:26:18 <yanmaani> My intuitive idea was that it would be incentive-incompatible
23:26:23 <yanmaani> since miners would flock to one pool
23:26:42 <yanmaani> but they wouldn't; if one pool has 30 shares outstanding and the other has 20, then mining on the shortest chain should be beneficial
23:27:19 <yanmaani> that said, you might get some BCash-esque scenario when ALL miners mine on the shortest chain, and whoops there comes 30 blocks at the same time, and then they all switch, etc
23:27:39 <yanmaani> though I imagine there's some Schelling point where they do it probabilistically
23:29:46 <yanmaani> like if the chain lengths are 35 35 35 32 30 15, then they'd pick a chain with weights f(0) f(0) f(0) f(3) f(5) f(20)