A regular transaction is just a collection of inputs (coins spent) and outputs (coins produced):
Code:
payload: {
inputs: [...],
outputs: [...]
}
All of that is public, and everybody sees who spent what and to whom. Also, everybody can validate the transaction.
Now, Alice and Bod don't want to show their transactions to the entire world, and Alice hashes the above payload and stores only the hash on the public database. At the same time, Alice sends the payload itself directly to Bob. Along with payload hash, she also stores the spend proof, which is a hash of the input. So, this is what she posts to the public database:
Code:
private_transaction: {
payload_hash: ".....",
spend_proof: "......"
}
Both hashes posted to the public database are obviously meaningless for all third parties, they can learn nothing from Alice's transaction except the fact that she sent _some_ transaction.
By making the spend proof public, we enable everybody to verify that the same input is not spent twice, as the same input will produce the same spend proof.
Byteball way :
Alice creates a txn that has her 10(could be hidden) input and a 10 output to Bob.
Alice generates a random number, that she will need to share with Bob, along with ALL the previous proofs in the chain(if her 10 is hidden), to decode the spend proofs.
Alice creates a txn that has her 10(could be hidden) input and a 10 output to Bob.
Alice generates a random number, that she will need to share with Bob, along with ALL the previous proofs in the chain(if her 10 is hidden), to decode the spend proofs.
Previous proofs (spend proofs) are already public, they don't need to be sent directly. What is sent directly from Alice to Bob is previous payloads (plaintext inputs and outputs), which allow Bob to verify that the corresponding payload hashes and spend proofs do exist in the public database.
Quote
Alice 'hashes-the-txn' with the random number. (There are a few steps here..)
The random number is added as part of output, it is not something external. It's purpose is to make preimaging of the spend proof impossible, you can safely ignore this part for initial understanding.Quote
(This keeps the spend address visible for the network to check, but hides the rest.?)
Correct, the network sees only the fact that Alice spent something, and here the network's knowledge ends.Quote
Alice sends the txn to the network and the spend proof to Bob. Who can then check for himself that the txn is what Alice says it is. And that all the parents are also valid.
Actually, the opposite: the spend proof is sent to the network (along with payload hash) while the plaintext transaction is sent to Bob.Quote
The network knows that Alice has spent the 10(or hidden value). but doesn't know to who or for how much.
The network doesn't know how much Alice spent, see above.Quote
The network doesn't know that Bob has a spendable output. So how does Bob then make a spend ? I know he knows, and he can prove the the next person, but the network won't have a record - so ..?
It's enough that Bob and all subsequent owners of the coin know that, the network doesn't need this knowledge.
