1 2016-04-14 00:13:57	0|BlueMatt|cfields_: the only logic in the added node stuff that I think is really useful to keep around is the logic around the connecting thread
  2 2016-04-14 00:15:51	0|cfields_|BlueMatt: yes, that's preserved.
  3 2016-04-14 00:16:10	0|BlueMatt|cfields_: eg if you change an added dns name's ip it should connect to one of the new ones
  4 2016-04-14 00:16:24	0|BlueMatt|though if you change the getaddednodeinfo stuff too much it'll be useless?
  5 2016-04-14 00:16:25	0|cfields_|BlueMatt: but as far as rpc is concerned, I think that logic should kinda be a black box. It should only be reporting which addresses you've requested to connect to, and which are currently connected
  6 2016-04-14 00:16:41	0|BlueMatt|well how does it know which are currently connected without a dns lookup?
  7 2016-04-14 00:17:17	0|BlueMatt|unless you keep a cache from dns -> ip that is updated every time the connect thread runs through its loop
  8 2016-04-14 00:17:19	0|cfields_|BlueMatt: node should preserve the original dns as well as the resolved
  9 2016-04-14 00:17:48	0|BlueMatt|"original"?
 10 2016-04-14 00:17:54	0|BlueMatt|oh, you mean CNode?
 11 2016-04-14 00:18:06	0|cfields_|yea
 12 2016-04-14 00:18:41	0|BlueMatt|no, thats not sufficient...if you change the ip of a dns name, then the rpc will still report that you're connected even if you're not connected to the new name
 13 2016-04-14 00:19:05	0|cfields_|BlueMatt: that's my point though, doing a new resolve won't necessarily give you the same results. For ex, if you add a seed node, which has a very short ttl, you won't find a match if you resolve again a few min later
 14 2016-04-14 00:19:14	0|BlueMatt|this is confusing because now the background thread is doing something that is inconsistent with what the rpc will show you
 15 2016-04-14 00:19:53	0|BlueMatt|ehh, I'm less concerned about that, but if thats your concern then it seems the only way is for the background addnodes thread to keep a cache of its resolutions
 16 2016-04-14 00:19:58	0|cfields_|BlueMatt: ah i see your point
 17 2016-04-14 00:22:46	0|BlueMatt|I guess I see the RPC as answering the question "Am I currently connected to what the background thread would connect to if it ran right now?"
 18 2016-04-14 00:22:51	0|cfields_|BlueMatt: erm wait no, that doesn't follow. If i addnode foo.com, it resolves to 1.2.3.4, connects, then changes to 5.6.7.8, i'd say it's reasonable for rpc to report that foo.com is connected.
 19 2016-04-14 00:24:40	0|cfields_|yes, i see now that it's unclear.
 20 2016-04-14 00:24:55	0|BlueMatt|yea, I prefer the RPC to work the other way
 21 2016-04-14 00:25:18	0|BlueMatt|I'd say the RPC thread should report that it is not connected, because that would imply to the user that its going to try to connect
 22 2016-04-14 00:25:20	0|BlueMatt|which it is
 23 2016-04-14 00:26:35	0|cfields_|ah, there's the problem. i didn't get that logic right after all :)
 24 2016-04-14 00:28:37	0|cfields_|BlueMatt: thanks, understood now. I'll fix that up.
 25 2016-04-14 07:13:22	0|jonasschnelli|lmdb -reindex with default dbcache took ~6h42' http://pastebin.com/ERWMGb1p
 26 2016-04-14 07:14:30	0|jonasschnelli|So ~2.5* slower then leveldb on the 4core 64bit linux machine I have testes.
 27 2016-04-14 07:14:56	0|gmaxwell|doesn't really make sense that reindex would be slower.
 28 2016-04-14 07:15:02	0|gmaxwell|since the sync is so much faster.
 29 2016-04-14 07:15:09	0|gmaxwell|must be some reindex specific bug.
 30 2016-04-14 07:15:22	0|jonasschnelli|gmaxwell: the sync is faster because it didn't touch the db (was dbcache=9000)
 31 2016-04-14 07:15:43	0|gmaxwell|jonasschnelli: I benchmarked lmdb sync last weekend with default db cache.
 32 2016-04-14 07:15:50	0|gmaxwell|it was _significantly_ faster than leveldb.
 33 2016-04-14 07:16:04	0|jonasschnelli|hmm...
 34 2016-04-14 07:16:47	0|gmaxwell|5 hours 5 minutes vs 8 hours 27minutes.
 35 2016-04-14 07:16:51	0|jonasschnelli|I'll do now a reindex with the same parameter on current master (leveldb).
 36 2016-04-14 07:17:31	0|wumpus|so normally a reindex takes 2h40 on that machine with leveldb with default params?
 37 2016-04-14 07:18:23	0|jonasschnelli|Hmm... the 2h40 was a sync from random peers. Not sure if I acctually did a reindex with leveldb. Doing now.
 38 2016-04-14 07:18:49	0|jonasschnelli|I mean these are not scientific benchmarks... I'm just playing around.
 39 2016-04-14 07:18:51	0|wumpus|compare reindex against reindex please :)
 40 2016-04-14 07:18:59	0|jonasschnelli|yes. I'll do now.
 41 2016-04-14 07:19:07	0|wumpus|sync from network can be faster than reindex in some cases
 42 2016-04-14 07:19:12	0|gmaxwell|do we still have the thing where signature checks run during reindex at all blocks?
 43 2016-04-14 07:19:21	0|jonasschnelli|I just expected the lmdb reindex to be faster then the leveldb random peer sync
 44 2016-04-14 07:19:41	0|jonasschnelli|But right. could be an performance issue in reindex
 45 2016-04-14 07:19:46	0|wumpus|(for that reason I tend to benchmark syncing from a fast local-network peer instead of reindex these days)
 46 2016-04-14 07:20:36	0|wumpus|gmaxwell: I don't know, I don't think I even know of that issue
 47 2016-04-14 07:20:47	0|NicolasDorier|wumpus: how is it possible ? as I thought reindex would do less work than a resync
 48 2016-04-14 07:21:23	0|wumpus|NicolasDorier: you'd expect so
 49 2016-04-14 07:22:13	0|gmaxwell|yes it appears we do.
 50 2016-04-14 07:22:24	0|gmaxwell|wumpus: I complained about it so much that I gave up complaining.
 51 2016-04-14 07:22:27	0|wumpus|NicolasDorier: the difference is that a reindex doesn't need to write to block files, just read, and does so linearly instead of haphazard
 52 2016-04-14 07:22:32	0|wumpus|gmaxwell: did you ever file a github issue?
 53 2016-04-14 07:22:36	0|gmaxwell|It's mildly hard to fix.
 54 2016-04-14 07:22:38	0|gmaxwell|lemme see
 55 2016-04-14 07:22:54	0|gmaxwell|and it looks still unfixed.
 56 2016-04-14 07:23:23	0|wumpus|please do file an issue if there is none, complaining on IRC always gets lost
 57 2016-04-14 07:23:41	0|gmaxwell|basically the reindex doesn't run headers first, so it doesn't have the headers ahead of the blocks
 58 2016-04-14 07:23:48	0|gmaxwell|thus         if (pindexLastCheckpoint && pindexLastCheckpoint->GetAncestor(pindex->nHeight) == pindex) {
 59 2016-04-14 07:23:51	0|gmaxwell|doesn't work.
 60 2016-04-14 07:23:57	0|gmaxwell|and scriptchecks run on all blocks.
 61 2016-04-14 07:24:08	0|jonasschnelli|okay. Thats explains it.
 62 2016-04-14 07:24:12	0|jonasschnelli|We need to fix that. :)
 63 2016-04-14 07:24:17	0|wumpus|yes
 64 2016-04-14 07:24:19	0|gmaxwell|I'm looking to see if there is an issue. I believe there was.
 65 2016-04-14 07:24:23	0|NicolasDorier|wumpus: if reindex does not need to write to block file, why is it slower ? it does not make sense oO
 66 2016-04-14 07:24:33	0|wumpus|NicolasDorier: read what gmaxwell writes above
 67 2016-04-14 07:24:36	0|gmaxwell|secp256k1 made it so much faster that it was like fixing it... at least for a bit, chain growth is compensating. :)
 68 2016-04-14 07:25:35	0|wumpus|this is not a concurrent i/o issue but a validation issue, apparently, I also always assumed it had something to do with i/o but reasoning that through doesn't make a single bit of sense
 69 2016-04-14 07:25:47	0|NicolasDorier|oh
 70 2016-04-14 07:25:55	0|NicolasDorier|I understand, thanks
 71 2016-04-14 07:26:30	0|NicolasDorier|well, if you want to test performance, it is better to NOT have checkpoints right ?
 72 2016-04-14 07:26:48	0|gmaxwell|NicolasDorier: sure but it resulted in jonasschnelli doing an apples/oranges test.
 73 2016-04-14 07:26:48	0|wumpus|depends on what performance you want to measure, just compare apples against apples
 74 2016-04-14 07:26:50	0|GitHub33|13bitcoin/06master 144a1d5c1 15fanquake: [Doc] Update gitian build guide to debian 8.4.0
 75 2016-04-14 07:26:50	0|GitHub33|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/514993554c37...8bb5d3dff46d
 76 2016-04-14 07:26:51	0|GitHub33|13bitcoin/06master 148bb5d3d 15Wladimir J. van der Laan: Merge #7838: [Doc] Update gitian build guide to debian 8.4.0...
 77 2016-04-14 07:27:00	0|GitHub9|[13bitcoin] 15laanwj closed pull request #7838: [Doc] Update gitian build guide to debian 8.4.0 (06master...06gitian-debian-84) 02https://github.com/bitcoin/bitcoin/pull/7838
 78 2016-04-14 07:27:00	0|gmaxwell|https://github.com/bitcoin/bitcoin/issues/7875
 79 2016-04-14 07:27:14	0|wumpus|if you want to compare pure database performance, disabling validation makes some sense
 80 2016-04-14 07:27:17	0|jonasschnelli|gmaxwell: Yes. Right. Now started comparing Apple/Apples (reindex leveldb is running).
 81 2016-04-14 07:27:34	0|jonasschnelli|What we really want is a db benchmark script.
 82 2016-04-14 07:27:38	0|gmaxwell|in any case, we'd also like to get rid of checkpoints for script check bypassing, but what we'd replace them with would also need the headers... so...
 83 2016-04-14 07:27:43	0|jonasschnelli|script = test-suite thing.
 84 2016-04-14 07:28:51	0|wumpus|well it's easy enough to write a script that compares leveldb and lmdb (see e.g. the one in blockdb-troubleshoot that copies db-to-db), however what we want to measure is bitcoind's specific usage pattern not some dumb micro-benchmark - and that's almost impossible with an external script :)
 85 2016-04-14 07:30:59	0|wumpus|I agree though that a more reproducible kind of benchmark would be nice. In principle a reindex with disabled validation wouldb e an ok one I think
 86 2016-04-14 07:31:16	0|jonasschnelli|Right. That could work.
 87 2016-04-14 07:31:24	0|wumpus|(at least not anything that involves internet peers)
 88 2016-04-14 07:31:35	0|jonasschnelli|I think sync from a local peer is also not really representative.
 89 2016-04-14 07:31:43	0|wumpus|why not?
 90 2016-04-14 07:32:05	0|jonasschnelli|The local peer could do some other work during your test (like a backup or a heavy log rotate, etc.).
 91 2016-04-14 07:32:24	0|gmaxwell|if it's local you control that.
 92 2016-04-14 07:32:44	0|wumpus|well no I make sure it is completely available to the other node for downloading, it has no other network connections
 93 2016-04-14 07:32:51	0|gmaxwell|bigger problem is that low latency peers will conceal pipelining failures.
 94 2016-04-14 07:32:51	0|jonasschnelli|Sure. But I'd prefer something that exclude network and another linux.
 95 2016-04-14 07:33:15	0|gmaxwell|like, if you fetch one block at a time, a local peer will not be that slow, but then add a 50ms RTT and it's MUCH slower.
 96 2016-04-14 07:33:32	0|gmaxwell|of course, one can simulate real networks locally using dummynet.
 97 2016-04-14 07:33:50	0|wumpus|yes there it gets into really difficult territory
 98 2016-04-14 07:33:54	0|jonasschnelli|I think the reindex with disabled verification is probably better
 99 2016-04-14 07:33:54	0|wumpus|benchmarking the network code
100 2016-04-14 07:34:02	0|wumpus|we're in 'benchmarking for dummies' here with the database :)
101 2016-04-14 07:34:05	0|gmaxwell|jonasschnelli: depends on what you're testing.
102 2016-04-14 07:34:21	0|jonasschnelli|For the db performance comparison
103 2016-04-14 07:34:52	0|wumpus|for the db performance comparison using a reliable local peer is good enough - that won't be the bottleneck
104 2016-04-14 07:34:58	0|gmaxwell|e.g. faults in the database handling can take the form of excessive seralization such that IO and network doesn't overlap; testing only with reindex will hide that.
105 2016-04-14 07:35:13	0|wumpus|if you want to test pipelining in networking, well, good luck, there's stacks of books written about that :)
106 2016-04-14 07:35:17	0|gmaxwell|so my point is that the reindex like test is informative, but not complete.
107 2016-04-14 07:35:42	0|gmaxwell|wumpus: one can do a lot better just by testing with a more realistic setup.
108 2016-04-14 07:35:47	0|wumpus|maybe we can find a phd student hehe
109 2016-04-14 07:36:14	0|wumpus|gmaxwell: sure
110 2016-04-14 07:36:22	0|gmaxwell|e.g. for the testing for the recent inv changes sipa and I are working on, I setup a 14 node topology.
111 2016-04-14 07:36:55	0|gmaxwell|(with actual systems, though that test could have been done with dummynet and VMs okay, I think)
112 2016-04-14 07:36:59	0|wumpus|tools that reproduce internet circumstances on a simluated network are great for that, absolutely
113 2016-04-14 07:58:46	0|mase|hey
114 2016-04-14 07:59:05	0|mase|I am unravling the secrets of bitcion
115 2016-04-14 09:25:53	0|jonasschnelli|We really need something like https://github.com/bitcoin/bitcoin/pull/7551 for 0.13
116 2016-04-14 09:26:27	0|jonasschnelli|Importing a couple of addresses (for watching) is sooo painful on mainnet today.
117 2016-04-14 09:26:40	0|wumpus|I'm just in the preparations for merging it
118 2016-04-14 09:27:11	0|wumpus|agree, of course, it was long due
119 2016-04-14 09:27:35	0|sipa|concept ack on importmulti
120 2016-04-14 09:27:39	0|jonasschnelli|I also blame myself because I have never tested PR #7551
121 2016-04-14 09:27:48	0|sipa|sorry for not having looked at it more
122 2016-04-14 09:28:24	0|jonasschnelli|wumpus: while you at it (*duck*): https://github.com/bitcoin/bitcoin/pull/7518
123 2016-04-14 09:28:25	0|jonasschnelli|This PR seems also very valuable.
124 2016-04-14 09:28:36	0|sipa|wumpus: can you wait one second
125 2016-04-14 09:28:44	0|jonasschnelli|I have tested it a couple of times... but probably needs at least another tACK
126 2016-04-14 09:29:10	0|wumpus|jonasschnelli: will take a look
127 2016-04-14 09:43:05	0|wumpus|thanks for the review on #7551 sipa
128 2016-04-14 10:09:12	0|GitHub43|[13bitcoin] 15laanwj pushed 4 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/8bb5d3dff46d...536b75e946fb
129 2016-04-14 10:09:13	0|GitHub43|13bitcoin/06master 1411114a6 15MarcoFalke: [amount] test negative fee rates and full constructor
130 2016-04-14 10:09:13	0|GitHub43|13bitcoin/06master 14fa2da2c 15MarcoFalke: [amount] Add support for negative fee rates...
131 2016-04-14 10:09:14	0|GitHub43|13bitcoin/06master 14facf5a4 15MarcoFalke: [amount] tests: Fix off-by-one mistake
132 2016-04-14 10:09:22	0|GitHub175|[13bitcoin] 15laanwj closed pull request #7796: [amount] Add support for negative fee rates (06master...06Mf1604-amountNeg64) 02https://github.com/bitcoin/bitcoin/pull/7796
133 2016-04-14 10:09:30	0|jonasschnelli|sipa: > nOldFee already is enough for all previously replaced ones, so you only need to add minTxRelayFee to account for everything. That's the logic used by the replacement code as well.
134 2016-04-14 10:09:39	0|jonasschnelli|What if you need to add an input to fit the new fee?
135 2016-04-14 10:09:56	0|sipa|yes?
136 2016-04-14 10:10:15	0|jonasschnelli|bigger tx size, more fee required.
137 2016-04-14 10:10:18	0|GitHub187|13bitcoin/06master 14b778e59 15Wladimir J. van der Laan: Merge #7855: [doc] gitian: Replace precise with trusty...
138 2016-04-14 10:10:18	0|GitHub187|13bitcoin/06master 14fa6399d 15MarcoFalke: [doc] gitian: Replace precise with trusty
139 2016-04-14 10:10:18	0|GitHub187|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/536b75e946fb...b778e5993af9
140 2016-04-14 10:10:25	0|jonasschnelli|Just adding minTxRelayFee is not sufficient IMO
141 2016-04-14 10:10:26	0|sipa|jonasschnelli: yes, which the relay fee will account for
142 2016-04-14 10:10:37	0|sipa|minTxRelayFee is a feerate, you multiply it by the size of the tx
143 2016-04-14 10:11:01	0|jonasschnelli|But you don't know the size before you did ran the coinselection...
144 2016-04-14 10:11:50	0|jonasschnelli|rucksack problem, thats why I though running the CreateTransaction logic again
145 2016-04-14 10:12:36	0|jonasschnelli|s/rucksack/knapsack
146 2016-04-14 10:12:40	0|sipa|ok, i'm missing some context i think
147 2016-04-14 10:15:23	0|GitHub61|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/b778e5993af9...72c54e388315
148 2016-04-14 10:15:24	0|GitHub61|13bitcoin/06master 1485c807c 15Rusty Russell: getblockchaininfo: make bip9_softforks an object, not an array....
149 2016-04-14 10:15:24	0|GitHub61|13bitcoin/06master 14d12760b 15Rusty Russell: rpc-tests: handle KeyError nicely in test_framework.py...
150 2016-04-14 10:15:25	0|GitHub61|13bitcoin/06master 1472c54e3 15Wladimir J. van der Laan: Merge #7863: getblockchaininfo: make bip9_softforks an object, not an array....
151 2016-04-14 10:15:31	0|GitHub19|[13bitcoin] 15laanwj closed pull request #7863: getblockchaininfo: make bip9_softforks an object, not an array. (06master...06bip9-status-as-object) 02https://github.com/bitcoin/bitcoin/pull/7863
152 2016-04-14 10:18:29	0|sipa|do we backport 7863 to 0.12?
153 2016-04-14 10:25:48	0|wumpus|yes, it needs to be backported to 0.12 eventually
154 2016-04-14 10:26:14	0|wumpus|if there is 0.12.1rc3 may as well be in it
155 2016-04-14 10:27:02	0|Luke-Jr|I wonder sometimes if it should be named "bip9", but I can argue both ways, so I haven't brought it up.
156 2016-04-14 10:27:43	0|Luke-Jr|probably not important enough to matter
157 2016-04-14 10:28:30	0|wumpus|yes, feel no need to even have an opinion about it
158 2016-04-14 10:38:46	0|wumpus|cfields: let's have a chat some time about how to handle out-of-tree builds (#7466), I'd really like that working, we have two solutions, but I guess neither is mergeable yet and I'm not sure how to continue
159 2016-04-14 10:40:18	0|wumpus|(I'd really like to switch to a setup where the source code is on a different disk from the binaries)
160 2016-04-14 10:41:07	0|sipa|wumpus: squashfs? :p
161 2016-04-14 10:42:05	0|wumpus|lol would you compress the binaries or the source code?
162 2016-04-14 10:42:19	0|sipa|oops, i mean unionfs
163 2016-04-14 10:43:55	0|wumpus|could work I guess, but seems overkill, every project just supports out-of-tree builds except bitcoin core :)
164 2016-04-14 10:47:13	0|wumpus|but unionfs does look interesting, could help in some other cases
165 2016-04-14 10:47:55	0|sipa|hah, seems unionfs was the original used by Knoppix, since then there has been aufs (which was rejected by linux mainline, but the alternative overlayfs was merged)
166 2016-04-14 10:48:51	0|wumpus|the main motivation really (besides maybe performance) is to have a clearer separation between stuff that needs to be backed up and stuff that could just be rebuilt if lost
167 2016-04-14 10:50:28	0|sipa|maybe it would be interesting for me as well... whenever my laptop battaery dies while compiling bitcoin core (not surprisingly, that's the most common activity during which power fails), my git tree is corrupted
168 2016-04-14 11:39:18	0|GitHub62|[13bitcoin] 15laanwj closed pull request #7850: Removed call to `TryCreateDirectory` from `GetDefaultDataDir` in `src/util.cpp`. (06master...06issue7845) 02https://github.com/bitcoin/bitcoin/pull/7850
169 2016-04-14 12:47:05	0|GitHub198|13bitcoin/06master 144521f00 15Wladimir J. van der Laan: tests: add varints_bitpatterns test...
170 2016-04-14 12:47:05	0|GitHub198|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/229a17ca915c...ab8586e6677a
171 2016-04-14 12:47:06	0|GitHub198|13bitcoin/06master 14ab8586e 15Wladimir J. van der Laan: Merge #7849: tests: add varints_bitpatterns test...
172 2016-04-14 12:47:13	0|GitHub14|[13bitcoin] 15laanwj closed pull request #7849: tests: add varints_bitpatterns test (06master...062016_04_varint_bit_pattern_tests) 02https://github.com/bitcoin/bitcoin/pull/7849
173 2016-04-14 12:55:23	0|GitHub183|13bitcoin/06master 147e91f63 15Suhas Daftuar: Use txid as key in mapAlreadyAskedFor...
174 2016-04-14 12:55:23	0|GitHub183|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/ab8586e6677a...97d0b9889f15
175 2016-04-14 12:55:24	0|GitHub183|13bitcoin/06master 1497d0b98 15Wladimir J. van der Laan: Merge #7862: Use txid as key in mapAlreadyAskedFor...
176 2016-04-14 12:55:34	0|GitHub70|[13bitcoin] 15laanwj closed pull request #7862: Use txid as key in mapAlreadyAskedFor (06master...06inv-to-txid-mapalreadyaskedfor) 02https://github.com/bitcoin/bitcoin/pull/7862
177 2016-04-14 13:14:26	0|GitHub168|[13bitcoin] 15jtimon opened pull request #7876: Globals: Explicitly pass const CChainParams& to UpdateTip() (06master...060.12.99-globals-chainparams-updatetip) 02https://github.com/bitcoin/bitcoin/pull/7876
178 2016-04-14 13:47:36	0|GitHub171|13bitcoin/06master 145eeb913 15Pieter Wuille: Clean up lockorder data of destroyed mutexes...
179 2016-04-14 13:47:36	0|GitHub171|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/97d0b9889f15...491171f92954
180 2016-04-14 13:47:37	0|GitHub171|13bitcoin/06master 14491171f 15Wladimir J. van der Laan: Merge #7846: Clean up lockorder data of destroyed mutexes...
181 2016-04-14 13:47:41	0|GitHub9|[13bitcoin] 15laanwj closed pull request #7846: Clean up lockorder data of destroyed mutexes (06master...06cleanlocks) 02https://github.com/bitcoin/bitcoin/pull/7846
182 2016-04-14 14:10:31	0|GitHub48|13bitcoin/06master 1462a6486 15Pavel Janík: RPC: do not print ping info in getpeerinfo when no ping received yet, fix help
183 2016-04-14 14:10:31	0|GitHub48|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/491171f92954...d97101e5a84b
184 2016-04-14 14:10:32	0|GitHub48|13bitcoin/06master 14d97101e 15Wladimir J. van der Laan: Merge #7842: RPC: do not print minping time in getpeerinfo when no ping received yet...
185 2016-04-14 14:10:41	0|GitHub93|[13bitcoin] 15laanwj closed pull request #7842: RPC: do not print minping time in getpeerinfo when no ping received yet (06master...0620160408_getpeerinfo_no_ping_yet) 02https://github.com/bitcoin/bitcoin/pull/7842
186 2016-04-14 14:27:40	0|GitHub86|[13bitcoin] 15sipa opened pull request #7877: Change mapRelay to store CTransactions (06master...06relayctransaction) 02https://github.com/bitcoin/bitcoin/pull/7877
187 2016-04-14 14:35:23	0|GitHub101|13bitcoin/06master 144f7c959 15Jonas Schnelli: Refactor IsRBFOptIn, avoid exception
188 2016-04-14 14:35:23	0|GitHub101|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/d97101e5a84b...430fffefaab6
189 2016-04-14 14:35:24	0|GitHub101|13bitcoin/06master 14430fffe 15Wladimir J. van der Laan: Merge #7812: Tiny refactor of `IsRBFOptIn`, avoid exception...
190 2016-04-14 14:35:31	0|GitHub24|[13bitcoin] 15laanwj closed pull request #7812: Tiny refactor of `IsRBFOptIn`, avoid exception (06master...062016/04/rbf_refact) 02https://github.com/bitcoin/bitcoin/pull/7812
191 2016-04-14 14:45:26	0|jtimon|ping #7779
192 2016-04-14 15:47:15	0|GitHub90|[13bitcoin] 15laanwj closed pull request #7131: Add 'setblockmaxsize' RPC interface (06master...06setblockmaxsize) 02https://github.com/bitcoin/bitcoin/pull/7131
193 2016-04-14 17:55:27	0|OxADADA|we're using Kramdown for the bitcoin-core website, yes? GitHub is moving away from the other Markdown parsers.
194 2016-04-14 17:55:47	0|OxADADA|yes, we are using kramdown, we're good
195 2016-04-14 18:01:54	0|GitHub44|[13bitcoin] 15MarcoFalke opened pull request #7878: [test] bctest.py: Revert faa41ee (06master...06Mf1604-bctestPy) 02https://github.com/bitcoin/bitcoin/pull/7878
196 2016-04-14 18:11:40	0|jonasschnelli|Here is the comparison between reindex of current master vs wumpuses LMDB branch:
197 2016-04-14 18:11:40	0|jonasschnelli|http://pastebin.com/raw/evx62gak
198 2016-04-14 18:12:31	0|jonasschnelli|leveldb was 1.2842709773 faster
199 2016-04-14 18:19:34	0|jonasschnelli|Is there an rpc call to show the feerate of a rawtx? Or do I need to calc it myself strlen(hex/2)*estimatefee(2)?
200 2016-04-14 18:19:59	0|sipa|there is not even an rpc that can show the fee of a raw transaction :)
201 2016-04-14 18:20:10	0|sipa|oh, you mean the estimated necessary fee for a transaction?
202 2016-04-14 18:20:29	0|jonasschnelli|No. Forget about the example calculation above (its wrong).
203 2016-04-14 18:20:44	0|jonasschnelli|The absolute fee and the feerate would be nice.
204 2016-04-14 18:20:52	0|jonasschnelli|we should add that to decoderawtransaction
205 2016-04-14 18:21:31	0|sipa|we can't
206 2016-04-14 18:21:38	0|sipa|transactions don't have a "fee" field
207 2016-04-14 18:21:41	0|sipa|you need to know the input
208 2016-04-14 18:21:50	0|jonasschnelli|Lookup?
209 2016-04-14 18:22:08	0|sipa|decoderawtransaction decodes
210 2016-04-14 18:22:17	0|jonasschnelli|Thats true.
211 2016-04-14 18:22:19	0|sipa|it also doesn't tell you what scriptPubKeys were spent
212 2016-04-14 18:22:29	0|sipa|or what height the transaction is in
213 2016-04-14 18:22:38	0|sipa|furthermore, we generally *cannot* look that up
214 2016-04-14 18:22:43	0|jonasschnelli|Well, at least we could tell the estimate fee (size*estimatefee(2))
215 2016-04-14 18:22:47	0|sipa|because that information is no longer in the UTXO set
216 2016-04-14 18:23:00	0|jonasschnelli|Yes. Would only work for unspent inputs.
217 2016-04-14 18:23:06	0|sipa|right
218 2016-04-14 18:23:10	0|sipa|i guess that's still useful
219 2016-04-14 18:23:49	0|jonasschnelli|Hmm.. but can be confusing if the rawtx is not signed,... maybe estimating the signature size *duck*
220 2016-04-14 18:27:06	0|gmaxwell|showing an estimate fee there would be potentially dangerous when someone mistakes it for the actual fee.
221 2016-04-14 18:31:56	0|jonasschnelli|Yes. I think the nested command extension I have added to the GUI could be usefull for bitcoin-cli for such situations.
222 2016-04-14 18:32:28	0|jonasschnelli|estimatefee(2)*decoderawtransaction(<hex>)['size']
223 2016-04-14 18:32:52	0|jonasschnelli|missing a /1000
224 2016-04-14 18:34:10	0|gmaxwell|using decode raw transactions to determine the number of bytes in a hex string seems weird... also, was mentioned, it doesn't include signatures at the point where you're estimating the fee.
225 2016-04-14 18:34:47	0|gmaxwell|when you're author a transaction the fee calculation should be based on how many and what kind of inputs you're using and how many and what kind of outputs.
226 2016-04-14 18:34:49	0|jonasschnelli|Agree. decoderawtransaction(<hex>)['size'] is stupid
227 2016-04-14 18:35:00	0|jonasschnelli|Only makes sense if you also need other data form the call.
228 2016-04-14 18:43:05	0|sipa|gmaxwell: i guess it would be convenient past segwit
229 2016-04-14 18:43:07	0|sipa|to get vsize
230 2016-04-14 19:00:35	0|cfields|meeting?
231 2016-04-14 19:00:42	0|gmaxwell|Hi all.
232 2016-04-14 19:00:46	0|wumpus|I guess?
233 2016-04-14 19:00:48	0|sdaftuar|hello
234 2016-04-14 19:00:50	0|lightningbot|Meeting started Thu Apr 14 19:00:50 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
235 2016-04-14 19:00:50	0|wumpus|#startmeeting
236 2016-04-14 19:00:51	0|lightningbot|Useful Commands: #action #agreed #help #info #idea #link #topic.
237 2016-04-14 19:00:55	0|morcos|confidence inspiring wumpus
238 2016-04-14 19:01:01	0|btcdrak|gavel wont be attending due to last week's beating.
239 2016-04-14 19:01:04	0|cfields|heh
240 2016-04-14 19:01:06	0|gmaxwell|"If I have to."
241 2016-04-14 19:01:12	0|wumpus|topics?
242 2016-04-14 19:01:32	0|gmaxwell|Whats up with the 0.12.1 release? I haven't been paying attention to it.
243 2016-04-14 19:01:34	0|morcos|status of 12.1
244 2016-04-14 19:01:41	0|btcdrak|0.12.1 status
245 2016-04-14 19:01:57	0|wumpus|0.12.1 is at rc2
246 2016-04-14 19:02:28	0|wumpus|haven't heard of any issues with it
247 2016-04-14 19:02:36	0|gmaxwell|There was a 0.12.1(rc) block mined in the last week.
248 2016-04-14 19:02:41	0|sipa|i suggest we go ahead with release?
249 2016-04-14 19:02:50	0|jonasschnelli|+1
250 2016-04-14 19:02:53	0|btcdrak|+10
251 2016-04-14 19:02:56	0|sipa|-11
252 2016-04-14 19:03:01	0|btcdrak|doh!
253 2016-04-14 19:03:03	0|gmaxwell|+1i.
254 2016-04-14 19:03:46	0|sipa|gmaxwell: interesting; block version 0x2..?
255 2016-04-14 19:03:52	0|sipa|but not classic
256 2016-04-14 19:03:53	0|Luke-Jr|we should release 0.12.1 when 0.12.1 is observed to be released.
257 2016-04-14 19:04:18	0|sipa|Luke-Jr is the first member of the club containing Luke-Jr as first member
258 2016-04-14 19:04:33	0|gmaxwell|sipa: yes, it seems we kinda flubbed the part of the motivation with the BIP9 starting dates to remove the possibility of warings in advance of a release. :)
259 2016-04-14 19:04:36	0|Luke-Jr|that sounds lonely.
260 2016-04-14 19:04:38	0|wumpus|usually we wait a week after the release of the binaries before labeling the rc as final, the binary release was only 3 days ago
261 2016-04-14 19:04:44	0|sipa|wumpus: ok
262 2016-04-14 19:04:47	0|wumpus|but if you insist
263 2016-04-14 19:05:01	0|sipa|topic suggestion: segwit and backports
264 2016-04-14 19:05:07	0|btcdrak|let's insist
265 2016-04-14 19:05:08	0|jonasschnelli|Yes. We should wait at least one week.
266 2016-04-14 19:05:09	0|gmaxwell|sipa: but at least thats just a one time event.
267 2016-04-14 19:05:38	0|gmaxwell|well 1 week - 3 days is still before the next meeting. So the action should be release 0.12.1 prior to the next meeting. :)
268 2016-04-14 19:05:43	0|Luke-Jr|could start the gitian building now and wait the rest of the week to publish?
269 2016-04-14 19:06:11	0|btcdrak|1 business week is 5 days :)
270 2016-04-14 19:06:11	0|jonasschnelli|the tag could be seen as "release"
271 2016-04-14 19:06:27	0|wumpus|good to hear a block would mined with 0.12.1 though, hadn't heard that yet
272 2016-04-14 19:06:32	0|wumpus|s/would/was
273 2016-04-14 19:06:54	0|btcdrak|why not tag 0.12.1 we can build over the weekend and release on Monday?
274 2016-04-14 19:07:14	0|jonasschnelli|Why not tag on monday and build on monday?
275 2016-04-14 19:07:22	0|jonasschnelli|You don't need to handhold you bulder?
276 2016-04-14 19:07:24	0|sipa|wumpus decides
277 2016-04-14 19:07:26	0|gmaxwell|the building has latency.
278 2016-04-14 19:07:28	0|wumpus|you're too eager
279 2016-04-14 19:07:46	0|btcdrak|gotta build, cfields needs to sign etc.
280 2016-04-14 19:07:50	0|gmaxwell|in the future we should figure out how to deseralize builds of the final release and publication of the tag.
281 2016-04-14 19:08:13	0|wumpus|huh
282 2016-04-14 19:08:16	0|jonasschnelli|we could agree on a commit and build that and tag later.
283 2016-04-14 19:08:40	0|gmaxwell|the fact that we've been doing "releases" that get announced and circulated ahead of the project's announcement and then having binary days delayed is suboptimal.
284 2016-04-14 19:08:40	0|sipa|we need to have gitian build inside a homomorphically encrypted environment, so that we can verify binary correctness, but only release the key at release time
285 2016-04-14 19:08:43	0|cfields|fwiw, dropping the commit hash in the binary would create a few more options
286 2016-04-14 19:08:43	0|wumpus|is this still serious?
287 2016-04-14 19:08:55	0|sipa|wumpus: no
288 2016-04-14 19:09:00	0|wumpus|ok...
289 2016-04-14 19:09:02	0|wumpus|next topic?
290 2016-04-14 19:09:13	0|jonasschnelli|[21:05:02]  <sipa>
291 2016-04-14 19:09:16	0|btcdrak|segwit backports
292 2016-04-14 19:09:28	0|wumpus|#topic segwit and backports
293 2016-04-14 19:09:42	0|sipa|so, segwit branch is currently on top of 0.12.1
294 2016-04-14 19:10:03	0|btcdrak|so you'd be forward porting it to master
295 2016-04-14 19:10:13	0|sipa|with a set of backports from master and some PRs first
296 2016-04-14 19:10:36	0|Luke-Jr|it would be ideal if the same branch can merge into both 0.12 and master, but that seems unlikely for segwit
297 2016-04-14 19:10:40	0|gmaxwell|FWIW on the other implementations front, btcd has what looks like a more or less complete implementation of the consensus changes for segwit and is interoperating with segnet4.
298 2016-04-14 19:10:40	0|sipa|i don't know what the best way forward is, but i think we're close to PRing it for bitcoin
299 2016-04-14 19:10:53	0|Luke-Jr|gmaxwell: nice!
300 2016-04-14 19:11:13	0|cfields|sipa: woohoo!
301 2016-04-14 19:11:28	0|wumpus|gmaxwell:  "and then having binary days delayed is suboptimal." why don't you ever gitian-build? :p
302 2016-04-14 19:11:35	0|sipa|do we rebase on master, have that merged first, and then "magically" come up with a 0.12 backport? :D
303 2016-04-14 19:11:48	0|sipa|which happens to include the necessary backports
304 2016-04-14 19:11:49	0|btcdrak|sipa: I hear you are good at magic
305 2016-04-14 19:12:01	0|Luke-Jr|sipa: what's the current segwit branch?
306 2016-04-14 19:12:05	0|Luke-Jr|without segnet ideally
307 2016-04-14 19:12:34	0|sipa|Luke-Jr: segwit4 and segwit (the first is where i continuously rebase, the second i push to whenever there is something significant)
308 2016-04-14 19:12:36	0|wumpus|the reason for the delay is that a certian minimum threshold of number of people have to build it, submit signatures, etc., the only way to speed it up wouldb e if people build it quicker, although it's already lots faster than it used to be
309 2016-04-14 19:12:53	0|sipa|Luke-Jr: they have segnet, though the commits for segnet are separate and can easily be skipped
310 2016-04-14 19:13:17	0|gmaxwell|wumpus: if you'd like me to do so, I will. (re gitian builds)
311 2016-04-14 19:13:28	0|sipa|that's anohter question: do we merge segnet?
312 2016-04-14 19:13:35	0|btcdrak|gmaxwell: yes please.
313 2016-04-14 19:13:42	0|wumpus|gmaxwell: I dont mind, but please don't complain if you're not involved okay :)
314 2016-04-14 19:13:55	0|btcdrak|sipa: do we really need segnet?
315 2016-04-14 19:14:00	0|sipa|btcdrak: i don't think so
316 2016-04-14 19:14:07	0|morcos|This might sound crazy, but I'd be in favor of merging the segwit PR very quickly.  I think we should make the PR's for master and 0.12 at roughly the same time.  And then we should all bust our ass to review them at roughly the same time.
317 2016-04-14 19:14:22	0|sipa|that sounds fine to me
318 2016-04-14 19:14:28	0|morcos|If they are outstanding for a while, then we'll all be reviewing different code as its rebased or merge conflicts are addressed or whatever
319 2016-04-14 19:14:33	0|btcdrak|morcos: no complaints
320 2016-04-14 19:14:36	0|morcos|We should just rip the bandaid off and get it in
321 2016-04-14 19:14:39	0|gmaxwell|wumpus: my complaint wasn't about any of the people, for sure. if it were, I'd just build. Also, it wasn't really a complaint with anything we're doing. It's a complaint that the community prereleases our releases, but we can't stop that; so the best fix is to reduce latency, I think.
322 2016-04-14 19:14:59	0|morcos|And then every other PR out there can get conflicted once and be done with it
323 2016-04-14 19:15:02	0|btcdrak|in all fairness there has been so much testing and peer review and help from downstream consumers with segwit.
324 2016-04-14 19:15:16	0|sipa|ok, will PR soon
325 2016-04-14 19:15:29	0|jonasschnelli|A quick merge sound good. Also, nobody can complain we haven gave any change for review because there is already an open pr since weeks/month.
326 2016-04-14 19:15:31	0|sipa|both master and 0.12
327 2016-04-14 19:15:39	0|btcdrak|super. jonasschnelli you should close your preview PR so it doesnt get confusing
328 2016-04-14 19:15:43	0|gmaxwell|I've felt bad about working on 0.13 in areas that I know will need to be tweaked for segwit, so I can agree with that. As soon as 0.12 is tagged this could be done. If we end up needing a 0.12.2 without segwit we could branch 0.12 pre-segwit.
329 2016-04-14 19:16:07	0|jonasschnelli|Yes. Will close. Its pointing also to the wrong branch.
330 2016-04-14 19:16:24	0|btcdrak|gmaxwell: maybe we dont need to over complicate if the PR/backport will come soon.
331 2016-04-14 19:18:19	0|morcos|My main point is that it is goign to be a lot of work to adequeately review and test segwit.  It'll be more efficient use of everyones time if we concentrate that effort at the same time.
332 2016-04-14 19:18:29	0|sipa|that makes sense
333 2016-04-14 19:20:19	0|sipa|any other topics?
334 2016-04-14 19:20:33	0|wumpus|what about c++11 status?
335 2016-04-14 19:20:39	0|sipa|ack
336 2016-04-14 19:20:47	0|wumpus|#topic c++11 status
337 2016-04-14 19:21:16	0|cfields|wumpus: travis has enabled caching but only for flagged projects. I mailed this morning and asked for the flag.
338 2016-04-14 19:21:34	0|sipa|cfields: is that the final blocker?
339 2016-04-14 19:21:43	0|cfields|sipa: as far as i know, yes
340 2016-04-14 19:21:47	0|sipa|awesome
341 2016-04-14 19:21:52	0|wumpus|that was already the case right? open source projects needed a flag to support caching. But we need a new one now?
342 2016-04-14 19:22:06	0|wumpus|hopefully theyll give it :)
343 2016-04-14 19:22:07	0|cfields|wumpus: no, for trusty
344 2016-04-14 19:22:08	0|cfields|sec..
345 2016-04-14 19:22:46	0|cfields|https://github.com/travis-ci/travis-scheduler/pull/14
346 2016-04-14 19:23:07	0|cfields|merged last week
347 2016-04-14 19:23:32	0|wumpus|great!
348 2016-04-14 19:23:47	0|sipa|how do we plan to proceed after that?
349 2016-04-14 19:23:49	0|wumpus|hopefully we can start supporting it this week then
350 2016-04-14 19:23:56	0|gmaxwell|would we be using C++11 in 0.13 then?
351 2016-04-14 19:24:05	0|cfields|if there's a delay with this step, I'm completely ok with saying "screw it" and disabling whatever we need so that we can limp along until it's not blocking anymore
352 2016-04-14 19:24:32	0|wumpus|gmaxwell: that was the plan
353 2016-04-14 19:24:33	0|Luke-Jr|Travis is not willing to flag just any projects. We should try to avoid relying on it.
354 2016-04-14 19:24:40	0|gmaxwell|wumpus: good. :)
355 2016-04-14 19:24:43	0|cfields|so, I've been hacking on c++11 on a branch of mine for a while. One thing that's clear is that we need a policy on what modernizations we'll allow...
356 2016-04-14 19:25:00	0|cfields|otherwise, I'm afraid it'll be endless PRs
357 2016-04-14 19:25:10	0|cfields|Luke-Jr: it's just a flag while it's in testing
358 2016-04-14 19:25:10	0|sipa|cfields: there are a couple of mechanic translations i think we'll want ayt some point
359 2016-04-14 19:25:21	0|wumpus|I created this in december, a bit optimistic maybe, but five months later :) https://github.com/bitcoin/bitcoin/pull/7165
360 2016-04-14 19:25:39	0|gmaxwell|We should keep modernization PRs slow initially. Then do the mechanical updates (e.g. replace boost with C++11).. and only after go back and make more changes.
361 2016-04-14 19:25:49	0|gmaxwell|at least thats my intuition.
362 2016-04-14 19:25:50	0|sipa|cfields: BOOST_FOREACH and boost::thread are good examples
363 2016-04-14 19:25:55	0|wumpus|replacing boost is far from mechanical
364 2016-04-14 19:26:00	0|wumpus|well ok some parts
365 2016-04-14 19:26:10	0|cfields|sipa: yes, for sure. what I worry about it thousands of PRs that sprinkle in std::move all over the place.
366 2016-04-14 19:26:16	0|morcos|is there any downside to using c++11 in new code while not yet doing any modernization PR's?
367 2016-04-14 19:26:16	0|sipa|but for example: adding move constructors instead of swaps everywhere
368 2016-04-14 19:26:17	0|gmaxwell|in particular I think it's probably unwise to do many moderinization updates when non C++11 versions are still supported.
369 2016-04-14 19:26:20	0|Luke-Jr|someone remind me why are we not doing a release that fails with C++11 at configure, before actually introducing C++11 code?
370 2016-04-14 19:26:23	0|cfields|(and emplace, which would be significant in several places)
371 2016-04-14 19:26:25	0|BlueMatt|Start with only new code is C++11, then only boost-replacement, then revisit
372 2016-04-14 19:26:26	0|BlueMatt|?
373 2016-04-14 19:26:28	0|gmaxwell|because that would vastly complicate backports.
374 2016-04-14 19:26:41	0|sipa|one option is building with c++11 and c++03 both for a while
375 2016-04-14 19:26:44	0|morcos|I would say we have a lot on our plate in the next couple months, and we should just say no modernaization right now.  (sounds like what BlueMatt said)
376 2016-04-14 19:26:46	0|wumpus|meh
377 2016-04-14 19:26:47	0|cfields|morcos: i think that would be my preference
378 2016-04-14 19:26:56	0|wumpus|we can already build with c++11 for quite a while, that's nothing new
379 2016-04-14 19:27:12	0|sipa|ok
380 2016-04-14 19:27:25	0|sipa|just not too actively replace things initially
381 2016-04-14 19:27:42	0|BlueMatt|I mean for 0.13 Id say dont actively replace anything unless its a big performance win
382 2016-04-14 19:27:43	0|Luke-Jr|at the very least, let's add something to configure that fails if C++11 is not supported?
383 2016-04-14 19:27:49	0|wumpus|we've never let refactors through too quickly
384 2016-04-14 19:27:54	0|wumpus|correctness is most imporant
385 2016-04-14 19:28:02	0|gmaxwell|Matt has an upcoming PR that uses C++11 that it might be nice to not have to port to C++03.
386 2016-04-14 19:28:02	0|Luke-Jr|that way we get user reports
387 2016-04-14 19:28:07	0|wumpus|Luke-Jr: yes, see the pull I quoted
388 2016-04-14 19:28:20	0|wumpus|Luke-Jr: it fails without c++11 support
389 2016-04-14 19:28:21	0|BlueMatt|gmaxwell: for the tcp stuff I think it actually doesnt matter, I was just lazy...udp would be annoying to fix, I think
390 2016-04-14 19:28:28	0|cfields|wumpus: let's use a real example.. adding move ctors to our containers
391 2016-04-14 19:28:31	0|cfields|yea or nay?
392 2016-04-14 19:28:39	0|sipa|cfields: yay, please... but maybe not immediately
393 2016-04-14 19:28:49	0|BlueMatt|cfields: for 0.13, I'd vote only new code, maybe boost replacement, too
394 2016-04-14 19:28:57	0|wumpus|cfields: if it helps performance, absolute yay
395 2016-04-14 19:28:59	0|sipa|(prevector specifically is unsafe to use for more complex types now)
396 2016-04-14 19:29:06	0|BlueMatt|but I'm always the annoyingly conservative one, sooooo
397 2016-04-14 19:29:11	0|wumpus|boost replacement is too late for 0.13
398 2016-04-14 19:29:15	0|sipa|wumpus: agree
399 2016-04-14 19:29:15	0|wumpus|too much work
400 2016-04-14 19:29:29	0|BlueMatt|wumpus: ehh, I meant partial-boost-replacement
401 2016-04-14 19:29:32	0|wumpus|we can do some minor things and use it in new code, but aiming to replace boost enitrely just won't work
402 2016-04-14 19:29:38	0|gmaxwell|New code +1, especially new features, but as I mentioned, I think we should avoid making backports to 0.12 harder while 0.12 is still supported.
403 2016-04-14 19:29:44	0|sipa|just turning on c++11 may already give a performance improvement, because STL magically gets move constructors
404 2016-04-14 19:30:01	0|jonasschnelli|At least we could throw out boost::filesystem soon (there is no c++11 equivalent).
405 2016-04-14 19:30:05	0|wumpus|to me it seems we want to backport so much to 0.12 it is starting to make more sense to do 0.13 sooner
406 2016-04-14 19:30:09	0|wumpus|do a release from master
407 2016-04-14 19:30:21	0|wumpus|may work better with cfields' holiday too
408 2016-04-14 19:30:32	0|morcos|wumpus: but then not release segwit for 0.12?
409 2016-04-14 19:30:40	0|cfields|stupid inconvenient honeymoon...
410 2016-04-14 19:30:48	0|morcos|thats the issue right..  are we only going to support it on 0.13?
411 2016-04-14 19:30:50	0|sipa|cfields: priorities!
412 2016-04-14 19:30:53	0|jonasschnelli|heh!
413 2016-04-14 19:30:56	0|gmaxwell|morcos: I don't think we should do that.
414 2016-04-14 19:30:58	0|sipa|i think we should backport segwit to 0.12
415 2016-04-14 19:31:02	0|wumpus|(we have to change the release schedule a bit anyway)
416 2016-04-14 19:31:07	0|sipa|let's not push users too much
417 2016-04-14 19:31:24	0|btcdrak|if we release 0.13 we still have to backport to 0.12
418 2016-04-14 19:31:34	0|btcdrak|since we support this and prev version
419 2016-04-14 19:31:35	0|gmaxwell|wumpus: what kind of schedule change are you thinking of?
420 2016-04-14 19:32:42	0|gmaxwell|Can we talk about what notable features are still in flight that people are working on with an intent of targeting 0.13?
421 2016-04-14 19:32:44	0|btcdrak|maybe backport to 0.12 and release 0.13 early.
422 2016-04-14 19:33:14	0|morcos|whats the hurry to release 0.13 early in that case?
423 2016-04-14 19:33:14	0|wumpus|yes was a bad idea
424 2016-04-14 19:33:19	0|btcdrak|This is the list of 0.13 milestones https://github.com/bitcoin/bitcoin/milestones/0.13.0
425 2016-04-14 19:33:19	0|wumpus|ntext topic
426 2016-04-14 19:33:21	0|phantomcircuit|jonasschnelli: was that benchmark of leveldb vs lmdb on a system with a hdd or ssd?
427 2016-04-14 19:33:32	0|jonasschnelli|ssd
428 2016-04-14 19:33:40	0|phantomcircuit|interesting
429 2016-04-14 19:33:52	0|jonasschnelli|(can be discussed after the meeting)
430 2016-04-14 19:34:15	0|gmaxwell|btcdrak: there are things people are working on that aren't PRs yet.
431 2016-04-14 19:34:18	0|Luke-Jr|gmaxwell: I'd like to rework the config/arg stuff, but I don't know I'll have time to finish it before 0.13 forks
432 2016-04-14 19:34:42	0|BlueMatt|wumpus: next topic? we didnt really come to a conclusion at all here yet? what is the release schedule for 0.13 looking like, and does that mesh with turning on C++11 and allowing new code to use it?
433 2016-04-14 19:35:00	0|Luke-Jr|(and there's no reason it can't wait for 0.14 etc)
434 2016-04-14 19:35:07	0|wumpus|well the change we have to make in the 0.13 release schedule is to clear june - this works btter for cfields
435 2016-04-14 19:35:29	0|wumpus|but we can just as well postpone it to later, moving it ealier was just a stupid idea
436 2016-04-14 19:35:36	0|cfields|no reason to change just for me?
437 2016-04-14 19:35:47	0|btcdrak|oh just a note regarding ctaes, independent review is in progress from one of Matthew Green's graduates, hopefully available in a couple of weeks.
438 2016-04-14 19:35:51	0|wumpus|well the rc cycle was exactly planned that
439 2016-04-14 19:35:56	0|wumpus|then*
440 2016-04-14 19:36:03	0|gmaxwell|wumpus: I dunno that its stupid. But it should be made with consideration.
441 2016-04-14 19:36:07	0|wumpus|can do that in july instead of june , no problem
442 2016-04-14 19:36:14	0|morcos|gmaxwell: yes, i'm working on 2 things that might be nice to get in.  an improvement to fee estimation and some measurement of policy alignment.  they are goign to be annoying for anyone to review, but they also stand alone.
443 2016-04-14 19:36:36	0|wumpus|BlueMatt: release schedule 0.13: https://github.com/bitcoin/bitcoin/issues/7679
444 2016-04-14 19:36:37	0|gmaxwell|BlueMatt: C++11 is getting turned on, in a week barring emergencies if I understood above. And it sounded like new things could use it, but we'd avoid going and refactoring for more until 0.14.
445 2016-04-14 19:36:39	0|morcos|wumpus: yes i like the idea of pushing back 0.13 a bit
446 2016-04-14 19:36:48	0|sipa|gmaxwell: ack
447 2016-04-14 19:36:49	0|BlueMatt|gmaxwell: ACK
448 2016-04-14 19:37:13	0|jonasschnelli|Features I'd like to see in 0.13: wallet/RBF (+GUI), simple profiles (maybe GUI only), BIP32 (probably not in 0.13 because of lack of review)
449 2016-04-14 19:37:15	0|sdaftuar|regarding 0.13, i thought it might make sense to push the freature freeze back slightly, since there's a meetup happening in zurich a week afterward that many of us would be at
450 2016-04-14 19:37:17	0|BlueMatt|wumpus: ok, so release schedule stays as-is for now?
451 2016-04-14 19:37:29	0|wumpus|BlueMatt: I proposed moving the rc phase to july instead of june
452 2016-04-14 19:37:33	0|jonasschnelli|sdaftuar: good point.
453 2016-04-14 19:37:33	0|Luke-Jr|in talking about using C++11, we won't need GCC 5, right?
454 2016-04-14 19:37:44	0|BlueMatt|when does cfields gete back?
455 2016-04-14 19:37:44	0|Luke-Jr|because GCC 5 is not really a reasonable minimum yet
456 2016-04-14 19:37:53	0|morcos|wumpus: ack
457 2016-04-14 19:37:59	0|cfields|Luke-Jr: 4.8 should be fine, i think
458 2016-04-14 19:38:02	0|Luke-Jr|k
459 2016-04-14 19:38:02	0|wumpus|no, we don't need gcc5, the features we should use of c++11 shoudl work in gcc4.8+
460 2016-04-14 19:38:05	0|sipa|Luke-Jr: i believe (but cfields correct me) that the features from c++11 we'd want are almost entirely support in 4.8
461 2016-04-14 19:38:11	0|wumpus|otherwise we can't use trusty for building
462 2016-04-14 19:38:18	0|cfields|BlueMatt: july4ish
463 2016-04-14 19:38:20	0|wumpus|and that's the whole point
464 2016-04-14 19:38:34	0|sipa|that's clear, thank you
465 2016-04-14 19:39:04	0|cfields|BlueMatt: if it turns out to be too problematic, i can revisit the dates.
466 2016-04-14 19:39:20	0|gmaxwell|Luke-Jr: C++11 is fully supported in 4.9, and 4.8 has basically everything. I think we could reference 4.8 for compatibility.
467 2016-04-14 19:39:22	0|BlueMatt|cfields: lol, dont change honeymoon for us
468 2016-04-14 19:39:23	0|wumpus|cfields: no
469 2016-04-14 19:39:27	0|gmaxwell|Luke-Jr: https://gcc.gnu.org/gcc-4.8/cxx0x_status.html
470 2016-04-14 19:39:28	0|morcos|cfields: you better hope your fiance doesnt read these logs
471 2016-04-14 19:39:37	0|jonasschnelli|haha
472 2016-04-14 19:40:12	0|cfields|heh
473 2016-04-14 19:40:36	0|BlueMatt|wumpus: ACK pushing 0.13 a month...gives a week or two for post-zurich things to make the feature freeze
474 2016-04-14 19:40:38	0|wumpus|sdaftuar: if we move the rc phase a month we can move the feature freeze with the same amount
475 2016-04-14 19:40:48	0|BlueMatt|wumpus: eg things that get reviewed in zurich can be cleaned up and merged before freeze
476 2016-04-14 19:40:51	0|wumpus|BlueMatt: right
477 2016-04-14 19:40:52	0|sdaftuar|wumpus: sounds good to me
478 2016-04-14 19:41:01	0|BlueMatt|ACKs on pushing a month?
479 2016-04-14 19:41:06	0|btcdrak|ACK
480 2016-04-14 19:41:10	0|wumpus|ack
481 2016-04-14 19:41:12	0|jonasschnelli|ack
482 2016-04-14 19:41:13	0|gmaxwell|ok
483 2016-04-14 19:41:14	0|Luke-Jr|I don't see any resolution to C++11's ABI issues in the github tracker - did that get resolved?
484 2016-04-14 19:41:14	0|morcos|ACK
485 2016-04-14 19:42:05	0|wumpus|#action move 0.13 schedule a month forward
486 2016-04-14 19:42:39	0|cfields|Luke-Jr: what issues?
487 2016-04-14 19:42:41	0|sipa|Luke-Jr: https://github.com/bitcoin/bitcoin/pull/7165#issuecomment-165499462
488 2016-04-14 19:42:52	0|sipa|all known ABI issues result in link errors
489 2016-04-14 19:43:05	0|cfields|for that matter, gcc6 will build with c++14 by default. So either way (maybe even for 0.12 backport), we need to specify the standard we're using.
490 2016-04-14 19:43:31	0|wumpus|hah, c++14
491 2016-04-14 19:43:34	0|gmaxwell|As far as other in-flight stuff, Matt has implemented efficient block relay; related to a design I've been circulating for a long while.  He has code up, and it works pretty well.. I get about a 96% reduction in block bandwidth. The protocol needs a few tweaks still but once in, it should be able to send the vast majority of blocks in 0.5 round-trip times (plus whatever awful overhead TCP adds),
492 2016-04-14 19:43:38	0|wumpus|not looking forward to going through this again :(
493 2016-04-14 19:43:40	0|gmaxwell|the rest will need 1.5 RTT. I've started on a BIP. Matt has also been working on some other things that go further and eliminate even more latency, though that work is likely only going to be interesting to miners.
494 2016-04-14 19:44:21	0|BlueMatt|I think gmaxwell is more excited about tcp-smaller-block relay since his internet at home sucks
495 2016-04-14 19:44:26	0|gmaxwell|I think with segwit upcoming I'd really like to see that work make its way into 0.13, since we really need propagation time mitigations, and the relay network client only goes so far.
496 2016-04-14 19:44:27	0|cfields|nice
497 2016-04-14 19:44:33	0|cfields|BlueMatt: you have a branch somewhere?
498 2016-04-14 19:44:39	0|BlueMatt|I see it more as foundational work that is useful for compression on the wire, but is primarily for udp-based relay which is nice and fast :)
499 2016-04-14 19:45:02	0|BlueMatt|cfields: simple tcp stuff at https://github.com/TheBlueMatt/bitcoin/commits/udp, udp-based stuff which hasnt been fully rebased on top at https://github.com/TheBlueMatt/bitcoin/commits/udp-wip
500 2016-04-14 19:45:21	0|wumpus|cfields: how does it make sense that they will build with c++14 by default?!
501 2016-04-14 19:45:44	0|BlueMatt|tcp stuff is close to ready with one or two stubs to be replaced, pr next week when I'm off vacation, udp stuff is a bit longer-term
502 2016-04-14 19:45:48	0|cfields|wumpus: i suppose because it should all be forward compat, in theory
503 2016-04-14 19:45:49	0|sipa|wumpus: i think c++14 has less impact on standard libraries
504 2016-04-14 19:45:50	0|cfields|BlueMatt: thanks
505 2016-04-14 19:46:09	0|BlueMatt|cfields: if you want to tackle the udp-wip changing to libevent I'd owe you :)
506 2016-04-14 19:46:09	0|sipa|and is much more incremental than c++11 was
507 2016-04-14 19:46:12	0|cfields|yes, c++14 as i see it is kinda a c++11 fixup
508 2016-04-14 19:46:23	0|wumpus|ok...
509 2016-04-14 19:46:30	0|Luke-Jr|cfields: IIRC, binaries (incl libraries) compiled with C++11 mode are incomptible with libraries compiled with C++98 mode.
510 2016-04-14 19:46:36	0|sipa|c++14 finally has a solution for the exponentially-sized error messages
511 2016-04-14 19:46:37	0|Luke-Jr|sipa: ok
512 2016-04-14 19:46:56	0|cfields|Luke-Jr: that has nothing to do with how we compile though. That'll be the case either way.
513 2016-04-14 19:47:00	0|gmaxwell|BlueMatt: mostly trying to avoid bleeding out over load increases permitted by segwit. :)
514 2016-04-14 19:47:06	0|wumpus|sipa: nice!
515 2016-04-14 19:47:13	0|cfields|BlueMatt: heh yes, we should sync up some
516 2016-04-14 19:47:34	0|Luke-Jr|cfields: ? our dependencies are compiled with C++98 in almost all cases today
517 2016-04-14 19:47:36	0|wumpus|anyhow any other meeting topics?
518 2016-04-14 19:47:49	0|kanzure|MAST bip status?
519 2016-04-14 19:48:05	0|gmaxwell|lol. way too premature for discussion here.
520 2016-04-14 19:48:13	0|btcdrak|kanzure: it got published BIP114
521 2016-04-14 19:48:18	0|cfields|Luke-Jr: yes, and they'll be switched to c++11 for the ones we build. Otherwise it's a cointoss what users have on their systems, sticking with c++03 could be equally incompatible for them.
522 2016-04-14 19:48:19	0|wumpus|Luke-Jr: cfields let's leave the small implementation details about the c++11 switch to after the meeting
523 2016-04-14 19:48:26	0|cfields|ack
524 2016-04-14 19:48:36	0|Luke-Jr|cfields: we do not build our dependencies typically.
525 2016-04-14 19:48:49	0|Luke-Jr|wumpus: k
526 2016-04-14 19:49:03	0|wumpus|I'm sure we'll get it to work somehow
527 2016-04-14 19:49:31	0|wumpus|#topic MAST bip status
528 2016-04-14 19:49:44	0|kanzure|no no, it was sufficiently NACKed
529 2016-04-14 19:49:59	0|sipa|i haven't looked at it yet
530 2016-04-14 19:50:17	0|instagibbs|https://github.com/bitcoin/bips/blob/master/bip-0114.mediawiki < fwiw
531 2016-04-14 19:50:30	0|wumpus|#link https://github.com/bitcoin/bips/blob/master/bip-0114.mediawiki
532 2016-04-14 19:51:43	0|Luke-Jr|possible topic?: using SHA256d for segwit
533 2016-04-14 19:52:29	0|wumpus|sha256d?
534 2016-04-14 19:52:33	0|sipa|Luke-Jr: i'd rather not break all tests and downstream code that was written yet... though we'll want new segwit script versions soon, and they can use sha256d hashing
535 2016-04-14 19:53:04	0|sipa|wumpus: background: p2wsh scriptPubKeys contain a SHA256 (not double SHA256) of the witness program
536 2016-04-14 19:53:09	0|paveljanik|double sha256
537 2016-04-14 19:53:26	0|sipa|which is incompatible with the "P2SH^2" scheme that greg proposed a while ago
538 2016-04-14 19:53:34	0|wumpus|oh right
539 2016-04-14 19:53:43	0|wumpus|it would be consistent
540 2016-04-14 19:53:47	0|gmaxwell|The only advantage of it that I'm aware of is the p2sh^2 trick which would need new address types and such to ever get used. Disadvantage is that its slow.
541 2016-04-14 19:54:12	0|gmaxwell|And consistency, I suppose.
542 2016-04-14 19:54:15	0|sipa|... which interacts with the discussion of addresses for native segwit
543 2016-04-14 19:54:17	0|Luke-Jr|gmaxwell: there's no address types for bare segwit yet
544 2016-04-14 19:54:36	0|sipa|Luke-Jr: i do plan on proposing one
545 2016-04-14 19:54:41	0|sipa|(though not immediately)
546 2016-04-14 19:54:59	0|Luke-Jr|yes, my point is that we have an opportunity to avoid breaking compatibility
547 2016-04-14 19:55:10	0|gmaxwell|we'd purposefully moved them out to avoid shedpainting and address-type-deployment issues from harming segwit consensus code deployment.
548 2016-04-14 19:55:44	0|phantomcircuit|gmaxwell: sha256d also prevents length extention attacks although i dont see how that's applicable here at all
549 2016-04-14 19:55:49	0|gmaxwell|Luke-Jr: I think that nativesegwit of that initial type is not likely to see long term use, see also that MAST bip.
550 2016-04-14 19:55:56	0|Luke-Jr|sipa: am I incorrect in assuming adjusting downstream code for this would be super trivial?
551 2016-04-14 19:56:26	0|sipa|Luke-Jr: probably, but we also don't have a way to deploy P2SH^2 easily
552 2016-04-14 19:56:32	0|Luke-Jr|gmaxwell: yes, but I think sipa wants an address format that works for all segwit outputs, regardless of version
553 2016-04-14 19:57:00	0|Luke-Jr|sipa: that's not something we need to bundle with making it possible
554 2016-04-14 19:57:36	0|gmaxwell|we should close the meeting and continue the discussion.
555 2016-04-14 19:57:40	0|sipa|ok
556 2016-04-14 19:57:46	0|gmaxwell|no resolution to this will happen this instant.
557 2016-04-14 19:58:51	0|sipa|#shutdown -h now meeting
558 2016-04-14 19:59:04	0|jonasschnelli|sudo!
559 2016-04-14 19:59:08	0|wumpus|#endmeeting
560 2016-04-14 19:59:09	0|lightningbot|Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-04-14-19.00.log.html
561 2016-04-14 19:59:09	0|lightningbot|Meeting ended Thu Apr 14 19:59:08 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
562 2016-04-14 19:59:09	0|lightningbot|Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-04-14-19.00.html
563 2016-04-14 19:59:09	0|lightningbot|Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-04-14-19.00.txt
564 2016-04-14 19:59:28	0|paveljanik|jonasschnelli, no need for sudo once you have # ;-)
565 2016-04-14 19:59:50	0|jonasschnelli|nerds! oO
566 2016-04-14 19:59:55	0|gmaxwell|So, wrt p2sh^2. That got proposed eons ago and I think it's unlikely to ever get implemented.
567 2016-04-14 19:59:55	0|jtimon|meeting?
568 2016-04-14 20:00:00	0|gmaxwell|jtimon: an hour ago.
569 2016-04-14 20:00:00	0|jonasschnelli|jtimon: hahaha
570 2016-04-14 20:00:17	0|jtimon|oh...
571 2016-04-14 20:00:26	0|phantomcircuit|timezones strike again
572 2016-04-14 20:00:31	0|jtimon|well, read the logs I guess
573 2016-04-14 20:00:32	0|btcdrak|jtimons needs to run an ntp daemon
574 2016-04-14 20:00:33	0|kanzure|this is why we should abolish time zones
575 2016-04-14 20:00:37	0|Luke-Jr|gmaxwell: isn't the only major hold-up the backward compat issue?
576 2016-04-14 20:00:46	0|Luke-Jr|kanzure: tonal time! :D
577 2016-04-14 20:00:55	0|kanzure|i would be willing to accept tonal time if it means no more time zones
578 2016-04-14 20:00:55	0|paveljanik|meeting bot should be modified to ping people beforehand :-)
579 2016-04-14 20:00:57	0|jonasschnelli|jtimon: I can add a cron job that sends you a PM 10mins before the meeting? But people where using alarm-clock back in the "old days". :)
580 2016-04-14 20:01:02	0|gmaxwell|Luke-Jr: no, well it requires yet another kind of witness data in transactions.
581 2016-04-14 20:01:03	0|sipa|Luke-Jr: plus that it's easily bypassable, and we could end up encouraging people to send to miners directly
582 2016-04-14 20:01:23	0|jtimon|phantomcircuit: I would share last week it was a 22:00, but it may may that I forgot about my last mistake
583 2016-04-14 20:01:25	0|Luke-Jr|gmaxwell: that's pretty simple now with segwit
584 2016-04-14 20:01:34	0|gmaxwell|the pairing crypto based scheme I came up with didn't have those issues but it's slow.
585 2016-04-14 20:01:38	0|jtimon|jonasschnelli: that would be indeed useful
586 2016-04-14 20:01:41	0|Luke-Jr|sipa: that assumes miners are willing to cooperate in the spam
587 2016-04-14 20:01:43	0|Luke-Jr|actively
588 2016-04-14 20:01:59	0|sipa|Luke-Jr: why wouldn't they, if people want to pay
589 2016-04-14 20:02:03	0|Luke-Jr|at the very least, such miners would likely opt to charge higher fees (I hope)
590 2016-04-14 20:02:42	0|jtimon|never mind much, I will eventually adapt to this without putting it in google calendar, you'll see
591 2016-04-14 20:02:56	0|sipa|p2sh^2 is also incompatible with forward compatible address types
592 2016-04-14 20:03:14	0|gmaxwell|sipa: I dunno, thats kind of an argument against any non-stanardness. Dust limits have been effective.
593 2016-04-14 20:03:23	0|sipa|gmaxwell: fair enough
594 2016-04-14 20:03:28	0|Luke-Jr|not necessarily? if all future address types are p2sh^2
595 2016-04-14 20:03:29	0|gmaxwell|But yes, it would be incompatible with address types that change the top hashing scheme.
596 2016-04-14 20:03:36	0|wumpus|jtimon: date -u , if it shows thursday 19:00-20:00 it's time for the meeting :)
597 2016-04-14 20:04:04	0|sipa|Luke-Jr: i guess if we stick to 1) there is some scheme below that results in 32-byte data 2) on top of that there is single SHA256
598 2016-04-14 20:04:10	0|Luke-Jr|we tried a one-size-fits-all address type for p2sh, and that failed with segwit. I'm not sure it's possible to make future-proof here really.
599 2016-04-14 20:04:10	0|sipa|then it can be compatible
600 2016-04-14 20:04:30	0|gmaxwell|No but we can be a bit more future robust than p2sh was.
601 2016-04-14 20:04:49	0|gmaxwell|There is a greater archectural question around the pace of script changes.
602 2016-04-14 20:05:24	0|gmaxwell|If there are a lot of little script changes that do nothing other than add OP_SWEETANDSOURCHECKSIG then its essential there be an address type that automagically covers them.
603 2016-04-14 20:05:54	0|CodeShark|how is simply encoding the scriptPubKey not fully general?
604 2016-04-14 20:06:04	0|sipa|CodeShark: it doesn't cover P2SH^2
605 2016-04-14 20:06:11	0|Luke-Jr|gmaxwell: hopefully all scripts will be inside the witness
606 2016-04-14 20:06:15	0|sipa|CodeShark: but apary from that, yes
607 2016-04-14 20:06:24	0|sipa|Luke-Jr: the witness version number needs to be outside
608 2016-04-14 20:06:27	0|CodeShark|what's P2SH^2?
609 2016-04-14 20:06:34	0|Luke-Jr|kanzure: http://176.9.18.83:5984/buddy-clock/_design/site/_list/show/by_tz btw
610 2016-04-14 20:06:54	0|Luke-Jr|sipa: yes, but that doesn't interfere with p2sh^2
611 2016-04-14 20:07:10	0|sipa|CodeShark: you have an address that encodes SHA256(script), and the output contains SHA256(SHA256(script))... but for relay you're required to also provide SHA256(script) (which does not go into blocks, however)
612 2016-04-14 20:07:12	0|instagibbs|can we get the post on p2sh^2? I read it like 3 years ago, forgot the details
613 2016-04-14 20:07:26	0|instagibbs|oh ok
614 2016-04-14 20:07:37	0|sipa|CodeShark: this guarantees that the data in the output is a hash, and not data storage
615 2016-04-14 20:08:08	0|gmaxwell|CodeShark: and also makes it somewhat harder to just send funds to random "addresses" culled from the blockchain (you need the preimage side information).
616 2016-04-14 20:08:24	0|gmaxwell|A practice which is a major accounting nusance for many parties.
617 2016-04-14 20:08:47	0|sipa|b.i will of course publish all the preimages they see in the network
618 2016-04-14 20:08:49	0|CodeShark|so no more shakespeare in the blockchain? :( https://www.smartbit.com.au/tx/8f64d2b7a762767e3870c4aee95f8c7b5439cf02cf7d7e5d99b6e39967ecada8
619 2016-04-14 20:08:51	0|sipa|*ducks*
620 2016-04-14 20:09:17	0|gmaxwell|CodeShark: not in the UTXO set, of course that stuff could still end up in witnesses.
621 2016-04-14 20:09:26	0|instagibbs|sipa, sigh, you are of course correct
622 2016-04-14 20:09:39	0|instagibbs|or just captured by sybil anti-laundering services
623 2016-04-14 20:09:50	0|gmaxwell|sipa: I wouldn't be so sure.
624 2016-04-14 20:10:27	0|sipa|there is also a minor downside to using sha256^2 for script hashes, namely that it means wallet needs to maintain two indexes for scripts (one for p2sh, one for p2wsh, because their hashes are not compatible)
625 2016-04-14 20:10:51	0|sipa|very minor, and possibly something that can't be maintained for future witness script version anyway
626 2016-04-14 20:10:53	0|Luke-Jr|nah, addresses are either p2sh or p2wsh, not both.
627 2016-04-14 20:11:05	0|sipa|Luke-Jr: scripts, not addresses
628 2016-04-14 20:11:26	0|sipa|but i agree it's minor
629 2016-04-14 20:11:30	0|wumpus|* [new tag]         v0.12.1 -> v0.12.1
630 2016-04-14 20:11:42	0|Luke-Jr|I don't follow. If it's used in a p2sh address, you don't need to index the script for p2wsh..?
631 2016-04-14 20:12:06	0|sipa|Luke-Jr: you have an index from Hash160 -> script for known scripts
632 2016-04-14 20:12:17	0|sipa|Luke-Jr: that can be used for matching both P2SH and P2WSH
633 2016-04-14 20:12:36	0|Luke-Jr|but you don't need scripts for p2wsh in that index
634 2016-04-14 20:13:08	0|sipa|perhaps it's better that it's a separate index
635 2016-04-14 20:13:10	0|sipa|maybe
636 2016-04-14 20:13:37	0|Luke-Jr|oh, you mean just having two different indexes at all, even if non-overlapping
637 2016-04-14 20:14:07	0|sipa|well you need an index anyway for p2wsh scripts
638 2016-04-14 20:14:26	0|sipa|the question is whether it can be the same one or not :)
639 2016-04-14 20:20:27	0|CodeShark|we could in principle add another marker to the address to indicate some operation to be performed on the data to transform it into the scriptPubKey
640 2016-04-14 20:21:47	0|CodeShark|this would give us flexibility to apply other hash functions or transformations later on
641 2016-04-14 20:22:06	0|CodeShark|but I would like to avoid special cases