08:00:45 <Inge> .usd
10:20:27 <Awaru> how much confirmations needed till xmr arrives?
10:20:28 <Awaru> 10 or 20?
10:21:54 <sech1> 10
10:23:43 <Awaru> thx
10:24:07 <Awaru> waiting and waiting...
10:33:53 <merope> 10 is just the waiting time before you can spend it again 
10:34:03 <merope> The incoming tx should show up almost right away
10:35:42 <Awaru> not at all wallets
10:48:48 <moneromooo> Typically, just one, unless the txpool is > 300 kB. Then it depends on the fee you used.
10:49:43 <moneromooo> If your tx didn't make it to other peers (it can happen if temp network problem on one of the nodes in the dandelion path), then it might take a few minutes for a timeout.
15:04:59 <gingeropolous> anyone have a good link for the malicious node fee bug thing?
15:26:36 <selsta> gingeropolous: not sure if there is a writeup
15:26:46 <selsta> ideally we would need an IP
15:27:49 <selsta> but in the end we will have to replace the node scanner with a list of "trusted" nodes, there are probably a lot of more things malicious nodes can do
15:36:09 <gingeropolous> ugh. when the solution is centralization is it really a solution. blargh
15:36:32 <louipc> no. its a stop-gap
15:39:36 <tobtoht> gingeropolous: not really a write up, but see get_fee_estimate here: https://docs.featherwallet.org/guides/nodes
15:41:33 <gingeropolous> i still think a better stop gap is to connect to multiple remote nodes simultaneously. but until i can code it its as good an idea as a ...... <funny_analogy>
15:42:07 <gingeropolous> how is it a fungibility defect? i guess it tags a tx... yeah
15:50:09 <gingeropolous> multiple nodes thing would be like a "trust the crowd" thing
15:52:51 <tobtoht> how would you prevent sybil attacks?
16:27:16 <moneromooo> The better stopgap is what it always has been. Don't insert your wallet into some random unknown's open port.
16:28:38 <moneromooo> It's a stopgap, a solution, and the right way to do things.
16:28:59 <moneromooo> Start equating this with safe sex and people will start getting the idea.
16:29:11 <moneromooo> (maybe)
17:12:20 <gingeropolous> tobtoht, the same way the monero network client (monerod) currently prevents sybil attacks. 
17:15:24 <selsta> doesn't work
17:18:14 <selsta> monerod requires one honest peer to stay up to date with the network
17:18:37 <selsta> rpc would require some majority because you don't know which node is honest
17:18:54 <selsta> that overcomplicates things a lot when people could just run their own node
17:19:02 <gingeropolous> yeah
17:19:02 <selsta> or use a node of someone they trust
17:22:15 <gingeropolous> i feel like "just" run your own node is closer to being simple than its ever been. 
17:22:35 <gingeropolous> but for some its apparently a step too far
17:23:31 <gingeropolous> and then there's the port forwarding. though, viewtags will lessen the burden on these services, so wallet providers may be able to provide the infra
19:19:43 <tidux> What ports do I need to unblock in my firewall, if any, to run a node?
19:20:02 <tidux> I've got an initial sync going so I've got time to tweak before it's done.
19:21:31 <moneromooo> 18080 (not strictly needed, but prefered)
19:25:22 <tidux> cool, opening now
22:24:11 <apotheon> tidux: I think 18080 is the one you open to allow others to use your node.
22:27:17 <moneromooo> That's the RPC port at 18081. It should remain closed unless you know what you're doing.
22:29:27 <tidux> moneromooo: oh good, I did leave that closed
22:29:57 <tidux> on the plus side: the full-system power draw for this node-hosting machine is ~30W under load and it isn't a laptop
22:30:03 <tidux> on the minus side: mechanical HDD
22:45:33 <apotheon> ooh, spinning disks