Bottlecaps 2.1 UPDATE REQUIRED - HARDFORK JULY 4 2014 to 200% Annual PoS

[Ense04]

Going on my 4th day of staking. No coins yet. I have a block of 6000 waiting. Not sure why its taking so long...

[Tranz]

Going on my 4th day of staking. No coins yet. I have a block of 6000 waiting. Not sure why its taking so long...

Blocks created before July 4th, will take the full 30 days to age. Blocks created after the 4th should stake in 15. The staking icon, unfortunately doesn't reflect this properly.

[Ense04]

Going on my 4th day of staking. No coins yet. I have a block of 6000 waiting. Not sure why its taking so long...

Blocks created before July 4th, will take the full 30 days to age. Blocks created after the 4th should stake in 15. The staking icon, unfortunately doesn't reflect this properly.

OK. I originally thought that was the case but when the staking icon lit up 4 days ago I figured I was good to go. Oh well...

[Jamesco]

Soon my pretties, soon...

[Tranz]

Going on my 4th day of staking. No coins yet. I have a block of 6000 waiting. Not sure why its taking so long...

Blocks created before July 4th, will take the full 30 days to age. Blocks created after the 4th should stake in 15. The staking icon, unfortunately doesn't reflect this properly.

OK. I originally thought that was the case but when the staking icon lit up 4 days ago I figured I was good to go. Oh well...

My blocks from the 4th are now getting weight and staking. So the 15 day is working as planned..

[PressF1]

Going on my 4th day of staking. No coins yet. I have a block of 6000 waiting. Not sure why its taking so long...

Blocks created before July 4th, will take the full 30 days to age. Blocks created after the 4th should stake in 15. The staking icon, unfortunately doesn't reflect this properly.

OK. I originally thought that was the case but when the staking icon lit up 4 days ago I figured I was good to go. Oh well...

My blocks from the 4th are now getting weight and staking. So the 15 day is working as planned..

Mine too. But something weird is going on, check out this transaction ID at http://cap.cryptocoinexplorer.com: 5a2c52bd5b87031c2debf72e226fa13a131841188106101f5d019a2b100d5b1e transaction coming from nowhere?

[Tranz]

Going on my 4th day of staking. No coins yet. I have a block of 6000 waiting. Not sure why its taking so long...

Blocks created before July 4th, will take the full 30 days to age. Blocks created after the 4th should stake in 15. The staking icon, unfortunately doesn't reflect this properly.

OK. I originally thought that was the case but when the staking icon lit up 4 days ago I figured I was good to go. Oh well...

My blocks from the 4th are now getting weight and staking. So the 15 day is working as planned..

Mine too. But something weird is going on, check out this transaction ID at http://cap.cryptocoinexplorer.com: 5a2c52bd5b87031c2debf72e226fa13a131841188106101f5d019a2b100d5b1e transaction coming from nowhere?

The previous transaction(e2815838e585a050dbfe...) was the 2nd transaction at the height, during the 500 block roll back. The explorer didn't create a new entry. But using your wallet you can see the details.

Code:

09:00:18

gettransaction e2815838e585a050dbfe060f48a6bfdfc28baff632b980a9a0cf0ea2e43256a9


09:00:18

{
"txid" : "e2815838e585a050dbfe060f48a6bfdfc28baff632b980a9a0cf0ea2e43256a9",
"version" : 1,
"time" : 1404483424,
"locktime" : 0,
"vin" : [
{
"txid" : "ddff9b5c56ffb4ca0b8df82438810c391dde369770a808ca784f36d6adfda5ea",
"vout" : 0,
"scriptSig" : {
"asm" : "3046022100e6b7b641b3f942f8427cb36ae0d25d580465bf5a0811f2b579fac7d1ef6d584d022100f2b8c9320ad44fea5dd3f3906fc829cfa6979dfe8fbd77133230e9f083dfa3c401 038797a20f7b93e4a2969870a2a4d9c0b5768916492dedaea94e426984101fde9b",
"hex" : "493046022100e6b7b641b3f942f8427cb36ae0d25d580465bf5a0811f2b579fac7d1ef6d584d022100f2b8c9320ad44fea5dd3f3906fc829cfa6979dfe8fbd77133230e9f083dfa3c40121038797a20f7b93e4a2969870a2a4d9c0b5768916492dedaea94e426984101fde9b"
},
"sequence" : 4294967295
}
],
"vout" : [
{
"value" : 0.00000000,
"n" : 0,
"scriptPubKey" : {
"asm" : "",
"type" : "nonstandard"
}
},
{
"value" : 3000.00000000,
"n" : 1,
"scriptPubKey" : {
"asm" : "038797a20f7b93e4a2969870a2a4d9c0b5768916492dedaea94e426984101fde9b OP_CHECKSIG",
"reqSigs" : 1,
"type" : "pubkey",
"addresses" : [
"EuGFoMB5JW3DJmKRkccRkuZ1SpBRp9Bo7v"
]
}
},
{
"value" : 3000.00000000,
"n" : 2,
"scriptPubKey" : {
"asm" : "038797a20f7b93e4a2969870a2a4d9c0b5768916492dedaea94e426984101fde9b OP_CHECKSIG",
"reqSigs" : 1,
"type" : "pubkey",
"addresses" : [
"EuGFoMB5JW3DJmKRkccRkuZ1SpBRp9Bo7v"
]
}
}
],
"blockhash" : "97e2c40a05b784ce8c57b0030c3da1626c9f27db121bac1801e2f49ed92c6f7e",
"confirmations" : 24166
}

[PressF1]

Going on my 4th day of staking. No coins yet. I have a block of 6000 waiting. Not sure why its taking so long...

Blocks created before July 4th, will take the full 30 days to age. Blocks created after the 4th should stake in 15. The staking icon, unfortunately doesn't reflect this properly.

OK. I originally thought that was the case but when the staking icon lit up 4 days ago I figured I was good to go. Oh well...

My blocks from the 4th are now getting weight and staking. So the 15 day is working as planned..

Mine too. But something weird is going on, check out this transaction ID at http://cap.cryptocoinexplorer.com: 5a2c52bd5b87031c2debf72e226fa13a131841188106101f5d019a2b100d5b1e transaction coming from nowhere?

The previous transaction(e2815838e585a050dbfe...) was the 2nd transaction at the height, during the 500 block roll back. The explorer didn't create a new entry. But using your wallet you can see the details.

Code:

09:00:18

gettransaction e2815838e585a050dbfe060f48a6bfdfc28baff632b980a9a0cf0ea2e43256a9


09:00:18

{
"txid" : "e2815838e585a050dbfe060f48a6bfdfc28baff632b980a9a0cf0ea2e43256a9",
"version" : 1,
"time" : 1404483424,
"locktime" : 0,
"vin" : [
{
"txid" : "ddff9b5c56ffb4ca0b8df82438810c391dde369770a808ca784f36d6adfda5ea",
"vout" : 0,
"scriptSig" : {
"asm" : "3046022100e6b7b641b3f942f8427cb36ae0d25d580465bf5a0811f2b579fac7d1ef6d584d022100f2b8c9320ad44fea5dd3f3906fc829cfa6979dfe8fbd77133230e9f083dfa3c401 038797a20f7b93e4a2969870a2a4d9c0b5768916492dedaea94e426984101fde9b",
"hex" : "493046022100e6b7b641b3f942f8427cb36ae0d25d580465bf5a0811f2b579fac7d1ef6d584d022100f2b8c9320ad44fea5dd3f3906fc829cfa6979dfe8fbd77133230e9f083dfa3c40121038797a20f7b93e4a2969870a2a4d9c0b5768916492dedaea94e426984101fde9b"
},
"sequence" : 4294967295
}
],
"vout" : [
{
"value" : 0.00000000,
"n" : 0,
"scriptPubKey" : {
"asm" : "",
"type" : "nonstandard"
}
},
{
"value" : 3000.00000000,
"n" : 1,
"scriptPubKey" : {
"asm" : "038797a20f7b93e4a2969870a2a4d9c0b5768916492dedaea94e426984101fde9b OP_CHECKSIG",
"reqSigs" : 1,
"type" : "pubkey",
"addresses" : [
"EuGFoMB5JW3DJmKRkccRkuZ1SpBRp9Bo7v"
]
}
},
{
"value" : 3000.00000000,
"n" : 2,
"scriptPubKey" : {
"asm" : "038797a20f7b93e4a2969870a2a4d9c0b5768916492dedaea94e426984101fde9b OP_CHECKSIG",
"reqSigs" : 1,
"type" : "pubkey",
"addresses" : [
"EuGFoMB5JW3DJmKRkccRkuZ1SpBRp9Bo7v"
]
}
}
],
"blockhash" : "97e2c40a05b784ce8c57b0030c3da1626c9f27db121bac1801e2f49ed92c6f7e",
"confirmations" : 24166
}

Thanks for your reply. I was just a little worried of something I didn't understand. It's not my wallet though, noticed it in the block chain.

[dreamwatcher]

The previous transaction(e2815838e585a050dbfe...) was the 2nd transaction at the height, during the 500 block roll back. The explorer didn't create a new entry. But using your wallet you can see the details.

Do I need to recreate the database on the explorer? When did this roll-back occur?

[Tranz]

The previous transaction(e2815838e585a050dbfe...) was the 2nd transaction at the height, during the 500 block roll back. The explorer didn't create a new entry. But using your wallet you can see the details.

Do I need to recreate the database on the explorer? When did this roll-back occur?

The big roll back happened on July 4th, due to an issue with the ACP server.  It was approx 500 blocks. But the real question I have is what happens during more normal re-orgs. Like 1 or 2 blocks. Does the explorer update those or no?

[dreamwatcher]

The previous transaction(e2815838e585a050dbfe...) was the 2nd transaction at the height, during the 500 block roll back. The explorer didn't create a new entry. But using your wallet you can see the details.

Do I need to recreate the database on the explorer? When did this roll-back occur?

The big roll back happened on July 4th, due to an issue with the ACP server.  It was approx 500 blocks. But the real question I have is what happens during more normal re-orgs. Like 1 or 2 blocks. Does the explorer update those or no?

If one looks in the CCE3 development thread (now locked: https://bitcointalk.org/index.php?topic=262539.msg2804427), I spent much of the time on solving the orphan block issue.

There are two methods in place to avoid this issue.

1. When the database loader is triggered by the coin daemon block notify, there is a 15 second delay before the loader starts to query the coin daemon for information. This gives the daemon time to catch and reorganize the quickly detected orphan blocks before the loader commits the information to its database.

2. There is a settable range, normally set at 250 blocks,  in the explorer configuration file for block look back. Every time the database loader is triggered , it compares the previous block hashes in the range against an immediate query to the coin daemon. If a hash does not match, it corrects all the information pertaining to that block(block information, transactions, address balances, etc.) with the new information the daemon provides.


However, if changes occur after the check range, they go unnoticed until a transaction is referred to in a future block that does not exist in the explorer database. After all, it is completely impractical to check the entire chain every update.
I am working on CCE version 3.5, however this is a rare occurrence and I will need to balance the complexity vs. benefit in solving this particular situation. Progress with 3.5 is slow right now because of exchange software I am writing at the moment.

So far this system has proven quite effective and the only issues so far have been with daemons that cannot return information from their own databases after a major reorganization. In that situation, there is not much I can do as I am not going to start patching coin daemons in which I am not a developer for.   (This is not the case here. I am referring to another coin.)

This is one of the advantages of moving to a sponsored system for the explorers. Once people have a vested interest in something, they are much more apt to give me a heads up when these types of things occurred. Again, not the case here, I knew about the Jul 4 fork but did not know it caused a major reorganization that occurred outside the check parameters.

Anyway, I will start on the database reconstruction. It might take a day or so because of the size of the CAP block chain.

[Tranz]

The previous transaction(e2815838e585a050dbfe...) was the 2nd transaction at the height, during the 500 block roll back. The explorer didn't create a new entry. But using your wallet you can see the details.

Do I need to recreate the database on the explorer? When did this roll-back occur?

The big roll back happened on July 4th, due to an issue with the ACP server.  It was approx 500 blocks. But the real question I have is what happens during more normal re-orgs. Like 1 or 2 blocks. Does the explorer update those or no?

If one looks in the CCE3 development thread (now locked: https://bitcointalk.org/index.php?topic=262539.msg2804427), I spent much of the time on solving the orphan block issue.

There are two methods in place to avoid this issue.

1. When the database loader is triggered by the coin daemon block notify, there is a 15 second delay before the loader starts to query the coin daemon for information. This gives the daemon time to catch and reorganize the quickly detected orphan blocks before the loader commits the information to its database.

2. There is a settable range, normally set at 250 blocks,  in the explorer configuration file for block look back. Every time the database loader is triggered , it compares the previous block hashes in the range against an immediate query to the coin daemon. If a hash does not match, it corrects all the information pertaining to that block(block information, transactions, address balances, etc.) with the new information the daemon provides.


However, if changes occur after the check range, they go unnoticed until a transaction is referred to in a future block that does not exist in the explorer database. After all, it is completely impractical to check the entire chain every update.
I am working on CCE version 3.5, however this is a rare occurrence and I will need to balance the complexity vs. benefit in solving this particular situation. Progress with 3.5 is slow right now because of exchange software I am writing at the moment.

So far this system has proven quite effective and the only issues so far have been with daemons that cannot return information from their own databases after a major reorganization. In that situation, there is not much I can do as I am not going to start patching coin daemons in which I am not a developer for.   (This is not the case here. I am referring to another coin.)

This is one of the advantages of moving to a sponsored system for the explorers. Once people have a vested interest in something, they are much more apt to give me a heads up when these types of things occurred. Again, not the case here, I knew about the Jul 4 fork but did not know it caused a major reorganization that occurred outside the check parameters.

Anyway, I will start on the database reconstruction. It might take a day or so because of the size of the CAP block chain.

Good information thanks. The July 4th roll back took us all by surprise, especially after the fork had been in place for 5 or 6 hours with no issues.  But so far it has been pretty smooth sailing since then, so that is good.

Thanks for the diligent effort with the explorer.  Let us know the best way we can support you.

[dreamwatcher]

Good information thanks. The July 4th roll back took us all by surprise, especially after the fork had been in place for 5 or 6 hours with no issues.  But so far it has been pretty smooth sailing since then, so that is good.

Thanks for the diligent effort with the explorer.  Let us know the best way we can support you.

The database has been reconstructed and went live late last night. After looking a bit at the code, I remember that I did not program the system to go into orphan recovery when a "ghost" transaction was found. I wanted to make sure the orphan correction system worked well in production with the check range, before allowing the system to correct deep changes when a reorganization occurred beyond the check range. The issue has come up so infrequently, that it kind of slipped my mind.  
Since system has worked well to date, in the next patch,  I will add the ability for the orphan recovery system to run when a ghost transaction is found.

As for support: I will give a friendly reminder that donation funded explorers are being phased out, and getting the explorer sponsored will keep the CAP CCE explorer online when the donation "funded" explorers are shut down.
I have some good plans in place for 3.5, including GUI updates, market tickers and a mempool display. Though I personally do not see the value of a mempool display, people seem to want it.  

The exchange software I am writing should be going into beta testing late this week - early next week. Once I get into late second stage beta testing, I will be able to dedicate more time to CCE 3.5.

[Tranz]

Good information thanks. The July 4th roll back took us all by surprise, especially after the fork had been in place for 5 or 6 hours with no issues.  But so far it has been pretty smooth sailing since then, so that is good.

Thanks for the diligent effort with the explorer.  Let us know the best way we can support you.

The database has been reconstructed and went live late last night. After looking a bit at the code, I remember that I did not program the system to go into orphan recovery when a "ghost" transaction was found. I wanted to make sure the orphan correction system worked well in production with the check range, before allowing the system to correct deep changes when a reorganization occurred beyond the check range. The issue has come up so infrequently, that it kind of slipped my mind.  
Since system has worked well to date, in the next patch,  I will add the ability for the orphan recovery system to run when a ghost transaction is found.

As for support: I will give a friendly reminder that donation funded explorers are being phased out, and getting the explorer sponsored will keep the CAP CCE explorer online when the donation "funded" explorers are shut down.
I have some good plans in place for 3.5, including GUI updates, market tickers and a mempool display. Though I personally do not see the value of a mempool display, people seem to want it.  

The exchange software I am writing should be going into beta testing late this week - early next week. Once I get into late second stage beta testing, I will be able to dedicate more time to CCE 3.5.

Can you explain just a bit about how the explorer would be sponsored? Like x price for x months type deal?

Cool deal about the exchange, I check it out once it is live.

Good luck.

[Zer0Sum]

Excited about this!! Getting sick of cryptsy!  I can personally say that coin-swap is legit and has been very professional and quick to reply to any support requests.... compared to waiting for days to hear from phoebe at cryptsy.

No kidding. Moving trades over.

However, 0.5% trade fee, which is higher than Cryptsy at 0.25%.

Thank you Lord, I staked for 1st time... then again 19 minutes later.

------------------------------------------------------------------

I'm not sure if people realize exchange = business... it's not hobby or public service.

So if you are doing 10-15 BTC/day in total volume ($30/day in fees)...
That is not in any way a viable business...
So either they get volume up to around 500 BTC/day...
Or they have to cheat... or get hacked... or disappear.

A panhandler that sleeps in a dumpster can gross $30/day.

http://www.cryptocoincharts.info/v2/markets/info

[dnp]

i'm running the v2.1.0.0 wallet and it wont synch past block 502467 (july 19th) with "7 connections"
been trying for over a day now.

[Tranz]

i'm running the v2.1.0.0 wallet and it wont synch past block 502467 (july 19th) with "7 connections"
been trying for over a day now.

dnp. I have not done a full sync in a while, let me try one and get back to you.
Have you done any addnodes?
How many connections are you pulling?
Have you tried to restart the client?

[dnp]

i'm running the v2.1.0.0 wallet and it wont synch past block 502467 (july 19th) with "7 connections"
been trying for over a day now.

dnp. I have not done a full sync in a while, let me try one and get back to you.
Have you done any addnodes?
How many connections are you pulling?
Have you tried to restart the client?

anywhere from 7-12 connections.
no config file, so no addnodes.
i restarted the client a few times.
the last time around (when i posted the above) i deleted peers.dat and started the client and have left it running.
currently at 12 connections, and still stuck on july 19th.

[Tranz]

i'm running the v2.1.0.0 wallet and it wont synch past block 502467 (july 19th) with "7 connections"
been trying for over a day now.

dnp. I have not done a full sync in a while, let me try one and get back to you.
Have you done any addnodes?
How many connections are you pulling?
Have you tried to restart the client?

anywhere from 7-12 connections.
no config file, so no addnodes.
i restarted the client a few times.
the last time around (when i posted the above) i deleted peers.dat and started the client and have left it running.
currently at 12 connections, and still stuck on july 19th.

Just completed a full sync, no issues. From zero to current in about 5 hours.

Do you see anything relevant in you debug.log?

[dnp]

i'm running the v2.1.0.0 wallet and it wont synch past block 502467 (july 19th) with "7 connections"
been trying for over a day now.

dnp. I have not done a full sync in a while, let me try one and get back to you.
Have you done any addnodes?
How many connections are you pulling?
Have you tried to restart the client?

anywhere from 7-12 connections.
no config file, so no addnodes.
i restarted the client a few times.
the last time around (when i posted the above) i deleted peers.dat and started the client and have left it running.
currently at 12 connections, and still stuck on july 19th.

Just completed a full sync, no issues. From zero to current in about 5 hours.

Do you see anything relevant in you debug.log?

relevant? *shrug*

here are the current last few lines of the log:
--------------
[bunch of log text edited out -- now no longer relevant]