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

[Thrash]

So far 1.4.2 is treating me much better. I have had a consistent 15-18 connections and have not been dropping any. Keep my fingers crossed.

I think the reason the blockexplorer was unavailable for a little while was he was updating it to only include nodes above 79,700.

Mullick, thanks for all of your work on this. It looks like we are making progress.

[ISAWHIM]

So far 1.4.2 is treating me much better. I have had a consistent 15-18 connections and have not been dropping any. Keep my fingers crossed.

I think the reason the blockexplorer was unavailable for a little while was he was updating it to only include nodes above 79,700.

Mullick, thanks for all of your work on this. It looks like we are making progress.

Where are you getting 1.4.2? The links on the first post all still link to 1.4.1? I have refreshed a million times, and the only links and descriptions are for 1.4.1 still. I think he just screwed-up the title...

P.S. It's almost 01:00 here, that is when mass-genocide happens for connections... watching like a hawk again. lol. OOps... forgot it is military time 13:00 not 01:00...

[BitJohn]

We had to suspend CAPs trading until the sync and forking issue is fixed. Sad day for me. I have faith they will get it fixed as well its a good team.

[ISAWHIM]

We had to suspend CAPs trading until the sync and forking issue is fixed. Sad day for me. I have faith they will get it fixed as well its a good team.

You could still allow internal trades... since that doesn't use the wallet until deposit or withdraw...

Eg, Just inform them that deposits and withdraws are the only limitation for the coins. But they can still trade to any coin that you have listed, which is working, since you KNOW the coins you have already received are in your possession.

Just saying, that that might be a future upgrade to your system, if you implemented it, to reduce or alleviate some issues with coins that all eventually have a fork. Stopping all trades, internal and external is kind-of silly.

It is only the "newly minted coins", or "transfer-blocks" that are the issue with the exchanges. You could trade any coins already confirmed and in your possession, without any issues. (Just blocking withdrawals and deposits with a notice to those depositing and withdrawing. With a little baby-sitting, you know how to get on the right chain, and get accidental deposits which you can't control.)

[Beeker]

We had to suspend CAPs trading until the sync and forking issue is fixed. Sad day for me. I have faith they will get it fixed as well its a good team.

You could still allow internal trades... since that doesn't use the wallet until deposit or withdraw...

Eg, Just inform them that deposits and withdraws are the only limitation for the coins. But they can still trade to any coin that you have listed, which is working, since you KNOW the coins you have already received are in your possession.

Just saying, that that might be a future upgrade to your system, if you implemented it, to reduce or alleviate some issues with coins that all eventually have a fork. Stopping all trades, internal and external is kind-of silly.

It is only the "newly minted coins", or "transfer-blocks" that are the issue with the exchanges. You could trade any coins already confirmed and in your possession, without any issues. (Just blocking withdrawals and deposits with a notice to those depositing and withdrawing. With a little baby-sitting, you know how to get on the right chain, and get accidental deposits which you can't control.)

only if criptsy is on the right chain

[ISAWHIM]

only if criptsy is on the right chain

An internal trade is one that someone has already sent and been confirmed as being "on the right chain".

Unless the fork is longer than the number of confirms... but by that point, it is already too late anyways, those have already been traded and would be lost at that point. If you know there is a fork, and you know where it is... roughly... you know which coins to "not trust" that came-in beyond block-x or within x-blocks...

But if someone deposited 20000 blocks at 5000-height, and the fork is 7000+... then you can safely allow those coins to move to any internal account on an exchange. Since those coins are not physically moved in a wallet, just tracked by the database as having a new owner.

When you trade CAP for BTC on an exchange, you don't get it instantly deposited into a personal wallet. It stays in the exchanges wallet, until you decide to withdraw it to your external wallet. Then it just checks that you are the owner, and if you are, they get pushed to a block for withdraw.

Internally, issues with a wallet only impede deposits, because someone may be depositing on the wrong chain, which is not detected by the other chain. (So it can't be collected, or would be erased if it came in after the fork, from another block, or didn't come in at all.)

But internally, it doesn't matter. On an exchange. (Not to a trader, who doesn't actually withdraw, but simply exchanges CAP->BTC then uses that BTC to buy WDC... from that same exchange. Not being able to remove it to your personal wallet is simply a hinderance. That can be instantly warned, prior to exchange, if the system takes that into consideration. Not everyone "cashes-out", many just keep trading from coin to coin.)

The short solution is to temporarily raise the "confirm acceptance" for the exchange to something crazy like 10,000 confirms for deposits, and stop all withdraws. Then, inform anyone making a trade, that they will not be able to withdraw that coin, only trade for another coin, which can be withdrawn. While any pending deposits will be notified on a similar level, alerting them that pending deposits will not be available for trade, until the fork has found a resolution. Asking them not to deposit, until the fork is over, and alerting them that pending deposits may not come through, and may have to be resent, if they were sent from the wrong fork. (If sent from the wrong fork, the coins would return to the wallet of the sender, once the bad fork disappears.)

[ISAWHIM]

The one good thing that comes from an exchange stopping all exchanges of a coin... is that we get a bunch of cheap to purchase coins after they begin accepting trades again. lol...

Cheaper to buy, than to mine.

Why would you stop someone from buying something you already have in your possession? Just because coins that are not in your possession yet, can't be confirmed? That makes no sense.

That would be like walmart closing it's doors in the TV department, because 100 new TV's didn't arrive yet so they stop selling all those TV's. Even though they have 100 of that same TV sitting on the shelves, ready to sell or put on lay-away.

[Thrash]

Here is 1.4.2 More checkpoints to help you sync. Github updated as well Make sure your port is forwarded Default:7685

https://docs.google.com/file/d/0B0V-7FME2rcycmItM09wOFVvb0U/edit?usp=sharing

Please add reservebalance=1000000 to your .conf for now to prevent your client from generating proof of stake blocks until we are all on the same chain and stable

Hers is a copy of the blockchain up to about block 79500 if you are still having trouble syncing. Your connections may start low but will grow with time

https://docs.google.com/file/d/0B0V-7FME2rcyTkwyek5tdGVHRVk/edit?usp=sharing

Heres a short list of peers displaying the correct starting height

addnode=92.5.104.42
addnode=92.100.75.51
addnode=80.229.2.127
addnode=85.228.195.71
addnode=77.172.80.106
addnode=67.167.228.42
addnode=223.64.63.132
addnode=4.30.96.132
addnode=217.169.211.146
addnode=188.165.211.202
addnode=188.165.194.201
addnode=115.76.20.64
addnode=97.81.165.175
addnode=68.43.193.187
addnode=24.52.207.220
addnode=67.11.24.42
addnode=221.2.149.227
addnode=106.186.115.181
addnode=223.64.63.17
addnode=50.137.233.14
addnode=24.56.243.130
addnode=60.242.225.227
addnode=192.241.216.151
addnode=82.46.148.115

Got it from here and it is still working well.

[BitcoinFX]

Updated to BottleCaps v1.4.2 and seem to be correctly in sync currently.

addnode=80.229.2.127

gen=0
dns=1
dnsseed=1
listen=1
port=7685
maxconnections=100

Port correctly forwarded.

I've updated the download link at http://bottlecaps.cc.ai to v.1.4.2

[ISAWHIM]

Here is 1.4.2

One problem... there is no 1.4.2 yet... The title of the post says 1.4.2 but the program is only 1.4.1...

Who compiled that version? Where is the source? Why is it not listed on page 1?

Just asking before I download some strangers personal version of a program that might be a backdoor broadcasting my wallet or doing something that can't be monitored.

V1.4.1 listed on post 1 of this thread is still functioning at the moment... and indicates no-where, other than the title, there is a v1.4.2 made by the creator/manager "John Eden".

Excuse my paranoia... lol

[BitcoinFX]

Its this v1.4.2 release by mullick (i.e. the same person that posted v1.4.1). I'm guessing the OP will be updated soon enough...

Here is 1.4.2 More checkpoints to help you sync. Github updated as well Make sure your port is forwarded Default:7685

https://docs.google.com/file/d/0B0V-7FME2rcycmItM09wOFVvb0U/edit?usp=sharing

Please add reservebalance=1000000 to your .conf for now to prevent your client from generating proof of stake blocks until we are all on the same chain and stable

Hers is a copy of the blockchain up to about block 79500 if you are still having trouble syncing. Your connections may start low but will grow with time

https://docs.google.com/file/d/0B0V-7FME2rcyTkwyek5tdGVHRVk/edit?usp=sharing

...

I don't store any coins in the wallet at the static IP I posted above, so...  

[DrGoose]

ISAWHIM: Just in case you did not know, mullick is the active maintainer/developer of CAP, may be you can reduce a bit the paranoia setting

[ISAWHIM]

ISAWHIM: Just in case you did not know, mullick is the active maintainer/developer of CAP, may be you can reduce a bit the paranoia setting

No...

lol. I had to say it... it is in my nature... hope the linux versions and server versions get posted soon... those are the ones kicking us offline and rejecting us.

But now I know who Mullick is!

Now all we need is some of the other things I mentioned, to be taken care of...
- Higher diff for POS blocks, to reduce block-flooding and collisions
- Split block-chain having an archive from 0 to last-hard-coded, and one for last-hard-coded to present-height. For the purpose of ease of "rebuilding from last-hard-coded forward", as opposed to 0 to present. (Or manually by just deleting the latter half of the DB, keeping the archive portion. Better yet, a command to dumptopdatabase, or rebuildfromarchive.)
- Ability for the program to automatically remove blocks that don't match the "tallest found chain", so the new chain can be rebuilt from that fork onward... (As opposed to staying on the small chain or just crapping out, since it can't build on the last block, which does not match, obviously, to the taller forked chain hash.)
- 1 mandatory roaming connection to traverse rooms looking for anyone reporting a taller chain, to jump on that chain and rebuild the fork, at the point of the fork.
- Ability to start wallet unlocked, via startup shortcut or bat, refusing mining until the wallet is unlocked. (Eg, not relaying block data if it is locked, so we don't start mining with invalid credentials that produce invalid blocks.)

Oh, and free cookies for every 10'th block mined...

Oh, and the POS thing fixed... POS still only gives 0.01 no matter how many coins are staked, or ready to be staked. 20, 40, 60, 80, 100... all give 0.01 reward... (only seeing 10+10 = 0.01) and instantly moving coins out of stake, and the reward, as soon as they are confirmed... after 25 blocks. (I don't think that is the way it was intended to function, as per the description of how POS works.)

[mullick]

Woirked 16 hours. Came home apent another 3 getting that client to sync and get it out. Just forgot to update the main page and change version # before I pushed to github

 The pool has stayed on the correct chain and both clients I updated to 1.4.2 have stayed on the right chain. I still think the issue will be fixed once everyone gets disconnected for the old peers. If you get on the right chain and leave it peer bans will slowly be lifted and your connections will grow. Went to bed last night one had 3 connections woke up to 23 the other has maintained 20+ all nihgt

Gotta go to work again.

[ISAWHIM]

Woirked 16 hours. Came home apent another 3 getting that client to sync and get it out. Just forgot to update the main page and change version # before I pushed to github
 The pool has stayed on the correct chain and both clients I updated to 1.4.2 have stayed on the right chain
Gotta go to work again.

Thank-you by the way...

Noticed the only connections I get are still only showing as version:70000.... are they just not updated yet, or did you not change that version number internally?

[John Eden]

Woirked 16 hours. Came home apent another 3 getting that client to sync and get it out. Just forgot to update the main page and change version # before I pushed to github
 The pool has stayed on the correct chain and both clients I updated to 1.4.2 have stayed on the right chain
Gotta go to work again.

Thank-you by the way...

Noticed the only connections I get are still only showing as version:70000.... are they just not updated yet, or did you not change that version number internally?

Version 7000 is the protocol version not the wallet version. Its what is used to classify older peers before the protocol switch. There is no need to up protocol version in this release

[ISAWHIM]

Gotcha...

While you are here... can you update the 1st post...

Still says version 1.4.1 release notes... and there are two IP's mentioned... one for regular wallet setup and one for solo setup. I believe the solo setup has an old IP that is not responding... It is more near the bottom of the post. (Well, it never responds to me.)

That is my OCD kicking-in... Might want to just remove that part, about solo mining, mention it once above with the other settings, which work for solo or normal wallet operation. (Or just remember to change that, if your trusted nodes changes on a fork again. With all the connections, nodes should not need to be listed anyways. Since they are just a suggestion, and the program connects to anything that it finds in the rooms anyways.)

P.S. I noticed this version is like version 1.3... Generating a lot less POS blocks again. Did you increase the diff, and if so... is the reward or coins going to be compensated, since the diff is higher, and thus, less frequently found by all? Or is this just going to auto-balance and distribute more evenly now, as opposed to one person getting tons of POS and others getting none, due to slower connections (net lag causing stale POS submissions and rejects of POS)?

Eg, the blocks are climbing a lot slower on the chain than before. There were soooo many POS created, like 20x more than normal blocks.

[feeleep]

updated on http://cap.coinmine.pl

[mullick]

So here is where it stands.

I have done a side by side comparison of Caps and CGB code.

The only difference is the obvious chain start time ect. There are no stake changes that would cause any issues in caps that would be prevented in CGB. The amount of changes are extremely small.

I have implemented the fix Sunny King thought could be causing the issue. Compute minwork not being adjusted for ntargettimespan which has not been done in CGB or any other caps fork

Therfore it must be an issue with a previous client. 1.3 or earlier and 1.3 only contained checkpoint updates.

So I have disconnected all previous client ensured all clients were compiled from the same source ect.

Now it should only be an issue of weeding out the old clients creating the problem. The changes took effect yesterday but they are not disconnected immediately. If you had a peer running an obsolete version and on the right chain it would keep connection until you either restarted or it went off on a bad chain and got banned. If you were connected to an old client or even a new client still connected to an obsolete client when they generate a bad block it will still cause an issue

It will take time but We have been having a good streak since last night. Hopefully 1.4.2 will get everyone synced and stay on the right chain since there are no old clients generating the PoS blocks that were causing the problems left on the network really. The issue is PoS blocks are being generated and clients are giving this error "Contains too little proof of stake" some clients get past this others do not and create a seperate chain

[ISAWHIM]

So is 1.4.1 still OK to connect with, and run if it connects for us?

I really wish the POS blocks were on a separate chain. Every time a POS is found, it forces all our half-finished work to stop, and get a new hash, essentially starting the hunt for a normal POW block, which has to be built off that POS block, which is not circulating through the net fast enough.

If it was a separate chain, built off the same seed, running along side of the POW chain... except POS only having to match the hash of the "seed" and the "last hard-coded POW block"... (In addition to being valid with your signature and valid block that was staked...) Then it wouldn't matter if they were out of order, as long as they were valid, until the point where they had to move back to the POW chain as a normal TX. But that would not interfere with the POW chain that does require successive building, to prevent tampering.

Though, because POS moves too fast, with low diff... it is inevitable that many POS that are honestly earned, will be rejected due to slow distribution through the net. (Might be a little faster if it was a separate chain also, with a variable diff too.)

But that is not a tiny thing that can be changed by adjusting a setting. It would require a lot more programming to make it reality. (Just thinking out loud here, not demanding anything. )