< aj>
sipa: hmm, wouldn't it be better to have AreInputsStandard() return false for taproot spends prior to taproot actually activating? could pass down currentBlockScriptVerifyFlags to do that, I think?
< sipa>
aj: there is no script validation flag that will reject a valid taproot spend
< sipa>
one could be added, but that's a bit invasive... i'd rather do it through policy/policy.cpp alone
< sipa>
aj: and yes, i suggest that (a) before activation is defined: creation is allowed, spending is not (b) while defined but unactivated: neither is allowed (c) when active, both are allowed
< sipa>
an alternative - if we don't care about the theft protection - is making (b) identical to (a)
< aj>
sipa: oh... maybe it was too early in the morning when i read what you were saying then, that sounds great
< sipa>
and looking at implementation... (a) can easily be extended to "any situation in which it will never activate", including when it has failed
< sipa>
one downside to have (a) and (b) have different behavior is that it introduces a trivial relay policy difference between nodes-with-activation and nodes-without-activation
< sipa>
so if that's a concern, it should just be: whenever not active: creating allowed, spending not
< aj>
there'll be a relay policy difference between (a) and (c) and (b)/(c) are the same nodes, so that seems fine?
< sipa>
right, but we can expect that by the time activation happens, many nodes will have activation included
< sipa>
so it's a synchronized event rather than dependent on upgrade time
< bitcoin-git>
bitcoin/master cbb5f3a fanquake: Merge #19836: rpc: Properly deserialize txs with witness before signing
< bitcoin-git>
[bitcoin] fanquake merged pull request #19836: rpc: Properly deserialize txs with witness before signing (master...2008-rpcDeserTxsWitness) https://github.com/bitcoin/bitcoin/pull/19836
< bitcoin-git>
[bitcoin] sipa opened pull request #20165: Only relay Taproot spends if next block has it active (master...202010_taproot_policy) https://github.com/bitcoin/bitcoin/pull/20165
< luke-jr>
sipa: hmm, I wonder if, ideally, we would wait 100 blocks after activation to relay them
< luke-jr>
similar to coinbase spends
< sipa>
luke-jr: what would that protect against?
< bitcoin-git>
[bitcoin] laanwj closed pull request #19635: param: add bool parameter -ephemeraltoronion to generate ephemeral tor addreses (master...ephemeral-tor-onion) https://github.com/bitcoin/bitcoin/pull/19635
< luke-jr>
sipa: reorgs invalidating them with a miner theft
< luke-jr>
sipa: downstream of the actual taproot spend
< luke-jr>
ie, a taproot spend is similar to a coinbase in that it can be claimed by any miner before the activation block
< aj>
luke-jr: provided the pay-to-taproot tx has block height locktime, that's fine though
< sipa>
luke-jr: that argument would apply to creation of outputs, not spending them
< luke-jr>
aj: oh, that's true
< luke-jr>
hmm, might have been interesting to have a consensus rule that taproot spends need a locktime after the activation height/time; probably also not worth the additional effort tho
< luke-jr>
actually, that doesn't work
< luke-jr>
because that rule wouldn't exist before activation either
< sipa>
right
< luke-jr>
hmm… maybe it would anyway? since it'd be an invalid taproot spend normally
< luke-jr>
oh well, could just as well be a "wallets should do this" best practice
< bitcoin-git>
[bitcoin] laanwj closed pull request #19419: wallet: let Listwalletdir do not iterate through our blocksdata. (master...wallet_351) https://github.com/bitcoin/bitcoin/pull/19419
< bitcoin-git>
[bitcoin] fanquake closed pull request #20164: [test] undo truncation of digits in btc amount (master...rpc-testmempoolaccept-fee) https://github.com/bitcoin/bitcoin/pull/20164
< hebasto>
fanquake: is /private dir a travis artefact?
< fanquake>
hebasto: no that is on my macOS machine
< hebasto>
ok, going to reproduce on macOS
< hebasto>
fanquake: looks like kind of sandboxing
< fanquake>
hebasto: possibly, however I haven't looked further yet. Just noticed that the issue started occurring with the introduction of fs::canonical
< bitcoin-git>
bitcoin/master 0d9d2a1 Jonas Schnelli: Only update the updateSmartFeeLabel once in sync
< bitcoin-git>
bitcoin/master 9e8d2bd MarcoFalke: Merge bitcoin-core/gui#97: Relax GUI freezes during IBD (when using wallet...
< bitcoin-git>
[bitcoin] practicalswift opened pull request #20169: Taproot follow-up: Make ComputeEntrySchnorr and ComputeEntryECDSA const to clarify contract (master...const-ComputeEntrySchnorr) https://github.com/bitcoin/bitcoin/pull/20169