Topic: Devcoin - page 114. (Read 412952 times)

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.

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-

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.

0.8's blockchain uses 128 bit integers?

-MarkM-

The transaction was sent trough the deamon

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

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-

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

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-

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?

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

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?

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-

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.

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-

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.

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-

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?

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-

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

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-