Re: [bitcoin-dev] Future of the bitcoin-dev mailing list

From: Brad Morrison <bradmorrison@sonic•net>
To: vjudeu@gazeta•pl,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Future of the bitcoin-dev mailing list
Date: Thu, 04 Jan 2024 05:50:51 -0800	[thread overview]
Message-ID: <5d51234c0dd9b45cb3d86b69ea92c1e8@sonic.net> (raw)
In-Reply-To: <102858647-4a24d51eb95c76b443567edd0852c411@pmq6v.m5r2.onet>

[-- Attachment #1: Type: text/plain, Size: 3572 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 4448 bytes --]