📅 Original date posted:2015-06-16
📝 Original message:On Mon, Jun 15, 2015 at 1:59 PM, Kalle Rosenbaum <kalle at rosenbaum.se> wrote:
> 2015-06-15 12:00 GMT+02:00 Pieter Wuille <pieter.wuille at gmail.com>:
> I'm not sure if we will be able to support PoP with CoinJoin. Maybe
> someone with more insight into CoinJoin have some input?
>
Not really. The problem is that you assume a transaction corresponds to a
single payment. This is true for simple wallet use cases, but not
compatible with CoinJoin, or with systems that for example would want to
combine multiple payments in a single transaction.
> > Also, if I understand correctly, there is no commitment to anything
> you're
> > trying to say about the sender? So once I obtain a proof-of-payment from
> you
> > about something you paid, I can go claim that it's mine?
>
> I don't understand this. The pop includes a nonce randomly generated
> by the server. If you're very lucky, 1/(2^48) per try, you can reuse a
> pop.
>
>
I owe you an apology here, for judging based on the summary you posted
rather than reading the actual text.
48 bits seems low to me, but it does indeed solve the problem. Why not 128
or 256 bits?
> Why does anyone care who paid? This is like walking into a coffeshop,
> > noticing I don't have money with me, let me friend pay for me, and then
> have
> > the shop insist that I can't drink it because I'm not the buyer.
>
> If you pay as you use the service (ie pay for coffee upfront), there's
> no need for PoP. Please see the Motivation section. But you are right
> that you must have the wallet(s) that paid at hand when you issue a
> PoP.
>
> >
> > Track payments, don't try to assign identities to payers.
>
> Please elaborate, I don't understand what you mean here.
>
I think that is a mistake. You should not assume that the wallet who held
the coins is the payer/buyer. That's what I said earlier; you're implicitly
creating an identity (the one who holds these keys) based on the
transaction. This seems fundamentally wrong to me, and not necessary. The
receiver should not care who paid or how, he should care what was payed for.
The easiest solution to this IMHO would be an extension to the payment
protocol that gives you (or your wallet) a token in return for paying, and
that knowledge of that token is used to gain access to the services you
provide.
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150616/75813f1f/attachment.html>;
Pieter Wuille [ARCHIVE] /
npub1tj…jtl6r
2023-06-07 15:36:54
in reply to nevent1q…2x78
Author Public Key
npub1tjephawh7fdf6358jufuh5eyxwauzrjqa7qn50pglee4tayc2ntqcjtl6rPublished at
2023-06-07 15:36:54Event JSON
{
"id": "543fd22b66e33701a51fb91048afa6ae3a8d49266586d170004cd1e1b7bc1578",
"pubkey": "5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6",
"created_at": 1686152214,
"kind": 1,
"tags": [
[
"e",
"e1766602ba0f6768319a1583d11fb84dd1782fa79b735d969ef1342e648fd1da",
"",
"root"
],
[
"e",
"d9fa1351a3b0ad63717aee0dd3ad1e30fbfba48c9cd2cfbc3886c3a2dacde629",
"",
"reply"
],
[
"p",
"e39d9ce3b0ed9cbb17528b25bb4b33bcee465476e44ea5980fb6f2693b97ab95"
]
],
"content": "📅 Original date posted:2015-06-16\n📝 Original message:On Mon, Jun 15, 2015 at 1:59 PM, Kalle Rosenbaum \u003ckalle at rosenbaum.se\u003e wrote:\n\n\u003e 2015-06-15 12:00 GMT+02:00 Pieter Wuille \u003cpieter.wuille at gmail.com\u003e:\n\u003e I'm not sure if we will be able to support PoP with CoinJoin. Maybe\n\u003e someone with more insight into CoinJoin have some input?\n\u003e\n\nNot really. The problem is that you assume a transaction corresponds to a\nsingle payment. This is true for simple wallet use cases, but not\ncompatible with CoinJoin, or with systems that for example would want to\ncombine multiple payments in a single transaction.\n\n\n\u003e \u003e Also, if I understand correctly, there is no commitment to anything\n\u003e you're\n\u003e \u003e trying to say about the sender? So once I obtain a proof-of-payment from\n\u003e you\n\u003e \u003e about something you paid, I can go claim that it's mine?\n\u003e\n\u003e I don't understand this. The pop includes a nonce randomly generated\n\u003e by the server. If you're very lucky, 1/(2^48) per try, you can reuse a\n\u003e pop.\n\u003e\n\u003e\nI owe you an apology here, for judging based on the summary you posted\nrather than reading the actual text.\n\n48 bits seems low to me, but it does indeed solve the problem. Why not 128\nor 256 bits?\n\n\u003e Why does anyone care who paid? This is like walking into a coffeshop,\n\u003e \u003e noticing I don't have money with me, let me friend pay for me, and then\n\u003e have\n\u003e \u003e the shop insist that I can't drink it because I'm not the buyer.\n\u003e\n\u003e If you pay as you use the service (ie pay for coffee upfront), there's\n\u003e no need for PoP. Please see the Motivation section. But you are right\n\u003e that you must have the wallet(s) that paid at hand when you issue a\n\u003e PoP.\n\u003e\n\u003e \u003e\n\u003e \u003e Track payments, don't try to assign identities to payers.\n\u003e\n\u003e Please elaborate, I don't understand what you mean here.\n\u003e\n\nI think that is a mistake. You should not assume that the wallet who held\nthe coins is the payer/buyer. That's what I said earlier; you're implicitly\ncreating an identity (the one who holds these keys) based on the\ntransaction. This seems fundamentally wrong to me, and not necessary. The\nreceiver should not care who paid or how, he should care what was payed for.\n\nThe easiest solution to this IMHO would be an extension to the payment\nprotocol that gives you (or your wallet) a token in return for paying, and\nthat knowledge of that token is used to gain access to the services you\nprovide.\n\n-- \nPieter\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150616/75813f1f/attachment.html\u003e",
"sig": "126a8b4beaa3c905a9515d951c5dd06c465a2a30b2af172d56f1f53745f97f5b3dfd8274d9a9895e8bfbb6af34d55b831ac475cc6799ba3620db96968fcb9072"
}