What would be rationale behind that...? I mean from a technical PoV? Having 50K is all wee and fine, but the reason i used > rather than >= was at that time i assumed that one would first spin up a BN then get at least one payment to prove they are an active BN then start mining. However users can get around that by simply sending 50000.001.
How can we resolve this ?
if they send 50000.001 they cannot start a BN but can mine. (for a BN to be started it's needed a fixed 50000 transaction)
If they send 50000 they can start a BN but cannot mine until they receive a payment.
If they have more BN's and just clear the BN wallet and send all coins received to another wallet, there is a possibility that they cannot mine because they are left only with 50000 BCR transaction.
For me, does not seems alright ...
Right, thus we find the conflict. However, do we make provisions in the code for this , or should we leave this to the users' discretion? Indeed we have to have clear policy and support for various setups and options, but do the benefits of coding a solution outweigh the costs in terms of development/testing/deploy time and the additional computing required ? remember we now check for balances and consecutive keys. Already the client suffers slow downs , would the additional cost of computing be worthwhile, or should we leave it to users to understand that emptying a BN means wait for another payment before mining? In general users emptying a BN use coin control perhaos we can just add a note in the client that warns users of this ?
Hehehe, I am changing my approach to development/problem solving based on what I am learning through books and practical
