Devcoin(DVC) Source Code Updated to Bitcoin 0.8.x

[markm]

For point 1 we will have a bounty of I think 8 shares for the new qt images and 4 shares for second best... the images we need are in the  original post of this thread.

That seems insanely high, since we already have logo images so all that is needed is to re-size our official logo (whichever one was picked, we already paid bounties to get the logos in the first place didn't we?) to the correct sizes needed for this particular case of actually using the already paid for logo.

Its a one line command fergoshsakes, "for size in sizeone, sizetwo, sizethree do resize logo".

-MarkM-

[1714864353]

1714864353

[sidhujag]

For point 1 we will have a bounty of I think 8 shares for the new qt images and 4 shares for second best... the images we need are in the  original post of this thread.

That seems insanely high, since we already have logo images so all that is needed is to re-size our official logo (whichever one was picked, we already paid bounties to get the logos in the first place didn't we?) to the correct sizes needed for this particular case of actually using the already paid for logo.

Its a one line command fergoshsakes, "for size in sizeone, sizetwo, sizethree do resize logo".

-MarkM-

I think the splash images are different as well as the testnet ones.. Maybe not 8 shares since the logo can be resized and its little work. Your right. I propose 4 shares for all of the images. LightLord did i0coin so if noone takes this up in a timely manor  I can ask him .

[emfox]

Does your src exactly based on bitcoin 0.8.5 ? I see some files missing, e.g. src/leveldb/Makefile is in bitcoin 0.8.5, but not in your devcoin source, and that prevent me from build on linux.

Edit: after add src/leveldb/Makefile from original bitcoin 0.8.5, and add line '-l curl' in LIBS in makefile.unix, I could build devcoind properly on my debian box.

I suggest change the captical D to d, 'cause it not so normal that we use $HOME/.Devcoin and Devcoin.conf file.

Taken from i0coin which was based on btc 0.8.5... I can add that makefile I will get it from 0.8.5 thanks...

Once you can build please share the makefile so I can update it. We are still testing so the official binaries will come after we are done testing. But can I rely on you to make the linux builds? Can you do 64 and 32 bit?

About the lowercase 'd' thing... fixed in 1.0.1, can you retest for this?

Thanks
Jag

I'm the official linux Administrator of devcoin, so you could rely on me. currently I've done the 32bit build, and if everything ok, I'll set up my 64bit virtual machine to do the 64bit ones.

please also update the git source, adding src/leveldb/Makefile(does not need any change), and add line '-l curl' in src/makefile.unix.

[sidhujag]

The main purpose of fees is to discourage spamming.

Devcoin creates (more than) 1000 times as many coins per block as bitcoin so fees were set as a thousand times higher than bitcoin's fees back when we created Devcoin.

The idea was that Devcoins would be worth 1/1000 (at best, and actually now that bitcoin makes only 25 coins not 50, presumably more like 1/2000) of what bitcoins are worth, so that however many bitcoins of fee it would take to discourage spammers it would presumably take 1000 (nowadays maybe more like at least 2000) times as much fee to accomplish the same amount of discouragement in Devcoin.

So maybe while you are at it you should update our old "fees 1000 times as much as bitcoin's fees" to be at least 2000 times as much.

Which would be a hard fork, so should be set to come into effect at some particular block number.

Plus we can predict ahead too, we know in how many years bitcoin will again halve its number of coins per block, so maybe we could plan ahead to have our fees jump yet again at those times. Though when those times actually come bitcoin will maybe have changed its fees so come the day we'd want to look at bitcoin's fees and do our multiply accordingly then when updating devcoin again then.

-MarkM-

I think there was a fee structure change in 0.8.6 so we might need to rethink the fee stuff now. Gaven did to a push to change the fee stuff I remember. Not sure if it affects us... so should we double our min fees? right now minfee is 5 coins (int64 CTransaction::nMinTxFee = 5*COIN) and the 0.5 fee comes from getminfee():

Code:

    // DEVCOIN: To limit dust spam, require an additional one tenth of CTransaction::nMinTxFee/CTransaction::nMinRelayTxFee for each output
    BOOST_FOREACH(const CTxOut& txout, vout)
         nMinFee += nBaseFee / 10;

Which basically takes 5*Coin / 10 = 0.5 coins fees...

The code was setting nBaseFee to 0 for tx under 27000 coins, which I commented out so now fees for all transactions will be based on the size of the transaction:

Code:

    // Base fee is either nMinTxFee or nMinRelayTxFee
    int64 nBaseFee = (mode == GMF_RELAY) ? nMinRelayTxFee : nMinTxFee;

    unsigned int nBytes = ::GetSerializeSize(*this, SER_NETWORK, PROTOCOL_VERSION);
    unsigned int nNewBlockSize = nBlockSize + nBytes;
    int64 nMinFee = (1 + (int64)nBytes / 1000) * nBaseFee;

This is the same code its always been, just that I commented out the code that comes right after this which sets fee back to 0 if transactions are small (allow free for small transactions).

[sidhujag]

Does your src exactly based on bitcoin 0.8.5 ? I see some files missing, e.g. src/leveldb/Makefile is in bitcoin 0.8.5, but not in your devcoin source, and that prevent me from build on linux.

Edit: after add src/leveldb/Makefile from original bitcoin 0.8.5, and add line '-l curl' in LIBS in makefile.unix, I could build devcoind properly on my debian box.

I suggest change the captical D to d, 'cause it not so normal that we use $HOME/.Devcoin and Devcoin.conf file.

Taken from i0coin which was based on btc 0.8.5... I can add that makefile I will get it from 0.8.5 thanks...

Once you can build please share the makefile so I can update it. We are still testing so the official binaries will come after we are done testing. But can I rely on you to make the linux builds? Can you do 64 and 32 bit?

About the lowercase 'd' thing... fixed in 1.0.1, can you retest for this?

Thanks
Jag

I'm the official linux Administrator of devcoin, so you could rely on me. currently I've done the 32bit build, and if everything ok, I'll set up my 64bit virtual machine to do the 64bit ones.

please also update the git source, adding src/leveldb/Makefile(does not need any change), and add line '-l curl' in src/makefile.unix.

The change is not so simply to the unix file. Have a look at

https://github.com/sidhujag/devcoin/commit/36d595726636255a55c62780a671386c0cc7c505

I had to make multiple changes, give it a whirl and see if it compiles.

I added the makefile's too, for some reason gitignore had makefile in there but I took it out and then it added all of them, there were tons from libcurl aswell.

[sidhujag]

The main purpose of fees is to discourage spamming.

Devcoin creates (more than) 1000 times as many coins per block as bitcoin so fees were set as a thousand times higher than bitcoin's fees back when we created Devcoin.

The idea was that Devcoins would be worth 1/1000 (at best, and actually now that bitcoin makes only 25 coins not 50, presumably more like 1/2000) of what bitcoins are worth, so that however many bitcoins of fee it would take to discourage spammers it would presumably take 1000 (nowadays maybe more like at least 2000) times as much fee to accomplish the same amount of discouragement in Devcoin.

So maybe while you are at it you should update our old "fees 1000 times as much as bitcoin's fees" to be at least 2000 times as much.

Which would be a hard fork, so should be set to come into effect at some particular block number.

Plus we can predict ahead too, we know in how many years bitcoin will again halve its number of coins per block, so maybe we could plan ahead to have our fees jump yet again at those times. Though when those times actually come bitcoin will maybe have changed its fees so come the day we'd want to look at bitcoin's fees and do our multiply accordingly then when updating devcoin again then.

-MarkM-

While we are on that topic the initial inflationary goal was tobe 1000x inflationary than bitcoin as really I
thought the goal was for price to stabalize at 0.001btc?

So if fees are maintaining the ratio maybe the generation rate should also be affected? At btc 1 we would stop and make 1000 dvc per block the minimum.. idk makes sense based on initial goals to be 1000x btc

[sidhujag]

v1.0.2 available check OP to download from github, reminder you have to view zip file raw because github really isn't a file repository.. we are just using it temp for our testing.

[markm]

Devcoin continues minting coins forever partly because receivers need to be receiving coins forever.

Changing the fee structure probably requires checking the block number, so that existing blocks do not suddenly look like they had too little in the way of fees?

So you maybe cannot simply change fees boom just by changing the numbers in the code, you also likely have to keep those old nubmers in there for when the validity of old blocks is being checked, and have any change in fees take effect as of some specific future block.

Unless you are absolutely sure that your new fee values/code does in fact still find all already-existing blocks and all blocks people who continue to user old code to be be valid, of course. But you'd better be very sure of that, because some people are likely to keep on using old clients for years thus to continue sending fees as dictated by the old code not by the new code...

-MarkM-

[sidhujag]

Devcoin continues minting coins forever partly because receivers need to be receiving coins forever.

Changing the fee structure probably requires checking the block number, so that existing blocks do not suddenly look like they had too little in the way of fees?

So you maybe cannot simply change fees boom just by changing the numbers in the code, you also likely have to keep those old nubmers in there for when the validity of old blocks is being checked, and have any change in fees take effect as of some specific future block.

Unless you are absolutely sure that your new fee values/code does in fact still find all already-existing blocks and all blocks people who continue to user old code to be be valid, of course. But you'd better be very sure of that, because some people are likely to keep on using old clients for years thus to continue sending fees as dictated by the old code not by the new code...

-MarkM-

This was done via getminfee() @ block 10700 so I was forced to test it anyway.. I downloaded entire blockchain using the new daemon for my tests. When I didnt check the daemon stopped downloading at block 10700.. so now we would change the numbers again at block x in the future.

On minting forver i already agree to that I just said to reduce to keep the ratio consistent up until say 1 btc per
block at which point ratio widens from then on.

[sidhujag]

Created a cross platform java installer

[markm]

If screwing everyone over by pulling the rug out from under the most basic definitions of a coin, the how many coins there will be and the how many there will be per block is absolutely necessary, go ahead and have bitcoin not halve its minting, that will fix the ratio and it will do so without turning devcoin into fraud / false advertising / scam / bait-and switch.

Let the other chain be the fraud not this one, okay?

-MarkM-

[sidhujag]

If screwing everyone over by pulling the rug out from under the most basic definitions of a coin, the how many coins there will be and the how many there will be per block is absolutely necessary, go ahead and have bitcoin not halve its minting, that will fix the ratio and it will do so without turning devcoin into fraud / false advertising / scam / bait-and switch.

Let the other chain be the fraud not this one, okay?

-MarkM-

I didnt say i was changine it.. but maybe thats what a vote can be used for? I thought its a perfect chance to use it. Sometimes in hindsight it makes sense to make the changes if its beneficial.. others in the space are tending towards that direction there had to be some truth to te argument hence why I brought it up in first place.

[markm]

Back when GRouPcoin and DeVCoin were created, the forums were full of people screaming and shouting that bitcoin is doomed, it is a flawed model, deflation is deadly, a currency absolutely has to continue being printed, and on and on like that.

So GRouPcoin and DeVCoin were deliberately created to just keep churning out coins, to basically prove that those people were so full of shit that they would not support a non-delfationary coin themselves. Sure enough, none of them jumped onto these coins that we made for them as far as I know.

DeVCoin though has an actual reason for doing things the way that it does. It deliberately is doing it, there is no error or mistake, if you don't like coins that keep minting then please just go away and play with some coin that is deflationary or something.

Your voting idea is a big problem with democracy. "We have decided to violate all our contracts and thereby screw everyone, ha ha tough luck everyone who believed our promises, we had another election and decided to break all the contracts we made last election. You can always depend on the masses to vote for bread and circuses even the Romans knew that what are you stupid or something, what a sucker ha ha maybe we should spawn a bunch new contracts to break and screw you all all over again you suckers..."

Go play with Novacoin they are into doing that kind of crap.

Oh Solidcoin too, you are right scamming is popular isn't it?

-MarkM-

[sidhujag]

Back when GRouPcoin and DeVCoin were created, the forums were full of people screaming and shouting that bitcoin is doomed, it is a flawed model, deflation is deadly, a currency absolutely has to continue being printed, and on and on like that.

So GRouPcoin and DeVCoin were deliberately created to just keep churning out coins, to basically prove that those people were so full of shit that they would not support a non-delfationary coin themselves. Sure enough, none of them jumped onto these coins that we made for them as far as I know.

DeVCoin though has an actual reason for doing things the way that it does. It deliberately is doing it, there is no error or mistake, if you don't like coins that keep minting then please just go away and play with some coin that is deflationary or something.

Your voting idea is a big problem with democracy. "We have decided to violate all our contracts and thereby screw everyone, ha ha tough luck everyone who believed our promises, we had another election and decided to break all the contracts we made last election. You can always depend on the masses to vote for bread and circuses even the Romans knew that what are you stupid or something, what a sucker ha ha maybe we should spawn a bunch new contracts to break and screw you all all over again you suckers..."

Go play with Novacoin they are into doing that kind of crap.

Oh Solidcoin too, you are right scamming is popular isn't it?

-MarkM-

I totally get the history and I get the need for always minting but I just said to reduce it to stick to the ratio for as long as possible so the avg rate of dvc would be 1 mbtc setting it for an advantage when the mbtc switch happens with btc later on. Nothing changes except scarcity going fwd... thequestion lies would 1000 dvc per block be granular enough long term. at this rate we are tending towards 0 btc and hard to gain acceptance with a price preceding 7 zero's

[markm]

All that is happening is that we have not yet built up enough "depth" at the bottom of the buy side of the order book(s) to accomodate more than 200 million coins being dumped per month.

It should not take long to reach a point where we can put in a buy order for a billion or so coins at one satoshi each every month to accomodate people who want to dump, and eventually to have a buy order at one satoshi per coin that is big enough to buy each and every devcoin that exists.

At that point even if everyone tried to dump all their devcoins they would be able to, and the folks sitting earning interest on their bitcoins on Vircurex with those bitcoins parked in such buy orders will be laughing all the way back up to 350+ satoshis per coin and it will be trivial to buy up the new 200 million being minted each month, even maybe to give the dumpers a break by offering two satoshis each for them.

Then each cycle, as we have already been seeing, of down to however low the dumpers are willing to go, or feel forced by starvation etc to go, and back up to whatever price buyers are willing to pay for reasonable quantities, the dumpers can dump while the rest of us buy up all the cheap coins, then those who prefer a nicer price for their coins can sit them up over 200 satoshis or over 350 or wherever ready to get sold the next time a buyer comes along who wants more than the few billion that get minted per year or even just more than the few hundred million that get minted in the course of a few months.

How many devcoins worth of buy offers do you have sitting at 1 to 30 or so satoshis waiting for dirt cheap coins from dumpers? The more buy offers there are down there, and the higher the huge stack of such offers climbs, the harder it will be for dumpers who are only dumping a few months minting worth of coins to drive the price down into that pile.

Mostly it is maybe just a matter of gaining trust in Vircurex, trust that by the time they run off with all your bitcoins that are sitting there on the buy side earning interest all those coins will be just part of your profits so you'll still be ahead even if they do run off with them.

-MarkM-

[smeagol]

I think the splash images are different as well as the testnet ones.. Maybe not 8 shares since the logo can be resized and its little work. Your right. I propose 4 shares for all of the images. LightLord did i0coin so if noone takes this up in a timely manor  I can ask him .

4 shares for a new set of qt images and icons (like send, receive, etc.) and 2 for the next-best set.  This will be voted on by randomly selected admins.

Any objections?

[sidhujag]

All that is happening is that we have not yet built up enough "depth" at the bottom of the buy side of the order book(s) to accomodate more than 200 million coins being dumped per month.

It should not take long to reach a point where we can put in a buy order for a billion or so coins at one satoshi each every month to accomodate people who want to dump, and eventually to have a buy order at one satoshi per coin that is big enough to buy each and every devcoin that exists.

At that point even if everyone tried to dump all their devcoins they would be able to, and the folks sitting earning interest on their bitcoins on Vircurex with those bitcoins parked in such buy orders will be laughing all the way back up to 350+ satoshis per coin and it will be trivial to buy up the new 200 million being minted each month, even maybe to give the dumpers a break by offering two satoshis each for them.

Then each cycle, as we have already been seeing, of down to however low the dumpers are willing to go, or feel forced by starvation etc to go, and back up to whatever price buyers are willing to pay for reasonable quantities, the dumpers can dump while the rest of us buy up all the cheap coins, then those who prefer a nicer price for their coins can sit them up over 200 satoshis or over 350 or wherever ready to get sold the next time a buyer comes along who wants more than the few billion that get minted per year or even just more than the few hundred million that get minted in the course of a few months.

How many devcoins worth of buy offers do you have sitting at 1 to 30 or so satoshis waiting for dirt cheap coins from dumpers? The more buy offers there are down there, and the higher the huge stack of such offers climbs, the harder it will be for dumpers who are only dumping a few months minting worth of coins to drive the price down into that pile.

Mostly it is maybe just a matter of gaining trust in Vircurex, trust that by the time they run off with all your bitcoins that are sitting there on the buy side earning interest all those coins will be just part of your profits so you'll still be ahead even if they do run off with them.

-MarkM-

Every time the block reward halves the ratio widens and pushes price down further. This means the price is tending towards 0 btc but not necessarily usd. So the case where dvc may stabalize in price is if/when bitcoiners switch to devcoin (not likely) and that is the case where devcoin has long term prospects unless the model is followed to allow a constant ratio until supply is saturated which I eluded to earlier, not sure if you got that. Supply will be saturated and we will still have an infinite generation rate.. just alot less, and at that point I would argue that people would switch to devcoin just because it offers more than a simple deflationary spiral.

[markm]

Well if other things tend toward cheaper and cheaper too, which they ought to in relation to bitcoin if bitcoin deflates as it is hoped/expected to, devcoin will be a lot more useful than bitcoin for buying cheap things since it gives much more granularity then just "one satoshi each, two satoshis each etc".

Albeit scale helps with that kind of thing too in Open Transactions. Cheap things can be offered on large scale markets, so for example instead of having people offer a number of bitcoins for one of something, cheap somethings could choose to use a million at a time scale market or a hundred thousand at a time scale market in which people bid bitcoins for whole millions or whole hundred thousands of the cheap thing.

(Bear in mind that all assets, not just shares and deeds but also currencies, on my server are integers, so when you bid in bitcoins for something you bid in whole bitcoins for whole somethings... Probably resulting in bitcoiners preferring to offer their bitcoins for sale for cheaper things to bid for them rather than to bid bitcoins on a market where the something else is the thing for sale and the bitcoins are the thing in which bids are being taken.)

-MarkM-

[sidhujag]

Hey guys 1.0.3 is built and ready. I enabled QR payments in this one, so we need a mobile wallet to allow QR payments to take place... which really is a cool idea if we want traction in the vendor space.

[sidhujag]

Well if other things tend toward cheaper and cheaper too, which they ought to in relation to bitcoin if bitcoin deflates as it is hoped/expected to, devcoin will be a lot more useful than bitcoin for buying cheap things since it gives much more granularity then just "one satoshi each, two satoshis each etc".

Albeit scale helps with that kind of thing too in Open Transactions. Cheap things can be offered on large scale markets, so for example instead of having people offer a number of bitcoins for one of something, cheap somethings could choose to use a million at a time scale market or a hundred thousand at a time scale market in which people bid bitcoins for whole millions or whole hundred thousands of the cheap thing.

(Bear in mind that all assets, not just shares and deeds but also currencies, on my server are integers, so when you bid in bitcoins for something you bid in whole bitcoins for whole somethings... Probably resulting in bitcoiners preferring to offer their bitcoins for sale for cheaper things to bid for them rather than to bid bitcoins on a market where the something else is the thing for sale and the bitcoins are the thing in which bids are being taken.)

-MarkM-

This is why I like the ratio of 1000:1 so we can talk about mBTC instead of satoshi's and it would appeal to a larger audience and not just the devcoin community who deals with 6 or 7 trailing zero pricing. I like the idea that you can get more, and the idea that mBTC would be the target price, however letting it tend to zero means you can't really use anything other than a satoshi, and that in itself is a problem with widespread adaption, continue to think it is worthless in the face of even great developments. Maybe in a hundred years when the ratio of new minted coins is negligible on the entire supply will it make sense for investors to put serious money into helping open source development, however as an investor today that really is like throwing money away and so the catch 22 rolls on. (Which investor wants to wait 100 years today for an investment to mature enough to consider it a success?)

If you do the math it would take 100 years before you reach < 1% inflation p.a.

Since we are early adopters changing it now wouldn't be considered a scam because in the long run it works to achieve a certain goal. I outlined the goal already but if the goals are different then I would like to know simply how what I said isn't better in the long run. That is I already agree to an infinite minting we are really talking about scale here only. The project description doesn't change.