📅 Original date posted:2019-02-18
📝 Original message:Trying the four possible options (p2pkh compressed, p2pkh uncompressed,
seg3, and bech32) is certainly a possibility and in fact, that's what I
ended up doing because not every wallet implements something like this, but
if there is a header field currently in use, it seemed reasonable to me to
use it specify which type of key is being used. If the header includes
whether the key is compressed or not compressed it seems logical to include
all data about what type of key it is and not just this one type of
information. That's why I thought the solution made sense and I wrote it up.
On Mon, Feb 18, 2019 at 3:50 PM Aymeric Vitte <vitteaymeric at gmail.com>
wrote:
> 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 at 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 at 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
>>
>> --
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190218/f2be0366/attachment-0001.html>;
Christopher Gilliard [ARCHIVE] /
npub1qm…0hwnt
2023-06-07 18:16:31
in reply to nevent1q…gqnn
Author Public Key
npub1qmsejphez6np2my9fu40kj9en68d5fa3s7ap4ul7eh9aeuljusgs50hwntPublished at
2023-06-07 18:16:31Event JSON
{
"id": "d8ac9208bff4b070259a922b5679729080dabaca2478a6d2762b1089283eb2d5",
"pubkey": "06e19906f916a6156c854f2afb48b99e8eda27b187ba1af3fecdcbdcf3f2e411",
"created_at": 1686161791,
"kind": 1,
"tags": [
[
"e",
"90a0c763220b1b7816fac44840b029ebb7addf90dbc79e7c5fd8420c02e92ed9",
"",
"root"
],
[
"e",
"aaa2ddedb48bef701fa8ebb1bc5ea672ef001b833dcf18ec5254a81be807fd34",
"",
"reply"
],
[
"p",
"a2711d6616d348a3542bb2a791a9e51fcbc7b7d1d20652e5abe16d3e179321df"
]
],
"content": "📅 Original date posted:2019-02-18\n📝 Original message:Trying the four possible options (p2pkh compressed, p2pkh uncompressed,\nseg3, and bech32) is certainly a possibility and in fact, that's what I\nended up doing because not every wallet implements something like this, but\nif there is a header field currently in use, it seemed reasonable to me to\nuse it specify which type of key is being used. If the header includes\nwhether the key is compressed or not compressed it seems logical to include\nall data about what type of key it is and not just this one type of\ninformation. That's why I thought the solution made sense and I wrote it up.\n\nOn Mon, Feb 18, 2019 at 3:50 PM Aymeric Vitte \u003cvitteaymeric at gmail.com\u003e\nwrote:\n\n\u003e Ah, OK, that's of course a good thing to document this undocumented (and\n\u003e strange) stuff, as a matter of fact I implemented it after reading your\n\u003e post (because this was on my todo list since some time) and got annoyed\n\u003e quickly, mainly by what is doing formatMessageForSigning (which is quite\n\u003e trivial when you know it but would be good to document precisely)\n\u003e\n\u003e So, yes, it's a good idea to write this, regarding the header I still\n\u003e don't see the use, testing the different possibilities is not a big deal,\n\u003e why the signature format is not the same as transactions one is mysterious\n\u003e too\n\u003e Le 19/02/2019 à 00:24, Christopher Gilliard a écrit :\n\u003e\n\u003e The proposal includes actual code that does verification, but I didn't\n\u003e include code for signing. I thought it could be inferred, but I could at\n\u003e least include a description of how to sign. I am not sure exactly what part\n\u003e you are referring to by \"keys speech\", but the signatures are done by ECDSA\n\u003e keys so it's hard to not include anything about keys even though that's not\n\u003e the main topic. The \"Background on ECDSA keys\" section was mainly meant to\n\u003e give background about what kind of keys Bitcoin uses, for people who\n\u003e already know that they can easily skip this section so I would probably\n\u003e think it's best just to leave in. Maybe it should be at the end as an\n\u003e addendum though. Yes, I did not invent any of this, I'm just documenting\n\u003e what people actually seem to do because I had to verify signatures as part\n\u003e of a project I'm working on. I would have liked to have had this document\n\u003e when I started the project so I thought it might be useful to others since\n\u003e as far as I can tell this was not specified anywhere. The reason for\n\u003e including this data in the header is the same that compressed/uncompressed\n\u003e is included in the header so that you know which type of key the signature\n\u003e is from and you don't have to try all options to see if any matches. This\n\u003e is why Trezor did that way and why I documented it. I'm sure there are\n\u003e other ways to do this, but since this is out there in the field being used\n\u003e and is a reasonable solution, I thought I'd write it up.\n\u003e\n\u003e On Mon, Feb 18, 2019 at 2:59 PM Aymeric Vitte \u003cvitteaymeric at gmail.com\u003e\n\u003e wrote:\n\u003e\n\u003e\u003e Then, since you wrote this proposal, maybe you should add the very\n\u003e\u003e precise description of the signing/verification process since it is\n\u003e\u003e documented nowhere\n\u003e\u003e\n\u003e\u003e I don't get the use of the speech regarding keys while it should focus on\n\u003e\u003e signatures which are summarized in a vague sentence inspired by your ref\n\u003e\u003e [2] with a not very logical link to the next paragraph stating that r,s\n\u003e\u003e should be 32B and the whole thing 65B with a header of 1B, you did not\n\u003e\u003e invent it, that's probably the rule, not sure where it is specified again\n\u003e\u003e and for what purpose, the header seems completely of no use especially when\n\u003e\u003e you extend to segwit/bech32 since you just have to check that related\n\u003e\u003e compressed key matches\n\u003e\u003e Le 17/02/2019 à 15:14, Christopher Gilliard via bitcoin-dev a écrit :\n\u003e\u003e\n\u003e\u003e I have written up a proposed BIP. It has to do with Signature formats\n\u003e\u003e when using Bitcoin Private keys. It is here:\n\u003e\u003e https://github.com/cgilliard/BIP/blob/master/README.md\n\u003e\u003e\n\u003e\u003e This BIP was written up as suggested in this github issue:\n\u003e\u003e https://github.com/bitcoin/bitcoin/issues/10542\n\u003e\u003e\n\u003e\u003e Note that the proposal is inline with the implementation that Trezor\n\u003e\u003e implemented in the above issue.\n\u003e\u003e\n\u003e\u003e Any feedback would be appreciated. Please let me know what the steps are\n\u003e\u003e with regards to getting a BIP number assigned or any other process steps\n\u003e\u003e required.\n\u003e\u003e\n\u003e\u003e Regards,\n\u003e\u003e Chris\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing listbitcoin-dev at lists.linuxfoundation.orghttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\u003e\u003e --\n\u003e\u003e Move your coins by yourself (browser version): https://peersm.com/wallet\n\u003e\u003e Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions\n\u003e\u003e Zcash wallets made simple: https://github.com/Ayms/zcash-wallets\n\u003e\u003e Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets\n\u003e\u003e Get the torrent dynamic blocklist: http://peersm.com/getblocklist\n\u003e\u003e Check the 10 M passwords list: http://peersm.com/findmyass\n\u003e\u003e Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org\n\u003e\u003e Peersm : http://www.peersm.com\n\u003e\u003e torrent-live: https://github.com/Ayms/torrent-live\n\u003e\u003e node-Tor : https://www.github.com/Ayms/node-Tor\n\u003e\u003e GitHub : https://www.github.com/Ayms\n\u003e\u003e\n\u003e\u003e --\n\u003e Move your coins by yourself (browser version): https://peersm.com/wallet\n\u003e Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions\n\u003e Zcash wallets made simple: https://github.com/Ayms/zcash-wallets\n\u003e Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets\n\u003e Get the torrent dynamic blocklist: http://peersm.com/getblocklist\n\u003e Check the 10 M passwords list: http://peersm.com/findmyass\n\u003e Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org\n\u003e Peersm : http://www.peersm.com\n\u003e torrent-live: https://github.com/Ayms/torrent-live\n\u003e node-Tor : https://www.github.com/Ayms/node-Tor\n\u003e GitHub : https://www.github.com/Ayms\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190218/f2be0366/attachment-0001.html\u003e",
"sig": "bc326911be539913902d2458ded7d3bf7b3f4049a59cd0eca33aadab55e1d831a5612efb70ad4fca18001d32d8eba5614e20d1747e66cd52bda6e31aec20a02a"
}