From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <0xb10c@gmail.com> Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id C6F11C000D for ; Tue, 7 Sep 2021 16:07:55 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id C32BD81025 for ; Tue, 7 Sep 2021 16:07:55 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvyaVGyC8MWY for ; Tue, 7 Sep 2021 16:07:51 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) by smtp1.osuosl.org (Postfix) with ESMTPS id E59BF80DE9 for ; Tue, 7 Sep 2021 16:07:50 +0000 (UTC) Received: by mail-wm1-x334.google.com with SMTP id i3so7248786wmq.3 for ; Tue, 07 Sep 2021 09:07:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:subject:to:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=ZiTxmdq8kU5AYAwVFvqamMZWjAXRuN1u++9XidUlhjQ=; b=UQ5ZI8SBPB8VDzylJJVlu2uAwoM2jG01BXe5ShX0DkWN/8ex7ArQbV/n4EoD6Yat/x S/31vzLgv2CJn1V4HRNKU0k7dBMZFY5u9R/GJkVgB6pARJtG6RLN6UKFkreaASEsCBof NP2eBjvods8ozoQtTSAAB1CCpUwjS6zK58pnrUfBJG7CRIx5L9TLJ8EBG/t0NjsfXJ7d V46yKFiiVvoTAYpYMHWDUU6dTY/ixqgWTPErzmNo7BV399OXZeDhiBukmoMElxmselJ7 X9ySFP1aso5b7x+zAu14dBr/3DNWzRvn6An8Chrdu53mWS/Ivf43DPtPfd2eR2IRoRKT rtQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=ZiTxmdq8kU5AYAwVFvqamMZWjAXRuN1u++9XidUlhjQ=; b=ByN2sdl1OuYIrtrnvot/AUdhD+ZGkyNherak7lk7cDtV/mIj11uWOlTrA7QWA3s7EA nR0oUfvrtc+Lx1UkSs/lZsttF2fKkjbmRCaVL1sawcW8XILcCBX+zEMgUfQR4U2UXaWU 6mjHlT36mPNM5CCMIm9TTtXAHrqOSrpnq+QclKHn7SgoyQSjEMVQa3rCMCFT1oHtK9Qz WDC/cSf+IaLdwafBfyAVMAX0uU/BOtmQe4pGC2+wpQSrBjDOu9oyHHWnuVyR1Fat2E2m S1L7e/1aLbuaIFL/1RNY3xQ2x47jlYO4UTJ0pqVK3wgVuU0lLUCmcQpRsECzk+a9AKy2 fmug== X-Gm-Message-State: AOAM532w4C2Anjj+35gsLZNzMQJcDzVi39QcF8eUNxiN1eXOAn//PVT9 CW8OnEIQ5h250H5gA3GDzTNBGnullo0rww== X-Google-Smtp-Source: ABdhPJzT2mY/anVnG8Vc4UyphTPaM6JGFMPd2ZWpaSzNOSrj3JqbTYLNbXqaMBPn/zsqQ7oydJwn5A== X-Received: by 2002:a7b:cbcd:: with SMTP id n13mr4694416wmi.49.1631030868645; Tue, 07 Sep 2021 09:07:48 -0700 (PDT) Received: from [192.168.178.28] (fttx-pool-185.76.98.156.bambit.de. [185.76.98.156]) by smtp.gmail.com with ESMTPSA id s1sm11523312wrs.53.2021.09.07.09.07.48 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 07 Sep 2021 09:07:48 -0700 (PDT) From: 0xB10C <0xb10c@gmail.com> To: bitcoin-dev@lists.linuxfoundation.org Message-ID: <83272afb-ed87-15b6-e02c-16bb1102beb4@gmail.com> Date: Tue, 7 Sep 2021 18:07:47 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Mailman-Approved-At: Tue, 07 Sep 2021 16:11:49 +0000 Subject: [bitcoin-dev] Reorgs on SigNet - Looking for feedback on approach and parameters X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2021 16:07:55 -0000 Hello, tl;dr: We want to make reorgs on SigNet a reality and are looking for feedback on approach and parameters. One of the ideas for SigNet is the possibility for it to be reliably unreliable, for example, planned chain reorganizations. These have not been implemented yet. My summerofbitcoin.org mentee Nikhil Bartwal and I have been looking at implementing support for reorgs on SigNet. We are looking for feedback on which approach and parameters to use. Please consider answering the questions below if you or your company is interested in chain reorganizations on SigNet. With feedback from AJ and Kalle Alm (thanks again!), we came up with two scenarios that could be implemented in the current SigNet miner script [0]. Both would trigger automatically in a fixed block interval. Scenario 1 simulates a race scenario where two chains compete for D blocks. Scenario 2 simulates a chain rollback where the top D blocks get replaced by a chain that outgrows the earlier branch. AJ proposed to allow SigNet users to opt-out of reorgs in case they explicitly want to remain unaffected. This can be done by setting a to-be-reorged version bit flag on the blocks that won't end up in the most work chain. Node operators could choose not to accept to-be-reorged SigNet blocks with this flag set via a configuration argument. The reorg-interval X very much depends on the user's needs. One could argue that there should be, for example, three reorgs per day, each 48 blocks apart. Such a short reorg interval allows developers in all time zones to be awake during one or two reorgs per day. Developers don't need to wait for, for example, a week until they can test their reorgs next. However, too frequent reorgs could hinder other SigNet users. We propose that the reorg depth D is deterministically random between a minimum and a maximum based on, e.g., the block hash or the nonce of the last block before the reorg. Compared to a local randint() based implementation, this allows reorg-handling tests and external tools to calculate the expected reorg depth. # Scenario 1: Race between two chains For this scenario, at least two nodes and miner scripts need to be running. An always-miner A continuously produces blocks and rejects blocks with the to-be-reorged version bit flag set. And a race-miner R that only mines D blocks at the start of each interval and then waits X blocks. A and R both have the same hash rate. Assuming both are well connected to the network, it's random which miner will first mine and propagate a block. In the end, the A miner chain will always win the race. # Scenario 2: Chain rollback This scenario only requires one miner and Bitcoin Core node but also works in a multiminer setup. The miners mine D blocks with the to-be-reorged version bit flag set at the start of the interval. After allowing the block at height X+D to propagate, they invalidate the block at height X+1 and start mining on block X again. This time without setting the to-be-reorged version bit flag. Non-miner nodes will reorg to the new tip at height X+D+1, and the first-seen branch stalls. # Questions     1. How do you currently test your applications reorg handling? Do the two discussed scenarios (race and chain rollback) cover your needs? Are we missing something you'd find helpful?     2. How often should reorgs happen on the default SigNet? Should there be multiple reorgs a day (e.g., every 48 or 72 blocks assuming 144 blocks per day) as your engineers need to be awake? Do you favor less frequent reorgs (once per week or month)? Why? 3. How deep should the reorgs be on average? Do you want to test deeper reorgs (10+ blocks) too? # Next Steps We will likely implement Scenario 1, the race between two chains, first. We'll set up a public test-SigNet along with a faucet, block explorer, and a block tree visualization. If there is interest in the second approach, chain rollbacks can be implemented too. Future work will add the possibility to include conflicting transactions in the two branches. After enough testing, the default SigNet can start to do periodical reorgs, too. Thanks, 0xB10C [0]: https://github.com/bitcoin/bitcoin/blob/master/contrib/signet/miner