< nanotube>
https://bitcoin.org/en/download <- suggest that the "over 20GB" part toward the bottom should probably be updated to "over 50GB", or point to some resource that tracks blockchain size for future-proofness, to avoid giving misleading info.
< gmaxwell>
hah. last time that got bumped I suggested removing the explicit size claim!
< Luke-Jr>
I think there's an open issue for that since some weeks ago :/
< gmaxwell>
I wonder if we shouldn't periodically write out a opaque file that gives a hash of a block 100 back or so, which acts like a persistant validation bypass, so that if you resync a pruned node it can skip the expense.
< gmaxwell>
big problem with pruning right now is that the frequent leveldb corruption some users expirence make it quite a gamble.
< morcos>
gmaxwell: can you elaborate on that? what expense are you skipping? validation?
< morcos>
are you basically talking about your own private checkpoint?
< Luke-Jr>
local UTXO commitments for pruned bootstrapping would be handy, but dangerous
< * Luke-Jr>
ponders that each release is 1 GB of hosted data for him XD
< Luke-Jr>
there were no changes to bitcoin-cli in 0.11.1, right?
< Luke-Jr>
answer: OPENSSL_no_config :|
< cfields>
Luke-Jr: that fixes possible crashes (or exit()s) due to faulty local openssl config
< Luke-Jr>
right
< cfields>
i don't think it should cause any abi issues?
< Luke-Jr>
no, but it's a reason to bump -cli pkg to 0.11.1
< midnightmagic>
btcdrak: is there some other place from the gitian sigs to find your pubkey? Or have other people in core signed it?
< btcdrak>
petertodd signed it
< btcdrak>
it's on the public keyservers
< midnightmagic>
sometimes i think my comments are being filtered through some kind of cthulhu filter before they end up in front of everyone else's eyes.
< michagogo>
midnightmagic: huh?
< nanotube>
midnightmagic: how did you know about my cthulhu filter? i was told it was undetectable. >_____>
< midnightmagic>
michagogo: eh. I had a big rant typed out but it doesn't matter. I just hate using public key servers. They're full of sigspam and the maintainers are too stubborn to stop using shortform keyids. Also, I am only okay with transitive trust sigs: via that, and places where btcdrak has direct control over, I triangulate key validity and mark local trust accordingly.
< btcdrak>
midnightmagic: you sound eccentric :-P
< midnightmagic>
I fully expect virtually nobody here has actually verified anything about my keys except they're sitting there on pgp.mit.edu after someone who's not-me uploaded them there.
< midnightmagic>
btcdrak: Well what's the point in using PGP keys at all if nobody does any verification on them right?
< btcdrak>
midnightmagic: just teasing you :)
< midnightmagic>
:-P
< midnightmagic>
And thereby you point out my hypocrisy! lol I love it.
< morcos>
btcdrak: just sent an email to ML, i'm a bit confused as to why we're still getting people to review those pulls if we expect them to change?
< morcos>
Request for acks on 6618, its a very simple change (other than modifying the unit test) its really an improvement that would have been nice to have backported to 0.11 and included in the last release. We can still do it for the next realease.
< morcos>
wumpus or jonasschnelli: i'm also going to refresh 6134 to do the same thing (return the next best answer if the result is -1) for priority. Could you tell me if the way I'm updating the slider in updateSmartFeeLabel is right?
< jonasschnelli>
morcos: hmm..
< morcos>
I don't know anything about QT, and the way I made it if you try to move the slider over it keeps snapping back, which is kind of what I want, except it results in a stream of calls to estimateFee
< jonasschnelli>
does ui->sliderSmartFee->setValue() not work?
< * jonasschnelli>
is reading
< morcos>
it works, but if you try it out, you try to move the slider over to 1, and it won't let you (because answer is -1 or whatever) and so it kind of encourages you to keep trying to move it over, until you sort of give up and say hmm, i guess it wont' let me select anything higher than 2
< morcos>
but if you look at whats happening, as you're trying to move it over, its causing a repeated stream of function calls as you move it over and it triggers updates, it snaps back and triggers updates, all very quickly in succession
< jonasschnelli>
morcos: i think you have a strange loop there. from updateSmartFeeLabel() you call ui->sliderSmartFee->setValue() which has a signal to updateSmartFeeLabel().
< morcos>
yes
< jonasschnelli>
Somehow a circular loop.
< morcos>
this is why i wanted someone else to look at it! i think the loop ends because after it gets triggered once the else if clause should no longer be hit, EXCEPT if the user is still trying to move the slider over, which in practice happens for a little while
< jonasschnelli>
morcos: i can take a look at it.
< jonasschnelli>
Do you have other changes planed. Or can i work on top of 6134?
< morcos>
so i'd love a better way to do this, what i want to accomplish is if there are no valid fee estimates for say a confirmation target of 1, then it won't let you move the slider there
< jonasschnelli>
we could set the slider to readonly during that time..
< morcos>
i'm going to change more of 6134, but i don't think the changes should conflict.
< jonasschnelli>
But first i need to read myself into your PR... i miss the context because i'm working on some c script implementation and my head is full of OP_s
< morcos>
thanks for taking a look, no real hurry, but this pull has been open for a long time and i think its a nice improvement
< jonasschnelli>
morcos: okay. Will work on it
< morcos>
great!
< * jonasschnelli>
puts 6134 on the stack to work on. :)
< morcos>
Regarding my request for reviewing 6618, let me withdraw that, I think I'll fold it into 6134
< michagogo>
Also, an unfortunate typo got into release-process at some point... (gbuild -> bguild)
< michagogo>
wumpus: hm, I can understand not having release notes for chronologically earlier releases that are in a later branch
< michagogo>
But I feel like we should at least have e.g. All the 0.10.x notes in the 0.10 branch
< btcdrak>
morcos: because the PRs were already changed as per your request.
< btcdrak>
morcos: it's now masking the bits
< morcos>
btcdrak: yes, sorry missed that. i checked the BIP, but not the PR. you should maybe announce it instead of letting people discover it in the code? back in a few
< btcdrak>
morcos: yeah I agree. I guess the addition was also made invisible by squashing the commit.
< morcos>
btcdrak: thanks for sending the email!
< gmaxwell>
https://www.reddit.com/r/Bitcoin/comments/3ou1im/bitcoin_core_version_0111_released/cw0g8d0 someone should respond to "A cool example of how an attack can prompt developers to make Bitcoin better." with "This improvement was written years ago, but not activated because at the time it blocked most transactions. We've been waiting for wallets to upgrade; with the attacks going on, it didn't mak
< michagogo>
btcdrak: er, I don't know if that was yours or the other one, but they seem to both be deleted
< btcdrak>
Oh ffs
< michagogo>
(One of them has a comment, so it's appearing... Looks like someone made a throwaway to support gmaxwell)
< morcos>
wumpus: sorry for not doing this myself, but we really should make sure somoene runs the extended rpc tests before a release. actually i think i ran them on rc1, but then never got around to it for rc2.
< wumpus>
morcos: agreed, need to make sure some tests and checks are run before a release
< gmaxwell>
whomever gmaxwellfan is, thanks; but realize that any mention of me on reddit is going to likely result in me getting the same crap.
< wumpus>
michagogo: I guess that makes sense
< morcos>
wumpus: rpcbind_test.py doesn't work for anyone right? i'll comment it out of the extended tests
< wumpus>
morcos: it works if you use libevent beta/master
< wumpus>
morcos: I've also got the libevent people to backport that fix to next stable release
< wumpus>
morcos: but sure, you could comment it out for now, or better, the ipv6 part that fails
< morcos>
wumpus: ah thought about that, seems like we'll forget if thats what i do, but up to you
< wumpus>
another option would be to log the libevent version to debug.log, then parse that from the test, and determine based on that whether to do that subtest.. but nah...
< wumpus>
just comment it out is fine
< GitHub199>
[bitcoin] Michagogo opened pull request #6836: Bring historical release notes up to date (0.10...0.10-add-release-notes) https://github.com/bitcoin/bitcoin/pull/6836
< devrandom>
any known chef scripts for bitcoind that leverage gitian-downloader for auto-updates?
< Luke-Jr>
gmaxwell: lol, the linked comment seems to be very confused
< Luke-Jr>
gmaxwell: is there an actual problem?
< devrandom>
if not, I might write some
< btcdrak>
yeah gmaxwell: dont pay it any mind. They just want to stop us being productive (and they succeeded to some degree over the last several months)
< CodeShark>
the PR play is at a higher level than reddit - reddit is just a good way to measure response
< CodeShark>
but offtopic here
< CodeShark>
I guess only point being I think gmaxwell should focus his efforts on persuading more important people and fuck the trolls
< gmaxwell>
Luke-Jr: no. as noted in the actual PR, it was measured by multiple people. The guy at bitgo is likely seeing a mix of the malleability attack and the effect of the relay fee bump.
< Luke-Jr>
+1 on ignoring them then - it's not even on a reputable subreddit
< gmaxwell>
sure I was ignoring it, it's clearly trolling.
< btcdrak>
would it be wiser to merge 6312+6564 (sequence numbers and op_csv) into one PR?
< michagogo>
gmaxwell: uh. Wtf?
< michagogo>
sipa: that won't block np.reddit.com, pay.reddit.com (the domain they use for payments, but at one point you could use it anywhere on the site, and it was the only way to get https), etc
< michagogo>
Better to put it into a ublock origin filter if you want to block it
< michagogo>
devrandom: I've not been keeping track so closely lately. Has there been any improvement on the topic of LXC?
< michagogo>
It's annoying to have to keep manually upgrading the container
< devrandom>
I have to admit I don't recall the status there
< devrandom>
I've been distracted
< devrandom>
any progress would be on the relevant github issue(s)
< * michagogo>
wonders if one was ever created
< michagogo>
I'm not sure I understand why debootstrap is incapable of using packages from -updates/-security
< gmaxwell>
holy crap. I want a device that lets me shock people with lightning bolts over the internet when they don't disclose their software versions
< gmaxwell>
dcousens: the line before you joined was partly directed at you! :)
< gmaxwell>
"holy crap. I want a device that lets me shock people with lightning bolts over the internet when they don't disclose their software versions"
< gmaxwell>
:)
< gmaxwell>
dcousens: what version were you running that crashed?
< dcousens>
So, yeah, had a box up for 2.5 months no issues suddenly it went down after a get version
< dcousens>
gmaxwell: quickest way to check that on CLI?
< dcousens>
nvm
< dcousens>
"version" : 110000,
< sipa>
dcousens: or in the first line it prints to debug.log
< gmaxwell>
dcousens: look in debug.log? first line logged. or... yea
< sipa>
which will also report the git commit
< gmaxwell>
well shit.
< dcousens>
there was no other information, at all, anywhere :/
< sipa>
any chance it OOMed?
< dcousens>
sipa: no way to tell, I had it running using nohup but nothing showed at all
< gmaxwell>
sipa: it's crashing with ERROR: ReadBlockFromDisk: Deserialize or I/O error - ReadCompactSize(): size too large at CBlockDiskPos(nFile=356, nPos=43062353)
< dcousens>
Running it now in tmux so I shouldn't miss anything if it happens again
< sipa>
dcousens: did it crash with that error message?
< gmaxwell>
(that was from someone else, but it sounded like dcousens got the same thing)
< dcousens>
gmaxwell: I feel like my comment in that thread might be misplaced, I hadn't read the thread, only that my situation directly correlated
< gmaxwell>
dcousens: how did it correlate?
< dcousens>
gmaxwell: node went down after a get version, however I had no error message show
< gmaxwell>
just timing and you were on aws?
< dcousens>
correct
< gmaxwell>
okay, if you didn't get that error its almost certantly a different issue.
< dcousens>
will amend comment
< gmaxwell>
at least make it clear you didn't get that error.
< dcousens>
gmaxwell: I wonder if rromanchuk received that error
< dcousens>
His comment seemed to indicate he didn't IMHO
< dcousens>
sipa: is OOM handled gracefully or would we expect the process to just end with no message?
< sipa>
dcousens: you'd expect to die with a std::bad_alloc exception
< dcousens>
sipa: right, nothing of that sort. Will keep closer tabs on it
< gmaxwell>
well the exception wouldn't go into the logs, so you might not have seen it depending on how it was running.
< dcousens>
gmaxwell: indeed
< jcorgan>
Luke-Jr: your travis-ci emailed me about your #192
< Luke-Jr>
jcorgan: ?
< jcorgan>
yep, just got an email
< jcorgan>
i guess about your branch zeromq-0.11.x
< jcorgan>
so thoughtful of them
< Luke-Jr>
eh?
< Luke-Jr>
I'm lost
< Luke-Jr>
jcorgan: no idea why it emailed you
< jcorgan>
no worries
< Luke-Jr>
note the error is just Travis's bug
< dcousens>
gmaxwell: them pesky rpi nodes and their SD cards :P
< gmaxwell>
gah he still didn't answer my question!