3 ms·

Hm, I am Not Happy about a feature of the new protocol. It's unfortunate that -- although I can hear the gears of politics turning in the document -- the detail

by gwillen 14y ago

Hm, I am Not Happy about a feature of the new protocol. It's unfortunate that -- although I can hear the gears of politics turning in the document -- the details of the argument that spawned it are not laid out there for me to read. In this day and age, using X.509 for something like this is ... pretty bad. The bitcoin community elsewhere has standardized on PGP, and with very good reason; X.509 is a well-known clusterfuck. I understand wanting to include an X.509 option anyway, if the point is not to improve usability by the bitcoin community, but rather by people who aren't already in it. But I do not think the lack of a PGP option is excusable, and I do not wish to see the protocol succeed in its current form for that reason. (I can't imagine a significant fraction of the bitcoin community will want it to succeed in this form either.)

maaku 14y ago
IIRC (I'm on the developer mailing list, but only skimmed the relevant thread), the X.509 part has been made optional, and there is support for other trust mechanisms such as PGP.
- gwillen 14y ago
  Oh, that's fantastic news. Thanks for updating me. I will check out the list archives to learn more.
sneak 14y ago
https://github.com/gavinandresen/paymentrequest/issues/1 https://github.com/gavinandresen/paymentrequest/issues/1
contingencies 14y ago
Hey there. I was one of the first to raise this anti-X.509 sentiment on the list and gist. Here's my initial fork: https://gist.github.com/4165865 https://gist.github.com/4165865 I continue to believe that Bitcoin should avoid dealing with these issues and instead tightly circumscribe its scope, allowing other software to resolve the trust issues around payment endpoint communication. If it continues along the present path, it's going to have an integration complexity akin to one of those grain-of-sand metaphors, and wind up subsuming emacs.
- contingencies 14y ago
  See also a non settlement-system or asset-linked proposal for this problem space currently under development at http://www.ifex-project.org/our-proposals/ifex/ http://www.ifex-project.org/our-proposals/ifex/ The current, github forkable proposal is available at https://github.com/globalcitizen/ifex-protocol https://github.com/globalcitizen/ifex-protocol

by gwillen 14y ago

maaku 14y ago

IIRC (I'm on the developer mailing list, but only skimmed the relevant thread), the X.509 part has been made optional, and there is support for other trust mechanisms such as PGP.

gwillen 14y ago
Oh, that's fantastic news. Thanks for updating me. I will check out the list archives to learn more.

sneak 14y ago

https://github.com/gavinandresen/paymentrequest/issues/1 https://github.com/gavinandresen/paymentrequest/issues/1

contingencies 14y ago

Hey there. I was one of the first to raise this anti-X.509 sentiment on the list and gist. Here's my initial fork: https://gist.github.com/4165865 https://gist.github.com/4165865 I continue to believe that Bitcoin should avoid dealing with these issues and instead tightly circumscribe its scope, allowing other software to resolve the trust issues around payment endpoint communication. If it continues along the present path, it's going to have an integration complexity akin to one of those grain-of-sand metaphors, and wind up subsuming emacs.

contingencies 14y ago
See also a non settlement-system or asset-linked proposal for this problem space currently under development at http://www.ifex-project.org/our-proposals/ifex/ http://www.ifex-project.org/our-proposals/ifex/ The current, github forkable proposal is available at https://github.com/globalcitizen/ifex-protocol https://github.com/globalcitizen/ifex-protocol