Interesting project, I will wait for the result of the development. Fingers cross. BTW is there a discord channel for Bamboo?
Telegram @ http://t.me/teampandacoin
Discord @ https://discord.gg/aFBzuKVg86
Topic: Bamboo: New crypto using ED25519 signing keys - page 6. (Read 4652 times)
Telegram @ http://t.me/teampandacoin
Discord @ https://discord.gg/aFBzuKVg86
Interesting project, I will wait for the result of the development. Fingers cross. BTW is there a discord channel for Bamboo?
I think your implementation is good but the assignment https://github.com/mr-pandabear/bamboo/blob/b2dd0f392f3be3b2db861bc450268ae88135d987/src/core/merkle_tree.cpp#L33 should replaced by a move using std::move(). The compiler won't do it automatically.
Your non-standard Merkle proofs will be shorter or equally long. When they are carefully designed, they can be tailored to your non-standard computation. But who needs Merkle proofs? Only SVP nodes right? And these nodes are not really necessary for a cryptocurrency, people can just run a full node when they are concerned about privacy or use a public block chain explorer when they are noobs.
Your non-standard Merkle proofs will be shorter or equally long. When they are carefully designed, they can be tailored to your non-standard computation. But who needs Merkle proofs? Only SVP nodes right? And these nodes are not really necessary for a cryptocurrency, people can just run a full node when they are concerned about privacy or use a public block chain explorer when they are noobs.
I re-wrote a much simpler Merkle hash computation here:
https://github.com/mr-pandabear/bamboo/blob/b2dd0f392f3be3b2db861bc450268ae88135d987/src/core/merkle_tree.cpp
So the problem we will introduce by creating a new Merkle calculation is that we will now have two hashing schemes and need to handle validating each one differently based on block number. This is a little bit ugly. I wonder how bad the construction I had earlier is in terms of the length of the proofs it would generate. If it's not that bad my inclination is to just leave it and we will have slightly non-standard Merkle proofs.
https://github.com/mr-pandabear/bamboo/blob/b2dd0f392f3be3b2db861bc450268ae88135d987/src/core/merkle_tree.cpp
So the problem we will introduce by creating a new Merkle calculation is that we will now have two hashing schemes and need to handle validating each one differently based on block number. This is a little bit ugly. I wonder how bad the construction I had earlier is in terms of the length of the proofs it would generate. If it's not that bad my inclination is to just leave it and we will have slightly non-standard Merkle proofs.
3. Maybe use Meson? I think its easier and cleaner than CMake and has -Wall -Winvalid-pch -Wnon-virtual-dtor -Wextra -Wpedantic warnings by default.
4. So there you can get XMR
5. Sounds good.
8. I would not use an open source implementation because it introduces too much bloat. It is not too difficult to implement the merkle tree. Especially since you do not need the O(log(TXs)) verification for now.
For example fill in the leaves hashes in a vector v and iterate i=0 to (length+1)/2 and put the hash of v[2i] || v[2i+2] into v taking special care to duplicate the last value in odd cases then resize to (length+1)/2. Do this until the vector length is 1. I think this should work?
Furthermore I think you don't need a tree construction with shared pointers, do you? And yes, it is correct that block contents are still protected against tampering. When correcting this please do future forks without starting the chain from scratch. Do a case distinction in the block verification that is sensitive to the block height and executes the forked verification code for specific heights.
Will do some more investigation when I have more time.
4. So there you can get XMR
5. Sounds good.
8. I would not use an open source implementation because it introduces too much bloat. It is not too difficult to implement the merkle tree. Especially since you do not need the O(log(TXs)) verification for now.
For example fill in the leaves hashes in a vector v and iterate i=0 to (length+1)/2 and put the hash of v[2i] || v[2i+2] into v taking special care to duplicate the last value in odd cases then resize to (length+1)/2. Do this until the vector length is 1. I think this should work?
Furthermore I think you don't need a tree construction with shared pointers, do you? And yes, it is correct that block contents are still protected against tampering. When correcting this please do future forks without starting the chain from scratch. Do a case distinction in the block verification that is sensitive to the block height and executes the forked verification code for specific heights.
Will do some more investigation when I have more time.
3. Yeah, I'll make a note to rename this in the codebase. The set 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.
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.
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
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:
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
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.
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
Quote
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& items) {
std::sort(items.begin(), items.end(), [](const Transaction & a, const Transaction & b) -> bool {
return SHA256toString(a.getHash()) > SHA256toString(b.getHash());
});
queue> q;
for(auto item : items) {
SHA256Hash h = item.getHash();
this->fringeNodes[h] = make_shared(h);
q.push(this->fringeNodes[h]);
}
if (q.size()%2 == 1) {
auto repeat = make_shared(q.back()->hash);
q.push(repeat);
}
while(q.size()>1) {
shared_ptr a = q.front();
q.pop();
shared_ptr b = q.front();
q.pop();
shared_ptr root = make_shared(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();
}
std::sort(items.begin(), items.end(), [](const Transaction & a, const Transaction & b) -> bool {
return SHA256toString(a.getHash()) > SHA256toString(b.getHash());
});
queue
for(auto item : items) {
SHA256Hash h = item.getHash();
this->fringeNodes[h] = make_shared
q.push(this->fringeNodes[h]);
}
if (q.size()%2 == 1) {
auto repeat = make_shared
q.push(repeat);
}
while(q.size()>1) {
shared_ptr
q.pop();
shared_ptr
q.pop();
shared_ptr
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
/ \
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.
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
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
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:
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.
5.
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.
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"
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: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.
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.
Then these coins will indeed be missing to 100M (if you decrease the bounds by 125180+7750).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);
}
}
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);
}
}
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.
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
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
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?
I will have a detailed look on this. Do you also have the file of the first fork?
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
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
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.
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
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
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);
}
}
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)
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
Newest version of miner show 0 Net hash rate?
Rebuild it, now it shows hash based on last 10 blocks averaged.
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".
-- 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".
Newest version of miner show 0 Net hash rate?
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:
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:
The balances sum up to 66474818493 which is 6647481.8493 BMB. But mrpandabear says on discord that the fork is at block 125990
________________
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.
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:
Quote
, 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.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));
}
The balances sum up to 66474818493 which is 6647481.8493 BMB. But mrpandabear says on discord that the fork is at block 125990
Quote
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. 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);
}
}
________________
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.
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
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
Thanks for discord !! I see also rename on git to Bamboo does Panda can beat Doge :D:D
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 ?
:D:DHi, Where can i find the miner binaries for windows ??
thnx in advance !
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.
Thanks for discord !! I see also rename on git to Bamboo does Panda can beat Doge :D:D
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 ?
:D:DHi, Where can i find the miner binaries for windows ??
thnx in advance !
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 ?
Jump to: