From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 693B8D109 for ; Fri, 8 Mar 2019 20:20:53 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.bluematt.me (mail.bluematt.me [192.241.179.72]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 33C0012E for ; Fri, 8 Mar 2019 20:20:52 +0000 (UTC) Received: from [192.168.0.100] (unknown [69.202.205.58]) by mail.bluematt.me (Postfix) with ESMTPSA id D841812035A; Fri, 8 Mar 2019 20:20:50 +0000 (UTC) From: Matt Corallo Content-Type: multipart/alternative; boundary=Apple-Mail-15E73318-EBB0-40A3-9C40-6545A13BA653 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Date: Fri, 8 Mar 2019 15:20:49 -0500 Message-Id: <939C132D-8599-4258-8F14-62E992BA9F51@mattcorallo.com> References: In-Reply-To: To: Karl-Johan Alm , Bitcoin Protocol Discussion X-Mailer: iPhone Mail (16D57) X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE, MIME_QP_LONG_LINE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Sat, 09 Mar 2019 18:28:16 +0000 Subject: Re: [bitcoin-dev] Signet X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 20:20:53 -0000 --Apple-Mail-15E73318-EBB0-40A3-9C40-6545A13BA653 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable To make testing easier, it may make sense to keep the existing block header f= ormat (and PoW) and instead apply the signature rules to some field in the c= oinbase transaction. This means SPV clients (assuming they only connect to h= onest/trusted nodes) work as-is. A previous idea regarding reorgs (that I believe Greg came up with) is to al= low multiple keys to sign blocks, with one signing no reorgs and one signing= a reorg every few blocks, allowing users to choose the behavior they want. > On Mar 8, 2019, at 00:54, Karl-Johan Alm via bitcoin-dev wrote: >=20 > Hello, >=20 > As some of you already know, I've been working on a network called "signet= ", which is bascially a complement to the already existing testnet, except i= t is completely centralized, and blocks are signed by a specific key rather t= han using proof of work. >=20 > Benefits of this: >=20 > 1. It is more predictable than testnet. Miners appear and disappear regula= rly, causing irregular block generation. >=20 > 2. Since it is centrally controlled, it is easy to perform global testing,= such as reorgs (e.g. the network performs a 4 block reorg by request, or as= scheduled). >=20 > 3. It is more stable than testnet, which occasionally sees several thousan= d block reorgs. >=20 > 4. It is trivial to spin up (and shut down) new signets to make public tes= ts where anyone can participate. >=20 > Anyone can create a signet at any time, simply by creating a key pair and c= reating a challenge (scriptPubKey). The network can then be used globally by= anyone, assuming the creator sends some coins to the other participants. >=20 > Having a persistent signet would be beneficial in particular to services w= hich need a stable place to test features over an extended period of time. M= y own company implements protocols on top of Bitcoin with sidechains. We nee= d multi-node test frameworks to behave in a predictable manner (unlike testn= et) and with the same standardness relay policy as mainnet. >=20 > Signets consist of 2 parameters: the challenge script (scriptPubKey) and t= he solution length. (The latter is needed to retain fixed length block heade= rs, despite having an additional payload.) >=20 > I propose that a default persistent "signet1" is created, which can be rep= laced in future versions e.g. if the coins are unwisely used as real money, s= imilarly to what happened to previous testnets. This signet is picked by def= ault if a user includes -signet without providing any of the parameters ment= ioned above. The key holder would be someone sufficiently trusted in the com= munity, who would be willing to run the system (block generation code, fauce= t, etc). It could be made a little more sturdy by using 1-of-N multisig as t= he challenge, in case 1 <=3D x < N of the signers disappear. If people oppos= e this, it can be skipped, but will mean people can't just jump onto signet w= ithout first tracking down parameters from somewhere. >=20 > Implementation-wise, the code adds an std::map with block hash to block si= gnature. This is serialized/deserialized as appropriate (Segwit witness styl= e), which means block headers in p2p messages are (80 + solution_length) byt= es. Block header non-contextual check goes from checking if block header has= h < target to checking if the payload is a valid signature for the block hea= der hash instead. >=20 > Single commit with code (will split into commits and make PR later, but ju= st to give an idea what it looks like): https://github.com/kallewoof/bitcoin= /pull/4 >=20 > I don't think this PR is overly intrusive, and I'm hoping to be able to ge= t signet code into Bitcoin Core eventually, and am equally hopeful that devs= of other (wallet etc) implementations will consider supporting it. >=20 > Feedback requested on this. >=20 > Attribution: parts of the signet code (in particular signblock and getnewb= lockhex) were adapted from the ElementsProject/elements repository. When PR i= s split into atomic commits, I will put appropriate attribution there. >=20 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --Apple-Mail-15E73318-EBB0-40A3-9C40-6545A13BA653 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
To m= ake testing easier, it may make sense to keep the existing block header form= at (and PoW) and instead apply the signature rules to some field in the coin= base transaction. This means SPV clients (assuming they only connect to hone= st/trusted nodes) work as-is.

A previous idea regarding reorgs (that I believe Greg came up with) is to= allow multiple keys to sign blocks, with one signing no reorgs and one sign= ing a reorg every few blocks, allowing users to choose the behavior they wan= t.


On Mar 8, 2019, at 00:54, Karl-Johan Alm via bitcoin-dev <bitcoin-dev@lists.linuxfoundati= on.org> wrote:

Hello,

As some of you already know, I've been working on a network called "signe= t", which is bascially a complement to the already existing testnet, except i= t is completely centralized, and blocks are signed by a specific key rather t= han using proof of work.

Benefits of this:

1. It is more predictable than testnet. Miners appear and d= isappear regularly, causing irregular block generation.

=
2. Since it is centrally controlled, it is easy to perform global testi= ng, such as reorgs (e.g. the network performs a 4 block reorg by request, or= as scheduled).

3. It is more stable than testnet, w= hich occasionally sees several thousand block reorgs.

4. It is trivial to spin up (and shut down) new signets to make public te= sts where anyone can participate.

Anyone can create= a signet at any time, simply by creating a key pair and creating a challeng= e (scriptPubKey). The network can then be used globally by anyone, assuming t= he creator sends some coins to the other participants.

<= div>Having a persistent signet would be beneficial in particular to services= which need a stable place to test features over an extended period of t= ime. My own company implements protocols on top of Bitcoin with sidechains. W= e need multi-node test frameworks to behave in a predictable manner (unlike t= estnet) and with the same standardness relay policy as mainnet.

Signets consist of 2 parameters: the challenge script (scri= ptPubKey) and the solution length. (The latter is needed to retain fixed len= gth block headers, despite having an additional payload.)

I propose that a default persistent "signet1" is created, which can b= e replaced in future versions e.g. if the coins are unwisely used as real mo= ney, similarly to what happened to previous testnets. This signet is picked b= y default if a user includes -signet without providing any of the parameters= mentioned above. The key holder would be someone sufficiently trusted in th= e community, who would be willing to run the system (block generation code, f= aucet, etc). It could be made a little more sturdy by using 1-of-N multisig a= s the challenge, in case 1 <=3D x < N of the signers disappear. If peo= ple oppose this, it can be skipped, but will mean people can't just jump ont= o signet without first tracking down parameters from somewhere.
Implementation-wise, the code adds an std::map with block hash t= o block signature. This is serialized/deserialized as appropriate (Segwit wi= tness style), which means block headers in p2p messages are (80 + solut= ion_length) bytes. Block header non-contextual check goes from checking if b= lock header hash < target to checking if the payload is a valid signature= for the block header hash instead.

Single commit w= ith code (will split into commits and make PR later, but just to give an ide= a what it looks like): https://github.com/kallewoof/bitcoin/pull/4

I don't think this PR is overly intrusive, and I'm ho= ping to be able to get signet code into Bitcoin Core eventually, and am equa= lly hopeful that devs of other (wallet etc) implementations will consider su= pporting it.

Feedback requested on this.
=
Attribution: parts of the signet code (in particular signbloc= k and getnewblockhex) were adapted from the ElementsProject/elements reposit= ory. When PR is split into atomic commits, I will put appropriate attributio= n there.

________= _______________________________________
bitcoin-dev mailing l= ist
bitcoin-dev@lists.linuxfoundation.org
https://lists.linu= xfoundation.org/mailman/listinfo/bitcoin-dev
= --Apple-Mail-15E73318-EBB0-40A3-9C40-6545A13BA653--