Topic: Adding anti-theft feature to Bitcoin using a new address type (Read 420 times)

No..this is exactly the point. the exchange only ever keeps the R-ON key online. This is no problem.

The R-OFF key is NEVER online. Only ever used AFTER a hack.

This way you get cold storage security, with hot wallet convenience.

It's not there's yet. They can't touch the coins for 144 blocks. Again - this is only for LARGE HOT WALLETS.


Once the User has waited 144 blocks, those coins are _then_ his, and behave like regular normal coins.

I'm not saying ALL coins should use this, but it's certainly a very handy way of securing certain situations.

You could choose. You want to have your coins stored by the exchange in their R-Address (probably insured too..), and wait 144 blocks before getting your withdrawal (which you can then use as per usual), or.. not use the R-Address and risk theft, but get your coins quicker when you withdraw. Up to you.

Absolutely, but this situation is very different.

These addresses would work great for Large Online Hot Wallets.

Like an exchange.

In practice - it just means they don't send the user their coins directly. They send them first to the special safe-house address, the S-Address. And once there, the user can come and collect them. Then he can consider the coins his. Not before. No one is reversing anything.

If the coins are taken maliciously, the exchange can just retrieve them from the safe-house, before the malicious user can.

Obviously - if the R-OFF key is stolen, all bets are off. Hacker would then have root. But the R-ON address could certainly be kept online, with no real security issues.

Anything with the word "reversible" in Bitcoin should make your alarms beeping automatically. I wouldn't honestly trust these addresses for cold storage. In fact, anything but legacy addresses I would not trust for the very long term (20+ years). I do not see the problem in having your coins sitting on legacy addresses which are sitting on a computer which never touched the internet (and obviously whose private keys were generated in a controlled airgaped environment too).

If these premises are meet then your coins are as safe as they get, you don't need to add additional features into Bitcoin for that, no one is going to steal your coins. Just have to keep the physical container of your coins safe. If you trust the seed approach then you don't even need that (im paranoid about Electrum seeds for cold storage for instance).

Thinking more on this..

It can all be done with Covenants. ( This is a script feature that allows you to specify conditions for which addresses an output can be spent to.. )

https://blockstream.com/2016/11/02/covenants-in-elements-alpha.html

A future feature..

Putting aside the FORK that this would take..

.........

An R-Address is a special address that is composed of 2 separate addresses.

One of the addresses is meant to be kept online (for fast payments), and one offline (secure). R-ON and R-OFF.

R-Address = HASH ( R-ON | R-OFF )

Spending with the R-OFF key lets you do whatever you want. This is only ever used after a hack.

Spending with the R-ON key means that you MUST send the funds to another special address, the S Address.
 
The S Address is also made up of 2 separate addresses.

One of the addresses is the user address S-USER, and one MUST be the R-OFF key from the R address.

S-Address = HASH ( S-USER | R-OFF )

Again, spending with the R-OFF key lets you do whatever you want, as soon as the transaction is confirmed. And again you would only use this after a hack.

Spending the S-USER address requires you to wait 144 blocks.

R and S addresses should be verifiable by the miners, so you can't just stick it all into an obscured P2SH.

Soo.. what this means is..

When a user receives funds from an R-Address he will need to wait 144 blocks before he can claim them. I think this is a non issue given the security implications of an un-hackable online hot wallet.

BUT - if a hacker steals the R-ON key (the exchanges online key), he MUST also send the funds to an S address. Then also wait 144 blocks. Enough time for the exchange to notice, and use the R-OFF key.

the part that I bolded, how could that be done?
if the transaction has been confirmed, it creates new utxo belongs to receiver
enabling R-address sender to somehow control receiver's utxo before 100 confirmations is probably troublesome (or impossible?)
you are opening a pandora's box, this could be misused and create more problems in the future

Transactions can never be removed from previous blocks, it would be a huge mess if someone tried to make a protocol that removes transactions from previous blocks.
This R-address system can work by allowing the private key of R-address to spend coins from the address they've sent coins if there's less than 100 confirmations.


Flagging is a horrible idea, it violates privacy and creates more problems than it solves.

Overall this idea will become more relevant in the future, when less and less on-chain transactions will be used for doing purchases. Since on-chain transactions will be used for moving big amounts, security features will become more important than now.

RBF doesn't violate the principles.
RBF is applied on unconfirmed transaction still in mempool and never tried to change blockhain history
this "R-address" concept is clearly breaking it, by having the ability to reverse a confirmed transaction

can be reversed before 100 confirmations = can remove it from previous block as if the transaction never happened/confirmed
that means changing the blockchain history, which is against the fundamental of  "Blockchain History should be immutable."

How R-Address works? you have a single wallet and two addresses on that wallet, and you can choose with which one you want to send coins with, or that works like two wallets, and you can send coins between normal address and R-address?


How exactly flagging works? Everybody agrees that coins in that wallet are stolen, and all transactions from that wallet, will be dismissed on blockchain?

Delaying the inevitable will not solve the problem, we must find other ways to stop these thefts. We have seen the disadvantages linked to Chargebacks and how scammers are using that to scam people. So it did not work with the fiat system, because it has disadvantages and advantages.

Flagging stolen coins through a consensus decision or voting system, might work if you can make sure that it cannot be exploited. Once the coins are tainted, merchants might not be willing to accept it as payment for their goods.  

I like this idea, these addresses could be very useful for cold storage and other types of saving wallet, you can even run a script that checks new blocks for unauthorized transactions made from your R-address and if it finds one, it can automatically broadcast a signed counter-transaction. This can even be outsourced to some online service.


But this is a new address type, no one talks about making all transactions like that. We already have RBF and no one has problems with that, because it's pretty clear what type of transaction you receive.
Wallets would just need to make it very clear that the received transaction is not final until 100 blocks and can be reversed, to avoid malicious people from taking advantage of newbies, like it happens with all those "double your coins" scams.

having cold, warm and hot wallets would help mitigate that problem
decentralized exchange is another option to reduce (if not solve) the risk of losing coin at exchange

this is completely against one of the main Principles of Bitcoin, irreversible transactions

Sadly you are right.. it won't work. It'll just be a race between the attacker and the real owner to double spend coins.  We need something more, such as "return to previous" sender kind of kill switch.

not really, it can be a 2way pegged sidechain,

from what I can understand the point is to force transactions to be stored(abusing blockchain as a database) with an nlocktime that prevent a transaction to be confirmed.
but it is pointless as a robber have no problem adding ridiculous high fees.

Thanks for the suggestions. I will work on it.

The point is that an organization/person whose coins are stolen will have about 16 hours to discover it and save them. In current scenario, this is not possible once the coins get even 1 confirmation. I assume this time should be sufficient to discover a theft and also code the recovery transactions.  

Obviously, these addresses should not be used for paying for stuff that we buy online. It is designed for exchanges and pools that hold large amount of funds in hotwallets, which when compromised can lead to huge losses.

Merchants need to tell customers to ensure that their payments don't come from R-addresses.

Your proposal itself requires a fork as it is a change to the consensus rules.

If you want to be taken seriously, then you should post to the bitcoin-dev mailing list and create a BIP

---

What is the point of this? You are just extending the period of time that something is unconfirmed for. Merchants, when they see coins sent from such addresses, will simply not accept the coins until the 100 confirmation mark because they know that the coins can be double spent anyways. It is just the same security as unconfirmed transactions.

What is proposed?

A new type of address called R-address ("reversible addresses") to be added to Bitcoin alongside the usual type of addresses.

Funds sent from an R-address behave like freshly mined coins in that they need 100 confirmations before they can be further spent.
Additionally, funds sent from R-addresses can be double-spent (i.e., reversed) before 100 confirmations are made.

These make sense for exchanges where large amounts can be stolen, but not for buying a coffee (which would be done via normal addresses).

To prevent flooding attacks, something like RBF will be used to ensure that the double spent fee is higher than the original fee.

Some issues probably need to be ironed out but overall is this a practical idea?

Will the core developers take this up? Or will this require another hard fork?