< esotericnonsense> what's the recommended way to construct transactions via RPC if you want to confirm the amounts involved before sending?
< esotericnonsense> createrawtransaction, decoderawtransaction?
< sipa> esotericnonsense: createraw, fundraw, signraw, sendraw
< luke-jr> It's pretty fun to draw transactions.
< sipa> esotericnonsense: or (at your own risk, there are some kinks), walletcreatefundedpsbt, decodepsbt, walletprocesspsbt, finalizepsbt, sendrawtransaction
< sipa> decodepsbt will also show things like fee
< esotericnonsense> hm. so when createrawtransaction states that inputs are required, it actually just means the parameter
< esotericnonsense> e.g. it's reasonable to "createrawtransaction [] ..." and then fund it
< sipa> esotericnonsense: probably move to #bitcoin
< zhangzf> Hi everybody! Bitcoin core can run on Android?
< phantomcircuit> zhangzf, https://github.com/greenaddress/abcore
< zhangzf> phantomcircuit, Thanks
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #14726: Use RPCHelpMan for all RPCs (master...Mf1810-rpcHelpMan) https://github.com/bitcoin/bitcoin/pull/14726
< zhangzf> #bitcoin
< zhangzf> The ABCore download all the blocks and cann't run on 3G or 4G networks
< zhangzf> Can I set it run as a spv node?
< sipa> zhangzf: no, Bitcoin Core always runs as a full node
< zhangzf> sipa, Thanks.
< gmaxwell> zhangzf: it can run on 3g/4g networks fine, though it transfers a lot of data for the initial sync to it would probably be best to do that over wifi.
< zhangzf> Where is a wallet it can run as spv node, it do not download all the blocks, it just connect a server get the data.
< booyah> zhangzf: electrum is popular wallet, works on androids too
< zhangzf> booyah, Thanks.
< booyah> zhangzf: also, with such usage questions come to #bitcoin - there are more users to help. Also this channel here is only for developers of bitcoin itself so it's not good to ask here
< zhangzf> booyah, Ok. I got it.
< shanmugam> Ho
< shanmugam> any BTC Testnet wallet accessable online
< shanmugam> any BTC Testnet wallet accessable online
< wumpus> not sure how you mean that, but if you need testnet coins just say so and someone will send you some
< wumpus> MarcoFalke: thanks
< meshcollider> wumpus: #14698 looks RTM
< gribble> https://github.com/bitcoin/bitcoin/issues/14698 | build: Add bitcoin-tx.exe into Windows installer by ken2812221 · Pull Request #14698 · bitcoin/bitcoin · GitHub
< wumpus> has anyone used the python type-annotation stuff yet? just curious about it
< wumpus> meshcollider: thanks
< wumpus> (I mean PEP 484/526 "type hinting")
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/8c59bb85f979...33cd94279cd6
< bitcoin-git> bitcoin/master 5c5902a Chun Kuan Lee: build: Add bitcoin-tx.exe into Windows installer
< bitcoin-git> bitcoin/master 33cd942 Wladimir J. van der Laan: Merge #14698: build: Add bitcoin-tx.exe into Windows installer...
< bitcoin-git> [bitcoin] laanwj closed pull request #14698: build: Add bitcoin-tx.exe into Windows installer (master...win-bitcoin-tx) https://github.com/bitcoin/bitcoin/pull/14698
< fanquake> wumpus a little, although not on anything btc related
< fanquake> Hopefully something that'll end up in the test framework
< wumpus> fanquake: yes I was asking in general, not so much btc related, does it help catch mistakes at 'compile' time?
< wumpus> (e.g. before the program even runs?)
< fanquake> wumpus you add the "type hints", then can use something like http://mypy-lang.org/, to do the checking
< wumpus> or well.. guess linters use the information for a kind of static checking?
< wumpus> right
< fanquake> As soon as we require Python >3.5, we could probably start using it in some capacity https://docs.python.org/3/library/typing.html
< wumpus> so that part isn't integrated into python 3.5+, just the type annotation module
< wumpus> yes, exactly
< fanquake> Correct, mypy is an external tool
< wumpus> thanks, that's kind of what I wanted to know! I see we require python 3.4 at the moment, so it's just one minor version away
< fanquake> wumpus np
< wumpus> ___llvm_gcov_writeout?!
< wumpus> (#14727)
< gribble> https://github.com/bitcoin/bitcoin/issues/14727 | Mac OSX High Sierra 10.13.6 Build error · Issue #14727 · bitcoin/bitcoin · GitHub
< wumpus> looks like they inadvertently enable a coverage checker (but no such mention in the build steps)
< wumpus> then don't link against its runtime
< fanquake> Looks like it doesn't even finish compiling?
< wumpus> it fails during link of bitcoind
< fanquake> ah yea
< fanquake> #14723 I don't think we've ever (even tried) to support the official Qt installed binaries. At least, we call it out as not working on macOS
< gribble> https://github.com/bitcoin/bitcoin/issues/14723 | Build with official Qt binary installer fails · Issue #14723 · bitcoin/bitcoin · GitHub
< wumpus> no, I don't think so either, just the homebrew
< wumpus> we document that in the build instructions as far as I know, if people try unsupported stuff that's fine but it probably doesn't warrant an issue
< fanquake> wumpus I think 14725 is ok to merge
< wumpus> yes
< fanquake> Release notes, and possibly a further bump?, can come later on
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/33cd94279cd6...74213fa4d13e
< bitcoin-git> bitcoin/master 2bc3f11 Hennadii Stepanov: Bump the minimum Qt version to 5.2
< bitcoin-git> bitcoin/master 74213fa Wladimir J. van der Laan: Merge #14725: qt: Bump the minimum Qt version to 5.2...
< bitcoin-git> [bitcoin] laanwj closed pull request #14725: qt: Bump the minimum Qt version to 5.2 (master...20181113-bump-qt52) https://github.com/bitcoin/bitcoin/pull/14725
< wumpus> well at least this is is non-controversial, 5.2 is old as the hills
< murrayn> lol
< fanquake> wumpus I've updated 13478 and added a release notes tag as a reminder
< fanquake> Just realised that pr should have bump qt in dependencies.md heh
< wumpus> discussion in #13478 was mostly agreeing on 5.4/5.5 until someone came and apparently screamed that 5.2.1 is LTS and offered to pay for longer term support, now everyone is just confused
< gribble> https://github.com/bitcoin/bitcoin/issues/13478 | [RFC] gui: Minimum required Qt5 · Issue #13478 · bitcoin/bitcoin · GitHub
< fanquake> I can't imagine we'll stick with 5.2.1, no pay for any support
< fanquake> *nor
< wumpus> personally I think in the case of the GUI (moreso than say, boost) it would make sense to narrow down the supported versions and make sure things work *really well* with them, instead of having a long range of supported versions which probably no one really checks
< wumpus> e.g., as automated testing is more or less out of the question, and there is tons of so-so workarounds
< murrayn> yes, agreed
< wumpus> there's so many interactions between operating systems and UI, say newer features such as HiDPY, environments that may or may not support tray icons, and so on
< fanquake> wumpus Last two LTS versions would be 5.6 and 5.9, so should we make the minimum 5.6 in 0.18.0?
< wumpus> I guess it will be even worse for MacOSX once Qt supports the dark mode properly, and we signal support for it in the descriptor, that will pretty much mean there's only one supported version
< fanquake> However, 5.12 LTS will be released befoer 0.18.0, so could make it 5.9+?
< fanquake> Yea that'll start to get a bit messy
< fanquake> and use 5.12 in depends etc
< wumpus> (luckily that iis irrelevalt for other platforms...)
< wumpus> fanquake: hehe, that's yet another proposal
< wumpus> fanquake: would make sense to me though
< wumpus> maybe hebasto can tell us what he's using 5.2.1 for and why
< wumpus> anyhow this is an endless discussion, glad we got agreed on at least 5.2 ;-)
< fanquake> heh
< fanquake> wumpus #14701 is a trvial change, but one that fixes some user confusion
< gribble> https://github.com/bitcoin/bitcoin/issues/14701 | build: Add CLIENT_VERSION_BUILD to CFBundleGetInfoString by fanquake · Pull Request #14701 · bitcoin/bitcoin · GitHub
< wumpus> fanquake: would you want to add the RC as well?
< wumpus> or wait, didn't we merge something that keeps track of RCs in configure.ac?
< wumpus> oh that's #14612
< gribble> https://github.com/bitcoin/bitcoin/issues/14612 | Include full version number in released file names by achow101 · Pull Request #14612 · bitcoin/bitcoin · GitHub
< wumpus> might want to hold it off until that's merged
< fanquake> wumpus makes sense
< fanquake> I think #14704 is ok to go as well
< gribble> https://github.com/bitcoin/bitcoin/issues/14704 | doc: add detached release notes for #14060 by mruddy · Pull Request #14704 · bitcoin/bitcoin · GitHub
< fanquake> Also #14688
< gribble> https://github.com/bitcoin/bitcoin/issues/14688 | Doc: update release notes for changes since 0.17.0 branch by harding · Pull Request #14688 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/74213fa4d13e...99a3e6f0b1ab
< bitcoin-git> bitcoin/master 6062f0e David A. Harding: Release notes: update notes through to 11e1ac3ae08
< bitcoin-git> bitcoin/master ba8f0c6 David A. Harding: Release notes: integrate detached release notes
< bitcoin-git> bitcoin/master 99a3e6f Wladimir J. van der Laan: Merge #14688: Doc: update release notes for changes since 0.17.0 branch...
< bitcoin-git> [bitcoin] laanwj closed pull request #14688: Doc: update release notes for changes since 0.17.0 branch (master...2018-11-release-notes) https://github.com/bitcoin/bitcoin/pull/14688
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/99a3e6f0b1ab...2e8f9dc2bbb1
< bitcoin-git> bitcoin/master 86cddf0 mruddy: doc: add detached release notes for #14060
< bitcoin-git> bitcoin/master 2e8f9dc Wladimir J. van der Laan: Merge #14704: doc: add detached release notes for #14060...
< bitcoin-git> [bitcoin] laanwj closed pull request #14704: doc: add detached release notes for #14060 (master...zmq-release-notes) https://github.com/bitcoin/bitcoin/pull/14704
< wumpus> kind of forgot that the plist is programatically generated, so once dark mode support lands in qt it could set NSRequiresAquaSystemAppearance based on the qt version built against; that won't avoid having to add a very recent Qt into depends but at least it doesn't have to restrict the supported versions
< fanquake> Looks like any accessibility concerns are addressed in #14577. ACK from jonass as well
< gribble> https://github.com/bitcoin/bitcoin/issues/14577 | qt: Cleanup `textInteractionFlags` for `QLabel` by hebasto · Pull Request #14577 · bitcoin/bitcoin · GitHub
< wumpus> yea, I still think "ripping out partial accessibility support with the idea (but not promise) to add it back in fully later" is kinda lousy, but ok...
< wumpus> especially as the whole PR only about asthetic concerns
< wumpus> but Jonas is GUI maintainer he can merge if he wants
< fanquake> #14594 😬
< gribble> https://github.com/bitcoin/bitcoin/issues/14594 | qt: Fix minimized window bug on Linux by hebasto · Pull Request #14594 · bitcoin/bitcoin · GitHub
< wumpus> AHHH
< wumpus> I'm not going into that, sorry
< wumpus> "it's broken, have you tried toggling window visibility to hidden and back to show?"
< gmaxwell> Groundhog day: IRC edition
< fanquake> I downloaded a mint vm, and will test, but can't be sure nothing else breaks.
< fanquake> gmaxwell, while you are here, was wondering if you could give any pointers/guidance for testing #14624? Seems like it's be nit-picked to death already.
< gribble> https://github.com/bitcoin/bitcoin/issues/14624 | Some simple improvements to the RNG code by sipa · Pull Request #14624 · bitcoin/bitcoin · GitHub
< wumpus> travis failing badly, but seems a problem on their side (problems downloading packages!)
< simondodsley_> /!\ ATᎢN: Thіѕ chаᥒᥒᥱl haѕ movеd to ⅰrс.frᥱenode.ᥒet #/joіᥒ /ǃ⧹
< simondodsley_> Ꮤіth our IᏒC ɑd sᥱrviϲᥱ yоᥙ ⅽaᥒ reɑϲh а ɡⅼobaⅼ аᥙdіеnce of ᥱntreрrеᥒe∪rѕ аnd fеntanyl adԁictѕ wⅰth extraοrdiᥒary enɡageⅿᥱnt ratеsⵑ httрs://ᴡіⅼⅼiaⅿpіtcoⅽk.coⅿ/
< simondodsley_> І tһo∪ght yoᥙ guyѕ ⅿight bе intеrestᥱԁ in thіѕ bⅼoɡ by freеnഠԁe staff ⅿember Brỿɑᥒ kⅼoеrі Ostergɑɑrd httрs:/∕brỿanoѕterɡɑɑrⅾ.coⅿ/
< simondodsley_> Rеɑd ᴡhаt IᏒC іnveѕtigɑtⅰve ϳourᥒaⅼⅰsts hɑvе unco∨ered on tһе frеeᥒode pedoрһіlia ѕⅽandaⅼ https://ᥱncусlⲟpеԁiadrɑmɑtіⅽa.rѕ/Freenⲟԁеɡаtе
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/2e8f9dc2bbb1...c7366d2399e2
< bitcoin-git> bitcoin/master b4f6e58 MeshCollider: Better error message for user when corrupt wallet unlock fails
< bitcoin-git> bitcoin/master c7366d2 MarcoFalke: Merge #14478: Show error to user when corrupt wallet unlock fails...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #14478: Show error to user when corrupt wallet unlock fails (master...201810_wallet_corruption_error) https://github.com/bitcoin/bitcoin/pull/14478
< bitcoin-git> [bitcoin] MarcoFalke pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/c7366d2399e2...e74649e95122
< bitcoin-git> bitcoin/master 65b740f Russell Yanofsky: [wallet] Restore ability to list incoming transactions by label...
< bitcoin-git> bitcoin/master da427db Russell Yanofsky: Rename ListTransactions filter variable...
< bitcoin-git> bitcoin/master e74649e MarcoFalke: Merge #14411: [wallet] Restore ability to list incoming transactions by label...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #14411: [wallet] Restore ability to list incoming transactions by label (master...pr/list-label) https://github.com/bitcoin/bitcoin/pull/14411
< core_> i am just starting with bitcoin core and I'm a little confused with the architecture
< core_> specifically how the client wallet fits in and connects to what pieces of the system (as shown in mastering bitcoin architecture diagram)
< phantomcircuit> core_, mastering bitcoin is basically just a copy of the wiki
< phantomcircuit> and is randomly completely wrong
< instagibbs> sipa, is SignatureData still the "supported" way to carry around signature data internally, or is there thought of moving to PSBT long-term?
< instagibbs> Some stuff connected to SignatureData have dire warnings about extending them, so thought I'd ask for clarity :)
< phantomcircuit> sipa, also, using std::swap for a single call to std::swap?
< phantomcircuit> but why
< sipa> instagibbs: where?
< instagibbs> sipa, DataFromTransaction, but this might be the only thing with the dire warning
< instagibbs> ripping out sigs from standing transactions, combining, etc
< sipa> instagibbs: SignatureData is perfectly supported, but is an internal structure (it's not specific to transactions)
< sipa> DataFromTransaction does something crazy, it tries to figure out partially signed data from a transaction
< instagibbs> Exactly what I wanted to hear, thanks
< sipa> which shouldn't be ever needed in a post-PSBT world
< sipa> in PSBT land, you never put signatures in a transaction until they're all valid
< gwillen> instagibbs: PSBT makes use of SignatureData heavily in the signing path
< gwillen> (the actual way by which this happens feels quite convoluted to me, I dug into it to make sure I understood what was happening in Finalize)
< sipa> i think you can see SignatureData as the internal non-transaction-specific way of representing things, while PSBT is the transaction-specific interchangeable way
< bitcoin-git> [bitcoin] kazcw opened pull request #14728: fix uninitialized read when stringifying an addrLocal (master...uninit-scopeid) https://github.com/bitcoin/bitcoin/pull/14728