Bitcoin Core Github
44 subscribers
121K links
Download Telegram
πŸ“ kevkevinpal opened a pull request: "doc: upgrade Bitcoin Core license to 2024"
(https://github.com/bitcoin/bitcoin/pull/29222)
See https://github.com/bitcoin/bitcoin/pull/26748, [23945](https://github.com/bitcoin/bitcoin/pull/23945), https://github.com/bitcoin/bitcoin/pull/20805, https://github.com/bitcoin/bitcoin/pull/17801, https://github.com/bitcoin/bitcoin/pull/15061

Every year had his upgrade :)

---

cherry-picked these commits from this PR by @22388o and then squashed them to open this PR above is the original desc of the PR
https://github.com/kevkevinpal/bitcoin/pull/new/updateBitcoinLicense2024

85a9
...
πŸ’¬ mzumsande commented on pull request "Fix -netinfo backward compat with getpeerinfo pre-v26":
(https://github.com/bitcoin/bitcoin/pull/29212#discussion_r1448067295)
ok, if it's on purpose it's fine.
πŸ’¬ mzumsande commented on pull request "Fix -netinfo backward compat with getpeerinfo pre-v26":
(https://github.com/bitcoin/bitcoin/pull/29212#issuecomment-1885855351)
Code Review ACK 5fa74609b833643334dfb5519f2023119984267b
πŸ’¬ mzumsande commented on issue "Witness scripts being abused to bypass datacarriersize limit (CVE-2023-50428)":
(https://github.com/bitcoin/bitcoin/issues/29187#issuecomment-1885891577)
> A softfork making data storage impractical. [...] It would also be a slow process

It's going to be a slow process either way:

Even if Bitcoin Core changed its default policy, the effect on propagation would be negligible for a long time.
The p2p network is densely connected, with reachable nodes having 8 tx-relaying outbound peers and typically many more tx-relaying inbounds. Some network simulations I did in the context of full-RBF a few years ago indicated that already a minority of 1
...
πŸ’¬ murchandamus commented on pull request "Add Gutter Guard Selector":
(https://github.com/bitcoin/bitcoin/pull/28977#issuecomment-1885907384)
Yeah, oldest first might be better for soaking up tiny UTXOs at low feerates that have been piling up during bouts of high feerates.

@achow101: What do you think about one of the two like the following progression

| | <2s/vB | <3s/vB | <4s/vB | <5s/vB | <6s/vB | <7s/vB | <8s/vB | <9s/vB | <10s/vB | >=10s/vB |
| --- | --- | -- | -- | -- | -- | -- | -- | -- | -- | -- |
| [A:] UTXO Limit | +21<sup>†</sup> | +18<sup>†</sup> | +15 | +12 | +10 | +8 | +6 | +5 | +4 |+3|
| [B:] UTXO Limit | +4
...
πŸ’¬ andrewtoth commented on pull request "rpc,rest,zmq: faster getblock, NotifyBlock and rest_block by reading raw block":
(https://github.com/bitcoin/bitcoin/pull/26415#discussion_r1448161451)
Fixed. Apparently `IsBlockPruned` is not sufficient to know whether we can read the block or not. Getting the file position of a block that we don't have returns us a null `FlatFilePos`, and `ReadBlockFromDisk` fails on opening a file at null position. `ReadRawBlockFromDisk` instead first tries to decrement `nPos` by 8 before trying to open the file, which results in UB due to `nPos` being unsigned and 0 for a null position.
πŸ’¬ ariard commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#issuecomment-1886085872)
I think this is correct to say that nversion=3 is a weak pinning mitigation.
One can always use a revoked state with max outgoing HTLC outputs=483 to pin.
So 483 * 33 + 1000, you have ~18k vbytes state, mempool backlog at 20 sat/vb, you can steal ~100 USD payments.
Yes `max_offered_htlc` chan policy param can be introduced at the LN-level to bound more commitment size.
However mempool backlog will always make the level of pin exposure dynamic, a bad thing.
(Let's be nice and not introduce c
...
πŸ’¬ murchandamus commented on pull request "wallet: Add CoinGrinder coin selection algorithm":
(https://github.com/bitcoin/bitcoin/pull/27877#discussion_r1448210370)
```suggestion
* reach the target. We continue with the direct successor of our `next_utxo` for the
```
πŸ’¬ murchandamus commented on pull request "wallet: Add CoinGrinder coin selection algorithm":
(https://github.com/bitcoin/bitcoin/pull/27877#discussion_r1448211928)
```suggestion
// Success, adding more weight cannot be better: SHIFT
```
πŸ’¬ saltduck commented on issue "Witness scripts being abused to bypass datacarriersize limit (CVE-2023-50428)":
(https://github.com/bitcoin/bitcoin/issues/29187#issuecomment-1886210780)
Can we just remove the discount of the segwit data? It is fair for both generic users and the attackers.在 2024εΉ΄1月11ζ—₯,07:11,Martin Zumsande ***@***.***> ε†™ι“οΌšο»Ώ

A softfork making data storage impractical. [...] It would also be a slow process

It's going to be a slow process either way:
Even if Bitcoin Core changed its default policy, the effect on propagation would be negligible for a long time.
The p2p network is densely connected, with reachable nodes having 8 tx-relaying outbound peers an
...
πŸ’¬ maflcko commented on pull request "doc: upgrade Bitcoin Core license to 2024":
(https://github.com/bitcoin/bitcoin/pull/29222#issuecomment-1886617839)
In the OP: Just linking to the previous year's pull should be enough. Also, the link to open a pull request doesn't make sense. Also, the @-mention should be removed from the pull description, as described in the docs.
πŸ€” glozow reviewed a pull request: "mempool / rpc: followup to getprioritisedtransactions and delete a mapDeltas entry when delta==0"
(https://github.com/bitcoin/bitcoin/pull/28885#pullrequestreview-1815052118)
ACK 5353af1c8a2dd402a303a786d8aae5edbfc1ff3a
πŸ’¬ glozow commented on pull request "mempool / rpc: followup to getprioritisedtransactions and delete a mapDeltas entry when delta==0":
(https://github.com/bitcoin/bitcoin/pull/28885#discussion_r1448536720)
dc189d3ec5c4af9bca02928dfeb4770570060982: I'm not sure that "new fee" would be understood by people. It would also be helpful to add the units here, i.e.
```suggestion
{RPCResult::Type::NUM, "modified_fee", /*optional=*/true, "modified fee in satoshis. Only returned if in_mempool=true"},
```
πŸ“ BrandonOdiwuor opened a pull request: "wallet: Refactor DumpWallet function to accept -dumpfile path argument"
(https://github.com/bitcoin/bitcoin/pull/29223)
Quick follow-up to https://github.com/bitcoin/bitcoin/pull/29117, coming from _https://github.com/bitcoin/bitcoin/pull/29117#discussion_r1431999422_.

Refactor `DumpWallet(...)` to accept the `-dumpfile` path arg instead of the entire `ArgsManager`
πŸ’¬ maflcko commented on pull request "wallet: Refactor DumpWallet function to accept -dumpfile path argument":
(https://github.com/bitcoin/bitcoin/pull/29223#issuecomment-1886719702)
Not sure. The current version seems just fine
πŸ‘ fanquake approved a pull request: "Use hardened runtime on macOS release builds."
(https://github.com/bitcoin/bitcoin/pull/29127#pullrequestreview-1815147663)
ACK 4fdd836db92e789c98b9e68398ca931a968cc9c3 - we can move ahead with this, and figure out notarisation / stapling as a followup.
βœ… fanquake closed an issue: "macOS App Notarization"
(https://github.com/bitcoin/bitcoin/issues/15774)
πŸš€ fanquake merged a pull request: "Use hardened runtime on macOS release builds."
(https://github.com/bitcoin/bitcoin/pull/29127)
⚠️ fanquake reopened an issue: "macOS App Notarization"
(https://github.com/bitcoin/bitcoin/issues/15774)
> The Apple notary service is an automated system that scans your software for malicious content, checks for code-signing issues, and returns the results to you quickly. If there are no issues, the notary service generates a ticket for you to staple to your software; the notary service also publishes that ticket online where Gatekeeper can find it.

> Beginning in **macOS 10.14.5**, all new or updated kernel extensions and all software from developers new to distributing with Developer ID must
...
πŸ€” glozow reviewed a pull request: "RPC: add new `listmempooltransactions`"
(https://github.com/bitcoin/bitcoin/pull/29016#pullrequestreview-1815145958)
> > Assuming you mean the sequence emitted from Transaction{AddedTo,RemovedFrom}Mempool, note that this is not actually the case (they're usually off by 1 or more due to when the sequence increments happen).
>
> Can you say more about this divergence or point me to a doc that contains more info?

It's more that they just happen to use the same counter, but that doesn't mean they match.
The mempool entry's sequence number is assigned here;
https://github.com/bitcoin/bitcoin/blob/fcacbab487
...