Date: Tue, 23 May 2023 13:25:31 +0000
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
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Bitcoin Transaction Relay over Nostr
Precedence: list

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