path: root/04/bb32b0d89821d682339e213b2c70ed27d25e9f

Return-Path: <prayank@tutanota.de>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id C6F74C002F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 21 Jan 2022 23:45:39 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id A127E83EAA
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 21 Jan 2022 23:45:39 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 1.298
X-Spam-Level: *
X-Spam-Status: No, score=1.298 tagged_above=-999 required=5
 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001,
 PDS_OTHER_BAD_TLD=1.997, RCVD_IN_MSPIKE_H3=0.001,
 RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
 autolearn=no autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=tutanota.de
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 Os09ZPH8U30u
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 21 Jan 2022 23:45:37 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from w1.tutanota.de (w1.tutanota.de [81.3.6.162])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 30A1183E5E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 21 Jan 2022 23:45:37 +0000 (UTC)
Received: from w3.tutanota.de (unknown [192.168.1.164])
 by w1.tutanota.de (Postfix) with ESMTP id A6E77FA030D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 21 Jan 2022 23:45:34 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1642808734; 
 s=s1; d=tutanota.de;
 h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Cc:Date:Date:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:Sender;
 bh=syQHZILxjWuba6w2NqBcxmD/wBJT2N43l6YVLiyh2GU=;
 b=JPE/UHIy8uAhkF4BJ21CRyK89nRc27abIOA+tzPeP2WSYkYlMs4BP9jNNNQRD/x9
 4wSfpEo/GFycp5OeqzPyCwUu9HK7bpE1BZ34e9Ij3Q37DiXNSQ7CknrXXeyAUG6Ebha
 EAa3pfOgDiCijxe/G7Pne7UAUCPoLS2NvCoiHp2uq1T4OsHCVcATWwGXV8Jib+27EJo
 abekZh//yWofldHnTfS3oDgtasLHAQuuwXv7RPA+zktWGcY/3Ku1TYYH4j+wHISC+ck
 qJSagO8eyDE8kTCyHVY/V6VsgoW4v6tQgG6z1WlpwRcYYL9B2PXZHGBaElaUhJL2twk
 6tvltwf/vQ==
Date: Sat, 22 Jan 2022 00:45:34 +0100 (CET)
From: Prayank <prayank@tutanota.de>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <Mtz0y_---3-2@tutanota.de>
MIME-Version: 1.0
Content-Type: multipart/alternative; 
 boundary="----=_Part_185896_666031829.1642808734667"
X-Mailman-Approved-At: Sat, 22 Jan 2022 09:22:24 +0000
Subject: [bitcoin-dev] Bob-Pays-For-Transaction
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: Fri, 21 Jan 2022 23:45:39 -0000

------=_Part_185896_666031829.1642808734667
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I have rephrased things discussed in a [tweet thread][1] in 2020, added a f=
ew things and interested to know possible issues if we had an opt in policy=
 based on CPFP in which recipients pay fees for transactions instead of sen=
ders or most of the wallets followed this:

## Bob-Pays-For-Transaction

=3D=3DMotivation=3D=3D

CPFP is less explored, payjoin did not get enough adoption, fee market can =
be improved,
recipients paying fees for the transactions sounds interesting and it can a=
lso be used
in projects that use market making (maker-taker model).

1.Recipient cares about the urgency and the security of the payment in lot =
of transactions.
2.It might affect fee market post subsidy era and resolve issues with miner=
s revenue, security etc.

=3D=3D=3DReceiving wallet=3D=3D=3D

Provide easy options to use CPFP and pay fees that confirms the parent tran=
saction.

[CPFP calculator][1] by djbooth07 or effective fee rate shown in explorers =
like https://mempool.space can be helpful.

=3D=3D=3DSpending wallet=3D=3D=3D

Broadcast all transactions with 1 sat/vB

=3D=3DIssues=3D=3D

Few issues shared by Sergej Kotliar:

1.Receiver can pay via CPFP, but if that=E2=80=99s known about them it gets=
 exploitable, senders will consolidate lot of UTXOs by sending one output t=
o receiver.
2.Receivers would send their unconfirmed coins onward expecting others to p=
ay the fees until someone considers the transaction important enough to be =
confirmed soon.

Bitcoin Core does not allow you to spend [unconfirmed UTXO using GUI][2] an=
d most of the RPC in CLI. However Kristaps made an interesting point in the=
 linked issue that it could be allowed for transactions
 that do not signal RBF. It is not considered safe however lot of wallets a=
llow this including Wasabi
in which I recently found [some UI/UX issues][3] related to unconfirmed UTX=
O.

The part which may require changes in protocol:

The whole fee paid for such transactions wouldn't be paid to the miner conf=
irming the transaction but
it would be shared between the miners creating next N blocks.

=C2=A0 [1]: https://twitter.com/LaurentMT/status/1292100590462537733
=C2=A0 [2]: https://github.com/djbooth007/cpfp-calculator
=C2=A0 [3]: https://github.com/zkSNACKs/WalletWasabi/issues/7045
=C2=A0 [4]: https://github.com/bitcoin-core/gui/issues/242


--=20
Prayank

A3B1 E430 2298 178F

------=_Part_185896_666031829.1642808734667
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta http-equiv=3D"content-type" content=3D"text/html; charset=3DUTF-8=
">
  </head>
  <body>
<div>I have rephrased things discussed in a [tweet thread][1] in 2020, adde=
d a few things and interested to know possible issues if we had an opt in p=
olicy based on CPFP in which recipients pay fees for transactions instead o=
f senders or most of the wallets followed this:<br></div><div dir=3D"auto">=
<br></div><div dir=3D"auto">## Bob-Pays-For-Transaction<br></div><div dir=
=3D"auto"><br></div><div dir=3D"auto">=3D=3DMotivation=3D=3D<br></div><div =
dir=3D"auto"><br></div><div dir=3D"auto">CPFP is less explored, payjoin did=
 not get enough adoption, fee market can be improved,<br></div><div dir=3D"=
auto">recipients paying fees for the transactions sounds interesting and it=
 can also be used<br></div><div dir=3D"auto">in projects that use market ma=
king (maker-taker model).<br></div><div dir=3D"auto"><br></div><div dir=3D"=
auto">1.Recipient cares about the urgency and the security of the payment i=
n lot of transactions.<br></div><div dir=3D"auto">2.It might affect fee mar=
ket post subsidy era and resolve issues with miners revenue, security etc.<=
br></div><div dir=3D"auto"><br></div><div dir=3D"auto">=3D=3D=3DReceiving w=
allet=3D=3D=3D<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">Provi=
de easy options to use CPFP and pay fees that confirms the parent transacti=
on.<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">[CPFP calculator=
][1] by djbooth07 or effective fee rate shown in explorers like https://mem=
pool.space can be helpful.<br></div><div dir=3D"auto"><br></div><div dir=3D=
"auto">=3D=3D=3DSpending wallet=3D=3D=3D<br></div><div dir=3D"auto"><br></d=
iv><div dir=3D"auto">Broadcast all transactions with 1 sat/vB<br></div><div=
 dir=3D"auto"><br></div><div dir=3D"auto">=3D=3DIssues=3D=3D<br></div><div =
dir=3D"auto"><br></div><div dir=3D"auto">Few issues shared by Sergej Kotlia=
r:<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">1.Receiver can pa=
y via CPFP, but if that=E2=80=99s known about them it gets exploitable, sen=
ders will consolidate lot of UTXOs by sending one output to receiver.<br></=
div><div dir=3D"auto">2.Receivers would send their unconfirmed coins onward=
 expecting others to pay the fees until someone considers the transaction i=
mportant enough to be confirmed soon.<br></div><div dir=3D"auto"><br></div>=
<div dir=3D"auto">Bitcoin Core does not allow you to spend [unconfirmed UTX=
O using GUI][2] and most of the RPC in CLI. However Kristaps made an intere=
sting point in the linked issue that it could be allowed for transactions<b=
r></div><div dir=3D"auto"> that do not signal RBF. It is not considered saf=
e however lot of wallets allow this including Wasabi<br></div><div dir=3D"a=
uto">in which I recently found [some UI/UX issues][3] related to unconfirme=
d UTXO.<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">The part whi=
ch may require changes in protocol:<br></div><div dir=3D"auto"><br></div><d=
iv dir=3D"auto">The whole fee paid for such transactions wouldn't be paid t=
o the miner confirming the transaction but<br></div><div dir=3D"auto">it wo=
uld be shared between the miners creating next N blocks.<br></div><div dir=
=3D"auto"><br></div><div dir=3D"auto">&nbsp; [1]: https://twitter.com/Laure=
ntMT/status/1292100590462537733<br></div><div dir=3D"auto">&nbsp; [2]: http=
s://github.com/djbooth007/cpfp-calculator<br></div><div dir=3D"auto">&nbsp;=
 [3]: https://github.com/zkSNACKs/WalletWasabi/issues/7045<br></div><div di=
r=3D"auto">&nbsp; [4]: https://github.com/bitcoin-core/gui/issues/242<br></=
div><div dir=3D"auto"><br></div><div><br></div><div>-- <br></div><div>Praya=
nk<br></div><div><br></div><div dir=3D"auto">A3B1 E430 2298 178F<br></div> =
 </body>
</html>

------=_Part_185896_666031829.1642808734667--