1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
|
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
|
