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

v13.0 Testing

https://docs.dash.org/en/latest/masternodes/dip3-upgrade.html#option-1-automatic-method

When fix?

I haz sad of trustz

OpSec point of interest: Can it be specified/forced that such fees are paid from PS balance of broadcasting daemon?

If not, could this be a feature-add? Seems like a quick copy-pasta from realm of sendtoaddress/true false true possible?

Failing this, MN Hosting Services cease to be private by means beyond their control. This forces unsafe use.

@moocowmoo
@UdjinM6
@Bertrand256
I'll quote myself for emphasis, since nobody wants to acknowledge this problem.

And I'll further add, that if these types of fees could be paid ONLY from PS balance (instead of being an option), this would have the side effect of making the collateral unbreakable...

...not to mention, those offering to pay the fee wouldn't be forcibly associated, which is another problem...

There's a lot of collateral damage (no pun intended) here which is being completely ignored.
 
Last edited:
Trying to understand your objection @camosoul . When making the protx transaction, there is a tiny transaction fee that you feel will compromise the privacy of the MNO. Right? But you do see that you can manually enter this information into a fully sync'd core wallet, entering the results in MNT and execute the update through the combination of MNT and a core wallet without trust? It's just the fully automated version that goes through a trusted node. I'm terrible at explanation, sorry! Let me know if I'm wrong!

Also, paying $5 to cover everyone's fees means nothing in the long run. What would authorities gleen from that? How could the fee payer be held responsible for anything? I don't think there is a risk there, just choosing to take the easy way out to make things as easy as possible for the MNO. It's good to hash out the logic in this, let me know what I'm not seeing :) I hope I don't come across as dismissive or antagonizing, as I know I may not be getting it.
 
I'm wrong!
That's not the point I'm making at all...

My point is that there is no way to pay the fee from privatized funds, which creates multiple OpSec problems.

My secondary point is that if paying it from privatized funds were required, this problem would be solved and the trusted broadcaster would be decoupled from the blockchain vector for his benefit as well, if not the trust vector.

If it's at least optional, the MNO can CHA.

Trust vectors can be managed. Blockchain exposure cannot. I think a lot if MNOs do not realize what they are losing as a result if this shift in function.

Also, "tiny" is not a number. But, it is larger than zero, and, therefore, exists.
 
Last edited:
Oh dear, I really don't understand. I hope someone steps up that can follow your concern and talk about it, sorry!
 
Question about v0.13 testing procedure : will there be a code-freeze stage at some point for v0.13, where only bug fixes will be integrated into v0.13.0 and all other pull requests will be reserved for v0.13.1 ?
I noticed code-freezes were implemented in some of the previous versions, but i have not noticed it yet for this version and since we are working with release candidates i'm starting to wonder about that.
 
Last edited:
RC10 has just been released: https://github.com/dashpay/dash/releases/tag/v0.13.0.0-rc10
Please upgrade when you find time, it's however not that urgent this time.

@qwizzie We are in feature freeze atm and only do fixes from now on. I think RC10 is pretty stable and might end up being the last RC. For the next release (v14), we'll probably redefine the release process and introduce something like "beta" versions before going to RCs, this was also suggested in this thread. The current release process did not align well with the testing and many fixes that were needed when deployment on testnet began. This release was special in some ways, e.g. the multi-stage deployment plan.

@camosoul We're looking into the possible privacy issues that you brought up.
 
...we'll probably redefine the release process and introduce something like "beta" versions before going to RCs, this was also suggested in this thread. The current release process did not align well with the testing and many fixes that were needed when deployment on testnet began. This release was special in some ways, e.g. the multi-stage deployment plan.
DASH is quite a lot more complex than any other crypto project. Drawing the line between beta/RC is more difficult, because there is an order of magnitude, at least, more potential for the unpredictable. I'm not sure there's a point in making the distinction. I suggest that your time is better spent on pretty much anything other than worrying how to most appropriately pick nits from that split hair... It's testnet, just whatever... It's just not that important.

What other cryptocurrency even has a use for a multi-stage deployment, rolling through the entire process with every RC?

While other projects are fingerpainting on the wall with their own poo, you're painting the Sistine Chapel... My advice to critics of this process are "Just shush and stand back."
@camosoul We're looking into the possible privacy issues that you brought up.
Awesome, thanks!
 
1) Why is there no user-friendly way to know if my transaction is going to be auto-locked (has <=4 inputs), before sending it? This info could be useful. I'm asking for simple message, just like "gonna confirm instantly" or "will need a few minutes to confirm, check InstantSend box to force instant confirmation".
2) Am I right thinking that auto-locked txs are no different for a receiver than normal IS transactions? Thus, all wallets/exchanges which do not support IS will show that tx is unconfirmed, even if it is locked, right?
 
Last edited:
Can someone explain the protx register_fund feature that was added to the protx command?

Does that replace the register_prepare syntax when you want to specify funds for the protx?

In the console help menus register_prepare says use "feeSourceAddress" but register_fund uses "fundAddress"
 
RC11 has just been released: https://github.com/dashpay/dash/releases/tag/v0.13.0.0-rc11
Only change is a new parameter for all protx commands. The parameter allows you to specify which address should be scanned for inputs usable as fees source. If not specified, it will try to use the rewardAddress to pay the fees, which will however only work if the key belonging to that address is in your local wallet. This means, you have two options to pay the fees now:
1. Send a few Duffs to the reward address before doing the actual protx commands. Use PrivateSend if you want to avoid linkage of masternodes through fees. Then call the protx command without explicitly specifying the fees source.
2. Do the same as in 1., but use a fresh address to send funds to and specify that address in the protx command.

This should allow cautious MNOs to register and update their MNs without linking them together by fee inputs/outputs. This is basically what @camosoul was reporting/complaining about.

@Miner237 No, "protx register_fund" is not meant as a replacement for the prepare/sign/submit flow. The reason is that register_fund is NOT supported on Trezor at the moment.
 
RC11 has just been released: https://github.com/dashpay/dash/releases/tag/v0.13.0.0-rc11
Only change is a new parameter for all protx commands. The parameter allows you to specify which address should be scanned for inputs usable as fees source. If not specified, it will try to use the rewardAddress to pay the fees, which will however only work if the key belonging to that address is in your local wallet. This means, you have two options to pay the fees now:
1. Send a few Duffs to the reward address before doing the actual protx commands. Use PrivateSend if you want to avoid linkage of masternodes through fees. Then call the protx command without explicitly specifying the fees source.
2. Do the same as in 1., but use a fresh address to send funds to and specify that address in the protx command.

This should allow cautious MNOs to register and update their MNs without linking them together by fee inputs/outputs. This is basically what @camosoul was reporting/complaining about.
Aw, shucks... [mwah]

...now it's up to me to figure out how this works...

Any comms with Satoshi Labs about updating Trezor firmware for support?

@TaoOfSatoshi has one heck of a guide update workout ahead of him...
 
1) Why is there no user-friendly way to know if my transaction is going to be auto-locked (has <=4 inputs), before sending it? This info could be useful. I'm asking for simple message, just like "gonna confirm instantly" or "will need a few minutes to confirm, check InstantSend box to force instant confirmation".
2) Am I right thinking that auto-locked txs are no different for a receiver than normal IS transactions? Thus, all wallets/exchanges which do not support IS will show that tx is unconfirmed, even if it is locked, right?
I still suggest that IX needs to be detached from the current mode of operation, as it makes the process sender-centric. The whole point of IX is to assure the RECIPIENT that the TX can't bounce.

It should be possible for any observer holding memory pool to request a VIN lock on any TXID it sees, with total disregard to VIN ownership. A fee should be part of this. Anyone on the network can pay a fee and IX lock any current mempool TXID. This also means that the client initiating the message, which if malevolent, is clearly not going to help the rest of the network figure it out... So, removing the power from the sender takes the power to abuse the network out of the message initiator's hands altogether, since it simply wouldn't be managed that way anymore...

The worst case scenario, under the model I'm suggesting, is that a bad actor essentially becomes a generous humanitarian, paying fees to lock everyone else's TXes for them... Oh darn, not that... The Black Hat becomes a charity of his own funds...

This allows centralized, passive HD chasing wallets to request IX on any TX in it's HD chain, without needing to be directly coordinated with the node actually conducting the transaction. This would help large retailers.

But most importantly, NOT doing it this way leaves the vendor to wonder if the buyer is jerking them around. Waiting for confirmations is not an option at the checkout counter. It has to happen NOW, with certainty. While a bad actor may not be able to enact the exploits of other coins on DASH, he can still back up the line by deliberately not using IX and make DASH look bad in the eyes of the vendor...

If you're going to do this on-chain, it has to work every time. The only way to be assured of this, is that it not be in the hands of the sender. Off-chain and side-chain settlement systems, like lightning network, offer this assurance. DASH currently does not, in spite of having been the ones to invent the concept... That's rather embarrassing.

Right now, it's backwards.

At the very least: IX needs to be recipient-centric, since it is the recipient which is meant to be assured of security. As it currently operates, this assurance is ambiguous and still exploitable by nuisance vector, even if not by transaction reversal vector or transaction failure vector. From a retail vendor's perspective, this nuisance vector could be a major deal breaker. The final operation of any POS transaction, the actual movement of funds, can't be monkey-wrenched in any way.

Making it open ended is just another bonus, as I see it... @UdjinM6 has previously explained that the current mode of operation is a deeply-rooted technical limitation. I'm saying that's gotta change... It's a significant augmentation of how crypto-at-large has been operating since it's inception; but, so are masternodes... Which leads to PoSe for privileged mining, but I'm already straying off topic for a testnet thread...
 
Last edited:
@camosoul beta docs for the upgrade process are available here: https://docs.dash.org/DIP3-masternode-upgrade

Situation : i'm a masternode owner and i want to dedicate my blockrewards to a different address then my current collateral address.

A couple of questions / remarks :

1 : Does this mean that i can provide 0 as operatorReward and state my different address in payoutAddress in the preparation of my ProRegTx transaction and be done with it ?
2 : Does the source for fees issue still play a role in above situation, when my different payout address is located in a separate hardware wallet?
3 : Those masternode owners that do fill a percentage other then 0 as operatorReward will need to have their operator do a separate update_service transaction as the owner does not specify the operator’s payout address.
Should we not include that more clearly in our Dash 0.13 upgrade procedure ? Either by adding clear operator instructions or by adding a link (
https://docs.dash.org/en/latest/masternodes/maintenance.html#updating-masternode-information).
4 : Maybe a bit of a dumb question, but will v0.13 need a restart from cold wallet for masternode owners ? (i'm getting the impression it does not need that)
5 : Can someone please change "(Step 5 below)" to "(Step : Submit the signed message)" as these steps are not numbered at all, so it can be confusing. The "Step 5 below" can be found in here : Masternode Registration from Dash Core
-> Add the private key to your masternode configuration






 
Last edited:
A couple answers...
1 : Does this mean that i can provide 0 as operatorReward and state my different address in payoutAddress in the preparation of my ProRegTx transaction and be done with it ?
Yes

3 : Those masternode owners that do fill a percentage other then 0 as operatorReward will need to have their operator do a separate update_service transaction as the owner does not specify the operator’s payout address.
Should we not include that more clearly in our Dash 0.13 upgrade procedure ? Either by adding clear operator instructions or by adding a link (
Operators should be familiar with this. Also, the owner does not need to be too concerned about whether or not the operator actually does specify a payout address - in the event the operator does not provide one, the entire reward will go to the owner.


4 : Maybe a bit of a dumb question, but will v0.13 need a restart from cold wallet for masternode owners ? (i'm getting the impression it does not need that)
During the transition phase (post v0.13 install, but before DIP3 / Spork 15 activation), masternodes will still operate the way they do today (i.e. start required). After the transition to the new MN system completes with spork 15 activation, it will no longer be necessary to start them. At that point all necessary info to validate/run them will exist in the DIP-3 txs on-chain.
 
A couple answers...

Yes


Operators should be familiar with this. Also, the owner does not need to be too concerned about whether or not the operator actually does specify a payout address - in the event the operator does not provide one, the entire reward will go to the owner.



During the transition phase (post v0.13 install, but before DIP3 / Spork 15 activation), masternodes will still operate the way they do today (i.e. start required). After the transition to the new MN system completes with spork 15 activation, it will no longer be necessary to start them. At that point all necessary info to validate/run them will exist in the DIP-3 txs on-chain.

You will have to hot wallet start the MN after version 13 to bump the protocol to 70213 just like usual, and then you will have the PROTX command you have to run to register on the deterministic list once activated.

This is going to be a fun couple of months...How long for ant pool to update I'm placing bets on first and last mining pools to upgrade.
 
2 : Does the source for fees issue still play a role in above situation, when my different payout address is located in a separate hardware wallet?

If your private key for the payout address is in a separate wallet and you do not specify a feeSourceAddress, you will not be able to submit the transaction since Dash Core will attempt to pay the fee from an address it does not control. Specifying a feeSourceAddress is therefore needed to cover the transaction fee when you submit the transaction.

4 : Maybe a bit of a dumb question, but will v0.13 need a restart from cold wallet for masternode owners ? (i'm getting the impression it does not need that)

Good question! I think a restart will be required because a protocol bump has occurred. I will confirm this and make sure it is added to the documentation upgrade guide. The masternode will continue running (and getting paid) according to the old system until Spork 15 activates. At that point we stop talking about "starting" a masternode, they are "registered" in a transaction instead.

5 : Can someone please change "(Step 5 below)" to "(Step : Submit the signed message)" as these steps are not numbered at all, so it can be confusing. The "Step 5 below" can be found in here : Masternode Registration from Dash Core

Done, thanks for that. I have reviewed all DIP3 documentation again today and appreciate any further comments and testing, particularly from hardware wallets using DMT.
 
@camosoul can you provide specifics of what you would you think is missing or would like to see included?
 
@camosoul can you provide specifics of what you would you think is missing or would like to see included?
Well, I'm hesitant to do so because I fear my grasp of how this new system works is still somewhat tenuous.

If I'm seeing this correctly, and I might not be...

The feature added to RC11 is the simplest workaround you could find without further delaying the rest of the project. Fully understandable since it would probably take quite a bit more time and effort to specify that fees be paid via deep DS funds. Fully vetted MN OpSec isn't the focus of this major update.

My concern with the workaround is that it's not clear, and could easily be fumbled... For self-preservation reasons, I've been trying to avoid saying it directly. I look at how I'm going to manage it across hundreds of MNs, trying to keep the owners not only unlinked from each other, but unlinked from the operator or the payment source... It's a lot of very fancy footwork with your workaround, one mis-step, someone gets hammered by Stasi 2.0. I have to keep myself separated to avoid false accusations of unclaimed income via Stasi 2.0 trying to take me out. I don't actually run any MasterNodes, but I could end up linked to the broadcasts for the people I'm helping... It's a workaround, and I would hope that it gets a more robust support in a later revision when you aren't so heavily focused on the priorities at hand. I really don't want this fee payment anywhere in an HD chain that might be reconstructed. Certainly not on the trezor... Instead of having to have that extra setup step, it would be better to specify that the fee is paid from DS funds.

The feature I'm requesting, and expressing the problem that it fixes, presents a few challenges of it's own.

How do you register a collateral address on a hardware wallet, while paying from denominated funds which, by current definition, cannot exist in a hardware wallet? You have to use two different wallets. Can the rest of the protocol comprehend this?

Since DMT can access both a "remote" RPC daemon (which can be running @localhost), and a local hardware wallet... Maybe This should be addressed more to @Bertrand256 ? Though, it seems both the dashd and DMT would have to understand and support this operation... It seems to me that it would need co-ordination between all...

Moving forward I'm not sure how this conflicts with dash-qt. A separate dashd and DMT tool as currently use, compared to what I assume will be dash-qt becoming a light client through DAPI. Does DMT become obsoete? Merge it's functionality into dash-qt? Hardware wallets are strongly recommended in the documentation for a reason. To avoid wasted resources, I'm not sure where to plug that functionality in. I'm not part of DASH Core... ;-)
 
Back
Top