Bitcoin Forum
October 18, 2018, 02:06:00 AM *
News: Make sure you are not using versions of Bitcoin Core other than 0.17.0 [Torrent], 0.16.3, 0.15.2, or 0.14.3. More info.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Time-based crypto container on Bitcoin blockchain?  (Read 1531 times)
-Greed-
Hero Member
*****
Offline Offline

Activity: 910
Merit: 1000


Decentralized Jihad


View Profile
November 13, 2014, 08:16:28 AM
 #1

I wonder if it's possible to make some kind of crypto container using blockchain technology which I can only decrypt after sometime (eg. 1 year). I know there are some methods depending on Moore's law and weak cryptography but this is not what I need. In brief, I'd like to have a time capsule.

1539828360
Hero Member
*
Offline Offline

Posts: 1539828360

View Profile Personal Message (Offline)

Ignore
1539828360
Reply with quote  #2

1539828360
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1539828360
Hero Member
*
Offline Offline

Posts: 1539828360

View Profile Personal Message (Offline)

Ignore
1539828360
Reply with quote  #2

1539828360
Report to moderator
1539828360
Hero Member
*
Offline Offline

Posts: 1539828360

View Profile Personal Message (Offline)

Ignore
1539828360
Reply with quote  #2

1539828360
Report to moderator
Elwar
Legendary
*
Offline Offline

Activity: 2618
Merit: 1257


www.varyon.io


View Profile WWW
November 13, 2014, 08:45:59 AM
 #2

There are ways to add time delays to a transaction but from everything I have seen you have to run the client the whole time.

I checked into it a while ago, basically you can add code to a transaction but the code lives on your wallet and executes only if that wallet is running (there is more to it but that was the high level impression I got out of it).

                     ▄▓▓▓▓    ▄▓█▓▄
                  ▄▓██████    ██████▓▄
                ▐████████▓    ▓████████▌
            ▄▓▓▄ ▀██▓▀▀▀         ▀▀▓██▓ ▄▓▓▄
         ▄▓█████▌ ▄▄▓▓██▓▌     ▓██▓▓▄▄ ▐█████▓▄
       ▓███████▀▄▓███████▌    ▐███████▓▄▀▓██████▓
       ▓█████▓ ▓█████████▌     █████████▓ ▓█████▓
               ▀▓████████      █████████▓
     ▄▄             ▀▀▀▀▀       ▀▀▀▀             ▄▄
    ▓████▓▓                                  ▄▓█████
    ▐██████ ▄▓█▓▓▄▄                   ▄▄▓▓▓▓ ██████▌
     ▓█████ ████████▓▓            ▄▓████████ █████▓
      ▓███▓ █████████▓            ▓█████████ ▓████
            ▀███████▀               ▓██████▀
        ▓███▓ ▓███▓      ▄▓██▓▄      ▓███▓ ▓███▓
        ▓█████▄        ▄▓██████▓▄        ▄▓████▓
         ██████▓      ▓██████████▓      ▐██████
         ▐████▓       ▀▓████████▓▀       ▓████▌
           ▀▀▀    ▄▓██▓▓▄▄ ▀▀ ▄▄▓▓███▓     ▀▀▀
                 ▓█████████  ██████████▄
                 ▓▓██████▓▓  ▀▓██████▓▓
██
██
██
██
██
██
██
██
██
██
██
██
██
██
.......Social Media.......
██▄▓█████████████████████▓▓▄
▓██████████████████████████▌
███████████████████▓▓▀  ▓██▌
██████████████▓▀▀       ▓██▌
████████▓▀▀      ▄█    ▐███▌
███▓▀        ▄▄▓▀      ▓███▌
███▓▄▄▄   ▄▓█▓         ████▌
████████▓ ▓▌          ▓████▌
█████████▓    ▄       █████▌
██████████▌ ▄▓██▓▄   ▐█████▌
███████████████████▓▓██████▌
▐██████████████████████████
  ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
▄███████████████████▄
██████████████████████▌
██████████████████████▌
████████████     █▀███▌
███   █████        ▐██▌
███               ▐███▌
███               ████▌
████             █████▌
█████▄▄         ██████▌
████         ▄████████▌
██████████████████████▌
██████████████████████▌
██
██
██
██
██
██
██
██
CIYAM
Legendary
*
Offline Offline

Activity: 1876
Merit: 1000


Ian Knowles - CIYAM Lead Developer


View Profile WWW
November 13, 2014, 08:49:19 AM
 #3

@Elwar

You are probably referring to nLockTime and yes the issue is that nLockTime txs whose time (or block) is in the future are not accepted by peers (so your client would have to re-broadcast the tx after that point in time).

It still has some value in that the tx could be manually sent to another person (thus acting like a last will) provided that they eventually broadcast in order to make sure the transfer actually happens.

@OP - this of course has nothing to do with encryption (as Bitcoin doesn't encrypt anything).

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
Vessko
Full Member
***
Offline Offline

Activity: 139
Merit: 100



View Profile
November 13, 2014, 09:03:17 AM
 #4

Time-lock encryption is a fiendishly difficult problem but there are various possible solutions. For a short overview, see, for instance, Time-lock encryption.
Elwar
Legendary
*
Offline Offline

Activity: 2618
Merit: 1257


www.varyon.io


View Profile WWW
November 13, 2014, 09:15:19 AM
 #5

@Elwar

You are probably referring to nLockTime and yes the issue is that nLockTime txs whose time (or block) is in the future are not accepted by peers (so your client would have to re-broadcast the tx after that point in time).

It still has some value in that the tx could be manually sent to another person (thus acting like a last will) provided that they eventually broadcast in order to make sure the transfer actually happens.

Yes, that is what I was talking about. This would actually make a pretty good Bitcoin service.

                     ▄▓▓▓▓    ▄▓█▓▄
                  ▄▓██████    ██████▓▄
                ▐████████▓    ▓████████▌
            ▄▓▓▄ ▀██▓▀▀▀         ▀▀▓██▓ ▄▓▓▄
         ▄▓█████▌ ▄▄▓▓██▓▌     ▓██▓▓▄▄ ▐█████▓▄
       ▓███████▀▄▓███████▌    ▐███████▓▄▀▓██████▓
       ▓█████▓ ▓█████████▌     █████████▓ ▓█████▓
               ▀▓████████      █████████▓
     ▄▄             ▀▀▀▀▀       ▀▀▀▀             ▄▄
    ▓████▓▓                                  ▄▓█████
    ▐██████ ▄▓█▓▓▄▄                   ▄▄▓▓▓▓ ██████▌
     ▓█████ ████████▓▓            ▄▓████████ █████▓
      ▓███▓ █████████▓            ▓█████████ ▓████
            ▀███████▀               ▓██████▀
        ▓███▓ ▓███▓      ▄▓██▓▄      ▓███▓ ▓███▓
        ▓█████▄        ▄▓██████▓▄        ▄▓████▓
         ██████▓      ▓██████████▓      ▐██████
         ▐████▓       ▀▓████████▓▀       ▓████▌
           ▀▀▀    ▄▓██▓▓▄▄ ▀▀ ▄▄▓▓███▓     ▀▀▀
                 ▓█████████  ██████████▄
                 ▓▓██████▓▓  ▀▓██████▓▓
██
██
██
██
██
██
██
██
██
██
██
██
██
██
.......Social Media.......
██▄▓█████████████████████▓▓▄
▓██████████████████████████▌
███████████████████▓▓▀  ▓██▌
██████████████▓▀▀       ▓██▌
████████▓▀▀      ▄█    ▐███▌
███▓▀        ▄▄▓▀      ▓███▌
███▓▄▄▄   ▄▓█▓         ████▌
████████▓ ▓▌          ▓████▌
█████████▓    ▄       █████▌
██████████▌ ▄▓██▓▄   ▐█████▌
███████████████████▓▓██████▌
▐██████████████████████████
  ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
▄███████████████████▄
██████████████████████▌
██████████████████████▌
████████████     █▀███▌
███   █████        ▐██▌
███               ▐███▌
███               ████▌
████             █████▌
█████▄▄         ██████▌
████         ▄████████▌
██████████████████████▌
██████████████████████▌
██
██
██
██
██
██
██
██
-Greed-
Hero Member
*****
Offline Offline

Activity: 910
Merit: 1000


Decentralized Jihad


View Profile
November 13, 2014, 10:03:45 AM
 #6

@Elwar @CIYAM
I found nLockTime interesting but it has some issues. As far as I understand a tx with nLockTime may be lost (it's stored in mempool and not included in the blockchain) if mempools of nodes, my client broadcasted to, were wiped. So such method can't be used for long-term savings (I want to keep myself from spending some BTC for a long time).

@Vessko
Thanks for the link. I will look into it.

CIYAM
Legendary
*
Offline Offline

Activity: 1876
Merit: 1000


Ian Knowles - CIYAM Lead Developer


View Profile WWW
November 13, 2014, 10:53:45 AM
 #7

As far as I understand a tx with nLockTime may be lost (it's stored in mempool and not included in the blockchain) if mempools of nodes, my client broadcasted to, were wiped.

I think you'll find it's actually worse than that (from what I recall reading it won't be included in the mempool of peers at all unless you are running "testnet").

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
The00Dustin
Hero Member
*****
Offline Offline

Activity: 807
Merit: 500


View Profile
November 13, 2014, 10:59:42 AM
 #8

@Elwar @CIYAM
I found nLockTime interesting but it has some issues. As far as I understand a tx with nLockTime may be lost (it's stored in mempool and not included in the blockchain) if mempools of nodes, my client broadcasted to, were wiped. So such method can't be used for long-term savings (I want to keep myself from spending some BTC for a long time).
While I haven't done any investigation, I am assuming that it is possible to export a signed raw transaction with the nLockTime setting encoded in it.  I am also assuming that the signature covers nLockTime so that it cannot be manipulated.  Otherwise, this wouldn't make sense:
It still has some value in that the tx could be manually sent to another person (thus acting like a last will) provided that they eventually broadcast in order to make sure the transfer actually happens.
Specifically because of this:
You are probably referring to nLockTime and yes the issue is that nLockTime txs whose time (or block) is in the future are not accepted by peers (so your client would have to re-broadcast the tx after that point in time).
In other words, assuming I'm right, once you generate and export a signed nLockTime transaction, it can be distributed to multiple parties, any one of whom can execute it after the time has expired.  However, in the meantime, the funds would not really be locked.  That is to say that if you wanted to cancel the scheduled transaction, you would only need to make a new transaction right now to move coins from the input that is scheduled to be used, however, it also means that if your private keys were hacked/stolen, the funds could still be stolen (ETA: immediately).

ETA: I know this still isn't what you want, but it isn't what you want because you want to lock yourself out, while you indicated it wasn't what you wanted because the transaction could be lost (presumably by the software closing).
CIYAM
Legendary
*
Offline Offline

Activity: 1876
Merit: 1000


Ian Knowles - CIYAM Lead Developer


View Profile WWW
November 13, 2014, 11:03:16 AM
 #9

@The00Dustin

Yup - I think you have understood it correctly - so it doesn't really "lock funds" at all - but instead can "unlock them" assuming they weren't spent in the meantime.

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
CIYAM
Legendary
*
Offline Offline

Activity: 1876
Merit: 1000


Ian Knowles - CIYAM Lead Developer


View Profile WWW
November 13, 2014, 11:04:58 AM
 #10

There is a system (which I created some time back) that could easily be able to do part of what the OP is wanting to do (still not encrypting - but proper time locking).

It's called AT (http://ciyam.org/at) and in particular read the "Dormant Funds Transfer" use case (http://ciyam.org/at/at_dormant.html).

Unfortunately although I created a 20 BTC "bounty" to implement AT on a Bitcoin clone (https://bitcointalk.org/index.php?topic=826263.0) there hasn't been much interest from devs so far (it is being currently implemented for Qora which is a separate blockchain altogether).

I am not sure whether Ethereum can do this (although presumably it could) so you might also want to look into that (as it is now being used by Counterparty which does actually sit on top of Bitcoin).

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
Flashman
Hero Member
*****
Offline Offline

Activity: 518
Merit: 500


Hodl!


View Profile
November 13, 2014, 11:19:56 AM
 #11

Counterparty just ported the entire Ethereum command language to Bitcoin, so whatever that could do, now bitcoin can.

TL;DR See Spot run. Run Spot run. .... .... Freelance interweb comedian, for teh lulz >>> 1MqAAR4XkJWfDt367hVTv5SstPZ54Fwse6

Bitcoin Custodian: Keeping BTC away from weak heads since Feb '13, adopter of homeless bitcoins.
CIYAM
Legendary
*
Offline Offline

Activity: 1876
Merit: 1000


Ian Knowles - CIYAM Lead Developer


View Profile WWW
November 13, 2014, 12:43:08 PM
 #12

For the encryption part I don't think that Ethereum can actually help, however, there is a new "proof" that I have been developing (can't go into details as I am getting a math guy to evaluate it for any unforeseen attack vectors and to provide it with a more formal analysis before creating a white paper) that when combined with Shamir's Secret Sharing could go a long way towards providing *exactly* what you are after.

It would not be a "trustless" solution, however, it would only require trusting say X out of Y parties (not sure what the limits of X and Y are with Shamir's offhand) such that X do not conspire together (to break the time-lock) or Y - X do not stop creating new blocks (making the time-lock locked forever).

The "time" would not be exact but would likely occur within a pretty reasonable tolerance.

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
-Greed-
Hero Member
*****
Offline Offline

Activity: 910
Merit: 1000


Decentralized Jihad


View Profile
November 14, 2014, 09:12:47 AM
 #13

@The00Dustin
Well, now I see that nLockTime is pretty useless for my aim.

@CIYAM
You made a great system. I will check it out when some coin integrates it.

@Flashman
I will be glad to see an example of delayed (time-lock) transaction. Unfortunately, I haven't found anything about it on the XCP wiki.

Pages: [1]
  Print  
 
Jump to:  

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!