From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UczWr-000375-6Z for bitcoin-development@lists.sourceforge.net; Thu, 16 May 2013 14:51:37 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 74.125.83.54 as permitted sender) client-ip=74.125.83.54; envelope-from=adam.back@gmail.com; helo=mail-ee0-f54.google.com; Received: from mail-ee0-f54.google.com ([74.125.83.54]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UczWb-0004I3-CD for bitcoin-development@lists.sourceforge.net; Thu, 16 May 2013 14:51:37 +0000 Received: by mail-ee0-f54.google.com with SMTP id e50so1902035eek.13 for ; Thu, 16 May 2013 07:51:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent:x-hashcash:x-hashcash:x-hashcash:x-hashcash; bh=TPgjTSe1E0dvFnpv9PVtKBbP5UHf5Bs8NJhLRyrWX8I=; b=U+CLm/Bfbzdq7WcHJJaHxUCFjGl7EJzEzIsz5vKc1ODGWuPC4B5Kf4w5TsBD4Tn5fU ZCbN4F2mTvapIRjU1M691K7UA7krwMYMsCF0N0aSk5LUXx2kO3KQHJrFpwRl6mrtLgt3 NDWbBGc6qScGdDvAXPtWWP0VXvM9Q3UKGHU465utDFVkV1ZIA7JYGvKHTsAh1Tqvo9Fj 9Ezr2rQ2axlxWWKAU/Cqugeu5/SAssUxm8lMzN+pDnMNeKjuv5lv3R2rpx4ZsV0jInp3 eKC8xirbEKRs4gc2/WXUpYaMyw6ISg2meOos1cJ8CXK5NgsN3jC1sqeCcuIm1HDpgP6f Gd0A== X-Received: by 10.14.93.201 with SMTP id l49mr47903422eef.23.1368715874959; Thu, 16 May 2013 07:51:14 -0700 (PDT) Received: from netbook (c83-90.i07-21.onvol.net. [92.251.83.90]) by mx.google.com with ESMTPSA id bn53sm11163473eeb.7.2013.05.16.07.51.13 for (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 16 May 2013 07:51:14 -0700 (PDT) Received: by netbook (Postfix, from userid 1000) id 3E4332E0652; Thu, 16 May 2013 16:51:11 +0200 (CEST) Received: by flare (hashcash-sendmail, from uid 1000); Thu, 16 May 2013 16:51:09 +0200 Date: Thu, 16 May 2013 16:51:09 +0200 From: Adam Back To: Gregory Maxwell Message-ID: <20130516145109.GA18115@netbook.cypherspace.org> References: <20130515111906.GA26020@savin> <20130515114956.GA5863@netbook.cypherspace.org> <5193825B.20909@lavabit.com> <20130515162129.GB6156@netbook.cypherspace.org> <20130515234030.GA17920@netbook.cypherspace.org> <20130516113222.GA16384@netbook.cypherspace.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20130516113222.GA16384@netbook.cypherspace.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Hashcash: 1:20:130516:gmaxwell@gmail.com::LNimIHwUVejqrbU+:0000000000000000000 0000000000000000000000001j+v X-Hashcash: 1:20:130516:mike@plan99.net::1eSE9BQMc/jzRPav:001MdV X-Hashcash: 1:20:130516:bitcoin-development@lists.sourceforge.net::xJCvlJ+sSW533 GaP:000000000000000000002wjX X-Hashcash: 1:20:130516:adam@cypherspace.org::bGPbiIMHgNV21TP9:00000000000000000 0000000000000000000000003CbU 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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (adam.back[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.0 TIME_LIMIT_EXCEEDED Exceeded time limit / deadline X-Headers-End: 1UczWb-0004I3-CD Cc: "bitcoin-development@lists.sourceforge.net" Subject: Re: [Bitcoin-development] blind symmetric commitment for stronger byzantine voting resilience (Re: bitcoin taint & unilateral revocability) 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: Thu, 16 May 2013 14:51:37 -0000 More somewhat improved crypto stuff... On Thu, May 16, 2013 at 01:32:22PM +0200, Adam Back wrote: >I suggested fixed size committed coin spends [...] > >(blind-sender, auth-tag, encrypted-tx-commit) > >(pub key P = xG, G = base point) > > blind-sender = cP (public key EC multiplied by constant c) > sig = ECDSA( cx, encrypted-tx-commit ) > encrypted-tx-commit = AES( K, tx-commit ) > K = random > >as K is random, knowledge of P if stored unencrypted does not allow >committed spend-to-junk. To reveal to a recipient just send them P and K at >each hop. (Same K each time, anyone on the committed coin spend chain can >already chose to reveal at any time so no loss of security.) Actually same K every time is not so hot, as then earlier in the committed spend chain, can force a reveal for someone later. A clearer requirement is that each person should only be able to reveal committed coin chains up to the point of their direct involvement. So that is easily fixable, just include the K for the input committed coin in the encrypted-tx-commit, as above but: encrypted-tx-commit = AES( K_i, K_{i-1} || tx-commit ) K_i = random (different K for each spend). And actually for symmetric encrypted variant the coin as specified was already evaluatable with fixed size committed spend (of the last public key) - I just didnt realize it in the previous mail: the input public key is necessarily revealed when processing the decrypted tx-commit, allowing identification and validation of the txin, and validation recursively back to the first non-committed coin. With symmetric verification, the limitation is one-use coin committed addresses (and inability to remove spend to committed junk with public validation, though there is the tx fee as a discouragement, it does bloat a recipients verification and so maybe frustates SPV->SPV consumption of committed coins). (blind-sender, auth-tag, encrypted-tx-commit) blind-sender = SHA1( SHA256( 1, pub ) ) auth = HMAC-SHA256-128( K, encrypted-tx-commit ) encrypted-tx-commit = AES( K, tx-commit ) K = SHA-256( pub ) Adam ps and it would be better and clearer to read also in terms of purpose of hashes, to use a KDF like IEEE P1363 KDF2, or PKCS#5 PBKDF2 with 1 iteration, rather than adhoc hashes for key derivation.