View Bazaar branches
Get this repository:
git clone https://git.launchpad.net/pivx-core

Branches

Name Last Modified Last Commit
TESTNET_pr1002 2019-09-18 01:10:15 UTC 8 hours ago
[GUI] Tx detail dialog, show seconds in toString date.

Author: furszy
Author Date: 2019-09-18 01:10:15 UTC

[GUI] Tx detail dialog, show seconds in toString date.

master 2019-09-17 23:51:13 UTC 10 hours ago
Merge #968: [Staking][Wallet] Add Multi-Split functionality to stake output s...

Author: random-zebra
Author Date: 2019-09-17 23:50:35 UTC

Merge #968: [Staking][Wallet] Add Multi-Split functionality to stake output splitting

2e41db5fdb7f2abb16cd7703fc7a0b6bd41498a7 [Staking] Revise stakesplit to multi-split (Cave Spectre)

Pull request description:

  ### **Release notes**
  - [Staking] Staking inputs are now split into 2 or more outputs based on the stake split threshold

  ### **Note**
  For ease of rebasing; and for cleaner testing; this PR is built on top of PR #952 and will need adjustments if PR #952 has changes.

  ### **Background**
  The common function of `stakesplitthreshold` is to break a stake that has grown large into two outputs, splitting them in half. It is assumed the size of the split is based on the users amount of coins they are staking, and they desire their staking UTXOs to be sized between their stake split threshold and 2 times that stake split threshold.

  This design falters when a stake UTXO is a multiple of the stake split threshold; causing repetitive halving until all outputs reach below twice the stake split threshold.

  For example, with a stake split threshold of 2000; a UTXO will grow until it hits 4000 coins, at which point it will split to 2000 coins. However if the UTXO was 10,000 coins; it would split to two 5000 coin UTXOs, which would then split on the next stake for each of them; to 2500 coins.

  This becomes more problematic when considering the impact to the coin owners staking odds. After a split; the coins will not stake until they mature. So when that 10k splits into two 5k blocks, they won't stake for another 101 transactions. After 101 transactions, the 10k is now being staked, until the next split; at which point only 5k is staking for the next 101 transactions.

  This issue comes up in a variety of scenarios; A large transaction from an exchange or a payment received, Unlocking a masternode for staking, auto combine rewards (especially with PR #953) sweeping up a lot of dust bunnies into a big UTXO; just to name a few.

  ### **Multi-Split**
  Multi-Split will now use the stake split threshold to determine how many multiples of the threshold is contained in the input transaction; and split accordingly. In the theoretical example above; that first stake of 10k will now be split into 5 outputs of 2000.4. When one of those outputs receives a stake, instead of only the other 5k being staked for the 101 transactions to maturity; now 8k will remain staked for the maturity period of the UTXO (post split) being unavailable for staking.

  For a real example, with a stake split threshold of 1500, and a UTXO of 4708.1557; the current stake split algorithm would break that into two outputs of approximately 2355.07785. With this new logic; it will be broken into 3 outputs instead of two; each sized 1570.0519 (4708.1557 input + 2 stake = 4710.1557 / 3 outputs = 1570.0519.

  _See this test transaction in [testnet block 1171496](https://testnet.pivx.link/block/1171496)_

  In order to limit the potential size growth of the staking transaction; the number of splits is limited. This limit is a calculation based on the MAX_STANDARD_TX_SIZE, and is meant to limit the staking transaction to less than 10% of that size. With an assumed per vout size of 190, rounded up, and converted to a bit shift for speed; MAX_STANDARD_TX_SIZE is shifted right 11 bits. In simpler math:
   The limit is effectively MAX_STANDARD_TX_SIZE divided by 2048, creating a maximum limit of outputs for the stake split to 48 (with the current MAX_STANDARD_TX_SIZE of 100k).

  An example of this test can be seen in [testblock 1171785](https://testnet.pivx.link/block/1171785), where a UTXO of 13114.83882369 coins was used for a stake; and the stake split threshold was set to 100. The logic would have split this into 131 outputs of 131.116 and change, however the maximum threshold is reached, and thus it is split into 47 outputs of 273.26747549, with the 48th output having the .17 uPiv remainder added and resulting in that final output of 273.26747566.

  As the stake splitting is contained within the wallet software itself; there is **no protocol change with this PR**; the consensus is already built to look at the last vout for the masternode payment, and look at the total value of a variable number of outputs to confirm that an overmint is not occurring.

ACKs for top commit:
  random-zebra:
    ACK 2e41db5fdb7f2abb16cd7703fc7a0b6bd41498a7
  Fuzzbawls:
    utACK 2e41db5fdb7f2abb16cd7703fc7a0b6bd41498a7
  furszy:
    utACK [2e41db5](https://github.com/PIVX-Project/PIVX/commit/2e41db5fdb7f2abb16cd7703fc7a0b6bd41498a7)

Tree-SHA512: 35f612a5042de964bd3fda040ff2e3ea24de81300ecdc7d9d322757471df45cc4c7cb3d7905554ec41b607bb8364a94ced372c93ac7963c7729653d88cf32765

3.4 2019-08-26 12:46:13 UTC 2019-08-26
v3.4.0 release

Author: Fuzzbawls
Author Date: 2019-08-26 12:46:13 UTC

v3.4.0 release

3.3 2019-06-18 10:35:53 UTC 2019-06-18
PIVX Core v3.3.0

Author: Fuzzbawls
Author Date: 2019-06-18 10:34:00 UTC

PIVX Core v3.3.0

2019_annoying_debug_missing_line_jump 2019-06-14 13:12:33 UTC 2019-06-14
Update accumulators.cpp

Author: Matias Furszyfer
Author Date: 2019-06-14 13:12:33 UTC

Update accumulators.cpp

2019_publicSpend 2019-05-21 22:44:23 UTC 2019-05-21
[Consensus] spork 15 + min prev protocol version. (squash this later)

Author: furszy
Author Date: 2019-05-21 22:44:23 UTC

[Consensus] spork 15 + min prev protocol version. (squash this later)

3.2 2019-05-08 07:31:48 UTC 2019-05-08
3.2.2 Release

Author: Fuzzbawls
Author Date: 2019-05-08 07:31:48 UTC

3.2.2 Release

Bulletproofs 2018-12-27 11:46:12 UTC 2018-12-27
fix OSX compilation error

Author: random-zebra
Author Date: 2018-12-27 11:46:12 UTC

fix OSX compilation error

3.1 2018-07-10 04:02:43 UTC 2018-07-10
Bump version to 3.1.1

Author: Fuzzbawls
Author Date: 2018-07-10 04:02:43 UTC

Bump version to 3.1.1

3.0 2017-11-30 00:05:25 UTC 2017-11-30
Bump Version to 3.0.6

Author: Fuzzbawls
Author Date: 2017-11-30 00:05:25 UTC

Bump Version to 3.0.6

Add Release Notes

2.3 2017-09-19 03:55:07 UTC 2017-09-19
Merge #260: [RPC] Sanitize proposal-name and -URL parameters

Author: Fuzzbawls
Author Date: 2017-09-19 03:54:57 UTC

Merge #260: [RPC] Sanitize proposal-name and -URL parameters

08df887 [RPC] Sanitize proposal-name and -URL parameters (Mrs-X)

Tree-SHA512: 81ee152f2bd277c7c64a08e6f0ec0b713c85dacfa28fd2c4cf216a807cafa55e01a5e47612aea4ac11ba93fd6931270f98fb1033af799d816c39e59357e15651

2.2 2017-05-05 03:47:26 UTC 2017-05-05
Merge #173: [2.2.1] release process

Author: Fuzzbawls
Author Date: 2017-05-05 03:47:13 UTC

Merge #173: [2.2.1] release process

7bd59f5 [Build] Bump version to 2.2.1 (Fuzzbawls)
5b84ec1 [Doc] Add release notes for 2.2.1 (Fuzzbawls)
ebae538 Update translations for 2.2.1 (Fuzzbawls)
3186181 Update hard coded seeds for 2.2.1 (Fuzzbawls)

Tree-SHA512: c77e191a230f57fb0f24ef3e96d5e98ee5fadf55e0132d80e4a158e97f69114abcf501dee96053e2a09cba42567d89fbdd8f01fd588830b9cabc0e805e794593

112 of 12 results

Other repositories

Name Last Modified
lp:pivx-core 1 hour ago
lp:~fuzzbawls/pivx-core/+git/test 5 hours ago
12 of 2 results
You can't create new repositories for PIVX Core.