path: root/f8/1a27abfaa6013ce74774a395126e2fd85903c7

Return-Path: <alicexbt@protonmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 0EAD7C002A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 23 May 2023 13:25:49 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id C9FD182279
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 23 May 2023 13:25:48 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org C9FD182279
Authentication-Results: smtp1.osuosl.org;
 dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com
 header.a=rsa-sha256 header.s=protonmail3 header.b=X85+FPt4
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level: 
X-Spam-Status: No, score=-2.102 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,
 RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id XldppnGkoyxw
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 23 May 2023 13:25:47 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org A095582258
Received: from mail-40137.protonmail.ch (mail-40137.protonmail.ch
 [185.70.40.137])
 by smtp1.osuosl.org (Postfix) with ESMTPS id A095582258
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 23 May 2023 13:25:47 +0000 (UTC)
Date: Tue, 23 May 2023 13:25:31 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail3; t=1684848345; x=1685107545;
 bh=nWPGeE/PGDIwzY+JbcEnLzYu9BBnwkY2Y58yjwmjHKk=;
 h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References:
 Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
 Message-ID:BIMI-Selector;
 b=X85+FPt4PEK7bW+asZLiwoFC4KyFxa853D5sKL7+nSINOZuo4ZKBsSBnOeXfeT9lI
 UYOaLHUG2BDjuC9Ds6Qk3xX6X6W+s/WceiUzWFrm9HJTNiImM555tIrXvvP1hqdCxg
 AM78HRDlmLRJPVLOUXVcmXfbxF3f8yLipvBgfM+jdu7Zmdm7FVqtndCfFxZvO1mNAQ
 J7sx5I6Cyu8+u6jc//SNv/LIbAuhAfi01y+qR5SKYt8+U6fe96+zAqrR5Lw3igaNWJ
 fHyiKt1Aiqkwhx0y2PKfdX1iGKct7TyUVyqW72MRXslqkDe80UV7shI9kix3Kx15OW
 z07LIUR+WEqMQ==
To: Joost Jager <joost.jager@gmail.com>
From: alicexbt <alicexbt@protonmail.com>
Message-ID: <FVGoJA8LiudZ3BF2LRmy1w2tF-8IpZDKA49w56skRoerZ96j-qkxw-DUjSxZ3m-APMI_V-Wojn-rD3juO3IcBYRNAh9JwKFlyDWz3vwERS0=@protonmail.com>
In-Reply-To: <CAJBJmV932eeuiBzo_EMxJ1iU=Gave9=PC3U7seVoBXUFsu_GUA@mail.gmail.com>
References: <CAJBJmV932eeuiBzo_EMxJ1iU=Gave9=PC3U7seVoBXUFsu_GUA@mail.gmail.com>
Feedback-ID: 40602938:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Tue, 23 May 2023 14:38:11 +0000
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 23 May 2023 13:25:49 -0000

Hi Joost,

Transaction relay over nostr sounds interesting. I have 2 suggestions:

- Transactions could be encrypted when published as nostr events initially =
except size, fee rate and offer. This can be used by different clients to s=
how them as external mempool with transactions sorted by fee rate without a=
ffecting privacy of users.
- Mining pools will be incentivized to include these transaction in their b=
locks if they are using a higher fee rate compared to transactions in norma=
l mempool used by bitcoin nodes or there is a mechanism to accept published=
 offers, NIP4 is used to privately coordinate everything between user and p=
ool. User can lock some sats in a 2of2 multisig and release it to mining po=
ol on confirmation.

/dev/fd0
floppy disk guy

Sent with Proton Mail secure email.

------- Original Message -------
On Tuesday, May 23rd, 2023 at 12:49 PM, Joost Jager via bitcoin-dev <bitcoi=
n-dev@lists.linuxfoundation.org> wrote:


> Hi,
>=20
>=20
>=20
> I write to get your thoughts on an alternative approach for Bitcoin trans=
action relay, addressing some of the limitations in the current peer-to-pee=
r 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 shar=
e the idea on this list to garner wider perspectives and feedback.
>=20
>=20
>=20
> 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 limita=
tion lies in the system's inability to relay transaction packages. This con=
straint 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 m=
arketplace.
>=20
>=20
>=20
> Nostr, an open and decentralized network of relays for public and ephemer=
al messages between pseudonymous entities, could help address these shortco=
mings. With the standards defined in NIP-89 [1], it becomes possible to bro=
adcast arbitrary Bitcoin transaction packages, overcoming one of the key hu=
rdles in the current relay system.
>=20
>=20
>=20
> In this proposed alternative relay mechanism, miners would listen for the=
se broadcasted transaction packages and insert the packages into their loca=
l mempool. They can take advantage of the `submitpackage` RPC, limited to s=
afe 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.
>=20
>=20
>=20
> A notable advantage of this approach is that it delegates the responsibil=
ity of dealing with Denial-of-Service (DoS) threats to the relays themselve=
s. They could, for example, require a payment to mitigate such concerns. Th=
ere are in fact paid nostr relays already in operation. This partitioning w=
ould result in a clear separation between the Bitcoin transaction layer and=
 DoS protection, introducing more flexibility in the system and potentially=
 boosting its resilience.
>=20
>=20
>=20
> Implementing Nostr as a relay mechanism also has the potential to democra=
tize access to miner mempools, thus leveling the playing field in the Bitco=
in network. In the current state, those with direct connections or certain =
privileges can more readily submit transactions to miners, perhaps even thr=
ough means as informal as email.
>=20
>=20
>=20
> I have been working on a prototype of this concept (based on [3]) and hav=
e captured its workings in a demonstration video [4].
>=20
>=20
>=20
> Joost
>=20
>=20
>=20
> [1] https://github.com/nostr-protocol/nips/pull/476
>=20
> [2] https://github.com/bitcoin/bitcoin/pull/27609#issuecomment-1544414801
>=20
> [3] https://github.com/benthecarman/nostr-tx-broadcast
>=20
> [4] https://twitter.com/joostjgr/status/1658487013237211155