1. If you empty the wallet with a single transaction there is only a very tiny chance that you are affected.  For this the client must be really buggy selecting the same nonce twice in this transaction, and someone (amaclin  ) needs to have his bot running that tries to immediately double spend your transaction after seeing it.  I have seen such a double-spend attempt once but it didn't succeed; although if it had succeeded, I wouldn't have seen it.

2. Probably no bitcoin client is completely safe.  With regards to this problem, they are safe since they use deterministic signatures (January 2015).

3. No.  My script also scans for multisig (at least I intended to do that).  But I haven't found a reused nonce in a multisig so far.

4. They claim to use deterministic signatures.  If that is correct, they are safe.

I updated the first post, so far 7 BTC.


It's better to empty the paper wallet at once into Mycelium and never use it again.  If that contains too much, create several paper wallets with smaller amounts.
Mycelium is not affected by this bug (I think they use deterministic signatures).

My guess is a cloned virtual machine state. 

Observation: The reuse happened several days apart and then the nonces are repeated in roughly the same order.  This happened three times.  Then another completely different set of 10 nonces were repeated again after a few days. 

Possible Explanation: The nonces are generated by a random number generator whose state is stored in a virtual machine image.  After a few days the machine was restored to an earlier snapshot and restarted.  Then again after a few days the machine was restored to this state. 

Only, if you spend the paper wallet with a broken client.  But if you don't reuse paper wallets after emptying them, you are not affected by this problem.

The last time this happened was the Blockchain.info December 2014 incident.  You can read it up here

  https://bitcointalk.org/index.php?topic=581411.0

AFAIK all hardware wallets use deterministic signatures by now, so I don't think it is a hardware wallet.  The wallet is reusing random nonces to generate the signatures.  It could be a bad random number generator or someone cloned the random state (e.g. by cloning a virtual machine or forking processes) or maybe even another openssl problem.  I guess a cloned virtual machine is most likely from the pattern I observe.  It wouldn't have happened if they had used deterministic signatures.

https://blockchain.info/tx/fc9c8c56ce09b48f1e593a0df3f9a03f8dc33ba2027621e047fc5fc4f86f93f6
https://blockchain.info/tx/34535e979bf3e0b960d7e3be85713fa6561a4d9642c7199a7bdf93b721b529a7
https://blockchain.info/tx/e1c9b009cfa861501ae6f3379148fcc5c0de98c5774a6c576fb9f9e6eb2879eb

All three transactions use r = 538d2959108c11f0a34dd65c084af69765c66988b04e09eb0eebb7be69dde951

My script that I still occasionally run has detected repeated nonces (r-value) in signatures again.  Looks like a bad random number generator; the repetitions usually happen some days apart.  The problem seems already to be fixed but the addresses that were compromised are still used.

There were at least 135 keys involved of which at least 82 are compromised now.  Most keys are related to 1BTrViTDX... (in the sense that they are inputs in the same transaction).

I setup a bot to sweep the compromised keys.  If you can prove that it is your address, you can contact me to get the collected funds back.

But don't use the addresses again.  There will probably be other persons setting up bots soon...

EDIT: To prove ownership, you can sign a message with 1HGXq5Spi6NNXFKuQFfDDcYZmzTczKJi4b.  This address doesn't seem to be compromised yet.  Note that this address has also been exposed and should not be used any more.

So far I have collected about 7 BTC.

EDIT2: Fixed the number of addresses.  I accidently counted five unrelated addresses.  Here is a complete list (addresses marked with + can be cracked):
http://johoe.mooo.com/bitcoin/2016-03-compromised.txt

Can you give more details? Does the prover need to know c before choosing x? This would not be possible, since the prover needs to commit for x and c is the hash of the commitment.

Ja, dit werkt ook offline.

Maar met electrum, je hebt die private keys niet nodig.  De zaad (seed), die je hopelijk hebt genodeerd, bevat alle private keys van alle adressen.  Dit is het vordeel van electrum, dat je alleen de zaat veilig te houden hebt.  Het nadeel is: de zaad werkt alleen met electrum. Dit kan misschien een probleem zijn indien electrum niet kan worden uitgevoerd in een paar jaar.

Het is niet goed de private key in verschillende clienten te gebruiken: Als een client heeft een bug, zou de private key in gevaar kommen.  Ook moet men niet onnodig adressen meervoudig gebruiken.

You may want to follow this tutorial on reddit. You need to install python-trezor, to have Trezor support in electrum. 

Don't enter the Trezor seed in Electrum, as this would make you vulnerable to key loggers.  If electrum asks for the seed, you haven't picked the right right option to setup Trezor as a hardware wallet.

Als je niet de bitcoins beweegt, blijven ze op de ene adres.
   

Electrum creërt een nieuwe adres, zodra een vorig adres gebruikt werd.

I think your update won't prevent this scenario:

Prover sets x = -1/2 or another small fraction, E=x*G, F=x*E, I=x*H,  where -1/2 is computed modulo the prime order of the respective curve, i.e. I = (m-1)/2 * H.  Then if c is divisible by 2, c*x is a small number and m = r+c*x is in range.  The verifier would still accept the proof.

I think a better way to fix this is to require c to be a prime, instead of adding I, H and the second curve.  This puts a bit more burden on the prover, as it has to restart if c is not prime.  This extra burden is no problem for your scenario, right? The verifier would just have one additional step that checks that c is prime (e.g., using some probabilistic primality test, or requiring that the prover provides a  primality certificate).  I haven't completely checked this yet but I think it should work.   If the verifier succeeds, it means that |c*x| is <= 2^t * T (or the prover had a very lucky guess of c).  Moreover, since c is prime, this means that x < 2^t*T or x is a multiple of 1/c (which means that the prover guessed c).

The universe is estimated to be 14 billion years.  Lets say it will be there for another 50 billion years.  If you want to exhaust 2^160 addresses, you and every other person on this planet must generate 100 million addresses every picosecond (a trillionth second) until the end of the universe.  And to say what was already said in this thread in other words: once there is enough computing power on this planet to generate all bitcoin addresses, then the current bitcoin address scheme is broken and we need longer addresses.

You can't sell addresses The address is generated from a private key that you choose at random.  You don't want to use an address where someone else generated the private key and has full access to the account.

First, the anti-DDOS measure are there to prevent an attacker to use the distributed bitcoin network to DOS the network.  There is nothing that you can do in the bitcoin source to prevent DDOS attacks from Botnets that are under the control of the attacker.

I think you are correct with your assumptions.  Just like it is possible to DDOS the network from a botnet using DNS amplification attacks you can also use the bitcoin protocol.  I think the developers are aware of these and this is basically a risk that the bitcoin network has to live with.  Just like it is always possible to bring a big server farm down with a sophisticated DOS attack it would probably also be possible to DOS the bitcoin network.  The question is if the attacker has the bandwidth to sustain an attack to all nodes.  Note that all full nodes must be attacked individually for the attack you described.

I think there is no significantly faster way to distinguish a random number from a valid signature except by verifying the signature.  Banning based on IP address is the best one could do, with all its disadvantages.

I'm not sure why anyone want to convert compressed into uncompressed keys, but there are several tools as others pointed out.  Even brainwallet.org had the possibility before it was shut down.

https://rawgit.com/brainwallet/brainwallet.github.io/f7679dd03f39a04edced641960a7c3df1116fea9/

Note that the public key is (slightly) different, so if your other wallet only support uncompressed keys, you can't spend money send to the compressed address.

Yes, privacy is the main concern.  It is also that if one of the keys was broken because of bad signatures with weak r values or because you simply leaked the private key, then the xpub can be used to derive all other private keys in the wallet.  On the theoretical side it also makes you vulnerable to quantum computers (similar as reusing addresses does).  And someone may send you 0.0009 BTC just to annoy you   (They were sent today).


Yes this could be an issue.  Mycelium and myTrezor lite assume standard structure m/is_change/n, which seems to be the case here (at least I can see a lot of transactions).  Note that hardened child keys do not work with xpubs (this is the reason why one uses hardening in the first place).  So you can at least exclude that.

You can also use bip32.org to generate the addresses.  Then you can choose the path by hand.  E.g., "Custom" and m/0/0 gives you the first used address.  It is not really practical, though. You need to generate the addresses one by one and then use a block explorer to check the balance.

EDIT: electrum also works: "Recover wallet or import key" (under File->New/Recover)  and then enter the xpub in the seed field..

You shouldn't post your xpub in a public forum...  unless you use it only for testing.

There is myTrezor lite android app that reads an xpub (from a qrcode) and shows the balance.  It cannot spend from it but it is useful for watching.

Mycelium can also import xpub addresses.

Your balance is 0.0009 BTC (according to Mycelium).

The optimization doesn't work.

For E=a*G, F = (-a-2)*E,  F is a negative number but it can be "proved" with the new protocol:

  W = U + V = r*G + r*E,  c=HASH(E||F||W)
  m = r - c*a

satisfy m*G + (m-c)*E - c*F = W

I'd say both

The lightning network is a great invention.  It supports low-overhead nano-payments with near instant confirmation times that are fully backed by bitcoins.  It has also a few disadvantages:

• If your hub is down, you can't send or receive payments.  You either need to wait until your hub is up again or receive the bitcoins by the pre-signed transactions, which takes several days.
• Hubs may censor your transactions.  Sure, you can always choose another hub or use bitcoin directly.
• You need to establish a payment channel on the blockchain beforehand.  This is a locked coin on the blockchain that contains enough funds to cover your funds that you have at the hub.  The hub must fund it with his own coins to guarantee for the maximum balance that you may receive.  So it is quite capital intensive to run a big hub.  Not only does the hub not get the funds that the customer put there (which is a good thing) but the hub also has to cover for the maximum that its customers may put in their accounts without requiring a new on-chain transaction.
• The security of the lightning network relies on the fact that nobody can spam the blockchain to prevent the confirmation of a fixed fee transaction for a few days.  Do you think this is possible with the current block size?
• If you don't constantly watch the blockchain, your hub may cheat you and steal your coins after a few days.
• There is no implementation, yet.

We need a larger block size anyway.  The lightning network may help to reduce the current growth, but the size of the blocks have to grow.  Also we should at least kick the can to ensure that the current growth can continue short term until we know the lightning network works and is accepted by the community.   And if we keep the block size small to get fees of 20 $ per on-chain transaction (like some small block proponents want), we would basically prevent that people can avoid LN because of censoring or other reasons.

28 BTC is what was sent to the published addresses and what was subsequently sweeped from them.  So it includes the fees that the sweeping transactions payed.  It doesn't include the fee that coinwallet.eu payed to produce the dust output.  This fee could be another 20-40 BTC; I'm too lazy to write a program to count it.   What people trying to collect the dust received was probably in the range of 5-7 BTC, but that is a wild guess.  I guess amaclin is the only one who made more than a bitcoin.  Okay, there is also the 3J9AGq2aHeqjW13jj1LkaK5kCgZ8EyAjXZ address.  When I have time I write a script that counts the fees and sweeped amount for every major reused address.

According to my script you were successful in cleaning the last dust.  0 UTXO left (my script only considers confirmed transactions).

Why did you do it in so many transactions?  It would save a few bytes to use larger transactions and give a better fee per byte ratio.  I guess the reason is that large transactions are more likely to conflict with something in the mempool and are therefore much harder to push to the miners, correct?

Total received: 28.15759741 BTC on 791 addresses (unless I have a bug in my quick 'n dirty counting script).   Does this mean that the keys for the remaining 172 BTC will be published later?

PS: Another effect of these transaction is that my R-value cracker runs much much slower now.  Almost 2.5 Million duplicated R-values