<b​awdyanarchist:matrix.org> The IEEE paper showed that "Publish or Perish" had a better chain quality metric than Bitcoin at γ>0.4 (percent of honest HP mining on the attacker's chain). It was the best performing protocol in the study for chain quality. Although they dont really discuss what expected values for γ might be in the wild.

<b​awdyanarchist:matrix.org> Attesting to an uncle block might make sense from an information theory perspective. An uncle block is a PoW piece of information that's traditionally discarded, but might have theoretical value for honest miners.

<k​ayabanerve:matrix.org> I've spent ~10 hours on Monero's undocumented hash to curve that's allegedly U's paper on extending the applicability of SW's methodology. AFAICT, it's the Elligator 2 map. Section 5.5 of the Elligator paper, describing applying Elligator 2 to Curve25519, matches exactly for the two candidate x coordinates.

<k​ayabanerve:matrix.org> It's ridiculous. I called to understand it, and if necessary, replace it with Elligator. I spent hours reading up on SW and U. Turns out what's now the famous SWU was actually a restatement of their collective works by a completely different group.

<k​ayabanerve:matrix.org> Shen Noether wrote an entire technical note, one of the first MRL publications, on this unknown, undocumented, potentially faster hash to curve algorithm

<k​ayabanerve:matrix.org> And it's Elligator the whole time

<k​ayabanerve:matrix.org> cc koe000, not because you need to reply, but we discussed this prior and you were the one who told me the Cryptonote authors alleged it's Ulas's work

<k​ayabanerve:matrix.org> The check if the first x coordinate is really weirdly implemented, but I believe it's 'just' an alternate expansion? Instead of checking if the evaluation of the curve formula is square, it computes an equivalent value to delay _when_ modular inverses are taken? It ends up only using two in the entire algorithm (if you drop the y coordinate, and only recover the x at least) which <clipped message

<k​ayabanerve:matrix.org> is probably optimal. The traditional method would use three.

<k​ayabanerve:matrix.org> Unfortunately, the elligator 2 used in IETF standards is distinct and we do still require people implement our special cryptography, even if it's the same paper.

<k​oe000:matrix.org> According to datatracker.ietf.org/doc/draft-irtf-cfrg-hash-to-curve/16, Elligator 2 did not show up until 2018. Cryptonote was coded in ~2012.

<v​enture:monero.social> matrix.monero.social/_matrix/media/…ero.social/uFwbOmZsNRzLkClvAkxRgBvw

<v​enture:monero.social> ^ if somebody feels intrigued to publish this as Github Issue for broader discussion, I would be grateful. Unfortunately, my account is being shadow-banned on GH and I don't know how GH support will take for this.

<v​enture:monero.social> *how long GH support will take for this

<l​owdegree:matrix.org> hello

<l​owdegree:matrix.org> .

<k​ayabanerve:matrix.org> monero-project/research-lab #142

<k​ayabanerve:matrix.org> koe000: The Elligator 2 paper was 2013 in ACM CCS.

<k​ayabanerve:matrix.org> It was also published to IACR in the first half of 2013, despite ACM CCS being late 2013.

<k​ayabanerve:matrix.org> Though before I looked up the exact timing, I did wonder if Elligator 2 may post-date Cryptonote, implying NvS was an associate of the authors. Especially since the implementation uses an implementation different from the specification, which I'd guess was a first draft before they realized the specified version was slightly more efficient? (It replaces a mul with an add)

<k​ayabanerve:matrix.org> As for why it's still in the paper at the bottom, my guess would be a forgotten leftover.

<k​ayabanerve:matrix.org> Oh. Rucknium: ^ At the next MRL meeting please?

<s​yntheticbird:monero.social> Meeting in this room in 5 minutes

<v​enture:monero.social> "^ if somebody feels intrigued to publish this as Github Issue for broader discussion, I would be grateful. Unfortunately, my account is being shadow-banned on GH and I don't know how long GH support will take for this."

<v​enture:monero.social> shadow-ban is resolved. it's online now monero-project/research-lab #141

<l​eonarth_:matrix.org> docs.dash.org/en/stable/docs/core/guide/dash-features-chainlocks.html

<l​eonarth_:matrix.org> did we consider this solution to prevent reorgs?

<k​ayabanerve:matrix.org> It's effectively a finality layer, though the proposal there would be a poor choice for Monero Leonardo. I was aware of it.

<l​eonarth_:matrix.org> what would be a poor choice, the quorum of 300 nodes?

<l​eonarth_:matrix.org> the way I understand it is as soon as a block is submitted to the network

<l​eonarth_:matrix.org> nodes lock on that block, therefore if an actor is selfish-mining when they submit a 6 block reorg it won't work

<l​eonarth_:matrix.org> as the first actor who submitted has its block locked and the reorg cannot happen

<l​eonarth_:matrix.org> seems smart

<r​avfx:xmr.mx> who decide what node get that role?

<l​eonarth_:matrix.org> also safe, b/c if the lock doesn't work, everything continues normally as if the chainlock feature didn't exist

<l​eonarth_:matrix.org> a quorum of 300 randomly selected nodes all agree to put a lock on the block so that it cannot be reorganized

<r​avfx:xmr.mx> oh, ok.

<r​avfx:xmr.mx> I read "dash" in the link so I tought it was fednodes related

<r​avfx:xmr.mx> But if its random and change, and can't be easily games, then it might be useful

<l​eonarth_:matrix.org> seems like a very smart idea, can't understand why it's not being considered

<j​ack_ma_blabla:matrix.org> random = inviting asshole nodes

<l​eonarth_:matrix.org> oh, so that's what kayabanerve meant as "poor choice" for monero

<l​eonarth_:matrix.org> we could be getting spy nodes in the quorum of 300

<r​avfx:xmr.mx> would need rules like no more than one node per /24

<r​avfx:xmr.mx> And MRL ban list executed in the algo, at minimum

<r​avfx:xmr.mx> Also maybe addning "node age" in the selection algo

<l​eonarth_:matrix.org> with proxies one can easily get more nodes in different /24 running from same infra

<l​eonarth_:matrix.org> also not hard to get multiple VMs around the globe

<l​eonarth_:matrix.org> rules on networking are more like a deterrent (get the evil guy to do more work), than an actual security measure

<r​avfx:xmr.mx> But you can know it's the same node, I think

<r​avfx:xmr.mx> like the trick to put the same node behind the same ip

<r​avfx:xmr.mx> erk, the same node behind many different IP

<r​avfx:xmr.mx> you want to prevent Lionlink to get 10% of the nodes lol

<l​eonarth_:matrix.org> would be nice if tech to produce a hardware signature that is temperproof would exist

<e​longated:matrix.org> This is Lab, let researchers discuss here; please move to lounge

<k​ayabanerve:matrix.org> Leonardo: The fact it doesn't achieve an optimal resilience bound.

<k​ayabanerve:matrix.org> In an asynchronous network, even if nodes can communicate, it doesn't achieve liveness (the adversary may require some amount of masternodes to cause this fault, but not the optimal bound).

<k​ayabanerve:matrix.org> It isn't that a finality layer is a bad idea IMO. It's that their consensus algorithm is a poor choice.

<k​ayabanerve:matrix.org> Correction: in an asynchronous network, an adversary with zero master nodes is able to completely stall finality.

<k​ayabanerve:matrix.org> (Under Dash's chain locks)

<k​ayabanerve:matrix.org> I'd also guess it's unsafe in an asynchronous network...

<k​ayabanerve:matrix.org> So:

<k​ayabanerve:matrix.org> Stops working in an asynchronous network

<k​ayabanerve:matrix.org> May finalize distinct blockchains under an asynchronous network (as briefly described in that blog post, it would, and I've never seen formal security proofs of their protocol)

<l​eonarth_:matrix.org> Understood kayabanerve, thank you for your input

<k​oe000:matrix.org> August 28th 2013 at the earliest. It's likely the cryptonote algorithm was written in 2012 or early 2013, although impossible to know for certain given their screwy history.

<k​ayabanerve:matrix.org> > 2013-06-02: received

<k​ayabanerve:matrix.org> eprint.iacr.org/2013/325 according to ePrint

<k​ayabanerve:matrix.org> I do agree it's close. I'm unsure if NvS had early access, or if they originally implemented the Ulas paper and immediately moved to Elligator once published, or what. That doesn't change the implemented hash to curve exactly matches the paper's section 5.5.