12016-08-11T00:16:57 *** spudowiar has quit IRC
22016-08-11T00:31:41 *** fengling has joined #bitcoin-core-dev
32016-08-11T01:05:51 *** Ylbam has quit IRC
42016-08-11T01:08:18 *** Giszmo has quit IRC
52016-08-11T01:15:02 *** Alopex has quit IRC
62016-08-11T01:16:07 *** Alopex has joined #bitcoin-core-dev
72016-08-11T02:05:26 *** btcdrak has joined #bitcoin-core-dev
82016-08-11T02:18:38 *** TomMc has quit IRC
92016-08-11T02:28:01 *** Alopex has quit IRC
102016-08-11T02:29:06 *** Alopex has joined #bitcoin-core-dev
112016-08-11T02:30:02 *** nibor has quit IRC
122016-08-11T02:41:03 *** Chris_Stewart_5 has quit IRC
132016-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
142016-08-11T03:44:39 *** da2ce7 has quit IRC
152016-08-11T03:45:57 *** eenoch has quit IRC
162016-08-11T03:46:19 *** Evel-Knievel has quit IRC
172016-08-11T03:47:09 *** Evel-Knievel has joined #bitcoin-core-dev
182016-08-11T03:47:41 *** ryan-c has quit IRC
192016-08-11T03:47:54 *** eenoch has joined #bitcoin-core-dev
202016-08-11T03:48:33 *** achow101 has quit IRC
212016-08-11T03:48:33 *** go1111111 has quit IRC
222016-08-11T03:49:00 *** Silence_ has quit IRC
232016-08-11T03:49:32 *** Arnavion has quit IRC
242016-08-11T03:49:45 *** Arnavion has joined #bitcoin-core-dev
252016-08-11T03:49:45 *** Arnavion has quit IRC
262016-08-11T03:50:32 *** Silence_ has joined #bitcoin-core-dev
272016-08-11T03:53:24 *** ryan-c has joined #bitcoin-core-dev
282016-08-11T03:53:28 *** da2ce7 has joined #bitcoin-core-dev
292016-08-11T03:53:28 *** Arnavion has joined #bitcoin-core-dev
302016-08-11T03:55:45 *** go1111111 has joined #bitcoin-core-dev
312016-08-11T03:55:47 *** achow101 has joined #bitcoin-core-dev
322016-08-11T04:39:49 *** Chris_Stewart_5 has joined #bitcoin-core-dev
332016-08-11T04:51:13 *** Arnavion has quit IRC
342016-08-11T04:56:35 *** jtimon has quit IRC
352016-08-11T05:31:20 *** Arnavion has joined #bitcoin-core-dev
362016-08-11T05:35:39 *** kadoban has quit IRC
372016-08-11T05:39:56 *** murch has joined #bitcoin-core-dev
382016-08-11T05:40:11 *** btcdrak has quit IRC
392016-08-11T05:41:11 *** aalex_ has joined #bitcoin-core-dev
402016-08-11T05:42:02 *** BashCo_ has joined #bitcoin-core-dev
412016-08-11T05:48:39 *** BashCo has quit IRC
422016-08-11T05:48:39 *** aalex has quit IRC
432016-08-11T06:20:02 *** Alopex has quit IRC
442016-08-11T06:21:07 *** Alopex has joined #bitcoin-core-dev
452016-08-11T06:42:16 *** Alopex has quit IRC
462016-08-11T06:43:21 *** Alopex has joined #bitcoin-core-dev
472016-08-11T06:47:19 *** BashCo_ has quit IRC
482016-08-11T06:56:42 *** dcousens has joined #bitcoin-core-dev
492016-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?
502016-08-11T06:58:33 <dcousens> I know it comes down to Mandatory script verification flags that all new blocks must comply with for
512016-08-11T06:58:52 <dcousens> I know it comes down MANDATORY_SCRIPT_VERIFY_FLAGS* being const and only has P2SH
522016-08-11T06:59:33 <dcousens> Sorry, mis-type
532016-08-11T07:01:01 <sipa> right, the message is confusing
542016-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
552016-08-11T07:01:17 <sipa> we have basically three 3 classes of flags:
562016-08-11T07:01:28 <sipa> mandatory <= consensus <= standardness
572016-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
582016-08-11T07:03:02 <dcousens> sure, OK so its purely just an error message issue
592016-08-11T07:03:16 <sipa> but mandatory doesn't even include BIP66
602016-08-11T07:03:22 <sipa> i think we should change that
612016-08-11T07:03:23 <dcousens> indeed
622016-08-11T07:05:47 <dcousens> sipa: perhaps MANDATORY_SCRIPT_FLAGS shouldn't be const, but instead based on the soft-fork status?
632016-08-11T07:06:19 <dcousens> and STANDARD_NOT_MANDATORY_VERIFY_FLAGS derived, that way it maintains the non banning nature
642016-08-11T07:08:08 <sipa> well MANDATORY flags aren't based on current softfork status, but on what we expect our peers to enforce
652016-08-11T07:08:26 <sipa> s/expect/require/
662016-08-11T07:08:31 <dcousens> sipa: which you would expect to correlate to what soft forks have activated no?
672016-08-11T07:09:20 <sipa> i don't think so
682016-08-11T07:09:37 <sipa> there is no need to break compatibility with old clients
692016-08-11T07:10:00 <sipa> unless there is an attack that can't be fixed without it
702016-08-11T07:10:20 *** BashCo has joined #bitcoin-core-dev
712016-08-11T07:10:37 *** [Author] has quit IRC
722016-08-11T07:11:21 <dcousens> right
732016-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
742016-08-11T07:14:34 <sipa> in mandatory
752016-08-11T07:14:39 <sipa> even before segwit activates
762016-08-11T07:15:00 <sipa> because all those rules only apply to transactions that have been nonstandard for a long time
772016-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?
782016-08-11T07:19:26 <wumpus> sipa: I'll try to remember too
792016-08-11T07:19:36 <dcousens> +1 2)
802016-08-11T07:19:52 <dcousens> anyway, no worries cheers for the help sipa
812016-08-11T07:26:03 *** Cheeseo has quit IRC
822016-08-11T07:26:50 *** dcousens has quit IRC
832016-08-11T07:30:55 *** btcdrak has joined #bitcoin-core-dev
842016-08-11T07:42:39 *** d_t has joined #bitcoin-core-dev
852016-08-11T07:44:57 *** rubensayshi has joined #bitcoin-core-dev
862016-08-11T07:49:04 *** midnightmagic has quit IRC
872016-08-11T07:52:14 *** d_t has quit IRC
882016-08-11T08:04:38 *** [Author] has joined #bitcoin-core-dev
892016-08-11T08:16:01 *** Guyver2 has joined #bitcoin-core-dev
902016-08-11T08:18:45 *** midnightmagic has joined #bitcoin-core-dev
912016-08-11T08:47:15 *** zooko has quit IRC
922016-08-11T08:53:00 *** LeMiner2 is now known as LeMiner
932016-08-11T08:53:29 *** LeMiner has joined #bitcoin-core-dev
942016-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?
952016-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
962016-08-11T09:22:22 <jl2012> so you want it for non-segwit scripts too?
972016-08-11T09:23:07 <sipa> well to be discussed
982016-08-11T09:27:07 *** Giszmo has joined #bitcoin-core-dev
992016-08-11T09:30:12 *** jannes has joined #bitcoin-core-dev
1002016-08-11T09:30:15 <jl2012> with low-s rule, even the wtxid of a p2wpkh tx is not malleable
1012016-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.
1022016-08-11T09:32:02 <sipa> i'm about to go sleep
1032016-08-11T09:33:06 <jl2012> ok no hurry. I'll leave my thought here
1042016-08-11T09:39:25 *** MarcoFalke has joined #bitcoin-core-dev
1052016-08-11T09:43:46 *** Yogh has quit IRC
1062016-08-11T09:44:28 *** Yogh has joined #bitcoin-core-dev
1072016-08-11T10:02:07 *** JackH has joined #bitcoin-core-dev
1082016-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?
1092016-08-11T10:12:21 <sipa> one reason would be avoid 3rd party relayers messing with compact block relay
1102016-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)
1112016-08-11T10:14:06 <jl2012> high-S txs are non-standard already? So it won't happen unless a miner is anti-social
1122016-08-11T10:14:16 <gmaxwell> jl2012: non-segwit low-s is already standardness required for a long time now.
1132016-08-11T10:17:06 <jl2012> i don't see how a non-mining malicious relayer could exploit this
1142016-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.
1152016-08-11T10:21:05 <gmaxwell> It provably doesnot usefully expand the utility of the system to permit it, so it's just excess malleability.
1162016-08-11T10:21:24 <gmaxwell> Standardness rules are also not guarenteed, miners in the past have simply flipped them off.
1172016-08-11T10:21:46 <jl2012> but it's already a standardness rule?
1182016-08-11T10:21:58 <gmaxwell> For non-segwit.
1192016-08-11T10:22:13 <sipa> for segwit too
1202016-08-11T10:22:16 <jl2012> for segwit too, I believe
1212016-08-11T10:22:20 <gmaxwell> For non-segwit it leaves open malleability attacks for a greater set of transactions.
1222016-08-11T10:22:30 <gmaxwell> so there is more reason to preclude it there.
1232016-08-11T10:22:46 <gmaxwell> (and it has been exploited even since non-standard)
1242016-08-11T10:22:58 <jl2012> and now you also need the nulldummy softfork too.....
1252016-08-11T10:23:54 * sipa zZzZ
1262016-08-11T10:24:09 <jl2012> good night
1272016-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.
1282016-08-11T10:25:23 <gmaxwell> and having more vectors for miners to intentionally play with propagation isn't very interesting.
1292016-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.
1302016-08-11T10:25:46 <gmaxwell> Having more "mandatory standardness rules" doesn't reduce the complexity of the system, it increases it.
1312016-08-11T10:26:02 <jl2012> and that's less obvious than mining high-S
1322016-08-11T10:26:04 <gmaxwell> Yes they can, I agree. But that it's a reason that an additional way is desirable.
1332016-08-11T10:26:20 <gmaxwell> I think both are pretty obvious if done extensively. :)
1342016-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.
1352016-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.
1362016-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" :)
1372016-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)
1382016-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)
1392016-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)
1402016-08-11T10:39:17 <jl2012> What is hybrid monkey?
1412016-08-11T10:39:45 <jl2012> pubkey...
1422016-08-11T10:39:53 <jl2012> Autocorrect
1432016-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.
1442016-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).
1452016-08-11T10:40:53 *** luke-jr has quit IRC
1462016-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.
1472016-08-11T10:41:36 *** luke-jr has joined #bitcoin-core-dev
1482016-08-11T10:42:04 <gmaxwell> (at least that we can detect, we can't tell for hash160s we don't know the preimage for)
1492016-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.
1502016-08-11T10:42:44 <gmaxwell> but it would be more than a one line change, alas.
1512016-08-11T10:43:10 <jl2012> Just one line to check the size of key
1522016-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. :)
1532016-08-11T10:45:27 *** murch has quit IRC
1542016-08-11T10:45:50 <jl2012> There is no reason to support uncompressed key in segwit
1552016-08-11T10:46:00 *** luke-jr has quit IRC
1562016-08-11T10:46:08 *** luke-jr has joined #bitcoin-core-dev
1572016-08-11T10:46:19 <gmaxwell> Agreed.
1582016-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)
1592016-08-11T10:48:35 *** thesnark has quit IRC
1602016-08-11T10:51:48 <jl2012> If someone assumes any existing key hashes are valid in segwit, he may lost money
1612016-08-11T10:52:54 <jl2012> Bad assumption, but I'm not surprised if someone really do that
1622016-08-11T10:53:03 <gmaxwell> same kind of error might try to reuse a p2pkh hash or a p2sh hash as a segwit script.
1632016-08-11T10:53:16 <gmaxwell> People have confused p2sh/p2pkh values in the past.
1642016-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)
1652016-08-11T10:54:15 *** thesnark has joined #bitcoin-core-dev
1662016-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
1672016-08-11T11:21:56 *** TomMc has joined #bitcoin-core-dev
1682016-08-11T11:31:46 *** fengling has quit IRC
1692016-08-11T11:40:12 <jonasschnelli> Re: https://github.com/bitcoin/bitcoin/issues/8497
1702016-08-11T11:40:26 <jonasschnelli> I think this would work, although not sure if we want to support that
1712016-08-11T11:41:26 <jonasschnelli> (importing keys with no rescan option could at least use the UTXO set to get the keys current balance)
1722016-08-11T11:41:44 <jonasschnelli> But I guess it would be complicated for the current data model implementation
1732016-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
1742016-08-11T11:50:35 <wumpus> this is fast and will work with pruned block chain
1752016-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
1762016-08-11T11:51:54 <wumpus> I don't think we should call it 'pruned wallet' tho :-)
1772016-08-11T11:52:02 <wumpus> that word is already overused. Bt that's a nit
1782016-08-11T11:55:30 *** molly has quit IRC
1792016-08-11T12:03:28 <jonasschnelli> wumpus: yes. Pruned wallet is confusing. But yes, the feature could be neat...
1802016-08-11T12:03:34 <jonasschnelli> I just feat the UX implications..
1812016-08-11T12:04:04 <jonasschnelli> The datamodel needs something like an "initial" balance... atm, everything is calculated with SUM()
1822016-08-11T12:06:31 *** laurentmt has joined #bitcoin-core-dev
1832016-08-11T12:07:11 *** laurentmt has quit IRC
1842016-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
1852016-08-11T12:07:27 <wumpus> agree that with the complicated wallet code it's probably more work than it seems
1862016-08-11T12:10:57 <wumpus> eh, no, you don't need that
1872016-08-11T12:11:06 <wumpus> you're not going to throw away transactions that count toward your balance
1882016-08-11T12:11:43 <wumpus> the completely reduced wallet would contain only transactions with unspent outputs
1892016-08-11T12:12:01 <wumpus> there may be some changed needed to balance computation, but you should never have to store a balance delta
1902016-08-11T12:12:02 <jonasschnelli> wumpus: hmm... I guess your right
1912016-08-11T12:12:31 <jonasschnelli> What about p2sh/multisig?
1922016-08-11T12:13:11 <wumpus> the wallet utxo index may be helpful here, https://github.com/bitcoin/bitcoin/pull/7823
1932016-08-11T12:13:33 <wumpus> p2sh/multisig doesn't really change, I think
1942016-08-11T12:18:54 <wumpus> in any case you are right that the implications should be thought through carefully
1952016-08-11T12:28:24 *** fengling has joined #bitcoin-core-dev
1962016-08-11T12:33:06 *** fengling has quit IRC
1972016-08-11T12:34:52 *** spudowiar has joined #bitcoin-core-dev
1982016-08-11T12:42:20 *** Squidicuz has quit IRC
1992016-08-11T12:42:33 *** Squidicuz has joined #bitcoin-core-dev
2002016-08-11T13:00:12 *** btcdrak has quit IRC
2012016-08-11T13:01:34 *** spudowiar has quit IRC
2022016-08-11T13:04:21 *** spudowiar has joined #bitcoin-core-dev
2032016-08-11T13:06:18 *** BashCo has quit IRC
2042016-08-11T13:16:04 *** Eliel_ has quit IRC
2052016-08-11T13:23:17 *** Eliel has joined #bitcoin-core-dev
2062016-08-11T13:23:29 <GitHub65> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/edebf425a2df...0d0abcac1efe
2072016-08-11T13:23:29 <GitHub65> bitcoin/master 05242e9 adlawren: Fix minimize and close bugs...
2082016-08-11T13:23:30 <GitHub65> bitcoin/master 0d0abca Wladimir J. van der Laan: Merge #8481: Qt: Fix minimize and close bugs...
2092016-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
2102016-08-11T13:26:24 *** Cheeseo has joined #bitcoin-core-dev
2112016-08-11T13:26:35 *** cjcj has quit IRC
2122016-08-11T13:27:20 *** jtimon has joined #bitcoin-core-dev
2132016-08-11T13:29:43 *** fengling has joined #bitcoin-core-dev
2142016-08-11T13:34:46 *** fengling has quit IRC
2152016-08-11T13:44:16 *** Chris_Stewart_5 has quit IRC
2162016-08-11T13:46:41 *** moli has joined #bitcoin-core-dev
2172016-08-11T13:47:18 *** Chris_Stewart_5 has joined #bitcoin-core-dev
2182016-08-11T14:18:27 *** bad_duck is now known as kcud_dab
2192016-08-11T14:22:37 *** kcud_dab is now known as bad_duck
2202016-08-11T14:29:03 *** btcdrak has joined #bitcoin-core-dev
2212016-08-11T14:31:23 *** fengling has joined #bitcoin-core-dev
2222016-08-11T14:35:46 *** fengling has quit IRC
2232016-08-11T14:39:08 *** bad_duck is now known as kcud_dab
2242016-08-11T14:40:58 *** kcud_dab is now known as bad_duck
2252016-08-11T14:48:29 *** jtimon has quit IRC
2262016-08-11T14:57:03 *** jtimon has joined #bitcoin-core-dev
2272016-08-11T15:01:25 *** Chris_Stewart_5 has quit IRC
2282016-08-11T15:16:26 *** BashCo has joined #bitcoin-core-dev
2292016-08-11T15:17:09 *** murch has joined #bitcoin-core-dev
2302016-08-11T15:18:14 *** whphhg has quit IRC
2312016-08-11T15:19:20 *** Chris_Stewart_5 has joined #bitcoin-core-dev
2322016-08-11T15:32:51 *** Chris_Stewart_5 has quit IRC
2332016-08-11T15:33:14 *** fengling has joined #bitcoin-core-dev
2342016-08-11T15:37:26 *** fengling has quit IRC
2352016-08-11T15:45:12 *** cryptapus_afk is now known as cryptapus_
2362016-08-11T15:45:15 *** cryptapus_ is now known as cryptapus
2372016-08-11T15:55:26 *** whphhg has joined #bitcoin-core-dev
2382016-08-11T16:24:22 *** kadoban has joined #bitcoin-core-dev
2392016-08-11T16:25:10 <GitHub118> [bitcoin] jl2012 opened pull request #8499: [Untested] Check bad witness (master...badwitnesscheck) https://github.com/bitcoin/bitcoin/pull/8499
2402016-08-11T16:33:55 *** fengling has joined #bitcoin-core-dev
2412016-08-11T16:38:46 *** fengling has quit IRC
2422016-08-11T16:46:42 *** rubensayshi has quit IRC
2432016-08-11T16:49:25 *** Yogh has quit IRC
2442016-08-11T17:24:01 *** Yogh has joined #bitcoin-core-dev
2452016-08-11T17:28:58 *** arowser has quit IRC
2462016-08-11T17:30:02 *** arowser has joined #bitcoin-core-dev
2472016-08-11T17:33:23 *** Chris_Stewart_5 has joined #bitcoin-core-dev
2482016-08-11T17:33:35 *** d_t has joined #bitcoin-core-dev
2492016-08-11T17:34:04 *** d_t has joined #bitcoin-core-dev
2502016-08-11T17:51:03 *** Chris_Stewart_5 has quit IRC
2512016-08-11T17:53:36 *** Chris_Stewart_5 has joined #bitcoin-core-dev
2522016-08-11T18:13:55 *** Chris_Stewart_5 has quit IRC
2532016-08-11T18:22:08 *** Chris_Stewart_5 has joined #bitcoin-core-dev
2542016-08-11T18:27:21 *** Chris_Stewart_5 has quit IRC
2552016-08-11T18:43:44 *** Chris_Stewart_5 has joined #bitcoin-core-dev
2562016-08-11T18:59:35 <cfields> meeting?
2572016-08-11T18:59:42 <jonasschnelli> yes
2582016-08-11T18:59:42 <wumpus> yes
2592016-08-11T18:59:45 <wumpus> #startmeeting
2602016-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.
2612016-08-11T18:59:45 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
2622016-08-11T19:00:25 <sipa> present
2632016-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)
2642016-08-11T19:00:41 <wumpus> eh no 4
2652016-08-11T19:01:11 <wumpus> can anyone do the giant highlight list?
2662016-08-11T19:01:27 *** yep has joined #bitcoin-core-dev
2672016-08-11T19:01:44 <jonasschnelli> ping gmaxwell
2682016-08-11T19:01:47 <cfields> gmaxwell: paging bot
2692016-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
2702016-08-11T19:01:55 <kanzure> hi.
2712016-08-11T19:02:08 <instagibbs> oops, it's not wednesday, how about that
2722016-08-11T19:02:08 <wumpus> thanks
2732016-08-11T19:02:41 <luke-jr> heh
2742016-08-11T19:02:47 <wumpus> another topic would be rc3 go-ahead
2752016-08-11T19:02:48 <kanzure> not sure about priority but jtimon was asking for code review eyeballs on #8493
2762016-08-11T19:03:05 <wumpus> but let's start with sipa's topics
2772016-08-11T19:03:07 <btcdrak> hi
2782016-08-11T19:03:14 <wumpus> #topic segwit policy limits
2792016-08-11T19:03:27 <michagogo> cfields: I think last time he said it's not a bot...
2802016-08-11T19:03:48 <cfields> michagogo: was a joke :)
2812016-08-11T19:03:49 <gmaxwell> it's just an alias.
2822016-08-11T19:03:50 <wumpus> michagogo: all bots say that!
2832016-08-11T19:03:51 <sipa> jl2012 has suggested some changes to prevent DoS attacks with segwit
2842016-08-11T19:04:08 <michagogo> Also, if anyone's interested I think the KSK ceremony is starting soon
2852016-08-11T19:04:21 <sipa> do we in addition want per txin witness size limits or so
2862016-08-11T19:04:47 *** gmaxwell has left #bitcoin-core-dev
2872016-08-11T19:04:56 <wumpus> may make sense to add some initial limits, they can always be removed later
2882016-08-11T19:05:02 <wumpus> adding limits later is more controversial
2892016-08-11T19:05:14 <sipa> agree
2902016-08-11T19:05:51 <instagibbs> is this merely to offset people stuffing data for 25% the price
2912016-08-11T19:05:54 <sipa> but i'd like to know what opinions people have about this
2922016-08-11T19:06:06 <instagibbs> could you elaborate additional motivations if any
2932016-08-11T19:06:07 <jl2012> this is a conceptual PR: https://github.com/bitcoin/bitcoin/pull/8499
2942016-08-11T19:06:11 <wumpus> ofc
2952016-08-11T19:06:18 <luke-jr> a policy limit matching p2sh's consensus limit sounds uncontroversial
2962016-08-11T19:06:37 <luke-jr> but this is too small for N-of->15, so maybe slightly larger is desirable
2972016-08-11T19:07:28 <luke-jr> someone involved with Lightning probably should comment as well
2982016-08-11T19:07:58 <wumpus> yes, it would be important not to sabotage that
2992016-08-11T19:08:28 <btcdrak> ping roasbeef GreenIsMyPepper rusty ^
3002016-08-11T19:08:33 <instagibbs> could someone tell me what we're protecting against first? I can't really form an opinion
3012016-08-11T19:09:06 <jtimon> is this a new consensus rule or just policy? (looking at 8499 seems policy only, just want to confirm)
3022016-08-11T19:09:12 <sipa> jl2012: policy
3032016-08-11T19:09:16 <sipa> eh, jtimon ^
3042016-08-11T19:09:16 <kanzure> instagibbs: txin witness size bloating
3052016-08-11T19:09:20 <jtimon> thanks
3062016-08-11T19:10:05 <sipa> jl2012: 8499 does not set a size limit, right?
3072016-08-11T19:10:35 <instagibbs> 8499 I think just bans peers for bad witnesses
3082016-08-11T19:10:58 <sipa> instagibbs: also protection against the problems discussed in #8279
3092016-08-11T19:11:18 <jl2012> sipa: it's per input size limit
3102016-08-11T19:11:25 <instagibbs> sipa, yes, makes sense
3112016-08-11T19:11:37 <sipa> ok
3122016-08-11T19:12:11 <sipa> jl2012: but no limits for p2wsh
3132016-08-11T19:12:39 <sipa> (sorry, i haven't looked in detail; correct me if i'm wrong)
3142016-08-11T19:13:53 <sipa> seems there are not too many opinions; i'll propose some thing for next meeting
3152016-08-11T19:14:19 <sipa> next topic?
3162016-08-11T19:14:50 <wumpus> #topic softfork to make low-s required simultaneously with segwit
3172016-08-11T19:15:37 <wumpus> there was some discussion about this earliet today between sipa and jl2012
3182016-08-11T19:15:38 <luke-jr> IIRC, this just blocks transactions that can be fixed with malleation anyway. might as well.
3192016-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?
3202016-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
3212016-08-11T19:15:39 <wumpus> <jl2012> so you want it for non-segwit scripts too?
3222016-08-11T19:15:39 <wumpus> <sipa> well to be discussed
3232016-08-11T19:15:52 <murch> Are there any downsides to that?
3242016-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
3252016-08-11T19:16:06 <wumpus> <jl2012> with low-s rule, even the wtxid of a p2wpkh tx is not malleable
3262016-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?
3272016-08-11T19:16:13 <wumpus> <sipa> one reason would be avoid 3rd party relayers messing with compact block relay
3282016-08-11T19:16:41 <jl2012> sipa: limiting p2wsh is more difficult, I think it could only be done case-by-case
3292016-08-11T19:16:52 <wumpus> sipa: agreed; the thing for discussion is mostly why to combine it with segwit
3302016-08-11T19:17:13 <wumpus> a low-s softfork itself at some point is uncontroversial imo
3312016-08-11T19:17:17 <sipa> pro combining it with segwit: it may be hard to do this as a separate softfork
3322016-08-11T19:17:32 <jonasschnelli> why is it hard?
3332016-08-11T19:17:34 <luke-jr> ^
3342016-08-11T19:17:52 <sipa> miners need to upgrade software
3352016-08-11T19:18:08 <jonasschnelli> Combine it with another, later software?
3362016-08-11T19:18:12 <jonasschnelli> softfork
3372016-08-11T19:18:16 <sipa> a low-s softfork would be uncontroversial, but also very low benefit
3382016-08-11T19:18:27 <luke-jr> no reason to make it urgent; just roll it out and let miners deploy on their own time?
3392016-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
3402016-08-11T19:18:30 <wumpus> but rolling everything into one giant softfork is more risky
3412016-08-11T19:18:36 <GreenIsMyPepper> reading scrollback...
3422016-08-11T19:19:30 <wumpus> that is true
3432016-08-11T19:19:39 <jonasschnelli> I think it's useful to combine to low-s restriction with the SW software in 0.13.1
3442016-08-11T19:19:52 <sipa> it's literally, VersionBitsActive(pindexPrev, DEPLOYMENT_LOW_S) == ACTIVE { flags |= SCRIPT_VERIFY_LOW_S; }
3452016-08-11T19:19:56 <wumpus> well yes that would be 0.13.1
3462016-08-11T19:19:59 <GreenIsMyPepper> is the policy limit for number of sigs? (sorry for the noise)
3472016-08-11T19:20:05 *** achow101_ has joined #bitcoin-core-dev
3482016-08-11T19:20:11 <kanzure> size
3492016-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
3502016-08-11T19:20:18 <luke-jr> oh, right. speaking of 0.13.1, it seems quite uncontroversial
3512016-08-11T19:20:20 <instagibbs> Oh, if the two bip9 aren't packaged, I think we should
3522016-08-11T19:20:25 <wumpus> jtimon: yes, sipa just quoted the code change :)
3532016-08-11T19:20:28 <instagibbs> (duh, bip9)
3542016-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
3552016-08-11T19:21:45 <wumpus> I like coupling an uncontroversial change to a more risky one more than the other way around at least
3562016-08-11T19:21:46 <kanzure> s/we should not/we should not bundle
3572016-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)
3582016-08-11T19:22:13 <jtimon> no strong opinion about doing the low-s sf with segwit or later
3592016-08-11T19:22:16 *** Chris_Stewart_5 has quit IRC
3602016-08-11T19:22:35 <jtimon> but yeah, the sf itself seems uncontroversial
3612016-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
3622016-08-11T19:23:13 <GreenIsMyPepper> seems cleaner to have low-S from the start, no?
3632016-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)
3642016-08-11T19:24:34 <luke-jr> (separate in the BIP9 sense, not necessarily a different release)
3652016-08-11T19:24:53 <instagibbs> luke-jr, my assumption would be a different bit
3662016-08-11T19:24:54 <btcdrak> I think lowS softfork is a nobrainer, it's also easy and uncomplicated since it's already policy.
3672016-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
3682016-08-11T19:25:05 <jtimon> I mean, we can also deploy low-s in, say 0.12.2 before segwit (oh, wait, backport bip9)
3692016-08-11T19:25:24 <jtimon> if they go in the same release, why separate them in the bip9 sense?
3702016-08-11T19:25:29 <kanzure> luke-jr: that's at best an argument for your segwit bip9 activation decoupling idea.
3712016-08-11T19:25:39 <wumpus> I don't think we should deploy anything before segwit
3722016-08-11T19:25:50 <sipa> wumpus: agree
3732016-08-11T19:25:58 <jonasschnelli> agree
3742016-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
3752016-08-11T19:26:35 <luke-jr> kanzure: well, it's almost certainly too late for that (it definitely would add to testing required)
3762016-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
3772016-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
3782016-08-11T19:27:02 <sipa> ok
3792016-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
3802016-08-11T19:27:22 <luke-jr> GreenIsMyPepper: thanks
3812016-08-11T19:27:38 *** Ylbam has joined #bitcoin-core-dev
3822016-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
3832016-08-11T19:28:32 <instagibbs> also segwit could activate first, in some universe
3842016-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
3852016-08-11T19:29:26 <wumpus> next topic?
3862016-08-11T19:29:41 <wumpus> #topic raising mandatory script flags to include bip66
3872016-08-11T19:29:53 <btcdrak> I would prefer we combine lowS with segwit.
3882016-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
3892016-08-11T19:29:59 <sipa> so, we have 3 sets of flags currently
3902016-08-11T19:30:00 <luke-jr> what node versions does this result in cutting off from the network? pre-0.8, I think?
3912016-08-11T19:30:16 <sipa> 1) mandatory flags 2) consensus flags 3) standardness
3922016-08-11T19:30:26 <wumpus> luke-jr: no one is 'cut off' from the network?
3932016-08-11T19:30:39 <luke-jr> then I am misunderstanding
3942016-08-11T19:30:42 <jtimon> sipa: how are mandatory flags different from consensus flags?
3952016-08-11T19:30:50 <sipa> luke-jr is not misunderstanding
3962016-08-11T19:31:00 <wumpus> luke-jr: it's a softfork so 0.8 nodes should still be able to verify?
3972016-08-11T19:31:14 <sipa> wumpus: i'm explaining
3982016-08-11T19:31:27 <instagibbs> Mandatory script verification flags that all new blocks must comply with for
3992016-08-11T19:31:28 <instagibbs> * them to be valid. (but old blocks may not comply with) Currently just P2SH,
4002016-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
4012016-08-11T19:31:36 *** anchow101 has joined #bitcoin-core-dev
4022016-08-11T19:31:50 <sipa> and we would ban them if they send a BIP66-invalid transaction, for example
4032016-08-11T19:31:55 <instagibbs> "Failing one of these tests may trigger a DoS ban" I see
4042016-08-11T19:32:01 <sipa> so that's why BIP66 is not part of mandatory flags
4052016-08-11T19:32:18 <sipa> i just wanted to bring up the topic, not necessarily for anytime soon
4062016-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
4072016-08-11T19:32:28 <luke-jr> note we have a fork of 0.5.3 that is actively "maintained" and used
4082016-08-11T19:32:33 <jtimon> instagibbs: also bip66, bip65 and bip112, no?
4092016-08-11T19:32:34 <sipa> wumpus: it could partition the network, though
4102016-08-11T19:32:41 <luke-jr> s/we/someone else on the network/
4112016-08-11T19:32:55 <wumpus> sipa: ok, let's look at it from the other side then
4122016-08-11T19:32:57 <instagibbs> jtimon, oh, the comment is straight from master
4132016-08-11T19:33:00 <wumpus> sipa: what would be the advantage?
4142016-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
4152016-08-11T19:33:12 *** chris2000 has joined #bitcoin-core-dev
4162016-08-11T19:33:23 <jtimon> but all new blocks must comply with those too
4172016-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?
4182016-08-11T19:33:58 <sipa> wumpus: good point
4192016-08-11T19:34:22 <sipa> perhaps the policy should just be to never extend mandatory flags
4202016-08-11T19:34:24 *** achow101_ has quit IRC
4212016-08-11T19:34:31 <sipa> unless there is a DoS attack that needs it to be fixed
4222016-08-11T19:34:39 <wumpus> I remember a previous discussion about being less trigger happy regarding DoS banning
4232016-08-11T19:34:49 <wumpus> right, if there is DoS risk it is the appropriate measure
4242016-08-11T19:35:04 <sipa> i just noticed that this is something we've been ignoring the value of mandatory flags
4252016-08-11T19:35:20 <wumpus> yes, sure, it's confusing
4262016-08-11T19:35:25 <sipa> yes, indeed, i remember reducing dos banning flags
4272016-08-11T19:35:50 <wumpus> but adding a comment explaining this rationale would do just as well as extending the mandatory flags
4282016-08-11T19:36:08 <sipa> fair enough
4292016-08-11T19:36:45 <jtimon> sipa: I'm not sure I follow, why aren't SCRIPT_VERIFY_CHECKLOCKTIMEVERIFY and SCRIPT_VERIFY_CHECKSEQUENCEVERIFY in MANDATORY_SCRIPT_VERIFY_FLAGS ?
4302016-08-11T19:36:57 *** chris2000 has quit IRC
4312016-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
4322016-08-11T19:37:25 <wumpus> jtimon: for the same reason, probably, it would be harmful to DoS ban on them
4332016-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
4342016-08-11T19:37:55 <wumpus> (to not accidentally partition the network)
4352016-08-11T19:38:01 <jtimon> ok, so it's all about the DoS score
4362016-08-11T19:38:06 <wumpus> yes
4372016-08-11T19:38:23 <instagibbs> so why is it ok to ban a misbehaving p2sh transaction (probably veering off the path here)
4382016-08-11T19:38:26 *** fengling has joined #bitcoin-core-dev
4392016-08-11T19:38:44 <jtimon> why SCRIPT_VERIFY_P2SH is different from other softforks for this again?
4402016-08-11T19:38:48 <wumpus> validation overhead?
4412016-08-11T19:39:00 *** gmaxwell has joined #bitcoin-core-dev
4422016-08-11T19:39:06 <sipa> jtimon: it was very old at the time mandatory flags was introduced, so nobody cared, i guess
4432016-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.
4442016-08-11T19:39:43 <wumpus> well people run them on their own risk
4452016-08-11T19:40:04 <jtimon> wumpus: well they risk being banned, no?
4462016-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.
4472016-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
4482016-08-11T19:41:12 <sipa> i like the idea of reducing dos banning where possible
4492016-08-11T19:41:14 <wumpus> sure, but would be best to not DoS ban in the first place for non DoS offenses
4502016-08-11T19:41:45 <jtimon> sipa: for SCRIPT_VERIFY_P2SH too?
4512016-08-11T19:41:57 <luke-jr> gmaxwell: would blocks-only treatment break their wallet broadcasts, though?
4522016-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.
4532016-08-11T19:42:09 <wumpus> I don't think we should make the one-sided decision to make lower version nodes blocks-only
4542016-08-11T19:42:28 <gmaxwell> luke-jr: yes but nodes that old already have wallet broadcast problems because of high-S enforcement as standardness.
4552016-08-11T19:42:28 <wumpus> e.g. something may report a low network version but be perfectly able to handle new transactions
4562016-08-11T19:42:44 <wumpus> they're not really coupled the same way in other software than bitcoin core
4572016-08-11T19:42:50 <gmaxwell> probablity of their txn not relaying already is exponential in the number of signatures.
4582016-08-11T19:42:51 <luke-jr> gmaxwell: consider that there's a crowd who insist on using 0.5.3 :/
4592016-08-11T19:43:06 *** fengling has quit IRC
4602016-08-11T19:43:06 <wumpus> in any case I don't think this is a very urgent topic
4612016-08-11T19:43:08 <luke-jr> I guess they must have patched that
4622016-08-11T19:43:31 <jtimon> luke-jr: who insists in using 0.5.3 ?
4632016-08-11T19:43:48 <luke-jr> jtimon: therealbitcoin.org people
4642016-08-11T19:43:52 *** harrymm has joined #bitcoin-core-dev
4652016-08-11T19:43:58 <gmaxwell> luke-jr: they have to apply a small pile of fixes in any case.
4662016-08-11T19:44:25 <gmaxwell> presumably they're fixed to produce high-S signatures (or not transacting at all... :P )
4672016-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
4682016-08-11T19:45:27 <wumpus> they probably write raw transactions in their head instead of using the bitcoin core wallet
4692016-08-11T19:45:30 <jtimon> I guess I can ask after the meeting, but why don't they want to upgrade?
4702016-08-11T19:45:51 <sipa> jtimon: yes, let's discuss that after the meeting
4712016-08-11T19:45:58 <luke-jr> ^+1
4722016-08-11T19:46:02 <jtimon> sipa: sure, np
4732016-08-11T19:46:07 <sipa> i think this is getting too abstract
4742016-08-11T19:46:21 <sipa> i just wanted to raise attention to the neglected mandatory flags :)
4752016-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
4762016-08-11T19:46:33 <wumpus> yes, next topic?
4772016-08-11T19:46:39 <btcdrak> I dont see any 0.5.3 useragents
4782016-08-11T19:46:58 <sipa> wumpus: you had rc3 as topic?
4792016-08-11T19:47:04 <wumpus> #topic rc3 go-ahead
4802016-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
4812016-08-11T19:47:32 <wumpus> yes, quick question, anything that still needs to be merged/backported for 0.13.0 apart from release notes?
4822016-08-11T19:48:09 <wumpus> not seeing anything here https://github.com/bitcoin/bitcoin/milestone/20
4832016-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
4842016-08-11T19:48:28 <wumpus> so I'm going to tag rc3 in a very short while, after the usual translation updates and such
4852016-08-11T19:48:49 <luke-jr> btcdrak: 1) those are just listening nodes, 2) 7 nodes show as 99999 "/therealbitcoin.org:0.9.99.99/"
4862016-08-11T19:49:23 <wumpus> yes they don't report as 0.5.3
4872016-08-11T19:49:40 <jtimon> sipa: so should we get SCRIPT_VERIFY_P2SH out of mandatory too?
4882016-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.
4892016-08-11T19:50:01 <sipa> jtimon: out of topic :)
4902016-08-11T19:50:15 <jtimon> sipa: ok, later too, whatever
4912016-08-11T19:50:26 <wumpus> btcdrak: it's not a concern
4922016-08-11T19:50:29 <btcdrak> wumpus: rc3 looks good to go.
4932016-08-11T19:50:59 <wumpus> foss gives that freedom to run your own stack of weird hacks if you want for whatever reason
4942016-08-11T19:51:15 <wumpus> btcdrak: ok!
4952016-08-11T19:51:37 <sipa> ack rc3
4962016-08-11T19:51:42 *** anchow101 has quit IRC
4972016-08-11T19:51:44 <jonasschnelli> ready to build
4982016-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?
4992016-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
5002016-08-11T19:52:03 *** anchow101 has joined #bitcoin-core-dev
5012016-08-11T19:52:38 <sipa> cfields: fine be me
5022016-08-11T19:53:18 <sipa> btcdrak: great
5032016-08-11T19:53:27 *** anchow101 has quit IRC
5042016-08-11T19:53:30 <wumpus> cfields: eh, so that means holding up rc3?
5052016-08-11T19:53:32 <cfields> wumpus: opinion ^^? Not critical, we have testnet.
5062016-08-11T19:53:55 <wumpus> if it's not critical I'd say not do it, at this point
5072016-08-11T19:54:03 <sipa> cfields: 0.13.0 has no activation, so it would not produce a default_witness_commitment?
5082016-08-11T19:54:10 <wumpus> unless you want to be that person holding up the release :)
5092016-08-11T19:54:13 <sipa> i think there is no need for that in 0.13.0
5102016-08-11T19:54:22 <luke-jr> sipa: the subject was commitments pre-activation
5112016-08-11T19:54:40 <sipa> i'm confused about that
5122016-08-11T19:55:01 <wumpus> #link review blog post https://github.com/bitcoin-core/bitcoincore.org/pull/199
5132016-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)
5142016-08-11T19:55:35 <gmaxwell> ^ thats my expectation
5152016-08-11T19:55:38 <sipa> there is no problem if people choose to diverge from that
5162016-08-11T19:56:08 <wumpus> cfields: to be honest I'm not sure what the advantage or disadvantage of that is
5172016-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.
5182016-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
5192016-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.
5202016-08-11T19:57:44 <sipa> cfields: 0.13.0 for all intents and purposes behaves identical to older nodes wrt segwit behaviour
5212016-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
5222016-08-11T19:58:05 <cfields> sipa: understood
5232016-08-11T19:58:44 <sipa> so, ack rc3?
5242016-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.
5252016-08-11T19:58:55 <gmaxwell> rc3 sounds good to me.
5262016-08-11T19:59:19 <cfields> works for me
5272016-08-11T19:59:41 <jtimon> yay 0.13.0!
5282016-08-11T19:59:54 <gmaxwell> jtimon: careful, you're going to trigger some confused reddit posts.
5292016-08-11T20:00:12 <wumpus> roughly one minute to go
5302016-08-11T20:00:20 <jtimon> oops, sorry, yay ack rc3
5312016-08-11T20:00:24 <gmaxwell> I think someone's clock is off.
5322016-08-11T20:00:31 <gmaxwell> Time to die.
5332016-08-11T20:00:37 <wumpus> jtimon: yes, let's not get ahead of ourselves
5342016-08-11T20:00:39 <wumpus> #endmeeting
5352016-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)
5362016-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
5372016-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
5382016-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
5392016-08-11T20:00:40 <sipa> #killtime
5402016-08-11T20:00:49 <gmaxwell> and it ended on time. hurrah.
5412016-08-11T20:00:52 * gmaxwell bbl
5422016-08-11T20:01:03 * btcdrak flies off
5432016-08-11T20:01:05 <wumpus> no, clock is not off, the server is just travelling at relativistic speeds...
5442016-08-11T20:01:22 <jtimon> sipa: so should we get SCRIPT_VERIFY_P2SH out of mandatory too?
5452016-08-11T20:02:13 <wumpus> or completely drop mandatory?
5462016-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)
5472016-08-11T20:02:50 <jtimon> wumpus: well, at that point mandatory would be only SCRIPT_VERIFY_NONE so it's kind of the same
5482016-08-11T20:03:18 <murch> luke-jr: Are they the people around Mircea Popescu?
5492016-08-11T20:03:23 <luke-jr> murch: right
5502016-08-11T20:03:24 <sipa> murch: yes
5512016-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
5522016-08-11T20:03:28 <wumpus> jtimon: so after that the logic can be removed, cleanups, yay
5532016-08-11T20:03:43 <instagibbs> pigeons, how do they feel about base32...
5542016-08-11T20:03:50 <murch> well, in that case⦠Why bother putting in the extra work of maintaining special cases for them?
5552016-08-11T20:03:59 <wumpus> murch: we don't
5562016-08-11T20:03:59 <jtimon> this reminds me of https://github.com/jtimon/bitcoin/commit/6314ef0aeb288eb01b9250c0b83e9e4b46c17259 btw
5572016-08-11T20:04:01 <sipa> murch: we shouldn't
5582016-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
5592016-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
5602016-08-11T20:04:40 <pigeons> lol instagibbs i don't know you can ask in #trilema if yu want entertinment
5612016-08-11T20:04:50 <instagibbs> pigeons, i like not being DoS'd thank you
5622016-08-11T20:04:53 * instagibbs back on topic
5632016-08-11T20:04:55 <luke-jr> lol
5642016-08-11T20:05:00 <jtimon> wumpus: sounds good to me
5652016-08-11T20:05:05 <wumpus> cfields: what approach do you consider switching to?
5662016-08-11T20:05:13 * sipa afk
5672016-08-11T20:05:29 <jtimon> luke-jr: I see, thanks
5682016-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
5692016-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...
5702016-08-11T20:05:50 <cfields> wumpus: then a few more little things like that. It keeps growing and growing...
5712016-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)
5722016-08-11T20:06:09 <wumpus> cfields: what do we use thread local for?
5732016-08-11T20:06:22 <jtimon> but sipa didn't answer if that would be ok with him
5742016-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
5752016-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
5762016-08-11T20:07:03 <wumpus> cfields: so the interruptions require the spottily-supported functionality?
5772016-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.
5782016-08-11T20:07:06 <cfields> wumpus: it's necessary for this::thread stuff. So, this_thread::interrupt, this_thread::sleep (interruptible), etc
5792016-08-11T20:07:32 <cfields> er, this_thread::interruption_point
5802016-08-11T20:07:49 <murch> luke-jr: Thanks for clarifying
5812016-08-11T20:08:02 <luke-jr> murch: realistic daily spending values seem to be anything from 0.01 to 1 BTC. :p
5822016-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
5832016-08-11T20:08:12 <wumpus> cfields: right
5842016-08-11T20:08:27 <wumpus> cfields: it's easy enough to switch interruption points to just a flag
5852016-08-11T20:08:36 <cfields> wumpus: sorry, i was unclear. thread_local or thread_specific_ptr are necessary for implementing the interruptible threads
5862016-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
5872016-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.
5882016-08-11T20:09:03 <wumpus> cfields: e.g. we stuff everything into one thread group
5892016-08-11T20:09:10 <cfields> wumpus: right, now that we have atomics, we can just throw those checks around instead
5902016-08-11T20:09:50 <wumpus> right
5912016-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.
5922016-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
5932016-08-11T20:10:42 *** eratkat has joined #bitcoin-core-dev
5942016-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
5952016-08-11T20:12:42 <wumpus> if we can do without thread local data, let's do that
5962016-08-11T20:12:42 <cfields> wumpus: ok thanks, i'll give that approach a shot
5972016-08-11T20:13:27 <wumpus> I do like how httpserver was switched to c++11 threads without any issues
5982016-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
5992016-08-11T20:13:31 <wumpus> good work
6002016-08-11T20:14:54 <cfields> thanks. ok, I'll start pr'ing those changes then.
6012016-08-11T20:14:56 *** Chris_Stewart_5 has joined #bitcoin-core-dev
6022016-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
6032016-08-11T20:15:11 <cfields> shame to throw away all of that wrapper code, but it was a good learning experience :)
6042016-08-11T20:15:28 <luke-jr> cfields: well, hopefully Apple will get TLS by 0.14? :P
6052016-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
6062016-08-11T20:16:41 <luke-jr> yeah, so just save it until post-0.13 rather than throw away?
6072016-08-11T20:16:44 <wumpus> cfields: yes it's a pity, but I don't think we could have forseen this
6082016-08-11T20:16:45 <cfields> but based on that, i'm assuming they're probably not the only ones
6092016-08-11T20:16:59 <wumpus> cfields: though I think the wrapper was always meant to be temporary?
6102016-08-11T20:17:25 <wumpus> just a self-contained step in moving away from boost
6112016-08-11T20:17:41 <cfields> wumpus: right
6122016-08-11T20:21:54 <wumpus> luke-jr: correction: until 0.14 is out of the door :)
6132016-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)
6142016-08-11T20:24:10 <wumpus> many open source projects are switching to requiring c++11
6152016-08-11T20:24:40 <luke-jr> yes, I'm not arguing against it.
6162016-08-11T20:25:04 *** MarcoFalke has quit IRC
6172016-08-11T20:28:26 *** yep has quit IRC
6182016-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?
6192016-08-11T20:39:29 *** fengling has joined #bitcoin-core-dev
6202016-08-11T20:40:03 <btcdrak> jtimon: sorry I am way behind this week.
6212016-08-11T20:40:31 <jtimon> no worries, I don't need an urgent answer
6222016-08-11T20:40:55 <btcdrak> please dont close the PRs.
6232016-08-11T20:41:00 <jtimon> ok
6242016-08-11T20:41:26 <jtimon> that means rebase I guess
6252016-08-11T20:43:06 <jtimon> thanks
6262016-08-11T20:44:06 *** fengling has quit IRC
6272016-08-11T20:45:12 *** spudowiar has quit IRC
6282016-08-11T21:01:16 *** molz has joined #bitcoin-core-dev
6292016-08-11T21:02:28 <luke-jr> wumpus: https://github.com/bitcoin/bitcoin/issues/8500 :|
6302016-08-11T21:03:00 * luke-jr wonders how compact block code reacts to such thinblock nodes
6312016-08-11T21:03:28 <wumpus> gah
6322016-08-11T21:03:37 *** moli has quit IRC
6332016-08-11T21:03:58 <murch> lol
6342016-08-11T21:04:30 <murch> it's kinda funny that nobody saw that until now. ^^
6352016-08-11T21:05:49 <Lightsword> are enough people using thinblocks for it to even matter?
6362016-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
6372016-08-11T21:06:40 <Lightsword> I mean, compact blocks is already in useâ¦
6382016-08-11T21:06:53 <murch> Lightsword: 500 Classic nodes or so
6392016-08-11T21:07:20 <Lightsword> murch, whatâs first classic version that had thinblocks?
6402016-08-11T21:07:27 <murch> Lightsword: and roughly 90 BU and XT perhaps
6412016-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
6422016-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
6432016-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)
6442016-08-11T21:08:27 <luke-jr> but it'd be nice to let people implement both
6452016-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.
6462016-08-11T21:09:07 <luke-jr> yes, this is a failure of thin blocks to use the BIP process :/
6472016-08-11T21:09:31 <wumpus> changing that enumeration would mean changing the BIP too
6482016-08-11T21:09:34 <wumpus> indeed
6492016-08-11T21:09:40 <Lightsword> yeahâ¦I think core node count with compact block support is roughly the same
6502016-08-11T21:09:42 <Lightsword> the most common classic node is one that doesnât seem to support it anyways
6512016-08-11T21:09:42 *** thaumaturge has joined #bitcoin-core-dev
6522016-08-11T21:09:45 <luke-jr> even their own BUIP doesn't seem to mention this
6532016-08-11T21:09:50 <Lightsword> I donât think people actually use classic in any meaningful sense
6542016-08-11T21:11:37 <wumpus> yes, clearly a process failure
6552016-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.
6562016-08-11T21:12:13 <wumpus> if you grab a number in the protocol you should publish a BIP
6572016-08-11T21:12:25 <Lightsword> murch, Iâm not sure I care
6582016-08-11T21:12:39 <achow101> so it comes down to who defined that enum first
6592016-08-11T21:12:41 <wumpus> otherwise how are people supposed to know?
6602016-08-11T21:13:11 <sipa> wumpus: they published a buip, i think :)
6612016-08-11T21:13:16 *** Chris_Stewart_5 has quit IRC
6622016-08-11T21:13:17 <wumpus> it's clearly too late now anyhow
6632016-08-11T21:13:24 <wumpus> sipa: well that doesn't do it
6642016-08-11T21:13:31 <Lightsword> wait, is it conflicting with MSG_THINBLOCK or MSG_XTHINBLOCK?
6652016-08-11T21:13:59 <achow101> MSG_THINBLOCK
6662016-08-11T21:14:14 <sipa> ah
6672016-08-11T21:14:15 <wumpus> if we're no longer going to follow the BIP process, could as well abandon it
6682016-08-11T21:14:36 <Lightsword> so it doesnât conflict with XT at least since âBUIP010 thin block. We don't support these.â
6692016-08-11T21:14:43 <Lightsword> for MSG_THINBLOCK
6702016-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
6712016-08-11T21:16:16 <wumpus> TD-Linux: link?
6722016-08-11T21:16:31 <TD-Linux> one sec
6732016-08-11T21:16:38 <luke-jr> sipa: a BUIP that doesn't mention either the inv enum nor the service bit.. :/
6742016-08-11T21:16:53 <wumpus> it should mention the enum value (4)
6752016-08-11T21:16:59 *** thaumaturge has quit IRC
6762016-08-11T21:17:24 <TD-Linux> wumpus, https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-March/012526.html
6772016-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.
6782016-08-11T21:17:31 <luke-jr> TD-Linux: this doesn't mention the enum
6792016-08-11T21:17:35 <TD-Linux> yes it does
6802016-08-11T21:17:49 <wumpus> that's about the services bit
6812016-08-11T21:18:02 <TD-Linux> oh okay I see.
6822016-08-11T21:18:06 <Lightsword> murch, that issue states the issue isnât with xthin enum but normal thin enum
6832016-08-11T21:18:10 <wumpus> not MSG_THINBLOCK inv type
6842016-08-11T21:19:40 <GitHub73> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/9058617afb24594f09848d2a53403760bd64470a
6852016-08-11T21:19:40 <GitHub73> bitcoin/0.13 9058617 Wladimir J. van der Laan: qt: translations update pre-rc3
6862016-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
6872016-08-11T21:20:29 <achow101> It isn't in any documentation though
6882016-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
6892016-08-11T21:21:39 <sipa> ah, right, if you want to set both service bits...
6902016-08-11T21:21:49 <luke-jr> yeah âº
6912016-08-11T21:28:26 <GitHub177> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/b52c67c4b188c274de60fbd5e26441e9a644dba6
6922016-08-11T21:28:26 <GitHub177> bitcoin/0.13 b52c67c Wladimir J. van der Laan: doc: Update changelog for rc3
6932016-08-11T21:29:16 *** Chris_Stewart_5 has joined #bitcoin-core-dev
6942016-08-11T21:31:11 <wumpus> * [new tag] v0.13.0rc3 -> v0.13.0rc3
6952016-08-11T21:31:25 <achow101> woo building time
6962016-08-11T21:32:10 * sipa fires up the gitian
6972016-08-11T21:37:12 *** laurentmt has joined #bitcoin-core-dev
6982016-08-11T21:37:36 *** laurentmt has quit IRC
6992016-08-11T21:40:25 *** fengling has joined #bitcoin-core-dev
7002016-08-11T21:45:26 *** fengling has quit IRC
7012016-08-11T21:46:13 *** cryptapus is now known as cryptapus_afk
7022016-08-11T21:48:05 <cfields> https://github.com/theuni/ckpool/commits/segwit-rebased
7032016-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
7042016-08-11T21:48:29 <cfields> luke-jr: ^^
7052016-08-11T21:49:19 <cfields> oh
7062016-08-11T21:49:24 * cfields fires up gitian too
7072016-08-11T21:49:51 <luke-jr> cfields: trade? :P (I should probably merge tests into libblkmaker segwit first though)
7082016-08-11T21:50:41 <luke-jr> actually, tests could use review independently: https://github.com/bitcoin/libblkmaker/pull/7
7092016-08-11T21:50:49 <cfields> luke-jr: trade for libblkmaker review?
7102016-08-11T21:50:54 <luke-jr> right
7112016-08-11T21:50:54 <cfields> sure
7122016-08-11T21:55:55 <cfields> luke-jr: looking now.
7132016-08-11T21:58:49 *** To7 has joined #bitcoin-core-dev
7142016-08-11T22:02:15 * michagogo runs his all-in-one gitian script
7152016-08-11T22:29:02 *** d_t has quit IRC
7162016-08-11T22:33:26 *** anchow101 has joined #bitcoin-core-dev
7172016-08-11T22:33:29 *** anchow101 has quit IRC
7182016-08-11T22:35:00 *** spudowiar has joined #bitcoin-core-dev
7192016-08-11T22:36:46 <luke-jr> cfields: ok, I think the rest looks good
7202016-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)
7212016-08-11T22:38:27 <luke-jr> cfields: eh, the commitment insertion stuff isn't in that PR <.<
7222016-08-11T22:39:01 <cfields> luke-jr: eh? I'm not looking at the tests, I'm looking at #6
7232016-08-11T22:39:22 <luke-jr> ok I guess
7242016-08-11T22:39:37 <luke-jr> IMO the tests should go first though XD
7252016-08-11T22:39:39 <cfields> need to be familiar with what it's testing first :)
7262016-08-11T22:42:07 *** fengling has joined #bitcoin-core-dev
7272016-08-11T22:42:52 *** murch has quit IRC
7282016-08-11T22:46:26 *** fengling has quit IRC
7292016-08-11T23:14:40 *** Guyver2 has quit IRC
7302016-08-11T23:21:26 *** droark has quit IRC
7312016-08-11T23:25:31 *** Giszmo has quit IRC
7322016-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.
7332016-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)
7342016-08-11T23:41:25 <luke-jr> oh, maybe I pushed those before you looked XD
7352016-08-11T23:41:39 <michagogo> cfields: my sigs are up
7362016-08-11T23:43:28 *** fengling has joined #bitcoin-core-dev
7372016-08-11T23:48:26 *** fengling has quit IRC