search

stacks-network / stacks-core

The Stacks blockchain implementation
https://docs.stacks.co
GNU General Public License v3.0
3.01k stars 674 forks source link

The STX mining VRF evaluation failing to consider all the miners BTC registrations (leader block commit) #2402

Closed paradigma-cl closed 3 years ago

paradigma-cl commented 3 years ago

Describe the bug I have seen systematically, the STX mining VRF evaluation is not considering all the miners BTC leader block commit. So it is collecting both sats fees for the STX mining and paying the sats fees for the BTC network. When you see the trace in the STX database, the miner does not appear at all on the VRF evaluation. So the miner is losing everything paid as it is not considered. We have lost the participation in the sortition for more than 50 blocks (more that 10 hours, night). No possibilityto win a block,

Steps To Reproduce

Running the miner Expected behavior When a miner manages to submit a leader block commit it should consider the miner in the VRF sortition.

Environment (please complete the following information):

Additional context Please include any relevant stack traces, error messages and logs. INFO [1612273824.615900] [testnet/stacks-node/src/burnchains/bitcoin_regtest_controller.rs:804] [relayer] Miner node: submitting leader_block_commit op for 057ede735365ac5e7af9c0286e993baa0cdcadfa55a8e5dc 9426f8167911e3fa - 02b5eefde4d2b01042f3a3386b3a46c55a37c93974e4ffbff8c6f193ac5c9fda9f, waiting for its inclusion in the next Bitcoin block INFO [1612273860.323298] [src/burnchains/burnchain.rs:1280] [main] Syncing Bitcoin blocks: 100.0% (668752 to 668753 out of 668753) WARN [1612273861.388623] [src/chainstate/burn/operations/leader_block_commit.rs:671] [chains-coordinator] Invalid block commit: missed target block, intended_modulus: 2, actual_modulus: 3, block_height: 6 68753 WARN [1612273861.388741] [src/chainstate/burn/db/processing.rs:66] [chains-coordinator] REJECTED(668753) leader block commit ead8c1582620a1aae9acb0b1e3ec076b418a08758859b2881b8908686824c5c9 at 668753,313: BlockCommitNoParent WARN [1612273861.568394] [src/chainstate/burn/operations/leader_block_commit.rs:671] [chains-coordinator] Invalid block commit: missed target block, intended_modulus: 2, actual_modulus: 3, block_height: 6 68753 WARN [1612273861.568462] [src/chainstate/burn/db/processing.rs:66] [chains-coordinator] REJECTED(668753) leader block commit 4645a323fe1e5af2f0f0b5f37c65c8c691ed90d340a35d6b917bb549dc7e828d at 668753,877: BlockCommitNoParent INFO [1612273861.603356] [src/chainstate/burn/db/sortdb.rs:3358] [chains-coordinator] ACCEPTED(668753) leader block commit b1780d4f3725acdeabe05f112523f6d0fc75c5e8f9cda80cbe6fc93a320829ea at 668753,50 INFO [1612273861.666554] [src/chainstate/burn/db/sortdb.rs:3358] [chains-coordinator] ACCEPTED(668753) leader block commit c681f216260bb8311fc9d481ec7db0a9a7cebe9c33de5ebd8f8bdb9fb0824c1c at 668753,53 INFO [1612273861.680404] [src/chainstate/burn/db/sortdb.rs:3358] [chains-coordinator] ACCEPTED(668753) leader block commit aad0306713d8287f7d332914511c9fc591876fec20ba83f79bd1fe90c412fec3 at 668753,524 INFO [1612273861.690470] [src/chainstate/burn/db/sortdb.rs:3358] [chains-coordinator] ACCEPTED(668753) leader block commit 6301e19fbbf49a9979c22bea07c8761565b3380426e829fbc3e9ba09c53c6fb0 at 668753,680 INFO [1612273862.081366] [testnet/stacks-node/src/neon_node.rs:1690] [main] Received burnchain block #668753 including block_commit_op - 17RfeXjpSQzqWrsEXd71eVWP4d28t1wKis (17fb029b1ca794a6cf5676fedf24e01 9462b67f42d35274d6fb40a98f54b54a8) INFO [1612273862.081394] [testnet/stacks-node/src/neon_node.rs:1690] [main] Received burnchain block #668753 including block_commit_op - 16sAXi1jxhxKCfY84hubDdnFNaAhqd5t49 (7446092aaef91508d93fa7e93fa9e3a c71123d7e727d20a1a895918fce2a1a57) INFO [1612273862.081409] [testnet/stacks-node/src/neon_node.rs:1681] [main] Received burnchain block #668753 including block_commit_op (winning) - 15282N4BYEwYh3j1dTgJu64Ey5qWn9Po9F (8875658191fd6081110cd b988957dfe0ca87469095d4bea01c557eb3a7cec34a) INFO [1612273862.081422] [testnet/stacks-node/src/neon_node.rs:1690] [main] Received burnchain block #668753 including block_commit_op - 1BKKtxfH8ouwuQGeSS9XUzUNQS9hknSrQp (fcd3c377e04d37978c9cd9322a523f9 6673f7864e58e33e656e9f6efe5d078ce)

But the submitting leader_block_commit op for 057ede735365ac5e7af9c0286e993baa0cdcadfa55a8e5dc is correctly submitted to block 668753 as shown here: https://www.blockchain.com/btc/tx/ead8c1582620a1aae9acb0b1e3ec076b418a08758859b2881b8908686824c5c9

Other cases, presented through Discord: 668765 2 668763 2185> 2,466.40 2,217,000 br170 s:55b68c1504 p:0fcf3c6898 c:e2904495d4 i:e37226fb8a b:00000000000000000005fa503 [0.5]SP105ARDW7 [27.1]SP137NZXD0 [9.0]SP1RJH1641 [9.0]SP3HCT23HV [27.1]SPAZ7Y7BMM [27.3]SPP1DJ1JE2* https://mempool.space/es/tx/515a99f6e8b41bd723e73505832614b6c993d4135d731140f7e9a6e48bbadbe7

Another case: Another: 668767 2 668765 2186> 4,932.80 2,217,000 br170 s:1904cf2991 p:55b68c1504 c:aff7040fb0 i:0eb3c02a02 b:000000000000000000080765a [0.5]SP105ARDW7 [27.1]SP137NZXD0*[9.0]SP1RJH1641 [9.0]SP3HCT23HV [27.1]SPAZ7Y7BMM [27.3]SPP1DJ1JE2 https://www.blockchain.com/btc/tx/ea80e82d60895e4ae4782cce5008b6766363dbbb9b6e365588f601edd7989618

paradigma-cl commented 3 years ago

We had to stop the miner, due to failing to consider the block leader commits to the Bitcoin blockchain in the VRF sortition producing a loss.

jcnelson commented 3 years ago

The error message Invalid block commit: missed target block indicates that the block-commit was supposed to have been included in an earlier Bitcoin block than where it was discovered -- in this case, Bitcoin block 668752. Because the block-commit transaction was late, it was not considered.

The solutions are to increase the fee rate, and possibly try running the develop branch (which includes some new, but lightly-tested mining code that minimizes the chances of this happening better than master currently does).

paradigma-cl commented 3 years ago

Probably the node has to presume commit, if no information about the transaction exists. But that commit has to be acknowledge probably in another way. With a prepare face, informing the rest that a leader block commit is coming. Then if it is confirmed, the sends a confirm, if not an abort.

paradigma-cl commented 3 years ago

The error message Invalid block commit: missed target block indicates that the block-commit was supposed to have been included in an earlier Bitcoin block than where it was discovered -- in this case, Bitcoin block 668752. Because the block-commit transaction was late, it was not considered.

The solutions are to increase the fee rate, and possibly try running the develop branch (which includes some new, but lightly-tested mining code that minimizes the chances of this happening better than master currently does).

I tried increasing the fee variant. In our case, we have a quite high fee of 151 sats/vb. Obviously, the top 2 miners are putting 200 sats/vb and 266 sats/vb. But this path will end in prohibited fees for mining, more than the fees that go for stacking. What if the price of the BTC goes to USD 100.000? We should try solve it in a technical way.
I will look into the developer branch, but as funds are going through, our hands are trembling.

jcnelson commented 3 years ago

Hey @paradigma-cl, this issue should be significantly better as of release 2.0.4. Wanna give it a try?

paradigma-cl commented 3 years ago

@jcnelson I have been trying to eliminate the missing or late mining publish block commit not considered on the rewards assignment through adjusting the fees, dedicated computers, network improvements, among others. Still after a certain frequency of 8 or 10 blocks, our miner is not considered for one block or two blocks. This happens also with 2 other miners, but the rest 6 are always considered, even having the same btc fees. So probably, what I am suspecting is that the stacks miner with its bitcoind have to be as close as possible to the Bitcoin miners. Is there any study or guess about that? If so, the Stacks Miners will need to be as close as possible to the Bitcoin miners (like the recent joint venture with Foundry) to be more effective and efficient in terms of not loosing the fees put to the Stacks network and BTC network. Any ideas or suggestions?

paradigma-cl commented 3 years ago

I have been testing live, the latest version 2.0.4

paradigma-cl commented 3 years ago

Here are some statistics from our mining node in a period less than a Week, and doubts and questions:

The Stacks mining registered 534 blocks mined, but missed 118 blocks commits considered late. Totaling 652 blocks. Between that period, there were 41 blocks that none of the miners registered a commit, quantity not considered in the total. This impacts the Stacking process, as 82 stackers cannot receive their rewards. The loss percentage of block commits was 18.10%, a considerable high percentage. Additionally, one must consider the BTC fees for the Bitcoin network and the fees for the Stacks network for each missed block.

In that period, 3 blocks were actually won, from 4. The percentage of won from actually mined was 0.46% compared to a theoretical of 1.17% Why such a low percentage of wins?

From this data, one could infer that something is going wrong with the mining process in some of these points of failure analized from the 3R perspective (Reach, Range and Robustness). Reach

  1. Local network with improved Internet connection.
  2. Internet connection to world level. Supposedly, it was also improved.
  3. Connected under a router with NAT. Range
  4. Bitcoind node running under Linux in a dedicated machine. Do not know if there are National BTC miners that are quickly accessible from our Bitcoind. Is it better to be close to a BTC Miner?
  5. Stacks-Miner Node of the Stacks Network running under Linux in a dedicated machine. Running a follower in another machine. Do not know if that impacts the mining process. Any way better?
  6. Tuned all the parameters of the Stacks node and fees in order to be present for the reward session.
  7. Similar fees as other miners to register in Bitcoin. Is the amount of the total BTC transaction consideration for the priority of processing commits?

Robustness

  1. The Stacks Mining protocol involved with the BTC network. The actual approach is a pessimistic one, instead of 2 Phase Commit. If the Stacks Node does not receive a confirmation of a commit of the transaction to the BTC network, considers it as it was not done. But sometimes arrives late, in the next block.
stale[bot] commented 3 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

stale[bot] commented 3 years ago

This issue has been automatically closed. Please reopen if needed.

blockstack-devops commented 3 weeks ago

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.