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

John Eden

member

Activity: 98

Merit: 10

Have you mined Bottlecaps today?

Quote from: digitalindustry on July 28, 2013, 06:52:19 PM

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

hero member

Activity: 798

Merit: 1000

‘Try to be nice’

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 ?

eBit

member

Activity: 91

Merit: 10

Quote from: flound1129 on July 28, 2013, 06:19:22 PM

Quote from: John Eden on July 28, 2013, 06:14:37 PM

Quote from: eBit on July 28, 2013, 06:03:02 PM

Quote from: John Eden on July 28, 2013, 05:46:21 PM

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://bitcointalksearch.org/topic/m.2795464

erk

hero member

Activity: 826

Merit: 500

Quote from: flound1129 on July 28, 2013, 06:36:58 PM

Quote from: erk on July 28, 2013, 06:26:03 PM

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

Quote

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.

flound1129

hero member

Activity: 938

Merit: 1000

www.multipool.us

Quote from: erk on July 28, 2013, 06:26:03 PM

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

Quote

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

hero member

Activity: 826

Merit: 500

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

Quote

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.

John Eden

member

Activity: 98

Merit: 10

Have you mined Bottlecaps today?

Quote from: flound1129 on July 28, 2013, 06:19:22 PM

Quote from: John Eden on July 28, 2013, 06:14:37 PM

Quote from: eBit on July 28, 2013, 06:03:02 PM

Quote from: John Eden on July 28, 2013, 05:46:21 PM

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.

flound1129

hero member

Activity: 938

Merit: 1000

www.multipool.us

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.

flound1129

hero member

Activity: 938

Merit: 1000

www.multipool.us

Quote from: John Eden on July 28, 2013, 06:14:37 PM

Quote from: eBit on July 28, 2013, 06:03:02 PM

Quote from: John Eden on July 28, 2013, 05:46:21 PM

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.

John Eden

member

Activity: 98

Merit: 10

Have you mined Bottlecaps today?

Quote from: eBit on July 28, 2013, 06:03:02 PM

Quote from: John Eden on July 28, 2013, 05:46:21 PM

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.

StephenJH

hero member

Activity: 1470

Merit: 521

No more Rekt and Bust

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.

eBit

member

Activity: 91

Merit: 10

Quote from: John Eden on July 28, 2013, 05:46:21 PM

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.

flound1129

hero member

Activity: 938

Merit: 1000

www.multipool.us

Quote from: John Eden on July 28, 2013, 05:46:21 PM

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?

John Eden

member

Activity: 98

Merit: 10

Have you mined Bottlecaps today?

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

hero member

Activity: 938

Merit: 1000

www.multipool.us

Quote from: SoulSlayerPT on July 28, 2013, 05:28:30 PM

The coin will die if he kills cryptsy chain..

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

SoulSlayerPT

full member

Activity: 131

Merit: 100

The coin will die if he kills cryptsy chain..

flound1129

hero member

Activity: 938

Merit: 1000

www.multipool.us

Quote from: John Eden on July 28, 2013, 04:12:38 PM

Quote from: flound1129 on July 28, 2013, 11:12:49 AM

I'd say the truth is the dev doesn't know what caused the fork.

Interesting how the finger pointing started before any investigation was done.

We do not know if it was caused directly by multipool. The timing just seemed to perfect for it not to be.

It is not any easy decision choosing the chain to be considered valid. Since the only exchanges to currently trade the coin are on the same chain as you we are going with the longer chain.

Multipool and Cryptsy are not on the same chain. If you are keeping Cryptsy's chain you are orphaning all of my miners' blocks. The chain that had the most nodes should be the one considered valid, not just the one that the exchanges happened to be using.

I predict your coin will suffer serious credibility issues if you keep the smaller chain as you will be screwing over a far greater number of miners.

Damnsammit

sr. member

Activity: 406

Merit: 250

Quote from: SoulSlayerPT on July 28, 2013, 04:53:14 PM

Well here you have a good explanation! https://en.bitcoin.it/wiki/Block_chain

If the normal chain forks, some people are working and other people on other chain, so when john decides what chain stays, the other chain coins are lost.

Got it? Wink

I think I got it... sounds like I'm going to be losing some CAPs... oh well as long as it gets fixed Tongue

Damnsammit

sr. member

Activity: 406

Merit: 250

Quote from: flound1129 on July 28, 2013, 04:51:33 PM

What I suspect happened is that Vern's pool or another pool did not have the right addnodes, but was operating fine for a while because it was well connected. Most likely, their coin daemon was restarted at some point last night, and did not fully reconnect to all the nodes or connected to a different set of nodes that was already forked. Then they continued to mine and fully confirm at least 1 block (which requires 25 confirms) before the two networks reconnected to each other. Multipool and the other pools/solo miners on the main chain had also mined 25 or more blocks.

I was reading somewhere on here that a slower block times (namely under 2 minutes) were a bad idea for crypto-coins. Is this the reason?

SoulSlayerPT

full member

Activity: 131

Merit: 100

Quote from: Damnsammit on July 28, 2013, 04:24:54 PM

Well my mind is blown. I'm too stupid to understand what a fork actually does to a coin.

I want to be involved with Bottlecaps, but I can't get the client to sync and I can no longer solo mine. I've tried a few pools and they don't seem to be stable... currently mining on the Multipool that you are saying is causing the problems...

Huh

more confusion...

Well here you have a good explanation! https://en.bitcoin.it/wiki/Block_chain

If the normal chain forks, some people are working and other people on other chain, so when john decides what chain stays, the other chain coins are lost.

Got it? Wink

Topic: Bottlecaps 2.1 UPDATE REQUIRED - HARDFORK JULY 4 2014 to 200% Annual PoS - page 198. (Read 388610 times)