[Bitcoin-development] Proposal: No-Collision mode for Multisig BIP32 Wallets
This topic has been touched on briefly here before, but I wanted to solidify it and propose it as a BIP if there is wider support for it. Also, the topic is difficult to discuss without lots of pictures -- so that's what I've done (mainly to describe it to my team, but also as general documentation). It's in presentation form: https://s3.amazonaws.com/bitcoinarmory-media/MultisigWalletNoCollide.pdf The proposal is that for an M-of-N multisig wallet based on BIP32, there should be N internal chains and N external chains. Each party is assigned a chain based on the lexicographic ordering of their wallet's root public key in the multisig. This guarantees that no parties are generating and distributing the same addresses, and also provides a certain level of built-in book-keeping. Coins being received on chain 2*x were created by participant x (receiving), and coins received on 2*x+1 are change outputs created by participant x (outgoing). Thus, it's easy from simply looking at the wallet structure who was responsible for which transactions. Alternatively, we could change it to suggest that each device is assigned a pair of chains. For a 2-of-3 there may 3 participants plus a CFO with a watch-only version of the multisig wallet. Then you might use four pairs of chains. I'm just not sure how they would be assigned. If this has been proposed before, then consider this my contribution to documentation. -Alan P.S. -- No-Collision Mode is not a great name. Happy to take suggestions for changing it. -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: No-Collision mode for Multisig BIP32 Wallets
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09/23/2014 04:16 PM, Alan Reiner wrote: P.S. -- No-Collision Mode is not a great name. Happy to take suggestions for changing it. I'd call it a voting pool wallet, since that was the original application for this arrangement. Would be nice if you'd at least mention our work, since we did share it with you back in January and have been publicly documenting it ever since. Or does the fact that we're implementing it in btcwallet mean what we're working on is unmentionable here? - -- Justus Ranvier | Monetas http://monetas.net/ mailto:jus...@monetas.net | Public key ID : C3F7BB2638450DB5 | BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc -BEGIN PGP SIGNATURE- iQEcBAEBCAAGBQJUIaHAAAoJEMP3uyY4RQ21nwoH/3MYi9JibblZYmSOvCT1vJrN Ih+Q2WNumIAI+Y9bh4bBgLuhnG5lXyHedhYEUW+mfuwGiX+92Uc47nwaWED2/Lte 4Zk/KZnwLifdWCgKLdGpW6mzksRiOaVyU4vV5JchVOrGZZ2zYNIq+NcChtCph7Y5 L202ReAG+1dfSpp4rFckuv7pTVjNcrq89UN1tJFDNQdxzIRd7bwoeCuvyFurZagB 88bNiOl0BI3e090WC+CWmbC6BfqJiicn/d0gp/agW01wy7CVbLypPPTKmYqt3+54 msLUgaRHcbjuyKqu8HMHpYtgYVSNFg2q+U4SgmEepzPAkQ97khbduqA6i1B0ULM= =t/xp -END PGP SIGNATURE- 0x38450DB5.asc Description: application/pgp-keys -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: No-Collision mode for Multisig BIP32 Wallets
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/23/2014 12:37 PM, Justus Ranvier wrote: Would be nice if you'd at least mention our work, since we did share it with you back in January and have been publicly documenting it ever since. Or does the fact that we're implementing it in btcwallet mean what we're working on is unmentionable here? Please don't assume poor intentions or sneaky motives. I get a lot of emails from a lot of people about a lot of things. Nine months ago was an eternity in this world, and it can't be ruled out that I simply forgot. I have no problem giving credit where it is due, and I mentioned in my first email that I wasn't sure if my stuff was original. Please recap/link it here so that it can be part of this discussion. - -Alan -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJUIaRiAAoJEBHe6b77WWmFcBgP/2IiQWda5diBIrd8MjbtYz/X pF+B1zOipClil151pKN5h9f4CI75qwSBSG6pUS+QH1lCz97nr5AoVYV5SAaRzv0z L9Bz0PiHJFHd4IRbfuFqlPZB8mw2TMD7QWJx/1U+WmpnYYOGsUeJn25psIVZSRTU FTCsmYrA4cGZ4bZoUKI/eiXrHao8rm/zQ7QHKOMSFWZT57sNea67vlxPXKu+AkmK nEYa4hD0kD7/R/TrNcmRmOlmbqCnyjICd/yp8Lj26CdHPv3PAvaxUwSX3VhWPbdc UOiGeo+lXqRnBVpwMd+k7oFddwrc2k9ISRdUVsU86z3JdAXKl/dLS5UoOtfC1JA9 m90TuRtq4QuuzjLF3brI9FthuHNowA//qaVfjo/AYgsKy15td9UBtFbt4E9w263M NiFEmFkXfbE1JmIvmPG3AQEEdQ1/nmWiN5UcLrBfauEHMDQ1fGd89A8IBpus7bWM kYXboW3E9RBN4lB6OdyYU4AuH0YQhZodmry4iElMPox/tclmNiaeqDR8UYhD5BMd eQN9zAALyR1IY1167Ki/abVfWVf5jF7b0Eeu/wAfwcble3sCFrvWWAwzHjNi3GjY gNfy1eDTbwLj2M63QbtB+YqzQBZx3+SY4euGKYQ1s1CVV9ibAFI52oxeMhwzVOWF ofeDK5BPL8H+5L3tk+1o =tX2n -END PGP SIGNATURE- -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: No-Collision mode for Multisig BIP32 Wallets
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09/23/2014 04:48 PM, Alan Reiner wrote: Please recap/link it here so that it can be part of this discussion. http://sourceforge.net/p/bitcoin/mailman/message/32736455/ http://opentransactions.org/wiki/index.php/Deposit_Address_(voting_pools) Currently being implemented here: https://github.com/monetas/btcwallet/commits/vp - -- Really what's so annoying is how the BIP numbering process is handled in such a way that proposals can be silently pigeonholed. Especially so in the case of an *informational* BIP which requires no action on anyone's part (except for not using the same BIP43 purpose code). We resolved this by changing the naming scheme for our proposals, and their associated purpose codes, to not rely on centrally-allocated numbers. https://github.com/Open-Transactions/rfc/tree/master/bips - -- Justus Ranvier | Monetas http://monetas.net/ mailto:jus...@monetas.net | Public key ID : C3F7BB2638450DB5 | BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc -BEGIN PGP SIGNATURE- iQEcBAEBCAAGBQJUIajuAAoJEMP3uyY4RQ215dQH/1GNOmZd19/e2Ys7MNFx0gqz rDmTFBylU3lhJrMY4CDd4Duq5+2U7HgaovqgX8UqxquHWLQUwEzZLqdEPCifLg0c d/u90cRlClFAaOxPh4HV2/3aZoS2R27N+ZjOfziW7RZySBP/2fMt4/ra+SPbkcAQ oeplYgqMRDqW52C/o2zm4y4yb0TJPS+lzSNM+JfxHSPRyY55l0KzLJfUNz1RSOze A8UAwdsLiJROKPKiSrQcqFOejPV7uqSPh10ukm/AI0k8TbvX8ffGQ083394M9IuE DB/1eyeLQVP5+lQMWNrTHk3BQ75XBEDJoSukaRENcqxtHV2m1JzTWoS2CQBXi2M= =TwI3 -END PGP SIGNATURE- 0x38450DB5.asc Description: application/pgp-keys -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin-development Digest, Vol 40, Issue 9
Have you looked at how Coinvault does it? They have a similar setup, but sort the pubkeys at each address. On Tue, Sep 23, 2014 at 1:09 PM, bitcoin-development-requ...@lists.sourceforge.net wrote: Send Bitcoin-development mailing list submissions to bitcoin-development@lists.sourceforge.net To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/bitcoin-development or, via email, send a message with subject or body 'help' to bitcoin-development-requ...@lists.sourceforge.net You can reach the person managing the list at bitcoin-development-ow...@lists.sourceforge.net When replying, please edit your Subject line so it is more specific than Re: Contents of Bitcoin-development digest... Today's Topics: 1. Re: Proposal: No-Collision mode for Multisig BIP32 Wallets (Justus Ranvier) 2. Re: Proposal: No-Collision mode for Multisig BIP32 Wallets (Alan Reiner) 3. Re: Proposal: No-Collision mode for Multisig BIP32 Wallets (Justus Ranvier) -- Message: 1 Date: Tue, 23 Sep 2014 16:37:20 + From: Justus Ranvier jus...@monetas.net Subject: Re: [Bitcoin-development] Proposal: No-Collision mode for Multisig BIP32 Wallets To: bitcoin-development@lists.sourceforge.net Message-ID: 5421a1c0.6080...@monetas.net Content-Type: text/plain; charset=utf-8 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09/23/2014 04:16 PM, Alan Reiner wrote: P.S. -- No-Collision Mode is not a great name. Happy to take suggestions for changing it. I'd call it a voting pool wallet, since that was the original application for this arrangement. Would be nice if you'd at least mention our work, since we did share it with you back in January and have been publicly documenting it ever since. Or does the fact that we're implementing it in btcwallet mean what we're working on is unmentionable here? - -- Justus Ranvier | Monetas http://monetas.net/ mailto:jus...@monetas.net | Public key ID : C3F7BB2638450DB5 | BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc -BEGIN PGP SIGNATURE- iQEcBAEBCAAGBQJUIaHAAAoJEMP3uyY4RQ21nwoH/3MYi9JibblZYmSOvCT1vJrN Ih+Q2WNumIAI+Y9bh4bBgLuhnG5lXyHedhYEUW+mfuwGiX+92Uc47nwaWED2/Lte 4Zk/KZnwLifdWCgKLdGpW6mzksRiOaVyU4vV5JchVOrGZZ2zYNIq+NcChtCph7Y5 L202ReAG+1dfSpp4rFckuv7pTVjNcrq89UN1tJFDNQdxzIRd7bwoeCuvyFurZagB 88bNiOl0BI3e090WC+CWmbC6BfqJiicn/d0gp/agW01wy7CVbLypPPTKmYqt3+54 msLUgaRHcbjuyKqu8HMHpYtgYVSNFg2q+U4SgmEepzPAkQ97khbduqA6i1B0ULM= =t/xp -END PGP SIGNATURE- -- next part -- A non-text attachment was scrubbed... Name: 0x38450DB5.asc Type: application/pgp-keys Size: 14046 bytes Desc: not available -- Message: 2 Date: Tue, 23 Sep 2014 12:48:34 -0400 From: Alan Reiner etothe...@gmail.com Subject: Re: [Bitcoin-development] Proposal: No-Collision mode for Multisig BIP32 Wallets To: bitcoin-development@lists.sourceforge.net Message-ID: 5421a462.6030...@gmail.com Content-Type: text/plain; charset=ISO-8859-1 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/23/2014 12:37 PM, Justus Ranvier wrote: Would be nice if you'd at least mention our work, since we did share it with you back in January and have been publicly documenting it ever since. Or does the fact that we're implementing it in btcwallet mean what we're working on is unmentionable here? Please don't assume poor intentions or sneaky motives. I get a lot of emails from a lot of people about a lot of things. Nine months ago was an eternity in this world, and it can't be ruled out that I simply forgot. I have no problem giving credit where it is due, and I mentioned in my first email that I wasn't sure if my stuff was original. Please recap/link it here so that it can be part of this discussion. - -Alan -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJUIaRiAAoJEBHe6b77WWmFcBgP/2IiQWda5diBIrd8MjbtYz/X pF+B1zOipClil151pKN5h9f4CI75qwSBSG6pUS+QH1lCz97nr5AoVYV5SAaRzv0z L9Bz0PiHJFHd4IRbfuFqlPZB8mw2TMD7QWJx/1U+WmpnYYOGsUeJn25psIVZSRTU FTCsmYrA4cGZ4bZoUKI/eiXrHao8rm/zQ7QHKOMSFWZT57sNea67vlxPXKu+AkmK nEYa4hD0kD7/R/TrNcmRmOlmbqCnyjICd/yp8Lj26CdHPv3PAvaxUwSX3VhWPbdc UOiGeo+lXqRnBVpwMd+k7oFddwrc2k9ISRdUVsU86z3JdAXKl/dLS5UoOtfC1JA9 m90TuRtq4QuuzjLF3brI9FthuHNowA//qaVfjo/AYgsKy15td9UBtFbt4E9w263M NiFEmFkXfbE1JmIvmPG3AQEEdQ1/nmWiN5UcLrBfauEHMDQ1fGd89A8IBpus7bWM kYXboW3E9RBN4lB6OdyYU4AuH0YQhZodmry4iElMPox/tclmNiaeqDR8UYhD5BMd eQN9zAALyR1IY1167Ki/abVfWVf5jF7b0Eeu/wAfwcble3sCFrvWWAwzHjNi3GjY gNfy1eDTbwLj2M63QbtB+YqzQBZx3+SY4euGKYQ1s1CVV9ibAFI52oxeMhwzVOWF ofeDK5BPL8H+5L3tk+1o =tX2n -END PGP SIGNATURE- -- Message: 3 Date: Tue, 23 Sep 2014 17:07:58 + From: Justus Ranvier jus...@monetas.net
Re: [Bitcoin-development] Bitcoin-development Digest, Vol 40, Issue 9
Yes, we sort the keys at each address as well. But this isn't about key sorting, it's about assigning each device a different branch of the BIP 32 tree to avoid accidental address re use and to make it self evident which devices were used for each transaction in the overall wallet history. I only suggested sorting the root public keys as a way to assign which internal/external pair of chains the device should use. @Justus... Looking at the links you sent I'm not clear how it is related. And naming it key voting pools seems unrelated to why we are proposing this scheme. I'll need more than naked links to understand (I'm not saying it isn't related, I'm just not seeing the connection) -Alan Sent from my overpriced smartphone On Sep 23, 2014 2:25 PM, Vitalik Buterin v...@buterin.com wrote: Have you looked at how Coinvault does it? They have a similar setup, but sort the pubkeys at each address. On Tue, Sep 23, 2014 at 1:09 PM, bitcoin-development-requ...@lists.sourceforge.net wrote: Send Bitcoin-development mailing list submissions to bitcoin-development@lists.sourceforge.net To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/bitcoin-development or, via email, send a message with subject or body 'help' to bitcoin-development-requ...@lists.sourceforge.net You can reach the person managing the list at bitcoin-development-ow...@lists.sourceforge.net When replying, please edit your Subject line so it is more specific than Re: Contents of Bitcoin-development digest... Today's Topics: 1. Re: Proposal: No-Collision mode for Multisig BIP32 Wallets (Justus Ranvier) 2. Re: Proposal: No-Collision mode for Multisig BIP32 Wallets (Alan Reiner) 3. Re: Proposal: No-Collision mode for Multisig BIP32 Wallets (Justus Ranvier) -- Message: 1 Date: Tue, 23 Sep 2014 16:37:20 + From: Justus Ranvier jus...@monetas.net Subject: Re: [Bitcoin-development] Proposal: No-Collision mode for Multisig BIP32 Wallets To: bitcoin-development@lists.sourceforge.net Message-ID: 5421a1c0.6080...@monetas.net Content-Type: text/plain; charset=utf-8 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09/23/2014 04:16 PM, Alan Reiner wrote: P.S. -- No-Collision Mode is not a great name. Happy to take suggestions for changing it. I'd call it a voting pool wallet, since that was the original application for this arrangement. Would be nice if you'd at least mention our work, since we did share it with you back in January and have been publicly documenting it ever since. Or does the fact that we're implementing it in btcwallet mean what we're working on is unmentionable here? - -- Justus Ranvier | Monetas http://monetas.net/ mailto:jus...@monetas.net | Public key ID : C3F7BB2638450DB5 | BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc -BEGIN PGP SIGNATURE- iQEcBAEBCAAGBQJUIaHAAAoJEMP3uyY4RQ21nwoH/3MYi9JibblZYmSOvCT1vJrN Ih+Q2WNumIAI+Y9bh4bBgLuhnG5lXyHedhYEUW+mfuwGiX+92Uc47nwaWED2/Lte 4Zk/KZnwLifdWCgKLdGpW6mzksRiOaVyU4vV5JchVOrGZZ2zYNIq+NcChtCph7Y5 L202ReAG+1dfSpp4rFckuv7pTVjNcrq89UN1tJFDNQdxzIRd7bwoeCuvyFurZagB 88bNiOl0BI3e090WC+CWmbC6BfqJiicn/d0gp/agW01wy7CVbLypPPTKmYqt3+54 msLUgaRHcbjuyKqu8HMHpYtgYVSNFg2q+U4SgmEepzPAkQ97khbduqA6i1B0ULM= =t/xp -END PGP SIGNATURE- -- next part -- A non-text attachment was scrubbed... Name: 0x38450DB5.asc Type: application/pgp-keys Size: 14046 bytes Desc: not available -- Message: 2 Date: Tue, 23 Sep 2014 12:48:34 -0400 From: Alan Reiner etothe...@gmail.com Subject: Re: [Bitcoin-development] Proposal: No-Collision mode for Multisig BIP32 Wallets To: bitcoin-development@lists.sourceforge.net Message-ID: 5421a462.6030...@gmail.com Content-Type: text/plain; charset=ISO-8859-1 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/23/2014 12:37 PM, Justus Ranvier wrote: Would be nice if you'd at least mention our work, since we did share it with you back in January and have been publicly documenting it ever since. Or does the fact that we're implementing it in btcwallet mean what we're working on is unmentionable here? Please don't assume poor intentions or sneaky motives. I get a lot of emails from a lot of people about a lot of things. Nine months ago was an eternity in this world, and it can't be ruled out that I simply forgot. I have no problem giving credit where it is due, and I mentioned in my first email that I wasn't sure if my stuff was original. Please recap/link it here so that it can be part of this discussion. - -Alan -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJUIaRiAAoJEBHe6b77WWmFcBgP/2IiQWda5diBIrd8MjbtYz/X
Re: [Bitcoin-development] Bitcoin-development Digest, Vol 40, Issue 9
Okay I see, that makes sense. -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] cryptographic review requested
Hello, I've made a proposal for a standardized ecies scheme for bitcoin communication. To address gmaxwell's criticism, I'd like to also follow up with a proposed change to BIP44, such that a structured wallet would also include a series of identity keys, both addresses which will be used for signing, and public keys which would be used as destinations for encrypted messages. If anyone is familiar with ECIES and would be interested, there is a working implementation at http://memwallet.info/btcmssgs.html, which also includes this whitepaper: Abstract This document describes a scheme for sending signed encrypted messages using bitcoin public and private keys. Motivation PGP and Bitmessage and other secure communications channels exist. This standard allows for secure messaging using a bitcoin wallet alone, without the need for other software. This standard allows the owner of an address to conveniently prove ownership to the holder of another address privately without the need for separate secure communications channels. Specification: Message Format In the rest of this text we will assume the public key cryptography used in Bitcoin. The || operator is concatenation. All operations are defined over binary, and not text conversion of the data. When serializing public keys the compressed encoding is always used, even if the input parameters are passed as uncompressed. Bitcoin addresses are always serialized from compressed public keys, and for mainnet. (directives to use testnet or uncompressed keys ignored) String literals are represented as if for the C programming language in native UTF-8. No assumptions are made about the payload message format, it may even be binary. Caveat Decryptor. Plain unformatted text message payloads are recommended to use utf-8. - CompactSize format is a variable size little endian length field serialization format, know as a bitcoin Variable length integer - CompactSizePrefix(X) = CompactSize(X) || X - QTHASH(x) = SHA256((SHA256( CompactSizePrefix(Bitcoin Signed Message:\n) || CompactSizePrefix(x) ) This standard assumes the reader is familiar with the bitcoin compact signature format, which is a 65 byte signature which allows the verifier to recover the public key associated with the signature, eliminating the need to send it with the message. Once consequence of this format is that signatures of tampered messages will nearly always result in some public key, but it will not be the same as the orignial signing key. The address of the sender will be provided to enable validation of the signature. The format is a 1 byte recid, followed by ECDSA R then S values. - CompactSign( PrivateKey, 32 byte QT Hash ) == 65 byte message - CompactVerify( 65 byte message, 32 bytes Hash ) public key counterpart of (PrivateKey) - ECIES with HMAC_SHA256 for mac, PBKDF2 for KDF - PBKDF2 is used with 2048 iterations, salt=( Bitcoin Secure Message || ecies_nonce_publickey ) - AES is used with 256 bit keys, and CFB mode, with a 128 bit feedback buffer. No padding or envelope, simply a pure byte cipher - compact_signed_message = 0x01 || CompactSizePrefix(M) || Sender_Address || Signature - compact_unsigned_message = 0x00 || CompactSizePrefix(M) - Secure message format: ECIES( compact_signed_message or compact_unsigned_message ) Summary of the functions defined: - eM = SendMessage( M, Signing_Key, Dest_Pub ) - M,Sender_Address = ReceiveMessage( eM, Decrypting_Key ) It is acceptable for deterministic nonces to be used for signatures, however nonces generated for ECIES must be high quality random bytes. (excepting unit test vectors) Message Sending Inputs: - The message to send M (treat as precise binary bytes, no space stripping or normalization) - The bitcoin private key Signing_Key to be used to sign the message - The bitcoin public key Dest_Pub to be used as the destination of the message Algorithm Calculations: - Calculate the QTHASH(M) to obtain M_hash, 32 bytes of data - if signing Sign with CompactSign(Signing_Key,M_hash) to obtain Signature, 65 bytes of data ** Calculate the compressed address of Signing_Key to obtain Sender_Address 21 bytes of data ** Serialize 0x01 || CompactSizePrefix(M) || Sender_Address || Signature to obtain Signed_Message - if not signing, instead Serialize 0x00 || CompactSizePrefix(M) to obtain Unsigned_Message - Generate 32 random bytes ecies_nonce_bytes - Generate a bitcoin private key from ecies_nonce_bytes, Nonce_Key 32 bytes of data (retry if invalid) - Derive the compressed public key of Nonce_Key, Nonce_Pub, 33 bytes of data - ECMultiply Dest_Pub by Nonce_Key to obtain the point Shared_Secret_Point - Serialize Shared_Secret_Point as a compressed point Shared_Secret - Derive KeyingBytes = PBKDF2( Shared_Secret ) to get 80 bytes of data - Directly Derive AES256_Key from the first 32 bytes of KeyingBytes (index 0 to 32)
