Welcome to the Dash Forum!

Please sign up to discuss the most innovative cryptocurrency!

Development Update - 5/30/2014 - Fork Causes and Solutions

Discussion in 'Official Developer Thread' started by eduffield, May 30, 2014.

  1. eduffield

    eduffield Core Developer
    Dash Core Team

    Joined:
    Mar 9, 2014
    Messages:
    1,084
    Likes Received:
    5,318
    Trophy Points:
    183
    Development Update - 5/30/2014

    Fork Causes and Solutions
    Over the last few days, InternetApe and I have been collecting data to help recreate the problems we experienced with the last hard fork. We reached out to the community and requested that anyone still running a daemon on the wrong fork report back to us. We received a great number of responses, and analysis of these daemons was incredibly useful in our effort to determine the root cause of the issue.

    After examining the daemons and their associated blockchains, we've determined that, when approving blocks, in very rare situations the Masternode voting system was looking at the incorrect previous block. The forked clients were receiving an error that could only have been caused by the client comparing the current block to something that wasn't the correct previous block. This error caused the votes to appear manipulated and the client would reject the block.

    Later, when receiving the same block again, the client would accept the block. This makes it clear that there wasn't an issue with the block itself, but with the system that checks it.

    To solve this problem, we are going to take a multifaceted approach to development:

    1.) We are recreating this problem on testnet in order to determine the best fix possible (it's a rare error, so it's taking some time).
    2.) We are implementing automatic checkpointing, so that if this does happen again the network will not be able to diverge paths. In the event of a rejected block, the auto-checkpointing system will be able to tell the daemon to retry it later and put the daemon on the correct chain.

    Development Schedule
    Because we are implementing new technology, it will be necessary to change the schedule a bit:

    RC3 (Mid June): This version will include automatic checkpointing, resolution of the forking issue, and fixes for ghost Masternodes (Masternodes which have gone offline but still appear to be online, or which have transferred their 1000DRK out but remain in the election).

    RC4 (Mid July): The previous plans for RC3 are being moved to RC4. This will include significant improvements to anonymity and multi ticket support (which allows single daemons to have more than one "ticket" in the election by holding more than 1000DRK).

    Programming Team
    Last update we asked for anyone interested in helping the program to reach out to us. We've gotten a great number of responses, and we are still organizing and trying to find the best fit for the people that want to help out. Thanks to everyone that wanted to help further the development of Darkcoin.
     
    • Like Like x 16
  2. TsuyokuNaritai

    TsuyokuNaritai Active Member

    Joined:
    May 24, 2014
    Messages:
    181
    Likes Received:
    102
    Trophy Points:
    103
    Thank you for all your hard work! :)

    So to be clear... paying masternodes has been moved to mid-July?
     
    • Like Like x 1
  3. ozziecoin

    ozziecoin Member

    Joined:
    May 26, 2014
    Messages:
    50
    Likes Received:
    14
    Trophy Points:
    48
    Thanks for all the hardwork Evan. Do realise how difficult this must be.

    I have two questions:

    1. If there is no way for pools to hardcode/set which MN they vote for - why are 6 "votes" required?

    2. Re: auto checkpointing - is this for MNs only or for the entire network of nodes?
     
  4. eduffield

    eduffield Core Developer
    Dash Core Team

    Joined:
    Mar 9, 2014
    Messages:
    1,084
    Likes Received:
    5,318
    Trophy Points:
    183
    Mid-June. July we'll have the privacy enhancements and other functionality.
     
    • Like Like x 5
  5. Scriptiee

    Scriptiee Member

    Joined:
    Apr 24, 2014
    Messages:
    44
    Likes Received:
    20
    Trophy Points:
    48
    This multi ticket solution is not a good idea:
    1. Reduces the number of MNs, which decreases resiliency.
    2. If malicious party infiltrated the large pot MN, you will have a compromised coinjoin service. i.e. This is back to the centralised coinjoin problem again.
     
    • Like Like x 2
  6. YourNightmare

    YourNightmare New Member

    Joined:
    May 31, 2014
    Messages:
    23
    Likes Received:
    4
    Trophy Points:
    3
    Glad to hear that DRK is going forward! Thanks and waiting for relase
     
  7. UdjinM6

    UdjinM6 Official Dash Dev
    Dash Core Team Moderator

    Joined:
    May 20, 2014
    Messages:
    3,619
    Likes Received:
    3,528
    Trophy Points:
    1,183
    I also think that multi ticket support should be done with great caution. Maybe we have to limit max number of tickets, let's say, to 5 or 10 per MN. That would be nice compromise between centralization and difficulties on maintaining many MNs.
     
    • Like Like x 1
  8. ozziecoin

    ozziecoin Member

    Joined:
    May 26, 2014
    Messages:
    50
    Likes Received:
    14
    Trophy Points:
    48
    Also please see AlexGR suggestion that high resourced people can do their own stack in one MN via virtual servers on the one machine. i.e. There is no need to mess with the protocol to allow multi ticket on one MN. https://bitcointalk.org/index.php?topic=421615.msg7046010#msg7046010
     
    • Like Like x 2
  9. Argamas

    Argamas New Member

    Joined:
    May 31, 2014
    Messages:
    1
    Likes Received:
    0
    Trophy Points:
    1
    I don't see any issue with the ticket system itself, since creating and owning multiple MNs account to the same thing (eg. greater probability of processing a transaction). It doesn't really improve decentralization to have more MNs, since a single owner can still get a larger share of the transactions by deploying more nodes. It only distribute the load across more instances.

    Although I agree that this feature is probably not really required at this point, and should receive a lower priority, overall.
     
  10. just_mike

    just_mike Member

    Joined:
    Mar 9, 2014
    Messages:
    218
    Likes Received:
    20
    Trophy Points:
    78
    Agree - Lower number is better.
     
  11. ozziecoin

    ozziecoin Member

    Joined:
    May 26, 2014
    Messages:
    50
    Likes Received:
    14
    Trophy Points:
    48
    I think the MN processing a transaction is randomly chosen, whereas the MN reward is paid using a 6 vote system. So, I can't assume the stacked MN has a greater probability of processing a transaction, though it has greater probability of winning the MN reward. I don't know if people would like that, tbh.

    Moreover, if you're right and there is a greater probability of processing a transaction; if the large stacked MN is infiltrated, this introduces centralised coinjoin issues.
     
  12. pinwc4

    pinwc4 Member

    Joined:
    May 16, 2014
    Messages:
    45
    Likes Received:
    60
    Trophy Points:
    58
    I have multiple MN's and I agree with this as well, for health of the network encourage people to have multiple masternodes not centralize them. While it would somewhat simplify managing them for anyone actually experienced managing servers managing 1 or 100 identical servers is about the same.

    Maybe a compromise would be to make the number of tickets scale less than 1000 to 1 as you increase. Something like tickets=round(dark/1000 * 0.9). With this when you move above 5000 dark you miss out on one ticket. When you get above 10,000 then you miss out on 2 tickets etc.

    The more you centralize them the less credit you get. Maybe even scale to a curve instead of a fixed line to further discourage bigger groupings.
     
    • Like Like x 5
  13. UdjinM6

    UdjinM6 Official Dash Dev
    Dash Core Team Moderator

    Joined:
    May 20, 2014
    Messages:
    3,619
    Likes Received:
    3,528
    Trophy Points:
    1,183
    Like this idea too. Less work - less reward. Proof Of Work MasterNode-Style :)
     
  14. Probe

    Probe New Member

    Joined:
    May 28, 2014
    Messages:
    25
    Likes Received:
    3
    Trophy Points:
    3
    +1
     
  15. kaene

    kaene New Member

    Joined:
    Apr 11, 2014
    Messages:
    12
    Likes Received:
    20
    Trophy Points:
    3
    +1
    This solution makes sense to me, but still limit it to a maximum of maybe 10k DRK per MN.
     
  16. Populandum

    Populandum Well-known Member
    Foundation Member

    Joined:
    Apr 9, 2014
    Messages:
    103
    Likes Received:
    76
    Trophy Points:
    178
    In my opinion a multi-ticket system doesn't sound like the right move as it is very important to maintain network decentralization and stability.
     
    • Like Like x 2
  17. fernando

    fernando Powered by Dash
    Dash Core Team Foundation Member Moderator

    Joined:
    May 9, 2014
    Messages:
    1,522
    Likes Received:
    2,046
    Trophy Points:
    283
    Yes, but also having well taken care servers is important. To really be able to give an opinion I would need to know how many people run one server vs several ones.
     
    • Like Like x 1
  18. FoldingTime

    FoldingTime New Member

    Joined:
    May 26, 2014
    Messages:
    33
    Likes Received:
    12
    Trophy Points:
    8
    I completely agree. We need a decentralized system which is the core principle of crypto-currencies. We need thousands of MN across the globe.
     
    • Like Like x 2
  19. donho

    donho Member
    Masternode Owner/Operator

    Joined:
    Apr 16, 2014
    Messages:
    98
    Likes Received:
    21
    Trophy Points:
    58
    sounds good at first glance. the factor could be adjusted maybe but I kind of like the idea
    Would be nice to hear the Masters opinion on this :)
     
  20. fernando

    fernando Powered by Dash
    Dash Core Team Foundation Member Moderator

    Joined:
    May 9, 2014
    Messages:
    1,522
    Likes Received:
    2,046
    Trophy Points:
    283
    Another good thing about the multi ticket support is that it is probably more friendly to a multi investor masternode for people who don't have 1000 drk to start their own.
     
  21. Scriptiee

    Scriptiee Member

    Joined:
    Apr 24, 2014
    Messages:
    44
    Likes Received:
    20
    Trophy Points:
    48
    This would have nothing to do to multi investors really. think you understanding it wrong
     
    • Like Like x 1
  22. just_mike

    just_mike Member

    Joined:
    Mar 9, 2014
    Messages:
    218
    Likes Received:
    20
    Trophy Points:
    78
    No but it would allow a person to setup a Masternode and sell shares to other investors. Easily add or remove 1k DRK.
     
  23. fernando

    fernando Powered by Dash
    Dash Core Team Foundation Member Moderator

    Joined:
    May 9, 2014
    Messages:
    1,522
    Likes Received:
    2,046
    Trophy Points:
    283
    Exactly. Depending on how this system would work (it doesn't exist yet!) it could make easier to reallocate investments if there were the option to have bigger masternodes.
     
  24. just_mike

    just_mike Member

    Joined:
    Mar 9, 2014
    Messages:
    218
    Likes Received:
    20
    Trophy Points:
    78
    BUT, I am still in favor of a max around 5. Much higher and we lose decentralization.
     
  25. pinestabe

    pinestabe New Member

    Joined:
    May 1, 2014
    Messages:
    26
    Likes Received:
    9
    Trophy Points:
    3
    Would it be possible / a good idea to implement checkpoints so that they are accepted for only limited times? Seems like they should only be needed for a short time after hardforks.
     
  26. eltito

    eltito Active Member

    Joined:
    Apr 21, 2014
    Messages:
    157
    Likes Received:
    185
    Trophy Points:
    103
    Think of it as a safety net. In the event of any unforeseen issues, it'll prevent the sort of forking we saw last weekend (well, more precisely, it'll correct it before it becomes a network-wide problem). Better idea to have it running constantly "just in case".
     
  27. pinestabe

    pinestabe New Member

    Joined:
    May 1, 2014
    Messages:
    26
    Likes Received:
    9
    Trophy Points:
    3
    It's nice to have a safety-net, but the checkpoint server could also be a source of problems. Seems like it would require considerable effort to continuously make sure it's running properly. If it's running only for limited times there's less chance of problems happening over time. I'm not really familiar with the checkpointing system, though.
     
  28. eltito

    eltito Active Member

    Joined:
    Apr 21, 2014
    Messages:
    157
    Likes Received:
    185
    Trophy Points:
    103
    I understand your concern, but standard maintenance headaches like those you mention are simply insignificant in comparison to another random forking incident.
     
    • Like Like x 1

Share This Page