summaryrefslogtreecommitdiff
path: root/57/239401f272f428f5ba97ebf1cb6390c8195ebb
blob: 847e730f9fe2831ba9e42c1c55c5e6969f1c00f1 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
Return-Path: <user@petertodd.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 6519CCA5
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	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 <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)
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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--