Re: [Bitcoin-development] Proof of Payment

[Jorge Timón]

Forget it, sorry, I misunderstood the proposal entirely, re-reading
with more care...

On Tue, Apr 28, 2015 at 2:41 PM, Kalle Rosenbaum  wrote:
> Hi Jorge,
>
> I don't think I understand the question. Proof of Payment is used to prove
> that you have the credentials needed for a certain transaction. It does not
> care where in the blockchain the transaction is. Or if it's in the
> blockchain at all.
>
> /Kalle
>
> So at the low level, how does a "proof of payment" differ from just proving
> that a given transaction is in a given block (what SPV nodes take as proof
> of payment today)?
>
> On Apr 27, 2015 2:42 PM, "Kalle Rosenbaum"  wrote:
>>
>> "Or a really high lock_time, but it would not make it invalid, just
>> delayed."
>>
>> Ok, this was a bad idea, since nodes would have to keep it in memory.
>> Please disregard that idea...
>>
>> Kalle
>>
>> Den 27 apr 2015 14:35 skrev "Kalle Rosenbaum" :
>> >
>> > >
>> > > Some more use cases might be:
>> > > Waiting in comfort:
>> > >  - Send a payment ahead of time, then wander over and collect the
>> > > goods
>> > > after X confirmations.
>> > >
>> > > Authorized pickup :
>> > >  - Hot wallet software used by related people could facilitate the use
>> > > of 1 of N multisig funds.  Any one of the N wallets could collect
>> > > goods
>> > > and services purchased by any of the others.
>> >
>> > I like this one, because it shows the power of reusing the transaction
>> > data structure.
>> >
>> > >
>> > > Non-monetary gifts:
>> > >  - Sender exports spent keys to a beneficiary, enabling PoP to work as
>> > > a
>> > > gift claim
>> > >
>> > > Contingent services:
>> > >  - Without Bob's permission, a 3rd party conditions action on a
>> > > payment
>> > > made from Alice to Bob.  For example, if you donated at least .02 BTC
>> > > to
>> > > Dorian, you (or combining scenarios, any of your N authorized family
>> > > members), can come to my dinner party.
>> >
>> > This is an interesting one.
>> >
>> > >
>> > > I tried out your demo wallet and service and it worked as advertised.
>> > >
>> > > Could the same standard also be used to prove that a transaction COULD
>> > > BE created?  To generalize the concept beyond actual payments, you
>> > > could
>> > > call it something like proof of payment potential.
>> >
>> > I guess it's possible, but we'd have to remove the txid from the output,
>> > since there is none. This is a way of saying "I'm in control of these
>> > addresses". The other party/parties can then verify the funds on the
>> > blockchain and watch those addresses for changes. Maybe there are some
>> > interesting use cases here. Ideas?
>> >
>> > >
>> > > Why not make these proofs permanently INVALID transactions, to remove
>> > > any possibility of their being mined and spending everything to fees
>> > > when used in this way, and also in cases involving reorganizations?
>> >
>> > Yes. Initially I thought it would be enough that the funds are already
>> > spent, but I think you're right here. Reorgs could be a problem. Worse, you
>> > also might want to prove 0-confirmation transactions, in which case it's a
>> > huge security problem. Someone might intercept the PoP and publish it on 
>> > the
>> > bitcoin network, spending all the funds. But I still would like wallets to
>> > be able to build/verify PoPs with little or no modifications. Could we
>> > possibly change the version number on the PoP to something other than 1?
>> > Maybe 2^4-1? Or a really high lock_time, but it would not make it invalid,
>> > just delayed. Any suggestions here?
>> >
>> > >
>> > > I agree that PoP seems complementary to BIP70.
>> > >
>> > >
>> >
>> > Thank you very much for your comments!
>> >
>> > /Kalle
>>
>>
>>
>> --
>> One dashboard for servers and applications across Physical-Virtual-Cloud
>> Widest out-of-the-box monitoring support with 50+ applications
>> Performance metrics, stats and reports that give you Actionable Insights
>> Deep dive visibility with transaction tracing using APM Insight.
>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>> ___
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proof of Payment

[Kalle Rosenbaum]

Hi Jorge,

I don't think I understand the question. Proof of Payment is used to prove
that you have the credentials needed for a certain transaction. It does not
care where in the blockchain the transaction is. Or if it's in the
blockchain at all.

/Kalle

So at the low level, how does a "proof of payment" differ from just proving
that a given transaction is in a given block (what SPV nodes take as proof
of payment today)?
On Apr 27, 2015 2:42 PM, "Kalle Rosenbaum"  wrote:

> "Or a really high lock_time, but it would not make it invalid, just
> delayed."
>
> Ok, this was a bad idea, since nodes would have to keep it in memory.
> Please disregard that idea...
>
> Kalle
>
> Den 27 apr 2015 14:35 skrev "Kalle Rosenbaum" :
> >
> > >
> > > Some more use cases might be:
> > > Waiting in comfort:
> > >  - Send a payment ahead of time, then wander over and collect the goods
> > > after X confirmations.
> > >
> > > Authorized pickup :
> > >  - Hot wallet software used by related people could facilitate the use
> > > of 1 of N multisig funds.  Any one of the N wallets could collect goods
> > > and services purchased by any of the others.
> >
> > I like this one, because it shows the power of reusing the transaction
> data structure.
> >
> > >
> > > Non-monetary gifts:
> > >  - Sender exports spent keys to a beneficiary, enabling PoP to work as
> a
> > > gift claim
> > >
> > > Contingent services:
> > >  - Without Bob's permission, a 3rd party conditions action on a payment
> > > made from Alice to Bob.  For example, if you donated at least .02 BTC
> to
> > > Dorian, you (or combining scenarios, any of your N authorized family
> > > members), can come to my dinner party.
> >
> > This is an interesting one.
> >
> > >
> > > I tried out your demo wallet and service and it worked as advertised.
> > >
> > > Could the same standard also be used to prove that a transaction COULD
> > > BE created?  To generalize the concept beyond actual payments, you
> could
> > > call it something like proof of payment potential.
> >
> > I guess it's possible, but we'd have to remove the txid from the output,
> since there is none. This is a way of saying "I'm in control of these
> addresses". The other party/parties can then verify the funds on the
> blockchain and watch those addresses for changes. Maybe there are some
> interesting use cases here. Ideas?
> >
> > >
> > > Why not make these proofs permanently INVALID transactions, to remove
> > > any possibility of their being mined and spending everything to fees
> > > when used in this way, and also in cases involving reorganizations?
> >
> > Yes. Initially I thought it would be enough that the funds are already
> spent, but I think you're right here. Reorgs could be a problem. Worse, you
> also might want to prove 0-confirmation transactions, in which case it's a
> huge security problem. Someone might intercept the PoP and publish it on
> the bitcoin network, spending all the funds. But I still would like wallets
> to be able to build/verify PoPs with little or no modifications. Could we
> possibly change the version number on the PoP to something other than 1?
> Maybe 2^4-1? Or a really high lock_time, but it would not make it invalid,
> just delayed. Any suggestions here?
> >
> > >
> > > I agree that PoP seems complementary to BIP70.
> > >
> > >
> >
> > Thank you very much for your comments!
> >
> > /Kalle
>
>
> --
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proof of Payment

[Jorge Timón]

So at the low level, how does a "proof of payment" differ from just proving
that a given transaction is in a given block (what SPV nodes take as proof
of payment today)?
On Apr 27, 2015 2:42 PM, "Kalle Rosenbaum"  wrote:

> "Or a really high lock_time, but it would not make it invalid, just
> delayed."
>
> Ok, this was a bad idea, since nodes would have to keep it in memory.
> Please disregard that idea...
>
> Kalle
>
> Den 27 apr 2015 14:35 skrev "Kalle Rosenbaum" :
> >
> > >
> > > Some more use cases might be:
> > > Waiting in comfort:
> > >  - Send a payment ahead of time, then wander over and collect the goods
> > > after X confirmations.
> > >
> > > Authorized pickup :
> > >  - Hot wallet software used by related people could facilitate the use
> > > of 1 of N multisig funds.  Any one of the N wallets could collect goods
> > > and services purchased by any of the others.
> >
> > I like this one, because it shows the power of reusing the transaction
> data structure.
> >
> > >
> > > Non-monetary gifts:
> > >  - Sender exports spent keys to a beneficiary, enabling PoP to work as
> a
> > > gift claim
> > >
> > > Contingent services:
> > >  - Without Bob's permission, a 3rd party conditions action on a payment
> > > made from Alice to Bob.  For example, if you donated at least .02 BTC
> to
> > > Dorian, you (or combining scenarios, any of your N authorized family
> > > members), can come to my dinner party.
> >
> > This is an interesting one.
> >
> > >
> > > I tried out your demo wallet and service and it worked as advertised.
> > >
> > > Could the same standard also be used to prove that a transaction COULD
> > > BE created?  To generalize the concept beyond actual payments, you
> could
> > > call it something like proof of payment potential.
> >
> > I guess it's possible, but we'd have to remove the txid from the output,
> since there is none. This is a way of saying "I'm in control of these
> addresses". The other party/parties can then verify the funds on the
> blockchain and watch those addresses for changes. Maybe there are some
> interesting use cases here. Ideas?
> >
> > >
> > > Why not make these proofs permanently INVALID transactions, to remove
> > > any possibility of their being mined and spending everything to fees
> > > when used in this way, and also in cases involving reorganizations?
> >
> > Yes. Initially I thought it would be enough that the funds are already
> spent, but I think you're right here. Reorgs could be a problem. Worse, you
> also might want to prove 0-confirmation transactions, in which case it's a
> huge security problem. Someone might intercept the PoP and publish it on
> the bitcoin network, spending all the funds. But I still would like wallets
> to be able to build/verify PoPs with little or no modifications. Could we
> possibly change the version number on the PoP to something other than 1?
> Maybe 2^4-1? Or a really high lock_time, but it would not make it invalid,
> just delayed. Any suggestions here?
> >
> > >
> > > I agree that PoP seems complementary to BIP70.
> > >
> > >
> >
> > Thank you very much for your comments!
> >
> > /Kalle
>
>
> --
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proof of Payment

[Kalle Rosenbaum]

"Or a really high lock_time, but it would not make it invalid, just
delayed."

Ok, this was a bad idea, since nodes would have to keep it in memory.
Please disregard that idea...

Kalle

Den 27 apr 2015 14:35 skrev "Kalle Rosenbaum" :
>
> >
> > Some more use cases might be:
> > Waiting in comfort:
> >  - Send a payment ahead of time, then wander over and collect the goods
> > after X confirmations.
> >
> > Authorized pickup :
> >  - Hot wallet software used by related people could facilitate the use
> > of 1 of N multisig funds.  Any one of the N wallets could collect goods
> > and services purchased by any of the others.
>
> I like this one, because it shows the power of reusing the transaction
data structure.
>
> >
> > Non-monetary gifts:
> >  - Sender exports spent keys to a beneficiary, enabling PoP to work as a
> > gift claim
> >
> > Contingent services:
> >  - Without Bob's permission, a 3rd party conditions action on a payment
> > made from Alice to Bob.  For example, if you donated at least .02 BTC to
> > Dorian, you (or combining scenarios, any of your N authorized family
> > members), can come to my dinner party.
>
> This is an interesting one.
>
> >
> > I tried out your demo wallet and service and it worked as advertised.
> >
> > Could the same standard also be used to prove that a transaction COULD
> > BE created?  To generalize the concept beyond actual payments, you could
> > call it something like proof of payment potential.
>
> I guess it's possible, but we'd have to remove the txid from the output,
since there is none. This is a way of saying "I'm in control of these
addresses". The other party/parties can then verify the funds on the
blockchain and watch those addresses for changes. Maybe there are some
interesting use cases here. Ideas?
>
> >
> > Why not make these proofs permanently INVALID transactions, to remove
> > any possibility of their being mined and spending everything to fees
> > when used in this way, and also in cases involving reorganizations?
>
> Yes. Initially I thought it would be enough that the funds are already
spent, but I think you're right here. Reorgs could be a problem. Worse, you
also might want to prove 0-confirmation transactions, in which case it's a
huge security problem. Someone might intercept the PoP and publish it on
the bitcoin network, spending all the funds. But I still would like wallets
to be able to build/verify PoPs with little or no modifications. Could we
possibly change the version number on the PoP to something other than 1?
Maybe 2^4-1? Or a really high lock_time, but it would not make it invalid,
just delayed. Any suggestions here?
>
> >
> > I agree that PoP seems complementary to BIP70.
> >
> >
>
> Thank you very much for your comments!
>
> /Kalle
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proof of Payment

[Kalle Rosenbaum]

>
> Some more use cases might be:
> Waiting in comfort:
>  - Send a payment ahead of time, then wander over and collect the goods
> after X confirmations.
>
> Authorized pickup :
>  - Hot wallet software used by related people could facilitate the use
> of 1 of N multisig funds.  Any one of the N wallets could collect goods
> and services purchased by any of the others.

I like this one, because it shows the power of reusing the transaction data
structure.

>
> Non-monetary gifts:
>  - Sender exports spent keys to a beneficiary, enabling PoP to work as a
> gift claim
>
> Contingent services:
>  - Without Bob's permission, a 3rd party conditions action on a payment
> made from Alice to Bob.  For example, if you donated at least .02 BTC to
> Dorian, you (or combining scenarios, any of your N authorized family
> members), can come to my dinner party.

This is an interesting one.

>
> I tried out your demo wallet and service and it worked as advertised.
>
> Could the same standard also be used to prove that a transaction COULD
> BE created?  To generalize the concept beyond actual payments, you could
> call it something like proof of payment potential.

I guess it's possible, but we'd have to remove the txid from the output,
since there is none. This is a way of saying "I'm in control of these
addresses". The other party/parties can then verify the funds on the
blockchain and watch those addresses for changes. Maybe there are some
interesting use cases here. Ideas?

>
> Why not make these proofs permanently INVALID transactions, to remove
> any possibility of their being mined and spending everything to fees
> when used in this way, and also in cases involving reorganizations?

Yes. Initially I thought it would be enough that the funds are already
spent, but I think you're right here. Reorgs could be a problem. Worse, you
also might want to prove 0-confirmation transactions, in which case it's a
huge security problem. Someone might intercept the PoP and publish it on
the bitcoin network, spending all the funds. But I still would like wallets
to be able to build/verify PoPs with little or no modifications. Could we
possibly change the version number on the PoP to something other than 1?
Maybe 2^4-1? Or a really high lock_time, but it would not make it invalid,
just delayed. Any suggestions here?

>
> I agree that PoP seems complementary to BIP70.
>
>

Thank you very much for your comments!

/Kalle
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proof of Payment

[Tom Harding]

On 4/22/2015 1:03 PM, Kalle Rosenbaum wrote:
>
> I've built a proof-of-concept for Proof of Payment. It's available at
> http://www.rosenbaum.se:8080. The site contains links to the source
> code for both the server and a Mycelium fork as well as pre-built apk:s.
>
>
> >> There are several scenarios in which it would be useful to
> prove that you have paid for something. For example:
> >> A pre-paid hotel room where your PoP functions as a key to the
> door.
> >> An online video rental service where you pay for a video and
> watch it on any device.
> >> An ad-sign where you pay in advance for e.g. 2-weeks
> exclusivity. During this period you can upload new content to the
> sign whenever you like using PoP.
> >> A lottery where all participants pay to the same address, and
> the winner of the T-shirt is selected among the transactions to
> that address. You exchange the T-shirt for a PoP for the winning
> transaction.
>

Kalle,

You propose a standard format for proving that wallet-controlled funds
COULD HAVE BEEN spent as they were in a real transaction.  Standardized
PoP would give wallets a new way to communicate with the outside world.

PoP could allow payment and delivery to be separated in time in a
standard way, without relying on a mechanism external to bitcoin's
cryptosystem, and enable standardized real-world scenarios where sender
!= beneficiary, and/or receiver != provider.

Payment:
sender -> receiver

Delivery:
beneficiary <- provider

Some more use cases might be:
Waiting in comfort:
 - Send a payment ahead of time, then wander over and collect the goods
after X confirmations.

Authorized pickup :
 - Hot wallet software used by related people could facilitate the use
of 1 of N multisig funds.  Any one of the N wallets could collect goods
and services purchased by any of the others.

Non-monetary gifts:
 - Sender exports spent keys to a beneficiary, enabling PoP to work as a
gift claim

Contingent services:
 - Without Bob's permission, a 3rd party conditions action on a payment
made from Alice to Bob.  For example, if you donated at least .02 BTC to
Dorian, you (or combining scenarios, any of your N authorized family
members), can come to my dinner party.

I tried out your demo wallet and service and it worked as advertised.

Could the same standard also be used to prove that a transaction COULD
BE created?  To generalize the concept beyond actual payments, you could
call it something like proof of payment potential.

Why not make these proofs permanently INVALID transactions, to remove
any possibility of their being mined and spending everything to fees
when used in this way, and also in cases involving reorganizations?

I agree that PoP seems complementary to BIP70.



--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proof of Payment

[Kalle Rosenbaum]

Hi Martin,

Thank you very much for your comments. See my answers inline:

Den 23 apr 2015 03:28 skrev "Martin Lie" :
>
> Hej, Kalle.
>
> I love the idea of standardised PoPs, including a protocol for
requesting/sending them as an extension of BIP-70.
>

Me too!

>
> A couple of comments:
>
> 1. You admit that the txid is just a convenience and not strictly
necessary. Perhaps this should be reflected in the sequence of bits/bytes
in the record you're proposing, e.g. "OP_RETURN POP_LITERAL  "?
>

I was thinking that txid should be mandatory just as the nonce so the order
was arbitrarily chosen. I think you may be right that it's more intuitive
to put txid last if it's not mandatory in a future version. It makes sense
to swap order. I'll put that on my todo list.

> 2. Building on #1, perhaps there could be other identifying information
than a txid? Perhaps a txid field shouldn't be "hardcoded" into the
standard at all?
>
> How about taking the same approach as BIP-43 (and others) and use a
prefix that determines how the rest of the records should be interpreted,
i.e. a "type" (or "purpose" or "version" or whatever you'd like to call it)
field. This would allow for different purposes/versions of a PoP, including
as of now unforeseen ones.
>
> The new structure would then be:
> OP_RETURN POP_PREFIX POP_TYPE POP_NONCE POP_PAYLOAD
>
> POP_PREFIX (? bytes): I'll leave it up to you to specify the exact bits
(and length) of the POP_PREFIX, but if your literal is used, it'd be 3
bytes: 0x506f50.
>
> Literals in Bitcoin protocols generally seem to be of the "binary" sort
as opposed to human-readable text, so perhaps the devs wouldn't ACK
something as "wasteful" as using 3 bytes just to identify it as a PoP
record? Obviously, this is a small detail that can be changed at short
notice, but as with all standards - once people start using it, you're
mostly stuck with what you have. ;)
>

Yes, maybe we could drop POP_PREFIX altogether. The server is expecting a
pop and can therefore just assume it's a pop. No need to explicitly write
that inside the pop. Can you think of a scenario where it is actually
needed. Keeping the POP_PREFIX makes sense only if other transaction-like
data structures with OP_RETURN appears in the same contexts as pops. What
do you think?

> POP_TYPE: (1 byte): 0x01 for your "standard" version, which would mean
that the payload contains a txid.
>

This is a good idea. Todo!

> POP_NONCE: (4 bytes): "2^32 re-uses should be enough for everyone", no? ;)
>

Euhm, well, I don't know... The bigger the better. If we drop POP_PREFIX we
could allow for 2 bytes version and 6 bytes nonce. Or 1 byte version and 7
bytes nonce.

> POP_PAYLOAD (32+ bytes): The contents of which is determined by POP_TYPE,
e.g. a txid or possibly extra nonce data. Or perhaps some text that makes
the purpose or context of this PoP human-readable? (This could then be
stored by wallets in order to show a list of what kind of proofs you've
sent.)
>

For now I think I'll stick to "txid is mandatory".

>
> 3. I noticed that your post-OP_RETURN structure included exactly 40
bytes. Is that due to the 40-byte limitation on OP_RETURN's "data"? Are you
aware that it will be increased to 80 bytes? Cf. https://
github.com
/
bitcoin
/
bitcoin
/pull/5286

>

Yes, I deliberately limited the data to 40 bytes for that reason. With
versioning, this may change in the future.

> :)
>
>
> Vennlig hilsen
> Martin Lie
--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proof of Payment

[Kalle Rosenbaum]

Hi again

I've built a proof-of-concept for Proof of Payment. It's available at
http://www.rosenbaum.se:8080. The site contains links to the source code
for both the server and a Mycelium fork as well as pre-built apk:s.

I'm still very interested in feedback on this, so please let me know what
you think.

Stuff that has come up so far, and my answers:

* Some people think it's too complicated. I disagree. Using transactions as
the data structure actually makes it simple to implement both on the server
and in wallets. Just use existing wallet software to sign and verify PoPs.

* Other ideas on Proof of Payment use a single key from the proven
transaction, for example the first key from the first input of the
transaction. This is problematic when multisig and other P2SH transactions
are used. I also think that it's necessary to use *all* credentials used
for the transaction. Otherwise we wouldn't be sure that the sender actually
have all the needed credentials.

* Another suggestion is that a payment request from BIP70 is used as proof.
That is possible, but it's reusable which makes it inappropriate to send
over networks; If it is stolen somewhere, anyone can use it as many times
they like. As stated in BIP70, the payment request is suitable for dispute
resolution, more like a receipt. On the other hand, I think that PoP would
fit nicely into the workflow of BIP70: a) Read a url for the PoP request,
b) get the (possibly signed) PoP request. c) send the PoP through http POST
to the URL in the PoP request, d) profit!

* A thought of my own: The txid used in the PoP output is not strictly
necessary. It's more of a convenience for the verifier of the PoP. Without
it, the verifier would need to lookup the transaction based on the inputs
of the PoP,

Regards,
Kalle Rosenbaum

2015-03-14 19:16 GMT+01:00 Kalle Rosenbaum :

> Den 14 mar 2015 00:59 skrev "Patrick Mccorry (PGR)" <
> patrick.mcco...@newcastle.ac.uk>:
> >
> > That all seems more complicated than it needs to be - the service you
> are paying knows that it had received a payment from some public key Q
> (regardless of script type, as all scripts require a public key).
>
> The service knows it had received a payment from Q1, Q2,...,Qn. A tx may
> have multiple inputs and each input may have several public keys.
>
> >
> > So I want to rent a movie, they send me a challenge and I respond with a
> zero knowledge proof to demonstrate that I am the owner of Q, and as they
> know that Q made a payment - then there is a proof of payment - as this is
> provided by the time stamped transaction on the blockchain - in this sense
> you are bootstrapping trust from the blockchain.
> >
>
> Ok. Without knowing much about zero knowledge proof, i guess you'd need a
> challenge/response for each of the keys Q1,..,Qn. If we settle on only a
> single key, what key from what input should we use? One input may be a
> multisig (2 of 3) input. Is it ok to settle on only one of the multisig
> keys? Probably not. I'd say that we need 2 of 3 signatures (just as in a
> bitcoin transaction), and not necessarily the same two that made the
> payment.
>
> > For all of your scenarios, a simple challenge-response scheme would
> work. Adding an op_return makes the payment transaction worse as it is now
> distinguishable on the blockchain - you want use information that is
> already available on that transaction.
>
> I'm not sure I follow. Do you mean that it's a problem that the PoP itself
> reveals what transaction I'm proving? Well, maybe it is a problem under
> some circumstances. The least you can do to protect yourself from revealing
> information to third party is to communicate over secure channels. Could
> you please elaborate on this?
>
> Anyway, if both the client and the server knows what transaction to prove
> (ad-sign example) you are right that the tx info is kind of redundant. But
> if we don't send the tx hints from server to client, the client user must
> manually select the transaction to prove which makes the user experience
> worse.
>
> Thank you very much for your comments,
>
> /Kalle
>
> >
> > Sent from my iPhone
> >
> > On 13 Mar 2015, at 19:58, Kalle Rosenbaum  wrote:
> >
> >> Hi all,
> >>
> >> I've been thinking about how a person can prove that she has made a
> payment. I came up with an idea I call Proof of Payment (PoP) and I would
> highly appreciate your comments. Has something like this been discussed
> somewhere before?
> >>
> >> Use cases
> >>
> >> There are several scenarios in which it would be useful to prove that
> you have paid for something. For example:
> >> A pre-paid hotel room where your PoP functions as a key to the door.
> >> An online video rental service where you pay for a video and watch it
> on any device.
> >> An ad-sign where you pay in advance for e.g. 2-weeks exclusivity.
> During this period you can upload new content to the sign whenever you like
> using PoP.
> >> A lottery where all participants pay to the same address, and the
> win

Re: [Bitcoin-development] Proof of Payment

[Kalle Rosenbaum]

Den 14 mar 2015 00:59 skrev "Patrick Mccorry (PGR)" <
patrick.mcco...@newcastle.ac.uk>:
>
> That all seems more complicated than it needs to be - the service you are
paying knows that it had received a payment from some public key Q
(regardless of script type, as all scripts require a public key).

The service knows it had received a payment from Q1, Q2,...,Qn. A tx may
have multiple inputs and each input may have several public keys.

>
> So I want to rent a movie, they send me a challenge and I respond with a
zero knowledge proof to demonstrate that I am the owner of Q, and as they
know that Q made a payment - then there is a proof of payment - as this is
provided by the time stamped transaction on the blockchain - in this sense
you are bootstrapping trust from the blockchain.
>

Ok. Without knowing much about zero knowledge proof, i guess you'd need a
challenge/response for each of the keys Q1,..,Qn. If we settle on only a
single key, what key from what input should we use? One input may be a
multisig (2 of 3) input. Is it ok to settle on only one of the multisig
keys? Probably not. I'd say that we need 2 of 3 signatures (just as in a
bitcoin transaction), and not necessarily the same two that made the
payment.

> For all of your scenarios, a simple challenge-response scheme would work.
Adding an op_return makes the payment transaction worse as it is now
distinguishable on the blockchain - you want use information that is
already available on that transaction.

I'm not sure I follow. Do you mean that it's a problem that the PoP itself
reveals what transaction I'm proving? Well, maybe it is a problem under
some circumstances. The least you can do to protect yourself from revealing
information to third party is to communicate over secure channels. Could
you please elaborate on this?

Anyway, if both the client and the server knows what transaction to prove
(ad-sign example) you are right that the tx info is kind of redundant. But
if we don't send the tx hints from server to client, the client user must
manually select the transaction to prove which makes the user experience
worse.

Thank you very much for your comments,

/Kalle

>
> Sent from my iPhone
>
> On 13 Mar 2015, at 19:58, Kalle Rosenbaum  wrote:
>
>> Hi all,
>>
>> I've been thinking about how a person can prove that she has made a
payment. I came up with an idea I call Proof of Payment (PoP) and I would
highly appreciate your comments. Has something like this been discussed
somewhere before?
>>
>> Use cases
>>
>> There are several scenarios in which it would be useful to prove that
you have paid for something. For example:
>> A pre-paid hotel room where your PoP functions as a key to the door.
>> An online video rental service where you pay for a video and watch it on
any device.
>> An ad-sign where you pay in advance for e.g. 2-weeks exclusivity. During
this period you can upload new content to the sign whenever you like using
PoP.
>> A lottery where all participants pay to the same address, and the winner
of the T-shirt is selected among the transactions to that address. You
exchange the T-shirt for a PoP for the winning transaction.
>>
>> These use cases can be achieved without any personal information (no
accounts, no e-mails, etc) being involved.
>>
>> Desirable properties:
>> A PoP should be generated on demand.
>> It should only be usable once to avoid issues due to theft.
>> It should be able to create a PoP for any payment, regardless of script
type (P2SH, P2PKH, etc.).
>> Current methods of proving a payment, as I know of:
>> BIP0070, The PaymentRequest together with the transactions fulfilling
the payment makes some sort of proof. However, it does not meet 1 or 2 and
it obviously only meets 3 if the payment is made through BIP0070. Also,
there's no standard way to request/provide the proof.
>> Signing messages, chosen by the entity that the proof is provided to,
with the private keys used to sign the transaction. This could meet 1 and 2
but probably not 3. This is not standardized either.
>> Proof of Payment, the data structure
>>
>> A proof of payment for a transaction T, PoP(T), is used to prove that
one has ownership of the credentials needed to unlock all the inputs of T.
It has the exact same structure as a bitcoin transaction with the same
inputs as T and with a single OP_RETURN output:
>>
>> OP_RETURN PoP  
>>
>> | Field | Size [B] | Description|
>> |---|--||
>> | PoP   | 3| Literal identifying this as a PoP  |
>> | | 32   | The transaction to Prove   |
>> || 5| Unsigned integer   |
>>
>> The PoP is signed using the same signing process that is used for
bitcoin transactions. The purpose of the nonce is to make it harder to use
a stolen PoP. Once the PoP has reached the destination, that PoP is useless
since the destination will generate a new nonce for every PoP.
>>
>> Proof of Payment, the pro

Re: [Bitcoin-development] Proof of Payment

[Kalle Rosenbaum]

>
> Actually, the security of the PaymetRequest is pretty much out of your
>> control as soon as the PaymentRequest is created on the server. You have no
>> idea what the hotel does with it. Also if it's stored in the hotel server I
>> have to trust the hotel to keep it safe for me.
>>
>
> Well, yes. But if the hotel itself is hacked then the whole process is
> meaningless, no? The hacker could just make the hotel think the proof of
> payment is correct even though it was never made at all, for instance.
>

Maybe the hotel example is not perfect for this discussion. Let's instead
assume that the server holds yearly subscriptions to some expensive video
service. If that service stores PaymentRequests for all their subscribers,
and accept them as proof of payment, that would be similar to storing
username and (possibly hashed) passwords for all subscribers. If all the
PaymentRequests for all users are stolen, then they have to shut down all
accounts if they discover the theft. If they don't discover the theft the
"accounts" are out in the wild, for sale, for blackmail, etc.

Wouldn't it be better if the service don't accept the reusable
PaymentRequests as proof, and instead accept a proof generated on demand,
at the very moment it is needed, and that it is only usable once? From a
usability perspective there is no difference; The users simply need access
the service and authorize the proof being sent to the server.


>
>
>> Another thing is that you assume BIP0070 is used for payments, which
>> isn't necessarily is the case.
>>
>
> It's just a convenient place to put things. There are lots of useful
> features that need BIP 70. I hope eventually all wallets will support it.
>

I also hope BIP0070 will take off. It would greatly improve the user
experience. But even then, all payments are not BIP0070. BIP0070 is
primarily for merchants who have the skills, time and money to use
certificates. I don't think a lottery at the local church would want to set
up a secure BIP0070 server, but they still might want to use bitcoin for
their lottery.

Regards,
Kalle
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proof of Payment

[Mike Hearn]

>
> As soon as that PaymentRequest leaves the wallet on its way to the hotel
> server, it is up for grabs
>

Is it? I'm assuming TLS is being used here. And the hotel server also has a
copy of the PaymentRequest, as the hotel actually issued it and that's how
they're deciding the receipt is valid. So I don't know how it could be
stolen unless the attacker can break TLS.
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proof of Payment

[Kalle Rosenbaum]

Hi

No I don't agree with the analysis.

Yes, the PaymentRequest can be stored with the same security as the private
keys are stored. The big difference is that the keys never leave the
wallet. As soon as that PaymentRequest leaves the wallet on its way to the
hotel server, it is up for grabs which makes it inappropriate for use as a
proof of payment other than for resolving disputes and other one-time stuff.

/Kalle


2015-03-13 22:31 GMT+01:00 Mike Hearn :

> Hi Kalle,
>
> I think you're thinking along the right lines, but I am skeptical that
> this protocol adds much. A saved payment request is meant to be unique per
> transaction e.g. because the destination address is unique for that payment
> (for privacy reasons). Where would you store the signed payment request?
> Probably in the wallet. You could just extract the metadata that's useful
> for UI rendering into a separate structure and then encrypt the original
> full payment request under the wallet key. At least this is how I imagine
> it would work.
>
> So then, if someone can steal a payment request they can probably steal
> the wallet signing keys too, and thus signing a challenge with the wallet
> keys doesn't add much. It means the wallet doesn't have to store the
> PaymentRequest encrypted. But AFAICT that's about all it does.
>
> Do you agree with this analysis?
>
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proof of Payment

[Mike Hearn]

Hi Kalle,

I think you're thinking along the right lines, but I am skeptical that this
protocol adds much. A saved payment request is meant to be unique per
transaction e.g. because the destination address is unique for that payment
(for privacy reasons). Where would you store the signed payment request?
Probably in the wallet. You could just extract the metadata that's useful
for UI rendering into a separate structure and then encrypt the original
full payment request under the wallet key. At least this is how I imagine
it would work.

So then, if someone can steal a payment request they can probably steal the
wallet signing keys too, and thus signing a challenge with the wallet keys
doesn't add much. It means the wallet doesn't have to store the
PaymentRequest encrypted. But AFAICT that's about all it does.

Do you agree with this analysis?
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proof of Payment

[Natanael]

Den 13 mar 2015 20:57 skrev "Kalle Rosenbaum" :
>
> Hi all,
>
> I've been thinking about how a person can prove that she has made a
payment. I came up with an idea I call Proof of Payment (PoP) and I would
highly appreciate your comments. Has something like this been discussed
somewhere before?
>
> Use cases
>
> There are several scenarios in which it would be useful to prove that you
have paid for something. For example:
> A pre-paid hotel room where your PoP functions as a key to the door.
> An online video rental service where you pay for a video and watch it on
any device.
> An ad-sign where you pay in advance for e.g. 2-weeks exclusivity. During
this period you can upload new content to the sign whenever you like using
PoP.
> A lottery where all participants pay to the same address, and the winner
of the T-shirt is selected among the transactions to that address. You
exchange the T-shirt for a PoP for the winning transaction.
>
> These use cases can be achieved without any personal information (no
accounts, no e-mails, etc) being involved.
>
> Desirable properties:
> A PoP should be generated on demand.
> It should only be usable once to avoid issues due to theft.
> It should be able to create a PoP for any payment, regardless of script
type (P2SH, P2PKH, etc.).

Relevant: https://idemix.wordpress.com/

Anonymous Credentials allows an issuer to declare that you have certain
rights. For example, upon paying the service provider could issue you the
credentials for using their service up until a certain date.

When challenged to prove a statement about what credentials you have, you
can prove the fact that you've got the right credentials without revealing
anything else. You don't even reveal you're the same person as the last
time, if you prove the right to access a VPN multiple times there's no data
in it that links the different sessions together.

The main difference is that issuance of Anonymous Credentials aren't
"atomic" with the payment transactions, which can open up the risk for
certain types of dishonest behavior by the seller. You could however use a
proof in court of having paid for the credentials but not getting them
issued to you (maybe throw in usage of Factom to log issuance of
credentials?). With this construction of using both these methods, you add
stronger privacy for the usage of the services while simultaneously keeping
a degree of accountability for the payment.

The Zerocoin developers also got a paper on a blockchain version,
"Distributed Anonymous Credentials".
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development