[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.

[1713953585]

1713953585

[1713953585]

1713953585

[1713953585]

1713953585

[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.