Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id C0F2DC0032 for ; Fri, 4 Aug 2023 22:33:19 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 77A2983F15 for ; Fri, 4 Aug 2023 22:33:19 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 77A2983F15 Authentication-Results: smtp1.osuosl.org; dkim=pass (1024-bit key) header.d=reardencode.com header.i=@reardencode.com header.a=rsa-sha256 header.s=mail header.b=souCSGtE X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.201 X-Spam-Level: X-Spam-Status: No, score=-0.201 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 yliiNFfWtZ0u for ; Fri, 4 Aug 2023 22:33:18 +0000 (UTC) X-Greylist: delayed 325 seconds by postgrey-1.37 at util1.osuosl.org; Fri, 04 Aug 2023 22:33:18 UTC DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 9DA0B838E0 Received: from mail.reardencode.com (mail.reardencode.com [206.125.169.165]) by smtp1.osuosl.org (Postfix) with ESMTPS id 9DA0B838E0 for ; Fri, 4 Aug 2023 22:33:18 +0000 (UTC) Date: Fri, 4 Aug 2023 15:27:17 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=reardencode.com; s=mail; t=1691188071; bh=YmxLPjwlqP88HlqsZeYW5xfLL21qgbMsRdQZ7OIRNGk=; h=Date:From:To:Subject:References:In-Reply-To; b=souCSGtEt8COdL2yMv02Y6xDVMPdc5K/41kwMVS9S1qCED+UgMShNhfF7Wy40I9ZD Ud5slr08nI/yumgzXfT6wGWDR/pkn3A0pzauIxFt4VSzri+Wwrtp9w79ytys+/arVz gvJrkTGbEg0071NjwQrCmq4vzUNaak2c81OdbE+w= From: Brandon Black To: Peter Todd , Bitcoin Protocol Discussion Message-ID: Mail-Followup-To: Peter Todd , Bitcoin Protocol Discussion References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Linux 5.15.110 x86_64 X-Mailman-Approved-At: Sat, 05 Aug 2023 12:21:15 +0000 Subject: Re: [bitcoin-dev] BIP-352 Silent Payments addresses should have an expiration time 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, 04 Aug 2023 22:33:19 -0000 I agree. Non-expiring addresses are a significant risk to bitcoin users. On 2023-08-04 (Fri) at 17:39:03 +0000, Peter Todd via bitcoin-dev wrote: > Fixing this is easy: add a 3 byte field to silent payments addresses, encoding > the expiration date in terms of days after some epoch. 2^24 days is 45,000 > years, more than enough. Indeed, 2 bytes is probably fine too: 2^16 days is 180 > years. We'll be lucky if Bitcoin still exists in 180 years. Instead of a fixed width nDays, consider a custom compact encoding with the position of the first 0-bit indicating the number of extension bytes and the encoded granularity. bytes | prefix | usable bits | granularity | max expiration ------|------------|-------------|-------------|--------------- 1 | 0b0 | 7 | year | 128 years 2 | 0b10 | 14 | week | 315 years 3 | 0b110 | 21 | day | 5700 years 4 | 0b1110 | 28 | block | 5100 years 5 | 0b11110 | 35 | ??? | ??? 6 | 0b111110 | 42 | ??? | ??? 7 | 0b1111110 | 49 | ??? | ??? 8 | 0b11111110 | 56 | ??? | ??? For address expiration, year or week expiration will typically be sufficiently granular, but for rare occasions more granularity can be encoded with longer addresses. This method also degrades cleanly even if the same address format is still in use in 100 or 300 years. I included block-based expiration to enable SP users to match CLTVs embedded in their scripts, e.g. <2 years> OP_CLTV OP_VAULT_RECOVER or <2 years> OP_CLTV OP_CHECKSIG Best, --Brandon