 Show Posts
|
|
Pages: [1]
|
this is the message block 1606987 is giving
Block 1606987 BlockTime=1515220020 CurrTime=1515220024 AdjustedTime=1515220023 vtx[0].nTime=1515219952
**
EXCEPTION: 12bignum_error
CBigNum::operator/ : BN_div failed
Magi in ProcessMessages()
ProcessMessage(block, 265 bytes) FAILED
hope it helps
Exactly the same problem. I tried Debian 8/9, Win x86, all go to crash. No matter the binary I take, or compile by myself (compile only on Debian 8 ). Win x64 seems not crash, but also not sync. Wallet 1.4.5.2 can you try build from source after apply this commit https://github.com/filoozom/magi/commit/2ffa778bf7be59a4da76bd1d56b77a133ce795ef ? just cd to magi folder
wget https://github.com/filoozom/magi/commit/2ffa778bf7be59a4da76bd1d56b77a133ce795ef.patch
git apply 2ffa778bf7be59a4da76bd1d56b77a133ce795ef.patch
Thanks for commit, but nothing changed, The same result ************************
EXCEPTION: 12bignum_error
CBigNum::operator/ : BN_div failed
Magi in ThreadStakeMiner()
Update: 've disabled stacking, magi seems get run, but something still wrong with block 1606987 , wallet not syncing |
|
|
|
this is the message block 1606987 is giving
Block 1606987 BlockTime=1515220020 CurrTime=1515220024 AdjustedTime=1515220023 vtx[0].nTime=1515219952
**
EXCEPTION: 12bignum_error
CBigNum::operator/ : BN_div failed
Magi in ProcessMessages()
ProcessMessage(block, 265 bytes) FAILED
hope it helps
Exactly the same problem. I tried Debian 8/9, Win x86, all go to crash. No matter the binary I take, or compile by myself (compile only on Debian 8 ). Win x64 seems not crash, but also not sync. Wallet 1.4.5.2 |
|
|
|
Should we keep following with the only 104.128.225.215 node's chain (connect=104.128.225.215) or it's allowed to expand nodes list as regular (addnode etc)? I ask because I've changed the "connect=104.128.225.215" to "addnode=104.128.225.215" and seems catch some strange behaviour Wallet-1.4.3.1 Here is from my debug.log agiMiner:
new block found
hash: 000000005b5ea0db12ed287ce8d3cb475a7c87e04a71195ac0654ba407e89c29
target: 0000000086ef0000000000000000000000000000000000000000000000000000
CBlock(hash=000000005b5ea0db12ed287ce8d3cb475a7c87e04a71195ac0654ba407e89c29, ver=5, hashPrevBlock=986ebca6348c3ac0322dfd4696f7b6adcaf08f283181ed849ad608cb4efb39b7, hashMerkleRoot=0bb55fed8894498844ac73b94c3ec4a5b939e9b5f7bfec797d769b7effa96e72, nTime=1505252350, nBits=1d0086ef, nNonce=187196, vtx=1, vchBlockSig=3044022069414970439829a3c229980788ba43a16a137892ee0b804dacfa76787e586ad0022020425f2c0480936ea13f2fbcefa23bb6ca11a5b78abb7377ff8591d933253bbe)
Coinbase(hash=0bb55fed88, nTime=1505252314, ver=1, vin.size=1, vout.size=1, nLockTime=0)
CTxIn(COutPoint(0000000000, 4294967295), coinbase 03d4881602c700062f503253482f)
CTxOut(nValue=8.78079905, scriptPubKey=025bcf17216ee86f14906f9026ce8b9dd5627d98d4b5d7486c53321fe303368945 OP_CHECKSIG)
vMerkleTree: 0bb55fed88
generated 8.78079905
AddToWallet 0bb55fed88 new
NotifyTransactionChanged 0bb55fed8894498844ac73b94c3ec4a5b939e9b5f7bfec797d769b7effa96e72 status=0
updateWallet 0bb55fed8894498844ac73b94c3ec4a5b939e9b5f7bfec797d769b7effa96e72 0
SetBestChain: new best=000000005b5ea0db12ed287ce8d3cb475a7c87e04a71195ac0654ba407e89c29 height=1476820 money supply=8052770 trust=66450092821708 date=12.09.2017 21:39:10
Stake checkpoint: a7c46b89
ProcessBlock: ACCEPTED
And here is from this block's info from chainz.cryptoid.info {
"hash": "00000000835d34917dbefadd1d33fa1eb6f0ad0b8cd28e13d4629405ae2ebe23",
"confirmations": 471,
"size": 282,
"height": 1476820,
"version": 5,
"merkleroot": "941148c19a9d696701066b17cbbed86670f6a3c371909721e944d2768e459238",
"mint": 8.78079905,
"time": 1505252350,
"nonce": 3758111380,
"bits": "1d0086ef",
"difficulty": 1.89720059,
"previousblockhash": "986ebca6348c3ac0322dfd4696f7b6adcaf08f283181ed849ad608cb4efb39b7",
"nextblockhash": "5a4016e30461fd84d67627cc28ac8b3b49a4f8219ca7e201ce9d12bfea6c1228",
"flags": "proof-of-work",
"proofhash": "00000000835d34917dbefadd1d33fa1eb6f0ad0b8cd28e13d4629405ae2ebe23",
"entropybit": 1,
"modifier": "3125108231465701",
"modifierchecksum": "a7c46b89",
"tx": [
"941148c19a9d696701066b17cbbed86670f6a3c371909721e944d2768e459238"
],
"signature": "304402202a7c4ea0e7e2fe4da016f646ad4d8228d47816757c4480e2e7d9cb2a5bb4d58602203745ff249d254837ef2ed5aec9c159c2b79488c88aa90fce9b013581991b77e2"
}I've resynced the wallet with "connect=104.128.225.215" and I do not see mined coins. Update: Chain seems perform REORGANIZE received block 00000000835d34917dbe
ProcessBlock: ACCEPTED
received block 5a4016e30461fd84d676
REORGANIZE
REORGANIZE: Disconnect 1 blocks; 986ebca6348c3ac0322d..000000005b5ea0db12ed
REORGANIZE: Connect 2 blocks; 986ebca6348c3ac0322d..5a4016e30461fd84d676
REORGANIZE: done
|
|
|
|
PoW mining is not working
(mining "via setgenerate true")
Pls add the version you use in the post so we don't get confused. wallet 1.4.3.2 (linux version) I can provide the whole debug.log if nec |
|
|
|
PoW mining in test wallet 1.4.3.2 (linux version) is not working (mining via "setgenerate true") MagiMiner:
new block found
hash: 00000f14abec41e0f39f8effb07420e98cd217e8f5745d21b2d8658e8540fc0e
target: 00000fffff000000000000000000000000000000000000000000000000000000
CBlock(hash=00000f14abec41e0f39f8effb07420e98cd217e8f5745d21b2d8658e8540fc0e, ver=5, hashPrevBlock=00000407185e0b72f5f672cd463726510ad387317a0dc4524c611381feb96b7b, hashMerkleRoot=3412f4a8ca2dff58511faf7e78e8eaec820ebcefe1cbc0270dcd532b10f935a1, nTime=1504853099, nBits=1e0fffff, nNonce=44657, vtx=1, vchBlockSig=3045022100bcf7c3704619a70ad35d90e107f81fb3432654cc2801e518e516650bb2ced573022029e124193c693aaddf013ad8535062acced18401d2f3bf816493c7524ad61d6c)
Coinbase(hash=3412f4a8ca, nTime=1504853080, ver=1, vin.size=1, vout.size=1, nLockTime=0)
CTxIn(COutPoint(0000000000, 4294967295), coinbase 039825160101062f503253482f)
CTxOut(nValue=8.19326608, scriptPubKey=025bcf17216ee86f14906f9026ce8b9dd5627d98d4b5d7486c53321fe303368945 OP_CHECKSIG)
vMerkleTree: 3412f4a8ca
generated 8.19326608
ERROR: AcceptBlock() : proof-of-work block violation (height = 1451416)
ERROR: ProcessBlock() : AcceptBlock FAILED
ERROR: MagiMiner : ProcessBlock, block not accepted
wallet 1.4.3.2 (linux version) |
|
|
|
@starmman It seems we have the similar in mind on it And thank you for polite and informative answer  |
|
|
|
Saturday afternoon, relaxing with a good beer, and asking myself: why not just junk the POW?
AMEN brotha I've been askin myself that too It's very simple, dudes. There are few easy stages that will follow: 1) thousands past miners who want to sell Magi junked; 2) all exchanges junk the Magi due to low volume; 3) Magi junked at all. Do you want this scenario for Magi? I do not. |
|
|
|
General steps to improve stability of MAGI chain: 1. Hardcode main pools in client (need list) to be guarantors of the chain, not forever. For example, we have 10 pools in list, if 7 of 10 accepted block, that block true. 2. Try to find out vector of attack (pow or pos) and develop a protection system. 3. Test protection system several times with emulation of attack 4. Remove hardcoded pools. Please vote for my plan: https://twitter.com/moiseev_aa/status/899972940887994369If you're not a developer than what's purport to vote or not? Can you implement your "plan"? Seems you just rend the air. I am developer with +10 years experience. I know that at least first and last step easy to realize. If so, I'm sorry for my words. Please give me the link to coin that you've launch My developer work not linked with crypto coins. I thought exactly so |
|
|
|
General steps to improve stability of MAGI chain: 1. Hardcode main pools in client (need list) to be guarantors of the chain, not forever. For example, we have 10 pools in list, if 7 of 10 accepted block, that block true. 2. Try to find out vector of attack (pow or pos) and develop a protection system. 3. Test protection system several times with emulation of attack 4. Remove hardcoded pools. Please vote for my plan: https://twitter.com/moiseev_aa/status/899972940887994369If you're not a developer than what's purport to vote or not? Can you implement your "plan"? Seems you just rend the air. I am developer with +10 years experience. I know that at least first and last step easy to realize. If so, I'm sorry for my words. Please give me the link to coin that you've launch |
|
|
|
General steps to improve stability of MAGI chain:1. Hardcode main pools in client (need list) to be guarantors of the chain, not forever. For example, we have 10 pools in list, if 7 of 10 accepted block, that block true. 2. Try to find out vector of attack (pow or pos) and develop a protection system. 3. Test protection system several times with emulation of attack 4. Remove hardcoded pools. Please vote for my plan: https://twitter.com/moiseev_aa/status/899972940887994369 If you're not a developer than what's purport to vote or not? Can you implement your "plan"? Seems you just rend the air. |
|
|
|
To ALL,
The fork takes place from one pool to another, and that I believe something fundamental needs a clarification as we haven't seen this before. This has messed around the mining. I suggest stop mining at this time until we firstly 1) get a keep-it-going solution, and 2) root cause finding and a solution to the fork. The mining just going on, unfortunately, doesn't make sense to me, and I would propose a rollover back to a fair point. Let me know if rollover sounds good to you, and where you want to startover.
I think many would agree that our goal is to get Magi back to stable coin. If rollover back is necessary, so let's perform this. About point - if rollover purpose is to remove some unfair block(s) so let's choose the last fair block before first unfair one in straight chain in order to minimize the loss. I agree with those words! Do not forget coins have been rolling out to exchanges and being sold. If you rollback ("edit") the blockchain hard enough, exchanges will get back on Magi, as they will lose those funds already sold, and eventually delist XMG... I've seen this happen at Cryptopia for another coin. At one point - delist, at the other one - re-delist. Looks like we should choose between bad option (rollback) and very bad option (fair chain absence at all). Or maybe I'm wrong and situation not so bad? If no, I think I have no doubts which one to choose. Hmm its not a easy desicion. We have look at different consequences for Magi, miners, holders, exchanges etc. Rollback or new XMG with coinswap there are many different options. The whole idea about Magi is very good. If we work together we can make a difference in cryptoworld. Think we us about the options & share ideas! So let me express you my support To you, to Joe and to other Magi developers. I hope Magi will keep growing and I believe we overcome this point |
|
|
|
To ALL,
The fork takes place from one pool to another, and that I believe something fundamental needs a clarification as we haven't seen this before. This has messed around the mining. I suggest stop mining at this time until we firstly 1) get a keep-it-going solution, and 2) root cause finding and a solution to the fork. The mining just going on, unfortunately, doesn't make sense to me, and I would propose a rollover back to a fair point. Let me know if rollover sounds good to you, and where you want to startover.
I think many would agree that our goal is to get Magi back to stable coin. If rollover back is necessary, so let's perform this. About point - if rollover purpose is to remove some unfair block(s) so let's choose the last fair block before first unfair one in straight chain in order to minimize the loss. I agree with those words! Do not forget coins have been rolling out to exchanges and being sold. If you rollback ("edit") the blockchain hard enough, exchanges will get back on Magi, as they will lose those funds already sold, and eventually delist XMG... I've seen this happen at Cryptopia for another coin. At one point - delist, at the other one - re-delist. Looks like we should choose between bad option (rollback) and very bad option (fair chain absence at all). Or maybe I'm wrong and situation not so bad? If no, I think I have no doubts which one to choose. |
|
|
|
To ALL,
The fork takes place from one pool to another, and that I believe something fundamental needs a clarification as we haven't seen this before. This has messed around the mining. I suggest stop mining at this time until we firstly 1) get a keep-it-going solution, and 2) root cause finding and a solution to the fork. The mining just going on, unfortunately, doesn't make sense to me, and I would propose a rollover back to a fair point. Let me know if rollover sounds good to you, and where you want to startover.
I think many would agree that our goal is to get Magi back to stable coin. If rollover back is necessary, so let's perform this. About point - if rollover purpose is to remove some unfair block(s) so let's choose the last fair block before first unfair one in straight chain in order to minimize the loss. |
|
|
|
|
Welcome team.
I'm mining Magi for about 2 years at couple of regular PC's, I got about 150 khash. And I'd like to say that I like Magi. I like it for that I can take the average PC, just start mining and get some solvent amount of coins a little faster than thousand years without extreme gaming card and asic farm. I'm not appreciate switching magi to PoS-only coin, and some sense tells me that I'm not the only person who think so.
I think that if developers switch Magi to PoS-only mode, most part of community will leave it, including me. But I'd like to keep my friendship with Magi.
My vote is 2 hands up to keep PoW. I believe that solution can be found.
|
|
|
|
|
Seems some work on it is in progress
Look at wallet version
getpeerinfo
?[{
"addr" : "173.247.233.38:8233",
"services" : "00000001",
"lastsend" : 1502896393,
"lastrecv" : 1502896393,
"conntime" : 1502863879,
"version" : 71061,
"subver" : "/m-core:1.4.0.1/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 1446298,
"banscore" : 0
}]
|
|
|
|
|
