From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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: From: John Dillon To: Peter Todd 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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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: > // 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) > 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-----