These BIPs have been assigned 120 and 121: 120: Proof of Payment 121: Proof of Payment URI scheme Regards, Kalle Den 24 jul 2015 08:27 skrev "Kalle Rosenbaum" : > These BIPs have been assigned 120 and 121: > > 120: Proof of Payment > 121: Proof of Payment URI scheme > > Regards, > Kalle > Den 21 jun 2015 16:39 skrev "Kalle Rosenbaum" : > >> Hi Greg! >> >> After a lot of constructive discussion, feedback and updating, I'm >> requesting that you please assign these proposals BIP numbers. It's both >> the "Proof of Payment" proposal and the "Proof of Payment URI scheme" >> proposal that I'm referring to. >> >> The wikimedia source is available here: >> https://github.com/kallerosenbaum/poppoc/wiki/Proof-of-Payment-BIP and >> https://github.com/kallerosenbaum/poppoc/wiki/btcpop-scheme-BIP. >> >> Is this what you need in order to proceed or is there something else you >> need from me? >> >> Best regards, >> /Kalle >> >> 2015-06-17 11:51 GMT+02:00 Kalle Rosenbaum : >> >>> 2015-06-16 21:48 GMT+02:00 Pieter Wuille : >>> > I don't see why existing software could create a 40-byte OP_RETURN but >>> not >>> > larger? The limitation comes from a relay policy in full nodes, not a >>> > limitation is wallet software... and PoPs are not relayed on the >>> network. >>> >>> You are probably right here. The thing is that I don't know how *all* >>> wallet signing and validating software is written, so I figure it's >>> better to stick to a "valid" output. Since I don't *need* more data >>> than 40 bytes, why bother. There's another constraint to this as well: >>> The other BIP proposal, "Proof of Payment URI scheme", includes a >>> nonce parameter in the URI. If the nonce is very long, the QR code >>> will be unnecessarily big. The server should try to detect a brute >>> force of the 48 bit nonce, or at least delay the pop requests by some >>> 100 ms or so. >>> >>> Do you think this is an actual problem, and why? Is your suggestion to >>> use a bigger nonce, given the above? >>> >>> > >>> > Regarding sharing, I think you're talking about a different use case. >>> Say >>> > you want to pay for 1-week valid entrance to some venue. I thought the >>> > purpose of the PoP was to be sure that only the person who paid for >>> it, and >>> > not anyone else can use it during that week. >>> > >>> >>> That's right. That's one use case. You pay for the 1-week entrance and >>> then you use your wallet to sign PoPs when you enter the venue. >>> >>> > My argument against that is that the original payer can also hand the >>> > private keys in his wallet to someone else, who would then become able >>> to >>> > create PoPs for the service. He does not lose anything by this, >>> assuming the >>> > address is not reused. >>> > >>> >>> Yes, that is possible. It's about the same as giving out a >>> username/password for a service that you have paid for. In the case of >>> a concert ticket, it's simple. Just allow one entrance per payment. >>> But in the example you gave, it's a bit more complicated. You could >>> for example give all guests a bracelet upon first entry or upon first >>> exit. Or you can put a stamp on people leaving the venue, and demand >>> that all re-entries show the stamp, possibly along with a new PoP. >>> Pretty much as is done already. Different use cases will need >>> different protection. In this example, the value added by PoP is that >>> the venue does not have to distribute tickets in advance. This in turn >>> allows for better privacy for the customer, who don't have to give out >>> personal information such as an email-address. >>> >>> > So, using a token does not change anything, except it can be provided >>> to the >>> > payer - instead of relying on creating an implicit identity based on >>> who >>> > seems to have held particular private keys in the past. >>> > >>> >>> Yes, that's a difference, but it comes at the cost of security. The >>> stolen token can be used over and over. In the case of PoP it's only >>> usable once, and it's only created when it's actually needed, >>> minimizing the window of opportunity for the thief. >>> >>> Regards, >>> Kalle >>> >>> > On Jun 16, 2015 9:41 PM, "Kalle Rosenbaum" wrote: >>> >> >>> >> 2015-06-16 21:25 GMT+02:00 Pieter Wuille : >>> >> > You can't avoid sharing the token, and you can't avoid sharing the >>> >> > private >>> >> > keys used for signing either. If they are single use, you don't lose >>> >> > anything by sharing them. >>> >> >>> >> Forwarding the PoP request would be a way to avoid sharing keys, as >>> >> suggested above. >>> >> >>> >> > >>> >> > Also you are not creating a real transaction. Why does the OP_RETURN >>> >> > limitation matter? >>> >> >>> >> This was discussed in the beginning of this thread: "The idea is to >>> >> simplify implementation. Existing software can be used as is to sign >>> >> and validate PoPs" >>> >> >>> >> Regards, >>> >> Kalle >>> >> >>> >> > >>> >> > On Jun 16, 2015 9:22 PM, "Kalle Rosenbaum" >>> wrote: >>> >> >> >>> >> >> Thank you for your comments Pieter! Please find my answers below. >>> >> >> >>> >> >> 2015-06-16 16:31 GMT+02:00 Pieter Wuille >> >: >>> >> >> > On Mon, Jun 15, 2015 at 1:59 PM, Kalle Rosenbaum < >>> kalle@rosenbaum.se> >>> >> >> > wrote: >>> >> >> >> >>> >> >> >> 2015-06-15 12:00 GMT+02:00 Pieter Wuille < >>> pieter.wuille@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. >>> >> >> > >>> >> >> >>> >> >> Yes, you are right. It's not compatible with CoinJoin and the >>> likes. >>> >> >> >>> >> >> > >>> >> >> > 48 bits seems low to me, but it does indeed solve the problem. >>> Why >>> >> >> > not >>> >> >> > 128 >>> >> >> > or 256 bits? >>> >> >> >>> >> >> The nonce is limited because of the OP_RETURN output being limited >>> to >>> >> >> 40 bytes of data: 2 bytes version, 32 bytes txid, 6 bytes nonce. >>> >> >> >>> >> >> > >>> >> >> >> > 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. >>> >> >> >>> >> >> You are saying that it's a problem that the wallet used to pay, >>> must >>> >> >> also be used to issue the PoP? That may very well be a problem in >>> some >>> >> >> cases. People using PoP should of course be aware of it's >>> limitations >>> >> >> and act accordingly, i.e. don't pay for concert tickets for a >>> friend >>> >> >> and expect your friend to be able to enter the arena with her >>> wallet. >>> >> >> As Tom Harding noted, it is possible to transfer keys to your >>> friend's >>> >> >> wallet, but that might not be desirable if those keys are also used >>> >> >> for other payments. Also that would weaken the security of an HD >>> >> >> wallet, since a chain code along with a private key would reveal >>> all >>> >> >> keys in that tree. Another solution is that your friend forwards >>> the >>> >> >> PoP request to your wallet, through twitter or SMS, and you send >>> the >>> >> >> PoP for her. Maybe that forwarding mechanism can be built into >>> wallets >>> >> >> and automated so that the wallet automatically suggests to sign the >>> >> >> PoP for your friend. This is probably something to investigate >>> >> >> further, but not within the scope of this BIP. >>> >> >> >>> >> >> Of course the simplest solution would be to send money to your >>> friend >>> >> >> first so that she can pay for the ticket from her own wallet, but >>> >> >> that's not always feasible. >>> >> >> >>> >> >> > >>> >> >> > 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. >>> >> >> > >>> >> >> >>> >> >> That token would then be reusable. Someone stealing it would be >>> able >>> >> >> to use it as much as she wants. That is what I want to avoid with >>> PoP. >>> >> >> The BIP proposal briefly mentions something like this in the >>> >> >> rationale. I also had a discussion about this with Mike Hearn on >>> this >>> >> >> list on Mars 13 that I think covers most pros and cons of the >>> >> >> different approaches. >>> >> >> >>> >> >> While your suggestion does indeed separate the transaction from the >>> >> >> proof of payment, it also assumes that the token is held in the >>> wallet >>> >> >> that pays. Otherwise you would need to keep it in another safe >>> place, >>> >> >> remember it's reusable. Where would that be? How would you transfer >>> >> >> that token to your friend? >>> >> >> >>> >> >> Thank you again for your comments. I appreciate it. >>> >> >> >>> >> >> Best regards, >>> >> >> Kalle >>> >> >> >>> >> >> > -- >>> >> >> > Pieter >>> >> >> > >>> >> >>