• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

V12.1 Testnet Launch Thread

Status
Not open for further replies.
Interesting idea, however MNs are identified not by the payee address but by the vin really (we need to know if it's still unspent), so even if from blockchain perspective it could look like address has nothing to do with MN for online node it should be obvious which MN is getting payed every block (or there is no consensus). "Facebook-of-crypto" functionality for end users does not affect consensus in any way.
Well, I understand how it works now. But, if you could use a smaller-scale version of the "facebook-of-crypto" to treat the VIN as an alias? Or create an alias association to the VINs. That way the payment doesn't hit the 1000 vin anymore, but the network still knows which identity is supposed to be getting paid.

My interest being, right now it is really easy to track masternode payments. They report IPs. IP is owned by a known person. So, every payment can be attributed to that person and proven in the blockchain. We really don't have an easy way to change that from the IP side. Blinding sill isn't a thing, either...

But, it seems the construct for using a new address for every payment is feasible. Just make the MN's VIN into a pay-to alias just like the "facebook-of-crypto" idea. Since it's all pretty much network defined, strip out all the unnecessary features and use it like a minimal test of the larger concept.

Totally different way to attack the matter: Simply add an argument to the masternode start(-many) for inclusion of a public deterministic seed? All payments go to that, the network keeps track.

Even simpler: Just specify an address(es) argument in the masternode start(-many) as an alternative to the vin. Can update it at any time. Use mathgic so that it isn't visible as an association.

Maybe include automixing before delivery? MN/miner payments pass through PS before delivery?

While this still doesn't hide MNOs, it at least disconnects the actual payments from the obvious connection they have now.

Just a bunch of crazy ideas... They all seem feasible and would at least insulate the network from a bulk bureaucratic attack. We don't need the entire MN network being taken down by IRS auditors on fishing expeditions. If they can't actually prove real numbers and names, they can't make their move... Sure, they'll still be able to see the average network numbers and divide it by the number of masternodes. They could even still know how many MNs a person is running. But they wouldn't be able to prove the payments with certainty or precision. Maybe there were PoS penalties in effect? Maybe it went offline for a while? It would make the network less vulnerable to guvthug coercion in at least a small way by making their so-called "job" harder.

In what is supposed to be PrivacyCoin, there is scant little attention given to keeping the entire 2nd tier safe from this form of attack. DASH being more than a toy, it may be considered a real threat to the evil powers that be, and you have to consider this.
 
Well, I understand how it works now. But, if you could use a smaller-scale version of the "facebook-of-crypto" to treat the VIN as an alias? Or create an alias association to the VINs. That way the payment doesn't hit the 1000 vin anymore, but the network still knows which identity is supposed to be getting paid.
...
We need vins not only to detect payment address but to make sure 1000 DASH are still there i.e. "locked".

...
Even simpler: Just specify an address(es) argument in the masternode start(-many) as an alternative to the vin. Can update it at any time. Use mathgic so that it isn't visible as an association.
...
That's what donation feature was which opened some attack vector iirc.

...
Maybe include automixing before delivery? MN/miner payments pass through PS before delivery?
...
Mixing requires private keys - you have to sign inputs to create composed mixing transaction.

...
Just a bunch of crazy ideas... They all seem feasible and would at least insulate the network from a bulk bureaucratic attack. We don't need the entire MN network being taken down by IRS auditors on fishing expeditions. If they can't actually prove real numbers and names, they can't make their move... Sure, they'll still be able to see the average network numbers and divide it by the number of masternodes. They could even still know how many MNs a person is running. But they wouldn't be able to prove the payments with certainty or precision. Maybe there were PoS penalties in effect? Maybe it went offline for a while? It would make the network less vulnerable to guvthug coercion in at least a small way by making their so-called "job" harder.

In what is supposed to be PrivacyCoin, there is scant little attention given to keeping the entire 2nd tier safe from this form of attack. DASH being more than a toy, it may be considered a real threat to the evil powers that be, and you have to consider this.
Yep, I agree, we need to come with some solution sooner or later. I just don't see it (yet).

EDIT:
The problem is that you need to verify block somehow i.e. you need to make sure that miner paid exactly to the masternode which was supposed to be paid and not to some another random address (e.g. to himself). This means there must be a link MN<-->payee.
 
Last edited:
I never really understood why the donation addresses where removed....
 
The problem is that you need to verify block somehow i.e. you need to make sure that miner paid exactly to the masternode which was supposed to be paid and not to some another random address (e.g. to himself). This means there must be a link MN<-->payee.
This is why I thought some stripped-down version of the facebook-of-crypto might be useful.

It's right in the Evolution whitepaper that you can pay to an alias or name, and the payment will go to a different address every time. Obviously, it's confirming that the payee is accurate regardless of the address by using the public seed tied to that alias. But, it could end up being circular... If that association is plainly readable, it's no more private than simply paying to the VIN. This suggests a more fundamental change is needed to provide privacy.

I see your point of using the VIN to prove miner allocation. But, that doesn't seem to preclude the matter. It's an easy way, but not the only way. If Evolution can scan a payee public seed for the next unused address, that same association and method can still be used both to make, and verify MN payments. You're just paying to the next address on the seed, which is found by looking up the MN's alias. Almost a carbon copy of the same plan outlined in the whitepaper...

We need to start looking at the current implementation of masternodes as exactly what they are: a crude implementation of something that really needs to be re-examined and beefed up a bit.

It makes setting up a masternode more complicated, and I'm sure there will be whiners. But, MNOs are supposed to be smart and motivated, not mad that they have to actually do some work and know a few things...

As for signing... Yeah, having that seed in the MN seems a bit risky, but if it's separate from the VIN hot/cold schema... Maybe we need to revisit the absolute-ism of protecting dumb masternode operators from themselves? Maybe they should, shock, actually learn something about server security instead of relying entirely upon the hot/cold scenario? We;re clinging to this "let stupid people stay stupid" thing pretty hard, and nowhere in the real world of IT is this a real option...

I think the options are far too limited as a result of that attitude. Force votes, even a scripted "abstain" vote, by using an "abstain" option in the DGBB/PoService to put more pressure on these lazy shared node services/operators. You cut yourself off from so many possibilities by insisting on the "save stupid people from themselves" circumstance. MNOs aren't supposed to be as stupid and lazy as the end users... We have to start actually expecting something from them.
 
Last edited:
Mixing requires private keys - you have to sign inputs to create composed mixing transaction.
Can't the network itself sign certain transactions upon certain conditions? Isn't that exactly how Smart Contract coins work? Kinda like a multisig, but the network is one of the signers guaranteeing a condition met? Where do block come from, anyway? :p
 
Can't the network itself sign certain transactions upon certain conditions? Isn't that exactly how Smart Contract coins work? Kinda like a multisig, but the network is one of the signers guaranteeing a condition met? Where do block come from, anyway? :p
Can't really say much about Smart Contract coins but if I get it correctly they are balance based, not utxo based which means that you just say "hey, I want to transfer X coins to fund that contract" and it will subtract X coins from you balance and add them to the balance of that contract and when you're done you say "I want withdraw Y coins back to my balance" and it will subtract Y coins from contract balance and add them to yours. All of this of course assumes that contract has such functions implemented i.e. "fund" and "withdraw". You not giving that contract your keys at any point afaik. But it also means that if there is a flow in contract logic you could end up with theDAO situation when you can withdraw more then you normally would be able.
Anyway, bitcoin-like multisig does require you to actually have keys to move coins and if keys are known by the network i.e. everyone... well :rolleyes:
 
Very quiet in here lately...how goes testing? What are we currently working on?

this is the last thing i remember : https://www.dash.org/forum/threads/v12-1-testnet-launch-thread.9014/page-21#post-97480
i'm still waiting on an officially announced test release where that pull is implemented, so we can test the "Enable PrivateSend multi-session" option.

edit : i guess we could grab it from below and test it

https://dashpay.atlassian.net/builds/browse/DASHW-DEV/latest/artifact/JOB1/gitian-win-dash-dist/

I think the team is in the cleanup phase right now looking at github and there are also some open pull requests that are getting attention it seems

eIekEQR.jpg
 
Last edited:
Yep, doing some cleanups/refactoring while waiting for Evan to push a new version of governace code for a review
 
Last edited:

I'm referring to the last officially announced test version by flare in this thread .. anyways those revolutionary new features that would be made public after the d10e presentation
have not been included yet and also Evan did not do an official Testnet announcement yet as he mentioned he would do after that d10e presentation.
So i'm guessing they still need some time to wrap things up before making that announcement.
 
Last edited:
Status
Not open for further replies.
Back
Top