From: alicexbt <alicexbt@protonmail•com>
To: Joost Jager <joost.jager@gmail•com>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Bitcoin Transaction Relay over Nostr
Date: Tue, 23 May 2023 13:25:31 +0000 [thread overview]
Message-ID: <FVGoJA8LiudZ3BF2LRmy1w2tF-8IpZDKA49w56skRoerZ96j-qkxw-DUjSxZ3m-APMI_V-Wojn-rD3juO3IcBYRNAh9JwKFlyDWz3vwERS0=@protonmail.com> (raw)
In-Reply-To: <CAJBJmV932eeuiBzo_EMxJ1iU=Gave9=PC3U7seVoBXUFsu_GUA@mail.gmail.com>
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 show them as external mempool with transactions sorted by fee rate without affecting privacy of users.
- Mining pools will be incentivized to include these transaction in their blocks if they are using a higher fee rate compared to transactions in normal mempool used by bitcoin nodes or there is a mechanism to accept published offers, NIP4 is used to privately coordinate everything between user and pool. User can lock some sats in a 2of2 multisig and release it to mining pool 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 <bitcoin-dev@lists•linuxfoundation.org> wrote:
> 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
next prev parent reply other threads:[~2023-05-23 13:25 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-23 7:19 Joost Jager
2023-05-23 13:25 ` alicexbt [this message]
2023-05-23 15:26 ` Joost Jager
2023-05-28 2:37 ` David A. Harding
2023-05-30 12:30 ` Joost Jager
2023-05-30 13:30 ` Greg Sanders
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='FVGoJA8LiudZ3BF2LRmy1w2tF-8IpZDKA49w56skRoerZ96j-qkxw-DUjSxZ3m-APMI_V-Wojn-rD3juO3IcBYRNAh9JwKFlyDWz3vwERS0=@protonmail.com' \
--to=alicexbt@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=joost.jager@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox