path: root/53/70ebdcfb8806b7665fe9edbeb2456586676c94

Return-Path: <lf-lists@mattcorallo.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 693B8D109
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	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 <lf-lists@mattcorallo.com>
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: <CALJw2w5OiKHk1oj1p=rmQ-jvYOdieOD=xHcPt9D0A_-nLKvv7Q@mail.gmail.com>
In-Reply-To: <CALJw2w5OiKHk1oj1p=rmQ-jvYOdieOD=xHcPt9D0A_-nLKvv7Q@mail.gmail.com>
To: Karl-Johan Alm <karljohan-alm@garage.co.jp>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <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: 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 <bitcoin-dev@list=
s.linuxfoundation.org> 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

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div dir=3D"ltr"></div><div dir=3D"ltr">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.</div><div dir=3D"ltr"><br></div><div dir=3D"lt=
r">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.</div><div dir=3D"ltr"><br></div><div dir=3D"ltr"><br></div><div dir=3D"lt=
r">On Mar 8, 2019, at 00:54, Karl-Johan Alm via bitcoin-dev &lt;<a href=3D"m=
ailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundati=
on.org</a>&gt; wrote:<br><br></div><blockquote type=3D"cite"><div dir=3D"ltr=
"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr">Hello,<div><br></div><d=
iv>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.</div><div><br></div><div>Benefits of this:</div><di=
v><br></div><div>1. It is more predictable than testnet. Miners appear and d=
isappear regularly, causing irregular block generation.</div><div><br></div>=
<div>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).</div><div><br></div><div>3. It is more stable than testnet, w=
hich occasionally sees several thousand block reorgs.</div><div><br></div><d=
iv>4. It is trivial to spin up (and shut down) new signets to make public te=
sts where anyone can participate.</div><div><br></div><div>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><div><br></div><=
div>Having a persistent signet would be beneficial in particular to services=
 which need a stable place to test features over an extended&nbsp;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.<br></div><di=
v><br></div><div>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.)</div><div><br></di=
v><div>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 &lt;=3D x &lt; 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.</div><div><b=
r></div><div>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&nbsp;+ solut=
ion_length) bytes. Block header non-contextual check goes from checking if b=
lock header hash &lt; target to checking if the payload is a valid signature=
 for the block header hash instead.</div><div><br></div><div>Single commit w=
ith code (will split into commits and make PR later, but just to give an ide=
a what it looks like):&nbsp;<a href=3D"https://github.com/kallewoof/bitcoin/=
pull/4" target=3D"_blank">https://github.com/kallewoof/bitcoin/pull/4</a></d=
iv><div><br></div><div>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.</div><div><br></div><div>Feedback requested on this.</div><div>=
<br></div><div>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.</div><div><br></div></div></div></div>
</div></blockquote><blockquote type=3D"cite"><div dir=3D"ltr"><span>________=
_______________________________________</span><br><span>bitcoin-dev mailing l=
ist</span><br><span><a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org"=
>bitcoin-dev@lists.linuxfoundation.org</a></span><br><span><a href=3D"https:=
//lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linu=
xfoundation.org/mailman/listinfo/bitcoin-dev</a></span><br></div></blockquot=
e></body></html>=

--Apple-Mail-15E73318-EBB0-40A3-9C40-6545A13BA653--