path: root/0c/7037fc7ec62c9a9c0534a56febbadcaaa6aca1

Return-Path: <antoine.riard@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id BF6F5C002A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  1 May 2023 17:48:00 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 8B34D41823
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  1 May 2023 17:48:00 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 8B34D41823
Authentication-Results: smtp4.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20221208 header.b=iyDNsfO9
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id nD2nvgW-cwqA
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  1 May 2023 17:47:58 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 869B541528
Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com
 [IPv6:2607:f8b0:4864:20::12c])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 869B541528
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  1 May 2023 17:47:58 +0000 (UTC)
Received: by mail-il1-x12c.google.com with SMTP id
 e9e14a558f8ab-32b1ee270ebso7625685ab.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 01 May 2023 10:47:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20221208; t=1682963277; x=1685555277;
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :from:to:cc:subject:date:message-id:reply-to;
 bh=lOnQLPB+vgo9iEVHfJsdeq2yUsgX4J4bmYacBe3ZVYs=;
 b=iyDNsfO9A7jmdTkfW7YK06SDLcaAi7p+aaTMgoMLvOWQ3PPJbvqOw5sTTgIIR+QN/e
 o8JXTqnSgG7GX45Q9XfLCtcEDPTzv/0Yh6OPCRg8uBsi7c4i8G8IQ/x8z2xgQgxt6HQu
 SwVMbqWtuUpjTC6RBdws+l5UQVloQeQfnNJs5XKnUjEBkAvHTwt/CHS8/v5PIQkcIkz1
 Q94K4B6UVxdvvMqmiZ/mjS7l8bXduoeo8nE+WtWPg4/1VyCAtAOD8xBywOMpJd5ZyzBQ
 CgRdMR/bnOrfZpnL5NH3e4VwTszmSE23MX67lGztnkmKEqoB+VWB6fA1NnSOBGJ8J7hc
 M+Ag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20221208; t=1682963277; x=1685555277;
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
 bh=lOnQLPB+vgo9iEVHfJsdeq2yUsgX4J4bmYacBe3ZVYs=;
 b=BCJEVObO9C/kRmPXvszUTCt4fDR4JJf6i4qWGGJ0JCISLGZLMYWYZwmxs2NYHt3eV/
 k3ul7KkL/PgT3BdbUSUFFExYvKeUgBE8+Ht9rSqU3D6YD29B3U9gnWLd1TObbj5vML2b
 /PthzNQh170ZycPi1NeV7JUlX5SGlKO3nV/HtZ0e64a9H2SWIHMBWMhzDVDpwYP+t+6n
 aE/fzTb/fxH/s4NSnXSlXDN7tZDiAfJbugc5x06bMTip28FCM/TIhe4wNKV6ztpMXyj4
 QCIMouw8841+7mVgtBvWl8lEgN9/QQS4APeo4BCr6BXM2Z5j7lPiRQgncI0NkS+qZkNi
 gCUg==
X-Gm-Message-State: AC+VfDwiMEiSF8Nln2qqnCCKWOifpkOxnhCX5OYPkSw8p1whBNY2rXDU
 GpsPNmMSPjUommc56L2arNHHMzKPE77TvAuNerfNujZn9HS4IeA5
X-Google-Smtp-Source: ACHHUZ5Y/XZx/93EVaGQsK4hcrokVS/dC7+oC8NxdW7WuEgnXfK5sHtf6nxxg5Kh1RLHlTrOTGoNCdQL+41HvwwFU+w=
X-Received: by 2002:a05:6e02:78a:b0:323:ced:cffe with SMTP id
 q10-20020a056e02078a00b003230cedcffemr9268137ils.12.1682963277051; Mon, 01
 May 2023 10:47:57 -0700 (PDT)
MIME-Version: 1.0
References: <CALZpt+G_wqAqXkenDwdojT4EhpweYwe2DiCYZRFfCbMLL8DbVA@mail.gmail.com>
In-Reply-To: <CALZpt+G_wqAqXkenDwdojT4EhpweYwe2DiCYZRFfCbMLL8DbVA@mail.gmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Mon, 1 May 2023 18:47:46 +0100
Message-ID: <CALZpt+Ga5nT5yy=DpjiU8ULgnas=5CWJYqrRPu5i2Tyq5tG=UA@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000004c7c6505faa56cb8"
X-Mailman-Approved-At: Mon, 01 May 2023 18:05:56 +0000
Subject: Re: [bitcoin-dev] Civ Kit: A Peer-to-Peer Electronic Market System
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 01 May 2023 17:48:00 -0000

--0000000000004c7c6505faa56cb8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi all,

One of the most relevant feedback I received on the paper publication
was the lack of underscoring front-running resistance as a fundamental
property wished for a peer-to-peer marketplace.

It is expected the level of front-running resistance aimed by the
market participants to be heavily functioned by the types of trades
considered: fiat currencies, real goods, services. For some classes of
goods, e.g commodities one cannot expect the same level of item
liquidity due to cycle of production and exogenous factors like
weather. Some types of trades marketplaces might be exposed to far
less front-running risks and rather would have to deal with accurate
risk modelling of the underlying goods. E.g attest there is a
decentralized identifier or any other linkage proof of the physical
good existence staying valid for the duration of offer lifetime.
Offers conditions themselves might be far more verbose and precise
special Bitcoin Script paths to morph the shipment risks.

On the other hand, the types of trades like fiat currencies or bitcoin
financial contracts (e.g discreet log contracts or submarine swaps),
front-running risk by the bulletin board sounds a qualified concern.
In traditional finance, front-running is defined as "entering into an
equity trade, options or future contracts with advance knowledge of a
block transaction that will influence the price of the underlying
security to capitlize on the trade" [0]. In Bitcoin/Civkit parlance, a
front-running could be a board on the discovery of a batch of market
offers increasing liquidity for a fiat-2-btc pair, seizing the
opportunity by forwarding a HTLC across a Lightning payment path to
enter into the trade, before publishing the offer on its board.

I think you have at least two security paradigms to mitigate
front-running happening peer-to-peer marketplace. The first one is to
duplicate the announcement of the offers to a number of concurrent
board operated by independent identities and in parallel monitor the
latency. Latency anomalies should be spotted on by watchtower-like
infrastructure at the service of makers/takers and in case of repeated
anomalies a maker should disqualify the misbehaving board from future
announcements. As all statistical mitigation it is not perfect and
open the way to some margin of exploitation by the boards, as the
watchtower monitoring frequency can be guessed. Additionally, this
latency monitoring paradigm sounds to be valid under the assumption
that at least one board is "honest" and board might have a holistic
interest to silently collude. Running or accessing monitoring
infrastructure comes with a new liveliness requirement or additional
cost for mobile clients.

Another paradigm can be to run the bulletin boards as a federation e.g
under Honey Badger BFT as used by Fedimint [1]. The incoming board
offers become consensus items that must be announced to all the
federations members onion gateway and which are not announced before a
consensus proposal has been adopted. The e-cash tokens can be rather
Bitcoin-paid credentials required by the board federation for
publication. The federation members earn an income as a group to
follow the consensus rules and be paid only when there is "consensus"
publication. The federation could adopt some "DynFed" techniques to
extend the federation set [2]. One can imagine a federation consisting
of all the significant market participants, leveling the field for
all.

Is there another security paradigm direction to mitigate front-running
and other asymmetries of information ? I can't immediately imagine
more though I believe it stays an interesting open question.

In fine, the Civkit proposes a flexible framework for peer-to-peer
marketplace, where propagation latency monitoring and federation set
and rules can be tweaked as "front-running resistance" parameters,
adapting to the types of trades and market participants tolerance.
Configuration of those parameters will at the end be function of
real-world deployments. Somehow mass front-running on the board is a
"champagne" issue  I'll be happy to have.

Best,
Antoine

[0] https://www.finra.org/investors/insights/getting-speed-high-frequency-t=
rading
[1] https://fedimint.org/docs/CommonTerms/HBBFTConsensus
[2] https://blockstream.com/assets/downloads/pdf/liquid-whitepaper.pdf


Le jeu. 13 avr. 2023 =C3=A0 15:10, Antoine Riard <antoine.riard@gmail.com> =
a
=C3=A9crit :

> Hi list,
>
> We have been working since a while with Nicholas Gregory (Commerce Block)=
,
> Ray Youssef (the Built With Bitcoin foundation) and few others on a new
> peer-to-peer market system to enable censorship-resistant and
> permissionless global trading in all parts of the world. While the design
> aims in priority to serve on-ramp/off-ramp trading, it can be extended to
> support any kind of trading: goods, services, bitcoin financial derivativ=
es
> like discreet log contracts.
>
> The design combines the Nostr architecture of simple relays announcing
> trade orders to their clients with Lightning onion routing infrastructure=
,
> therefore granting high-level of confidentiality to the market
> participants. The market boards are Nostr relays with a Lightning gateway=
,
> each operating autonomously and in competition. The market boards can be
> runned as a federation however there is no "decentralized orderbook" logg=
ed
> into the blockchain. The trades are escrowed under Bitcoin Script
> contracts, relying on moderations and know your peer oracles for
> adjudication.
>
> The scoring of trades, counterparties and services operators should be
> enabled by the introduction of a Web-of-Stakes, assembled from previous
> ideas [0]. From the Bitcoin UTXO set servicing as a trustless source of
> truth, an economic weight can be assigned to each market entity. This
> reputation paradigm could be composed with state-of-the-art Web-of-Trust
> techniques like decentralized identifiers [1].
>
> A consistent incentive framework for service operators is proposed by the
> intermediary of privacy-preserving credentials backed by Bitcoin payments=
,
> following the lineaments of IETF's Privacy Pass [2]. Services operators
> like market boards and oracles are incentivized to thrive for efficiency,
> akin to routing hops on Lightning and miners on the base layer.
>
> The whitepaper goes deep in the architecture of the system [3] (Thanks to
> the peer reviewers!).
>
> We'll gradually release code and modules, extensively building on top of
> the Lightning Dev Kit [4] and Nostr libraries. All according to the best
> Bitcoin open-source and decentralized standards established by Bitcoin Co=
re
> and we're looking forward to collaborating with everyone in the community
> to standardize libraries and guarantee interoperability between clients
> with long-term thinking.
>
> Feedback is very welcome!
>
> Cheers,
> Nick, Ray and Antoine
>
> [0]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-November/0=
02884.html
> [1] https://www.w3.org/TR/2022/REC-did-core-20220719/
> [2] https://privacypass.github.io
> [3] https://github.com/civkit/paper/blob/main/civ_kit_paper.pdf
> [4] https://lightningdevkit.org
>

--0000000000004c7c6505faa56cb8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><pre style=3D"word-wrap:break-word"><font face=3D"arial, s=
ans-serif"><font color=3D"#000000"><span style=3D"white-space:pre-wrap">Hi =
all,

One of the most relevant feedback I received on the paper publication was t=
he lack of underscoring front-running resistance as a fundamental property =
wished for a peer-to-peer marketplace.

It is expected the level of front-running resistance aimed by the market pa=
rticipants to be heavily functioned by the types of trades considered: fiat=
 currencies, real goods, services. For some classes of goods, e.g commoditi=
es one cannot expect the same level of item liquidity due to cycle of produ=
ction and exogenous factors like weather. Some types of trades marketplaces=
 might be exposed to far less front-running risks and rather would have to =
deal with accurate risk modelling of the underlying goods. E.g attest there=
 is a decentralized identifier or any other linkage proof of the physical g=
ood existence staying valid for the duration of offer lifetime. Offers cond=
itions themselves might be far more verbose and precise special Bitcoin Scr=
ipt paths to morph the shipment risks.

On the other hand, the types of trades like fiat currencies or bitcoin fina=
ncial contracts (e.g discreet log contracts or submarine swaps), front-runn=
ing risk by the bulletin board sounds a qualified concern. In traditional f=
inance, front-running is defined as &quot;entering into an equity trade, op=
tions or future contracts with advance knowledge of a block transaction tha=
t will influence the price of the underlying security to capitlize on the t=
rade&quot; [0]. In Bitcoin/Civkit parlance, a front-running could be a boar=
d on the discovery of a batch of market offers increasing liquidity for a f=
iat-2-btc pair, seizing the opportunity by forwarding a HTLC across a Light=
ning payment path to enter into the trade, before publishing the offer on i=
ts board.

I think you have at least two security paradigms to mitigate front-running =
happening peer-to-peer marketplace. The first one is to duplicate the annou=
ncement of the offers to a number of concurrent board operated by independe=
nt identities and in parallel monitor the latency. Latency anomalies should=
 be spotted on by watchtower-like infrastructure at the service of makers/t=
akers and in case of repeated anomalies a maker should disqualify the misbe=
having board from future announcements. As all statistical mitigation it is=
 not perfect and open the way to some margin of exploitation by the boards,=
 as the watchtower monitoring frequency can be guessed. Additionally, this =
latency monitoring paradigm sounds to be valid under the assumption that at=
 least one board is &quot;honest&quot; and board might have a holistic inte=
rest to silently collude. Running or accessing monitoring infrastructure co=
mes with a new liveliness requirement or additional cost for mobile clients=
.

Another paradigm can be to run the bulletin boards as a federation e.g unde=
r Honey Badger BFT as used by Fedimint [1]. The incoming board offers becom=
e consensus items that must be announced to all the federations members oni=
on gateway and which are not announced before a consensus proposal has been=
 adopted. The e-cash tokens can be rather Bitcoin-paid credentials required=
 by the board federation for publication. The federation members earn an in=
come as a group to follow the consensus rules and be paid only when there i=
s &quot;consensus&quot; publication. The federation could adopt some &quot;=
DynFed&quot; techniques to extend the federation set [2]. One can imagine a=
 federation consisting of all the significant market participants, leveling=
 the field for all.

Is there another security paradigm direction to mitigate front-running and =
other asymmetries of information ? I can&#39;t immediately imagine more tho=
ugh I believe it stays an interesting open question.

In fine, the Civkit proposes a flexible framework for peer-to-peer marketpl=
ace, where propagation latency monitoring and federation set and rules can =
be tweaked as &quot;front-running resistance&quot; parameters, adapting to =
the types of trades and market participants tolerance. Configuration of tho=
se parameters will at the end be function of real-world deployments. Someho=
w mass front-running on the board is a &quot;champagne&quot; issue  I&#39;l=
l be happy to have.

Best,
Antoine

[0] <a href=3D"https://www.finra.org/investors/insights/getting-speed-high-=
frequency-trading">https://www.finra.org/investors/insights/getting-speed-h=
igh-frequency-trading</a>
[1] <a href=3D"https://fedimint.org/docs/CommonTerms/HBBFTConsensus">https:=
//fedimint.org/docs/CommonTerms/HBBFTConsensus</a>
[2] <a href=3D"https://blockstream.com/assets/downloads/pdf/liquid-whitepap=
er.pdf">https://blockstream.com/assets/downloads/pdf/liquid-whitepaper.pdf<=
/a></span></font></font></pre></div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr" class=3D"gmail_attr">Le=C2=A0jeu. 13 avr. 2023 =C3=A0=C2=A015:10, =
Antoine Riard &lt;<a href=3D"mailto:antoine.riard@gmail.com">antoine.riard@=
gmail.com</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-s=
tyle:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D=
"ltr">Hi list,<div><br></div><div>We have been working since a while with N=
icholas Gregory (Commerce Block), Ray Youssef (the Built With Bitcoin found=
ation) and few others on a new peer-to-peer market system to enable censors=
hip-resistant and permissionless global trading in all parts of the world. =
While the design aims in priority to serve on-ramp/off-ramp trading, it can=
 be extended to support any kind of trading: goods, services, bitcoin finan=
cial derivatives like discreet log contracts.</div><div><br></div><div>The =
design combines the Nostr architecture of simple relays announcing trade or=
ders to their clients with Lightning onion routing infrastructure, therefor=
e granting high-level of confidentiality to the market participants. The ma=
rket boards are Nostr relays with a Lightning gateway, each operating auton=
omously and in competition. The market boards can be runned as a federation=
 however there is no &quot;decentralized orderbook&quot; logged into the bl=
ockchain. The trades are escrowed under Bitcoin Script contracts, relying o=
n moderations and know your peer oracles for adjudication.</div><div><br></=
div><div>The scoring of trades, counterparties and services operators shoul=
d be enabled by the introduction of a Web-of-Stakes, assembled from previou=
s ideas [0]. From the Bitcoin UTXO set servicing as a trustless source of t=
ruth, an economic weight can be assigned to each market entity. This reputa=
tion paradigm could be composed with state-of-the-art Web-of-Trust techniqu=
es like decentralized identifiers [1].</div><div><br></div><div>A consisten=
t incentive framework for service operators is proposed by the intermediary=
 of privacy-preserving credentials backed by Bitcoin payments, following th=
e lineaments of IETF&#39;s Privacy Pass [2]. Services operators like market=
 boards and oracles are incentivized to thrive for efficiency, akin to rout=
ing hops on Lightning and miners on the base layer.</div><div><br></div><di=
v>The whitepaper goes deep in the architecture of the system [3] (Thanks to=
 the peer reviewers!).</div><div><br></div><div>We&#39;ll gradually release=
 code and modules, extensively building on top of the Lightning Dev Kit [4]=
 and Nostr libraries. All according to the best Bitcoin open-source and dec=
entralized standards established by Bitcoin Core and we&#39;re looking forw=
ard to collaborating with everyone in the community to standardize librarie=
s and guarantee interoperability=C2=A0between clients with long-term thinki=
ng.</div><div><br></div><div>Feedback is very welcome!</div><div><br></div>=
<div>Cheers,</div><div>Nick, Ray and Antoine</div><div><br></div><div>[0]=
=C2=A0<a href=3D"https://lists.linuxfoundation.org/pipermail/lightning-dev/=
2020-November/002884.html" target=3D"_blank">https://lists.linuxfoundation.=
org/pipermail/lightning-dev/2020-November/002884.html</a></div><div>[1]=C2=
=A0<a href=3D"https://www.w3.org/TR/2022/REC-did-core-20220719/" target=3D"=
_blank">https://www.w3.org/TR/2022/REC-did-core-20220719/</a></div><div>[2]=
=C2=A0<a href=3D"https://privacypass.github.io" target=3D"_blank">https://p=
rivacypass.github.io</a></div><div>[3]=C2=A0<a href=3D"https://github.com/c=
ivkit/paper/blob/main/civ_kit_paper.pdf" target=3D"_blank">https://github.c=
om/civkit/paper/blob/main/civ_kit_paper.pdf</a></div><div>[4]=C2=A0<a href=
=3D"https://lightningdevkit.org" target=3D"_blank">https://lightningdevkit.=
org</a></div></div>
</blockquote></div>

--0000000000004c7c6505faa56cb8--