Welcome to the Dash Forum!

Please sign up to discuss the most innovative cryptocurrency!

v13.0 Testing

Discussion in 'Testing' started by codablock, Nov 10, 2018.

  1. camosoul

    camosoul Grizzled Member

    Joined:
    Sep 19, 2014
    Messages:
    2,251
    Likes Received:
    1,125
    Trophy Points:
    1,183
    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.
     
    #121 camosoul, Dec 20, 2018
    Last edited: Dec 20, 2018
  2. TanteStefana

    TanteStefana Grizzled Member
    Foundation Member

    Joined:
    Mar 9, 2014
    Messages:
    2,860
    Likes Received:
    1,854
    Trophy Points:
    1,283
    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.
     
  3. camosoul

    camosoul Grizzled Member

    Joined:
    Sep 19, 2014
    Messages:
    2,251
    Likes Received:
    1,125
    Trophy Points:
    1,183
    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.
     
    #123 camosoul, Dec 21, 2018
    Last edited: Dec 23, 2018
    • Like Like x 1
  4. TanteStefana

    TanteStefana Grizzled Member
    Foundation Member

    Joined:
    Mar 9, 2014
    Messages:
    2,860
    Likes Received:
    1,854
    Trophy Points:
    1,283
    Oh dear, I really don't understand. I hope someone steps up that can follow your concern and talk about it, sorry!
     
  5. qwizzie

    qwizzie Well-known Member

    Joined:
    Aug 6, 2014
    Messages:
    1,504
    Likes Received:
    715
    Trophy Points:
    183
    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.
     
    #125 qwizzie, Dec 21, 2018
    Last edited: Dec 21, 2018
  6. codablock

    codablock Member
    Core Developer

    Joined:
    Mar 29, 2017
    Messages:
    98
    Likes Received:
    149
    Trophy Points:
    83
    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.
     
    • Like Like x 5
  7. camosoul

    camosoul Grizzled Member

    Joined:
    Sep 19, 2014
    Messages:
    2,251
    Likes Received:
    1,125
    Trophy Points:
    1,183
    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."
    Awesome, thanks!
     
    • Like Like x 1
    • Funny Funny x 1
    • Optimistic Optimistic x 1
  8. f8192

    f8192 New Member

    Joined:
    Dec 17, 2017
    Messages:
    27
    Likes Received:
    4
    Trophy Points:
    3
    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?
     
    #128 f8192, Jan 1, 2019
    Last edited: Jan 1, 2019
    • Like Like x 2
  9. Miner237

    Miner237 Well-known Member
    Foundation Member

    Joined:
    May 28, 2014
    Messages:
    506
    Likes Received:
    223
    Trophy Points:
    213
    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"
     
  10. codablock

    codablock Member
    Core Developer

    Joined:
    Mar 29, 2017
    Messages:
    98
    Likes Received:
    149
    Trophy Points:
    83
    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.
     
    • Like Like x 2
    • Informative Informative x 1
  11. camosoul

    camosoul Grizzled Member

    Joined:
    Sep 19, 2014
    Messages:
    2,251
    Likes Received:
    1,125
    Trophy Points:
    1,183
    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...
     
  12. TaoOfSatoshi

    TaoOfSatoshi Grizzled Member

    Joined:
    Jul 15, 2014
    Messages:
    2,699
    Likes Received:
    2,604
    Trophy Points:
    1,183
    Bring it on!
     
    • Like Like x 1
    • Winner Winner x 1
  13. camosoul

    camosoul Grizzled Member

    Joined:
    Sep 19, 2014
    Messages:
    2,251
    Likes Received:
    1,125
    Trophy Points:
    1,183
    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...
     
    #133 camosoul, Jan 2, 2019
    Last edited: Jan 2, 2019
  14. strophy

    strophy Administrator
    Dash Core Team Dash Support Group Moderator

    Joined:
    Feb 13, 2016
    Messages:
    670
    Likes Received:
    378
    Trophy Points:
    133
  15. qwizzie

    qwizzie Well-known Member

    Joined:
    Aug 6, 2014
    Messages:
    1,504
    Likes Received:
    715
    Trophy Points:
    183
    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






     
    #135 qwizzie, Jan 3, 2019
    Last edited: Jan 3, 2019
  16. thephez

    thephez Member
    Dash Core Team

    Joined:
    Jan 23, 2016
    Messages:
    113
    Likes Received:
    49
    Trophy Points:
    78
    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.
     
    • Like Like x 1
    • Useful Useful x 1
  17. Miner237

    Miner237 Well-known Member
    Foundation Member

    Joined:
    May 28, 2014
    Messages:
    506
    Likes Received:
    223
    Trophy Points:
    213
    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.
     
  18. strophy

    strophy Administrator
    Dash Core Team Dash Support Group Moderator

    Joined:
    Feb 13, 2016
    Messages:
    670
    Likes Received:
    378
    Trophy Points:
    133

    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.


    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.



    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.
     
    • Like Like x 1
  19. strophy

    strophy Administrator
    Dash Core Team Dash Support Group Moderator

    Joined:
    Feb 13, 2016
    Messages:
    670
    Likes Received:
    378
    Trophy Points:
    133
    @camosoul can you provide specifics of what you would you think is missing or would like to see included?
     
  20. camosoul

    camosoul Grizzled Member

    Joined:
    Sep 19, 2014
    Messages:
    2,251
    Likes Received:
    1,125
    Trophy Points:
    1,183
    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... ;-)
     
  21. strophy

    strophy Administrator
    Dash Core Team Dash Support Group Moderator

    Joined:
    Feb 13, 2016
    Messages:
    670
    Likes Received:
    378
    Trophy Points:
    133
    I see, I thought you were referring to the documentation, not the actual design and implementation of DIP3. I have a brief response, but will let others tackle most of your concerns.

    Yes, this is possible. When preparing your registration transaction, specify the collateralHash and collateralIndex on the Trezor as usual. Specify any payoutAddress you like - hardware wallet, mobile wallet, exchange - it doesn't matter. Then use an address in the Dash Core wallet holding mixed funds for feeSourceAddress. I'm not 100% sure how the change address is selected, but it can also go straight back into mixing.
     
  22. camosoul

    camosoul Grizzled Member

    Joined:
    Sep 19, 2014
    Messages:
    2,251
    Likes Received:
    1,125
    Trophy Points:
    1,183
    It used to be that only the network traffic was involved to launch a masternode. Now that it's printed on the blockchain, too, there's a whole new web of mess one has to consider for OpSec. It doesn't seem much thought was given to this. Of course, that wasn't really on the to do list...

    I'm worried that a lot of people are going to end up compromised without knowing that this exposure vector was created by DIP3. Without having a solid explanation of how it works in the documentation, it's hard to audit it or know what's going on. The documentation reads more like a how-to, just "do this and it'll turn on" but telling the user nothing about what's happening or how it gets done. Proper OpSec requires more than the power button, but that's all the documentation tells us, because it's not really documentation, it's just a "guide." When I read it I'm left with more questions than answers, and no context to even know how to ask it properly... This is why I hate "guides." I realize that the objective is simply to get people online with as little knowledge and effort as possible, but that's dangerously foolish.

    When you live under Stasi 2.0 in East Germany 2.0, it matters. A lot. Especially when you're someone (me) who openly and loudly opposes their evil agenda. Since most people involved in Crypto agree with said agenda, it doesn't bother them to see someone like me get smashed by it. In fact, its exactly what they hope for. Crypto has become a worse version of the very monster is was supposedly created to oppose. It's become a life-risking endeavor for anyone that isn't politically extreme-left to be involved in crypto, because people like me don't get a pass like the SJW/snowflakes do. "Laws for thee but not for me." Most of the people posting on this forum can break any laws they want, and never pay any taxes. Nothing will ever be done to them because they are fellow extreme leftists... I'm not afforded the same luxuries. Most of the people on this forum are happily working lockstep with the Stasi 2.0 to make people like me extinct. If they can misrepresent 400+ MNs as mine because this TX isn't isolated, I'll be fraudulently accused of tax evasion at the soonest opportunity. There's no way I'm going to prove my innocence. Show me the judge that would care to listen to the technical complexities of DASH, and how the evidence presented doesn't actually prove anything... All that matters is that I dare to practice wrongthink, and a plausible excuse to make me disappear has been presented. That's how it's done in East Germany 2.0 these days. The only option is to keep everything concealed from, or at least un-provable to, these predatory, sociopathic, lying, commie bastards... Anything they know about WILL be weaponized. Unless you're a fellow leftist, then it'll be ignored and you can do whatever you want. But, I digress... The point is, OpSec matters. Please take it more seriously... Some of us can/will literally be killed for this.

    did it
    and
    did it properly, securely and safely so I don't get murdered in my sleep by Stasi 2.0
    Not the same thing.

    All we previously had to do was make sure we use tor, and force a different connection every broadcast. We knew everything that might be leaked in network traffic, and how to mitigate it. TCP/IP has been around for a while, so we know what to do... Even if you screw this up, network traffic isn't preserved in a blockchain for all eternity. Oh and never touch your dust, because it'll wreck you. blockchain. eternity.

    Since a TX has been added to the MN launch process, we need to know absolutely everything about how that is done and any and all information that might be leaked on the blockchain, so that we might mitigate that leakage. This was just recently invented, and the previous iteration conditioned us to not worry about it and not even ask the question because this vector didn't exist. If you screw up even one time, it will be recorded in the blockchain until the end of time... OpSec matters. DIP3's mode of operation has opened a huge can of worms, and it seems to have gone laregely unnoticed and unmentioned.


    I think I'm seeing a work around of using feeSourceAddress.

    Create a new wallet. don't use HD. getnewaddress. Send something that had been DS mixed to this address. Specify that as the feeSourceAddress.
    Clean up by allowing the change to mix, and accept all dust as a loss because you can't touch it without compromising the previous TXes.
    Send what mixes back to original wallet.
    srm wallet.dat
    or
    Somehow identify an existing x16 VIN and it's unique address. Specify this as the feeSourceAddress.
    Write off all dust generated as a loss because you can't touch it without compromising all previous TXes.
    Since it's not in the Trezor, how does DMT handle this?

    There may be some other permutations...

    How do I know if a denom is big enough? How big is this fee? What happens if the VIN balance on the specified feeSourceAddress is insufficient? Will it fail? Will there be any feedback to that effect? Or will it seek out unsafe funds elsewhere and use them without telling me? Is the only way to find out, the process of blindly doing it and hoping I don't die? Other failure modes, and what the result will be?

    How do I minimize the dust losses I'll accrue as a result of this? Doing this over 400 times... Dust collection superblocks/superTXes, please! Add proper MN blinding or tor-like tunneling of the messages and you've got the basis for a rolling blockchain completely transparent to the user...

    This is a lot of damn work for something I don't get paid to do, coupled to the risk to my life that's involved. I may decide not to do it because its just too much of a cumbersome time suck. One mistake and I'm dead. Simplify! I was hoping for a simple "useDSfunds" option to make it more manageable, but I understand why not...

    It could be as simple as DMT learning how to select DS mixed VINs as the fee payment source on it's own, checkbox in the UX. Hell, why wouldn't it be the default option? DMT can do the hunting and managing of the feeSourceAddress variable, it knows how to crawl HD... It can parse dash.conf to see the specified mix depth, crawl VINs to see if anything is sufficiently mixed and automatically select what it finds. If it finds nothing, warn the user and disable the "do stuff" button until the option is unchecked (warning the user again of the consequences), or mix depth is achieved. Poll DS balance every 10 minutes? Of course, that's all predicated upon using one's own local RPC... How would DMT know that? The current model doesn't make such a distinction in the server config, maybe a hardcoded "localhost RPC" option? Radio buttons? Localhost RPC or remote?

    Sure, the SJWs giggle at the thought of me being dead, but I'm hoping there's still a few people working on DASH that aren't sick communist freaks... If I have to stop this, that's a lot of MNOs that are just going to drop their nodes and cash out. Most of the people I've onboarded to running MNs have already expressed that they wouldn't do it without my help.

    This doesn't benefit me alone. I'm just an example... The world in which the most powerful governments really are this evil isn't coming. It's here. Help me live in it?

    I thought DAPI was coming a lot sooner, or I would have taken that DMT .onion service more seriously... Never did get dashd to run on the Pi 0...
     
    #142 camosoul, Jan 4, 2019
    Last edited: Jan 4, 2019
  23. qwizzie

    qwizzie Well-known Member

    Joined:
    Aug 6, 2014
    Messages:
    1,504
    Likes Received:
    715
    Trophy Points:
    183
    I assume we can specify the feeSourceAddress in the v0.13 upgrade procedure Masternode Registration for Dash Core, step : Prepare a ProRegTx transaction ?
    Currently in that procedure the "Prepare a ProRegTx transaction" step only shows :

    [​IMG]

    Can we add the feeSourceAddress to it and emphasize this should only be used when the payoutAddress is located on a separate wallet (hardware wallet / exchange wallet, any address not under direct control of the Dash Core wallet).

    Maybe even add it as pure text to the v0.13 upgrade guide ("Prepare a ProRegTx transaction" step) here too as last step :

    Lastly ... feeSourceAddress .. generate or choose .. etc etc.

    getnewaddress

    * make sure it has funds (a few duffs) before further proceeding *

    Also we need to make sure this works as intended, so we need to test this before release...


     
    #143 qwizzie, Jan 4, 2019
    Last edited: Jan 4, 2019
  24. f8192

    f8192 New Member

    Joined:
    Dec 17, 2017
    Messages:
    27
    Likes Received:
    4
    Trophy Points:
    3
    Excuse me, is PrivateSend supposed to work with integer numbers only? When i type anything with lower denomination it throws an error
     

    Attached Files:

  25. camosoul

    camosoul Grizzled Member

    Joined:
    Sep 19, 2014
    Messages:
    2,251
    Likes Received:
    1,125
    Trophy Points:
    1,183
    You should be able to use numbers down to a single duff, breaking a 0.001 for unmixable change...
    Hmm... UX seem confusing since it shows a balance, but not a DS balance. From that screenshot, we have no way of knowing if you have a sufficient DS balance... Maybe the error is totally appropriate. There's no way you or I can tell... What's going on?

    If I type
    Code:
     ~/.dashcore/dash-cli getwalletinfo
    I get
    Code:
    {
      "walletversion": 120200,
      "balance": [redacted],
      "privatesend_balance": [redacted],
      "unconfirmed_balance": [redacted],
      "immature_balance": [redacted],
      ...
    }
    Very succinct. Exactly what I needed.

    ...just pointing out why I don't use the QT anymore. It's a pain. Instead of being user friendly, it's annoying and subverts the user's interest. How did DASH end up with a CLI that is an improvement over the GUI?

    I had a lot of annoying errors with the QT. All of which seemed to be contradicting itself. When I switched to the CLI I could actually see what was happening and it made a lot more sense. Turns out I wasn't crazy, QT is is crazy.

    Would be nice if the GUI showed users what they need to know...

    I ran into two conditions where this "insufficient balance" would happen to me, even when I'm not using DS.

    1) Not long after having sent a new, very large VIN. Say, 75,000 DASH. The cleint willbreak this into denominations, then start mixing. During the initial denomination process, you can't touch it. The QT won't tell you what's going on. It shows you the balance, but then it tell you you have nothing. You can try to send 0.00000001 DASH and it'll tell you that your balance is insufficient. If you're rolling a "tail -f debug.log" you'll eventually realize that you can't touch your duffs during the denomination process. Nobody will tell you this. It's not documented. The QT won't tell you why. Just wait about half an hour and it'll work. It does not instill confidence. Especially when it seems like the thing has gone haywire by giving you conflicting information about your very large pile of money you can't seem to touch anymore...

    2) The QT selects source funds very stupidly. Again, a DS related issue. The QT loves to select VINs that are pending from a mix submission. Nobody will tell you this. It's not documented. The QT won't tell you why. But, when it tries to generate/sign the message, it'll tell you that your balance is insufficient because it picks VINs that are pending. It's dumb.

    It'll do this whether you use DS or not, but it a condition caused by not reporting or not noticing that DS is in mid-mixing operation. Again, if you watch tail -f debug.log, and try to hit the command right after a new block lands (grep for "new best" lines), and before DS can accomplish anything or reset it's state after the new block, it'll work perfectly... But, once DS starts doing it's thing, you get dumb, self-contradicting errors that leave you wondering if this thing can be trusted, if you're about to lose everything, or already lost everything... The sane person will try to restart the software, but that just exacerbates the problem... You can end up with a bunch of wallet TXes that never broadcast and need to be zapped... At no point is there any outward indication what's going on or why. It's actually perfectly normal. Just wait. It'll get it's head out of it's butt in about half an hour...

    When dealing with the large numbers I do, this crap gives me a heart attack. When I discovered that the CLI doesn't suffer from these problems, I quit using the QT. I don't need this stress in my life.

    I also force a restart of the deamon in cron every so often. It used to be my lame way of dealing with the constant crashes. But ever since the malformed block update imported from Bitcoin core, the client runs solid and never crashes anymore. I mean never. Now the cron restarts are there strictly to deliberately re-index and zap all TXes every once in a while. Paranoid habit... Not sure if it's helping not, but I don't have any of these weird problems anymore. Can't wait to go DAPI/light...

    One thing that does sometimes happen with using DS from the command line, is that it will pick tons of tiny VINs that result in a "transaction too large" failure. If you're trying to create 1000 DASH outputs from a wallet containing very large amounts of DASH, you'll run into this. You may successfully get a a few dozen 1000 DASH outputs. But, then the next one keeps throwing "transaction too large." What, I'm too big of a whale? No, it actually means the physical size of the transaction is too big, not the amount of DASH. What happened is that the previous 1000 DASH increments were created using all the large VINs. 10s and 1s. All you've got left is a giant heap of .01s. Blocksize limitations being lifted resulted in a condition where each transaction had to be limited in size to prevent a problem. DS doesn't pick what it throws into a TX very wisely. You end up with, say, 1200 DASH worth of .01 that exceeds the TX KB limit if you try a 1000 DASH TX on it. Send to self in a smaller amount. Keep trying smaller numbers until it works. That new VIN will re-denominate with new 10s and 1s. Eventually, it'll all re-mix and you'll be able to make a TX out of it with the new, larger denominations... This definitely bones your privacy... DASH doesn't handle "seismic events" well. and why should it? It's an edge case that almost never happens...

    Sadly, it can be said that XMR doesn't have these problems... All of these have been nagging issues for years, which will all be fixed in Evolution... Or so we were told years ago... Here's 0.13 on testnet... 0.13.0.0-RC11 looks like our girl... Evolution is here. I really hope it gets fixed... Only one of the people currently working on DASH was actually around way back then... These loose ends have been left untied for waayyy too long. Most of the team is a bunch of new guys who may not even be aware of it... It may seem like getting blindsided out of left field when a bunch of people start saying "Uhm, what about X, Y, and Z that you promised? Evolution doesn't at all resemble what Evan said it would back in 2015, and all these problems are still problems..." Saying "It's not ready yet, wait for Evolution, it'll all be fixed in Evolution." isn't going to work anymore, because this is Evolution... The rest of the marketplace has "DASH promise fatigue" to the point that nobody takes it seriously anymore... [fingers crossed]
     
    #145 camosoul, Jan 4, 2019
    Last edited: Jan 5, 2019
  26. qwizzie

    qwizzie Well-known Member

    Joined:
    Aug 6, 2014
    Messages:
    1,504
    Likes Received:
    715
    Trophy Points:
    183
    I came across these sort of errors too, while trying to PrivateSend certain transactions, i dont think it has anything to do with integer numbers.
    What i normally do with PrivateSend transactions these days is :

    * Mix to at least 9 rounds (provides pretty strong privacy)
    * Try to send a PrivateSend transaction, if your mentioned error occurs you then have two options :

    1 : Lower your number of rounds with one round (in this case to 8 rounds) and try to send that PrivateSend transaction again ( this seems to work most of the times as it frees up some input amounts and you still have strong privacy)
    2 : Do more mixing by setting your number of rounds higher (in this case to 10 rounds), hit the Start mixing button and when done mixing try to send that PrivateSend transaction again

    Setting higher or lower number of rounds to mix can be done through Settings --> Wallet --> PrivateSend rounds to use (which can be set all the way to 16).
    Personally i prefer to set the number of rounds to mix a bit higher then strictly necessary, so i can just lower the number of rounds if that PrivateSend error pops up and still have strong privacy.
     
    #146 qwizzie, Jan 4, 2019
    Last edited: Jan 4, 2019
  27. strophy

    strophy Administrator
    Dash Core Team Dash Support Group Moderator

    Joined:
    Feb 13, 2016
    Messages:
    670
    Likes Received:
    378
    Trophy Points:
    133
    Thanks @qwizzie good catch! I added feeSourceAddress three days ago to the setup guide but forgot it also needed to be added to the upgrade guide. That is now done, together with a short note on what this argument could be used for.

    I completely agree and also live in a county where this level of OpSec is a concern. But DCG is responsible for developing and documenting software, not OpSec. It is simply beyond scope of the documentation, which must be written from a neutral perspective and kept as simple as possible so the broadest possible audience (and translators) can comprehend it and complete the task. The DIP on which both the software and documentation are based contains sufficient detail for users needing to take additional security measures.

    What errors did you encounter? The official cross-compiled release should run fine under arm-linux-gnu. I recently submitted a PR to fix compilation under armv7l, but it is probably not going to make it into the 0.13 release.
     
    • Like Like x 1
  28. camosoul

    camosoul Grizzled Member

    Joined:
    Sep 19, 2014
    Messages:
    2,251
    Likes Received:
    1,125
    Trophy Points:
    1,183
    The point is that what is being called documentation is actually a guide, and no actual documentation exists. This makes finding the needed facts to perform proper OpSec due diligence is next to impossible.

    Documentation is exhaustive. A guide covers just barely enough to get from A to B with no details or options. We've got a guide. Not documentation.

    I'd gladly RTFM, but there is no FM. Not that I can find...

    man dashd

    Or at least a well commented config file with commented syntactical examples...

    torrc is a good example of how to do this properly with minimal effort... Or course, this wouldn't cover the actual process... Which is why both a guide and proper documentation are both needed.

    In fairness, it's not like it's been around for 15 years... Making it go has been the focus, not writing an exhaustive man page...
    Code:
    Linux hostname 4.14.9+ #1159 Sun Nov 4 17:28:08 GMT 2018 armv6l
    
    This seems like it would matter...

    Code:
    [email protected]:~/.dashcore $ ./dashd
    Segmentation fault
    [email protected]:~/.dashcore $
    
    No obvious readme about dependencies or some such...
     
  29. strophy

    strophy Administrator
    Dash Core Team Dash Support Group Moderator

    Joined:
    Feb 13, 2016
    Messages:
    670
    Likes Received:
    378
    Trophy Points:
    133
    This exists, but likely doesn't work because Dash is generally installed from a direct download rather than a package manager. If you are using Fedora, @t0dd has packages which should result in man dashd working. I have tried to get similar packages working under Debian/Ubuntu but I just don't have the necessary skill/understanding. Any help here would be welcome. The contents of the manpage are likely similar to the argument/RPC documentation located here: https://docs.dash.org/en/latest/wallets/dashcore/cmd-rpc.html

    Yes, that is likely the problem. I only have an armv7l platform for testing, and I think most devs don't even have that. Devs might respond here to help you troubleshoot what is causing the segfault, but I recommend you open an issue on Github to follow up on this.
     
  30. t0dd

    t0dd Active Member

    Joined:
    Mar 21, 2016
    Messages:
    151
    Likes Received:
    132
    Trophy Points:
    103
    Dash Address:
    XyxQq4qgp9B53QWQgSqSxJb4xddhzk5Zhh
    Access to Fedora packages can be found here: https://github.com/taw00/dashcore-rpm

    man dashd gives me...

    Code:
    DASHD(1)                                                              User Commands                                                             DASHD(1)
    
    NAME
           dashd - manual page for dashd v0.13.0.0
    
    DESCRIPTION
           Dash Core Daemon version v0.13.0.0
    
       Usage:
           dashd [options]
                  Start Dash Core Daemon
    
    OPTIONS
           -?
                  Print this help message and exit
    ...etc...