That’s very interesting, I thought there would be enough space for many more motions in the coinbase string. In your case you of course can easily fix it by just removing the votes that already have passed.
In general there are two (obvious) approaches to support more hashes:
Increase the allowed block size or use smaller hashes
It would be nice to hear from someone with access to the code what the current limitations in terms of hashes roughly is, instead of relying on your exhaustive attempt to reverse engineer it.
Its not about the blockchain, too large blocks get rejected very early before clients even look into them. A synchronized client perfectly knows which motion has passed and could internally avoid writing passed motions into the voting even though the user might have specified them in the GUI.
Furthermore, when the client finds a block, and adds the coinbase string and the staking transaction, it should immediately recognize that this block is too large (the block actually should never get broadcasted because the client should know that nobody will accept it). This at least should trigger a visible error to the user.
OK I wanted to point you to code, but github doesn’t let us search in forked repositories right now
Anyway, the staking transaction is a transaction to yourself with a certain UTXO containing at least 10k NSR and a negative transaction fee of -40 NSR (since you will get the block, this will give you a block reward of 40 NSR). The more coin are contained in the UTXO, the more likely they meet the target in the kernel function [EDIT: I think coin age is not in the equation here in Nu, but I’m not 100% sure].
A transaction itself is implemented using a (not very powerful) scripting language. Internally this is just a stack of bytes (8 bit units) and describes a set of commands that have to be executed by the client.
However, in the coinbase transaction, the script does not need to obey any rules and you can dump anything into it you want. In Bitcoin large mining pools usually add a identifier here. Nu uses it to store a byte string that represents a voting.
In the end each element in the script buffer increases the block size by 1 byte ( + overhead).
EDIT: If you open the file “blk0001.dat”, which you will find in the folder of every bitcoin clone, with a hex editor you can see all the coinbase strings that were used in the corresponding blockchain. On linux you can just run the tool strings on this file.
First of all, you got duplicate minting error (while this has nothing to do with duplicating).
Second, you put only 8 motions, 8 rates and 11 custodian votes, it seems, to get the error, which is in fact an overflow of memory space taken in the blockchain.
If Nu is successful, one can argue that we could have say simultaneously 20 motions, 20 custodian votes and 10 rates going on at the same time. Or is it exaggerated?
At least the max information inputtable at the same time should be in the documentation, imho.
I just checked the whitepaper and it actually contains a lot of information about that I didn’t recall first. So a motion is just the RIPEMD-160 hash (20 bytes), a custodial grant is the address + a uint64 (28 bytes) and park rates are an uint8 for the block height and a uint32 for the interest rate (5 byte). For @crypto_coiner’s voting posted in the OP we get
9 x 20 + 11 x 28 + 8 x 5 = 528 byte
Which is significantly smaller than 1024 bytes (but its larger than the allowed size if it for some reason gets written twice)
I did some investigations and found a limitation I was not aware of: push commands in the script system have a size limit of 520 bytes. So votes are actually limited to 520 bytes, and the vote you described above has 591 bytes.
Expanding this limit is a protocol change so it can’t be fixed until the next protocol update.
That doesn’t explain why you don’t have any error in your log though. In my experiments I got some errors. And I don’t see how this could be related to the duplicate stake errors you get.
In my case, these errors correlated and appeared at the same time as the bloat issue.
However, in other cases, I believe ppl got some duplicate stake errors without the bloat ie being prevented from minting
That is good to know, eventually.
Hope the open sourcing of the code will enable ppl to scrutinize this kind of limitations and bugs much faster and more toroughly.