From: Adam Back <adam@cypherspace•org>
To: Caleb James DeLisle <calebdelisle@lavabit•com>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] blind symmetric commitment for stronger byzantine voting resilience (Re: bitcoin taint & unilateral revocability)
Date: Thu, 16 May 2013 01:40:30 +0200 [thread overview]
Message-ID: <20130515234030.GA17920@netbook.cypherspace.org> (raw)
In-Reply-To: <20130515162129.GB6156@netbook.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
next prev parent reply other threads:[~2013-05-15 23:40 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-14 11:51 [Bitcoin-development] ecash and revocability Adam Back
2013-05-14 14:09 ` [Bitcoin-development] bitcoin taint & unilateral revocability (Re: ecash and revocability) Adam Back
2013-05-14 14:27 ` Simon Barber
2013-05-14 17:30 ` grarpamp
2013-05-15 10:25 ` [Bitcoin-development] blind symmetric commitment for stronger byzantine voting resilience (Re: bitcoin taint & unilateral revocability) Adam Back
2013-05-15 11:19 ` Peter Todd
2013-05-15 11:49 ` Adam Back
2013-05-15 12:40 ` Caleb James DeLisle
2013-05-15 16:21 ` Adam Back
2013-05-15 18:01 ` Caleb James DeLisle
2013-05-15 23:40 ` Adam Back [this message]
2013-05-16 1:24 ` Gavin
2013-05-16 1:39 ` Gregory Maxwell
2013-05-16 2:22 ` Mike Hearn
2013-05-16 2:45 ` Gregory Maxwell
2013-05-16 5:52 ` Caleb James DeLisle
2013-05-16 11:32 ` Adam Back
2013-05-16 14:51 ` Adam Back
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130515234030.GA17920@netbook.cypherspace.org \
--to=adam@cypherspace$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=calebdelisle@lavabit$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox