--- Day changed Thu Dec 08 2016 00:10 -!- ratoder [~ratoder@static.111.19.201.138.clients.your-server.de] has joined #bitcoin-core-dev 00:18 -!- Cory [~Cory@unaffiliated/cory] has quit [Ping timeout: 268 seconds] 00:27 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 00:40 -!- laptop__ [~laptop@79-73-186-159.dynamic.dsl.as9105.com] has quit [Quit: Leaving] 00:40 -!- JackH [~laptop@79-73-186-159.dynamic.dsl.as9105.com] has joined #bitcoin-core-dev 00:50 -!- echonaut9 [~echonaut@46.101.192.134] has joined #bitcoin-core-dev 00:50 -!- echonaut [~echonaut@46.101.192.134] has quit [Read error: Connection reset by peer] 01:09 -!- Cory [~Cory@unaffiliated/cory] has joined #bitcoin-core-dev 01:17 -!- LeMiner2 [~LeMiner@5ED1AFBF.cm-7-2c.dynamic.ziggo.nl] has joined #bitcoin-core-dev 01:18 -!- LeMiner [~LeMiner@unaffiliated/leminer] has quit [Ping timeout: 260 seconds] 01:18 -!- LeMiner2 is now known as LeMiner 01:18 -!- harrymm [~wayne@104.237.91.137] has quit [Ping timeout: 260 seconds] 01:34 -!- harrymm [~wayne@104.237.91.209] has joined #bitcoin-core-dev 01:40 -!- laurentmt [~Thunderbi@80.215.178.140] has joined #bitcoin-core-dev 01:41 -!- laurentmt [~Thunderbi@80.215.178.140] has quit [Client Quit] 01:47 -!- Guest62446 [~ChillazZ@194.97.152.20] has quit [Quit: leaving] 01:47 -!- ChillazZ [~ChillazZ@194.97.152.20] has joined #bitcoin-core-dev 01:48 -!- ChillazZ is now known as Guest80396 02:39 -!- AaronvanW [~ewout@207pc74.sshunet.nl] has joined #bitcoin-core-dev 02:39 -!- AaronvanW [~ewout@207pc74.sshunet.nl] has quit [Changing host] 02:39 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 02:42 -!- Atomicat [~Atomicat@unaffiliated/atomicat] has joined #bitcoin-core-dev 02:58 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has quit [] 03:27 -!- emzy [~quassel@raspberry.emzy.de] has quit [Quit: No Ping reply in 180 seconds.] 03:29 -!- emzy [~quassel@raspberry.emzy.de] has joined #bitcoin-core-dev 03:43 -!- laurentmt [~Thunderbi@80.215.138.103] has joined #bitcoin-core-dev 03:45 -!- laurentmt [~Thunderbi@80.215.138.103] has quit [Client Quit] 04:08 < wumpus> sipa: seed.bitcoin.sipa.be is not returning any results here 04:12 < bitcoin-git> [bitcoin] laanwj pushed 5 new commits to 0.13: https://github.com/bitcoin/bitcoin/compare/0a4aa876230c...e591c1049fe5 04:12 < bitcoin-git> bitcoin/0.13 4c71fc4 Matt Corallo: Remove duplicate nBlocksEstimate cmp (we already checked IsIBD())... 04:12 < bitcoin-git> bitcoin/0.13 ad20cdd Gregory Maxwell: IBD check uses minimumchain work instead of checkpoints.... 04:12 < bitcoin-git> bitcoin/0.13 5b93eee Gregory Maxwell: Remove GetTotalBlocksEstimate and checkpoint tests that test nothing.... 04:27 -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 04:30 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 265 seconds] 05:09 < BlueMatt> wait...wut 05:09 < BlueMatt> why did that get backported??? 05:12 < wumpus> BlueMatt: https://github.com/bitcoin/bitcoin/pull/9293 also there was some discussino here earlier 05:13 < BlueMatt> wumpus: I meant specifically my commit there 05:14 < BlueMatt> maybe was needed to make the commits apply cleanly 05:14 < BlueMatt> it just surprised me 05:15 < wumpus> I wouldn't know that, best to ask gmaxwell 05:17 < wumpus> but I suppose his reason for grabbing just that commit is that it intersected with #9053 in some way 05:17 < gribble> https://github.com/bitcoin/bitcoin/issues/9053 | IBD using chainwork instead of height and not using header timestamps by gmaxwell · Pull Request #9053 · bitcoin/bitcoin · GitHub 05:20 < BlueMatt> wumpus: yes, that was my guess 05:20 < BlueMatt> nbd anyway 05:21 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has quit [Ping timeout: 268 seconds] 05:28 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has joined #bitcoin-core-dev 05:42 < cfields> fyi, BlueMatt and I won't make it to the meeting today, we're on the other side of the world 05:43 < cfields> also a bit slow to work through pr comments/review. certainly not ignoring though :) 05:44 -!- laurentmt [~Thunderbi@80.215.138.103] has joined #bitcoin-core-dev 06:02 -!- laurentmt [~Thunderbi@80.215.138.103] has quit [Quit: laurentmt] 06:04 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has quit [Ping timeout: 246 seconds] 06:06 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has joined #bitcoin-core-dev 06:08 -!- shockoo [~shockoo@ip-94-112-163-197.net.upcbroadband.cz] has joined #bitcoin-core-dev 06:17 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 06:31 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 06:31 < btcdrak> wumpus: #7562 is ready for merge 06:31 < gribble> https://github.com/bitcoin/bitcoin/issues/7562 | Bump transaction version default to 2 by btcdrak · Pull Request #7562 · bitcoin/bitcoin · GitHub 06:49 < morcos> btcdrak: i'm fine with you leaving that commit out, but how coudl that cause those errors? 06:50 < btcdrak> morcos: It was totally fine locally, Travis threw up and it's just not worth my time fighting with it. Will have another go once merged. 06:50 < btcdrak> even paveljanik was ok with it locally :/ 06:50 < morcos> weird.. 06:54 -!- shockoo [~shockoo@ip-94-112-163-197.net.upcbroadband.cz] has quit [Read error: Connection reset by peer] 07:21 -!- TomMc [~tom@unaffiliated/tommc] has joined #bitcoin-core-dev 07:34 -!- TomMc [~tom@unaffiliated/tommc] has quit [Ping timeout: 250 seconds] 07:39 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has joined #bitcoin-core-dev 07:40 -!- Sosumi [~Leon@bl10-113-190.dsl.telepac.pt] has joined #bitcoin-core-dev 07:44 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 07:45 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 246 seconds] 07:48 -!- TomMc [~tom@unaffiliated/tommc] has joined #bitcoin-core-dev 07:58 -!- laurentmt [~Thunderbi@80.215.138.103] has joined #bitcoin-core-dev 07:58 -!- laurentmt [~Thunderbi@80.215.138.103] has quit [Client Quit] 08:27 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 08:30 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 258 seconds] 08:33 < morcos> sipa: this is minor, but i'm curious in loadmempool why you chose to use state.IsValid for reporting # of successes, it's certainly possible for the state to be valid but the tx not be accepted 08:49 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 08:58 -!- jtimon [~quassel@77.224.94.35] has joined #bitcoin-core-dev 09:01 < morcos> btcdrak: unfortunately it still fails for me locally... since i gave you a weasly non-review of that json test data stuff, i'll see if i can track down the issue . especially weird that it passes travis sometimes 09:02 < btcdrak> Did we update Univalue at all recently? 09:03 < btcdrak> I fixed a bug in it which will break those json tests when we sync up 09:03 -!- MarcoFalke_ [8af602fa@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.250] has joined #bitcoin-core-dev 09:03 < btcdrak> https://github.com/jgarzik/univalue/pull/29 09:04 < MarcoFalke_> btcdrak: We can do that some time before 0.14, if necessary. 09:04 < MarcoFalke_> See https://github.com/bitcoin-core/univalue/pull/4 09:05 < MarcoFalke_> We might want to wait for some of the fixes after testing with the JSONtestSuite 09:06 < sipa> morcos: re state.IsValid for loadmempool... good point, i just didn't realize that 09:12 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has quit [Quit: Leaving.] 09:15 < morcos> btcdrak: the reason it sometimes passes travis is somethign later changed in master to cause your PR to break 09:15 < morcos> the merge that travis ran on for the PR that is up there now is an old merge, i think if you locally checkout a new merge it'll probably break for you 09:15 < btcdrak> morcos: oh, thank you for looking at that. If that can be solved, I'll push the rebased version with your other fix in 09:16 < btcdrak> oh, ofc, I'm not rebased to master... makes sense now 09:18 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection] 09:18 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 09:22 < morcos> yeah but ideally travis would be running on your PR merged with master, its not clear to me how that works exactly or why its not the case here 09:22 < morcos> i don't know the details of when travis decides it needs to rerun the merge 09:22 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 260 seconds] 09:30 < btcdrak> morcos: ok I can replicate it now locally! 09:30 < btcdrak> at least with something to replicate I can investigate 09:36 < morcos> btcdrak: maybe something to do with https://github.com/bitcoin/bitcoin/pull/9100 ? 09:39 < morcos> btcdrak: oh never mind, i should read the errors more closly 09:39 < morcos> it's #8837 09:39 < gribble> https://github.com/bitcoin/bitcoin/issues/8837 | allow bitcoin-tx to parse partial transactions by jnewbery · Pull Request #8837 · bitcoin/bitcoin · GitHub 09:39 < morcos> there were two new tests added 09:41 < sipa> morcos: i think the version travis test is always a merge with master at the time of the last push 09:43 < btcdrak> what happened to #9023 I thought it produced diffs when I reviewed it, now it doesnt. 09:43 < gribble> https://github.com/bitcoin/bitcoin/issues/9023 | Add logging to bitcoin-util-test.py by jnewbery · Pull Request #9023 · bitcoin/bitcoin · GitHub 09:43 < morcos> sipa: so it's surprising that bugs like this don't happen more often 09:44 < morcos> the only reason we caught this is btcdrak tried to do a new push... but if he hadn't, there would have been no merge conflict and it wouldn't have been caught... luckily in this case it resulted in a test failing 09:45 < morcos> btcdrak: it's definitely 8837 and its a trivial fix fo ryou 09:50 -!- laurentmt [~Thunderbi@80.215.138.103] has joined #bitcoin-core-dev 09:52 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 09:57 < MarcoFalke_> morcos: We have merge conflicts every couple of weeks. I'd propose to invalidate travis results after 2 or 3 weeks. 09:58 < MarcoFalke_> * silent merge conflicts 10:00 -!- laurentmt [~Thunderbi@80.215.138.103] has quit [Quit: laurentmt] 10:01 < morcos> MarcoFalke_: could there be a pre-merge button which reruns travis when wumpus or whoever thinks the PR is ready for merge? i guess it would be annoying to revisit it a second time, and scary to auto-merge if it passes 10:02 < morcos> maybe someone else could be in charge or pressing the pre-merge button on almost ready to be merged PR's even if it doesn't catch them all, if it catches some and doesn't slow down wumpus, it'll be good 10:05 < MarcoFalke_> I was more thinking of something automated. for pull in pulls: rerun if travis_result.age > 14 days; 10:07 < btcdrak> morcos: great. I'll take a look in a bit 10:12 < morcos> MarcoFalke_: yeah i was just thinking its more useful if its close to actual merge and unnecessary if its not 10:16 < gmaxwell> it would be helpful if we could figure out the causes of varrious bits of failed dependency tracking, since it also effects users and not just travis. 10:16 < MarcoFalke_> Would still catch some of the silent merge conflicts. If it is only done pre merge, it would slow down the merge process unnecessarily. 10:17 < MarcoFalke_> If it passed, it is just wasted time. If it fails, the pull author needs go back anyway. 10:18 < gmaxwell> BlueMatt: Because the thing actually being backported eliminated the checkpoint estimate of the number of blocks; so it needed that change of yours that eliminated a call to it. Otherwise the change was trivial and wouldn't have been backported. 10:24 < morcos> If we're doign a wallet opperation, whats the rule of thumb with whether we open our CWalletDB with fFlushOnClose true or not? 10:27 < wumpus> depends on whether data loss would lead to funds loss IIRC 10:27 < morcos> For instance in AbandonTransaction I copied MarkConflicted which doesn't flush on close "for performance reasons" but in retrospect it seems almost everything else does flush on close and maybe is only because MarkConflicted gets called inside a loop 10:28 < wumpus> in case of doubt, flush on close 10:29 < morcos> so perhaps in the markconflicted case we should do a specific flush after all the conflicting has been done? (seems more important than abandon anyway) 10:31 < wumpus> but is it critical? e.g., not just something that could be repeated after starting the client? 10:34 < wumpus> though I don't think it hurts to do an explicit flush afterwards 10:35 < morcos> wumpus: i don't know i'm out of my depth... 10:35 < wumpus> although the wallet is being flushed+consolidated all the time, periodically, by the wallet flush thread if an update has been done - the point of flushonclose is just to do a flush immediately, for critical things 10:35 < morcos> i'm not sure what how wallet state and chainstate are kept in sync 10:36 < wumpus> the wallet stores the last position that it is synced to, it will rescan from there on on client start 10:38 < morcos> yeah ok, thats what i was just seeing, so yeah maybe you're right... it not an issue.. 10:56 -!- TomMc [~tom@unaffiliated/tommc] has quit [Ping timeout: 260 seconds] 11:00 < wumpus> meeting time? 11:00 < jonasschnelli> yes 11:00 < wumpus> #startmeeting 11:00 < lightningbot> Meeting started Thu Dec 8 19:00:40 2016 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot. 11:00 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic. 11:01 < wumpus> proposed topics? 11:02 < gmaxwell> #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 11:02 < instagibbs> here 11:02 < sdaftuar> hi 11:02 < btcdrak> sort of here 11:02 < CodeShark> hello 11:03 < kanzure> hi. 11:03 < gmaxwell> I'd like to briefly talk about #9290 11:03 < gribble> https://github.com/bitcoin/bitcoin/issues/9290 | Make RelayWalletTransaction attempt to AcceptToMemoryPool. by gmaxwell · Pull Request #9290 · bitcoin/bitcoin · GitHub 11:03 < morcos> i'd like to discuss increasing mempool tx expiry time but nto sure if thats a meeting topic 11:04 < wumpus> #topic #9290 Make RelayWalletTransaction attempt to AcceptToMemoryPool 11:04 < gribble> https://github.com/bitcoin/bitcoin/issues/9290 | Make RelayWalletTransaction attempt to AcceptToMemoryPool. by gmaxwell · Pull Request #9290 · bitcoin/bitcoin · GitHub 11:05 < gmaxwell> There was previously a concern expressed (sorry, I forget who); that trying to reaccept to mempool all unconfirmed txn might be a cpu load for some wallet gunked up with unconfirmed transactions. I made this PR anyways, noting that it doesn't apply to abandoned or known conflicted txn, and I don't believe gunked up wallets exist at any real rate-- if they do, then that is its own problem.. and 11:05 < gmaxwell> they could avoid a performance issue by abandoning. I hope this is convincing but I haven't had feedback on that point. 11:06 < gmaxwell> Beyond that question, this is a really obvious bugfix for a somewhat embarassing misbehavior. 11:06 < wumpus> well at least it's now possible to get rid of unconfirmed transactions by abandoning them 11:06 < morcos> gmaxwell: that was (at least) me, but i made my mark on your PR.. suhas beat me down into being unable to succesfully argue my position 11:06 < wumpus> there should be no need to have excessive numbers of unconfirmed transactinons 11:07 < sdaftuar> gmaxwell: i agree with the PR and the backport, fwiw 11:07 < gmaxwell> morcos: hah. I missed the was here. okay thats precisely what I was looking for. 11:07 < morcos> but as for backporting... 11:07 < morcos> maybe ok for that one... but i'm not so sure about #9262 11:07 < gmaxwell> I just felt a little uncomfortable doing something I knew someone had expressed concern with; without making sure that we heard if concerns remained. 11:08 < gribble> https://github.com/bitcoin/bitcoin/issues/9262 | Prefer coins that have fewer ancestors, sanity check txn before ATMP by instagibbs · Pull Request #9262 · bitcoin/bitcoin · GitHub 11:08 < morcos> i feel like although these are definitely fixing poor behavior... they're also fairly large changes in behavior and it worries me that in a backport, they wont' get enough testing to be sure they don't raise new issues 11:08 < morcos> personally i think we backport too much 11:08 < gmaxwell> Well I think we must backport at least one of 9262 or 9290. If you backport 9290 I think there is less need to backport 9262 and if we only do one I'd prefer it be 9290. 11:08 < morcos> backports should be for either critical or simple bugs 11:09 < morcos> gmaxwell: why? that behavior has been like that for several major versions no? 11:09 < morcos> do we think it is more of an issue now b/c of occasional mempool backlogs? 11:09 < gmaxwell> The issue that these are collectively fixing are stuck coins in wallets which combined with user error can lead to funds loss. We are currently having resports from multiple users encountering it. 11:09 < gmaxwell> morcos: ding ding. 11:09 < luke-jr> backporting all bugfixes is fine if we do RCs IMO; critical/simple criteria mainly makes sense for security stuff 11:09 < sdaftuar> i think 9290 is simple, and implements the behavior we all thought was already happening 11:10 < gmaxwell> luke-jr: thats going offtopic but I don't fully agree. 11:10 < morcos> yes, 9290 is pretty simple 11:10 < gmaxwell> for 9262 if 9290 is in place there is an argument that the default behavior should change (don't refuse to create the failing txn.) 11:10 < gmaxwell> which is another question. 11:10 < morcos> i'd feel a bit easier about that one i guess... , and although i have no idea what might go wrong with 9262, you never know 11:11 < sipa> do we have a patch that deal with ATMP failing in createtransactionm 11:11 < sipa> ? 11:11 < gmaxwell> well as is 9262 adds another reason for a send rpc to fail, which is user visible. With 9290 there is a lot less reason for that. I felt that that behavior change was not very sutiable for backport which is why I created 9290. 11:11 < morcos> yes, if we can briefly dive into that other question... one argument for refusing to create a failing tx is that if you try again you might succeed... 11:11 < sipa> that would be much less invasive to backport 11:11 < morcos> but not sure how deterministic the coin selection is 11:12 < michagogo> o/ 11:12 < gmaxwell> morcos: since unconfirmed coins are a last resort already your odds are not good. with the rest of 9262 in place... your odds are probably nearly zero. 11:12 < morcos> sipa: 9262 makes it much less likely that you will get to ATMP fail at least for the reason of chains. 11:12 < sipa> morcos: i know, but it is not fully generic 11:13 -!- TomMc [~tom@unaffiliated/tommc] has joined #bitcoin-core-dev 11:13 < morcos> gmaxwell: i disagree i think... since it all depends on how many coins you end up using as inputs, which is not a factor in our logic now 11:13 < instagibbs> fully generic would be something like justCheck ATMP 11:13 < sipa> morcos: i would be much more confortable with something that deals correctly with an occasional failurr, rather than trying our best to avoid failures 11:13 < gmaxwell> The mempool chain limit change is transitory, which is why I believe avoid + rebroadcast is the right solution. 11:13 < morcos> sipa: but as gmaxwell would probably argue, depending ont he reason for your failure you might want to do different things, so its maybe not a simple patch 11:14 < sipa> morcos: well we can still use whatever logic to avoid the failure 11:14 < sipa> but knowing that we don't get into hard-to-recover states would give more peace of mind 11:14 < gmaxwell> morcos: for 9262 I say very low because if it was possible to avoid the failure it likely would have due to the prior selectcoins runs. the only time where a retry would work is where it couldn't be done with low count coins, could be done with midcount coins and the retry gets lucky. 11:15 < gmaxwell> sipa: transitory failure is not a hard to recover state. 11:15 < gmaxwell> at least not any worse than "I paid too little fee" 11:15 < morcos> gmaxwell: no i don't think so.. some of your low count coins may have ancestors with other descendants.. you may choose a lot of low value low count coins, vs just 1 high value one.. etc.. 11:15 < gmaxwell> I believe (someone can correct) that there is now no way to get a failure there except a transitory one. But belt and suspenders could be fine. 11:16 < sipa> gmaxwell: well at least you'd know your transaction was not broadcast immediately 11:16 < sipa> gmaxwell: and i'm talking more generically than chain depth limits 11:16 < morcos> gmaxwell: definitely can get non-transitory failures... i have some wallet that everytime i start the node tries to broadcast a too high fee tx 11:16 < gmaxwell> sipa: you never really know that, since we have no monitoring to tell if the broadcasts were successful. I think we should seperately track successful broadcasts in the wallet. some lite wallets do this. 11:16 < sipa> gmaxwell: ATMP is complicated 11:17 < morcos> if it wasn't ATMP, then it wasn't broadcast 11:17 < gmaxwell> morcos: yes but it can be ATMP and never broadcast. 11:17 < sipa> gmaxwell: i mean: since we *can* recover from failure to ATMP, we should 11:17 < sdaftuar> perhaps a simple backport would be to return the txid of the failed to ATMP transaction back to the RPC caller, once it's been added to the wallet? 11:17 < MarcoFalke_> I am not against backporting 9290, but if we do, I'd prefer a small section in the release notes. Previously one could just resend the tx and figure out the problem later. Now, it might cause you to fund the same recipient twice. 11:17 < gmaxwell> sipa: "recover", I don't think I agree. Backing out a send and returning an error is not recovery. 11:17 < sdaftuar> that seems strictly better than prior behavior 11:18 < sdaftuar> and after 9290, semi-reasonable 11:18 < gmaxwell> It just pushes error handling downstream to a caller that likely has none. 11:18 < sipa> are we sure that every ATMP failure is temporary? 11:18 < morcos> to bring it back to what we should backport.. i'd say at most 9290 .. and lets concentrate on the more robust fix for 0.14 11:18 < gmaxwell> MarcoFalke_: I am confused as to what you believe the effect of 9290 is. 11:18 < instagibbs> sipa, I have some memory of absurd fee issue, but not on hand 11:19 < gmaxwell> sipa: I believed that was the case, though morcos just pointed out something about a too-high-fee txn. 11:19 < gmaxwell> I would agree that returning an error on non-temporary failures would be good. 11:19 < morcos> the high fee code did change, so not sure if that got fixed 11:19 < sdaftuar> morcos: i disagree with just doing 9290. the rpc situation is a disaster when you get an RPC failure for a created tx 11:19 < sipa> gmaxwell: sendtoaddress can already fail in various ways before even attempting ATMP (for example, tx too large, insufficient funds, ..) that the caller needs to deal with 11:20 < morcos> sdaftuar: its been like that forever though! i agree we should fix it, but we shouldn't be just now designing a fix to push out in a backport 11:20 < morcos> it will not get sufficient testing 11:20 < gmaxwell> morcos: it hasn't been like that forever because the failures are modulated by network conditions. 11:20 < MarcoFalke_> gmaxwell: 9290 will put tx in your mempool that previously failed to be accepted while running. We did never do that. (only after restart) 11:21 < gmaxwell> some people that never built unconfirmed chains are building them now. 11:21 < morcos> i guess i just think we are close enough to 0.14, that we should concetnrate on a good and well tested fix for that 11:22 < gmaxwell> MarcoFalke_: We did it at every restart. So you couldn't have counted on the behavior. And you also would have had no way of knowing that it failed on the very first try. 11:22 < morcos> i'm always worried about unintended consequences of these things 11:22 < sdaftuar> morcos: what is your objection to my proposal above, of returning the txid of the failed-to-accept-tomempool transaction, that is now in your wallet? 11:22 < sdaftuar> i think that should be a simple change, and just tells the users what is going on 11:22 < wumpus> I tend to agree with morcos - better to focus on a good solution for 0.14, then try to rush something for 0.13.2 last minute 11:23 < gmaxwell> well I don't feel this is rushed. :) 11:23 < sipa> sdaftuar: if we expect every such failure to be temporary, and start retrying automatically, i agree 11:23 < morcos> sdaftuar: maybe nothing, but what do users do with it? abandon? (what if they've waited 20 mins and 9290 rebroadcasted it) i don' tknow it just seems .. like a band-aid 11:23 < CodeShark> fwiw, in all my stuff I've separated the equivalent of "sendtoaddress" into at least two separate calls 11:23 < wumpus> it's not even merged to master yet, and we're not sure of the consequences 11:23 < wumpus> so yes it feels rushed 11:23 < sipa> CodeShark: yes, so do we in the raw tx api 11:23 < sdaftuar> morcos: right now though users are confused and think their money is gone -- at least this way they can see where it is 11:24 < morcos> sdaftuar: were you proposing that it looks different than if it did get accepted, or you can't tell from the rpc return value 11:24 < MarcoFalke_> gmaxwell: The rpc returns an error if it failed on the very first try, no? 11:24 < sipa> i did not know we did not report a txid if ATMP fails 11:24 < wumpus> simple fixes and things we're really sure about can be merged+backported last minute 11:24 < wumpus> but it doesn't look to be the case here, given this discussion already 11:24 < instagibbs> sipa, it's a very scary and useless message 11:24 < instagibbs> well, now it propagates more 11:24 < morcos> it seems to me you'd want to distinguish between it got ATMP and it didn't 11:24 < instagibbs> but still scary 11:24 < sipa> well i think we should either delete wallet txs that fail to ATMP at creation time, OR report the txid anyway 11:25 < sipa> now people think the tx failed, but they're still rebroadcasting it 11:25 < sdaftuar> sipa: i agree with that, though i'd be nervous about doing the first (delete wallet tx) in a backport 11:25 < wumpus> yes that makes no sense to the user 11:25 < sipa> sdaftuar: agree 11:25 < gmaxwell> sipa: not just that, but it is holding coins up in their wallet. 11:25 < wumpus> ideally the API should be atomic, either it succeeds or fails, not fails and still make a transaction 11:26 < sdaftuar> morcos: i agree it'd be better to indicate somehow that the new tx isn't in the mempool,but perhaps we can't change the API like that in a backport... reporting the txid still seems better than current behavior though 11:26 < sdaftuar> no different than if the tx was acepted and then evicted before relay 11:26 < gmaxwell> MarcoFalke_: you're right. 11:26 < wumpus> but it may be too much to fix in a backport in a release that we want out as soon as possible 11:26 < morcos> sdaftuar: but that doesn't work very well for a tx that'll never go anywhere ... 11:26 < sipa> can we do rebroadcast + report txid anyway in a backport? 11:26 < sdaftuar> current behavior is even worse though for a tx that won't go anywhere 11:27 < sdaftuar> you don't even know what tx to inspect/abandon! 11:27 < sipa> and for 0.14 consider long chain avoidance + deletion of failed creations? 11:27 < wumpus> although I'm not entirely sure when we want to do 0.13.2 11:27 < gmaxwell> wumpus: I want to do 0.13.2 11:27 < morcos> i mean if we do think this is such a large problem that it HAS to be addressed in a back port... then i'd argue we should include 9262, because at least if that works right, it means all the other functionality we'll backport will get used much less often 11:27 < wumpus> gmaxwell: I'm asking when, not whether 11:27 < gmaxwell> morcos: that was my thinking. 11:28 < sdaftuar> i lean towards backporting 9262, myself 11:28 < gmaxwell> wumpus: oops, I missed the word when. 11:28 < morcos> i'd rather have a lot less people asking about rpc calls that look like they work but theres no tx in mempool or random rebroadcasts a day later when parts of the chain confirm 11:28 < sipa> imho not reporting the txid of a tx that was added to your wallet is the worat bug here 11:28 < sipa> *worst 11:28 < sdaftuar> sipa: agree! 11:28 < jonasschnelli> Agree 11:28 < jonasschnelli> Reporting the txid seems worth a backport 11:29 < jonasschnelli> And the API change is accaptable 11:29 < wumpus> yes 11:29 < sipa> i don't have much opinion on 9262 11:29 < gmaxwell> morcos: I am unsure of how much reduction it will get. It will be a reduction, but at least 2 out of 3 people I've directly helped in this condition had no other coins in their wallet, as the wallet was created with a single large lump payment. 11:29 < CodeShark> then a separate call to check whether it failed to broadcast? 11:29 < MarcoFalke_> So reporting the txid would hide the fact that ATMP failed? 11:29 < gmaxwell> the third, however, was making large chains pointlessly and their problem would have been avoided by 9262. 11:30 < sipa> CodeShark: we can't make people change the way they use the api 11:30 < sipa> not in the short term 11:30 < jonasschnelli> 9262 is great. But whats the reason for a backport? Is a wallet function, users can and should upgrade to 0.14? 11:30 < CodeShark> imho, sendtoaddress should be deprecated in the long run 11:30 < morcos> realistically speaking what's the date when 13.2 would be out vs 14.0.. and would people be more likely to want 13.2 11:30 < wumpus> not in a backport at least 11:30 < CodeShark> but yeah, nearterm compatibility is important 11:30 < wumpus> CodeShark: we're talking about what to do in a backport 11:30 < sipa> CodeShark: maybe, but that's totally off topic in this discussion 11:30 < gmaxwell> My view on what we should eventually do: If a failure is perminante we should fail the send, and not save the txn. If the failure is temporary, we should return the txid and rebroadcast when we can. We should try to avoid creating temporary failures. 11:30 < wumpus> not what to do in the long run 11:30 < CodeShark> right 11:31 < gmaxwell> I was of the view that the case where we will ever create a non-temporary failure now is basically non-existant already. 11:31 < sipa> gmaxwell: it certainly seems infrequent 11:31 < gmaxwell> so I haven't given any thought to the 'not save the txn' branch above. 11:32 < gmaxwell> There may be fringe cases, so belt and suspenders would be good for robustness. 11:32 < jonasschnelli> hmm.. not saving the tx would mean, the wallet rpc functions depend fully on the mempool policy? 11:32 < sipa> so rebroadcast + avoid long chains + report txid anyway... all for 0.13.2? 11:32 < morcos> if its really rare, it might be we just track failures to reaccept and when they hit a cerain number, stop trying and have a way of reproting those txs for manual abandonment 11:32 < wumpus> when do we want to do 0.13.2? 11:33 < wumpus> is it some short term thing or januari? 11:33 < gmaxwell> As far as when 0.13.2 I've personally been spending almost all my recent attention on the remaining things I thought 0.13.2 needed. I had hoped in december. 11:33 < morcos> sipa: it seems thats what people are arguing for 11:33 < jonasschnelli> wumpus: +1 month after 0.14? 11:33 < wumpus> this sounds like it still needs a lot of work and testing and new things 11:33 < morcos> wumpus: reporting the txid anyway is probably super simple... just a question of thinking about the consequences 11:33 < sipa> jonasschnelli: a new 0.13 after 0.14 makes little sense 11:33 < wumpus> cfields also thought it was this week, he felt guilty he couldn't sign it this week :) 11:33 < gmaxwell> These things (and the open backport PR) are the only things I'm perosnally tracking for 0.13.2 (I made a call in #bitcoin this morning for bugreports against 0.13.1 with an eye towards getting 0.13.2 ready). 11:34 < morcos> so not unheard of that all these things could be merged into master by tomorrow 11:34 < wumpus> morcos: they're not even in master yet, I'm not sure of merging so much new stuff into a backport 11:35 < morcos> wumpus: well neither am i... i personally favor less emphasis on backports.. but i'm saying if we are going to do it, well lets get to it... 11:35 < wumpus> I really think we should make a choice here and solve the worst problems for 0.13.2 instead of trying to rush everything into it 11:35 < gmaxwell> I didn't even know about the rebroadcast behavior that 9290 fixed until discussion about this subject. :( 11:35 < wumpus> could always do a 0.13.3 later 11:36 < wumpus> jonasschnelli: I think the idea was to do it before 0.14. If after, none of these things are a problem 11:36 < gmaxwell> This discussion revealed that we also need the return txid anyways change, that is also a serious bug. 11:36 < morcos> i guess i believe that all or nothing makes sense, simply b/c anything less than the all sipa mentioned still leaves a big problem "rebroadcast + avoid long chains + report txid anyway." 11:36 < jonasschnelli> wumpus: Yes. Right. 11:37 < morcos> i would vote nothing, but i recognize i am outvoted 11:37 < sipa> morcos: i think the long chain avoidance is the least important in that set 11:37 < wumpus> but does the wallet get enough testing on 0.13.2 to warrant this? 11:37 < gmaxwell> I do believe we could leave the avoidance out and at least not be buggy in any risky way. Just potentially creating a needlessly bad performance. 11:37 < wumpus> I sometimes even doubt it gets enough testing on master 11:37 < MarcoFalke_> The rc1 for 0.13.2 should probably happen in Dec, otherwise it will "overlap" with 0.14 11:37 < gmaxwell> wumpus: I think wallet sometimes gets more testing on backport than on master. 11:38 < wumpus> MarcoFalke_: agreed, and people will probably be away lot later this month 11:38 < luke-jr> I think there'd be value in 0.13.x beyond 0.14, but realistically it won't get enough testing, so if we want a well-tested 0.13.x we should aim for before 0.14 11:38 < gmaxwell> wumpus: perhaps we should table this and (1) get the things we have open into master. (2) get a return txid fix. 11:38 < morcos> sipa: my reason for including the avoidance would be to limit the number of people affected by the other two changes.. but i guess i'm not sure how helpful it will be.. sure 11:39 < morcos> it always worries me when we change the behavior 11:40 < morcos> it seems people are always dependent on existing behvaior or using the bitcoind in a way we didn't anticipate 11:40 < CodeShark> why not preserve the current behavior for the existing API call and instead create a new API call that has the desired behavior? 11:40 < jonasschnelli> CodeShark: bugfix with a new feature? :) 11:40 < wumpus> gmaxwell: I suppose what is in 0.13.2 right now is already enough for a release? we could do the wallet stuff in a 0.13.3 11:40 < gmaxwell> Let my summarize the bug and why I think it's important to fix. Right now normal use of the wallet for some users can suffer inexplicible failures due to creating long transactions. These long transactions will look like the send failed, but it will still go into the wallet and _still_ be broadcast later potentially (After a restart). Users lose access to their funds and may falsely believe a 11:40 < morcos> the avoidance (if its not buggy) just works magic behind the scenes 11:40 < gmaxwell> wallet is empty. Users may double pay as a result. 11:40 < MarcoFalke_> CodeShark: We'd end with an new API every release. :) 11:41 < CodeShark> lol 11:41 < gmaxwell> These are all serious money losing bugs. And are the most reported issue I've dealt with users for existing software. 11:41 < wumpus> CodeShark: I think the point is fixing the current behavior 11:41 < CodeShark> the current behavior is it still stores the transaction in the wallet even if ATMP fails? 11:41 < sipa> CodeShark: this is all besides the issue. the current behaviour is clearly broken in numerous ways, and it should be fixed 11:42 < gmaxwell> if not for that, I wouldn't bother with wanting any of this backported. 11:42 < sipa> CodeShark: new APIs are possible that avoid some of the pitfalls we've learned about in earlier designs 11:42 < gmaxwell> (not for the fact that people are hitting it and can lose money as a result) 11:42 < Chris_Stewart_5> gmaxwell: 'long chains of txs' or just large txs for inexplicable failures? 11:43 < gmaxwell> Chris_Stewart_5: large transactions will not cause the behavior I described. 11:43 < sipa> CodeShark: yes 11:43 < MarcoFalke_> Chris_Stewart_5: mempool chains. 11:43 < jonasschnelli> Agree with gmaxwell: But I think we must at least offer a way how to detect this on the RPC consumer side and mention it in the release nots 11:43 < gmaxwell> The send mail fail but the failure is clean and won't freeze the users funds and/or send anyways. 11:43 < jonasschnelli> Reporting txid seems to be the sane way for a backport IMO 11:43 < gmaxwell> I think reporting the txid is correct too. I agree. 11:44 < gmaxwell> If its possible that the send will go through we must report the txid. Right now we don't. 11:44 < luke-jr> another potential way to address this particular case, would be to simply toggle the default of -spendzeroconfchange I think? 11:44 < wumpus> yes, if the transaction is added to the wallet it should be reported 11:44 < luke-jr> not the best way, but perhaps good enough to solve the critical part of the issue 11:45 < morcos> I'd rather spend less days arguing about it and more days testing the RC that fixes it... so can someone add the report txid anyway PR and lets merge that, #9262 and #9290 into master 11:45 < gribble> https://github.com/bitcoin/bitcoin/issues/9262 | Prefer coins that have fewer ancestors, sanity check txn before ATMP by instagibbs · Pull Request #9262 · bitcoin/bitcoin · GitHub 11:45 < gribble> https://github.com/bitcoin/bitcoin/issues/9290 | Make RelayWalletTransaction attempt to AcceptToMemoryPool. by gmaxwell · Pull Request #9290 · bitcoin/bitcoin · GitHub 11:45 < gmaxwell> None of the users reporting issues I worked with had been tripped up by the failure to return a txid (at least not that they noticed). 11:45 < wumpus> and that doesn't sound like a very risky or large change 11:45 < MarcoFalke_> #action create report txid patch 11:45 < sipa> MarcoFalke_: already on it 11:45 < jonasschnelli> sipa: nice! 11:45 < jonasschnelli> (just wanted to start) :) 11:45 < morcos> sipa: are you typing one-handed, its taking you a while 11:46 < sipa> morcos: i just switched to my laptop 11:46 < gmaxwell> luke-jr: I think szcc=0 is a huge disruptive and surprising change. :( 11:46 < wumpus> it's throwing out the baby with the bath water too 11:47 < luke-jr> gmaxwell: but it can't result in losing money (I agree a proper fix would be better though) 11:47 < gmaxwell> it's almost like "we could make sendtoaddress always fail." :) yes, that would fix the problem.. but.. 11:47 < wumpus> if it is really a critical problem we could consider that 11:47 < gmaxwell> but I suppose I would consider it if we really felt we couldn't do a better fix soon. 11:47 < wumpus> I remember we've done that before, in the time of the malleability problem 11:48 < wumpus> but preferably not, no 11:48 < gmaxwell> but I think we have a collection of better fixes which (with the txid return) will be more than sufficient. 11:48 < gmaxwell> so I'd rather not think about szcc=0. :) 11:48 < luke-jr> k 11:49 < morcos> actually i guess its not as simple as i thought 11:50 < gmaxwell> morcos: returning a txid? 11:50 < bitcoin-git> [bitcoin] sipa opened pull request #9302: Return txid even if ATMP fails for new transaction (master...failedtxid) https://github.com/bitcoin/bitcoin/pull/9302 11:50 < gmaxwell> I believe thats as simple as 11:50 < gmaxwell> ^ yep, thats the change I imagined. 11:50 < CodeShark> I never thought sendtoaddress was a reliable call as far as error handling so I sort of stopped thinking about how to do the error handling from the app side - not sure what issues people have had because of this behavior 11:51 < morcos> ha ha ha 11:51 < jonasschnelli> sipa: I think you should also change the logprint ("CommitTransaction(): Error: Transaction not valid, %s\n"), but meh, OT. 11:51 < sdaftuar> jonasschnelli: +1 :) 11:51 < sipa> jonasschnelli: we don't know if it's not valid 11:52 < sipa> jonasschnelli: wait, i don't see the change 11:52 < jonasschnelli> "ATMP failed" or something. 11:52 < gmaxwell> sipa: maybe that was the point of jonasschnelli's comment 11:52 < sipa> ah! 11:52 < sipa> i thought you said "change it TO ..." 11:52 < morcos> thanks sipa 11:53 < jonasschnelli> No. Just criticised the current one. 11:53 < jonasschnelli> Yes. Thanks sipa. 11:53 < jonasschnelli> Next time please faster 11:53 < gmaxwell> so: action proposed, 9302, 9290, 9262 and help get them into master. 11:53 < luke-jr> ._. 11:53 < sdaftuar> gmaxwell: concur 11:53 < luke-jr> gmaxwell: sgtm 11:54 < morcos> gmaxwell: i think thats the stable equilibrium... if 9262 seems dicey we can ditch, but i think its good 11:54 < morcos> can we briefly discuss tx expiry if no one else has another unrelated topic 11:54 < gmaxwell> yes, 9262 is the most optional, esp with the first two in. 11:54 < wumpus> at least 9290 and 9302 11:54 < gmaxwell> morcos: I would like to discuss expiry. 11:54 < wumpus> the latter should obv get into master but not sure about 0.13.2 11:54 < MarcoFalke_> #action 9302, 9290, 9262 for master (and backport), 9262 optional backport 11:55 < MarcoFalke_> ^fine this way? 11:55 < wumpus> #topic mempool expiry time increase 11:55 < instagibbs> I still think preferential coin choosing should go in, even if we drop the abort 11:55 < wumpus> 5 minutes to go ^^ 11:55 < instagibbs> sorry, continue 11:55 < morcos> i'd like to raise the time to at least 1 week... although we could use a few more heads thinking about whether there are any issues.. obv after 9290, it doesn't matter as much for gtting yhour own txs confirmed 11:55 < gmaxwell> instagibbs: I'd like to default the abort to off, with the rest it won't be needed. We can discuss later. 11:55 < morcos> but i think if we want to be able to fully utilize weekly cycles in the tx volume, then we need to have txs which sit around for a week or more to measure how long it takes them to get confirmed 11:56 < wumpus> morcos: would it make much of a difference in practice? wouldn't the transactions be evicted due to the mempool limit first? 11:56 < luke-jr> morcos: I can't think of any reason this wouldn't be okay. (but haven't given it thought before now) 11:56 < morcos> i'm not really sure that the problems that expiry were meant to protect against are actually any more prevent with 3 days vs say 14 11:56 < gmaxwell> morcos: I do believe I made the argument for a week way back when on this basis. OTOH, the mempool is simply not large enough to exploit the weekly cycle currently. 11:56 < wumpus> morcos: apart from that I don't see any problems with it 11:57 < morcos> wumpus: no.. any tx with fee rate > 1.5 sat / byte gets evicted b/c of 3 day limit and would otherwise get mined within a week (and usually does b/c of rebroadcast) 11:57 < instagibbs> does the wallet "abort" if it drops from mempool, or does it resubmit 11:57 < sipa> luke-jr: i think the expectation should be that everything in the mempool leaves it either due to accept/conflict or fee based eviction 11:57 < instagibbs> I assume resubmits 11:57 < gmaxwell> My view on the expiration is that it removes high fee cruft that got softforked out but is taking up your mempool. 11:57 < morcos> gmaxwell: its way more than big enough for a week cycle 11:57 < morcos> b/c remember it only has to hodl backlog 11:57 < sipa> luke-jr: expiration is for things that somehow linger much longer 11:57 < morcos> gmaxwell: yeah, but if thats actually happening 3 days is way too long, and is breaking yoru fee estimates already 11:58 < gmaxwell> morcos: okay point so long as it is at least as big as the daily cycle, txn can persist through the week. 11:58 < luke-jr> hmm 11:58 < wumpus> instagibbs: abort right now, the idea of #9290 is to change that and make it reaccept on rebroadcast 11:58 < gribble> https://github.com/bitcoin/bitcoin/issues/9290 | Make RelayWalletTransaction attempt to AcceptToMemoryPool. by gmaxwell · Pull Request #9290 · bitcoin/bitcoin · GitHub 11:58 < morcos> ok, i'd propose 14 days, so we don't have this problem again... and lets just think about whether anyone can think of any problems with it 11:58 < gmaxwell> morcos: in terms of fee estimates, we can address that by using a narrower filter... e.g. only consider transactions which are structurally similar to our own.. but a seperate topic. 11:59 < gmaxwell> also the expiration hardly works now in any case. 11:59 < sdaftuar> there's one other advantage of 3 days versusu a week, which is being able to double-spend a too-low-fee tx. after fee bumping, i think this reason largely goes away 11:59 < morcos> i don't think we can really take advantage of it until we change fee estimates... but i'd rather have more of the network behaving similarilyh 11:59 < morcos> and after 9290 11:59 < gmaxwell> if you are connectable there are 'helpful' parties that connect and spam you with a zillion old txn. 11:59 < instagibbs> morcos, that's too weeks of nodes not accepting fee bumps if you mess up and don't do bip125 (not sure how big an issue that is but still) 11:59 < morcos> you have a tiny windo 11:59 < sdaftuar> morcos: good point 11:59 < instagibbs> even with manual bumping* 12:00 < gmaxwell> instagibbs: I think it doesn't matter for replacement. 12:00 < morcos> instagibbs: but after 9290 your tx comes again anyway, you just lose the information that its old 12:00 < gmaxwell> Right now replacement of non-replacable transactions works even a day later fine, due to restarts and fullrbf miners. 12:00 < morcos> i want to retain that information 12:00 < luke-jr> instagibbs: if the fee is that excessively small though, it will get bumped out by non-conflicting transactions sooner probably 12:00 < gmaxwell> instagibbs: also what luke said. 12:00 < morcos> nothing with a fee rate > 1.5 sat / byte as ever been evicted due to low fee rate 12:00 < gmaxwell> morcos: does it need to be 14 days or is 7 sufficient to exploit the weekly cycle? 12:01 < morcos> i don't know... maybe 7.. but maybe you need more data points that are older than that to know things that don't get confirmed in 7 days 12:01 < morcos> which is kind of importnat 12:01 < gmaxwell> oh I see, for the estimator. 12:01 -!- JackH [~laptop@79-73-186-159.dynamic.dsl.as9105.com] has quit [Quit: Leaving] 12:02 < sipa> very short announcement: github now supports listing reviewers for your PR... always feel free to list me 12:02 < morcos> anyway, all i wanted to do is raise the topic, so other people cna think of potential problems 12:02 < gmaxwell> morcos: OKAY! 12:02 < gmaxwell> morcos: just open an PR and set sipa as the reviewer. Done. 12:02 < wumpus> #endmeeting 12:02 < lightningbot> Meeting ended Thu Dec 8 20:02:43 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 12:02 < lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-12-08-19.00.html 12:02 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-12-08-19.00.txt 12:02 < lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-12-08-19.00.log.html 12:04 < gmaxwell> instagibbs: I think of the 9262 "failure" case as a lot like spendzeroconfchange-- basically we replace a messy error with an even worse error but one which is cleaner to deal with. 12:04 < gmaxwell> (at least assuming the rebroadcast and txid return problems are solved) 12:04 < instagibbs> sure, I don't mind if there's something better in place removing it or turning it off by default 12:05 < Chris_Stewart_5> what does the acronym ATMP stand for? 12:05 < instagibbs> AcceptToMemoryPool 12:05 < gmaxwell> instagibbs: I think a proper mental model is that ignoring out of funds conditions-- which are likely "handled" by running getbalance before the send--, callers have no error handling on sendtoaddress. 12:05 < Chris_Stewart_5> ah, thanks instagibbs 12:06 < btcdrak> Can I scrounge some urgent review for https://github.com/bitcoin/libblkmaker/pull/6 please. It's required for some downstream miners for segwit. 12:06 < gmaxwell> or another way of thinking about it: Users will have no error handling for an error condition which isn't either Obvious (out of funds) or Very easily encountered in practice (also out of funds)... even fairly advanced users will not handle errors unless we either have an error simulator that returns them or very clear documentation which says "here are all the errors you will have to handle". 12:07 < gmaxwell> So given that I think we should assume the best handling users commonly have for sendtoaddress failure of "stop the world, something unexpected happened." 12:10 -!- marcoagner [~marcoagne@177.79.10.49] has joined #bitcoin-core-dev 12:12 -!- marcoagner [~marcoagne@177.79.10.49] has quit [Client Quit] 12:17 -!- CubicEarth [~cubiceart@2002:329f:7e15:0:9909:f524:6820:33da] has joined #bitcoin-core-dev 12:19 < btcdrak> morcos: ok I think I fixed that PR. Fingers crossed on Travis. 12:26 < morcos> btcdrak: i guess we won't be in favor of any soft forks that depend on tx version again 12:35 -!- bsm1175321 is now known as bsm117532 12:45 -!- jtimon [~quassel@77.224.94.35] has quit [Ping timeout: 248 seconds] 12:47 < btcdrak> morcos: I wouldnt say that necessarily, it's just we never did and were relying of default values. 12:49 < btcdrak> It reminds me that one shouldn't use API defaults for versioning. 13:00 -!- Sosumi [~Leon@bl10-113-190.dsl.telepac.pt] has quit [Quit: Bye] 13:01 -!- jtimon [~quassel@77.224.94.35] has joined #bitcoin-core-dev 13:28 -!- aalex__ [~aalex@64.187.177.58] has joined #bitcoin-core-dev 13:31 -!- aalex_ [~aalex@64.187.177.58] has quit [Ping timeout: 244 seconds] 13:51 -!- paracyst [paracyst@unaffiliated/paracyst] has joined #bitcoin-core-dev 14:52 -!- droark [~droark@c-24-22-123-27.hsd1.or.comcast.net] has quit [Ping timeout: 245 seconds] 14:53 -!- MarcoFalke_ [8af602fa@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.250] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] 14:57 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 246 seconds] 14:57 -!- MarcoFalke_ [8af602fa@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.250] has joined #bitcoin-core-dev 14:58 -!- TomMc [~tom@unaffiliated/tommc] has quit [Ping timeout: 246 seconds] 14:59 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 15:03 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 15:06 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 250 seconds] 15:07 -!- aalex_ [~aalex@64.187.177.58] has joined #bitcoin-core-dev 15:10 -!- TomMc [~tom@gateway/vpn/privateinternetaccess/tommc] has joined #bitcoin-core-dev 15:11 -!- aalex__ [~aalex@64.187.177.58] has quit [Ping timeout: 260 seconds] 15:12 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)] 15:49 -!- koha [~koha@dhcp-18-189-77-221.dyn.mit.edu] has joined #bitcoin-core-dev 15:57 -!- MarcoFalke [~marco@2001:4ca0:0:f226:a063:75b:7f88:d780] has joined #bitcoin-core-dev 15:59 -!- MarcoFalke_ [8af602fa@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.250] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] 16:00 -!- koha [~koha@dhcp-18-189-77-221.dyn.mit.edu] has quit [Ping timeout: 250 seconds] 16:07 < CubicEarth> I had a repeat of my node stalling when trying to sync a couple of days ago. Recent version of Ubuntu, 13.1, and basically nothing else on the machine. It was about 6 days behind, and promptly caught up to about 40 hours remaining. Then it just stopped. CPU was idle, only relaying traffic was seemingly being passed. After about 10 minutes I restarted the node, and syncing was completed within just a coup 16:07 < CubicEarth> le minutes of he restart. 16:09 < CubicEarth> I did try booting peers, but that didn't help anything. 16:09 < sipa> this is a known issue 16:09 < sipa> it is resolved automatically if you wait for the next block 16:09 < CubicEarth> I'm glad it's know :) 16:10 -!- MarcoFalke [~marco@2001:4ca0:0:f226:a063:75b:7f88:d780] has left #bitcoin-core-dev [] 16:11 -!- jtimon [~quassel@77.224.94.35] has quit [Ping timeout: 250 seconds] 16:54 -!- TomMc [~tom@gateway/vpn/privateinternetaccess/tommc] has quit [Ping timeout: 268 seconds] 17:09 -!- TomMc [~tom@unaffiliated/tommc] has joined #bitcoin-core-dev 17:10 < bitcoin-git> [bitcoin] sipa opened pull request #9303: Update comments in ctaes (master...ctaes) https://github.com/bitcoin/bitcoin/pull/9303 17:17 < gmaxwell> CubicEarth: it's due to nodes (usually spy nodes) that break the protocol and don't respond to headers requests interacting poorly with the sync logic. 17:25 < CubicEarth> I was wondering... Seems like my node ought to be a little bit more selfish, a little bit more aggressive, in requesting the data it needs. At least I wish it was. I'm guessing what you are describing is due to the fact Core codes nodes to be good network citizens, and non-standard nodes can disrupt that? 17:26 -!- alpalp [~allen@unaffiliated/alpalp] has joined #bitcoin-core-dev 17:29 < CubicEarth> Once payment channels and LN become a reality, I foresee the P2P layer integrating lots of micro-fees, charging for serving block data, for relaying TX, etc. 17:34 -!- alpalp [~allen@unaffiliated/alpalp] has quit [Read error: Connection reset by peer] 17:36 -!- alpalp [~allen@cpe-24-27-58-209.austin.res.rr.com] has joined #bitcoin-core-dev 17:36 -!- alpalp [~allen@cpe-24-27-58-209.austin.res.rr.com] has quit [Changing host] 17:36 -!- alpalp [~allen@unaffiliated/alpalp] has joined #bitcoin-core-dev 17:36 < gmaxwell> CubicEarth: no, it's not due to that, pretty much the opposite. 17:37 < gmaxwell> if it requests redundant data, then it might knock itself off the network if otherwise it only has enough bandwidth available to only fetch one copy. 17:39 < CubicEarth> So my node requests a piece of data, what happens? A peer says "yes, I have it, I'll give it to you" and then never does? And my node sites there, waiting, because if it asked another peer for data they could both end up providing it? 17:42 < gmaxwell> CubicEarth: right. It will eventually give up-- but for this particular request its triggered by a new block showing up on the network. 17:43 < gmaxwell> Smarter would be dynamic timeouts, -- the tricky thing is that care has to be taken to avoid unstable algorithins that can suffer congestion collapse. E.g. you have a limited bandwith network with 5 nodes on it... and then they fall behind and start agressively rerequesting and never recover. 17:43 < gmaxwell> It's not _that_ hard, but ... so many other things going on... 17:50 < CubicEarth> Other priorities for sure. It's nice that it respects bandwidth limits currently. It makes sense for it to be conservative by default, but perhaps there should / could be a setting where you tell how much bandwidth you would like it make use of, not just an "upper limit" for inbound connections, but "please use this much to make things happen faster" 17:51 < CubicEarth> Onto the back burner... 17:52 < gmaxwell> well it's not that it respects, it just has no idea what they are, so it assumes it's operating with very little, since thats consderative. 17:53 < gmaxwell> RE manual setting, I think very few users will use that correctly-- we should have settings, but they're way less important than better default behavior. 17:57 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 18:00 < CubicEarth> The funny thing is the software is already 'aware' in the sense that it can generate a graph of network activity, but I get that it's probably not 'hardened code'. 18:01 < gmaxwell> Past performance doesn't indicate future results. Assuming that it does is how you get schemes that suffer congestion collapse. :P 18:03 < CubicEarth> gmaxwell: so a node dosent DDoS itself? 18:07 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-piyzaagohwcdgtxn] has quit [Quit: Connection closed for inactivity] 18:08 < gmaxwell> CubicEarth: e.g. you have 5 nodes on a 1 mbit connection. They each observe 1mbit available.. but then they all try to use it at once and there will be far less than 1mbit available. 18:09 < CubicEarth> got it 18:22 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has joined #bitcoin-core-dev 19:14 -!- fengling [~fengling@223.223.187.142] has quit [Ping timeout: 268 seconds] 19:19 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Ping timeout: 250 seconds] 19:19 -!- afk11 [~afk11@176.61.67.182] has joined #bitcoin-core-dev 19:19 -!- afk11 [~afk11@176.61.67.182] has quit [Changing host] 19:19 -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-core-dev 19:22 -!- fengling [~fengling@223.223.187.142] has joined #bitcoin-core-dev 19:25 -!- murch [~murch@p4FE38618.dip0.t-ipconnect.de] has joined #bitcoin-core-dev 19:26 -!- murch_ [~murch@p4FDB642C.dip0.t-ipconnect.de] has quit [Ping timeout: 265 seconds] 19:28 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Ping timeout: 245 seconds] 19:31 -!- abpa [~abpa@107-131-125-191.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev 19:33 -!- afk11 [~afk11@176.61.67.182] has joined #bitcoin-core-dev 19:33 -!- afk11 [~afk11@176.61.67.182] has quit [Changing host] 19:33 -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-core-dev 19:35 -!- fengling [~fengling@223.223.187.142] has quit [Ping timeout: 268 seconds] 19:39 < bitcoin-git> [bitcoin] droark opened pull request #9304: Allow linearization scripts to support little endian hashes (master...master) https://github.com/bitcoin/bitcoin/pull/9304 19:47 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has quit [Quit: Leaving.] 20:05 -!- fengling [~fengling@223.223.187.142] has joined #bitcoin-core-dev 20:22 < bitcoin-git> [bitcoin] kallewoof opened pull request #9305: Refactor: Removed begin/end_ptr functions. (master...remove-begin-end_ptr-usage) https://github.com/bitcoin/bitcoin/pull/9305 20:22 -!- alpalp [~allen@unaffiliated/alpalp] has quit [Ping timeout: 258 seconds] 20:24 -!- alpalp [~allen@unaffiliated/alpalp] has joined #bitcoin-core-dev 20:25 -!- fengling [~fengling@223.223.187.142] has quit [Ping timeout: 268 seconds] 20:32 -!- abpa [~abpa@107-131-125-191.lightspeed.sntcca.sbcglobal.net] has quit [Quit: Textual IRC Client: www.textualapp.com] 20:34 -!- alpalp [~allen@unaffiliated/alpalp] has quit [Ping timeout: 256 seconds] 20:37 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Ping timeout: 268 seconds] 20:43 -!- afk11 [~afk11@176.61.67.182] has joined #bitcoin-core-dev 20:43 -!- afk11 [~afk11@176.61.67.182] has quit [Changing host] 20:43 -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-core-dev 20:53 -!- TomMc [~tom@unaffiliated/tommc] has quit [Ping timeout: 246 seconds] 21:06 -!- Squidicuz [~squid@pool-173-48-116-49.bstnma.fios.verizon.net] has quit [Quit: Oh no, not again] 21:08 -!- Squidicuz [~squid@pool-173-48-116-49.bstnma.fios.verizon.net] has joined #bitcoin-core-dev 21:10 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Ping timeout: 268 seconds] 21:14 -!- afk11 [~afk11@176.61.67.182] has joined #bitcoin-core-dev 21:14 -!- afk11 [~afk11@176.61.67.182] has quit [Changing host] 21:14 -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-core-dev 21:28 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 21:29 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 23:00 -!- dermoth [~thomas@dsl-66-36-158-238.mtl.aei.ca] has quit [Read error: Connection reset by peer] 23:00 -!- dermoth [~thomas@dsl-66-36-158-238.mtl.aei.ca] has joined #bitcoin-core-dev 23:09 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 23:10 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 23:13 -!- SKESAFIROS_ZEF2P [~2efPer_1a@221.163.38.118] has joined #bitcoin-core-dev 23:21 -!- Murh [~2efPer_1a@221.163.38.118] has joined #bitcoin-core-dev 23:22 -!- Murh [~2efPer_1a@221.163.38.118] has left #bitcoin-core-dev [] 23:23 -!- SKESAFIROS_ZEF2P [~2efPer_1a@221.163.38.118] has quit [Quit: 暂离] 23:24 -!- MurhS0xFF [~2efPer_1a@221.163.38.118] has joined #bitcoin-core-dev 23:24 -!- MurhS2x1 [~2efPer_1a@221.163.38.118] has joined #bitcoin-core-dev 23:25 -!- MurhS0xFF [~2efPer_1a@221.163.38.118] has quit [Client Quit] 23:25 -!- MurhS2x1 [~2efPer_1a@221.163.38.118] has quit [Client Quit] 23:31 -!- fengling [~fengling@223.223.187.142] has joined #bitcoin-core-dev 23:59 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]