bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
davterra has joined #bitcoin-core-dev
mikehu44_ has quit [Ping timeout: 264 seconds]
bitdex has quit [Remote host closed the connection]
bitdex has joined #bitcoin-core-dev
mikehu44 has quit [Ping timeout: 260 seconds]
b10c has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
Guest73 has joined #bitcoin-core-dev
gene has joined #bitcoin-core-dev
Guest73 has quit [Ping timeout: 256 seconds]
___nick___ has joined #bitcoin-core-dev
___nick___ has quit [Client Quit]
___nick___ has joined #bitcoin-core-dev
bomb-on has joined #bitcoin-core-dev
dviola has quit [Quit: WeeChat 3.3]
dviola has joined #bitcoin-core-dev
Talkless has joined #bitcoin-core-dev
grettke has joined #bitcoin-core-dev
jarthur has joined #bitcoin-core-dev
dviola has quit [Quit: WeeChat 3.3]
bairen has joined #bitcoin-core-dev
yanmaani has joined #bitcoin-core-dev
paulo has quit [Remote host closed the connection]
meshcollider has quit [Remote host closed the connection]
RDK has quit [Quit: Leaving]
meshcollider has joined #bitcoin-core-dev
paulo has joined #bitcoin-core-dev
Guyver2 has left #bitcoin-core-dev [Closing Window]
jespada has joined #bitcoin-core-dev
jespada has quit [Client Quit]
brunoerg has quit [Quit: Client closed]
brunoerg has joined #bitcoin-core-dev
jespada has joined #bitcoin-core-dev
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] dougEfresh closed pull request #23344: ci: Reuse pre-built docker builder image for rapid local CI iteration testing (master...ci_reuse_container) https://github.com/bitcoin/bitcoin/pull/23344
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
Talkless has quit [Quit: Konversation terminated!]
<theStack>
taproot question: i'm just trying to convert a simple P2WSH script (OP_TRUE, i.e. any-one-can-spend) to P2TR. what would one choose as internal key in this case, if key-path spending is not used? i guess it doesn't matter that much, as long as it's a valid x-only-pubkey?
<sipa>
theStack: BIP341 has recommendations
<theStack>
sipa: thanks, will take a look
white5moke has quit [Quit: Leaving...]
bairen has quit [Remote host closed the connection]
bairen has joined #bitcoin-core-dev
smartin has quit [Quit: smartin]
brunoerg has quit [Quit: Client closed]
lukedashjr has joined #bitcoin-core-dev
___nick___ has quit [Ping timeout: 260 seconds]
luke-jr has quit [Ping timeout: 260 seconds]
lukedashjr is now known as luke-jr
b10c has quit [Quit: Connection closed for inactivity]
lukedashjr has joined #bitcoin-core-dev
luke-jr has quit [Ping timeout: 260 seconds]
lukedashjr is now known as luke-jr
ishi has joined #bitcoin-core-dev
lukedashjr has joined #bitcoin-core-dev
luke-jr has quit [Ping timeout: 260 seconds]
lukedashjr is now known as luke-jr
ishaqm has quit [Remote host closed the connection]
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
bitdex has quit [Ping timeout: 276 seconds]
bitdex has joined #bitcoin-core-dev
bitdex has quit [Client Quit]
bitdex has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Quit: Client closed]
luke-jr has quit [Ping timeout: 260 seconds]
lukedashjr has joined #bitcoin-core-dev
lukedashjr is now known as luke-jr
Kaizen_K_ has joined #bitcoin-core-dev
Kaizen___ has joined #bitcoin-core-dev
Kaizen_Kintsugi has quit [Ping timeout: 264 seconds]
Kaizen_K_ has quit [Ping timeout: 260 seconds]
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] mzumsande opened pull request #23365: index: Fix backwards search for bestblock (master...202110_index_backtrack) https://github.com/bitcoin/bitcoin/pull/23365
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
jespada has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<_aj_>
sipa: conditional code with ranges or a fallback? i was just meaning once we switched everything to c++20 in a few years, that's a cool thing we could use. if we were really excited, we could also include the ranges library backported to c++17, but meh. conditional code seems nuts?
<_aj_>
sipa: once we switched to c++20 as the minimum standard, i mean
<sipa>
_aj_: oh sure, once we switch to depending on c++20, using ranges goes from nuts to go nuts
<sipa>
but that seems like a discussion for a reasonably far future that we don't need to care
<_aj_>
sipa: yeah, that's how i took that entire issue. ah, i guess i see how you went from my "can't rely" to "just make it conditional then", my bad
<sipa>
but say, something that lets us switch to a safer (stricter types e.g.) interface for Span in C++20, would perhaps be worth it
<sipa>
even conditionally
<sipa>
even if that adds conditional code, it may help catch bugs in caller code that's not C++20 specific
<_aj_>
as long as it's not conditional at every call site, sure
<sipa>
actually, we can probably modernize Span using some C++17 features already
<sipa>
ah, no, it needs C++20
<sipa>
/** Construct a span from a begin and end pointer.
<sipa>
*
<sipa>
* This implements a subset of the iterator-based std::span constructor in C++20,
<sipa>
* which is hard to implement without std::address_of.
<sipa>
yes, but that's for the range interface, which _would_ require conditional code on the caller side
<sipa>
right?
<_aj_>
maybe? i've been trying to avoid learning anything about c++20 so i don't feel sad that i can't use the features for years
<cfields>
23226 turns some range compilation failures into valid code. But it only has any meaning when the caller is c++20.
<sipa>
i'm wrong about the code i quoted too
<sipa>
the currently supported interface is a strict subset of what is allowed by the C++20 std::span constructor
<sipa>
so enabling it in C++20 mode doesn't add anything for non-C++20 callers
sipsorcery has quit [Ping timeout: 260 seconds]
<cfields>
for that PR, correct. It's only useful for playing with c++20.
<cfields>
I guess you two are discussing conditionally adding the c++20 ctors and other functionality if in c++20 mode?
Guest80 has joined #bitcoin-core-dev
Guest80 has quit [Client Quit]
<sipa>
i think that was mostly a tangent i got on, thinking it would be an actual benefit to non-C++20-code, to add the full iterators-based Span constructor in C++20 mode
<sipa>
but i was wrong
<sipa>
adding concepts-based checks could be useful though
<sipa>
in that it may give nicer compiler error messages
<_aj_>
you'd only get nicer compiler error messages if you did your dev with c++20 enabled, which would then not give you errors at all when you use non-c++17 features?
<sipa>
in theory, possibly
<sipa>
but in practice, almost certainly yes, only an inscrutible wall of errors
<_aj_>
well, it's still c++? :)
<sipa>
if you're not familiar with concepts: e.g. you're instantiating an std::map with a type that doesn't have an operator<
<sipa>
due to SFINAE, you don't get an error when instantiating the type, but in the call site where that actually is a problem (e.g. insertion), and then really the compiler error is just "i tried all of these things to make it work, but none work"
<sipa>
with concepts, the type itself can get a compile-time constraint on properties its template parameters must have