Bitcoin Forum
September 27, 2018, 11:07:50 PM *
News: ♦♦ New info! Bitcoin Core users absolutely must upgrade to previously-announced 0.16.3 [Torrent]. All Bitcoin users should temporarily trust confirmations slightly less. More info.
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 [16]  All
  Print  
Author Topic: Invoices/Payments/Receipts proposal discussion  (Read 24403 times)
gweedo
Legendary
*
Offline Offline

Activity: 1246
Merit: 1000


Java, PHP, HTML/CSS Programmer for Hire!


View Profile WWW
October 26, 2013, 03:25:10 AM
 #301

2) Once the payment has been made, there's no proof that you actually made that purchase.

So I guess the blockchain is just for show and the signing/verifying messages will be removed now.

Currently, you can prove that you made a payment,  but you can't prove that the merchant owns the address that you sent the funds to.

Lets back up now, this why we have SSL, we can kinda prove that the page we had with the address came from the valid source we want to pay.

2) Once the payment has been made, there's no proof that you actually made that purchase.
So I guess the blockchain is just for show and the signing/verifying messages will be removed now.
Currently, you can prove that you made a payment,  but you can't prove that the merchant owns the address that you sent the funds to.
Or what the terms of the agreement were.  "It was a donation!"

And forget courts— though perhaps someday it might matter in those too— it's also about making the case in the court of public opinion. Certainly plenty of people have made fraudulent scam complaints (against business competitors or just for fun).

Making strong cryptographic evidence of contracts is an important part of building infrastructure that enables people to freely contract without depending on things like courts to enforce their agreements.

Ok no one doubts that agreements/contracts need to be an important part of business and consumer relationship or even business to business. But as I see it CA's are still the biggest issue, they get hacked, they get court orders. That is the bottleneck of this whole protocol. Taxes you need those receipts especially for at least 7yrs (I didn't fact check that) what happens when a CA gets hacked, now my receipt is technically "invalided" cause they revoke that certificate. Now I am in a pickle because I need to prove I brought X amount of Y and the business can say we were hacked and didn't issue that receipt. I don't see any plan b.

Want to earn 2500 SATOSHIS per hour? Come Chat and Chill in https://goseemybits.com/lobby
1538089670
Hero Member
*
Offline Offline

Posts: 1538089670

View Profile Personal Message (Offline)

Ignore
1538089670
Reply with quote  #2

1538089670
Report to moderator
1538089670
Hero Member
*
Offline Offline

Posts: 1538089670

View Profile Personal Message (Offline)

Ignore
1538089670
Reply with quote  #2

1538089670
Report to moderator
1538089670
Hero Member
*
Offline Offline

Posts: 1538089670

View Profile Personal Message (Offline)

Ignore
1538089670
Reply with quote  #2

1538089670
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1538089670
Hero Member
*
Offline Offline

Posts: 1538089670

View Profile Personal Message (Offline)

Ignore
1538089670
Reply with quote  #2

1538089670
Report to moderator
kjj
Legendary
*
Offline Offline

Activity: 1302
Merit: 1001



View Profile
October 26, 2013, 03:59:23 AM
 #302

Lets back up now, this why we have SSL, we can kinda prove that the page we had with the address came from the valid source we want to pay.

No you can't.  The authentication in SSL is ephemeral.  At no point do you ever possess a document signed by their key.

17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8
I routinely ignore posters with paid advertising in their sigs.  You should too.
gweedo
Legendary
*
Offline Offline

Activity: 1246
Merit: 1000


Java, PHP, HTML/CSS Programmer for Hire!


View Profile WWW
October 26, 2013, 04:12:05 AM
 #303

Lets back up now, this why we have SSL, we can kinda prove that the page we had with the address came from the valid source we want to pay.

No you can't.  The authentication in SSL is ephemeral.  At no point do you ever possess a document signed by their key.

That is why I said kinda, but if you connected SSL to a site, and a CA says you are connected to the right server you can use that to prove that the page was coming from them. Yes of course Man the middle sets up a fake CA forces all other CA request to go thru him, then yes it isn't.

Want to earn 2500 SATOSHIS per hour? Come Chat and Chill in https://goseemybits.com/lobby
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2520
Merit: 1514



View Profile
October 26, 2013, 04:40:52 AM
 #304

now my receipt is technically "invalided" cause they revoke that certificate.
uhhh.  So you're saying that every receipt that doesn't have a cryptographic signature on it (meaning basically every receipt which has ever been created in the history of mankind) is "invalid"?

The CA model is weak and lame and mildly exploitative. But what alternative are you suggesting?   This is an optional feature, and if it's used its certainly no worse than if its not used.

The protocol itself is specifically designed to be extensible to other authentication types, but at the moment there don't appear to be any actually useful alternatives, as they arise future extensions can add support for them... and you still have the option of not using the authentication.

Bitcoin will not be compromised
gweedo
Legendary
*
Offline Offline

Activity: 1246
Merit: 1000


Java, PHP, HTML/CSS Programmer for Hire!


View Profile WWW
October 26, 2013, 04:59:38 AM
 #305

now my receipt is technically "invalided" cause they revoke that certificate.
uhhh.  So you're saying that every receipt that doesn't have a cryptographic signature on it (meaning basically every receipt which has ever been created in the history of mankind) is "invalid"?

The CA model is weak and lame and mildly exploitative. But what alternative are you suggesting?   This is an optional feature, and if it's used its certainly no worse than if its not used.

The protocol itself is specifically designed to be extensible to other authentication types, but at the moment there don't appear to be any actually useful alternatives, as they arise future extensions can add support for them... and you still have the option of not using the authentication.

No I am not saying that at all. What I am saying is a hacker can make it very difficult for me keep a receipt valid once I get it.

I wish I had the magic bullet alternative and was like here use A to do this. Sadly I don't that is why I think energy being put into something that we know is broken is utter waste of time and energy used in a better way.

I do have the option, but I would alienate my company when accepting bitcoins. Just like today, any newbie using the web knows to look for the green lock.

Want to earn 2500 SATOSHIS per hour? Come Chat and Chill in https://goseemybits.com/lobby
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2520
Merit: 1514



View Profile
October 26, 2013, 05:15:49 AM
 #306

No I am not saying that at all.
Then what you are saying makes no sense. If an unsigned receipt is valid then why would a signed receipt be invalid just because a CA was compromised?

Bitcoin will not be compromised
phillipsjk
Legendary
*
Offline Offline

Activity: 1008
Merit: 1000

Let the chips fall where they may.


View Profile WWW
November 16, 2013, 06:58:49 AM
 #307

I skimmed the whole tread.

Mike Hearn's FAQ helped explain the reasoning behind this: PKI is hard apparently.

I think the hostility to this stems from the fact that the CA system is known to be broken. An attacker will not try to change the "common name"; they will change the payment address: the very thing being hidden by this proposal.

With money on the line, attackers may even be well-funded, purchasing one of those corporate CA spoofing appliances in order to go after a high-value target.

I was also wondering why it was stated as fact that self-signed certificates allow the MITM attack. Later in the thread, somebody even pointed out that CAs themselves use self-signed certificates. The difficulty, hinted at in this link is that X.509 certificates do not allow the end-user to trust a specific CA for a specific domain. All CAs can sign for all domains: which makes me trying to be my own CA for *.economicprisoner.com a very bad idea.

In my experimentation with OpenPGP, I noticed that most people have shockingly lax certificate verification practices. They are confused when you ask for their public key: when you can simply search for their e-mail address or their short-key is included in their mail signature. They don't realize that it is trivial to generate collisions with both of those identifiers. There has essentially been a gentleman's agreement to not do that as far as I can tell. This tells me that even if a "bricks and mortar" business had the fingerprint of their self-signed cert prominently displayed: nobody would actually check it.

PS: To the people hung up on SSL: You can have Certs without using SSL.

TL;DR: I still don't like it, but don't really have a better suggestion at the moment. Namecoin would not work since the first person to grab a specific .bit domain can not be forced to surrender it in the event of a trademark dispute (unless you can get the holder in court somehow).


James' OpenPGP public key fingerprint: EB14 9E5B F80C 1F2D 3EBE  0A2F B3DE 81FF 7B9D 5160
Carlton Banks
Legendary
*
Offline Offline

Activity: 2142
Merit: 1341



View Profile
November 16, 2013, 08:29:24 PM
 #308

I was seeking clarification for this, and the reality is that this is no greater a danger to your privacy when paying than what everyone does today, and it increases the needed attack sophistication to replace a genuine merchant payment address with the address of an attacker.

The danger of any MITM attack with the Payments Protocol is not any privacy leak, but someone using a faked or stolen certificate in combination with further attack code infecting the webmerchant itself, all coming together to allow the attacker to supply their own address for the user to pay, instead of the address belonging to the webmerchant. The Payment Protocol could be tricked into validating the authenticity of the faked/stolen Certificate, and in turn incorrectly verifying the address as being one supplied by the webmerchant. Payment Protocol can't solve this problem, it's an issue with the inherent design of the CA system. But pulling it off successfully is more difficult to engineer than attacking the webmerchant payment methods being used today, hence the barrier to hijacking payments through html web pages are higher with Payments Protocol.

Personal information (like your real name, postal address and the Bitcoin address you pay from) is now and will continue to be transmitted to the merchant over plain old html, or using SSL encrypted htmls sessions if they're using currently considered best practice. What level of security the webmerchant uses to store this information on their servers is another factor. These things have nothing to do with Payment Protocol, it's between you and them: your browser and OS, their webstore software and webserver configuration.

Vires in numeris
justusranvier
Legendary
*
Offline Offline

Activity: 1400
Merit: 1006



View Profile WWW
January 09, 2014, 07:31:25 AM
 #309

A discussion of why the payment protocol should default to using BIP32 extended public keys instead of individual addresses, and a debunking of several common objections:

http://bitcoinism.blogspot.com/2014/01/business-accounting-and-bitcoin-privacy.html
Peter Todd
Legendary
*
expert
Offline Offline

Activity: 1106
Merit: 1001


View Profile
January 09, 2014, 11:36:36 AM
 #310

A discussion of why the payment protocol should default to using BIP32 extended public keys instead of individual addresses, and a debunking of several common objections:

http://bitcoinism.blogspot.com/2014/01/business-accounting-and-bitcoin-privacy.html

Or if you want to be able to reveal the address publicly without sacrificing privacy: Stealth Addresses

Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526
Merit: 1006


View Profile
January 10, 2014, 03:09:54 PM
 #311

A discussion of why the payment protocol should default to using BIP32 extended public keys instead of individual addresses, and a debunking of several common objections:

http://bitcoinism.blogspot.com/2014/01/business-accounting-and-bitcoin-privacy.html

Good article, thanks for writing it.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 [16]  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!