Topic: Reused R values again - page 11. (Read 121295 times)

50MB and not GB? That is not so much just upload it here https://www.sendspace.com/ The max you can upload there is 300MB so a 50MB file is good.

I omitted most of the important details of how to do the attack (e.g. how the RNG works, how you get the private key) and don't publish my scripts, so this step by step instruction won't help much  

I have a list of the first million public keys/R values the random number generator can generate.  I think I have spotted every weak transaction now.  If someone is interested to host a 50 MB file (100 MB uncompressed), I can publish it. I also have the corresponding private keys / k values, but I want to keep those secret for now.   The R value list may be useful to check if I found all compromised addresses.

There are still weak transactions. Please, clear your browser cache.

http://btc.blockr.io/tx/info/afcb94f22ceee047fc2b59a55b452e5f9e2bcd697fa2a4056d5ac176020a960c
http://btc.blockr.io/tx/info/549cf7a5a11e7a50ccc634f2edcbcbcbc244a4a42de9f946d3c6a32ced27e6f2
http://btc.blockr.io/tx/info/3f79c9b06d46fbbc3ba6c3fdd0512beeb2e928818cdb7d83035b2575458f55ae

And there are some recent transactions paying to a weak key.



At last, regarding the pronunciation of my nick (since someone asked):  In IPA it is ['joːhø].  It sounds something like English yo-ho.

Try using screen:

screen -dmS sessionname to start a new session (disconnected)
screen -ls to list sessions
screen -r id to reconnect
ctrl+a d to disconnect
exit to ...exit!

If your connection craps out the screen will keep alive. You can even start a session on one PC then disconnect and reconnect to it from another.

It should work fine for any unspent output.


Redeeming dust is always to prefer imho. I guess you were referring to the case where, say for example, there is an output close to the dust threshold, which you could move once, but then there would be not enough coins left to move them again, if it were a single transaction where the fee is subtracted from the dust. In this case I'd try to bundle them. It's usually also possible to get away with somewhat lower-than-usual fees at the cost of a moderate confirmation delay. In fact, last time I checked, about three months ago, the average confirmation delay of a sample of 2170 transactions with a size of about ~600+ byte each, with an attached fee of only 0.00001 BTC, was only 20:15 minutes.

What OS are you using?


I was thinking something similar, but on the other hand: once it was "out" that there are some transactions which can be sweeped, it was already too late, so to speak. And not only once it was mentioned people are doing this already. If I had to decide between trying to keep all this secret or a public database of endangered transactions, I'd choose the later - for the sake of awareness. Imho it is a bit similar to the chaos related to transaction malleability, which was "known for ages", but it still required a major incident to raise enough awareness to make users and service providers start to care about on a broader level.

This has been done before, and it is obvious how to do it. It still requires a lot of skill and work to execute and you have to find the weak addresses in the first place.

EDIT: And by the way: Any wallet service which does not implement RFC6979 soon, is doomed anyway. This kind of bugs will always come up, especially if you run the crypto in a web browser.

Other people are going to start sweeping wallets.

This thread is pretty much a step to step guide on how to do it now.

 

I basically have a list of private keys.   I also imported them in bitcoind.  However without rescanning the wallet (this takes several hours now).

I have my own script that scans the block chain and searches for transactions paying to any of these keys (it also detects multisigs and p2sh but not p2sh to multisigs).  If it finds a transaction spending the output it removes it.  In the end I have a list of UTXO for all private keys.  However, this is based on the confirmed transactions only.

What I then do is to get the 10 or 20 most valuable UTXOs and build a transaction for them.  I sign it and send it to the network.  The problem is that sometimes this doesn't work.  Possible causes:

• one of the inputs is already spent by an unconfirmed transaction
• one of the inputs is a coinbase output and doesn't have 100 confirmations.

I mark coinbase outputs in my list so I can avoid them.  However the spent transactions are not so easy to avoid.  The effect can be that signing return "incomplete" or sending gives a strange error message.  In either case I don't know which input the culprit is.  Usually I have to check each input manually to see if there is an unconfirmed spent on it.


I have to try if it works if the wallet was not rescanned.  If yes, this may be what  I need.

I think what I need is to make this fully automatic.  Take the list of all UTXOs, decide which ones can be spend and then spend them all in one or two larger transactions.  Of course, spent outputs by unconfirmed transactions are not well-defined and may differ from node to node.

The other question is how far should I spend the dust?  If the transaction fee goes to 90 % it does not really matter that we saved the money.  On the other hand, letting them lay around in the block chain for all eternity doesn't help either.  One could also try to suck them in with some high-priority free transactions.

Can you rephrase your questions and tell me what you intend to do and then how you do it right now?

Let's skip the part about how you get the information about endangered coins, but I assume you have a list of endangered outputs and you are looking for a handy way to check, if they are already spent. Is that correct?

You may use:


It returns something, if an output is unspent and nothing or empty otherwise. It can only be used to test, if an output is unspent, but not, if an output is spent. Out of range values, invalid transaction hashes, ... are accepted input and result in "nothing" as well. As per default unconfirmed transactions are checked.

Checking an unspent output on mainnet:


Checking a spent output on mainnet:


This transaction is few thousand blocks deep, but it should also work for in-mempool transactions.

How do you sweep coins? What do you need to be more efficient? Do you have, besides a list of endangered transactions as I assume, also the associated private keys? Would it help to have a script to autosweep coins based on a list of transactions and private keys?

Then try mosh. Your connection won't go down. Even if your IP changes.

Yes he swept mine too and just emailed blockchain about it.  But yes Johoe is a great guy...tough to find those in this world most of the time.

try 'screen' command (gnu screen)

keeps your shit running even if you connection goes down. You can connect again with 'screen -x'

Johoe, you just swept my keys!!!

Thank god your doing the right thing, you are my f*cking hero.

(will PM my address for further verification)

True. A fix needs to be implemented soon so that other malicious bystanders do not gain access to his method(s) and wreak havoc.

@johoe,

I'll send you one of my brass coins (unloaded) to you for free.

PM me or email me your shipping information and I'll send it your way.

[email protected]

thanks for being honest! It is refreshing to have that around here. 

I guess you'd move your funds away from all other addresses generated in this wallet first. You will have to abandon this account anyway.

If you're still afraid of signing transactions with blockchain.info, you may sign these transactions offline with other clients like Electrum.

Are you sure this was sent by blockchain.info not some other scammer?

I've had 1+btc "sweeped" into your account, and have requested to get it returned from Blockchain.info - this is their response:
    

This looks like the stupidest idea ever to me - to send them my identifier and password over email (I have other bitcoin in other wallets inside that account... not for long..)

I'm pretty shocked that this is their approach to helping me to SECURE my bitcoin? Is this even allowed / legit?

I'm confused here.

I have been using the reference (Satoshi) client, both the graphic version and the daemon version.  I did not check before posting, but I am pretty sure that I have used watch only addresses for a year or two.

If there was a forwarding option in the protocol, the first thing a black hat hacker would do is to sweep the coins, the second thing would be to set up forwarding to his address (and set it again every time the original owner tries to reset it).

I think it'd be a good idea not to explain in any detail no matter how minor the process that allows you to get these private keys etc.

People with different intentions are going to learn how to do it.