Topic: Invoices/Payments/Receipts proposal discussion - page 2. (Read 24728 times)

Maybe it is not (anyway I don't think bitcoin will be used as a payment medium at large scale due to liquidity problem), but judging from the extensive amount of explanation in BIP70, I can't say it is a minor change

well I suppose I was looking at it from the point of view of the customer and not the merchant.
if you use a different certificate for the invoicing, possibly from a different certificating authority, then how do I know that both of these separate authorities have been able to ascertain that the owners of both certificates are the same? it seems to introduce extra security issues.
I would have thought that best practice would have been to use the same certificate seeing as the main focus of this in the first place was to provide the customer with a provably authentic receipt.


 of course if we're talking about best practice in terms of key management it might be considered that if you can't manage one key properly then you'll do a better job with two?
 i am sure that in reality the invoice keys would be signing stuff dynamically and would not necessarily be any more insulated from the outside world than any other private key being used for encryption - unless you were going to manually sign each invoice away from the server.

 I am being picky here but using two different certificates, possibly from different authorities does technically introduce other problems into any authentication protocol.
 

Ok, I'm following. So this means that the unhashed Payment Details are not required to verify the signature, contrary to my presumption before. Any light to shed on why the Payment Details are used to generate signatures at all? They themselves form no part of the verification. Is it useful (for security?) to have some piece of "unique to this transaction" data to generate the signature? I appreciate that the hashed Payment Details are not being sent to the CA, so if anything they're more vulnerable when sent SSL encrypted, but not hashed, to the user from the merchant (as well as from the user to the merchant in the first instance). There must be a good reason to hash the Payment Details and have them specifically signed and sent to the user for verification against the CA certificate (which the user already possesses locally via a web browser or their OS)!

Sorry about all this, but I'm quite capable of misinterpreting documents like BIP 70 that are pretty concisely defined in their descriptions, now that I can take another look having talked it over.

 

Huh?

By definition, the https certificate and private key must be on the front line.  Keeping that private key secure is a gigantic pain in the ass, and pretty much no one bothers doing it right.  They are pretty much disposable.

The invoice key, however, can sit safely on a hardened back end box, well insulated from the outside world.  Depending on the implementation, you can also store it encrypted with the encryption key stored only in non-swapped memory.  (You can do the encryption thing on a webserver too, but no one ever does.*  Think load balancers and cloud servers starting up without human intervention.)

So, while the two offer little difference in security, it is still a "best practice" to do things right, when possible.

* For certain values of "no one".  I used to work in a datacenter, and one of our customers had their webserver configured for security.  We had to physically key in the decryption key for the certificate's private key every time the server rebooted.  Everyone hated that box, I think including the customer.

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

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?

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.

bitcoin: URI hander.

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.

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.

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.

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.

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

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.



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.

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?

Hi Carlton,

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


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


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.


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.

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 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.

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"

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")