Topic: Devcoin(DVC) Source Code Updated to Bitcoin 0.8.x - page 3. (Read 5377 times)

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?

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-

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

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

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-

Created a cross platform java installer

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.

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-

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.

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

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.

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():

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:


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

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.

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 .

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-

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-

Fixed points 2 and 3 in 1.0.1, thanks.

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.

Ok I uploaded 1.0.1 for the qt binary you can try it again. I don't know if it will throw up a message saying you don't have enough or whatever but as long as the fee's are "right" I think its good for now.

Thanks,
Jag

Just about the test wekkel, not the dvc. It should have said something like 'you don't have the funds, change the send amount'. Let me know when you have the newest update and I'll try sending again.