< 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?
< 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>
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
< 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
< 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
< 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
< 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
< 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
< 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.
< 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/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