path: root/f8/1ff4ec1c4c1e574972153427365a85e63f1da7

Return-Path: <aj@erisian.com.au>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id E7DF0C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 27 Oct 2022 15:37:38 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id B5EB160DB7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 27 Oct 2022 15:37:38 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org B5EB160DB7
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 LQlb32BLUIHL
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 27 Oct 2022 15:37:37 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 89802606BF
Received: from azure.erisian.com.au (azure.erisian.com.au [172.104.61.193])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 89802606BF
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 27 Oct 2022 15:37:37 +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 1oo4wk-00039c-OW; Fri, 28 Oct 2022 01:37:35 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
 Fri, 28 Oct 2022 01:37:27 +1000
Date: Fri, 28 Oct 2022 01:37:27 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Gloria Zhao <gloriajzhao@gmail.com>
Message-ID: <Y1qlt6uX5Iccuxkc@erisian.com.au>
References: <Y1nIKjQC3DkiSGyw@erisian.com.au>
 <CAFXO6=+Bjr_nuy+24VZR-zE3=Heii_NJxWPdiJTJW6ZgWbZ8rA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAFXO6=+Bjr_nuy+24VZR-zE3=Heii_NJxWPdiJTJW6ZgWbZ8rA@mail.gmail.com>
X-Spam-Score-int: -18
X-Spam-Bar: -
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] On mempool policy consistency
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: Thu, 27 Oct 2022 15:37:39 -0000

On Thu, Oct 27, 2022 at 01:36:47PM +0100, Gloria Zhao wrote:
> > The cutoff for that is probably something like "do 30% of listening
> > nodes have a compatible policy"? If they do, then you'll have about a
> > 95% chance of having at least one of your outbound peers accept your tx,
> > just by random chance.
> Yes, in most cases, whether Bitcoin Core is restricting or loosening
> policy, the user in question is fine as long as they have a path from their
> node to a miner that will accept it. This is the case for something like
> -datacarriersize if the use case is putting stuff into OP_RETURN outputs,
> or if they're LN and using CPFP carveout, v3, package relay, etc.

> But
> replacement is not only a question of "will my transaction propagate" but
> also, "will someone else's transaction propagate, invalidating mine" or, in
> other words, "can I prevent someone else's transaction from propagating."

"Can I prevent someone else's transaction from propagating" is almost
the entirety of the question with -datacarrier, -datacarriersize and
-permitbaremultisig though: "we" don't want people to spam the utxo
set or the blockchain with lots of data (cf BSV's gigabytes worth of
dog pictures [0]), so for the people who are going to find some way
of putting data in we'd like to encourage them to make it small, and
do it in a way that's prunable and doesn't bloat the utxo set, whose
size matters even more than the overall blockchain's size does. As I
understand it, people were doing that by creating bare multisig utxos,
ie a bare (non-p2sh) scriptPubKey that perhaps looks like:

  1 my_key data1 data2 data3 data4 data5 5 CHECKMULTISIG

which is "bad" in two ways: you're only committing to the data, so why
not save 128 bytes by doing hash(data1 data2 data3 data4 data5) instead;
and even more so, that data is only interesting to you, not everyone else,
so why not do it in a way that doesn't bloat the utxo set, which we want
to keep small so that it's easier to efficiently look up potential spends.

Hence the -datacarriersize limitation that limits you to about 2.5
"dataN" entries per tx ("we'll prevent your tx from propagating if you
do much more than publish a hash") and hence at least the potential for
doing the same for baremultisig in general.

[0] https://twitter.com/bsvdata/status/1427866510035324936

> A
> zeroconf user relies on there *not* being a path from someone else's full
> RBF node to a full RBF miner. This is why I think RBF is so controversial
> in general,

Yes; but I think it's also true to say that this is why *zeroconf* is as
controversial as it is.

Likewise OP_RETURN has had its own "controversies" to some extent, too:

  https://blog.bitmex.com/dapps-or-only-bitcoin-transactions-the-2014-debate/
  https://github.com/bitcoin/bitcoin/pull/3715
  https://github.com/bitcoin/bitcoin/pull/3939

> why -mempoolfullrbf on someone else's node is considered more
> significant than another policy option, and why full RBF shouldn't be
> compared with something like datacarriersize.

It's definitely a different scenario: unexpected RBF can cause you to
have less money than you expected; whereas more OP_RETURN data just
bloats the blockchain, and losing money that you thought was yours is
definitely more painful than more spam.

But while the level of pain is different; I don't think the mechanism is:
whether you're trying to preserve zeroconf or prevent utxo set spam,
you're still relying on a vast majority of nodes working together to
prevent even a small minority of hashpower from doing "bad" things, with
no cryptographic assurances that will continue to work well or at all.

> I don't think past patterns can be easily applied here,

I mean, technically they trivially could? We *could* roll out support for
full RBF in exactly the same way we rolled out support for opt-in RBF:
making it the default for all nodes, but supplying an option that node
operators can use to disable the feature for seven releases / ~4 years:

https://bitcoin.org/en/release/v0.12.0#opt-in-replace-by-fee-transactions
https://bitcoin.org/en/release/v0.19.0.1#deprecated-or-removed-configuration-options

If we don't want to do that immediately, but also want to make a definite
move forward, then we could:

 * just say that, and then keep our word about it
 * keep the feature in master, but remove it in 24.x
 * put a time delay on the feature so that it doesn't happen immediately
   but is locked in in the code for whenever we are ready to do it

> and I don't think this necessarily shows a
> different "direction" in thinking about mempool policy in general.

If we're not applying past patterns, then this is a different direction
in how we're thinking about things than what we did in the past.

That's not necessarily a bad thing -- maybe we should be thinking
differently; but I don't see how you can honestly dispute it: those are
just two ways of saying the exact same thing.

Cheers,
aj