Unsubscribing

We’ve moved to a new platform for distributing this week’s newsletter. If you’re not interested in receiving weekly updates on what’s happening in the Bitcoin open source community, please click on the unsubscribe link at the bottom of this email.

Don’t hesitate to contact us at info@bitcoinops.org if you have any questions or comments about what we’re doing!

Welcome

Welcome to the second Bitcoin Optech Group newsletter! As a member of our new organization, you can expect to see regular newsletters from us covering Bitcoin open source development and protocol news, Optech announcements, and member company’s case studies. These newsletters are also available on our web site.

As always, please feel free to contact us if you have feedback or comments on this newsletter.

A reminder to companies that haven’t yet become an official member yet. We ask that you pay a nominal contribution of $5,000 to help fund our expenses.

First Optech workshop!

As announced previously, Bitcoin Optech Group is organizing our first workshop July 17 in San Francisco. Participants will be 1-2 engineers from SF Bay area Bitcoin companies. We will have roundtable discussions covering 3 topics:

  • Coin selection best practices;
  • Fee estimation, RBF, CPFP best practices;
  • Optech community and communication - optimizing Optech for business’ needs.

Please contact us if you would like to be involved in this or future workshops in other regions.

Open Source News

A summary of relevant action items, dashboard items, and news from the broader Bitcoin open source community.

Action items

No new action items, but follow-up related to the following previously-published items is still recommended.

Dashboard items

  • ● Transaction fees remain very low: as of this writing, fee estimates for confirmation 2 or more blocks in the future remain at roughly the level of the default minimum relay fee in Bitcoin Core. It’s a good time to consolidate inputs.

    UPDATE (July 2): The estimated network hash rate decreased in the last 3-4 days, initially by as much as 10%, but rebounding a bit since then. Some have speculated that flooding in south western China has destroyed a significant amount of mining equipment. Note, however, that due to the natural variance in the rate of block discovery, it’s only possible to make a rough estimate of the current amount of network hash rate over short periods of time. Lower network hash rate implies a slower rate of block discovery, which can lead to mempool congestion and potentially higher fees. So far, mempool congestion does not appear to have increased significantly and fees remain low. However, it is recommended to keep monitoring block discovery rate and mempool congestion before sending large transactions.

  • ● Testnet high block production rate: late last week, a miner produced a large number of blocks in rapid succession on testnet, sometimes several blocks per second, leading to a degradation of service from some testnet providers. This is a recurrent problem on testnet that is the result of the deliberate lack of economic incentive to mine there. If you to need test your software, it’s more reliable to build your own private testent using Bitcoin Core’s regtest mode.

News

  • ● Continued discussion over graftroot safety: Graftroot is a proposed opt-in alternative to taproot, which is a proposed enhancement of MAST, which is itself a proposed enhancement of the current Bitcoin script. MAST improves scalability, privacy, and fungibility by allowing unused conditional branches in Bitcoin scripts to be left out of the block chain. Taproot further improves MAST scalability, privacy, and fungibility by allowing even the used conditional branch in a script to be left out of the block chain in the common case. Graftroot improves taproot’s flexibility and scalability by allowing participants in the script to delegate their spending authority to other parties, including allowing the existing participants to impose additional script-based conditions on the delegates—all done offchain and without reducing the scalability, privacy, and fungibility benefits.

    In a slowly-progressing discussion, members of the bitcoin-dev mailing list have been attempting to construct an informally-worded security proof that enabling graftroot delegation by default doesn’t reduce the security of users who don’t need it (e.g. who just want to use taproot without delegation or even just plain MAST). Although more peer review is needed, the effort seems to be proceeding positively with experts currently agreeing that it’s safe to enable graftroot by default.

  • ● BIP174 discussion: as mentioned in last week’s newsletter, mailing list discussion continues surrounding this proposed BIP for an industry standard to make it easier for wallets to communicate with each other in the case of online/offline (hot/cold) wallets, software/hardware wallets, multisig wallets, and multi-user transactions (e.g. CoinJoin). However, the BIP proposer has now opened a pull request requesting the BIP’s status be changed from “draft” to “proposed”. That means it is unlikely to be changed unless a significant problem with implementation is found. If your organization produces or makes critical use of one of the aforementioned interoperating wallets, you may wish to evaluate the current proposal ASAP before it is finalized.
  • ● Dandelion transaction relay: this proposed privacy-enhancing improvement to the way new transactions are initially relayed was briefly discussed on the bitcoin-dev mailing list this week. The main concern was how it selects which peers to route transactions through, which could be abused to reduce privacy temporarily during the initial deployment when only a few nodes support Dandelion. Two mitigations for this problem were discussed.