MIME-Version: 1.0
Date: Thu, 04 Jan 2024 05:50:51 -0800
From: Brad Morrison <bradmorrison@sonic.net>
To: vjudeu@gazeta.pl, Bitcoin Protocol Discussion
 <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <102858647-4a24d51eb95c76b443567edd0852c411@pmq6v.m5r2.onet>
References: <102858647-4a24d51eb95c76b443567edd0852c411@pmq6v.m5r2.onet>
Message-ID: <5d51234c0dd9b45cb3d86b69ea92c1e8@sonic.net>
User-Agent: Roundcube Webmail/1.3.17
Content-Type: multipart/alternative;
 boundary="=_6bbca1e0788a90a369c77b66b53b9d4e"
Subject: Re: [bitcoin-dev] Future of the bitcoin-dev mailing list
Precedence: list

--=_6bbca1e0788a90a369c77b66b53b9d4e
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII

Hi all, 

It looks like there are only a few mailing lists left on
https://lists.linuxfoundation.org/mailman/listinfo and all of the
remaining ones are using Mailman version 2.1.15, which is not the
current version - https://www.gnu.org/software/mailman/   

Was there any decision made on where to move the bitcoin-dev mailing
list to? 

Thanks, 

Brad

On 2023-11-11 02:54, vjudeu via bitcoin-dev wrote:

> What about using Signet, or some separate P2P network, to handle all of that? 
> 
> 1. All e-mails could be sent in a pure P2P way, just each "mailing list node" would receive it, and include to its mempool.
> 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 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 public 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 done 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 public keys", the regular participants could be allowed anyway, without providing additional Proof of Work. Their signature would be sufficient in that case.
> 6. The code is almost there. Maybe there are even altcoins, designed specifically for storing data, and we could just use them?
> 7. This kind of decision would push things 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 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, they could be easily disabled, if they would be misused. Or we could start with 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 some shared key, if revealing that is not desirable, or even it is possible to easily reach "approved by all moderators" messages, because their Schnorr signatures could be combined. Also, any K-of-N multisig can be battle-tested in that way. 
> 
> So, I can see two options: reusing some existing P2P network, or making 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 is no promising altcoin, or if we don't want to be associated with any altcoin, then our own Signet-like network could solve it. 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--=_6bbca1e0788a90a369c77b66b53b9d4e
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=
=3DUTF-8" /></head><body style=3D'font-size: 10pt'>
<p>Hi all, </p>
<p>It looks like there are only a few mailing lists left on <a href=3D"http=
s://lists.linuxfoundation.org/mailman/listinfo">https://lists.linuxfoundati=
on.org/mailman/listinfo</a> and all of the remaining ones are using Mailman=
 version 2.1.15, which is not the current version - <a href=3D"https://www.=
gnu.org/software/mailman/">https://www.gnu.org/software/mailman/</a> &nbsp;=
</p>
<p>Was there any decision made on where to move the bitcoin-dev mailing lis=
t to?</p>
<p>Thanks,</p>
<p>Brad</p>
<div>&nbsp;</div>
<p><br /></p>
<p>On 2023-11-11 02:54, vjudeu via bitcoin-dev wrote:</p>
<blockquote type=3D"cite" style=3D"padding: 0 0.4em; border-left: #1010ff 2=
px solid; margin: 0"><!-- html ignored --><!-- head ignored --><!-- meta ig=
nored -->
<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>
<br />
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
_______________________________________________<br /> bitcoin-dev mailing l=
ist<br /> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-=
dev@lists.linuxfoundation.org</a><br /> <a href=3D"https://lists.linuxfound=
ation.org/mailman/listinfo/bitcoin-dev" target=3D"_blank" rel=3D"noopener n=
oreferrer">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</=
a></div>
</blockquote>
</body></html>

--=_6bbca1e0788a90a369c77b66b53b9d4e--