π¬ hebasto commented on pull request "build: Introduce CMake-based build system":
(https://github.com/bitcoin/bitcoin/pull/30454#discussion_r1720978737)
It installs the built project to the default install prefix, which is the value of the `CMAKE_INSTALL_PREFIX` variable.
(https://github.com/bitcoin/bitcoin/pull/30454#discussion_r1720978737)
It installs the built project to the default install prefix, which is the value of the `CMAKE_INSTALL_PREFIX` variable.
π¬ fjahr commented on pull request "seeds: Pull additional nodes from my seeder and update fixed seeds":
(https://github.com/bitcoin/bitcoin/pull/30008#discussion_r1720984906)
> I think you can make a symlink in the repo and just make sure it's updated every time.
I tried this but it seems like it's not supported. I didn't an official statement but here is a discussion that seems to confirm there is not way to use symlinks for this: https://github.com/dear-github/dear-github/issues/156
(https://github.com/bitcoin/bitcoin/pull/30008#discussion_r1720984906)
> I think you can make a symlink in the repo and just make sure it's updated every time.
I tried this but it seems like it's not supported. I didn't an official statement but here is a discussion that seems to confirm there is not way to use symlinks for this: https://github.com/dear-github/dear-github/issues/156
π¬ ryanofsky commented on pull request "refactor: Replace ParseHex with consteval HexLiteral":
(https://github.com/bitcoin/bitcoin/pull/30377#discussion_r1721008790)
re: https://github.com/bitcoin/bitcoin/pull/30377#discussion_r1720801552
> I mean both `Vec(HexLiteral(` and the existing `ToByteVector(HexLiteral(` would work here, right?
Right, ToByteVector could be used here instead of Vec, and Vec was just chosen because it is shorter. Sorry I misunderstood your original question.
I do think in general Vec has some benefits over ToByteVector:
- `Vec` only changes the type of the container, not the type of the elements inside the container, so it
...
(https://github.com/bitcoin/bitcoin/pull/30377#discussion_r1721008790)
re: https://github.com/bitcoin/bitcoin/pull/30377#discussion_r1720801552
> I mean both `Vec(HexLiteral(` and the existing `ToByteVector(HexLiteral(` would work here, right?
Right, ToByteVector could be used here instead of Vec, and Vec was just chosen because it is shorter. Sorry I misunderstood your original question.
I do think in general Vec has some benefits over ToByteVector:
- `Vec` only changes the type of the container, not the type of the elements inside the container, so it
...
π¬ ryanofsky commented on pull request "refactor: Replace ParseHex with consteval HexLiteral":
(https://github.com/bitcoin/bitcoin/pull/30377#discussion_r1721004385)
re: https://github.com/bitcoin/bitcoin/pull/30377#discussion_r1720801377
Yes, you're right , I misread the suggestion. Using valtype to construct vectors would not change which CScript method is called, so it should be not a problem to make that change in this PR, and maybe it would be better. I do think tests would be more readable and consistent if they used HexLiteral as much as possible to represent raw bytes, but that's a subjective opinion and your approach seems fine too.
(https://github.com/bitcoin/bitcoin/pull/30377#discussion_r1721004385)
re: https://github.com/bitcoin/bitcoin/pull/30377#discussion_r1720801377
Yes, you're right , I misread the suggestion. Using valtype to construct vectors would not change which CScript method is called, so it should be not a problem to make that change in this PR, and maybe it would be better. I do think tests would be more readable and consistent if they used HexLiteral as much as possible to represent raw bytes, but that's a subjective opinion and your approach seems fine too.
π¬ johndpierre1 commented on pull request "build: Introduce CMake-based build system":
(https://github.com/bitcoin/bitcoin/pull/30454#issuecomment-2295339790)
Hey
On Sun, Aug 4, 2024 at 11:40 l0rinc ***@***.***> wrote:
> I can barely contain my excitement about this change, finally the whole
> project came alive for me in CLion - a few of the features that are working
> with cmake that didn't work before:
>
> - right click to run boost test + debug:
>
> image.png (view on web)
> <https://github.com/user-attachments/assets/ab8c93f8-58e0-435f-b834-51e245a26468> image.png
> (view on web)
> <https://github.com/user-attachments/assets/d20
...
(https://github.com/bitcoin/bitcoin/pull/30454#issuecomment-2295339790)
Hey
On Sun, Aug 4, 2024 at 11:40 l0rinc ***@***.***> wrote:
> I can barely contain my excitement about this change, finally the whole
> project came alive for me in CLion - a few of the features that are working
> with cmake that didn't work before:
>
> - right click to run boost test + debug:
>
> image.png (view on web)
> <https://github.com/user-attachments/assets/ab8c93f8-58e0-435f-b834-51e245a26468> image.png
> (view on web)
> <https://github.com/user-attachments/assets/d20
...
β οΈ bitcoinchunk opened an issue: "Question on Changing Bitcoin Blockchain Data Directory in Linux Without Redownloading"
(https://github.com/bitcoin/bitcoin/issues/30672)
Hello Bitcoin Community,
Iβm looking for some guidance on how to change the default data directory for the Bitcoin blockchain on a Linux system. I want to move the blockchain data to a different drive with more space, but Iβd prefer not to download the entire blockchain from scratch.
Could someone walk me through the steps to move the data seamlessly, ensuring that all configurations are correctly updated? Any tips to avoid issues during the process would be greatly appreciated.
Thanks
...
(https://github.com/bitcoin/bitcoin/issues/30672)
Hello Bitcoin Community,
Iβm looking for some guidance on how to change the default data directory for the Bitcoin blockchain on a Linux system. I want to move the blockchain data to a different drive with more space, but Iβd prefer not to download the entire blockchain from scratch.
Could someone walk me through the steps to move the data seamlessly, ensuring that all configurations are correctly updated? Any tips to avoid issues during the process would be greatly appreciated.
Thanks
...
π¬ whitslack commented on pull request "build: Introduce CMake-based build system":
(https://github.com/bitcoin/bitcoin/pull/30454#discussion_r1721043065)
> I'm doing some test builds on Windows and it was a bit of a treasure hunt to find the binaries.
@sipsorcery: Rather than going on a treasure hunt, wouldn't you "install" the built product to a staging directory and then produce your distributable package from there? That way you'll pick up all the bits that the build system wants you to have and none that it doesn't.
(https://github.com/bitcoin/bitcoin/pull/30454#discussion_r1721043065)
> I'm doing some test builds on Windows and it was a bit of a treasure hunt to find the binaries.
@sipsorcery: Rather than going on a treasure hunt, wouldn't you "install" the built product to a staging directory and then produce your distributable package from there? That way you'll pick up all the bits that the build system wants you to have and none that it doesn't.
π¬ whitslack commented on pull request "build: Introduce CMake-based build system":
(https://github.com/bitcoin/bitcoin/pull/30454#issuecomment-2295367078)
> > One small gripe: When we enter the install phase, CMake always rebuilds `src/clientversion.cpp`, which forces a relink of all target executables. It would be better if `ninja install` would not rebuild anything.
>
> Is this still an issue with the recent update?
@hebasto: Nope! It works as expected at 41051290ab3b6c36312cec26a27f787cea9961b4. :grin: Thanks!
(https://github.com/bitcoin/bitcoin/pull/30454#issuecomment-2295367078)
> > One small gripe: When we enter the install phase, CMake always rebuilds `src/clientversion.cpp`, which forces a relink of all target executables. It would be better if `ninja install` would not rebuild anything.
>
> Is this still an issue with the recent update?
@hebasto: Nope! It works as expected at 41051290ab3b6c36312cec26a27f787cea9961b4. :grin: Thanks!
π¬ johndpierre1 commented on pull request "build: Introduce CMake-based build system":
(https://github.com/bitcoin/bitcoin/pull/30454#issuecomment-2295367360)
Who is using my email to text you
I have been hacked
On Sun, Aug 18, 2024 at 20:30 Matt Whitlock ***@***.***>
wrote:
> ***@***.**** commented on this pull request.
> ------------------------------
>
> In doc/build-windows-msvc.md
> <https://github.com/bitcoin/bitcoin/pull/30454#discussion_r1721043065>:
>
> > +
> +### 4. Building with Dynamic Linking with GUI
> +
> +```
> +cmake -B build --preset vs2022 -DBUILD_GUI=ON # It might take a while if the vcpkg binary cache is unpop
...
(https://github.com/bitcoin/bitcoin/pull/30454#issuecomment-2295367360)
Who is using my email to text you
I have been hacked
On Sun, Aug 18, 2024 at 20:30 Matt Whitlock ***@***.***>
wrote:
> ***@***.**** commented on this pull request.
> ------------------------------
>
> In doc/build-windows-msvc.md
> <https://github.com/bitcoin/bitcoin/pull/30454#discussion_r1721043065>:
>
> > +
> +### 4. Building with Dynamic Linking with GUI
> +
> +```
> +cmake -B build --preset vs2022 -DBUILD_GUI=ON # It might take a while if the vcpkg binary cache is unpop
...
π¬ johndpierre1 commented on pull request "build: Introduce CMake-based build system":
(https://github.com/bitcoin/bitcoin/pull/30454#issuecomment-2295367666)
I donβt know who Iβm talking to right now everything is confusing me here
John
On Sun, Aug 18, 2024 at 20:36 John D Pierre ***@***.***> wrote:
>
> Who is using my email to text you
> I have been hacked
>
>
> On Sun, Aug 18, 2024 at 20:30 Matt Whitlock ***@***.***>
> wrote:
>
>> ***@***.**** commented on this pull request.
>> ------------------------------
>>
>> In doc/build-windows-msvc.md
>> <https://github.com/bitcoin/bitcoin/pull/30454#discussion_r1721043065>:
>>
>> >
...
(https://github.com/bitcoin/bitcoin/pull/30454#issuecomment-2295367666)
I donβt know who Iβm talking to right now everything is confusing me here
John
On Sun, Aug 18, 2024 at 20:36 John D Pierre ***@***.***> wrote:
>
> Who is using my email to text you
> I have been hacked
>
>
> On Sun, Aug 18, 2024 at 20:30 Matt Whitlock ***@***.***>
> wrote:
>
>> ***@***.**** commented on this pull request.
>> ------------------------------
>>
>> In doc/build-windows-msvc.md
>> <https://github.com/bitcoin/bitcoin/pull/30454#discussion_r1721043065>:
>>
>> >
...
π¬ paplorinc commented on pull request "refactor: Replace ParseHex with consteval HexLiteral":
(https://github.com/bitcoin/bitcoin/pull/30377#discussion_r1721044730)
> But nice thing is neither of these should be necessary if cscript supports std::array
Would it be too early for me to provide a separate PR for that?
(https://github.com/bitcoin/bitcoin/pull/30377#discussion_r1721044730)
> But nice thing is neither of these should be necessary if cscript supports std::array
Would it be too early for me to provide a separate PR for that?
β
achow101 closed an issue: "Question on Changing Bitcoin Blockchain Data Directory in Linux Without Redownloading"
(https://github.com/bitcoin/bitcoin/issues/30672)
(https://github.com/bitcoin/bitcoin/issues/30672)
π¬ achow101 commented on issue "Question on Changing Bitcoin Blockchain Data Directory in Linux Without Redownloading":
(https://github.com/bitcoin/bitcoin/issues/30672#issuecomment-2295371762)
Usually the issue tracker is used to track technical issues related to the Bitcoin Core code base. General bitcoin questions and/or support requests are best directed to the [Bitcoin StackExchange](https://bitcoin.stackexchange.com) or the `#bitcoin` IRC channel on Libera Chat.
(https://github.com/bitcoin/bitcoin/issues/30672#issuecomment-2295371762)
Usually the issue tracker is used to track technical issues related to the Bitcoin Core code base. General bitcoin questions and/or support requests are best directed to the [Bitcoin StackExchange](https://bitcoin.stackexchange.com) or the `#bitcoin` IRC channel on Libera Chat.
π¬ sipsorcery commented on pull request "build: Introduce CMake-based build system":
(https://github.com/bitcoin/bitcoin/pull/30454#discussion_r1721048474)
> @sipsorcery: Rather than going on a treasure hunt, wouldn't you "install" the built product to a staging directory and then produce your distributable package from there? That way you'll pick up all the bits that the build system wants you to have and none that it doesn't.
I think that would be a reasonable soln. I'm used to the way msvc places all the executables in a single directory. GIven the `cmake --install` command provides an option to achieve the same that would work.
As mentio
...
(https://github.com/bitcoin/bitcoin/pull/30454#discussion_r1721048474)
> @sipsorcery: Rather than going on a treasure hunt, wouldn't you "install" the built product to a staging directory and then produce your distributable package from there? That way you'll pick up all the bits that the build system wants you to have and none that it doesn't.
I think that would be a reasonable soln. I'm used to the way msvc places all the executables in a single directory. GIven the `cmake --install` command provides an option to achieve the same that would work.
As mentio
...
π TheCharlatan approved a pull request: "validation: improve m_best_header tracking"
(https://github.com/bitcoin/bitcoin/pull/30666#pullrequestreview-2244388019)
ACK c9bf06a531617fdd70b64e23572931af2b969828
(https://github.com/bitcoin/bitcoin/pull/30666#pullrequestreview-2244388019)
ACK c9bf06a531617fdd70b64e23572931af2b969828
π¬ TheCharlatan commented on pull request "validation: improve m_best_header tracking":
(https://github.com/bitcoin/bitcoin/pull/30666#discussion_r1721048165)
It might be a good idea to expand this a bit:
```diff
@@ -45 +45 @@ class InvalidateTest(BitcoinTestFramework):
- tip = int(self.nodes[0].getbestblockhash(), 16)
+ tip = self.nodes[0].getbestblockhash()
@@ -47 +47 @@ class InvalidateTest(BitcoinTestFramework):
- block = create_block(tip, create_coinbase(self.nodes[0].getblockcount()), block_time, version=4)
+ block = create_block(int(tip, 16), create_coinbase(self.nodes[0].getblockcount()), block_time, version=
...
(https://github.com/bitcoin/bitcoin/pull/30666#discussion_r1721048165)
It might be a good idea to expand this a bit:
```diff
@@ -45 +45 @@ class InvalidateTest(BitcoinTestFramework):
- tip = int(self.nodes[0].getbestblockhash(), 16)
+ tip = self.nodes[0].getbestblockhash()
@@ -47 +47 @@ class InvalidateTest(BitcoinTestFramework):
- block = create_block(tip, create_coinbase(self.nodes[0].getblockcount()), block_time, version=4)
+ block = create_block(int(tip, 16), create_coinbase(self.nodes[0].getblockcount()), block_time, version=
...
π¬ hodlinator commented on pull request "test: Shut down framework cleanly on RPC connection failure":
(https://github.com/bitcoin/bitcoin/pull/30660#issuecomment-2295379703)
> Can you explain this a bit more? I think optimizing the test framework to cleanly shut down on a failure is a bit premature, and may not be needed.
As long as the additional complexity and maintenance burden is low, I think it is worth having a cleaner shutdown to avoid muddying the waters for people trying to figure out root causes.
> However, if a failing test may leave behind a dangling bitcoind process, this seems like something to fix, because it will otherwise lead to test warnings
...
(https://github.com/bitcoin/bitcoin/pull/30660#issuecomment-2295379703)
> Can you explain this a bit more? I think optimizing the test framework to cleanly shut down on a failure is a bit premature, and may not be needed.
As long as the additional complexity and maintenance burden is low, I think it is worth having a cleaner shutdown to avoid muddying the waters for people trying to figure out root causes.
> However, if a failing test may leave behind a dangling bitcoind process, this seems like something to fix, because it will otherwise lead to test warnings
...
π€ tdb3 reviewed a pull request: "addrman: change internal id counting to int64_t"
(https://github.com/bitcoin/bitcoin/pull/30568#pullrequestreview-2244390291)
Approach ACK
Reviewed a bit more. Just nits.
(https://github.com/bitcoin/bitcoin/pull/30568#pullrequestreview-2244390291)
Approach ACK
Reviewed a bit more. Just nits.
π¬ tdb3 commented on pull request "addrman: change internal id counting to int64_t":
(https://github.com/bitcoin/bitcoin/pull/30568#discussion_r1721050883)
nit: The return type in the Doxygen content could be adjusted.
```diff
- * @return int The nid of the entry. If the addrman position is empty or not found, returns -1.
+ * @return nid_type The nid of the entry. If the addrman position is empty or not found, returns -1.
* */
nid_type GetEntry(bool use_tried, size_t bucket, size_t position) const EXCLUSIVE_LOCKS_REQUIRED(cs);
```
nit / thinking out loud: Returning `-1` is a remnant of the previous type being a pla
...
(https://github.com/bitcoin/bitcoin/pull/30568#discussion_r1721050883)
nit: The return type in the Doxygen content could be adjusted.
```diff
- * @return int The nid of the entry. If the addrman position is empty or not found, returns -1.
+ * @return nid_type The nid of the entry. If the addrman position is empty or not found, returns -1.
* */
nid_type GetEntry(bool use_tried, size_t bucket, size_t position) const EXCLUSIVE_LOCKS_REQUIRED(cs);
```
nit / thinking out loud: Returning `-1` is a remnant of the previous type being a pla
...
π andrewtoth opened a pull request: "coins: remove logic for spent-and-FRESH cache entries and writing non-DIRTY entries"
(https://github.com/bitcoin/bitcoin/pull/30673)
Following up from https://github.com/bitcoin/bitcoin/pull/28280#discussion_r1655477509, which suggested a revival of #18746.
`GetCoin` will never return `true` for a spent entry, so we can safely assume that any entry we fetch will not be spent. This lets us remove the only non-test code path which adds a FRESH-but-not-DIRTY entry to the flagged linked list. This in turn ensures all entries being sent to `BatchWrite` are `DIRTY` entries.
This is a pure refactor removing dead code which han
...
(https://github.com/bitcoin/bitcoin/pull/30673)
Following up from https://github.com/bitcoin/bitcoin/pull/28280#discussion_r1655477509, which suggested a revival of #18746.
`GetCoin` will never return `true` for a spent entry, so we can safely assume that any entry we fetch will not be spent. This lets us remove the only non-test code path which adds a FRESH-but-not-DIRTY entry to the flagged linked list. This in turn ensures all entries being sent to `BatchWrite` are `DIRTY` entries.
This is a pure refactor removing dead code which han
...