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

Who tested the spam-proofing?

I do not recall even hearing about any attempts at spamming, nor any analysis of how much it would cost to achieve how much of what kind of effect by spamming.

Maybe spammers have been holding off a while antic
ipating it becoming five times cheaper to spam so are waiting until more than 50% of the network is ready to let them spam cheaply?

Devcoin is not really up a lot in price compared to bitcoin, so as long as we simply use 1000 (or maybe nowadays 2000 would be better now we mint 2000 times as many coins as bitcoin) we should continue to inherit bitcoins' analysis and calculation of how much the various aspects of fee ought best be set to.

Maybe more than 2000 even since really a value of only 1/200 that of bitcoin is a max not a likelihood.

This is why I have always figured we'd just be doing the same usually changes to bitcoin code that we did originally: multiple all their span fix figures by a multiplier intended to reflect jow much less than a bitcoin we expect a devcoin to be worth.

Presumably we'd also inherit their expert analysis of which changes are forking ones that need to come into effect at a certain block number, as we'd see that when they changed their fee they did or did not do it as a change set to come into effect at a certain block.

So basically they'd continue to do most of the work for us.

-MarkM-

You know more about this than me, but if few even noticed and the intention of spam-proofing was still achieved why raise it now?

I don't think we should just arbitrarily keep a typo that so far hasn't happened to fork the chain if it is indeed a forking change.

If it is for sure that no old client will fork upon seeing a free the typo puts into the blockchain then it is not a forking change so is not important.

Any forking change though should be scheduled for some far-future block then we start warning people over the year or two it will take to come into effect that some time in those coming blocks they will need to get around to updating their clients/daemons.

-MarkM-

cyke's code report and UTB's msg implied 1*coin was actually in the code (even though 5*coin was the original intent) and that explains why most transactions were of 1 dvc fee. So I was just pointing out that if it that worked to prevent spam why change it (UTB seemed to think the lower 1*coin fee should now be maintained, markm didn't).

This is my Linux client: 1NtbgQ61TH579orJQEpAZ4zGvgyzLX4L39

I had some payments disappear in the black hole as well. Those were payments from the Linux client to Cryptostocks.com. One went through some hours after the payment, the other after some days. The client showed the payment but the online block explorers did not state a payment having been made.

In the end, things were settled over time.

I think there were different views, but all came down to price risk. For example, the bitcoin grant you referred to - I assume that's a grant in bitcoins? So really what we're saying is that the problem amounts to liquidity and absolute price not necessarily devcoin, as it's not that long ago that paying btc would have raised the same issues. My personal view is that making an atm (for any coin) would probably pay for itself on roll-out through price change, but that's a personal assessment to make by those with the technical skills to achieve it.

I fully appreciate it's very hard, so maybe a few steps are required with devcoin before an atm is necessary - making it work would need regular fiat filling - so again that's a bit of a chicken and egg situation with regards to liquidity and stability (or even speculation) where I'm not sure there's much value in transient price spikes on fantastic news of an atm only for a lack of support to maintain them until the user base is there? Also, I think the kind of project you're talking about is certainly one DVC would support - but obviously you must realise that providing any greater 'assurance' to your return must demand doing the opposite for others. It would be quite difficult at this point to necessarily prioritise say an open-source ATM vs simple to use Open Transactions platform vs other etc.

Some bounties have been funded directly by users putting DVC up - e.g. updating the client, a dvc video. Perhaps if a natural point's reached where a devcoin ATM is demanded by the user base it could be funded that way

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

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

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.

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-

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.

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-

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-

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.

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 ?

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.