Thanks again for the feedback. Comments inline. > On Sep 27, 2022, at 02:29, alicexbt <alice...@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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
