From: Eric Voskuil <eric@voskuil•org>
To: alicexbt <alicexbt@protonmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Packaged Transaction Relay
Date: Tue, 27 Sep 2022 12:21:35 -0700 [thread overview]
Message-ID: <AA9BD913-E5BA-4D70-B3DB-9D83C1BBB62E@voskuil.org> (raw)
In-Reply-To: <A485FF21-3B14-49B4-BC53-99AFAA90E38D@voskuil.org>
Thanks again for the feedback. Comments inline.
> On Sep 27, 2022, at 02:29, alicexbt <alicexbt@protonmail•com> wrote:
>
> Hi Eric,
>
>
>> If by "range" you mean a connected tx subgraph, I don't see why not. But note that nodes only operate over signed txs. PSBT is a wallet workflow.
>
> Matt Corallo mentioned that pre-signed transactions created with low fee rate become an issue when they are broadcasted after a long time and there is a high demand for block space at that moment.
Yes, I understood this. There are many ways that a fee may be created which is too low for propagation.
> Example:
>
> Bob created PSBT1 in a multi party contract with fee rate 5 sat/vbyte however its taking hours/days to confirm the transaction with such low fee rate.
>
> Carol created PSBT1 (5 sat/vbyte), PSBT2 (10 sat/vbyte) and PSBT3 (20 sat/vbyte) for spending same inputs. She broadcasted PSBT3 which got confirmed in a few minutes.
>
>
>> Always. Only signed transactions are accepted. But assuming you are referring to a transaction that has been produced by a pre-signing workflow, I'm not sure how this would be distinct from any other tx.
>
>
> `minfeefilter` for all peers of my node was 0.00001000 at the time of writing this email. I am assuming nobody creates pre-signed transaction with fee rate below 1 sat/vbyte. How often does it happen that `minfeefilter` is above this default value?
I don’t consider node configuration relevant, regardless of its apparent consistency.
>> I'm not sure I follow this, maybe you could reword it. But it seems that you are saying that CPFP fee-bumping is a problem scenario and the complexity of the proposed solutions are not justified by such scenarios.
>
>
> Sorry that sentence was confusing. Yes complexity isn't justified for CPFP fee-bumping txs below minimum fee rate.
>
>
>> There are many node implementations used presently. And of course these are protocol proposals, which presumes more than one implementation.
>
>
> Yes, a few implementations exist (knots, libbitcoin, btcd, bcoin etc.) however they aren't used by lot of nodes. Based on this [chart][1] 98% nodes use bitcoin core. Lot of bitcoin protocol proposals are influenced by bitcoin core contributors and things could be different if even 30% nodes used other implementations.
I don’t consider such a measure relevant. This is a protocol consideration. Also consider that many nodes are not visible, and aspects of nodes, such as for p2p communication, are embedded into applications such as wallets - which could easily exceed the number of visible nodes.
>> I don't consider this relevant to any protocol considerations. Miners should always be expected to select the most optimal set of txs available in the time available to do so.
>
>
> Agree, miners should be expected to select most optimal set of txs. However, according to one [comment][2] by Pieter Wuille, miners could affect the security of some bitcoin projects with MEV.
This would be a deficiency in such projects, by assuming economic irrationality. The fact that fees will become a greater percentage of the block reward is a surprise to no one.
>> Over time we are likely to see that the only policies that remain in widespread application are those that are necessary for DOS protection (fee rate), as other restrictions are not economically rational and cannot be enforced. We've seen recent debate regarding dust policy, and op_return policy. "non-standard" txs are perfectly valid but get stuck very easily. I'll reiterate, any policy beyond what is published via the protocol will cause the above problems.
>
> I completely agree with this.
>
>
> [1]: https://luke.dashjr.org/programs/bitcoin/files/charts/software.html
> [2]: https://bitcoin.stackexchange.com/questions/107787/front-running-in-bitcoin#comment123441_107796
>
>
> /dev/fd0
next parent reply other threads:[~2022-09-27 19:21 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <A485FF21-3B14-49B4-BC53-99AFAA90E38D@voskuil.org>
2022-09-27 19:21 ` Eric Voskuil [this message]
2022-10-05 20:43 Eric Voskuil
2022-10-06 4:32 ` eric
2022-10-07 6:31 ` Anthony Towns
2022-10-08 19:58 ` eric
2022-10-09 5:52 ` Anthony Towns
2022-10-09 7:00 ` eric
2022-10-09 13:27 ` Anthony Towns
2022-10-10 22:05 ` eric
-- strict thread matches above, loose matches on Subject: below --
2022-06-08 22:43 eric
2022-09-26 17:50 ` alicexbt
2022-09-26 21:19 ` eric
2022-09-27 9:29 ` alicexbt
2022-10-04 15:15 ` Suhas Daftuar
2022-10-05 0:01 ` eric
2022-10-05 6:55 ` Anthony Towns
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=AA9BD913-E5BA-4D70-B3DB-9D83C1BBB62E@voskuil.org \
--to=eric@voskuil$(echo .)org \
--cc=alicexbt@protonmail$(echo .)com \
--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