1 2017-12-21 00:07:33	0|valentinewallace|\query jonasschnelli Hi, you commented on one of my PRs yesterday. Are you available for a question?
  2 2017-12-21 00:17:04	0|bitcoin-git|[13bitcoin] 15fanquake closed pull request #11921: Fixing env variables/arguments in OpenBSD build instructions (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/11921
  3 2017-12-21 01:08:32	0|bitcoin-git|[13bitcoin] 15fanquake closed pull request #11967: Add script to test the dns seeds (06master...062017/12/seed_test) 02https://github.com/bitcoin/bitcoin/pull/11967
  4 2017-12-21 01:13:29	0|bigboytimc|hey got a quick code question for you guys
  5 2017-12-21 01:19:33	0|meshcollider|bigboytimc: "don't ask to ask, just ask" - pieter ;)
  6 2017-12-21 01:20:27	0|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
  7 2017-12-21 01:20:51	0|bigboytimc|I figured it'd be in primitives with block.h, but there's nothing there that looks like it
  8 2017-12-21 01:21:01	0|bigboytimc|so I guess I'm just wondering where the extended block is in the code
  9 2017-12-21 01:21:08	0|echeveria|'extended block'?
 10 2017-12-21 01:21:23	0|meshcollider|what do you mean by an extended block, the block structure hasn't really changed
 11 2017-12-21 01:22:05	0|bigboytimc|doesn't segwit include an additional structure that isn't on the blockchain?
 12 2017-12-21 01:22:11	0|gmaxwell|no.
 13 2017-12-21 01:22:28	0|bigboytimc|like the change involved moving some parts of the block into a separate structure to add more transactions?
 14 2017-12-21 01:22:34	0|gmaxwell|the blocks are totally unchanged.
 15 2017-12-21 01:22:38	0|gmaxwell|bigboytimc: nope.
 16 2017-12-21 01:23:04	0|gmaxwell|There is a new field in transactions, called the witness field, which is after the outputs and before the nlocktime.
 17 2017-12-21 01:23:28	0|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
 18 2017-12-21 01:23:29	0|photonclock_|How well is Bitcoin holding up to the mempool overflow? Is everything working as expected?
 19 2017-12-21 01:23:45	0|gmaxwell|New nodes know how to strip out this witness field from the transactions befor passing them along to old unupgraded nodes.
 20 2017-12-21 01:24:03	0|gmaxwell|photonclock_: yup. things are working very well.
 21 2017-12-21 01:24:06	0|bigboytimc|interesting, I guess reading about segwit made it sound like they took the witness stuff and added it to a different structure
 22 2017-12-21 01:24:17	0|gmaxwell|bigboytimc: there is a lot of misinformation out there.
 23 2017-12-21 01:24:55	0|photonclock_|gmax I know this is not the room for general Bitcoin chat - can I chat you up on the Bitcoin channel?
 24 2017-12-21 01:25:23	0|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/
 25 2017-12-21 01:26:05	0|bigboytimc|thanks!
 26 2017-12-21 02:07:51	0|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
 27 2017-12-21 02:09:56	0|meshcollider|or I should just use UniValue for the globals
 28 2017-12-21 02:10:41	0|instagibbs|did someone say command line registration of args? meshcollider pointer to PR/issue?
 29 2017-12-21 02:11:58	0|meshcollider|instagibbs: working on it atm, was discussed here: https://botbot.me/freenode/bitcoin-core-dev/2017-12-14/?msg=94674799&page=9
 30 2017-12-21 02:12:21	0|meshcollider|issues 11819 and 1044 are directly related
 31 2017-12-21 02:12:38	0|meshcollider|still solidifying the approach in my head atm
 32 2017-12-21 03:20:54	0|jonasschnelli|valentinewallace: sure.. shoot your Q
 33 2017-12-21 03:24:04	0|sipa|jonasschnelli: why are you awake? :)
 34 2017-12-21 03:26:54	0|jonasschnelli|sipa: I'm usually awake at 17:26. :)
 35 2017-12-21 03:27:18	0|jonasschnelli|Don't assume I'm always in CH. :)
 36 2017-12-21 03:28:28	0|sipa|oh.
 37 2017-12-21 03:28:50	0|sipa|hawaii?
 38 2017-12-21 03:28:56	0|jonasschnelli|Jup
 39 2017-12-21 03:33:43	0|SomeBuggyCode|Hello
 40 2017-12-21 03:37:38	0|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
 41 2017-12-21 03:41:47	0|jonasschnelli|SomeBuggyCode: https://github.com/bitcoin/bitcoin/issues
 42 2017-12-21 03:42:34	0|SomeBuggyCode|True enough
 43 2017-12-21 03:43:03	0|jonasschnelli|https://github.com/bitcoin/bitcoin/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22
 44 2017-12-21 03:43:03	0|jonasschnelli|Look also for the "good first issue" tag:
 45 2017-12-21 03:43:47	0|SomeBuggyCode|Oh wow
 46 2017-12-21 03:43:55	0|SomeBuggyCode|Didn't know about that
 47 2017-12-21 05:34:34	0|bitcoin-git|[13bitcoin] 15Varunram opened pull request #11969: logs: Improve "mempool min fee not met" error (06master...06mempoolfix) 02https://github.com/bitcoin/bitcoin/pull/11969
 48 2017-12-21 05:49:58	0|mcorbettsr|hello all having prob with core 0.15.1
 49 2017-12-21 05:54:03	0|jonasschnelli|meshcollider: maybe #bitcoin?
 50 2017-12-21 05:54:20	0|jonasschnelli|sry, mean mcorbettsr but he left
 51 2017-12-21 05:54:57	0|meshcollider|heh all good, I never understand why people ask questions and then leave before they get a response
 52 2017-12-21 05:55:26	0|gmaxwell|maybe he solved his problem
 53 2017-12-21 06:30:38	0|jonasschnelli|Do I need to hold cs_main while looping through CCoinsViewCursor& cursor with while (cursor.Valid()) and cursor.Next();?
 54 2017-12-21 06:30:55	0|jonasschnelli|I guess no (at least gettxoutinfo does not
 55 2017-12-21 06:30:59	0|jonasschnelli|+)
 56 2017-12-21 08:07:19	0|ryanofsky|jonasschnelli, i think if you're using pcoinsdbview you don't need cs_main, but if you using pcoinsTip you do
 57 2017-12-21 08:08:02	0|jonasschnelli|thanks ryanofsky
 58 2017-12-21 08:08:39	0|ryanofsky|i was also wondering if #9306 might be useful for what you are doing
 59 2017-12-21 08:08:41	0|gribble|https://github.com/bitcoin/bitcoin/issues/9306 | Make CCoinsViewCache::Cursor() return latest data by ryanofsky · Pull Request #9306 · bitcoin/bitcoin · GitHub
 60 2017-12-21 08:12:15	0|jonasschnelli|ryanofsky: I'm implementing UTXO scans (provide pubkeys, xpubs, get unspents, total, etc.)
 61 2017-12-21 08:15:13	0|jonasschnelli|ryanofsky: Can you explain the benefits of 9306?
 62 2017-12-21 08:17:18	0|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
 63 2017-12-21 08:18:34	0|jonasschnelli|If you FlushStateToDisk(); and then loop with the curser will give you the same results?
 64 2017-12-21 08:19:24	0|ryanofsky|yeah, that should basically be the same
 65 2017-12-21 08:19:57	0|jonasschnelli|Are there any performance implications/benefits?
 66 2017-12-21 08:20:07	0|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
 67 2017-12-21 08:20:10	0|jonasschnelli|Scanning the whole set takes a couplf of mins here
 68 2017-12-21 08:20:28	0|jonasschnelli|*couple
 69 2017-12-21 08:20:49	0|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
 70 2017-12-21 08:22:40	0|jonasschnelli|ryanofsky: I'll open a PR soon (next week maybe) and happy if you have a look for possible optimisations...
 71 2017-12-21 08:22:42	0|jonasschnelli|thanks
 72 2017-12-21 08:23:13	0|ryanofsky|sounds good
 73 2017-12-21 08:28:23	0|sipa|flushing just to perform a wallet operation sounds like sething we should avoid
 74 2017-12-21 08:30:50	0|bitcoin-git|[13bitcoin] 15laanwj pushed 5 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/604e08c83cf5...7a11ba7e01f3
 75 2017-12-21 08:30:51	0|bitcoin-git|13bitcoin/06master 14b798f9b 15Wladimir J. van der Laan: contrib: New clang patch for install_db4...
 76 2017-12-21 08:30:51	0|bitcoin-git|13bitcoin/06master 14c0298b0 15Wladimir J. van der Laan: contrib: Make X=Y arguments work in install_db4...
 77 2017-12-21 08:30:52	0|bitcoin-git|13bitcoin/06master 14d95c83d 15Wladimir J. van der Laan: contrib: FreeBSD compatibility in install_db4.sh...
 78 2017-12-21 08:31:25	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11945: Improve BSD compatibility of contrib/install_db4.sh (06master...062017_12_contrib_bsd) 02https://github.com/bitcoin/bitcoin/pull/11945
 79 2017-12-21 09:49:08	0|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
 80 2017-12-21 09:50:05	0|meshcollider|Without using a variant or univalue or whatever
 81 2017-12-21 09:51:39	0|ryanofsky|is registration just declaring a global variable? if so the type should just be part of the variable type, maybe a template argument
 82 2017-12-21 10:24:17	0|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
 83 2017-12-21 11:44:30	0|ryanofsky|meshcollider, probably through subclassing. you could have list<unique_ptr<Option>>, with IntOption, BoolOption, StringOption subclasses, for example
 84 2017-12-21 12:03:52	0|bitcoin-git|[13bitcoin] 15laanwj pushed 8 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/7a11ba7e01f3...711d16ca4a91
 85 2017-12-21 12:03:53	0|bitcoin-git|13bitcoin/06master 14b702ae8 15MeshCollider: Add CScripts to dumpwallet RPC
 86 2017-12-21 12:03:53	0|bitcoin-git|13bitcoin/06master 14cdc260a 15MeshCollider: Add GetCScripts to CBasicKeyStore
 87 2017-12-21 12:03:54	0|bitcoin-git|13bitcoin/06master 14ef0c730 15MeshCollider: Add scripts to importwallet RPC
 88 2017-12-21 12:04:17	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11667: Add scripts to dumpwallet RPC (06master...06201710_dumpwallet_scripts) 02https://github.com/bitcoin/bitcoin/pull/11667
 89 2017-12-21 12:05:22	0|bitcoin-git|[13bitcoin] 15ryanofsky opened pull request #11970: Add test coverage for bitcoin-cli multiwallet calls (06master...06pr/mcli) 02https://github.com/bitcoin/bitcoin/pull/11970
 90 2017-12-21 12:14:21	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10051: adhere to `-whitelist` for outbound connection (06master...06whitelist-outbound) 02https://github.com/bitcoin/bitcoin/pull/10051
 91 2017-12-21 12:49:56	0|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 ?
 92 2017-12-21 13:12:31	0|DSidH|nvm: got the answer. (yes)
 93 2017-12-21 13:47:21	0|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)
 94 2017-12-21 13:49:02	0|wumpus|Varunram: usually we do one "update copyright years" PR at the end of the yera
 95 2017-12-21 13:49:09	0|wumpus|if the file is touched that year
 96 2017-12-21 13:49:27	0|Varunram|was just curious, thanks!
 97 2017-12-21 13:51:34	0|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.
 98 2017-12-21 13:54:05	0|Varunram|yep, got the "don't update copyright until the file is changed" part, but just wanted to know the rationale behind it :)
 99 2017-12-21 14:01:02	0|bitcoin-git|[13bitcoin] 15Varunram opened pull request #11971: [docs]: include README with binary releases (06master...06bindoc) 02https://github.com/bitcoin/bitcoin/pull/11971
100 2017-12-21 16:36:07	0|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?
101 2017-12-21 16:37:38	0|ilanosortap|Also, since i am beginner how can i choose bugs to work on
102 2017-12-21 16:40:06	0|mikestovlensky|Anyone here?
103 2017-12-21 16:40:12	0|mikestovlensky|I've got a quick question
104 2017-12-21 16:43:10	0|ryanofsky|ilanosortap, list of good first issues is https://github.com/bitcoin/bitcoin/issues?q=label%3A%22good+first+issue%22, build instructions https://github.com/bitcoin/bitcoin/blob/master/doc/README.md
105 2017-12-21 16:44:47	0|mikestovlensky|Hi Ryan
106 2017-12-21 16:45:10	0|mikestovlensky|Have you had any contact with the people at Coinbase about when they plan to support Segwit?
107 2017-12-21 16:49:13	0|BlueMatt|mikestovlensky: dont think this is the place, #bitcoin
108 2017-12-21 16:49:23	0|ryanofsky|sorry, i don't know anything and i don't think coinbase developers are active here
109 2017-12-21 16:49:28	0|BlueMatt|also, answer is probably no
110 2017-12-21 16:50:41	0|mikestovlensky|I asked Coinbase, they just ignore me
111 2017-12-21 16:50:49	0|mikestovlensky|Just checking in case they have a line in with you folks
112 2017-12-21 16:51:26	0|wumpus|no, not at all
113 2017-12-21 16:51:41	0|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
114 2017-12-21 16:52:12	0|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
115 2017-12-21 16:52:21	0|wumpus|thank you, same to you
116 2017-12-21 17:01:42	0|ilanosortap|Thanks a lot @ryanofsky
117 2017-12-21 17:16:00	0|goatpig|Is there a version of SPV that keeps track a record of the last 1000 blocks or so?
118 2017-12-21 17:18:07	0|wumpus|no, there is no SPV mode in bitcoin core at all at the moment
119 2017-12-21 17:18:44	0|goatpig|oh, what about pruned mode?
120 2017-12-21 17:19:00	0|wumpus|there's https://github.com/bitcoin/bitcoin/pull/9483 which could use review and testing
121 2017-12-21 17:19:07	0|wumpus|yes, there is a pruned mode
122 2017-12-21 17:19:43	0|goatpig|thanks
123 2017-12-21 18:13:13	0|luke-jr|goatpig: pruned mode isn't SPV
124 2017-12-21 18:14:33	0|goatpig|i know, im just looking into alternate node modes and thinking forward
125 2017-12-21 18:29:16	0|jonasschnelli|goatpig: what are you building?
126 2017-12-21 18:29:37	0|jonasschnelli|IMO the most straight forward way if you want to run multiple wallets away from a Core node would be an RPC proxy.
127 2017-12-21 18:30:39	0|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
128 2017-12-21 18:30:41	0|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).
129 2017-12-21 18:31:00	0|jonasschnelli|Which would also work with pruned peers.
130 2017-12-21 18:31:21	0|jonasschnelli|So a single pruned peer node could server (maybe) hundreds of wallets.. no index required
131 2017-12-21 18:31:39	0|jonasschnelli|Backup recovery is only possible via UTXO-set sweep
132 2017-12-21 18:32:50	0|goatpig|not building anything yet
133 2017-12-21 18:32:53	0|goatpig|working on my supernode
134 2017-12-21 18:33:11	0|goatpig|thinking of a hybrid mode where clients bootstrap on a public supernode then run off of a lite bitcoin node
135 2017-12-21 18:36:35	0|jonasschnelli|goatpig: what is a supernode?
136 2017-12-21 18:36:48	0|jonasschnelli|what is a lite bitcoin node?
137 2017-12-21 18:37:01	0|goatpig|db that tracks all blockchain history undiscrimnately
138 2017-12-21 18:37:21	0|goatpig|can handle any arbitrary history request quickly
139 2017-12-21 18:37:36	0|arubi|I can just feed it any blockchain and it would index it?
140 2017-12-21 18:37:39	0|luke-jr|archive node?
141 2017-12-21 18:37:47	0|goatpig|basically yes
142 2017-12-21 18:37:47	0|jonasschnelli|goatpig: fully indexed? Like an electrum server?
143 2017-12-21 18:37:49	0|luke-jr|oh
144 2017-12-21 18:37:53	0|goatpig|yes
145 2017-12-21 18:38:06	0|arubi|well, sounds like free for all dos
146 2017-12-21 18:38:07	0|jonasschnelli|Okay. Yes. Pretty inefficient if you just want to run a handful of wallets
147 2017-12-21 18:38:08	0|luke-jr|goatpig: so that assumes the blockchains in question are minimally compatible with Bitcoin in some way?
148 2017-12-21 18:38:14	0|jonasschnelli|But ideally for a large backend
149 2017-12-21 18:38:33	0|luke-jr|jonasschnelli: IMO it should be a goal that Core does something similar long-term
150 2017-12-21 18:38:34	0|goatpig|luke-jr: this is targetted at Bitcoin, i dont do alts
151 2017-12-21 18:38:47	0|arubi|oh ^
152 2017-12-21 18:38:54	0|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
153 2017-12-21 18:38:56	0|jonasschnelli|luke-jr: Yeah.. I started to change my mind about indexing... it may should be in Core
154 2017-12-21 18:38:57	0|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!
155 2017-12-21 18:39:02	0|luke-jr|goatpig: that contradicts the "undiscrimnately" part.. invalid blocks aren't Bitcoin
156 2017-12-21 18:39:03	0|goatpig|arubi: any public facing service has to, but this can also be used internally by businesses
157 2017-12-21 18:39:05	0|webuser8434|Ah, and please please release this bloody Segwit yesterday.
158 2017-12-21 18:39:11	0|webuser8434|Good holidays chaps!
159 2017-12-21 18:39:20	0|luke-jr|jonasschnelli: for example, by tracking BCH's chain, we can use "total known hashrate" as a security metric
160 2017-12-21 18:39:45	0|arubi|goatpig, I'll have to see what you mean by "any blockchain"
161 2017-12-21 18:39:45	0|wumpus|eck: 'cryptography' is kind of general
162 2017-12-21 18:40:13	0|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
163 2017-12-21 18:40:21	0|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
164 2017-12-21 18:40:26	0|goatpig|arubi: im not saying that, this is based on Bitcoin, i dont care about other networks/chains
165 2017-12-21 18:40:37	0|luke-jr|jonasschnelli: yes, but it's an improvement
166 2017-12-21 18:41:04	0|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
167 2017-12-21 18:41:27	0|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.
168 2017-12-21 18:41:38	0|luke-jr|jonasschnelli: it's harder to hide 50%
169 2017-12-21 18:41:40	0|arubi|goatpig, alright, but I don't think I understand the usefulness if it's targeted at bitcoin specifically
170 2017-12-21 18:41:56	0|goatpig|my users run against fullnodes
171 2017-12-21 18:41:58	0|goatpig|this lets you do
172 2017-12-21 18:42:09	0|goatpig|1 fullnode -> 1 db -> any amount of clients
173 2017-12-21 18:42:10	0|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
174 2017-12-21 18:42:18	0|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
175 2017-12-21 18:42:39	0|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.
176 2017-12-21 18:42:43	0|arubi|goatpig, so the clients aren't fully validating?
177 2017-12-21 18:42:52	0|jonasschnelli|goatpig: if you don't care about the backup recovery, you can run endless wallets on a 4GB pruned peer
178 2017-12-21 18:43:17	0|provoostenator|(known work, and the trustworthy timestamp bit doesn't seem trivial)
179 2017-12-21 18:43:22	0|wumpus|eck: in that case it might be useful to focus on the math underpinning it, group theory etc first
180 2017-12-21 18:43:40	0|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
181 2017-12-21 18:44:13	0|goatpig|arubi: the armory stack is full node, db, client. im looking into possible ways around that
182 2017-12-21 18:44:43	0|arubi|ah, you're right.  yea I understand now.  I missed context
183 2017-12-21 18:44:58	0|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/
184 2017-12-21 18:45:08	0|eck|great, thank you for the recommendation!
185 2017-12-21 18:45:16	0|goatpig|jonasschnelli: as long as i can deliver a good service with armory, Core wouldn't need to work towards that
186 2017-12-21 18:45:19	0|wumpus|eck: besides I really enjoyed "applied cryptoanalsys
187 2017-12-21 18:45:30	0|wumpus|eck: but that's as off topic to cryptocurrencies as it's possible :)
188 2017-12-21 18:45:44	0|eck|i might enjoy it anyway, i'll take a look
189 2017-12-21 18:46:01	0|jonasschnelli|"applied cryptoanalysys"... is that the new word for hacking?
190 2017-12-21 18:46:04	0|jonasschnelli|:-)
191 2017-12-21 18:46:59	0|wumpus|jonasschnelli: it's about breaking rsa in some edge cases, timing attacks, and breaking various historical ciphers, so yea sort of
192 2017-12-21 18:47:31	0|wumpus|but not the expoitation kind
193 2017-12-21 18:50:06	0|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...
194 2017-12-21 18:50:36	0|wumpus|eck: http://cryptopals.com/ has some fairly interesting challenges re: applied cryptography things
195 2017-12-21 18:50:55	0|wumpus|provoostenator: uh oh
196 2017-12-21 18:51:28	0|wumpus|provoostenator: are you able to get a traceback?
197 2017-12-21 18:51:33	0|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.
198 2017-12-21 18:51:58	0|provoostenator|wumpus: where would I find that?
199 2017-12-21 18:52:33	0|wumpus|well if you ran it in gdb it would be easy, otherwise, did it dump a core file?
200 2017-12-21 18:53:20	0|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
201 2017-12-21 18:55:13	0|jonasschnelli|provoostenator: I guess you ran in the OOM issue? It's still in master AFAIK
202 2017-12-21 18:55:17	0|provoostenator|OSX applications sometimes create crash reports. Maybe that's something we can / need to enable? At least in debug mode.
203 2017-12-21 18:55:31	0|jonasschnelli|The crash report should be stored somewhere
204 2017-12-21 18:55:38	0|provoostenator|I'm on sipa's SegWit branch and I set a pretty high dbcache
205 2017-12-21 18:56:18	0|jonasschnelli|provoostenator: reindexes on current master causes OOM (on my 32GB machine it did): You need https://github.com/bitcoin/bitcoin/pull/11824
206 2017-12-21 18:56:26	0|jonasschnelli|11824 should probably by hi-prio
207 2017-12-21 18:56:58	0|jonasschnelli|I did a reindex 4-5 days ago and had the OOM crash on debian with 32GB ram
208 2017-12-21 18:57:07	0|provoostenator|Why would an OOM cause a new IDB?
209 2017-12-21 18:57:10	0|provoostenator|IBD
210 2017-12-21 18:57:10	0|provoostenator|IBD
211 2017-12-21 18:57:34	0|promag|does it cause ibd?
212 2017-12-21 18:57:52	0|jonasschnelli|provoostenator: I think you may end up with a corrupted db.. even if you souldn't (in theory)
213 2017-12-21 18:58:03	0|provoostenator|Oh I was monitoring memory usage, and that was about 30 GB during the reindex (I have 16 GB physical)
214 2017-12-21 18:58:22	0|jonasschnelli|provoostenator: yes. Its fixed in 11824
215 2017-12-21 18:58:35	0|jonasschnelli|reindex in master is currently not usable
216 2017-12-21 18:58:38	0|provoostenator|promag: I don't know if it caused IBD, but it certain started an IBD after this happened
217 2017-12-21 18:58:40	0|wumpus|apparently the validation queue fills memory
218 2017-12-21 18:59:58	0|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.
219 2017-12-21 19:00:04	0|promag|guess I'll check 11824 too
220 2017-12-21 19:00:47	0|gmaxwell|it would effect IBD too
221 2017-12-21 19:01:05	0|luke-jr|depending on bandwidth?
222 2017-12-21 19:01:09	0|jonasschnelli|I haven't looked at the code of 11824 to be honest...
223 2017-12-21 19:01:11	0|cfields|meeting?
224 2017-12-21 19:01:13	0|wumpus|#startmeeting
225 2017-12-21 19:01:14	0|lightningbot|Meeting started Thu Dec 21 19:01:13 2017 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
226 2017-12-21 19:01:14	0|lightningbot|Useful Commands: #action #agreed #help #info #idea #link #topic.
227 2017-12-21 19:01:19	0|provoostenator|gmaxwell: ok, that's "great"; saves me time to reproduce. So far it's only using 1.1 GB of RAM in ~2013...
228 2017-12-21 19:01:19	0|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
229 2017-12-21 19:01:28	0|jonasschnelli|hi
230 2017-12-21 19:01:39	0|Chris_Stewart_5|hello
231 2017-12-21 19:01:40	0|provoostenator|hi
232 2017-12-21 19:01:42	0|promag|hi o/
233 2017-12-21 19:01:55	0|kanzure|hi.
234 2017-12-21 19:01:59	0|luke-jr|why?
235 2017-12-21 19:02:09	0|gmaxwell|people travling for holidays
236 2017-12-21 19:02:14	0|luke-jr|oh
237 2017-12-21 19:02:23	0|sipa|oh, look, a meeting
238 2017-12-21 19:02:24	0|provoostenator|Without taking their laptop? Lame.
239 2017-12-21 19:02:26	0|promag|or buying gifts
240 2017-12-21 19:02:34	0|wumpus|seems there are enough people to warrant a meeting
241 2017-12-21 19:02:42	0|cfields|hi
242 2017-12-21 19:03:13	0|wumpus|but yes holidays is a good topic, I won't be there for next week and the week after that meeting
243 2017-12-21 19:03:42	0|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
244 2017-12-21 19:04:39	0|jonasschnelli|topics?
245 2017-12-21 19:04:43	0|jtimon|hi
246 2017-12-21 19:04:50	0|wumpus|segwit wallet merge? please? :)
247 2017-12-21 19:04:58	0|jonasschnelli|Yes. Please
248 2017-12-21 19:05:00	0|gmaxwell|plz
249 2017-12-21 19:05:04	0|jonasschnelli|xmas present
250 2017-12-21 19:05:09	0|sipa|but also please review first
251 2017-12-21 19:05:10	0|wumpus|#topic segwit wallet
252 2017-12-21 19:05:18	0|wumpus|what is left to do?
253 2017-12-21 19:05:34	0|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
254 2017-12-21 19:05:34	0|sipa|ryanofsky made a nice list of todos in a comment (all for other PRs ino)
255 2017-12-21 19:05:46	0|wumpus|yes, I mean for this PR
256 2017-12-21 19:05:52	0|sipa|BlueMatt: i've responded, please review
257 2017-12-21 19:06:00	0|BlueMatt|yes, will try to get back to it this week
258 2017-12-21 19:06:06	0|wumpus|there's plenty of things that can be done after merging it
259 2017-12-21 19:06:13	0|sipa|cool
260 2017-12-21 19:06:22	0|gmaxwell|sipa: did you look into that multisig still using p2sh thing we discussed?
261 2017-12-21 19:06:32	0|sipa|gmaxwell: yes, fixed, and added tests
262 2017-12-21 19:06:42	0|BlueMatt|oh, yes, it def needed more tests
263 2017-12-21 19:06:52	0|aj|ryanofsky's todo's: https://github.com/bitcoin/bitcoin/pull/11403#pullrequestreview-83563917
264 2017-12-21 19:06:58	0|sipa|BlueMatt: also addressed, i think
265 2017-12-21 19:07:03	0|BlueMatt|kool
266 2017-12-21 19:07:07	0|wumpus|#link ryanofsky's todo's: https://github.com/bitcoin/bitcoin/pull/11403#pullrequestreview-83563917
267 2017-12-21 19:07:55	0|sipa|ah yes, there are no address_type parsing tests yet
268 2017-12-21 19:07:59	0|sipa|i'll add those
269 2017-12-21 19:08:16	0|wumpus|great
270 2017-12-21 19:09:08	0|wumpus|any other topics?
271 2017-12-21 19:09:18	0|jonasschnelli|gitian build are broken
272 2017-12-21 19:09:19	0|jonasschnelli|https://github.com/bitcoin/bitcoin/issues/11935
273 2017-12-21 19:09:23	0|jonasschnelli|*builds
274 2017-12-21 19:09:34	0|BlueMatt|review 0.16 stuff!
275 2017-12-21 19:09:35	0|jonasschnelli|(I think its not a local issue)
276 2017-12-21 19:09:40	0|BlueMatt|(not just segwit wallet)
277 2017-12-21 19:09:42	0|wumpus|oh no not again
278 2017-12-21 19:09:53	0|cfields|mm, will have a look
279 2017-12-21 19:09:55	0|jonasschnelli|I think its one for cfields
280 2017-12-21 19:09:59	0|cfields|jonasschnelli: thanks for reporting
281 2017-12-21 19:10:18	0|cfields|jonasschnelli: oh, i see
282 2017-12-21 19:10:30	0|cfields|it's missing -static-libstdc++ for some reason
283 2017-12-21 19:10:30	0|Chris_Stewart_5|is there still a memory leak on master?
284 2017-12-21 19:10:38	0|wumpus|oh the symbols check fails
285 2017-12-21 19:10:50	0|gmaxwell|Chris_Stewart_5: it's not a memory leak, but yes its still there.
286 2017-12-21 19:10:50	0|jonasschnelli|Chris_Stewart_5: yes see 11824
287 2017-12-21 19:10:53	0|sipa|Chris_Stewart_5: not a leak, but memory is growing unboundedly
288 2017-12-21 19:10:59	0|wumpus|yes, it shouldn't dynamically import libstdc++
289 2017-12-21 19:11:02	0|cfields|yea, the stdlib is just linked shared. Will get to the bottom of it.
290 2017-12-21 19:11:21	0|wumpus|cfields: thanks
291 2017-12-21 19:11:22	0|cfields|nice to see that got caught!
292 2017-12-21 19:12:34	0|jonasschnelli|it's broken since dec. 1st if that helps track down the relevant commit
293 2017-12-21 19:13:38	0|wumpus|two PRs were merged that day, #11804 and #11337
294 2017-12-21 19:13:40	0|gribble|https://github.com/bitcoin/bitcoin/issues/11804 | [docs] Fixed outdated link with archive.is by TimothyShimmin · Pull Request #11804 · bitcoin/bitcoin · GitHub
295 2017-12-21 19:13:42	0|gribble|https://github.com/bitcoin/bitcoin/issues/11337 | Fix code constness in CBlockIndex::GetAncestor() overloads by danra · Pull Request #11337 · bitcoin/bitcoin · GitHub
296 2017-12-21 19:14:14	0|cfields|thanks
297 2017-12-21 19:14:35	0|jonasschnelli|Build 2017-12-01 00:00:10 UTC failed... but build 2017-11-30 00:00:10 UTC succeeded
298 2017-12-21 19:14:50	0|wumpus|ok many more things were merged the day before that
299 2017-12-21 19:15:37	0|sipa|dec 1st in what tz?
300 2017-12-21 19:15:46	0|jonasschnelli|2017-12-01 00:00:10 UTC
301 2017-12-21 19:16:05	0|jonasschnelli|Commit must be between 2017-11-30 00:00:10 UTC and 2017-12-01 00:00:10 UTC
302 2017-12-21 19:16:20	0|jonasschnelli|But maybe other topics first?
303 2017-12-21 19:16:55	0|jonasschnelli|anything to change at / mention from the HP list https://github.com/bitcoin/bitcoin/projects/8?
304 2017-12-21 19:17:15	0|jtimon|BlueMatt: what is "0.16 stuff"?
305 2017-12-21 19:17:15	0|wumpus|there's 10 things on there already, I don't think it will help to add more
306 2017-12-21 19:17:31	0|BlueMatt|jtimon: https://github.com/bitcoin/bitcoin/milestone/30
307 2017-12-21 19:17:36	0|wumpus|only so much that can be 'high priority' at once
308 2017-12-21 19:17:55	0|wumpus|and what we really want is segwit wallet anyway
309 2017-12-21 19:18:06	0|sipa|prioritize ALL THE THINGS!
310 2017-12-21 19:18:14	0|wumpus|hehe
311 2017-12-21 19:18:27	0|jtimon|does everything in there need to be merged before forking 0.16 ?
312 2017-12-21 19:18:36	0|wumpus|jtimon: no
313 2017-12-21 19:18:46	0|wumpus|just segwit wallet + the bugfixes
314 2017-12-21 19:18:56	0|wumpus|all features are optional
315 2017-12-21 19:19:14	0|wumpus|I think we get this question every week
316 2017-12-21 19:19:33	0|jonasschnelli|Maybe a short discussion about fallbackfee / RBF defaults?
317 2017-12-21 19:19:43	0|wumpus|#topic fallbackfee / RBF defaults
318 2017-12-21 19:19:44	0|jtimon|I guess the 0.16 tag confuses me
319 2017-12-21 19:20:10	0|jonasschnelli|There is a PR to split walletrbf between RPC and GUI #11605 (I don't think we should do that)
320 2017-12-21 19:20:13	0|gribble|https://github.com/bitcoin/bitcoin/issues/11605 | [Wallet] Enable RBF by default in QT by Sjors · Pull Request #11605 · bitcoin/bitcoin · GitHub
321 2017-12-21 19:20:20	0|wumpus|RBF should probably become default, I don't think there's any way around that
322 2017-12-21 19:20:23	0|gmaxwell|RBF should probably be default now, electrum does it, without any great consequence.
323 2017-12-21 19:20:23	0|jonasschnelli|Also,.. there are two PRs do disable the fallback fee (one on mainnet, one entierly)
324 2017-12-21 19:20:34	0|instagibbs|wumpus, ACK
325 2017-12-21 19:20:41	0|jonasschnelli|Okay. I agree. So lets enable it by default.
326 2017-12-21 19:20:51	0|promag|+1
327 2017-12-21 19:20:53	0|gmaxwell|jonasschnelli: if fallback fee is disabled what happens if it would otherwise use it?
328 2017-12-21 19:21:05	0|jonasschnelli|provoostenator: can you transform your PR toward that: 11605?
329 2017-12-21 19:21:05	0|wumpus|not sure what the rationale is to enable it only by default for qt?
330 2017-12-21 19:21:11	0|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.
331 2017-12-21 19:21:14	0|jonasschnelli|gmaxwell: reject
332 2017-12-21 19:21:26	0|jonasschnelli|Disabled fallback fee = JSON throw or QT reject
333 2017-12-21 19:21:34	0|gmaxwell|jonasschnelli: I mean, does the user get prompted to enter a fee?
334 2017-12-21 19:21:39	0|jonasschnelli|No
335 2017-12-21 19:21:45	0|wumpus|but let's merge enabling it for the gui first at least that's a step forward
336 2017-12-21 19:21:46	0|jonasschnelli|No manual fee entering is provoked
337 2017-12-21 19:21:48	0|provoostenator|Electrum is used afaik person to person, not for broadcasting lots of stuff through an automated process.
338 2017-12-21 19:21:49	0|gmaxwell|so the software just becomes unusable?
339 2017-12-21 19:21:52	0|luke-jr|^
340 2017-12-21 19:21:57	0|wumpus|jonasschnelli: but it's possible to select a custom fee right?
341 2017-12-21 19:22:04	0|wumpus|jonasschnelli: the GUI has a checkbox for that
342 2017-12-21 19:22:05	0|jonasschnelli|wumpus: Yes. Always...
343 2017-12-21 19:22:10	0|luke-jr|hmm
344 2017-12-21 19:22:13	0|wumpus|so no, the software doesn't become unusable
345 2017-12-21 19:22:15	0|gmaxwell|What about in the rpc/cli?
346 2017-12-21 19:22:18	0|jonasschnelli|wumpus: but if you don't and fee estimations are not ready,.. rject!
347 2017-12-21 19:22:33	0|jonasschnelli|gmaxwell: reject if you haven't set fallbackfee or paytxfee and feeest is not ready
348 2017-12-21 19:22:40	0|jonasschnelli|fallback fees are the worst!
349 2017-12-21 19:22:43	0|jonasschnelli|(UX)
350 2017-12-21 19:23:00	0|gmaxwell|Is there are rpc way to see a fallback fee?
351 2017-12-21 19:23:01	0|jonasschnelli|Especially if its default enabled and the user don't get informed it was used!
352 2017-12-21 19:23:06	0|sipa|feeest!
353 2017-12-21 19:23:16	0|jonasschnelli|gmaxwell: I don't think so
354 2017-12-21 19:23:21	0|gmaxwell|jonasschnelli: in the gui does the failure message tell you that you can set a fee?
355 2017-12-21 19:23:25	0|provoostenator|See this comment and the IRC discussion it points back to: https://github.com/bitcoin/bitcoin/pull/11605#issuecomment-352056518 (also cc bluematt)
356 2017-12-21 19:23:26	0|jonasschnelli|If we disable it by default, you wonldn't
357 2017-12-21 19:23:40	0|jonasschnelli|gmaxwell: no.. but I guess I should add that
358 2017-12-21 19:23:58	0|jonasschnelli|gmaxwell: it says you should wait for the feeest to be ready (a couple of blocks)
359 2017-12-21 19:24:37	0|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.
360 2017-12-21 19:24:49	0|gmaxwell|probably need to add a trivial rpc to set the fallback fee.
361 2017-12-21 19:24:51	0|jtimon|ack on RBF by default. I would also remove -mempoolreplacement and always do replacements but that's likely to be more controversial
362 2017-12-21 19:25:07	0|instagibbs|jtimon, luke-jr says miners actually use this option
363 2017-12-21 19:25:11	0|jonasschnelli|gmaxwell: I agree.
364 2017-12-21 19:25:11	0|wumpus|it's still settable on the command line at least
365 2017-12-21 19:25:31	0|gmaxwell|since paytxfee doesn't really do the right thing there.
366 2017-12-21 19:25:32	0|sipa|it's probably best to look at the actual UI, which i haven't :)
367 2017-12-21 19:25:33	0|jonasschnelli|We could even fetch estimations from bitcoincore.org (*hide* *duck* *runaway")
368 2017-12-21 19:25:34	0|wumpus|not sure it'd make sense as a RPC, as there's already paytxfee
369 2017-12-21 19:25:42	0|zelest|sorry for asking, but can anyone just grab whatever bug in the repo and fix it.. and submit a pull request? :o
370 2017-12-21 19:25:48	0|instagibbs|jonasschnelli, or from one of my two suspended twitter bots :P
371 2017-12-21 19:25:54	0|jtimon|instagibbs: yeah, I remember that, just repeating my opinion about it
372 2017-12-21 19:25:55	0|jonasschnelli|heh
373 2017-12-21 19:26:02	0|gmaxwell|wumpus: IIRC paytxfee overrides the estimator, rather than being overridden by the estimator.
374 2017-12-21 19:26:11	0|sipa|indeed
375 2017-12-21 19:26:13	0|wumpus|zelest: no, you need triple-signed off documents from the central committee first
376 2017-12-21 19:26:20	0|wumpus|zelest: (yes, everyone can just do that :-)
377 2017-12-21 19:26:28	0|gmaxwell|wumpus: so if you achieve your fallback by setting paytxfee then you'll end up underpaying even when your estimator knows better.
378 2017-12-21 19:26:29	0|zelest|Ah ;-)
379 2017-12-21 19:26:32	0|jonasschnelli|The sendto commands have really no clever way to set the txfee
380 2017-12-21 19:26:51	0|zelest|Mayhaps this is what I should spend/waste my free time on...
381 2017-12-21 19:26:53	0|gmaxwell|in any case, I can write the rpc to set the fallback fee, it would be trivial.
382 2017-12-21 19:27:02	0|jtimon|what is the fallback fee?
383 2017-12-21 19:27:07	0|meshcollider|hi, sorry I'm late
384 2017-12-21 19:27:13	0|gmaxwell|and then the errors when you hit that case should just tell you to set the fee.
385 2017-12-21 19:27:14	0|wumpus|gmaxwell: I think it'd be slightly confusing to add yet another fee setting RPC, but okay
386 2017-12-21 19:27:15	0|jonasschnelli|jtimon: its the feerate used when no estimations are available
387 2017-12-21 19:27:22	0|wumpus|another global used in fee determination
388 2017-12-21 19:27:24	0|jtimon|jonasschnelli: thanks
389 2017-12-21 19:27:29	0|wumpus|zelest: that'd be awesome
390 2017-12-21 19:27:59	0|jonasschnelli|I agree with gmaxwell that we need a good UX for the first "day" when fee estimations are not available
391 2017-12-21 19:28:03	0|gmaxwell|wumpus: Agreed, but I don't see around it, telling lots of people to use paytxfee is probably a bad situation.
392 2017-12-21 19:28:11	0|promag|so if fee estimation is not available, rpc funding should fail?
393 2017-12-21 19:28:22	0|gmaxwell|jonasschnelli: not just first day, every day, because of resource usage lots of people don't leave their nodes running.
394 2017-12-21 19:28:24	0|jonasschnelli|promag: Yes
395 2017-12-21 19:28:25	0|wumpus|gmaxwell: agree...
396 2017-12-21 19:28:32	0|jonasschnelli|gmaxwell: indeed.
397 2017-12-21 19:28:47	0|gmaxwell|promag: unless you've set a fallback feerate.
398 2017-12-21 19:28:48	0|wumpus|gmaxwell: would almost wish that there'd be something like 'paytxfeepriority' but not that that would be any easier to understand :-)
399 2017-12-21 19:28:52	0|promag|jonasschnelli: and in the UI too? or prompt for custom?
400 2017-12-21 19:28:53	0|jtimon|gmaxwell: yeah, or people just shut down their computers when they go to sleep
401 2017-12-21 19:28:57	0|jonasschnelli|So either the user enters the current feerates into RPC/GUI or we load it from somewhere
402 2017-12-21 19:29:04	0|wumpus|gmaxwell: (e.g. whether it'd override the fee estimator or not)
403 2017-12-21 19:29:05	0|promag|gmaxwell: but we want to remove that?
404 2017-12-21 19:29:20	0|gmaxwell|promag: no we want to eliminate there being a default one.
405 2017-12-21 19:29:49	0|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.
406 2017-12-21 19:30:03	0|gmaxwell|But a static compiled in fallback is dumb.
407 2017-12-21 19:30:05	0|wumpus|promag: the problem is that fees are too variable now to hardcode any sensible default in the software
408 2017-12-21 19:30:07	0|promag|gmaxwell: ok, but once defined it can be outdated very fast
409 2017-12-21 19:30:22	0|luke-jr|ideally we could pre-sign multiple fee rates and send the higher ones once we have an estimate
410 2017-12-21 19:30:43	0|promag|luke-jr: only with rbf signaled
411 2017-12-21 19:30:54	0|gmaxwell|RBFing has complications, unfortunately.
412 2017-12-21 19:30:54	0|promag|?
413 2017-12-21 19:31:05	0|jonasschnelli|luke-jr: long term.... yes. Maybe. But complicated to implement
414 2017-12-21 19:31:05	0|luke-jr|well, require RBF when there's no estimates?
415 2017-12-21 19:31:14	0|jonasschnelli|luke-jr: I had this in a PR
416 2017-12-21 19:31:18	0|gmaxwell|You can't just assume that RBF will work unfortunately.
417 2017-12-21 19:31:25	0|gmaxwell|Because of the pinning problem.
418 2017-12-21 19:31:27	0|jonasschnelli|But then morocs asked for just disabling fallback.. which makes sense
419 2017-12-21 19:31:32	0|wumpus|RBF is orthogonal imo
420 2017-12-21 19:31:34	0|luke-jr|even without RBF, it would probably work if the problem is fee rate too low
421 2017-12-21 19:31:44	0|instagibbs|gmaxwell, "pinning" meaning someone spending on top?
422 2017-12-21 19:31:47	0|instagibbs|I like the name if so
423 2017-12-21 19:31:48	0|luke-jr|if nobody has the conflicting tx in their mempool, it's not even considered a replacement
424 2017-12-21 19:31:51	0|wumpus|yes, we also want RBF by default, but that doesn't change the fallback fee situation
425 2017-12-21 19:31:52	0|gmaxwell|instagibbs: with a large txn, yes.
426 2017-12-21 19:32:10	0|wumpus|certainly not for RPC
427 2017-12-21 19:32:38	0|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
428 2017-12-21 19:32:42	0|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.
429 2017-12-21 19:33:04	0|gmaxwell|jonasschnelli: RPC I think is fine, setfallbackfee ...  and the error returned on send tells you that you have to use that.
430 2017-12-21 19:33:15	0|wumpus|yeah...
431 2017-12-21 19:33:22	0|jonasschnelli|I think gmaxwell idea with the setfallbackfee RPC makes most sense..
432 2017-12-21 19:33:26	0|jtimon|yeah I think RBF is orthogonal too. let's just make it default independently of the estimation issue
433 2017-12-21 19:33:36	0|wumpus|jtimon: agree
434 2017-12-21 19:33:37	0|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.
435 2017-12-21 19:33:48	0|wumpus|right
436 2017-12-21 19:33:50	0|gmaxwell|(automatically)
437 2017-12-21 19:34:00	0|jtimon|don't we have an estimator purely based on past blocks with no knowledge of the mempool?
438 2017-12-21 19:34:28	0|instagibbs|jtimon, that's the only way we do it
439 2017-12-21 19:34:55	0|gmaxwell|instagibbs: not quite we watch the dwell time of transactions that confirm.
440 2017-12-21 19:34:55	0|jtimon|mhm, then why do you need to be up for some time to have estimates?
441 2017-12-21 19:34:59	0|gmaxwell|it needs both
442 2017-12-21 19:35:01	0|promag|how about something to help/speedup fee estimation?
443 2017-12-21 19:35:24	0|instagibbs|mistook the question
444 2017-12-21 19:35:25	0|wumpus|using only blocks would be easy to manipulate
445 2017-12-21 19:35:27	0|promag|like feeding fee estimation with something.. don't know the internals
446 2017-12-21 19:35:31	0|gmaxwell|using blocks exclusively is exploitable, unfortunately. Though there are limited ways which it could help.
447 2017-12-21 19:35:56	0|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.
448 2017-12-21 19:36:03	0|jtimon|perhaps we could have a non-mempool estimator that is used by default until there's data for the mempool based one
449 2017-12-21 19:36:20	0|wumpus|adding a new estimator is not going to go for 0.16 at least
450 2017-12-21 19:36:33	0|wumpus|in the future, who knows
451 2017-12-21 19:36:44	0|gmaxwell|also it's not likely to be invented by folks who don't know the current one and history. :)
452 2017-12-21 19:36:54	0|jtimon|say, something stupid like max (the minimum feerate in each block for the last 144 blocks)
453 2017-12-21 19:37:38	0|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.
454 2017-12-21 19:37:56	0|sipa|or bounding estimates by the feerate at 1 MB vbyte from the top of the mempool
455 2017-12-21 19:38:01	0|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
456 2017-12-21 19:38:09	0|gmaxwell|sipa: without mempool sync that isn't fast.
457 2017-12-21 19:38:16	0|jtimon|gmaxwell: right, 100 empty blocks would screw you
458 2017-12-21 19:38:18	0|sipa|ah yes
459 2017-12-21 19:38:23	0|gmaxwell|but indeed, once we have some kind of mempool sync we could do things like that.
460 2017-12-21 19:38:49	0|wumpus|100 empty blocks would screw everyone
461 2017-12-21 19:39:24	0|jtimon|is there a way to persist the mempool while running instead of only when shutting down?
462 2017-12-21 19:39:39	0|instagibbs|jtimon, i think there is an rpc for that
463 2017-12-21 19:39:50	0|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.
464 2017-12-21 19:40:06	0|wumpus|savemempool RPC
465 2017-12-21 19:40:22	0|instagibbs|https://github.com/bitcoin/bitcoin/pull/11099
466 2017-12-21 19:40:44	0|jtimon|gmaxwell: yeah, that sounds less stupid than what I proposed, and still isn't hard
467 2017-12-21 19:41:20	0|gmaxwell|or instead of their minimum feerate, their Nth percentile feerate.
468 2017-12-21 19:41:27	0|jtimon|I mean, still probably not for 0.16, but not hard to code I think
469 2017-12-21 19:41:32	0|gmaxwell|right
470 2017-12-21 19:41:48	0|wumpus|any other topics?
471 2017-12-21 19:42:07	0|gmaxwell|e.g. what feerate is less than 95% of the txn in the block... gives it room to ignore 5% priority txn.
472 2017-12-21 19:42:19	0|jtimon|wumpus: instagibbs thank you! and sorry, the question is kind of unrelated anyway
473 2017-12-21 19:42:21	0|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.
474 2017-12-21 19:42:21	0|wumpus|yes that'd make sense
475 2017-12-21 19:42:40	0|gmaxwell|provoostenator: an RPC using service can at least read the release note and simply turn it off again.
476 2017-12-21 19:42:44	0|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
477 2017-12-21 19:42:50	0|wumpus|promag: let's first enable it for the gui, at least that's uncontroversial
478 2017-12-21 19:42:55	0|wumpus|provoostenator*
479 2017-12-21 19:44:23	0|instagibbs|15 minutes left
480 2017-12-21 19:44:25	0|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.
481 2017-12-21 19:44:30	0|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
482 2017-12-21 19:44:52	0|gmaxwell|rpc can wait, we can release note a reminder that you can turn it on for cli/rpc use.
483 2017-12-21 19:44:54	0|promag|wumpus: ok
484 2017-12-21 19:45:10	0|wumpus|people using RPC will usually have a better idea of available options anyhow
485 2017-12-21 19:45:12	0|provoostenator|gmaxwell: I already put that in the release note in my PR
486 2017-12-21 19:45:21	0|instagibbs|perhaps with a warning that future versions may change this
487 2017-12-21 19:45:22	0|provoostenator|(sort of)
488 2017-12-21 19:45:35	0|jonasschnelli|I don't think splitting walletrbf between GUI and RPC makes sense in the long run
489 2017-12-21 19:45:40	0|wumpus|yes, defaults are subject to change
490 2017-12-21 19:45:44	0|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.
491 2017-12-21 19:45:45	0|wumpus|jonasschnelli: on the long run it makes no sense
492 2017-12-21 19:45:50	0|provoostenator|I think it does make sense to treat GUI and RPC different
493 2017-12-21 19:45:53	0|wumpus|jonasschnelli: it'd be a temporary artifact
494 2017-12-21 19:45:56	0|provoostenator|Very different use cases.
495 2017-12-21 19:45:59	0|gmaxwell|just get rid of the setting for the GUI.
496 2017-12-21 19:46:15	0|provoostenator|It's just a code maintenance thing why we shouldn't make them too different.
497 2017-12-21 19:46:28	0|sipa|gmaxwell: if you're worried about OOB paymemts, shouldn't you also be concerned about OOB refunds?
498 2017-12-21 19:46:39	0|jonasschnelli|What speak again just enabling -walletrbf GUI/RPC by default?
499 2017-12-21 19:46:42	0|jonasschnelli|*against
500 2017-12-21 19:46:44	0|wumpus|gmaxwell: I think that's a good point too - why would the GUI need a setting for the default?
501 2017-12-21 19:46:47	0|jtimon|i think rbf active is the most sensible default for both rpc and gui
502 2017-12-21 19:46:49	0|gmaxwell|sipa: OOB refunds don't currently appear to be a real thing.
503 2017-12-21 19:46:50	0|wumpus|it has a checkbox if you really want to disable it
504 2017-12-21 19:46:57	0|provoostenator|gmaxwell: yes, I can kill the setting for the GUI, especially because I renamed the RPC setting to -rpcwalletrbf
505 2017-12-21 19:47:01	0|gmaxwell|wumpus: yep thats just what I was typing, that it has a checkbox.
506 2017-12-21 19:47:01	0|jonasschnelli|wumpus: people are lazy to read checkboxes? :)
507 2017-12-21 19:47:26	0|gmaxwell|then they'll certantly not read a setting. :)
508 2017-12-21 19:47:26	0|wumpus|jonasschnelli: well the default is sensible, lazy people won't want to override it!
509 2017-12-21 19:47:32	0|wumpus|gmaxwell: indeed
510 2017-12-21 19:47:43	0|sipa|gmaxwell: for now.
511 2017-12-21 19:47:58	0|wumpus|+1 on not having the GUI default setting
512 2017-12-21 19:48:02	0|jonasschnelli|Set walletrbf=1 by default,.. switch the checkbox in the GUI  (to disable RBF instead of enable)
513 2017-12-21 19:49:25	0|jtimon|why not leave the checkbox as meaning enabled but simply have it checked by default?
514 2017-12-21 19:49:30	0|provoostenator|Rather than renaming -walletrbf to -rpcwalletrbf, I can also make it clear that -walletrbf won't impact the GUI.
515 2017-12-21 19:49:43	0|wumpus|provoostenator: yes, I'd prefer that
516 2017-12-21 19:49:47	0|gmaxwell|+1
517 2017-12-21 19:49:54	0|wumpus|provoostenator: I'd really prefer not to have a rename/deprecate cycle there
518 2017-12-21 19:50:00	0|wumpus|provoostenator: (as I've expressed before)
519 2017-12-21 19:50:03	0|gmaxwell|better to not break things for people who are already walletrbf=1 if we can avoid it.
520 2017-12-21 19:50:10	0|wumpus|yeah...
521 2017-12-21 19:50:26	0|wumpus|just document the option instead of renaming it
522 2017-12-21 19:50:27	0|jonasschnelli|Wait...yes. This makes sense
523 2017-12-21 19:50:28	0|provoostenator|Yeah, the deprecation stuff was a bit overkill.
524 2017-12-21 19:50:49	0|gmaxwell|just adjust the description, make the gui not read that setting for the checkbox default.
525 2017-12-21 19:50:49	0|wumpus|ok, cool!
526 2017-12-21 19:50:56	0|wumpus|seems we agree
527 2017-12-21 19:50:58	0|jonasschnelli|ack
528 2017-12-21 19:51:06	0|meshcollider|yep sounds good
529 2017-12-21 19:51:07	0|gmaxwell|if users complain that they can't set a different default we'll deal with that then, but I don't expect it.
530 2017-12-21 19:51:16	0|luke-jr|why not just let -walletrbf continue to work, but have the new defaults only affect when it's unset?
531 2017-12-21 19:51:24	0|wumpus|luke-jr: it will continue to work
532 2017-12-21 19:51:31	0|wumpus|for the RPC
533 2017-12-21 19:51:34	0|luke-jr|wumpus: I mean for both
534 2017-12-21 19:51:37	0|wumpus|any other topics?
535 2017-12-21 19:51:48	0|wumpus|luke-jr: using the same setting with different default in different places was *ugly*
536 2017-12-21 19:52:01	0|provoostenator|^
537 2017-12-21 19:52:14	0|provoostenator|That was actually what I did in the first version, but it's confusing.
538 2017-12-21 19:52:24	0|gmaxwell|the 'implementation defined behavior when not set' should be used very sparingly.
539 2017-12-21 19:52:29	0|provoostenator|Making it clear that -walletrbf has no bearing on the GUI (including it's default) seems better.
540 2017-12-21 19:52:31	0|luke-jr|IMO the ugliness only comes from having two defaults, not from having a common setting
541 2017-12-21 19:52:42	0|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
542 2017-12-21 19:52:48	0|provoostenator|I'll push that after the meeting.
543 2017-12-21 19:52:57	0|jonasschnelli|Thanks provoostenator!
544 2017-12-21 19:52:58	0|gmaxwell|In general we should probably not have config file setting for GUI checkboxes that stare the user in the face.
545 2017-12-21 19:53:06	0|provoostenator|Remind me not to make changes to defaults too often :-)
546 2017-12-21 19:53:09	0|gmaxwell|if the GUI wants a persistant default it should be changable from the GUI.
547 2017-12-21 19:53:14	0|meshcollider|Which I am trying to work on at the moment :)
548 2017-12-21 19:53:18	0|jonasschnelli|provoostenator: hah... these are the worst. :)
549 2017-12-21 19:53:18	0|luke-jr|gmaxwell: via rwconf ;)
550 2017-12-21 19:53:21	0|gmaxwell|But hopefully we won't need a changable persistant default for this.
551 2017-12-21 19:53:51	0|wumpus|right
552 2017-12-21 19:53:53	0|jtimon|the rbf checkbox doesn't appear with every tx?
553 2017-12-21 19:54:04	0|provoostenator|luke-jr: rwconf?
554 2017-12-21 19:54:18	0|wumpus|jtimon: isn't it always there?
555 2017-12-21 19:54:20	0|meshcollider|jtimon: what?
556 2017-12-21 19:54:21	0|gmaxwell|provoostenator: code to allow the conf file to be rewritten by setting changes at runtime.
557 2017-12-21 19:54:23	0|luke-jr|provoostenator: lets the GUI change config file settings
558 2017-12-21 19:54:33	0|wumpus|please, no scope creep
559 2017-12-21 19:54:39	0|gmaxwell|that was just a tangent.
560 2017-12-21 19:54:44	0|gmaxwell|not scope creep. :)
561 2017-12-21 19:54:56	0|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?
562 2017-12-21 19:55:18	0|gmaxwell|I was just expressing the principle that controlling GUI defaults via non-gui accessable settings is just not very good.
563 2017-12-21 19:55:24	0|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
564 2017-12-21 19:55:32	0|wumpus|it would add another bitcoin.conf, bitcoin_rw.conf, which can be written by the software itself
565 2017-12-21 19:55:45	0|provoostenator|gmaxwell: indeed, also not very easy to launch QT with flags on OSX.
566 2017-12-21 19:55:53	0|gmaxwell|I know, we could save the users settings ON THE BLOCKCHAIN
567 2017-12-21 19:56:04	0|meshcollider|jtimon: yep that's basically what this is doing
568 2017-12-21 19:56:08	0|wumpus|hehehe, settings delta chain
569 2017-12-21 19:56:10	0|sipa|gmaxwell: woah!
570 2017-12-21 19:56:44	0|meshcollider|lol
571 2017-12-21 19:56:51	0|wumpus|gmaxwell: I"m surprised that no *coin project commits git diffs to the blockchain yet
572 2017-12-21 19:56:56	0|jtimon|meshcollider: then I don't understand the -walletrbf discussion, but it's fine
573 2017-12-21 19:57:02	0|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!
574 2017-12-21 19:57:12	0|provoostenator|Some people use opentimestamps for that
575 2017-12-21 19:57:24	0|provoostenator|The git integration thing.
576 2017-12-21 19:57:33	0|achow101|wumpus: there's definitely a Core commit diff somewhere on the blockchain
577 2017-12-21 19:57:33	0|meshcollider|jtimon: the walletrbf discussion is about whether that parameter should affect the GUI default or only the RPC I believe
578 2017-12-21 19:57:34	0|wumpus|or even better, just commit javascript code for the GUI to the block chain
579 2017-12-21 19:57:42	0|wumpus|:')
580 2017-12-21 19:57:48	0|achow101|I found it once, but don't know where it is
581 2017-12-21 19:58:06	0|wumpus|achow101: oh! which one?
582 2017-12-21 19:58:19	0|wumpus|it'd certainly create incentive to make patches small
583 2017-12-21 19:58:24	0|achow101|wumpus: I don't quite remember
584 2017-12-21 19:58:57	0|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.
585 2017-12-21 19:58:58	0|meshcollider|wumpus: heh why just the GUI, entire new versions of core could be downloaded directly from the blockchain too!
586 2017-12-21 19:59:09	0|wumpus|no one would submit a diff-all-over-the-place PR if it costs >300 sat/byte
587 2017-12-21 19:59:29	0|wumpus|meshcollider: yes of course, updates to the consensus algo too :')
588 2017-12-21 19:59:30	0|sipa|wumpus: do you get a refund for deleted lines?
589 2017-12-21 19:59:35	0|wumpus|sipa: yes!
590 2017-12-21 19:59:36	0|provoostenator|Unless they want to show off their wealth as an offering...
591 2017-12-21 19:59:37	0|meshcollider|jtimon: yep exactly
592 2017-12-21 19:59:38	0|jtimon|meshcollider: that would be great to make sure everyone upgrades before a hf :p
593 2017-12-21 19:59:45	0|sipa|wumpus: brb, deleting all the tests
594 2017-12-21 19:59:54	0|wumpus|sipa: but only if accepted :-)
595 2017-12-21 19:59:58	0|luke-jr|wumpus: you're going to give my children nightmares
596 2017-12-21 19:59:59	0|sipa|oh.
597 2017-12-21 20:00:05	0|sipa|DONG
598 2017-12-21 20:00:09	0|lightningbot|Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-12-21-19.01.log.html
599 2017-12-21 20:00:09	0|lightningbot|Meeting ended Thu Dec 21 20:00:08 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
600 2017-12-21 20:00:09	0|lightningbot|Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-12-21-19.01.html
601 2017-12-21 20:00:09	0|lightningbot|Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-12-21-19.01.txt
602 2017-12-21 20:00:09	0|wumpus|#endmeeting
603 2017-12-21 20:00:11	0|wumpus|luke-jr: uh oh
604 2017-12-21 20:00:18	0|achow101|I forgot there was a meeting today..
605 2017-12-21 20:00:18	0|jonasschnelli|cfields: chainsettingsalytics?
606 2017-12-21 20:00:40	0|meshcollider|achow101: at least you made it for the end ;)
607 2017-12-21 20:00:52	0|cfields|jonasschnelli: for tracking and selling on-chain user settings, of course
608 2017-12-21 20:01:05	0|jtimon|-forceautoupgradeonversionsolderthanthisoption
609 2017-12-21 20:01:07	0|cfields|jonasschnelli: you happen to have git revisions for good/broken gitian builds?
610 2017-12-21 20:01:10	0|sipa|achow101: you should make the blockchain remind you
611 2017-12-21 20:01:17	0|achow101|sipa: lol
612 2017-12-21 20:01:21	0|jonasschnelli|cfields: let me check
613 2017-12-21 20:01:33	0|cfields|thanks
614 2017-12-21 20:01:48	0|jonasschnelli|Good: 38d31f95
615 2017-12-21 20:01:54	0|jonasschnelli|Broken: 13e31dd6
616 2017-12-21 20:01:54	0|jtimon|sipa: can you even program a smart contract alarm without turing completeness? :p
617 2017-12-21 20:01:56	0|jonasschnelli|Happy bisect
618 2017-12-21 20:02:19	0|achow101|in other unrelated news, I finally got around to simulating the branch and bound coin selection stuff
619 2017-12-21 20:02:19	0|cfields|perfect! thanks :)
620 2017-12-21 20:04:32	0|jtimon|alright, I'm going to go try that savemempool rpc...
621 2017-12-21 20:07:49	0|jonasschnelli|jtimon: why?
622 2017-12-21 20:08:01	0|gmaxwell|achow101: and?
623 2017-12-21 20:08:07	0|wumpus|FYI you can only save to the default file, it doesn't take a filename argument
624 2017-12-21 20:08:11	0|achow101|gmaxwell: it's taking a long time
625 2017-12-21 20:08:43	0|achow101|I'm looking at some results right now and I'll add a comment to the PR with them
626 2017-12-21 20:11:25	0|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
627 2017-12-21 20:13:06	0|spence|Is there a roadmap for integrating segwit better into Core?  Gui, etc...
628 2017-12-21 20:13:31	0|gmaxwell|it'll be in the next release.
629 2017-12-21 20:16:33	0|wumpus|#11403
630 2017-12-21 20:16:43	0|gribble|https://github.com/bitcoin/bitcoin/issues/11403 | SegWit wallet support by sipa · Pull Request #11403 · bitcoin/bitcoin · GitHub
631 2017-12-21 20:20:43	0|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?
632 2017-12-21 20:20:52	0|contrapumpkin|oh sorry, wrong channel
633 2017-12-21 20:21:05	0|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/
634 2017-12-21 20:21:55	0|achow101|provoostenator: congrats!
635 2017-12-21 20:23:29	0|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
636 2017-12-21 20:23:43	0|jonasschnelli|ah
637 2017-12-21 20:24:47	0|sipa|provoostenator: congratulations
638 2017-12-21 20:24:50	0|sipa|very happy to see that
639 2017-12-21 20:25:23	0|jonasschnelli|provoostenator: Oh. Nice! Well done.
640 2017-12-21 20:25:45	0|wumpus|provoostenator: great!
641 2017-12-21 20:26:20	0|jimpo|Just out of curiousity, why is much of the secp256k1 code in _impl.h header files instead of .c files?
642 2017-12-21 20:27:06	0|wumpus|jimpo: optimization, scope for inlining, as well as making it easy to add secp256k1 to a project by just adding one .c file
643 2017-12-21 20:28:16	0|jtimon|provoostenator: cool, great news
644 2017-12-21 20:32:48	0|meshcollider|🎉
645 2017-12-21 20:32:50	0|cfields|provoostenator: congrats!
646 2017-12-21 20:33:47	0|zelest|how much of self-torture will I have to live through to get bitcoin running on OpenBSD? :)
647 2017-12-21 20:33:49	0|provoostenator|Thanks! Also, updated #11605 (but do check carefully, it's a bit late here...)
648 2017-12-21 20:33:52	0|gribble|https://github.com/bitcoin/bitcoin/issues/11605 | [Wallet] Enable RBF by default in QT by Sjors · Pull Request #11605 · bitcoin/bitcoin · GitHub
649 2017-12-21 20:39:17	0|cfields|zelest: there are freshly updated docs for that
650 2017-12-21 20:39:48	0|cfields|wumpus self-tortured himself so you wouldn't have to
651 2017-12-21 20:41:01	0|wumpus|cfields: well we didn't update the docs yet for openbsd 6.2, just the bdb building tool
652 2017-12-21 20:41:15	0|wumpus|although the current instructions should work
653 2017-12-21 20:41:24	0|cfields|oh, i thought that was all that was needed
654 2017-12-21 20:41:58	0|wumpus|the docs could be really simplified because openbsd 6.2 includes clang, it currently tells to install either clang or a newer gcc
655 2017-12-21 20:42:19	0|wumpus|openbsd 6.2's built-in compiler can build bitcoin core :)
656 2017-12-21 20:42:25	0|cfields|ah right
657 2017-12-21 20:42:28	0|cfields|nice
658 2017-12-21 20:43:09	0|cfields|wonder what obsd would've done without clang.
659 2017-12-21 20:44:21	0|wumpus|dunno either, could hardly have sticked with gcc 4.2 forever
660 2017-12-21 20:46:41	0|wumpus|zelest: so basically: append CC=cc CXX=c++ to the contrib/install_db4.sh and configure commands
661 2017-12-21 20:47:12	0|wumpus|so that it will use clang and not the gcc 4.2, which for some reason is still installed
662 2017-12-21 20:48:14	0|wumpus|(or maybe that's because my openbsd box was upgraded from $OLD_VERSION)
663 2017-12-21 20:48:45	0|cfields|it switched your default cc/c++ after an upgrade?
664 2017-12-21 20:49:38	0|wumpus|it didn't use to have cc/c++, just gcc/g++
665 2017-12-21 20:49:52	0|cfields|ah
666 2017-12-21 20:50:29	0|wumpus|and by default, most build systems will pick gcc over cc
667 2017-12-21 20:50:31	0|cfields|yikes, though. buildsystems do all kinds of combinations of checks for cc/gcc
668 2017-12-21 20:50:41	0|cfields|stupid cmake, for example, uses cc/c++
669 2017-12-21 20:51:25	0|wumpus|I should try installing an openbsd 6.2 from scratch and see if it has only clang, that'd make more sense
670 2017-12-21 20:52:00	0|wumpus|g++ and c++ have an incompatible abi so ou're right that it cause all kind of pain
671 2017-12-21 20:52:01	0|cfields|or gcc -> cc
672 2017-12-21 20:52:08	0|cfields|that's what macos does
673 2017-12-21 20:52:36	0|wumpus|yes the same command line interface anyway
674 2017-12-21 20:53:40	0|cfields|10% unrelated: gcc is able to build in a chroot with only binutils/gmake/previous gcc/libc/kernel headers.
675 2017-12-21 20:54:08	0|cfields|cmake, however, is the first to require a whole mess of libs :(
676 2017-12-21 20:54:19	0|wumpus|what do we need cmake for?
677 2017-12-21 20:54:26	0|cfields|clang
678 2017-12-21 20:54:26	0|wumpus|it's mostly used for graphical stuff right?
679 2017-12-21 20:54:30	0|wumpus|oh
680 2017-12-21 20:54:46	0|cfields|so no avoiding it as part of the early build process, i'm afraid
681 2017-12-21 20:55:46	0|wumpus|clang is cmake only now?
682 2017-12-21 20:55:59	0|wumpus|Ithought it had an autoconf based build as well
683 2017-12-21 20:56:06	0|cfields|not sure if it is for 5.0, but if not, the autotools is heavily deprecated
684 2017-12-21 20:56:17	0|wumpus|ah yes you're right
685 2017-12-21 20:56:39	0|wumpus|I see I also switched my clang configuration script to cmake at some point, apparently without remembering
686 2017-12-21 20:56:52	0|cfields|heh
687 2017-12-21 20:57:04	0|cfields|well it's probably not all that different if you're using all system paths
688 2017-12-21 20:58:12	0|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
689 2017-12-21 20:58:18	0|wumpus|well it's not as bad as some cross-compiles...
690 2017-12-21 21:02:04	0|zelest|wumpus, Ah, awesome! thanks :)
691 2017-12-21 21:49:36	0|zelest|wumpus, boo! the compile blew up P
692 2017-12-21 21:49:37	0|zelest|:P
693 2017-12-21 21:50:30	0|wumpus|with what?
694 2017-12-21 21:50:36	0|zelest|https://pastebin.com/0WLsNR7j
695 2017-12-21 21:51:18	0|wumpus|zelest: what version are you building?
696 2017-12-21 21:51:49	0|wumpus|and you did do contrib/install_db4.sh CC=cc CXX=c++ ?
697 2017-12-21 21:52:17	0|wumpus|this happens when dbc++ was built with a different compiler than bitcoind
698 2017-12-21 21:53:39	0|zelest|wumpus, 0.15.1 and yeah.. and no, I used CC=egcc CXX=eg++ CPP=ecpp :o
699 2017-12-21 21:53:59	0|sipa|what version of gcc is that?
700 2017-12-21 21:54:10	0|zelest|4.2.1
701 2017-12-21 21:54:32	0|zelest|i did however run ./configure with CC=cc and CXX=c++
702 2017-12-21 21:54:41	0|sipa|that won't work
703 2017-12-21 21:54:45	0|sipa|you need gcc 4.7
704 2017-12-21 21:56:03	0|wumpus|zelest: 0.15.1 doesn't have the necessary patch, unfortunately that install_db4.sh  ignores arguments
705 2017-12-21 21:56:10	0|zelest|oh
706 2017-12-21 21:56:40	0|wumpus|this was fixed on master yesterday with #11945
707 2017-12-21 21:56:41	0|gribble|https://github.com/bitcoin/bitcoin/issues/11945 | Improve BSD compatibility of contrib/install_db4.sh by laanwj · Pull Request #11945 · bitcoin/bitcoin · GitHub
708 2017-12-21 21:56:49	0|wumpus|you could probably just copy the file from there
709 2017-12-21 21:57:02	0|zelest|wumpus, can I compile master? (i saw build:failed on there, hence me picking 0.15.1)
710 2017-12-21 21:57:07	0|wumpus|https://raw.githubusercontent.com/laanwj/bitcoin/2712742ef2947feef4a142f7d1360d1e821597dc/contrib/install_db4.sh
711 2017-12-21 21:57:08	0|zelest|ah
712 2017-12-21 21:57:18	0|wumpus|sure, you can build master
713 2017-12-21 21:57:46	0|zelest|oh yeah, the link in build-openbsd.md is wrong btw
714 2017-12-21 21:57:49	0|zelest|it 404s
715 2017-12-21 21:57:53	0|wumpus|but thanks for reminding me it needs a backport label
716 2017-12-21 21:58:15	0|wumpus|which link?
717 2017-12-21 21:59:50	0|wumpus|anyhow that's likely fixed on master too
718 2017-12-21 21:59:51	0|zelest|https://github.com/bitcoin/bitcoin/blob/master/doc/build-openbsd.md the "the installation script included in contrib/" under Building Berkley DB
719 2017-12-21 22:00:18	0|zelest|BerkeleyDB*
720 2017-12-21 22:03:33	0|bitcoin-git|[13bitcoin] 15laudaa opened pull request #11976: [Doc] Fix link to installation script (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/11976
721 2017-12-21 22:03:49	0|Lauda|Sorry, we missed that one
722 2017-12-21 22:03:58	0|wumpus|apparently Lauda in #11960 fixed that in all files except build-openbsd.md in
723 2017-12-21 22:03:59	0|gribble|https://github.com/bitcoin/bitcoin/issues/11960 | [Doc] Fix link to installation script by laudaa · Pull Request #11960 · bitcoin/bitcoin · GitHub
724 2017-12-21 22:06:03	0|zelest|no love for OpenBSD :(
725 2017-12-21 22:09:19	0|Emcy|!topic
726 2017-12-21 22:09:20	0|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/
727 2017-12-21 22:09:34	0|Emcy|when are the meetings? weekly?
728 2017-12-21 22:09:51	0|Lauda|Yes
729 2017-12-21 22:09:59	0|wumpus|19:00-20:00 UTC Thursdays, you just missed one
730 2017-12-21 22:10:25	0|Emcy|ok
731 2017-12-21 22:27:15	0|zelest|wumpus, yeah, failed even with those CC flags
732 2017-12-21 22:27:19	0|zelest|oh well
733 2017-12-21 22:29:25	0|Emcy|0.16 i branching soon. nice.
734 2017-12-21 22:29:34	0|wumpus|zelest: so you used the new version of install_db4.sh?
735 2017-12-21 22:29:38	0|zelest|yeah
736 2017-12-21 22:29:43	0|Emcy|and segwit gui is getting merged
737 2017-12-21 22:29:55	0|wumpus|zelest: ok, no clue in that case, it worked for me
738 2017-12-21 22:30:14	0|zelest|wumpus, i'm using -current though, might affecting it.. *shrugs*
739 2017-12-21 22:30:32	0|zelest|also had it running back in 6.1
740 2017-12-21 22:31:08	0|zelest|wumpus, thanks for all the help though :)
741 2017-12-21 22:32:28	0|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
742 2017-12-21 22:32:42	0|wumpus|zelest: if not, you get linker errors, due to ABI mismatch
743 2017-12-21 22:34:41	0|zelest|hmms..
744 2017-12-21 22:34:48	0|Guest99499|How can 4 btc come out of my wallet and I did not send anything
745 2017-12-21 22:35:45	0|Guest99499|It was  several different transactions with the same address going out is it rerouting
746 2017-12-21 22:36:00	0|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. :)
747 2017-12-21 22:36:08	0|Guest99499|Will it come back to my Wallet
748 2017-12-21 22:36:33	0|sipa|Guest99499: #bitcoin
749 2017-12-21 22:36:35	0|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
750 2017-12-21 22:36:41	0|sipa|Guest99499: or https://bitcoin.stackexchange.com
751 2017-12-21 22:36:59	0|zelest|wumpus, ah, true
752 2017-12-21 22:37:33	0|Guest99499|So there's nothing to worry about it will come back to my wallet
753 2017-12-21 22:37:45	0|sipa|Guest99499: not here.
754 2017-12-21 22:39:43	0|Guest99499|How can I get my missing btc back in my wallet  Who authorized to take it out
755 2017-12-21 22:41:39	0|Guest99499|Has anybody else had the same problem
756 2017-12-21 22:44:17	0|wumpus|Guest99499: #bitcoin please
757 2017-12-21 22:44:23	0|sipa|Guest99499: last warning, not here. this channel is for development, not support
758 2017-12-21 23:00:00	0|talha_|hi
759 2017-12-21 23:04:50	0|bitcoin-git|[13bitcoin] 15theuni opened pull request #11981: Fix gitian build after libzmq bump (06master...06fix-gitian-build) 02https://github.com/bitcoin/bitcoin/pull/11981
760 2017-12-21 23:13:55	0|talha_|any fork expert here?
761 2017-12-21 23:14:40	0|wumpus|that's off topic here
762 2017-12-21 23:34:30	0|talha_|whats the topic here?
763 2017-12-21 23:36:48	0|zelest|wumpus, heh, who needs sleep.. :D removed both trees and started over. seems to be compiling now.. \o/
764 2017-12-21 23:45:03	0|meshcollider|talha_: topic here is development of bitcoin core, not any other software or forks