path: root/bd/878041e88cc00a1c411f16af1a28e45bb35bf0

Return-Path: <chris@suredbits.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id B7E8FC002A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  9 May 2023 15:09:31 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 92BEC614C2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  9 May 2023 15:09:31 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 92BEC614C2
Authentication-Results: smtp3.osuosl.org;
 dkim=pass (2048-bit key) header.d=suredbits-com.20221208.gappssmtp.com
 header.i=@suredbits-com.20221208.gappssmtp.com header.a=rsa-sha256
 header.s=20221208 header.b=nh7a4QH8
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id AbvGOiqhGvfP
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  9 May 2023 15:09:29 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 5FFE160E1D
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com
 [IPv6:2a00:1450:4864:20::531])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 5FFE160E1D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  9 May 2023 15:09:29 +0000 (UTC)
Received: by mail-ed1-x531.google.com with SMTP id
 4fb4d7f45d1cf-50bd37ca954so59939936a12.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 09 May 2023 08:09:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=suredbits-com.20221208.gappssmtp.com; s=20221208; t=1683644967; x=1686236967;
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :from:to:cc:subject:date:message-id:reply-to;
 bh=vwG488fj7asQrqhZQIg+5KHXaetirvyvVJqbNt3E8y0=;
 b=nh7a4QH81nHbDYlWXY2yxwfWF2xt5e9vsO/mb9XcQ5EKKZVyjYvtXGdTEDdDKlT7vD
 Shpc/Sso6vhC/BAfm/puR7P4tQCxqumA/wTe9yN0lAjgDueqmePXXHkBeYiMmRNPO3tJ
 VmewnjyPqdjKVw7VdWGbIDAEJHOK7Y/MJKnY4n7PECnJqf62r9FbMB/Wsh9nEasx9xh7
 fq103Vahkk2dZI2xThiKCpYLA1NHai2rTSQ8npP65o/7goVhmHJE5hmZ+vKCnpeEJc8k
 Py7rRI3KGLuJ5igUU7GfIu0TW4uyUvJ7xX75kpFqOz7lb7lJinGRqIX1LpkUmoxmSq5h
 i4DQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20221208; t=1683644967; x=1686236967;
 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=vwG488fj7asQrqhZQIg+5KHXaetirvyvVJqbNt3E8y0=;
 b=i2h+nsYXYxx3NJ/KjLLc+RXz05nR867dmh1pF2rfarP3W/3r6Zu+ZsF13spuvfEVB1
 x+PamGlbMEnN1kpmv8qeO/GCL5kaRt85cGRizTjCwHuRHG5PqK2Dfw5kRXdjWTDy/igo
 6GXfdLazbgg5DdrWJEueQcTqpSEt9h/3qRhskKvzb+RlnlmL7atcS1eH8jA6gKH7kHFA
 oesadPLKKKT9oTw807iFRJFW7YGrn+Rt2/FyhEGRHrvyGmh1n4kWtIJsSQfIQh6WAcFP
 aX2hmXKmp12lWl6UzWdz5IvEwkVKyualM7c5sLrTTDvFxDzAxS0J1/cZrcF8i/wNayrV
 cTCw==
X-Gm-Message-State: AC+VfDzvplaetkTBxQn3DibLimk/A+YZZtPWxxqrToGvphnLyXHYAn7M
 aK9jtZDJDf9GKIv8NPzwFZY77RNEHdjeQagSBPBZ0tkJjXIX8F+Mz+Y=
X-Google-Smtp-Source: ACHHUZ4j5cZ/1BPVeON/SbGM8uycn84eLgL9Yw92fASYh0fJx1JjQ5wutepsHxVA/KJPvEw3a9KVpkm+08iG2p3FPxE=
X-Received: by 2002:a17:907:318a:b0:965:ddb1:99d3 with SMTP id
 xe10-20020a170907318a00b00965ddb199d3mr10759948ejb.14.1683644967256; Tue, 09
 May 2023 08:09:27 -0700 (PDT)
MIME-Version: 1.0
References: <CALZpt+G_wqAqXkenDwdojT4EhpweYwe2DiCYZRFfCbMLL8DbVA@mail.gmail.com>
 <CALZpt+Ga5nT5yy=DpjiU8ULgnas=5CWJYqrRPu5i2Tyq5tG=UA@mail.gmail.com>
In-Reply-To: <CALZpt+Ga5nT5yy=DpjiU8ULgnas=5CWJYqrRPu5i2Tyq5tG=UA@mail.gmail.com>
From: Chris Stewart <chris@suredbits.com>
Date: Tue, 9 May 2023 10:09:16 -0500
Message-ID: <CAFQwNuwDCC08jbhAE2pjqi9JFNerP00JpGo9dfzT4j8KNc_+0A@mail.gmail.com>
To: Antoine Riard <antoine.riard@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000033a0ba05fb442479"
X-Mailman-Approved-At: Tue, 09 May 2023 16:18:39 +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: Tue, 09 May 2023 15:09:31 -0000

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

>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.

To summarize, assume we have Mary the Maker, Terry the Taker, and Bob the
bulletin board operator

1. Mary the Maker publishes a limit order to buy a derivative
2. Bob the bulletin board operator has the option to execute against Mary's
order
3. If Bob doesn't want to execute against the order, he relays the order to
Terry the Taker (and other subscribers to Bob's market)
4. Terry has the option to execute a trade against Mary's limit order
5. If Terry decides not to execute, Mary's order sits on the bulletin board=
.

I personally don't think this is that big of a concern, if Bob can collect
outsized profits from his trusted position as the bulletin board operator,
Terry will eventually move to other markets because Bob is only relaying
what Bob perceives to be unprofitable orders.

From the perspective of Mary, she is happy. Her order got executed at the
price she specified. Terry is the one that loses here. This model ends up
looking much more like a brokerage rather than an exchange market
structure. Terry should open up his own brokerage (bulletin board) and
compete on quoting prices with Bob.

Bob and Terry can then be compared on metrics like execution quality
<https://clearingcustody.fidelity.com/trade-execution-quality>, which then
draws more market activity since they are providing better prices.

>Somehow mass front-running on the board is a "champagne" issue I'll be
happy to have.

This. Frontrunning is a good problem to have, that means your market has
active participants and liquidity. Finding what products people are
interested in trading, and giving them a good user experience is more
important. Everything else will fall in line after that.


On Mon, May 1, 2023 at 1:06=E2=80=AFPM Antoine Riard via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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 propert=
y 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: fi=
at currencies, real goods, services. For some classes of goods, e.g commodi=
ties one cannot expect the same level of item liquidity due to cycle of pro=
duction and exogenous factors like weather. Some types of trades marketplac=
es might be exposed to far less front-running risks and rather would have t=
o deal with accurate risk modelling of the underlying goods. E.g attest the=
re is a decentralized identifier or any other linkage proof of the physical=
 good existence staying valid for the duration of offer lifetime. Offers co=
nditions themselves might be far more verbose and precise special Bitcoin S=
cript paths to morph the shipment risks.
>
> On the other hand, the types of trades like fiat currencies or bitcoin fi=
nancial contracts (e.g discreet log contracts or submarine swaps), front-ru=
nning risk by the bulletin board sounds a qualified concern. In traditional=
 finance, front-running is defined as "entering into an equity trade, optio=
ns or future contracts with advance knowledge of a block transaction that w=
ill influence the price of the underlying security to capitlize on the trad=
e" [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-bt=
c pair, seizing the opportunity by forwarding a HTLC across a Lightning pay=
ment 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-runnin=
g happening peer-to-peer marketplace. The first one is to duplicate the ann=
ouncement of the offers to a number of concurrent board operated by indepen=
dent identities and in parallel monitor the latency. Latency anomalies shou=
ld be spotted on by watchtower-like infrastructure at the service of makers=
/takers and in case of repeated anomalies a maker should disqualify the mis=
behaving board from future announcements. As all statistical mitigation it =
is not perfect and open the way to some margin of exploitation by the board=
s, as the watchtower monitoring frequency can be guessed. Additionally, thi=
s 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 un=
der Honey Badger BFT as used by Fedimint [1]. The incoming board offers bec=
ome consensus items that must be announced to all the federations members o=
nion gateway and which are not announced before a consensus proposal has be=
en adopted. The e-cash tokens can be rather Bitcoin-paid credentials requir=
ed 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" techn=
iques to extend the federation set [2]. One can imagine a federation consis=
ting of all the significant market participants, leveling the field for all=
.
>
> Is there another security paradigm direction to mitigate front-running an=
d other asymmetries of information ? I can't immediately imagine more thoug=
h I believe it stays an interesting open question.
>
> In fine, the Civkit proposes a flexible framework for peer-to-peer market=
place, where propagation latency monitoring and federation set and rules ca=
n be tweaked as "front-running resistance" parameters, adapting to the type=
s of trades and market participants tolerance. Configuration of those param=
eters will at the end be function of real-world deployments. Somehow mass f=
ront-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=
-trading
> [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 o=
n a
>> new peer-to-peer market system to enable censorship-resistant and
>> permissionless global trading in all parts of the world. While the desig=
n
>> aims in priority to serve on-ramp/off-ramp trading, it can be extended t=
o
>> support any kind of trading: goods, services, bitcoin financial derivati=
ves
>> like discreet log contracts.
>>
>> The design combines the Nostr architecture of simple relays announcing
>> trade orders to their clients with Lightning onion routing infrastructur=
e,
>> therefore granting high-level of confidentiality to the market
>> participants. The market boards are Nostr relays with a Lightning gatewa=
y,
>> each operating autonomously and in competition. The market boards can be
>> runned as a federation however there is no "decentralized orderbook" log=
ged
>> 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 th=
e
>> intermediary of privacy-preserving credentials backed by Bitcoin payment=
s,
>> 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 t=
o
>> 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 C=
ore
>> and we're looking forward to collaborating with everyone in the communit=
y
>> 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/=
002884.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
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><div><font face=3D"arial, sans-serif"><font style=3D"--dar=
kreader-inline-color: #e8e6e3;" color=3D"#000000">&gt;</font><font style=3D=
"--darkreader-inline-color: #e8e6e3;" color=3D"#000000"><span style=3D"whit=
e-space:pre-wrap">In traditional finance, front-running is defined as &quot=
;entering into an equity trade, options or future contracts with advance kn=
owledge of a block transaction that will influence the price of the underly=
ing security to capitlize on the trade&quot; [0]. In Bitcoin/Civkit parlanc=
e, a front-running could be a board on the discovery of a batch of market o=
ffers increasing liquidity for a fiat-2-btc pair, seizing the opportunity b=
y forwarding a HTLC across a Lightning payment path to enter into the trade=
, before publishing the offer on its board.</span></font></font></div><div>=
<font face=3D"arial, sans-serif"><font style=3D"--darkreader-inline-color: =
#e8e6e3;" color=3D"#000000"><span style=3D"white-space:pre-wrap"><br></span=
></font></font></div><div><font face=3D"arial, sans-serif"><font style=3D"-=
-darkreader-inline-color: #e8e6e3;" color=3D"#000000"><span style=3D"white-=
space:pre-wrap">To summarize, assume we have Mary the Maker, Terry the Take=
r, and Bob the bulletin board operator</span></font></font></div><div><font=
 face=3D"arial, sans-serif"><font style=3D"--darkreader-inline-color: #e8e6=
e3;" color=3D"#000000"><span style=3D"white-space:pre-wrap"><br></span></fo=
nt></font></div><div><font face=3D"arial, sans-serif"><font style=3D"--dark=
reader-inline-color: #e8e6e3;" color=3D"#000000"><span style=3D"white-space=
:pre-wrap">1. Mary the Maker publishes a limit order to buy a derivative</s=
pan></font></font></div><div><font face=3D"arial, sans-serif"><font style=
=3D"--darkreader-inline-color: #e8e6e3;" color=3D"#000000"><span style=3D"w=
hite-space:pre-wrap">2. Bob the bulletin board operator has the option to e=
xecute against Mary&#39;s order</span></font></font></div><div><font face=
=3D"arial, sans-serif"><font style=3D"--darkreader-inline-color: #e8e6e3;" =
color=3D"#000000"><span style=3D"white-space:pre-wrap">3. If Bob doesn&#39;=
t want to execute against the order, he relays the order to Terry the Taker=
 (and other subscribers to Bob&#39;s market)</span></font></font></div><div=
><font face=3D"arial, sans-serif"><font style=3D"--darkreader-inline-color:=
 #e8e6e3;" color=3D"#000000"><span style=3D"white-space:pre-wrap">4. Terry =
has the option to execute a trade against Mary&#39;s limit order<br></span>=
</font></font></div><div><font face=3D"arial, sans-serif"><font style=3D"--=
darkreader-inline-color: #e8e6e3;" color=3D"#000000"><span style=3D"white-s=
pace:pre-wrap">5. If Terry decides not to execute, Mary&#39;s order sits on=
 the bulletin board.</span></font></font></div><div><font face=3D"arial, sa=
ns-serif"><font style=3D"--darkreader-inline-color: #e8e6e3;" color=3D"#000=
000"><span style=3D"white-space:pre-wrap"><br></span></font></font></div><d=
iv><font face=3D"arial, sans-serif"><font style=3D"--darkreader-inline-colo=
r: #e8e6e3;" color=3D"#000000"><span style=3D"white-space:pre-wrap">I perso=
nally don&#39;t think this is that big of a concern, if Bob can collect out=
sized profits from his trusted position as the bulletin board operator, Ter=
ry  will eventually move to other markets because Bob is only relaying what=
 Bob perceives to be unprofitable orders.</span></font></font></div><div><f=
ont face=3D"arial, sans-serif"><font style=3D"--darkreader-inline-color: #e=
8e6e3;" color=3D"#000000"><span style=3D"white-space:pre-wrap"><br></span><=
/font></font></div><div><font face=3D"arial, sans-serif"><font style=3D"--d=
arkreader-inline-color: #e8e6e3;" color=3D"#000000"><span style=3D"white-sp=
ace:pre-wrap">From the perspective of Mary, she is happy. Her order got exe=
cuted at the price she specified. Terry is the one that loses here. This mo=
del ends up looking much more like a brokerage rather than an exchange mark=
et structure. Terry should open up his own brokerage (bulletin board) and c=
ompete on quoting prices with Bob. </span></font></font></div><div><font fa=
ce=3D"arial, sans-serif"><font style=3D"--darkreader-inline-color: #e8e6e3;=
" color=3D"#000000"><span style=3D"white-space:pre-wrap"><br></span></font>=
</font></div>Bob and Terry can then be compared on metrics like <a href=3D"=
https://clearingcustody.fidelity.com/trade-execution-quality">execution qua=
lity</a>, which then draws more market activity since they are providing be=
tter prices.<br><div><div><font face=3D"arial, sans-serif"><font style=3D"-=
-darkreader-inline-color: #e8e6e3;" color=3D"#000000"><span style=3D"white-=
space:pre-wrap"><br></span></font></font></div><div><font face=3D"arial, sa=
ns-serif"><font style=3D"--darkreader-inline-color: #e8e6e3;" color=3D"#000=
000">&gt;</font><font style=3D"--darkreader-inline-color: #e8e6e3;" color=
=3D"#000000"><span style=3D"white-space:pre-wrap">Somehow mass front-runnin=
g on the board is a &quot;champagne&quot; issue  I&#39;ll be happy to have.=
</span></font></font></div><div><font face=3D"arial, sans-serif"><font styl=
e=3D"--darkreader-inline-color: #e8e6e3;" color=3D"#000000"><span style=3D"=
white-space:pre-wrap"><br></span></font></font></div><div><font face=3D"ari=
al, sans-serif"><font style=3D"--darkreader-inline-color: #e8e6e3;" color=
=3D"#000000"><span style=3D"white-space:pre-wrap">This. Frontrunning is a g=
ood problem to have, that means your market has active participants and liq=
uidity. Finding what products people are interested in trading, and giving =
them a good user experience is more important. Everything else will fall in=
 line after that. <br></span></font></font></div><div><br></div></div></div=
><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mo=
n, May 1, 2023 at 1:06=E2=80=AFPM Antoine Riard via bitcoin-dev &lt;<a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfo=
undation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex"><div dir=3D"ltr"><pre style=3D"overflow-wrap: break-word;"><fon=
t face=3D"arial, sans-serif"><font color=3D"#000000"><span style=3D"white-s=
pace: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" target=3D"_blank">https://www.finra.org/investors/insigh=
ts/getting-speed-high-frequency-trading</a>
[1] <a href=3D"https://fedimint.org/docs/CommonTerms/HBBFTConsensus" target=
=3D"_blank">https://fedimint.org/docs/CommonTerms/HBBFTConsensus</a>
[2] <a href=3D"https://blockstream.com/assets/downloads/pdf/liquid-whitepap=
er.pdf" target=3D"_blank">https://blockstream.com/assets/downloads/pdf/liqu=
id-whitepaper.pdf</a></span></font></font></pre></div><br><div class=3D"gma=
il_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" target=3D"_blank">antoine.riard@gmail.com</a>&gt; a =C3=A9crit=C2=A0:<=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid 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 Nichol=
as Gregory (Commerce Block), Ray Youssef (the Built With Bitcoin foundation=
) and few others on a new peer-to-peer market system to enable censorship-r=
esistant 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 e=
xtended to support any kind of trading: goods, services, bitcoin financial =
derivatives like discreet log contracts.</div><div><br></div><div>The desig=
n combines the Nostr architecture of simple relays announcing trade orders =
to their clients with Lightning onion routing infrastructure, therefore gra=
nting high-level of confidentiality to the market participants. The market =
boards are Nostr relays with a Lightning gateway, each operating autonomous=
ly and in competition. The market boards can be runned as a federation howe=
ver there is no &quot;decentralized orderbook&quot; logged into the blockch=
ain. The trades are escrowed under Bitcoin Script contracts, relying on mod=
erations and know your peer oracles for adjudication.</div><div><br></div><=
div>The scoring of trades, counterparties and services operators should be =
enabled by the introduction of a Web-of-Stakes, assembled from previous ide=
as [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 li=
ke decentralized identifiers [1].</div><div><br></div><div>A consistent inc=
entive framework for service operators is proposed by the intermediary of p=
rivacy-preserving credentials backed by Bitcoin payments, following the lin=
eaments of IETF&#39;s Privacy Pass [2]. Services operators like market boar=
ds and oracles are incentivized to thrive for efficiency, akin to routing h=
ops on Lightning and miners on the base layer.</div><div><br></div><div>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 decentra=
lized standards established by Bitcoin Core and we&#39;re looking forward t=
o collaborating with everyone in the community to standardize libraries and=
 guarantee interoperability=C2=A0between clients with long-term thinking.</=
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-No=
vember/002884.html" target=3D"_blank">https://lists.linuxfoundation.org/pip=
ermail/lightning-dev/2020-November/002884.html</a></div><div>[1]=C2=A0<a hr=
ef=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://privacypa=
ss.github.io</a></div><div>[3]=C2=A0<a href=3D"https://github.com/civkit/pa=
per/blob/main/civ_kit_paper.pdf" target=3D"_blank">https://github.com/civki=
t/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>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--00000000000033a0ba05fb442479--