💬 MarcoFalke commented on pull request "MaybePunishNodeForTx: Remove unused message arg and logging":
(https://github.com/bitcoin/bitcoin/pull/27947#issuecomment-1607064993)
lgtm ACK 9fe5f6d5d1ec31ebfacfe23368f22c2a0b58832d 🕚
<details><summary>Show signature</summary>
Signature:
```
untrusted comment: signature from minisign secret key on empty file; verify via: minisign -Vm "${path_to_any_empty_file}" -P RWTRmVTMeKV5noAMqVlsMugDDCyyTSbA3Re5AkUrhvLVln0tSaFWglOw -x "${path_to_this_whole_four_line_signature_blob}"
RUTRmVTMeKV5npGrKx1nqXCw5zeVHdtdYURB/KlyA/LMFgpNCs+SkW9a8N95d+U4AP1RJMi+krxU1A3Yux4bpwZNLvVBKy0wLgM=
trusted comment: lgtm ACK 9fe5f6d5d1ec31eb
...
(https://github.com/bitcoin/bitcoin/pull/27947#issuecomment-1607064993)
lgtm ACK 9fe5f6d5d1ec31ebfacfe23368f22c2a0b58832d 🕚
<details><summary>Show signature</summary>
Signature:
```
untrusted comment: signature from minisign secret key on empty file; verify via: minisign -Vm "${path_to_any_empty_file}" -P RWTRmVTMeKV5noAMqVlsMugDDCyyTSbA3Re5AkUrhvLVln0tSaFWglOw -x "${path_to_this_whole_four_line_signature_blob}"
RUTRmVTMeKV5npGrKx1nqXCw5zeVHdtdYURB/KlyA/LMFgpNCs+SkW9a8N95d+U4AP1RJMi+krxU1A3Yux4bpwZNLvVBKy0wLgM=
trusted comment: lgtm ACK 9fe5f6d5d1ec31eb
...
💬 fanquake commented on pull request "Autogen 25.x":
(https://github.com/bitcoin/bitcoin/pull/27938#issuecomment-1607066605)
Thanks for the pull request, however it's unlikely we are going to make significant (refactoring) changes to our autotools based build system at this point.
(https://github.com/bitcoin/bitcoin/pull/27938#issuecomment-1607066605)
Thanks for the pull request, however it's unlikely we are going to make significant (refactoring) changes to our autotools based build system at this point.
✅ fanquake closed a pull request: "Autogen 25.x"
(https://github.com/bitcoin/bitcoin/pull/27938)
(https://github.com/bitcoin/bitcoin/pull/27938)
💬 tansanDOTeth commented on issue "Keep getting errors after a while of syncing":
(https://github.com/bitcoin/bitcoin/issues/27972#issuecomment-1607082182)
I tried reindexing since I posted this and I got this:
> 023-06-26T09:16:24Z UpdateTip: new best=00000000000000000c93572c7fcf0ccc927b5fb00039e90d1550327d6d83552f height=368600 version=0x00000003 log2_work=83.174292 tx=78966308 date='2015-08-06T04:29:51Z' progress=0.093234 cache=380.0MiB(2905123txo)
2023-06-26T09:16:25Z UpdateTip: new best=00000000000000000be13a49f9c0852b6c2c773efc816afadf4b2328bebc1b0f height=368601 version=0x00000003 log2_work=83.174322 tx=78967060 date='2015-08-06T04:36:12
...
(https://github.com/bitcoin/bitcoin/issues/27972#issuecomment-1607082182)
I tried reindexing since I posted this and I got this:
> 023-06-26T09:16:24Z UpdateTip: new best=00000000000000000c93572c7fcf0ccc927b5fb00039e90d1550327d6d83552f height=368600 version=0x00000003 log2_work=83.174292 tx=78966308 date='2015-08-06T04:29:51Z' progress=0.093234 cache=380.0MiB(2905123txo)
2023-06-26T09:16:25Z UpdateTip: new best=00000000000000000be13a49f9c0852b6c2c773efc816afadf4b2328bebc1b0f height=368601 version=0x00000003 log2_work=83.174322 tx=78967060 date='2015-08-06T04:36:12
...
💬 fanquake commented on issue "deadlock shutting down v25.0":
(https://github.com/bitcoin/bitcoin/issues/27965#issuecomment-1607090365)
@Crypt-iQ possibly similar to issues you've been seeing?
(https://github.com/bitcoin/bitcoin/issues/27965#issuecomment-1607090365)
@Crypt-iQ possibly similar to issues you've been seeing?
🚀 fanquake merged a pull request: "MaybePunishNodeForTx: Remove unused message arg and logging"
(https://github.com/bitcoin/bitcoin/pull/27947)
(https://github.com/bitcoin/bitcoin/pull/27947)
💬 MarcoFalke commented on issue "Keep getting errors after a while of syncing":
(https://github.com/bitcoin/bitcoin/issues/27972#issuecomment-1607094114)
Has anyone ever put the leveldb directory successfully on an external drive, I am not sure if this is even supported by leveldb?
(https://github.com/bitcoin/bitcoin/issues/27972#issuecomment-1607094114)
Has anyone ever put the leveldb directory successfully on an external drive, I am not sure if this is even supported by leveldb?
💬 MarcoFalke commented on issue "Keep getting errors after a while of syncing":
(https://github.com/bitcoin/bitcoin/issues/27972#issuecomment-1607099769)
In the meantime you can test your storage device use smartctl or CrystalDiskInfo to rule out any hardware defects.
(https://github.com/bitcoin/bitcoin/issues/27972#issuecomment-1607099769)
In the meantime you can test your storage device use smartctl or CrystalDiskInfo to rule out any hardware defects.
💬 tansanDOTeth commented on issue "Keep getting errors after a while of syncing":
(https://github.com/bitcoin/bitcoin/issues/27972#issuecomment-1607102513)
> In the meantime you can test your storage device use smartctl or CrystalDiskInfo to rule out any hardware defects.
I'll give that a try and report back
(https://github.com/bitcoin/bitcoin/issues/27972#issuecomment-1607102513)
> In the meantime you can test your storage device use smartctl or CrystalDiskInfo to rule out any hardware defects.
I'll give that a try and report back
💬 joostjager commented on pull request "policy: make unstructured annex standard":
(https://github.com/bitcoin/bitcoin/pull/27926#discussion_r1241919261)
My thought was that it might be good to choose a number of actually useable bytes that is a multiple of a commonly used data structure sizes such as 32 bytes. Therefore 256. It is an arbitrary number though that it supposed to strike a balance between the limiting the potency of annex inflation attacks and having enough space to make the annex useful.
Are you proposing to limit the annex size including any tags to 257 bytes? I see the conceptual difference, but there wouldn't be a functional
...
(https://github.com/bitcoin/bitcoin/pull/27926#discussion_r1241919261)
My thought was that it might be good to choose a number of actually useable bytes that is a multiple of a commonly used data structure sizes such as 32 bytes. Therefore 256. It is an arbitrary number though that it supposed to strike a balance between the limiting the potency of annex inflation attacks and having enough space to make the annex useful.
Are you proposing to limit the annex size including any tags to 257 bytes? I see the conceptual difference, but there wouldn't be a functional
...
💬 joostjager commented on pull request "policy: make unstructured annex standard":
(https://github.com/bitcoin/bitcoin/pull/27926#discussion_r1241927265)
With the constant defined as suggested below, this suggestion does seem to make reading easier. Changed.
(https://github.com/bitcoin/bitcoin/pull/27926#discussion_r1241927265)
With the constant defined as suggested below, this suggestion does seem to make reading easier. Changed.
👍 fanquake approved a pull request: "macOS: Bump minimum required runtime version and prepare for building with upstream LLVM"
(https://github.com/bitcoin/bitcoin/pull/27676#pullrequestreview-1498126174)
ACK 3df60704661cdb5e61ea2b999f468f3a1d16105f
(https://github.com/bitcoin/bitcoin/pull/27676#pullrequestreview-1498126174)
ACK 3df60704661cdb5e61ea2b999f468f3a1d16105f
💬 joostjager commented on pull request "policy: make unstructured annex standard":
(https://github.com/bitcoin/bitcoin/pull/27926#discussion_r1241936380)
Added `MAX_PER_INPUT_ANNEX_SIZE`.
Not sure if a per tx maximum is necessary. I'd say that opting in to annex usage has some risks to be aware of. Maybe you don't want to use it for multi-party protocols at all because of that. To me, `MAX_PER_INPUT_ANNEX_SIZE` is already debatable when you have opt-in, and `MAX_ANNEX_BUDGET` feels even more like an unnecessary precaution. In the end, this is all policy.
(https://github.com/bitcoin/bitcoin/pull/27926#discussion_r1241936380)
Added `MAX_PER_INPUT_ANNEX_SIZE`.
Not sure if a per tx maximum is necessary. I'd say that opting in to annex usage has some risks to be aware of. Maybe you don't want to use it for multi-party protocols at all because of that. To me, `MAX_PER_INPUT_ANNEX_SIZE` is already debatable when you have opt-in, and `MAX_ANNEX_BUDGET` feels even more like an unnecessary precaution. In the end, this is all policy.
💬 joostjager commented on pull request "policy: make unstructured annex standard":
(https://github.com/bitcoin/bitcoin/pull/27926#discussion_r1241938735)
Which DoS concerns are you referring to? Since #24007 hasn't landed yet, the tx can only be accepted once?
(https://github.com/bitcoin/bitcoin/pull/27926#discussion_r1241938735)
Which DoS concerns are you referring to? Since #24007 hasn't landed yet, the tx can only be accepted once?
💬 joostjager commented on pull request "policy: make unstructured annex standard":
(https://github.com/bitcoin/bitcoin/pull/27926#discussion_r1241941706)
My answer here would be the same as in https://github.com/bitcoin/bitcoin/pull/27926#discussion_r1241936380. I think you can argue that opt-in is enough protection and multi-party flows with annexes may not be a good idea. Especially if there are no concrete plans for multi-party protocols that require the unique properties of the annex.
(https://github.com/bitcoin/bitcoin/pull/27926#discussion_r1241941706)
My answer here would be the same as in https://github.com/bitcoin/bitcoin/pull/27926#discussion_r1241936380. I think you can argue that opt-in is enough protection and multi-party flows with annexes may not be a good idea. Especially if there are no concrete plans for multi-party protocols that require the unique properties of the annex.
💬 joostjager commented on pull request "policy: make unstructured annex standard":
(https://github.com/bitcoin/bitcoin/pull/27926#discussion_r1241944433)
Happy to do it if others agree that the current annex check isn't too minimal for its own file.
(https://github.com/bitcoin/bitcoin/pull/27926#discussion_r1241944433)
Happy to do it if others agree that the current annex check isn't too minimal for its own file.
💬 MarcoFalke commented on issue "Indefinite "Bitcoin Core is shutting down..."":
(https://github.com/bitcoin/bitcoin/issues/27848#issuecomment-1607185201)
Makes sense, but then it seems a duplicate of #27965, which also still has the scheduler thread running (and more debug info)?
(https://github.com/bitcoin/bitcoin/issues/27848#issuecomment-1607185201)
Makes sense, but then it seems a duplicate of #27965, which also still has the scheduler thread running (and more debug info)?
💬 MarcoFalke commented on issue "deadlock shutting down v25.0":
(https://github.com/bitcoin/bitcoin/issues/27965#issuecomment-1607197525)
Looks like the deadlock in the shutoff thread is here?
https://github.com/bitcoin/bitcoin/blob/642b5dd1b4fc5788ec7ab162a7c6ce0b96e7a6e4/src/httpserver.cpp#L481-L486
So maybe this is related to https://github.com/bitcoin/bitcoin/issues/27722 ?
(https://github.com/bitcoin/bitcoin/issues/27965#issuecomment-1607197525)
Looks like the deadlock in the shutoff thread is here?
https://github.com/bitcoin/bitcoin/blob/642b5dd1b4fc5788ec7ab162a7c6ce0b96e7a6e4/src/httpserver.cpp#L481-L486
So maybe this is related to https://github.com/bitcoin/bitcoin/issues/27722 ?
💬 MarcoFalke commented on issue "deadlock shutting down v25.0":
(https://github.com/bitcoin/bitcoin/issues/27965#issuecomment-1607204268)
However, I don't see how the debug log and the gdb output are matching. The debug log claims that the net and msghand thread have been stopped, but that only happens in connman->Stop, in a line after `StopHTTPServer()`, which is the current point in gdb:
```
Thread 22 (Thread 0x7fffa16fe700 (LWP 584804) "b-shutoff"):
#0 futex_wait_cancelable (private=0, expected=0, futex_word=0x5555570e4be8 <g_requests_cv+40>) at ../sysdeps/nptl/futex-internal.h:186
#1 __pthread_cond_wait_common (abstime
...
(https://github.com/bitcoin/bitcoin/issues/27965#issuecomment-1607204268)
However, I don't see how the debug log and the gdb output are matching. The debug log claims that the net and msghand thread have been stopped, but that only happens in connman->Stop, in a line after `StopHTTPServer()`, which is the current point in gdb:
```
Thread 22 (Thread 0x7fffa16fe700 (LWP 584804) "b-shutoff"):
#0 futex_wait_cancelable (private=0, expected=0, futex_word=0x5555570e4be8 <g_requests_cv+40>) at ../sysdeps/nptl/futex-internal.h:186
#1 __pthread_cond_wait_common (abstime
...
💬 Crypt-iQ commented on issue "deadlock shutting down v25.0":
(https://github.com/bitcoin/bitcoin/issues/27965#issuecomment-1607205825)
Yeah I think the thread exits confused me since torcontrol, connman are stopped after the httpserver. I think those log lines mean the threads were interrupted and exited their loop (hence the exit log line) and are now joinable. So I think it's a dupe. If you look at #27722 you'll see that the tor control thread, msghand thread have exited as well
(https://github.com/bitcoin/bitcoin/issues/27965#issuecomment-1607205825)
Yeah I think the thread exits confused me since torcontrol, connman are stopped after the httpserver. I think those log lines mean the threads were interrupted and exited their loop (hence the exit log line) and are now joinable. So I think it's a dupe. If you look at #27722 you'll see that the tor control thread, msghand thread have exited as well