Questions
- Does follower validate state/blocks? YES
- When do tenure extends happen? Do they have coinbase (or only fee promise)?
- Current: Only when sorition is missed (burn block with no stacks block commit op)
- Future: Long period / or miner failed to propose
- What are chunks? (What do they contain? Does miner remember what they proposed (for a chunk to be created)?)
- If the majority of miners are acting maliciously while a minority follow the correct procedures, once the mining winner is selected, will the correct block still be validated on-chain even if the winner belongs to the minority? Or could the malicious majority manipulate the data and falsely claim they’ve won the block?
- If Nakamoto forks (malicious majority)? Which forks is followed by others?
- Are miners ever penalized?
- What happens if miner only submits nakamoto coinbase (and no next fast blocks)?
- Are signers ever penalized?
- Field in block header, which signers are behaved. If signers’ bit is zero, stacking slots will be burned instead. (punish slow signers?)
- Can you stack using bitcoin transactions? This should be possible, otherwise total failure if no Stacks blocks in prepare phase or the current 30%+1 signer is malicious and doesn’t sign any transactions
- Is this the typical process? Yes. The miner writes data to the stackerdb, signers read from it, then communicate with their nodes (mostly followers) to validate the data, and finally send back chunks through the stackerdb to the miner.
- Does a miner node always need a signer? No
- When the bitcoin transaction for miners have to be sent in the flow
btc. | 1000
stx. 300. | 301 302
miner (that is not the winner of this tenure) submits after seeing 301 for 1001
miner that is the winner of this tenure can submit it before 301 is anchored as it knows it (will not influence the overall flow with anything)
301 tenure change tx so i commit to that in my bitcoin transaction
Chaos Testing
Anything that can go down will go down
[ ] Investigate the use of "toxiproxy" to simulate instability locally
Swallowing communication (%)
Miner<>Signer (RPC)
P2P<>Followers<>Miners
Solution: Docker composed into regtest-env
Metric: Block height; Cycles with rewards; Number/% of stuck followers;
Censoring Stacks burn ops
“Flash blocks” or censorship
Metric:
Do signers recover? ()
How many censored blocks until
Unlikely: Entire prepare phase censored?
Speed
How fast to bitcoin/nakamoto blocks have to be to break the system?
Unusually long bitcoin block; what happens? How many extends?
Forks
Stories
[ ] #5232
Todo: Write test for this (not present in codebase)
[x] Miner ignores latest nakamoto blocks; instead proposes “fork” nakamoto block using the previous to last block in the tenure. This integration test evaluates the behavior at the end of a tenure. Specifically, the miner will broadcast the last block of the tenure, even if the signing is completed after the next burn block arrives. Additionally, the signers will not sign any block that arrives after the next burn block; however, they will complete any signing process that was already in progress when the next burn block arrived.
This means that the block proposed by the miner will be invalid and he should built on top of the latest block available.
[x] What happens if 40% refuse to sign? Invalid till threshold is met
this unit test verifies that for 66% voted when threshold is 70% the isn't signed enough to be anchored making it invalid
[x] Integration test for: miners fork and the signers split between them (if more than 30% of signers go with 1 fork, both forks would not produce blocks anymore)
Miners
Less important? They’ll figure out how to restart. Someone else will take over.
Stories
[x] Other miner can’t propose on behalf of current tenure miner. Is the sig/key checked?
[x] ~Signer doesn’t respond to proposal (delayed by 2 minutes); Miner in the meantime tries new proposal(s); Instead signer later responds with “old” valid proposal acceptance; Does miner recover and continue off of “valid” chain? (Integration/Unit)~
~Signer broadcasts (which makes it easier, and miner should recover by receiving new block over P2P)~
[x] Miner proposes update block (same height), but signers then validate previous proposal (same height)
If majority (maliciously) signs/approves invalid block; the fair minority should still work off of “valid” chain? They would have to stall as there are not enough signatures (Integration)
[ ] #5136
[x] Signer can only write to their own allotted StackerDB slot (Unit)
this test only checks they have their own slot, not that they run on it
this test checks the write through public key check
[x] Prepare phase missed stalls system — unrecoverable
Question: Can you stack using bitcoin transactions? This should be possible, otherwise total failure if no Stacks blocks in prepare phase or the current 30%+1 signer is malicious and doesn’t sign any transactions.
Answer: Yes, it is possible and integrated at the consensus level. (SIP section here)
Question 2: Would it still stall? Is the signer set calculated on a Stacks Block?
Answer 2: There must be at least two tenure-start Stacks blocks mined in the prepare phase in order for the system to detect and compute the new reward set. Otherwise, it would stall.
[ ] How can the stackerdb be corrupted/stalled?
Post invalid chunk somehow? (Signers) - try sql injection
Invalid chain state? (Node; Unit test)
P2P stalls (Node; Unit test)
Tenures
Stories
[ ] #5234
Signers will reject
Signers listen to: StackerDB events; proposal events; burn block events
Questions
- Does follower validate state/blocks? YES - When do tenure extends happen? Do they have coinbase (or only fee promise)? - Current: Only when sorition is missed (burn block with no stacks block commit op) - Future: Long period / or miner failed to propose - What are chunks? (What do they contain? Does miner remember what they proposed (for a chunk to be created)?) - If the majority of miners are acting maliciously while a minority follow the correct procedures, once the mining winner is selected, will the correct block still be validated on-chain even if the winner belongs to the minority? Or could the malicious majority manipulate the data and falsely claim they’ve won the block? - If Nakamoto forks (malicious majority)? Which forks is followed by others? - Are miners ever penalized? - What happens if miner only submits nakamoto coinbase (and no next fast blocks)? - Are signers ever penalized? - Field in block header, which signers are behaved. If signers’ bit is zero, stacking slots will be burned instead. (punish slow signers?) - Can you stack using bitcoin transactions? This should be possible, otherwise total failure if no Stacks blocks in prepare phase or the current 30%+1 signer is malicious and doesn’t sign any transactions - Is this the typical process? Yes. The miner writes data to the stackerdb, signers read from it, then communicate with their nodes (mostly followers) to validate the data, and finally send back chunks through the stackerdb to the miner. - Does a miner node always need a signer? No - When the bitcoin transaction for miners have to be sent in the flow btc. | 1000 stx. 300. | 301 302 miner (that is not the winner of this tenure) submits after seeing 301 for 1001 miner that is the winner of this tenure can submit it before 301 is anchored as it knows it (will not influence the overall flow with anything) 301 tenure change tx so i commit to that in my bitcoin transactionChaos Testing
Anything that can go down will go down
Forks
Stories
Miners
Less important? They’ll figure out how to restart. Someone else will take over.
Stories
Signers
Stories
Miner proposes bad/invalid block; Signer should NOT accept it; (Unit/Integration)(/validate is RPC called by signer before signing)If majority (maliciously) signs/approves invalid block; the fair minority should still work off of “valid” chain? They would have to stall as there are not enough signatures (Integration)Tenures
Stories