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
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
|
Delivery-date: Thu, 08 May 2025 01:17:13 -0700
Received: from mail-oo1-f55.google.com ([209.85.161.55])
by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
(Exim 4.94.2)
(envelope-from <bitcoindev+bncBAABB76Q6HAAMGQEHEYVJPY@googlegroups.com>)
id 1uCwRM-0007Y1-IA
for bitcoindev@gnusha.org; Thu, 08 May 2025 01:17:13 -0700
Received: by mail-oo1-f55.google.com with SMTP id 006d021491bc7-60214b7cdbcsf680400eaf.0
for <bitcoindev@gnusha.org>; Thu, 08 May 2025 01:17:12 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1746692226; cv=pass;
d=google.com; s=arc-20240605;
b=ZBp2rw/9pwV1MSeWm3ZwNTUMrWfcoao0GiC+dZMsnum8UieJeNXX00aJZAvlB0YaTn
owcMqzjE3ncV663h7K3/wUpEnxoul2EuicNDSNk2YKVKDBJs5b1DH2Uc4M5vkxu54v1p
nFnJv9uR3HTHcRW8nMG3j9a4QWJzmqRNxsbURaHaSvWRKi4Ve3LJDClG2pTry9AhaZ4J
udb6rNVJQzHS6FjnWpSmqpvFCVXdiUTrCqbIDosEqYvYeXKXrIOnG/PU0YSFxoRt29Ba
vBLmhP2UBagKdAK/TkJKOhC5hdBNPVoIANMFlKBAHf/7FvmiBDZdyLJhhSYMJZZTrq7o
kggg==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:date:message-id:mime-version
:references:in-reply-to:subject:cc:to:from:sender:dkim-signature;
bh=7FsVN33aXNYwFRjRndyWYmPI4eCTS9SiovrV3PvbMp4=;
fh=I2E16PE5KzTG30Um20UuCGCwzHqgW3iQAY+an0YHKqc=;
b=erbfqyatt9or/8lkgr5SnJOFYiGWTxNPGuzGwcx5EA99f4lhZBlcvPJ5RLiXPhb8F4
CBLdzy/aZwAExw2aRieYMY20HPfSUEIgKHhmM1yIVNZRiVPGmaPY1y5WTVTxDu8cUyAm
IA+kvUMhH141ALsYBrwkECTuMeLUhSOesDw6LwXNEQi97Ev4DEQLttaZ3ZGHCCy4QaM0
02BzZw4LELg/lZKMo8gQyIaTmpLZDU1gzcx6vzD2ZVplYi03FwkqenKnj/K5Lk55WCSA
FIz47y2/BfaFXzYMd84jwmS0bGS/OXxkZdwXXDIrpDKbvX7YxxMhFp9XmbUKYu50RHTA
JXdg==;
darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
spf=pass (google.com: domain of pithosian@i2pmail.org designates 91.143.83.7 as permitted sender) smtp.mailfrom=pithosian@i2pmail.org
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=googlegroups.com; s=20230601; t=1746692226; x=1747297026; darn=gnusha.org;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-authentication-results
:x-original-sender:date:message-id:mime-version:references
:in-reply-to:subject:cc:to:from:sender:from:to:cc:subject:date
:message-id:reply-to;
bh=7FsVN33aXNYwFRjRndyWYmPI4eCTS9SiovrV3PvbMp4=;
b=vxULlkI3ukytUJkjY/Ufp7xNK6ymIvzlT3zeW4GXOZVrcgawlcEBazFNPBiNUkHV2R
qADvxcW173lSIk6HMUDxF+nXEGYIBKQKburZdKAXaH5RYdd8h0exhUR8G5a1QBuiVSlb
vspPly1nDow5ylVDlxua6ImUTg3wmCA9uOPm7/xRicPvji9S6viG/sew3U3yyBs5nShY
6hHkU7foNWfUL8v3YHZ92h4FXQJOaV7r0pE0tm9dz0zOFWm6/yxemVhsNSRA+VRv8K+/
czmeOHx0TDnug4zwNA5PtfGbUEIRpImjfgSwseXoXJMBgzvPyDZLSC+vBEhLRDAZSbPc
XRvw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1746692226; x=1747297026;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-authentication-results
:x-original-sender:date:message-id:mime-version:references
:in-reply-to:subject:cc:to:from:x-beenthere:x-gm-message-state
:sender:from:to:cc:subject:date:message-id:reply-to;
bh=7FsVN33aXNYwFRjRndyWYmPI4eCTS9SiovrV3PvbMp4=;
b=j1FqUUS2Y8YbeHEUAavJcqqoRP4I3EkcxA0WKZ4tYOvTBFY3XboSziUKiZnTPo54gP
vtqFFbYQzps95gdD5eM4uCE7BddD605t2n4U0KDowqU+MBoTddGcu5e7K713vWHoPJI/
BYNNa2tcmakIwpbJbiHDwTQmIp3Ix+Dpe4DAeR2WAvECzCS4lB2nZj6rVeydE1R3P9HE
W0PHglw1L0BOMdVZbCbbbajmpqA9mirXiprf3vVRPhvIo1z3QezIlSlqRThTDd5B+MB3
qRvCvNMLeL3wSyraLMbTS4b8erjSQGnz7gnD55W6toV8dyLDWbvvPuDFbSxqfeP7k2zC
+/+Q==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCXUo0dohNgDQAXXU+sW3bvvwN5Y2wTjR5c1grpjAKRn/6qL9OzHV+xW4yOR5GROqc5hiXF8GWt3B1yh@gnusha.org
X-Gm-Message-State: AOJu0YxqaVsWd0hlcppL7Ul01U1269fOsvxL5Eg3FL/pfMs36xR4D0x0
jywJL8SB+mO0RSepQwClZWz13FHL9w44g5mm6xhZKKJuTq9sp+XG
X-Google-Smtp-Source: AGHT+IE9+CGLxPS3X0Mbct6tI9sBOUswoigHbnuba/P/PD7OQ7A2BBtq4W7iBpJFNNHR1NUMFpHL3A==
X-Received: by 2002:a05:6820:3108:b0:600:5673:69ef with SMTP id 006d021491bc7-608333af26amr1732489eaf.1.1746692226421;
Thu, 08 May 2025 01:17:06 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AVT/gBHNXKAMksIEWc9kJQ77woYVa0xfWl0kWwf1TcVG5nb3kA==
Received: by 2002:a4a:db61:0:b0:602:a14b:beba with SMTP id 006d021491bc7-60832e0e9c8ls214258eaf.0.-pod-prod-00-us;
Thu, 08 May 2025 01:17:03 -0700 (PDT)
X-Received: by 2002:a05:6808:2f18:b0:3f6:a851:fe85 with SMTP id 5614622812f47-403779c8baamr1760697b6e.14.1746692223348;
Thu, 08 May 2025 01:17:03 -0700 (PDT)
Received: by 2002:a05:600c:458a:b0:43c:fd8b:faa8 with SMTP id 5b1f17b1804b1-441d45adb72ms5e9;
Wed, 7 May 2025 21:30:16 -0700 (PDT)
X-Received: by 2002:a05:600c:1e24:b0:43d:745a:5a50 with SMTP id 5b1f17b1804b1-441d44c7d80mr47980425e9.19.1746678613961;
Wed, 07 May 2025 21:30:13 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1746678613; cv=none;
d=google.com; s=arc-20240605;
b=eHMvu1q/1xRtM9rFKHimSpu/Yz51vYF1xY0QvwwSZ96K6y59tg79BiIcydoBp8Ikld
dx1CeVApQKSiR26ZIZzSxPPG0ELTjPfgyf3++QzkfojOAI0RyLC+SLfy02Ar3utYR/Fm
fvv7TLEEnWGX8KpNInezz9WI6TWPLOph8yMUJmd0doekta9oriCXtKPaoMdhqE3HA15J
8SW8XPocIIn83zhdg6MUZmQk8DkRvnHJj5v7hlstGl5Rhti3DToFYgyR/sJM7mnDtpm2
/Bivsj+/aRqtI8Yu3Eb+5x3TJnIpJuSkgcqXxnYKWl3QFS69/CHFBfOYxvp8eg0u8Fdy
wOlg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
h=date:message-id:content-transfer-encoding:mime-version:references
:in-reply-to:subject:cc:to:from;
bh=YwIF7fBRw8WtFdfFGrq3blH2eXgtd0ZvDU6kK9gDrfQ=;
fh=1eoIOSo2S/txxE0ejC06v22yyqVju0HqmQsQrJwdf+c=;
b=KpfI8IFGlG4BTNq/QTeiuU1SyP+eMGm+KQ7VHkgQ1vcJ8N0bAaTsbLCsSQQsXyAaG8
+PLgaEkFu2prgFKHeOWr7XDA3tDufF95Asw7T78VXJ2MOPjRDO83uUk6e8/b6ixsKdW6
0al75Jtw0RHl3TS0N/LVNE3FgtmjBw8uWA/Nck696THyOeJQtucghcG4dT/wqLBq3lj0
GIlA9EejQnI5FtgtvzFiCFi4UD2G/bv95axhb9qwivbmwdqo4U2ZaORCVy30eu8Em9Q1
2mQXllVIQpdni2ja+2tYtFU2MhLOqJqCrmFW4VAVgZ9IWJ5S24QlfAivr6NQj3S6pUI9
8XyQ==;
dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
spf=pass (google.com: domain of pithosian@i2pmail.org designates 91.143.83.7 as permitted sender) smtp.mailfrom=pithosian@i2pmail.org
Received: from mail.i2pproject.net (mail.i2pproject.net. [91.143.83.7])
by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-442cd3310e5si355775e9.2.2025.05.07.21.30.13
for <bitcoindev@googlegroups.com>
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Wed, 07 May 2025 21:30:13 -0700 (PDT)
Received-SPF: pass (google.com: domain of pithosian@i2pmail.org designates 91.143.83.7 as permitted sender) client-ip=91.143.83.7;
Received: from i2prouter.i2p.net ([81.7.8.99] helo=smtp.postman.i2p)
by mail.i2pproject.net with esmtp (Exim 4.96)
(envelope-from <pithosian@i2pmail.org>)
id 1uCstf-001J7s-18;
Thu, 08 May 2025 06:30:13 +0200
X-Mailer: smtp.postman.i2p - Official I2P Mailer
From: pithosian <pithosian@i2pmail.org>
To: Greg Maxwell <gmaxwell@gmail.com>
Cc: bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] Re: Relax OP_RETURN standardness restrictions
In-Reply-To: <20250507121109.6CEA77C0AAF@smtp.postman.i2p>
References: <rhfyCHr4RfaEalbfGejVdolYCVWIyf84PT2062DQbs5-eU8BPYty5sGyvI3hKeRZQtVC7rn_ugjUWFnWCymz9e9Chbn7FjWJePllFhZRKYk=@protonmail.com>
<20250502064744.92B057C0EE2@smtp.postman.i2p>
<20250507012038.3EAE07C10F1@smtp.postman.i2p>
<20250507121109.6CEA77C0AAF@smtp.postman.i2p>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
X-Virus-Scanned: clamav-milter 0.103.X on milter.postman.i2p
Message-Id: <20250507165518.0B5037C0EEB@smtp.postman.i2p>
Date: Wed, 7 May 2025 16:55:18 +0000 (UTC)
X-Spam-Score: -2.9 (--)
X-Original-Sender: pithosian@i2pmail.org
X-Original-Authentication-Results: gmr-mx.google.com; spf=pass
(google.com: domain of pithosian@i2pmail.org designates 91.143.83.7 as
permitted sender) smtp.mailfrom=pithosian@i2pmail.org
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
<https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: 0.9 (/)
On Wed, 7 May 2025 12:11:09 +0000 (UTC)
Greg Maxwell <gmaxwell@gmail.com> wrote:
> That creates a withholding attack where you announce a block then
> withhold some transactions entirely.
>
> It does already relay to other full nodes before validating
> everything, but the nodes need to have the data.
>
> Of course the recipient's mining is also still delayed until
> validation so even if not for the withholding issue it would only
> reduce the hop by hop component. (As the recipient would presumably
> not have the transaction either with its relay blocked in the network
> and the transaction submitted directly to the party that included.)
>
> There are, of course, numerous optimizations that could be done to
> reduce the impact... but none so effective as actually having the
> transaction and even having already validated it, and all with
> considerable development effort.
> That creates a withholding attack where you announce a block then
> withhold some transactions entirely.
A miner can already do this to all of their direct peers. The only
difference is whether it gets passed along. What's the functional
difference between this, and a miner delaying broadcast of a block
entirely, besides the fact withholding transactions is network-visible?
> It does already relay to other full nodes before validating
> everything, but the nodes need to have the data.
It relays once it has all of the transactions, and has done preliminary
validation up to BLOCK_VALID_TRANSACTIONS.
To finish validating the block, nodes of course will need to have all
the transactions. But relay of the compact block doesn't need to be
slowed down by nodes who don't have all transactions yet. Minimal
validation (POW, header, merkleroot) should be sufficient for relay.
> Of course the recipient's mining is also still delayed until
> validation so even if not for the withholding issue it would only
> reduce the hop by hop component.
Which is the block propagation part.
Right now, your miner won't receive the compact block until every node
along whichever path reaches them first has all the transactions
locally. Every node who was missing some of those transactions will
slow down propagation. The miner could already have all the
transactions locally, and still, they could be delayed. If they don't,
it takes longer for them to even know that they're missing transactions.
If we relay compact blocks before we have all the transactions locally,
the miner gets the compact block without any missing TX delay. If they
already have all transactions, they can finish validation and get to
work no questions asked. If they don't, the only delay in building on
the new block is because transactions were missing *from their own
mempool*.
Whether miners choose to start mining an empty block on top of this new
block, which they haven't yet fully validated, or continue with existing
work until validation completes is up to them. A decision they already
have to make.
> As the recipient would presumably not have the transaction either
> with its relay blocked in the network and the transaction submitted
> directly to the party that included.
As full-RBF demonstrated, transaction relay doesn't require every node
to have the same mempool policy. A small percentage of nodes running
permissive policy can get transactions to miners.
You don't need to try to force people to all use the same relay policy.
Never mind that it's impossible. The transaction can, and will be able
to reach miners via mempool relay by simply giving users more control
over their own node's policy, and lobbying enough of them to choose
more permissive relay policy.
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/20250507165518.0B5037C0EEB%40smtp.postman.i2p.
|
