Bitcoin Core Github
42 subscribers
125K links
Download Telegram
💬 sipa commented on pull request "rpc: show P2(W)SH redeemScript in getrawtransaction #27637":
(https://github.com/bitcoin/bitcoin/pull/27638#discussion_r1391514253)
`txundo->vprevout[txin.prevout.n].scriptPubKey` is the scriptPubKey you want.
💬 glozow commented on pull request "bugfix, Change up submitpackage results to return results for all transactions":
(https://github.com/bitcoin/bitcoin/pull/28848#discussion_r1391519236)
yeah makes sense
⚠️ m3dwards opened an issue: "25.0 RC Testing Guide Feedback"
(https://github.com/bitcoin/bitcoin/issues/28866)
This issue is to discuss the [26.0 Release Candidate Testing Guide](https://github.com/bitcoin-core/bitcoin-devwiki/wiki/26.0-Release-Candidate-Testing-Guide). If you have any issues with or feedback on the document, please leave a comment here.

Note: this is for feedback on the document, not on Bitcoin Core or on the 26.0 changes. Please see the https://github.com/bitcoin/bitcoin/issues/28718 for instructions on how to report bug/results.

Thank you for your feedback
💬 theuni commented on pull request "guix: update time-machine":
(https://github.com/bitcoin/bitcoin/pull/28580#issuecomment-1808794490)
Post-merge ACK 92d12f1c890350f40d8e5d5c6a59d5c172ea7550.

x86_64 guix builds:
```
13a7d1be447ecb614cf43034af4f7a3a7ce7dffbcdb6c1773bc939ba80587ef6 guix-build-92d12f1c8903/output/aarch64-linux-gnu/SHA256SUMS.part
5ab66c69b742a89b0aa52705e48563749cb72ebcc92745a4eb07df285a20c62a guix-build-92d12f1c8903/output/aarch64-linux-gnu/bitcoin-92d12f1c8903-aarch64-linux-gnu-debug.tar.gz
d3224eb0eb66bf4433ed8757667ed438e419db4240b06d76122e8754de241742 guix-build-92d12f1c8903/output/aarch64-linux-gn
...
💬 theuni commented on pull request "guix: Use LTO to build releases":
(https://github.com/bitcoin/bitcoin/pull/25391#issuecomment-1808900147)
Any idea where `in6addr_any` is coming from? Seems fine, just curious.
💬 1440000bytes commented on issue "25.0 RC Testing Guide Feedback":
(https://github.com/bitcoin/bitcoin/issues/28866#issuecomment-1808910369)
The title of this issue should be 26.0 instead of 25.0
💬 petertodd commented on pull request "policy: Enable full-rbf by default":
(https://github.com/bitcoin/bitcoin/pull/28132#issuecomment-1809001659)
@Daniel600

> At GAP600 to date we have not seen any significant impact of FULLRBF on our service - we have seen circa 2 trxs which affected us, keep in mind we processed Circa 180k unique trx hash in Sept of 2023.

Have you actually tested full-RBF double spends against your service? Because at the moment, about 40% of hash power is mining with full-RBF enabled. So the chance of a full-RBF double-spend succeeding is approximately 40%.

As an example, here in El Salvador the Chivo ATMs ac
...
💬 petertodd commented on pull request "datacarriersize: Match more datacarrying":
(https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1809035958)
> In addition, it is important to note that if developers do not help node runners defend themselves against this attack, they may have to resort to misappropriate means to strengthen their defense.

This pull-req is not a defense. In fact, it does the opposite: with compact blocks, rejecting transactions that are very likely to get mined actually increases bandwidth consumption, in particular, peak bandwidth. You can either incur that cost when the transaction is broadcast. Or later, when the
...
💬 petertodd commented on pull request "[WIP] BIP300 (Drivechains) consensus-level logic":
(https://github.com/bitcoin/bitcoin/pull/28311#issuecomment-1809045700)
Note that BIP-301 suffers from an [equivocation attack](https://petertodd.org/2023/drivechains#equivocation-attack). While there are [many other reasons](https://petertodd.org/2023/drivechains) to NACK this pull-req, at minimum the equivocation attack is a sufficient reason alone.
💬 furszy commented on pull request "p2p: make block download logic aware of limited peers threshold":
(https://github.com/bitcoin/bitcoin/pull/28120#discussion_r1391727313)
Sounds good. Corrected.
💬 furszy commented on pull request "p2p: make block download logic aware of limited peers threshold":
(https://github.com/bitcoin/bitcoin/pull/28120#discussion_r1391727015)
Done as suggested. Thanks.
⚠️ jb55 opened an issue: "macOS qt QTimer::stop crash on v26.0rc2"
(https://github.com/bitcoin/bitcoin/issues/28867)
### Is there an existing issue for this?

- [X] I have searched the existing issues

### Current behaviour

It crashed randomly

### Expected behaviour

Not to crash randomly

### Steps to reproduce

No idea, I was just syncing the chain.

### Relevant log output

https://cdn.jb55.com/s/adcf1a349cdfc36d.txt

### How did you obtain Bitcoin Core

Compiled from source

### What version of Bitcoin Core are you using?

v26.0rc2

### Operating system and version

macOS Ventura 13.6

### Machine specif
...
📝 achow101 opened a pull request: "wallet: Fix migration of wallets with txs that have both spendable and watchonly outputs"
(https://github.com/bitcoin/bitcoin/pull/28868)
A transaction does not necessarily have to belong to either the migrated wallet (with the private keys) and the watchonly wallet (with watchonly things), it could have multiple outputs with each isminetype. So we should be putting such transactions in one or the other wallet, but rather putting it in both.

I've added a test for this behavior, however the test also revealed a few other issues. Notably, it revealed that `migratewallet` would have the watchonly wallet rescan from genesis when it
...
💬 pablomartin4btc commented on pull request "script, assumeutxo: Enhance validations in utxo_snapshot.sh":
(https://github.com/bitcoin/bitcoin/pull/28852#discussion_r1391748844)
I'll update it with an alternative, as I don't have an instance with macOS, please let me know if that would work better now.
💬 pablomartin4btc commented on pull request "script, assumeutxo: Enhance validations in utxo_snapshot.sh":
(https://github.com/bitcoin/bitcoin/pull/28852#discussion_r1391749053)
Yes! I'll do, but the `reconsiderblock` won't do anything, the issue I see now is that `PIVOT_BLOCKHASH` wasn't initialised so perhaps it fails there.
💬 pablomartin4btc commented on pull request "script, assumeutxo: Enhance validations in utxo_snapshot.sh":
(https://github.com/bitcoin/bitcoin/pull/28852#discussion_r1391749127)
Same as in the previous PR #27845. We could add more context in the output message and perhaps we could update the documentation as well:
https://github.com/bitcoin/bitcoin/blob/5800c558eb5efb4839ed00d6967e43306d68e1c3/doc/design/assumeutxo.md?plain=1#L42-L45
💬 pablomartin4btc commented on pull request "script, assumeutxo: Enhance validations in utxo_snapshot.sh":
(https://github.com/bitcoin/bitcoin/pull/28852#issuecomment-1809202640)
> By the way, at some point when a bash script gets very complicated, it may be better to convert it to Python.

I do agree, but so far I think it's manageable. I'm happy to convert it if more reviewers see other issues there.
💬 pablomartin4btc commented on pull request "script, assumeutxo: Enhance validations in utxo_snapshot.sh":
(https://github.com/bitcoin/bitcoin/pull/28852#discussion_r1391753302)
done.
💬 pablomartin4btc commented on pull request "script, assumeutxo: Enhance validations in utxo_snapshot.sh":
(https://github.com/bitcoin/bitcoin/pull/28852#discussion_r1391753979)
Done, pls let me know.
💬 pablomartin4btc commented on pull request "script, assumeutxo: Enhance validations in utxo_snapshot.sh":
(https://github.com/bitcoin/bitcoin/pull/28852#issuecomment-1809212719)
Addressed @Sjors's feedback.

cc @jamesob as he reviewed #27845, @ryanofsky & @theStack