◈◈Bitcredit ◈◈ Migrating to UniQredit◈◈

[bitcreditscc]

So, it seems that better peers resolved some network problems, great  better later than never

1. Logic has been changed in fees ? 7 BCR instead 8,4  for bn mining and 38 BCR instead of 6 , please correct me if I'm at least close to it, it must be more complicated than this.

2. txindex=1 must be set only for the first time when using bootstrap or set permanently in conf ? It woked for me for some time but only till I closed a wallet and started it again.

3. It doesn't matter if few people set the same local address for BN ? (for exapmple 127.0.0.1:8877)

4. Old BN address when emptied completely can be re-used or it's better to start from a new one ?

5. Still if bn miner tries to mine consecutive block and is rejected, the only way to start it again after some time is to execute setgenerate once again ?

The network is visible @ chainz now. I think all the nodes that have lower number are still syncing , anyone who has synced from start will notice that it's taking time.

2) Rewards depend on bids there is no real change except that from a 30K block, its now in every block.

3)  you can have local Bns but i advise against it if you plan to offer services.

4) you can use any address you want though if you can, use vanity gen to generate a 6BCRbnk address.

5) havent touched the mining logic in a while.

[bitcreditscc]

a lot of users are confusing themselves by looking @ debug and using debug commands in rpc. if you want to know your current block height, either use getinfo or getblockcount.

If you are using a client that does not show protocol version 70014, then yes you are on a fork, update your client.

[bitcreditscc]

Anyone running multiple peers on one node, IT WILL LAG  the client is becoming larger and more resource hungry so unless you have really good hardware and internet, one client per machine is best.

there are of course optimizations being considered , but play it safe.

[jasemoney]

looks like i got left behind on 259613.. resyncing.

[bitcreditscc]

looks like i got left behind on 259613.. resyncing.

would have preferred a copy of your debug so i can see the reason. I want to ensure that sync is simple for everyone with no need for starting again.

fresh sync has worked for me on multiple nodes in north america, UK, europe and africa. I want to try australia , south america and asia then we'll see.

[hack_]

I for one would be very interested in an android wallet.

People block height is clear as day when you look on chainz, why the headaches?

@dev new commit?

[jasemoney]

ive been looking at it wrong, seems i saw BN payouts as miner rewards. anyways I do keep getting left behind.

[bitcreditscc]

ive been looking at it wrong, seems i saw BN payouts as miner rewards. anyways I do keep getting left behind.

already working on improvements to sync, should see a version in a couple of hours, i just need to rest a bit

[bitcreditscc]

definite improvement on the sync speed, at least 50% faster any user who is building right now, can you please time your sync based of latest master branch.  please

[alganonim]

a lot of users are confusing themselves by looking @ debug and using debug commands in rpc. if you want to know your current block height, either use getinfo or getblockcount.

If you are using a client that does not show protocol version 70014, then yes you are on a fork, update your client.

So all windows wallet users should be on fork, because latest win version still uses 70013 protocol.

My ubuntu wallet started from dragos' boostrap (258881) stopped yestarday after trying again from bootstrap it stopped at 258882, only 1 block ahead, today the same after some trying, win wallet the same block.

Then I looked thru peers in wallet, only 2 peers had a higher starting block than my

addnode=176.56.238.121
addnode=45.32.235.149

91.230.123.11 at 259340 , so close

So I deleted prefered peers and left only those 2, ubuntu wallet is syncing (on win wallet it doesn't help), I'm not sure that I'm not on fork but at least syncing and basically at the same block as chainz, so what'a going on here ?

Will try the newest build now.

[jasemoney]

win wallet is linked last page by bitcreditscc for new protocol.
a bunch of nodes ended up on 258882 after the bootstrap. but the win wallet syncs past that for me anyways

well it had been. anyways 176.56.238.121:8877 is a high chain. so i added
seednode=176.56.238.121:8877
addnode=176.56.238.121:8877
connect=176.56.238.121:8877

to my conf and it started off syncing past 258882

(this forces the single connection so its not worth using longer than to get synced.) how can we get users stuck on 258882 to shut it down. can anyone confirm the nodes stuck are not any of the seed nodes?

edit:
turning off a node and back on it seems to fail block check.

2015-12-04 05:22:19 ERROR: ConnectBlock(): coinbase key detected in last 40 blocks
2015-12-04 05:22:19 Misbehaving: 176.56.238.121:8877 (0 -> 100) BAN THRESHOLD EXCEEDED
2015-12-04 05:22:19 InvalidChainFound: invalid block=0004b19fb3571639da9b4a1c327402d878bc942c89f5b81167cc96f4869a2715  height=259992  log2_work=35.947191  date=2015-12-04 05:21:38
2015-12-04 05:22:19 InvalidChainFound:  current best=00138d7b04a2e3f32291a30804c11dbb5c53acd0ffdbec3f3865d9ad20f9db84  height=259991  log2_work=35.947191  date=2015-12-04 05:20:26
2015-12-04 05:22:19 ERROR: ConnectTip(): ConnectBlock 0004b19fb3571639da9b4a1c327402d878bc942c89f5b81167cc96f4869a2715 failed
2015-12-04 05:22:19 InvalidChainFound: invalid block=0004b19fb3571639da9b4a1c327402d878bc942c89f5b81167cc96f4869a2715  height=259992  log2_work=35.947191  date=2015-12-04 05:21:38
2015-12-04 05:22:19 InvalidChainFound:  current best=00138d7b04a2e3f32291a30804c11dbb5c53acd0ffdbec3f3865d9ad20f9db84  height=259991  log2_work=35.947191  date=2015-12-04 05:20:26
2015-12-04 05:22:19 ERROR: AcceptBlockHeader : block is marked invalid
2015-12-04 05:22:19 ERROR: invalid header received

just did this on height 259885  and a different node im running at 259991 anyways it ends up banning the 1 node who has the real blockchain.

for me, if i close the wallet it stays at that block next time i open the wallet no matter how long i leave it open

[bitcreditscc]

win wallet is linked last page by bitcreditscc for new protocol.
a bunch of nodes ended up on 258882 after the bootstrap. but the win wallet syncs past that for me anyways

well it had been. anyways 176.56.238.121:8877 is a high chain. so i added
seednode=176.56.238.121:8877
addnode=176.56.238.121:8877
connect=176.56.238.121:8877

to my conf and it started off syncing past 258882

(this forces the single connection so its not worth using longer than to get synced.) how can we get users stuck on 258882 to shut it down. can anyone confirm the nodes stuck are not any of the seed nodes?

edit:
turning off a node and back on it seems to fail block check.

2015-12-04 05:22:19 ERROR: ConnectBlock(): coinbase key detected in last 40 blocks
2015-12-04 05:22:19 Misbehaving: 176.56.238.121:8877 (0 -> 100) BAN THRESHOLD EXCEEDED
2015-12-04 05:22:19 InvalidChainFound: invalid block=0004b19fb3571639da9b4a1c327402d878bc942c89f5b81167cc96f4869a2715  height=259992  log2_work=35.947191  date=2015-12-04 05:21:38
2015-12-04 05:22:19 InvalidChainFound:  current best=00138d7b04a2e3f32291a30804c11dbb5c53acd0ffdbec3f3865d9ad20f9db84  height=259991  log2_work=35.947191  date=2015-12-04 05:20:26
2015-12-04 05:22:19 ERROR: ConnectTip(): ConnectBlock 0004b19fb3571639da9b4a1c327402d878bc942c89f5b81167cc96f4869a2715 failed
2015-12-04 05:22:19 InvalidChainFound: invalid block=0004b19fb3571639da9b4a1c327402d878bc942c89f5b81167cc96f4869a2715  height=259992  log2_work=35.947191  date=2015-12-04 05:21:38
2015-12-04 05:22:19 InvalidChainFound:  current best=00138d7b04a2e3f32291a30804c11dbb5c53acd0ffdbec3f3865d9ad20f9db84  height=259991  log2_work=35.947191  date=2015-12-04 05:20:26
2015-12-04 05:22:19 ERROR: AcceptBlockHeader : block is marked invalid
2015-12-04 05:22:19 ERROR: invalid header received

just did this on height 259885  and a different node im running at 259991 anyways it ends up banning the 1 node who has the real blockchain.

for me, if i close the wallet it stays at that block next time i open the wallet no matter how long i leave it open

You likely are connecting to nodes running on an older version.

use the 176 address, the 168 and the 45

[alganonim]

Somehow I have missed link to rc win version even that I read it before

So :

176.56.238.121
168.235.88.30
45.32.235.149

are new peers ? Just found it here few hours ago, it was mentioned anywhere.

 https://github.com/bitcreditscc/bicreditsnew/commit/38704c57641ec58e2b200f1a3046a3b244ab115c


Now demo win wallet is syncing even, didn't changed anything besides those 2 peers.

[bitcreditscc]

Somehow I have missed link to rc win version even that I read it before

So :

176.56.238.121
168.235.88.30
45.32.235.149

are new peers ? Just found it here few hours ago, it was mentioned anywhere.

 https://github.com/bitcreditscc/bicreditsnew/commit/38704c57641ec58e2b200f1a3046a3b244ab115c


Now demo win wallet is syncing even, didn't changed anything besides those 2 peers.

good to know, i am now trying to get the QT to show the database so you can test out and see your raw stats on addresses. after this we will move on to testing lending messages and responses, voting and blacklisting. once we are sure, we can begin p2plending.

[bitcreditscc]

Sync, while faster than the first rc is still pretty slow than most clients, while we have a lot more going on than clones, i still think we can do better.

with everything in place, has any windows user had a crash?

[jasemoney]

just my mining crash likely related to trying to mine a block consecutively, other stuff including sync seems manageable for now.

[alganonim]

Something new for me here, some big changes in source ?  anyone can help ?

Code:

 libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `build-aux'.
libtoolize: copying file `build-aux/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `build-aux/m4'.
libtoolize: copying file `build-aux/m4/libtool.m4'
libtoolize: copying file `build-aux/m4/ltoptions.m4'
libtoolize: copying file `build-aux/m4/ltsugar.m4'
libtoolize: copying file `build-aux/m4/ltversion.m4'
libtoolize: copying file `build-aux/m4/lt~obsolete.m4'
configure.ac:10: installing 'build-aux/compile'
configure.ac:5: installing 'build-aux/config.guess'
configure.ac:5: installing 'build-aux/config.sub'
configure.ac:9: installing 'build-aux/install-sh'
configure.ac:9: installing 'build-aux/missing'
Makefile.am:45: warning: source file 'src/secp256k1.c' is in a subdirectory,
Makefile.am:45: but option 'subdir-objects' is disabled
automake: warning: possible forward-incompatibility.
automake: At least a source file is in a subdirectory, but the 'subdir-objects'
automake: automake option hasn't been enabled.  For now, the corresponding output
automake: object file(s) will be placed in the top-level directory.  However,
automake: this behaviour will change in future Automake versions: they will
automake: unconditionally cause object files to be placed in the same subdirectory
automake: of the corresponding sources.
automake: You are advised to start using 'subdir-objects' option throughout your
automake: project, to avoid future incompatibilities.
Makefile.am:62: warning: source file 'src/bench_inv.c' is in a subdirectory,
Makefile.am:62: but option 'subdir-objects' is disabled
Makefile.am:56: warning: source file 'src/bench_recover.c' is in a subdirectory,
Makefile.am:56: but option 'subdir-objects' is disabled
Makefile.am:59: warning: source file 'src/bench_sign.c' is in a subdirectory,
Makefile.am:59: but option 'subdir-objects' is disabled
Makefile.am:53: warning: source file 'src/bench_verify.c' is in a subdirectory,
Makefile.am:53: but option 'subdir-objects' is disabled
Makefile.am:70: warning: source file 'src/tests.c' is in a subdirectory,
Makefile.am:70: but option 'subdir-objects' is disabled
Makefile.am: installing 'build-aux/depcomp'
parallel-tests: installing 'build-aux/test-driver'
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `build-aux'.
libtoolize: copying file `build-aux/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `build-aux/m4'.
libtoolize: copying file `build-aux/m4/libtool.m4'
libtoolize: copying file `build-aux/m4/ltoptions.m4'
libtoolize: copying file `build-aux/m4/ltsugar.m4'
libtoolize: copying file `build-aux/m4/ltversion.m4'
libtoolize: copying file `build-aux/m4/lt~obsolete.m4'
autoheader: cannot rename /tmp/arXhQb9A/ahcvJkUa/config.hin as src/config/bitcredit-config.h.in: No such file or directory
autoreconf: /usr/bin/autoheader failed with exit status: 1
 

[tombcoin]

Didn´t get an error like this on my ubuntu.
Only thing that changed is sqlite:
sudo apt-get install sqlite3 libsqlite3-dev
Then it should work.
Try to delete the local git-rep and clone new from github.
Then try again to compile.
lg t.

[alganonim]

Didn´t get an error like this on my ubuntu.
Only thing that changed is sqlite:
sudo apt-get install sqlite3 libsqlite3-dev
Then it should work.
Try to delete the local git-rep and clone new from github.
Then try again to compile.
lg t.

No luck, I had already latest version, so tried to remove it then install again, still the same, it could stop to work after some update, found somewhere that running ./autogen.sh twice could help but not in my case, I will try later some older not updated version.

[bitcreditscc]

Didn´t get an error like this on my ubuntu.
Only thing that changed is sqlite:
sudo apt-get install sqlite3 libsqlite3-dev
Then it should work.
Try to delete the local git-rep and clone new from github.
Then try again to compile.
lg t.

No luck, I had already latest version, so tried to remove it then install again, still the same, it could stop to work after some update, found somewhere that running ./autogen.sh twice could help but not in my case, I will try later some older not updated version.

the issue is your automake/ autoconf 

you need to either re-install or make a fresh machine