Skip to content

Instantly share code, notes, and snippets.

@taoeffect
Last active August 11, 2018 00:22
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save taoeffect/9ff64cf78cf1408ec29f13ed39e534c9 to your computer and use it in GitHub Desktop.
Save taoeffect/9ff64cf78cf1408ec29f13ed39e534c9 to your computer and use it in GitHub Desktop.

Anyone-Can-Spend Transactions Creep Into Bitcoin

An increased use of anyone-can-spend (ACS) transactions in Bitcoin has potentially dangerous repercussions for its future.

ACS in Drivechain

DISCLAIMER: This is my current understanding, and as Drivechain evolves it might change.

Normal bitcoins cannot be stolen by anyone. You need the private key to spend them. Even a 51%+ coalition of miners cannot spend them (but they can censor them).

Anyone-Can-Spend txns, OTOH, are txns that... anyone can spend.

They have been used to introduce new features via soft-fork, like Pay-To-Script-Hash (P2SH) transactions, SegWit transactions, and most recently, transactions associated with Drivechain.

Not All Anyone-Can-Spends Are Created Equal!

For example:

  • P2SH transactions contain all of the data needed for upgraded full nodes to validate them. A P2SH transaction can only be spent according to the result of the associated script. Full nodes are able to determine whether the script and transaction were executed properly.
  • Similarly, SegWit transactions are fully validated by running full nodes (with some caveats), and contain (at some point) all of the data within the transaction for upgraded full nodes to validate them.

Drivechain transactions, OTOH, do not contain the information full nodes need to validate them.

Instead, the network relies on trusting miners to not steal the transactions.

True, people who run full nodes can check SPV proofs to determine, for example, whether a Sidechain->Mainchain withdrawal transaction (called WT^) has been accepted by the sidechain.

However, we run into several very serious problems, starting in order of least severe to most severe:

  • Merge-mined sidechains can be "taken over" by the miners controlling the main chain, and thus a "valid-invalid" WT^ can be created to steal coins from the sidechain that generate "valid" SPV proofs.
  • Supposing an invalid WT^ is created with no valid SPV proof. Well, most main-chain nodes operators are unlikely to be monitoring every sidechain to check the SPV proof. Thus, even if the SPV proof can be determined to be invalid by some full node operators, there is nothing preventing the theft from occurring.

Here's a critical point: even if blocks containing invalid WT^ transactions were rejected by those "properly monitoring" the sidechain and main chain, doing so would result in those "good citizen" main-chain nodes getting forked off of the main network, and therefore there is no incentive for those node operators to reject the blocks containing provably invalid WT^ transactions.

Thus, as far as I can tell, Drivechain SPV proofs appear to be kinda useless. If anyone wants to correct me on this, I'm all ears!

Unnecessary and Unnecessarily Complicated

With regards to Drivechain, I think it is unnecessary, not to mention extremely overly complicated.

I feel fairly confident that better solution(s) will come along using different approaches. I have one bouncing around in my head that I'd like to fully spec out and write down, and if I have something in my head, it's likely people smarter than me do too.

ACS in general

ACS has been used as a "hack" to introduce new features into bitcoin. We are now seeing this hack being used in new ways where the security guarantees associated with owning a Bitcoin can be chipped away at.

This feels "dirty" to me and is something to keep an eye on. Improper use of ACS transactions also creates a potential network-split risk for Bitcoin.

Any Bitcoin altcoins or HFs would likely do well to simply eliminate this entire method of "feature introduction" and create a better one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment