[DVC]DevCoin - Official Thread - Moderated

[sidhujag]

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.

[sidhujag]

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.

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

[markm]

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.

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-

[sidhujag]

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.

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 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.

[Unthinkingbit]

..
Here's a detailled code report.
I took ALL the commits made by Twobits or twobits in the devcoin client.
I made a list from all the changes made by twobits and compare with the code of Sidhujag.

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.

..
The first difference about the timestamp on bip30 I think that is to avert a potential problem in the future so since blocks are already created and patch is applied I think its safe? Unless someone can prove me wrong?

I agree, it should be the same as Twobits's version. It will work anyways, but it's one less difference to keep track of.

..
pblock->vtx[0].vout[0].nValue = GetBlockValue(pindexPrev->nHeight+1, nFees);
   txNew.vout[0].nValue = minerValue + nFees;
in devtome wiki technical

But in all codes (twobits,Sidjuhag) , it's  pblock->vtx[0].vout[0].nValue = minerValue + nFees;

pblock->vtx[0] is txNew

because the txNew is the first transaction to be placed on the block:

Code:

 // Add our coinbase tx as first transaction
pblock->vtx.push_back(txNew);

so it should be changed in the code to txNew instead of pblock->vtx[0] because it's simpler and easier to read.

..
MIN_TX_FEE = MIN_RELAY_TX_FEE = 500,000,000 but in Twobits and Sidhujag values are
100,000,000 = COIN
Why ?

Twobits changed that without telling me. I didn't know because at the time we couldn't afford a code review. Now that blocks have been made with Twobit's lower transaction fee, the change must be kept and I will change the wiki documentation.

For the port difference noted by cyke64:

port used by RPCPORT is always 52332 (there's no testnet) in twobits instead of bitcoin RPCPORT 8332.
In Sidhujag , port used is 7332 defaut and for testnet 17332 (src\bitcoinrpc.cpp,src\init.cpp)
Could it be the source of your problem ?

Sidhujag wrote:

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.

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.

[sidhujag]

..
Here's a detailled code report.
I took ALL the commits made by Twobits or twobits in the devcoin client.
I made a list from all the changes made by twobits and compare with the code of Sidhujag.

Thank you for your excellent code report, you get 12 shares:


The last remaining code report bounty is 6 shares.

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

[Unthinkingbit]

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

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

[KleinMatthias]

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.

[sidhujag]

..
Here's a detailled code report.
I took ALL the commits made by Twobits or twobits in the devcoin client.
I made a list from all the changes made by twobits and compare with the code of Sidhujag.

Thank you for your excellent code report, you get 12 shares:


The last remaining code report bounty is 6 shares.

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

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

[notabot]

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.

[sidhujag]

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.

[cyke64]

..
Here's a detailled code report.
I took ALL the commits made by Twobits or twobits in the devcoin client.
I made a list from all the changes made by twobits and compare with the code of Sidhujag.

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.

Thank you 
Today I take a look in the account_31.csv but I'am only located one time in the file for trying the new Sidjuhag client.
I saw no mention yet for the code report 
I wrote during round 31 two short articles on devtome. If the word count is < to 1000 can I see my word count ? If the answer is affirmative in which file of the website Charity ?

[advanced]

thank you all for your responses both about DVC shares system, betting and ATM.

You say that the 96 shares for the first to make an open source DVC ATM machine should be only a side contribution. Moreover you want the ATM to run both ways (cash2dvc and dvc2cash).

I was pointed out that a one-way ATM will receive only half of the shares. I cannot stop to emphasise how hard it is to achieve such thing. The top todays manufacturers which are well funded, closed source and ship the ATM for freaking 4k$, only managed to build it one way. http://www.coindesk.com/lamassu-ships-first-bitcoin-atm/ .

If you really want to encourage me or others around to build an open source one, that cannot be done with a 'side contribution'.

I work in a makerspace, we are a no-profit association, and we do not have any plan of building a business model around the ATM . This is what will make it great. We won't sell it anywhere! We will just make it very easy to re-build with fine desigh, thourough documentation, open source software distribution, 3dprinted and lasercutted components, standard and available safety and electronic components.  This is the kind of project DVC should support, not some backed startups who already makes money by selling it and will 'just add DVC'.


My 2 DVC-cents.

[markm]

MIN_TX_FEE = MIN_RELAY_TX_FEE = 500,000,000 but in Twobits and Sidhujag values are
100,000,000 = COIN
Why ?

Twobits changed that without telling me. I didn't know because at the time we couldn't afford a code review. Now that blocks have been made with Twobit's lower transaction fee, the change must be kept and I will change the wiki documentation.

Why? Obviously the original / main client accepted the blocks that had the lower fee otherwise the blockchain the people using his version of the client would have forked away from the mainline blockchain.

Since it didn't obviously the old client accepted it.

The sooner we get it back to the correct value the better so we don't persist the error since we evidently do not need to cause it to persist.

(Especially if it is possible that one of these days it might end up creating a block that the original client, still in use probably for a long time to come by people who use what worked instead of trying out new versions to discover what new bugs have been introduced, might not accept. It seems like you are potentially trying to possibly blow away all the serious users who are conservative about sticking with what they know works instead of risking all on some new release. If it is not a deliberate hard-fork, fix it before it becomes one. The goal here is not to produce a hard-fork release, is it? If it is, then a block number far in the future should be chosen as the block at which it will come into effect.)

-MarkM-

[markm]

thank you all for your responses both about DVC shares system, betting and ATM.

You say that the 96 shares for the first to make an open source DVC ATM machine should be only a side contribution. Moreover you want the ATM to run both ways (cash2dvc and dvc2cash).

I was pointed out that a one-way ATM will receive only half of the shares. I cannot stop to emphasise how hard it is to achieve such thing. The top todays manufacturers which are well funded, closed source and ship the ATM for freaking 4k$, only managed to build it one way. http://www.coindesk.com/lamassu-ships-first-bitcoin-atm/ .

If you really want to encourage me or others around to build an open source one, that cannot be done with a 'side contribution'.

I work in a makerspace, we are a no-profit association, and we do not have any plan of building a business model around the ATM . This is what will make it great. We won't sell it anywhere! We will just make it very easy to re-build with fine desigh, thourough documentation, open source software distribution, 3dprinted and lasercutted components, standard and available safety and electronic components.  This is the kind of project DVC should support, not some backed startups who already makes money by selling it and will 'just add DVC'.


My 2 DVC-cents.

If the bounty is not yet sufficient, wait for the value per coin to make it sufficient or for our market cap due to sheer number more coins we have minted to make it feasible for us to offer a higher bounty?

Do we even have free open source 3D printers and laser-cutters yet?

If those are the tools you will be designing for maybe lets get those developed first?

-MarkM-

[Hunterbunter]

Some questions for the (armchair or otherwise) economists out there:

What is the intention behind used coins, when it comes to devcoins?

I should probably quantify what I mean by "used". It's those coins which people have purchased simply to inject cash into the devcoin system so developers can be paid - be they the devcoin admin team buying them from advertising revenue, or philanthropists which have more money than they know what to do with and wish to support open source development. They buy the earned coins off developers (giving them their pay), and then what? Is the intention for them to add them to wallets and leave them there forever?

What "use" are coins like these? A token to measure karma by before the gates of heaven?

Would it make sense to have a null pointer in the blockchain? a fixed address to which any coin sent to is destroyed forever? Or is the expectation that given enough time, those coins can come back in the form of development direction: the holder can direct productivity based on extra bounties for things they want to see done (that would actually make the most sense).

As I understand it, there is no destruction process so even if they are all put back on the market and crash the price to almost nothing for 2 months. Is this a possible way to temporarily hamstring progress on devtome (because no one wants to work if they think the coins are worth nothing)?

These people are different from speculators - people buying and holding hoping to sell for a profit, who ironically might be the buffer against this sort of attack.

[markm]

The "latest rates include file", http://galaxies.mygamesonline.org/latestrates.inc uses DeVCoin as the unit of measure, as indicated by the fact that DVC appears as being a value (rate) of 1.00000000 in that file.

This has led to DVC being used as a "unit of account", for example a lot of loans are denominated in DVC now.

General Financial Corp alone has accounts receivable denominated in DeVCoins totalling 341391108170.02256199 DVC as of the plots and tables timestamped Sat Dec 28 01:55:50 AST 2013.

GFC itself had outstanding DeVCoin-denominated debt totalling 287239801234.20907405 DVC as of that same timestamp set of reports tables and plots.

A whole heck of a lot more DeVCoin need to be minted before such figures could ever be paid off in lump sums using DeVCoin, thus necessitating conversion rates between DeVCoin and other means of settlement, hence the latestrates.inc file.

-MarkM-

[weisoq]

Thank you  
Today I take a look in the account_31.csv but I'am only located one time in the file for trying the new Sidjuhag client.
I saw no mention yet for the code report  
I wrote during round 31 two short articles on devtome. If the word count is < to 1000 can I see my word count ? If the answer is affirmative in which file of the website Charity ?

The count will show on this file http://d.evco.in/charity/devtome_31.csv
You're not there yet, which will just be because it takes a while to get your address added to the receiver list and for an initial check of your articles. The round doesn't end until about 10th Jan but let us know is you're still not added before then, although I'm sure you will.

[weisoq]

...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

UTB:

MIN_TX_FEE = MIN_RELAY_TX_FEE = 500,000,000 but in Twobits and Sidhujag values are
100,000,000 = COIN
Why ?

Twobits changed that without telling me. I didn't know because at the time we couldn't afford a code review. Now that blocks have been made with Twobit's lower transaction fee, the change must be kept and I will change the wiki documentation.

100,000,000 = 1.00000000. That's why the fee has been 1*coin to date. Is it not simple enough to maintain that?

Markm: Also fair point if that was the original intent, but if 1*coin has achieved it's aim of preventing spam is there any need to raise it? Surely the lower the better.

[sidhujag]

...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

UTB:

MIN_TX_FEE = MIN_RELAY_TX_FEE = 500,000,000 but in Twobits and Sidhujag values are
100,000,000 = COIN
Why ?

Twobits changed that without telling me. I didn't know because at the time we couldn't afford a code review. Now that blocks have been made with Twobit's lower transaction fee, the change must be kept and I will change the wiki documentation.

100,000,000 = 1.00000000. That's why the fee has been 1*coin to date. Is it not simple enough to maintain that?

Markm: Also fair point if that was the original intent, but if 1*coin has achieved it's aim of preventing spam is there any need to raise it? Surely the lower the better.

I think its 5*coin in the current client.. atleast the src ive been working with (link from devtome) was that. 1.0.8 isthe same now..

But for some reason when i send coins to vircurex (old client)
my transaction doesnt get accepted I think? Id like someone else to try or give me
their address while using old client so I cam try sending u coins.

see old dvc src mintxfee of 5*coin https://gitorious.org/devcoin/devcoin/source/4e23c180945785c49bbab682b7f6c6e1eda29b05:src/main.h