Re: [Bitcoin-development] blind symmetric commitment for stronger byzantine voting resilience (Re: bitcoin taint & unilateral revocability)

[Adam Back <adam@cypherspace.org>]

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