<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