Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 803A0C0039 for ; Fri, 17 Nov 2023 07:58:46 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 55D3F42C8D for ; Fri, 17 Nov 2023 07:58:46 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 55D3F42C8D X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 pW6JSGkazOLl for ; Fri, 17 Nov 2023 07:58:45 +0000 (UTC) Received: from cerulean.erisian.com.au (azure.erisian.com.au [172.104.61.193]) by smtp4.osuosl.org (Postfix) with ESMTPS id 1762F42C58 for ; Fri, 17 Nov 2023 07:58:44 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 1762F42C58 Received: from aj@azure.erisian.com.au by cerulean.erisian.com.au with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1r3tkN-0002qB-TD; Fri, 17 Nov 2023 17:58:42 +1000 Received: by email (sSMTP sendmail emulation); Fri, 17 Nov 2023 17:58:34 +1000 Date: Fri, 17 Nov 2023 17:58:34 +1000 From: Anthony Towns To: Bitcoin Protocol Discussion Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam_score: -0.0 X-Spam_bar: / Cc: Casey Rodarmor Subject: Re: [bitcoin-dev] Purely off-chain coin colouring 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, 17 Nov 2023 07:58:46 -0000 On Sat, Feb 04, 2023 at 08:38:54PM +1000, Anthony Towns via bitcoin-dev wrote: > > AJ Towns writes: > > > I think, however, that you can move inscriptions entirely off-chain. I > > > wrote a little on this idea on twitter already [1], but after a bit more > > > thought, I think pushing things even further off-chain would be plausible. Oh, you could also do inscriptions minimally on-chain. Rather than posting the inscription on-chain per se, take a hash of the data you want to inscribe, and then do a sign-to-contract commitment of that hash. That reduces your on-chain overhead for creating an inscription to approximately zero (you're just signing a transaction), so can be much cheaper, and also can't be blocked or front run by mempool observers. But obviously means the inscription must be announced off-chain for anyone to know about it. Of course, that could be seen as a benefit: you can now have a private inscription, that's still transferable via the regular ordinals protocol. OTOH, there's no way to definitvely say "this tx is the Nth inscription that matches pattern X", as there may be many earlier sign-to-contract inscriptions that match that pattern that simply haven't been publicly revealed yet. So that wouldn't be compatible with "inscription numbers" or "first X inscripts count as minting token Y". If you go one step further and allow the sign-to-contract to be the merkle root of many inscriptions, then you've effectively reinvented timestamping. (You can't outsource inscriptions to a timestamp server, because you'd fail to own the ordinal that indicates "ownership" of the inscription, however you could provide timestamping services as a value-add while creating inscriptions) Sign-to-contract looks like: * generate a secret random nonce r0 * calculate the public version R0 = r0*G * calculate a derived nonce r = r0 + SHA256(R0, data), where "data" is what you want to commit to * generate your signature using public nonce R=r*G as usual To be able to verify sign-to-contract, you reveal R0 and data, and the verification is just checking that R=R0+SHA256(R0, data)*G. That works with both ecdsa and schnorr signatures, so doesn't require any advance preparation. While it's not widely supported, sign-to-contract is a useful feature in general for anti-exfil (eg, preventing a malicious hardware wallet from leaking your secret key when signing txs). Some references: https://www.reddit.com/r/Bitcoin/comments/d3lffo/technical_paytocontract_and_signtocontract/ https://github.com/BlockstreamResearch/secp256k1-zkp/blob/d22774e248c703a191049b78f8d04f37d6fcfa05/include/secp256k1_ecdsa_s2c.h https://github.com/bitcoin-core/secp256k1/pull/1140 https://wally.readthedocs.io/en/release_0.8.9/anti_exfil_protocol/ https://github.com/opentimestamps/python-opentimestamps/pull/14 Cheers, aj