If I have a wallet on a machine, I mined a bit, and I also burned a bit, but then I import the private key of that wallet in another wallet and shut down the machine, the PoB started on the first machine will still work?
Yes.
I mean, the expected coins will come to the new wallet or never?
They will come to whatever wallet is online and contains the address which made the burn tx that “won” the burn hash for which the coins are being received.
Is there a link between a specific wallet and the PoB algorithm or it's linked only to the address that burns coins?
Only the address. Wallets are as ephemeral as mayflies, only the blockchain endures. Every unspent TXO is associated with an address. To reassign the unspent TXO to a different address (i.e. spend the coins), the appropriate privkey for the TXO's currently-associated address needs to be provided to the scripting engine so that the necessary matching hash can be computed and checked.
Mint-by-proof-of-burn coins go to the address of the “winning” burn tx:
When one burns coins, that transaction is used to calculate burn hashes. There is also a multiplier that is applied to the raw burn hash to calculate the final burn hash. The greater the amount of coins burnt by a user, the smaller the multiplier will be and the smaller the burn hashes will be. The smaller the burn hash is, the more likely the hash will meet the difficulty target (be accepted by the network as valid). Over time, the multiplier of a single burn transaction increases slowly, lowering the effectiveness of those burn hashes, acting like "decaying burnt coins". Per transaction, only 1 burn hash is needed to be calculated per ~90 seconds. The reason low power can mine this is because basically almost any machine can hash a few SHA256 hashes in ~90 seconds.
Over the total period of their expiry, burned coins will generally figure in the PoB calculations for about a year.
The wallet must be up all the time in order to receive the coins?
Yes. The client must be contributing hash to the network in order to earn rewards. The greater the number of coins staked, the greater the amount of hash required as contribution. The fewer the contributing clients, the more work the remaining contributing clients have to do in order to provide the requisite amount of total hash power designed to maintain the integrity of the public ledger.
And *that’s* why my client is permanently nailed at 100% of its allocated thread, it's completely consumed with calculating the overall staking weight - that’s how
reservebalance works, by cutting down the search space and thereby reducing the computational demand. My wallet reports over 3500 transactions in total, no wonder the GUI client is unacceptably sluggish in responding to user input. The vast majority of those txs were received by one address from which a few significant, unexpired burn txs have been made.
Creating a new wallet and importing the privkey for that address also imports the 3000+ tx history and - without a reservebalance that basically equates to “staking=no” - again the client process immediately consumes 100% of its allocated thread as it disappears into endlessly calculating the new stake weight, in order to earn more coins which arrive as transactions which then must be taken into account in the calculation of the new stake weight, in order to earn more coins ...
As the number of nodes decreases, the [number of coins received by|hash load on] the remaining clients increases.
It’s beginning to look like the network was configured around an assumption that people would overwhelmingly prefer burn hashing, not stake hashing. My GUI client is already consuming 33% of its allocated thread and there are only 250 tx in total and a balance of 1400 SLM. I set
reservebalance to 0 in order to check what kind of tx rate I’d see and that turns out to be at least
a dozen tx a day (i.e. 8 staking tx thus far today and two orphaned stakings). Just to confirm, I shut down the GUI client and fired up the headless daemon - which also consumed 33% of the thread, so the elevated CPU use is not explained by some infelicity introduced into the GUI.
With a continual stream of incoming tx, that 30% will simply increase until the total thread compute capacity is reached and then
the engine will start to fall behind. It's an issue for some PoS coins - Sprouts (a PPCoin clone with a codebase not too dissimilar to Slimcoin's) was recently delisted by Cryptopia because their wallet was crashing “30 times a day”, a condition apparently local to them and not reported by anyone else. There is some evidence to suggest that the exchange was staking the coins in the deposit wallet, which could well explain the particularly acute problem they were experiencing.
The Slimcoin address which I used to have in my local GUI client is now being curated by my remote server, a faster m/c, where it only consumes 5% of its allocated thread.
I’m tempted to consider this as a consequence of the basic design tradeoff entailed by PoS in the constraining of hash work calculations to the thread in which the app is executing - in PoW coins, hash work calculations are performed by recruiting additional compute power from a separate spawned thread, leaving the app's ability to respond to user input unimpaired.
Fortunately, Slimcoin’s mint-by-proof-of-burn offers a compute-friendly alternative: if your client is thrashing then don’t stake, burn.
Each to his own, ofc.
Cheers
Graham
