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 ------------------------------------------------------------------------------ AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
