00:10:09 For a 128 input tx with a 2s POW it does; however different people are saying very different things, such as applying PoWER to all TXs. > <@boog900> @articmine:monero.social: does this answer why it is not realistic that tx creators will go directly to miners 00:10:09 I am at a loss as to what exactly is this supposed to deter. A single bad tx or a flood. 00:10:09 If it is per connection does this mean over 3 min of POW at 2 sec per connection for 100 connections? 00:14:16 Requiring this for only TXs with more than 8 inputs was a reasonable compromise until people started pushing this for all TXs 00:17:06 tevador: It is not if it is only applied to greater than 8 inputs 00:17:45 By applying PoWER to all txs I meant to relay any tx over p2p you need to do a 1 time PoW per connection. I suggested this after I realised we need to make PoW opt-out for P2P as we can't rely on people to opt in, so most nodes are going to be doing the PoW anyway. 00:17:45 > If it is per connection does this mean over 3 min of POW at 2 sec per connection for 100 connections? 00:17:45 yes although the PoW is only computed for outbound tx-relay connections only. You don't need that many connections for tx relay, and the PoW could be half that. 00:18:19 For wallets/RPC the 8 input without PoW is going to be the same 00:24:55 @boog900: So to be clear if I set up a full relay Monero node, and I am not the first node relaying a greater than 8 input transaction do I have to perform the POW? 00:27:38 @articmine: yeah not for that specific tx tho, for any outbound connections which you want to send txs to 00:29:02 You mean any tx including relay from other nodes 00:29:25 yes 00:30:21 you pay a 1 time PoW per connection for all txs you send, the other node has no way to know if you made the tx or not 00:30:51 Since the POW is not tied to the TX 00:32:05 yeah otherwise it would be PoW per tx 00:34:07 PoW per TX for over 8 inputs is a far better solution 00:34:49 @articmine: what should a node do when the PoW runs our 00:34:51 out* 00:35:06 for per tx it needs a deadline as otherwise you can build up the PoW 00:35:45 if I have a full tx-pool of txs that have PoW that has run out I can't send them to anyone without doing the PoW myself 00:37:15 Why would the PoW run out. Because the TXs did not pay a fee that allows for scaling? 00:38:29 no it needs a very short deadline to prevent building up PoW over a long time 00:38:56 Like how long? 00:39:58 10 blocks 00:40:09 was the original proposal 00:40:21 you can't scale that fast 00:41:11 You need at least 50 blocks 00:41:31 exactly but that is more time to build up PoW 00:41:57 but now another issue what I send out a load of txs with almost ran out PoW 00:42:20 now you have to deal with this, do you drop them or do you do the PoW 00:42:32 or do you keep them in the pool 00:42:46 without being able to send them anywhere 00:44:19 also with PoW per tx you can reuse the PoW across multiple connections 00:44:30 amplifying your attack 00:46:39 The node can choose to drop them or do the PoW. 00:46:39 The creator of the TX could choose the amount of PoW to do 00:47:04 nice those are the 2 options yes 00:47:10 @boog900: Yes this is an issue. 00:47:15 you need to pick one for the node to do though 00:48:09 if you drop them you make it easy to do tx-pool double spends, something a lot of people are against 00:48:09 if you do PoW you open a DoS vector 00:48:38 @articmine: hence we are doing PoW per connection 00:49:45 Which opens another avenue for attack. Nodes in Canada attacking Nodes in Australia in January 00:50:33 Back to the heat issue 00:51:19 we can't keep going back to this 00:51:30 Did the Canadian node drop the connections because of malice or a legitimate network issue 00:52:00 outbound connections only 00:52:01 We cannot ignore heat when considering POW 00:52:22 dropped connections would not cause a DoS 00:52:31 only doing PoW, then sending a bad tx 00:52:39 getting yourself banned 00:52:53 in an ideal world but the ban is not currently the case 00:53:20 It is a different attack. Force Nodes in hot climates is do the POS 00:53:46 @articmine: that would 100% be a DoS, how? 00:53:47 To 00:55:14 outbound connections only, you can't force that without owning a lot of the address space and becoming a sybil, an already known attack. 00:55:42 as long as you have some good connections eventually you'll stop connecting to bad ones 00:56:44 @boog900: eclipse* 00:56:55 Because the nodes in the hot climates have a significantly higher cost for the POW electricity wise while the Nodes in the cold climates have effectively no cost for the electricity 00:57:17 yeah but that is not the how you make them do PoW 00:57:37 They need to reconnect 00:57:38 the node makes its connections you can't force it to do more work 00:58:06 @articmine: exactly you need to node to repeatedly choose to connect to your node 00:58:31 the argument against hot/cold is not relevant here 00:58:48 Over TOR how do they know 00:59:08 it might be cheaper in theory to attack in Canada doesn't make it suddenly feasible 00:59:22 on normal hardware* 01:00:02 But as I said before how can the hot node know if the dropped connection is malicious or not 01:00:15 @articmine: 1. you know the outbound address you connect to. 01:00:15 2. eclipse attacks are a lot easier on Tor 01:00:56 @articmine: it doesn't matter if it doesn't try that node again 01:01:37 but the hot node cannot determine malice 01:01:55 @articmine: why does it need to? 01:05:45 If a node is punished for something outside of the node's operator's control, it is fair to say that is centralization 01:06:31 @articmine: where is there anything about punishment? 01:06:37 @boog900: ^ 01:06:48 It does 01:07:00 explain 01:07:13 The node is effectively being blacklisted 01:07:47 So it is punishment 01:07:48 "doesn't try that node again" just means doesn't immediately try reconnect 01:08:07 I meant as long as another node is chosen immediately after 01:08:11 Define immediately 01:08:20 the next connect attempt 01:08:37 to fulfill the outbound connection count 01:08:48 From the cold node 01:09:11 no PoW is only done on outbound connections 01:09:20 I only do PoW if I made the connection 01:09:31 otherwise I check it on people connecting to me 01:12:27 Doesn't this lead to a passive aggressive attack. Do the POW on 12 nodes. Wait for say 100 more nodes to connect. Then attack 01:13:25 @articmine: yeah but thats not really a DoS, those nodes will check the tx, see its invalid and disconnect 01:14:00 After doing the POW 01:14:35 yeah, so ~2s wasted per connection 01:14:56 per bad outbound 01:15:12 1s PoW + 1s bad tx 01:15:47 More like 200 seconds over 100 nodes 01:16:30 yeah not nearly at the levels you would be able to reach without it 01:16:31 For the price of 24 seconds at -40 01:16:45 C or F 01:16:52 what? 01:16:56 no 01:17:22 2 sec per node 01:17:31 these are outbound connections, you have to wait for nodes to connect to you 01:17:33 100 nodes 01:17:39 you get not advantage being in the cold 01:17:41 1 bad TX 01:18:09 yes then they disconnect and ban your node for sending them a bad tx and connect to someone else 01:18:22 I really thought we were getting somewhere 😭 01:18:36 Yes you do. Cold is always an adventure with POW 01:18:59 THERE IS NO POW FOR INBOUND CONNECTIONS 01:19:10 YOU ONLY VERIFY THE ONES CONNECTING TO YOU 01:19:26 I know 01:19:51 no advantage for running a node listening for connections in Canada like you just sadi 01:20:38 The POW for the first 12 connections is free 01:20:45 Cold 01:21:00 you don't need to do PoW at all for them 01:21:11 as you don't need to do tx relay with them 01:21:23 you just need to get your address into the network 01:21:26 Just for the first 12. Then you listen 01:21:36 @boog900: ^ 01:21:40 no advantage 01:21:55 even so 12 connections worth of PoW ain't heating a house 01:22:25 The is always an advantage with cold. Even if it is 1 connection 01:22:40 ITS ZERO 01:22:51 No 01:23:01 It is not zero 01:23:11 why? 01:23:51 ok lets move on 01:24:05 you have made my node do 2 seconds worth of work, now what? 01:24:14 you are now banned 01:24:17 Because the electricity is effectively free, if one is also heating the space 01:24:51 I make 100 nodes do 2 seconds of work each 01:25:30 Then I have a "power failure" 01:26:39 Should I be banned? 01:26:55 ok my node does not ban you as you did not send a bad tx (which would cause a ban) I just choose to connect to someone else 01:27:35 ... and so do the other 99 nodes 01:28:07 yeah exactly like the current protocol 01:28:40 you are not banned 01:28:59 you are not isolated your outbound connections still work 01:29:11 you will get more inbound 01:34:24 So an honest node in a hot climate can minimize the impact of the POW by only making very few outbound connections while an honest node in a cold climate goes crazy with outbound connections in order to support the network 01:35:06 Both can end up with 100+ connections 01:35:58 @articmine: well define very few, I would say the current default is fine. Also only tx-relay connection you can have more block relay with no PoW 01:36:44 Sure 12 vs 100 01:37:10 but like we already don't need nodes with 100 outbound connections 01:38:47 anyway, you accept (albeit reluctantly) the proposal now? 01:39:33 I have 5GBPS of symmetrical Internet at home here. 01:39:42 Not everyone does 01:40:17 @articmine: don't worry there is a proposal for that too! 01:40:33 tx-realy v2 already in progress 01:40:38 Like? 01:41:05 I will accept the proposal 01:41:24 @articmine: https://github.com/monero-project/monero/issues/9334 01:42:50 Yes that does deserve praise 01:44:14 also 0xFFFC0000 & everyone reviewing their PR: https://github.com/monero-project/monero/pull/9933 01:44:51 It is critical for scaling. 01:45:13 Tx Relay v2 01:47:10 What is the gain. With respect to total data relays vs TX size? 01:47:36 For a given Tx 01:48:32 if you just look at a single tx going over 1 connection to a node which hasn't seen the tx before it is actually a ~100 byte increase 01:48:50 but to a node which has seen the tx it is a constant 32 byte cost no matter the tx 01:49:04 where as currently both cases require you send the full tx 01:55:54 ... and the baseline is the mined transaction 01:56:36 That is the 5Mbs 01:58:31 So we go from an additional 15Mbs to an additional 7Mbs 01:59:31 20Mbps to 12Mbps in total 02:04:22 @articmine: In the tests 0xFF did for that PR yes although I did get a better saving from just looking at the raw tx data in my proposal issue 02:05:26 What I am getting at is:If I send a 10000byte transaction what is the total bandwidth spent by the average node on that transaction including the transaction in a mined block 02:06:55 It comes down to comparing the sanity median to low typical and high residential bandwidth 02:07:50 The average node should only need to send the full tx once so one full send plus 32 times the number of connections 02:08:28 This includes the mined block? 02:09:09 Nah mined blocks is a completely different system and is already covered by fluffy blocks 02:11:22 So with say 100 connections it is 13200 bytes or a factor of 1.32 02:11:39 That is great