< 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?
< yanmaani> ChainstateManager is only for names?
< yanmaani> I mean RPCs
< bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/06d573f053c6...a0d1d487e93d
< bitcoin-git> bitcoin/master 39e1971 John Newbery: [net processing] Add internal _RelayTransactions()
< bitcoin-git> bitcoin/master a0d1d48 fanquake: Merge bitcoin/bitcoin#21845: net processing: Don't require locking cs_main...
< 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.
< jnewbery> (as long as it's not SecureTheBag!)
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/a0d1d487e93d...a33f360fcdd2
< bitcoin-git> bitcoin/master 2227fc4 windsok: test: minor fixes & improvements for files linter test
< bitcoin-git> bitcoin/master a33f360 MarcoFalke: Merge bitcoin/bitcoin#21873: test: minor fixes & improvements for files li...
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #21873: test: minor fixes & improvements for files linter test (master...files-lint-fixups) https://github.com/bitcoin/bitcoin/pull/21873
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/a33f360fcdd2...eb9a1fe03779
< bitcoin-git> bitcoin/master fa09871 MarcoFalke: refactor: Avoid sign-compare compiler warning in util/asmap
< bitcoin-git> bitcoin/master eb9a1fe MarcoFalke: Merge bitcoin/bitcoin#21802: refactor: Avoid UB in util/asmap (advance a d...
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #21802: refactor: Avoid UB in util/asmap (advance a dereferenceable iterator outside its valid range) (master...2104-asmapRefactor) https://github.com/bitcoin/bitcoin/pull/21802
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #21874: fuzz: Add WRITE_ALL_FUZZ_TARGETS_AND_ABORT (master...2105-fuzzWRITE_ALL_FUZZ_TARGETS_AND_ABORT) https://github.com/bitcoin/bitcoin/pull/21874
< 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.
< conman> great thanks, will move to t's and a's
< bitcoin-git> [bitcoin] jbampton opened pull request #21875: doc: fix spelling (master...fix-spelling) https://github.com/bitcoin/bitcoin/pull/21875
< jonatack> hebasto: seeing this too, fuzzer timing out since a day or so
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/eb9a1fe03779...9313c4e6aa4b
< bitcoin-git> bitcoin/master fa5cb6b MarcoFalke: fuzz: Add WRITE_ALL_FUZZ_TARGETS_AND_ABORT
< bitcoin-git> bitcoin/master 9313c4e MarcoFalke: Merge bitcoin/bitcoin#21874: fuzz: Add WRITE_ALL_FUZZ_TARGETS_AND_ABORT
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #21874: fuzz: Add WRITE_ALL_FUZZ_TARGETS_AND_ABORT (master...2105-fuzzWRITE_ALL_FUZZ_TARGETS_AND_ABORT) https://github.com/bitcoin/bitcoin/pull/21874
< bitcoin-git> [bitcoin] vasild opened pull request #21878: fubar everything (master...Sock_all_over_the_place) https://github.com/bitcoin/bitcoin/pull/21878
< bitcoin-git> [bitcoin] vasild opened pull request #21879: Wrap accept() and extend usage of Sock (master...SockAccept) https://github.com/bitcoin/bitcoin/pull/21879
< bitcoin-git> [bitcoin] vasild closed pull request #21700: net: expand Sock and fuzz-test more of CConnman (master...Sock_expand) https://github.com/bitcoin/bitcoin/pull/21700
< 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
< michaelfolkson> luke-jr: Fair enough
< bitcoin-git> [bitcoin] klementtan opened pull request #21880: wallet: remove GetScriptPubKeyMan spam (master...GetScriptPubKeyMan-spam) https://github.com/bitcoin/bitcoin/pull/21880
< achow101> wallet meeting?
< achow101> #startmeeting
< core-meetingbot> Meeting started Fri May 7 19:01:56 2021 UTC. The chair is achow101. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
< core-meetingbot> Available commands: action commands idea info link nick
< fjahr> hi
< sipa> hi
< meshcollider> Hi
< achow101> #bitcoin-core-dev Wallet Meeting: achow101 aj amiti ariard bluematt cfields Chris_Stewart_5 digi_james dongcarl elichai2 emilengler fanquake fjahr gleb glozow gmaxwell gwillen hebasto instagibbs jamesob jb55 jeremyrubin jl2012 jnewbery jonasschnelli jonatack jtimon kallewoof kanzure kvaciral lightlike luke-jr maaku marcofalke meshcollider michagogo moneyball morcos nehan NicolasDorier paveljanik petertodd phantomcircuit promag
< achow101> provoostenator ryanofsky sdaftuar sipa vasild wumpus
< achow101> any topics?
< sipa> none from me
< jonatack> hi
< meshcollider> Any wallet review begs?
< achow101> #17331 pls
< jonatack> yes!
< gribble> https://github.com/bitcoin/bitcoin/issues/17331 | Use effective values throughout coin selection by achow101 · Pull Request #17331 · bitcoin/bitcoin · GitHub
< meshcollider> Theres a few things in the GUI repo I need to have a look at
< fjahr> will re-review 17331 this weekend
< jonatack> #21786 is my second proposal to fix #20534 from last year
< gribble> https://github.com/bitcoin/bitcoin/issues/21786 | wallet: ensure sat/vB feerates are in range (mantissa of 3) by jonatack · Pull Request #21786 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/20534 | sat/b values arent validated to be in-range · Issue #20534 · bitcoin/bitcoin · GitHub
< jonatack> it's simpler and more complete
< achow101> cool, I'll add it to my list
< jonatack> 17331 and follow-up are on my list
< jonatack> the review clubs were very good
< fjahr> Looking forward to a rebase on #21365 as well :)
< gribble> https://github.com/bitcoin/bitcoin/issues/21365 | Basic Taproot signing support for descriptor wallets by sipa · Pull Request #21365 · bitcoin/bitcoin · GitHub
< fjahr> jonatack: will check it out
< jonatack> fjahr: thanks. it's only a handful of lines and then tests
< achow101> Is it reasonable to try to get taproot wallets for 22.0?
< achow101> With feature freeze in June, I'm not sure that we can make it
< meshcollider> I think so?
< jonatack> five weeks until June 15 feature freeze
< meshcollider> Nothing is impossible if enough people are willing to make it happen :)
< achow101> oh, it's only #21365, the prereqs were merged
< gribble> https://github.com/bitcoin/bitcoin/issues/21365 | Basic Taproot signing support for descriptor wallets by sipa · Pull Request #21365 · bitcoin/bitcoin · GitHub
< fjahr> I guess if signalling goes well interest will be high enough, if not people will focus on activation discussions :-/
< fjahr> (by well at least going in the right direction towards lockin within the next 4 weeks)
< fjahr> *by well I mean
< achow101> hmm, there's also the question of how does the wallet behave if that is merged before taproot activates?
< achow101> definitely don't want to be giving out taproot addresses before activation
< achow101> 22.0 will definitely be released before activation
< sipa> we can merge taproot wallet support without by default construction such descriptors
< achow101> but what happens if someone imports a taproot descriptor?
< sipa> perhaps we additionally want a safeguard that prevents the creation of such addresses in general before activation
< sipa> but you can't prevent people from importing crazy descriptors in general
< meshcollider> I mean, it's not like someone can accidentally import a taproot descriptor if they didn't intend to
< achow101> indeed
< jonatack> address safeguard sounds good
< sipa> i'm not sure where such a safeguard should go
< sipa> prevent importing the descriptor?
< sipa> that's possible with some adhoc code i guess
< sipa> or prevent generating addresses with it?
< sipa> or outlaw the descriptor in general?
< achow101> I was thinking we should have a warning if someone imports a taproot descriptor
< luke-jr> maybe tr() shouldn't be valid until activation?
< achow101> and then something that disallows getting bech32m addresses
< jonatack> for mainnet
< sipa> luke-jr: a downside is that a wallet rescanning post activation might consider the descriptor invalid then
< luke-jr> hmm
< sipa> well, or a node reindexing, with a loaded wallet
< sipa> sec, brb
< luke-jr> I guess logically it should simply not be recognised as the sPK matching
< achow101> maybe just a scary warning on import then. just tell people what they're doing is not recommended because taproot isn't active
< luke-jr> since you don't want a wallet rescan to show pre-activation coins either
< sipa> luke-jr: hmm
< achow101> hmm, if we disallow import until after activation, then none of this would be a problem?
< achow101> even pre-activation coins are fine post-activation
< meshcollider> Yeah it seems a catch at import-time would be simplest then
< sipa> achow101: yeah, that seems reasonable
< achow101> anything else to discuss?
< achow101> #endmeeting
< core-meetingbot> topic: Bitcoin Core development discussion and commit log | Feel free to watch, but please take commentary and usage questions to #bitcoin | Channel logs: http://www.erisian.com.au/bitcoin-core-dev/, http://gnusha.org/bitcoin-core-dev/ | Meeting topics http://gnusha.org/bitcoin-core-dev/proposedmeetingtopics.txt / http://gnusha.org/bitcoin-core-dev/proposedwalletmeetingtopics.txt
< core-meetingbot> Meeting ended Fri May 7 19:30:00 2021 UTC.
< 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> I think it's false
< roconnor> the consensus rule was 100 blocks, but the policy was 120.
< jeremyrubin> correct
< 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
< bitcoin-git> [bitcoin] hebasto opened pull request #21882: build: Fix undefined reference to __mulodi4 (master...210507-fuzz32) https://github.com/bitcoin/bitcoin/pull/21882
< gmaxwell> there was a time when libbitcoin was spewing uninitilized memory in the nversion field of transactions.
< conman> gmaxwell: thanks, went to bed so couldn't respond immediately, but appreciate your response
< gmaxwell> conman: No problem!
< conman> can I ask about coinbaseaux whilst I'm at it? Nothing seems to actually be coming from there any more
< conman> are there any plans for any scriptsig strings to come from there or can I assume it will be blank with the current bitcoin core?
< 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.
< sipa> phantomcircuit: agree
< conman> gmaxwell: gotcha
< luke-jr> conman: I was just pointing out it's been documented explicitly as *not* required since 2012 https://github.com/bitcoin/bips/blob/master/bip-0022.mediawiki
< bitcoin-git> [bitcoin] jaanauati opened pull request #21883: doc: remove 'experimental' word. (master...patch-1) https://github.com/bitcoin/bitcoin/pull/21883
< gmaxwell> heh. the see other PRs linked in the reply to that actually form a loop.
< bitcoin-git> [bitcoin] fanquake closed pull request #21883: doc: remove 'experimental' word. (master...patch-1) https://github.com/bitcoin/bitcoin/pull/21883