1 2017-05-06 02:12:05 0|jtimon|luke-jr: I isolated the new error in 9494, but I still don't understand it, did s/argsGlobal/gArgs/ accross the history but working on doing it more scripted as suggested by BlueMatt , so don't hurry up to ack until I say something in the PR (but never too early to nit)
2 2017-05-06 03:11:07 0|gmaxwell|sipa: https://cloud.githubusercontent.com/assets/548488/25769030/c84fe65e-31c4-11e7-8819-264c44e50ddf.png one heck of a graph on PR #10195
3 2017-05-06 03:11:09 0|gribble|https://github.com/bitcoin/bitcoin/issues/10195 | Switch chainstate db and cache to per-txout model by sipa ÷ Pull Request #10195 ÷ bitcoin/bitcoin ÷ GitHub
4 2017-05-06 03:21:33 0|achow101|where can I find the description of the fee estimation stuff?
5 2017-05-06 03:36:28 0|praxeology|Does the fee estimator take CPFP into account?
6 2017-05-06 03:39:14 0|gmaxwell|praxeology: it takes it into account by not being confused by it.
7 2017-05-06 03:44:50 0|praxeology|gmaxwell: that is a pretty evasive answer. I would guess it would take it into account by grouping all transactions that depend on each other in a block into one transaction, so long as children are higher fee/byte than parents
8 2017-05-06 03:45:44 0|gmaxwell|praxeology: IIRC it just ignores things with dependencies in its estimation, there are few enough that it doesn't matter.
9 2017-05-06 03:47:27 0|praxeology|I guess so. CPFP parents would probably be statistical outliers
10 2017-05-06 05:13:35 0|phantomcircuit|gmaxwell, that reminds me the cache shouldn't flush entries entirely like that
11 2017-05-06 05:13:59 0|sipa|phantomcircuit: working on it
12 2017-05-06 05:14:16 0|phantomcircuit|sipa, iirc i did this but couldn't get the change to pass tests...
13 2017-05-06 05:14:17 0|sipa|(but it is much harder than you may think)
14 2017-05-06 05:14:18 0|phantomcircuit|which was
15 2017-05-06 05:14:19 0|phantomcircuit|uh
16 2017-05-06 05:14:21 0|phantomcircuit|suspicious
17 2017-05-06 05:14:36 0|sipa|i've made it work fine, it just ended up being slower
18 2017-05-06 05:14:38 0|phantomcircuit|yeah but why is it harder
19 2017-05-06 05:14:51 0|sipa|due to more frequent flushing
20 2017-05-06 05:14:55 0|phantomcircuit|yeah it makes the flushing logic significantly harder
21 2017-05-06 05:15:30 0|sipa|i'm planning on a background thread flushing now, after #10148
22 2017-05-06 05:15:31 0|gribble|https://github.com/bitcoin/bitcoin/issues/10148 | [WIP] Use non-atomic flushing with block replay by sipa ÷ Pull Request #10148 ÷ bitcoin/bitcoin ÷ GitHub
23 2017-05-06 05:16:33 0|phantomcircuit|iirc what i ended up doing was randomly selecting sections to flush or something
24 2017-05-06 05:16:44 0|phantomcircuit|regardless of whether they just needed to be written or not
25 2017-05-06 05:16:52 0|phantomcircuit|and kept a list of things which needed to be written
26 2017-05-06 05:17:08 0|phantomcircuit|which of course increased memory usage because i did it poorly
27 2017-05-06 10:02:51 0|bitcoin-git|13bitcoin/06master 14965a124 15John Newbery: [tests] Fix abandonconflict.py intermittency
28 2017-05-06 10:02:51 0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02 https://github.com/bitcoin/bitcoin/compare/35da2aeed7d4...e9274839bf31
29 2017-05-06 10:02:52 0|bitcoin-git|13bitcoin/06master 14e927483 15MarcoFalke: Merge #10344: [tests] Fix abandonconflict.py intermittency...
30 2017-05-06 10:03:16 0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #10344: [tests] Fix abandonconflict.py intermittency (06master...06fix_abandon_conflict) 02 https://github.com/bitcoin/bitcoin/pull/10344
31 2017-05-06 10:10:04 0|bitcoin-git|13bitcoin/06master 14f19abd9 15Suhas Daftuar: [qa] Fixes segwit block relay test after inv-direct-fetch was disabled...
32 2017-05-06 10:10:04 0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02 https://github.com/bitcoin/bitcoin/compare/e9274839bf31...314ebdfcb38d
33 2017-05-06 10:10:05 0|bitcoin-git|13bitcoin/06master 14314ebdf 15MarcoFalke: Merge #10134: [qa] Fixes segwit block relay test after inv-direct-fetch was disabled...
34 2017-05-06 10:10:21 0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #10134: [qa] Fixes segwit block relay test after inv-direct-fetch was disabled (06master...062017-03-fix-segwit-relay-test) 02 https://github.com/bitcoin/bitcoin/pull/10134
35 2017-05-06 10:23:41 0|bitcoin-git|13bitcoin/06master 143e3c22f 15John Newbery: [tests] fix wait_for_inv()
36 2017-05-06 10:23:41 0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02 https://github.com/bitcoin/bitcoin/compare/314ebdfcb38d...170bc2c381f8
37 2017-05-06 10:23:42 0|bitcoin-git|13bitcoin/06master 14170bc2c 15MarcoFalke: Merge #10318: [tests] fix wait_for_inv()...
38 2017-05-06 10:24:01 0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #10318: [tests] fix wait_for_inv() (06master...06fix_wait_for_inv) 02 https://github.com/bitcoin/bitcoin/pull/10318
39 2017-05-06 11:19:36 0|SopaXorzTaker|guys, will including an invalid public key in a tx, such as (0, 0), which obviously doesn't follow the y^2=x^3+7 rule, ever invalidate a multisig script
40 2017-05-06 11:20:13 0|SopaXorzTaker|This is about core development, as this approach is currently valid but may stop being so in the future
41 2017-05-06 11:20:21 0|SopaXorzTaker|my vanity P2SH address generator relies on that
42 2017-05-06 15:47:57 0|sipa|SopaXorzTaker: there is currently no consensus rule that forbids that
43 2017-05-06 15:48:36 0|sipa|though it is a bit complicated since bip66
44 2017-05-06 15:51:01 0|luke-jr|there's no reason to assume there won't be a consensus rule in the future that does forbid it, although IMO such a rule shouldn't affect existing UTXOs, and it's hard to see how it could prevent new ones
45 2017-05-06 15:51:25 0|luke-jr|either way though, it's not something that should be done ;)
46 2017-05-06 15:51:56 0|SopaXorzTaker|luke-jr, I'll resort to using compressed dummy keys then
47 2017-05-06 15:52:26 0|luke-jr|SopaXorzTaker: that's probably worse
48 2017-05-06 15:52:34 0|SopaXorzTaker|hwy?
49 2017-05-06 15:52:37 0|SopaXorzTaker|why?
50 2017-05-06 15:52:43 0|luke-jr|if you must do one or the other, use the one that uses less space
51 2017-05-06 15:53:33 0|luke-jr|SopaXorzTaker: because the only reason not to do it, is the abusive nature of adding unnecessary data; and compressed dummy keys is just as abusive
52 2017-05-06 15:55:21 0|SopaXorzTaker|why?
53 2017-05-06 15:55:30 0|SopaXorzTaker|because they have to be chacked
54 2017-05-06 15:55:34 0|SopaXorzTaker|checked?
55 2017-05-06 15:57:03 0|luke-jr|or at least downloaded by every node
56 2017-05-06 15:57:16 0|SopaXorzTaker|wait
57 2017-05-06 15:57:26 0|SopaXorzTaker|what that has to do with compressed keys
58 2017-05-06 15:57:54 0|SopaXorzTaker|also, little offtopic: thanks for spending that puzzle P2SH address, I really appreciate my freedom :)