Age | Commit message (Collapse) | Author |
|
This commit makes compat.h no longer a required include for users of the
libbitcoinkernel. Including compat.h imports a bunch of
platform-specific definitions.
This commit is part of the libbitcoinkernel project, namely its stage 1
step 3: Decouple most non-consensus headers from libbitcoinkernel.
|
|
Move functions requiring the netaddress.h include out of
libbitcoinkernel source files.
The netaddress.h file contains many non-consensus related definitions
and should thus not be part of the libbitcoinkernel. This commit makes
netaddress.h no longer a required include for users of the
libbitcoinkernel.
This commit is part of the libbitcoinkernel project, namely its stage 1
step 3: Decouple most non-consensus headers from libbitcoinkernel.
|
|
This is done in preparation to the next commit, but has the nice
effect of removing one further data structure relying on the global
`Params()`.
|
|
|
|
The protocol.h file contains many non-consensus related definitions and
should thus not be part of the libbitcoinkernel. This commit makes
protocol.h no longer a required include for users of the
libbitcoinkernel.
This commit is part of the libbitcoinkernel project, namely its stage 1
step 3: Decouple most non-consensus headers from libbitcoinkernel.
Co-Authored-By: Cory Fields <cory-nospam-@coryfields.com>
|
|
|
|
This is already possible for C-style arrays, so allow it for C++11
std::array as well.
|
|
specify that a default port is used
9a84200cfc994eebf38c46919b20e0c0261799ae doc, refactor: Changing -torcontrol help to specify that a default port is used (kevkevin)
Pull request description:
Right now when we get the help for -torcontrol it says that there is a default ip and port we dont specify if there is a specified ip that we would also use port 9051 as default
Also I create a new const instead of using 9051 directly in the function
linking this PR because this was discussed here https://github.com/bitcoin/bitcoin/pull/28018
ACKs for top commit:
jonatack:
re-ACK 9a84200cfc994eebf38c46919b20e0c0261799ae
achow101:
ACK 9a84200cfc994eebf38c46919b20e0c0261799ae
MarnixCroes:
utACK 9a84200cfc994eebf38c46919b20e0c0261799ae
kristapsk:
utACK 9a84200cfc994eebf38c46919b20e0c0261799ae
Tree-SHA512: 21d9e65f3c280a2853a9cf60d4e93e8d72caccea106206d1862c19535bde7ea6ada7f55e6ea19a1fc0f59dbe791ec6fc4084fdbe7fa6d6991fa89c62070db637
|
|
walletprocesspsbt if complete
2e249b922762f19d6ae61edaad062f31bc2849f3 doc: add release note for PR #28414 (Matthew Zipkin)
4614332fc4514f63fcbe9e6de507f7bb9b7e87e9 test: remove unnecessary finalizepsbt rpc calls (ismaelsadeeq)
e3d484b603abff69c6ebfca5cfb78cf82743d090 wallet rpc: return final tx hex from walletprocesspsbt if complete (Matthew Zipkin)
Pull request description:
See https://github.com/bitcoin/bitcoin/pull/28363#discussion_r1315753887
`walletprocesspsbt` currently returns a base64-encoded PSBT and a boolean indicating if the tx is "complete". If it is complete, the base64 PSBT can be finalized with `finalizepsbt` which returns the hex-encoded transaction suitable for `sendrawtransaction`.
With this patch, `walletprocesspsbt` return object will ALSO include the broadcast-able hex string if the tx is already final. This saves users the extra step of calling `finalizepsbt` assuming they have already inspected and approve the transaction from earlier steps.
ACKs for top commit:
ismaelsadeeq:
re ACK 2e249b922762f19d6ae61edaad062f31bc2849f3
BrandonOdiwuor:
re ACK 2e249b9
Randy808:
Tested ACK 2e249b922762f19d6ae61edaad062f31bc2849f3
achow101:
ACK 2e249b922762f19d6ae61edaad062f31bc2849f3
ishaanam:
ACK 2e249b922762f19d6ae61edaad062f31bc2849f3
Tree-SHA512: 229c1103265a9b4248f080935a7ad5607c3be3f9a096a9ab6554093b2cd8aa8b4d1fa55b1b97d3925ba208dbc3ccba4e4d37c40e1491db0d27ba3d9fe98f931e
|
|
on all versions of GCC
fabb419a3caafc00fbbc533fee14fab7a5d2a2c6 doc: Clarify that -fstack-reuse=all bugs exist on all versions of GCC (MarcoFalke)
Pull request description:
This is a follow-up to commit 7b850bc2a1cd8547a2dbb5a18173f53439601220. While the test case no longer reproduces, the general class of `-fstack-reuse` bugs still exists in all versions of GCC. The workaround can never be removed, unless the whole class of bugs is fixed.
ACKs for top commit:
fanquake:
ACK fabb419a3caafc00fbbc533fee14fab7a5d2a2c6
Tree-SHA512: 566e14fe82d13dda4f7b8cca90c6de75006d14828906b936780716d5b5b31de9b36a904aa7cfc9820ccdfb4d3224a8437f502f25f7230da5abe87c927123f0c8
|
|
971bae9174293b79f1f29822d662b31a2ba62234 rpc: Deprecate rpcserialversion=0 (Anthony Towns)
Pull request description:
This option was introduced in #9194 to ease the transition to segwit; now that most libraries and apps have been updated it should no longer be necessary.
ACKs for top commit:
MarcoFalke:
review ACK 971bae9174293b79f1f29822d662b31a2ba62234
Randy808:
Code Review ACK 971bae9174293b79f1f29822d662b31a2ba62234
glozow:
ACK 971bae9174293b79f1f29822d662b31a2ba62234, seems appropriate to remove. Thanks for looking at usage in https://github.com/bitcoin/bitcoin/pull/28448#issuecomment-1714699556
Tree-SHA512: 6880314504281e9d7c288bd159f8cadefb3e653ac2dd148396810f7f5a27ba352ecfe720eb2dbc6172b57820cb9a2a254dcb2585881abae43811013505f0e09a
|
|
|
|
be reversed
c0bf667912064960df194ea94150976b34f7c267 index: add [nodiscard] attribute to functions writing to the db (furszy)
eef595560e9ecf3a0d1db4d8ea7ecc33a49d839f index: coinstats reorg, fail when block cannot be reversed (furszy)
Pull request description:
Found it while reviewing https://github.com/bitcoin/bitcoin/pull/24230#discussion_r1310863359.
During a reorg, continuing execution when a block cannot be reversed leaves the
coinstats index in an inconsistent state.
This was surely overlooked when 'CustomRewind' was implemented.
ACKs for top commit:
ryanofsky:
Code review ACK c0bf667912064960df194ea94150976b34f7c267. Only change since last review is new commit adding [[nodiscard]]
Tree-SHA512: f4fc8522508d23e4fff09a29c935971819b1bd3b2a260e08e2e2b72f9340980d74fbec742a58fe216baf61d27de057c7c8300e8fa075f8507cd1227f128af909
|
|
64704386b28ce3a1ab607a946ec729286da8faa6 doc: fix typos and mistakes in BIP324 code comments (Pieter Wuille)
9bde93df2c84b6d5f333aa56cbd0b28b6ad337b0 net: do not use send buffer to store/cache garbage (Pieter Wuille)
b6934fd03f080d437acb1fd2b665503c3d6de785 net: merge V2Transport constructors, move key gen (Pieter Wuille)
Pull request description:
This addresses a few remaining comments on #28196:
* Deduplicate the `V2Transport` constructors (https://github.com/bitcoin/bitcoin/pull/28196#discussion_r1318573111)
* Do not use the send buffer to store garbage (https://github.com/bitcoin/bitcoin/pull/28196#discussion_r1319134141)
* Fix typo (https://github.com/bitcoin/bitcoin/pull/28196#discussion_r1315179378)
In addition, also fix an incorrect description in `V2Transport::SendState` (it claimed garbage was sent in the `READY` state, but it's in the `AWAITING_KEY` state).
ACKs for top commit:
naumenkogs:
ACK 64704386b28ce3a1ab607a946ec729286da8faa6
theStack:
Code-review ACK 64704386b28ce3a1ab607a946ec729286da8faa6
Tree-SHA512: 4bf6d2fe73c8054502d0b60e9de1722f8b3dd269c2dd6bf67197c3fb6eabcf047b6360cdab3c1fd5504215c2ac4ac2890a022780efc30ff583776242c8112451
|
|
|
|
|
|
Before this commit the V2Transport::m_send_buffer is used to store the
garbage:
* During MAYBE_V1 state, it's there despite not being sent.
* During AWAITING_KEY state, while it is being sent.
* At the end of the AWAITING_KEY state it cannot be wiped as it's still
needed to compute the garbage authentication packet.
Change this by introducing a separate m_send_garbage field, taking over
the first and last role listed above. This means the garbage is only in
the send buffer when it's actually being sent, removing a few special
cases related to this.
|
|
This removes the ability for BIP324Cipher to generate its own key, moving that
responsibility to the caller (mostly, V2Transport). This allows us to write
the random-key V2Transport constructor by delegating to the explicit-key one.
|
|
(27831 follow-ups)
9f55773a370a0d039e727445ccee6b84e05f562a test: refactor: usdt_mempool: store all events (stickies-v)
bc432704505eb165dd86de39ea3434c6fb7a2514 test: refactor: remove unnecessary nonlocal (stickies-v)
326db63a6819813db55ba0d01ab4fe80f7a0d818 test: log sanity check assertion failures (stickies-v)
f5525ad6808df6afc38e5c6e4767ab577e30629c test: store utxocache events (stickies-v)
f1b99ac94fb77340c4d3a5b4bbc3df28009bc773 test: refactor: deduplicate handle_utxocache_* logic (stickies-v)
ad90ba36bd930f00753643cd1fe0af72d1c828c2 test: refactor: rename inbound to is_inbound (stickies-v)
afc0224cdbe73e326addf5fb98a3e95d941f2104 test: refactor: remove unnecessary blocks_checked counter (stickies-v)
Pull request description:
Various cleanups to the USDT functional tests, largely (but not exclusively) follow-ups to https://github.com/bitcoin/bitcoin/pull/27831#pullrequestreview-1491438045. Except for slightly different logging behaviour in "test: store utxocache events" and "test: log sanity check assertion failures", this is a refactor PR, removing unnecessary code and (imo) making it more readable and maintainable.
The rationale for each change is in the corresponding commit message.
Note: except for "test: store utxocache events" (which relies on its parent, and I separated into two commits because we may want the parent but not the child), all commits are stand-alone and I'm okay with dropping one/multiple commits if they turn out to be controversial or undesired.
ACKs for top commit:
0xB10C:
ACK 9f55773a370a0d039e727445ccee6b84e05f562a. Reviewed the code and ran the USDT interface tests. I stepped through the commits and think all changes are reasonable.
Tree-SHA512: 6c37a0265b6c26d4f9552a056a690b8f86f7304bd33b4419febd8b17369cf6af799cb87c16df35d0c2a1b839ad31de24661d4384eafa88816c2051c522fd3bf5
|
|
8d6228fc1fe72db3ac38ab9c853be0256bed5f24 consensus/validation.h: remove needless GetTransactionOutputWeight helper (Antoine Poinsot)
Pull request description:
Introduced in #26567. My bad. Thanks AJ for noticing.
ACKs for top commit:
ajtowns:
utACK 8d6228fc1fe72db3ac38ab9c853be0256bed5f24
Tree-SHA512: cf13647b4aac82fb6a54ae0338e3928e9bdf226ed4f5e91d529996328471744132db2bee9676e0b3f40a8bbe0e0ca51a9e5f91560a84e0f33597290551a1ee18
|
|
CBlockLocator and CDiskBlockIndex
e73d2a8018def940afadb5d699b18f39e882c1fc refactor: remove clientversion include from dbwrapper.h (Cory Fields)
4240a082b81d8ceb7615b1b4ca0d2857382f317b refactor: Use DataStream now that version/type are unused (Cory Fields)
f15f790618d328abd207d55e6291229eb2a8643f Remove version/hashing options from CBlockLocator/CDiskBlockIndex (Cory Fields)
Pull request description:
This is also a much simpler replacement for #28327.
There are version fields in `CBlockLocator` and `CDiskBlockIndex` that have always been written but discarded when read.
I intended to convert them to use SerParams as introduced by #25284, which [ended up looking like this](https://github.com/theuni/bitcoin/commit/3e3af451652322c92e8e41cf918e69d608ec7c77). However because we don't currently have any definition of what a hash value would mean for either one of those, and we've never assigned the version field any meaning, I think it's better to just not worry about them.
If we ever need to assign meaning in the future, we can introduce `SerParams` as was done for `CAddress`.
As for the dummy values chosen:
`CDiskBlockIndex::DUMMY_VERSION` was easy as the highest ever client version, and I don't expect any objection there.
`CBlockLocator::DUMMY_VERSION` is hard-coded to the higest _PROTOCOL_ version ever used. This is to avoid a sudden bump that would be visible on the network if CLIENT_VERSION were used instead. In the future, if we ever need to use the value, we can discard anything in the CLIENT_VERSION range (for a few years as needed), as it's quite a bit higher.
While reviewing, I suggest looking at the throwaway `SerParams` commit above as it shows where the call-sites are. I believe that should be enough to convince one's self that hashing is never used.
ACKs for top commit:
TheCharlatan:
Re-ACK e73d2a8018def940afadb5d699b18f39e882c1fc
ajtowns:
reACK e73d2a8018def940afadb5d699b18f39e882c1fc
Tree-SHA512: 45b0dd7c2e918493e2ee92a8e35320ad17991cb8908cb811150a96c5fd584ce177c775baeeb8675a602c90b9ba9203b8cefc0a2a0c6a71078b1d9c2b41e1f3ba
|
|
|
|
|
|
|
|
|
|
db9888feec48c6220a2fcf92865503bbbdab02a4 net: detect wrong-network V1 talking to V2Transport (Pieter Wuille)
91e1ef8684997fb4b3e8b64ef3935a936445066b test: add unit tests for V2Transport (Pieter Wuille)
297c8889975a18258d6cc39b1ec1e94fed6630fb net: make V2Transport preallocate receive buffer space (Pieter Wuille)
3ffa5fb49ee4a6d9502aa957093bd94058630282 net: make V2Transport send uniformly random number garbage bytes (Pieter Wuille)
0be752d9f8ca27320bc3e82498c7640fabd7e8de net: add short message encoding/decoding support to V2Transport (Pieter Wuille)
8da8642062fa2c7aa2f49995b832c3d0897e37ed net: make V2Transport auto-detect incoming V1 and fall back to it (Pieter Wuille)
13a7f01557272db652b3f333af3f06af6897253f net: add V2Transport class with subset of BIP324 functionality (Pieter Wuille)
dc2d7eb810ef95b06620f334c198687579916435 crypto: Spanify EllSwiftPubKey constructor (Pieter Wuille)
5f4b2c6d79e81ee0445752ad558fcc17831f4b2f net: remove unused Transport::SetReceiveVersion (Pieter Wuille)
c3fad1f29df093e8fd03d70eb43f25ee9d531bf7 net: add have_next_message argument to Transport::GetBytesToSend() (Pieter Wuille)
Pull request description:
This is part of #27634.
This implements the BIP324 v2 transport (which implements all of what the BIP calls transport layer *and* application layer), though in a non-exposed way. It is tested through an extensive fuzz test, which verifies that v2 transports can talk to v2 transports, and v1 transports can talk to v2 transports, and a unit test that exercises a number of unusual scenarios. The transport is functionally complete, including:
* Autodetection of incoming V1 connections.
* Garbage, both sending and receiving.
* Short message type IDs, both sending and receiving.
* Ignore packets (receiving only, but tested in a unit test).
* Session IDs are visible in `getpeerinfo` output (for manual comparison).
Things that are not included, left for future PRs, are:
* Actually using the v2 transport for connections.
* Support for the `NODE_P2P_V2` service flag.
* Retrying downgrade to V1 when attempted outbound V2 connections immediately fail.
* P2P functional and unit tests
ACKs for top commit:
naumenkogs:
ACK db9888feec48c6220a2fcf92865503bbbdab02a4
theStack:
re-ACK db9888feec48c6220a2fcf92865503bbbdab02a4
mzumsande:
Code Review ACK db9888feec48c6220a2fcf92865503bbbdab02a4
Tree-SHA512: 8906ac1e733a99e1f31c9111055611f706d80bbfc2edf6a07fa6e47b21bb65baacd1ff17993cbbf588063b2f5ad30b3af674a50c7bc8e8ebf4671483a21bbfeb
|
|
Introduced in 9b7ec393b82ca9d7ada77d06e0835df0386a8b85. This copied the format of the other Get.*Weight helpers but it's useless for a CTxOut.
|
|
1580e3be83bd03985b2f288ed70de510903068d9 fuzz: add ConstructPubKeyBytes function (josibake)
Pull request description:
In https://github.com/bitcoin/bitcoin/pull/28246 and https://github.com/bitcoin/bitcoin/pull/28122 , we add a `PubKeyDestination` and a `V0SilentPaymentsDestination`. Both of these PRs update `fuzz/util.cpp` and need a way to create well-formed pubkeys. Currently in `fuzz/util.cpp`, we have some logic for creating pubkeys in the multisig data provider. This logic is duplicated in #28246 and duplicated again in #28122. Seems much better to have a `ConstructPubKeyBytes` function that both PRs (and any future work) can reuse.
This PR introduces a function to do this and has the existing code use it. While the purpose is to introduce a utility function, the previous multisig code used `ConsumeIntegralInRange(4, 7)` which would have created some uncompressed pubkeys with the prefix 0x05, which is incorrect (see https://bitcoin.stackexchange.com/questions/57855/c-secp256k1-what-do-prefixes-0x06-and-0x07-in-an-uncompressed-public-key-signif)
tldr; using `PickValueFromArray` is more correct as it limits to the set of defined prefixes for compressed and uncompressed pubkeys.
ACKs for top commit:
Sjors:
ACK 1580e3be83bd03985b2f288ed70de510903068d9
Tree-SHA512: c87c8bcd1f6b3a97ef772be93102efb912811c59f32211cfd531a116f1da8a57c8c6ff106b34f2a2b88d8b34fb5bc30d9f9ed6d2720113ffcaaa2f8d5dc9eb27
|
|
During a reorg, continuing execution when a block cannot be
reversed leaves the coinstats index in an inconsistent state,
which was surely overlooked when 'CustomRewind' was implemented.
|
|
`p2p_invalid_block`
3eb03803c4111d09c63550a6a6c09afbe3430bf6 test: remove unused variables in `p2p_invalid_block` (brunoerg)
Pull request description:
ACKs for top commit:
stickies-v:
ACK 3eb03803c4111d09c63550a6a6c09afbe3430bf6
Tree-SHA512: eadae1eb323e5562d1ea0aed43ebf0145f0fdbb6cd6d4646bbf1ca89f384820e7b9cb69f0bb04a949e9f8983a879aee8387d6f7ac3d4e4ea027f8892e656fb98
|
|
7d5815293ed8a3dea68b61a78944e410f02b147f depends: cctools 986 & ld64 711 (fanquake)
1ed1183f47794d1a2d8deced58226b2a4e84eaf0 depends: libtapi 1300.0.6.5 (fanquake)
Pull request description:
Update [libtapi to `1300.0.6.5`](https://github.com/tpoechtrager/apple-libtapi/tree/1300.6.5), [cctools to `986` & ld64 to `711`](https://github.com/tpoechtrager/cctools-port/commits/986-ld64-711).
Updating these dependencies fixes the macOS build failures in #27897, when using a native GCC 12 toolchain, which means after this change, we can use use GCC 12 for all HOSTS, rather than splitting between 12 & 10 (for macOS).
Guix Build (x86_64):
```bash
a684a3e7668250610d653e5160115fb50b477339423335b185bd4716c8420e14 guix-build-7d5815293ed8/output/aarch64-linux-gnu/SHA256SUMS.part
9c66b82e2c5b6dbdcabdd962481485f71af5770e8bb573eaefb55d45e85e2875 guix-build-7d5815293ed8/output/aarch64-linux-gnu/bitcoin-7d5815293ed8-aarch64-linux-gnu-debug.tar.gz
63f82714a93e7a3c0e922cdcce7d3b27789d63cdf136dc3a71b74d61b0910ce8 guix-build-7d5815293ed8/output/aarch64-linux-gnu/bitcoin-7d5815293ed8-aarch64-linux-gnu.tar.gz
dcc79295462e0f585753959247ec02b273f5a933fadc5d528c266d56bbdaaf44 guix-build-7d5815293ed8/output/arm-linux-gnueabihf/SHA256SUMS.part
044fc0ad2a8615dd004579b5003fa981ebc4e3bfaacf5eba8a33cea02a9ba518 guix-build-7d5815293ed8/output/arm-linux-gnueabihf/bitcoin-7d5815293ed8-arm-linux-gnueabihf-debug.tar.gz
a032899be14fa2987dfd5a21865567d3beea703e778a2f91ec17eddb099d0c46 guix-build-7d5815293ed8/output/arm-linux-gnueabihf/bitcoin-7d5815293ed8-arm-linux-gnueabihf.tar.gz
27d43a97ea6c4ed2e84d9a9dd6c240e8e199174f4491ee1fb62abb1d950a96bd guix-build-7d5815293ed8/output/arm64-apple-darwin/SHA256SUMS.part
029347186cc55c15152e8c255493ed457e58127ffa536982f3a632fc416b6662 guix-build-7d5815293ed8/output/arm64-apple-darwin/bitcoin-7d5815293ed8-arm64-apple-darwin-unsigned.dmg
791399447c33f7d3ed4d77fd22fde69aa7c87adda9291fca9508237b69b05b80 guix-build-7d5815293ed8/output/arm64-apple-darwin/bitcoin-7d5815293ed8-arm64-apple-darwin-unsigned.tar.gz
b9c72b7f37068889a83384598b6de97c8e39e7a097b661152084a5e69236541d guix-build-7d5815293ed8/output/arm64-apple-darwin/bitcoin-7d5815293ed8-arm64-apple-darwin.tar.gz
6a249cc6d02d7398b9ed70b251422bf4bb1c2acdaafb5a885870e8ef20d43a89 guix-build-7d5815293ed8/output/dist-archive/bitcoin-7d5815293ed8.tar.gz
064e5e0df21aa177eaf8d67254ad5166b190559f69da68d34174a323d8c975c6 guix-build-7d5815293ed8/output/powerpc64-linux-gnu/SHA256SUMS.part
6aee00585bdd680d42f3341df523b7173dc06defa8f51f98af38c8518ddf4532 guix-build-7d5815293ed8/output/powerpc64-linux-gnu/bitcoin-7d5815293ed8-powerpc64-linux-gnu-debug.tar.gz
d6e51b521c84276d5c9606a96ee36b94bc235370064cf75148d15d3a4011ed9d guix-build-7d5815293ed8/output/powerpc64-linux-gnu/bitcoin-7d5815293ed8-powerpc64-linux-gnu.tar.gz
e0a133afe0e0e7894d3c6110b7b1895efff8f45abbe473d95100d3c5615dc855 guix-build-7d5815293ed8/output/powerpc64le-linux-gnu/SHA256SUMS.part
8d62884b81fca76720284ae4d5b2a0d0ebfcbcf533d9936c8aa8ab04739540e9 guix-build-7d5815293ed8/output/powerpc64le-linux-gnu/bitcoin-7d5815293ed8-powerpc64le-linux-gnu-debug.tar.gz
c4c90dd3c83a84aa074ab5dc77b82fd2a26d872547037ef2a8a2d11abba1db98 guix-build-7d5815293ed8/output/powerpc64le-linux-gnu/bitcoin-7d5815293ed8-powerpc64le-linux-gnu.tar.gz
dd28d196e89f74cf7666b347e1cbdd16eb90bfe0d5b054ac2edbf0e4f755bd9a guix-build-7d5815293ed8/output/riscv64-linux-gnu/SHA256SUMS.part
8d3ace8a17d4c1a13786adb3669b1d929485b164c59efb1fe7cf8fe3aad90f73 guix-build-7d5815293ed8/output/riscv64-linux-gnu/bitcoin-7d5815293ed8-riscv64-linux-gnu-debug.tar.gz
bf530b7944dfdd9ffd03b2be541fa349e8598cb39ee5e1bd4be0b5b48bdfcc31 guix-build-7d5815293ed8/output/riscv64-linux-gnu/bitcoin-7d5815293ed8-riscv64-linux-gnu.tar.gz
6172224f94d52eb22a3749b1e3c0639476dfdaff47d15c6a8ec3e6dbf8763f9b guix-build-7d5815293ed8/output/x86_64-apple-darwin/SHA256SUMS.part
f59f68ad4783ff1ecb09cd84f15bbfc803c856971de5a131fbb1777cf8f1b79a guix-build-7d5815293ed8/output/x86_64-apple-darwin/bitcoin-7d5815293ed8-x86_64-apple-darwin-unsigned.dmg
ac31df20d1e5f3a73aadb5455e804af053b179ca6471b5a57afe3c7df0f09128 guix-build-7d5815293ed8/output/x86_64-apple-darwin/bitcoin-7d5815293ed8-x86_64-apple-darwin-unsigned.tar.gz
a33f661386d415f621ab17edf7fe3efa61f0c2b0c3003fecd4f5f6898129992d guix-build-7d5815293ed8/output/x86_64-apple-darwin/bitcoin-7d5815293ed8-x86_64-apple-darwin.tar.gz
03104057b86de994258587ff5a8de16f48354a7493527e5bb2559714c0e2bf39 guix-build-7d5815293ed8/output/x86_64-linux-gnu/SHA256SUMS.part
a9c3f233629038978b9fa11c1353b4e686406851c0e84a5539cf3bc90722d98b guix-build-7d5815293ed8/output/x86_64-linux-gnu/bitcoin-7d5815293ed8-x86_64-linux-gnu-debug.tar.gz
61db7ec4aa306a6f79628b217c05387b69002d123fcf07d6784cce03d9a8574d guix-build-7d5815293ed8/output/x86_64-linux-gnu/bitcoin-7d5815293ed8-x86_64-linux-gnu.tar.gz
7f5b42d02d8c026492376b644a94a45613155a0ccc1d3ef9f067b3370d45c4d2 guix-build-7d5815293ed8/output/x86_64-w64-mingw32/SHA256SUMS.part
de23de0fb32c77f9ff91ffe554347c7ddc77fae22212d0e609389b4b7a1d6e29 guix-build-7d5815293ed8/output/x86_64-w64-mingw32/bitcoin-7d5815293ed8-win64-debug.zip
2131ce905aa3452883a9f47b6618506a6cb90c2a1725818084bc4e08856ff8d3 guix-build-7d5815293ed8/output/x86_64-w64-mingw32/bitcoin-7d5815293ed8-win64-setup-unsigned.exe
5555d28d9ea14a50ab296c2b1f1db7f7acde933009334999b6be29a2ed469bc0 guix-build-7d5815293ed8/output/x86_64-w64-mingw32/bitcoin-7d5815293ed8-win64-unsigned.tar.gz
7dc29c317c140ae8a8f487d2d66761c3fae90a5521dd4bfd0d071adbfafb30ef guix-build-7d5815293ed8/output/x86_64-w64-mingw32/bitcoin-7d5815293ed8-win64.zip
```
ACKs for top commit:
TheCharlatan:
ACK 7d5815293ed8a3dea68b61a78944e410f02b147f
hebasto:
ACK 7d5815293ed8a3dea68b61a78944e410f02b147f
Tree-SHA512: 98873733abb2ebc318129d9fa6627d39f751495776338f539bd58985d08246c1fb85d6bb9b5911f0cd692c26e519713b93d496ffbae513a45942357b82497a91
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This introduces a V2Transport with a basic subset of BIP324 functionality:
* no ability to send garbage (but receiving is supported)
* no ability to send decoy packets (but receiving them is supported)
* no support for short message id encoding (neither encoding or decoding)
* no waiting until 12 non-V1 bytes have been received
* (and thus) no detection of V1 connections on the responder side
(on the sender side, detecting V1 is not supported either, but that needs
to be dealt with at a higher layer, by reconnecting)
|
|
|
|
|
|
Before this commit, there are only two possibly outcomes for the "more" prediction
in Transport::GetBytesToSend():
* true: the transport itself has more to send, so the answer is certainly yes.
* false: the transport has nothing further to send, but if vSendMsg has more message(s)
left, that still will result in more wire bytes after the next
SetMessageToSend().
For the BIP324 v2 transport, there will arguably be a third state:
* definitely not: the transport has nothing further to send, but even if vSendMsg has
more messages left, they can't be sent (right now). This happens
before the handshake is complete.
To implement this, we move the entire decision logic to the Transport, by adding a
boolean to GetBytesToSend(), called have_next_message, which informs the transport
whether more messages are available. The return values are still true and false, but
they mean "definitely yes" and "definitely no", rather than "yes" and "maybe".
|
|
serialization
fa626af3edbe8d98b2de91dd71729ceef90389fb Remove unused legacy CHashVerifier (MarcoFalke)
fafa3fc5a62702da72991497e3270034eb9159c0 test: add tests that exercise WithParams() (MarcoFalke)
fac81affb527132945773a5315bd27fec61ec52f Use serialization parameters for CAddress serialization (MarcoFalke)
faec591d64e40ba7ec7656cbfdda1a05953bde13 Support for serialization parameters (MarcoFalke)
fac42e9d35f6ba046999b2e3a757ab720c51b6bb Rename CSerAction* to Action* (MarcoFalke)
aaaa3fa9477eef9ea72e4a501d130c57b47b470a Replace READWRITEAS macro with AsBase wrapping function (MarcoFalke)
Pull request description:
It seems confusing that picking a wrong value for `ADDRV2_FORMAT` could have effects on consensus. (See the docstring of `ADDRV2_FORMAT`).
Fix this by implementing https://github.com/bitcoin/bitcoin/issues/19477#issuecomment-1147421608 .
This may also help with libbitcoinkernel, see https://github.com/bitcoin/bitcoin/pull/28327
ACKs for top commit:
TheCharlatan:
ACK fa626af3edbe8d98b2de91dd71729ceef90389fb
ajtowns:
ACK fa626af3edbe8d98b2de91dd71729ceef90389fb
Tree-SHA512: 229d379da27308890de212b1fd2b85dac13f3f768413cb56a4b0c2da708f28344d04356ffd75bfcbaa4cabf0b6cc363c4f812a8f1648cff9e436811498278318
|
|
guix/INSTALL
8f541023b9582f8291d00ed4fc14a0db096b0113 doc: s/--no-substitute/--no-substitutes in guix/INSTALL (fanquake)
Pull request description:
https://guix.gnu.org/manual/en/html_node/Common-Build-Options.html
ACKs for top commit:
hebasto:
ACK 8f541023b9582f8291d00ed4fc14a0db096b0113.
TheCharlatan:
ACK 8f541023b9582f8291d00ed4fc14a0db096b0113
Tree-SHA512: 4d79791a8fa772d35723d35e85aaf9ab86304f2a1238e883bbb85051d0cc5f9841dab99ef0fe1e9d67f6259798e98942be00ae7c4320328987234293d9bf3012
|
|
583af18fd1d0bda5a6a1d0403ffc498a512a546d fuzz: introduce and use `ConsumePrivateKey` helper (Sebastian Falbesoner)
Pull request description:
In the course of reviewing BIP324 related PRs I noticed a frequent pattern of creating private keys (`CKey` instances) with data consumed from the fuzz data provider:
```
auto key_data = provider.ConsumeBytes<unsigned char>(32);
key_data.resize(32);
CKey key;
key.Set(key_data.begin(), key_data.end(), /*fCompressedIn=*/true);
```
This PR introduces a corresponding helper `ConsumePrivateKey` in order to deduplicate code. The compressed flag can either be set to a fixed value, or, if `std::nullopt` is passed (=default), is also consumed from the fuzz data provider via `.ConsumeBool()`.
Note that this is not a pure refactor, as some of the replaced call-sites previously consumed a random length (`ConsumeRandomLengthByteVector`) instead of a fixed size of 32 bytes for key data. As far as I can see, there is not much value in using a random size, as in all those cases we can only proceed or do something useful with a valid private key, and key data with sizes other than 32 bytes always lead to invalid keys.
ACKs for top commit:
sipa:
utACK 583af18fd1d0bda5a6a1d0403ffc498a512a546d
brunoerg:
crACK 583af18fd1d0bda5a6a1d0403ffc498a512a546d
Tree-SHA512: 58a178432ba1eb0a2f7597b6700e96477e8b10f429ef642445a52db12e74d81aec307888315b772bfda9610f90df3e1d556cf024c2bef1d520303b12584feaaa
|
|
|
|
using descriptors
10546a569c6c96a5ec1b9708abf9ff5c8644f669 wallet: accurately account for the size of the witness stack (Antoine Poinsot)
9b7ec393b82ca9d7ada77d06e0835df0386a8b85 wallet: use descriptor satisfaction size to estimate inputs size (Antoine Poinsot)
8d870a98731e8db5ecc614bb5f7c064cbf30c7f4 script/signingprovider: introduce a MultiSigningProvider (Antoine Poinsot)
fa7c46b503f0b69630f55dc43021d2099e3515ba descriptor: introduce a method to get the satisfaction size (Antoine Poinsot)
bdba7667d2d65f31484760a8e8420c488fc5f801 miniscript: introduce a helper to get the maximum witness size (Antoine Poinsot)
4ab382c2cdb09fb4056711b4336807845cbe1ad5 miniscript: make GetStackSize independent of P2WSH context (Antoine Poinsot)
Pull request description:
The wallet currently estimates the size of a signed input by doing a dry run of the signing logic. This is unnecessary since all outputs we can sign for can be represented by a descriptor, and we can derive the size of a satisfaction ("signature") directly from the descriptor itself.
In addition, the current approach does not generalize well: dry runs of the signing logic are only possible for the most basic scripts. See for instance the discussion in #24149 around that.
This introduces a method to get the maximum size of a satisfaction from a descriptor, and makes the wallet use that instead of the dry-run.
ACKs for top commit:
sipa:
utACK 10546a569c6c96a5ec1b9708abf9ff5c8644f669
achow101:
re-ACK 10546a569c6c96a5ec1b9708abf9ff5c8644f669
Tree-SHA512: 43ed1529fbd30af709d903c8c5063235e8c6a03b500bc8f144273d6184e23a53edf0fea9ef898ed57d8a40d73208b5d935cc73b94a24fad3ad3c63b3b2027174
|
|
sync_with_ping
fae0b21e6c7a27f08ea8f8b49198c734f923b5da test: Combine sync_send_with_ping and sync_with_ping (MarcoFalke)
Pull request description:
This reduces bloat, complexity, and makes tests less fragile to intermittent failures, see https://github.com/bitcoin/bitcoin/pull/27675#discussion_r1315648343.
This should not cause any noticeable slowdown, or may even be faster, because active polling will be done at most once.
ACKs for top commit:
glozow:
Concept ACK fae0b21e6c7a27f08ea8f8b49198c734f923b5da
theStack:
ACK fae0b21e6c7a27f08ea8f8b49198c734f923b5da 🏓
Tree-SHA512: 6c543241a7b85458dc7ff6a6203316b80a6227d83d38427e74f53f4c666a882647a8a221e5259071ee7bb5dfd63476fb03c9b558a1ea546734b14728c3c619ba
|
|
|
|
|
|
|