Thinking of starting a service to prevent stolen coins. Input please?

[f392ad57b]

Years ago, there was a reddit user btcrobinhood, who saved 35 bitcoins:

https://www.reddit.com/r/Bitcoin/comments/295las/35_of_my_btc_gone_pc_not_compromised/

Though this account has been dormant for a while, I have been thinking about it a lot lately. The reaction to him/her saving 35 bitcoins was mixed. Some thought they were just a thief who did the right thing when provided with sufficient proof. Others hailed them as a hero.

It occured to me that a service that simply returned coins to the address from which coins were sent to a compromised private key might be a safe middle ground.

What do people think of this?

It would work as follows:

1) a large database D of compromised private keys would be compiled

2) the bitcoin network would be monitored for transactions that sent funds from any address A to an address B, where address B was generated from a private key contained in D

3) the system would attempt to intercept such funds before a thief could steal them, by signing a transaction that sends the same amount of coin that was sent from A to B back from B to A.

Thoughts?

[Soros Shorts]

Years ago, there was a reddit user btcrobinhood, who saved 35 bitcoins:

https://www.reddit.com/r/Bitcoin/comments/295las/35_of_my_btc_gone_pc_not_compromised/

Though this account has been dormant for a while, I have been thinking about it a lot lately. The reaction to him/her saving 35 bitcoins was mixed. Some thought they were just a thief who did the right thing when provided with sufficient proof. Others hailed them as a hero.

It occured to me that a service that simply returned coins to the address from which coins were sent to a compromised private key might be a safe middle ground.

What do people think of this?

It would work as follows:

1) a large database D of compromised private keys would be compiled

2) the bitcoin network would be monitored for transactions that sent funds from any address A to an address B, where address B was generated from a private key contained in D

3) the system would attempt to intercept such funds before a thief could steal them, by signing a transaction that sends the same amount of coin that was sent from A to B back from B to A.

Thoughts?

The crux of the problem is that 2 (or more) people have access to the same private key. You'd have a hard time determining who is the rightful owner. If both users happened to use some identical phrase from Shakespeare to generate a brainwallet private key then both are innocent (though exceedingly stupid).

[f392ad57b]

Ah. A good point but I think it's moot. Here's why:

Let B be the compromised address that has been generated from a private key contained in database D.

You can be reasonably confident that at any given moment in time the balance at B is 0. Why? Precisely because of the fact that this address is known to be associated with a private key that multiple people hold -- no one who holds such a key would keep funds at that address. They would immediately transfer any funds to an address that only they can sign on.

Thus, we monitor the network for any new transactions that are of the form A -> B, where A is any Address (say, maybe, also any address that is NOT in D). Then we simply attempt to sign a transaction that sends the same amount of coin from B -> A. Essentially we are saying:

"Look, person who owns address A, you are trying to send funds to address B that multiple people hold the key to, so we are going to throw those funds back to you so you can try again, lest they be stolen in a subsequent transaction from B -> some address a hacker owns.

Make sense?

[franky1]

alot of people already monitor known compromised keys. and have a app that autosends the funds to another address, even with a huge fee markup to ensure their tx gets confirmed. after all if you put a 50% of funds fee.. 50% of something is better than 1% of nothing.

usually legitimate owners that accidently funded a compromised address would waste alot of time panicing and searching and crying and its too late to ask for help because the funds were moved in seconds.

also some exchanges outputs (people making a tx to withdraw) the funds dont actually come from the users 'balance' but from a mixed address/vault where returning coins wont 'credit' the user. but then just be free coin for the exchange. so its not really a guarantee/help

one idea is for people to use CLTV and CSV to lock(mature date) funds(CLTV) and have a refund/chargeback clause(CSV) where they can force funds to return to a certain address. thus people can make their own smart payment be protected without needing a middleman/service

[f392ad57b]

This is anecdotal, but I saw someone lose 5 BTC earlier this week through one of these hacks, and the fee was 0.001 BTC. I'm fully aware that the chances of this service succeeding are slim, but if it saves the coins of even 1 person, it would be worth it to me.

The exchange point is interesting, but I would hope that exchanges have some kind of blacklist of addresses that they could use to warn users about outbound transfers to. Such as "Hey you're about to send money to address XYZ and that address is known to many and you money will be stolen instantly." They prob dont do a check like this but I feel like they should...

[franky1]

again if people used things like CLTV and CSV they can put their own time delay and chargeback conditions on payment thus protect themselves without middlemen.

but seems devs and other people want average users to prefer middlemen and counterparty control (banks) which then voids the whole point of bitcoin.
CLTV and CSV as a feature of onchain transactions has utility. but ignoring self control and instead HOPING a third party will protect them is just a waste
EG promoting CLTV and CSV as a feature of only LN is stupid. LN is banking 2.0 due to counter party requirement to dual sign, its much better to just use CLTV and CSV as a feature of onchain bitcoin transactions that peopl can self administer