> Signed by the key pair that was referenced in the output of the on-chain > transaction?
Signed by the key pair referenced in the private output. > (Bob in my example, actually) I misread your example. If it was Bob, then the troll couldn't generate the correct spend proof because he didn't see the private output C. The troll could try to replay the spend proof in the Alice's transaction as soon as he sees it in the mempool, but then the spend proof would be signed by the wrong user. > Doesn't that mean it's easy to > follow who is paying whom, you just can't see how much is going to reach > recipient? Only the recipients of the private outputs can see the previous owners of the coins they receive (including amounts). What everybody else sees, is just meaningless hashes that hide both the recipient of the coin and the amount. 2016-08-10 7:31 GMT+03:00 James MacWhyte <[email protected]>: > Signed by the key pair that was referenced in the output of the on-chain > transaction? (Bob in my example, actually) Doesn't that mean it's easy to > follow who is paying whom, you just can't see how much is going to reach > recipient? > > On Tue, Aug 9, 2016, 04:40 Tony Churyumoff <[email protected]> wrote: >> >> This troll is harmless. A duplicate spend proof should also be signed >> by the same user (Alice, in your example) to be considered a double >> spend. >> >> 2016-08-09 3:18 GMT+03:00 James MacWhyte <[email protected]>: >> > One more thought about why verification by miners may be needed. >> > >> > Let's say Alice sends Bob a transaction, generating output C. >> > >> > A troll, named Timothy, broadcasts a transaction with a random hash, >> > referencing C's output as its spend proof. The miners can't tell if it's >> > valid or not, and so they include the transaction in a block. Now Bob's >> > money is useless, because everyone can see the spend proof referenced >> > and >> > thinks it has already been spent, even though the transaction that >> > claims it >> > isn't valid. >> > >> > Did I miss something that protects against this? >> > _______________________________________________ bitcoin-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
