13:08:20 <nonie> (-(-_(-_-)_-)-)
14:02:17 <nonie> Does anyone happen to know the maximum number of possible accounts for monero?
14:04:18 <azy> realistically, i think it might come down to the maximum the wallet can handle
14:07:20 <nonie> I want to use this rpc call: https://www.getmonero.org/resources/developer-guides/wallet-rpc.html#get_height
14:07:48 <nonie> What is the maximum id number i can call here?
14:11:31 <nonie> Or maybe I just limit it to 10 digit. Should be sufficient - until it is not.
14:11:53 <azy> did you link the right call? that just returns the amount of blocks in the chain
14:13:34 <nonie> But i have to pass the id.
14:13:45 <nonie> id = account
14:14:04 <moneromooo> If by accounts you mean number of subaddress-accounts, 2^32. If number of possible secret keys, around 2^252.
14:14:23 <azy> nah theres no inputs for get_height, id = 0 always i think, that's returned by the rpc, not input by the coder
14:14:30 <moneromooo> Height can in theory go to 2^64.
14:15:02 <azy> is there a way to load a specific subaddress index yet? i still have 0.05 in some stupid number
14:15:29 <moneromooo> 10 decimal digits for height should be enough for ~ 38 thousand years.
14:15:32 <nonie> Good to know
14:15:43 <moneromooo> No.
14:15:56 <moneromooo> I'll add that to my list.
14:20:30 <mujo> Hello, is there a common issues page? I've started the GUI and it's stuck at "2020-02-21 14:14:46.505	I Synced 1017016/2038490 (49%, 1021474 left)
14:20:30 <mujo> 2020-02-21 14:14:46.507	I [batch] DB resize needed"
14:21:13 <moneromooo> What's the output of "status" and "sync_info" ? Paste on some paste site, not here.
14:21:55 <moneromooo> Otherwise, monero.stackexchange.com has a number of these questions, though some do tend to become obsolete with time.
14:22:36 <moneromooo> (those are daemon commands, I think you can enter daemon commands somewhere in the settings)
14:24:07 <nonie> That was a false assumption on my part. The id != account. »assumption« is the mother of all fuck ups.
14:26:12 <moneromooo> Good thing my mother's not named Assumption. I dodged a bullet there.
14:27:23 <nonie> XD
16:27:07 <yanmaani> gingeropolous: I saw your post on Reddit
16:27:15 <yanmaani> did you consider using the BitTorrent network for this?
16:27:55 <yanmaani> so, you send out pings to random IPs - just UDP packets. Can be done async. Then, you establish a connection to the network from whatever comes back.
16:28:14 <hyc> yes, but we need bittorrent nodes to cooperate.
16:28:23 <yanmaani> Then you ask the DHT to find 'seeds' for the 'torrent' with 'info hash' sha1("monero")
16:28:29 <yanmaani> hyc: no
16:28:40 <yanmaani> you can just insert random stuff into the DHT
16:29:01 <yanmaani> the key can be any arbitrary bitstring of 160 bits, the value is fixed to be the IP of the sender
16:29:15 <yanmaani> C implementations of kademlia DHT are pretty tiny too
16:29:17 <moneromooo> Does this impair bittorrent as a whole (beyond extra traffic) ?
16:29:18 <yanmaani> and bitcoin DHT is big
16:29:31 <yanmaani> moneromooo: no, I don't see how it would
16:29:47 <yanmaani> it impairs IPv4 somewhat to send out UDP packets to random IPs but it's not very much
16:29:50 <moneromooo> Do you not see despite knowing well enough to know if it would ?
16:29:56 <hyc> I'm sure someone would get annoyed that we were leeching on them
16:29:57 <yanmaani> but your load on the network is negligible
16:30:10 <yanmaani> hyc: You're not leeching, you're inserting into the DHT
16:30:20 <yanmaani> moneromooo: I do not see how it would impair bittorrent.
16:30:42 <asymptotically> aren't you just moving the problem? you need DNS seeds to bootstrap your connection to the bittorrent dht
16:30:58 <yanmaani> the algorithm is as such: depending on your IP you are responsible for a certain subset of keys. To insert, find nodes at that IP and tell them you want to insert
16:30:59 <hyc> indeed
16:31:06 <yanmaani> asymptotically: not really
16:31:09 <yanmaani> the BitTorrent DHT is bigger
16:31:14 <moneromooo> That's what you said before. I'm asking whether you do not see how it would because you do not know much about it, or because you know enough to tell with reasonable certainty that it would not.
16:31:25 <yanmaani> quoth reddit post:
16:31:27 <yanmaani> "Surprisingly, the numbers aren't that bad. For a network size of bitcoin, for instance, you only need to randomly scan like 5k IP addresses to statistically find an IP address running a bitcoin node"
16:31:29 <asymptotically> yanmaani: ah you meant it will make the random bruteforce faster?
16:31:32 <yanmaani> BitTorrent DHT is much bigger
16:31:36 <yanmaani> yes
16:32:14 <hyc> there's going to be a storage cost for bittorrent nodes to record these entries
16:32:15 <yanmaani> in Bitcoin you need to open 2^32/N TCP connections
16:32:30 <yanmaani> in BitTorrent you need to "open" 2^32/M UDP "connections"
16:32:36 <hyc> if all of bitcoin and monero started advertising their nodes this way
16:32:43 <yanmaani> hyc: yes, but it's tiny
16:32:49 <yanmaani> they are stored in RAM
16:33:22 <sech1> I already proposed the exact same idea a couple of months back (to bootstrap from bittorrent DHT network)
16:33:36 <sech1> there are literally millions of active DHT peers
16:33:36 <hyc> sech1 what happened to the suggestion?
16:33:45 <sech1> hyc it didn't go anywhere
16:33:56 <moneromooo> sech1: and you, do you know enough about it to tell whether it'd impair the bittorrent network ?
16:34:28 <sech1> negligible
16:34:31 <moneromooo> By impair, I mean annoy enough for them to want to do something about it.
16:34:46 <sech1> a few hundred nodes would store 160-bit hash with bootstrap data for Monero
16:34:56 <sech1> it's just another torrent hash for them
16:35:01 <moneromooo> Should I read "you know enough to be reasonably certain the impairment would be negligible" ?
16:35:05 <sech1> and they only store it in RAM, not even on disk
16:35:07 <hyc> .... how do we control the volume of data that gets injected?
16:35:22 <sech1> moneromooo yes
16:35:27 <moneromooo> Thanks.
16:35:36 <sech1> I did quite a bit of development for torrent sites back in 2000's
16:35:38 <hyc> if we just add this feature, 100% of monero nodes start advertising themselves to the bittorrent network
16:35:46 <sech1> not that I'm proud of it, lol
16:35:49 <yanmaani> a downside is that you don't know the port for DHT
16:36:20 <yanmaani> moneromooo: I don't think you need to worry, it's sort of officially supported
16:36:22 <yanmaani> https://www.libtorrent.org/dht_store.html
16:37:05 <hyc> because the idea is to get away from centralized node management. thus there is nothing to distinguish a "seed" node from any other node.
16:37:16 <moneromooo> Sounds good (that page's blocked though).
16:37:28 <yanmaani> hyc: If you're really worried, you can ramp it up gradually
16:37:35 <hyc> how do we do that?
16:37:41 <yanmaani> on each start, generate a random number mod 100
16:37:50 <yanmaani> if number is below N, announce to dht
16:37:56 <yanmaani> vary N with each version
16:38:41 <yanmaani> that said I don't think it's anywhere near a problem. How many Monero nodes are there even? 10k?
16:39:27 <moneromooo> sech1: I recall a discussion about this. Did it die off due to nobody doing anything, or was there a roadblock ?
16:39:50 <sech1> no roadblocks, discussion just stopped
16:40:15 <sech1> My proposal was to just have a single unique 160-bit hash for all Monero nodes
16:40:26 <sech1> then they would find all peers with this hash in DHT
16:40:29 <sech1> and their IPs
16:40:37 <sech1> and then connect to IP:18080
16:40:54 <sech1> so it's literally just one additional hash in DHT
16:40:59 <yanmaani> A good idea could be to try and get the Bitcoin community on board - they presumably have the same issue
16:41:04 <hyc> if this is actually an intended use of the DHT, it all sounds good
16:41:20 <yanmaani> hyc: it has an extension to store arbitrary data
16:41:24 <moneromooo> Added to my list. I know close to nothing about bittorrent though, so if anyone wants to run with it, feel free ^_^
16:42:18 <hyc> I used to work on rtorrent. another C++ codebase I hated.
16:42:54 <yanmaani> One problem I can see with this is that the chaos of the DHT works against us.
16:43:01 <yanmaani> in Bitcoin/Monero, all nodes listen on a certain port
16:43:11 <yanmaani> in BitTorrent, they vary it due to ISP detection efforts
16:43:38 <sech1> DHT is battle tested against multiple shutdown/block attempts
16:43:42 <hyc> so if we have to poll random IP addresses *and* ports, that makes it a bit harder
16:43:47 <sech1> all those anti-piracy battles
16:44:16 <yanmaani> hyc: Right. But we have a bit of respite in that not all clients use random ports.
16:44:30 <sech1> hyc you can just connect to any popular torrent tracker, get the most popular torrent hash from there, and then ask tracker for the list of peers
16:44:42 <sech1> 90% of these peers will be DHT enabled
16:44:47 <yanmaani> predictable_port*total_bittorrent might be greater than total_monero
16:44:51 <hyc> sech1: that brings us back to square 1
16:44:57 <yanmaani> sech1: right but then you could just ask the tracker for the monero hash
16:45:03 <yanmaani> and then you could just run your own tracker
16:45:10 <yanmaani> and then you have re-invented the seed node
16:45:22 <hyc> exactly. square 1. we don't want that.
16:45:22 <sech1> I'm talking about chicken-egg problem
16:45:34 <yanmaani> if so a better solution could be to ship a file of a few thousand known DHT/Monero nodes with each release
16:45:35 <sech1> how to find the first peer to connect to
16:45:42 <hyc> the chicken-egg problem is what seed nodes are for, which we are trying to eliminate.
16:46:14 <yanmaani> 1 ipv4 addr + port is 6 bytes, so 256k would enable you to ship 44k nodes
16:46:40 <hyc> That is a lot of data for us to manage between releases
16:47:15 <hyc> I prefer the IP multicast solution. we just decide on a multicast group ID, send a UDP packet to the mcast group, and talk to all the nodes that respond.
16:47:27 <sech1> multicast doesn't work on Internet
16:47:46 <hyc> adoption will follow demand.
16:47:56 <yanmaani> hyc: is it? Isn't the monero package several hundred mb?
16:48:05 <hyc> every IPv6 router has support for it
16:48:15 <yanmaani> win64 installer is 82.1mb
16:48:16 <hyc> most IPv4 routers by now should too
16:48:33 <hyc> yanmaani: 44k IP addresses would be a PITA to administer
16:48:50 <yanmaani> would it? Just run a script that scrapes the DHT a few times and spits out random nodes
16:48:58 <sech1> hyc why? Just scan the Internet for Monero nodes before each release and update the file
16:49:00 <asymptotically> rip deterministic builds
16:49:01 <yanmaani> data quality can be complete garbage, even if just 1% are good that's fine
16:49:27 <yanmaani> asymptotically: you could put it in the git tree.
16:49:32 <yanmaani> ugly yes? but deterministic af
16:51:50 <yanmaani> So you start off with the DHT, then query all the nodes for their friends and build a list of a few hundred thousand. Then you query them repeatedly to check uptime. The most robust and well-connected nodes make it into the source tree
16:53:22 <hyc> this is still not a hands-off solution. it is fundamentally the same as administering seednodes
16:54:02 <yanmaani> yes although there is no server running that can disappear
16:54:13 <yanmaani> and even with high attrition rates probably some of the nodes will be running years from now
16:54:46 <asymptotically> but if we're going to embed a big blob of thousands of ips into a release, why not just embed the addresses of monero nodes?
16:55:14 <sech1> yep, just scan them all: "On a computer with a gigabit connection, ZMap can scan the entire public IPv4 address space in under 45 minutes."
16:55:45 <yanmaani> yeah so why not do that? that sounds pretty reasonable actually
17:15:35 <yanmaani> OK, so I did some ad-hoc research. ~15% of nodes use port 6881, which should be good enough.
17:17:41 <yanmaani> so round this to 10% and using 10 million from Wikipedia we have 1 million nodes => need to query 4300 nodes
17:21:32 <sech1> So only 4300 UDP packets, barely an inconvenience
17:28:04 <gingeropolous> is this still a random brute force? or is there still an IP list?
17:32:09 <asymptotically> would distributing a peerlist bin on getmonero.org along with the blockchain dump not be an easy solution? then nobody gets upset about large files being in git, or by thousands of packets being blasted everywhere
17:32:23 <asymptotically> then anyone that wanted to use it over dns seeds could just start monerod with something like --go-away-dns --import-peerlist ./peers.bin
17:32:43 <gingeropolous> thats the same problem, just repackaged
17:33:57 <asymptotically> but people are probably already going to be there to download the daemon to begin with
17:35:57 <gingeropolous> i mean, yeah true. but designing for 100% perfect conditions is a bit......... well, its not how I think things should be done for monero. If we were building a new p2p farmville sure
17:38:12 <gingeropolous> i mean, we need solutions for the scenario where the monero project has been attacked, all of its resources are dead. Monero source code is floating around on torrents and random websites, and you may have even gotten yours from a friend on a USB stick. The training wheels are off.
17:38:39 <asymptotically> your friend can put a peerlist onto the memory stick, or he can give you the address of his node
17:38:58 <gingeropolous> yeah, true.
17:40:03 <yanmaani> gingeropolous: Random bruteforce
17:40:27 <LatitudeSnowbird> shitting up random hosts trying to find peers is questionable
17:40:27 <gingeropolous> bittorent using random ports isn't a problem?
17:40:35 <yanmaani> see above
17:40:40 <yanmaani> about 15% use port 6881
17:41:13 <yanmaani> LatitudeSnowbird: it's not really shitting up though. We are talking about a message <100b which will probably get filtered by firewall
17:41:48 <gingeropolous> well agreed, its questionable. But if you don't have functioning seed system, and your don't have any friends that have peer lists... how do you connect to the network
17:42:34 <yanmaani> the only issue I see with this is that it relies on ipv4
17:42:40 <gingeropolous> its a measure of last resort. When things are fine, sure, monerod will use the seeding system. But when things aren't fine... well, we need something.
17:42:46 <yanmaani> which, if we are going to be honest with each other, will never ever die
17:43:09 <gingeropolous> i got lost in multicast a bit... something about ipv6 has it native something something?
17:43:24 <yanmaani> agreed. A simple solution might be to cascade. So it first tries regular bootstrap, then bittorrent bootstrap, then brute-force
17:43:55 <yanmaani> I don't think it's that big a problem anyway. The adversarial conditions you outline already exist
17:44:15 <yanmaani> there's a P2P network in Japan called Perfect Dark. For obvious reasons, they can't run seed nodes.
17:44:31 <yanmaani> What do you do? Well you look around on forums or whatever for a nodelist to import.
17:44:33 <yanmaani> boom, done
17:44:53 <yanmaani> Monero could do this with Tor easily as an option of last resort.
17:45:10 <asymptotically> gingeropolous: if you don't have any friends that use monero, who's going to send monero to you, or who are you going to send monero to?
17:45:45 <LatitudeSnowbird> fwiw even bittorrent with dht uses a centralized node to bootstrap :)
17:45:56 <yanmaani> asymptotically: random people on the internet?
17:46:35 <asymptotically> yanmaani: yeah :D and you can peer with those random people or ask them for their peer list
17:47:02 <yanmaani> right
17:47:28 <yanmaani> if shtf, the most likely scenario is that people run some sort of onion site where you could download monero, or ship a peerlist with the torrents
17:48:56 <LatitudeSnowbird> or if you are really desperate to find peers, masscan/zmap goes a long way
17:50:43 <yanmaani> sure but in the case that monero is outlawed you may have a hard time finding any clearnet nodes
17:50:57 <selsta> I think we shouldn’t over engineer a solution unless it is noticeably better than the current seed nodes.
17:51:59 <yanmaani> the not over-engineered solution is to add a box in the UI "bootstrap from arbitrary node or load list from file"
17:52:21 <yanmaani> although there is something sort of clean with doing away with the seednodes
18:23:30 <gingeropolous> selsta, can you define better? Because in terms of decentralization, i'd argue anything is better than seed nodes
18:24:09 <selsta> Anything?
18:24:52 <gingeropolous> i mean they are kinda de-facto centralized.
18:25:01 <gingeropolous> but no not anything. elephant transport, for instance, not a good solution
18:25:15 <selsta> Would using the bittorrent network, which also relies on seed nodes be decentralized?
18:25:59 <gingeropolous> i dunno. im neither here nor there on that solution. it sounds like kicking the can to someone else kinda.
18:27:14 <gingeropolous> if indeed they use seed nodes, then its effectively relying on some other decentralized network that uses a centralized bootstrapping mechanism
18:28:31 <selsta> What would happen if a node connects to a malicious node through a decentralized seed node system?
18:28:41 <gingeropolous> which is probably why i came up with the trans peer thing. because if all of the p2p networks worked together, we'd all eat lollipops and drink butter beer
18:29:07 <gingeropolous> i dunno. what would happen if a node connects to a compromised seed node?
18:29:39 <Mochi101> The p2p thing sounds awesome gingeropolous... and I literally was on the edge of my seat.
18:29:46 <Mochi101> Like... really exited.
18:29:47 <gingeropolous> presumably witha  decentralized system, you could compare multiple
18:29:54 <gingeropolous> i.e., you could portscan for 1 open port.
18:30:09 <gingeropolous> and then keep scanning for another one
18:30:19 <selsta> I think compromised seed nodes are way more unlikely than in a decentralized system which you can easily sybil attack.
18:30:31 <gingeropolous> you could timeout on some number, and then use what you';ve got
18:30:34 <Mochi101> Bob sounds like such an fun guy too.
18:30:37 <selsta> But like I said I don’t know how serious something like this would be.
18:32:41 <yanmaani> selsta: The BitTorrent network does not rely on seed nodes.
18:32:58 <yanmaani> It is possible to use a tracker instead, or pre-existing nodes. If all the seed nodes were shut down tomorrow it would still work
18:33:06 <selsta> Same for Monero.
18:33:13 <gingeropolous> well yeah thats just a built in peer list
18:33:16 <gingeropolous> right?
18:33:22 <yanmaani> Yes, but you can bootstrap using the pre-existing BT DHT
18:33:29 <yanmaani> You can't bootstrap with the Monero network
18:33:35 <yanmaani> or well you can but it'll take a lot of packets
18:33:49 <gingeropolous> right, because the entire peer list isn't stored as a DHT
18:34:39 <yanmaani> No, not because of that.
18:34:50 <yanmaani> Even if the Monero network is alive and kicking, I can't join it without a seed node.
18:35:04 <yanmaani> But the alive-and-kicking-ness does not strictly depend on the existence of seed nodes.
18:35:21 <selsta> What is the difference between a seed node and a normal node in Monero?
18:35:25 <yanmaani> The BitTorrent network can be joined without a seed node by brute-force, and even if the seed nodes die it can still keep working.
18:35:29 <selsta> Apart from that seed nodes are hardcoded.
18:35:33 <yanmaani> none
18:35:49 <yanmaani> (the BitTorrent network can find nodes from other sources than hardcoded dht seeds)
18:36:08 <gingeropolous> by scanning?
18:36:51 <yanmaani> no, not only
18:36:58 <yanmaani> so the ways you get into the Mainline DHT is
18:37:01 <milkt> i heard that using remote node with monero-wallet-cli can reduce privacy, but does security remain in same level?, or does using remote node reduce security about my wallet or fund?
18:37:07 <yanmaani> 1) talk to a router (hardcoded seed node)
18:37:24 <yanmaani> 2) talk to any of your peers from whom you are downloading torrents
18:37:33 <yanmaani> and you can get peers by PEX, DHT, or tracker
18:37:43 <yanmaani> PEX is when you ask your peers for more peers, not applicable
18:37:57 <yanmaani> but trackers are another mechanism. Trackers are distributed within torrent files.
18:38:10 <yanmaani> 3) Torrent files may contain DHT node hints
18:38:16 <yanmaani> so it's incredibly antifragile in this way
18:38:29 <yanmaani> we don't trust that the BitTorrent network's seed nodes keep working, just that the DHT network does
18:38:30 <gingeropolous> but 2 and 3 sound like you've already connected to the torrent network....?
18:38:31 <selsta> What is the difference between specifying a node IP address in Monero and specifying a torrent file?
18:38:39 <selsta> Both seem like manual work.
18:38:49 <yanmaani> gingeropolous: no, trackers are run by random people
18:38:53 <yanmaani> and included in torrent files
18:38:54 <moneromooo> It reduces the security. Can't steal outright though.
18:39:00 <yanmaani> selsta: You download torrents anyway, so it's 'free'
18:39:25 <selsta> Do I?
18:39:25 <gingeropolous> ok. so basically, the way torrent really does this is that their..... thing of value.. is a separate file that you can get outside of the network
18:39:26 <moneromooo> And I remember this discussion from when sech1 was talking about it. I think someone also claimed trackers arne't seed nodes too.
18:39:31 <yanmaani> If you don't have DHT nodes, but you download a torrent, that contains some (random) DHT nodes to get started.
18:39:39 <moneromooo> In the end, we wrked out it was basically the same.
18:39:40 <yanmaani> gingeropolous: It's one of their solutions yes.
18:39:41 <gingeropolous> so you download a torrent from the internet
18:39:48 <yanmaani> corret
18:39:55 <gingeropolous> so basically other people self host something that has seeders
18:40:10 <yanmaani> you search for 'linux ISOs' on site A, get a torrent file (basically a file hash), ask the tracker/DHT for peers
18:40:25 <yanmaani> gingeropolous: no it's segregated. Torrents are just a few k, adn the bittorrent network doesn't do indexing
18:40:27 <milkt> moneromooo: can you explain bit more about how much does using remote node reduce security
18:40:31 <moneromooo> The stranger's node can feed you fake blocks. If it knows your address, it can make it look like you got some money. But you did not.
18:40:47 <moneromooo> It can DoS you (claim there are no blocks, when there are).
18:41:48 <selsta> Adding the bittorrent network into this sounds like over engineering if the difference in the end is googling "linux iso" or "monero node ip"
18:41:52 <gingeropolous> milkt, and also keep in mind you should be concerned about untrusted nodes, ran by random people
18:41:55 <selsta> instead*
18:42:09 <gingeropolous> you can have your own remote node, and there are minimal implications for that
18:42:24 <gingeropolous> but those can all be covered by proper opsec (encrypted channels with the tubes etc)
18:42:36 <gingeropolous> tunnels, tubes, and channels oh my!
18:42:51 <moneromooo> And bananas.
18:42:51 <Quotes> peanut butter jelly time!
18:42:56 <moneromooo> Or bananae... ?
18:43:04 <milkt> i'm running own node currently, but disk space running out soon
18:43:05 <gingeropolous> clearly its bananananananananananas
18:43:17 <milkt> i'm wondering about what is worse case scenario which can happen when i'm using remote node
18:43:19 <moneromooo> Ah yes. Clearly plural.
18:43:59 <gingeropolous> milkt, if its your remote node, the worst case scenario is that...... it gets hacked and then somehow messes with yah
18:44:00 <moneromooo> The worst case... Your ISP confuses monero traffic for child porn traffic, the police bashes your door in and "accidentally" shoot you.
18:44:05 <gingeropolous> but thats the same with your own node at home
18:44:28 <milkt> eh i mean about worst case about my wallet and fund mostly
18:44:40 <selsta> milkt: You can prune your node.
18:44:41 <milkt> privacy is not a concern now
18:44:44 <moneromooo> Worst case in pratice is "it doesn't work".
18:44:54 <gingeropolous> yeah you should just prune milkt
18:45:10 <milkt> i'm considering pruning as well
18:45:27 <gingeropolous> can get it down to 25 GB. though i still don't know if that works in place, like with an existing file
18:45:30 <moneromooo> To prune an existing db, you need an extra ~25 GB temporarily.
18:45:45 <gingeropolous> see that makes the brain hurt
18:45:57 <milkt> so there is possibility that my transaction can be rejected, or getting false block information when using remote node?
18:46:01 <gingeropolous> when im running out of space i rarely have 25 GB of extra space
18:46:04 <moneromooo> Yes.
18:47:12 <gingeropolous> in fact I'd probably most likely nuke the existing db and resync from the network with pruning enabled
18:47:55 <milkt> so malicious remote node can reject or give false information, but can't modify transaction or consume my fund, is it correct?
18:48:05 <gingeropolous> correct
18:48:15 <milkt> thank you
18:54:05 <gingeropolous> so is there anything shareable about the monero network that people would want to host for downloads
18:56:37 <moneromooo> Binaries and gitian signatures.
18:57:50 <moneromooo> I was gonna say "and instructions to check", but that kinda defeats the purpose since an attacker would put wrong instructions :/
18:58:48 <Mochi101> Pictures of fluffypony
19:04:07 <moneromooo> You don't mean... *those*... pictures ?
19:05:11 <hyc> weren't those pictures erased when ETH rolled back?
19:07:46 <gingeropolous> i was gonna say "lets put an IP address in the XMR address!" but then privacy
19:09:07 <hyc> this is the big problem I see with the "ping 2^32 address" approach as well. makes your own node stick out like a sore thumb
19:09:23 <hyc> but perhaps that doesn't matter if we're already justing using plaintext connections
19:09:49 <Mochi101> It's a difficult problem.
19:10:27 <Mochi101> How about we all agree to write node ip addresses in the bathroom stalls whenever we use a public restroom?
19:10:40 <gingeropolous> now thats a protocol
19:10:57 <Mochi101> I can see the news headlines already.
19:11:10 <Mochi101> "Monero Gives P2P a New Meaning"
19:11:18 <gingeropolous> lol
19:11:37 <moneromooo> I'll rename to monerolooo if it helps.
19:11:44 <hyc> LOL
19:11:44 <Mochi101> hahahaha
19:11:46 <Mochi101> nice
19:12:08 <gingeropolous> it could be a new mandate for all monero sticker makers
19:12:09 <hyc> secure and private - like a restroom
19:12:15 <gingeropolous> always include an ip address on your stickers
19:12:28 <gingeropolous> else, you are part of the problem
19:13:35 <gingeropolous> same with shirt makers
19:13:58 <gingeropolous> any merch!
19:14:09 <gingeropolous> merch without IP is blasphemy!
19:15:08 <gingeropolous> although still targetable
19:15:16 <hyc> On IPv4 it would have made sense to use a single multicast group as a directory of all participating P2P protocols
19:16:02 <hyc> since the address space is kinda limited there. every node of every P2P project would participate; broadcast its own existence and maintain a small table of everything it hears.
19:16:29 <hyc> i.e., it only needs to keep a few records for each protocol, and can keep a list of as many protocols as it wants to save space for
19:16:51 <moneromooo> OTOH, thanks to bitcoin's success, we now have a huge number of dross p2p shite spamming everything...
19:17:08 <hyc> on IPv6 their approach won't work any more
19:17:12 <hyc> but multicast will
19:17:27 <hyc> too bad there are no competent network protocol guys in Bitcoin
19:17:53 <gingeropolous> yeah randomly searching through ipv6?
19:18:05 <moneromooo> They don't ? If not, it won't be long before one gets interested and joins.
19:18:30 <gingeropolous> well they built fibre
19:19:00 <gingeropolous> but thats different
19:19:10 <hyc> a competent protocol guy post-2008 would have kept IPv6 in mind for any solutions they built
19:20:14 <hyc> hell, bitcoin itself could have had enough critical mass to make internet-wide multicast adoption happen
19:20:39 <hyc> bittorrent has critical mass, but too much piracy associated with it
19:20:56 <moneromooo> Make it well in monero, then try to get bitcoin to use it :D
19:21:15 <hyc> just like CT? :P
19:21:35 <moneromooo> Yeah, works both ways.
19:21:42 <gingeropolous> yeah lookin forward to the librecast response
19:22:09 <hyc> Brett @ librecast is a friend of mine, we've talked about this before
19:22:46 <gingeropolous> ah. does he want a pet project to showcase the tech? :) :) :)
19:23:23 <hyc> I suspect he does. the last time we talked, nobody in monero was talking about seed discovery
19:23:26 <hyc> maybe now's the right time
19:29:36 <hyc> https://twitter.com/brett_sheffield/status/1230937351624495104
19:30:04 <hyc> kind of what I was afraid of. currently need to tunnel if intervening network isn't mcast-enabled
19:31:48 <hyc> so for now - lol - you need seed multicast routers
19:32:19 <yanmaani> gingeropolous: That's pretty much an analogue of how BitTorrent does it
19:32:46 <yanmaani> it's not that silly, as you could always use an onion, but it's fundamentally ugly and brittle
20:02:11 <kinghat> was there a talk about librecast on FOSDEM this year?
20:02:19 <kinghat> scanning the youtubes
20:04:13 <hyc> yes
20:04:23 <hyc> I think librecast itself was only a lightning talk
20:05:08 <hyc> https://www.reddit.com/r/Monero/comments/f6y8xn/ccs_idea_maybe_someone_can_write_it_up/fia1p3t/
20:06:18 <kinghat> ah tyvm hyc 🙏 havent been on the reddits for a min.
20:09:08 <kinghat> oo they even linked the linux.conf talk: https://www.youtube.com/watch?v=IO2_b8EeJws
21:31:45 <azizLIGHT> hmmm, how do i enable mining via the wallet? i followed all iterations of the wallet command but i get error https://paste.ubuntu.com/p/M8BVHzkm2K/
21:33:09 <asymptotically> azizLIGHT: try start_mining 4 true
21:34:06 <azizLIGHT> ah ok, thank you
21:34:24 <azizLIGHT> that worked, just wasnt sure what argument it had aproblem with