First batch of per-utxo backports (up until 0.13)#1691
Merged
UdjinM6 merged 12 commits intodashpay:developfrom Oct 23, 2017
Merged
First batch of per-utxo backports (up until 0.13)#1691UdjinM6 merged 12 commits intodashpay:developfrom
UdjinM6 merged 12 commits intodashpay:developfrom
Conversation
8504867 Save the last unnecessary database read (Alex Morcos)
…`gettxoutsetinfo` 509cb00 txdb: Add Cursor() method to CCoinsView to iterate over UTXO set (Wladimir J. van der Laan)
a3310b4 txdb: Fix assert crash in new UTXO set cursor (Wladimir J. van der Laan)
…r other databases 869cf12 dbwrapper: Move `HandleError` to `dbwrapper_private` (Wladimir J. van der Laan) b69836d dbwrapper: Pass parent CDBWrapper into CDBBatch and CDBIterator (Wladimir J. van der Laan) 878bf48 dbwrapper: Remove CDBWrapper::GetObfuscateKeyHex (Wladimir J. van der Laan) 74f7b12 dbwrapper: Remove throw keywords in function signatures (Wladimir J. van der Laan)
99e7075 Break circular dependency main ↔ txdb (Wladimir J. van der Laan)
txdb.h does not include validation.h anymore, so we need these structs somewhere else
This is ~1.7x slower than the Lookup3-of-Xor-with-salt construct we were using before, but it is a primitive designed for exactly this.
Taken from Bitcoin bitcoin#8173/888483098e60f2a944f1d246bbfec4d14a2975f8 Needed to align code for upcoming per-utxo backports.
c6cb6f7 Avoid unnecessary database access for unknown transactions (Alex Morcos)
…lid length 1e44169 Add tests for CCoins deserialization (Pieter Wuille) 5d0434d Fix OOM bug: UTXO entries with invalid script length (Pieter Wuille) 4bf631e CDataStream::ignore Throw exception instead of assert on negative nSize. (Patrick Strateman) 4f87af6 Treat overly long scriptPubKeys as unspendable (Pieter Wuille) f8e6fb1 Introduce constant for maximum CScript length (Pieter Wuille)
This was referenced Oct 23, 2017
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is the first batch of backported PRs required to get the per-utxo changes from Bitcoin into Dash. This batch contains the PRs up until Bitcoin 0.13.
The list of required PRs was gathered by looking at commit logs on files which are related to the UTXO handling/storing. I also included other PRs (or single commits) which were required to fix compilation and to reduce later conflicts as much as possible, while trying my best to not introduce changes not related to UTXOs at all.
In some cases it may not be immediately clear why I chose a specific PR. This will only be visible in the upcoming batches as these will then touch the code changed by the PRs in this batch. This is part of the conflict avoidance strategy I chose. If you have questions, I can dig up the reason for specific PRs in my local branch (which contains all PRs).
@UdjinM6 You normally merge PRs in squashed mode, which is the preferred way in most cases. In this case however, is it possible that you merge this PR (and the followups) without squashing? With squashed merging, it will later become very hard to backtrack changes. I'm using the annotate/blame feature of Git all the time to figure out why/when a change was introduced, so I can decide what needs to be done when I get merge conflicts. With squashed merges, "blame" will show that all changes were done in one commit.
I'd suggest to do review on commit/PR basis instead of looking at all changes. To get the original Bitcoin PR, click on the #XXXX link you'll find in the commit message. Commits which were added by myself, contain a short explanation why they were needed.