[AMBER] X13 POW/POS| 10k AMBER=0,01% SHARES | BUY, HOLD & GET DIVIDENDS in BTC/$

[verycoinsuchlist]

getblockbynumber 600315
"proofhash" : "0000000075bb366a563a67411b42306397c38b0f93bd566d6deda464289a14ba"

Thanks, I'll try to re-sync again but I'm probably locked out now.

Going to leave the wallet locked as well so it won't try to stake any coins.  I'm thinking that's what caused me to fork.

EDIT - Correct DB from Nov 27 restored, but can't connect to ambercoin01.mooo.com.  Guess I'm offline for the next 24 hours.


trying connection ambercoin01.mooo.com lastseen=0.0hrs
connected ambercoin01.mooo.com
send version message: version 90001, blocks=594334, us=0.0.0.0:0, them=108.61.173.201:31982, peer=108.61.173.201:31982
socket closed
disconnecting node ambercoin01.mooo.com
trying connection ambercoin01.mooo.com lastseen=0.0hrs
connected ambercoin01.mooo.com
send version message: version 90001, blocks=594334, us=0.0.0.0:0, them=108.61.173.201:31982, peer=108.61.173.201:31982
socket closed
disconnecting node ambercoin01.mooo.com

had the same experience at some point within the last hour and drew the same conclusion... something went wrong while staking, client tried to reconnect with an invalid but however accepted block = fork and viola: node banned my client
rollback, no reconnect atm. but I'm too lazy to walk to the router to get a new ip. this certainly is an issue with the block validity check and/or pos implementation and would require some fix in the future... for now, I leave pos off, tho it's a shame as network weight is darn low, too
btw, the wallets that aren't engaged into staking are brave and sturdy and doing quite well with their one connection...
however, it was like I felt a strong disturbance in the force when suddenly zpool went back on. regarding the block time, that's when my staking wallet went to the dark side

getblockbynumber 600367

"proofhash" : "000bcdf2a47db1553cb03c563846a19fa090e38010b4352870d2b500ef1d84fe"

is that correct?

unlikely...

I'm as well going along with two wallets

getblockbynumber 600367
"proofhash" : "000000006937c4f1a22ffea48af494e3eefcdc2cf76f439ff7a420981bf9c107"

"000bcdf2a47db1553cb03c563846a19fa090e38010b4352870d2b500ef1d84fe" looks like ultra low diff, so its either a pos block while the other is a pow block, or it's a pow block with diff ~ 0.00somthing which would as well be spurious

[Slydrule]

Perhaps the ban time should be made a bit shorter.  Is 24 hours necessary?  Not only is it harsh but it is prevent us from getting in sync and getting on the correct fork.  I think even an hour is sufficient.  If a wallet reconnects and is still forked, it will just get banned again right?

What is required to change the ban time?

[Fuzzbawls]

Perhaps the ban time should be made a bit shorter.  Is 24 hours necessary?  Not only is it harsh but it is prevent us from getting in sync and getting on the correct fork.  I think even an hour is sufficient.  If a wallet reconnects and is still forked, it will just get banned again right?

What is required to change the ban time?

node operator could start with -bantime=<seconds>

[verycoinsuchlist]

Perhaps the ban time should be made a bit shorter.  Is 24 hours necessary?  Not only is it harsh but it is prevent us from getting in sync and getting on the correct fork.  I think even an hour is sufficient.  If a wallet reconnects and is still forked, it will just get banned again right?

What is required to change the ban time?

node operator could start with -bantime=<seconds>

that would be one option... but it actually might turn out to be pretty simple to reconnect.

so, if you happen to find yourself banned after your wallet got a hickup while staking (check for the disconnect thing as pointed out on the recent posts, see log excerpts and compare with your own logs), you might try the following:

- do a rollback to a point when the blockchain was ok, to first and foremost remove the cause of further dropped connections.
- start the client and perform a repairwallet, so your wallet doesn't reflect the mismatch it renders because it's last known bockchain was in the process of staking when it went bad.
- again restart the client, your ballance should show the correct value before it went away and the rolled back blockchain should start updating, as the node is accepting you again.
(I also changed the 'port' option to some other value some steps earlier without success, but I left it changed afterwards, so I cannot be sure by a 100% that it has no effect... it might be one option to try additionally, the blockchain rollback plus repairwallet however are the most important steps.)


so, it's certainly not just the ip that is used to check if the client has or has not been banned

I think it should be stressed that the 'repairwallet' step really is important... especially if you want to perform a transaction... I had some unspendable marked coins, that were tumbling in the twilight zone of the transaction cache, available yet unspendable, schroedingers coins if you will xD
...and as we are at it... wallet backups turn out to be very important, too

[AmberCoinDev]

Perhaps the ban time should be made a bit shorter.  Is 24 hours necessary?  Not only is it harsh but it is prevent us from getting in sync and getting on the correct fork.  I think even an hour is sufficient.  If a wallet reconnects and is still forked, it will just get banned again right?

What is required to change the ban time?

node operator could start with -bantime=<seconds>

Is "-bantime=60" worth to try on main node?

[Fuzzbawls]

Perhaps the ban time should be made a bit shorter.  Is 24 hours necessary?  Not only is it harsh but it is prevent us from getting in sync and getting on the correct fork.  I think even an hour is sufficient.  If a wallet reconnects and is still forked, it will just get banned again right?

What is required to change the ban time?

node operator could start with -bantime=<seconds>

Is "-bantime=60" worth to try on main node?

way too short imho...with all the individual forking going on, a bantime that short will just lead to the node being bombarded with invalid chain data. People really do need time to react to a ban manually in this situation so even an hour may be ineffective unless someone is monitoring their client on a regular basis.

[Bannedseller]

Round #1 (0.02$   or  8200 satoshi):   4,000,000 - SOLD OUT
Round #2 (0.025$   or  10400 satoshi):   500,000 - SOLD OUT
Round #3 (0.03$   or  12500 satoshi):   500,000 - SOLD OUT
Round #4 (0.04$   or  14600 satoshi):   500,000 - SOLD OUT
Round #5 (0.045$   or  16700 satoshi):   250,000 - SOLD OUT
Round #6 (0.05$   or  21000 satoshi):   250,000 - SOLD OUT
Round #7 (0.06$   or  21000 satoshi):   250,000 - SOLD OUT
Round #8 (0.07$   or  21400 satoshi):   250,000 - SOLD OUT
Round #9 (0.08$   or  23500 satoshi):   250,000 - SOLD OUT

>>>   Round #10 (0.09$ or 25750 satoshi):   sold 73,323 out of 250,000  <<<[/center]

Isn't it be round 11 as mentioned earlier?

SPECIFICATIONS

Algo: X13
Abbreviation: AMBER
Max number of coins ( Including POS phase) : 50,000,000
Timing of block (in seconds) : 60
Difficulty Retarget every block
Total POW: 49,000,000 coins
Block number when POW ends : 2,000,000
POS interest per year : 25%
Min stake age : 6 hours
Max stake age : 30 days

Isn't the max coins be 49M and interest be 7% as of now?

AmberCoin.conf

server=1
daemon=1
listen=1
rpcuser=user
rpcpassword=pass
rpcport=31981
addnode=108.61.173.201
addnode=104.238.177.80
addnode=45.32.69.218
addnode=188.163.90.183
addnode=88.198.100.148
addnode=45.55.140.160
addnode=144.76.238.2
addnode=134.249.144.169
addnode=24.18.171.156
addnode=71.195.24.21
addnode=173.177.224.169
addnode=85.25.214.214
addnode=176.9.165.51
addnode=70.83.130.225
addnode=77.239.40.238
addnode=37.59.21.58
addnode=86.174.112.113
addnode=71.180.153.230
addnode=104.131.230.130

Please update the ambercoin.conf with the latest nodes.

BTW does my coins staked before block 585000 safe (not affected by the recent forks)?

[bathrobehero]

We need more nodes that are only connected to the main node and connect to each other one at a time with maxconnections=2, 3, etc.

[Fuzzbawls]

We need more nodes that are only connected to the main node and connect to each other one at a time with maxconnections=2, 3, etc.

yeah, more stable, secure, and reliable nodes that can manage to agree with each other is a good plan. everyone connecting to just one node will never really see the problem solved

[AmberCoinDev]

We need more nodes that are only connected to the main node and connect to each other one at a time with maxconnections=2, 3, etc.

We have 2 more nodes which currently are connected to first one.
Should they to be connected to each other only?
Or they should allow 2,3 additional connections?

Edit: should it look like that? :

Node02:

Code:

./AmberCoind -connect=ambercoin01.mooo.com  -connect=ambercoin03.mooo.com

Node03:

Code:

./AmberCoind -connect=ambercoin01.mooo.com  -connect=ambercoin02.mooo.com

[bathrobehero]

We need more nodes that are only connected to the main node and connect to each other one at a time with maxconnections=2, 3, etc.

We have 2 more nodes which currently are connected to first one.
Should they to be connected to each other only?
Or they should allow 2,3 additional connections?

Edit: should it look like that? :

Node02:

Code:

./AmberCoind -connect=ambercoin01.mooo.com  -connect=ambercoin03.mooo.com

Node03:

Code:

./AmberCoind -connect=ambercoin01.mooo.com  -connect=ambercoin02.mooo.com

I'm not sure. The point is that each node that is only connected to ambercoin01.mooo.com should eventually be interconnected while blocking nodes with the old walelt and nodes on the wrong fork. It should probably solve itself if the new wallet is refusing to connect to old wallets and people abandon the bad fork(s).

[AmberCoinDev]

We need more nodes that are only connected to the main node and connect to each other one at a time with maxconnections=2, 3, etc.

We have 2 more nodes which currently are connected to first one.
Should they to be connected to each other only?
Or they should allow 2,3 additional connections?

Edit: should it look like that? :

Node02:

Code:

./AmberCoind -connect=ambercoin01.mooo.com  -connect=ambercoin03.mooo.com

Node03:

Code:

./AmberCoind -connect=ambercoin01.mooo.com  -connect=ambercoin02.mooo.com

I'm not sure. The point is that each node that is only connected to ambercoin01.mooo.com should eventually be interconnected while blocking nodes with the old walelt and nodes on the wrong fork. It should probably solve itself if the new wallet is refusing to connect to old wallets and people abandon the bad fork(s).

Old wallets are cut by "protocolversion".

Will "maxconnections=" work with "connect=" option and "listen=1"?

[lethax]

I've just started AmberCoin with the new wallet, today. It's working fine. Solo mining, now.

[crzybilly]

We need more nodes that are only connected to the main node and connect to each other one at a time with maxconnections=2, 3, etc.

We have 2 more nodes which currently are connected to first one.
Should they to be connected to each other only?
Or they should allow 2,3 additional connections?

Edit: should it look like that? :

Node02:

Code:

./AmberCoind -connect=ambercoin01.mooo.com  -connect=ambercoin03.mooo.com

Node03:

Code:

./AmberCoind -connect=ambercoin01.mooo.com  -connect=ambercoin02.mooo.com

I'm not sure. The point is that each node that is only connected to ambercoin01.mooo.com should eventually be interconnected while blocking nodes with the old walelt and nodes on the wrong fork. It should probably solve itself if the new wallet is refusing to connect to old wallets and people abandon the bad fork(s).

Old wallets are cut by "protocolversion".

Will "maxconnections=" work with "connect=" option and "listen=1"?

It's best they stay connected to the main node, so they don't cause forks... but others should connect to those nodes if they are having issues connecting to the first node.

[AmberCoinDev]

I have added to .conf on node02  such lines and restarted it.
But it still has ONLY 1 connection to main node.
And I can not connect to it from outside.

Code:

listen=1
maxconnections=5
connect=ambercoin01.mooo.com
connect=ambercoin03.mooo.com

[AmberCoinDev]

It's best they stay connected to the main node, so they don't cause forks... but others should connect to those nodes if they are having issues connecting to the first node.

How to make it in that way?

[TimC]

I have added to .conf on node02  such lines and restarted it.
But it still has ONLY 1 connection to main node.
And I can not connect to it from outside.

Code:

listen=1
maxconnections=5
connect=ambercoin01.mooo.com
connect=ambercoin03.mooo.com

if you use 'connect' you will only have one connection to that address

What you need on your nodes 'maxconnections=100' or greater

Code:

listen=1
maxconnections=100
addnode=ambercoin01.mooo.com
addnode=ambercoin03.mooo.com

this will allow 100 peers to connect to this node.

[crzybilly]

It's best they stay connected to the main node, so they don't cause forks... but others should connect to those nodes if they are having issues connecting to the first node.

How to make it in that way?

check and make sure they aren't getting banned

[AmberCoinDev]

It's best they stay connected to the main node, so they don't cause forks... but others should connect to those nodes if they are having issues connecting to the first node.

How to make it in that way?

check and make sure they aren't getting banned

ambercoin02.mooo.com now allow connections.
You can try it.

[exemplaar]

Current status: 2 active connections to Ambercoin network

.conf:
listen=0
addnode=ambercoin01.mooo.com
addnode=ambercoin02.mooo.com

getblockbynumber 601182 "proofhash" : "0000709ddf69c904205bf4e922f49d32775c9ec6d1313d72b34f9f9f4e402b5d"

it looks ok for now...