From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id C6F74C002F for ; 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 ; 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 ; 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 ; 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 ; 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 To: Bitcoin Dev Message-ID: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
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:
=
## 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 also be used
in projects that use market ma= king (maker-taker model).

1.Recipient cares about the urgency and the security of the payment i= n lot of transactions.
2.It might affect fee mar= ket post subsidy era and resolve issues with miners revenue, security etc.<= br>

=3D=3D=3DReceiving w= allet=3D=3D=3D

Provi= de easy options to use CPFP and pay fees that confirms the parent transacti= on.

[CPFP calculator= ][1] by djbooth07 or effective fee rate shown in explorers like https://mem= pool.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 Kotlia= r:

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

=
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
that do not signal RBF. It is not considered saf= e however lot of wallets allow this including Wasabi
in which I recently found [some UI/UX issues][3] related to unconfirme= d UTXO.

The part whi= ch may require changes in protocol:

The whole fee paid for such transactions wouldn't be paid t= o the miner confirming the transaction but
it wo= uld be shared between the miners creating next N blocks.

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


--
Praya= nk

A3B1 E430 2298 178F
= ------=_Part_185896_666031829.1642808734667--