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
|
Return-Path: <vjudeu@gazeta.pl>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 67D72C002B
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 17 Feb 2023 15:06:48 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 437D28213D
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 17 Feb 2023 15:06:48 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 437D28213D
Authentication-Results: smtp1.osuosl.org;
dkim=pass (1024-bit key) header.d=gazeta.pl header.i=@gazeta.pl
header.a=rsa-sha256 header.s=2013 header.b=EEizoLlH
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 6BIazHXRIjVD
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 17 Feb 2023 15:06:46 +0000 (UTC)
X-Greylist: delayed 00:10:03 by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 4E05482131
Received: from smtpo92.poczta.onet.pl (smtpo92.poczta.onet.pl
[213.180.149.145])
by smtp1.osuosl.org (Postfix) with ESMTPS id 4E05482131
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 17 Feb 2023 15:06:46 +0000 (UTC)
Received: from pmq7v.m5r2.onet (pmq7v.m5r2.onet [10.174.35.192])
by smtp.poczta.onet.pl (Onet) with ESMTP id 4PJFJM0p9jzlk0
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 17 Feb 2023 15:56:35 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013;
t=1676645795; bh=2dky6ZjwQRi1Mu6XZPUp4pTaa+wGo+fEHfg9yqbhB8Y=;
h=From:To:In-Reply-To:Date:Subject:From;
b=EEizoLlHqrBwNfGgvfY2v/4AGiN296Od059ukdrMD+61lqU6rpR5/v1IIgbWNG8HU
5h60Nq7x5tA8bA4idF4T5jYhx7GuS0wAiSu5TqP3YVGuxBm0UKi/ulYZPxnqhczNSI
q34EqokZgVM3siyUVU52Fu8DpYjPFgPjEaqziALg=
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Received: from [82.177.167.2] by pmq7v.m5r2.onet via HTTP id ;
Fri, 17 Feb 2023 15:56:35 +0100
From: vjudeu@gazeta.pl
X-Priority: 3
To: "alicexbt <alicexbt@protonmail.com>,
Bitcoin Protocol Discussion" <bitcoin-dev@lists.linuxfoundation.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <TG0yVn41L6VFOHFRYqd3iGz7mxHWtjFdaBrz8mlP6Uk8bmog_isDbtq_2QyvdUs9_Q-jStmx7V7l5rAesXDfHlK9Ehft7SkK5EWQ_3mg-eQ=@protonmail.com>
Date: Fri, 17 Feb 2023 15:56:31 +0100
Message-Id: <177016307-23dca06637e70217317077657442d0d8@pmq7v.m5r2.onet>
X-Mailer: onet.poczta
X-Onet-PMQ: <vjudeu@gazeta.pl>;82.177.167.2;PL;1
X-Mailman-Approved-At: Fri, 17 Feb 2023 15:09:55 +0000
Subject: Re: [bitcoin-dev] Testing censorship resistance of bitcoin p2p
network
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: Fri, 17 Feb 2023 15:06:48 -0000
> [0]: https://gist.github.com/luke-jr/4c022839584020444915c84bdd825831
I wonder how far should that rule go: SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS=
. Because "OP_FALSE OP_IF <anything> OP_ENDIF" is effectively the same as "=
OP_NOP", and putting NOPs in many places is considered non-standard. The sa=
me is true for "OP_TRUE OP_NOTIF <anything> OP_ENDIF", and also there are m=
any variants, where someone could use "OP_FALSE OP_NOT" instead of "OP_TRUE=
", or check if "2+2=3D=3D4" by using "OP_2 OP_2 OP_ADD OP_4 OP_EQUAL" (inst=
ead of putting "OP_TRUE").
There are endless combinations, and even if there will be a rule to evaluat=
e constant values on the input stack, and put OP_NOP, where any non-empty s=
et of opcodes will evaluate into nothing, then still, there are ways to inc=
lude spam on-chain. So, the question is: how strict should those rules be?
> "I disapprove of what you say, but I will defend to the death your right =
to say it."
Yes, I disapprove spamming the blockchain. But because people will rather d=
ie than stop it, creating some kind of official alternative is needed. I th=
ink most of the time it is not needed to store that data on-chain, all that=
is needed, is just proving they existed, and that they are connected to a =
certain transaction (so, it is about timestamping, not about storage).
When it comes to the solution, I think a commitment to a signature should h=
andle all cases. In this way, it can be done for any address type that can =
support OP_CHECKSIG. To validate such commitment, all that is needed, is co=
nverting R-value of a signature into the Taproot address, and then checking=
if a given commitment matches such key.
> I agree with Peter that, given that users have found ways to store arbitr=
ary amounts of data on-chain if they really want, we might as well just mak=
e OP_RETURN a free-for-all.
I think we should go in the opposite direction. Using OP_RETURN means that =
all nodes will store such data. Using witness means that only witness nodes=
will keep that. So, if it is already possible to have a node that cannot s=
ee witness data, and still remain in the network, I think commitments shoul=
d be stored only by nodes that will enable them explicitly. So, from that p=
oint of view, commitment is "a witness of a signature", it is additional in=
formation that can be skipped if needed.
On 2023-02-13 14:08:21 user alicexbt via bitcoin-dev <bitcoin-dev@lists.lin=
uxfoundation.org> wrote:
> Hi Bitcoin Developers,
There is a famous quote attributed to Evelyn Beatrice Hall in her biography=
of Voltaire: "I disapprove of what you say, but I will defend to the death=
your right to say it." I'm curious to know how many Bitcoin developers sha=
re this sentiment.
Recently there was a lot of enthusiasm on social media to run bitcoin core =
with a [patch][0] that would reject some transactions in mempool. Bitcoin K=
nots already has an option to reject transactions that reuse addresses. Wha=
t if such practices become common and some projects that provide easy to us=
e node software start censoring transactions? How would government agencies=
take advantage of this whole drama?
I understand it is difficult to censor different type of transaction becaus=
e there will be some nodes relaying them and miners including in blocks. It=
is still important to discuss this and different ways to test censorship r=
esistance.
- Peter Todd had written a [blog post][1] in which counting number of INVs =
(step 5,6,7 and 8) helps in testing if your transactions are getting relaye=
d by the connected peers. =
- I had tried broadcasting transaction to specific nodes using [libbtc][2].=
Based on my understanding it uses GETDATA to confirm your transaction was =
seen on other nodes after broadcasting.
What would an ideal tool for testing censorship resistance look like?
- Allows user to construct different types of transactions that might be co=
nsidered "bad" by some people. Example: OFAC address in output, Inscription=
, OP_RETURN, Address reuse etc.
- Option to broadcast transaction to specific nodes
- Verify if the transaction was relayed successfully or rejected
- Ban such peers using [setban][3] RPC as it would increase the probability=
of tx getting propagated to miners
There was even some discussion about an [external mempool][4] that could be=
used for non-standard transactions. It could also help in avoiding censors=
hip in some cases. I welcome your thoughts and feedback on this topic.
[0]: https://gist.github.com/luke-jr/4c022839584020444915c84bdd825831
[1]: https://petertodd.org/2022/bitcoin-core-nodes-running-fullrbf
[2]: https://twitter.com/1440000bytes/status/1574225052240777216
[3]: https://bitcoincore.org/en/doc/24.0.0/rpc/network/setban/
[4]: https://twitter.com/jamesob/status/1623827708168863747
/dev/fd0
floppy disc guy
Sent with Proton Mail secure email.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
