Date: Mon, 12 Aug 2019 10:40:23 -0400
From: Peter Todd <pete@petertodd.org>
To: Bryan Bishop <kanzure@gmail.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20190812144023.4mixitkcsrvpb7i6@petertodd.org>
References: <CABaSBawe_oF_zoso2RQBX+7OWDoCwC7T2MeKSX9fYRUQaY_xmg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="3p2sitlo2zuzyi5i"
Content-Disposition: inline
In-Reply-To: <CABaSBawe_oF_zoso2RQBX+7OWDoCwC7T2MeKSX9fYRUQaY_xmg@mail.gmail.com>
User-Agent: NeoMutt/20170113 (1.7.2)
Subject: [bitcoin-dev] Single-use-Seal Implementation
Precedence: list


--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--