<v​enture:monero.social> plowsof: "Rucknium have there been any KISS solutions of lifting suggested defences against selfish mining from published papers? Like instead of first seen, lick the winner at random? "

<v​enture:monero.social> Regarding what to pick as the random source, we could hash the array of all candidate block hashes and use the first bits as entropy for picking

<v​enture:monero.social> see here: matrix.to/#/!toFcRZtpaiwiyapgVO:mat…a=monero.social&via=cypherstack.com

<v​enture:monero.social> *all competing block hashes

<h​ardenedsteel:monero.social> juraj.bednar.io/en/blog-en/2020/11/…nsorship-will-most-likely-come-pt-2

<h​ardenedsteel:monero.social> may be good to read

<a​ntilt:we2.ee> History of BFT in Ethereum: past votes affect chain tip selection. eth2book.info/latest/part2/consensu…s/lmd_ghost/#finding-the-head-block

<v​enture:monero.social> voting, slashing, halting, liveness, safety, 1/3, 2/3... it's an entire can of worms

<v​enture:monero.social> I wonder if / when the project decides on a general direction forward, should we do weighted voting based proof_reserves? with slashing / voiding the vote if somebody votes more than once :)

<v​enture:monero.social> it would be a gauge for coin migration / price movement after the inevitable hard fork

<v​enture:monero.social> I also wonder why my proposal hasn't solicited more discussion..

<v​enture:monero.social> PoW, as I understand it has no deadlock (100% safety), but 33% liveness (defined as something good/expected happens, under selfish mining+51% attack)

<v​enture:monero.social> I believe my proposal raises that bar to 66% for the so-coined 51% attack to be profitable.

<v​enture:monero.social> if anybody wonders about the percentages, just have a look at yesterday's raid from qubic, their transparent hashrate was at around 2gh/s whereas 1gh/s was used internally for their side-chain

<v​tnerd:monero.social> Going through the linked paper @venture, hopefully I can say something constructive

<v​enture:monero.social> thanks! It would just be the section 3.6.1 that is relevant

<v​tnerd:monero.social> I wonder if this stems from a Bitcoin talk thread I was reading? I.e. where this came from

<v​enture:monero.social> byzcoin.. yeah no idea what happened to that and why it failed or never launched?, would be good to find that out. But yes, i did come to it from bitcointalk

<v​tnerd:monero.social> This is a crazy idea, but almost feels too easy. The thing is that it changes the selfish mining for sure, they can't predict which block chain will win. If your +2 on the side chain you potentially use lots of work by not being cooperative

<v​tnerd:monero.social> Looks like they werent using pow for byzcoin tho, but it should still work

<v​tnerd:monero.social> I'll look up the byzcoin discussion I guess. The problem is that this requires a hard fork, and that takes some time

<v​enture:monero.social> yes, it does seem more aligned. It doesn't eliminate the attack vector completely though, if you can generate blocks and compare hashes faster than rest. but this takes 150% network hashrate (the side chain hashrate is never included in monerod hashrate). 1/1.5 = 0.6666

<v​tnerd:monero.social> if Im understanding this correctly, we’d also need to broadcast all minority chains (that have valid pow) for this to work. currently we dont do this

<v​tnerd:monero.social> someone proposed this the other day

<v​enture:monero.social> not sure about this. in the honest / normal case, there are no minority chains? and if somebody broadcasts an altchain, we compare it with the main chain (each sibling if it's deeper than one block re-org)

<v​enture:monero.social> and reject atomically

<v​tnerd:monero.social> if Im reading this correctly, the suggestion is to make reorgs determinisitic but unpredictable via hashing

<v​tnerd:monero.social> everyone needs to compare both chains to make this happen

<v​enture:monero.social> yes, it's deterministic. and exponentially harder the longer re-org. since it's 0.5 if you have 2 candidate block hashes. 0.5^3 for the alt branch to be accepted + the needed difficulty in the first place

<v​tnerd:monero.social> selfish mining also becomes more unpredictable as you “lose” 50% of the time you try it. someone better with statistics may need to crunch the outcome

<v​enture:monero.social> *my example was for 3 blocks deep re-org

<v​tnerd:monero.social> I don’t follow the last part of your sentence. why would it get harder for longer reorgs?

<v​enture:monero.social> each competing block of the alt chain has a sibling in the main chain. it would be compared to each and the entire alt-chain would be rejected atomically

<v​enture:monero.social> since, this is not something that can be done in pure PoW?

<v​tnerd:monero.social> yeah I thought it was saying you put every block hash involved in sorted order into a hash function again, and then use that to determine which entire chain to use

<v​tnerd:monero.social> maybe I need to read the whole paper instead of skipping to this section?

<v​enture:monero.social> I will also read through again.. not sure if they went further. The sibling thing was my interpretation of it

<v​enture:monero.social> but intuitively, we want it to be exponentially harder with each block, instead of building an alt chain and then doing one coin-toss?

<v​tnerd:monero.social> Yes, but I don't see how it can done that way. You cant pick and choose blocks and you can't know which chain was seen first

<v​enture:monero.social> it's also used for indexing with which block to go with / mine upon. so having multiple block hashes at different levels in the array doesn't work

<v​tnerd:monero.social> The other issue is that I think this helps pop off honesst chains

<v​tnerd:monero.social> Nvm, not thrilled about it, but will look at Bitcoin talk for some outside thoughts

<v​enture:monero.social> doesn't the re-org procedure has the blockchain and the altchain?

<a​ntilt:we2.ee> eprint.iacr.org/2019/676.pdf, p.3 III for critique

<s​gp_:monero.social> With 3.6.1, am I missing something, or does this simply change how the singular top block in a chain is selected, if there are competing top blocks? A deep reorganization to a chain with more is still possible afaict

<v​enture:monero.social> they don't mention the selfish mining defense but other parts of byzcoin like their collective signing it seems

<v​enture:monero.social> well, how is it now selected? First seen? But yes, it changes

<v​enture:monero.social> and yes, it's still possible but with more hashing power to honest miners

<v​enture:monero.social> (imho)

It's only used to select between forks of equal chainwork. Longer chain still takes precedence.

<v​tnerd:monero.social> I still don't see how their defense mechanism works to the benefit of everyone. A selfish miner could just trigger a single alternative block proposal, and win 50% of the time

<s​gp_:monero.social> I tend to prefer the simplicity of the first block seen is the one that should be used, but this seems like a relatively minor implementation detail not a meaningful increase in security

<v​tnerd:monero.social> It doesn't work basically, I got excited because I was reading with too hopeful of eyes. Sorry

<v​tnerd:monero.social> Unless tevador has any follow ups

<v​enture:monero.social> it's a balance shift of 33% needed for a selfish miner to 66%

<s​gp_:monero.social> Where do you get the 66% from? Page 15?

<v​enture:monero.social> i guess you are right here. we would need to keep the fluffy orphans or fluffy orphan chain around for IBD/sync.

<v​enture:monero.social> But it wouldn't happen anymore than previous time before qubic, unless they have 66%

<v​enture:monero.social> i derived it. might be wrong. but since selfish mining doesn't increase network hashrate (they replace blocks), currently they need 33%. and with that change it would be 0.66 I THINK. need to formalize it again. but the percentages are tricky when we calculate attackers hashrate, since this is not transparent

AFAIK this deterministic fork selection was used to reduce the impact of network propagation delays. It was not meant to address selfish mining.

<s​gp_:monero.social> Having 51% hashrate would allow them to always have the longest block in any case under this scheme. So I don't see how it's possible to be higher than 51%

<v​tnerd:monero.social> Yes but the problem is they can still do one block in secret, then trigger this algorithm when the honest nodes relay there block. The selfish node would win 50% of the time. Currently the selfish mining algorithm gives up if there's another block relayed

<v​enture:monero.social> no, they directly tackle selfish mining with that

Yes, it makes selfish mining worse.

<v​tnerd:monero.social> And I don't think it works as expected

You can't use the deterministic selection for chains of different length, otherwise anyone can fork off a block of any age just by mining a block that wins the selection formula.

<v​enture:monero.social> i need to think it through, but my intuition is that blocks produced are basically a sampling function of the underlying hashrate.

<v​enture:monero.social> in 50% of the cases AFTER they produced a block, the attacker would need to generate another one which the majority was already mining upon

<v​enture:monero.social> that's why it needs to be applied at every level

<v​enture:monero.social> but maybe I'm really premature with this...

<s​gp_:monero.social> The example in the paper includes a finality layer with the PBFT, which might be crossing wires here

<v​enture:monero.social> ^ see my previous explanation.

<v​enture:monero.social> but again, i might be missing something

<v​enture:monero.social> "Currently the selfish mining algorithm gives up if there's another block relayed"

<v​enture:monero.social> I don't think this is accurate, they might be building nonetheless and hoping to catch up

<v​enture:monero.social> ah well, need to read sirer's paper again. but it's not substantial

<v​enture:monero.social> "(Now same length. Try our luck)" from the selfish-mining paper

<v​enture:monero.social> I believe, this would cut their luck of the sampling function / blocks found literally in half, which by definition eliminates their luck

<v​enture:monero.social> 51% of what? The effort that goes into the main chain? Not any side chain. That's not true then. if you have say 60% and eventually 40% of the hashrate produces a block and you attempt to override it, you have 50% chance to do so.

<v​enture:monero.social> so your 40% hashrate gives you 20% effective blocks produced under adverserial conditions (in the worst case), in the average case, it's 40

<v​enture:monero.social> ^ given the hash thing proposal

<v​enture:monero.social> currently:

<v​enture:monero.social> > 33%: need 50% luck to override / re-org the main chain

<v​enture:monero.social> > 50% can always override completely and catch-up the main chain eventually, ie. squat all blocks

<v​enture:monero.social> with the hashing:

<v​enture:monero.social> > 33% no chance to override the main chain *probabilisticly*. If you have 20%, 20% will go through eventually

<v​enture:monero.social> > 50% may cut others effective hashrate in half. 20% hashrate => 10% blocks over adversial times

<v​enture:monero.social> > 66% I believe that number is correct, can always override completely

<v​enture:monero.social> formatting went wrong , there should be an > before the numbers

<1​7lifers:matrix.org> put a backslash before each of the greater-than signs

<v​enture:monero.social> currently:

<v​enture:monero.social> \> 33%: need 50% luck to override / re-org the main chain

<v​enture:monero.social> \> 50% can always override completely and catch-up the main chain eventually, ie. squat all blocks

<v​enture:monero.social> with the hashing:

<v​enture:monero.social> \> 33% no chance to override the main chain _probabilisticly_. If you have 20%, 20% will go through eventually

<v​enture:monero.social> \> 50% may cut others effective hashrate in half. 20% hashrate => 10% blocks over adversial times

<v​enture:monero.social> \> 66% I believe that number is correct, can always override completely

<s​yntheticbird:monero.social> not repeating the same points challenge: IMPOSSIBLE

There is nothing you can do with PoW that protects the network from an attacker with >50% of the hashrate.

<s​yntheticbird:monero.social> Some people really believes that there exists some CONSENSUS algorithm that resist to 51% attack. aka consensus being resilient to consensus

<k​ayabanerve:matrix.org> tevador: you can get rid of it /s

<k​ayabanerve:matrix.org> 51% would be the bound even with full synchrony, yeah

<v​enture:monero.social> takes a bet and a monte carlo simulation to prove you wrong.

<v​enture:monero.social> we do agree that blocks are sampling from the hashrate distribution, right? So, under normal circumstances, having 2 players with 1% and 99% hashrate, will have the minor player produce 100 blocks out of 10,000 for example.

<v​enture:monero.social> same logic for 60/40 distribution.

<v​enture:monero.social> under adverserial circumstances, the blocks are not accurately sampling from the distribution because of overwritings by the major player.

<v​enture:monero.social> but I maintain, that in the range of 50-66%, at least half will get through and fail to be overriden given the hashing thingy.

<v​enture:monero.social> it's maybe easier to see when you think of effort or hashrate as thermodynamic work, general flow of entropy. the adversary mines need to "mine" backwards that direction since every time the hash-coin-toss fails for him, he needs to attempt again by finding a whole new block hash. and that will happen 50% of the time. he will be able to succeed in the other half, hence slashing th<clipped message>

<v​enture:monero.social> e expected payout of the victim in half (from 40% to 20%)

One detail you missed: an attacker with >50% of the hashrate can produce 100% of the blocks.

<v​enture:monero.social> tevador: right now, pure PoW, this is the case. if he chooses to do so / employ overwriting

The attacker can simply ignore all blocks they didn't mine themselves and eventually their chain will be the longest one. No magic math or hashes can help with that.

<v​enture:monero.social> for > 66%, yes

For >50%

<v​enture:monero.social> but I guess a monte carlo is warranted

<v​enture:monero.social> it would get rejected by the rest if he ignores one that didn't satisfy the hash condition

<v​enture:monero.social> it would get rejected by the rest if he ignores one that and builds a competing one that didn't satisfy the hash condition

Monte Carlo will just confirm what I said above. >50% by definition means the attacker is on average producing more chainwork than the rest of the network, so under any "most-work" rule, their chain will always be selected.

<v​enture:monero.social> we are talking about amending the most-work / LCR rule

OK, then please write out the complete set of changes (not here but in a document/repository) and then it can be reviewed. Any rule other than "most-work" is set to fail with PoW.

<v​enture:monero.social> "it's maybe easier to see when you think of effort or hashrate as thermodynamic work, general flow of entropy. the adversary mines need to "mine" backwards that direction since every time the hash-coin-toss fails for him, he needs to **attempt again by finding a whole new block hash**. and that will happen 50% of the time. he will be able to succeed in the other half, hence slashi<clipped message>

<v​enture:monero.social> ng the expected payout of the victim in half (from 40% to 20%)"

<v​enture:monero.social> please remember, the effort I highlighted will not contribute to cumulative difficulty

If your new rule is that everytime I encounter two valid blocks at the same height, I use a hash-coin-toss to select the correct one, then this is completely disfunctional. I can mine a block at height 1 until I win the coin toss and reorg the whole network to the genesis block.

<v​enture:monero.social> tevador: first of all, first you would need an altchain with similar cumulative diff. secondly, the coin toss is applied at every block along both chains

<v​tnerd:monero.social> A chain of one is the most interesting. A selfish miner ends up with even more blocks

<v​tnerd:monero.social> If you can't see this, then the discussion needs to happen in direct messages or something, because it's not going to work. The paper also had other flaws as listed in document above

You just said that cumulative diff rule was amended with the new rule.

If you want to continue, the chat should be in #monero-research-lounge

<v​enture:monero.social> it's okay, we can end it here. I will attempt to model a monte carlo simulation. but it's rather complex.

Then remember to model a scenario when a new node joins the network and is presented with the attacker's chain that has a much higher cumulative difficulty.

<v​enture:monero.social> ok