From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 7C8EBC000A for ; Fri, 16 Apr 2021 20:48:52 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 5644183AA7 for ; Fri, 16 Apr 2021 20:48:52 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 1.3 X-Spam-Level: * X-Spam-Status: No, score=1.3 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=q32-com.20150623.gappssmtp.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 cutL5N7m2LHw for ; Fri, 16 Apr 2021 20:48:47 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) by smtp1.osuosl.org (Postfix) with ESMTPS id A9F8B832C6 for ; Fri, 16 Apr 2021 20:48:47 +0000 (UTC) Received: by mail-pf1-x42d.google.com with SMTP id h15so1425846pfv.2 for ; Fri, 16 Apr 2021 13:48:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=q32-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=PznL/QrWHEc64Adt3HM5CI815N9al3ttwRmWElwfpKA=; b=kHkwc5t5UpAAK+yCXCm9a64KvnuOAi5b1aef4q4g2HPj34aDYQgDNP/ks9fc8oPBAt Mu8MF0nvPqHmJ1nsLkNnTGjM4q7NNsVmDsKtm3CBh/Qh5LmixOk0IBEe8k57QgbS8wiQ UWHikKdN7DdM1RL7DTE5xoZdeucWBQSqFA749SjtfpYL3mqFe6FxD5Uf2wzBULmwdE37 8k1QZpfl2BXMg3OYH/3A6EYydujFKWN+1XPivrPvBTf76jW9IaHl+AXTfHDcC/UP+ShE v72OdB90RmkUEw/sDkj/2NqFNVS2DvwfHhx/cSx1qSm6p+a9IrkEPjPE5+UcPeN2jZwt rjpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=PznL/QrWHEc64Adt3HM5CI815N9al3ttwRmWElwfpKA=; b=RGkQB6mJZqQkOid5EiqUBYGSyZDx71UdFntKh/S9HbtSwtD0sZTaORsBRcTXIAJsL9 MZinfwGA0PIPbtZi7GDciH3UAnGNJWoSwSPas6q6q5Hg+K3Wn3NvM6qzarKm2H4q/yU6 YM63BEhqgpiZWZw3W0TYQdHDUzP1zcse6TH/eSXFrDogCiTrqcODmJ+rkj5uCZWVQVEU 1sElmYqQ2WcAxJ4QYoWc+lWTu0Sl5RLJd09UN3e0kKnWlhhVni7thzamLWxMHKW3jGEz 9RL/2U7MVK6qRk++ZOcyOGpX6E7TOZqlF+YiwoTs+0aPMoN+HXwoF3o0A3gKHTPYofOi 9XJQ== X-Gm-Message-State: AOAM530SnLjwuiEKjZoCjuj+22oCTVcxMf3ifbhPgYOqGd9ekhOorxaF gqWCmrZsaM7KpgkUIvHZArfaY/ciGEuUvNNSHpkXrse33hRQjKrFGw== X-Google-Smtp-Source: ABdhPJwejK01K004TdPvTyOdlsTtw4Fzncx7bGwUP144vUXd/G6q648NhGbamribh32kjRVpsS+rjaCIOLOOu94dtzQ= X-Received: by 2002:aa7:908c:0:b029:209:aacd:d8b with SMTP id i12-20020aa7908c0000b0290209aacd0d8bmr9466500pfa.74.1618606126875; Fri, 16 Apr 2021 13:48:46 -0700 (PDT) MIME-Version: 1.0 From: Erik Aronesty Date: Fri, 16 Apr 2021 16:48:35 -0400 Message-ID: To: Bitcoin Protocol Discussion Content-Type: text/plain; charset="UTF-8" X-Mailman-Approved-At: Fri, 16 Apr 2021 21:08:06 +0000 Subject: [bitcoin-dev] Gradual transition to an alternate proof without a hard fork. 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: Fri, 16 Apr 2021 20:48:52 -0000 Not sure of the best place to workshop ideas, so please take this with a grain of salt. Starting with 3 assumptions: - assume that there exists a proof-of-burn that, for Bitcoin's purposes, accurately-enough models the investment in and development of ASICs to maintain miner incentive. - assume the resulting timing problem "how much burn is enough to keep blocks 10 minutes apart and what does that even mean" is also... perfectly solvable - assume "everyone unanimously loves this idea" The transition *could* look like this: - validating nodes begin to require proof-of-burn, in addition to proof-of-work (soft fork) - the extra expense makes it more expensive for miners, so POW slowly drops - on a predefined schedule, POB required is increased to 100% of the "required work" to mine Given all of that, am I correct in thinking that a hard fork would not be necessary? IE: We could transition to another "required proof" - such as a quantum POW or a POB (above) or something else .... in a back-compat way (existing nodes not aware of the rules would continue to validate).