bitterness and self loathing
Kill yourself now mate, life just gets worse!  |
|
|
|
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.
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. 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. 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. |
|
|
|
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.
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. |
|
|
|
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
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. |
|
|
|
All that matters is a good strong solid anon coin. For me the price isnt important to watch until that is established. In the end people will go where the quality is.
+1. Personally, it think it will be drk. I think it will be worth the wait and trouble. As I see it, there are two situations that could be going on. 1. Evan is screwing us over. 2. Evan is keeping it closed source and not talking much, because he is producing a product (Hate that word, but can't think of anything better) that is much, much better then the competition. I'm (Personally) sure that it's #2. #1 - no way #2 - yes, he's reviewing all ideas to see if there is a better way to do this that won't cause forking. I made a suggestion, but InternetApe said it was centralization, however, I think he is wrong. But I'll put it out here and see what you all think? I realized that the reason we don't pay masternodes each a shar of the 20% block reward is because there are so many masternodes, and to do hundreds or thousands of transactions for each block would obviously bulk up the block chain, not something anyone would want. But what if an account - no, call it a secondary blockchain that is volatile, it is dumped once it completes it's task. This thing keeps track of each available masternode, for each block, awarding them a share if they were available, and then also collects the 20% mining rewards. Then once a day, this account pays all the masternodes at once, with one transaction, a percentage of the purse depending on how many shares each masternode submits, kind of like a pool. Once the payment is made, the account is cleared, all the tallying for the day is deleted and the system starts afresh. Every wallet would process this information, keeping a copy of it, like the blockchain, except that it is volatile information, and it goes away once the payout is made. Do you all think this is centralized? I think it's no more centralized than any single transaction, unless I'm missing something? 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  |
|
|
|
I think this is really good for the coin, it takes the pressure off from the implementation schedule. For every buyer there is a seller, we need investors not speculators, and more importantly we need time. It is obvious that Darkcoin is a real project, the fact that the masternode payment system worked for a while and then broke is a symptom of reality. It feels good, you know the devs are working on something that's complex, once we get it right its going to be great.
On the other hand, I hold a lot of drk and I just cant bring myself to sell high to buy lower, it just doesn't feel right to me. It makes me feel like I am doing a disservice to the coin. I know is silly because I could easily crash the market to buy lower but it makes me feel like I would be hurting something I believe in. I think I am too idealistic to trade so I am in long-term.
I made about 200 DRK today in dribs and drabs, but I feel no shame in relieving idiots of their DRK, the higher the communal IQ of investors, the greater the eventual price and stability will be. No.1 and the rest of the smart money haven't gone anywhere, so I aint worried. |
|
|
|
End of June: MRO 'devs' still wont have figured out how to use qt-designer, XC will still make me giggle every time I hear 'transdimensional gestalt paradigm' and DRK will be sitting pretty with still the only actually working anonymous means of shifting money about  |
|
|
|
when they enter the badroom
That's what I'm buying when DRK hits $50 - a badroom. Always wanted one of those.  |
|
|
|
More DRK being concentrated in fewer wallets... mine among them. |
|
|
|
spam
Shouldn't you update your sig - you're still promoting the last copy/paste crapcoin you got suckered by. |
|
|
|
Maybe all the FUD, attacks, etc. in the last month have left me skittish -- but I wonder even in the short term what might happen to the coin if there is an organized effort to hurt DRK based around pools cheating. If Evan does go through with this then I hope I am just worrying over nothing.
If? It is a given that at least half the pools and big farms (a lot of them nowadays) won't be paying. So the 20% will be more like 10% for the masternodes, =what they were expecting anyway. But it will be a disproportionate weight to the "fair" pools. The whole thing to appease investors with "ok guys no hard forks" and bagholders of masternodes with "ok guys you'll get 20%" is sketchy. I know I'm harsh but I like things to go right  Price is price. It'll go up, down, sideways etc. Let it be. All the price attention is having an impact in development. Development must proceed as planned so we can have the final product, nice and polished - no matter if it takes 1-2-3 or 5 hardforks and no matter if investors are bitching that they are losing masternode income because the implementation is late. Do they want to have masternodes of a coin that is GOOD or do they want to have a masternode of a coin that is doing hack-arounds? The masternode protocol works, the masternode payments work (we saw them - it's not vapor), it's just that there is something introducing instability which has to be debugged and sorted out. If the origin is difficult to trace, then perhaps a different mechanism can be used for doing the payments (not voluntarily) We also need improvements in DarkSend. The competition (MRO) is integrating I2P (as we've said) and XC will be using encrypted communication between nodes (as it has been said of DRK's future plans as well). I know this sounds like a mom's "to-do list" to the child until she gets back home, but priorities are priorities, and price or reaching litecoin immediately are not a priority. If the code is sorted out and the product delivered in final form, LTC will start rolling down. Too fast of a price rise with a half-baked product is problematic. LTC can't compete anyway in fundamentals like inflation (10x the BTCs to absorb LTC production compared to DRK) or innovation so they will be dead anyway by debasement. #2 is a given. Preserving #2 is not due to the competition. Who is gonna buy 300k USD of LTCs per day? It'll go 0.019 -> 18 -> 17 over time. It doesn't look that "hot" of a property. Only buys will be for cost-averaging buys at 0.025+. Having said that about the #2 competition, the anonymity competition actually looks pretty lame (BCN and clones too many issues, XC mostly vapor for now but that could change a few months ahead as they seem to have the prospects of delivering a product similar to what Evan has at like 70-80% completion). But we can't base our strategy on others failing or being pumps & dumps that are "threatening" us due to pumps => we must excel and take the market. Then bring V2 for "fatality". Otherwise the risk is there for more serious contenders appearing. My 2 duffs. Apparently I have more faith in humanity than anyone else around here I'll implement the masternode payments via hardfork, who knows, maybe all of you are right. By the way, I'm not talking about the price now or even in a year. It's about the security of the network when it's large enough to support a decent amount of transactions. Giving a higher reward simply doubles or triples the cost of such an attack, 10% was just too low. A lot of minds set at ease there hopefully. edit: and thank you! |
|
|
|
I'm wondering if those of you with Masternodes are more interested in going with Evan's new proposal so you can start getting paid, or would you rather Evan take more time to get the original implementation, or something similar working? I'm curious to know, I know where I stand (I'd rather he take his time) but don't know where you all stand  Please comment Need to get it right this time. Idiots losing coins due to their own crap security is one thing, but the system itself needs to be solid. So: it'll be ready when it's ready hopefully, I'm in no hurry. If you need crash test dummies for testing, I've got rigs and nodes to spare. |
|
|
|
I'm going to go ahead and quote myself for effect, because I think this is important:
------
I hate to say this, but handing out an ISO for a MN built by a competent person is in a very real way analogous to handing out condoms to horny teenagers. You can tell them not to fuck all you want, but they're still going to do it. At least if they have rubbers they're less likely to get the drip-dick or pregnant.
In this case, if MNs get a rep for being a major Achilles heel to the coin and people start looking elsewhere, we're all screwed. All of us.
It's not my preference, believe me, but in the bigger picture it may be the safer thing to do. Anyone who's ever run a business will understand the need to eat a shit sandwich for the greater good now and then.
And I'll requote you for bigger effect I'm not sure if we need an official ISO, or published best practices, or lectures, or whatever. But we need something to avoid people losing coins and damaging our image. I believe that most people who are running masternodes are eager to learn about this if they don't know enough. And no matter how competent each one is, everyone can use some more ideas on how to secure his masternode. Masternodes are a target and will be attacked, this much is certain. If a properly locked down ISO is provided and best practices are published and adhered to, it will help mitigate the inevitable. Of course, cold storage would solve most issues. Have the MN validate the private keys to the cold storage and check the balance, or something. Good to go. (Yes, maybe it's a little more complex than that.) Just establish your masternode on a VPS....or through TOR. it's pretty easy and makes your real IP unknown. How does a VPS 'make your real IP unknown?' Do you mean the local/remote setup? If so sure, but right now it's impractical to run more than one MN in that config, unless you also have several (or twenty, whatever) running boxes at home |
|
|
|
I'm going to go ahead and quote myself for effect, because I think this is important:
------
I hate to say this, but handing out an ISO for a MN built by a competent person is in a very real way analogous to handing out condoms to horny teenagers. You can tell them not to fuck all you want, but they're still going to do it. At least if they have rubbers they're less likely to get the drip-dick or pregnant.
In this case, if MNs get a rep for being a major Achilles heel to the coin and people start looking elsewhere, we're all screwed. All of us.
It's not my preference, believe me, but in the bigger picture it may be the safer thing to do. Anyone who's ever run a business will understand the need to eat a shit sandwich for the greater good now and then.
And I'll requote you for bigger effect I'm not sure if we need an official ISO, or published best practices, or lectures, or whatever. But we need something to avoid people losing coins and damaging our image. I believe that most people who are running masternodes are eager to learn about this if they don't know enough. And no matter how competent each one is, everyone can use some more ideas on how to secure his masternode. Masternodes are a target and will be attacked, this much is certain. If a properly locked down ISO is provided and best practices are published and adhered to, it will help mitigate the inevitable. Of course, cold storage would solve most issues. Have the MN validate the private keys to the cold storage and check the balance, or something. Good to go. (Yes, maybe it's a little more complex than that.) |
|
|
|
funny thing about your XC dev is : he was a summercoin fan .. looks like xc is also made in china XC - we don't know who our dev is DRK - Darksend is anonymous, not the dev. |
|
|
|
gibberish
Darksend works already, with some beta limitations. Masternode payments start again on 14th June, last I heard. edit: managed to get a 0.6DRK masternode payment on one of my nodes just before The Antifork |
|
|
|
it will leverage multi-path paradigm topology
LOL, away with you, you gibbering cretin. You will get dumped by all and sundry before you manage to produce a single drop of your snake oil. Who is your dev again? XC - as useless as MRO, but with bigger words! |
|
|
|
|
Surely there is some way of just ignoring old/outdated/tampered with versions of whatever software the pool ops are running, to force upgrading and prevent cheats.
This is an old problem, has it not been solved over and over again?
Pool provides some checksum/whatever to masternodes/network, gets told to sod off it it isn't what it should be.
|
|
|
|
I am just going to throw out there what I said the other day... I wish I could find the article I read, but I am sure someone else read the same thing. I don't always understand where people come up with their analysis, but so far he seems dead on, and I am encouraged at the possibilities still.... not wavering one bit.
To recap, he stated that so far DRK has followed the same pattern over and over (I think he said it has happened 5-6 times already), and that is the price of DRK climbs 5x, and then has a 40% sell-off.
Well, the price peaked at .0277 btc before this latest drop started...
Using that number, .0277 x .6 = .01662
This is right about where we have seen the price finally settle after some valleys & peaks trading around this level.
So assuming he is right, sometime in the next couple of weeks the coin could be heading upwards to the .0831 neighborhood ($48.04 based on current price of BTC).
Just repeating what I read really, but until I see different I think it is the best analysis I have seen.
This makes sense. The general consensus is that at some point DRK will test LTC. This isn't only my belief, or the beliefs of the full time trades I talk with on a regular basis, but also the belief of many prominent BTC evangelists, writers and investors. But the price can't just jump up like that, it has to do it in swings, it's how markets work. All the people selling now are just short term investors who can't look past the 15M charts and think this downtrend is the end. I really wouldn't worry about the price right now, it will settle soon and then we will see another huge uptrend. Me, and so many other experienced traders are just using moments like this to increase our stake. Darkcoin is the most innovative coin since bitcoin, fullstop, I would seriously like to see a competent argument against this, There isn't another coin out there that can influence the way the market works in the way this coin can. Don't worry about the price, and if you are, just make sure your in before the next jump. I don't think there is anymore than two before we test 0.1 To put this in perspective, I'm now sitting on my first loss in six months. Am I worried? Nope. This is called price discovery, and we can't move up again until we shake off all the weaker investors from this recent rise. Some people just don't have the stomach for swings, these are the people who more often than not lose money. Anyways, from my perspective, the more the price drops the better. It just means were shaking off more of those investors and getting more serious ones in. I mean shit, who else buys near the end of a downtrend apart from good investors? Because its defiantly not the weak investors, this is exactly when their supposed to sell. Exactly. > 85% of coins are now in potential masternodes (adresses with more than 1000 DRK)
Holders may understand they cant accumulate more than 85% without hig risks to lose everything. Manipulation and dumps will be harder now, and are a total waste of time on the 500 M$ marketcap route.
Up from 80% yesterday. Actually manipulation becomes easier in one important way - when a small group owns the majority of coins, guess who dictates the price. When the chocks come off, the next rise is going to be big. Darksend and the masternode system will simply evolve faster due to the recent lessons learned. Good to see Evan getting offers of skilled help! About masternodes in the hands of the inept, shit inevitably happens. Nothing can be done about that, dunderheads will be dunderheads, but I think eltito and others are right in that an ISO with good secure defaults and a more detailed 'official security procedure' somewhere will go a long way to keeping problems to a minimum. |
|
|
|
I'm getting an odd problem with my client.
Every time I try to send, it alters the amount to 0 and erases the address, calls it a send to self of 0DRK and still shows confirms... Damn strange.
Restarted client. Now different effect...
Only applies to using darksend. regular send works fine.
Waiting for entries 1/3. Stays that way until a block pops, then says idle and poof, like the darksend attempt never happened... Absolutely no log output in regard to it.
I'm not even sure where to look... Fuckin' weird...
Now spontaneously back to "payment to yourself" shit... Address is definitely not mine...
Darksend is just plain broken.
It just timed out while waiting for other inputs. Nothing ended up being sent anywhere, that's all. Working as intended within beta limitations. |
|
|
|
|
Show Posts
