Going back to the commit definition (symmetric version, with defense against insider commit to junk):
you're saying that Alice broadcasts the blind commitment to the network, then Bob doesn't de-commit and just sends Alice the merchandise
yes Bob accepts the blind commitment payment after waiting however many confirmations he requires. He does have the decommitted value Alice sent him directly (without broadcasting) so he can validate.
then Alice tries to double-spend her input with a secondary non-blind txn and networks respects Alice's secondary txn
if Alice double spends non-blind she definitionally reveals her public key, and so allows anyone to correlate with any blind commitments with the same key, and validate them, and so presuming the blind commitments are not all fakes, the secondary txn is rejected unless there are remaining sufficient funds on the address to fulfill it also.
Alternatively if Alice tried to double spend in blind committed form, the committed sender address would be the same and the recipient who needs to validate would receive the decomitted value over a private channel, and be able to validate the committed transactions. (Validation includes discarding junk commitments).
and then Bob decommits and reveals to the network that Alice actually double-spent her input, so the network nodes reverse their earlier decision and now respect Bob's decommitted txn and dismiss Alice's secondary txn?
No reversing. See above the secondary (double-spent non-blind) txn is rejected. So decommiting the first (committed) transaction just optionally exposes more details about the committed transaction.
Overall the picture with blind and non-blind transactions however you mix them and whichever comes first and how much money is left on the input address after processing, is just like standard transactions. First is accepted, later are rejected as double spends. Despite the blinding you can still tell because two blind committed transactions with the same input address are hashed deterministically so SHA1( SHA256( pub ) ) is the same in both cases. If you send a non-blind transaction that is also correlatable to blind addresses because the public key is revealed as part of the signature.
Therefore, as far as I can see, your statement here that "committed coin cant be locked by someone malicious who knows the public key" is false. The only way that you demonstrated that prevents double-spending by Alice, unless I'm missing something, is not to allow what you said here and instead use your previous suggestion so that when Alice attempts to double-spend she reveals her pubkey and then the network nodes compute the secondary deterministic hash e.g. SHA1(SHA256(pubkey)) and verify that there are no earlier blind txns with this pubkey. If what I claim is true, then an attacker who obtains a pubkey can instantly lock the corresponding coins forever, and we must guarantee that no one will even send coins to the same hashed pubkey address more than once.
OK this is a second issue - an insider who knows pub, was an issue with the straight hash-based commitment of the transaction. This is why I said in a later mail (as quoted at the top of this message) encrypting and use of a MAC is more robust, and safely allows multiple use addresses, because it defends against that issue.
As you indicate preventing other users sending multiple times to the same address is problematic.
If I'm wrong, please demonstrate how Bob could send his merchandise to Alice before decommitting in public (which means that the hashpower majority can impose their policies), without giving Alice the opportunity to double-spend.
so lets say Alice is malicious, Eve is malicious but doesnt know pub, Mallory is malicious and does know pub (eg because she gave the committed coin to Alice) but Bob wants to send Alice her goods after 1 confirmation anyway provided there is no double spending within that time-period.
Com( pub, tx-commit ) = (blind-sender, auth, encrypted-tx-commit)
blind-sender = SHA1( SHA256( pub ) )
auth = HMAC-SHA256-128( K, encrypted-tx-commit )
encrypted-tx-commit = AES( K, tx-commit )
K = SHA-256( pub )
(A: indicates A broadcasts, A->B: indicates A sends to B private channel)
Alice: Com( A, "A spends 1BTC to B" )
Alice -> Bob: pub
Alice: Com( A, "A spends 1BTC to A" )
Eve: blind-sender, auth, junk [blind-sender & auth copied from Alice commit]
Mallory: Com( A, "A spends 1BTC to M" )
Eve -> Bob
[cant send pub as doesnt know it]
Mallory -> Bob: pub
Bob can validate Alice's first spend as he has the pub.
Bob can also validate Alice's attempted double spend to herself. However so long as the confirmation rejects the second one, it doesnt matter. Normal bitcoin double spend semantics: first spend to reach the winning miner is valid.
now Bob can see that Eve's message is junk because the junk doesnt match the auth tag.
Bob cant tell as easily with Mallory's message as she has pub and so K; but still the tx-commit
decrypted from Mallory's message has no valid signature, as Mallory can not forge signature with Alice's key.
Bob waits 1 confirmation, and as the double spend from Alice to herself was not hashed by the winning miner, and the two fake commits from Eve and Mallory are the only other transactions relating to Alice's input, he accepts and sends the goods.
Bob nor Alice have to reveal. They may opt to decommit after the transaction is long confirmed.
Bob can pay Carol who can pay Dave etc all without necessarily decommitting.
Each person in the chain of committed spends must see all transaction details earlier in the chain to verify its validity. They learn this conveniently because they see the public key of the tx-commit, and from that can see the public key of the sender. That in turn allows them to lookup the SHA1( SHA256( pub ) ) of the sender, and from that transaction learn the pub key of the previous sender and so on until they see a non-committed transaction, or a mined coin.
Adam
