Hacker Publishes Private Key, But No One Can Steal His ETH

Your privates are private, but not for this hacker, Robert M. C. Forster (pictured above), who was very happy to share his private key of an ethereum address containing one eth, yet no one could hack it.

At around 12:06 PM London time on bitcoin’s birthday, January 3rd, Forster funded the address in question.

Around the same time, he made a public statement revealing the private key. Circa 20 minutes later, the funds moved.

The one who tried to take this eth said he was impressed, and was kind enough to share some detail about the transaction that never made it to the ethereum network.

As we can see in the previous screenshot, the eth went to 0x25, not 0x4e2. In his initial statement, Forster said 0x25 is his safety wallet and is where the eth would go.

So it worked, and it worked because of something called Replace by Fee (RBF) mixed with a fairly novel execution.

The idea is far too simple. You sign a transaction, but you don’t tell the network about it, you just keep it to yourself as a backup. Now… we tried to speak to Forster without timely success, but presumably you run what are called listening nodes to see if anything is happening with your account.

Once something does happen, as with the case of the Gucards hacker there above, you quickly broadcast the backup transaction and, presuming your transaction fee – payment to miners – is bigger than Gucards’, then the safety wallet transaction will be included above that of the hacker.

The hacker’s transaction then drops off the network, hence why we can’t see what Gucards actually did and have to rely on his word.

Yet we don’t have to trust Gucards or even Forster regarding whether this works as if we could bother – have time – we could probably code this ourselves and make it all work because it is a bit far too simple, yet also quite novel.

Replace by Fee, as you might know, is an implicit rule where miners include the transaction that pays the highest fee when there are otherwise two identical transactions waiting to be included in the network.

Miners don’t have to do so. They can choose the lower fee transaction instead, but dumb miners in this ruthless industry tend to get flushed out. So, in our own experience it does seem far too often miners just include the transaction that pays them more regardless of whether it is the second or third “clone” transaction.

So when the hacker broadcasts the theft transaction, the blockd system broadcasts the one that has already been signed, prepared, and has been furnished with a higher gas fee.

In ethereum, block times have dropped to 12 seconds, so the blockd system must be working extremely fast when the network is not congested, and even if it is congested, because the hacker can always increase the fee.

The secret sauce presumably therefore is just how does it work so fast, but not necessarily so secret cus Infura.

The weakness is obvious. The hacker can Infura too. Yet the end result would be wasted time because if the hacker is bidding up the fee and backd is too until it reaches the stage where the entire value is the fee, then not only has the hacker run the risk of prison, but also has nothing to show for it.

Execution is key and in that regard this is a bit too new to pass judgment on execution, but Forster says instead of signing the unbroadcasted transaction through their front-end facing interface which might not be too secure, you could potentially just give them an offline signed transaction that you yourself have created, with their primary service obviously being the monitoring and the quick reaction.

As you might know, a cryptographic signature is a way of proving who you are, that you have the private key, while not revealing exactly who you are – as in while not showing the exact gibberish numbers and letters of the private key which look something like what Forster published:

ca9a3a3d4026e6228713e683a9c45ef65a538b2f9336813bd597f5effa38668d

If you publish those letters and numbers, then you give any hacker full power. But to not publish it and only sign with it, constrains action to whatever you’ve signed.

In this case what is signed is the right to transfer the funds to the safe wallet public address. This dictation can not be altered and if you publish this order of a signed transaction, all that can be done is to follow what the order is, that being to send the eth to the safe wallet.

This ability to order while not revealing yourself is a considerable part of the bitcoin invention and without it this whole thing can’t really work as smoothly as it does, yet pedantically every signing potentially reveals a tiny little bit of your private key. Hence the advice is usually to change address every time a transaction is made.

Realistically no one really does that because this reversion to the private key through an authorized signature is a bit far too theoretical at this stage, but conceptually arguably as you can go one way, you could potentially maybe one day go back the other way.

For now and the foreseeable future, the setup here at a cryptographic level where conceptually it is concerned, appears sound with the trust requirement being more the monitoring part presuming the unbroadcasted transaction was not created through their website as then you’d have to trust their online setup and yours.

You’d have to trust it so because to sign, you have to reveal the private key. Once it is signed, you can reveal the transaction if you wish as all the network would be doing would be following what is ordered – sending the eth to the safe wallet.

Yet in the process of signing, if the private key is learned – then presuming it is before blockd is up and running – well you’d see funds leave to a non safe wallet and very, very quickly.

So the execution and the combination of all these aspects in Blockd is quite interesting, because while it does not provide full security as no system created by man can be perfect, it does provide a higher level of security through a very complex and yet quite simple method of basically hackers hacking hackers.

Copyrights Trustnodes.com