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

How To Withdraw EVOnode Rewards from Dash Platform.

CoinRider

New member
Hello,
How to make withdraw's of EvoNode Rewards ?


Trying to proceed with Dash Evo Tool v0.1.3
by this video example


And getting errors:

Error: Withdrawal error: Proof verification error: context provider error: Context provider error: JSON-RPC error: transport error: Couldn't connect to host: No connection could be made because the target machine actively refused it. (os error 10061)

Error: Withdrawal error: Dapi client error: Transport(Status { code: Internal, message: "Internal error", metadata: MetadataMap { headers: {"grpc-accept-encoding": "identity", "grpc-encoding": "identity", "content-type": "application/grpc+proto", "date": "Sat, 09 Nov 2024 11:58:11 GMT", "x-envoy-upstream-service-time": "14", "server": "envoy"} }, source: None }, Address { ban_count: 0, banned_until: None, uri: https://93.190.140.112:443/ })



What can cause this errors?
Or is there any other way how to do this?

Thanks.​

 
Try again and again, it often fails several times before working, also verify if your withdrawal appears on this page https://mnowatch.org/evonodes/ In case it doesn't help, wait for 2 days and a new version of the DET will be released that may solve this problem.
 
Hello,
How to make withdraw's of EvoNode Rewards ?


Trying to proceed with Dash Evo Tool v0.1.3
by this video example


And getting errors:

Error: Withdrawal error: Proof verification error: context provider error: Context provider error: JSON-RPC error: transport error: Couldn't connect to host: No connection could be made because the target machine actively refused it. (os error 10061)

Error: Withdrawal error: Dapi client error: Transport(Status { code: Internal, message: "Internal error", metadata: MetadataMap { headers: {"grpc-accept-encoding": "identity", "grpc-encoding": "identity", "content-type": "application/grpc+proto", "date": "Sat, 09 Nov 2024 11:58:11 GMT", "x-envoy-upstream-service-time": "14", "server": "envoy"} }, source: None }, Address { ban_count: 0, banned_until: None, uri: https://93.190.140.112:443/ })



What can cause this errors?
Or is there any other way how to do this?

Thanks.​


With regards to the 'Internal error' that is blocking your withdrawals : it is most likely related to your owner private key causing an issue with withdrawals, but to be 100% sure that is the case, it is maybe better that you talk to QE (quantum explorer) about this. I have informed him about your issue on Discord (help-desk channel) and i will tag him here : @QuantumExplorer

This is my still open Github issue with regards to 'internal error' when using owner private key with DET to create a withdrawal and the solution i found for myself after a few days is in there as well --> https://github.com/dashpay/dash-evo-tool/issues/28
 
Last edited:
@CoinRider and everyone else : Do not sent Withdrawals to your Ledger hardware wallet address directly (as destination address).
It will be receivved in your Ledger hardware wallet address, but you can't get it out of Ledger wallet through DMT --> bytearray index out of range error. Bertrand256 (dev of DMT) is looking into it, but this could take awhile. Same problem it seems with Trezor, but perhaps more easily fixed.

Just use a Dash Core wallet address as payout address for your Evonode for now and dont sent Platform withdrawals through DET directly to your hardware wallet address. Sent them to your Dash Core wallet address.
 
Thank You,
Try again and again, it often fails several times before working, also verify if your withdrawal appears on this page https://mnowatch.org/evonodes/ In case it doesn't help, wait for 2 days and a new version of the DET will be released that may solve this problem.
With regards to the 'Internal error' that is blocking your withdrawals : it is most likely related to your owner private key causing an issue with withdrawals, but to be 100% sure that is the case, it is maybe better that you talk to QE (quantum explorer) about this. I have informed him about your issue on Discord (help-desk channel) and i will tag him here : @QuantumExplorer

This is my still open Github issue with regards to 'internal error' when using owner private key with DET to create a withdrawal and the solution i found for myself after a few days is in there as well --> https://github.com/dashpay/dash-evo-tool/issues/28


It did passed through, and aphered on https://mnowatch.org/evonodes/

But not from first attempt, it took several attempts, and using Payout Address Private Key - selecting payout address manually.

And amount was selected, less than available. And rest change wasn't possible to withdraw same day,
but was accomplished successful withdraw attempt next day.
 
Thank You,




It did passed through, and aphered on https://mnowatch.org/evonodes/

But not from first attempt, it took several attempts, and using Payout Address Private Key - selecting payout address manually.

And amount was selected, less than available. And rest change wasn't possible to withdraw same day,
but was accomplished successful withdraw attempt next day.
Were you previously using the owner private key methode when that internal error ocurred ? And after switching to payout private key methode that solved the internal error issue for you ? (i want to be as clear as possible to devs trying to solve this issue with owner private key and show them its not just one user (me) having this problem)
 
Were you previously using the owner private key methode when that internal error ocurred ? And after switching to payout private key methode that solved the internal error issue for you ? (i want to be as clear as possible to devs trying to solve this issue with owner private key and show them its not just one user (me) having this problem)
Yes, first i tried with a Owner Key and it didn't work, it was mentioned in a video that is better to use it for now.

Next day after your suggestions , i tried with Payout Address and selected same address as a Payout address and placed a bit less amount than was available.
and i'm not sure if its passed from first attempt or from several, but it did passed and appeared in Withdrawal Queue list.

Than i tried to withdraw a rest of change left, and it didn't worked.
I tried to withdraw what left next day and it also did pass to list.
 
How about waiting till tomorrow @CoinRider ?
A new version of DET will be released that fix a LOT of bugs and issues.
 
How about waiting till tomorrow @CoinRider ?
A new version of DET will be released that fix a LOT of bugs and issues.
I don't think DET next version will fix this specific ownerkey issue, which i have created a Github issue for (https://github.com/dashpay/dash-evo-tool/issues/28) that still remains open and has no response from DET developers. I think this is very much an ongoing issue, that will affect more and more people during withdrawal initiation through DET.
 
FYI, for those who want to deal with raw truth. Thanks to the admins, I can see the deleted messages. I inform you that this thread has been severely spammed by a dark web pedo-porn advertiser, who joined this forum Jun 2, 2021. He posted 68 advertising messages, I have never seen anything like this on this forum before!!!!

And the question is, why this very person attacked this very thread, at this time? Is it by chance, or a warning message?
 
Last edited:
How about waiting till tomorrow @CoinRider ?
A new version of DET will be released that fix a LOT of bugs and issues.
Did tried to process Withdraw with new Dash Evo Tool v0.2.1

And get an Error
Error: Withdrawal error: Protocol error: platform deserialization error: unable to deserialize ConsensusError : UnexpectedVariant { type_name: "ConsensusError", allowed: Range { min: 0, max: 4 }, found: 65 }

This error appears using both keys Owner Key and Payout Address Key.

Any suggestions what can be wrong?
 
Did tried to process Withdraw with new Dash Evo Tool v0.2.1

And get an Error
Error: Withdrawal error: Protocol error: platform deserialization error: unable to deserialize ConsensusError : UnexpectedVariant { type_name: "ConsensusError", allowed: Range { min: 0, max: 4 }, found: 65 }

This error appears using both keys Owner Key and Payout Address Key.

Any suggestions what can be wrong?
Looks like a bug that not only affect owner key but now also affect payout address key, when trying to do a withdrawal in v0.2.1
I think i will stick with v0.1.3 and using my payout address key to get a withdrawal out. With next epoch in two days, i will check if this (v0.1.3) still work.

You could check if just having the payout address key in your loaded Identity helps with regards to withdrawals in v0.2.1
Maybe having both owner key and payout key in your loaded Identity causes both of them to not work anymore in this new version.

Make sure you have these two in your dash.conf as well

zmqpubhashchainlock=tcp://0.0.0.0:23708
zmqpubrawtxlocksig=tcp://0.0.0.0:23708

If that does not fix things, can you try doing a withdrawal with older DET version 0.1.3
(https://github.com/dashpay/dash-evo-tool/releases v0.1.3 - Assets)
Does that still work ?

Also on what OS are you experiencing these issues ? Windows ? Linux ? Mac ?
I am on Windows 10 Pro / using DET Windows binaries.
 
Last edited:
I can also confirm that DET v0.3.1 does not work on Windows. Only the operator’s key is accepted (the voting key is not accepted and the information is not the same as that contained in the blockchain. Voting in DAO works great and without errors)
I also noticed huge problems with connecting DET and core
 
I can also confirm that DET v0.3.1 does not work on Windows. Only the operator’s key is accepted (the voting key is not accepted and the information is not the same as that contained in the blockchain. Voting in DAO works great and without errors)
I also noticed huge problems with connecting DET and core

My experience was different, I am on windows and was able to vote on contested resources. Be sure to try several times and to verify after each vote on this special page. https://dash.vote/
 
I did some withdrawals through DET v0.3.1 on Windows 10 Pro
There are a few things to consider :

* Refresh your Evonode identy first, in case of multiple Evonode identities keep refreshing untill they all show the correct balance and in the correct order. I normally just refresh the top identity untill they are all updated and in the correct order again.
* Max button to withdrawal still has a bug (places the comma wrong / wrong max amount of dash), so manually correct this.
* Subtract 0.01 dash in your mind from your current updated balance and take that as max amount, that should get your withdrawals through
* In case of an error check your explorer.log (C:\Users\Admin\AppData\Roaming\Dash-Evo-Tool\config) as more information about that error can be found there. Usually it is about DET having an issue with how much you are withdrawing. Lowering the amount helps (hence the 0.01 dash subtraction).

Voting works for me and refreshing contested usernames works for me too.
If anyone is having an issue with DET, it is best to contact the helpdesk : [email protected] or go to the help-desk channel on Discord
 
Last edited:
He work on windows, but this bug still relevant

Error: Withdrawal error: Dapi client error: Transport(Grpc(Status { code: Internal, message: "Internal error", metadata: MetadataMap { headers: {"grpc-accept-encoding": "identity", "grpc-encoding": "identity", "content-type": "application/grpc+proto", "date": "Mon, 18 Nov 2024 18:09:27 GMT", "x-envoy-upstream-service-time": "5", "server": "envoy"} }, source: None }))

my logs today
2024-11-18T18:05:57.561522Z WARN request routine: rs_dapi_client::dapi_client: retrying error with sleeping 0.01 secs error=ExecutionError { inner: Transport(Grpc(Status { code: Internal, message: "Internal error", metadata: MetadataMap { headers: {"grpc-accept-encoding": "identity", "grpc-encoding": "identity", "content-type": "application/grpc+proto", "date": "Mon, 18 Nov 2024 18:05:57 GMT", "x-envoy-upstream-service-time": "27", "server": "envoy"} }, source: None })), retries: 0, address: Some(Address { ban_count: 0, banned_until: None, uri: https://37.60.236.151:443/ }) }
2024-11-18T18:05:57.893106Z WARN request routine: rs_dapi_client::dapi_client: retrying error with sleeping 0.01 secs error=ExecutionError { inner: Transport(Grpc(Status { code: Internal, message: "Internal error", metadata: MetadataMap { headers: {"grpc-accept-encoding": "identity", "grpc-encoding": "identity", "content-type": "application/grpc+proto", "date": "Mon, 18 Nov 2024 18:05:57 GMT", "x-envoy-upstream-service-time": "64", "server": "envoy"} }, source: None })), retries: 1, address: Some(Address { ban_count: 0, banned_until: None, uri: https://213.199.44.112:443/ }) }
2024-11-18T18:05:58.734884Z WARN request routine: rs_dapi_client::dapi_client: retrying error with sleeping 0.01 secs error=ExecutionError { inner: Transport(Grpc(Status { code: Internal, message: "Internal error", metadata: MetadataMap { headers: {"grpc-accept-encoding": "identity", "grpc-encoding": "identity", "content-type": "application/grpc+proto", "date": "Mon, 18 Nov 2024 18:05:58 GMT", "x-envoy-upstream-service-time": "117", "server": "envoy"} }, source: None })), retries: 2, address: Some(Address { ban_count: 0, banned_until: None, uri: https://157.10.199.82:443/ }) }
2024-11-18T18:05:59.041422Z WARN request routine: rs_dapi_client::dapi_client: retrying error with sleeping 0.01 secs error=ExecutionError { inner: Transport(Grpc(Status { code: Internal, message: "Internal error", metadata: MetadataMap { headers: {"grpc-accept-encoding": "identity", "grpc-encoding": "identity", "content-type": "application/grpc+proto", "date": "Mon, 18 Nov 2024 18:05:58 GMT", "x-envoy-upstream-service-time": "37", "server": "envoy"} }, source: None })), retries: 3, address: Some(Address { ban_count: 0, banned_until: None, uri: https://37.60.243.119:443/ }) }
2024-11-18T18:05:59.299490Z WARN request routine: rs_dapi_client::dapi_client: retrying error with sleeping 0.01 secs error=ExecutionError { inner: Transport(Grpc(Status { code: Internal, message: "Internal error", metadata: MetadataMap { headers: {"grpc-accept-encoding": "identity", "grpc-encoding": "identity", "content-type": "application/grpc+proto", "date": "Mon, 18 Nov 2024 18:05:59 GMT", "x-envoy-upstream-service-time": "11", "server": "envoy"} }, source: None })), retries: 4, address: Some(Address { ban_count: 0, banned_until: None, uri: https://134.255.183.250:443/ }) }
2024-11-18T18:06:03.152595Z WARN request routine: rs_dapi_client::dapi_client: retrying error with sleeping 0.01 secs error=ExecutionError { inner: Transport(Grpc(Status { code: Internal, message: "Internal error", metadata: MetadataMap { headers: {"grpc-accept-encoding": "identity", "grpc-encoding": "identity", "content-type": "application/grpc+proto", "date": "Mon, 18 Nov 2024 18:06:03 GMT", "x-envoy-upstream-service-time": "6", "server": "envoy"} }, source: None })), retries: 0, address: Some(Address { ban_count: 0, banned_until: None, uri: https://104.200.24.196:443/ }) }
2024-11-18T18:06:13.188071Z WARN request routine: rs_dapi_client::dapi_client: retrying error with sleeping 0.01 secs error=ExecutionError { inner: Transport(Grpc(Status { code: Unavailable, message: "tcp connect error: deadline has elapsed", source: Some(tonic::transport::Error(Transport, ConnectError(ConnectError("tcp connect error", Custom { kind: TimedOut, error: Elapsed(()) })))) })), retries: 1, address: Some(Address { ban_count: 0, banned_until: None, uri: https://157.90.238.161:443/ }) }
2024-11-18T18:06:23.208209Z WARN request routine: rs_dapi_client::dapi_client: retrying error with sleeping 0.01 secs error=ExecutionError { inner: Transport(Grpc(Status { code: Unavailable, message: "tcp connect error: deadline has elapsed", source: Some(tonic::transport::Error(Transport, ConnectError(ConnectError("tcp connect error", Custom { kind: TimedOut, error: Elapsed(()) })))) })), retries: 2, address: Some(Address { ban_count: 0, banned_until: None, uri: https://146.59.4.9:443/ }) }
2024-11-18T18:06:23.354290Z WARN request routine: rs_dapi_client::dapi_client: retrying error with sleeping 0.01 secs error=ExecutionError { inner: Transport(Grpc(Status { code: Internal, message: "Internal error", metadata: MetadataMap { headers: {"grpc-accept-encoding": "identity", "grpc-encoding": "identity", "content-type": "application/grpc+proto", "date": "Mon, 18 Nov 2024 18:06:23 GMT", "x-envoy-upstream-service-time": "37", "server": "envoy"} }, source: None })), retries: 3, address: Some(Address { ban_count: 0, banned_until: None, uri: https://37.60.243.119:443/ }) }
2024-11-18T18:06:23.634368Z WARN request routine: rs_dapi_client::dapi_client: retrying error with sleeping 0.01 secs error=ExecutionError { inner: Transport(Grpc(Status { code: Internal, message: "Internal error", metadata: MetadataMap { headers: {"grpc-accept-encoding": "identity", "grpc-encoding": "identity", "content-type": "application/grpc+proto", "date": "Mon, 18 Nov 2024 18:06:23 GMT", "x-envoy-upstream-service-time": "10", "server": "envoy"} }, source: None })), retries: 4, address: Some(Address { ban_count: 0, banned_until: None, uri: https://134.255.182.186:443/ }) }

Perhaps the error was made on purpose to prevent funds from being withdrawn from the platform, I don’t know
 
He work on windows, but this bug still relevant



my logs today


Perhaps the error was made on purpose to prevent funds from being withdrawn from the platform, I don’t know
If you get that error while doing it with owner key, you need to switch to using payout address private key.
Do not send it to a hardware address !! Send it to a Dash Core address.

I added your issue with owner key to my DET Github issue. Now three people having a problem with owner key.
 
Last edited:
Back
Top