brunoerg_ has quit [Remote host closed the connection]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Remote host closed the connection]
brunoerg has joined #bitcoin-core-dev
kevkevin has joined #bitcoin-core-dev
kevkevin has quit [Ping timeout: 260 seconds]
diego has joined #bitcoin-core-dev
diego is now known as Guest6228
salvatoshi has quit [Ping timeout: 246 seconds]
jarthur has joined #bitcoin-core-dev
kevkevin has joined #bitcoin-core-dev
<Chris_Stewart_5>
Hi, I believe i've found an unsatisfiable test case in script_assets_test.json when new op codes are introduced. The witness is redeem script is 'de4c' which is OP_GREATERTHAN64 OP_PUSHDATA1 when decoded. There is no bytes after OP_PUSHDATA1 which causes script parsing and the test case to fail when it is expected to succeed. Here is a link to my code to reproduce w/ the example embedded
<Chris_Stewart_5>
I pulled the test case from the script_assets_test.json available on the qa-assets repo, as i'm trying to get #29221 . Even if the PR i'm working on is disliked, I believe this problem holds true for any future op code soft forks using the op code 'de'
<instagibbs>
I'm having trouble parsing what your issue is. You redefined an OP_SUCCESS(right?), and now something that has that redefined opcode is failing?
<sipa>
OP_SUCCESSx, when not redefined, must succeed the script, even if it is unparseable
kevkevin has joined #bitcoin-core-dev
<Chris_Stewart_5>
Exactly. So IIUC the OP_PUSHDATA1 will always cause things to fail, even if there is nothing wrong with the Script
<Chris_Stewart_5>
So what i'm looking for is 1. Confirmation that i'm right, 2. if you want me to work on the test gen code to avoid this scenario and generate new script_assets_test.json to be uploaded to qa-assets, i can
<sipa>
Chris_Stewart_5: when your softfork is not active, it cannot change the behavior of script
kevkevin has quit [Ping timeout: 264 seconds]
<sipa>
'de4c' is always valid, right now
<sipa>
if you're changing that, you're doing something wrong
zato has joined #bitcoin-core-dev
<Chris_Stewart_5>
i'll think about this more. I see your point. Seems like pre-processing parsing logic now needs to be gated by flags IIUC
kevkevin has joined #bitcoin-core-dev
bugs_ has joined #bitcoin-core-dev
kevkevin has quit [Ping timeout: 252 seconds]
Guest82 has quit [Quit: Client closed]
kevkevin has joined #bitcoin-core-dev
cotsuka has quit [Remote host closed the connection]
<bitcoin-git>
bitcoin/master c3d02be Gloria Zhao: [test] rescan legacy wallet with reorged parent + IsFromMe child in mempool
<bitcoin-git>
bitcoin/master df30247 glozow: [test] import descriptor wallet with reorged parent + IsFromMe child in me...
<bitcoin-git>
bitcoin/master 27d935f Ava Chow: Merge bitcoin/bitcoin#29179: test: wallet rescan with reorged parent + IsF...
<bitcoin-git>
[bitcoin] achow101 merged pull request #29179: test: wallet rescan with reorged parent + IsFromMe child in mempool (master...2024-01-test-reorg-rescan) https://github.com/bitcoin/bitcoin/pull/29179
cotsuka has joined #bitcoin-core-dev
kevkevin has quit [Ping timeout: 264 seconds]
flooded has joined #bitcoin-core-dev
test__ has quit [Ping timeout: 264 seconds]
<jonasschnelli>
I was wondering if it would make sense to revive BIP150 (p2p authentication) now that V2 p2p is available. Authenticating designated p2p connections could be a useful feature.
<sipa>
jonasschnelli: we've worked on getting countersign (a much more private authentication scheme) formalized and proven, but the project is a bit stalled right now
<jonasschnelli>
sipa: that would be the "authenticate-everything" approach? right?
<sipa>
not sure what that means
<sipa>
jonasschnelli: the protocol lets one party (with a pubkey) query another (with a privkey) figure out if the key matched, and nothing else
<jonasschnelli>
Countersign would authenticate against all pre-known v2 p2p peers, right?
<jonasschnelli>
okay.. then I had it wrong in my head.
<sipa>
the idea would be to always run it, even if you don't care about authentication, you'd just run with dummy/random keys, and ignore the failure
<sipa>
there is a link to a writeup in bip324
<sipa>
the writeup is a bit outdated, but gives a good idea
<jonasschnelli>
I'll take a look. Thanks
<jonasschnelli>
Might be a dead end, but now that v2 p2p is here, I though it would be not overly dumb to use BIP39 via an authenticated p2p connection to a self-run/trusted node.
<jonasschnelli>
No tunnel, no SSH, no VPN
<jonasschnelli>
BIP37, src
<jonasschnelli>
sry
<jonasschnelli>
ofc, bloom filters would be unnecessary (but since the standard is there)
<bitcoin-git>
bitcoin/master 74ebd4d Martin Zumsande: doc, test: Test and explain service flag handling
<bitcoin-git>
bitcoin/master 5711da6 Ava Chow: Merge bitcoin/bitcoin#29213: doc, test: test and explain service flag hand...
<bitcoin-git>
[bitcoin] achow101 merged pull request #29213: doc, test: test and explain service flag handling (master...202401_addrman_serviceflags) https://github.com/bitcoin/bitcoin/pull/29213
PaperSword has joined #bitcoin-core-dev
kevkevin has joined #bitcoin-core-dev
kevkevin has quit [Ping timeout: 264 seconds]
rolf has joined #bitcoin-core-dev
kevkevin has joined #bitcoin-core-dev
kevkevin has quit [Ping timeout: 240 seconds]
cotsuka has quit [Remote host closed the connection]
cotsuka has joined #bitcoin-core-dev
raini_ok has joined #bitcoin-core-dev
test__ has joined #bitcoin-core-dev
flooded has quit [Ping timeout: 276 seconds]
abubakarsadiq has quit [Quit: Connection closed for inactivity]