Update Bitmark to Bitcoin source code v.27 #135
Conversation
This file contains 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
Ensure we are checking sigop-adjusted virtual size by creating setups and packages where sigop cost is larger than bip141 vsize. Co-authored-by: Gregory Sanders <[email protected]>
…etban.py --v2transport`, run it in CI cc87ee4 test: fix intermittent failure in rpc_setban.py --v2transport (Martin Zumsande) Pull request description: This test failed for me on master locally: The reason is that when initiating a v2 connection and being immediately disconnected, a node cannot know if the disconnect happens because the peer only supports v1, or because it has banned you, so it schedules to reconnect with v1. If the test doesn't wait for that, the reconnect can happen at a bad time, resulting in failure in a later `connect_nodes` call. Also add the test with `--v2transport` to the test runner because banning with v2 seems like a useful thing to have test coverage for. ACKs for top commit: delta1: tested ACK cc87ee4 epiccurious: Concept ACK cc87ee4. achow101: ACK cc87ee4 stratospher: tested ACK cc87ee4. nice find! Tree-SHA512: ae234d9b771d9c9c11501ddd93c99cf93257c999de3da62280d4d51806cd246b289c10a5f41fa7d5651b2fb4fdaee753f5b2d6939a99f89d71aa012af4a4d231
…it tests 5ca9b24 test: Add makefile target for running unit tests (TheCharlatan) Pull request description: `make check` runs a bunch of other subtree tests that exercise code that is hardly ever changed and have a comparatively long runtime. There seems to be no target for running just the unit tests, so add one. Alternatively the secp256k1 tests could be removed from the `check-local` target, reducing its runtime. This was rejected before though in bitcoin/bitcoin#20264. ACKs for top commit: delta1: utACK 5ca9b24 edilmedeiros: Tested ACK 5ca9b24 achow101: ACK 5ca9b24 ryanofsky: Tested ACK 5ca9b24. Tree-SHA512: 470969d44585d7cc33ad038a16e791db9e2be8469f52ddf122c46f20776fad34e6a48f988861a132c42540158fed05f3cf66fcc3bea05708253daaa35af54339
… msg disconnect if limit is reached, improve existing test coverage b58f009 test: check that mempool msgs lead to disconnect if uploadtarget is reached (Sebastian Falbesoner) dd5cf38 test: check for specific disconnect reasons in feature_maxuploadtarget.py (Sebastian Falbesoner) 73d7372 test: verify `-maxuploadtarget` limit state via `getnettotals` RPC result (Sebastian Falbesoner) Pull request description: This PR improves existing and adds new test coverage for the `-maxuploadtarget` mechanism (feature_maxuploadtarget.py) in the following ways, one commit each: * verify the uploadtarget state via the `getnettotals` RPC (`uploadtarget` result field): https://github.com/bitcoin/bitcoin/blob/160d23677ad799cf9b493eaa923b2ac080c3fb8e/src/rpc/net.cpp#L581-L582 Note that reaching the total limit (`target_reached` == True) always implies that the historical blocks serving limits is also reached (`serve_historical_blocks` == False), i.e. it's impossible that both flags are set to True. * check for peer's specific disconnect reason (in this case, `"historical block serving limit reached, disconnect peer"`): https://github.com/bitcoin/bitcoin/blob/160d23677ad799cf9b493eaa923b2ac080c3fb8e/src/net_processing.cpp#L2272-L2280 * add a test for a peer disconnect if the uploadtarget is reached and a `mempool` message is received (if bloom filters are enabled): https://github.com/bitcoin/bitcoin/blob/160d23677ad799cf9b493eaa923b2ac080c3fb8e/src/net_processing.cpp#L4755-L4763 Note that another reason for disconnect after receiving a MEMPOOL msg of a peer is if bloom filters are disabled on the node. This case is already covered in the functional test `p2p_nobloomfilter_messages.py`. ACKs for top commit: maflcko: lgtm ACK b58f009 achow101: ACK b58f009 sr-gi: tACK [b58f009](bitcoin/bitcoin@b58f009) Tree-SHA512: 7439134129695c9c3a7ddc5e39f2ed700f91e7c91f0b7a9e0a783f275c6aa2f9918529cbfd38bb37f9139184e05e0f0354ef3c3df56da310177ec1d6b48b43d0
CoinGrinder is a DFS-based coin selection algorithm that deterministically finds the input set with the lowest weight creating a change output.
CoinGrinder may not be able to exhaustively search all potentially interesting combinations for large UTXO pools, so we keep track of whether the search was terminated by the iteration limit.
Co-authored-by: Pieter Wuille <[email protected]>
Once we exceed the weight of the current best selection, we can always shift as adding more inputs can never yield a better solution.
Introduces a dedicated data structure to track the total effective_value available in the remaining UTXOs at each index of the UTXO pool. In contrast to the approach in BnB, this allows us to immediately jump to a lower index instead of visiting every UTXO to add back their eff_value to the lookahead.
When two successive UTXOs match in effective value and weight, we can
skip the second if the prior is not selected: adding it would create an
equivalent input set to a previously evaluated.
E.g. if we have three UTXOs with effective values {5, 3, 3} of the same
weight each, we want to evaluate
{5, _, _}, {5, 3, _}, {5, 3, 3}, {_, 3, _}, {_, 3, 3},
but skip {5, _, 3}, and {_, _, 3}, because the first 3 is not selected,
and we therefore do not need to evaluate the second 3 at the same
position in the input set.
If we reach the end of the branch, we must SHIFT the previously selected
UTXO group instead.
When two successive UTXOs differ in weight but match in effective value, we can skip the second if the first is not selected, because all input sets we can generate by swapping out a lighter UTXOs with a heavier UTXO of matching effective value would be strictly worse.
In situations where we have UTXO groups of various weight, we can CUT rather than SHIFT when we exceeded the max_weight or the best selection’s weight while the last step was equal to the minimum weight in the lookahead.
Initialize `best_selection_weight` as `max_weight` allows us to skip the separate `max_weight` check on every loop.
Given a lot of small amount UTXOs it is possible that the lookahead indicates sufficient funds, but any combination of them would push us beyond the current best_weight. We can estimate a lower bound for the minimal necessary weight to reach target from the maximal amount and minimal weight in the tail of the UTXO pool: if adding a number of hypothetical UTXOs of this maximum amount and minimum weight would not be able to beat `best_weight`, we can SHIFT to the omission branch, and CUT if the last selected UTXO is not heavier than the minimum weight of the remainder.
The goal of the function is to erase the wallet transactions that match the inputted hashes. There is no need to traverse the database, reading record by record, to then perform single entry removals for each of them. To ensure consistency and improve performance, this change-set removes all tx records within a single atomic db batch operation, as well as it cleans up code, improves error handling and simplifies the transactions removal process entirely. This optimizes the removal of watch-only transactions during the wallet migration process and the 'removeprunedfunds' RPC command.
-BEGIN VERIFY SCRIPT- sed -i 's/ZapSelectTx/RemoveTxs/g' $(git grep -l 'ZapSelectTx' ./src/wallet) -END VERIFY SCRIPT-
…lgorithm 13161ec opt: Skip over barren combinations of tiny UTXOs (Murch) b7672c7 opt: Skip checking max_weight separately (Murch) 1edd2ba opt: Cut if last addition was minimal weight (Murch) 5248e2a opt: Skip heavier UTXOs with same effective value (Murch) 9124c73 opt: Tiebreak UTXOs by weight for CoinGrinder (Murch) 451be19 opt: Skip evaluation of equivalent input sets (Murch) 407b1e3 opt: Track remaining effective_value in lookahead (Murch) 5f84f3c opt: Skip branches with worse weight (Murch) d68bc74 fuzz: Test optimality of CoinGrinder (Murch) 67df6c6 fuzz: Add CoinGrinder fuzz target (Murch) 1502231 coinselection: Track whether CG completed (Murch) 7488acc test: Add coin_grinder_tests (Murch) 6cc9a46 coinselection: Add CoinGrinder algorithm (Murch) 89d0956 opt: Tie-break UTXO sort by waste for BnB (Murch) aaee658 doc: Document max_weight on BnB (Murch) Pull request description: ***Please refer to the [topic on Delving Bitcoin](https://delvingbitcoin.org/t/gutterguard-and-coingrinder-simulation-results/279) discussing Gutter Guard/Coingrinder simulation results.*** Adds a coin selection algorithm that minimizes the weight of the input set while creating change. Motivations --- - At high feerates, using unnecessary inputs can significantly increase the fees - Users are upset when fees are relatively large compared to the amount sent - Some users struggle to maintain a sufficient count of UTXOs in their wallet Approach --- So far, Bitcoin Core has used a balanced approach to coin selection, where it will generate multiple input set candidates using various coin selection algorithms and pick the least wasteful among their results, but not explicitly minimize the input set weight. Under some circumstances, we _do_ want to minimize the weight of the input set. Sometimes changeless solutions require many or heavy inputs, and there is not always a changeless solution for Branch and Bound to find in the first place. This can cause expensive transactions unnecessarily. Given a wallet with sufficient funds, `CoinGrinder` will pick the minimal-waste input set for a transaction with a change output. The current implementation only runs `CoinGrinder` at feerates over 3×long-term-feerate-estimate (by default 30 ṩ/vB), which may be a decent compromise between our goal to reduce costs for the users, but still permit transactions at lower feerates to naturally reduce the wallet’s UTXO pool to curb bloat. Trade-offs --- Simulations for my thesis on coin selection ([see Section 6.3.2.1 [PDF]](https://murch.one/erhardt2016coinselection.pdf)) suggest that minimizing the input set for all transactions tends to grind a wallet’s UTXO pool to dust (pun intended): an approach selecting inputs per coin-age-priority (in effect similar to “largest first selection”) on average produced a UTXO pool with 15× the UTXO count as Bitcoin Core’s Knapsack-based Coin Selection then (in 2016). Therefore, I do not recommend running `CoinGrinder` under all circumstances, but only at extreme feerates or when we have another good reason to minimize the input set for other reasons. In the long-term, we should introduce additional metrics to score different input set candidates, e.g. on basis of their privacy and wallet health impact, to pick from all our coin selection results, but until then, we may want to limit use of `CoinGrinder` in other ways. ACKs for top commit: achow101: ACK 13161ec sr-gi: ACK [13161ec](bitcoin/bitcoin@13161ec) sipa: ACK 13161ec Tree-SHA512: 895b08b2ebfd0b71127949b7dba27146a6d10700bf8590402b14f261e7b937f4e2e1b24ca46de440c35f19349043ed2eba4159dc2aa3edae57721384186dae40
29029df [doc] v3 signaling in mempool-replacements.md (glozow) e643ea7 [fuzz] v3 transactions and sigop-adjusted vsize (glozow) 1fd16b5 [functional test] v3 transaction submission (glozow) 27c8786 test framework: Add and use option for tx-version in MiniWallet methods (MarcoFalke) 9a1fea5 [policy/validation] allow v3 transactions with certain restrictions (glozow) eb8d5a2 [policy] add v3 policy rules (glozow) 9a29d47 [rpc] return full string for package_msg and package-error (glozow) 158623b [refactor] change Workspace::m_conflicts and adjacent funcs/structs to use Txid (glozow) Pull request description: See #27463 for overall package relay tracking. Delving Bitcoin discussion thread: https://delvingbitcoin.org/t/v3-transaction-policy-for-anti-pinning/340 Delving Bitcoin discussion for LN usage: https://delvingbitcoin.org/t/lightning-transactions-with-v3-and-ephemeral-anchors/418 Rationale: - There are various pinning problems with RBF and our general ancestor/descendant limits. These policies help mitigate many pinning attacks and make package RBF feasible (see #28984 which implements package RBF on top of this). I would focus the most here on Rule 3 pinning. [1][2] - Switching to a cluster-based mempool (see #27677 and #28676) requires the removal of CPFP carve out, which applications depend on. V3 + package RBF + ephemeral anchors + 1-parent-1-child package relay provides an intermediate solution. V3 policy is for "Priority Transactions." [3][4] It allows users to opt in to more restrictive topological limits for shared transactions, in exchange for the more robust fee-bumping abilities that offers. Even though we don't have cluster limits, we are able to treat these transactions as having as having a maximum cluster size of 2. Immediate benefits: - You can presign a transaction with 0 fees (not just 1sat/vB!) and add a fee-bump later. - Rule 3 pinning is reduced by a significant amount, since the attacker can only attach a maximum of 1000vB to your shared transaction. This also enables some other cool things (again see #27463 for overall roadmap): - Ephemeral Anchors - Package RBF for these 1-parent-1-child packages. That means e.g. a commitment tx + child can replace another commitment tx using the child's fees. - We can transition to a "single anchor" universe without worrying about package limit pinning. So current users of CPFP carve out would have something else to use. - We can switch to a cluster-based mempool [5] (#27677 #28676), which removes CPFP carve out [6]. [1]: Original mailing list post and discussion about RBF pinning problems https://gist.github.com/glozow/25d9662c52453bd08b4b4b1d3783b9ff, https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019817.html [2]: A FAQ is "we need this for cluster mempool, but is this still necessary afterwards?" There are some pinning issues that are fixed here and not fully fixed in cluster mempool, so we will still want this or something similar afterward. [3]: Mailing list post for v3 https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020937.html [4]: Original PR #25038 also contains a lot of the discussion [5]: https://delvingbitcoin.org/t/an-overview-of-the-cluster-mempool-proposal/393/7 [6]: https://delvingbitcoin.org/t/an-overview-of-the-cluster-mempool-proposal/393#the-cpfp-carveout-rule-can-no-longer-be-supported-12 ACKs for top commit: sdaftuar: ACK 29029df achow101: ACK 29029df instagibbs: ACK 29029df modulo that Tree-SHA512: 9664b078890cfdca2a146439f8835c9d9ab483f43b30af8c7cd6962f09aa557fb1ce7689d5e130a2ec142235dbc8f21213881baa75241c5881660f9008d68450
…for BIP21 URIs ede5014 Modify command line help to show support for BIP21 URIs (Hernan Marino) Pull request description: While reviewing a different PR (see bitcoin-core/gui#742 ) **hebasto** suggested that the help for bitcoin-qt should be updated to reflect the fact that bitcoin-qt supports an optional BIP21 URI parameter. Since this reflects actual behaviour of bitcoin-qt and is independent of whether or not the other PR gets merged, I created this simple PR to fix the help message. ACKs for top commit: kristapsk: utACK ede5014 pablomartin4btc: lgtm, re ACK ede5014 hebasto: ACK ede5014. Tree-SHA512: c456297c486bc5cc65e0e092e7ba9d51b0bd7a584d4fabca7f7ca1f8e58cbcc66e96226539c689ed0f5e7f40da220bbc4ea30b90e31e1aeeb8867a385a90209c
…sabled if no wallet is selected b2e531e qt: update widgets availability on wallet selection (pablomartin4btc) Pull request description: This PR addresses an issue where, with no wallet selected, ticking on "Settings -> Mask values" checkbox twice enables the transaction tab when the checkbox is unticked. <details> <summary>Current behavior display on master</summary>  </details> <details> <summary>Correction display from this branch</summary>  </details> Note for maintaners: this PR should be backported to both 25.x and 26.x. --- Originally this PR was disabling the "Mask Values" checkbox when no wallet was selected but since a reviewer pointed out that a user might want to open a wallet already on "privacy mode" I rolled that change out. <details> <summary>Original correction display disabling "Mask Values" </summary>  </details> ACKs for top commit: alfonsoromanz: Tested ACK bitcoin-core/gui@b2e531e hebasto: ACK b2e531e, tested on Ubuntu 22.04. Tree-SHA512: 6be77ab4d5ec86267a9b0a289a4d8600bb67d279f7e0be65e47b608ec392fe705cf026e32f3c082d2f27449b697d1d9e6a1d110035900d7a804ba823c9f5dfd4
…gnedness fa0ceae test: Fix utxo set hash serialisation signedness (MarcoFalke) Pull request description: It is unsigned in Bitcoin Core, so the tests should match it: https://github.com/bitcoin/bitcoin/blob/5b8990a1f3c49b0b02b7383c69e95320acbda13e/src/kernel/coinstats.cpp#L54 Large positive values for the block height are too difficult to hit in tests, but it still seems fine to fix this. The bug was introduced when the code was written in 6ccc8fc. (Lowercase `i` means signed, see https://docs.python.org/3/library/struct.html#format-characters) ACKs for top commit: epiccurious: Tested ACK fa0ceae. fjahr: utACK fa0ceae Tree-SHA512: ab4405c74fb191fff8520b456d3a800cd084d616bb9ddca27d56b8e5c8969bd537490f6e204c1870dbb09a3e130b03b22a27b6644252a024059c200bbd9004e7
…ter the user has touched it bee0ffb GUI/Intro: Never change the prune checkbox after the user has touched it (Luke Dashjr) 420a983 Bugfix: GUI/Intro: Disable GUI prune option if -prune is set, regardless of set value (Luke Dashjr) Pull request description: Re-PR from bitcoin/bitcoin#18729 Now includes a bugfix too (`-prune=2+` disabled the checkbox, but `-prune=0/1` did not; this behaviour is necessary since `-prune` overrides GUI settings) ACKs for top commit: hebasto: ACK bee0ffb, both commits are improvements of the current behaviour. Tested on Ubuntu 23.10. Tree-SHA512: 8eb7d90af37deb30fe226179db3bc9df8ab59e4f3218c8e447ed31fc9ddc81ac1a1629da63347518587a56a4c8558b05cf7ec474024c5f5dfc6d49d6ff0eb0cc
9d37886 gui: Update Node window title with chain type (pablomartin4btc) Pull request description: It fixes #544. Enhance the Node window title by appending the chain type to it, except for the `mainnet`, mirroring the behavior in the main window.  There was also some [interest](bitcoin-core/gui#78 (comment)) on this while discussing network switching. ACKs for top commit: MarnixCroes: tACK 9d37886 hernanmarino: tACK 9d37886 BrandonOdiwuor: tested ACK 9d37886 alfonsoromanz: Tested ACK bitcoin-core/gui@9d37886 kristapsk: ACK 9d37886 hebasto: ACK 9d37886, tested on Ubuntu 23.10. Tree-SHA512: 8c34c4586bd59b1c522662e8aa0726dccc8f12e020f7a6a1af5200a29e5817e1c51e0f467c7923041fc41535ea093c3e0dd787befbbcc84d6b9f7ff0d969db04
d756a38 doc: update manual pages for 27.1 (fanquake) 93bb18f build: bump version to v27.1 final (fanquake) fcf1241 doc: update release notes for v27.1 final (fanquake) f2e05cd depends: Update Boost download link (Hennadii Stepanov) ba35920 build: Fix building `fuzz` binary on on SunOS / illumos (Hennadii Stepanov) Pull request description: Backports: * bitcoin/bitcoin#30216 * bitcoin/bitcoin#30217 I don't think either of these changes warrants an `rc2` cycle. ACKs for top commit: stickies-v: ACK d756a38 willcl-ark: ACK d756a38 Tree-SHA512: b5662143283a49156403d865dee25f3b6c22741345a4c8ff10f16845ea7a1a6d9d1319a70a44d07f31263bf1a6d85701146e9cc697b82a5a58922c48504a552c
Allows IPV6 functional tests to run inside the container Github-Pull: #30193 Rebased-From: 4b527fa93b9763a33842069bc07446313cbf5e0f
Moving it from Cirrus CI so it can be easier to maintain and used by forks Github-Pull: #30193 Rebased-From: 9eea51d9058ad638861aa4b94c1c6e71caeb8765
Github-Pull: #30299 Rebased-From: 518b06c4b889d71a3fdd61f8fe38d519ea5e4a1b
See: miniupnp/miniupnp@c0a50ce The return value of 2 now indicates: "A valid connected IGD has been found but its IP address is reserved (non routable)" We continue to ignore any return value other than 1. Github-Pull: #30283 Rebased-From: 8acdf66540834b9f9cf28f16d389e8b6a48516d5
b3093eb doc: Update rel notes for 27.x (fanquake) 6338f92 upnp: add compatibility for miniupnpc 2.2.8 (Cory Fields) f34e446 ci: remove unused bcc variable from workflow (Max Edwards) 0d524b1 ci: move Asan / LSan / USDT job to Github Actions (Max Edwards) 43c40dd ci: add IPV6 network to ci container (Max Edwards) Pull request description: Backports: * bitcoin/bitcoin#30193 * bitcoin/bitcoin#30283 * bitcoin/bitcoin#30299 ACKs for top commit: willcl-ark: ACK b3093eb stickies-v: ACK b3093eb Tree-SHA512: 325149f2b388072276e10fae2ebb7d8f3f5138d75f237c0182a09c631334fc2af9c2fe500db31bf41e94d4f154771e3cd386f8eb0d09d7a1ad656f637b71e735
A common issue that our fuzzers keep finding is that outpoints don't exist in the non witness utxos. Instead of trying to track this down and checking in various individual places, do the check early during deserialization. Github-Pull: #29855 Rebased-From: 9e13ccc50eec9d2efe0f472e6d50dc822df70d84
Initiating an outbound network connection currently involves the
following steps after the socket connection is established (see
`CConnman::OpenNetworkConnection` method):
1. set up node state
2. queue VERSION message
3. add new node to vector `m_nodes`
If we connect to ourself, it can happen that the sent VERSION message
(step 2) is received and processed locally *before* the node object
is added to the connection manager's `m_nodes` vector (step 3). In this
case, the self-connect remains undiscovered, as the detection doesn't
find the outbound peer in `m_nodes` yet (see `CConnman::CheckIncomingNonce`).
Fix this by swapping the order of 2. and 3., by taking the `PushNodeVersion`
call out of `InitializeNode` and doing that in the `SendMessages` method
instead, which is only called for `CNode` instances in `m_nodes`.
Thanks go to vasild, mzumsande, dergoegge and sipa for suggestions on
how to fix this.
Github-Pull: #30394
Rebased-From: 66673f1c1302c986e344c7f44bb0b352213d5dc8
Now that the queueing of the VERSION messages has been moved out of
`InitializeNode`, there is no need to pass a mutable `CNode` reference any
more. With a const reference, trying to send messages in this method would
lead to a compile-time error, e.g.:
----------------------------------------------------------------------------------------------------------------------------------
...
net_processing.cpp: In member function ‘virtual void {anonymous}::PeerManagerImpl::InitializeNode(const CNode&, ServiceFlags)’:
net_processing.cpp:1683:21: error: binding reference of type ‘CNode&’ to ‘const CNode’ discards qualifiers
1683 | PushNodeVersion(node, *peer);
...
----------------------------------------------------------------------------------------------------------------------------------
Github-Pull: #30394
Rebased-From: 0dbcd4c14855fe2cba15a32245572b693dc18c4e
…ect" This reverts commit 9ec2c53701a391629b55aeb2804e8060d2c453a4 with a tiny change included (identation of the wait_until call). Github-Pull: #30394 Rebased-From: 16bd283b3ad05daa41259a062aee0fc05b463fa6
This avoids situations during a reindex in which shutdown doesn't finish since SyncWithValidationInterfaceQueue is called by the load block thread when the scheduler is already stopped. Github-Pull: #30435 Rebased-From: 5fd48360198d2ac49e43b24cc1469557b03567b8
Fix cases of calls to `FillPSBT` returning `complete=true` when it's not the case. This can happen when some inputs have been signed but the transaction is subsequently modified, e.g. in the context of PayJoins. Also fixes a related bug where a finalized hex string is attempted to be added during `walletprocesspsbt` but a CHECK_NONFATAL causes an abort. Reported in #30077. Github-Pull: #30357 Rebased-From: 39cea21ec51b9838669c38fefa14f25c36ae7096
This test checks that we can successfully process PSBTs and opt out of finalization. Previously trying to call `walletprocesspsbt` would attempt to auto-finalize (as a convenience), and would not permit opt-out of finalization, instead aborting via `CHECK_NONFATAL`. Github-Pull: #30357 Rebased-From: 7e36dca657c66bc70b04d5b850e5a335aecfb902
4f23c86 [WIP] doc: update release notes for 27.x (fanquake) 54bb9b0 test: add test for modififed walletprocesspsbt calls (willcl-ark) f22b9ca wallet: fix FillPSBT errantly showing as complete (willcl-ark) 05192ba init: change shutdown order of load block thread and scheduler (Martin Zumsande) ab42206 Reapply "test: p2p: check that connecting to ourself leads to disconnect" (Sebastian Falbesoner) 064f214 net: prevent sending messages in `NetEventsInterface::InitializeNode` (Sebastian Falbesoner) 0933cf5 net: fix race condition in self-connect detection (Sebastian Falbesoner) fa90989 psbt: Check non witness utxo outpoint early (Ava Chow) Pull request description: Backports: * bitcoin/bitcoin#29855 * bitcoin/bitcoin#30357 * bitcoin/bitcoin#30394 (modified test commit) * bitcoin/bitcoin#30435 ACKs for top commit: stickies-v: ACK 4f23c86 willcl-ark: ACK 4f23c86 Tree-SHA512: 5c26445f0855f9d14890369ce19873b0686804eeb659e7d6da36a6f404f64d019436e1e6471579eaa60a96ebf8f64311883b4aef9d0ed528a95bd610c101c079
|
Some additional notes:
Where BDB_PREFIX is the location of your Bearkley DB 4.8.
|
|
Nice work! We have always planned to synchronize with Bitcoin Core. I compiled your code (with default gcc on Ubuntu 22) and now I am checking whether it will sync. I suspect it will fail due to the lyra hash problems, but I have a fix for that in my 0.9.7.5 fork (https://github.com/bitmarkcc/bitmark). This will probably need a lot of testing and I am definitely willing to help with that. |
|
To validate the integrity of this commit, I made my own "27.x" branch off of my master branch (https://github.com/bitmarkcc/bitmark/tree/27.x) where I first remove all files (git rm -r '*'), and then I merge bitcoin/27.x using the command |
|
Thanks, @bitmarkcc,
Yeah, makes sense. We definitely need at least one release before version 27, since #133 is needed for version 27 to sync up with bitmark network. |
|
The Lyra hash fails with the BMW hash (one of the hashes used). I have 2 solutions for this. 1 is a one line hack, and I'm not sure why it works, and 2 is to use a different implementation for the BMW hash. I like the second solution more, though I brought this up with another coin repo (VERGE I think) and they accepted my hack into their code. Here is the issue I made explaining this: #131 Also, your code synced fine 2 nights ago with Ubuntu 22, because it had gcc 10.5 on it... |
|
I have also a "27.xb" branch that starts with the Bitcoin code and adds small incremental changes while preserving the success of the unit tests. Some of the tests have to be modified of course for the BTM parameters. See https://github.com/bitmarkcc/bitmark/tree/27.xb. So far I am able to sync with a 0.9.7.5 node up to the pre-fork blocks (around block 450000). I am keeping Bitcoin's address prefixes for now since there many hardcoded addresses/keys in the unit tests. Also, I'm trying to decide on the RPC and Tor (new) ports. I think 9264 is ok for the Tor port and keep 9266 as the rpc. |
Looks good. 👍 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 PR upgrades Bitmark to Bitcoin code from 27.x branch. Bitmark git fork history is now in sync with Bitcoin repo, so future upstream merge with bitcoin should be far easier.
With this PR Bitmark gets a lot of important bug fixes and bitcoin improvements, including Segwit which enables the creation of the lightning network. Hopefully one day LN can be a bridge to trade coins between different chains.
What is left to be done:
git mv. This way git history is maintained in most cases.Known issues:
connect=nodeip:nodeportin bitmark.conf.👍 Let's revive the development of this legendary OG coin. 👍