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

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?

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.

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.)

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

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...


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

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

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

Got it from here and it is still working well.

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.

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.)

only if criptsy is on the right chain

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.)

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.

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...

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.

I wasn't complaining, just making a joke about the lack of the actual 1.4.2 being listed before the title was changed. I am about 99% sure that the forum ate his post submission, and he is retyping it all up, as we post now. xD That, or he just assumed it was actually posted... and left to go back to other things.

Even with this issue, this is still the one-of-the-best coins to mine. (Opinion)

He has been working here,at least , much better than the CNC' issuer

Crossing fingers... UPDATE, UPDATE, UPDATE!

Pfft... front page still has 1.4.1... Don't update yet... That was premature... lol.

How to update 101
1: Update and compile and test all versions
2: Upload all compiled versions and source
3: Update information and links on post
4: Check that everything is correctly listed and working as links
5: Change title of post to "Update 1.4.2"

You got 1 and 5... now try 2,3 and 4.

P.S. Potential fork detected... The block-crawler just returned 0 connections again, and 0 block-height... Last time it did that, it began killing our connections, and we forked. It was severed, and now we are about to be severed, I assume, again. (Prepare for reconnection when the big-guns get severed from that list, that is where the new tallest branch will be.)

Hmm, right at noon... 12:00... Guess it will happen within the hour, when it sees us all as "misbehaving" by about 01:00 again... Time-glitch or time-hack?

ARG... lol... I was mining the last half hour on my locked wallet... that is sooo annoying... I knew I would forget that one of these times... lol.

1.4.2 ? 

These are the times/dates where the network has severed me from connection... I have no idea what the blocks are, because the wallet doesn't show that information. All times are (GMT -5)

(Last block found before being severed from 25+ conn - first block isolated on 1-2 conn, now is a ? block.)
Date: Just now connected again... after I woke-up...
Date: 8/18/2013 01:31 - 01:35
Date: 8/17/2013 16:31 - 16:34
Date: 8/17/2013 11:50 - 11:55
Date: 8/17/2013 00:53 - 00:57
Date: 8/15/2013 05:26 - ? (Stopped mining until 8/15/2013 12:51, when I could get back on any chain.)
Date: 8/15/2013 02:25 - ? (Same as above - 8/15/2013 04:55)
Date: 8/12/2013 23:41 - ? (Same as above - 8/14/2013 21:12)
Date: 8/12/2013 17:30 - ? (Same as above - 8/12/2013 20:32)

Prior to this date, I mined fine... on version 1.4.0

Note: Always eventually connecting to the chain that is listed on http://bottlecaps.kicks-ass.net/block_crawler.php using the peer-list from http://bottlecaps.kicks-ass.net/peers.php

Also note: Only version 1.4.1 connections after 8/17/2013 00:53, and POS has nothing to do with "all of us getting rejected and disconnected for misbehaving at the same time".