[DVC]DevCoin - Official Thread - Moderated

[weisoq]

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.

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

[Wekkel]

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.

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.

[weisoq]

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

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

[markm]

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-

[weisoq]

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-

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?

[markm]

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-

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?

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-

[weisoq]

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.

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

[markm]

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.

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

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-

[weisoq]

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-

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.

[markm]

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-

[weisoq]

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.

[tabnk]

How does devcoin work? 

[smeagol]

I downloaded one of the newer clients, none of my generation is showing up and it says "117 weeks behind."

Isit supposed to be like that?

[sidhujag]

I downloaded one of the newer clients, none of my generation is showing up and it says "117 weeks behind."

Isit supposed to be like that?

You had entire blockchain already? Check in the debug to see if you have any connections and that blocks are downloading...

[sidhujag]

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-

I dont think your code is theofficial one.. ive been looking at the one i pointed out last post and fees been set to 5 coins... if you go back to 1 coin wouldnt that be a fork? If any client is using 5coins would thy accept blocks wih lower fees? This is why I changed it
back to 5 coins in 1.0.8 and its really only an issue for low dvc amounts.. Once you send over a few thousamd dvc seems the fee is fine (1.5 dvc with 1 dvc per 1k tx size and 0.5 dvc per output). So question is do we have to roll with the lower denominator of 5 coins to prevent a fork?

Repos that have min fee 5 coins:

https://github.com/doublec/devcoin
https://github.com/knotwork/old-devcoind/tree/master/src
https://gitorious.org/devcoin/devcoin/source/4e23c180945785c49bbab682b7f6c6e1eda29b05:src

Where is the one using 5x less fees?

I will send that linux address coins see if they to through.. then after a merged mine block is found and we all see it on our old clients and new We are good..

[sidhujag]

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.

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.

Can you try sending from the NEW client ( 1.0.8 ) to your cryptostock or vircurex account? We are trying to see if new client can send coins to old clients.

[sidhujag]

Just sent Wekkel's old client (Linux) 1200 DVC from my new client 1.0.8 which I funded from my vircurex account. Let's see if it goes through. Notice that it was only 1 dvc fee to send even though minfee variable is 5*COINS.


see screenshot of my transaction to him here: http://sourceforge.net/projects/devcoin/files/wekkel.PNG/download

[weisoq]

How does devcoin work? 

http://devcoin.org/
http://devtome.com/doku.php?id=devcoin

[weisoq]

I dont think your code is theofficial one.. ive been looking at the one i pointed out last post and fees been set to 5 coins... if you go back to 1 coin wouldnt that be a fork? If any client is using 5coins would thy accept blocks wih lower fees? This is why I changed it
back to 5 coins in 1.0.8 and its really only an issue for low dvc amounts.. Once you send over a few thousamd dvc seems the fee is fine (1.5 dvc with 1 dvc per 1k tx size and 0.5 dvc per output). So question is do we have to roll with the lower denominator of 5 coins to prevent a fork?

Repos that have min fee 5 coins:

https://github.com/doublec/devcoin
https://github.com/knotwork/old-devcoind/tree/master/src
https://gitorious.org/devcoin/devcoin/source/4e23c180945785c49bbab682b7f6c6e1eda29b05:src

Where is the one using 5x less fees?

I will send that linux address coins see if they to through.. then after a merged mine block is found and we all see it on our old clients and new We are good..

Thought UTB had now changed it back to 1*coin - http://devtome.com/doku.php?id=devcoin#generation_rate
I'm a bit lost now as to what's being changed, so leave you to it.

[Wekkel]

Sent 1,000 DVC from 1.0.8 Windows client to Vircurex. Not shown in the block explorer yet.

Sent 94 DVC (triggered 6 DVC payment fee) to my (older) Linux wallet. Not shown in the block explorer yet.

No sign yet of your 1,000 into here (my Linux wallet).

It seems we both cannot get the 1.0.8 client to register payments into the network.