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

[chondrite]

Mine on multipool or cryptsy pools... they both have the correct chains, until you get all setup.

You may have to keep disconnecting and reconnecting, until you get the right one, or if it hangs while downloading the chain from the connections. (Deleting the peers file AFTER the client shuts-down. If you delete it before, it saves it when it does shut-down, defeating the purpose of deleting it.)

While I appreciate what you're saying, I'm not trying to mine CAPS.  I'm just trying to get my wallet connected to the main blockchain so I can move coins in and out if I wanted to.  I've been trying since an hour after 1.4.1 was released, i've reconnected and deleted the peers file dozens of times.  I never have had any problems like this with any other coin.

[1715033706]

1715033706

[1715033706]

1715033706

[1715033706]

1715033706

[mullick]

Updated download for the block chain. Copy/replace files into your appdata/roaming/BottleCaps directory

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

EDIT: Also cleared the peer list from my nodes so they should be connectable to you again

[chondrite]

Updated download for the block chain. Copy/replace files into your appdata/roaming/BottleCaps directory

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

EDIT: Also cleared the peer list from my nodes so they should be connectable to you again

Connected, thanks for updating!

[feeleep]

I think I finally managed to update http://cap.coinmine.pl to latest client and successfully download blockchain. Please send some hashes here to test current setup.

Thank you very much. Ill throw some hash there tonight. Thats one thing we need now is a few good pools

pool if off the chain again - I dont know what is happening, but windows client doesn't have such problem

[feeleep]

back on track but all mining during the night was invalid - sorry guys...

[butjust41day]

Twelve hours of staying on the right chain here...one thing I did was turn off my port forwarding limiting the number of nodes I can connect to. Started out with good nodes on the right chain and locked out those bad nodes. Seemed to help

[mullick]

Yep it seems once you get on the right chain get a good peers list you stay there. Which is looking good for tomorrow's switch

[mullick]

Looks like I managed to fork NVC P2Pool to work on CAP
My git repo: https://github.com/Rav3nPL/p2pool-rav
use "cap" branch
My 1st block: http://bottlecaps.kicks-ass.net/block_crawler.php?block_hash=00000001a43f7af2523c3d390889e916c301b79876bd323d33d32edea3c115f0

Wow that's great news Sorry I missed it

Do you have any plans of setting up one of your own?

[mullick]

back on track but all mining during the night was invalid - sorry guys...

Im watching it like a hawk

Seem to be staying on the chain

[feeleep]

back on track but all mining during the night was invalid - sorry guys...

Im watching it like a hawk

Seem to be staying on the chain

so far so good

[mullick]

Someone is really throwing some power at this solo now. Difficutly has risen 15% over the last 25-50 blocks Your pool is finding less and less % of the total blocks

[Pmalek]

What will happen with epool? It is down, will Erundook turn it back on?

And will caps need another fix or somethoing?

[rav3n_pl]

Looks like I managed to fork NVC P2Pool to work on CAP
My git repo: https://github.com/Rav3nPL/p2pool-rav
use "cap" branch
My 1st block: http://bottlecaps.kicks-ass.net/block_crawler.php?block_hash=00000001a43f7af2523c3d390889e916c301b79876bd323d33d32edea3c115f0

Wow that's great news Sorry I missed it

Do you have any plans of setting up one of your own?

It is working since I made it ;]
http://rav3n.dtdns.net:8645
Some last blocks went orphaned/block crawler not see them :/

[rav3n_pl]

Hmm im getting lots of errors in log:

Code:

connection timeout
received block 0000000011237b5d8290
ProcessBlock: ORPHAN BLOCK, prev=00000000926fcb1dcf80
trying connection 172.250.241.106:7685 lastseen=0.9hrs


******* exception encountered *******
bottlecapsd[0x81c9bcc]
bottlecapsd[0x80632e1]
bottlecapsd[0x80f336f]
bottlecapsd[0x80f3fc6]
bottlecapsd[0x811ccc1]
bottlecapsd[0x811ceae]
/usr/lib/libboost_thread.so.1.49.0(+0xb97c)[0xb76bf97c]
/lib/i386-linux-gnu/libpthread.so.0(+0x6d78)[0xb72f6d78]
/lib/i386-linux-gnu/libc.so.6(clone+0x5e)[0xb70e53de]
ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
ProcessMessage(ping, 0 bytes) FAILED
getheaders 77761 to 000000025ef15d938741
connection timeout

What is goin on? Not updated nodes banging to my ports?

edit:
ok, looks like it is p2pool messing...
in same time error in p2pool log:

Code:

2013-08-17 12:48:25.575161  Pool: 1108kH/s Stale rate: 0.0% Expected time to block: 20.4 minutes
2013-08-17 12:48:26.940773 RECV addr 01010000000000000000000000000000000000ffff5bebfe251e05
2013-08-17 12:48:26.941540 > Error handling message: (see RECV line)
2013-08-17 12:48:26.941739 > Traceback (most recent call last):
2013-08-17 12:48:26.941781 >   File "/usr/local/lib/python2.7/site-packages/twisted/internet/tcp.py", line 215, in doRead
2013-08-17 12:48:26.941855 >     return self._dataReceived(data)
2013-08-17 12:48:26.941895 >   File "/usr/local/lib/python2.7/site-packages/twisted/internet/tcp.py", line 221, in _dataReceived
2013-08-17 12:48:26.941937 >     rval = self.protocol.dataReceived(data)
2013-08-17 12:48:26.941974 >   File "/home/rav3n/p2pool-rav/p2pool/util/p2protocol.py", line 26, in dataReceived
2013-08-17 12:48:26.942019 >     self.dataReceived2(data)
2013-08-17 12:48:26.942396 >   File "/home/rav3n/p2pool-rav/p2pool/util/datachunker.py", line 40, in _DataChunker
2013-08-17 12:48:26.942500 >     wants = receiver.send(buf.get(wants))
2013-08-17 12:48:26.942589 > --- <exception caught here> ---
2013-08-17 12:48:26.942711 >   File "/home/rav3n/p2pool-rav/p2pool/util/p2protocol.py", line 54, in dataReceiver
2013-08-17 12:48:26.942820 >     self.packetReceived(command, type_.unpack(payload))
2013-08-17 12:48:26.942935 >   File "/home/rav3n/p2pool-rav/p2pool/util/pack.py", line 63, in unpack
2013-08-17 12:48:26.943145 >     obj = self._unpack(data)
2013-08-17 12:48:26.943250 >   File "/home/rav3n/p2pool-rav/p2pool/util/pack.py", line 42, in _unpack
2013-08-17 12:48:26.943392 >     obj, (data2, pos) = self.read((data, 0))
2013-08-17 12:48:26.943497 >   File "/home/rav3n/p2pool-rav/p2pool/util/pack.py", line 293, in read
2013-08-17 12:48:26.944308 >     item[key], file = type_.read(file)
2013-08-17 12:48:26.944438 >   File "/home/rav3n/p2pool-rav/p2pool/util/pack.py", line 169, in read
2013-08-17 12:48:26.944584 >     res[i], file = self.type.read(file)
2013-08-17 12:48:26.944724 >   File "/home/rav3n/p2pool-rav/p2pool/util/pack.py", line 293, in read
2013-08-17 12:48:26.944844 >     item[key], file = type_.read(file)
2013-08-17 12:48:26.944970 >   File "/home/rav3n/p2pool-rav/p2pool/util/pack.py", line 293, in read
2013-08-17 12:48:26.945179 >     item[key], file = type_.read(file)
2013-08-17 12:48:26.945321 >   File "/home/rav3n/p2pool-rav/p2pool/util/pack.py", line 228, in read
2013-08-17 12:48:26.945447 >     data, file = read(file, 16)
2013-08-17 12:48:26.945562 >   File "/home/rav3n/p2pool-rav/p2pool/util/pack.py", line 16, in read
2013-08-17 12:48:26.945679 >     raise EarlyEnd()
2013-08-17 12:48:26.945796 > p2pool.util.pack.EarlyEnd:

Have no idea it is harmless or not :/

edit2:
There is another error in daemon log, nothing in p2pool:

Code:

connect() failed after select(): Connection refused


******* exception encountered *******
bottlecapsd[0x81c9bcc]
bottlecapsd[0x80632e1]
bottlecapsd[0x80f336f]
bottlecapsd[0x80f3fc6]
bottlecapsd[0x811ccc1]
bottlecapsd[0x811ceae]
/usr/lib/libboost_thread.so.1.49.0(+0xb97c)[0xb76bf97c]
/lib/i386-linux-gnu/libpthread.so.0(+0x6d78)[0xb72f6d78]
/lib/i386-linux-gnu/libc.so.6(clone+0x5e)[0xb70e53de]
ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
ProcessMessage(ping, 0 bytes) FAILED
trying connection 23.19.50.218:7685 lastseen=1.1hrs

Odd...

[albon]

well mined all night just to find out when I got up that it had jumped to the wrong chain.
thats 200CAP I won't see again

Back on the correct one now

[rav3n_pl]

What one is correct?
My daemon says::

Code:

    "version" : "v1.4.1.0-g32a928e-caps",
    "protocolversion" : 70000,
    "walletversion" : 60000,
    "blocks" : 77775,
    "moneysupply" : 773174.66990000,
    "connections" : 13,
    "proxy" : "",
    "ip" : "91.235.254.37",
    "difficulty" : 0.31471503,
    "testnet" : false,
    "keypoololdest" : 1374085657,
    "keypoolsize" : 102,
    "paytxfee" : 0.00100000,
    "errors" : ""

Using latest git, compiled yesterday.

[leroy_k]

my client minted blocks during one of it's trips down the wrong path. I have finally got it updated on the right chain and minting blocks but the ones that were rejected still show as generated but not accepted and my balance is missing the staked coins for those blocks that were not accepted.

How do I get my coins back? Will they timeout eventually and remove the transactions that were not accepted?

[ISAWHIM]

grr... I went to sleep at 1AM (gmt -5), and just as I left, the programs all shut-down and apparently forked on a new chain.

That, or this program just hates me...

Only lost about 20 blocks, because the miner seemed to be connecting and rejecting randomly... The 16k diff on cgminer let me know something was up. lol.

Have you considered changing the POS diff to 1k (0.015), to stop massive burps of near-zero diff blocks from flooding the network. That is still an acceptable CPU diff, and would add more time between blocks.

I wasn't kidding when I said I was getting TONS of POS blocks. Just last night I believe I had found over 97 POS blocks and only 39 normal blocks. (Near the end, before I was severed from the net, by being rejected by the other miners... I had found 20 POS's in a row.)

Now, I am sitting at an uncomfortable 2 connections, out of the 25 listed... so that is a lot of connections not talking/communicating with anyone, on that list at http://bottlecaps.kicks-ass.net/block_crawler.php

[ISAWHIM]

How do I get my coins back? Will they timeout eventually and remove the transactions that were not accepted?

did you use the command -rescan, after getting on the right block-height?

They should move back, in time... once enough blocks have gotten above them, beyond the point of (Confirmed invalid) eg, the point where they should be confirmed, but the chain indicates they were not the actual blocks that were confirmed as valid.

The only thing you have to deal with, is that those coins can not be staked, while they remain pending-stake, waiting for release back to your wallet.

[ISAWHIM]

Good to see that diff back up to normal... 100K (1.53) That comforts me a lot more than what it was last night. I don't mind making less and demanding more for my efforts, since the coins are majorly undervalued by those who are trading them. They will stop selling themselves short, once people stop hoarding them and actually start spending them.

Now that the number of places to spend is growing, and hopefully this next release will address many of the connection issues that is leading to the forking issues.

I still think the best solution is to have at-least one roaming connection, of the 8 that the wallets are limited to... used to traverse the rooms, looking for higher blocks, and 1 of the 8 to look for rooms with less blocks, to alert them and deliver the higher blocks.

However, that will not do much good if you HAVE to shut-down, delete the database, restart, hope to connect to a higher chain, and then wait for the whole chain to be delivered, and then unlock and restart the miners that were running, so they can mine again, on the unlocked taller chain.

Having an archive of the "block-0 to block-last-hard-coded", in addition to "new-blocks", and having the ability to "delete invalid block from database", up to the point of the branch... to rebuild it from that point forward... would make most of these issues go away. (Except the connection issues, where people keep getting connections killed and invalid packets are being sent, or packets are being improperly read/translated, once sent.)

I would also like to mention... I see "ping" in the debug info that was posted on the last few posts...

You do realize that 90% of the world's routers do not allow or respond to pings, even if a router does, ISP's do not allow them. Pings from the internet are "suspicious", as they are usually a sign of a hacker attempt to find an open port or get a response. Internally, in an intranet, routers will allow pings, because that is how home-devices let other devices know they are alive. But ISP's block pings, inbound and outbound, and most routers block any inbound pings, only allowing internal pings to be used.

If our connections are being killed because we are not responding to pings that we never hear... then you need to remove that part of the code.

That will FORCE segregation, as it will keep only intranet (private networks), who DO respond to pings, isolated as the only valid connections. EG, If I had 10 rigs, all connected to my wallet, and 20 connections, but 10 from the net didn't respond to pings, so I sever those connections, and my 10 rigs DO respond to pings... I would end-up isolating myself from the world, only talking to my 10 rigs with running wallets, building my own chains.

You can't ask people to "allow pings" and HOPE that works. (Not only because it exposes them to hacking detection, but also because many ISP's will drop most pings, and make it a useless fix.) They should just not be used, except to determine if that connection is possibly an internal connection on an intranet, or an external connection on an internet. Nothing more.

Spitting-out a UDP packet is the correct way to test for a connection, when a TCP connection is severed. Not a PING. Though, those too can be blocked, if they contain detectable data that is not encrypted. (Eg, if an ISP doesn't want mining, and they can detect mining packets, they will block them. If the packets are encrypted, they have no real detection, and usually allow them to pass. That is what TOR and torrents now do.)