{"type":"rich","version":"1.0","author_name":"npub1aeetueshkcgcx4x7uze7qteaq85d9d4c8kzrwxqmxq2rjnl5drmssu7ctd","author_url":"https://nostr.ae/npub1aeetueshkcgcx4x7uze7qteaq85d9d4c8kzrwxqmxq2rjnl5drmssu7ctd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2014-04-07\n📝 Original message:\u003e\n\u003e I'd be fine with changing the key fingerprint algorithm to something else. Do you like CRC16?\n\u003e\nI like CRC16.  Do you intend to use it in conjunction with a cryptographic hash?\n\nRegarding the choice of fields, any implementation of this BIP will\nneed big integer arithmetic to do base-58 anyway.  The operations\nrequired for SSS are nearly the same as for base-58 and can probably\nbe done by the same subset of the chosen bignum library.  So in fact\nusing GF(2^8) will add complexity to both the BIP and its\nimplementations.  However, the maths in GF(2^8) is so simple that this\nadditional complexity can be considered negligible.\n\nAs a co-author of a bitcoin application running on a real\nmicrocontroller (not the sort of big-iron thing Trezor runs on), I was\nalso going to implement my SSS over a 256-bit prime field.  (I am not\ngoing into 512-bit master seeds at this time.)\n\nUniform processing of secrets of any size (instead of using different\nprimes for different cases) is a valid argument in favour of GF(2^8),\nthough.  I have no preference one way or another."}