On reversible transactions | Bitcointalksearch.org

deisik

legendary

Activity: 3514

Merit: 1280

English ⬄ Russian Translation Services

Quote from: franky1 on February 10, 2019, 09:27:42 PM

Quote from: deisik on February 09, 2019, 08:59:21 AM

Quote from: pat4cryptoreal on February 09, 2019, 07:31:58 AM

This will not profound solution to cryptocurrency theft. As security level goes higher the hackers also upgrade their hacking techniques. The solution is just to be careful and security conscious

Being careful and aware of security concerns doesn't seem to help exchanges much

As they are continually being hacked with coins stolen. So we need something which would stop hackers at the protocol level itself, something which they can't possibly beat (then no improved hacking techniques will be able to help them). I think an option of locking addresses at this level with a whitelist of addresses attached would help a lot in this department. Can anyone ask Bitcoin developers to think about implementing this option?

again. no protocol changes are needed.
the issue is that exchanges use "hotwallets". meaning they store private keys on the very same server as the exchange front-end. thus if a hacker can get to the server he can get to the keys

Exchanges don't store coins in hot wallets

Even if they do use hot wallets too as you seem to understand yourself (since you refer to hot wallets meaning you understand there are cold wallets as well). I don't know the exact ratio but I don't think that the amount of dough they store in their hot wallets exceeds a few percentages of their total holdings (unless there is an exchange run). The option proposed helps increase security of cold wallets, and it is a big deal

franky1

legendary

Activity: 4410

Merit: 4788

Quote from: deisik on February 09, 2019, 08:59:21 AM

Quote from: pat4cryptoreal on February 09, 2019, 07:31:58 AM

This will not profound solution to cryptocurrency theft. As security level goes higher the hackers also upgrade their hacking techniques. The solution is just to be careful and security conscious

Being careful and aware of security concerns doesn't seem to help exchanges much

As they are continually being hacked with coins stolen. So we need something which would stop hackers at the protocol level itself, something which they can't possibly beat (then no improved hacking techniques will be able to help them). I think an option of locking addresses at this level with a whitelist of addresses attached would help a lot in this department. Can anyone ask Bitcoin developers to think about implementing this option?

again. no protocol changes are needed.
the issue is that exchanges use "hotwallets". meaning they store private keys on the very same server as the exchange front-end. thus if a hacker can get to the server he can get to the keys.

easy solution is that exchanges stop using hotwallets
next instead of usernames and passwords. users can register a public key on the exchange. and then to login AND to withdraw they simply sign a message the exchange requests to prove identity.
EG: 'sign a message using 13xamP734ddr355 with the message:
deisiksayzletzmein110219

user signs the message using their key and pastes it to the server
this public signature sits on a database on the server front end. and separately a remote server just sniffs the database and sees the withdraw request and see's that the signature matches the users registered public key and then its the remote(secret) system that then processes actual withdrawals. thus no passwords, no private keys are ever saved on the exchange server

that way a hacker cant just grab a private key, because there are none. and cannot log in, because they dont have access to sign a message to prove ID.

i find it absolutely astonishing that in a bitcoin world people are not using the benefits of signatures as proof of ID

deisik

legendary

Activity: 3514

Merit: 1280

English ⬄ Russian Translation Services

Quote from: prasad87 on February 08, 2019, 07:01:01 PM

What you don't seem to understand is that "once reversible" transactions will always be reversible. How do you determine who has the authority to reverse transactions? What gives you the confidence that once a precedent is there, you won't see "reversals" for "moral" reasons like wealth distribution and other garbage?

You may want to read the OP in its entirety first

Quote from: pat4cryptoreal on February 09, 2019, 07:31:58 AM

This will not profound solution to cryptocurrency theft. As security level goes higher the hackers also upgrade their hacking techniques. The solution is just to be careful and security conscious

Being careful and aware of security concerns doesn't seem to help exchanges much

As they are continually being hacked with coins stolen. So we need something which would stop hackers at the protocol level itself, something which they can't possibly beat (then no improved hacking techniques will be able to help them). I think an option of locking addresses at this level with a whitelist of addresses attached would help a lot in this department. Can anyone ask Bitcoin developers to think about implementing this option?

bots1

sr. member

Activity: 957

Merit: 278

Vave.com - Crypto Casino

Interesting to apply, I think decentralization must have the same function as centralization. The first point is easy to apply for now either through code locking or hardware locking. While the second point must use a command code that can keep private keys into new unique code. The possibility of these transactions can use smart contract orders, so there are no 2x fees. But clearly, the private key on the wallet address becomes a new code that is difficult to solve.

deisik

legendary

Activity: 3514

Merit: 1280

English ⬄ Russian Translation Services

Quote from: d5000 on February 08, 2019, 03:04:03 PM

Quote from: deisik on February 08, 2019, 03:47:52 AM

But I don't think that BIP70 solves the problem described (i.e. sending coins to nowhere) as it is assumed that you have to take some actions beforehand.

The buyer (i.e. the person who sends Bitcoins) doesn't have to do anything

That's not my point

The whole idea behind BIP70 (as I got it) consists in you wanting to buy something from someone who is ready and willing to send you an "invoice" (let's call this code so for simplicity's sake). Obviously, it limits the application of this scheme to a very specific and narrow use cases. That's likely the reason why support for BIP70 has been dropped as it is not something worth having at the protocol level

Quote from: d5000 on February 08, 2019, 03:04:03 PM

Quote

Why not add an option in a Bitcoin wallet to make an automatic check whether an address already exists on the blockchain? It looks like a simple but nevertheless effective solution

This doesn't help in two cases:
- when the payee wants the payer to transfer coins to a new address (which is the default behaviour of many wallets, including Bitcoin Core and Electrum)
- when the payer mistypes the address, but the address exists

In the latter case it actually helps a lot as it allows you to see the balance of the wallet and understand that something is probably wrong and you likely sending your coins to a wrong destination

pat4cryptoreal

full member

Activity: 630

Merit: 102

This will not profound solution to cryptocurrency theft. As security level goes higher the hackers also upgrade their hacking techniques. The solution is just to be careful and security conscious.

prasad87

jr. member

Activity: 242

Merit: 7

What you don't seem to understand is that "once reversible" transactions will always be reversible. How do you determine who has the authority to reverse transactions? What gives you the confidence that once a precedent is there, you won't see "reversals" for "moral" reasons like wealth distribution and other garbage?

qtronix

member

Activity: 596

Merit: 10

I think that these innovations could help us somehow from hacker attacks. I like the idea of reversibility. But in this case it is necessary to think over everything very well, because it seems to me that many will be against it.

d5000

legendary

Activity: 3906

Merit: 6249

Decentralization Maximalist

Quote from: deisik on February 08, 2019, 03:47:52 AM

But I don't think that BIP70 solves the problem described (i.e. sending coins to nowhere) as it is assumed that you have to take some actions beforehand.

The buyer (i.e. the person who sends Bitcoins) doesn't have to do anything - (s)he must only paste the code provided by the merchant to the wallet. Bitcoin Core and Electrum support it out of the box, although usability could be improved. And I read recently that Bitcoin Core has deprecated BIP70 (maybe as consequence/part of the conflict between Bitcoin Core and BitPay?) in favour of BIP20, which offers a somewhat similar but significantly weaker protection against mistyping (address "hijacking" is possible).

For merchants there should be automated solutions to generate the message for the buyer, but I don't know which wallets support that out of the box.

Quote

Why not add an option in a Bitcoin wallet to make an automatic check whether an address already exists on the blockchain? It looks like a simple but nevertheless effective solution

This doesn't help in two cases:
- when the payee wants the payer to transfer coins to a new address (which is the default behaviour of many wallets, including Bitcoin Core and Electrum)
- when the payer mistypes the address, but the address exists.
As far as I know, address mistyping is very improbable because of Bitcoin's address format, and even more so with the bech32 (Segwit) format. But it's a very common fear people without technical background cite when they are asked to name the hurdles to use Bitcoin. So BIP70-like solutions are definitively necessary for Bitcoin to become mainstream.

deisik

legendary

Activity: 3514

Merit: 1280

English ⬄ Russian Translation Services

Quote from: d5000 on February 07, 2019, 02:02:22 PM

For these reasons, for the mistyping problem I think BIP70 is much more appropiated. In BIP70, the receiver first sends a message to the emittant of the transaction, which does not only provide the address to send to, but also the name of the business. So when you send a BIP70 transaction to Bitpay (Bitpay is the entity that mostly uses BIP70), you can't mistype or send the TX to the wrong person because the transaction then would be invalid.

See BIP70 here: https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki

Thanks for taking an effort to explain this to me

But I don't think that BIP70 solves the problem described (i.e. sending coins to nowhere) as it is assumed that you have to take some actions beforehand. It is more like a crutch or a solution for a specific case which doesn't solve the issue in general, conceptually. I think it was in fact an effort to make up for this shortcoming of Bitcoin but not a very effective one. Why not add an option in a Bitcoin wallet to make an automatic check whether an address already exists on the blockchain? It looks like a simple but nevertheless effective solution

Freny250

copper member

Activity: 307

Merit: 1

Hacks are not what comes by easily. Most hacks comes mostly on a centralized exchange where you have no control of your private key. But in decentralised exchange you can monitor and control your funds . Using a reversible transaction i belive will be contrary to the main concept of blockchain

deisik

legendary

Activity: 3514

Merit: 1280

English ⬄ Russian Translation Services

Quote from: ?? on ??

Quote from: deisik on February 04, 2019, 11:23:52 AM

As an extension to this basic feature, it could be beneficial to create a white list of addresses where the coins can be sent to during this lock time

Good idea, the only problem is adding another OP codes (which allow spend Bitcoin if the transaction output only contain address on the script) for unlocking script. Hard-fork might be needed in this case

And this also seems to be an effective solution to the problem of stolen keys

I didn't even know that I already came up with that solution in the OP. Basically, when locking an address you can add a white list of addresses where coins can be moved during the lock time, so even if the private key from this wallet gets stolen or otherwise compromised, you can still safely move your coins to one of these "backup" addresses. I guess this will be useful for a lot of cold wallets out there (and their owners)

d5000

legendary

Activity: 3906

Merit: 6249

Decentralization Maximalist

Quote from: deisik on February 07, 2019, 01:34:54 PM

First, how is that solution better (worse) overall than what franky(stein) offers? I mean a 1-of-2 multisig?

If I understood it the right way, in franky's design there's no timelock involved. So while Bob does not move the funds, Alice can move it back.

If franky's design involves a timelock, then the designs are roughly equivalent.

Quote

And second, is it possible to set it as a default mode in wallets like Electrum (or even Bitcoin's vanilla wallet)? Or is it more like you can't mistype an address simply because you have to set it up first to make a transaction with it? If this is not the case, then what are the shortcomings of making it a default mode of operation (in simple terms)?

I think there are two reasons:
- first, it occupies more space on the blockchain as the multisig transaction is larger, and additionally you would have to move the money with a second transaction, so your transaction fees would be at least doubled;
- second, to send the secret via another channel requires you to set up this channel. I don't know currently a wallet that includes this feature (it would need access to your email address or an instant messaging protocol).

For these reasons, for the mistyping problem I think BIP70 is much more appropiated. In BIP70, the receiver first sends a message to the emittant of the transaction, which does not only provide the address to send to, but also the name of the business. So when you send a BIP70 transaction to Bitpay (Bitpay is the entity that mostly uses BIP70), you can't mistype or send the TX to the wrong person because the transaction then would be invalid.

See BIP70 here: https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki

munareal

full member

Activity: 644

Merit: 102

I am more for the second option creating an option for a reversible transaction. Transactions on cryptocurrencies that will not be successful until when confirmed. This will go a long way to curb hacking of cryptocurrencies.

tetyulfania

member

Activity: 653

Merit: 10

Only one way how to know about exchange market was hacked is by checking condition or exchange owner, they have know more about their exchange and we will see the owner of exchange will rich or not after his exchange was hacked.

deisik

legendary

Activity: 3514

Merit: 1280

English ⬄ Russian Translation Services

Quote from: d5000 on February 07, 2019, 01:22:02 PM

Quote from: deisik on February 07, 2019, 01:03:18 PM

But with this setup will I (as that Bob in your post) be able to retrieve my money if Alice doesn't spend it (I mean after I send her the secret)? The point is to protect your dough from sending it to a wrong address or even a non-existing address.

Yes, because the transaction contains also a CheckLockTimeVerify (CLTV) timelock. I should have clarified that better.

When the timelock expires, Alice can spend the money again.

In reality, it's a bit complicated - Alice's transaction has two "alternative" outputs, one that authorizes Alice [the sender] to move the funds after the timelock expired, and the other one that authorizes Bob to move the funds when he provides the secret. If Bob doesn't provide the secret in time, Alice is able to move the funds back. But if she doesn't, then Bob can still move the funds (but that's no danger because he must know the secret).

So yes, this setup can be a solution for mistyped addresses. However, in this case, I would prefer to use the BIP70 payment protocol, which avoids mistyping without the hassle of a HTLC

Okay then. But I have two questions

First, how is that solution better (worse) overall than what franky(stein) offers? I mean a 1-of-2 multisig? And second, is it possible to set it as a default mode in wallets like Electrum (or even Bitcoin's vanilla wallet)? Or is it more like you can't mistype an address simply because you have to set it up first to make a transaction with it? If this is not the case, then what are the shortcomings of making it a default mode of operation (in simple terms)? From my perspective, it makes perfect sense in order to avoid losing money

c_atlas

member

Activity: 140

Merit: 56

As others have said, thefts mostly occur in major exchange hacks (in which case it wouldn't matter if you had a transaction where you send the receiver a question and they answer correctly, i.e "confirm it" since both the sender and receiver would be the hacker). Further, if an exchange is storing their funds they probably don't want to lower their liquidity (and perhaps their reputation with users) by locking users funds with CLTV. What if people want to withdraw? If you need to dip into your cold storage (which is locked for the next n weeks) what will you tell users?

Hacks on individual people's addresses, or sending to the wrong address are very unlikely these days because you're unlikely to be manually typing out addresses. Sure there are instances where malware can change the result of a copy/pasted address, but this can be fixed by just double checking the addresses you're sending to.

d5000

legendary

Activity: 3906

Merit: 6249

Decentralization Maximalist

Quote from: deisik on February 07, 2019, 01:03:18 PM

But with this setup will I (as that Bob in your post) be able to retrieve my money if Alice doesn't spend it (I mean after I send her the secret)? The point is to protect your dough from sending it to a wrong address or even a non-existing address.

Yes, because the transaction contains also a CheckLockTimeVerify (CLTV) timelock. I should have clarified that better.

When the timelock expires, Alice can spend the money again.

In reality, it's a bit complicated - Alice's transaction has two "alternative" outputs, one that authorizes Alice [the sender] to move the funds after the timelock expired, and the other one that authorizes Bob to move the funds when he provides the secret. If Bob doesn't provide the secret in time, Alice is able to move the funds back. But if she doesn't, then Bob can still move the funds (but that's no danger because he must know the secret).

So yes, this setup can be a solution for mistyped addresses. However, in this case, I would prefer to use the BIP70 payment protocol, which avoids mistyping without the hassle of a HTLC.

deisik

legendary

Activity: 3514

Merit: 1280

English ⬄ Russian Translation Services

Quote from: d5000 on February 07, 2019, 12:29:40 PM

Quote from: deisik on February 04, 2019, 11:23:52 AM

Basically, you send money to someone but they won't be able to receive it without a protection code which you send them separately (or tell in person). Thus, if no code is provided on time, the transaction gets canceled.

This is basically how atomic swaps work presently. It's one of the forms of the already mentioned "HTLCs" (hashed timelock contracts).

Your setup could work this way:

- Alice sends a transaction to Bob containing a timelock and the condition to provide a secret S to spend the funds (this includes a hash of S)
- Bob must provide the secret to move it. Once Alice is sure that Bob is really Bob, she provides Bob the secret (e.g. via an encrypted email).

In atomic swaps, the secret is provided only when the other party has also transferred the funds (the setup is even a bit more complicated, see https://en.bitcoin.it/wiki/Atomic_swap), but you don't need that in your setup, as all you want is that the other party needs to provide information received from two different channels (1 - the transaction, 2 - the secret)

Yeah, I know (more or less) what atomic swaps are

But with this setup will I (as that Bob in your post) be able to retrieve my money if Alice doesn't spend it (I mean after I send her the secret)? The point is to protect your dough from sending it to a wrong address or even a non-existing address. A lot of people lost their coins for making a mistake in typing the address. Yeah, I also know that you can't use certain characters which can cause such spelling mistakes like I and l (the first is a capital i, while the second is a lowercase L), but the idea of losing money just because you make a stupid mistake doesn't sit quite well with me

cizatext

member

Activity: 952

Merit: 41

Your second option and suggestion is OK by me, for transactions to auto reverse if not confirmed by the receiver I think if that option is added it will be OK. But your first point is where am finding hard to understand do you mean a wallet that received certain amount of bitcoin should be locked for some time before the owner is able to send it out, in that way we will not have the fast transactions rate that we always look forward in bitcoin.

Topic: On reversible transactions (Read 594 times)