Invoices/Payments/Receipts proposal discussion

[piotr_n]

I am not saying it is a rocket science - I am saying that OpenSSL is a one big mess and nobody knows what it really does these days.
Come on, you must know life; how much you can actually rely on any documentation? OpenSSL is surely no exception.
Mind that you have just quoted "Bugs" section of the doc, to support your statement that "No attempt is made to download CRLs from the CRL distribution points extension".

If my fate is about to be judged on whether you set a flag or not while calling the lib, and whether this flag actually does what the man page says it should - then I would rather stay away from such a secured payment solution. And I will be advising people to do the same, if you don't mind.

[1714861550]

1714861550

[1714861550]

1714861550

[1714861550]

1714861550

[1714861550]

1714861550

[1714861550]

1714861550

[grau]

While I assume that you integrate these protocols with extreme care, they are hairball on their own with lots of flavors and options. Adding them is the exact opposite of what I would like to see happening to the reference client.

Is there a hope for a standard build without payment protocol, like the no wallet option jgarzik worked on?

[piotr_n]

Yeah, that would be cool.
A no-GUI node with a block-parser only, no wallet and as few external dependencies as possible, even without UPnP.
Instead of adding more mess to the existing one...

[justusranvier]

Yeah, that would be cool.
A no-GUI node with a block-parser only, no wallet and as few external dependencies as possible, even without UPnP.

It's called btcd.

[metacoin]

Yeah, that would be cool.
A no-GUI node with a block-parser only, no wallet and as few external dependencies as possible, even without UPnP.
Instead of adding more mess to the existing one...

Hopefully this soon becomes a reality. In Gavin's blog post today, he mentioned the goal of making the client less monolithic and more modular. This is absolutely a step in the right direction.

We are (slowly) moving from a monolithic code base that does everything (wallet, RPC, network, blockchain storage/validation) towards more modular internals with fewer dependencies between the different pieces. Another change you should see in the 0.9 release is moving away from the bitcoind executable functioning both as a server and as a RPC client– Wladimir J. van der Laan split the RPC client functionality (“tell the running bitcoin daemon to do THIS”) into a separate executable, ‘bitcoin-cli’.  The RPC client code will eventually be removed from bitcoind, but will be kept for backwards compatibility for a release or two.

https://bitcoinfoundation.org/blog/?p=290

[Carlton Banks]

I'd just like to make the general point that if we were all perfectly aware of every factor that affects this new introduction pertaining to all wider contexts, then there wouldn't really be anything to discuss. Sort of a general principle to the concept of discussions, really.

Those that complain about me and others being ignorant of everything that they themselves already know should get a grasp of the limits of their own perceptions. Your expert level of understanding is by definition exceptional. Opening it up to discussion, but making any reasonable discussion conditional on us all being versed in everything you know is clearly never going to be productive. We do need to get your comments on the implications of this proposal, your comments are the most relevant of all contributors, seeing as you guys know this software better than anyone else. Some don't trust your motives for the introduction, others like me don't know either way and would like to take the opportunity proposed by the creation of this thread to, as described, discuss the proposal. It seems as if the very idea that broaching subject of whether this protocol endangers the privacy or identity of the user is being taken as an offense, and I am sorry if that's how you feel, but it's unavoidable given the wider circumstances. If you know you're acting with the best intentions, then having your integrity questioned by those that do not understand the whole as completely as you do must be frustrating. This is no excuse to behave unpleasantly towards those who pose the questions, especially when my own such questions have been posed entirely on the basis of the technical aspects without bringing any aspersion on the good character or technical competence of the core developers who choose to answer the questions. It seems that not all devs can say the same about their own conduct in this thread.

I propose that we should be concentrating on improving the understanding and acceptance of this protocol, not indulging in one-upmanship as a diversion from the topic matter. Anyone would think that this proposal is already reflected in the title of this thread, which is not "Where everyone tears strips off each other to prove who's the biggest computer science know-it-all, under the pretense of discussing some protocol or other". The outcome of the overall consensus of this discussion should be more important to us all than the way this has played out so far.

(plaudits to kjj for writing some good posts overviewing the relevancy of the SSL PKI, a far more useful response than just saying "read up about the entire thing from this overarching article")  

[johnyj]

Sigh, I'm not a technical expert and I don't have time to dig into it either, but I start to understand why central banks control the world by just printing money

We now have the most brilliant monetary system in the world but the designer of the system are talking about business, profit, salary ... Exactly those things made billions of people the slaves of current monetary system while bankers happily print money to keep them working ...

How did those banks achieve this? All they did is very simple: Maintain and strengthen people's trust of their monetary system. They build biggest modern office, paying employee highest salary, strict clothing rules... Just to make sure people always believe that they are trustworthy and professional, and they seldom change their system for decades

But what I saw here is opposite: Once a while devs will come out with a complex change that brings a lot of uncertainty, reduce our trust and increase our confusion. The bitcoin project is quite unstable, not very trustworthy, at least in my opinion

I wish core devs can spend some time on monetary history and macro economy to better understand the devastating power of this project, thus less concerned about trivial things at enterprise level. All the enterprises in the world are still slaves of banks, since they only care about profit and they don't know where those money they made come from

Is there any dev spend enough time studying the meaning of what Satoshi wrote in the genesis block?
"The Times 03/Jan/2009 Chancellor on brink of second bailout for banks"

[kjj]

Ok, so only the holder(s) of the merchant's privkey can verify that the signature is a hash of the Payment Request. The merchant's certificate cannot be used to do this. Is this right?

If so, I still fail to understand the necessity of hashing the Request Details and signing that. The end user cannot verify that the hash is a result of such a hashing operation, and they are the only recipient of this signature. Only the merchant should be able to ascertain that the signature is generated by signing a hash of the Request, and they have no apparent need to verify this, being as they presume to have collected the details in a direct https session with the user.

Why use the Payment Details, which the merchant should be confident of anyway?

No, in DSA systems, the signature is verified with the public key, but created with the private key.  This way, only the private key holder can create a signature, but anyone can verify it.  The certificate is a jumble of stuff, but at heart it is a carrier for the public key and information related to the public key.

This is really the whole point of digital signatures, and the reason why DSA is always done with public key cryptosystems.

I'd just like to make the general point that if we were all perfectly aware of every factor that affects this new introduction pertaining to all wider contexts, then there wouldn't really be anything to discuss. Sort of a general principle to the concept of discussions, really.

Those that complain about me and others being ignorant of everything that they themselves already know should get a grasp of the limits of their own perceptions. Your expert level of understanding is by definition exceptional. Opening it up to discussion, but making any reasonable discussion conditional on us all being versed in everything you know is clearly never going to be productive. We do need to get your comments on the implications of this proposal, your comments are the most relevant of all contributors, seeing as you guys know this software better than anyone else. Some don't trust your motives for the introduction, others like me don't know either way and would like to take the opportunity proposed by the creation of this thread to, as described, discuss the proposal. It seems as if the very idea that broaching subject of whether this protocol endangers the privacy or identity of the user is being taken as an offense, and I am sorry if that's how you feel, but it's unavoidable given the wider circumstances. If you know you're acting with the best intentions, then having your integrity questioned by those that do not understand the whole as completely as you do must be frustrating. This is no excuse to behave unpleasantly towards those who pose the questions, especially when my own such questions have been posed entirely on the basis of the technical aspects without bringing any aspersion on the good character or technical competence of the core developers who choose to answer the questions. It seems that not all devs can say the same about their own conduct in this thread.

I propose that we should be concentrating on improving the understanding and acceptance of this protocol, not indulging in one-upmanship as a diversion from the topic matter. Anyone would think that this proposal is already reflected in the title of this thread, which is not "Where everyone tears strips off each other to prove who's the biggest computer science know-it-all, under the pretense of discussing some protocol or other". The outcome of the overall consensus of this discussion should be more important to us all than the way this has played out so far.

(plaudits to kjj for writing some good posts overviewing the relevancy of the SSL PKI, a far more useful response than just saying "read up about the entire thing from this overarching article")   

I'd like to point out that this is not an expert level discussion, not even close.  This is basic stuff, "Introduction to Cryptography 101" level.  In short, this is stuff that you should already know to participate in discussions in Dev & Tech.

I don't say that to be insulting.  I don't want to drive anyone away.  I don't want to discourage anyone from learning.  I don't want to prevent anyone from contributing to the conversation.  Quite the opposite on all counts, actually.  I have very little time to devote to bitcoin, but most of the time that I do have is spent helping and teaching others, at the expense of time I'd rather be spending on my own projects.

But if someone comes in here and their understanding is not sufficient to making meaningful contributions, they really should spend a lot of time reading silently, or asking very polite questions and reading the answers with great care.  What they should not be doing is repeating nonsense they heard elsewhere or arguing with the dismissive answers they get when they do.

Now let me explain why I'm so hostile to piotr_n.  For the last year or two, there has been a deluge of FUD.  Virtually all changes that have come to public discussion have come under relentless attack, typically by people "asking questions" and spreading misinformation.  Piotr is a good example of this.  Go read his post history and you'll find a fairly complete catalog of recent changes to the bitcoin system.  He is opposed to every single one of them, he thinks that Gavin is the puppet of the Illuminati, and when pressed, he doesn't know a fucking thing about anything he's ever talked about.

But he isn't alone.  Dozens of him have come and gone.  I don't like to assume malice while incompetence is still a viable option, but after a while even the least paranoid among us starts to wonder exactly who wants to undermine the development team and process, and why.

So, again, I apologize to anyone* that has ever been dismissed or answered less than politely.  But no one here is here to educate you, particularly not about the basics, and if you show up saying the sorts of crap that we've been dealing with nonstop for the last year or so, the odds really aren't in your favor.

* With a few exceptions.

[riplin]

Hi Carlton,

Sorry I snapped at you. You kind of got caught in the crossfire.

I'd just like to make the general point that if we were all perfectly aware of every factor that affects this new introduction pertaining to all wider contexts, then there wouldn't really be anything to discuss. Sort of a general principle to the concept of discussions, really.

There would be loads to discuss. New features, other security measures, etc.

Those that complain about me and others being ignorant of everything that they themselves already know should get a grasp of the limits of their own perceptions. Your expert level of understanding is by definition exceptional. Opening it up to discussion, but making any reasonable discussion conditional on us all being versed in everything you know is clearly never going to be productive.

The problem is, it's not a discussion if some parties are not educated in some of the core technologies that are being used in the payment protocol. I for example could not have any kind of meaningful discussion with a quantum physicist, simply because I don't know anything about the subject matter. I can ask him loads of questions, but me making any kind of statement on the subject at hand would be foolish.

We do need to get your comments on the implications of this proposal, your comments are the most relevant of all contributors, seeing as you guys know this software better than anyone else.

Ok, I'll try to summarize what the payment protocol is trying to solve (at least, the way I see it, correct me if I'm wrong).

Right now, when you want to buy alpaca socks, you go to the website, click on the product, click pay and then you're presented with a QR code or a link that you can use to make a payment to the merchant.

There are two problems with this.

1) There's no telling if that QR code or link isn't modified en route to your computer (man in the middle attack);
2) Once the payment has been made, there's no proof that you actually made that purchase.

The first one isn't even a truly big issue. Most likely the webpage you're visiting is already running over SSL. The second one however, proof of purchase, is a big one. If you want to file a dispute (and would want to take the merchant to small claims court), then you want to show the judge some kind of receipt. That's exactly what the payment protocol provides. A signed payment request (tied to the merchant's identity), containing the payment request and the address(es) that you sent your payment to.

That's the gist of it. It has other features, like you can supply a refund address when you make your payment and you optionally get an acknowledgement (but this is optional).

At no point in this communication is the customer required to identify himself. (other than the practical need to supply a shipment address for the product of course).

I'm sure there are more things possible, but that's in layman's terms what it does.

In two words: Consumer protection.

[grau]

1) There's no telling if that QR code or link isn't modified en route to your computer (man in the middle attack);
2) Once the payment has been made, there's no proof that you actually made that purchase.

The first one isn't even a truly big issue. Most likely the webpage you're visiting is already running over SSL. The second one however, proof of purchase, is a big one.

We agree that the first one is not really an issue since every serious webpage works with https:// and a certificate of a well known CA.

The second is an issue not limited to Bitcoin but to any type of payment. Having a cryptographic proof of the payment at customer side would positively distinguish Bitcoin payments.

In my opinion both address generation and digital receipts belong to the webshop's business process facilitated by other tools. There could be a whole lot of business rules influencing how payment is requested and there are already digital bills and regulatory requirements to present a receipt for money taken in (at least in the EU). 

I do not question if goals of payment protocol are noble or that its design is not careful and state-of-the art, but if it should be embedded into the bitcoin protocol server.

I wish for a proof of concept implementation of the payment protocol that is a separate build artifact from the protocol server and ask if this was considered and if why rejected?

[riplin]

The second is an issue not limited to Bitcoin but to any type of payment. Having a cryptographic proof of the payment at customer side would positively distinguish Bitcoin payments.

Yup. Right now there's nothing you can provide as proof, as compared to traditional payment methods, where identities are already linked to CC's and bank accounts, etc.

I wish for a proof of concept implementation of the payment protocol that is a separate build artifact from the protocol server and ask if this was considered and if why rejected?

https://github.com/gavinandresen/paymentrequest


Should give you everything you need to get up and running. I recall that Gavin also had a test page up and running somewhere, but I can't seem to find it right now.

[grau]

I wish for a proof of concept implementation of the payment protocol that is a separate build artifact from the protocol server and ask if this was considered and if why rejected?

https://github.com/gavinandresen/paymentrequest


Should give you everything you need to get up and running. I recall that Gavin also had a test page up and running somewhere, but I can't seem to find it right now.

This is great, but why is it planned to be closely coupled and embedded with the code base of bitcoin-qt in 0.9 ?

[riplin]

I wish for a proof of concept implementation of the payment protocol that is a separate build artifact from the protocol server and ask if this was considered and if why rejected?

https://github.com/gavinandresen/paymentrequest


Should give you everything you need to get up and running. I recall that Gavin also had a test page up and running somewhere, but I can't seem to find it right now.

This is great, but why is it planned to be closely coupled and embedded with the code base of bitcoin-qt in 0.9 ?

I edited my previous comment, but I'll move it here.

It makes sense to roll this into the Bitcoin-QT client (in fact, it would be totally awesome if all bitcoin clients were to support it). It's kind of the same as the mailto: URI handler. It wouldn't make much sense to have a separate app that would handle that for you only to present it to you so you could copy/paste it into your email client.

The payment protocol is proposed to become a standard way for merchants to present payment requests. If everyone were to roll their own solution, it would be really hard for all the wallet developers to support. And as was stated earlier in this thread, this is version 1. Everyone is welcome to propose new features, improvements, etc for an eventual version 2. On top of that, the protocol buffers allow you to add additional fields to the messages that you could use in your own solution to extend the current functionality.

As for the server side, that's what you could use that reference implementation for.

[grau]

It makes sense to roll this into the Bitcoin-QT client (in fact, it would be totally awesome if all bitcoin clients were to support it).

Would it not be easier to achieve wide support by implementing the payment protocol self contained, so it can be connected to other wallet implementations?

I know, bitcoin-qt does not currently have interfaces to allow such loose coupling, but should that be the excuse to embed yet an other complex protocol instead of implementing a better interface?

We do suffer under a monolithic reference implementation and this extension, if added as usual, compounds the problem.

[riplin]

It makes sense to roll this into the Bitcoin-QT client (in fact, it would be totally awesome if all bitcoin clients were to support it).

Would it not be easier to achieve wide support by implementing the payment protocol self contained, so it can be connected to other wallet implementations?

I know, bitcoin-qt does not currently have interfaces to allow such loose coupling, but should that be the excuse to embed yet an other complex protocol instead of implementing a better interface?

We do suffer under a monolithic reference implementation and this extension, if added as usual, compounds the problem.

If you look at the C++ code, it's quite minimal. ~600 lines of code total. The bulk of the work is probably UI handling, database storage, etc. That's all pretty specific per wallet implementation. I personally don't think it's going to be too big of an issue.

[wumpus]

I know, bitcoin-qt does not currently have interfaces to allow such loose coupling, but should that be the excuse to embed yet an other complex protocol instead of implementing a better interface?

How would that help? It'd put another program between the wallet client and the web browser which does what, exactly? The payment request interface as it is now is pretty well documented (https://en.bitcoin.it/wiki/BIP_0070), and if you have questions you can always ask them on the mailing list or IRC channel. I don't get what would be gained with another interface.

IMO it's much better if the different wallet clients simply implement the payment protocol themselves. If you've gone all the way to implement a bitcoin client, which is an impressive feat, adding the payment protocol functionality is easy and relatively well documented and easily testable.

[jgarzik]

This is great, but why is it planned to be closely coupled and embedded with the code base of bitcoin-qt in 0.9 ?

bitcoin: URI hander.

[grau]

If you've gone all the way to implement a bitcoin client, which is an impressive feat, adding the payment protocol functionality is easy and relatively well documented and easily testable.

I did not re-implement a "bitcoin client" but a protocol server facing P2P and other modules that connect to the protocol server using its message bus.

Those modules implement wallets, exchanges, a payment processor and more to come. The payment protocol is a puzzle that will fit into some modules or be implemented as part of specific business processes.

I would eventually replace my protocol server with the reference client if it was moving into a direction of being extensible instead of embedding yet an other proof of a concept. I agree with the concept but not the implementation and the priority it enjoys.

[Crowex]

1. Merchant pays for a certificate from a certificate authority, and
then gives the payment service the certificate and their private key.
This could be the same certificate and private key as is used for the
merchant's web site, but best security practice would be to purchase a
separate certificate for authenticating Invoices.


why is it best security practice to buy a separate certificate?
if I trust the original website authentication and encryption then why wouldn't I trust it to sign the invoice and know that the person who signed the invoice is the one that I have been communicating with.
If I don't trust the original certificate then why would getting a separate certificate give me any more confidence.
I don't understand the security advantages of a separate certificate?

[johnyj]

Just because there have been security breaches, doesn't mean that the system is useless.  While the system could be improved, the alternatives are terrible.  If you don't use an established system, then you need to build up a whole new "web of trust", and users and merchants will be doing a lot of work, outside an established system, just to accommodate this use case (Bitcoin payments).

This put it very well

The spirit of bitcoin is "trust no one but the network", since human are always prone to failure. So, build up a trust of web will just end up like today's system where a few highly trusted elites sitting at the top deciding people's fate, and when they run into a crisis, they turn to government asking for bailout

Of course it is convenient for children to find a trustworthy authority to rely on, but adults should manage their own risk individually. If everyone know how to manage risk by themselves and don't blindly trust authorities like banks and institutions, they won't run into this financial crisis

My opinion is that user should manage their own risk in payment. If they have a good risk management strategy, and accidentally lose some money, that should not impact them too much

And from risk management point of view, this move is also risky for bitcoin, because it is a large change. If it caused some unforeseeable problem in future, it will spread negative sentiment for bitcoin, sink its value, thus impact all bitcoin users (majority of bitcoin users use it as a store of value)

Third party payment solution will not affect bitcoin network, thus much less risky for bitcoin's robustness. I think an interface for third party payment solution to connect to is much better in this case