Devcoin

[markm]

With so little hashing-power bitcoins, namecoins and devcoins would be lotteries, over the months you will from time to time find a block but if you set up p2pool for bitcoins you will get tiny fractions of a bitcoin regularly, and p2pool supports merged-mining so alongside the bitcoins you can merged-mine namecoins, devcoins, ixcoins, i0coins, groupcoins and coiledcoins. YOu might find a namecoin block every several months or maybe one a year or couple some years or something, from time to time you will happen across a devcoin block, ixcoin blocks you will find more often, but i0coins, groupcoins and coiledcoin you will keep raking in all the time. Currently coiledcoins a little slower than groupcoins and i0coins but I suspect that is because coiledcoin got stuck at a high difficulty when many miners abandoned it and it has been taking a long time for its difficulty to drop down to match the current low amount of miners that are working on it.

Basically 200 MHash is tiny so you need the coins like groupcoins, i0coins and coiledcoins that the "big boys" consider to be beneath their notice, but p2pool can let you get a trickle of fractions of a bitcoin while you do that.

It would maybe be nice for p2pool to be patched so that it can use devcoins as primary chain, so people could use it to get a steady trickle of devcoins while merged mining other chains instead of devcoins having to be one of the merged chains, since variance is massive on merged chains that are difficult as compared to your hashrate. (You get a whole block every once in a possibly long while instead of a steady trickle of fractions of block-reward all the time.)

-MarkM-

[1713400295]

1713400295

[1713400295]

1713400295

[1713400295]

1713400295

[1713400295]

1713400295

[rob1313]

thanks markm. i had trouble finding much info on dev coins

[dust]

Is http://sourceforge.net/projects/galacticmilieu/files/ the latest official source?

[markm]

Is http://sourceforge.net/projects/galacticmilieu/files/ the latest official source?

Technically I think it is out of date by one github patch, someone submitted a pull request on github to turn off the compiling in of the mini plug and play library because the version of plug and play this old code uses is much older than the one more-recent bitcoin-derived code uses so most people if they have the plug and play lib installed at all probably have the newer version that uses a different syntax (different number of arguments in a function call).

I don't think I bothered to make a new package for sourceforge for just that tiny change, since in any case anyone not wanting to compile in the lib would just put USE_UPNP= on the make invocation line instead of USE_UPNP=0 or USE_UPNP=1

Basically the change was to make it default to empty string instead of the 0 or 1 it used to default to.

The github repos are

https://github.com/knotwork/old-devcoind

and

https://github.com/knotwork/old-devcoin-qt

-MarkM-

[dust]

The github repos are

https://github.com/knotwork/old-devcoind

and

https://github.com/knotwork/old-devcoin-qt

-MarkM-

Thanks.  The "old" in the repo name threw me off.

[markm]

Yeah the plan was to make new ones based on more-recent bitcoin code, just didn't get to that yet. Once 0.8 is stable, maybe.

-MarkM-

[Icoin]

Yeah the plan was to make new ones based on more-recent bitcoin code, just didn't get to that yet. Once 0.8 is stable, maybe.

please check: DVC Block 75878
http://devda.ch:2750/chain/Devcoin?count=1&hi=75878
Will it be possble to confirm this block with version 0.8?

[markm]

Yeah the plan was to make new ones based on more-recent bitcoin code, just didn't get to that yet. Once 0.8 is stable, maybe.

please check: DVC Block 75878
http://devda.ch:2750/chain/Devcoin?count=1&hi=75878
Will it be possble to confirm this block with version 0.8?

What are we supposed to be looking for in that block?

Presumably there is something about it that causes you to wonder; what exactly is it about that you are wondering about?

What exactly is it about 0.8 that you thing might not like this block?

-MarkM-

[Icoin]

What are we supposed to be looking for in that block?

Value Out:        35 110 016 DVC
Date:                2013-01-31 00:15:30
Confirmations: 0

I just wanna know if the 35 Mio will ever arrive.

[markm]

Oh, it is not actually a transaction that is in the blockchain? (Zero confirmations?)

I thought you were talking about a block that is in the blockchain, thus one that presumably has more and more confirmations all the time.

And it has no fee? Or does it have fee?

-MarkM-

[Icoin]

Oh, it is not actually a transaction that is in the blockchain? (Zero confirmations?)

I thought you were talking about a block that is in the blockchain, thus one that presumably has more and more confirmations all the time.

And it has no fee? Or does it have fee?

-MarkM-

Mark this is no question about fee or no fee, its 35 Mio means incoherent to the whole 21 Mio policy of bitcoin. The transaction is writen to the chain, as you can see in the Blockexplorer, http://devda.ch:2750/chain/Devcoin?count=1&hi=75878 But the block never was confirmed by anyone till today.
According to me this is a serious Devcoin Bug, and with the present version of Devcoin it never can be solved! Lets assume DVC continue to grow, sooner or later it will be normal that a block becomes bigger than 21 Mio DVC. Every time this happens, the block doesnt get confirmed.

[markm]

Hmm I am pretty sure we tried to increase a bunch of the "highest number of coins" constants when we created DeVCoin, but, I think that there is one that  limited by the fact that the number of "devtoshis" is a 64-bit integer. So the for-real limit caused by using 64-bit integers should be maxint64 divided by one hundred million.

Thus I think we ended up trying to limit the number of coins at any one spot in the binary representation to the inherited 21-million number. I cannot recall if that meant no more than 21 million at any one address or no more than 21 million as any one input or output.

I think actually it might have been, no more than 21 million in any one calculation, so whenever adding them up or multiplying them etc the result must always be within the limit.

Arguably 21 million might not be quite the very largest number of whole coins a 64 bit signed integer can represent, I don't recall ever thinking too hard about that, maybe just figuring Satoshi likely already had and had thus tuned the total minted coins in the original bitcoin to be a number of Satoshis that int64 can handle.

-MarkM-

[Icoin]

Hmm I am pretty sure we tried to increase a bunch of the "highest number of coins" constants when we created DeVCoin, but, I think that there is one that  limited by the fact that the number of "devtoshis" is a 64-bit integer. So the for-real limit caused by using 64-bit integers should be maxint64 divided by one hundred million.

Thus I think we ended up trying to limit the number of coins at any one spot in the binary representation to the inherited 21-million number. I cannot recall if that meant no more than 21 million at any one address or no more than 21 million as any one input or output.

I think actually it might have been, no more than 21 million in any one calculation, so whenever adding them up or multiplying them etc the result must always be within the limit.

Arguably 21 million might not be quite the very largest number of whole coins a 64 bit signed integer can represent, I don't recall ever thinking too hard about that, maybe just figuring Satoshi likely already had and had thus tuned the total minted coins in the original bitcoin to be a number of Satoshis that int64 can handle.

-MarkM-

What brings us back to the initial question, will it be possible to confirm this block or are this 35 Mio DVC lost in the Devcoin Abbyss?

[markm]

What brings us back to the initial question, will it be possible to confirm this block or are this 35 Mio DVC lost in the Devcoin Abbyss?

I don't know, but I don't think bitcoin 0,8's code will fix it, as the limits constants inherited from bitcoin aren't any different from one version of bitcoin to another.

So if we can fix it, we can do so right away, with a fix to the current old-bitcoin-code based DeVCoin; no need to wait for some day when we get around to making a version of DeVCoin that is based on the 0.8 bitcoin code.

Basicically if we can figure out what number where in the code is preventing it from being processed into a block, we will then be able to check whether preventing it getting into a block is necessary; if it is in fact necessary we should fix the user interface (the RPC calls for sending coins, and whatever the GUI code to do it is in the GUI version) to prevent users from being able to do such transfers in the first place, so that they never get sent to the block building system in the first place.

I suspect the problem, at root, is that users are being allowed to [try to] send more than 21,000,000 coins at once.

Possibly we can also adjust the actual limit constant definition, which is probably currently set to 21,000,000 coins, to (maxint64/100000000) too, if that is so much larger than 21M that such a change is worth stepping away from the number 21M that coiners already have genetically coded into their expectations of maximum number of coins of a bitcoin-based / bitcoin-derived coin system.

-MarkM-

EDIT: As to actually losing the coins, probably if you double-spend them, that is, send them in batches of less than 21 million somewhere else, your new transactions might get into the chain, making the old one obsolete, leading to it being dropped from the memory pool. If that doesn't work without a fee, maybe adding a fee too could help if the block building code actually does prioritise transactions that have fees over ones that have lower fees or no fees. Whether clients tend to allow one to easily attempt such re-sends aka double-spends I do not know.

(That might be where newer bitcoin code might come in: maybe the old code we used does not have coin-control and does not have a raw transactions RPC call.)

[Icoin]

probably if you double-spend them

Yes, i agree that could be the solution by now for the 35M when i would be the sender. But how do you wanna prevent that all transactions worldwide become greater than the 21M Block limit? Means when i send 11M DVC then i have to hope that noone else sends 11M DVC in the same block?

[markm]

probably if you double-spend them

Yes, i agree that could be the solution by now for the 35M when i would be the sender. But how do you wanna prevent that all transactions worldwide become greater than the 21M Block limit? Means when i send 11M DVC then i have to hope that noone else sends 11M DVC in the same block?

We need to go over the user-interface again, making sure it rejects any attempt by the user to send more than max number (currently probably 21M) coins at a time.

It might even turn out that it is the GUI that is allowing it not the deamon, as I know nithing about wxwidgets nor QT widgets and input/output forms/templates and so on thus I'd think myself far more likely to have missed a spot in the GUI code than in the daemon. But maybe not, maybe both don't check user inputs against the max and reject ones that are too large.

I also wonder what will happen when a user interface tries to tell aq user the total balance of a wallet or account if that wallet or account contains lots of addresses that each have the full 21M coins in them. I don't even know if doubles (double precision reals) are used for such displays and the addition that leads to them or if int64 is used there, a timebomb waiting to overflow the integer. I vaguely recall or have an impression that I had a cursory glance at it but I think I basically took it on faith from Unthinkingbit that it is the total per transaction/address that needs to be limited, the grand total of all coins in existence of in a wallet or account or whatever not being limited to using int64., Not sure though at this late date.

-MarkM-

[K1773R]

probably if you double-spend them

Yes, i agree that could be the solution by now for the 35M when i would be the sender. But how do you wanna prevent that all transactions worldwide become greater than the 21M Block limit? Means when i send 11M DVC then i have to hope that noone else sends 11M DVC in the same block?

We need to go over the user-interface again, making sure it rejects any attempt by the user to send more than max number (currently probably 21M) coins at a time.

It might even turn out that it is the GUI that is allowing it not the deamon, as I know nithing about wxwidgets nor QT widgets and input/output forms/templates and so on thus I'd think myself far more likely to have missed a spot in the GUI code than in the daemon. But maybe not, maybe both don't check user inputs against the max and reject ones that are too large.

-MarkM-

well, this is only a hotfix, the bugfix would be to lift the 21M coinlimit.
atleast u can delete the TX so u get ur coins back

[markm]

As I said really the limit is the use of int64 in the blockchain.

We'd need a blockchain based on, I guess, 128 bit integers instead of 64 bit to really lift the limit properly.

The constant set as 21M though maybe could be tuned up to maxint64/100000000.

-MarkM-

[Icoin]

It might even turn out that it is the GUI that is allowing it not the deamon

The transaction was sent trough the deamon

We'd need a blockchain based on, I guess, 128 bit integers instead of 64 bit to really lift the limit properly.

I guess we are not the only ones that need to do that. What brings me back to 0.8

[markm]

0.8's blockchain uses 128 bit integers?

-MarkM-