Devcoin

[Icoin]

0.8's blockchain uses 128 bit integers?

-MarkM-

No, i dnt mean that, what i mean is that the Bitcoin core devs needs to adress that issue?

Devcoin just reached this issue 1000 times faster.

[1713890059]

1713890059

[1713890059]

1713890059

[1713890059]

1713890059

[1713890059]

1713890059

[markm]

No, because bitcoin will never have more than 21 million coins.

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-

[Icoin]

No, because bitcoin will never have more than 21 million coins.

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-

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

[markm]

I don't think we need more than the int64 on the blockchain.

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.

-MarkM-

[Icoin]

I don't think we need more than the int64 on the blockchain.

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.

-MarkM-

No, as you can see in the block there are 6 Transactions in total, not a single one is larger then 20M.
http://devda.ch:2750/block/994f6e2fb4c2580ba431640d48a1c13333c52c13537d7d8a2f25b769282aeb60

[markm]

No, as you can see in the block there are 6 Transactions in total, not a single one is larger then 20M.
http://devda.ch:2750/block/994f6e2fb4c2580ba431640d48a1c13333c52c13537d7d8a2f25b769282aeb60

Could it be a limit of no one address having a balance over 21M?

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-

[Icoin]

No, as you can see in the block there are 6 Transactions in total, not a single one is larger then 20M.
http://devda.ch:2750/block/994f6e2fb4c2580ba431640d48a1c13333c52c13537d7d8a2f25b769282aeb60

Could it be a limit of no one address having a balance over 21M?

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.

[markm]

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.

-MarkM-

[Unthinkingbit]

From:
http://www.devtome.com/doku.php?id=devcoin#generation_rate

Code:

//static const int64 MAX_MONEY = 21000000 * COIN;
static const int64 MAX_MONEY = 21000000000 * COIN;

MAX_MONEY was multiplied by 1,000, so that should not be the problem. It would have to be an instance where:
2100000000000000

was not replaced with:
2100000000000000000

or another place where:
21000000 * COIN

was not replaced by:
21000000000 * COIN

We'll look through the code to find that. When those are found, the existing code will be changed. There will not be an upgrade to a later version of bitcoin because that would take longer.

// In the meantime, please don't make any devcoin transactions through vircurex or cryptostocks, even though they
// might work, because they might cause some kind of problem later on.

Edit:
The problem is resolved, so you can send and receive devcoins safely:
https://bitcointalk.org/index.php?topic=34586.msg1547662#msg1547662

Edit:
The only unchanged instance of 21000000 I could find was in rpc.cpp. If someone finds another unchanged instance of 21000000 please post that.

[markm]

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?

-MarkM-

[Unthinkingbit]

Looking through the block chain, two other blocks with a total value of more than 21,000,000 devcoins were found.

Block 75803:
http://devda.ch:2750/chain/Devcoin?count=1&hi=75803

had a send of 25,000,000 devcoins total to address 1DC2i3Z1ZZ35qXbpbRDWirmaT9vSWeBYDr, plus some small transactions bringing the total to 25,050,845 on 2013-01-30 11:23:47.

Block 73979:
http://devda.ch:2750/chain/Devcoin?count=1&hi=73979

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

both list the 35 million devcoin block.

please check: DVC Block 75878
http://devda.ch:2750/chain/Devcoin?count=1&hi=75878

Icoin, could you please check the source code of your devcoin version to see if the 21000000 string in rpc.cpp has been changed to 21000000000.

[smoothie]

Are there any merchants accepting DVC?

[Icoin]

Icoin, could you please check the source code of your devcoin version to see if the 21000000 string in rpc.cpp has been changed to 21000000000.

Yes that string is below the 21000000 string in my rpc.cpp using the latest source but still 0 conf.

[Unthinkingbit]

Yes that string is below the 21000000 string in my rpc.cpp using the latest source but still 0 conf.

I assume you mean that the active string is 21000000000.

When you say 0 confirmations, what is the current block number of your client?

[Icoin]

Yes that string is below the 21000000 string in my rpc.cpp using the latest source but still 0 conf.

I assume you mean that the active string is 21000000000.

When you say 0 confirmations, what is the current block number of your client?

78737

[DiabloD3]

Which url is the correct url for git upstream?

[Unthinkingbit]

..
When you say 0 confirmations, what is the current block number of your client?

78737

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?

[Icoin]

..
When you say 0 confirmations, what is the current block number of your client?

78737

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.

[markm]

Are there any merchants accepting DVC?

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.

-MarkM-

[Unthinkingbit]

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.