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

[SoulSlayerPT]

The coin will die if he kills cryptsy chain..

[flound1129]

The coin will die if he kills cryptsy chain..

It deserves to die then.  Release Bottlecaps 2.0 with a longer block confirm.

[John Eden]

Last night when I checked Cryptsy wallets verns pool and Multipool all appeared to be on the same chain. The biggest pool to be on the shorter chain was Epools

[flound1129]

Last night when I checked Cryptsy wallets verns pool and Multipool all appeared to be on the same chain. The biggest pool to be on the shorter chain was Epools

My transfers and my miners' transfers are not showing up on Cryptsy, has he disabled deposits?

[eBit]

Last night when I checked Cryptsy wallets verns pool and Multipool all appeared to be on the same chain. The biggest pool to be on the shorter chain was Epools

Epools and Silverwolf combined had more hashing power than the BigVern pool, but the difficulty was higher at the BigVern chain indicating there was some other hashing power on that chain, most likely Multipool.

[StephenJH]

I sent 750 to cryptsy last night and they're still not showing...

Now the remaining coins in my wallet are showing as 'unconfirmed'. I tried dl the blockchain again.

[John Eden]

Last night when I checked Cryptsy wallets verns pool and Multipool all appeared to be on the same chain. The biggest pool to be on the shorter chain was Epools

Epools and Silverwolf combined had more hashing power than the BigVern pool, but the difficulty was higher at the BigVern chain indicating there was some other hashing power on that chain, most likely Multipool.

Yes i could verify this by the gaps in blocks found on verns pool. When multipool switched they would push the chain further ahead of the other. When the difficulty rose it would switch off and it lowered they returned.

[flound1129]

Last night when I checked Cryptsy wallets verns pool and Multipool all appeared to be on the same chain. The biggest pool to be on the shorter chain was Epools

Epools and Silverwolf combined had more hashing power than the BigVern pool, but the difficulty was higher at the BigVern chain indicating there was some other hashing power on that chain, most likely Multipool.

Yes i could verify this by the gaps in blocks found on verns pool. When multipool switched they would push the chain further ahead of the other. When the difficulty rose it would switch off and it lowered they returned.

Have the other pools checked their addnodes?  Are the addnodes in post #1 still valid?  I can only seem to connect to 2 of them.

[flound1129]

If Multipool ends up being on the chain that is kept, we will donate some CAP to the miners that were other chain to help make those miners whole.  I don't like seeing other pools' miners lose money any more than my own.

[John Eden]

Last night when I checked Cryptsy wallets verns pool and Multipool all appeared to be on the same chain. The biggest pool to be on the shorter chain was Epools

Epools and Silverwolf combined had more hashing power than the BigVern pool, but the difficulty was higher at the BigVern chain indicating there was some other hashing power on that chain, most likely Multipool.

Yes i could verify this by the gaps in blocks found on verns pool. When multipool switched they would push the chain further ahead of the other. When the difficulty rose it would switch off and it lowered they returned.

Have the other pools checked their addnodes?  Are the addnodes in post #1 still valid?  I can only seem to connect to 2 of them.

Took the nodes down temporarily. I am going to be releasing a new client with new nodes and checkpoints  I have setup to get the network back on track.

[erk]

What I proposed a an error handler for a sudden increase in hash rate in the DGC thread was:

My solution to the hash rate burst problem is simple, reject blocks that try to be added to the chain faster than a predetermined rate. So you are introducing a minimum gap between blocks.

Say a DGC miner finds a new block and want's to submit it to the block chain, the digitalcoind would check the current time against the timestamp on the newest block of the chain and if less than 15sec had elapsed, it would not submit the block.  Also the copies of digitalcoind peering, would not accept any blocks to be added to the chain unless their timestamp was at least 15 higher than the highest timestamp in their copy of the block chain, but not higher than the current time. (to avoid cheats)   For ARG you would probably make it a 25 sec minimum gap between blocks.


You would need to calculated difficulty slightly differently, it would be based on the ratio of blocks that were submitted exactly at the 15sec mark rather than the 20sec target. Some testing and tuning would be requited. 15secmin between blocks might be too long for a good difficulty calculation, perhaps 10sec.

So you would multiply the times by 3 to suit CAP since DGC is 20sec block target and CAP is 60sec.

[flound1129]

What I proposed a an error handler for a sudden increase in hash rate in the DGC thread was:

My solution to the hash rate burst problem is simple, reject blocks that try to be added to the chain faster than a predetermined rate. So you are introducing a minimum gap between blocks.

Say a DGC miner finds a new block and want's to submit it to the block chain, the digitalcoind would check the current time against the timestamp on the newest block of the chain and if less than 15sec had elapsed, it would not submit the block.  Also the copies of digitalcoind peering, would not accept any blocks to be added to the chain unless their timestamp was at least 15 higher than the highest timestamp in their copy of the block chain, but not higher than the current time. (to avoid cheats)   For ARG you would probably make it a 25 sec minimum gap between blocks.


You would need to calculated difficulty slightly differently, it would be based on the ratio of blocks that were submitted exactly at the 15sec mark rather than the 20sec target. Some testing and tuning would be requited. 15secmin between blocks might be too long for a good difficulty calculation, perhaps 10sec.

So you would multiply the times by 3 to suit CAP since DGC is 20sec block target and CAP is 60sec.

This would not be easy to implement since you can't guarantee that all nodes are going to be within 15/25/whatever seconds of each other.

[erk]

What I proposed a an error handler for a sudden increase in hash rate in the DGC thread was:

My solution to the hash rate burst problem is simple, reject blocks that try to be added to the chain faster than a predetermined rate. So you are introducing a minimum gap between blocks.

Say a DGC miner finds a new block and want's to submit it to the block chain, the digitalcoind would check the current time against the timestamp on the newest block of the chain and if less than 15sec had elapsed, it would not submit the block.  Also the copies of digitalcoind peering, would not accept any blocks to be added to the chain unless their timestamp was at least 15 higher than the highest timestamp in their copy of the block chain, but not higher than the current time. (to avoid cheats)   For ARG you would probably make it a 25 sec minimum gap between blocks.


You would need to calculated difficulty slightly differently, it would be based on the ratio of blocks that were submitted exactly at the 15sec mark rather than the 20sec target. Some testing and tuning would be requited. 15secmin between blocks might be too long for a good difficulty calculation, perhaps 10sec.

So you would multiply the times by 3 to suit CAP since DGC is 20sec block target and CAP is 60sec.

This would not be easy to implement since you can't guarantee that all nodes are going to be within 15/25/whatever seconds of each other.

If, for the faster coins, it requires the timestamps to become more accurate, that could be a useful modification too. There are no shortage of accurate Internet time sources the client could calibrate to.

[eBit]

Last night when I checked Cryptsy wallets verns pool and Multipool all appeared to be on the same chain. The biggest pool to be on the shorter chain was Epools

Epools and Silverwolf combined had more hashing power than the BigVern pool, but the difficulty was higher at the BigVern chain indicating there was some other hashing power on that chain, most likely Multipool.

Yes i could verify this by the gaps in blocks found on verns pool. When multipool switched they would push the chain further ahead of the other. When the difficulty rose it would switch off and it lowered they returned.

Have the other pools checked their addnodes?  Are the addnodes in post #1 still valid?  I can only seem to connect to 2 of them.

There was a post about a questionable node, the node subsequently removed from the original posted addnode list. addnode=69.85.86.195 If any of the pools removed this node, I'm guessing it might have been the BigVern pool. Whatever was done with this node, if anything, may not have been coordinated with the other pools and clients.

https://bitcointalk.org/index.php?topic=241445.msg2795464#msg2795464

[digitalindustry]

Feeling awesome about the lost 1100 Caps

I'm know it comes with the territory but think about what it says....

People that hold this Currency pay the price , whereas if i had of mined an sold every 50 id have been fine.

so i guess in the future I'll mine and sell mine and sell.

I guess I'm lucky i only lost 1100 ?

[John Eden]

Feeling awesome about the lost 1100 Caps

I'm know it comes with the territory but think about what it says....

People that hold this Currency pay the price , whereas if i had of mined an sold every 50 id have been fine.

so i guess in the future I'll mine and sell mine and sell.

I guess I'm lucky i only lost 1100 ?

Once its all straightened out the only coins lost will be the ones mined on the shorter chain since the fork

[digitalindustry]

Feeling awesome about the lost 1100 Caps

I'm know it comes with the territory but think about what it says....

People that hold this Currency pay the price , whereas if i had of mined an sold every 50 id have been fine.

so i guess in the future I'll mine and sell mine and sell.

I guess I'm lucky i only lost 1100 ?

Once its all straightened out the only coins lost will be the ones mined on the shorter chain since the fork

ok its good to get a response - I had these Caps in a wallet and sent it to Cryptsy , if Cryptsy was on the longest chain , they should arrive eventually ?

[John Eden]

Feeling awesome about the lost 1100 Caps

I'm know it comes with the territory but think about what it says....

People that hold this Currency pay the price , whereas if i had of mined an sold every 50 id have been fine.

so i guess in the future I'll mine and sell mine and sell.

I guess I'm lucky i only lost 1100 ?

Once its all straightened out the only coins lost will be the ones mined on the shorter chain since the fork

ok its good to get a response - I had these Caps in a wallet and sent it to Cryptsy , if Cryptsy was on the longest chain , they should arrive eventually ?

If you are on another chain than cryptsy when you sync to the same chain the tx will be processed. It will require you to redownload the chain to process all transaction again

[jonoiv]

i can remember a while back i saw a block confirmed on silverwolfs pool.  and 5 mins later the same block confirmed on bottlecaps pool!  I expected to see it become an orphan but it didn't! I didn't know enough about how mmcfe worked so i didn't question it.  the block if i remember correctly was 21090..   

what really made me suspicious was that the block was mined by user torispelling.

[Damnsammit]

The coin will die if he kills cryptsy chain..

It deserves to die then.  Release Bottlecaps 2.0 with a longer block confirm.

Agreed.

No need to keep a fucked up coin.  Re-launch.