12016-04-20T00:13:32 *** AaronvanW has joined #bitcoin-core-dev
22016-04-20T00:13:33 *** AaronvanW has joined #bitcoin-core-dev
32016-04-20T00:53:50 *** TomMc has joined #bitcoin-core-dev
42016-04-20T00:54:34 <kanzure> sipa: there is some minor doubled text at the start of your issue comment, https://github.com/bitcoin/bitcoin/pull/7910#issuecomment-211998958
52016-04-20T00:54:54 <kanzure> well, nearly.
62016-04-20T01:13:00 *** Ylbam has quit IRC
72016-04-20T01:17:52 *** frankenmint has quit IRC
82016-04-20T01:29:13 *** frankenmint has joined #bitcoin-core-dev
92016-04-20T01:30:05 *** dermoth_ has quit IRC
102016-04-20T01:30:41 *** dermoth_ has joined #bitcoin-core-dev
112016-04-20T01:41:47 <kanzure> "The must be at least one output whose scriptPubKey is a single 36-byte push" word missing?
122016-04-20T01:45:38 *** aquentson1 has joined #bitcoin-core-dev
132016-04-20T01:46:54 *** aquentson has quit IRC
142016-04-20T01:56:24 *** shangzhou has joined #bitcoin-core-dev
152016-04-20T01:58:13 *** PaulCapestany has quit IRC
162016-04-20T01:58:34 *** PaulCapestany has joined #bitcoin-core-dev
172016-04-20T01:58:35 <phantomcircuit> sipa: there three preparation commits in 7910 seem like they could be separe pr's
182016-04-20T01:58:47 <phantomcircuit> (and appear to be trivial to review as such)
192016-04-20T01:59:06 <phantomcircuit> as well as the "don't check genesis block" commit
202016-04-20T01:59:16 <phantomcircuit> any reason they aren't proposed as separate pr's?
212016-04-20T02:06:55 *** Chris_Stewart_5 has quit IRC
222016-04-20T02:07:12 *** Giszmo has quit IRC
232016-04-20T02:22:01 *** Chris_Stewart_5 has joined #bitcoin-core-dev
242016-04-20T02:26:47 *** mrkent_ has quit IRC
252016-04-20T02:34:04 *** Chris_Stewart_5 has quit IRC
262016-04-20T02:45:08 *** PaulCapestany has quit IRC
272016-04-20T02:45:37 *** PaulCapestany has joined #bitcoin-core-dev
282016-04-20T02:48:33 *** jtimon has quit IRC
292016-04-20T02:58:03 *** PaulCapestany has quit IRC
302016-04-20T02:58:31 *** PaulCapestany has joined #bitcoin-core-dev
312016-04-20T03:14:01 *** gevs has quit IRC
322016-04-20T03:21:39 *** arubi has quit IRC
332016-04-20T03:22:20 *** PaulCapestany has quit IRC
342016-04-20T03:22:45 *** PaulCapestany has joined #bitcoin-core-dev
352016-04-20T03:25:44 *** gevs has joined #bitcoin-core-dev
362016-04-20T03:39:09 *** TomMc has quit IRC
372016-04-20T03:51:49 *** nhancm has joined #bitcoin-core-dev
382016-04-20T03:53:39 *** nhancm_ has joined #bitcoin-core-dev
392016-04-20T03:57:35 *** nhancm has quit IRC
402016-04-20T04:02:01 *** Alopex has quit IRC
412016-04-20T04:03:06 *** Alopex has joined #bitcoin-core-dev
422016-04-20T04:08:11 *** shangzhou has quit IRC
432016-04-20T04:09:42 *** achow101 has quit IRC
442016-04-20T04:10:40 *** afk11 has quit IRC
452016-04-20T04:10:44 *** PaulCapestany has quit IRC
462016-04-20T04:11:07 *** PaulCapestany has joined #bitcoin-core-dev
472016-04-20T04:11:49 *** isis has quit IRC
482016-04-20T04:15:25 *** afk11 has joined #bitcoin-core-dev
492016-04-20T04:18:32 *** nhancm__ has joined #bitcoin-core-dev
502016-04-20T04:18:51 *** isis has joined #bitcoin-core-dev
512016-04-20T04:21:43 *** nhancm_ has quit IRC
522016-04-20T04:28:02 *** Alopex has quit IRC
532016-04-20T04:29:07 *** Alopex has joined #bitcoin-core-dev
542016-04-20T04:43:55 *** PaulCapestany has quit IRC
552016-04-20T04:44:16 *** PaulCapestany has joined #bitcoin-core-dev
562016-04-20T04:44:44 *** nhancm_ has joined #bitcoin-core-dev
572016-04-20T04:48:04 *** nhancm__ has quit IRC
582016-04-20T05:23:53 *** cryptocoder has quit IRC
592016-04-20T05:28:07 *** cryptocoder has joined #bitcoin-core-dev
602016-04-20T05:31:45 *** xabbix_ has joined #bitcoin-core-dev
612016-04-20T05:32:57 *** xabbix__ has quit IRC
622016-04-20T05:34:51 <NicolasDorier> question: during a sync headers first. chainActive is updated to the last block first when it received the header chain then rewinded if a block is incorrect, or does chainActive is updated as blocks are verified ?
632016-04-20T05:40:05 *** BashCo has quit IRC
642016-04-20T05:46:13 *** mrkent_ has joined #bitcoin-core-dev
652016-04-20T05:54:58 *** PaulCapestany has quit IRC
662016-04-20T05:57:58 *** PaulCapestany has joined #bitcoin-core-dev
672016-04-20T06:00:16 *** dermoth_ has quit IRC
682016-04-20T06:01:00 *** dermoth_ has joined #bitcoin-core-dev
692016-04-20T06:01:08 *** paveljanik has quit IRC
702016-04-20T06:09:46 *** BashCo has joined #bitcoin-core-dev
712016-04-20T06:42:01 *** mrkent_ has quit IRC
722016-04-20T06:48:02 *** Ylbam has joined #bitcoin-core-dev
732016-04-20T07:04:30 *** pedrobranco has joined #bitcoin-core-dev
742016-04-20T07:06:30 *** pedrobranco has quit IRC
752016-04-20T07:17:02 *** Guyver2 has joined #bitcoin-core-dev
762016-04-20T07:24:28 *** Lightsword has quit IRC
772016-04-20T07:24:39 *** TD-Linux has quit IRC
782016-04-20T07:25:20 *** Lightsword has joined #bitcoin-core-dev
792016-04-20T07:25:48 *** TD-Linux has joined #bitcoin-core-dev
802016-04-20T07:30:57 *** aquentson1 has quit IRC
812016-04-20T07:38:39 *** sanada has joined #bitcoin-core-dev
822016-04-20T08:11:48 <sipa> NicolasDorier: chainActive is the best known fully validated chain
832016-04-20T08:14:28 <NicolasDorier> thanks
842016-04-20T08:15:00 <sipa> phantomcircuit: they are
852016-04-20T08:27:16 *** cryptocoder has quit IRC
862016-04-20T08:28:27 *** paveljanik has joined #bitcoin-core-dev
872016-04-20T08:35:16 *** nhancm__ has joined #bitcoin-core-dev
882016-04-20T08:38:19 *** nhancm_ has quit IRC
892016-04-20T08:54:14 *** pedrobranco has joined #bitcoin-core-dev
902016-04-20T08:56:20 *** pedrobranco has quit IRC
912016-04-20T08:56:27 *** pedrobranco has joined #bitcoin-core-dev
922016-04-20T08:57:10 *** murch has joined #bitcoin-core-dev
932016-04-20T08:58:19 <sipa> phantomcircuit: they're in #7749
942016-04-20T09:00:48 <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?
952016-04-20T09:01:59 <btcdrak> murch: they can submit a pull request https://github.com/bitcoin-core/bitcoincore.org/blob/gh-pages/_includes/pages/segwit_support.md
962016-04-20T09:02:32 <btcdrak> as well as https://github.com/bitcoin-core/bitcoincore.org/blob/gh-pages/_posts/en/pages/2016-01-13-segwit-support.md
972016-04-20T09:02:56 <sipa> hi murch!
982016-04-20T09:03:03 <murch> Hi sipa :)
992016-04-20T09:04:35 <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.
1002016-04-20T09:05:22 <btcdrak> murch not sure I follow you.
1012016-04-20T09:07:30 <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
1022016-04-20T09:08:31 <murch> The table is still the same as 16 days ago. :)
1032016-04-20T09:10:54 <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. ;)
1042016-04-20T09:11:08 <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.
1052016-04-20T09:11:20 *** PaulCape_ has joined #bitcoin-core-dev
1062016-04-20T09:13:59 *** PaulCapestany has quit IRC
1072016-04-20T09:17:02 <murch> Okay, I guess I'm mistaken then.
1082016-04-20T09:17:21 <sipa> i think it's good in general to ask teams to keep updating their status
1092016-04-20T09:17:38 <sipa> "in progress" can mean a lot of things
1102016-04-20T09:17:51 <sipa> and there could be a "Ready to rollout whenever the network is ready"
1112016-04-20T09:17:54 <gmaxwell> Indeed, but probably in the form of getting something more granular than in progress.
1122016-04-20T09:18:20 <gmaxwell> like ... "in tested on segnet/testnet"
1132016-04-20T09:20:45 <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
1142016-04-20T09:22:09 <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 :)
1152016-04-20T09:22:21 <sipa> And further analysis would be very useful.
1162016-04-20T09:22:33 <sipa> For example,
1172016-04-20T09:22:46 <murch> Cool, because I'd like to work on something useful for my thesis. :)
1182016-04-20T09:23:09 <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.
1192016-04-20T09:23:34 <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)
1202016-04-20T09:24:27 <murch> sipa: Oh, interesting. I hadn't thought of that. But, shouldn't transactions aim to create the least necessary new UTXO?
1212016-04-20T09:25:19 <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)
1222016-04-20T09:25:58 <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
1232016-04-20T09:27:05 <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.
1242016-04-20T09:27:26 <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?
1252016-04-20T09:27:59 <sipa> it's a complicated problem, because its priorities are unclear: privacy of address linkage, current transaction size, and future transaction sizes
1262016-04-20T09:30:23 <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.
1272016-04-20T09:30:55 <gmaxwell> no, not at all.
1282016-04-20T09:31:00 <sipa> segwit should be orthogonal
1292016-04-20T09:31:09 <sipa> all it does is change the cost metric for computing fees
1302016-04-20T09:31:12 <murch> sipa: I'll have to see if I can find more information on the occurrence of address reuse.
1312016-04-20T09:32:00 <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
1322016-04-20T09:32:21 <murch> gmaxwell: Great! :)
1332016-04-20T09:33:15 <sipa> from an email i have from satoshi over 5 years ago:
1342016-04-20T09:33:18 <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.
1352016-04-20T09:33:18 <gmaxwell> murch: yes, I believe it has; but thats not your fault. We discussed it then.
1362016-04-20T09:33:27 <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
1372016-04-20T09:33:39 *** grimescapes has quit IRC
1382016-04-20T09:34:05 <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.
1392016-04-20T09:35:08 <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)
1402016-04-20T09:35:15 <sipa> should you do that or not
1412016-04-20T09:35:27 <sipa> eh, creating two change outputs
1422016-04-20T09:35:39 <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
1432016-04-20T09:36:06 <sipa> oh, there is a way in which segwit may be relevant: adding an extra input will be cheaper than adding an extra output
1442016-04-20T09:36:33 <gmaxwell> well there will also be the added complication from aggregation in the not that distant future.
1452016-04-20T09:36:38 <murch> sipa: I thought it would make the two about equally expensive?
1462016-04-20T09:36:44 <gmaxwell> Where its much cheaper to spend more inputs at once.
1472016-04-20T09:37:18 <gmaxwell> sipa: it's about equal because of the witness costs of the additional input (id selection)
1482016-04-20T09:37:46 * sipa opens spreadsheet
1492016-04-20T09:37:48 <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?
1502016-04-20T09:38:20 <sipa> murch: the effect of Schnorr isn't that large anymore after segwit
1512016-04-20T09:38:29 <murch> I see, thanks.
1522016-04-20T09:38:32 <sipa> (if you're talking about transaction-wide aggregation)
1532016-04-20T09:39:04 <murch> I believe I was. :)
1542016-04-20T09:39:21 <gmaxwell> sipa: thats now getting called schnorr signatures due to that article. :(
1552016-04-20T09:39:34 <sipa> https://docs.google.com/spreadsheets/d/1TvWBvjAAiVOBUgbYuuQ4rWnMQLXxI3qlMXVWhCdAtSw
1562016-04-20T09:40:16 <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
1572016-04-20T09:40:39 <sipa> murch: where are you studying?
1582016-04-20T09:40:51 <murch> sipa: Karlsruhe Institute of Technology
1592016-04-20T09:41:11 <sipa> ha, nice; i'm in stuttgart currently
1602016-04-20T09:41:17 <sipa> that's pretty close i think
1612016-04-20T09:41:26 <murch> Yeah, it is. I thought you were in Switzerland?
1622016-04-20T09:41:33 <sipa> it's complicated :)
1632016-04-20T09:42:07 <sipa> but i'll be here a lot the next month/months
1642016-04-20T09:45:42 *** MarcoFalke has joined #bitcoin-core-dev
1652016-04-20T09:47:17 <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. :)
1662016-04-20T09:47:27 <sipa> sure!
1672016-04-20T09:47:56 <murch> Do I remember correctly that I've read somewhere that you enjoy rock climbing? ^^
1682016-04-20T09:48:10 <sipa> i believe that's petertodd
1692016-04-20T09:48:32 <gmaxwell> actually petertodd does caves. rock climbing is too safe.
1702016-04-20T09:48:38 <murch> ah, nevermind then. :D
1712016-04-20T09:48:59 <gmaxwell> (maybe he also does rockclimbing, but certantly more caves)
1722016-04-20T09:49:07 <sipa> he's a miner, after all
1732016-04-20T09:49:14 <kinlo> :p
1742016-04-20T09:49:39 <gmaxwell> ::groan::
1752016-04-20T09:49:49 <gmaxwell> I think not anymore.
1762016-04-20T09:50:12 <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.
1772016-04-20T09:50:34 <murch> Thanks guys, you just made my day.
1782016-04-20T09:54:16 *** Thireus1 has quit IRC
1792016-04-20T09:55:46 *** Thireus has joined #bitcoin-core-dev
1802016-04-20T10:00:13 *** aquentson has joined #bitcoin-core-dev
1812016-04-20T10:13:04 *** jannes has joined #bitcoin-core-dev
1822016-04-20T10:18:41 *** murch has quit IRC
1832016-04-20T10:19:54 *** nhancm__ has quit IRC
1842016-04-20T10:38:42 <GitHub185> [bitcoin] venatici opened pull request #7914: [qa] Add optional unique coinbase generation (master...coinbase) https://github.com/bitcoin/bitcoin/pull/7914
1852016-04-20T10:40:34 *** sanada has left #bitcoin-core-dev
1862016-04-20T10:40:43 *** sanada has joined #bitcoin-core-dev
1872016-04-20T10:52:52 *** achow101 has joined #bitcoin-core-dev
1882016-04-20T11:02:01 *** zlover has joined #bitcoin-core-dev
1892016-04-20T11:36:35 <zlover> Hi
1902016-04-20T11:46:42 *** jtimon has joined #bitcoin-core-dev
1912016-04-20T11:53:46 *** cryptapus has joined #bitcoin-core-dev
1922016-04-20T12:36:23 *** randy-waterhouse has quit IRC
1932016-04-20T12:54:17 *** cryptapus__ has joined #bitcoin-core-dev
1942016-04-20T12:57:44 *** cryptapus has quit IRC
1952016-04-20T13:02:43 *** zooko has quit IRC
1962016-04-20T13:16:44 *** mr_burdell has joined #bitcoin-core-dev
1972016-04-20T13:17:03 *** Guest25495 has quit IRC
1982016-04-20T13:17:23 *** Lightsword has quit IRC
1992016-04-20T13:18:41 *** windsok has quit IRC
2002016-04-20T13:18:45 *** schmidty has quit IRC
2012016-04-20T13:19:34 *** windsok has joined #bitcoin-core-dev
2022016-04-20T13:19:50 *** Lightsword has joined #bitcoin-core-dev
2032016-04-20T13:21:08 *** zooko has joined #bitcoin-core-dev
2042016-04-20T13:22:25 <GitHub149> [bitcoin] hmel opened pull request #7916: Explicitly pass CChainParams& to DisconnectTip() (master...global-params-cleanup) https://github.com/bitcoin/bitcoin/pull/7916
2052016-04-20T13:27:16 *** Chris_Stewart_5 has joined #bitcoin-core-dev
2062016-04-20T13:31:35 <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
2072016-04-20T13:42:13 *** face has joined #bitcoin-core-dev
2082016-04-20T13:42:58 *** TomMc has joined #bitcoin-core-dev
2092016-04-20T13:44:32 <jtimon> thank you face for participating in my little experiment in #7829 with your PR #7916 which I'm very happy with!
2102016-04-20T13:47:49 *** zlover has quit IRC
2112016-04-20T13:48:55 *** cryptapus__ is now known as cryptapus
2122016-04-20T13:56:30 <face> jtimon, thank you for doing this. It's a great way to get potential devs to experience for real the dev workflow!
2132016-04-20T14:13:19 <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>)
2142016-04-20T14:13:34 <GitHub13> [bitcoin] sipa opened pull request #7917: Optimize reindex (master...betterreindex) https://github.com/bitcoin/bitcoin/pull/7917
2152016-04-20T14:19:07 <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)
2162016-04-20T14:19:35 *** d_t has joined #bitcoin-core-dev
2172016-04-20T14:30:37 *** zooko has quit IRC
2182016-04-20T14:34:27 <helo> +1 wonderful
2192016-04-20T14:34:31 *** cryptapus has quit IRC
2202016-04-20T14:34:43 *** cryptapus has joined #bitcoin-core-dev
2212016-04-20T14:42:24 *** zooko has joined #bitcoin-core-dev
2222016-04-20T14:44:01 *** BashCo has quit IRC
2232016-04-20T14:46:56 *** galileopy has quit IRC
2242016-04-20T14:47:51 *** Guyver2 has quit IRC
2252016-04-20T15:00:06 *** galileopy has joined #bitcoin-core-dev
2262016-04-20T15:06:36 *** cryptapus is now known as cryptapus_
2272016-04-20T15:06:40 *** JackH has joined #bitcoin-core-dev
2282016-04-20T15:06:52 *** cryptapus_ is now known as cryptapus__
2292016-04-20T15:07:08 *** cryptapus__ is now known as cryptapus
2302016-04-20T15:07:53 *** BashCo has joined #bitcoin-core-dev
2312016-04-20T15:09:11 *** baldur has quit IRC
2322016-04-20T15:13:35 *** murch has joined #bitcoin-core-dev
2332016-04-20T15:21:41 <paveljanik> MarcoFalke, do you have an issue for the wallet.py test?
2342016-04-20T15:22:02 <sipa> cfields has been looking into it as well
2352016-04-20T15:22:10 <paveljanik> I did a quick test yesterday and end up with db-> rename returning 2...
2362016-04-20T15:22:43 <paveljanik> and I'm not able to reproduce the problem today 8)
2372016-04-20T15:22:45 <MarcoFalke> Should be one of those tagged with "wallet": https://github.com/bitcoin/bitcoin/issues/created_by/MarcoFalke
2382016-04-20T15:22:51 <murch> sipa: My master thesis' working title is "Evaluation of Coin Selection Strategies" ;)
2392016-04-20T15:23:13 <MarcoFalke> nice
2402016-04-20T15:23:14 <sipa> murch: nice
2412016-04-20T15:23:25 <MarcoFalke> which field are you doing your masters in?
2422016-04-20T15:23:30 <MarcoFalke> ec or cs?
2432016-04-20T15:23:32 <murch> Computer Science
2442016-04-20T15:24:33 <paveljanik> MarcoFalke, this particular issue seems to be different...
2452016-04-20T15:25:10 <MarcoFalke> Did you save the log?
2462016-04-20T15:25:53 <paveljanik> Once I started to run ./wallet.py --tracerpc --nocleanup in endless cycle, no error 8)
2472016-04-20T15:26:07 <paveljanik> Probably only in the terminal scrollback buffer
2482016-04-20T15:26:09 <paveljanik> 8(
2492016-04-20T15:26:18 <paveljanik> I'm on it.
2502016-04-20T15:27:21 <paveljanik> it would be nice to have --nocleanuponfail ;-)
2512016-04-20T15:28:38 <sipa> --nocleanup exists
2522016-04-20T15:28:52 <sipa> as well as --noshutdown
2532016-04-20T15:38:38 <sipa> morcos: what do you think about https://github.com/sipa/bitcoin/pull/77/commits/9debcaf442f6705c3b08c9fffd5da2ff2116ba53?w=1 ?
2542016-04-20T15:39:05 <sipa> morcos: if you negotiated in the version message to not send transactions, and then send a feefilter, it will start relaying txn
2552016-04-20T15:59:30 <morcos> sipa: so this is just a way to have more flexibility, to allow turning sending of txs back on?
2562016-04-20T16:00:21 <morcos> i don't think i have any issue with that concept, but i'm a bit hesitant on whether its worth the complication
2572016-04-20T16:00:42 <morcos> for instance isn't there code to disconnect/ban peers that send you txs when you didnt' ask for them
2582016-04-20T16:00:56 <morcos> is that corrected to account for this (haven't reviewed the whole pull)
2592016-04-20T16:01:31 <sipa> well this is about sending invs, not getdata or tx
2602016-04-20T16:02:08 <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
2612016-04-20T16:02:24 <sipa> (same as with bip37 filters)
2622016-04-20T16:03:18 <morcos> i'm confused, are you talking about for other implementations sending this (such as lite clients)?
2632016-04-20T16:03:30 <sipa> yes
2642016-04-20T16:03:51 <sipa> not that any of them do send feefilter right now
2652016-04-20T16:04:08 <sipa> i'm just trying to guess why greg's adding a seemingly unrelated change here
2662016-04-20T16:04:34 <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
2672016-04-20T16:04:47 <morcos> ha ha, thats what i'm trying to guess
2682016-04-20T16:06:07 <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.
2692016-04-20T16:06:42 <sipa> it's not that you'd want to start with no txs
2702016-04-20T16:07:04 <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
2712016-04-20T16:07:32 <morcos> but you never get a torrent of invs
2722016-04-20T16:07:45 <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
2732016-04-20T16:07:48 <sipa> i know :)
2742016-04-20T16:07:51 <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
2752016-04-20T16:09:12 <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
2762016-04-20T16:10:09 <morcos> its just tying it into the fRelayTxes variable that i don't see the point of.
2772016-04-20T16:10:24 <sipa> ok
2782016-04-20T16:15:08 <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
2792016-04-20T16:20:55 *** cryptocoder has joined #bitcoin-core-dev
2802016-04-20T16:21:45 <jtimon> ping #7728, all nits resolved, I think
2812016-04-20T16:25:29 <morcos> we don't guard the printing of IP address for incoming connections with fLogIPs. is that intentional?
2822016-04-20T16:31:19 *** cryptocoder_ has joined #bitcoin-core-dev
2832016-04-20T16:33:27 *** cryptocoder has quit IRC
2842016-04-20T16:33:28 *** cryptocoder_ is now known as cryptocoder
2852016-04-20T16:34:44 <kanzure> i have completed my read-through of the segwit pull request, now on to organizing thoughts/notes/bugs...
2862016-04-20T16:47:16 <GitHub21> [bitcoin] MarcoFalke opened pull request #7918: [qa] mininode: Use hexlify wrapper from util (master...Mf1604-qaMininodeHexlify) https://github.com/bitcoin/bitcoin/pull/7918
2872016-04-20T17:06:48 *** arowser has quit IRC
2882016-04-20T17:07:13 *** arowser has joined #bitcoin-core-dev
2892016-04-20T17:19:52 *** Chris_Stewart_5 has quit IRC
2902016-04-20T17:26:54 *** zooko has quit IRC
2912016-04-20T17:49:01 *** zooko has joined #bitcoin-core-dev
2922016-04-20T17:50:06 *** LeMiner2 has joined #bitcoin-core-dev
2932016-04-20T17:52:22 *** LeMiner has quit IRC
2942016-04-20T18:01:12 *** murch has quit IRC
2952016-04-20T18:13:51 *** d_t has quit IRC
2962016-04-20T18:22:46 *** Guyver2 has joined #bitcoin-core-dev
2972016-04-20T18:26:38 <GitHub54> [bitcoin] sdaftuar opened pull request #7919: Fix headers announcements edge case (master...fix-sendheaders-edge-case) https://github.com/bitcoin/bitcoin/pull/7919
2982016-04-20T18:29:00 *** pedrobranco has quit IRC
2992016-04-20T18:30:59 *** pedrobranco has joined #bitcoin-core-dev
3002016-04-20T18:35:16 *** pedrobranco has quit IRC
3012016-04-20T18:37:23 <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.
3022016-04-20T18:37:33 <gmaxwell> I've yanked out those changes.
3032016-04-20T18:39:57 <sipa> thanks
3042016-04-20T18:46:29 *** jannes has quit IRC
3052016-04-20T18:47:26 <sipa> sdaftuar, morcos: did you see BlueMatt's proposal to treat non-connecting headers as invs, and go fetch it?
3062016-04-20T18:48:33 *** pedrobranco has joined #bitcoin-core-dev
3072016-04-20T18:48:35 <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
3082016-04-20T18:49:09 <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
3092016-04-20T18:49:19 <sdaftuar> right, i agree with that
3102016-04-20T18:49:28 <sipa> right, though i vaguely remember that there can be edge cases in which we can't orevent non-connecting headers
3112016-04-20T18:50:03 <sdaftuar> oh, and you're suggesting that we just send the header anyway, rather then revert to inv?
3122016-04-20T18:50:06 <sdaftuar> we could do that too
3132016-04-20T18:50:51 <sdaftuar> there's not much benefit though i think?
3142016-04-20T18:53:17 *** pedrobranco has quit IRC
3152016-04-20T18:54:01 <sipa> i forget the whole discussion; i think it's more about us dealing well with others sending unconnecting headers
3162016-04-20T18:56:52 <sdaftuar> AcceptBlockHeader will give a DoS (10) to a peer for sending a header with an unknown prev block
3172016-04-20T18:59:26 <gmaxwell> My understanding of Matt's complaint is that this then forces you to do the rather complex tracking.
3182016-04-20T18:59:45 <BlueMatt> it introduces a lot of required state in order to do sendheaders
3192016-04-20T18:59:57 <BlueMatt> which seems kinda crazy to me since sendheaders is so conceptually simple
3202016-04-20T19:03:45 *** d_t has joined #bitcoin-core-dev
3212016-04-20T19:04:19 <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?
3222016-04-20T19:04:36 <sdaftuar> i do agree that we could handle unconnecting headers more gracefully though
3232016-04-20T19:05:42 <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?
3242016-04-20T19:06:10 <BlueMatt> having to track the current state of your peer's chain is so gross
3252016-04-20T19:06:17 *** zooko has quit IRC
3262016-04-20T19:06:27 <sdaftuar> we already mostly have to track the state of their chain, to avoid re-announcing blocks to them that they know about
3272016-04-20T19:06:44 *** molz is now known as moli
3282016-04-20T19:06:52 <sdaftuar> and to know which blocks we can download from them
3292016-04-20T19:07:02 <BlueMatt> no we dont
3302016-04-20T19:07:21 <BlueMatt> you can announce any shit you want and your peer will figure out if they want to request it or not
3312016-04-20T19:07:41 <BlueMatt> it says nowhere in the protocol that you have to be reasonable about what you announce
3322016-04-20T19:08:54 <BlueMatt> it also says nowhere that you have to download from all your peers or be a downloading peer in order to sendheaders
3332016-04-20T19:08:57 <BlueMatt> or, at least, you shouldnt be
3342016-04-20T19:09:22 <BlueMatt> not to mention its always been a general goal for the protocol to be as stateless as possible :/
3352016-04-20T19:12:16 *** belcher has joined #bitcoin-core-dev
3362016-04-20T19:16:45 *** Chris_Stewart_5 has joined #bitcoin-core-dev
3372016-04-20T19:18:36 <sipa> BlueMatt: calm down
3382016-04-20T19:18:50 <sipa> BlueMatt: sdaftuar was just saying that we are already tracking that anyway
3392016-04-20T19:19:33 <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
3402016-04-20T19:20:11 <sipa> yes, i'm aware of that
3412016-04-20T19:20:24 <sipa> i don't think anyone is disagreeing with anyone else
3422016-04-20T19:21:10 *** frankenmint has quit IRC
3432016-04-20T19:22:00 <sipa> so the changes required would be 1) not DoS when unconnecting headers are received 2) trigger a getheaders in that case?
3442016-04-20T19:23:19 <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
3452016-04-20T19:23:32 <BlueMatt> might have been unrelated bugs causing it, however
3462016-04-20T19:48:30 *** mrkent_ has joined #bitcoin-core-dev
3472016-04-20T19:54:40 *** molz has joined #bitcoin-core-dev
3482016-04-20T19:57:30 *** moli has quit IRC
3492016-04-20T20:10:44 *** mrkent_ has quit IRC
3502016-04-20T20:21:57 *** frankenmint has joined #bitcoin-core-dev
3512016-04-20T20:26:43 *** frankenmint has quit IRC
3522016-04-20T20:27:36 *** galileopy has quit IRC
3532016-04-20T20:31:34 *** paveljanik has quit IRC
3542016-04-20T20:35:54 *** Chris_Stewart_5 has quit IRC
3552016-04-20T20:47:49 *** cryptapus has quit IRC
3562016-04-20T20:48:13 *** mrkent_ has joined #bitcoin-core-dev
3572016-04-20T20:50:29 *** zooko has joined #bitcoin-core-dev
3582016-04-20T21:02:13 *** frankenmint has joined #bitcoin-core-dev
3592016-04-20T21:04:45 *** zooko` has joined #bitcoin-core-dev
3602016-04-20T21:06:00 *** zooko has quit IRC
3612016-04-20T21:07:25 *** frankenmint has quit IRC
3622016-04-20T21:15:53 *** MarcoFalke has quit IRC
3632016-04-20T21:22:49 *** Chris_Stewart_5 has joined #bitcoin-core-dev
3642016-04-20T21:27:04 *** zooko` has quit IRC
3652016-04-20T21:34:31 *** Giszmo has joined #bitcoin-core-dev
3662016-04-20T21:35:57 *** pedrobranco has joined #bitcoin-core-dev
3672016-04-20T21:43:12 *** pedrobranco has quit IRC
3682016-04-20T21:48:02 *** pedrobranco has joined #bitcoin-core-dev
3692016-04-20T22:04:44 *** pedrobranco has quit IRC
3702016-04-20T22:08:19 *** Guyver2 has quit IRC
3712016-04-20T22:13:57 <kanzure> sipa: i replied re: SignatureHash namecalling :) https://github.com/bitcoin/bips/pull/374#issuecomment-212632899
3722016-04-20T22:15:06 *** d_t has quit IRC
3732016-04-20T22:16:45 *** TomMc has quit IRC
3742016-04-20T22:25:28 <sipa> kanzure: so did i :)
3752016-04-20T22:29:16 *** SteveTaylor has quit IRC
3762016-04-20T22:30:21 *** AaronvanW has quit IRC
3772016-04-20T22:43:20 <kanzure> yes i know it's the hash being signed...
3782016-04-20T22:43:30 <sipa> sorry :)
3792016-04-20T22:43:37 <sipa> may not be obvious to everyone
3802016-04-20T22:43:51 <kanzure> *shrug* hard thing to name anyway. i don't have any good ideas for that.
3812016-04-20T22:44:16 <sipa> ComputeTransactionHashForSigning
3822016-04-20T22:44:28 <kanzure> "but this is a different transaction hash, we promise"
3832016-04-20T22:45:23 <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
3842016-04-20T22:45:25 <phantomcircuit> cfields, i'd like to add something like the benchmarking framework for fuzzing
3852016-04-20T22:45:45 <phantomcircuit> i tried copy/pasting the benchmark stuff but i cant seem to get it to work
3862016-04-20T22:46:14 <phantomcircuit> any chance you have spare cycles for this?
3872016-04-20T22:46:59 <phantomcircuit> essentially just want to have a separate set of binaries which are fenced off by --enable-fuzzing
3882016-04-20T22:47:17 *** Don_John has joined #bitcoin-core-dev
3892016-04-20T22:47:47 <BlueMatt> heh, I didnt realize petertodd had posted the bribe-miners-to-do-aml shit on reddit/his blog
3902016-04-20T22:52:00 *** Giszmo has quit IRC
3912016-04-20T23:10:34 *** zooko has joined #bitcoin-core-dev
3922016-04-20T23:19:43 *** Chris_Stewart_5 has quit IRC
3932016-04-20T23:51:32 *** belcher has quit IRC