Protocol version numbers, minimum maker count and compressed keys

[chris-belcher]

The protocol needs a way to announce version numbers, in case we ever update it that the bots can know their incompatibility. Best way is probably to say !ver [version] in IRC as the first command, and the other bots wont respond unless your bot has first said !ver. !ver 1!orderbook !ver 1!relorder [data]

Maker's orders should have an option for requiring a certain number of other makers. For instance patientsendpayment.py will announce an order that can only be filled if two other makers are also taking part. Yield-generator.py would of course be happy with any number of makers.

Compressed public keys should be used. Reduces size, lower miner fees required, bitcoind uses them by default. Only issue is if a coinjoin takes place with both compressed and uncompressed pubkeys it is obvious which output belongs to whom, so this is a hard protocol break.

[AdamISZ]

With regard to compressed pubkeys:

The pybitcointools bip32 libraries only use compressed pubkeys (in line with BIP 32 itself). I double checked by looking at the code (the privkeys are 33 bytes which is read as 'hex_compressed' or 'bin_compressed' by get_privkey_format(), and so encode_pubkey() produces a compressed pubkey output).

Maybe I totally missed the point, but isn't joinmarket only using the bip32 keys from pybitcointools?

[AdamISZ]

With regard to protocol version, I had a think about it but didn't form a clear opinion. I think a !ver at start up is perfectly good for now, if we encounter some problem with that we could update it later.

[chris-belcher]

Yep you are correct about joinmarket already using compressed keys.

[chris-belcher]

Probably the best way to do this is for makers to announce !version along with their offers, and takers will send their version number along with their !fill command