summaryrefslogtreecommitdiff
path: root/63/6c95b9f75689deacb3cb816140a3b921e325d4
blob: 866d36deb3bd446bf5562335b715101a3575f894 (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
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <pete@petertodd.org>) id 1V3Fep-00018u-Nt
	for bitcoin-development@lists.sourceforge.net;
	Sun, 28 Jul 2013 01:20:23 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.148.113 as permitted sender)
	client-ip=62.13.148.113; envelope-from=pete@petertodd.org;
	helo=outmail148113.authsmtp.com; 
Received: from outmail148113.authsmtp.com ([62.13.148.113])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
	id 1V3Fem-0000eq-5z for bitcoin-development@lists.sourceforge.net;
	Sun, 28 Jul 2013 01:20:23 +0000
Received: from mail-c233.authsmtp.com (mail-c233.authsmtp.com [62.13.128.233])
	by punt10.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id
	r6S1KEEp086095 for <bitcoin-development@lists.sourceforge.net>;
	Sun, 28 Jul 2013 02:20:14 +0100 (BST)
Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109])
	(authenticated bits=128)
	by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id r6S1K8jV091224
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO)
	for <bitcoin-development@lists.sourceforge.net>;
	Sun, 28 Jul 2013 02:20:11 +0100 (BST)
Date: Sat, 27 Jul 2013 21:20:08 -0400
From: Peter Todd <pete@petertodd.org>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Message-ID: <20130728012008.GA19958@savin>
References: <20130727234918.GA11635@savin>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="CE+1k2dSO48ffgeK"
Content-Disposition: inline
In-Reply-To: <20130727234918.GA11635@savin>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: d96f4dd6-f723-11e2-a49c-0025907707a1
X-AuthReport-Spam: If SPAM / abuse - report it at:
	http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVJwpGK10IU0Fd
	P1hXKl1LNVAaWXld WiVPGEoXDxgzCjYj NEgGOBsDNw4AXQ11
	Kg0VXVBSFQZ4AR4L BB4UUxg8cANYeX5u ZEFqQHFbVVt/fUFi
	QwAWEw4HHm86DmAW UUJac01VcApMelER Y1YpUCdZZ3hRYXhj
	WlZqMmp0NGkOI2EN GltQfApNHh5UF2cq fR1QVQYFHFEOQCQ1
	ahArNFMYG14UP0Mu BBMdRlVQPRYZFgpE V15EBCtUOxEeRjYr
	RQRcUAsCEThQBD9V GQY3JQVEGVQA
X-Authentic-SMTP: 61633532353630.1021:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 76.10.178.109/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
	anti-virus system.
X-Spam-Score: -1.5 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	-0.0 SPF_PASS               SPF: sender matches SPF record
X-Headers-End: 1V3Fem-0000eq-5z
Subject: Re: [Bitcoin-development] Two factor wallet with one-time-passwords
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Sun, 28 Jul 2013 01:20:23 -0000


--CE+1k2dSO48ffgeK
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Jul 27, 2013 at 07:49:18PM -0400, Peter Todd wrote:
> Implementation
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> Savings use P2SH outputs matching the following scriptPubKey form:
>=20
> HASH160 <H(nonce_i)> EQUALVERIFY <pubkey> CHECKSIG
>=20
> spent with:
>=20
> <sig> <nonce_i>

FWIW with some minor scripting language additions such as access to txin
and txout contents, along with merklized abstract syntax tree (MAST)
support, we can even implement a version where scriptPubKey's can be
reused:

    <pubkey> CHECKSIGVERIFY

    // Verify we aren't spending more than the maximum spend amount
    0 GET-TXIN-VALUE      // relative indexing
    0 GET-TXOUT-VALUE
    SUB
    <max-spend-amount>
    LESSTHAN
    VERIFY

    // If the txout is greater than the maximum spend amount force it to
    // also follow these same rules.
    0 GET-TXOUT-VALUE
    <max-spend-amount>
    LESSTHAN
    IFNOT
        GET-THIS-SCRIPT
        MAST-HASH
        <serialized script "MAST-HASH MAST-EVAL">
        CAT
        GET-TXOUT-SCRIPT
        EQUALVERIFY
    ENDIF

    // Hash the provided oracle nonce, saving original for later.
    DUP
    HASH160

    // Use the txid:vout nonce as an index to a table, embedded with MAST
    // script compression.
    0 GET-TXIN-TXID
    0 GET-TXIN-VOUT
    CAT
    HASH160

    // The table, n=3D64 levels deep, not all levels shown for brevity.
    DUP
    1
    AND
    IF
        1
        RSHIFT
        DUP
        1
        AND
        IF
            1
            RSHIFT
            DUP
            1
            AND
            IF
                <MAST digest, not executed>
            ELSE
                1
                RSHIFT
                DUP
                1
                AND
                IF
                    // Lowest level contains the following pushdata,
                    // with 0 <=3D i < 2^64
                    <HASH160(HASH160(nonce-secret + i))>
                ELSE
                    <MAST digest, not executed>
                ENDIF
        ELSE
            <MAST digest, not executed>
        ENDIF
    ELSE
        <MAST digest, not executed>
    ENDIF

    // Drop the txid:vout nonce
    SWAP
    DROP

    // Verify that the hash of the nonce and the pre-committed value in
    // the H(nonce) table match.
    EQUALVERIFY

    // Stack now only contains the nonce preceeded by a merkle path linking
    // that nonce to the tip of a merkle tree over all nonces.
    //
    // Verify that path.
    SWAP // Move direction flag to the top
    IF
        SWAP
    ENDIF
    HASH160
    (repeat above five lines 63 more times)

    <nonce-merkle-tree-tip-digest>
    EQUAL

The scriptPubKey is spent by the following scriptSig:

    <nonce-merkle-path-0>...<nonce-merkle-path-63>
    <nonce>
    <signature>
    <serialized-script>

(note that I've left off a number of possible optimizations for clarity)

Now when the user wishes to spend a txout greather than their spending
limit their wallet software will first give them a short 6 word string
calculated from the last 64-bits of H(txid:vout). They simply enter this
string into their phone, ideally via convenient qr-code or voice/thought
recognition, and their phone provides a second short 6 word string to
enter into the wallet software on their computer, authorizing the
payment. If they opt for a paper-based one-time-password table they
simply use the 6 word string as an index to their pre-printed OTP
encyclopedia set.

Like the previously described version the security level is still a
healthy 2^64 - again the attacker needs to find a 64-bit pre-image,
considered to be a highly difficult task for any attacker unable to
count from 0 to 2^64 or store a table containing 2^64 values.

There is the disadvantage of the large storage requirements for both
wallets, however because of the double hashed construction,
H(H(nonce-secret+i)), neither table needs to be kept secret. Thus
without loss of security both tables can be easily stored in a
distributed hash table in the cloud and queried as needed.

--=20
'peter'[:-1]@petertodd.org
0000000000000012199fe3f1f54921e8e11c0b0d318ed6245dee22a4ad55bc65

--CE+1k2dSO48ffgeK
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBCAAGBQJR9HHHAAoJECSBQD2l8JH76HUH/0wNA5122jnqJ1Gkpp8dyz5j
jZMZoOxbxkb+K8srxBhvTSGLl4OaZSqw07SK/3aYUzDta0HhtfiEGpX0bTOTJUYp
csOXQC+ZITzcDHvP3LPIXnaEkQbEYOLXjy/rZ9reQDIm5n5BptA62PLIr0bu64LX
KFGdYyXlJpcFbiYcKb8rHx8Yo3E0/gX1qim7OHrkiNq2sWnGqTXRY/YyWLOcNQ3x
xj2L1zzImBtqYWH5optDaKVut+AxX0zoOKFm5gDIWTsMyBaxEDwfMBzaTbMQ01HW
F9Fowvym9ANJ/DzldgWA7RdN5/QxMIioMd0uk+RHnHKDZf/+buF+AE46P/Va1ik=
=58uZ
-----END PGP SIGNATURE-----

--CE+1k2dSO48ffgeK--