Hot wallet protection concept ("Loaded gun method")

[RedWojak]

Hello.

I have a web service with hot wallet that generates addresses to my end users, receive payments, allow withdrawals - the usual stuff. It came to my mind that besides usual sanity checks I should integrate some sort of safeguard protecting me from people who managed to somehow gain access to the private keys of those deposit addresses. So I came up with following idea:

Create a bot that scans mempool and act like this:

"If it sees a transaction that empties everything (or significant part of it - rules for triggering this mechanism can be adjusted) from unspent outputs corresponding to my addresses, it immediately sends another transaction with same inputs, but with significantly bigger fee, therefore preventing the theft.".

Will this work? I don't think I'm the first one to think of this method of protection, so there should be some sort of established practice for this or something that will prevent this from working as intended.

[1714772096]

1714772096

[1714772096]

1714772096

[1714772096]

1714772096

[1714772096]

1714772096

[Xynerise]

1.) There is no concept of "the" mempool; all full nodes have their own local mempool.
So it's possible that your bot won't even find the tx at all.

2.) It's not guaranteed to work at all.
How do you know a miner hasn't already assembled the first tx in a candidate block?
If he already has then he can't accept the new tx even though he sees it because it conflicts with one already in his candidate block.


There's no way for it to work.
The private key is what you should protect.

[HeRetiK]

Well, it could work, but as mentioned by Xynerise there's absolutely no guarantee for it to work. Higher transaction fees does not necessarily mean "skipping the line" if your adversary has also put an adequate transaction fee in place. Problem being that your adversary will have a head start and given a high enough transaction fee has thus a better chance of getting added into a block than your defensive double-spend transaction.

Furthermore you mentioned that you would trigger this transaction if someone where to withdraw the full address balance. Wouldn't this also prevent your users from accessing their own coins?

You could implement such a bot as an additional safety measure, but it shouldn't be all that you rely on. The safer bet is automatically moving incoming user deposits to cold storage addresses, keeping only a fraction of coins available in a hot wallet for your user to withdraw. For keeping track of the hot wallet a defensive watcher bot may make sense, keeping in mind aforementioned deficits.

It is also worth noting that automating the movement of coins from cold storage to the hot wallet opens additional attack vectors, so be mindful of that, should you choose to add cold storage as part of your security model -- which you definitely should.

[RedWojak]

Well, it could work, but as mentioned by Xynerise there's absolutely no guarantee for it to work. Higher transaction fees does not necessarily mean "skipping the line" if your adversary has also put an adequate transaction fee in place. Problem being that your adversary will have a head start and given a high enough transaction fee has thus a better chance of getting added into a block than your defensive double-spend transaction.

That is well understood, but it at least can give a slight chance to prevent funds being stolen. I actually can pregenerate my transaction and only attach fee as soon as I see malicious tx (if I see it at all), so it surely be higher, therefore raising my chances to save the day.

Furthermore you mentioned that you would trigger this transaction if someone where to withdraw the full address balance. Wouldn't this also prevent your users from accessing their own coins?

Depending on the service architecture - it may or may not be the case. At least I will retain control of the funds. Refunding them to end users is kinda trivial.

You could implement such a bot as an additional safety measure, but it shouldn't be all that you rely on. The safer bet is automatically moving incoming user deposits to cold storage addresses, keeping only a fraction of coins available in a hot wallet for your user to withdraw. For keeping track of the hot wallet a defensive watcher bot may make sense, keeping in mind aforementioned deficits.

It is also worth noting that automating the movement of coins from cold storage to the hot wallet opens additional attack vectors, so be mindful of that, should you choose to add cold storage as part of your security model -- which you definitely should.

I have contemplated defensive measures for quite a while now and cold storage is for sure one of them. My current model is to move 50-60% of all hot wallet contents to cold storage daily, leaving only bare minimum in the automated system (to handle necessary automated withdrawals).

There of course no possibility to automatically refill hot wallet (i.e. production backend have no access to cold storage, it is physically separated systems with proper airgap, and encrypted keys are stored offline, only allowing signing raw transactions that are taken from printed qr codes, which is manually checked before being signed - this sort of paranoia).

The idea I described above is just another layer that in theory could add some extra security to what is left in hot wallet system.

[HeRetiK]

Well, it could work, but as mentioned by Xynerise there's absolutely no guarantee for it to work. Higher transaction fees does not necessarily mean "skipping the line" if your adversary has also put an adequate transaction fee in place. Problem being that your adversary will have a head start and given a high enough transaction fee has thus a better chance of getting added into a block than your defensive double-spend transaction.

That is well understood, but it at least can give a slight chance to prevent funds being stolen. I actually can pregenerate my transaction and only attach fee as soon as I see malicious tx (if I see it at all), so it surely be higher, therefore raising my chances to save the day.

If the core security model is based on cold storage with a watcher bot being just another line of defense for the hot wallet I see no harm done -- ignoring the additional complexity such an approach brings.

But just to stress it once again: Which transaction gets selected by a miner is largely dependent on their respective mining software and configuration, which may or may not take transaction fees into account. So even if your transaction fee is reliably higher than that of your adversary and both transactions start to propagate at roughly the same time, it's still a gamble. Worth a shot probably, but just be aware that beyond a certain minimum the size of the transaction fee may be irrelevant to some or most miners.

[RedWojak]

Well, it could work, but as mentioned by Xynerise there's absolutely no guarantee for it to work. Higher transaction fees does not necessarily mean "skipping the line" if your adversary has also put an adequate transaction fee in place. Problem being that your adversary will have a head start and given a high enough transaction fee has thus a better chance of getting added into a block than your defensive double-spend transaction.

That is well understood, but it at least can give a slight chance to prevent funds being stolen. I actually can pregenerate my transaction and only attach fee as soon as I see malicious tx (if I see it at all), so it surely be higher, therefore raising my chances to save the day.

If the core security model is based on cold storage with a watcher bot being just another line of defense for the hot wallet I see no harm done -- ignoring the additional complexity such an approach brings.

But just to stress it once again: Which transaction gets selected by a miner is largely dependent on their respective mining software and configuration, which may or may not take transaction fees into account. So even if your transaction fee is reliably higher than that of your adversary and both transactions start to propagate at roughly the same time, it's still a gamble. Worth a shot probably, but just be aware that beyond a certain minimum the size of the transaction fee may be irrelevant to some or most miners.

Understood!
Thank you for your expertise.

[Spendulus]

Hello.

I have a web service with hot wallet that generates addresses to my end users, receive payments, allow withdrawals - the usual stuff. It came to my mind that besides usual sanity checks I should integrate some sort of safeguard protecting me from people who managed to somehow gain access to the private keys of those deposit addresses. So I came up with following idea:

Create a bot that scans mempool and act like this:

"If it sees a transaction that empties everything (or significant part of it - rules for triggering this mechanism can be adjusted) from unspent outputs corresponding to my addresses, it immediately sends another transaction with same inputs, but with significantly bigger fee, therefore preventing the theft.".

Will this work? ....

You've heard what people think. Myself I'd like to see actual test results of a try with it.

A while back there was a thread on a proposed method of creating a withdraw address that was really just a "honeypot," I wonder if anyone ever implemented that.

[hatshepsut93]

I've been thinking about such system myself some time ago, and I think it can be slightly improved if instead of trying to publish transaction with big fee, you give this signed counter-transaction directly to miners (they should have as much hashpower as possible and you can have this arrangement with multiple pools) and ask them to include it in the next block for some reward. This can increase chances of counter-transaction succeeding, but attackers can also utilize this - they might privately ask miners to include their transaction in a block, without broadcasting it, so after that your only chance to stop it is to try to rewrite the last block by coordinating the majority of mining power (again, you need to work with multiple mining pools). Maybe some big exchanges like Coinbase have something like that, and miners can be also interested in that, because if a major exchange will get robbed, the price might go down significantly.

[Spazzer]

It's a really interesting idea, but I feel like searching for the TX would take up a large amount of resources or not be possible.

[RGBKey]

Maybe it's possible to use a non-standard wallet that stores some kind of outputs that are designed to not be spent all at once.

[Anti-Cen]

Hello.

Nice to see you are thinking out the box and passing it around.

[Anti-Cen]

A while back there was a thread on a proposed method of creating a withdraw address that was really just a "honeypot,"

I wrote a honeypot as a proxy service and 99% of the traffic was from robots fake clicking internet adverts
(including googles double-click) so I did a lot of caching and faking HTTP reply's to limit the amount of up-stream
traffic and at times I was dealing with about a million requests an hour on a little PC.

Contracts are sold on Tor by add-servers that pay in Bitcoin and these guys have there own underground network
for this type of activity but I could feed these bots for weeks and still they didn't seem to notice and i would say that today
we have 70% plus of data being generated by bots and twatter is awash with them and is starting to include a little A.I