00:02:01 <merope> I stand corrected
00:09:16 <merope> Wait, so the tx hash does not cover the signature?
06:41:19 <moneromoooo> The tx hash includes the signatures.
06:41:53 <moneromoooo> 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 <moneromoooo> The hash of the pruned data is one of the inputs to the second hashing level.
06:43:05 <moneromoooo> 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 <merope> 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 <moneromoooo> The final one :)
06:48:21 <moneromoooo> And there are not two but 4. First level has 3, second level has 1.
06:55:57 <merope> 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 <moneromoooo> Yes, unless you have the hash of the pruned data.
07:19:06 <merope> Oooh I see, so a pruned node just keeps that hash and can thus compute the txid. Neat!
07:52:59 <rbrunner> https://www.coindesk.com/tech/2022/11/02/rogue-actor-disrupts-lightning-network-with-a-single-transaction/
08:46:48 <DataHoarder> lnd (go) strikes again, c-lightning fine
13:35:05 <llacqie[m]> 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 <selsta> llacqie[m]: https://github.com/monero-project/monero/issues/8520
13:38:36 <selsta> you might also have this issue
13:56:16 <llacqie[m]> 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 <llacqie[m]> And I thought it might be some kind of restriction on connections from a single IP
13:59:16 <llacqie[m]> Because all incoming connections to the node come from the same IP (because the node is behind NAT)
14:30:04 <selsta> llacqie[m]: there's a `--max-connections-per-ip` flag
14:30:12 <selsta> which defaults to 1
14:41:24 <llacqie[m]> selsta: Thank you, it helped, now there are more than one connections)
15:24:53 <llacqie[m]> But, no, I can have more than one connection only when I add my peer to another node as exclusive peer((
15:29:01 <llacqie[m]> 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 <llacqie[m]> So now I think this issue describes my case too https://github.com/monero-project/monero/issues/8520
15:51:12 <llacqie[m]> Other nodes are trying to connect, but after the handshake they disconnect((
15:52:47 <selsta> 16:24 <llacqie[m]> 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 <llacqie[m]> selsta: When I run monerod on another host with "--add-priority-node <ip_of_my_node>:18080 --no-sync" it connects successfully and I have 2 incoming connections
15:56:47 <selsta> right but that's what doesn't make sense to me
15:58:01 <selsta> i have seen the same behavior with other nodes on the linked github issue
15:58:12 <selsta> manually connecting works fine
16:00:43 <selsta> llacqie[m]: is this your home internet connection?
16:03:24 <llacqie[m]> selsta: No, it's a VPS
16:04:25 <llacqie[m]> To be more precise, these are two VPS, each with ipv4, but one of them nevertheless goes online through the second
16:05:16 <selsta> try it without NAT and see if you still have the same issue
16:07:04 <llacqie[m]> 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 <llacqie[m]> *disable forwarding
16:07:40 <selsta> you'll have to wait a bit
16:10:42 <llacqie[m]> But it really looks like the incoming connection from this bot does not let other peers connect.
16:11:33 <selsta> but then manually connecting also wouldn't work
16:14:20 <llacqie[m]> Manually connecting works through NAT and directly
16:15:31 <llacqie[m]> Now I have up to 3 incoming connections
16:20:30 <llacqie[m]> 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 <llacqie[m]> third one also have peer_id ffdad98ead103705
16:23:24 <llacqie[m]> If I ban that bot, another bot with similar id connects
16:23:39 <llacqie[m]> ip from 162.218.65.0/24 subnet
16:24:00 <llacqie[m]> Exactly as specified in the issue
16:26:39 <llacqie[m]> If I ban subnet, bot from 209.222.252.0/24 connects
16:27:59 <selsta> and if you ban that too?
16:28:07 <llacqie[m]> But bots from the subnet 209.222.252.0/24 behave differently
16:28:33 <selsta> I know these bots exist but so far I'm not convinced they are related to your issue
16:34:09 <llacqie[m]> I banned these subnets, restarted monerod and deleted p2pstate. And I got more than 3 incoming connections for a short time
16:39:10 <llacqie[m]> Ah, this is probably because when I delete the p2p state, the bans are reset
16:40:10 <selsta> bans reset on monerod restart
16:40:28 <selsta> unless you specify a --ban-list
17:52:23 <llacqie[m]> Added really big banlist(popular banlist + all subnets of bot's AS), and anyway 0 incoming connections
17:53:13 <llacqie[m]> Also blocked these 3 subnets by firewall
17:58:26 <llacqie[m]> [ 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=<my_ip> 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 <llacqie[m]> There are lots of incoming connections to 18080 port, according to the firewall
18:14:27 <merope> 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 <llacqie[m]> 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 <llacqie[m]> Yes, all connections, except those that are started manually by me, behave like this.
20:17:58 <llacqie[m]> And does anyone host a node here without these problems, what parameters do you use?
21:00:56 <selsta> llacqie[m]: if you ban all 3 subnets you get zero incoming peers?
21:01:10 <selsta> apart from manual connections?
21:16:21 <llacqie[m]> <selsta> "llacqie: if you ban all 3..." <- Yes
21:16:53 <selsta> even after restart?
21:17:55 <selsta> in the linked issue someone had the same issue on stagenet / testnet
21:18:29 <llacqie[m]> I banned all subnet's from bots' AS
21:18:32 <llacqie[m]> restarted
21:18:49 <llacqie[m]> *banned by adding to banlist
21:19:04 <llacqie[m]> removed p2pstate
21:19:55 <llacqie[m]> I wrote above how the nodes behave, I think the problem is in this, and not in these bots
21:25:08 <selsta> 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 <llacqie[m]> selsta: 25 gigabytes of storage
21:28:28 <llacqie[m]> Stupidly there is not enough space to synchronize
21:55:26 <selsta> llacqie[m]: I'm just trying to see if we can isolate the issue somehow
22:11:37 <llacqie[m]> The nodes don't even try to request anything from my node, they just connect and disconnect, it's really weird.
22:13:38 <llacqie[m]> Why do they connect at all? Are there any checks that run only after connection and make the node disconnect?
22:15:31 <llacqie[m]> Or do they check that the port is open?
22:17:42 <llacqie[m]> If yes, then this is a very weird check, it can also be an open port of any other service running over tcp