{"id":24474,"date":"2024-03-08T17:01:20","date_gmt":"2024-03-08T17:01:20","guid":{"rendered":"https:\/\/bitcoins-101.com\/2024\/03\/08\/an-interview-with-polyd-the-rabbit-hole-of-covenants\/"},"modified":"2024-03-08T17:01:20","modified_gmt":"2024-03-08T17:01:20","slug":"an-interview-with-polyd-the-rabbit-hole-of-covenants","status":"publish","type":"post","link":"https:\/\/bitcoins-101.com\/2024\/03\/08\/an-interview-with-polyd-the-rabbit-hole-of-covenants\/","title":{"rendered":"An Interview With Polyd: The Rabbit hole of Covenants"},"content":{"rendered":"

Have you fallen into the \u2018rabbit hole\u2019 of covenants?<\/strong><\/p>\n

Interviewer:<\/strong><\/em> Hua, freelance writer, independent researcher. X: @AmelieHua<\/em><\/p>\n

Interviewee:<\/strong><\/em> Poly, a Controls Specialist, maintains multiple Distributed Control Systems (DCS’s) and has worked with other five nine systems (99.999% uptime availability). X: @Polyd_ <\/em><\/p>\n

Covenants are an old yet fresh topic. As early as 2013, developers began discussing this topic, and in recent years, multiple BIPs aimed at implementing covenants have been proposed, sparking intense debates and making it one of the hottest topics.<\/p>\n

Covenants warrant serious discussion due to their powerful capabilities. They are considered to bring new possibilities to the programmability of Bitcoin and are believed to enable smart contracts. For Bitcoin, this is undoubtedly a double-edged sword. In this article, we will explore what covenants are, how they work, their robust functionality, and their significance for Bitcoin. While discussing details, this article often uses CTV as an example, but CTV is not the only method of implementing covenants.<\/p>\n

This article delves into the exploration of covenants but also magnifies a slice of Bitcoin under a microscope for observation. Through this observation, we can understand how Bitcoin operates at a granular level, comprehending both its capabilities and limitations. Understanding what it cannot do is as crucial as understanding what it can do because only then can we choose the right path for building on Bitcoin.<\/p>\n

1.<\/h2>\n

Hua:<\/strong><\/p>\n

Before discussing covenants, clarifying two issues related to Bitcoin may be necessary, which can help us better understand covenants.<\/p>\n

We know that Bitcoin uses a scripting language, and it is known that scripting languages support the implementation of smart contracts. However, in reality, smart contracts have not been implemented on the Bitcoin main chain. This inevitably creates a sense that implementing smart contracts on Bitcoin faces some insurmountable obstacles, and it seems impossible on the Bitcoin network.<\/p>\n

However, many people may not be aware that although Bitcoin can be programmed using a scripting language, the set of opcodes is extremely limited. This limited set of opcodes restricts the programmability scope of Bitcoin, meaning that, although the scripting language can implement smart contracts, programmers do not have sufficient “tools” to implement smart contracts.<\/p>\n

Poly:<\/strong><\/p>\n

Definitely, Bitcoin Script can be considered limiting as it can only perform the basic operations such as making simple payments. Some of the reasons that people may find it \u201climiting\u201d is that it doesn\u2019t have a global state, it\u2019s not considered turing complete, it uses a UTXO-based system (which has \u201cvalue blindness\u201d) instead of an account-based system. The last big reason is that very little data from the blockchain itself can be integrated into contracts causing blockchain-blindness.<\/em><\/p>\n

This has created a lot of challenges over the years as people have worked around these limitations. We\u2019ve also had a semantic shift with the term \u201csmart contract\u201d to mean one specific thing when you should consider the lightning network a production of many smart contracts formed by many individuals. Those multi-sigs with hashlocks and timelocks are not only smart contracts, but also have time-based covenants. <\/em><\/p>\n

The problem is, just as you mentioned before, because Bitcoin only has simple opcodes to perform just the basics, if you attempt to scale beyond two people in a smart contract, you can get either a lot of bloat for an on-chain footprint or the things you want to do just might not be possible. This strict limitation comes from a few places, I think the biggest being that when the inflation bug occurred back in 2010, Satoshi had disabled a whole list of higher order opcodes including OP_CAT which would\u2019ve allowed us to create more dynamic smart contracts via transaction introspection.<\/em><\/p>\n

BCH has since overcome this limitation within their own script, showing that Script isn\u2019t as weak as everyone assumes, just that Bitcoin has always been slower due to its decentralization and coordination is near impossible except over long periods of time. We\u2019ve also barely touched on Taproot and Tapscript which will alleviate a lot of the footprint concerns and allows for new behaviors such as BitVM by rolling up the contract into the signature and you only reveal as necessary.<\/em><\/p>\n

Hua: <\/strong><\/p>\n

Why are there strict limitations on opcodes? Can you use OP_CAT as an example to help us understand this point? <\/p>\n

Poly: <\/strong><\/p>\n

So OP_CAT is deceptively simple, it will take two strings and add them together. It was originally disabled because it had resource issues and could be used to cause nodes to crash, but I\u2019m not sure if that\u2019s the full story as Satoshi set the 520 byte stack limit <\/em>and<\/em> disabled OP_CAT in the same commit so there could be more to it than just simple resource exhaustion.<\/em><\/p>\n

But just to give a short list of what OP_CAT can perform: CTV\/TXHASH covenants, verify SPV proofs, double-spend protection for 0-conf TXs, 64-bit arithmetic, vaults, quantum-resistant signatures. The list goes on, with OP_CAT alone, it can emulate both CTV[CheckTemplateVerify] and TXHASH style transactions. The only issue is it\u2019s highly inefficient in the manner that it performs these actions that might be possible, but that could just preclude these transactions from being desirable except by users of scale such as custodians.<\/em><\/p>\n

2.<\/h2>\n

Hua: <\/strong><\/p>\n

Let’s talk about another “limitation” of Bitcoin. Bitcoin only supports “verification” as a form of computation and can’t do general-purpose computation.<\/p>\n

We also know that, for example, smart contracts on Ethereum contain rules for state transitions. It completes the state transition through computation, enabling the functionality of smart contracts. In comparison, Bitcoin can’t do general-purpose computation, meaning it cannot achieve state transitions through computation on its own.<\/p>\n

Is my understanding correct? <\/p>\n

Poly:<\/strong><\/p>\n

Yeah, I\u2019d agree that\u2019s a simple summary of the current state of things. Bitcoin could be made to support computational transactions and the line can become quite thin when covenants and state transitions are involved, but those proposals aren\u2019t as well researched and might not be something that\u2019s considered desirable.<\/em><\/p>\n

I\u2019m actually not that much of a fan of the way Ethereum does things. Due to it being computational in nature with the verification built on-top, if I attempt to perform a trade, my window could shift and I could \u201cfail to trade\u201d but the transaction for the attempt to trade was still valid so i still paid for fees which wasted my money on what i\u2019d want to consider a failed transaction and wasted blockspace for someone else. Another weird aspect are the Oracles in Ethereum. Oracles must pay gas to update their oracle prices whereas in Bitcoin DLC\u2019s, the Oracle are blinded and are just providing a signature and can\u2019t be \u201cpinned\u201d due to a change in fees nor can Oracles target specific contracts.<\/em><\/p>\n

Earlier I discussed all the downsides to the UTXO model compared to the account model and global state model, but what allows the UTXO model to shine is parallelism. The only concern you have is the child transactions to the same UTXO, nothing else matters, this allows the system to scale much better. <\/em><\/p>\n

3.<\/h2>\n

Hua:<\/strong><\/p>\n

Let’s start discussing covenants now. What are covenants?<\/p>\n

Poly:<\/strong><\/p>\n

Covenants usually refer to restrictions on how coins can be transferred. The word covenant seems to carry some sort of connotation with it so it helps to demystify it and explain it as simple locking mechanisms you can place only on your *own* coin.<\/em><\/p>\n

We have two covenants already inside Bitcoin and they power the Lightning Network, CSV [CheckSequenceVerify] and CLTV [CheckLockTimeVerify]. Some just call these opcodes \u201csmart contract primitives\u201d as they\u2019re simple time locks, but they can also be classified as time covenants. <\/em><\/p>\n

CTV [CheckTemplateVerify] is a proposed Bitcoin upgrade and is included in BIP 119. It is different from CSV and CLTV, you can think of CTV as a \u201cTXID [Transaction ID] lock\u201d or \u201cUTXO lock\u201d, only these TXID\u2019s can be made from this lock. For CTV, we refer to this TXID lock as \u201cEquality Covenants\u201d as the resulting transactions must equal to the original transactions that were committed. It\u2019s also called a deferred commitment covenant, as you can see that your UTXO has been committed to, but it isn\u2019t yet placed on-chain. <\/em><\/p>\n

The most known alternative is SH_APO [Any Previous Out or AnyPrevOut] which focuses on the payout commitment being ensured while allowing the pay-in method to be flexible. A few others discussed are OP_CCV [also known as MATT], OP_EXPIRE, TXHASH and TEMPLATE KEY. <\/em><\/p>\n

Hua:<\/strong><\/p>\n

When you mention “covenants usually refer to restrictions on how coins can be transferred,” can I understand it like this: Covenants are a method of specifying how funds can be used, or in other words, it’s a way of restricting where funds can be spent.<\/p>\n

Poly:<\/strong><\/p>\n

Yep, it effectively earmarks the UTXO to be distributed in a specific manner, once you commit to it, you can’t take it back, it’s now consensus bound, and only its new owner can decide how to spend their funds.<\/em><\/p>\n

When a UTXO is created on-chain, our instinct is to assume that a single private key is holding that UTXO in place. But if it was a CTV bound UTXO, when the UTXO is spent, you’ll see an extra 32 byte hash paired with the new transaction that represents the hidden state that was inside the original UTXO.<\/em><\/p>\n

Hua:<\/strong><\/p>\n

You’ve mentioned “TXID lock\/UTXO lock” multiple times. Can I understand it like this: To understand how CTV achieves their functionality, we need to understand what TXID lock is and how it works. TXID lock is a key mechanism.<\/p>\n

Poly:<\/strong><\/p>\n

Yes, It creates a strong foundation to build further schemes. The TXID is determined by the contents of a tx. And if you can add inputs to a tx, you can manipulate the TXID. CTV makes you lock the number of inputs and outputs. This is how we ensure that CTV commitments are trustless, if the TXID could be malleable, you could potentially be able to steal someone\u2019s funds. Once you have a TXID locking mechanism, you combine it with other locking mechanisms such as the time locks to build even greater smart contracts. <\/em><\/p>\n

4.<\/h2>\n

Hua:<\/strong><\/p>\n

Why do you think covenants are a rabbit hole?<\/p>\n

Poly:<\/strong><\/p>\n

I call covenants a rabbit hole because there\u2019s so much you can do with simple restrictions on transactions such as a time lock or a TXID lock. We\u2019ve managed to build the entire Lightning network with simple time locks and while it isn\u2019t perfect, it is the only truly decentralized L2 in existence. I don\u2019t like how it\u2019s slowly shifting towards being custodial focused, but that\u2019s exactly why I\u2019ve started down this rabbit hole to begin with: To make our smart contracts more powerful. We refer to the TXID lock as a Template. With Taproot, we gained the ability to have signature aggregation. With Templates and CTV, we gain the ability to have transaction aggregation.<\/em><\/p>\n

CTV serves as a replacement for a pre-signed transaction oracle, which eliminates the trust and interactivity requirements needed to create more sophisticated smart contracts that are needed for things like vaults and payment pools. The vaults and payment pools that you can make with CTV are technically possible today, but <\/em>currently<\/em> they\u2019re precluded by the trust or interactivity needed to make it work. Moreover, with CTV, we can build channel factories, additional layer 2 solutions such as Ark, Timeout-Trees, Stakechains or Surfchains, and JIT fidelity bond solutions such as PathCoin. <\/em><\/p>\n

Probably my favorite feature is Non-Interactive Channels [NIC\u2019s] that we\u2019ve also been referring to as Cold Channels. The basic idea is to take a normal lightning channel and simply place it in a CTV template. What makes this different from a normal lightning channel is that neither party actually needed to be online to create this channel. So if I need a channel with another person, I don\u2019t need them to be online to create it, I don\u2019t even need to tell them I made it until I\u2019m ready to spend from it! This allows for cold storage capability on lightning because I don\u2019t need a watchtower nor a node to safeguard my funds in any channels that aren\u2019t yet active. Third-party coordinators can also establish NIC\u2019s for two individuals so there\u2019s a lot of flexibility in what\u2019s possible.<\/em><\/p>\n

As it stands, CTV won\u2019t allow you to build a DEX on-chain, but I\u2019m not sure if that is such a bad thing as people are currently trying to build DEX\u2019s off-chain using the Lightning Network as it is today. I think this ties back into the \u201cVerification vs Computation\u201d discussion, how much do you really want on-chain versus how much do you need to verify on-chain. One concern I have about on-chain DEX\u2019s, besides the excessive on-chain updates driving higher fees, is MEV. We\u2019ve already spotted some MEV from BCH\u2019s DEX\u2019s transactions and as the market matures, this is bound to get worse.<\/em><\/p>\n

Hua:<\/strong><\/p>\n

Can you give an example to help us understand how CTV works?<\/p>\n

Poly:<\/strong><\/p>\n

Let\u2019s say I am expecting to receive 5 BTC, as of right now, the only thing I can do is receive the payment and verify it on-chain. With CTV, I can commit to future addresses or to people and reduce it down to a simple pubkey that I give to my payer to pay me. They don\u2019t know the details of it so it remains private to everyone but me. Once I can confirm that they\u2019ve paid me, all of the actions I took using the CTV template have now also taken effect.<\/em><\/p>\n

So if I had elected to create a channel with Bob, once Alice pays me, the channel with Bob is now committed, even though the channel with Bob is nowhere to be seen on-chain, it is only accessible by my template and the transaction that Alice had created. It\u2019s only known to me until I share the channel details with Bob. Once I do share the details with Bob, we can use the channel as normal. When we cooperatively close the channel, instead of needing to place an open channel details on-chain, we just place the closing channel on-chain. This allows us to perform transaction cut-through, reducing the total number of transactions that need to be on-chain by at least half for layer 2 solutions.<\/em><\/p>\n

The opening portion only needs a commitment, what we really care about are the closing details. If this was a shared UTXO with multiple people, we could collaborate to close our transactions together as well, reducing the number of on-chain transactions even further.<\/em><\/p>\n

5.<\/h2>\n

Hua:<\/strong><\/p>\n

As you mentioned before, we can introduce different opcodes to implement covenants.<\/p>\n

Poly:<\/strong><\/p>\n

So if we re-introduced OP_CAT, I think it would allow for nearly every type of covenant possible as you can emulate any form of introspection for TXHASH. The more limited method would be to introduce opcodes representing the explicit behavior desired like with CTV, CSFS or CheckSeperateSignature. CTV is the ability to do deferred outputs. CSFS is the ability to do deferred signatures so you can defer the payment itself. They sound similar and in fact they work well together as building blocks to enable LN-Symmetry, but the commitments are happening at different levels.<\/em><\/p>\n

TXHASH and TEMPLATE KEY both enable introspection and serve the same purpose, but TEMPLATE KEY uses a single-byte mode while TXHASH uses multi-byte flags. This allows for much more powerful capabilities inside script and smart contracts, but many are concerned about the side effects it could have. TXHASH and TEMPLATE KEY are more of a CTVv2, something that would make CTV more powerful and expressive.<\/em><\/p>\n

Hua:<\/strong><\/p>\n

I’ve noticed that there doesn’t seem to be a significant disagreement about whether to support the implementation of covenants. However, in comparison, there seems to be more significant divergence among people regarding which method or set of opcodes to add to implement covenants.<\/p>\n

Poly:<\/strong><\/p>\n

I think a large part is there\u2019s different camps of thought. There\u2019s a lot of the lack of understanding the intent behind each proposal as they have different goals in mind and are designed in completely different ways. <\/em><\/p>\n

A lot of developers have only had their eye on Lightning and how it\u2019s to evolve, they tend to favor opcodes like SH_APO since it enables LN-Symmetry. For a lot of developers that don\u2019t particularly like Lightning due to its limitations such as Inbound Liquidity constraints or the requirement to be online, they tend to favor opcodes like OP_CAT, TXHASH as more expressive scaling solutions. The developers that prefer CTV are more neutral and are looking at it from a systems point of view, it doesn\u2019t necessarily do any one thing perfectly but it greatly enhances everyone\u2019s ability to do their preferred thing, whatever it may be without introducing risks that can\u2019t be measured since it doesn\u2019t introduce introspection.<\/em><\/p>\n

6.<\/h2>\n

Hua:<\/strong><\/p>\n

Before discussing covenants, we talked about issues related to opcodes in scripting language and the problem of limited computation leading to state transition. We already know the relationship between covenants and opcodes. Now, let’s delve into the issue of state transition. I’m not sure if looking at covenants from the perspective of “state transition” is correct, but this perspective truly fascinates me. <\/p>\n

Without covenants, the scripting language’s main function is to retrieve transactions’ signatures and verify them. The transaction can only be completed when the private key is correct, and there is no intermediate state. With covenants, a transaction can be completed when certain conditions are met. Moreover, a transaction can only be completed when specific conditions are satisfied (not just the correctness of the private key). Can we understand it this way: Covenants indirectly provide conditions for state transition.<\/p>\n

Poly:<\/strong><\/p>\n

The covenant is the template shell or the “state”. Inside of it, you’re going to need to make time locks and other functions to enable the desired functionality that you\u2019re wanting, be that a vault, lightning channel or some other layer 2 solution.<\/em><\/p>\n

So CTV allows for the state creation to occur, but you have to dynamically rebuild the state at each transition to keep it in homeostasis, we call this meta-recursive. Whereas something like SH_APO allows you to create a state and then periodically update that state, making it recursive. CTV can also create a chain of transactions that would allow you to \u201cstep-through\u201d that state. <\/em><\/p>\n

A good example to think about is Ark, it\u2019s a giant smart contract, almost like a giant coinjoin and the one running the protocol creates a new state [or rounds as it\u2019s called] every few seconds to facilitate participants to pay others as needed. Once the Ark operator is ready, they will send a transaction to the mempool to commit the current state to on-chain. These on-chain placeholders can be thought of as the \u201ctransition states.\u201d The operator has to constantly recompute new states to present to the Ark participants and what\u2019s sent to on-chain is the verification of that state.<\/em><\/p>\n

Hua:<\/strong><\/p>\n

Can we understand it this way: Covenants implement a form of smart contract based on verification rather than computation?<\/p>\n

Poly:<\/strong><\/p>\n

Yes. Definitely. This smart contract is just comparing a transaction to an associated sha256 hash. Block speed verification would actually increase since there\u2019s no signature operations. <\/em><\/p>\n

Hua:<\/strong><\/p>\n

One direction of development for blockchains is modularity, including off-chain computation. However, Bitcoin seems naturally designed for off-chain computation, appearing behind but actually leading the way. What do you think?<\/p>\n

Poly:<\/strong><\/p>\n

Time is a flat circle. It\u2019s crazy how it seems like we\u2019ve come full circle to what\u2019s wanted in a blockchain. Bitcoin still seems to have some modularity issues and footprint issues. I wish we had better side-chains that weren\u2019t simply multi-sig solutions and used actual cryptographic means to secure one\u2019s funds and allowed for Unilateral Exits. I think that would help push the boundaries on Bitcoin\u2019s modularity. Taproot has allowed for even more off-chain computation with things such as BitVM, which would allow us to compute almost anything off-chain. But unfortunately, it can\u2019t emulate things inside Bitcoin such as CTV so it seems we still have progress to make.<\/em><\/p>\n

7.<\/h2>\n

Hua:<\/strong><\/p>\n

What possibilities can be achieved by combining covenants with other opcodes like DLC?<\/p>\n

Poly:<\/strong><\/p>\n

So DLC\u2019s have a few problems that would be fixed with covenants such as increasing the flexibility of the parameters of the DLC by making many price points [if we\u2019re wagering on the price of something such as Bitcoin]. Another one is that hardware wallets [HWW] can\u2019t interact with a lot of DLC\u2019s, the signing rounds for DLCs and attempting to do it with HWWs causes DLCs to take several minutes to open. With CTV, this delay to enter a DLC can be reduced down to seconds. <\/em><\/p>\n

8.<\/h2>\n

Hua:<\/strong><\/p>\n

Are there any other points you’d like to introduce to the readers?<\/p>\n

Poly:<\/strong><\/p>\n

We went over a lot of concepts. We touched on how it can be used to mitigate excessive blockspace demand and potential ddos attacks. We discussed how people could save space by making Non-Interactive Channels. I think another good one to discuss is the “L2 exit problem”. If we managed to get everyone off of the L1 layer and get them onto a large L2, there’s currently no good way to get people off that L2 in an expedited manner. We could think of that L2 as Lightning [we call the potential mass exodus on Lightning, the “Thundering Herd problem\u201d], or we could think of Coinbase, Binance or Liquid as the L2. There are people who hold claims to Bitcoin, but their only way to actually acquire that claim is by submitting a transaction to get it placed on-chain. There’s millions of people on Coinbase, I have no idea how to get them off of there and onto Bitcoin in any orderly fashion in today’s environment. There would be a mempool backlog of 6 months attempting to get people off the exchange. CTV can fix this. <\/em><\/p>\n

Make an Ark or a Timeout-Tree with CTV. The exchange could even offer the service directly. Everyone could be offloaded from the original “shared UTXO” that was under Coinbase’s consensus and pushed into a “shared UTXO” with a consensus of their choice, be it a simple pool or a large Timeout-Tree. This is where it really wrinkles the brain, this was a pure L2 L2 conversion. There was no intermediary step requiring me to go down to L1 first. And I can continue repeating this process indefinitely, using any layer of my choice. There isn\u2019t a need to return to the base layer unless I was forced there such as from an uncooperative closeout from my channel or perhaps an unvaulting from my vault. The Ark and Timeout-Tree pitfall is that they have rollover requirements, you have to move your funds every few weeks or months or you forfeit your funds. This isn\u2019t an ideal solution for long-term funds but works great for any short term holdings and larger markets.<\/em><\/p>\n

I’d like to provide a full list of every concept that\u2019s been developed using CTV and its ability to simply aggregate pre-signed transactions: Non-Interactive Channels, Timeout-Trees, Ark, Darkpools, Payment Pools, Payment Channels, Ball Lightning, Congestion Control, Dpool’s, Compaction, Tree Swaps, PathCoin, Stakechains, Surfchains. But don\u2019t think of these as all independent Templates, if there\u2019s a feature of one that you wish to include in another, you can create your own custom Template to try and find your desired behavior. <\/em><\/p>\n

References:<\/strong><\/em><\/p>\n

Owen’s Covenants 101 https:\/\/x.com\/OwenKemeys\/status\/1741575353716326835<\/a><\/p>\n

Owen’s Covenants 102 https:\/\/x.com\/OwenKemeys\/status\/1744181234417140076<\/a><\/p>\n

Owen\u2019s CTV Demo https:\/\/x.com\/OwenKemeys\/status\/1752138051105493274<\/a> <\/p>\n

Dallas’s Primer https:\/\/x.com\/dallasirushing\/status\/1740443095689318566<\/a><\/p>\n

Batching Lightning Channels Required Covenants https:\/\/lists.linuxfoundation.org\/pipermail\/bitcoin-dev\/2023-October\/022006.html<\/a><\/p>\n

Timeout-Trees https:\/\/lists.linuxfoundation.org\/pipermail\/bitcoin-dev\/2023-September\/021941.html<\/a><\/p>\n

Ark https:\/\/www.arkpill.me\/<\/a><\/p>\n

Darkpools https:\/\/gist.github.com\/moonsettler\/6a214f5d01148ea204e9131b86a35382<\/a><\/p>\n

PathCoin https:\/\/github.com\/AdamISZ\/pathcoin-poc<\/a><\/p>\n

This is a guest post by Aemlie Hua. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.<\/em><\/p>","protected":false},"excerpt":{"rendered":"

Have you fallen into the \u2018rabbit hole\u2019 of covenants? Interviewer: Hua, freelance writer, independent researcher. X: @AmelieHua Interviewee: Poly, a Controls Specialist, maintains multiple Distributed Control Systems (DCS’s) and has worked with other five nine systems (99.999% uptime availability). X: @Polyd_ Covenants are an old yet fresh topic. As early as 2013, developers began discussing […]<\/p>\n","protected":false},"author":0,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-24474","post","type-post","status-publish","format-standard","hentry","category-crypto-news"],"_links":{"self":[{"href":"https:\/\/bitcoins-101.com\/wp-json\/wp\/v2\/posts\/24474"}],"collection":[{"href":"https:\/\/bitcoins-101.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/bitcoins-101.com\/wp-json\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/bitcoins-101.com\/wp-json\/wp\/v2\/comments?post=24474"}],"version-history":[{"count":0,"href":"https:\/\/bitcoins-101.com\/wp-json\/wp\/v2\/posts\/24474\/revisions"}],"wp:attachment":[{"href":"https:\/\/bitcoins-101.com\/wp-json\/wp\/v2\/media?parent=24474"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/bitcoins-101.com\/wp-json\/wp\/v2\/categories?post=24474"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/bitcoins-101.com\/wp-json\/wp\/v2\/tags?post=24474"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}