Topic: Coin Devs??? Can you help a fellow Dev Out??? Just a Question (Read 1548 times)
Just got back from a trip to visit the family, I will take a look at that. Glad its narrowed to an address issue, I appreciate your time on this. If Im able to get this reward situation figured out I wouldn't have a problem giving you a Viking Coin donation if you would like.
you're using the old version.
oops
Ok... now running the newer version I'm getting the empty scriptPubKey
too. I guess I should properly debug this when I have the chance, but I wonder
about this:
rpcmining.cpp:36
Code:
// getwork/getblocktemplate mining rewards paid here:
pMiningKey = new CReserveKey(pwalletMain);
pMiningKey = new CReserveKey(pwalletMain);
The static pMiningKey that is defined a few lines above gave
me errors when I tried to build with wallet-disabled configuration, so
something is funny around there anyway. (in that case I got rid of those errors
by putting the pMiningKey definition to miner.h and made the two
aux functions return false)
you're using the old version. i3lome is using the hard forked version
I tried it out (getting the source from github) and mining
testnet everything went ok.
But apparently the official source isn't the one you are
having trouble with? (You are generating coins with "DevcoinMiner")
2014-08-25 08:29:13 DevcoinMiner:
2014-08-25 08:29:13 proof-of-work found
hash: 0000000048ee719e56e730184e293bccfb369959195ce18982399515d7c4d8f9
target: 0000019726000000000000000000000000000000000000000000000000000000
2014-08-25 08:29:13 CBlock(hash=0000000048ee719e56e730184e293bccfb369959195ce18982399515d7c4d8f9, ver=327681, hashPrevBlock=0000000017fa717a610764dc771e4a6bc6f4f07de545d232a0a910e95d491b95, hashMerkleRoot=dab5d829d5f1b8ee5de7c7da8000089312381038c8194f0b9c1787b7ccce9929, nTime=1408955344, nBits=1e019726, nNonce=1386869691, vtx=1)
2014-08-25 08:29:13 CTransaction(hash=dab5d829d5, ver=1, vin.size=1, vout.size=1, nLockTime=0)
CTxIn(COutPoint(0000000000, 4294967295), coinbase 01350101062f503253482f)
CTxOut(nValue=1.00000000, scriptPubKey=)
2014-08-25 08:29:13 vMerkleTree: dab5d829d5f1b8ee5de7c7da8000089312381038c8194f0b9c1787b7ccce9929
2014-08-25 08:29:13 generated 1.00
I think, you send the block reward to an invalid address (scriptPubKey is empty). Examine the transaction in debug console:2014-08-25 08:29:13 proof-of-work found
hash: 0000000048ee719e56e730184e293bccfb369959195ce18982399515d7c4d8f9
target: 0000019726000000000000000000000000000000000000000000000000000000
2014-08-25 08:29:13 CBlock(hash=0000000048ee719e56e730184e293bccfb369959195ce18982399515d7c4d8f9, ver=327681, hashPrevBlock=0000000017fa717a610764dc771e4a6bc6f4f07de545d232a0a910e95d491b95, hashMerkleRoot=dab5d829d5f1b8ee5de7c7da8000089312381038c8194f0b9c1787b7ccce9929, nTime=1408955344, nBits=1e019726, nNonce=1386869691, vtx=1)
2014-08-25 08:29:13 CTransaction(hash=dab5d829d5, ver=1, vin.size=1, vout.size=1, nLockTime=0)
CTxIn(COutPoint(0000000000, 4294967295), coinbase 01350101062f503253482f)
CTxOut(nValue=1.00000000, scriptPubKey=)
2014-08-25 08:29:13 vMerkleTree: dab5d829d5f1b8ee5de7c7da8000089312381038c8194f0b9c1787b7ccce9929
2014-08-25 08:29:13 generated 1.00
Code:
gettransaction dab5d829d5f1b8ee5de7c7da8000089312381038c8194f0b9c1787b7ccce9929
you sould see at the end something like this:
Quote
....
"vout" : [
{
"value" : 50000.00000000,
"n" : 0,
"scriptPubKey" : {
"asm" : "OP_DUP OP_HASH160 f048507208cdddb41b5c89e035542d594aa10202 OP_EQUALVERIFY OP_CHECKSIG",
"hex" : "76a914f048507208cdddb41b5c89e035542d594aa1020288ac",
"reqSigs" : 1,
"type" : "pubkeyhash",
"addresses" : [
"BqhBQLxQSh6CnmP7pzZu9q7Mr1veRxE4r8"
]
}
}
...
"vout" : [
{
"value" : 50000.00000000,
"n" : 0,
"scriptPubKey" : {
"asm" : "OP_DUP OP_HASH160 f048507208cdddb41b5c89e035542d594aa10202 OP_EQUALVERIFY OP_CHECKSIG",
"hex" : "76a914f048507208cdddb41b5c89e035542d594aa1020288ac",
"reqSigs" : 1,
"type" : "pubkeyhash",
"addresses" : [
"BqhBQLxQSh6CnmP7pzZu9q7Mr1veRxE4r8"
]
}
}
...
I think you may be onto something. I tried the Version adjustment last night. I will spend today trying to work this out.
This is what gettransaction gives me.
i3lome@i3lome-A740GM-M:~/vikingcoin/src$ ./vikingcoind -testnet gettransaction 81572fda124605376e67bed3df05726133246e03ee619f718f15a5d64df23fbf
error: {"code":-5,"message":"Invalid or non-wallet transaction id"}
2014-08-25 08:29:13 DevcoinMiner:
2014-08-25 08:29:13 proof-of-work found
hash: 0000000048ee719e56e730184e293bccfb369959195ce18982399515d7c4d8f9
target: 0000019726000000000000000000000000000000000000000000000000000000
2014-08-25 08:29:13 CBlock(hash=0000000048ee719e56e730184e293bccfb369959195ce18982399515d7c4d8f9, ver=327681, hashPrevBlock=0000000017fa717a610764dc771e4a6bc6f4f07de545d232a0a910e95d491b95, hashMerkleRoot=dab5d829d5f1b8ee5de7c7da8000089312381038c8194f0b9c1787b7ccce9929, nTime=1408955344, nBits=1e019726, nNonce=1386869691, vtx=1)
2014-08-25 08:29:13 CTransaction(hash=dab5d829d5, ver=1, vin.size=1, vout.size=1, nLockTime=0)
CTxIn(COutPoint(0000000000, 4294967295), coinbase 01350101062f503253482f)
CTxOut(nValue=1.00000000, scriptPubKey=)
2014-08-25 08:29:13 vMerkleTree: dab5d829d5f1b8ee5de7c7da8000089312381038c8194f0b9c1787b7ccce9929
2014-08-25 08:29:13 generated 1.00
I think, you send the block reward to an invalid address (scriptPubKey is empty). Examine the transaction in debug console:2014-08-25 08:29:13 proof-of-work found
hash: 0000000048ee719e56e730184e293bccfb369959195ce18982399515d7c4d8f9
target: 0000019726000000000000000000000000000000000000000000000000000000
2014-08-25 08:29:13 CBlock(hash=0000000048ee719e56e730184e293bccfb369959195ce18982399515d7c4d8f9, ver=327681, hashPrevBlock=0000000017fa717a610764dc771e4a6bc6f4f07de545d232a0a910e95d491b95, hashMerkleRoot=dab5d829d5f1b8ee5de7c7da8000089312381038c8194f0b9c1787b7ccce9929, nTime=1408955344, nBits=1e019726, nNonce=1386869691, vtx=1)
2014-08-25 08:29:13 CTransaction(hash=dab5d829d5, ver=1, vin.size=1, vout.size=1, nLockTime=0)
CTxIn(COutPoint(0000000000, 4294967295), coinbase 01350101062f503253482f)
CTxOut(nValue=1.00000000, scriptPubKey=)
2014-08-25 08:29:13 vMerkleTree: dab5d829d5f1b8ee5de7c7da8000089312381038c8194f0b9c1787b7ccce9929
2014-08-25 08:29:13 generated 1.00
Code:
gettransaction dab5d829d5f1b8ee5de7c7da8000089312381038c8194f0b9c1787b7ccce9929
you sould see at the end something like this:
Quote
....
"vout" : [
{
"value" : 50000.00000000,
"n" : 0,
"scriptPubKey" : {
"asm" : "OP_DUP OP_HASH160 f048507208cdddb41b5c89e035542d594aa10202 OP_EQUALVERIFY OP_CHECKSIG",
"hex" : "76a914f048507208cdddb41b5c89e035542d594aa1020288ac",
"reqSigs" : 1,
"type" : "pubkeyhash",
"addresses" : [
"BqhBQLxQSh6CnmP7pzZu9q7Mr1veRxE4r8"
]
}
}
...
"vout" : [
{
"value" : 50000.00000000,
"n" : 0,
"scriptPubKey" : {
"asm" : "OP_DUP OP_HASH160 f048507208cdddb41b5c89e035542d594aa10202 OP_EQUALVERIFY OP_CHECKSIG",
"hex" : "76a914f048507208cdddb41b5c89e035542d594aa1020288ac",
"reqSigs" : 1,
"type" : "pubkeyhash",
"addresses" : [
"BqhBQLxQSh6CnmP7pzZu9q7Mr1veRxE4r8"
]
}
}
...
You need to decide if you're on version 2 blocks or version 2 transactions.
CTransaction::CURRENT_VERSION = 1; so the above is always false.
tip, you're on version 1 transactions so change all code that looks for tx.nVersion equaling 2 back to 1.
Code:
bool IsStandardTx(const CTransaction& tx, string& reason)
{
AssertLockHeld(cs_main);
if (tx.nVersion > CTransaction::CURRENT_VERSION || tx.nVersion < 2) {
reason = "version";
return false;
}
{
AssertLockHeld(cs_main);
if (tx.nVersion > CTransaction::CURRENT_VERSION || tx.nVersion < 2) {
reason = "version";
return false;
}
CTransaction::CURRENT_VERSION = 1; so the above is always false.
tip, you're on version 1 transactions so change all code that looks for tx.nVersion equaling 2 back to 1.
That's the type of information I was looking for. Thank you
Im not great with explaining things but you turned on my light bulb. The original chain produces V1 blocks, while the upgrade and Merge Mining produces V2 blocks. I started testnet on the New Client which produces V2 blocks from the get go.
Seems what I need to do its, take the Testnet from Client 1 that's been established to a point then, implement MM chain allowing v2 to be accepted from that point forward.
The blocks are fine, it's the transactions that are being rejected. You have V2 blocks and V1 transactions - well you should, you currently have both but have code like the above that rejects V1 transactions, fix that and it'll work. Especially the above line.
Im on my way home now, I give it a go when I get in. Figured it would be something simple just not that obvious. lol.
You need to decide if you're on version 2 blocks or version 2 transactions.
CTransaction::CURRENT_VERSION = 1; so the above is always false.
tip, you're on version 1 transactions so change all code that looks for tx.nVersion equaling 2 back to 1.
Code:
bool IsStandardTx(const CTransaction& tx, string& reason)
{
AssertLockHeld(cs_main);
if (tx.nVersion > CTransaction::CURRENT_VERSION || tx.nVersion < 2) {
reason = "version";
return false;
}
{
AssertLockHeld(cs_main);
if (tx.nVersion > CTransaction::CURRENT_VERSION || tx.nVersion < 2) {
reason = "version";
return false;
}
CTransaction::CURRENT_VERSION = 1; so the above is always false.
tip, you're on version 1 transactions so change all code that looks for tx.nVersion equaling 2 back to 1.
That's the type of information I was looking for. Thank you
Im not great with explaining things but you turned on my light bulb. The original chain produces V1 blocks, while the upgrade and Merge Mining produces V2 blocks. I started testnet on the New Client which produces V2 blocks from the get go.
Seems what I need to do its, take the Testnet from Client 1 that's been established to a point then, implement MM chain allowing v2 to be accepted from that point forward.
The blocks are fine, it's the transactions that are being rejected. You have V2 blocks and V1 transactions - well you should, you currently have both but have code like the above that rejects V1 transactions, fix that and it'll work. Especially the above line.
You need to decide if you're on version 2 blocks or version 2 transactions.
CTransaction::CURRENT_VERSION = 1; so the above is always false.
tip, you're on version 1 transactions so change all code that looks for tx.nVersion equaling 2 back to 1.
Code:
bool IsStandardTx(const CTransaction& tx, string& reason)
{
AssertLockHeld(cs_main);
if (tx.nVersion > CTransaction::CURRENT_VERSION || tx.nVersion < 2) {
reason = "version";
return false;
}
{
AssertLockHeld(cs_main);
if (tx.nVersion > CTransaction::CURRENT_VERSION || tx.nVersion < 2) {
reason = "version";
return false;
}
CTransaction::CURRENT_VERSION = 1; so the above is always false.
tip, you're on version 1 transactions so change all code that looks for tx.nVersion equaling 2 back to 1.
That's the type of information I was looking for. Thank you
Im not great with explaining things but you turned on my light bulb. The original chain produces V1 blocks, while the upgrade and Merge Mining produces V2 blocks. I started testnet on the New Client which produces V2 blocks from the get go.
Seems what I need to do its, take the Testnet from Client 1 that's been established to a point then, implement MM chain allowing v2 to be accepted from that point forward.
You need to decide if you're on version 2 blocks or version 2 transactions.
CTransaction::CURRENT_VERSION = 1; so the above is always false.
tip, you're on version 1 transactions so change all code that looks for tx.nVersion equaling 2 back to 1.
Code:
bool IsStandardTx(const CTransaction& tx, string& reason)
{
AssertLockHeld(cs_main);
if (tx.nVersion > CTransaction::CURRENT_VERSION || tx.nVersion < 2) {
reason = "version";
return false;
}
{
AssertLockHeld(cs_main);
if (tx.nVersion > CTransaction::CURRENT_VERSION || tx.nVersion < 2) {
reason = "version";
return false;
}
CTransaction::CURRENT_VERSION = 1; so the above is always false.
tip, you're on version 1 transactions so change all code that looks for tx.nVersion equaling 2 back to 1.
Sounds like some of the code in the forms or overviewpage is broken. If I'm understanding correctly that you are finding blocks but they just aren't showing up in the QT? What does 'getinfo' return?
You are correct. Blocks are found with a Value but is not credited to the wallet.I don't have a Copy of "getinfo" saved but,
Balance stays at 0, while block count and difficulty adjusts as it should.
I will look threw the forms to see if I can find the problem. Im sure it something small or out of place. I appreciate your input
Sounds like some of the code in the forms or overviewpage is broken. If I'm understanding correctly that you are finding blocks but they just aren't showing up in the QT? What does 'getinfo' return?
Yes, the problem is with the Viking Coin upgrade that Im working on. Im the dev of Viking Coin, this whole post is asking for assistance on finding the root of the problem. Im a dev asking for fellow dev assistance 
Please. Enough. If you can't do this how are you going to develop a coin worthwhile to the current environment. Just quit now or learn to develop.
Satoshi's vision is being raped just so people like you can make clone shitcoins to hock for ICO or whatever BTC profit you can get.
And you're not a fellow developer.
Wow, so much vague hostility. ICO? no clue what that is but IPO defiantly not. Quit now and learn to develop? Isnt Developing evolving a code to meet the need of its purpose? In the developing process, new things are learned and applied so it will develop over a period of time. right?
Im not you average dev, Im not afraid to ask for assistance on an issue someone else may have experienced. If no assistance is around it just takes a little longer to work things out. I have no secrets, I hold no premine and hype is not part of Viking Coin. 3 months old now, we have outlive several coins.
Ahmed_bodi, I thank you for the kind words and your efforts with Viking Coin. Viking wont be able to overlooked too much longer. The slow forward pace just allows us to pick up momentum.
You really need to think before you speak. i3lome isnt a standard shitcoin dev. They are WORKING on the code. Not copy and pasting as random shitcoin devs do. Theres a big difference there
Yes, the problem is with the Viking Coin upgrade that Im working on. Im the dev of Viking Coin, this whole post is asking for assistance on finding the root of the problem. Im a dev asking for fellow dev assistance
Please. Enough. If you can't do this how are you going to develop a coin worthwhile to the current environment. Just quit now or learn to develop.
Satoshi's vision is being raped just so people like you can make clone shitcoins to hock for ICO or whatever BTC profit you can get.
And you're not a fellow developer.
Yes, the problem is with the Viking Coin upgrade that Im working on. Im the dev of Viking Coin, this whole post is asking for assistance on finding the root of the problem. Im a dev asking for fellow dev assistance
If it work with other coins testnet then the problem is with the vikingcoin.
No I have not tried another coins testnet? What would I learn from that?
Have you tried other SHA coin testnet?
Solo mining- 3- 333mhs Usb Block Eruptors.
Setgenerate= true, same result.
Upgrade to 0.9.2 + Merge Mine patch.
Auxpow, isn't active at this time. Still on original testnet chain.
The source is at
https://github.com/i3lome/vikingcoin
Branch 0.9.2
The Master is the Original Client that is still being mined. Well, Except the Update today to Disable KGW
Setgenerate= true, same result.
Upgrade to 0.9.2 + Merge Mine patch.
Auxpow, isn't active at this time. Still on original testnet chain.
The source is at
https://github.com/i3lome/vikingcoin
Branch 0.9.2
The Master is the Original Client that is still being mined. Well, Except the Update today to Disable KGW
Jump to: