When you have a cold wallet (https://en.bitcoin.it/wiki/Cold_storage), you sometimes want to transfer funds out of it, but keep the majority in the cold wallet. Problem: the cold wallet is no longer cold, when you import it in an NCC which is running on an online computer.
To solve this, NCC could create a tansaction, but instead of sending it directly to other nodes, it allows an export of this transaction (e.g. to an USB drive). You then import the file (which includes the data for the transaction) into another NCC which is running on an online computer and send it to other nodes.
This should technically be possible and I think it would be a huge benefit for NEM, if that was possible without doing complicated stuff like self coded scripts or anything like that.
To make it perfect, NCC could not only allow to export the transaction, but display the transaction data as a QR code, so you could then scan that could with the mobile NEM client (which runs on your phone) and send it directly to the block chain. The information transfer via QR code is even safer than via USB drive of course, because it is strictly oneway.
that would be sweet if when you click send(with box bottom left checked) it just puts up a QR code to scan with your phone to send the tx… 
or like you said, transfer over the data with usb to a hot computer… 
would definitely make use of that.
I don't see the huge benefit over a simple multi-sig. A multi-sig account is also cold as it can't send tx anymore. Only the co-signatories can send tx from it so it's bound to be cold. As soon as you have created that multi-sig account you can afaik delete the account and private key so it doesn't even have to be imported anywhere.
I also think it's not easily possible (but this should definitely be answered by a core dev)…
To create a tx you need a timestamp. To get synced with the network-time you need to be connected to it i.e. you need the interwebs. At that point you might as well send it right away.
If you just don't include that timestamp yet and let it be included by the sending NCC then i think you're gonna need to carry over the priv-key as you couldn't sign the tx on the cold wallet because you didn't have all the information (unless of course parts of the tx are not included in the signature which i think is what's known as tx malleability).
Might be completely wrong about the technical details though.
NCC is open. I think what your saying wouldn't be too hard to do.
I could even imagine if NEM gets a mobile app that the ability to scan a QR code created from an offline machine with transaction data wouldn't be too hard to incorporate.
For people like me, I could put my NEM wallet on an Ubuntu stick and boot from the stick with the Ethernet turned off. That would be extra secure.
Great tech for exchanges too. They could keep 95% of their deposits in cold storage.
I don't see the huge benefit over a simple multi-sig. A multi-sig account is also cold as it can't send tx anymore. Only the co-signatories can send tx from it so it's bound to be cold. As soon as you have created that multi-sig account you can afaik delete the account and private key so it doesn't even have to be imported anywhere.
I also think it's not easily possible (but this should definitely be answered by a core dev)...
To create a tx you need a timestamp. To get synced with the network-time you need to be connected to it i.e. you need the interwebs. At that point you might as well send it right away.
If you just don't include that timestamp yet and let it be included by the sending NCC then i think you're gonna need to carry over the priv-key as you couldn't sign the tx on the cold wallet because you didn't have all the information (unless of course parts of the tx are not included in the signature which would bei weird and is what's known as tx malleability).
Might be completely wrong about the technical details though.
That's a good point about the time stamp.
I don't see the huge benefit over a simple multi-sig. A multi-sig account is also cold as it can't send tx anymore. Only the co-signatories can send tx from it so it's bound to be cold.
Wrong, the cosigning accounts are not cold, so the multisignature account is not cold either.
Yes, a multisignature account is more secure than a normal account, but not as secure as a cold wallet/account.
To create a tx you need a timestamp. To get synced with the network-time you need to be connected to it i.e. you need the interwebs. At that point you might as well send it right away.
If you just don't include that timestamp yet and let it be included by the sending NCC then i think you're gonna need to carry over the priv-key as you couldn't sign the tx on the cold wallet because you didn't have all the information (unless of course parts of the tx are not included in the signature which i think is what's known as tx malleability).
Good point, but I think it is still doable. At least in a certain time window. Look at the API documentation (http://bob.nem.ninja/docs/#initiating-a-transaction):
[code]Possible Errors:
[...]
- The timestamp is invalid because it lies too far in the future.[/code]
It would be nice if a dev could give some feedback.
I don't see the huge benefit over a simple multi-sig. A multi-sig account is also cold as it can't send tx anymore. Only the co-signatories can send tx from it so it's bound to be cold.
Wrong, the cosigning accounts are not cold, so the multisignature account is not cold either.
Yes, a multisignature account is more secure than a normal account, but not as secure as a cold wallet/account.
Personally I'd consider it more secure as one machine can be compromised at least physically. The likelyhood of say 5 machines all being compromised no matter how hot or cold is imho smaller than that.
I guess it's debatable and strongly depends on how cold the cold wallet actually is. 90% of the time a cold wallet is as cold as it can be without loosing a certain level of convenience. So not really cold.
I don't agree, but I don't want to discuss the security of cold wallets (and what a cold wallet really is) in this thread.
Good point, but I think it is still doable. At least in a certain time window. Look at the API documentation (http://bob.nem.ninja/docs/#initiating-a-transaction):
[code]Possible Errors:
[...]
- The timestamp is invalid because it lies too far in the future.[/code]
It would be nice if a dev could give some feedback.
There is only a 10 second window, but doing what you're proposing is still technically possible:
[li]Use NIS to determine the current time stamp[/li]
[li]Create a transaction on the cold wallet machine with a timestamp some time (e.g. an hour) in the future[/li]
[li]Copy the transaction payload to a hot machine[/li]
[li]Have the hot machine send the transaction to NIS with the transaction network time is reached[/li]
Due to the multitude of steps, this is a pretty advanced operation, and I'm not sure if it makes sense for the bulk of NCC users. But, it could be accomplished fairly easily with some scripts.
Ok so if the default window is only 10 seconds, the transaction, which is created on the cold wallet machine, has to be in the future, right.
But I think the steps could be like this:
[li]Check if the system time of the cold wallet machine is correct (doesnt even have to be accurate to few seconds).[/li]
[li]Create the transaction on the cold wallet machine and tick the checkbox "Create transaction data only (don't send)". (NCC will then create the transaction with a timestamp 10 minutes in the future; this time window could be configurable somewhere deep in advanced settings.)[/li]
[li]Scan the QR-Code with the mobile wallet and send it to the block chain.[/li]
Due to the multitude of steps, this is a pretty advanced operation, and I'm not sure if it makes sense for the bulk of NCC users.
-> I think this should NOT be for advanced users only, thats why I would love to see it as simple as that in the GUI.
Good point, but I think it is still doable. At least in a certain time window. Look at the API documentation (http://bob.nem.ninja/docs/#initiating-a-transaction):
[code]Possible Errors:
[...]
- The timestamp is invalid because it lies too far in the future.[/code]
It would be nice if a dev could give some feedback.
There is only a 10 second window, but doing what you're proposing is still technically possible:
[li]Use NIS to determine the current time stamp[/li]
[li]Create a transaction on the cold wallet machine with a timestamp some time (e.g. an hour) in the future[/li]
[li]Copy the transaction payload to a hot machine[/li]
[li]Have the hot machine send the transaction to NIS with the transaction network time is reached[/li]
Due to the multitude of steps, this is a pretty advanced operation, and I'm not sure if it makes sense for the bulk of NCC users. But, it could be accomplished fairly easily with some scripts.
Doesn't NIS have to be connected to the network to determine a correct timestamp (or rather be sure that the timestamp is accurate)?
At that point you're connected to the internet and the wallet isn't as cold anymore and you might aswell broadcast the tx :)
@mixmaster: No matter how easy the GUI is. If you think anyone other than a really advanced user would use this you're kidding yourself.
When the checkbox is ticked, NCC will just use local system time. Easy as that…
@mixmaster: No matter how easy the GUI is. If you think anyone other than a really advanced user would use this you're kidding yourself.
The easier this is, the more people you can get to use features like this. And advanced users are also happy, if this is easier than hacking some script.
Actually the time window is a lot wider
You can create a transaction that has a deadline up to 12 hours in the future. The validator only validates if the transaction timestamp lies no more than 10 seconds in the future, no check for "too far in the past" is done other than that the deadline is already exceeded. So in practice you got a time window of about 12 hours at max.
So if I am sending txs and I turn my system time ahead by one hr will the txs go through one hr later?
Actually the time window is a lot wider :)
You can create a transaction that has a deadline up to 12 hours in the future. The validator only validates if the transaction timestamp lies no more than 10 seconds in the future, no check for "too far in the past" is done other than that the deadline is already exceeded. So in practice you got a time window of about 12 hours at max.
When the checkbox is ticked, NCC will just use local system time. Easy as that...
...
Pretty sure that's not how it works.
When the checkbox is ticked, NCC will just use local system time. Easy as that...
...
Pretty sure that's not how it works.
Not now, but hopefully in the future...
When the checkbox is ticked, NCC will just use local system time. Easy as that...
...
Pretty sure that's not how it works.
Not now, but hopefully in the future...
No I mean I'm pretty sure it wouldn't be reliable. If I'm not mistaken that would result in different timewindows for people in different timezones.
So if I am sending txs and I turn my system time ahead by one hr will the txs go through one hr later?
Actually the time window is a lot wider :)
You can create a transaction that has a deadline up to 12 hours in the future. The validator only validates if the transaction timestamp lies no more than 10 seconds in the future, no check for "too far in the past" is done other than that the deadline is already exceeded. So in practice you got a time window of about 12 hours at max.
This is possible since I already have done it plus it is also possible to set your system time back at least an hr and have txs clear (I also done it). By being able to sent the time in the past and have txs clear shows that there is no validation in the system.
So if I am sending txs and I turn my system time ahead by one hr will the txs go through one hr later?
Actually the time window is a lot wider :)
You can create a transaction that has a deadline up to 12 hours in the future. The validator only validates if the transaction timestamp lies no more than 10 seconds in the future, no check for "too far in the past" is done other than that the deadline is already exceeded. So in practice you got a time window of about 12 hours at max.
This is possible since I already have done it plus it is also possible to set your system time back at least an hr and have txs clear (I also done it). By being able to sent the time in the past and have txs clear shows that there is no validation in the system.
Any chance that was like A WHILE ago ? NTP wasn't implemented in the earlier version.
It was today, I have been able to set my system time back for at least the last three betas. Usually I just set it back a couple of mins but after reading BloodyRookies post about the timeframe I tried the 1hr timeframe and it worked.So if I am sending txs and I turn my system time ahead by one hr will the txs go through one hr later?
Actually the time window is a lot wider :)
You can create a transaction that has a deadline up to 12 hours in the future. The validator only validates if the transaction timestamp lies no more than 10 seconds in the future, no check for "too far in the past" is done other than that the deadline is already exceeded. So in practice you got a time window of about 12 hours at max.
This is possible since I already have done it plus it is also possible to set your system time back at least an hr and have txs clear (I also done it). By being able to sent the time in the past and have txs clear shows that there is no validation in the system.
Any chance that was like A WHILE ago ? NTP wasn't implemented in the earlier version.