Do you have the problem with a new coin or peercoin directly?
I came across it in Stronghands, (a clone with 90billion coinsupply, one owner having 18 billion coins, and a 2billion MAX_MONEY ) then decided to check up stream and found same problem in Peerunity. i'm not that familiar with PPC rewards, but i doubt it will have a problem for some time. |
|
|
|
edited. I've become aware of a bug which breaks the wallet.dat on PPC (and clones). It's more likely to effect clones as it involves having a balance exceeding MAX_MONEY. Basically sending any transaction with combined inputs exceeding MAX_MONEY results in failing various error checks. and client will refuse to load the wallet.dat brief list of experiments so far with MAX_MONEY=1000 - sending 10000 breaks wallet - Setting the txfee to 100, then sending 9900, breaks wallet. - setting up two inputs of 5001, then sending 5002, breaks wallet. https://github.com/Peerunity/Peerunity/issues/199notes: to be an issue - it must be possible for one wallet to hold balance > max_money. - Qt GUI limitation may help prevent issue (eg, send field limitations), but assumedly command line send may exceed the GUI limitation .. issue revealed itself in Stronghands. a fix to limit max spend to (MAX_MONEY / 2) is a quick answer to the problem needs to include fees into the initial check, https://github.com/bumbacoin/stronghands/commit/817da6efb8410579f940be4270e823463ee981b0if MAX_MONEY is 2 billion, adding 1 to either MAX_MONEY, or to error checks will allow neat send values of 1 billion. .. |
|
|
|
Sadly first quick fix (v0130) didnt work for all occasions.
See below for second fix  v0140
https://github.com/bumbacoin/stronghands/releases/tag/v0140.. For anyone with a broken walleti have compiled a SPECIAL QT with increased Max Money !!!! this should enable you to open your wallet and extract the privkeys, then you can import them into a new wallet please PM me and i'll send you a copy. it's not for general use. this is the expected error for such a borken wallet EXCEPTION: St13runtime_error
CWallet::GetDebit() : value out of range
ppcoin in ThreadStakeMinter()
terminate called after throwing an instance of 'std::runtime_error'
what(): CWallet::GetDebit() : value out of range
|
|
|
|
hello, i've come across a code issue in Stronghands and Peerunity that likely exists in PAC, it will only be an issue where users have more coins than MAX_MONEY (in this case 2 billion). simply put, sending 2billion coins (MAX_MONEY) will break your wallet, it's only the wallet.dat, so if you back up yr keys or wallet.dat, it's good. if you want to test, backup your wallet.dat, then send 2 billion coins then just replace the borken wallet with the back up ….. edit looks ok for PAC coin. max_money is 1 trillion, so it becomes a problem when you have more than that in a wallet also i see the qt is limited to sending 99,999,999 (whereas the SHND wallet allows 9,999,999,999) |
|
|
|
|
i'm helping with Stronghands, just wondering if anyone has seen anything similar ??
transactions over 2billion corrupt wallet.
see two posts above, by Pineapples.
another coin which might suffer from the same is PAC.
ppc code base, mega coinsupply, 2billion MAX_MONEY which is easily acheivable balance for an individual..
EDIT
have replicated the same problem in PPC,
so likely to exist in other PPC clones.
obviously only a problem where it is possible for a user to hold MAX_MONEY
|
|
|
|
The main limitation is that JSON, being JavaScript-based
What does JSON have to do with any of this? The Bitcoin protocol does not use JSON anywhere. No, but the RPC interface does, and enough programs are still treating bitcoin amounts as floats that floating-point precision is the limit of what numbers are "safe". In fact, I predict that within a year of fractional satoshis being introduced (by a protocol extension or second layer or whatever), someone will lose a significant amount of money due to a floating-point rounding error in third-party software. i've been looking at Stronghands (PPC clone) because it can't handle a transaction value close to MAX_MONEY, it appears to pass a pre-check, then is entered into wallet db, then fails a post-check breaking the wallet.dat i'm not sure what's going on, but at some point tx out value is handled by JSON. i'm wondering if this is causing the problem through slight variations in value. there are a bunch of checks arounds MAX_MONEY (including MoneyRange). i changed one of the error checks to (MAX_MONEY - 1), and it still allows .00000011 over that value so there is some obvious looseness around these values. (edited, too many zeroes) https://github.com/bumbacoin/stronghands/commit/8bc58843f43012e142beff29a8fcbb7a37c8ed5bon a cursory glance the code is the same as PPC, BTC has changed a lot since then. |
|
|
|
if anyone has any suggestions as to why the code treats the pre /post error checks differently please add your voice you can see below, that as long as txout.nValue and nDebit are the same everything should be fine, however, the problem with current code is that it seems to fails on the Debit check. (which is after the tx is added to the wallet, so the wallet then fails to load.) https://github.com/bumbacoin/stronghands/blob/master/src/wallet.h#L182 int64 GetCredit(const CTxOut& txout) const
{
if (!MoneyRange(txout.nValue))
throw std::runtime_error("CWallet::GetCredit() : value out of range");
return (IsMine(txout) ? txout.nValue : 0);
} int64 GetDebit(const CTransaction& tx) const
{
int64 nDebit = 0;
BOOST_FOREACH(const CTxIn& txin, tx.vin)
{
nDebit += GetDebit(txin);
if (!MoneyRange(nDebit))
throw std::runtime_error("CWallet::GetDebit() : value out of range");
}
return nDebit; here's an example of failing transaction, this is after some fucking around, so pure value MAX_MONEY as tx limit is not being used, ie not 2billion coins being sent, from memory i have no idea what was being used at the time . lol but it is true to the behaviour of sending over 2billion sendtoaddress Sh1A3HKCmWHXiwLAEPUDhAH2JhCwxQHbqA 1999999999.999999
error: {"code":-4,"message":"Error: The transaction was rejected. This might happen if some of the coins in your wallet were already spent, such as if you used a copy of wallet.dat and coins were spent in the copy but not marked as spent here."} from debug.log CommitTransaction:
CTransaction(hash=1296fcf30a, nTime=1486976866, ver=1, vin.size=2, vout.size=2, nLockTime=0)
CTxIn(COutPoint(ae178efe20, 0), scriptSig=3046022100d9b652c2500088)
CTxIn(COutPoint(b47018e531, 1), scriptSig=30460221008bebbd1a7d525a)
CTxOut(nValue=0.870001, scriptPubKey=OP_DUP OP_HASH160 6d24e85c6fda83f7454e20f4796abf16848a0d5b OP_EQUALVERIFY OP_CHECKSIG)
CTxOut(nValue=1999999999.999999, scriptPubKey=OP_DUP OP_HASH160 d832f6a6d6b39a2631c26fe42c8f049795840fdc OP_EQUALVERIFY OP_CHECKSIG)
keypool keep 9
AddToWallet 1296fcf30a new
WalletUpdateSpent found spent coin 1999999999.98ppc ae178efe20c6fcdaac9197087b5ef5378392f6fde0a01871c9538d06e61c0041
WalletUpdateSpent found spent coin 1999999999.97ppc b47018e53178a5e80a78dcc60f40d2058953a5d873ec6f22c451b0d59b571fce
ERROR: CTransaction::CheckTransaction() : txout total out of range
ERROR: CTxMemPool::accept() : CheckTransaction failed
CommitTransaction() : Error: Transaction not valid
|
|
|
|
i have a quickfix for the problem https://github.com/bumbacoin/stronghands/commit/8bc58843f43012e142beff29a8fcbb7a37c8ed5bencouraging clients to reject transactions at 1999999999 coins. will build clients tomorrow. .. there is some issue with the way the code handles values, previously a transaction would pass through the credit check (creating the tx), enter into the wallet db, but then fail on the debit check (loading the tx) causing the wallet to refuse to load and quit .. with this "fix" if (dAmount <= 0.0 || dAmount > ((MAX_MONEY / COIN) -1)) it appears that it should reject values of >1999999999 but it still accepts transactions of 1999999999.00000011 so not really sure where the discrepancy in handling is. |
|
|
|
and 2 ^63 is around 92 billion, wat? sorry, 9.22337203685478E18 satoshis (or dogetoshis, or bumbatoshis lol), which is ~92 billion coins, fixed above also |
|
|
|
|
i notice doge has over 100 billion coins,
and 2 ^63 is around 92 billion coins (9.22337203685478E18 satoshi),
so seemingly as long as they're not all in one tx, it's possible because any individual case will not exceed int64 limits.
i wonder how PoS coins with their moneysupply rpc would handle that.
seems like that 'd be the first thing to break.
|
|
|
|
curiously enough, 21 million is allegedly close to a 64 bit floating point number ? 2^52 = 2251799813685248 satoshis https://en.bitcoin.it/wiki/Controlled_supply#Currency_with_Finite_Supply"Speculated justifications for the unintuitive value "21 million" are that it matches a 4-year reward halving schedule; or the ultimate total number of Satoshis that will be mined is close to the maximum capacity of a 64-bit floating point number. Satoshi has never really justified or explained many of these constants." obviously there are some programming limitations on what a 64 bit integer can usefully represent, this has confused me no end. lol |
|
|
|
|
ignoring the obvious 21mill projected coin supply,
what is the theoretical max value that the code base can handle ?
is it int64 ?
or
9223372036854775807
divided by satoshi ofc, so just over 92 billion coins ?
edit.
i see dogecoin has over 100 billion coins :p
edit.
i've just been looking further and i see int64 max is 2^63, as 1 bit is used for +/-
|
|
|
|
i am helping with glorytimes wallet issue, here is a run down of the issue.all transactions are checked against the variable MAX_MONEY (2billion coins) to ascertain they do not exceed it. official code will allow transactions to enter the wallet.dat that further error checks will reject, effectively breaking the wallet.datif you have two inputs in your wallet of 1.1 billion coins, you send 1.2 billion, the transaction value is 1.2 billion which is < 2 billion, which passes the first round error check and gets entered into the wallet.dat soon enough another round of checks looks at all inputs and outputs. 1.1 input + 1.1 input = 1.2 tx output + 1.0 change output + fee = 2.2 billion which is not < 2 billion so the next error check fails. and yr wallet is now geborken !! -- fixes so far do not require any fork, and are compatible with official qt's,it is only that the official qt's allow you to break your wallet ( as happened with glorytime ). -- if you have geborken your wallet, i have compiled a special increased max_money qt, that should enable you to load your wallet, and export your privkeys to import into a clean wallet. PM me -- this code bug exists in the Peerunity code base, however it is highly unlikely to ever be an issue for PPC. to be an issue some wallet must have a balance > max_money Stronghands currently has around 90billion coin supply, which is 45x the value of MAX_MONEY ( 2 billion) there are other coins out there that might have the conditions necessary !! be alert !! |
|
|
|
spent a few minutes looking at the explorer, seems various bounties have not been paid yet (judging on amounts posted in thread) namo joblessminer bitcoinrulzz all are very vocal supporters, including attacking me yet none of those have received any bounties yet ? nor have they asked ? also apple_talk has received no bounty, there is one question from v.coinz asking for apple_talk address, so perhaps they are mining only? apple_talk is most likely to not be a sockpuppet !! |
|
|
|
please dont selete this post i want an answer about this http://84.200.210.130:3001/richlistwhy 1 wallet already have 387,000,000 virtual coins i am hard to mining this coins but already stock 387M virtual coins in 1 person That is their for few reasons... . Bounty . Development . Rewards . Any time money is taken out from that account it is posted here with details. Anytime bounty is paid for the VirtualCoin team efforts including myself it will be disclosed. Once we meet our bounty list as mentioned all the remaining coins will be destroyed. Even if we do not meet all the bounties by the end of 6 months. Coins will be destroyed as well. These coins will help us to remain in Top 5 once Marketcapital is calculated. No these coins are not for sale or IPO, but for funding VirtualCoin development. Hope this help. Their will be and is full disclosure each time withdraw is made to whom & what purpose. good to see, dev finally actually has admitted the pre=mine exists, after numerous posts deleted, and years of ongoing ignoring. for some reason. all previous questions regarding the premine were considered as spam and fud, and my questions elicited an attack from a couple of obvious dev sockpuppets. still the problem exists that there is no official mention of it in the OP. looking forward to total transparency. heh. of course my question still is why is the premine so confusingly created in teh code? lol definite reward for the most unclear code ever !! int64 Vcoinr = 50;
if(Vcoinh >= 1 && Vcoinh < 1000) {
if((Vcoinh >= 101 && dDiff > 75) || Vcoinh >= 1000) {
// 222000/(((x+2600)/9)^2)
// Vcoinr = (222000.0 / (pow((dDiff+2600.0)/9.0,2.0)));
Vcoinr = dDiff * .4356;
if (Vcoinr == 25) Vcoinr = (1 + 250.00) - (Vcoinh / 4);
if (Vcoinr == 5) Vcoinr = 250.00 - (Vcoinh / 4);
}
else {
Vcoinr = dDiff * .4426;
// Vcoinr = (1112.0 / (pow((dDiff+51.0)/6.0,2.0)));
if (Vcoinr == 500) Vcoinr = (5 + 250.00) - (Vcoinh / 4);
if (Vcoinr == 25) Vcoinr = 250.00 - (Vcoinh / 4);
if (Vcoinh > 10 && Vcoinh < 12) Vcoinr = pow (pzx,pzy);
} |
|
|
|
the price from 0.0085 bitcoin then down to 0.000012 bitcoin very sad to see this condition maybe its need help from pumper or investor to make high price happen, around 0.01 btc to 0.1 btc is very high but hope it will happen, will buy it some with current price now hope to the moon in the near future  This is due to the fact that this exchange is very in volume. Allow some time, once we started get listed on popular exchanges value will be lot higher. Believe in VirtualCoin, I myself have not sold even 1 VC yet, it has a lot of potential & growth. Thanks, Dev the pre-mine is an obvious thing to see, sockpuppets are not so obvious to prove, the dev might not have sold any, but sockpuppets are allowed to sell? |
|
|
|
please dont selete this post i want an answer about this http://84.200.210.130:3001/richlistwhy 1 wallet already have 387,000,000 virtual coins i am hard to mining this coins but already stock 387M virtual coins in 1 person That is their for few reasons... . Bounty . Development . Rewards . Any time money is taken out from that account it is posted here with details. Anytime bounty is paid for the VirtualCoin team efforts including myself it will be disclosed. Once we meet our bounty list as mentioned all the remaining coins will be destroyed. Even if we do not meet all the bounties by the end of 6 months. Coins will be destroyed as well. These coins will help us to remain in Top 5 once Marketcapital is calculated. No these coins are not for sale or IPO, but for funding VirtualCoin development. Hope this help. Their will be and is full disclosure each time withdraw is made to whom & what purpose. good to see, dev finally actually has admitted the pre=mine exists, after numerous posts deleted, and years of ongoing ignoring. for some reason. all previous questions regarding the premine were considered as spam and fud, and my questions elicited an attack from a couple of obvious dev sockpuppets. still the problem exists that there is no official mention of it in the OP. looking forward to total transparency. heh. of course my question still is why is the premine so confusingly created in teh code? lol definite reward for the most unclear code ever !! int64 Vcoinr = 50;
if(Vcoinh >= 1 && Vcoinh < 1000) {
if((Vcoinh >= 101 && dDiff > 75) || Vcoinh >= 1000) {
// 222000/(((x+2600)/9)^2)
// Vcoinr = (222000.0 / (pow((dDiff+2600.0)/9.0,2.0)));
Vcoinr = dDiff * .4356;
if (Vcoinr == 25) Vcoinr = (1 + 250.00) - (Vcoinh / 4);
if (Vcoinr == 5) Vcoinr = 250.00 - (Vcoinh / 4);
}
else {
Vcoinr = dDiff * .4426;
// Vcoinr = (1112.0 / (pow((dDiff+51.0)/6.0,2.0)));
if (Vcoinr == 500) Vcoinr = (5 + 250.00) - (Vcoinh / 4);
if (Vcoinr == 25) Vcoinr = 250.00 - (Vcoinh / 4);
if (Vcoinh > 10 && Vcoinh < 12) Vcoinr = pow (pzx,pzy);
} |
|
|
|
OK but is the old wallet file compatible with the new wallet? If so, isn't deleting just the blockchain data enough?
i dont think there should be any need to do anything other than start the new client, but i'm not sure what obavijest has done apart from the changes i made. so simple way to check back up your datadirectory, start new client. and it's always good to back up things. says I who has deleted a goodly quantity of coins over time. lol. price you pay for having a serious amount of coin data directories .. wowsers, i just checked, i think i need to work out a better system for dev/compiling as i have about 150 data directories atm ... |
|
|
|
|
Show Posts
