On 04/03/2012 02:46 PM, Gavin Andresen wrote: > RE: signature blocks and BIP 10: > > We should avoid reinventing the wheel, if we can. I think we should > extend existing standards whenever possible. > > So: could we encode signature blocks or BIP-10 transactions using > S/MIME ? Or is there a more appropriate "sign a message" standard we > could/should use? > > You're glossing over little details like what character encoding is > used for the message, but I'd rather leverage all the work already > done by the IETF to nail down all those little details rather then > re-discover them and come up with our own solutions. > I'm glossing over details because I actually have no experience dealing with character encodings, or the implementation specifics of existing solutions (PGP or S/MIME). That's why I'm emailing this list: I want to figure this stuff out, and at the same time try to converge on something that is efficient and can be interoperable between Armory and the Satoshi client (wallets, signature collection, sig blocks).
I don't go into these things solely to reinvent stuff. My primary motivation for both ideas I have pitched so far (BIP 0010 and the sig blocks) is the versatility. I like the encoding-independent, visual compactness of PGP ASCII-armored text blocks, but I don't like their opaqueness. PGP vs my signature blocks basically look the same to a casual user, but even a moderately-knowledgeable user can appreciate the human-readable components of it. You can visually identify if signatures are missing from sig-collection packet, or see that you signed with the wrong address without having to load an external program. But that isn't a critical requirement, it's just my personal preference. I'm fine with existing systems if it sidesteps a lot of problems and there's easy interface to it. But, I don't want to have another BSDDB-wallet situation where we end up with 10x more capability than we need, and pay for it with 10x the complexity (at least in this case, using PGP is an existing crypto/security-sensitive technology). I have made "simplicity" one of my goals in Armory. Alternatively, we could change the discussion to a requirements discussion, to first figure out what we need in order to address multi-signature collection, etc. Then evaluate competing ideas based on their qualities relative to the requirements. ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
