--- Day changed Fri Dec 09 2016 00:28 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 00:29 -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 00:33 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 256 seconds] 00:41 -!- JackH [~laptop@79-73-186-159.dynamic.dsl.as9105.com] has joined #bitcoin-core-dev 01:09 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-xkoywnheodgqvrfi] has joined #bitcoin-core-dev 01:14 -!- laurentmt [~Thunderbi@80.215.138.103] has joined #bitcoin-core-dev 01:15 -!- laurentmt [~Thunderbi@80.215.138.103] has quit [Client Quit] 01:18 -!- jannes [~jannes@178.132.211.90] has joined #bitcoin-core-dev 01:18 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has joined #bitcoin-core-dev 01:23 < bitcoin-git> [bitcoin] MarcoFalke pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/86017842d6ef...72bf1b3d0962 01:23 < bitcoin-git> bitcoin/master 8501bed Pieter Wuille: Squashed 'src/crypto/ctaes/' changes from cd3c3ac..003a4ac... 01:23 < bitcoin-git> bitcoin/master 760765d Pieter Wuille: Update ctaes 01:23 < bitcoin-git> bitcoin/master 72bf1b3 MarcoFalke: Merge #9303: Update comments in ctaes... 01:23 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #9303: Update comments in ctaes (master...ctaes) https://github.com/bitcoin/bitcoin/pull/9303 01:36 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 260 seconds] 01:37 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Read error: Connection reset by peer] 01:39 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 01:46 -!- LeMiner2 [~LeMiner@5ED1AFBF.cm-7-2c.dynamic.ziggo.nl] has joined #bitcoin-core-dev 01:46 -!- LeMiner [~LeMiner@5ED1AFBF.cm-7-2c.dynamic.ziggo.nl] has quit [Ping timeout: 260 seconds] 01:46 -!- LeMiner2 is now known as LeMiner 01:53 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 02:01 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has left #bitcoin-core-dev [] 02:08 -!- chris2000 [~chris2000@p5DCB510A.dip0.t-ipconnect.de] has joined #bitcoin-core-dev 02:17 -!- harrymm [~wayne@104.237.91.209] has quit [Remote host closed the connection] 02:20 -!- harrymm [~wayne@104.237.91.97] has joined #bitcoin-core-dev 02:30 -!- VeryWellAged [3a45962d@gateway/web/freenode/ip.58.69.150.45] has joined #bitcoin-core-dev 02:31 -!- VeryWellAged [3a45962d@gateway/web/freenode/ip.58.69.150.45] has quit [Client Quit] 03:04 -!- MurhS0xFF [~2efPer_1a@222.117.212.4] has joined #bitcoin-core-dev 03:17 -!- MurhS0xFF [~2efPer_1a@222.117.212.4] has quit [Read error: Connection reset by peer] 04:34 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has joined #bitcoin-core-dev 04:37 -!- LeMiner2 [LeMiner@5ED1AFBF.cm-7-2c.dynamic.ziggo.nl] has joined #bitcoin-core-dev 04:40 -!- LeMiner [~LeMiner@5ED1AFBF.cm-7-2c.dynamic.ziggo.nl] has quit [Ping timeout: 260 seconds] 04:40 -!- LeMiner2 is now known as LeMiner 04:50 -!- jtimon [~quassel@77.224.94.35] has joined #bitcoin-core-dev 04:59 -!- jtimon [~quassel@77.224.94.35] has quit [Ping timeout: 246 seconds] 05:03 -!- michagogo [uid14316@wikia/Michagogo] has quit [] 05:04 -!- michagogo [uid14316@wikia/Michagogo] has joined #bitcoin-core-dev 05:13 -!- jtimon [~quassel@77.224.94.35] has joined #bitcoin-core-dev 05:23 < BlueMatt> hmmmmmm....I'm pretty sure CheckForkWarningConditionsOnNewFork is completely useless atm... 05:24 < BlueMatt> it looks like it was written assuming pindexNewForkTip would be a CBlockIndex* to the highest block on a new fork (which I think is the case in the original code, and I'm not just saying it because I originally wrote it) 05:24 < BlueMatt> but in the current code its given the last block which ActivateBestChainStep wanted to connect (but failed because either it, or a previous block) was invalid 05:25 < BlueMatt> and that last block is always either current chain + 1 unless its a reorg 05:37 < BlueMatt> ehh, excuse me...CheckForkWarningConditionsOnNewFork is called with a larger vector which isnt exactly the things ABCS tries, but what it might've tried if it didnt want to give up cs_main earlier 05:37 < BlueMatt> still, i think due to headers first this stuff is horribly broken 05:42 -!- laurentmt [~Thunderbi@80.215.210.76] has joined #bitcoin-core-dev 05:43 -!- laurentmt [~Thunderbi@80.215.210.76] has quit [Client Quit] 06:06 -!- CubicEarth [~cubiceart@2002:329f:7e15:0:9909:f524:6820:33da] has quit [Remote host closed the connection] 06:07 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Quit: WeeChat 0.4.2] 06:16 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev 06:18 -!- TomMc [~tom@unaffiliated/tommc] has joined #bitcoin-core-dev 06:29 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 06:37 < gmaxwell> nah it does work. 06:42 < BlueMatt> you sure? that code doesnt look sane to me now 06:42 < BlueMatt> (do we have any tests for it? couldnt find any) 06:43 < BlueMatt> and jl2012 was saying he tried to trigger it by sending invalid blocks with valid headers and couldnt 06:52 * BlueMatt -> out 07:07 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has joined #bitcoin-core-dev 07:10 < bitcoin-git> [bitcoin] ryanofsky opened pull request #9306: Make CCoinsViewCache::Cursor() return latest data (master...pr/coins-cursor) https://github.com/bitcoin/bitcoin/pull/9306 07:12 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has quit [Ping timeout: 265 seconds] 07:33 < bitcoin-git> [bitcoin] ryanofsky opened pull request #9307: [trivial] Remove undefined FetchCoins method declaration (master...pr/coins-delfetch) https://github.com/bitcoin/bitcoin/pull/9307 07:36 < bitcoin-git> [bitcoin] ryanofsky opened pull request #9308: [test] Add CCoinsViewCache Access/Modify/Write tests (master...pr/coins-test) https://github.com/bitcoin/bitcoin/pull/9308 07:37 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev 07:52 -!- Samdney [~Samdney@178.162.209.142] has joined #bitcoin-core-dev 07:54 -!- Teroxice [Teroxice@47.190.17.19] has joined #bitcoin-core-dev 07:54 < Teroxice> Hello 07:54 < Teroxice> I build an ATM software and right now its sending money from a centralized bitcore server with just one wallet. I will offer my software to the market but I would like that every client has their own independent wallet in my centralized bitcore server. That is why I'm asking if it is posible to have more than one wallet on the same bitcore server. Anyone knows? 07:55 < achow101> Teroxice: bitcore or bitcoin core? There is a difference. 07:55 < achow101> also, wrong channel 07:55 < Teroxice> bitcoin core 07:56 < achow101> bitcoin core does not have multiwallet support 07:56 < instagibbs> Teroxice, try #bitcoin 08:00 -!- laurentmt [~Thunderbi@80.215.210.76] has joined #bitcoin-core-dev 08:01 -!- laurentmt [~Thunderbi@80.215.210.76] has quit [Client Quit] 08:02 -!- aalex__ [~aalex@64.187.177.58] has joined #bitcoin-core-dev 08:06 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 250 seconds] 08:06 -!- aalex_ [~aalex@64.187.177.58] has quit [Ping timeout: 258 seconds] 08:06 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev 08:07 -!- aalex__ [~aalex@64.187.177.58] has quit [Ping timeout: 258 seconds] 08:07 -!- aalex__ [~aalex@64.187.177.58] has joined #bitcoin-core-dev 08:10 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 244 seconds] 08:11 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev 08:23 -!- Teroxice [Teroxice@47.190.17.19] has left #bitcoin-core-dev [] 08:42 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection] 08:43 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 08:43 -!- aalex__ [~aalex@64.187.177.58] has quit [Quit: Connection reset by beer] 08:44 -!- Samdney [~Samdney@178.162.209.142] has quit [Quit: Verlassend] 08:46 < bitcoin-git> [bitcoin] morcos opened pull request #9309: Spurious RPC test failure (master...rarerpcfail) https://github.com/bitcoin/bitcoin/pull/9309 08:48 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 268 seconds] 08:53 -!- aalex_ [~aalex@64.187.177.58] has joined #bitcoin-core-dev 08:57 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 246 seconds] 09:04 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 09:10 -!- CubicEarth [~cubiceart@2002:329f:7e15:0:9188:a7c5:5f4a:f82f] has joined #bitcoin-core-dev 09:15 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 09:27 -!- TomMc [~tom@unaffiliated/tommc] has quit [Ping timeout: 245 seconds] 09:32 -!- Samdney [~Samdney@178.162.209.132] has joined #bitcoin-core-dev 09:40 -!- TomMc [~tom@gateway/vpn/privateinternetaccess/tommc] has joined #bitcoin-core-dev 10:09 < bitcoin-git> [bitcoin] ryanofsky opened pull request #9310: Assert FRESH validity in CCoinsViewCache::BatchWrite (on top of #9308) (master...pr/coins-batch-assert) https://github.com/bitcoin/bitcoin/pull/9310 10:24 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 10:25 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit] 10:32 -!- TomMc [~tom@gateway/vpn/privateinternetaccess/tommc] has quit [Ping timeout: 250 seconds] 10:40 -!- jtimon [~quassel@77.224.94.35] has quit [Remote host closed the connection] 10:44 -!- TomMc [~tom@unaffiliated/tommc] has joined #bitcoin-core-dev 10:46 -!- dermoth [~thomas@dsl-66-36-158-238.mtl.aei.ca] has quit [Ping timeout: 265 seconds] 10:47 -!- dermoth [~thomas@dsl-66-36-158-238.mtl.aei.ca] has joined #bitcoin-core-dev 10:53 < bitcoin-git> [bitcoin] morcos opened pull request #9311: Flush wallet after abandontransaction (master...flushwalletonabandon) https://github.com/bitcoin/bitcoin/pull/9311 11:03 < morcos> gmaxwell: maybe easier to explain what's happening in #9167 here 11:03 < gribble> https://github.com/bitcoin/bitcoin/issues/9167 | IsAllFromMe by morcos · Pull Request #9167 · bitcoin/bitcoin · GitHub 11:04 < morcos> if you ran that same command on the old code your grep would find fee twice 11:04 < morcos> it prints an overall fee for the transaction and it prints a fee for each accounting entry 11:05 < morcos> it was already the case that if it didn't think the tx was from you (meaning none of it was from you) it would leave off the overall fee for the tx 11:05 < gmaxwell> ah, I see. what the heck is the fee for the accounting entries for? 11:05 < morcos> i changed that logic to be whether all of it was from you 11:06 < morcos> don't get me started on that 11:06 < morcos> getbalance("*") uses those random incorrect negative fees to offset other errors in tracking balances 11:06 < morcos> so it was not possible to fix those 11:06 < morcos> i suppose we could not print them, but that seems like an api change 11:07 < gmaxwell> We should probably be telling the wallet about the actual values of all the inputs... we know them (we're a full node, after all!). then the fees it displays can be correct. 11:08 < gmaxwell> but thats a bigger change. 11:08 < morcos> yeah i don't think we should try to make any changes of that behavior until we remove accounts 11:08 < morcos> then we can clean up a lot 11:08 < morcos> which reminds me i need to be participating in wumpus's labels discussion 11:09 < sdaftuar> gmaxwell: +1 on telling the wallet! 11:09 < sdaftuar> er, about al the fees 11:09 < sdaftuar> i think it's nuts the way that works now 11:09 < gmaxwell> we've let the accounts stuff deadlock us for a long time, I believe that this was also the reason we didn't fix the absurd handling wrt fees when it was first noticed. :( 11:10 < sdaftuar> i think my proposal would just be to pass fee information through SyncTransaction(). we have it during ATMP, and we could cache it while validating a block 11:11 < sdaftuar> that doesn't go as far as all input values, but i think it'd be a simple improvement 11:12 < gmaxwell> it would be. full input values are needed if we want to create detailed corrective accounting entries for txn with inputs which aren't fromme. 11:13 < gmaxwell> e.g. txid 1234 spend 1000 of our coins, spent 4001 coins from {these sources}, paid 5000 coins, and 1 coin fee. 11:13 < gmaxwell> if {these sources} is just "from outside this wallet" then we don't need per input amounts. 11:14 < gmaxwell> we just need the fee. 11:17 < sdaftuar> well i definitely agree that with the goal of per-input amounts being passed through! maybe that's not so hard to implement either, actually... 11:18 < sdaftuar> we can probably come up with some reasonable data structure and pass that through to the wallet as well 11:19 < gmaxwell> sipa: do we have a philosophical opposition to decoderawtransaction using the UTXO set, telling you if each of the inputs is unspent, and if they all are-- displaying the fee? 11:19 < sipa> gmaxwell: i think that should be a separate rpc call 11:20 < gmaxwell> sipa: what would it be called? 11:20 < sipa> gmaxwell: decoderawtransaction is purely a utility function now, and i think it should stay that way 11:20 < sipa> analyserawtransaction ? 11:20 < gmaxwell> please no more words with different en_gb/en_us spelling! 11:20 < gmaxwell> :P 11:21 < sipa> rawtransactionanalysis 11:21 < sipa> :p 11:21 < sdaftuar> could we add memory-only per-input values to CTransaction(), so that they get filled in and passed through to the wallet in SyncTransaction()? 11:22 < sipa> evaluaterawtransaction 11:22 < sipa> sdaftuar: bleh... what if they aren't known? the consensus logic (which uses CTransaction) shouldn't need such values 11:23 < sdaftuar> right, consensus wouldn't use it. but it would be convenient to fill in for downstream consumers 11:23 < gmaxwell> well consensus certantly does eventually need to know the input values! :) 11:23 < sdaftuar> we could do outside of CTransaction() of course 11:23 < sipa> gmaxwell: but CTransaction is by design now immutable 11:23 < sdaftuar> the witness is not? 11:23 < sipa> sdaftuar: it will be 11:24 < sdaftuar> ah! didn't realize that. 11:24 < sipa> (also, CTransactionRef is a ref to a _const_ CTransaction, which includes the witness) 11:24 < sdaftuar> ok so i guess stuffing data into that just won't work 11:24 < sipa> but we could have a wrapper around CTransaction that adds some metadata, which is used by ATMP and wallet code 11:25 < sipa> or just pass along a separate object that contains that metadata 11:25 < morcos> but speakign of that idea... lets imagine inputs were part of CTxMempoolEntry, then maybe you don't need a UTXO cache anymore 11:25 < sipa> morcos: though it makes the mempool's correctness now consensus critical 11:25 < sdaftuar> nack 11:25 < morcos> thats what we're arguign about 11:26 -!- molz is now known as moli 11:26 < gmaxwell> eventually the fast that txn are already verified in the mempool will have to be exploited for performance reasons. :( 11:27 -!- Lightsword [~Lightswor@107.170.253.193] has quit [Quit: ZNC] 11:27 < sdaftuar> i would like that to be the last change that goes in before i stop working on the codebase :) 11:27 < gmaxwell> hah. yea. :( 11:27 < gmaxwell> or we'll just end up with miners using Joe-Marketers-Recklessly-Optimized-Fork that "validates blocks 5x faster"... 11:27 -!- Lightsword [~Lightswor@2604:a880:1:20::1d3:9001] has joined #bitcoin-core-dev 11:28 < gmaxwell> and then all the care in not being reckless didn't matter because relevant parties aren't using it. 11:31 < sipa> morcos: even if we had that, we'd need to apply utxo changes to the chainstate... which is perhaps harder if we haven't previously looked up the entry (because it's missing from intermediate cache layers, we don't know if it's fresh...) 11:33 < sipa> i'd prefer something weak-block based to have pre-evaluated sets of transactions to apply to the chainstate 11:34 < sdaftuar> sipa: so assuming the set that gets mined is identical to something you were expecting, you can have very fast validation? 11:35 < sipa> sdaftuar: yup 11:35 < sipa> you can basically have the utxo set diff cached 11:36 < gmaxwell> (not just that but you can have the block template for the next block you'd mine after it cached) 11:38 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 11:40 -!- TomMc [~tom@unaffiliated/tommc] has quit [Ping timeout: 265 seconds] 11:48 < bitcoin-git> [bitcoin] morcos opened pull request #9312: Increase mempool expiry time to 2 weeks (master...longerexpiry) https://github.com/bitcoin/bitcoin/pull/9312 11:49 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt] 11:54 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 11:57 -!- TomMc [~tom@unaffiliated/tommc] has joined #bitcoin-core-dev 12:23 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)] 12:34 < gmaxwell> #9295 is an obvious simply bugfix that really would like to be merged (and backported) 12:34 < gribble> https://github.com/bitcoin/bitcoin/issues/9295 | An error has occurred and has been logged. Please contact this bot's administrator for more information. 12:44 < morcos> gmaxwell: the whole requesting parents of orphans functionality... i didn't realize it basically doesn't work when your peer is a core node. were you aware of that? 12:44 < morcos> b/c you won't let a peer getdata a tx that's not in your relay map 12:44 < gmaxwell> morcos: it works so long as the parents are still in the relay pool, or if they're an older version. 12:45 < gmaxwell> (which will answer out of the mempool) 12:45 < gmaxwell> Yes, I knew that when I did it. 12:45 -!- aalex__ [~aalex@64.187.177.58] has joined #bitcoin-core-dev 12:45 < gmaxwell> In particular it's helpful for older versions that still do the trickling.. they're the source of most orphans I see, and they also answer out of the mempool. 12:45 < morcos> ok.. i just noticed it on a new node i started up 12:46 < gmaxwell> I'm glad someone else noticed. 12:47 < morcos> i'm about to PR a small fix to fee filter your minrelaytxfee if your limitfreerelay is 0.. will save some unnecessary free tx requesting/rejecting 12:47 < gmaxwell> thank god. 12:48 < gmaxwell> Re the minrelayfee decay, did much thought or testing go into it? ISTM it looks like it goes too low. e.g. continues dropping at a relatively high speed even once its past a level where your mempool will fill again, given enough time. 12:49 -!- aalex_ [~aalex@64.187.177.58] has quit [Ping timeout: 268 seconds] 12:52 < bitcoin-git> [bitcoin] morcos opened pull request #9313: If we don't allow free txs, always send a fee filter (master...minminfee) https://github.com/bitcoin/bitcoin/pull/9313 12:53 < morcos> gmaxwell: much thought went into it, there is a bit of a discussion on #6722 on my reasoning behind the half-life of 12 hours... But its certainly possible that the tradeoff has changed a bit. 12:53 < gribble> https://github.com/bitcoin/bitcoin/issues/6722 | Limit mempool by throwing away the cheapest txn and setting min relay fee to it by TheBlueMatt · Pull Request #6722 · bitcoin/bitcoin · GitHub 12:54 < morcos> The idea behind the min fee was to protect the limited resource of your memory, so it wasn't meant to be smart enough to know that certain fees are really never going to be worth it.. 12:57 < morcos> Actually rereading the justification now, I think if anything we'd move it the other way.. Packages are limited to much smaller than the 2.5MB envisioned in that argument... So the amount of "free relay" is really small. 12:57 < gmaxwell> morcos: I guess what trips it up is that it decays at a constant rate but the supply of transactions is not uniform (or even 1/rate). 12:58 < morcos> what exactly is the behavior you are seeing that you think is not good 12:59 < gmaxwell> that it drops it back down to nothing and then one of these clowns that relays old transactions connects, fills me back to 300mb... then 72 hours later, these expire, and it slides back down.... 13:00 < gmaxwell> At least in my mind what it should be trying to do is find a value that results in the mempool being close to full-- but it ends up far lower than that; maybe I'm thinking of the wrong goal. 13:01 < morcos> yeah but even if it didn't go down at all, he could do the exact same thing at 2 sat/byte. They still wouldn't be mined within 82 hours 13:01 < morcos> 72 13:01 < sdaftuar> i think modeling the arrival rate of transactions is hard 13:02 < gmaxwell> I think what I'm talking about is as much a question of the distribution of feerates in the supply of unconfirmed transactions, as it is arrival. (more so, because at the 2sat byte level, they're never getting mined.) 13:03 < morcos> i think if you look at tx supply.. there is a backlog of between 1MB - 100MB of txs that pay > 1 sat/byte and there is a backlog of 100-1000MB additional of txs that pay 1 sat/byte it just happens to be the distribution of txs now i think 13:03 < morcos> gmaxwell: ah, but thats wrong 13:04 < morcos> for txs that pay between 1.5-2 sat/byte 95% of them are mined within 1000 blocks and 75% of them are mined within 256 blocks 13:04 < morcos> crazy right 13:05 < gmaxwell> bleh. okay. Crazy. 13:06 -!- aalex_ [~aalex@64.187.177.58] has joined #bitcoin-core-dev 13:06 < morcos> it's just there are sooo many in the 1-1.5 range that only about 10% of them get mined within 1000 blocks 13:10 -!- aalex__ [~aalex@64.187.177.58] has quit [Ping timeout: 260 seconds] 13:30 -!- aalex__ [~aalex@64.187.177.58] has joined #bitcoin-core-dev 13:33 -!- aalex_ [~aalex@64.187.177.58] has quit [Ping timeout: 245 seconds] 13:56 < luke-jr> gmaxwell: hmm, I wonder if we should be rescanning for conflicts then (#9290) 13:56 < gribble> https://github.com/bitcoin/bitcoin/issues/9290 | Make RelayWalletTransaction attempt to AcceptToMemoryPool. by gmaxwell · Pull Request #9290 · bitcoin/bitcoin · GitHub 13:57 < gmaxwell> luke-jr: make rescan take less than N hours? :-/ 13:57 < luke-jr> hours now? :o 13:57 < gmaxwell> I think it takes 5 on my laptop. 13:57 < gmaxwell> on a really fast machine it's not so terrible. 13:58 < luke-jr> I guess ideally we should be waiting until the blockchain is synced, checking if we have unconfirmed txns, checking a wallet flag, and rescanning at runtime 13:58 < luke-jr> sounds complex though :/ 13:59 < luke-jr> (oh, and then we could simply not broadcast unconfirmed txns until it finishes the rescan) 13:59 < gmaxwell> the 'getting real fee info' will be another reason to rescan the chain for all wallets. 13:59 < gmaxwell> so it would be worth giving some thought to adding an extra kinda of versioning to the wallet (metadata-rescanned-since).. and making rescan faster... 13:59 < luke-jr> yeah 14:00 < luke-jr> "rescan depth" or something 14:00 < sdaftuar> luke-jr: it's in general not really possible to always know that a transaction is conflicted. i think we should keep that in mind before doing anything expensive... 14:00 < gmaxwell> well they won't broadcast if conflicted-- they'll fail for mempool add. so the only harm is wasting a little time trying to look up utxos that aren't there. 14:00 < luke-jr> to be happy with downgrading+upgrading, we'd need a timestamp per each depth, but that seems unnecessarily over-compatible 14:01 < dcousens> gmaxwell: rescan is for private keys no? 14:01 < dcousens> or is it UTXO? 14:01 < luke-jr> gmaxwell: oh, right. that's not too bad compared to hours rescanning 14:01 < luke-jr> sdaftuar: ah, parent conflicts 14:02 < gmaxwell> Yes, though we won't spend non-wallet inputs (ignoring coinjoins because stupid) until they are six confirms old. 14:02 < gmaxwell> So it's really hard to end up in a case where there is an undetectable conflict in your wallet. 14:02 < luke-jr> gmaxwell: if someone else sends you a payment using coins later conflicted? 14:03 < dcousens> why is rescan so slow? is it because it tries to match all possible scripts or? 14:03 < gmaxwell> luke-jr: you won't spend that payment until it is 6 confirmed. 14:03 < gmaxwell> dcousens: I think much (most?) of the time is spent hashing the blocks. 14:04 < luke-jr> gmaxwell: but you'll try to mempool-add the receive, no? 14:04 < gmaxwell> luke-jr: okay, sure nevermind me.. that payment itself will be an undetectable conflict, I was only thinking about IsFromMe transactions. 14:04 < dcousens> gmaxwell: why is it hashing blocks? (i'll look into the code ooi) 14:05 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has quit [Quit: Leaving.] 14:05 < gmaxwell> dcousens: side-effect of deseralization. 14:06 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has joined #bitcoin-core-dev 14:07 < dcousens> gmaxwell: still weir,t I use similar enough deserialization code (lib/consensus) in my own parser and it does a full parse purely bottlenecked at IO, so 3-4 minutes on an SSD, script checking shouldn't be much more on that i'd of though... 14:07 < dcousens> but I guess I'd have to look into the code to find out why 14:09 < gmaxwell> At least my vague recollection of profiling it before was that the time was all in the heap allocator and sha256. 14:12 < dcousens> gmaxwell: hmmm, by hashing do you mean the merkle tree generation? 14:13 < dcousens> well, merkle root calculation*** 14:13 < gmaxwell> I assume, I don't know what else sha256 would be used for while scanning blocks. 14:14 < sipa> the checksum? 14:15 < sipa> blocks on disk have a checksum, i think? 14:15 < sipa> or am i confusing it with peers.day 14:15 < dcousens> sipa: they have a magic byte 14:15 < dcousens> no checksum afaik 14:15 < gmaxwell> fun random graph https://people.xiph.org/~greg/temp/blk-sizes-windowed.png 14:16 < dcousens> a checksum would probably work wonders in bypassing that 14:16 < dcousens> esp. given the situation of all the zero padding in the files 14:41 -!- CubicEarth [~cubiceart@2002:329f:7e15:0:9188:a7c5:5f4a:f82f] has quit [Read error: Connection reset by peer] 14:41 -!- CubicEarth [~cubiceart@2002:329f:7e15:0:9909:f524:6820:33da] has joined #bitcoin-core-dev 14:43 -!- aalex_ [~aalex@64.187.177.58] has joined #bitcoin-core-dev 14:43 -!- Samdney [~Samdney@178.162.209.132] has quit [Quit: Verlassend] 14:44 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has quit [Ping timeout: 258 seconds] 14:44 -!- MykelSIlver [~MykelSIlv@192-228-145-85.ftth.glasoperator.nl] has joined #bitcoin-core-dev 14:46 -!- aalex__ [~aalex@64.187.177.58] has quit [Ping timeout: 265 seconds] 14:53 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 14:58 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-ywoixdrhkfsdfjvi] has quit [Quit: Connection closed for inactivity] 15:00 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 15:06 -!- AaronvanW [~ewout@207pc74.sshunet.nl] has joined #bitcoin-core-dev 15:06 -!- AaronvanW [~ewout@207pc74.sshunet.nl] has quit [Changing host] 15:06 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 15:11 < dcousens> RE: 9312, 2 week expiration time, won't that further prevent parties from attempting broadcast a conflict of a stuck transaction 2.1 days after the first broadcast, and having a high chance of the other transaction being "mostly" out of the network by then? 15:11 < dcousens> of course, that is what RBF is for, but 15:13 < gmaxwell> dcousens: not really. (1) right now those conflicts are pretty successful immediately; due to nodes restarting, full-rbf miners, etc. (2) there are people who go around connecting to everyone constantly rebroadcasting old transactions... so they're already defeating that timeout. 15:13 < dcousens> gmaxwell: in practice it works though? 15:14 < dcousens> oh wait, misread what you wrote 15:14 < gmaxwell> in practice it works even in 1 hour, so it works-- but not because of the 72 hour timeout. 15:14 < dcousens> yeah 15:16 < gmaxwell> we could also consider adding a new datastructure, a blacklist: if something hits the expire time, that txid becomes blacklisted for n-months. That would actually make things much easier to replace with a double spend after two weeks. 15:17 < dcousens> gmaxwell: is there a way to "push out" a transaction from the mempool using the RPC? aka, "oops, forget the last one, use this instead" 15:17 < dcousens> aka, ignore conflicts, or drop conflicts 15:18 < dcousens> just thinking about you could by-pass that timeout without wiping your local mempool 15:18 < dcousens> obviously that wouldn't help others 15:18 < dcousens> but, as you say, others are quite the dynamic 15:22 < gmaxwell> dcousens: kinda useless to do something locally, it won't do it to anyone else... 15:25 < dcousens> gmaxwell: depending on their expiration timeout, mempool size & fee filter, full-RBF, etc, could go either way no? 15:26 < gmaxwell> dcousens: you can send things that aren't in your mempool, the whitelisting stuff does that already. 15:27 < dcousens> gmaxwell: true 15:35 -!- CubicEarth [~cubiceart@2002:329f:7e15:0:9909:f524:6820:33da] has quit [Remote host closed the connection] 15:54 -!- cryptapus is now known as cryptapus_afk 16:01 -!- wvr [~wvr@0.red-88-15-41.dynamicip.rima-tde.net] has quit [Read error: Connection reset by peer] 16:04 < gmaxwell> sipa: 9295 calls to you, -- /merge me/ /merge me/ 16:13 -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has quit [Ping timeout: 265 seconds] 16:15 < bitcoin-git> [bitcoin] sipa pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/72bf1b3d0962...815640ec6af9 16:15 < bitcoin-git> bitcoin/master c24a4f5 Jonas Schnelli: [Wallet] Bugfix: FRT: don't terminate when keypool is empty 16:15 < bitcoin-git> bitcoin/master 1a6eacb Jonas Schnelli: [QA] add fundrawtransaction test on a locked wallet with empty keypool 16:15 < bitcoin-git> bitcoin/master 815640e Pieter Wuille: Merge #9295: [Wallet] Bugfix: Fundrawtransaction: don't terminate when keypool is empty... 16:15 < bitcoin-git> [bitcoin] sipa closed pull request #9295: [Wallet] Bugfix: Fundrawtransaction: don't terminate when keypool is empty (master...2016/12/fix_frt) https://github.com/bitcoin/bitcoin/pull/9295 16:21 < bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/815640ec6af9...d38b0d7a6b60 16:21 < bitcoin-git> bitcoin/master fe41f58 Russell Yanofsky: Remove undefined FetchCoins method declaration 16:21 < bitcoin-git> bitcoin/master d38b0d7 Pieter Wuille: Merge #9307: Remove undefined FetchCoins method declaration... 16:22 < bitcoin-git> [bitcoin] sipa closed pull request #9307: Remove undefined FetchCoins method declaration (master...pr/coins-delfetch) https://github.com/bitcoin/bitcoin/pull/9307 16:31 < bitcoin-git> [bitcoin] sipa pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/d38b0d7a6b60...a1dcf2e1087b 16:31 < bitcoin-git> bitcoin/master bf663f8 Alex Morcos: remove external usage of mempool conflict tracking 16:31 < bitcoin-git> bitcoin/master a874ab5 Alex Morcos: remove internal tracking of mempool conflicts for reporting to wallet 16:31 < bitcoin-git> bitcoin/master a1dcf2e Pieter Wuille: Merge #9240: Remove txConflicted... 16:31 < bitcoin-git> [bitcoin] sipa closed pull request #9240: Remove txConflicted (master...removeTxConflicted) https://github.com/bitcoin/bitcoin/pull/9240 16:36 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has joined #bitcoin-core-dev 16:41 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has quit [Ping timeout: 260 seconds] 16:43 -!- vorksholk [ae1cac5c@gateway/web/freenode/ip.174.28.172.92] has joined #bitcoin-core-dev 16:53 -!- murch [~murch@p4FE38618.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 16:57 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has quit [Quit: Textual IRC Client: www.textualapp.com] 17:18 -!- JackH [~laptop@79-73-186-159.dynamic.dsl.as9105.com] has quit [Ping timeout: 246 seconds] 17:37 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has joined #bitcoin-core-dev 17:41 -!- brg444 [~bergealex@qubcpq1531w-lp130-02-65-92-226-222.dsl.bell.ca] has joined #bitcoin-core-dev 17:42 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has quit [Ping timeout: 244 seconds] 17:54 -!- brg444_ [~bergealex@qubcpq1531w-lp130-02-65-92-226-222.dsl.bell.ca] has joined #bitcoin-core-dev 17:55 -!- brg444 [~bergealex@qubcpq1531w-lp130-02-65-92-226-222.dsl.bell.ca] has quit [Ping timeout: 258 seconds] 17:55 -!- brg444_ is now known as brg444 18:35 -!- brg444_ [~bergealex@qubcpq1531w-lp130-02-65-92-226-222.dsl.bell.ca] has joined #bitcoin-core-dev 18:37 -!- brg444 [~bergealex@qubcpq1531w-lp130-02-65-92-226-222.dsl.bell.ca] has quit [Ping timeout: 258 seconds] 18:37 -!- brg444_ is now known as brg444 18:37 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has joined #bitcoin-core-dev 18:49 -!- alpalp [~allen@cpe-24-27-58-209.austin.res.rr.com] has joined #bitcoin-core-dev 18:49 -!- alpalp [~allen@cpe-24-27-58-209.austin.res.rr.com] has quit [Changing host] 18:49 -!- alpalp [~allen@unaffiliated/alpalp] has joined #bitcoin-core-dev 18:52 < gmaxwell> There is now several percent of hashpower producing blocks with version=0x30000000 ... what is that? 18:56 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-hljdvudwsfpdpgdq] has joined #bitcoin-core-dev 19:03 -!- alpalp [~allen@unaffiliated/alpalp] has quit [Remote host closed the connection] 19:12 -!- alpalp [~allen@cpe-24-27-58-209.austin.res.rr.com] has joined #bitcoin-core-dev 19:12 -!- alpalp [~allen@cpe-24-27-58-209.austin.res.rr.com] has quit [Changing host] 19:12 -!- alpalp [~allen@unaffiliated/alpalp] has joined #bitcoin-core-dev 19:17 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-xkoywnheodgqvrfi] has quit [Quit: Connection closed for inactivity] 19:32 -!- echonaut [~echonaut@46.101.192.134] has joined #bitcoin-core-dev 19:33 -!- TomMc [~tom@unaffiliated/tommc] has quit [Ping timeout: 262 seconds] 19:33 -!- echonaut [~echonaut@46.101.192.134] has quit [Remote host closed the connection] 19:34 -!- echonaut [~echonaut@46.101.192.134] has joined #bitcoin-core-dev 19:34 -!- lightningbot [~supybot@2400:8901::f03c:91ff:febb:bbc1] has quit [Disconnected by services] 19:35 -!- BCBot_ [~BCBot@46.101.246.115] has joined #bitcoin-core-dev 19:36 -!- BCBot [~BCBot@46.101.246.115] has quit [Write error: Broken pipe] 19:36 -!- echonaut9 [~echonaut@46.101.192.134] has quit [Remote host closed the connection] 19:36 -!- lightningbot [~supybot@2400:8901::f03c:91ff:febb:bbc1] has joined #bitcoin-core-dev 19:37 -!- rabidus_ [~rabidus@uhiainen.com] has joined #bitcoin-core-dev 19:37 -!- sipa_ [~pw@2a02:348:86:3011::1] has joined #bitcoin-core-dev 19:37 -!- kinlo_ [peter@unaffiliated/kinlo] has joined #bitcoin-core-dev 19:38 -!- rabidus [~rabidus@uhiainen.com] has quit [Write error: Broken pipe] 19:38 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has quit [Write error: Broken pipe] 19:38 -!- kinlo [peter@unaffiliated/kinlo] has quit [Read error: Connection reset by peer] 19:38 -!- sipa [~pw@unaffiliated/sipa1024] has quit [Remote host closed the connection] 19:38 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has joined #bitcoin-core-dev 19:38 -!- kinlo_ is now known as kinlo 19:43 -!- jannes [~jannes@178.132.211.90] has quit [Quit: Leaving] 20:08 -!- chris2000 [~chris2000@p5DCB510A.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer] 20:14 -!- brg444 [~bergealex@qubcpq1531w-lp130-02-65-92-226-222.dsl.bell.ca] has quit [Quit: brg444] 20:20 -!- alpalp [~allen@unaffiliated/alpalp] has quit [Ping timeout: 248 seconds] 21:47 -!- droark [~droark@c-24-22-123-27.hsd1.or.comcast.net] has joined #bitcoin-core-dev 21:50 -!- To7 [~theo@cpe-158-222-222-232.nyc.res.rr.com] has joined #bitcoin-core-dev 22:08 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has quit [Quit: Leaving.] 22:50 -!- cannon-c [ccc23f04@gateway/web/freenode/ip.204.194.63.4] has joined #bitcoin-core-dev