Topic: ** LAUNCHED ** CredaCash -- The Most Private Cryptocurrency in the World - page 7. (Read 10790 times)

Before we push for wider deployment, we decided to make an important change to the wallet.

One of the fundamental jobs of the wallet is to work cooperatively with the user to ensure that a payment is reliably sent once and not more than once (i.e., no unintended double payments).

When the send command is submitted, the user can experience three possible outcomes:

1. The wallet responds that the payment was submitted to the network and provides a TXID to track the payment.
2. The wallet responds with an error, indicating the payment was not submitted to the network.
3. The user receives no response, which can occur when the connection between the user and wallet is interrupted.

Condition #3, the no response condition, is the most complicated to handle correctly.  The wallet may or may not have received the send command and submitted the payment to the network.  There is no way to tell from the response.  In that case, the user could query the wallet to scan for a transaction that looks similar to the one that was submitted (same address, amount and in the right block or time range). However, before making this query, the wallet would have to wait a sufficient time to allow both the network and wallet to timeout, which ensures the prior send command is not still pending or in progress.  This is the method we originally envisioned to handle this situation, but it is both complex and has reliability pitfalls.

In order to address this case better, we are implementing a new send command, cc.send, which will require three parameters: a destination, an amount, and a unique reference id. This command has slightly different semantics than sendtoaddress.  Unlike sendtoaddress, the user can submit the command "cc.send referenceid destination amount" multiple times, but the wallet will never send the payment more than once.  This allows much easier and more reliable handling of the no response condition.  If no response is received from cc.send, the user can simply submit the identical command again, as many times as required, and will eventually receive a response that contains either an error or a TXID to track the payment.  The payment however will never be sent more than once, which cannot be guaranteed by the bitcoin-compatible sendtoaddress command.  And as an added benefit, no queries will be required to scan for and obtain the TXID.

That is one of the changes we are working on, along with a number of other usability changes, including adjusting the timeout that caused many users to see "Insufficient Funds" when sending payments in the current release.  Once all of this is implemented and thoroughly tested (which might take a few weeks), we plan on releasing an updated version of the software along with a testnet, and then we will proceed with attempting to assist exchanges in listing the CredaCash currency.

Thank you again for your interest and support, and please let us know if you have any additional questions.

Credacash Devs are very responsive to users feedback and issues,
I am sure they be at their best to answer all users concerns. 

The first task is to publish the GUI wallet.

any news?

Short term, the major items on our agenda are to set up a testnet, update the Quick Start Guide and other documentation, see if we can assist any exchanges in listing the CredaCash currency.  Our long term roadmap is to continue to develop the technology, which includes more features in the wallet and blockchain (in particular, implementing our Proof-of-Stake protocol and full support for all the capabilities in our zero knowledge proof implementation), support for more platforms such as smartphones, and making everything easier to use and integrate.  Part of that is also looking a how we are going to fund the project, while maintaining compliance with applicable laws both in the USA where we are located, and in any other location that might be relevant.

Those are the major things we are working on.  Thank you for inquiry, and please let us know if there are any additional questions we can answer.

What kind of work is going on behind the scenes now?? What is approximately the road map for the month of September?

I'm not sure what that question means.  What specific numbers are you looking at that indicate that the blocks are growing?

Why are the blocks growing?

When you create a wallet, it prints out the wallet's master secret and gives instructions on how you can store that as a last resort backup.  That is intended to serve the same purpose.  (There is currently no a way to print out the master secret of an existing wallet, but we may add that in the future.)  Even with the master secret, it is still a good idea to back up the wallet file itself occasionally, since reconstructing a wallet from the master secret and password might not be 100% successful.  When backing up the wallet file, we recommend putting it into an encrypted archive file first in order to keep it secure.

Thank you for using CredaCash, and please let us know if you have any additional questions.

Thought about to back up private keys of storage addresses, good old practice of mine (and hopefully lot of others)
Easier to store 10 private keys than holding 10x 100 MB wallets.
Hope that will be an option once GUI wallet is available. 

The validateaddress command will give you some information about a CredaCash destination.  If the destination belongs to your wallet, then valudateaddress will give you the "hdmasterkeyid", which is the hash of the master secret used to create the destination.  The information needed to spend billets sent to that destination is contained in your wallet's CCWallet.ccw file and could be extracted using the sqlite3 tool.  What would you do with that information once you had it?

how to get private key of address?

Thanks Devs! PM sent

I'm not sure at this point.  Let's start with the PM and we can follow up from there.

What info do you need from my end to PM?
Thanks!

From what you have posted above, it appears that the transaction was successfully sent, but it was not sent to the second wallet, in other words, the address to which you sent the transaction does not belong to the second wallet, it belongs to some other wallet.  If you would like to troubleshoot this further, please feel free to contact us via PM or via our website if you need to provide transaction details that you would prefer not to post here.  Thank you.

I made a serious of transactions they all seem to fail and returned the following as an example of both wallets, used command gettransaction

In Sending Wallet, it returned this

 {
    "abandoned" : false,
    "account" : "",
    "address" : "CredaCash_bxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
    "amount" : -2886.51,
    "bip125-replaceable" : "no",
    "blockhash" : "0000000000000000000000000000000000000000000000000000000000000084",
    "blockindex" : 0,
    "blocktime" : 1566118604,
    "category" : "send",
    "confirmations" : 6,
    "fee" : -0.0838,
    "time" : 1566118604,
    "timereceived" : 1566118604,
    "txid" : "CCTX_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
    "vout" : 0,
    "walletconflicts" : []
  }


In Receiving Wallet, it returned this

ccwallet> gettransaction CCTX_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Executing JSON command:
{"method":"gettransaction","params":["CCTX_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"]}

Error:
{
  "code" : -5,
  "message" : "Invalid or non-wallet transaction id"
}

Glad that worked. Thank you for letting us know, and please let us know if you run into any additional problems.

you are magic... and the whole project is cool.. helped. thank you!

You can try restarting the wallet again with the --reset-wallet option and then run the listunspent command.  Please let us know if this helps.  Thank you.