* [Bitcoin-development] ecash and revocability
@ 2013-05-14 11:51 Adam Back
2013-05-14 14:09 ` [Bitcoin-development] bitcoin taint & unilateral revocability (Re: ecash and revocability) Adam Back
0 siblings, 1 reply; 18+ messages in thread
From: Adam Back @ 2013-05-14 11:51 UTC (permalink / raw)
To: Bitcoin-Dev
So back in 1999, in an ecash thread on cypherpunks I claimed:
http://marc.info/?l=cypherpunks&m=95280154629900&w=2
> I wouldn't say ecash has to use blinding, but I would argue it would be a
> misuse of the word "ecash", if something which was revocable were dubbed
> ecash.
This was in the context of a discussion of digigold (e-gold stored the
physical gold, digigold offered "ecash" backed in that physical gold).
Digigold ran on Systemics payment server/sox protocol. Because of inferred
regulatory concerns and patent licensing issues digigold & systemics were
not using blind signatures. However with systemics sox server, like
bitcoin, you could create multiple accounts on demand and shuffle payments
around for a degree of privacy. The bitcoin analogy would be the
transaction log lived in the systemics server, so it had a central failure
point, but arguably more privacy as the log was not public. Also systemics
SOX protocol (Ian Grigg & Gary Howland) had some aspect of bitcoins smart
contract concepts - ricardian contracts.
http://iang.org/papers/ricardian_contract.html
(Btw the anonymous reply itself was interesting -
http://marc.info/?l=cypherpunks&m=95280154629912&w=2 that could have been
Nakamoto, the only missing thing from the parts on the discussion room floor
to bitcoin is mathematical inflation control.)
The thread actually started here
http://marc.info/?l=cypherpunks&m=95280154629912&w=2 and then continues here
http://marc.info/?l=cypherpunks&m=95280154629900&w=2 because of a subject
line change and then http://marc.info/?l=cypherpunks&m=95280154629916&w=2
and http://marc.info/?l=cypherpunks&m=95280154629948&w=2
more subject line change confusion.
A related thread a few days later also covers Sander & Ta-Shma (which
zerocoin is based on):
http://marc.info/?l=cypherpunks&m=95280154630167&w=2
there were many more threads about various ecash technologies.
Adam
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bitcoin-development] bitcoin taint & unilateral revocability (Re: ecash and revocability)
2013-05-14 11:51 [Bitcoin-development] ecash and revocability Adam Back
@ 2013-05-14 14:09 ` Adam Back
2013-05-14 14:27 ` Simon Barber
` (2 more replies)
0 siblings, 3 replies; 18+ messages in thread
From: Adam Back @ 2013-05-14 14:09 UTC (permalink / raw)
To: Bitcoin-Dev
On Tue, May 14, 2013 at 01:51:51PM +0200, Adam Back wrote:
> Adam Back in Sep 1999, cypherpunks list:
>>I wouldn't say ecash has to use blinding, but I would argue it would be a
>>misuse of the word "ecash", if something which was revocable were dubbed
>>ecash.
So I still think that is an important point. "Ecash should not be
revocable". I think bitcoin currently has a partial problem because of
taint.
Now blinding based unlinkability, in a distributed cryptographic payer/payee
anonymous system like Sander & Ta Shma [1] and zerocoin has so far been
based on ZKP of set membership. Of course that is somewhat expensive,
though zerocoin improved the ZKP with an relatively efficient (but still
cut-and-choose) proof.
Bitcoins relative lack of privacy creates a problem with tainted coins
risking becoming unspendable, or spendable only with some users, or at a
discount. So while the policy coded says all coins are equally acceptable,
the information exists so people can unilaterally reject them, depending on
what the taint is. So far revocability hasnt reared it's head that I heard,
nor taint inspection too much? However people have the choice and technical
means to check the taint and send the bitcoins back.
Another aspect is that bitcoin, like systemics sox/digigold, makes a
different privacy tradeoff. Somewhat private, but not very much.
But it creates the question: could the taint issue be fixed efficiently (eg
even without blinding or ZKP of set membership?)
One related concept is commitments. I think its relatively easy to commit
to a payment and lock a coin without identifying yourself, until the
commitment is released. You might do the commitment, wait 6-blocks for
confirmation, then reveal the commitment. Then that is like a self-issued
green coin with no need for trust, that can be immediately cleared. The
recipient has to be committed to at the same time to prevent double
spending.
So just commit = H( input-pub ) H( transaction ) and put it in the block
chain. Where transaction the is usual ( input signature, output-pub,
script). (Fee for the commit would have to come from an unlinked coin or
the input-pub reveals the coin). Wait 6 blocks, send/reveal the transaction
(free because fee was already paid). Validators check input-pub hash
against committed coins by hash, check the transaction hash, and the usual
ransaction validations = sum inputs, otherwise reject. The user better pay
change if any to a different public key, as the inputs public keys are one
use - are after the reveal they are DoS lockable by other people reposting
H( input-pub ).
The input-pub coin is locked as normal transactions have their public key hash
validate as not being locked.
Adam
[1] Sander & Ta Shma "Auditable, Anonymous Electronic Cash"
http://www.cs.tau.ac.il/~amnon/Papers/ST.crypto99.pdf
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Bitcoin-development] bitcoin taint & unilateral revocability (Re: ecash and revocability)
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
2 siblings, 0 replies; 18+ messages in thread
From: Simon Barber @ 2013-05-14 14:27 UTC (permalink / raw)
To: Adam Back; +Cc: Bitcoin-Dev, Xavier Boyen
Adam,
Take a look at this privacy enhancing solution based on fair exchange
implemented by bitcoin contracts and cut-and-choose. It would require a
public pool of users willing to exchange in common denominations at
moments in time together to ensure unlinkability. It also leave a trace
of exchange activity in the chain. This could all be added to wallet
software to become automatic.
http://robotics.stanford.edu/~xb/fc12/index.html
Simon
On 05/14/2013 07:09 AM, Adam Back wrote:
> On Tue, May 14, 2013 at 01:51:51PM +0200, Adam Back wrote:
>> Adam Back in Sep 1999, cypherpunks list:
>>> I wouldn't say ecash has to use blinding, but I would argue it would be a
>>> misuse of the word "ecash", if something which was revocable were dubbed
>>> ecash.
>
> So I still think that is an important point. "Ecash should not be
> revocable". I think bitcoin currently has a partial problem because of
> taint.
>
> Now blinding based unlinkability, in a distributed cryptographic payer/payee
> anonymous system like Sander & Ta Shma [1] and zerocoin has so far been
> based on ZKP of set membership. Of course that is somewhat expensive,
> though zerocoin improved the ZKP with an relatively efficient (but still
> cut-and-choose) proof.
>
> Bitcoins relative lack of privacy creates a problem with tainted coins
> risking becoming unspendable, or spendable only with some users, or at a
> discount. So while the policy coded says all coins are equally acceptable,
> the information exists so people can unilaterally reject them, depending on
> what the taint is. So far revocability hasnt reared it's head that I heard,
> nor taint inspection too much? However people have the choice and technical
> means to check the taint and send the bitcoins back.
>
>
> Another aspect is that bitcoin, like systemics sox/digigold, makes a
> different privacy tradeoff. Somewhat private, but not very much.
>
> But it creates the question: could the taint issue be fixed efficiently (eg
> even without blinding or ZKP of set membership?)
>
>
> One related concept is commitments. I think its relatively easy to commit
> to a payment and lock a coin without identifying yourself, until the
> commitment is released. You might do the commitment, wait 6-blocks for
> confirmation, then reveal the commitment. Then that is like a self-issued
> green coin with no need for trust, that can be immediately cleared. The
> recipient has to be committed to at the same time to prevent double
> spending.
>
> So just commit = H( input-pub ) H( transaction ) and put it in the block
> chain. Where transaction the is usual ( input signature, output-pub,
> script). (Fee for the commit would have to come from an unlinked coin or
> the input-pub reveals the coin). Wait 6 blocks, send/reveal the transaction
> (free because fee was already paid). Validators check input-pub hash
> against committed coins by hash, check the transaction hash, and the usual
> ransaction validations = sum inputs, otherwise reject. The user better pay
> change if any to a different public key, as the inputs public keys are one
> use - are after the reveal they are DoS lockable by other people reposting
> H( input-pub ).
>
> The input-pub coin is locked as normal transactions have their public key hash
> validate as not being locked.
>
> Adam
>
> [1] Sander & Ta Shma "Auditable, Anonymous Electronic Cash"
> http://www.cs.tau.ac.il/~amnon/Papers/ST.crypto99.pdf
>
> ------------------------------------------------------------------------------
> 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
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Bitcoin-development] bitcoin taint & unilateral revocability (Re: ecash and revocability)
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
2 siblings, 0 replies; 18+ messages in thread
From: grarpamp @ 2013-05-14 17:30 UTC (permalink / raw)
To: bitcoin-development
> Bitcoins relative lack of privacy creates a problem with tainted coins
> risking becoming unspendable, or spendable only with some users, or at a
> discount. So while the policy coded says all coins are equally acceptable,
> the information exists so people can unilaterally reject them, depending on
> what the taint is. So far revocability hasnt reared it's head that I heard,
> nor taint inspection too much? However people have the choice and technical
> means to check the taint and send the bitcoins back.
a) Is there a paper detailing bitcoin traceability issues?
Particularly when using various combinations of the often
advised 'use different address for every transaction', 'wash coins',
and 'use anonymity networks' privacy enhancement methods.
b) People would be nuts to reject tainted coins on the current
chain, or any chain. How many of the bills in your wallet passed
through 'illicit' transactions? How would you feel if your payee's
serial checker bounced yours, possibly forcing you to dispense
with them through other, possibly illicit, means? What about a
total blackball? Who's going to compensate you? How exactly do
you roll that all back? And are you going to KYC and scour the lives
of your every potential customer beforehand? What if someone has
money to burn and blackballs a million notes for fun. A currency of
common global adoption that you can't spend after some thieving
crackdealer bought an onion off your garden stand isn't of much use
to anyone, not even the purists who come up with such ideas.
Specialized currencies in special markets, sure, maybe, all still
fraught with the same dilemmas. But for a global common one? No.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bitcoin-development] blind symmetric commitment for stronger byzantine voting resilience (Re: bitcoin taint & unilateral revocability)
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 ` Adam Back
2013-05-15 11:19 ` Peter Todd
2 siblings, 1 reply; 18+ messages in thread
From: Adam Back @ 2013-05-15 10:25 UTC (permalink / raw)
To: Bitcoin-Dev
So in a previous mail I described a simple, extremely efficient and easy to
implement symmetric key commitment that is unlinkable until reveal time (at
bottom). I think this can help improve the byzantine generals problem, that
bitcoin only defends to simple majority (with one vote per CPU power), and
so assumes most nodes by cpu power are honest. With this simple protocol
change you dont need any honest nodes, just some honest clients to spend to,
to have your transaction accepted.
You can think of this in terms of a (somewhat distributed) server performing
validations, but in a way that it sufficiently blind to the details of the
validations that it can not selectively enforce a policy, it power is
limited to random DoS.
There are other situations where you can rely on a server for one property
but not another - eg a somewhat distributed encrypted backup (like Tahoe
LAFS) you rely on for availability, but not integrity nor confidentiality
(because you encrypt those, and some sharing scenarios still work.) So this
is in that class of protocols - zero-trust in server, but can extract
service and some guarantees from the (optionally distributed) server anyway.
(Bitcoin does not use known better than majority results for byzantine
generals based on fair coin toss, relying instead on simple majority and an
assumed largely unjammable network. I notice Nick Szabo was complaining
about this on his blog and saying bitcoins majority is not even a standard
or proven byzantine voting protocol - something adhoc. I think the bitcoin
unjammable network assumption is a false at the limit so that someone with
strong network hacking capabilities can create network splits long enough to
even overcome the network majority vote without having any compute power of
their own. All they need is to have a split with enough power to plausibly
quickly get the victims their desired number of (split) confirmations.)
Anyway this should be a clear voting improvement, that is efficient.
Imagine a couple of big pools or ASIC miners started enforcing some
arbitrary coin policy, eg say coins must not have some taint according to
its list of black coins, or coins must be certified by some entity, be
traceable to some type of event etc. Well call these miners/voters
"dishonest", in that they are not following the intended zero-policy
protocol.
If the coins dont match their chosen policy, the dishonest miners will
refuse to include transactions in blocks they issue. If they see a
transaction which does not match their policy in a block by someone else
they will ignore it and try to make it into an orphan. As they have say 75%
of the network power they can do that successfully. Even with current
validation protocols in the clients, so the "but clients wont accept the
change" argument does not apply - the existing clients will accept the
policy change, because they cant detect it, nor prove it, and dont have the
voting power to impose honest policies.
(For realism of this risk, note that according to Kaminsky there already
exist multiple entities with reserve ASIC power each exceeding current
network difficulty who are holding part of their power in reserve for profit
maximisation reasons. This is a coming to fruition of the concentration of
power issue I was talking about in my first bitcoin forum post. People who
have that kind of power in reserve have clearly invested millions of
dollars, which probably makes them more vulnerable to political influence.)
Alright so the solution. Use the commitment protocol (below) which even
though it is symmetric key strongly hides the committed transaction public
key. (Symmetric in the sense that the validation steps are all highly
efficient symmetric key based). Now send the transaction (which includes
the public key) direct to the receiver, over a secure channel, or an assumed
non-eavesdropped direct channel, with no p2p flood of the transaction. The
receiver can check the hash to the commitment, and decide how many
confirmtions he needs. Once he has eg 6 confirmations he reveals the
commitment to the transaction (by publishing it). The sender may also send
the reveal/transaction to the network directly himself, if the recipient is
offline. However there is no advantage to publishing early so it seems
better to let the recipient do it when he is ready to incorporate the
payment into his wallet.
Now the powerful dishonest voters if they try to apply their policy when
they see the reveal triggers it, must redo the work of the 6-commitments
that they computed themselves. This is like starting 6-steps behind in the
statstical gamblers ruin game that Nakamoto describes in the bitcoin paper.
Consequently even with 75%, they will find it very hard to outcompete their
own prior work, to create a 6 chain long orphan while the 25% is moving
forward on the honest chain. Each time they see transactions which violate
their policy, they have to restart their chain recalculation again from
scratch. Often if simple lower powered intermittent recipient sends the
coin will be burried hundreds of blocks back. In addition 6 chain long
branches are extremely unlikely with honest payers, so clients can (and
maybe already do?) act with suspicion of they see one.
Going further, I said for best security, the recipient should never even
reveal (to the network) until he is actually about to spend, but futher he
does not even have to reveal publicly ever, he can choose to reveal only to
the recipient with a direct connection (no p2p flood fill of transaction.)
And the direct spend argument composes, ie the 2nd recipient can not do the
same thing again. (public key A sends to public key B sends to public key
C: B publishes COM( transaction B->C ), sends the reveal of COM( transaction
A->B ), and COM transaction B->C ) to C. C waits 6 confirmations and is
convinced. So its the approach is composable, and in fact the network
doesnt learn the size of the transaction even, though the spend grows each
time. Eventually presumably someone will publish will the confirmations to
the network to trim the tansaction size, though it is not strictly
necessary, and the transaction flow is small and direct (no network scaling
issues), so that it wouldnt be a huge problem to have a 1MB payment
representing 1000s of hops of network blind transactions. (For the
composable network blind respending the commitment has to commit publicly to
both the sender and next hop recipient keys, so the network can see how long
the chain is).
Probably you can cope with multiple inputs and outputs, and maybe given even
you can work with a 100% dishonest network mining network (all the dishonest
miner can do is selectively DoS transactions if they are all network blind
except the mining), maybe the mining can even be decoupled from the voting,
as you no longer demand much from the voting process. That admits more
interesting things like pool free direct mining, low variance hashcash
coins, probably. Many things to think through.
I suppose the commitment could be described as a blind symmetric commitment.
Adam
On Tue, May 14, 2013 at 04:09:02PM +0200, Adam Back wrote:
> [...]
>
>One related concept is commitments. I think its relatively easy to commit
>to a payment and lock a coin without identifying yourself, until the
>commitment is released. You might do the commitment, wait 6-blocks for
>confirmation, then reveal the commitment. Then that is like a self-issued
>green coin with no need for trust, that can be immediately cleared. The
>recipient has to be committed to at the same time to prevent double
>spending.
>
>So just commit = H( input-pub ) H( transaction ) and put it in the block
>chain. Where transaction the is usual ( input signature, output-pub,
>script). (Fee for the commit would have to come from an unlinked coin or
>the input-pub reveals the coin). Wait 6 blocks, send/reveal the transaction
>(free because fee was already paid). Validators check input-pub hash
>against committed coins by hash, check the transaction hash, and the usual
>ransaction validations = sum inputs, otherwise reject. The user better pay
>change if any to a different public key, as the inputs public keys are one
>use - are after the reveal they are DoS lockable by other people reposting
>H( input-pub ).
>
>The input-pub coin is locked as normal transactions have their public key hash
>validate as not being locked.
>
>Adam
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Bitcoin-development] blind symmetric commitment for stronger byzantine voting resilience (Re: bitcoin taint & unilateral revocability)
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
0 siblings, 1 reply; 18+ messages in thread
From: Peter Todd @ 2013-05-15 11:19 UTC (permalink / raw)
To: Adam Back; +Cc: Bitcoin-Dev
[-- Attachment #1: Type: text/plain, Size: 1414 bytes --]
On Wed, May 15, 2013 at 12:25:09PM +0200, Adam Back wrote:
Protocols aren't set in stone - any attacker that controls enough
hashing power to pose a 51% attack can simply demand that you use a
Bitcoin client modified to provide the attack with the full transactions
from the beginning. Any blocks containing transactions with unknown
contents will be attacked into oblivion.
On the other hand if the "attacker" has less than 50% of the hashing
power, they have no choice but to let other blocks through, and provided
miners are free from regulation imposed on them you can bid to get your
transactions mined with fees. Anyone using a blockchain-based
crypto-currency simply has to accept that mining is a random process and
getting a transaction confirmed is inherently unreliable.
> So in a previous mail I described a simple, extremely efficient and easy to
> implement symmetric key commitment that is unlinkable until reveal time (at
> bottom). I think this can help improve the byzantine generals problem, that
> bitcoin only defends to simple majority (with one vote per CPU power), and
> so assumes most nodes by cpu power are honest. With this simple protocol
> change you dont need any honest nodes, just some honest clients to spend to,
> to have your transaction accepted.
--
'peter'[:-1]@petertodd.org
00000000000001754b62829d854463fa72fe7d972a7b7d13d0c30fc86423773c
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Bitcoin-development] blind symmetric commitment for stronger byzantine voting resilience (Re: bitcoin taint & unilateral revocability)
2013-05-15 11:19 ` Peter Todd
@ 2013-05-15 11:49 ` Adam Back
2013-05-15 12:40 ` Caleb James DeLisle
0 siblings, 1 reply; 18+ messages in thread
From: Adam Back @ 2013-05-15 11:49 UTC (permalink / raw)
To: Peter Todd; +Cc: Bitcoin-Dev
On Wed, May 15, 2013 at 07:19:06AM -0400, Peter Todd wrote:
>Protocols aren't set in stone - any attacker that controls enough
>hashing power to pose a 51% attack can simply demand that you use a
>Bitcoin client modified [to facilitate evaluation of his policy]
Protocol voting is a vote per user policy preference, not a CPU vote, which
is the point. Current bitcoin protocol is vulnerable to hard to prove
arbitrary policies being imposable by a quorum of > 50% miners. The blind
commitment proposal fixes that, so even an 99% quorum cant easily impose
policies, which leaves the weaker protocol vote attack as the remaining
avenue of attack. That is a significant qualitative improvement.
The feasibility of protocol voting attacks is an open question, but you
might want to consider the seeming unstoppability of p2p protocols for a
hint.
Adam
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Bitcoin-development] blind symmetric commitment for stronger byzantine voting resilience (Re: bitcoin taint & unilateral revocability)
2013-05-15 11:49 ` Adam Back
@ 2013-05-15 12:40 ` Caleb James DeLisle
2013-05-15 16:21 ` Adam Back
0 siblings, 1 reply; 18+ messages in thread
From: Caleb James DeLisle @ 2013-05-15 12:40 UTC (permalink / raw)
To: bitcoin-development
I can't see this working, if 51% of the mining power doesn't like your
coins, when you create the commitment they will reject it.
If the commitment is opaque at the time of inclusion in the block then
I will create multiple commitments and then after revealing the
commitment and spend to you I will reveal the earlier commitment which
commits the coins to an address I control.
On the topic of reversibility, I suspect in the long term the lack of
chargebacks will create issues as criminals learn that for the first
time in history, kidnap & ransom is effective. Suffice to say after the
first >= $10mn kidnapping-for-bitcoin heist, governments will be forced
to decide how they view the system. It will likely fall somewhere between
"arrest/question anyone identified holding tainted coins" to something
nonsensical and reactionary like "blocking" bitcoin as Iran does TOR.
Thanks,
Caleb
On 05/15/2013 07:49 AM, Adam Back wrote:
> On Wed, May 15, 2013 at 07:19:06AM -0400, Peter Todd wrote:
>> Protocols aren't set in stone - any attacker that controls enough
>> hashing power to pose a 51% attack can simply demand that you use a
>> Bitcoin client modified [to facilitate evaluation of his policy]
>
> Protocol voting is a vote per user policy preference, not a CPU vote, which
> is the point. Current bitcoin protocol is vulnerable to hard to prove
> arbitrary policies being imposable by a quorum of > 50% miners. The blind
> commitment proposal fixes that, so even an 99% quorum cant easily impose
> policies, which leaves the weaker protocol vote attack as the remaining
> avenue of attack. That is a significant qualitative improvement.
>
> The feasibility of protocol voting attacks is an open question, but you
> might want to consider the seeming unstoppability of p2p protocols for a
> hint.
>
> 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
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Bitcoin-development] blind symmetric commitment for stronger byzantine voting resilience (Re: bitcoin taint & unilateral revocability)
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
0 siblings, 2 replies; 18+ messages in thread
From: Adam Back @ 2013-05-15 16:21 UTC (permalink / raw)
To: Caleb James DeLisle; +Cc: bitcoin-development
On Wed, May 15, 2013 at 08:40:59AM -0400, Caleb James DeLisle wrote:
>If the commitment is opaque at the time of inclusion in the block then
>I will create multiple commitments and then after revealing the
>commitment and spend to you I will reveal the earlier commitment which
>commits the coins to an address I control.
Bit-commitments are based on deterministic one-way functions eg like SHA1(
SHA256( public key ) ) Obviously it has to be a different one-way function
to the coin address calculation which is RIPEMD( SHA256( public key ) ) as
that is already public. Alternatively it can be a different serialization
using the same hash eg RIPEMD( SHA256( 1 || public key ) ).
There is only one commitment possible per public key - so you can only
create one commitment that would validate to a receiver, or to the network.
The network checks that there are no non-blind double spends of committed
coins which it can do as spends require disclosure of the public key, which
allows existing commitments to be verified, and it similarly qchecks that
there are no blind double-commitments.
Each committed coin would be:
one-spend-commit = Com( spender pub ), Com( transaction )
where Com is implemented as the above hash. The network just places the
commitments in order as with conventional transactions.
The committed coins are not linkable to your non-blind coin because you did
not reveal your public key in the (largely passive) act of receiving to a
coin address.
>On the topic of reversibility, I suspect in the long term the lack of
>chargebacks will create issues as criminals learn that for the first
>time in history, kidnap & ransom is effective.
The temporary unlinkability (until commitment reveal) is a necessary side
effect, not a cryptographic anonymity feature like zerocoin. The
transactions are identical to bitcoins once revealed. How long the
committed transaction chains can be between reveals is an implementation
choice could be 1 hop, or as long as you like. (Actually it appears to be
up to the individual users how long the maximum chain they accept is - the
network itself, though ordering the committed spends (if there are multiple
spends on the same key) cant even tell how long the commitment payment
chains are).
Obviously the first coins in the network ordered committed coins on the same
key up to the coin value are spends as verified by the recipient, the rest
are double-spend and ignored. If someone wants to waste fees by sending
more spends than there inputs thats up to them.
Probably the typical user doesnt care about long committed chains other
than their wallet will bloat if the chains are too long, so probably they
would periodically compact it by revealing the long chains. Committed coins
are probably a bit less SPV client friendly, though with correct formatting
in the merkle trees between blocks, probably a committed coin holder can
provide enough proof to an SPV client to verify even multi-spend committed
coins directly (without a network feed).
About privacy, up to the entire commitment chain can be opened at any time
(to other people or to the bitcoin network in general) with the cooperation
of any user on the chain (up to the point they saw it), so while the blind
commitment protocol is not vulnerable to a > 50% power quorum unilaterally
imposed policy (without even needing client updates), it is fully dependent
on the good will of the recipients for its temporary unlinkability. Thats
the point: it puts policy control in the users hands not in the > 50% power
quorum.
If you want cryptographic anonymity its better to look to zerocoin. You may
have noticed zero coin talked about optional fraud tracing. Its usually
trivial to add tracing to an otherwise privay preserving protocol.
The blind commitment if implemented as described (and its not obvious how to
get more privacy from it) offers somewhat like community policing. Users on
the chain can still themselves do fraud tracing, or any policy they choose,
on any blind committed coins that they receive. If they dont like the
colour of them they can refund them. The point is to enforce that this is a
free uncoerced community choice, by individual end users, not a > 50% cpu
power quorum choice surreptitiously imposed.
Adam
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Bitcoin-development] blind symmetric commitment for stronger byzantine voting resilience (Re: bitcoin taint & unilateral revocability)
2013-05-15 16:21 ` Adam Back
@ 2013-05-15 18:01 ` Caleb James DeLisle
2013-05-15 23:40 ` Adam Back
1 sibling, 0 replies; 18+ messages in thread
From: Caleb James DeLisle @ 2013-05-15 18:01 UTC (permalink / raw)
To: bitcoin-development
On 05/15/2013 12:21 PM, Adam Back wrote:
> On Wed, May 15, 2013 at 08:40:59AM -0400, Caleb James DeLisle wrote:
>> If the commitment is opaque at the time of inclusion in the block then
>> I will create multiple commitments and then after revealing the
>> commitment and spend to you I will reveal the earlier commitment which
>> commits the coins to an address I control.
>
> Bit-commitments are based on deterministic one-way functions eg like SHA1(
> SHA256( public key ) ) Obviously it has to be a different one-way function
> to the coin address calculation which is RIPEMD( SHA256( public key ) ) as
> that is already public. Alternatively it can be a different serialization
> using the same hash eg RIPEMD( SHA256( 1 || public key ) ).
Ahh thanks for clearing that up, although it would limit the possibilities
of scripting it is silly of me not to think of it.
>
> There is only one commitment possible per public key - so you can only
> create one commitment that would validate to a receiver, or to the network. The network checks that there are no non-blind double spends of committed
> coins which it can do as spends require disclosure of the public key, which
> allows existing commitments to be verified, and it similarly qchecks that
> there are no blind double-commitments.
>
> Each committed coin would be:
>
> one-spend-commit = Com( spender pub ), Com( transaction )
>
> where Com is implemented as the above hash. The network just places the
> commitments in order as with conventional transactions.
>
> The committed coins are not linkable to your non-blind coin because you did
> not reveal your public key in the (largely passive) act of receiving to a
> coin address.
>
>> On the topic of reversibility, I suspect in the long term the lack of
>> chargebacks will create issues as criminals learn that for the first
>> time in history, kidnap & ransom is effective.
>
> The temporary unlinkability (until commitment reveal) is a necessary side
> effect, not a cryptographic anonymity feature like zerocoin. The
> transactions are identical to bitcoins once revealed. How long the
> committed transaction chains can be between reveals is an implementation
> choice could be 1 hop, or as long as you like. (Actually it appears to be
> up to the individual users how long the maximum chain they accept is - the
> network itself, though ordering the committed spends (if there are multiple
> spends on the same key) cant even tell how long the commitment payment
> chains are).
>
> Obviously the first coins in the network ordered committed coins on the same
> key up to the coin value are spends as verified by the recipient, the rest
> are double-spend and ignored. If someone wants to waste fees by sending
> more spends than there inputs thats up to them.
>
> Probably the typical user doesnt care about long committed chains other
> than their wallet will bloat if the chains are too long, so probably they
> would periodically compact it by revealing the long chains. Committed coins
> are probably a bit less SPV client friendly, though with correct formatting
> in the merkle trees between blocks, probably a committed coin holder can
> provide enough proof to an SPV client to verify even multi-spend committed
> coins directly (without a network feed).
>
> About privacy, up to the entire commitment chain can be opened at any time
> (to other people or to the bitcoin network in general) with the cooperation
> of any user on the chain (up to the point they saw it), so while the blind
> commitment protocol is not vulnerable to a > 50% power quorum unilaterally
> imposed policy (without even needing client updates), it is fully dependent
> on the good will of the recipients for its temporary unlinkability. Thats
> the point: it puts policy control in the users hands not in the > 50% power
> quorum.
That is indeed interesting. If I understand this properly Alice commits coins
to pay to Bob and gives Bob the transaction, Bob then commits to pay to Charlie
and gives him the related transaction. If Charlie wants to collect the bitcoin
he then reveals Alice's transaction and Bob's.
I think what you're trying to do is *almost* possible now (ab)using BIP-0016
In the output of the previous tx you put:
OP_HASH160 [20-byte-hash-value] OP_EQUAL
and in the next tx you use a new type of input which specifies it's value but
not the output which is spent. In the input script you place:
OP_DUP OP_1ADD OP_HASH160 [20-byte-hash-value] OP_EQUALVERIFY
Then a serialized script containing the normal stuff as well as the last
transaction hash and output index would be passed around out of band and the
validating nodes would execute each script with a shared stack, beginning with
the out of band one, then the input one (the OP_EQUALVERIFY) then the output.
When the serialized sigscript reaches the bottom of the stack, having been
verified twice, it will now be evaluated as per the rules of P2SH.
None of this probably works in the real world since I'm not familiar with the
actual implementation of P2SH and it probably has quite a number of things
which will break if used this way but it is interesting to see that in theory
it is possible with little change to the protocol (just a new input format).
Thanks,
Caleb
>
> If you want cryptographic anonymity its better to look to zerocoin. You may
> have noticed zero coin talked about optional fraud tracing. Its usually
> trivial to add tracing to an otherwise privay preserving protocol.
>
> The blind commitment if implemented as described (and its not obvious how to
> get more privacy from it) offers somewhat like community policing. Users on
> the chain can still themselves do fraud tracing, or any policy they choose,
> on any blind committed coins that they receive. If they dont like the
> colour of them they can refund them. The point is to enforce that this is a
> free uncoerced community choice, by individual end users, not a > 50% cpu
> power quorum choice surreptitiously imposed.
>
> Adam
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Bitcoin-development] blind symmetric commitment for stronger byzantine voting resilience (Re: bitcoin taint & unilateral revocability)
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
1 sibling, 1 reply; 18+ messages in thread
From: Adam Back @ 2013-05-15 23:40 UTC (permalink / raw)
To: Caleb James DeLisle; +Cc: bitcoin-development
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Bitcoin-development] blind symmetric commitment for stronger byzantine voting resilience (Re: bitcoin taint & unilateral revocability)
2013-05-15 23:40 ` Adam Back
@ 2013-05-16 1:24 ` Gavin
2013-05-16 1:39 ` Gregory Maxwell
0 siblings, 1 reply; 18+ messages in thread
From: Gavin @ 2013-05-16 1:24 UTC (permalink / raw)
To: Adam Back; +Cc: bitcoin-development
Busy with pre-conference stuff, not following details of this conversation...
... but it sounds a lot like the "guy fawkes" protocol Zooko was thinking about a year or so ago.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Bitcoin-development] blind symmetric commitment for stronger byzantine voting resilience (Re: bitcoin taint & unilateral revocability)
2013-05-16 1:24 ` Gavin
@ 2013-05-16 1:39 ` Gregory Maxwell
2013-05-16 2:22 ` Mike Hearn
0 siblings, 1 reply; 18+ messages in thread
From: Gregory Maxwell @ 2013-05-16 1:39 UTC (permalink / raw)
To: Gavin; +Cc: bitcoin-development
On Wed, May 15, 2013 at 6:24 PM, Gavin <gavinandresen@gmail•com> wrote:
> Busy with pre-conference stuff, not following details of this conversation...
>
> ... but it sounds a lot like the "guy fawkes" protocol Zooko was thinking about a year or so ago.
Sort of, but in a guy fawkes signature you use the commitment to hide
the preimage that proves you had authority to spend a coin. Adam
proposes you do this in order to hide _which coin you're spending_.
This has obvious anti-DOS complications, but Adam deftly dodged my
initial attempts to shoot him down on these grounds by pointing out
that you could mix blinded and blinded inputs and have priority and
transaction fees come from only the unblinded ones.
Effectively, it means that so long as you could convince the network
to let you spend some coins, you could also spend other ones along for
the ride and the network wouldn't know which ones those were until it
was too late for it to pretend it never saw them.
I think there are all kinds of weird economic implications to this— a
blinded payment would seem to have a different utility level to an
unblinded one: you can't use it for fees— except you can unblind it at
any time. And the discontinuousness ("two types of inputs") and that
it would enable mining gibberish (though perhaps not data storage, if
you see my preimage solution to that) seems awkward and I think I have
to spend some time internalizing it before I can really think through
the implications.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Bitcoin-development] blind symmetric commitment for stronger byzantine voting resilience (Re: bitcoin taint & unilateral revocability)
2013-05-16 1:39 ` Gregory Maxwell
@ 2013-05-16 2:22 ` Mike Hearn
2013-05-16 2:45 ` Gregory Maxwell
0 siblings, 1 reply; 18+ messages in thread
From: Mike Hearn @ 2013-05-16 2:22 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 2556 bytes --]
Conceptually it sounds a lot like ZeroCoin (not in implementation)?
I'm not really convinced miner cartels that try to exclude transactions are
likely to be a big deal, but such schemes could I suppose be kept in a back
pocket in case one day I'm proven wrong.
On Wed, May 15, 2013 at 6:39 PM, Gregory Maxwell <gmaxwell@gmail•com> wrote:
> On Wed, May 15, 2013 at 6:24 PM, Gavin <gavinandresen@gmail•com> wrote:
> > Busy with pre-conference stuff, not following details of this
> conversation...
> >
> > ... but it sounds a lot like the "guy fawkes" protocol Zooko was
> thinking about a year or so ago.
>
> Sort of, but in a guy fawkes signature you use the commitment to hide
> the preimage that proves you had authority to spend a coin. Adam
> proposes you do this in order to hide _which coin you're spending_.
>
> This has obvious anti-DOS complications, but Adam deftly dodged my
> initial attempts to shoot him down on these grounds by pointing out
> that you could mix blinded and blinded inputs and have priority and
> transaction fees come from only the unblinded ones.
>
> Effectively, it means that so long as you could convince the network
> to let you spend some coins, you could also spend other ones along for
> the ride and the network wouldn't know which ones those were until it
> was too late for it to pretend it never saw them.
>
> I think there are all kinds of weird economic implications to this— a
> blinded payment would seem to have a different utility level to an
> unblinded one: you can't use it for fees— except you can unblind it at
> any time. And the discontinuousness ("two types of inputs") and that
> it would enable mining gibberish (though perhaps not data storage, if
> you see my preimage solution to that) seems awkward and I think I have
> to spend some time internalizing it before I can really think through
> the implications.
>
>
> ------------------------------------------------------------------------------
> 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
>
[-- Attachment #2: Type: text/html, Size: 3339 bytes --]
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Bitcoin-development] blind symmetric commitment for stronger byzantine voting resilience (Re: bitcoin taint & unilateral revocability)
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
0 siblings, 2 replies; 18+ messages in thread
From: Gregory Maxwell @ 2013-05-16 2:45 UTC (permalink / raw)
To: Mike Hearn; +Cc: bitcoin-development
On Wed, May 15, 2013 at 7:22 PM, Mike Hearn <mike@plan99•net> wrote:
> Conceptually it sounds a lot like ZeroCoin (not in implementation)?
Zerocoin conceals the connection from everyone forever, assuming the
underlying trapdoor problem is computational infeasible, but at great
cost.
Adamcoin, depending on how its done, at most conceals the transactions
from people who aren't a party to them... though as time goes on
eventually everyone becomes a party to a sufficiently old coin, and
avoiding publication creates quadratic costs in evaluating a private
clique's claims.... so instead an implementation would make the
identities public but only once they're burred a bit.
Perhaps an extreme version of the idea is easier to understand. Ignore
DOS attacks for a moment and pretend there is never any address reuse:
Everyone creates txouts paying a P2SH addresses that have a OP_PUSH
nonce in them and tell you recipient the nonce out of band.
When the recipients spend those coins they provide the script but not the nonce.
The recipient knows what coins he's spending, but the public does not.
The public can tell there is no double spend though, because they'd
see the same script twice. The person he's paying may be skeptical
that he actually has any coin and didn't just mine some gibberish, but
our spender tells that their receiver the nonce, and that person can
see the coin available for spending in the chain and also see that
there are no double spends.
This could actually go on forever with no ambiguity over who owns
what, but the out of band proofs that you have to give people when you
spend coins would grow with the history of the coins.
Since there wouldn't be much privacy once a transaction was
sufficiently split up in any case, you instead just publish the
unblindings once transactions are sufficiently buried. Thus bounding
the growth of the proofs. The reason I say I need to internalize
this more is mostly that I need to think about attacks on the
publication for 'tained' transactions being more or less isomorphic
to just refusing to allow spending of the 'tainted' coins in any case.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Bitcoin-development] blind symmetric commitment for stronger byzantine voting resilience (Re: bitcoin taint & unilateral revocability)
2013-05-16 2:45 ` Gregory Maxwell
@ 2013-05-16 5:52 ` Caleb James DeLisle
2013-05-16 11:32 ` Adam Back
1 sibling, 0 replies; 18+ messages in thread
From: Caleb James DeLisle @ 2013-05-16 5:52 UTC (permalink / raw)
To: bitcoin-development
Not only does the size of the proof grow endlessly as the coin is
passed around, the size of the UTXO set grows endlessly as more and
more of the already spent coins cannot be proven to have been spent
because the proofs are passed out-of-band. I never said the idea was
good, just interesting :)
Thanks,
Caleb
On 05/15/2013 10:45 PM, Gregory Maxwell wrote:
> On Wed, May 15, 2013 at 7:22 PM, Mike Hearn <mike@plan99•net> wrote:
>> Conceptually it sounds a lot like ZeroCoin (not in implementation)?
>
> Zerocoin conceals the connection from everyone forever, assuming the
> underlying trapdoor problem is computational infeasible, but at great
> cost.
>
> Adamcoin, depending on how its done, at most conceals the transactions
> from people who aren't a party to them... though as time goes on
> eventually everyone becomes a party to a sufficiently old coin, and
> avoiding publication creates quadratic costs in evaluating a private
> clique's claims.... so instead an implementation would make the
> identities public but only once they're burred a bit.
>
> Perhaps an extreme version of the idea is easier to understand. Ignore
> DOS attacks for a moment and pretend there is never any address reuse:
>
> Everyone creates txouts paying a P2SH addresses that have a OP_PUSH
> nonce in them and tell you recipient the nonce out of band.
>
> When the recipients spend those coins they provide the script but not the nonce.
>
> The recipient knows what coins he's spending, but the public does not.
>
> The public can tell there is no double spend though, because they'd
> see the same script twice. The person he's paying may be skeptical
> that he actually has any coin and didn't just mine some gibberish, but
> our spender tells that their receiver the nonce, and that person can
> see the coin available for spending in the chain and also see that
> there are no double spends.
>
> This could actually go on forever with no ambiguity over who owns
> what, but the out of band proofs that you have to give people when you
> spend coins would grow with the history of the coins.
>
> Since there wouldn't be much privacy once a transaction was
> sufficiently split up in any case, you instead just publish the
> unblindings once transactions are sufficiently buried. Thus bounding
> the growth of the proofs. The reason I say I need to internalize
> this more is mostly that I need to think about attacks on the
> publication for 'tained' transactions being more or less isomorphic
> to just refusing to allow spending of the 'tainted' coins in any case.
>
> ------------------------------------------------------------------------------
> 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
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Bitcoin-development] blind symmetric commitment for stronger byzantine voting resilience (Re: bitcoin taint & unilateral revocability)
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
1 sibling, 1 reply; 18+ messages in thread
From: Adam Back @ 2013-05-16 11:32 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: bitcoin-development
On Wed, May 15, 2013 at 07:45:34PM -0700, Gregory Maxwell wrote:
>[committed coins] depending on how its done, at most conceals the
>transactions from people who aren't a party to them... though as time goes
>on eventually everyone becomes a party to a sufficiently old coin, and
>avoiding publication creates quadratic costs in evaluating a private
>clique's claims.... so
I believe the coin size and verification cost is linear not quadratic, but
maybe it depends on the parameter you're measuing in. The coin size is
linear with the number of committed (uncompacted) spends. You can view
reveals as committed compaction. For efficiency a recipient of a committed
coin may as well compact and spend in one transaction so no new messages are
created.
Btw I believe if one were concerned about the committed coin size, I can see
a small tweak that would keep the size of the committed coins small eg
256-bit regardless of number of spends (no longer grows), and let the block
store the encrytped & MACed commitment. Then compaction is no longer a
concern. However I think that is SPV -> SPV client unfriendly. (A full
client -> SPV client should still be workable as the full client could
alternatively send the client the MACed data and key, rather than have him
look at it from his block history.) (Crypto sketch below).
However I am not sure multi-spend committed coin size is really a concern
because to the extent people hold long commitments without revealing to the
network for the long term, that is a bandwidth saving to the network.
Overall about privacy it would be typically temporary, though the peers have
the technical means to react and defend themselves by using longer committed
chains if dishonest mining is detected on a significant scale.
>instead an implementation would make the identities public but only once
>they're burred a bit.
That was the seed idea. The more aggressive "spend lots of times in
committed form" is just a technical threat that will keep dishonest mining
in check. By definition the coin is already irrevocably spent before the
reveal (without the threat of having the dishonest miners endlessly redoing
their own deeply burried work). The only person who could be punished by
policy by >50% dishonest miner (retroactively) is the recipient, not the
spender, and the punishment is very muted: all he can do is prevent coin
compaction. If the committed coins are small, compact doesnt even hurt the
committed coin user, just network itself. Therefore a dishonest miner is
wasting his time his dishonesty cant enforce his dishonest policy.
To store the commitments in the block chain replace:
> (blind-sender, auth-tag, tx-commit)
>
> blind-sender = SHA1( SHA256( 1, pub ) )
> auth = HMAC-SHA256-128( K, tx-commit )
> tx-commit = SHA-256( tx )
> K = SHA-256( pub )
with:
(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 )
then a reveal is just to send the recipient the public key (32 bytes)
per hop, still linear but ~3x smaller.
I suggested fixed size committed coin spends, that also you can do but with
public key crypto needed probably, and so dropping to the verification
efficiency of standard transactions. Sketch 2:
(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.)
You dont need to verify a second signature inside the tx-commit because you
already signed the encrypted-tx which binds to it (encryption with out MAC
is malleable but you cant change it at all without invalidating the
encryption). Just need to check the input tx in the tx-commit has P as its
recipient. P does not even need to go into tx-commit as its already bound
by cP and signature security (cant create a signature with someone elses
key). So I think the commited coins of this form are the same size and
verification cost for the network. And small and fixed size to spend
offline. (32+32=64 bytes fixed).
Adam
(*) You should not as a principle re-use keys across algorithms, I omitted a
second key for simplicity. Really K1 = SHA256( 1||pub ), K2 = SHA256(
2||pub ) encrypted-tx-commit = AES( K1, tx-commit ), auth = HMAC( K2,
encrypted-tx-committ ). Or more simply a combined authenticated mode like
CCM or GCM and a single key managed by the mode.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Bitcoin-development] blind symmetric commitment for stronger byzantine voting resilience (Re: bitcoin taint & unilateral revocability)
2013-05-16 11:32 ` Adam Back
@ 2013-05-16 14:51 ` Adam Back
0 siblings, 0 replies; 18+ messages in thread
From: Adam Back @ 2013-05-16 14:51 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: bitcoin-development
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.
^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2013-05-16 14:51 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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 is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox