Well I am saying the dishonest miners must not be able to guess with good confidence that the transaction involves tainted coins or other information like who is paying or receiving, or they can reject them even though they are blinded, ie if that happens the blinding was ineffective.

About necessity of using addresses & public keys: one clear requirement is that double spending must be prevented, and the way that works is that if you double spend a non-blind version of an unspent output then a signature is provided to prove ownership of the output.  And a signature always includes the public key to allow the signature to be verified.  The public key was previously unknown (before spending) and so could serve as a blinding factor

So the main trick is that if the public key is used as the only non-public blinding factor, then double spending in non-blind form will unblind and expose double spend attempts.

We cant use eg the recipients address in as the blinding-factor because we want one recipient to be able to tell that the sender tried to double spend an output with another recipient.  If the recipient doesnt know the other recipients address, he would be unable to detect double-spending.

So the commitment looks like

(com1,com2) = SHA1( SHA256( pub ) ), AES-CCM( key, transaction )

where key = SHA256( pub ).

There has to be separate blinding per unspent output used because the UTXOs could be double-spent separately.  So a blind transaction could include a list of blind commitments and a plaintext fee to pay for the processing of the blind transaction.  The fee should be extremely taint free.  The fee may optionally be paid by the recipient.

Adam

I tried to retain the existing bitcoin semantic that first spend is valid, later double-spends are invalid and rejected (whether the spend is blind or non-blind).

I think what you said was that it could be possible to have unblind transactions take priority over blind transactions.  You could define it that way but it might create problems I think.  Eg say you accept  a blind transaction after one confirmation then you pay it to someone else.  But the second block has a double-spend with a non-blind transaction in it.  Now according to the one block confirmation view the blind transaction is valid, but according to the two block confirmation view the non-blind transaction is valid (and the blind one invalid).  What if you try to spend it with someone who expects two block confirmations, and goes and looks and sees that according to that definition the blind coin should be rejected?

Its somewhat but not quite analogous with the confirmations required in bitcoin now, because those can only be undone by orphans which are expected to be increasingly rare (longer orphan chain is increasingly less likely) or require a lot of resources by a dishonest entity to create.

Conversely revealing a non-blind transaction has no cost and can be done at any time for no cost by the original owner.  Maybe it has no effect if it happens after a given number of confirmations.  eg if everyone agreed that six confirmations were always required, then it could work, as the recipient can just check that there are no overriding non-blind transactions during the six blocks that came after the blind transaction.  So I think the problem is if people have differing preferences for how many blocks of confirmation they require (of no double-spend event happening) then one type of transaction (non-blind) overriding another type of transaction (blind) becomes a problem.

Adam

Yes, I think censoring transaction reveals matters less because the transaction has actually already completed in blind form, and can continue to be spent in blind form.


If the dishonest miners have a lot more power than honest miners so that they could forcibly make any acceptance of honest reveals into orphans yes.  Though payments can continue.

Also I notice that there is no actual need for mining of reveals, they were already mined in blind form.  They can simply be made available p2p for download by user clients.  They can easily be verified as correct with out need for high hashing power confirmations, the only validation needed is that they hash to a previous blind commit in the block chain.


I think the wallet storage for a blind transaction even after a long chain is simply the set of public keys for the addresses in the last hop unspent output set.  That is because you can validate a blind coin by iterating backwards if you have the last hop public keys, you can decrypt the commitment.  Then you see the public key of the previous hop, so you fetch the previous committed transaction, decrypt it and get keys for next hop etc until you reach a mined coin or a non-blind transaction.  So the wallet itself doesnt really grow. 

The validation procedure becomes longer and eventually the privacy eroded if many users are party to it (each user only has visibility of the transactions before, not after; but a user being the last hop in a long chain sees a lot of history).  No worse than now, just not helping privacy that much long term.


I think the answer maybe above, to not require reveals to be hashed a second time into the block. 
Just have peers make them available for download, there is no DoS as they can be validated back to their hash which is already cemented into the block chain in blind form.  If no mining is required on reveals, then there is no need to trust miners to process them.  And users can reveal at their convenience without the need for cooperation from miners.


Its hard to allocate blame.  The dishonest miner may say it is the revealer that dropped the connection part way through and so falsely claim he never received it.

Adam

Hmm, come to think of it, not even the fees need to be in the block, as long as the miner has seen the actual transactions.

So, if ordering is all the miners are doing, then validation isn't even necessary, because individual clients could do it. Double spends could silently bounce, as I understand they do in the Ripple ledger. I hadn't thought about flooding spamming, which is an important point.

In Bitcoin the miners are responsible for creating the block and therefore ensuring the transaction inputs and outputs all balance out and performing other validation checks prior to inclusion into a block.   Are you saying that there are no validation checks for a transaction to be included in a block?

Don't you still need to validate enough to be able to collect the fees and stop spammers?

As I understand it, miners validate each other's work in the bitcoin network.  So even if a powerful miner builds the block, other miners verify the block after creation.   So in your scenario, how do the miners keep a check on each other?  That is, if there is nothing to validate, what then do they check to see if nobody is attacking the network?

Followiing.