Bitcoin Forum
May 04, 2024, 09:17:57 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
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 24652 times)
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 4158
Merit: 8382



View Profile WWW
October 22, 2013, 06:27:17 AM
 #121

I was clearly the one being rude in this thread [...] cause I don't bow down to Gavin and his almighty coding power does make me rude
Case in point.
Quote
I never really reply on this sub-forum
Yes, as I said, this subforum is generally lower in nonsense than the rest of the forum.

Again, please feel free to state concerns, but if you regularly cannot manage to do so in a polite, adult manner I'm going to have to ask you to leave.

Back to the thread subject, the limitations of the CA infrastructure have been extensively discussed both in this very thread and in the older bitcoin-development thread. I agree that the CA infrastructure is lame, but the world doesn't really have any good PKIs.

Fortunately, the way the payment protocol is designed the CA infrastructure being potentially weak isn't all that critical, as payment messages can be sent directly between buyers and sellers over whatever secure channel they already have. An evil CA cannot do as ShadowOfHarbringer suggests, it cannot prevent people from transacting with each other even inside the payment protocol (of course, the option of just not using it would work too), nor can it produce completely undetectable forgeries, nor could it impersonate anyone _at all_ unless it could already impersonate your secure communications channel. As far as I know the x.509 support does in the payment protocol is create a non-reputable signature for invoices for messages which you would be sending over a secure channel anyways.

If a community of users (now or in the future) prefers to send their payment messages with external PGP signing— because they don't even trust the CA infrastructure for non-repudiation—, they can do that instead of or in addition to the x.509 key signing.
1714857477
Hero Member
*
Offline Offline

Posts: 1714857477

View Profile Personal Message (Offline)

Ignore
1714857477
Reply with quote  #2

1714857477
Report to moderator
1714857477
Hero Member
*
Offline Offline

Posts: 1714857477

View Profile Personal Message (Offline)

Ignore
1714857477
Reply with quote  #2

1714857477
Report to moderator
1714857477
Hero Member
*
Offline Offline

Posts: 1714857477

View Profile Personal Message (Offline)

Ignore
1714857477
Reply with quote  #2

1714857477
Report to moderator
"Bitcoin: mining our own business since 2009" -- Pieter Wuille
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1714857477
Hero Member
*
Offline Offline

Posts: 1714857477

View Profile Personal Message (Offline)

Ignore
1714857477
Reply with quote  #2

1714857477
Report to moderator
1714857477
Hero Member
*
Offline Offline

Posts: 1714857477

View Profile Personal Message (Offline)

Ignore
1714857477
Reply with quote  #2

1714857477
Report to moderator
1714857477
Hero Member
*
Offline Offline

Posts: 1714857477

View Profile Personal Message (Offline)

Ignore
1714857477
Reply with quote  #2

1714857477
Report to moderator
phelix
Legendary
*
Offline Offline

Activity: 1708
Merit: 1019



View Profile
October 22, 2013, 07:28:01 AM
 #122

There should have been a poll or something about the payment protocol and other features to go into the satoshi client much earlier. Now it is too late and we will vote the hard way.

In my opinion the CA system is bad and there are many things more important than the payment system. On the other hand side this is a great opportunity for Bitcoin to diversify into several independent client versions.

gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 4158
Merit: 8382



View Profile WWW
October 22, 2013, 07:48:56 AM
 #123

There should have been a poll or something about the payment protocol.
Do you even have any idea what you're talking about here? What do you think the payment protocol does? Or, stated another way why the histrionics. If you don't like it, just don't use it. It doesn't do anything if you don't use it.
ShadowOfHarbringer
Legendary
*
Offline Offline

Activity: 1470
Merit: 1005


Bringing Legendary Har® to you since 1952


View Profile
October 22, 2013, 08:45:37 AM
 #124

@Gavin

I tried to be as constructive & reasonable as possible (and no shouting/emphasing/whatever).
I am getting any of my questions answered ?

Once again, the questions were:
Quote
1. In the post-NSA-snowden era, are you sure it is wise to participate in creation of a centralized mechanism, which governments can easily control ? Why would we trust *any* CA ?
2. What would Satoshi think of this ? Isn't adding a centralized stuff to a decentralized-by-design system kind of senseless ?
3. How do you think will the tinfoil-hatted-extremely-paranoid Bitcoin community react, when they realize you added a broken by design schema to the most important Bitcoin app ?
4. What problem exactly  are you trying to solve with this solution ? I don't see Bitpay, Inpay, Coinbase or others complain that they cannot do business using Bitcoin without this feature ?
Isn't the invoicing possible to do through third party app or in-browser using SSL ?
5. Why add such a non-critical feature to the core client ? Isn't it supposed to be as clean, fast and efficient as possible without unnecessary bloat ?

ShadowOfHarbringer
Legendary
*
Offline Offline

Activity: 1470
Merit: 1005


Bringing Legendary Har® to you since 1952


View Profile
October 22, 2013, 08:52:22 AM
 #125

Can somebody quote my questions, please ?

Gavin probably has me on his ignore list again. And i really want my questions answered.

phelix
Legendary
*
Offline Offline

Activity: 1708
Merit: 1019



View Profile
October 22, 2013, 09:03:08 AM
Last edit: October 22, 2013, 09:59:07 AM by phelix
 #126

There should have been a poll or something about the payment protocol.
Do you even have any idea what you're talking about here? What do you think the payment protocol does? Or, stated another way why the histrionics. If you don't like it, just don't use it. It doesn't do anything if you don't use it.
"express strong emotions with an impressionistic style" - hehe. I think Bitcoin has the potential to improve the world. That's why I sometimes become emotional about it.

The shouting was just to stay in the style of the thread Wink My strong emotions against the payment protocol with CA system have somewhat faded as I also see the opportunity of diversification.

From what I understand the payment protocol is by far the largest single addition to the Bitcoin client ever (provocation or truth?). So it is a good idea to think about it twice.

It is very intransparent to me how the decision was made to include it. Is there some decision process? "For a BIP to become Active requires the mutual consent of the community." (https://en.bitcoin.it/wiki/Bitcoin_Improvement_Proposals)  -  hmmmm.

From an engineering perspective imho the core client should be separated from the GUI and be kept as minimalistic as possible. Hopefully libcoin or libbitcoin will take this role.



Can somebody quote my questions, please ?

Gavin probably has me on his ignore list again. And i really want my questions answered.

@Gavin

I tried to be as constructive & reasonable as possible (and no shouting/emphasing/whatever).
I am getting any of my questions answered ?
I'll go for it  Grin


Quote
1. In the post-NSA-snowden era, are you sure it is wise to participate in creation of a centralized mechanism, which governments can easily control ? Why would we trust *any* CA ?
No, but there is nothing better. (Namecoin is not ready yet Wink)

Quote
2. What would Satoshi think of this ? Isn't adding a centralized stuff to a decentralized-by-design system kind of senseless ?
Payment protocol is similar to the original IP paying that Satoshi had in mind. If you don't want your IP to be known you have to use Tor anyway.

Quote
3. How do you think will the tinfoil-hatted-extremely-paranoid Bitcoin community react, when they realize you added a broken by design schema to the most important Bitcoin app ?
You don't have to use it. Though it complicates the main client even more! Also: Most people will probably swallow everything.

Quote
4. What problem exactly  are you trying to solve with this solution ? I don't see Bitpay, Inpay, Coinbase or others complain that they cannot do business using Bitcoin without this feature ?
Can't really answer this one... maybe we don't know what we are missing? I think GM wrote: Big merchants are longing for it.
edit: Address privacy
edit2: refunds, memos

Quote
Isn't the invoicing possible to do through third party app or in-browser using SSL ?
5. Why add such a non-critical feature to the core client ? Isn't it supposed to be as clean, fast and efficient as possible without unnecessary bloat ?
So everybody can use it and it will penetrate the system ? I tried but I can not find a proper argument.
edit: The Satoshi client is the reference client. It needs to include every important feature so it can be tested.
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526
Merit: 1129


View Profile
October 22, 2013, 09:24:54 AM
 #127

These questions come up repeatedly, which is why I wrote an FAQ:

    https://bitcointalk.org/index.php?topic=300809.0

Please do read it. I really think by now that a lot of you will never stop discussing this or going round in circles, but ONE LAST TIME

Quote
1. In the post-NSA-snowden era, are you sure it is wise to participate in creation of a centralized mechanism, which governments can easily control ? Why would we trust *any* CA ?

As I have pointed out multiple times now, what we learned from the Snowden leaks is that the PKI works. The NSA and friends are not engaged in mass forgery of SSL certificates or any other kind of bulk attack on the certificate system, because they are unable to. Instead they are building large databases of whatever private keys they can obtain, via whatever mechanisms can be found.

There was one documented case where a forged certificate appeared to have been used. It was deployed in highly targeted attacks of the kind of that can take out basically any real-world software system. If an entire team of professional hackers goes after you, the chances of them failing are pretty low. The CA targeted could easily have been hacked and never even knew.

But even with that caveat, the certificate transparency upgrade is designed to expose hacked or malicious CA's publicly.

What's more, after Lavabit were forced to give up their SSL private key to the FBI, GoDadddy (the epitome of corporatism) revoked the SSL cert because industry policies required them to. I don't see how the existing set of CA's could have done a better job really, given the enormous scale on which the entire system operates.

But ultimately X.509 does not dictate any particular set of root certs. If you don't like the current set, feel free to go ahead and set up the ShadowOfHarbringer wallet that trusts the ShadowOfHarbringer CA, then start handing out certificates yourself. You can adopt whatever policies you want, including running your CA over Tor and being entirely anonymous.

Quote
2. What would Satoshi think of this ? Isn't adding a centralized stuff to a decentralized-by-design system kind of senseless ?

Given that Bitcoin 0.1 had a payment protocol in it, and he ended up disabling it due to the lack of authentication allowing MITM attacks, I can only assume he'd be fine with bringing it back in a fixed form.

But at any rate, calling the PKI "centralised" vs Bitcoin "decentralised" is kind of amusing, given that there are more root CA's than mining pools.

Quote
3. How do you think will the tinfoil-hatted-extremely-paranoid Bitcoin community react, when they realize you added a broken by design schema to the most important Bitcoin app ?

We know already. A few people on bitcointalk will get upset because they have a kneejerk reaction that says "companies == bad". The fact that there's a free market with hundreds of competitors to choose from will be ignored, the fact that they have not proposed anything better will cause them to be ignored. Also calling it "broken by design" is a way to get an insta-ignore because it simply isn't "broken by design", it's exactly the same system used to encrypt the internet connections of over a billion people daily. Rage that it isn't perfect if you like, but it's what we've got.

Quote
4. What problem exactly  are you trying to solve with this solution ? I don't see Bitpay, Inpay, Coinbase or others complain that they cannot do business using Bitcoin without this feature ?

Go read my FAQ, it's covered very thoroughly there.

Quote
Isn't the invoicing possible to do through third party app or in-browser using SSL ?

You do realize that SSL is exactly the same system supported by the payment protocol, right? You can't use SSL without getting a certificate from this so-called "centralized" system. Realistically all online web shops are expected to use SSL already, as Jeff has pointed out many times. So it doesn't make much difference in the end.

Quote
5. Why add such a non-critical feature to the core client ? Isn't it supposed to be as clean, fast and efficient as possible without unnecessary bloat ?

You mean the core client that has a complete cross-platform GUI? It's a reference implementation. Even if not many people choose to use it, it gives developers something to test against and it allows us to verify that what we've designed actually works in the real world. Plus, there are plenty of users who may choose to run a full node wallet, anyone who has a computer switched on 24/7 is a good candidate for using Bitcoin-Qt. With this question, you're really asking "why does anyone bother to maintain the Bitcoin-Qt GUI at all?" which is a topic for another time.
phelix
Legendary
*
Offline Offline

Activity: 1708
Merit: 1019



View Profile
October 22, 2013, 09:52:31 AM
 #128

Updated my answers above. I was close for 1. to 3.  Cheesy
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 4158
Merit: 8382



View Profile WWW
October 22, 2013, 10:20:07 AM
 #129

But at any rate, calling the PKI "centralised" vs Bitcoin "decentralised" is kind of amusing, given that there are more root CA's than mining pools.
Do take care there, it's not the right comparison.  _Generally_ more CAs == more vulnerable because any CA can author a cert for any domain.

The greater point is that the payment protocol, while it can use x.509 doesn't have security that turns totally brittle even if the CA infrastructure misbehaves.

I'd like to see better support for non-SSL CA stuff, but the options are pretty limited. Doing other things, however, is not mutually exclusive with also supporting x.509.

ShadowOfHarbringer
Legendary
*
Offline Offline

Activity: 1470
Merit: 1005


Bringing Legendary Har® to you since 1952


View Profile
October 22, 2013, 10:25:11 AM
 #130

Given that Bitcoin 0.1 had a payment protocol in it, and he ended up disabling it due to the lack of authentication allowing MITM attacks, I can only assume he'd be fine with bringing it back in a fixed form.
But there were several mentions of alternative ways to mitigate MITM problem in this very thread. Is none of them valid ? (I will cite the previous mentions from this thread):

- "Rivest's Interlock Protocol can prevent a man in the middle from altering your communications while allowing you to communicate at all.  At most, he is then reduced to an eavesdropper or able to engage a denial-of-service attack".
- "Bitcoin already has a solid public key infrastructure in that each and every coin is controlled by a public/private key pair.  If you know who owns a coin, you can compose a message to them and encrypt it using that coin's public key".
- "ZRTP: For people seeking trustless key exchange algorithm: it has been already invented (i.e. you can avoid MITM attack without relying on PKI) - ZRTP could be easily adapted to bitcoin payments, changing SAS authentication string to PIN , for example, as it can be only 16 bit number. However, you would have to trust the merchant not to scam you".

But at any rate, calling the PKI "centralised" vs Bitcoin "decentralised" is kind of amusing, given that there are more root CA's than mining pools.

1. This is not an excuse. Just because some part of Bitcoin is already centralized, should we make it even more centralized thus breaking it even more ? Where's the logic in that ?

2. There are decentralized pools (p2pool and such), just not many people are currently using it.
So mining is or at least *can be* decentralized.

----
Other than above, no more questions for now.

piotr_n
Legendary
*
Offline Offline

Activity: 2053
Merit: 1354


aka tonikt


View Profile WWW
October 22, 2013, 10:42:00 AM
Last edit: October 22, 2013, 02:29:14 PM by piotr_n
 #131

You mean the core client that has a complete cross-platform GUI? It's a reference implementation. Even if not many people choose to use it, it gives developers something to test against and it allows us to verify that what we've designed actually works in the real world. Plus, there are plenty of users who may choose to run a full node wallet, anyone who has a computer switched on 24/7 is a good candidate for using Bitcoin-Qt. With this question, you're really asking "why does anyone bother to maintain the Bitcoin-Qt GUI at all?" which is a topic for another time.
Sure, that's a great point!
Since Bitcoin-Qt is already one big mess, with like almost 10 dependency libs, why not to turn it into even a bigger one, right?

You know what, you guys keep doing what you do and in the meantime I will just go to buy some popcorn...
It's gonna be useful when one day I finally get to watch the show, after the great "let's mess it all up even more" approach to the bitcoin development blows right up into your face.

Check out gocoin - my original project of full bitcoin node & cold wallet written in Go.
PGP fingerprint: AB9E A551 E262 A87A 13BB  9059 1BE7 B545 CDF3 FD0E
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 4158
Merit: 8382



View Profile WWW
October 22, 2013, 10:45:11 AM
 #132

However, you would have to trust the merchant not to scam you".
None of that list of things actually do anything to address whats the payment protocol is doing.  x.509 is used to provide non-repudiation. The merchant tells you to pay 5 BTC to scriptpubkey X and they'll send you 10 widgets.  If the merchant scams you, you can show other people the signed invoice to convince them that the merchant really did make that agreement.  This means that none of the authentication for ephemeral keying things are actually useful (e.g. every one of your bulleted "alternatives"), nor is "have to trust the merchant not to scam you".

Since Bitcoin-Qt is already one big mess, with like almost 10 dependency libs, why not to turn it into even a bigger one, right?
Payment protocol does not increase the lib dependencies in bitcoin-qt/bitcoind. Have you looked at the implementation? it's pretty small.
piotr_n
Legendary
*
Offline Offline

Activity: 2053
Merit: 1354


aka tonikt


View Profile WWW
October 22, 2013, 10:53:47 AM
 #133

Payment protocol does not increase the lib dependencies in bitcoin-qt/bitcoind. Have you looked at the implementation? it's pretty small.
It ties the implementation to openssl lib even more, making it harder (if not impossible) to remove openssl dependency in the future.
And openssl is a much bigger mess than the bitcoin at the current stage.

As we have learned recently NSA is probably actively trying to put backdoors wherever they can.
There are reasons to suspect that they had Google to put one into Android's RNG - also an open source code.
I would say that openssl would be one of their targets as well.
But it does not even need to be NSA - it can be just a bug.
All it takes is one bug that would allow to inject an exploit via a stack overflow (e.g. via a "broken" certificate) - and there goes all your money...

Check out gocoin - my original project of full bitcoin node & cold wallet written in Go.
PGP fingerprint: AB9E A551 E262 A87A 13BB  9059 1BE7 B545 CDF3 FD0E
ShadowOfHarbringer
Legendary
*
Offline Offline

Activity: 1470
Merit: 1005


Bringing Legendary Har® to you since 1952


View Profile
October 22, 2013, 10:56:14 AM
 #134

Since Bitcoin-Qt is already one big mess, with like almost 10 dependency libs, why not to turn it into even a bigger one, right?
Payment protocol does not increase the lib dependencies in bitcoin-qt/bitcoind. Have you looked at the implementation? it's pretty small.

Point taken, however this makes the possible ramifications even worse.
Because the implementation is so efficient and bloat-free, the risk of it becoming "standard" way of doing transactions in the future is even bigger.

So as I already wrote, 15 years from now it may not be possible to buy something using Bitcoin without trusting some CA, which are controlled by government.

But well, if using PKI stays optional, then I think I can live with that. Still, I hope most people will not be using this broken (as of today) functionality.

ShadowOfHarbringer
Legendary
*
Offline Offline

Activity: 1470
Merit: 1005


Bringing Legendary Har® to you since 1952


View Profile
October 22, 2013, 10:59:15 AM
 #135

Payment protocol does not increase the lib dependencies in bitcoin-qt/bitcoind. Have you looked at the implementation? it's pretty small.
It ties the implementation to openssl lib even more, making it harder (if not impossible) to remove openssl dependency in the future.
And openssl is a much bigger mess the bitcoin at the current stage.
Actually there is an easy solution for it.
There is a minimal version of openssl targetted specifically for low-power embedded devices: cyassl

You are obviously a low-level programmer, so stop wasting time on the forums and perhaps make Bitcoin compatibile with it.

piotr_n
Legendary
*
Offline Offline

Activity: 2053
Merit: 1354


aka tonikt


View Profile WWW
October 22, 2013, 11:05:06 AM
 #136

Linking a blockchain parser and (even worse) a wallet with any SSL lib is totally unnecessary and hugely irresponsible.

Check out gocoin - my original project of full bitcoin node & cold wallet written in Go.
PGP fingerprint: AB9E A551 E262 A87A 13BB  9059 1BE7 B545 CDF3 FD0E
Carlton Banks
Legendary
*
Offline Offline

Activity: 3430
Merit: 3071



View Profile
October 22, 2013, 01:13:19 PM
 #137

Benign interpretations of NSA's ability to abuse technology companies do not inspire confidence, it assumes we have all of the facts. You can't even assume that Edward Snowden has all the facts, and not all his revelations have been published yet.

It makes more sense to me to be prudent, given the above. We have no control over what content gets delivered in payment request messages; a merchant that didn't disclose personal details one week might suddenly change that the following week, and equally, a merchant that self signs messages might suddenly start using CA signed messages subsequently. The first awareness we end users of these merchants can discover their changing use of the Payments Protocol will be once the potential identity leak has already taken place, when it's too late to choose against it.

I won't be using this protocol until I can somehow be certain that I know what type of information will be in the Payments Protocol message and how the message will be delivered. I want to wear my all-body faraday-cage suit, thankyouverymuch.

Vires in numeris
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 4158
Merit: 8382



View Profile WWW
October 22, 2013, 01:38:59 PM
 #138

So as I already wrote, 15 years from now it may not be possible to buy something using Bitcoin without trusting some CA, which are controlled by government.
This just isn't how it works. You keep repeating this, but it's nonsensical.

You can transmit a payment request via whatever channel you want. If the x.509 non-repudiation signature in it is not secure you're still secured by whatever channel you're transmitting the data over.  If you have no secure channel at all, your problem is ... kinda out of scope for the payment requests.

What would you have the payment protocol do instead? All you've done so far is list completely inapplicable things that demonstrate that you don't understand what it does at all.
Carlton Banks
Legendary
*
Offline Offline

Activity: 3430
Merit: 3071



View Profile
October 22, 2013, 01:42:34 PM
 #139

So as I already wrote, 15 years from now it may not be possible to buy something using Bitcoin without trusting some CA, which are controlled by government.
This just isn't how it works. You keep repeating this, but it's nonsensical.

You can transmit a payment request via whatever channel you want. If the x.509 non-repudiation signature in it is not secure you're still secured by whatever channel you're transmitting the data over.  If you have no secure channel at all, your problem is ... kinda out of scope for the payment requests.

All these "you"s are the person sending the payments request, are they not?

Vires in numeris
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 4158
Merit: 8382



View Profile WWW
October 22, 2013, 02:16:24 PM
 #140

All these "you"s are the person sending the payments request, are they not?
Yes, but if you're going to make the argument that you're being harmed by bitcoin-qt not restricting the freedom of others (an argument I've used here and there at times) I don't think it applies here.

The payment protocol doesn't provide its own secure channel. Thats not what x.509 for is used for in the payment protocol. The use of x.509 in the payment protocol is for non-repudiation (which many secure communications channels don't provide, including SSL).  Without a secure communications channel your privacy/security is hosed, and with one your usage of the payment protocol is secure from privacy or theft attacks even if the x.509 certs aren't secure.

In particular: It's primarily the sender the payment request which cares about the integrity of non-repudiation since if their non-repudiation is compromised customers will be able to convince others that the sender ripped them off.

If someone were making an argument about non-repudiation there might be something to discuss here, but no one appears to be talking about it.
Pages: « 1 2 3 4 5 6 [7] 8 9 10 11 12 13 14 15 16 »  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!