path: root/ed/ebbf2cae978e2c97002e2d447dd40b7481076b

Return-Path: <antoine.riard@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 26B1AC0037
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 30 Jun 2023 03:46:47 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id E0AC540194
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 30 Jun 2023 03:46:46 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org E0AC540194
Authentication-Results: smtp2.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20221208 header.b=QM2/wBOX
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 smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 9nhLaLjvkQkU
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 30 Jun 2023 03:46:44 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 7622A400E5
Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com
 [IPv6:2607:f8b0:4864:20::12c])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 7622A400E5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 30 Jun 2023 03:46:44 +0000 (UTC)
Received: by mail-il1-x12c.google.com with SMTP id
 e9e14a558f8ab-3426e9a9c3eso3585515ab.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 29 Jun 2023 20:46:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20221208; t=1688096803; x=1690688803;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=XdiHeQBAlTZ6qLa73jsjaZ9DZk9sSanFDnWdxQOo1W8=;
 b=QM2/wBOX2VqVXRQgS05Vd6wtxA6Gv7iQm008/zTnBhUtMU265+Ti4vMSatHkQdN8AE
 2W24MiDxuBXAXNtQp1HTOqkLTnZSp1WRZuyDNQ/WgD3PWsRkz9Tkmpcsh64euugAdAaO
 hFNIZuo78K4tfVeVG4549J4nQ/uuoCBJ++YVSmzc14cVWhv+OkVVxVe+bYdEdtxmbcfc
 rrO2ARLIJ/ZBMKy6xLuE2Rqx1ep1juFFogUjHUrXANktXPTMAwlTh3apkM9Sg425271c
 NREbvyDStXkgSmlTH/E2FM8anpRSe5BGZuPSZ55weL4REnmVNZDcCGqXv0zHP2qoOHPG
 6vNg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20221208; t=1688096803; x=1690688803;
 h=cc: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=XdiHeQBAlTZ6qLa73jsjaZ9DZk9sSanFDnWdxQOo1W8=;
 b=TI7vGGE47lLZE7ipKZb/iYr/Gy9+QwzxRD4oSw7huZIdoJ50ET00p+7XhAOaTApOaN
 iSG6xOUi+gEtrtqciDWQRd7LYHJMFFzvnGsyREeZSGtS3BvurlIwc99zMfms2hB5gUq8
 OhYh1twAQgwA7pHx5qNWFRfiNEXLmIdNeJneSehbCpEjjEHt65bLJhpB0G0n0fSAcJ+i
 QprY84cWRe9XzBkTxjivVo7VCPpumw69Ia2PtnIalDMX+3uKhJjVsLICa/Oj537Ql/Gg
 F9BTnMTqhPZXR9GAp5CiDa3DFcT8bBgMgX5r/KiTngDwPkC42Gucb83idTrhDuED2JFC
 iqvA==
X-Gm-Message-State: AC+VfDzGz6CDMt27911kO3SdS8WyObb9wPgvfOCbmViTWfpYdcaUYXtW
 FQyuolQEQgOklFQHkD01M6YahJPnZcwtljc112feuihP5e4=
X-Google-Smtp-Source: ACHHUZ6JO2CRl4a1yQqpMEZVOjytcEXeTbj1EkWiSL4CAWBuEHHIXrfOqRQxI8SjpywT5So55j+xAZRS68gC+gV4L1I=
X-Received: by 2002:a05:6e02:f91:b0:345:ad29:1f84 with SMTP id
 v17-20020a056e020f9100b00345ad291f84mr4725492ilo.3.1688096803175; Thu, 29 Jun
 2023 20:46:43 -0700 (PDT)
MIME-Version: 1.0
References: <CALZpt+G_wqAqXkenDwdojT4EhpweYwe2DiCYZRFfCbMLL8DbVA@mail.gmail.com>
 <CALZpt+Ga5nT5yy=DpjiU8ULgnas=5CWJYqrRPu5i2Tyq5tG=UA@mail.gmail.com>
 <CAFQwNuwDCC08jbhAE2pjqi9JFNerP00JpGo9dfzT4j8KNc_+0A@mail.gmail.com>
In-Reply-To: <CAFQwNuwDCC08jbhAE2pjqi9JFNerP00JpGo9dfzT4j8KNc_+0A@mail.gmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Fri, 30 Jun 2023 04:46:32 +0100
Message-ID: <CALZpt+GZgnRTpQZOpHQEo5Txt-DJZ+Zu=frm0OkoX6gzhZP-rg@mail.gmail.com>
To: Chris Stewart <chris@suredbits.com>
Content-Type: multipart/alternative; boundary="0000000000004cc12605ff50aa2f"
X-Mailman-Approved-At: Fri, 30 Jun 2023 13:07:48 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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: Fri, 30 Jun 2023 03:46:47 -0000

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

Hi Chris,

Thanks for the review and sorry for the late answer here.

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

Yes this is somehow a design assumption of the CivKit architecture, to keep
the migration cost low from a bulletin board to another one, if all the
orders are executed by the "house" based on privileged "market-making"
liquidity, and the outsized profits makes it interesting for another
incumbent to enter into the market, you will spawn competing bulletin
boards showing up.

Note, Terry the maker client might be okay to follow and pay the premium
for access to a market board, if the board has a very consistent policy
protecting against "bad" order wasting timevalue of Terry's liquidity.

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

Yes, I think this is very expected that you might have tiered services
where you have a market bulletin board specialized in processing
large-scale volume of data (with high-guarantees of fault-tolerance) and
another hand "brokers" which have more content aggregators. The brokerage
service will be harder to "trust-minimized", unless somehow all the Bobs
are publishing their quoting prices in real-time.

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

Yes, I think this is more or less the type of "board monitoring" algorithms
suggested in section 5 "orderbook risks", though the scoring criterias are
not presented like for the Fidelity definition of quality (i.e price
improvement, execution price, execution speed, effective spread).

One can expect to have this running as a "watchtower" like we have under
deployment for Lightning clients with fluctuating levels of flappyness.

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

While the first approach is the one more described in the CivKit paper,
from the history of peer-to-peer systems bootstrap, relying on social
assumptions like the over-the-counter ones might be more prolific. It might
also be a better user experience when people are exchanging cash versus
satoshis on the ground, or any other physical goods.

Ideally, if the offers data structures and the reputation framework common
between both OTC and "public boards" you might have traffic flows
circulating between both, and users will pick up the trading approach that
fits more the type of trades they wish to engage into. Compatibility of the
key-material for the clients between the different contexts sounds to
matter for smooth bootstrap too.

Best,
Antoine

Le mar. 9 mai 2023 =C3=A0 16:09, Chris Stewart <chris@suredbits.com> a =C3=
=A9crit :

> >In traditional finance, front-running is defined as "entering into an
> equity trade, options or future contracts with advance knowledge of a blo=
ck
> 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 collec=
t
> 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 wa=
s the lack of underscoring front-running resistance as a fundamental proper=
ty 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: f=
iat currencies, real goods, services. For some classes of goods, e.g commod=
ities one cannot expect the same level of item liquidity due to cycle of pr=
oduction and exogenous factors like weather. Some types of trades marketpla=
ces 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 th=
ere is a decentralized identifier or any other linkage proof of the physica=
l good existence staying valid for the duration of offer lifetime. Offers c=
onditions 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 f=
inancial contracts (e.g discreet log contracts or submarine swaps), front-r=
unning risk by the bulletin board sounds a qualified concern. In traditiona=
l finance, front-running is defined as "entering into an equity trade, opti=
ons or future contracts with advance knowledge of a block transaction that =
will influence the price of the underlying security to capitlize on the tra=
de" [0]. In Bitcoin/Civkit parlance, a front-running could be a board on th=
e discovery of a batch of market offers increasing liquidity for a fiat-2-b=
tc pair, seizing the opportunity by forwarding a HTLC across a Lightning pa=
yment path to enter into the trade, before publishing the offer on its boar=
d.
>>
>> I think you have at least two security paradigms to mitigate front-runni=
ng happening peer-to-peer marketplace. The first one is to duplicate the an=
nouncement of the offers to a number of concurrent board operated by indepe=
ndent identities and in parallel monitor the latency. Latency anomalies sho=
uld be spotted on by watchtower-like infrastructure at the service of maker=
s/takers and in case of repeated anomalies a maker should disqualify the mi=
sbehaving board from future announcements. As all statistical mitigation it=
 is not perfect and open the way to some margin of exploitation by the boar=
ds, as the watchtower monitoring frequency can be guessed. Additionally, th=
is 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 wit=
h a new liveliness requirement or additional cost for mobile clients.
>>
>> Another paradigm can be to run the bulletin boards as a federation e.g u=
nder Honey Badger BFT as used by Fedimint [1]. The incoming board offers be=
come consensus items that must be announced to all the federations members =
onion gateway and which are not announced before a consensus proposal has b=
een adopted. The e-cash tokens can be rather Bitcoin-paid credentials requi=
red 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 ther=
e is "consensus" publication. The federation could adopt some "DynFed" tech=
niques to extend the federation set [2]. One can imagine a federation consi=
sting of all the significant market participants, leveling the field for al=
l.
>>
>> Is there another security paradigm direction to mitigate front-running a=
nd other asymmetries of information ? I can't immediately imagine more thou=
gh I believe it stays an interesting open question.
>>
>> In fine, the Civkit proposes a flexible framework for peer-to-peer marke=
tplace, where propagation latency monitoring and federation set and rules c=
an be tweaked as "front-running resistance" parameters, adapting to the typ=
es of trades and market participants tolerance. Configuration of those para=
meters 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-frequenc=
y-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.co=
m> 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 desi=
gn
>>> aims in priority to serve on-ramp/off-ramp trading, it can be extended =
to
>>> support any kind of trading: goods, services, bitcoin financial derivat=
ives
>>> like discreet log contracts.
>>>
>>> The design combines the Nostr architecture of simple relays announcing
>>> trade orders to their clients with Lightning onion routing infrastructu=
re,
>>> therefore granting high-level of confidentiality to the market
>>> participants. The market boards are Nostr relays with a Lightning gatew=
ay,
>>> each operating autonomously and in competition. The market boards can b=
e
>>> runned as a federation however there is no "decentralized orderbook" lo=
gged
>>> 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-Trus=
t
>>> 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 la=
yer.
>>>
>>> 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 o=
f
>>> the Lightning Dev Kit [4] and Nostr libraries. All according to the bes=
t
>>> Bitcoin open-source and decentralized standards established by Bitcoin =
Core
>>> and we're looking forward to collaborating with everyone in the communi=
ty
>>> 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
>>
>

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

<div dir=3D"ltr">Hi Chris,<div><br></div><div>Thanks for the review and sor=
ry for the late answer here.</div><div><br></div><div><div><font face=3D"ar=
ial, sans-serif"><font color=3D"#000000"><span style=3D"white-space:pre-wra=
p">&gt; To summarize, assume we have Mary the Maker, Terry the Taker, and B=
ob the bulletin board operator</span></font></font></div><div><font face=3D=
"arial, sans-serif"><font color=3D"#000000"><span style=3D"white-space:pre-=
wrap">&gt; </span></font></font></div><div><font face=3D"arial, sans-serif"=
><font color=3D"#000000"><span style=3D"white-space:pre-wrap">&gt; 1. Mary =
the Maker publishes a limit order to buy a derivative</span></font></font><=
/div><div><font face=3D"arial, sans-serif"><font color=3D"#000000"><span st=
yle=3D"white-space:pre-wrap">&gt; 2. Bob the bulletin board operator has th=
e option to execute against Mary&#39;s order</span></font></font></div><div=
><font face=3D"arial, sans-serif"><font color=3D"#000000"><span style=3D"wh=
ite-space:pre-wrap">&gt; 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-ser=
if"><font color=3D"#000000"><span style=3D"white-space:pre-wrap">&gt; 4. Te=
rry has the option to execute a trade against Mary&#39;s limit order<br></s=
pan></font></font></div><div><font face=3D"arial, sans-serif"><font color=
=3D"#000000"><span style=3D"white-space:pre-wrap">&gt; 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, sans-serif"><font color=3D"#000000"><=
span style=3D"white-space:pre-wrap">&gt; </span></font></font></div><div><f=
ont face=3D"arial, sans-serif"><font color=3D"#000000"><span style=3D"white=
-space:pre-wrap">&gt; I personally don&#39;t think this is that big of a co=
ncern, if Bob can collect outsized profits from his trusted position as the=
 bulletin board operator, Terry  will eventually move to other markets beca=
use Bob is</span></font></font></div><div><font face=3D"arial, sans-serif">=
<font color=3D"#000000"><span style=3D"white-space:pre-wrap">&gt; only rela=
ying what Bob perceives to be unprofitable orders.</span></font></font></di=
v></div><div><font face=3D"arial, sans-serif"><font color=3D"#000000"><span=
 style=3D"white-space:pre-wrap"><br></span></font></font></div><div><font f=
ace=3D"arial, sans-serif"><font color=3D"#000000"><span style=3D"white-spac=
e:pre-wrap">Yes this is somehow a design assumption of the CivKit architect=
ure, to keep the migration cost low from a bulletin board to another one, i=
f all the orders are executed by the &quot;house&quot; based on privileged =
&quot;market-making&quot; liquidity, and the outsized profits makes it inte=
resting for another incumbent to enter into the market, you will spawn comp=
eting bulletin boards showing up.</span></font></font></div><div><font face=
=3D"arial, sans-serif"><font color=3D"#000000"><span style=3D"white-space:p=
re-wrap"><br></span></font></font></div><div><font face=3D"arial, sans-seri=
f"><font color=3D"#000000"><span style=3D"white-space:pre-wrap">Note, Terry=
 the maker client might be okay to follow and pay the premium for access to=
 a market board, if the board has a very consistent policy protecting again=
st &quot;bad&quot; order wasting timevalue of Terry&#39;s liquidity.</span>=
</font></font></div><div><font face=3D"arial, sans-serif"><font color=3D"#0=
00000"><span style=3D"white-space:pre-wrap"><br></span></font></font></div>=
<div><div><font face=3D"arial, sans-serif"><font color=3D"#000000"><span st=
yle=3D"white-space:pre-wrap">&gt; From the perspective of Mary, she is happ=
y. 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 t=
han an</span></font></font></div><div><span style=3D"white-space:pre-wrap;c=
olor:rgb(0,0,0);font-family:arial,sans-serif">&gt; exchange market structur=
e. Terry should open up his own brokerage (bulletin board) and compete on q=
uoting prices with Bob. </span></div><div><span style=3D"white-space:pre-wr=
ap;color:rgb(0,0,0);font-family:arial,sans-serif"><br></span></div><div><sp=
an style=3D"white-space:pre-wrap;color:rgb(0,0,0);font-family:arial,sans-se=
rif">Yes, I think this is very expected that you might have tiered services=
 where you have a market bulletin board specialized in processing large-sca=
le volume of data (with high-guarantees of fault-tolerance) and another han=
d &quot;brokers&quot; which have more content aggregators. The brokerage se=
rvice will be harder to &quot;trust-minimized&quot;, unless somehow all the=
 Bobs are publishing their quoting prices in real-time.</span></div><div><b=
r></div><div>&gt; Bob and Terry can then be compared on metrics like<span c=
lass=3D"gmail-Apple-converted-space">=C2=A0</span><a href=3D"https://cleari=
ngcustody.fidelity.com/trade-execution-quality" target=3D"_blank">execution=
 quality</a>, which then draws more market activity since they are providin=
g better prices.<br><div><span class=3D"gmail-im" style=3D"color:rgb(80,0,8=
0)"></span></div><br class=3D"gmail-Apple-interchange-newline"></div><div>Y=
es, I think this is more or less the type of &quot;board monitoring&quot; a=
lgorithms suggested in section 5 &quot;orderbook risks&quot;, though the sc=
oring criterias are not presented like for the Fidelity definition of quali=
ty (i.e price improvement, execution price, execution speed, effective spre=
ad).</div><div><br></div><div>One can expect to have this running as a &quo=
t;watchtower&quot; like we have under deployment for Lightning clients with=
 fluctuating levels of flappyness.</div><div><span style=3D"white-space:pre=
-wrap;color:rgb(0,0,0);font-family:arial,sans-serif"><br></span></div><div>=
<span style=3D"color:rgb(0,0,0);font-family:arial,sans-serif;white-space:pr=
e-wrap">&gt; 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 &gt; is m=
ore important. Everything else will fall in line after that.</span></div><d=
iv><span style=3D"color:rgb(0,0,0);font-family:arial,sans-serif;white-space=
:pre-wrap"><br></span></div><div><span style=3D"color:rgb(0,0,0);font-famil=
y:arial,sans-serif;white-space:pre-wrap">While the first approach is the on=
e more described in the CivKit paper, from the history of peer-to-peer syst=
ems bootstrap, relying on social assumptions like the over-the-counter ones=
 might be more prolific. It might also be a better user experience when peo=
ple are exchanging cash versus satoshis on the ground, or any other physica=
l goods.</span></div><div><span style=3D"color:rgb(0,0,0);font-family:arial=
,sans-serif;white-space:pre-wrap"><br></span></div><div><span style=3D"colo=
r:rgb(0,0,0);font-family:arial,sans-serif;white-space:pre-wrap">Ideally, if=
 the offers data structures and the reputation framework common between bot=
h OTC and &quot;public boards&quot; you might have traffic flows circulatin=
g between both, and users will pick up the trading approach that fits more =
the type of trades they wish to engage into. </span><span style=3D"color:rg=
b(0,0,0);font-family:arial,sans-serif;white-space:pre-wrap">Compatibility o=
f the key-material for the clients between the different contexts sounds to=
 matter for smooth bootstrap too.</span></div><div><span style=3D"color:rgb=
(0,0,0);font-family:arial,sans-serif;white-space:pre-wrap"><br></span></div=
><div><span style=3D"color:rgb(0,0,0);font-family:arial,sans-serif;white-sp=
ace:pre-wrap">Best,</span></div><div><span style=3D"color:rgb(0,0,0);font-f=
amily:arial,sans-serif;white-space:pre-wrap">Antoine</span></div></div></di=
v><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=
=C2=A0mar. 9 mai 2023 =C3=A0=C2=A016:09, Chris Stewart &lt;<a href=3D"mailt=
o:chris@suredbits.com">chris@suredbits.com</a>&gt; a =C3=A9crit=C2=A0:<br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,2=
04);padding-left:1ex"><div dir=3D"ltr"><div><font face=3D"arial, sans-serif=
"><font color=3D"#000000">&gt;</font><font color=3D"#000000"><span style=3D=
"white-space:pre-wrap">In traditional finance, front-running is defined as =
&quot;entering into an equity trade, options or future contracts with advan=
ce knowledge of a block transaction that will influence the price of the un=
derlying security to capitlize on the trade&quot; [0]. In Bitcoin/Civkit pa=
rlance, a front-running could be a board on the discovery of a batch of mar=
ket offers increasing liquidity for a fiat-2-btc pair, seizing the opportun=
ity by 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 color=3D"#000000"><span style=
=3D"white-space:pre-wrap"><br></span></font></font></div><div><font face=3D=
"arial, sans-serif"><font color=3D"#000000"><span style=3D"white-space:pre-=
wrap">To summarize, assume we have Mary the Maker, Terry the Taker, and Bob=
 the bulletin board operator</span></font></font></div><div><font face=3D"a=
rial, sans-serif"><font color=3D"#000000"><span style=3D"white-space:pre-wr=
ap"><br></span></font></font></div><div><font face=3D"arial, sans-serif"><f=
ont color=3D"#000000"><span style=3D"white-space:pre-wrap">1. Mary the Make=
r publishes a limit order to buy a derivative</span></font></font></div><di=
v><font face=3D"arial, sans-serif"><font 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 color=3D"#000000"><span style=3D"white-space:p=
re-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 color=
=3D"#000000"><span style=3D"white-space:pre-wrap">4. Terry has the option t=
o execute a trade against Mary&#39;s limit order<br></span></font></font></=
div><div><font face=3D"arial, sans-serif"><font color=3D"#000000"><span sty=
le=3D"white-space: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, sans-serif"><font color=3D"#000000"><span style=3D"white-space:p=
re-wrap"><br></span></font></font></div><div><font face=3D"arial, sans-seri=
f"><font color=3D"#000000"><span style=3D"white-space:pre-wrap">I personall=
y don&#39;t think this is that big of a concern, if Bob can collect outsize=
d 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.</span></font></font></div><div><font =
face=3D"arial, sans-serif"><font color=3D"#000000"><span style=3D"white-spa=
ce:pre-wrap"><br></span></font></font></div><div><font face=3D"arial, sans-=
serif"><font color=3D"#000000"><span style=3D"white-space:pre-wrap">From th=
e perspective of Mary, she is happy. Her order got executed at the price sh=
e specified. Terry is the one that loses here. This model ends up looking m=
uch more like a brokerage rather than an exchange market structure. Terry s=
hould open up his own brokerage (bulletin board) and compete on quoting pri=
ces with Bob. </span></font></font></div><div><font face=3D"arial, sans-ser=
if"><font 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" targe=
t=3D"_blank">execution quality</a>, which then draws more market activity s=
ince they are providing better prices.<br><div><div><font face=3D"arial, sa=
ns-serif"><font color=3D"#000000"><span style=3D"white-space:pre-wrap"><br>=
</span></font></font></div><div><font face=3D"arial, sans-serif"><font colo=
r=3D"#000000">&gt;</font><font color=3D"#000000"><span style=3D"white-space=
:pre-wrap">Somehow mass front-running on the board is a &quot;champagne&quo=
t; issue  I&#39;ll be happy to have.</span></font></font></div><div><font f=
ace=3D"arial, sans-serif"><font color=3D"#000000"><span style=3D"white-spac=
e:pre-wrap"><br></span></font></font></div><div><font face=3D"arial, sans-s=
erif"><font color=3D"#000000"><span style=3D"white-space:pre-wrap">This. Fr=
ontrunning is a good problem to have, that means your market has active par=
ticipants and liquidity. Finding what products people are interested in tra=
ding, 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 Mon, May 1, 2023 at 1:06=E2=80=AFPM Antoine Riard via bitcoi=
n-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=
=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pa=
dding-left:1ex"><div dir=3D"ltr"><pre><font face=3D"arial, sans-serif"><fon=
t 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" 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-width:1px;border-left-style:solid;border-left-color:rgb(204,2=
04,204);padding-left:1ex"><div dir=3D"ltr">Hi list,<div><br></div><div>We h=
ave 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 globa=
l trading in all parts of the world. While the design aims in priority to s=
erve on-ramp/off-ramp trading, it can be extended to support any kind of tr=
ading: goods, services, bitcoin financial derivatives like discreet log con=
tracts.</div><div><br></div><div>The design combines the Nostr architecture=
 of simple relays announcing trade orders to their clients with Lightning o=
nion routing infrastructure, therefore granting high-level of confidentiali=
ty to the market participants. The market boards are Nostr relays with a Li=
ghtning gateway, each operating autonomously and in competition. The market=
 boards can be runned as a federation however there is no &quot;decentraliz=
ed orderbook&quot; logged into the blockchain. The trades are escrowed unde=
r Bitcoin Script contracts, relying on moderations and know your peer oracl=
es for adjudication.</div><div><br></div><div>The scoring of trades, counte=
rparties 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 assign=
ed to each market entity. This reputation paradigm could be composed with s=
tate-of-the-art Web-of-Trust techniques like decentralized identifiers [1].=
</div><div><br></div><div>A consistent incentive framework for service oper=
ators is proposed by the intermediary of privacy-preserving credentials bac=
ked by Bitcoin payments, following the lineaments of IETF&#39;s Privacy Pas=
s [2]. Services operators like market boards and oracles are incentivized t=
o thrive for efficiency, akin to routing hops on Lightning and miners on th=
e base layer.</div><div><br></div><div>The whitepaper goes deep in the arch=
itecture of the system [3] (Thanks to the peer reviewers!).</div><div><br><=
/div><div>We&#39;ll gradually release code and modules, extensively buildin=
g on top of the Lightning Dev Kit [4] and Nostr libraries. All according to=
 the best Bitcoin open-source and decentralized standards established by Bi=
tcoin Core and we&#39;re looking forward to collaborating with everyone in =
the community to standardize libraries and guarantee interoperability=C2=A0=
between 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 A=
ntoine</div><div><br></div><div>[0]=C2=A0<a href=3D"https://lists.linuxfoun=
dation.org/pipermail/lightning-dev/2020-November/002884.html" target=3D"_bl=
ank">https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-Novembe=
r/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-di=
d-core-20220719/</a></div><div>[2]=C2=A0<a href=3D"https://privacypass.gith=
ub.io" target=3D"_blank">https://privacypass.github.io</a></div><div>[3]=C2=
=A0<a href=3D"https://github.com/civkit/paper/blob/main/civ_kit_paper.pdf" =
target=3D"_blank">https://github.com/civkit/paper/blob/main/civ_kit_paper.p=
df</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>
</blockquote></div>

--0000000000004cc12605ff50aa2f--