< bitcoin-git> [bitcoin] fanquake closed pull request #18661: Compress PNG images with `zopflipng`. (master...master) https://github.com/bitcoin/bitcoin/pull/18661
< hebasto> wumpus: if reasons for minimal libevent version 2.0.22 are unsure, it seems unsafe to allow build against 2.0.21, no?
< wumpus> as MarcoFalke says we have already allowed it forever
< wumpus> it works
< bitcoin-git> [bitcoin] meshcollider pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/969ee8549496...0856c1570679
< bitcoin-git> bitcoin/master 9b5950d Andrew Chow: bnb: exit selection when best_waste is 0
< wumpus> you are breaking it with your PR
< bitcoin-git> bitcoin/master 0856c15 Samuel Dobson: Merge #18262: bnb: exit selection when best_waste is 0
< bitcoin-git> [bitcoin] meshcollider merged pull request #18262: bnb: exit selection when best_waste is 0 (master...bnb-waste-zero) https://github.com/bitcoin/bitcoin/pull/18262
< wumpus> unless you intend to come up with a reason for that, which none of us really know for sure, that's hard to defend
< hebasto> wumpus: ok, going to set minimum to 2.0.21
< wumpus> thanks! if the fuzz test really turns out to be a problem to make compatible, you could just #ifdef it out for that version
< wumpus> but I don't know the error message they get
< wumpus> so that's why I recommended to enable building the fuzz tests on the xenial travis run so we can see
< wumpus> I see I still have a xenial VM myself, will try...
< icota> has anyone tried compiling libbitcoind.so since https://github.com/bitcoin/bitcoin/pull/5084 ?
< icota> i'm trying to use the rdynamic trick
< icota> i configure with: LDFLAGS='-rdynamic' --disable-reduce-exports --disable-tests --disable-bench --enable-debug --with-utils=no --with-gui=no --enable-shared
< icota> but i can't link my hello world against the resulting binary
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/0856c1570679...4a71c469058b
< bitcoin-git> bitcoin/master 69ffddc Sebastian Falbesoner: refactor: Remove unused methods CBloomFilter::reset()/clear()
< bitcoin-git> bitcoin/master 4a71c46 MarcoFalke: Merge #18670: refactor: Remove unused methods CBloomFilter::reset()/clear(...
< theStack> ad libevent 2.0.21: the problem is that the fuzz test http_request calls functions from libevent that are not part from the API, i.e. internal functions: evhttp_parse_firstline_
< emilengler> icota: Can you send a link to a pastebin with the error message?
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #18670: refactor: Remove unused methods CBloomFilter::reset()/clear() (master...20200416-refactor-remove-unused-bloom-filter-reset) https://github.com/bitcoin/bitcoin/pull/18670
< theStack> and those functions are named slightly different on libevent 2.0.21, the last underline is missing (at least on my system, ubuntu xenial)
< icota> emilengler: sure thing, https://pastebin.com/EmKEZcuP
< icota> it seems to be exporting std::cout amongst other symbols
< icota> i'd like to play with this. any clever way to stop it from exporting stdlib symbols?
< emilengler> icota: Can you try `LD_RUN_PATH=. g++ test.cpp -l:bitcoind -L.`
< icota> emilengler: same error
< emilengler> Maybe the problem is the argument order in your g++ invoke
< emilengler> `LD_RUN_PATH=. g++ test.cpp -L .-l:bitcoind`
< emilengler> Oh, please put a space between the dot before invoking -l
< emilengler> Mistake on my side...
< emilengler> Also is the colon required? I never saw a colon when invoking -l
< icota> no worries
< icota> colon is because the binary doesn't have a conventional name
< icota> libwhatever.so
< icota> it finds it, hence the erro
< icota> r
< meshcollider> what do we do with changes like #18466 which is API breaking
< gribble> https://github.com/bitcoin/bitcoin/issues/18466 | rpc: fix invalid parameter error codes for {sign,verify}message RPCs by theStack · Pull Request #18466 · bitcoin/bitcoin · GitHub
< meshcollider> The change looks correct but I also suspect we have to just keep incorrect error codes as-is
< bitcoin-git> [bitcoin] meshcollider pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/4a71c469058b...c189bfd260ca
< bitcoin-git> bitcoin/master 1abbdac Fabian Jahr: wallet: Prefer full destination groups in coin selection
< bitcoin-git> bitcoin/master a2324e4 Fabian Jahr: test: Improve naming and logging of avoid_reuse tests
< bitcoin-git> bitcoin/master c189bfd Samuel Dobson: Merge #17824: wallet: Prefer full destination groups in coin selection
< wumpus> theStack: thanks, that sounds easy to work around with an ifdef at least then :)
< bitcoin-git> [bitcoin] meshcollider merged pull request #17824: wallet: Prefer full destination groups in coin selection (master...i17603) https://github.com/bitcoin/bitcoin/pull/17824
< wumpus> meshcollider: if it's minor things, just mention it in the release notes
< wumpus> (and in this case it is, I don't have much of an optinion on the PR itself looks like it slightly improves consistency, though, no one has written strong guidelines when to use what RPC error code)
< meshcollider> Yeah, alright
< theStack> wumpus: yes, a preprocessor check should solve the problem for libevent 2.0.21
< meshcollider> promag: what's the status of #18471
< gribble> https://github.com/bitcoin/bitcoin/issues/18471 | qa: Test shared validation interface by promag · Pull Request #18471 · bitcoin/bitcoin · GitHub
< meshcollider> You asked for 0.20 milestone a while back, is it still important?
< wumpus> what in libc was blocking thread-local support, I have been unable to figure this out, compiled a few small C++ programs using __thread but didn't see any libc dependencies appear
< wumpus> the only tls-related libc function I could find is " __tls_get_addr@GLIBC_2.3", which would suggest libc 2.3
< bitcoin-git> [bitcoin] laanwj opened pull request #18681: donotmerge: build: Enable thread-local with glibc compat (master...2020_04_thread_local_compat) https://github.com/bitcoin/bitcoin/pull/18681
< fanquake> wumpus: I haven’t gone back to read the old threads, but a gitian build sounds like a good idea
< wumpus> right, probably most efficient way to find out :)
< fanquake> In regards to libevent 2.0.21. Also tried to find all the old discussion, my gut feeling was bugs that we were trying to avoid, maybe shutdown related. Haven’t got anything conclusive though
< fanquake> It's also possible in the mean time that we've done refactorings such that those concerns are no longer relevant.
< wumpus> given that everyone with xenial has been building against 2.0.21 and we got, afaik, zero complaints about that (besides the fuzzer build issue), it can't be *that* bad
< wumpus> yes, that's possible too
< wumpus> it highlights that it's kind of important to document *why* something is the minimum version somewhere, sure, it's always possible to find it between reams of commits and github comments, but for older projects that gets less and less efficient
< wumpus> #8639 does that ofcourse for most deps
< gribble> https://github.com/bitcoin/bitcoin/issues/8639 | Docs: Minimum required dependencies and current CVEs · Issue #8639 · bitcoin/bitcoin · GitHub
< wumpus> and in the case of libevent i'm sure no CVE was involved
< bitcoin-git> [bitcoin] MarcoFalke pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/c189bfd260ca...c2e53ff064df
< bitcoin-git> bitcoin/master bda84a0 Fabian Jahr: rpc: Add documentation for deactivating settxfee
< bitcoin-git> bitcoin/master 3867727 Fabian Jahr: rpc: settxfee respects -maxtxfee wallet setting
< bitcoin-git> bitcoin/master c2e53ff MarcoFalke: Merge #18467: rpc: Improve documentation and return value of settxfee
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #18467: rpc: Improve documentation and return value of settxfee (master...txfee0) https://github.com/bitcoin/bitcoin/pull/18467
< hebasto> theStack: on xenial trying to replicate compiling bug for fuzzing code. Currently, configure returns error: checking whether C++ compiler accepts -fsanitize=fuzzer,address,undefined... no
< hebasto> did you encounter it?
< hebasto> having system clang version 3.8.0-2ubuntu4 (tags/RELEASE_380/final)
< theStack> hebasto: i only tried with clang-8 so far, where the configure script didn't cause problems
< hebasto> theStack: ok, going to upgrade clang :)
< wumpus> clang-8 is a xenial package?
< theStack> i found out that libevent 2.1.1-alpha was the first release with internal functions renamed with underscore suffix
< theStack> see upcoming PR
< bitcoin-git> [bitcoin] theStack opened pull request #18682: fuzz: http_request workaround for libevent < 2.1.1 (master...20200417-fuzz-http-req-workaround-for-older-libevent) https://github.com/bitcoin/bitcoin/pull/18682
< hebasto> it seems GH has connection issues. Or just for me?
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #18683: ci: Disable valgrind functionl tests on forked repos to avoid timeouts (master...2004-ciTravisNoTimeout) https://github.com/bitcoin/bitcoin/pull/18683
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/c2e53ff064df...ecc2e4e363ee
< bitcoin-git> bitcoin/master eab7367 Jon Atack: fuzz: fix unused variable compiler warning
< bitcoin-git> bitcoin/master ecc2e4e MarcoFalke: Merge #18664: fuzz: fix unused variable compiler warning
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #18664: fuzz: fix unused variable compiler warning (master...fix-unused-variable-warning) https://github.com/bitcoin/bitcoin/pull/18664
< hebasto> wow! we have "Needs Guix build" label now. cool :)
< bitcoin-git> [bitcoin] jnewbery closed pull request #17562: Validation: Remove ConnectTrace and PerBlockConnectTrace (master...2019-11-remove-connect-trace) https://github.com/bitcoin/bitcoin/pull/17562
< promag> meshcollider: thanks for taking a look, needs rebase. don't worry
< bitcoin-git> [bitcoin] MarcoFalke pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/ecc2e4e363ee...54f812d9d298
< bitcoin-git> bitcoin/master fac5c37 MarcoFalke: scripted-diff: Sort test includes
< bitcoin-git> bitcoin/master fa488f1 MarcoFalke: scripted-diff: Bump copyright headers
< bitcoin-git> bitcoin/master fa4632c MarcoFalke: test: Move boost/stdlib includes last
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #18673: scripted-diff: Sort test includes (master...2004-testSortIncludes) https://github.com/bitcoin/bitcoin/pull/18673
< MarcoFalke> Does anyone run the tests locally? Is anyone seeing failures in wallet_dump?
< MarcoFalke> via the test_runner.py
< bitcoin-git> [bitcoin] jnewbery opened pull request #18685: [validation] Simplify ConnectTrace (master...2020-04-connecttrace-simplify) https://github.com/bitcoin/bitcoin/pull/18685
< jonatack> MarcoFalke: I run them locally. Rerunning now on master.
< MarcoFalke> They reproducibly fail for me, so either no one is running the tests or everyone has horribly slow machines or no one reports test failures
< MarcoFalke> They are broken for the last 3 days or so
< jonatack> yup it fails line 161
< jonatack> first run both via the runner and directly calling it
< MarcoFalke> Anyway, the fix is here: #18641
< gribble> https://github.com/bitcoin/bitcoin/issues/18641 | test: Create cached blocks not in the future by MarcoFalke · Pull Request #18641 · bitcoin/bitcoin · GitHub
< hebasto> wumpus: sipa: could block TBAALi-ros on GH ?
< bitcoin-git> [bitcoin] MarcoFalke pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/54f812d9d298...244daa482151
< bitcoin-git> bitcoin/master fa86a4b MarcoFalke: rpc: Rename first arg of generateblock RPC to "output"
< bitcoin-git> bitcoin/master fa5b1f0 MarcoFalke: rpc: Document all aliases for second arg of getblock
< bitcoin-git> bitcoin/master fa168d7 MarcoFalke: rpc: Document all aliases for first arg of listtransactions
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #18607: rpc: Fix named arguments in documentation (master...2004-rpcDoc) https://github.com/bitcoin/bitcoin/pull/18607
< dongcarl> Did we ever reach a conclusion about PPA organization?
< bitcoin-git> [bitcoin] hebasto opened pull request #18686: Fix -Wsign-compare warning on ARM 32-bit (master...200417-arm-sign) https://github.com/bitcoin/bitcoin/pull/18686
< bitcoin-git> [bitcoin] hebasto closed pull request #18686: Fix -Wsign-compare warning on ARM 32-bit (master...200417-arm-sign) https://github.com/bitcoin/bitcoin/pull/18686
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/244daa482151...d7bdba460cc0
< bitcoin-git> bitcoin/master faceeae MarcoFalke: ci: Disable valgrind functionl tests on forked repos to avoid timeouts
< bitcoin-git> bitcoin/master d7bdba4 MarcoFalke: Merge #18683: ci: Disable valgrind functionl tests on forked repos to avoi...
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #18683: ci: Disable valgrind functionl tests on forked repos to avoid timeouts (master...2004-ciTravisNoTimeout) https://github.com/bitcoin/bitcoin/pull/18683
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/d7bdba460cc0...c54295c1a206
< bitcoin-git> bitcoin/master fa32097 MarcoFalke: test: Create cached blocks not in the future
< bitcoin-git> bitcoin/master c54295c MarcoFalke: Merge #18641: test: Create cached blocks not in the future
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #18641: test: Create cached blocks not in the future (master...2004-qaNoCacheFuture) https://github.com/bitcoin/bitcoin/pull/18641
< sipa> fanquake: deleted comments from and blocked jasdeep9899
< midnight> go sipa \o/
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #18688: fuzz: Merge in parallel (master...2004-fuzzPar) https://github.com/bitcoin/bitcoin/pull/18688
< bitcoin-git> [bitcoin] pierreN opened pull request #18689: rpc: allow dumptxoutset to dump human-readable data (master...feature-utxo-ascii) https://github.com/bitcoin/bitcoin/pull/18689
< bitcoin-git> [bitcoin] robot-visions opened pull request #18690: test: Check object hashes in wait_for_getdata (master...wait-for-getdata) https://github.com/bitcoin/bitcoin/pull/18690
< bitcoin-git> [bitcoin] jonatack opened pull request #18691: test: fix intermittent error in interface_bitcoin_cli (master...fix-intermittent-credentials-issue) https://github.com/bitcoin/bitcoin/pull/18691
< captjakk> Currently the behavior of Bitcoin Core in a pruned state is to return an RPC error when a block is requested that has been pruned. I was thinking about working on a change that would allow Core to dynamically fetch a block it didn't have, and verify it against the retained headers. This ultimately implies a slight implementation change to the peer protocol, but at first glance this seems harmless and potentially very helpful
< captjakk> as we get to larger numbers of applications/protocols that depend on core. Does anyone know of a reason this would be bad?
< gwillen> that's kind of interesting. I'm not an expert so you should wait for one of those to chime in, but I expect this sort of thing mostly doesn't exist due to lack of demand?
< gwillen> you would need a more complicated scheme for managing pruning if you have random old blocks lying around because an RPC client wanted them, you'd want some kind of cacheing or pinning scheme, presumably you'd need new RPCs to implement that (not just make it implicit, it's too expensive an operation for that I think)
< captjakk> Here's why we want it. At Start9 We are building the Embassy which allows you to run a pruned node quite easily. Archives are necessary for some and helpful for everyone, but we want to make it such that running a full node that is usable by various wallets today does not necessitate full archives/txindex
< gwillen> I think it's rare to want single old blocks, do you have a specific place that's coming up?
< captjakk> Here's the situation
< captjakk> say you have a full node synced from genesis but it's pruned to only keep 5GB of data
< captjakk> if you want to add a new application, say, c-lightning, you either require a resync or it needs to be able to register itself with core to inform core to retain all blocks newer than a certain height
< captjakk> OR
< captjakk> it would need to be able to dynamically fetch a block that had been pruned
< captjakk> my understanding is that currently pruned nodes keep ALL block headers
< captjakk> even if the associated blocks have been long since purged
< sipa> <opinionated mode> applications that require access to historical blocks are broken, except for debugging/emergency recovery situations
< captjakk> even for new syncs?
< gwillen> well "new syncs" are why I asked about "random" blocks specifically
< sipa> a new wallet doesn't need access to old blocks, because its keys are new
< captjakk> OK so dynamic fetching may be unnecessarily expensive here
< gwillen> also, isn't "retain all blocks after a certain height" in fact already supported in RPC
< sipa> that said, i see no technical reason why implementing your suggestion would be a problem
< gwillen> so you might already have what you need
< captjakk> it needs to support it from multiple dependents
< captjakk> if I want both C-lightning and wasabi to share a full node, they need a way to deconflict the specification of which old blocks they need
< sipa> captjakk: there is a recently opened issue about multiple applications being able to register they need blocks, and letting them individually declare to be done up to block X
< captjakk> do you know what number? or the name of the rpc call?
< captjakk> (proposed)
< gwillen> for reference the mentioned issue is https://github.com/bitcoin/bitcoin/issues/18599
< captjakk> This was opened by my brother, I am the other commenter :)
< captjakk> captjakk == ProofOfKeags
< captjakk> haven't changed my irc handle yet
< gwillen> ah! hah.
< captjakk> But either way, great!
< captjakk> We are more than happy to develop this proposal/code it up
< gwillen> this seems like it may be a "patches accepted" situation -- that is, it's probably not too hard to write 'keepheight', but you might have to do it if you want it
< captjakk> I just wanted to check in to see if it may be controversial
< sipa> gwillen: well there already exists manual pruning mode
< sipa> where you need to issue an RPC to prune
< sipa> the issue is that this is "single user"
< captjakk> correct
< gwillen> right, so it seems like modifying it to track multiple "pins" wouldn't be too complex
< captjakk> because it pruning is done via positiva
< captjakk> great
< captjakk> again, we're happy to code it up
< sipa> patches welcome, as far as i'm concerned
< captjakk> cool!
< gwillen> I don't know if you've worked in the bitcoin core tree before, but in addition to https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md I highly recommend looking around under /doc/, especially /doc/productivity.md .
< captjakk> This will be the first code contributions we've made
< captjakk> so yes, any info on how to do this from a process standpoint is appreciated
< gwillen> cool, definitely read through CONTRIBUTING.md, whatever links from it look relevant, plus productivity.md, which has some big time-saving tips in it
< jonatack> good tips. also don't miss doc/developer-notes.md
< gwillen> honestly the whole 'doc' folder is good to skim for stuff that appears relevant
< gwillen> also I would consider fleshing out your proposed RPC interface and detailing it on the issue thread before you start coding too much, so people can comment on the design
< proofofkeags> yeah I figured
< gwillen> (probably come back here with a link once you have that)
< proofofkeags> is this something that should be detailed in the issue, or does it warrant a Bip
< proofofkeags> seems that since it's limited to RPC the bip isn't necessary
< proofofkeags> but I'm not sure what heuristic is used for bips
< sipa> proofofkeags: BIPs == things that require cross-application standards
< sipa> i don't think that's applicable here
< proofofkeags> cool, makes sense
< proofofkeags> so any change or addition to the peer protocol or address schemes and the like
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #18692: test: Bump timeout in wallet_import_rescan (master...2004-qaBumpTimeout) https://github.com/bitcoin/bitcoin/pull/18692
< sipa> P2P protocol changes, consensus changes, address formats, but also general things like standard derivation paths for keys, ...
< sipa> there is a BIP for the "bits" denomination
< proofofkeags> lol, I suppose that's fair
< sipa> changes to the BIP process itself (BIP 1, BIP 2)
< proofofkeags> cool, thanks for the input y'all
< yevaud> for a rare one, BIP50 is a report, not a change.
< sipa> ah, indeed
< yevaud> an incorrect report, but one none the less.
< proofofkeags> incorrect how?
< yevaud> it's conclusion is wrong, fundamentally. it suggests that the correct option was to encourage people to downgrade to 0.7, limit block size to 500KB, and increase the number of locks allowed in berkleydb.
< yevaud> simply, no version of Bitcoin before 0.8 was able to maintain consensus even between nodes of the same version. realistically there's no amount of increase in berkeleydb which can allow nodes to operate properly, and the number in that document is well, well below the value required even for the time.
< sipa> the document does mention "This would be an issue even if the entire network was running version 0.7.2. It is theoretically possible for one 0.7.2 node to create a block that others are unable to validate, or for 0.7.2 nodes to create block re-orgs that peers cannot validate, because the contents of each node's blkindex.dat database is not identical, and the number of locks required depends on the
< sipa> exact arrangement of the blkindex.dat on...
< sipa> disk (locks are acquired per-page). "
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/c54295c1a206...895c71e53557
< bitcoin-git> bitcoin/master 6f8b498 Sebastian Falbesoner: fuzz: http_request workaround for libevent < 2.1.1
< bitcoin-git> bitcoin/master 895c71e MarcoFalke: Merge #18682: fuzz: http_request workaround for libevent < 2.1.1
< yevaud> I've seen a few people argue based on BIP50 that if the locks are set to the value described, it is safe.
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #18682: fuzz: http_request workaround for libevent < 2.1.1 (master...20200417-fuzz-http-req-workaround-for-older-libevent) https://github.com/bitcoin/bitcoin/pull/18682
< yevaud> perhaps that's down to interpretation.
< sipa> due to the way locks were grabbed for an entire reorg, arguably for any finite value of the lock limits, pre-0.8 was unable to handle arbirarily long reorgs, which is arguably a consensus failure
< sipa> then again, i believe there have been plenty of other versions since 0.8 that also weren't practically capable of doing very deep (say 1000s of blocks) reorgs
< yevaud> true. in those versions reverting a UTXO change wrote back into the mempool for every block (or something close), it was excruciatingly slow.
< yevaud> I've attempted to sync 0.7 with 2**32 locks, it ends up failing consensus effectively at random. it was never clear exactly why.
< sipa> by unable i don't just mean infeasibly slow - i mean it'd go OOM
< yevaud> right. it would be an interesting exercise to get 0.7 to sync with the modern network, but it's in the order of months of sync time, even entirely in NVMe cache.
< yevaud> I'm not even confident it can process blocks fast enough to stay in sync at the head.
< sipa> haha, yes
< sipa> that too is arguably a consensus failure...
< yevaud> presumably if we had CPUs that were orders of magnitude faster, it would be consensus compatible again. sort of stretching the definition.
< gwillen> ugh, I hate the fact that every time some fucking altcoin brings over a commit that has my name in it, I get pinged
< gwillen> if anybody knows a way to prevent that I'd love to hear it
< sipa> i think we have some recommendation somewhere not to put @username in commit messages
< sipa> someone even suggested having a linter for it
< gwillen> welp
< fanquake> sipa: ok
< sipa> fanquake: were you... asleep?
< fanquake> Yes I was hah
< fanquake> Can you also block amirabbaska
< sipa> done
< achow101> fanquake sleeps? that's new :p
< sipa> it must be a sporadic activity
< dongcarl> achow101: You see, he has a secondary brain directly attached to an X server, which never sleeps
< sipa> dongcarl: his computer?
< dongcarl> XD
< jonatack> :D
< bitcoin-git> [bitcoin] hebasto opened pull request #18695: test: Replace boost::mutex with std::mutex (master...200417-boost-mu) https://github.com/bitcoin/bitcoin/pull/18695
< hebasto> IIUC, it seems our unit tests ignore the case when g_parallel_script_checks=false. Is it intended?