The QRL Hardfork blockheight has been set! Bromine code is released!
The QRL Hardfork (codename Bromine) is set to trigger at blockheight of 942,375 — approximately April 6th.
The code has been released as well, which means everyone who’s running a mainnet node** is encouraged to update** (instructions below).
Update to the latest release
If you are not running a node and just holding Quanta, there’s nothing that you need to do (Though we’d encourage you to run a node!).
If you are running a mainnet node, you can update to the latest release now by stopping your node and issuing the following command:
The first thing it will do is update the previous state which can take several hours (~8). You can read more here: https://docs.theqrl.org/hardfork/bromine/information/ Release can be found here: https://github.com/theQRL/QRL/releases/tag/v2.0.0
Quantum secure multisignature addresses & transactions
Multisig allows multiple parties governance over how allocated funds can be spent.
Examples are numerous, including:
Petty joint account — where either party can spend funds
Savings account — where signatures from both parties are required to spend funds.
Two-factor Authentication wallet — where you have the confirm the transaction from another device.
To use it, you’ll need to use the latest wallet after the hardfork. From there it’s a matter of 1, 2, 3… 4, 5.
- Create a multisignature wallet.
- Add funds to a multisignature wallet.
- Any signatory can submit a spend transaction proposal
- Votes are cast to accept or reject the proposal
- When the threshold is reached before the blockheight is hit, the transaction is issued.
For more information on this, be sure to check out our youtube video “What Does a Quantum Secure Implementation of MultiSig Look Like? — Episode 005”
Ephemeral messaging latticeTX — Project Mercury
Dubbed as “Project Mercury”, ephemeral messaging has been a long awaited feature of QRL but was temporarily set aside to ensure the timely release of mainnet, and the stability of the core network.
Now with the Bromine hardfork release, you’ll be able to use all the functionality to create an ephemeral messaging application with the qrl-cli: https://github.com/theQRL/qrl-cli/
For the moment, you’ll still need to create your own off-chain network, but this sets the stage for go-qrl, where everything can be incorporated on-chain for a fully decentralized, quantum secure, ephemeral messaging network!
From https://github.com/jplomas/ephemeral-chat-poc — very WIP
If you want to get into the details of ephemeral messaging, be sure to take a look at our ephemeral messaging system whitepaper: https://github.com/theQRL/ephemeral/blob/master/EMS_whitepaper_v1.pdf
Other minor changes
Ability to toggle mainnet or testnet with a network-type argument to
Note: To run both at the same time, it’s still necessary to change ports in config.yml of one of the nodes.
Added addr_to field in message transaction
Now an address can be added to an 80 byte message transaction, allowing for assignable messages on the blockchain.
Added message_data to transfer transaction
Allows for on-chain transactions to include references to transaction ID’s in things like e-commerce applications.
- New API has been added to support data related to new transactions
- Address State has been optimized
- Legacy API support for wallet daemon & grpcProxy
- grpcProxy & wallet daemon both support — network-type as an argument
- Updated versions for some of the dependencies
- Added more unit tests covering different scenarios