Talk:Wallet protocol: Difference between revisions
Jump to navigation
Jump to search
| Line 5: | Line 5: | ||
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. Of course one advantage with TLS is the ability to replace ciphers etc. when needed, this is admittedly more difficult for a bare bones home brewed setup. | : 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. Of course one advantage with TLS is the ability to replace ciphers etc. when needed, this is admittedly more difficult for a bare bones home brewed setup. [[User:Casascius|Casascius]] 17:00, 26 March 2011 (GMT) | ||
:: PKI by definition involves a CA. SSL/TLS already has active CAs with common trust lists. It would seem TLS using the cert client-side is a perfect fit... --[[User:Luke-jr|Luke-jr]] 20:45, 26 March 2011 (GMT) | |||
:For a similar 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) | :For a similar 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) | ||
:: Since communication is *not* simply line-based, it's not quite so simple... This seems like something else that should be able to recycle an existing standard-- in this case, TCP seems to be a good fit. It already has the ability to retransmit missing/corrupt packets, after all. Or perhaps PPP, since that'd be even more trivial to implement on most system. --[[User:Luke-jr|Luke-jr]] 20:45, 26 March 2011 (GMT) | |||
Revision as of 20:45, 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. Of course one advantage with TLS is the ability to replace ciphers etc. when needed, this is admittedly more difficult for a bare bones home brewed setup. Casascius 17:00, 26 March 2011 (GMT)
- PKI by definition involves a CA. SSL/TLS already has active CAs with common trust lists. It would seem TLS using the cert client-side is a perfect fit... --Luke-jr 20:45, 26 March 2011 (GMT)
- For a similar 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)
- Since communication is *not* simply line-based, it's not quite so simple... This seems like something else that should be able to recycle an existing standard-- in this case, TCP seems to be a good fit. It already has the ability to retransmit missing/corrupt packets, after all. Or perhaps PPP, since that'd be even more trivial to implement on most system. --Luke-jr 20:45, 26 March 2011 (GMT)