< sipa>
MarcoFalke: i find it mildly annoying that the "this pull request conflicts with" messages cause those referenced PRs to be marked as recently updated
< wumpus>
it would be great if github had a way for bots to bypass those things
< wumpus>
add information to a PR but not spawn a notification or update metadata like taht
< bitcoin-git>
[bitcoin] fanquake closed pull request #12656: Add scripts for doing gitian builds on any platform using VirtualBox + Vagrant + Packer (master...vagrant) https://github.com/bitcoin/bitcoin/pull/12656
< provoostenator>
jonasschnelli: ensuring that at least one person actually tests Gitian (QT) build, and then leaving "tACK bitcoind/QT on macOS/Windows/[favorite Linux distro]" seems like a good idea.
< provoostenator>
In addition each release could have one Github issue where we post standard testing instructions ("go to bitcoincore.org, get rc..., etc) and let us know if it worked. It would be a noisy thread, but just one.
< Sparklefairy22>
With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
< Sparklefairy22>
I thought you guys might be interested in this blog by freenode staff member Bryan kloeri Ostergaard https://bryanostergaard.com/
< bitcoin-git>
[bitcoin] kallewoof opened pull request #14582: wallet: try -avoidpartialspends mode and use its result if fees do not change (master...181026-try-avoidpartialspends) https://github.com/bitcoin/bitcoin/pull/14582
< fenrus020>
With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
< fenrus020>
I thought you guys might be interested in this blog by freenode staff member Bryan kloeri Ostergaard https://bryanostergaard.com/
< bitcoin-git>
[bitcoin] merland opened pull request #14583: docs: Textual improvements in build docs (master...proof-read-build-docs) https://github.com/bitcoin/bitcoin/pull/14583
< promag>
I think #14518 is ready and could be backport
< harding>
For 0.17.0.1, a few questions related to what changes I might need to make to BitcoinCore.org for it: (1) is only the MacOS binary going to be added to /bin/bitcoin-core-0.17.0.1/ or will there be .0.1 versions for all platforms? (2) Are there going to be release notes for it? (3) Do we want a blog post about it on the home page?
< wumpus>
harding: (1) there will be a 0.17.0.1 version for all platforms, I think that's most convenient as that allows following the normal release process. I also think that's what we did before in these cases?
< wumpus>
harding: (3) I think a blog post is not worth doing, this is just a minor fixup that affects a small part of users it seems
< harding>
wumpus: that's what I remember being done for all the other 0.*.*.1 releases, and it's easiest for the website if there are release notes because, as you say, it's the same release process. It is possible (and pretty easy) to have binaries split across two directories on both BitcoinCore.org and Bitcoin.org as we both use the same mechanism to allow for easy changes in the filenames across releases, so let me know if you ever do
< harding>
need to do a partial release.
< harding>
wumpus: thanks! That's everything I needed to know. I'll get a PR up.
< wumpus>
harding: I also remember that, to not confuse users, we've once used the 0.x.y release notes for 0.x.y.1, and just added the mention of the fix
< wumpus>
otherwise it's like "wow this is supposed to be a major release but it changes nothing"
< wumpus>
might be something for the web site at least; but good to know the binary situation works for you, will go ahead with that then
< harding>
wumpus: if users being confused is a concern and it's ok with everyone, I can just add a sentence on the website version of the release notes that says, "Otherwise this software is identical to [0.17.0](/link/to/0.17.0/release/notes)".
< wumpus>
harding: yes, that would help I think!
< promag>
jonasschnelli: please take a look at #14573
< harding>
promag: I assume it's named to correspond to gettxoutsetinfo.
< promag>
harding: makes sense
< promag>
gettxoutsetinfo should be getutxosetinfo? :P
< instagibbs>
promag, bitcoind doesn't track stxo so no info to give ;P
< instagibbs>
I do find that the most impossible rpc command to remember/type out
< andytoshi>
wumpus: the rust-bitcoinrpc crate has a huge dep tree that has all sorts of borderline-unstable stuff written by "webscale" people. i would not trust it
< bitcoin-git>
[bitcoin] ken2812221 closed pull request #13827: [WIP] depends: Add native_nsis to support unicode (master...depends-nsis) https://github.com/bitcoin/bitcoin/pull/13827
< andytoshi>
rust-jsonrpc is better but it's still not where i want it to be. afaik there is no HTTP client library for rust that doesn't have a bad dependency story. we would need to write our own to do bitcoin-cli in rust.
< andytoshi>
OTOH, if somebody were to do that work it'd be generally very useful
< wumpus>
andytoshi: interesting—yes such a outgrowth of dependencies shouldn't be necessary for a little tool like that
< wumpus>
it's not bad to have deps, but…I certainly get your point
< wumpus>
promag: I also *always* by definition, forget the name of that command
< andytoshi>
wumpus: at blockstream we have functionary software written in rust, and the HTTP stuff is literally 50% of our dep tree (and has caused 100% of our dependency-related trouble). if we were using the latest version of hyper the tree size would double again, so it'd be 75% of our dep tree. and it's exactly the kind of stuff that is hard to vet and tends to be written by incautious people
< wumpus>
the other long RPC I have no trouble with, like signrawtransaction with wallet, but that utxo statistics command darn how was it called again
< andytoshi>
so sure, not bad to have deps, but i think in this case it's a problem
< promag>
instagibbs: lol
< wumpus>
andytoshi: so 'hyper' is the root of the tree of trouble, so to say?
< andytoshi>
yep
< promag>
provoostenator: ken2812221: hebasto: please test #14123, ty!
< andytoshi>
FWIW you can disable all of its connection management stuff (and with it most of the dep tree) .. but there's no replacement for it, you'd have to write all that yourself, and then you might as well just rewrite the whole thing
< wumpus>
it's absolutely overkill for a RPC client, I was happy not to need hyper for my c-lightning RPC wrapper
< hebasto>
promag: doing now :)
< andytoshi>
wumpus: awesome :) i've been thinking about writing a simple single-threaded "template-based HTTP" client for a while, and slowly add things to it as needed. i think that could be done with almost no deps and have a very small code footprint
< andytoshi>
but i haven't had the time
< e4xit>
why was BIP 159 allocated service bit 10 rather than then next freely available bit (5)? Were those bits previously allocated but not used, or something else?
< luke-jr>
service bits aren't really allocated (perhaps they should be?), just claimed
< e4xit>
ok, so would be simply a decision made by jonasschnelli then
< luke-jr>
there was probably discussion here, but at the end of the day, yes
< e4xit>
thanks
< luke-jr>
note that some high bits are typically perceived as temporary/testing/adhoc usage
< luke-jr>
eg, the full RBF bit
< jonasschnelli>
I used bit 10 because other non bitcoin (core) stuff did use the below ones.
< e4xit>
ok thanks jonas. I thought that was likely the case but I couldn't find much (core) documentation detailing what might be using them, which makes sense now...
< luke-jr>
I only have 0-4,10,26 documented (or visible on the network in any notable count)
< luke-jr>
BIP 158 seems to use bit 6
< luke-jr>
bit 5 was allocated in BIP 149, but obviously n/a
< luke-jr>
I wonder when we should start retiring the segwit service bit
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #14534: Enable flake8 rule E225 which checks for missing whitespace around op… (master...flake8-fix-E225) https://github.com/bitcoin/bitcoin/pull/14534
< e4xit>
thank luke-jr
< e4xit>
*thanks
< wumpus>
right, you can just try to claim your favourite bit in your BIP
< wumpus>
you don't need to explain why you picked it
< wumpus>
although yes what luke-jr says, the higher bit are considered special purpose for temporary or experimental things, I think that's written in a BIP somewhere
< wumpus>
luke-jr: I think retiring that bit needs a BIP in itself
< wumpus>
(e.g. with your time planning, when to stop setting and/or interpreting it, as other software will need that too)
< wumpus>
and there will have to be a period before it can be reused for other things
< luke-jr>
nah, software can just decide when it's no longer worth filtering for (and instead handling the occasional "bad" peer), and then software can decide when it's no longer useful to set
< luke-jr>
doesn't have to be coordinated
< wumpus>
well, I think it makes sense to coordinate this
< wumpus>
even if at least to get discussion about it, write down what it takes to retire a service bit (it's the first time isn't it?)
< wumpus>
also it gives future BIPs that want to use that bit something to refer to, that they can reclaim it
< * esotericnonsense>
scrolls up. lol.
< esotericnonsense>
my project for learning some rust, was http. this explains why I am chasing my tail.
< bitcoin-git>
[bitcoin] practicalswift opened pull request #14585: Don't rely on locale dependent functions in base_blob<BITS>::SetHex(...) (uint256), DecodeBase58(...), ParseMoney(...) and ParseHex(...) (master...no-locale-surprises-please) https://github.com/bitcoin/bitcoin/pull/14585
< gmaxwell>
Is there a reason we can't have the wallet sync status _never_ tell people that it is "X years behind" and instead say that it is synced up to date x/y/z? The foo years behind thing seems to frequently cause people to think that it will take years to finish the sync.
< oshithemoto>
Anyone here who coded a bitcoin wallet in VB.NET?
< sipa>
oshithemoto: off topic here
< oshithemoto>
offtopic? isn´t this the developer channel?
< jarthur>
Specifically Bitcoin Core development. #bitcoin-dev or #bitcoin may be better suited.
< oshithemoto>
ok thx!
< oshithemoto>
maybe offtopic but are here ppl from the good old Sub7 Crew?
< sipa>
yes, offtopic
< oshithemoto>
no one is writting here, just like idling here? gg I am an old developer, i did some decentraliced stuff bevor bitcoin, cordinated ddos attacs and i hope to find some old crew member, it was not sub7 crew but some of the ppl from this crew can help me find my old crew members I think one of them is satoshi nakamoto. his "old" nickname was "oso", he was a hacker and our crew name was #ratpack and he told my about a decen
< sipa>
oshithemoto: please go away
< sipa>
this channel is about discussing development on the Bitcoin Core software; you're welcome to idle or discuss relevant topics, but those don't include other Bitcoin clients, and certainly not trojan horse software
< oshithemoto>
he told me about a new decentraliced system called "the bitnetwork" in 2002, so he was developing it, I search him now for 6 years, maybe someone of here knows him, pls contact me thx
< oshithemoto>
that´s it sorry ;)
< sipa>
noted.
< phantomcircuit>
gmaxwell, i dont see a reason to change that
< phantomcircuit>
it's definitely confusing as is
< gwillen>
phantomcircuit: a reason not to change, rather? :-)
< phantomcircuit>
gwillen, yeah
< phantomcircuit>
there was a "not" in there
< phantomcircuit>
seems it stayed in my head
< gwillen>
safest place for it really
< wumpus>
gmaxwell: it used to be like that a long time ago, "X" years behind was apparantly seen as an improvement
< wumpus>
gmaxwell: I... don't know, it seems we're circularly revisiting the same ideas over and over
< gmaxwell>
Any chance you can refer me to the discussion where "X years behind" was proposed an improvement?
< wumpus>
someone claims that something is better UI so that gets implemented, then someone else calls somethinge else again
< wumpus>
we're never going to make progress without someone with an actual clue in this
< wumpus>
no, I don't know, must be in git history somewhere...
< gmaxwell>
I can go pull some other examples up if you'd like to see them.
< wumpus>
I really don't know, I'm sick and tired of this tbh
< gmaxwell>
Then quit the project wumpus.
< wumpus>
yes
< wumpus>
you wouldn't believe how many times the progress display was redesigined, in a way someone found better, but of course, it results in other people complaining
< sipa>
whatever we do, people are always going to complain about something
< wumpus>
I'm sorry.. I'm having trouble with this
< midnightmagic>
And then some of us will complain about people complaining!
< gmaxwell>
There isn't anyone even really complaining on this, just a regular stream of confused people.
< gmaxwell>
I asked specifically to avoid looping on it.
< wumpus>
I try to be helpful, I really try to do what is useful, what are good choices that help people, but it's never okay
< midnightmagic>
wumpus: Don't quit. We love you man! You're a longer-term-thinking moderate, which means it's harder for people to find a reason to hate you.
< gmaxwell>
No one did anything wrong with this. It just turns out presenting a long delay to users is fundimentally hard because user easily get anxious and worry that it isn't working.
< wumpus>
midnightmagic: believe me, I don't want to!
< sipa>
i think the real problem is that syncing is slow :)
< wumpus>
midnightmagic: it's just that after years it feels a bit repetitive, that's all
< midnightmagic>
(external) people like arguing about shed colours, man, it's only avoidable if nobody engages them.
< sipa>
for many people it's a fundamentally inconvenient interface, but we're constrained in how to improve that
< midnightmagic>
wumpus: Super repetitive. And I don't even contribute code to the repo..!
< wumpus>
I just wish... someone with UI design experience would get involved, and make a good descsion based on human psychology on this, and we'll just stick with that
< sipa>
wumpus: that'd be great
< midnightmagic>
Those people are all working for games companies.
< wumpus>
but that never happens
< wumpus>
yep
< sipa>
and yeah... please don't quit; but if you need a break...
< midnightmagic>
People don't want to get their hands dirty building bitcoin because they worry that if they make a mistake, someone will blame them for millions of $$ lost. And the people who overcome that are philosophically-minded people who jump off that cliff anyway and hope Miles back at the base camp packed their parachute properly. :)
< gmaxwell>
wumpus: it doesn't work that way in any case. You can put all the expirence in the world, and sometimes you're going to find that people get confused, so you tweak it a bit. It's not a big deal. Sometimes it's all fine, and then the language educational materials use changes, and people end up confused and things have to change to respond, etc.
< gwillen>
wumpus: FWIW that's not even how it works in commercial software
< wumpus>
but we can't keep doing 'someone complains about this! let's change it again'
< gwillen>
over there you get promoted for making big changes pointlessly
< gwillen>
so they do it even more frequently
< gwillen>
they are supposed to have UX people, but it's not like the UX people don't also get promoted for making big changes
< sipa>
wumpus: just because someone complains doesn't mean it needs to change
< gwillen>
*shrugs* I think churn is a fact of life in software
< sipa>
but it may be worthwhile to look at why it was changed in the past
< wumpus>
midnightmagic: it's painful to overcome, I agree
< gmaxwell>
sipa: thats why I was asking instead of just opening a PR, to get context.
< midnightmagic>
Yeah, sick people like me on them. I'll change the topic to POWER hardware, and they'll go off and buy a Blackbird and forget they had a complaint at all! :)
< gmaxwell>
[I certantly remember this stuff being changed before, not that particular behavior but the opening message]
< midnightmagic>
wumpus: You could do the Linus thing and take up extensive and heavy drinking for a couple decades.
< gwillen>
look at it this way, we know more now than we did then, so we're more likely to make the right choice now than we were then :-)
< wumpus>
gmaxwell: yes... I think at a deeper level it's something like 'people only pay attention to the GUI to complain about something'
< wumpus>
midnightmagic: I don't like shouting at people :p
< gmaxwell>
is where the 'x years behind' language was added.
< midnightmagic>
wumpus: hehe I was about to say, just kidding, the fact you haven't means IMO you're ahead of where Linus was.
< wumpus>
gmaxwell: it might even be that I didn't even find it a very good idea at the time
< gmaxwell>
Prior to that it gave a height behind, with numbers based off peers starting height claims.
< gmaxwell>
IIRC we also had some issue with malicious/broken peers at the time giving bogus starting heights.
< gmaxwell>
I agree that the blocks based behind is pretty opaque and unhelpful to users, and obviously the old behavior of relying on peers claimed heights is not a good one.
< sipa>
it looks like that PR is just introducing a better estimation algorithm, without any reasons for the particular UI chosen
< wumpus>
midnightmagic: I guess one thing I am good at is keeping the project together despite all the controversy and hostility from outside
< gmaxwell>
What I was thinking of doing was replacing the 'foo behind' language with a 'Synced up to yyyy-mm-dd' or similar, with a rational that it would not be realistically possible to mistake that for a 'how long it will take to sync' (Omg it's going to take 2018 years to sync! :P )
< wumpus>
gmaxwell: oh it moved from blocks behind?
< gmaxwell>
wumpus: yes
< wumpus>
gmaxwell: I thought it showed a date first, as you proposed
< sipa>
gmaxwell: sounds very reasonable to me
< gmaxwell>
Not as far as I can tell from the history. There might have been a branch at some point that did?
< wumpus>
yes it might have been a proposal then at the time, which didn't make it?
< wumpus>
people chose the N days behind
< gmaxwell>
most of the PR discussion is about the progress estimation.
< gmaxwell>
it originally gave it in days, and before it went in you changed it to use more human-ish units at schildbach's request.
< gmaxwell>
But I don't see any discussion of anything but a 'behind'.
< gmaxwell>
The prior behavior was N blocks behind.
< wumpus>
ok
< gwillen>
gmaxwell: if you wanted to include time-in-past, perhaps less confusing would be "synced blocks through $DATE (XX units ago)"
< wumpus>
I'm happy if people can agree on something
< gwillen>
I imagine that would less tempt people to imagine that it will take XX units to sync.
< wumpus>
please don't make this another bikeshedding thing
< * sipa>
forcibly volunteers gwillen to suggest an improvement
< gwillen>
but just a bare "through $DATE" obviously presents no possible confusion.
< gwillen>
for the record I have no preference and will express no opinion on the final outcome, I only offer an option for cleverer people than me to consider :-)
< gmaxwell>
gwillen: I think any AGO is going to trigger the same 'it'll take this long to finish' confusion. Is there an important reason for the ago?
< sipa>
i think anything with an actual date will be less confusing
< gwillen>
gmaxwell: nope, just avoid making me do mental math :-)
< gmaxwell>
I think the date is useful, in the sense of the wallet will show transactions made up until DATE.
< gwillen>
but I guess there's no actual reason to _care_ how long ago it was
< gmaxwell>
But how is ago useful? it doesn't tell you when it will finish. right
< gwillen>
right, date is actually more useful if I want to know "will it include a particular tx"
< gmaxwell>
Basically I think people want to know two things: When it will finish, and (dim second) when is it current through.
< wumpus>
gwillen: that's a good point
< wumpus>
gwillen: it's actually *useful*
< gwillen>
*nods*
< gwillen>
yeah, on reflection it is mostly _fun and entertaining_ to see how long ago it's synced through
< gwillen>
which is maybe not a good reason
< wumpus>
we've left fun and entertaining long ago, it's deadly serious now
< gwillen>
yeah
< midnightmagic>
Everybody likes watching speed meters. "Verifying X utxo/sec, complexity measure Y". And a little running graph. With blinking lights. Where's that guy who was trying to do chain visualization in OpenGL anyway..
< * midnightmagic>
ducks and runs away
< gmaxwell>
sipa: I agree with your earlier point that the sync taking a long time is the real issue.
< gwillen>
honestly for my own purposes, the most important innovation in progress technology was the "XX percent per second" meter
< gwillen>
that's really all I look at now when doing IBD
< gmaxwell>
gwillen: what I think from talking to people they do is dimiss that it's-not-in-sync dialog, then they just see "XX years behind" and at least some portion of them mistake it for an ETA.
< gwillen>
ahhhh, right, that appears in the status bar which is normally covered by the dialog to start
< gwillen>
*nods*
< gmaxwell>
I dunno what percentage, probably small, but enough that I see a confused user every couple of months.
< wumpus>
midnightmagic: hah we've had ideas like that xD it would have been fun at some point in time
< gwillen>
so perhaps the status bar should include an _actual_ ETA? if it doesn't already? (I forget what it says and I don't have a client in IBD to check)
< wumpus>
midnightmagic: now it's more like making a joke at a funeral I guess
< gwillen>
(or percent synced, or whatever the most important thing is from the dialog they just dismissed)
< gmaxwell>
I was particularly frustrated today because I encountered yet another one where they got a long reply given them a 10 step procedure to stop using bitcoin core, which never even mentioned they were confused about progress. (certantly not the first time I've seen that happen).
< gwillen>
(I just never dismiss the dialog until sync is complete because I don't know how to get it back, or whether you can get it back)
< gmaxwell>
gwillen: you click on the 'xx behind' text to get it back.
< gwillen>
ahhhh
< wumpus>
not even the fancy new progress dialog helped :-(
< gmaxwell>
Oh I'm sure it helps.
< wumpus>
people were confused about progress, so that overlay was added, but ... it's all the same
< gmaxwell>
Though it also could use some improvements, the choice in bold text is weird. IIRC it was supposted to get fixed before the release but it wasn't.
< wumpus>
yess of course they just want to attack bitcoin core
< wumpus>
we're the enemy after all
< gmaxwell>
and/or just the blind leading the blind
< wumpus>
it doesn't matter, whatever your politics, either bitcoin is destroying the world, or well otherwise there's always infighting between implementation
< wumpus>
it's good that everyone is so mature about it
< sipa>
wumpus: i find the twitter mute button incredibly useful
< gmaxwell>
I find not loading twitter useful. :P
< wumpus>
yea :/
< gmaxwell>
that popup thing is kind of mesmerizing.... click, hide, click, hide.
< wumpus>
reddit is so much better
< wumpus>
yes I think that's kind of neat !
< gmaxwell>
An alternative would be to make the XX behind just show the ETA and a "(click for details)". Though I'm not sure what it shoudl display when the ETA isn't available.
< gmaxwell>
gwillen: researching user reports, the percent per hour thing also seems to be confusing in non-initial sync.
< gwillen>
interesting
< gwillen>
I guess that makes sense, after IBD you're not probably thinking in terms of "percent of entire blockchain downloaded"
< gmaxwell>
because it seems to report percentage of the whole chain always.
< gwillen>
well, it's not clear what else it would report
< gwillen>
"percent of the amount of blockchain that was missing when I started up most recently" maybe?
< gmaxwell>
Thats probably what its being interperted as in any case.
< gwillen>
my user model is hopelessly contaminated with already knowing what's going on, so it makes perfect sense to _me_
< gmaxwell>
"Bitcoin core is currently 15 hours behind as I'm writing this and the piph (progress increase per hour) is at a STUPIDLY low speed. There are 95 blocks left but it says its going up 0.04% per hour."
< gwillen>
I mean, it's also maybe worth considering that some users will have less useful input than others
< gwillen>
"Bitcoin core is also apparently using 50% of my disk which is not true. An application was using 12mb/s of disk and it was only using about 20% of the disk total. Bitcoin core however is using 3mb/s and is using 50%"
< gwillen>
I can't even parse what this sentence is attempting to communicate.
< sipa>
gwillen: I/O bandwidth grap?
< gmaxwell>
gwillen: absolutely, but actually the percentage per hour is pretty inexplicable when talking about syncing 0.0002% of the chain. :P
< gmaxwell>
I mean in those cases the number won't even show anything useful.
< gwillen>
yeah, it's weird to be sure, I guess my machine syncs fast enough that I don't run into such tiny numbers for more than a few seconds
< gmaxwell>
gwillen: regarding that sentence, I think he edited his question.
< gwillen>
he did edit it, I just cannot for the life of me figure out what the edit it _saying_.
< gmaxwell>
gwillen: likely he only had one stuck peer up or whatever.. and probably it was done by the time he was through posting.
< gmaxwell>
gwillen: it's some IO meter thing, who knows what.
< gmaxwell>
The comment I think its basically saying "there is a lot of random IO"
< gmaxwell>
e.g. 50% "utilization" but only 3MB/s.
< gmaxwell>
In any case, I've found three people conused by the percentage thing. That was just the most clear (lol, I suppose) of them.
< gwillen>
yeah, *nodnods*
< gmaxwell>
I don't see anyone confused about the ETA thing.
< gwillen>
I assume no, because nobody uses OS X but me: has anybody run the various sanitizers on OS X?
< gwillen>
it seems like they don't build here, due to -fsanitize being passed to the compiler but not the linker
< gwillen>
I can easily one-off fix this just to run them on my own change, but I am afraid to dive in to fix it properly
< gwillen>
oh, it's weirder than that
< gwillen>
we're passing -fsanitize to libtool, which is dropping it on the floor and not passing it to the linker