Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id C45C2C0037 for ; Thu, 30 Nov 2023 23:17:59 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 9347F4022F for ; Thu, 30 Nov 2023 23:17:59 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 9347F4022F Authentication-Results: smtp4.osuosl.org; dkim=pass (1024-bit key) header.d=reardencode.com header.i=@reardencode.com header.a=rsa-sha256 header.s=mail header.b=JnjX+bl2 X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.307 X-Spam-Level: X-Spam-Status: No, score=-1.307 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, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id agzW_j8A69z0 for ; Thu, 30 Nov 2023 23:17:57 +0000 (UTC) X-Greylist: delayed 311 seconds by postgrey-1.37 at util1.osuosl.org; Thu, 30 Nov 2023 23:17:56 UTC DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 6026140209 Received: from mail.reardencode.com (unknown [IPv6:2607:f2f8:ad40:ea11::1]) by smtp4.osuosl.org (Postfix) with ESMTPS id 6026140209 for ; Thu, 30 Nov 2023 23:17:56 +0000 (UTC) Date: Thu, 30 Nov 2023 15:12:05 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=reardencode.com; s=mail; t=1701385959; bh=5gow6rSNP23L2ZMPYD61T1noELJjmmu6eKxs/7hZrgg=; h=Date:From:To:Subject:References:In-Reply-To; b=JnjX+bl2Nu1MVvDXvHsUuRb8rmB9RbapzA+Q5Cq+vcPc5xelWWGcvxSqUTU8/RVbO aPsXQm4wyD3ioADteeYt1CqJevEnDw92KZZva+Asc2M7IxLFL4I1I55mIK75jcoa+X pdsn1LUts25LvNHqBIUPROtaMOEQNwdGMxdMYGBE= From: Brandon Black To: SeedHammer Team , Bitcoin Protocol Discussion Message-ID: Mail-Followup-To: SeedHammer Team , Bitcoin Protocol Discussion References: <_pNFQS1xsa8HZF-9x3hk8EBZRfYAbzCAha1rKaFbwpfqMqjK51rGQspALrdYvB0R0r90iReLLsktJOfFowJG-wkX3E1NvPwtEQyMT95uo_4=@seedhammer.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <_pNFQS1xsa8HZF-9x3hk8EBZRfYAbzCAha1rKaFbwpfqMqjK51rGQspALrdYvB0R0r90iReLLsktJOfFowJG-wkX3E1NvPwtEQyMT95uo_4=@seedhammer.com> X-Operating-System: Linux 5.15.110 x86_64 X-Mailman-Approved-At: Fri, 01 Dec 2023 00:27:48 +0000 Subject: Re: [bitcoin-dev] A proposal for a "PSBT for descriptors" format 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: Thu, 30 Nov 2023 23:17:59 -0000 Hi Seedhammer, I think the goal of such a format should be that it is already a valid PSBT, or can be trivially converted into one. Ideally, a coordinating device can load the standardized descriptor file, add inputs (PSBTv2) or unsigned TX (PSBTv1), and send it to compatible signing devices without further modification. Seems like the additions to BIP174 would be a PSBT_GLOBAL_DESCRIPTOR with key of | and value of the descriptor encoded as proposed, and then PSBT_GLOBAL_KEY_NAME with key of and value of . Best, --Brandon On 2023-11-23 (Thu) at 22:25:43 +0000, SeedHammer Team via bitcoin-dev wrote: > Hi, > > At SeedHammer we're interested in standard, compact output descriptors to make > self-contained metal engraved backups feasible. To that end, we're proposing a > descriptor format based on the PSBT binary encoding. The format has not reached > widespread consensus, never mind adoption, so at this point we're soliciting > comments before formally proposing it as a BIP. > > See [proposal], [implementation] and [playground] for details and examples. > > The format is a binary and compact serialization specification for the > [wallet-policies] BIP. Features: > > - Based on the binary [BIP174] PSBT format, including re-using the compact > PSBT_GLOBAL_XPUB encoding for extended keys. > - The descriptor itself is encoded in the same textual format as described > in BIPs 380-386 (+389). > - Key references (always) use the wallet-policies format @. > - Miniscript is trivially supported, except inline keys are not allowed, and > pk(NAME) expressions are replaced with indexed (@) key references. > - Metadata such as labels and birthdate blocks are encoded as PSBT > map entries. > > Known issues: > > - CBOR vs PSBT. Blockchain Commons believes[0] that a CBOR based format is better > because it is a widely used binary encoding standard, whereas we believe the > complexity of CBOR doesn't justify its cost compared to the PSBT encoding > already widely supported by wallet software. > - The proposal specifies a separate header and magic; should the format instead be > an extension to the PSBT format? > > Thanks, > E > > [proposal] https://github.com/BlockchainCommons/Research/issues/135 > [implementation] https://github.com/seedhammer/bip-serialized-descriptors > [playground] https://go.dev/play/p/nouZlbbcEWt > [wallet-policies] https://github.com/bitcoin/bips/blob/bb98f8017a883262e03127ab718514abf4a5e5f9/bip-wallet-policies.mediawiki > [BIP174] https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki > > [0] https://github.com/BlockchainCommons/Research/issues/135#issuecomment-1789644032 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev