Bamboo: New crypto using ED25519 signing keys

[MMOStars]

Hi, Where can i find the miner binaries for windows ??

thnx in advance !

Don't recommend supporting such projects, the linux release was released and windows mining was not available for a long while. Pathetic for launch for a blockchain.

[danglingnullptr]

I have seen on Github that there was a hack of malicious miners that manipulate timestamps. The fix is a bit fragile because
1. https://github.com/mr-pandabear/panda-coin/blob/44875696e210e1359d109d7a08cc795209b6b2fb/src/server/blockchain.cpp#L303 depends on the server timestamp they can be out of sync especially it the project goes decentralized one day. Bitcoin uses a 2 hour tolerance I think.
2. And it uses a median rule, see https://en.bitcoin.it/wiki/Block_timestamp instead of your hard rule of strictly increasing timestamps https://github.com/mr-pandabear/panda-coin/blob/44875696e210e1359d109d7a08cc795209b6b2fb/src/server/blockchain.cpp#L301
Maybe adopt these things?
Furthermore, I spotted another bug of undefined behaviour: You cannot do C-style casts or reinterpret_casts at arbitrary addresses because of memory alignment https://stackoverflow.com/a/32590117. For example processors cannot access aligned 4 byte integer types at addresses not equal to a multiple of 4, so casting as done in
https://github.com/mr-pandabear/panda-coin/blob/44875696e210e1359d109d7a08cc795209b6b2fb/src/tools/server.cpp#L166
or https://github.com/mr-pandabear/panda-coin/blob/44875696e210e1359d109d7a08cc795209b6b2fb/src/tools/server.cpp#L184
is undefined behaviour. Such castings appear at more places in the code base.

And I was not the attacker exploiting the mining timestamp bug. I am not even mining this coin as it is not decentralized at this stage. Amazon AWS where the central servers are located (and thus the NSA) track all miners' IPs if they are not using a proxy. But it is instructive to see this project grow and I like the clean code of mrpandabaer

Furthermore

Hi, Where can i find the miner binaries for windows ??

thnx in advance !

Don't recommend supporting such projects, the linux release was released and windows mining was not available for a long while. Pathetic for launch for a blockchain.

I think every project starts only one platform in its early stage (for Bitcoin it was Windows). That's normal, not pathetic. In return for the user inconvenience you get more coins at this stage because there is less competition.

[mrpandabear]

Windows binaries are available on the github project page (https://github.com/mr-pandabear/panda-coin/)

Direct link: https://github.com/mr-pandabear/panda-coin/releases/download/v0.2-alpha/panda-coin-win-20211221.zip


@danglingnullptr ... so here is explanation of the questions you posit:

{EDIT: so the issue is that the forum messes up the array code ... the code posted in the forum has the array brackets removed it should be newA [ i ] }

I link the code in a github gist here: https://gist.github.com/mr-pandabear/2a97a1f008145d81ccb3982c71248c93


1. Why you are overwriting newA in every loop iteration?
newA is of type std::array<uint8_t,32> ... so the outer loop fills in each "stripe" of the hash, while the inner loop computes the value of the stripe. This is why it is "newA [ i ] = stripe"

2. Why does this loop have 32 rounds?
To fill in each of the 32 bytes of the output SHA256 Hash

3. Where did you define SHA256Hash& SHA256Hash::operator=( uint8_t) ? Maybe I will see it when I look at the rest of your project, but for now this means that your final hash can only have 256 different values because this is true for the variable stripe.
(See above)


The idea here is that we use the values of the vector of SHA digests to generate the value of each stripe. These SHA digests *must* be stored in memory because they are randomly accessed based on the previous value. val and nextIdx create a random pointer into the hash and the nextIdx is a function of the previously read value within the SHA hash.

You can think of the value of newA[ i ] to be a sum of a random walk over the 8 byte portions within the (large) vector of SHA256Hashes we generate.


Great catches re: Timestamp medians (didn't know that was how Bitcoin does it!)... as well as the C style casts. They are used in a few places and will need to be re-written to be portable.

[danglingnullptr]

Thank you, the questions only arised because of the messed assignment "newA = stripe" (seems like 32 times overwritten using operator SHA256Hash::operator=( uint8_t) ). A moderator merged with my second post where I had already figured out. There I say

This is a bad hash function because a good hash function should have uncorrelated and approximate random outputs. The above function will return complete 0 vectors with higher probability than other outputs because in case that initially val==0 (which is roughly in about 1/10^10 of the cases) in all iterations delta==0 and nextIdx==0 and val==0 such that stripe==0 and newA== NULL_SHA256_HASH (which satisfies even the most difficult target) is returned (which is 1/(2^256) of all possible outputs). Therefore this output occurs disproportionately more often, orders of magnitudes more often. Something similar happens for val equal to multiples of the divisors in the modulo operations because then still delta==0 and nextId==0 such that newA will have one byte repeated, i.e. for val equal to multiples of the least common multiple of  32-4 and NUM_SHA_DIGESTS, which is 7000. This means at least every 7000th input will yield an output with one byte repeated.
I would not roll out my own hash function. It can easily happen that your hash function does not scatter well in its return values such that some targets might become unmineable which will kill your blockchain. (Do you really known that it is possible that a certain number of leading zeros can be achieved as an output?). In your case it is the opposite: every 10^10 hashes you can easily have one that has complete zeros, i.e. will certainly mine the block at every difficulty.

[moderator's note: consecutive posts merged]

and this still holds true. What I'm saying is that for example every 2^32 tries the value
uint32_t val = *(uint32_t*)digests[0].data();
will be uint32_t(0) and in this case the function will return NULL_SHA256_HASH, i.e. this output will be overrepresented because NULL_SHA256_HASH should only occur every 2^256 hashes. Not only overrepresented but also will break difficulty adjustment. If blocks are mined too quickly, the difficulty adjustment cannot do something against it because if NULL_SHA256_HASH is returned it will always mine a new block even the with strictest difficulty requirement. Furthermore multiple blocks in the chain could have the same hash NULL_SHA256_HASH.

And why are you not using a RAII lock such as unique_lock or lock_guard here https://github.com/mr-pandabear/panda-coin/commit/0dd7b6a6ac266ec597da522198d395ee3d7b492a#diff-bef89388d9552fd0e9f163ac736709c197fe7888c036658069689d33f5275020R267

[mrpandabear]

Okay I absolutely see the problem perfectly now! 

[AllForOneA41]

Thanks for discord !! I see also rename on git to Bamboo does Panda can beat Doge :D:D

Hi, Where can i find the miner binaries for windows ??

thnx in advance !

Don't recommend supporting such projects, the linux release was released and windows mining was not available for a long while. Pathetic for launch for a blockchain.

Are You an Noob mate? there are a Linux VMs for Window where you can easly run new projects are you first day in crypto space ?

[Lind]

Thanks for discord !! I see also rename on git to Bamboo does Panda can beat Doge :D:D

Hi, Where can i find the miner binaries for windows ??

thnx in advance !

Don't recommend supporting such projects, the linux release was released and windows mining was not available for a long while. Pathetic for launch for a blockchain.

Are You an Noob mate? there are a Linux VMs for Window where you can easly run new projects are you first day in crypto space ?

Well the unit was Bamboo to begin with, even in the miner so...  BMB is the ticker. 

[mrpandabear]

Mainnet is now up again, everything went smoothly

If you want to run a node please try it out. We have support for Ubuntu and CentOS at the moment:
https://github.com/mr-pandabear/bamboo-utils

[danglingnullptr]

Unfortunately I have to say that this project gets fishy now. Several things destroy trust:

1. mrpandabear has broken his promise that there won't exist more than 100M coins, in fact he said in https://github.com/mr-pandabear/bamboo/blob/c9c274d2405c3e98e5095e8894ecde0b815b614d/README.md:

, which yields a total final circulation of 100M BMB

Now there will exist more than 106.6 million because he transferred previous balances and started the chain again at block 1. It is very important that there will never exist more coins than claimed.
2. No one can verify whether this transfer is correct. For transparency, one should
   a) make the previous chain public such that everyone can verify, for example as a zip file.
   b) include the last hash of the previous chain in the genesis block header's previous hash field such that it is proven that the presented previous chain was not tampered. Unfortunately, a) and b) did not happen.
3. I verified that mrpandabear created coins out of thin air, which is very disappointing. Here is the proof:
In the genesis.hpp file https://github.com/mr-pandabear/bamboo/blob/c9c274d2405c3e98e5095e8894ecde0b815b614d/src/server/genesis.hpp:

Code:

void addGenesisTransactions(Block &b) {
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("00E9826757F00E3379D7D769983F0039428AC2A2657CAE43E4"), 7055500000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("003ED0F94E04FB9AE467D712D0B86C8005BF528B5D34B5CDAA"), 2796500000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("00834DD96D6EF642B6790073D176C254B4B2384B529654E90C"), 2616500000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("000499952F5B98DDAD2F9CB9085420CB1628450236F77643AA"), 2541820000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("0074B1415B9E224724C8A17B5E2E39C7C8A310ABEAD58F4269"), 2533500000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("0003EFFB219BB4C782677BC1B036005A9884AADC7815E312BA"), 2509000000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("00D038EC8DA84703D1D4CD16B362960CA54AAE51E4A484C9E8"), 2495500000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("0017E700398C34409C213DD6977E40DE8E16E51A87F27CD988"), 2493000000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("00DE5E40E97D00A1B64EB7529F7DB89E7D5A1E857682C26250"), 2484500000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("00437E53BA063C24AC1A49FA4BB2A57CBD6EB6AE13AD29812B"), 2474500000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("0069D123253FB8C3C766622804A95781D72C5803116AD3C9F1"), 2457500000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("0049A42C07A55CADA8FEDC267E7657AADD824DB1D874E388C1"), 2450500000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("00D79306A08E1A5BA97E5C6EA182E77C1DEF6547EBB02D4416"), 2427500000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("00E31527CF3B7C8AF1D1B0EAEFB0AC2915234A4534A895DD24"), 2415000000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("0009CE8CE2619A8C392A36B9EB90897CB2968AE6DBE0FD0451"), 2256500000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("00E7F4F6B35B2B828353FA0AF95375DDF81BAC0F56B29A55C8"), 2240000000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("00A4D04A5B88E5D5A81070E2CD119568E4229F78D058633144"), 2145000000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("002049A12D5CC39C1D58B12CD6894611ED6A9DC0CABEAF41BD"), 2081500000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("00A46B35E7E1C97598B2DB8191C48854C1370F4C4975D4D86D"), 2063500000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("0089CE8E002103B40ECF45DD7550C288434DD1EDBFD90D99F3"), 1748500000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("0040B77A814E0E0DAC7178F43A829B140D25DFCBDB12A64683"), 1572000000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("00340179E56547C8228D2F5793B032171DE8C91AA5668C0B5F"), 1340999997, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("0095557B94A368FE2529D3EB33E6BF1276D175D27A4E876249"), 1325310047, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("00A33A1E6A434CBD9C53E98489D9A2E02A0BB6CF6416141381"), 1042500000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("000D96B31BC1ED85CEC7FCC7439C54AFE2663821979D646DC7"), 908960000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("003C35463F9A3D7E75784A801DFE37A9437822CC2A5CAC38A0"), 885000000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("0062050663701707233C8FFA0C2F969A1B4BCD7F526951808C"), 874000000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("00D368B6A8C88D240D43A92D05307A35588DE465B7C0DF94BB"), 824000000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("00C886980F3A31114D482ECE2D8A8C1CF835FE16563814147D"), 747999989, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("0092AA9566D3DE6146E54187F91B6ED84870D56FB98D0217D8"), 670500000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("00615126A3C7A0EEEB2DD19E630081D396BD5D1B80BFA4E5F7"), 548500000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("00098588687833782A40C1DFCFA863F5C3190F4301DFCE8DA3"), 524000000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("00DD367D49C047B1F2D4786B67718E533846AB432957C38AAF"), 356500000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("00A28BB4EDD6334D97A63ABA6EF60E5AB2E0DADCCC26306918"), 310500000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("008969DEA9270340ABE71D58717C181EB1220E977F68DA7A37"), 225500000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("008E3EE0FD84750B3268C97A96CEBCFFDED88BCA41DB2C2EEB"), 165500000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("00F5DDEBDFA303DCDBFC12F0C97602AFF4CDB615A9B45929C7"), 150000000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("0081114D47D958F2B6C5AE8F7A63C00F8C7559AAA60E2FD384"), 126000000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("00850AA6DE249ACF35639230164E075592001FD6B7B6E1D227"), 102000000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("002AE8DBAEAB076D5F88BDB73DC6FD844DC78C2C535ACA144A"), 101000000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("00B6027FE79D7364B59EECE0F425B4DFBC63421712A74B46EC"), 99000000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("00B968EED036C9EDEC1D07E767E0F3ADE705B06F130455ED66"), 94000000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("003B61AF65D2FED09EBFE65E17933FDC971010853B3B9CBE3E"), 87500000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("0024FCC5A3CEE5C847E25A960F6A3949DF2561F0D9479BE474"), 86500000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("0090B14CCB3A1DE9AD58D4784AFB9D8645E23328442D38C49A"), 85500000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("009F56D22641A07B598865A5497F125449247E36DABE464C79"), 83000000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("005403D3F3CAE6820FA13695D8891826CCE0C368C80D5BD1A5"), 76000000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("005FC69F59C0D179D7F89DC643178957DEE6152FD1EC9F4EE5"), 65900000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("00B28B48A25AFFBF80122963F2CB7957571AE2612B0126BF0D"), 62500000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("00288D23F3219B77DF332645C0378766023306EF9C7873DE8E"), 62000000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("00B304C18FC109BA8F9BC7B888F0255BF8D8DF61DBF2422F00"), 56500000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("00A1EA31E833383634E1A18162E89AAEBF933C8EE9D43C8093"), 47500000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("0006221CD3645BA006C153EDB5B1D7DA34BC45A03AA207FA12"), 43824507, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("00C1639A6B204EEF08B737D2AA5878ACCFA001B3755CE50B33"), 42000000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("0076FFF46D89146495C43BC6E8BFA94BB8F5619A95419B15A9"), 36000000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("00BDCB7E9F4D90DA6FD92ADA494DE72001B9AE79DD4564F265"), 33000000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("00FC60ABABF0A2D278F1669BC2376FC7092A720B0D69143CC7"), 30500000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("0035191220AB8C16D11525A70064BFDC973CEDB4E6573501DC"), 24500000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("007F1B0A28351269B341F9942848C71ED43C5EA302C28734A7"), 24000000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("0025043A4DDD629425B7353C5FC5A4BC3C698BEF26580ABD4D"), 19500000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("00C6036D01FF40900D6924A8EEF12382952C63700C42826A69"), 19500000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("0007E1BB3C1B85281AB42BC86E851B055EF2C50E0F3F0C529B"), 19500000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("00E0B9D8E7C6D643331EB7CD116F1C77A9D01697489AA323F5"), 16000000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("002645B783D84D79B398866006994E91F76069F7C30538658F"), 13500000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("005A12B59868CCAA9C0DFC1B9E8A7003D7517DF75A03F9BE6E"), 13500000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("00F37273AE040BE8B911B438F60B331563CAFADB0DC2457C13"), 12500000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("00541AC2AB6EE552B9A5C721C64A59B55CBFBCD6B371B5F12B"), 11000000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("0073DD2958990A7D7EDDA6FA455C787986091CC91CB649463A"), 11000000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("0038339C95AE62901F1C2A81510E14B01487E62CCBD4982DD0"), 11000000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("00F8DC5BD1A68FDDF1B410791DFF22B637262F716479735108"), 11000000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("0095B122957B6353EE66F0230500D7079C63C88B237F9085BE"), 9000000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("00DEEBA031BBF39FAFC3EFBFDEC6ACDBC1F278BF6282AEDFD7"), 8000000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("00FDD9CF8ABC2E9147FBEC5FB2E4A83677660F1DD01D816280"), 6500000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("001BD86ECA961597AA9C5905AF6192D375A88B0F72D576574D"), 6500000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("009D80EE0F1A802C3A713E84E92060549E5C5DD1A773E7FDCB"), 6000000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("00AFBE7F1F1B3725BCB60B24165FC3A56A6844E5874B603B43"), 5500000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("00537B5A6D62BFBAC9CC03C6DABEC089D7DD624DD614FC1D77"), 5500000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("001AAE6EA3E0BB5115C6AA55348F29D56415982B31842EFA2C"), 5000000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("00E18F9B6BB1A0B947C23D023F3A41AB8DA8126A2D5686972B"), 5000000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("00ADB00B563C112F6ADD73775F93FCD13AB65CB9CFDE67FF02"), 5000000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("0009D39E34BFC00CF4747C2FA410029A3348A9D7A736DB83FB"), 4500000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("0003AC1436F083A9FE1574E991B6E52C507AE351F803AEECDB"), 4000000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("0091E0E2141F661A55B81ACE97CC299FF918A11B9AA3E0FB88"), 4000000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("00803F09D2D6C4F32072A04434B11D6AD75D36A4F5C340BA04"), 3000000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("006FC530AEEC0EEC8965148B5C28BC6335EB5D1916B9E3FF0B"), 2500000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("0030DEF022CE9FAB1FDADE1A08A98F64D1BE2E8D92B6818426"), 2000000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("001A9493BDC70A9A3981BA921482C58FD34B4FE8934FCCE20B"), 1500000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("00FEE017AEB0A0CE19EBC4D19FE77A875A54AB7F7156C119CF"), 1000000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("00CFBEA8019F4BBD7811BABDD05553825C1144DD080840A4E1"), 1000000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("008B9453983F79616C7113623B97FE6BC1717B3DD267D8A3B8"), 500000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("0088F3F3B90D55B0AAC72511EBE856CB467ED5F3D1293E9ABD"), 500000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("00982CD377F2852599A5EF509A4D983E52A1488503E9A31872"), 500000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("0033A31CC7E9ABBB174E279AC3DF06F2D862AF87F7C8608769"), 500000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("00AF9FAE89447B47D542FDC1AFA772DF263712DD79F0CE5D67"), 500000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("0098A8E20EC73F00124958E69801D3196340042E01DD9D3D95"), 500000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("00C82D5092E8D7D8339F650704C35C7A090358B95667C677BB"), 500000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("001573FC0EE22B7416A1DCED7A4F27009E7FC18FE3C86FA50D"), 500000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("00EFF6FF40314D9220A0A3437868022547F777D93597691FAD"), 500000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("007B864FFFB370432C366BD28254DAE7E61F35D60A1AC705FD"), 500000, NULL_KEY, 0, 0));
	b.addTransaction(Transaction(NULL_ADDRESS, stringToWalletAddress("0066ED5DBC6C0BEAC820656DCA50BC424678A3698DA833DD1F"), 3953, NULL_KEY, 0, 0));
}

Why do so many accounts have such special numbers? 11000000 = 1100 BMB appears four times, why do people stop mining when the have exactly this number of BMB? This looks like prepared accounts, look at the amounts. If there are reserved community accounts this should be made clear in advance. It is not legit to silently prepare such accounts without telling people.

The balances sum up to 66474818493 which is 6647481.8493 BMB. But mrpandabear says on discord that the fork is at block 125990

Hey everyone. We are going to do the fork tonight. I recommend everyone currently mining STOP (you won't earn anything after block 125990 on the fork),[...]

In accordance to the readme.md file the reward is 50 BMB for every of the 125990 blocks:

Code:

uint32_t BlockChain::getCurrentMiningFee() {
    if (this->numBlocks < 1000000) {
        return BMB(50.0);
    } else if (this->numBlocks < 2000000) {
        return BMB(25.0);
    }  else if (this->numBlocks < 4000000) {
        return BMB(12.5);
    } else {
        return BMB(0.0);
    }
}

So there cannot exist more than 50*125990=6299500 BMB at block 125990. So I ask: Where do the 6647481.8493-6299500 = 347981.8493 BMB come from??? He just added them to some of the accounts and we can't verify. These BMB should not exist.
________________
Edit:
I want to think that mrpandabear is honest so I try to explain the issues:
Maybe 1. is just a mistake and this can be fixed by declaring that the block count starts with a higher number to compensate for the already mined number of coins.
2. Should really be done. a) Could you please give us the previous chain as zip? b) Very sad that the previous last hash was not included in the restarted chain.
3. Maybe the imbalance is due to a previous restart where you preserved peoples' balances in the genesis block (see 1., you should always forward the initial block count appropriately when you start with a premined genesis block and 2a) provide the old chain and 2b) include the previous chain's last hash in the previous hash header field of the new genesis block).

BUT: I cannot understand why the total number of coins is not a multiple of 50 BMB. Something must be wrong here, no matter how often you copied people's balances into the new genesis block. Coins are not destroyed, only transferred. And the account balances look like prepared. You can just write any balance here and we should be able to verify (Please do 2.).

I hope and want to believe that all this is just a mistake and not on purpose.

[Salamande]

Newest version of miner show 0 Net hash rate?

[mrpandabear]

Thanks for the questions -- I'll try to answer clearly.

-- 1. you are correct that there will be ~106.6M BMB minted, not 100M as originally promised. This is because old balances from two forks have been added. The first fork happened at block 7750 (which I believe is also discussed in this thread)... this accounts for an additional 388,750BMB ... I carried through those balances to the second fork. README.md has been updated to reflect this fact.

-- 2. There is no desire to obfuscate the fact that these additional balances are added. It is my fault that I did not update the README.md on github ... in fact the headerfile you mentioned is there precisely for purpose of transparency...I could have just left it out of the codebase as the chain just reads "genesis.json". There is no desire to hide anything -- there is a very clear "genesis.json" file that is used as the genesis block. These decisions to preserve accounts is made because community members sacrificed their hardware early on to stress test things on a codebase that we know is very young. You can also see the code for generating the new genesis block commented out here:
https://github.com/mr-pandabear/bamboo/blob/master/src/server/blockchain.cpp#L127

-- 3. There was some sloppiness in how the transfer was done. There are a lot of test transactions that were done for amounts < 1/1000 BMB all from my accounts. You can see these in src/tools/simulate.cpp ... some of these accounts were discarded or merged to prevent too many dummy accounts.
https://github.com/mr-pandabear/bamboo/blob/master/src/tools/simulate.cpp

All in all I would have preferred *NOT* to carry through folks accounts in the codebase as it is sloppy but that would not be fair to those early testers who used their hardware.

The first versions of the chain was all hosted on single EC2 boxes and was not truly distributed... now we have made it so that anyone can run a node and the project can grow, in fact many such nodes are running today. With community run nodes we will no longer be doing these types of sloppy updates.

http://ec2-34-218-176-84.us-west-2.compute.amazonaws.com/


Also the fork balances are computed at block 125,180 *NOT* 125,990. I will be the first to admit that this is some sloppiness and bad communication on my part. The file used to generate the genesis block can be found here on Google Drive. Each line is a JSON blob of the block:
https://drive.google.com/file/d/1GCkDhYJNCy5OBFaVDdAjohqqwW8izmrF/view?usp=sharing

** I encourage you all to explore this data in depth. Searching for bugs here is important so we can prevent them in the future. For example you will find a tx with value 18446744073709551615 ... this was due to an overflow bug and not included in the amounts. **

I also include a spreadsheet of all transactions != 50BMB:
https://gist.github.com/mr-pandabear/d96c08fe3d063dad9a2602175bacbfa6

As you can see there are many transactions for 5/10,000 of a BMB or less to dummy accounts for load testing. It would be excessive to preserve all of these in the genesis block creation code.

I encourage you to apply Hanlon's razor to this instance : we were sloppy in transferring balances. Some blocks towards the end of the fork were lost... transactions < 50 BMB were merged and placed into the genesis account '0095557B94A368FE2529D3EB33E6BF1276D175D27A4E876249'  because these all correspond to funds I was using for testing.

I hope this answers the questions and provide some clarity! We are still early in the project these balances are not worth anything until we can get the codebase truly distributed and grow the number of public nodes. The whole point of a cryptocurrency is that it will be physically impossible to do these sort of fork fixes once we are truly "live".

[Lind]

Newest version of miner show 0 Net hash rate?

Rebuild it, now it shows hash based on last 10 blocks averaged.

[danglingnullptr]

Sounds good, but you could account for the additional BMB by adjusting the function: the block bounds 10000000, 2000000, 4000000 could decreased by some number such that we pretend that the block count does not start at 1 but at a higher number (this is actually true because of the previously mined blocks). This way we could keep the 100 M total amount.

Code:

uint32_t BlockChain::getCurrentMiningFee() {
    if (this->numBlocks < 1000000) {
        return BMB(50.0);
    } else if (this->numBlocks < 2000000) {
        return BMB(25.0);
    }  else if (this->numBlocks < 4000000) {
        return BMB(12.5);
    } else {
        return BMB(0.0);
    }
}

I have made a short check and there are discrepancies, here are the meld screenshot for the sorted balances, I think negative numbers are due to the initial distribution. And I did not account for the overflow error transaction. Left are your genesis block values and on the right are the values I computed:
https://pasteboard.co/yVYBqPrmBlsd.png
https://pasteboard.co/27r9Dz6YMJE9.png
https://pasteboard.co/l0RGLdDvJKMa.png

But I can confirm that you genesis balances look mostly correct. I used the julia code

Code:

using JSON, DataFrames, CSV
function add(dict,account,amount)
    if !haskey(dict,account)
        dict[account]=0;
    end
    dict[account]+=amount
end

path="all.txt"
balances=Dict{String,Int128}()
lines=readlines(path);
for line = [lines[1]]
for t=JSON.parse(line)["transactions"]
add(balances,t["from"],-t["amount"])
add(balances,t["to"],t["amount"])
if t["amount"]<0
    print(t["amount"])
end
end
end

df=DataFrame(address=collect(keys(balances)), balance=collect(values(balances)))
sort!(df,[:balance],rev=true)
print(df[:,:balance])
CSV.write("balances.csv",df)

BTW there is a code formatting option in this forum that would not have messed up the code before.
If I have time I will look at the file in depth. Some XMR please

[mrpandabear]

What is your XMR address? I appreciate the efforts and discussion here and transparency is critical for the project.

I did some calculations on my end, and it turns out there is actually some BMB missing:
6647750   Expected ( (125180+7750) * 50)
6647481.8493 Minted in new genesis

6647750 - 6647481.8493 = 268.1507 BMB Missing

Here is code used to compute, note that I added in fees paid to miners for solving blocks. This happened only quite rarely on test transactions and for very small amounts.
https://gist.github.com/mr-pandabear/62742eb4f91b92e11f68b5c552c2a4c8

My inclination is rather than patch to correct this, we leave the system as is and accept that there will be 99,999,XXX BMB instead of 100M.


Best,

Mr. Panda

[danglingnullptr]

Thank you, my XMR address is 86Juw7yZ313E8u2nfHBqKGGLKmki3Tg41CAZjwCTgNpk2DqqAMSR2d3KEwu6evrkMQ3eLzwbEfx9thL aYud3JgC7NxTf5eM
I will have a detailed look on this. Do you also have the file of the first fork?

[mrpandabear]

I sent a small tip... TXID: eacad9737bae2c77032e6b475dfd7156a1c7dc79b3918f1ec2f3cc7f05e377a0 ... will send more later when I get a chance to buy some XMR (it is quite difficult to get).


Unfortunately the original first fork data is missing, the best I can do is provide you the generation of that genesis block here:
https://github.com/mr-pandabear/bamboo/commit/fcca96e28cc654c277433a9a14bd92ecad37d238#diff-aed855b92f4becac396ee70bea5d07170391986f0ee4c81776ea265c3d092928

[danglingnullptr]

Will do some more investigations when I have more time. Here are a few things:

1. In https://github.com/mr-pandabear/bamboo/blob/fcca96e28cc654c277433a9a14bd92ecad37d238/src/core/blockchain.cpp#L68 use `auto& pair` instead of `auto pair` because otherwise you copy while you only need a reference. Only copy small types such as ints or pointers.

2. In block 75136 of `all.txt` there are two self-addressed transactions, one of which has negative transaction amount:

Code:

julia> blocks[75136]["transactions"][1]
Dict{String, Any} with 9 entries:
  "amount"     => 1000
  "fee"        => 0
  "signature"  => "B4E285D5D8494CBA90C0B5093C5FB35DDC0FB779315536C439286F667544A1E5BFB7A2E94E…
  "id"         => 0
  "signingKey" => "79288F16DFF26D08A2426F7A0513EAE5ED680F1B5133D3CF862DEFC8D5BBCB3F"
  "to"         => "0095557B94A368FE2529D3EB33E6BF1276D175D27A4E876249"
  "from"       => "0095557B94A368FE2529D3EB33E6BF1276D175D27A4E876249"
  "timestamp"  => "1640340456"
  "nonce"      => "PN2qmWqB"

julia> blocks[75136]["transactions"][2]
Dict{String, Any} with 9 entries:
  "amount"     => -1
  "fee"        => 560968
  "signature"  => "E9EB42D190145DE95AEB5937145DABF1C1B213BD1E43FD261901D1B74DAF5058556F099047…
  "id"         => 0
  "signingKey" => "79288F16DFF26D08A2426F7A0513EAE5ED680F1B5133D3CF862DEFC8D5BBCB3F"
  "to"         => "0095557B94A368FE2529D3EB33E6BF1276D175D27A4E876249"
  "from"       => "0095557B94A368FE2529D3EB33E6BF1276D175D27A4E876249"
  "timestamp"  => "1640340618"
  "nonce"      => "PN2qmWqB"

3. For me it does not make sense to have a timestamp for transactions. How is it assigned? By the transaction creator or miner? Then it can be faked. The only half-reliable time in blockchain is the block creation time which is protected e.g. in bitcoin by the median and 2 hour rules from below and above.

4.

... will send more later when I get a chance to buy some XMR (it is quite difficult to get).

Have never tried but always found this interesting https://www.getmonero.org/2021/08/20/atomic-swaps.html?

5.

I did some calculations on my end, and it turns out there is actually some BMB missing:
6647750   Expected ( (125180+7750) * 50)
6647481.8493 Minted in new genesis

6647750 - 6647481.8493 = 268.1507 BMB Missing

Here is code used to compute, note that I added in fees paid to miners for solving blocks. This happened only quite rarely on test transactions and for very small amounts.
https://gist.github.com/mr-pandabear/62742eb4f91b92e11f68b5c552c2a4c8

My inclination is rather than patch to correct this, we leave the system as is and accept that there will be 99,999,XXX BMB instead of 100M.

To me this only shows that there are missing some coins of the additional coins that are added to 100M. So there will still be more than 100M? Or am I missing something? Do you plan to do this:

you could account for the additional BMB by adjusting the function: the block bounds 10000000, 2000000, 4000000 could decreased by some number such that we pretend that the block count does not start at 1 but at a higher number (this is actually true because of the previously mined blocks). This way we could keep the 100 M total amount.

Code:

uint32_t BlockChain::getCurrentMiningFee() {
    if (this->numBlocks < 1000000) {
        return BMB(50.0);
    } else if (this->numBlocks < 2000000) {
        return BMB(25.0);
    }  else if (this->numBlocks < 4000000) {
        return BMB(12.5);
    } else {
        return BMB(0.0);
    }
}

Then these coins will indeed be missing to 100M (if you decrease the bounds by 125180+7750).

6. Some privacy remarks: Discord is not good for privacy, you cannot use tor (they then want your phone number). Please do also announce important things here. Furthermore, if I was you I would clear my cookies and browser history more frequently to not get tracked: obviously, you and many others did not notice that the GitHub readme does not show the bamboo image anymore because you still have it in cache since you renamed the project: https://github.com/mr-pandabear/panda-website/raw/master/site/static/logo.png is no longer a valid link.

[mrpandabear]

1. Yes, some sloppiness here.
2. Self addressed transactions are not a problem ... they just equate to a no-op. Ofc, there is the potential for an attacker to flood the system with self-addressed transactions or zero-valued transactions. This edge case should be handled.

 The negative -1 transaction you showed is the one that caused a faulty tx of sz 2^64 that I ignored during the fork. The ledger was never updated but the block was not rejected so it was a bug :/

3. Two transactions with exact same contents cannot be executed twice ... you can think of timestamp as a nonce parameter. if I want to send 2BMB twice to same recepient the signature and hash of transaction is the same unless I change the timestamp.

4. I think I used this or something similar to get Monero first time.

5. I am still not sure if I really want to mess with it. I think the cleanest solution is just to mint an additional 6.6M coins and leave it at that.

6.  I'm not so worried about Discord at the moment. BMB makes lesser claims to anonymity than something like Monero... our security guarantees are not much more than what Bitcoin offers. I agree though that if the coin gains value (which we all hope it does) ... then it will be important for those with large holdings such as early miners to remain anonymous lest they become targets for attackers. Nice catch on the repo image... yeah it was cached on my machine and I made the website repo private it broke

[danglingnullptr]

3. But then this is just a nonce and not a timestamp right? There are no rules for this value that enforce it to be approximately the timestamp, right? So it should not be called `timestamp`?
4. Impressed! So did atomic swaps work for you?
5. I would not do it, you can leave it as it is. Normally one would need to ask the holders if they are fine with this 6% inflation because the value of their cons then decrease but I think it is ok in this case. I just mentioned it because you said there are coins missing and that there would be less than 100M

and accept that there will be 99,999,XXX BMB instead of 100M.

which is not correct (I misunderstood you obviously, since you now agree that there are additional  ~6M coins)
6. My point is not that you should not use Discord but that it should not be the only channel to get news because people concerned about privacy don't want to use it but still want to follow this project.


7. https://github.com/mr-pandabear/bamboo/blob/master/src/server/executor.cpp#L202 variable `nonces` unused

8. I found a bug:

Code:

void MerkleTree::setItems(vector<Transaction>& items) {
    std::sort(items.begin(), items.end(), [](const Transaction & a, const Transaction & b) -> bool { 
        return SHA256toString(a.getHash()) > SHA256toString(b.getHash());
    });
    queue<shared_ptr<HashTree>> q;
    for(auto item : items) {
        SHA256Hash h = item.getHash();
        this->fringeNodes[h] =  make_shared<HashTree>(h);
        q.push(this->fringeNodes[h]);
    }

    if (q.size()%2 == 1) {
        auto repeat = make_shared<HashTree>(q.back()->hash);
        q.push(repeat);
    }
    
    while(q.size()>1) {
        shared_ptr<HashTree> a = q.front();
        q.pop();
        shared_ptr<HashTree> b = q.front();
        q.pop();
        shared_ptr<HashTree> root = make_shared<HashTree>(NULL_SHA256_HASH);
        root->left = a;
        root->right = b;
        a->parent = root;
        b->parent = root;
        root->hash = concatHashes(a->hash, b->hash);
        q.push(root);
    }
    this->root = q.front();
}

The while loop has a bug, think of 6 elements, after 3 iterations, 3 elements are left, then after 4 iterations 2 elements are left. But these two are in different heights, your merkle tree will look like

Code:

       x 
      / \
     x   \
    / \   \
   x   x   x
  / \ / \ / \ 
  x x x x x x

which is wrong because the overall root is the parent of elements in two different heights. You only check for odd number of leaves and correct this once for the leaves and do not correct odd numbers in later stages.

[mrpandabear]

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 I used https://unstoppableswap.net/

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.