From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 6519CCA5 for ; Mon, 12 Aug 2019 14:40:30 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail149056.authsmtp.com (outmail149056.authsmtp.com [62.13.149.56]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B3F938A0 for ; Mon, 12 Aug 2019 14:40:28 +0000 (UTC) Received: from punt24.authsmtp.com (punt24.authsmtp.com [62.13.128.105]) by punt18.authsmtp.com. (8.15.2/8.15.2) with ESMTP id x7CEeQQb017273 for ; Mon, 12 Aug 2019 15:40:26 +0100 (BST) (envelope-from user@petertodd.org) Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237]) by punt24.authsmtp.com. (8.15.2/8.15.2) with ESMTP id x7CEeQd5055654; Mon, 12 Aug 2019 15:40:26 +0100 (BST) (envelope-from user@petertodd.org) Received: from petertodd.org (ec2-52-5-185-120.compute-1.amazonaws.com [52.5.185.120]) (authenticated bits=0) by mail.authsmtp.com (8.15.2/8.15.2) with ESMTPSA id x7CEeO1p010794 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 12 Aug 2019 15:40:25 +0100 (BST) (envelope-from user@petertodd.org) Received: from [127.0.0.1] (localhost [127.0.0.1]) by petertodd.org (Postfix) with ESMTPSA id 5C83340148; Mon, 12 Aug 2019 14:40:24 +0000 (UTC) Received: by localhost (Postfix, from userid 1000) id 1642B21A53; Mon, 12 Aug 2019 10:40:23 -0400 (EDT) Date: Mon, 12 Aug 2019 10:40:23 -0400 From: Peter Todd To: Bryan Bishop , Bitcoin Protocol Discussion Message-ID: <20190812144023.4mixitkcsrvpb7i6@petertodd.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3p2sitlo2zuzyi5i" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) X-Server-Quench: 1f5e1997-bd0f-11e9-b106-8434971169dc X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZIVwkA IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdwAUGUATAgsB Am8bWlFeVF17W2Y7 bghPaBtcak9QXgdq T0pMXVMcXAIbdEl+ B14eUxl1fgEIf35x YQhjCHUOXU1zclsv Fk4CCGwHMG59OmEf Vl1QcwBQeQRLfxlM PgMxNypTNjlSez8j EkoIMjk1dRRaMCBY RwwLMVsOQEENdgAA X-Authentic-SMTP: 61633532353630.1024:706 X-AuthFastPath: 0 (Was 255) X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: [bitcoin-dev] Single-use-Seal Implementation X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2019 14:40:30 -0000 --3p2sitlo2zuzyi5i Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 07, 2019 at 08:48:06AM -0500, Bryan Bishop via bitcoin-dev wrot= e: > Single-use seals > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > This proposal may have inadvertedly demonstrated a practical way to imple= ment > Peter Todd's single-use seals concept [4]. I am hesitant to say so, thoug= h, > because I think he would ask for a more sophisticated way to verify seal > closure. I'm not sure what you're getting at here; single-use-seals are really boring and simple. To recap, they're akin to a pubkey that has the "magical" prope= rty that it can only be signed once. This of course is impossible with math alo= ne, but can be implemented with beyond-math mechanisms like trust or PoW (physi= cs). Thus you have a globally unique seal, which can be closed over a message, producing a witness attesting to the fact that the seal was closed over that message. A single-use-seal protocol is secure if it is impossible (in your chosen security model) to trick the validation function into thinking a sin= gle seal was closed over two different messages. The obvious implementation with Bitcoin is to define the seal to be a speci= fied txout, and the witness to be a transaction (and lite client proof) that spe= nds that txout in a transation with an OP_RETURN output committing to the hash = of the message as the first output. A fancier implementation could use a pay-to-pubkey-style commitment (RGB=B9 uses something along these lines). For applications requiring a chain of single-use-seals, you can easily keep= two txouts for seals in your wallet, and alternate them as the chain is extende= d. Do you mean to say there didn't previously exist a practical way to impleme= nt them? Or that you've found another way? I'm curious what you mean here. 1) https://github.com/rgb-org/spec --=20 https://petertodd.org 'peter'[:-1]@petertodd.org --3p2sitlo2zuzyi5i Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEFcyURjhyM68BBPYTJIFAPaXwkfsFAl1RelIACgkQJIFAPaXw kfuqTgf/ams+7p8gExtmzCOdflO40mWLgP7Cr5DN42eMjSJUvwK7sHjqzqQbJjjy 84UmqitqRWzeBDP/1BSvd2y2axJ7TtrCFTfy1MBRQdVMGP/gxXKjMFFPxkdbgV9z GSkwryGfZSU7mWfS/wAOpOmRMyc30/vezDGsg/EckUvq/4U3U14zs+ilwi4J7OaJ MUfuZbDmxgAWhcEspH9Cd8GqOaCqFkDo1N3/UNtUt98dadwsEzTmRUkIRpSsdyC+ b9+Ed3oSNsf9ha34C4umc24CUCEDDvN+b6KRA4PvUNKhx4bpX9mSfL/8VF5k0JqS Ose1RgBD7SItBQ5g2l/QI8Hgn3sJGA== =8NNh -----END PGP SIGNATURE----- --3p2sitlo2zuzyi5i--