Talk:Wallet protocol

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)

It's a good fit for smartphones and computers, but in one stroke, makes some super cheap hardware that otherwise could implement a wallet protocol unable to, if that's of any value. The availability of a low-cost SHM (secure hardware module) for Bitcoin is something people would probably value. Not only does it up the minimum memory requirement from a few KBytes to several hundred KBytes, requiring a full TCP/IP stack also increases the attack surface for any hardware wallet device that implements it. Hopefully the gain from requiring an IP stack to do something that can be accomplished with CRC (e.g. elementary arithmetic ops like add/xor) somehow provides an offsetting benefit in exchange for making it too bloated to run on cheap smart cards or microcontrollers, the kind with 2 or 4 KBytes of flash and 128 bytes of RAM that you can source for pennies. Casascius 04:12, 19 April 2011 (GMT)

Miner security level

Why would a miner need to create new addresses? I think this creates a lot of DDoS potential --Witchspace 14:50, 24 July 2011 (GMT)

• A smart miner would need to create a new address to assign the generation to. The recommended security levels would not be mandatory, in any case. --Luke-jr 21:58, 24 July 2011 (GMT)