4 ms·

It appears that they are finding the private keys for transactions that already occurred. Reusing an address is not part of Bitcoin's design and it was never in

by hrehhf 9y ago

It appears that they are finding the private keys for transactions that already occurred. Reusing an address is not part of Bitcoin's design and it was never intended for people to do that. By not reusing addresses (not reusing private keys) I think one would be immune to this attack. The article doesn't seem to have much detail; anyone have more detail on this? Edit: The details are in the URL posted by alphydan; it looks like address reuse does not matter with their method.

TheDong 9y ago
To receive anything, you must have an address (the public key). All coins (UTXO) are associated with addresses which must have private keys. It's impossible to only have a public/private keypair for the instant a transaction is being made because the UXTOs must be owned spendable by some public/private keypair while a transaction containing them is not immediately happening. You clearly don't understand what you're talking about.
- hrehhf 9y ago
  You have ignored the difference between an address with has never spent anything and an address which is being reused. Since you know everything, why not address this directly? edit: Though unrelated to this article, here is a case where address reuse (and software bugs) led to vulnerable wallets: http://www.nilsschneider.net/2013/01/28/recovering-bitcoin-private-keys.html http://www.nilsschneider.net/2013/01/28/recovering-bitcoin-p...
  - TheDong 9y ago
    An address which never spent anything can still be the recipient of a transaction. Those are the addresses which are being attacked here.
- homero 9y ago
  There's actually a public key that isn't the address and it's revealed when spending
- dang 9y ago
  > You clearly don't understand what you're talking about. Please don't be rude in HN comments.
TheDong 9y ago
To receive anything, you must have an address (the public key). All coins (UTXO) are associated with addresses which must have private keys. It's impossible to only have a public/private keypair for the instant a transaction is being made because the UXTOs must be owned spendable by some public/private keypair while a transaction containing them is not immediately happening. You clearly don't understand what you're talking about.
csomar 9y ago
Even more important, by reusing addresses you are making more signatures using the same private key. This has proven to be a vulnerability where one can deduce the private key from these signatures (though limited to a bad implementation) but it's worth considering.

by hrehhf 9y ago

TheDong 9y ago

To receive anything, you must have an address (the public key). All coins (UTXO) are associated with addresses which must have private keys. It's impossible to only have a public/private keypair for the instant a transaction is being made because the UXTOs must be owned spendable by some public/private keypair while a transaction containing them is not immediately happening. You clearly don't understand what you're talking about.

hrehhf 9y ago
You have ignored the difference between an address with has never spent anything and an address which is being reused. Since you know everything, why not address this directly? edit: Though unrelated to this article, here is a case where address reuse (and software bugs) led to vulnerable wallets: http://www.nilsschneider.net/2013/01/28/recovering-bitcoin-private-keys.html http://www.nilsschneider.net/2013/01/28/recovering-bitcoin-p...
- TheDong 9y ago
  An address which never spent anything can still be the recipient of a transaction. Those are the addresses which are being attacked here.
homero 9y ago
There's actually a public key that isn't the address and it's revealed when spending
dang 9y ago
> You clearly don't understand what you're talking about. Please don't be rude in HN comments.

TheDong 9y ago

csomar 9y ago

Even more important, by reusing addresses you are making more signatures using the same private key. This has proven to be a vulnerability where one can deduce the private key from these signatures (though limited to a bad implementation) but it's worth considering.