📝 jotapea opened a pull request: "More comprehensive datacarrier configuration"
(https://github.com/bitcoin/bitcoin/pull/33682)
This PR expands the control and testing of datacarrier transactions by decoupling the total bytes limit from the policy configuration.
---
While doing this, the historical **money-first** defaults for OP_RETURN outputs were reverted.
The [motivation](https://github.com/bitcoin/bitcoin/issues/33595) for this PR is to continue allowing each node to decide/signal their mempool relay (and mining) policy. However, the open-data relaying capacity of v30.0 is acknowledged and build upon.
Th
...
(https://github.com/bitcoin/bitcoin/pull/33682)
This PR expands the control and testing of datacarrier transactions by decoupling the total bytes limit from the policy configuration.
---
While doing this, the historical **money-first** defaults for OP_RETURN outputs were reverted.
The [motivation](https://github.com/bitcoin/bitcoin/issues/33595) for this PR is to continue allowing each node to decide/signal their mempool relay (and mining) policy. However, the open-data relaying capacity of v30.0 is acknowledged and build upon.
Th
...
💬 jotapea commented on pull request "More comprehensive datacarrier configuration":
(https://github.com/bitcoin/bitcoin/pull/33682#discussion_r2452860094)
I must be missing something, because these added tests only work if any (2) previous tests are commented out. Getting the following error: bad-txns-inputs-missingorspent (-25).
(https://github.com/bitcoin/bitcoin/pull/33682#discussion_r2452860094)
I must be missing something, because these added tests only work if any (2) previous tests are commented out. Getting the following error: bad-txns-inputs-missingorspent (-25).
💬 jotapea commented on pull request "More comprehensive datacarrier configuration":
(https://github.com/bitcoin/bitcoin/pull/33682#discussion_r2452869582)
I must be missing something, because these added tests only work if any (2) previous tests are commented out. Getting the following error: bad-txns-inputs-missingorspent (-25).
(https://github.com/bitcoin/bitcoin/pull/33682#discussion_r2452869582)
I must be missing something, because these added tests only work if any (2) previous tests are commented out. Getting the following error: bad-txns-inputs-missingorspent (-25).
💬 kevkevinpal commented on pull request "ci: Retry image building once on failure":
(https://github.com/bitcoin/bitcoin/pull/33677#discussion_r2452929726)
Similar to this comment, https://github.com/bitcoin/bitcoin/pull/33639#discussion_r2448346644
maybe avoid using concats (e.g. via *list)
(https://github.com/bitcoin/bitcoin/pull/33677#discussion_r2452929726)
Similar to this comment, https://github.com/bitcoin/bitcoin/pull/33639#discussion_r2448346644
maybe avoid using concats (e.g. via *list)
💬 kevkevinpal commented on pull request "ci: Retry image building once on failure":
(https://github.com/bitcoin/bitcoin/pull/33677#discussion_r2452994242)
Doesn't this make more sense? And then you can change `*CI_BUILD_MOUNT` to `CI_BUILD_MOUNT`
```
CI_BUILD_MOUNT = []
...
CI_BUILD_MOUNT = f"--mount=type=bind,src={os.environ['BASE_BUILD_DIR']},dst={os.environ['BASE_BUILD_DIR']}"
```
(https://github.com/bitcoin/bitcoin/pull/33677#discussion_r2452994242)
Doesn't this make more sense? And then you can change `*CI_BUILD_MOUNT` to `CI_BUILD_MOUNT`
```
CI_BUILD_MOUNT = []
...
CI_BUILD_MOUNT = f"--mount=type=bind,src={os.environ['BASE_BUILD_DIR']},dst={os.environ['BASE_BUILD_DIR']}"
```
💬 kevkevinpal commented on pull request "ci: Retry image building once on failure":
(https://github.com/bitcoin/bitcoin/pull/33677#discussion_r2453051321)
Why add `check=False` for these commands when previously there was no `|| true` appended to the original statements
(https://github.com/bitcoin/bitcoin/pull/33677#discussion_r2453051321)
Why add `check=False` for these commands when previously there was no `|| true` appended to the original statements
💬 ubbabeck commented on pull request "rest: allow reading partial block data from storage":
(https://github.com/bitcoin/bitcoin/pull/33657#issuecomment-3433931938)
tACK 301116e855
What was done:
- functional test.
- unit test
- tested the new rest endpoint `rest/blockpart/<blockhash>.bin` manually with curl with different offsets and sizes.
If there are any additional test you'd like me to help with let me know.
I also did a perf dump, but I need some guidelines on what to measure/ grep for.
(https://github.com/bitcoin/bitcoin/pull/33657#issuecomment-3433931938)
tACK 301116e855
What was done:
- functional test.
- unit test
- tested the new rest endpoint `rest/blockpart/<blockhash>.bin` manually with curl with different offsets and sizes.
If there are any additional test you'd like me to help with let me know.
I also did a perf dump, but I need some guidelines on what to measure/ grep for.
⚠️ JohnnyFFM opened an issue: "qt: Amount field too narrow on Windows in Send Coins dialog"
(https://github.com/bitcoin-core/gui/issues/906)
### Is there an existing issue for this?
- [x] I have searched the existing issues
### Current behaviour
On my Windows machine, the amount input field in the Send Coins dialog is extremely narrow (approximately 25 pixels wide). I can't see the amount I'm entering, see screenshot:
<img width="739" height="528" alt="Image" src="https://github.com/user-attachments/assets/1a36aed1-def6-4696-adc4-4d86f3f26a46" />
My Linux machine is not affected.
### Expected behaviour
The amount field should
...
(https://github.com/bitcoin-core/gui/issues/906)
### Is there an existing issue for this?
- [x] I have searched the existing issues
### Current behaviour
On my Windows machine, the amount input field in the Send Coins dialog is extremely narrow (approximately 25 pixels wide). I can't see the amount I'm entering, see screenshot:
<img width="739" height="528" alt="Image" src="https://github.com/user-attachments/assets/1a36aed1-def6-4696-adc4-4d86f3f26a46" />
My Linux machine is not affected.
### Expected behaviour
The amount field should
...
💬 cedwies commented on pull request "More comprehensive datacarrier configuration":
(https://github.com/bitcoin/bitcoin/pull/33682#issuecomment-3434048783)
Concept NACK
Adding a new startup option (`-datacarriercount`) increases policy heterogeneity across the network. As discussed in the [motivation](https://github.com/bitcoin/bitcoin/issues/33595), more heterogeneity → less mempool overlap → more missing transactions during compact block reconstruction → slower propagation on the critical path.
v30 moved in the opposite direction to improve relay quality. Reintroducing another dimension of variance cuts against that goal.
v30 deliberately
...
(https://github.com/bitcoin/bitcoin/pull/33682#issuecomment-3434048783)
Concept NACK
Adding a new startup option (`-datacarriercount`) increases policy heterogeneity across the network. As discussed in the [motivation](https://github.com/bitcoin/bitcoin/issues/33595), more heterogeneity → less mempool overlap → more missing transactions during compact block reconstruction → slower propagation on the critical path.
v30 moved in the opposite direction to improve relay quality. Reintroducing another dimension of variance cuts against that goal.
v30 deliberately
...
💬 jotapea commented on pull request "More comprehensive datacarrier configuration":
(https://github.com/bitcoin/bitcoin/pull/33682#issuecomment-3434097094)
Much appreciated feedback @cedwies . As mentioned, the main features of the PR are:
> First, for more robust and complete testing. And second, to allow full backwards compatibility of datacarrier policy. Specifically, to allow limiting the amount of OP_RETURN outputs to just 1.
So, I can easily do a separate PR keeping v30.0 defaults. But will not for now, in order to not fragment the conversation.
*(I truly believe reverting the defaults asap is a net positive (some damage can't be und
...
(https://github.com/bitcoin/bitcoin/pull/33682#issuecomment-3434097094)
Much appreciated feedback @cedwies . As mentioned, the main features of the PR are:
> First, for more robust and complete testing. And second, to allow full backwards compatibility of datacarrier policy. Specifically, to allow limiting the amount of OP_RETURN outputs to just 1.
So, I can easily do a separate PR keeping v30.0 defaults. But will not for now, in order to not fragment the conversation.
*(I truly believe reverting the defaults asap is a net positive (some damage can't be und
...
💬 kevkevinpal commented on pull request "doc: add AGENTS.md":
(https://github.com/bitcoin/bitcoin/pull/33662#issuecomment-3434113195)
ACK [08cf213](https://github.com/bitcoin/bitcoin/pull/33662/commits/08cf213ec7e671dd4162d4ae4d0d20810547a444)
Doesn't hurt to add and it could useful when we do see the Co-author as an llm
(https://github.com/bitcoin/bitcoin/pull/33662#issuecomment-3434113195)
ACK [08cf213](https://github.com/bitcoin/bitcoin/pull/33662/commits/08cf213ec7e671dd4162d4ae4d0d20810547a444)
Doesn't hurt to add and it could useful when we do see the Co-author as an llm
💬 waketraindev commented on pull request "More comprehensive datacarrier configuration":
(https://github.com/bitcoin/bitcoin/pull/33682#issuecomment-3434185716)
Concept NACK
Unhealthy for the network and peers.
Relies on other peers to deliver already seen and rejected transactions upon confirmation and rebroadcast.
Default extra pool sizes are too small to retain arbitrary rejected transactions, whether they use datacarrier=0 or otherwise.
(https://github.com/bitcoin/bitcoin/pull/33682#issuecomment-3434185716)
Concept NACK
Unhealthy for the network and peers.
Relies on other peers to deliver already seen and rejected transactions upon confirmation and rebroadcast.
Default extra pool sizes are too small to retain arbitrary rejected transactions, whether they use datacarrier=0 or otherwise.
💬 Rob1Ham commented on pull request "wallet: warn against accidental unsafe older() import":
(https://github.com/bitcoin/bitcoin/pull/33135#issuecomment-3434194550)
I have a question as it relates to relative timelocks using the older() fragment if one were programming an epoch time based timelock.
The smallest value that can be used to have the miniscript compiler interpret a relative timelock is older(4194305) (calculated by following the BIP68 spec of: 1 |= (1 << 22)). This is a 1 unit timelock of duration 512 seconds.
The maximum value for a relative epoch timelock is older(4259839) which is 65,535 unit timelock, resulting in 33,554,431 seconds, o
...
(https://github.com/bitcoin/bitcoin/pull/33135#issuecomment-3434194550)
I have a question as it relates to relative timelocks using the older() fragment if one were programming an epoch time based timelock.
The smallest value that can be used to have the miniscript compiler interpret a relative timelock is older(4194305) (calculated by following the BIP68 spec of: 1 |= (1 << 22)). This is a 1 unit timelock of duration 512 seconds.
The maximum value for a relative epoch timelock is older(4259839) which is 65,535 unit timelock, resulting in 33,554,431 seconds, o
...
✅ achow101 closed a pull request: "More comprehensive datacarrier configuration"
(https://github.com/bitcoin/bitcoin/pull/33682)
(https://github.com/bitcoin/bitcoin/pull/33682)
💬 achow101 commented on pull request "More comprehensive datacarrier configuration":
(https://github.com/bitcoin/bitcoin/pull/33682#issuecomment-3434222122)
Concept NACK
I don't think any contributors are interested in re-litigating this. Please see all of the commentary that has already been made on this topic.
(https://github.com/bitcoin/bitcoin/pull/33682#issuecomment-3434222122)
Concept NACK
I don't think any contributors are interested in re-litigating this. Please see all of the commentary that has already been made on this topic.
📝 musaHaruna opened a pull request: "doc: Add blockman param to GetTransaction doc comment"
(https://github.com/bitcoin/bitcoin/pull/33683)
Follow-up to [#27125(comment)](https://github.com/bitcoin/bitcoin/pull/27125#discussion_r1190350876)
This PR addresses a minor documentation and style nit mentioned during review:
- Adds the missing `@param[in] blockman` line to the `GetTransaction()` doc comment.
- Moves the output parameter `hashBlock` to the end of both the function
declaration and definition, as suggested in the comment.
(https://github.com/bitcoin/bitcoin/pull/33683)
Follow-up to [#27125(comment)](https://github.com/bitcoin/bitcoin/pull/27125#discussion_r1190350876)
This PR addresses a minor documentation and style nit mentioned during review:
- Adds the missing `@param[in] blockman` line to the `GetTransaction()` doc comment.
- Moves the output parameter `hashBlock` to the end of both the function
declaration and definition, as suggested in the comment.
💬 romanz commented on pull request "rest: allow reading partial block data from storage":
(https://github.com/bitcoin/bitcoin/pull/33657#issuecomment-3434299935)
Many thanks @ubbabeck!
> If there are any additional test you'd like me to help with let me know.
It would be interesting to compare the performance for single transaction fetching, similar to how it was done in https://github.com/bitcoin/bitcoin/pull/32541#issuecomment-2897330791, comparing `txindex`-based and `locationindex`-based queries.
(https://github.com/bitcoin/bitcoin/pull/33657#issuecomment-3434299935)
Many thanks @ubbabeck!
> If there are any additional test you'd like me to help with let me know.
It would be interesting to compare the performance for single transaction fetching, similar to how it was done in https://github.com/bitcoin/bitcoin/pull/32541#issuecomment-2897330791, comparing `txindex`-based and `locationindex`-based queries.
💬 musaHaruna commented on pull request "rpc: Distinguish between vsize and sigop adjusted mempool vsize":
(https://github.com/bitcoin/bitcoin/pull/32800#issuecomment-3434365459)
> nit: The adjusted beginning is nicer, but would rather bring back the end from 1523e8d
Addressed by bring back the last sentence in commit [1523e8d](https://github.com/bitcoin/bitcoin/commit/1523e8d6c981efff1394bd1669fbbbea5ff7ac97)
> nit: I think this part is repetitive and somewhat arbitrary, currently the PR ensures sigop-adjusted and non-sigop-adjusted sizes are available for all mentioned RPCs. If I was using RPCs for each transaction for this calculation I would just pick the faste
...
(https://github.com/bitcoin/bitcoin/pull/32800#issuecomment-3434365459)
> nit: The adjusted beginning is nicer, but would rather bring back the end from 1523e8d
Addressed by bring back the last sentence in commit [1523e8d](https://github.com/bitcoin/bitcoin/commit/1523e8d6c981efff1394bd1669fbbbea5ff7ac97)
> nit: I think this part is repetitive and somewhat arbitrary, currently the PR ensures sigop-adjusted and non-sigop-adjusted sizes are available for all mentioned RPCs. If I was using RPCs for each transaction for this calculation I would just pick the faste
...
⚠️ achow101 opened an issue: "Async Payjoin"
(https://github.com/bitcoin/bitcoin/issues/33684)
This issue is for the tracking and brainstorming of the implementation of [BIP 77 Async Payjoin](https://github.com/bitcoin/bips) into the wallet.
***
- [ ] HPKE #32617
- [ ] The rest :)
***
Async Payjoin utilizes an external Directory server to allow the Sender and Receiver to communicate with each other without needing to operate any infrastructure. The servers are reached using [RFC 9458 Oblivious HTTP (OHTTP)](https://www.ietf.org/rfc/rfc9458.html) relays to avoid revealing the IPs of t
...
(https://github.com/bitcoin/bitcoin/issues/33684)
This issue is for the tracking and brainstorming of the implementation of [BIP 77 Async Payjoin](https://github.com/bitcoin/bips) into the wallet.
***
- [ ] HPKE #32617
- [ ] The rest :)
***
Async Payjoin utilizes an external Directory server to allow the Sender and Receiver to communicate with each other without needing to operate any infrastructure. The servers are reached using [RFC 9458 Oblivious HTTP (OHTTP)](https://www.ietf.org/rfc/rfc9458.html) relays to avoid revealing the IPs of t
...
✅ achow101 closed an issue: "Implement PayJoin / Pay-to-EndPoint"
(https://github.com/bitcoin/bitcoin/issues/19148)
(https://github.com/bitcoin/bitcoin/issues/19148)