{"id":15165,"date":"2021-08-11T23:00:00","date_gmt":"2021-08-11T23:00:00","guid":{"rendered":"http:\/\/ci028a6b50600025a3"},"modified":"2025-10-01T15:31:20","modified_gmt":"2025-10-01T20:31:20","slug":"bitcoin-mixing-security-improvement","status":"publish","type":"post","link":"https:\/\/bitcoinmagazine.com\/technical\/bitcoin-mixing-security-improvement","title":{"rendered":"New Implementation For Bitcoin Mixing Service CoinJoin Improves Sybil Resistance"},"content":{"rendered":"<div id=\"bsf_rt_marker\"><\/div><p><em>The Bitcoin Optech newsletter provides readers with a top-level summary of the most important technical news happening in Bitcoin, along with resources that help them learn more. To help our readers stay up-to-date with Bitcoin, we&#8217;re republishing the latest issue of this newsletter below. Remember to subscribe to receive this content straight to your inbox.<\/em><\/p>\n<p>This week\u2019s newsletter follows up on a previous description about fidelity bonds in JoinMarket and includes our regular sections with the summary of a Bitcoin Core PR Review Club meeting, suggestions for preparing for taproot, announcements of releases and release candidates, and descriptions of notable changes to popular infrastructure projects.<\/p>\n<h2>News<\/h2>\n<ul>\n<li>Implementation of fidelity bonds: the <a href=\"https:\/\/bitcoinops.us18.list-manage.com\/track\/click?u=70c3f85e5d13ffec674f30af8&amp;id=20f2711497&amp;e=1beccaec05\" target=\"_blank\" rel=\"noopener\">JoinMarket 0.9.0<\/a> implementation of <a href=\"https:\/\/bitcoinops.us18.list-manage.com\/track\/click?u=70c3f85e5d13ffec674f30af8&amp;id=629d69e275&amp;e=1beccaec05\" target=\"_blank\" rel=\"noopener\">coinjoin<\/a> includes <a href=\"https:\/\/bitcoinops.us18.list-manage.com\/track\/click?u=70c3f85e5d13ffec674f30af8&amp;id=cb43b68cc5&amp;e=1beccaec05\" target=\"_blank\" rel=\"noopener\">support<\/a> for <a href=\"https:\/\/bitcoinops.us18.list-manage.com\/track\/click?u=70c3f85e5d13ffec674f30af8&amp;id=979da96e6a&amp;e=1beccaec05\" target=\"_blank\" rel=\"noopener\">fidelity bonds<\/a>. As previously described in <a href=\"https:\/\/bitcoinops.us18.list-manage.com\/track\/click?u=70c3f85e5d13ffec674f30af8&amp;id=05a9f3cfa0&amp;e=1beccaec05\" target=\"_blank\" rel=\"noopener\">Newsletter #57<\/a>, the bonds improve the sybil resistance of the JoinMarket system, increasing the ability for coinjoin initiators (\u201ctakers\u201d) to choose unique liquidity providers (\u201cmakers\u201d). Within days of release, <a href=\"https:\/\/bitcoinops.us18.list-manage.com\/track\/click?u=70c3f85e5d13ffec674f30af8&amp;id=154bb9f826&amp;e=1beccaec05\" target=\"_blank\" rel=\"noopener\">over 50 BTC<\/a> (currently valued at over $2 million USD) had been placed in timelocked fidelity bonds.<br \/>Although the specific implementation is unique to JoinMarket, the overall design may be useful in other decentralized protocols built on top of Bitcoin.<\/li>\n<\/ul>\n<h2>Bitcoin Core PR Review Club<\/h2>\n<p><em>In this monthly section, we summarize a recent <\/em><a href=\"https:\/\/bitcoinops.us18.list-manage.com\/track\/click?u=70c3f85e5d13ffec674f30af8&amp;id=4bf67facc6&amp;e=1beccaec05\" target=\"_blank\" rel=\"noopener\"><em>Bitcoin Core PR Review Club<\/em><\/a><em> meeting, highlighting some of the important questions and answers. Click on a question below to see a summary of the answer from the meeting.<\/em><\/p>\n<p><a href=\"https:\/\/bitcoinops.us18.list-manage.com\/track\/click?u=70c3f85e5d13ffec674f30af8&amp;id=2b695fe8cd&amp;e=1beccaec05\" target=\"_blank\" rel=\"noopener\">Prefer to use txindex if available for GetTransaction<\/a> is a PR by Jameson Lopp which improves the performance of GetTransaction (and, by extension, the getrawtransaction RPC for users) by utilizing the transaction index (txindex) when possible. This change fixes an unexpected performance loss in which a call to getrawtransaction on a txindex-enabled node is significantly slower when called with the hash of the block that includes the transaction. The review club evaluated the cause of this performance issue by comparing the steps to retrieve a transaction with and without txindex.<\/p>\n<ul>\n<li>What are the different ways GetTransaction can retrieve a transaction from disk?<br \/>The transaction can be retrieved from the mempool (if unconfirmed), by retrieving the entire block from disk and searching for the transaction, or by using txindex to fetch the transaction from disk by itself.<\/li>\n<li>Why do you think that performance is worse when the block hash is provided (when txindex is enabled)?<br \/>Participants guessed that the bottleneck was in the deserialization of the block. Another process unique to fetching the entire block &#8211; albeit less time-consuming &#8211; is a linear search through the entire list of transactions.<\/li>\n<li>If we are looking up the transaction by block hash, what are the steps? How much data is deserialized?<br \/>We first use the block index to find the file and byte offset necessary for accessing the block. We then fetch and deserialize the entire block and scan through the list of transactions until we find a match. This involves deserializing about 1-2MB of data.<\/li>\n<li>If we are looking up the transaction using the txindex, what are the steps? How much data is deserialized?<br \/>The txindex maps from transaction id to the file, block position (similar to the block index), and the offset within the blk*.dat file where the transaction starts. We fetch and deserialize the block header and transaction. The header is 80B and allows us to return the block hash to the user (which is information not stored in the txindex). The transaction can be any size but is typically thousands of times smaller than the block.<\/li>\n<li>The first version of this PR included a behavior change: when an incorrect block_index is provided to GetTransaction, find and return the tx anyway using the txindex. Do you think this change is an improvement, and should it be included in this PR?<br \/>Participants agreed that it could be helpful but misleading, and that notifying the user of the incorrect block hash input would be better. They also noted that a performance improvement and behavior change would be best split into separate PRs.<\/li>\n<\/ul>\n<h2>Preparing For Taproot #8: Multisignature Nonces<\/h2>\n<p><em>A weekly <\/em><a href=\"https:\/\/bitcoinops.us18.list-manage.com\/track\/click?u=70c3f85e5d13ffec674f30af8&amp;id=e7b5645a8f&amp;e=1beccaec05\" target=\"_blank\" rel=\"noopener\"><em>series<\/em><\/a><em> about how developers and service providers can prepare for the upcoming activation of taproot at block height 709,632.<\/em><\/p>\n<p>In <a href=\"https:\/\/bitcoinops.us18.list-manage.com\/track\/click?u=70c3f85e5d13ffec674f30af8&amp;id=fe60bd2a5a&amp;e=1beccaec05\" target=\"_blank\" rel=\"noopener\">last week\u2019s column<\/a>, we wrote about <a href=\"https:\/\/bitcoinops.us18.list-manage.com\/track\/click?u=70c3f85e5d13ffec674f30af8&amp;id=eba04c9615&amp;e=1beccaec05\" target=\"_blank\" rel=\"noopener\">multisignatures<\/a> and gave an example using <a href=\"https:\/\/bitcoinops.us18.list-manage.com\/track\/click?u=70c3f85e5d13ffec674f30af8&amp;id=8e9ddb8146&amp;e=1beccaec05\" target=\"_blank\" rel=\"noopener\">MuSig2<\/a>. Our description appears to have been technically correct, but several cryptographers who contributed to MuSig2 <a href=\"https:\/\/bitcoinops.us18.list-manage.com\/track\/click?u=70c3f85e5d13ffec674f30af8&amp;id=d48d0a72b9&amp;e=1beccaec05\" target=\"_blank\" rel=\"noopener\">worried<\/a> that the way we suggested using it was dangerous. We <a href=\"https:\/\/bitcoinops.us18.list-manage.com\/track\/click?u=70c3f85e5d13ffec674f30af8&amp;id=e1345f06e1&amp;e=1beccaec05\" target=\"_blank\" rel=\"noopener\">updated<\/a> our description to address their immediate concerns and then began researching the issue more thoroughly. In this post, we\u2019ll look at what we learned may be the greatest challenge for safely implementing multisignatures: avoiding nonce reuse.<\/p>\n<p>To validate a signature in Bitcoin, you fill out a publicly known equation with the signature, the message that was signed (e.g. a transaction), your public key, and a public nonce. It\u2019s only possible for you to balance that equation if you know your private key and the private form of the nonce. Thus anyone seeing such a balanced equation considers the signature for that message and public key to be valid.<\/p>\n<p>The motivation for including the signature and the message in the equation is obvious. The public key is a stand-in for your private key. What\u2019s the public nonce for? If it wasn\u2019t there, every other value in the equation except for your private key would be known, meaning we could use basic algebra to solve for that single unknown value. But algebra can\u2019t solve for two unknown values, so the private form of the nonce serves to keep your private key secret. And, just as your public key is a stand-in for your private key in the signature equation, the public form of the nonce stands in for its private form.<\/p>\n<p>Nonces in this context are not only <em>numbers used once<\/em> but numbers that must only ever be used once. If you reuse the same nonce with two different signatures, the two signature equations can be combined, the nonce can be canceled out, and someone can again solve for the only remaining unknown value\u2014your private key. If you use <a href=\"https:\/\/bitcoinops.us18.list-manage.com\/track\/click?u=70c3f85e5d13ffec674f30af8&amp;id=dba0671bd1&amp;e=1beccaec05\" target=\"_blank\" rel=\"noopener\">BIP32<\/a> standard derivation (non-hardened derivation), which likely nearly all multisignature wallets will do, then the revelation of one private key means the reveal of every other private key in the same BIP32 path (and possibly in other paths as well). That means a multisignature wallet which has received bitcoins to a hundred different addresses will have every one of those addresses compromised for the signer who reuses even a single nonce.<\/p>\n<p>Single-sig wallets, or those using script-based multisig, can use a simple trick to avoid reusing nonces: they make their nonce dependent on the message they\u2019re signing. If there\u2019s any change to the message, the nonce changes, and so they never reuse a nonce.<\/p>\n<p>Multisignatures can\u2019t use this trick. They require each cosigner contribute not just a partial signature but also a partial public nonce. The partial public nonces are combined together to produce an aggregated public nonce which is included with the message to sign.<\/p>\n<p>That means it\u2019s not safe to use the same partial nonce more than once even if the transaction stays the same. If, the second time you sign, one of your cosigners changed their partial nonce (changing the aggregated nonce), your second partial signature will effectively be for a different message. That reveals your private key. Since it\u2019s impossibly circular for every party to make their private nonce dependent on all the other party\u2019s partial public nonces, there\u2019s no simple trick to avoid nonce reuse in multisignatures.<\/p>\n<p>At first glance, this doesn\u2019t seem like a big problem. Just have signers generate a new random nonce each time they need to sign something. This is harder to get right than it sounds\u2014since at least <a href=\"https:\/\/bitcoinops.us18.list-manage.com\/track\/click?u=70c3f85e5d13ffec674f30af8&amp;id=9c327b09c8&amp;e=1beccaec05\" target=\"_blank\" rel=\"noopener\">2012<\/a>, people have been finding bitcoin-losing bugs in wallets that depended on generating random nonces.<\/p>\n<p>But even if a wallet does generate high-quality random nonces, it has to ensure each nonce is only used a maximum of a single time. That can be a real challenge. In the original version of our column last week, we described a MuSig2-compatible cold wallet or hardware signing device that would create a large number of nonces on its first run. The wallet or device would then need to ensure each of those nonces was never used with more than one partial signature. Although that sounds simple\u2014just increment a counter each time a nonce is used\u2014it can be a real challenge when dealing with all the ways software and hardware can fail by accident, not to mention how they can be affected by external and possibly malicious intervention.<\/p>\n<p>Perhaps the easiest way for a wallet to reduce its risk of nonce reuse is to store nonces for as short a time as possible. Our example from last week suggested storing nonces for months or years, which not only creates a lot of opportunity for something to go wrong but also requires recording nonces to a persistent storage medium which may be backed up and restored or otherwise put into an unexpected state. An alternative way to use MuSig2 would be to only create nonces on demand, such as when a <a href=\"https:\/\/bitcoinops.us18.list-manage.com\/track\/click?u=70c3f85e5d13ffec674f30af8&amp;id=b856bda6d0&amp;e=1beccaec05\" target=\"_blank\" rel=\"noopener\">PSBT<\/a> is received. The nonces could be kept in volatile memory for the short time they were needed and so be automatically destroyed (made unreusable) in several cases of the unexpected happening, such as a software crash or a loss of power.<\/p>\n<p>Still, the cryptographers working on this problem seem very concerned about the lack of foolproof way to prevent nonce reuse in the original MuSig protocol (MuSig1) and MuSig2. MuSig-DN (deterministic nonce) does offer a solution, but it\u2019s complex and slow (an alpha implementation takes almost a second to create a nonce proof on a 2.9 GHz Intel i7; it\u2019s unknown to us how long that might take on a 16 MHz hardware signing device with a much less sophisticated processor).<\/p>\n<p>Our advice to anyone implementing multisignature signing is to consider stopping by the <a href=\"https:\/\/bitcoinops.us18.list-manage.com\/track\/click?u=70c3f85e5d13ffec674f30af8&amp;id=f00cccdf4e&amp;e=1beccaec05\" target=\"_blank\" rel=\"noopener\">#secp256k1<\/a> IRC room or another place where Bitcoin cryptographers congregate and describe your plans before you make any major investments of time or resources.<\/p>\n<h2>Releases And Release Candidates<\/h2>\n<p><em>New releases and release candidates for popular Bitcoin infrastructure projects. Please consider upgrading to new releases or helping to test release candidates.<\/em><\/p>\n<ul>\n<li><a href=\"https:\/\/bitcoinops.us18.list-manage.com\/track\/click?u=70c3f85e5d13ffec674f30af8&amp;id=a9fd6de97e&amp;e=1beccaec05\" target=\"_blank\" rel=\"noopener\">C-Lightning 0.10.1<\/a> is a release that contains a number of new features, several bug fixes, and a few updates to developing protocols (including <a href=\"https:\/\/bitcoinops.us18.list-manage.com\/track\/click?u=70c3f85e5d13ffec674f30af8&amp;id=2b8fa200d1&amp;e=1beccaec05\" target=\"_blank\" rel=\"noopener\">dual funding<\/a> and <a href=\"https:\/\/bitcoinops.us18.list-manage.com\/track\/click?u=70c3f85e5d13ffec674f30af8&amp;id=1ef0caf6ee&amp;e=1beccaec05\" target=\"_blank\" rel=\"noopener\">offers<\/a>).<\/li>\n<li><a href=\"https:\/\/bitcoinops.us18.list-manage.com\/track\/click?u=70c3f85e5d13ffec674f30af8&amp;id=20961f9f82&amp;e=1beccaec05\" target=\"_blank\" rel=\"noopener\">Bitcoin Core 22.0rc2<\/a> is a release candidate for the next major version of this full node implementation and its associated wallet and other software. Major changes in this new version include support for <a href=\"https:\/\/bitcoinops.us18.list-manage.com\/track\/click?u=70c3f85e5d13ffec674f30af8&amp;id=14742a5f71&amp;e=1beccaec05\" target=\"_blank\" rel=\"noopener\">I2P<\/a> connections, removal of support for <a href=\"https:\/\/bitcoinops.us18.list-manage.com\/track\/click?u=70c3f85e5d13ffec674f30af8&amp;id=ac86591380&amp;e=1beccaec05\" target=\"_blank\" rel=\"noopener\">version 2 Tor<\/a> connections, and enhanced support for hardware wallets.<\/li>\n<\/ul>\n<h2>Notable code and documentation changes<\/h2>\n<p><em>Notable changes this week in <\/em><a href=\"https:\/\/bitcoinops.us18.list-manage.com\/track\/click?u=70c3f85e5d13ffec674f30af8&amp;id=12fcfc41d2&amp;e=1beccaec05\" target=\"_blank\" rel=\"noopener\"><em>Bitcoin Core<\/em><\/a><em>, <\/em><a href=\"https:\/\/bitcoinops.us18.list-manage.com\/track\/click?u=70c3f85e5d13ffec674f30af8&amp;id=2f9afb8ad9&amp;e=1beccaec05\" target=\"_blank\" rel=\"noopener\"><em>C-Lightning<\/em><\/a><em>, <\/em><a href=\"https:\/\/bitcoinops.us18.list-manage.com\/track\/click?u=70c3f85e5d13ffec674f30af8&amp;id=66b64d350f&amp;e=1beccaec05\" target=\"_blank\" rel=\"noopener\"><em>Eclair<\/em><\/a><em>, <\/em><a href=\"https:\/\/bitcoinops.us18.list-manage.com\/track\/click?u=70c3f85e5d13ffec674f30af8&amp;id=8590efcd00&amp;e=1beccaec05\" target=\"_blank\" rel=\"noopener\"><em>LND<\/em><\/a><em>, <\/em><a href=\"https:\/\/bitcoinops.us18.list-manage.com\/track\/click?u=70c3f85e5d13ffec674f30af8&amp;id=55c18cfb55&amp;e=1beccaec05\" target=\"_blank\" rel=\"noopener\"><em>Rust-Lightning<\/em><\/a><em>, <\/em><a href=\"https:\/\/bitcoinops.us18.list-manage.com\/track\/click?u=70c3f85e5d13ffec674f30af8&amp;id=032f45fdc6&amp;e=1beccaec05\" target=\"_blank\" rel=\"noopener\"><em>libsecp256k1<\/em><\/a><em>, <\/em><a href=\"https:\/\/bitcoinops.us18.list-manage.com\/track\/click?u=70c3f85e5d13ffec674f30af8&amp;id=c3d0d075bf&amp;e=1beccaec05\" target=\"_blank\" rel=\"noopener\"><em>Hardware Wallet Interface (HWI)<\/em><\/a><em>, <\/em><a href=\"https:\/\/bitcoinops.us18.list-manage.com\/track\/click?u=70c3f85e5d13ffec674f30af8&amp;id=64078e6022&amp;e=1beccaec05\" target=\"_blank\" rel=\"noopener\"><em>Rust Bitcoin<\/em><\/a><em>, <\/em><a href=\"https:\/\/bitcoinops.us18.list-manage.com\/track\/click?u=70c3f85e5d13ffec674f30af8&amp;id=c49896400f&amp;e=1beccaec05\" target=\"_blank\" rel=\"noopener\"><em>BTCPay Server<\/em><\/a><em>, <\/em><a href=\"https:\/\/bitcoinops.us18.list-manage.com\/track\/click?u=70c3f85e5d13ffec674f30af8&amp;id=39678bf32f&amp;e=1beccaec05\" target=\"_blank\" rel=\"noopener\"><em>Bitcoin Improvement Proposals (BIPs)<\/em><\/a><em>, and <\/em><a href=\"https:\/\/bitcoinops.us18.list-manage.com\/track\/click?u=70c3f85e5d13ffec674f30af8&amp;id=5c3b2cee9d&amp;e=1beccaec05\" target=\"_blank\" rel=\"noopener\"><em>Lightning BOLTs<\/em><\/a><em>.<\/em><\/p>\n<ul>\n<li><a href=\"https:\/\/bitcoinops.us18.list-manage.com\/track\/click?u=70c3f85e5d13ffec674f30af8&amp;id=6c55317247&amp;e=1beccaec05\" target=\"_blank\" rel=\"noopener\">Bitcoin Core #21528<\/a> aims to improve the p2p propagation of full node listening addresses. Exposure to a diverse set of addresses is important for nodes to be protected against network partitions such as <a href=\"https:\/\/bitcoinops.us18.list-manage.com\/track\/click?u=70c3f85e5d13ffec674f30af8&amp;id=616f9e345d&amp;e=1beccaec05\" target=\"_blank\" rel=\"noopener\">eclipse attacks<\/a>. When Bitcoin Core nodes receive an address message containing 10 or fewer addresses, they forward it to 1 or 2 peers. This is the primary technique used to self-advertise addresses, so sending to peers that would not relay these addresses would effectively stop or \u201cblack hole\u201d the propagation through the network. Although propagation failures cannot be prevented in the malicious case, this patch improves address propagation for the honest cases, such as for block-relay-only connections or light clients.<br \/>This update identifies whether or not an inbound connection is a candidate for forwarding addresses based on whether it has sent an address related message over the connection, such as addr, addrv2, or getaddr. This behavior change could be problematic if there is software on the network that relies on receiving address messages but never initiates an address-related message. Therefore, the author took care to circulate this proposed change before it was merged, including posting it to the <a href=\"https:\/\/bitcoinops.us18.list-manage.com\/track\/click?u=70c3f85e5d13ffec674f30af8&amp;id=c21fc75d13&amp;e=1beccaec05\" target=\"_blank\" rel=\"noopener\">mailing list<\/a> and researching <a href=\"https:\/\/bitcoinops.us18.list-manage.com\/track\/click?u=70c3f85e5d13ffec674f30af8&amp;id=1fa976f137&amp;e=1beccaec05\" target=\"_blank\" rel=\"noopener\">other open source clients<\/a> to confirm compatibility.<\/li>\n<li><a href=\"https:\/\/bitcoinops.us18.list-manage.com\/track\/click?u=70c3f85e5d13ffec674f30af8&amp;id=ffba774ebb&amp;e=1beccaec05\" target=\"_blank\" rel=\"noopener\">LND #5484<\/a> allows storing all data in a single external Etcd database. This improves high-availability deployments by making cluster leadership changes instantaneous. The corresponding LND clustering documentation was previously covered in <a href=\"https:\/\/bitcoinops.us18.list-manage.com\/track\/click?u=70c3f85e5d13ffec674f30af8&amp;id=4f120c2684&amp;e=1beccaec05\" target=\"_blank\" rel=\"noopener\">Newsletter #157<\/a>.<\/li>\n<li>Rust-Lightning #1004 adds a new event for PaymentForwarded that allows tracking when a payment has been successfully forwarded. Since successful forwarding may earn fees for the node, this allows tracking that income for the user\u2019s accounting records.<\/li>\n<li><a href=\"https:\/\/bitcoinops.us18.list-manage.com\/track\/click?u=70c3f85e5d13ffec674f30af8&amp;id=a9ab03d05c&amp;e=1beccaec05\" target=\"_blank\" rel=\"noopener\">BTCPay Server #2730<\/a> makes the amount optional when generating invoices. This simplifies the payment flow in cases where the operator delegates the choice of the amount to the user, e.g. when topping up an account.<\/li>\n<\/ul>\n<p>Find the <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/\" target=\"_blank\" rel=\"noopener\">original post here.<\/a><\/p>\n<p>Please <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/\" target=\"_blank\" rel=\"noopener\">subscribe to the Bitcoin Optech newsletter<\/a> directly to receive this content straight to your inbox every month.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>This week\u2019s Bitcoin Optech newsletter details a JoinMarket implementation improvement for CoinJoin bitcoin mixing and more.<\/p>\n","protected":false},"author":3246,"featured_media":5744,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[35],"tags":[1791,2887,291,2622,1075],"class_list":["post-15165","post","type-post","status-publish","format-standard","has-post-thumbnail","category-technical","tag-bitcoin-mixing","tag-bitcoin-optech","tag-coinjoin","tag-joinmarket","tag-taproot"],"author_data":{"id":3246,"name":"Bitcoin Optech","nicename":"bitcoin-optech","avatar_url":"https:\/\/bitcoinmagazine.com\/wp-content\/uploads\/2024\/12\/optech-notext-96x96.png"},"featured_image_url":"https:\/\/bitcoinmagazine.com\/wp-content\/uploads\/2024\/11\/knapsack-and-unequal-coinjoin-transaction-amounts.jpg","_links":{"self":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/posts\/15165","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/users\/3246"}],"replies":[{"embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/comments?post=15165"}],"version-history":[{"count":0,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/posts\/15165\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/media\/5744"}],"wp:attachment":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/media?parent=15165"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/categories?post=15165"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/tags?post=15165"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}