From: Christopher Gilliard <christopher.gilliard@gmail•com>
To: Aymeric Vitte <vitteaymeric@gmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP proposal - Signatures of Messages using Bitcoin Private Keys
Date: Mon, 18 Feb 2019 23:24:27 -0000 [thread overview]
Message-ID: <CAK=nyAztSeEbDL=98PTdx-sdqGOug26-3vyADA-tc5oxECyZPw@mail.gmail.com> (raw)
In-Reply-To: <5c7fac0f-818b-d78d-5d5f-7a029fdd05ef@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3837 bytes --]
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 listbitcoin-dev@lists•linuxfoundation.orghttps://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
>
>
[-- Attachment #2: Type: text/html, Size: 6796 bytes --]
next prev parent reply other threads:[~2019-02-18 23:24 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-17 14:14 Christopher Gilliard
2019-02-17 19:42 ` Adam Ficsor
2019-02-18 22:59 ` Aymeric Vitte
2019-02-18 23:24 ` Christopher Gilliard [this message]
2019-02-18 23:50 ` Aymeric Vitte
2019-02-19 0:29 ` Christopher Gilliard
2019-03-06 10:37 ` [bitcoin-dev] Fwd: " Aymeric Vitte
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAK=nyAztSeEbDL=98PTdx-sdqGOug26-3vyADA-tc5oxECyZPw@mail.gmail.com' \
--to=christopher.gilliard@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=vitteaymeric@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox