Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

backport: Merge bitcoin#21750, 21727, 21856, 21897 #5997

Draft
wants to merge 3 commits into
base: develop
Choose a base branch
from

Conversation

vijaydasmp
Copy link

bitcoin backports

@vijaydasmp vijaydasmp changed the title Bp22 36 backport : Merge Apr 25, 2024
@vijaydasmp vijaydasmp changed the title backport : Merge backport : Merge bitcoin#21750, 21727, 21856, 21897 Apr 25, 2024
@vijaydasmp vijaydasmp changed the title backport : Merge bitcoin#21750, 21727, 21856, 21897 backport: Merge bitcoin#21750, 21727, 21856, 21897 Apr 25, 2024
@vijaydasmp vijaydasmp closed this Apr 25, 2024
@vijaydasmp vijaydasmp reopened this Apr 25, 2024
@vijaydasmp vijaydasmp force-pushed the bp22_36 branch 3 times, most recently from ce6ecaf to 191f9d0 Compare May 4, 2024 11:10
MarcoFalke added 3 commits May 5, 2024 06:59
9096b13 net: remove unnecessary check of CNode::cs_vSend (Vasil Dimov)

Pull request description:

  It is not possible to have a node in `CConnman::vNodesDisconnected` and
  its reference count to be incremented - all `CNode::AddRef()` are done
  either before the node is added to `CConnman::vNodes` or while holding
  `CConnman::cs_vNodes` and the object being in `CConnman::vNodes`.

  So, the object being in `CConnman::vNodesDisconnected` and its reference
  count being zero means that it is not and will not start to be used by
  other threads.

  So, the lock of `CNode::cs_vSend` in `CConnman::DisconnectNodes()` will
  always succeed and is not necessary.

  Indeed all locks of `CNode::cs_vSend` are done either when the reference
  count is >0 or under the protection of `CConnman::cs_vNodes` and the
  node being in `CConnman::vNodes`.

ACKs for top commit:
  MarcoFalke:
    review ACK 9096b13 🏧
  jnewbery:
    utACK 9096b13

Tree-SHA512: 910899cdcdc8934642eb0c40fcece8c3b01b7e20a0b023966b9d6972db6a885cb3a9a04e9562bae14d5833967e45e2ecb3687b94d495060c3da4b1f2afb0ac8f
47c3ea0 doc: add OSS-Fuzz section to fuzzing.md doc (Adam Jonas)

Pull request description:

  This adds documentation about [Bitcoin Core's participation](https://github.com/google/oss-fuzz/pull/5699/files) in Google's OSS-Fuzz program and adds the caveat that the project may not disclose vulnerabilities within the 90-day window described in the [program's disclosure guidelines](https://google.github.io/oss-fuzz/getting-started/bug-disclosure-guidelines/).

ACKs for top commit:
  jonatack:
    ACK 47c3ea0

Tree-SHA512: 87bf0146fb74d1e4b3b8839e6c8f3d53046008a6d5b926ffe5b95be3c396a5e47e47967533422f60b04c4446482f49d210ada410b742f69781a7afde623d704d
7031721 rpc/listaddressgroupings: redefine inner-most array as ARR_FIXED (Karl-Johan Alm)
8500f7b rpc/createrawtransaction: redefine addresses as OBJ_USER_KEYS (Karl-Johan Alm)
d9e2183 rpc: include OBJ_USER_KEY in RPCArg constructor checks (Karl-Johan Alm)

Pull request description:

  This PR adjusts the two issues I encountered while developing a tool that converts RPCHelpMan objects into bindings for other language(s).

  The first is in createrawtransaction, where the address part, e.g. bc1qabc in

  > createrawtransaction '[]' '[{"bc1qabc": 1.0}]'

  is declared as a `Type::OBJ`, when in reality it should be a `Type::OBJ_USER_KEYS`, defined as such:

  https://github.com/bitcoin/bitcoin/blob/5925f1e652768a9502831b9ccf78d16cf3c37d29/src/rpc/util.h#L126

  (coincidentally, this is the first and only (afaict) usage of this `RPCArg::Type`).

  The second is in the `listaddressgroupings` RPC, which returns an array of arrays of arrays, where the innermost one is a tuple-thingie with an optional 3rd item; this is an `ARR_FIXED`, not an `ARR`.

ACKs for top commit:
  MarcoFalke:
    ACK 7031721 🐀

Tree-SHA512: 769377416c6226d1738a956fb685498e009f9e7eb2d45bc679b81c5364b9520fdbcb49392c937ab45598aa0d33589e8e6a59ccc101cf8d8e7dfdafd58d4eefd0
Copy link

This pull request has conflicts, please rebase.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant