< eklitzke>
it's on my todo list, i have a systemtap script that hooks into the kernel events that update the process file descriptor tables
< eklitzke>
i want to use that to find the places where bitcoind creates file descriptors but doesn't track that
< gmaxwell>
eklitzke: the main reason we have FD limits at all is due to the use of select in the networking code.
< eklitzke>
so i don't quite understand what is the situation where you would get 1024 network sockets in your bitcoin process
< gmaxwell>
There is a fairly simple patch to use poll instead which has been delayed for a very long time now out of a desire to instead wait until a bigger rewrite.
< gmaxwell>
eklitzke: select will not work if any fd number is over 1023... not just if there are more network sockets.
< eklitzke>
ah, right
< gmaxwell>
because it's implemented as a bitmap.
< gmaxwell>
well a constant size bitmap. :P
< gmaxwell>
so we get fd pressure from all angles, multiple leveldbs, rpc, network, block files, etc.
< j0hnson2412>
does the bitcoin: uri scheme work ok with segwit addresses? i sent a payment with it and the actual transfer goes to a different address
< sipa>
it should work
< sipa>
what software and version?
< j0hnson2412>
bitcoin core v0.15.1
< sipa>
and do you mean a p2sh address or a native one? (3... or bc1...?)
< j0hnson2412>
the address parameter is set to a segwit (3) address, but it also has a r parameter. reading it looks like it just ignores what that address is and fetches info from the r parameter
< j0hnson2412>
this is to a coinbase.com merchant
< sipa>
who created the URI?
< j0hnson2412>
they say they didnt receive the payment so it looks like coinbase is messed up then
< j0hnson2412>
its from one of those 'pay with coinbase.com' buttons
< j0hnson2412>
i probably now have malware from this too
< achow101>
well if that's how you feel about it, guess I'll stop trying to help then
< j0hnson2412>
you need to statically link your stuff, linux one doesnt run either
< bramc>
Hey everybody
< meshcollider>
bramc: hi
< bitcoin-git>
[bitcoin] kallewoof opened pull request #12537: [arith_uint256] Make it safe to use "self" in operators (master...uint-safe-self-op) https://github.com/bitcoin/bitcoin/pull/12537
< j0hnson2412>
finally got the bitcoin script extracted from the paymentdetails, but it's in some weird python mix of ascii and escaped octal..
< wumpus>
and yes the forced adoption of the payment protocol by bitpay etc has been a letdown, many wallets don't have a BIP70 implementation, some don't work properly, there's problems with cloudflare and tor when fetching the requests
< wumpus>
last time I tried to pay something using bitpay I had to give up and pay by bank... all was okay when you could just pay manually to an address
< wumpus>
booyah: that bug was always in there AFAIK, and I don't think it was intentionally exploited, it was an unexpected interaction between the db library and consensus
< booyah>
wumpus: so all released versions of Bitcoin, including Satoshi's release, were vulneable?
< wumpus>
booyah: yes
< echeveria>
yes
< booyah>
I'm asking also since there're idiots in -otc claiming that is "bitcoin core fault"
< echeveria>
satoshis bitcoin 0.1 was more vulnerable in a pile of ways. there’s lots of things that aren’t understood well.
< wumpus>
everything using berkeleydb for the utxo set, which was the case from the first version
< echeveria>
ie, you could create unlimited bitcoin out of thin air and spend anybodies bitcoin.
< wumpus>
not that one echeveria
< echeveria>
?
< wumpus>
that was another bug in satoshi's code, much earlier
< echeveria>
I’m saying it’s not perfect, and you can’t attribute that to later development at all. I realise they’re 3 different, earlier bugs.
< booyah>
we need better CVE / bug disclosure process guys
< echeveria>
uh. this is ancient history.
< wumpus>
yes, this is ancient history
< booyah>
above information should be state in that BIP 50 imo. Which versions were affected (all), when it was introduced (in first version), by who (Satoshi)
< wumpus>
both the BIP50 fork and satoshi's counting mistake :-)
< booyah>
it is also the most known security event (or 1 of like 3) used NOW to prove that bitcoin core is incompetent
< booyah>
"prove"
< wumpus>
feel free to dig in history, someone must, but I focus on the future only
< echeveria>
booyah: feel free to write them up.
< booyah>
[10:33] <mats> this is 0.8.0, which satoshi did not release
< echeveria>
0.8 *fixed* the bug.
< booyah>
wumpus: I see. btw please provide such detailed info for any future (if any) then :)
< wumpus>
if their point is that bitcoin core's contributors make mistakes, then they are right
< echeveria>
no version before 0.7 was consensus complete due to berkeleydb not being deterministic.
< wumpus>
find any person alive who writes bugless software FFS, we have a very thorough QA and testing process in place but it's impossible to guarantee that bugs won't happen
< echeveria>
booyah: let’s take this to #bitcoin please.
< wumpus>
most of that trolling comes from people supporting projects that publish code with virtually no review and QA at all
< wumpus>
yes, take it somewhere else, it's not relevant to anything today
< wumpus>
if you want to call me incompetent, go ahead and try to do better. I have more than 20 years of experience in development and computer security. But I'm not perfect. Open source hinges on having lots of eyes on the source code to catch mistakes, not any special person.
< esotericnonsense>
:)
< wumpus>
so: try to attack the code, that's good. Don't try to attack the developers, that just results in drama.
< esotericnonsense>
bitcoin 0.8 was not 'bitcoin core' :D
< booyah>
wumpus: speaking about the future, will the bitcoin wallet be returning to name "bitcoin" instead "bitcoin core"?
< wumpus>
no
< wumpus>
you can pry my project name from my cold dead hands
< booyah>
hm? I was just asking about the name :)
< phantomcircuit>
booyah, fyi the people trying to blame someone for that stuff know they're lying
< wumpus>
if you want a serious answer: some things (such as naming, branding) are too trivial to be concerned with here. There's as many opinions on it as bitcoin users. You can fork the source code today and change the name (it's a constant in configure.ac FWIW) or use luke-jr's Bitcoin Knots. If there is no agreement on changing something, the best thing is just to stick with what is there.
< phantomcircuit>
pointing out that they're lying is mostly useless
< provoostenator>
If the amount of discussion required to change a few words in a tooltip is any indication... changing the name of the app would eat up all of Core's resources for a year :-) There's more important things to work on.
< wumpus>
And if you want to change the bitcoin logo to a purple elephant and denominate coins in 'fluppydoodleblurz' from now on, go ahead and release a wallet that does that, use that on your sites, make a BIP, etc. By nature, bitcoin is permissionless.
< wumpus>
provoostenator: exactly, it's like a human DDoS attack :)
< bitcoin-git>
[bitcoin] luke-jr closed pull request #11802: RPC/Wallet: Refuse to dumpprivkey for derived addresses (master...dumpprivkey_noderived) https://github.com/bitcoin/bitcoin/pull/11802
< promag>
denis2342: should have a test there no?
< denis2342>
promag: ?
< promag>
denis2342: for instance, decoderawtransactions calls TxToUniv with include_hex=false, so it would be nice to have some test checking that hex field isn't there
< promag>
denis2342: furthermore, this change is breaking change, and requires release note
< provoostenator>
Which is what the Reset settings feature uses.
< provoostenator>
I was thinking of using a (much) higher dbcache in QT if physical memory size is known (e.g. https://msdn.microsoft.com/en-us/library/cc300158(v=VS.85).aspx) and large enough. In that case we could remove the setting from the UI, and only honor -dbcache if set. Thoughts?
< esotericnonsense>
i'd be in favour of automatic dbcache / mempool / etc sizing. it seems obvious/useful enough that there's probably a reason we're not doing it though.
< esotericnonsense>
e.g. on a 1GB machine it's really common for bitcoind to get oomkilled and it seems to me that anyone that really wanted it to use ~all of the system ram could set that.
< bitcoin-git>
[bitcoin] practicalswift opened pull request #12542: Remove redundant includes. Conform to header include guidelines. (master...include-guidelines) https://github.com/bitcoin/bitcoin/pull/12542
< provoostenator>
I think the case for QT is stronger than bitcoind. GUI's are usually not on all the time. We may also want to flush if there's no activity for a while. I think this is especially useful during IBD, where the progress bar should make it obvious to users that this process can be a drain on their system.
< provoostenator>
I also don't think many GUI users will feel comfortable touching these settings.
< CubicEarths>
provoostenator: GUI users include many technical people
< bitcoin-git>
[bitcoin] Empact opened pull request #12545: test: Extend wait time by .1 seconds to ensure ping goes out (master...ping-timing) https://github.com/bitcoin/bitcoin/pull/12545
< tr4vis220202>
When sending a bip-70 payment, bitcoin core sent to regular address instead of p2sh, hexdump of script is 76A9142AFD057FD359FC1C180B177D05F1B4191867471A88AC
< sipa>
tr4vis220202: are you sure the BIP70 request didn't contain a regular output?
< sipa>
as far as i can see in the code, it just uses the exact script requested in the BIP70 payment request - regardless of what type of output it is
< tr4vis220202>
when i decode it, there is an address, and a p2sh
< sipa>
can you share the URI and the payment request?
< sipa>
(perhaps privately)
< michagogo>
Quick question about the release notes
< michagogo>
“Bitcoin Core is extensively tested on multiple operating systems using the Linux kernel, macOS 10.8+, and Windows Vista and later.”
< michagogo>
Is there actually anyone testing extensively on Vista?
< * Randolf>
laughs
< sipa>
I hope some people are testing the RCs on windows?
< michagogo>
Yeah, but Vista?
< Randolf>
I have been running RC3 and then RC4 on Windows 10 (64-bit).
< Randolf>
Haven't had any problems with it.
< Chris_Stewart_5>
doesn't microsoft even support vista anymore?
< Chris_Stewart_5>
does*
< michagogo>
Yeah, IIRC it EoL’d about a year ago
< sipa>
oh, i'm not up to date on windows versions
< Randolf>
There probably are people using Bitcoin on Windows 7. Windows Vista, I suspect, likely isn't used for much these days.
< sipa>
but we still support vista, no?
< michagogo>
And as far as I know, it’s not even like XP, which tons of people stuck with for way too long
< michagogo>
sipa: that’s the question
< Randolf>
I have extra hardware and a Windows Vista license I could throw together to see if Bitcoin works on it.
< michagogo>
Do we really, or did that just never get updated?
< michagogo>
And also, does it actually not work on XP, or do we just say we don’t support it?
< michagogo>
If the latter, we should drop Vista too imho
< Randolf>
I'd suggest we move it up to Windows 7.
< Randolf>
I can put a Pull Request in easily for that now.
< esotericnonsense>
as far as I'm aware XP is used _more_ than vista
< Randolf>
esotericnonsense++
< Randolf>
Windows Vista was so horrible that most people seem to want to forget it even existed.
< sipa>
Sounds like Windows ME to me.
< sipa>
(coincidentally the last windows version I used...)
< Randolf>
That's pre-WindowsXP stuff there.
< michagogo>
esotericnonsense: right, that’s my impression too
< Randolf>
Vista came after XP.
< michagogo>
Randolf: I don’t think sipa was saying he thought we were talking about me
< michagogo>
Rather, comparing the situation and the badness
< esotericnonsense>
according to wikipedia, vista has consistently had about 1/5th the usage of XP for the past few years. according to their trackers anyway.
< Randolf>
Oh, okay. :)
< esotericnonsense>
statcounter has it as 0.41% in march 2017 vs 2% for XP (of the overall total, desktop, mobile, everything included)
< rabidus>
mobile xp ..
< michagogo>
Randolf: I’m not sure MacOS is right
< michagogo>
I don’t think it was ever called that
< esotericnonsense>
rabidus: no, as in, all browser stats. approx 45% desktop and 55% mobile for whatever sites they're tracking. so XP is 4% of desktops in that stat
< Randolf>
Oh? I merely changed "macOS" to "MacOS" because I do remember supporting some MacOS computers at a help desk job many years ago.
< Randolf>
Maybe they've changed it since then?
< michagogo>
It was Mac OS until over a decade ago, then Mac OS X. A while back they dropped the Mac and made it just OS X
< michagogo>
In the last year or two (IIRC), it was renamed to macOS
< Randolf>
Oh. I'll have to fix that then.
< Randolf>
That new version looks like a mistake. Oh well. :)
< michagogo>
10.8 was still OS X (no Mac) if I’m not mistaken, but 1. I’m not sure if the renaming was retroactive or not, and 2. I feel like macOS is more understandable
< michagogo>
They changed it in order to make their various OSes consistent
< michagogo>
iOS, watchOS, tvOS, etc
< Randolf>
Well, I see that "macOS" is indeed how they're marketing it on their web site nowadays, so you're obviously correct that the name should begin with a lower-case "m."
< michagogo>
Don’t know what the HomePod runs
< esotericnonsense>
this is kind of a bitcoin question but kind of not. what's the trick to make bitcoin-qt not appear as a postage stamp on ubuntu with high dpi screens?
< esotericnonsense>
is there a 'qt-tweaker' or something?
< mlz>
i've been testing the RCs on windows for a while now but ofc I don't check everything
< mlz>
one thing i'm wondering if can be improved: cross-compiling for windonws on ubuntu 14 Trusty starting fresh from beginning to finishing takes about 4-5 hours, I wish this could be shorter