Odarhom - Release Notes ๐Ÿ“–

Short Overview - First Draft

Masternodes ๐Ÿ’ป

Odarhom brings along a masternode system for Bitcore. The collateral for one masternode is 2,100 BTX. This allows up to 10,000 masternodes to support the network. The masternodes receive half of all generated bitcores. It is possible to setup a masternode with the minimum version 0.90.8.x or higher. A government system is included in the new core and can be activated later, if necessary.

Datacarriersize

Odarhom increase the default datacarriersize up to 220 bytes. More infos con you find here | here no 2. | here no 3.

Command fork system

Different forks can be activated remotely in the future. This way we can ensure that all critical updates are only activated once all important network participants are ready.

Wallet changes

Odarhom introduces full support for segwit in the wallet and user interfaces. A new `-addresstype` argument has been added, which supports `legacy`, `p2sh-segwit` (default), and `bech32` addresses. It controls what kind of addresses are produced by `getnewaddress`, `getaccountaddress`, and `createmultisigaddress`. A `-changetype` argument has also been added, with the same options, and by default equal to `-addresstype`, to control which kind of change is used.

A new `address_type` parameter has been added to the `getnewaddress` and `addmultisigaddress` RPCs to specify which type of address to generate.

A `change_type` argument has been added to the `fundrawtransaction` RPC to override the `-changetype` argument for specific transactions.

All segwit addresses created through `getnewaddress` or `*multisig` RPCs explicitly get their redeemscripts added to the wallet file. This means that downgrading after creating a segwit address will work, as long as the wallet file is up to date.

All segwit keys in the wallet get an implicit redeemscript added, without it being written to the file. This means recovery of an old backup will work, as long as you use new software.

All keypool keys that are seen used in transactions explicitly get their redeemscripts added to the wallet files. This means that downgrading after recovering from a backup that includes a segwit address will work

Note that some RPCs do not yet support segwit addresses. Notably, `signmessage`/`verifymessage` doesn't support segwit addresses, nor does `importmulti` at this time. Support for segwit in those RPCs will continue to be added in future versions.

P2WPKH change outputs are now used by default if any destination in the transaction is a P2WPKH or P2WSH output. This is done to ensure the change output is as indistinguishable from the other outputs as possible in either case.

BIP173 (Bech32) Address support ("btx..." addresses)

Full support for native segwit addresses (BIP173 / Bech32) has now been added.

This includes the ability to send to BIP173 addresses (including non-v0 ones), and generating these addresses (including as default new addresses, see above).

A checkbox has been added to the GUI to select whether a Bech32 address or P2SH-wrapped address should be generated when using segwit addresses. When launched with `-addresstype=bech32` it is checked by default. When launched with `-addresstype=legacy` it is unchecked and disabled.

HD-wallets by default

Due to a backward-incompatible change in the wallet database, wallets created with version 0.15.2 will be rejected by previous versions. Also, version 0.15.2 will only create hierarchical deterministic (HD) wallets. Note that this only applies to new wallets; wallets made with previous versions will not be upgraded to be HD.

Replace-By-Fee by default in GUI

The send screen now uses BIP125 RBF by default, regardless of `-walletrbf`.There is a checkbox to mark the transaction as final.

The RPC default remains unchanged: to use RBF, launch with `-walletrbf=1` oruse the `replaceable` argument for individual transactions.

Wallets directory configuration (`-walletdir`)

Odarhom now has more flexibility in where the wallets directory can belocated. Previously wallet database files were stored at the top level of the bitcoin data directory. The behavior is now:

For new installations (where the data directory doesn't already exist), wallets will now be stored in a new `wallets/` subdirectory inside the data directory by default.

For existing nodes (where the data directory already exists), wallets will be stored in the data directory root by default. If a `wallets/` subdirectory already exists in the data directory root, then wallets will be stored in the `wallets/` subdirectory by default.- The location of the wallets directory can be overridden by specifying a

`-walletdir=<path>` option where `<path>` can be an absolute path to a directory or directory symlink.

Care should be taken when choosing the wallets directory location, as if it becomes unavailable during operation, funds may be lost.

Support for signalling pruned nodes (BIP159)

Pruned nodes can now signal BIP159's NODE_NETWORK_LIMITED using service bits, in preparation forfull BIP159 support in later versions. This would allow pruned nodes to serve the most recent blocks. However, the current change does not yet include support for connecting to these pruned peers.

GUI changes

We have added a new Walletdesign. The option to reuse a previous address has now been removed. This was justified by the need to "resend" an invoice, but now that we have the request history, that need should be gone.- Support for searching by TXID has been added, rather than just address and label.- A "Use available balance" option has been added to send coins dialog, to add the remaining available wallet balance to a transaction output.- A toggle for unblinding the password fields on the password dialog has been added

Security ๐Ÿšจ

We change the coinbase maturity via command fork from 100 to 576 blocks. Also, we have pumb the default the protoversion to 80004. It is possible later to disconnect the old version via command fork.

Hashalgorythm

Odarhom supports already lots of Hashalgorythms so can we later with an update new Hashalgorythms for mining. A final decision will be agreed with the community. Odarhom can work with timetravel10, scrypt, nist5, lyra2z, x11, x16r.

Sources

Bitcoin Core, Dash Core, FXTC Core, LTC Core, PIVX Core, Bitcoin Cash Core

Last updated