05:23:36 <m-relay> <p​olar9669:matrix.org> Like 70-80% of monero nodes running behind nat?
07:14:24 <m-relay> <e​ndor00:matrix.org> [[Citation needed]]
08:52:49 <m-relay> <k​4r4b3y:karapara.net> i2p fixes this
13:09:16 <m-relay> <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.
13:10:11 <m-relay> <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." https://moneroresearch.info/index.php?action=resource_RESOURCEVIEW_CORE&id=99
13:11:36 <m-relay> <r​ucknium:monero.social> In December 2018 about 30% of Monero nodes did not accept incoming connections.
13:12:48 <m-relay> <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."
13:13:25 <m-relay> <r​ucknium:monero.social> The network is different now. There are a lot more machines that say they are Monero nodes now at least.
13:14:27 <m-relay> <r​ucknium:monero.social> I don't think it would be too difficult to redo their analysis.
13:29:17 <m-relay> <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)
13:30:27 <m-relay> <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
13:30:39 <m-relay> <e​ndor00:matrix.org> Though I guess we could just filter those out
13:32:58 <m-relay> <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
20:37:58 <m-relay> <s​ilverpill:poa.st> Is it possible to create something like this using Monero?
20:37:58 <m-relay> <s​ilverpill:poa.st> https://github.com/sigma0-xyz/zkbitcoin
20:37:59 <m-relay> <s​ilverpill:poa.st> https://github.com/sigma0-xyz/zkbitcoin/blob/main/whitepaper.pdf
20:37:59 <m-relay> <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>
20:38:00 <m-relay> <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>
20:38:00 <m-relay> <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.