Norrin has quit [Remote host closed the connection]
martin_1 has quit [Read error: Connection reset by peer]
yanmaani has quit [Ping timeout: 255 seconds]
yanmaani has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] TheCharlatan opened pull request #27103: Blockstorage: Dont access gArgs to get blocks_dir (master...blockstorageArgs) https://github.com/bitcoin/bitcoin/pull/27103
<bitcoin-git>
[bitcoin] TheCharlatan closed pull request #27103: Blockstorage: Dont access gArgs to get blocks_dir (master...blockstorageArgs) https://github.com/bitcoin/bitcoin/pull/27103
<bitcoin-git>
bitcoin/master e37bcaa Pieter Wuille: Split ChaCha20 into aligned/unaligned variants
<bitcoin-git>
bitcoin/master 6babf40 Pieter Wuille: Rename ChaCha20::Seek -> Seek64 to clarify multiple of 64
<bitcoin-git>
bitcoin/master 12ff724 Pieter Wuille: Make unrestricted ChaCha20 cipher not waste keystream bytes
<bitcoin-git>
[bitcoin] fanquake merged pull request #26153: Reduce wasted pseudorandom bytes in ChaCha20 + various improvements (master...202209_chacha20) https://github.com/bitcoin/bitcoin/pull/26153
nanotube has joined #bitcoin-core-dev
bugs_ has joined #bitcoin-core-dev
Zenton has joined #bitcoin-core-dev
<jamesob>
_aj_: doing `CScriptNum.encode(CScriptNum(-1))`, e.g., results in the interpreter seeing "-257"
<sipa>
jamesob: Is this in the functional test framework or the C++ codebase?
<jamesob>
sipa: functional test framework -> C++
<jamesob>
in Python, CScriptNum.encode(CScriptNum(-1)) gives b'\x01\x81', whereas the script interpreter expects b'\x81' to encode "-1". Maybe there's a bug in the Python?
<sipa>
Looks like it.
<jamesob>
Interestingly, CScript([CScriptNum(-1)]) yields the right value (b`\x81`)
<bitcoin-git>
[bitcoin] MarcoFalke merged pull request #27035: test: simplify and speedup mempool_updatefromblock.py by using MiniWallet (master...202302-test-use_MiniWallet_for_mempool_updatefromblock) https://github.com/bitcoin/bitcoin/pull/27035
<sipa>
jamesob: Do you mean the *script* b'\x81' (which is OP_1), or the script that *pushes* b'\x81' (which is the encoding of -1).
<jamesob>
the latter
<jamesob>
Oddly enough, when putting `CScript([CScriptNum(-1)])` on the witness stack, the C++ script interpreter sees -257
<sipa>
The witness stack doesn't contain scripts; it contains script inputs directly encoded as byte arrays.
<jamesob>
Putting `b'\x81'` onto the witness stack does "the right thing" for me (which is to encode an integer value of -1)
<sipa>
Oh, in the functional framework, CScriptNum.encode and decode don't encode/decode to the byte encoding of the number, but to the script code that pushes that encoding.
<sipa>
Which is why CScript([CScriptNum(-1)]) works.
<sipa>
The encode/decode functions are only expected to be used in that context.
<jamesob>
Oh - whereas in a witness stack context, the "push" is implicit?
<sipa>
Right.
<jamesob>
Got it, thanks
<sipa>
Also in script context you have OP_1 through OP_16, and OP_1NEGATE available.
<sipa>
In witness stack context you don't.
<jamesob>
Oh you mean to minimally-encode small integers?
<jamesob>
As in, you can use those opcodes to minimally encode small integers in a script context, but not in the contents of the witness stack?
<sipa>
Yeah say to push b'\x03' (the encoding of the number 3) onto the stack, in script context you can use the 1-byte script "OP_3" (b'\x53').
<sipa>
Or you could use the 2-byte script "<3>" (b'\x01\x03').
<sipa>
In witness stack context, there are no scripts, you're just giving the stack of elements as you want it, so the only way is giving a stack containing the 1-byte element b'\x03').
<jamesob>
Ah got it, and in fact it would be a contemporary policy violation to use "\x01\x03" in lieu of OP_3 in a script context, right?
<sipa>
In standard scripts you *must* use OP_3 even, CheckMinimalPush will fail if you use <3>.
<jamesob>
right ^
Guest77 has joined #bitcoin-core-dev
<sipa>
Right, exactly.
Guest77 has quit [Client Quit]
<jamesob>
So, when encoding Python ints for use on a witness stack, what you really want is `script.bn2vch(...)`
hg has joined #bitcoin-core-dev
<jamesob>
I forgot, maybe we discussed this already: where did we land about the desireability of adding logging statements to the script interpreter? Are there performance concerns? Certain things would be nice to add, e.g. when the interpreter fails due to a generic exception, we don't do any logging of the excpetion itself; we just return
<bitcoin-git>
bitcoin/master 691eaf8 Matt Whitlock: Pass MSG_MORE flag when sending non-final network messages
<bitcoin-git>
bitcoin/master 5ecd14a fanquake: Merge bitcoin/bitcoin#26844: Net: Pass `MSG_MORE` flag when sending non-fi...
<bitcoin-git>
[bitcoin] fanquake merged pull request #26844: Net: Pass `MSG_MORE` flag when sending non-final network messages (round 2) (master...MSG_MORE) https://github.com/bitcoin/bitcoin/pull/26844
<jamesob>
Kind of surprised we don't have a macro to conditionally include certain LogPrintfs only when debug mode is enabled...
<vasild>
hebasto: wrt https://github.com/bitcoin/bitcoin/pull/27060#issuecomment-1431519355 "... adding more commits after reviewing and ACKing of previous ones ..." - what usually happens with big PRs that are split is that a different set of reviewers review the sub-PRs. How would that work if everything is kept in one unmerged PR and new commits are appended to it?
dzxzg has joined #bitcoin-core-dev
<vasild>
for example, if things get merged, like usually, e.g. there are 10 already merged commits from old sub-PRs and two new ones are opened in a separate new sub-PR. The (new) reviewers see just that 2 new commits, while if everything is kept in one PR, they would see 12 commits
<hebasto>
vasild: just trying to find a middle ground among different opinions, including "not merging unfinished build system"
<vasild>
yeah
hernanmarino has joined #bitcoin-core-dev
b_101_ has joined #bitcoin-core-dev
b_101 has quit [Ping timeout: 255 seconds]
b_101 has joined #bitcoin-core-dev
b_101_ has quit [Ping timeout: 246 seconds]
szkl has quit [Quit: Connection closed for inactivity]
jarthur has joined #bitcoin-core-dev
pablomartin has joined #bitcoin-core-dev
jarthur_ has quit [Ping timeout: 246 seconds]
roze_paul has joined #bitcoin-core-dev
b_101 has quit [Read error: Connection reset by peer]