Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id D3DC2C0037 for ; Thu, 4 Jan 2024 13:51:03 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 9B61C61189 for ; Thu, 4 Jan 2024 13:51:03 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 9B61C61189 Authentication-Results: smtp3.osuosl.org; dkim=pass (2048-bit key) header.d=sonic.net header.i=@sonic.net header.a=rsa-sha256 header.s=net23 header.b=lKwzAHrH X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4FA4CwpmA1x6 for ; Thu, 4 Jan 2024 13:51:02 +0000 (UTC) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) by smtp3.osuosl.org (Postfix) with ESMTPS id 5755E61188 for ; Thu, 4 Jan 2024 13:51:02 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 5755E61188 Received: from webmail.sonic.net (b.webmail.sonic.net [184.23.169.32]) (authenticated bits=0) by d.mail.sonic.net (8.16.1/8.16.1) with ESMTPA id 404Dopj7029866; Thu, 4 Jan 2024 05:50:51 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sonic.net; s=net23; t=1704376253; bh=PK6emy2+UNRVlzCxi/O3Wk4UK8z7DfaSn8miqq2v984=; h=MIME-Version:Date:From:To:Subject:Message-ID:From:Subject; b=lKwzAHrHY7kYUaPVXunMkM6qnyVOY0HPPYRiqHeARTwalkBaeDPF3ixHawkD0sKtv ERWbRdtu3EIc7bOSRlSZODpgpo10dhPeiQkdED4XlfpplcngUpAuBzXxD4Gko3jng9 YIcRuRnRUQdfyIJENE0TZoivEtyAQ3TeByKfmgrwQFW7aYxuLKHzkkhrvnCZ/YJjuz ye9qYEZtKMYQgJyK+baGNLgzWi+OuKwQtcTb9UyLrpXrvSfAUBvA3VwCMJ7W4OiwW+ kXJeA79etAvB+eUIaKPUZHFH8Jdf9tXRwfht9yEq1PVJrsWaHKOZ7Jpe5YGlUgDukv otexSQ5v85dbw== MIME-Version: 1.0 Date: Thu, 04 Jan 2024 05:50:51 -0800 From: Brad Morrison To: vjudeu@gazeta.pl, Bitcoin Protocol Discussion 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 X-Sonic-Auth: 0aBLX/MMhWy6yoKFeEuhIk9dZ0FGMPjDg3aG90hkzzGK3OsLaKaRf7bdUc4DCwOgNJQjJT1nP+dBlLJoJfyxFoVtwPL7Cvo608MoyBw4J28= Content-Type: multipart/alternative; boundary="=_6bbca1e0788a90a369c77b66b53b9d4e" X-Sonic-CAuth: UmFuZG9tSVaA466FK9WHgi7r8R4hRm9z6KODvohuV+CficI56aQvLq10bivP561ezHf8uUGFRZ2QPh6Sye5I+ofmkxrNKj4Sf8DySWlkpcQ= X-Sonic-ID: C;lkr+RQir7hGQI0ZFP63e0g== M;DkkKRgir7hGQI0ZFP63e0g== X-Sonic-Spam-Details: 0.1/5.0 by cerberusd X-Mailman-Approved-At: Fri, 05 Jan 2024 20:45:19 +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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2024 13:51:03 -0000 --=_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

Hi all,

It looks like there are only a few mailing lists left on https://lists.linuxfoundati= on.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 lis= t 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 o= f that?
 
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.
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.
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.=
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.
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.
6. The code is almost = there. Maybe there are even altcoins, designed specifically for storing dat= a, and we could just use them?
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.
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.=
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.
 
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.

= _______________________________________________
bitcoin-dev mailing l= ist
bitcoin-= dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--=_6bbca1e0788a90a369c77b66b53b9d4e--