< dviola> I'm confused
< achow101> dviola: the tarballs you download from bitcoincore.org are signed. I think luke-jr is talking about the tarballs that github generates for tags
< dviola> oh
< dviola> I see
< dviola> if I compile from git then I don't need to verify anything, right?
< dviola> i.e. if I clone from https://github.com/bitcoin/bitcoin.git
< achow101> you should at least check the tag signature
< achow101> you can also do a gitian build and check that your result matches the published binaries
< luke-jr> dviola: if you blindly trust GitHub, their security, and each and every maintainer
< luke-jr> or only check out a tag like achow101 suggests
< dviola> I don't trust github
< dviola> I'll just use the tarballs for now :P
< bitcoin-git> [bitcoin] hebasto opened pull request #17606: qt, refactor: Use proper classes for Ui::* (master...20191125-fix-ui-baseclass) https://github.com/bitcoin/bitcoin/pull/17606
< dviola> git verify-tag v0.19.0.1 tells me: gpg: Can't check signature: No public key
< dviola> which key do I have to import?
< achow101> those are the maintainers' PGP fingerprints
< dviola> hrm
< dviola> I'm not very familiar with gpg :/
< dviola> 71A3B16735405025D447E8F274810B012346C9A6
< dviola> how do I use it to verify the tag?
< dviola> --recv-keys did the trick
< dviola> so verify-tag tells me "good signature", is that all I have to do to verify the tag?
< luke-jr> dviola: you also need to be sure that's the correct key you trust
< luke-jr> dviola: for now, I suggest finding a video where one of them gave a presentation with their key visible in the slides
< luke-jr> ideally, verify in the flesh
< bitcoin-git> [bitcoin] meshcollider pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/2c1c43754b7a...0ee914ba9e59
< bitcoin-git> bitcoin/master 1a3a256 Harris: wallet: replace raw pointer with const reference in AddrToPubKey
< bitcoin-git> bitcoin/master 0ee914b Samuel Dobson: Merge #17584: wallet: replace raw pointer with const reference in AddrToPu...
< bitcoin-git> [bitcoin] meshcollider merged pull request #17584: wallet: replace raw pointer with const reference in AddrToPubKey (master...rpcwallet-redundant-pointer-conversion) https://github.com/bitcoin/bitcoin/pull/17584
< wumpus> dviola: FWIW rcs have tarballs and binaries too https://bitcoincore.org/bin/bitcoin-core-0.19.0/test.rc3/
< wumpus> the tarball is a subset of the repository contents, for obscure GNU legacy reasons, we're working on making it a full archive (see #17104), the contents of the tarball should be enough to build your own binaries though
< gribble> https://github.com/bitcoin/bitcoin/issues/17104 | build: `make dist` uses `git archive` by ch4ot1c . Pull Request #17104 . bitcoin/bitcoin . GitHub
< bitcoin-git> [bitcoin] promag opened pull request #17611: gui: Make send and receive widgets extend QWidget (master...2019-11-send-receive-widgets) https://github.com/bitcoin/bitcoin/pull/17611
< dviola> luke-jr: alright, thanks
< dviola> wumpus: thanks
< bitcoin-git> [bitcoin] fanquake pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/0ee914ba9e59...f2ab1309619b
< bitcoin-git> bitcoin/master 8781904 Hennadii Stepanov: qt: Fix class name of Ui::ModalOverlay
< bitcoin-git> bitcoin/master 93352d2 Hennadii Stepanov: qt: Use proper class for Ui::ReceiveCoinsDialog
< bitcoin-git> bitcoin/master f2ab130 fanquake: Merge #17606: qt, refactor: Use proper classes for Ui::*
< bitcoin-git> [bitcoin] fanquake merged pull request #17606: qt, refactor: Use proper classes for Ui::* (master...20191125-fix-ui-baseclass) https://github.com/bitcoin/bitcoin/pull/17606
< jnewbery> MarcoFalke, wumpus: #17283 seems ready for merge (5 ACKs total, 2 on the current head commit). It's also just a documentation and test change
< gribble> https://github.com/bitcoin/bitcoin/issues/17283 | rpc: improve getaddressinfo test coverage, help, code docs by jonatack . Pull Request #17283 . bitcoin/bitcoin . GitHub
< fanquake> I enjoy how that PR has managed to introduce yet another way to describe epoch time in the RPC output
< jonatack> fanquake: can revert/change that, if desired, in #17578
< gribble> https://github.com/bitcoin/bitcoin/issues/17578 | rpc: simplify getaddressinfo labels, deprecate previous behavior by jonatack . Pull Request #17578 . bitcoin/bitcoin . GitHub
< jonatack> fanquake: unsure which version of Epoch Time is the standard, though :)
< fanquake> I don't really care
< fanquake> There's currently "since epoch", "epoch (Jan 1 1970 GMT)", "Unix seconds-since-epoch", "since epoch (midnight Jan 1 1970 GMT)", "(seconds since Unix epoch)", and we'll be adding "since Epoch Time (Jan 1 1970 GMT)"
< fanquake> I'm probably missing some too
< jonatack> hehe, will pick one
< bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/f2ab1309619b...4fb82e916b3b
< bitcoin-git> bitcoin/master 27d82b6 fanquake: gui: remove macOS start on login code
< bitcoin-git> bitcoin/master 4fb82e9 fanquake: Merge #17567: gui: remove macOS start on login code
< bitcoin-git> [bitcoin] fanquake merged pull request #17567: gui: remove macOS start on login code (master...remove_macos_startup_item) https://github.com/bitcoin/bitcoin/pull/17567
< wumpus> jnewbery: agree
< MarcoFalke> Yeah, we should probably clarify that all times in Bitcoin are not clocks (e.g. the c++11 clock), but durations measured from epoch
< wumpus> fanquake: FWIW I think "UNIX epoch time" in itself should be enough, it's not really the domain of RPC documentation to explain things like that
< MarcoFalke> Maybe pull it out into a string, so that it is at least consistent
< wumpus> a simple google/wikipedia query can give all the details on that
< wumpus> yeah
< MarcoFalke> Agree that "UNIX epoch time" or something short should be sufficient
< fanquake> ?
< MarcoFalke> s/c++11 clocks/ c++11 time points/
< jonatack> +1
< fanquake> good-first-issued it in #17613. Maybe someone will see the tweet and fix it for us.
< gribble> https://github.com/bitcoin/bitcoin/issues/17613 | doc: unify epoch time description in RPC output . Issue #17613 . bitcoin/bitcoin . GitHub
< jonatack> In RPCExamples, is there a norm between providing real addresses, versus invalid ones?
< aj> MarcoFalke: i could see having two different chrono::time_points/clocks to distinguish mockable and non-mockable time fwiw
< jonatack> I wondered when updating the getaddressinfo example to bech32.
< sipa> MarcoFalke: how is it possible that s390x is faster than most other platforms?
< sipa> is it running on an actual IBM supercomputer? :s
< bitcoin-git> [bitcoin] laanwj pushed 8 commits to master: https://github.com/bitcoin/bitcoin/compare/4fb82e916b3b...d8a66626d631
< bitcoin-git> bitcoin/master 70cda34 Jon Atack: rpc: improve getaddressinfo RPCHelpman formatting
< bitcoin-git> bitcoin/master 5a0ed85 Jon Atack: rpc: improve getaddressinfo RPCHelpman content
< bitcoin-git> bitcoin/master 8d1ed0c Jon Atack: rpc: clarify label vs labels in getaddressinfo RPCHelpman
< aj> MarcoFalke: (i tried it out a bit. one downside is that due to c++ lameness, you can't have atomic<time_point>. otherwise it's kind of invasive, in the same way switching to durations is, but seems to work ok)
< bitcoin-git> [bitcoin] laanwj merged pull request #17283: rpc: improve getaddressinfo test coverage, help, code docs (master...rpc-getaddressinfo-labels) https://github.com/bitcoin/bitcoin/pull/17283
< bitcoin-git> [bitcoin] petterhs opened pull request #17614: rpc: fix failure calling dumptxoutset with invalid filename (master...fix-rpc-dumptxoutset) https://github.com/bitcoin/bitcoin/pull/17614
< bitcoin-git> [bitcoin] brakmic opened pull request #17615: rpc: check for irregular files in dumptxoutset (master...dumptxoutset-invalid-file-error) https://github.com/bitcoin/bitcoin/pull/17615
< bitcoin-git> [bitcoin] petterhs closed pull request #17614: rpc: fix failure calling dumptxoutset with invalid filename (master...fix-rpc-dumptxoutset) https://github.com/bitcoin/bitcoin/pull/17614
< dviola> can I run a node from git master, or not recommended?
< jarthur> A fine node for testnet. For mainnet... *shrug*
< dviola> hrm
< jonatack> dviola: this may be a poor example to follow, but i test nodes on master and PR branches all the time (with very small/symbolic amounts in them) on mainnet
< vasild> Why not on mainnet too? Else how will new code be tested on mainnet? Putting (many) BTC in it is another question.
< jonatack> ^
< jonatack> for dev purposes though. most people should probably only test release candidates, i suppose.
< jonatack> which would already be very helpful
< jarthur> In theory, what's in master has been accepted in both concept and code by other developers and has been tested. It hasn't baked as long in a features-frozen state, so might have slightly higher risk of A) participating in an accidental soft or hard fork. or B) loss of funds. The risk of an accidental fork damaging the network is made higher the higher number of nodes running from master there are.
< jarthur> https://bitnodes.earn.com/nodes/?q=Satoshi:0.19.99 are some folks that might be running master or an preliminary release of some sort.
< ysangkok> jarthur: "more master implies more forking" implies that master actually hard forks and those forks are fixed before the rc process. how often did that happen in the past?
< sipa> as far as i know, once
< sipa> before 0.8
< sipa> eh, 0.10
< sipa> though found by improved p2p tests, not rc procesz
< ysangkok> i guess it is very subjective and dependent on how afraid of hard forks you are, and how much you desire more testers. i always hear people complaining about the lack of testing in code review. it is never explicitly explained how this reconciles with an advice against running off master
< jarthur> ysangkok: I'm definitely not advising against running off master. Depending on what the goals of your node are (e.g. testing some code in real-world scenarios), it might the exact correct thing to do.
< ysangkok> all right, happy to hear that, mostly because i think of master of pretty stable and i want that view confirmed :P
< ysangkok> (speaking as someone not financially invested)
< bitcoin-git> [bitcoin] jonatack opened pull request #17617: rpc: replace varying UNIX time strings with a constant (master...unix-epoch-time-consistency) https://github.com/bitcoin/bitcoin/pull/17617
< dviola> jonatack: I see, interesting
< dviola> I might do something similar in the future