|
Enforcement is active, setting it for 15 minutes into the future
|
|
|
|
its just the hardfork for MN payments that has a delayed activation for either waiting for a certain pools compliance % or waiting for a certain time period, if one of those two conditions is met the
hardfork will be activated. This methode is also known as the spork update methode. The activation will be issued by Evan and then the hardfork will be active, forcing the mining pools to be on the right
darkcoin version or to have their mining efforts (on the wrong darkcoin version) rejected by the network.
We are using the spork methode for some time now, i dont understand why yr so bothered with it all of a sudden.. it gives the pools and the users some time to prepare and its more gracious then
forcing a hardfork down everyone's throat on short notice. The update methode is perhaps in a small number of hands (centralisation) but thats with all coins, even Bitcoin.
The lead developer is both in charge and has the responsibility over the coin he is developing, some times the lead developer operates alone.. sometimes he forms a team .. but it will still be a few experienced
people developing the code, or in this case flipping the switch.
My assumption was always that it is part of all the users to update to the new version, and that's it.Everything else (grace period, automatically going hardfork, etc.) is in the code itself.So I think I just get confused by all those gifs and all those phrasings like "it's in evans hands" and "the activation will be issued by evan" etc... He doesn't trigger anything at all.It's just that he creates a new version and it's the people who have to update and then the spork code in the new version waits for a period / formula before going hardfork. Evan triggers nothing, he just creates new versions and people have to follow. So again, I think everything is clear if explained like that, it's just that how people depict it or make it sound like is confusing sometimes, especially to newcomers. I need a coffee. Case closed. From the first post: Multi-Phased Fork Implementation (aka the “Spork”) In response to unforeseen issues with the rollout of RC3, the Darkcoin development team created a mechanism by which updated code is released to the network, but not immediately made active (or “enforced”). Communication is sent out to users informing them of the change and the need for them to update their clients. Those who update their clients run the new code, but in the event of errors occurring with that new code, the client’s blocks are not rejected by the network and unintended forks are avoided. Data about the error can then be collected and forwarded to the development team. Once the development team is satisfied with the new code’s stability in the mainnet environment - and once acceptable network consensus is attained - enforcement of the updated code can be activated remotely. Should problems arise, the code can be deactivated in the same manner, without the need for a network-wide rollback or client update. This innovation allows for far smoother transitions than in the traditional hard fork paradigm, as well as the collection of test data in the live network environment. We set out with the intention of calling this method of updating the “Soft Fork”, but the Darkcoin community quickly dubbed it the “Spork” and the name seems to have stuck. ------------- I control the key that turns the spork on and off, and it allows me to gather information on mainnet for a period of time before activating the code. If I see something is wrong with the spork, or have some other network issue I can turn it off at any time. I.e, A spork and a soft and hard fork at the same time. So the code immediately starts doing the soft-fork actions, but it will only reject blocks when enforcement is activated. https://github.com/darkcoin/darkcoin/blob/master/src/checkpointsync.cpp#L514https://github.com/darkcoin/darkcoin/blob/master/src/main.h#L1673It works by extending the checkpointing system, which I also have control over, so that it tells the network if the current spork is enforced or not. Yes, it's centralized, but it allows hard fork after hard fork without the risk of destroying the entire network or issuing emergency rollbacks of patches. But we don't need this forever, once we have all of the tools we need for the perfect eCash, we can get rid of checkpointing and sporking. For now though, it's allowing us to be very nimble. |
|
|
|
|
Enforcement is right around the corner. Messages are now propagating perfectly and we've updated enough to turn it on from that perspective. I've sent an email out to 4 bigger pools that need to upgrade their stratum, then I'll flip the switch.
|
|
|
|
Now my mixing is 100% but my Darksend Balance is only 4.00000004 DRK. Amount of 5 DRK is set.
You can anonymize amounts in denominations (1+10+100+500) and it requires fees to anonymize, so there's always up to 1DRK left over. Looks like it worked! |
|
|
|
Anybody got lucky here with the 1000drk on Cryptsy @ 0,0052?
I got those  |
|
|
|
I dont know why but on drk.mn ltc1btc.com shown they are not at newest wallet. Today at 7 a.m. GMT+1 they wrote me an email saying they updated to 0.10.15.16
CryptoADHD updated...they emailed me too.
Evan do we rly have to wait and inform always pools as new wallet version comes out? Can't we just give them 3-7 days to update and then enforce the net how it is???
We loose time for next improvments don't you think?
Release versions are tested for a period of time on testnet before release and pools should only have to update a few times a year after this. However, v0.10.15.13/v0.10.15.14 caused network fragmentation due to the client banning others when it shouldn't have. In the future we'll have better processes for more extensive testing. |
|
|
|
my internet connection is a bit buggy last time, disconnects and so on. could that be the reason for the 0.1 fees?
yep, that could very well be it... just sent Evan an email and maybe he can get you these 0.1 fees back as they are all gathered in a certain holding depot Yeah, that's too bad. That's a lot of collateral fees. However, fees are paid directly to miners now to avoid the possibility of double spend attacks. You could reach out to the pools that processed the transactions and ask for the DRK back. |
|
|
|
This is for TEST NET ONLY  ?? RIGHT? Nope. This is for mainnet. Only those who want to run a liquidity provider need to run it though. |
|
|
|
So the network instability - MNs getting disconnected, missing payments, wrong payments... that was caused by MN operators changing masternodeprivkey keys?
Edit: I thought we were awaiting enforcement to be the fix for these issues
For some masternodes it was caused by these invalid messages propagating around the network. However, missed payments and wrong payments will be fixed by enforcement. In a few days the system will be humming. |
|
|
|
v0.10.15.15 - Onyx Masternode Stability Update There have been some masternode stability problems (masternodes not staying active on the network) for some users, this was caused by the masternode operators changing the masternodeprivkey and then starting the masternode again. This lead to some of the networking have one pinging key and parts of the network having another. This update fixes that issue and will allow masternodes to change that key. Because of this issue clients were flagging peers as misbehaving, eventually leading to them being banned, causing network fragmentation, which lead to other issues on the network. An alternative solution is to move the 1000DRK input to a brand new address that the network has not seen. Then start the masternode normally. Once the network updates to v15.15, we won't have these issues anymore. Enforcement: At block 158,000 masternode rewards will jump to 25%, if more than 80% of the network is updating and paying the correct rewards enforcement will be activated then. From the looks of it, we're very close to those numbers already. Once enforcement is active, payments will be completely 100% fair and equal between all masternodes. 10.16.16 Onyx Binaries: All Users Source: https://github.com/darkcoin/darkcoinWindows .exe: https://github.com/darkcoinproject/darkcoin-binaries/raw/master/darkcoin-0.10.15.16-win.zipMac OSX: https://github.com/darkcoinproject/darkcoin-binaries/raw/master/darkcoin-0.10.15.16-osx.dmgLinux: https://github.com/darkcoinproject/darkcoin-binaries/raw/master/darkcoin-0.10.15.16-linux.tar.gz |
|
|
|
v0.10.15.14 - Onyx Update 15.14 Adds a fix for a DOS style attack against the masternode list that was attempted earlier today. This attack didn’t result in any harm to the network or extra payments for the attacker, but I've patched it to stop the list from bloating up. This is not mandatory, but please update if you can. https://www.darkcoin.io/downloads/ |
|
|
|
Apparently, I have no idea how to navigate git... Lols. I still don't. Link == win. 512MB vultr $0.007 SSD plans can't build... RAM insufficient... build local, scp... You can make some swap space, buy yeah if you have lots of MNs it's quicker to build it on your pet monsterbox, scp it to one of your MN's and then use that to push it to the rest, much quicker than uploading umpteen times on a domestic connection, unless you're very lucky in the local fibre department. Unfortunately, that link didn't help me, it's still not 10.16... I'd love to give this a shot but when I git clone the URL on the start-many branch, it's 15.13 I'm unsure if anyone is quite advocating main net use yet but here it is: https://darkcointalk.org/posts/26020/It's been shocking how popular this feature turned out to be. I just pushed up a draft of the code to github to basically save it, so I didn't lose it. It's not perfect and not nearly done, although, there's really no risk to using it. From what I've seen it works pretty well. |
|
|
|
A notion just struck me...
When denominating a large chunk that gets submitted, doesn't get enough entries, gets submitted, doesn't get enough entries... This happens hundreds of times before 3 finally show up... Does the failed entry process give anything away? It happens so much you're pretty much guaranteed to have submitted it to every masternode in the network several times before it actually happens, so couldn't just a single rogue node monitor/track large chunks through this process of repeated submissions?
The presubmission phase is where the client just says "hey, I'd like to mix these denominations here", then the masternode broadcasts a message saying it's accepting more clients. If it gets 3 of those "hey, I'd like to mix" messages, it'll tell those users to submit their actual transactions, inputs+outputs. So the system doesn't reveal any information until the actual mixing is about to happen. Look at the "dsa" and "dsq" message events in main.cpp for more info. |
|
|
|
It's the same miner that was paying his own masternode: XixmyNSGGGXEJEzKghoRnTto5ZVhficSek Gotcha. Looks like he'll get cleaned up in a week. Thanks Enforcement is in middle of November (I don't agree with that length, I think 2 weeks max). me neither but have to ask Evan if we get+90% of network updated if he switch the button on? Yeah, 3 weeks or 90% |
|
|
|
WTB DRK. Pm me  Thats interesting. Evan's wanting DRK. Either: - he needs it for engineering purposes - he's about to do something that's going to send the price sky high (thank god for unregulated markets eh ?! ) - he used his real DRK on testnet by mistake and lost it - he spent all his DRK on coffee and needs more coffee Which one is it ? option 5. Friend of the family wants some DRK |
|
|
|
|
Show Posts
