12015-12-22T00:03:58 *** Tera2342 has quit IRC
22015-12-22T00:04:31 *** Tera2342 has joined #bitcoin-core-dev
32015-12-22T00:09:09 *** JackH has joined #bitcoin-core-dev
42015-12-22T00:19:04 *** brg444 has quit IRC
52015-12-22T00:19:45 *** brg444 has joined #bitcoin-core-dev
62015-12-22T00:39:23 *** Madars has joined #bitcoin-core-dev
72015-12-22T00:40:21 *** Tera2342 has quit IRC
82015-12-22T00:44:55 *** brg444 has quit IRC
92015-12-22T00:49:45 *** Tera2342 has joined #bitcoin-core-dev
102015-12-22T00:51:27 *** JackH has quit IRC
112015-12-22T00:55:42 <Luke-Jr> cfields: yeah, but I'm not finding any practical way to do that.
122015-12-22T00:56:04 <cfields> Luke-Jr: worked fine in my local test..
132015-12-22T00:56:19 <cfields> PYTHONPATH=$(PYTHONPATH) python foo
142015-12-22T00:56:50 <Luke-Jr> cfields: well, if the user is overriding PYTHONPATH, presumably they want it used with any program during the build process..
152015-12-22T00:57:42 <cfields> Luke-Jr: yes, so make sure it's invoked like that any time python is used
162015-12-22T00:58:03 <cfields> or more easily, just export it from the makefile
172015-12-22T00:58:20 <Luke-Jr> is that portable? and would we need to do it in every makefile?
182015-12-22T00:58:49 <cfields> should be portable, yes. no, all makefiles are included from the top one
192015-12-22T00:59:00 <cfields> well, all in src/ anyway
202015-12-22T00:59:24 *** jrmithdobbs has joined #bitcoin-core-dev
212015-12-22T00:59:46 <jrmithdobbs> i'm sorry, that was poorly executed. That is all.
222015-12-22T01:00:05 <jrmithdobbs> my bad.
232015-12-22T01:01:06 *** jrmithdobbs has quit IRC
242015-12-22T01:01:11 *** jtimon has joined #bitcoin-core-dev
252015-12-22T01:07:02 *** Madars has quit IRC
262015-12-22T01:11:11 *** jcorgan|away is now known as jcorgan
272015-12-22T01:30:18 *** brg444 has joined #bitcoin-core-dev
282015-12-22T01:31:15 *** zookolaptop has quit IRC
292015-12-22T01:34:48 *** dcousens has joined #bitcoin-core-dev
302015-12-22T01:36:54 *** jl2012 has quit IRC
312015-12-22T01:38:00 *** Ylbam has quit IRC
322015-12-22T01:38:23 *** jl2012 has joined #bitcoin-core-dev
332015-12-22T01:39:19 *** Ylbam has joined #bitcoin-core-dev
342015-12-22T01:54:32 *** Ylbam has quit IRC
352015-12-22T01:59:43 *** brg444 has quit IRC
362015-12-22T02:00:18 *** dermoth has quit IRC
372015-12-22T02:00:56 *** dermoth has joined #bitcoin-core-dev
382015-12-22T02:02:49 *** blade has joined #bitcoin-core-dev
392015-12-22T02:03:23 *** PaulCapestany has quit IRC
402015-12-22T02:04:58 <blade> my transactions are not being confirmed whats going on
412015-12-22T02:04:59 *** PaulCapestany has joined #bitcoin-core-dev
422015-12-22T02:05:29 <blade> its been over an hour
432015-12-22T02:06:33 <blade> im useig the bitcoin core wallet
442015-12-22T02:07:02 <jcorgan> blade: this is not the correct channel for this, please go to #bitcoin
452015-12-22T02:07:11 <blade> ok ty
462015-12-22T02:08:08 *** blade has left #bitcoin-core-dev
472015-12-22T02:18:26 <GitHub106> [bitcoin] jrmithdobbs closed pull request #7243: This community NEEDS to adopt a code of conduct. Recent events make t⦠(master...code_of_conduct) https://github.com/bitcoin/bitcoin/pull/7243
482015-12-22T02:18:51 *** Yoghur114_2 has quit IRC
492015-12-22T02:29:05 *** BashCo_ has quit IRC
502015-12-22T02:31:52 *** dhuff has joined #bitcoin-core-dev
512015-12-22T02:34:04 *** dhuff is now known as jrmithdobbs
522015-12-22T02:41:08 *** Madars has joined #bitcoin-core-dev
532015-12-22T02:44:06 *** Tera2342 has quit IRC
542015-12-22T02:47:50 *** raedah has quit IRC
552015-12-22T02:50:46 <jrmithdobbs> I just wanted to say again that I am sorry for that shit storm and thank you guys for what you do.
562015-12-22T02:51:02 *** jrmithdobbs has quit IRC
572015-12-22T02:53:05 *** xiangfu has joined #bitcoin-core-dev
582015-12-22T03:06:07 *** Madars has quit IRC
592015-12-22T03:30:40 *** xiangfu has quit IRC
602015-12-22T03:30:41 <dcousens> jtimon: that came out wrong
612015-12-22T03:30:58 <dcousens> I meant, that is certainly the dream, but, I don't think its where bitcoin/bitcoin is headed
622015-12-22T03:31:31 <dcousens> At least, that opinion is based on the last time I spoke about it
632015-12-22T03:33:02 <jtimon> dcousens: it is certainly where Bitcoin JT is headed :p
642015-12-22T03:33:12 <dcousens> jtimon: haha
652015-12-22T03:33:29 <dcousens> Just realised as I re-read my comment, that it might have come across as "your dreaming buddy"
662015-12-22T03:34:11 <dcousens> when really it was more along the lines of "I hope so to, but, even this PR is having trouble :P"
672015-12-22T03:34:20 <jtimon> it came across just like Luke-Jr's later "I like that but seems out of scope for this PR"
682015-12-22T03:35:08 <jtimon> I literally mean just replacing the ints with strings for now
692015-12-22T03:36:11 <dcousens> I think its worth suggesting, but, theres still the concept which needs to be reach ACK'd status before the syntax is wortwhile
702015-12-22T03:38:01 *** xiangfu has joined #bitcoin-core-dev
712015-12-22T03:38:21 <jtimon> maybe I should make clear that I will maintain a branch with equivalent functionality on top of major releases starting with 0.12 regardless of the PR being merged or not?
722015-12-22T03:38:47 <dcousens> I think people will certainly look to that PR for a simple patch set
732015-12-22T03:41:36 <jtimon> yeah, I will just do free a back-and-forward-port service of the PR with my nits squashed
742015-12-22T03:54:59 *** Madars has joined #bitcoin-core-dev
752015-12-22T03:55:38 <midnightmagic> jtimon: You mean with full-RBF as an option?
762015-12-22T03:56:35 <jtimon> both fullrbf and firstseen, just like the PR (and then, hopefully more)
772015-12-22T03:57:22 <midnightmagic> jtimon: if you want someone to gitian it with you let me know, i'd be happy to an i have plenty of build capacity
782015-12-22T03:58:27 <jtimon> midnightmagic: that's great to know, my plan was to have only a source repo, but if you gitian it, that would be awesome
792015-12-22T03:59:37 *** p15 has joined #bitcoin-core-dev
802015-12-22T04:10:44 <jtimon> Luke-Jr: didn't pblocktemplate->vTxSigOps[0] used to count p2sh sigops too ?
812015-12-22T04:10:55 <Luke-Jr> jtimon: yes, it's supposed to
822015-12-22T04:11:29 <jtimon> so that's what you mean when you say that you won't be able to recommend 0.12 for mining?
832015-12-22T04:12:15 <morcos> jtimon: it still does or there is a bug
842015-12-22T04:12:52 <morcos> but i'm pretty sure there isn't, b/c in checking that blocks were the same i verified that the sigop count was the same
852015-12-22T04:15:20 <morcos> oh [0], i missed that. i don't think i changed that line.
862015-12-22T04:15:42 <jtimon> in last-0.12.99 3cd836c1 I see pblocktemplate->vTxSigOps[0] = GetLegacySigOpCount(pblock->vtx[0]);
872015-12-22T04:16:00 <morcos> yeah, i think thats what its like in 0.11 too
882015-12-22T04:16:29 <morcos> yep
892015-12-22T04:16:46 *** Madars has quit IRC
902015-12-22T04:17:43 <jtimon> yeah, that's not changed in 553cad94
912015-12-22T04:18:24 <jtimon> Luke-Jr: is it supposed to count p2sh sigops or not?
922015-12-22T04:18:26 <morcos> its probably meaningless the way its used in practice, because a p2sh script isn't used as the coinbase dummy argument
932015-12-22T04:18:29 <Luke-Jr> jtimon: yes
942015-12-22T04:18:53 <Luke-Jr> it's supposed to be everything to total to the sigoplimit
952015-12-22T04:21:51 <jtimon> Luke-Jr: but https://github.com/bitcoin/bitcoin/blame/master/src/miner.cpp#L289 it's there from the creation of miner.cpp
962015-12-22T04:25:08 <jtimon> oh that's only for the coinbase, never mind
972015-12-22T04:25:51 <jtimon> sorry, metal furt
982015-12-22T04:25:57 <jtimon> mental
992015-12-22T04:45:39 <Luke-Jr> [04:11:29] <jtimon> so that's what you mean when you say that you won't be able to recommend 0.12 for mining? <-- by this I mean, removal of priority policy support
1002015-12-22T04:46:17 <Luke-Jr> note the current status quo is not merely "disabled by default", because the new implementation is still buggy
1012015-12-22T04:46:51 <Luke-Jr> (status quo in master, I mean, not the network)
1022015-12-22T04:49:45 <jtimon> I'm mostly interested in your opinion on last-0.12.99 3cd836c1
1032015-12-22T04:50:41 <jtimon> Luke-Jr: ie what you think that needs to be solved for 0.12
1042015-12-22T04:51:42 <Luke-Jr> the big things IMO are 1) ability to configure RBF policy (high demand from users); 2) fix policy support; 3) restore sane default setting for policy size
1052015-12-22T04:52:16 * Luke-Jr looks over PR list to make sure he didn't miss anything too important
1062015-12-22T04:52:53 <Luke-Jr> bytespersigop may be a good idea, and is tagged for 0.12
1072015-12-22T04:53:04 <Luke-Jr> but technically not a fix
1082015-12-22T04:58:55 <jtimon> oh, you expect the optional fullrbf to be backported to 0.12 ?
1092015-12-22T04:59:27 <jtimon> I mean, I wouldn't oppose
1102015-12-22T04:59:47 <Luke-Jr> yes, that was something many people expected to be part of the original PR..
1112015-12-22T05:00:09 *** dermoth has quit IRC
1122015-12-22T05:00:36 <Luke-Jr> I consider it a bug that it's not configurable right now.
1132015-12-22T05:01:22 <jtimon> well, I consider it it cheap-to-maintain missing functionality, but we agree overall
1142015-12-22T05:01:42 <Luke-Jr> 7217 and 7213 also stand out as bugfixes that perhaps ought to get into 0.12
1152015-12-22T05:02:10 <jtimon> I guess the difference is that I would be happy if it was merged in master but not backported to 0.12
1162015-12-22T05:02:47 *** dermoth has joined #bitcoin-core-dev
1172015-12-22T05:02:49 <Luke-Jr> many people I spoke to (on reddit especially) found the RBF changes acceptable only knowing it was configurable
1182015-12-22T05:04:19 <jtimon> I think we should have supported fullrbf optionally and firstseen as default ages ago, maybe opt-in rbf wouldn't have been necessary
1192015-12-22T05:05:54 <Luke-Jr> well, in general I think opt-in was a good improvement. but not if it entails developers trying to control users.
1202015-12-22T05:07:50 <jtimon> yeah, I agree opt-in is a great solution to the dilema, I'm just pointing out that for me there wasn't a dilema in the first place, if there's controversy, that's more of a reason to offer both sides of the local policy controversy so that people can choose
1212015-12-22T05:08:43 <jtimon> I hope this doesn't get rejected under the "controversial syndrome" btcdrak once talked me about
1222015-12-22T05:10:02 <sipa> Luke-Jr: all fine with making optin configurable
1232015-12-22T05:10:23 <sipa> i am not fine with adding full rbf support
1242015-12-22T05:10:31 <Luke-Jr> sipa: it's not your place to decide.
1252015-12-22T05:10:36 <sipa> sure it is
1262015-12-22T05:10:53 <sipa> it is not my place to decide what people run
1272015-12-22T05:10:53 <Luke-Jr> no, it is the end-user's right to decide.
1282015-12-22T05:11:12 <sipa> it is my place to decide what i want the software that i am maintainer of to encourage
1292015-12-22T05:11:18 <jtimon> sipa: why -policy=firstseen is fine but -policy=fullrbf is not?
1302015-12-22T05:11:29 <sipa> jtimon: it breaks a social contract
1312015-12-22T05:11:39 <Luke-Jr> it breaks no social contract. -.-
1322015-12-22T05:11:40 <jtimon> what social contract?
1332015-12-22T05:12:21 <sipa> whether you like it or not, some people see transactions as implicitly promising to not double spend
1342015-12-22T05:12:28 <jtimon> this is policy, -policy=firstseen users must accept that they can't do anything about me running -policy=fullrbf (and viceversa)
1352015-12-22T05:12:28 <Luke-Jr> RBF does not change that.
1362015-12-22T05:12:46 *** Greyboy has quit IRC
1372015-12-22T05:12:48 <sipa> we can explain to people that this is a bad idea, but it does not change the expectation
1382015-12-22T05:13:08 <sipa> and we just made that promise stronger by giving a way to opt out of it
1392015-12-22T05:13:09 <jtimon> sipa: and they are free to use firstseen, whatever they like it or not, there's people that prefer fullrbf
1402015-12-22T05:13:28 <jtimon> and they can't do anything to stop them
1412015-12-22T05:13:34 <sipa> jtimon: absolutely!
1422015-12-22T05:13:47 <Luke-Jr> Opt-in RBF does not opt out of the implied promise not to fraudulently double-spend
1432015-12-22T05:13:48 <sipa> but i don't think we should encourage it either
1442015-12-22T05:14:26 <sipa> Luke-Jr: imho it does
1452015-12-22T05:14:45 <Luke-Jr> sipa: that's ridiculous.
1462015-12-22T05:14:52 <Luke-Jr> those promises are part of society, not the protocol
1472015-12-22T05:15:28 <jtimon> ok, but let's not make another bool please, let's do -policy=firstseen -policy=optinrbf even if bitcoin core insists on having people like petertodd publishing parallel releases
1482015-12-22T05:16:04 <jtimon> it will be cleaner for me to add the -policy=fullrbf option in bitcoin JT 0.12
1492015-12-22T05:16:53 <jtimon> Luke-Jr: I think he means bitcoin core did the promise, not the protocol
1502015-12-22T05:16:58 <Luke-Jr> jtimon: any interest in combining efforts perhaps BTW? maybe Bitcoin LJR + Bitcoin JT can merge to some not-so-personal name?
1512015-12-22T05:18:22 <jtimon> I would be happy to collaborate with you in bitcoin-policy if that makes sense to you
1522015-12-22T05:19:00 <jtimon> as long as it starts with something like #6423
1532015-12-22T05:20:19 <jtimon> but I'm still recovering from #5595/#6068's depression...
1542015-12-22T05:21:36 <Luke-Jr> jtimon: I suspect the key thing to merging our forks will be whether the changes you want conflict in unresolvable ways with the ones I want.
1552015-12-22T05:23:16 <jtimon> and sorry for being sincere, but you're partly responsible of me being so disappointed about that, I would have happily s/CStandardPolicy/CDefaultPolicy/ or added a TODO to some of the interface methods documentation to say it's incomplete months ago, but not when I closed it , for my own sanity
1562015-12-22T05:23:49 <btcdrak> sipa, luke-jr, we should just leave rbf as it is for now
1572015-12-22T05:24:15 <btcdrak> rbf will come slowly. it wont come by trying to push too fast
1582015-12-22T05:24:16 <jtimon> if you want to collaborate with me on this bitcoin-policy branch you'll have to learn to nit faster, because I already have Bitcoin Core for when I'm fine waiting
1592015-12-22T05:24:29 <sipa> agree
1602015-12-22T05:25:08 <jtimon> btcdrak: sipa: ok, but let's not make another bool please, let's do -policy=firstseen -policy=optinrbf even if bitcoin core insists on having people like petertodd publishing parallel releases
1612015-12-22T05:25:28 <sipa> jtimon: totally fine with that
1622015-12-22T05:26:12 <jtimon> Luke-Jr: would you be fine with that for #7219 ?
1632015-12-22T05:27:19 <Luke-Jr> jtimon: using -policy now, locks us in to the syntax for it; I don't know that the final syntax is so obvious
1642015-12-22T05:27:21 <jtimon> supporting -policy=firstseen and -policy=optinrbf, but not -policy=fullrbf (yet, we can do that on our branch for now)
1652015-12-22T05:28:24 <jtimon> well, in #6423 I was preparing for different policies to be able to have different attributes and command-line options dynamically
1662015-12-22T05:29:12 <jtimon> (even if most policies just use specific default values for parameters in CDefaultPolicy)
1672015-12-22T05:29:50 <Luke-Jr> hmm, so -policy would be kind of a "load this module" type logic?
1682015-12-22T05:30:01 <jtimon> see also #5180
1692015-12-22T05:30:06 <Luke-Jr> jtimon: how would you propose users select opt-in FSS?
1702015-12-22T05:30:21 <jtimon> optin FSS?
1712015-12-22T05:30:26 <jtimon> what is that?
1722015-12-22T05:30:27 *** desantis has quit IRC
1732015-12-22T05:30:33 <sipa> fss rbf?
1742015-12-22T05:31:38 <Luke-Jr> jtimon: first-seen-safe RBF only with the opt-in flag
1752015-12-22T05:31:50 <jtimon> I was thinking of maybe cpfp variations as more potential options, or maybe just a parametrizable cpfp class that extends CDefaultPolicy
1762015-12-22T05:33:01 <sipa> can we just stop doing dozens of policies that nobody asks for?
1772015-12-22T05:33:12 <sipa> i understand that you'd want to disable rbf
1782015-12-22T05:33:38 *** Tera2342 has joined #bitcoin-core-dev
1792015-12-22T05:36:35 <Luke-Jr> sipa: that implies we should do policies that people *do* ask for.. like priority space and full RBF
1802015-12-22T05:36:40 <jtimon> sipa: now we're talking about our potential collaboration (or Bitcoin JT if Luke-Jr cannot commit to the "nit early, nit often" principle) in which I'm interested in exposing as many policies as possible (just to prove the reusability of the underlying Cpolicy interface)
1812015-12-22T05:37:15 <Luke-Jr> jtimon: unfortunately, I don't think I can commit to that, due to time constraints.
1822015-12-22T05:37:53 <sipa> Luke-Jr: yes, i would like to support priority space; that's just an engineering tradeoff that it is hard to maintain; i am willing to promise that i'll personally look into a replacement
1832015-12-22T05:38:30 <sipa> Luke-Jr: full rbf makes no sense for a full node unless miners do it
1842015-12-22T05:38:49 <Luke-Jr> sipa: I'm pretty sure there are miners who do ti.
1852015-12-22T05:38:50 <sipa> Luke-Jr: once they do, i'm sure we can even discuss it as default policy in bitcoin core
1862015-12-22T05:39:00 <sipa> once they do in significant numbers
1872015-12-22T05:40:28 <Luke-Jr> wangchun: ^ willing to take the heat? :P
1882015-12-22T05:41:28 <jtimon> Luke-Jr: that shouldn't be an impediment, bitcoin-policy can be just the subset of bitcoin JT related to policy that you are happy with when you have time to be happy with it, not in a hurry for review anymore since this is going to be on top of 0.12 instead of master (I don't plan to PR anything policy-related until all the consensus code is encapsulated in a single building module independent from storage in master)
1892015-12-22T05:41:55 <Luke-Jr> sipa: a replacement for the priority area would be nice, but until it exists and is well-tested, it isn't reasonable to remove the existing, working policy there
1902015-12-22T05:42:09 <btcdrak> Luke-Jr: imo the best way for rbf is we release as is with optin full enabled, after 6-12 months after wallets have adapted and people see the world hasnt exploded, then we can propose a move to full full
1912015-12-22T05:42:32 <btcdrak> petertodds optin full rbf is a political compromise
1922015-12-22T05:42:41 <btcdrak> as was fssrbf
1932015-12-22T05:42:46 <btcdrak> baby steps...
1942015-12-22T05:42:58 <Luke-Jr> btcdrak: it wouldn't bother me as much, if it wasn't a pattern moving from "work toward increasing policy options" to "remove policy options and make them harder to develop"
1952015-12-22T05:43:20 <jtimon> btcdrak: maintaining the optional -policy=firstseen shouldn't be more controversial than not doing it
1962015-12-22T05:46:03 <jtimon> maybe -policy=default is better than -policy=optinrbf, but that is more resuable code and shouldn't be more controversial
1972015-12-22T05:47:45 <jtimon> or I don't see how unless we support -policy=fullrbf in core, but as said I'm not concerned about maintaining that in a separate branch, it should be much easier to rebase to the next major release from now on than it was before for petertodd
1982015-12-22T05:49:16 <jtimon> let's not support it on github/bitcoin, but it would be good that people understand that is going to be supported anyway, even if they don't like that
1992015-12-22T05:50:28 <jtimon> just like we fullrbf supporters understand that firstseen is going to be supported (in my case, I really want it to be supported)
2002015-12-22T05:52:15 <jtimon> just from the noise in the PR, I believe there's demand for firstseen, and I haven't seen anyone opposing to expose that, only some people opposing to fullrbf
2012015-12-22T05:52:23 <Luke-Jr> if we're going to deny an option to full-full-RBF users, it makes just as much sense to deny the option to no-optin-RBF users. neither opinion has a more logical basis than the other, so we shouldn't play favourites in this extreme.
2022015-12-22T05:54:41 <jtimon> well, although I agree that both parts in the policy-discussion should be treated equally (not necessarily with defaults) I guess the difference is that firstseen was the policy that was previously available
2032015-12-22T05:55:29 <jtimon> anyway, I would like to understand your opinion on the special-space better too
2042015-12-22T05:55:36 *** p15_ has joined #bitcoin-core-dev
2052015-12-22T05:57:12 <Luke-Jr> jtimon: you mean priority?
2062015-12-22T05:57:30 <jtimon> when I ask what's the use case you keep saying "to support the current policy", but I don't see how the current policy cannot be implemented with a unified metric, even if it's time dependent (which may have performance costs)
2072015-12-22T05:57:53 <jtimon> but there's no need for a separated space
2082015-12-22T05:57:54 *** Madars has joined #bitcoin-core-dev
2092015-12-22T05:58:00 *** p15 has quit IRC
2102015-12-22T05:58:25 <Luke-Jr> jtimon: by considering the feerate together with priority, it exposes the policy to feerate-based attacks (which are clearly a "when", not "if")
2112015-12-22T05:59:05 <jtimon> yep, you could have a g(f(fees, size), priority) "fitness function" for transactions without special space
2122015-12-22T05:59:46 <Luke-Jr> and then when someone games the fees, the whole block is spam and legit users are blocked
2132015-12-22T06:00:35 <jtimon> no, you can create an heuristic function that is equivalent to any policy you can think of based on separated spaces, that should be methematically provable (not that I can do it right now)
2142015-12-22T06:00:58 <jtimon> no, when I say equivalent I mean equivalent
2152015-12-22T06:01:15 <aj> jtimon: only if you adjust g() based on what transactions are available
2162015-12-22T06:01:40 <Luke-Jr> jtimon: that's at the very least much more complex to implement
2172015-12-22T06:01:51 <sipa> jtimon: that's not the case unless you're willing to recompute virtual fees after every tx
2182015-12-22T06:01:52 <jtimon> aj correct, that only seems a performance challenge
2192015-12-22T06:01:53 <Luke-Jr> the goal ought to be to make policies *easier* to write, not absurdly complicated
2202015-12-22T06:02:38 <sipa> Luke-Jr: how about we introduce a new scripting language then to configure relay and minig policies?
2212015-12-22T06:02:49 <sipa> we still have engineering tradeoffs to makr
2222015-12-22T06:02:56 *** go1111111 has joined #bitcoin-core-dev
2232015-12-22T06:03:23 <jtimon> aj not a code complexity one, we can maintain an optional functional-equivalent-but-far-less-performant version of "the current policy" with reduced maintainence costs, if someone wants to maitain the re-optimizations that's another topic
2242015-12-22T06:03:28 <Luke-Jr> sipa: that's basically my long-term goal
2252015-12-22T06:03:41 <Luke-Jr> minus it being a new language.. no reason not to allow using existing ones
2262015-12-22T06:05:09 <jtimon> the goal of my branch is to offer as much functionality as possible as a showcase that the refactors behind it actually make the code more reusable and maintainable, not necessarily that all particular optional functionalities are suppported in the most optimal way
2272015-12-22T06:05:43 <sipa> maintainable code is a worthy goal, and that's the extent of my support for policy refactors
2282015-12-22T06:06:04 <sipa> i don't agree with the extreme configurability of policy as a goal
2292015-12-22T06:06:04 <GitHub50> [bitcoin] luke-jr closed pull request #7219: Make RBF policies optional (master...rbf_opts) https://github.com/bitcoin/bitcoin/pull/7219
2302015-12-22T06:06:35 <jtimon> no, extreme configurability is the means
2312015-12-22T06:07:17 <sipa> extreme runtime configurability i mea
2322015-12-22T06:07:55 <jtimon> it doesn't need to get into master, but a -policy=<string> is, I think, not that much to ask (and could save us some new bool command-line options in the future)
2332015-12-22T06:08:05 <sipa> making policy changes easy to write is indeed a good way to verify the modularization you're obtained
2342015-12-22T06:08:41 <jtimon> yes, yes, I mean the same, the goal is software quality, extreme runtime configurability is kind of a test to reusability
2352015-12-22T06:09:31 <sipa> ok, agree!
2362015-12-22T06:10:15 <aj> jtimon: hmm, if you want to define your own g() and make it vary depending on the remainder of the mempool, maybe the way to do that is with a generic update_mempool_tx_score rpc call, and writing the actual logic externally in python/etc?
2372015-12-22T06:10:53 <jtimon> that's why I'm intersted on what luke really wants behind its defense of the separate space, because I find "the current policy" uninteresting to support in terms of reusability, I cannot think of another policy that is not time dependent and requires a separated space
2382015-12-22T06:11:50 <jtimon> aj: well, I would just start with a CPolicy abstract class
2392015-12-22T06:12:22 <jtimon> or a -policy=<string> command line option would also help
2402015-12-22T06:13:19 <jtimon> but yeah, we could have -policy=rpc_mempool_score_update, shouldn't be hard
2412015-12-22T06:14:36 <jtimon> and it could have different command-line parameters also configurable via GUI
2422015-12-22T06:16:19 <jtimon> s/requires/"requires"
2432015-12-22T06:17:56 <jtimon> so I would like to know more from luke about what's so great about not checking any minimum fee for some transactions
2442015-12-22T06:19:32 *** Madars has quit IRC
2452015-12-22T06:21:58 <jtimon> aj in other words:
2462015-12-22T06:21:58 <jtimon> def g(tx)
2472015-12-22T06:21:58 <jtimon> if reason(tx.fees, tx.size) < reason_plus_ddos(mempool, tx):
2482015-12-22T06:21:58 <jtimon> return false
2492015-12-22T06:21:58 <jtimon> if priority < simulate_separate_space(tx, whatever)
2502015-12-22T06:21:58 <jtimon> return false
2512015-12-22T06:22:01 <jtimon> return true
2522015-12-22T06:22:44 <phantomcircuit> Luke-Jr, i agree with jtimon that the cli parameter should be a string
2532015-12-22T06:22:49 <jtimon> if priority(tx) < simulate_separate_space(tx, whatever)
2542015-12-22T06:23:05 <Luke-Jr> phantomcircuit: comma-separated?
2552015-12-22T06:23:31 *** zookolaptop has joined #bitcoin-core-dev
2562015-12-22T06:23:38 *** p15_ has quit IRC
2572015-12-22T06:23:58 <phantomcircuit> Luke-Jr, rbf policy option should be a string not 0,1,2
2582015-12-22T06:24:08 <phantomcircuit> (just noticed you closed it, so nvm)
2592015-12-22T06:25:38 <Luke-Jr> phantomcircuit: how do you specify both FSS and optin?
2602015-12-22T06:25:49 <Luke-Jr> phantomcircuit: "nvm" is unnecessary, as this is still going in LJR
2612015-12-22T06:26:32 <phantomcircuit> Luke-Jr, specify the parameter twice
2622015-12-22T06:26:40 <aj> jtimon: the thing with priority is you can't just rely on choosing where in the order to insert the tx initially; you have to re-sort the old transactions as time passes. with an rpc set_mempool_tx_score call you could do that, but you'd still have to apply it to an individual transaction repeatedly while it sits in the mempool
2632015-12-22T06:26:40 <phantomcircuit> isn't it implemented as a multimap anyways?
2642015-12-22T06:26:44 <Luke-Jr> ew
2652015-12-22T06:26:50 <jtimon> no!!!
2662015-12-22T06:27:32 <jtimon> -policy=a, -policy=b, -policy=a_and_b: that's how you do a_and_b
2672015-12-22T06:27:57 <jtimon> I mean, how you support it in parallel to only_a and only_b
2682015-12-22T06:28:20 *** p15 has joined #bitcoin-core-dev
2692015-12-22T06:28:20 <Luke-Jr> jtimon: that isn't going to scale
2702015-12-22T06:28:25 <jtimon> I still don't think I undesrstand firstseen
2712015-12-22T06:28:43 <jtimon> I still don't think I undesrstand firstseen_optinrbf, isn't that the same as optinrbf?
2722015-12-22T06:28:52 <Luke-Jr> no, it isn't.
2732015-12-22T06:29:02 <Luke-Jr> why would you use underscores instead of commas?
2742015-12-22T06:29:17 <phantomcircuit> Luke-Jr, meh, internally it's a bitfield presented to the user as -policy=A -policy=B
2752015-12-22T06:30:05 <jtimon> Luke-Jr: well, some policies must die so that others can be maintained in parallel to the default one, infinite configurability forever certainly doesn't scale
2762015-12-22T06:31:23 <jtimon> the goal of bitcoin-policy could be to support the most interesting ones that are relatively easy to rebase from the latest major release, or that can be easily added in the current one
2772015-12-22T06:34:03 <Luke-Jr> â¦
2782015-12-22T06:34:18 *** zookolaptop has quit IRC
2792015-12-22T06:34:27 <jtimon> Luke-Jr: re why would you use underscores instead of commas?
2802015-12-22T06:34:28 <jtimon> I would use # or @, of course, (ie -policy=a#and#b), but I thought underscores were the new trend
2812015-12-22T06:34:48 <Luke-Jr> more user-friendly to use commas
2822015-12-22T06:34:57 <Luke-Jr> since it's being parsed into multiple options
2832015-12-22T06:36:07 <jtimon> the point is, once it is a string, I don't f#$%^ care what symbols you prefer as long as they play well with the command line (ie not -policy=m-y-p-o-l-i-c-y)
2842015-12-22T06:39:29 <jtimon> and the other point is, I undesrtand -policy=firstseen and -policy=optinrbf, but not -policy=firstseen,optinrbf
2852015-12-22T06:40:02 <jtimon> (or -policy=firstseen_optinrbf, whatever)
2862015-12-22T06:40:58 <sipa> aj: s/set_mempool_tx_score/prioritizetransaction/
2872015-12-22T06:41:05 <sipa> aj: it already exists :)
2882015-12-22T06:41:49 <jtimon> sipa: oh, that's what is for?
2892015-12-22T06:42:16 <aj> sipa: (prioritise with an s, apparently!)
2902015-12-22T06:42:31 <sipa> british vs american :)
2912015-12-22T06:42:36 <sipa> i never know which is which
2922015-12-22T06:42:42 <sipa> so i just pick the shortest
2932015-12-22T06:42:45 <btcdrak> s is british
2942015-12-22T06:42:49 <dcousens> ^
2952015-12-22T06:42:55 <btcdrak> british is the original <<<<<<
2962015-12-22T06:43:01 * btcdrak grins
2972015-12-22T06:43:27 <btcdrak> I think it's the status quo in software to use the American spelling
2982015-12-22T06:43:36 <dcousens> pretty much
2992015-12-22T06:43:50 <btcdrak> I dislike that fact a lot...
3002015-12-22T06:44:10 <dcousens> I gave up on `s` in favour of `z`, and almost never use `u`
3012015-12-22T06:44:50 <aj> sipa: yeah, that seems sufficient, would be a bit painful to use for externally hacking priority back in
3022015-12-22T06:45:17 <dcousens> jtimon: would it ever be worth policy being that 'plug and playable' though?
3032015-12-22T06:45:46 <dcousens> like, unless you're a miner, or doing it for hardware reasons
3042015-12-22T06:45:52 <jtimon> dcousens: as aj suggests? I don't know seems it would be very slow
3052015-12-22T06:46:05 <dcousens> you're almost better off just capturing everything
3062015-12-22T06:46:55 <dcousens> having your policy mimic miners is great for having an insight into what could be included in the next block
3072015-12-22T06:47:01 <dcousens> but, its entirely speculative
3082015-12-22T06:47:22 <jtimon> I would chose whatever option it's easier to maintain, if only I had an intersting use case (I just don't think free transactions are an interesting use case)
3092015-12-22T06:50:40 <jtimon> in fact, I believe I will just remove the free tx special case from bitcoin-consensus-policy-jt, so it doesn't beelong in the bitcoin-policy-luke-jt common branch
3102015-12-22T06:53:22 <wangchun> Luke-Jr: But I think for cafe-like small businesses, 0-conf is already unsafe as the block becoming full
3112015-12-22T06:53:49 <Luke-Jr> wangchun: unconfirmed transactions are absolutely unsafe, I agree
3122015-12-22T06:54:24 *** Guyver2 has joined #bitcoin-core-dev
3132015-12-22T06:54:59 <wangchun> If a customer pays the bill with a no-fee tx, what should the cashier do? It probably never get confirmed
3142015-12-22T06:56:02 <wangchun> And for priority space, if the block is not approaching to max block size, I would like to include some free tx in my block
3152015-12-22T06:56:10 <Luke-Jr> wangchun: well, he can always CPFP it
3162015-12-22T06:56:32 <Luke-Jr> and yes, priority will eventually make it eligible for charitable miners
3172015-12-22T06:56:34 <wangchun> but if the block is already full, why should I still sort some tx by priority?
3182015-12-22T06:56:45 <wangchun> That is why I used minblocksize=250000 before
3192015-12-22T06:56:49 <Luke-Jr> wangchun: well, what about if there is a spam attack with fees?
3202015-12-22T06:56:52 <Luke-Jr> like in the summer
3212015-12-22T06:58:05 <wangchun> I have to set limitfreerelay to zero because I am aware some of my tx to be dropped randomly from mempool due to one patch recently get merged
3222015-12-22T06:58:48 <wangchun> I am glad to hear how to disable this "feature", however.
3232015-12-22T06:59:29 <wangchun> Luke-Jr: As you have suggested before, set minblocksize to 250k may open a door to spammers
3242015-12-22T06:59:54 <wangchun> CPFP should solve cafe owner's problem
3252015-12-22T07:01:31 <Luke-Jr> wangchun: no, I mean like over the summer, when spammers backlogged with paying fees
3262015-12-22T07:01:42 <Luke-Jr> wangchun: if you put fees first, you would mine those before priority txs
3272015-12-22T07:01:55 <maaku> wangchun: it is only a matter of time until mempools are always full
3282015-12-22T07:04:34 <wangchun> maaku: that's why we have limitfreerelay to zero
3292015-12-22T07:05:21 <maaku> wangchun: no matter your parameters. bitcoin usage will grow to exceed capacity. this is the expected outcome
3302015-12-22T07:05:24 <wangchun> But if any devs could tell me how to disable the mempool tx dropping feature, I would like to increase limitfreerelay value to 3 or 5 which should help no-fee tx
3312015-12-22T07:06:23 <wangchun> also priority size should decrease as the block template is approaching max block size
3322015-12-22T07:07:50 <wangchun> Maybe I should write the patch
3332015-12-22T07:08:09 <sipa> wangchun: the mempool limiting will only drop the lowest fee transactions, quite intelligently
3342015-12-22T07:08:16 <wangchun> Luke-Jr: What's your attitude toward priority size?
3352015-12-22T07:08:27 <sipa> wangchun: the solution is just to increase the size of the mempool
3362015-12-22T07:08:30 <wangchun> sipa: I know, but we have the most important tx the lowest prioirty..
3372015-12-22T07:08:36 *** tripleslash_h has joined #bitcoin-core-dev
3382015-12-22T07:08:41 <wangchun> sipa: so I must switch off this feature
3392015-12-22T07:08:45 <sipa> wangchun: that i don't understand
3402015-12-22T07:08:56 <Luke-Jr> wangchun: I think it should be non-zero :p
3412015-12-22T07:09:12 <wangchun> sipa: I have a txt which has a list of tx we must confirm at the highest prioirty
3422015-12-22T07:09:25 <wangchun> sipa: this txt file is read every time createnewblock is called
3432015-12-22T07:09:34 <sipa> wangchun: you can use prioritisetransaction ?
3442015-12-22T07:09:43 <wangchun> sipa: but the tx themselves in mempool remain their priority untouched
3452015-12-22T07:09:58 <wangchun> sipa: prioritisetransaction does not persist
3462015-12-22T07:09:59 *** tripleslash has quit IRC
3472015-12-22T07:10:10 <wangchun> sipa: and it cannot be edited with vim
3482015-12-22T07:10:11 <sipa> wangchun: across restarts it does not
3492015-12-22T07:10:24 <Quent> if blocks are full is it not easy to ddos spam the system so increasing the fee short term to unbearable amounts?
3502015-12-22T07:10:43 <Quent> I think someone has some maths to show it too...
3512015-12-22T07:11:56 <sipa> wangchun: it'd be pretty easy to hook up the reading of that file with the prioritization inside the mempool that prioritisetransaction does too
3522015-12-22T07:12:14 <sipa> wangchun: which will automatically make those transactions ineligible for eviction
3532015-12-22T07:12:29 <wangchun> sipa: I don't know how often it is called, reading files is expensive i suppose
3542015-12-22T07:13:05 *** raedah has joined #bitcoin-core-dev
3552015-12-22T07:13:10 <sipa> wangchun: i haven't seen your code; i'm just saying that the two mechanisms should easily combinable
3562015-12-22T07:13:19 <Quent> http://www.metzdowd.com/pipermail/cryptography/2015-December/027568.html
3572015-12-22T07:13:22 <wangchun> sipa: but if you point me the git rev of the tx-dropping patch, that would help
3582015-12-22T07:13:41 <sipa> wangchun: just increase the mempool size to whatever you can support
3592015-12-22T07:14:02 <wangchun> sorry I have to leave, check irc log later
3602015-12-22T07:14:04 <sipa> wangchun: -maxmempool=10000 will give you a max 10G menpool
3612015-12-22T07:14:38 <sipa> wangchun: so set it to whatever amount of memory you can support; if it's still higher you'd go oit of memory anyway
3622015-12-22T07:14:55 <sipa> wangchun: anyway, feel free to ping here more if you have questions
3632015-12-22T07:21:25 <dcousens> sipa: with segwit, a rescan is only possible with all the witness data no?
3642015-12-22T07:24:55 *** raedah has quit IRC
3652015-12-22T07:30:05 *** Ylbam has joined #bitcoin-core-dev
3662015-12-22T07:41:08 <sipa> dcousens: no
3672015-12-22T07:41:26 <sipa> dcousens: i hadn't thought about that, but you can rescan without witnesses
3682015-12-22T07:49:12 *** Thireus has joined #bitcoin-core-dev
3692015-12-22T07:52:41 *** Madars has joined #bitcoin-core-dev
3702015-12-22T07:52:58 <dcousens> sipa: how so?
3712015-12-22T07:53:49 <sipa> dcousens: why do you need signatures?
3722015-12-22T07:54:09 <sipa> the amounts, addresses, consumed coins, locktime, ... are what matters to your wallet
3732015-12-22T07:54:17 <dcousens> sipa: I don't, but, I might need the output scripts, and if they are (not always, but maybe) in the seg wit data too
3742015-12-22T07:55:08 <sipa> dcousens: output scripts only matter for payments to yourself, and for those you know the full script anyway
3752015-12-22T07:55:24 <sipa> the witnesses are for inputs, not for outouts
3762015-12-22T07:55:33 <sipa> it's the same as p2sh
3772015-12-22T07:56:05 <dcousens> yeah, I guess I'd just watch for the sigwit hash that matched the P2PKH equivalent script
3782015-12-22T07:56:06 <sipa> you don't need to know the redeemscripts to analyse p2sh ouputs to your wallet either
3792015-12-22T07:56:09 <dcousens> nvm, ta
3802015-12-22T07:56:35 <sipa> not the equivalent; your wallet would know it gave out a segwit script, and explicitly look for that
3812015-12-22T07:56:49 <dcousens> sipa: a fresh import wouldn't know
3822015-12-22T07:57:14 *** d_t has quit IRC
3832015-12-22T07:57:34 *** d_t has joined #bitcoin-core-dev
3842015-12-22T07:58:28 <sipa> dcousens: why not? you'd need to import scripts just as with p2sh
3852015-12-22T07:58:32 <sipa> before import
3862015-12-22T08:00:55 <dcousens> sipa: not sure of how bitcoind handles it, but, conceptually, in regards to say watching a BIP32 tree, and trying to 'rediscover' it, you'd be able to track whats used based on a deterministic witsig scriptpubkey
3872015-12-22T08:01:30 <dcousens> per key
3882015-12-22T08:01:41 <dcousens> all good :), just like p2sh
3892015-12-22T08:12:33 *** xiangfu has quit IRC
3902015-12-22T08:12:50 *** xiangfu has joined #bitcoin-core-dev
3912015-12-22T08:20:31 *** Thireus has quit IRC
3922015-12-22T08:21:44 *** Thireus has joined #bitcoin-core-dev
3932015-12-22T08:29:34 *** Thireus1 has joined #bitcoin-core-dev
3942015-12-22T08:30:15 *** Thireus has quit IRC
3952015-12-22T08:30:43 *** Thireus1 has quit IRC
3962015-12-22T08:32:07 *** Thireus has joined #bitcoin-core-dev
3972015-12-22T08:41:34 *** arowser has quit IRC
3982015-12-22T08:41:56 *** arowser has joined #bitcoin-core-dev
3992015-12-22T08:50:42 *** JackH has joined #bitcoin-core-dev
4002015-12-22T08:54:36 *** p15_ has joined #bitcoin-core-dev
4012015-12-22T08:54:50 <GitHub25> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c24337964f2d...ed095f0407bd
4022015-12-22T08:54:50 <GitHub25> bitcoin/master 9b41a5f Suhas Daftuar: Add more tests to p2p-fullblocktest
4032015-12-22T08:54:50 <GitHub25> bitcoin/master ed095f0 Wladimir J. van der Laan: Merge pull request #7226...
4042015-12-22T08:54:56 <GitHub191> [bitcoin] laanwj closed pull request #7226: Tests: Add more tests to p2p-fullblocktest (master...add-more-tests) https://github.com/bitcoin/bitcoin/pull/7226
4052015-12-22T08:55:05 *** p15 has quit IRC
4062015-12-22T08:55:25 <GitHub133> [bitcoin] laanwj pushed 1 new commit to 0.12: https://github.com/bitcoin/bitcoin/commit/301f16ad1ca518c0873cd1bb99a26df36b46838b
4072015-12-22T08:55:25 <GitHub133> bitcoin/0.12 301f16a Suhas Daftuar: Add more tests to p2p-fullblocktest...
4082015-12-22T08:59:07 *** BashCo has joined #bitcoin-core-dev
4092015-12-22T08:59:46 *** MarcoFalke has joined #bitcoin-core-dev
4102015-12-22T09:00:01 <MarcoFalke> wumpus, 7242 is a loop. You can close it.
4112015-12-22T09:00:51 <MarcoFalke> It tries to merge .12 into master. Only running travis each time you commit
4122015-12-22T09:05:21 *** randy-waterhouse has quit IRC
4132015-12-22T09:07:28 *** BashCo has quit IRC
4142015-12-22T09:15:39 *** p15 has joined #bitcoin-core-dev
4152015-12-22T09:16:23 *** p15_ has quit IRC
4162015-12-22T09:27:52 <GitHub171> [bitcoin] laanwj closed pull request #7242: Master: Change the -keypool info text (master...0.12) https://github.com/bitcoin/bitcoin/pull/7242
4172015-12-22T09:29:19 *** BashCo has joined #bitcoin-core-dev
4182015-12-22T09:45:30 *** Thireus has quit IRC
4192015-12-22T09:46:40 *** Thireus has joined #bitcoin-core-dev
4202015-12-22T09:52:58 *** Tera2342 has quit IRC
4212015-12-22T09:56:04 *** Thireus has quit IRC
4222015-12-22T09:56:07 *** Thireus1 has joined #bitcoin-core-dev
4232015-12-22T10:00:34 *** Thireus1 has quit IRC
4242015-12-22T10:10:02 *** Thireus has joined #bitcoin-core-dev
4252015-12-22T10:10:23 <maaku> wumpus: what is the translation schedule for 0.12 ?
4262015-12-22T10:10:48 <wumpus> string freeze was dec 1, translations from transifex will be merged up until the last RC
4272015-12-22T10:12:30 <maaku> hrm ok. I'm on a project that could hugely benefit from #7192, shame if we have to wait until 0.13 for native translations :(
4282015-12-22T10:13:51 <wumpus> sorry for that
4292015-12-22T10:14:25 <maaku> yeah understandable
4302015-12-22T10:14:27 <wumpus> well it's only 6 months until 0.13 - that's the other side, the advantage of having hard deadlines
4312015-12-22T10:16:56 <wumpus> also: first RC for 0.12 is planned for start of 2016, so now changing so many original translation strings would give translators almost no time (and a shitty time, around christmas) to make native translations. Probably resulting in having no native translations for many of the new strings at all
4322015-12-22T10:17:58 <wumpus> it'd be possible though to include it for 0.12.1 (so backport 7192 after the 0.12 release)
4332015-12-22T10:18:41 <maaku> That would be nice.
4342015-12-22T10:20:18 *** Thireus has quit IRC
4352015-12-22T10:22:50 *** dcousens has quit IRC
4362015-12-22T10:32:32 <Luke-Jr> wumpus: the translation freeze can't be semi-relaxed for an algorithmic change, if I adjust them myself?
4372015-12-22T10:32:51 <Luke-Jr> I mean, I assume we're not using different package names within the translations..
4382015-12-22T10:33:42 <Luke-Jr> (that is, Bitcoin Kern is every place Bitcoin Core would otherwise have been)
4392015-12-22T10:34:47 <Luke-Jr> to be clear, what I'm suggesting means we wouldn't need to wait on translators to make the adjustment
4402015-12-22T10:36:04 <Luke-Jr> (I've done it before for the older stable branches)
4412015-12-22T10:37:39 <GitHub83> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/ed095f0407bd...595f93977c56
4422015-12-22T10:37:39 <GitHub83> bitcoin/master 37d271d mb300sd: Rename OP_NOP2 to OP_CHECKLOCKTIMEVERIFY.
4432015-12-22T10:37:40 <GitHub83> bitcoin/master 595f939 Wladimir J. van der Laan: Merge pull request #7213...
4442015-12-22T10:40:49 <maaku> Luke-Jr: I believe he means that the translators will have to update the translated strings
4452015-12-22T10:41:24 <maaku> unless you suggesting s/search/replace for each translation, which probably would work but should be approved by a native speaker...
4462015-12-22T10:42:47 <Luke-Jr> maaku: that's what I am suggesting, yes
4472015-12-22T10:43:02 <Luke-Jr> it shouldn't need approval from a native speaker, since it produces the same final strings..
4482015-12-22T10:44:05 <maaku> Luke-Jr: it is possible that the product name is translated differently in some languages based on context
4492015-12-22T10:44:20 <Luke-Jr> maaku: if so, then I would be unable to do the substitutions :p
4502015-12-22T10:44:47 <maaku> in which case the approach of 7192 would still work, but the translator would need to reword their translation to use a consistant grammar so the product name can remain the same
4512015-12-22T10:44:57 <maaku> no idea if this is actually the case though, and there's a good chance it isn't
4522015-12-22T10:45:48 <wumpus> Luke-Jr: that requires a feat of use of the transifex API above my knowledge at leest - and it's not a simple replace, remember that the name of the program has actually been translated in the native translations
4532015-12-22T10:45:52 <Luke-Jr> I can't really know without trying, and since trying takes some effort, I'd rather have someone "okay" the concept before I try
4542015-12-22T10:46:10 <Luke-Jr> wumpus: it's a replacement for each language
4552015-12-22T10:46:13 <wumpus> (and there's no guarantee of consistency there)
4562015-12-22T10:46:52 <Luke-Jr> wumpus: /if/ I can get the same output strings cleanly, are you okay with backporting it to 0.12?
4572015-12-22T10:47:14 <wumpus> imo there's just too little time left, at least I don't have a lot of time to spend on bitcoin the remainder oft this year
4582015-12-22T10:47:40 <Luke-Jr> and if I don't make it in time, we just go ahead without it?
4592015-12-22T10:47:46 *** tripleslash_h has quit IRC
4602015-12-22T10:48:13 *** tripleslash has joined #bitcoin-core-dev
4612015-12-22T10:48:24 <MarcoFalke> Wouldn't 0.12.1 be enough for that?
4622015-12-22T10:48:29 <wumpus> but given that you can patch the appropriate messgaes correctly on every translation on transifex (e.g. using the API) I'm not against it
4632015-12-22T10:48:35 <Luke-Jr> actually, I keep forgetting I need to do it regardless. so I'll just PR it when it's ready, and if that means it doesn't get merged until 0.12.1, so be it
4642015-12-22T10:48:38 <wumpus> MarcoFalke: yeah that's what I said
4652015-12-22T10:49:13 <wumpus> <wumpus> it'd be possible though to include it for 0.12.1 (so backport 7192 after the 0.12 release) <- I think we should stick to that
4662015-12-22T10:51:14 <wumpus> "<maaku> Luke-Jr: it is possible that the product name is translated differently in some languages based on context" hah yes - that's what I'm afraid of too, it's also one of the reasons this pull is a great idea, at least the product name will be the same everywhere in the program
4672015-12-22T10:51:59 <wumpus> (unless there are languages where it *has* to be translated differently based on the context for correctness... hmm)
4682015-12-22T10:52:29 <Luke-Jr> if that were the case, I think we'd already have problems in other areas
4692015-12-22T10:52:33 <maaku> right but a competent translator should be able to account for that to make it uniform everywhere
4702015-12-22T10:52:53 <Luke-Jr> anyhow, I'll try it and we'll see what I find.
4712015-12-22T10:52:55 <wumpus> maaku: yes that makes sense
4722015-12-22T10:53:11 <wumpus> (though that's another argument gainst doing this bot-wise)
4732015-12-22T10:55:17 <Luke-Jr> MarcoFalke: btw, re copyright display, note we've changed it from Bitcoin developers to Bitcoin Core developers already once :P
4742015-12-22T10:55:42 <wumpus> yes, it's supposed to be Bitcoin Core developers - was it changed back somehow?
4752015-12-22T10:56:38 <maaku> I think he meant to highlight me -- I was pointed out that e.g. if I use this patch to change Bitcoin Core -> Liquid, the Liquid documentation would say "Copyright 2009-2015 The Liquid Developers" which is wrong in at least two ways
4762015-12-22T10:56:41 <Luke-Jr> wumpus: no, he's complaining that PACKAGE_NAME gets substituted in the rendered places
4772015-12-22T10:57:14 <Luke-Jr> maaku: well, just the About dialogue; doing it in docs isn't practical
4782015-12-22T10:57:41 <Luke-Jr> maaku: how is it wrong?
4792015-12-22T10:57:48 <MarcoFalke> Luke-Jr, not everyone preserves git history and the binaries are often distributed without the source code, so there'd be no way to find out if "MF core developers" actually include the bitcoin core developers as well
4802015-12-22T10:58:06 <Luke-Jr> MarcoFalke: how is this a problem?
4812015-12-22T10:58:39 <wumpus> I understand MarcoFalke's issue - automatically updating copyrights can be a bit thorny
4822015-12-22T10:58:52 <MarcoFalke> Implying "MF" is the author of something he is not actually the author of.
4832015-12-22T10:59:02 <wumpus> it makes it easy to steal credit
4842015-12-22T10:59:08 <Luke-Jr> it doesn't imply that, though..
4852015-12-22T10:59:15 <maaku> Luke-Jr: (1) changing copyright from Bitcoin Core -> Liquid; (2) Should be Blockstream in this context anyway --- "Copyright 2009-2016 The Bitcoin Core Developers; Copyright 2015-2016 Blockstream"
4862015-12-22T10:59:42 <wumpus> so maybe leave the copyright alone
4872015-12-22T10:59:47 <wumpus> leave it up to a project to set that
4882015-12-22T10:59:50 <Luke-Jr> maaku: from Bitcoin Core *developers* -> Liquid *developers*
4892015-12-22T11:00:01 <Luke-Jr> neither is a legal entity
4902015-12-22T11:00:04 <wumpus> it doesn't matter if theres one more place to update it
4912015-12-22T11:00:07 <maaku> Luke-Jr: ok i suppose that is not strictly speaking wrong
4922015-12-22T11:00:21 <maaku> anyway yeah the copyright string probably shouldn't be changed
4932015-12-22T11:01:04 <wumpus> having it automatically substituted only makes sense for Bitcoin Core, derivative projects likely want to extend it instead
4942015-12-22T11:01:29 <MarcoFalke> Luke-Jr, it implies that, imo. Imagine MF Core is some fancy bitcoin app with the whole gui changed but running bitcoin core in the background. The only copyright notice says "(c) MF core developers". This clearly implies MF core developers are the only authors of the app.
4952015-12-22T11:01:39 <MarcoFalke> Right, it should be extended
4962015-12-22T11:01:55 <Luke-Jr> hm
4972015-12-22T11:01:57 <MarcoFalke> I think I saw some altcoins doing this correctly
4982015-12-22T11:02:04 <Luke-Jr> maybe a separate variable?
4992015-12-22T11:02:14 <wumpus> yes make the copyright separate
5002015-12-22T11:02:48 <wumpus> it's a good point
5012015-12-22T11:03:30 <wumpus> if we had done this naively, the altcoins doing it correctly would probably have been the ones reverting to doing it wrongly
5022015-12-22T11:06:31 <Luke-Jr> hrm, this is not trivial to do without breaking the translatability of this
5032015-12-22T11:06:41 <wumpus> maybe just skip it for now
5042015-12-22T11:06:47 <wumpus> leave the copyright as it
5052015-12-22T11:07:23 <wumpus> could do it later, or not, you don't have to iron out all the issues in one pull
5062015-12-22T11:09:38 <wumpus> but why is it so hard? e.g. make a function GetCopyright() { return _("Copyright 2009-2016 blabla developers"); }
5072015-12-22T11:10:09 <wumpus> use that in the two(?) places where you need it
5082015-12-22T11:10:20 <Luke-Jr> four, but that's more or less the approach I'm using
5092015-12-22T11:10:36 <Luke-Jr> difficulty is one of them is inside a plist
5102015-12-22T11:10:44 <maaku> Luke-Jr: add a %s at the end of the copyright which is the empty string
5112015-12-22T11:10:59 <Luke-Jr> maaku: O.o?
5122015-12-22T11:11:00 <wumpus> well the plist is another issue
5132015-12-22T11:11:05 <wumpus> imo you should leave that for another pull too
5142015-12-22T11:11:13 <maaku> and agree with ^
5152015-12-22T11:11:15 *** Tera2342 has joined #bitcoin-core-dev
5162015-12-22T11:11:29 <wumpus> just mae your pull what it promises to do - unify the product name where it's *easy to do*
5172015-12-22T11:11:32 <maaku> this is fixable, but for now just don't substitute "Bitcoin Core" in the copyright string
5182015-12-22T11:11:40 <wumpus> maaku: exactly
5192015-12-22T11:12:09 <MarcoFalke> Agree, we can leave that for now
5202015-12-22T11:12:20 <Luke-Jr> wumpus: easy to do was part of the first commit; the rest does very non-easy things :P
5212015-12-22T11:12:39 <Luke-Jr> what does strprintf do if there's more params than fields?
5222015-12-22T11:17:40 *** MarcoFalke has quit IRC
5232015-12-22T11:18:19 *** MarcoFalke has joined #bitcoin-core-dev
5242015-12-22T11:23:42 *** xiangfu has quit IRC
5252015-12-22T11:24:00 *** xiangfu has joined #bitcoin-core-dev
5262015-12-22T11:29:25 <wumpus> Luke-Jr: raise an exception
5272015-12-22T11:30:09 <Luke-Jr> thx
5282015-12-22T11:30:25 <wumpus> the script to fetch translations therefore checks if the % interpolations match in the translation and original string before accepting a line
5292015-12-22T12:01:10 <warren> wumpus: I suggested parameterizing the name "Bitcoin" everywhere in part to make the overall delta of a sidechain fork far smaller.
5302015-12-22T12:02:51 <warren> maaku: FWIW, Litecoin added a second copyright instead of renaming "Bitcoin developers" as renaming would be disrespectful and probably a copyright violation.
5312015-12-22T12:03:11 <maaku> Freicoin did the same
5322015-12-22T12:03:30 <maaku> but my point was that the above PR would have automatically done the copyright violating rename
5332015-12-22T12:05:28 <Luke-Jr> warren: how a copyright violation?
5342015-12-22T12:05:46 <Luke-Jr> jonasschnelli points out on the PR, that we do not independently list LevelDB etc
5352015-12-22T12:07:38 <maaku> I don't think it is a violation under MIT
5362015-12-22T12:07:46 <maaku> legally, ethically yes
5372015-12-22T12:07:51 <jonasschnelli> Right... I think the source codes copyrights are the "important ones", ... the distribution package copyright informations are different. Check the app stores (iOS/Android).
5382015-12-22T12:07:54 <MarcoFalke> Luke-Jr, I think it's called copyfraud in english
5392015-12-22T12:08:54 <jonasschnelli> It would definitively be unethically (copy the source, rename and change the copyright).
5402015-12-22T12:08:55 <maaku> anyway I think the proposed plan is good -- hard-code "The Bitcoin Core Developers" in #7192, and then later PR a bike-sheddable extended copyright notice for non-Bitcoin Core implementations
5412015-12-22T12:09:24 <jonasschnelli> And Luke-Jr does not change the string itself,... it makes it just more "accessible"
5422015-12-22T12:09:30 <jonasschnelli> *Luke-Jr s'PR
5432015-12-22T12:09:42 <warren> Can we go further and parameterize all variations of the word Bitcoin in various strings that are currently translated?
5442015-12-22T12:09:46 <Luke-Jr> maaku: but that leaves the problem unsolved
5452015-12-22T12:09:54 <jonasschnelli> ;-)
5462015-12-22T12:09:58 <Luke-Jr> warren: -.-
5472015-12-22T12:10:16 <warren> Luke-Jr: to make it easier for sidechains and ... XT to rebase =)
5482015-12-22T12:10:23 <maaku> warren: I believe this PR does just that
5492015-12-22T12:10:49 <maaku> my experience is that there are a few spots you don't want to search-replace however, such as references to the Bitcoin Wiki
5502015-12-22T12:11:09 <Luke-Jr> warren: sidechains are Bitcoin
5512015-12-22T12:11:14 <maaku> and there's still a few places that need to be parameterized, like bitcoind/bitcoin-cli in the RPC help text
5522015-12-22T12:11:25 <MarcoFalke> warren, I think this can be another PR if really desired?
5532015-12-22T12:12:43 <Luke-Jr> I don't think we need to spend time making altcoins easier :p
5542015-12-22T12:12:52 <jonasschnelli> maaku: i think Luke-Jr's PR does not change the binary names itself (like bitcoin-cli stays bitcoin-cli)
5552015-12-22T12:13:29 <warren> Luke-Jr: good point
5562015-12-22T12:13:44 <Luke-Jr> the goal here is to make it easier to rename and/or fork Core, but within the scope of Bitcoin
5572015-12-22T12:14:14 <Quent> sorry to barge in, but was just wondering whether there is any documentation on the algorithmic optimisations to libsec?
5582015-12-22T12:14:35 <Luke-Jr> Quent: I would expect to find it in source code comments
5592015-12-22T12:14:54 <Luke-Jr> you might try asking in #secp256k1 also
5602015-12-22T12:15:25 <Quent> there is no documentation of the maths etc used in libsec save for the code itself?
5612015-12-22T12:16:19 <jonasschnelli> Quent: all written here: https://github.com/bitcoin/secp256k1#implementation-details ?
5622015-12-22T12:16:53 <jonasschnelli> If you compile it with openssl, you can also run a benchmark IIRC
5632015-12-22T12:18:02 <maaku> Luke-Jr: we're in an era where multiple forks of bitcoind exist, and indeed are encouraged (outside of consensus code), and sidechains are moving into production
5642015-12-22T12:18:30 <maaku> I would also question the "but that makes altcoins easier!" argument -- who cares? -- but I know that would fall on deaf ears
5652015-12-22T12:19:06 <Luke-Jr> maaku: I see no use case in parameterising "bitcoins" for forks/sidechains, only altcoins.
5662015-12-22T12:20:39 <btcdrak> seems like much of this conversation belongs in #bitcoin-dev
5672015-12-22T12:22:00 <warren> MarcoFalke: re "Bump copyright headers to 2015" counsel at Red Hat advised us that it's most proper to have a comma separated list of years instead of a range, worst is replacing it with only the most recent year.
5682015-12-22T12:22:37 <warren> In practice the notice doesn't matter all that much and this is fine, just commenting what was practice at a major open source engineering firm.
5692015-12-22T12:23:42 <warren> ... and I think we violated that advice a lot and it didn't matter.
5702015-12-22T12:26:20 <Luke-Jr> indeed, the notice only matters insofar as it indicates intent
5712015-12-22T12:30:19 *** _Sam-- has joined #bitcoin-core-dev
5722015-12-22T12:30:20 *** _Sam-- has joined #bitcoin-core-dev
5732015-12-22T12:33:46 <MarcoFalke> warren, you are right, indeed. The old helper script replaced the copyright year which is wrong. I fixed it to extend the range.
5742015-12-22T12:34:26 <Luke-Jr> How's this look? https://github.com/luke-jr/bitcoin/commit/917b1d03cf3afa6939113e2fb0bf89dbfd9db2d7
5752015-12-22T12:34:44 <MarcoFalke> If people want a comma separated list, I am fine with that, too. Should I go this way?
5762015-12-22T12:35:04 <Luke-Jr> MarcoFalke: that is likely to complicate the code annoyingly. not worth it IMO
5772015-12-22T12:35:31 <MarcoFalke> Agree. And it wastes time to go through the diff.
5782015-12-22T12:35:52 <MarcoFalke> (in the PR which changes the syntax, that is)
5792015-12-22T12:43:19 <jonasschnelli> Luke-Jr: mac build fails again: "ImportError: No module named ez_setup"
5802015-12-22T12:43:22 <jonasschnelli> https://bitcoin.jonasschnelli.ch/pulls/7192/build-osx.log
5812015-12-22T12:46:06 <morcos> wangchun: Not sure if this is related to the issue you were describing, but very recently a fix to the way PrioritiseTransaction works was merged: https://github.com/bitcoin/bitcoin/pull/7062
5822015-12-22T12:47:39 <morcos> The theory is you should only have to prioritise each transaction once and then it should remain prioritized in your mempool. Eviction will consider its new modified fee and sorting for block inclusion will consider its new modified fee for each new CreateNewBlock. But you should apply a deltaFee not a deltaPriority.
5832015-12-22T12:49:15 *** Thireus has joined #bitcoin-core-dev
5842015-12-22T12:49:34 *** afk11 has quit IRC
5852015-12-22T12:56:43 <wumpus> <maaku> I would also question the "but that makes altcoins easier!" argument -- who cares? -- but I know that would fall on deaf ears <- yes, who cares, I'd rather have people that disagree on fundamental properties of bitcoin working on altcoins than staying around here to troll
5862015-12-22T12:58:14 <wumpus> and unifying repeated strings simply makes sense when it helps enforcing consistency
5872015-12-22T12:59:25 <wumpus> I also don't care about comma separated list versus range - range is a fine simplification IMO, the exact time and date of every change can be found in git if that's necessary for legal purposes
5882015-12-22T13:01:08 <MarcoFalke> I think comma vs range is not a legal issue. (Range sometimes includes more years than necessary, but you can't claim copyright for something that isn't there in the first place...)
5892015-12-22T13:02:28 <jonasschnelli> What about merging https://github.com/bitcoin/bitcoin/pull/7153?
5902015-12-22T13:03:09 <jonasschnelli> It ensures the 0.12 mempool limiting behavior.
5912015-12-22T13:03:58 <wumpus> jonasschnelli: oh, seems I forgot about that one, soryr
5922015-12-22T13:04:04 <jonasschnelli> np
5932015-12-22T13:04:09 <MarcoFalke> Looks good to merge. Isn't there other rpc test testing mempool stuff?
5942015-12-22T13:04:38 <MarcoFalke> Or is this the first one to test mempool limiting?
5952015-12-22T13:04:42 <wumpus> adding tests for new behavior is good
5962015-12-22T13:05:03 <wumpus> I think so? there are other tests that test basic mempool functionality like accepting transactions, but none about limiting IIRC
5972015-12-22T13:05:22 <MarcoFalke> Great, then let's merge!
5982015-12-22T13:06:02 <GitHub139> [bitcoin] jonasschnelli pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/595f93977c56...a1c185be546b
5992015-12-22T13:06:03 <GitHub139> bitcoin/master fa8c8d7 MarcoFalke: torcontrol debug: Change to a blanket message that covers both cases
6002015-12-22T13:06:03 <GitHub139> bitcoin/master fa5769e MarcoFalke: [qt] Fix misleading translation
6012015-12-22T13:06:04 <GitHub29> [bitcoin] jonasschnelli closed pull request #7218: [qt] Fix misleading translation (master...MarcoFalke-2015-trivial7) https://github.com/bitcoin/bitcoin/pull/7218
6022015-12-22T13:06:04 <GitHub139> bitcoin/master a1c185b Jonas Schnelli: Merge pull request #7218...
6032015-12-22T13:07:11 <GitHub198> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/a1c185be546b...97d83739db06
6042015-12-22T13:07:13 <GitHub198> bitcoin/master 110ff11 Jonas Schnelli: [Tests] Add mempool_limit.py test
6052015-12-22T13:07:13 <GitHub198> bitcoin/master 7632cf6 Jonas Schnelli: [Tests] Refactor some shared functions
6062015-12-22T13:07:14 <GitHub198> bitcoin/master 97d8373 Wladimir J. van der Laan: Merge pull request #7153...
6072015-12-22T13:07:22 <GitHub55> [bitcoin] laanwj closed pull request #7153: [Tests] Add mempool_limit.py test (master...2015/12/mempool-test) https://github.com/bitcoin/bitcoin/pull/7153
6082015-12-22T13:15:18 *** Thireus1 has joined #bitcoin-core-dev
6092015-12-22T13:15:19 *** Thireus has quit IRC
6102015-12-22T13:15:55 *** Cory has quit IRC
6112015-12-22T13:17:57 *** afk11 has joined #bitcoin-core-dev
6122015-12-22T13:18:37 *** xiangfu has quit IRC
6132015-12-22T13:18:53 *** Cory has joined #bitcoin-core-dev
6142015-12-22T13:20:28 <MarcoFalke> jonasschnelli I think it's still the same font on Linux and Windows? You'd need to compare with old screenshots.
6152015-12-22T13:21:07 <jonasschnelli> I compared against master. It's the same font size... but on windows, it feels really small (as said, not related to your PR).
6162015-12-22T13:21:54 <MarcoFalke> Ok, good to hear it didn't make things worse. :)
6172015-12-22T13:23:15 *** MarcoFalke has quit IRC
6182015-12-22T13:31:46 *** arubi has quit IRC
6192015-12-22T13:32:38 *** p15 has quit IRC
6202015-12-22T13:35:38 <Luke-Jr> jonasschnelli: fixed gitian issue
6212015-12-22T14:02:06 <jonasschnelli> Okay. Recompiling...
6222015-12-22T14:10:41 *** afk11 has quit IRC
6232015-12-22T14:24:39 *** laurentmt has joined #bitcoin-core-dev
6242015-12-22T14:25:17 *** laurentmt has quit IRC
6252015-12-22T14:59:08 *** Tera2342 has quit IRC
6262015-12-22T15:00:16 *** Tera2342 has joined #bitcoin-core-dev
6272015-12-22T15:08:46 *** Tera2342 has quit IRC
6282015-12-22T15:33:30 <jonasschnelli> Luke-Jr: works now. Took >50mins to build... any idea why? Did it somehow invalidate the dependency cache?
6292015-12-22T15:46:41 <GitHub121> [bitcoin] laanwj pushed 2 new commits to 0.12: https://github.com/bitcoin/bitcoin/compare/301f16ad1ca5...453c56701a14
6302015-12-22T15:46:41 <GitHub121> bitcoin/0.12 9ef7c54 Jonas Schnelli: [Tests] Add mempool_limit.py test...
6312015-12-22T15:46:42 <GitHub121> bitcoin/0.12 453c567 Wladimir J. van der Laan: tests: Disable Tor interaction...
6322015-12-22T15:46:51 *** MarcoFalke has joined #bitcoin-core-dev
6332015-12-22T15:51:19 *** adam3us has quit IRC
6342015-12-22T15:53:48 *** MarcoFalke has quit IRC
6352015-12-22T15:58:31 <Luke-Jr> jonasschnelli: it shouldn't have, but you wouldn't have gotten that error if your cache was working..
6362015-12-22T16:01:09 *** adam3us has joined #bitcoin-core-dev
6372015-12-22T16:03:05 *** laurentmt has joined #bitcoin-core-dev
6382015-12-22T16:03:15 *** laurentmt has quit IRC
6392015-12-22T16:21:22 *** arowser has quit IRC
6402015-12-22T16:21:49 *** arowser has joined #bitcoin-core-dev
6412015-12-22T16:27:55 *** afk11 has joined #bitcoin-core-dev
6422015-12-22T16:35:56 *** calibre720 has joined #bitcoin-core-dev
6432015-12-22T16:54:53 *** zookolaptop has joined #bitcoin-core-dev
6442015-12-22T17:10:59 *** afk11 has quit IRC
6452015-12-22T17:22:49 *** desantis has joined #bitcoin-core-dev
6462015-12-22T17:39:06 <jonasschnelli> Okay. Thanks. Maybe my build system was under heavy load...
6472015-12-22T17:40:33 *** zookolaptop is now known as zooko
6482015-12-22T18:05:12 *** BashCo has quit IRC
6492015-12-22T18:06:00 *** laurentmt has joined #bitcoin-core-dev
6502015-12-22T18:06:15 *** laurentmt has quit IRC
6512015-12-22T18:08:59 *** arubi has joined #bitcoin-core-dev
6522015-12-22T18:13:07 *** paveljanik has joined #bitcoin-core-dev
6532015-12-22T18:27:27 *** BashCo has joined #bitcoin-core-dev
6542015-12-22T18:34:28 *** brg444 has joined #bitcoin-core-dev
6552015-12-22T18:34:28 *** davec has quit IRC
6562015-12-22T18:34:59 *** davec has joined #bitcoin-core-dev
6572015-12-22T18:45:11 *** alpalp has joined #bitcoin-core-dev
6582015-12-22T18:51:47 *** alpalp has quit IRC
6592015-12-22T18:56:19 *** alpalp has joined #bitcoin-core-dev
6602015-12-22T18:59:43 *** amiller has quit IRC
6612015-12-22T19:03:05 *** Guest71119 has joined #bitcoin-core-dev
6622015-12-22T19:07:37 *** desantis has quit IRC
6632015-12-22T19:10:28 *** desantis has joined #bitcoin-core-dev
6642015-12-22T19:24:16 *** adam3us has quit IRC
6652015-12-22T19:24:24 *** adam3us has joined #bitcoin-core-dev
6662015-12-22T19:42:47 *** raedah has joined #bitcoin-core-dev
6672015-12-22T20:03:35 *** Quent has left #bitcoin-core-dev
6682015-12-22T20:07:46 *** JackH has quit IRC
6692015-12-22T20:20:42 *** randy-waterhouse has joined #bitcoin-core-dev
6702015-12-22T20:27:42 *** calibre720 has quit IRC
6712015-12-22T20:41:15 *** dgenr8 has quit IRC
6722015-12-22T20:46:12 *** dgenr8 has joined #bitcoin-core-dev
6732015-12-22T20:50:34 *** dgenr8 has quit IRC
6742015-12-22T20:53:35 *** Cory has quit IRC
6752015-12-22T20:56:30 *** Cory has joined #bitcoin-core-dev
6762015-12-22T21:02:18 *** raedah_ has joined #bitcoin-core-dev
6772015-12-22T21:02:26 *** raedah has quit IRC
6782015-12-22T21:12:43 *** BashCo_ has joined #bitcoin-core-dev
6792015-12-22T21:14:52 *** BashCo has quit IRC
6802015-12-22T21:14:55 *** arubi_ has joined #bitcoin-core-dev
6812015-12-22T21:15:13 *** arubi has quit IRC
6822015-12-22T21:15:15 *** arubi_ is now known as arubi
6832015-12-22T21:27:30 *** randy-waterhouse has quit IRC
6842015-12-22T21:27:55 *** raedah_ has quit IRC
6852015-12-22T21:41:29 *** raedah_ has joined #bitcoin-core-dev
6862015-12-22T21:51:17 *** paveljanik has quit IRC
6872015-12-22T22:08:13 *** Thireus has joined #bitcoin-core-dev
6882015-12-22T22:10:06 *** Thireus has quit IRC
6892015-12-22T22:10:09 *** Thireus2 has joined #bitcoin-core-dev
6902015-12-22T22:10:32 *** Thireus1 has quit IRC
6912015-12-22T22:10:58 *** Thireus has joined #bitcoin-core-dev
6922015-12-22T22:11:14 *** Thireus2 has quit IRC
6932015-12-22T22:19:53 *** Thireus has quit IRC
6942015-12-22T22:47:47 *** alpalp has quit IRC
6952015-12-22T22:49:16 *** Ylbam has quit IRC
6962015-12-22T22:49:28 *** jl2012 has quit IRC
6972015-12-22T22:54:40 *** Guyver2 has quit IRC
6982015-12-22T22:55:45 *** laurentmt has joined #bitcoin-core-dev
6992015-12-22T22:55:54 *** laurentmt has quit IRC
7002015-12-22T23:01:55 *** Madars has quit IRC
7012015-12-22T23:10:09 *** jl2012 has joined #bitcoin-core-dev
7022015-12-22T23:15:02 *** raedah_ has quit IRC
7032015-12-22T23:15:06 *** x___ has joined #bitcoin-core-dev
7042015-12-22T23:20:45 *** Ylbam has joined #bitcoin-core-dev
7052015-12-22T23:21:08 *** desantis has quit IRC
7062015-12-22T23:24:50 *** x___ has quit IRC
7072015-12-22T23:26:04 *** Tera2342 has joined #bitcoin-core-dev
7082015-12-22T23:44:51 *** JackH has joined #bitcoin-core-dev
7092015-12-22T23:46:55 <wangchun> morcos: I'll try prioritisetransaction, thx
7102015-12-22T23:48:05 <phantomcircuit> wangchun, trying to get things into your mempool which are otherwise rejected because of minrelay fee?
7112015-12-22T23:48:16 <wangchun> phantomcircuit: yes
7122015-12-22T23:49:35 <sipa> i think if you first call prioritizetransaction, and then submit it, it will be accepted
7132015-12-22T23:49:44 <wangchun> as blocks are not very full these days, we would like to confirm some free tx
7142015-12-22T23:49:52 <phantomcircuit> wangchun, should work, looks like that rpc command calls CTxMempool::PrioritiseTransaction which doesn't check if the transaction is already in the mempool or not
7152015-12-22T23:51:09 <phantomcircuit> wangchun, how are you selecting which free transactions to include?
7162015-12-22T23:51:38 <wangchun> sort by prioirity of course
7172015-12-22T23:51:45 <wangchun> priority
7182015-12-22T23:52:22 <phantomcircuit> wangchun, yeah then using the rpc command and prioritizetransaction is the best way to do that