[bitcoin-dev] Bitcoin Transaction Relay over Nostr

From: Joost Jager <joost.jager@gmail•com>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: [bitcoin-dev] Bitcoin Transaction Relay over Nostr
Date: Tue, 23 May 2023 09:19:17 +0200	[thread overview]
Message-ID: <CAJBJmV932eeuiBzo_EMxJ1iU=Gave9=PC3U7seVoBXUFsu_GUA@mail.gmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 2865 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 9533 bytes --]