path: root/d7/68a99fe193f09c886d8fa716b8cc9b334be2b2

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 B05E3A5E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 10 Mar 2019 01:02:49 +0000 (UTC)
X-Greylist: from auto-whitelisted 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 C2973821
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 10 Mar 2019 01:02:48 +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 5119B14C0C5
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 10 Mar 2019 10:02:47 +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; 10 Mar 2019 10:02:47 +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 382384C06D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 10 Mar 2019 10:02:47 +0900 (JST)
	(envelope-from karljohan-alm@garage.co.jp)
Received: from gw14.oz.hdemail.jp
	(ip-10-188-130-13.ap-northeast-1.compute.internal [10.188.130.13])
	by mo.garage.hdemail.jp (hde-mf-postfix) with ESMTP id 280CB14C0C5
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 10 Mar 2019 10:02:47 +0900 (JST)
	(envelope-from karljohan-alm@garage.co.jp)
X-Received: from mail-qk1-f200.google.com (lb05.oz.hdemail.jp [54.238.57.175])
	(using TLSv1 with cipher AES128-SHA (128/128 bits))
	(No client certificate requested)
	by gw14.oz.hdemail.jp (Postfix) with ESMTP id BB76C148C11A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 10 Mar 2019 10:02:46 +0900 (JST)
X-Received: by mail-qk1-f200.google.com with SMTP id b11so1362368qka.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 09 Mar 2019 17:02:46 -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:references:in-reply-to:from:date
	:message-id:subject:to:cc:content-transfer-encoding;
	bh=KQc9qad+QI024KMVvQhN8IibFTi58TT3hD9N8M6o/4w=;
	b=CO5ueIa2NqDwU+vWZCe22AfqxzRkpARl0n4olrWxCYsscYnBEtG21hdVovbypuZU0W
	b/w9hRdg+BHSGZslE5NEKcIxG5YpLDAL1VaeSl647zfR7/imFAIetosLtRY1gwQStIht
	OS4QnCSKvPsKkyXcW993HygUUiI34QM8VIKcERgqfULHo9KEqdysosXplcYP5tVEvJAO
	ASSoCjNIkJj81LbBhn8m25N9Z5VPyMz4Nl70NQ3epjrbXHvq9jnR3p1QWWoxt0D5gQKu
	7/0rvQnlbLFZYP7EVQl6wRLg22M6JEBjdnMu58D/w8iY9moQgizBHBNg+GMH6hk3Lmfe
	sivw==
X-Gm-Message-State: APjAAAVaAhvdwWJ/EbZjs0Y3k2cJSMJuMAseF1FmGrKCFAlPRjxnGkIP
	cVPrsamD0eRFcPE5VU4Hp2B7CemkVj28NxTygoG9HoLdIDuA6yxdVhbBPtFWY4WqVdVQxBMUh/9
	OExqtidRfq2evlxsaBWusmPE/QP5UTArfJXHBDHLn2kP62A6ejhFs//2E2UHUHqcEfzK7LZKtkI
	hq6vUqOr7D3FeTojHRzQPKoS1uQlwVZ87thFvehRSXu2sk75F06wGhRY/bPvGP5+oLMPCsVpqfk
	HvDha1Twsq0ERj1cYhYCH7kYJ7yoxPrV1+ansx1DmEuyFEb7XE0LmQBOS57v+auSh6RXo/2NX0J
	GFPOpLIZ0WeJs4CYqDtza0Vd0kE=
X-Received: by 2002:ae9:ec13:: with SMTP id h19mr9309602qkg.345.1552179765374; 
	Sat, 09 Mar 2019 17:02:45 -0800 (PST)
X-Google-Smtp-Source: APXvYqx1lWJZ6gJMfCc+DfbrgbewSjJWumcM7Bnij1hLI6O1s+vAo0XTZYSRPnOaqLRQMytQSb9JUA95844ULq8dZK0=
X-Received: by 2002:ae9:ec13:: with SMTP id h19mr9309591qkg.345.1552179765114; 
	Sat, 09 Mar 2019 17:02:45 -0800 (PST)
MIME-Version: 1.0
References: <CALJw2w5OiKHk1oj1p=rmQ-jvYOdieOD=xHcPt9D0A_-nLKvv7Q@mail.gmail.com>
	<CAK6DEsozy9kuqAMFvqu5qeFMq9S+hE7zpZAb1FhJ+8OvdDARWQ@mail.gmail.com>
In-Reply-To: <CAK6DEsozy9kuqAMFvqu5qeFMq9S+hE7zpZAb1FhJ+8OvdDARWQ@mail.gmail.com>
From: Karl-Johan Alm <karljohan-alm@garage.co.jp>
Date: Sun, 10 Mar 2019 10:02:34 +0900
Message-ID: <CALJw2w4SqEx__8kgGEg9F03ftCAEyq3dxWVG786ueLa=PY35aw@mail.gmail.com>
To: lautaro.dragan@gmail.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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: Sun, 10 Mar 2019 13:22:48 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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: Sun, 10 Mar 2019 01:02:49 -0000

Hi Lautaro,

Using regtest is not ideal for public networks, as anyone anywhere can
just rewrite the blockchain at their whim by mining a ton of blocks.

On Sun, Mar 10, 2019 at 4:52 AM Lautaro Dragan <lautarodragan@gmail.com> wr=
ote:
>
> Hi Karl-Johan, my two cents:
>
> At Po.et we use regtest to simulate reorgs in integration tests in Travis=
 / CircleCI. It has proved quite useful.
>
> In general regtest for automated testing has given us all we needed so fa=
r, but I admit we have a rather simple use of Bitcoin right now (colored co=
ins).
>
> For local development, we sometimes use a script that "mines" blocks in r=
egtest periodically. It was my goal to also use this method in QA, although=
 we wound up using testnet and didn't encounter any problems so far.
>
> Out of curiosity: what limitations did you find in using, for example, a =
private network of bitcoin core nodes running regtest? (this gives you the =
same power as centralization without any changes or extra functionality req=
uired)
>
> El vie., 8 de mar. de 2019 a la(s) 16:02, Karl-Johan Alm via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> escribi=C3=B3:
>>
>> Hello,
>>
>> As some of you already know, I've been working on a network called "sign=
et", which is bascially a complement to the already existing testnet, excep=
t it is completely centralized, and blocks are signed by a specific key rat=
her than using proof of work.
>>
>> Benefits of this:
>>
>> 1. It is more predictable than testnet. Miners appear and disappear regu=
larly, causing irregular block generation.
>>
>> 2. Since it is centrally controlled, it is easy to perform global testin=
g, 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 thous=
and block reorgs.
>>
>> 4. It is trivial to spin up (and shut down) new signets to make public t=
ests where anyone can participate.
>>
>> Anyone can create a signet at any time, simply by creating a key pair an=
d creating a challenge (scriptPubKey). The network can then be used globall=
y by anyone, assuming the creator sends some coins to the other participant=
s.
>>
>> 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 he=
aders, despite having an additional payload.)
>>
>> I propose that a default persistent "signet1" is created, which can be r=
eplaced in future versions e.g. if the coins are unwisely used as real mone=
y, similarly to what happened to previous testnets. This signet is picked b=
y default if a user includes -signet without providing any of the parameter=
s mentioned above. The key holder would be someone sufficiently trusted in =
the community, who would be willing to run the system (block generation cod=
e, faucet, etc). It could be made a little more sturdy by using 1-of-N mult=
isig as the challenge, in case 1 <=3D x < N of the signers disappear. If pe=
ople oppose this, it can be skipped, but will mean people can't just jump o=
nto 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 s=
tyle), which means block headers in p2p messages are (80 + solution_length)=
 bytes. Block header non-contextual check goes from checking if block heade=
r hash < target to checking if the payload is a valid signature for the blo=
ck 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/bitc=
oin/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 d=
evs of other (wallet etc) implementations will consider supporting it.
>>
>> Feedback requested on this.
>>
>> Attribution: parts of the signet code (in particular signblock and getne=
wblockhex) were adapted from the ElementsProject/elements repository. When =
PR is split into atomic commits, I will put appropriate attribution there.
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev