From: Adam Back <adam@cypherspace•org>
To: Gregory Maxwell <gmaxwell@gmail•com>
Cc: "bitcoin-development@lists•sourceforge.net"
<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 16:51:09 +0200 [thread overview]
Message-ID: <20130516145109.GA18115@netbook.cypherspace.org> (raw)
In-Reply-To: <20130516113222.GA16384@netbook.cypherspace.org>
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.
prev parent reply other threads:[~2013-05-16 14:51 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
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 [this message]
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=20130516145109.GA18115@netbook.cypherspace.org \
--to=adam@cypherspace$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=gmaxwell@gmail$(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