◈◈Bitcredit ◈◈ Migrating to UniQredit◈◈

[Nik4691]

Latest builds sometime works good and sometime have to restarted several times. I am a little stubborn so at the end i win not the client

This!
But I gave up.
I transfer all my coins to bittrex because I don't trust my wallet anymore.
But the problem is serious. As more and more people interested in BITCREDIT, the need for a wallet that works in all circumstances becomes number one mission.

[thelonecrouton]

I transfer all my coins to bittrex because I don't trust my wallet anymore.

Your BCR is safe, it doesn't live in the wallet. And if you don't trust the wallet, you shouldn't be using it to send money anywhere...  

Anyway, I've removed the non-working Redeem button on the bids page for the time being as interacting programatically with the RPC code is a PITA. I can do it pretty simply via an external call to bitcredit-cli but I'm doubtful about passing privkeys out to a terminal. In the meantime, I've put some hopefully clear instructions there instead:

[Nik4691]

I transfer all my coins to bittrex because I don't trust my wallet anymore.

Your BCR is safe, it doesn't live in the wallet. And if you don't trust the wallet, you shouldn't be using it to send money anywhere... 

You're right 
I mean I don't trust myself to accidentally erase my wallet with all that changes.

[thelonecrouton]

I transfer all my coins to bittrex because I don't trust my wallet anymore.

Your BCR is safe, it doesn't live in the wallet. And if you don't trust the wallet, you shouldn't be using it to send money anywhere... 

You're right 
I mean I don't trust myself to accidentally erase my wallet with all that changes.

Backups, stored somewhere else! And dumpprivkey for any address you've got a big amount stored in, has saved me grief several times! 

[jasemoney]

will push an update in a couple of hours, effectively seal all known loopholes that are preventing payout to bids aka donations.

1) Prevents consecutive blocks from single node
2) BN node only mining.

You will use bnminingkey=XXXXXX in your config with XXX being your Banknode's address

Depending on how long it takes, i am going to try and write temporary fall back code using the current method in bidtracker.cpp. Then i will try write it from scratch using json on my own time.

bnminingkey= will be instead of banknodeaddr=, or additional one.

in addition to...lol i think by the time we are on version 0.30.20 the config file of heavy duty users could easily be twenty lines before the addnodes.

i want extremely easy but flexible customization, because each service provider/ user will have different needs and use different features in combos.

so is it the pubkey or the actual address.
also it might be helpful to put the superblock payout ammount (im assuming its fixed) somewhere on the bid page. lastly you could get super fancy and put in some graphs as higher and higher bids result in dimishing returns.
PS i got my node up, a buddy bootstraped the blocks and chainstate folder for me thanks!

[thelonecrouton]

also it might be helpful to put the superblock payout ammount (im assuming its fixed) somewhere on the bid page. lastly you could get super fancy and put in some graphs as higher and higher bids result in dimishing returns.

I'll change it to "Next 30000 BCR Superblock in..." - not sure where I'd fit any graphs in though, and anyway we wouldn't want to discourage those who really want all the BCR in that superblock...  

[dragos_bdi]

I narrowed down the problem of the wallet on windows build to the transaction list from the main page.

I need to receive an feedback from you guys that this is correct.

This https://mega.nz/#!ahcSQLoL!a-bOx_RaWZxUwGqg_biNjOtq06SJnN9eOpVcHdFSZCM  is a test wallet with transaction list update disabled.
Windows 64bit only.

Please open on various Windows versions and setups and see if he throw an error or not.

ONLY FOR TESTING PURPOSE !!!


Waiting for your feedback.
thanks !

[alganonim]

I narrowed down the problem of the wallet on windows build to the transaction list from the main page.

I need to receive an feedback from you guys that this is correct.

This https://mega.nz/#!ahcSQLoL!a-bOx_RaWZxUwGqg_biNjOtq06SJnN9eOpVcHdFSZCM  is a test wallet with transaction list update disabled.
Windows 64bit only.

Please open on various Windows versions and setups and see if he throw an error or not.

ONLY FOR TESTING PURPOSE !!!


Waiting for your feedback.
thanks !

You are the man !!! 

Finally it works on both of my previously problematic systems, with empty wallets and BNs.
So what excactly was te problem with transaction list ? Just curious.

Thanx again, will test it tomorrow on more setups.

[proletariat]

I narrowed down the problem of the wallet on windows build to the transaction list from the main page.

I need to receive an feedback from you guys that this is correct.

This https://mega.nz/#!ahcSQLoL!a-bOx_RaWZxUwGqg_biNjOtq06SJnN9eOpVcHdFSZCM  is a test wallet with transaction list update disabled.
Windows 64bit only.

Please open on various Windows versions and setups and see if he throw an error or not.

ONLY FOR TESTING PURPOSE !!!


Waiting for your feedback.
thanks !

tried again and again...... and again.... I can not make it crash 

will let it run for a bit and then try to make it crash again and report back....

[proletariat]

what's up with the localhost nodes? 34 of them

[bitcreditscc]

Some notes:

The new update is ready and has code i am reasonably sure will be enough to encourage the behavior we want, however i did not make it extremely strict... i am yet to figure out a solid implementation for the dynamic block limit, so for now users are limited from mining just two consecutive blocks.

I have to be careful that checking blocks to meet our required standard does not result in slow processing and/or excessive cpu/ram usage (we need the client to be able to run on small low powered arm devices)

Advance warning -

The switch to this type of mining will result in 1 immediate problem, the chain will slow down until hash rate adjusts to the new rule set.

It takes a few minutes for a BN to be registered across the network so if you just started your BN or it's new, wait a bit until it's visible in the bn list then start mining.

So for existing BNs if you update now and have your BN in a running state in advance you are fine. For new ones once it starts successfully, wait maybe 3 minutes.

[jasemoney]

Some notes:

The new update is ready and has code i am reasonably sure will be enough to encourage the behavior we want, however i did not make it extremely strict... i am yet to figure out a solid implementation for the dynamic block limit, so for now users are limited from mining just two consecutive blocks.

I have to be careful that checking blocks to meet our required standard does not result in slow processing and/or excessive cpu/ram usage (we need the client to be able to run on small low powered arm devices)

Advance warning -

The switch to this type of mining will result in 1 immediate problem, the chain will slow down until hash rate adjusts to the new rule set.

It takes a few minutes for a BN to be registered across the network so if you just started your BN or it's new, wait a bit until it's visible in the bn list then start mining.

So for existing BNs if you update now and have your BN in a running state in advance you are fine. For new ones once it starts successfully, wait maybe 3 minutes.

if i have setgenerate true on a banknode wallet from yesterday am i all clear?
what keeps someone from pointing lots of hash to a wallet that is a banknode (sorry this has likely been answered previously)

[bitcreditscc]

Some notes:

The new update is ready and has code i am reasonably sure will be enough to encourage the behavior we want, however i did not make it extremely strict... i am yet to figure out a solid implementation for the dynamic block limit, so for now users are limited from mining just two consecutive blocks.

I have to be careful that checking blocks to meet our required standard does not result in slow processing and/or excessive cpu/ram usage (we need the client to be able to run on small low powered arm devices)

Advance warning -

The switch to this type of mining will result in 1 immediate problem, the chain will slow down until hash rate adjusts to the new rule set.

It takes a few minutes for a BN to be registered across the network so if you just started your BN or it's new, wait a bit until it's visible in the bn list then start mining.

So for existing BNs if you update now and have your BN in a running state in advance you are fine. For new ones once it starts successfully, wait maybe 3 minutes.

if i have setgenerate true on a banknode wallet from yesterday am i all clear?
what keeps someone from pointing lots of hash to a wallet that is a banknode (sorry this has likely been answered previously)

No, you need to update and then add bnminingkey="yourkeyhere" to your conf. 

[jasemoney]

Some notes:

The new update is ready and has code i am reasonably sure will be enough to encourage the behavior we want, however i did not make it extremely strict... i am yet to figure out a solid implementation for the dynamic block limit, so for now users are limited from mining just two consecutive blocks.

I have to be careful that checking blocks to meet our required standard does not result in slow processing and/or excessive cpu/ram usage (we need the client to be able to run on small low powered arm devices)

Advance warning -

The switch to this type of mining will result in 1 immediate problem, the chain will slow down until hash rate adjusts to the new rule set.

It takes a few minutes for a BN to be registered across the network so if you just started your BN or it's new, wait a bit until it's visible in the bn list then start mining.

So for existing BNs if you update now and have your BN in a running state in advance you are fine. For new ones once it starts successfully, wait maybe 3 minutes.

if i have setgenerate true on a banknode wallet from yesterday am i all clear?
what keeps someone from pointing lots of hash to a wallet that is a banknode (sorry this has likely been answered previously)

No, you need to update and then add bnminingkey="yourkeyhere" to your conf. 

damn ill might have to get it in the morning
"yourkeyhere" same as pubkey, or "yourkeyhere" is address (i think this was answered in the last pages)
and are there compiled versions out yet

[bitcreditscc]

Some notes:

The new update is ready and has code i am reasonably sure will be enough to encourage the behavior we want, however i did not make it extremely strict... i am yet to figure out a solid implementation for the dynamic block limit, so for now users are limited from mining just two consecutive blocks.

I have to be careful that checking blocks to meet our required standard does not result in slow processing and/or excessive cpu/ram usage (we need the client to be able to run on small low powered arm devices)

Advance warning -

The switch to this type of mining will result in 1 immediate problem, the chain will slow down until hash rate adjusts to the new rule set.

It takes a few minutes for a BN to be registered across the network so if you just started your BN or it's new, wait a bit until it's visible in the bn list then start mining.

So for existing BNs if you update now and have your BN in a running state in advance you are fine. For new ones once it starts successfully, wait maybe 3 minutes.

if i have setgenerate true on a banknode wallet from yesterday am i all clear?
what keeps someone from pointing lots of hash to a wallet that is a banknode (sorry this has likely been answered previously)

No, you need to update and then add bnminingkey="yourkeyhere" to your conf. 

damn ill might have to get it in the morning
"yourkeyhere" same as pubkey, or "yourkeyhere" is address (i think this was answered in the last pages)
and are there compiled versions out yet

yourkey is your address

I'll try get a build environ, but dragos will likely beat me to the punch

[dragos_bdi]

@bitcrediscc

need your help .. i'm not a programmer 

Error:
============
QObject::connect: No such signal WalletModel::balanceChanged(CAmount,CAmount,CAmount,CAmount,CAmount,CAmount,CAmount) in qt/overviewpage.cpp:266
============

in qt/overviewpage.cpp:266
connect(model, SIGNAL(balanceChanged(CAmount,CAmount,CAmount,CAmount,CAmount,CAmount,CAmount)), this, SLOT(setBalance(CAmount,CAmount,CAmount,CAmount,CAmount,CAmount,CAmount)));

Here are 7 params

in qt/transactionview.cpp:344
connect(model, SIGNAL(balanceChanged(CAmount,CAmount,CAmount)), this, SLOT(setBalance(CAmount,CAmount,CAmount)));

Here are 3 params

in qt/walletmodel.h
// Signal that balance in wallet changed
    void balanceChanged(const CAmount& balance, const CAmount& unconfirmedBalance, const CAmount& immatureBalance);

the definition involved 3 params


ring some bells for you ?

[dragos_bdi]

@bitcrediscc

need your help .. i'm not a programmer 

Error:
============
QObject::connect: No such signal WalletModel::balanceChanged(CAmount,CAmount,CAmount,CAmount,CAmount,CAmount,CAmount) in qt/overviewpage.cpp:266
============

in qt/overviewpage.cpp:266
connect(model, SIGNAL(balanceChanged(CAmount,CAmount,CAmount,CAmount,CAmount,CAmount,CAmount)), this, SLOT(setBalance(CAmount,CAmount,CAmount,CAmount,CAmount,CAmount,CAmount)));

Here are 7 params

in qt/transactionview.cpp:344
connect(model, SIGNAL(balanceChanged(CAmount,CAmount,CAmount)), this, SLOT(setBalance(CAmount,CAmount,CAmount)));

Here are 3 params

in qt/walletmodel.h
// Signal that balance in wallet changed
    void balanceChanged(const CAmount& balance, const CAmount& unconfirmedBalance, const CAmount& immatureBalance);

the definition involved 3 params


ring some bells for you ?

also ... some times ... throw:

QObject::connect: Cannot connect (null)::textChanged(QString) to TransactionView::changedAmount(QString)

[bitcreditscc]

@bitcrediscc

need your help .. i'm not a programmer 

Error:
============
QObject::connect: No such signal WalletModel::balanceChanged(CAmount,CAmount,CAmount,CAmount,CAmount,CAmount,CAmount) in qt/overviewpage.cpp:266
============

in qt/overviewpage.cpp:266
connect(model, SIGNAL(balanceChanged(CAmount,CAmount,CAmount,CAmount,CAmount,CAmount,CAmount)), this, SLOT(setBalance(CAmount,CAmount,CAmount,CAmount,CAmount,CAmount,CAmount)));

Here are 7 params

in qt/transactionview.cpp:344
connect(model, SIGNAL(balanceChanged(CAmount,CAmount,CAmount)), this, SLOT(setBalance(CAmount,CAmount,CAmount)));

Here are 3 params

in qt/walletmodel.h
// Signal that balance in wallet changed
    void balanceChanged(const CAmount& balance, const CAmount& unconfirmedBalance, const CAmount& immatureBalance);

the definition involved 3 params


ring some bells for you ?

I think this has to do with darksend being removed likely these are remnants from that. TLC is the one who handled that, if he's too busy, i'll take a look at it anyway because i am currently mucking about in QT already.

we'll have to co-ordinate our efforts via github , it seems all three of us are working on one part or the other of qt.

[dextronomous]

hi guys,

how much meg's could should one wallet could be should be, when i start the latest not the test version, so i cannot join in on helping with transaction list update disabled version test wallet.,

i am using the 30172
banknodeprivkey= not used anyomore ?
bnminingkey=yourkeyhere  this is the same key, and going to be used from now on?

2 wallets starting makes one wallet seem to super slow down, if started after each other. if downloading blocks etc. with an existing wallet that's QUITE large, so the first started wallet makes the second start up really slow, and or won't be able to use it's buttons they won't respond, even other way around first larger wallet.dat start fast then second empty or small wallet really slow again, since 30.17.1 i got something like this..

no txindex and or reindex or debug or what ever..

guys to wich version should we update now. whats the latest. besides the test version>

[bitcreditscc]

hi guys,

how much meg's could should one wallet could be should be, when i start the latest not the test version, so i cannot join in on helping with transaction list update disabled version test wallet.,

i am using the 30172
banknodeprivkey= not used anyomore ?
bnminingkey=yourkeyhere  this is the same key, and going to be used from now on?

2 wallets starting makes one wallet seem to super slow down, if started after each other. if downloading blocks etc. with an existing wallet that's QUITE large, so the first started wallet makes the second start up really slow, and or won't be able to use it's buttons they won't respond, even other way around first larger wallet.dat start fast then second empty or small wallet really slow again, since 30.17.1 i got something like this..

no txindex and or reindex or debug or what ever..

guys to wich version should we update now. whats the latest. besides the test version>

wait for new build if you are on windows. we are now on version 0.30.17.3

Why do you need to start multiple wallets?

bnminingkey and banknodeprivkey are different things