01:22:56 <wizardsmoke> What is the preferred amount of lockable memory to dispel the warning? Is this some established value?
01:25:50 <moneromooo> If the goal is to dispel the warning, as much as you can. I don't know the minimum expected amount needed. It depends on usage I think, since it's the number of crypto::secret_key (and possibly other things) in memory at once.
01:26:44 <moneromooo> It takes a page per though, which is wasteful. It'd be nice to group many 32 byte keys onto a page.
01:27:19 <moneromooo> Most of the time it's not possible, but some cases might, which will reduce the page locked load.
01:27:51 <wizardsmoke> moneromooo: is there some reason not to simply make it unlimited?
01:27:59 <moneromooo> The OS won't allow you.
01:28:06 <moneromooo> (for good reason, it'd be a DoS vector)
01:28:48 <wizardsmoke> I suppose I'm just looking for some indication as to what a rational level is. 128k, 2G, ...
01:29:18 <wizardsmoke> For some reason the wallet refreshed once, but now throws std::bad_alloc. Blocks received: ####
01:30:13 <moneromooo> Locked memory shortage should not cause this. If it does, it can be fixed.
01:34:47 <wizardsmoke> I wonder why in the world the wallet just broke like this
01:36:55 <moneromooo> What's the stack trace in the log ?
01:37:34 <wizardsmoke> oh, heh, I sent the log to /dev/null. Let me see about that
01:40:52 <wizardsmoke> oh heavenly, idk what it means
01:41:23 <wizardsmoke> 7f881d398a80    INFO    logging contrib/epee/src/mlog.cpp:273   New log categories: *:WARNING,net:FATAL,net.http:FATAL,net.ssl:FATAL,net.p2p:FATAL,net.cn:FATAL,global:INFO,verify:FATAL,serialization:FATAL,daemon.rpc.payment:ERROR,stacktrace:INFO,logging:INFO,msgwriter:INFO
01:41:48 <moneromooo> It just tells you what logs are active. Run with --log-level 0.
01:42:13 <moneromooo> The wallet disabled logs (request for people who're scared of leaving private traces on the filesystem).
01:42:20 <moneromooo> from
01:43:58 <wizardsmoke> Error: refresh failed: no connection to daemon. Please make sure daemon is running..
01:44:18 <wizardsmoke> which is nonsense because ./monerod status shows that I am synced
01:45:07 <wizardsmoke> and, the wallet just successfully refreshed 5m ago
01:50:57 <wizardsmoke> moneromooo: closed the terminal and tried in a new terminal seemed to fix (maybe)
02:01:28 <wizardsmoke> Is there a way to stop the cow from locking my wallet. I don't trust him.
02:03:43 <moneromooo> set inactivity-timeout 0
02:03:56 <moneromooo> Actual name may differ a bit, "set" will list it.
02:04:23 <wizardsmoke> ah, sweet. I must have missed that feature release. Didn't know what to think when the cow showed up on the scene. Might be a mallicious hacker.
02:05:12 <moneromooo> Out to milk you. Can't be too cowreful.
02:05:40 <wizardsmoke> oh, that's a good one ^_^ punny
02:08:49 <wizardsmoke> So, that issue resolved itself. Possibly can recreate by opening the wallet, allowing it to lock, and then closing the terminal without reentering password and properly closing the wallet. However, the fix was also close terminals, open a new one, and try again.
02:09:58 <moneromooo> "Closing terminal" meaning... kill the terminal window ?
02:10:28 <moneromooo> nvm, there's a save and swap files, can't be that.
02:11:04 <wizardsmoke> Yup, I saw the cow and freaked out, closed the window. Then tried in another terminal (which may have been previously open) but kept getting std::bad_alloc
02:11:32 <wizardsmoke> Then closed all windows and tried again. It refreshed again and I was able to close/reopen without issue.
02:17:06 <wizardsmoke> I reckon it had something to do with the previous refresh not being 'completed' somehow when I closed the wallet how I did. Some bad data artifact somewhere.
03:42:26 <bigslim[m]> When cow ascii on CLI release moo?
03:49:24 <wizardsmoke> bigslim[m]: do you not have the cow in your cli?
03:58:18 <bigslim[m]> 15.0.5 release?
03:59:33 <wizardsmoke> Should have it, I suspect.
04:00:54 <bigslim[m]> Let me run the hidden command ``moo_moo_mooooooon``
04:01:16 <bigslim[m]> Nope. Not there. Invalid request
04:09:08 <wizardsmoke> That's a real thing?
04:20:46 <bigslim[m]> There are many commands not listed by -help
04:23:05 <bigslim[m]> Is there a live MRL meeting tomorrow? I may join now that I’m WFH
04:33:18 <niocbrrrrrr> bigslim[m]: Research meeting Wednesdays @ 17:00 UTC ( https://github.com/monero-project/meta/issues/454 )
04:33:22 <niocbrrrrrr> #monero-research-lab
10:51:42 <TheFuzzStone[m]> ErCiccione[m]: Can you explain the reason for *another* migration of the Monero site repo, (now to Github)? When is the next migration planned, and how many more will be in the future?
10:51:42 <TheFuzzStone[m]> Is there any information, preferably structured, which repo (and where) remains relevant and which can be ignored?
10:54:50 <selsta> TheFuzzStone[m]: we tried out gitlab and found that github is better for development
10:55:02 <ErCiccione[m]> TheFuzzStone: There is no other migration planned. The only change is the monero-site repo moving from gitlab to github. the repo on gitlab is used for mirroring. The CCS repositories are staying on gitlab. The discussion is in this issue: https://github.com/monero-project/meta/issues/236
10:55:08 <selsta> something that we couldn’t know without testing first
10:55:26 <ErCiccione[m]> the announcement is here: https://github.com/monero-project/monero-site/pull/929
10:55:41 <TheFuzzStone[m]> ErCiccione[m]:
10:55:42 <TheFuzzStone[m]> Thanks
10:56:27 <ErCiccione[m]> no problem :)
12:06:49 <yanmaani> selsta: What was the difference?
12:25:35 <aquestion> Hello everyone. How likely is it, that some entity has so many monero nodes all over the world, that they are actually connected to every existing nodes? Thus making it possible to identify the node broadcasting a transaction for the first time, basically linking an IP to a transaction?
12:28:35 <yanmaani> Well, they would have to be a peer of the nodes too.
12:28:45 <yanmaani> As in, not just connected, but the peer that the transaction is sent to.
12:28:49 <yanmaani> Which I guess is all of them
12:29:05 <yanmaani> Low, anyway. Either they're using the same server for all of them, and then it would be clear as day in the logs
12:29:43 <yanmaani> or they wouldn't, and then they would have to pay obscene amounts of money
12:29:48 <aquestion> but some agencies could easily get, say, 5-10 vps from each country
12:30:06 <aquestion> and since a node seems to connect to (at least) 8 other peers, if they had like, 50% of the nodes, ithink they would have every peer existing
12:30:18 <moneromooo> With Dandelion, a node cannot tell even if they're connected to every other node.
12:30:38 <aquestion> may you explain what is dandelion?
12:30:58 <moneromooo> A system which protects against this :) I think we don't quite have it yet, there's still a PR left to merge.
12:31:08 <yanmaani> aquestion: There's 200 countries in the world, so that's 1000-2000 servers. Is the Monero network that small?
12:31:25 <aquestion> thx for both of your answers btw
12:31:26 <aquestion> i mean
12:31:30 <moneromooo> Basically it sends a tx to just one node. So it can send to the adversary, or to a not adversary.
12:31:34 <aquestion> 20 countries would be enough
12:31:41 <moneromooo> But the adversary cannot know who is the originator then.
12:31:51 <aquestion> 20x10vpsx$50 = $10k
12:32:13 <aquestion> well that's be nice
12:32:22 <aquestion> i know bitcoin is adding some sort of batching too
12:32:39 <aquestion> will monero do something like that?
12:33:13 <yanmaani> moneromooo: Is dandelion source-routed? And why not just use Tor?
12:33:17 <moneromooo> We do batching when syncing historical blocks. We could batch incoming "free" txes too, but the patch got rejected since it adds some latency.
12:33:34 <aquestion> i know about Tor though
12:33:58 <aquestion> but wondering about that
12:34:05 <yanmaani> just ghetto Freenet-style routing seems like it could work otherwise
12:34:20 <aquestion> because many users probably dont use tor, if you can link txs by IP you can eliminate many, many decoys from rings
12:34:26 <yanmaani> I make a packet, set HTL to a random value between 100 and 50, encrypt it with the key of my neighbor node
12:34:43 <moneromooo> Source, yes. I guess because it also works if Tor is blocked. And if all your guard nodes are pwned, you don't get the dandelion protection.
12:34:46 <yanmaani> That node decrements HTL by 1 and 10, sends it to a random neighbor
12:34:58 <moneromooo> I'm sure there's a lot of talk on this on the net as it was made for bitcoin first.
12:35:12 <yanmaani> It would not work if you'd be surrounded by bad nodes, but Better Than Nothing™
12:35:19 <moneromooo> Can you explain "if you can link txs by IP you can eliminate many, many decoys from rings" ?
12:35:21 <yanmaani> if Tor is blocked then you can just use bridges
12:36:56 <aquestion> give me a second im trying to formulate that properly
12:44:46 <aquestion> if some agency knows TX1 is from user A. And they also know which output is the change, and which one actually went to A. (say, they made the transaction themselves, or the exchange/other party told them).
12:44:46 <aquestion> They look each ring where that output appears. Lets make it easier, say it appears 3 times (TX2 and TX3 as a decoy, and TX4 as the real input).
12:44:46 <aquestion> We then have 6 outputs to watch. (2 from TX2, 2 from TX3, 2 from TX4)
12:44:46 <aquestion> Then they look at these 6 outputs, in which rings they appear.
12:44:46 <aquestion> If the same IP as TX4 broadcasts one of the transaction that has a ring with this output, its likely that one using the real output. The two others were decoys.
12:52:42 <UkoeHB_> Makes sense, sounds like an important benefit from Dandelion++
12:53:42 <aquestion> damn, i hoped i was wrong somewhere and that wasnt an issue
12:54:36 <moneromooo> Well, if you know lots of things, you can deduce more.
13:04:54 <Mochi101> What's the largest ringsize possible?
13:06:14 <Mochi101> Or is there no limit if you're willing to pay the fee?
13:06:53 <midipoet> i thought ring sizes were standardised (or maybe its just a minimum)
13:10:29 <moneromooo> Fixed to 11.
13:10:50 <moneromooo> (except special cases when spending pre-rct)
13:11:30 <moneromooo> Prior to that, it was as much as there are outouts available and the tx does not go past ~150 kB.
13:35:44 <Mochi101> I see
13:54:33 <dEBRUYNE> aquestion: Nodes cannot reliably determine whether the node that relays the transaction to them is also the node that created the transaction though
13:54:40 <dEBRUYNE> This only applies to local nodes
13:54:53 <dEBRUYNE> In case of a remote node, the node operator will be able to associate IP with the transaction
14:25:19 <yanmaani> dEBRUYNE: Isn't a trivial countermeasure to find a random node to give your txn to, as if you were a full node?
14:25:47 <yanmaani> A very ghetto approach is to just say, "whichever nodes would like to, please listen on port 12345 UDP for transactions"
14:26:07 <yanmaani> you make sure your txn is <1.5 kb, pick a random 32 bit number, bada bing bada boom
14:26:29 <yanmaani> it ain't perfect but it's a million times better than nothing, and fast to implement too
14:58:45 <moneromooo> Yes, let's make shitty solutions where one good one exists, just because people want to save 30 GB.
14:59:37 <yanmaani> This is instead of the so-far nonexistent anonymity networks.
15:01:08 <yanmaani> Also it could be combined with the onion routing, so that it's harder for the entry guard to see your entry point
15:01:11 <yanmaani> (It doesn't save 30 GB)
15:44:57 <asymptotically> yanmaani: tor isn't nonexistent
15:47:57 <yanmaani> no but Kovri is
15:48:10 <yanmaani> couldn't get Tor to work when I tried it, and it certainly isn't on by default
15:59:50 <visualshock> I am getting a lot of " peer claims higher version that we think (13 for 2063919 instead of 12) - we may be forked from the network and a software upgrade may be needed"
16:00:53 <moneromooo> You can ignore. Some other nodes are claiming this but it's false.
16:01:17 <visualshock> What does it mean?
16:02:19 <moneromooo> You think version 12. The other computer says version 13.
16:02:33 <moneromooo> So your dameon thinks maybe it's out of date.
16:05:41 <visualshock> I banned the two ips that claimed that, and now it is much better.
16:06:12 <visualshock> But version 12/13 of what?
16:06:44 <moneromooo> Of the monero protocol.
16:08:37 <visualshock> It went fast from 0% till 63%, slow fom 63 till 98%, and now it is very slow. Is this normal?
16:08:57 <moneromooo> Yes.
16:09:16 <moneromooo> If you have a spinning disk, it'll be even slower (by a lot).
16:09:43 <visualshock> Got a Samsung nvme
16:11:52 <visualshock> Why does it slow down the closer it is to finish?
16:13:19 <moneromooo> More usage, verifies PoW, verifies more tx data.
16:13:30 <moneromooo> Also slower tx constructions to verify.
16:15:34 <visualshock> What is PoW?
16:16:44 <yanmaani> proof of work
16:16:46 <yanmaani> (=mining)
16:16:55 <moneromooo> Proof of work. A system allowing distributed consensus among untrusted parties.
16:17:06 <moneromooo> (eventual consensus)
16:20:57 <visualshock> I see, thanks.
16:29:38 <visualshock> How long does it take to get a amount that I can send to another wallet if I enable setup-background-mining? I am just testing monero.
16:30:25 <jwinterm> visualshock, between 1-10000 days
16:30:27 <moneromooo> On mainnet, probably a long time. Like a year or more.
16:30:34 <moneromooo> It's basically a lottery.
16:30:54 <moneromooo> To test, run with --testnet. You'll get monero a LOT sooner.
16:31:20 <visualshock> Oh, that long.
16:31:56 <moneromooo> 1.7 monero a block, so at, er... $50 ? That's like $80. $80 every year or two, depending on your hash rate.
16:32:48 <visualshock> So I can only get a whole block?
16:33:10 <moneromooo> Yes. You try to get every block. First miner to find it gets the block reward.
16:33:10 <asymptotically> yes, but you can mine in a pool if you want more predictable rewards
16:33:46 <moneromooo> Solo mining, background mining = lottery. Pool = wage slave.
16:33:59 <moneromooo> Both have about the same expected value in the long term.
16:34:29 <moneromooo> Modulo decreasing block reward, pool fee, pool exit scam, that kind of thing.
16:35:18 <moneromooo> Solo is also more private. We like privacy generally.
16:35:29 <asymptotically> after 2 long years of hard mining, i finally neared the minimum payout threshold. and then the pool exit scammed and took it all away :'(
16:35:53 <moneromooo> What's the point of a pool if you gotta wait 2 years...
16:36:38 <moneromooo> What pool was that ?
16:37:38 <asymptotically> oh i was just making that up. the only exit scamming monero pool i can think of (so far) is fasthash, and it only lasted a couple of weeks
16:38:58 <moneromooo> Well, there's minergate which apparently claims you sent less hash than you did, and dwarfpool who scammed the ffs years ago (admittedly not a pool scam, just owned by the scammer).
16:41:55 <asymptotically> it seems like there's a ~30% chance they decide to not credit a share :(
16:47:50 <UkoeHB_> Isn't minergate part of the cryptonote scam network? Those guys are persistent
16:48:54 <asymptotically> with hitbtc and friends
16:50:36 <yanmaani> we need p2pool for monero...
16:50:47 <yanmaani> Does it support coinbase to multiple addresses?
16:57:58 <UkoeHB_> It's technically possible, idk how much effort would be needed to implement. Afaik _all_ coinbase tx have historically been 1-output
16:59:09 <yanmaani> One way would be to make it so that coinbase delays kick in slower.
16:59:14 <yanmaani> with a delay of one block
17:00:06 <yanmaani> so instead of coinbase going to addr X and being stuck there for a day, if it's spent in the same block as it's created, then the delay kicks in after the first transaction
17:00:28 <Skirmant> https://w1r3.net/paste/DJyVPg.webm
17:01:47 <UkoeHB_> well the delay is 2hr
17:02:15 <yanmaani> for p2pool systems to work, the delay must be 0 :/
17:04:25 <moneromooo> It supports any number of coinbase outputs. Pre-rct, you typically had 8-ish outputs.
17:04:52 <yanmaani> so a p2pool system would be possible?
17:05:38 <moneromooo> I don't see why not.
17:05:47 <moneromooo> But then I've not done it.
17:06:32 <yanmaani> short of good mempool sync, the only requirement is for coinbase outputs to be able to send to multiple addresses
17:06:42 <yanmaani> like, a few thousand preferably
17:07:26 <moneromooo> Coinbase outputs are very small. A few thousands is fine.
17:07:48 <yanmaani> seems like it's just mempool sync stopping the project from good decentralization then
17:08:15 <moneromooo> I don't think it needs that (though I did not think much about your objection from yesterday, so it might be valid).
17:08:37 <yanmaani> my objection isn't a super big deal. But if the mempool isn't sync, then it will just be logistical hell
17:09:02 <yanmaani> if there are to be new blocks every 30s, and it takes more than 30s to move the transactions around, then it will just be chaos
17:22:06 <UkoeHB_> iirc jtgrassie looked deep into p2pool for monero, and didn't have a positive conclusion
17:26:29 <yanmaani> UkoeHB_: The Brit?
17:26:33 <yanmaani> in the video?
17:27:51 <yanmaani> Right, yes, Jethro Grassie. Yeah, his problem was that the mempool wasn't synced.
17:27:53 <yanmaani> So the blocks were big
17:28:10 <yanmaani> and RIP goes the consensus
17:35:26 <UkoeHB_> mempool sync doesnt seem solvable
17:35:59 <yanmaani> Why not? You just have to make sure that the transactions are sent rapidly.
17:36:37 <wizardsmoke> What needs to happen for a wallet to connect to a node, hosted on a different device, on the same network. RPC port should be passed through and wallet should use --daemon-address=IP:Port no?
17:37:14 <wizardsmoke> Does the daemon need to bind something?
17:37:25 <yanmaani> I had a suggestion for this in #bitcoin-wizards a long time ago. Basically, you send transactions to everyone unprompted
17:37:54 <asymptotically> wizardsmoke: `--rpc-bind-ip 0.0.0.0 --confirm-external-bind` on daemon to make it listen on all interfaces i think
17:38:11 <yanmaani> And assuming transaction/block origin is geographically distributed, the local maxima will be to have a geographically dispersed set of 'friends'
17:39:32 <yanmaani> Then, miners could just delay adding transactions into blocks for a few seconds to stay on the safe side and prevent being orphaned.
17:41:16 <selsta> wizardsmoke: AFAIK --confirm-external-bind is only for binding to a non-localhost IP which is something you don’t want
17:45:42 <wizardsmoke> I took that line out and just added --rpc-bind-ip 0.0.0.0 but now I'm getting `Error: Couldn't connect to daemon: 127.0.0.1:18081`
17:47:28 <selsta> what is the exact command?
17:47:33 <asymptotically> in your wallet you'll need to add --daemon-address 192.168.x.x:18081
17:49:00 <wizardsmoke> I added rpc-bind-ip=0.0.0.0 to my config on the daemon, then restarted it and tried monerod status (on the server) but the server gave that error. Commenting rpc-bind-ip and restarting recovered it.
17:49:10 <wizardsmoke> I haven't even tried on the remote client yet
17:50:02 <selsta> can you post the exact command?
17:50:11 <UkoeHB_> yanmaani: how is that different from what is normally done? idk much about tx dispersion
17:50:32 <yanmaani> UkoeHB_: Usually you only send upon request
17:50:38 <yanmaani> So the flow goes like
17:50:44 <yanmaani> 1) Hey, I have txn
17:50:46 <yanmaani> 2) OK, send it
17:50:53 <yanmaani> 3) Here you go
17:51:40 <wizardsmoke> selsta: monerod status or do you mean for the daemon? the daemon is `./path/to/monerod --config-file /path/to/conf/file --detach --pid ...`
17:52:34 <yanmaani> So if we have 3 nodes, A, B, and C, with 100ms one-way latency between A/B and C/D, then the delay comes to 900ms A <-> C.
17:58:23 <selsta> wizardsmoke: and you put the rpc-bind-ip stuff in the config file?
17:58:44 <wizardsmoke> Yeap, and that broke it even on the host device
17:59:00 <wizardsmoke> Didn't bother to try the client after that didn't work
17:59:13 <selsta> okay, can you check what your local ip?
17:59:20 <wizardsmoke> i have it
17:59:58 <selsta> can you bind it to the local ip?
18:00:04 <selsta> not 127.0.0.1 and not 0.0.0.0
18:00:26 <wizardsmoke> Sure, I can try that
18:01:03 <wizardsmoke> Error: Couldn't connect to daemon: 127.0.0.1:18081
18:01:27 <wizardsmoke> That's from trying monerod status on the server device
18:01:57 <selsta> can you try monerod --rpc-bind-ip local-ip status
18:02:51 <wizardsmoke> Error: Couldn't connect to daemon: local-ip:18081
18:03:17 <UkoeHB_> I see what you mean yanmaani, is there some design reason for that flow vs pure broadcasting?
18:03:27 <selsta> wizardsmoke: can you try adding --confirm-external-bind
18:03:35 <wizardsmoke> sure thing
18:03:42 <yanmaani> UkoeHB_: Well it wastes insane amounts of b/w
18:04:08 <yanmaani> If you do it by just sending them on request, it's pretty much linear to the amount of nodes
18:04:11 <wizardsmoke> selsta: in that case restarting the daemon fails
18:04:41 <yanmaani> If you do it by sending them automatically, then you'll send it far more - each node would in expectation get 1 copy from each friend
18:04:47 <selsta> hmm I’m sure it is quite easy to do but I’ve only made my daemon available on localhost or externally reachable
18:04:48 <yanmaani> with 20 friends, that's 20x bw
18:04:56 <selsta> maybe someone else can help you
18:05:31 <wizardsmoke> The error it threw was --rpc-bind-ip permits inbound unencrypted external connections. Consider SSH tunnel or SSL proxy instead. Override with --confirm-external-bind
18:05:57 <wizardsmoke> should my config be like confir-external-bind=1?
18:06:19 <selsta> try it out
18:06:25 <selsta> seems like it didn’t add the option properly
18:06:34 <wizardsmoke> yeah, that got it to run actually
18:06:40 <wizardsmoke> I'll try connecting now
18:09:08 <wizardsmoke> Sweet, looking good. I changed the bind to 0.0.0.0 and I've got it now with both `monerod --rpc-bind-ip local-ip status` and `monerod status. Now, hopefully, the wallet will see it, too.
18:09:47 <selsta> wizardsmoke: but make sure that it isn’t externally reachable
18:09:58 <selsta> outside of your local network
18:10:29 <wizardsmoke> oh, that's hot
18:11:27 <wizardsmoke> I set the firewall to only pass through 18081 to the LAN. I will try different ways to get at it
18:11:59 <wizardsmoke> er, to only allow in traffic on 18081 from the LAN, rather
18:13:20 <wizardsmoke> Ideally, I'd like to bind only to the LAN IP and localhost, but I'm not sure its possible to have two binds
18:41:45 <visualshock> Does the cli also start the rpc?
18:43:05 <jwinterm> visualshock, there are separate binaries for cli and rpc
18:43:09 <jwinterm> if you're talking about the wallet
18:43:22 <visualshock> jwinterm, yes
18:43:42 <wizardsmoke> Oh, weird, what is the difference
18:43:57 <jwinterm> one starts the cli wallet the other starts the rpc wallet
18:44:26 <visualshock> The rpc closes when I try to open it, only the cli stays open
18:44:26 <jwinterm> cli you interact with from your terminal, rpc you interact with over the network interface
18:44:40 <jwinterm> you may need to launch it with some command line options
18:44:44 <wizardsmoke> Not sure that makes it any clearer to me. Can't I connect to RPC with monero-wallet-cli --daemon-address ip:port
18:44:46 <jwinterm> like wallet-file, password, etc
18:45:09 <jwinterm> no daemon-address tells the wallet what the rpc interface for the daemon is
18:45:24 <jwinterm> the wallet interacts with the daemon via rpc
18:45:56 <jwinterm> you can interact with the dameon by terminal or rpc
18:46:18 <jwinterm> you can only interact with cli wallet via terminal, and you can interact with rpc wallet only via rpc
18:49:13 <wizardsmoke> How is the rpc wallet different from the cli wallet?
18:49:44 <wizardsmoke> Now I don't even know what wallet I'm using or if it was necessary to open RPC port to get chain info from daemon
18:50:01 <selsta> ./monero-wallet-cli = cli wallet
18:50:24 <selsta> cli wallet communicates with daemon over rpc, that’s why you had to open RPC port
18:50:29 <selsta> rpc wallet is more for programmers
19:00:34 <visualshock> So monerod also starts the rpc?
19:02:02 <selsta> monerod uses rpc for communication with the cli wallet (https://en.wikipedia.org/wiki/Remote_procedure_call)
19:03:30 <selsta> monerod does not start monero-wallet-rpc
19:05:05 <wizardsmoke> What is an example where I'd use monero-wallet-rpc
19:06:12 <visualshock> When your code wants to interact with your wallet
19:10:09 <wizardsmoke> so its something I'd use programmatically to pass one RPC at a time?
19:10:25 <wizardsmoke> like get_balance or whatevr
19:11:46 <selsta> https://web.getmonero.org/resources/developer-guides/wallet-rpc.html
19:13:46 <wizardsmoke> thanks'
19:16:52 <Freneticks> Somebody can give me monero testnet ? many  faucet doesn't work
19:17:19 <jwinterm> wizardsmoke, you basically only would use rpc wallet if you're running a service with a lot of users and you're automating wallet interaction
19:17:24 <jwinterm> like an exchange or something
19:18:02 <wizardsmoke> jwinterm: maybe I aspire to own tradeogre one day
19:19:23 <jwinterm> I am using it for a project I am slowly working on
19:19:48 <Freneticks> btw is there a realtime api for rpc ? There was a thing in dev
19:19:50 <jwinterm> the commands are all basically exactly the same as cli wallet, just made from another program
19:20:23 <jwinterm> Freneticks, I think there was plans to put in like push notification type things, but don't think it was ever added
19:20:29 <jwinterm> not sure tho
19:22:15 <Freneticks> jwinterm: because log show when incoming money are received
19:22:35 <Freneticks> i thing there was a rabbitmq thing not sure where it is
19:22:56 <selsta> is this related? https://github.com/monero-project/monero/pull/6418
19:23:13 <jwinterm> zeromq I thought, but yea
19:23:45 <jwinterm> ohyea, maybe it's finally coming selsta
19:24:11 <yanmaani> jtgrassie: In your self-select pool implementation, is there any disincentive to making empty blocks, or charging fees out-of-band?
19:27:02 <yanmaani> from what I can see, share_t is only height, difficulty, address, and timestamp
19:32:05 <yanmaani> on lines ~680 in pool.c, it seems like you use the total fees in the found block when paying out, no?
19:37:54 <wizardsmoke> with wownero there's no limit to what kind of wealth we may achieve
20:06:31 <visualshock> What is the difference between wallet and account?
20:07:00 <selsta> one wallet can contain multiple accounts
20:07:16 <visualshock> So my wallet currently has 1 account?
20:07:23 <selsta> are you using the CLI?
20:07:27 <visualshock> yes
20:07:36 <selsta> yes, you can create a new account with account new
20:07:46 <selsta> every account has their own balance
20:08:16 <selsta> and history
20:13:44 <jwinterm> every account has its own seed?
20:14:21 <selsta> no
20:17:14 <midipoet> I still don't get how accounts work :-( So a seed can generate multiple main (4...) public addresses, and each main address can generate multiple subaddresses (8....)?
20:17:41 <yanmaani>  Yeah, sort of like how derive paths in Bitcoin work
20:20:44 <selsta> midipoet: subaddresses have two indices (major, minor)
20:20:54 <selsta> subaddress(0,0) = 4... main public address
20:21:03 <selsta> all other subaddresses start with 8
20:21:22 <selsta> the major index are accounts, the minor address are subaddresses
20:21:45 <selsta> so 1 wallet (1 seed) can have multiple accounts with multiple subaddresses in them
20:23:32 <selsta> not sure if that is more clear lol
20:24:55 <selsta> https://monerodocs.org/public-address/subaddress/ is a good read and also explains accounts in more detail
20:26:47 <jwinterm> ic
20:26:49 <jwinterm> thanks selsta
21:59:25 <newyearday> what this line do at basic.h            "if (std::is_same<Archive<W>, binary_archive<W>>())"
22:00:10 <selsta> https://en.cppreference.com/w/cpp/types/is_same