MIME-Version: 1.0
References: <CAJBJmV932eeuiBzo_EMxJ1iU=Gave9=PC3U7seVoBXUFsu_GUA@mail.gmail.com>
 <FVGoJA8LiudZ3BF2LRmy1w2tF-8IpZDKA49w56skRoerZ96j-qkxw-DUjSxZ3m-APMI_V-Wojn-rD3juO3IcBYRNAh9JwKFlyDWz3vwERS0=@protonmail.com>
In-Reply-To: <FVGoJA8LiudZ3BF2LRmy1w2tF-8IpZDKA49w56skRoerZ96j-qkxw-DUjSxZ3m-APMI_V-Wojn-rD3juO3IcBYRNAh9JwKFlyDWz3vwERS0=@protonmail.com>
From: Joost Jager <joost.jager@gmail.com>
Date: Tue, 23 May 2023 17:26:18 +0200
Message-ID: <CAJBJmV9sCCtyWS=yXuj9uG15t+d+hCcB-CrkNXL-Tk1UdaXVFg@mail.gmail.com>
To: alicexbt <alicexbt@protonmail.com>
Content-Type: multipart/alternative; boundary="000000000000688fac05fc5e04a7"
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Bitcoin Transaction Relay over Nostr
Precedence: list

--000000000000688fac05fc5e04a7
Content-Type: text/plain; charset="UTF-8"

Hi fd0,


> - 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.
>

I don't think this will work because those encrypted transactions could all
be fake and distort the view clients have on this 'mempool'?


> - 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.
>

I believe you are suggesting out-of-band payment in case the fee included
in the transaction itself is insufficient and CPFP/RBF is impossible or
impractical? The question is why would the miner trust you to indeed
release after confirmation? The 2-of-2 presumably has a clawback clause
with a timeout that could be used by the user to avoid paying.

Joost

--000000000000688fac05fc5e04a7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi fd0,</div><div><br></div><div class=3D"gmail_quote=
"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
- 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.<br></blockquote><div><br></div><div>I don&#39;t =
think this will work because those encrypted transactions could all be fake=
 and distort the view clients have on this &#39;mempool&#39;?</div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- 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.<br></blockquote><div><br></div><div>I believe you are s=
uggesting out-of-band payment in case the fee included in the transaction i=
tself is insufficient and CPFP/RBF is impossible or impractical?=C2=A0The q=
uestion is why would the miner trust you to indeed release after confirmati=
on? The 2-of-2 presumably has a clawback clause with a timeout that could b=
e used by the user to avoid paying.</div><div><br></div><div>Joost</div></d=
iv></div>

--000000000000688fac05fc5e04a7--