📅 Original date posted:2016-08-10
📝 Original message:> 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 at 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 at 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 at 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?
>> >
Tony Churyumoff [ARCHIVE] /
npub1nk…pugay
2023-06-07 17:52:30
in reply to nevent1q…d4fk
Author Public Key
npub1nk74067d6t4s9rxlad2ldmpr5wfe3uaquafs8hgklwlmh35y97gqrpugayPublished at
2023-06-07 17:52:30Event JSON
{
"id": "0e18266fe7fbcf0fa0b9b85cafcefb535680c75f8a516eb31fe20390803b2eae",
"pubkey": "9dbd57ebcdd2eb028cdfeb55f6ec23a39398f3a0e75303dd16fbbfbbc6842f90",
"created_at": 1686160350,
"kind": 1,
"tags": [
[
"e",
"ae333d0f17a38f0d93813c9365e2b4c52ff978cb9edb0ac873b1bbe342d91c71",
"",
"root"
],
[
"e",
"5d1878c45b739cd5316187f036333113b5f6398aa90a1ace15435ea9d5ecc06d",
"",
"reply"
],
[
"p",
"52e5d0646af3ea5ccb6c4bd31237d6068258a11ace3ac40f02466a3f89342928"
]
],
"content": "📅 Original date posted:2016-08-10\n📝 Original message:\u003e Signed by the key pair that was referenced in the output of the on-chain\n\u003e transaction?\n\nSigned by the key pair referenced in the private output.\n\n\u003e (Bob in my example, actually)\n\nI misread your example. If it was Bob, then the troll couldn't\ngenerate the correct spend proof because he didn't see the private\noutput C. The troll could try to replay the spend proof in the\nAlice's transaction as soon as he sees it in the mempool, but then the\nspend proof would be signed by the wrong user.\n\n\u003e Doesn't that mean it's easy to\n\u003e follow who is paying whom, you just can't see how much is going to reach\n\u003e recipient?\n\nOnly the recipients of the private outputs can see the previous owners\nof the coins they receive (including amounts). What everybody else\nsees, is just meaningless hashes that hide both the recipient of the\ncoin and the amount.\n\n\n2016-08-10 7:31 GMT+03:00 James MacWhyte \u003cmacwhyte at gmail.com\u003e:\n\u003e Signed by the key pair that was referenced in the output of the on-chain\n\u003e transaction? (Bob in my example, actually) Doesn't that mean it's easy to\n\u003e follow who is paying whom, you just can't see how much is going to reach\n\u003e recipient?\n\u003e\n\u003e On Tue, Aug 9, 2016, 04:40 Tony Churyumoff \u003ctony991 at gmail.com\u003e wrote:\n\u003e\u003e\n\u003e\u003e This troll is harmless. A duplicate spend proof should also be signed\n\u003e\u003e by the same user (Alice, in your example) to be considered a double\n\u003e\u003e spend.\n\u003e\u003e\n\u003e\u003e 2016-08-09 3:18 GMT+03:00 James MacWhyte \u003cmacwhyte at gmail.com\u003e:\n\u003e\u003e \u003e One more thought about why verification by miners may be needed.\n\u003e\u003e \u003e\n\u003e\u003e \u003e Let's say Alice sends Bob a transaction, generating output C.\n\u003e\u003e \u003e\n\u003e\u003e \u003e A troll, named Timothy, broadcasts a transaction with a random hash,\n\u003e\u003e \u003e referencing C's output as its spend proof. The miners can't tell if it's\n\u003e\u003e \u003e valid or not, and so they include the transaction in a block. Now Bob's\n\u003e\u003e \u003e money is useless, because everyone can see the spend proof referenced\n\u003e\u003e \u003e and\n\u003e\u003e \u003e thinks it has already been spent, even though the transaction that\n\u003e\u003e \u003e claims it\n\u003e\u003e \u003e isn't valid.\n\u003e\u003e \u003e\n\u003e\u003e \u003e Did I miss something that protects against this?\n\u003e\u003e \u003e",
"sig": "10b8f832477a94e72ac1089eac0967e787d7700a41390d15cf03a66b5b10d9ca08688b352b248b41922345857f22e30ebc95fbbee697e56c5c51a71f003e9238"
}