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