---WARNING----This Branch is under development---- If you want to build or use source, please relay on release tags, or branches. This branch is highly experimental.
http://www.uralscoin.info Bitcointalk https://bitcointalk.org/index.php?topic=2369658.0
This is a new major version release, bringing both new features and bug fixes.
Please report bugs using the issue tracker at github: https://github.com/JohnMnemonick/UralsCoin/issues
If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes for older versions), then run the installer (on Windows) or just copy over /Applications/urals-Qt (on Mac) or uralsd/urals-qt (on Linux).
Segregated witness (segwit) is a soft fork that, if activated, will allow transaction-producing software to separate (segregate) transaction signatures (witnesses) from the part of the data in a transaction that is covered by the txid. This provides several immediate benefits:
-
Elimination of unwanted transaction malleability: Segregating the witness allows both existing and upgraded software to calculate the transaction identifier (txid) of transactions without referencing the witness, which can sometimes be changed by third-parties (such as miners) or by co-signers in a multisig spend. This solves all known cases of unwanted transaction malleability, which is a problem that makes programming Bitcoin wallet software more difficult and which seriously complicates the design of smart contracts for Bitcoin.
-
Capacity increase: Segwit transactions contain new fields that are not part of the data currently used to calculate the size of a block, which allows a block containing segwit transactions to hold more data than allowed by the current maximum block size. Estimates based on the transactions currently found in blocks indicate that if all wallets switch to using segwit, the network will be able to support about 70% more transactions. The network will also be able to support more of the advanced-style payments (such as multisig) than it can support now because of the different weighting given to different parts of a transaction after segwit activates (see the following section for details).
-
Weighting data based on how it affects node performance: Some parts of each Bitcoin block need to be stored by nodes in order to validate future blocks; other parts of a block can be immediately forgotten (pruned) or used only for helping other nodes sync their copy of the block chain. One large part of the immediately prunable data are transaction signatures (witnesses), and segwit makes it possible to give a different "weight" to segregated witnesses to correspond with the lower demands they place on node resources. Specifically, each byte of a segregated witness is given a weight of 1, each other byte in a block is given a weight of 4, and the maximum allowed weight of a block is 4 million. Weighting the data this way better aligns the most profitable strategy for creating blocks with the long-term costs of block validation.
-
Signature covers value: A simple improvement in the way signatures are generated in segwit simplifies the design of secure signature generators (such as hardware wallets), reduces the amount of data the signature generator needs to download, and allows the signature generator to operate more quickly. This is made possible by having the generator sign the amount of bitcoins they think they are spending, and by having full nodes refuse to accept those signatures unless the amount of bitcoins being spent is exactly the same as was signed. For non-segwit transactions, wallets instead had to download the complete previous transactions being spent for every payment they made, which could be a slow operation on hardware wallets and in other situations where bandwidth or computation speed was constrained.
-
Linear scaling of sighash operations: In 2015 a block was produced that required about 25 seconds to validate on modern hardware because of the way transaction signature hashes are performed. Other similar blocks, or blocks that could take even longer to validate, can still be produced today. The problem that caused this can't be fixed in a soft fork without unwanted side-effects, but transactions that opt-in to using segwit will now use a different signature method that doesn't suffer from this problem and doesn't have any unwanted side-effects.
-
Increased security for multisig: Bitcoin addresses (both P2PKH addresses that start with a '1' and P2SH addresses that start with a '3') use a hash function known as RIPEMD-160. For P2PKH addresses, this provides about 160 bits of security---which is beyond what cryptographers believe can be broken today. But because P2SH is more flexible, only about 80 bits of security is provided per address. Although 80 bits is very strong security, it is within the realm of possibility that it can be broken by a powerful adversary. Segwit allows advanced transactions to use the SHA256 hash function instead, which provides about 128 bits of security (that is 281 trillion times as much security as 80 bits and is equivalent to the maximum bits of security believed to be provided by Bitcoin's choice of parameters for its Elliptic Curve Digital Security Algorithm [ECDSA].)
-
More efficient almost-full-node security Satoshi Nakamoto's original Bitcoin paper describes a method for allowing newly-started full nodes to skip downloading and validating some data from historic blocks that are protected by large amounts of proof of work. Unfortunately, Nakamoto's method can't guarantee that a newly-started node using this method will produce an accurate copy of Bitcoin's current ledger (called the UTXO set), making the node vulnerable to falling out of consensus with other nodes. Although the problems with Nakamoto's method can't be fixed in a soft fork, Segwit accomplishes something similar to his original proposal: it makes it possible for a node to optionally skip downloading some blockchain data (specifically, the segregated witnesses) while still ensuring that the node can build an accurate copy of the UTXO set for the block chain with the most proof of work. Segwit enables this capability at the consensus layer, but note that Bitcoin Core does not provide an option to use this capability as of this 0.13.1 release.
-
Script versioning: Segwit makes it easy for future soft forks to allow Bitcoin users to individually opt-in to almost any change in the Bitcoin Script language when those users receive new transactions. Features currently being researched by Bitcoin Core contributors that may use this capability include support for Schnorr signatures, which can improve the privacy and efficiency of multisig transactions (or transactions with multiple inputs), and Merklized Abstract Syntax Trees (MAST), which can improve the privacy and efficiency of scripts with two or more conditions. Other Bitcoin community members are studying several other improvements that can be made using script versioning.
Moving forward, we've dropped support for both InstantTX and DarkSend. With the SegWit upgrade these features are going to be superseeded by far superior technology. SegWit will enable the Urals to adopt the Lightning Network (https://lightning.network/lightning-network-paper.pdf), cross-chain atomic swaps, advanced versions of TumbleBit (https://eprint.iacr.org/2016/575.pdf) and more.
Validation speed and network propagation performance have been greatly improved, leading to much shorter sync and initial block download times.
- The script signature cache has been reimplemented as a "cuckoo cache", allowing for more signatures to be cached and faster lookups.
- Assumed-valid blocks have been introduced which allows script validation to be skipped for ancestors of known-good blocks, without changing the security model. See below for more details.
- In some cases, compact blocks are now relayed before being fully validated as per BIP152.
- P2P networking has been refactored with a focus on concurrency and throughput. Network operations are no longer bottlenecked by validation. As a result, block fetching is several times faster than previous releases in many cases.
- The UTXO cache now claims unused mempool memory. This speeds up initial block download as UTXO lookups are a major bottleneck there, and there is no use for the mempool at that stage.
Newly created wallets will use hierarchical deterministic key generation according to BIP32 (keypath m/0'/0'/k'). Existing wallets will still use traditional key generation.
Backups of HD wallets, regardless of when they have been created, can therefore be used to re-generate all possible private keys, even the ones which haven't already been generated during the time of the backup. Attention: Encrypting the wallet will create a new seed which requires a new backup!
Wallet dumps (created using the dumpwallet RPC) will contain the deterministic
seed. This is expected to allow future versions to import the seed and all
associated funds, but this is not yet implemented.
HD key generation for new wallets can be disabled by -usehd=0. Keep in
mind that this flag only has affect on newly created wallets.
You can't disable HD key generation once you have created a HD wallet.
There is no distinction between internal (change) and external keys.
HD wallets are incompatible with older versions of Bitcoin Core.
ECDSA signatures inside Bitcoin transactions now use validation using libsecp256k1 instead of OpenSSL.
Depending on the platform, this means a significant speedup for raw signature validation speed. The advantage is largest on x86_64, where validation is over five times faster. In practice, this translates to a raw reindexing and new block validation times that are less than half of what it was before.
Libsecp256k1 has undergone very extensive testing and validation.
A side effect of this change is that libconsensus no longer depends on OpenSSL.
A major part of the outbound traffic is caused by serving historic blocks to other nodes in initial block download state.
It is now possible to reduce the total upload traffic via the -maxuploadtarget
parameter. This is not a hard limit but a threshold to minimize the outbound
traffic. When the limit is about to be reached, the uploaded data is cut by not
serving historic blocks (blocks older than one week).
Moreover, any SPV peer is disconnected when they request a filtered block.
This option can be specified in MiB per day and is turned off by default
(-maxuploadtarget=0).
The recommended minimum is 144 * MAX_BLOCK_SIZE (currently 144MB) per day.
Whitelisted peers will never be disconnected, although their traffic counts for calculating the target.
A more detailed documentation about keeping traffic low can be found in /doc/reduce-traffic.md.
Between compatible peers, [BIP 130] (https://github.com/bitcoin/bips/blob/master/bip-0130.mediawiki) direct headers announcement is used. This means that blocks are advertised by announcing their headers directly, instead of just announcing the hash. In a reorganization, all new headers are sent, instead of just the new tip. This can often prevent an extra roundtrip before the actual block is downloaded.
With 0.12 it is possible to use wallet functionality in pruned mode. This can reduce the disk usage from currently around 60 GB to around 2 GB.
However, rescans as well as the RPCs importwallet, importaddress,
importprivkey are disabled.
To enable block pruning set prune=<N> on the command line or in
urals.conf, where N is the number of MiB to allot for
raw block & undo data.
A value of 0 disables pruning. The minimal value above 0 is 550. Your wallet is as secure with high values as it is with low ones. Higher values merely ensure that your node will not shut down upon blockchain reorganizations of more than 2 days - which are unlikely to happen in practice. In future releases, a higher value may also help the network as a whole: stored blocks could be served to other nodes.
For further information about pruning, you may also consult the release notes of v0.11.0.
The above only includes the most notable changes. Links to detailed release notes follow.
Update Urals 1.2.7.1
- add the command
shrinkdebuginterval(new feature which allows shrinking the debug file periodically) - getblocktemplate fix
- add new Help File "Create build-ubuntu-1404.md"
Urals is an experimental and new digital currency that enables anonymous, instant payments to anyone, anywhere in the world. Urals uses peer-to-peer technology to operate without a central authority: transaction management and money subsidy are carried out collectively by the network. Urals Core is the name of open source software which enables the use of this currency.
For more information, as well as an immediately useable, binary version of the Urals Core software, see http://www.uralscoin.info
Urals Core is released under the terms of the MIT license. See COPYING for more information or see https://opensource.org/licenses/MIT.
The master branch is meant to be stable. Development is normally done in separate branches.
Tags are created to indicate new official,
stable release versions of Urals Core.
The contribution workflow is described in CONTRIBUTING.md.
compiling Urals from git
Use the autogen script to prepare the build environment.
./autogen.sh
./configure
make
precompiled binaries
Precompiled binaries are available at GitHub, see https://github.com/JohnMnemonick/UralsCoin/releases
Always verify the signatures and checksums.
compiling for debugging
Run configure with the --enable-debug option, then make. Or run configure with CXXFLAGS="-g -ggdb -O0" or whatever debug flags you need.
debug.log
If the code is behaving strangely, take a look in the debug.log file in the data directory; error and debugging message are written there.
The -debug=... command-line option controls debugging; running with just -debug will turn on all categories (and give you a very large debug.log file).
The Qt code routes qDebug() output to debug.log under category "qt": run with -debug=qt to see it.
testnet and regtest modes
Run with the -testnet option to run with "play uralss" on the test network, if you are testing multi-machine code that needs to operate across the internet.
If you are testing something that can run on one machine, run with the -regtest option. In regression test mode blocks can be created on-demand; see qa/rpc-tests/ for tests that run in -regtest mode.
DEBUG_LOCKORDER
Urals Core is a multithreaded application, and deadlocks or other multithreading bugs can be very difficult to track down. Compiling with -DDEBUG_LOCKORDER (configure CXXFLAGS="-DDEBUG_LOCKORDER -g") inserts run-time checks to keep track of what locks are held, and adds warning to the debug.log file if inconsistencies are detected.