@crypto_coiner the karma protocol prohibits minting with votes for any passed motions or custodial grants. The Nu protocol sets a size maximum of just over 500 bytes, 520 to be exact, I think.
@creon maximum block size is 1MB.
The “Staked” section of the overview screen is used when a block is found and those funds have been put into a temporarily held state (for 5020 blocks). Once that time passes they are released back to the balance along with the blocks reward NSR.
Currently there is no way to view the transactions that can be used to solve a block reward, though now that we’ve open sourced and have more people with access to the code it should be straight-forward to port the code that allows the Peerunity wallet to display the “Minting” tab and related functionality.
thanks for your response. Does that mean that once I found a block, my balance (or part of it) will switch to “staking”?
Yes.
thank you!
1 Like
Up until march, I used to leave passed motion and grants in the vote list of my client. (call it lazyness)
Which we identified overflowed the maximum size of the block allocated to votes (motion, grants and parking rates).
For anybody that feels lazy, I strongly recommend to subscribe to a feed - otherwise you expose you to the risk of blocking your minting ability.
1 Like
So this would prevent shareholders from finding blocks in the event they are still voting for a motion which has recently passed or are subscribed to a data feed whereas this is the case. I know it will not have a large effect on the difficulty, as it changes very gradually, but doesn’t this effectively make it easier to pull off a 51% attack (increased likelihood of finding an adequate number of consecutive blocks by an attacker to confirm a double spend transaction)? Surely all shareholders will not be able to remove votes from the client immediately after the passage block is found.
I understand it is meant to keep the blockchain tidy, but I would like to hear more about if this results in any unintended consequences or if this concern has already been thought through and is figured negligible.
2 Likes
This was just a slightly entertaining way to say it is not nice to fill our blockchain with meaningless junk. You can, but its bad karma. At least that’s what I would like you to believe.
2 Likes
one more question regarding the staking: should I sent as many NSR to my wallet as possible in one transaction to have a higher weight or can I also have many small transactions to my wallet and the chance to find a block depends on the total of mature coins in the wallet? Maturation is 8 days, correct?
Thanks in advance!
As many as possible will do it, your client will combine as many 10k chunks as it can and will mint.
Just to add to what @willy said: Yes, the size of the UTXO increases the likelihood for it to find a block (after 10k blocks min age) but as willy said the minimal size of each UTXO has to be 10,000 NSR so the client will partition your funds in UTXOs of 10,000 NSR size.
If you want to use larger sizes you can overwrite this behavior by setting e.g. splitshareoutputs=50000 (for 50,000 NSR chunks) in the nu.conf. Note that the block reward is not weight dependent, ideally just ignore it.
Doing so would increase the chance of finding a block?
Yes this UTXO will have 5 times the chance to find a block but you only 1 instead of 5. In the end the 10,000 split is most likely what you want.
1 Like
By default when you send NSR the amount is split in chunks of 10,000 NSR. Having NSR in chunks of 10,000 is the most optimal way to find blocks. So you just have to send as many NSR as possible.
But some people (like exchanges) may change that to reduce the fee. So if you received a large amount of NSR you may want to send it back to yourself to split it. You should examine the transaction first to see whether it’s been split or not.
What happens if I have one wallet set splitshareoutputs=50000 and another wallet set splitshareoutputs=10000. When they receive fund they will split it into differently sized chunks? What if they both mint? Will the same coin mint different blocks because it is in different sized chunks in different wallets? for example 50000 nsr are received. the wallet with 10k sized chunks finds one pos block, will any coin in the other wallet be able to find pos blocks during “staked period”?
They won’t split when the funds are received, but when they are minted or sent. i.e.: you can force a split by sending shares.
Having two clients both minting on the same set of addresses (technically, transaction outputs) is setting up for a problem, due to this functionality: https://www.peercointalk.org/index.php?topic=1956.55;wap2 … the TL;DR-- at best you will get a lot of stale blocks, tying up outputs unnecessarily.
I’ll assume the 50k NSR are received as one transaction output (i.e.: they are not split)
In this example, the wallet with 10k chunks will try to mint the one output. When it’s successful, it will create a transaction with 5 outputs of 10k NSR in size.
If at the same time the splitshareoutputs=50k wallet is minting (ignoring for a moment the problem from above), and it also scores, it will create one output of 50k.
If both blocks are found and sent on the network at the same time (very likely, based on how the stake algorithm works), at best only one will win.
So both clients would have thought they ‘minted’ the singluar non-split 50k input transaction (that you received), and the 50k NSR are tied up for the coinstake period.
I know it. Please ignored it as you did for the sake of discussion.
Let’s go on. Suppose the 10k chunk wallet was chosen by the network as the block finder, the wallet splits the 50k coin in 5 10k chunks. Then the wallet with 50k chunk size will also see “its” coins sent to 5 utxos, right? That would all make sense.
That’s right. In fact in the core of the code, when a block is “found”, it basically takes the same path as if it was received from a peer. The splitting was done upstream.
i.e.: find candidate ‘stakeable’ transactions from tx outputs (whether these tx’es were from others or myself) --> generate a block, splitting outputs per whatever the config and client rules are --> mint (which is a baby Proof-of-work) --> (win! [or go back to the start]) --> “receive” the block internally (kind of like a loopback) --> validate the block & discover ‘my’ transactions --> commit to database --> announce to peers.
Meaning if you have multiple clients with the same addresses (and therefore looking for the same transactions) they will be in-synch. The client that generated the block wins.
A side note (just to share generally, many people already know) that setting reservebalance=999999999 in your .conf would allow a second client with the same addresses (perhaps loaded by importprivkey or copying the wallet) to “watch” the first client that may be minting. Apart from stale blocks, the two would have the same information. Stale blocks could impact how many coins are available, so there may be some variance there, but if minting was stopped on both clients, eventually all balances would be the same once the coin stake age on the orphan blocks expires.
if you want to only watch, just keep the watching wallet locked. no need to set reservebalance. no?