Given the nature of DASH. Can we please move away from a wallet.dat file that can be opened without password? Would be nice if the file was encrypted so if it was found on your computer or someone was able to grab it they couldn't see all of your transaction history.
bitshares has a cover screen where you must put in your password before being able to see your balance and transaction history. we need something like that! Well I quoted you two and made the suggestion on the testing thread, but I doubt it'd be included in this release 'cause it'd delay everything. But it's a cool idea and maybe Evan will see it  I've been thinking about this while I've been working on v12 today. It would be easy enough just to AES encrypt the entire wallet file, then ask for a password when you start the wallet to see anything at all. Seems simple enough to implement |
|
|
|
How is Dash prepared for a scenario like this?
We have undisclosed plans for handling huge transaction volumes eventually, but we're in no immediate danger of something like this in the mean time. |
|
|
|
So I setup the masternode.conf file so that I could vote with my masternodes without turning on my cold wallets and that worked great. If I can authorize a "vote-many" command with the masternode.conf file (and no cold wallets) why cant the same setup work for the "start-many" command?
start-many signs the actual 1000DRK keys, which then authorizes a secondary key for the masternodes to communicate with. When you use vote many, it's signing messages with that secondary key, so you don't need access to the cold wallet. |
|
|
|
Status of the vote so far (15h48 UTC):
YEA 799
NAY 16
ABSTAIN 1724
MN owners don't forget to vote!
Not forgotten, am just stretching the moment as long as possible  You have 1 week and 5 days more the think and re-think about it;) We only need 51% of the network to vote yes for this too pass ./dashd masternode list votes YEA | wc -l 931 |
|
|
|
-snip-
This is the decentralized vision that I see.
Each project owner controls his/her own wallet with the funds. Each project is directly paid similar to masternodes getting payments over time from block rewards, only the project owner receives and controls the funds. Quick, simple, no 'central fund' at risk, no fund manager/s. Each project would get paid their specific % of the block rewards they request so there isn't any funds sitting in a queue waiting accumulate before they can be sent out each month. The funding mechanism would also be the voting mechanism. 51% yes votes gets a project in the queue, and highest yes% gets priority until the 10% cap is reached. Projects get voted in every 3 months and each project has a set limit for 3 months of block rewards.
unless i'm missing something this seems like a much better/easier way to at least start this new system. the new/latest proposal seems very complicated but is probably the best for a long term plan as it allows more precision but at the cost of (temporary?) centralization. i guess the main complaint about evans original plan was that a project could be over funded. i see that as a small sacrifice to preserve a more decentralized system. seems like the dev could just return extra funds to a advertising wallet or something like that. if they did not they would be cut off. it's all pretty complicated so i could be wrong. My 2 Main concerns. A mandatory 10% tax will eventually turn into pork barrel projects along with an incentive for those getting the funding to increase that tax. A central escrow/wallet for projects will cause problems with theft/loss/confiscation/tax. These will be bigger problems as time goes on and it makes a lot more sense to get around these issues now. The blockchain is forever so any mistakes that happen now could be traced back in the future. Switching to the voting system today....This masternode voting system is bulletproof. I moved a masternode to a different IP address to see if it was possible to manipulate extra votes. It turns out as soon as the old node stops, that vote gets deleted. Even trying to use the same masternode key on 2 nodes didn't fool it. I am totally impressed! The system is designed to be highly resistant to waste. I think once we get something on testnet and show how it will work and how these issues have been resolved, people will realize it should work pretty efficiently. The starting version is going to have a very low amount of money to be used, so the priorities of that money are going to be on things that are more urgent in nature. After a few iterations we should have something humming along, that has very few downsides and can react pretty quickly to waste and eliminate it. As for your concerns with theft/loss/confiscation/tax, the way we'd implement multi-sig is highly secure and not subject to theft or loss. I think we can also work around possible confiscation/tax issues (which we could discuss later if we end up doing it). However, I think I've come up with a solution that gives the best of both worlds, exact payments directly from the blockchain. You know the mantra around here, nothing is ever written in stone. I'll write something up tomorrow. |
|
|
|
I just downloaded windows zip file of the .23 wallet from Dashpay.io, or what I thought was Dashpay.io anyway, and when I run the dash-qt.exe in the 64 bit folder I get a message that says "Windows protected your PC." "Windows SmartScreen prevented an unrecognized app from starting. Running this app may put your PC at risk." When I click "more info" it says the publisher is unknown. I'm using windows 8.1 64-bit and have always used the 64-bit version of the wallet with no issues. My unzipped wallet is 28,113 KB, is that the same as some of you guys?
Download a tool which can create MD5 or SHA-256 hashes for files, like http://code.kliu.org/hashcheck/ or something similar. Create the hash (it's saved in a new file) and check against the ones provided here: https://www.dashpay.io/downloads/If they are identical, you're fine. If not, DON'T RUN/EXECUTE THAT FILE.Delete it, someone has changed it. Hmmm. I deleted that one and downloaded it from dashpay.io again and created the hash. I was just supposed to right click on the zip file and clicking create checksum file right? This is what I got   It looks OK to me >> cat dash-0.11.2.23-win.zip.DIGESTS.txt # MD5 hash 04c2f0405d258416c161467a01c6ab4c dash-0.11.2.23-win.zip # SHA-256 hash f3d7128eb8106b715daa7931f5de66e6d19cee179d5f2494542a3297fcaaad28 dash-0.11.2.23-win.zip -- >> sha256sum dash-0.11.2.23-win.zip f3d7128eb8106b715daa7931f5de66e6d19cee179d5f2494542a3297fcaaad28 dash-0.11.2.23-win.zip >> md5sum dash-0.11.2.23-win.zip 04c2f0405d258416c161467a01c6ab4c dash-0.11.2.23-win.zip I definitely wouldn't run the files inside if they don't match... |
|
|
|
I get this from a daemon updated an synced for a couple of hours:
NAY - 1
YEA - 47
ABSTAIN - 2452
I'm on v23 but it's a normal daemon. Does it need to be a masternode (hot/cold) wallet to get the correct results? I was getting weird results on one of my daemons, then I restarted it and get: ./dashd masternode list votes YEA | wc -l 664 ./dashd masternode list votes NAY | wc -l 16 ./dashd masternode list votes ABS | wc -l 1834 Maybe there's a bug? Try restarting your client and see if it shows the correct votes PS. Votes don't sync when you open your client. So to watch the progress of the vote you must have had a client open before the vote started (any v11.2 would work), then update to v11.2.23 to see the correct count. |
|
|
|
I get different results:
YEA: 606
NAY: 5
ABSTAIN: 1872
Interesting. How are you checking results. dashd masternode list votes | grep -c YEA dashd masternode list votes | grep -c NAY dashd masternode list votes | grep -c ABSTAIN EDIT: My daemon wasn't updated. Your results were correct. Let me get this straight. 51% Yea is required to pass. However, 1872 Abstain? That means no pass. Or, are we saying 1872 have yet to vote because vote starts with default set to abstain? Or, are we saying 51% yea votes vs. nay votes, ignoring abstainers? Sorry, only got one brain cell, and its thinking about the one thing it likes to think about most. The vote requires 51% of the total masternodes to go through. Abstain is the default, so it means those nodes have not voted. |
|
|
|
I was holding off on dropping a new Windows wallet build until I could include the escrow manager. If you want a build sooner let me know, I can do one with the I2P stuff. The code is already up in github.
The issue with darksend is that there is a hardcoded collateral address in there, which I find a little scary. I want to look at it and evaluate it before making that stuff visible in the UI again.
jase there are a couple of ways to achieve connection encryption like that. We use something like that under the hood for the escrow orchestration and market infrastructure.
Glad other devs are finally addressing this, havent really ever seen it be discussed. There is some very sketchy stuff going on in the depths of the darksend code, I suggest all you investors dive deeper and take a look I'm assuming we're referring to addresses: Xq19GqFvajRrEdDHYRKGYjTsQfpV5jyipF y1EZuxhhNMAUofTBEeLqGE1bJrpC2TWRNp With the first not having activity since July 31, 2014 and the latter with no activity. I could be wrong, but these could be part of the legacy DS before all collateral and fees went to the network. If you're referring to something else, I'd love to know where. It used to be used for DS collateral transactions, but I thought it was a better idea to pay collateral to the miners in the form of a transaction fee. I didn't remove the actual key though, because it's used to check masternode inputs to make sure they're valid. Here's the only two places it's referenced in the code currently: https://github.com/dashpay/dash/blob/master/src/masternode.cpp#L265https://github.com/dashpay/dash/blob/master/src/masternodeman.cpp#L674Once those two references are fixed, it can be completely removed. |
|
|
|
How can I send funds via linux cmdline with IX ?
You can't yet, but I'll add it to the list for v12. |
|
|
|
|
Show Posts
