< bitcoin-git>
[bitcoin] windsok opened pull request #21873: test: minor fixes & improvements for files linter test (master...files-lint-fixups) https://github.com/bitcoin/bitcoin/pull/21873
< yanmaani>
what's the difference in terms of abstraction level of interfaces::Chain and ChainstateManager?
< bitcoin-git>
[bitcoin] fanquake merged pull request #21845: net processing: Don't require locking cs_main before calling RelayTransactions() (master...2021-05-internal_relay_txs) https://github.com/bitcoin/bitcoin/pull/21845
< hebasto>
cirrus fuzzer job timed out recently
< jnewbery>
jeremyrubin: I'm not familiar enough with the proposal to have an opinion. As the author, you should use whatever you think is the clearest and most concise name.
< conman>
Hi all, for taproot mining pool support, apart from signalling in the version bits, is there anything new that is needed for constructing blocks once it's activated?
< michaelfolkson>
conman: This is a question for ##taproot-activation. But in answer to your question, no just signaling in version bits. Assuming it successfully activates then Taproot rules are only enforced in November.
< jeremyrubin>
conman: I think the question is appropriate here fwiw. if you are running the latest core client your blocks will correctly mine all txns, if you don't upgrade you'll be SPV mining the tip, but you won't select any invalid txns but you won't include taproot spends in mempool
< gmaxwell>
michaelfolkson: please don't direct people to ##taproot-activation for asking technical questions about how bitcoin works.
< gmaxwell>
jeremyrubin: s/don't upgrade/don't upgrade by november/ to be pedantic, though I'm sure conman understands.
< gmaxwell>
conman: yeah, it's not like segwit there is no pool software changes or anything like that.
< michaelfolkson>
gmaxwell: Ok sorry. Just a habit by now after last 3 months. I won't do so again if people are happy to have Taproot activation related questions here from now on
< luke-jr>
michaelfolkson: it's not a Taproot activation question
< gmaxwell>
achow101: you could also ship with it disabled but have a conf setting to enable it, which can be set by users after activation... and then all the weird issues with rescan/etc. go away.
< roconnor>
achow101: do you wait for 120 blocks after activation? include special min-locktime logic?
< achow101>
gmaxwell: that's one possibility, although I would be concerned about users setting the config option before activation
< achow101>
roconnor: not implemented yet, so up for debate. I imagine it would just run the versionbits checker and see if it returns active
< gmaxwell>
achow101: his point was that as soon as it activates its not safe to use due to reorgs.
< gmaxwell>
achow101: any taproot payment should be locktimed the activation height, ideally-- at least until a few blocks after activation.
< achow101>
but as the receiver, you can't make the sender locktime it, so it would be better to just wait
< gmaxwell>
yeah, you shouldn't issue a taproot address until N blocks after activation, with N depending on how much value you're talking about.
< jeremyrubin>
i have ~generally thought about sender specified locktimes (it's something that CTV does let you do, in a roundabout way) as kind of useful
< jeremyrubin>
E.g., if I set up a will and testament "on your 21st birthday you get X" is desirable.
< roconnor>
I'll suggest N = 120 which was the original default coinbase maturity policy. Seems about as good as any other number.
< jeremyrubin>
source?
< roconnor>
source for what?
< sipa>
i confirm roconnor's claim
< sipa>
but i'm too lazy to go look in the source code now
< jeremyrubin>
yep but only for policy / wallet display
< sipa>
that's what roconnor said
< roconnor>
That's why I said "default coinbase maturity policy".
< jeremyrubin>
Ah
< jeremyrubin>
I think it was kinda confusing because there is only (afaiu?) a maturity consensus rule these days
< jeremyrubin>
I thought you meant there used to be a diff consensus rule
< jeremyrubin>
apologies
< roconnor>
It seems like a good number in this case in that it is the most conservative historal value used in cases where we are worried about loss of funds due to reorgs.
< sipa>
in reality, the most important part will just be when the wallet starts constructing such addresses by default (or even when it provides a moderately convenient way of choosing to do so), which will likely be 1000s of blocks after activation
< sipa>
we're just talking about a extra anti-footgun measure
< sipa>
here
< jeremyrubin>
also note that it won't accidentally get into a block
< jeremyrubin>
Nor relayed
< jeremyrubin>
(the spends of it, not creation)
< jeremyrubin>
I guess during a reorg that's already an edge case where priors of miner misbehavior are higher
< jeremyrubin>
I think I've seen it proposed by someone that soft forks like taproot be preceded by a period where spending txns are invalid
< sipa>
that has been the case for every softfork as far as i a can remmeber
< harding>
jeremyrubin: I wouldn't be opposed to that, but it seems like overkill when software developers can just not release taproot-address-generating software until taproot is deployed, or they can gate address updates on a config flag or block height or whatever like being proposed here.
< jeremyrubin>
oh yeah i'm not advocating it, just discussing what I've seen discussed
< jeremyrubin>
let them eat cake
< jeremyrubin>
I think where it's relevant is if we were to ever have a softfork where something that could get into the mempool became invalid... but that's a huge mess so I hope not
< gmaxwell>
I don't think there is any advantage to making the spending temporarily invalid over simply enforcing the rule earlier.
< gmaxwell>
not even in the case where a softfork is excluding previously policy-permitted txn.
< jeremyrubin>
exlcuding previously policy permitted stuff feels a lot like stealing money
< gmaxwell>
jeremyrubin: prior softforks have made invalid recently-policy-permitted txn, fwiw. The DER encoding changes were one such example.
< gmaxwell>
If you speak so generally you'll tend to say stuff thats just wrong.
< jeremyrubin>
gmaxwell: that is a thin line -- those are at least re-encodable right?
< gmaxwell>
There isn't any real basis to make that stement for der encoding changes, for example.
< gmaxwell>
jeremyrubin: in some sense _ever_ softfork breaks your rule, because policy restrictions didn't extend back to day one.
< gmaxwell>
er _every_.
< jeremyrubin>
Hmm actually no they aren't reencodable
< gmaxwell>
And have changed structure a few times.
< jeremyrubin>
gmaxwell: sure, I'll exclude some stone-age stuff
< gmaxwell>
jeremyrubin: yes they are unless you've intentionally done something moronic with OP_SIZE or comparisons. :P
< jeremyrubin>
I think generally we should be very careful with it
< gmaxwell>
Sure. Not news to anyone else.
< jeremyrubin>
Even DER encodings would break e.g. things which are presigneds sitting somewhere with more than 1 hop\
< gmaxwell>
That is why stuff explicit policy carveouts for future use even exist at all.
< jeremyrubin>
because re-encoding would break the 2nd presign
< sipa>
at least with segwit versioning, and taproot leaf versioning + op_success, there is generally no need for changing policy before introducing new (script) functionality
< gmaxwell>
jeremyrubin: yes but anyone could break the chain regardless.
< jeremyrubin>
that's a good point, malleability?
< gmaxwell>
jeremyrubin: and malliation attacks on the network used to be a thing that actually happened.
< gmaxwell>
Unclear why they stopped, other than maybe just that they failed to drop the bitcoin price.
< gmaxwell>
(well some stopped because they were performed by non-miners, but some were miner performed)
< gmaxwell>
In any case, indeed, one must be careful when adding new rules. The specific forwards-compat policy carefouts (like NOPs, segwit versions, OP_SUCCESS) exists to make those as easy and safe as possible. But sometimes, e.g. in the case of bug fixes, it may not be possible to use those mechenisms.
< sipa>
ah, NOPs too, of course
< gmaxwell>
Fortunately "the rule stops people from triggerign a weird bug" itself starts off with relatively low risk.
< roconnor>
Do we relay taproot spends with an annex? ... I mean other than the fact that we don't relay taproot spends at all?
< gmaxwell>
And setting something policy denyed well in advance makes things safer.
< sipa>
roconnor: no, those are nonstandard
< jeremyrubin>
roconnor: I think it's discouraged policy?
< roconnor>
ok
< gmaxwell>
In general, nothing without consensus meaning should get relayed-- without meaning there is no reason to set it... so the only reason it has for existing is to get assigned consensus meaning in the future. :P
< gmaxwell>
Though some non-standard things are more obviously intended for future compat than others.
< gmaxwell>
If you do something stupid with OP_SUCCESS or future segwit versions, well you get what you deserve for sure.
< gmaxwell>
(or the NOPs)
< sipa>
i think the insight here has been to construct things in a way such that so-far-unspecified features result in being equivalent to OP_TRUE at the consensus level, so that it is unambiguous the feature is useless before that point
< gmaxwell>
yeah thats the OP_SUCCESS insight, particularly the fact that it first scans the script for _ANY_ use of them, so it doesn't matter where you put them.
< gmaxwell>
OP_NOPs have the misfortune that you can stick them someplace in an otherwise working script and kaboom your funds are suddely frozen aftre two years of succesfully using the script.
< jeremyrubin>
is that true for "well behaved" NOP upgrades?
< gmaxwell>
jeremyrubin: I'm glad we've never had to go the route but it would be possible to make consensus rules depend on the nheight of the output.
< gmaxwell>
jeremyrubin: it's not a property of the NOP upgrade, it's a property of the sufficiently advanced idiot using one before it has a consensus meaning.
< jeremyrubin>
Well I just mean if it's OP_IF ... NOP OP_ELSE <sane thing> OP_ENDIF
< jeremyrubin>
sane thing will keep on working
< jeremyrubin>
even if it is NOP and not SUCCESSX
< gmaxwell>
but then the nop likely served no purpose, since the script sig decided if it ever got executed at all.
< jeremyrubin>
gmaxwell: even that is limited value since things like LN have multiple output hops precommitted
< gmaxwell>
and as I said, that isn't a property of the upgrade-- it's a property of the user.
< jeremyrubin>
well you claimed that it would break an otherwise working script, but it's ultimately policy of discouraging that protects successx and NOP today
< jeremyrubin>
successx is just more agrressive about it?
< gmaxwell>
I claimed what would break an otherwise working script?
< jeremyrubin>
Yes, so the script wouldn't work (via policy / discouraged nops) if it executes..
< jeremyrubin>
Unless it's a "aggressive NOP" that has odd semantics
< jeremyrubin>
(which is what successx is designed to enable?)
< gmaxwell>
I don't agree.
< jeremyrubin>
I just can't think of an example of something that would not be rejected by policy before the SF if it's a typical NOP upgrade
< jeremyrubin>
if it doesn't execute it has no effect
< jeremyrubin>
Counterexample?
< gmaxwell>
I see where your confusion comes from. There wouldn't be because we intentionally created policy to protect upgrades. But policy is a rather weak protection some miners bypass it, for example. (f2pool does, or at least has in the past).
< gmaxwell>
OP_SUCCESS is anti-footgun even without policy protecting it.
< jeremyrubin>
Just in terms of what it implies to the user?
< jeremyrubin>
Because f2pool can ignore policy on OPSUCCESSX too
< jeremyrubin>
I don't mean to question that there is a benefit for safety, I just still don't quite see it
< jeremyrubin>
and I'd like to!
< jeremyrubin>
(I do see a benefit for flexibility though of course)
< gmaxwell>
Say litecoin had some OP_INPUT_WASNT_CREATED_IN_THE_SAME_BLOCK which it used as OP_NOP3. Then some exchange was using that on litecoin and starts using it on bitcoin, and f2pool is mining it. It's harmless-- doesn't do anything. Over the next year they assign 10,000 BTC to those outputs.
< gmaxwell>
then Bitcoin deploys a softfork that turns OP_NOP3 into some new relative timelock. Boom all those outputs become forever unspendable and they lose 10,000 BTC.
< gmaxwell>
Now, contrast this with OP_SUCCESS. If they accidentally misuse an OP_SUCCESS in this manner, their coin on their first test transaction is just immediately (and probably automatically) stolen.
< gmaxwell>
They'd have no incentive to try to block a OP_NOP3 softfork upgrade because they were depending on the do-nothing behavior. ... because any use of an undefined OP_SUCCESS just gives away the coins.
< gmaxwell>
The OP_SUCCESS also makes it much easier to analyize if the change is safe, because by definition the old rules just accept anything that has the OP_SUCCESS anywhere in it.
< jeremyrubin>
I kinda see what you're saying, but I'd point out that both success and nop have local policy guarding things... so your own node should help you bounce the txn and so should the network. so it's really the case where you directly connect to those miners who ignore policy
< jeremyrubin>
I now understand what you see, but it seems (to me) a far fetched case that someone would discover a defect this way
< gmaxwell>
What node? Our superior idiot in this example has a team of Ruby experts that coded their own wallet.
< gmaxwell>
If they weren't idiots to begin with they wouldn't have had a non-consensus defined operation in their script at all. :P
< jeremyrubin>
yeah it's just too many hops of idiocy for me to care, but I admire your kind heart
< gmaxwell>
Hm? we've had issues with people inserting meaningless crap in transactions before... part of the origin of policy protection is to protect the ability to use tx fields for upgrades so that broken software doesn't degrade it.
< sipa>
it doesn't even need to be an unintentional thing like altcoin behavior accidentally being used on the wrong chain
< sipa>
e.g. certain data-stuffing-in-transaction methods could also interfere with future upgrades, for example
< jeremyrubin>
yeah; for the subsidy txs stuff I had to check carefully that OP_VER outputs aren't a thing
< phantomcircuit>
conman, i don't think coinbaseaux has been used in ages
< phantomcircuit>
that was the very old way of signaling for a soft fork
< gmaxwell>
conman: I *think* using tags in coinbaseaux isn't likely to be used in the future because there have been mining devices that are fairly particular about the structure of the coinbase scriptsig, unfortunately. (e.g. expect to be able to fuzz specific byte offsets via an fpga/asic).
< gmaxwell>
If it were used again there would probably be some huge circus of figuring out which devices/firmware it's incompatible with. :(
< gmaxwell>
(/pool software, but at least that is fixable)
< conman>
I understand it's not been used, but it's still there and in the documentation as a requirement
< conman>
but thanks, what I needed was whether it would ever be used again
< sipa>
conman: i think it's there because of the protocol having been envisioned to be used for pool-hasher communication too
< conman>
nod
< luke-jr>
it's documented as NOT required..
< sipa>
luke-jr: well, yes, but if it's present, it has to be obeyed?
< sipa>
i guess it says "SHOULD"
< luke-jr>
sipa: right
< conman>
oh is he talking? sorry he's been on ignore for a decade
< sipa>
anyway, i agree it's unlikely that bitcoin core would ever be in a position where it needs to set that field
< conman>
perhaps it's time to unignore him
< conman>
sipa: thanks
< phantomcircuit>
sipa, as gmaxwell said i don't even think it can be set without significant chaos
< gmaxwell>
conman: unfortunately bitcoin exposes far too much consensus innards to edge devices, it's a big problem... because it creates interactions with edge devices that ought not exist.