<a​rticmine:monero.social> In my view yes.vI is best to cut out botnets.

<a​rticmine:monero.social> I do agree that a benign botnet can help secure the network. So can PoUW. The reality is also that both can be used to attack Monero, or at least to be a nuisance.

<a​rticmine:monero.social> Let us not forget that the use of botnets against Monero has already been threatened.

<a​rticmine:monero.social> Cutting out botnets is also very positive for Monero since botnets are seen as criminal.

<l​eonarth_:matrix.org> Qubic is basically a botnet

<l​eonarth_:matrix.org> a central operator can redirect the compute of all its miners (bots) towards any task they please

<e​longated:matrix.org> Let’s not forget we kicked out legit miners when we moved to randomx, if we remove botnets xmr is again open to attacks; we need a gradual move to non botnet pow.

<a​rticmine:monero.social> XMR is being attacked now by a botnet as part of the Qubic attack.

<a​rticmine:monero.social> With regard to the Bitmain affair 7 years ago I, today, remain far from convinced that what Bitmain did was legal.

<l​eonarth_:matrix.org> I have an idea to deal with centralized pools, though it's not fully formed and I don't yet know how dumb this may sound

<l​eonarth_:matrix.org> ```Incentive for Distributed Mining

<l​eonarth_:matrix.org> p2pool achieves decentralization by eliminating a central mining operator using a p2p "share-chain" to track contributions and distributing Coinbase rewards.

<l​eonarth_:matrix.org> We could modify the protocol to optionally include the Merkle root of recent p2pool shares as state in each block. Nodes would validate this state against a synced p2pool share-chain. Blocks with a valid share-chain proof would receive extra reward, thus giving incentive for miners to use decentralized mining.

<l​eonarth_:matrix.org> Current block reward: 0.6

<l​eonarth_:matrix.org> Block reward when including p2pool share-chain proof: 0.9

<l​eonarth_:matrix.org> Extra incentive: if conflicting mined blocks, the block with a share-chain proof wins while the other is orphaned.

<l​eonarth_:matrix.org> Cons to think about:

<l​eonarth_:matrix.org> - Nodes now require running running p2pool alongside to validate the share-chain

<l​eonarth_:matrix.org> - How to prevent miners from forging share-chain proofs?

<l​eonarth_:matrix.org> - How to ensure miners don't collude in forming centralized p2pool setups?

<l​eonarth_:matrix.org> I have an idea to deal with centralized pools, though it's not fully formed and I don't yet know how dumb this may sound

<l​eonarth_:matrix.org> ```

<l​eonarth_:matrix.org> Incentive for Distributed Mining

<l​eonarth_:matrix.org> p2pool achieves decentralization by eliminating a central mining operator using a p2p "share-chain" to track contributions and distributing Coinbase rewards.

<l​eonarth_:matrix.org> We could modify the protocol to optionally include the Merkle root of recent p2pool shares as state in each block. Nodes would validate this state against a synced p2pool share-chain. Blocks with a valid share-chain proof would receive extra reward, thus giving incentive for miners to use decentralized mining.

<l​eonarth_:matrix.org> Current block reward: 0.6

<l​eonarth_:matrix.org> Block reward when including p2pool share-chain proof: 0.9

<l​eonarth_:matrix.org> Extra incentive: if conflicting mined blocks, the block with a share-chain proof wins while the other is orphaned.

<l​eonarth_:matrix.org> Cons to think about:

<l​eonarth_:matrix.org> - Nodes now require running running p2pool alongside to validate the share-chain

<l​eonarth_:matrix.org> - How to prevent miners from forging share-chain proofs?

<l​eonarth_:matrix.org> I have an idea to deal with centralized pools, though it's not fully formed and I don't yet know how dumb this may sound

<l​eonarth_:matrix.org> ```

<l​eonarth_:matrix.org> Incentive for Distributed Mining

<l​eonarth_:matrix.org> p2pool achieves decentralization by eliminating a central mining operator using a p2p "share-chain" to track contributions and distributing Coinbase rewards.

<l​eonarth_:matrix.org> We could modify the protocol to optionally include the Merkle root of recent p2pool shares as state in each block. Nodes would validate this state against a synced p2pool share-chain. Blocks with a valid share-chain proof would receive extra reward, thus giving incentive for miners to use decentralized mining.

<l​eonarth_:matrix.org> Current block reward: 0.6

<l​eonarth_:matrix.org> Block reward when including p2pool share-chain proof: 0.9

<l​eonarth_:matrix.org> Extra incentive: if conflicting mined blocks, the block with a share-chain proof wins while the other is orphaned.

<l​eonarth_:matrix.org> Cons to think about:

<l​eonarth_:matrix.org> - Nodes now require running p2pool alongside to validate the share-chain

<l​eonarth_:matrix.org> - How to prevent miners from forging share-chain proofs?

<a​rticmine:monero.social> There is a big Con: Changing the economic parameters of Monero. I have to say no to touching the block reward.

<j​ack_ma_blabla:matrix.org> Bitmain didnt use botnets to mine, they created asic miners legally. If others were not intersted in making asic miners for xmr, its no their problem.

<j​ack_ma_blabla:matrix.org> Nor did bitmain attack monero like these botnets are being used with qubic

<a​rticmine:monero.social> They engaged in deceptive marketing of such miners when they got wind that the Monero developers were going to hard fork. Deceptive marketing is illegal in many jurisdictions.

<j​ack_ma_blabla:matrix.org> They sold their miners while they could, they didn't market it any guarantee that it will keep mining xmr forever.

<j​ack_ma_blabla:matrix.org> They sold their miners while they could, they didn't market it with any guarantee that it will keep mining xmr forever.

<a​rticmine:monero.social> Did they disclose what they knew when they marketed?

<a​rticmine:monero.social> If you sell a product with the full knowledge that it will become useless in a few months, and do not disclose to the buyer what you know that is deception.

<e​longated:matrix.org> Did monero team contact them and tell them product will be obsolete and they should change product description?

<e​longated:matrix.org> Afaik bitmain was not incharge of hardfork

<a​rticmine:monero.social> The Monero team suspected that something was amiss and that . Bitmain was mining in secret with ASICS.

<a​rticmine:monero.social> At this point the proposed hard fork changes became available on GitHub. Monero is FLOSS. Only at this point did the used ASICS become available in the market.

<a​rticmine:monero.social> The above was very different from what happened in Bitcoin in 2012 / 2013.

<a​rticmine:monero.social> I was there for both the introduction of ASICS in Bitcoin and in Monero .I can say that unlike what happened with Bitcoin, Bitmain did not act with clean hands in the Monero case.

<j​ack_ma_blabla:matrix.org> Once those asics were available to public, was there any reason to then fork it ? just bcoz some cpu miners were less profitable than bitmain miners. Other asic manufactures could have made xmr miners if there was no fork, but xmr was hell bent on using cpu only.

<j​ack_ma_blabla:matrix.org> Anyways, can we do triple-pow ? randomx/merge-mine-with-ltc/sha3 ? 33-33-33 ?

Bitmain X3 shipped in May 2018, Monero v7 fork happened in April 2018. The only one who mined Monero with them was Bitmain.

<a​rticmine:monero.social> In my view we should go for the low hanging fruit first.Maximise the pain to the attacker, while minimizing the disruption to the Monero network

<a​rticmine:monero.social> 1) A 1% version of the block signing proposal

<a​rticmine:monero.social> 2) Strong copyleft in key mining code. XMRig is a good start

<a​rticmine:monero.social> 3) Instead of changing the block reward, nodes for example could take some extra time relaying suspected selfish mined blocks, thereby increasing the probability such blocks be orphaned.

<a​rticmine:monero.social> ...

<a​rticmine:monero.social> If an idea is proposed take a hard look at implementing the concept without drastic protocol changes.

<a​rticmine:monero.social> We don't need "perfect" solutions. Instead layer imperfect solutions that involve minimal or no consensus changes.

Ideally, we want centralized pools to be replaced by p2pool instances, so #98 seems to be a better solution than block signing, which would affect all pools alike.

<a​ntilt:we2.ee> are the practical issues with hardware requirements solved?

I'm trying to dig up my PoC code and run some new benchmarks.

tevador: since a certain mining pool is offering a perceived 100% 'bonus' on monero mining, couldn't #98 cause hashrate to fall for other centralized mining pools but actually increase for the pool offering a 'bonus'. Even if that wasnt the case, there ie then a possibility of reduced overall HR leaving monero more open to 51%? Obviously their premium isn't sustainable and is

based on speculation (and value of the token), but it's got them this far, and people can be irrational and not all in good faith..

<g​ingeropolous:monero.social> yeah i had similar thoughts. If #98 is implemented, and pools need to increase their fees to 6% or more, are we just going to end up with the same situation we have now, where some pool operator can just subsidize these fees, and offer 0-1%, leading to miners flocking to the larger, lower fee pool, and subsequently forcing out the little pools? which sux because i really like #98

<g​ingeropolous:monero.social> though i wonder if #98 was coupled with stratumv2 (or whatever its called... i think jtgrassie had worked on a version for monero poools) ... if that would offset the pool overhead.

I think PoW consensus is always vulnerable to irrational actors who pay above market rate for hashrate.

The point of #98 is to get rid of all centralized pools and move miners to p2pool (or solo mining). It doesn't directly address irrational pools.

<a​rticmine:monero.social> I see MRL issue 98 as encouraging miners to run their own full node. This is a very valid reason for me to strongly support it. I doubt it , by itself, will have much impact on the Qubic situation. It will however have an impact on the Qubic situation when combined with other measures.

<a​rticmine:monero.social> As for MRL issue 98 getting rid of centralized pools. I doubt it

would it not be wise to wait until the current situation is delt with until persuing #98, due to potential reduction in total hashrate and miner migrations?

<a​rticmine:monero.social> I would not implement it alone for the above reason, but combined with at least the block signing proposal it will help.

<a​rticmine:monero.social> This is a case where the whole is greater than the sum of its parts.

<a​rticmine:monero.social> Node relay used against selfish mining is also something I would look at.

<a​rticmine:monero.social> Nodes would delay relaying selfish mined blocks

<a​rticmine:monero.social> Especially empty blocks

<g​ingeropolous:monero.social> imo its too easy to circumvent to warrant the (potential) complexity. adversary just stuffs a block with some of their own txs, other nodes wouldn't know the difference. same goal achieved (real txs still stuck in txpool)... although, maybe get fancy with some "is this block including n% of the txs i currently have in my txpool" logic.

<a​rticmine:monero.social> The node could run a reasonableness teat on the tx pool and the mined block. If the mined block does not meet the test delay at least

<a​rticmine:monero.social> It is not easy to circumvent because the tx IDs and time are visible to the node

<a​rticmine:monero.social> So yes a bit of fancy is needed

<o​frnxmr:monero.social> If incoming blocks are N% smaller than what your node's templates would produce, reject the block ?

<a​rticmine:monero.social> That is part of it, a reasonableness test on the tx pool is needed also. Rejecting is an option, or just a delay.

<o​frnxmr:monero.social> This goes along with what i had said about allowing miners to produce small blocks via a runtime flag

<o​frnxmr:monero.social> > And miners shouldnt be allowed to produce blocks smaller than the calculated size of the block based on effect of the highest paying tx's in the txpool on the median block size. (if the next block would increase by a max of 2% [102%], nobody should be intentionally producing blocks are 98%..)

<o​frnxmr:monero.social> My point being, that we shouldn't accept blocks that intentionally ignore scaling

<a​rticmine:monero.social> In addition the miner needs to include a given %the tx in the tx pool that would normally be included by a miner acting in a non adversarial manner.

<a​rticmine:monero.social> As for forcing a miner to mine over the Medians I am not sure. There are valid reasons why a miner may choose not to scale

None of this is visible for consensus (e.g. 1 year later syncing the chain), so it can't work.

<o​frnxmr:monero.social> It should still work when at chain tip

<a​rticmine:monero.social> It is not visible to consensus. What it does is increase the probability that the malicious blocks are orphaned.

<a​rticmine:monero.social> This can work where the attacker has less than 51%

<r​ucknium:monero.social> Ideally, it could discourage miners from mining empty blocks or blocks not constructed in the expected way. However, I would worry that it would change the battlefield to the network level. It is easy to spin up many nodes to try to speed up propagation of your empty block, even if honest nodes delay broadcast of that block.

<a​rticmine:monero.social> It can create a race. It is way easier to get people to run full nodes than to mine

Miners have an economic incentive to always mine on top of the longest chain, so they would simply circumvent this with a private block relay network that would accept empty blocks.

<o​frnxmr:monero.social> currently, they are losing 1-2 blocks im revenue to the "longest" (empty) chain

<o​frnxmr:monero.social> In*

<a​rticmine:monero.social> The longest chain seen by whom?

<a​rticmine:monero.social> It could lead to a chain split as occurred in 2018. That was close to a 90% attack and the results are history.

<a​rticmine:monero.social> I very much doubt that Qubic has the resources that Bitmain had in 2018

<a​rticmine:monero.social> A node relay response can be an interim option while we put together a stronger consensus response

<o​frnxmr:monero.social> if the network (particularly) mining pools updated to a node-relay option that rejected reorgs from blocks that sre notably smaller than the ones they already have confirmed, i think the incentive would be for miners to use said update

A good incentive would be to temporarily increase the minimum tx relay fee.

<o​frnxmr:monero.social> qubic doesnt care about tx fees (or txs). The pools that are mining the txs are losing the fees when the block gets reorged, then someone else mines the lost txs

Unless qubic has >50%, some blocks are still mined by honest miners, so their revenue would go up with increased fees. Probably enough to compensate them for orphaned blocks.

<p​reland:monero.social> The main challenge with Qubic is that they have many incentives to attempt to 51%, none of which are directly economic. Their two main ones are “clout” (ie look at how powerful our network is, pls give us extra funding 🥺) and compute gain (ie they 51% the network and force current XMR miners to jump ship in order to earn anything, which aids their claimed goal of AGI, at le<clipped message>

<p​reland:monero.social> ast according to them)

<h​bs:matrix.org> What would the effect be if empty blocks do not get the full 0.6 XMR but a small portion of that only? Wouldn't the economic incentive be too small for mining empty blocks to be sustainable?

<r​avfx:xmr.mx> They can made fake tx in so the blocks are not empty anymore, I think

<r​avfx:xmr.mx> Basically free

<p​reland:monero.social> Is it possible to notice needlessly empty blocks? ie there are clearly transactions in mempool that should’ve been included but were ignored

<h​bs:matrix.org> indeed, didn't think of that, I'm too honest!

<o​frnxmr:monero.social> Yes, but the problem is that it can split the network if N miners dont accept them but Y miners nodes do

<p​reland:monero.social> How many empty blocks with transactions in mempool should be allowed to occur before we can reasonably assume that something might be wrong

<o​frnxmr:monero.social> depends on how youe own txpool looks. If your own block templates would be mining 1.8mb blocks, and your receiving 100kb blocks from peers.. something is wrong

<o​frnxmr:monero.social> A miner can do this right now by simply setting the txpool size to (essentially) empty, or by using the proposed change to allow miners to set their block template target sized manually (can have a full tx pool and decide to mine 25kb)

<o​frnxmr:monero.social> There nothing on the network to prevent this, and qubic _could_ just be using a similar method to oroduce empty blocks.. though i imaging its more likely that they are mining on a "dark" slave node, and only relaying their blocks when they are ahead