Greg Sanders [ARCHIVE] on Nostr: 📅 Original date posted:2022-11-02 📝 Original message:> I think that's a huge ...
📅 Original date posted:2022-11-02
📝 Original message:> I think that's a huge oversimplification of "rational" -- otherwise
you might as well say that deliberately pinning txs is also rational,
because it allows the person doing the pinning to steal funds from their
counterparty by forcing a timeout to expire.
To be clear, a pinner is attempting to *not* pay
the most fees, by definition. If we're somehow sure something is a pin,
we should not allow it, because miners rationally do not want it vs
an "honest" bid for fees. V3 design is one attempt to carve out a safe
space for fee bidding. Carving out a safe space for *non-bidding* is not the
same thing.
I think this mostly boils down having knobs or not. I'm fine with knobs
with paternalistic defaults, especially when a non-zero percentage of users
disagree with a value in either direction.
Greg
On Tue, Nov 1, 2022 at 11:07 PM Anthony Towns <aj at erisian.com.au> wrote:
> On Mon, Oct 31, 2022 at 12:25:46PM -0400, Greg Sanders via bitcoin-dev
> wrote:
> > For 0-conf services we have potential thieves who are willing
> > to *out-bid themselves* to have funds come back to themselves. It's not a
> > "legitimate" use-case, but a rational one.
>
> I think that's a huge oversimplification of "rational" -- otherwise
> you might as well say that deliberately pinning txs is also rational,
> because it allows the person doing the pinning to steal funds from their
> counterparty by forcing a timeout to expire.
>
> There's no need for us as developers, or us as node operators, to support
> every use case that some individual might find rational at some point in
> time. After all, it might be individually rational for someone to want the
> subsidy to stop decreasing, or to include 8MB of transactions per block.
>
> Note that it's also straightforwardly rational and incentive compatible
> for miners to not want this patch to be available, under the following
> scenario:
>
> - a significant number of on-chain txs are for zeroconf services
> - fee income would be reduced if zeroconf services went away
> (both directly due to the absence of zeroconf payments, and by
> reducing mempool pressure, reducing fee income from the on-chain txs
> that remain)
> - miners adopting fullrbf would cause zeroconf services to go away,
> (and won't enable a comparable volume of new services that generates
> comparable transaction volume)
> - including the option in core would make other miners adopting
> fullrbf more likely
>
> I think the first three of those are fairly straightforward and objective,
> at least at this point in time. The last is just a risk; but without
> any counterbalancing benefit, why take it?
>
> Gaining a few thousand sats due to high feerate replacement txs from
> people exploiting zeroconf services for a few months before all those
> services shutdown doesn't make up for the lost fee income over the months
> or years it might have otherwise taken people to naturally switch to
> some better alternative.
>
> Even if fullrbf worked for preventing pinning that likely doesn't directly
> result in much additional fee income: once you know that pinning doesn't
> work, you just don't try it, which means there's no opportunity for
> miners to profit from a bidding war from the pinners counterparties
> repeatedly RBFing their preferred tx to get it mined.
>
> That also excludes second order risks: if you can't do zeroconf with BTC
> anymore, do you switch to ERC20 tokens, and then trade your BTC savings
> for ETH or USDT, and do enough people do that to lower the price of BTC?
> If investors see BTC being less used for payments, does that lower their
> confidence in bitcoin's future, and cause them to sell?
>
> > Removing a
> > quite-likely-incentive-compatible option from the software just
> encourages
> > miners to adopt an additional patch
>
> Why shouldn't miners adopt an additional patch if they want some unusual
> functionality?
>
> Don't we want/expect miners to have the ability to change the code in
> meaningful ways, at a minimum to be able to cope with the scenario where
> core somehow gets coopted and releases bad code, or to be able to deal
> with the case where an emergency patch is needed?
>
> Is there any evidence miners even want this option? Peter suggested
> that some non-signalling replacements were being mined already [0], but
> as far as I can see [1] all of those are simply due to the transaction
> they replaced not having propagated in the first place (or having been
> evicted somehow? hard to tell without any data on the original tx).
>
> [0]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021012.html
> [1] https://github.com/bitcoin/bitcoin/pull/26287#issuecomment-1292692367
>
> > 2) Forcing miners to honor fees left on the table with respect to 0-conf,
> > or forcing them to run a custom patchset to go around it, is a step
> > backwards.
>
> As you already acknowledged, any miner that wants this behaviour can just
> pick up the patch (or could run Knots, which already has the feature
> enabled by default). It's simply false to say miners are being forced
> to do anything, no matter what we do here.
>
> If the direction you're facing is one where you're moving towards making
> life easier for people to commit fraud, and driving away businesses
> that aren't doing anyone harm, without achieving anything much else;
> then taking a step backwards seems like a sensible thing to do to me.
>
> (I remain optimistic about coming up with better RBF policy, and willing
> to be gung ho about everyone switching over to it even if it does kill
> off zeroconf, provided it actually does some good and we give people 6
> months or more notice that it's definitely happening and what exactly
> the new rules will be, though)
>
> Cheers,
> aj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221102/a1614798/attachment.html>;
📝 Original message:> I think that's a huge oversimplification of "rational" -- otherwise
you might as well say that deliberately pinning txs is also rational,
because it allows the person doing the pinning to steal funds from their
counterparty by forcing a timeout to expire.
To be clear, a pinner is attempting to *not* pay
the most fees, by definition. If we're somehow sure something is a pin,
we should not allow it, because miners rationally do not want it vs
an "honest" bid for fees. V3 design is one attempt to carve out a safe
space for fee bidding. Carving out a safe space for *non-bidding* is not the
same thing.
I think this mostly boils down having knobs or not. I'm fine with knobs
with paternalistic defaults, especially when a non-zero percentage of users
disagree with a value in either direction.
Greg
On Tue, Nov 1, 2022 at 11:07 PM Anthony Towns <aj at erisian.com.au> wrote:
> On Mon, Oct 31, 2022 at 12:25:46PM -0400, Greg Sanders via bitcoin-dev
> wrote:
> > For 0-conf services we have potential thieves who are willing
> > to *out-bid themselves* to have funds come back to themselves. It's not a
> > "legitimate" use-case, but a rational one.
>
> I think that's a huge oversimplification of "rational" -- otherwise
> you might as well say that deliberately pinning txs is also rational,
> because it allows the person doing the pinning to steal funds from their
> counterparty by forcing a timeout to expire.
>
> There's no need for us as developers, or us as node operators, to support
> every use case that some individual might find rational at some point in
> time. After all, it might be individually rational for someone to want the
> subsidy to stop decreasing, or to include 8MB of transactions per block.
>
> Note that it's also straightforwardly rational and incentive compatible
> for miners to not want this patch to be available, under the following
> scenario:
>
> - a significant number of on-chain txs are for zeroconf services
> - fee income would be reduced if zeroconf services went away
> (both directly due to the absence of zeroconf payments, and by
> reducing mempool pressure, reducing fee income from the on-chain txs
> that remain)
> - miners adopting fullrbf would cause zeroconf services to go away,
> (and won't enable a comparable volume of new services that generates
> comparable transaction volume)
> - including the option in core would make other miners adopting
> fullrbf more likely
>
> I think the first three of those are fairly straightforward and objective,
> at least at this point in time. The last is just a risk; but without
> any counterbalancing benefit, why take it?
>
> Gaining a few thousand sats due to high feerate replacement txs from
> people exploiting zeroconf services for a few months before all those
> services shutdown doesn't make up for the lost fee income over the months
> or years it might have otherwise taken people to naturally switch to
> some better alternative.
>
> Even if fullrbf worked for preventing pinning that likely doesn't directly
> result in much additional fee income: once you know that pinning doesn't
> work, you just don't try it, which means there's no opportunity for
> miners to profit from a bidding war from the pinners counterparties
> repeatedly RBFing their preferred tx to get it mined.
>
> That also excludes second order risks: if you can't do zeroconf with BTC
> anymore, do you switch to ERC20 tokens, and then trade your BTC savings
> for ETH or USDT, and do enough people do that to lower the price of BTC?
> If investors see BTC being less used for payments, does that lower their
> confidence in bitcoin's future, and cause them to sell?
>
> > Removing a
> > quite-likely-incentive-compatible option from the software just
> encourages
> > miners to adopt an additional patch
>
> Why shouldn't miners adopt an additional patch if they want some unusual
> functionality?
>
> Don't we want/expect miners to have the ability to change the code in
> meaningful ways, at a minimum to be able to cope with the scenario where
> core somehow gets coopted and releases bad code, or to be able to deal
> with the case where an emergency patch is needed?
>
> Is there any evidence miners even want this option? Peter suggested
> that some non-signalling replacements were being mined already [0], but
> as far as I can see [1] all of those are simply due to the transaction
> they replaced not having propagated in the first place (or having been
> evicted somehow? hard to tell without any data on the original tx).
>
> [0]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021012.html
> [1] https://github.com/bitcoin/bitcoin/pull/26287#issuecomment-1292692367
>
> > 2) Forcing miners to honor fees left on the table with respect to 0-conf,
> > or forcing them to run a custom patchset to go around it, is a step
> > backwards.
>
> As you already acknowledged, any miner that wants this behaviour can just
> pick up the patch (or could run Knots, which already has the feature
> enabled by default). It's simply false to say miners are being forced
> to do anything, no matter what we do here.
>
> If the direction you're facing is one where you're moving towards making
> life easier for people to commit fraud, and driving away businesses
> that aren't doing anyone harm, without achieving anything much else;
> then taking a step backwards seems like a sensible thing to do to me.
>
> (I remain optimistic about coming up with better RBF policy, and willing
> to be gung ho about everyone switching over to it even if it does kill
> off zeroconf, provided it actually does some good and we give people 6
> months or more notice that it's definitely happening and what exactly
> the new rules will be, though)
>
> Cheers,
> aj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221102/a1614798/attachment.html>;