Welcome to the Dash Forum!

Please sign up to discuss the most innovative cryptocurrency!

v0.10.15.x Testing

Discussion in 'Testing' started by eduffield, Oct 7, 2014.

Thread Status:
Not open for further replies.
  1. thelonecrouton

    thelonecrouton Well-known Member
    Foundation Member

    Joined:
    Apr 15, 2014
    Messages:
    1,135
    Likes Received:
    813
    Trophy Points:
    283
    I'm in agreement with the mob here. Maybe I'm just misunderstanding the mechanics of it, but a third layer in the cake doesn't seem a good idea just to achieve even distribution.

    Are these ubernodes running the same code as other MNs? What actually differentiates them? Why cannot plain old MNs serve the same function either via mass consensus or via a limited random selection to act as ubernodes for that block or n blocks?
     
    #541 thelonecrouton, Oct 15, 2014
    Last edited by a moderator: Oct 15, 2014
    • Like Like x 4
  2. eduffield

    eduffield Core Developer

    Joined:
    Mar 9, 2014
    Messages:
    1,084
    Likes Received:
    5,319
    Trophy Points:
    183
    Uber nodes run the exact same software with a special private key that enables them to sign messages that tell the network who to pay. Without the central authority, miners can pay whoever they want as the payee. The masternodes can't function as the authority, because they could exploit the code and fork the network.

    It doesn't have to be this way forever, it's just a good solution to support the growth of the network. I think the best overall solution is the voting mechanism that was blockchain based (RC3). To fix that system requires that we update all miners software (CPU, GPU, etc), all stratum pools and all daemons. But it would be completely decentralized and pretty much perfect.
     
  3. eduffield

    eduffield Core Developer

    Joined:
    Mar 9, 2014
    Messages:
    1,084
    Likes Received:
    5,319
    Trophy Points:
    183
    Uber nodes run the exact same software with a special private key that enables them to sign messages that tell the network who to pay. Without the central authority, miners can pay whoever they want as the payee. The masternodes can't function as the authority, because they could exploit the code and fork the network.

    It doesn't have to be this way forever, it's just a good solution to support the growth of the network. I think the best overall solution is the voting mechanism that was blockchain based (RC3). To fix that system requires that we update all miners software (CPU, GPU, etc), all stratum pools and all daemons. But it would be completely decentralized and pretty much perfect.

    How does a masternode get paid the first time?

    If you use the masternode list, they aren't always in sync between clients. So if a payee is on the list in one client, but not in another the network will fork.

    How does that ensure the masternodes port is open and doing the service properly?
     
    #543 eduffield, Oct 15, 2014
    Last edited by a moderator: Oct 15, 2014
  4. eduffield

    eduffield Core Developer

    Joined:
    Mar 9, 2014
    Messages:
    1,084
    Likes Received:
    5,319
    Trophy Points:
    183
    I'm open to any solution anyone can come up with. I've been working on this for months and have had five different implementations of it. This is the best solution I've come up with yet. Yes, it's a compromise, but it seems like the benefits completely outweigh the problems.

    Here's what it solves:

    - Non-exploitable masternode payments (Currently miners can pay their own masternode every single time)
    - Completely deterministic round-robin
    - 100% compatible with proof-of-service

    Anything that replaces it must solve all of those and can't be attackable.
     
  5. moocowmoo

    moocowmoo Bovine Bit-flipper
    Foundation Member

    Joined:
    Jun 15, 2014
    Messages:
    483
    Likes Received:
    603
    Trophy Points:
    263
    Dash Address:
    XmoocowYfrPKUR6p6M5aJZdVntQe71irCX
    once it reaches the payment age it would eventually get selected for it's first payment from the sorted-by-address (leveraging dispersion) list.

    wouldn't one of the blocks just get orphaned due to it not being 'best' -- in bitcoin thats the number of leading zeros -- nothing similar in x11?
     
  6. oblox

    oblox Well-known Member

    Joined:
    Aug 6, 2014
    Messages:
    1,032
    Likes Received:
    537
    Trophy Points:
    183
    Why can't the masternodes as a whole function as the authority? Understandably, individually they could exploit, but as a group, the majority shouldn't be rogue thus leading to consensus that is deterministically random.
     
  7. thelonecrouton

    thelonecrouton Well-known Member
    Foundation Member

    Joined:
    Apr 15, 2014
    Messages:
    1,135
    Likes Received:
    813
    Trophy Points:
    283
    The root problem seems to be that miners/pools lay outside of direct MN control.

    I've suggested before that MNs act as pools. If MN pools were the only network-acceptable pools to mine at, this would place miners under direct MN control, and also solve the potential hash centralisation issue.

    Maybe that's too big of a rewrite though, I don't know (assuming it was thought to be a viable idea anyway. No one has yet pointed out to me the suck in this plan. Maybe they are embarrassed by my stupidity? :tongue:)

    If the only difference between MNs and ubernodes is that the latter have this special private key, could the form that key takes be some hashed combination of blockheight and MN identity, along the lines of 2FA? Thus the ubernodes would vary with time.
     
    #547 thelonecrouton, Oct 15, 2014
    Last edited by a moderator: Oct 15, 2014
  8. eduffield

    eduffield Core Developer

    Joined:
    Mar 9, 2014
    Messages:
    1,084
    Likes Received:
    5,319
    Trophy Points:
    183
    Sure, but then I'd just make a bunch of 1000DRK inputs and get paid with no nodes running.

    No, the client must reject the bad blocks with the wrong payee.
     
  9. eduffield

    eduffield Core Developer

    Joined:
    Mar 9, 2014
    Messages:
    1,084
    Likes Received:
    5,319
    Trophy Points:
    183
    Really though, back to the "ubernode". It's just determining who the payee is for a given block in the future. It poses no security risk to the network and is trustless. So I don't think it should be a concern.

    Later on, we can revisit this and remove the checkpointer and ubernodes and replace it with something decentralized and is really well thought out. There's 2 good ideas, one the voting in-block chain and a second blockchain for the active masternodes that's used. Both are a lot of work.
     
  10. flare

    flare Administrator
    Dash Core Team Moderator

    Joined:
    May 18, 2014
    Messages:
    2,287
    Likes Received:
    2,406
    Trophy Points:
    1,183
    Excellent discussion folks :)

    I must confess that i am 50:50 on this topic: On the one hand i understand the dislike of yet another centralised component (beside checkpoint server and spork switch), on the other hand it doesn't make it worse, as the ubernodes are not crucial for the proper functioning of the network.

    Like Evan pointed out, the best solution (out of five!) so far was the vote based system he implemented in RC3, which is has a slight incompatibility with the current mining/stratum protocol, which in turn lead to permanent forks --> https://darkcointalk.org/threads/6-20-rc3-post-mortem.1463

    I also like the idea of masternodes mining (either the actual DRK blockchain or a distinct masternode blockchain).

    Both solutions are a lot of work, as either the miners and stratum protocol need to be updated or a second blockchain needs to be implemented. Both have pros and cons...
     
  11. HinnomTX

    HinnomTX Active Member

    Joined:
    Jul 22, 2014
    Messages:
    166
    Likes Received:
    196
    Trophy Points:
    103
    This appears to be a critical problem that needs to be solved. If we can share one blockchain among all the clients, surely there is a way to share one masternode list too. Perhaps this list cannot be updated in real time, but I bet it could be updated once per block. Then build in some hysteretic qualifiers to prevent gaming of the system (e.g. have 3000 confirms to make it on a MN list of 3000, plus a few confirms of closed port/inactivity/misbehavior to get kicked off the list).

    Edit: I see a second MN blockchain has been proposed. Sorry about the echo chamber.
     
  12. flare

    flare Administrator
    Dash Core Team Moderator

    Joined:
    May 18, 2014
    Messages:
    2,287
    Likes Received:
    2,406
    Trophy Points:
    1,183
    This is exactly what Evan implemented in RC3 as vote-in-blockchain: The votes had to mature for seven blocks. But there was an issue when two miners found the block almost simultanously with different vote confirmations.... --> fork.
     
  13. crowning

    crowning Well-known Member

    Joined:
    May 29, 2014
    Messages:
    1,428
    Likes Received:
    2,005
    Trophy Points:
    183
    Is there anything missing or tedious to implement??

    Code:
    1:  Read blockchain and look which Masternode got already a payment
    
    1a: all got payments already: select the one with the oldest payment:
        Goto 1:
    
    1b: not all got payments: select the oldest one (by its initial 1000 DRK transaction)
        and which is at least n-confirmations old
        If all unpaid are too young: apply 1a for the rest (already paid ones) of the Masternodes
        Goto 1:
      
      
    Each Masternode broadcasts its result and the Masternode with the most votes is selected
    
    
     
    • Like Like x 1
  14. thelonecrouton

    thelonecrouton Well-known Member
    Foundation Member

    Joined:
    Apr 15, 2014
    Messages:
    1,135
    Likes Received:
    813
    Trophy Points:
    283
    I don't know if you were referring to what I wrote, but to be clear, that isn't my suggestion. I think mining should remain, at least for now, a separate (and secondary, backup blockchain verification mechanism when InstanTX gets introduced) activity, I just think that if all pools had to run on MNs it would solve a variety of problems at once. I'll shut up about it now, promise. :)
     
    • Like Like x 1
  15. kryptofoo

    kryptofoo Member

    Joined:
    Jul 21, 2014
    Messages:
    114
    Likes Received:
    36
    Trophy Points:
    78
    It does seem like a reasonable compromise to make sure payments are equal and cannot be gamed. But please be sure to explain it thoroughly up front to head off the uproar. if it gets mentioned only in passing e.g. as a single bullet point in the release notes, the community may latch on to this and create a lot of heat. Let's make sure people understand this is only to ensure fair masternode payments, nothing more.

    I suggest not calling them privileged nodes or uber-nodes or anything of the sort. I would stick with something more benign like "reference masternodes" or "payment verification masternodes".

    I trust you have looked at this from all angles and have settled on this as the best possible solution that would not consume vast amounts of your valuable time. Let's get it done and roll with the release!
     
    • Like Like x 3
  16. qwizzie

    qwizzie Well-known Member

    Joined:
    Aug 6, 2014
    Messages:
    1,513
    Likes Received:
    717
    Trophy Points:
    183
    Good enough for me... i think we should just proceed with bringing v0.15 to mainnet,
    including the implementation of those few ubernodes that make the MN payments more reliable
    and brainstorm about how we can make this all better in a seperate post here on darkcointalk

    edit : assuming we consider v0.15 bugfree at the moment .. was my latest debug.log / wallet any help Evan?
    there were some 0.1 fees in there although that specific client was acting a bit weird from the start.
     
    #556 qwizzie, Oct 15, 2014
    Last edited by a moderator: Oct 15, 2014
  17. thelonecrouton

    thelonecrouton Well-known Member
    Foundation Member

    Joined:
    Apr 15, 2014
    Messages:
    1,135
    Likes Received:
    813
    Trophy Points:
    283
    Agreed, it's not that big of a deal, but how it's presented needs some, shall we say, finesse, there *will* be bitching about this.

    If some way could be found though of making the payment distribution nodes a moving bloc, that would be perfect and nobody would have anything to moan about. I'd happily trade a delay in release of Onyx for this to be achieved somehow. Sadly I'm not qualified to help much beyond tossing suggestions around.
     
    • Like Like x 1
  18. oblox

    oblox Well-known Member

    Joined:
    Aug 6, 2014
    Messages:
    1,032
    Likes Received:
    537
    Trophy Points:
    183
    Since we are essentially forcing mandatory updates, it wouldn't be half bad of an idea to also increase the tx size, much like BTC wants to do to future proof it. Better to get everything done in as few forks as possible than to try to fork a more established ecosystem.
     
    • Like Like x 1
  19. HinnomTX

    HinnomTX Active Member

    Joined:
    Jul 22, 2014
    Messages:
    166
    Likes Received:
    196
    Trophy Points:
    103
    IMHO, a revised blockchain based voting system is what you should strive for. The growth of the network will come from establishing completely decentralized, trustless relationships. A payment system that touts anonymity must be as trust-free as possible.
     
    • Like Like x 2
  20. thelonecrouton

    thelonecrouton Well-known Member
    Foundation Member

    Joined:
    Apr 15, 2014
    Messages:
    1,135
    Likes Received:
    813
    Trophy Points:
    283
    Yeah I'm still unsure how a few (how many?) ubernodes are able to enforce network behaviour (as InstanTX will require?) but a similar sized random - or deterministic, eg. the last n MN's to get paid - subset of existing MNs (if whole-network consensus is too unreliable) acting in the same way can not.

    Code:
    ubernodes = [last 8 winners]
    
    if MN in ubernodes:
        gets to act as ubernode, wields the magic key
    else:
        does not
    
    edit: random is better, an easily discoverable list paints a target on them
     
    #560 thelonecrouton, Oct 15, 2014
    Last edited by a moderator: Oct 15, 2014
  21. eduffield

    eduffield Core Developer

    Joined:
    Mar 9, 2014
    Messages:
    1,084
    Likes Received:
    5,319
    Trophy Points:
    183
    Yeah, looks bug free. You were the only one charged and your client froze up but was still in the process of anonymizing. I'm OK with users getting hit with collateral changes rarely, they can actually get them back if they wanted to. Plus they're only 0.1DRK. If you can anonymize 10000DRK and get hit with one, you paid about 50 cents for the whole process, which is more than fair.
     
  22. moli

    moli Grizzled Member

    Joined:
    Aug 5, 2014
    Messages:
    3,261
    Likes Received:
    1,837
    Trophy Points:
    1,183
    Is this collateral fee in place more likely to protect Darksend from being DoSed?
     
  23. eduffield

    eduffield Core Developer

    Joined:
    Mar 9, 2014
    Messages:
    1,084
    Likes Received:
    5,319
    Trophy Points:
    183
    Exactly.
     
  24. moli

    moli Grizzled Member

    Joined:
    Aug 5, 2014
    Messages:
    3,261
    Likes Received:
    1,837
    Trophy Points:
    1,183
    Thanks, Evan :)
     
  25. TaoOfSatoshi

    TaoOfSatoshi Grizzled Member

    Joined:
    Jul 15, 2014
    Messages:
    2,719
    Likes Received:
    2,613
    Trophy Points:
    1,183
    This is great now that 1DRK is $2.10, but what is going to happen when 1DRK is $100.00? $1,000? A person or business that wants to anonymize small amounts and gets hit with a $100.00 collateral charge is not going to be happy... :sad: I'm sure you will revisit those fees as DRK increases in value.:D
     
  26. moli

    moli Grizzled Member

    Joined:
    Aug 5, 2014
    Messages:
    3,261
    Likes Received:
    1,837
    Trophy Points:
    1,183
    Yes, i think he will... for now we need to get the system hardened and secure :)
     
  27. DrkMiner

    DrkMiner Member

    Joined:
    Jun 7, 2014
    Messages:
    204
    Likes Received:
    63
    Trophy Points:
    88
    eduffield, The problem is that we need a List that is accessible to all Node and that is tampered proof.

    We already have that "list" its the blockchain!

    What can't we "mine" the data we need from the blockchain?

    1) get all MN address, total number "N" and time "active minutes" (not sure where that info is stored ).
    2) compare all addresses to the "N" of last paid MN (blockchain info).
    3) payment:

    MN is not on that list and "active minutes" > 12 hours (or less??).

    I'm not a programmer, just brain storming.
     
  28. UdjinM6

    UdjinM6 Official Dash Dev
    Dash Core Team Moderator

    Joined:
    May 20, 2014
    Messages:
    3,637
    Likes Received:
    3,536
    Trophy Points:
    1,183
    I have few questions:
    1. Is that "special private key" shared by uber nodes or is it generated for each one independently like "masternode genkey"?
    2. Where is that functionality in code, can your give a code line link pls?
     
  29. Cofresí

    Cofresí Member
    Core Developer

    Joined:
    Aug 22, 2014
    Messages:
    85
    Likes Received:
    79
    Trophy Points:
    58
    Evan, please forgive my ignorance, but I don't understand how you can expect a subset of masternodes can function as an authority in the case of InstantX when at the same time you say that they cannot be trusted in case of signing messages for masternode payments. Instead in the latter case we have to trust a few (fixed?? centralized???) uber nodes? Santissima, maybe I'm missing something, but at this stage I have to say, come on and don't rush this. You can do better than that.
     
    • Like Like x 2
  30. eduffield

    eduffield Core Developer

    Joined:
    Mar 9, 2014
    Messages:
    1,084
    Likes Received:
    5,319
    Trophy Points:
    183
    The masternode list isn't always in perfect sync across the network. So if a node is on one clients list and not on another, the network would fork.
     
Thread Status:
Not open for further replies.