<g​ingeropolous:monero.social> how does FCMP++ protocol stand up to massive reorgs?

<c​haser:monero.social> yes and no. the Carrot addressing protocol will give everyone address-conditional forward secrecy = you need to prevent a quantum adversary from learning any of the addresses derived from your mnemonic (github.com/jeffro256/carrot/blob/ma…address-conditional-forward-secrecy), and if you generate a Carrot-native mnemonic or derive a Carrot wallet from an e<clipped message>

<c​haser:monero.social> xisting hardware wallet mnemonic, you get internal forward secrecy = churned enotes and change from a transaction enters "post-quantum heaven" (github.com/jeffro256/carrot/blob/ma…rot.md#221-internal-forward-secrecy). IMHO in practice, the way most people use Monero (staying with old mnemonics, sharing addresses left and right, not churning, not generating a new tem<clipped message>

<c​haser:monero.social> porary mnemonic for each receive), this will obscure _some_ of the transaction graph from a quantum attacker, but still leave a lot of it available for tracing.

<b​oog900:monero.social> slightly worse than current protocol, the current one as long as your tx doesn't reference any recent outputs that have been reorged you are good. With FCMP you reference a block and you would want to reference the most recent block you can.

<b​oog900:monero.social> you would still follow the 10 block lock though FWIW, so most recent you can would be the block 10 blocks from the top

<a​krmn25:matrix.org> Hi not sure if this is the right channel, but I think there is a sort of Proof-of-Stake soft fork that preserves decentralization using something called 'helper blocks' or a variation of it. See here for the general idea: medium.com/coinmonks/taming-large-m…ers-with-helper-blocks-6ae67ac242f6

<a​fungible:matrix.org> matrix.monero.social/_matrix/media/…matrix.org/OmDYCvEYBrcJXYUPuqHYJnhr

<h​bs:matrix.org> nothing and everything is on the table at the moment.

<i​nterestingband:matrix.org> What's the point of reshuffle of already existing knowldege for 200 xmr (who is the target audince ? people who can't use search engine ?) ?

<i​nterestingband:matrix.org> You can't even verify correctness of cryptography (even audit won't help, bcs you don't know what to audit) and but going to write a book about how to design decentralized consensus superior to PoW (randomx)

<i​nterestingband:matrix.org> :D

<i​nterestingband:matrix.org> In case if you will say that you can, then go to verify correctness of existing cryptography in xmr :D

<i​nterestingband:matrix.org> rekt.news/hashrate-heist-or-hype

<i​nterestingband:matrix.org> :D

<k​ayabanerve:matrix.org> Since interestingband: is a troll who seemingly doesn't participate in any actual way other than to insult people, what's the threshold for removing them?

<a​illia:matrix.org> The Q* drama has brought in a flood of low-quality posts, hurting the quality of discussions, imo. Maybe consider pinning room rules for contributions to set clear thresholds.

<s​yntheticbird:monero.social> fwiw interestingband has been there way before the drama

<s​yntheticbird:monero.social> and is apparently in conflict with the monero core team, tho I don't think that gives him the right to be a jackass in this channel particularly

<a​illia:matrix.org> The Q\* drama has brought in a flood of low-quality posts (mostly from newcomers), hurting the quality of discussions, imo. Maybe consider pinning room rules for contributions to set clear thresholds.

<o​frnxmr:monero.social> IB is IB, but a troll he is not

<o​frnxmr:monero.social> [@aillia:matrix.org](https://matrix.to/#/@aillia:matrix.org) true that there are a lot of new faces, but IB has many important code contributions and is qualified to make accusations on code. Would be nice for specifics though

<o​frnxmr:monero.social> Kayaba, you might recognize them as ooo123

Funny that. No idea who that is, but I just looked at my ignore list and there a few variatinos around that nick. I'd grepped logs for the new nick and dumped it into the ignore list earlier too after finding nothing of interest.

<o​frnxmr:monero.social> Mooo, you know who it is too, but under another handle

So really, if people want to make a new nick and try to particupate, it's fine, but if you're going to spew only pointless drive, expect the new nick to also go there. Doesn't take a genius.

Possibly. Maybe a new nick will avoid the 100% dreck trap, which is honestly easy to avoid after a few lines.

<r​ucknium:monero.social> IB/ooo123/wafarussian(sp?)/anon ( ccs.getmonero.org/proposals/anon-perfect-peer-to-peer-protocol.html ) has contributed to Monero and trolls mercilessly. Both can be true.

<0​xfffc:monero.social> I don't agree with interestingband tone ( at all ). he/she attacked my personally many time. But on technical term, he has a point. and I think we should investigate his point, instead of banning him!

<s​yntheticbird:monero.social> agree

<r​ucknium:monero.social> He never gives any details to figure out if he has a point or not, let alone what that point actually may be. Room ban would be unwarranted at this time, IMHO.

<r​ucknium:monero.social> IIRC, koe banned him from this room years ago, but he came back few minutes later with a new alias.

<o​frnxmr:monero.social> Like 7 times :P

<o​frnxmr:monero.social> Koe muted him from his own acct, iirc it was sgp and erc that banned. Not that the specifics matter. The issue at that time was his multisig patch

<s​yntheticbird:monero.social> I would be glad if he could participate in monero discussion again without toxicity. I'm unsure this might be possible without their reward situation being resolved.

<s​yntheticbird:monero.social> I don't know the details tho afaik there has been no clear answers on the matter

<s​yntheticbird:monero.social> maybe im disgressing a bit, point is i agree banning him might be unwarranted, tho his tone is not welcome.

<r​ucknium:monero.social> Let's take this conversation into #monero-research-lounge:monero.social

<r​brunner7:monero.social> A bit long, and with some distractions, but also with some nice hard info IMHO: shai-deshe.gitbook.io/parallel-thou…f-of-work/the-qubic-minority-report

<s​gp_:monero.social> Yeah seems fair enough

<v​enture:monero.social> this comes from the graveyard I guess, a project named byzcoin, not sure what happened to it. But they had a countermeasure for selfish mining.

<v​enture:monero.social> Amending the Longest-Chain-Rule: They would put every competing block hashes in a sorted array, hash the array and the first bit of the hash as index (probably modulo len(competing blocks)) determines the block to mine upon further.

<v​enture:monero.social> arxiv.org/abs/1602.06997

<v​enture:monero.social> section 3.6.1

<v​enture:monero.social> 3.6.1 Keyblock Conflicts and Selfish Mining

<v​enture:monero.social> PBFT’s strong consistency by definition does not permit

<v​enture:monero.social> inconsistencies such as forks in the microblock chain.

<v​enture:monero.social> The way the miners collectively decide how to resolve

<v​enture:monero.social> keyblock conflicts, however, can still allow selfish min-

<v​enture:monero.social> ing [25] to occur as in Bitcoin. Worse, if the min-

<v​enture:monero.social> ers decide randomly to follow one of the two blocks,

<v​enture:monero.social> "the first bit", obviously not a literal bit.. would be the first 4 or 8 bits or so

<v​enture:monero.social> I think this qualifies for "Bolstering PoW". I would be very happy seeing it discussed and if no obvious show-stoppers come up, kayabanerve would you then put it up on the github issue?

<v​enture:monero.social> cc ArticMine

<k​ayabanerve:matrix.org> venture: Sorry, which part? The block to build on when there's ties or PBFT?

<k​ayabanerve:matrix.org> The paper's abstract describes layering a finality layer.

<k​ayabanerve:matrix.org> (PBFT is a consensus algorithm ran by a declared set of validators)

<k​ayabanerve:matrix.org> The rule of which block to prefer is a minor detail which is justified _due to the usage of PBFT_

<v​enture:monero.social> only the part 3.6.1 Keyblock Conflicts and Selfish Mining

<v​enture:monero.social> the amendment to the LCR

<v​enture:monero.social> hm does it not standalone?

<v​enture:monero.social> oh I see the point

<k​ayabanerve:matrix.org> I mean, currently Monero miners prefer the first seen block. With this, preferring the first seen block, they'd prefer the same block assuming they'd all seen the same candidate blocks. While the paper describes not splitting the BFT finality layer, the same premise would apply to the hash power of the next block? Except the question is which block do we want 'normal' hash power to mine?

<k​ayabanerve:matrix.org> Presumably, a selfish miner has delayed publication of their blocks, so yes, we would want to prefer the existing block. If two blocks are sent at the very same time, then we would want honest hash power to form a wall against any 'malicious' block by preferring one which isn't simply the one they first saw?

<v​enture:monero.social> well, trusted seed nodes to resolve could be done. it's discussed in relation to max-reorgs

<k​ayabanerve:matrix.org> Except if the blocks were sent at the same time, one block wasn't withheld, so it wasn't so malicious.

<k​ayabanerve:matrix.org> There are other criteria we could attempt to establish, but I'm unsure they're well-defined. In fact, I think this primarily just further enables selfish mining as someone who continues to mine the prior block _may replace the existing block AND be built upon_

<v​enture:monero.social> this presupposes that delaying broadcasting actually yields something, which is unlikely given the hash.

<v​enture:monero.social> now, if different nodes have different candidates to apply the rule, that might be an issue / edge-case which could be mitigated by less frequent blocks or entirely avoided by trusted seed nodes

<v​enture:monero.social> it's applied only at the tip

<v​enture:monero.social> it's applied only at the tip, not retroactively

<v​enture:monero.social> "In fact, I think this primarily just further enables selfish mining as someone who continues to mine the prior block may replace the existing block AND be built upon"

<v​enture:monero.social> he would need to mine on the second-last block, roll-the-dice and hopefully may continue with his chain with the next block, which is all to waste once a new block is found the majority was already mining upon

<v​enture:monero.social> btw, how does the current re-org procedure work, do we keep of cache of historic difficulty targets or is the target encoded in the previous / each block?

<v​enture:monero.social> btw, how does the current re-org procedure work, do we keep a cache of historic difficulty targets or is the target encoded in the previous / each block?

<v​enture:monero.social> btw, how does the current re-org procedure work, do we keep a cache of historic difficulty targets or is the target encoded in the previous / each block? nvm, found it, it's calulated from the last block with get_difficulty_for_next_block()

<c​howbungaman:matrix.org> Would any monero sages in this room be down to jump on tomorrow’s MoneroTopia to discuss all the options 🙏 Similar to what Luke did last week. Obviously we will open it up to everyone but would nice to have someone with a good handle on all the options being discussed to lead the discussion 🙏

<u​nt0ld:matrix.org> > I think more fees + GUI wallet mining by default would help a lot. Shill this to devs.

<u​nt0ld:matrix.org> >

<u​nt0ld:matrix.org> > The casual user should go out of their way to disable mining and higher fees. Not the other way around. The Monero software should be a bit selfish and try to support its network. The wallet must by default:

<u​nt0ld:matrix.org> > - Set up as a pruned node (public node if HDD, full node if >750GB SSD free).

<u​nt0ld:matrix.org> > - Mine, even a little.

<u​nt0ld:matrix.org> > - Don't have slow fee selected by default.

<v​enture:monero.social> "In fact, I think this primarily just further enables selfish mining as someone who continues to mine the prior block may replace the existing block AND be built upon"

<v​enture:monero.social> he would need to mine on the second-last block, roll-the-dice and hopefully may continue with his chain with the next block, which is all to waste once a new block is found the majority was already mining upon

<v​enture:monero.social> or the other way around, withholding a block, mining further and hoping his chain will not be invalidated by any new block coming in. And even if not invalidated (being lucky by 50%, assuming 2 candidates), he would need to broadcast now since any additional block collapses his little tower definitely.

<v​enture:monero.social> to add: replacing existing blocks AND building upon is currently the case without caveats / maybes.

<v​enture:monero.social> ^ edited

<v​enture:monero.social> not sure if this can be easily implemented, restricted to be applied only at the tip.

<v​enture:monero.social> if not, we could artificially compare each sibling of the competing chains, making a 10 block-reorg way harder (pow + 0.5^10 luck)

<v​enture:monero.social> this presupposes that delaying broadcasting actually yields something, which is unlikely given the hash.

<v​enture:monero.social> now, if different nodes have different candidates to apply the rule, that might be an issue / edge-case which could be mitigated by less frequent blocks or entirely avoided by trusted seed nodes, but with fluffy blocks, 2mins are already fine I think