Long wait for 210001 probably...
Topic: ◈◈Bitcredit ◈◈ Migrating to UniQredit◈◈ - page 85. (Read 284526 times)
Got a BN up and running this morning on 17.3, left it mining on 1 core, we'll see what happens @ 210000.
Long wait for 210001 probably...
Long wait for 210001 probably...
@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 ?
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 ?
overviewpage is not used any more, I just didn't feel confident enough at the time to remove it completely until the 'new overviewpage' - transactionview.cpp was shown to be working correctly.
bitcreditscc is right, IIRC I got rid of the Dasksend balances as DS isn't being used, and also some 'watch only' balances, as I had no idea what they were and they didn't seem to be needed.
The problem goes from here.
Until the code is not cleaned up, will be problems.
OK, can you delete overviewpage.cpp/overviewpage.h and remove all overviewpage lines from src/Makefile.qt.include? I'm not a programmer either...
@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 ?
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 ?
overviewpage is not used any more, I just didn't feel confident enough at the time to remove it completely until the 'new overviewpage' - transactionview.cpp was shown to be working correctly.
bitcreditscc is right, IIRC I got rid of the Dasksend balances as DS isn't being used, and also some 'watch only' balances, as I had no idea what they were and they didn't seem to be needed.
The problem goes from here.
Until the code is not cleaned up, will be problems.
@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 ?
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 ?
overviewpage is not used any more, I just didn't feel confident enough at the time to remove it completely until the 'new overviewpage' - transactionview.cpp was shown to be working correctly.
bitcreditscc is right, IIRC I got rid of the Dasksend balances as DS isn't being used, and also some 'watch only' balances, as I had no idea what they were and they didn't seem to be needed.
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>
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
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>
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>
@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 ?
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.
@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 ?
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)
@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 ?
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 ?
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.
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.
"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
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.
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.
"yourkeyhere" same as pubkey, or "yourkeyhere" is address (i think this was answered in the last pages)
and are there compiled versions out yet
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.
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.
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.
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)
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.
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.
what's up with the localhost nodes? 34 of them
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 !
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....
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 !
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.
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 !
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 !
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...
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.
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!
Jump to: