--- Day changed Wed Apr 20 2016
00:04 -!- pedrobranco [~pedrobran@167.225.61.94.rev.vodafone.pt] has joined #bitcoin-core-dev
00:06 -!- pedrobranco [~pedrobran@167.225.61.94.rev.vodafone.pt] has quit [Remote host closed the connection]
00:17 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
00:24 -!- Lightsword [~Lightswor@2604:a880:1:20::1d3:9001] has quit [Ping timeout: 264 seconds]
00:24 -!- TD-Linux [~Thomas@about/essy/indecisive/TD-Linux] has quit [Ping timeout: 250 seconds]
00:25 -!- Lightsword [~Lightswor@107.170.253.193] has joined #bitcoin-core-dev
00:26 -!- TD-Linux [~Thomas@about/essy/indecisive/TD-Linux] has joined #bitcoin-core-dev
00:31 -!- aquentson1 [~aquentson@unaffiliated/aquentson] has quit [Ping timeout: 246 seconds]
00:39 -!- sanada [sanada@36-2-119-80.chiba.ap.gmo-isp.jp] has joined #bitcoin-core-dev
01:12 < sipa> NicolasDorier: chainActive is the best known fully validated chain
01:14 < NicolasDorier> thanks
01:15 < sipa> phantomcircuit: they are
01:27 -!- cryptocoder [~cryptocod@cpe-76-90-140-31.socal.res.rr.com] has quit [Quit: cryptocoder]
01:28 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev
01:35 -!- nhancm__ [~nhancm@14.161.4.70] has joined #bitcoin-core-dev
01:38 -!- nhancm_ [~nhancm@14.161.4.70] has quit [Ping timeout: 250 seconds]
01:54 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev
01:56 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Remote host closed the connection]
01:56 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev
01:57 -!- murch [~murch@p4FE39359.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
01:58 < sipa> phantomcircuit: they're in #7749
02:01 < murch> btcdrak: I saw that you last updated the SegWit adoption overview: https://bitcoincore.org/en/segwit_adoption/ A lot of discussion had been linking to that table, is there a way that one could get a status update by the other projects, so that the table is up-to-date as SegWit discussion recommences right now?
02:02 < btcdrak> murch: they can submit a pull request https://github.com/bitcoin-core/bitcoincore.org/blob/gh-pages/_includes/pages/segwit_support.md
02:02 < btcdrak> as well as https://github.com/bitcoin-core/bitcoincore.org/blob/gh-pages/_posts/en/pages/2016-01-13-segwit-support.md
02:03 < sipa> hi murch!
02:03 < murch> Hi sipa :)
02:04 < murch> btcdrak: What I meant, is there some sort of communication channel that could be useful to get companies to check if they should be updating their status on the table? I think it would help show that secondary work on SegWit is progressing.
02:05 < btcdrak> murch not sure I follow you.
02:07 < murch> btcdrak: E.g. adam3us has referred to the table 16 days ago (https://www.reddit.com/r/Bitcoin/comments/4d3pdg/clearing_the_fud_around_segwit/d1nxxq6) as showing that secondary projects are working on SegWit. I've called him out on that, because the table doesn't actually show that. (I'm Xekyo on reddit). I would like to propose that development teams listed on that table get nudged to update their status, because it is my understanding
02:08 < murch> The table is still the same as 16 days ago. :)
02:11 < murch> My intent is to point out an easy improvement that could be made in the communication with the broader Bitcoin community. Unless I'm mistaken and the table is up-to-date. Then I'll rest my case of course. ;)
02:11 < gmaxwell> You shouldn't expect it to change much until it's out there in the network. For anything not a full node there is no use in having it ready ahead of the network; so so I would expect most things to be in a working on it state for a bit yet.
02:11 -!- PaulCape_ [~PaulCapes@204.28.124.82] has joined #bitcoin-core-dev
02:14 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Ping timeout: 260 seconds]
02:17 < murch> Okay, I guess I'm mistaken then.
02:17 < sipa> i think it's good in general to ask teams to keep updating their status
02:17 < sipa> "in progress" can mean a lot of things
02:18 < sipa> and there could be a "Ready to rollout whenever the network is ready"
02:18 < gmaxwell> Indeed, but probably in the form of getting something more granular than in progress.
02:18 < gmaxwell> like ... "in tested on segnet/testnet"
02:21 < murch> Completely different topic: I'm going to have a meeting later today about a potential master thesis in the area of Bitcoin. I've proposed to do my master thesis on Coin Selection (which I've did some simulation work before, e.g. gmaxwell had commented then). I've seen that CoinSelection is scheduled to be "looked at" for 0.13. Do you think it would make sense to have a more systematic analysis of CoinSelection even though that's schedu
02:22 < sipa> I don't think you should see that "looked at" as anything more than that, and certainly not a promise that it will be investigated thoroughly or overhauled :)
02:22 < sipa> And further analysis would be very useful.
02:22 < sipa> For example, 
02:23 < murch> Cool, because I'd like to work on something useful for my thesis. :)
02:23 < gmaxwell> it's tagged as to be looked at because were in need of some stopgap because the behehavior now is not great. But I don't think we're planning on doing much more than a bandaid.
02:23 < sipa> creating multiple change outputs is an open question (when to do it, how to do it, what effects it has on the UTXO set in your wallet, and potentially indirectly the size of created transactions)
02:24 < murch> sipa: Oh, interesting. I hadn't thought of that. But, shouldn't transactions aim to create the least necessary new UTXO?
02:25 < sipa> murch: there are 2 reasons i know of to create multiple outputs: 1) privacy (if one of the change outputs looks identical to at least one of the payments, you can't tell anymore which of the outputs is the real change)
02:26 < sipa> murch: another is that it may result in a more balanced set of wallet UTXOs to pick from, and that that may result in better coin selection for future transactions
02:27 < murch> sipa: Yeah, one of my proposed algorithms then tried to create change of similar size to the target instead of "smallest possible". That's definitely an avenue I'd like to further investigate.
02:27 < sipa> another question: does preferably picking outputs sent to the same address whenever one such output is already used (because you've payed the privacy tax already) help?
02:28 < sipa> it's a complicated problem, because its priorities are unclear: privacy of address linkage, current transaction size, and future transaction sizes
02:30 < murch> Yeah, that's why I think it's a good topic for a thesis. You can try a lot of different things, you can simulate and model it well, and finding a better solution might benefit the project. :) Anyway, I'm glad I asked, because I felt that the topic might become obsolete with the SegWit discount and the scheduled review.
02:31 < gmaxwell> no, not at all.
02:31 < sipa> segwit should be orthogonal
02:31 < sipa> all it does is change the cost metric for computing fees
02:31 < murch> sipa: I'll have to see if I can find more information on the occurrence of address reuse.
02:32 < murch> sipa: Yeah, but I was afraid that the small changeset that was finally adopted from my last CoinSelection push has even made UTXO growth worse
02:32 < murch> gmaxwell: Great! :)
02:33 < sipa> from an email i have from satoshi over 5 years ago:
02:33 < sipa> Another case is breaking large change outputs into two random sizes to increase backup safety so you're not rewriting your entire savings in every transaction.  It would create more varied sizes for SelectCoins to choose from in the future.  Some may also want to do it to smooth out priority use or increase privacy wrt the amounts.
02:33 < gmaxwell> murch: yes, I believe it has; but thats not your fault. We discussed it then.
02:33 < murch> the pruning of inputs was added then, although my simulation hadn't conclusively shown that it would be an improvement, and I'm afraid that it contributes by keeping small UTXO from being consolidated now
02:33 -!- grimescapes [~user@46.166.188.223] has quit [Ping timeout: 276 seconds]
02:34 < gmaxwell> sipa: I think we should always split by default at some threshold.. it's silly to make outputs which are hundreds of btc or more.
02:35 < sipa> but for example: what if you have the choice between making an tiny change output (close to dust, unlikely to be used ever) and adding an extra input and creating two outputs (one of which is similar to the payment)
02:35 < sipa> should you do that or not
02:35 < sipa> eh, creating two change outputs
02:35 < murch> also an interesting thought. I had been considering an approach of #inputs should be greater than #outputs, but you really don't want to tell the recipient your whole balance every time. Anyway, I'm assuming that I'll be investing considerable effort to create a fitness function for evaluation
02:36 < sipa> oh, there is a way in which segwit may be relevant: adding an extra input will be cheaper than adding an extra output
02:36 < gmaxwell> well there will also be the added complication from aggregation in the not that distant future.
02:36 < murch> sipa: I thought it would make the two about equally expensive?
02:37 < gmaxwell> Where its much cheaper to spend more inputs at once.
02:37 < gmaxwell> sipa: it's about equal because of the witness costs of the additional input (id selection)
02:38  * sipa opens spreadsheet
02:38 < murch> another question: Will Schnorr signatures not make inputs vastly cheaper, as the signatures can be combined? Wouldn't that also help consolidate the UTXO set? When would we be expecting a switch to Schnorr?
02:38 < sipa> murch: the effect of Schnorr isn't that large anymore after segwit
02:38 < murch> I see, thanks.
02:38 < sipa> (if you're talking about transaction-wide aggregation)
02:39 < murch> I believe I was. :)
02:39 < gmaxwell> sipa: thats now getting called schnorr signatures due to that article. :(
02:39 < sipa> https://docs.google.com/spreadsheets/d/1TvWBvjAAiVOBUgbYuuQ4rWnMQLXxI3qlMXVWhCdAtSw
02:40 < murch> Thank you so much for the input, that'll help me later in my meeting with my (hopefully) future advisor convince him that it's a relevant topic. :D
02:41 < sipa> murch: where are you studying?
02:41 < murch> sipa: Karlsruhe Institute of Technology
02:41 < sipa> ha, nice; i'm in stuttgart currently
02:41 < sipa> that's pretty close i think
02:41 < murch> Yeah, it is. I thought you were in Switzerland?
02:41 < sipa> it's complicated :)
02:42 < sipa> but i'll be here a lot the next month/months
02:46 -!- MarcoFalke [8af6020a@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.10] has joined #bitcoin-core-dev
02:47 < murch> I'd love to grab a beer with you sometime. Perhaps throw around a few more ideas about my thesis once I'm further along. :)
02:47 < sipa> sure!
02:48 < murch> Do I remember correctly that I've read somewhere that you enjoy rock climbing? ^^
02:48 < sipa> i believe that's petertodd
02:48 < gmaxwell> actually petertodd does caves. rock climbing is too safe.
02:48 < murch> ah, nevermind then. :D
02:49 < gmaxwell> (maybe he also does rockclimbing, but certantly more caves)
02:49 < sipa> he's a miner, after all
02:49 < kinlo> :p
02:50 < gmaxwell> ::groan::
02:50 < gmaxwell> I think not anymore.
02:50 < murch> sipa: We've actually met once (very briefly) at Bitcoin 2014. :) I said hi, and told you that I'm a moderator on Bitcoin.SE. and you said, you love our work. Heh.
02:50 < murch> Thanks guys, you just made my day.
02:54 -!- Thireus1 [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Quit: Leaving.]
02:56 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
03:00 -!- aquentson [~aquentson@unaffiliated/aquentson] has joined #bitcoin-core-dev
03:13 -!- jannes [~jannes@178.132.211.90] has joined #bitcoin-core-dev
03:19 -!- murch [~murch@p4FE39359.dip0.t-ipconnect.de] has quit [Quit: Leaving.]
03:20 -!- nhancm__ [~nhancm@14.161.4.70] has quit [Ping timeout: 260 seconds]
03:39 < GitHub185> [bitcoin] venatici opened pull request #7914: [qa] Add optional unique coinbase generation (master...coinbase) https://github.com/bitcoin/bitcoin/pull/7914
03:40 -!- sanada [sanada@36-2-119-80.chiba.ap.gmo-isp.jp] has left #bitcoin-core-dev []
03:41 -!- sanada [sanada@36-2-119-80.chiba.ap.gmo-isp.jp] has joined #bitcoin-core-dev
03:53 -!- achow101 [~achow101@pool-96-227-114-115.phlapa.fios.verizon.net] has joined #bitcoin-core-dev
04:02 -!- zlover [uid34185@gateway/web/irccloud.com/x-dpnuvhvmdvexltnx] has joined #bitcoin-core-dev
04:36 < zlover> Hi
04:47 -!- jtimon [~quassel@18.29.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
04:54 -!- cryptapus [~cyptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
05:36 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Quit: Leaving.]
05:54 -!- cryptapus__ [~cyptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
05:58 -!- cryptapus [~cyptapus@unaffiliated/cryptapus] has quit [Ping timeout: 276 seconds]
06:03 -!- zooko [~user@2601:281:8000:8387:8800:5967:f290:947e] has quit [Ping timeout: 268 seconds]
06:18 -!- mr_burdell [~mr_burdel@unaffiliated/mr-burdell/x-7609603] has joined #bitcoin-core-dev
06:18 -!- Guest25495 [~mr_burdel@192.81.215.202] has quit [Read error: Connection reset by peer]
06:18 -!- Lightsword [~Lightswor@107.170.253.193] has quit [Ping timeout: 250 seconds]
06:19 -!- windsok [~windsok@45.63.59.8] has quit [Read error: Connection reset by peer]
06:19 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 268 seconds]
06:19 -!- windsok [~windsok@45.63.59.8] has joined #bitcoin-core-dev
06:20 -!- Lightsword [~Lightswor@2604:a880:1:20::1d3:9001] has joined #bitcoin-core-dev
06:21 -!- zooko [~user@c-73-217-16-2.hsd1.co.comcast.net] has joined #bitcoin-core-dev
06:22 < GitHub149> [bitcoin] hmel opened pull request #7916: Explicitly pass CChainParams& to DisconnectTip() (master...global-params-cleanup) https://github.com/bitcoin/bitcoin/pull/7916
06:27 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
06:31 < GitHub41> [bitcoin] jtimon closed pull request #7876: Globals: Explicitly pass const CChainParams& to UpdateTip() (master...0.12.99-globals-chainparams-updatetip) https://github.com/bitcoin/bitcoin/pull/7876
06:42 -!- face [~face@mail.hmel.org] has joined #bitcoin-core-dev
06:43 -!- TomMc [~tom@unaffiliated/tommc] has joined #bitcoin-core-dev
06:44 < jtimon> thank you face for participating in my little experiment in #7829 with your PR #7916 which I'm very happy with!
06:48 -!- zlover [uid34185@gateway/web/irccloud.com/x-dpnuvhvmdvexltnx] has quit [Quit: Connection closed for inactivity]
06:49 -!- cryptapus__ is now known as cryptapus
06:56 < face> jtimon, thank you for doing this. It's a great way to get potential devs to experience for real the dev workflow!
07:13 < jtimon> face you are welcomed, that is entirely the point (that, and getting people to do want I want to get done Ha ha ha</evil_laughter>)
07:13 < GitHub13> [bitcoin] sipa opened pull request #7917: Optimize reindex (master...betterreindex) https://github.com/bitcoin/bitcoin/pull/7917
07:19 < jtimon> I'm sure I have done that stuff several times already myself, so I thought it would be more productive tol help potential new devs do it whenever they want rather than me rebasing all the time a branch that it's just too disruptive to be merged at once, while PRing many little commits separately is a good way for me to run out of rebase patience  (while making more noise with more PRs open)
07:19 -!- d_t [~textual@195.52.242.214] has joined #bitcoin-core-dev
07:30 -!- zooko [~user@c-73-217-16-2.hsd1.co.comcast.net] has quit [Ping timeout: 250 seconds]
07:34 < helo> +1 wonderful
07:34 -!- cryptapus [~cyptapus@unaffiliated/cryptapus] has quit [Quit: Conversation terminated!]
07:35 -!- cryptapus [~cyptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
07:42 -!- zooko [~user@50.141.118.180] has joined #bitcoin-core-dev
07:44 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]
07:47 -!- galileopy [~galileopy@181.121.64.244] has quit [Ping timeout: 268 seconds]
07:48 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]
08:00 -!- galileopy [~galileopy@181.121.64.244] has joined #bitcoin-core-dev
08:06 -!- cryptapus is now known as cryptapus_
08:07 -!- JackH [~Jack@79-73-185-113.dynamic.dsl.as9105.com] has joined #bitcoin-core-dev
08:07 -!- cryptapus_ is now known as cryptapus__
08:07 -!- cryptapus__ is now known as cryptapus
08:08 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
08:09 -!- baldur [~baldur@pool-108-29-176-11.nycmny.fios.verizon.net] has quit [Ping timeout: 250 seconds]
08:13 -!- murch [~murch@p4FE39359.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
08:22 < paveljanik> MarcoFalke, do you have an issue for the wallet.py test?
08:22 < sipa> cfields has been looking into it as well
08:22 < paveljanik> I did a quick test yesterday and end up with db-> rename returning 2...
08:23 < paveljanik> and I'm not able to reproduce the problem today 8)
08:23 < MarcoFalke> Should be one of those tagged with "wallet": https://github.com/bitcoin/bitcoin/issues/created_by/MarcoFalke
08:23 < murch> sipa: My master thesis' working title is "Evaluation of Coin Selection Strategies" ;)
08:23 < MarcoFalke> nice
08:23 < sipa> murch: nice
08:23 < MarcoFalke> which field are you doing your masters in?
08:23 < MarcoFalke> ec or cs?
08:23 < murch> Computer Science
08:24 < paveljanik> MarcoFalke, this particular issue seems to be different...
08:25 < MarcoFalke> Did you save the log?
08:26 < paveljanik> Once I started to run ./wallet.py --tracerpc --nocleanup in endless cycle, no error 8)
08:26 < paveljanik> Probably only in the terminal scrollback buffer
08:26 < paveljanik> 8(
08:26 < paveljanik> I'm on it.
08:27 < paveljanik> it would be nice to have --nocleanuponfail ;-)
08:28 < sipa> --nocleanup exists
08:29 < sipa> as well as --noshutdown
08:38 < sipa> morcos: what do you think about https://github.com/sipa/bitcoin/pull/77/commits/9debcaf442f6705c3b08c9fffd5da2ff2116ba53?w=1 ?
08:39 < sipa> morcos: if you negotiated in the version message to not send transactions, and then send a feefilter, it will start relaying txn
08:59 < morcos> sipa: so this is just a way to have more flexibility, to allow turning sending of txs back on?
09:00 < morcos> i don't think i have any issue with that concept, but i'm a bit hesitant on whether its worth the complication
09:01 < morcos> for instance isn't there code to disconnect/ban peers that send you txs when you didnt' ask for them
09:01 < morcos> is that corrected to account for this (haven't reviewed the whole pull)
09:01 < sipa> well this is about sending invs, not getdata or tx
09:02 < sipa> and it does make sense that if you want to use feefilter, you want to make sure that you first get to tell the peer what feefilter you want before he starts sending transactions
09:02 < sipa> (same as with bip37 filters)
09:03 < morcos> i'm confused, are you talking about for other implementations sending this (such as lite clients)?
09:03 < sipa> yes
09:04 < sipa> not that any of them do send feefilter right now
09:04 < sipa> i'm just trying to guess why greg's adding a seemingly unrelated change here
09:04 < morcos> i guess i never thought of feefilter as a strict requirement.  you aren't required to obey it, its only an approximation of where you actually want the cutoff to be, and there are unknown delays in sending it
09:05 < morcos> ha ha, thats what i'm trying to guess
09:06 < morcos> anyway, i don't see a problem with it, but i don't see a specific advantage either, and it seems to me that if we don't know of a use case where you want to start with no txs and then turn them back on later, that there is no reason to add this.
09:07 < sipa> it's not that you'd want to start with no txs
09:07 < sipa> it's that you don't want to be bombed with a torrent of txs before you've had a chance to tell your peer what fee filter you want
09:07 < morcos> but you never get a torrent of invs
09:08 < sipa> but there are arguments against it: 1) what if you want both a bip37 filter and a feefilter? sending either will turn on invs before sending the second
09:08 < sipa> i know :)
09:08 < morcos> and if you are doing something like a filtered block or mempool command then you have the choice to send the feefilter message before you ask for those
09:09 < morcos> to be clear, i like the idea of moving the filtering to the end piece. it'll result in many more mempool lookups (once per inv), but i think thats ok 
09:10 < morcos> its  just tying it into the fRelayTxes variable that i don't see the point of.
09:10 < sipa> ok
09:15 < morcos> yeah in talking to sdaftuar, i don't really see the feefilter as analogous to the bip37filter.   feefilter seems almost unlikely to be used by lite clients, why would you not want to know about all relevant txs to you anyway, you can do your own logic if you dont' think the fees are high enough.  i see feefilter as a tool for full nodes to eliminate traffic that would be dropped at mempool acceptance anyway
09:21 -!- cryptocoder [~cryptocod@cpe-76-90-140-31.socal.res.rr.com] has joined #bitcoin-core-dev
09:22 < jtimon> ping #7728, all nits resolved, I think
09:25 < morcos> we don't guard the printing of IP address for incoming connections with fLogIPs.  is that intentional?
09:31 -!- cryptocoder_ [~cryptocod@cpe-76-90-140-31.socal.res.rr.com] has joined #bitcoin-core-dev
09:33 -!- cryptocoder [~cryptocod@cpe-76-90-140-31.socal.res.rr.com] has quit [Ping timeout: 260 seconds]
09:33 -!- cryptocoder_ is now known as cryptocoder
09:35 < kanzure> i have completed my read-through of the segwit pull request, now on to organizing thoughts/notes/bugs...
09:47 < GitHub21> [bitcoin] MarcoFalke opened pull request #7918: [qa] mininode: Use hexlify wrapper from util (master...Mf1604-qaMininodeHexlify) https://github.com/bitcoin/bitcoin/pull/7918
10:07 -!- arowser [~quassel@106.120.101.38] has quit [Quit: No Ping reply in 180 seconds.]
10:07 -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-core-dev
10:20 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 268 seconds]
10:27 -!- zooko [~user@50.141.118.180] has quit [Ping timeout: 260 seconds]
10:49 -!- zooko [~user@c-73-217-96-13.hsd1.co.comcast.net] has joined #bitcoin-core-dev
10:50 -!- LeMiner2 [LeMiner@5ED1AFBF.cm-7-2c.dynamic.ziggo.nl] has joined #bitcoin-core-dev
10:52 -!- LeMiner [LeMiner@unaffiliated/leminer] has quit [Ping timeout: 252 seconds]
11:01 -!- murch [~murch@p4FE39359.dip0.t-ipconnect.de] has quit [Quit: Leaving.]
11:14 -!- d_t [~textual@195.52.242.214] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
11:23 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
11:26 < GitHub54> [bitcoin] sdaftuar opened pull request #7919: Fix headers announcements edge case (master...fix-sendheaders-edge-case) https://github.com/bitcoin/bitcoin/pull/7919
11:29 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Remote host closed the connection]
11:31 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev
11:35 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Ping timeout: 252 seconds]
11:37 < gmaxwell> sipa: why I was making it there was because I went to go fix the lack of locking on fRelayTX and then realized feefilter didn't trigger it, which surprised me.
11:37 < gmaxwell> I've yanked out those changes.
11:40 < sipa> thanks
11:46 -!- jannes [~jannes@178.132.211.90] has quit [Quit: Leaving]
11:47 < sipa> sdaftuar, morcos: did you see BlueMatt's proposal to treat non-connecting headers as invs, and go fetch it?
11:48 -!- pedrobranco [~pedrobran@167.225.61.94.rev.vodafone.pt] has joined #bitcoin-core-dev
11:48 < sdaftuar> sipa: i did.  i think that's a fine change to make, though i'd be wary of doing it too much, as part of the point of headers relay is to avoid the extra round trip to propagate a reorg
11:49 < BlueMatt> sdaftuar: we can still be smart about what we send, but if another client doesnt want to implement that much and just wants to have a lazy protocol to announce we should be willing to recv smarter
11:49 < sdaftuar> right, i agree with that
11:49 < sipa> right, though i vaguely remember that there can be edge cases in which we can't orevent non-connecting headers
11:50 < sdaftuar> oh, and you're suggesting that we just send the header anyway, rather then revert to inv?
11:50 < sdaftuar> we could do that too
11:51 < sdaftuar> there's not much benefit though i think?
11:53 -!- pedrobranco [~pedrobran@167.225.61.94.rev.vodafone.pt] has quit [Ping timeout: 276 seconds]
11:54 < sipa> i forget the whole discussion; i think it's more about us dealing well with others sending unconnecting headers
11:57 < sdaftuar> AcceptBlockHeader will give a DoS (10) to a peer for sending a header with an unknown prev block
11:59 < gmaxwell> My understanding of Matt's complaint is that this then forces you to do the rather complex tracking.
12:00 < BlueMatt> it introduces a lot of required state in order to do sendheaders
12:00 < BlueMatt> which seems kinda crazy to me since sendheaders is so conceptually simple
12:04 -!- d_t [~textual@195.52.242.214] has joined #bitcoin-core-dev
12:04 < sdaftuar> i don't really follow why a peer would choose to implement sendheaders if they weren't going to do the tracking.  how is it better than sending inv's, which are smaller?
12:04 < sdaftuar> i do agree that we could handle unconnecting headers more gracefully though
12:06 < BlueMatt> sdaftuar: i mean you know that sending headers to your peer is gonna make their download more effecient, so you'd prefer to, why not?
12:06 < BlueMatt> having to track the current state of your peer's chain is so gross
12:06 -!- zooko [~user@c-73-217-96-13.hsd1.co.comcast.net] has quit [Ping timeout: 276 seconds]
12:06 < sdaftuar> we already mostly have to track the state of their chain, to avoid re-announcing blocks to them that they know about
12:07 -!- molz is now known as moli
12:07 < sdaftuar> and to know which blocks we can download from them
12:07 < BlueMatt> no we dont
12:07 < BlueMatt> you can announce any shit you want and your peer will figure out if they want to request it or not
12:08 < BlueMatt> it says nowhere in the protocol that you have to be reasonable about what you announce
12:09 < BlueMatt> it also says nowhere that you have to download from all your peers or be a downloading peer in order to sendheaders
12:09 < BlueMatt> or, at least, you shouldnt be
12:09 < BlueMatt> not to mention its always been a general goal for the protocol to be as stateless as possible :/
12:12 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-core-dev
12:17 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
12:18 < sipa> BlueMatt: calm down
12:19 < sipa> BlueMatt: sdaftuar was just saying that we are already tracking that anyway
12:19 < BlueMatt> hmm? I'm not upset? anyway, point was that we're requiring other protocol implementors to track it...we arent the only ones who have to implement this protocol
12:20 < sipa> yes, i'm aware of that
12:20 < sipa> i don't think anyone is disagreeing with anyone else
12:21 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Remote host closed the connection]
12:22 < sipa> so the changes required would be 1) not DoS when unconnecting headers are received 2) trigger a getheaders in that case?
12:23 < BlueMatt> I thought that was sufficient but went and did that and saw some cases where the resulting headers werent leading to chain sync, I didnt investigate why
12:23 < BlueMatt> might have been unrelated bugs causing it, however
12:48 -!- mrkent_ [~textual@unaffiliated/mrkent] has joined #bitcoin-core-dev
12:55 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
12:57 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 246 seconds]
13:11 -!- mrkent_ [~textual@unaffiliated/mrkent] has quit []
13:22 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev
13:27 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Ping timeout: 268 seconds]
13:27 -!- galileopy [~galileopy@181.121.64.244] has quit [Quit: Leaving]
13:31 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving]
13:36 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds]
13:48 -!- cryptapus [~cyptapus@unaffiliated/cryptapus] has quit [Ping timeout: 252 seconds]
13:48 -!- mrkent_ [~textual@unaffiliated/mrkent] has joined #bitcoin-core-dev
13:50 -!- zooko [~user@c-73-217-96-13.hsd1.co.comcast.net] has joined #bitcoin-core-dev
14:02 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev
14:05 -!- zooko` [~user@c-73-217-16-2.hsd1.co.comcast.net] has joined #bitcoin-core-dev
14:06 -!- zooko [~user@c-73-217-96-13.hsd1.co.comcast.net] has quit [Ping timeout: 244 seconds]
14:07 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Ping timeout: 268 seconds]
14:16 -!- MarcoFalke [8af6020a@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.10] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
14:23 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
14:27 -!- zooko` [~user@c-73-217-16-2.hsd1.co.comcast.net] has quit [Ping timeout: 240 seconds]
14:34 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has joined #bitcoin-core-dev
14:36 -!- pedrobranco [~pedrobran@167.225.61.94.rev.vodafone.pt] has joined #bitcoin-core-dev
14:43 -!- pedrobranco [~pedrobran@167.225.61.94.rev.vodafone.pt] has quit [Read error: Connection reset by peer]
14:48 -!- pedrobranco [~pedrobran@167.225.61.94.rev.vodafone.pt] has joined #bitcoin-core-dev
15:05 -!- pedrobranco [~pedrobran@167.225.61.94.rev.vodafone.pt] has quit []
15:08 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Read error: Connection reset by peer]
15:14 < kanzure> sipa: i replied re: SignatureHash namecalling :) https://github.com/bitcoin/bips/pull/374#issuecomment-212632899
15:15 -!- d_t [~textual@195.52.242.214] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
15:17 -!- TomMc [~tom@unaffiliated/tommc] has quit [Ping timeout: 276 seconds]
15:25 < sipa> kanzure: so did i :)
15:29 -!- SteveTaylor [~staylor@cpe-72-181-158-116.tx.res.rr.com] has quit [Max SendQ exceeded]
15:30 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
15:43 < kanzure> yes i know it's the hash being signed...
15:43 < sipa> sorry :)
15:43 < sipa> may not be obvious to everyone
15:44 < kanzure> *shrug* hard thing to name anyway. i don't have any good ideas for that.
15:44 < sipa> ComputeTransactionHashForSigning
15:44 < kanzure> "but this is a different transaction hash, we promise"
15:45 < kanzure> in some old source code i wrote, i called txid "txhash" because "well txid is a silly name" but now we're about to get a "transaction hash" in some rpc outputs heh
15:45 < phantomcircuit> cfields, i'd like to add something like the benchmarking framework for fuzzing
15:46 < phantomcircuit> i tried copy/pasting the benchmark stuff but i cant seem to get it to work
15:46 < phantomcircuit> any chance you have spare cycles for this?
15:47 < phantomcircuit> essentially just want to have a separate set of binaries which are fenced off by --enable-fuzzing
15:47 -!- Don_John [~Don@249-223-114-134.nat.resnet.nau.edu] has joined #bitcoin-core-dev
15:47 -!- Don_John [~Don@249-223-114-134.nat.resnet.nau.edu] has quit [Remote host closed the connection]
15:48 < BlueMatt> heh, I didnt realize petertodd had posted the bribe-miners-to-do-aml shit on reddit/his blog
15:52 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has quit [Quit: Leaving.]
16:10 -!- zooko [~user@c-73-229-199-227.hsd1.co.comcast.net] has joined #bitcoin-core-dev
16:20 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 250 seconds]
16:51 -!- belcher [~user@unaffiliated/belcher] has quit [Ping timeout: 260 seconds]
17:01 -!- PaulCape_ [~PaulCapes@204.28.124.82] has quit [Quit: .]
17:12 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-core-dev
17:13 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-tzszmypelosumhsf] has quit [Quit: Connection closed for inactivity]
17:25 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has joined #bitcoin-core-dev
17:26 -!- jtimon [~quassel@18.29.134.37.dynamic.jazztel.es] has quit [Ping timeout: 244 seconds]
17:38 -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
17:39 -!- mr_burdell [~mr_burdel@unaffiliated/mr-burdell/x-7609603] has quit [Ping timeout: 252 seconds]
17:39 -!- harding [~harding@mail.dtrt.org] has quit [Ping timeout: 252 seconds]
17:39 -!- LeMiner2 [LeMiner@5ED1AFBF.cm-7-2c.dynamic.ziggo.nl] has quit [Ping timeout: 252 seconds]
17:39 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 252 seconds]
17:39 -!- TD-Linux [~Thomas@about/essy/indecisive/TD-Linux] has quit [Ping timeout: 252 seconds]
17:39 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Ping timeout: 252 seconds]
17:39 -!- nkuttler [~nkuttler@unaffiliated/nkuttler] has quit [Ping timeout: 252 seconds]
17:40 -!- baldur [~baldur@pool-108-29-176-11.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
17:40 -!- windsok_ [~windsok@45.63.59.8] has joined #bitcoin-core-dev
17:40 -!- windsok [~windsok@45.63.59.8] has quit [Ping timeout: 252 seconds]
17:40 -!- harding [~harding@mail.dtrt.org] has joined #bitcoin-core-dev
17:41 -!- mr_burdell [~mr_burdel@unaffiliated/mr-burdell/x-7609603] has joined #bitcoin-core-dev
17:45 -!- TD-Linux [~Thomas@about/essy/indecisive/TD-Linux] has joined #bitcoin-core-dev
17:46 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev
18:03 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has quit [Quit: Leaving.]
18:07 -!- nhancm [~nhancm@14.161.4.70] has joined #bitcoin-core-dev
18:21 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
18:28 -!- nhancm [~nhancm@14.161.4.70] has quit [Quit: Leaving]
18:36 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev
18:38 -!- LeMiner2 [LeMiner@5ED1AFBF.cm-7-2c.dynamic.ziggo.nl] has joined #bitcoin-core-dev
18:38 -!- nkuttler [~nkuttler@unaffiliated/nkuttler] has joined #bitcoin-core-dev
18:48 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Quit: .]
18:50 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-core-dev
19:01 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Read error: Connection reset by peer]
19:01 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-core-dev
19:12 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
19:13 -!- droark [~droark@c-24-22-36-12.hsd1.or.comcast.net] has quit [Quit: ZZZzzz…]
19:15 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 246 seconds]
19:42 -!- cryptocoder [~cryptocod@cpe-76-90-140-31.socal.res.rr.com] has quit [Quit: cryptocoder]
19:51 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds]
19:53 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
20:04 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 276 seconds]
20:18 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
20:22 -!- TomMc [~tom@unaffiliated/tommc] has joined #bitcoin-core-dev
20:32 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Quit: Leaving.]
20:32 -!- TomMc [~tom@unaffiliated/tommc] has quit [Ping timeout: 276 seconds]
20:36 < GitHub112> [bitcoin] theuni opened pull request #7920: Do not merge yet: Switch Travis to Trusty (master...travis-trusty) https://github.com/bitcoin/bitcoin/pull/7920
20:46 -!- mrkent_ [~textual@unaffiliated/mrkent] has quit []
20:48 -!- justanotheruser is now known as justanot1eruser
20:49 -!- justanot1eruser is now known as justanotheruser
20:53 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
20:55 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Client Quit]
20:58 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds]
21:01 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
21:05 -!- shesek [~shesek@bzq-84-110-109-203.cablep.bezeqint.net] has joined #bitcoin-core-dev
21:09 -!- mrkent_ [~textual@unaffiliated/mrkent] has joined #bitcoin-core-dev
21:09 -!- mrkent_ [~textual@unaffiliated/mrkent] has quit [Read error: Connection reset by peer]
21:11 -!- mrkent_ [~textual@unaffiliated/mrkent] has joined #bitcoin-core-dev
21:21 -!- mrkent_ [~textual@unaffiliated/mrkent] has quit []
21:32 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has quit [Read error: Connection reset by peer]
21:33 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-core-dev
21:34 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: Konversation terminated!]
21:51 -!- xiangfu [~xiangfu@111.198.29.53] has joined #bitcoin-core-dev
21:54 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
22:03 -!- cryptocoder [~cryptocod@cpe-76-90-140-31.socal.res.rr.com] has joined #bitcoin-core-dev
22:12 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]
22:15 -!- cjcj [2e3b026a@gateway/web/freenode/ip.46.59.2.106] has joined #bitcoin-core-dev
22:17 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
22:18 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
22:33 -!- ebfull [~sean@73.34.119.0] has quit [Ping timeout: 244 seconds]
22:34 -!- ebfull [~sean@73.34.119.0] has joined #bitcoin-core-dev
22:36 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
22:37 -!- ebfull [~sean@73.34.119.0] has quit [Client Quit]
22:56 -!- mrkent_ [~textual@unaffiliated/mrkent] has joined #bitcoin-core-dev
22:58 -!- mrkent_ [~textual@unaffiliated/mrkent] has quit [Client Quit]
23:14 -!- mrkent_ [~textual@unaffiliated/mrkent] has joined #bitcoin-core-dev
23:14 -!- mrkent_ [~textual@unaffiliated/mrkent] has quit [Client Quit]
23:19 -!- murch [~murch@p4FDB77B2.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
23:21 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
23:22 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
23:42 < phantomcircuit> gmaxwell, is it going to cause problems for afl if a bunch of things to fuzz are all in the same binary with a giant switch() ?
23:45 < gmaxwell> No.
23:45 < gmaxwell> though it might be better to make the switch triggered with a commandline flag, and run afl seperately for each thing. or maybe not.
23:46 < gmaxwell> AFL has a hash table and branches are just randomly mapped into it, so combining things in one binary won't hurt.
23:46 < gmaxwell> you might not get even coverage of the different functions if which function is being used is read from the input though.
23:51 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-fmcnxdxjhbxnevje] has joined #bitcoin-core-dev
23:52 < phantomcircuit> gmaxwell, trying to figure out how to easily fuzz loooots of things
23:52 < gmaxwell> then perhaps one binary and input from AFL is the right thing to do.