 Show Posts
|
|
Pages: [1]
|
This pull/36 looks good I just have some comments: 1. https://github.com/mr-pandabear/bamboo/pull/36/files#diff-eae33aa8c4451ec780de10579fcb2ea0e24eb73f51d763a644d80269796e5e16R13-R34 There should be functions that a) allocate a temporary b) memcpy into it c) advance the cursor automatically by the correct number of bytes (take char& argument and advance it) d) return the temporary This way, everything will get cleaner, just write such functions for uint8_t, uint16_t, uint32_t uint64_t. 2. Where is htonll defined (64 bit version). Didn't now about it, I thought the 64 bit version does not exist and one has to use be64toh? 3. The bounds checks such as https://github.com/mr-pandabear/bamboo/pull/36/files#diff-b82141a62c41308dc177b35e12e9aedcea86c92d94ddc96e7c35570b0499c4a3R176 are error-prone, I would really use exceptions directly in the parser functions such as https://github.com/mr-pandabear/bamboo/pull/36/files#diff-77098f03ea93c1f33e959abf1779714cbf9ac364d993ef4f91877a6168ef5540R12 to check for range overflow, exceptions are not that expensive. So you would write a class containing a cursor and a buffer end and would take instances of this type as parameter of the parser by reference and advance the internal cursor and do the bounds check against the end, throwing in case of an overflow. This makes everything so much easier and cleaner. 4. https://github.com/mr-pandabear/bamboo/pull/36/files#diff-b82141a62c41308dc177b35e12e9aedcea86c92d94ddc96e7c35570b0499c4a3R176 Why are you allowing excessive bytes? I would consider it as an invalid submit if there are some more bytes at the end, i.e. if buffer.size() - sizeof(BlockHeader) % sizeof(TransactionInfo) != 0. Finally, all bytes should be consumed. |
|
|
|
Yes, received it. I will also look at these cpp files and the other blocks when I have more time. The struct memory alignment problem is not a protocol problem but a parsing problem. Please don't spoil the project with protocol buffers (msgpack is leaner and nicer but still, you don't need it, just memcpy). Just memcpy POD-wise with fixed-size data types into a temporary and copy from that instead of reinterpret_cast<>ing. Then it will be fine. I don't know atm if you did that but don't cast or memcpy large objects because then alignment of member variables matters. Do it for every data type individually: memcpy uint64_t, uint32_t and such things and use use htonl and ntohl, single bytes can be read directly (obviously, because they don't require alignment). Floats are platform dependent and are problematic. I would write serialization and parsing functions for your data types (or use msgpack if you don't want to do it by hand) For example instead of https://github.com/mr-pandabear/bamboo/blob/1ac855ff08db053d5fe10803ec60f86f1227351d/src/core/block.cpp#L48you would add a serialization function and a parsing function for https://github.com/mr-pandabear/bamboo/blob/1ac855ff08db053d5fe10803ec60f86f1227351d/src/core/block.hpp#L11-L19by overloading a stream operator for serializing the member types and write a corresponding parser. You would have to write a cursor class that does bound checking and throws in case of bound violations. It is some work but it would play out nicely in the end. Or you just use messagepack (or protocol buffers if you really want to but I don't it). It depends on the number of objects you want to serialize and on the time you want to spend.
1. Unsafe reinterpret_cast conversion https://github.com/mr-pandabear/bamboo/blob/1ac855ff08db053d5fe10803ec60f86f1227351d/src/core/api.cpp#L118 Maybe define another type which stores headers as byte sequence with getters? Then you can just initialize them with memcpy. These things need to be done ASAP. 2. No need for lambda callback https://github.com/mr-pandabear/bamboo/blob/1ac855ff08db053d5fe10803ec60f86f1227351d/src/core/header_chain.cpp#L52 since this already happens in a separate thread, the value vector can be returned by the function instead of being a void function. Or better return failure and return the other values by modifying a reference but don't use a lambda. 3. Special attention has to be payed whether the total work computation is correct. https://github.com/mr-pandabear/bamboo/blob/1ac855ff08db053d5fe10803ec60f86f1227351d/src/core/header_chain.cpp#L66 Do you have tests for this? This definitively needs some test and it needs to be wrapped into a function (which has to be tested) to be on the safe side. Instead of `totalWork+= base.pow((int)block.getDifficulty());` you need something like `totalWork.add(block.getDifficulty())` or `totalWork.add(block)` 4. Bad style: https://github.com/mr-pandabear/bamboo/blob/1ac855ff08db053d5fe10803ec60f86f1227351d/src/core/header_chain.cpp#L76 Are there exceptions you don't know the type of? Don't do this to be on the safe side. If you know that your HTTP request only throw exceptions derived from std::exception then if there is another exception you do not expect, you should crash the program because it could be something strange that you would not find out about otherwise. https://www.quora.com/What-does-crash-early-mean-in-software-engineering Never catch all. Actually you should not even catch std::exception but subclasses used in your HTTP client (if there are such, didn't check, otherwise it is a bad library). Have no time now, will continue later. |
|
|
|
I can write a mining pool, it is a fair amount of work but doable. So how much XMR would you be willing to give me (write me a personal message)? Plus I would like to keep the code for 2 months and host the pool for 5% pool fee (as I said, I don't have any BMB at the moment and now it starts getting interesting). Then after two months I would hand over the code to the community. Nice idea with the 'leaves' unit  |
|
|
|
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. |
|
|
|
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. |
|
|
|
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: 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 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. |
|
|
|
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: 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/62742eb4f91b92e11f68b5c552c2a4c8My 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. 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. |
|
|
|
|
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?
|
|
|
|
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. 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.pnghttps://pasteboard.co/27r9Dz6YMJE9.pnghttps://pasteboard.co/l0RGLdDvJKMa.pngBut I can confirm that you genesis balances look mostly correct. I used the julia 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 |
|
|
|
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: 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: 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. |
|
|
|
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 |
|
|
|
|
Will look at the code in more detail tomorrow but for now I do not understand :
1. Why you are overwriting newA in every loop iteration?
2. Why does this loop have 32 rounds?
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.
Some comments:
a) Please do not i for both the outer and the inner loop (even though i is not accessed),
b) Some people say preincrement is faster than postincrement, so use ++i.
I think you meant newA[i|=stripe so I am considering this(Note: Now I see that brackets are not printed in this forum because this notation is used for links so I do this [i|, i.e. closing with |):
-------
#define NUM_SHA_DIGESTS 1000
SHA256Hash memoryHardHash(SHA256Hash &a) {
vector<SHA256Hash> digests;
SHA256Hash last = a;
// Build vector of SHA hashes
for(int i = 0; i < NUM_SHA_DIGESTS; i++) {
SHA256Hash h = SHA256((const char*)last.data(), 32);
digests.push_back(h);
last = h;
}
SHA256Hash newA = NULL_SHA256_HASH;
uint32_t val = *(uint32_t*)digests[0].data();
uint32_t nextIdx = val % NUM_SHA_DIGESTS;
for (int i = 0; i < 32; ++i) {
uint8_t stripe = 0;
for(int j = 0; j < NUM_SHA_DIGESTS; ++j) {
uint8_t delta = val % (32 - sizeof(uint32_t));
val = *(uint32_t*)(digests[nextIdx].data() + delta);
nextIdx = val % NUM_SHA_DIGESTS;
stripe += *((uint8_t*)&val);
}
newA[i| = stripe;
}
return newA;
}
------
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]
|
|
|
|
|
Have no time atm, here is the code I have chosen for mining:
SHA256Hash mineHashShifu(SHA256Hash target, unsigned char challengeSize) {
vector<uint8_t> concat;
concat.resize(2*32);
for(size_t i = 0; i < 32; i++) concat=target;
// fill with random data for privacy (one cannot guess number of tries later)
for(size_t i=32; i<64;++i) concat=rand()%256;
while (true) {
*reinterpret_cast<uint64_t*>(concat.data()+32)+=1;
SHA256Hash fullHash = SHA256((const char*)concat.data(), concat.size());
bool found= checkLeadingZeroBits(fullHash, challengeSize);
if (found) {
SHA256Hash solution;
memcpy(solution.data(),concat.data()+32,32);
return solution;
}
}
}
So I do not call the concat function but manipulate right in place, furthermore one does not have to update every entry to get a new hash, I just directly write to the buffer using reinterpret_cast. 64 bits is enough for now but later at some point one has to also manipulate other bits (at every overflow of *reinterpret_cast<uint64_t*>(concat.data()+32) one should increase *reinterpret_cast<uint64_t*>(concat.data()+40) by one, then one has 128 bits. This can then be continued to get more bits changed when mining becomes that difficult. So this code is just for now because it only changes 64 bits.
Maybe I have time again in a few days to watch the progress of this project.
|
|
|
|
Could you share some of the mods you made to improve mineHash?
Sure but is it OK for you if I reregister as Master Shifu then? |
|
|
|
Couldn't help it  : https://www.youtube.com/watch?v=4uP7O2mM10A&t=18s8 ) Concerning the consensus problem: The way to go is to separate header and block downloads. Chain of headers are downloaded from peers to a) known who has the longest (most work) chain.and b) to known which peers have which blocks corresponding to this longest chain. Furthermore bad actors need to be banned based on IPv4. Enabling IPv6 is more difficult because there are so many of them, one approach is to block IPv6 subnet wise. 9) I do not completely oversee if MPFR will solve all problems. It is better to do this retargeting computation without floats similar to bitcoin. It is based on 256 bit numbers that are composed of multiple 64 bit numbers.You will need such large numbers for the concept of total work anyways. Programming such a retargeting function without floats is time-consuming but I think it is the only way. 10) The miner continues to mine if others find a block first (because the miner is not informed). This is really unfair for people with smaller hashrate because their mining problem is updated less frequently (only when the mineHash function returns https://github.com/mr-pandabear/panda-coin/blob/a1291fd9c8713818b8ad522e646a1b62a270e7e7/src/tools/miner.cpp#L71) and therefore they mining an already mined block most of the time (more % of time than faster miners). This gives then an additional disadvantage to their bad hashrate. 11) The mineHash function is inefficient. I have easily achieved a 10x speedup of this function in debug mode by rearranging some code. I could also turn on optimization flags, and other tricks to further increase my advantage (if I wanted mined this coin, maybe later). Please optimize this function a bit. But a good thing: One cannot use stratum protocol miners for this coin due to the custom mining function. So no one can just rent SHA256 hashrate. I wish you all the best to become the dragon warrior but I cannot further contribute because I have to focus on other things. |
|
|
|
Thanks for the tip. Here are some more thoughts: 5) The hash depends on sizeof(int) which is also platform dependent: https://github.com/mr-pandabear/panda-coin/blob/0641629b9ea6e195b99cc8b65e099d76ad934fe8/src/core/block.cpp#L1766) concerning 1) The fix is not super easy because you have to first rewrite the difficulty adjustment it in terms of integer computations such as in bitcoin's code and then verify that your current chain still satisfies these changes (if it already retargeted until now which I did not check) Please use uint32_t or uint64_t instead of int for 5) and 6) to have no platform dependence. 7) concerning 2) The delta idea won't help because an attacker can read the code and still lie to have a longer chain within the delta range in order to be selected as block download source. |
|
|
|
There are several problems with the current codebase: 1. The difficulty rebalance is based on floating point arithmetic and therefore platform dependent and not portable. Furthermore compiler flags such as --ffast-math will affect the difficulty computation and the log2 function used may also yield slightly different results on different platforms depending on its implementation. https://github.com/mr-pandabear/panda-coin/blob/0641629b9ea6e195b99cc8b65e099d76ad934fe8/src/core/blockchain.cpp#L185-L1872. The longest chain is chosen based on the chain lengths reported by the peers. A malicious peer can just lie and bring the whole program down by then sending garbage data. https://github.com/mr-pandabear/panda-coin/blob/0641629b9ea6e195b99cc8b65e099d76ad934fe8/src/core/api.cpp#L11-L153. The longest chain is defined in terms of number of blocks which is a serious mistake, it should be based on the total work. https://github.com/mr-pandabear/panda-coin/blob/0641629b9ea6e195b99cc8b65e099d76ad934fe8/src/core/host_manager.cpp#L814. The peer communication is based on HTTP requests and is not async. A peer that does not respond or purposefully delays its response can disturb the node. I want to inform you all about these severe problems with the current codebase. I could easily write a program that brings the whole pandacoin node down by exploiting above flaws 2. and 4. The other flaw 1. will manifest sooner or later and 3. is a total nonsense, I could just solo mine a longer chain in terms of number of blocks by keeping my difficulty low by manipulating timestamps. Then I my chain has less total work but more block count and it will be accepted and wipe the real chain. Yay, all coins are mine then. Please send some monero tip money for my effort to review the codebase: 86Juw7yZ313E8u2nfHBqKGGLKmki3Tg41CAZjwCTgNpk2DqqAMSR2d3KEwu6evrkMQ3eLzwbEfx9thL aYud3JgC7NxTf5eM |
|
|
|
|
