v0.10.16.x Testing

Status
Not open for further replies.
Thing is, I've always been this way. And it's so hard to figure out where you went wrong when it could be anything, regardless of logic. LOL I'm sincerely sorry for wasting everyone's time :( I will NOT give you a list of my nicknames ;P but you can guess what they're like.... LOL)
 
UdjinM6 said:
That's a good question. I think the easiest way to protect from this kind of attack is by simply stopping providing InstantX functionality if there is less then SomeReasonableNumberOfMasternodes. And set SomeReasonableNumberOfMasternodes to.. let's say 1000.
Click to expand...

This has been in the discussions before, and iirc the problem was it's hard to reach a trustless consensus on the number of running masternodes without every node pinging every masternode constantly. Perhaps it's not hard at all if you know how to do it though. :)
 
illodin said:
This has been in the discussions before, and iirc the problem was it's hard to reach a trustless consensus on the number of running masternodes without every node pinging every masternode constantly. Perhaps it's not hard at all if you know how to do it though. :)
Click to expand...

but nodes could just be checked in case of an instant tx, couldn't they? nodes have to be connected anyway during the election process

minimum_nodes connected could be 70% of the average of the last 2 months or something.
maybe the number of nodes could be found in the blockchain by scanning the masternodepayments?
 
superplus said:
i've got a question concerning instantx,
i read all the possible attacks through in the white paper, but what happens if the masternode network is ddos attacked and some bad actor masternodes overtake the network for a short period.
wouldn't that be a scenario for doublespending?
Click to expand...

This scenario is handled in chapter 4.5 "Multiple Consensus Messages" in Evan's whitepaper.

A locking message is propagated to ALL clients, so in case of a conflicting message ('bad' Masternodes send different messages for the same lock) it's (relatively, poor Evan has to implement this :smile: ) easy to find out that the same inputs are spent twice and switch back to 'normal' block confirmation.

So, if anything, it's more a kind of DDOS for the transaction-speed(!), not the function itself.
 
vertoe said:
I'm with a 0.9.x client on testnet currently. What are you up to?
Click to expand...
The latest release (10.16.16) would be the one you would use on testnet until Evan pushes testnet only releases with instantx and/or other features implemented.
 
crowning said:
If my wallet finally decides to _completely_ sync I'll join in a couple of minutes...
Click to expand...

I'm in:

DS1.jpg


Gotta catch some sleep now, see you tomorrow...
 
On mainnet or testnet... been over an hour on mainnet and not a single pty or darksend denominate.
 
1000/8 done. Ended up with 1200+ however... I'm just sent to fresh address and started over

EDIT: Another wallet containing exactly 1000 tDRK done 1000/8 -> ~998 anonymized
 
Last edited by a moderator:
UdjinM6 said:
1000/8 done. Ended up with 1200+ however... I'm just sent to fresh address and started over

EDIT: Another wallet containing exactly 1000 tDRK done 1000/8 -> ~998 anonymized
Click to expand...
I'm running 1000 tDRK, 8 rounds also. So far I've got 2 Payment-to-yourself fees at 0.10, but the denominating seems going well and faster than before.
 
Looking for the latest test build, will help with the mixing, went 3 pages back can't find the build links, can someone please link?
 
My Testnet wallet has finished only 63% overnight...

Edit: This wallet got 93% finished after I made this post, got 399 tDRK anonymized with 8 rounds, the 500 and one 100 denoms only got 2 rounds. This was enough for me to do some other testing.
 
Last edited by a moderator:
Status
Not open for further replies.
Back
Top