2015-06-16 21:48 GMT+02:00 Pieter Wuille pieter.wui...@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 ka...@rosenbaum.se wrote:
2015-06-16 21:25 GMT+02:00 Pieter Wuille pieter.wui...@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 ka...@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.wui...@gmail.com:
On Mon, Jun 15, 2015 at 1:59 PM, Kalle Rosenbaum ka...@rosenbaum.se
wrote:
2015-06-15 12:00 GMT+02:00 Pieter Wuille pieter.wui...@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
