1 2015-12-16T00:14:50  *** Tera2342 has joined #bitcoin-core-dev
  2 2015-12-16T00:17:25  *** desantis has joined #bitcoin-core-dev
  3 2015-12-16T00:22:06  *** Tera2342 has quit IRC
  4 2015-12-16T00:34:23  <morcos> jamesob: i'm also working on CNB improvements right now
  5 2015-12-16T00:34:48  <morcos> however the background threading was further down my list, so perhaps we can coordinate our work to some degree
  6 2015-12-16T00:35:10  <morcos> right now i'm refactoring CNB into a class (i should have just done that last time)
  7 2015-12-16T00:37:29  *** Thireus has quit IRC
  8 2015-12-16T00:39:06  *** raedah has quit IRC
  9 2015-12-16T00:41:47  <morcos> i'd be interested in understanding exactly what you're trying to accomplish though, b/c it's not really clear to me how to gain a whole lot without much more locking rework.
 10 2015-12-16T00:42:05  <morcos> certainly there are a couple of good ideas that should be implemented and which we've seen PR's take a stab at though:
 11 2015-12-16T00:42:46  <morcos> 1) moving TestBlockValidity to a background thread (although its not clear how easy it is to make this interuptable and this is 90% of the time of CNB right now)
 12 2015-12-16T00:43:10  <morcos> 2) returning a template based on no txs after a new tip
 13 2015-12-16T00:44:04  <sipa> making CNB as a whole run in the background would make taking TBV out of the delay very easy: just set the stored CNB result before verifying it
 14 2015-12-16T00:44:11  <morcos> 3) interrupting the cs_main lock required for block assembly (before TBV) when a new tip comes in, although now this is only 10-20ms and it really shouldn't require so much cs_main as a mempool lock which just happens to be cs_main now
 15 2015-12-16T00:45:36  <morcos> sipa: i suppose that's true.
 16 2015-12-16T00:46:03  *** tripleslash has quit IRC
 17 2015-12-16T00:46:03  <morcos> i guess it just seems to me that its almost more logical to let the caller dictate when (how often) the new block is assembled
 18 2015-12-16T00:46:28  <morcos> the latency is irrelvant except when a new tip comes in, and thats really the interupt function you need to get right
 19 2015-12-16T00:47:00  <morcos> and then can work just as well or even better in the same thread
 20 2015-12-16T00:47:41  <morcos> longpoll returns after a) some specified amount of time has passed, and then at the end of it a new template is created or b) a new tip comes in
 21 2015-12-16T00:47:45  *** moli has quit IRC
 22 2015-12-16T00:47:54  <morcos> i mean it really already is a "background" thread
 23 2015-12-16T00:48:31  <morcos> you just want to return the result before running TestBlockValidity, and you want to have an interupt for new tips
 24 2015-12-16T00:49:08  *** moli has joined #bitcoin-core-dev
 25 2015-12-16T00:50:12  *** laurentmt has joined #bitcoin-core-dev
 26 2015-12-16T00:50:33  <morcos> Or am I missing that there is some advantage of immediately returning a template that is Y seconds old when you call gbt instead of having to wait X seconds for a template that is X seconds old where X is by definition less than Y b/c X is the block assembly time
 27 2015-12-16T00:50:45  *** laurentmt has quit IRC
 28 2015-12-16T00:54:52  <morcos> sipa: do you have any thoughts on the feasibility of making ConnectBlock interuptable?  That seems to me its always going to be an issue with generating a lot of different blocks if you want to keep testing them.
 29 2015-12-16T01:04:38  *** Tera2342 has joined #bitcoin-core-dev
 30 2015-12-16T01:23:06  *** Quent has quit IRC
 31 2015-12-16T01:37:26  *** Cory has quit IRC
 32 2015-12-16T01:41:29  *** Ylbam has quit IRC
 33 2015-12-16T01:58:20  *** desantis has left #bitcoin-core-dev
 34 2015-12-16T02:10:49  *** desantis has joined #bitcoin-core-dev
 35 2015-12-16T02:11:36  *** desantis has left #bitcoin-core-dev
 36 2015-12-16T02:12:47  *** desantis has joined #bitcoin-core-dev
 37 2015-12-16T02:13:26  *** belcher has quit IRC
 38 2015-12-16T02:13:46  *** desantis has left #bitcoin-core-dev
 39 2015-12-16T02:14:46  *** desantis has joined #bitcoin-core-dev
 40 2015-12-16T02:15:39  *** desantis has quit IRC
 41 2015-12-16T02:15:57  *** desantis has joined #bitcoin-core-dev
 42 2015-12-16T02:16:17  *** desantis has quit IRC
 43 2015-12-16T02:16:35  *** desantis has joined #bitcoin-core-dev
 44 2015-12-16T02:25:09  <BlueMatt> morcos: please do not further complicate getblocktemplate
 45 2015-12-16T02:25:19  <BlueMatt> we want to move complexity out of pool servers and into bitcoind, not the other way around
 46 2015-12-16T02:25:44  <BlueMatt> (pool servers are largely bit proprietary blobs that get essentially no external review, whereas bitcoin core is....not that)
 47 2015-12-16T02:27:05  <sipa> morcos: i'd rather just not always call TBV... *ducks*
 48 2015-12-16T02:27:16  <BlueMatt> sipa: noooooooooooooooooo
 49 2015-12-16T02:27:25  <BlueMatt> that shit has been so broken up until literally the latest release
 50 2015-12-16T02:27:32  <BlueMatt> there is no way in hell we should remove that check
 51 2015-12-16T02:27:40  <sipa> i am not saying remove it
 52 2015-12-16T02:28:01  <sipa> but just call it 1% or 10% of the time or so
 53 2015-12-16T02:28:10  <sipa> it's there to detect software bugs
 54 2015-12-16T02:28:18  <sipa> it's not there to prevent incorrect responses
 55 2015-12-16T02:28:34  <BlueMatt> sipa: it is absolutely there to prevent incorrect responses
 56 2015-12-16T02:28:45  <BlueMatt> up until the latest release there were known bugs which made it required
 57 2015-12-16T02:28:57  <BlueMatt> (well assuming you dont check txn as you go, which we now dont)
 58 2015-12-16T02:28:58  <sipa> ... and cause the software to crash?
 59 2015-12-16T02:29:04  <sipa> it's an assert
 60 2015-12-16T02:29:10  <BlueMatt> it isnt anymore
 61 2015-12-16T02:33:44  <BlueMatt> morcos: in any case, my view for getblocktemplate refactors, which should be a few small changes (that I suggested to jamesob last night) is
 62 2015-12-16T02:33:50  <BlueMatt> 1) Interrupt CNB when a new block comes in...you suggest block validation times are not an issue, but, really, pools do not run with our fancy hardware or mempool limiting (hell, when talking about mempool limiting we often assumed miners have a massive mempool)
 63 2015-12-16T02:33:55  <BlueMatt> 2) run CNB in the background on a loop...making getblocktemplate never block. Often when pools call getblocktemplate, they do it very often, and you'll end up blocking accepting a new block for getblocktemplate to return.
 64 2015-12-16T02:34:05  <BlueMatt> 3) return an empty block if the current block template we have is not based on the tip
 65 2015-12-16T02:34:25  <BlueMatt> 3 should be a trivial change, and 1 and 2 should be pretty easily-reviewable code
 66 2015-12-16T02:34:48  <BlueMatt> between the 3 getblocktemplate is about as optimal as we need to care, and all of the questionable logic currently in pools to emulate this can go away
 67 2015-12-16T02:35:46  *** PRab has quit IRC
 68 2015-12-16T02:35:51  <sipa> 3) means that the update new tip code should also briefly lock the CNB cached value and wipe it
 69 2015-12-16T02:36:02  <BlueMatt> morcos: which looks almost identical to your proposal, but I dont think we should only be moving TBV to a background thread
 70 2015-12-16T02:36:09  <BlueMatt> all of CNB should be there, getblocktemplate should never block
 71 2015-12-16T02:36:20  <sipa> otherwise GBT needs to grab cs_main to determine whether the tip changed
 72 2015-12-16T02:36:27  <sipa> (not a problem; just realizing this)
 73 2015-12-16T02:36:28  <BlueMatt> sipa: good point
 74 2015-12-16T02:39:14  <morcos> ok hold on catching up on scrollback
 75 2015-12-16T02:39:36  *** PRab has joined #bitcoin-core-dev
 76 2015-12-16T02:41:07  <morcos> BlueMatt: ok first of all i'm not suggesting moving more logic into pool servers.  i 100% agree that bitcoind should on its own provide near optimal mining functionality
 77 2015-12-16T02:41:30  <BlueMatt> morcos: note that I only realized how similar our proposals were after going back and reading what I wrote :)
 78 2015-12-16T02:41:47  <morcos> for your #1, what do you want to interrupt?  90% of CNB is TBV which is mostly ConnectBlock, which is why I asked sipa about interrupting it?
 79 2015-12-16T02:42:23  <morcos> I'm not necessarily opposed to moving all of CNB into a separate thread, but I have two concerns with it, both minor'ish..
 80 2015-12-16T02:43:07  <BlueMatt> honestly I'd love to re-add the during CNB txn validity checks that were removed for 0.12, but I'll leave that one for now...in any case, in this case ConnectBlock only touches its own datastructures, so making it return when a particular flag gets set should be doable
 81 2015-12-16T02:43:14  <BlueMatt> annoying to shove that in ConnectBlock, but, doable
 82 2015-12-16T02:43:24  <BlueMatt> we could do more fucking thread::interruption_points
 83 2015-12-16T02:43:25  <morcos> a) if CNB still acquires cs_main for a lot of time, then busy running it is going to block a lot of other stuff even if somehow new tips can interrupt it, and thats not useful if the mining software isn't getting the new blocks that quickly.   you only need as many new blocks as often as they are going to switch work
 84 2015-12-16T02:44:06  <morcos> b) when you do return work to the miner, its sort of silly to return work that is old by the period of your CNB loop instead of returning it on demand
 85 2015-12-16T02:44:19  <BlueMatt> hmm? I'm confused on a) are you just talking about the other non-new-block shit that locks cs_main?
 86 2015-12-16T02:44:29  <morcos> yes
 87 2015-12-16T02:44:51  <morcos> a lot of the nodes operation does this
 88 2015-12-16T02:45:11  <morcos> acceptToMemoryPool being among the worst offenders
 89 2015-12-16T02:45:35  <BlueMatt> yea, I'm not too worried about that....mostly because the rest of that stuff is very non-latency-critical
 90 2015-12-16T02:45:47  <sipa> accepting new blocks is
 91 2015-12-16T02:45:58  <morcos> BlueMatt: as for your comment about massive mempools or fancy hardware.  CreateNewBlock speed is not related to mempool size, or only just barely.
 92 2015-12-16T02:46:01  <BlueMatt> yea, aside from a new block, nothing is latency-critical
 93 2015-12-16T02:46:21  <BlueMatt> morcos: true, I suppose that is now true...still thinking in a pre-0.12 world :)
 94 2015-12-16T02:46:48  <BlueMatt> morcos: oops, no, you misread my comment, I was suggesting accepting a new block is related to mempool size
 95 2015-12-16T02:46:59  <BlueMatt> which it still is, if you have a completely insanely large mempool
 96 2015-12-16T02:47:11  <sipa> how so?
 97 2015-12-16T02:47:13  <morcos> as for adding back in the tx validity checks.   one of the reasons i was happy to take them out is it would have been just as easy to have an error in how those were applied as have an error in mempool consistency
 98 2015-12-16T02:47:16  <BlueMatt> that plus disk i/o and cache size, and some miners have surprisingly low cache/disk throughput
 99 2015-12-16T02:47:56  <BlueMatt> morcos: in theory, sure, but we've never had a release where mempool was consistent (and we thought it was for many, many releases), but we've never found any issues in the way the txn checks were done in CNB
100 2015-12-16T02:48:22  <morcos> in fact we do have an error in how they are applied already.  0.11 will just has happily build a block that fails TBV as 0.12 when a new soft fork activates
101 2015-12-16T02:48:36  <BlueMatt> going back to your (b) above, meh, I'd much, much rather do that than block and make miners do some kind of crazy hacky solution because of it
102 2015-12-16T02:48:53  <BlueMatt> morcos: oh? do we really? fuck :(
103 2015-12-16T02:49:16  <morcos> BlueMatt: back to b a second.  I'm confused, what are minors doing that you are calling a crazy hacky solution
104 2015-12-16T02:49:16  <sipa> how so?
105 2015-12-16T02:49:34  <sipa> we never accept transactions that violate a future softfork into the mempool
106 2015-12-16T02:49:44  <sipa> even a non-activated one
107 2015-12-16T02:50:05  <BlueMatt> morcos: one major miner who happens to have a reasonable infrastructure has one pool server (with some failover stuff) controlling their hardware....connected to about 5/10 bitcoinds on the backend
108 2015-12-16T02:50:06  <morcos> sipa: oh yeah sorry, i think i meant if you're running wiht non default policy
109 2015-12-16T02:50:25  <BlueMatt> morcos: you have to do that for latency of accepting a new block reasons
110 2015-12-16T02:50:37  <BlueMatt> morcos: but, really, now that I say that, it doesnt really effect what we're talking about :)
111 2015-12-16T02:51:06  <morcos> BlueMatt: exactly.  once you do your number 3, then there is no more benefit to be gained beyond moving TBV out of thread
112 2015-12-16T02:51:32  <BlueMatt> in any case, my thought is really that if you block gbt, pool server implementors are going to have to build smarter software that does things like threading or calling select() instead of being able to be just as effecient as the next guy by just using blocking sockets :)
113 2015-12-16T02:51:37  <morcos> but at this point we're talking micro optimizations.  kind of depedns on how often minors want new work, and how frequently we think running CNB is reasonable.
114 2015-12-16T02:52:02  <sipa> you'd certainly not run CNB in a busy loop
115 2015-12-16T02:52:07  <BlueMatt> yea, we should have a discussion about how often we re-call CNB later
116 2015-12-16T02:52:17  <sipa> that'd interfere greatly with other cs_main lockers
117 2015-12-16T02:52:18  <BlueMatt> probably something related to how many new txn you have in mempool or so
118 2015-12-16T02:52:28  <BlueMatt> but...first lets get the easy stuff in
119 2015-12-16T02:52:30  <morcos> BlueMatt: thats already how it works
120 2015-12-16T02:52:39  <BlueMatt> i thought it currently has a timeout?
121 2015-12-16T02:52:47  <BlueMatt> meh, i havent looked at that code in too long, i guess
122 2015-12-16T02:53:01  <morcos> BlueMatt: yeah maybe it waits the timeout, and then also requires that the # of txs changed
123 2015-12-16T02:53:11  <morcos> but the point is it already has logic like that, tweakign the logic is easy
124 2015-12-16T02:53:26  <BlueMatt> in any case, my thought is really that it is easier to write a pool if calls to gbt never take longer than an ms or two than if they sometimes block
125 2015-12-16T02:53:32  <morcos> but anyway, sounds liek we agree on what we're trying to accomplish
126 2015-12-16T02:53:48  <BlueMatt> really my goal is to make a braindead pool software just as fast as a really smart and overengineered one
127 2015-12-16T02:53:57  <morcos> BlueMatt: ok, well if there is a difference between blocking for 10ms and blocking for 100ms then i agree with you
128 2015-12-16T02:54:31  <morcos> you could assemble the JSON response ahead of time too
129 2015-12-16T02:54:33  <BlueMatt> I mean fuck if I know, but if I'm writing something really braindead, if it blocks for 100ms I have to actually think about what to do, but if its 10 or 1, then I can just do whatever I think of first
130 2015-12-16T02:54:42  <BlueMatt> heh, could do that, too
131 2015-12-16T02:55:12  <morcos> but we should figure out how to interrupt connectblock
132 2015-12-16T02:55:21  <BlueMatt> yea, that sounds painful
133 2015-12-16T02:55:42  <sipa> how about we ship Varnish along with bitcoind to cache the GBT results *ducks*
134 2015-12-16T02:55:44  <morcos> also, we should have connetblock be able to give up its cs_main after connecting inputs and before validating sigs
135 2015-12-16T02:55:47  <BlueMatt> but we can since jamesob was asking for simple tasks, I was trying to avoid scope creep at all costs
136 2015-12-16T02:56:48  <BlueMatt> morcos: yea, that
137 2015-12-16T02:56:59  <sipa>     morcos: yea, that
138 2015-12-16T02:58:16  <morcos> hmm... so for the simple first version
139 2015-12-16T02:58:24  <morcos> 1) empty block template, all agree on that
140 2015-12-16T03:00:03  <morcos> 2) need to not wait on TBV at least.   if we move all of CNB into its own thread...  does it just run on a schedule continuously.   is that close enough to ok...  i guess maybe so..
141 2015-12-16T03:00:04  <BlueMatt> morcos: we used to be able to skip cs_main for the ConnectBlock call at the end to validate because we had a CCoinsViewCache that was filled with txn previns when we ran through and did the validation on each txn
142 2015-12-16T03:00:07  <BlueMatt> now we cant so easily :(
143 2015-12-16T03:00:32  <BlueMatt> (because ConnectBlock's calls to the CCoinsViewCache fall through to pcoinsViewTip since the cache is empty when we start checking validity)
144 2015-12-16T03:00:45  <BlueMatt> oh, nvm
145 2015-12-16T03:00:58  <morcos> one thing i don't like the idea of is waiting say 10 seconds to give a second template with actual txs in it after a new tip
146 2015-12-16T03:01:41  <morcos> if you have that information at T+10ms, it seems crazy to spend 10secs or 30 or 60 building empty blocks
147 2015-12-16T03:01:46  <BlueMatt> <BlueMatt> oh, nvm <-- nope, my previous statements was correct, ignore this comment
148 2015-12-16T03:01:53  <morcos> we have to make sure we get that switchover right
149 2015-12-16T03:02:47  <morcos> yeah i guess this is where i don't understand what pool server software should look like
150 2015-12-16T03:03:09  <morcos> the longpoll idea makes sense to me... b/c bitcoind tells you when hey, here is new info you need
151 2015-12-16T03:03:09  <BlueMatt> agreed
152 2015-12-16T03:03:14  <morcos> vs you having to know when to ask
153 2015-12-16T03:03:21  <morcos> so its by definition blocking for a while
154 2015-12-16T03:03:42  <BlueMatt> I dont think most pool servers use longpolling, because it is often slower or something
155 2015-12-16T03:03:46  <BlueMatt> i dont know why, havent looked into it
156 2015-12-16T03:04:04  <morcos> well thats the question we need to answer
157 2015-12-16T03:04:11  *** Tera2342 has quit IRC
158 2015-12-16T03:04:18  <BlueMatt> as for the switchover, another option is just to tickle the background thread when we realize the block is now out of date
159 2015-12-16T03:04:26  <BlueMatt> lose an extra ms on switching time, but thats fine
160 2015-12-16T03:04:40  <morcos> b/c it seems simpler to me to write braind dead pool software that long polls than pool software that has to figure out itself when it should ask bitcoind for info
161 2015-12-16T03:05:02  <morcos> yes but how does the pool know to ask again
162 2015-12-16T03:05:18  <morcos> is it literally going to busy call gbt and check if it changed?
163 2015-12-16T03:05:29  <BlueMatt> some software does this, yes
164 2015-12-16T03:19:56  *** bitdevsn_ has quit IRC
165 2015-12-16T03:22:07  *** bitdevsnyc has joined #bitcoin-core-dev
166 2015-12-16T03:30:08  *** randy-waterhouse has quit IRC
167 2015-12-16T03:34:02  *** randy-waterhouse has joined #bitcoin-core-dev
168 2015-12-16T03:40:39  *** desantis_ has joined #bitcoin-core-dev
169 2015-12-16T03:42:26  *** desantis has quit IRC
170 2015-12-16T03:42:38  *** desantis_ is now known as desantis
171 2015-12-16T03:44:33  *** zookolaptop has joined #bitcoin-core-dev
172 2015-12-16T03:48:46  *** zookolap` has joined #bitcoin-core-dev
173 2015-12-16T03:49:46  *** zookolaptop has quit IRC
174 2015-12-16T03:50:00  *** desantis_ has joined #bitcoin-core-dev
175 2015-12-16T03:51:24  *** desantis has quit IRC
176 2015-12-16T03:51:25  *** desantis_ is now known as desantis
177 2015-12-16T03:56:48  *** desantis has quit IRC
178 2015-12-16T04:01:55  *** bitdevsnyc has quit IRC
179 2015-12-16T04:02:10  *** desantis has joined #bitcoin-core-dev
180 2015-12-16T04:02:10  *** desantis has quit IRC
181 2015-12-16T04:03:14  *** desantis has joined #bitcoin-core-dev
182 2015-12-16T04:15:44  *** desantis has quit IRC
183 2015-12-16T04:19:25  <btcdrak> morcos: I dont think jamesob saw your messages, says he quit before you replied.
184 2015-12-16T04:21:02  <aj> btcdrak: sorry, i got distracted turning my htlc code into something closer to a working demo; should be up on github today or tomorrow
185 2015-12-16T04:21:28  <btcdrak> aj: thanks!
186 2015-12-16T04:21:50  *** dcousens has joined #bitcoin-core-dev
187 2015-12-16T04:59:25  *** Quent has joined #bitcoin-core-dev
188 2015-12-16T05:14:37  <Luke-Jr> jonasschnelli: meh, may need to find another font still :x
189 2015-12-16T05:16:01  <Luke-Jr> jonasschnelli: reason for generating a custom DS_Store, is that it needs the volume name in it
190 2015-12-16T05:59:12  *** Thireus has joined #bitcoin-core-dev
191 2015-12-16T06:09:10  *** Tera2342 has joined #bitcoin-core-dev
192 2015-12-16T06:24:16  *** Cory has joined #bitcoin-core-dev
193 2015-12-16T06:24:51  <Luke-Jr> fwiw, gentoo testing (not stable) just got GCC 5.3.0
194 2015-12-16T06:48:15  *** zookolap` has quit IRC
195 2015-12-16T06:50:02  <Luke-Jr> found a half-decent public domain font we can use
196 2015-12-16T06:52:55  *** raedah has joined #bitcoin-core-dev
197 2015-12-16T06:58:03  *** Tera2342 has quit IRC
198 2015-12-16T06:59:32  *** raedah has quit IRC
199 2015-12-16T07:22:51  *** Ylbam has joined #bitcoin-core-dev
200 2015-12-16T08:07:54  *** BashCo has quit IRC
201 2015-12-16T08:27:54  *** Tera2342 has joined #bitcoin-core-dev
202 2015-12-16T08:30:50  *** BashCo has joined #bitcoin-core-dev
203 2015-12-16T08:42:28  *** windsok has joined #bitcoin-core-dev
204 2015-12-16T08:49:14  *** Guyver2 has joined #bitcoin-core-dev
205 2015-12-16T08:51:15  <Luke-Jr> jonasschnelli: can you minimally modify the generated DS_Store to work, and post me the working file?
206 2015-12-16T08:52:23  <Luke-Jr> jonasschnelli: (not on your broken SSL server..)
207 2015-12-16T08:53:05  *** Cory has quit IRC
208 2015-12-16T09:28:30  *** randy-waterhouse has quit IRC
209 2015-12-16T10:00:34  *** Squidicuz has quit IRC
210 2015-12-16T10:04:06  *** desantis has joined #bitcoin-core-dev
211 2015-12-16T10:21:26  *** Guyver2 has quit IRC
212 2015-12-16T10:41:02  *** gribble has quit IRC
213 2015-12-16T10:43:37  *** Guyver2 has joined #bitcoin-core-dev
214 2015-12-16T10:56:57  *** dcousens has quit IRC
215 2015-12-16T11:11:56  *** MarcoFalke has joined #bitcoin-core-dev
216 2015-12-16T11:32:06  *** jtimon has quit IRC
217 2015-12-16T11:53:09  <Luke-Jr> hm, maybe I found a trivial bug in RBF logic.. it seems to be checking the replacement pays more fees than the replaced *plus* what would be required of the replacement on its own
218 2015-12-16T11:53:15  <Luke-Jr> rather than what would be required for both..
219 2015-12-16T11:55:05  <Luke-Jr> so if the replaced transaction had 1 BTC in fees, the replacment must have 1 BTC + relayMinimums(replacement), when it might be argued that it ought be relayMinimums(replaced) + relayMinimums(replacement)
220 2015-12-16T11:55:33  <Luke-Jr> thoughts?
221 2015-12-16T11:55:55  <aj> Luke-Jr: the 1BTC already includes relayMinimums(replaced) though?
222 2015-12-16T11:56:09  <MarcoFalke> But relayMinimums(replaced) + relayMinimums(replacement) can be smaller than 1 BTC
223 2015-12-16T11:56:25  <Luke-Jr> ^
224 2015-12-16T11:57:37  <Luke-Jr> so what we really would want is fee(replacement) > max(relayMinimums(replaced)+relayMinimums(replacement), fee(replaced))
225 2015-12-16T11:57:40  <aj> yeah, i thought that was to make RBF deliberately "expensive"
226 2015-12-16T11:58:42  <Luke-Jr> I don't follow..
227 2015-12-16T12:00:15  <Luke-Jr> unless you mean logic-less inflation of RBF costs
228 2015-12-16T12:00:20  <aj> i've seen gmaxwell (iirc) explain it on reddit as RBF having to pay for the cost of replacing both transactions
229 2015-12-16T12:00:30  <aj> i didn't follow why that was a good thing though
230 2015-12-16T12:00:42  <Luke-Jr> oh
231 2015-12-16T12:01:14  <Luke-Jr> if we use rM(repl'd)+rM(repl), we get a DoS attack because they could both be exactly 1 BTC and replace each other
232 2015-12-16T12:01:17  <Luke-Jr> we'd need a +1
233 2015-12-16T12:02:09  <MarcoFalke> It's max(relayMinimums(replaced)+relayMinimums(replacement), fee(replaced) + relayMinimums(replacement))
234 2015-12-16T12:02:30  <MarcoFalke> which is the same as 1 BTC + relayMinimums(replacement)
235 2015-12-16T12:02:42  <MarcoFalke> and you already explained why
236 2015-12-16T12:03:07  <Luke-Jr> I guess max doesn't do what I mean
237 2015-12-16T12:03:17  <Luke-Jr> wait, yes it does
238 2015-12-16T12:03:37  <Luke-Jr> MarcoFalke: it should be max(relayMinimums(replaced)+relayMinimums(replacement), fee(replaced) + 1), no?
239 2015-12-16T12:04:10  <MarcoFalke> what unit is "1"
240 2015-12-16T12:04:20  <MarcoFalke> satoshis?
241 2015-12-16T12:05:42  <Luke-Jr> sure
242 2015-12-16T12:05:51  <Luke-Jr> it just needs to be > to prevent recursion
243 2015-12-16T12:06:15  <GitHub32> [bitcoin] MarcoFalke opened pull request #7218: [qt] Fix misleading translation (master...MarcoFalke-2015-trivial7) https://github.com/bitcoin/bitcoin/pull/7218
244 2015-12-16T12:07:05  <MarcoFalke> Then you can just spend 1 satoshi to transmit whatever your tx size is to the whole network. Sounds like DOS?
245 2015-12-16T12:07:48  <Luke-Jr> MarcoFalke: only if you already paid more than enough in fees
246 2015-12-16T12:08:10  <Luke-Jr> ie, if you overpaid on your initial tx already, you can pay only 1 sat. more for replacement
247 2015-12-16T12:09:01  <aj> Luke-Jr: 2*relayMinimum could still be well below what's being accepted into blocks though?
248 2015-12-16T12:09:05  *** MarcoFalke has quit IRC
249 2015-12-16T12:10:54  <Luke-Jr> aj: I don't see relevance.
250 2015-12-16T12:15:59  <jonasschnelli> Luke-Jr: IIRC, the .DS_Store does link to the filename,.. so, if the filename (App Name) is dynamic, the DS_Store files need also. So you need a script that can generate/modify a DS_Store file.
251 2015-12-16T12:16:02  *** Quent has quit IRC
252 2015-12-16T12:16:12  *** Quent1 has joined #bitcoin-core-dev
253 2015-12-16T12:16:36  <Luke-Jr> jonasschnelli: yes, but I am lost for what the problem is, so analysing a fixed file would possibly help
254 2015-12-16T12:16:59  <jonasschnelli> Luke-Jr: SSL. I testes the Site with Ubuntu 12.04 and 15.04 as well as with a recent Fedora version. I guess the COMODO SSL CA is probably not supported by your OS?
255 2015-12-16T12:17:27  <Luke-Jr> jonasschnelli: it's not a cert error
256 2015-12-16T12:17:29  <jonasschnelli> Luke-Jr: Okay. Right. Makes sense. Will try to create a correct DS_Store
257 2015-12-16T12:17:50  <jonasschnelli> Does your browser/os enforce SSLv2 or v3?
258 2015-12-16T12:18:43  <GitHub128> [bitcoin] luke-jr opened pull request #7219: Make RBF policies optional (master...rbf_opts) https://github.com/bitcoin/bitcoin/pull/7219
259 2015-12-16T12:19:43  <GitHub143> [bitcoin] luke-jr opened pull request #7220: RBF: Allow replacements to pay for minRelayFee(replaced)+minRelayFee(replacement) rather than actualFee(replaced)+minRelayFee(replacement) (master...rbf_feecomp) https://github.com/bitcoin/bitcoin/pull/7220
260 2015-12-16T12:20:04  <Luke-Jr> jonasschnelli: probably?
261 2015-12-16T12:23:12  *** Prattler has quit IRC
262 2015-12-16T12:27:55  * Luke-Jr ponders if wget would work
263 2015-12-16T12:31:09  *** dcousens has joined #bitcoin-core-dev
264 2015-12-16T12:31:35  <jonasschnelli> Luke-Jr: give it a try with `curl -v` (and maybe a `curl -v --insecure`..
265 2015-12-16T12:33:11  <Luke-Jr> hm, got a link handy?
266 2015-12-16T12:33:19  <Luke-Jr> for some reason I am having trouble finding one in my log
267 2015-12-16T12:34:08  <Luke-Jr> found it https://bitcoin.jonasschnelli.ch
268 2015-12-16T12:34:19  <Luke-Jr> nope, curl and wget hate it too
269 2015-12-16T12:34:50  <jonasschnelli> argh. Some system wide problem...
270 2015-12-16T12:34:59  *** laurentmt has joined #bitcoin-core-dev
271 2015-12-16T12:35:18  <Luke-Jr> I don't think curl does SSL at all, just TLS
272 2015-12-16T12:35:44  <Luke-Jr> ooh
273 2015-12-16T12:35:45  *** laurentmt has quit IRC
274 2015-12-16T12:35:56  <Luke-Jr> jonasschnelli: IPv6!
275 2015-12-16T12:36:14  <Luke-Jr> you're only broken on IPv6, not IPv4
276 2015-12-16T12:36:42  <jonasschnelli> Luke-Jr: hmm.. how could
277 2015-12-16T12:36:45  <Luke-Jr> is the IPv6 address correct? ;)
278 2015-12-16T12:36:46  <Luke-Jr> in DNS
279 2015-12-16T12:36:57  <jonasschnelli> buh... no idea... need to check. :)
280 2015-12-16T12:37:02  <Luke-Jr> if not, I'm hitting some random other server :P
281 2015-12-16T12:37:52  * jonasschnelli is reading some IPv6 guides...
282 2015-12-16T12:42:40  *** desantis has quit IRC
283 2015-12-16T12:45:22  *** laurentmt has joined #bitcoin-core-dev
284 2015-12-16T12:46:32  *** desantis has joined #bitcoin-core-dev
285 2015-12-16T12:48:57  <jonasschnelli> Luke-Jr: hmm... IPv6 seems to be set up coorect. dig AAAA bitcoin.jonasschnelli.ch gives me the right answer, .. i can ping6 from another machine (in the same lan although).
286 2015-12-16T12:49:33  <Luke-Jr> I can ping it, just TLS fails
287 2015-12-16T12:55:07  <jonasschnelli> ah... found the issue. Missing apache ipv6 config.
288 2015-12-16T12:55:24  *** laurentmt has quit IRC
289 2015-12-16T12:56:46  <Luke-Jr> XD
290 2015-12-16T12:56:49  *** afk11 has joined #bitcoin-core-dev
291 2015-12-16T12:56:55  <Luke-Jr> works now
292 2015-12-16T12:57:13  <jonasschnelli> Luke-Jr: works? Perfect!
293 2015-12-16T13:00:25  *** dcousens has quit IRC
294 2015-12-16T13:12:54  <Luke-Jr> jonasschnelli: Our scheme looks more (not everywhere) after full length parameters/commands (we use createrawtransaction instead of createrawtx, etc.). <-- more what? O.o
295 2015-12-16T13:13:54  <jonasschnelli> Luke-Jr: things like '-limitfreerelay', or -stopafterblockimport or -permitbaremultisig
296 2015-12-16T13:14:14  <jonasschnelli> But right, there are also things like: acceptnonstdtxn
297 2015-12-16T13:14:27  <Luke-Jr> more examples don't help; the sentence is missing an adjective :p
298 2015-12-16T13:14:31  <jonasschnelli> but replacebyfee is relatively short.
299 2015-12-16T13:15:08  <Luke-Jr> "Our scheme looks more after full length … " doesn't parse <.<
300 2015-12-16T13:15:27  <jonasschnelli> Don't judge my english..,.  (or i gonna judge your german). But I know, my english lacks here and there. :)
301 2015-12-16T13:15:39  *** dcousens has joined #bitcoin-core-dev
302 2015-12-16T13:15:42  <Luke-Jr> ok, but I don't know what it means :<
303 2015-12-16T13:16:03  *** dcousens has quit IRC
304 2015-12-16T13:16:18  <jonasschnelli> I was trying to say, our command line arguments and rpc commands are mostly "full names" instead of abbreviations.
305 2015-12-16T13:18:50  <Luke-Jr> ah
306 2015-12-16T13:33:06  *** evoskuil has quit IRC
307 2015-12-16T13:33:40  <GitHub62> [bitcoin] parazyd opened pull request #7221: Merge pull request #1 from bitcoin/master (master...master) https://github.com/bitcoin/bitcoin/pull/7221
308 2015-12-16T13:34:15  <GitHub110> [bitcoin] parazyd closed pull request #7221: Merge pull request #1 from bitcoin/master (master...master) https://github.com/bitcoin/bitcoin/pull/7221
309 2015-12-16T13:49:48  *** evoskuil has joined #bitcoin-core-dev
310 2015-12-16T13:58:57  *** MarcoFalke has joined #bitcoin-core-dev
311 2015-12-16T14:12:44  *** Tera2342 has quit IRC
312 2015-12-16T14:26:02  <MarcoFalke> > Luke-Jr
313 2015-12-16T14:26:02  <MarcoFalke> MarcoFalke: only if you already paid more than enough in fees
314 2015-12-16T14:26:11  <MarcoFalke> For one transaction, that is.
315 2015-12-16T14:26:36  <MarcoFalke> But the network has to process every rbf tx
316 2015-12-16T14:27:16  <MarcoFalke> Just think about the "strss-test" in August
317 2015-12-16T14:27:35  <MarcoFalke> rbf with your logic would make it a lot cheaper
318 2015-12-16T14:32:23  *** dcousens has joined #bitcoin-core-dev
319 2015-12-16T14:38:49  <MarcoFalke> jonasschnelli, theoretically you could also change gui settings without the gui
320 2015-12-16T14:39:45  <jonasschnelli> MarcoFalke: how?
321 2015-12-16T14:39:50  <gijensen> PR 7220 Is it heavy to consider all TXs that were replaced in the chain up until the first TX with an RBF flag that didn't get replaced? That's the only solution I see to morco's NACK
322 2015-12-16T14:46:34  <MarcoFalke> In the registry and stuff, but "GUI settings" is not true as well. I will just use your suggestion.
323 2015-12-16T14:47:45  <jonasschnelli> MarcoFalke: Hm... sure, you can change everything by accessing the right space on your OS. I still think "GUI settings" is the right name.
324 2015-12-16T15:11:05  *** gribble has joined #bitcoin-core-dev
325 2015-12-16T15:18:34  *** MarcoFalke has quit IRC
326 2015-12-16T15:20:20  *** jgarzik has joined #bitcoin-core-dev
327 2015-12-16T15:20:20  *** jgarzik has joined #bitcoin-core-dev
328 2015-12-16T15:20:58  *** adam3us has joined #bitcoin-core-dev
329 2015-12-16T15:40:31  *** Squidicuz has joined #bitcoin-core-dev
330 2015-12-16T15:58:54  *** zookolaptop has joined #bitcoin-core-dev
331 2015-12-16T16:03:31  *** zookolaptop has quit IRC
332 2015-12-16T16:13:36  *** treehug88 has joined #bitcoin-core-dev
333 2015-12-16T16:14:49  *** sotisoti has joined #bitcoin-core-dev
334 2015-12-16T16:16:35  *** afk11 has quit IRC
335 2015-12-16T16:25:36  *** zookolaptop has joined #bitcoin-core-dev
336 2015-12-16T16:39:23  *** Prattler has joined #bitcoin-core-dev
337 2015-12-16T16:50:47  <helo> someone familiar with p2pool code may want to take a look at KipIngram's messages in #bitcoin
338 2015-12-16T17:03:19  *** dcousens has quit IRC
339 2015-12-16T17:22:52  *** rgergre has joined #bitcoin-core-dev
340 2015-12-16T17:24:36  *** rgergre has quit IRC
341 2015-12-16T17:39:55  *** jgarzik has left #bitcoin-core-dev
342 2015-12-16T17:40:12  *** jgarzik has joined #bitcoin-core-dev
343 2015-12-16T17:40:12  *** jgarzik has joined #bitcoin-core-dev
344 2015-12-16T17:52:09  *** jannes has joined #bitcoin-core-dev
345 2015-12-16T17:53:33  *** desantis has quit IRC
346 2015-12-16T17:54:15  *** wangchun has quit IRC
347 2015-12-16T17:54:33  *** wangchun has joined #bitcoin-core-dev
348 2015-12-16T18:06:46  *** treehug88 has quit IRC
349 2015-12-16T18:31:02  <GitHub4> [bitcoin] luke-jr closed pull request #7220: RBF: Allow replacements to pay for minRelayFee(replaced)+minRelayFee(replacement) rather than actualFee(replaced)+minRelayFee(replacement) (master...rbf_feecomp) https://github.com/bitcoin/bitcoin/pull/7220
350 2015-12-16T18:32:26  *** evoskuil has quit IRC
351 2015-12-16T18:37:44  <morcos> Am I allowed to store a reference to chainparams?
352 2015-12-16T18:38:40  <morcos> In particular refactoring CreateNewBlock to be a class needs access to chainparams, can i just pass it in as a reference on construction and access it whenever after that point?
353 2015-12-16T18:39:10  *** gmaxwell has left #bitcoin-core-dev
354 2015-12-16T18:39:30  <sipa> imho yes
355 2015-12-16T18:45:39  *** evoskuil has joined #bitcoin-core-dev
356 2015-12-16T18:52:45  *** zookolaptop has quit IRC
357 2015-12-16T18:53:14  *** Prattler has quit IRC
358 2015-12-16T18:53:46  *** evoskuil has quit IRC
359 2015-12-16T18:57:43  *** zookolaptop has joined #bitcoin-core-dev
360 2015-12-16T19:06:00  *** jtimon has joined #bitcoin-core-dev
361 2015-12-16T19:09:24  *** Cory has joined #bitcoin-core-dev
362 2015-12-16T19:13:28  *** helo has quit IRC
363 2015-12-16T19:13:42  *** helo has joined #bitcoin-core-dev
364 2015-12-16T19:27:45  *** evoskuil has joined #bitcoin-core-dev
365 2015-12-16T19:47:04  *** treehug88 has joined #bitcoin-core-dev
366 2015-12-16T19:56:08  *** jtimon has quit IRC
367 2015-12-16T20:06:35  <GitHub68> [bitcoin] sdaftuar opened pull request #7222: [WIP] RPC: Indicate which transactions are signaling opt-in RBF (master...add-optin-info) https://github.com/bitcoin/bitcoin/pull/7222
368 2015-12-16T20:09:16  *** laurentmt has joined #bitcoin-core-dev
369 2015-12-16T20:13:06  <gijensen> Luke-jr, PR 7220 for my sanity, you closed it because it doesn't cache the minimums (so the proper min can't be calculated)? That's what I thought but two other people disagreed with me :S
370 2015-12-16T21:25:17  *** treehug88 has quit IRC
371 2015-12-16T21:26:46  *** zookolaptop has quit IRC
372 2015-12-16T21:27:58  *** jannes has quit IRC
373 2015-12-16T21:44:39  *** Guyver2 has quit IRC
374 2015-12-16T21:49:20  *** laurentmt has quit IRC
375 2015-12-16T21:55:06  *** d_t has joined #bitcoin-core-dev
376 2015-12-16T22:05:50  <Luke-Jr> gijensen: ?
377 2015-12-16T22:08:41  <gijensen> Luke-Jr I'm just asking for clarity on the comments previous to your final one. I was trying to convey the issue is the PR as is didn't account for all the minimum fees of past transactions. Is that correct, or no?
378 2015-12-16T22:09:53  <gijensen> You mentioned a cache, so that made me believe I'm correct. I just want to know to be sure I properly understand what's happening.
379 2015-12-16T22:17:01  <Luke-Jr> yes, if A is replaced by B, and C might replace B, we need C to pay for A+B+C, but we no longer have A
380 2015-12-16T22:18:13  <gijensen> Thank you!
381 2015-12-16T22:18:24  <Luke-Jr> so to fix this, we would need to store the size of A (and anything it replaced) with B
382 2015-12-16T22:19:24  <Luke-Jr> nTotalRelaySize or smth
383 2015-12-16T22:20:01  <gijensen> Okay, yes I understand completely. Do you still plan on trying to work on the concept? Or just axe it for now?
384 2015-12-16T22:23:14  *** zookolaptop has joined #bitcoin-core-dev
385 2015-12-16T22:23:23  <Luke-Jr> I think the benefits do not outweigh the costs now
386 2015-12-16T22:29:41  <gijensen> I was worried about that, okay
387 2015-12-16T22:55:53  *** arubi has quit IRC
388 2015-12-16T22:56:28  *** arubi has joined #bitcoin-core-dev
389 2015-12-16T22:58:03  *** arubi has quit IRC
390 2015-12-16T22:58:25  *** arubi has joined #bitcoin-core-dev
391 2015-12-16T23:00:02  *** jtimon has joined #bitcoin-core-dev
392 2015-12-16T23:01:10  *** arubi has quit IRC
393 2015-12-16T23:02:02  *** arubi has joined #bitcoin-core-dev