07:03:26 still showing target height 2228507, even though current height across many peers is 2228824 11:01:06 Hi guys!I've been using the xmr rpc node for a while, but just now i faced a minor issue, but it's really important to solve. I don't understand how I can get info which node version I am currently using. I found rpc get_version method, but with this method I get the rpc wallet version, but I need to get the node version. With rpc get_version 11:01:06 method I get the installed version of rpc, but I want the version of the node itself that I installed, i.e. as on github monero-project/monero/releases/tag/v0.17.1.1or as in the monero site in Downloads part (Current Version: v0.17.1.4 - Oxygen Orion)For example, I am using node v0.17.1.1 and rpc wallet version v3.1. And I need to get the node 11:01:07 version i.e. v0.17.1.1 .Is it possible?a piece of advice from you would be really appreciated! 13:00:02 Why is it important to solve it ? 13:00:28 hyc: are you in sync mode ? 13:16:08 -xmr-pr- jaredweinfurtner opened issue #7015: [release-v0.17] Docker build failing 13:16:08 -xmr-pr- > https://github.com/monero-project/monero/issues/7015 14:07:05 moneromooo: node is all caught up 14:10:50 Then you are not in sync mode. 14:14:18 in which case, what? target height doesn't mean anything? 14:14:59 Right. 14:15:07 this log message is about being unable to relay txns. if the target height only means something in sync mode, then it's irrelevant here 14:15:16 because a syncing node isn't supposed to be relaying txns anyway 14:17:26 https://github.com/monero-project/monero/blob/master/src/cryptonote_protocol/levin_notify.cpp#L649 14:18:54 which means this commit 6352090e6d7f3c639ab9eec23a62304e785cb91b is wrong 14:20:58 xiphon: maybe you should have used the actual local blockchain height, instead of target height in that patch 14:29:38 hyc: example: your node connected to 2 peers. Your height is 1, peer A height is 2 and peer B height is 3 14:29:47 target height should be 3 14:29:50 local height is 1 14:30:41 if you use local height, you will send a tx to peer A as well though it is not synced 14:33:04 would actually tweak it and use std::max(local_height. target_height) 14:34:49 xiphon: as mooo just said, target height is meaningless when your node is syncing. and when your node is syncing, it is not relaying txns. 14:35:00 Does this allow some asshole to claim height 1e9 and prevent all txes being sent to *others* ? 14:35:21 yeah that seems likely too. 14:35:28 this patch is just wrong. 14:35:40 nope, it is not 14:35:52 "Does this allow some asshole to claim height 1e9 and prevent all txes being sent to *others* ?" 14:35:59 you should drop the connection 14:36:04 if it doesnt provide the blocks 14:36:24 It takes a few minutes IIRC. 14:36:32 To be nice to honest slow peers. 14:38:11 Or maybe do this ignoring only if the node claiming H > local has sent at least one valid block along the way, 14:39:30 xiphon: you're testing target height when target height is meaningless. so regardless of anything else, the patch is wrong. 14:39:53 it shouldn't be meaningless 14:40:01 the peers provide target height 14:40:08 if it doesn't work, then it is a bug 14:40:15 the patch is correct 14:40:39 just fix the target height 14:41:01 instead you want to revert the correct patch 14:41:07 and leave the target height but there 14:41:17 no, I want to fix the patch. target height is the wrong value 14:41:49 why do you think so? 14:41:57 WTF man pay attention 14:42:07 As long as it's not vulnerable to DoSing relay to other peers, I'd be happy with the result. 14:42:29 i'm pretty confident in what i'm saying 14:42:34 2020-11-12 14:40:49.861 W No suitable outbound tor connections at height 2228897 - currently unable to send transaction(s) to this zone 14:42:34 status 14:42:34 Height: 2229060/2229060 (100.0%) on mainnet, not mining, net hash 1.72 GH/s, v14, 12(out)+21(in) connections, uptime 1d 0h 9m 48s 14:42:46 the value has no relation to reality 14:42:46 i see no problem target height being the max of the peers' heights 14:43:13 my node has been logging this message with target height for hours 14:43:20 ^ " would actually tweak it and use std::max(local_height. target_height)" 14:43:23 in all cases, the target height is far out of date wrt to actual chain 14:43:48 and even if we tweak as you suggest, using max still means a lying node can shutdown all txn relaying. 14:44:02 nope 14:44:12 your should drop the lying node 14:44:23 if it claims the 1e9 height 14:44:23 ... we're talking in circles 14:44:28 but doesn't provide the blocks 14:44:31 Just fix it I think. 14:45:49 Just fix which part? 14:46:18 The dependency on the target value when there is no target. 14:46:42 so it should just use local height 14:47:00 yep, and eventually send txes to desynced peers 14:47:03 The DoS prevention can then come later, if there is such a DoS vector, xiphon says not but it'd be nice to make sure. 14:47:08 and then break the dandelion 14:47:33 xiphon: you're still not paying attention. this section of code only runs when the node is sync'd. 14:48:37 unless you're saying that with dandelion, nodes will relay txs even when they're not syncd? 14:48:38 hm, nope 14:48:48 i can send txes being at height 1 14:49:01 vtnerd: btw, I added a scoring system for peers recently. Do you think selecting dandelion targets based on score would be a good idea ? 14:49:09 ie, give much lower probability to low score peers. 14:49:18 mean "this section of code only runs when the node is sync'd" -> i can send txes being at height 1 14:49:20 Or would that remove too much entropy from picks... 14:50:11 in that case, the value should be local height when node is sync'd, target height when not sync'd. 14:51:41 but usually a node will not accept txs while syncing. the rpc will return BUSY 14:51:49 so I dunno what you're doing. 14:53:38 ^ ./monerod --no-sync 14:54:11 the RPC will allow sending txes to P2P even if you ain't synced 14:55:00 gawd, why do we have an option like that. means it can't validate the txn before relaying. 14:56:17 when a user don't want to sync all the blockchain just to send a tx 14:56:37 It's the third party node sickness that's propagating. IIRC it's used for the "find me a public node via P2P but don't sync" mode. 14:57:13 actually txes validation is other peers' business 14:57:17 It's kinda both good and bad at once :/ 14:59:21 sounds like that patch was written with only a non-syncing node in mind 14:59:33 (the current target height patch that is) 14:59:58 it is still wrong for the default case of a normal node. 15:02:33 "in that case, the value should be local height when node is sync'd, target height when not sync'd" 15:02:41 that's std::max(local_height. target_height) 15:03:07 either i wounder how would one know it is synced or not without comparing local height and target height 15:03:34 s/wounder/wonder/ 15:03:49 stop wondering and read the damn code 15:03:57 is_synchronized() is already there 15:05:28 it is damn "if (m_core.get_current_blockchain_height() >= m_core.get_target_blockchain_height())" 15:11:27 if (context.m_remote_blockchain_height >= m_core.get_target_blockchain_height()) 15:11:27 { 15:11:27 if (m_core.get_current_blockchain_height() >= m_core.get_target_blockchain_height()) 15:11:27 { 15:11:27 MGINFO_GREEN("SYNCHRONIZED OK"); 15:11:28 on_connection_synchronized(); 15:11:56 so again, target is not meaningful on its own 15:12:13 checking local height and remote height 15:17:57 target height is max(all peers' m_remote_blockchain_height) 15:18:47 and m_remote_blockchain_heigh is just the current peer's height 15:25:20 no, target_height is not *only* that. it gets reset when a connection closes 15:25:54 in void t_cryptonote_protocol_handler::on_connection_close(cryptonote_connection_context &context) 15:26:34 in particular, it can get set down to zero if there are no connections in the current zone 15:27:26 which is arguably the wrong thing to do if there are still other zones with live connections 15:28:25 sending is different than relaying 15:29:54 I guess max(local height, target height) will be enough. 15:29:56 ... right? in this discussion " the RPC will allow sending txes to P2P even if you ain't synced" . dunno if its important to distinguish tx initiation and relay 15:30:16 anyway, the current code in repo is wrong. 15:30:39 "anyway, the current code in repo is wrong." -> will send a PR soon 15:31:45 " sending is different than relaying" -> i would say that tx validation on sending is kinda optional (you are actually double-checking the tx you have just generated) 15:32:21 but when you relay someone's else tx, you must validate it to prevent spamming 15:32:45 Do public RPC nodes verify in the RPC ? If not, they can be uesd to relay spam. 15:33:29 Though a solution is enabling pay-for-rpc. 15:33:30 "Do public RPC nodes verify in the RPC" -> they do 15:34:12 still something suspicious about this. if target height is max(all peers remote height) 15:34:28 then that if statement makes no sense: 15:35:06 if (context.m_remote_blockchain_height > m_core.get_target_blockchain_height()) 15:36:47 https://github.com/monero-project/monero/blob/master/src/cryptonote_protocol/cryptonote_protocol_handler.inl#L2307 15:50:00 also - since you've already established that a non-sync'd node can send txs, but this code prevents relaying txs thru a non-sync'd node, 15:50:25 then you know for certain that if you receive a tx from a non-sync'd node, it was the originator 16:02:59 kinda defeats the purpose of running a node, doesn't it? 16:11:23 "if you receive a tx from a non-sync'd node, it was the originator" -> yep, though since the sending node doesn't fluff a tx, only one peer will know that. Anyway that's not good. It is primarily used in GUI Simple Mode and it warns a user on privacy implications of using Simple Mode (i.e. --no-sync + auto remote node) 16:14:05 "a non-sync'd node can send txs" -> was added cause sending txes through auto remote nodes wasn't that reliable 16:15:10 and there were a lot of users' reports on missing/failed/non-confirmed txes 16:15:18 this might be a dumb Q but if the node isn't synced how does it even know an output is spendable? or are we just counting on synced nodes to sort that out 16:15:43 the latter 16:16:39 seems like missing/failed txs was probably all due to the asshole nodes 16:17:05 I don't see how sending tx from a non-sync node is any more reliable than sending directly to a remote node 16:17:18 We do both now 16:17:28 thus.. more reliable 16:17:46 so we send the same tx to remote node and to P2P 16:21:07 "it was the originator" -> i actually don't like that. But the only way to fix it is to revert it back and don't send txes from a non-synced node 16:30:27 is there any reason why a non-synced node can't query the current blockheight from node A, then broadcast transaction to node B 16:30:39 in which case the non-synced node would appear synced to node B 16:31:59 GUI Simple Mode warning -> https://i.postimg.cc/CK9Ssmvy/simple-mode.png 16:32:26 jwinterm: a node reports its height to each of its peers 16:32:48 so the only way would be to "mirror" the peer's height 16:33:05 what is a hack and is a no-go at a glance 16:33:25 that's basically what the asshole nodes were doing 16:33:39 ic 17:00:55 moneromooo : I wouldn't recommend a weighted dandelion stem selection algo right now 17:01:50 a normal node will temporarily drop in score when "testing" you, but spy node could almost remain highest 17:02:32 Good point. 17:02:32 so I dunno, which is frustrating because its an alternative way to wreck small bit of havok 17:04:14 throw out highest score? 17:27:41 I am currently syncing a new node from scratch and I would have that bad node block height mirroring issue on a daily basis causing my sync to stop, so I would have to reboot monerod every day to get the sync going again. After upgrading to the latest version of monero and adding the --ban-list flag I have had ZERO issues of my sync freezing. So thanks a bunch for finding this issue and mitigating it! I am on 17:27:41 track to be at the tip soon! 🙌 18:46:08 -xmr-pr- mj-xmr opened pull request #7016: Split epee/string_tools.h and extracted boost_lexical_cast 18:46:08 -xmr-pr- > https://github.com/monero-project/monero/pull/7016 22:31:08 -xmr-pr- xiphon opened pull request #7018: cryptonote_core: dandelion++ stem - use max known blockchain height 22:31:08 -xmr-pr- > https://github.com/monero-project/monero/pull/7018 22:31:09 -xmr-pr- vtnerd opened pull request #7017: Do not use peer_id tracking method over i2p/tor 22:31:09 -xmr-pr- > https://github.com/monero-project/monero/pull/7017