Kalle Rosenbaum [ARCHIVE] on Nostr: 📅 Original date posted:2015-07-24 📝 Original message:These BIPs have been ...
📅 Original date posted:2015-07-24
📝 Original message: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" <kalle at rosenbaum.se>:
> 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" <kalle at rosenbaum.se>:
>
>> 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 <kalle at rosenbaum.se>:
>>
>>> 2015-06-16 21:48 GMT+02:00 Pieter Wuille <pieter.wuille at gmail.com>:
>>> > 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" <kalle at rosenbaum.se> wrote:
>>> >>
>>> >> 2015-06-16 21:25 GMT+02:00 Pieter Wuille <pieter.wuille at gmail.com>:
>>> >> > 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" <kalle at rosenbaum.se>
>>> wrote:
>>> >> >>
>>> >> >> Thank you for your comments Pieter! Please find my answers below.
>>> >> >>
>>> >> >> 2015-06-16 16:31 GMT+02:00 Pieter Wuille <pieter.wuille at gmail.com
>>> >:
>>> >> >> > 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.
>>> >> >> >
>>> >> >>
>>> >> >> 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
>>> >> >> >
>>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150724/34e83c0a/attachment-0001.html>;
📝 Original message: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" <kalle at rosenbaum.se>:
> 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" <kalle at rosenbaum.se>:
>
>> 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 <kalle at rosenbaum.se>:
>>
>>> 2015-06-16 21:48 GMT+02:00 Pieter Wuille <pieter.wuille at gmail.com>:
>>> > 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" <kalle at rosenbaum.se> wrote:
>>> >>
>>> >> 2015-06-16 21:25 GMT+02:00 Pieter Wuille <pieter.wuille at gmail.com>:
>>> >> > 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" <kalle at rosenbaum.se>
>>> wrote:
>>> >> >>
>>> >> >> Thank you for your comments Pieter! Please find my answers below.
>>> >> >>
>>> >> >> 2015-06-16 16:31 GMT+02:00 Pieter Wuille <pieter.wuille at gmail.com
>>> >:
>>> >> >> > 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.
>>> >> >> >
>>> >> >>
>>> >> >> 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
>>> >> >> >
>>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150724/34e83c0a/attachment-0001.html>;