Re: [Bitcoin-development] Two factor wallet with one-time-passwords

[John Dillon <john.dillon892@googlemail.com>]

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