👍 t-bast approved a pull request: "policy: Add PayToAnchor(P2A), `OP_TRUE <0x4e73>` as a standard output script for spending"
(https://github.com/bitcoin/bitcoin/pull/30352#pullrequestreview-2187787797)
ACK https://github.com/bitcoin/bitcoin/pull/30352/commits/8d956ccb86d70e2059a5e2ccd8e63b7f7c8e3842, thanks for pushing this!
I've read through the code and comments on this PR, and to me it makes sense to use a taproot 2-byte program, the cute trick of having it encode as "fees" in bech32m can be useful (since we need to arbitrarily choose 2 bytes anyway for the program), and it's a step towards ephemeral anchors which are much better than current anchor outputs :+1:
Regarding utxo bloat
...
(https://github.com/bitcoin/bitcoin/pull/30352#pullrequestreview-2187787797)
ACK https://github.com/bitcoin/bitcoin/pull/30352/commits/8d956ccb86d70e2059a5e2ccd8e63b7f7c8e3842, thanks for pushing this!
I've read through the code and comments on this PR, and to me it makes sense to use a taproot 2-byte program, the cute trick of having it encode as "fees" in bech32m can be useful (since we need to arbitrarily choose 2 bytes anyway for the program), and it's a step towards ephemeral anchors which are much better than current anchor outputs :+1:
Regarding utxo bloat
...
💬 t-bast commented on pull request "Ephemeral Dust":
(https://github.com/bitcoin/bitcoin/pull/30239#issuecomment-2238752561)
Concept ACK :+1:
(https://github.com/bitcoin/bitcoin/pull/30239#issuecomment-2238752561)
Concept ACK :+1:
💬 fanquake commented on pull request "Stratum v2 Template Provider common functionality":
(https://github.com/bitcoin/bitcoin/pull/30475#issuecomment-2238759084)
Can you clarify what the point of PRs like this is, given you have a number of them open? They aren't reviewable, or mergable (given they are all based on various PRs, which them selves are in various stages of draft/WIP), and the continual pushes keep taking up all the CI resources in the repo (I thought we'd adjusted the CI so that you can use your own repo?).
(https://github.com/bitcoin/bitcoin/pull/30475#issuecomment-2238759084)
Can you clarify what the point of PRs like this is, given you have a number of them open? They aren't reviewable, or mergable (given they are all based on various PRs, which them selves are in various stages of draft/WIP), and the continual pushes keep taking up all the CI resources in the repo (I thought we'd adjusted the CI so that you can use your own repo?).
💬 maflcko commented on issue "Feature Request: Broadcast Pool":
(https://github.com/bitcoin/bitcoin/issues/30471#issuecomment-2238799112)
The same problem exists in a broadcast pool. For example:
* Alice broadcasts at 10sat/vb, but the transaction isn't confirmed in $mempool_expiry time, and thus dropped from Alice's mempool (and broadcast pool). (The transaction may or may not be in a miner's mempool with larger expiry)
* Mallory broadcasts her at 9sat/vb.
* Alice's wallet discards her transaction using 10sat/vb, based on the hierarchy `confirmed > mempool > local` (or `confirmed > mempool > broadcast_pool > local`)
So I
...
(https://github.com/bitcoin/bitcoin/issues/30471#issuecomment-2238799112)
The same problem exists in a broadcast pool. For example:
* Alice broadcasts at 10sat/vb, but the transaction isn't confirmed in $mempool_expiry time, and thus dropped from Alice's mempool (and broadcast pool). (The transaction may or may not be in a miner's mempool with larger expiry)
* Mallory broadcasts her at 9sat/vb.
* Alice's wallet discards her transaction using 10sat/vb, based on the hierarchy `confirmed > mempool > local` (or `confirmed > mempool > broadcast_pool > local`)
So I
...
💬 fanquake commented on pull request "depends: build expat with CMake":
(https://github.com/bitcoin/bitcoin/pull/29878#issuecomment-2238813040)
Rebased on master. 32-bit builds should also be fixed. No longer a version bump, just a Autotools -> CMake switch.
(https://github.com/bitcoin/bitcoin/pull/29878#issuecomment-2238813040)
Rebased on master. 32-bit builds should also be fixed. No longer a version bump, just a Autotools -> CMake switch.
👋 fanquake's pull request is ready for review: "depends: build expat with CMake"
(https://github.com/bitcoin/bitcoin/pull/29878)
(https://github.com/bitcoin/bitcoin/pull/29878)
💬 craigraw commented on issue "Feature Request: Broadcast Pool":
(https://github.com/bitcoin/bitcoin/issues/30471#issuecomment-2238824451)
> and thus dropped from Alice's mempool (and broadcast pool)
This is where we differ. From my description in the OP: "Transactions in the broadcast pool are subject to almost all of the same rules as those in the mempool, except that they are not removed due to mempool size limitations." Therefore, in this scenario, the transaction would not be dropped from the broadcast pool.
I don't want to focus too deeply on whether the situation must be adversarial - as a wallet developer, I am always
...
(https://github.com/bitcoin/bitcoin/issues/30471#issuecomment-2238824451)
> and thus dropped from Alice's mempool (and broadcast pool)
This is where we differ. From my description in the OP: "Transactions in the broadcast pool are subject to almost all of the same rules as those in the mempool, except that they are not removed due to mempool size limitations." Therefore, in this scenario, the transaction would not be dropped from the broadcast pool.
I don't want to focus too deeply on whether the situation must be adversarial - as a wallet developer, I am always
...
💬 maflcko commented on issue "Feature Request: Broadcast Pool":
(https://github.com/bitcoin/bitcoin/issues/30471#issuecomment-2238834490)
> > and thus dropped from Alice's mempool (and broadcast pool)
>
> This is where we differ. From my description in the OP: "Transactions in the broadcast pool are subject to almost all of the same rules as those in the mempool, except that they are not removed due to mempool size limitations." Therefore, in this scenario, the transaction would not be dropped from the broadcast pool.
I think you accidentally mixed up size limits and expiry. They are different, because one looks at the memor
...
(https://github.com/bitcoin/bitcoin/issues/30471#issuecomment-2238834490)
> > and thus dropped from Alice's mempool (and broadcast pool)
>
> This is where we differ. From my description in the OP: "Transactions in the broadcast pool are subject to almost all of the same rules as those in the mempool, except that they are not removed due to mempool size limitations." Therefore, in this scenario, the transaction would not be dropped from the broadcast pool.
I think you accidentally mixed up size limits and expiry. They are different, because one looks at the memor
...
💬 Sjors commented on pull request "Stratum v2 Template Provider common functionality":
(https://github.com/bitcoin/bitcoin/pull/30475#issuecomment-2238837637)
@fanquake there's ongoing discussion in #29432 as to whether the Template Provider should be part of Bitcoin Core or be its own "sidecar" application. And the latter case there's still discussion about _how_ to do that, e.g. using ZMQ/RPC, p2p or IPC.
I built a proof of concept for the IPC sidecar approach in https://github.com/Sjors/bitcoin/pull/48.
It took me a while to iron out the interfaces, but with that (mostly) out of the way, I expect to need far fewer pushes than in the last few
...
(https://github.com/bitcoin/bitcoin/pull/30475#issuecomment-2238837637)
@fanquake there's ongoing discussion in #29432 as to whether the Template Provider should be part of Bitcoin Core or be its own "sidecar" application. And the latter case there's still discussion about _how_ to do that, e.g. using ZMQ/RPC, p2p or IPC.
I built a proof of concept for the IPC sidecar approach in https://github.com/Sjors/bitcoin/pull/48.
It took me a while to iron out the interfaces, but with that (mostly) out of the way, I expect to need far fewer pushes than in the last few
...
💬 craigraw commented on issue "Feature Request: Broadcast Pool":
(https://github.com/bitcoin/bitcoin/issues/30471#issuecomment-2238846496)
> They are different, because one looks at the memory usage and the other at expiry times (regardless of memory usage). With expiry, it is possible that transactions are dropped, even if the size limit is not yet hit.
I agree with this description, but am unclear how this impacts the scenario I described, where in no case is a transaction dropped due to expiry. All of the events described can occur within a 2 week period.
(https://github.com/bitcoin/bitcoin/issues/30471#issuecomment-2238846496)
> They are different, because one looks at the memory usage and the other at expiry times (regardless of memory usage). With expiry, it is possible that transactions are dropped, even if the size limit is not yet hit.
I agree with this description, but am unclear how this impacts the scenario I described, where in no case is a transaction dropped due to expiry. All of the events described can occur within a 2 week period.
💬 Sjors commented on issue "guix: build multiprocess":
(https://github.com/bitcoin/bitcoin/issues/30483#issuecomment-2238869283)
```
make: Entering directory '/bitcoin/depends'
Checksum missing or mismatched for native_capnp source. Forcing re-download.
Fetching capnproto-c++-1.0.1.tar.gz from https://capnproto.org/
/gnu/store/v9p25q9l5nnaixkhpap5rnymmwbhf9rp-bash-minimal-5.1.16/bin/sh: line 1: curl: command not found
Fetching capnproto-c++-1.0.1.tar.gz from https://bitcoincore.org/depends-sources
/gnu/store/v9p25q9l5nnaixkhpap5rnymmwbhf9rp-bash-minimal-5.1.16/bin/sh: line 1: curl: command not found
make: *** [func
...
(https://github.com/bitcoin/bitcoin/issues/30483#issuecomment-2238869283)
```
make: Entering directory '/bitcoin/depends'
Checksum missing or mismatched for native_capnp source. Forcing re-download.
Fetching capnproto-c++-1.0.1.tar.gz from https://capnproto.org/
/gnu/store/v9p25q9l5nnaixkhpap5rnymmwbhf9rp-bash-minimal-5.1.16/bin/sh: line 1: curl: command not found
Fetching capnproto-c++-1.0.1.tar.gz from https://bitcoincore.org/depends-sources
/gnu/store/v9p25q9l5nnaixkhpap5rnymmwbhf9rp-bash-minimal-5.1.16/bin/sh: line 1: curl: command not found
make: *** [func
...
💬 fanquake commented on issue "guix: build multiprocess":
(https://github.com/bitcoin/bitcoin/issues/30483#issuecomment-2238873291)
You need to have curl installed to download things with curl. The downloading happens outside guix, so this is a local issue.
(https://github.com/bitcoin/bitcoin/issues/30483#issuecomment-2238873291)
You need to have curl installed to download things with curl. The downloading happens outside guix, so this is a local issue.
💬 Sjors commented on issue "guix: build multiprocess":
(https://github.com/bitcoin/bitcoin/issues/30483#issuecomment-2238879050)
> The downloading happens outside guix, so this is a local issue.
Ah
I do have `curl` installed though.
```
curl --version
curl 8.5.0 (x86_64-pc-linux-gnu) libcurl/8.5.0 OpenSSL/3.0.13 zlib/1.3 brotli/1.1.0 zstd/1.5.5 libidn2/2.3.7 libpsl/0.21.2 (+libidn2/2.3.7) libssh/0.10.6/openssl/zlib nghttp2/1.59.0 librtmp/2.3 OpenLDAP/2.6.7
Release-Date: 2023-12-06, security patched: 8.5.0-2ubuntu10.1
Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s
...
(https://github.com/bitcoin/bitcoin/issues/30483#issuecomment-2238879050)
> The downloading happens outside guix, so this is a local issue.
Ah
I do have `curl` installed though.
```
curl --version
curl 8.5.0 (x86_64-pc-linux-gnu) libcurl/8.5.0 OpenSSL/3.0.13 zlib/1.3 brotli/1.1.0 zstd/1.5.5 libidn2/2.3.7 libpsl/0.21.2 (+libidn2/2.3.7) libssh/0.10.6/openssl/zlib nghttp2/1.59.0 librtmp/2.3 OpenLDAP/2.6.7
Release-Date: 2023-12-06, security patched: 8.5.0-2ubuntu10.1
Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s
...
💬 Sjors commented on issue "guix: build multiprocess":
(https://github.com/bitcoin/bitcoin/issues/30483#issuecomment-2238884517)
I tried with your branch as well, and get the same failure. So I agree it must be some difference between our guix setups. But I've signed plenty releases with it, and never ran into this with any of the build change PR's for which I made guix builds.
(https://github.com/bitcoin/bitcoin/issues/30483#issuecomment-2238884517)
I tried with your branch as well, and get the same failure. So I agree it must be some difference between our guix setups. But I've signed plenty releases with it, and never ran into this with any of the build change PR's for which I made guix builds.
💬 fanquake commented on issue "guix: build multiprocess":
(https://github.com/bitcoin/bitcoin/issues/30483#issuecomment-2238888015)
You should also add MULTIPROCESS=1 to your guix build command, so that your multiprocess tarballs are redownloaded outside guix.
The issue is that the mismatch is detected at build time in the container, where redownloading will fail due to the lack of curl.
(https://github.com/bitcoin/bitcoin/issues/30483#issuecomment-2238888015)
You should also add MULTIPROCESS=1 to your guix build command, so that your multiprocess tarballs are redownloaded outside guix.
The issue is that the mismatch is detected at build time in the container, where redownloading will fail due to the lack of curl.
💬 fanquake commented on pull request "Stratum v2 Template Provider common functionality":
(https://github.com/bitcoin/bitcoin/pull/30475#issuecomment-2238892864)
> Every PR I've opened is reviewable.
Sure, but it's unlikely anyone is going to review something like this, that is itself based on 7 other PRs, 4 of which are also marked as draft. Even just due to the fact that any review is likely wasted, due to that same review already being done in any of the base PRs.
> If the discussion in https://github.com/bitcoin/bitcoin/pull/29432 eventually settles on the sidecar approach (I don't think it has yet), then it makes sense that I move this PR, htt
...
(https://github.com/bitcoin/bitcoin/pull/30475#issuecomment-2238892864)
> Every PR I've opened is reviewable.
Sure, but it's unlikely anyone is going to review something like this, that is itself based on 7 other PRs, 4 of which are also marked as draft. Even just due to the fact that any review is likely wasted, due to that same review already being done in any of the base PRs.
> If the discussion in https://github.com/bitcoin/bitcoin/pull/29432 eventually settles on the sidecar approach (I don't think it has yet), then it makes sense that I move this PR, htt
...
✅ Sjors closed an issue: "guix: build multiprocess"
(https://github.com/bitcoin/bitcoin/issues/30483)
(https://github.com/bitcoin/bitcoin/issues/30483)
💬 Sjors commented on issue "guix: build multiprocess":
(https://github.com/bitcoin/bitcoin/issues/30483#issuecomment-2238893419)
Ah that worked, thanks!
In that case I don't think there's anything specific that needs to happen.
(https://github.com/bitcoin/bitcoin/issues/30483#issuecomment-2238893419)
Ah that worked, thanks!
In that case I don't think there's anything specific that needs to happen.
💬 hebasto commented on pull request "qa: Functional test improvements":
(https://github.com/bitcoin/bitcoin/pull/30463#discussion_r1684210193)
Your example creates a hard link on Linux, which is not what happens in the CMake-based build system.
Do you think we should adjust our functional tests in way to handle hard links on Linux?
(https://github.com/bitcoin/bitcoin/pull/30463#discussion_r1684210193)
Your example creates a hard link on Linux, which is not what happens in the CMake-based build system.
Do you think we should adjust our functional tests in way to handle hard links on Linux?
💬 Sjors commented on pull request "Stratum v2 Template Provider common functionality":
(https://github.com/bitcoin/bitcoin/pull/30475#issuecomment-2238912720)
I opened #29346, #30315 and #30332 months before the renewed discussion started. My approach in #29432 is no different from that of #27854 which has had multiple concept ACK's from experienced developers for more than a year now. So I don't think it was premature to open these sub PRs.
> Even just due to the fact that any review is likely wasted, due to that same review already being done in any of the base PRs.
That's always a risk when stacking PRs. So far it hasn't happened. The descrip
...
(https://github.com/bitcoin/bitcoin/pull/30475#issuecomment-2238912720)
I opened #29346, #30315 and #30332 months before the renewed discussion started. My approach in #29432 is no different from that of #27854 which has had multiple concept ACK's from experienced developers for more than a year now. So I don't think it was premature to open these sub PRs.
> Even just due to the fact that any review is likely wasted, due to that same review already being done in any of the base PRs.
That's always a risk when stacking PRs. So far it hasn't happened. The descrip
...