It was the Bitcointalk forum that inspired us to create Bitcointalksearch.org - Bitcointalk is an excellent site that should be the default page for anybody dealing in cryptocurrency,
since it is a virtual gold-mine of data. However, our experience and user feedback led us create our site;
Bitcointalk's search is slow, and difficult to get the results you need, because you need to log in first to find anything useful - furthermore, there are rate limiters for their search functionality.
The aim of our project is to create a faster website that yields more results and faster without having to create an account and eliminate the need to log in -
your personal data, therefore, will never be in jeopardy since we are not asking for any of your data and you don't need to provide them to use our site with all of its capabilities.
We created this website with the sole purpose of users being able to search quickly and efficiently in the field of cryptocurrency
so they will have access to the latest and most accurate information and thereby assisting the crypto-community at large.
+ return except("Failed to construct parent block");
+
+ if (!mergeBlocks(parent_block, b, std::vector()))
+ return except("Failed to postprocess mining block");
+ }
you make merge block in solo mining I do not understand why you do
There are block of two types: one is traditional blocks (Monero, Bytecoin, QuazarCoin, etc.), while the other one is for Fantomcoin only. This second block type allows merge mining of the first ones and is the only block type accepted by FCN (and MCN). FCN mining requires doing work with the block template of the second type (native to FCN). These blocks also allow merge mining with the first type blocks, but I started with fixing pool's block template to single mine FCN.
As for high orphan rates, I've found two problems. The first one was related to the network parameters, which turned out to be misconfigured. The second one was that the block hash was taken invalidly from the block explorer, which marked valid blocks as orphaned. The fix will be released soon.
up to now in your pool only blocks orphans left it is not because you are using the function merge also to mine only fcn? miner.cpp from the file miner.cpp I do not see the use of the merge works I know that you should not use it also you do not need to do the nonce on parentblock just have to modify the file so pool.js in this way
Code:
var shareBuffer = new Buffer(blockTemplate.buffer.length); blockTemplate.buffer.copy(shareBuffer); shareBuffer.writeUInt32BE(job.extraNonce, blockTemplate.reserveOffset); new Buffer(nonce, 'hex').copy(shareBuffer, 73); no 39 but 73 and in the function convert_blob you have to use get_bytecoin_block_hashing_blob
There is no merge mining implemented at the moment. I'm working on the solution but it is way more complicated than just Fantomcoin's blocks support. I hope to release it next week. At the moment Xminingpool implements single mining for FCN.
As for orphaned blocks, it's just the FCN daemon's configuration. I'm tuning it to fix the issue at the moment.
up to now in your pool only blocks orphans left it is not because you are using the function merge also to mine only fcn? miner.cpp from the file miner.cpp I do not see the use of the merge works I know that you should not use it also you do not need to do the nonce on parentblock just have to modify the file so pool.js in this way
Code:
var shareBuffer = new Buffer(blockTemplate.buffer.length); blockTemplate.buffer.copy(shareBuffer); shareBuffer.writeUInt32BE(job.extraNonce, blockTemplate.reserveOffset); new Buffer(nonce, 'hex').copy(shareBuffer, 73); no 39 but 73 and in the function convert_blob you have to use get_bytecoin_block_hashing_blob
Previously node-cryptonote-pool didn't provide proper address validation. Here are some addresses that are accepted by the pool but rejected by the wallet:
2Aui6ejTFsd1111111111111111111111111111111111111111111111111111111111111111111111111111114W5UeV - BCN invalid but accepted address 4BKnGLZNZ5q1111111111111111111111111111111111111111111111111111111111111111111111111111113S9JYY - XMR invalid but accepted address
Pool is checking whether the coin's address starts with a proper character, but this is an invalid rule of thumb unfortunately. The address is being created based on the currency's prefix (6 for Bytecoin, 18 for Monero), which shouldn't be confused with the address's first number. It is possible to create an address for Bytecoin with prefix 7 (and for Monero with prefix 19), which would look exactly like the two addresses above. The outcome is a potential attack on the open source pools which would freeze all payouts once the invalid address is processed by the wallet.
I've also fixed the duckNote's address validation.