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).
Topic: [IDEA] - LockMyCoins - page 2. (Read 3916 times)
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
Donations are welcome:
18ER6uQZDoRd3SZhHi1LZvRWCTnvovjDAF
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.
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.
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.
This is a really good idea. Esp. For a coin like CGB. It's meant to be a long term investment.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
this could have saved me so bad yesterday... 
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.
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.
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?
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.
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.
Jump to: