-
DataHoarder
qubic currently has a +5 alt chain
-
DataHoarder
and ofc, they are mining almost no user transactions on their blocks, if any they are mining only their own
-
br-m
<andrea_togni:matrix.org> 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?
-
DataHoarder
no
-
DataHoarder
not mining monero transactions just purely their loss and harm on rest of monero users
-
DataHoarder
their selfish efficiency is very bad, even at high hashrates
-
DataHoarder
they lose more than they'd mine normally
-
DataHoarder
so effectively they mine less and more likely just grift others along the way
-
DataHoarder
we look at just "blocks" and not monero amounts
-
DataHoarder
(biased towards qubic favor)
-
DataHoarder
their own templates are limited to around 20 transactions max, so it's mostly a joke of a system
-
br-m
<andrea_togni:matrix.org> 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"?
-
sech1
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.
-
DataHoarder
<br-m> <andrea_togni:matrix.org> Thanks for the reply. Why is their efficiency bad and why do they mine less than honest miners?
-
DataHoarder
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
-
DataHoarder
even when they had hashrate they also had low efficiency, meaning they'd earn more without selfish
-
DataHoarder
you'd have to ask or see their systems internally, no idea how they implemented selfish so badly
-
DataHoarder
it's mostly to do more marketing, but even such an implementation can still do orphaning fine enough
-
br-m
<andrea_togni:matrix.org> OK, so economically-profitable selfish mining is not impossible but is "somehow difficult" to implement properly
-
br-m
-
br-m
<andrea_togni:matrix.org> 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?
-
br-m
<andrea_togni:matrix.org> (I'm in favor of pure PoW, this is just to properly understand the terms being used).
-
br-m
<andrea_togni:matrix.org> 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?
-
midipoet
how are we sure they aren't trying (but failing) to pull off a double spend attack?
-
br-m
<andrea_togni:matrix.org> 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?
-
br-m
<articmine> 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.
-
br-m
<articmine> 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.
-
br-m
<articmine> I guess I just defined the 51% Bitcoin small blocker attack on Monero
-
br-m
<rucknium> @andrea_togni:matrix.org: Transaction invalidation could be considered an attack:
rucknium.me/posts/monero-18-block-reorg
-
DataHoarder
Due to Monero circumstances it is a direct attack, specially deep reorgs
-
DataHoarder
In Bitcoin case as the blog explains all transactions on the other branch just get mined again (minus double spends)
-
DataHoarder
In Monero transactions get reverted even for non-attacking entities that just transacted then
-
DataHoarder
Selfish mining from Qubic has stopped since about one hour ago
-
nioc
-
br-m
<andrea_togni:matrix.org> @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?
-
br-m
<rucknium> If a way to require inclusion of these txs in blocks could be found, I think the protocol probably would require it.
-
br-m
<andrea_togni:matrix.org> 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 > <DataHoarder> Due to Monero circumstances it is a direct attack, specially deep reorgs
-
DataHoarder
I call 10+ (or whatever causes invalidation) deep
-
DataHoarder
It also allows double spends, ofc
-
DataHoarder
You could consider multi day ones too
-
DataHoarder
In bandaids like dns checkpointing the goal is to prevent deep reorgs (10+) but not outright remove selfish mining at lower depths
-
br-m
<andrea_togni:matrix.org> @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
-
br-m
<rucknium> AFAIK, the computer science literature uses the term "attack" very freely.
-
br-m
<andrea_togni:matrix.org> 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 > <DataHoarder> I call 10+ (or whatever causes invalidation) deep
-
br-m
<rucknium> So you can file a complaint with them :P
-
DataHoarder
Basically anyone re-spending could be an opportunistic double spend
-
DataHoarder
You can't know unless merchants or users show so
-
DataHoarder
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
-
DataHoarder
Someone assisting someone else to do theft is also considered malicious, and Qubic was aware of this before their two big reorgs
-
DataHoarder
They even quoted our own messages that this would be the case
-
br-m
<andrea_togni:matrix.org> @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
-
DataHoarder
The line is drawn here where it moves from affecting miners to affecting end users or outright hurting them (not just delays)
-
br-m
<rucknium> 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.
-
br-m
<ofrnxmr:xmr.mx> @andrea_togni:matrix.org: There is technically no difference between a respend and a double spend
-
br-m
<ofrnxmr:xmr.mx> Id personally use the terminology double spend and double spend attack, instead of respend
-
br-m
<andrea_togni:matrix.org> 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
-
br-m
<ofrnxmr:xmr.mx> Miners can choose to not include txs as a way to force fees up
-
br-m
<ofrnxmr:xmr.mx> Its in a miners best interests to not grow the blocks, and force users to pay high fees
-
br-m
<rucknium> @ofrnxmr:xmr.mx: That doesn't really work without soft fork enforcement, i.e. miners don't build on blocks that include all txs.
-
br-m
<ofrnxmr:xmr.mx> it does work
-
br-m
<ofrnxmr:xmr.mx> Miners can choose to produce small blocks if they choose to
-
br-m
<rucknium> Yes, but they just lose fee revenue to the miners who do include the txs
-
br-m
<rucknium> which defeats their purpose
-
br-m
<ofrnxmr:xmr.mx> At these volume levels, sure
-
br-m
<andrea_togni:matrix.org> 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
-
br-m
<ofrnxmr:xmr.mx> Imo yes
-
DataHoarder
Yeah affect I mean a permanent hurt
-
DataHoarder
Delay is not affecting users directly
-
DataHoarder
That's an annoyance and Monero itself finds ways to not mine blocks for 40m+ on its own :)
-
br-m
<articmine> 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?
-
br-m
<articmine> 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.
-
br-m
<articmine> One common misconception is that if the total fees paid exceed the penalty the miner should include the transaction. This is false.
-
br-m
<articmine> In reality the lowest fee per byte transaction pays the highest incremental penalty.
-
br-m
<articmine> So it is very legitimate for a miner to make a profit on scaling
-
br-m
<andrea_togni:matrix.org> @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
-
DataHoarder
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
-
DataHoarder
then afterwards go "reorg never happened and it's a lie" :)