diff options
| author | Antoine Riard <antoine.riard@gmail.com> | 2023-06-30 04:46:32 +0100 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2023-06-30 03:46:47 +0000 |
| commit | 71e034c35cd0d223fa936873bcfe54a4ee00e404 (patch) | |
| tree | 74dafa730f11b53bbef072f3841981df0e665d62 | |
| parent | c596dd1b56c4cb9dd420e531b8946471b6b4c1f3 (diff) | |
| download | pi-bitcoindev-71e034c35cd0d223fa936873bcfe54a4ee00e404.tar.gz pi-bitcoindev-71e034c35cd0d223fa936873bcfe54a4ee00e404.zip | |
Re: [bitcoin-dev] Civ Kit: A Peer-to-Peer Electronic Market System
| -rw-r--r-- | ed/ebbf2cae978e2c97002e2d447dd40b7481076b | 713 |
1 files changed, 713 insertions, 0 deletions
diff --git a/ed/ebbf2cae978e2c97002e2d447dd40b7481076b b/ed/ebbf2cae978e2c97002e2d447dd40b7481076b new file mode 100644 index 000000000..c9bc52f2e --- /dev/null +++ b/ed/ebbf2cae978e2c97002e2d447dd40b7481076b @@ -0,0 +1,713 @@ +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">> 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">> </span></font></font></div><div><font face=3D"arial, sans-serif"= +><font color=3D"#000000"><span style=3D"white-space:pre-wrap">> 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">> 2. Bob the bulletin board operator has th= +e option to execute against Mary'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">> 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)</span></font></font></div><div><font face=3D"arial, sans-ser= +if"><font color=3D"#000000"><span style=3D"white-space:pre-wrap">> 4. Te= +rry has the option to execute a trade against Mary'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">> 5. If Terry decides = +not to execute, Mary'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">> </span></font></font></div><div><f= +ont face=3D"arial, sans-serif"><font color=3D"#000000"><span style=3D"white= +-space:pre-wrap">> I personally don'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">> 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 "house" based on privileged = +"market-making" 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 "bad" order wasting timevalue of Terry'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">> 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">> 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 "brokers" which have more content aggregators. The brokerage se= +rvice will be harder to "trust-minimized", unless somehow all the= + Bobs are publishing their quoting prices in real-time.</span></div><div><b= +r></div><div>> 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 "board monitoring" a= +lgorithms suggested in section 5 "orderbook risks", 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" 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">> 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 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 "public boards" 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 <<a href=3D"mailt= +o:chris@suredbits.com">chris@suredbits.com</a>> 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">></font><font color=3D"#000000"><span style=3D= +"white-space:pre-wrap">In traditional finance, front-running is defined as = +"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" [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'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't want to execute against the order, he relays= + the order to Terry the Taker (and other subscribers to Bob'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'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'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'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">></font><font color=3D"#000000"><span style=3D"white-space= +:pre-wrap">Somehow mass front-running on the board is a "champagne&quo= +t; issue I'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 <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target= +=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>> 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 "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" [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 "honest" 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 "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 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 "front-running resistance" 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 "champagne" issue I'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 <<a href=3D"mailto:antoine.riard@gmail.= +com" target=3D"_blank">antoine.riard@gmail.com</a>> 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 "decentraliz= +ed orderbook" 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'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'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'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-- + + |