1 2016-08-11T00:16:57  *** spudowiar has quit IRC
  2 2016-08-11T00:31:41  *** fengling has joined #bitcoin-core-dev
  3 2016-08-11T01:05:51  *** Ylbam has quit IRC
  4 2016-08-11T01:08:18  *** Giszmo has quit IRC
  5 2016-08-11T01:15:02  *** Alopex has quit IRC
  6 2016-08-11T01:16:07  *** Alopex has joined #bitcoin-core-dev
  7 2016-08-11T02:05:26  *** btcdrak has joined #bitcoin-core-dev
  8 2016-08-11T02:18:38  *** TomMc has quit IRC
  9 2016-08-11T02:28:01  *** Alopex has quit IRC
 10 2016-08-11T02:29:06  *** Alopex has joined #bitcoin-core-dev
 11 2016-08-11T02:30:02  *** nibor has quit IRC
 12 2016-08-11T02:41:03  *** Chris_Stewart_5 has quit IRC
 13 2016-08-11T03:44:36  <GitHub104> [bitcoin] jtimon opened pull request #8498: Optimization: Minimize the number of times it is checked that no money... (master...0.13-consensus-inputs) https://github.com/bitcoin/bitcoin/pull/8498
 14 2016-08-11T03:44:39  *** da2ce7 has quit IRC
 15 2016-08-11T03:45:57  *** eenoch has quit IRC
 16 2016-08-11T03:46:19  *** Evel-Knievel has quit IRC
 17 2016-08-11T03:47:09  *** Evel-Knievel has joined #bitcoin-core-dev
 18 2016-08-11T03:47:41  *** ryan-c has quit IRC
 19 2016-08-11T03:47:54  *** eenoch has joined #bitcoin-core-dev
 20 2016-08-11T03:48:33  *** achow101 has quit IRC
 21 2016-08-11T03:48:33  *** go1111111 has quit IRC
 22 2016-08-11T03:49:00  *** Silence_ has quit IRC
 23 2016-08-11T03:49:32  *** Arnavion has quit IRC
 24 2016-08-11T03:49:45  *** Arnavion has joined #bitcoin-core-dev
 25 2016-08-11T03:49:45  *** Arnavion has quit IRC
 26 2016-08-11T03:50:32  *** Silence_ has joined #bitcoin-core-dev
 27 2016-08-11T03:53:24  *** ryan-c has joined #bitcoin-core-dev
 28 2016-08-11T03:53:28  *** da2ce7 has joined #bitcoin-core-dev
 29 2016-08-11T03:53:28  *** Arnavion has joined #bitcoin-core-dev
 30 2016-08-11T03:55:45  *** go1111111 has joined #bitcoin-core-dev
 31 2016-08-11T03:55:47  *** achow101 has joined #bitcoin-core-dev
 32 2016-08-11T04:39:49  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 33 2016-08-11T04:51:13  *** Arnavion has quit IRC
 34 2016-08-11T04:56:35  *** jtimon has quit IRC
 35 2016-08-11T05:31:20  *** Arnavion has joined #bitcoin-core-dev
 36 2016-08-11T05:35:39  *** kadoban has quit IRC
 37 2016-08-11T05:39:56  *** murch has joined #bitcoin-core-dev
 38 2016-08-11T05:40:11  *** btcdrak has quit IRC
 39 2016-08-11T05:41:11  *** aalex_ has joined #bitcoin-core-dev
 40 2016-08-11T05:42:02  *** BashCo_ has joined #bitcoin-core-dev
 41 2016-08-11T05:48:39  *** BashCo has quit IRC
 42 2016-08-11T05:48:39  *** aalex has quit IRC
 43 2016-08-11T06:20:02  *** Alopex has quit IRC
 44 2016-08-11T06:21:07  *** Alopex has joined #bitcoin-core-dev
 45 2016-08-11T06:42:16  *** Alopex has quit IRC
 46 2016-08-11T06:43:21  *** Alopex has joined #bitcoin-core-dev
 47 2016-08-11T06:47:19  *** BashCo_ has quit IRC
 48 2016-08-11T06:56:42  *** dcousens has joined #bitcoin-core-dev
 49 2016-08-11T06:58:30  <dcousens> If I submit an incorrectly formed CLTV transaction,  I get a Error 64: non-mandatory-script-flags error... is that odd considering CLTV is active?
 50 2016-08-11T06:58:33  <dcousens> I know it comes down to  Mandatory script verification flags that all new blocks must comply with for
 51 2016-08-11T06:58:52  <dcousens> I know it comes down MANDATORY_SCRIPT_VERIFY_FLAGS* being const and only has P2SH
 52 2016-08-11T06:59:33  <dcousens> Sorry, mis-type
 53 2016-08-11T07:01:01  <sipa> right, the message is confusing
 54 2016-08-11T07:01:05  <dcousens> My point being, CheckInputs does that double check to recognize you as just a non-standard tx,  but in this case the tx is actually invalid
 55 2016-08-11T07:01:17  <sipa> we have basically three 3 classes of flags:
 56 2016-08-11T07:01:28  <sipa> mandatory <= consensus <= standardness
 57 2016-08-11T07:02:01  <sipa> the reason why consensus != mandatory is because pre-CLTV nodes may relay you violating transactions, and if they do so, you should not ban them for it
 58 2016-08-11T07:03:02  <dcousens> sure,  OK so its purely just an error message issue
 59 2016-08-11T07:03:16  <sipa> but mandatory doesn't even include BIP66
 60 2016-08-11T07:03:22  <sipa> i think we should change that
 61 2016-08-11T07:03:23  <dcousens> indeed
 62 2016-08-11T07:05:47  <dcousens> sipa: perhaps MANDATORY_SCRIPT_FLAGS shouldn't be const, but instead based on the soft-fork status?
 63 2016-08-11T07:06:19  <dcousens> and STANDARD_NOT_MANDATORY_VERIFY_FLAGS derived,  that way it maintains the non banning nature
 64 2016-08-11T07:08:08  <sipa> well MANDATORY flags aren't based on current softfork status, but on what we expect our peers to enforce
 65 2016-08-11T07:08:26  <sipa> s/expect/require/
 66 2016-08-11T07:08:31  <dcousens> sipa: which you would expect to correlate to what soft forks have activated no?
 67 2016-08-11T07:09:20  <sipa> i don't think so
 68 2016-08-11T07:09:37  <sipa> there is no need to break compatibility with old clients
 69 2016-08-11T07:10:00  <sipa> unless there is an attack that can't be fixed without it
 70 2016-08-11T07:10:20  *** BashCo has joined #bitcoin-core-dev
 71 2016-08-11T07:10:37  *** [Author] has quit IRC
 72 2016-08-11T07:11:21  <dcousens> right
 73 2016-08-11T07:14:30  <sipa> but if we ever go as far as breaking such compatibility below 0.10, we can at once include CSV, CLTV and segwit
 74 2016-08-11T07:14:34  <sipa> in mandatory
 75 2016-08-11T07:14:39  <sipa> even before segwit activates
 76 2016-08-11T07:15:00  <sipa> because all those rules only apply to transactions that have been nonstandard for a long time
 77 2016-08-11T07:18:23  <sipa> wumpus: just so i don't forget, a few topics for the meeting 1) segwit policy limits 2) can we propose a softfork to make low-s required simultaneously with segwit? 3) raising mandatory script flags to include bip66?
 78 2016-08-11T07:19:26  <wumpus> sipa: I'll try to remember too
 79 2016-08-11T07:19:36  <dcousens> +1 2)
 80 2016-08-11T07:19:52  <dcousens> anyway, no worries cheers for the help sipa
 81 2016-08-11T07:26:03  *** Cheeseo has quit IRC
 82 2016-08-11T07:26:50  *** dcousens has quit IRC
 83 2016-08-11T07:30:55  *** btcdrak has joined #bitcoin-core-dev
 84 2016-08-11T07:42:39  *** d_t has joined #bitcoin-core-dev
 85 2016-08-11T07:44:57  *** rubensayshi has joined #bitcoin-core-dev
 86 2016-08-11T07:49:04  *** midnightmagic has quit IRC
 87 2016-08-11T07:52:14  *** d_t has quit IRC
 88 2016-08-11T08:04:38  *** [Author] has joined #bitcoin-core-dev
 89 2016-08-11T08:16:01  *** Guyver2 has joined #bitcoin-core-dev
 90 2016-08-11T08:18:45  *** midnightmagic has joined #bitcoin-core-dev
 91 2016-08-11T08:47:15  *** zooko has quit IRC
 92 2016-08-11T08:53:00  *** LeMiner2 is now known as LeMiner
 93 2016-08-11T08:53:29  *** LeMiner has joined #bitcoin-core-dev
 94 2016-08-11T09:09:49  <jl2012> sipa: why would you like to have a low-s softfork? And is it for segwit  scripts only, or for all scripts?
 95 2016-08-11T09:21:25  <sipa> jl2012: it's already nonstandard for a long time, it doesn't hurt anyone, and removes a source of malleability
 96 2016-08-11T09:22:22  <jl2012> so you want it for non-segwit scripts too?
 97 2016-08-11T09:23:07  <sipa> well to be discussed
 98 2016-08-11T09:27:07  *** Giszmo has joined #bitcoin-core-dev
 99 2016-08-11T09:30:12  *** jannes has joined #bitcoin-core-dev
100 2016-08-11T09:30:15  <jl2012> with low-s rule, even the wtxid of a p2wpkh tx is not malleable
101 2016-08-11T09:31:20  <gmaxwell> sipa: jl2012 won't be around during the metting so if you're still awake you might want to discuss with him in PM.
102 2016-08-11T09:32:02  <sipa> i'm about to go sleep
103 2016-08-11T09:33:06  <jl2012> ok no hurry. I'll leave my thought here
104 2016-08-11T09:39:25  *** MarcoFalke has joined #bitcoin-core-dev
105 2016-08-11T09:43:46  *** Yogh has quit IRC
106 2016-08-11T09:44:28  *** Yogh has joined #bitcoin-core-dev
107 2016-08-11T10:02:07  *** JackH has joined #bitcoin-core-dev
108 2016-08-11T10:08:40  <jl2012> I don't see a compelling reason to have a low-s soft fork with segwit (in 0.13.1). Non-segwit txs are hopeless and we should not spend any energy to fix them. For segwit txs, why would we need immallable wtxid?
109 2016-08-11T10:12:21  <sipa> one reason would be avoid 3rd party relayers messing with compact block relay
110 2016-08-11T10:12:51  <jl2012> Immallable wtxid might be desirable for cmpblock and weak block, but enforcing lowS with policy is enough (since miners could always be anti-social)
111 2016-08-11T10:14:06  <jl2012> high-S txs are non-standard already? So it won't happen unless a miner is anti-social
112 2016-08-11T10:14:16  <gmaxwell> jl2012: non-segwit low-s is already standardness required for a long time now.
113 2016-08-11T10:17:06  <jl2012> i don't see how a non-mining malicious relayer could exploit this
114 2016-08-11T10:20:25  <gmaxwell> for compact blocks? not if its a standardness rule, but we have (>=) _100%_ of the code complexity for having it as a consensus rule just by having it as a standardness rule.
115 2016-08-11T10:21:05  <gmaxwell> It provably doesnot usefully expand the utility of the system to permit it, so it's just excess malleability.
116 2016-08-11T10:21:24  <gmaxwell> Standardness rules are also not guarenteed, miners in the past have simply flipped them off.
117 2016-08-11T10:21:46  <jl2012> but it's already a standardness rule?
118 2016-08-11T10:21:58  <gmaxwell> For non-segwit.
119 2016-08-11T10:22:13  <sipa> for segwit too
120 2016-08-11T10:22:16  <jl2012> for segwit too, I believe
121 2016-08-11T10:22:20  <gmaxwell> For non-segwit it leaves open malleability attacks for a greater set of transactions.
122 2016-08-11T10:22:30  <gmaxwell> so there is more reason to preclude it there.
123 2016-08-11T10:22:46  <gmaxwell> (and it has been exploited even since non-standard)
124 2016-08-11T10:22:58  <jl2012> and now you also need the nulldummy softfork too.....
125 2016-08-11T10:23:54  * sipa zZzZ
126 2016-08-11T10:24:09  <jl2012> good night
127 2016-08-11T10:24:31  <gmaxwell> no you don't-- something can only improve things for many transactions, it doesn't have to (and can't) fix everything.
128 2016-08-11T10:25:23  <gmaxwell> and having more vectors for miners to intentionally play with propagation isn't very interesting.
129 2016-08-11T10:25:37  <jl2012> my point is, if a miner wants to be anti-social, they have many different ways. For example, they could mine txs that is never seen on the network.
130 2016-08-11T10:25:46  <gmaxwell> Having more "mandatory standardness rules" doesn't reduce the complexity of the system, it increases it.
131 2016-08-11T10:26:02  <jl2012> and that's less obvious than mining high-S
132 2016-08-11T10:26:04  <gmaxwell> Yes they can, I agree. But that it's a reason that an additional way is desirable.
133 2016-08-11T10:26:20  <gmaxwell> I think both are pretty obvious if done extensively. :)
134 2016-08-11T10:27:30  <gmaxwell> I don't think we should have standardness rules for anything except forward compatibility and things moving towards being softforked out. Otherwise people get a false expectation of what properties the system provides.
135 2016-08-11T10:28:10  <gmaxwell> I was hearing from someone a day ago that wanted to use a cryptographic protocol where the hash of a signature was used as a key.  They could have worked around low/high-S but it surely would have been an unwelcome surprise.
136 2016-08-11T10:29:15  <gmaxwell> so since low-S is already required defacto, it may make sense to require it de jure-- because "not allowed" is fundimentally simpler than "usually not allowed but maybe happens" :)
137 2016-08-11T10:31:21  <jl2012> maybe in the next softfork after segwit? It seems not a strong reason to delay segwit. (I know that's only a one-line change in consensus code but we still need more tests)
138 2016-08-11T10:32:18  <gmaxwell> another way to look at it is that since it is non-standard it is likely completely untested. (not that I'd expect it to have issues)
139 2016-08-11T10:33:50  <gmaxwell> I don't think it would make sense to delay anything for it. (And indeed, I suggested earlier to pieter that segwit really should require compressed pubkeys and absolutely prohbit hybrid pubkeys (which are the worst of all worlds)-- but he pointed out this would require acutal code additions)
140 2016-08-11T10:39:17  <jl2012> What is hybrid monkey?
141 2016-08-11T10:39:45  <jl2012> pubkey...
142 2016-08-11T10:39:53  <jl2012> Autocorrect
143 2016-08-11T10:40:07  <gmaxwell> I'm glad I didn't actually say monkey, but I was worried for a moment.  It's an uncompressed pubkey, but with a sign flag at the front like compressed.
144 2016-08-11T10:40:44  <gmaxwell> This takes all the space of an uncompressed pubkey, but it is as slow to use as a compressed pubkey. (actually very slightly slower).
145 2016-08-11T10:40:53  *** luke-jr has quit IRC
146 2016-08-11T10:41:32  <gmaxwell> As far as anyone can tell there is no reason for them to exist, other than some standards person got too excited about specifying every combination of options. At least at one point that I looked, there weren't any in the blockchain at all.
147 2016-08-11T10:41:36  *** luke-jr has joined #bitcoin-core-dev
148 2016-08-11T10:42:04  <gmaxwell> (at least that we can detect, we can't tell for hash160s we don't know the preimage for)
149 2016-08-11T10:42:33  <gmaxwell> We didn't move to block them in the past because we couldn't be sure that we wouldn't invalidate some txout. But for segwit that problem doesn't exist.
150 2016-08-11T10:42:44  <gmaxwell> but it would be more than a one line change, alas.
151 2016-08-11T10:43:10  <jl2012> Just one line to check the size of key
152 2016-08-11T10:44:13  <gmaxwell> true, if uncompressed and hybrid are limited at the same time... but more than one line to pass the flags through to the right place. :)
153 2016-08-11T10:45:27  *** murch has quit IRC
154 2016-08-11T10:45:50  <jl2012> There is no reason to support uncompressed key in segwit
155 2016-08-11T10:46:00  *** luke-jr has quit IRC
156 2016-08-11T10:46:08  *** luke-jr has joined #bitcoin-core-dev
157 2016-08-11T10:46:19  <gmaxwell> Agreed.
158 2016-08-11T10:46:52  <gmaxwell> (well I could be contrary and argue that someone somewhere might have an easier time migrating to segwit if it did... but, I don't think thats a good argument at all)
159 2016-08-11T10:48:35  *** thesnark has quit IRC
160 2016-08-11T10:51:48  <jl2012> If someone assumes any existing key hashes are valid in segwit, he may lost money
161 2016-08-11T10:52:54  <jl2012> Bad assumption, but I'm not surprised if someone really do that
162 2016-08-11T10:53:03  <gmaxwell> same kind of error might try to reuse a p2pkh hash or a p2sh hash as a segwit script.
163 2016-08-11T10:53:16  <gmaxwell> People have confused p2sh/p2pkh values in the past.
164 2016-08-11T10:54:00  <gmaxwell> though it wasn't a super frequent error. (e.g. two distinct pieces of software made the error, that I'm aware of.. but only two)
165 2016-08-11T10:54:15  *** thesnark has joined #bitcoin-core-dev
166 2016-08-11T10:56:54  <jl2012> I'd like to at least make uncompressed keys non std. It helps to prevent some type of garbage witness attack
167 2016-08-11T11:21:56  *** TomMc has joined #bitcoin-core-dev
168 2016-08-11T11:31:46  *** fengling has quit IRC
169 2016-08-11T11:40:12  <jonasschnelli> Re: https://github.com/bitcoin/bitcoin/issues/8497
170 2016-08-11T11:40:26  <jonasschnelli> I think this would work, although not sure if we want to support that
171 2016-08-11T11:41:26  <jonasschnelli> (importing keys with no rescan option could at least use the UTXO set to get the keys current balance)
172 2016-08-11T11:41:44  <jonasschnelli> But I guess it would be complicated for the current data model implementation
173 2016-08-11T11:50:12  <wumpus> yes it's quite an interesting possibility, if you're not interested in history then rescanning over the utxo set is enough
174 2016-08-11T11:50:35  <wumpus> this is fast and will work with pruned block chain
175 2016-08-11T11:51:23  <wumpus> so no, no categorical objections from me, I've thought of the idea in the past too but yes it requires some deeper changes to handle
176 2016-08-11T11:51:54  <wumpus> I don't think we should call it 'pruned wallet' tho :-)
177 2016-08-11T11:52:02  <wumpus> that word is already overused. Bt that's a nit
178 2016-08-11T11:55:30  *** molly has quit IRC
179 2016-08-11T12:03:28  <jonasschnelli> wumpus: yes. Pruned wallet is confusing. But yes, the feature could be neat...
180 2016-08-11T12:03:34  <jonasschnelli> I just feat the UX implications..
181 2016-08-11T12:04:04  <jonasschnelli> The datamodel needs something like an "initial" balance... atm, everything is calculated with SUM()
182 2016-08-11T12:06:31  *** laurentmt has joined #bitcoin-core-dev
183 2016-08-11T12:07:11  *** laurentmt has quit IRC
184 2016-08-11T12:07:13  <wumpus> yes, you'd need to summarize the non-existent history in an "initial" balance, that seems like just a bit of bookkeeping
185 2016-08-11T12:07:27  <wumpus> agree that with the complicated wallet code it's probably more work than it seems
186 2016-08-11T12:10:57  <wumpus> eh, no, you don't need that
187 2016-08-11T12:11:06  <wumpus> you're not going to throw away transactions that count toward your balance
188 2016-08-11T12:11:43  <wumpus> the completely reduced wallet would contain only transactions with unspent outputs
189 2016-08-11T12:12:01  <wumpus> there may be some changed needed to balance computation, but you should never have to store a balance delta
190 2016-08-11T12:12:02  <jonasschnelli> wumpus: hmm... I guess your right
191 2016-08-11T12:12:31  <jonasschnelli> What about p2sh/multisig?
192 2016-08-11T12:13:11  <wumpus> the wallet utxo index may be helpful here, https://github.com/bitcoin/bitcoin/pull/7823
193 2016-08-11T12:13:33  <wumpus> p2sh/multisig doesn't really change, I think
194 2016-08-11T12:18:54  <wumpus> in any case you are right that the implications should be thought through carefully
195 2016-08-11T12:28:24  *** fengling has joined #bitcoin-core-dev
196 2016-08-11T12:33:06  *** fengling has quit IRC
197 2016-08-11T12:34:52  *** spudowiar has joined #bitcoin-core-dev
198 2016-08-11T12:42:20  *** Squidicuz has quit IRC
199 2016-08-11T12:42:33  *** Squidicuz has joined #bitcoin-core-dev
200 2016-08-11T13:00:12  *** btcdrak has quit IRC
201 2016-08-11T13:01:34  *** spudowiar has quit IRC
202 2016-08-11T13:04:21  *** spudowiar has joined #bitcoin-core-dev
203 2016-08-11T13:06:18  *** BashCo has quit IRC
204 2016-08-11T13:16:04  *** Eliel_ has quit IRC
205 2016-08-11T13:23:17  *** Eliel has joined #bitcoin-core-dev
206 2016-08-11T13:23:29  <GitHub65> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/edebf425a2df...0d0abcac1efe
207 2016-08-11T13:23:29  <GitHub65> bitcoin/master 05242e9 adlawren: Fix minimize and close bugs...
208 2016-08-11T13:23:30  <GitHub65> bitcoin/master 0d0abca Wladimir J. van der Laan: Merge #8481: Qt: Fix minimize and close bugs...
209 2016-08-11T13:23:44  <GitHub196> [bitcoin] laanwj closed pull request #8481: Qt: Fix minimize and close bugs (master...fix-minimize-and-close-bugs) https://github.com/bitcoin/bitcoin/pull/8481
210 2016-08-11T13:26:24  *** Cheeseo has joined #bitcoin-core-dev
211 2016-08-11T13:26:35  *** cjcj has quit IRC
212 2016-08-11T13:27:20  *** jtimon has joined #bitcoin-core-dev
213 2016-08-11T13:29:43  *** fengling has joined #bitcoin-core-dev
214 2016-08-11T13:34:46  *** fengling has quit IRC
215 2016-08-11T13:44:16  *** Chris_Stewart_5 has quit IRC
216 2016-08-11T13:46:41  *** moli has joined #bitcoin-core-dev
217 2016-08-11T13:47:18  *** Chris_Stewart_5 has joined #bitcoin-core-dev
218 2016-08-11T14:18:27  *** bad_duck is now known as kcud_dab
219 2016-08-11T14:22:37  *** kcud_dab is now known as bad_duck
220 2016-08-11T14:29:03  *** btcdrak has joined #bitcoin-core-dev
221 2016-08-11T14:31:23  *** fengling has joined #bitcoin-core-dev
222 2016-08-11T14:35:46  *** fengling has quit IRC
223 2016-08-11T14:39:08  *** bad_duck is now known as kcud_dab
224 2016-08-11T14:40:58  *** kcud_dab is now known as bad_duck
225 2016-08-11T14:48:29  *** jtimon has quit IRC
226 2016-08-11T14:57:03  *** jtimon has joined #bitcoin-core-dev
227 2016-08-11T15:01:25  *** Chris_Stewart_5 has quit IRC
228 2016-08-11T15:16:26  *** BashCo has joined #bitcoin-core-dev
229 2016-08-11T15:17:09  *** murch has joined #bitcoin-core-dev
230 2016-08-11T15:18:14  *** whphhg has quit IRC
231 2016-08-11T15:19:20  *** Chris_Stewart_5 has joined #bitcoin-core-dev
232 2016-08-11T15:32:51  *** Chris_Stewart_5 has quit IRC
233 2016-08-11T15:33:14  *** fengling has joined #bitcoin-core-dev
234 2016-08-11T15:37:26  *** fengling has quit IRC
235 2016-08-11T15:45:12  *** cryptapus_afk is now known as cryptapus_
236 2016-08-11T15:45:15  *** cryptapus_ is now known as cryptapus
237 2016-08-11T15:55:26  *** whphhg has joined #bitcoin-core-dev
238 2016-08-11T16:24:22  *** kadoban has joined #bitcoin-core-dev
239 2016-08-11T16:25:10  <GitHub118> [bitcoin] jl2012 opened pull request #8499: [Untested] Check bad witness (master...badwitnesscheck) https://github.com/bitcoin/bitcoin/pull/8499
240 2016-08-11T16:33:55  *** fengling has joined #bitcoin-core-dev
241 2016-08-11T16:38:46  *** fengling has quit IRC
242 2016-08-11T16:46:42  *** rubensayshi has quit IRC
243 2016-08-11T16:49:25  *** Yogh has quit IRC
244 2016-08-11T17:24:01  *** Yogh has joined #bitcoin-core-dev
245 2016-08-11T17:28:58  *** arowser has quit IRC
246 2016-08-11T17:30:02  *** arowser has joined #bitcoin-core-dev
247 2016-08-11T17:33:23  *** Chris_Stewart_5 has joined #bitcoin-core-dev
248 2016-08-11T17:33:35  *** d_t has joined #bitcoin-core-dev
249 2016-08-11T17:34:04  *** d_t has joined #bitcoin-core-dev
250 2016-08-11T17:51:03  *** Chris_Stewart_5 has quit IRC
251 2016-08-11T17:53:36  *** Chris_Stewart_5 has joined #bitcoin-core-dev
252 2016-08-11T18:13:55  *** Chris_Stewart_5 has quit IRC
253 2016-08-11T18:22:08  *** Chris_Stewart_5 has joined #bitcoin-core-dev
254 2016-08-11T18:27:21  *** Chris_Stewart_5 has quit IRC
255 2016-08-11T18:43:44  *** Chris_Stewart_5 has joined #bitcoin-core-dev
256 2016-08-11T18:59:35  <cfields> meeting?
257 2016-08-11T18:59:42  <jonasschnelli> yes
258 2016-08-11T18:59:42  <wumpus> yes
259 2016-08-11T18:59:45  <wumpus> #startmeeting
260 2016-08-11T18:59:45  <lightningbot> Meeting started Thu Aug 11 18:59:45 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
261 2016-08-11T18:59:45  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
262 2016-08-11T19:00:25  <sipa> present
263 2016-08-11T19:00:37  <wumpus> sipa proposed some topics earlier today: 1) segwit policy limits  2) can we propose a softfork to make low-s required simultaneously with segwit?  3) 3) raising mandatory script flags to include bip66 4)
264 2016-08-11T19:00:41  <wumpus> eh no 4
265 2016-08-11T19:01:11  <wumpus> can anyone do the giant highlight list?
266 2016-08-11T19:01:27  *** yep has joined #bitcoin-core-dev
267 2016-08-11T19:01:44  <jonasschnelli> ping gmaxwell
268 2016-08-11T19:01:47  <cfields> gmaxwell: paging bot
269 2016-08-11T19:01:50  <gmaxwell> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier
270 2016-08-11T19:01:55  <kanzure> hi.
271 2016-08-11T19:02:08  <instagibbs> oops, it's not wednesday, how about that
272 2016-08-11T19:02:08  <wumpus> thanks
273 2016-08-11T19:02:41  <luke-jr> heh
274 2016-08-11T19:02:47  <wumpus> another topic would be rc3 go-ahead
275 2016-08-11T19:02:48  <kanzure> not sure about priority but jtimon was asking for code review eyeballs on #8493
276 2016-08-11T19:03:05  <wumpus> but let's start with sipa's topics
277 2016-08-11T19:03:07  <btcdrak> hi
278 2016-08-11T19:03:14  <wumpus> #topic segwit policy limits
279 2016-08-11T19:03:27  <michagogo> cfields: I think last time he said it's not a bot...
280 2016-08-11T19:03:48  <cfields> michagogo: was a joke :)
281 2016-08-11T19:03:49  <gmaxwell> it's just an alias.
282 2016-08-11T19:03:50  <wumpus> michagogo: all bots say that!
283 2016-08-11T19:03:51  <sipa> jl2012 has suggested some changes to prevent DoS attacks with segwit
284 2016-08-11T19:04:08  <michagogo> Also, if anyone's interested I think the KSK ceremony is starting soon
285 2016-08-11T19:04:21  <sipa> do we in addition want per txin witness size limits or so
286 2016-08-11T19:04:47  *** gmaxwell has left #bitcoin-core-dev
287 2016-08-11T19:04:56  <wumpus> may make sense to add some initial limits, they can always be removed later
288 2016-08-11T19:05:02  <wumpus> adding limits later is more controversial
289 2016-08-11T19:05:14  <sipa> agree
290 2016-08-11T19:05:51  <instagibbs> is this merely to offset people stuffing data for 25% the price
291 2016-08-11T19:05:54  <sipa> but i'd like to know what opinions people have about this
292 2016-08-11T19:06:06  <instagibbs> could you elaborate additional motivations if any
293 2016-08-11T19:06:07  <jl2012> this is a conceptual PR: https://github.com/bitcoin/bitcoin/pull/8499
294 2016-08-11T19:06:11  <wumpus> ofc
295 2016-08-11T19:06:18  <luke-jr> a policy limit matching p2sh's consensus limit sounds uncontroversial
296 2016-08-11T19:06:37  <luke-jr> but this is too small for N-of->15, so maybe slightly larger is desirable
297 2016-08-11T19:07:28  <luke-jr> someone involved with Lightning probably should comment as well
298 2016-08-11T19:07:58  <wumpus> yes, it would be important not to sabotage that
299 2016-08-11T19:08:28  <btcdrak> ping roasbeef GreenIsMyPepper rusty ^
300 2016-08-11T19:08:33  <instagibbs> could someone tell me what we're protecting against first? I can't really form an opinion
301 2016-08-11T19:09:06  <jtimon> is this a new consensus rule or just policy? (looking at 8499 seems policy only, just want to confirm)
302 2016-08-11T19:09:12  <sipa> jl2012: policy
303 2016-08-11T19:09:16  <sipa> eh, jtimon ^
304 2016-08-11T19:09:16  <kanzure> instagibbs: txin witness size bloating
305 2016-08-11T19:09:20  <jtimon> thanks
306 2016-08-11T19:10:05  <sipa> jl2012: 8499 does not set a size limit, right?
307 2016-08-11T19:10:35  <instagibbs> 8499 I think just bans peers for bad witnesses
308 2016-08-11T19:10:58  <sipa> instagibbs: also protection against the problems discussed in #8279
309 2016-08-11T19:11:18  <jl2012> sipa: it's per input size limit
310 2016-08-11T19:11:25  <instagibbs> sipa, yes, makes sense
311 2016-08-11T19:11:37  <sipa> ok
312 2016-08-11T19:12:11  <sipa> jl2012: but no limits for p2wsh
313 2016-08-11T19:12:39  <sipa> (sorry, i haven't looked in detail; correct me if i'm wrong)
314 2016-08-11T19:13:53  <sipa> seems there are not too many opinions; i'll propose some thing for next meeting
315 2016-08-11T19:14:19  <sipa> next topic?
316 2016-08-11T19:14:50  <wumpus> #topic softfork to make low-s required simultaneously with segwit
317 2016-08-11T19:15:37  <wumpus> there was some discussion about this earliet today between sipa and jl2012
318 2016-08-11T19:15:38  <luke-jr> IIRC, this just blocks transactions that can be fixed with malleation anyway. might as well.
319 2016-08-11T19:15:39  <wumpus> <jl2012> sipa: why would you like to have a low-s softfork? And is it for segwit  scripts only, or for all scripts?
320 2016-08-11T19:15:39  <wumpus> <sipa> jl2012: it's already nonstandard for a long time, it doesn't hurt anyone, and removes a source of malleability
321 2016-08-11T19:15:39  <wumpus> <jl2012> so you want it for non-segwit scripts too?
322 2016-08-11T19:15:39  <wumpus> <sipa> well to be discussed
323 2016-08-11T19:15:52  <murch> Are there any downsides to that?
324 2016-08-11T19:15:57  <sipa> so it was recently suggested that since low-s has been non-standard and not present on the network for over a year now, we could propose to turn it into a consensus rules
325 2016-08-11T19:16:06  <wumpus> <jl2012> with low-s rule, even the wtxid of a p2wpkh tx is not malleable
326 2016-08-11T19:16:13  <wumpus> <jl2012> I don't see a compelling reason to have a low-s soft fork with segwit (in 0.13.1). Non-segwit txs are hopeless and we should not spend any energy to fix them. For segwit txs, why would we need immallable wtxid?
327 2016-08-11T19:16:13  <wumpus> <sipa> one reason would be avoid 3rd party relayers messing with compact block relay
328 2016-08-11T19:16:41  <jl2012> sipa: limiting p2wsh is more difficult, I think it could only be done case-by-case
329 2016-08-11T19:16:52  <wumpus> sipa: agreed; the thing for discussion is mostly why to combine it with segwit
330 2016-08-11T19:17:13  <wumpus> a low-s softfork itself at some point is uncontroversial imo
331 2016-08-11T19:17:17  <sipa> pro combining it with segwit: it may be hard to do this as a separate softfork
332 2016-08-11T19:17:32  <jonasschnelli> why is it hard?
333 2016-08-11T19:17:34  <luke-jr> ^
334 2016-08-11T19:17:52  <sipa> miners need to upgrade software
335 2016-08-11T19:18:08  <jonasschnelli> Combine it with another, later software?
336 2016-08-11T19:18:12  <jonasschnelli> softfork
337 2016-08-11T19:18:16  <sipa> a low-s softfork would be uncontroversial, but also very low benefit
338 2016-08-11T19:18:27  <luke-jr> no reason to make it urgent; just roll it out and let miners deploy on their own time?
339 2016-08-11T19:18:30  <sipa> that's possible, but i thought it would be neat to just never have anything but low-s in segwit
340 2016-08-11T19:18:30  <wumpus> but rolling everything into one giant softfork is more risky
341 2016-08-11T19:18:36  <GreenIsMyPepper> reading scrollback...
342 2016-08-11T19:19:30  <wumpus> that is true
343 2016-08-11T19:19:39  <jonasschnelli> I think it's useful to combine to low-s restriction with the SW software in 0.13.1
344 2016-08-11T19:19:52  <sipa> it's literally, VersionBitsActive(pindexPrev, DEPLOYMENT_LOW_S) == ACTIVE { flags |= SCRIPT_VERIFY_LOW_S; }
345 2016-08-11T19:19:56  <wumpus> well yes that would be 0.13.1
346 2016-08-11T19:19:59  <GreenIsMyPepper> is the policy limit for number of sigs? (sorry for the noise)
347 2016-08-11T19:20:05  *** achow101_ has joined #bitcoin-core-dev
348 2016-08-11T19:20:11  <kanzure> size
349 2016-08-11T19:20:13  <jtimon> a low s softfork should be also quite easy, no? it's already implemented, just make a flag mandatory for consensus
350 2016-08-11T19:20:18  <luke-jr> oh, right. speaking of 0.13.1, it seems quite uncontroversial
351 2016-08-11T19:20:20  <instagibbs> Oh, if the two bip9 aren't packaged, I think we should
352 2016-08-11T19:20:25  <wumpus> jtimon: yes, sipa just quoted the code change :)
353 2016-08-11T19:20:28  <instagibbs> (duh, bip9)
354 2016-08-11T19:21:31  <sipa> jl2012 sounded like he thought this would require more testing; and i agree that if due to extra testing this would delay the segwit softfork, we should not
355 2016-08-11T19:21:45  <wumpus> I like coupling an uncontroversial change to a more risky one more than the other way around at least
356 2016-08-11T19:21:46  <kanzure> s/we should not/we should not bundle
357 2016-08-11T19:21:53  <luke-jr> (huh, it occurs to me - not a real suggestion - that we *could* have de-bundled the block size increase from segwit into a separate BIP9 bit, so long as all deployment of segwit included support for the separate blocksize-increase bit; IMO interesting)
358 2016-08-11T19:22:13  <jtimon> no strong opinion about doing the low-s sf with segwit or later
359 2016-08-11T19:22:16  *** Chris_Stewart_5 has quit IRC
360 2016-08-11T19:22:35  <jtimon> but yeah, the sf itself seems uncontroversial
361 2016-08-11T19:22:41  <sipa> gmaxwell countered that if low_s requires testing, that's testing we should be doing already, as it's being enforced on every transaction on the network already, so making it consensus likely just removes the possibility for untested cases
362 2016-08-11T19:23:13  <GreenIsMyPepper> seems cleaner to have low-S from the start, no?
363 2016-08-11T19:24:22  <luke-jr> wumpus: coupling an uncontroversial change to a more controversial one, could be taken as pressure to activate the controversial one; so for that reason, it may be best to keep them separate (like how we don't do softforks in .0 releases)
364 2016-08-11T19:24:34  <luke-jr> (separate in the BIP9 sense, not necessarily a different release)
365 2016-08-11T19:24:53  <instagibbs> luke-jr, my assumption would be a different bit
366 2016-08-11T19:24:54  <btcdrak> I think lowS softfork is a nobrainer, it's also easy and uncomplicated since it's already policy.
367 2016-08-11T19:25:04  <wumpus> luke-jr:that would be if it is uncontroverial *and* attractive, but there's no one really waiting for low-s enforcement, it's just a cleanup
368 2016-08-11T19:25:05  <jtimon> I mean, we can also deploy low-s in, say 0.12.2 before segwit (oh, wait, backport bip9)
369 2016-08-11T19:25:24  <jtimon> if they go in the same release, why separate them in the bip9 sense?
370 2016-08-11T19:25:29  <kanzure> luke-jr: that's at best an argument for your segwit bip9 activation decoupling idea.
371 2016-08-11T19:25:39  <wumpus> I don't think we should deploy anything before segwit
372 2016-08-11T19:25:50  <sipa> wumpus: agree
373 2016-08-11T19:25:58  <jonasschnelli> agree
374 2016-08-11T19:26:27  <wumpus> it's time for segwit now, we should try to move ahead with things instead of introducing more things in between
375 2016-08-11T19:26:35  <luke-jr> kanzure: well, it's almost certainly too late for that (it definitely would add to testing required)
376 2016-08-11T19:26:45  <jtimon> wumpus: just saying that together is not the only option for having low-s from the start of segwit, no strong opinion
377 2016-08-11T19:26:54  <wumpus> so, yeah, let's get 0.13.0 out asap then decide on a timeframe etc for segwit and do 0.13.1
378 2016-08-11T19:27:02  <sipa> ok
379 2016-08-11T19:27:08  <GreenIsMyPepper> luke-jr: to follow up with the above ping, we're presuming a policy limit to be the same as P2SH constraints with the redeemScript size
380 2016-08-11T19:27:22  <luke-jr> GreenIsMyPepper: thanks
381 2016-08-11T19:27:38  *** Ylbam has joined #bitcoin-core-dev
382 2016-08-11T19:27:57  <wumpus> adding LOW_S is fine with me, it's simple to do and not risky and not controversial, indeed is a lot of overhead to do a seperate softfork for it
383 2016-08-11T19:28:32  <instagibbs> also segwit could activate first, in some universe
384 2016-08-11T19:28:33  <sipa> GreenIsMyPepper: oh sure - no reason why segwit would be able to do less than what is currently possible with P2SH
385 2016-08-11T19:29:26  <wumpus> next topic?
386 2016-08-11T19:29:41  <wumpus> #topic raising mandatory script flags to include bip66
387 2016-08-11T19:29:53  <btcdrak> I would prefer we combine lowS with segwit.
388 2016-08-11T19:29:58  <jtimon> regarding luke-jr's argument, I don't think segwit is controversial either, but if segwit+low-s deployment fails, you can always try again with them separated
389 2016-08-11T19:29:59  <sipa> so, we have 3 sets of flags currently
390 2016-08-11T19:30:00  <luke-jr> what node versions does this result in cutting off from the network? pre-0.8, I think?
391 2016-08-11T19:30:16  <sipa> 1) mandatory flags 2) consensus flags 3) standardness
392 2016-08-11T19:30:26  <wumpus> luke-jr: no one is 'cut off' from the network?
393 2016-08-11T19:30:39  <luke-jr> then I am misunderstanding
394 2016-08-11T19:30:42  <jtimon> sipa: how are mandatory flags different from consensus flags?
395 2016-08-11T19:30:50  <sipa> luke-jr is not misunderstanding
396 2016-08-11T19:31:00  <wumpus> luke-jr: it's a softfork so 0.8 nodes should still be able to verify?
397 2016-08-11T19:31:14  <sipa> wumpus: i'm explaining
398 2016-08-11T19:31:27  <instagibbs> Mandatory script verification flags that all new blocks must comply with for
399 2016-08-11T19:31:28  <instagibbs>  * them to be valid. (but old blocks may not comply with) Currently just P2SH,
400 2016-08-11T19:31:34  <sipa> the reason why mandatory flags are different from consensus is because old nodes are not guaranteed to not send us currently-invalid transactions
401 2016-08-11T19:31:36  *** anchow101 has joined #bitcoin-core-dev
402 2016-08-11T19:31:50  <sipa> and we would ban them if they send a BIP66-invalid transaction, for example
403 2016-08-11T19:31:55  <instagibbs> "Failing one of these tests may trigger a DoS ban" I see
404 2016-08-11T19:32:01  <sipa> so that's why BIP66 is not part of mandatory flags
405 2016-08-11T19:32:18  <sipa> i just wanted to bring up the topic, not necessarily for anytime soon
406 2016-08-11T19:32:20  <wumpus> right, so they would not be cut off the network, but only if they actually generate or relay something invalid by new rules
407 2016-08-11T19:32:28  <luke-jr> note we have a fork of 0.5.3 that is actively "maintained" and used
408 2016-08-11T19:32:33  <jtimon> instagibbs: also bip66, bip65 and bip112, no?
409 2016-08-11T19:32:34  <sipa> wumpus: it could partition the network, though
410 2016-08-11T19:32:41  <luke-jr> s/we/someone else on the network/
411 2016-08-11T19:32:55  <wumpus> sipa: ok, let's look at it from the other side then
412 2016-08-11T19:32:57  <instagibbs> jtimon, oh, the comment is straight from master
413 2016-08-11T19:33:00  <wumpus> sipa: what would be the advantage?
414 2016-08-11T19:33:01  <sipa> wumpus: if there is a large group of pre-0.8 nodes connected to eachother, and they get an invalid transactions relayed to eachother
415 2016-08-11T19:33:12  *** chris2000 has joined #bitcoin-core-dev
416 2016-08-11T19:33:23  <jtimon> but all new blocks must comply with those too
417 2016-08-11T19:33:45  <wumpus> does it cost a node a lot of resources to verify BIP66 compliance? if not, why does it warrant DoS banning?
418 2016-08-11T19:33:58  <sipa> wumpus: good point
419 2016-08-11T19:34:22  <sipa> perhaps the policy should just be to never extend mandatory flags
420 2016-08-11T19:34:24  *** achow101_ has quit IRC
421 2016-08-11T19:34:31  <sipa> unless there is a DoS attack that needs it to be fixed
422 2016-08-11T19:34:39  <wumpus> I remember a previous discussion about being less trigger happy regarding DoS banning
423 2016-08-11T19:34:49  <wumpus> right, if there is DoS risk it is the appropriate measure
424 2016-08-11T19:35:04  <sipa> i just noticed that this is something we've been ignoring the value of mandatory flags
425 2016-08-11T19:35:20  <wumpus> yes, sure, it's confusing
426 2016-08-11T19:35:25  <sipa> yes, indeed, i remember reducing dos banning flags
427 2016-08-11T19:35:50  <wumpus> but adding a comment explaining this rationale would do just as well as extending the mandatory flags
428 2016-08-11T19:36:08  <sipa> fair enough
430 2016-08-11T19:36:57  *** chris2000 has quit IRC
431 2016-08-11T19:37:18  <sipa> jtimon: because pre-0.11.2 nodes could get banned by us if they'd send a CSV-violating transaction
432 2016-08-11T19:37:25  <wumpus> jtimon: for the same reason, probably, it would be harmful to DoS ban on them
433 2016-08-11T19:37:45  <luke-jr> jtimon: if a 0.5.3 node sends you a transaction violating those rules, you don't want to ban them, just reject it; if you banned them, you partition such nodes off the network and they stop getting blocks
434 2016-08-11T19:37:55  <wumpus> (to not accidentally partition the network)
435 2016-08-11T19:38:01  <jtimon> ok, so it's all about the DoS score
436 2016-08-11T19:38:06  <wumpus> yes
437 2016-08-11T19:38:23  <instagibbs> so why is it ok to ban a misbehaving p2sh transaction (probably veering off the path here)
438 2016-08-11T19:38:26  *** fengling has joined #bitcoin-core-dev
439 2016-08-11T19:38:44  <jtimon> why SCRIPT_VERIFY_P2SH is different from other softforks for this again?
440 2016-08-11T19:38:48  <wumpus> validation overhead?
441 2016-08-11T19:39:00  *** gmaxwell has joined #bitcoin-core-dev
442 2016-08-11T19:39:06  <sipa> jtimon: it was very old at the time mandatory flags was introduced, so nobody cared, i guess
443 2016-08-11T19:39:13  <gmaxwell> We can't reasonably support old versions forever; We're not testing them, and certantly not testing weirdo transactions with them.  perhaps we should have a program of making links to sufficiently old versions blocks-only after some point.
444 2016-08-11T19:39:43  <wumpus> well people run them on their own risk
445 2016-08-11T19:40:04  <jtimon> wumpus: well they risk being banned, no?
446 2016-08-11T19:40:17  <gmaxwell> yes, though if we blocks only them we won't risk partitioning them do to weirdness with txn handling. Much more likely to be reliable.
447 2016-08-11T19:41:12  <sipa> i think it's more a philosophical issue... another implementation may have different policy, and it's not our place to trigger happy ban them
448 2016-08-11T19:41:12  <sipa> i like the idea of reducing dos banning where possible
449 2016-08-11T19:41:14  <wumpus> sure, but would be best to not DoS ban in the first place for non DoS offenses
450 2016-08-11T19:41:45  <jtimon> sipa: for SCRIPT_VERIFY_P2SH too?
451 2016-08-11T19:41:57  <luke-jr> gmaxwell: would blocks-only treatment break their wallet broadcasts, though?
452 2016-08-11T19:42:07  <gmaxwell> Sending a consensus invalid transaction is a prefectly reasonable thing to ban for ... ignoring that the consensus rules change over time.
453 2016-08-11T19:42:09  <wumpus> I don't think we should make the one-sided decision to make lower version nodes blocks-only
454 2016-08-11T19:42:28  <gmaxwell> luke-jr: yes but nodes that old already have wallet broadcast problems because of high-S enforcement as standardness.
455 2016-08-11T19:42:28  <wumpus> e.g. something may report a low network version but be perfectly able to handle new transactions
456 2016-08-11T19:42:44  <wumpus> they're not really coupled the same way in other software than bitcoin core
457 2016-08-11T19:42:50  <gmaxwell> probablity of their txn not relaying already is exponential in the number of signatures.
458 2016-08-11T19:42:51  <luke-jr> gmaxwell: consider that there's a crowd who insist on using 0.5.3 :/
459 2016-08-11T19:43:06  *** fengling has quit IRC
460 2016-08-11T19:43:06  <wumpus> in any case I don't think this is a very urgent topic
461 2016-08-11T19:43:08  <luke-jr> I guess they must have patched that
462 2016-08-11T19:43:31  <jtimon> luke-jr: who insists in using 0.5.3 ?
463 2016-08-11T19:43:48  <luke-jr> jtimon: therealbitcoin.org people
464 2016-08-11T19:43:52  *** harrymm has joined #bitcoin-core-dev
465 2016-08-11T19:43:58  <gmaxwell> luke-jr: they have to apply a small pile of fixes in any case.
466 2016-08-11T19:44:25  <gmaxwell> presumably they're fixed to produce high-S signatures (or not transacting at all... :P )
467 2016-08-11T19:45:20  <luke-jr> I suppose the BIP 66 patch is fairly trivial to add to that pile if they care; but sipa is right about the principle of not cutting them off IMO
468 2016-08-11T19:45:27  <wumpus> they probably write raw transactions in their head instead of using the bitcoin core wallet
469 2016-08-11T19:45:30  <jtimon> I guess I can ask after the meeting, but why don't they want to upgrade?
470 2016-08-11T19:45:51  <sipa> jtimon: yes, let's discuss that after the meeting
471 2016-08-11T19:45:58  <luke-jr> ^+1
472 2016-08-11T19:46:02  <jtimon> sipa: sure, np
473 2016-08-11T19:46:07  <sipa> i think this is getting too abstract
474 2016-08-11T19:46:21  <sipa> i just wanted to raise attention to the neglected mandatory flags :)
475 2016-08-11T19:46:29  <wumpus> in any case, not our problem, we should not do anything to sabotage use of old clients, but we're also not responsible for making sure all old versions still work, they'll have to do with a pile of patches on top
476 2016-08-11T19:46:33  <wumpus> yes, next topic?
477 2016-08-11T19:46:39  <btcdrak> I dont see any 0.5.3 useragents
478 2016-08-11T19:46:58  <sipa> wumpus: you had rc3 as topic?
479 2016-08-11T19:47:04  <wumpus> #topic rc3 go-ahead
480 2016-08-11T19:47:30  <btcdrak> luke-jr: are you sure there are 0.5.3 nodes on the network? https://bitnodes.21.co/nodes/?q=0.5.3
481 2016-08-11T19:47:32  <wumpus> yes, quick question, anything that still needs to be merged/backported for 0.13.0 apart from release notes?
482 2016-08-11T19:48:09  <wumpus> not seeing anything here https://github.com/bitcoin/bitcoin/milestone/20
483 2016-08-11T19:48:11  <luke-jr> on the off-chance there's no objection, I'd like to PR https://github.com/bitcoin/bitcoin/commit/5a716a3bc6621e4d2e2c1de5b6b5596d6877d589 for 0.13.0 mostly just to make #8459 uncontroversial
484 2016-08-11T19:48:28  <wumpus> so I'm going to tag rc3 in a very short while, after the usual translation updates and such
485 2016-08-11T19:48:49  <luke-jr> btcdrak: 1) those are just listening nodes, 2) 7 nodes show as 99999 "/therealbitcoin.org:"
486 2016-08-11T19:49:23  <wumpus> yes they don't report as 0.5.3
487 2016-08-11T19:49:40  <jtimon> sipa: so should we get  SCRIPT_VERIFY_P2SH out of mandatory too?
488 2016-08-11T19:49:57  <btcdrak> luke-jr: ok so there are 5 nodes out of 5000, I really dont think we have to be concerned.
489 2016-08-11T19:50:01  <sipa> jtimon: out of topic :)
490 2016-08-11T19:50:15  <jtimon> sipa: ok, later too, whatever
491 2016-08-11T19:50:26  <wumpus> btcdrak: it's not a concern
492 2016-08-11T19:50:29  <btcdrak> wumpus: rc3 looks good to go.
493 2016-08-11T19:50:59  <wumpus> foss gives that freedom to run your own stack of weird hacks if you want for whatever reason
494 2016-08-11T19:51:15  <wumpus> btcdrak: ok!
495 2016-08-11T19:51:37  <sipa> ack rc3
496 2016-08-11T19:51:42  *** anchow101 has quit IRC
497 2016-08-11T19:51:44  <jonasschnelli> ready to build
498 2016-08-11T19:51:52  <cfields> sipa: as discussed yesterday, any need to try to get default_witness_commitment added to gbt with no witness data for 0.13.0? So miners can start easily adding commitments even before activation?
499 2016-08-11T19:52:00  <btcdrak> There's also a blog post being written about 0.13.0 if some eyes could review and comment https://github.com/bitcoin-core/bitcoincore.org/pull/199
500 2016-08-11T19:52:03  *** anchow101 has joined #bitcoin-core-dev
501 2016-08-11T19:52:38  <sipa> cfields: fine be me
502 2016-08-11T19:53:18  <sipa> btcdrak: great
503 2016-08-11T19:53:27  *** anchow101 has quit IRC
504 2016-08-11T19:53:30  <wumpus> cfields: eh, so that means holding up rc3?
505 2016-08-11T19:53:32  <cfields> wumpus: opinion ^^? Not critical, we have testnet.
506 2016-08-11T19:53:55  <wumpus> if it's not critical I'd say not do it, at this point
507 2016-08-11T19:54:03  <sipa> cfields: 0.13.0 has no activation, so it would not produce a default_witness_commitment?
508 2016-08-11T19:54:10  <wumpus> unless you want to be that person holding up the release :)
509 2016-08-11T19:54:13  <sipa> i think there is no need for that in 0.13.0
510 2016-08-11T19:54:22  <luke-jr> sipa: the subject was commitments pre-activation
511 2016-08-11T19:54:40  <sipa> i'm confused about that
512 2016-08-11T19:55:01  <wumpus> #link review blog post https://github.com/bitcoin-core/bitcoincore.org/pull/199
513 2016-08-11T19:55:13  <sipa> i think a miner on 0.13.0 should never produce a segwit commitment, and a 0.13.1 one (assuming it has a defined start date) should always (regardless of whether it is before or after the start time)
514 2016-08-11T19:55:35  <gmaxwell> ^ thats my expectation
515 2016-08-11T19:55:38  <sipa> there is no problem if people choose to diverge from that
516 2016-08-11T19:56:08  <wumpus> cfields: to be honest I'm not sure what the advantage or disadvantage of that is
517 2016-08-11T19:56:56  <gmaxwell> The reason I believe we should do that is so that we don't hae sudden behavior changes at times which are far away from updating the software which might break downstream mining infrastructure.
518 2016-08-11T19:56:57  <cfields> works for me. i was only considering it as a way to see that pools had begun adding valid structures. obviously it wouldn't be actually checked/used
519 2016-08-11T19:57:32  <gmaxwell> e.g. if you update your bitcoin node and then days/weeks later it starts doing thing with segwit commitments that breaks your miners or pooling software, that is preferable. You would prefer the break to happen at upgrade time.
520 2016-08-11T19:57:44  <sipa> cfields: 0.13.0 for all intents and purposes behaves identical to older nodes wrt segwit behaviour
521 2016-08-11T19:58:03  <sipa> cfields: so i think there is no point in using witness commitments as a signalling mechanism for anything in 0.13.0 already
522 2016-08-11T19:58:05  <cfields> sipa: understood
523 2016-08-11T19:58:44  <sipa> so, ack rc3?
524 2016-08-11T19:58:50  <gmaxwell> as far as 0.13 vs 0.13.1 I think 0.13 should not change behavior, because it won't ever activate. so there is no problem of behavior suddenly changing with it.
525 2016-08-11T19:58:55  <gmaxwell> rc3 sounds good to me.
526 2016-08-11T19:59:19  <cfields> works for me
527 2016-08-11T19:59:41  <jtimon> yay 0.13.0!
528 2016-08-11T19:59:54  <gmaxwell> jtimon: careful, you're going to trigger some confused reddit posts.
529 2016-08-11T20:00:12  <wumpus> roughly one minute to go
530 2016-08-11T20:00:20  <jtimon> oops, sorry, yay ack rc3
531 2016-08-11T20:00:24  <gmaxwell> I think someone's clock is off.
532 2016-08-11T20:00:31  <gmaxwell> Time to die.
533 2016-08-11T20:00:37  <wumpus> jtimon: yes, let's not get ahead of ourselves
534 2016-08-11T20:00:39  <wumpus> #endmeeting
535 2016-08-11T20:00:39  <lightningbot> Meeting ended Thu Aug 11 20:00:39 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
536 2016-08-11T20:00:39  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-08-11-18.59.html
537 2016-08-11T20:00:39  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-08-11-18.59.txt
538 2016-08-11T20:00:39  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-08-11-18.59.log.html
539 2016-08-11T20:00:40  <sipa> #killtime
540 2016-08-11T20:00:49  <gmaxwell> and it ended on time. hurrah.
541 2016-08-11T20:00:52  * gmaxwell bbl
542 2016-08-11T20:01:03  * btcdrak flies off
543 2016-08-11T20:01:05  <wumpus> no, clock is not off, the server is just travelling at relativistic speeds...
544 2016-08-11T20:01:22  <jtimon> sipa: so should we get  SCRIPT_VERIFY_P2SH out of mandatory too?
545 2016-08-11T20:02:13  <wumpus> or completely drop mandatory?
546 2016-08-11T20:02:31  <luke-jr> jtimon: to answer your earlier question best I can: I think they perceive 0.5.3 as the last release before the Bitcoin Foundation "got involved" (I know the BCF was never involved, but they're conspiracy nuts)
547 2016-08-11T20:02:50  <jtimon> wumpus: well, at that point mandatory would be only SCRIPT_VERIFY_NONE so it's kind of the same
548 2016-08-11T20:03:18  <murch> luke-jr: Are they the people around Mircea Popescu?
549 2016-08-11T20:03:23  <luke-jr> murch: right
550 2016-08-11T20:03:24  <sipa> murch: yes
551 2016-08-11T20:03:26  <pigeons> i asked before too, got answers about gavin making changes for CIA, "only real bitcoin address starts with a 1", etc
552 2016-08-11T20:03:28  <wumpus> jtimon: so after that the logic can be removed, cleanups, yay
553 2016-08-11T20:03:43  <instagibbs> pigeons, how do they feel about base32...
554 2016-08-11T20:03:50  <murch> well, in that case… Why bother putting in the extra work of maintaining special cases for them?
555 2016-08-11T20:03:59  <wumpus> murch: we don't
556 2016-08-11T20:03:59  <jtimon> this reminds me of https://github.com/jtimon/bitcoin/commit/6314ef0aeb288eb01b9250c0b83e9e4b46c17259 btw
557 2016-08-11T20:04:01  <sipa> murch: we shouldn't
558 2016-08-11T20:04:34  <sipa> murch: but we should also find practices that don't gratuiously kick certain types of software off the network, regardless of what that software is
559 2016-08-11T20:04:40  <cfields> wumpus: so, it was a bit too in-detailed for the meeting, so i didn't bother... I'm considering switching approaches on the boost::thread conversion, curious to get your opinion
560 2016-08-11T20:04:40  <pigeons> lol instagibbs i don't know you can ask in #trilema if yu want entertinment
561 2016-08-11T20:04:50  <instagibbs> pigeons, i like not being DoS'd thank you
562 2016-08-11T20:04:53  * instagibbs back on topic
563 2016-08-11T20:04:55  <luke-jr> lol
564 2016-08-11T20:05:00  <jtimon> wumpus: sounds good to me
565 2016-08-11T20:05:05  <wumpus> cfields: what approach do you consider switching to?
566 2016-08-11T20:05:13  * sipa afk
567 2016-08-11T20:05:29  <jtimon> luke-jr: I see, thanks
568 2016-08-11T20:05:31  <murch> okay, I must have missed something, because it sounded like someone was thinking about putting extra code and special rules to maintain compatibility to 0.5.3 with the flags thing
569 2016-08-11T20:05:34  <cfields> wumpus: turns out, osx's clang doesn't support thread_local (ugh). And I doubt it's the only one. So I ended up re-implementing a clone of boost::thread_specific_ptr...
570 2016-08-11T20:05:50  <cfields> wumpus: then a few more little things like that. It keeps growing and growing...
571 2016-08-11T20:06:06  <luke-jr> murch: we currently already have this code; the topic was adjusting it (which would have a side effect of effectively kicking off older nodes from the network)
572 2016-08-11T20:06:09  <wumpus> cfields: what do we use thread local for?
573 2016-08-11T20:06:22  <jtimon> but sipa didn't answer if that would be ok with him
574 2016-08-11T20:06:29  <cfields> wumpus: I've started to think it would make more sense to just fix up our code one place at a time to not require interruptions
575 2016-08-11T20:06:42  <luke-jr> murch: we cannot remove the code, since it is required for every softfork to prevent forking off pre-softfork nodes
576 2016-08-11T20:07:03  <wumpus> cfields: so the interruptions require the spottily-supported functionality?
577 2016-08-11T20:07:04  <murch> By the way, while there are still lots of well-informed people reading this. Does anyone else have another list of realistic spending values for Bitcoin Nodes? I'd love to have a second scenario to test my coin selection simulation on.
578 2016-08-11T20:07:06  <cfields> wumpus: it's necessary for this::thread stuff. So, this_thread::interrupt, this_thread::sleep (interruptible), etc
579 2016-08-11T20:07:32  <cfields> er, this_thread::interruption_point
580 2016-08-11T20:07:49  <murch> luke-jr: Thanks for clarifying
581 2016-08-11T20:08:02  <luke-jr> murch: realistic daily spending values seem to be anything from 0.01 to 1 BTC. :p
582 2016-08-11T20:08:04  <wumpus> there are two uses of boost::thread_specific_ptr at the moment, one in lock debugging, one in util, also for debugging purposes. I think we could switch away from using them
583 2016-08-11T20:08:12  <wumpus> cfields: right
584 2016-08-11T20:08:27  <wumpus> cfields: it's easy enough to switch interruption points to just a flag
585 2016-08-11T20:08:36  <cfields> wumpus: sorry, i was unclear. thread_local or thread_specific_ptr are necessary for implementing the interruptible threads
586 2016-08-11T20:08:42  <wumpus> cfields: after all we always interrupt all threads at once anyway, we don't do it on a per-thread basis
587 2016-08-11T20:08:44  <murch> luke-jr: Sorry, I mean a list of subsequent amounts that were sent by one node, as in a model for simulating wallet behavior.
588 2016-08-11T20:09:03  <wumpus> cfields: e.g. we stuff everything into one thread group
589 2016-08-11T20:09:10  <cfields> wumpus: right, now that we have atomics, we can just throw those checks around instead
590 2016-08-11T20:09:50  <wumpus> right
591 2016-08-11T20:10:15  <cfields> wumpus: i'd be more comfortable with that. I'm growing less and less confident in the correctness of the wrapper.
592 2016-08-11T20:10:26  <wumpus> I agree onthe longer term it'd be nice to have each module handle its own interruption/shutdown, but we could first replace our use of boost::interruption_poiint with a global flag easily enough and do that leater
593 2016-08-11T20:10:42  *** eratkat has joined #bitcoin-core-dev
594 2016-08-11T20:11:22  <wumpus> cfields: sure; we should try to reimplement as little as possible boost functionality, only what we realy need for our current usage
595 2016-08-11T20:12:42  <wumpus> if we can do without thread local data, let's do that
596 2016-08-11T20:12:42  <cfields> wumpus: ok thanks, i'll give that approach a shot
597 2016-08-11T20:13:27  <wumpus> I do like how httpserver was switched to c++11 threads without any issues
598 2016-08-11T20:13:29  <cfields> yea, i think it works out to be easier that way. It means evaluating some of the threads individually, but we were going to have to do that eventually anyway
599 2016-08-11T20:13:31  <wumpus> good work
600 2016-08-11T20:14:54  <cfields> thanks. ok, I'll start pr'ing those changes then.
601 2016-08-11T20:14:56  *** Chris_Stewart_5 has joined #bitcoin-core-dev
602 2016-08-11T20:15:03  <luke-jr> I think we won't know if there are issues until 0.13.0 is out the door. :x
603 2016-08-11T20:15:11  <cfields> shame to throw away all of that wrapper code, but it was a good learning experience :)
604 2016-08-11T20:15:28  <luke-jr> cfields: well, hopefully Apple will get TLS by 0.14? :P
605 2016-08-11T20:16:01  <cfields> luke-jr: yea, it's available in the current xcode beta. funny thing is, they actually ripped it out of upstream clang
606 2016-08-11T20:16:41  <luke-jr> yeah, so just save it until post-0.13 rather than throw away?
607 2016-08-11T20:16:44  <wumpus> cfields: yes it's a pity, but I don't think we could have forseen this
608 2016-08-11T20:16:45  <cfields> but based on that, i'm assuming they're probably not the only ones
609 2016-08-11T20:16:59  <wumpus> cfields: though I think the wrapper was always meant to be temporary?
610 2016-08-11T20:17:25  <wumpus> just a self-contained step in moving away from boost
611 2016-08-11T20:17:41  <cfields> wumpus: right
612 2016-08-11T20:21:54  <wumpus> luke-jr: correction: until 0.14 is out of the door :)
613 2016-08-11T20:23:25  <luke-jr> wumpus: oh, that missed the 0.13 merge window? in any case, we don't know that any C++11 is actually safe yet. (in the sense that we may have users who can no longer build)
614 2016-08-11T20:24:10  <wumpus> many open source projects are switching to requiring c++11
615 2016-08-11T20:24:40  <luke-jr> yes, I'm not arguing against it.
616 2016-08-11T20:25:04  *** MarcoFalke has quit IRC
617 2016-08-11T20:28:26  *** yep has quit IRC
618 2016-08-11T20:38:35  <jtimon> btcdrak: it seems I am the only one that considers moving consensus code a good thing by itself, should I close #8337 and #8329 or rebase them?
619 2016-08-11T20:39:29  *** fengling has joined #bitcoin-core-dev
620 2016-08-11T20:40:03  <btcdrak> jtimon: sorry I am way behind this week.
621 2016-08-11T20:40:31  <jtimon> no worries, I don't need an urgent answer
622 2016-08-11T20:40:55  <btcdrak> please dont close the PRs.
623 2016-08-11T20:41:00  <jtimon> ok
624 2016-08-11T20:41:26  <jtimon> that means rebase I guess
625 2016-08-11T20:43:06  <jtimon> thanks
626 2016-08-11T20:44:06  *** fengling has quit IRC
627 2016-08-11T20:45:12  *** spudowiar has quit IRC
628 2016-08-11T21:01:16  *** molz has joined #bitcoin-core-dev
629 2016-08-11T21:02:28  <luke-jr> wumpus: https://github.com/bitcoin/bitcoin/issues/8500 :|
630 2016-08-11T21:03:00  * luke-jr wonders how compact block code reacts to such thinblock nodes
631 2016-08-11T21:03:28  <wumpus> gah
632 2016-08-11T21:03:37  *** moli has quit IRC
633 2016-08-11T21:03:58  <murch> lol
634 2016-08-11T21:04:30  <murch> it's kinda funny that nobody saw that until now. ^^
635 2016-08-11T21:05:49  <Lightsword> are enough people using thinblocks for it to even matter?
636 2016-08-11T21:06:21  <wumpus> well it's not nice to conflict with something in use, but on the other hand, it's telling enough that it's only discovered now
637 2016-08-11T21:06:40  <Lightsword> I mean, compact blocks is already in use…
638 2016-08-11T21:06:53  <murch> Lightsword: 500 Classic nodes or so
639 2016-08-11T21:07:20  <Lightsword> murch, what’s first classic version that had thinblocks?
640 2016-08-11T21:07:27  <murch> Lightsword: and roughly 90 BU and XT perhaps
641 2016-08-11T21:08:01  <wumpus> would have been useful for finding conflicts if the enumeration actually had the numbers, instead of relying on c++ for counting
642 2016-08-11T21:08:03  <murch> Lightsword: No clue, I just was aware that r/btc had their panties in a twist over the whole Thinblocks/CompactBlocks thing
643 2016-08-11T21:08:20  <luke-jr> I suppose it's important for both protocols to handle malicious nodes, and conflicts are not any worse than malice (technically speaking)
644 2016-08-11T21:08:27  <luke-jr> but it'd be nice to let people implement both
645 2016-08-11T21:08:39  <wumpus> in any case BIP152 has the number: A new inv type (MSG_CMPCT_BLOCK == 4) and several new protocol messages are added: sendcmpct, cmpctblock, getblocktxn, and blocktxn.
646 2016-08-11T21:09:07  <luke-jr> yes, this is a failure of thin blocks to use the BIP process :/
647 2016-08-11T21:09:31  <wumpus> changing that enumeration would mean changing the BIP too
648 2016-08-11T21:09:34  <wumpus> indeed
649 2016-08-11T21:09:40  <Lightsword> yeah…I think core node count with compact block support is roughly the same
650 2016-08-11T21:09:42  <Lightsword> the most common classic node is one that doesn’t seem to support it anyways
651 2016-08-11T21:09:42  *** thaumaturge has joined #bitcoin-core-dev
652 2016-08-11T21:09:45  <luke-jr> even their own BUIP doesn't seem to mention this
653 2016-08-11T21:09:50  <Lightsword> I don’t think people actually use classic in any meaningful sense
654 2016-08-11T21:11:37  <wumpus> yes, clearly a process failure
655 2016-08-11T21:11:48  <murch> Lightsword: Don't let yourself quote like that. You'll face endless harrassment on Reddit. :p I'm having a hard time finding the Bitcoin Classic release notes.
656 2016-08-11T21:12:13  <wumpus> if you grab a number in the protocol you should publish a BIP
657 2016-08-11T21:12:25  <Lightsword> murch, I’m not sure I care
658 2016-08-11T21:12:39  <achow101> so it comes down to who defined that enum first
659 2016-08-11T21:12:41  <wumpus> otherwise how are people supposed to know?
660 2016-08-11T21:13:11  <sipa> wumpus: they published a buip, i think :)
661 2016-08-11T21:13:16  *** Chris_Stewart_5 has quit IRC
662 2016-08-11T21:13:17  <wumpus> it's clearly too late now anyhow
663 2016-08-11T21:13:24  <wumpus> sipa: well that doesn't do it
664 2016-08-11T21:13:31  <Lightsword> wait, is it conflicting with MSG_THINBLOCK or MSG_XTHINBLOCK?
665 2016-08-11T21:13:59  <achow101> MSG_THINBLOCK
666 2016-08-11T21:14:14  <sipa> ah
667 2016-08-11T21:14:15  <wumpus> if we're no longer going to follow the BIP process, could as well abandon it
668 2016-08-11T21:14:36  <Lightsword> so it doesn’t conflict with XT at least since “BUIP010 thin block. We don't support these.”
669 2016-08-11T21:14:43  <Lightsword> for MSG_THINBLOCK
670 2016-08-11T21:15:50  <TD-Linux> they submitted a BIP draft to bitcoin-dev which only reserved the bit with no documentation of what it did
671 2016-08-11T21:16:16  <wumpus> TD-Linux: link?
672 2016-08-11T21:16:31  <TD-Linux> one sec
673 2016-08-11T21:16:38  <luke-jr> sipa: a BUIP that doesn't mention either the inv enum nor the service bit.. :/
674 2016-08-11T21:16:53  <wumpus> it should mention the enum value (4)
675 2016-08-11T21:16:59  *** thaumaturge has quit IRC
676 2016-08-11T21:17:24  <TD-Linux> wumpus, https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-March/012526.html
677 2016-08-11T21:17:28  <murch> Lightsword: Not sure whether that's what you were saying, but bitcoinxt merged XThin blocks in 0.11F on 24th of June.
678 2016-08-11T21:17:31  <luke-jr> TD-Linux: this doesn't mention the enum
679 2016-08-11T21:17:35  <TD-Linux> yes it does
680 2016-08-11T21:17:49  <wumpus> that's about the services bit
681 2016-08-11T21:18:02  <TD-Linux> oh okay I see.
682 2016-08-11T21:18:06  <Lightsword> murch, that issue states the issue isn’t with xthin enum but normal thin enum
683 2016-08-11T21:18:10  <wumpus> not MSG_THINBLOCK inv type
684 2016-08-11T21:19:40  <GitHub73> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/9058617afb24594f09848d2a53403760bd64470a
685 2016-08-11T21:19:40  <GitHub73> bitcoin/0.13 9058617 Wladimir J. van der Laan: qt: translations update pre-rc3
686 2016-08-11T21:20:20  <achow101> The earliest mention of MSG_THINBLOCK that I could find is in their reference implementation here: https://github.com/ptschip/bitcoinxt/commit/7ea5854a3599851beffb1323544173f03d45373b#diff-1df47808b82268c616535e7b20216dfbR157
687 2016-08-11T21:20:29  <achow101> It isn't in any documentation though
688 2016-08-11T21:21:09  <sipa> i also don't see the problem; an implementation that wants to support both can just look at the service bits
689 2016-08-11T21:21:39  <sipa> ah, right, if you want to set both service bits...
690 2016-08-11T21:21:49  <luke-jr> yeah ☺
691 2016-08-11T21:28:26  <GitHub177> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/b52c67c4b188c274de60fbd5e26441e9a644dba6
692 2016-08-11T21:28:26  <GitHub177> bitcoin/0.13 b52c67c Wladimir J. van der Laan: doc: Update changelog for rc3
693 2016-08-11T21:29:16  *** Chris_Stewart_5 has joined #bitcoin-core-dev
694 2016-08-11T21:31:11  <wumpus>  * [new tag]         v0.13.0rc3 -> v0.13.0rc3
695 2016-08-11T21:31:25  <achow101> woo building time
696 2016-08-11T21:32:10  * sipa fires up the gitian
697 2016-08-11T21:37:12  *** laurentmt has joined #bitcoin-core-dev
698 2016-08-11T21:37:36  *** laurentmt has quit IRC
699 2016-08-11T21:40:25  *** fengling has joined #bitcoin-core-dev
700 2016-08-11T21:45:26  *** fengling has quit IRC
701 2016-08-11T21:46:13  *** cryptapus is now known as cryptapus_afk
702 2016-08-11T21:48:05  <cfields> https://github.com/theuni/ckpool/commits/segwit-rebased
703 2016-08-11T21:48:27  <cfields> tested a good bit on testnet. getting ready to push upstream, if anyone's interested in taking a look first
704 2016-08-11T21:48:29  <cfields> luke-jr: ^^
705 2016-08-11T21:49:19  <cfields> oh
706 2016-08-11T21:49:24  * cfields fires up gitian too
707 2016-08-11T21:49:51  <luke-jr> cfields: trade? :P  (I should probably merge tests into libblkmaker segwit first though)
708 2016-08-11T21:50:41  <luke-jr> actually, tests could use review independently: https://github.com/bitcoin/libblkmaker/pull/7
709 2016-08-11T21:50:49  <cfields> luke-jr: trade for libblkmaker review?
710 2016-08-11T21:50:54  <luke-jr> right
711 2016-08-11T21:50:54  <cfields> sure
712 2016-08-11T21:55:55  <cfields> luke-jr: looking now.
713 2016-08-11T21:58:49  *** To7 has joined #bitcoin-core-dev
714 2016-08-11T22:02:15  * michagogo runs his all-in-one gitian script
715 2016-08-11T22:29:02  *** d_t has quit IRC
716 2016-08-11T22:33:26  *** anchow101 has joined #bitcoin-core-dev
717 2016-08-11T22:33:29  *** anchow101 has quit IRC
718 2016-08-11T22:35:00  *** spudowiar has joined #bitcoin-core-dev
719 2016-08-11T22:36:46  <luke-jr> cfields: ok, I think the rest looks good
720 2016-08-11T22:37:56  <cfields> luke-jr: thanks. Still going through yours. the commitment insertion stuff looks fine so far (though i've already looked over that a good bit)
721 2016-08-11T22:38:27  <luke-jr> cfields: eh, the commitment insertion stuff isn't in that PR <.<
722 2016-08-11T22:39:01  <cfields> luke-jr: eh? I'm not looking at the tests, I'm looking at #6
723 2016-08-11T22:39:22  <luke-jr> ok I guess
724 2016-08-11T22:39:37  <luke-jr> IMO the tests should go first though XD
725 2016-08-11T22:39:39  <cfields> need to be familiar with what it's testing first :)
726 2016-08-11T22:42:07  *** fengling has joined #bitcoin-core-dev
727 2016-08-11T22:42:52  *** murch has quit IRC
728 2016-08-11T22:46:26  *** fengling has quit IRC
729 2016-08-11T23:14:40  *** Guyver2 has quit IRC
730 2016-08-11T23:21:26  *** droark has quit IRC
731 2016-08-11T23:25:31  *** Giszmo has quit IRC
732 2016-08-11T23:26:33  <cfields> luke-jr: i don't see anything to complain about in #6. I'll grab/run the tests and go through them.
733 2016-08-11T23:40:54  <luke-jr> cfields: FWIW, I found two things to complain about in #6 >_<  (weightlimit was being enforced even when unset (internally zero), and when transaction weights were unknown)
734 2016-08-11T23:41:25  <luke-jr> oh, maybe I pushed those before you looked XD
735 2016-08-11T23:41:39  <michagogo> cfields: my sigs are up
736 2016-08-11T23:43:28  *** fengling has joined #bitcoin-core-dev
737 2016-08-11T23:48:26  *** fengling has quit IRC