nostril icon indicating copy to clipboard operation
nostril copied to clipboard

Why is mining a pubkey maybe cryptographically dubious?

Open gwillen opened this issue 1 year ago • 10 comments

I had trouble finding where the note to this effect was originally added to the documentation. I was hoping for some kind of explanation of just how dubious.

gwillen avatar Sep 13 '23 22:09 gwillen

On Wed, Sep 13, 2023 at 03:29:19PM -0700, Glenn Willen wrote:

I had trouble finding where the note to this effect was originally added to the documentation. I was hoping for some kind of explanation of just how dubious.

I'm not sure if it is or not. It is just a statement of ignorance.

jb55 avatar Sep 15 '23 17:09 jb55

Well, I was specifically wondering what would make it more dubious than just regular key generation. After reading the source, I'm assuming it's about the fast trick for generating the next candidate, at the bottom of the loop?

gwillen avatar Sep 15 '23 20:09 gwillen

On Fri, Sep 15, 2023 at 01:08:52PM -0700, Glenn Willen wrote:

Well, I was specifically wondering what would make it more dubious than just regular key generation. After reading the source, I'm assuming it's about the fast trick for generating the next candidate, at the bottom of the loop?

I think I was wondering if grinding a pubkey with a certain number of leading zeros would reduce the uniformity of the keyspace or something, and if that opened it up to some kind of attacks. I didn't think it would be an issue but I'm not sure becase I'm not cryptographer.

The xor thing seemed fine? I hope? =/

jb55 avatar Sep 16 '23 20:09 jb55

I am also not a cryptographer but I have worked with a few. I'm pretty sure grinding itself is fine, I'm pretty sure I had cryptographically-knowledgeable ex-coworkers who used bitcoin vanity addresses (which are ground like this.)

The xor thing is kind of sus to me, in the way of "I'm pretty sure it's fine; I couldn't come up with anything wrong with it in 5 minutes of thinking, which was enough for me to use it; but I would run it by a cryptographer to be sure."

I can try to get one of of my Blockstream ex-coworkers to look at it if you like.

gwillen avatar Sep 16 '23 21:09 gwillen

On Sat, Sep 16, 2023 at 02:39:12PM -0700, Glenn Willen wrote:

I am also not a cryptographer but I have worked with a few. I'm pretty sure grinding itself is fine, I'm pretty sure I had cryptographically-knowledgeable ex-coworkers who used bitcoin vanity addresses (which are ground like this.)

The xor thing is kind of sus to me, in the way of "I'm pretty sure it's fine; I couldn't come up with anything wrong with it in 5 minutes of thinking, which was enough for me to use it; but I would run it by a cryptographer to be sure."

I can try to get one of of my Blockstream ex-coworkers to look at it if you like.

sure! thanks!

jb55 avatar Sep 16 '23 21:09 jb55

There is no problem grinding a secret key to get some property of the public key, as long as the only thing you're filtering for is a pubkey property. (If this were a problem, then an attacker could e.g. scan the Bitcoin blockchain for public keys that naturally had a lot of 0s, and then apply whatever attack your grinding supposedly enabled, and normal non-grinding public key cryptography would be vulnerable. At least in a world where there were lots of public keys. But it is not, so you are fine.)

But this xor thing does seem super weird, and this tactic of repeatedly generating fresh independent keys is extremely slow. You should be able to get a multiple-hundred-times speedup by using e.g. https://github.com/bitcoin-core/secp256k1/pull/507

apoelstra avatar Sep 17 '23 13:09 apoelstra

Because it is not otherwise linked here, the grinding code is at https://github.com/jb55/nostril/blob/8726ad3b15f10e5a09864bbef61f7a35d1d2f3d7/nostril.c#L255

apoelstra avatar Sep 17 '23 13:09 apoelstra

On Sun, Sep 17, 2023 at 06:36:26AM -0700, Andrew Poelstra wrote:

There is no problem grinding a secret key to get some property of the public key, as long as the only thing you're filtering for is a pubkey property. (If this were a problem, then an attacker could e.g. scan the Bitcoin blockchain for public keys that naturally had a lot of 0s, and then apply whatever attack your grinding supposedly enabled, and all of pubkey cryptography.)

But this xor thing does seem super weird, and this tactic of repeatedly generating fresh independent keys is extremely slow. You should be able to get a multiple-hundred-times speedup by using e.g. https://github.com/bitcoin-core/secp256k1/pull/507

happy to drop it, I'll look into applying this patch locally if it hasn't bitrotted.

jb55 avatar Sep 17 '23 14:09 jb55

@jb55 even if the patch does not apply, you can get a speedup by using the public API to repeatedly call pubkey_tweak_add and seckey_tweak_add with the same fixed value (say, 1). This should still give you a massive speedup, though it will still leave a lot of performance on the table.

apoelstra avatar Sep 17 '23 15:09 apoelstra

On Sun, Sep 17, 2023 at 08:01:29AM -0700, Andrew Poelstra wrote:

@jb55 even if the patch does not apply, you can get a speedup by using the public API to repeatedly call pubkey_tweak_add and seckey_tweak_add with the same fixed value (say, 1). This should still give you a massive speedup, though it will still leave a lot of performance on the table.

oh! ok that makes sense. If someone reading this wants to PR that I would appreciate it.

jb55 avatar Sep 18 '23 13:09 jb55