Skip to content
A digital currency for a new era of decentralized trust
Branch: master
Clone or download
scravy Use proper meta input prevout (#1099)
A coinbase transaction in both bitcoin as well as in unit-e includes a meta input which does not spend anything and is skipped in validation. It's scriptSig contains block height and snapshot hash.

The prevout of that input should be `0x00000` (which it is) and `0xFFFF` as index (currently uses 0). This is not correct and changed in this pull request. By using the default constructor of `COutPoint`, which in turn invokes `SetNull` (which sets the afore mentioned values), the right values are being filled in + delegated to the definition of `SetNull (as it should).

The problem otherwise: Theoretically it is allowed for a transaction to have the hash `0x00...00` (although this will lead to other problems in the wallet...), but it is super unlikely that any transaction would ever have 2^16 number of inputs. That both happen is astronomically super black hole merger unlikely.

Signed-off-by: Julian Fleischer <julian@thirdhash.com>
Latest commit 046062b May 17, 2019
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
.github Add more GitHub labels (#966) Apr 12, 2019
.travis Restore linters missed when merging bitcoin 0.17 (#1101) May 16, 2019
build-aux/m4 Merge Bitcoin 0.17 into master (#1013) May 2, 2019
contrib Fix pre-commit hook (#1103) May 17, 2019
depends Merge Bitcoin 0.17 into master (#1013) May 2, 2019
doc Restore linters missed when merging bitcoin 0.17 (#1101) May 16, 2019
share Merge Bitcoin 0.17 into master (#1013) May 2, 2019
src Use proper meta input prevout (#1099) May 17, 2019
test Use proper meta input prevout (#1099) May 17, 2019
.clonemachine Rename executables (#862) Apr 2, 2019
.gitattributes Separate protocol versioning from clientversion Oct 29, 2014
.gitignore Rename executables (#862) Apr 2, 2019
.pep8speaks.yml Enable lint-python.sh in Travis (#1090) May 10, 2019
.travis.yml Merge Bitcoin 0.17 into master (#1013) May 2, 2019
CHANGELOG.md Add initial changelog (#946) Apr 15, 2019
CODE_OF_CONDUCT.md Adapt code of conduct contact email (#910) Apr 9, 2019
CONTRIBUTING.md Refine CONTRIBUTING.md (#913) Apr 11, 2019
COPYING Add Unit-e copyright to COPYING file (#647) Feb 20, 2019
MAINTAINERS.md Adapt to Unit-e naming (#698) Mar 1, 2019
Makefile.am Merge Bitcoin 0.17 into master (#1013) May 2, 2019
README.md
autogen.sh Merge Bitcoin 0.17 into master (#1013) May 2, 2019
configure.ac Merge Bitcoin 0.17 into master (#1013) May 2, 2019
libuniteconsensus.pc.in Adapt Unit-e naming (#765) Mar 20, 2019
unit-e-logo.png Adapt README.md to unit-e (#633) Feb 19, 2019
unit-e-logo.svg Adapt README.md to unit-e (#633) Feb 19, 2019

README.md

Unit-e

Build Status pullreminders

The unit-e client is the first implementation for the Unit-e cryptocurrency network protocol, implemented in C++.

What is Unit-e?

Unit-e is providing a scalable and decentralized monetary and payment network based on current scientific research. It is the first project supported by the Distributed Technology Research Foundation (DTR). Its design is backed by the research DTR is funding, delivering the scalable performance needed to enter mainstream use. You can find more information about the project on the website and in the technical paper.

The Unit-e client

⚠️⚠️⚠️ WARNING: The client is under rapid development, is subject to breaking protocol changes (consensus, blockchain, p2p, RPC) and redoing from scratch of the alpha testnet. Please check the announcements page for information regarding such changes. ⚠️⚠️⚠️

This repository hosts the implementation of the first Unit-e client: unit-e, also known as the "Feuerland" client. It's based on the Bitcoin C++ client and introduces major improvements and features such as:

  • Replace Proof of Work (PoW) with Esperanza Proof of Stake (PoS). Unlike most blockchain projects, that's a complete rewrite of the consensus, leaving no trace of PoW while keeping the UTXO model and other areas (blockchain, p2p, wallet) functioning, potentially benefiting from future upstream improvements. In order to make it happen, we decoupled the layers and features to components with dependency injection following software design best practices. Allowing good testability and being able to do future modifications with confidence, including changes in the complex consensus layer
  • Finality is enabled by finalizer nodes, voting every epoch (currently 50 blocks), with advanced on-chain lifecycle (deposit, vote, slash, withdraw) on top of UTXO, using custom advanced scripts. Security is maintained through financial incentives, including availability requirement and slashing for misbehavior. Finality is essential for monetary applications, it mitigates against the major security issues of PoS (long-range, history revision, nothing-at-stake) and provides important scalability features such as pruning and fast-sync which otherwise wouldn't be possible in a fork-based PoS protocol
  • Staking wallet with remote staking support, activated by default, lightweight and without a minimum stake, allowing large participation rate and potential scale
  • Enhanced fork-choice rule by the best-finalized chain
  • Malleability protection through native SegWit support
  • Reduced bandwidth, storage, and time to sync of initial blockchain download by UTXO snapshots
  • Enhanced privacy through Dandelion Lite
  • Canonical transactions ordering, eliminating the need to send sorting metadata with each block, providing faster propagation and potential scability features as multi core validation
  • Optimized block propagation through a hybrid set reconciliation protocol of compact blocks and Graphene
  • Hardware wallet support, including remote staking

We regularly merge upstream changes into the unit-e code base and also strive to contribute back changes which are relevant for upstream as we already have done. The last upstream sync was with the 0.17 version, plus some changes cherry-picked from later development branches.

Alpha Testnet

With the launch of the alpha testnet we will start a regular cadence of releases. The goals of opening the project and network are to further develop the protocol, client and community:

  • The protocol isn't complete and will be further developed with breaking changes in order to reach our security & scalability goals (you can read about it more in the design paper).
  • Areas such as crypto-economics and coin emission rate, need to be well understood, fair and flexible - we're planning to use the testnet in order to figure out important aspects such as the level of stake required to keep the system secured and how should influence the emission rate.
  • We're opening our code repository to the blockchain and open-source community. We aspire to develop a community of active participants.

Currency emission

The current emission rate is fixed over time and isn't meant to be definitive, as we are still exploring the emission model from the economics & security perspectives, which goes side by side with the consensus protocol that is going to be further developed.

We plan to explore models with dynamic emission rate, where the network pays for the security it needs. In PoS consensus, taking into account the number of tokens being deposited/staked seems like the right direction.

As was also researched, time-based emission, starting very high and decreasing over the years (in Bitcoin halving every four years), isn't securing the protocol efficiently nor is it fair in terms of compounding and the future currency distribution.

Running from source

To run unit-e from sources you will need to check it out from this GitHub repository, compile it, and launch the resulting binary. This currently is the only supported way of running it. Detailed instructions for a variety of platforms can be found in the docs directory.

Development

Development takes place on the master branch. All code changes go through peer-reviewed and tested pull requests. We aim for meeting high standards as an open source project and a collaborative community project. The contribution workflow is described in CONTRIBUTING.md.

The Unit-e team is committed to fostering a welcoming and harassment-free environment. All participants are expected to adhere to our code of conduct.

Testing

We strive to keep the unit-e codebase fully tested and covered by automated tests.

Unit tests can be compiled and run with: make check. Further details on running and extending unit tests can be found in src/test/README.md.

There are also functional tests, including regression and integration tests. They are written in Python and most of them are also run as part of automated continuous integration. These tests can be run locally with test/functional/test_runner.py.

Unit and functional tests are run on Travis as part of our continuous integration system. This tests the master branch and all pull requests. It makes sure that code is checked, built and tested for Windows, Linux, and OS X automatically before it gets merged into master.

Any additional testing, automated or manual, is very welcome. If you encounter any issues or run into bugs please report them as issues.

Related repositories

License

unit-e is released under the terms of the MIT license. See COPYING for more information or see https://opensource.org/licenses/MIT.

You can’t perform that action at this time.