Topic: [ANN][DASH] Dash (dash.org) | First Self-Funding Self-Governing Crypto Currency - page 4863. (Read 9723748 times)

Mine all good been up 9 days now no problems

bump

I don't really know. With Darksend+ going around all over the place, the blockchain will be really foggy, particularly to humans. But a computer might be able to figure some of it out, maybe just in specific situations dependent on size of tx.

Whether Darksend+ should be mandatory is another topic entirely. I'm not presently sure you could even make it so. Nodes (or the block finder) would need to reject transactions not originating from the elected masternode(s) with an exception for the block reward I guess.

MORE from the PeaceMaker. ...Soap & Peace are related now that I think about it.
I posted this 4 days ago when we were crashing HARD & XC was up 40 or so %.





 

Do you think there could be a entry that reboots the server ?

I think it's obvious that this will work the same way with 0.5, 0.2, 0.1, 0.05 ... and smaller inputs.

Yeah, that does seem like an very good intermediate step before I2P or data encryption.  

It paaaaains me seeing litecoin's price higher than dark... 0.018 and stable seems reasonable. Above that when we've sporked and it works.

Does this become a non-issue if Darksend is mandatory? If not then yes, some in-wallet automagic might need to happen.

I meant could the whole Amazon network act similarly to one entity owning 300 master nodes, being a bad actor, and unveiling users trying to Darksend. Thanks for your reply though! 



I like this idea.

Say you have 5 master nodes on the network:

1.1.1.1
1.1.1.2
12.41.11.35
5.24.156.3
96.4.223.44

1.1.1.1 is selected as MN1. Now it'd be obviously foolish to choose 1.1.1.2 as MN2, because 1.1.1.1 and 1.1.1.2 are very likely run by the same person. Additionally in case of compromise it would (regardless of the fact who runs them) be more likely that both of them are compromised because they are likely running similar setups or may even be running on the same physical machine.

Look into Crontab.

I should change my name to the PeaceMaker.
My post to the Cloak thread.

I have not had any trouble with them. I set up alerts as El Presidenté suggested, and they have only showed down once (been up since payments started). I went and looked right away when the alerts showed down, but they were all up, so even that must have been a glitch.

I don't know, but from my limited software development experience I suspect that getting the machinery in place to process the transactions is the bigger job by far, encrypting the traffic should be fairly straightforward once Darksend+ is in place, and the developers will probably have an easier time testing without encryption to begin with.

In short I expect some form of encryption/IP obfuscation to be rolled out pretty soon after Darksend+ has been shown robust on main net. Of course it depends on the team's longer term strategy - what else they have planned and how it all fits together.

Has anybody also had a problem with vultr server. Mine was shut down again and i don't know why.
Server was running but darkoind was shut down. It looks like server gets started new but darcoind
is not into startup routine.

Can you explain in more detail? Or are there some Tor reference materials?  

That sub-1 change still has all sorts of problems from my perspective (note: when sending a "rounded" tx, the above method seems pretty nearly flawless; the only weakness I can think of at this time is if there's say 3 transactions happening, and one of the wallets doing the sending has (and is trying to send) less than either of the other two. It wouldn't work in this case, as one could still simply follow inputs/outputs.)

A way to somewhat alleviate the above scenario would be to have a "Prepare wallet for Darksend+" button, which would complete step one (with masternode 1), leaving a bunch of denominated change around to send in later transactions. Then you would have different transactions involved in an actual Darksend+ transaction versus who shared in the change denomination session.

But back to the sub-1 change issue. Let's say we need to send 17.54321 DRK from A to B (we can ignore other senders/receivers):

A sends 20 DRK to MN1; he get's change back as follows:
C gets 10 DRK
D gets 5 DRK
E gets 1 DRK
F gets 1 DRK
G gets 1 DRK
H gets 1 DRK
I gets 0.54321 DRK
J gets 0.45679 DRK

Now the transaction can proceed as normal, going to MN2 as expected (addresses C, D, E, F, and I get sent). B receives the requested 17.54321 DRK.

The problem is address J is now tainted and could potentially link some things together if used for future transactions with F, G, and H (if used with all 3 simultaneously, it would 100% link the original A to B tx). Additionally, it has the further weakness of not being very useful for future Darksend+'s, as it won't denominate well.

The potential "fix" that's on my mind (maybe just a workaround) is to store up these "tainted", mostly useless addresses until you have them totaling more than 1 (or 5, or whatever), at which point they could be sent to a special "redenominating" pool (and maybe you don't even need a pool, I haven't taken the time to think through all the implications of just doing it like a normal Darksend+) for recycling back to standard sized change addresses. You would still end up with one sub-1 address every time, but that's not too big of deal in my view.

Any thoughts?

That's not an argument against prohibiting the selection of two nodes that are _obviously_ run by the same person.

bump