DeVCoin has the issue because there is no actual real limit to how many DeVCoins there will be; it makes 50,000 more every block forever, so some day, I do not know when, should have more coins than can fit into the "int64 devtoshis" format used on the blockchain.

But, that just means no one transaction-input or transaction-output can have more than int64 devtoshis.

DeVCoin has the issue because there is no actual real limit to how many DeVCoins there will be; it makes 50,000 more every block forever, so some day, I do not know when, should have more coins than can fit into the "int64 devtoshis" format used on the blockchain.

But, that just means no one transaction-input or transaction-output can have more than int64 devtoshis.

-MarkM-

RightThe probability that Bitcoin switches to 128bit anytime soon isnt given, so there is a need to address this issue in the actual Devcoin code.

Where we'd need more is any place that tries to add up all the inputs or outputs.

So actually even though the blockchain allows int64 per input/output, the code that adds up the total in and the total out probably also uses int64 currently, so the total of any one transaction is probably supposed to be limited; somehow though you managed to input a command to transfer more than 21M coins in one move and the input checking didn't check and tell you hey no way, too large a number.

Where we'd need more is any place that tries to add up all the inputs or outputs.

So actually even though the blockchain allows int64 per input/output, the code that adds up the total in and the total out probably also uses int64 currently, so the total of any one transaction is probably supposed to be limited; somehow though you managed to input a command to transfer more than 21M coins in one move and the input checking didn't check and tell you hey no way, too large a number.

Maybe until the code tries to put together a block it cannot tell how much is "at" any one address, thus cannot even tell that an address is going to end up with more than the limit as its balance, while the code that does try to build blocks does check each address as it does so?

If that is the problem, then maybe we need to make sure the user interface does not have any problem displaying balances that are above that limit then let the block building code go ahead and allow the total balance "at" an address to be whatever it ends up being, since the blockchain does not store that it only stores inputs and outputs?

Maybe until the code tries to put together a block it cannot tell how much is "at" any one address, thus cannot even tell that an address is going to end up with more than the limit as its balance, while the code that does try to build blocks does check each address as it does so?

If that is the problem, then maybe we need to make sure the user interface does not have any problem displaying balances that are above that limit then let the block building code go ahead and allow the total balance "at" an address to be whatever it ends up being, since the blockchain does not store that it only stores inputs and outputs?

-MarkM-

Stop!It was a regular transaction from cryptostocks.com. I dont doubt the integrity of Vircurex. But i doubt the integrity of the Devcoin code. Its not just me that is affected. And since the new generated Block value of 45k and 5k is virgin i doubt now that anyone received this from this block or is able to recover it. Probably just the 15M and 20M transaction will be recoverable trough Vircurex.

Well maybe Unthinkingbit can cast some light upon it. He is the designer and basically the senior analyst, I mostly just coded/modified what and where he told me to code/modify and dealt with making tarballs, putting them online, setting up github repos and such.

I can't think of anything offhand to explain this problem, at a glance it doesn't even look like it is trying to make the balance of any one address go over 21M but then again I haven't looked up the current balance of each address it is trying to send to. Nor am I even sure the per address total balance even matters / is limited.

The rpc.cpp one is commented out and replaced with 21 billion, and what it seems to be for is to limit how many coins one can send such as with sendtoaddress; we let people try to send up to 21 billion coins instead of only up to 21 million.

Supposedly this "problem block" does not involve any transactions of 21 million or more anyway, so maybe allowing people to try to send 21 billion is fine.

But something seems to be preventing the block from getting mined, we just have not figured out what.

Is it possible the automatically included fees are not large enough to satisfy the block building codes expectations of the amount of fees? I would hope they would use the same code so they come up with the same required fee though.

The inputs are large, do larger inputs require more coindays destroyed before they become useable? Maybe they are so huge, and were moved to where they are now so recently compared to the "problem transaction" that they simply have not had time to mature yet?

has a send of 19,300,000 devcoins total to address 1CTNFBDDAJQ4BxN2o8DYAJuMnqSVtnLUHQ, plus a send of 9,080,133 devcoins to 1A4n5Pdh3xaTPbbhQteqLyRLceh6eZrgHU, plus small transactions bringing the total to 23,781,815 on 2013-01-16 14:15:07.

Could the people who sent coins in any of those transactions please report, by posting in the thread of messaging me, if the transactions were successful or not.

The rpc.cpp code with the 21,000,000 coin limit was in my old version of devcoin-qt. Mark updated that to 21,000,000,000 in his latest version. The block explorers, both Icoin's block explorer and K1773R's block explorer:http://darkgamex.ch:2751/chain/DevCoin?count=1&hi=75878

I expect most will do so via Ripple, we have oodles of devcoins ready to back oodles of IOUs on Ripple so that any merchant accepting any currency via Ripple will automagically accept devcoins if someone chooses to use devcoins to pay them with.

That's strange, because block 75878 is part of the block chain, so there should be 78,737 - 75,878 = 2,859 confirmations.

Have you sent any other devcoins since then? From what type of client (devcoin-qt, devcoind, your web wallet, vircurex, cryptostocks, etc..) to what type of client were the devcoins sent?

Since the sender client is on the side of crytostocks i assume the latest devcoind. I was able to send and receive dvc with my client what is aswell the latest devcoind.

Do you mean from cryptostocks to your devcoind client? Did the balance change in your cryptostocks account? If you sent it to your devcoind client, could you please restart devcoind with the -rescan option, and post the results.