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

Maybe that could be addressed by just setting up a system where individuals or groups can pool funds separately from 'official' devcoin bounties. So those who want a devcoin atm (I'm also not that interested yet - getting a uk crypto-£ exchange would be a first step, reckon there's zero chance an atm would be permitted here) can get together and enable it in whatever way they think would be most effective. That would provide unlimited avenues for direct investment without getting into controversy over formal bounties. Perhaps even a method where if x% of estimated total required is raised by individuals it can move towards general bounties. i.e. there's nothing stopping anyone using their dvc to fund whatever they'd like to see, and I think that could develop over time.

Whatever is in my github repo is what I have been using all along.

As far as I know whatever mmpool has been using is based on that or mine is based on his, from way back when.

No idea what other pools might have used.

-MarkM-

Unless I'm missing something, there was never an actual change to 5*coin as in UTB's listed technical changes (twobits didn't change it). It's been 1*coin the whole time. The discussion of the new version is whether to incorporate the original intention of 5*coin in the new code, in the context of discovering it was never implemented in the first place. So I think 'time' means everything from devcoin's creation to now. Edit: actually it would be from twobit's changes, whenever that was, to now.

Time? But there has not been any time has there? We are still discussing deploying the new version. If some minority of nodes has been running it from time to time like these two people who ran it to try to send each other coins have they even actually generated any blocks with it?

Or is the fact that the blockchain wasn't broken yet simply due to their low hash power that happened to cause no blocks to even be in the chain yet that they created?

Is there a list anywhere of blocks that could only have been generated by a node that has this change in it?

Maybe they have tried to form such blocks but the network has consistently rejected them thus they did not make it into the blockchain?

Have any of the merged mining pools used the new code yet?

My private p2pool certainly hasn't.

There no non merged mined devcoin pools are there?

Has any solo miner used it long enough to actually find a block yet?

(How many months does that take?)

-MarkM-

I'm assuming that time was the test, and that UTB being willing to leave it where it is at 1*coin means it serves its purpose. That's me implying, I don't know if it's correct.

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 ?