1 2015-10-02T00:06:00  <jcorgan> ok, #6743 passes travis finally
  2 2015-10-02T00:21:00  <phantomcircuit> I dont think we need the "Address refresh broadcast" in main.cpp now that addrKnown is a CRollingBloomFilter
  3 2015-10-02T00:30:00  <phantomcircuit> gavinandresen, sanity check on above statement?
  4 2015-10-02T00:38:00  <phantomcircuit> ie the filter will "forget" an addr after 5000 inserts anyways so there's no reason to clear it
  5 2015-10-02T00:43:00  <GitHub53> [bitcoin] pstratem opened pull request #6745: Net: Remove "Address refresh broadcast" logic. (master...addr_known_reset) https://github.com/bitcoin/bitcoin/pull/6745
  6 2015-10-02T00:52:00  <phantomcircuit> is there a reason that ARM is the fastest travis build?
  7 2015-10-02T00:52:00  <phantomcircuit> that seems odd
  8 2015-10-02T01:01:00  <jgarzik> builds fewer components IIRC
  9 2015-10-02T01:08:00  <phantomcircuit> jgarzik, sanity check on #6745 ?
 10 2015-10-02T01:13:00  <jgarzik> phantomcircuit, add a unit test to prove it :)
 11 2015-10-02T01:16:00  <phantomcircuit> jgarzik, there's already CRollingBloomFilter tests that validate it's properties
 12 2015-10-02T01:16:00  <phantomcircuit> so im not sure what you mean
 13 2015-10-02T01:27:00  <gmaxwell> phantomcircuit: not clearing would significantly reduce address propagation, I think? like... if the ratio of addresses to filter size is small enough it's the same as never clearing.
 14 2015-10-02T01:31:00  <phantomcircuit> gmaxwell, which addresses though?
 15 2015-10-02T01:31:00  <phantomcircuit> real node count, addresses in addrman, or addresses that random peers push out to the network?
 16 2015-10-02T01:32:00  <gmaxwell> well if real node count is low then basically learning about them depends on their being enough bogus addresses to flush out the table... seems like a dumb thing to count on!
 17 2015-10-02T01:33:00  <jgarzik> heh, same comment on the PR
 18 2015-10-02T01:35:00  <phantomcircuit> oh right
 19 2015-10-02T01:35:00  <phantomcircuit> i forgot that PushAddress is what checks addrKnown
 20 2015-10-02T01:35:00  <gmaxwell> :)
 21 2015-10-02T01:36:00  <phantomcircuit> i believe that even with a very low real node/filter size ratio the node would still effectively broadcast it's own address
 22 2015-10-02T01:37:00  <phantomcircuit> for all outbound connections we broadcast our own address
 23 2015-10-02T01:37:00  <phantomcircuit> gmaxwell, hehe also AdvertizeLocal -> AdvertiseLocal
 24 2015-10-02T01:39:00  <phantomcircuit> gmaxwell, the logic in AdvertizeLocal is slightly different from the logic in the "version" message handler, is there a reason for that?
 25 2015-10-02T01:40:00  <phantomcircuit> oh and the logic in the "version" handler ignores fDiscover
 26 2015-10-02T01:44:00  <PRab> https://github.com/bitcoin/bitcoin/blob/master/contrib/gitian-downloader/prab-key.pgp has expired, but I have created and rolled over to a new key. What is the "proper" way to update this?
 27 2015-10-02T01:54:00  <phantomcircuit> hmm except IsInitialBlockDownload() is going to be true fairly often
 28 2015-10-02T02:00:00  <phantomcircuit> gmaxwell, im thinking that the IsInitialBlockDownload check shouldnt gate AdvertiseLocal in the "version" handler
 29 2015-10-02T02:01:00  <phantomcircuit> (i bet that's mostly the reason why people who up in #bitcoin and ask why they have no inbound connections)
 30 2015-10-02T02:47:00  <CodeShark> I would perhaps like to merge code that just moves the IsSuperMajority checks into a separate unit before going full force on version bits. This change would not affect any behavior and only touches main.cpp in very few places. Any objections to this approach?
 31 2015-10-02T02:50:00  <CodeShark> should be easy to review...and easy to rebase against
 32 2015-10-02T02:51:00  <CodeShark> The reason being that if we're going to still use ISM for deployments I'd like to start organizing them better
 33 2015-10-02T02:52:00  <CodeShark> So that when we do the first version bits deployments they are easier to review
 34 2015-10-02T02:55:00  <gmaxwell> So it seems someone might have taken my comment about canoniczing transactions to heart, as someone is complaining to me about mutants, and they say that they think the smaller of the mutants is the mutated one.
 35 2015-10-02T02:56:00  <gmaxwell> and that it started for them around midnight utc.
 36 2015-10-02T02:56:00  <gmaxwell> if someone here is doing that, you probably should cut it out. If nothing else, it'll complicate scanning the blockchain and figuring out which wallet software needs to be nagged to produce low-S signatures.
 37 2015-10-02T03:02:00  <CodeShark> if we rebase the current ISM soft forks against my soft forks unit, we can more easily decide how to deploy them later on without having to rebase them again
 38 2015-10-02T03:03:00  <CodeShark> we can either continue to use ISM, we can deploy them one at a time, or several together, or eventually use versionbits
 39 2015-10-02T03:06:00  <rusty> CodeShark I can only really judge after I've seen the result, so use your judgement I guess.
 40 2015-10-02T03:08:00  <CodeShark> rusty, basically https://github.com/bitcoin/bitcoin/compare/master...CodeShark:versionbits but without softforks.h/softforks.cpp
 41 2015-10-02T03:08:00  <CodeShark> and with better structured commits
 42 2015-10-02T03:11:00  <CodeShark> I can rebase 68, 112, and 113 against it
 43 2015-10-02T03:11:00  <CodeShark> as well as 65
 44 2015-10-02T03:14:00  <CodeShark> I just want to see if there are any potential serious objections so I don't waste my time doing it
 45 2015-10-02T03:14:00  <rusty> CodeShark that patch does too much.  There's unnecesary code motion, collapse of variables, and a new return state.Invalid() which I don't see a source for.
 46 2015-10-02T03:15:00  <CodeShark> which code motion are you referring to in particular?
 47 2015-10-02T03:15:00  <rusty> CodeShark ah, this is more than one commit I'm looking at.  One sec/
 48 2015-10-02T03:15:00  <CodeShark> yeah, ignore the commit structure - just look at the final compare
 49 2015-10-02T03:15:00  <CodeShark> I'll be sure to structure the commits to make them easier to review
 50 2015-10-02T03:17:00  <rusty> CodeShark Hmm, IsValidVersion seems like a new concept; I can't see where the equiv code is removed.  Maybe because you commented out rather than removing?
 51 2015-10-02T03:17:00  <CodeShark> it replaces the explicit calls to IsSuperMajority in ContextualCheckBlockHeader
 52 2015-10-02T03:18:00  <CodeShark> I'll be sure to make those movements in a single commit
 53 2015-10-02T03:18:00  <CodeShark> yes, I did comment out what it replaces in main.cpp
 54 2015-10-02T03:20:00  <rusty> Right, so overall it's not too bad, but I would be super paranoid and keep eg. "fEnforceBIP30" var, so diff is minimized.  Then cleanup unnecessary vars at the end.
 55 2015-10-02T03:20:00  <rusty> Make it super bite-size digestible.  People may want a backport...
 56 2015-10-02T03:21:00  <CodeShark> yeah, I want to try to change as little as possible in main.cpp.
 57 2015-10-02T03:21:00  <CodeShark> Eventually I'd like the forks to be clearly visible within the consensus code and structured nicely...but that can wait
 58 2015-10-02T03:24:00  <phantomcircuit> gmaxwell, ha
 59 2015-10-02T03:25:00  <CodeShark> one of the goals, rusty, is to separate the review of BIPs for their features from the review of the deployment strategy
 60 2015-10-02T03:26:00  <CodeShark> would be nice to disentangle the two
 61 2015-10-02T03:28:00  <CodeShark> it would also be beautiful if we could avoid as much rebasing as possible from BIP proposal to BIP deployment
 62 2015-10-02T03:29:00  <CodeShark> we keep getting stuck on stupid crap that continues to delay deployment unnecessarily
 63 2015-10-02T03:29:00  <gmaxwell> versionbits must be backported unless we want to delay it's deployment until 0.12 is the oldest thing we'd backport to. :(
 64 2015-10-02T03:29:00  <gmaxwell> we 'backported' it could be reimplemented, of course.
 65 2015-10-02T03:30:00  <rusty> CodeShark: Agreed, a laudable goal.
 66 2015-10-02T03:30:00  <gmaxwell> I think sipa's initial plan might have been to do that... e.g. using efficient implementation in new code and a 'walks the last 1000 blocks very block' implementation in backports.
 67 2015-10-02T03:31:00  <CodeShark> walking back 1000 blocks every block isn't enough - we need to map state every activation interval in the block index
 68 2015-10-02T03:31:00  <phantomcircuit> gmaxwell, what do you think about setting random bits to 0 in the bloom filter instead of clearing it at a fixed interval?
 69 2015-10-02T03:32:00  <CodeShark> in any case, I'm fine with backporting versionbits itself after 0.12
 70 2015-10-02T03:32:00  <CodeShark> the implementation is the easy part - it's getting it reviewed and acked that's a bitch :p
 71 2015-10-02T03:32:00  <gmaxwell> we're pretty screwed on backport review bandwidth.
 72 2015-10-02T03:33:00  <CodeShark> point is the current proposal won't require backporting
 73 2015-10-02T03:33:00  <CodeShark> or will minimize it considerably
 74 2015-10-02T03:33:00  <gmaxwell> there is always backporting even if the code is unchanged. :)
 75 2015-10-02T03:34:00  <CodeShark> backporting will probably amount to changing a handful of lines in main.cpp
 76 2015-10-02T03:34:00  <CodeShark> or are you also taking into account the proposed code movements for consensus and other stuff?
 77 2015-10-02T03:35:00  <gmaxwell> More that I just mean that most of the 'backporting' work is actually the review to figure out if the changes are really safe in the new context.
 78 2015-10-02T03:37:00  <CodeShark> yes, which is why I'm primarily interested in first merging stuff that will minimize such risks later on
 79 2015-10-02T03:37:00  <CodeShark> it's a horrendous bottleneck
 80 2015-10-02T03:37:00  <CodeShark> lots of people are frustrated
 81 2015-10-02T03:39:00  <CodeShark> a good number of people doing real quantum leap type work on Bitcoin are waiting on changes that are taking forever
 82 2015-10-02T03:40:00  <CodeShark> and it seems that we're wasting a lot of precious expert dev time having them basically repeat the same type of grunt work for each PR
 83 2015-10-02T03:40:00  <CodeShark> (I'm looking at you, sipa)
 84 2015-10-02T04:01:00  <CodeShark> to be clear, I don't want to sound like I'm complaining - this is not a complaint...I want to help Bitcoin Core be more efficient
 85 2015-10-02T04:03:00  <CodeShark> the dev process, that is
 86 2015-10-02T05:36:00  <GitHub54> [bitcoin] CodeShark opened pull request #6747: Softforks unit (master...softforks_unit) https://github.com/bitcoin/bitcoin/pull/6747
 87 2015-10-02T05:49:00  <phantomcircuit> that's interesting someone reported "non-canonical ReadCompactSize()" in their error field thing
 88 2015-10-02T05:50:00  <phantomcircuit> see the same thing... on all nodes
 89 2015-10-02T05:50:00  <GitHub176> [bitcoin] paveljanik opened pull request #6748: Rewrite help texts for features enabled by default (master...configure_disable) https://github.com/bitcoin/bitcoin/pull/6748
 90 2015-10-02T06:05:00  <gmaxwell> http://blog.coinkite.com/post/130318407326/ongoing-bitcoin-malleability-attack-low-s-high    "BIP62 is not currently deployed and we encourage all miners to enforce it as soon as possible."   0_o
 91 2015-10-02T06:12:00  <phantomcircuit> gmaxwell, at this point it seems like it would be best if BIP62 rules were made IsStandard
 92 2015-10-02T06:13:00  <gmaxwell> phantomcircuit: IIRC they aren't even all implemented, and as far as bip62 goes many were only to be applied to higher versioned transactions which don't exist.
 93 2015-10-02T06:13:00  <gmaxwell> we also have relatively low confidence that they're complete.
 94 2015-10-02T06:13:00  <gmaxwell> (like... I don't think anyone has even ever tried implementing them and AFLing to try to get a passing mutant)
 95 2015-10-02T06:14:00  <phantomcircuit> gmaxwell, sure... but it raises the bar a bit
 96 2015-10-02T06:15:00  <gmaxwell> but .. it doesn't. it would have no effect on the current mutations if they're ecdsa based, until people started producing elevated version transactions.
 97 2015-10-02T06:18:00  <phantomcircuit> gmaxwell, mutate to low-s and reject even without higher version numbers as non standard
 98 2015-10-02T06:18:00  <phantomcircuit> it's not a security consideration
 99 2015-10-02T06:18:00  <phantomcircuit> just a nuisance reduction
100 2015-10-02T06:18:00  <gmaxwell> phantomcircuit: okay, thats the instutionalize the attack thing I mentioned a day ago.
101 2015-10-02T06:19:00  <phantomcircuit> broken wallets producing high-s are already just as broken as they are now
102 2015-10-02T06:19:00  <gmaxwell> I'd really like to figure out who is producing high S and nag them to change.
103 2015-10-02T06:19:00  <gmaxwell> I went to go measure it today but of course the attacks obscure the results. :)
104 2015-10-02T06:20:00  <phantomcircuit> follow the crumbs of users complaining about weirdness with their wallet :P
105 2015-10-02T06:21:00  <phantomcircuit> or maybe they'll stop
106 2015-10-02T06:22:00  <gmaxwell> phantomcircuit: we should probably go write the nuclear canonicize transaction patch at least.
107 2015-10-02T06:22:00  <phantomcircuit> yup
108 2015-10-02T06:22:00  <phantomcircuit> gmaxwell, btw im trying to go back and get that trickle logic fixing patch commit ready
109 2015-10-02T06:23:00  <phantomcircuit> thus my questions from before about AdvertiseLocal
110 2015-10-02T06:37:00  <phantomcircuit> gmaxwell, well lets see, of the things on the BIP62 list the first is BIP66, right?
111 2015-10-02T07:08:00  <wumpus> <phantomcircuit> is there a reason that ARM is the fastest travis build? <- yes a) no GUI b) doesn't run tests
112 2015-10-02T07:08:00  <Luke-Jr> eh, why no GUI?
113 2015-10-02T07:09:00  <Luke-Jr> I just figured it was because it ran first :P
114 2015-10-02T07:09:00  <CodeShark> how can I run the same tests travis runs locally?
115 2015-10-02T07:09:00  <Luke-Jr> wumpus: is there a reason for unbanning lightningbot?
116 2015-10-02T07:10:00  <wumpus> Luke-Jr: something with depends, building Qt was somewhat tricky on ARM
117 2015-10-02T07:10:00  <wumpus> CodeShark: qa/pulltester/rpc-tests.py
118 2015-10-02T07:10:00  <wumpus> Luke-Jr: it's the logging bot
119 2015-10-02T07:11:00  <Luke-Jr> oh
120 2015-10-02T07:12:00  <CodeShark> thanks, wumpus
121 2015-10-02T07:12:00  <Luke-Jr> wumpus: btw, I believe 5574 and 6349 are good to go
122 2015-10-02T07:15:10  *** lightningbot has joined #bitcoin-core-dev
123 2015-10-02T07:16:38  <aj> wumpus: this time for sure :-/
124 2015-10-02T07:18:14  *** d_t has quit IRC
125 2015-10-02T07:18:22  <aj> wumpus: logs are backfilled from my scrollback too fwiw
126 2015-10-02T07:24:52  *** gmaxwell is now known as gmaxwell_
127 2015-10-02T07:24:59  *** gmaxwell_ is now known as gregorymaxwell
128 2015-10-02T07:25:04  *** gregorymaxwell is now known as gmaxweii
129 2015-10-02T07:25:09  *** gmaxweii is now known as gmaxwelI
130 2015-10-02T07:25:15  *** gmaxwelI is now known as gmaxwelIl
131 2015-10-02T07:26:01  *** BlueMatt is now known as gmaxweII
132 2015-10-02T07:26:14  *** gmaxweII is now known as BlueMatt
133 2015-10-02T07:26:20  <BlueMatt> lol, you reg'd gmaxweII???
134 2015-10-02T07:26:59  <midnightmagic> lotta scammers.
135 2015-10-02T07:29:38  <wumpus> where bitcoin developers do their ritual tribal name-swapping dance
136 2015-10-02T07:30:59  <CodeShark> hmm, when I run the tests locally it succeeds - but travis is choking
137 2015-10-02T07:32:05  <BlueMatt> oh, I love those ones :(
138 2015-10-02T07:32:12  <gmaxwelIl> BlueMatt: there was a scammer using it in the past, also freenode is about to expire a bunch of not used for a while nicks.
139 2015-10-02T07:32:16  * BlueMatt misses when he ran the tester, then I could ssh in and figure it all out :)
140 2015-10-02T07:32:25  <Luke-Jr> can someone throw a notice on BIP 62 that it is currently not deployable? http://blog.coinkite.com/post/130318407326/ongoing-bitcoin-malleability-attack-low-s-high
141 2015-10-02T07:32:53  <jonasschnelli> Hmm... I think we could speed up Travis by moving to the new platform. Would require to get rid of "sudo", "apt-*" calls and migrate to package installing over the YAML structure.
142 2015-10-02T07:33:46  <gmaxwelIl> Luke-Jr: write the patch, I'll gladly ack/merge, just a "This document is a work in progress and is not complete, implemented, or otherwise suitable for deployment."
143 2015-10-02T07:34:06  <jonasschnelli> BlueMatt: an additional CI is still possible. Maybe no github auto-comment feature. I think some people run it.
144 2015-10-02T07:34:24  *** dcousens has joined #bitcoin-core-dev
145 2015-10-02T07:34:51  <BlueMatt> jonasschnelli: you miss the point, my point is when the tester failed, I could manually fix it for my pulls, adding new testers just means more failures, not ability for me to have privileged status through fixing my own pulls :p
146 2015-10-02T07:35:14  <jonasschnelli> Ah.. I see. :-)
147 2015-10-02T07:37:27  <Luke-Jr> https://github.com/bitcoin/bips/pull/210
148 2015-10-02T07:41:24  <CodeShark> is there anything else I can do to diagnose the travis test failure issue?
149 2015-10-02T07:41:26  <wumpus> CodeShark: travis servers tend to be very busy, this has, for me at least, triggered race conditions that wouldn't appear locally
150 2015-10-02T07:41:49  <CodeShark> so what's the workaround?
151 2015-10-02T07:42:39  <BlueMatt> load your workstation a ton before running locally?
152 2015-10-02T07:42:46  <CodeShark> lol
153 2015-10-02T07:42:57  <BlueMatt> also run tests on a workstation with like 20 cores?
154 2015-10-02T07:42:59  <wumpus> run your tests while running a parallel a build of bitcoin core with gccin the background?
155 2015-10-02T07:43:13  <wumpus> that will help to fill up memory as well as cores :-)
156 2015-10-02T07:43:20  *** gmaxwelIl is now known as gmawell
157 2015-10-02T07:43:25  <BlueMatt> wumpus: yea, if only my workstation would actually fill up its cores running "make -j"
158 2015-10-02T07:43:29  <BlueMatt> but, it doesnt :(
159 2015-10-02T07:43:39  <BlueMatt> damn 40 threads
160 2015-10-02T07:43:41  <wumpus> BlueMatt: if X is high enough (though it will probabl yfill up memory first)
161 2015-10-02T07:43:55  <BlueMatt> wumpus: no, not "make -jX", "make -j"
162 2015-10-02T07:43:59  <BlueMatt> as in, run it ALL at once
163 2015-10-02T07:44:20  <wumpus> but it creates a lot of nice I/O delays. Another option is the latter part of the chain verification with -par=high-number
164 2015-10-02T07:44:25  <CodeShark> are you saying the race conditions are in Bitcoin Core? or in the travis environment?
165 2015-10-02T07:44:27  <wumpus> BlueMatt: ooh I didn't know that one
166 2015-10-02T07:44:35  <wumpus> CodeShark: in your code change, usually
167 2015-10-02T07:44:45  <CodeShark> I didn't touch any threading stuff whatsoever
168 2015-10-02T07:44:54  <BlueMatt> CodeShark: time to dust off the cpu miner!
169 2015-10-02T07:45:25  <wumpus> CodeShark: where is it failing btw?
170 2015-10-02T07:45:26  <BlueMatt> wumpus: yes, its only useful when you have 64GB memory lying around that has half your hdd in cache anyway, plus lots of threads to eat the work quick
171 2015-10-02T07:45:39  <CodeShark> https://travis-ci.org/bitcoin/bitcoin/jobs/83252957
172 2015-10-02T07:46:31  <CodeShark> oh, hmm Coinbase script size out of range
173 2015-10-02T07:47:07  <wumpus> ah it fails in the block tester
174 2015-10-02T07:47:17  <CodeShark> yeah - how can I reproduce that locally?
175 2015-10-02T07:48:17  * wumpus did it in the past but doesn't know by heart
176 2015-10-02T07:49:15  <wumpus> also don't see it in travis.yml at all, it just does 'make check' then the rpc-tests.sh script
177 2015-10-02T07:49:28  <wumpus> but it's there somewhere!
178 2015-10-02T07:49:36  <BlueMatt> its in ./configure
179 2015-10-02T07:49:40  <BlueMatt> --with-comparison-tool=....
180 2015-10-02T07:49:41  <BlueMatt> or so
181 2015-10-02T07:49:44  <BlueMatt> then make check runs it
182 2015-10-02T07:49:55  <BlueMatt> the ... being the path to the jar
183 2015-10-02T07:50:11  <CodeShark> oh, I need to install java? :)
184 2015-10-02T07:50:13  <CodeShark> lol
185 2015-10-02T07:50:25  <BlueMatt> yes
186 2015-10-02T07:50:29  <wumpus> ahh, yes I think in the case of travis it's being installed as part of depends, then configure picks it up automatically
187 2015-10-02T07:52:21  <wumpus> but you can also download the jar and pas it with --with-comparison-tool, or even build the jar yourself if you're adventurous
188 2015-10-02T07:53:37  <wumpus> we should add some documentation for this at some point
189 2015-10-02T07:54:05  <wumpus> how to run the python tests is pretty well documented, but this isn't
190 2015-10-02T07:54:08  <CodeShark> for the block tester, is it using real blocks on mainnet? or is it mining something?
191 2015-10-02T07:54:22  <wumpus> regtest IIRC
192 2015-10-02T07:54:50  <CodeShark> hmm...seems related to BIP34
193 2015-10-02T07:55:04  <CodeShark> just a guess :)
194 2015-10-02T07:55:06  <wumpus> I think it was the original motivation for regtest even
195 2015-10-02T07:57:19  <CodeShark> ok, fine...installing jre...
196 2015-10-02T07:57:21  <CodeShark> lol
197 2015-10-02T08:01:54  <CodeShark> where can I grab the jar file?
198 2015-10-02T08:02:13  *** n0n0_ has joined #bitcoin-core-dev
199 2015-10-02T08:02:53  <CodeShark> meh...I'll install the jdk as well
200 2015-10-02T08:03:30  <CodeShark> where's the java source located?
201 2015-10-02T08:07:11  <wumpus> it's part of bitcoinj *however* that may not be the newest version, the person to ask would be cfields
202 2015-10-02T08:07:42  <BlueMatt> the bitcoinj one is +/- the latest
203 2015-10-02T08:09:11  <wumpus> https://github.com/theuni/bitcoind-comparisontool  does he have any information there?
204 2015-10-02T08:09:27  <CodeShark> I found the source - but I suppose I need to install the library as well and all that
205 2015-10-02T08:09:33  <CodeShark> it's been ages since I touched java
206 2015-10-02T08:10:22  <BlueMatt> you can grab the binary from the above repo
207 2015-10-02T08:10:59  <wumpus> building it yourself is probably not worth it, unless you want to work on it, and fathom learning java build systems and such
208 2015-10-02T08:11:22  <CodeShark> the 8c666 jar?
209 2015-10-02T08:11:42  <wumpus> that's the one referred to in depends/packages/native_comparisontool.mk
210 2015-10-02T08:13:13  <CodeShark> ok, test is running (crossing fingers)
211 2015-10-02T08:14:22  <CodeShark> alright, successfully reproduced the error :)
212 2015-10-02T08:14:42  <wumpus> phew, good
213 2015-10-02T08:25:38  *** d_t has joined #bitcoin-core-dev
214 2015-10-02T08:26:18  *** d_t has joined #bitcoin-core-dev
215 2015-10-02T08:27:06  *** d_t has joined #bitcoin-core-dev
216 2015-10-02T08:28:14  *** d_t has quit IRC
217 2015-10-02T08:28:59  *** d_t has joined #bitcoin-core-dev
218 2015-10-02T08:29:36  *** Cocodude has left #bitcoin-core-dev
219 2015-10-02T08:30:08  *** d_t has quit IRC
220 2015-10-02T08:31:05  *** d_t has joined #bitcoin-core-dev
221 2015-10-02T08:32:00  *** d_t has quit IRC
222 2015-10-02T08:32:47  *** d_t has joined #bitcoin-core-dev
223 2015-10-02T08:33:52  *** d_t has quit IRC
224 2015-10-02T08:36:03  *** TZander is now known as zander
225 2015-10-02T08:36:32  *** zander is now known as thomasz
226 2015-10-02T08:37:21  *** thomasz is now known as TZander
227 2015-10-02T08:52:15  *** BashCo has joined #bitcoin-core-dev
228 2015-10-02T08:53:16  <BlueMatt> sdaftuar/morcos: great call on switching to calling RemoveStaged after each loop iteration instead of at the end
229 2015-10-02T08:53:21  <BlueMatt> resulted in removing more than a third of the lines of code in TrimToSize!
230 2015-10-02T08:53:26  <BlueMatt> and the mempool is no longer sorted based on max(tx-feerate-with-descendants, tx-feerate), but instead only tx-feerate-with-descendants :)
231 2015-10-02T08:54:29  <BlueMatt> the heart of mempool limiting in 6722 is now 55 LOC :)
232 2015-10-02T08:56:29  <gmawell> BlueMatt: that sounds fantastic.
233 2015-10-02T09:00:49  <gmawell> FWIW: re current malleability event, https://bitcointalk.org/index.php?topic=1198032.msg12579271#msg12579271
234 2015-10-02T09:02:09  <BlueMatt> hah
235 2015-10-02T09:10:25  <BlueMatt> ok, that shit was bugging me, now its 50 :)
236 2015-10-02T09:14:58  *** warren_2 has joined #bitcoin-core-dev
237 2015-10-02T09:15:11  *** Apocalyptic_ has joined #bitcoin-core-dev
238 2015-10-02T09:17:21  *** TZander has quit IRC
239 2015-10-02T09:17:47  *** Apocalyptic has quit IRC
240 2015-10-02T09:17:47  *** warren has quit IRC
241 2015-10-02T09:17:50  *** nanotube has quit IRC
242 2015-10-02T09:17:51  *** Apocalyptic_ is now known as Apocalyptic
243 2015-10-02T09:17:51  *** warren_2 is now known as warren
244 2015-10-02T09:23:48  *** nanotube has joined #bitcoin-core-dev
245 2015-10-02T09:38:29  *** tripleslash_e has joined #bitcoin-core-dev
246 2015-10-02T09:38:41  *** tripleslash has quit IRC
247 2015-10-02T10:04:30  *** rusty has joined #bitcoin-core-dev
248 2015-10-02T10:33:33  <GitHub108> [bitcoin] petertodd opened pull request #6750: Recent rejects backport to v0.11 (0.11...recent-rejects-v0.11-backport) https://github.com/bitcoin/bitcoin/pull/6750
249 2015-10-02T11:10:01  *** midnightmagic has quit IRC
250 2015-10-02T11:14:40  *** midnightmagic has joined #bitcoin-core-dev
251 2015-10-02T11:16:11  *** midnightmagic has quit IRC
252 2015-10-02T11:20:16  *** midnightmagic has joined #bitcoin-core-dev
253 2015-10-02T11:20:39  *** midnightmagic is now known as Guest73782
254 2015-10-02T11:22:19  *** rusty has quit IRC
255 2015-10-02T11:28:20  *** rusty has joined #bitcoin-core-dev
256 2015-10-02T11:44:50  *** Guest73782 has quit IRC
257 2015-10-02T11:46:56  *** ParadoxSpiral has joined #bitcoin-core-dev
258 2015-10-02T12:11:28  *** midnightmagic_ has joined #bitcoin-core-dev
259 2015-10-02T12:21:28  *** rusty has quit IRC
260 2015-10-02T12:41:20  *** midnightmagic_ is now known as midnightmagic
261 2015-10-02T12:58:02  *** midnightmagic has quit IRC
262 2015-10-02T12:59:29  *** midnightmagic has joined #bitcoin-core-dev
263 2015-10-02T13:05:12  *** BashCo has quit IRC
264 2015-10-02T13:05:12  *** BashCo has joined #bitcoin-core-dev
265 2015-10-02T13:05:12  *** BashCo has quit IRC
266 2015-10-02T13:05:12  *** BashCo has joined #bitcoin-core-dev
267 2015-10-02T13:06:51  *** BashCo_ has joined #bitcoin-core-dev
268 2015-10-02T13:09:10  *** dcousens has quit IRC
269 2015-10-02T13:10:49  *** BashCo has quit IRC
270 2015-10-02T13:29:41  <btcdrak> Luke-Jr: gmaxwell: I asked coinkite to change their blog post
271 2015-10-02T13:40:03  *** goregrind has quit IRC
272 2015-10-02T13:43:26  <sdaftuar> ;
273 2015-10-02T13:46:24  <DocHex> btcdrak: (it's been updated) if you have a link to something about what's missing in BIP62, or what remains to be done, I'm happy to link to that on the blog too.
274 2015-10-02T13:55:33  <sdaftuar> BlueMatt: one other thought about the mempool limiting algorithm -- i was thinking about how, in TrimToSize, we're skipping over any packages that have the new tx as a descendant
275 2015-10-02T13:56:11  <sdaftuar> it seems a little counterintuitive to me that we might let in a new transaction that ends up joining some package near the bottom of the mempool, while it may have been able to evict some higher up package (and set the min relay fee higher than the bottom package in the mempool)
276 2015-10-02T13:57:59  <sdaftuar> i'm not sure there's any big problem here that needs solving, i haven't yet thought of any new fundamental attacks, but it made me wonder if this modified algorithm might be easier to reason about:
277 2015-10-02T13:59:19  <sdaftuar> when a new transaction comes in, let it in if it exceeds the current prevailing relay fee (and all the usual other checks). after accepting it, call TrimToSize() and remove packages from the bottom until we're under the size limit, and update the relay fee based on whether anything was evicted
278 2015-10-02T13:59:56  <sdaftuar> (at that point, we could set our notion of whether this tx was accepted or rejected based on whether it's still in the mempool at the end)
279 2015-10-02T14:11:25  *** CoinMuncher has joined #bitcoin-core-dev
280 2015-10-02T14:13:12  *** BashCo has joined #bitcoin-core-dev
281 2015-10-02T14:16:03  *** BashCo_ has quit IRC
282 2015-10-02T14:38:59  <morcos> BlueMatt: your change to use only package fee rate and not max: any reasoning behind that?
283 2015-10-02T14:39:36  <morcos> I can't think of a problem off of the top of my head, i know there were problems with earlier versions if you didn't use the max, but maybe they've all gone away now that we evict (and resort) on every pass.
284 2015-10-02T14:39:48  <morcos> but it certainly changes behavior.
285 2015-10-02T14:44:06  *** paveljanik has joined #bitcoin-core-dev
286 2015-10-02T14:57:02  *** rubensayshi has joined #bitcoin-core-dev
287 2015-10-02T15:05:25  *** zooko has joined #bitcoin-core-dev
288 2015-10-02T15:16:46  *** goregrind has joined #bitcoin-core-dev
289 2015-10-02T15:35:18  *** zveda has joined #bitcoin-core-dev
290 2015-10-02T15:35:39  *** zveda has left #bitcoin-core-dev
291 2015-10-02T15:38:16  *** fkhan has quit IRC
292 2015-10-02T15:51:29  *** rubensayshi has quit IRC
293 2015-10-02T15:52:06  *** treehug88 has joined #bitcoin-core-dev
294 2015-10-02T16:04:50  *** BashCo has quit IRC
295 2015-10-02T16:07:04  *** d_t has joined #bitcoin-core-dev
296 2015-10-02T16:10:15  *** n0n0__ has joined #bitcoin-core-dev
297 2015-10-02T16:13:54  *** n0n0_ has quit IRC
298 2015-10-02T16:15:24  *** rubensayshi has joined #bitcoin-core-dev
299 2015-10-02T16:18:35  *** rubensayshi has quit IRC
300 2015-10-02T16:46:10  *** fkhan has joined #bitcoin-core-dev
301 2015-10-02T16:49:36  *** randy-waterhouse has joined #bitcoin-core-dev
302 2015-10-02T16:50:15  <cfields> jonasschnelli: sorry i missed your question yesterday, i didn't realize my irc client had shut down. It did seem unusually quiet, though :)
303 2015-10-02T16:50:29  <cfields> Missed the meeting too :\
304 2015-10-02T16:52:07  <cfields> wumpus / sipa: I'm working to have something to show wrt network code asap. It's taking much longer than expected, I've hit snags and had to refactor several times now
305 2015-10-02T16:53:14  <cfields> ultimately I've decided not to mess with much at the individual message level yet, so the general flow there is pretty much the same as now
306 2015-10-02T16:53:36  <wumpus> "i didn't realize my irc client had shut down" hehe that has happened to me too
307 2015-10-02T16:53:42  <wumpus> nice cfields!
308 2015-10-02T16:54:18  <wumpus> any problems with libevent? or just with our code structure?
309 2015-10-02T16:55:17  <cfields> wumpus: nah, no problems. Just lots of sudden "oh, so that's how that works. well shit." moments
310 2015-10-02T17:08:02  *** d_t has quit IRC
311 2015-10-02T17:14:50  *** adam3us has joined #bitcoin-core-dev
312 2015-10-02T17:29:31  *** zooko has quit IRC
313 2015-10-02T17:31:24  <CodeShark> cfields: as you probably know, I've also dabbled a bit in this messaging stuff...if you would like me to review anything I'd like to have a look
314 2015-10-02T17:40:47  <cfields> CodeShark: great, thanks
315 2015-10-02T17:40:52  *** CoinMuncher1 has joined #bitcoin-core-dev
316 2015-10-02T17:43:07  *** CoinMuncher has quit IRC
317 2015-10-02T17:44:01  *** CoinMuncher has joined #bitcoin-core-dev
318 2015-10-02T17:45:19  *** CoinMuncher1 has quit IRC
319 2015-10-02T17:51:37  <jgarzik> cfields, feel free to ask questions
320 2015-10-02T17:52:25  <jgarzik> cfields, there is a lot of subtlety.  for example, we stop reading in if writing output pauses.  fixes some TCP windowing attacks (along with some related logic).
321 2015-10-02T17:55:54  <btcdrak> ping maaku
322 2015-10-02T17:59:00  <maaku> yes?
323 2015-10-02T18:00:51  <btcdrak> maaku: sdaftuar was asking if there was a resolution to this http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009344.html
324 2015-10-02T18:01:03  <jgarzik> cfields, management of the active set should be the same across current code and new libevent code
325 2015-10-02T18:01:26  <sdaftuar> maaku: yeah i was just wondering if there was an open pull to implement your solution in that thread?
326 2015-10-02T18:06:49  <maaku> sdaftuar: #6312 does not suffer that issue
327 2015-10-02T18:07:10  <maaku> most significant bit determines whether relative lock-time semantics are used
328 2015-10-02T18:10:27  <CodeShark> maaku: you still don't have a PR for the actual soft forks, just the mempool stuff, right?
329 2015-10-02T18:11:56  <sdaftuar> maaku: thanks, i think i'm reading the wrong bip 68 text, perhaps -- i believe the link from #6312 is to an older draft?
330 2015-10-02T18:13:21  <CodeShark> I wanted to ask you about the trigger mechanisms when you have a moment
331 2015-10-02T18:13:31  *** DocHex has left #bitcoin-core-dev
332 2015-10-02T18:15:41  <btcdrak> CodeShark: there wont be softforking PRs until this gets merged
333 2015-10-02T18:19:37  <btcdrak> sdaftuar: should be this https://github.com/maaku/bips/blob/bip68/bip-0068.mediawiki
334 2015-10-02T18:20:50  <sdaftuar> btcdrak: that differs from https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki
335 2015-10-02T18:21:07  <btcdrak> oh i see, typo.
336 2015-10-02T18:21:22  <btcdrak> well /master/ is the right one
337 2015-10-02T18:23:21  *** zooko has joined #bitcoin-core-dev
338 2015-10-02T18:28:58  <morcos> btcdrak: typo?  its just different text, oh you mean typo on the link?
339 2015-10-02T18:29:28  <btcdrak> yeah the link is to brancn bip68 rather than master branch, ping @maaku
340 2015-10-02T18:31:26  <morcos> what's the right way to leave feedback on the bip text
341 2015-10-02T18:31:46  <morcos> the terminology "reduced by 2^14" was confusing to me, also there are small typos
342 2015-10-02T18:32:02  <morcos> open an issue?
343 2015-10-02T18:32:37  *** ParadoxSpiral_ has joined #bitcoin-core-dev
344 2015-10-02T18:33:25  *** d_t has joined #bitcoin-core-dev
345 2015-10-02T18:35:22  *** ParadoxSpiral has quit IRC
346 2015-10-02T18:39:22  *** CoinMuncher has quit IRC
347 2015-10-02T18:41:38  <btcdrak> Open a PR directly
348 2015-10-02T18:42:02  <btcdrak> or if you dont have time PM me the issues and I'll make a PR quickly
349 2015-10-02T18:44:39  <morcos> Yeah I didn't want to PR because I'm not sure what the history of arriving at the phrase "reduced by" is, but I found it confusing.  that same sentence has a typo "heigh" instead of "height".  If I find more, I'll PR them, but I'm going to review pulls now
350 2015-10-02T18:51:07  <btcdrak> ty
351 2015-10-02T19:08:41  *** BashCo has joined #bitcoin-core-dev
352 2015-10-02T19:41:26  <btcdrak> does anyone know which block BIP66 enforced on specifically?
353 2015-10-02T19:41:54  <CodeShark> I think 358806
354 2015-10-02T19:43:51  <CodeShark> it's probably something really stupid - according to the cli, it's still activating the best chain when it runs
355 2015-10-02T19:54:01  *** CodeShark_ has quit IRC
356 2015-10-02T19:54:53  *** treehug88 has quit IRC
357 2015-10-02T19:55:23  <maaku> sdaftuar: it's a one-line fix to make the CLTV soft-fork do 68, 112, and 113 as well
358 2015-10-02T19:57:31  <btcdrak> maaku, we need to bump transaction version to 2 also right?
359 2015-10-02T20:02:32  *** d_t has quit IRC
360 2015-10-02T20:02:50  *** d_t has joined #bitcoin-core-dev
361 2015-10-02T20:12:12  <BlueMatt> morcos: the reasoning was its not no longer useful to do so
362 2015-10-02T20:12:54  <BlueMatt> (and simplicity is better)
363 2015-10-02T20:15:15  <BlueMatt> sdaftuar: hmmmmmm, yeaaaaa
364 2015-10-02T20:15:38  *** bitdevsnyc has joined #bitcoin-core-dev
365 2015-10-02T20:16:31  *** zooko has quit IRC
366 2015-10-02T20:19:14  <BlueMatt> sdaftuar: yay more loc removal :)
367 2015-10-02T20:20:16  <jgarzik> maaku, oh?  (RE one-line)
368 2015-10-02T20:20:46  <morcos> BlueMatt: For example: if A->B,C and B,C -> D.    D = 90  B = 10, C = 10  A = 70.   Then the package sorts before B or C, but the max sorts after
369 2015-10-02T20:21:20  <morcos> so would you really want to boot A from your mempool?  it might be the most expensive immediately minable tx in there?
370 2015-10-02T20:22:00  <maaku> ok maybe 2-3 lines. basically the CLTV soft-fork does a supermajority check and sets a script validation flag. 112 would set a different script validation flag, and 68 and 113 would set a lock-time flag
371 2015-10-02T20:22:38  <morcos> its not clear to me that max is better, but its a difference worth considering.
372 2015-10-02T20:22:41  <maaku> the pull requests for 68, 112, and 113 are specifically coded to support the same soft-fork rollout as cltv
373 2015-10-02T20:23:18  <morcos> maaku: i've just started my review of these things, is there an analysis anywhere of why we don't need the mempool-only versions to be released for a while before we do the soft fork
374 2015-10-02T20:23:21  <BlueMatt> ok, TrimToSize is now 10 LOC
375 2015-10-02T20:23:35  <morcos> for instance do we know there are no txs which would fail?
376 2015-10-02T20:23:55  <morcos> well not none, but you know what i mean, they aren't being regularly generateed
377 2015-10-02T20:24:50  <morcos> quite honestly this seems like kind of a lot of new code to me and that it might make more sense to have it as mempool only first before softforking it in
378 2015-10-02T20:24:59  <maaku> morcos: why would we?
379 2015-10-02T20:25:09  <morcos> or at least have it in master for a while before releasing a soft fork with it
380 2015-10-02T20:25:17  <morcos> why would we what?
381 2015-10-02T20:25:46  <maaku> what would be the reason to have them in master as mempool only?
382 2015-10-02T20:26:00  <maaku> for some period of time that is, it obviously makes sense to break up the PRs that way
383 2015-10-02T20:26:20  <morcos> so they get a lot more real world testing
384 2015-10-02T20:27:09  <BlueMatt> morcos: hmmm...how did I convince myself that it was never used? :/
385 2015-10-02T20:27:16  <BlueMatt> (anymore)
386 2015-10-02T20:27:31  <maaku> (1) they can (and have) been tested on elements alpha, (2) i'm not sure what real world testing can be done until it is a consensus rule, that can't already be done against the PR before merging it
387 2015-10-02T20:27:51  <morcos> i mean i can see why waiting for 0.12 to release mempool only and months later for a soft fork roll out is too long to wait.  but i find it hard to imagine that i personally will be comfortable with acking it for a soft fork in the next couple weeks
388 2015-10-02T20:27:59  <morcos> 1) is a good point, i hadn't though tabout that
389 2015-10-02T20:28:20  <morcos> thats not to say i would NACK it, not at all, just i'd depend on other people being really comfortable with it
390 2015-10-02T20:28:54  <morcos> anyway, i'll keep reviewing, maybe comfort will come quicker, and at the very least we should get the mempool pulls merged as quickly as we can
391 2015-10-02T20:29:09  <maaku> morcos: maybe there's a reason to have it tested as mempool-only. but i'd like to actually see a test plan.
392 2015-10-02T20:29:55  <btcdrak> morcos we should get these ACKd, the ISM softfork would be a separate PR anyway, so there's no reason you couldnt ACK these as they are mempool only anyhow.
393 2015-10-02T20:30:50  <morcos> BlueMatt: certainly before you evicted on every pass, it was a requirement to avoid certain types of degenerate situations..  i remember being glad it was there on several occasions.  i _think_ its not required any more, but i'm not sure whether its better or worse with it.
394 2015-10-02T20:31:02  <morcos> btcdrak: yes agreed, see my prior mesg
395 2015-10-02T20:32:33  <BlueMatt> morcos: well its obviously non-optimal in the case you just proposed
396 2015-10-02T20:33:00  <BlueMatt> welll, maybe not
397 2015-10-02T20:33:23  <BlueMatt> so I'm gonna leave it in
398 2015-10-02T20:33:48  <morcos> BlueMatt: leave what in?
399 2015-10-02T20:34:14  <BlueMatt> hmm, I dunno, so the metric I was targeting (which it seems we can hit) is to optimize average feerate in mempool
400 2015-10-02T20:34:24  <morcos> I'd vote for reverting it to max, but I can't make a concrete argument thats better.
401 2015-10-02T20:34:27  <maaku> morcos: my frustration re: this is that I've seen stuff get shelved on multiple occasions for reasons such as "to get more real world testing", but really all that seems to happen is delay because nothing gets done in the interim
402 2015-10-02T20:34:53  <maaku> if we need to delay for mempool testing, then that's fine, but we need to be explicit about what needs to be tested before advancing to the next stage
403 2015-10-02T20:34:56  <morcos> BlueMatt: I don't think you should be worrying about optimizing for that metric.  Worry about attacks and not doing anything stupid.
404 2015-10-02T20:35:04  <BlueMatt> suresure
405 2015-10-02T20:35:40  <BlueMatt> i wasnt suggesting deciding based on that metric, but that that metric is what we can make an algorithm that isnt trivially attack-able and is optimal
406 2015-10-02T20:36:21  <BlueMatt> in the above case, using a max() will result in a larger mempool with lower feerate
407 2015-10-02T20:36:42  <BlueMatt> which I kinda like
408 2015-10-02T20:36:46  <BlueMatt> so, yea, I'd prefer leaving it in
409 2015-10-02T20:36:50  <BlueMatt> (I already pushed that, anyway)
410 2015-10-02T20:36:53  <sdaftuar> maaku: i've been reviewing #6312, and one thing jumps out at me
411 2015-10-02T20:37:10  <jgarzik> What are good pre-reqs for time based limiting?  bluematt's stuff
412 2015-10-02T20:37:11  <sdaftuar> i don't understand how we're using the new LockTime() function in ContextualCheckBlock
413 2015-10-02T20:37:12  <jgarzik> ?
414 2015-10-02T20:37:27  <sdaftuar> pcoinsTip isn't being updated between transactions in the caller
415 2015-10-02T20:37:48  <sdaftuar> so i don't get how the LockTime code can be doing the right thing, in the case of a chain of transactions within a block?
416 2015-10-02T20:38:14  <sdaftuar> i know it's not relevant for the mempool-only case, but it seems like a problem when we want to make it part of consensus
417 2015-10-02T20:38:23  <maaku> sdaftuar: in that case it isn't being called with pcoinsTip, it is using the block validation view
418 2015-10-02T20:38:29  <maaku> the consensus code doesn't use pcoinsTip
419 2015-10-02T20:39:00  <sdaftuar> ContextualCheckBlock() does, right?
420 2015-10-02T20:39:43  <morcos> jgarzik: i didn't understand your question.  i think BlueMatt is adding time based expiration similar to sipa's commit from 6557 right?
421 2015-10-02T20:41:21  <maaku> sdaftuar: you are correct. hrm. working around sipa's nits broke that
422 2015-10-02T20:41:28  <morcos> BlueMatt: was the time based commit going to be added to 6722?  what else is left to do?  i'm kind of waiting til you say "done" to start diving into it again.
423 2015-10-02T20:41:39  <maaku> (prior versions would skip inputs that weren't found)
424 2015-10-02T20:42:12  <jgarzik> ditto
425 2015-10-02T20:42:30  <jgarzik> morcos, BlueMatt: I thought time-based was "later" but may have misunderstood.
426 2015-10-02T20:44:01  <sdaftuar> i don't think skipping would be safe either, would it?
427 2015-10-02T20:44:19  <sdaftuar> you might have a transaction that can't be spent until a block after its parent...
428 2015-10-02T20:44:52  <sdaftuar> i'm not sure but i don't believe that ConnectBlock redoes the LockTime() tests (?)
429 2015-10-02T20:45:55  <morcos> maaku: btw, i think the answer to my question a few mins ago is that its already non-standard to create txs which violate the new rules, because they have to be nVersion=2.  i hadn't caught that that makes it safer to go straight to soft fork.
430 2015-10-02T20:46:24  <BlueMatt> morcos: I was figuring I'd just leave the timeout-ing to right afterwards, and adding multiple txn in one step, too
431 2015-10-02T20:46:34  <BlueMatt> so....go review?
432 2015-10-02T20:46:41  <BlueMatt> all thats left that I know of is writing tests
433 2015-10-02T20:46:49  <BlueMatt> it may be very broken right now and I wouldnt know it
434 2015-10-02T20:47:32  <morcos> BlueMatt: you didn't adddress the DynamicMemoryUsage calculation then.  its already set up to include a time index, which wouldn't be part of your pull
435 2015-10-02T20:47:41  <morcos> i commented on the pull about that earlier
436 2015-10-02T20:48:14  <morcos> i say just add the Expire() commit, its short and simple and basically stands alone
437 2015-10-02T20:48:29  <jgarzik> BlueMatt, +1   :)
438 2015-10-02T20:48:35  <morcos> and i think it really helps to reason about how the whole mempool is kept limited
439 2015-10-02T20:49:29  <morcos> (but definitely hold off on the multiple txs piece!  i'm not sure i even agree thats something we want to do, RBF is so much superior)
440 2015-10-02T20:49:45  <sdaftuar> wow that is way shorter code
441 2015-10-02T20:49:49  <maaku> sdaftuar: I'm investigating -- that was my memory that ConnectBlock redoes the LockTime() tests with context
442 2015-10-02T20:50:04  <maaku> but I'm having trouble finding it
443 2015-10-02T20:51:08  <jgarzik> Does CLTV/CSV enable a situation where you can create tiered time locks:  funds frozen on chain.  At time X, pubkey A can redeem.  At time X+N, pubkeys (A,B) can redeem.
444 2015-10-02T20:52:00  <maaku> jgarzik: yes that's the driving purpose
445 2015-10-02T20:52:04  <jgarzik> The idea is a custodian could hold a backup key for the later time period, if funds are not claimed by active and aware participants.
446 2015-10-02T20:52:14  <btcdrak> jgarzik: yup.
447 2015-10-02T20:52:17  <gmawell> jgarzik: of course, as its just a script opcode. :)
448 2015-10-02T20:52:41  <morcos> maaku: interpreter.cpp calls CheckLockTime
449 2015-10-02T20:52:43  <gmawell> if () {lock1 condition} elsif () {lock2 condition2} ....
450 2015-10-02T20:53:06  <jgarzik> CLTV can do this alone, yes?
451 2015-10-02T20:53:13  <morcos> EvalScript I should say
452 2015-10-02T20:53:24  <jgarzik> It appears so.
453 2015-10-02T20:53:30  <maaku> morcos: different CheckLockTime (ugh, sorry about that)
454 2015-10-02T20:53:50  <maaku> the interpreter.cpp one is a method of SignatureChecker
455 2015-10-02T20:53:57  <morcos> oh yeah of course, thats horrible
456 2015-10-02T20:54:12  <maaku> yeah didn't even notice until now
457 2015-10-02T20:55:30  *** gmawell is now known as gmaxwell
458 2015-10-02T20:55:51  * btcdrak just had a cup of coffee
459 2015-10-02T20:56:04  <btcdrak> *gmaxwell
460 2015-10-02T20:59:22  <BlueMatt> morcos: it stands well alone is exactly why it should be its own pr :p
461 2015-10-02T20:59:48  <morcos> BlueMatt: i regreted that choice of words before I hit Enter
462 2015-10-02T20:59:55  <BlueMatt> :)
463 2015-10-02T20:59:59  <BlueMatt> morcos: yes, but the earlier comment was "the 9 is wrong"
464 2015-10-02T21:00:01  <BlueMatt> not what it should be
465 2015-10-02T21:00:20  <morcos> i think its supposed to be 3 * the number of indices
466 2015-10-02T21:00:22  <BlueMatt> so the 9 should be 3
467 2015-10-02T21:00:22  <morcos> so 6
468 2015-10-02T21:00:24  <BlueMatt> and then its fine?
469 2015-10-02T21:00:26  <BlueMatt> oh, wait, what
470 2015-10-02T21:00:27  <morcos> no
471 2015-10-02T21:00:42  <morcos> unfortunately sdaftuar and i broke it in master already
472 2015-10-02T21:00:43  <BlueMatt> the 9 should be 6 and then its fine?
473 2015-10-02T21:00:53  <morcos> DynamicMemoryUsage is 9 (and hsould be 6) in master
474 2015-10-02T21:01:00  <BlueMatt> who's code is it anyway? (tm)
475 2015-10-02T21:01:07  <sdaftuar> was my fault :)
476 2015-10-02T21:01:12  <morcos> GuessDynamicMemoryUSage is new and should be the same as master
477 2015-10-02T21:01:17  <morcos> sorry
478 2015-10-02T21:01:22  <morcos> same as DynamicMemoryUsage
479 2015-10-02T21:01:24  <BlueMatt> ahh, ok
480 2015-10-02T21:01:27  <BlueMatt> I'll go fix both, then
481 2015-10-02T21:01:30  <morcos> so both should be 6 unless you add expiration
482 2015-10-02T21:01:33  <morcos> which is what you should do
483 2015-10-02T21:01:37  <morcos> so then they should both be 9
484 2015-10-02T21:01:46  <BlueMatt> I'll just do 6 and let you add expiration :)
485 2015-10-02T21:02:52  <morcos> (if i remain silent does it cause you to reconsider?)
486 2015-10-02T21:03:00  <BlueMatt> heh
487 2015-10-02T21:03:06  <BlueMatt> I'm gonna go rebase the whole pr
488 2015-10-02T21:03:10  <morcos> +!
489 2015-10-02T21:03:12  <morcos> 1
490 2015-10-02T21:14:08  <phantomcircuit> sipa, what ever happened to the normalized transaction id stuff?
491 2015-10-02T21:17:39  <morcos> maaku: btcdrak: its really confusing for someone who hasn't been following all along when the BIP's and the PR's are just completely different
492 2015-10-02T21:17:56  <morcos> for CSV, the BIP seems to be describing an earlier version?
493 2015-10-02T21:18:02  *** belcher_ has joined #bitcoin-core-dev
494 2015-10-02T21:19:31  <morcos> where is the most up to date version of BIP-112?
495 2015-10-02T21:21:47  <btcdrak> morcos, the BIP text needs updating, let me push that
496 2015-10-02T21:21:51  <btcdrak> (for 112)
497 2015-10-02T21:23:51  <morcos> btcdrak: i know BIPs are supposed to be descriptive, not proscriptive, but it sure would be helpful for proposed soft forks like this if there is a clear consensus on the semantics separately and first, and then the code can be reviewed for compliance with that
498 2015-10-02T21:24:41  *** n0n0__ has quit IRC
499 2015-10-02T21:25:15  <btcdrak> BIP68 was ironed out exactly that way. BIP112 just needs tweaking because of the references to BIP68.
500 2015-10-02T21:26:05  <morcos> ok fair enough
501 2015-10-02T21:28:52  <maaku> sorry btcdrak had authored new text for BIP 112. I didn't realize it hadn't been pushed
502 2015-10-02T21:36:16  <morcos> maaku: oh i didn't realize the name conflict on CheckLockTime goes away with CSV, that's good
503 2015-10-02T21:37:31  <morcos> oh spoke too soon, sorry
504 2015-10-02T21:49:37  <BlueMatt> morcos/jgarzik/sdafutar: ok, pushed a new version of #6722
505 2015-10-02T21:49:46  <BlueMatt> because expiry is so simple I went ahead and merged that
506 2015-10-02T21:49:54  <BlueMatt> I also squashed everything into reasonably reviewable bites
507 2015-10-02T21:50:25  <jgarzik> BlueMatt, does expiry occur even if mempool is not full?
508 2015-10-02T21:50:31  <BlueMatt> yes
509 2015-10-02T21:50:37  <jgarzik> good
510 2015-10-02T21:51:04  <morcos> BlueMatt: great!  just in time for me to call it a week however.  will review asap
511 2015-10-02T21:51:11  <morcos> why'd you make it 72 hours though
512 2015-10-02T21:51:14  <morcos> way too small
513 2015-10-02T21:52:10  <BlueMatt> because we dont have large-scale cpfp deployed by miners :(
514 2015-10-02T21:52:16  <morcos> if blocks are on average 90% full, then a 300MB mempool could last most of a week
515 2015-10-02T21:52:17  <BlueMatt> and the mempool limiting stuff assumes that
516 2015-10-02T21:52:19  <morcos> ah
517 2015-10-02T21:52:36  <morcos> ok will review with that in mind
518 2015-10-02T21:55:18  <jgarzik> BlueMatt, with 10,000 txs in mempool, what is the expense of Expire() + TrimToSize() for each new tx?  (wall clock time /cpu cycles)
519 2015-10-02T22:00:16  <morcos> jgarzik: i did some measurements on old versions, and it was pretty fast, and its been made much much faster with matt's algo
520 2015-10-02T22:00:31  <morcos> the slow stuff is already merged which is calculating the descendant packages
521 2015-10-02T22:00:32  <BlueMatt> in terms of real cost, untested, in terms of complexity - its something like n*m^2*lgm where n is the number of packages to remove and m is the number of txn in that package
522 2015-10-02T22:00:52  <morcos> it wouldn't be a bad idea to measure it again now
523 2015-10-02T22:00:53  <jgarzik> as long as it's operating off a sorted index it's fine.  just want to avoid a bunch of whole-mempool walks in edge/worst cases.  reading now...
524 2015-10-02T22:01:05  <morcos> but the real question is yep, exactly, edge cases
525 2015-10-02T22:01:15  <morcos> so its more about thinking of whats the worst case we can encounter
526 2015-10-02T22:01:22  <BlueMatt> if you have a bunch of tiny packages, then its just n, which isnt so bad
527 2015-10-02T22:01:27  <BlueMatt> if you have very large packages, then n is 1
528 2015-10-02T22:01:57  <BlueMatt> the worst-case, really, is a large single txn comes in to replace a single package which has a TON of tiny txn
529 2015-10-02T22:02:42  <morcos> no i meant like the attack scenarios we were describing
530 2015-10-02T22:03:01  <morcos> shoot, i forgot i was supposed to draft an email to dev about reduced package sizes
531 2015-10-02T22:03:05  <jgarzik> expiry can also create orphans
532 2015-10-02T22:03:37  <morcos> CalculateDescendants makes sure all the descendants are found and also removed
533 2015-10-02T22:05:45  <dgenr8> expiring at 2 hours, and happily relying on replacement to bump fees is an interesting strategy
534 2015-10-02T22:07:34  <jgarzik> I think 2 hours is way too short for expiry
535 2015-10-02T22:09:18  <BlueMatt> honestly I think it should be closer to 12/24 with the current mempool limiting stuff
536 2015-10-02T22:09:53  * dgenr8 good to look at the latest fee estimates
537 2015-10-02T22:10:01  <jgarzik> 48 hours is my pref
538 2015-10-02T22:10:22  <BlueMatt> jgarzik: you forget the mempool limiting stuff assumes cpfp
539 2015-10-02T22:10:24  <BlueMatt> and miners dont have it
540 2015-10-02T22:10:35  <BlueMatt> so anything that is in mempool because of cpfp is essentially there until it times out
541 2015-10-02T22:10:38  <jgarzik> miners run big mempools anyway
542 2015-10-02T22:10:55  <BlueMatt> that is irrelevant
543 2015-10-02T22:11:27  <jgarzik> few use CPFP or descendents at all
544 2015-10-02T22:11:40  <BlueMatt> yes, thats my point
545 2015-10-02T22:11:45  <jgarzik> zero conf security actively incentives against it
546 2015-10-02T22:11:55  <jgarzik> & malleation
547 2015-10-02T22:12:18  <BlueMatt> what???
548 2015-10-02T22:12:50  <BlueMatt> as a miner, its clearly in your best interest to use cpfp
549 2015-10-02T22:13:23  <BlueMatt> there just isnt code to do so, so most dont
550 2015-10-02T22:13:29  <BlueMatt> well, not merged code, at least
551 2015-10-02T22:13:31  <BlueMatt> ie well-reviewed code
552 2015-10-02T22:13:48  <dgenr8> estimatefee 12 = 0.00008634; estimatefee 24 = 0.00006981
553 2015-10-02T22:13:59  <jgarzik> BlueMatt, think from the user PoV
554 2015-10-02T22:14:08  <BlueMatt> in any case, the point is, because miners dont do it, random nodes' mempools accept things that they hold because cpfp makes them have lots of fees
555 2015-10-02T22:14:20  <BlueMatt> so they hold these txn only because of cpfp and will hold them until they expire
556 2015-10-02T22:14:26  <BlueMatt> hence why a low expiry time makes sense
557 2015-10-02T22:14:31  <jgarzik> BlueMatt, in practice there are few descendents and malleation attacks make them even less likely
558 2015-10-02T22:14:41  <BlueMatt> what does this have to do with miners?
559 2015-10-02T22:14:45  <BlueMatt> yes, users dont use cpfp
560 2015-10-02T22:14:52  <BlueMatt> they should be using rbf
561 2015-10-02T22:14:53  <jgarzik> thus miners don't use cpfp
562 2015-10-02T22:15:07  <jgarzik> let's consider what -is- before -should be- :)
563 2015-10-02T22:15:15  <BlueMatt> miners dont because its not much extra income and the patches arent well-reviewed, not because they actively choose not to
564 2015-10-02T22:15:24  <BlueMatt> yes, thats what I'm saying.......
565 2015-10-02T22:15:42  <BlueMatt> of course all the mempool stuff being written today is written assuming we do cpfp in mining soon
566 2015-10-02T22:15:43  <jgarzik> if there is no user cpfp traffic, miners do not use cpfp (nor have an incentive to deploy it or bother with it much at all)
567 2015-10-02T22:15:44  <BlueMatt> which we should
568 2015-10-02T22:15:54  <BlueMatt> there is some, however
569 2015-10-02T22:16:01  <BlueMatt> and thus they should be using it
570 2015-10-02T22:16:34  <BlueMatt> in *any* case, writing a cpfp-included mining thing based on mempool tracking will make mining a TON more efficient in any case
571 2015-10-02T22:16:44  <BlueMatt> so we should do that
572 2015-10-02T22:17:50  <jgarzik> In theory sure.  But's it's optimizing for the "last 0.0001%"   Bitcoin isn't great for long chains of unconfirmed transactions.  Sure miners should capture those, but users and services will not generate them.
573 2015-10-02T22:18:06  <BlueMatt> we need to rewrite the mining stuff anyway
574 2015-10-02T22:18:07  <jgarzik> Just noting the context.  If it comes for free, great.  But don't put a lot of effort into supporting something users won't much use.
575 2015-10-02T22:18:08  <BlueMatt> because it sucks
576 2015-10-02T22:18:14  <BlueMatt> including cpfp in that is the logical decision
577 2015-10-02T22:19:15  <jgarzik> Including rarely used features isn't necessarily logical.
578 2015-10-02T22:19:18  <BlueMatt> in any case, this is way off topic from the original discussion - the mempool expiry time
579 2015-10-02T22:19:34  <BlueMatt> rarely used because you also cant use it, because miners dont care about it
580 2015-10-02T22:19:41  <BlueMatt> so its also a chicken-and-egg problem
581 2015-10-02T22:20:03  <BlueMatt> of course the real solution is rbf, but...well, people are against that for political reasons
582 2015-10-02T22:20:25  <dgenr8> if fee(12) and fee(24) were equal, should txes expire at 12?
583 2015-10-02T22:20:34  <BlueMatt> ?
584 2015-10-02T22:20:41  <dgenr8> see #'s above
585 2015-10-02T22:21:08  <jgarzik> no it's not quite chichen-and-egg.  users are incentivized against it because long chains of unconfirmed transactions do not work well in the bitcoin system.  that's not specific to CPFP but relevant to evaluating CPFP.
586 2015-10-02T22:21:17  <dgenr8> if they were equal, that amount gets you confirmed in 12 and nothing happens for the next 12 blocks
587 2015-10-02T22:21:24  *** PaulCapestany has quit IRC
588 2015-10-02T22:21:33  <BlueMatt> jgarzik: indeed, hence why we need RBF :p
589 2015-10-02T22:21:49  <jgarzik> BlueMatt, so you agree CPFP is mostly useless?  :)
590 2015-10-02T22:21:56  <BlueMatt> no, i dont agree its mostly useless
591 2015-10-02T22:22:07  <jgarzik> it's a miner "nice to have, in the rare occasions the code is triggered"
592 2015-10-02T22:22:09  <BlueMatt> its the next-best thing when people are against rbf for bullshit reasons
593 2015-10-02T22:22:19  <BlueMatt> its useful for the system as a whole
594 2015-10-02T22:22:22  <BlueMatt> very useful
595 2015-10-02T22:22:25  <BlueMatt> its just not as nice as rbf
596 2015-10-02T22:22:41  *** PaulCapestany has joined #bitcoin-core-dev
597 2015-10-02T22:22:45  <dgenr8> RBF solves an important need.  but that need is not more important than not destroying all confidence in 0conf
598 2015-10-02T22:22:57  <BlueMatt> dgenr8: I think you're comparing different numbers? estimatefee 12 is in 12 blocks, no? not 12 hours?
599 2015-10-02T22:23:03  <jgarzik> The businesses like Coinbase and Bitpay are fine with RBF -- if and only if there is a secure instant transaction tech in place
600 2015-10-02T22:23:11  <dgenr8> yes, im talking about 12 blocks = 2 hours
601 2015-10-02T22:23:19  <jgarzik> need a replacement first, hard requirement
602 2015-10-02T22:23:26  <jgarzik> *zero conf replacement
603 2015-10-02T22:23:41  <BlueMatt> the funny thing is rbf has almost zero effect on 0conf security
604 2015-10-02T22:23:54  <BlueMatt> its so hilariously insecure already that adding rbf to the mix doesnt make it materially worse
605 2015-10-02T22:23:58  *** wumpus has quit IRC
606 2015-10-02T22:24:04  <jgarzik> It matters from a practical standpoint
607 2015-10-02T22:24:09  <BlueMatt> people using 0confs today are doing so by betting most customers are not trying to rip them off
608 2015-10-02T22:24:17  <BlueMatt> which works fine for many people who have lots of customers
609 2015-10-02T22:24:30  <BlueMatt> and who do other kyc stuff
610 2015-10-02T22:24:37  <BlueMatt> so, they can keep doing that
611 2015-10-02T22:24:47  <BlueMatt> with or without rbf
612 2015-10-02T22:25:15  <jgarzik> Outside the theoretical world, deploying full bore RBF is anti social to several existing payment flows at major businesses
613 2015-10-02T22:25:18  <dgenr8> today, if you pay with a highly standard tx and miner respects first-seen, it's not that easy to get double-spent
614 2015-10-02T22:25:23  <BlueMatt> in any case, this is my point - people object to rbf because, whatever, which means we need cpfp
615 2015-10-02T22:25:35  <BlueMatt> jgarzik: how?!
616 2015-10-02T22:25:49  <BlueMatt> dgenr8: not true
617 2015-10-02T22:26:01  <jgarzik> Attacks become quite a bit easier
618 2015-10-02T22:26:03  <dgenr8> ah you'll want to enter my "double-spend me" contest
619 2015-10-02T22:26:05  <BlueMatt> dgenr8: also, the way "the big guys" are mostly doing it doesnt even check that miners have seen a tx
620 2015-10-02T22:26:10  <BlueMatt> or that its not double spent anywhere
621 2015-10-02T22:26:17  <jgarzik> There was an RBF attack spree the instant that Chinese pool turned it on
622 2015-10-02T22:26:19  <BlueMatt> jgarzik: not really, actually
623 2015-10-02T22:26:30  <BlueMatt> jgarzik: yea, because it was publicized
624 2015-10-02T22:26:37  <jgarzik> ...thus reality != theory
625 2015-10-02T22:26:47  <BlueMatt> so dont publicize it on reddit
626 2015-10-02T22:26:54  <jgarzik> There is real end user negative impact
627 2015-10-02T22:26:54  <BlueMatt> still, you're just proving my point - people reject to rbf, so we need cpfp
628 2015-10-02T22:26:59  <jcorgan> guys, can you take it to #bitcoin-dev or #bitcoin?
629 2015-10-02T22:27:08  <BlueMatt> because we need *something* for this usecase
630 2015-10-02T22:27:29  <jgarzik> CPFP is harmless, so no NAK.  Just will be rarely used feature.
631 2015-10-02T22:27:44  <jgarzik> Similar to code miners should have that sweeps anyone-can-pay into their wallet.
632 2015-10-02T22:27:54  <BlueMatt> then how do wallets who paid too little fee fix their stuck txn?
633 2015-10-02T22:28:11  <dgenr8> i actually think mempool expiration at 2 hours is the solution to replacement
634 2015-10-02T22:28:26  <jgarzik> Miners -should- be doing that, just like they -should- be deploying CPFP, a just-in-case capture.  It won't be used much at all though.
635 2015-10-02T22:29:04  <jgarzik> dgenr8, the lower the limit, the greater the traffic on the network
636 2015-10-02T22:30:27  <dgenr8> depends on the numbers then
637 2015-10-02T22:30:58  <jgarzik> yep, as with anything in life there is a zen balance to be achieved :)
638 2015-10-02T22:32:31  *** d_t has quit IRC
639 2015-10-02T22:32:58  <morcos> ahh i go away for 30 mins
640 2015-10-02T22:33:10  <morcos> you guys are touching on this, but its a very important point
641 2015-10-02T22:33:17  <morcos> we're conflating two completely different things
642 2015-10-02T22:33:35  <morcos> CPFP as a user action for helping a stuck tx is completely separate from CPFP as a mining algo
643 2015-10-02T22:33:40  <morcos> i couldn't care less about the first
644 2015-10-02T22:33:51  <morcos> but the second is just properly maximizing miner income
645 2015-10-02T22:34:00  <morcos> its very important that core includes a good algorithm for that
646 2015-10-02T22:34:23  <morcos> otherwise big miners that have the money and talent to do their own custom mining algos will have a significant advantag over small miners
647 2015-10-02T22:34:32  <BlueMatt> jeff's point is that it really doesnt matter today (go ask big miners - they dont care about fees, really)
648 2015-10-02T22:34:35  <morcos> its another example of where the default has to be really close enough to optimal
649 2015-10-02T22:34:42  <BlueMatt> however, if you have users using it for stuck txn, then it does matter
650 2015-10-02T22:34:52  <btcdrak> this really is a discussion for #bitcoin-dev or #bitcoin
651 2015-10-02T22:35:25  <morcos> this is exactly a discussion for core-dev we're trying to figure out how important it is to include CPFP in core's mining algo
652 2015-10-02T22:36:15  <BlueMatt> the big miners I've heard from dont care about fees, and are perfectly willing to forgo them to make bitcoin work properly for users - if users' wallets are using cpfp to unstick transactions, then it becomes required for bitcoin to work properly for users
653 2015-10-02T22:36:43  <btcdrak> CPFP is incredibly inefficient compared to RBF
654 2015-10-02T22:36:52  <Luke-Jr> is someone going to rewrite CPFP?
655 2015-10-02T22:36:56  <BlueMatt> indeed, but there are many rejections to rbf
656 2015-10-02T22:36:58  <morcos> btcdrak: exactly we're not talking about CPFP for users
657 2015-10-02T22:37:04  <Luke-Jr> btcdrak: they're not competitive, they solve different problems
658 2015-10-02T22:37:09  <BlueMatt> Luke-Jr: i dont think anyone has signed up to do so, yet
659 2015-10-02T22:37:18  <BlueMatt> Luke-Jr: it requires adding more mempool tracking
660 2015-10-02T22:37:23  * Luke-Jr not entirely sure why his CPFP was closed then.
661 2015-10-02T22:37:29  <BlueMatt> but it should all be inverse duplication of whats already there
662 2015-10-02T22:37:30  <morcos> sdaftuar and i are rewriting mining to be more optimal (which includes tracking ancestor package fee rates)
663 2015-10-02T22:37:38  <BlueMatt> Luke-Jr: the way to do it is to do ancestor package tracking
664 2015-10-02T22:37:41  <BlueMatt> ahh, ok, good
665 2015-10-02T22:37:42  <morcos> i'm going to stop calling it CPFP so poeple don't think i'm talking about adding a user feature
666 2015-10-02T22:38:02  <Luke-Jr> CPFP is what it's always been called, and doesn't imply anything like user features..
667 2015-10-02T22:38:02  <BlueMatt> morcos: please make sure to fix https://github.com/bitcoin/bitcoin/issues/6531 when you do
668 2015-10-02T22:38:28  <btcdrak> how is CPFP not a user feature?
669 2015-10-02T22:38:43  <BlueMatt> btcdrak: its both a user feature and a miner feature, is the point
670 2015-10-02T22:38:54  <Luke-Jr> morcos: if you're going to work on this stuff, it'd be nice to avoid the centralised policy problem we have now before it gets too deep ;)
671 2015-10-02T22:39:10  <Luke-Jr> btcdrak: users don't care *how* their transactions get confirmed
672 2015-10-02T22:39:16  <morcos> BlueMatt: i think that should be doable
673 2015-10-02T22:39:36  <BlueMatt> morcos: its easy, just not done yet
674 2015-10-02T22:39:47  <morcos> Luke-Jr: i'm thinking that the policy is adjusted by using your priorizeTransaction functionality
675 2015-10-02T22:39:57  <Luke-Jr> morcos: that is not sufficient/reasonable.
676 2015-10-02T22:40:08  <morcos> ha, well thats hard enough on its own
677 2015-10-02T22:40:13  <morcos> why is that not sufficient
678 2015-10-02T22:40:34  <btcdrak> OT: curious, who here, other than jgarzik and dgen8 are opposed to RBF?
679 2015-10-02T22:40:52  <morcos> btcdrak: heh, and i get yelled at.  :)
680 2015-10-02T22:40:55  <Luke-Jr> because then people need to figure out how to translate their policy into relationship with the default policy
681 2015-10-02T22:41:37  <Luke-Jr> it's already hard enough to implement policies; forcing people to implement *and* translate is even more work
682 2015-10-02T22:42:04  <btcdrak> morcos: if you cant beat them, join them? :-P
683 2015-10-02T22:42:06  <Luke-Jr> the goal is to make policy changes *easier*, not harder
684 2015-10-02T22:42:10  <morcos> ok, i think its worth me learning more about that, so maybe i'll ping you next week to try to learn a bit more about what policies look like
685 2015-10-02T22:43:23  <morcos> BlueMatt: to your point about miners not caring, i agree maybe the urgency isn't there at this exact second
686 2015-10-02T22:43:57  <morcos> but it could be important soon, and we shouldn't fall behind the curve
687 2015-10-02T22:44:14  <morcos> anyway, i really have to run now...  good night!
688 2015-10-02T22:44:26  <btcdrak> I mean, especially now that f2pool has RBF there's no reason we shouldnt add it to core
689 2015-10-02T22:44:39  <btcdrak> FSS-RBF at the very least..
690 2015-10-02T22:45:38  <Luke-Jr> frankly there was never a reason not to
691 2015-10-02T22:46:16  <BlueMatt> morcos: sure
692 2015-10-02T22:46:57  <Luke-Jr> other than perhaps encouraging miners not to use Core's policy code.. but that's a failure so far
693 2015-10-02T22:47:56  <btcdrak> The funny thing is the clutching onto insecure 0conf will go away when we have real instant paynebt via payment channels/LN
694 2015-10-02T22:48:06  <BlueMatt> btcdrak: yupp
695 2015-10-02T22:48:11  <BlueMatt> we're all looking forward to that :)
696 2015-10-02T22:48:22  <btcdrak> :)
697 2015-10-02T22:48:25  <Luke-Jr> btcdrak: well, that's not really relevant to merge-or-not, since miners can run RBF whether it's in Core or not
698 2015-10-02T22:49:03  <BlueMatt> does eligius still do rbf?
699 2015-10-02T22:49:25  <btcdrak> Luke-Jr: right, but I mean the people who are objecting on the grounds of 0conf lose their basis
700 2015-10-02T22:50:45  <phantomcircuit> jgarzik, it's the businesses responsibility to ensure that users are credit worthy if they are accepting unconfirmed transactions
701 2015-10-02T22:50:59  <dgenr8> btcdrak: do you need to replace your tx like, pronto?  can you wait 2 hours?
702 2015-10-02T22:51:25  <phantomcircuit> jgarzik, realistically they cannot rely on unconfirmed transactions to confirm when it is in the financial best interest of miners to run full replace by fee
703 2015-10-02T22:51:54  <phantomcircuit> jgarzik, long term it's going to do much more harm to them if we even try to make it less dangerous
704 2015-10-02T22:56:41  <btcdrak> dgenr8: think about fee bumps
705 2015-10-02T22:57:39  <dgenr8> btcdrak: yes, i'm asking how high-frequency fee-bumps need to be
706 2015-10-02T22:58:49  <phantomcircuit> jgarzik, also there is CPFP traffic on mainnet today
707 2015-10-02T23:01:56  <phantomcircuit> it's in the Schildbach wallet
708 2015-10-02T23:03:35  <BlueMatt> oh really?
709 2015-10-02T23:03:37  <BlueMatt> heh, thats cool
710 2015-10-02T23:05:20  <phantomcircuit> BlueMatt, it basically is useless though because miners aren't running cpfp
711 2015-10-02T23:05:36  <phantomcircuit> Luke-Jr, is eligius running cpfp?
712 2015-10-02T23:07:20  <BlueMatt> phantomcircuit: indeed
713 2015-10-02T23:07:29  <BlueMatt> cool that its deployed though, thats pretty awesome
714 2015-10-02T23:11:03  <Luke-Jr> yes, Eligius has been CPFP since like 2011 or 2012
715 2015-10-02T23:11:23  <Luke-Jr> which also means unless it gets updated for 0.12, we're going to have to stick to 0.11 ..
716 2015-10-02T23:13:55  <BlueMatt> I'm sure there will be a patch to do it on 0.12, even if not merged
717 2015-10-02T23:18:01  *** d_t has joined #bitcoin-core-dev
718 2015-10-02T23:22:16  *** randy-waterhouse has quit IRC
719 2015-10-02T23:43:27  *** BananaLotus has joined #bitcoin-core-dev