Thought I'd share an interesting story in an attempt to get out of newbie purgatory.
Maybe if I copypasta they'll let me out too
Interesting share though, it makes me more curious about potential alt currency vulnerabilities.
Topic: First post and an interesting observation about ECDSA (Read 806 times)
Maybe if I copypasta they'll let me out too
Interesting share though, it makes me more curious about potential alt currency vulnerabilities.
Now that's 1000x better than a stupid "why do I have to make a stupid post" post!
An interesting observation (and now we're sure to get some others wanting to do something to "rescue" those poor lost coins) - welcome aboard!
An interesting observation (and now we're sure to get some others wanting to do something to "rescue" those poor lost coins) - welcome aboard!
Thought I'd share an interesting story in an attempt to get out of newbie purgatory.
If you dig into the ECDSA signature algorithm it turns out during key generation you can pick any secret exponent less than the group order when generating a private key ... but you aren't supposed to pick 0.
So what happens if you pick 0? If you pick 0 your public key ends up being the group identity element which has an odd-ball SEC representation of 00 (hex) and this yields a bitcoin address of 1FYMZEHnszCHKTBdFZ2DLrUuk3dGwYKQxh ... I turns out this address has been sent 2.08 BTC over 14 transactions [1].
So I got to wondering ... does the signature math still work out in this case ... i.e. I tried to create a transaction to spend these coins that were sent to the group identity. It turns out you can make the math work out. That said, technically a signature verifier is supposed to check to make sure the signer's public key isn't the identity element as the first step of the verification algorithm, however, the underlying crypto library bitcoin uses does not explicitly do this. That said, checks added to the script system about a year ago [2] cockblock any attempt to spend these coins because they length-checks the representation of public keys ... and the identity element has an non-standard 1-byte representation.
As proof, I just sent an attempt to spend one of these coins:
http://blockchain.info/tx/e1801a2458252f7d80be5fe82aa73378fccf9efb2f0bb07a153cb66893f2aad9 ... blockchain.info is a bit confused by this transaction (and it will eventually remove it from the pool because it will never make it in a block). Note also, it parses the scriptSig ambigiously because the public key representation is 00 (aka OP_FALSE).
[1] https://blockchain.info/address/1FYMZEHnszCHKTBdFZ2DLrUuk3dGwYKQxh
[2] https://github.com/bitcoin/bitcoin/commit/58bc86e37fda1aec270bccb3df6c20fbd2a6591c
[3] This address was mentioned in passing in https://bitcointalk.org/index.php?topic=50206.15 ... ironically at the time, by my analysis anyone could have actually spent these coins at that time because [2] was not implemented yet.
If you dig into the ECDSA signature algorithm it turns out during key generation you can pick any secret exponent less than the group order when generating a private key ... but you aren't supposed to pick 0.
So what happens if you pick 0? If you pick 0 your public key ends up being the group identity element which has an odd-ball SEC representation of 00 (hex) and this yields a bitcoin address of 1FYMZEHnszCHKTBdFZ2DLrUuk3dGwYKQxh ... I turns out this address has been sent 2.08 BTC over 14 transactions [1].
So I got to wondering ... does the signature math still work out in this case ... i.e. I tried to create a transaction to spend these coins that were sent to the group identity. It turns out you can make the math work out. That said, technically a signature verifier is supposed to check to make sure the signer's public key isn't the identity element as the first step of the verification algorithm, however, the underlying crypto library bitcoin uses does not explicitly do this. That said, checks added to the script system about a year ago [2] cockblock any attempt to spend these coins because they length-checks the representation of public keys ... and the identity element has an non-standard 1-byte representation.
As proof, I just sent an attempt to spend one of these coins:
http://blockchain.info/tx/e1801a2458252f7d80be5fe82aa73378fccf9efb2f0bb07a153cb66893f2aad9 ... blockchain.info is a bit confused by this transaction (and it will eventually remove it from the pool because it will never make it in a block). Note also, it parses the scriptSig ambigiously because the public key representation is 00 (aka OP_FALSE).
[1] https://blockchain.info/address/1FYMZEHnszCHKTBdFZ2DLrUuk3dGwYKQxh
[2] https://github.com/bitcoin/bitcoin/commit/58bc86e37fda1aec270bccb3df6c20fbd2a6591c
[3] This address was mentioned in passing in https://bitcointalk.org/index.php?topic=50206.15 ... ironically at the time, by my analysis anyone could have actually spent these coins at that time because [2] was not implemented yet.
Jump to: