ghost43 has quit [Remote host closed the connection]
ghost43 has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 268 seconds]
qxs has joined #bitcoin-core-dev
puchka has quit [Ping timeout: 240 seconds]
AaronvanW has quit [Remote host closed the connection]
<jamesob>
anyone ever see blockfilterindex fail to build because it couldn't read undo data for recently connected blocks? Trying to figure out if this is an assumeutxo thing or an outstanding issue on master
puchka has joined #bitcoin-core-dev
<jamesob>
oh, nevermind, this is definitely an assumeutxo thing - can't have an aggressive (i.e. nonexistent) trailing prune window for the bg chainstate when building indexes, because it'll remove undo data too quickly. easy fix.
<TheCharlatan>
willcl_ark: yes, it's a pity though that I cannot edit the original issue. I'm preparing a new one, but just copying over much of the original content seems wrong.
SpellChecker_ has quit [Quit: bye]
<willcl_ark>
Oh that's annoying. Prob best to copy over and use a new one in that case then? I personally don't see any issue in copying the content as a starting point now that you picked up the project...
brunoerg has quit [Ping timeout: 256 seconds]
SpellChecker has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 248 seconds]
Guest6961 has joined #bitcoin-core-dev
Guest6961 has quit [Client Quit]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 260 seconds]
<bitcoin-git>
[bitcoin] hebasto opened pull request #27580: msvc: Cleanup after upgrading libsecp256k1 up to 0.3.0 (master...230505-cleanup) https://github.com/bitcoin/bitcoin/pull/27580
<darosior>
For what it's worth i've been seeing "DrahtBot requested review from w0xlt and removed request for w0xlt now" multiple times on #26076. Last occurence seems to have been triggered when i pushed a review.
<gribble>
https://github.com/bitcoin/bitcoin/issues/26076 | Switch hardened derivation marker to h (in normalized descriptors and new wallets) by Sjors · Pull Request #26076 · bitcoin/bitcoin · GitHub
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 256 seconds]
test_ has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
flooded has quit [Ping timeout: 268 seconds]
brunoerg has quit [Ping timeout: 240 seconds]
pharonix71 has quit [Ping timeout: 240 seconds]
pharonix71 has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 268 seconds]
qxs has quit [Remote host closed the connection]
qxs has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
Guyver2 has joined #bitcoin-core-dev
Guyver2 has left #bitcoin-core-dev [#bitcoin-core-dev]
brunoerg has quit [Ping timeout: 265 seconds]
<josie>
for output types that have a scriptSig (P2PKH for example), is the scriptSig malleable? meaning can I put other things in the scriptSig such that it still unlocks the locking script?
<sipa>
Malleability specifically refers to third parties (not signers) to turn a valid signature into another valid signature.
<sipa>
If you're talking about signers, that's trivially true - they can just sign again.
<sipa>
Besides other signatures, for P2PKH, taking standardness into account, I don't think there are any malleabilities.
<josie>
ah, im not using the right term. I'm more referring to the structure. so the scriptSig for a P2PKH is `<signature> <pubkey>`, right? can i put any other data in the scriptSig and still have it satisfy the scriptPubKey locking script?
brunoerg has joined #bitcoin-core-dev
<sipa>
For consensus, definitely. E.g. `<dummy> OP_DROP <signature> <pubkey>`, but that violates the pure push standardness rule.
<josie>
gotcha, thats what I was worried about. in your example, <dummy> could be something that looks like a pubkey, yeah?
<sipa>
In theory, yes, literally anything (up to 520 bytes).
<sipa>
I think you can restrict yourself to just looking at normal-looking P2PKH spends (two pushes)
<josie>
darosior: thanks! this is really helpful
brunoerg has quit [Remote host closed the connection]
<josie>
sipa: in the context of silent payments, its more a problem for coinjoins. lets say im malicious and i collaboratively do the silent payment tweak with the "real" pubkey, but then in the scriptSig add a dummy pubkey (and a valid signature for it, if thats possible). the receiver can't determine which public key to use for ECDH on their side and can't find the funds
brunoerg has joined #bitcoin-core-dev
<sipa>
Including a malicious pubkey (one that has no corresponding signature) completely breaks the security
<sipa>
But just excluding one does not.
<sipa>
So I think you should just include P2PKH spends that contain 2 standard-looking stack items on the scriptSig.
AaronvanW has quit [Remote host closed the connection]
bitdex has quit [Ping timeout: 240 seconds]
<josie>
sipa: yeah, the question came up for coinjoins in that maybe I (the sender) don't know what your scriptSig is going to be until the tx is finalized and broadcast, and so if you (the malicious coinjoin participant) do a non-standard scriptSig, the receiver would skip your P2PKH input when scanning because its not a standard scriptSig
AaronvanW has joined #bitcoin-core-dev
AaronvanW has quit [Remote host closed the connection]
<josie>
using your example from earlier, you and I would be coinjoining, I'd see that you want to spend a P2PKH output, so I'd say "hey participate in this tweak," you do, but then you use the scriptSig `<dummy> OP_DROP <sig> <pubkey>` and I don't catch it. The receiver sees your P2PKH scriptSig isn't two standard items and skips your input when doing ECDH and then can't find the output intended
<josie>
for them
<josie>
but now that I type it out, feels like you could probably solve for that in the coinjoin protocol? like verifying all the scriptSigs look good and refusing to sign if not
<bitcoin-git>
[bitcoin] fanquake merged pull request #26653: test, init: perturb file to ensure failure instead of only deleting them (master...2022-12-stress-test-perturbing) https://github.com/bitcoin/bitcoin/pull/26653
vysn has quit [Remote host closed the connection]
vysn has joined #bitcoin-core-dev
preimage has joined #bitcoin-core-dev
flooded has joined #bitcoin-core-dev
test_ has quit [Ping timeout: 256 seconds]
bugs_ has joined #bitcoin-core-dev
<cfields>
TheCharlatan: the last shutdown transform I have is from about a year ago.. I stopped committing them after I got my plugin working. But now I'm struggling to get the plugin working agian, heh...
<bitcoin-git>
bitcoin/master dda961c Hennadii Stepanov: test, refactor: Add `set_binary_paths` function
<bitcoin-git>
bitcoin/master f6d7636 Hennadii Stepanov: test: Treat `bitcoin-wallet` binary in the same way as others
<bitcoin-git>
bitcoin/master 5566405 fanquake: Merge bitcoin/bitcoin#27554: test: Treat `bitcoin-wallet` binary in the sa...
<bitcoin-git>
[bitcoin] fanquake merged pull request #27554: test: Treat `bitcoin-wallet` binary in the same way as others (master...230502-toolwallet) https://github.com/bitcoin/bitcoin/pull/27554
<cfields>
TheCharlatan: If those are helpful and you'd like a new one based on master, just lmk.
<TheCharlatan>
cfields, cool :)
<cfields>
Note that shutdowns are handled there but not interruptions. I think the interrupts were much more manageable.