May 1, 2026

Capitalizations Index – B ∞/21M

IRI and client libraries update Feb 8

Iri and client libraries update feb 8

IRI and client libraries update Feb 8

Iri and client libraries update feb 8

The past weeks our engineering department has been transitioning to a very different, and much more open communication model with our community. Regular updates for Trinity, Entangled, IRI and client libraries are now coming out.

Probably even more visible, at least if you are active on our Discord, is the presence of new channels. The day-to-day development team discussions are now happening in these channels. The channels are visible to anyone. For IRI and client libraries, the channels are:

  • iri-dev – day-to-day IRI team discussions. Read only.
  • iri-discussion – public IRI discussion, anyone can join in.
  • clients-dev – day-to-day client library team discussions. Read only.
  • clients-discussion – public client library discussion, anyone can join in.

Please join the IOTA Discord server here to see what we are up to daily and ask questions!

Client libraries

In the previous update we mentioned that the client libraries team has been mainly working on a design of functionality the libraries will support in the full 1.0.0 release. The main part of that is about making libraries stateful. Last week, we officially started the development of the first version of what we call the Account module.

If you are a developer, you can look at the spec in Go, here. We’re aiming for having a first version of the account module usable in a new beta release of the client libraries within February. The design and implementation will then iteratively evolve towards the full 1.0.0 release.

IRI

The main focus of the past couple weeks has been and still is investigating and fixing issues with IRI 1.6.0. Some of the issues relate to syncing, others to high resource consumption in certain scenarios. We’re still heads down debugging and fixing the issues, but we’ve already made some fixes that will be present in IRI 1.6.1.

PRs merged since the last release:

- Add configurable variables for spent addresses DB#1274
- Fix: added a buffer to LSManager #1286
- Fix: test existence of spent addresses db do not point to correct folder #1305
- Fix: Batch process spent addresses to avoid out of memory issues #1314
- Fresh transactionToRequest #1316
- Fix for (closed) issue #1086, missing user-agent header in cors #1319

If you have not been following the projects, you can do so on our GitHub:

We welcome community pull requests and can help you get up to speed with everything in our discord channels. Join the IOTA Discord server here.

Iri and client libraries update feb 8


IRI and client libraries update Feb 8 was originally published in IOTA on Medium, where people are continuing the conversation by highlighting and responding to this story.

IRI and client libraries update Feb 8 was originally published on https://medium.com/@jakubcech?source=rss-ada7b46e03f——2. The IOTA-News Community curates, examines, and summarizes news from external services while producing its own original material. Copyrights from external sources will be credited as they pertain to their corresponding owners. The purpose is to make use of 3rd party content or pictures as either allusion or promotional endorsement of mentioned sites. If you have a claim of copyright infringement with respect to material, please mail to support[at]iota-news.com. IOTA-News.com is a community run website and is NOT affiliated with the IOTA Foundation in any way.

source: https://iota-news.com/iri-and-client-libraries-update-feb-8/

Published at Fri, 08 Feb 2019 18:45:44 +0000

Previous Article

Bitcoin, Ripple, Ethereum, Litecoin, EOS, ₿itcoin Cash, Tron, Stellar, Binance Coin, ₿itcoin SV: Price Analysis, Feb. 8

Next Article

Funds Were Moving From QuadrigaCX Right Before Its Collapse

You might be interested in …

BIP 91 Has Locked In. Here’s What That Means (and What It Does Not)

BIP91.jpg

It looks as if bitcoin is getting Segregated Witness.

Bitcoin Improvement Proposal 91 (BIP 91) just locked in. Up to 90 percent of all hash power signaled support for this soft fork, which implies miners intend, in turn, to trigger Segregated Witness (SegWit) activation. By extension, this should make BIP 148 obsolete and August 1 a non-event.

But SegWit is not certain. In fact, on a technical level, SegWit is not any closer to activation at all.

BIP 91

Segregated Witness, defined by BIP 141, locks in if at least 95 percent of miners (by hash power) signal support for the upgrade within a two-week difficulty period. To do so, miners need to embed a piece of data called “bit 1” in the blocks they mine.

Importantly, this is technically the only way for SegWit to activate right now. And this threshold has not yet been met.

But there are alternative strategies to try and trigger this threshold “indirectly” — like BIP 91.

BIP 91 is a bitcoin Improvement Proposal proposed by Bitmain Warranty engineer James Hilliard. It is compatible with the New York Agreement and backed by a number of bitcoin companies and mining pools. It is also compatible with BIP 148, another strategy to trigger the BIP 141 threshold indirectly.

Miners have been signaling support for BIP 91 over the past couple of days through another piece of data, “bit 4.” Once 269 blocks within a 336-block window included bit 4, this BIP 91 soft fork locks in. This threshold was just met.

This means that after another 336 blocks, a little over two days from now, all BIP 91–compatible nodes will reject any block that doesn’t include bit 1.

As long as a majority of hash power enforces BIP 91, this majority should eventually control the longest valid chain according to all bitcoin nodes. And as this chain consists of bit 1 SegWit-signaling blocks only, it would in turn lock in SegWit on all SegWit-ready nodes by mid-August. SegWit itself should then be live on the bitcoin network after a two-week “grace period” by the end of that month.

If all goes well …

What Could Go Wrong?

Although well over 80 percent of hash power has signaled bit 4 for BIP 91 lock in, this doesn’t actually guarantee anything. Most importantly, it doesn’t in itself mean that these miners will signal bit 1 for SegWit.

Indeed, so far, most miners don’t. Currently, the proportion of miners signaling bit 1 is still far lower than BIP 91 activation would suggest. It is even lower than 50 percent.

Moreover, BIP 91 will probably be enforced by hardly any economically relevant nodes; that is, nodes operated by users that accept bitcoins as payment. Almost no bitcoin users on the network recognize BIP 91 or its bit 4 signaling at all, and will therefore continue to accept blocks with or without bit 1.

BIP 91 will, instead, be enforced by hash power alone. This in turn means that a majority of miners (by hash power) could back out of BIP 91 with little more than reputational damage. They could continue to mine blocks that do not signal bit 1, even after BIP 91 activates in a few days. As long as these miners are in a majority, they will still control the longest valid chain: valid according to most miners, and valid to most users.

Furthermore, any minority of miners and the few nodes that do enforce the BIP 91 soft fork would then be forked off the bitcoin network. In a few days from now, these miners would mine (on top of) blocks that almost only they themselves would care for, while most of the rest of the entire bitcoin network would completely ignore them.

With this week’s bit 4 signaling, a majority of miners have effectively made a statement that they intend to start to activate the SegWit soft fork within a couple of days. But for now, that’s really all it is: a very public, blockchain-based statement of intent.

Actual SegWit activation should start next week, if miners stick to their stated intent.

The post BIP 91 Has Locked In. Here’s What That Means (and What It Does Not) appeared first on Bitcoin Magazine.