< bitcoin-git>
bitcoin/master 33eb907 Russell Yanofsky: Fix ComputeTimeSmart test failure with -DDEBUG_LOCKORDER...
< bitcoin-git>
bitcoin/master 1846296 MarcoFalke: Merge #12681: Fix ComputeTimeSmart test failure with -DDEBUG_LOCKORDER...
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #12681: Fix ComputeTimeSmart test failure with -DDEBUG_LOCKORDER (master...pr/locksmart) https://github.com/bitcoin/bitcoin/pull/12681
< bitcoin-git>
[bitcoin] sipa opened pull request #12683: Fix more constness violations in serialization code (master...201803_moreser) https://github.com/bitcoin/bitcoin/pull/12683
< tied2chainz>
hi
< tied2chainz>
just have a really quick question about version 16.
< sipa>
tied2chainz: shoot
< sipa>
(and generally just ask, don't ask to ask)
< Randolf>
(Slow questions are okay too.)
< tied2chainz>
wanted to know can I also lookup transactions outside of send and receive transactions.
< sipa>
no
< tied2chainz>
only transactions that I've received or sent through my wallet
< sipa>
unless you enable the transaction index (run with -txindex, or put txindex=1 in bitcoin.conf; that will enable the getrawtransaction txid RPC which works for all transactions, not just your own)
< sipa>
it will require a full rebuild of the database though, and slows things down significantly
< tied2chainz>
yeah thanks for the heads
< eklitzke>
interesting, somehow i corrupted my chainstate directory
< tied2chainz>
thanks for the heads up
< sipa>
eklitzke: what did you do?
< kallewoof>
tied2chainz: You can look them up if you know the block hash they're in.
< eklitzke>
and then the next time i tried to start it
< eklitzke>
corrupted database
< sipa>
eklitzke: wow, with a clean shutdown? :S
< eklitzke>
this is actually on v0.16.0, not from my branches
< eklitzke>
hmm
< eklitzke>
interesting, well i had been asking users if they could give me corrupted database files, looks like i got what i was asking for
< kallewoof>
Am I right that signmessage <addr> leaks the public key of <addr> in the resulting signature?
< kallewoof>
s/leaks/exposes/ I guess.
< eklitzke>
actually i remember now what i was doing, the last thing i had been doing with this was running my python utxo scanning script on the data directory
< kallewoof>
sipa: Well, it's sorta like spending an UTXO vs handing out the pubkey for its PKH. One seems worse than the other (though only a little).
< sipa>
kallewoof: but regardless, you can't create a signature without revealing the public key
< kallewoof>
Yeah, I was initially very confused about how verifymessage could pull it off with only an address, until I realized the signature had a recoverable pubkey in it.
< kallewoof>
It struck me that people may not realize they are revealing the pubkey when they signmessage a utxo. Clearly as you say, you need the pubkey to verify the sig.
< kallewoof>
Perhaps it doesn't really matter that you show the pubkey (long) before spending.
< luke-jr>
kallewoof: hopefully when someone gets around to replacing signmessage, it can be MAST-based with a separate key for messages
< kallewoof>
luke-jr: Interesting. I'll have to think about how that would work.
< sipa>
kallewoof: well a decent replacement for signmessage would be something that just uses script
< sipa>
(but signs something else than a tx)
< sipa>
that would automatically support any kind of output type
< kallewoof>
sipa: That makes sense, yeah.
< meshcollider>
Wasn't someone already working on a BIP draft for an improved signmessage, or am I imagining things
< kallewoof>
sipa: Presumably it would sign H(addr||message). Not sure if addr is strictly necessary though.
< luke-jr>
meshcollider: at one point, someone was talking about it at least
< sipa>
kallewoof: yup, this is the way to fix it
< mrjenkins>
hello!
< mrjenkins>
why does github repo say that the build is failing?
< fanquake>
If you'd already looked at a PR 1 month ago; why wait until it's been squashed, rebased and has 3 ACKs to suddenly start nit-picking it to shreds?
< sipa>
fanquake: what PR are you referring to?
< eklitzke>
sipa: for #12683 did you do this manually or have a tool identify the temporary references?
< sipa>
eklitzke: there are only 2 dozen calls of REF, some are there as arguments to one of the wrappers (which aren't fixed yet), and some are around the wrappers (which are fixed now)
< sipa>
it's quite mechanical
< sipa>
eklitzke: #10785 has many more things like this
< kallewoof>
fanquake: Don't know if you're referring to me, but I may be guilty of doing that. I'll try to think of whether it's worth it with the amount of ACKs for current state in the future.
< pierre_rochard>
achow101: I’m taking a look at #12375 - do you have a fix in the works? I just implemented Akio’s solution and it works, though I’d like to do more research before letting a platform-specific issue add what feels like cruft.
< bitcoin-git>
[bitcoin] practicalswift opened pull request #12686: travis: Generate a trap for signed arithmetic overflows (enable -ftrapv) (master...trapv) https://github.com/bitcoin/bitcoin/pull/12686
< wumpus>
<fanquake> If you'd already looked at a PR 1 month ago; why wait until it's been squashed, rebased and has 3 ACKs to suddenly start nit-picking it to shreds? <- yeah...
< wumpus>
feel free to call me out when I do that
< wumpus>
usually I add "but this doesn't have to be done in this PR" in that case
< * luke-jr>
calls jonasschnelli out on doing it with multiwallet? XD
< wumpus>
at this point I'd be happy to have *any* multiwallet GUI in, just so that work can proceed on it in the repository
< luke-jr>
well, #11383 is ready besides a new conflict in wallet_tests I could easily resolve :x
< wumpus>
I'm still not convinced adding that whitespace check to travis was a good idea. On the other hand at least it avoids PRs to "fix" whitespace!
< fanquake>
After discussing with theuni 5.9.x is the way to go for the next QT bump, however the changes should be more involved than what's been done in that PR so far.
< fanquake>
I think I'll close it for now. I start work on an alternate pr last week.
< wumpus>
agree, better to close it if it doesn't make progress, probably the author underestimated the work involved
< wumpus>
it's kind of a long haul, for a first-time contributor to try to bump qt in the depends system
< wumpus>
might learn a thing if he was really involved, but it's going slow
< fanquake>
I'm not quite on top of how we are doing things on Transifex.
< wumpus>
I have no idea either
< setpill>
has anyone tried to test #12656 ? currently running into some problems but not sure if it's an issue in my virtualbox install or in the PR
< gribble>
https://github.com/bitcoin/bitcoin/issues/12656 | Add scripts for doing gitian builds on any platform using VirtualBox + Vagrant + Packer by maaku · Pull Request #12656 · bitcoin/bitcoin · GitHub
< fanquake>
setpill I'm planning on testing shortly. Report any issues your having to the PR.
< wumpus>
I don't use virtualbox anymore (now use libvirt/virsh on my VM servers) so can't test
< fanquake>
wumpus I was wondering if the /docs repo might be a better place for that PR ?
< wumpus>
fanquake: at least the documentation for it should go into the docs repo, so that it's with the other menagerie of gitian building methods. If there are scripts that are more-or-less bound to the bitcoin core release schedule they can be in our repo. Not sure.
< wumpus>
I think the other gitian building script is also in our repo
< bitcoin-git>
bitcoin/master c316fdf João Barbosa: [qt] Add support to search the address book
< bitcoin-git>
bitcoin/master 56cc022 Wladimir J. van der Laan: Merge #12080: Add support to search the address book...
< bitcoin-git>
[bitcoin] laanwj closed pull request #12080: Add support to search the address book (master...2018-01-searchaddressbook) https://github.com/bitcoin/bitcoin/pull/12080
< promag>
in particular, if the rescan should resume or not
< instagibbs>
wumpus, I must be the only one who gets triggered seeing extra whitespace on my git diff...
< wumpus>
instagibbs: no, I don't think so, it's really easy to notice such things. I consciously have to push myself to ignore all kinds of small grievances while reviewing, to be able to focus at the real changes
< wumpus>
and yes, sometimes I still fail at that
< achow101>
pierre_rochard: I haven't really looked at that issue yet. I can't reproduce it either; I don't have a mac
< provoostenator>
wumpus: should I make a PR to get rid of it then?
< wumpus>
provoostenator: dunno, I don't think there's really a hurry
< provoostenator>
I didn't specificy when :-)
< wumpus>
I don't think anyone would be opposed to just removing safe mode and everything assosicated with it, but there's probably more important things, its existence isn't blocking any developments
< wumpus>
otoh it was deprecated in 0.16 so removing it in 0.17 would be sensible
< provoostenator>
Afaik the parameter literraly doesn't do anything except show that message. It's not setting any (global) variable.
< wumpus>
so if you run with -disablesafemode=0 -testsafemode , you should be prevented from executing various RPCs
< wumpus>
(to be precise, the ones that call ObserveSafeMode)
< wumpus>
congratulations, thanks for sticking with this
< provoostenator>
Very nice!
< Murch>
Thank you achow101, instagibbs, morcos, ryanofsky, eklitzke and everyone else! :D
< Murch>
This makes me really happy!
< achow101>
\O/
< achow101>
Time to start working on replacing the fallback strategy
< Murch>
Yessir!
< Murch>
Thanks wumpus
< bitcoin-git>
[bitcoin] Sjors opened pull request #12687: Remove unused -testsafemode [AKA: why this PR is wrong] (master...2018-03/testsafemode) https://github.com/bitcoin/bitcoin/pull/12687
< provoostenator>
wumpus: I figured out what I was missing...
< bitcoin-git>
[bitcoin] Sjors closed pull request #12687: Remove unused -testsafemode [AKA: why this PR is wrong] (master...2018-03/testsafemode) https://github.com/bitcoin/bitcoin/pull/12687
< instagibbs>
gave a whoop at taco place when i saw the email. Thanks for all the heavy lifting achow101 :)
< Murch>
instagibbs: Everybody was looking at my bewilderedly when I just whooped here at the office. Had to explain what happened. :D
< instagibbs>
next: rip up knapsack and crazy transaction looping...
< sipa>
congrats all, and achow101 and Murch in particular
< iyahjeff>
Hi there. Anyone running a full BTC node on Linux that would be kind enough to paste me the output of “du -shm .bitcoin/blocks/”
< arubi>
191199 datadir/blocks/
< arubi>
oh this is #-core-dev
< iyahjeff>
@arubi Thanks a lot.
< pierre_rochard>
ryanofsky I’m looking at the 0.17 wallet PRs to see what to review next, is #11536 the priority? It seems to precede the two other label PRs
< meshcollider>
Yay congrats on the coin selection merge finally achow101, Murch \o/
< bitcoin-git>
[bitcoin] dooglus closed pull request #11085: Add 'sethdseed' RPC to initialize or replace HD seed. (master...set_hd_seed) https://github.com/bitcoin/bitcoin/pull/11085
< santiago0>
hello
< santiago0>
I'm IT student. Never participated to bigger projects. How do you manage bitcoin source code? What IDE are you using?
< sipa>
text editor
< AndyS2>
I guess most people just use vim and the command line. After trying a few IDEs, I settled for Eclipse CDT with a VIM plugin for better overview. I'm just fooling around, though.
< AndyS2>
Mostly because their debugger has a nice overview and seperate interfaces weren't as nice to use.
< AndyS2>
oops
< santiago0>
ok thanks. Until now I also used VIM for everything.
< AndyS2>
It's easier to navigate unknown code with an IDE in my opinion. that said, there's probably some plugin that does just that for vim, too.
< AndyS2>
I just got a vim plugin for eclipse. serves my purpose well