• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

Masternodes with offline (paper) wallets

This is an interesting idea that I am considering whether to implement this feature in the future release of DashMasternodeTool application.

In this case, you would have two instances of the app: one offline, one online. A purpose of the online instance would be to prepare 'start masternode' message and sign it with a private key, imported from a paper wallet. In turn, a purpose of the online instance would be to broadcast that signed 'start masternode' message. A file with a signed message would be moved on a pendrive.

I do not promise yet whether and when I will implement it. First I have to investigate whether there are any constraints in the time between signing the message and its broadcasting on the network - in practice this activity will take at least a few minutes.

I'm really interested in hearing your findings. Are there any contraints that prevent this.
Looking at the code I'm seeing; block_hash, sig_time and lastping going into the Broadcast (masternode start) - so I'm guessing it has to be fast if possible at all?

The reason behind my questing is I'm working on a small tool that can work on air gapped / cold system using ShamirSS to produce the priv-key (paper-a-like), and optical (QR-code) moving of messages only. A tool to essentially produces two types of messages;
1. to transfer rewards from a masternode running on paperwallet collateral.
2. to produce masternode start.
Both types of messages moved via optical data transfer (QR) to an online system where from they can be broadcasted to the network.
 
Last edited:
I'm really interested in hearing your findings. Are there any contraints that prevent this.
Looking at the code I'm seeing; block_hash, sig_time and lastping going into the Broadcast (masternode start) - so I'm guessing it has to be fast if possible at all?

The reason behind my questing is I'm working on a small tool that can work on air gapped / cold system using ShamirSS to produce the priv-key (paper-a-like), and optical (QR-code) moving of messages only. A tool to essentially produces two types of messages;
1. to transfer rewards from a masternode running on paperwallet collateral.
2. to produce masternode start.
Both types of messages moved via optical data transfer (QR) to an online system where from they can be broadcasted to the network.

I started testing this solution quite recently, so I have not checked all the possible scenarios yet (and there are a lot of them). For now I know, that despite a few restrictions, the case looks quite promising. In a few days I should have quite definitive conclusions.
 
I started testing this solution quite recently, so I have not checked all the possible scenarios yet (and there are a lot of them). For now I know, that despite a few restrictions, the case looks quite promising. In a few days I should have quite definitive conclusions.
Sounds good - let me know if I can help with anything.

On the same note - are you able to provide info about the format/construct of the Masternode Start Alias message? Or point me to any (literally any) documentation of the construct of such message?

Thanks a bunch :)

BR. Ndrezza
 
Last edited:
Sounds good - let me know if I can help with anything.

On the same note - are you able to provide info about the format/construct of the Masternode Start Alias message? Or point me to any (literally any) documentation of the construct of such message?

Thanks a bunch :)

BR. Ndrezza

The best source, in my opinion, is the official protocol documentation: https://github.com/dashpay/dash/blob/master/dash-docs/protocol-documentation.md#mnannounce---mnb

Here's how I implemended it in DashMasternodeTool:

Message classes:
https://github.com/Bertrand256/dash...0dd1096dd42e9bd17/src/dash_utils.py#L349-L448

In line 419 there is a function that signs the message using a hardware wallet. At this point you must apply your own solution.

Message construction:
https://github.com/Bertrand256/dash...0dd1096dd42e9bd17/src/main_dlg.py#L1400-L1409

And finally, adding the number of mn boradcast messages in one RPC call:
https://github.com/Bertrand256/dash...0dd1096dd42e9bd17/src/main_dlg.py#L1557-L1558

BTW, you probably know that along with Dash v12.4 this approach will be obsolete, so in my opinion it might not make much sense to use too much energy for this solution.
 
If i understand correctly broadcasted masternode activation message require sigTime and lastPing so its impossible to store on paper activation message and use many times.
But i am not sure what key is used for signature: masternode private key or wallet private key.
 

Thanks

If i understand correctly broadcasted masternode activation message require sigTime and lastPing so its impossible to store on paper activation message and use many times.
But i am not sure what key is used for signature: masternode private key or wallet private key.

Yes, but I imagine much as with Armory or Electrum, you produce the message on an online client, QR-code move it to an offline/air gapped/cold, sign it, QR-code move it back, and broadcast it.
 
If i understand correctly broadcasted masternode activation message require sigTime and lastPing so its impossible to store on paper activation message and use many times.

Yes, you can not re-use mn broadcast messages - if the message is the same as the previous one, it is skipped.

But i am not sure what key is used for signature: masternode private key or wallet private key.

CMasternodePing part of the masternode broadcast message (CMasternodeBroadcast) is signed with the masternode private key and the rest of the message is signed with the collateral private key.

Yes, but I imagine much as with Armory or Electrum, you produce the message on an online client, QR-code move it to an offline/air gapped/cold, sign it, QR-code move it back, and broadcast it.

Yes, it is feasible. The only information you need to attach to the message that can not be faked/guessed/computed is the hash of the block, which is not older by more than 24 from the latest block at the time of processing the message by a dash node.

In other words, you have 24 blocks of time (i.e. about an hour) to get the hash of the lastet block, create a message and sign it on an offline computer, transfer to an online one, and finally, send it to the network. If your offline computer is not on the opposite side of the city than your online location, you have more than enough time to do so.
 
Yes, it would be good to have an opportunity to use air-gaped PC for messages generation. Even if have to use QR codes.
But what plans are for 12.4? MN announcement messages will be changed?
 
Back
Top