Does such a “discount” effectively reduce the security - aka the cost to rewrite history, censor transactions when compared to proof of burn?
Do you have a pointer to a discussion of the security of the current network (virtual chain on bitcoin), vs the original proposed proof of burn stacks v2.0 vs the new proposed PoX stacks v2.0 network?
Hi @argonau7,
Stackers and miners are generally not the same entities, since they each have different responsibilities, operational expenditures, and motivations.
Miners do the following:
In particular, miners are always spending BTC, and miners are always online. These are ongoing expenses, which are compensated by the protocol via STX coinbases and transaction fees. Their incentive to do this at all is that they always receive STX on the fork they mine, even in the absence of Stacking.
Stackers to the following:
A Stacker’s operational costs come from identifying the set of forks and coordinating with other Stackers to bless a >80% fork. At worst, this is the cost of running a full node that doesn’t relay anything, plus the cost of a BTC transaction fee to send out the blessing. As you point out, this cost can be amortized across a set of Stackers who collectively offload this responsibility to a pool operator. Even then, some Stackers may choose to not run a node at all, and instead simply trust a block explorer to tell them which forks exist and whether or not a fork has >80% support. But regardless, Stackers do not receive STX; in expectation, they receive the BTC-denominated market rate for STX collected by miners.
Stackers participate opportunistically – their participation is welcome, but not required for the Stacks blockchain to work. If anything, it helps miners make better decisions on which fork to mine on if there is contention.
In the earlier comment, I was contrasting Stacking from PoS. In PoS, you get the same number of tokens regardless of market prices. In Stacking, you don’t. But yes, if you assume that miners collectively spend the same amount of BTC per block in a Stacking reward cycle, then Stackers with more slots will receive more BTC.
Yes, I do think running a PoS node is “install and click.” I think the fact that can be much more than that for certain blockchains is an artifact of the design of the installer, not the design of the protocol. This is because in correct PoS blockchains do not fork. A PoS blockchain behaves like your typical run-of-the-mill BFT database, where forks only arise if the safety properties of these systems are violated (at which point, out-of-band human intervention is required to fix it). If (1) you know the current validator set’s public keys, and (2) the 66%+ majority of all current and future validators remain honest, then your node will always be on the 66%+ fork. There’s no need for a human-in-the-loop to tell the node periodically which validator set(s) to trust. The only human involvement is deciding what to do with the earned PoS tokens.
This is not true with Stacking, since the Stacks blockchain can and will fork even under correct operation (this is a feature, not a bug, since forking allows the blockchain to repair itself in-band). Therefore, Stackers need to be able to make decisions as to which fork they’ll bless. This decision is influenced by a variety of both in-band and out-of-band factors, such as (but not limited to the following):
There is not protocol-determinable “right answer” to these, since Stacking isn’t part of the consensus protocol (recall that miners make progress with or without Stackers).
Hope this clarifies things!
Yes, discounts reduce safety, since miners can spend less to mine blocks than other miners who don’t receive the discount. However, discount-mining is superior to free-mining from a safety-perspective, since you can bound the advantage a miner can have if their Stacking addresses come up for rewards. Proof-of-burn is the most secure form of proof-of-transfer, since there is no possibility of a discount then.
The security models for virtual chains and PoB/PoX are fundamentally different, since virtual chains do not have a protocol-determined way to identify “fork quality.” Choosing the right fork requires human intervention in virtual chains.
PoB is more secure than PoX, since all miners pay at the same rate. However, there exists variants of PoX that can limit how much of a discount a miner could receive to the point where, practically speaking, PoX would work out just fine. Requiring a fraction b to be burned is one such variant. Requiring O(b^e) to be burned is anther option, where e > 0 is a protocol-defined constant.
This is a good question. Stacks chain sortitions are globally-scoped – there is one sortition per Bitcoin block, and it picks a Stacks block out of all candidate Stacks blocks across all Stacks forks that exist. As proposed in this SIP, miners only transfer Bitcoin if they mine on a fork with a significant majority support. If this were not the case, then a miner with a very small amount of mining power (let’s say 1%) could slowly but surely mine its own fork and Stack only the STX that exist on that fork up until the point where the fork would pass the “prepare” phase and enter the “reward” phase. At this point, the miner could mine blocks for free – they could take out a loan for a huge amount of BTC (e.g. 10,000 BTC) and then PoX it to mine on their own fork during the “reward” phase. Because they were the only Stacker on their fork, they’d receive all of the BTC back. But because sortitions are globally-scoped, what would happen is that this 1% miner would effectively deny service to all other forks besides theirs for the duration of their fork’s reward cycle, which would not only stop blocks on the dominant fork from being mined, but could also be used to eventually overtake the dominant fork and reorg the entire chain (all for free, minus the cost of BTC transaction fees). This cannot be allowed to happen, so SIP 007 specifically limits Stacking to occur on forks with over 80% mining support.
I think this will likely be the case. In my mind the model is roughly number of STX parked * work done (0 or 1). If a Stacks holder is not actively running a full-node and signaling the information then she is not actively participating and won’t earn any BTC reward. But if the holder is participating then the payouts will likely be proportional to STX parked.
No, a large amount of Bitcoin is not burned. That’s for corner cases. The goal here is for the bulk of Bitcoin that is used to get distributed to active Stacks holders that are participating in the consensus algorithm.
Hi everyone!
Love the proposal and love the idea of updating the proof-of-burn system to a proof-of-transfer system. Seems like a clear upgrade.
On that note, I have a few comments on this proposal. The biggest one I’ve included below, which outlines what I see as an issue with the “prepare” round and the reward set that can cause the system to inevitably devolve into proof of stake.
In the SIP-007 proof-of-transfer proposal, it appears that the “prepare” process can be gamed in order to provide unfair advantages to miners with more funds, thus leading to a system where the rich get richer.
To illustrate this, we can consider a simplified version where there is 1 address in the reward set per cycle. Not that the same issue applies with 5 addresses per reward set, but to a lesser degree, and we will build up to this condition below.
Imagine that every block there is only 1 address randomly selected from the eligible “whale” addresses (addresses with 0.02% holdings). Then, each round, most miners would be able to give up their Bitcoin for a chance at winning the Stacks, while the owner of the recipient address would be able to send all of their Bitcoin and send it to themselves in order to virtually guarantee that they will be rewarded the Stacks.
In this scenario, the miner risked nothing and gained the Stacks reward for free. It is easy to see how the system would devolve into a steady state in which the only miners operating are those with whale addresses and where those whale miners are only participating in rounds in which they are the only guaranteed recipients. One could argue that this isn’t a total breakdown of the system, but is in actuality simply a devolution into proof-of-stake with pooling.
It is also important to consider that this should not just be a theoretical devolution, but rather a necessary devolution if one assumes any reasonably efficient mining market (like Bitcoin).
Now we can consider the scenario with 5 addresses per reward set. The path to devolution is not as apparent here, and it would undoubtedly take a bit longer to play out, but the same properties apply.
In each round, most miners would be able to give up their Bitcoin for a chance to win the stacks, while the owners of 1/5 of the recipient addresses would be able to send 20% more for the same amount of risk, thus getting 1.25x the votes as everyone else. Every round, there should be up to 5 miners who have the ability to get 1.25x the votes that round. And in certain rounds, certain miners would get even more because they would own more than 1 recipient address for the round:
We should assume an efficient market with the Bitcoin-to-Stacks conversion. A big part of this is that at any point in time, miners could choose to purchase Stacks on exchanges rather than mine. This means that after a certain number of rounds, the amount of Bitcoin spent should vary around some average amount, as miners seek to predict how many Bitcoin will be transferred for Stacks and thus how much expected profit they will make by participating in any given block.
With this knowledge of the average amount, it should be apparent that miners with a recipient address in the set should be the only miners who participate, as they will be the ones with a 1.25x advantage.
Miners who do not do this analysis and who do not practice discerning mining will progressively realize that they are losing money, as they are receiving mining rewards at below market rate, and will then go to the exchanges to purchase stacks instead. The only miners left will be the whale address miners who focus on the blocks with their own recipient addresses. This will essentially be a proof-of-stake mining system, with a layer of obfuscation.
This process can be exacerbated if miners band together and create alliances. Together, these miners would be able to own 2/5 addresses or more in certain blocks, and so would be able to gain 1.67x advantages, which would be even less feasible for other miners to compete with. The larger the miner alliances, the larger the advantages.
All in all, over time, the senders who play the simulated proof-of-stake game and only mine in the blocks in which they own recipient addresses will be the ones who continually make profits while the miners who do not play the game (and instead play the honest proof-of-transfer game) will continually make losses.
Now onto the solution.
The way to fix this would be to add a third phase in the beginning in which miners must commit to a given round and post collateral before the recipient addresses in that round are revealed. If this is done, then the collateral can be seized if the miner does not actually participate in the round.
The collateral can be posted in Stacks by having the miner send a commitment transaction from an address with a Stacks balance. The protocol has control over the Stacks balances, so it has the capacity to seize the collateral in the instance that a miner fails to send the Bitcoin in the round.
The amount of Stacks required to be posted as collateral could be the same amount as the potential reward for that block. This would ensure that there is no possible way that any miner could cheat and come out net positive.
In summary, the collateral posting system would prevent miners from selectively participating only in rounds in which they get a percentage of the proceeds. It would mean that every round is effectively the same to all participants. And it should mean that the system does not devolve into proof-of-stake.
Hi @shea256, thanks for your feedback!
We’ve been calling the scenario you just described “free-mining,” whereby a miner who knows their addresses are going to be picked for the next round of PoX rewards has every reason to transfer as much BTC as they possibly can in order to win sortition “for free” (since they’d be getting their BTC back in the overwhelmingly-likely case that they win). There’s a variation of PoX whereby miners are required to burn at least b% of their BTC no matter what, which reduces the problem from mining blocks for free to mining blocks with a maximum discount.
I think your proposal is interesting, but I have a few questions:
I think what you saying is that before the “prepare” phase (where Stackers bless the fork), there’d be a phase where miners put up a STX collateral for each Bitcoin sortition they intend to participate in. If a miner intends to mine a Stacks block in Bitcoin block B, they have to lock up some number of STX that effectively constitutes a promise that at Bitcoin block B, they’ll send a PoX transaction. If they do, they’ll get their STX back. If they don’t, the STX will be burnt. Is my understanding correct?
If this is what you mean by “commit to a given round,” then aren’t the following still true?
I think you’re saying here that miners have to put up an entire STX coinbase as collateral? There’s no way to know in advance how many STX a miner will receive from a block, however, since the miner doesn’t know how much transaction fees they’ll get. Doesn’t this mean that the protocol-dictated collateral is potentially too low, in any case?
Yes this is correct.
I’m not saying there’s an issue with free-mining. I’m saying there’s an issue with only free-mining. Committing before the “prepare” phase means that you can only free-mine probabilistically. You can’t do so opportunistically.
Yes, there are two options here. Either (a) put up the entire STX Coinbase, which is a lot but solves the problem, or (b) figure out a way for the protocol to “know” the exchange rate between BTC and STX.
Ah, I’m more pessimistic. I think that free-mining should be prohibited at all times, as a hedge against any future attacks STX and/or BTC miners and/or Stackers can come up with after the protocol gets launched. I’m worried that the minute it becomes possible to free-mine in any circumstance, economic efficiencies will ensure that eventually, only free-miners can afford to mine.
OK so at a minimum it seems we agree the current arrangement is problematic.
Do you believe that requiring a commitment before the “prepare” phase is a strict improvement?
I’d argue it fully addresses the problem, but it seems you don’t believe that.
The reason I say this is because everyone gets the same deal and there is no strategy that can be employed to selectively mine.
The problem arises when there are dominant strategies that can be employed to outcompete others.
With a commitment to participate before you see the recipient addresses, I believe this is addressed.
My second proposed modification would be to revisit the method of:
Why not reset the randomization every time instead of rotating through addresses in round robin fashion? And why not just remove the threshold?
I see why one would want to cycle through all the addresses - this allows you to guarantee that all addresses will get paid out in a given time period. But I would say that if you do a random selection each and every round then you will probabilistically get everyone paid out the same.
As a thought experiment, if you and I play a game where we flip coins, and I call heads on the first round and win, we don’t force the second round to come up tails. We keep the same odds every round. Yes, I could win 3 times in a row with 3 heads in a row, or you could win 3 times in a row with 3 tails in a row, but as the number of flips goes up the distribution approaches 50-50. This is closer to what Bitcoin mining is.
I fear that moving away from probability and towards supposed “equality guarantees” (with a round robin system), we’re creating a more complex system that isn’t actually more equal.
One alternative would be to allow for any address to participate (without pooling), and for their participation to be weighted proportional to the number of Stacks they have in their addresses. This would mean addresses with 100,000 Stacks would be chosen 10x as often as addresses with 10,000 Stacks.
Pooling would become an emergent property rather than a built-in feature.
And yes, one should be concerned about excessive transactions with lower thresholds to participate, but the high transaction fees (as a percentage of revenue) for the smaller participants would mean that there would be natural incentive for the smaller participants to pool. This should lead to a reduction in transaction volume.
A key advantage of the randomized round-robin approach is that it puts an upper-bound on reward frequency. A participant will receive BTC within the reward cycle if the system is working. This is not true for probabilistic approaches.
My third proposed modification is a method for significantly reducing the variance of payouts from one address to another, while also reducing the amount of data load on the blockchain.
First, when we think about variance, we should consider that for any given set of eligible mining addresses, there is a fixed period it will take for the expected variance to fall below a desirable threshold. This expected variance is the same whether the rounds have an independent probability (like coin flips) or whether one employs a round robin approach to cycle through all addresses before restarting a round cycle.
Second, when we think about minimizing load on the Bitcoin blockchain, we should not be focusing on the total number of transactions, but rather the total number of bytes. Bitcoin addresses are priced in bytes and the scarce resource is bytes. Transactions scale with the number of inputs and outputs. A transaction with 1 input and 7 outputs (5 recipients, 1 change address, 1 data field) can lead to approximately 2x the data load as a transaction with 1 input and 3 outputs (1 recipient, 1 change address, 1 data field).
Now for the proposed modification.
In SIP-007, the proposal features a mechanism where in every round, a new set of 5 addresses is randomly selected to be the recipients of the proof-of-transfer process.
I propose changing this so that in each round, instead of requiring all miners to send to the same 5 recipients, the protocol randomly selects a distinct address for each miner, which serves as the recipient for the miner’s proof-of-transfer transaction.
For example, imagine that in a hypothetical system there are 5000 miners and 5000 addresses with equal balances. Then in each round, each address should probabilistically be the recipient of 1 mining transaction on average (#2438 would send to #1872, while if #1872 is mining it would send to #4831, and so on).
In a hypothetical system with 5000 addresses with unequal balances, the probability of being selected in any given round-miner-pair would be proportional to the balance of the hodling address.
Address selection would be accomplished by taking the same verifiable random function (VRF), producing a new seed in every round using the VRF, and combining the seed with the address of every pre-committed miner to produce the full list of miner-specific addresses for that round.
This would result in a web of sending in every given round, rather than all miners sending to the same recipients every round.
Variance of earning Bitcoin via the mining process would be significantly reduced, since in every single round a hodler would have N chances to be chosen as the recipient, where N is the number of miners.
Data used per round would also be reduced, since instead of 5000 miners sending 5000 7-output transactions each round, 5000 miners would be sending 5000 3-output transactions each round.
Hope this is helpful and curious to know what you think. Happy to elaborate further or answer any questions you have.
The PoX protocol, by design, does not know which miners exist a priori, and therefore cannot assign miners an address to send to. It only assigns addresses to blocks, which any miner(s) must send to whether they like it or not.
Such a scheme could only work in conjunction with a “miner registration” system whereby miners announce their intentions to mine on a particular block. Such a scheme would also be extremely risky, since it would enable free-mining if miners had any freedom to choose which addresses they could send to – they’d only ever send to themselves, or at least try and bias it so that their addresses have a better-than-random chance of being selected. The fact that miners must send to a particular set of address that they cannot choose is a feature, not a bug.
With this proposal the protocol wouldn’t need to know which miners exist a priori. Each miner would take the seed for the round and combine it with their own address and the list of recipient addresses to deterministically figure out the recipient they need to send to.
This is proposed to be in combination with a pre-commitment process with collateral, which seems to be required anyway to prevent gaming. If this pre-commitment with collateral is implemented, then opportunistic free-mining would not be possible.
I think it’s a clear upgrade to SIP-001 as well!
I’m going to boil down the above discussion into a few topics and then comment.
Discounted Mining:
We plan to update SIP-007 with a discussion on discounted mining. I think “free mining” is a potentially misleading term for this because the discount is in the 10-20% range given no. of slots and the probability of the discount being 90% or whatever is negligible.
A miner’s main motivation to mine should be the STX coinbase, transaction fees (in STX), and Clarity contract fees (in STX). This decision to mine or not mine needs to be made by the miner for the vast majority of the blocks (where the miner does not have an address) and the miner will decide to mine if it’s profitable to do so.
No miner will mine at a loss, it’s about how much profit can a miner make. It’s a local decision that every miner makes, a miner will not even know if someone else is engaging in discounted mining or not.
Sporadic Mining:
If a miner decides that it only makes sense to mine in blocks where she has a payout addresses then that will likely result in sporadic mining where say that miner is participating only in a small subset of blocks.
First, I think the miner does not have the right incentives to participate in sporadic mining. The STX coinbase is not a guarantee but a probability. If you mine sporadically then you are potentially hurting your chances to get the STX coinbase vs mining regularly.
Secondly, you can make it harder for miners to participate in sporadic mining. You can introduce a minimum participation window. For example, if you don’t participate in at least 10 consecutive blocks as a miner then you don’t qualify for the STX coinbase at all. This takes the 10-20% discount to a 1-2% discount and can make it even smaller by increasing the size of the minimum participation window.
Interestingly, an earlier version of STX mining had a window and we got rid of it due to some potential unintended consequences. It might be worth exploring if a modification of a sliding window in the form of a “minimum participation threshold” makes sense.
Thanks for the discussion around discounted mining! It definitely opens interesting discussions and design tradeoffs.
For any readers following along I think it’s important to put some of these in a more practical/realistic scenario.
Practical Scenario: Let’s say a miner is willing to put up significant capital, say $1M, to take advantage of discounted mining. At the current ~$0.10 price that is roughly 10M STX or 2.0% of the liquid supply (current circulating supply is ~508M STX). 2% of liquid STX means that this miner now gets 100 out of ~5000 slots for a payout and would need to make a decision about mining (or not mining) in the vast majority of the blocks where the miner does not have an address.
Also, it’s unclear to me if this behavior is net negative to the ecosystem, especially in the initial year(s). There are crypto-assets like BNB (Binance) where holders of BNB get a discount on trading. Miners who want to use discounted mining are providing value to the network by becoming longer-term holders. There is very clearly a cost to the miner for locking $1M USD in Stacking to get discounts vs using that money somewhere else.
The sliding window mentioned above (which was part of an earlier design for a different reason) addresses this issue anyway but it’s interesting to explore what positive/negative impacts this miner behavior can have.
We debated the two designs and their pros/cons. Ultimately the question is that do we want a system that behaves more like a lottery or a system that behaves more like “I hold STX and do work that is useful to the network and get a predictable payout from the network each month”.
We can certainly discuss modifications to the two approaches where they start looking a bit more like each other but the lottery vs predictable monthly payouts for work is a central design question. SIP-007 is in the camp of predictable monthly payouts for work. Interesting to explore randomness and how that impacts potential Stackers and their incentives.
I like the data reduction aspect of this. The 5000 miners number looks very high to me and might not be realistic, especially in the initial year(s).
Large crypto projects struggle to get full-nodes in that range and having independent miners in 5K range is even harder. We’re currently debating a minimum threshold for no. of miners that can trigger a switch from Stacks 1.0 to Stacks 2.0 and are debating 10-20 miners as a range.
Glad you like that! Would be awesome to cut the data usage in half.
The part I think is an even bigger improvement with the proposal is the enormous increase in payout frequency.
(I used the 5000 figure for number of miners but we can do thought experiments with other orders of magnitude)
Let’s assume 5000 addresses at 0.02% holdings each.
And all that with 1/2 the amount of data transmitted on the blockchain.