From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UclJL-0004hC-F7 for bitcoin-development@lists.sourceforge.net; Wed, 15 May 2013 23:40:43 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.215.175 as permitted sender) client-ip=209.85.215.175; envelope-from=adam.back@gmail.com; helo=mail-ea0-f175.google.com; Received: from mail-ea0-f175.google.com ([209.85.215.175]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UclJK-0007t4-9l for bitcoin-development@lists.sourceforge.net; Wed, 15 May 2013 23:40:43 +0000 Received: by mail-ea0-f175.google.com with SMTP id h10so1233393eaj.34 for ; Wed, 15 May 2013 16:40:36 -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; bh=pzy8VVtia2EUFSdgL4zIt5PTk7tkn18hXJskmvTej+Y=; b=Y29tVU21znsccWbZjlSEyp/K/T7agqCNehzhCdiwN0M2Zg2hT6yNmmureo2Km2rvNi fRps2DSxyCP5PzYx/jizGjcvfXyoQUFC9F6uIWUcIUceSZn/6kMA68XtDOPBQqbthJiJ cu7ZLIPAjiyxUHm4lGB9LSGWei9P5GH30gVToiDQclifA7vK5/mcyyq7G4U41JzKUDv0 wTYPhyMSHskWf8HVAybAra1d9k1KMZsYVn2DmX0GPA9pPQagw3/Q3hdX/paIaMsukYFd WSCGkZtw/XdKLPSRJWX4+gMGsrfilAafdtwgdzcgL8/8DwZEPlHnBHKYGn+OU/mZAWfv cg1g== X-Received: by 10.14.111.5 with SMTP id v5mr109527072eeg.27.1368661235943; Wed, 15 May 2013 16:40:35 -0700 (PDT) Received: from netbook (c83-90.i07-21.onvol.net. [92.251.83.90]) by mx.google.com with ESMTPSA id y10sm7004773eev.3.2013.05.15.16.40.34 for (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 15 May 2013 16:40:35 -0700 (PDT) Received: by netbook (Postfix, from userid 1000) id 4A07B2E04CB; Thu, 16 May 2013 01:40:32 +0200 (CEST) Received: by flare (hashcash-sendmail, from uid 1000); Thu, 16 May 2013 01:40:30 +0200 Date: Thu, 16 May 2013 01:40:30 +0200 From: Adam Back To: Caleb James DeLisle Message-ID: <20130515234030.GA17920@netbook.cypherspace.org> References: <20130514115151.GA21600@netbook.cypherspace.org> <20130514140902.GA22447@netbook.cypherspace.org> <20130515102509.GA3401@netbook.cypherspace.org> <20130515111906.GA26020@savin> <20130515114956.GA5863@netbook.cypherspace.org> <5193825B.20909@lavabit.com> <20130515162129.GB6156@netbook.cypherspace.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20130515162129.GB6156@netbook.cypherspace.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Hashcash: 1:20:130515:calebdelisle@lavabit.com::xG+lxO59WLW1qpLC:0000000000000 0000000000000000000000000N6q X-Hashcash: 1:20:130515:bitcoin-development@lists.sourceforge.net::GPe8eVqdFN/3E GAR:000000000000000000009YBR X-Hashcash: 1:20:130515:adam@cypherspace.org::1g1La2HzZE6AHF6E:00000000000000000 0000000000000000000000000faV 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 X-Headers-End: 1UclJK-0007t4-9l 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: Wed, 15 May 2013 23:40:43 -0000 btw I posted some of this thread on the dev forum: https://bitcointalk.org/index.php?topic=206303.msg2157994#msg2157994 A related idea is occuring to me that maybe these committed transactions could actually as a side effect make bitcoin scale slightly better by reducing the p2p flood filled transaction size. As I said on the forum: > Note committed transactions are more compact than regular transactions - > they are just two hashes, so they reduce network bandwidth and make > bitcoin more scalable to the extent that transaction reveals stay off > network. (As well as more secure against centralization policy risks). Surely its lower bandwidth for nodes to send only committed transactions to the p2p network, and pass committed payment chains direct to recipients. Say committed transaction size is c (20bytes+32bytes+16bytes +header ~ 72 bytes?) And full transaction smallest size is t (txin=20bytes, amount out 4bytes, sender pub key 32bytes, recip address 20bytes, change address 20bytes, formatting 5 bytes, ECDSA signature 64bytes, script 10 byte surely ~ 175bytes)? Thats over twice the size. Probably average more, and it is sent to every node. Its always going to be lower bandwidth to send transactions to the recipients than to send to the network, even if you have to increase the transaction size with each respend. The alternative is for the entire network to see the same transaction. I think the commitment needs to bind the two parts together eg (blind-sender, auth-tag, tx-commit) blind-sender = SHA1( SHA256( 1, pub ) ) auth = HMAC-SHA256-128( K, tx-commit ) tx-commit = SHA-256( tx ) Or some variantion, and you must not reuse the pub key, and must send change if any to a different address, otherwise chain recipients or malicious forwarders could lock your coin, by putting random junk onto the network which would be unverifiable, and non-disclaimable - you cant prove you dont know the preimage of some junk. The MAC prevents it. Maybe there's a more compact way to do it even, but that works efficient demonstration of security feasibility. Other public key variants could be possible, P = xG is the ECDSA public key, x the private key, G base point. Sender could reveal P' = cP, c some fixed constant (computing c from cP is ECDL problem considered oneway & hard), and a signature by private key x' = cx over the tx-commit. That is a publicly auditable commitment also, but one tht can make an ECDSA signature over the tx-commit hash, and can be revealed by revealing P later. However that imposes public key computation on the validation (which it already currently does, but faster validation as above is nicer). With that one you dont even have to verify the transaction signature on reveal :) You already did it, just provide the tx that hashes to the signed hash, and P for the recipient to verify the signature was made by cP. Adam