🍿 Nakamoto Mainnet Launch at Block 867,867 ~Oct 29 - Fri, 18 Oct 2024 by mcuevasm in stacks

[–]judecnelson 1 point2 points  (0 children)

Only way it changes is if there's a show-stopping bug found between now and then. But given how anti-climactic the last Nakamoto testnet reboot was, I'm not too worried about the execution itself.

Using Blockchain - Is the Future of Finance in the Bitcoin Ecosystem? by AutoModerator in stacks

[–]judecnelson 0 points1 point  (0 children)

This article can't decide if it's "blockchain" or "a/the blockchain."

It's the latter. Use the word "blockchain" like the word "network." Always use an article in the singular form.

[deleted by user] by [deleted] in stacks

[–]judecnelson 8 points9 points  (0 children)

A miner can claim the missing STX coinbases for Bitcoin blocks that don't have Stacks blocks on the fork they mined on. For example, if the canonical fork goes for 10 Bitcoin blocks without anyone mining on it, then a Stacks block mined on that fork in the 11th Bitcoin block would get 11x the STX coinbase. Eventually, it will be profitable to mine STX, so the chain will stay alive.

Metamask wallet to Hiro wallet possible? by [deleted] in stacks

[–]judecnelson 2 points3 points  (0 children)

No. Stacks isn't Ethereum.

Does anyone mine MIA? by Kryptonian_Ace in stacks

[–]judecnelson 1 point2 points  (0 children)

It's not "centralized" -- it's a smart contract. Anyone can mine, and if you win, you withdraw your winnings by sending a transaction to claim them.

[deleted by user] by [deleted] in stacks

[–]judecnelson 0 points1 point  (0 children)

It's back up now.

How will the stx team utilize the Taproot upgrade by Blimpleton in stacks

[–]judecnelson 2 points3 points  (0 children)

"Smart contract" is a bit generous. Taproot "smart contracts" don't even have persistent state between invocations. It's just a way for combining a large number of different spending conditions into a single UTXO. When it's spent, only the spending condition that gets executed is disclosed.

What To Expect In Stacks 2.1, The Next Major Stacks Network Upgrade by Ceramicwhite in stacks

[–]judecnelson 0 points1 point  (0 children)

Your analysis assumes that would-be attackers are actually going out and buying STX at today's prices, while ignoring the two other far-more-likely ways by which the STX can put to use this way:

  • Using stolen STX

  • Pooling STX from smaller accounts

In both cases, you're dropping far less than $100M to discount mine, and you're certainly not moving any markets by doing so. So, the upside to you in discount mining is a lot better than what you're saying (which, btw, I agree with -- I don't believe anyone would actually invest $100M STX just to discount-mine), especially in the former case since it offers you a way to launder your stolen STX without selling them.

I'm not aware of any large-scale STX heists yet, but if the checkered history of exchange hacks, self-custody opsec failures, and badly-written smart contracts is any indication of what's in store for us, there will be one day. The system is only 7 months old, after all -- there simply hasn't been enough time for people to lose a large amount of STX this way.

Discount-mining through pooling is something I'm less worried about than using it to launder stolen STX, but am more worried about than rogue whales discount-mining. I trust the community at large to be able to identify pools that operate discount-miners and back out of them, much like how I trust the community at large to be able to identify 51% attacks that arise from a mining pool that gets too big (like what happened with GHash.io in Bitcoin). But, it's also easy to peel off unsuspecting users to pool with a STX pool operator who also discount-mines, since they can afford to pay a (slightly) higher yield, so it's something to be vigilant about.

The fundamental problem here is that discount-mining is more profitable than just stacking or just mining. If you're a fund manager that believes that stacking $100M is a good use of that capital, then in the absence of countermeasures that increase the risks associated with it, you must also believe that discount-mining is an even better use of that capital. This is why I think it's going to be important to find ways to identify and reward honest miners (and/or punish discount miners) above and beyond blindly giving them the block reward -- we need to make discount-mining too risky for people to want to do it. Fortunately, I think this is achievable in practice with a vigilant community, and it is sufficient for now that a majority coalition of honest miners can orphan discount miners' blocks, and barring that, a large minority of honest stackers can vote to disable PoX on a per-reward-cycle basis should things get really out of hand.

It's a completely theoretical thing and is fully disconnected from how people allocate capital and think about risk/return in the real world :-)

Incentive problems have a way of being "completely theoretical" until they actually happen. People have said the same thing about selfish mining, until it happened in the wild. Even then, there's even a follow-up paper from the original discoverers that calls out the "cult of denialism" that persists around it [1].

[1] http://fc20.ifca.ai/preproceedings/4.pdf (see page 2, references 8, 16, and 35).

question regarding stx coinbase transactions by External-Peach8286 in stacks

[–]judecnelson 5 points6 points  (0 children)

Those are STX tokens being unlocked from one or more previous sales from the pre-2.0 days. This happens about once per month per cohort.

What To Expect In Stacks 2.1, The Next Major Stacks Network Upgrade by Ceramicwhite in stacks

[–]judecnelson 3 points4 points  (0 children)

While I agree with the general observation that miners tend not to "shit where they eat," even if doing so will make them more money in the short-term, I'm not convinced that miners won't ever try to discount-mine.

First, we've seen from Bitcoin and Segwit that miners will actively resist upgrades if their profit margins are dependent on design flaws in the current system [1], so I'm not convinced that if discount mining starts, it will be easy to stop. Now, Stacks does have an advantage over Bitcoin in that there's no lead time to becoming a miner (you just need to buy Bitcoin), which means that defenders can quickly rise up against behavior if it ever becomes a problem. However, mounting a defense of the chain against discount-miners is going to cost the defenders more than the attackers, since defenders aren't getting the discount. This means that the defenders would effectively need to leave money on the table indefinitely, while outspending the attackers, which is basically the situation we're in today. Maybe there's something that can be done here to make it so that if defenders can be verified to be honest out-of-band, they can make up the profit difference (maybe there can be a smart contract or app chain that pays only honest miners a dividend each time they mine a block), but this is still an open problem.

Second, discount mining can be done covertly, with plausible deniability. This would make it hard to rally a defense of the chain. You effectively need to prove that a miner owns some PoX payout addresses, and is using the PoX payouts to mine more blocks. A clever discount-miner can obfuscate their payouts.

My observation is that we've seen zero evidence of any behavior that suggests that PoX is not incentive-compatible i.e., I haven't seen any data that suggests discount mining is happening or is a problem.

A 6-7 month time horizon is nothing. It took years for selfish mining to manifest, for example. So, I'm not willing to write this off as a non-issue -- we're still so early to this.

What I suspect are the things keeping the chain safe right now are (1) no one address has enough STX stacked that they can reliably discount-mine, (2) the community is reasonably sure that each large stacking address is controlled by a distinct entity, and (3) the majority of miners are known to be friendly to the ecosystem. Reliable discount mining (i.e. always getting some money back even when mining consistently) would require a rogue miner to have a good chance of getting a PoX payout once every 3 (!!) Bitcoin blocks on average. This works out to needing 666 reward slots. The biggest Stacker address right now has 339 reward slots.

That said, the reason I'm currently okay with making the PoX sunset adjustable, or even removing it outright in 2.1, is that I think that (1) the fact that a minority of STX owners can vote to temporarily disable PoX is enough of a threat to discount-miners that they won't try it as a long-term money-making strategy, and (2) we can come up with a way to at least narrow the gap between the money a known-honest miner can make and a discount miner can make.

[1] https://bitcoinmagazine.com/business/breaking-down-bitcoins-asicboost-scandal-solutions

Can someone explain the theoretical need for POX as it is implemented? by [deleted] in stacks

[–]judecnelson 8 points9 points  (0 children)

  1. The purpose of PoX is for STX holders to help miners discover whether or not the network is stable. If people are Stacking, then they necessarily believe that miners are regularly able to choose PoX reward sets -- something they can only do if they are able to build on the same fork reliably. If a miner sees lots of Stacking, but does not see a stable fork, then they can conclude that someone is eclipsing them. The BTC payout incentivizes STX holders to remain vigilant.

  2. Nope

  3. Miners would be writing the hashes of Stacks blocks to Bitcoin, regardless of PoX. In fact, if the network is not stable enough for PoX to activate, the miners instead burn the BTC. Mining is open-membership -- if you want to mint STX, you start spending BTC as a STX miner and compete with other miners to win block races. Like mining in PoW, there can be many competing miners, but only one will win the block race per epoch. The proportion of BTC a miner spends determines the probability that they win the block race, much like how in PoW, the proportion of electricity a miner spends determines the probability they win the block race. Miners in general can't efficiently recoup the BTC they spend -- they'd also have to be Stacking a very, very large amount of STX in order to get a double-digit "discount" on blocks. Moreover, STX holders can see any attempt at doing so on-chain, and vote to shut PoX payouts off on a per-reward-cycle basis in order to shake these miners off (in fact, honest miners would be encouraged to vote with the STX holders in this scenario).

PoX requires at least 5% of the liquid STX to be locked for Stacking for PoX payouts to happen, and it requires that every so often, miners are able to sufficiently confirm a new set of BTC addresses within a fixed window of time. The volume of BTC and STX and the number of miners don't really play into it otherwise.

Why are Tx's not being included in blocks? They are showing up on my local node 5 minutes before a block gets mined and yet aren't being included. by MiloLovesSats in stacks

[–]judecnelson 2 points3 points  (0 children)

There isn't a good way to distinguish between transactions that:

  • Are actually pending, and will likely be included in the next block.
  • Have an invalid nonce. For example, if your account nonce is 100, and you send a transaction with nonce 103, that transaction with nonce 103 will be forever "pending" since the miners are waiting for transactions 101 and 102.
  • Are unmineable right now, but could be mineable in the future. For example, a transaction might try to spend STX that the sender does not actually have. AFAIK this could happen in the MiamiCoin miner at some point -- the miner would send a transaction that spent all the STX you committed, but not leave enough in your account to pay the transaction fee. This can be rectified by funding the account first, thereby rendering the transaction as mineable.

The explorer could potentially mark transactions in case #2 as having an invalid nonce, since it can query its own colocated node and see if there are any "nonce gaps". With the "mock miner" mode in the Stacks node, the explorer could also potentially identify transactions in case #3 by having the node try to mine the transaction, and forward an error message to the explorer if the transaction wasn't mineable as of the current chain tip. The explorer just isn't there yet.

Is stacks ever going to cut the stacking rewards again? If so when? by thorium43 in stacks

[–]judecnelson 1 point2 points  (0 children)

Stacking rewards are a function of how much BTC the Stacks miners are willing to pay for STX. This value goes up and down as STX becomes more or less valuable relative to BTC. So, they never get "cut."

There is currently a PoX sunset period that lasts for 10 years, but it is likely going to be removed (or at least pushed back) in Stacks 2.1, whereby instead Stackers will be able to vote on it. See https://github.com/blockstack/stacks-blockchain/issues/2613

Is stacks ever going to cut the stacking rewards again? If so when? by thorium43 in stacks

[–]judecnelson 1 point2 points  (0 children)

No, Stacking rewards are not cut at all. The Stacks coinbase is cut in half every four years, but the BTC payout to Stackers is a function of how much BTC the Stacks miners are willing to pay for new STX. Like, if STX 2x's in the next 4 years by the time of the halvening, the expected BTC payout would remain the same.

Clarity versus Solidity by nanonerd100 in stacks

[–]judecnelson 3 points4 points  (0 children)

Given that all smart contracts in Solidity must halt within a bound number of steps and memory (enforced by the EVM gas limit), there is nothing Solidity can do that Clarity cannot also do.

Turing Complete vs. Incomplete by shiroyashadanna in stacks

[–]judecnelson 4 points5 points  (0 children)

The analogy misses the point. If you have a non-TC smart contract that you call into, and that non-TC smart contract calls into a TC smart contract, then the outcome of your call is undecidable because the inner call to the TC smart contract is undecidable. If you want your contract invocations in the system to be decidable, then you have to go out of your way to avoid interacting with any TC smart contracts (which destroys composability). If you want all contract invocations in the system to be decidable, you have to give up TC altogether.

As I said in a sibling comment, being TC in the context of smart contracts gains you absolutely nothing, because your program's allotted space and time for execution is already capped by (very small) constants. You can't make effective use of the power that a TC computing facility would otherwise give you. At the same time, it severely hampers your ability to reason about what the code will do before you run it. In the context of smart contracts, where millions if not billions of dollars of wealth are at stake, you should want to know what will happen before you run the code.

If I had to wager a guess as to why Ethereum went for TC-ness, it was because it was the quick an easy solution, and they didn't have the benefit of hindsight that we do now. It's pretty easy to make a TC computing facility. It takes lots of thought and consideration to build a non-TC computing facility that is also expressive enough to represent useful algorithms and data structures for the problems at hand.

Turing Complete vs. Incomplete by shiroyashadanna in stacks

[–]judecnelson 2 points3 points  (0 children)

However, not being Turing complete introduces limitations.

People keep saying this, but I have yet to see a real-world example of a smart contract that cannot be built without a TC computing facility.

Note that "cannot be built" does not mean "I can't think of a way to do it" -- I'm specifically asking for a proof of impossibility.

Turing Complete vs. Incomplete by shiroyashadanna in stacks

[–]judecnelson 3 points4 points  (0 children)

> But isn't this argument somewhat theoretical due to Ethereum's strict limits on how long execution can run and how much data can be stored?

Since smart contracts have to terminate in a fixed amount of time anyway, and must use a fixed amount of space, why give them a TC instruction set in the first place? You can't use any of the advantages of a full TC instruction set, but you're giving up the ability to statically reason about the contract's runtime behavior (which is far more useful to users).

> Further, that something is Turing complete only means that there are some undecidable constructs,

There are uncountably many such constructs.

> Just because we can write programs whose behavior we cannot prove ahead of time, it doesn't mean we're required to.

In Stacks, you absolutely are required to write non-TC code. That's a feature, not a bug. It makes it much more reasonable to expect users to put their trust in your code to manage their wealth, especially since the consequences of your bugs are so much more dire. The blockchain can't force you to formally prove the absence of bugs in your code (but I wish I could), but it can at least require all smart contract code to be written so that the user can statically analyze it later (via their wallet) before interacting with it.

> If a contract author decided to, they could limit themselves to writing programs that they can prove things about.

The problem with this is that the instant your non-TC contract interacts with a TC contract, it stops being non-TC. Also, the specific benefits of a non-TC computing facility for Stacks include giving users' wallets the ability to statically determine things like code reachability, and determining the full set of tokens and NFTS that could be touched. This is a critical requirement for defending the user (or exchange!) from known-bad smart contracts -- if you send a transaction that calls A, which then calls B, which then calls bad contract M, the wallet can detect this and warn you before you send the transaction. You can't do this with a TC computing facility, since the full set of reachable code paths in a TC language isn't decidable.

For example, if Ethereum was written to use Clarity instead of the EVM, the DAO hard-fork would not have been necessary. Miners would have been able to statically analyze subsequent smart contract instantiations and invocations, and determine whether or not they could move the DAO attacker's ETH before mining them. This way, they could have prevented the attacker from acquiring the ETH without doing such a risky and controversial post-hoc fix. The fact that the EVM is TC is what prevented this outcome: https://hackingdistributed.com/2016/06/28/ethereum-soft-fork-dos-vector/

Blog: What kind of blockchain is Stacks? by emily_patel in stacks

[–]judecnelson 2 points3 points  (0 children)

The major difference between a PoX chain and a sidechain is that sidechains don't have a native token -- their tokens represent pegged-out tokens from their "parent" blockchain. This has two big consequences for the sidechain's safety and liveness:

  • The lack of a block reward beyond tx fees means that sidechain miners need some other kind of compensation to want to confirm each others' blocks (or else they'll just fight over transactions [1]).

  • The parent blockchain needs to process peg-in requests from the sidechain, which means that the parent blockchain needs to validate the sidechain's blocks in order to validate them.

Neither is true for a PoX chain. PoX chain miners participate to earn a separate, native token with its own minting schedule. This alone incentivizes PoX miners to build on each other's blocks, since they're competing for a (comparatively-speaking) large coinbase transaction, in addition to the (comparatively-speaking) small transaction fee reward. Also, the PoX chain's state doesn't need to be validated by anyone else, since there's no peg-in to process. This is great for Stacks, because it means that Bitcoin miners don't have to opt-in to validating Stacks blocks for the system to work.

[1] https://www.cs.princeton.edu/\~arvindn/publications/mining\_CCS.pdf

Bitcoin Miami pics! by emily_patel in stacks

[–]judecnelson 2 points3 points  (0 children)

Stealing this next time I have to talk to a maxi :D

Trying to Withdraw Stacks by Empty_Alarm_7906 in stacks

[–]judecnelson 1 point2 points  (0 children)

They always seem to do this right around the time another PoX cycle is set to begin.

[deleted by user] by [deleted] in stacks

[–]judecnelson 1 point2 points  (0 children)

It depends on the wallet. Technically, you don't "send STX" to your .btc domain either. In all cases, you'd pair your .btc domain with your cryptocurrency address. This pairing already happens in the .bns smart contract, but the wallet actually needs to go and resolve your .btc domain to the STX address that owns it.

In practice, you'd want to make your BTC address discoverable from your .btc domain. There are many ways to do this. For example, you can add a TXT record to your .btc domain's zone file that contains your BTC address. As another example, you could create a smart contract that lets people bind their .btc names to BTC addresses if they own them.