* Add support for fork9_sidechainversionfork:
* Add Horizen specific section in else if chain and remove now redundant code
* Refactor fork management for Horizen (forks and required data are now defined in s-nomp/coins/zen.json)
* Fix: typo
* Fix: regression introduced in 'Pers Auto (#61)'
* Added support for new type of blocks in zendoo
* Fixed synchronization with getSidechainMerkleRoots RPC calls
* Updated package.json
* Renamed RPC commands and removed initialization of merkleRoot an hashReserved
* Removed condition when hashReserved is taken from RPC
* Changed RPC command name
* Added check for coin and block version
* Replace string.contains with string.indexOf
* Replace string.contains with string.indexOf
* Changes after code review
* Change symbol for zen testnet
* Fix regression after code review
(node:40) UnhandledPromiseRejectionWarning: TypeError: Cannot read property 'version' of undefined
at JobManager.processTemplate (/home/node/s-nomp/node_modules/stratum-pool/lib/jobManager.js:175:26)
at /home/node/s-nomp/node_modules/stratum-pool/lib/pool.js:686:73
at itemFinished (/home/node/s-nomp/node_modules/stratum-pool/lib/daemon.js:166:36)
at /home/node/s-nomp/node_modules/stratum-pool/lib/daemon.js:180:17
at parseJson (/home/node/s-nomp/node_modules/stratum-pool/lib/daemon.js:92:17)
at IncomingMessage.<anonymous> (/home/node/s-nomp/node_modules/stratum-pool/lib/daemon.js:103:17)
at IncomingMessage.emit (events.js:203:15)
at endReadableNT (_stream_readable.js:1145:12)
at process._tickCallback (internal/process/next_tick.js:63:19)
* Fixup
Co-authored-by: MarcoOl94 <marco.olivero94@libero.it>
Co-authored-by: cronicc <cronic@zensystem.io>
Fixes a bug where invalid blocks are generated when a coin reaches a
SubsidyHalvingInterval block.
node-stratum-pool uses the 'getblocksubsidy' RPC call without the optional
'height' argument, which returns the block subsidy reward at the current
block height. Instead 'height' with the block height of the next block
needs to be passed to 'getblocksubsidy'.
As the values from 'getblocksubsidy' are used to set the amounts of coinbase
tx vouts, upon reaching the halving block height boundry, node-stratum-pool would
generate a block that doesn't take the halved block rewards into account, which
gets rejected by the coin daemon.
Explanation of this code provided by blondefrogs:
The transactions in a block are places in a vector. To serialize a vector, we need to be able to read its contents, so it serializes the size of the vector first but we don't know the size, so it uses a variable called a varint. A varint is trying to serialize the size in as little bits as possible. If the size is below 0xfc, it will just serialize the size Otherwise, if the size is above 0xfc, it will serialize a 0xfd first, then the size.
Basically, before this fix, the stratum would submit an invalidly coded block to the node if there were between 127 - 253 transactions in the block.
nTime is coming through as a reverse buffer and is properly being
parsed, but not properly being converted to an integer. Because of this,
the checks that follow could never be triggered. This change converts
the ntime buffer to a string before running it through parseInt. In
addition, an isNaN check was added for additional safety.
BTH's getblocksubsidy returns satoshi which differs from other chains who
return full coins. With this change, we'll default to expecting full
coin but allow that to be overridden by setting subsidyMultipleOfSatoshi
in the coin's config file.
This PR adds payouts to all three tier of zelnodes (zelcash masternodes). Information is taken directly from getblocktemplate rpc call. If there isn't an enabled zelnode, the information is undefined and payout goes to miners.
Payouts are paid even if they are not yet enforced by the spork. Enforcement of payouts will be activated through spork after 21st of Feb.
payZelNodes can either be set to true or to a timestamp (in seconds!) of when expected enforcement of zelnode rewards by spork activation is about to happen for automatic transition. When false or unspecified zelnode payouts wont be paid.
The expected time of zelnode payouts is around 25th of Feb (TBD) so pool operators update their backend and specify "payZelNodes": 1551103200 in their zel.json file and once that time passes zelnode payouts will be paid. This still checks if the conditions for payouts are present - so if daemon is not specifying a zelnode payout address with a value, the payout will go to miner and not to zelnode even if payZelNodes is active.
blockHeight is not defined and fails when `sapling` or `overwinter` are set to a block height in the coin config. I've updated the code to use the correct `rpcData.height`.
Update the transaction.js file to use the coin variable already passed in to create the json variable needed by the bitgo-utxo-lib. This way new coins can be added to s-nomp without a push to the bitgo-utxo-lib repo.
* Update lib/transactions.js
patched rewards function to run without burn being set to true. added if statement to error catch empty reward recipients.
* Update lib/transactions.js
burn = 0 added to recipient loop so it clears on each run.
* Update lib/transactions.js
removed extra space
* Update lib/transactions.js
spacing fix
* Update lib/transactions.js
removed extra line
* Update lib/transactions.js
actually removed extra line.
* Update lib/transactions.js
spacing fix
Summary:
Currently, s-nomp is not reporting rejected shares properly back to the
miner. This change modifies the response to the miner to properly report
errors.
This commit adds SafeCash support, has some minor changes to messages to make debugging easier and also updates the "getinfo" API usage to the newer calls.
* 192,7 Solution Slice 4
* testing purposes only
* Lets try again with the slice
* Found correct size 6
* Removed testing branch
* Update package-lock.json
This is a copy of a fresh npm update from the root of z-nomp.
* Connected with equihashverify/sync-with-upstream
* Removed testing branch
It was a bit tricky to get ZEN to work as expected. In the process of
working through the issues, I refactored some of the code (initial
refactoring) and updated the packages.
If you configure payments to be too frequent, a call to the payment
daemon may still be executing while another payment loop begins. This
could lead to the second (or more) loop fetching the some of the same
share information as the first and making extra payments. This is
evident when balances go negative.
This commit adds the ability to set a timeout for calls. The default
timeout is 60 seconds but is overriden by another change to
paymentProcess.js in z-nomp that sets the timeout to half of the payment
processing time alotted by configs. This ensures some of the more time
expensive calls don't stick around long enough, leading to double (or
more) payments.