Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 23E1AE99 for ; Fri, 31 Aug 2018 00:06:24 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vk0-f47.google.com (mail-vk0-f47.google.com [209.85.213.47]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0E234720 for ; Fri, 31 Aug 2018 00:06:22 +0000 (UTC) Received: by mail-vk0-f47.google.com with SMTP id i2-v6so3041090vkg.3 for ; Thu, 30 Aug 2018 17:06:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3IUKFk7r+cwkfiu/dQRhh2bJU2UhLMzXkJ3PyHE7fyw=; b=Wc9iwo/sX3zHVkSyEgk6j2OnGy5a6jxtYG1oN9VPmtoXzibhI/hoCk9z/Owxg1RZ4K rHgMbGlOt/RSGTBDExgDhNGE6B2EnuiE+MSaL/dcsdBEF2k4M1kQKWSnTrVfx/dgMszp 2nNGfMjnqYR+6ElLMhpcxHx780qhZfm+2jyQL4wb6o7h35LtijIDUv/gM6f3/QmF0OJ9 WYCXgh96RWkC0yAGhrC9fml6dpunB75pcwkWEMXhVgwiuwV02cnX3a36sPs6XOMwxJgH OoP3CAPNET5dF/1SN0gG92jgurEVeUaX97lGTWWqf4BBPLqYjiuRqypSMlTWEowLVUtb A1EQ== X-Gm-Message-State: APzg51C4JWNcxrndCoMehOyZthHwvuuSSEnzgGXoOenDJzWDiIgadyxH UHlnDum+V4XeZSg2kOh67I/sQqzDiuicDc+/ReQ= X-Google-Smtp-Source: ANB0VdakaVF4TX6HR566WQEYKA28jdb6LyTlAyxSBjKkqDVkBlNMhNdMSNyBI2xYOA6Yv167q9B4DirihNbYYnGtSAQ= X-Received: by 2002:a1f:2413:: with SMTP id k19-v6mr7815566vkk.128.1535673982124; Thu, 30 Aug 2018 17:06:22 -0700 (PDT) MIME-Version: 1.0 References: <20180830200239.ujuzh7pitcuatdt3@petertodd.org> <7E247E56-38A5-4B99-941A-A2CC837D2567@xbt.hk> In-Reply-To: <7E247E56-38A5-4B99-941A-A2CC837D2567@xbt.hk> From: Gregory Maxwell Date: Fri, 31 Aug 2018 00:06:06 +0000 Message-ID: To: jl2012 , Bitcoin Dev Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Fri, 31 Aug 2018 12:39:49 +0000 Cc: shiva sitamraju Subject: Re: [bitcoin-dev] Testnet3 Reest X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2018 00:06:24 -0000 On Thu, Aug 30, 2018 at 11:21 PM Johnson Lau via bitcoin-dev wrote: > A public testnet is still useful so in articles people could make references to these transactions. > Maybe we could have 2 testnets at the same time, with one having a smaller block size? I would much rather have a signed blocks testnet, with a predictable structured reorg pattern* (and a config flag so you can make your node ignore all blocks that are going to get reorged out in a reorg of nth or larger). There are many applications where the mined testnet just doesn't give you anything useful... it's too stable when you want it to be a bit unstable and too wildly unstable when you want a bit of stability-- e.g. there are very few test cases where a 20,000 block reorg does anything useful for you; yet they happen on testnet. We looked at doing this previously in Bitcoin core and jtimon had some patches, but the existing approach increased the size of the blockindex objects in memory while not in signed testnet mode. This could probably have been fixed by turning one of the fields like the merkel root into a union of it's normal value and a pointer a look-aside block index that is used only in signed block testnet mode. Obviously such a mode wouldn't be a replacement for an ordinary testnet, but it would be a useful middle ground between regtest (that never sees anything remotely surprising and can't easily be used for collaborative testing) and full on testnet where your attempts to test against ordinary noise require you cope your entirely universe being removed from existence and replaced by something almost but not quite entirely different at the whim of some cthulhuian blind idiot god.