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