Re-sending to the list since it never made it
BIP or not, at least this process desserves to be documented
precisely
Sujet : | Re: [bitcoin-dev] BIP proposal - Signatures of Messages using Bitcoin Private Keys |
---|---|
Date : | Mon, 18 Feb 2019 16:29:34 -0800 |
De : | Christopher Gilliard <christopher.gilliard@gmail.com> |
Pour : | Aymeric Vitte <vitteaymeric@gmail.com> |
Copie à : | Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> |
Ah, OK, that's of course a good thing to document this undocumented (and strange) stuff, as a matter of fact I implemented it after reading your post (because this was on my todo list since some time) and got annoyed quickly, mainly by what is doing formatMessageForSigning (which is quite trivial when you know it but would be good to document precisely)
So, yes, it's a good idea to write this, regarding the header I still don't see the use, testing the different possibilities is not a big deal, why the signature format is not the same as transactions one is mysterious too
Le 19/02/2019 à 00:24, Christopher Gilliard a écrit :
The proposal includes actual code that does verification, but I didn't include code for signing. I thought it could be inferred, but I could at least include a description of how to sign. I am not sure exactly what part you are referring to by "keys speech", but the signatures are done by ECDSA keys so it's hard to not include anything about keys even though that's not the main topic. The "Background on ECDSA keys" section was mainly meant to give background about what kind of keys Bitcoin uses, for people who already know that they can easily skip this section so I would probably think it's best just to leave in. Maybe it should be at the end as an addendum though. Yes, I did not invent any of this, I'm just documenting what people actually seem to do because I had to verify signatures as part of a project I'm working on. I would have liked to have had this document when I started the project so I thought it might be useful to others since as far as I can tell this was not specified anywhere. The reason for including this data in the header is the same that compressed/uncompressed is included in the header so that you know which type of key the signature is from and you don't have to try all options to see if any matches. This is why Trezor did that way and why I documented it. I'm sure there are other ways to do this, but since this is out there in the field being used and is a reasonable solution, I thought I'd write it up.
On Mon, Feb 18, 2019 at 2:59 PM Aymeric Vitte <vitteaymeric@gmail.com> wrote:
Then, since you wrote this proposal, maybe you should add the very precise description of the signing/verification process since it is documented nowhere
I don't get the use of the speech regarding keys while it should focus on signatures which are summarized in a vague sentence inspired by your ref [2] with a not very logical link to the next paragraph stating that r,s should be 32B and the whole thing 65B with a header of 1B, you did not invent it, that's probably the rule, not sure where it is specified again and for what purpose, the header seems completely of no use especially when you extend to segwit/bech32 since you just have to check that related compressed key matches
Le 17/02/2019 à 15:14, Christopher Gilliard via bitcoin-dev a écrit :
I have written up a proposed BIP. It has to do with Signature formats when using Bitcoin Private keys. It is here: https://github.com/cgilliard/BIP/blob/master/README.md
This BIP was written up as suggested in this github issue: https://github.com/bitcoin/bitcoin/issues/10542
Note that the proposal is inline with the implementation that Trezor implemented in the above issue.
Any feedback would be appreciated. Please let me know what the steps are with regards to getting a BIP number assigned or any other process steps required.
Regards,Chris
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev-- Move your coins by yourself (browser version): https://peersm.com/wallet Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions Zcash wallets made simple: https://github.com/Ayms/zcash-wallets Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets Get the torrent dynamic blocklist: http://peersm.com/getblocklist Check the 10 M passwords list: http://peersm.com/findmyass Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org Peersm : http://www.peersm.com torrent-live: https://github.com/Ayms/torrent-live node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms-- Move your coins by yourself (browser version): https://peersm.com/wallet Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions Zcash wallets made simple: https://github.com/Ayms/zcash-wallets Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets Get the torrent dynamic blocklist: http://peersm.com/getblocklist Check the 10 M passwords list: http://peersm.com/findmyass Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org Peersm : http://www.peersm.com torrent-live: https://github.com/Ayms/torrent-live node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms