path: root/eb/bd3911edb9dff3b3ce2fbecb8a4431350b352e

Return-Path: <karljohan-alm@garage.co.jp>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id D6CA4C9D6
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  8 Mar 2019 06:00:34 +0000 (UTC)
X-Greylist: delayed 00:05:32 by SQLgrey-1.7.6
Received: from mo.garage.hdemail.jp (mo.garage.hdemail.jp [46.51.242.127])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C256812E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  8 Mar 2019 06:00:33 +0000 (UTC)
Received: from ip-10-217-1-36.ap-northeast-1.compute.internal
	(localhost.localdomain [127.0.0.1])
	by mo.garage.hdemail.jp (hde-mf-postfix) with SMTP id 2632714C0F6
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  8 Mar 2019 14:55:00 +0900 (JST)
	(envelope-from karljohan-alm@garage.co.jp)
X-Received: from unknown (HELO mo.garage.hdemail.jp) (127.0.0.1)
	by 0 with SMTP; 8 Mar 2019 14:55:00 +0900
X-Received: from mo.garage.hdemail.jp (localhost.localdomain [127.0.0.1])
	by mo.garage.hdemail.jp (hde-ma-postfix) with ESMTP id DC7FC4C08D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  8 Mar 2019 14:54:59 +0900 (JST)
	(envelope-from karljohan-alm@garage.co.jp)
Received: from gw24.oz.hdemail.jp
	(ip-10-169-158-233.ap-northeast-1.compute.internal [10.169.158.233])
	by mo.garage.hdemail.jp (hde-mf-postfix) with ESMTP id 8BFB914C0EC
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  8 Mar 2019 14:54:59 +0900 (JST)
	(envelope-from karljohan-alm@garage.co.jp)
X-Received: from mail-qt1-f197.google.com (lb07.oz.hdemail.jp [54.238.57.67])
	(using TLSv1 with cipher AES128-SHA (128/128 bits))
	(No client certificate requested)
	by gw24.oz.hdemail.jp (Postfix) with ESMTP id 2E9CC148C0FE
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  8 Mar 2019 14:54:59 +0900 (JST)
X-Received: by mail-qt1-f197.google.com with SMTP id g42so1637192qtb.20
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 07 Mar 2019 21:54:59 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
	bh=GSCNBzK4t09k2ijWunkj54yI1YRM6CKQJdsYY3R9/Zc=;
	b=FR9UWLwGlStyL2yRFU2iDEaTxGhjlncp2cK2azB3ipgGmbTmmIIYqgh0CZjmVr0i1T
	mE4G6ZsbnClvskMQZStFZQOc0Sb1t1xS6ZTXuudlVH1RW0GWjvzWd96KW/tlTSdzHq2F
	BxeMTwXyWXCp1TejRgLu4bCsPi0LqU1P+0L0gn/vre7HmXHBLF1KpGzKch4DlS1v2nwV
	7hqf2vlGV15M7FYveImVCwcqWRSkYEKOLqK8MOsvduF7s+JjtsLp1YzNddgGZOuSGibT
	hZIQAZR8Crxu9AF6z7nD0rYv+3JBUVlV+R85aQ7OKmU0jQxAF2DfBzaoTuOA18SwXcRp
	L9kA==
X-Gm-Message-State: APjAAAWpGG+oUCnZJzBnyJgtaj6L2TQ24Aps1vfA9avhYxlhAHyNMxG8
	pl4HlKp2ZGsxuVTRQH5DERGuN6WJtNqL5yVeMZj6rOHsvUfnFhQ2879oGxj5rXwrRwpTP8RcGqT
	5MQwK+XoxFHljDpscjcxO8to9jkk9DRAFeDIuMFsmhw1HEbqs88xEiKR53OzpjzFIkvvUajYxX8
	ZP1s+GJTl1tIFwFhyxH/UbAfJ3bYKzWXKgtyTkvHwrQEPU2EmbKNzNJ2OcsHKPY+nOmaGgXrBBH
	Mvj1KtKTeGEFOo7AC1QJdtPtJUmFuthzUEwnnvCwzmxQIxokiK8SgjX3z8A+FywtyGjROJG4GwY
	rlRcsM5kr4WJyLJRCwmxmK+L1Uk=
X-Received: by 2002:a0c:be13:: with SMTP id k19mr13635183qvg.68.1552024497722; 
	Thu, 07 Mar 2019 21:54:57 -0800 (PST)
X-Google-Smtp-Source: APXvYqwmnd5b0OLuRs3fVVodKpgnxqQOyE3XURg9fyeTaRTy1nlTuSF8IgWAgzh3UdNXcpAUW3sDNtKKjshJH/+3wCY=
X-Received: by 2002:a0c:be13:: with SMTP id k19mr13635171qvg.68.1552024497425; 
	Thu, 07 Mar 2019 21:54:57 -0800 (PST)
MIME-Version: 1.0
From: Karl-Johan Alm <karljohan-alm@garage.co.jp>
Date: Fri, 8 Mar 2019 14:54:46 +0900
Message-ID: <CALJw2w5OiKHk1oj1p=rmQ-jvYOdieOD=xHcPt9D0A_-nLKvv7Q@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000da23e205838edc6f"
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE 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: Fri, 08 Mar 2019 18:59:16 +0000
Subject: [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 06:00:34 -0000

--000000000000da23e205838edc6f
Content-Type: text/plain; charset="UTF-8"

Hello,

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 it is completely centralized, and blocks are signed by a specific
key rather than using proof of work.

Benefits of this:

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

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).

3. It is more stable than testnet, which occasionally sees several thousand
block reorgs.

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

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

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

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

I propose that a default persistent "signet1" is created, which can be
replaced in future versions e.g. if the coins are unwisely used as real
money, similarly to what happened to previous testnets. This signet is
picked by default if a user includes -signet without providing any of the
parameters mentioned above. The key holder would be someone sufficiently
trusted in the community, who would be willing to run the system (block
generation code, faucet, etc). It could be made a little more sturdy by
using 1-of-N multisig as the challenge, in case 1 <= x < N of the signers
disappear. If people oppose this, it can be skipped, but will mean people
can't just jump onto signet without first tracking down parameters from
somewhere.

Implementation-wise, the code adds an std::map with block hash to block
signature. This is serialized/deserialized as appropriate (Segwit witness
style), which means block headers in p2p messages are (80 +
solution_length) bytes. Block header non-contextual check goes from
checking if block header hash < target to checking if the payload is a
valid signature for the block header hash instead.

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

I don't think this PR is overly intrusive, and I'm hoping to be able to get
signet code into Bitcoin Core eventually, and am equally hopeful that devs
of other (wallet etc) implementations will consider supporting it.

Feedback requested on this.

Attribution: parts of the signet code (in particular signblock and
getnewblockhex) were adapted from the ElementsProject/elements repository.
When PR is split into atomic commits, I will put appropriate attribution
there.

--000000000000da23e205838edc6f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr">Hello,<div><br></div><di=
v>As some of you already know, I&#39;ve been working on a network called &q=
uot;signet&quot;, which is bascially a complement to the already existing t=
estnet, except it is completely centralized, and blocks are signed by a spe=
cific key rather than using proof of work.</div><div><br></div><div>Benefit=
s of this:</div><div><br></div><div>1. It is more predictable than testnet.=
 Miners appear and disappear regularly, causing irregular block generation.=
</div><div><br></div><div>2. Since it is centrally controlled, it is easy t=
o perform global testing, such as reorgs (e.g. the network performs a 4 blo=
ck reorg by request, or as scheduled).</div><div><br></div><div>3. It is mo=
re stable than testnet, which occasionally sees several thousand block reor=
gs.</div><div><br></div><div>4. It is trivial to spin up (and shut down) ne=
w signets to make public tests 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 challenge (scriptPubKey). The network can then be used=
 globally by anyone, assuming the creator sends some coins to the other par=
ticipants.</div><div><br></div><div>Having a persistent signet would be ben=
eficial in particular to services which need a stable place to test feature=
s over an extended=C2=A0period of time. My own company implements protocols=
 on top of Bitcoin with sidechains. We need multi-node test frameworks to b=
ehave in a predictable manner (unlike testnet) and with the same standardne=
ss relay policy as mainnet.<br></div><div><br></div><div>Signets consist of=
 2 parameters: the challenge script (scriptPubKey) and the solution length.=
 (The latter is needed to retain fixed length block headers, despite having=
 an additional payload.)</div><div><br></div><div>I propose that a default =
persistent &quot;signet1&quot; is created, which can be replaced in future =
versions e.g. if the coins are unwisely used as real money, similarly to wh=
at happened to previous testnets. This signet is picked by default if a use=
r includes -signet without providing any of the parameters mentioned above.=
 The key holder would be someone sufficiently trusted in the community, who=
 would be willing to run the system (block generation code, faucet, etc). I=
t could be made a little more sturdy by using 1-of-N multisig as the challe=
nge, in case 1 &lt;=3D x &lt; N of the signers disappear. If people oppose =
this, it can be skipped, but will mean people can&#39;t just jump onto sign=
et without first tracking down parameters from somewhere.</div><div><br></d=
iv><div>Implementation-wise, the code adds an std::map with block hash to b=
lock signature. This is serialized/deserialized as appropriate (Segwit witn=
ess style), which means block headers in p2p messages are (80=C2=A0+ soluti=
on_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 signatur=
e for the block header hash instead.</div><div><br></div><div>Single commit=
 with code (will split into commits and make PR later, but just to give an =
idea what it looks like):=C2=A0<a href=3D"https://github.com/kallewoof/bitc=
oin/pull/4" target=3D"_blank">https://github.com/kallewoof/bitcoin/pull/4</=
a></div><div><br></div><div>I don&#39;t think this PR is overly intrusive, =
and I&#39;m hoping to be able to get signet code into Bitcoin Core eventual=
ly, and am equally hopeful that devs of other (wallet etc) implementations =
will consider supporting it.</div><div><br></div><div>Feedback requested on=
 this.</div><div><br></div><div>Attribution: parts of the signet code (in p=
articular signblock and getnewblockhex) were adapted from the ElementsProje=
ct/elements repository. When PR is split into atomic commits, I will put ap=
propriate attribution there.</div><div><br></div></div></div></div>

--000000000000da23e205838edc6f--