MIME-Version: 1.0
References: <CALJw2w5OiKHk1oj1p=rmQ-jvYOdieOD=xHcPt9D0A_-nLKvv7Q@mail.gmail.com>
In-Reply-To: <CALJw2w5OiKHk1oj1p=rmQ-jvYOdieOD=xHcPt9D0A_-nLKvv7Q@mail.gmail.com>
Reply-To: lautaro.dragan@gmail.com
From: Lautaro Dragan <lautarodragan@gmail.com>
Date: Sat, 9 Mar 2019 16:52:26 -0300
Message-ID: <CAK6DEsozy9kuqAMFvqu5qeFMq9S+hE7zpZAb1FhJ+8OvdDARWQ@mail.gmail.com>
To: Karl-Johan Alm <karljohan-alm@garage.co.jp>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000075dc6b0583aeae25"
Subject: Re: [bitcoin-dev] Signet
Precedence: list

--00000000000075dc6b0583aeae25
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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 far,
but I admit we have a rather simple use of Bitcoin right now (colored
coins).

For local development, we sometimes use a script that "mines" blocks in
regtest 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
required)

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
> "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 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 tim=
e.
> 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 <=3D x < N of the signe=
rs
> 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.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">Hi Karl-Johan, my two cents:<div><br></div><div>At Po.et w=
e use regtest to simulate reorgs in integration tests in Travis / CircleCI.=
 It has proved quite useful.=C2=A0</div><div><br></div><div>In general regt=
est for automated testing has given us all we needed so far, but I admit we=
 have a rather simple use of Bitcoin right now (colored coins).</div><div><=
br></div><div>For local development, we sometimes use a script that &quot;m=
ines&quot; blocks in regtest periodically. It was my goal to also use this =
method in QA, although we wound up using testnet and didn&#39;t encounter a=
ny problems so far.</div><div><br></div><div>Out of curiosity: what limitat=
ions did you find in using, for example, a private network of bitcoin core =
nodes running regtest? (this gives you the same power as centralization wit=
hout any changes or extra functionality required)</div></div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">El vie., 8 de mar. d=
e 2019 a la(s) 16:02, Karl-Johan Alm via bitcoin-dev &lt;<a href=3D"mailto:=
bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.or=
g</a>&gt; escribi=C3=B3:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr">Hello,<div><br></div><div>As som=
e of you already know, I&#39;ve been working on a network called &quot;sign=
et&quot;, which is bascially a complement to the already existing testnet, =
except it is completely centralized, and blocks are signed by a specific ke=
y rather than using proof of work.</div><div><br></div><div>Benefits of thi=
s:</div><div><br></div><div>1. It is more predictable than testnet. Miners =
appear and disappear regularly, causing irregular block generation.</div><d=
iv><br></div><div>2. Since it is centrally controlled, it is easy to perfor=
m global testing, 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 stabl=
e than testnet, which occasionally sees several thousand block reorgs.</div=
><div><br></div><div>4. It is trivial to spin up (and shut down) new signet=
s to make public tests where anyone can participate.</div><div><br></div><d=
iv>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.</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 a=
n extended=C2=A0period 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.<br></div><div><br></div><div>Signets consist of 2 param=
eters: the challenge script (scriptPubKey) and the solution length. (The la=
tter is needed to retain fixed length block headers, despite having an addi=
tional payload.)</div><div><br></div><div>I propose that a default persiste=
nt &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 what happe=
ned to previous testnets. This signet is picked by default if a user includ=
es -signet without providing any of the parameters mentioned above. The key=
 holder would be someone sufficiently trusted in the community, who would b=
e 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 &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 signet witho=
ut first tracking down parameters from somewhere.</div><div><br></div><div>=
Implementation-wise, the code adds an std::map with block hash to block sig=
nature. This is serialized/deserialized as appropriate (Segwit witness styl=
e), which means block headers in p2p messages are (80=C2=A0+ solution_lengt=
h) bytes. Block header non-contextual check goes from checking if block hea=
der hash &lt; target to checking if the payload is a valid signature for th=
e block header hash instead.</div><div><br></div><div>Single commit with co=
de (will split into commits and make PR later, but just to give an idea wha=
t it looks like):=C2=A0<a href=3D"https://github.com/kallewoof/bitcoin/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=
9;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 con=
sider supporting it.</div><div><br></div><div>Feedback requested on this.</=
div><div><br></div><div>Attribution: parts of the signet code (in particula=
r signblock and getnewblockhex) were adapted from the ElementsProject/eleme=
nts repository. When PR is split into atomic commits, I will put appropriat=
e attribution there.</div><div><br></div></div></div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--00000000000075dc6b0583aeae25--