< valentinewallace> \query jonasschnelli Hi, you commented on one of my PRs yesterday. Are you available for a question?
< bitcoin-git> [bitcoin] fanquake closed pull request #11921: Fixing env variables/arguments in OpenBSD build instructions (master...master) https://github.com/bitcoin/bitcoin/pull/11921
< bitcoin-git> [bitcoin] fanquake closed pull request #11967: Add script to test the dns seeds (master...2017/12/seed_test) https://github.com/bitcoin/bitcoin/pull/11967
< bigboytimc> hey got a quick code question for you guys
< meshcollider> bigboytimc: "don't ask to ask, just ask" - pieter ;)
< bigboytimc> haha sounds good, my question is just that I'm looking through the source code and I'm trying to find where the segwit extended block structure is
< bigboytimc> I figured it'd be in primitives with block.h, but there's nothing there that looks like it
< bigboytimc> so I guess I'm just wondering where the extended block is in the code
< echeveria> 'extended block'?
< meshcollider> what do you mean by an extended block, the block structure hasn't really changed
< bigboytimc> doesn't segwit include an additional structure that isn't on the blockchain?
< gmaxwell> no.
< bigboytimc> like the change involved moving some parts of the block into a separate structure to add more transactions?
< gmaxwell> the blocks are totally unchanged.
< gmaxwell> bigboytimc: nope.
< gmaxwell> There is a new field in transactions, called the witness field, which is after the outputs and before the nlocktime.
< meshcollider> bigboytimc: transactions are serialized and hashed in a slightly different way now, but they are still included in blocks the same as they used to be
< photonclock_> How well is Bitcoin holding up to the mempool overflow? Is everything working as expected?
< gmaxwell> New nodes know how to strip out this witness field from the transactions befor passing them along to old unupgraded nodes.
< gmaxwell> photonclock_: yup. things are working very well.
< bigboytimc> interesting, I guess reading about segwit made it sound like they took the witness stuff and added it to a different structure
< gmaxwell> bigboytimc: there is a lot of misinformation out there.
< photonclock_> gmax I know this is not the room for general Bitcoin chat - can I chat you up on the Bitcoin channel?
< meshcollider> bigboytimc: there are a number of bad actors who like to mislead people into thinking segwit does things which it doesn't, mostly because they themselves are uneducated. Try http://segwit.org/
< bigboytimc> thanks!
< meshcollider> for this command line arg registration thing, whats the cleanest way to have a pointer to a variable whose type is not known currently
< meshcollider> or I should just use UniValue for the globals
< instagibbs> did someone say command line registration of args? meshcollider pointer to PR/issue?
< meshcollider> instagibbs: working on it atm, was discussed here: https://botbot.me/freenode/bitcoin-core-dev/2017-12-14/?msg=94674799&page=9
< meshcollider> issues 11819 and 1044 are directly related
< meshcollider> still solidifying the approach in my head atm
< jonasschnelli> valentinewallace: sure.. shoot your Q
< sipa> jonasschnelli: why are you awake? :)
< jonasschnelli> sipa: I'm usually awake at 17:26. :)
< jonasschnelli> Don't assume I'm always in CH. :)
< sipa> oh.
< sipa> hawaii?
< jonasschnelli> Jup
< SomeBuggyCode> Hello
< SomeBuggyCode> I just wanted to ask and see if there might be anywhere to start besides reading the bitcoin docs. Is there any good way to start contributing? Thank you
< jonasschnelli> SomeBuggyCode: https://github.com/bitcoin/bitcoin/issues
< SomeBuggyCode> True enough
< jonasschnelli> Look also for the "good first issue" tag:
< SomeBuggyCode> Oh wow
< SomeBuggyCode> Didn't know about that
< bitcoin-git> [bitcoin] Varunram opened pull request #11969: logs: Improve "mempool min fee not met" error (master...mempoolfix) https://github.com/bitcoin/bitcoin/pull/11969
< mcorbettsr> hello all having prob with core 0.15.1
< jonasschnelli> meshcollider: maybe #bitcoin?
< jonasschnelli> sry, mean mcorbettsr but he left
< meshcollider> heh all good, I never understand why people ask questions and then leave before they get a response
< gmaxwell> maybe he solved his problem
< jonasschnelli> Do I need to hold cs_main while looping through CCoinsViewCursor& cursor with while (cursor.Valid()) and cursor.Next();?
< jonasschnelli> I guess no (at least gettxoutinfo does not
< jonasschnelli> +)
< ryanofsky> jonasschnelli, i think if you're using pcoinsdbview you don't need cs_main, but if you using pcoinsTip you do
< jonasschnelli> thanks ryanofsky
< ryanofsky> i was also wondering if #9306 might be useful for what you are doing
< gribble> https://github.com/bitcoin/bitcoin/issues/9306 | Make CCoinsViewCache::Cursor() return latest data by ryanofsky · Pull Request #9306 · bitcoin/bitcoin · GitHub
< jonasschnelli> ryanofsky: I'm implementing UTXO scans (provide pubkeys, xpubs, get unspents, total, etc.)
< jonasschnelli> ryanofsky: Can you explain the benefits of 9306?
< ryanofsky> 9306 just lets you scan pcoinsTip instead of pcoinsdbview. pcoinsTip has current utxo data, pcoinsdbview has older utxo data from the time of the last flush
< jonasschnelli> If you FlushStateToDisk(); and then loop with the curser will give you the same results?
< ryanofsky> yeah, that should basically be the same
< jonasschnelli> Are there any performance implications/benefits?
< ryanofsky> meshcollider, for command line option registration, can't you require the type of the option when registering it? this would let you enforce the type during parsing
< jonasschnelli> Scanning the whole set takes a couplf of mins here
< jonasschnelli> *couple
< ryanofsky> jonasschnelli, i don't know the performance tradeoffs. if calling FlushStateToDisk() is an option though, I would go with that because it seems simpler
< jonasschnelli> ryanofsky: I'll open a PR soon (next week maybe) and happy if you have a look for possible optimisations...
< jonasschnelli> thanks
< ryanofsky> sounds good
< sipa> flushing just to perform a wallet operation sounds like sething we should avoid
< bitcoin-git> [bitcoin] laanwj pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/604e08c83cf5...7a11ba7e01f3
< bitcoin-git> bitcoin/master b798f9b Wladimir J. van der Laan: contrib: New clang patch for install_db4...
< bitcoin-git> bitcoin/master c0298b0 Wladimir J. van der Laan: contrib: Make X=Y arguments work in install_db4...
< bitcoin-git> bitcoin/master d95c83d Wladimir J. van der Laan: contrib: FreeBSD compatibility in install_db4.sh...
< bitcoin-git> [bitcoin] laanwj closed pull request #11945: Improve BSD compatibility of contrib/install_db4.sh (master...2017_12_contrib_bsd) https://github.com/bitcoin/bitcoin/pull/11945
< meshcollider> ryanofsky yeah that's what I thought, but I can't think of how to pass a type as a parameter in the registration
< meshcollider> Without using a variant or univalue or whatever
< ryanofsky> is registration just declaring a global variable? if so the type should just be part of the variable type, maybe a template argument
< meshcollider> But you have to pass a pointer to the global variable to the arg manager right, so I'm just confused as to the best way of accepting a pointer to a variable of unknown type
< ryanofsky> meshcollider, probably through subclassing. you could have list<unique_ptr<Option>>, with IntOption, BoolOption, StringOption subclasses, for example
< bitcoin-git> [bitcoin] laanwj pushed 8 new commits to master: https://github.com/bitcoin/bitcoin/compare/7a11ba7e01f3...711d16ca4a91
< bitcoin-git> bitcoin/master cdc260a MeshCollider: Add GetCScripts to CBasicKeyStore
< bitcoin-git> bitcoin/master b702ae8 MeshCollider: Add CScripts to dumpwallet RPC
< bitcoin-git> bitcoin/master ef0c730 MeshCollider: Add scripts to importwallet RPC
< bitcoin-git> [bitcoin] laanwj closed pull request #11667: Add scripts to dumpwallet RPC (master...201710_dumpwallet_scripts) https://github.com/bitcoin/bitcoin/pull/11667
< bitcoin-git> [bitcoin] ryanofsky opened pull request #11970: Add test coverage for bitcoin-cli multiwallet calls (master...pr/mcli) https://github.com/bitcoin/bitcoin/pull/11970
< bitcoin-git> [bitcoin] laanwj closed pull request #10051: adhere to `-whitelist` for outbound connection (master...whitelist-outbound) https://github.com/bitcoin/bitcoin/pull/10051
< DSidH> When creating a transaction by hand, how do I decide the scriptPubKey contents? Do I just look at the first byte of the pubKeyHash and decide that its either P2PKH or P2SH ?
< DSidH> nvm: got the answer. (yes)
< Varunram> If I may ask, what's the reason in some of the license banners being old? (e.g. bitcoinconsensus.h has a 2009-2016 banner)
< wumpus> Varunram: usually we do one "update copyright years" PR at the end of the yera
< wumpus> if the file is touched that year
< Varunram> was just curious, thanks!
< wumpus> it's certainly allowed to update the copyright year of a file together with your change, but almost no one bothers to do that, and it might even result in merge conflicts/rebases as it's a single hotspot per file. There's just no urgency in updating them.
< Varunram> yep, got the "don't update copyright until the file is changed" part, but just wanted to know the rationale behind it :)
< bitcoin-git> [bitcoin] Varunram opened pull request #11971: [docs]: include README with binary releases (master...bindoc) https://github.com/bitcoin/bitcoin/pull/11971
< ilanosortap> Hey guys, i would like to contribute to this project. I understand that the first step should be to build it on my system, how can i do so?
< ilanosortap> Also, since i am beginner how can i choose bugs to work on
< mikestovlensky> Anyone here?
< mikestovlensky> I've got a quick question
< mikestovlensky> Hi Ryan
< mikestovlensky> Have you had any contact with the people at Coinbase about when they plan to support Segwit?
< BlueMatt> mikestovlensky: dont think this is the place, #bitcoin
< ryanofsky> sorry, i don't know anything and i don't think coinbase developers are active here
< BlueMatt> also, answer is probably no
< mikestovlensky> I asked Coinbase, they just ignore me
< mikestovlensky> Just checking in case they have a line in with you folks
< wumpus> no, not at all
< mikestovlensky> thanks folks. Keep coding ahead. We'll win this battle. Roger Ver and his cronies got nothing on the hard work you lot are doing
< mikestovlensky> The community believes in you guys. Your vision is the way forward. I'll leave you lot to plug back in. Merry Xmas in advance
< wumpus> thank you, same to you
< ilanosortap> Thanks a lot @ryanofsky
< goatpig> Is there a version of SPV that keeps track a record of the last 1000 blocks or so?
< wumpus> no, there is no SPV mode in bitcoin core at all at the moment
< goatpig> oh, what about pruned mode?
< wumpus> there's https://github.com/bitcoin/bitcoin/pull/9483 which could use review and testing
< wumpus> yes, there is a pruned mode
< goatpig> thanks
< luke-jr> goatpig: pruned mode isn't SPV
< goatpig> i know, im just looking into alternate node modes and thinking forward
< jonasschnelli> goatpig: what are you building?
< jonasschnelli> IMO the most straight forward way if you want to run multiple wallets away from a Core node would be an RPC proxy.
< eck> can i get any book recommendations for practical/applied cryptography for an engineer who has an undergraduate or so level of background in mathematics
< jonasschnelli> The (new) wallet app could hold keys, and therefore do the signing. That app would create new wallets via RPC (proxy) (which would create a watch-only-wallet on your node).
< jonasschnelli> Which would also work with pruned peers.
< jonasschnelli> So a single pruned peer node could server (maybe) hundreds of wallets.. no index required
< jonasschnelli> Backup recovery is only possible via UTXO-set sweep
< goatpig> not building anything yet
< goatpig> working on my supernode
< goatpig> thinking of a hybrid mode where clients bootstrap on a public supernode then run off of a lite bitcoin node
< jonasschnelli> goatpig: what is a supernode?
< jonasschnelli> what is a lite bitcoin node?
< goatpig> db that tracks all blockchain history undiscrimnately
< goatpig> can handle any arbitrary history request quickly
< arubi> I can just feed it any blockchain and it would index it?
< luke-jr> archive node?
< goatpig> basically yes
< jonasschnelli> goatpig: fully indexed? Like an electrum server?
< luke-jr> oh
< goatpig> yes
< arubi> well, sounds like free for all dos
< jonasschnelli> Okay. Yes. Pretty inefficient if you just want to run a handful of wallets
< luke-jr> goatpig: so that assumes the blockchains in question are minimally compatible with Bitcoin in some way?
< jonasschnelli> But ideally for a large backend
< luke-jr> jonasschnelli: IMO it should be a goal that Core does something similar long-term
< goatpig> luke-jr: this is targetted at Bitcoin, i dont do alts
< arubi> oh ^
< webuser8434> Hey I just wanted to say that I think maybe at some point in the future you guys might want to consider dissolution of the "Core" brand thing. As much I support everything you do and how you do it the whole "Core" idea is Bad and you'll never stop paying price for it and by extension the entire Bitcoin community. It's divisive in its nature and it gives opponents a tangible target. Unless of course it goes away. It was
< jonasschnelli> luke-jr: Yeah.. I started to change my mind about indexing... it may should be in Core
< webuser8434> The only label there is is Bitcoin. Maybe use a section of bitcoin.org to communicate development .. whatever, details are not import. Core needs to die for Bitcoin to live!
< luke-jr> goatpig: that contradicts the "undiscrimnately" part.. invalid blocks aren't Bitcoin
< goatpig> arubi: any public facing service has to, but this can also be used internally by businesses
< webuser8434> Ah, and please please release this bloody Segwit yesterday.
< webuser8434> Good holidays chaps!
< luke-jr> jonasschnelli: for example, by tracking BCH's chain, we can use "total known hashrate" as a security metric
< wumpus> eck: 'cryptography' is kind of general
< arubi> goatpig, I'll have to see what you mean by "any blockchain"
< luke-jr> jonasschnelli: this is useful because if we know hashrate is mining BCH, we know it isn't being used to make an attack reorg chain
< jonasschnelli> luke-jr: hmm... thats interesting... though "known" hashrate is probably not enough for a security metric... there could be hashrate sitting around in non BCH/BTC chains
< goatpig> arubi: im not saying that, this is based on Bitcoin, i dont care about other networks/chains
< luke-jr> jonasschnelli: yes, but it's an improvement
< jonasschnelli> luke-jr: if you attack BTC, then you would just have to "hide" the hashrate until it drops out of BTC hash security algo, then attack with that hidden hashrate
< eck> wumpus: well eventually i'd like to understand things like pederson commitments, ring signatures etc. at a deeper level, my current understanding is superficial. doesn't necessarily have to be a book that covers those things specifically, but i'd like to build a more solid theory foundation.
< luke-jr> jonasschnelli: it's harder to hide 50%
< arubi> goatpig, alright, but I don't think I understand the usefulness if it's targeted at bitcoin specifically
< goatpig> my users run against fullnodes
< goatpig> this lets you do
< goatpig> 1 fullnode -> 1 db -> any amount of clients
< luke-jr> jonasschnelli: but for example, if 50% of miners switch to BCH, we wouldn't want to false flag this as a security problem in Bitcoin
< jonasschnelli> goatpig: I'm currently in favor of a direct backend. Means, you pass in new just created pubkeys in oder to track them (like a wallet), means you don't need block history, means you can run on pruned peers
< provoostenator> In theory you could feed the client any sha256 hash from any source and it couuld figure out how much went into it. So you can feed it headers from anything that's completely different from Bitcoin, as long as it has a trustworthy timestamp, and it only cares aobut estimating total work in the world.
< arubi> goatpig, so the clients aren't fully validating?
< jonasschnelli> goatpig: if you don't care about the backup recovery, you can run endless wallets on a 4GB pruned peer
< provoostenator> (known work, and the trustworthy timestamp bit doesn't seem trivial)
< wumpus> eck: in that case it might be useful to focus on the math underpinning it, group theory etc first
< goatpig> arubi: maybe some context is lost, the supernode is for armory, i was asking about litghter nodes for users to interface with while they bootstrap off a remote supernode
< goatpig> arubi: the armory stack is full node, db, client. im looking into possible ways around that
< arubi> ah, you're right. yea I understand now. I missed context
< wumpus> eck: one of my fav books in that regard is Victor Shoup's A Computational Introduction to Number Theory and Algebra, it's free for download too at http://shoup.net/ntb/
< eck> great, thank you for the recommendation!
< goatpig> jonasschnelli: as long as i can deliver a good service with armory, Core wouldn't need to work towards that
< wumpus> eck: besides I really enjoyed "applied cryptoanalsys
< wumpus> eck: but that's as off topic to cryptocurrencies as it's possible :)
< eck> i might enjoy it anyway, i'll take a look
< jonasschnelli> "applied cryptoanalysys"... is that the new word for hacking?
< jonasschnelli> :-)
< wumpus> jonasschnelli: it's about breaking rsa in some edge cases, timing attacks, and breaking various historical ciphers, so yea sort of
< wumpus> but not the expoitation kind
< provoostenator> I doubt this is reproducable, but I just managed to crash QT while it was doing a reindex (in order to get -txindex=1 to work). At the next launch it decided to just redownload the whole blockchain...
< wumpus> eck: http://cryptopals.com/ has some fairly interesting challenges re: applied cryptography things
< wumpus> provoostenator: uh oh
< wumpus> provoostenator: are you able to get a traceback?
< provoostenator> I'm not entirely sure how I managed to crash it. I was running the eclair lightning test suite, so it's possible that that interfered.
< provoostenator> wumpus: where would I find that?
< wumpus> well if you ran it in gdb it would be easy, otherwise, did it dump a core file?
< wumpus> linux also prints the crash eip to dmesg in case of a segmentation fault but I've found that fairly useless usually with ASLR
< jonasschnelli> provoostenator: I guess you ran in the OOM issue? It's still in master AFAIK
< provoostenator> OSX applications sometimes create crash reports. Maybe that's something we can / need to enable? At least in debug mode.
< jonasschnelli> The crash report should be stored somewhere
< provoostenator> I'm on sipa's SegWit branch and I set a pretty high dbcache
< jonasschnelli> provoostenator: reindexes on current master causes OOM (on my 32GB machine it did): You need https://github.com/bitcoin/bitcoin/pull/11824
< jonasschnelli> 11824 should probably by hi-prio
< jonasschnelli> I did a reindex 4-5 days ago and had the OOM crash on debian with 32GB ram
< provoostenator> Why would an OOM cause a new IDB?
< provoostenator> IBD
< provoostenator> IBD
< promag> does it cause ibd?
< jonasschnelli> provoostenator: I think you may end up with a corrupted db.. even if you souldn't (in theory)
< provoostenator> Oh I was monitoring memory usage, and that was about 30 GB during the reindex (I have 16 GB physical)
< jonasschnelli> provoostenator: yes. Its fixed in 11824
< jonasschnelli> reindex in master is currently not usable
< provoostenator> promag: I don't know if it caused IBD, but it certain started an IBD after this happened
< wumpus> apparently the validation queue fills memory
< provoostenator> So only a re-index should cause this crash, right? Not the new IBD? I might just let this IBD finish and then do another re-index to see if it crashes, before cherry-picking that fix.
< promag> guess I'll check 11824 too
< gmaxwell> it would effect IBD too
< luke-jr> depending on bandwidth?
< jonasschnelli> I haven't looked at the code of 11824 to be honest...
< cfields> meeting?
< wumpus> #startmeeting
< lightningbot> Meeting started Thu Dec 21 19:01:13 2017 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
< lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
< provoostenator> gmaxwell: ok, that's "great"; saves me time to reproduce. So far it's only using 1.1 GB of RAM in ~2013...
< wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag
< jonasschnelli> hi
< Chris_Stewart_5> hello
< provoostenator> hi
< * BlueMatt> is betting on low attendance
< promag> hi o/
< kanzure> hi.
< luke-jr> why?
< gmaxwell> people travling for holidays
< luke-jr> oh
< sipa> oh, look, a meeting
< provoostenator> Without taking their laptop? Lame.
< promag> or buying gifts
< wumpus> seems there are enough people to warrant a meeting
< cfields> hi
< wumpus> but yes holidays is a good topic, I won't be there for next week and the week after that meeting
< promag> on my side just want to let know that I've made some progress on the activity feature, hope to submit PR next week
< jonasschnelli> topics?
< jtimon> hi
< wumpus> segwit wallet merge? please? :)
< * sipa> is in favor
< jonasschnelli> Yes. Please
< gmaxwell> plz
< jonasschnelli> xmas present
< sipa> but also please review first
< wumpus> #topic segwit wallet
< wumpus> what is left to do?
< BlueMatt> I think it needs more review still? I havent checked since my last round but there were a number of papercuts that needed fixing
< sipa> ryanofsky made a nice list of todos in a comment (all for other PRs ino)
< wumpus> yes, I mean for this PR
< sipa> BlueMatt: i've responded, please review
< BlueMatt> yes, will try to get back to it this week
< wumpus> there's plenty of things that can be done after merging it
< sipa> cool
< gmaxwell> sipa: did you look into that multisig still using p2sh thing we discussed?
< sipa> gmaxwell: yes, fixed, and added tests
< BlueMatt> oh, yes, it def needed more tests
< sipa> BlueMatt: also addressed, i think
< BlueMatt> kool
< sipa> ah yes, there are no address_type parsing tests yet
< sipa> i'll add those
< wumpus> great
< wumpus> any other topics?
< jonasschnelli> gitian build are broken
< jonasschnelli> *builds
< BlueMatt> review 0.16 stuff!
< jonasschnelli> (I think its not a local issue)
< BlueMatt> (not just segwit wallet)
< wumpus> oh no not again
< cfields> mm, will have a look
< jonasschnelli> I think its one for cfields
< cfields> jonasschnelli: thanks for reporting
< cfields> jonasschnelli: oh, i see
< cfields> it's missing -static-libstdc++ for some reason
< Chris_Stewart_5> is there still a memory leak on master?
< wumpus> oh the symbols check fails
< jonasschnelli> Chris_Stewart_5: yes see 11824
< gmaxwell> Chris_Stewart_5: it's not a memory leak, but yes its still there.
< sipa> Chris_Stewart_5: not a leak, but memory is growing unboundedly
< wumpus> yes, it shouldn't dynamically import libstdc++
< cfields> yea, the stdlib is just linked shared. Will get to the bottom of it.
< wumpus> cfields: thanks
< cfields> nice to see that got caught!
< jonasschnelli> it's broken since dec. 1st if that helps track down the relevant commit
< wumpus> two PRs were merged that day, #11804 and #11337
< gribble> https://github.com/bitcoin/bitcoin/issues/11804 | [docs] Fixed outdated link with archive.is by TimothyShimmin · Pull Request #11804 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/11337 | Fix code constness in CBlockIndex::GetAncestor() overloads by danra · Pull Request #11337 · bitcoin/bitcoin · GitHub
< cfields> thanks
< jonasschnelli> Build 2017-12-01 00:00:10 UTC failed... but build 2017-11-30 00:00:10 UTC succeeded
< wumpus> ok many more things were merged the day before that
< sipa> dec 1st in what tz?
< jonasschnelli> 2017-12-01 00:00:10 UTC
< jonasschnelli> Commit must be between 2017-11-30 00:00:10 UTC and 2017-12-01 00:00:10 UTC
< jonasschnelli> But maybe other topics first?
< jonasschnelli> anything to change at / mention from the HP list https://github.com/bitcoin/bitcoin/projects/8?
< wumpus> there's 10 things on there already, I don't think it will help to add more
< jtimon> BlueMatt: what is "0.16 stuff"?
< wumpus> only so much that can be 'high priority' at once
< wumpus> and what we really want is segwit wallet anyway
< sipa> prioritize ALL THE THINGS!
< wumpus> hehe
< jtimon> does everything in there need to be merged before forking 0.16 ?
< wumpus> jtimon: no
< wumpus> just segwit wallet + the bugfixes
< wumpus> all features are optional
< wumpus> I think we get this question every week
< jonasschnelli> Maybe a short discussion about fallbackfee / RBF defaults?
< wumpus> #topic fallbackfee / RBF defaults
< jtimon> I guess the 0.16 tag confuses me
< jonasschnelli> There is a PR to split walletrbf between RPC and GUI #11605 (I don't think we should do that)
< gribble> https://github.com/bitcoin/bitcoin/issues/11605 | [Wallet] Enable RBF by default in QT by Sjors · Pull Request #11605 · bitcoin/bitcoin · GitHub
< wumpus> RBF should probably become default, I don't think there's any way around that
< jonasschnelli> Also,.. there are two PRs do disable the fallback fee (one on mainnet, one entierly)
< gmaxwell> RBF should probably be default now, electrum does it, without any great consequence.
< instagibbs> wumpus, ACK
< jonasschnelli> Okay. I agree. So lets enable it by default.
< promag> +1
< gmaxwell> jonasschnelli: if fallback fee is disabled what happens if it would otherwise use it?
< jonasschnelli> provoostenator: can you transform your PR toward that: 11605?
< wumpus> not sure what the rationale is to enable it only by default for qt?
< provoostenator> Well, I'm not so sure if that's a good idea for the RPC, which is used by different applicaitons than e.g. electrum.
< jonasschnelli> gmaxwell: reject
< jonasschnelli> Disabled fallback fee = JSON throw or QT reject
< gmaxwell> jonasschnelli: I mean, does the user get prompted to enter a fee?
< jonasschnelli> No
< wumpus> but let's merge enabling it for the gui first at least that's a step forward
< jonasschnelli> No manual fee entering is provoked
< provoostenator> Electrum is used afaik person to person, not for broadcasting lots of stuff through an automated process.
< gmaxwell> so the software just becomes unusable?
< luke-jr> ^
< wumpus> jonasschnelli: but it's possible to select a custom fee right?
< wumpus> jonasschnelli: the GUI has a checkbox for that
< jonasschnelli> wumpus: Yes. Always...
< luke-jr> hmm
< wumpus> so no, the software doesn't become unusable
< gmaxwell> What about in the rpc/cli?
< jonasschnelli> wumpus: but if you don't and fee estimations are not ready,.. rject!
< jonasschnelli> gmaxwell: reject if you haven't set fallbackfee or paytxfee and feeest is not ready
< jonasschnelli> fallback fees are the worst!
< jonasschnelli> (UX)
< gmaxwell> Is there are rpc way to see a fallback fee?
< jonasschnelli> Especially if its default enabled and the user don't get informed it was used!
< sipa> feeest!
< jonasschnelli> gmaxwell: I don't think so
< gmaxwell> jonasschnelli: in the gui does the failure message tell you that you can set a fee?
< provoostenator> See this comment and the IRC discussion it points back to: https://github.com/bitcoin/bitcoin/pull/11605#issuecomment-352056518 (also cc bluematt)
< jonasschnelli> If we disable it by default, you wonldn't
< jonasschnelli> gmaxwell: no.. but I guess I should add that
< jonasschnelli> gmaxwell: it says you should wait for the feeest to be ready (a couple of blocks)
< gmaxwell> We should probably do this but we need to make the matching fixes so that the software isn't unusuable for the first day of running it or whatever. e.g. by telling you that you can manually set a fee and providing facilities to do that.
< gmaxwell> probably need to add a trivial rpc to set the fallback fee.
< jtimon> ack on RBF by default. I would also remove -mempoolreplacement and always do replacements but that's likely to be more controversial
< instagibbs> jtimon, luke-jr says miners actually use this option
< jonasschnelli> gmaxwell: I agree.
< wumpus> it's still settable on the command line at least
< gmaxwell> since paytxfee doesn't really do the right thing there.
< sipa> it's probably best to look at the actual UI, which i haven't :)
< jonasschnelli> We could even fetch estimations from bitcoincore.org (*hide* *duck* *runaway")
< wumpus> not sure it'd make sense as a RPC, as there's already paytxfee
< zelest> sorry for asking, but can anyone just grab whatever bug in the repo and fix it.. and submit a pull request? :o
< instagibbs> jonasschnelli, or from one of my two suspended twitter bots :P
< jtimon> instagibbs: yeah, I remember that, just repeating my opinion about it
< jonasschnelli> heh
< gmaxwell> wumpus: IIRC paytxfee overrides the estimator, rather than being overridden by the estimator.
< sipa> indeed
< wumpus> zelest: no, you need triple-signed off documents from the central committee first
< wumpus> zelest: (yes, everyone can just do that :-)
< gmaxwell> wumpus: so if you achieve your fallback by setting paytxfee then you'll end up underpaying even when your estimator knows better.
< zelest> Ah ;-)
< jonasschnelli> The sendto commands have really no clever way to set the txfee
< zelest> Mayhaps this is what I should spend/waste my free time on...
< gmaxwell> in any case, I can write the rpc to set the fallback fee, it would be trivial.
< jtimon> what is the fallback fee?
< meshcollider> hi, sorry I'm late
< gmaxwell> and then the errors when you hit that case should just tell you to set the fee.
< wumpus> gmaxwell: I think it'd be slightly confusing to add yet another fee setting RPC, but okay
< jonasschnelli> jtimon: its the feerate used when no estimations are available
< wumpus> another global used in fee determination
< jtimon> jonasschnelli: thanks
< wumpus> zelest: that'd be awesome
< jonasschnelli> I agree with gmaxwell that we need a good UX for the first "day" when fee estimations are not available
< gmaxwell> wumpus: Agreed, but I don't see around it, telling lots of people to use paytxfee is probably a bad situation.
< promag> so if fee estimation is not available, rpc funding should fail?
< gmaxwell> jonasschnelli: not just first day, every day, because of resource usage lots of people don't leave their nodes running.
< jonasschnelli> promag: Yes
< wumpus> gmaxwell: agree...
< jonasschnelli> gmaxwell: indeed.
< gmaxwell> promag: unless you've set a fallback feerate.
< wumpus> gmaxwell: would almost wish that there'd be something like 'paytxfeepriority' but not that that would be any easier to understand :-)
< promag> jonasschnelli: and in the UI too? or prompt for custom?
< jtimon> gmaxwell: yeah, or people just shut down their computers when they go to sleep
< jonasschnelli> So either the user enters the current feerates into RPC/GUI or we load it from somewhere
< wumpus> gmaxwell: (e.g. whether it'd override the fee estimator or not)
< promag> gmaxwell: but we want to remove that?
< gmaxwell> promag: no we want to eliminate there being a default one.
< gmaxwell> The estimator is always going to take time to start working. And it's not reasonable to force people to not transact until they have estimates.
< gmaxwell> But a static compiled in fallback is dumb.
< wumpus> promag: the problem is that fees are too variable now to hardcode any sensible default in the software
< promag> gmaxwell: ok, but once defined it can be outdated very fast
< luke-jr> ideally we could pre-sign multiple fee rates and send the higher ones once we have an estimate
< promag> luke-jr: only with rbf signaled
< gmaxwell> RBFing has complications, unfortunately.
< promag> ?
< jonasschnelli> luke-jr: long term.... yes. Maybe. But complicated to implement
< luke-jr> well, require RBF when there's no estimates?
< jonasschnelli> luke-jr: I had this in a PR
< gmaxwell> You can't just assume that RBF will work unfortunately.
< gmaxwell> Because of the pinning problem.
< jonasschnelli> But then morocs asked for just disabling fallback.. which makes sense
< wumpus> RBF is orthogonal imo
< luke-jr> even without RBF, it would probably work if the problem is fee rate too low
< instagibbs> gmaxwell, "pinning" meaning someone spending on top?
< instagibbs> I like the name if so
< luke-jr> if nobody has the conflicting tx in their mempool, it's not even considered a replacement
< wumpus> yes, we also want RBF by default, but that doesn't change the fallback fee situation
< gmaxwell> instagibbs: with a large txn, yes.
< wumpus> certainly not for RPC
< * luke-jr> wonders how pinning affects mempool eviction of low feerate
< jonasschnelli> I think the fallback fee problem is solveble in the GUI,... but not sure about RPC layer,... we would have to add feerate parameters to the send commands
< gmaxwell> in any case, ACK removing fallback fee but we must be mindful that for a lot of users the no-estimate case will be very frequent so the workflow has to be good: which means clear messages and a straight forward way to set a fee.
< gmaxwell> jonasschnelli: RPC I think is fine, setfallbackfee ... and the error returned on send tells you that you have to use that.
< wumpus> yeah...
< jonasschnelli> I think gmaxwell idea with the setfallbackfee RPC makes most sense..
< jtimon> yeah I think RBF is orthogonal too. let's just make it default independently of the estimation issue
< wumpus> jtimon: agree
< gmaxwell> then for cli users the workflow is basically like the GUI one, and for businesses they might pull the fallback off another node, or an estimation site.
< wumpus> right
< gmaxwell> (automatically)
< jtimon> don't we have an estimator purely based on past blocks with no knowledge of the mempool?
< instagibbs> jtimon, that's the only way we do it
< jtimon> mhm, then why do you need to be up for some time to have estimates?
< gmaxwell> instagibbs: not quite we watch the dwell time of transactions that confirm.
< gmaxwell> it needs both
< promag> how about something to help/speedup fee estimation?
< instagibbs> mistook the question
< wumpus> using only blocks would be easy to manipulate
< promag> like feeding fee estimation with something.. don't know the internals
< gmaxwell> using blocks exclusively is exploitable, unfortunately. Though there are limited ways which it could help.
< gmaxwell> e.g. you could look at the minimum fee confirmed over many blocks, but sadly it would be misleadingly low because of OOB payments and such.
< jtimon> perhaps we could have a non-mempool estimator that is used by default until there's data for the mempool based one
< wumpus> adding a new estimator is not going to go for 0.16 at least
< wumpus> in the future, who knows
< gmaxwell> also it's not likely to be invented by folks who don't know the current one and history. :)
< jtimon> say, something stupid like max (the minimum feerate in each block for the last 144 blocks)
< gmaxwell> jtimon: yes, maybe... under the bet that there is at least one block with no OOB fees. You'd have to exclude blocks that weren't full.
< sipa> or bounding estimates by the feerate at 1 MB vbyte from the top of the mempool
< aj> jtimon: aggregate all the fee rates over a bunch of blocks and choose a fee that's higher than ~10% or 20% of them
< gmaxwell> sipa: without mempool sync that isn't fast.
< jtimon> gmaxwell: right, 100 empty blocks would screw you
< sipa> ah yes
< gmaxwell> but indeed, once we have some kind of mempool sync we could do things like that.
< wumpus> 100 empty blocks would screw everyone
< jtimon> is there a way to persist the mempool while running instead of only when shutting down?
< instagibbs> jtimon, i think there is an rpc for that
< gmaxwell> jtimon: just go back one day of blocks, counting only blocks at least 0.95*MAX_WEIGHT in size, and check the maximum of their minimum feerates. Would be interesting to see what that yields right now. It _might_ be useful.
< wumpus> savemempool RPC
< jtimon> gmaxwell: yeah, that sounds less stupid than what I proposed, and still isn't hard
< gmaxwell> or instead of their minimum feerate, their Nth percentile feerate.
< jtimon> I mean, still probably not for 0.16, but not hard to code I think
< gmaxwell> right
< wumpus> any other topics?
< gmaxwell> e.g. what feerate is less than 95% of the txn in the block... gives it room to ignore 5% priority txn.
< jtimon> wumpus: instagibbs thank you! and sorry, the question is kind of unrelated anyway
< wumpus> yes that'd make sense
< provoostenator> I'm still reluctant about enabling RBF for RPC. Without having a long disucssion here, is there a list of known large services that use Bitcoin Core RPC to broadcast transactions? I'd like to know their take on this.
< gmaxwell> provoostenator: an RPC using service can at least read the release note and simply turn it off again.
< aj> i did sextile graphs of fee rates aggregated over 24 hours the other day, http://azure.erisian.com.au/~aj/tmp/graphs/fpvb-trends.png and http://azure.erisian.com.au/~aj/tmp/graphs/segwit-comparison.png i think they track pretty well
< wumpus> promag: let's first enable it for the gui, at least that's uncontroversial
< wumpus> provoostenator*
< instagibbs> 15 minutes left
< provoostenator> It's equally trivial for an RPC user to just set walletrbf=1 if they want to use this. The only problem seems to be code complexity.
< wumpus> I think having a too long defaults discussion is not productive, if anyone is opposed to enabling it for RPC with good reason then we shouldn't do that
< gmaxwell> rpc can wait, we can release note a reminder that you can turn it on for cli/rpc use.
< promag> wumpus: ok
< wumpus> people using RPC will usually have a better idea of available options anyhow
< provoostenator> gmaxwell: I already put that in the release note in my PR
< instagibbs> perhaps with a warning that future versions may change this
< provoostenator> (sort of)
< jonasschnelli> I don't think splitting walletrbf between GUI and RPC makes sense in the long run
< wumpus> yes, defaults are subject to change
< gmaxwell> sipa: so what do you think long term trying to use that block percentile as a maximum fee for a fast estimate, and then use a synced mempool to potentially reduce the number. I think that escapes the primary manipulation concerns we have.
< wumpus> jonasschnelli: on the long run it makes no sense
< provoostenator> I think it does make sense to treat GUI and RPC different
< wumpus> jonasschnelli: it'd be a temporary artifact
< provoostenator> Very different use cases.
< gmaxwell> just get rid of the setting for the GUI.
< provoostenator> It's just a code maintenance thing why we shouldn't make them too different.
< sipa> gmaxwell: if you're worried about OOB paymemts, shouldn't you also be concerned about OOB refunds?
< jonasschnelli> What speak again just enabling -walletrbf GUI/RPC by default?
< jonasschnelli> *against
< wumpus> gmaxwell: I think that's a good point too - why would the GUI need a setting for the default?
< jtimon> i think rbf active is the most sensible default for both rpc and gui
< gmaxwell> sipa: OOB refunds don't currently appear to be a real thing.
< wumpus> it has a checkbox if you really want to disable it
< provoostenator> gmaxwell: yes, I can kill the setting for the GUI, especially because I renamed the RPC setting to -rpcwalletrbf
< gmaxwell> wumpus: yep thats just what I was typing, that it has a checkbox.
< jonasschnelli> wumpus: people are lazy to read checkboxes? :)
< gmaxwell> then they'll certantly not read a setting. :)
< wumpus> jonasschnelli: well the default is sensible, lazy people won't want to override it!
< wumpus> gmaxwell: indeed
< sipa> gmaxwell: for now.
< wumpus> +1 on not having the GUI default setting
< jonasschnelli> Set walletrbf=1 by default,.. switch the checkbox in the GUI (to disable RBF instead of enable)
< jtimon> why not leave the checkbox as meaning enabled but simply have it checked by default?
< provoostenator> Rather than renaming -walletrbf to -rpcwalletrbf, I can also make it clear that -walletrbf won't impact the GUI.
< wumpus> provoostenator: yes, I'd prefer that
< gmaxwell> +1
< wumpus> provoostenator: I'd really prefer not to have a rename/deprecate cycle there
< wumpus> provoostenator: (as I've expressed before)
< gmaxwell> better to not break things for people who are already walletrbf=1 if we can avoid it.
< wumpus> yeah...
< * jonasschnelli> unsure
< wumpus> just document the option instead of renaming it
< jonasschnelli> Wait...yes. This makes sense
< provoostenator> Yeah, the deprecation stuff was a bit overkill.
< gmaxwell> just adjust the description, make the gui not read that setting for the checkbox default.
< wumpus> ok, cool!
< wumpus> seems we agree
< jonasschnelli> ack
< meshcollider> yep sounds good
< gmaxwell> if users complain that they can't set a different default we'll deal with that then, but I don't expect it.
< luke-jr> why not just let -walletrbf continue to work, but have the new defaults only affect when it's unset?
< wumpus> luke-jr: it will continue to work
< wumpus> for the RPC
< luke-jr> wumpus: I mean for both
< wumpus> any other topics?
< wumpus> luke-jr: using the same setting with different default in different places was *ugly*
< provoostenator> ^
< provoostenator> That was actually what I did in the first version, but it's confusing.
< gmaxwell> the 'implementation defined behavior when not set' should be used very sparingly.
< provoostenator> Making it clear that -walletrbf has no bearing on the GUI (including it's default) seems better.
< luke-jr> IMO the ugliness only comes from having two defaults, not from having a common setting
< wumpus> yes, that used to be the case, but it's no way to handle options imo, and won't be ocmpatible when we introduce an actual options registration/parsing system
< provoostenator> I'll push that after the meeting.
< jonasschnelli> Thanks provoostenator!
< gmaxwell> In general we should probably not have config file setting for GUI checkboxes that stare the user in the face.
< provoostenator> Remind me not to make changes to defaults too often :-)
< gmaxwell> if the GUI wants a persistant default it should be changable from the GUI.
< meshcollider> Which I am trying to work on at the moment :)
< luke-jr> gmaxwell: via rwconf ;)
< jonasschnelli> provoostenator: hah... these are the worst. :)
< gmaxwell> But hopefully we won't need a changable persistant default for this.
< wumpus> right
< jtimon> the rbf checkbox doesn't appear with every tx?
< provoostenator> luke-jr: rwconf?
< wumpus> jtimon: isn't it always there?
< meshcollider> jtimon: what?
< gmaxwell> provoostenator: code to allow the conf file to be rewritten by setting changes at runtime.
< luke-jr> provoostenator: lets the GUI change config file settings
< wumpus> please, no scope creep
< gmaxwell> that was just a tangent.
< gmaxwell> not scope creep. :)
< provoostenator> Ah, so we don't have this "here's a setting, but if you use -blah it's overridden, unless you also have bitcoin.conf, unless you have another one" stuff?
< gmaxwell> I was just expressing the principle that controlling GUI defaults via non-gui accessable settings is just not very good.
< jtimon> sorry, I should look at the gui. my assumption was that for every tx a checkbox would say "allow rbf" and that is unchecked by default and we're moving to checked by default
< wumpus> it would add another bitcoin.conf, bitcoin_rw.conf, which can be written by the software itself
< provoostenator> gmaxwell: indeed, also not very easy to launch QT with flags on OSX.
< gmaxwell> I know, we could save the users settings ON THE BLOCKCHAIN
< meshcollider> jtimon: yep that's basically what this is doing
< wumpus> hehehe, settings delta chain
< sipa> gmaxwell: woah!
< meshcollider> lol
< * cfields> founds chainsettingsalytics
< wumpus> gmaxwell: I"m surprised that no *coin project commits git diffs to the blockchain yet
< jtimon> meshcollider: then I don't understand the -walletrbf discussion, but it's fine
< gmaxwell> plus the related costs will make them never get changed, and since they're never changed we could remove the implementation of the choices... less UI to maintain!
< provoostenator> Some people use opentimestamps for that
< provoostenator> The git integration thing.
< achow101> wumpus: there's definitely a Core commit diff somewhere on the blockchain
< meshcollider> jtimon: the walletrbf discussion is about whether that parameter should affect the GUI default or only the RPC I believe
< wumpus> or even better, just commit javascript code for the GUI to the block chain
< wumpus> :')
< achow101> I found it once, but don't know where it is
< wumpus> achow101: oh! which one?
< wumpus> it'd certainly create incentive to make patches small
< achow101> wumpus: I don't quite remember
< jtimon> meshcollider: right, we're moving to not affecting it seems, which is what makes most sense to me, just what I described with no relation to -walletrbf. so it's fine.
< meshcollider> wumpus: heh why just the GUI, entire new versions of core could be downloaded directly from the blockchain too!
< wumpus> no one would submit a diff-all-over-the-place PR if it costs >300 sat/byte
< wumpus> meshcollider: yes of course, updates to the consensus algo too :')
< sipa> wumpus: do you get a refund for deleted lines?
< wumpus> sipa: yes!
< provoostenator> Unless they want to show off their wealth as an offering...
< meshcollider> jtimon: yep exactly
< jtimon> meshcollider: that would be great to make sure everyone upgrades before a hf :p
< sipa> wumpus: brb, deleting all the tests
< wumpus> sipa: but only if accepted :-)
< luke-jr> wumpus: you're going to give my children nightmares
< sipa> oh.
< sipa> DONG
< wumpus> #endmeeting
< lightningbot> Meeting ended Thu Dec 21 20:00:08 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< wumpus> luke-jr: uh oh
< jonasschnelli> cfields: chainsettingsalytics?
< achow101> I forgot there was a meeting today..
< meshcollider> achow101: at least you made it for the end ;)
< cfields> jonasschnelli: for tracking and selling on-chain user settings, of course
< jtimon> -forceautoupgradeonversionsolderthanthisoption
< cfields> jonasschnelli: you happen to have git revisions for good/broken gitian builds?
< sipa> achow101: you should make the blockchain remind you
< achow101> sipa: lol
< jonasschnelli> cfields: let me check
< cfields> thanks
< jonasschnelli> Good: 38d31f95
< jtimon> sipa: can you even program a smart contract alarm without turing completeness? :p
< jonasschnelli> Broken: 13e31dd6
< jonasschnelli> Happy bisect
< achow101> in other unrelated news, I finally got around to simulating the branch and bound coin selection stuff
< cfields> perfect! thanks :)
< jtimon> alright, I'm going to go try that savemempool rpc...
< jonasschnelli> jtimon: why?
< gmaxwell> achow101: and?
< wumpus> FYI you can only save to the default file, it doesn't take a filename argument
< achow101> gmaxwell: it's taking a long time
< achow101> I'm looking at some results right now and I'll add a comment to the PR with them
< achow101> gmaxwell: AFAICT, it performs on par with the current coin selection behavior but I think that might be because BnB was only used <3% of the time with the dataset and parameters I just tried
< spence> Is there a roadmap for integrating segwit better into Core? Gui, etc...
< gmaxwell> it'll be in the next release.
< wumpus> #11403
< gribble> https://github.com/bitcoin/bitcoin/issues/11403 | SegWit wallet support by sipa · Pull Request #11403 · bitcoin/bitcoin · GitHub
< contrapumpkin> is there a way I can feed bitcoin core an HD wallet xpub key and get it to monitor the balance without holding the private keys?
< contrapumpkin> oh sorry, wrong channel
< provoostenator> On a meta note. Looks like I can keep helping out for a while without running out food :-) https://blog.blockchain.com/2017/12/21/first-open-source-developer/
< achow101> provoostenator: congrats!
< jtimon> jonasschnelli: I'm working on an explorer, and every time I deploy ir restarts the daemon's container, but it doesn't wait for the mempool dump, so I lose the whole mempool every time. I'll fix it with process that periodically calls savemempool
< jonasschnelli> ah
< sipa> provoostenator: congratulations
< sipa> very happy to see that
< jonasschnelli> provoostenator: Oh. Nice! Well done.
< wumpus> provoostenator: great!
< jimpo> Just out of curiousity, why is much of the secp256k1 code in _impl.h header files instead of .c files?
< wumpus> jimpo: optimization, scope for inlining, as well as making it easy to add secp256k1 to a project by just adding one .c file
< jtimon> provoostenator: cool, great news
< meshcollider> 🎉
< cfields> provoostenator: congrats!
< zelest> how much of self-torture will I have to live through to get bitcoin running on OpenBSD? :)
< provoostenator> Thanks! Also, updated #11605 (but do check carefully, it's a bit late here...)
< gribble> https://github.com/bitcoin/bitcoin/issues/11605 | [Wallet] Enable RBF by default in QT by Sjors · Pull Request #11605 · bitcoin/bitcoin · GitHub
< cfields> zelest: there are freshly updated docs for that
< cfields> wumpus self-tortured himself so you wouldn't have to
< wumpus> cfields: well we didn't update the docs yet for openbsd 6.2, just the bdb building tool
< wumpus> although the current instructions should work
< cfields> oh, i thought that was all that was needed
< wumpus> the docs could be really simplified because openbsd 6.2 includes clang, it currently tells to install either clang or a newer gcc
< wumpus> openbsd 6.2's built-in compiler can build bitcoin core :)
< cfields> ah right
< cfields> nice
< cfields> wonder what obsd would've done without clang.
< wumpus> dunno either, could hardly have sticked with gcc 4.2 forever
< wumpus> zelest: so basically: append CC=cc CXX=c++ to the contrib/install_db4.sh and configure commands
< wumpus> so that it will use clang and not the gcc 4.2, which for some reason is still installed
< wumpus> (or maybe that's because my openbsd box was upgraded from $OLD_VERSION)
< cfields> it switched your default cc/c++ after an upgrade?
< wumpus> it didn't use to have cc/c++, just gcc/g++
< cfields> ah
< wumpus> and by default, most build systems will pick gcc over cc
< cfields> yikes, though. buildsystems do all kinds of combinations of checks for cc/gcc
< cfields> stupid cmake, for example, uses cc/c++
< wumpus> I should try installing an openbsd 6.2 from scratch and see if it has only clang, that'd make more sense
< wumpus> g++ and c++ have an incompatible abi so ou're right that it cause all kind of pain
< cfields> or gcc -> cc
< cfields> that's what macos does
< wumpus> yes the same command line interface anyway
< cfields> 10% unrelated: gcc is able to build in a chroot with only binutils/gmake/previous gcc/libc/kernel headers.
< cfields> cmake, however, is the first to require a whole mess of libs :(
< wumpus> what do we need cmake for?
< wumpus> it's mostly used for graphical stuff right?
< cfields> clang
< wumpus> oh
< cfields> so no avoiding it as part of the early build process, i'm afraid
< wumpus> clang is cmake only now?
< wumpus> Ithought it had an autoconf based build as well
< cfields> not sure if it is for 5.0, but if not, the autotools is heavily deprecated
< wumpus> ah yes you're right
< wumpus> I see I also switched my clang configuration script to cmake at some point, apparently without remembering
< cfields> heh
< cfields> well it's probably not all that different if you're using all system paths
< wumpus> cmake -DLLVM_TOOL_COMPILER_RT_BUILD:BOOL=ON -DBUILD_SHARED_LIBS=ON -DCMAKE_INSTALL_PREFIX=/opt/clang${VER} -DLLVM_BINUTILS_INCDIR=/usr/include -DCMAKE_BUILD_TYPE=RelWithDebInfo ../llvm
< wumpus> well it's not as bad as some cross-compiles...
< zelest> wumpus, Ah, awesome! thanks :)
< zelest> wumpus, boo! the compile blew up P
< zelest> :P
< wumpus> with what?
< wumpus> zelest: what version are you building?
< wumpus> and you did do contrib/install_db4.sh CC=cc CXX=c++ ?
< wumpus> this happens when dbc++ was built with a different compiler than bitcoind
< zelest> wumpus, 0.15.1 and yeah.. and no, I used CC=egcc CXX=eg++ CPP=ecpp :o
< sipa> what version of gcc is that?
< zelest> 4.2.1
< zelest> i did however run ./configure with CC=cc and CXX=c++
< sipa> that won't work
< sipa> you need gcc 4.7
< * zelest> tries what wumpus suggested and runs llvm for both dbc++ and bitcoind
< wumpus> zelest: 0.15.1 doesn't have the necessary patch, unfortunately that install_db4.sh ignores arguments
< zelest> oh
< wumpus> this was fixed on master yesterday with #11945
< gribble> https://github.com/bitcoin/bitcoin/issues/11945 | Improve BSD compatibility of contrib/install_db4.sh by laanwj · Pull Request #11945 · bitcoin/bitcoin · GitHub
< wumpus> you could probably just copy the file from there
< zelest> wumpus, can I compile master? (i saw build:failed on there, hence me picking 0.15.1)
< zelest> ah
< wumpus> sure, you can build master
< zelest> oh yeah, the link in build-openbsd.md is wrong btw
< zelest> it 404s
< wumpus> but thanks for reminding me it needs a backport label
< wumpus> which link?
< wumpus> anyhow that's likely fixed on master too
< zelest> https://github.com/bitcoin/bitcoin/blob/master/doc/build-openbsd.md the "the installation script included in contrib/" under Building Berkley DB
< zelest> BerkeleyDB*
< bitcoin-git> [bitcoin] laudaa opened pull request #11976: [Doc] Fix link to installation script (master...master) https://github.com/bitcoin/bitcoin/pull/11976
< Lauda> Sorry, we missed that one
< wumpus> apparently Lauda in #11960 fixed that in all files except build-openbsd.md in
< gribble> https://github.com/bitcoin/bitcoin/issues/11960 | [Doc] Fix link to installation script by laudaa · Pull Request #11960 · bitcoin/bitcoin · GitHub
< zelest> no love for OpenBSD :(
< Emcy> !topic
< gribble> Bitcoin Core development discussion and commit log | This is the channel for developing Bitcoin Core. Feel free to watch, but please take commentary and usage questions to #bitcoin | Channel logs: https://botbot.me/freenode/bitcoin-core-dev, http://www.erisian.com.au/bitcoin-core-dev/
< Emcy> when are the meetings? weekly?
< Lauda> Yes
< wumpus> 19:00-20:00 UTC Thursdays, you just missed one
< Emcy> ok
< zelest> wumpus, yeah, failed even with those CC flags
< zelest> oh well
< Emcy> 0.16 i branching soon. nice.
< wumpus> zelest: so you used the new version of install_db4.sh?
< zelest> yeah
< Emcy> and segwit gui is getting merged
< wumpus> zelest: ok, no clue in that case, it worked for me
< zelest> wumpus, i'm using -current though, might affecting it.. *shrugs*
< zelest> also had it running back in 6.1
< zelest> wumpus, thanks for all the help though :)
< wumpus> zelest: I don't think that should matter - what matters is that both dbc++ and bitcoind are compiled with the same c and c++ compiler
< wumpus> zelest: if not, you get linker errors, due to ABI mismatch
< zelest> hmms..
< Guest99499> How can 4 btc come out of my wallet and I did not send anything
< Guest99499> It was several different transactions with the same address going out is it rerouting
< zelest> wumpus, i will give it another go tomorrow and start out with a fresh copy of both source trees.. need to hit the shower before i hit the sack. :)
< Guest99499> Will it come back to my Wallet
< sipa> Guest99499: #bitcoin
< wumpus> zelest: yes it might be that something left behind from earlier builds; also it's a good idea to pipe the build output to a file to see if the right compiler gets used
< sipa> Guest99499: or https://bitcoin.stackexchange.com
< zelest> wumpus, ah, true
< Guest99499> So there's nothing to worry about it will come back to my wallet
< sipa> Guest99499: not here.
< Guest99499> How can I get my missing btc back in my wallet Who authorized to take it out
< Guest99499> Has anybody else had the same problem
< wumpus> Guest99499: #bitcoin please
< sipa> Guest99499: last warning, not here. this channel is for development, not support
< talha_> hi
< bitcoin-git> [bitcoin] theuni opened pull request #11981: Fix gitian build after libzmq bump (master...fix-gitian-build) https://github.com/bitcoin/bitcoin/pull/11981
< talha_> any fork expert here?
< wumpus> that's off topic here
< talha_> whats the topic here?
< zelest> wumpus, heh, who needs sleep.. :D removed both trees and started over. seems to be compiling now.. \o/
< meshcollider> talha_: topic here is development of bitcoin core, not any other software or forks