public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* Re: [bitcoin-dev] Signet
@ 2019-03-13  9:15 Varunram Ganesh
  0 siblings, 0 replies; 11+ messages in thread
From: Varunram Ganesh @ 2019-03-13  9:15 UTC (permalink / raw)
  To: bitcoin-dev

[-- Attachment #1: Type: text/plain, Size: 867 bytes --]

Hello Kalle,

I like your idea of a signet as it would greatly help test reorgs and stuff
without having to experiment with regtest. But I'm a bit concerned about
running a common signet (Signet1) controlled by a trusted entity. I guess
if someone wants to test signet on a global scale, they could spin up a
couple nodes in a couple places (and since it is anyway trusted, they can
choose to run it on centralised services like AWS). Another concern is that
the maintainer might have unscheduled work, emergencies, etc and that could
affect how people test stuff on. This would also mean that we need people
to run signet1 nodes in parallel with current testnet nodes (one could
argue that Signet is trusted anyway and this doesn't matter, still)

I'm sure you would have considered these while designing, so would be great
to hear your thoughts.

Regards,
Varunram

[-- Attachment #2: Type: text/html, Size: 1004 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread
[parent not found: <CACJ+Xm+-+C43ev_Sk8T-wdm=1nsmHHR_wB4rk+wu9CJvMHS5jw@mail.gmail.com>]
* [bitcoin-dev] Signet
@ 2019-03-08  5:54 Karl-Johan Alm
  2019-03-08 20:20 ` Matt Corallo
  2019-03-09 19:52 ` Lautaro Dragan
  0 siblings, 2 replies; 11+ messages in thread
From: Karl-Johan Alm @ 2019-03-08  5:54 UTC (permalink / raw)
  To: Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 3305 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 3870 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2019-03-14  1:17 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-03-13  9:15 [bitcoin-dev] Signet Varunram Ganesh
     [not found] <CACJ+Xm+-+C43ev_Sk8T-wdm=1nsmHHR_wB4rk+wu9CJvMHS5jw@mail.gmail.com>
2019-03-14  1:17 ` Karl-Johan Alm
  -- strict thread matches above, loose matches on Subject: below --
2019-03-08  5:54 Karl-Johan Alm
2019-03-08 20:20 ` Matt Corallo
2019-03-10  0:43   ` Karl-Johan Alm
2019-03-10 17:01     ` David A. Harding
2019-03-12  5:44       ` Karl-Johan Alm
2019-03-13  3:23   ` Anthony Towns
2019-03-14  1:07     ` Karl-Johan Alm
2019-03-09 19:52 ` Lautaro Dragan
2019-03-10  1:02   ` Karl-Johan Alm

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox