summaryrefslogtreecommitdiff
path: root/09/b8045e4651d7cd7f9f11d319ea56a2db20660f
blob: 2ad783ea5b46dfbdc9f3011039cf70e12881afbb (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
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <john.dillon892@googlemail.com>) id 1V3WNj-00079x-8C
	for bitcoin-development@lists.sourceforge.net;
	Sun, 28 Jul 2013 19:11:51 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of googlemail.com
	designates 209.85.215.195 as permitted sender)
	client-ip=209.85.215.195;
	envelope-from=john.dillon892@googlemail.com;
	helo=mail-ea0-f195.google.com; 
Received: from mail-ea0-f195.google.com ([209.85.215.195])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1V3WNh-0005zd-6p
	for bitcoin-development@lists.sourceforge.net;
	Sun, 28 Jul 2013 19:11:51 +0000
Received: by mail-ea0-f195.google.com with SMTP id z15so1541561ead.2
	for <bitcoin-development@lists.sourceforge.net>;
	Sun, 28 Jul 2013 12:11:42 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.14.1.70 with SMTP id 46mr56520486eec.82.1375038702864; Sun,
	28 Jul 2013 12:11:42 -0700 (PDT)
Received: by 10.223.12.131 with HTTP; Sun, 28 Jul 2013 12:11:42 -0700 (PDT)
In-Reply-To: <20130728012008.GA19958@savin>
References: <20130727234918.GA11635@savin>
	<20130728012008.GA19958@savin>
Date: Sun, 28 Jul 2013 19:11:42 +0000
Message-ID: <CAPaL=UUQJmLquQJRwQO5FB28-QYFw1q_scU24S0Wr1HQVDu4WQ@mail.gmail.com>
From: John Dillon <john.dillon892@googlemail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: text/plain; charset=ISO-8859-1
X-Spam-Score: -1.4 (-)
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(john.dillon892[at]googlemail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
	digit (john.dillon892[at]googlemail.com)
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1V3WNh-0005zd-6p
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
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 19:11:51 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Sun, Jul 28, 2013 at 1:20 AM, Peter Todd <pete@petertodd.org> wrote:
> 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:

<snip>

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

You missed a 'CAT' opcode here.

>     HASH160
>     (repeat above five lines 63 more times)

<snip>

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

I think you should disclose whether or not you have any ties to the pulp and
paper business... By my calculations the production of a single OTP table would
consume roughly half of all the forest biomass on this planet.

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

ROTFL!

Your idea is better than you realize, you are just too paranoid for your own
good. The thing is the attacker isn't going to be someone paying you funds over
your minimum spending limit, which means the size of the table deriving which
H(nonce) is selected for a given txid:vout can be significantly smaller. For
instance if you want to have 256 total payments before a 50:50 chance of any
pair using the same nonce, you only need a table with ~2^16 elements or with 20
byte hashes just a megabyte of data. It is the 16 level merkle proofs that are
the problem, 16*21=336 bytes of data in the scriptSig. Then again, that's only
4.5x the size of a single signature, not unreasonable.

Also your nested IF statements, while a lovely and hilarious use of MAST, can
be replaced by simply creating the merkle tree over the tuples [i,H(nonce_i)]
and proving that the nonce_i you provided matched the precommitted tree. Now
you only need to provide one merkle proof, not two.

But don't let me discourage you, rarely do I see elaborate jokes that also meet
the criteria to be a least publishable unit. :)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBCAAGBQJR9WzMAAoJEEWCsU4mNhiP8wIIAJTESdZiIyrfmrJIQad19He0
nPUB1UGdrcRyYBKfk2bxmIgeTppEneISerAzFpfsZk/R1vLSp2zuFvFLMvaTqF0a
nof9dR4ztp753P6O9nLBIK1gcoOagg/FL61Cd1mQzoTjznGioEgk1mCo/Qjb8h9E
I43De70j575bvUkq8RQgijctIt463bM7vfdBC6qtgSziL/xrLUDQEJ6Mhqz3rnmX
+A2+MPHd/aGnRIcBuN6DFQTMXpjXG2y1CIM45e2gPL5x/vSIXqJoJs9tgGyzuFLG
rR34GCsifUKxJyvswG5ue9rNuo5mDkri2jIFx8SlqhfT/b8iWU8JIieoZYGuMiA=
=uhmy
-----END PGP SIGNATURE-----