path: root/dc/57f3cfac4eb2e4fcbd2156a07dfa03b9a04b2c

Return-Path: <aj@erisian.com.au>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 4281DC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 13 Dec 2022 12:55:23 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 0F52C60BE4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 13 Dec 2022 12:55:23 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 0F52C60BE4
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001,
 UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 9YXx083wxN3d
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 13 Dec 2022 12:55:21 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 82D096006A
Received: from azure.erisian.com.au (azure.erisian.com.au [172.104.61.193])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 82D096006A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 13 Dec 2022 12:55:21 +0000 (UTC)
Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au)
 by azure.erisian.com.au with esmtpsa (Exim 4.92 #3 (Debian))
 id 1p54oU-0001PQ-55; Tue, 13 Dec 2022 22:55:16 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
 Tue, 13 Dec 2022 22:55:08 +1000
Date: Tue, 13 Dec 2022 22:55:08 +1000
From: Anthony Towns <aj@erisian.com.au>
To: angus <angus@toaster.cc>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <Y5h2LD/Zi3NVAhIK@erisian.com.au>
References: <mailman.48662.1670246787.956.bitcoin-dev@lists.linuxfoundation.org>
 <CAHTn92wri-edhivrtqZCoEzAPEmwZFap12mM4yzxgp77O-+JYA@mail.gmail.com>
 <CAJowKgJQJvsZQgTjEqXaz6DVw_iG4JfXCL8s0G7v2o3O453Ajg@mail.gmail.com>
 <j5xgF7aMEAtOtWJ1CfZv-gRIw-gUUe8jMvuZzY9z3K9cRNo91ApiXbtaoXdHdSx61sMmyEHPZu8BWvSSszEAmV0v-g-k2-YTNRFim3hEljw=@toaster.cc>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <j5xgF7aMEAtOtWJ1CfZv-gRIw-gUUe8jMvuZzY9z3K9cRNo91ApiXbtaoXdHdSx61sMmyEHPZu8BWvSSszEAmV0v-g-k2-YTNRFim3hEljw=@toaster.cc>
X-Spam-Score-int: -18
X-Spam-Bar: -
Cc: John Carvalho <john@synonym.to>
Subject: Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate
 danger (angus)
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Dec 2022 12:55:23 -0000

On Fri, Dec 09, 2022 at 03:58:37PM +0000, angus via bitcoin-dev wrote:
> Those in favour of Full RBF see trusting and relying on predictable
> mempool policy as a fundamentally flawed=A0bad idea.

I don't believe that claim is true, at least in general: the motivation
for the -mempoolfullrbf PR was to make mempool policy behave in a way
that was (believed to be) more reliable and predictable than the current
behaviour.

In particular, if you can't rely on predictable relay/mempool policy,
you can't build "fraud proof" protocols on top of the blockchain: whether
that be like lightning today, which relies on people being able to get a
penalty transaction mined in a reasonable amount of time, or lightning in
the future which in an eltoo world relies on getting an update transaction
mined in a similar amount of time, or optimistic rollups that offer the
ability for people to challenge with a fraud proof.

I think the basis for the fullrbf vision is more that fullrbf advocates
think miners will always want to optimise fees in the short term: that is,
given two conflicting transactions H and L, if including H in the block
gives a higher total reward for that block than including L, they will
always want to include H. Presuming that is a common attitude amongst
miners, fullrbf is a natural outcome: those miners will advertise how
to connect to their nodes, and anyone who prefers H over L will send H
to them directly, and H will be mined and L will not be.

I think it's fair to say that's what people mean when they talk about
"incentive compatible" -- miners want to see the highest fee alternative
of a transaction, and are "incentivised" by fees to do so, so relaying
that transaction is "incentive compatible" while relaying lower fee
alternatives is "incentive incompatible".

That can be a stable outcome too: if it's common to have multiple
transactions like that, then the pools that take the higher fee
transactions will give higher payouts per hashrate, and owners of mining
hardware will switch to those pools, so that the amount of hashrate
accepting replacements will tend towards 100%. That scenario is already
the case for opt-in RBF.

However, expecting pools/miners to optimise fees in the short term is an
assumption, not the economic fact of life that some seem to assume it is.

It's also possible that owners of ASICs or pool operators will decide that
they're in this for the long term, and therefore that it's smarter to look
at fee income over multiple blocks, rather than taking each block as its
own entity. Similar to treating the prisoner's dilemma as a one-off game
(where the dominant strategy is to always defect) versus an iterated game
(where cooperation or tit-for-tat may be better strategies).

In particular, the outcome of fullrbf might not simply be the rosy
scenario:

  + there are just as many txs paying similar fees as there now,
    except that
  + it's easy for people to cancel mistakes, and
  + people stop complaining to wallet authors when their opt-in=20
    rbf tx takes longer to confirm than they expected

but might instead be either:

  + everyone using BTC for payments switches to lightning, causing
  - on-chain traffic to drop and fee income to drop with it

or

  - everyone paying for goods/services online with cryptocurrency
    switches to stablecoins or ETH or Liquid or RSK,
  - bitcoin traffic and tx fees drop substantially as a result,
  - and bitcoin price drops too as people switch to hodling their
    hot wallet balances in stablecoins and ETH

which pool operators or hashrate owners might consider to not be in
their best interests.

Sergej's numbers at
https://github.com/bitcoin/bitcoin/pull/26525#issuecomment-1332823282
suggest bitefill's zeroconf txs alone account for something like 0.5%
of on-chain txs. I'm not really sure how to interpret the numbers Daniel
Lipshitz/Max Krupyshev reported; "700+ inputs a month" doesn't sound like
very many, but "300k incoming transactions" would be 35 years worth of
700 inputs per month, so something doesn't add up... The gap600 webpage
=66rom 2018 cites 3 million Bitcoin txs over about 13 months, which would
be about 230k/month, which would be roughly 3% of on-chain txs at the
moment.

It's not clear to me what that adds up to; is reducing tx volume
by perhaps 5% or 10% a big deal? Given fee income is maybe 2% of the
block reward at the best of times, reducing it by 5% (to 1.9%) probably
doesn't matter directly, but then, nor would increasing it by 5%. So
if there's a negative effect on demand for bitcoin because it becomes
slower and less widely accepted, driving its price down, though, that
probably dominates. Is that likely to be signficant? No idea. Is there
some counterveiling effect where mempoolfullrbf would make bitcoin more
desirable, increasing demand and hence increasing its price? I can't
see one.

(The original reasoning for the mempoolfullrbf option was that it
would allow new use cases, namely collaborative funding of coinjoins or
lightning channels with less risk of getting your utxo stuck without
being able to blame whoever was causing it to get stuck, which would
have added a potential for both more fees from additional txs, and more
demand due to those use cases.  Without that actually working as hoped,
we just have fewer on chain txs and worse demand in every scenario,
as far as I can see)


This isn't necessarily an incredibly stable equilibrium: once somewhere
around 10%-30% of hashrate is mining with fullrbf, presumably that
would make it too easy to cheat anyone willing to accept txs signalling
first-seen-final with 0 confirmations and they'll stop doing that, and if
the consequences are that everyone switches to lightning or stablecoins
and ETH, then that's all there is to it; it doesn't really matter what
the remaining 70%-90% of hashrate does, so at that point they might as
well do fullrbf as well, even if it only gets them a few pennies more.

But it's certainly possible for 95%+ of hashrate to decide that continuing
to ignore high fee replacements is in their best interests over the
long term -- that's how things are working currently, and how they've
worked for some years now. It's also how we'll want things to work if
we want anti-pinning schemes like those proposed for version-3 relay to
be effective.


One reason we might hope that miners will take a long-term view and
(presuming the long-term view is actually in favour of zeroconf) decide to
keep supporting zeroconf, even if we don't care about zeroconf ourselves,
is that miners prioritising long term income is arguably one of plausible
ways we can prevent 51% attacks from being a dominant strategy. If miners
are only focussing on immediate revenue, then case #4 in section 3.1 of
[0] applies, so 51% attacks are likely to be possible and profitable,
whereas if miners are focussing on bitcoin's long term value proposition,
then reorgs due to successful 51% attacks can be expected to trigger a
decline in the value of their investment in mining equipment, causing
case #4 not to apply. This is a similar argument to that presented in
section 2.3 of [1].

[0] https://www.nber.org/papers/w24717
[1] https://uncommoncore.co/wp-content/uploads/2019/10/A-model-for-Bitcoins=
-security-and-the-declining-block-subsidy-v1.02.pdf

Of course, that only needs perhaps 30%-50% of hashpower to be thinking
long term, rather than 70%-90%, and a lack of regular reorgs is probably
a clearer benefit than zeroconf transactions. Which is a bit of a win-win:
success at keeping zeroconf going should give confidence that miners will
help prevent 51% attacks; but failure at keeping zeroconf going doesn't
mean they won't be of help. And, of course it assumes that there is a
negative impact on either BTC price or block reward from killing off
zeroconf, which might not be true.

> I have sympathy for the utility argument, but to me it's completely
> overpowered by the "node policy is not consensus and not trustworthy"
> argument.

Anyway, in summary: consistent and predictable relay policy across nodes
remains important and possible whether or not that's a relay policy of
first seen is final, or highest fee rate wins, or something else.

> But for now, I want to run a Full RBF node because I see it as ultimately=
 making Bitcoin stronger. It eliminates a use-case that takes risk.

It seems strange to advocate for preventing other people from voluntarily
taking on a small risk, that's demonstrably quite easily managed, and
also already quite easily avoided.

> Bitcoin is money for enemies.

I mean, if you want to live in a world where everyone's trying to help
someone else steal your money from you, it seems like the existing
banking system already had you covered?

If everyone's actually your enemy, your payments are going to get 51%
attacked, nodes are going to blacklist your utxos, miners are going
to ignore your penalty transactions so you'll lose all your L2 funds,
on-ramps and off-ramps will run KYC and put a hold on all your withdrawals
and confiscate your deposits, and in general Bitcoin isn't going to work
for you.

The point of "money for enemies" isn't that we need to treat other
Bitcoiners as enemies and stop them from doing things we dislike; it's
that to be a Bitcoiner you only need to agree on a few things, almost
none of which are the things that usually cause people to become enemies.

An alternative aphorism might be: Bitcoin is the money of the honest
majority.

That is, it puts the power in the hands of everyone running a node,
operating a miner, or holding their own private keys, rather than in a
few regulators or people with printing presses -- trusting an eclectic
majority rather than an elite minority, perhaps on the basis that you're
more likely to have a few dishonest people getting power out of a mass
of upstanding ordinary folks, rather than the reverse.

YMMV, of course, but I know how I'd prefer to view fellow Bitcoiners,
even the ones that disagree with me. (OTOH, if you claim we're enemies,
and I claim you're honest, where's that end up?)

Cheers,
aj