Topic: [DVC]DevCoin - Official Thread - Moderated - page 289. (Read 1059181 times)

Anyone who tested the new client were you able to send coins to old clients? I sent coins to vircurex and the transaction is not on block chain. I even tried to put the fees back to what the old source was (1.0.8 ) still not on there.

To assist in the proper functioning of the Devtome wiki for future growth, articles require categorizing. Please take the time to categorize all new articles that you post. If you don’t do this it will take an admin time and effort to complete this, and as admins are quite busy behind the scenes, it is in everyone’s best interest if author’s do this as they go. In addition to your new articles, you should also go over all your previous articles and categorize them also, as it could affect your word count by 10%.

There is a brief page at Devtome Categorizing Your Articles that explains the process. If anyone notices any errors on this page, please post so we can ensure the process is correct.

Thank you.

Uploaded latest release with the changes suggested above:

Block reference to txNew and changed rpcports,

Created new hosted installer 1.0.7 at: https://sourceforge.net/projects/devcoin/files/

You can download lastest java installer here. As soon as we upload it to the official site devcoin.org I can create a web installer that will only be 1.5 megs and download the right pack depending on the platform selected.

One issue I was having was, I tried to send some coins back to my vircurex account, but I dont even see my transaction show up on the blockchain? It shows on my wallet(non confirmed), and its been more than a day? How can that happen? Maybe 0.2 dvc is too little of a fee and not accepted by old clients?


So I created 1.0.8 by setting the fees to you 5*COIN like it is in the current codebase. So the fee is high for small transactions in single digit DVC but it is ok for normal transactions. I sent a bunch using the normal fees to my vircurex account and now seeing if they get confirmed by the older client on the blockchain explorer http://darkgamex.ch:2751

Hi,

Since not all users of this coin are as active as you are, may I ask for a feature in a future wallet version?

Please implement one of the following features:
1) an autoupdate feature which automatically keeps the QT updated without the user doing anything (or with the user just clicking an "update" button which only appears when new updates are available - but where the entire update process is done automatically)
2) a notification feature where the user can enter his eMail address into the wallet and the wallet sends him an eMail when a new version is available? That requires - of course - that the wallet has a way to check for updates. But since Microsoft/Apple/Adobe/andalltheothers can do it, so can you :-)
3) (for those who don't even run their QT all the time) a notification feature where the user can enter his eMail address into the wallet and the wallet sends that eMail address plus its own version information to a central server of yours which then sends out an eMail when a new software version is available. And which sends a warning eMail when a mantatory update has to be performed.

Naturally, as of today, the Cryptocurrency-community has been very active but with the price explosion of the Bitcoin last month, more and more "normal users" will enter the market.
They will not keep their wallet running all the time.
They will not check the forum all the time.
But they might spend hard cash on buying this coin at an exchange and then send it over to their wallet. As a community, we even need that kind of passive user - and we need their money buying this coin.
And when they find ways to spend or donate the coin, they will. And for that purpose they will open their wallets - but not in between.

Having said this, I personally prefer feature (3) because it has a few advantage over the other 2:

• It keeps even those "passive" users in the loop that do not run their wallet regularily.
• That way, if a really important change has to be made (e.g. a new blockchain), even those users won't lose their money because they get a notification. Think of the bad publicity when "normal users" start losing their money because they simply ignored their wallets for months only to find them not working anymore because weeks before, a new blockchain or equally invasive measure was introduced without them knowing.
• That feature can be extended for marketing purposes: add a checkmark "the makers of this coin are allowed to send me exciting news about this coin yaddayaddaya" - and voila you get yourself a free marketing database with tons of eMail addresses that you can use to keep engaging your users. Notify them of new shops where they can pay with this currency. Notify them of faucets. Notify them of exchanges that trade this coin. Notify them of the rise in value of that coin. And so on. Just keep engaging even the passive users - because to make a currency successful, you need every hand and every dollar you can get.

You guys and all the other professionals or those that have privacy concerns won't use that feature - and should never be required to do so. But the regular passive user will get that fuzzy feeling that he will be informed of important stuff without him spending much time checking bitcointalk or their wallets. And that will give him extra confidence when it comes to him spending the coin or buying the coin with his FIAT.

Just a few additional remarks:

• Naturally, the best possible combination would be (3) with (1) where the users gets a "move your ass and update your wallet or else..." eMail (friendly version, of course) - and then he opens the wallet and clicks on the "update" button and that's it for him.
  
• May be the required serverside portion (the thing that collects all version information and the eMail addresses and which also allows for sending out mass eMails to all users in that database) could be written in a generic way so that other virtual currencies can implement that feature, too?
• May be, future wallets should have a default setting that causes them to run in the background as a service whenever the computer starts. That way, even many passive users will contribute to the P2P network without them even knowing. But that was just a sideline remark and describes a completely different feature request. But then again, while you are at it... :-)

Don't know. What do you guys think about that feature request?
Does anyone second that request?
Does anyone have a better idea how to solve the above mentioned challenges that this new species of regular, passive users will introduce in the weeks and months to come?

Thanks
Matt
_{DVC: 1NEvNu9EC9YzRoviNaZDrt6TfqfZsKqLE9}


P.S. Just a full disclosure: I have posted this same feature request to the thread of some other cryptocurrencies as well.

I haven't tried the java installer. The code must be tested and finalized before making a bounty for an installer.

You try out the java installer? I will create a sorceforge so
I can host the releases.

Thank you for your excellent code report, you get 12 shares:
https://raw.github.com/Unthinkingbit/charity/master/bounty_31.csv

The last remaining code report bounty is 6 shares.


I'm glad this will be changed. Even if it's overwritten, it's still good to have it the same as the documentation to prevent confusion.

Ya that was i0coin ports I scanned Important places left that one out.. Should change...

Anyone have  experience with maven? Having a heck of a time building
bitcoinj with android wallet ootb.

I never use conf files, except for those ancient multicoin-based coins like the old GeistGeld and Tenebrix.

If for some reason I need to use a port other than the default I put it on the commandline in my start-the-daemon script.

Usually I do not put it on the commandline though because to do so I'd have to go digging into the source-code to discover what the heck the default port actually is, since that is the port I'd put there anyway unless it was one of those stupid crapcoins that forgot to change its port from whichever coin it was cloned from; and those coins I usually try to avoid.

-MarkM-

Ya 1.2 dvc fees are normal or 0.2 dvc fees depends on transaction..

The default rpcport is a setting in the conf file that I oerwrote I can connext so its working. I will change this but its only useful for proxies and if conf file doesnt specify rpcporr in the firet place...

Otherwise we just need to send a few coins back forth to confirm fees and mining merged works.

Ok, tested the payment fees again. When sending 8 DVC, no message from my client (it sends the payment right away). At 7 DVC, the client informs me that a 1.2 DVC fee will apply. I have not investigated further into decimals.

Unthinkingbit's original approach to the second to the post problem was to award bounties to the first few of a thing instead of only to the first.

I have seen that for pretty much all the bounties that I have noticed. Is that not the case with the ATM bounty or is that approach not a good one?

-MarkM-

At some point, 96 shares may be worth between $25k and $250k, or $250k-$2.5m. The first person/group who can produce the bounty economically will do so, including or excluding the bounty in their business plan - which is a risk in itself, since if they're second to market, they must rely on market demand alone (or perhaps a reduced bounty). There is no guarantee the price will ever get that high, but the point in time it is produced will be the moment that someone finds the risk acceptable and goes for it.

I've only ever noticed a flat 1 dvc fee. Perhaps with very low sums it differs. Makes sense to not have any transactions actually prevented as risks having to change code again in the event that price rose significantly or micro-payments become very popular.

Absolutely. Bitcoin had been promoted as no transaction fees so kind of had to use coin-age instead of all transactions having a fee.

We don't advertise free transactions hopefully so aren't thusly constrained.

-MarkM-

I didn't know it was using coin age to stop that. In any case, even if coin age can stop dust, free transactions are still a cost on the network.

Essentially they just enabled isdust function which throws the tx away or some other weird logic inside wallet.cpp that increases the fee until it gets high enough to be acceptable and another that adds fees if your close to the creation of a block?

since btc dust in devcoin codebase turns out to be under 526 uDVC medium amount are still very low in terms of btc or usd so we need to add a valid fee to deter devcoin dust.. This is valid on something like under a few hundred devcoins.. im seeing this howver wekkel is reporting he doesnt get the confirmation for 1.2dvc fee on small transactions like 10dvc like I do.. it sent it for 0.2 dvc fee.. Id like 1.0.6 to be used be a few ppl to ensure it works as I expect and like it worked on my machine.