summaryrefslogtreecommitdiff
path: root/37/974da68c9aedb2d5aa7501b4fc3ee492d8433b
blob: 0c1dae3fd9bed3f5f712dff0ed9cf1cf3a27a4af (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
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
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 10205C0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 11 Nov 2023 10:55:11 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id CC9B082127
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 11 Nov 2023 10:55:10 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org CC9B082127
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=dLSbz/kL
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.604
X-Spam-Level: 
X-Spam-Status: No, score=0.604 tagged_above=-999 required=5
 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001,
 RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=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 wJpkDVwtuoki
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 11 Nov 2023 10:55:09 +0000 (UTC)
Received: from smtpa40.poczta.onet.pl (smtpa40.poczta.onet.pl [213.180.142.40])
 by smtp1.osuosl.org (Postfix) with ESMTPS id E80858210C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 11 Nov 2023 10:55:08 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org E80858210C
Received: from pmq6v.m5r2.onet (pmq6v.m5r2.onet [10.174.33.77])
 by smtp.poczta.onet.pl (Onet) with ESMTP id 4SSCJN0Dhhzlg8Fw;
 Sat, 11 Nov 2023 11:55:00 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013;
 t=1699700100; bh=ijCu984QePX4Fu6nQ68xTzxBAppbvqinFVRdS/gNWak=;
 h=From:To:Date:Subject:From;
 b=dLSbz/kLaBU3PqD98n/ghRg2vM9hC6SHLAGy1djC1Ml9M235omAky9GFxGj57Q/Vt
 ny2LbH/E47kOu/zCEk+HgqJ0p555JMuvWZonyI8PLXe4GQ4GgJsnAwdKvxR2wwUh8h
 EiveCtVvnJ2X73yIoyiYSL4HDo1P2u9iDCGOmmpk=
Content-Type: multipart/alternative;
 boundary="===============4439648803092852745=="
MIME-Version: 1.0
Received: from [5.173.250.33] by pmq6v.m5r2.onet via HTTP id ;
 Sat, 11 Nov 2023 11:55:00 +0100
From: vjudeu@gazeta.pl
X-Priority: 3
To: Bryan Bishop <kanzure@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Date: Sat, 11 Nov 2023 11:54:56 +0100
Message-Id: <102858647-4a24d51eb95c76b443567edd0852c411@pmq6v.m5r2.onet>
X-Mailer: onet.poczta
X-Onet-PMQ: <vjudeu@gazeta.pl>;5.173.250.33;PL;2
X-Mailman-Approved-At: Sun, 12 Nov 2023 15:08:18 +0000
Subject: Re: [bitcoin-dev] Future of the bitcoin-dev mailing list
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, 11 Nov 2023 10:55:11 -0000

This is a multi-part message in MIME format.
--===============4439648803092852745==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

What about using Signet, or some separate P2P network, to handle all of tha=
t?
=C2=A0
1. All e-mails could be sent in a pure P2P way, just each "mailing list nod=
e" would receive it, and include to its mempool.
2. The inclusion of some message would be decided by signing a block. Moder=
ators would pick the proper messages, and publish them by broadcasting a ne=
w block to all nodes.
3. Each message will be signed by some public key. It could be changed each=
 time, or even derived from some HD wallet. Only those owning "master publi=
c keys" would know, which messages were sent by the same person.
4. The time of the block could be much longer than 10 minutes. It could be =
for example one hour, one day, or even longer. Or, the commitment to all of=
 that could be just included "every sometimes" to the existing Signet chain=
, because it would take no additional on-chain bytes, and can be easily don=
e in the coinbase transaction.
5. If there will be too much spam in the mempool, then hashcash-based Proof=
 of Work can be used to filter messages. Instead of fee-based filtering, it=
 could be Proof-of-Work-based filtering. Even better: because of "master pu=
blic keys", the regular participants could be allowed anyway, without provi=
ding additional Proof of Work. Their signature would be sufficient in that =
case.
6. The code is almost there. Maybe there are even altcoins, designed specif=
ically for storing data, and we could just use them?
7. This kind of decision would push things like Silent Payments forward. Be=
cause then, you could develop scanners, to know, who wrote which message. Y=
ou could enter some "master public key", scan the whole chain, and find out=
 all messages written by that particular participant.
8. It would push commitments forward. Because then, it would be possible to=
 send some message to the "P2P mailing list network", and reveal it later. =
Of course, it is not mandatory to accept commitments at all, which means, t=
hey could be easily disabled, if they would be misused. Or we could start w=
ith no commitments, and introduce them later if needed.
9. Because Signet challenge can contain some multisig, or even some Taproot=
 address, there will be no issue with using the same password to access the=
 moderation panel. Also, in that case, it is possible to prove later, which=
 moderator accepted which message. And also, it is still possible to use so=
me shared key, if revealing that is not desirable, or even it is possible t=
o easily reach "approved by all moderators" messages, because their Schnorr=
 signatures could be combined. Also, any K-of-N multisig can be battle-test=
ed in that way.
=C2=A0
So, I can see two options: reusing some existing P2P network, or making a n=
ew one, designed specifically for handling mailing list messages in a pure =
P2P way. I guess we can try some existing chains first, and if there is no =
promising altcoin, or if we don't want to be associated with any altcoin, t=
hen our own Signet-like network could solve it.
--===============4439648803092852745==
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

<div>
<div>What about using Signet, or some separate P2P network, to handle all o=
f that?</div>
<div>&nbsp;</div>
<div>1. All e-mails could be sent in a pure P2P way, just each "mailing lis=
t node" would receive it, and include to its mempool.<br />2. The inclusion=
 of some message would be decided by signing a block. Moderators would pick=
 the proper messages, and publish them by broadcasting a new block to all n=
odes.<br />3. Each message will be signed by some public key. It could be c=
hanged each time, or even derived from some HD wallet. Only those owning "m=
aster public keys" would know, which messages were sent by the same person.=
<br />4. The time of the block could be much longer than 10 minutes. It cou=
ld be for example one hour, one day, or even longer. Or, the commitment to =
all of that could be just included "every sometimes" to the existing Signet=
 chain, because it would take no additional on-chain bytes, and can be easi=
ly done in the coinbase transaction.<br />5. If there will be too much spam=
 in the mempool, then hashcash-based Proof of Work can be used to filter me=
ssages. Instead of fee-based filtering, it could be Proof-of-Work-based fil=
tering. Even better: because of "master public keys", the regular participa=
nts could be allowed anyway, without providing additional Proof of Work. Th=
eir signature would be sufficient in that case.<br />6. The code is almost =
there. Maybe there are even altcoins, designed specifically for storing dat=
a, and we could just use them?<br />7. This kind of decision would push thi=
ngs like Silent Payments forward. Because then, you could develop scanners,=
 to know, who wrote which message. You could enter some "master public key"=
, scan the whole chain, and find out all messages written by that particula=
r participant.<br />8. It would push commitments forward. Because then, it =
would be possible to send some message to the "P2P mailing list network", a=
nd reveal it later. Of course, it is not mandatory to accept commitments at=
 all, which means, they could be easily disabled, if they would be misused.=
 Or we could start with no commitments, and introduce them later if needed.=
<br />9. Because Signet challenge can contain some multisig, or even some T=
aproot address, there will be no issue with using the same password to acce=
ss the moderation panel. Also, in that case, it is possible to prove later,=
 which moderator accepted which message. And also, it is still possible to =
use some shared key, if revealing that is not desirable, or even it is poss=
ible to easily reach "approved by all moderators" messages, because their S=
chnorr signatures could be combined. Also, any K-of-N multisig can be battl=
e-tested in that way.</div>
<div>&nbsp;</div>
<div>So, I can see two options: reusing some existing P2P network, or makin=
g a new one, designed specifically for handling mailing list messages in a =
pure P2P way. I guess we can try some existing chains first, and if there i=
s no promising altcoin, or if we don't want to be associated with any altco=
in, then our own Signet-like network could solve it.</div>
</div>

--===============4439648803092852745==--