Releases: exonum/exonum-btc-anchoring
Release 1.0.0
api::TransactionProof
layout has been simplified.- All methods of the following traits became async:
api::PublicApi
,api::PrivateApi
,sync::BitcoinRelay
. - Public methods of the
sync::AnchoringChainUpdateTask
andsync::SyncWithBitcoinTask
also became async. You need to use these methods inside the future executor like
tokio
oractix_rt
. btc_anchoring_sync
utility has been moved to examples.
Release Candidate 1.0.0
Breaking changes
-
Updated to the Exonum 1.0.0-rc.1
release with some minor changes (#155).api::TransactionProof
layout has been refined.
Release Candidate 0.13.0
Breaking changes
-
Ported
exonum-btc-anchoring
to a new version of Exonum with support
of dynamic services. (#145)In this way, a large number of changes have occurred in service business logic:
- Nodes performing anchoring are no longer strictly associated with the
validator nodes. It means that there may exist a validator node that does not
perform anchoring, and vice versa an anchoring node that is not a validator.
But we strongly recommend to keep one to one relationship between the
anchoring and validator nodes. - The bootstrapping procedure has been completely changed in accordance with
the fact that the service can be started at any time during the blockchain
life. The implementation of the service has become stateless and all logic
that previously was performed in theafter_commit
method was taken out
in a separatebtc_anchoring_sync
utility. - "v1" prefix has been removed from API endpoints and introduced a lot of
private API endpoints for thebtc_anchoring_sync
util. - Removed cryptographic proofs for Exonum blocks feature.
It will be implemented as separate service. - Funding transaction entry in config has been replaced by the
add-funds
endpoint in the anchoring private API. This means that you no longer need
to use the configuration update procedure in order to add a new funding
transaction. Now there is a simpler voting procedure with the help of the
add-funds
endpoint. A qualified majority of nodes (2/3n+1
) just have
to send the same transaction so that it is used as a funding one.
- Nodes performing anchoring are no longer strictly associated with the
Internal improvements
exonum_bitcoinrpc
crate has been replaced in favor ofbitcoincore-rpc
. (#145)
Exonum 0.12
- Updated to the Exonum 0.12.0
release (#144).
Exonum 0.11
Exonum 0.10
Internal improvements
- Updated to the
Rust-bitcoin 0.14
release (#134).
Breaking changes
-
New anchoring implementation is based on native segwit transactions. Acceptance of an
anchoring transaction still requires the majority of votes of the validators -
2/3n+1
. As the votes are now separated from the transaction body, they do not
affect transaction hash and, correspondingly, its ID. (#136)In this way:
- Anchoring transactions have become fully deterministic. The problem of transaction
malleability has,
thus, been solved. The validators do not have to agree on the latest Exonum
transaction anchored to Bitcoin blockchain any more to continue the anchoring
chain. - The service can extract the anchoring chain or information on a particular
anchoring transaction from its database any time by a simple API request. It does
not need to use a separate observer functionality any more to extract information
on the latest Exonum anchoring transaction from Bitcoin blockchain and rebuild the
anchoring chain from of this transaction. - There is no need to connect each Exonum node to the
bitcoind
. The anchoring
transactions are generated deterministically and independently from the connection
to the Bitcoin blockchain. New anchoring transactions are monitored by a separate
method and forwarded to the Bitcoin blockchain whenever they occur.
For more details on the updated anchoring service operation you can visit the
readme page. - Anchoring transactions have become fully deterministic. The problem of transaction
Hotfix release
- Fixed compatibility with the
bitcoind
0.17 rpc.
Exonum 0.9 "Halmahera Boobook"
Breaking changes
-
The anchoring chain observer logic has been moved to the
before_commit
stage. (#131)
Thus additional thread in the public api handler has been no longer used.
Thus nowanchoring-observer-check-interval
is measured in blocks instead of milliseconds. -
The anchoring API has been ported to the new
actix-web
backend. (#132)
Some of API endpoints have been changed, you can see updated API description in
the documentation.
Internal improvements
- Added check that funding transaction in
anchoring-funding-txid
contains
output to the anchoring address. (#130)
Bugfix release
Exonum 0.8 "Great Grey Owl"
Breaking changes
-
The anchoring service has been switched to using p2wsh address format. (#123)
It now uses segwit addresses....
This change increases the limit on the number of validators and anchoring security
as well as reduces fees for applying thereof.Note that the old format of anchoring transactions is incompatible with the new one.
Hence, update of the existing blockchain to the new anchoring version is not possible.
For use of a new anchoring format a new blockchain has to be launched.
New features
- Introduced a new API method
/v1/block_header_proof/:height
that provides cryptographic
proofs for Exonum blocks including those anchored to Bitcoin blockchain.
The proof is an apparent evidence of availability of a certain Exonum block
in the blockchain. (#124)
Internal improvements
- Updated to the Rust-bitcoin 0.13
release (#123).
Fixed
- Fixed bug with the
nearest_lect
endpoint that sometimes didn't return actual data [ECR-1387]. (#125)