''it's a huge advantage that bitcoin has a built in voting process to handle upgrades, checks and balances on maintainers of any fork, etc''
~~Brian Armstrong~~

The 1k bounty private key is never disclosed and the 1k balance can never be removed from the cold wallet as far as I know because you only pair 1 private key belonging to a 'payment' address.
Think of it like a partially shared bank account with your girlfriend or wife (she has gambling/shopping problems so you allow a weekly allowance)
You both have separate bank accounts and can not draw out from each others main balance using your own account but you can draw out from a special trading account deposit number that is the same for both of you within your accounts.
This is a trusted number as either party can empty the balance, but they can not empty the balance of the rest of the account as they do not have access, and if either party moves the balance to another address within in the account-the deposit is no longer visiable to the other person.

To help you guys, I could write a short guide in the masternode guide help section and people can add their thoughts on it from there rather then getting lost in this thread (again, hehe) ...

It works, I have tried it (but only on hot wallets so far!)
Do not confuse the 1k bounty private key with the 'donation' payment private key, they are separate entities.
You are only twinning one shared key between 2 wallets. Try it on 2 other wallets first, with listen=0 and run them at the same time, you will see what I mean.

Good morning ,btw.

Edit: Its an odd thing having only 1 shared address because if you move the coins around in same wallet using coin control, it can change the balance of the other wallet , but only 1 wallet of the 2 wallets balance has the potential to change at a time.(you must change the shared key for this to happen otherwise there is no change in both wallets)

Just a thought here, but I have noticed that I can get a more reliable sync if I am downloading the blockchain (from scratch) at the same time, while this doesn't quite make sense-why download it all again anyway? But I am thinking that the download process slows the client down enough so that it syncs/aligns better with the network, basically helps match the speed of all the processes involved.
If you were on a slow computer like the Pi, this could be more of an issue perhaps.

Edit: Yep, you are almost there, but the private key must be the change payment address and not the 1k address, they are different. And when you import the key to the new wallet, if it had 1 dash before, it will now add 1 dash to the hot wallet and remain in the cold wallet at the same time (twinned, so to speak, until moved to another address)

And my question still stands,
is there any security threat for the cold wallet by sharing only one private key between 2 wallets to use as a donation address,
anyone, please ??

Fun off topic chart 

now that there is no donation address, can we not just import the dumped priv key from the cold wallet payment address to another unsafe hot wallet, I tried this and imported the priv key into the new wallet, and seems to work fine.
If you send within the hot wallet from the imported address to another address within the same wallet, this will make the payment balance of the 1k cold wallet disappear but will keep the 1k bounty intact.
So, effectively the 2 wallets are twinned by 1 mutually exclusive address.
wondering is this a 100% secure way of receiving masternode payments to an unsafe hot wallet, as the priv key for the 1k is still safe in the cold wallet that never has to be started up, am I missing anything, anyone ?

below sgminer v5.0
https://www.nicehash.com/?p=software
and Reuben's detailed guide with wolf0's links,
https://dashtalk.org/threads/reubens-guide-to-mining-dash-with-an-amd-gpu-on-windows.4051/

In the beginning,
http://web.archive.org/web/20130509235146/http:/coinmarketcap.com/

I see the masternodes like shock absorbers on a car:-
when there are bumpy price movements downwards this produces a counter acting force and increased dampening factor of more buy ins for extra masternodes.
when the price goes bumpity up, people empty their spare change from the masternodes, producing a counter acting (and higher dampened) force downwards on the price.
Hence both reactions are equal and opposite forces against the market price trend thus evening out the larger spikes to smoother price swings.

Sounds pie in the sky to me, in 12 months it may not even matter so where will the incentive be?

Thats a good idea, have a counter for the number of keys used, and when the limit is near there could be a warning to backup your wallet - useful if doing a lot of mixing.

But you can increase the number of keys made with keypool in the config at wallet startup so using keypool=100000 for example.
Satoshi said that each key uses 1k, so normally only 1 megabyte space used for default 1000, you could easily increase it to 100,000 keys and still only use 100 megabytes, I imagine loadup and wallet encryption may be a little slow.
https://bitcointalk.org/index.php?topic=1414.0

Nice answer, Tante, you have a great grammatical prose way of summing up what I was trying to say.
I like how you left out the 'for life' part, so we can tick this off as another hard problem solved.

Hard problems solved already

How to instantly confirm a transaction in an otherwise slow blockchain while still part of the client and remaining decentralized : solved
How to provide lasting incentive to full nodes to seed quickly, reliably and guard network integrity : solved
How to resolve the 'benevolent dictator for life' in software development while maintaining decentralized leadership : solved

So does masternode voting then solve the hard problem of 'Benevolent dictator for life' within an open source blockchain decision making conundrum that bitcoin is struggling with at the moment?
http://www.theatlantic.com/technology/archive/2014/01/on-the-reign-of-benevolent-dictators-for-life-in-software/283139/

Coins, thanks! You helped give me an idea  

The link lead me to this comment by Kristov Atlas,
https://groups.google.com/forum/#!topic/bitcoin-xt/irrzfMH_dfo
''Do you consider raising the block size limit to be an act of scaling the network? Based on my reading, it seems purely an act of increasing throughput, at the (difficult to quantify) cost of raising the minimum resource requirements for full nodes. Scaling in my amateur understanding is primarily about efficiency gains. If this fits at all with your understanding, what sorts of efficiency gains for the network are in the pipeline for Bitcoin-XT?''
Thanks,
~~Kristov~~

Then I had a brainstorm when he mentioned efficiency  
wait for it ...

The blockchain efficiency is inversely proportional to the Tao ratio, (I should have seen that before)

None normalized efficiency = 1 / Tao

efficiency (Dash)   =  4.16%
efficiency (bitcoin) = 0.24%
efficiency (Monero) = 0.07%

Normalizing to 100% can be done by inversely scaling using the worst possible scenerio which for these purposes is Monero (Tao =14.2), the minimum value has to be assumed to be zero as the lower tao limit is unknown.
https://en.wikipedia.org/wiki/Feature_scaling

using this normalization method :-
[current tao - min tao) / (max tao - min tao)) * -1 ) +1)] * 100

so, finally, normalizing to always give 100% as the maximum using Monero as the highest value we have,

Normalized network/blockchain efficiencies

Dash efficiency = 98.3%
Bitcoin efficiency = 70.9%
Monero efficiency = 0%

I'll have to measure litecoin and a couple of others to stick in the middle somewhere!

[of course if there is a coin slower than Monero that sets the standard, this would mean Monero is more than zero]

Whoops!
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010379.html
''Connections are made over clearnet even when using a proxy or
onlynet=tor, which leaks connections on the P2P network with the real
location of the node. Knowledge of this traffic along with uptime metrics
from bitnodes.io can allow observers to easily correlate the location and
identity of persons running Bitcoin nodes''

edit: for more whoops ..
'Theres way over 1000 lines of code determining who gets banned, and as far as I can tell they ban people at will too... And that's where the real abuse will come in. If government got it they would ruin a lot of Bitcoin dealers overnight.'
~~Turtlehurricane~~
   

Good luck with your new exchange, nice to see mining with dash combined and listed.

Coins, I am waiting for Thor's hammer to come down before timing V12, need the network to calm down otherwise the readings will be spurious, and the more fast masternodes to lock onto for seeding the better.
Btw, bitcoin does appear to be increasing it's Tao sync ratio, on the 7th March 2015 when the bitcoin v10 memory hop speed up was instigated (big speedup time) Tao = 3.3 seconds / hour, then on the 3rd August, bitcoin's Tao = 4.1 seconds / hour. This is not surprising with a congested network, poor seeding, full blocks and 40 gigabytes of blockchain to download - imagine what it will be like with 8 meg blocks if they get full quickly.

At the time, we were still a fork of bitcoin v0.9.3 with 0.11.2.23, so we didn't have Mr Andresen's 60 times memory hop speed up fixes fully in place.
In testnet, V12 update times were promising but we shall see  ...

You can have the remote machine as windows, depends if your host/location allows the option.