Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 565B1C002A for ; Tue, 23 May 2023 07:19:57 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 236FA407D7 for ; Tue, 23 May 2023 07:19:57 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 236FA407D7 Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20221208 header.b=ogGAsZ/t X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTFbGYxOqoDf for ; Tue, 23 May 2023 07:19:55 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 67F34402A7 Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) by smtp4.osuosl.org (Postfix) with ESMTPS id 67F34402A7 for ; Tue, 23 May 2023 07:19:55 +0000 (UTC) Received: by mail-ej1-x632.google.com with SMTP id a640c23a62f3a-96fe88cd2fcso362187466b.1 for ; Tue, 23 May 2023 00:19:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684826393; x=1687418393; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=81hHE503ZwMWue148JQRj7jtj2fIS3TZga0jHEnV9aE=; b=ogGAsZ/tw6TEle7VZj5cJWuCiqZNBa7LP+JjcUCiDZMByM1E6imIwRGzbLvnCkdWT6 e0tFNrlvXrJiu0+Nn2tRID2Jp/ENZMv/XmlLgzktwSuVJz9nepeQEDc8wzAFM5TI0z30 SlSL9MM0K1fpi9/MnbB+zGa7bZ8z1vMO3zjqPCwDDR24G/RtIhaczFm6MqEvXp6AJWdI Sz+Vii8T23Nj4ZcdTNQAesVC2F1uR/dFfZEmKrNNiwhfSGE0Vs5g4j2Wp98Na15wKPXo UcMnj7l0OishthbiEqIdDbHdnElFLHVZu6a1AJobABVFVBKl9G/xpGwitZJ4CBVuhcxa IrlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684826393; x=1687418393; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=81hHE503ZwMWue148JQRj7jtj2fIS3TZga0jHEnV9aE=; b=C+/r22S/8BbD/r71FYON+Rx5x2YJ5WWah1cwIZ3iKz6+pKsvHX1ufONIiTy5D3XsU2 9Bzo6LFjUDsmy2zpAEBVz3243iRofpdugHg9t9n2J76KdDMYCn6Cag/JyEChKH5jquFz RmRhqpEscAau9vvd3M+aMpqD2mSgwxy6rcULk9U/W7JPnHsMgeDt2ASlFPu0lk3s5T5X RG3QMXg/re4CVNJDfkN5fE+PzsanVAndZgxLsLdgqaXnssS8j+GqIH/lig/7BPt9WyOG zhwvqtKpxaJBOG91e9u+jDTryATkmljj8I/Caiz+El50iwanCVIRU8tNluI0my2rxgO6 fgxw== X-Gm-Message-State: AC+VfDylWCwB9xqVuyEbILkZppxhETtj4VtcZ9YYUw4NutuT0jCobByQ THsEOKkLf5tUWlDuEwH2HfnewZrn17jJbdzt/ELayGvkJw8= X-Google-Smtp-Source: ACHHUZ6+csLryBL40AjiSuoKBAWlssHwAX4148P9Wp4mvtn1UY7DTZRyr9ZqHQmip0ZGBG1Nlvq3zNxXfvNd3i9INtU= X-Received: by 2002:a17:907:31ce:b0:96a:6723:da48 with SMTP id xf14-20020a17090731ce00b0096a6723da48mr10369972ejb.75.1684826393021; Tue, 23 May 2023 00:19:53 -0700 (PDT) MIME-Version: 1.0 From: Joost Jager Date: Tue, 23 May 2023 09:19:17 +0200 Message-ID: To: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary="000000000000aa120905fc57362f" X-Mailman-Approved-At: Tue, 23 May 2023 09:58:53 +0000 Subject: [bitcoin-dev] Bitcoin Transaction Relay over Nostr X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2023 07:19:57 -0000 --000000000000aa120905fc57362f Content-Type: text/plain; charset="UTF-8" Hi, I write to get your thoughts on an alternative approach for Bitcoin transaction relay, addressing some of the limitations in the current peer-to-peer transaction relay system. To the best of my knowledge, the credit for the original concept goes to Ben Carman. I felt it would be beneficial to share the idea on this list to garner wider perspectives and feedback. The existing peer-to-peer (P2P) transaction relay system comes with a set of limitations that may negatively impact applications, notably those like Lightning that make extensive use of pre-signed transactions. A key limitation lies in the system's inability to relay transaction packages. This constraint can lead to HTLCs expiring before being swept, thereby risking fund losses. In addition, the P2P system falls short in supporting non-standard transactions, despite an established demand for such transactions in the marketplace. Nostr, an open and decentralized network of relays for public and ephemeral messages between pseudonymous entities, could help address these shortcomings. With the standards defined in NIP-89 [1], it becomes possible to broadcast arbitrary Bitcoin transaction packages, overcoming one of the key hurdles in the current relay system. In this proposed alternative relay mechanism, miners would listen for these broadcasted transaction packages and insert the packages into their local mempool. They can take advantage of the `submitpackage` RPC, limited to safe topologies only - specifically child and direct parents, tree only [2]. This feature could serve as an interim solution for package relay until it becomes available through the traditional P2P method. A notable advantage of this approach is that it delegates the responsibility of dealing with Denial-of-Service (DoS) threats to the relays themselves. They could, for example, require a payment to mitigate such concerns. There are in fact paid nostr relays already in operation. This partitioning would result in a clear separation between the Bitcoin transaction layer and DoS protection, introducing more flexibility in the system and potentially boosting its resilience. Implementing Nostr as a relay mechanism also has the potential to democratize access to miner mempools, thus leveling the playing field in the Bitcoin network. In the current state, those with direct connections or certain privileges can more readily submit transactions to miners, perhaps even through means as informal as email. I have been working on a prototype of this concept (based on [3]) and have captured its workings in a demonstration video [4]. Joost [1] https://github.com/nostr-protocol/nips/pull/476 [2] https://github.com/bitcoin/bitcoin/pull/27609#issuecomment-1544414801 [3] https://github.com/benthecarman/nostr-tx-broadcast [4] https://twitter.com/joostjgr/status/1658487013237211155 --000000000000aa120905fc57362f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi,


I write to get your thought= s on an alternative approach for Bitcoin transaction relay, addressing some= of the limitations in the current peer-to-peer transaction relay system. T= o the best of my knowledge, the credit for the original concept goes to Ben= Carman. I felt it would be beneficial to share the idea on this list to ga= rner wider perspectives and feedback.


The existing peer-to-peer (= P2P) transaction relay system comes with a set of limitations that may nega= tively impact applications, notably those like Lightning that make extensiv= e use of pre-signed transactions. A key limitation lies in the system's= inability to relay transaction packages. This constraint can lead to HTLCs= expiring before being swept, thereby risking fund losses. In addition, the= P2P system falls short in supporting non-standard transactions, despite an= established demand for such transactions in the marketplace.


Nostr, an open and decentra= lized network of relays for public and ephemeral messages between pseudonym= ous entities, could help address these shortcomings. With the standards def= ined in NIP-89 [1], it becomes possible to broadcast arbitrary Bitcoin tran= saction packages, overcoming one of the key hurdles in the current relay sy= stem.


In this proposed alternativ= e relay mechanism, miners would listen for these broadcasted transaction pa= ckages and insert the packages into their local mempool. They can take adva= ntage of the `submitpackage` RPC, limited to safe topologies only - specifi= cally child and direct parents, tree only [2]. This feature could serve as = an interim solution for package relay until it becomes available through th= e traditional P2P method.


A notable advantage of this= approach is that it delegates the responsibility of dealing with Denial-of= -Service (DoS) threats to the relays themselves. They could, for example, r= equire a payment to mitigate such concerns. There are in fact paid nostr re= lays already in operation. This partitioning would result in a clear separa= tion between the Bitcoin transaction layer and DoS protection, introducing = more flexibility in the system and potentially boosting its resilience.


Implementing Nostr as a rel= ay mechanism also has the potential to democratize access to miner mempools= , thus leveling the playing field in the Bitcoin network. In the current st= ate, those with direct connections or certain privileges can more readily s= ubmit transactions to miners, perhaps even through means as informal as ema= il.


I have been working on a pr= ototype of this concept (based on [3]) and have captured its workings in a = demonstration video [4].


Joost


[1] https://github.com/nostr-protocol/nips= /pull/476

[2] https://github.co= m/bitcoin/bitcoin/pull/27609#issuecomment-1544414801

[3] https://github.com/benthecarman/nos= tr-tx-broadcast

[4] https://twitter.com/joostjgr/st= atus/1658487013237211155

--000000000000aa120905fc57362f--