00:39:00 vtnerd_: in tx_pool.cpp, when making a block template: 00:39:05 if (!m_blockchain.get_txpool_tx_meta(sorted_it->second, meta) && !meta.matches(relay_category::legacy)) 00:39:34 That && is clearly wrong, but I'm not sure what the second part should be. 00:39:48 This got added with the dandelion code. 00:47:52 moneromooo: ok, looking now 00:49:10 thanks 01:04:40 crap, definitely wrong. the `&&` -> `||` but otherwise that should be the check you want 01:04:49 perhaps in its own if statement if another message should be displayed 01:05:36 `|| !matches_category(legacy)` will return true with `local` and `stem` transactions. but `do_not_relay` and every other mode will return false 01:06:30 But you want to mine local ones don't you. 01:06:42 So it should only reject stem ? 01:08:06 umm, maybe? the local mode is either attempting an i2p/tor send or "just before" a d++ stem starts 01:08:45 i.e. if there is no i2p/tor running, it gets "upgraded" to a d++ stem send 01:09:57 Oh. I thought local was "do not relay, I want to mine it". 01:10:09 OK, you did make a distinction with do_not_relay... 01:10:34 Alright, so just || seems good hten. 01:10:36 no that is `none`. yup, legacy was an attempt to mean "this is what we have always done" (i.e. there wasn't this "hidden" set of txes) 01:12:06 Do you want to send a patch or shall I ? 01:13:51 I can do it I suppose, doesn't seem to matter really 01:15:04 should this get included in v0.16.0.1? 01:15:17 if yes please PR against both branches vtnerd_ 01:20:57 I guess it should, or a pool using this will leak stem txes. 03:14:42 0.16 GUI does not show proper transaction status when transaction failed. Stuck at pending. (CLI shows failed) 03:33:51 Bobtette: I second that. Had 2 transactions stuck on GUI as pending, but sent same output normally using monerujo 07:15:15 Do blackholed tx's get put back into the a node's non-hidden transaction pool? 07:15:15 I'm asking because I scrape a decent chunk of available public remote nodes (~300) and re-relay any transactions that do not show up in my node's mempool 07:15:21 This came about after once particular incident where some guy had make a $10k transaction to a different wallet 07:15:28 Both wallets happened to be connected to the same remote node, so the transaction showed up in his second wallet as waiting to be confirmed 07:15:33 He then deleted his first wallet thinking the transaction would clear. 07:15:40 But no, the transaction was stuck in the node's mempool. When it took longer than expected for the transaction to confirm he switched to a different remote node and the incoming transaction disappeared. 07:15:48 I read his panicked post only after 26 hours so I rushed to code up a scraper so I could rescue his transaction, which was successful. 07:16:15 I don't want to see that happen ever again, so I kept the scraper running as a public service. So far it's rescued over 500 transactions in 2 months time. 07:16:15 Monero's netcode seems to just give up if it fails to relay a transaction and appears to make no attempt to fix it. 07:16:19 So you have properly configured nodes drop random transactions every once in a while. 07:16:29 Wallets should really have a way to resubmit stuck transactions to a different node. 07:16:35 Or inform wallets that they were unable to relay the transaction. 07:16:54 Apologies for the rant, just really tired of providing support for this issue. 10:25:47 lol https://github.com/monero-project/monero/issues/6649 10:25:51 moneromooo: what does it mean?? 10:26:14 we should maybe add that it can be popped on to GitHub or sent on IRC :) 10:43:35 salü ^^ 10:43:37 does anyone know what that means in the deamon 10:44:53 Cheers in quebecoise ? 10:46:29 ??? 10:47:22 Try pasting it on https://paste.debian.net or https://paste.ubuntu.com and paste the link here. 10:49:14 Or better, pm the link to moneromooo. 10:51:13 (y) 10:58:40 The wallet *will* complain if it fails to send it to the node. 10:59:07 The node will not if if fails to send to other nodes, but it will retry to send them later, and you can send again with relay_tx manually. 10:59:35 If it's not your daemon, then why the hell are you using a decentralized currency in the first place... 11:00:29 fluffypony: the wording seems pretty clear. I'll try to reword it on the issue. Thanks. 11:49:15 moneromooo: >but it will retry to send them later -> Could you point me to the relevant code for this? 11:49:21 Do you expect every user with a mobile wallet to connect to a remote node that they run at home and make sure they know how to call relay_tx in case it fucks up? 11:49:25 If that is the case you greatly overestimate the technical competence of the average user. 11:49:35 Imo Monero should be accessible to users that seek reasonable privacy below nation state level threat models. 11:49:41 Network level metadata is much less of a concern than data stored on the blockchain. The blockchain is forever. 11:49:48 If connecting to a third party remote node (e.g. simple mode) is not a supported use-case it should just be removed. 11:49:58 All I'm saying is the wallet should be better at handling nodes that don't do what they are supposed to do. 11:50:04 A relatively simple change of storing the raw tx until it is included in a block, and allowing it to be copied to the clipboard so it can be manually relayed via a tx pusher would already do so much for UX and lower a lot of burden on support. 11:50:06 See m_txpool_auto_relayer.do_call(boost::bind(&core::relay_txpool_transactions, this)); 11:50:14 thanks 11:50:26 And yes, I expect people to run their node. Otherwise what's the point ? 11:54:15 The tx is kept around IIRC, so a command to display it should be simple enough. 11:54:45 Removing the ability to connect to a third party node would also likely remove the ability to connect to your own. 11:54:46 That would be great. 11:55:18 And I recognize some people just can't run their own, not out of sheer mindlessness, but circumstances. 11:55:19 With simple mode/ bootstrap mode you connect to a random node, no? 11:55:38 Right, What if I'm just concerned with private transactions and don't care for decentralization? Is there any alternative? What if I don't have 35 GB to store a blockchain? What if my bandwith is limited? What if I'm network capped? What if I don't have the technical competence to maintain my own node? What if I want to start using Monero when I'm on the go? 11:55:52 bootstrap mode proxies to another node. There might be a random setting now, kinda ring a bell. 11:57:25 If you don't care about decentralization, then you don't care much about your privacy (or you're just ignorant of the realities that any privacy you have that's at the whim of a third party is not really privacy). 11:58:32 Seriously, if you want to improve it, do it. Don't expect to moan about it to get someone who doesn't like it to do it. 12:00:03 So many problems (including this one) happen because someone surrenders their agency to a third party. 12:00:20 Making this better is just papering over hte cracks. 12:00:42 The stranger can always screw you if it chooses to, if you rely on it to do your job. 12:02:01 And fuck docker eating > 12 of disk space for a single image build, wtf. 12:03:54 People should work on making the "run your node" case better, rather than "use a stranger's" better. 12:13:34 Sure, I support that viewpoint. But, sometimes there is just no alternative. People are going to use remote nodes whether they be better off running their own node or not. Maybe that's dumb, whatever, it sure does make Monero look like an unreliable piece of software. I know, because I deal with support queries day in day out. Relying on a third party doesn't have to be this brittle, the change I mentioned or the ability to submit to 12:13:34 multiple daemons would reduce 95% of the support cases, I'm sure. 12:13:42 Not asking you to do anything about it, just broadcasting my concerns in the hope that it falls into someone's ears. If I were competent enough in C++ I would do it myself. 12:15:00 I'm kinda on the fence between encouraging improvements there. It appeals to me coding self, but making it easier gives more incentive to give your privacy away :/ 12:16:23 Anyway, there's a recent improvement here. When you connect to a new node, there's an auto tpxool sync. 12:16:54 (so you should not need to wait 4 hours for a retry)) 12:17:15 As far as I can see from reading in the log, the subject of daemons for smartphone wallets did not yet get thrown into the ring. Many people, especially in third-world countries, don't have PCs anymore (or never had one), and running even a pruned node on a smartphone is too heavy still for "normal" people 12:17:25 Of course, only works for honest nodes, and a stranger's may or may not be honest. 12:18:12 Well, maybe we should use grin then. Less privacy, but smaller chain. 12:18:29 Touché. 12:18:58 I'm not sure how much less privacy though. 12:19:14 Don't know however how a Grin node looks from a traffic point of view. Many people have to do with 500 MB or 1 GB a month, or are even on prepaid trafic. 12:19:54 Grin has a deducible transaction graph afaik. 12:20:21 What was an idea for a theoretical improvement - connect to more than 1 remote node, and compare at least some results? 12:21:32 Yes. 12:22:38 A welcome chance to make `wallet2.cpp` even bigger :) 12:23:02 That could work, doesn't have to be a long lived connection. Just need to make sure that your transaction ends up in some other node's pool or blockchain. Then you can be relatively sure that it was relayed to the entire network. 12:23:05 Or you submit the tx directly to multiple nodes. 12:23:45 Uh, we just know introduced Dandelion++ which goes more or less directly against that 12:24:11 Which part? 12:24:22 The "subject to multiple nodes" 12:25:00 Well, probably depends how you choose them 12:25:58 Those people really should use another coin. Buy, I dunno, bitcoin, and use that. Maybe buy monero later if you want privacy while not actively transacting. 12:26:20 Which sounds weird. 12:26:41 I assume the user is connecting to the remote node over Tor. And if both nodes are 'trusted' than I don't see an issue. 12:27:03 I suspect many of the people using stranger's nodes are speculators who don't care about moenro anyway. 12:27:03 Clearnet nodes are bad, but not worse than using Bitcoin. 12:27:50 No I think you underestimate how common this usecase is. 12:28:12 I know what you mean with "using another" coin, but I am regularly in a quite populous third-world country with high corruption, and to just tell them "use another coin" would be a pity 12:29:06 And I am not sure at all whether that other coin would have better security than Monero "even" with remote nodes ... 12:29:19 Yes, and then you're not factoring liquidity, exchange acceptance, services, etc etc 12:29:23 However it would not be our problem anymore for sure :) 12:31:39 If I'm in a third world country and I want to one-off purchase a VPN anonymously. It's easy to do that with Monero, many services accept it. If I boot up Tails and connect to an .onion remote node in what way am I compromising my privacy? 12:31:39 Then someone who is not me gets to design a system where you can use several of these nodes to gather bits and bobs here and there and do your thing. 12:32:40 No, you are surrendering your agency and the security that a PoW chain gives you when you run your own node. 12:32:56 Andd.... I'm off because wtf am I doing here. 12:33:27 Gah. And I'm back with fucking docker and 12 GB for a simple oss-fuzz image. ,sfrsafajfjavj 12:33:31 * moneromooo hates 12:33:43 That did not take long 12:33:56 Oh yeah, I hate 24/7. 12:40:29 And it's back to downloading 1 GB every new try. Thanks docker. 12:40:57 See, not only monero sucks with needing resources. 12:43:41 Did not claim otherwise. And we sure use our ressources wisely for our purpose and our goals. See e.g. fluffyblocks. 14:08:54 selsta: you seem to be planning a new release. When is that, if you know already ? 14:16:32 moneromooo: would like to do merges soon and then we can talk what is left to do before we can tag 14:16:44 maybe you can send a merge list to luigi? 14:17:16 OK 14:17:54 Btw did you look at these logs? https://github.com/monero-project/monero/issues/6262 14:18:07 someone else reported this issue too 14:19:00 Probably. I looked into that person's various logs for a while, but never found the big bad one, just smaller bugs. 14:39:58 nice did you fix the diff drift bug 14:40:24 or is it only part of the problem 14:40:32 I think it's fixed. 14:40:49 looks like adding the logs was worth it 15:01:54 If anyone wants to merge 6651 on a mainnet node for a while to make sure nothing bad happens, feel free :) 17:03:45 am looking for a way to make it easy for people to run monero i2p seeds on low cost VPSs without needing to purchase enough storage to store the pruned/unpruned blockchain. Is there a way of running monerod such that it will share new txs via --tx-proxy but not download blocks? 17:04:29 Yes. 17:05:04 There was a reason for this, which I can't recall right now... 17:06:09 Ah yes, to talk to the p2p layer to get a list of public nodes. 17:06:26 Such a node can't relay txes though, since it can't verify them. It'd be just spam. 17:06:32 So I change my yes to no. 17:06:37 yeah that's what i was thinking :( 17:06:47 although 17:07:11 actually that is all the mipseed needs to do, it just needs to advise others of peers 17:07:17 it doesn't need to actually relay txs 17:07:32 i was wondering if it is enough to just set limit_down=0 17:07:43 or limit 0 17:07:45 No, that will totally suck. Don't do this. 17:07:57 See --help for hte "do not sync" option. 17:09:50 ah --no-sync 17:10:34 so now the question is: will other peers ignore a peer and no relay info about it if it is never able to actually get any txs from it? 17:10:46 No. 17:11:01 ok sweet, problem solved. thanks mooo 17:11:58 dsc will need to repurpose his server in about a month, so will need to find other volunteers to run mipseeds 17:12:00 hmmm. don't nodes drop peers that never send them valid blocks? 17:12:04 Maybe we should consider just always dropping connections to nodes that don't seem to sync. 17:12:32 I don't think so. They'll still send a keepalive I think. 17:13:04 ok. I was thinking about peers that lie and say they're always the same height as the node 17:13:06 It might happen if there are new new peers to send with the keepalive, one would have to test. 17:13:27 Yes, it would be nice to find a non false positive way to kick those jerks. 17:13:56 why is limit 0 worse than --no-sync? 17:14:28 i assume since it'd act as quicksand 17:14:30 A node that sends and receives nothing is pointless. 17:14:47 suppose a node opens a 2nd connection to the peer, advertising a different height, and see if the peer still just gives that height back? 17:14:50 but how is limit 0 different than --no-sync in that regard? 17:14:53 It'll just timeout, eating a socket tlil timeout. 17:15:27 Nodes don't send only blocks around. 17:15:41 They send, at the very least, handshakes when they connect. 17:15:46 ah so limit applies to more than just block sync 17:16:06 Hopefully everything... 17:16:12 limit is for everything 17:16:17 all network traffic 17:16:18 aha ok great thanks 17:28:05 knaccc: shouldn’t a 4€ Hetzner VPS be enough to run a pruned node? does a i2p monero seed node need anything special? 17:29:15 how much RAM and disk does 4euro get you? 17:29:34 40GB SSD and 2GB RAM 17:29:38 20TB traffic 17:30:04 40GB doesn't leave you a lot of room for growth 17:30:18 pruned is 26GB currently 17:30:34 You can bump the size later though, right ? 17:30:40 yep 17:32:56 i'm talking about much cheaper options than hetzner, so we get the maximum number of volunteers. like at a $24/year price point 17:33:08 this site has deals like that all the time lowendbox.com 17:37:53 $2/mo gets you 1GB ram, 30GB HDD, 1TB transfer 17:38:20 selsta monero i2p seed just needs i2p-zero and monerod with --no-sync 17:39:15 * moneromooo wonders what network connectivity will do if we get a massive influx of this kind of troll nodes... 18:12:50 i have i2p running on my lowest hetzner vps 18:22:00 kinghat want to be a seed node? :) 18:23:20 sure, as long as it's not a burden to the network. 18:23:36 oh nice, that's great, thanks! what do you mean by burden? 18:24:08 you mean to your own connection? 18:24:27 I had an extra volume attached to the server that was running a full node but I stopped paying for it 🙃 18:24:47 it will only use i2p bandwidth, and you can limit i2p bandwidth in the normal way 18:25:07 nah, just referring to whatever the 🐄 is talking about 18:25:34 my terminal doesn't show whatever emoji or special character you just typed 18:25:48 i am guessing a cow :) 18:25:50 I meant that having loads of those might make it hard for people to have reliable connections. A few will not be bad. 18:26:06 I let the floodgates open on the i2p connection. think it averages like 1.5mb/s 18:26:55 kinghat do you run a monerod on that box too? 18:27:48 not since I let the attached storage volume expire 18:28:09 ah i see. i'll chat in #i2p-zero in order to stop spamming this channel 18:28:19 👌 19:43:41 does anyone know what the retry interval is if an attempt fails to connect to an i2p peer specified with --add-peer (with the --tx-proxy option also set)