I'm sure coinmine know the account holders email and hopefully had ask him to split up their hashrate onto other pools. I find it highly unlikely that this person does not know what they are doing. One does not simply "have" 25Ghs lying about without knowing their impact on the hashrate.
What does it matter if he splits his hashrate? That only hides the problem, because it's still only one entity controlling a third of the entire hashrate (like someone here wrote). Miner himself can't do anything harmful, only pool op can because it's a pool who is constructing a new block to mine, not the miner. |
|
|
|
Hey, i want to update to the newest version. Within the Linux 64 tgz is no longer a executabale file in the bin folder. No glue how to start the wallet  I guess you are talking about dash-qt, right? Open terminal, navigate to that folder and run it manually via "./dash-qt" or try this https://bitcointalk.org/index.php?topic=421615.msg12253785#msg12253785 if you are on Ubuntu |
|
|
|
I did the same thing, with Litecoin, when I first started! Freaked me out thinking that all my coins got stolen! Now I always reuse an existing address for change.
There is a it's a good idea to use fresh change addresses. Although, we won't have to worry about the problem for years to come. Once an address has been /sent from/ its public key is visible on the network. Eventually, years from now, a quantum computer may be able to compute the private key of that address given it's public key. But, since addresses are /hashes of/ public keys, un-sent-from addresses are not susceptible to this particular attack. I've proposed for some time now a feature to be able to add a static change address to the config file. Obviously this has potential anonymity issues, but on the other side of the scope it brings great benefits for many different types of operations out there. Be it at a private or corporate level.
The proper way to manage this is with deterministic address chains. (BIP32/BIP44) Best of both worlds. Fresh addresses and absolute certainty your funds lie within your chain/your control. Agreed. But how do I implement this with the QT ? Is this currently possible, or a future possible feature ? bitcoin devs are on it https://github.com/bitcoin/bitcoin/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+bip32 |
|
|
|
Probably bad news for everyone running their nodes with "masternode start" (i.e. using local dash.conf): I guess there's a bug with masternode self-activation somewhere. If you are using local dash.conf to start your remote masternode do NOT run this local wallet while masternode=1 is still in local dash.conf, I think it will try to self-activate for some reason and will drop your node to the end of the queue. Either set it to masternode=0 before you run it OR better option would be to use masternode.conf even if you only have one masternode. Sorry about that  PS. Code there became a bit messy actually because of many different options. I think we should stop using this one, clean it up and stick to masternode.conf method only to activate remote nodes while old dash.conf method should only be used for activating local Hot masternodes from now. PPS. Users with masternode.conf setup should not be affected by this. https://dashtalk.org/threads/v12-release.5888/page-52#post-66578 |
|
|
|
Hello, thanks for the feedback! Yes, I watched the past 3 votes pass with flying colors...and the system looks to be working just as it was intended to. I would love to get this promotion/marketing proposal on the budget management voting board. I see you have to have atleast (1) MasterNode to make this happen, or I can maybe have someone submit it for me? I have 260 Dash currently, so I'm a bit off from being able to host a MN...but I'd be willing to pay some dash to a community member to maybe submit the proposal for me? Cheers, MasterTrader777 Nope, there is no need to have a Masternode to submit a proposal but you have to pay 5 DASH as a fee. And tbh I wouldn't expect to see your proposal to be voted with that many "yes" or at least at the same speed as the first 3 one. Even though this system relies on a protocol it's still people who vote and I think these 3 were voted that easy because they were proposed and discussed a long time before actual voting happened. Another thing to remember is that they were posted by the dev team, specifically by Evan himself and people trust him a lot. I would recommend you to post your proposal on dashtalk in a new thread, describe it in detail and have a discussion with community first. That could save you 5 DASH if you found in early stages that there is not so many people who are willing to vote "yes" for it. But that's of course only my opinion (and advice based on it), you are free to do it the way you like.  |
|
|
|
Looks like we might be headed for a revaluation. Someone's been dumping 4-figure trades for days on Cryptsy and eroding all the support.
Possible re-settling at 0.008.
Maybe that person is afraid of the Bitcoin stress test thats going to happen next week and he predicts the price of BTC will drop because sending BTC will probably be broken with the stress test.  I think the whole stress test is overblown. Coinwallet is sending TXs with a fee of 0.0005 (eleven cents) and some miners are even starting to ignore their transactions and not put them in blocks. Even if they do get included, is it that much to ask to pay more than eleven cents to make a transfer? Float your fees higher and you have no problem, unless you're trying to send microtransactions.* *Coinwallet is trying to prove that Bitcoin blocks need to be made larger by spamming the network with a huge number of transactions. Ironically, he may well prove the opposition's point--that the system doesn't need fixed because TX fees can always be raised to cut through the backlog of TXs. The problem is not just "to cut through" to get your tx confirmed, the problem is also that huge backlog could lead small nodes to eat all free memory they have and simply die. That was the case during one of the previous stress tests. This however can be avoided by rising relay fee on such nodes but some legit low fee txes will stop to propagate too in that case so no easy one-solution-fit-all here imo. |
|
|
|
Is there a simply guide how to build the Dash Linux daemon from source?
i read the instructions in the source but I was having building problems and thought that there might be something that I was missing or that the build environment is incorrect.
This one https://github.com/dashpay/dash/blob/master/doc/build-unix.md ? What kind of build problems did you have? Post error here and we'll try to help. And btw, check "Dependencies" section there first. Thanks UdjinM6 for the pointer, I'm checking it out and correcting a few errors; I had the wrong version of libdb and also no swap space. Fixing these problems and trying again. Update: seems now that when running make, it crashes when attempting to build libbitcoin_server_a-main.o ~/dash_git/dash$ make
Making all in src
make[1]: Entering directory `/home/****/dash_git/dash/src'
make[2]: Entering directory `/home/****/dash_git/dash/src'
CXX libbitcoin_server_a-main.o
g++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.8/README.Bugs> for instructions.
make[2]: *** [libbitcoin_server_a-main.o] Error 4
make[2]: Leaving directory `/home/****/dash_git/dash/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/****/dash_git/dash/src'
make: *** [all-recursive] Error 1
****@masternode01:~/dash_git/dash$ free
total used free shared buffers cached
Mem: 501800 174040 327760 16 1780 25236
-/+ buffers/cache: 147024 354776
Swap: 1048572 205620 842952 In most cases this "g++: internal compiler error: Killed (program cc1plus)" means you need even more memory for compiler otherwise OS see that it running out of memory and kill the heaviest process. Make swap 2Gb for example and try again (I have 4Gb just in case). |
|
|
|
Is there a simply guide how to build the Dash Linux daemon from source?
i read the instructions in the source but I was having building problems and thought that there might be something that I was missing or that the build environment is incorrect.
This one https://github.com/dashpay/dash/blob/master/doc/build-unix.md ? What kind of build problems did you have? Post error here and we'll try to help. And btw, check "Dependencies" section there first. |
|
|
|
per the official websites mining page https://www.dashpay.io/mining/I downloaded the ccminer optimized for GTX 750 Ti and AVG is picking up that ccminer as a threat "ADP.ARES.Generic" I want to assume this is a false positive, but figured I'd get some feedback first? DISCLAIMER: This list is provided for informational purposes only. Services listed here have not been evaluated or endorsed by the Dash developers and no guarantees are made as to the accuracy of this information. Please exercise discretion when using third-party services.  I think it's better to ask author there https://bitcointalk.org/index.php?topic=770064.0 |
|
|
|
Talking about masternode payments, is it me or do the MN payments seem to have like a 3 day period these days ?
Probably because mine keeps dropping off - ugh  crash on v51? not since V51 - yet - I keep watching... edit: Active Duration 1 day 21 hours 28 seconds edit 2: I tried to shut down the MN and restart in within a few minutes and it reset my MN to the back of the list - so if you have the corr3ect MN re-start CMDs that would be great because it's not working for me That's strange... I restart daemon many many times each day (only daemon, no "masternode start"!!) - it never dropped to the end of a queue.. |
|
|
|
Talking about masternode payments, is it me or do the MN payments seem to have like a 3 day period these days ?
Probably because mine keeps dropping off - ugh crash on v51? |
|
|
|
Another good episode is Let's Talk Bitcoin! #241 - The 'Big Blockist' Perspective https://letstalkbitcoin.com/blog/post/lets-talk-bitcoin-241-the-big-blockist-perspectiveAdam talks about the block size and puts it into perspective based on transactions available. Currently, bitcoin can only do 2-4 transactions per second. So if 64 million people want to transact in bitcoin, they could only make 1 transaction per year with current block size. If we look at banking transaction, this is what is needed for blocksize for each. US Bank Wires(150 Million transactions) = 1.7MB Swift(international) wires(5 Billion transactions) = 53.3MB ACH(19 Billion transactions) = 202.4MB Thinking about the 202.4MB blocksize? That would add 29GB to the blockchain EACH DAY. Almost the entire size of the bitcoin blockchain today. Now to figure out how DASH does with this same metric. What is the average transaction size? I looked at a raw transaction and it had 3500 characters without spaces. Assuming a character is a byte then this size is 3500bytes. /1024 to convert to KB = 3.4KB Am I close on this? block size: https://bitinfocharts.com/comparison/size-dash.htmlnumber of txes per day: https://bitinfocharts.com/comparison/transactions-dash.htmlnumber of blocks per day: https://chainz.cryptoid.info/dash/#!overview (number of blocks per day) x (block size) / (number of txes per day) EDIT: wrong chart, fixed |
|
|
|
Talking about masternode payments, is it me or do the MN payments seem to have like a 3 day period these days ?
Same for me for a while. I guess the previously used reference node just wasnt as efficient as this decentralised method of processing mn payments Something strange. My was payed after almost 6 days... And now wallet stopps at 75%. V51... try "mnsync reset" in console |
|
|
|
- When you restart your masternode with either "masternode start" or "masternode start-many" or "masternode start-alias" command, you are forced to the back of the queue. Please remind, what for? Let me correct this ^^^^^ Daemon restart is ok. |
|
|
|
...snip.... wrong version !! wrong protocol !! correct version 0.12.0.51 correct protocol 70103 edit : unless he is still trying to upgrade from wallet 0.11.2.23 to v0.12.0.51 ? In that case ignore this post.. no worries, guided him via PMs should be up and running soon |
|
|
|
************************
EXCEPTION: St12out_of_range
CInv::GetCommand() : type=15 unknown type
dash in ProcessMessages()
That happens when a v11 client gets a v12 message which it doesn't yet know. Build a v12 client from here: https://github.com/dashpay/dashi compille wallet from this source - https://www.dashpay.io/downloads/ - ( https://github.com/dashpay/dash) my wallet { "version" : 110223, "protocolversion" : 70076, "walletversion" : 61000, "balance" : 0.00000000, "darksend_balance" : 0.00000000, "blocks" : 0, "timeoffset" : 0, "connections" : 0, "proxy" : "", "difficulty" : 0.00024414, "testnet" : false, "keypoololdest" : 1432325190, "keypoolsize" : 1001, "paytxfee" : 0.00000000, "relayfee" : 0.00001000, "errors" : "" } Version Protocol Version Wallet Version Peers Status Blocks Accounts 110223 70076 61000 0 OK 0 1 git checkout master git pull |
|
|
|
|
Show Posts
