{"id":3057,"date":"2019-11-24T23:49:22","date_gmt":"2019-11-24T23:49:22","guid":{"rendered":"https:\/\/bitcoinsv.io\/?p=3057"},"modified":"2020-09-28T07:00:47","modified_gmt":"2020-09-28T07:00:47","slug":"on-the-future-of-bitcoin-transaction-fees","status":"publish","type":"post","link":"https:\/\/bitcoinsv.io\/2019\/11\/24\/on-the-future-of-bitcoin-transaction-fees\/","title":{"rendered":"On the future of Bitcoin transaction fees"},"content":{"rendered":"\n<h2><em>New transaction fee toolsets coming to Bitcoin SV<\/em><\/h2>\n\n\n\n<p><strong>TLDR;<\/strong><\/p>\n\n\n\n<ul class=\"ml3vw\"><li><strong>Cheaper transaction fees, fiat stable pricing and a highly flexible framework for dynamic fee rate discovery are all on the horizon for Bitcoin SV.<\/strong><\/li><\/ul>\n\n\n\n<p>Since a recent price rise of BSV in fiat terms and the announcement of WeatherSV\u2019s transaction fee deal directly with a mining pool (Mempool), the subject of transaction fees has become a hot topic in the Bitcoin SV space &nbsp;&nbsp;It\u2019s an important topic to think through as BSV finally unlocks Bitcoin\u2019s massive scaling capability and has opened the door to new business models for use of the blockchain to record large and continuous volumes of data.&nbsp; Transaction fees on Bitcoin SV are still far less than on competing blockchains (especially BTC and Ethereum), but we can do more to ensure that fees are <strong>reliably low, <\/strong>so applications can properly plan their business models while miners are also economically agile.<\/p>\n\n\n\n<p>I\u2019ve discussed this issue with several mining groups and many Bitcoin app developers. There are some common themes and opinions about future direction along with a general consensus that the toolset we inherited from BTC and BCH-ABC for managing transaction fee rates is clunky and inflexible.&nbsp;<\/p>\n\n\n\n<p>We\u2019ll begin by examining the common concerns among both users and miners of Bitcoin SV. Then we\u2019ll survey the current state of play and what\u2019s possible with the existing transaction fee toolset before turning our attention to where that toolset is heading on BSV.&nbsp; Finally we will consider what can be done between now and when it is fully available.<\/p>\n\n\n\n<h2>Concerns<\/h2>\n\n\n\n<h4>Lack of fee discovery<\/h4>\n\n\n\n<p>It is astonishing that after 10 years, Bitcoin wallets still have no way to reliably determine what fees are required to get a transaction mined.&nbsp; Most rely on complex and unreliable mechanisms.&nbsp; This is partially a consequence of the Bitcoin Core model of a fee market where miners are price <strong><em>takers<\/em><\/strong> rather than price <strong>makers<\/strong>.&nbsp; Bitcoin SV turns this model on its head so there\u2019s no excuse for miners not to be able to provide definitive fee quotes barring an implementation.<\/p>\n\n\n\n<h4>Price too high<\/h4>\n\n\n\n<p>The current fee rate is inherited from the default in the Bitcoin ABC implementation for BCH.&nbsp; It is denominated in satoshis per byte and currently equates to about $1.20 USD per MB. There is no particular reason for this price level and it appears to be widely agreed among the BSV ecosystem that rate is currently too high for data transactions (as compared to payment transactions).<\/p>\n\n\n\n<h4>Fiat stability<\/h4>\n\n\n\n<p>When you build a business model based on an operational cost of X and the volatile BSV market makes that price jump to 2X overnight, it\u2019s very hard to make safe predictions about the viability of your business.&nbsp; Fiat stable pricing, e.g. $0.XX per MB, is something we\u2019ve heard many enquiries about from businesses seeking certainty.<\/p>\n\n\n\n<h4>We don\u2019t know the floor<\/h4>\n\n\n\n<p>No one really knows what the cost of processing a transaction is. It is very hard to model this as the inputs to the model are highly variable and some require guesses at future transaction volume.&nbsp; There are variable costs like cost\/MB-bandwidth-use that are relatively proportional to the amount of transactions; that\u2019s the easy part. The harder part are the fixed costs that must be amortised over many transactions without knowing exactly how many.&nbsp; There is some work beginning by some of the miners to start building these models and understanding the zones of risk.&nbsp; But it is only just beginning now because it\u2019s only just started to matter.&nbsp; Until this is better understood I predict there will be some reluctance by miners to lower costs in an extreme manner because it is much harder to ask the market to bear a later increase than is to continually lower prices until the floor is found naturally.<\/p>\n\n\n\n<h4>Disparities in data value<\/h4>\n\n\n\n<p>Suffice to say, some data is worth more than other data from a miner\u2019s point of view. We\u2019ll address this further in the next section.<\/p>\n\n\n\n<h2>The current state of play<\/h2>\n\n\n\n<p>Right now miners have only two manual configuration options in Bitcoin SV to manage fees and changing either requires a restart of the node.&nbsp; These form the \u201ctransaction fee toolset\u201d currently available to BSV miners:<\/p>\n\n\n\n<ul class=\"ml3vw\"><li>There is the \u201cactual fee rate\u201d that miners accept to mine a transaction denominated in sats\/byte.&nbsp;<\/li><li>There is an additional option \u201cminrelaytxfee\u201d which should be lower and is the fee rate required for a miner to even bother validating a transaction and subsequently relaying it to peers.&nbsp;<\/li><\/ul>\n\n\n\n<p>To my knowledge almost all miners currently use the default settings which are both set to 1 sat\/byte.&nbsp; However, it is actually important for a safe 0-conf fee market to emerge that minrelaytxfee is set lower by some margin than the actual fee rate, so for the purposes of this discussion we will assume that the default minrelaytxfee is actually 0.5 sats\/byte. The existence of this range of fee rates is important to enable room for miners to be competitive whilst still protecting the \u201cfirst see rule\u201d that is a fundamental pillar of 0-conf security. I have referenced the idea of a \u201csecondary mempool\u201d in many of my public presentations that is for miners to keep some transactions for double spend protection even if they don\u2019t intend to mine them.&nbsp; There is a lower bound to the fee rate where this protection kicks in simply to discourage the excessive use of zero fee transactions.&nbsp;<\/p>\n\n\n\n<figure class=\"wp-block-image\"><img src=\"https:\/\/bitcoinsv.io\/wp-content\/uploads\/2019\/11\/tx-fee-scale-1024x293.png\" alt=\"\" class=\"wp-image-3065\"\/><figcaption><em>Relation between transaction properties and miner fee rates<\/em><\/figcaption><\/figure>\n\n\n\n<p>To illustrate the use of this range, let\u2019s assume that all miners except one use the defaults and that one \u201cexception miner\u201d accepts a fee rate of 0.8 sats\/byte.&nbsp; If confirmation time is not important to you, you might use this fee rate; the \u201cmajority miners\u201d will accept the transaction into the mempool and refuse to allow it to be double spent because the fee is higher than 0.5 sats\/byte, but because it is below the one 1 sat\/byte fee rate that all the majority miners are using, only the one exception miner will try to mine it into a block so likely you\u2019ll have to wait many blocks for it to be mined.&nbsp;<\/p>\n\n\n\n<p>Let\u2019s try a second scenario where one exception miner uses a fee rate of 0.3 sats\/byte.&nbsp; This is below the 0.5 sats\/byte threshold so the majority miners will not even accept or relay it let alone mine it.&nbsp; In this case most miners have forgotten the transaction and cannot do a double spend check in order to respect the first seen rule.&nbsp; For some use cases this might be ok (e.g. WeatherSV since they won\u2019t double spend themselves).<\/p>\n\n\n\n<p>With these examples along with the diagram above we can clearly see four distinct classes of transaction properties based on the chosen fee rate:<\/p>\n\n\n\n<ol class=\"ml3vw\"><li>Offline, miners will ignore them. This can be useful if you consider that using CPFP you can later upgrade a transaction to one of the later classes<\/li><li>Slow to mine, no double spend protection<\/li><li>Slow to mine, full double spend protection<\/li><li>Fast to mine, full double spend protection.<\/li><\/ol>\n\n\n\n<p>These properties have progressively higher value dependant on use case and you should be able to select what is most appropriate for your situation.&nbsp; And in fact some of those properties are not just black and white.&nbsp; E.g. time to mine can be improved by choosing a fee rate that will satisfy xx% of miners without choosing the highest fee rate.<\/p>\n\n\n\n<p>What this highlights is that not all transactions are created equal, and it would be nice if miners could compete on each class or specialize in some.&nbsp; But right now there is only one fee rate for everything.<\/p>\n\n\n\n<p>So back to the current transaction fee toolset currently available. These two settings are buried inside the Bitcoin SV Node software itself.&nbsp; That means if you want to modify how they work you have to modify the node code.&nbsp; Because the node code handles some other very sensitive parts of the Bitcoin network, our Bitcoin SV Node team has very onerous QA processes and few other people are willing to risk touching it.&nbsp; The consequence is that changes to these mechanisms are slow and complex to implement and can only be implemented by one team (unless you want the overhead of maintaining a full Bitcoin codebase).&nbsp; This is the opposite of what is needed to enable multiple players to dynamically implement new mechanisms and engage in a real-time process of price floor discovery.&nbsp; I\u2019m going to drop a controversial word here and say that Bitcoin needs a fee market.&nbsp; <strong>But unlike Bitcoin Core we aren\u2019t using a market to discover how <em>high <\/em>transactions fees can be, we are using it to discover how <em>low <\/em>they can go.<\/strong><\/p>\n\n\n\n<p>A further issue with this setup is that the general public doesn\u2019t have any visibility into these settings.&nbsp; So the actual price that miners are asking is unknown to the people who need to set the transactions fees in the transactions they create. There are all sorts of horrible fee estimation algorithms out there that we inherited from Bitcoin Core but they rarely give the best price, no assurance that you\u2019ll even get it high enough and give you no visibility of what fee rate will actually provide 0-conf safety.&nbsp; We are currently saved from the disaster this could become by virtue of the fact that almost all miners currently use the defaults.&nbsp; This works until miners start changing them which they will likely do very soon.<\/p>\n\n\n\n<p>Lastly, there is the lack of granularity.&nbsp; There is no mechanism to price different types of transactions at different rates.&nbsp; Data bytes cost less to process than ECDSA signatures but miners cannot reflect that in the current pricing model. Some types of data might be worth more from a miner\u2019s point of view than others. For example, it could be argued that weather data is more valuable than pictures of someone\u2019s cat as the weather data is a public utility that enhances the value of the blockchain as a data store.<\/p>\n\n\n\n<h2>Near future tools<\/h2>\n\n\n\n<p>For Bitcoin SV, there are three tools in the pipeline directly applicable to most of these concerns around transaction fees.&nbsp; The second might make the first one redundant but it illustrates one of the points above.<\/p>\n\n\n\n<ol class=\"ml3vw\"><li>The ability for miners to price data bytes differently to the rest of the bytes in a transaction.<\/li><li>Moving the fee evaluation function OUT of the Bitcoin SV Node software.<\/li><li>Providing a fee discovery mechanism to end users<\/li><\/ol>\n\n\n\n<p>Change 1 is a change to the Bitcoin SV code that has been in pipeline for quite some time and will likely make it to release around Feb 2020.&nbsp; Its function will be easily replicated by change 2.&nbsp; Along its journey through the change pipeline it has dealt with competing priorities (e.g. the Genesis hard fork) and only being worked on by the Bitcoin SV team due to the myriad complexities of it being embedded in that code. This alone is a great justification for change 2.<\/p>\n\n\n\n<p>Change 2 will have its first implementation in our planned Merchant API but it requires a change in the Bitcoin SV Node to open up a gateway.&nbsp; In essence, the Bitcoin SV Node needs a mechanism to accept transactions from a trusted source and because that source is trusted it will not check fee policies, rather it will just check the transaction is valid and append it to a block.&nbsp; This means delegating fee evaluation to an external module.&nbsp; There can be many implementations of these and anyone can build and maintain one without having to touch the Bitcoin SV code. The requirements for such a module are quite small so a project like this is not terribly onerous.<\/p>\n\n\n\n<p>Change 3 is also a part of Merchant API but it doesn\u2019t require changes to the node for its first iteration, so fee discovery will be available as a beta implementation in the coming weeks.<\/p>\n\n\n\n<p>Let\u2019s take Merchant API as an example of externalising fee evaluation, since it already has the facility to provide fee quotes to users and accept transactions it is a logical place to perform fee evaluation.&nbsp; It is embodied as a REST API which every developer on Earth knows how to use.&nbsp; So consider a few possibilities of what it might be able to do:<\/p>\n\n\n\n<ul class=\"ml3vw\"><li>User based fee policies \u2013 public connections might be offered one fee rate whilst authenticated users might offered fees based on their particular contractual arrangements.<\/li><li>FeeQuote mechanism enables rapid changes to fee policies whilst users remain fully informed.<\/li><li>Lower pricing for data bytes compared to signature bytes.<\/li><li>That ability makes fiat stable pricing possible, fees can be updated daily or hourly to ensure they cost the same amount in USD rather than floating with the BSV price.<\/li><li>Per protocol pricing \u2013 Using the widely adopted OP_RETURN protocol_id standard to price different protocols according to their perceived utility e.g. plaintext data available to all users may be cheaper than encrypted data accessible to only one.<\/li><li>Volume discounts for bulk submission.<\/li><li>Out of band payment \u2013 \u201cHi Amazon, for $X\/month payed with your credit card we\u2019ll take care of getting all your transactions mined\u201d.<\/li><\/ul>\n\n\n\n<p>The range of possibilities is endless when this functionality is pushed into the hands of miners and payment processors. The fee quote mechanism has been designed to very flexible going far beyond the traditional \u201csatoshis per byte\u201d mechanism we have today.<\/p>\n\n\n\n<p>Merchant API and its companion tool, Miner ID, are beginning private beta testing over the next couple of weeks and we\u2019d expect to make the endpoints public early in 2020.<\/p>\n\n\n\n<h2>Interim measures<\/h2>\n\n\n\n<p>But can we do something right now with the blunt instruments we currently have at our disposal?&nbsp; The answer is probably yes. From the discussions I\u2019ve had with many actors (including miners) around the ecosystem there are clearly a couple of common themes:<\/p>\n\n\n\n<ol class=\"ml3vw\"><li>There is a strong appetite to cut transaction fees significantly in the near term.<\/li><li>It is widely recognised that volatile pricing in fiat terms needs to be addressed to provide operational cost stability to businesses using Bitcoin SV so whatever solution is presented for the first point will probably be accompanied by a periodic review of pricing to keep them relatively stable in USD equivalent until automated mechanisms are enabled.<\/li><\/ol>\n\n\n\n<p><strong>I think it\u2019s reasonably safe to say these changes are imminent<\/strong>, it\u2019s only a question of when and by how much.&nbsp; But what is probably important to note is that Bitcoin SV is already cheapest of all major blockhains to transact upon for real utility, both in satoshis and in fiat terms, any cut will send a clear signal to the market the cost of using Bitcoin SV is going in only one direction, down. &nbsp;<strong>This is only economically possible because the future of Bitcoin SV is to massively scale<\/strong>.<\/p>\n\n\n\n<p>We\u2019re just now experiencing how Bitcoin\u2019s economic system should have played out for many years before. It will take the BSV ecosystem some time to adjust to this new reality, but we will do so by developing flexible new transaction fee toolsets and constructive business approaches.&nbsp; These steps will ensure a healthy and long-lasting transaction fee market that that is flexible and meets the economics needs of both application builders and miners.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>New transaction fee toolsets coming to Bitcoin SV TLDR; Cheaper transaction fees, fiat stable pricing and a highly flexible framework for dynamic fee rate discovery are all on the horizon for Bitcoin SV. Since a recent price rise of BSV in fiat terms and the announcement of WeatherSV\u2019s transaction fee deal directly with a mining [&hellip;]<\/p>\n","protected":false},"author":4,"featured_media":3066,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[73],"tags":[],"lang":"en","translations":{"en":3057},"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v15.0 - https:\/\/yoast.com\/wordpress\/plugins\/seo\/ -->\n<title>On the future of Bitcoin transaction fees - Bitcoin SV<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/stag.bitcoinsv.io\/2019\/11\/24\/on-the-future-of-bitcoin-transaction-fees\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"On the future of Bitcoin transaction fees - Bitcoin SV\" \/>\n<meta property=\"og:description\" content=\"New transaction fee toolsets coming to Bitcoin SV TLDR; Cheaper transaction fees, fiat stable pricing and a highly flexible framework for dynamic fee rate discovery are all on the horizon for Bitcoin SV. Since a recent price rise of BSV in fiat terms and the announcement of WeatherSV\u2019s transaction fee deal directly with a mining [&hellip;]\" \/>\n<meta property=\"og:url\" content=\"https:\/\/stag.bitcoinsv.io\/2019\/11\/24\/on-the-future-of-bitcoin-transaction-fees\/\" \/>\n<meta property=\"og:site_name\" content=\"Bitcoin SV\" \/>\n<meta property=\"article:published_time\" content=\"2019-11-24T23:49:22+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2020-09-28T07:00:47+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/bitcoinsv.io\/wp-content\/uploads\/2020\/09\/bitcoin-sv-bsv-mines-world-record-128mb-blocks.jpg\" \/>\n\t<meta property=\"og:image:width\" content=\"1234\" \/>\n\t<meta property=\"og:image:height\" content=\"616\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:creator\" content=\"@BitcoinSVNode\" \/>\n<meta name=\"twitter:site\" content=\"@BitcoinSVNode\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"Organization\",\"@id\":\"https:\/\/bitcoinsv.io\/#organization\",\"name\":\"Bitcoin SV\",\"url\":\"https:\/\/bitcoinsv.io\/\",\"sameAs\":[\"https:\/\/twitter.com\/BitcoinSVNode\"],\"logo\":{\"@type\":\"ImageObject\",\"@id\":\"https:\/\/bitcoinsv.io\/#logo\",\"inLanguage\":\"en-US\",\"url\":\"https:\/\/bitcoinsv.io\/wp-content\/uploads\/2020\/10\/bsv-logo-wh-medium.png\",\"width\":800,\"height\":144,\"caption\":\"Bitcoin SV\"},\"image\":{\"@id\":\"https:\/\/bitcoinsv.io\/#logo\"}},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/bitcoinsv.io\/#website\",\"url\":\"https:\/\/bitcoinsv.io\/\",\"name\":\"Bitcoin SV\",\"description\":\"Just another WordPress site\",\"publisher\":{\"@id\":\"https:\/\/bitcoinsv.io\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":\"https:\/\/bitcoinsv.io\/?s={search_term_string}\",\"query-input\":\"required name=search_term_string\"}],\"inLanguage\":\"en-US\"},{\"@type\":\"ImageObject\",\"@id\":\"https:\/\/stag.bitcoinsv.io\/2019\/11\/24\/on-the-future-of-bitcoin-transaction-fees\/#primaryimage\",\"inLanguage\":\"en-US\",\"url\":\"\"},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/stag.bitcoinsv.io\/2019\/11\/24\/on-the-future-of-bitcoin-transaction-fees\/#webpage\",\"url\":\"https:\/\/stag.bitcoinsv.io\/2019\/11\/24\/on-the-future-of-bitcoin-transaction-fees\/\",\"name\":\"On the future of Bitcoin transaction fees - Bitcoin SV\",\"isPartOf\":{\"@id\":\"https:\/\/bitcoinsv.io\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/stag.bitcoinsv.io\/2019\/11\/24\/on-the-future-of-bitcoin-transaction-fees\/#primaryimage\"},\"datePublished\":\"2019-11-24T23:49:22+00:00\",\"dateModified\":\"2020-09-28T07:00:47+00:00\",\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/stag.bitcoinsv.io\/2019\/11\/24\/on-the-future-of-bitcoin-transaction-fees\/\"]}]},{\"@type\":\"Article\",\"@id\":\"https:\/\/stag.bitcoinsv.io\/2019\/11\/24\/on-the-future-of-bitcoin-transaction-fees\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/stag.bitcoinsv.io\/2019\/11\/24\/on-the-future-of-bitcoin-transaction-fees\/#webpage\"},\"author\":{\"@id\":\"https:\/\/bitcoinsv.io\/#\/schema\/person\/d1b90c2f0b7b27b52e59ef856a57ab4e\"},\"headline\":\"On the future of Bitcoin transaction fees\",\"datePublished\":\"2019-11-24T23:49:22+00:00\",\"dateModified\":\"2020-09-28T07:00:47+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/stag.bitcoinsv.io\/2019\/11\/24\/on-the-future-of-bitcoin-transaction-fees\/#webpage\"},\"publisher\":{\"@id\":\"https:\/\/bitcoinsv.io\/#organization\"},\"image\":{\"@id\":\"https:\/\/stag.bitcoinsv.io\/2019\/11\/24\/on-the-future-of-bitcoin-transaction-fees\/#primaryimage\"},\"articleSection\":\"Articles\",\"inLanguage\":\"en-US\"},{\"@type\":\"Person\",\"@id\":\"https:\/\/bitcoinsv.io\/#\/schema\/person\/d1b90c2f0b7b27b52e59ef856a57ab4e\",\"name\":\"Steve Shadders\",\"image\":{\"@type\":\"ImageObject\",\"@id\":\"https:\/\/bitcoinsv.io\/#personlogo\",\"inLanguage\":\"en-US\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/d08dfcc7367f9cdd71cedbd77082b84f?s=96&d=mm&r=g\",\"caption\":\"Steve Shadders\"},\"description\":\"Steve has been involved in Bitcoin infrastructure since early 2011. In his role, he contributes his ecosystem-wide perspective, to support building the mining and UX infrastructure, needed to enable Satoshi\\u2019s Vision.\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","pll_sync_post":[],"_links":{"self":[{"href":"https:\/\/bitcoinsv.io\/wp-json\/wp\/v2\/posts\/3057"}],"collection":[{"href":"https:\/\/bitcoinsv.io\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/bitcoinsv.io\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/bitcoinsv.io\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/bitcoinsv.io\/wp-json\/wp\/v2\/comments?post=3057"}],"version-history":[{"count":3,"href":"https:\/\/bitcoinsv.io\/wp-json\/wp\/v2\/posts\/3057\/revisions"}],"predecessor-version":[{"id":4290,"href":"https:\/\/bitcoinsv.io\/wp-json\/wp\/v2\/posts\/3057\/revisions\/4290"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/bitcoinsv.io\/wp-json\/wp\/v2\/media\/3066"}],"wp:attachment":[{"href":"https:\/\/bitcoinsv.io\/wp-json\/wp\/v2\/media?parent=3057"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/bitcoinsv.io\/wp-json\/wp\/v2\/categories?post=3057"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/bitcoinsv.io\/wp-json\/wp\/v2\/tags?post=3057"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}