Talk:Wallet protocol: Difference between revisions
Jump to navigation
Jump to search
Created page with "== User interaction == As one goal of this protocol is to properly abstract the User Interface from the Wallet, there are presumed to be no conditions where a Wallet itself has a..." |
|||
| Line 4: | Line 4: | ||
== PKI to authenticate merchant == | == PKI to authenticate merchant == | ||
This doesn't seem like something we should be inventing just for Bitcoin. Surely there's some existing standard? I don't see why TLS client certs wouldn't work... --[[User:Luke-jr|Luke-jr]] 06:16, 25 March 2011 (GMT) | This doesn't seem like something we should be inventing just for Bitcoin. Surely there's some existing standard? I don't see why TLS client certs wouldn't work... --[[User:Luke-jr|Luke-jr]] 06:16, 25 March 2011 (GMT) | ||
: Possibly. It depends on what devices you can imagine supporting it. In a sense we have "already" invented PKI for Bitcoin, and done so in a space-friendly manner, such that public and private keys and digital signatures fit in one or two lines of text rather than a screen-sized blob of data, and there is no guesswork involved in validating signatures. That sort of efficiency scales well to small gadgets with miniscule memory. Parsing X.509 certificates is a challenge for tiny devices because of the huge variation in formats, this is what I mean by guesswork. If it can be kept simple, we preserve the possibility that wallets can be implemented on extremely cheap hardware like microcontrollers and keep their cost down. | |||
:For the same reason I would suggest avoiding running TCP/IP-over-serial, just because it is a disproportionately large amount of overhead for the type of device that would be using it, for negligible benefit. If communication is CR/LF-terminated lines of text, simply terminating each line with "*xx" (where xx is a simple hash of the entire line) would suffice - just so receivers can reject garbled data - this is exactly the methodology common serial GPS receivers use today and is very inexpensive to implement (google "NMEA checksum"). [[User:Casascius|Casascius]] 17:00, 26 March 2011 (GMT) | |||
Revision as of 17:00, 26 March 2011
User interaction
As one goal of this protocol is to properly abstract the User Interface from the Wallet, there are presumed to be no conditions where a Wallet itself has any direct user interaction. This is why it is left entirely to the Wallet implementation to decide if there may be circumstances that warrant leaving out the 'merchant' account. --Luke-jr 06:16, 25 March 2011 (GMT)
PKI to authenticate merchant
This doesn't seem like something we should be inventing just for Bitcoin. Surely there's some existing standard? I don't see why TLS client certs wouldn't work... --Luke-jr 06:16, 25 March 2011 (GMT)
- Possibly. It depends on what devices you can imagine supporting it. In a sense we have "already" invented PKI for Bitcoin, and done so in a space-friendly manner, such that public and private keys and digital signatures fit in one or two lines of text rather than a screen-sized blob of data, and there is no guesswork involved in validating signatures. That sort of efficiency scales well to small gadgets with miniscule memory. Parsing X.509 certificates is a challenge for tiny devices because of the huge variation in formats, this is what I mean by guesswork. If it can be kept simple, we preserve the possibility that wallets can be implemented on extremely cheap hardware like microcontrollers and keep their cost down.
- For the same reason I would suggest avoiding running TCP/IP-over-serial, just because it is a disproportionately large amount of overhead for the type of device that would be using it, for negligible benefit. If communication is CR/LF-terminated lines of text, simply terminating each line with "*xx" (where xx is a simple hash of the entire line) would suffice - just so receivers can reject garbled data - this is exactly the methodology common serial GPS receivers use today and is very inexpensive to implement (google "NMEA checksum"). Casascius 17:00, 26 March 2011 (GMT)