< bitcoin-git> [bitcoin] fanquake opened pull request #12095: [contrib] Use BDB_LIBS/CFLAGS and pass --disable-replication (master...db4-script-flags) https://github.com/bitcoin/bitcoin/pull/12095
< phantomcircuit> so there are a lot of peers which are sending transactions even when you're in blocksonly mode
< phantomcircuit> would there be any opposition to banning those peers?
< achow101> phantomcircuit: aren't they supposed to be banned?
< BlueMatt> phantomcircuit: I mean you have to do *something* for eg spv peers...at a minimum would need to bump protocol version and only apply to peers over that version, or have some additional handshake message
< echeveria> BlueMatt: blocksonly should really be implying peerbloomfilters=0 anyway.
< BlueMatt> echeveria: why?
< BlueMatt> echeveria: you mean because its implied "low-bandwidth-dont-serve-others" mode?
< phantomcircuit> BlueMatt, iirc the version was already bumped
< phantomcircuit> it sets the flag in the version message which was part of the bip37 changes originally
< phantomcircuit> echeveria, not sure it matters, the only thing you'll filter on is mempool requests and you dont have a mempool
< phantomcircuit> so
< phantomcircuit> \_(``/)_/-
< phantomcircuit> oh you'll filter blocks
< phantomcircuit> derp
< phantomcircuit> yeah
< phantomcircuit> im hungry
< echeveria> BlueMatt: they want mempool transactions, a blocks only node is deceptively useless to them.
< BlueMatt> echeveria: do they? they also filter blocks
< echeveria> BlueMatt: if they trust a node will give it mempool transactions, and it doesn't. they only ever use one 'master' node, others for headers only.
< BlueMatt> echeveria: I'd very much hope no bloom-filter-based clients are only using one node to receive transaction data, that would be a huge, huge security issue for them
< BlueMatt> also, my point stands - bip37 nodes *also* receive filtered blocks, it may be that they're ok with just that
< echeveria> unless they only get those block peers.
< luke-jr> [03:08:01] <BlueMatt> echeveria: you mean because its implied "low-bandwidth-dont-serve-others" mode? <-- this does seem like a good reason to toggle the default in blocksonly mode
< BlueMatt> luke-jr: yea, i kinda realized that after i said it, its not a bad justification for changing default, though we've always used nolisten as a "really dont want to be serving other clients" not nopeerbloomfilter
< echeveria> luke-jr: blocksonly is pretty much a DOS on bad bip37 peers expecting unconfirmed transactions.
< BlueMatt> "I only accept transactions from one peer, and that peer isnt sending me transactions" aww boo hoo
< luke-jr> BlueMatt: true
< echeveria> BlueMatt: I trusted a node to filter transactions and they just sent back blank proofs. literally no SPV client handles that today either.
< luke-jr> echeveria: it's absurd for light clients to look at unconfirmed transactions anyway
< echeveria> luke-jr: yes, but people are conditioned to think that's reasonable.
< luke-jr> unless it's your own node it's using, in which case "don't do that"
< luke-jr> echeveria: that's a reason TO break it, not to avoid breaking it
< BlueMatt> echeveria: do no spv clients do duplicative sync from multiple peers?
< echeveria> BlueMatt: I'd have to check, not when I last looked. there's also like, 2 BIP37 wallets in use today.
< BlueMatt> jimpo: where are we on the better spv sync stuff? :p
< BlueMatt> echeveria: yea, well bip37 should be killed off entirely at this point anyway
< echeveria> BlueMatt: the biggest one is Bread and they refuse to use Segwit, so, maybe it's a problem that solves itself.
< BlueMatt> "refuse"? as in "we dont want to do the work, fuck our users"?
< BlueMatt> or as in "we're going under, so dont support the app anymore"
< echeveria> er hold on, I am not remembering that right.
< BlueMatt> yea, that doesnt sound like breadwallet, but i dunno
< echeveria> there was *some* wallet that was saying it's not valuable, I forget which.
< BlueMatt> s/dunno/dont know them well/
< luke-jr> BlueMatt: Bread was doing 2X-y stuff back when
< BlueMatt> so were lots of folks, doesnt mean they'd deliberately screw their users *now*...
< echeveria> luke-jr: note that I retracted my comment there.
< luke-jr> not using Segwit isn't screwing anyone
< BlueMatt> depends on if your users want cheaper fees, but, sure
< luke-jr> if users believe Segwit reduces fees and want to use it, they can always look at competing wallets
< jimpo> BlueMatt: It's Coming Soon TM.
< jimpo> Another look at #11857 might help :-). I promise it's related.
< gribble> https://github.com/bitcoin/bitcoin/issues/11857 | Build tx index in parallel with validation by jimpo · Pull Request #11857 · bitcoin/bitcoin · GitHub
< BlueMatt> jimpo: mmm, ok, added to heap...
< jimpo> \o/
< jimpo> Yeah, I'm pretty close with the drafts of the revised BIPs (I'm thinking 2 instead of 1, though it might end up just being one huge one). Need to run the changes by roasbeef.
< BlueMatt> jimpo: heh, dont get too excited, the heap is very very large and essentially unsorted :p
< jimpo> Oh, it's unsorted then I've got some probability of being next at random.
< bitcoin-git> [bitcoin] kallewoof opened pull request #12096: [rpc] [wallet] Allow single-output transactions in bumpfee (master...better-bumpfee) https://github.com/bitcoin/bitcoin/pull/12096
< ossifrage> This is odd, bitcoin-qt is still running and responding to bitcoin-cli commands, but the tray icon is gone and I can't seem to map the window.
< Randolf> ossifrage: Do you mean the Taskbar icon? Or the System Tray icon?
< ossifrage> system tray icon (I have it set to unmap to the tray)
< ossifrage> the hexchat system tray icon is still present and I can map/unmap that window by clicking on it, but bitcoin-qt is gone
< ossifrage> (it has been running for >50 days)
< Randolf> ossifrage: Windows sometimes unexpectedly moves System Tray icons into the more obscure section, which you have to use the mouse to access -- the icon to access it usually looks like a Carat character: ^
< ossifrage> Randolf, this is linux running xfce... it does show up as a client with xlsclients, but does not show up in the wm window lists
< Randolf> ossifrage: Oh. Sorry.
< Randolf> I made an assumption there.
< wumpus> systray causes a never ending string of issues on linux, should get #12054 in asap
< ossifrage> Nothing in the .xsession-errors log, but I think I've long since closed the terminal I initially started bitcoin-qt
< gribble> https://github.com/bitcoin/bitcoin/issues/12054 | Qt: Minimize to tray functionality only on Windows by vajdaz · Pull Request #12054 · bitcoin/bitcoin · GitHub
< provoostenator> Compiling bitcoin dependencies on Ubuntu inside Windows 10 running on a VM on an iMac. Wonderful... I notice compilation sometimes just stalls and I have to hit enter to make it continue.
< ossifrage> wumpus, this is a new failure mode for me, trying to figure out how to force remap the window id or something
< wumpus> ossifrage: I've heard many reports of the icon just disappearing, or not appearing at all, it works better in some wm's than others but overall it seems unreliable
< ossifrage> wumpus, sending the system tray process a SIGHUP fixed the problem
< wumpus> ok
< ossifrage> I'm amazed it worked, I sorta expected the whole thing to catch fire or something
< sipa> heh
< sipa> that was easy
< sipa> provoostenator: you must go deeper
< provoostenator> Well, I got as far as "make" but CCLD lisecp256k1.la complains: libtool: warning: undefined symbols not allowed in x86_64-w64-mingw32 shared libraries; building static only
< provoostenator> And then things break down: https://gist.github.com/Sjors/37bf6a3af47be36baed169788b2316a3
< provoostenator> I'll try upgrading to Ubuntu 17.
< provoostenator> y
< wumpus> looks like you didn't install the posix variant of gcc-mingw
< wumpus> sudo update-alternatives --config x86_64-w64-mingw32-g++ (see the build-windows.md)
< wumpus> you must have forgot that line otherwise you wouldn't be getting errors with c++11 threading primitives
< wumpus> unless this is yet another new issue with WFL
< provoostenator> I'll check my bash history after either the upgrade is done or I figure out how to open a second window / tab in this Windows 10 setup...
< provoostenator> wumpus: would all the dependencies have built successfully if I hadn't entered that command?
< wumpus> provoostenator: yes
< wumpus> the dependencies are all statically linked, so you'd only get the error as soon as it tries to build a target executable
< wumpus> oh wait, no, this is not a linker issue
< wumpus> I'm not sure
< wumpus> but I think bitcoin core itself is the only thing among the dependencies that uses c++11 threading
< provoostenator> I did run that command.
< wumpus> boost implements its own, the other deps are C
< wumpus> well then, you discovered a new problem it seems
< provoostenator> I'll upload config.log (anything else?)
< wumpus> number of days since last WFL issue: 0
< provoostenator> Will hold off on upgrading Ubuntu version if that's useful.
< wumpus> provoostenator: something to try would be to make a minimal c++ file that uses c++11 threading primitives, and try to compile/link that separately
< wumpus> provoostenator: if that also doesn't work you can be sure your build environment is bodged, otherwise it might be something with bitcoin's build system...
< wumpus> make sure to cross-bulid for the target and not for the local OS (e.g. x86_64-w64-mingw32-g++ test.cpp -o test.exe)
< provoostenator> "make a minimal c++ file that uses c++11 threading primitives" - I think you're overestimating my C++ and Windows compiler skill level :-)
< provoostenator> (I'm still working my way through a rather massive primer on C++)
< bitcoin-git> [bitcoin] Sjors opened pull request #12097: [scripts] lint-whitespace: use perl instead of grep -P (master...lint-whitespace-no-grep-P) https://github.com/bitcoin/bitcoin/pull/12097
< bitcoin-git> [bitcoin] laanwj closed pull request #12054: Qt: Minimize to tray functionality only on Windows (master...win-only-tray) https://github.com/bitcoin/bitcoin/pull/12054
< bitcoin-git> [bitcoin] Sjors opened pull request #12098: [scripts] lint-whitespace: add param to check last N commits (master...lint-whitespace-n-commits) https://github.com/bitcoin/bitcoin/pull/12098
< coolass> Where do they take suggestions for improvement of the User Experience for the bitcoin core application?
< coolass> thx!
< promag> sipa: hi
< sipa> ohai
< promag> how do you suggest to detect invalid hash when parsing?
< sipa> in what context?
< promag> I had in mind return the processed characters in SetHex
< promag> getblock foobar
< sipa> we have IsHexNumber ?
< promag> but why base_blob<BITS>::SetHex(const char* psz) doesn't process the whole input?
< sipa> constructors are very annoying to return error conditions from, as they have to produce an object (or throw an exception)
< sipa> oh, SetHex, ignore me
< sipa> it could return a bool
< Chris_Stewart_5> sipa: How do you feel about trying to create an abstraction of coinselection with higher order functions (lambdas)
< Chris_Stewart_5> Do you think this is possible/reasonable to do?
< sipa> Chris_Stewart_5: or just an interface class
< Chris_Stewart_5> proovsentator mentioned this yesterday during the meeting
< sipa> or even just something that you pass a list of all UTXOs
< sipa> and the short-term and long-term feerate
< Chris_Stewart_5> yeah, i was thinking like (utxos, minFee, maxFee, amount) -> utxos
< sipa> right, and amount :)
< Chris_Stewart_5> i haven't delved into it too much I guess, I wanted to see if it was an obvious bad idea hah
< Chris_Stewart_5> would interfaces be preferred for backwards compatability of older c++ compilers?
< sipa> no, we target c++11; you're free to use any c++11 features
< sipa> but lambdas may not be the most appropriate thing to do (if there are multiple callbacks involved, for example)
< sipa> but even that is overkill - we currently build an explicit list of all UTXOs anyway, no reason why you can't just create a mechanism where you pass that list explicitly
< Chris_Stewart_5> Hmm, I'll have to dive into the details. Seems like it would be better to just have lambda's represent our various coin selection algo's instead of some weird inheritance hierachy
< sipa> i suggest you start simple
< sipa> and not use any of those
< Chris_Stewart_5> Fair enough. Thanks for the advice!
< leviathan_> hello
< provoostenator> I installed a nightly Ubuntu 18.04 build on a VM, compiled Bitcoin, ran QT in regtest mode, make check, ran functional tests (all pass except fullblocktest.py). Seems to Just Work(tm). Shocking?
< sipa> no, why would it not work?
< provoostenator> New OS, so you never know?
< sipa> there are occasionally issues with new boost versions that show some incompatibilities, but that's about it
< sipa> sometimes some Qt/UI issues
< provoostenator> As for Windows 10... I reinstalled Ubuntu and upgraded straight to 17.10 (which didn't go smooth). I get an error during the dependencies make for zeromq: funcs.mk:242: recipe for target '/usr/src/bitcoin/depends/work/build/x86_64-w64-mingw32/zeromq/4.2.2-c6f340e09c9/.stamp_preprocessed' failed
< sipa> compiling for windows in general is more error prone, it seems :)
< provoostenator> When I try make again, it throws a nice riddle: Reversed (or previously applied) patch detected! Assume -R?
< provoostenator> I cleared the zeromq dir and tried again, but no luck: https://gist.github.com/Sjors/b4b3c683144e84a23bc43a4009d2fcbb
< provoostenator> I fixed the locale error with some incantations. Now zeromq does compile.
< provoostenator> No it doesn't. Blegh, will try some other time.
< provoostenator> Mmm, I didn't select the "posix" option in the update-alternatives command
< jonasschnelli> provoostenator: have you installed all windows cross compile dependencies?
< provoostenator> Yes, I think I got all the other stuff right, but I'll try again with this change.
< provoostenator> As well as on a regular Ubuntu 17.10 VM.
< jonasschnelli> I recently (~2 weeks ago) compile windows on Debian 9 (worked there)
< provoostenator> If this works, I might make a PR that moves that instruction from a code comment to the main markdown text.
< provoostenator> Even though I'm stupid, I'd like to assume at least some other people will make the same mistake :-)
< jonasschnelli> I made https://github.com/bitcoin/bitcoin/pull/11903/files after the last attempt to X-compile
< jonasschnelli> So,.. I think it would be good to overhaul the documentation even further to make it simpler to setup the depends/x-compile
< provoostenator> Note to self: don't run two VM's and give each of them half your RAM and CPU's and expect the host computer not to crash...
< provoostenator> jonasschnelli: mmm, why are those in depends.md and not in windows build? Or are they the same?
< provoostenator> Oh wait, the windows sections points there, nvm
< jonasschnelli> Not sure if it would be better if all would be in depends.md
< provoostenator> Yeah, I do find the division of information a bit confusing. It might be more clear to put all instructions up to the ./autogen step in depends.md for all platforms and cross complication setups.
< provoostenator> I deleted the "built" folder, but the zeromq stuff still doesn't work for me.
< provoostenator> (will try again deleting the whole depends folder to be on the safe side)
< cfields> provoostenator: depends is fully deterministic. If you delete the 'built' folder, it'll just get rebuilt the same way :)
< cfields> doing a 'make' in depends after re-configuring gcc should trigger all cross packages to be rebuilt
< provoostenator> Wouldn't it be different after I selected that -posix option?
< cfields> sorry, that was probably unclear. Doing a 'make' in depends should do the right thing. If nothing's changed, nothing should be rebuilt. If something has changed, it should rebuild appropriately
< cfields> but you shouldn't ever need to manually mess with the built packages
< cfields> provoostenator: i see. Annoyingly, clang shows its thread-model with "clang --version", but gcc needs "-version -v"
< cfields> this should fix: https://0bin.net/paste/Nqyju+vaLybxvxyg#v3T6OFViIa9mqTb+28wNrHmSsiwXJ1HBcc3z6boYIBq
< cfields> grr nm, that won't fix either. The verbose stuff is sent to stderr :\
< provoostenator> Deterministic schmermenistic, I got a different result this time (haven't tried your fix): https://gist.github.com/Sjors/87c05168dd5ebde87f264bd7e055968d
< provoostenator> (will read the chat log tomorrow)
< cfields> provoostenator: yes, I see now that the change won't be detected.
< cfields> Not too concerned though, I'm working on the toolchain builder atm that would remove the issue completely
< cfields> provoostenator: looks like you installed for x86_64 but not x86? or gcc but not g++?
< luke-jr> cfields: thoughts on migrating to bionic/18.04 for gitian?
< luke-jr> or maybe not worth it with the plan to build our own compilers anyway
< cfields> luke-jr: with the toolchain builder done, the ubuntu image should be irrelevant
< cfields> precise/trusty/xenial/bionic _should_ all build the same result
< luke-jr> cfields: what toolchain are we targetting for now?
< luke-jr> is there a PR?
< cfields> trusty
< luke-jr> no, I mean the compiler we build/use
< cfields> luke-jr: no, still working on it. Hitting some snags.
< luke-jr> looks like GCC 6 is the bare minimum needed for POWER9 target
< cfields> luke-jr: oh, you mean the one I'm working on? I've been targetting 7.2 for no particular reasoon
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/56910285fa4a...fd4ca17360e6
< bitcoin-git> bitcoin/master 8a93543 251: Replaces numbered place marker %2 with %1....
< bitcoin-git> bitcoin/master fd4ca17 MarcoFalke: Merge #12092: [qt] Replaces numbered place marker %2 with %1....
< cfields> (other than I wanted to see what new warnings it would show during bitcoind build)
< luke-jr> cfields: sounds good, probably makes sense to just wait for it, before tackling POWER9
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #12092: [qt] Replaces numbered place marker %2 with %1. (master...patch/12015/sendcoinsdialog-replaces-numbered-place-marker) https://github.com/bitcoin/bitcoin/pull/12092
< cfields> luke-jr: heh yes, I'd rather not jump through hoops for hardware that's coming "in two weeks" :p
< cfields> no reason why it shouldn't work as long as gcc supports it, though
< luke-jr> cfields: hey, at least they're shipping with Meltdown+Sceptre fixed* :p
< cfields> luke-jr: what endianness does it use by default?
< luke-jr> no idea
< cfields> oh?
< luke-jr> not sure there is a default
< cfields> well something has to select it somewhere down the line, and that selector must have a default :)
< luke-jr> whatever OS you install? ☺
< cfields> fair enough
< cfields> that's bound to flesh out all kinds of endian-hard-coded-at-build-time != runtime-endian bugs
< luke-jr> I don't think any software can handle different target/runtime endians
< cfields> i meant that plenty of software does #if x86 do small_endian_stuff()
< cfields> but "#if power9 do_big_endian_stuff()" would break
< sipa> i'm sure it will rather be power9 and power9le
< sipa> which systems will treat as different architectures
< sipa> like mips and mipsel
< cfields> sipa: but it's switchable at boot time
< sipa> so?
< sipa> x86_64 and i686 are also selectable at boot time, and run on the same hardware
< sipa> (bad example, as i686 actually runs on x86_64 systems, but ignore that for a second)
< luke-jr> it's switchable at runtime too <.<
< cfields> sipa: yes, one is a subset of the other there. I don't see your point.
< luke-jr> cfields: if software does #if x86 for endian, it's already totally broken
< sipa> cfields: i mean... i expect that the kernel you compile will support either only BE or only LE; you boot a particular kernel, and then the entirety of the OS and all userspace must use that endianness
< cfields> luke-jr: sure, agreed. But that doesn't mean it's not done
< luke-jr> sipa: are you sure?
< sipa> luke-jr: no, not at all
< sipa> but i would be very surprised if it's possible to make different endianesses cooperate
< cfields> sipa: ok, I see your point. You're saying a different config is effectively different hardware as far as the build for it goes
< luke-jr> I guess at the very least you'd need both endians in libraries
< sipa> cfields: yup
< sipa> cfields: but that's a theory
< luke-jr> but so long as we're talking static binaries..
< sipa> cfields: i think it will be very similar to mips and mipsel
< cfields> luke-jr: then you'd download the power9 or power9le binary
< luke-jr> sounds like the ELF header decides the program's endianness
< luke-jr> cfields: well, if we can avoid any dynamic linking, we *could* just do a fully static binary of one or the other, and I think it will run on either
< luke-jr> but.. we might need dynamic linking for Qt I guess
< cfields> why? we already link qt static
< sipa> or maybe the linux world will quickly come to a convential that only LE is used (or only BE)
< sipa> oh wait, linux and agreeing on a convention, never mind...
< luke-jr> ok, wasn't there something we dynamic link?
< luke-jr> sipa: :D
< cfields> luke-jr: we used to dynamic link qt and leave it up to the target system to provide it
< cfields> sipa: you can end any linux "convention" discussion with one of dozens of buzzwords. So that seems unlikely :p
< cfields> haha that's the first one that came to mind
< cfields> speaking of which, it's hilarious to see "#ifdef emacs" in the gcc code
< cfields> I haven't dug in to see why yet
< Fithos> Why does Bitcoin Core max out at 0.1 btc in transaction fee?
< luke-jr> I sure hope there's never a need to pay more :/
< Fithos> My transaction size is like 60kb =(
< Fithos> I had my miner paying into my wallet like once per day.. I need to get a new wallet!
< Derek314> A
< Fithos> I didn't know amount of transactions would increase the fee /cries
< BlueMatt> luke-jr: my understanding is sipa is correct here - you'd have a hard time getting a be binary to run with a le kernel and visa versa, however you *can* run a be vm inside a le host and visa versa
< BlueMatt> (on power)
< luke-jr> I guess the syscalls are endian-specific
< bambum> hi i have a bug on bitcoin-qt. Its not broadcasting my transaction but the amount showing me is already 0
< bambum> txid: 73627d8ad001135c50cc279cab7b372b8ed83669390b22e50a8b213e10e058e6 waiting 2 hours already but can´t find anything on public blockchain explorers