3. Yeah, I'll make a note to rename this in the codebase. The set<string> nonce was there to originally implement a per block nonce (in fact there was no TXDB in the original version and transactions were only accepted with a particular blockID to ensure that they could not be repeated in future blocks... this design was very cumbersome as you'd have to discard and re-submit transactions if they didn't make it into a particular block. A 5 character nonce string was used to ensure a lack of repeats within a given block but removed with the introduction of the txdb). TXDB was introduced in this commit:
https://github.com/mr-pandabear/bamboo/commit/b2c09d315bdc2acb5f817755df10391f61f0cdc0#diff-70e9ec68696d98d3955ce2a5ba9954596b47e14c812d2b13ee724a2529a0a5e7
4. Yes they worked like a charm
5. My plan is to correct for the larger 6.6M but not the 268.1507 ... yes agree that the 6.6M coins were minted
6. Makes sense, will make a note to put announcements here as well. Speaking of which we released a Windows light wallet:
https://github.com/mr-pandabear/bamboo-wallet/releases/tag/v0.0.1-alpha
7. See 3.
8. I didn't feel fully confident in the Merkle tree implementation and had an itch I'd get it wrong. Luckily it seems the bug you point out just prevents verification in log(TX count) hashes ... but is enough to prevent tampering with block contents (I think?). The ideal would be to use a good open source implementation. I'll probably swap it out for this one:
https://github.com/microsoft/merklecpp
https://github.com/mr-pandabear/bamboo/commit/b2c09d315bdc2acb5f817755df10391f61f0cdc0#diff-70e9ec68696d98d3955ce2a5ba9954596b47e14c812d2b13ee724a2529a0a5e7
4. Yes they worked like a charm
5. My plan is to correct for the larger 6.6M but not the 268.1507 ... yes agree that the 6.6M coins were minted
6. Makes sense, will make a note to put announcements here as well. Speaking of which we released a Windows light wallet:
https://github.com/mr-pandabear/bamboo-wallet/releases/tag/v0.0.1-alpha
7. See 3.
8. I didn't feel fully confident in the Merkle tree implementation and had an itch I'd get it wrong. Luckily it seems the bug you point out just prevents verification in log(TX count) hashes ... but is enough to prevent tampering with block contents (I think?). The ideal would be to use a good open source implementation. I'll probably swap it out for this one:
https://github.com/microsoft/merklecpp