<p>I'm sorry about the title, but I could not think of a more condensed way to describe this problem. I forked an older version of blackcoin a while back to make a test altcoin for fun. I have been running it on a few vps nodes and a client. It was set to go to pos after a short pow period, and has been running smoothly.</p>

<p>Now, I recently cloned the latest Blackcoin source (the one that switches to posv2 after a certain block) and edited it to connect to my test coin. It does this, but for some reason every block it stakes is conflicted, even though it is not set to switch to protocol v2 until some block in the future.</p>

<p>Why is this? I have looked over the pos algorithm in <code>kernel.cpp</code> and <code>CheckStakeKernelHash</code> should definitely use the ppc pos algo. Why are they all conflicted? Every pos transaction gets 1 confirm, then conflicts.</p>

CC BY-SA 3.0
2014-08-08T19:29:11.827Z
I don't know much about Blackcoin, but Bitcoin and its immediate derivatives have "checkpoints" where certain blocks have their hashes hardcoded in the source. If Blackcoin has something similar, that would certainly screw up your alternate chain.
Nate Eldredge
CC BY-SA 3.0
2014-08-08T19:30:17.203Z
You are right, but I changed the mapStakeModifierCheckpoints in kernel.cpp to match my testcoin
Matthew Darnell
CC BY-SA 3.0
2014-08-08T19:37:30.433Z
I did a gettransaction rpc call on the new client and another client running the older version on a mined tx from staking. Everything on both looked the same in the returned json, except at the end:
Matthew Darnell
CC BY-SA 3.0
2014-08-08T19:39:11.850Z
the conflicted one:                                                           ],
"amount" : -812.93728365,
"fee" : 0.09336264,
"confirmations" : -1,
"generated" : true,
"txid" : "362a66bebb08da276a3dedf9bdac992d0516138cf3f8a29b8ae88c9352482882",
"time" : 1407524288,
"timereceived" : 1407524288,
"details" : [
]
Matthew Darnell
CC BY-SA 3.0
2014-08-08T19:39:43.863Z
this one was ok:                                      "amount" : -812.93728365,
"fee" : 0.09336264,
"confirmations" : 30,
"generated" : true,
"blockhash" : "b00a59ad2f09032389cd55585ebe0d4e1c581a2a9693a5defc438a511751ed06",
"blockindex" : 1,
"blocktime" : 1407524288,
"txid" : "d3e5a989aae0298005cea6daf0da12169a48b67e5adfc527294e113b75b86d9b",
"time" : 1407524288,
"timereceived" : 1407524530,
"details" : [
{
"account" : "",
"address" : "RKYdwr66HGjtaV3GapTTXnBqJ8DRcxbMbD",
"category" : "immature",
"amount" : 0.09336264
}
]
Matthew Darnell
CC BY-SA 3.0
2014-08-08T19:50:27.637Z
Just as a general suggestion, it is easier to read updates like this if you edit your question to include them, rather than leaving them as comments.  (You might also see the help center to read about how to format them like code snippets.)
Nate Eldredge
<altcoin-development><proof-of-stake><blackcoin><block-validity>
PoS coin is producing conflicted chain after merging with upstream developments
Matthew Darnell
# PoS coin is producing conflicted chain after merging with upstream developments

(Asked by: username_0 on 2014-08-08)

I'm sorry about the title, but I could not think of a more condensed way to describe this problem. I forked an older version of blackcoin a while back to make a test altcoin for fun. I have been running it on a few vps nodes and a client. It was set to go to pos after a short pow period, and has been running smoothly.

Now, I recently cloned the latest Blackcoin source (the one that switches to posv2 after a certain block) and edited it to connect to my test coin. It does this, but for some reason every block it stakes is conflicted, even though it is not set to switch to protocol v2 until some block in the future.

Why is this? I have looked over the pos algorithm in `kernel.cpp` and `CheckStakeKernelHash` should definitely use the ppc pos algo. Why are they all conflicted? Every pos transaction gets 1 confirm, then conflicts.

**Tags:** altcoin-development, proof-of-stake, blackcoin, block-validity

> **Comments:**
> **username_1**: I don't know much about Blackcoin, but Bitcoin and its immediate derivatives have "checkpoints" where certain blocks have their hashes hardcoded in the source. If Blackcoin has something similar, that would certainly screw up your alternate chain.  
> **username_0**: You are right, but I changed the mapStakeModifierCheckpoints in kernel.cpp to match my testcoin  
> **username_0**: I did a gettransaction rpc call on the new client and another client running the older version on a mined tx from staking. Everything on both looked the same in the returned json, except at the end:  
> **username_0**: the conflicted one:                                                           ], "amount" : -812.93728365, "fee" : 0.09336264, "confirmations" : -1, "generated" : true, "txid" : "362a66bebb08da276a3dedf9bdac992d0516138cf3f8a29b8ae88c9352482882", "time" : 1407524288, "timereceived" : 1407524288, "details" : [ ]  
> **username_0**: this one was ok:                                      "amount" : -812.93728365, "fee" : 0.09336264, "confirmations" : 30, "generated" : true, "blockhash" : "b00a59ad2f09032389cd55585ebe0d4e1c581a2a9693a5defc438a511751ed06", "blockindex" : 1, "blocktime" : 1407524288, "txid" : "d3e5a989aae0298005cea6daf0da12169a48b67e5adfc527294e113b75b86d9b", "time" : 1407524288, "timereceived" : 1407524530, "details" : [ { "account" : "", "address" : "RKYdwr66HGjtaV3GapTTXnBqJ8DRcxbMbD", "category" : "immature", "amount" : 0.09336264 } ]  
> **username_1**: Just as a general suggestion, it is easier to read updates like this if you edit your question to include them, rather than leaving them as comments.  (You might also see the help center to read about how to format them like code snippets.)  

---

## 0 answers

