00:02:01 I stand corrected 00:09:16 Wait, so the tx hash does not cover the signature? 06:41:19 The tx hash includes the signatures. 06:41:53 The signature scheme was updated from a straight data hash to a two level hash to allow calculating the hash of a pruned tx. 06:42:36 The hash of the pruned data is one of the inputs to the second hashing level. 06:43:05 So if you don't have the pruned data, you can still do it if you have that hash (which is a lot smaller than the pruned data). 06:46:32 Which of these two hashes is used as txid in the block info, and to calculate the merkle root of the block? 06:47:58 The final one :) 06:48:21 And there are not two but 4. First level has 3, second level has 1. 06:55:57 So without the signature data (lost to pruning), I assume that one would not be able to calculate the second-level hash - and therefore, they would not be able to verify that a given transaction matches a specific txid in a pruned block. Correct? 07:10:50 Yes, unless you have the hash of the pruned data. 07:19:06 Oooh I see, so a pruned node just keeps that hash and can thus compute the txid. Neat! 07:52:59 https://www.coindesk.com/tech/2022/11/02/rogue-actor-disrupts-lightning-network-with-a-single-transaction/ 08:46:48 lnd (go) strikes again, c-lightning fine 13:35:05 I need some help. I hosted mainnet monero node behind NAT, forwarded ports (18080, 18089), but have only one incoming connection(I seen many before_handshake connections, but only one normal connection). Why is this happening and how to fix it?? 13:38:17 llacqie[m]: https://github.com/monero-project/monero/issues/8520 13:38:36 you might also have this issue 13:56:16 But I also host stagenet node(which is not behind NAT, but on node which provide NAT(server that acts as router) so they have same IP address) and everything is fine 13:58:31 And I thought it might be some kind of restriction on connections from a single IP 13:59:16 Because all incoming connections to the node come from the same IP (because the node is behind NAT) 14:30:04 llacqie[m]: there's a `--max-connections-per-ip` flag 14:30:12 which defaults to 1 14:41:24 selsta: Thank you, it helped, now there are more than one connections) 15:24:53 But, no, I can have more than one connection only when I add my peer to another node as exclusive peer(( 15:29:01 And the only node that isn't mine isn't syncing, maybe it's a bot, so there's probably another reason why peers don't want to connect to my node. 15:43:29 So now I think this issue describes my case too https://github.com/monero-project/monero/issues/8520 15:51:12 Other nodes are trying to connect, but after the handshake they disconnect(( 15:52:47 16:24 But, no, I can have more than one connection only when I add my peer to another node as exclusive peer(( <-- what do you mean with this? 15:56:13 selsta: When I run monerod on another host with "--add-priority-node :18080 --no-sync" it connects successfully and I have 2 incoming connections 15:56:47 right but that's what doesn't make sense to me 15:58:01 i have seen the same behavior with other nodes on the linked github issue 15:58:12 manually connecting works fine 16:00:43 llacqie[m]: is this your home internet connection? 16:03:24 selsta: No, it's a VPS 16:04:25 To be more precise, these are two VPS, each with ipv4, but one of them nevertheless goes online through the second 16:05:16 try it without NAT and see if you still have the same issue 16:07:04 I just tried to disable redirecting all traffic through the second host. And it turns out quite interesting behavior. I still have an incoming connection from my second host (NAT is working) and no other incoming (although the IP has changed) 16:07:25 *disable forwarding 16:07:40 you'll have to wait a bit 16:10:42 But it really looks like the incoming connection from this bot does not let other peers connect. 16:11:33 but then manually connecting also wouldn't work 16:14:20 Manually connecting works through NAT and directly 16:15:31 Now I have up to 3 incoming connections 16:20:30 One of this nodes is monero(dot)fail node, another one is a bot with peer_id ffdad98ead103705, and third one maybe bot too 16:21:08 third one also have peer_id ffdad98ead103705 16:23:24 If I ban that bot, another bot with similar id connects 16:23:39 ip from 162.218.65.0/24 subnet 16:24:00 Exactly as specified in the issue 16:26:39 If I ban subnet, bot from 209.222.252.0/24 connects 16:27:59 and if you ban that too? 16:28:07 But bots from the subnet 209.222.252.0/24 behave differently 16:28:33 I know these bots exist but so far I'm not convinced they are related to your issue 16:34:09 I banned these subnets, restarted monerod and deleted p2pstate. And I got more than 3 incoming connections for a short time 16:39:10 Ah, this is probably because when I delete the p2p state, the bans are reset 16:40:10 bans reset on monerod restart 16:40:28 unless you specify a --ban-list 17:52:23 Added really big banlist(popular banlist + all subnets of bot's AS), and anyway 0 incoming connections 17:53:13 Also blocked these 3 subnets by firewall 17:58:26 [ 2220.227234] [UFW ALLOW] IN=ens3 OUT= MAC=52:54:00:11:3b:af:02:00:00:00:00:01:08:00 SRC=103.231.91.232 DST= LEN=60 TOS=0x00 PREC=0x00 TTL=48 ID=26728 DF PROTO=TCP SPT=38334 DPT=18080 WINDOW=42780 RES=0x00 SYN URGP=0 17:59:19 There are lots of incoming connections to 18080 port, according to the firewall 18:14:27 fwiw, the sybil nodes in the three listed ip ranges are very aggressive... they show up thousands of times in node network scans, and each ip shows up with like 5 different p2p ports 19:26:21 I am analyzing traffic using wireshark. And so far I have seen the following behavior: our node (node A) connects to node B(port n to 18080), they communicate. And at some point node B decides to connect to node A(port n to our 18080), a handshake occurs, but instead of communicating over this connection node B immediately closes it. 19:47:18 Yes, all connections, except those that are started manually by me, behave like this. 20:17:58 And does anyone host a node here without these problems, what parameters do you use? 21:00:56 llacqie[m]: if you ban all 3 subnets you get zero incoming peers? 21:01:10 apart from manual connections? 21:16:21 "llacqie: if you ban all 3..." <- Yes 21:16:53 even after restart? 21:17:55 in the linked issue someone had the same issue on stagenet / testnet 21:18:29 I banned all subnet's from bots' AS 21:18:32 restarted 21:18:49 *banned by adding to banlist 21:19:04 removed p2pstate 21:19:55 I wrote above how the nodes behave, I think the problem is in this, and not in these bots 21:25:08 llacqie[m]: you said you don't have this issue on your stagenet node, what happens when you run a mainnet node on this exact machine? 21:27:19 selsta: 25 gigabytes of storage 21:28:28 Stupidly there is not enough space to synchronize 21:55:26 llacqie[m]: I'm just trying to see if we can isolate the issue somehow 22:11:37 The nodes don't even try to request anything from my node, they just connect and disconnect, it's really weird. 22:13:38 Why do they connect at all? Are there any checks that run only after connection and make the node disconnect? 22:15:31 Or do they check that the port is open? 22:17:42 If yes, then this is a very weird check, it can also be an open port of any other service running over tcp