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
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Signet
Precedence: list

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