public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Jeremy Rubin <jeremy.l.rubin@gmail.com>
To: vjudeu@gazeta.pl
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] One testnet to rule them all
Date: Sat, 5 Mar 2022 23:40:11 +0000	[thread overview]
Message-ID: <CAD5xwhghrFtziT+WXOcJs_60pSEqksGiq4Wd2EuP7-SxYsH6qw@mail.gmail.com> (raw)
In-Reply-To: <157830221-11b5cb76ed5c332d9b27cdd734c5f3b1@pmq5v.m5r2.onet>

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

Signet degrades to a testnet if you make your key OP_TRUE.


It's not about needing 21M coins it's about easily getting access to said
coins for testing, where it's kinda tricky to get testnet coins.

On Sat, Mar 5, 2022, 6:17 PM <vjudeu@gazeta.pl> wrote:

> > There's no point to pegging coins that are worthless into a system of
> also worthless coins, unless you want to test the mechanism of testing
> pegging.
>
> But testing pegging is what is needed if we ever want to introduce
> sidechains. On the other hand, even if we don't want sidechains, then the
> question still remains: why we need more than 21 million coins for testing,
> if we don't need more than 21 million coins for real transactions?
>
> > If anything I think we should permanently shutter testnet now that
> signet is available.
>
> Then, in that case, the "mainchain" can be our official signet and other
> signets can be pegged into that. Also, testnet3 is permissionless, so how
> signet can replace that? Because if you want to test mining and you cannot
> mine any blocks in signet, then it is another problem.
>
> On 2022-03-05 17:19:40 user Jeremy Rubin <jeremy.l.rubin@gmail.com> wrote:
> There's no point to pegging coins that are worthless into a system of also
> worthless coins, unless you want to test the mechanism of testing pegging.
>
>
> As is, it's hard enough to get people set up on a signet, if they have to
> run two nodes and then scramble to find testnet coins and then peg them
> were just raising the barriers to entry for starting to use a signet for
> testing.
>
>
>
>
> If anything I think we should permanently shutter testnet now that signet
> is available.
>
>
> On Sat, Mar 5, 2022, 3:53 PM vjudeu via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> In testnet3, anyone can become a miner, it is possible to even mine a
> block on some CPU, because the difficulty can drop to one. In signet, we
> create some challenge, for example 1-of-2 multisig, that can restrict who
> can mine, so that chain can be "unreliably reliable". Then, my question is:
> why signets are introducing new coins out of thin air, instead of forming
> two-way peg-in between testnet3 and signet?
>
> The lack of coins is not a bug, it is a feature. We have more halvings in
> testnet3 than in mainnet or signets, but it can be good, we can use this to
> see, what can happen with a chain after many halvings. Also, in testnet3
> there is no need to have any coins if we are mining. Miners can create,
> move and destroy zero satoshis. They can also extend the precision of the
> coins, so a single coin in testnet3 can be represented as a thousand of
> coins in some signet sidechain.
>
> Recently, there are some discussions regarding sidechains. Before they
> will become a real thing, running on mainnet, they should be tested.
> Nowadays, a popular way of testing new features is creating a new signet
> with new rules. But the question still remains: why we need new coins,
> created out of thin air? And even when some signet wants to do that, then
> why it is not pegged into testnet3? Then it would have as much chainwork
> protection as testnet3!
>
> It seems that testnet3 is good enough to represent the main chain during
> sidechain testing. It is permissionless and open, anyone can start mining
> sidechain blocks, anyone with a CPU can be lucky and find a block with the
> minimal difficulty. Also, because of blockstorms and regular chain reorgs,
> some extreme scenarios, like stealing all coins from some sidechain, can be
> tested in a public way, because that "unfriendly and unstable" environment
> can be used to test stronger attacks than in a typical chain.
>
> Putting that proposal into practice can be simple and require just
> creating one Taproot address per signet in testnet3. Then, it is possible
> to create one testnet transaction (every three months) that would move
> coins to and from testnet3, so the same coins could travel between many
> signets. New signets can be pegged in with 1:1 ratio, existing signets can
> be transformed into signet sidechains (the signet miners rule that chains,
> so they can enforce any transition rules they need).
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

      reply	other threads:[~2022-03-05 23:40 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-04 20:46 [bitcoin-dev] One testnet to rule them all vjudeu
2022-03-05 16:19 ` Jeremy Rubin
2022-03-05 18:17   ` vjudeu
2022-03-05 23:40     ` Jeremy Rubin [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAD5xwhghrFtziT+WXOcJs_60pSEqksGiq4Wd2EuP7-SxYsH6qw@mail.gmail.com \
    --to=jeremy.l.rubin@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=vjudeu@gazeta.pl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox