corollari

0x259af1b259dfd477afc47ff6d59c7bdba3d64c390e6edbb95ce76d599c9727de

corollari

Main idea

Build an off-chain orderbook DEX such as oasis with the following differences:

• Order matching is done by software running inside a trusted execution environment -> nobody can know what the orderbook looks like.
• Orders are broadcast along with range proofs that prove that the amounts are higher than a certain value.
• Use a scheme like tornado.cash to hide the creators of the order.

Information leakage

• Deposits and withdrawals, although these are not linked between them
• Orders that matched, although the amount of the order is not revealed

corollari

Date: 8/12/2020

Methodology

It's likely that the data collected has some biases due to the source (ACINQ explorer) and the filters we apply to the node list. Here's the list of steps performed:

1. Get the list from ACINQ (6111 nodes)
2. Filter out nodes for which ACINQ doesn't provides a url (3092 nodes left)
3. Filter out nodes that don't use the standard port 9735 (2589 nodes left). Reasoning: it's annoying to pass a different port for each IP to nmap
4. Filter out those that use IPv6 addresses (2553 nodes left). Reasoning: Again annoying to handle with nmap since it requires passing the -6 flag and splitting the batches
5. Ignore the nodes that had their ports closed on the first pass. Reasoning: This may be nodes that don't allow incoming tcp connections and instead initiate all the connections themselves. Here a better solution would be to ping them through the p2p network, but I only wanted to get a rough estimate and setting that up is too much work.

corollari

# Written by M. Umpalumpa

# cat dades.txt | cut -d '|' -f 2 | sed 's/$/,/g'  
library("tidyverse")
library("scales")  
library("cowplot")

m=c(32.13020295700615,  99.1405981485184,  1.5942239429670317,  0.1022817979395588,  89.89998743639623,  22.04740581659658,  2.908773788484201,  2.128161394532075,  19.854438448603766,  6.100715578450923,  73.52812544028787,  0.15303352123049677,  2.057510431112946,  0.5090975471690009,  8.822847307873154,  0.9646507894505084,  10.633486158012644,  10.752961215353686,  0.623227667529089,  1.9249673092713593,  1062.3245263045403,  2.4026945192310976,  0.4724306252362129,  0,  0,  2.4370985287994262,  2.4025600190304695,  14.294229431358646,  5.561130232484709,  58.91914985068248,  1.3802330592663525,  4.39056552762256,  2.282080180456862,  170.09152041345268,  183.1396468217296,  26.70259034244617,  0.8114306181571791,  110.40120381282193,  629.1901071865803,  0.09634317553917675,  9690.707387984183,  64.81246759592297,  8.264424183171974,  0.34785172662825015,  72.4988944

corollari

Building blocks

Let's start by describing it's main building block: the ability to make a reedem script (scriptPubKey in BTC terms) have access to the transaction that is attempting to spend it. This is achievable through several ways:

• BCH forked in OP_CHECKDATASIG some time ago to enable scripts encumbered by an oracle, but this enabled the construction of covenants as described in [1]
• Elements/Liquid directly forked in the opcode OP_CHECKSIGFROMSTACK proposed in [1], thus enabling the covenants described in that paper
• It's possible to check transaction contents by generating a signature for them inside the script and checking that against the real contents through OP_CHECKSIG ([2] describes how to do that for Schnorr signatures, but it is easily adaptable to ECDSA signatures)
• This would actually be viable on BTC if OP_CHECKSIG could be made to perform primitive operations (such as AND, comparisons...) but I believe that I have mathematically proved that this is impossible (intuition: CHECKSIG d

corollari

Keybase proof

I hereby claim:

• I am corollari on github.
• I am corollari (https://keybase.io/corollari) on keybase.
• I have a public key ASAKwzVVc42KOJZGd-k0-hDGsgi-sFdkIbyu5bM8SHDgVwo

To claim this, I am signing this object:

corollari

Background

In Onramper, the company I am currently working in, we are trying to minimize the amount of personal data that is stored on our systems, and, as part of that effort, I am currently building a system that will allow us to avoid storing any directly identifiable data while also allowing us to track repeated customers.

A simple way of achieving that would be to hash some unique per-customer data points such as email and call it a day, but the problem with that approach is the lack of a unique salt, which would make the creation of site-wide rainbow tables possible thus severely diminishing security.

Now you might think that adding salt on that hash would be simple, but consider that here we are generating the customer identifier, so storing per-customer salt on the database becomes infeasible because you have no way to index it (you need the salt to generate the identifier but you need the identifier to retrieve the salt). It should also be possible to take an approach where salt can be retrieved

corollari

Implementation strategies

• nonblocking sockets on the client

Experiments

I’ve simulated packet loss by commenting out the code responsible of sending packets on the server and the results obtained are pretty much what anyone might expect, the removal of replies leads to clients requests being repeated and, when the server is using at least once invocation semantics,

Note from the author:

Security

• udp being used to augment spam attacks

corollari

corollari

<!DOCTYPE HTML>
<html>
	<head>
		<title>Page</title>
		<meta charset="utf-8" />
		<link rel="shortcut icon" href="favicon.ico">
		<meta name="viewport" content="width=device-width, initial-scale=1" />
	</head>
	<body>