summaryrefslogtreecommitdiff
path: root/cc/fb1cc62d61973423d9d709508f8af42f100d3b
blob: ed89c2f0368137a1a67f0481e5ec586c17baec63 (plain)
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
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 34C5BC002B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 18 Feb 2023 09:48:17 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 0372C80DAD
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 18 Feb 2023 09:48:17 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 0372C80DAD
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=pjAQ8+D0
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 xFFneTQPgIKM
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 18 Feb 2023 09:48:15 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 6DEA0812A1
Received: from smtpo90.poczta.onet.pl (smtpo90.poczta.onet.pl
 [213.180.149.143])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 6DEA0812A1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 18 Feb 2023 09:48:15 +0000 (UTC)
Received: from pmq3v.m5r2.onet (pmq3v.m5r2.onet [10.174.32.69])
 by smtp.poczta.onet.pl (Onet) with ESMTP id 4PJkPy0W0Gz2K24x5;
 Sat, 18 Feb 2023 10:48:05 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013;
 t=1676713686; bh=1W9G7gr/Xg5q3ejIwJ+WsmH4Fz207DP8EVYbdLFsf64=;
 h=From:To:In-Reply-To:Date:Subject:From;
 b=pjAQ8+D0rbfAn5hIUS7yXOvn29wyR5Cf9wi6TXd+ZQqF1kDHu/rHGf7usSPZCgGOG
 fKYnriOUApvBswfbMm759BS/V/ApY1c8kyVoclnjoFQAFN+p0B5tXU5isxgPWyGhzD
 smqZzrVfiDVUo/M7IEw2vguaxXQjSXaTZex/N/hw=
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Received: from [5.173.232.145] by pmq3v.m5r2.onet via HTTP id ;
 Sat, 18 Feb 2023 10:48:05 +0100
From: vjudeu@gazeta.pl
X-Priority: 3
To: Andrew Poelstra <apoelstra@wpsoftware.net>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <Y/AQH9s7RN14uKvE@camus>
Date: Sat, 18 Feb 2023 10:48:02 +0100
Message-Id: <177848612-ad2b15230d78bcd732bbe8621af89a1e@pmq3v.m5r2.onet>
X-Mailer: onet.poczta
X-Onet-PMQ: <vjudeu@gazeta.pl>;5.173.232.145;PL;2
X-Mailman-Approved-At: Sat, 18 Feb 2023 10:11:53 +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: Sat, 18 Feb 2023 09:48:17 -0000

> By standardness rules (where you can have up to 80-byte pushes), a little=
 over 1%. By consensus (520-byte pushes) less than 0.2%.

Note that instead of "OP_DROP OP_DROP", people can use "OP_2DROP", so the n=
umber of dropping opcodes could be halved.

> I mean, they'd provide the `FALSE` as a separate witness element rather t=
han being part of the witnessScript.

That means people can still reject an official alternative (for example com=
mitments), so a different approach is needed to fight that spam. Assuming t=
hat transactions will be sent directly to the miners, they will be included=
, that way or another. So, the solution should assume that we will have lar=
ge NOPs in the chain. And then, if we want to deal with them, some kind of =
pruning is needed. Switching from witness to non-witness node is not an opt=
ion, because it would require additional witness validation, and because ru=
les for OP_RETURN can be also lifted.

So, how to prune the Script? In a typical hash function, like SHA-256, data=
 are splitted into smaller chunks, and then processed linearly. I think it =
is possible to store the first and the last chunk, and keep the internal st=
ate of SHA-256, before entering the last chunk. In this way, it should be p=
ossible to prune those OP_NOPs. Because that solution will also cover raw s=
cripts (people can switch to them if witness will be more restricted than n=
ow).

Also, it gives us a hint, that if any Script upgrade will be considered in =
the future, we can think about doing it in a way, where unused parts can be=
 pruned, without invalidating signatures.

On 2023-02-18 00:39:16 user Andrew Poelstra <apoelstra@wpsoftware.net> wrot=
e:
> On Fri, Feb 17, 2023 at 11:35:34PM +0000, Andrew Poelstra via bitcoin-dev=
 wrote:
> =

> If you ban any of these specific script fragments then spammers will
> just use `IF <anything> ENDIF` and provide the `FALSE` as a zero push.
> And banning *this* would ban legitimate use cases.
>

I realize this is confusingly worded. I mean, they'd provide the `FALSE`
as a separate witness element rather than being part of the witnessScript.




-- =

Andrew Poelstra
Director of Research, Blockstream
Email: apoelstra at wpsoftware.net
Web:   https://www.wpsoftware.net/andrew

The sun is always shining in space
    -Justin Lewis-Webster