💬 sipa commented on issue "Restarting Development on BIP-199":
(https://github.com/bitcoin/bitcoin/issues/32126#issuecomment-2746507262)
> I'd like to use pay-to-public key addresses to implement the feature so that the full script is on-chain.
If it's a pay-to-pubkey address, it's not an HTLC.
(https://github.com/bitcoin/bitcoin/issues/32126#issuecomment-2746507262)
> I'd like to use pay-to-public key addresses to implement the feature so that the full script is on-chain.
If it's a pay-to-pubkey address, it's not an HTLC.
💬 k26dr commented on issue "Restarting Development on BIP-199":
(https://github.com/bitcoin/bitcoin/issues/32126#issuecomment-2746510169)
Pay-to-public key which just stick the script on-chain, no? @sipa
(https://github.com/bitcoin/bitcoin/issues/32126#issuecomment-2746510169)
Pay-to-public key which just stick the script on-chain, no? @sipa
💬 sipa commented on issue "Restarting Development on BIP-199":
(https://github.com/bitcoin/bitcoin/issues/32126#issuecomment-2746510364)
Well, yes, but it would be a pay-to-pubkey script, not an HTLC script?
(https://github.com/bitcoin/bitcoin/issues/32126#issuecomment-2746510364)
Well, yes, but it would be a pay-to-pubkey script, not an HTLC script?
💬 k26dr commented on issue "Restarting Development on BIP-199":
(https://github.com/bitcoin/bitcoin/issues/32126#issuecomment-2746511168)
As I understand it, this is an HTLC script:
```
OP_IF
[HASHOP] <digest> OP_EQUALVERIFY OP_DUP OP_HASH160 <seller pubkey hash>
OP_ELSE
<num> [TIMEOUTOP] OP_DROP OP_DUP OP_HASH160 <buyer pubkey hash>
OP_ENDIF
OP_EQUALVERIFY
OP_CHECKSIG
```
and if this was put on-chain as a pay-to-pubkey script it would still work without breaking consensus.
If this is true, I'm cool with that.
(https://github.com/bitcoin/bitcoin/issues/32126#issuecomment-2746511168)
As I understand it, this is an HTLC script:
```
OP_IF
[HASHOP] <digest> OP_EQUALVERIFY OP_DUP OP_HASH160 <seller pubkey hash>
OP_ELSE
<num> [TIMEOUTOP] OP_DROP OP_DUP OP_HASH160 <buyer pubkey hash>
OP_ENDIF
OP_EQUALVERIFY
OP_CHECKSIG
```
and if this was put on-chain as a pay-to-pubkey script it would still work without breaking consensus.
If this is true, I'm cool with that.
💬 k26dr commented on issue "Restarting Development on BIP-199":
(https://github.com/bitcoin/bitcoin/issues/32126#issuecomment-2746512093)
If P2WSH is the preferred implementation, I'm cool with that too. I'm just trying to understand why pay-to-pubkey script would be an issue.
(https://github.com/bitcoin/bitcoin/issues/32126#issuecomment-2746512093)
If P2WSH is the preferred implementation, I'm cool with that too. I'm just trying to understand why pay-to-pubkey script would be an issue.
💬 k26dr commented on issue "Restarting Development on BIP-199":
(https://github.com/bitcoin/bitcoin/issues/32126#issuecomment-2746513255)
The NPM implementation uses P2WSH, so I'm not unfamiliar with that methodology. I just ran into the issue that if you lose the witness script, you lose the ability to claim the HTLC.
(https://github.com/bitcoin/bitcoin/issues/32126#issuecomment-2746513255)
The NPM implementation uses P2WSH, so I'm not unfamiliar with that methodology. I just ran into the issue that if you lose the witness script, you lose the ability to claim the HTLC.
💬 sipa commented on issue "Restarting Development on BIP-199":
(https://github.com/bitcoin/bitcoin/issues/32126#issuecomment-2746517066)
"Pay to pubkey" (P2PK) means a "<pubkey> OP_CHECKSIG" script, nothing else. I think what you mean is what I'd call a "bare HTLC script", i.e., putting the script you give above directly in the `scriptPubKey`?
Terminology aside, this is problematic for several reasons:
* There exist no addresses for HTLC scripts (BIP199 or otherwise), you'd need to introduce a new address format for this to work or nobody can send to it. Previous experience shows that this is a multi-year process, at least (even
...
(https://github.com/bitcoin/bitcoin/issues/32126#issuecomment-2746517066)
"Pay to pubkey" (P2PK) means a "<pubkey> OP_CHECKSIG" script, nothing else. I think what you mean is what I'd call a "bare HTLC script", i.e., putting the script you give above directly in the `scriptPubKey`?
Terminology aside, this is problematic for several reasons:
* There exist no addresses for HTLC scripts (BIP199 or otherwise), you'd need to introduce a new address format for this to work or nobody can send to it. Previous experience shows that this is a multi-year process, at least (even
...
✅ k26dr closed an issue: "Restarting Development on BIP-199"
(https://github.com/bitcoin/bitcoin/issues/32126)
(https://github.com/bitcoin/bitcoin/issues/32126)
💬 k26dr commented on issue "Restarting Development on BIP-199":
(https://github.com/bitcoin/bitcoin/issues/32126#issuecomment-2746518848)
Ok fair enough. If a future BIP takes care of this, I'll close the issue. Thanks for the explanation.
(https://github.com/bitcoin/bitcoin/issues/32126#issuecomment-2746518848)
Ok fair enough. If a future BIP takes care of this, I'll close the issue. Thanks for the explanation.
💬 fjahr commented on pull request "[EXPERIMENTAL] Schnorr batch verification for blocks":
(https://github.com/bitcoin/bitcoin/pull/29491#discussion_r2009282526)
> Instead of a bucket per thread, have a batch per thread. However, instead of batch verifying after each vChecks batch, batch verify after the queue of checks is empty for the block. We need CCheckQueue::Complete to set a flag that no more checks will be added, and wake all threads again. The threads will all verify their batches once the global queue is empty. We would need to reset the flag after Complete.
Yes, one batch per thread is the approach I mentioned above as well as preferred, if
...
(https://github.com/bitcoin/bitcoin/pull/29491#discussion_r2009282526)
> Instead of a bucket per thread, have a batch per thread. However, instead of batch verifying after each vChecks batch, batch verify after the queue of checks is empty for the block. We need CCheckQueue::Complete to set a flag that no more checks will be added, and wake all threads again. The threads will all verify their batches once the global queue is empty. We would need to reset the flag after Complete.
Yes, one batch per thread is the approach I mentioned above as well as preferred, if
...
📝 Elmarinero1983 opened a pull request: "5e8bc97cdc6dd8d7be10f0ac8c1b46d2c2fd1547"
(https://github.com/bitcoin/bitcoin/pull/32127)
<!--
*** Please remove the following help text before submitting: ***
Pull requests without a rationale and clear improvement may be closed
immediately.
GUI-related pull requests should be opened against
https://github.com/bitcoin-core/gui
first. See CONTRIBUTING.md
-->
<!--
Please provide clear motivation for your patch and explain how it improves
Bitcoin Core user experience or Bitcoin Core developer experience
significantly:
* Any test improvements or new tests that improv
...
(https://github.com/bitcoin/bitcoin/pull/32127)
<!--
*** Please remove the following help text before submitting: ***
Pull requests without a rationale and clear improvement may be closed
immediately.
GUI-related pull requests should be opened against
https://github.com/bitcoin-core/gui
first. See CONTRIBUTING.md
-->
<!--
Please provide clear motivation for your patch and explain how it improves
Bitcoin Core user experience or Bitcoin Core developer experience
significantly:
* Any test improvements or new tests that improv
...
✅ fanquake closed a pull request: "5e8bc97cdc6dd8d7be10f0ac8c1b46d2c2fd1547"
(https://github.com/bitcoin/bitcoin/pull/32127)
(https://github.com/bitcoin/bitcoin/pull/32127)
💬 frankomosh commented on issue "29.0 RC Testing Guide Feedback":
(https://github.com/bitcoin/bitcoin/issues/32026#issuecomment-2746971852)
> This issue is to discuss the [29.0 Release Candidate Testing Guide](https://github.com/bitcoin-core/bitcoin-devwiki/wiki/29.0-Release-Candidate-Testing-Guide). If you have any feedback on the document, please leave a comment here.
>
> Note: This is for feedback on the document, not on Bitcoin Core or on the 29.0 changes.
>
> Thank you for taking a look at the guide and leaving your feedback.
>
> ps. The initial page was co-authored-by: [@arejula27](https://github.com/arejula27) [@musaHaruna
...
(https://github.com/bitcoin/bitcoin/issues/32026#issuecomment-2746971852)
> This issue is to discuss the [29.0 Release Candidate Testing Guide](https://github.com/bitcoin-core/bitcoin-devwiki/wiki/29.0-Release-Candidate-Testing-Guide). If you have any feedback on the document, please leave a comment here.
>
> Note: This is for feedback on the document, not on Bitcoin Core or on the 29.0 changes.
>
> Thank you for taking a look at the guide and leaving your feedback.
>
> ps. The initial page was co-authored-by: [@arejula27](https://github.com/arejula27) [@musaHaruna
...
📝 martinus opened a pull request: "Draft: CCoinMap Experiments"
(https://github.com/bitcoin/bitcoin/pull/32128)
This is a draft PR to show various possible optimizations for `CCoinsMap`. In my benchmark, all these changes lead to a statistically significant speed improvement for `-reindex-chainstate`.
```
Benchmark 1: ./build/bin/bitcoind -stopatheight=600000 -dbcache=5000 -printtoconsole=0 -reindex-chainstate -noconnect -connect=192.168.8.118 (COMMIT = ac188b573c8)
Time (mean ± σ): 2089.253 s ± 23.737 s [User: 2110.111 s, System: 299.197 s]
Range (min … max): 2062.751 s … 2108.561 s
...
(https://github.com/bitcoin/bitcoin/pull/32128)
This is a draft PR to show various possible optimizations for `CCoinsMap`. In my benchmark, all these changes lead to a statistically significant speed improvement for `-reindex-chainstate`.
```
Benchmark 1: ./build/bin/bitcoind -stopatheight=600000 -dbcache=5000 -printtoconsole=0 -reindex-chainstate -noconnect -connect=192.168.8.118 (COMMIT = ac188b573c8)
Time (mean ± σ): 2089.253 s ± 23.737 s [User: 2110.111 s, System: 299.197 s]
Range (min … max): 2062.751 s … 2108.561 s
...
💬 maflcko commented on pull request "signet: omit commitment for some trivial challenges":
(https://github.com/bitcoin/bitcoin/pull/29032#discussion_r2009586472)
https://cirrus-ci.com/task/5609902313308160?logs=ci#L5104
```
[20:25:29.234] test 2025-03-24T00:25:28.624000Z TestFramework (ERROR): Called Process failed with 'b'''
[20:25:29.234] Traceback (most recent call last):
[20:25:29.234] File "/ci_container_base/test/functional/test_framework/test_framework.py", line 178, in main
[20:25:29.234] self.run_test()
[20:25:29.234]
...
(https://github.com/bitcoin/bitcoin/pull/29032#discussion_r2009586472)
https://cirrus-ci.com/task/5609902313308160?logs=ci#L5104
```
[20:25:29.234] test 2025-03-24T00:25:28.624000Z TestFramework (ERROR): Called Process failed with 'b'''
[20:25:29.234] Traceback (most recent call last):
[20:25:29.234] File "/ci_container_base/test/functional/test_framework/test_framework.py", line 178, in main
[20:25:29.234] self.run_test()
[20:25:29.234]
...
💬 maflcko commented on issue "Wallet passpharse":
(https://github.com/bitcoin/bitcoin/issues/31852#issuecomment-2747136359)
Now that 29.0 is in the release phase, you could also try that: https://bitcoincore.org/bin/bitcoin-core-29.0/test.rc2/ (It is the rc, so only use it for testing and after making a backup, etc ...)
(https://github.com/bitcoin/bitcoin/issues/31852#issuecomment-2747136359)
Now that 29.0 is in the release phase, you could also try that: https://bitcoincore.org/bin/bitcoin-core-29.0/test.rc2/ (It is the rc, so only use it for testing and after making a backup, etc ...)
💬 Sjors commented on pull request "signet: omit commitment for some trivial challenges":
(https://github.com/bitcoin/bitcoin/pull/29032#discussion_r2009614780)
I can reproduce this once I rebase on the latest master. I'll investigate.
(https://github.com/bitcoin/bitcoin/pull/29032#discussion_r2009614780)
I can reproduce this once I rebase on the latest master. I'll investigate.
💬 maflcko commented on pull request "fuzz: Fix off-by-one in package_rbf target":
(https://github.com/bitcoin/bitcoin/pull/32122#issuecomment-2747190493)
> why not just modify `initialize_package_rbf` to use this statement
Why would that be better? Once an off-by-two is added in a future patch, the fuzz target once again will crash, whereas with the patch in this pull, it will work fine?
(https://github.com/bitcoin/bitcoin/pull/32122#issuecomment-2747190493)
> why not just modify `initialize_package_rbf` to use this statement
Why would that be better? Once an off-by-two is added in a future patch, the fuzz target once again will crash, whereas with the patch in this pull, it will work fine?
💬 Sjors commented on pull request "signet: omit commitment for some trivial challenges":
(https://github.com/bitcoin/bitcoin/pull/29032#discussion_r2009667758)
It seems to be caused by #31866, because the test passes when I revert it.
(https://github.com/bitcoin/bitcoin/pull/29032#discussion_r2009667758)
It seems to be caused by #31866, because the test passes when I revert it.
💬 maflcko commented on pull request "signet: omit commitment for some trivial challenges":
(https://github.com/bitcoin/bitcoin/pull/29032#discussion_r2009685207)
You'll have to use `node.binaries.rpc_argv()` instead here
(https://github.com/bitcoin/bitcoin/pull/29032#discussion_r2009685207)
You'll have to use `node.binaries.rpc_argv()` instead here