v0.10.15.x Testing
- Thread starter eduffield
- Start date
- Status
My wallet's anonymized perfectly too. I need to do a couple more tests, but then it looks like we're good to release this. Thankyou everyone who helped!
Thanks for the explanation of how collateral works! Since you're wrapping it up, here's some trivial stuff:
I noticed in processmessage() for "dsa", there's a version check:
pfrom->nVersion != darkSendPool.MIN_PEER_PROTO_VERSION
with a constant that is a bit confusingly named, maybe it should be named PEER_PROTO_VERSION since it must be an exact match
I get confused easy!
Also, there are a lot of logprintf messages in RegisterAsMasterNode() that don't have newlines, and the port check in there does exit() instead of what seems like it should be doing is returning.
There's a typo in the logmessage in main.cpp near line 4098 ( transactione )
<edit>
after 1 DS round, my clients get stuck in state 7, so doautomaticdenominate aborts. in CDarkSendPool::Check() where it's supposed to reset after 10 seconds, the state check passes, but not enough time has passed. This check seems to be done only once, so the reset doesn't happen. this could be due to my odd configuration: I have a masternode and 3 clients that I'm forcing to connect to my masternode, all on the same machine. If i restart the clients they work again for 1 round, also works if I just put a sleep for 10sec after checking only for state and not time.
I noticed in processmessage() for "dsa", there's a version check:
pfrom->nVersion != darkSendPool.MIN_PEER_PROTO_VERSION
with a constant that is a bit confusingly named, maybe it should be named PEER_PROTO_VERSION since it must be an exact match
I get confused easy!
Also, there are a lot of logprintf messages in RegisterAsMasterNode() that don't have newlines, and the port check in there does exit() instead of what seems like it should be doing is returning.
There's a typo in the logmessage in main.cpp near line 4098 ( transactione )
<edit>
after 1 DS round, my clients get stuck in state 7, so doautomaticdenominate aborts. in CDarkSendPool::Check() where it's supposed to reset after 10 seconds, the state check passes, but not enough time has passed. This check seems to be done only once, so the reset doesn't happen. this could be due to my odd configuration: I have a masternode and 3 clients that I'm forcing to connect to my masternode, all on the same machine. If i restart the clients they work again for 1 round, also works if I just put a sleep for 10sec after checking only for state and not time.
Last edited by a moderator:
Thanks for your efforts!
How are masternode payments looking?
I've got mixed feelings about your new method. It is definitely fairer but I'm going to miss the occasional bonanza day
Last edited by a moderator:
Sorry, I woke up to find that my laptop was disconnected for some time. The wallet is back up now. Thanks for pairing!
I think on Testnet it takes only 2 or more participants for testing, but on Mainnet it takes 3 or more for Darksend to work.
Last edited by a moderator:
Hey guys, did we have to do something for the latest wallet (10.15.12)? Mine won't sync the last 10 hours?
eduffield, still no answer whether this will be done or not?
After thinking about it a second time I find it even WORSE than last time for several reasons:
- Forget "anonymous" nodes. Security by obscurity doesn't work (never has, never will; each security guy will tell you that). Someone WILL find them, DDOS them to dead, fire up some own nodes and the payments will be very predictable his. Or hers. Or if I'd hire that guy, mine!
- Now that we have almost 1000 Masternodes (which lots of people still consider a kind of centralization) we add _another_ kind of rare, special nodes. Explain THAT to the public.
- What do they can do what a normal Masternode can't do?
^^ Maybe the Übernodes are just regular MNs selected ad-hoc to act as such. Would be good to hear more about how this works.
1. Sure, someone might be able to find one of them and DDOS it. But there's more than one. If they find all of them and DDOS them, the system falls back to the way it works now. DDOSing them doesn't give you some special ability to print money and they can be checked by any user on the network to make sure they're working correctly.
2 & 3. All it can do is sign a special message that the network understands, which will tell the network who to pay for a specific block in the future. The code it uses is deterministic, so someone else can run one and check that the payments are being made correctly.
The solution I came up with is fantastic, but no one has really looked through the code yet and I haven't written a technical document showing how it works.
- These nodes are ran by trusted people in the community
- These nodes can't cheat, it can be detected
- There is nothing bad that happens if they aren't present, the network continues to pay nodes ... just more randomly.
- The system can't be exploited by mining pools. They must pay a specific address and a specific amount.
- These nodes can be 100% anonymous by using the multi-path routing system to talk to the network: https://darkcointalk.org/threads/open-source-announcement-and-future-plans.2528/
I really do not like the idea of having to rely on trusted parties. The whole concept and process should be trustless by design. Why structurally couldn't the existing population of masternodes do the same task and reach consensus?
Is this the "round-robin" you talked about before? If so the MN payment isn't going to be a variance system anymore, correct?
It's still trustless due to the deterministic algorithm that determines the payee. It's just a specific set of clients that are allowed to send the message.
So how come existing masternodes can't serve this purpose in terms of consensus? If all of them are running the same deterministic algorithm and the majority (most likely all) are coming to the same payee, then why the need for special nodes serving this purpose?
I DDOS yours and run mine, which pay my Masternodes only. Others can check of course, but what can they do against it?
That's completely orthogonal to a trustless network. I trust no one!
I do a brute-force for every IP on port 9999 and throw away the known Masternodes from the result. Needs some time, but isn't impossible for a proper botnet.
And the bad boys HAVE botnets...
I also would feel more comfortable with a system that relies on quorum opposed to selected address signatures.
Is there a reason why those nodes cannot be selected randomly among normal MNs in the network each round and use a majority type win...
Last edited by a moderator:
Sorry, but I don't think this is going to fly. The community is speaking to you and they are saying that the uber nodes run by 'trusted members of the community' are not acceptable. We've already tarnished the decentralized nature of Bitcoin by introducing masternodes. As a community, we have accepted that masternodes are a necessary infrastructure to do what Darkcoin does, and there are future capabilities that will be built using the masternodes. So on the whole they are a benefit more than a hazard.
Adding a third layer of node hierarchy to fix a problem with masternode payouts is going to be impossible to sell to the larger bitcoin-savvy community. If our goal is to replace Litecoin, we need to consider that our target audience will be highly critical of Darkcoin's construction. They will be looking for 'automatic checkpoints' and 'trusted nodes' to laugh us off the reddit forums and BCT.
Somehow, the masternode payout system needs to be pushed up to the masternode level (i.e. run by all masternodes, good and bad) and be robust enough to check for bad MNs and ban them for a period of time when they are not agreeing to the deterministic payee.
Last edited by a moderator:
I think so many of you guys were asking for a "fair payment" on your MNs.... So I guess you're getting what you asked for and however you want to slice it... someone is going to complain? :tongue:
Edit: Or however Evan is going to slice it.... lol
Edit: Or however Evan is going to slice it.... lol
There is more than one way to accomplish this is all we're saying.
Maybe someone needs to look at the code and help Evan?
Agreed. Personally, I'm more concerned about fixing the theft of MN payouts from cheating miners and other potential exploits than I'm concerned about low variance payments. As it stands, I would rather keep the flawed but 95% effective high variance (RC5) system we have today than move to a three tiered 'trusted nodes' system to make payouts100% and low variance. I just don't think we can sell that kind of setup outside our own enclave.
Although the solution is good technically, it would be a public relations disaster. Trolls & dummies already scream about "CENTRALIZED masternodes", now the majority will join them, only the already converted who have bothered to understand everything properly would defend us. The perception of the coin would remain tainted even after such a change was reversed. The crypto community *really* doesn't like anything that smells of centralization, even when it's a perfectly brilliant idea in practice.
Solution: find a way to do it using either all masternodes, or those older than a certain age, or a random subset of such. Maybe require a supermajority to agree to the new deterministic payments, or it reverts back to the way it works now till consensus is restored. No-one will bother trying to game the system if they need 75% of the masternodes to do it.
Solution: find a way to do it using either all masternodes, or those older than a certain age, or a random subset of such. Maybe require a supermajority to agree to the new deterministic payments, or it reverts back to the way it works now till consensus is restored. No-one will bother trying to game the system if they need 75% of the masternodes to do it.
Last edited by a moderator:
Very well said. For the love of god, lets not go down this road of trusted nodes. The backlash will be far worse than any sort of good out of it. If "trusted nodes" as is are capable, there is no reason that all masternodes can't serve this purpose. I can't see any viable reason that would prevent implementing it into all masternodes vs just a select few, trusted nodes.
Here's my stab at a possible solution. Please feel free to rip it apart.
1) from blockchain: during daemon startup, walk last 4000 blocks, collect paid masternode addresses.
2) from network: collate all masternode addresses from peers into array 'mnlist'
3) prune masternode addresses having been paid within length(mnlist) blocks
4) prune masternode addresses with 1k deposits newer than length(mnlist) from array. (i.e. 3000 active masternodes requires 3000 confirmations to receive payments.)
5) array now contains nodes due for payment.
6) sort array by address.
7) pay top address
8) GOTO 2
This will create a deterministic payout list all masternodes can confirm with their peers before accepting.
This assumes masternode addresses (mnlist contents) are valid/validated and that we haven't yet grown past 4000 masternodes. (step one would be adjusted accordingly.)
tl;dr: use the historical blockchain payments to prevent dupes, filter out the too-new, alpha sort the to-be-paid and pay the top address.
1) from blockchain: during daemon startup, walk last 4000 blocks, collect paid masternode addresses.
2) from network: collate all masternode addresses from peers into array 'mnlist'
3) prune masternode addresses having been paid within length(mnlist) blocks
4) prune masternode addresses with 1k deposits newer than length(mnlist) from array. (i.e. 3000 active masternodes requires 3000 confirmations to receive payments.)
5) array now contains nodes due for payment.
6) sort array by address.
7) pay top address
8) GOTO 2
This will create a deterministic payout list all masternodes can confirm with their peers before accepting.
This assumes masternode addresses (mnlist contents) are valid/validated and that we haven't yet grown past 4000 masternodes. (step one would be adjusted accordingly.)
tl;dr: use the historical blockchain payments to prevent dupes, filter out the too-new, alpha sort the to-be-paid and pay the top address.
Last edited by a moderator:
- Status