<p​olar9669:matrix.org> Like 70-80% of monero nodes running behind nat?

<e​ndor00:matrix.org> [[Citation needed]]

<k​4r4b3y:karapara.net> i2p fixes this

<r​ucknium:monero.social> Except when i2p is DDoSed. Monero cannot fully rely on an anonymity network like Tor or i2p for that reason IMHO.

<r​ucknium:monero.social> endor00: Ask and you shall receive: Cao, T., Yu, J., Decouchant, J., Luo, X., & Verissimo, P. (2020) "Exploring the Monero peer-to-peer network." moneroresearch.info/index.php?action=resource_RESOURCEVIEW_CORE&id=99

<r​ucknium:monero.social> In December 2018 about 30% of Monero nodes did not accept incoming connections.

<r​ucknium:monero.social> If I am interpreting this paper correctly. "We say peers are active but unreachable if they are connected to nodes we connected to and if a connection could not be established with them."

<r​ucknium:monero.social> The network is different now. There are a lot more machines that say they are Monero nodes now at least.

<r​ucknium:monero.social> I don't think it would be too difficult to redo their analysis.

<e​ndor00:matrix.org> If that's the only criterium, then yeah, it could be done with my scanner as well (which I've done some significant improvements to, but not published)

<e​ndor00:matrix.org> The problem is that there is a massive amount of "fake" nodes from LinkingLion - and some that don't belong to their IP ranges either

<e​ndor00:matrix.org> Though I guess we could just filter those out

<e​ndor00:matrix.org> One thing I want to try implementing is the other side of the system (which is also what LinkingLion has implemented): a script that listens for incoming connections from peers to see if it gets any inbound connections from peers that it could not reach through outbound connections

<s​ilverpill:poa.st> Is it possible to create something like this using Monero?

<s​ilverpill:poa.st> github.com/sigma0-xyz/zkbitcoin

<s​ilverpill:poa.st> github.com/sigma0-xyz/zkbitcoin/blob/main/whitepaper.pdf

<s​ilverpill:poa.st> >We introduce a light multi-party computation protocol to verify zero-knowledge circuits on Bitcoin. This enables two use-cases: state-less zkapps (zero-knowledge applications) that lock funds on Bitcoin until users unlock them using zero-knowledge proofs, and stateful zkapps that allow users to update, deposit, and withdraw from a zkapp using zero-knowledge proofs. Since zero-kno<clipped message>

<s​ilverpill:poa.st> wledge proofs can’t be verified directly on Bitcoin (for lack of optimized opcodes) we use a multi-party committee to verify them off-chain and compute a single on-chain signature. The protocol is akin to a minimal layer 2 on top of Bitcoin that uses Bitcoin as a data-availability layer. Specifically, the committee in charge of verifying zero-knowledge proofs does not have to be<clipped message>

<s​ilverpill:poa.st> connected to the chain as hashes of circuits (verifier keys) are stored in UTXOs on-chain, and the latest state of a (stateful) application is also stored and kept on-chain.