12015-12-16T00:14:50  *** Tera2342 has joined #bitcoin-core-dev
  22015-12-16T00:17:25  *** desantis has joined #bitcoin-core-dev
  32015-12-16T00:22:06  *** Tera2342 has quit IRC
  42015-12-16T00:34:23  <morcos> jamesob: i'm also working on CNB improvements right now
  52015-12-16T00:34:48  <morcos> however the background threading was further down my list, so perhaps we can coordinate our work to some degree
  62015-12-16T00:35:10  <morcos> right now i'm refactoring CNB into a class (i should have just done that last time)
  72015-12-16T00:37:29  *** Thireus has quit IRC
  82015-12-16T00:39:06  *** raedah has quit IRC
  92015-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.
 102015-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:
 112015-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)
 122015-12-16T00:43:10  <morcos> 2) returning a template based on no txs after a new tip
 132015-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
 142015-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
 152015-12-16T00:45:36  <morcos> sipa: i suppose that's true.
 162015-12-16T00:46:03  *** tripleslash has quit IRC
 172015-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
 182015-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
 192015-12-16T00:47:00  <morcos> and then can work just as well or even better in the same thread
 202015-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
 212015-12-16T00:47:45  *** moli has quit IRC
 222015-12-16T00:47:54  <morcos> i mean it really already is a "background" thread
 232015-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
 242015-12-16T00:49:08  *** moli has joined #bitcoin-core-dev
 252015-12-16T00:50:12  *** laurentmt has joined #bitcoin-core-dev
 262015-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
 272015-12-16T00:50:45  *** laurentmt has quit IRC
 282015-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.
 292015-12-16T01:04:38  *** Tera2342 has joined #bitcoin-core-dev
 302015-12-16T01:23:06  *** Quent has quit IRC
 312015-12-16T01:37:26  *** Cory has quit IRC
 322015-12-16T01:41:29  *** Ylbam has quit IRC
 332015-12-16T01:58:20  *** desantis has left #bitcoin-core-dev
 342015-12-16T02:10:49  *** desantis has joined #bitcoin-core-dev
 352015-12-16T02:11:36  *** desantis has left #bitcoin-core-dev
 362015-12-16T02:12:47  *** desantis has joined #bitcoin-core-dev
 372015-12-16T02:13:26  *** belcher has quit IRC
 382015-12-16T02:13:46  *** desantis has left #bitcoin-core-dev
 392015-12-16T02:14:46  *** desantis has joined #bitcoin-core-dev
 402015-12-16T02:15:39  *** desantis has quit IRC
 412015-12-16T02:15:57  *** desantis has joined #bitcoin-core-dev
 422015-12-16T02:16:17  *** desantis has quit IRC
 432015-12-16T02:16:35  *** desantis has joined #bitcoin-core-dev
 442015-12-16T02:25:09  <BlueMatt> morcos: please do not further complicate getblocktemplate
 452015-12-16T02:25:19  <BlueMatt> we want to move complexity out of pool servers and into bitcoind, not the other way around
 462015-12-16T02:25:44  <BlueMatt> (pool servers are largely bit proprietary blobs that get essentially no external review, whereas bitcoin core is....not that)
 472015-12-16T02:27:05  <sipa> morcos: i'd rather just not always call TBV... *ducks*
 482015-12-16T02:27:16  <BlueMatt> sipa: noooooooooooooooooo
 492015-12-16T02:27:25  <BlueMatt> that shit has been so broken up until literally the latest release
 502015-12-16T02:27:32  <BlueMatt> there is no way in hell we should remove that check
 512015-12-16T02:27:40  <sipa> i am not saying remove it
 522015-12-16T02:28:01  <sipa> but just call it 1% or 10% of the time or so
 532015-12-16T02:28:10  <sipa> it's there to detect software bugs
 542015-12-16T02:28:18  <sipa> it's not there to prevent incorrect responses
 552015-12-16T02:28:34  <BlueMatt> sipa: it is absolutely there to prevent incorrect responses
 562015-12-16T02:28:45  <BlueMatt> up until the latest release there were known bugs which made it required
 572015-12-16T02:28:57  <BlueMatt> (well assuming you dont check txn as you go, which we now dont)
 582015-12-16T02:28:58  <sipa> ... and cause the software to crash?
 592015-12-16T02:29:04  <sipa> it's an assert
 602015-12-16T02:29:10  <BlueMatt> it isnt anymore
 612015-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
 622015-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)
 632015-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.
 642015-12-16T02:34:05  <BlueMatt> 3) return an empty block if the current block template we have is not based on the tip
 652015-12-16T02:34:25  <BlueMatt> 3 should be a trivial change, and 1 and 2 should be pretty easily-reviewable code
 662015-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
 672015-12-16T02:35:46  *** PRab has quit IRC
 682015-12-16T02:35:51  <sipa> 3) means that the update new tip code should also briefly lock the CNB cached value and wipe it
 692015-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
 702015-12-16T02:36:09  <BlueMatt> all of CNB should be there, getblocktemplate should never block
 712015-12-16T02:36:20  <sipa> otherwise GBT needs to grab cs_main to determine whether the tip changed
 722015-12-16T02:36:27  <sipa> (not a problem; just realizing this)
 732015-12-16T02:36:28  <BlueMatt> sipa: good point
 742015-12-16T02:39:14  <morcos> ok hold on catching up on scrollback
 752015-12-16T02:39:36  *** PRab has joined #bitcoin-core-dev
 762015-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
 772015-12-16T02:41:30  <BlueMatt> morcos: note that I only realized how similar our proposals were after going back and reading what I wrote :)
 782015-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?
 792015-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..
 802015-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
 812015-12-16T02:43:14  <BlueMatt> annoying to shove that in ConnectBlock, but, doable
 822015-12-16T02:43:24  <BlueMatt> we could do more fucking thread::interruption_points
 832015-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
 842015-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
 852015-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?
 862015-12-16T02:44:29  <morcos> yes
 872015-12-16T02:44:51  <morcos> a lot of the nodes operation does this
 882015-12-16T02:45:11  <morcos> acceptToMemoryPool being among the worst offenders
 892015-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
 902015-12-16T02:45:47  <sipa> accepting new blocks is
 912015-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.
 922015-12-16T02:46:01  <BlueMatt> yea, aside from a new block, nothing is latency-critical
 932015-12-16T02:46:21  <BlueMatt> morcos: true, I suppose that is now true...still thinking in a pre-0.12 world :)
 942015-12-16T02:46:48  <BlueMatt> morcos: oops, no, you misread my comment, I was suggesting accepting a new block is related to mempool size
 952015-12-16T02:46:59  <BlueMatt> which it still is, if you have a completely insanely large mempool
 962015-12-16T02:47:11  <sipa> how so?
 972015-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
 982015-12-16T02:47:16  <BlueMatt> that plus disk i/o and cache size, and some miners have surprisingly low cache/disk throughput
 992015-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
1002015-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
1012015-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
1022015-12-16T02:48:53  <BlueMatt> morcos: oh? do we really? fuck :(
1032015-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
1042015-12-16T02:49:16  <sipa> how so?
1052015-12-16T02:49:34  <sipa> we never accept transactions that violate a future softfork into the mempool
1062015-12-16T02:49:44  <sipa> even a non-activated one
1072015-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
1082015-12-16T02:50:06  <morcos> sipa: oh yeah sorry, i think i meant if you're running wiht non default policy
1092015-12-16T02:50:25  <BlueMatt> morcos: you have to do that for latency of accepting a new block reasons
1102015-12-16T02:50:37  <BlueMatt> morcos: but, really, now that I say that, it doesnt really effect what we're talking about :)
1112015-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
1122015-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 :)
1132015-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.
1142015-12-16T02:52:02  <sipa> you'd certainly not run CNB in a busy loop
1152015-12-16T02:52:07  <BlueMatt> yea, we should have a discussion about how often we re-call CNB later
1162015-12-16T02:52:17  <sipa> that'd interfere greatly with other cs_main lockers
1172015-12-16T02:52:18  <BlueMatt> probably something related to how many new txn you have in mempool or so
1182015-12-16T02:52:28  <BlueMatt> but...first lets get the easy stuff in
1192015-12-16T02:52:30  <morcos> BlueMatt: thats already how it works
1202015-12-16T02:52:39  <BlueMatt> i thought it currently has a timeout?
1212015-12-16T02:52:47  <BlueMatt> meh, i havent looked at that code in too long, i guess
1222015-12-16T02:53:01  <morcos> BlueMatt: yeah maybe it waits the timeout, and then also requires that the # of txs changed
1232015-12-16T02:53:11  <morcos> but the point is it already has logic like that, tweakign the logic is easy
1242015-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
1252015-12-16T02:53:32  <morcos> but anyway, sounds liek we agree on what we're trying to accomplish
1262015-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
1272015-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
1282015-12-16T02:54:31  <morcos> you could assemble the JSON response ahead of time too
1292015-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
1302015-12-16T02:54:42  <BlueMatt> heh, could do that, too
1312015-12-16T02:55:12  <morcos> but we should figure out how to interrupt connectblock
1322015-12-16T02:55:21  <BlueMatt> yea, that sounds painful
1332015-12-16T02:55:42  <sipa> how about we ship Varnish along with bitcoind to cache the GBT results *ducks*
1342015-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
1352015-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
1362015-12-16T02:56:48  <BlueMatt> morcos: yea, that
1372015-12-16T02:56:59  <sipa>     morcos: yea, that
1382015-12-16T02:58:16  <morcos> hmm... so for the simple first version
1392015-12-16T02:58:24  <morcos> 1) empty block template, all agree on that
1402015-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..
1412015-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
1422015-12-16T03:00:07  <BlueMatt> now we cant so easily :(
1432015-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)
1442015-12-16T03:00:45  <BlueMatt> oh, nvm
1452015-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
1462015-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
1472015-12-16T03:01:46  <BlueMatt> <BlueMatt> oh, nvm <-- nope, my previous statements was correct, ignore this comment
1482015-12-16T03:01:53  <morcos> we have to make sure we get that switchover right
1492015-12-16T03:02:47  <morcos> yeah i guess this is where i don't understand what pool server software should look like
1502015-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
1512015-12-16T03:03:09  <BlueMatt> agreed
1522015-12-16T03:03:14  <morcos> vs you having to know when to ask
1532015-12-16T03:03:21  <morcos> so its by definition blocking for a while
1542015-12-16T03:03:42  <BlueMatt> I dont think most pool servers use longpolling, because it is often slower or something
1552015-12-16T03:03:46  <BlueMatt> i dont know why, havent looked into it
1562015-12-16T03:04:04  <morcos> well thats the question we need to answer
1572015-12-16T03:04:11  *** Tera2342 has quit IRC
1582015-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
1592015-12-16T03:04:26  <BlueMatt> lose an extra ms on switching time, but thats fine
1602015-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
1612015-12-16T03:05:02  <morcos> yes but how does the pool know to ask again
1622015-12-16T03:05:18  <morcos> is it literally going to busy call gbt and check if it changed?
1632015-12-16T03:05:29  <BlueMatt> some software does this, yes
1642015-12-16T03:19:56  *** bitdevsn_ has quit IRC
1652015-12-16T03:22:07  *** bitdevsnyc has joined #bitcoin-core-dev
1662015-12-16T03:30:08  *** randy-waterhouse has quit IRC
1672015-12-16T03:34:02  *** randy-waterhouse has joined #bitcoin-core-dev
1682015-12-16T03:40:39  *** desantis_ has joined #bitcoin-core-dev
1692015-12-16T03:42:26  *** desantis has quit IRC
1702015-12-16T03:42:38  *** desantis_ is now known as desantis
1712015-12-16T03:44:33  *** zookolaptop has joined #bitcoin-core-dev
1722015-12-16T03:48:46  *** zookolap` has joined #bitcoin-core-dev
1732015-12-16T03:49:46  *** zookolaptop has quit IRC
1742015-12-16T03:50:00  *** desantis_ has joined #bitcoin-core-dev
1752015-12-16T03:51:24  *** desantis has quit IRC
1762015-12-16T03:51:25  *** desantis_ is now known as desantis
1772015-12-16T03:56:48  *** desantis has quit IRC
1782015-12-16T04:01:55  *** bitdevsnyc has quit IRC
1792015-12-16T04:02:10  *** desantis has joined #bitcoin-core-dev
1802015-12-16T04:02:10  *** desantis has quit IRC
1812015-12-16T04:03:14  *** desantis has joined #bitcoin-core-dev
1822015-12-16T04:15:44  *** desantis has quit IRC
1832015-12-16T04:19:25  <btcdrak> morcos: I dont think jamesob saw your messages, says he quit before you replied.
1842015-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
1852015-12-16T04:21:28  <btcdrak> aj: thanks!
1862015-12-16T04:21:50  *** dcousens has joined #bitcoin-core-dev
1872015-12-16T04:59:25  *** Quent has joined #bitcoin-core-dev
1882015-12-16T05:14:37  <Luke-Jr> jonasschnelli: meh, may need to find another font still :x
1892015-12-16T05:16:01  <Luke-Jr> jonasschnelli: reason for generating a custom DS_Store, is that it needs the volume name in it
1902015-12-16T05:59:12  *** Thireus has joined #bitcoin-core-dev
1912015-12-16T06:09:10  *** Tera2342 has joined #bitcoin-core-dev
1922015-12-16T06:24:16  *** Cory has joined #bitcoin-core-dev
1932015-12-16T06:24:51  <Luke-Jr> fwiw, gentoo testing (not stable) just got GCC 5.3.0
1942015-12-16T06:48:15  *** zookolap` has quit IRC
1952015-12-16T06:50:02  <Luke-Jr> found a half-decent public domain font we can use
1962015-12-16T06:52:55  *** raedah has joined #bitcoin-core-dev
1972015-12-16T06:58:03  *** Tera2342 has quit IRC
1982015-12-16T06:59:32  *** raedah has quit IRC
1992015-12-16T07:22:51  *** Ylbam has joined #bitcoin-core-dev
2002015-12-16T08:07:54  *** BashCo has quit IRC
2012015-12-16T08:27:54  *** Tera2342 has joined #bitcoin-core-dev
2022015-12-16T08:30:50  *** BashCo has joined #bitcoin-core-dev
2032015-12-16T08:42:28  *** windsok has joined #bitcoin-core-dev
2042015-12-16T08:49:14  *** Guyver2 has joined #bitcoin-core-dev
2052015-12-16T08:51:15  <Luke-Jr> jonasschnelli: can you minimally modify the generated DS_Store to work, and post me the working file?
2062015-12-16T08:52:23  <Luke-Jr> jonasschnelli: (not on your broken SSL server..)
2072015-12-16T08:53:05  *** Cory has quit IRC
2082015-12-16T09:28:30  *** randy-waterhouse has quit IRC
2092015-12-16T10:00:34  *** Squidicuz has quit IRC
2102015-12-16T10:04:06  *** desantis has joined #bitcoin-core-dev
2112015-12-16T10:21:26  *** Guyver2 has quit IRC
2122015-12-16T10:41:02  *** gribble has quit IRC
2132015-12-16T10:43:37  *** Guyver2 has joined #bitcoin-core-dev
2142015-12-16T10:56:57  *** dcousens has quit IRC
2152015-12-16T11:11:56  *** MarcoFalke has joined #bitcoin-core-dev
2162015-12-16T11:32:06  *** jtimon has quit IRC
2172015-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
2182015-12-16T11:53:15  <Luke-Jr> rather than what would be required for both..
2192015-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)
2202015-12-16T11:55:33  <Luke-Jr> thoughts?
2212015-12-16T11:55:55  <aj> Luke-Jr: the 1BTC already includes relayMinimums(replaced) though?
2222015-12-16T11:56:09  <MarcoFalke> But relayMinimums(replaced) + relayMinimums(replacement) can be smaller than 1 BTC
2232015-12-16T11:56:25  <Luke-Jr> ^
2242015-12-16T11:57:37  <Luke-Jr> so what we really would want is fee(replacement) > max(relayMinimums(replaced)+relayMinimums(replacement), fee(replaced))
2252015-12-16T11:57:40  <aj> yeah, i thought that was to make RBF deliberately "expensive"
2262015-12-16T11:58:42  <Luke-Jr> I don't follow..
2272015-12-16T12:00:15  <Luke-Jr> unless you mean logic-less inflation of RBF costs
2282015-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
2292015-12-16T12:00:30  <aj> i didn't follow why that was a good thing though
2302015-12-16T12:00:42  <Luke-Jr> oh
2312015-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
2322015-12-16T12:01:17  <Luke-Jr> we'd need a +1
2332015-12-16T12:02:09  <MarcoFalke> It's max(relayMinimums(replaced)+relayMinimums(replacement), fee(replaced) + relayMinimums(replacement))
2342015-12-16T12:02:30  <MarcoFalke> which is the same as 1 BTC + relayMinimums(replacement)
2352015-12-16T12:02:42  <MarcoFalke> and you already explained why
2362015-12-16T12:03:07  <Luke-Jr> I guess max doesn't do what I mean
2372015-12-16T12:03:17  <Luke-Jr> wait, yes it does
2382015-12-16T12:03:37  <Luke-Jr> MarcoFalke: it should be max(relayMinimums(replaced)+relayMinimums(replacement), fee(replaced) + 1), no?
2392015-12-16T12:04:10  <MarcoFalke> what unit is "1"
2402015-12-16T12:04:20  <MarcoFalke> satoshis?
2412015-12-16T12:05:42  <Luke-Jr> sure
2422015-12-16T12:05:51  <Luke-Jr> it just needs to be > to prevent recursion
2432015-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
2442015-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?
2452015-12-16T12:07:48  <Luke-Jr> MarcoFalke: only if you already paid more than enough in fees
2462015-12-16T12:08:10  <Luke-Jr> ie, if you overpaid on your initial tx already, you can pay only 1 sat. more for replacement
2472015-12-16T12:09:01  <aj> Luke-Jr: 2*relayMinimum could still be well below what's being accepted into blocks though?
2482015-12-16T12:09:05  *** MarcoFalke has quit IRC
2492015-12-16T12:10:54  <Luke-Jr> aj: I don't see relevance.
2502015-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.
2512015-12-16T12:16:02  *** Quent has quit IRC
2522015-12-16T12:16:12  *** Quent1 has joined #bitcoin-core-dev
2532015-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
2542015-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?
2552015-12-16T12:17:27  <Luke-Jr> jonasschnelli: it's not a cert error
2562015-12-16T12:17:29  <jonasschnelli> Luke-Jr: Okay. Right. Makes sense. Will try to create a correct DS_Store
2572015-12-16T12:17:50  <jonasschnelli> Does your browser/os enforce SSLv2 or v3?
2582015-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
2592015-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
2602015-12-16T12:20:04  <Luke-Jr> jonasschnelli: probably?
2612015-12-16T12:23:12  *** Prattler has quit IRC
2622015-12-16T12:27:55  * Luke-Jr ponders if wget would work
2632015-12-16T12:31:09  *** dcousens has joined #bitcoin-core-dev
2642015-12-16T12:31:35  <jonasschnelli> Luke-Jr: give it a try with `curl -v` (and maybe a `curl -v --insecure`..
2652015-12-16T12:33:11  <Luke-Jr> hm, got a link handy?
2662015-12-16T12:33:19  <Luke-Jr> for some reason I am having trouble finding one in my log
2672015-12-16T12:34:08  <Luke-Jr> found it https://bitcoin.jonasschnelli.ch
2682015-12-16T12:34:19  <Luke-Jr> nope, curl and wget hate it too
2692015-12-16T12:34:50  <jonasschnelli> argh. Some system wide problem...
2702015-12-16T12:34:59  *** laurentmt has joined #bitcoin-core-dev
2712015-12-16T12:35:18  <Luke-Jr> I don't think curl does SSL at all, just TLS
2722015-12-16T12:35:44  <Luke-Jr> ooh
2732015-12-16T12:35:45  *** laurentmt has quit IRC
2742015-12-16T12:35:56  <Luke-Jr> jonasschnelli: IPv6!
2752015-12-16T12:36:14  <Luke-Jr> you're only broken on IPv6, not IPv4
2762015-12-16T12:36:42  <jonasschnelli> Luke-Jr: hmm.. how could
2772015-12-16T12:36:45  <Luke-Jr> is the IPv6 address correct? ;)
2782015-12-16T12:36:46  <Luke-Jr> in DNS
2792015-12-16T12:36:57  <jonasschnelli> buh... no idea... need to check. :)
2802015-12-16T12:37:02  <Luke-Jr> if not, I'm hitting some random other server :P
2812015-12-16T12:37:52  * jonasschnelli is reading some IPv6 guides...
2822015-12-16T12:42:40  *** desantis has quit IRC
2832015-12-16T12:45:22  *** laurentmt has joined #bitcoin-core-dev
2842015-12-16T12:46:32  *** desantis has joined #bitcoin-core-dev
2852015-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).
2862015-12-16T12:49:33  <Luke-Jr> I can ping it, just TLS fails
2872015-12-16T12:55:07  <jonasschnelli> ah... found the issue. Missing apache ipv6 config.
2882015-12-16T12:55:24  *** laurentmt has quit IRC
2892015-12-16T12:56:46  <Luke-Jr> XD
2902015-12-16T12:56:49  *** afk11 has joined #bitcoin-core-dev
2912015-12-16T12:56:55  <Luke-Jr> works now
2922015-12-16T12:57:13  <jonasschnelli> Luke-Jr: works? Perfect!
2932015-12-16T13:00:25  *** dcousens has quit IRC
2942015-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
2952015-12-16T13:13:54  <jonasschnelli> Luke-Jr: things like '-limitfreerelay', or -stopafterblockimport or -permitbaremultisig
2962015-12-16T13:14:14  <jonasschnelli> But right, there are also things like: acceptnonstdtxn
2972015-12-16T13:14:27  <Luke-Jr> more examples don't help; the sentence is missing an adjective :p
2982015-12-16T13:14:31  <jonasschnelli> but replacebyfee is relatively short.
2992015-12-16T13:15:08  <Luke-Jr> "Our scheme looks more after full length … " doesn't parse <.<
3002015-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. :)
3012015-12-16T13:15:39  *** dcousens has joined #bitcoin-core-dev
3022015-12-16T13:15:42  <Luke-Jr> ok, but I don't know what it means :<
3032015-12-16T13:16:03  *** dcousens has quit IRC
3042015-12-16T13:16:18  <jonasschnelli> I was trying to say, our command line arguments and rpc commands are mostly "full names" instead of abbreviations.
3052015-12-16T13:18:50  <Luke-Jr> ah
3062015-12-16T13:33:06  *** evoskuil has quit IRC
3072015-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
3082015-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
3092015-12-16T13:49:48  *** evoskuil has joined #bitcoin-core-dev
3102015-12-16T13:58:57  *** MarcoFalke has joined #bitcoin-core-dev
3112015-12-16T14:12:44  *** Tera2342 has quit IRC
3122015-12-16T14:26:02  <MarcoFalke> > Luke-Jr
3132015-12-16T14:26:02  <MarcoFalke> MarcoFalke: only if you already paid more than enough in fees
3142015-12-16T14:26:11  <MarcoFalke> For one transaction, that is.
3152015-12-16T14:26:36  <MarcoFalke> But the network has to process every rbf tx
3162015-12-16T14:27:16  <MarcoFalke> Just think about the "strss-test" in August
3172015-12-16T14:27:35  <MarcoFalke> rbf with your logic would make it a lot cheaper
3182015-12-16T14:32:23  *** dcousens has joined #bitcoin-core-dev
3192015-12-16T14:38:49  <MarcoFalke> jonasschnelli, theoretically you could also change gui settings without the gui
3202015-12-16T14:39:45  <jonasschnelli> MarcoFalke: how?
3212015-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
3222015-12-16T14:46:34  <MarcoFalke> In the registry and stuff, but "GUI settings" is not true as well. I will just use your suggestion.
3232015-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.
3242015-12-16T15:11:05  *** gribble has joined #bitcoin-core-dev
3252015-12-16T15:18:34  *** MarcoFalke has quit IRC
3262015-12-16T15:20:20  *** jgarzik has joined #bitcoin-core-dev
3272015-12-16T15:20:20  *** jgarzik has joined #bitcoin-core-dev
3282015-12-16T15:20:58  *** adam3us has joined #bitcoin-core-dev
3292015-12-16T15:40:31  *** Squidicuz has joined #bitcoin-core-dev
3302015-12-16T15:58:54  *** zookolaptop has joined #bitcoin-core-dev
3312015-12-16T16:03:31  *** zookolaptop has quit IRC
3322015-12-16T16:13:36  *** treehug88 has joined #bitcoin-core-dev
3332015-12-16T16:14:49  *** sotisoti has joined #bitcoin-core-dev
3342015-12-16T16:16:35  *** afk11 has quit IRC
3352015-12-16T16:25:36  *** zookolaptop has joined #bitcoin-core-dev
3362015-12-16T16:39:23  *** Prattler has joined #bitcoin-core-dev
3372015-12-16T16:50:47  <helo> someone familiar with p2pool code may want to take a look at KipIngram's messages in #bitcoin
3382015-12-16T17:03:19  *** dcousens has quit IRC
3392015-12-16T17:22:52  *** rgergre has joined #bitcoin-core-dev
3402015-12-16T17:24:36  *** rgergre has quit IRC
3412015-12-16T17:39:55  *** jgarzik has left #bitcoin-core-dev
3422015-12-16T17:40:12  *** jgarzik has joined #bitcoin-core-dev
3432015-12-16T17:40:12  *** jgarzik has joined #bitcoin-core-dev
3442015-12-16T17:52:09  *** jannes has joined #bitcoin-core-dev
3452015-12-16T17:53:33  *** desantis has quit IRC
3462015-12-16T17:54:15  *** wangchun has quit IRC
3472015-12-16T17:54:33  *** wangchun has joined #bitcoin-core-dev
3482015-12-16T18:06:46  *** treehug88 has quit IRC
3492015-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
3502015-12-16T18:32:26  *** evoskuil has quit IRC
3512015-12-16T18:37:44  <morcos> Am I allowed to store a reference to chainparams?
3522015-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?
3532015-12-16T18:39:10  *** gmaxwell has left #bitcoin-core-dev
3542015-12-16T18:39:30  <sipa> imho yes
3552015-12-16T18:45:39  *** evoskuil has joined #bitcoin-core-dev
3562015-12-16T18:52:45  *** zookolaptop has quit IRC
3572015-12-16T18:53:14  *** Prattler has quit IRC
3582015-12-16T18:53:46  *** evoskuil has quit IRC
3592015-12-16T18:57:43  *** zookolaptop has joined #bitcoin-core-dev
3602015-12-16T19:06:00  *** jtimon has joined #bitcoin-core-dev
3612015-12-16T19:09:24  *** Cory has joined #bitcoin-core-dev
3622015-12-16T19:13:28  *** helo has quit IRC
3632015-12-16T19:13:42  *** helo has joined #bitcoin-core-dev
3642015-12-16T19:27:45  *** evoskuil has joined #bitcoin-core-dev
3652015-12-16T19:47:04  *** treehug88 has joined #bitcoin-core-dev
3662015-12-16T19:56:08  *** jtimon has quit IRC
3672015-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
3682015-12-16T20:09:16  *** laurentmt has joined #bitcoin-core-dev
3692015-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
3702015-12-16T21:25:17  *** treehug88 has quit IRC
3712015-12-16T21:26:46  *** zookolaptop has quit IRC
3722015-12-16T21:27:58  *** jannes has quit IRC
3732015-12-16T21:44:39  *** Guyver2 has quit IRC
3742015-12-16T21:49:20  *** laurentmt has quit IRC
3752015-12-16T21:55:06  *** d_t has joined #bitcoin-core-dev
3762015-12-16T22:05:50  <Luke-Jr> gijensen: ?
3772015-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?
3782015-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.
3792015-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
3802015-12-16T22:18:13  <gijensen> Thank you!
3812015-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
3822015-12-16T22:19:24  <Luke-Jr> nTotalRelaySize or smth
3832015-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?
3842015-12-16T22:23:14  *** zookolaptop has joined #bitcoin-core-dev
3852015-12-16T22:23:23  <Luke-Jr> I think the benefits do not outweigh the costs now
3862015-12-16T22:29:41  <gijensen> I was worried about that, okay
3872015-12-16T22:55:53  *** arubi has quit IRC
3882015-12-16T22:56:28  *** arubi has joined #bitcoin-core-dev
3892015-12-16T22:58:03  *** arubi has quit IRC
3902015-12-16T22:58:25  *** arubi has joined #bitcoin-core-dev
3912015-12-16T23:00:02  *** jtimon has joined #bitcoin-core-dev
3922015-12-16T23:01:10  *** arubi has quit IRC
3932015-12-16T23:02:02  *** arubi has joined #bitcoin-core-dev