[IDEA] - LockMyCoins

[ripper234]

A cure for speculators - LockMyCoins™
(Just an idea, I don't have the time to develop it right now)

Client-side javascript that does the following:

1. Generates a new private/public key pair --> INCOMING_ADDRESS.
2. Accepts a RETURN_ADDRESS from the user.
3. When it detects an incoming transaction to INCOMING_ADDRESS, the service creates and broadcasts an nLockTime transaction 1 year into the future (configurable) to RETURN_ADDRESS.
4. When the browser window is closed, the private key is forgotten.

The purpose of the service is to allow someone to lock away a certain amount of coins for some time. This self-handicapping is done to prevent oneself from day-trading. It's meant for people who are long-term bitcoin bulls, and want to rest assured knowing their funds will be waiting for them in the future without being expose to the temptations of short term speculation and day-trading.

[1715644980]

1715644980

[1715644980]

1715644980

[1715644980]

1715644980

[1715644980]

1715644980

[600watt]

should include a five year and a 10 year option.

= solid retirement plan...   

[msc]

I'd rather just create a wallet, store the private keys in a safe, and watch the public addresses to know that the coins are actually there and in my possession.  Maybe you'll need them in an emergency, or maybe there will be a protocol change that requires a key rotation, etc.  Who knows?  Yes, it requires more will power, but only a little.

[ripper234]

I'd rather just create a wallet, store the private keys in a safe, and watch the public addresses to know that the coins are actually there and in my possession.  Maybe you'll need them in an emergency, or maybe there will be a protocol change that requires a key rotation, etc.  Who knows?  Yes, it requires more will power, but only a little.

Well yeah, this solution isn't for everyone - if your will is strong enough, move along.

Although ... one actual use for this would be insurance against rubber-hose cryptoanalysis:



If you physically can't deliver the coins except at pre-allocated times ... and suppose you make sure to keep these times secret (say ... your coins open once every year for a window of 1 day, and you keep the choice of day private) ... you can't be extorted to send away your coins at gunpoint.

[theonewhowaskazu]

I'd rather just create a wallet, store the private keys in a safe, and watch the public addresses to know that the coins are actually there and in my possession.  Maybe you'll need them in an emergency, or maybe there will be a protocol change that requires a key rotation, etc.  Who knows?  Yes, it requires more will power, but only a little.

Well yeah, this solution isn't for everyone - if your will is strong enough, move along.

Although ... one actual use for this would be insurance against rubber-hose cryptoanalysis:



If you physically can't deliver the coins except at pre-allocated times ... and suppose you make sure to keep these times secret (say ... your coins open once every year for a window of 1 day, and you keep the choice of day private) ... you can't be extorted to send away your coins at gunpoint.

Legit

[str4wm4n]

I would LOVE to see this get developed. As someone who likes to gamble...I really wish this existed about a month ago...

[michagogo]

This is an interesting idea, but there *is* one issue. You can't broadcast a transaction with nlocktime a year in the future and expect it to stick around in mempools -- you would need to keep the transaction somewhere safe, outside of the bitcoin network, and then broadcast it a year later.

[ripper234]

This is an interesting idea, but there *is* one issue. You can't broadcast a transaction with nlocktime a year in the future and expect it to stick around in mempools -- you would need to keep the transaction somewhere safe, outside of the bitcoin network, and then broadcast it a year later.

Hmm - excellent point, I hadn't thought of that.
One thing you can do - send the client a signed copy of your transaction (in JSON format or encoded as a link).
You can also schedule a reminder to be sent to the client using a 3rd party service such as followupthen.com

This way the client can always rebroadcast the tx themselves in case something happens to your service.
Of course under ideal circumstances you would add a server to this setup that automatically broadcasts this tx itself after the time expired.


We were actually thinking of doing a quick hackathon and implement this at Bitblu just for fun's sake, but this technical complication you spotted might mean that it's now a bit too much work to hack up a working solution in a few hours ...

[theonewhowaskazu]

So assuming you did broadcast a nlocktime a year in the future, and saved the transaction, you can't 'cash it in' early, can you? You'd just have to re-broadcast it in a year to get your Bitcoins, if you broadcasted it early, nothing would happen because everybody would just be sitting there waiting for the nlocktime to expire.

[bitwhizz]

buy the rare casascius coins, thats a way to not touch your bitcoins,

[theonewhowaskazu]

buy the rare casascius coins, thats a way to not touch your bitcoins,

You have to pay a huge premium, for those, though. If nlocktime works as I think it does you could get a better result for free.

[bitwhizz]

i wasn't being that serious, nclock sounds like an awesome idea everyone could really benefit from,

[ripper234]

So assuming you did broadcast a nlocktime a year in the future, and saved the transaction, you can't 'cash it in' early, can you? You'd just have to re-broadcast it in a year to get your Bitcoins, if you broadcasted it early, nothing would happen because everybody would just be sitting there waiting for the nlocktime to expire.

nLockTime means by definition the transaction isn't valid until a specific block number. You can't 'cash it in' early no matter what.

You have to re-broadcast the tx in the future to get your bitcoins.

[theonewhowaskazu]

So assuming you did broadcast a nlocktime a year in the future, and saved the transaction, you can't 'cash it in' early, can you? You'd just have to re-broadcast it in a year to get your Bitcoins, if you broadcasted it early, nothing would happen because everybody would just be sitting there waiting for the nlocktime to expire.

nLockTime means by definition the transaction isn't valid until a specific block number. You can't 'cash it in' early no matter what.

You have to re-broadcast the tx in the future to get your bitcoins.

So. then whats wrong with the nLockTime idea?

You broadcast & save a transaction with nLockTime of 144 blocks. 144 blocks later you either receive your transaction or rebroadcast  the tx and get your Bitcoins.

[ripper234]

So assuming you did broadcast a nlocktime a year in the future, and saved the transaction, you can't 'cash it in' early, can you? You'd just have to re-broadcast it in a year to get your Bitcoins, if you broadcasted it early, nothing would happen because everybody would just be sitting there waiting for the nlocktime to expire.

nLockTime means by definition the transaction isn't valid until a specific block number. You can't 'cash it in' early no matter what.

You have to re-broadcast the tx in the future to get your bitcoins.

So. then whats wrong with the nLockTime idea?

You broadcast & save a transaction with nLockTime of 144 blocks. 144 blocks later you either receive your transaction or rebroadcast  the tx and get your Bitcoins.

Nothing wrong, the idea works - it's just a bit more time to implement properly than what we have at our disposal right now.
We were hoping to implement a complete solution in 4-5 hours of work, but I think that a good quality solution would just make time than that given the above. It's not a huge project, perhaps a few days, but we're just a bit too busy for that ourselves a.t.m.

[theonewhowaskazu]

So assuming you did broadcast a nlocktime a year in the future, and saved the transaction, you can't 'cash it in' early, can you? You'd just have to re-broadcast it in a year to get your Bitcoins, if you broadcasted it early, nothing would happen because everybody would just be sitting there waiting for the nlocktime to expire.

nLockTime means by definition the transaction isn't valid until a specific block number. You can't 'cash it in' early no matter what.

You have to re-broadcast the tx in the future to get your bitcoins.

So. then whats wrong with the nLockTime idea?

You broadcast & save a transaction with nLockTime of 144 blocks. 144 blocks later you either receive your transaction or rebroadcast  the tx and get your Bitcoins.

Nothing wrong, the idea works - it's just a bit more time to implement properly than what we have at our disposal right now.
We were hoping to implement a complete solution in 4-5 hours of work, but I think that a good quality solution would just make time than that given the above. It's not a huge project, perhaps a few days, but we're just a bit too busy for that ourselves a.t.m.

No, I'm just saying why does it even need to be done at all, if you can just usre nLockTime and your normal Bitcoin client to do it yourselves anyway?

[ripper234]

No, I'm just saying why does it even need to be done at all, if you can just usre nLockTime and your normal Bitcoin client to do it yourselves anyway?

Providing an easy to use interface to this kind of operation is what it's about.
You can of course implement this using your normal client, but it's a bit difficult. E.g. you have to get it to forget your private key, otherwise your future self can always just spend the coins.

Just to make sure we all understand how it works: If you sign an nLockTime tx, until that time passes, and regardless if the transaction was broadcast or not, you can still send the bitcoins away to another address and essentially "double spend" the nLockTime tx. To fully implement my idea you need to create an nLockTime and then forget the private key, leaving the only option of getting your coins back as transmitting the nLockTime tx at the correct time.

[prophetx]

I think this could also be useful for enforcement of periodic payments. Or for transferring funds between addresses that are linked to an accounting system where one address accounts for future revenue, were payment has been been received, and the other for recognized revenue.  And yet nother address for committed funds which need to be sent out at some time period in the future.  Though one does not need to throw away the keys necessarily, just do the scheduling.

[str4wm4n]

this could have saved me so bad yesterday... 

[Mitchell]

Well, it would be nice to have something like this. Maybe a website like BlockChain.info (so that the server has no access) that locks up your coins until a certain time before you are able to spend it.

[ripper234]

Well, it would be nice to have something like this. Maybe a website like BlockChain.info (so that the server has no acces) that locks up your coins until a certain time before you are able to spend it.

Well, yeah, that's what I specified in the OP - a trustless solution is relatively easy to implement here.

[Mitchell]

Well, it would be nice to have something like this. Maybe a website like BlockChain.info (so that the server has no acces) that locks up your coins until a certain time before you are able to spend it.

Well, yeah, that's what I specified in the OP - a trustless solution is relatively easy to implement here.

I wish I had to knowledge to create something like that, because I really like the idea and would do it if I knew how. Maybe I should look into the way BlockChain.info stores wallets.

[Herbert]

Interesting idea, but isn't this quite risky? The moment the locked transaction gets lost the coins are gone, because the original private keys are already forgotten.
This would be cool if the locked transaction would be safe in the blockchain, but as this is not the case you need to have a real safe storage for the locked transaction in order to broadcast it when it's time has come.

[ripper234]

Interesting idea, but isn't this quite risky? The moment the locked transaction gets lost the coins are gone, because the original private keys are already forgotten.
This would be cool if the locked transaction would be safe in the blockchain, but as this is not the case you need to have a real safe storage for the locked transaction in order to broadcast it when it's time has come.

The locked tx can be emailed / exported to the user before the private keys are deleted.
The user can then broadcast this tx himself at a later date.

[Herbert]

Interesting idea, but isn't this quite risky? The moment the locked transaction gets lost the coins are gone, because the original private keys are already forgotten.
This would be cool if the locked transaction would be safe in the blockchain, but as this is not the case you need to have a real safe storage for the locked transaction in order to broadcast it when it's time has come.

The locked tx can be emailed / exported to the user before the private keys are deleted.
The user can then broadcast this tx himself at a later date.

Yes, but that's the point. User needs to manually store the tx in a safe place. Not the kind of a "fire-and-forget" action, instead user has to take exactly the same security consideration as with any offline wallet.

[ripper234]

Interesting idea, but isn't this quite risky? The moment the locked transaction gets lost the coins are gone, because the original private keys are already forgotten.
This would be cool if the locked transaction would be safe in the blockchain, but as this is not the case you need to have a real safe storage for the locked transaction in order to broadcast it when it's time has come.

The locked tx can be emailed / exported to the user before the private keys are deleted.
The user can then broadcast this tx himself at a later date.

Yes, but that's the point. User needs to manually store the tx in a safe place. Not the kind of a "fire-and-forget" action, instead user has to take exactly the same security consideration as with any offline wallet.

Not really - he just needs to back the transaction, he doesn't need to secure it - he doesn't care if anyone steals it (it being the transaction), because all the thief can do is broadcast it, which doesn't get him any coins.

[Mitchell]

Just so you guys know. I am currently trying to create something like this. If someone could tell me how to get nLockTime into a rawtransaction, that would be great.

[miffman]

This is a really good idea. Esp. For a coin like CGB. It's meant to be a long term investment.

[gmaxwell]

Be very careful:  We don't know what the world will look like in ten years. Security fixes may make transactions authored today no longer valid.

At a minimum any such transaction should be sighashed anyone can pay so that extra fees could be added in the future, if fees are required to get acceptable transaction processing time.

[str4wm4n]

how does one generate an nLockTime transaction using http://brainwallet.org/#tx ?

is this possible?

[Mitchell]

how does one generate an nLockTime transaction using http://brainwallet.org/#tx ?

is this possible?

No. That is why I am redoing it. I know what to edit (at least a bit), but I cannot get it like it should. You can checkout my current progress here: http://lockmycoins.bitcoininformation.info Everything is client sided, so don't worry about me stealing your private key.

[Mitchell]

Aaaand. I am done, I guess. You can check it out here: LockMyCoins and you can find the source code on GitHub and the page itself (because it's 100% client sided Javascript). I hope this is what you meant.

Donations are welcome:
18ER6uQZDoRd3SZhHi1LZvRWCTnvovjDAF

[ripper234]

Coolness!

A few comments:

1. Usability - I think the website isn't usable enough, it doesn't explain what it does, and it has too many controls. I doubt anyone but you could use this (I thought up the idea and I'm not sure what I should do here ... instead of explaining on the thread, you need to make the site dead simple for new users finding it).
2. I won't have time to review the actual code, but maybe someone else can help with that.
3. "JavaScript Client-Side BitCoin Lookup" - did you mean "Lockup" ?
4. I would lose the Passphrase field.
5. Fee's --> Fee (or Fees, but never Fee's)
6. Unix timestamp --> omg, please provide an easier way to choose the time. People could accidentally end up locking their coins 10,000 years in the future.
7. The output (JSON tx/rax tw) shouldn't be in the same place as the input (time , dest address). In fact, I'd place the different input fields all visible and not in a tabbed interface.
8. A link to this thread somewhere visible would be good - it can give the user some background.
9. Register lockmycoins.com/.org or lockyourcoins.com/.org or something like ... (I think one of these was free when I started this thread).

[Mitchell]

Coolness!

A few comments:

1. Usability - I think the website isn't usable enough, it doesn't explain what it does, and it has too many controls. I doubt anyone but you could use this (I thought up the idea and I'm not sure what I should do here ... instead of explaining on the thread, you need to make the site dead simple for new users finding it).
2. I won't have time to review the actual code, but maybe someone else can help with that.
3. "JavaScript Client-Side BitCoin Lookup" - did you mean "Lockup" ?
4. I would lose the Passphrase field.
5. Fee's --> Fee (or Fees, but never Fee's)
6. Unix timestamp --> omg, please provide an easier way to choose the time. People could accidentally end up locking their coins 10,000 years in the future.
7. The output (JSON tx/rax tw) shouldn't be in the same place as the input (time , dest address). In fact, I'd place the different input fields all visible and not in a tabbed interface.
8. A link to this thread somewhere visible would be good - it can give the user some background.
9. Register lockmycoins.com/.org or lockyourcoins.com/.org or something like ... (I think one of these was free when I started this thread).

Thank you for these comments, remember it was just an example to show that it works. I will try to make it better looking, more self explaining. I don't think I will buy a domain for that, because I run short on money + BTC, but someone else could. I mean, it's opensource (MIT License) after all

But why lose the Passphrase field? You could use that to get your coins back if you really want to (it would destroy the purpose of the concept). I mostly used Brainwallet's Javascript files and a few extra functions for the Unix Timestamp to Hex conversion.

[Jabbatheslutt]

should include a five year and a 10 year option.

= solid retirement plan...   

This. Help resist temptation to dice them

[ripper234]

Coolness!

A few comments:

1. Usability - I think the website isn't usable enough, it doesn't explain what it does, and it has too many controls. I doubt anyone but you could use this (I thought up the idea and I'm not sure what I should do here ... instead of explaining on the thread, you need to make the site dead simple for new users finding it).
2. I won't have time to review the actual code, but maybe someone else can help with that.
3. "JavaScript Client-Side BitCoin Lookup" - did you mean "Lockup" ?
4. I would lose the Passphrase field.
5. Fee's --> Fee (or Fees, but never Fee's)
6. Unix timestamp --> omg, please provide an easier way to choose the time. People could accidentally end up locking their coins 10,000 years in the future.
7. The output (JSON tx/rax tw) shouldn't be in the same place as the input (time , dest address). In fact, I'd place the different input fields all visible and not in a tabbed interface.
8. A link to this thread somewhere visible would be good - it can give the user some background.
9. Register lockmycoins.com/.org or lockyourcoins.com/.org or something like ... (I think one of these was free when I started this thread).

Thank you for these comments, remember it was just an example to show that it works. I will try to make it better looking, more self explaining. I don't think I will buy a domain for that, because I run short on money + BTC, but someone else could. I mean, it's opensource (MIT License) after all

But why lose the Passphrase field? You could use that to get your coins back if you really want to (it would destroy the purpose of the concept). I mostly used Brainwallet's Javascript files and a few extra functions for the Unix Timestamp to Hex conversion.

No worries, it's great you managed to get something out there!
Did you test it?

You already have the private key field to get your coins back, isn't that enough?
The domain cost is trivial, I could buy one of these and point to your server if you want.
I see the site is down right now?

[Mitchell]

Coolness!

A few comments:

1. Usability - I think the website isn't usable enough, it doesn't explain what it does, and it has too many controls. I doubt anyone but you could use this (I thought up the idea and I'm not sure what I should do here ... instead of explaining on the thread, you need to make the site dead simple for new users finding it).
2. I won't have time to review the actual code, but maybe someone else can help with that.
3. "JavaScript Client-Side BitCoin Lookup" - did you mean "Lockup" ?
4. I would lose the Passphrase field.
5. Fee's --> Fee (or Fees, but never Fee's)
6. Unix timestamp --> omg, please provide an easier way to choose the time. People could accidentally end up locking their coins 10,000 years in the future.
7. The output (JSON tx/rax tw) shouldn't be in the same place as the input (time , dest address). In fact, I'd place the different input fields all visible and not in a tabbed interface.
8. A link to this thread somewhere visible would be good - it can give the user some background.
9. Register lockmycoins.com/.org or lockyourcoins.com/.org or something like ... (I think one of these was free when I started this thread).

Thank you for these comments, remember it was just an example to show that it works. I will try to make it better looking, more self explaining. I don't think I will buy a domain for that, because I run short on money + BTC, but someone else could. I mean, it's opensource (MIT License) after all

But why lose the Passphrase field? You could use that to get your coins back if you really want to (it would destroy the purpose of the concept). I mostly used Brainwallet's Javascript files and a few extra functions for the Unix Timestamp to Hex conversion.

No worries, it's great you managed to get something out there!
Did you test it?

You already have the private key field to get your coins back, isn't that enough?
The domain cost is trivial, I could buy one of these and point to your server if you want.
I see the site is down right now?

I did test it with fake input. Everything works except pushing it (which is logical ).

Also you are right, private key should be good enough and yes, my website is currently down. Trying to fix it with my hosting provider (once again). I use a shared server and it seems that I use to much resources. That's why I redid my scripts, merged stuff, decreased API calls and set my CloudFlare Security Settings to high (to block off bots and shit like that). It seems that it didn't help or something on their side is off.

EDIT: Apperently my log files were to big. It's fixed now.

[Mitchell]

I updated the page and pushed everything to GitHub.

It is now user friendly and you can enter whatever date you want (for example, "Fri Oct 31 2014 00:00:00 GMT+0200" works without a problem). It will be instantly converted to a Unix Timestamp and put into the rawtransaction.

Just a quick note, the scripts won't do anything if the address balance is zero.


Donations are welcome:
18ER6uQZDoRd3SZhHi1LZvRWCTnvovjDAF

[str4wm4n]

.01 btc to whom ever posts a step by step list of instructions for using this!

thanks!

[Mitchell]

.01 btc to whom ever posts a step by step list of instructions for using this!

thanks!

I though my website was quite clear. I will make a tutorial about how to use it tomorrow, if you still need it then. I'm currently a bit busy with a job.

[str4wm4n]

looking forward to it!

[ripper234]

BTW I have thought of a good use case for this website except to prevent short term speculation:

Time Vault

You know how banks have vaults that can only open at specific times?
The same could be very useful with BTC, to prevent someone forcing you to send him your BTC at gunpoint.

If you lock your coins away each year, if you get kidnapped and held at gunpoint in the middle of the year, you can honestly tell your kidnapper - "Listen, I really cannot access my bitcoins right now ... here's the proof!"

[str4wm4n]

any luck on writing that guide?

[Mitchell]

Not really. My back hurts like hell and I have no motivation at all to do something. I will try to explain the basics:

When you ope the website an address will be generated for you (the private key can be copied, no worries). This will be the address used to lock your coins in a transactions, so you will need to send the coins you want to lock to that address.
 
After that the only thing you need to do is enter an Destination Address, how much you want to send to it (I advice you to send everything, haha) and when it should be accessible (you can enter something like "Tomorrow", "Next month", "23-11-2013" and many more options, just check that the Lock Time variable in the Json output isn't 0 / the output isn't empty).

The script will output an hex encoded transaction and a json one just for display purposes. You have to save the hex one! After that go to the "Broadcast Transaction" and push the transaction. That will push the transaction into the network.

Please note that if you set a time lock for more then a few days, you will have to push the transaction again from time to time. The network / the miners don't support Time Locked Transactions that well.

I hope this helps

[michagogo]

Please note that if you set a time lock for more then a few days, you will have to push the transaction again from time to time. The network / the miners don't support Time Locked Transactions that well.

...
No. You push the transaction locking up the coins right away. The other transaction, the timelocked one, you don't need to broadcast at all until it becomes valid. There's no point broadcasting it, because it won't be stored or relayed. What you need to do is keep the timelocked transaction that pays the coins back out to you safe, and once it matures, you can broadcast it and it should be mined.

[Mitchell]

Like I have stated before, I have never read the whitepaper, nor do I know a lot of the Bitcoin Protocol itself. I'm just a simple programmer. No need to attack me if I made a mistake.

[michagogo]

Like I have stated before, I have never read the whitepaper, nor do I know a lot of the Bitcoin Protocol itself. I'm just a simple programmer. No need to attack me if I made a mistake.

My intention wasn't to attack you, simply to correct that misinformation for other people who may see this. I apologize if you interpreted it as an attack.

[doronk69]

A great idea could really help a lot of ppl here. who's gonna work on it?

[Mitchell]

A great idea could really help a lot of ppl here. who's gonna work on it?

I already created it: LockMyCoins.

Small explanation:

When you open the website an address will be generated for you (the private key can be copied, no worries). This will be the address used to lock your coins in a transactions, so you will need to send the coins you want to lock to that address.
 
After that the only thing you need to do is enter an Destination Address, how much you want to send to it (I advice you to send everything, haha) and when it should be accessible (you can enter something like "Tomorrow", "Next month", "23-11-2013" and many more options, just check that the Lock Time variable in the Json output isn't 0 / the output isn't empty).

The script will output an hex encoded transaction and a json one just for display purposes. You have to save the hex one! After that go to the "Broadcast Transaction" and push the transaction. That will push the transaction into the network.

You push the transaction locking up the coins right away. The other transaction, the timelocked one, you don't need to broadcast at all until it becomes valid. There's no point broadcasting it, because it won't be stored or relayed. What you need to do is keep the timelocked transaction that pays the coins back out to you safe, and once it matures, you can broadcast it and it should be mined.

Michagogo, thanks for the last paragraph.

[Mitchell]

Hello ripper234,

It might pleases you to hear that I am going to redo this project in a more user friendly style. This will include a new name and (of course) a domain. It will also include a little FAQ and a explanation why and how this works.

I will contact you when it's done and posts in this topic

Kind Regards,
Mitchell (BitcoinInformation)


Donations for this project are welcome. 2 dollar is already enough to keep a domain up for a year. The donation address is: 1BTg9Xoy9fwUXoYJppXJfEJWbN9NeYL83Y
All the funds on this address will be used to host and support this project. If you see something you don't trust, just post a message on here or send me a PM and I will explain my expenses.

[Mitchell]

Sneak Preview:

Donations for this project are welcome. 2 dollar is already enough to keep a domain up for a year. The donation address is: 1BTg9Xoy9fwUXoYJppXJfEJWbN9NeYL83Y
All the funds on this address will be used to host and support this project. If you see something you don't trust, just post a message on here or send me a PM and I will explain my expenses.

[ripper234]

I see that http://lockmycoins.bitcoininformation.info/ is down.

Is it because the new site is under development?
Why not keep the old site alive for the time being?

[Mitchell]

I see that http://lockmycoins.bitcoininformation.info/ is down.

Is it because the new site is under development?
Why not keep the old site alive for the time being?

Yes, I shut it down because of the new website. There is a bug in the old version which makes the transaction go through instantly and some other small things that I need to change. Working on it as fast as I can, but school makes it a bit harder. It's consuming a lot of time.