<bitcoin-git>
bitcoin/master f6f18ee Andrew Chow: guix: Zip needs to include all files with time as SOURCE_DATE_EPOCH
<bitcoin-git>
bitcoin/master 697ded9 fanquake: Merge bitcoin/bitcoin#28757: guix: Zip needs to include all files and set ...
<bitcoin-git>
[bitcoin] fanquake merged pull request #28757: guix: Zip needs to include all files and set time to SOURCE_DATE_EPOCH (master...macos-zip-recursive) https://github.com/bitcoin/bitcoin/pull/28757
<bitcoin-git>
[bitcoin] jonatack reopened pull request #28749: test: add peer connection unit test coverage (master...2023-10-net_peer_connection_tests) https://github.com/bitcoin/bitcoin/pull/28749
qxs has quit [Ping timeout: 256 seconds]
qxs has joined #bitcoin-core-dev
qxs has quit [Remote host closed the connection]
m3dwards has joined #bitcoin-core-dev
qxs has joined #bitcoin-core-dev
qxs has quit [Remote host closed the connection]
qxs has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] jonatack closed pull request #28749: test: add peer connection unit test coverage (master...2023-10-net_peer_connection_tests) https://github.com/bitcoin/bitcoin/pull/28749
meshcollider has quit [Quit: :wave:]
brunoerg has joined #bitcoin-core-dev
Talkless has joined #bitcoin-core-dev
meshcollider has joined #bitcoin-core-dev
PaperSword has quit [Quit: PaperSword]
m3dwards has left #bitcoin-core-dev [#bitcoin-core-dev]
vysn has joined #bitcoin-core-dev
puchka1101 has quit [Ping timeout: 255 seconds]
brunoerg has quit [Remote host closed the connection]
<bitcoin-git>
[bitcoin] instagibbs opened pull request #28764: Fuzz: Check individual and package transaction invariants (master...fuzz_atmp_invariants) https://github.com/bitcoin/bitcoin/pull/28764
vasild has quit [Ping timeout: 256 seconds]
vasild has joined #bitcoin-core-dev
kevkevin_ has joined #bitcoin-core-dev
kevkevin has quit [Ping timeout: 252 seconds]
vasild has quit [Remote host closed the connection]
vasild has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
<stevenroose>
Got a question about how OP_CHECKSIG evaluation works. I'm trying to read the interpreter.cpp code, but I can't seem to find the codepath where OP_CHECKSIG (not VERIFY) leaves a 0 on the stack. It seems to either return false which halts execution or return true and set success to true.
<stevenroose>
In EvalChecksigTapscript the success bool is set to !sig.empty() and then never changed, but false is always returned on any error path.
<stevenroose>
In the pre-taproot version of the check, it seems that it's possible to return 0, when SCRIPT_VERIFY_NULLFAIL is not set
<stevenroose>
sipa, you might be familiar with this code, sorry to bother :)
<stevenroose>
Is that a consensus rule I'm not aware of? That OP_CHECKSIG behaves the same as OP_CHECKSIGVERIFY in case of bad signature?
<stevenroose>
Hmm, I'm suspecting I'm reading it wrong, because the same logic is used for CHECKSIGADD
ibiko1 has joined #bitcoin-core-dev
kevkevin_ has quit [Quit: Leaving...]
brunoerg has quit [Remote host closed the connection]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Remote host closed the connection]
ibiko1 has quit [Remote host closed the connection]
vasild has quit [Remote host closed the connection]
vasild has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
vasild has quit [Remote host closed the connection]
vasild has joined #bitcoin-core-dev
brunoerg has quit [Remote host closed the connection]
brunoerg has joined #bitcoin-core-dev
<achow101>
stevenroose: the return value is misleading. the signature succes/fail is in fSuccess, while EvalCheckSig* return value indicates some other error
<stevenroose>
achow101: I know. What I'm saying is that if the return value is false, execution halts. And I don't see any case (except that one in pre-tap) where success is set to false but true is returned
<stevenroose>
(That API is so bad, though, there is `fSuccess`, `serror` and the return value, so three dimensions
<stevenroose>
But I guess the return value is just an indicator to see if `serror` was set or not
<achow101>
success is set to false if the signature itself fails to validate
<achow101>
see interpreter.cpp:338
<achow101>
also "the script execution fails when using non-empty invalid signature."
<darosior>
stevenroose: on line 338 fSuccess may be set to false. Then on line 340-341, false is only returned if fSuccess is false and the signature isn't empty (standardness check), or fSuccess is false and we don't force invalid signatures to be empty vectors (consensus check). So there is a codepath (in fact, there is two) where an invalid signature makes
<darosior>
the function return true but set fSuccess to false.
preimage has quit [Quit: WeeChat 4.1.0]
<darosior>
stevenroose: on the other hand for Tapscript, invalid signatures must be empty by consensus (otherwise it stops execution). If an empty signature is passed to EvalChecksigTapscript, `success` is set to false on line 356, therefore the signature is not checked on line 369 and true is returned. In this case there is a single codepath where success is
<darosior>
set to false and the function returns true.
Talkless has quit [Quit: Konversation terminated!]
<warren>
Heads up. Linux Foundation announced that lists.linuxfoundation.org will shut down at the end of this year. This has been a long time coming. They asked us to move from this list server several times years ago. They can't keep it running anymore because the underlying software is insecure abandonware. We as a community have the collective responsibility to come up with a plan of where we move it to next.
<warren>
The next solution cannot be mailman2, which is unmaintainable no matter who runs it.
<warren>
The existing server has never worked well. It has severe problems with spam mitigation (hence why we had 100% manual moderation for years). It has delivery problems due to entire service providers having blacklisted the server IP address.
<warren>
So perhaps the next solution shouldn't be a mailing list anymore.
vysn has quit [Read error: Connection reset by peer]
brunoerg has quit [Remote host closed the connection]
bugs_ has quit [Quit: Leaving]
<warren>
History: People had (overly paranoid) concerns of a hostile centralized entity exerting influence over these dev lists which is why we never moved to the least effort solution years ago: Google Groups.
<warren>
Linux Foundation was seen as neutral, nobody worried about them being evil. Unfortunately they could not host it forever. We need to move now.
abubakarsadiq has quit [Quit: Connection closed for inactivity]
<warren>
As a related concern I expressed concern that the historical web archives https://lists.linuxfoundation.org/mailman/listinfo are linked to from thousands of other sites. I asked that they please keep that online as a frozen historical archive.
<warren>
ah good, they agreed to keep the archive links valid. "Correct, the plan is to keep pipermail archives at their current URL (or served as redirects to the new location). So, the links will remain valid. "
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 245 seconds]
ibiko1 has joined #bitcoin-core-dev
ibiko1 has quit [Ping timeout: 240 seconds]
<fjahr>
warren: Could you link to the announcement? I can't find it. Thanks!
<warren>
it isn't public
<warren>
this isn't the first time they asked us to move
<warren>
the reasons were written about years ago and they haven't changed
<warren>
the existing mailing list management software is unmaintainable abandonware
<warren>
IMO we should just move it to https://groups.google.com/ 1) Nobody seriously thinks Google is going to exert influence. There isn't a legitmate neutrality concern. 2) This is very low effort to maintain. 3) It can be used as either a web forum or a mailing list depending on what the subscriber wants.
<sipa>
warren: this discussion really belongs on the ML
<kanzure>
well, let's post to the mailing list
<warren>
writing ...
<warren>
If you want to discuss this please join ##bitcoin-dev-lists
<RubenSomsen>
There's also delvingbitcoin.org
<warren>
temporary channel for this topic
<josie>
exit
<warren>
I need to finish writing this later tonight.