v0.10.15.x Testing

Status
Not open for further replies.
oblox said:
Reference nodes.
Click to expand...

Better if it was something that screams the reasons why it's not really centralization, that it only affects masternode payments and is in no way in possession of special powers that control the user's transactions themselves.
 
Dr.Crypto said:
I'm obviously not Evan, but I think the point is that InstantX can perfectly rely on a randomly subset of RANDOMLY selected masternodes, while being extremely expensive to compromise just like Darksend.
Click to expand...

I'm with Cofresi on this, I'm not understanding what the difference is. Fundamentally it's the same thing as far as I can see.

Dr.Crypto said:
On the other hand, the point of relying on ubernodes would be to actually fight that randomness and get deterministic masternode payments. Which has nothing to do with the network's security.
Click to expand...

I'm not following you here. There have been several suggestions for getting even MN payments that don't involve static reference nodes. It boils down to maintaining a distributed list across as many nodes as is deemed necessary. If the entire network is too unwieldy to achieve perfect consensus every block, pick a smaller number and have them do it. LIke, well, reference nodes, just different ones each time.
 
Cofresí said:
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.
Click to expand...

Here's the gist:

1.) InstantX - A set of deterministic masternodes sign a message, they broadcast a message, which locks a transaction. A miner mines a block, which is a single entity and respects that transaction lock.
2.) Masternode Payments - A set of deterministic masternodes sign a message, they broadcast a message, which locks a block to a specific payee. In this case the whole network must have 1 specific payee, otherwise there is a blockchain fork. If half the network thinks the payee is one masternode and half thinks it's the other, there's a real problem. Blocks will be rejected by half the network and they'll start working on their own chain.

TLDR; One relies on mining in the end, one doesn't.
 
eduffield said:
Here's the gist:

1.) InstantX - A set of deterministic masternodes sign a message, they broadcast a message, which locks a transaction. A miner mines a block, which is a single entity and respects that transaction lock.
2.) Masternode Payments - A set of deterministic masternodes sign a message, they broadcast a message, which locks a block to a specific payee. In this case the whole network must have 1 specific payee, otherwise there is a blockchain fork. If half the network thinks the payee is one masternode and half thinks it's the other, there's a real problem. Blocks will be rejected by half the network and they'll start working on their own chain.
Click to expand...

Ok, thanks for trying to explain. So if I understand correctly the difference is that in 1.) only a single entity need to respect it, while in 2.) the whole network needs a consensus and we have a byzantine generals problem all over again. Still can't follow you completely. Would need to study the code.

Fair enough. But why the heck do the reference nodes need to be static? What would be so bad if the reference nodes were dynamic like the last 10 winning masternodes?
 
Cofresí said:
Ok, thanks for trying to explain. So if I understand correctly the difference is that in 1.) only a single entity need to respect it, while in 2.) the whole network needs a consensus and we have a byzantine generals problem all over again. Still can't follow you completely. Would need to study the code.

Fair enough. But why the heck do the reference nodes need to be static? What would be so bad if the reference nodes were dynamic like the last 10 winning masternodes?
Click to expand...

Dynamic reference nodes could attack the network by delayed the message till the last millisecond it would be accepted. Then half the network is correct and half is set on the wrong node. Fork.

We'll fix it later. I'm all about incremental improvements. This is a decent improve upon the existing system, but it doesn't fix everything.
 
eduffield said:
Dynamic reference nodes could attack the network by delayed the message till the last millisecond it would be accepted. Then half the network is correct and half is set on the wrong node. Fork.

We'll fix it later. I'm all about incremental improvements. This is a decent improve upon the existing system, but it doesn't fix everything.
Click to expand...
Engage, Numba One!
 
Hi guys and gals! I have created "TAO'S MASTERNODE GUIDE FOR DUMMIES" a fully step by step, funny, informative Masternode Set-up guide. Check it out here when you get a chance, and spread the word! We have 2,000 Masternodes to create, and this is just the place to send peeps:

https://darkcointalk.org/threads/taos-masternode-setup-guide-for-dummies.2680/

Cheers! :grin:

EDIT: Can someone who knows how to do so move this thread to the "Guides" section? I messed up and put it under General Support!
 
Last edited by a moderator:
pinestabe said:
<yesterday>
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.
Click to expand...
I also get stuck in state 7 if "no matching denomiations" happens. to fix it, in the check "CDarkSendPool::CheckTimeout() -- Session timed out (30s).." I had to chage the
UpdateState(POOL_STATUS_ERROR) line to
if(fMasterNode) UpdateState(POOL_STATUS_ERROR)
in order to get the timeout to kick in and put the clients back in state 3.
I'm not really sure what I'm doing, I just played around a bit till things started working!
 
Hey everyone,
Short question: are the new binaries on GitHub (https://github.com/darkcoinproject/darkcoin-binaries/) for mainnet? They're referenced as Onyx release and were pushed 8 hours ago. I wanted to download the 10.14.1 release with the masternode security update, but it has apparently been replaced.
Or maybe is everything already ready and we're just waiting for the official announcement from Evan? :D
 
Dr.Crypto said:
Hey everyone,
Short question: are the new binaries on GitHub (https://github.com/darkcoinproject/darkcoin-binaries/) for mainnet? They're referenced as Onyx release and were pushed 8 hours ago. I wanted to download the 10.14.1 release with the masternode security update, but it has apparently been replaced.
Or maybe is everything already ready and we're just waiting for the official announcement from Evan? :D
Click to expand...
15.13 is the latest. Please update to that.
 
Status
Not open for further replies.
Back
Top