Topic: [ANN][DASH] Dash (dash.org) | First Self-Funding Self-Governing Crypto Currency - page 5485. (Read 9723733 times)

Yep, im going to panic sell my DRK now! 

Honestly I've never understood this 'voting' thing.

On every block, get current known good masternode list, pick one at random, pay it. Why does it need to be more complex than that?

Are the six votes needed because the current list is slow to update, untrusted somehow, what? It's not like you can easily game the system by suddenly turning on a hundred masternodes every two and a half minutes. Is it?

Feel free to call me an idiot, but I'm pretty sure I'm not the only one confused about this, so any explanation appreciated.

darkcoin is the same as the other shitcoins PUMP AND DUMP

0.0113 toch 50 BTC buy ))

Thanks for 20 btc in this pump!

More one doubt:

How do you prove that a random node was selected, tho?  Under most random implementations, the miner could pick whatever masternode they wanted.  If you're talking quasi-random based on some kind of prev blockhash, then the problem is predictability, although in this case that might not matter as much as say with block rewards.

Surely this just adds extra overhead and doesn't really affect the results over time.

Select one MN at random from the MNs currently available, pay it, job done.

Don't forget to panic folks.

You make most money that way - whether it's a panic sell or a panic buy, when you feel that wince in the pit of your stomach, thats the signal to DO SOMETHING.

It’s the first rule of markets that trading in a panic is THE best way to optimise profits or mitigate losses   

If you need it spelled out to you then here's my 4 point guide:

[1] - as a warm up, pull up a BCW 15 minute chart at maximum scale and wrap your eyes round a few of those red candles for about 20 minutes

[2] - get yourself loaded up on some fresh FUD in the DRK [ANN] thread from prime sources such as mr_random, ymer and ac2. Focus in particular on the fear factor from XC coin - its sh*t hot dev who MUST be better than Evan cos he’s done all that work in radio networks and stuff. Check the guy’s LinkedIn CV once more just to ram that point home

[3] - get onto Mintpal and check the liquidity on the bid side. Hopefully there won’t be much so you can actually contribute to driving the price down while you offload and make doubly sure this mother doesn’t come back up

[4] - check you’ve thoughroughly lost your appetite by now and, despite having a mouth as dry as a badger’s ass have convinced yourself that this coin is never ever nunca nada coming back to anywhere near the last trading price ever again and FIRE !! (Make sure you get rid of your entire holdings without trace)

Oops.

[5] - now that the shoe’s on the other foot, start panicking again. Hope to f*ck that Even doesn’t deliver on his roadmap or expand his development team to include a load of sh*t hot coders that don’t have day jobs and can concentrate on the project full time. Hope to f*ck that DRK’s commercial approach doesn’t attract more buy ins from masternode wannabees and drive the price back up. Hope to f*ck that that sell off wasn’t nothing more that just the 12-hour and 4-hour MACD crossovers coinciding and triggering a spring tide profit take by speculators who will buy straight back in again once they cross again to the upside. Hope to f*ck that the fudster material you read in the threads was well researched and made in good faith by non XC and Monero bag holders.

Yes indeed. That panic button is the boy. Press it, and hope to f*ck you maximise profits is the way to go 

I don't like the masternode idea myself (quasi-centralized anonymous spends seem just plain silly), but here's a possible idea for handling payments:

When a masternode comes online, it broadcasts its pretense to the network, and joins the back of a payment queue.
Miners maintain a list of masternodes, along with the last payment time.
The masternode that hasn't been paid in the longest gets a chunk of the next block.
The masternode that was paid then falls to the bottom of the payment queue.

Checks could be coded into block validation that ensures the right masternode was paid, and if not, nodes reject the block.

No, I think you misunderstand how the masternodes will be paid under the current implementation, once masternode payments are turned back on.  (Somebody please correct me if I'm wrong.)

There are hundreds of masternodes.  Each of them is available to perform coin-mixing services.  The people who want to send coins pick a masternode, somewhat at random, but once one is picked then others join in and send their coins to that same one.  The masternode performs the mixing, the mixed transactions get included in the block, and that masternode receives payment within that block for services actually rendered within that block.

So out of the hundreds of masternodes, there might be just a handful that actually perform the mixing and receive payment for any given block.

This makes perfect sense and is actually a good way of making payments.  It would be extremely difficult to keep track of which masternodes are connected all the time, and keep up with the accounting for all of it.  It is far more efficient to only pay a few masternodes on each block, which have been chosen randomly by the clients sending coins.  So masternodes will not be getting a perfectly steady income due to the random chosing, but it will average out over time.

I'm dying of laughter here... Literally dying...

On the positive side, vs. the previous week at least it's less than half the cost to have the POS required to run a masternode.  

It is... 50 btc buy walls appear out of nowhere.

jupp..  even selling only to buy back is risky

Yes... alternate system involves a system in which greedy miners won't be so greedy - kind of semi voluntarily running a client which pays the nodes.

Given the past record of people mining DRK (they were sitting at coinmine for extended periods despite >51% hashrate back in March) that would present problems implementing and would be the wrong way of doing it really. It's a hack that will be hacked for selfish gain. Better do it the right way, after finding the bugs and eliminating them (or using a different mechanism).

at times, i get the urge to give you a man hug.

don't take that the wrong way. I'm completely hetro.

i can imagine a large proportion of people rather risk the short term gains and I wouldn't call a $15 to $7 drop just a short term swing.

Needs a hardfork to force pool compliance I think.

What would really be good news would be to hear from Evan that he's figured out what was causing the forking last time. My suspicions are the p2pool code but I'm pulling that out of my arse really, I'm no expert.

if the masternode payment problem can allegedly be fixed without a hard fork, why is evan considering hard forking for the payments again? can someone explain the rationale here

Must be having a blonde moment, I'm not seeing the problem here? Block processed, 20% reward goes to randomly selected MN, it adds a fraction of a microsecond and one more transaction per block. Where's the bloat