Bitcoin Forum
February 23, 2019, 01:46:57 AM *
News: Latest Bitcoin Core release: 0.17.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 [2] 3 »  All
  Print  
Author Topic: On reversible transactions  (Read 255 times)
ePesoInitiative
Sr. Member
****
Offline Offline

Activity: 644
Merit: 250



View Profile WWW
February 04, 2019, 09:23:33 PM
 #21

But what I suggest should be done on the protocol level. This feature will also prevent you from sending your coins to a wrong address by mistake. If you make such a mistake, whether the receiving address actually exists or not won't matter as your coins will come back to you after the grace period is over. Honestly, I don't understand why we don't have such a system already implemented


This can be done by Smart Contracts I believe. The contract will keep the sent coins locked for a grace period unless the recipient sends a confirmation TX. No confirmation after a time, the coins will return to the sendee.


                    ▓██████████████████████████████████████████████████▓░     
                    ▓██████████████████████████████████████████████████░░     
                    ▓█████████████████████████████████████████████████░       
                    ▓████████████████████████████████████████████████▒░       
                    ▓████████████████████████████████████████████████         
                    ▓███████████████████████████████████████████████░ 
         
                     ░░ ██████████████████████████▓               ░ ░░         
                          ░▓█████████████████████████▓░░             
           
        ███████████████████████████████████████████████████░░                   
       ▒██████████████████████████████████████████████████                     
       ░██████████████████████████████████████████████████                     
        ░█████████████████████████████████████████████████                     
        ░░████████████████████████████████████████████████                     
        ░░████████████████████████████████████████████████                     
          ░███████████████████████████████████████████████░░ 
                 
                        ░░░██████████████████████████▓░                       
                     ░░██████████████████████████▒░
                           
                    ▓███████████████████████████████████████████████████░     
                    ▓██████████████████████████████████████████████████░       
                    ▓█████████████████████████████████████████████████░       
                    ▓█████████████████████████████████████████████████░       
                    ▓████████████████████████████████████████████████░░       
                   ░▓███████████████████████████████████████████████░         
                                                                               
                                                                   
██▀
▐▌
▐║
▐║
▐▌
██▄
▀██
▐▌
║▌
║▌
▐▌
▄██
─── SOCIAL MEDIA ───
Facebook Twitter  Github 
Telegram  Medium  Reddit
1550886417
Hero Member
*
Offline Offline

Posts: 1550886417

View Profile Personal Message (Offline)

Ignore
1550886417
Reply with quote  #2

1550886417
Report to moderator
1550886417
Hero Member
*
Offline Offline

Posts: 1550886417

View Profile Personal Message (Offline)

Ignore
1550886417
Reply with quote  #2

1550886417
Report to moderator
Your Bitcoin transactions
The Ultimate Bitcoin mixer
made truly anonymous.
with an advanced technology.
Mix coins
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1550886417
Hero Member
*
Offline Offline

Posts: 1550886417

View Profile Personal Message (Offline)

Ignore
1550886417
Reply with quote  #2

1550886417
Report to moderator
deisik
Legendary
*
Offline Offline

Activity: 1834
Merit: 1089


Free crypto every day here: discord.gg/pXB9nuZ


View Profile
February 04, 2019, 09:33:01 PM
 #22

On the flip side, though, there is another catch here. For example, it becomes known that the keys have been compromised, but the hacker can't steal the coins as it has a timer counting. So how can a legitimate owner claim his coins and not let the hacker claim them before him? That's an interesting implication which I didn't think of when starting this thread

I think there would be no way to do that. Once the countdown ended, they both would try to send the coins to another address at the same time, so the only way the legitimate owner could keep his coins would be by spending a higher fee than the hacker and being lucky

That's what I think myself

However, there can be a way out, something like a fallback plan. For example, you can also add an encrypted variable with a password known only to you, which you set at the moment you lock the address. It would allow you to stop the timer prematurely and thus claim the coins back immediately. I know you are going to say that it can be stolen too, but it is a one-off variable which is used only to stop the timer, so you don't need to save it anywhere but in your head only (read, it is not the same as your private key)



      ▄████████████▄
    ▄████████████████▄
   ██████▀       ▀████▄       ▄▄                 ▄▄▄
  █████           █████    ▐████                ▐████
 ██████         ▄█████     ████▌                █████
 ██████         █████     ▐████  ▄▄▄           ▐████▌   ▄██▄
  ██████▄               ▄▄██████████           █████  ▄████▀
   ████████▄       ▄▄█████████████▀  ▄▄▄▄      ████▌▄████▀  ▄▄████▄
     ▀█████████▄   ███████████▀▀  ▄████████▄  ▐████████▀  ▄█████████
        ▀█████████▄ ▀▀▀ ▐████▌   █████▀ ████  ███████▀   █████▀ ▀███
      ▄▄▄   ▀███████▄   █████   █████  ▄███  ▐███████   █████  ▄███▀
   ▄██████     ▀█████  ▐████▌   ████   ████  ████████▄  ████████▀
  ██████▀       █████  █████  ▄█████ ▄█████▄██████████▄ ▀█████  ▄██▄
 █████▀        ▄█████  ▐██████████████████████████ ████▄ ▀█████████▀       ▄████▄  ▄████▄  ██▄██▄██▄
 █████       ▄▄█████▀   ▀▀███▀   ▀▀██▀  ▀██▀ ▀██▀   ████▄  ▀▀▀▀▀▀ ▄▄      ██▀     ██▀  ▀██ ██  ██  ██
 ██████▄▄▄████████▀                                  █████▄▄▄▄▄▄████ ▄██▄ ██▄     ██▄  ▄██ ██  ██  ██
  ▀█████████████▀                                     ▀▀█████████▀▀  ▀██▀  ▀████▀  ▀████▀  ██  ██  ██
    ▀▀█████▀▀


██
██
██
██
██
██
██
██
██
██
██

             ▄▄▄▄▀▀▀▀▄
     ▄▄▄▄▀▀▀▀        ▀▄▄▄▄
▄▀▀▀▀                 █   ▀▀▀▀▀▀▀▄▄
█   ▄▀▀▄              ▀▄          █
 █  █▀▀█    ██▄        █          █
 ▀▄        ▐████▄       █        █
  █        ███████▄     ▀▄       █
   █      ▐████████      █       █
   ▀▄      ▀██████▌       █     █
    █        ▀████        ▀▄    █
     █         ▀█▌   █▄▄█  █    █
     ▀▄              ▀▄▄▀   █  █
      █                 ▄▄▄▀▀  █
       █        ▄▄▄▄▀▀▀▀       █
       ▀▄▄▄▄▀▀▀▀   ▀▀▀▀▀▀▄▄▄▄▄▄▀


██
██
██
██
██
██
██
██
██
██
██



██
██
██
██
██
██
██
██
██
██
██


«
«
«

»
»
»
squatter
Hero Member
*****
Offline Offline

Activity: 1036
Merit: 710


STOP SNITCHIN'


View Profile
February 04, 2019, 09:44:52 PM
 #23

What is the difference between your suggest and using OP_CHECKLOCKTIMEVERIFY (OP_HOD ?

Or using Hashed Timelock Contracts (HTLCs) ?

That's the closest we have to the OP's first idea ("frozen addresses"), yes. I'm pretty sure I've seen this use case suggested before, but it doesn't seem particularly useful as an anti-hacking mechanism. If your private keys are compromised, then once the timelock is ending you're still just racing the attacker to spend the outputs and hoping your transaction gets confirmed first.

This feature should allow a transaction to expire (i.e. be reversed) unless the payee (i.e. the person you pay to and who is to receive the money) confirms it from their side.

You should use payment channels on Lightning then. Both counterparties need to sign a transactions before channel state can be updated. Otherwise, the last valid state can be broadcast to the blockchain.

franky1
Legendary
*
Online Online

Activity: 2324
Merit: 1378



View Profile
February 04, 2019, 10:10:58 PM
 #24

Okay then, probably it is exactly what I wanted to see in Bitcoin, though done in a different way (maybe, even in a more flexible way). So how can we prevent coins from being sent to a non-existent address? Well, not actually prevent them from being sent but rather being able to claim them back?

Perhaps, adding a variable (a timer) that would allow to claim the coins back if they don't get spent?

how multisig works
you both then make a separate private/public keys
1deisikr4nd0m4ddr355  \
                                     >=bc1qD31s1kfri3nd
1fr13ndr4nd0m4ddr355 /

you both can calculate that your random PUBLIC keys BOTH created the bc1qD31s1kfri3nd address and you can both confirm its a real address as you both calculated it separately
again neither of you know/provided the private keys to each other
but both have the public info to check the address is real.

..
as for a separate situation of just wanting to prevent people funding addresses they mistakenly mistyped/misspelled... there is no real way.
because if you start implementing a system where people can get coins out of an address that a person does not have a private key of.. then thats just going to cause alot of hacking.

the only way to stop this is to prevent typo's... NOT allow a way to get funds from addresses which people dont have priv keys for.. but just a way to double check with other parties that an address is actually an active address

I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER.
Please do your own research & respect what is written here as both opinion & information gleaned from experience. many people replying with insults but no on-topic content substance, automatically are 'facepalmed' and yawned at
d5000
Legendary
*
Offline Offline

Activity: 2002
Merit: 1356


Decentralization Maximalist


View Profile
February 07, 2019, 05:29:40 PM
Merited by ETFbitcoin (1)
 #25

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)



cizatext
Member
**
Offline Offline

Activity: 504
Merit: 35


View Profile
February 07, 2019, 06:02:18 PM
 #26

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.

deisik
Legendary
*
Offline Offline

Activity: 1834
Merit: 1089


Free crypto every day here: discord.gg/pXB9nuZ


View Profile
February 07, 2019, 06:03:18 PM
 #27

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



      ▄████████████▄
    ▄████████████████▄
   ██████▀       ▀████▄       ▄▄                 ▄▄▄
  █████           █████    ▐████                ▐████
 ██████         ▄█████     ████▌                █████
 ██████         █████     ▐████  ▄▄▄           ▐████▌   ▄██▄
  ██████▄               ▄▄██████████           █████  ▄████▀
   ████████▄       ▄▄█████████████▀  ▄▄▄▄      ████▌▄████▀  ▄▄████▄
     ▀█████████▄   ███████████▀▀  ▄████████▄  ▐████████▀  ▄█████████
        ▀█████████▄ ▀▀▀ ▐████▌   █████▀ ████  ███████▀   █████▀ ▀███
      ▄▄▄   ▀███████▄   █████   █████  ▄███  ▐███████   █████  ▄███▀
   ▄██████     ▀█████  ▐████▌   ████   ████  ████████▄  ████████▀
  ██████▀       █████  █████  ▄█████ ▄█████▄██████████▄ ▀█████  ▄██▄
 █████▀        ▄█████  ▐██████████████████████████ ████▄ ▀█████████▀       ▄████▄  ▄████▄  ██▄██▄██▄
 █████       ▄▄█████▀   ▀▀███▀   ▀▀██▀  ▀██▀ ▀██▀   ████▄  ▀▀▀▀▀▀ ▄▄      ██▀     ██▀  ▀██ ██  ██  ██
 ██████▄▄▄████████▀                                  █████▄▄▄▄▄▄████ ▄██▄ ██▄     ██▄  ▄██ ██  ██  ██
  ▀█████████████▀                                     ▀▀█████████▀▀  ▀██▀  ▀████▀  ▀████▀  ██  ██  ██
    ▀▀█████▀▀


██
██
██
██
██
██
██
██
██
██
██

             ▄▄▄▄▀▀▀▀▄
     ▄▄▄▄▀▀▀▀        ▀▄▄▄▄
▄▀▀▀▀                 █   ▀▀▀▀▀▀▀▄▄
█   ▄▀▀▄              ▀▄          █
 █  █▀▀█    ██▄        █          █
 ▀▄        ▐████▄       █        █
  █        ███████▄     ▀▄       █
   █      ▐████████      █       █
   ▀▄      ▀██████▌       █     █
    █        ▀████        ▀▄    █
     █         ▀█▌   █▄▄█  █    █
     ▀▄              ▀▄▄▀   █  █
      █                 ▄▄▄▀▀  █
       █        ▄▄▄▄▀▀▀▀       █
       ▀▄▄▄▄▀▀▀▀   ▀▀▀▀▀▀▄▄▄▄▄▄▀


██
██
██
██
██
██
██
██
██
██
██



██
██
██
██
██
██
██
██
██
██
██


«
«
«

»
»
»
d5000
Legendary
*
Offline Offline

Activity: 2002
Merit: 1356


Decentralization Maximalist


View Profile
February 07, 2019, 06:22:02 PM
 #28

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.

c_atlas
Jr. Member
*
Offline Offline

Activity: 40
Merit: 5


View Profile
February 07, 2019, 06:30:18 PM
 #29

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.
deisik
Legendary
*
Offline Offline

Activity: 1834
Merit: 1089


Free crypto every day here: discord.gg/pXB9nuZ


View Profile
February 07, 2019, 06:34:54 PM
 #30

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



      ▄████████████▄
    ▄████████████████▄
   ██████▀       ▀████▄       ▄▄                 ▄▄▄
  █████           █████    ▐████                ▐████
 ██████         ▄█████     ████▌                █████
 ██████         █████     ▐████  ▄▄▄           ▐████▌   ▄██▄
  ██████▄               ▄▄██████████           █████  ▄████▀
   ████████▄       ▄▄█████████████▀  ▄▄▄▄      ████▌▄████▀  ▄▄████▄
     ▀█████████▄   ███████████▀▀  ▄████████▄  ▐████████▀  ▄█████████
        ▀█████████▄ ▀▀▀ ▐████▌   █████▀ ████  ███████▀   █████▀ ▀███
      ▄▄▄   ▀███████▄   █████   █████  ▄███  ▐███████   █████  ▄███▀
   ▄██████     ▀█████  ▐████▌   ████   ████  ████████▄  ████████▀
  ██████▀       █████  █████  ▄█████ ▄█████▄██████████▄ ▀█████  ▄██▄
 █████▀        ▄█████  ▐██████████████████████████ ████▄ ▀█████████▀       ▄████▄  ▄████▄  ██▄██▄██▄
 █████       ▄▄█████▀   ▀▀███▀   ▀▀██▀  ▀██▀ ▀██▀   ████▄  ▀▀▀▀▀▀ ▄▄      ██▀     ██▀  ▀██ ██  ██  ██
 ██████▄▄▄████████▀                                  █████▄▄▄▄▄▄████ ▄██▄ ██▄     ██▄  ▄██ ██  ██  ██
  ▀█████████████▀                                     ▀▀█████████▀▀  ▀██▀  ▀████▀  ▀████▀  ██  ██  ██
    ▀▀█████▀▀


██
██
██
██
██
██
██
██
██
██
██

             ▄▄▄▄▀▀▀▀▄
     ▄▄▄▄▀▀▀▀        ▀▄▄▄▄
▄▀▀▀▀                 █   ▀▀▀▀▀▀▀▄▄
█   ▄▀▀▄              ▀▄          █
 █  █▀▀█    ██▄        █          █
 ▀▄        ▐████▄       █        █
  █        ███████▄     ▀▄       █
   █      ▐████████      █       █
   ▀▄      ▀██████▌       █     █
    █        ▀████        ▀▄    █
     █         ▀█▌   █▄▄█  █    █
     ▀▄              ▀▄▄▀   █  █
      █                 ▄▄▄▀▀  █
       █        ▄▄▄▄▀▀▀▀       █
       ▀▄▄▄▄▀▀▀▀   ▀▀▀▀▀▀▄▄▄▄▄▄▀


██
██
██
██
██
██
██
██
██
██
██



██
██
██
██
██
██
██
██
██
██
██


«
«
«

»
»
»
tetyulfania
Member
**
Offline Offline

Activity: 448
Merit: 10


View Profile
February 07, 2019, 06:44:20 PM
 #31

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.

ETFbitcoin
Legendary
*
Offline Offline

Activity: 1596
Merit: 1555

Use SegWit and enjoy lower fees.


View Profile WWW
February 07, 2019, 06:46:57 PM
 #32

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.

Second, we should make some transactions reversible, but please don't attack me before you actually listen me out. It is most certainly not what you think it is. This feature should allow a transaction to expire (i.e. be reversed) unless the payee (i.e. the person you pay to and who is to receive the money) confirms it from their side. This is how many online payment systems work (e.g. Yandex.Money). 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. Essentially the same thing can and should be implemented in Bitcoin

Aside from it's already possible with HTLC, if a transaction is reversed (the transaction is deleted or look like never happen), it would mess up Bitcoin consensus where block become invalid due to invalid block hash & previous block hash.

munareal
Full Member
***
Offline Offline

Activity: 532
Merit: 102


https://assetsplit.org/


View Profile WWW
February 07, 2019, 06:54:13 PM
 #33

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.

d5000
Legendary
*
Offline Offline

Activity: 2002
Merit: 1356


Decentralization Maximalist


View Profile
February 07, 2019, 07:02:22 PM
Merited by deisik (1)
 #34

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

deisik
Legendary
*
Offline Offline

Activity: 1834
Merit: 1089


Free crypto every day here: discord.gg/pXB9nuZ


View Profile
February 07, 2019, 08:15:51 PM
 #35

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)



      ▄████████████▄
    ▄████████████████▄
   ██████▀       ▀████▄       ▄▄                 ▄▄▄
  █████           █████    ▐████                ▐████
 ██████         ▄█████     ████▌                █████
 ██████         █████     ▐████  ▄▄▄           ▐████▌   ▄██▄
  ██████▄               ▄▄██████████           █████  ▄████▀
   ████████▄       ▄▄█████████████▀  ▄▄▄▄      ████▌▄████▀  ▄▄████▄
     ▀█████████▄   ███████████▀▀  ▄████████▄  ▐████████▀  ▄█████████
        ▀█████████▄ ▀▀▀ ▐████▌   █████▀ ████  ███████▀   █████▀ ▀███
      ▄▄▄   ▀███████▄   █████   █████  ▄███  ▐███████   █████  ▄███▀
   ▄██████     ▀█████  ▐████▌   ████   ████  ████████▄  ████████▀
  ██████▀       █████  █████  ▄█████ ▄█████▄██████████▄ ▀█████  ▄██▄
 █████▀        ▄█████  ▐██████████████████████████ ████▄ ▀█████████▀       ▄████▄  ▄████▄  ██▄██▄██▄
 █████       ▄▄█████▀   ▀▀███▀   ▀▀██▀  ▀██▀ ▀██▀   ████▄  ▀▀▀▀▀▀ ▄▄      ██▀     ██▀  ▀██ ██  ██  ██
 ██████▄▄▄████████▀                                  █████▄▄▄▄▄▄████ ▄██▄ ██▄     ██▄  ▄██ ██  ██  ██
  ▀█████████████▀                                     ▀▀█████████▀▀  ▀██▀  ▀████▀  ▀████▀  ██  ██  ██
    ▀▀█████▀▀


██
██
██
██
██
██
██
██
██
██
██

             ▄▄▄▄▀▀▀▀▄
     ▄▄▄▄▀▀▀▀        ▀▄▄▄▄
▄▀▀▀▀                 █   ▀▀▀▀▀▀▀▄▄
█   ▄▀▀▄              ▀▄          █
 █  █▀▀█    ██▄        █          █
 ▀▄        ▐████▄       █        █
  █        ███████▄     ▀▄       █
   █      ▐████████      █       █
   ▀▄      ▀██████▌       █     █
    █        ▀████        ▀▄    █
     █         ▀█▌   █▄▄█  █    █
     ▀▄              ▀▄▄▀   █  █
      █                 ▄▄▄▀▀  █
       █        ▄▄▄▄▀▀▀▀       █
       ▀▄▄▄▄▀▀▀▀   ▀▀▀▀▀▀▄▄▄▄▄▄▀


██
██
██
██
██
██
██
██
██
██
██



██
██
██
██
██
██
██
██
██
██
██


«
«
«

»
»
»
Freny250
Copper Member
Newbie
*
Offline Offline

Activity: 33
Merit: 0


View Profile
February 08, 2019, 02:50:20 AM
 #36

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
*
Offline Offline

Activity: 1834
Merit: 1089


Free crypto every day here: discord.gg/pXB9nuZ


View Profile
February 08, 2019, 08:47:52 AM
 #37

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



      ▄████████████▄
    ▄████████████████▄
   ██████▀       ▀████▄       ▄▄                 ▄▄▄
  █████           █████    ▐████                ▐████
 ██████         ▄█████     ████▌                █████
 ██████         █████     ▐████  ▄▄▄           ▐████▌   ▄██▄
  ██████▄               ▄▄██████████           █████  ▄████▀
   ████████▄       ▄▄█████████████▀  ▄▄▄▄      ████▌▄████▀  ▄▄████▄
     ▀█████████▄   ███████████▀▀  ▄████████▄  ▐████████▀  ▄█████████
        ▀█████████▄ ▀▀▀ ▐████▌   █████▀ ████  ███████▀   █████▀ ▀███
      ▄▄▄   ▀███████▄   █████   █████  ▄███  ▐███████   █████  ▄███▀
   ▄██████     ▀█████  ▐████▌   ████   ████  ████████▄  ████████▀
  ██████▀       █████  █████  ▄█████ ▄█████▄██████████▄ ▀█████  ▄██▄
 █████▀        ▄█████  ▐██████████████████████████ ████▄ ▀█████████▀       ▄████▄  ▄████▄  ██▄██▄██▄
 █████       ▄▄█████▀   ▀▀███▀   ▀▀██▀  ▀██▀ ▀██▀   ████▄  ▀▀▀▀▀▀ ▄▄      ██▀     ██▀  ▀██ ██  ██  ██
 ██████▄▄▄████████▀                                  █████▄▄▄▄▄▄████ ▄██▄ ██▄     ██▄  ▄██ ██  ██  ██
  ▀█████████████▀                                     ▀▀█████████▀▀  ▀██▀  ▀████▀  ▀████▀  ██  ██  ██
    ▀▀█████▀▀


██
██
██
██
██
██
██
██
██
██
██

             ▄▄▄▄▀▀▀▀▄
     ▄▄▄▄▀▀▀▀        ▀▄▄▄▄
▄▀▀▀▀                 █   ▀▀▀▀▀▀▀▄▄
█   ▄▀▀▄              ▀▄          █
 █  █▀▀█    ██▄        █          █
 ▀▄        ▐████▄       █        █
  █        ███████▄     ▀▄       █
   █      ▐████████      █       █
   ▀▄      ▀██████▌       █     █
    █        ▀████        ▀▄    █
     █         ▀█▌   █▄▄█  █    █
     ▀▄              ▀▄▄▀   █  █
      █                 ▄▄▄▀▀  █
       █        ▄▄▄▄▀▀▀▀       █
       ▀▄▄▄▄▀▀▀▀   ▀▀▀▀▀▀▄▄▄▄▄▄▀


██
██
██
██
██
██
██
██
██
██
██



██
██
██
██
██
██
██
██
██
██
██


«
«
«

»
»
»
d5000
Legendary
*
Offline Offline

Activity: 2002
Merit: 1356


Decentralization Maximalist


View Profile
February 08, 2019, 08:04:03 PM
 #38

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.

qtronix
Member
**
Offline Offline

Activity: 448
Merit: 10


View Profile
February 08, 2019, 11:59:17 PM
 #39

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.

▂ ▃ ▅ ▆   LUCRE ▬ DON'T HODL; TRADE!   ▆ ▅ ▃ ▂
✓ BITCOIN & CRYPTO CURRENCY ALGORITHMIC TRADING & SIGNAL SERVICE ✓ 
▌▐ ▬▬▬▬▬  Twitter ⬝  Telegram ⬝   Facebook ⬝  Youtube ⬝  Meduim   ▬▬▬▬▬ ▌▐
prasad87
Jr. Member
*
Offline Offline

Activity: 168
Merit: 7


View Profile
February 09, 2019, 12:01:01 AM
 #40

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?

Borderless trading with the Jarvis Exchanges.
Buy Apple stocks with Bitcoin. Jarvis.exchange (http://Jarvis.exchange)
Pages: « 1 [2] 3 »  All
  Print  
 
Jump to:  

Bitcointalk.org is not available or authorized for sale. Do not believe any fake listings.
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!