Re: [bitcoin-dev] Hiding entire content of on-chain transactions

[Tony Churyumoff <tony991@gmail.com>]

> 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 <macwhyte@gmail.com>:
> 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 <tony991@gmail.com> 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 <macwhyte@gmail.com>:
>> > 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?
>> >