< kallewoof>
I am looking for ZMQ dumps or any other format of log files showing when transactions enter/exit the mempool, as well as when blocks are mined (although the
< kallewoof>
latter can be deduced with some work). If anyone has dumps let me know. I have most of this year covered but missing most of January.
< bitcoin-git>
[bitcoin] murrayn opened pull request #13476: Fix incorrect shell quoting in FreeBSD build instructions. (master...freebsd-doc) https://github.com/bitcoin/bitcoin/pull/13476
< provoostenator>
Are there any WIP branches or proposals / discussions regarding partial functionality while IBD is in progress?
< provoostenator>
And the various security trade-offs. For example showing a freshly generated receive address seems perfectly safe vs. trusting the mempool when the address receives funds very unsafe.
< provoostenator>
But perhaps, after a header sync, temporarily assuming the most recent block is valid and validating all new blocks (while IBD catches up), would give at least some confidence that the funds are actually there if confirmed.
< provoostenator>
Scarier, but very interesting if possible, would be if you can open a lightning channel, either where it's purely your own funds at stake and you only spend those, or the reverse where only the other side spends.
< provoostenator>
I'm aware of #9483 but this would be orthogonal to any SPV or even neutrino stuff.
< provoostenator>
Use case is basically: user just bought some low power ARM device, a smart phone or Pi, which needs a week to do initial sync. During IBD such a device is useless, so everyone uses light-weight clients, even though long term it might be perfectly capable of staying in sync as a full node. So that 1 week experience causes a poor long term trade-off.
< provoostenator>
It could even spend 5 minutes downloading and partially validating the most recent 300 blocks; obviously it doesn't know the UTXO set, but at least it can check against complete nonsense.
< provoostenator>
Argh, this is the second time I misinterpreted the title of 9483, and agree with Luke's comment at the top. Will study it a bit more closely.
< fanquake>
wumpus: You must have just about ripped out every trace of Qt4 now..
< wumpus>
fanquake: I hope I pulled it out with all roots now, though it seems more pervasive then I thought
< fanquake>
wumpus Your doing a good job so far. I've been looking at the leftover QT_VERSION related code, I think we'll be able to clean it up a lot further after that PR is merged.
< wumpus>
but I'm happy people are looking for all remaning traces of it, better to to this in one go
< fanquake>
Although going to depend somewhat on where we set the minimum required Qt
< fanquake>
Just looking at Qt "supported versions", the lowest version of qt5 that is still supported is 5.6 (LTS), and that ends in March 2019.
< fanquake>
5.9 (LTS), which we might move depends too, is supported until May 2020
< wumpus>
I think we should try to support as many versions as possible, unless there's good reason not to
< fanquake>
Obviously not saying we have to jump to 5.9 as a minimum.. but Qt's release frequency is getting quite aggressive
< wumpus>
yes, agreed
< fanquake>
Wondering if someone will volunteer to compile with increasingly older versions of Qt5, until something breaks :p
< wumpus>
someone must be using debian stable or some othe rdistro with an old qt
< fanquake>
Pretty sure everyone running Core is using Debian sid and the master branch on GH? Alleviating the need to support anything older than a few weeks
< fanquake>
wumpus Opened #13478 for qt5 minimum discussion, will add some more thoughts a bit later
< provoostenator>
fanquake: "not far away" points back to the issue itself
< provoostenator>
I can do some testing with older QT5 versions on macOS, though on macOS it seems unlikely users can't upgrade to Qt5-fairly-recent, except if they have old (e.g. 32 bit) machines: http://doc.qt.io/qt-5/osx.html#macos-versions
< bitcoin-git>
bitcoin/master 9b72c98 Ben Woosley: scripted-diff: Avoid temporary copies when looping over std::map...
< bitcoin-git>
bitcoin/master be27048 MarcoFalke: Merge #13241: scripted-diff: Avoid temporary copies when looping over std::map...
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #13241: scripted-diff: Avoid temporary copies when looping over std::map (master...pair-const-key) https://github.com/bitcoin/bitcoin/pull/13241
< harding>
wumpus: release PR for the website updated to use correct dates and magnet URI, and it now passes Travis. It needs you, jonasschnelli, or jnewbery to Approve PR for me to be able to merge.
< wumpus>
harding: ACKed
< harding>
wumpus: thanks! Merging momentarily.
< cfields>
Empact: neat! Nice work.
< cfields>
Empact: turns out clang has a warning for those. Mind if i go ahead and clean up the rest, and add the warning?
< cfields>
Empact: turned out to be trivial, I'm just going to go ahead and PR it.
< bitcoin-git>
[bitcoin] theuni opened pull request #13480: Avoid copies in range-for loops and add a warning to detect them (master...no-for-copies) https://github.com/bitcoin/bitcoin/pull/13480
< bitcoin-git>
bitcoin/master cf01fd6 Chun Kuan Lee: Avoid concurrency issue
< bitcoin-git>
bitcoin/master 81069a7 MarcoFalke: Merge #13465: Avoid concurrency issue when make multiple target...
< provoostenator>
Doesn't #11423 deserve slightly more emphasis in the release notes? E.g. "Disables OP_CODESEPARATOR in non-segwit scripts, make positive FindAndDelete result invalid, reject transaction smaller than 82 bytes (non-segwit size."