From: Prayank <prayank@tutanota•de>
To: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] Bob-Pays-For-Transaction
Date: Sat, 22 Jan 2022 00:45:34 +0100 (CET) [thread overview]
Message-ID: <Mtz0y_---3-2@tutanota.de> (raw)
[-- Attachment #1: Type: text/plain, Size: 2325 bytes --]
I have rephrased things discussed in a [tweet thread][1] in 2020, added a few 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 senders or most of the wallets followed this:
## Bob-Pays-For-Transaction
==Motivation==
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 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 miners revenue, security etc.
===Receiving wallet===
Provide easy options to use CPFP and pay fees that confirms the parent transaction.
[CPFP calculator][1] by djbooth07 or effective fee rate shown in explorers like https://mempool.space can be helpful.
===Spending wallet===
Broadcast all transactions with 1 sat/vB
==Issues==
Few issues shared by Sergej Kotliar:
1.Receiver can pay via CPFP, but if that’s known about them it gets exploitable, senders 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 important enough to be confirmed soon.
Bitcoin Core does not allow you to spend [unconfirmed UTXO using GUI][2] and 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 allow this including Wasabi
in which I recently found [some UI/UX issues][3] related to unconfirmed UTXO.
The part which may require changes in protocol:
The whole fee paid for such transactions wouldn't be paid to the miner confirming the transaction but
it would be shared between the miners creating next N blocks.
[1]: https://twitter.com/LaurentMT/status/1292100590462537733
[2]: https://github.com/djbooth007/cpfp-calculator
[3]: https://github.com/zkSNACKs/WalletWasabi/issues/7045
[4]: https://github.com/bitcoin-core/gui/issues/242
--
Prayank
A3B1 E430 2298 178F
[-- Attachment #2: Type: text/html, Size: 3594 bytes --]
reply other threads:[~2022-01-21 23:45 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=Mtz0y_---3-2@tutanota.de \
--to=prayank@tutanota$(echo .)de \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/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