path: root/60/5ebbde8c98f436e274e087736e6d0002b26d6d

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 E5F32D56
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 17 Jul 2019 07:52:58 +0000 (UTC)
X-Greylist: delayed 00:08:30 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 895D6879
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 17 Jul 2019 07:52:57 +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 558FC14C100
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 17 Jul 2019 16:44:26 +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; 17 Jul 2019 16:44:26 +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 4D1C94C096
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 17 Jul 2019 16:44:26 +0900 (JST)
	(envelope-from karljohan-alm@garage.co.jp)
Received: from gw31.oz.hdemail.jp
	(ip-10-122-153-121.ap-northeast-1.compute.internal [10.122.153.121])
	by mo.garage.hdemail.jp (hde-mf-postfix) with ESMTP id 4723814C100
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 17 Jul 2019 16:44:26 +0900 (JST)
	(envelope-from karljohan-alm@garage.co.jp)
X-Received: from mail-qt1-f197.google.com (lb05.oz.hdemail.jp [54.238.57.175])
	(using TLSv1 with cipher AES128-SHA (128/128 bits))
	(No client certificate requested)
	by gw31.oz.hdemail.jp (Postfix) with ESMTP id D8CEF148C130
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 17 Jul 2019 16:44:25 +0900 (JST)
X-Received: by mail-qt1-f197.google.com with SMTP id y19so20534449qtm.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 17 Jul 2019 00:44:25 -0700 (PDT)
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=WifUYb410G/3Jfg0SfkYvDLxybZL21+Wr7l1qRSLbYg=;
	b=k5W0+Z1KrPZpitenOVv33lt5LSCLJIJSIYnEyjS/r9hRA7jLvlxLw7c65YBAia4z9K
	Lp1q04ui9SQXasaz4APj/uLGQ1ShUD9avEHzIvGnDOntR+rfyk+KMvL6uMFGTOgeRwoU
	kug7jXW8+6V8mAFiCFmiJUskYtw4cefxEwIOLzv0R2+HQoQthxfb9tZKKVEkeGaK3y4+
	t1HXJ97vDIXRHeaJL2KAgBKgRpyK5X8pBTmLWbCp3k+6IQf0daQe5CML6SYxAPUakd0c
	mb9EKIo0czb6eiLo4J4zbbPSeOVcjFdCI8cpNkrgJfFuEDc77ZecbTbK6Po85sMLigHR
	9GJA==
X-Gm-Message-State: APjAAAWFRbqiNAf3CHMg+HYlwoEIVHji5oIHltJYN63y8aoj+9lXmQi3
	KUh8iXY8IvfedZJLbnmh/yIya7DDEwBF+WsfiYKLkOGnsim7nSMyT1crItcdvJPc7sQe9Z2zTED
	tWDM9qWGdole0I2qXj5PlhrIBNC06icseHLjYppgAvaGaeIWC3avD7PLnmvatcTGAYQG5cVRVsN
	fyJS8Npi5XVxIq1Xi/0fZlKRhCrfdNfafr4C4o7IJkohJfpq4ozJenLQqvJY2R5G1qDIAPuuGNs
	RxWj0ZLuWFSz/WozFP54QkXb6KNmUXuW31ZIlV5N2ZdjooXU4zRHKI2ZB370D+trN7+ay8crYow
	Rz6BY7AKrhRnq+7fshdiAZMY/Oc=
X-Received: by 2002:a05:6214:1c3:: with SMTP id
	c3mr21215222qvt.144.1563349464431; 
	Wed, 17 Jul 2019 00:44:24 -0700 (PDT)
X-Google-Smtp-Source: APXvYqxLII+TzCR+S+vstnuOdZp5QNrbnghpcT0acdCINTBze9pbqRenNXTjfrHymzjiqcCVxEKeyqtf8M3JV0toql0=
X-Received: by 2002:a05:6214:1c3:: with SMTP id
	c3mr21215202qvt.144.1563349464014; 
	Wed, 17 Jul 2019 00:44:24 -0700 (PDT)
MIME-Version: 1.0
From: Karl-Johan Alm <karljohan-alm@garage.co.jp>
Date: Wed, 17 Jul 2019 16:44:13 +0900
Message-ID: <CALJw2w6PZS8ERQmNczbLKudjfSF+xcew9qy_LjXnnmNzsghMiA@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,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: Wed, 17 Jul 2019 08:08:28 +0000
Subject: [bitcoin-dev] BIP: 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: Wed, 17 Jul 2019 07:52:59 -0000

Hello,

I have written a BIP describing the Signet network. Feedback requested!

https://github.com/bitcoin/bips/pull/803

Pasted in its entirety below, with formatting issues left as is. See
above link for styled version.

<pre>
BIP: XXXX
Layer: Applications
Title: Signet
Author: Karl-Johan Alm <karljohan-alm@garage.co.jp>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-XXXX
Status: Draft
Type: Standards Track
Created: 2019-03-20
License: CC0-1.0
</pre>

== Abstract ==

A new type of test network where signatures are used in addition to
proof of work for block progress, enabling much better coordination
and robustness (be reliably unreliable), for persistent, longer-term
testing scenarios involving multiple independent parties.

== Motivation ==

Testnet is a great place to try out new things without risking real
money, but it is notoriously unreliable. Huge block reorgs, long gaps
in between blocks being mined or sudden bursts of blocks in rapid
succession mean that realistic testing of software, especially
involving multiple independent parties running software over an
extended period of time, becomes infeasible in practice.

A new type of test network would be more suitable for integration
testing by organizations such as exchanges, or testing of next
generation Layer-2 protocols like Eltoo or sidechain pegs. The goal is
not to be perfectly reliable but rather to have a predictable amount
of unreliability. You want a test network to behave like mainnet (i.e.
no thousands of block reorgs) while also making it easier to trigger
expected but rare events like a 6-block reorg. Regtest is not suitable
for longer-term scenarios involving multiple independent parties
because creating blocks costs nothing, so any party can completely
control the test network.


== Specification ==

A new type of network ("signet"), which takes an additional consensus
parameter called the challenge (scriptPubKey). The challenge can be a
simple pubkey (P2PKH style), or a k-of-n multisig, or any other script
you would want.

The witness commitment of the coinbase transaction is extended to
include a secondary commitment (the signature/solution):

1-4 bytes - Push the following (x + 4) bytes
4 bytes - Signet header (0xecc7daa2)
x bytes - Solution (sigScript)

Any push operations that do not start with the 4 byte signet header
are ignored. Multiple push operations with the 4 byte signet header
are ignored except for the first entry.

Any signature operations contained within the challenge use
SHA256d(modifiedBlockHash), i.e. the double-SHA256 digest of the
following data as the sighash:

{|class="wikitable" style="text-align: center;"
|-
!Type
!Size
!Name
|-
|Int32||4||nVersion
|-
|Uint256||32||hashPrevBlock
|-
|Uint256||32||modifiedMerkleRoot
|-
|Uint32||4||nTime
|-
|Uint32||4||nBits
|}

The <code>modifiedMerkleRoot</code> hash is obtained by generating the
merkle root of the block transactions, with the coinbase witness
commitment as is, without the signet extension. This means the merkle
root of the block is different from the merkle root in the signet
commitment, but in return, the block nonce value is the only component
that the signet signature does not commit to. When grinding proof of
work, the extended nonce cannot be used as it would invalidate the
signature. Instead, simply resigning the same (or an updated) block
will give a new search space.

A block is considered fully validated if the above commitment is
found, and its solution is valid. This verification should be done
directly before or after the witness commitment verification.

== Compatibility ==

This specification is backwards compatible in the sense that existing
software can use Signet out of the box.

Simply by adding the network parameters for signet (magic number,
etc), a client can connect to and use any signet network without
further modifications. The block headers have valid proof of work, so
clients can trivially check that blocks are "probably" valid.

However, anyone can mine blocks that are accepted by the client for
any given signet network. These blocks do not contain the required
signatures, however, so any fully validating node will promptly reject
them. As such, clients need to either validate the block signature
inside the coinbase transaction, or connect to trusted peers.

Other software need not add block signature validation code that they
will not use in production. This is adequate for non-production test
purposes where the goal is to have a network behave as much like
mainnet as possible.

== Reference implementation ==

WIP implementation at https://github.com/kallewoof/bitcoin/pull/4

== Acknowledgements ==

TODO

== References ==

# Original mailing list thread:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-March/016734.html
# Bitcoin Wiki entry: https://en.bitcoin.it/wiki/Signet

== Copyright ==

This document is licensed under the Creative Commons CC0 1.0 Universal license.