1 2015-12-22T00:03:58  *** Tera2342 has quit IRC
  2 2015-12-22T00:04:31  *** Tera2342 has joined #bitcoin-core-dev
  3 2015-12-22T00:09:09  *** JackH has joined #bitcoin-core-dev
  4 2015-12-22T00:19:04  *** brg444 has quit IRC
  5 2015-12-22T00:19:45  *** brg444 has joined #bitcoin-core-dev
  6 2015-12-22T00:39:23  *** Madars has joined #bitcoin-core-dev
  7 2015-12-22T00:40:21  *** Tera2342 has quit IRC
  8 2015-12-22T00:44:55  *** brg444 has quit IRC
  9 2015-12-22T00:49:45  *** Tera2342 has joined #bitcoin-core-dev
 10 2015-12-22T00:51:27  *** JackH has quit IRC
 11 2015-12-22T00:55:42  <Luke-Jr> cfields: yeah, but I'm not finding any practical way to do that.
 12 2015-12-22T00:56:04  <cfields> Luke-Jr: worked fine in my local test..
 13 2015-12-22T00:56:19  <cfields> PYTHONPATH=$(PYTHONPATH) python foo
 14 2015-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..
 15 2015-12-22T00:57:42  <cfields> Luke-Jr: yes, so make sure it's invoked like that any time python is used
 16 2015-12-22T00:58:03  <cfields> or more easily, just export it from the makefile
 17 2015-12-22T00:58:20  <Luke-Jr> is that portable? and would we need to do it in every makefile?
 18 2015-12-22T00:58:49  <cfields> should be portable, yes. no, all makefiles are included from the top one
 19 2015-12-22T00:59:00  <cfields> well, all in src/ anyway
 20 2015-12-22T00:59:24  *** jrmithdobbs has joined #bitcoin-core-dev
 21 2015-12-22T00:59:46  <jrmithdobbs> i'm sorry, that was poorly executed. That is all.
 22 2015-12-22T01:00:05  <jrmithdobbs> my bad.
 23 2015-12-22T01:01:06  *** jrmithdobbs has quit IRC
 24 2015-12-22T01:01:11  *** jtimon has joined #bitcoin-core-dev
 25 2015-12-22T01:07:02  *** Madars has quit IRC
 26 2015-12-22T01:11:11  *** jcorgan|away is now known as jcorgan
 27 2015-12-22T01:30:18  *** brg444 has joined #bitcoin-core-dev
 28 2015-12-22T01:31:15  *** zookolaptop has quit IRC
 29 2015-12-22T01:34:48  *** dcousens has joined #bitcoin-core-dev
 30 2015-12-22T01:36:54  *** jl2012 has quit IRC
 31 2015-12-22T01:38:00  *** Ylbam has quit IRC
 32 2015-12-22T01:38:23  *** jl2012 has joined #bitcoin-core-dev
 33 2015-12-22T01:39:19  *** Ylbam has joined #bitcoin-core-dev
 34 2015-12-22T01:54:32  *** Ylbam has quit IRC
 35 2015-12-22T01:59:43  *** brg444 has quit IRC
 36 2015-12-22T02:00:18  *** dermoth has quit IRC
 37 2015-12-22T02:00:56  *** dermoth has joined #bitcoin-core-dev
 38 2015-12-22T02:02:49  *** blade has joined #bitcoin-core-dev
 39 2015-12-22T02:03:23  *** PaulCapestany has quit IRC
 40 2015-12-22T02:04:58  <blade> my transactions are not being confirmed whats going on
 41 2015-12-22T02:04:59  *** PaulCapestany has joined #bitcoin-core-dev
 42 2015-12-22T02:05:29  <blade> its been over an hour
 43 2015-12-22T02:06:33  <blade> im useig the bitcoin core wallet
 44 2015-12-22T02:07:02  <jcorgan> blade: this is not the correct channel for this, please go to #bitcoin
 45 2015-12-22T02:07:11  <blade> ok ty
 46 2015-12-22T02:08:08  *** blade has left #bitcoin-core-dev
 47 2015-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
 48 2015-12-22T02:18:51  *** Yoghur114_2 has quit IRC
 49 2015-12-22T02:29:05  *** BashCo_ has quit IRC
 50 2015-12-22T02:31:52  *** dhuff has joined #bitcoin-core-dev
 51 2015-12-22T02:34:04  *** dhuff is now known as jrmithdobbs
 52 2015-12-22T02:41:08  *** Madars has joined #bitcoin-core-dev
 53 2015-12-22T02:44:06  *** Tera2342 has quit IRC
 54 2015-12-22T02:47:50  *** raedah has quit IRC
 55 2015-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.
 56 2015-12-22T02:51:02  *** jrmithdobbs has quit IRC
 57 2015-12-22T02:53:05  *** xiangfu has joined #bitcoin-core-dev
 58 2015-12-22T03:06:07  *** Madars has quit IRC
 59 2015-12-22T03:30:40  *** xiangfu has quit IRC
 60 2015-12-22T03:30:41  <dcousens> jtimon: that came out wrong
 61 2015-12-22T03:30:58  <dcousens> I meant, that is certainly the dream, but, I don't think its where bitcoin/bitcoin is headed
 62 2015-12-22T03:31:31  <dcousens> At least, that opinion is based on the last time I spoke about it
 63 2015-12-22T03:33:02  <jtimon> dcousens: it is certainly where Bitcoin JT is headed :p
 64 2015-12-22T03:33:12  <dcousens> jtimon: haha
 65 2015-12-22T03:33:29  <dcousens> Just realised as I re-read my comment, that it might have come across as "your dreaming buddy"
 66 2015-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"
 67 2015-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"
 68 2015-12-22T03:35:08  <jtimon> I literally mean just replacing the ints with strings for now
 69 2015-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
 70 2015-12-22T03:38:01  *** xiangfu has joined #bitcoin-core-dev
 71 2015-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?
 72 2015-12-22T03:38:47  <dcousens> I think people will certainly look to that PR for a simple patch set
 73 2015-12-22T03:41:36  <jtimon> yeah, I will just do free a back-and-forward-port service of the PR with my nits squashed
 74 2015-12-22T03:54:59  *** Madars has joined #bitcoin-core-dev
 75 2015-12-22T03:55:38  <midnightmagic> jtimon: You mean with full-RBF as an option?
 76 2015-12-22T03:56:35  <jtimon> both fullrbf and firstseen, just like the PR (and then, hopefully more)
 77 2015-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
 78 2015-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
 79 2015-12-22T03:59:37  *** p15 has joined #bitcoin-core-dev
 80 2015-12-22T04:10:44  <jtimon> Luke-Jr: didn't pblocktemplate->vTxSigOps[0] used to count p2sh sigops too ?
 81 2015-12-22T04:10:55  <Luke-Jr> jtimon: yes, it's supposed to
 82 2015-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?
 83 2015-12-22T04:12:15  <morcos> jtimon: it still does or there is a bug
 84 2015-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
 85 2015-12-22T04:15:20  <morcos> oh [0], i missed that. i don't think i changed that line.
 86 2015-12-22T04:15:42  <jtimon> in last-0.12.99 3cd836c1 I see pblocktemplate->vTxSigOps[0] = GetLegacySigOpCount(pblock->vtx[0]);
 87 2015-12-22T04:16:00  <morcos> yeah, i think thats what its like in 0.11 too
 88 2015-12-22T04:16:29  <morcos> yep
 89 2015-12-22T04:16:46  *** Madars has quit IRC
 90 2015-12-22T04:17:43  <jtimon> yeah, that's not changed in 553cad94
 91 2015-12-22T04:18:24  <jtimon> Luke-Jr: is it supposed to count p2sh sigops or not?
 92 2015-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
 93 2015-12-22T04:18:29  <Luke-Jr> jtimon: yes
 94 2015-12-22T04:18:53  <Luke-Jr> it's supposed to be everything to total to the sigoplimit
 95 2015-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
 96 2015-12-22T04:25:08  <jtimon> oh that's only for the coinbase, never mind
 97 2015-12-22T04:25:51  <jtimon> sorry, metal furt
 98 2015-12-22T04:25:57  <jtimon> mental
 99 2015-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
100 2015-12-22T04:46:17  <Luke-Jr> note the current status quo is not merely "disabled by default", because the new implementation is still buggy
101 2015-12-22T04:46:51  <Luke-Jr> (status quo in master, I mean, not the network)
102 2015-12-22T04:49:45  <jtimon> I'm mostly interested in your opinion on last-0.12.99 3cd836c1
103 2015-12-22T04:50:41  <jtimon> Luke-Jr: ie what you think that needs to be solved for 0.12
104 2015-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
105 2015-12-22T04:52:16  * Luke-Jr looks over PR list to make sure he didn't miss anything too important
106 2015-12-22T04:52:53  <Luke-Jr> bytespersigop may be a good idea, and is tagged for 0.12
107 2015-12-22T04:53:04  <Luke-Jr> but technically not a fix
108 2015-12-22T04:58:55  <jtimon> oh, you expect the optional fullrbf to be backported to 0.12 ?
109 2015-12-22T04:59:27  <jtimon> I mean, I wouldn't oppose
110 2015-12-22T04:59:47  <Luke-Jr> yes, that was something many people expected to be part of the original PR..
111 2015-12-22T05:00:09  *** dermoth has quit IRC
112 2015-12-22T05:00:36  <Luke-Jr> I consider it a bug that it's not configurable right now.
113 2015-12-22T05:01:22  <jtimon> well, I consider it it cheap-to-maintain missing functionality, but we agree overall
114 2015-12-22T05:01:42  <Luke-Jr> 7217 and 7213 also stand out as bugfixes that perhaps ought to get into 0.12
115 2015-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
116 2015-12-22T05:02:47  *** dermoth has joined #bitcoin-core-dev
117 2015-12-22T05:02:49  <Luke-Jr> many people I spoke to (on reddit especially) found the RBF changes acceptable only knowing it was configurable
118 2015-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
119 2015-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.
120 2015-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
121 2015-12-22T05:08:43  <jtimon> I hope this doesn't get rejected under the "controversial syndrome" btcdrak once talked me about
122 2015-12-22T05:10:02  <sipa> Luke-Jr: all fine with making optin configurable
123 2015-12-22T05:10:23  <sipa> i am not fine with adding full rbf support
124 2015-12-22T05:10:31  <Luke-Jr> sipa: it's not your place to decide.
125 2015-12-22T05:10:36  <sipa> sure it is
126 2015-12-22T05:10:53  <sipa> it is not my place to decide what people run
127 2015-12-22T05:10:53  <Luke-Jr> no, it is the end-user's right to decide.
128 2015-12-22T05:11:12  <sipa> it is my place to decide what i want the software that i am maintainer of to encourage
129 2015-12-22T05:11:18  <jtimon> sipa: why -policy=firstseen is fine but -policy=fullrbf is not?
130 2015-12-22T05:11:29  <sipa> jtimon: it breaks a social contract
131 2015-12-22T05:11:39  <Luke-Jr> it breaks no social contract. -.-
132 2015-12-22T05:11:40  <jtimon> what social contract?
133 2015-12-22T05:12:21  <sipa> whether you like it or not, some people see transactions as implicitly promising to not double spend
134 2015-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)
135 2015-12-22T05:12:28  <Luke-Jr> RBF does not change that.
136 2015-12-22T05:12:46  *** Greyboy has quit IRC
137 2015-12-22T05:12:48  <sipa> we can explain to people that this is a bad idea, but it does not change the expectation
138 2015-12-22T05:13:08  <sipa> and we just made that promise stronger by giving a way to opt out of it
139 2015-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
140 2015-12-22T05:13:28  <jtimon> and they can't do anything to stop them
141 2015-12-22T05:13:34  <sipa> jtimon: absolutely!
142 2015-12-22T05:13:47  <Luke-Jr> Opt-in RBF does not opt out of the implied promise not to fraudulently double-spend
143 2015-12-22T05:13:48  <sipa> but i don't think we should encourage it either
144 2015-12-22T05:14:26  <sipa> Luke-Jr: imho it does
145 2015-12-22T05:14:45  <Luke-Jr> sipa: that's ridiculous.
146 2015-12-22T05:14:52  <Luke-Jr> those promises are part of society, not the protocol
147 2015-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
148 2015-12-22T05:16:04  <jtimon> it will be cleaner for me to add the -policy=fullrbf option in bitcoin JT 0.12
149 2015-12-22T05:16:53  <jtimon> Luke-Jr: I think he means bitcoin core did the promise, not the protocol
150 2015-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?
151 2015-12-22T05:18:22  <jtimon> I would be happy to collaborate with you in bitcoin-policy if that makes sense to you
152 2015-12-22T05:19:00  <jtimon> as long as it starts with something like #6423
153 2015-12-22T05:20:19  <jtimon> but I'm still recovering from #5595/#6068's depression...
154 2015-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.
155 2015-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
156 2015-12-22T05:23:49  <btcdrak> sipa, luke-jr, we should just leave rbf as it is for now
157 2015-12-22T05:24:15  <btcdrak> rbf will come slowly. it wont come by trying to push too fast
158 2015-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
159 2015-12-22T05:24:29  <sipa> agree
160 2015-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
161 2015-12-22T05:25:28  <sipa> jtimon: totally fine with that
162 2015-12-22T05:26:12  <jtimon> Luke-Jr: would you be fine with that for #7219 ?
163 2015-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
164 2015-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)
165 2015-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
166 2015-12-22T05:29:12  <jtimon> (even if most policies just use specific default values for parameters in CDefaultPolicy)
167 2015-12-22T05:29:50  <Luke-Jr> hmm, so -policy would be kind of a "load this module" type logic?
168 2015-12-22T05:30:01  <jtimon> see also #5180
169 2015-12-22T05:30:06  <Luke-Jr> jtimon: how would you propose users select opt-in FSS?
170 2015-12-22T05:30:21  <jtimon> optin FSS?
171 2015-12-22T05:30:26  <jtimon> what is that?
172 2015-12-22T05:30:27  *** desantis has quit IRC
173 2015-12-22T05:30:33  <sipa> fss rbf?
174 2015-12-22T05:31:38  <Luke-Jr> jtimon: first-seen-safe RBF only with the opt-in flag
175 2015-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
176 2015-12-22T05:33:01  <sipa> can we just stop doing dozens of policies that nobody asks for?
177 2015-12-22T05:33:12  <sipa> i understand that you'd want to disable rbf
178 2015-12-22T05:33:38  *** Tera2342 has joined #bitcoin-core-dev
179 2015-12-22T05:36:35  <Luke-Jr> sipa: that implies we should do policies that people *do* ask for.. like priority space and full RBF
180 2015-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)
181 2015-12-22T05:37:15  <Luke-Jr> jtimon: unfortunately, I don't think I can commit to that, due to time constraints.
182 2015-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
183 2015-12-22T05:38:30  <sipa> Luke-Jr: full rbf makes no sense for a full node unless miners do it
184 2015-12-22T05:38:49  <Luke-Jr> sipa: I'm pretty sure there are miners who do ti.
185 2015-12-22T05:38:50  <sipa> Luke-Jr: once they do, i'm sure we can even discuss it as default policy in bitcoin core
186 2015-12-22T05:39:00  <sipa> once they do in significant numbers
187 2015-12-22T05:40:28  <Luke-Jr> wangchun: ^ willing to take the heat? :P
188 2015-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)
189 2015-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
190 2015-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
191 2015-12-22T05:42:32  <btcdrak> petertodds optin full rbf is a political compromise
192 2015-12-22T05:42:41  <btcdrak> as was fssrbf
193 2015-12-22T05:42:46  <btcdrak> baby steps...
194 2015-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"
195 2015-12-22T05:43:20  <jtimon> btcdrak: maintaining the optional -policy=firstseen shouldn't be more controversial than not doing it
196 2015-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
197 2015-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
198 2015-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
199 2015-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)
200 2015-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
201 2015-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.
202 2015-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
203 2015-12-22T05:55:29  <jtimon> anyway, I would like to understand your opinion on the special-space better too
204 2015-12-22T05:55:36  *** p15_ has joined #bitcoin-core-dev
205 2015-12-22T05:57:12  <Luke-Jr> jtimon: you mean priority?
206 2015-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)
207 2015-12-22T05:57:53  <jtimon> but there's no need for a separated space
208 2015-12-22T05:57:54  *** Madars has joined #bitcoin-core-dev
209 2015-12-22T05:58:00  *** p15 has quit IRC
210 2015-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")
211 2015-12-22T05:59:05  <jtimon> yep, you could have a g(f(fees, size), priority) "fitness function" for transactions without special space
212 2015-12-22T05:59:46  <Luke-Jr> and then when someone games the fees, the whole block is spam and legit users are blocked
213 2015-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)
214 2015-12-22T06:00:58  <jtimon> no, when I say equivalent I mean equivalent
215 2015-12-22T06:01:15  <aj> jtimon: only if you adjust g() based on what transactions are available
216 2015-12-22T06:01:40  <Luke-Jr> jtimon: that's at the very least much more complex to implement
217 2015-12-22T06:01:51  <sipa> jtimon: that's not the case unless you're willing to recompute virtual fees after every tx
218 2015-12-22T06:01:52  <jtimon> aj correct, that only seems a performance challenge
219 2015-12-22T06:01:53  <Luke-Jr> the goal ought to be to make policies *easier* to write, not absurdly complicated
220 2015-12-22T06:02:38  <sipa> Luke-Jr: how about we introduce a new scripting language then to configure relay and minig policies?
221 2015-12-22T06:02:49  <sipa> we still have engineering tradeoffs to makr
222 2015-12-22T06:02:56  *** go1111111 has joined #bitcoin-core-dev
223 2015-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
224 2015-12-22T06:03:28  <Luke-Jr> sipa: that's basically my long-term goal
225 2015-12-22T06:03:41  <Luke-Jr> minus it being a new language.. no reason not to allow using existing ones
226 2015-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
227 2015-12-22T06:05:43  <sipa> maintainable code is a worthy goal, and that's the extent of my support for policy refactors
228 2015-12-22T06:06:04  <sipa> i don't agree with the extreme configurability of policy as a goal
229 2015-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
230 2015-12-22T06:06:35  <jtimon> no, extreme configurability is the means
231 2015-12-22T06:07:17  <sipa> extreme runtime configurability i mea
232 2015-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)
233 2015-12-22T06:08:05  <sipa> making policy changes easy to write is indeed a good way to verify the modularization you're obtained
234 2015-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
235 2015-12-22T06:09:31  <sipa> ok, agree!
236 2015-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?
237 2015-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
238 2015-12-22T06:11:50  <jtimon> aj: well, I would just start with a CPolicy abstract class
239 2015-12-22T06:12:22  <jtimon> or a -policy=<string> command line option would also help
240 2015-12-22T06:13:19  <jtimon> but yeah, we could have -policy=rpc_mempool_score_update, shouldn't be hard
241 2015-12-22T06:14:36  <jtimon> and it could have different command-line parameters also configurable via GUI
242 2015-12-22T06:16:19  <jtimon> s/requires/"requires"
243 2015-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
244 2015-12-22T06:19:32  *** Madars has quit IRC
245 2015-12-22T06:21:58  <jtimon> aj in other words:
246 2015-12-22T06:21:58  <jtimon> def g(tx)
247 2015-12-22T06:21:58  <jtimon> if reason(tx.fees, tx.size) < reason_plus_ddos(mempool, tx):
248 2015-12-22T06:21:58  <jtimon> return false
249 2015-12-22T06:21:58  <jtimon> if priority < simulate_separate_space(tx, whatever)
250 2015-12-22T06:21:58  <jtimon> return false
251 2015-12-22T06:22:01  <jtimon> return true
252 2015-12-22T06:22:44  <phantomcircuit> Luke-Jr, i agree with jtimon that the cli parameter should be a string
253 2015-12-22T06:22:49  <jtimon> if priority(tx) < simulate_separate_space(tx, whatever)
254 2015-12-22T06:23:05  <Luke-Jr> phantomcircuit: comma-separated?
255 2015-12-22T06:23:31  *** zookolaptop has joined #bitcoin-core-dev
256 2015-12-22T06:23:38  *** p15_ has quit IRC
257 2015-12-22T06:23:58  <phantomcircuit> Luke-Jr, rbf policy option should be a string not 0,1,2
258 2015-12-22T06:24:08  <phantomcircuit> (just noticed you closed it, so nvm)
259 2015-12-22T06:25:38  <Luke-Jr> phantomcircuit: how do you specify both FSS and optin?
260 2015-12-22T06:25:49  <Luke-Jr> phantomcircuit: "nvm" is unnecessary, as this is still going in LJR
261 2015-12-22T06:26:32  <phantomcircuit> Luke-Jr, specify the parameter twice
262 2015-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
263 2015-12-22T06:26:40  <phantomcircuit> isn't it implemented as a multimap anyways?
264 2015-12-22T06:26:44  <Luke-Jr> ew
265 2015-12-22T06:26:50  <jtimon> no!!!
266 2015-12-22T06:27:32  <jtimon> -policy=a, -policy=b, -policy=a_and_b: that's how you do a_and_b
267 2015-12-22T06:27:57  <jtimon> I mean, how you support it in parallel to only_a and only_b
268 2015-12-22T06:28:20  *** p15 has joined #bitcoin-core-dev
269 2015-12-22T06:28:20  <Luke-Jr> jtimon: that isn't going to scale
270 2015-12-22T06:28:25  <jtimon> I still don't think I undesrstand firstseen
271 2015-12-22T06:28:43  <jtimon> I still don't think I undesrstand firstseen_optinrbf, isn't that the same as optinrbf?
272 2015-12-22T06:28:52  <Luke-Jr> no, it isn't.
273 2015-12-22T06:29:02  <Luke-Jr> why would you use underscores instead of commas?
274 2015-12-22T06:29:17  <phantomcircuit> Luke-Jr, meh, internally it's a bitfield presented to the user as -policy=A -policy=B
275 2015-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
276 2015-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
277 2015-12-22T06:34:03  <Luke-Jr> …
278 2015-12-22T06:34:18  *** zookolaptop has quit IRC
279 2015-12-22T06:34:27  <jtimon> Luke-Jr: re why would you use underscores instead of commas?
280 2015-12-22T06:34:28  <jtimon> I would use # or @, of course, (ie -policy=a#and#b), but I thought underscores were the new trend
281 2015-12-22T06:34:48  <Luke-Jr> more user-friendly to use commas
282 2015-12-22T06:34:57  <Luke-Jr> since it's being parsed into multiple options
283 2015-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)
284 2015-12-22T06:39:29  <jtimon> and the other point is, I undesrtand -policy=firstseen and -policy=optinrbf, but not -policy=firstseen,optinrbf
285 2015-12-22T06:40:02  <jtimon> (or -policy=firstseen_optinrbf, whatever)
286 2015-12-22T06:40:58  <sipa> aj: s/set_mempool_tx_score/prioritizetransaction/
287 2015-12-22T06:41:05  <sipa> aj: it already exists :)
288 2015-12-22T06:41:49  <jtimon> sipa: oh, that's what is for?
289 2015-12-22T06:42:16  <aj> sipa: (prioritise with an s, apparently!)
290 2015-12-22T06:42:31  <sipa> british vs american :)
291 2015-12-22T06:42:36  <sipa> i never know which is which
292 2015-12-22T06:42:42  <sipa> so i just pick the shortest
293 2015-12-22T06:42:45  <btcdrak> s is british
294 2015-12-22T06:42:49  <dcousens> ^
295 2015-12-22T06:42:55  <btcdrak> british is the original <<<<<<
296 2015-12-22T06:43:01  * btcdrak grins
297 2015-12-22T06:43:27  <btcdrak> I think it's the status quo in software to use the American spelling
298 2015-12-22T06:43:36  <dcousens> pretty much
299 2015-12-22T06:43:50  <btcdrak> I dislike that fact a lot...
300 2015-12-22T06:44:10  <dcousens> I gave up on `s` in favour of `z`, and almost never use `u`
301 2015-12-22T06:44:50  <aj> sipa: yeah, that seems sufficient, would be a bit painful to use for externally hacking priority back in
302 2015-12-22T06:45:17  <dcousens> jtimon: would it ever be worth policy being that 'plug and playable' though?
303 2015-12-22T06:45:46  <dcousens> like, unless you're a miner, or doing it for hardware reasons
304 2015-12-22T06:45:52  <jtimon> dcousens: as aj suggests? I don't know seems it would be very slow
305 2015-12-22T06:46:05  <dcousens> you're almost better off just capturing everything
306 2015-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
307 2015-12-22T06:47:01  <dcousens> but, its entirely speculative
308 2015-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)
309 2015-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
310 2015-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
311 2015-12-22T06:53:49  <Luke-Jr> wangchun: unconfirmed transactions are absolutely unsafe, I agree
312 2015-12-22T06:54:24  *** Guyver2 has joined #bitcoin-core-dev
313 2015-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
314 2015-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
315 2015-12-22T06:56:10  <Luke-Jr> wangchun: well, he can always CPFP it
316 2015-12-22T06:56:32  <Luke-Jr> and yes, priority will eventually make it eligible for charitable miners
317 2015-12-22T06:56:34  <wangchun> but if the block is already full, why should I still sort some tx by priority?
318 2015-12-22T06:56:45  <wangchun> That is why I used minblocksize=250000 before
319 2015-12-22T06:56:49  <Luke-Jr> wangchun: well, what about if there is a spam attack with fees?
320 2015-12-22T06:56:52  <Luke-Jr> like in the summer
321 2015-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
322 2015-12-22T06:58:48  <wangchun> I am glad to hear how to disable this "feature", however.
323 2015-12-22T06:59:29  <wangchun> Luke-Jr: As you have suggested before, set minblocksize to 250k may open a door to spammers
324 2015-12-22T06:59:54  <wangchun> CPFP should solve cafe owner's problem
325 2015-12-22T07:01:31  <Luke-Jr> wangchun: no, I mean like over the summer, when spammers backlogged with paying fees
326 2015-12-22T07:01:42  <Luke-Jr> wangchun: if you put fees first, you would mine those before priority txs
327 2015-12-22T07:01:55  <maaku> wangchun: it is only a matter of time until mempools are always full
328 2015-12-22T07:04:34  <wangchun> maaku: that's why we have limitfreerelay to zero
329 2015-12-22T07:05:21  <maaku> wangchun: no matter your parameters. bitcoin usage will grow to exceed capacity. this is the expected outcome
330 2015-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
331 2015-12-22T07:06:23  <wangchun> also priority size should decrease as the block template is approaching max block size
332 2015-12-22T07:07:50  <wangchun> Maybe I should write the patch
333 2015-12-22T07:08:09  <sipa> wangchun: the mempool limiting will only drop the lowest fee transactions, quite intelligently
334 2015-12-22T07:08:16  <wangchun> Luke-Jr: What's your attitude toward priority size?
335 2015-12-22T07:08:27  <sipa> wangchun: the solution is just to increase the size of the mempool
336 2015-12-22T07:08:30  <wangchun> sipa: I know, but we have the most important tx the lowest prioirty..
337 2015-12-22T07:08:36  *** tripleslash_h has joined #bitcoin-core-dev
338 2015-12-22T07:08:41  <wangchun> sipa: so I must switch off this feature
339 2015-12-22T07:08:45  <sipa> wangchun: that i don't understand
340 2015-12-22T07:08:56  <Luke-Jr> wangchun: I think it should be non-zero :p
341 2015-12-22T07:09:12  <wangchun> sipa: I have a txt which has a list of tx we must confirm at the highest prioirty
342 2015-12-22T07:09:25  <wangchun> sipa: this txt file is read every time createnewblock is called
343 2015-12-22T07:09:34  <sipa> wangchun: you can use prioritisetransaction ?
344 2015-12-22T07:09:43  <wangchun> sipa: but the tx themselves in mempool remain their priority untouched
345 2015-12-22T07:09:58  <wangchun> sipa: prioritisetransaction does not persist
346 2015-12-22T07:09:59  *** tripleslash has quit IRC
347 2015-12-22T07:10:10  <wangchun> sipa: and it cannot be edited with vim
348 2015-12-22T07:10:11  <sipa> wangchun: across restarts it does not
349 2015-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?
350 2015-12-22T07:10:43  <Quent> I think someone has some maths to show it too...
351 2015-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
352 2015-12-22T07:12:14  <sipa> wangchun: which will automatically make those transactions ineligible for eviction
353 2015-12-22T07:12:29  <wangchun> sipa: I don't know how often it is called, reading files is expensive i suppose
354 2015-12-22T07:13:05  *** raedah has joined #bitcoin-core-dev
355 2015-12-22T07:13:10  <sipa> wangchun: i haven't seen your code; i'm just saying that the two mechanisms should easily combinable
356 2015-12-22T07:13:19  <Quent> http://www.metzdowd.com/pipermail/cryptography/2015-December/027568.html
357 2015-12-22T07:13:22  <wangchun> sipa: but if you point me the git rev of the tx-dropping patch, that would help
358 2015-12-22T07:13:41  <sipa> wangchun: just increase the mempool size to whatever you can support
359 2015-12-22T07:14:02  <wangchun> sorry I have to leave, check irc log later
360 2015-12-22T07:14:04  <sipa> wangchun: -maxmempool=10000 will give you a max 10G menpool
361 2015-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
362 2015-12-22T07:14:55  <sipa> wangchun: anyway, feel free to ping here more if you have questions
363 2015-12-22T07:21:25  <dcousens> sipa: with segwit, a rescan is only possible with all the witness data no?
364 2015-12-22T07:24:55  *** raedah has quit IRC
365 2015-12-22T07:30:05  *** Ylbam has joined #bitcoin-core-dev
366 2015-12-22T07:41:08  <sipa> dcousens: no
367 2015-12-22T07:41:26  <sipa> dcousens: i hadn't thought about that, but you can rescan without witnesses
368 2015-12-22T07:49:12  *** Thireus has joined #bitcoin-core-dev
369 2015-12-22T07:52:41  *** Madars has joined #bitcoin-core-dev
370 2015-12-22T07:52:58  <dcousens> sipa: how so?
371 2015-12-22T07:53:49  <sipa> dcousens: why do you need signatures?
372 2015-12-22T07:54:09  <sipa> the amounts, addresses, consumed coins, locktime, ... are what matters to your wallet
373 2015-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
374 2015-12-22T07:55:08  <sipa> dcousens: output scripts only matter for payments to yourself, and for those you know the full script anyway
375 2015-12-22T07:55:24  <sipa> the witnesses are for inputs, not for outouts
376 2015-12-22T07:55:33  <sipa> it's the same as p2sh
377 2015-12-22T07:56:05  <dcousens> yeah, I guess I'd just watch for the sigwit hash that matched the P2PKH equivalent script
378 2015-12-22T07:56:06  <sipa> you don't need to know the redeemscripts to analyse p2sh ouputs to your wallet either
379 2015-12-22T07:56:09  <dcousens> nvm, ta
380 2015-12-22T07:56:35  <sipa> not the equivalent; your wallet would know it gave out a segwit script, and explicitly look for that
381 2015-12-22T07:56:49  <dcousens> sipa: a fresh import wouldn't know
382 2015-12-22T07:57:14  *** d_t has quit IRC
383 2015-12-22T07:57:34  *** d_t has joined #bitcoin-core-dev
384 2015-12-22T07:58:28  <sipa> dcousens: why not? you'd need to import scripts just as with p2sh
385 2015-12-22T07:58:32  <sipa> before import
386 2015-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
387 2015-12-22T08:01:30  <dcousens> per key
388 2015-12-22T08:01:41  <dcousens> all good :), just like p2sh
389 2015-12-22T08:12:33  *** xiangfu has quit IRC
390 2015-12-22T08:12:50  *** xiangfu has joined #bitcoin-core-dev
391 2015-12-22T08:20:31  *** Thireus has quit IRC
392 2015-12-22T08:21:44  *** Thireus has joined #bitcoin-core-dev
393 2015-12-22T08:29:34  *** Thireus1 has joined #bitcoin-core-dev
394 2015-12-22T08:30:15  *** Thireus has quit IRC
395 2015-12-22T08:30:43  *** Thireus1 has quit IRC
396 2015-12-22T08:32:07  *** Thireus has joined #bitcoin-core-dev
397 2015-12-22T08:41:34  *** arowser has quit IRC
398 2015-12-22T08:41:56  *** arowser has joined #bitcoin-core-dev
399 2015-12-22T08:50:42  *** JackH has joined #bitcoin-core-dev
400 2015-12-22T08:54:36  *** p15_ has joined #bitcoin-core-dev
401 2015-12-22T08:54:50  <GitHub25> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c24337964f2d...ed095f0407bd
402 2015-12-22T08:54:50  <GitHub25> bitcoin/master 9b41a5f Suhas Daftuar: Add more tests to p2p-fullblocktest
403 2015-12-22T08:54:50  <GitHub25> bitcoin/master ed095f0 Wladimir J. van der Laan: Merge pull request #7226...
404 2015-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
405 2015-12-22T08:55:05  *** p15 has quit IRC
406 2015-12-22T08:55:25  <GitHub133> [bitcoin] laanwj pushed 1 new commit to 0.12: https://github.com/bitcoin/bitcoin/commit/301f16ad1ca518c0873cd1bb99a26df36b46838b
407 2015-12-22T08:55:25  <GitHub133> bitcoin/0.12 301f16a Suhas Daftuar: Add more tests to p2p-fullblocktest...
408 2015-12-22T08:59:07  *** BashCo has joined #bitcoin-core-dev
409 2015-12-22T08:59:46  *** MarcoFalke has joined #bitcoin-core-dev
410 2015-12-22T09:00:01  <MarcoFalke> wumpus, 7242 is a loop. You can close it.
411 2015-12-22T09:00:51  <MarcoFalke> It tries to merge .12 into master. Only running travis each time you commit
412 2015-12-22T09:05:21  *** randy-waterhouse has quit IRC
413 2015-12-22T09:07:28  *** BashCo has quit IRC
414 2015-12-22T09:15:39  *** p15 has joined #bitcoin-core-dev
415 2015-12-22T09:16:23  *** p15_ has quit IRC
416 2015-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
417 2015-12-22T09:29:19  *** BashCo has joined #bitcoin-core-dev
418 2015-12-22T09:45:30  *** Thireus has quit IRC
419 2015-12-22T09:46:40  *** Thireus has joined #bitcoin-core-dev
420 2015-12-22T09:52:58  *** Tera2342 has quit IRC
421 2015-12-22T09:56:04  *** Thireus has quit IRC
422 2015-12-22T09:56:07  *** Thireus1 has joined #bitcoin-core-dev
423 2015-12-22T10:00:34  *** Thireus1 has quit IRC
424 2015-12-22T10:10:02  *** Thireus has joined #bitcoin-core-dev
425 2015-12-22T10:10:23  <maaku> wumpus: what is the translation schedule for 0.12 ?
426 2015-12-22T10:10:48  <wumpus> string freeze was dec 1, translations from transifex will be merged up until the last RC
427 2015-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 :(
428 2015-12-22T10:13:51  <wumpus> sorry for that
429 2015-12-22T10:14:25  <maaku> yeah understandable
430 2015-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
431 2015-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
432 2015-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)
433 2015-12-22T10:18:41  <maaku> That would be nice.
434 2015-12-22T10:20:18  *** Thireus has quit IRC
435 2015-12-22T10:22:50  *** dcousens has quit IRC
436 2015-12-22T10:32:32  <Luke-Jr> wumpus: the translation freeze can't be semi-relaxed for an algorithmic change, if I adjust them myself?
437 2015-12-22T10:32:51  <Luke-Jr> I mean, I assume we're not using different package names within the translations..
438 2015-12-22T10:33:42  <Luke-Jr> (that is, Bitcoin Kern is every place Bitcoin Core would otherwise have been)
439 2015-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
440 2015-12-22T10:36:04  <Luke-Jr> (I've done it before for the older stable branches)
441 2015-12-22T10:37:39  <GitHub83> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/ed095f0407bd...595f93977c56
442 2015-12-22T10:37:39  <GitHub83> bitcoin/master 37d271d mb300sd: Rename OP_NOP2 to OP_CHECKLOCKTIMEVERIFY.
443 2015-12-22T10:37:40  <GitHub83> bitcoin/master 595f939 Wladimir J. van der Laan: Merge pull request #7213...
444 2015-12-22T10:40:49  <maaku> Luke-Jr: I believe he means that the translators will have to update the translated strings
445 2015-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...
446 2015-12-22T10:42:47  <Luke-Jr> maaku: that's what I am suggesting, yes
447 2015-12-22T10:43:02  <Luke-Jr> it shouldn't need approval from a native speaker, since it produces the same final strings..
448 2015-12-22T10:44:05  <maaku> Luke-Jr: it is possible that the product name is translated differently in some languages based on context
449 2015-12-22T10:44:20  <Luke-Jr> maaku: if so, then I would be unable to do the substitutions :p
450 2015-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
451 2015-12-22T10:44:57  <maaku> no idea if this is actually the case though, and there's a good chance it isn't
452 2015-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
453 2015-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
454 2015-12-22T10:46:10  <Luke-Jr> wumpus: it's a replacement for each language
455 2015-12-22T10:46:13  <wumpus> (and there's no guarantee of consistency there)
456 2015-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?
457 2015-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
458 2015-12-22T10:47:40  <Luke-Jr> and if I don't make it in time, we just go ahead without it?
459 2015-12-22T10:47:46  *** tripleslash_h has quit IRC
460 2015-12-22T10:48:13  *** tripleslash has joined #bitcoin-core-dev
461 2015-12-22T10:48:24  <MarcoFalke> Wouldn't 0.12.1 be enough for that?
462 2015-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
463 2015-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
464 2015-12-22T10:48:38  <wumpus> MarcoFalke: yeah that's what I said
465 2015-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
466 2015-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
467 2015-12-22T10:51:59  <wumpus> (unless there are languages where it *has* to be translated differently based on the context for correctness... hmm)
468 2015-12-22T10:52:29  <Luke-Jr> if that were the case, I think we'd already have problems in other areas
469 2015-12-22T10:52:33  <maaku> right but a competent translator should be able to account for that to make it uniform everywhere
470 2015-12-22T10:52:53  <Luke-Jr> anyhow, I'll try it and we'll see what I find.
471 2015-12-22T10:52:55  <wumpus> maaku: yes that makes sense
472 2015-12-22T10:53:11  <wumpus> (though that's another argument  gainst doing this bot-wise)
473 2015-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
474 2015-12-22T10:55:42  <wumpus> yes, it's supposed to be Bitcoin Core developers - was it changed back somehow?
475 2015-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
476 2015-12-22T10:56:41  <Luke-Jr> wumpus: no, he's complaining that PACKAGE_NAME gets substituted in the rendered places
477 2015-12-22T10:57:14  <Luke-Jr> maaku: well, just the About dialogue; doing it in docs isn't practical
478 2015-12-22T10:57:41  <Luke-Jr> maaku: how is it wrong?
479 2015-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
480 2015-12-22T10:58:06  <Luke-Jr> MarcoFalke: how is this a problem?
481 2015-12-22T10:58:39  <wumpus> I understand MarcoFalke's issue - automatically updating copyrights can be a bit thorny
482 2015-12-22T10:58:52  <MarcoFalke> Implying "MF" is the author of something he is not actually the author of.
483 2015-12-22T10:59:02  <wumpus> it makes it easy to steal credit
484 2015-12-22T10:59:08  <Luke-Jr> it doesn't imply that, though..
485 2015-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"
486 2015-12-22T10:59:42  <wumpus> so maybe leave the copyright alone
487 2015-12-22T10:59:47  <wumpus> leave it up to a project to set that
488 2015-12-22T10:59:50  <Luke-Jr> maaku: from Bitcoin Core *developers* -> Liquid *developers*
489 2015-12-22T11:00:01  <Luke-Jr> neither is a legal entity
490 2015-12-22T11:00:04  <wumpus> it doesn't matter if theres one more place to update it
491 2015-12-22T11:00:07  <maaku> Luke-Jr: ok i suppose that is not strictly speaking wrong
492 2015-12-22T11:00:21  <maaku> anyway yeah the copyright string probably shouldn't be changed
493 2015-12-22T11:01:04  <wumpus> having it automatically substituted only makes sense for Bitcoin Core, derivative projects likely want to extend it instead
494 2015-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.
495 2015-12-22T11:01:39  <MarcoFalke> Right, it should be extended
496 2015-12-22T11:01:55  <Luke-Jr> hm
497 2015-12-22T11:01:57  <MarcoFalke> I think I saw some altcoins doing this correctly
498 2015-12-22T11:02:04  <Luke-Jr> maybe a separate variable?
499 2015-12-22T11:02:14  <wumpus> yes make the copyright separate
500 2015-12-22T11:02:48  <wumpus> it's a good point
501 2015-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
502 2015-12-22T11:06:31  <Luke-Jr> hrm, this is not trivial to do without breaking the translatability of this
503 2015-12-22T11:06:41  <wumpus> maybe just skip it for now
504 2015-12-22T11:06:47  <wumpus> leave the copyright as it
505 2015-12-22T11:07:23  <wumpus> could do it later, or not, you don't have to iron out all the issues in one pull
506 2015-12-22T11:09:38  <wumpus> but why is it so hard? e.g. make a function GetCopyright() { return _("Copyright 2009-2016 blabla developers"); }
507 2015-12-22T11:10:09  <wumpus> use that in the two(?) places where you need it
508 2015-12-22T11:10:20  <Luke-Jr> four, but that's more or less the approach I'm using
509 2015-12-22T11:10:36  <Luke-Jr> difficulty is one of them is inside a plist
510 2015-12-22T11:10:44  <maaku> Luke-Jr: add a %s at the end of the copyright which is the empty string
511 2015-12-22T11:10:59  <Luke-Jr> maaku: O.o?
512 2015-12-22T11:11:00  <wumpus> well the plist is another issue
513 2015-12-22T11:11:05  <wumpus> imo you should leave that for another pull too
514 2015-12-22T11:11:13  <maaku> and agree with ^
515 2015-12-22T11:11:15  *** Tera2342 has joined #bitcoin-core-dev
516 2015-12-22T11:11:29  <wumpus> just mae your pull what it promises to do - unify the product name where it's *easy to do*
517 2015-12-22T11:11:32  <maaku> this is fixable, but for now just don't substitute "Bitcoin Core" in the copyright string
518 2015-12-22T11:11:40  <wumpus> maaku: exactly
519 2015-12-22T11:12:09  <MarcoFalke> Agree, we can leave that for now
520 2015-12-22T11:12:20  <Luke-Jr> wumpus: easy to do was part of the first commit; the rest does very non-easy things :P
521 2015-12-22T11:12:39  <Luke-Jr> what does strprintf do if there's more params than fields?
522 2015-12-22T11:17:40  *** MarcoFalke has quit IRC
523 2015-12-22T11:18:19  *** MarcoFalke has joined #bitcoin-core-dev
524 2015-12-22T11:23:42  *** xiangfu has quit IRC
525 2015-12-22T11:24:00  *** xiangfu has joined #bitcoin-core-dev
526 2015-12-22T11:29:25  <wumpus> Luke-Jr: raise an exception
527 2015-12-22T11:30:09  <Luke-Jr> thx
528 2015-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
529 2015-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.
530 2015-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.
531 2015-12-22T12:03:11  <maaku> Freicoin did the same
532 2015-12-22T12:03:30  <maaku> but my point was that the above PR would have automatically done the copyright violating rename
533 2015-12-22T12:05:28  <Luke-Jr> warren: how a copyright violation?
534 2015-12-22T12:05:46  <Luke-Jr> jonasschnelli points out on the PR, that we do not independently list LevelDB etc
535 2015-12-22T12:07:38  <maaku> I don't think it is a violation under MIT
536 2015-12-22T12:07:46  <maaku> legally, ethically yes
537 2015-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).
538 2015-12-22T12:07:54  <MarcoFalke> Luke-Jr, I think it's called copyfraud in english
539 2015-12-22T12:08:54  <jonasschnelli> It would definitively be unethically (copy the source, rename and change the copyright).
540 2015-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
541 2015-12-22T12:09:24  <jonasschnelli> And Luke-Jr does not change the string itself,... it makes it just more "accessible"
542 2015-12-22T12:09:30  <jonasschnelli> *Luke-Jr s'PR
543 2015-12-22T12:09:42  <warren> Can we go further and parameterize all variations of the word Bitcoin in various strings that are currently translated?
544 2015-12-22T12:09:46  <Luke-Jr> maaku: but that leaves the problem unsolved
545 2015-12-22T12:09:54  <jonasschnelli> ;-)
546 2015-12-22T12:09:58  <Luke-Jr> warren: -.-
547 2015-12-22T12:10:16  <warren> Luke-Jr: to make it easier for sidechains and ... XT to rebase =)
548 2015-12-22T12:10:23  <maaku> warren: I believe this PR does just that
549 2015-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
550 2015-12-22T12:11:09  <Luke-Jr> warren: sidechains are Bitcoin
551 2015-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
552 2015-12-22T12:11:25  <MarcoFalke> warren, I think this can be another PR if really desired?
553 2015-12-22T12:12:43  <Luke-Jr> I don't think we need to spend time making altcoins easier :p
554 2015-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)
555 2015-12-22T12:13:29  <warren> Luke-Jr: good point
556 2015-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
557 2015-12-22T12:14:14  <Quent> sorry to barge in, but was just wondering whether there is any documentation on the algorithmic optimisations to libsec?
558 2015-12-22T12:14:35  <Luke-Jr> Quent: I would expect to find it in source code comments
559 2015-12-22T12:14:54  <Luke-Jr> you might try asking in #secp256k1 also
560 2015-12-22T12:15:25  <Quent> there is no documentation of the maths etc used in libsec save for the code itself?
561 2015-12-22T12:16:19  <jonasschnelli> Quent: all written here: https://github.com/bitcoin/secp256k1#implementation-details ?
562 2015-12-22T12:16:53  <jonasschnelli> If you compile it with openssl, you can also run a benchmark IIRC
563 2015-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
564 2015-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
565 2015-12-22T12:19:06  <Luke-Jr> maaku: I see no use case in parameterising "bitcoins" for forks/sidechains, only altcoins.
566 2015-12-22T12:20:39  <btcdrak> seems like much of this conversation belongs in #bitcoin-dev
567 2015-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.
568 2015-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.
569 2015-12-22T12:23:42  <warren> ... and I think we violated that advice a lot and it didn't matter.
570 2015-12-22T12:26:20  <Luke-Jr> indeed, the notice only matters insofar as it indicates intent
571 2015-12-22T12:30:19  *** _Sam-- has joined #bitcoin-core-dev
572 2015-12-22T12:30:20  *** _Sam-- has joined #bitcoin-core-dev
573 2015-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.
574 2015-12-22T12:34:26  <Luke-Jr> How's this look? https://github.com/luke-jr/bitcoin/commit/917b1d03cf3afa6939113e2fb0bf89dbfd9db2d7
575 2015-12-22T12:34:44  <MarcoFalke> If people want a comma separated list, I am fine with that, too. Should I go this way?
576 2015-12-22T12:35:04  <Luke-Jr> MarcoFalke: that is likely to complicate the code annoyingly. not worth it IMO
577 2015-12-22T12:35:31  <MarcoFalke> Agree. And it wastes time to go through the diff.
578 2015-12-22T12:35:52  <MarcoFalke> (in the PR which changes the syntax, that is)
579 2015-12-22T12:43:19  <jonasschnelli> Luke-Jr: mac build fails again: "ImportError: No module named ez_setup"
580 2015-12-22T12:43:22  <jonasschnelli> https://bitcoin.jonasschnelli.ch/pulls/7192/build-osx.log
581 2015-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
582 2015-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.
583 2015-12-22T12:49:15  *** Thireus has joined #bitcoin-core-dev
584 2015-12-22T12:49:34  *** afk11 has quit IRC
585 2015-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
586 2015-12-22T12:58:14  <wumpus> and unifying repeated strings simply makes sense when it helps enforcing consistency
587 2015-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
588 2015-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...)
589 2015-12-22T13:02:28  <jonasschnelli> What about merging https://github.com/bitcoin/bitcoin/pull/7153?
590 2015-12-22T13:03:09  <jonasschnelli> It ensures the 0.12 mempool limiting behavior.
591 2015-12-22T13:03:58  <wumpus> jonasschnelli: oh, seems I forgot about that one, soryr
592 2015-12-22T13:04:04  <jonasschnelli> np
593 2015-12-22T13:04:09  <MarcoFalke> Looks good to merge. Isn't there other rpc test testing mempool stuff?
594 2015-12-22T13:04:38  <MarcoFalke> Or is this the first one to test mempool limiting?
595 2015-12-22T13:04:42  <wumpus> adding tests for new behavior is good
596 2015-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
597 2015-12-22T13:05:22  <MarcoFalke> Great, then let's merge!
598 2015-12-22T13:06:02  <GitHub139> [bitcoin] jonasschnelli pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/595f93977c56...a1c185be546b
599 2015-12-22T13:06:03  <GitHub139> bitcoin/master fa8c8d7 MarcoFalke: torcontrol debug: Change to a blanket message that covers both cases
600 2015-12-22T13:06:03  <GitHub139> bitcoin/master fa5769e MarcoFalke: [qt] Fix misleading translation
601 2015-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
602 2015-12-22T13:06:04  <GitHub139> bitcoin/master a1c185b Jonas Schnelli: Merge pull request #7218...
603 2015-12-22T13:07:11  <GitHub198> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/a1c185be546b...97d83739db06
604 2015-12-22T13:07:13  <GitHub198> bitcoin/master 110ff11 Jonas Schnelli: [Tests] Add mempool_limit.py test
605 2015-12-22T13:07:13  <GitHub198> bitcoin/master 7632cf6 Jonas Schnelli: [Tests] Refactor some shared functions
606 2015-12-22T13:07:14  <GitHub198> bitcoin/master 97d8373 Wladimir J. van der Laan: Merge pull request #7153...
607 2015-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
608 2015-12-22T13:15:18  *** Thireus1 has joined #bitcoin-core-dev
609 2015-12-22T13:15:19  *** Thireus has quit IRC
610 2015-12-22T13:15:55  *** Cory has quit IRC
611 2015-12-22T13:17:57  *** afk11 has joined #bitcoin-core-dev
612 2015-12-22T13:18:37  *** xiangfu has quit IRC
613 2015-12-22T13:18:53  *** Cory has joined #bitcoin-core-dev
614 2015-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.
615 2015-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).
616 2015-12-22T13:21:54  <MarcoFalke> Ok, good to hear it didn't make things worse. :)
617 2015-12-22T13:23:15  *** MarcoFalke has quit IRC
618 2015-12-22T13:31:46  *** arubi has quit IRC
619 2015-12-22T13:32:38  *** p15 has quit IRC
620 2015-12-22T13:35:38  <Luke-Jr> jonasschnelli: fixed gitian issue
621 2015-12-22T14:02:06  <jonasschnelli> Okay. Recompiling...
622 2015-12-22T14:10:41  *** afk11 has quit IRC
623 2015-12-22T14:24:39  *** laurentmt has joined #bitcoin-core-dev
624 2015-12-22T14:25:17  *** laurentmt has quit IRC
625 2015-12-22T14:59:08  *** Tera2342 has quit IRC
626 2015-12-22T15:00:16  *** Tera2342 has joined #bitcoin-core-dev
627 2015-12-22T15:08:46  *** Tera2342 has quit IRC
628 2015-12-22T15:33:30  <jonasschnelli> Luke-Jr: works now. Took >50mins to build... any idea why? Did it somehow invalidate the dependency cache?
629 2015-12-22T15:46:41  <GitHub121> [bitcoin] laanwj pushed 2 new commits to 0.12: https://github.com/bitcoin/bitcoin/compare/301f16ad1ca5...453c56701a14
630 2015-12-22T15:46:41  <GitHub121> bitcoin/0.12 9ef7c54 Jonas Schnelli: [Tests] Add mempool_limit.py test...
631 2015-12-22T15:46:42  <GitHub121> bitcoin/0.12 453c567 Wladimir J. van der Laan: tests: Disable Tor interaction...
632 2015-12-22T15:46:51  *** MarcoFalke has joined #bitcoin-core-dev
633 2015-12-22T15:51:19  *** adam3us has quit IRC
634 2015-12-22T15:53:48  *** MarcoFalke has quit IRC
635 2015-12-22T15:58:31  <Luke-Jr> jonasschnelli: it shouldn't have, but you wouldn't have gotten that error if your cache was working..
636 2015-12-22T16:01:09  *** adam3us has joined #bitcoin-core-dev
637 2015-12-22T16:03:05  *** laurentmt has joined #bitcoin-core-dev
638 2015-12-22T16:03:15  *** laurentmt has quit IRC
639 2015-12-22T16:21:22  *** arowser has quit IRC
640 2015-12-22T16:21:49  *** arowser has joined #bitcoin-core-dev
641 2015-12-22T16:27:55  *** afk11 has joined #bitcoin-core-dev
642 2015-12-22T16:35:56  *** calibre720 has joined #bitcoin-core-dev
643 2015-12-22T16:54:53  *** zookolaptop has joined #bitcoin-core-dev
644 2015-12-22T17:10:59  *** afk11 has quit IRC
645 2015-12-22T17:22:49  *** desantis has joined #bitcoin-core-dev
646 2015-12-22T17:39:06  <jonasschnelli> Okay. Thanks. Maybe my build system was under heavy load...
647 2015-12-22T17:40:33  *** zookolaptop is now known as zooko
648 2015-12-22T18:05:12  *** BashCo has quit IRC
649 2015-12-22T18:06:00  *** laurentmt has joined #bitcoin-core-dev
650 2015-12-22T18:06:15  *** laurentmt has quit IRC
651 2015-12-22T18:08:59  *** arubi has joined #bitcoin-core-dev
652 2015-12-22T18:13:07  *** paveljanik has joined #bitcoin-core-dev
653 2015-12-22T18:27:27  *** BashCo has joined #bitcoin-core-dev
654 2015-12-22T18:34:28  *** brg444 has joined #bitcoin-core-dev
655 2015-12-22T18:34:28  *** davec has quit IRC
656 2015-12-22T18:34:59  *** davec has joined #bitcoin-core-dev
657 2015-12-22T18:45:11  *** alpalp has joined #bitcoin-core-dev
658 2015-12-22T18:51:47  *** alpalp has quit IRC
659 2015-12-22T18:56:19  *** alpalp has joined #bitcoin-core-dev
660 2015-12-22T18:59:43  *** amiller has quit IRC
661 2015-12-22T19:03:05  *** Guest71119 has joined #bitcoin-core-dev
662 2015-12-22T19:07:37  *** desantis has quit IRC
663 2015-12-22T19:10:28  *** desantis has joined #bitcoin-core-dev
664 2015-12-22T19:24:16  *** adam3us has quit IRC
665 2015-12-22T19:24:24  *** adam3us has joined #bitcoin-core-dev
666 2015-12-22T19:42:47  *** raedah has joined #bitcoin-core-dev
667 2015-12-22T20:03:35  *** Quent has left #bitcoin-core-dev
668 2015-12-22T20:07:46  *** JackH has quit IRC
669 2015-12-22T20:20:42  *** randy-waterhouse has joined #bitcoin-core-dev
670 2015-12-22T20:27:42  *** calibre720 has quit IRC
671 2015-12-22T20:41:15  *** dgenr8 has quit IRC
672 2015-12-22T20:46:12  *** dgenr8 has joined #bitcoin-core-dev
673 2015-12-22T20:50:34  *** dgenr8 has quit IRC
674 2015-12-22T20:53:35  *** Cory has quit IRC
675 2015-12-22T20:56:30  *** Cory has joined #bitcoin-core-dev
676 2015-12-22T21:02:18  *** raedah_ has joined #bitcoin-core-dev
677 2015-12-22T21:02:26  *** raedah has quit IRC
678 2015-12-22T21:12:43  *** BashCo_ has joined #bitcoin-core-dev
679 2015-12-22T21:14:52  *** BashCo has quit IRC
680 2015-12-22T21:14:55  *** arubi_ has joined #bitcoin-core-dev
681 2015-12-22T21:15:13  *** arubi has quit IRC
682 2015-12-22T21:15:15  *** arubi_ is now known as arubi
683 2015-12-22T21:27:30  *** randy-waterhouse has quit IRC
684 2015-12-22T21:27:55  *** raedah_ has quit IRC
685 2015-12-22T21:41:29  *** raedah_ has joined #bitcoin-core-dev
686 2015-12-22T21:51:17  *** paveljanik has quit IRC
687 2015-12-22T22:08:13  *** Thireus has joined #bitcoin-core-dev
688 2015-12-22T22:10:06  *** Thireus has quit IRC
689 2015-12-22T22:10:09  *** Thireus2 has joined #bitcoin-core-dev
690 2015-12-22T22:10:32  *** Thireus1 has quit IRC
691 2015-12-22T22:10:58  *** Thireus has joined #bitcoin-core-dev
692 2015-12-22T22:11:14  *** Thireus2 has quit IRC
693 2015-12-22T22:19:53  *** Thireus has quit IRC
694 2015-12-22T22:47:47  *** alpalp has quit IRC
695 2015-12-22T22:49:16  *** Ylbam has quit IRC
696 2015-12-22T22:49:28  *** jl2012 has quit IRC
697 2015-12-22T22:54:40  *** Guyver2 has quit IRC
698 2015-12-22T22:55:45  *** laurentmt has joined #bitcoin-core-dev
699 2015-12-22T22:55:54  *** laurentmt has quit IRC
700 2015-12-22T23:01:55  *** Madars has quit IRC
701 2015-12-22T23:10:09  *** jl2012 has joined #bitcoin-core-dev
702 2015-12-22T23:15:02  *** raedah_ has quit IRC
703 2015-12-22T23:15:06  *** x___ has joined #bitcoin-core-dev
704 2015-12-22T23:20:45  *** Ylbam has joined #bitcoin-core-dev
705 2015-12-22T23:21:08  *** desantis has quit IRC
706 2015-12-22T23:24:50  *** x___ has quit IRC
707 2015-12-22T23:26:04  *** Tera2342 has joined #bitcoin-core-dev
708 2015-12-22T23:44:51  *** JackH has joined #bitcoin-core-dev
709 2015-12-22T23:46:55  <wangchun> morcos: I'll try prioritisetransaction, thx
710 2015-12-22T23:48:05  <phantomcircuit> wangchun, trying to get things into your mempool which are otherwise rejected because of minrelay fee?
711 2015-12-22T23:48:16  <wangchun> phantomcircuit: yes
712 2015-12-22T23:49:35  <sipa> i think if you first call prioritizetransaction, and then submit it, it will be accepted
713 2015-12-22T23:49:44  <wangchun> as blocks are not very full these days, we would like to confirm some free tx
714 2015-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
715 2015-12-22T23:51:09  <phantomcircuit> wangchun, how are you selecting which free transactions to include?
716 2015-12-22T23:51:38  <wangchun> sort by prioirity of course
717 2015-12-22T23:51:45  <wangchun> priority
718 2015-12-22T23:52:22  <phantomcircuit> wangchun, yeah then using the rpc command and prioritizetransaction is the best way to do that