05:02:41 <m-relay> <h​bs:matrix.org> Can TF be merged mined with Monero using p2pool?
05:51:04 <moneromooo> No. It is possible in theory, but p2pool uses some field in a way that's incompatible.
05:51:37 <moneromooo> It'd need a fork to fix this. And I don't have the drive to fix this anymore.
13:21:07 <MaddieKalan> Whats the minimum amount of bandwidth I should have available to keep the monero blockchain up to date in real time?
13:22:43 <m-relay> <o​frnxmr:monero.social> Data allotment or up/down speeds?
13:24:07 <m-relay> <o​frnxmr:monero.social> Can get away with about 4gb/day or well under 30kbps, but not good for mining.
13:25:11 <m-relay> <o​frnxmr:monero.social> 300kb/s should download a block in ~1 second
13:28:43 <sech1> Monero has 20-25k transactions per day. Average transaction size is 2-2.5 kb, so you can stay in sync for as little as 50-60 Mb traffic
13:29:45 <sech1> But in reality Monero node uses 50-100 KB/s bandwidth
13:30:16 <sech1> Or maybe it's just my node that has a lot of connections
13:31:18 <moneromooo> My seed node averages about 275 kB/s over the last 4 months (cumulative up and down). So that's a comfortably high bound.
13:33:46 <MaddieKalan> ofrnxmr whats good for mineing then?
13:34:35 <m-relay> <o​frnxmr:monero.social> Priority connections to mining pool or largenodes
13:37:31 <sech1> I'd say 10 Mbit connection if you're running a node (mining solo or on p2pool). And yes, connections to other mining pool nodes
13:38:07 <MaddieKalan> supportxmr and hashcault good?
13:38:13 <MaddieKalan> vault*
13:52:31 <sech1> Yes
16:50:07 <m-relay> <k​ilopool:matrix.org> I disagree, both supportxmr and hashvault have more than 20% of network hashrate.
16:51:11 <m-relay> <k​ilopool:matrix.org> If one of them colludes with the biggest pool (nanopool.org), they could 51% attack Monero.
16:52:50 <m-relay> <k​ilopool:matrix.org> You should mine either in P2Pool (best option), or in smaller pools (good smaller pools are kilopool.com, herominers.com, gntl.uk, monerod.org, minexmr2.com, aterx.com...)
16:55:27 <sech1> He meant connecting to pool nodes, not mining on those pools
16:55:43 <sech1> You connect to other pool's nodes to get blocks from those pools faster
16:56:12 <m-relay> <k​arano:poddery.com> In monero , even if a pool had more  than 51% hashrate , their is only a limited things a pool can do , instead of a whole "attack"
16:57:07 <m-relay> <k​arano:poddery.com> They can't write any transactions to the block by themselves
16:57:46 <m-relay> <k​ilopool:matrix.org> Yes, in Monero a pool with more than 51% of the hashrate can "just" do a reorg and reverse transactions, so they can spend their money again after having sent it.
16:59:36 <m-relay> <k​ilopool:matrix.org> Which is exactly what happens in Bitcoin too.
17:11:17 <m-relay> <k​arano:poddery.com> No , i don't think they can double spend
17:14:41 <sech1> They can
17:26:40 <m-relay> <k​arano:poddery.com> They can but , if they do they will create distrust in the network , which will indirectly affect themselves
17:27:57 <m-relay> <k​arano:poddery.com> They can but , if they do they will create distrust in the network , which will indirectly affect themselves and their investment in mining xmr
17:28:31 <sech1> We can always consider hostile pool takeover for this scenario (i.e. government, or hackers)
17:29:02 <sech1> so entities who don't care about network trust
20:12:04 <moneromooo> They can only "double spend" in the sense that they can nuke an earlier spend and spend those inputs again, since they are no longer spent on the chain they mine. They still can't spend an output more than once on whatever chain they mine.
20:13:35 <moneromooo> So one can protect against this by requiring N blocks before acting on a payment (with the assumption that the attacker will not have >50% for too long, or that a 40% attacker will not be so lucky with more blocks).
23:27:26 <m-relay> <p​olar9669:matrix.org> They don’t need to invest, they can rent it