Search results

I don't have them running side-by-side, but using two datadirs and rpcports should work. cd ~; mkdir .darkcoin.masternode .darkcoin.liqprov #~/.darkcoin.liqprov/darkcoin.conf #---- rpcuser=nicelonghexstring rpcpassword=adifferentnicelonghexstring rpcallowip=127.0.0.1 rpcport=9996 #----...

Looks like you can run it beside a masternode. Doesn't need to listen on port 9999. my aggressive (mix every 30 blocks) darkcoin.conf #---- rpcuser=stuff rpcpassword=stuff rpcallowip=127.0.0.1 rpcport=9998 #---- listen=0 server=1 daemon=1 logtimestamps=1 maxconnections=256...

Have everyone update again, and enable enforcement on Friday. Let's shake out the bugs one layer at a time.

10% of my nodes were affected (wrong fork.) Whether or not that's representative of the network, I can't say.

Looks like one day. 576 blocks. darksend.cpp 1300 bool CMasternodePayments::AddWinningMasternode(CMasternodePaymentWinner& winnerIn) 1301 { 1302 uint256 blockHash = 0; 1303 if(!darkSendPool.GetBlockHash(blockHash, winnerIn.nBlockHeight-576)) { 1304 return false; 1305 } ...

left liquidity provider darkcoind version:101602, running all night with a 125 DRK deposit. Saw some normal denominations 100,10, etc. Next day: user@box:~/.darkcoin$ darkcoind getbalance 124.93850000 user@box:~/.darkcoin$ darkcoind listunspent | grep amount "amount" : 96.24668080...

patience. I have nodes not paid since Oct 8, Oct 16 -- give it time. Is the nature of non-enforcement.

One more v0.10.16.1 provider with 125 DRK now online and mixing! I've set darksend_blocks_between_successes to 24 -- allowing mix once every hour at a cost of 0.3DRK/day. Any issue with that?

setting up v0.10.16.1 on pc: https://bitcointalk.org/index.php?topic=421615.msg9309514#msg9309514

You're welcome. Glad to assist. I'd like to see an introduction built into the wallet that covers (in plain english) things like: Darksend requires two other participants mixing at the same time: don't watch it, leave it overnight or for a day or more. And 'if you're already mixing, your newly...

I got that on a fresh wallet (fresh deposits from 0), but went to bed and found stuff mixing when I woke up. We need to teach people that darksend isn't something you watch, it's an overnight/daylong process.

you can also do this in darkcoin.conf listen=0 enabledarksend=1 darksendrounds=99999 darksend_blocks_between_successes=57 and you can set datadir in a shortcut as: C:\Users\YOURUSER\Downloads\darkcoin-0.10.16.1-win\32\darkcoin-qt.exe...

I've launched v0.10.16.1-gd6431b3-beta on an existing wallet with 78 DRK (all I have currently) already sent through 8 rounds. It's denominated into: 7 x 10.00000001 + 7 x 1.00000001 inputs plus some change Am I understanding you correctly that this will only attempt to mix with people mixing...

did you update to 101514 ?? mine are fine since the update.

src/main.cpp: if(nHeight > 158000) ret += blockValue / 20; //25.0% - 2014-10-23 block 158001 is the shift. Assuming 2.5 minute blocks thats 46.6 hours from now. w00t!

Does propulsion run p2pool nodes? That, I think, should be our ultimate goal. Distributed everything-possible. (and estimates from many sources to calculate max p2pool bandwidth)

I agree that POS is bad due to GPU > CPU. Is that what you mean, oblox?

While I'm interested in p2pool implementations involving masternodes, onion routing (masternode ip masking) would (should!) hide the ips' p2pool might need. Proxy services (servers) could be built to support the p2pool traffic as a onion/garlic-routed service frontend separate from the...

I'm not fully versed on POS, but it seems to me that the bigger the hash, the bigger the protection. I can't see 3000-100000 cpu's offering as much blockchain integrity as Gigahashes can. If we can assess the bandwidth impact, I'm interested in how p2pool could work with masternodes too.

I would love to see this providing we can estimate bandwidth usage against existing implementations.