path: root/ad/31a6afbd5021679922a38b4a1a21296f3f2b8f

Delivery-date: Tue, 02 Apr 2024 17:23:09 -0700
Received: from mail-qt1-f192.google.com ([209.85.160.192])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDFIP6H73EBBBZOCWKYAMGQEBSAX47I@googlegroups.com>)
	id 1rroPE-0002FI-FR
	for bitcoindev@gnusha.org; Tue, 02 Apr 2024 17:23:09 -0700
Received: by mail-qt1-f192.google.com with SMTP id d75a77b69052e-43442ed9385sf543781cf.0
        for <bitcoindev@gnusha.org>; Tue, 02 Apr 2024 17:23:08 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1712103782; cv=pass;
        d=google.com; s=arc-20160816;
        b=ZfNYn6xJiM71bjaArz34d2Xq7VpRFOooPpSEooB35+TciuwQ8GWeMlrB1NZv6pn6Ov
         vYqQu7M8iPFbuxp2OcWa8lP2HcRIKj09Mg/0cRZ26CDiq+f38nQhLKPmc/ScaQufldOp
         RkpLSMk8ldQ85jS5vA5ISLpwDle/Kh1u8CCgbOw4yu/oa2m/nA+HyjmNLF3t0bOZJqss
         Z68hTRaw0FbhrYBBkn1Gduco4BaZcwbcK1WbNBcN4lERUgHi6icY5GUp8O1lFXnOgW9X
         kHrthChfyTax5EPyU5LO7uuC7M02QFldlV3YHHtDgHS1CwDGlHIW/S04HvFyD0B8P+AU
         n24g==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:sender:dkim-signature
         :dkim-signature;
        bh=olldi31259gXPn3xsF/Z1eBbQQU+3RAKoSmBgkGaoLo=;
        fh=/zeWSk4Zf4JGRsE3Q9/nhOzuNIkd0iSIcLoSjkI4HUY=;
        b=klnXMO//X8b2/V3siQ7S/Q1qZtT0ip2hG9Wqy3BBcAFALbQLupUVXC1rqSNhfrIiPx
         MSzO/z9hrWw+2BqlxteoktHlcauQBy+cdnO/FQyNSV5n2utPETcogyUlqJZDwNUUjnbD
         a/6lTMSBWXB+N4AH0tuf2Ni37K7AWfpkSJxDddiXjzKicGACszz74PnQnt6BHoex7NsH
         5Q/VlSMYV0TY/UzOMaSsfQ3uNpwafXINU0kRPK5RrgBd9KX7JKPwvVZnj0975JY6ZELB
         hs6RNoiBHE6LLmyqLKPtlevZIHKyPtJd85cjnlY2E1e2fAjn3K4jEe4XdhWYcM7Kyh3D
         YflA==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=RodxY8cP;
       spf=pass (google.com: domain of jameson.lopp@gmail.com designates 2607:f8b0:4864:20::102c as permitted sender) smtp.mailfrom=jameson.lopp@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1712103782; x=1712708582; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=olldi31259gXPn3xsF/Z1eBbQQU+3RAKoSmBgkGaoLo=;
        b=hG7RYfWxkxuVoCIzxtSeY2vCR+ajV02/F650UXc/0dVOX+J5ho/TPJYbfTYBqR8IPj
         JmxYZhKDknxqyqK9vOqrErF00QLPvZfL24H9o4Q3P9ciOOjvWZ48XktDp+k3svl6ou46
         BenE2FaOWJaKFKr7uf4emQm2yEJWK67F6JAfuoIVNUaX2v5KYd6K5etlN+xa8oLS27po
         dBUy6JliQtdEA5kpgIG3z8Wa2KvGnKjHKu3QYlxtmYyXCDzuTqhzO/JXLp04v4zeWUyZ
         NFMLsJWo1EyY3PWSD8MK4zp06EuVVVA7Yqjlx4WFxvZntnXitCpdKiqmeEoxtVP7C1e7
         mMkA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1712103782; x=1712708582; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=olldi31259gXPn3xsF/Z1eBbQQU+3RAKoSmBgkGaoLo=;
        b=JDN9JD9ThIutcis8jcnWVB19xOK99OIlSSEXvjN+E24U7mosdEQDbli9c02GTgtnex
         r8nwfmC8Irlw0WMyG5ZlnJgmcUTFL/8mxTGCgoDx3E584cJF+4lVcKEDLPFCV059PPJe
         XPnYq4fnmUwTVhzrDha73qCmnEUYN192L981N7N7vkKBHZIU6IbPuM0ENvEAxlk41cxY
         UE4HbIE5DLPrNo82MNVtx4n7QXOhTY/rBo+gV6FSgmQbt5pRtpkvIXDnr5L5rk3cK0Gs
         jNqbmFSzXa6i/ygCtVWFkNiHEbeb8dFvBeAYehGK3mV78RPWND5XHVSPHuHRJOQFjNbk
         H3gg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1712103782; x=1712708582;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:x-beenthere:x-gm-message-state:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=olldi31259gXPn3xsF/Z1eBbQQU+3RAKoSmBgkGaoLo=;
        b=qekKUzgg2EMqgpwsseLCq5y3uXwX/jh3r6moQHmtlct5/PtmjpxjpI3+Ow/Z1RzRoV
         nLpFdY0r3bylpM6KcuAUGAMqfrEMxX1Igq+Zy1lD8BNfcSevTYK4Ajp04xKSt/62b6C5
         UMY2tpwX4z2Iioy3/dx6p6mfZmoidmD1RvbWumbnWlohFxsKpjoK+JAowXoF4jbuGvG2
         JaltQDHleRF+2K7YOfn4TOMx9jyeJ8oq3M9xev1aYtKkdUfCwWasS99Gy5FZXdkx/4Fa
         81zjAYrUAG9LZ2eSuHYjCZRDoD8JXXGOAzMHnG1R1+9trPXOD9Xn+kUQLEgXfzLQE2jA
         cX7g==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCWoLKv4SObFulL1Qm8u2Vm8KE1kcILzyIyZTpWLLvly+OyNUZ5U43AQFO1NUtLllwm67S2ihZ31d9tqMIqMV4zpQQDVMD0=
X-Gm-Message-State: AOJu0Yzl1Nmm1qFXPF9s3dLKUfI0SZr7zHxkV/bTW8kFQiQGU3FaBfeC
	zfHnkF2Nrg8sgWe/OcUWnmrmQzU8+rMicg8LoDx09ahCRTpKQXpO
X-Google-Smtp-Source: AGHT+IFE4wcg/5twS0yGSZa4aEKzB1yF9HtSlnJNLsUH1ZIeVDILfK1xXT+kGbekuca70sSnESyMnw==
X-Received: by 2002:ac8:5b86:0:b0:432:b6d3:4d70 with SMTP id a6-20020ac85b86000000b00432b6d34d70mr18645700qta.60.1712103781891;
        Tue, 02 Apr 2024 17:23:01 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a05:622a:190f:b0:432:d735:f040 with SMTP id
 w15-20020a05622a190f00b00432d735f040ls5424434qtc.0.-pod-prod-07-us; Tue, 02
 Apr 2024 17:23:01 -0700 (PDT)
X-Received: by 2002:a05:622a:386:b0:431:5135:1b66 with SMTP id j6-20020a05622a038600b0043151351b66mr411313qtx.9.1712103780860;
        Tue, 02 Apr 2024 17:23:00 -0700 (PDT)
Received: by 2002:a05:620a:4112:b0:78c:4db6:8bba with SMTP id af79cd13be357-78d36d57e6ems85a;
        Tue, 2 Apr 2024 12:46:38 -0700 (PDT)
X-Received: by 2002:a05:6122:410c:b0:4d4:b89:bd2a with SMTP id ce12-20020a056122410c00b004d40b89bd2amr10812985vkb.3.1712087196778;
        Tue, 02 Apr 2024 12:46:36 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1712087196; cv=none;
        d=google.com; s=arc-20160816;
        b=QRBqObINdfBRsNEE69d2cp9iqnFgkGOeexB+7TLUoBoiUkH4X8x9xiCyAVnofjkQA9
         hriQBkRf4LvapclLROf5aLxeJKhL9oJJRn5Ms11o42yaUxIIO9r1wpO4NB80Fyso0tJB
         CKJfrLoSiFUW7QW/62dMd4C3O8E3tNogQldo/TpYso71dzPqMaI6ITMS4+jw934AknJk
         NeIq0RoSgWBzSXko3GCoMnhsfcHkfugUkXgQfl/8uXUe1NAyvkyjwGg2/ZUectdM9DV5
         C0jhksXxx4127+reJM/RHpy0CsZZMinIu5+62oKBmHfv01DmcJ49J1QLX6CA3Itc1iI8
         oJsw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:dkim-signature;
        bh=ibT9TabNCWf5rc+OF6jYPY9XCdZURVKnOTWXJH1/vvI=;
        fh=KwdsfmdQs870rGOZhw3KA3/EOSHI2wH2VqrDesubUJE=;
        b=gCBI/p7r8vrv8v/s7FGujVXiOql2JhJRv8QIbvyOKk7V+8IwS7yGHSUJ3ileZGIUl4
         Bf9pygVxEXJzX9rKZ34C7XLi5bmbZsfa0lhUWk93vvmrags9erzWS0NV8mpAvxhPz5a5
         d/4lZQSv5tN+Ee8pmTy4jQT6zdTq8tUyyKLsnqlNhvPtrADWMWFU7Y5wdXY4fxt0kHIz
         1PRPt6pL9OLFuYxTvSkzohbM+8oxOE6PpDswlbelm7igiG0fwBJoFQ9+ZZIVlxf0LRUD
         18LjPS2JTZuRfwf4yqHn+xgqLJw6lpbuvqxi0VPLVMdVjQyD/vDZrK2B+bB6psBer/lA
         0X5Q==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=RodxY8cP;
       spf=pass (google.com: domain of jameson.lopp@gmail.com designates 2607:f8b0:4864:20::102c as permitted sender) smtp.mailfrom=jameson.lopp@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com
Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com. [2607:f8b0:4864:20::102c])
        by gmr-mx.google.com with ESMTPS id n1-20020a1fd601000000b004d8995bf32bsi1438852vkg.3.2024.04.02.12.46.36
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Tue, 02 Apr 2024 12:46:36 -0700 (PDT)
Received-SPF: pass (google.com: domain of jameson.lopp@gmail.com designates 2607:f8b0:4864:20::102c as permitted sender) client-ip=2607:f8b0:4864:20::102c;
Received: by mail-pj1-x102c.google.com with SMTP id 98e67ed59e1d1-2a293ba705eso15644a91.3
        for <bitcoindev@googlegroups.com>; Tue, 02 Apr 2024 12:46:36 -0700 (PDT)
X-Received: by 2002:a17:90a:4a03:b0:2a2:140b:7287 with SMTP id
 e3-20020a17090a4a0300b002a2140b7287mr10600207pjh.47.1712087195648; Tue, 02
 Apr 2024 12:46:35 -0700 (PDT)
MIME-Version: 1.0
References: <CADL_X_eXjbRFROuJU0b336vPVy5Q2RJvhcx64NSNPH-3fDCUfw@mail.gmail.com>
 <ZgmJFfXnQddkTQVq@petertodd.org> <CAFC_Vt7zKvMEfQLzWHQ6t_9bgv1iqt4Ah8N883CuoSfmLUKdMA@mail.gmail.com>
 <ZgnVtJHn2ikLfwa9@petertodd.org> <CADL_X_cmcXxHke089OD_45VRJy5aR+9uj-18bSjXBE7FKwR-Jw@mail.gmail.com>
 <wKrcm6SEjcG_7UmxByP-rDDVajB7-oYJRF9p_BjLe5XVzxVV9nCB8RsTAXcD5vF_rWxUmLK4HOM7zV7U4-kZSUO9Ccj4jEehsbbb7FD45GQ=@wuille.net>
 <ZgrCxWxMkiAt2Tg2@camus> <06oL-GctrcLb99M_RuOgygXKMjtB_vPLHOCuc-axYrGVy_QBRGPu5wA9C2QXDb7cKIJbJu_t_JKmRrr9FsBORdUPavXPFvOi98p04UQuvuE=@protonmail.com>
 <CADL_X_dR1ENC9jm76azf_dkbJdeSCSBbPEpTkm71s4i-g_g=WA@mail.gmail.com> <c1e32072-55ff-4cca-a56c-09c747e7e4a6n@googlegroups.com>
In-Reply-To: <c1e32072-55ff-4cca-a56c-09c747e7e4a6n@googlegroups.com>
From: Jameson Lopp <jameson.lopp@gmail.com>
Date: Tue, 2 Apr 2024 15:46:21 -0400
Message-ID: <CADL_X_c3YhyeqgsrFBVixpPOQWEacsa5cZUSK5uzLLNha9w=+Q@mail.gmail.com>
Subject: Re: [bitcoindev] The Future of Bitcoin Testnet
To: =?UTF-8?B?THVrw6HFoSBLcsOhxL4=?= <emsit@emsit.sk>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Content-Type: multipart/alternative; boundary="0000000000001f0fa90615225dd4"
X-Original-Sender: jameson.lopp@gmail.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@gmail.com header.s=20230601 header.b=RodxY8cP;       spf=pass
 (google.com: domain of jameson.lopp@gmail.com designates 2607:f8b0:4864:20::102c
 as permitted sender) smtp.mailfrom=jameson.lopp@gmail.com;       dmarc=pass
 (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.5 (/)

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

There are no official rules; this is crypto anarchy. No one can kill
testnet3 or stop anyone from using it.

However, the only real "principle" of testnet (AFAIK) is that the coins
should be worthless in order to encourage freely sharing said coins with
anyone who needs them for development or testing purposes. Client
implementations can choose to no longer support old versions of testnet in
adherence to this principle.

The rough agreement, which hasn't been necessary to enforce for 13 years,
is that testnet should get reset any time it starts to have economic value.
I propose that such rug pulls should continue until everyone gets a clue
that they're going to lose any money they put into it.

On Tue, Apr 2, 2024 at 3:05=E2=80=AFPM Luk=C3=A1=C5=A1 Kr=C3=A1=C4=BE <emsi=
t@emsit.sk> wrote:

> I think people will be very reluctant to give up testnet3, including
> myself. I've been running a testnet3 faucet for 10 years, distributing
> 327197.44 tBTC via the faucet + a few thousand outside the faucet.
> Resetting the testnet will mean the end for my faucet because I won't be
> mining new coins anymore. People who have testnet3 will have to find a ne=
w
> way to obtain testnet4.
>
> Are there any official rules for when a testnet reset will occur? If I
> understand correctly, it's being considered because of the "price" and th=
e
> low mining reward? When testnet4 launches and starts trading in a month,
> will testnet5 be launched shortly after...?
>
> I would focus more on how to keep it invaluable and easily accessible to
> developers. I would definitely leave the transitional phase for at least =
a
> year, and the BTC client should have parameters for both -testnet3 and
> -testnet4. Personally, *I think the adoption of testnet4 will be very
> slow*.
>
> D=C3=A1tum: utorok 2. apr=C3=ADla 2024, =C4=8Das: 14:00:40 UTC+2, odosiel=
ate=C4=BE: Jameson
> Lopp
>
>> I think Andrew's difficulty rule suggestions are the least invasive and
>> make sense for fixing the block storm issue while keeping the code chang=
es
>> to the logic that is already conditional to testnet. Though even with th=
ose
>> rules I think it would still be possible, though far less likely, for th=
e
>> difficulty to get permanently reset very low unless we also implement th=
e
>> difficulty adjustment patch Fabian mentioned.
>>
>> I suspect that creating a "fair" faucet is an unsolvable problem: the
>> only robust way to gate free giveaways (much like airdrops) is to impose=
 an
>> economic cost on claiming them, which is against the spirit of testnet.
>>
>> As emsit and I both noted, 13 years without a reset means that it would
>> be courteous to give testnet operators a reasonably long heads up to
>> prepare. Perhaps 6 months or 1 year lead time?
>>
>> On Mon, Apr 1, 2024 at 6:06=E2=80=AFPM 'Fabian' via Bitcoin Development =
Mailing
>> List <bitco...@googlegroups.com> wrote:
>>
>>> Hi,
>>>
>>> removing the special rule and moving to a reduced block interval sounds
>>> like a good and simple solution.
>>>
>>> Another idea: Keep the current exception logic and adapt the difficulty
>>> adjustment code (`CalculateNextWorkRequired`) to look for the last bloc=
k
>>> that didn't have difficulty 1 and use that block's difficulty as the ba=
sis
>>> for the new difficulty calculation. It seemed like the most intuitive f=
ix
>>> to me when I looked at the code after reading Jameson's first email (se=
e
>>> https://github.com/bitcoin/bitcoin/pull/29775/commits/9913549637706749f=
0af5d326f949bd652cbd5f8
>>> ).
>>>
>>> Best,
>>> Fabian
>>>
>>>
>>>
>>> On Monday, April 1st, 2024 at 4:20 PM, Andrew Poelstra <
>>> apoe...@wpsoftware.net> wrote:
>>>
>>> > On Mon, Apr 01, 2024 at 01:37:59PM +0000, Pieter Wuille wrote:
>>> >
>>> > > As for using other measures to prevent too large difficulty
>>> variations... I'm not sure that's desirable, because it always cuts bot=
h
>>> ways (nicely demonstrated by the "allow difficulty 1 rule" on testnet3
>>> backfiring and enabling block storms!). For applications that actually =
need
>>> very predictable block rate, there is signet. For others, just the norm=
al
>>> mainnet rules are probably not too terrible. I would be ok with having =
a
>>> somewhat reduced block interval (say a few days instead of 2 weeks) if
>>> that's not deemed to complex to implement across the ecosystem, but I d=
on't
>>> think it's that important.
>>> >
>>> >
>>> > I really like this. For my part (rust-bitcoin) this would be as simpl=
e
>>> > as adding an extra parameter to my blockparams structure. Possibly on=
e
>>> > already exists, I'd have to check.
>>> >
>>> > This would be much easier than the existing situation where we have
>>> > special-case logic for testnet the difficulty-1 target.
>>> >
>>> > It would also limit the amount of bikeshedding possible, since there
>>> > aren't too many conflicting goals regarding the retargeting window...
>>> > unlike tweaking the existing logic where there's a tradeoff between
>>> > "we should make this never happen" and "it should happen often enough
>>> > that it doesn't break people's code" and "it should happen if blocks
>>> > slow down to like, 1/50th their normal rate even if they are still
>>> > technically being produced" and "it shouldn't be possible to trigger
>>> > it within the 2-hour timestamp-faking window" etc. And questions
>>> > about whether we should fix/redesign the interaction between the rese=
t
>>> > rule and the normal difficulty retarget.
>>> >
>>> >
>>> > OTOH, since we already have the special logic, I'd also be happy with
>>> > tweaking the existing rule. My specific proposal (after reading
>>> Jameson's
>>> > post, which has some nice graphs of difficulty) would be
>>> >
>>> > * increase the reset threshold from 20 minutes to 6 hours, which is
>>> > (a) well outside the 2-hour window in which miners can easily fake
>>> > timestamps, and (b) will basically never be hit by accident
>>> > * increase the reset difficulty from 1 to 1MM, which is an rough lowe=
r
>>> > bound on the "normal" testnet difficulty seen historically
>>> >
>>> > Which puts us in the "this rule would never be triggered unless
>>> > literally everyone stopped mining" corner of the design space.
>>> >
>>> >
>>> > --
>>> > Andrew Poelstra
>>> > Director of Research, Blockstream
>>> > Email: apoelstra at wpsoftware.net
>>> > Web: https://www.wpsoftware.net/andrew
>>> >
>>> > The sun is always shining in space
>>> > -Justin Lewis-Webster
>>> >
>>> > --
>>> > You received this message because you are subscribed to the Google
>>> Groups "Bitcoin Development Mailing List" group.
>>> > To unsubscribe from this group and stop receiving emails from it, sen=
d
>>> an email to bitcoindev+...@googlegroups.com.
>>> > To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/bitcoindev/ZgrCxWxMkiAt2Tg2%40camus.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Bitcoin Development Mailing List" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to bitcoindev+...@googlegroups.com.
>>>
>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/bitcoindev/06oL-GctrcLb99M_RuOgygXKMj=
tB_vPLHOCuc-axYrGVy_QBRGPu5wA9C2QXDb7cKIJbJu_t_JKmRrr9FsBORdUPavXPFvOi98p04=
UQuvuE%3D%40protonmail.com
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/bitcoindev/c1e32072-55ff-4cca-a56c-09c7=
47e7e4a6n%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/c1e32072-55ff-4cca-a56c-09c=
747e7e4a6n%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter>
> .
>

--=20
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/=
bitcoindev/CADL_X_c3YhyeqgsrFBVixpPOQWEacsa5cZUSK5uzLLNha9w%3D%2BQ%40mail.g=
mail.com.

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

<div dir=3D"ltr">There are no official rules; this is crypto anarchy. No on=
e can kill testnet3 or stop anyone from using it.<div><br></div><div>Howeve=
r, the only real &quot;principle&quot; of testnet (AFAIK) is that the coins=
 should be worthless in order to encourage freely sharing said coins with a=
nyone who needs them for development or testing purposes. Client implementa=
tions can choose to no longer support old versions of testnet in adherence =
to this principle.</div><div><br></div><div>The rough agreement, which hasn=
&#39;t been necessary to enforce for 13 years, is that testnet should get r=
eset any time it starts to have economic value. I propose that such rug pul=
ls should continue until everyone gets a clue that they&#39;re going to los=
e any money they put into it.</div></div><br><div class=3D"gmail_quote"><di=
v dir=3D"ltr" class=3D"gmail_attr">On Tue, Apr 2, 2024 at 3:05=E2=80=AFPM L=
uk=C3=A1=C5=A1 Kr=C3=A1=C4=BE &lt;<a href=3D"mailto:emsit@emsit.sk">emsit@e=
msit.sk</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef=
t:1ex"><p style=3D"border:0px solid rgb(227,227,227);box-sizing:border-box;=
margin:0px 0px 1.25em;color:rgb(13,13,13);font-family:S=C3=B6hne,ui-sans-se=
rif,system-ui,-apple-system,&quot;Segoe UI&quot;,Roboto,Ubuntu,Cantarell,&q=
uot;Noto Sans&quot;,sans-serif,&quot;Helvetica Neue&quot;,Arial,&quot;Apple=
 Color Emoji&quot;,&quot;Segoe UI Emoji&quot;,&quot;Segoe UI Symbol&quot;,&=
quot;Noto Color Emoji&quot;;font-size:16px">I think people will be very rel=
uctant to give up testnet3, including myself. I&#39;ve been running a testn=
et3 faucet for 10 years, distributing 327197.44 tBTC via the faucet + a few=
 thousand outside the faucet. Resetting the testnet will mean the end for m=
y faucet because I won&#39;t be mining new coins anymore. People who have t=
estnet3 will have to find a new way to obtain testnet4.</p><p style=3D"bord=
er:0px solid rgb(227,227,227);box-sizing:border-box;margin:1.25em 0px;color=
:rgb(13,13,13);font-family:S=C3=B6hne,ui-sans-serif,system-ui,-apple-system=
,&quot;Segoe UI&quot;,Roboto,Ubuntu,Cantarell,&quot;Noto Sans&quot;,sans-se=
rif,&quot;Helvetica Neue&quot;,Arial,&quot;Apple Color Emoji&quot;,&quot;Se=
goe UI Emoji&quot;,&quot;Segoe UI Symbol&quot;,&quot;Noto Color Emoji&quot;=
;font-size:16px">Are there any official rules for when a testnet reset will=
 occur? If I understand correctly, it&#39;s being considered because of the=
 &quot;price&quot; and the low mining reward? When testnet4 launches and st=
arts trading in a month, will testnet5 be launched shortly after...?</p><p =
style=3D"border:0px solid rgb(227,227,227);box-sizing:border-box;margin:1.2=
5em 0px 0px;color:rgb(13,13,13);font-family:S=C3=B6hne,ui-sans-serif,system=
-ui,-apple-system,&quot;Segoe UI&quot;,Roboto,Ubuntu,Cantarell,&quot;Noto S=
ans&quot;,sans-serif,&quot;Helvetica Neue&quot;,Arial,&quot;Apple Color Emo=
ji&quot;,&quot;Segoe UI Emoji&quot;,&quot;Segoe UI Symbol&quot;,&quot;Noto =
Color Emoji&quot;;font-size:16px">I would focus more on how to keep it inva=
luable and easily accessible to developers. I would definitely leave the tr=
ansitional phase for at least a year, and the BTC client should have parame=
ters for both -testnet3 and -testnet4. Personally, <b>I think the adoption =
of testnet4 will be very slow</b>.</p><br><div class=3D"gmail_quote"><div d=
ir=3D"auto" class=3D"gmail_attr">D=C3=A1tum: utorok 2. apr=C3=ADla 2024, =
=C4=8Das: 14:00:40 UTC+2, odosielate=C4=BE: Jameson Lopp<br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">I think Andrew&#3=
9;s difficulty rule suggestions are the least invasive and make sense for f=
ixing the block storm issue while keeping the code changes to the logic tha=
t is already conditional to testnet. Though even with those rules I think i=
t would still be possible, though far less likely, for the difficulty to ge=
t permanently reset very low unless we also implement the difficulty adjust=
ment patch Fabian mentioned.<div><br></div><div>I suspect that creating a &=
quot;fair&quot; faucet is an unsolvable problem: the only robust way to gat=
e free giveaways (much like airdrops) is to impose an economic cost on clai=
ming them, which is against the spirit=C2=A0of testnet.</div><div><br></div=
><div>As emsit and I both noted, 13 years without a reset means that it wou=
ld be courteous to give testnet operators a reasonably long heads up to pre=
pare. Perhaps 6 months or 1 year lead time?</div></div><br><div class=3D"gm=
ail_quote"></div><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail=
_attr">On Mon, Apr 1, 2024 at 6:06=E2=80=AFPM &#39;Fabian&#39; via Bitcoin =
Development Mailing List &lt;<a rel=3D"nofollow">bitco...@googlegroups.com<=
/a>&gt; wrote:<br></div></div><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">Hi,<br>
<br>
removing the special rule and moving to a reduced block interval sounds lik=
e a good and simple solution.<br>
<br>
Another idea: Keep the current exception logic and adapt the difficulty adj=
ustment code (`CalculateNextWorkRequired`) to look for the last block that =
didn&#39;t have difficulty 1 and use that block&#39;s difficulty as the bas=
is for the new difficulty calculation. It seemed like the most intuitive fi=
x to me when I looked at the code after reading Jameson&#39;s first email (=
see <a href=3D"https://github.com/bitcoin/bitcoin/pull/29775/commits/991354=
9637706749f0af5d326f949bd652cbd5f8" rel=3D"noreferrer nofollow" target=3D"_=
blank">https://github.com/bitcoin/bitcoin/pull/29775/commits/99135496377067=
49f0af5d326f949bd652cbd5f8</a>).<br>
<br>
Best,<br>
Fabian<br>
<br>
<br>
<br>
On Monday, April 1st, 2024 at 4:20 PM, Andrew Poelstra &lt;<a rel=3D"nofoll=
ow">apoe...@wpsoftware.net</a>&gt; wrote:<br>
<br>
&gt; On Mon, Apr 01, 2024 at 01:37:59PM +0000, Pieter Wuille wrote:<br>
&gt; <br>
&gt; &gt; As for using other measures to prevent too large difficulty varia=
tions... I&#39;m not sure that&#39;s desirable, because it always cuts both=
 ways (nicely demonstrated by the &quot;allow difficulty 1 rule&quot; on te=
stnet3 backfiring and enabling block storms!). For applications that actual=
ly need very predictable block rate, there is signet. For others, just the =
normal mainnet rules are probably not too terrible. I would be ok with havi=
ng a somewhat reduced block interval (say a few days instead of 2 weeks) if=
 that&#39;s not deemed to complex to implement across the ecosystem, but I =
don&#39;t think it&#39;s that important.<br>
&gt; <br>
&gt; <br>
&gt; I really like this. For my part (rust-bitcoin) this would be as simple=
<br>
&gt; as adding an extra parameter to my blockparams structure. Possibly one=
<br>
&gt; already exists, I&#39;d have to check.<br>
&gt; <br>
&gt; This would be much easier than the existing situation where we have<br=
>
&gt; special-case logic for testnet the difficulty-1 target.<br>
&gt; <br>
&gt; It would also limit the amount of bikeshedding possible, since there<b=
r>
&gt; aren&#39;t too many conflicting goals regarding the retargeting window=
...<br>
&gt; unlike tweaking the existing logic where there&#39;s a tradeoff betwee=
n<br>
&gt; &quot;we should make this never happen&quot; and &quot;it should happe=
n often enough<br>
&gt; that it doesn&#39;t break people&#39;s code&quot; and &quot;it should =
happen if blocks<br>
&gt; slow down to like, 1/50th their normal rate even if they are still<br>
&gt; technically being produced&quot; and &quot;it shouldn&#39;t be possibl=
e to trigger<br>
&gt; it within the 2-hour timestamp-faking window&quot; etc. And questions<=
br>
&gt; about whether we should fix/redesign the interaction between the reset=
<br>
&gt; rule and the normal difficulty retarget.<br>
&gt; <br>
&gt; <br>
&gt; OTOH, since we already have the special logic, I&#39;d also be happy w=
ith<br>
&gt; tweaking the existing rule. My specific proposal (after reading Jameso=
n&#39;s<br>
&gt; post, which has some nice graphs of difficulty) would be<br>
&gt; <br>
&gt; * increase the reset threshold from 20 minutes to 6 hours, which is<br=
>
&gt; (a) well outside the 2-hour window in which miners can easily fake<br>
&gt; timestamps, and (b) will basically never be hit by accident<br>
&gt; * increase the reset difficulty from 1 to 1MM, which is an rough lower=
<br>
&gt; bound on the &quot;normal&quot; testnet difficulty seen historically<b=
r>
&gt; <br>
&gt; Which puts us in the &quot;this rule would never be triggered unless<b=
r>
&gt; literally everyone stopped mining&quot; corner of the design space.<br=
>
&gt; <br>
&gt; <br>
&gt; --<br>
&gt; Andrew Poelstra<br>
&gt; Director of Research, Blockstream<br>
&gt; Email: apoelstra at <a href=3D"http://wpsoftware.net" rel=3D"noreferre=
r nofollow" target=3D"_blank">wpsoftware.net</a><br>
&gt; Web: <a href=3D"https://www.wpsoftware.net/andrew" rel=3D"noreferrer n=
ofollow" target=3D"_blank">https://www.wpsoftware.net/andrew</a><br>
&gt; <br>
&gt; The sun is always shining in space<br>
&gt; -Justin Lewis-Webster<br>
&gt; <br>
&gt; --<br>
&gt; You received this message because you are subscribed to the Google Gro=
ups &quot;Bitcoin Development Mailing List&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an email to <a rel=3D"nofollow">bitcoindev+...@googlegroups.com</a>.<br>
&gt; To view this discussion on the web visit <a href=3D"https://groups.goo=
gle.com/d/msgid/bitcoindev/ZgrCxWxMkiAt2Tg2%40camus" rel=3D"noreferrer nofo=
llow" target=3D"_blank">https://groups.google.com/d/msgid/bitcoindev/ZgrCxW=
xMkiAt2Tg2%40camus</a>.<br>
<br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">bitcoindev+...@googlegroups.com</a>.<br></block=
quote></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex">
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/06oL-GctrcLb99M_RuOgygXKMjtB_vPLHOCuc-axYrGVy_QBRGPu5=
wA9C2QXDb7cKIJbJu_t_JKmRrr9FsBORdUPavXPFvOi98p04UQuvuE%3D%40protonmail.com"=
 rel=3D"noreferrer nofollow" target=3D"_blank">https://groups.google.com/d/=
msgid/bitcoindev/06oL-GctrcLb99M_RuOgygXKMjtB_vPLHOCuc-axYrGVy_QBRGPu5wA9C2=
QXDb7cKIJbJu_t_JKmRrr9FsBORdUPavXPFvOi98p04UQuvuE%3D%40protonmail.com</a>.<=
br>
</blockquote></div>
</blockquote></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com" target=
=3D"_blank">bitcoindev+unsubscribe@googlegroups.com</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/c1e32072-55ff-4cca-a56c-09c747e7e4a6n%40googlegroups.=
com?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">https://g=
roups.google.com/d/msgid/bitcoindev/c1e32072-55ff-4cca-a56c-09c747e7e4a6n%4=
0googlegroups.com</a>.<br>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/CADL_X_c3YhyeqgsrFBVixpPOQWEacsa5cZUSK5uzLLNha9w%3D%2=
BQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.=
google.com/d/msgid/bitcoindev/CADL_X_c3YhyeqgsrFBVixpPOQWEacsa5cZUSK5uzLLNh=
a9w%3D%2BQ%40mail.gmail.com</a>.<br />

--0000000000001f0fa90615225dd4--