02:22:24 qubic currently has a +5 alt chain 02:37:21 and ofc, they are mining almost no user transactions on their blocks, if any they are mining only their own 06:41:37 DataHoarder: Hello, is the fact that qubic doesn't collect users' fees the main reason for the claim that their selfish mining is not economically profitable, or there is some other factor? 06:41:54 no 06:42:14 not mining monero transactions just purely their loss and harm on rest of monero users 06:42:33 their selfish efficiency is very bad, even at high hashrates 06:42:42 they lose more than they'd mine normally 06:44:11 so effectively they mine less and more likely just grift others along the way 06:44:36 we look at just "blocks" and not monero amounts 06:44:59 (biased towards qubic favor) 06:45:45 their own templates are limited to around 20 transactions max, so it's mostly a joke of a system 06:53:14 Thanks for the reply. Why is their efficiency bad and why do they mine less than honest miners? Is it because of the delay in the propagation of blocks _inherent_ to selfish mining, or just because _they_ don't selfish mine "appropriately"? 07:28:50 Their block propagation is less efficient, and their selfish mining implementation is suboptimal. And they don't have enough hashrate. So everything at once contributes to them losing profits. 07:33:07

Thanks for the reply. Why is their efficiency bad and why do they mine less than honest miners? 07:33:56 their implementation is quite suboptimal, plus their own weird network has delays, plus their technical implementation limits them how big their templates can be, plus broken selfish implementation 07:34:16 even when they had hashrate they also had low efficiency, meaning they'd earn more without selfish 07:35:03 you'd have to ask or see their systems internally, no idea how they implemented selfish so badly 07:35:23 it's mostly to do more marketing, but even such an implementation can still do orphaning fine enough 10:11:56 OK, so economically-profitable selfish mining is not impossible but is "somehow difficult" to implement properly 10:15:59 https://github.com/libbitcoin/libbitcoin-system/wiki/Selfish-Mining-Fallacy 10:15:59 Last clarification: do you agree with Voskuill's thesis that selfish mining per se is not an attack but an optimization that depends on the flaw of latency-based pooling pressure that is common to all PoW systems? 10:15:59 (I'm in favor of pure PoW, this is just to properly understand the terms being used). 10:15:59 So, if Voskuill is right, as long as there is no double spend (theft), selfish mining is legitimate, even when they don't include txs or when they voluntary cause txs to be invalidated. So the question is: technically, in monero where do we draw the line between legitimate optimization and attack? We just include double-spending? Or also network disruption? Or something else? 10:17:15 how are we sure they aren't trying (but failing) to pull off a double spend attack? 10:20:06 Sure, if they are trying to double spend, that would qualify as an attack (theft). But my question is more theoretical, not just about qubic: what is the theoretical (technical?) criterion to distinguish between an attack and a legitimate optimization? 10:26:24 I would argue that in Monero if you have over 51% and don't include enough transactions to allow for scaling that is an attack. 10:26:24 You are effectively using 51% to impose a Bitcoin style block weight cap on Monero. So one cannot extrapolate from Bitcoin to Monero on this issue. 10:28:10 I guess I just defined the 51% Bitcoin small blocker attack on Monero 12:11:33 @andrea_togni:matrix.org: Transaction invalidation could be considered an attack: https://rucknium.me/posts/monero-18-block-reorg/ 13:26:48 Due to Monero circumstances it is a direct attack, specially deep reorgs 13:27:54 In Bitcoin case as the blog explains all transactions on the other branch just get mined again (minus double spends) 13:28:26 In Monero transactions get reverted even for non-attacking entities that just transacted then 13:51:39 Selfish mining from Qubic has stopped since about one hour ago 15:44:49 https://github.com/hbs/MoneroMisc/blob/master/CARROT-discussion.md 16:38:59 @articmine: Interesting point, but would you conclude from this that (big) miners should be forced to include txs in their blocks even if they don't want to for whatever reason? 16:42:08 If a way to require inclusion of these txs in blocks could be found, I think the protocol probably would require it. 16:45:47 The distinction between deep and non-deep reorgs is quite arbitrary, the 10 block lock is just how monero works. Distinguishing between a "non-attack" (below 10 reorgs) and attack (above 10) sounds weird, because the action of selfish mining is the same in both cases > Due to Monero circumstances it is a direct attack, specially deep reorgs 16:46:26 I call 10+ (or whatever causes invalidation) deep 16:46:49 It also allows double spends, ofc 16:47:14 You could consider multi day ones too 16:48:00 In bandaids like dns checkpointing the goal is to prevent deep reorgs (10+) but not outright remove selfish mining at lower depths 16:51:38 @rucknium: The distinction between respends and double-spends is very useful. In the first case there is no loss of money and therefore no theft. The loss of privacy seems to depend on a "flaw" of ring signatures in the case of long reorgs. So the term "attack" sounds quite strong in this case 16:56:51 AFAIK, the computer science literature uses the term "attack" very freely. 16:57:01 Maybe double spend can be understood as an "absolute" attack because it amounts to theft, while 10+ as a "relative" attack because it runs against monero specific rules > I call 10+ (or whatever causes invalidation) deep 16:57:14 So you can file a complaint with them :P 16:59:00 Basically anyone re-spending could be an opportunistic double spend 16:59:25 You can't know unless merchants or users show so 17:00:16 End user also has their privacy impacted due to decoys being recreated even in the case that the bug in Monero was fixed that caused ringdb tracking info to get removed 17:01:26 Someone assisting someone else to do theft is also considered malicious, and Qubic was aware of this before their two big reorgs 17:01:37 They even quoted our own messages that this would be the case 17:01:49 @rucknium: It's not a minor issue, because when it comes to fixes against an "attack", it is important to ascertain not only that the fix technically works, but also why it should be implemented in the first place 17:02:09 The line is drawn here where it moves from affecting miners to affecting end users or outright hurting them (not just delays) 17:03:10 Miners are free to stop mining Monero. They don't have a right to mine blocks however they want to. If they did, they would pay themselves one billion XMR for every block mined. 17:07:10 @andrea_togni:matrix.org: There is technically no difference between a respend and a double spend 17:07:44 Id personally use the terminology double spend and double spend attack, instead of respend 17:08:10 DataHoarder: Affecting users also includes not including their txs for whatever reason, which seems to be a prerogative of miners. Hurting users (like causing privacy loss) sounds as a stricter and better criterion 17:09:49 Miners can choose to not include txs as a way to force fees up 17:10:13 Its in a miners best interests to not grow the blocks, and force users to pay high fees 17:11:19 @ofrnxmr:xmr.mx: That doesn't really work without soft fork enforcement, i.e. miners don't build on blocks that include all txs. 17:11:32 it does work 17:11:44 Miners can choose to produce small blocks if they choose to 17:12:10 Yes, but they just lose fee revenue to the miners who do include the txs 17:12:17 which defeats their purpose 17:13:42 At these volume levels, sure 17:14:40 Is this because the difference can be told only by the actual receivers? > <@ofrnxmr:xmr.mx> There is technically no difference between a respend and a double spend 17:14:52 Imo yes 17:18:18 Yeah affect I mean a permanent hurt 17:18:26 Delay is not affecting users directly 17:18:47 That's an annoyance and Monero itself finds ways to not mine blocks for 40m+ on its own :) 17:28:36 If the transactions are economic based upon the principle of enlightenment self interest then yes miners should be expected to include those transactions. > <@andrea_togni:matrix.org> Interesting point, but would you conclude from this that (big) miners should be forced to include txs in their blocks even if they don't want to for whatever reason? 17:28:37 On the other hand if the transaction doesn't meet the above criteria it is very reasonable for a miner to not include the transaction. 17:33:33 One common misconception is that if the total fees paid exceed the penalty the miner should include the transaction. This is false. 17:33:33 In reality the lowest fee per byte transaction pays the highest incremental penalty. 17:33:33 So it is very legitimate for a miner to make a profit on scaling 17:38:28 @ofrnxmr:xmr.mx: That would clarify a lot. Q's selfish mining is not only legitimate mining optimization (à la Voskuill) but also an attack because it caused actual (and not just possible) double spends. Whether those double spends were "honest" or not doesn't really change the nature of what happened 18:06:54 the wording in how I referred to Qubic pre-deep-reorg and after changed, as well. Specially doing so after they specifically quoted our conversations to delay them, and it was proven in testnet 18:07:03 then afterwards go "reorg never happened and it's a lie" :)