--- Day changed Thu Nov 19 2015
00:09 -!- CodeShark [uid126576@gateway/web/irccloud.com/x-bezmkwimjnhmlgic] has joined #bitcoin-core-dev
00:13 -!- tulip [~tulip@128.199.135.43] has quit []
00:18 < GitHub1> [bitcoin] jonasschnelli pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/73fa5e604356...15765df3521b
00:18 < GitHub1> bitcoin/master bd42e6b Michael Ford: [doc] Users now see 'Bitcoin Core' in the OSX bundle...
00:18 < GitHub1> bitcoin/master 15765df Jonas Schnelli: Merge pull request #7041...
00:18 < GitHub73> [bitcoin] jonasschnelli closed pull request #7041: [doc][trivial] Update OS X install instructions (master...patch-5) https://github.com/bitcoin/bitcoin/pull/7041
00:23 < jonasschnelli> wumpus: if you provide / pastebin your bitcoin-win-0.12-build.assert somewhere I can check the packages.
00:23 < jonasschnelli> even the bitcoin-0.11.99.tar.gz doesn't match (against the hashes you have posted)
00:24 < jonasschnelli> i only compared against your hashes, not against another build
00:24 < wumpus> if you upload the files, I'll compare them
00:25 < wumpus> the source archive doesn't match either? that's (ruling out tar nondeterminism issues) almost certain indication that it was the wrong source code that was built :)
00:26 < jonasschnelli> wumpus: yeah.. i have though this also. But: git:b08293544a207088193de8834bb754f5d212c9bf bitcoin
00:26 < jonasschnelli> Can you compare: b8affff612d645598a4642dcc4eef7d4974c02d73c31a99ba2faa36425142aca  bitcoin-win-0.12-desc.yml?
00:27 < wumpus> so when I follow your link I see
00:27 < wumpus>     67c3bc85ece1ad2905a7f801277fbd76d1e7ac653ad2e021cd7fadf1fa6a6307  src/bitcoin-0.11.99.tar.gz MATCH
00:27 -!- tulip [~tulip@128.199.135.43] has joined #bitcoin-core-dev
00:28 < wumpus> 7fd5e22a794a6fa34defe0cd0e82d8f0ad759fba73e190aa5bd202627fa45bc5  bitcoin-0.11.99-win-unsigned.tar.gz MATCH
00:28 < wumpus> they all match to my hashes
00:29 < jonasschnelli> grml...
00:29 < jonasschnelli> right. They match. I compared against the wrong file...
00:29 < wumpus> I don't have the yml anymore so can't check that one :(
00:29 < wumpus> but it's just the hash of the hashes, so should be the same
00:30 < jonasschnelli> Nice to see this working!
00:31 < wumpus> let's hear from fanquake if he gets the same
00:32 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
00:35 -!- molly [~molly@unaffiliated/molly] has quit [Read error: Connection reset by peer]
00:38 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev
00:48 -!- tulip [~tulip@128.199.135.43] has quit []
00:49 < jonasschnelli> paveljanik: "Maybe his screenshot is from the same code from which you did the screenshot." -> could be, but github does not show a push in between (chronologically)
00:50 < paveljanik> yes
00:50 < paveljanik> But I think it is RtM now
00:50 < wumpus> yes, would make sense to make a custom out of providing the current HEAD commit that our comments are about
00:53 < Luke-Jr> wumpus: wait, you have gitian integrated in your browser?
00:53 < wumpus> I don't think so :)
00:54 < Luke-Jr> so the "MATCH" wasn't part of what you saw there? aww
00:55 < wumpus> no I added that part myself - yea, disappointing :)
01:00 -!- guest234234 [~guest2342@223.207.232.28] has quit [Read error: Connection reset by peer]
01:01 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-tqooqtiqdlldfrlu] has joined #bitcoin-core-dev
01:05 -!- tulip [~tulip@128.199.135.43] has joined #bitcoin-core-dev
01:12 < GitHub169> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/15765df3521b...f8e87d74c9b7
01:12 < GitHub169> bitcoin/master c5f211b fanquake: [doc][trivial] Remove miniupnpc build notes build-unix
01:12 < GitHub169> bitcoin/master f8e87d7 Wladimir J. van der Laan: Merge pull request #7048...
01:12 < GitHub128> [bitcoin] laanwj closed pull request #7048: [doc][trivial] Remove miniupnpc build notes from build-unix (master...miniupnpc-build-unix) https://github.com/bitcoin/bitcoin/pull/7048
02:33 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving]
02:56 -!- MarcoFalke [8af6027e@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.126] has joined #bitcoin-core-dev
03:20 -!- rubensayshi [~ruben@91.206.81.13] has joined #bitcoin-core-dev
03:23 -!- arowser [~quassel@106.120.101.38] has quit [Quit: No Ping reply in 180 seconds.]
03:23 -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-core-dev
03:28 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Quit: Leaving.]
03:52 < GitHub102> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f8e87d74c9b7...a1907772f021
03:52 < GitHub102> bitcoin/master b4f3e9c Wladimir J. van der Laan: ui: Add "Copy raw transaction data" to transaction list context menu...
03:52 < GitHub102> bitcoin/master a190777 Wladimir J. van der Laan: Merge pull request #7051...
03:52 < GitHub180> [bitcoin] laanwj closed pull request #7051: ui: Add "Copy raw transaction data" to transaction list context menu (master...2015_11_transaction_hex2) https://github.com/bitcoin/bitcoin/pull/7051
03:59 < GitHub39> [bitcoin] laanwj pushed 1 new commit to master: https://github.com/bitcoin/bitcoin/commit/52c563710ddd80a90c58205e866a42b01887ab63
03:59 < GitHub39> bitcoin/master 52c5637 Wladimir J. van der Laan: qt: Periodic translations update
04:02 < GitHub150> [bitcoin] laanwj pushed 6 new commits to master: https://github.com/bitcoin/bitcoin/compare/52c563710ddd...c983d6fcb47b
04:02 < GitHub150> bitcoin/master 9f251b7 Wladimir J. van der Laan: devtools: add libraries for bitcoin-qt to symbol check...
04:02 < GitHub150> bitcoin/master 0b416c6 Wladimir J. van der Laan: depends: qt PIDLIST_ABSOLUTE patch...
04:02 < GitHub150> bitcoin/master 2e31d74 Wladimir J. van der Laan: gitian: use trusty for building
04:02 < GitHub117> [bitcoin] laanwj closed pull request #6900: gitian: build on ubuntu 14.04 (master...2015_10_gitian_trusty) https://github.com/bitcoin/bitcoin/pull/6900
04:07 < MarcoFalke> wumpus, when will translations close?
04:08 < wumpus> translations never close, there will be a string freeze after Dec 1 though, to prevent translation strings being changed in the source code and thus giving translators time to catch up
04:09 < wumpus> translations from transifex will be merged up until the last rc
04:09 < MarcoFalke> ok
04:13 < GitHub9> [bitcoin] laanwj opened pull request #7060: doc: Make networking work inside builder in gitian-building.md (master...2015_11_gitian_building) https://github.com/bitcoin/bitcoin/pull/7060
04:19 -!- MarcoFalke [8af6027e@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.126] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
04:20 -!- MarcoFalke [8af6027e@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.126] has joined #bitcoin-core-dev
04:21 -!- jtimon [~quassel@74.29.134.37.dynamic.jazztel.es] has quit [Read error: Connection reset by peer]
04:42 < MarcoFalke> wumpus, about the "all fees in bitcoin core are per kB" thing:
04:42 < MarcoFalke> Do you think 6708 should go into .12?
04:44 < wumpus> MarcoFalke: I think so, but needs more review/testing
05:06 -!- PaulCape_ [~PaulCapes@204.28.124.82] has quit [Quit: .]
05:07 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-core-dev
05:32  * jonasschnelli wonder what why we have the "Pay only the required fee of 0.00001000 BTC/kB" in the UI
05:33 < wumpus> that's the -mintxfee I think?
05:33 < jonasschnelli> std::max(mintxfee, minrelayfee)
05:34 < jonasschnelli> but it's somehow wrong. "required fee" is a misleading term.
05:34 < wumpus> I agree that it is misleading
05:35 < wumpus> 'required' by whom, for what. It no longer makes sense now that all fee thresholds are going dynamic
05:36 < jonasschnelli> And one line above, you can select fee: [ ] per Kilobyte [ ] total at least [____ amount ___]?
05:36 < jonasschnelli> So somehow i think we should entirely remove fPayAtLeastCustomFee together with the GUI line.
05:36 < MarcoFalke> > 'required' by whom
05:37 < MarcoFalke> Required by mempool and the node operator
05:37 < MarcoFalke> GetMinimumFee() however takes also into account current network conditions
05:37 < jonasschnelli> I think either you go for the "Recommended" fee (estimation) or you choose a custom fee (per KB or absolute).
05:37 < jonasschnelli> Even there, does an absolute fee make sense?
05:38 < wumpus> absolute makes no sense
05:38 < jonasschnelli> What if your transaction has 20 ins and outs?
05:38 < wumpus> needs to be per kB
05:39 < wumpus> but I agree that you either want bitcoin core to choose a fee for you (estimate confirm within # confirmations) or you want to set a fee/kB, which should be above what your mempool accepts at all
05:39 < MarcoFalke> I think the only reason we have this is that there were some lazy unit test writers
05:40 < jonasschnelli> the software should not follow the unit/rpc tests. Should be the other way around. :)
05:40 < MarcoFalke> "Let's just assume every transaction is 1000 bytes and less, so we can hard code the balance asserts"
05:40 < jonasschnelli> I agree that test with fees are difficult and break easily, but this can't be a reason to not make changes.
05:42 < MarcoFalke> * Forgot to eat lunch, gone now.
05:42 < jonasschnelli> hmm... maybe users will complain that they can set an absolute fee (if we remove that feature).
05:43 < jonasschnelli> If absolute fees are possible, they should be hidden behind CoinControl feature (or similar expert setting)
05:43 < wumpus> they can't set an absolute fee can they?
05:43 < wumpus> you can't know the size of the transaction in advance so what point is it?
05:43 < wumpus> it'd require you to second-guess the input selection knapsack algorithm
05:44 < jonasschnelli> The ui says custom fee [ ]    --- [ ] per KB , [ ] total at least   ______ <- (amount)
05:44  * jonasschnelli is checking the code
05:44 < wumpus> (exeapt in the case of coin control where you choose inputs yourself, but in that case you know the ~size of the transaction so you could just as well set per kB)
05:45 < wumpus> jonasschnelli: crazy! never really paid attention to that
05:45 < jonasschnelli> wumpus: me too ... :)
05:49 < sipa> jonasschnelli: i find strprintf far more readable generally than "a" + b + "c" :)
05:50 < sipa> (and that's all i'll say about the topic)
05:51 < jonasschnelli> sipa: Yes. It's better readable. I Agree,... i don't want to microoptimize that stuff, but i normally try to avoid printf when it's just appending strings.
05:51 < jonasschnelli> But probably only matters if your on an embedded system and calling the printf a LOT
05:52 < sipa> a + b + c may actually be less efficient than strprintf("%s%s%s") for large strings, as the first operation needs to allocate a new string twice, and copy the contents of a 2 times
05:52 < wumpus> yeah... and in that case you probably don't want to be processing strings in the critical path a t all 
05:52 < sipa> and that ^
05:53 < jonasschnelli> agreed. For sure it's okay in the Luke-Jr PR. I regret bringing up this point... :)
05:56 < wumpus> you're right that strprintf isn't terribly efficient, its goals are compatibility with sprintf (which was used before, so there wasn't impact on all debug messages) and type-safety
05:56 < sipa> i've never benchmarked it :)
05:57 < wumpus> tinyformat's github page has some benchmarks
05:57 < wumpus> but yeah if its performance matters you're doing something wrong :)
05:57 < sipa> agree there
05:58 < jonasschnelli> "but yeah if its performance matters you're doing something wrong" <- that's a good point
05:59 < wumpus> (e.g. LogPrint has a shortcut to avoid calling tinyformat at all if the message is not being logged)
06:01 < instagibbs> wumpus, can we confirm user-oriented scripts go in 'share'? I can't glean the intent of the folder by its contents unfortunately
06:01 < instagibbs> there are some images, certs, etc
06:01 < wumpus> instagibbs: to be really sure you should ask cfields_
06:01 < instagibbs> cfields_, *ping*
06:02 < wumpus> user oriented scripts need to be installed, which means they should go into a directory that's normally part of the tarball, as well as added to the 'make install'
06:02 < wumpus> which reminds me, the man pages need that too
06:02 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
06:03 -!- MarcoFalke [8af6027e@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.126] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
06:06 < wumpus> contrib/ is for examples and such, as well as things only necessary during development
06:09 -!- Amnez777 [~Amnez777@unaffiliated/amnez777] has joined #bitcoin-core-dev
06:43 < morcos> wumpus: if we are to have a string freeze by Dec 1st.  We really need to solve the UI problem of how to report to user and deal with txs that have been evicted from the mempool.
06:46 -!- CodeShark [uid126576@gateway/web/irccloud.com/x-bezmkwimjnhmlgic] has quit [Ping timeout: 252 seconds]
06:46 -!- zmanian_ [sid113594@gateway/web/irccloud.com/x-nhhpsseihgioqkpd] has quit [Ping timeout: 246 seconds]
06:46 < morcos> dgenr8 had some comments on 6871 on what this functionality should look like.  I think we should probalby try to agree on that design, and hopefully it won't be too hard to implement.
06:47 -!- btcdrak [uid115429@gateway/web/irccloud.com/x-nimlgqombgnllegr] has quit [Ping timeout: 247 seconds]
06:48 < morcos> In particular, if you have a non-optin-for-replacement tx that has been removed from your mempool.  Does it make sense for their to be an option to manually release the inputs for double spending?  It seems relatively likely to me that just rebroadcasting the original tx isn't going to be that helpful unless you can send it directly to a miner who will prioritize
06:49 < morcos> However if we want to keep the closest to the existing behavior, then perhaps we do not allow that if you've not opted in for replacement.
06:50 < morcos> existing behavior I mean 0.11.  right now master will just let you respend it anyway.  but i think having it evicted from your mempool in 0.12 is the same thing as just having it sit forever at the bottom of your mempool in 0.11 which doesn't allow you to respend
06:52 < morcos> In the case that you have opted in for replacement, I suppose the question is if you want to replace it and its been evicted, are you stil required to follow the replacement rules?  This would be a lot of wallet code that hasn't been written.
06:53 < morcos> So I guess the answer to that is no.  Actually the wallet is not aware of whether you have opted in for replacement or not.  
06:54 < morcos> Anyway, the point is lets sketch out what the desired behavior is so someone can implement it.  But master as it exists now is a bit of a mess UI wise
06:54 -!- btcdrak [uid115429@gateway/web/irccloud.com/x-jwyhpappcdgxcqov] has joined #bitcoin-core-dev
06:55 -!- CodeShark [uid126576@gateway/web/irccloud.com/x-mluizvxgwdnddpbi] has joined #bitcoin-core-dev
07:01 < morcos> sipa: do you think we should have some kind of configuration warning/check if someone had a config file with maxsigcachesize=100000 or something
07:05 -!- aburan28 [~xypher@static-108-45-93-78.washdc.fios.verizon.net] has joined #bitcoin-core-dev
07:05 -!- zmanian_ [sid113594@gateway/web/irccloud.com/x-miwknbvlwmroihsw] has joined #bitcoin-core-dev
07:10 < GitHub68> [bitcoin] jonasschnelli opened pull request #7061: [Wallet] add rescanblockchain <height> RPC command (master...2015/11/wallet_rescan_rpc) https://github.com/bitcoin/bitcoin/pull/7061
07:10 < wumpus> morcos: a related problem is that with -walletbroadcast=0, transactions never enter the mempool at all
07:11 < wumpus> (well that's not a problem in itself, it's what it is supposed to be , but how it is shown is suboptimal)
07:15 < morcos> wumpus: hmm.. i wasn't aware of that, so do they also show as conflicted?
07:15 < wumpus> es
07:15 < wumpus> +y
07:16 -!- zooko [~user@c-71-237-69-190.hsd1.co.comcast.net] has joined #bitcoin-core-dev
07:17 < morcos> hmm.. putting aside the timline for how fast all this will be fixed
07:17 < morcos> what is the ideal behavior there
07:17 < morcos> is there a reason we don't put it in the mempool and just don't relay it?
07:17 < wumpus> privacy problems - you'll never request it
07:17 < morcos> ah, we're waiting for it to be relayed back to us?
07:17 < wumpus> the point of walletbroadcast=0 is to completely isolate the wallet from the node in one direction
07:18 < morcos> what do you mean you'll never request it? oh, right, what i jsut said
07:18 < morcos> hmm... ok, so in that case you'd want to ignore a child tx to that tx anyway until you saw the parent
07:19 < wumpus> also putting it into our own mempool can be a leak as the mempool can be requested through P2P
07:21 -!- tulip [~tulip@128.199.135.43] has quit []
07:21 < wumpus> the ideal behavior there would be to just trust that a transaction that you created yourself exists
07:21 < wumpus> e.g. 'created but not yet seen on network'
07:22 < wumpus> entirely ideally there would be a way to delete it again, if you decide not to broadcast it at all
07:22 < morcos> yeah i suppose, but then you get into the question of whether you want to predict whether it had been evicted or not?
07:23 < morcos> i suppose the simple version of that is you expect to see it within a certain amount of time as you tell the wallet it should be on the network now
07:23 < wumpus> I don't think that really matters in the walletbroadcast=0 case, it assumes that the user will manage the transaction and somehow getting it to the network/miner themselves
07:24 < wumpus> the client does not need to care about it anymore, it will either eventually see it relayed on the network, or see it appear in a block
07:25 < morcos> Yes I think the real questions is when to mark inputs as freed for respending by automatic coin selection
07:25 < wumpus> doesn't need to be within a certain time either - it could have been submitted to a low-latency relay network that takes hours to release it somewhere
07:26 < wumpus> it shouldn't
07:26 < morcos> So right now when a tx is not in your mempool, they are marked as freed correct?
07:26 < wumpus> I think the behavior where a transaction exists but the inputs are reused is very strange
07:26 < morcos> (I'm talking about code I haven't looked at here btw)
07:27 < morcos> I think if we change the default to be that inputs are not marked as freed just b/c a tx does not appear in your mempool, and add a manual method of saying forget this tx, and ideally add detection for true conflicts which will also free the remaining unspent outputs
07:28 < wumpus> yes, but I think that's inadvertent. The -1 confirm handling was introduced when there were malleablity attacks, to prevent *conflicted* transactions from being counted
07:28 < morcos> Then maybe that covers all cases, and we just change the UI to say something other than conflicted except in the conflicted case
07:28 < wumpus> I'd love a manual way to say 'forget this tx'
07:28 < wumpus> currently the only way is to do -zapwallettxes on the command line which takes a long time as it does a rescan
07:29 < wumpus> but I think being allowed to delete unconfirmed transactions (certainly those that are not in the mempool) wouldn't hurt. There was a previous implementation but I think it was broken in case of dependent transactions.
07:30 < wumpus> sounds good
07:31 < morcos> Heh, I wasn't volunteering.  Actually I wouldn't mind, but I'm not going to be around.   
07:31 < morcos> But maybe we can point a handy volunteer to this little converation.
07:31 < wumpus> e.g. https://github.com/bitcoin/bitcoin/pull/3845   Add a method for removing a single wallet tx (rebased)
07:32 < wumpus> it was slated for 0.10 but there were too many issues with the implementation and no one picked it up again
07:33 < jgarzik> A lot of people would love a 'forget this tx'    +100
07:33 < sipa> can we just start by remembering in WalletTx whether accepttomempool failed
07:33 < sipa> (because conflict)
07:33 < sipa> if so, mark it as conflicted and spemdable again
07:33 < morcos> What I think we really need to do is set a minimum viable product for 0.12.  
07:33 < morcos> sipa: isn't that what happens now?
07:34 < sipa> if no, it's just 0 confirmed, not -1 confirmed
07:34 < sipa> morcos: no, now we check whether it is in the mempool, and if not, comsider it spendable
07:35 < sipa> (afaik, i haven't looked at the code in a long time)
07:38 < morcos> no -1, just tried it
07:38 < morcos> oh i misunderstood
07:39 < sipa> i thought that not in mempool == -1 comfirms == conflicted == respendable
07:39 < sipa> if not, you should ignore me
07:39 < wumpus> the wallet code gives me a headache. I tried to explain https://github.com/bitcoin/bitcoin/issues/7054 (Difference in getbalance and sum(listtransactions) amounts (testnet)) but failed
07:39 < wumpus> yes I think that's how it is sipa
07:39 < morcos> yes, that is what happens, what are you saying should happen
07:40 < sipa> morcos: make accepttomempool return whether all inputs were available or not
07:40 < sipa> morcos: if not, remember in the wallet that it should be considered conflicted/resoendable
07:40 < sipa> otherwise, just unconfirmed
07:41 < morcos> ok, but that doesn't make sense to me
07:41 < morcos> so it doesn't make it in b/c too low fee
07:41 < morcos> you don't want it to be respendable?
07:41 -!- MarcoFalke [8af6027e@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.126] has joined #bitcoin-core-dev
07:41 < morcos> i agree it should say something other than conflicted
07:41 < morcos> but the respendability should be the same if it never made it in in my opinion
07:42 < morcos> if it was in, and got evicted, then i think thats a different question, then it should not automatically be respendable
07:42 < morcos> or if you never tried to submit it
07:42 < sipa> right, if it wasn't accepted at all (and never broadcast) it should be respendable too
07:42 < sipa> but it's very hard to know whether it jever made it to the network
07:42 < sipa> peoppe may manually rebroadcast
07:42 < morcos> but if we're going to implement those features where now sometimes its not automatically respendable, we probably have to implment the forget function
07:45 < morcos> so what do we think is a reasonable goal for 0.12?   
07:46 < sipa> a remove function for unconfirmed transactions, and no longer looking at mempool to dexide conflictedness
07:46 < wumpus> +1 sipa
07:46 < jgarzik> +1 + mention @ meeting
07:46 < sipa> +1 jgarzik
07:47 < wumpus> though the feature freeze for 0.12 is in less than two weeks, so there is not much time
07:47 < jgarzik> The remove function will be very popular with users
07:48 < sipa> having the feature freeze so close to hongkong is inconvenient
07:49 < morcos> yeah sorry if i'm being a bit insistent on this, but the impending feature freeze is why i keep bringing this up.
07:50 < wumpus> yes, in general december is always an inconvenient month
07:50 < sipa> oh, we already have *pfMissingInputs in AcceptToMemoryPool
07:50 < wumpus> I don't want to plan the feature freeze during holidays either
07:50 < sipa> we could just remember that result
07:50 < morcos> sipa: so what happens if a tx is evicted
07:51 < sipa> morcos: it remain unconfirmed, but its accepttomemorypool succeeded, so we assume it can still confirm
07:51 < wumpus> then again if you label this as a 'bugfix' it can go in after the feature freeze
07:51 < morcos> ok, does it indicate somehow its not in the memory pool?
07:51 < morcos> i agree, this seems like the right behavior
07:52 < sipa> morcos: so whether a tx is in the mempool isn't relevant; whether it ever made it in is
07:52 < morcos> i understand for whehter or not its respendable
07:52 < sipa> or rather, whether it failed to add it _due to missing inputs_
07:52 < morcos> but to indicate whether or not you might want to manually forget it
07:52 -!- ParadoxSpiral [~ParadoxSp@p508B9E47.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
07:53 < sipa> the removetransaction functionality can still look at the mempool in the GUI and warn if it's there ("warning: it looks like this transaction may still confirm")
07:53 < morcos> sipa: see that last statement confuses me a bit.  I agree we want to distinguish on the reason it failed to add.  but if it failed to add, it should still be automatically replaceable in my mind
07:53 < wumpus> sipa: but only if it was requested by at least one other node :-)
07:53 < sipa> morcos: what if you received it from the network in the first place, but didn't get added to the mempool
07:54 < morcos> sipa: what happens now in that case?  are you even alerted to the txs existence
07:55 < sipa> i don't think so
07:55 < morcos> so no change there then
07:55 < wumpus> transactions not accepted into the mempool don't exist from the viewpoint of the node
07:55 < wumpus> (if you receive them)
07:55 < wumpus> this prevents some wallet spam attacks
07:56 < sipa> fair enough
07:58 < morcos> ok , i agree though.  a good baseline is to not conflict unless its conflicted.   so non-conflicted non mempool txs wont' be auto respendable.  but you can manually forget them.  its an optimization as to whether you want to detect that it never made it into the mempool period, but we dont' need it, i was being too picky.
07:58 < sipa> i like that
08:00 < morcos> in other news, sorry for all the churn on 6898, i'm trying to get it into as final a state as possible, and did a bunch of testing yesterday.
08:01 < morcos> sdaftuar is reworking the index to allow for considering manual tx prioritisation for eviction
08:01 < morcos> if there are no objections i will rebase and squash once more off that commit instead of my index commit
08:02 < morcos> sipa, should the dynamic memory usage now be 12 * ptrs with 4 indices?
08:02 < sipa> morcos: let me have a look at the boost code to be sure :)
08:05 < sipa> ordered indexes are 3 pointers overhead
08:06 < morcos> great thank you
08:07 < sipa> hash indexes are harder
08:08 < jgarzik> morcos, RE manual tx pro for eviction - dumb question - what does that imply for the goal of removing tx prio from mempool?
08:08 < sipa> jgarzik: right now priority-based things in the mempool are very easily evicted
08:08 < jgarzik> s/tx pro/tx prio/  - /me kicks autocorrect
08:09 < morcos> jgarzik: i was trying to distinguish between 2 overly similar names
08:09 < morcos> i'm talking about adding a feeDelta using prioritiseTransaction
08:09 < jgarzik> ah, ok.  That I understand.  :)
08:09 < morcos> i don't think we're talking about removing that, although of course getting rid of priorityDelta would be nice
08:15 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has left #bitcoin-core-dev ["Leaving"]
08:15 -!- jgarzik [~jgarzik@104-178-201-106.lightspeed.tukrga.sbcglobal.net] has joined #bitcoin-core-dev
08:15 -!- jgarzik [~jgarzik@104-178-201-106.lightspeed.tukrga.sbcglobal.net] has quit [Changing host]
08:15 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has joined #bitcoin-core-dev
08:16 < jgarzik> morcos, RE feeDelta...     ok, that I understood.  tnx
08:16 < jgarzik> That's pretty much how my original remove-prio patch worked.
08:16 < jgarzik> feeDelta could be used to execute arbitrary policy
08:17 < sipa> jgarzik: it seems that that is not really the case; you can come up with a formula to treat bitcoin-days-destroyed as extra fee, but it's probably hard to prevent it from making miners lose large amounts in fees
08:18 < sipa> (though if someone succeeds in that, I still like the idea!)
08:18 < jgarzik> sipa, nod - my idea was keep the current two-pass system
08:18 < jgarzik> sipa, if transactions fall out of pass #1, apply deltas, try again, see what happens
08:19 < jgarzik> check reality first, then distorted reality
08:20 < sipa> hmm
08:20 < sipa> but that's just for mempool eviction
08:20 < sipa> you need it also in block construction
08:30 < morcos> sipa: jgarzik: Just to sanity check what sdaftuar and I are doing, we are making any feeDeltas you put on transactions through prioritiseTransaction be treated just like real fee.
08:30 < sipa> sounds good to me
08:31 < morcos> so for instance if you add a big feeDelta to every tx, your mempool will end up with a very high minimum fee
08:31 < morcos> i can't think of any other way that would make sense, but just wanted to be sure
08:31 < jgarzik> morcos, yes
08:31 < morcos> of course the one exception is calculating the coinbase in the mining code (i hope)
08:31 -!- vbuilderv [~JoeLiu@110.186.124.35] has quit [Read error: Connection reset by peer]
08:31 < sipa> morcos: i think you should literally treat it as "I'm being paid out of band for this tx"
08:32 < morcos> once we remove priorityDelta for 0.13... we can change mapDeltas to only exist for txs not yet in the mempool i think...
08:33 < morcos> sipa: yes it just want clear to me that people knew to think about the scale, because before a limited mempool, it wouldn't really matter if you added huge fees to everything.. you'd just try to mine them first
08:33 < morcos> wasnt
09:01 -!- CodeShark [uid126576@gateway/web/irccloud.com/x-mluizvxgwdnddpbi] has quit [Quit: Connection closed for inactivity]
09:09 < btcdrak> sipa: Thank you very much for that patch for #6312 I hadnt quite grasped what you originally meant.
09:13 < sipa> btcdrak: oh, ok!
09:22 -!- trippysalmon [rob@2001:984:6466:0:a0d3:d9b8:fab7:bab3] has joined #bitcoin-core-dev
09:36 -!- rubensayshi [~ruben@91.206.81.13] has quit [Ping timeout: 265 seconds]
09:36 < GitHub36> [bitcoin] sdaftuar opened pull request #7062: [Mempool] Fix mempool limiting for PrioritiseTransaction (master...fix-mempool-limiting) https://github.com/bitcoin/bitcoin/pull/7062
09:39 < cfields_> instagibbs: pong
09:41 -!- Anduck [~anduck@unaffiliated/anduck] has joined #bitcoin-core-dev
10:02 -!- zmanian_ [sid113594@gateway/web/irccloud.com/x-miwknbvlwmroihsw] has quit [Ping timeout: 246 seconds]
10:04 < instagibbs> how shall I include a python script that is intended for end-users of Core? Which directory, etc?
10:05 -!- aburan28 [~xypher@static-108-45-93-78.washdc.fios.verizon.net] has quit [Ping timeout: 246 seconds]
10:07 -!- btcdrak [uid115429@gateway/web/irccloud.com/x-jwyhpappcdgxcqov] has quit [Remote host closed the connection]
10:20 -!- teward [teward@ubuntu/member/teward] has left #bitcoin-core-dev ["Leaving"]
10:22 -!- zmanian_ [sid113594@gateway/web/irccloud.com/x-jcpcgdmbossuwhfs] has joined #bitcoin-core-dev
10:24 -!- btcdrak [uid115429@gateway/web/irccloud.com/x-oxmyfwfrtctnavdc] has joined #bitcoin-core-dev
10:36 < GitHub67> [bitcoin] sdaftuar opened pull request #7063: [Tests] Add prioritisetransaction RPC test (master...add-prioritisetransaction-rpctest) https://github.com/bitcoin/bitcoin/pull/7063
10:38 < sipa> hmm, do we have any means for people to select pruning at first run of Bitcoin-Qt?
10:38 < sipa> or any way to enable it in the GUI
10:39 < wumpus> nope
10:42 -!- MarcoFalke [8af6027e@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.126] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
10:43 -!- zooko [~user@c-71-237-69-190.hsd1.co.comcast.net] has quit [Ping timeout: 240 seconds]
10:44 -!- Thireus [~Thireus@icy.thireus.fr] has quit [Remote host closed the connection]
10:44 -!- zooko [~user@c-71-237-69-190.hsd1.co.comcast.net] has joined #bitcoin-core-dev
10:46 -!- Thireus [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev
10:52 -!- jtimon [~quassel@74.29.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
10:55 < jonasschnelli> sipa: there is already an issue for that with a little discussion: https://github.com/bitcoin/bitcoin/issues/6461
10:56 < jgarzik> meeting?
10:56 -!- CodeShark [uid126576@gateway/web/irccloud.com/x-msbxdejlcdqrjaih] has joined #bitcoin-core-dev
10:57 < sipa> jgarzik: you're early!
10:58 < jonasschnelli> t-2min
10:58 < jtimon> sipa: saw https://github.com/jtimon/bitcoin/commit/071bc1cf615c0528d4f7e2fe33dc80186da447d3 ?
10:59 < wumpus> #meetingstart
10:59 < wumpus> eh wrong channel
10:59 < petertodd> lol
11:03 -!- treehug88 [~textual@static-108-30-103-59.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
11:07 -!- zooko [~user@c-71-237-69-190.hsd1.co.comcast.net] has quit [Ping timeout: 265 seconds]
11:10 -!- MarcoFalke [c3523fc6@gateway/web/cgi-irc/kiwiirc.com/ip.195.82.63.198] has joined #bitcoin-core-dev
11:16 -!- MarcoFalke [c3523fc6@gateway/web/cgi-irc/kiwiirc.com/ip.195.82.63.198] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
11:21 < sipa> jtimon: no opinion :)
11:33 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has left #bitcoin-core-dev ["Leaving"]
11:33 -!- jgarzik [~jgarzik@104-178-201-106.lightspeed.tukrga.sbcglobal.net] has joined #bitcoin-core-dev
11:33 -!- jgarzik [~jgarzik@104-178-201-106.lightspeed.tukrga.sbcglobal.net] has quit [Changing host]
11:33 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has joined #bitcoin-core-dev
11:34 -!- MarcoFalke [c3523fc6@gateway/web/cgi-irc/kiwiirc.com/ip.195.82.63.198] has joined #bitcoin-core-dev
11:48 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev
11:56 -!- zooko [~user@c-73-217-16-2.hsd1.co.comcast.net] has joined #bitcoin-core-dev
12:04 -!- wangchun [~wangchun@li414-193.members.linode.com] has quit [Ping timeout: 260 seconds]
12:05 -!- wangchun [~wangchun@li414-193.members.linode.com] has joined #bitcoin-core-dev
12:07 < jtimon> sipa: your opinion is the reason #6068 is closed https://github.com/bitcoin/bitcoin/pull/6068#issuecomment-152850502 : "Frankly, I think this type of encapsulation needs to wait until the mempool
12:07 < jtimon> code itself and the code relying on it is stable, and it is clear which
12:07 < jtimon> parts are configurable and which aren't."
12:08 < sipa> jtimon: yes; that PR itself may be fine, but it can't really do much useful in terms of encapsulation
12:08 < jtimon> sipa: well I can't open the ones that depend on it until it is merged without creating a lot of noise
12:09 < sipa> so just wait until all this mempool stuff has cooled down :)
12:11 < jtimon> #6423 #5114 #6420 and much more stuff is waiting for #6068
12:11 < jtimon> sipa: but I strugle to understand why one thing needs to wait for the other
12:12 < jtimon> if #6068 won't interfere with "the mempool stuff", why does it have to wait?
12:12 < sipa> if you want to do any useful encapsulation of policy it does
12:13 < jtimon> because #6423 #5114 #6420 are useless in terms of encapsulation or interfere with the mempool stuff?
12:14 < jtimon> when the mempool code is "ready" for me to be able to encapsulate that part, I will still want to do this stuff first
12:15 < sipa> 5114 seems perfectly fine and independent of any policy classes
12:16 < jtimon> well, #6420 wasn't a great example, but most of my policy branches weren't opened as PRs
12:16 < sipa> oh, it does add that too
12:16 < jtimon> 5114 is waiting for #6068 because it could be a method in CPolicy
12:17 < jtimon> waiting for ages, long before any of the "mempool stuff"
12:18 < jtimon> and I think #6423 could have been a model for adding new mempool attributes/globals
12:19 < jtimon> of course the code in the PR is heaavily out of date
12:23 < jtimon> but I have newer versions of all that stuff. some more advanced things [ie fully decouple txmempool and policy/fees from each other, you may not believe this] are somewhere in the pile of forgotten branches...
12:24 < jtimon> and I won't try to repeat that until the mempool code is more stable
12:25 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Ping timeout: 250 seconds]
12:25 -!- tripleslash_x [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev
12:25 < jtimon> but the things that I know can only conflict trivially...
12:25 < morcos> jtimon: what happened to your high level document
12:26 < morcos> i'm all in favor of getting some of these changes merged, b/c its getting hard to write new code and access the right things
12:26 < sipa> morcos: that was about consensus stuff movement, not policy encapsulation 
12:26 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-core-dev
12:26 < morcos> i think we should have a time shortly after 0.12 is branched or released, i don't care which, in which we actively merge a lot of refactors
12:27 < morcos> sipa: in my mind it was about overall code architecture
12:27 < morcos> i would be happy to rework any open pulls i have then and help review
12:41 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev
12:43 < jtimon> morcos: that's for libconsensus, not policy
12:43 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Read error: No route to host]
12:43 < jtimon> morcos: but yeah I should go back to that
12:44 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev
12:47 < jtimon> which reminds me...I need to ask cfields what would he think about a consensus building module separated from util, common, etc, maybe merging with libsecp256 and crypto modules (that is not good for bitcoin-tx when we start adding non-tx stuff to the module, but verifyheader and verifyblock should be relatively light compared to verifytx and verifyscript)
12:49 < jtimon> anyway, I should adapt it to post-libsecp256k1, it should make the document simpler and clearer, and change it to plan that starts after forking 0.12 instead of right before it
12:50 < jtimon> s/plan/a plan/
12:53 < instagibbs> cfields_, ping: how shall I include a python script that is intended for end-users of Core? Which directory, etc?
12:55 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has joined #bitcoin-core-dev
12:56 < dcousens> wumpus: what are your thoughts on using github milestones for tracking what issues/PRs need to be resolved for releases (say, 0.12)
12:56 < dcousens> I feel like that'd be really useful to help concentrate review effort etc
12:56 < sdaftuar> dcousens: there are PRs tagged for 0.12
12:57 < dcousens> sdaftuar: I don't see the 0.12 label?
12:57 < sdaftuar> it's under milestones
12:57 < dcousens> right, its already being done
12:57 < cfields_> instagibbs: depends on what it is, i guess
12:57 < cfields_> jtimon: not sure what you mean
12:57 < dcousens> sweet, nvm :)
12:58 < dcousens> sdaftuar: just didn't see a single recently updated PR with a milestone, and assumed otherwise haha
12:58 < jtimon> cfields_: so what's in libbitcoinconsensus_la_SOURCES = \
12:59 < instagibbs> cfields_, https://github.com/bitcoin/bitcoin/pull/7044
12:59 < sdaftuar> i'll take that as an opportunity to beg for review -- please take a look at #6494! :)
12:59 -!- fkhan [weechat@gateway/vpn/mullvad/x-ubkfcmuajrofuphz] has quit [K-Lined]
12:59 < jtimon> is repeated in libbitcoin_util_a_SOURCES, libbitcoin_common_a_SOURCES, etc
12:59 < instagibbs> it has a script that is basically the suggested way of generating a name/salt/pass
13:00 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has quit [Client Quit]
13:01 < jtimon> cfields_: we could have a libbitcoin_consensus_a_SOURCES that libbitcoinconsensus_la_SOURCES takes but it's also build separately as part of building bitcoind (like util, univalue, etx)
13:01 < cfields_> instagibbs: mm, share/ would probably be the best fit
13:01 < jtimon> s/etx/etc
13:01 < cfields_> jtimon: i have a branch around somewhere that does something similar
13:02 < cfields_> jtimon: problem is the mixing of libtool/non-libtool
13:02 -!- Thireus [~Thireus@icy.thireus.fr] has quit [Ping timeout: 240 seconds]
13:02 < jtimon> cfields_: does that make sense to you? at some point we need to do that AND move all the code inside the same folder if we want to make a subtree ala https://github.com/libbitcoin/libbitcoin-consensus
13:02 < instagibbs> cheers, I'll move it around.
13:04 -!- Thireus [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev
13:04 < jtimon> cfields_: it would be great if you could resurrect it
13:05 < cfields_> jtimon: yea. i believe the issue was that libtool doesn't like linking a lib into another lib. Can't remember if i PR'd changes to fix that behavior or not
13:06 < jtimon> cfields_: I'm not sure I undesrtand the libtool/non-libtool but things like script/interpreter.cpp not appearing twice seems trivial
13:06 < cfields_> jtimon: go for it :)
13:08 < jtimon> cfields_: well, probably that's the correct(tm) solution but I think something simpler could be done: libbitcoinconsensus_la_SOURCES just happens to build the same things as the libbitcoin_consensus_a_SOURCES module, but they still build twice
13:08 < jtimon> cfields_: well, I don't have much experience with the building part
13:09 < jtimon> I just see a util and a common module and want another one for consensus
13:09 < cfields_> to what end?
13:09 < jtimon> I mean, if you're willing to point out my mistakes I may try to do it myself
13:10 < jtimon> at some point we want to have it in an independent repo, no?
13:11 < jtimon> therefore it seems a logical module to be built together (like libsecp256 currently is)
13:12 < jtimon> I mean, that's what I'm asking if makes sense to you
13:12 < jtimon> it could even include crypto and libsecp256 in one single module (independent from util and common)
13:12 < cfields_> jtimon: that makes sense to me (not sure about making external), but imo it's not worth shuffling around the build stuff until the end
13:14 < jtimon> cfields_: well, I think I disagree, I want the compiler to tell people when they "un-encapsulate" or "add unwanted dependencies" to consensus code
13:14 -!- dhill [~dhill@phengo.phobia.ms] has quit [Remote host closed the connection]
13:15 < jtimon> for example, if I move primitives/block.o to that module and then someone includes util.h in block.cpp, the linking should fail
13:16 < cfields_> jtimon: in that case, build/link would still succeed if it's pulling header-only stuff from util.h. sounds like you want to be messing with include paths instead.
13:17 < jtimon> IMO, it helps to more easily "protect" the already-encapsulated code, like moving the files to the same folder, it can always be done later, but it makes things clearer to devs I think
13:17 < jtimon> at least not if is something defined in util.cpp, right?
13:18 < cfields_> right
13:19 < jtimon> something is something, for the other thing I guess we would need to divide BITCOIN_CORE_H or something, but seems much more messy if it's even possible
13:21 < cfields_> it'd likely involve moving non-lib-safe headers to their own dir, yea
13:21 < jtimon> that seems like a smart division
13:21 -!- zooko [~user@c-73-217-16-2.hsd1.co.comcast.net] has quit [Ping timeout: 260 seconds]
13:22 < jtimon> so do you think you could do the consensus module?
13:22 < jtimon> I mean...are you interested?
13:23 < cfields_> jtimon: not at the moment, i'm trying to get net stuff firmed up
13:25 < jtimon> btw, right now is a mess that I don't want to even show you, but if you want to co-author of the libconsensus planning doc, you're more than welcomed, last time I just happened to be breaking up script and learn a lot from you BlueMatt and sipa (also invited to become co-authors), at least I hope all of you will find time to review it
13:27 < jtimon> cfields_: mhmm, ok, I guess I can try it myself and nagg you to point out my mistakes, do I have to touch any other file apart from src/Makefile.am ?
13:27 -!- aburan28 [~xypher@static-108-45-93-78.washdc.fios.verizon.net] has joined #bitcoin-core-dev
13:27 < cfields_> jtimon: sure, i'll have a look. I'd like to help out, but i'm currently overcommitted and afraid i'd just slow you down
13:27 < cfields_> shouldn't
13:28 < jtimon> cfields_: ok, in any case the plan will start after forking 0.12 so no rush to publish it until that happens
13:29 < cfields_> ok
13:29 < jtimon> cfields_: thanks, I'll try it and I may come with more questions
13:30 < cfields_> sounds good :)
13:30 < jtimon> thoughts on unifying the new consensus module with libsecp256 and crypto modules (I believe the current libconsensus depends on the whole crypto module and libsecp256k1 while nothing that depends on those modules doesn't depend on consensus too?) ?
13:32 < cfields_> not sure what you mean by unify...
13:32 < cfields_> keep in mind that consensus isn't the only POV for layout
13:32 -!- ParadoxSpiral [~ParadoxSp@p508B9E47.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
13:33 < jtimon> what's in libbitcoin_util_a_SOURCES, for example, is linked as the same module/package, right?
13:33 < jtimon> aren't those these the packages/modules in which bitcoin core is divided?
13:33 < jtimon> bitcoind_LDADD = \
13:33 < jtimon>   $(LIBBITCOIN_SERVER) \
13:33 < jtimon>   $(LIBBITCOIN_COMMON) \
13:33 < jtimon>   $(LIBUNIVALUE) \
13:33 < jtimon>   $(LIBBITCOIN_UTIL) \
13:33 < jtimon>   $(LIBBITCOIN_CRYPTO) \
13:34 < jtimon>   $(LIBLEVELDB) \
13:34 < jtimon>   $(LIBMEMENV) \
13:34 < jtimon>   $(LIBSECP256K1)
13:34 < jtimon> it could turn into:
13:34 < jtimon> bitcoind_LDADD = \
13:34 < jtimon> $(LIBBITCOIN_SERVER) \
13:34 < jtimon> $(LIBBITCOIN_COMMON) \
13:34 < jtimon> $(LIBUNIVALUE) \
13:34 < jtimon> $(LIBBITCOIN_UTIL) \
13:34 < jtimon> $(LIBBITCOIN_CONSENSUS) \
13:34 < jtimon> $(LIBLEVELDB) \
13:34 < jtimon> $(LIBMEMENV)
13:34 < jtimon> no?
13:35 < instagibbs> wumpus, any pointers on installing the rpcuser python script? Source of Q: https://github.com/bitcoin/bitcoin/pull/7044#discussion_r45213005
13:36 < cfields_> jtimon: that's what i meant by "consensus isn't the only POV". For (bad) example, bitcoin-tx might need hashing, but not use libsecp256k1
13:36 < jtimon> yeah, is it a problem if it depends on both?
13:36 < jtimon> or rather, how much of a problem it is?
13:37 < cfields_> jtimon: better to keep the chunks small and localized, and let the bigger libs/progs only include what they need
13:37 < jtimon> assuming a future in which bitcoin core consumes libbitcoinconsensus C API directly instead of its code, that dependency will eventually happen
13:39 < jtimon> is that assumption crazy?
13:40 < cfields_> no, but the assumption that everything that needs _some_ parts of the consensus code need _all_ of it is, i think
13:40 < jtimon> that's the assumption I'm talking about
13:41 < jtimon> is not that needs it, but it has to link it as a whole
13:41 < cfields_> then yes, i think that's a bad path
13:42 < jtimon> in the same sense, bitcoin-tx may not require everything in util or common, but it depends on util and common as a whole
13:42 < jtimon> doesn't it?
13:43 < cfields_> yes, but common/util were split up for just that reason
13:44 < jtimon> doesn't bitcoin-tx depend on both of them?
13:44 < cfields_> yes, but see bitcoin-cli
13:45 < jtimon> does bitcoin-tx use every function defined in every cpp in util and common?
13:45 < jtimon> what's with bitcoin-cli ?
13:45 < cfields_> jtimon: no need to take this to the extreme. The lines are somewhat arbitrary and could certainly be redrawn. But i'd rather see the scopes narrowed than grown.
13:48 < jtimon> well, my main goal is consensus being one scope (instead of having hash.o in common and uint256 in util, for example), so let's just forget about the "unifying consensus + crypto + libsecp256" thing for very long
13:50 -!- fkhan [~weechat@unaffiliated/loteriety] has joined #bitcoin-core-dev
13:54 < jtimon> cfields_: instead of doing a full library-friendly vs non-friendly separation I will only separate the current libconsensus headers for now, which reminds me...where do you think ScriptErrorString() (removing script_error.cpp) should be put?
13:54 < jtimon> it doesn't seem to be needed for libbitcoinconsensus
13:56 -!- zooko [~user@50.141.117.66] has joined #bitcoin-core-dev
13:58 < cfields_> jtimon: yea, i suppose you could call that a core-specific thing, since it's not exposed
13:58 < cfields_> though, heh, core doesn't actually use it anywhere
13:59 < jtimon> oh, so we can actually just remove it or is it supposed to be used by libconsensus?
14:00 < jtimon> or by core?
14:01 < cfields_> the original intention was to have api-stable error codes, and that function would be exposed as well
14:01 -!- trippysalmon [rob@2001:984:6466:0:a0d3:d9b8:fab7:bab3] has quit [Ping timeout: 250 seconds]
14:01 -!- zooko` [~user@2601:281:8001:26aa:7c2c:2601:b748:7d8a] has joined #bitcoin-core-dev
14:02 < cfields_> but once we dropped the external error codes, it stopped being useful for anything other than internal debugging, i guess
14:02 < jtimon> assuming we didn't had dropped them
14:03 -!- zooko [~user@50.141.117.66] has quit [Ping timeout: 255 seconds]
14:03 < jtimon> where would this errorCodeToString() function go?
14:04 < cfields_> libconsensus
14:04 < jtimon> ok, so then script_error.cpp should be in libbitcoinconsensus_la_SOURCES right?
14:05 < cfields_> yea
14:06 < jtimon> I mean, for example, amount.h is part of libconsensus but amount.cpp isn't (because once we take IsDust out of transaction.h, CFeeRate can go somewhere in the policy folder)
14:07 < jtimon> I thought this could be a similar case, so thanks that's very useful
14:08 -!- zooko` is now known as zooko
14:41 -!- CodeShark [uid126576@gateway/web/irccloud.com/x-msbxdejlcdqrjaih] has quit [Quit: Connection closed for inactivity]
14:44 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]
14:47 -!- tulip [~tulip@128.199.135.43] has joined #bitcoin-core-dev
14:47 -!- MarcoFalke [c3523fc6@gateway/web/cgi-irc/kiwiirc.com/ip.195.82.63.198] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
14:58 -!- treehug88 [~textual@static-108-30-103-59.nycmny.fios.verizon.net] has quit [Quit: Textual IRC Client: www.textualapp.com]
15:21 < phantomcircuit> the current wallet bdb behavior is to write everything to wallet.dat in CDB::Flush and to only use the log files as crash recovery
15:21 < phantomcircuit> which means there's a basically free 2x speedup available by flushing to the log instead of to the log and the backing store
15:22 < phantomcircuit> the question is are we ok that wallet.dat might also need the database directory for upto 500ms after an operation has completed?
15:23 < sipa> i'm fine with that
15:24 < sipa> i thought that was the model anyway: at shutdown, we try to make sure the log files are empty and the wallet.dat files are independent
15:24 < sipa> but before that time, in case.of a crash, you need the log file
15:31 < phantomcircuit> sipa, nope currently the only time you need the log files is if you actually crash
15:42 < phantomcircuit> also doing it this way reduces the total number of fsync calls as bdb will coalesce writes to wallet.dat
15:43 < sipa> good
15:47 < phantomcircuit> still cant figure out why calling pdb->sync() doesn't cause an actual fsync/fdatasync though
15:49 < phantomcircuit> sipa, actually it's closing the database handle which i believe isn't necessary
15:49 < phantomcircuit> lets find out...
15:51 < phantomcircuit> the particular function im confused by is https://docs.oracle.com/cd/E17276_01/html/api_reference/C/dbsync.html
15:57 -!- aburan28 [~xypher@static-108-45-93-78.washdc.fios.verizon.net] has quit [Ping timeout: 250 seconds]
16:17 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Read error: No route to host]
16:20 -!- tulip [~tulip@128.199.135.43] has quit []
16:23 -!- PRab [~chatzilla@c-68-34-102-231.hsd1.mi.comcast.net] has quit [Quit: ChatZilla 0.9.92 [Firefox 42.0/20151029151421]]
16:23 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev
16:31 -!- tulip [~tulip@128.199.135.43] has joined #bitcoin-core-dev
16:51 -!- aburan28 [~xypher@static-108-45-93-78.washdc.fios.verizon.net] has joined #bitcoin-core-dev
17:05 -!- aburan28 [~xypher@static-108-45-93-78.washdc.fios.verizon.net] has quit [Ping timeout: 260 seconds]
17:10 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has joined #bitcoin-core-dev
17:10 < dcousens> everytime I read IBLT, I think to myself "inverted bacon lettuce tomato"
17:10 < dcousens> Sigh
17:15 < sipa> LOL
17:16 -!- zooko [~user@2601:281:8001:26aa:7c2c:2601:b748:7d8a] has quit [Ping timeout: 246 seconds]
17:25 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Quit: .]
17:35 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-core-dev
17:38 -!- zooko [~user@2601:281:8001:26aa:7c2c:2601:b748:7d8a] has joined #bitcoin-core-dev
17:44 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-tqooqtiqdlldfrlu] has quit [Quit: Connection closed for inactivity]
17:57 < gmaxwell> likewise, fwiw
18:08 -!- guest234234 [~guest2342@223.207.232.28] has joined #bitcoin-core-dev
18:29 < GitHub122> [bitcoin] pstratem opened pull request #7064: Perform entire CWallet::TopUpKeyPool in a transaction. (master...2015-11-19-wallet-topupkeypool) https://github.com/bitcoin/bitcoin/pull/7064
18:30 -!- guest234234 [~guest2342@223.207.232.28] has quit [Ping timeout: 240 seconds]
18:34 < phantomcircuit> CDB::Close abort's any active transaction, it seems like any time we're calling CDB::Close and have an active transaction in play that's an exception
18:35 -!- belcher [~user@unaffiliated/belcher] has quit [Quit: Leaving]
18:57 -!- zooko [~user@2601:281:8001:26aa:7c2c:2601:b748:7d8a] has quit [Ping timeout: 246 seconds]
19:07 -!- teward [teward@ubuntu/member/teward] has joined #bitcoin-core-dev
19:33 -!- guest234234 [~guest2342@223.207.232.28] has joined #bitcoin-core-dev
21:43 -!- Guest23423 [~guest2342@223.207.239.241] has joined #bitcoin-core-dev
21:45 -!- guest234234 [~guest2342@223.207.232.28] has quit [Ping timeout: 240 seconds]
22:02 -!- Guest23423 [~guest2342@223.207.239.241] has quit [Ping timeout: 252 seconds]
23:21 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Read error: Connection reset by peer]
23:22 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev
23:25 -!- MarcoFalke [50edb194@gateway/web/cgi-irc/kiwiirc.com/ip.80.237.177.148] has joined #bitcoin-core-dev
23:35 < GitHub13> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c983d6fcb47b...a1bfca80521e
23:35 < GitHub13> bitcoin/master 2798e0b daniel: add powerpc build support for openssl lib
23:35 < GitHub13> bitcoin/master a1bfca8 Wladimir J. van der Laan: Merge pull request #7059...
23:35 < GitHub156> [bitcoin] laanwj closed pull request #7059: add powerpc build support for openssl lib (master...ppc) https://github.com/bitcoin/bitcoin/pull/7059
23:38 < gmaxwell> I'm bummed that my ppc debian host stopped booting. I think something is wrong with the PSU.
23:39 < midnightmagic> I still got mine running!
23:40 < gmaxwell> midnightmagic: can you update to bitcoin core master and see that it still works there?
23:40 < midnightmagic> sure!
23:40 < gmaxwell> I'd wanted to use it to test the switch to libsecp256k1 validation.
23:41 < midnightmagic> hrm. i think it's trying to do a kernel update.
23:55 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-sovgqgjhecqovgzf] has joined #bitcoin-core-dev
23:58 -!- MarcoFalke [50edb194@gateway/web/cgi-irc/kiwiirc.com/ip.80.237.177.148] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]