jcnelson
commented
4 years ago Thank you so much for taking a deep look at this @psq @friedger!
Fundamentally, the reason why a LeaderKeyRegisterOp Bitcoin transaction creates a UTXO with 5500 sats is because it needs to register a Bitcoin address with the Stacks node that will be paired with a corresponding LeaderBlockCommitOp. The LeaderBlockCommitOp "consumes" an associated LeaderKeyRegisterOp in that one of its inputs must have a scriptSig that matches the second scriptPubKey output of the LeaderKeyRegisterOp (i.e. the first non-OP_RETURN output). This check ensures that the principal who can use the VRF public key to produce a VRF proof and VRF seed as part of a block-commit can only have been the same principal who registered the VRF public key in the first place. But, implementing this check currently creates a "dust" UTXO output each time a VRF public key is registered, leading to this problem.
There's a couple ways I think we could fix this:
- Make the Bitcoin UTXO scanner remember the UTXOs it creates. Then, when it goes to produce a new Bitcoin transaction, it will try to reuse a known UTXO instead of ask the Bitcoin node to re-scan each time.
- Implement #1615, so a miner only needs to register a single VRF public key to mine multiple blocks. Moreover, #1615 would drop the requirement that a
LeaderBlockCommitOp's firstscriptSigneeds to be paired with theLeaderKeyRegisterOp'sscriptPubKey, since only the principal who possesses the VRF private key can generate a valid Stacks block in the first place. This would remove the need to create the dust UTXOs onLeaderKeyRegisterOps in the first place.
Related, I welcome any thoughts and opinions on #1615. It's a consensus-breaking change.
paradigma-cl
psq
diwakergupta
While analyzing the blocks produced by the miners, I noticed that some miners were mining only every other block. For example, with the help of Discord, we have identified the miners from from phillip and @friedger were behaving that way. My miner has not exhibited this behavior, and this is still not clear to me why only some would behave that way (maybe the fact that they are both on different continents may be a factor...).
From the logs (from @friedger, but the logs from phillip look similar), we see the following (excerpt with the relevant bits around the start of each new block):
In #1 the miner registers a key. So far, so good
In #2, there was a key registered, so the node will commit a block:
the 2 calls to
BitcoinRPC buildershould belistunspentandsendrawtransactionThen the miners tries to register a key for next block:
but this fails because the node could not find UTXOs (spoiler alert, there are still some!). The 3 calls to
BitcoinRPC buildershould be respectivelylistunspent,importaddress, andlistunspent(from https://github.com/blockstack/stacks-blockchain/blob/master/testnet/stacks-node/src/burnchains/bitcoin_regtest_controller.rs#L206). Note that the the 3 calls can take up to 6-7 seconds (not visible in #2, but check #6).So the above seems to explain why the node only mines every other blocks as the leader key registration fails every other time.
But now the question is: why do the UTXOs disappear?
My best theory so far is that spending some UTXOs for the commit transaction forces a rescan on the bitcoin node (an other possibility is that the utxos get kicked out of the cache), and even though
get_utxosuses asleep(1000)before the second call tolistunspent, this does not seem to be enough, but 30 seconds later, when it is time to register a new key, the rescan has completed, and the node will find utxos.Now one reason why the the rescan takes so long is that there are a lot of them after a miner has been mining for a while. In the case of @friedger when I queried the argon bitcoin node, there were about 3,400 and counting. Here are a few:
Only 1 of them meets the requirement (> 11000 sat). My current thinking is that the miner's code should more judiciously reuse small utxos (created by the key registration transaction) instead of looking for the first utxo with sufficient balance (https://github.com/blockstack/stacks-blockchain/blob/master/testnet/stacks-node/src/burnchains/bitcoin_regtest_controller.rs#L860).
One possibility might be to use the amount the node plans to burn on the next round for the tx amount rather than 5500 so that utxo can be reused, or transfer the whole utxo amount minus the fee (no change output required means smaller transaction)) to avoid creating all these tiny utxos.
I would not suggest combining more than 1 input to meet the amount required, this would make the transaction bigger.
If my theory is close to correct, the fix should be fairly simple...