12018-04-12T00:00:03 *** weez17 has quit IRC
22018-04-12T00:00:47 *** AaronvanW has joined #bitcoin-core-dev
32018-04-12T00:00:49 *** weez17 has joined #bitcoin-core-dev
42018-04-12T00:01:14 *** Victorsueca has quit IRC
52018-04-12T00:01:16 *** meshcollider has joined #bitcoin-core-dev
62018-04-12T00:01:17 <fanquake> dongcarl I think measuring towards the end of every release cycle would be a good start. Likely to be funded out of the pockets of whoever is running the tests. Unless someone donates some servers.
72018-04-12T00:02:22 *** Victorsueca has joined #bitcoin-core-dev
82018-04-12T00:02:55 *** shesek has joined #bitcoin-core-dev
92018-04-12T00:02:55 *** shesek has joined #bitcoin-core-dev
102018-04-12T00:04:47 *** dafunkiz_ has joined #bitcoin-core-dev
112018-04-12T00:05:55 *** moneyball has joined #bitcoin-core-dev
122018-04-12T00:23:08 <bitcoin-git> [bitcoin] MarcoFalke opened pull request #12956: contrib: Only lint our src files for include guards (master...Mf1804-lintFixups) https://github.com/bitcoin/bitcoin/pull/12956
132018-04-12T00:25:01 *** dafunkiz_ has quit IRC
142018-04-12T00:30:17 *** moneyball has quit IRC
152018-04-12T00:31:59 *** AaronvanW has quit IRC
162018-04-12T00:32:56 *** rls has joined #bitcoin-core-dev
172018-04-12T00:35:41 <bitcoin-git> [bitcoin] sparpana opened pull request #12957: Update README.md (master...master) https://github.com/bitcoin/bitcoin/pull/12957
182018-04-12T00:36:20 <bitcoin-git> [bitcoin] fanquake closed pull request #12957: Update README.md (master...master) https://github.com/bitcoin/bitcoin/pull/12957
192018-04-12T00:42:31 *** isis_ is now known as isis
202018-04-12T00:43:02 *** dafuq_ has joined #bitcoin-core-dev
212018-04-12T00:46:14 *** ken2812221 has quit IRC
222018-04-12T00:46:21 *** murrayn has quit IRC
232018-04-12T00:47:17 *** ken2812221 has joined #bitcoin-core-dev
242018-04-12T00:50:08 * dongcarl nods
252018-04-12T00:50:08 *** Krellan has quit IRC
262018-04-12T00:50:49 *** Krellan has joined #bitcoin-core-dev
272018-04-12T00:51:18 <bitcoin-git> [bitcoin] Empact opened pull request #12959: Drop IsCompressedOrUncompressedPubKey and IsCompressedPubKey (master...is-compressed-or-uncompressed) https://github.com/bitcoin/bitcoin/pull/12959
282018-04-12T00:56:19 *** dafunkiz_ has joined #bitcoin-core-dev
292018-04-12T01:01:06 *** dafunkiz_ has quit IRC
302018-04-12T01:04:23 *** rls0 has joined #bitcoin-core-dev
312018-04-12T01:07:49 *** rls has quit IRC
322018-04-12T01:08:57 *** Randolf has quit IRC
332018-04-12T01:24:23 *** AaronvanW has joined #bitcoin-core-dev
342018-04-12T01:25:48 *** dafunkiz_ has joined #bitcoin-core-dev
352018-04-12T01:30:49 *** Samdney has quit IRC
362018-04-12T01:32:50 <bitcoin-git> [bitcoin] MarcoFalke opened pull request #12960: doc: Revert to previous header include policy (master...Mf1804-docIncludes) https://github.com/bitcoin/bitcoin/pull/12960
372018-04-12T01:40:26 *** tryphe_ is now known as tryphe
382018-04-12T01:42:06 <bitcoin-git> [bitcoin] MarcoFalke closed pull request #12956: contrib: Only lint our src files for include guards (master...Mf1804-lintFixups) https://github.com/bitcoin/bitcoin/pull/12956
392018-04-12T01:46:05 *** moneyball has joined #bitcoin-core-dev
402018-04-12T01:49:37 *** tiboclan has joined #bitcoin-core-dev
412018-04-12T01:52:24 *** tiboclan has quit IRC
422018-04-12T01:52:49 *** dafuq_ has quit IRC
432018-04-12T01:54:30 *** zautomata1 has joined #bitcoin-core-dev
442018-04-12T01:56:09 *** zautomata has quit IRC
452018-04-12T01:57:59 <bitcoin-git> [bitcoin] fanquake closed pull request #12433: [qt] move SendCoinsRecipient to its own file (master...2018/02/qt-send-coins-recipient) https://github.com/bitcoin/bitcoin/pull/12433
462018-04-12T02:01:39 *** moneyball has quit IRC
472018-04-12T02:01:44 *** zigen has joined #bitcoin-core-dev
482018-04-12T02:02:17 *** Randolf has joined #bitcoin-core-dev
492018-04-12T02:08:38 *** murrayn has joined #bitcoin-core-dev
502018-04-12T02:10:24 *** moneyball has joined #bitcoin-core-dev
512018-04-12T02:21:02 *** meshcollider has quit IRC
522018-04-12T02:21:48 *** moneyball has quit IRC
532018-04-12T02:22:26 *** moneyball has joined #bitcoin-core-dev
542018-04-12T02:25:04 *** zigen has quit IRC
552018-04-12T02:25:37 *** zigen has joined #bitcoin-core-dev
562018-04-12T02:27:17 *** zigen has quit IRC
572018-04-12T02:27:29 *** zigen has joined #bitcoin-core-dev
582018-04-12T02:30:18 <fanquake> Is there an easy way to comment on an issue like #12961 inline?
592018-04-12T02:30:19 <gribble> https://github.com/bitcoin/bitcoin/issues/12961 | 979f598: Clang Static Analyzer Report · Issue #12961 · bitcoin/bitcoin · GitHub
602018-04-12T02:32:06 *** dafunkiz_ has quit IRC
612018-04-12T02:32:23 *** Victorsueca has quit IRC
622018-04-12T02:32:35 <aj> fanquake: don't think so. you can copy a bit and quote it with a ">" prefix, eg "> what they said \n\n helpful response from you" ?
632018-04-12T02:32:54 <kallewoof> fanquake: Maybe I should've made a PR with 'no-merge:'. That would let you inline comment.
642018-04-12T02:33:17 <kallewoof> No/limited formatting though..
652018-04-12T02:33:23 <fanquake> Yes that's normally what I'd do, but copying out of an issue like that which has heaps of markdown is always a bit of a nightmare.
662018-04-12T02:33:38 *** Victorsueca has joined #bitcoin-core-dev
672018-04-12T02:33:44 <fanquake> kallewoof, I'll have a go at adding some comments to the issue first.
682018-04-12T02:33:53 <kallewoof> OK
692018-04-12T02:53:48 *** moneyball has quit IRC
702018-04-12T02:55:03 *** moneyball has joined #bitcoin-core-dev
712018-04-12T02:55:59 *** Giszmo has quit IRC
722018-04-12T02:56:54 *** AaronvanW has quit IRC
732018-04-12T03:01:21 *** moneyball has quit IRC
742018-04-12T03:09:23 *** boblee has quit IRC
752018-04-12T03:09:31 *** boblee has joined #bitcoin-core-dev
762018-04-12T03:10:00 *** cryptojanitor has joined #bitcoin-core-dev
772018-04-12T03:10:04 *** moneyball has joined #bitcoin-core-dev
782018-04-12T03:13:41 *** dafunkiz_ has joined #bitcoin-core-dev
792018-04-12T03:16:24 *** Krellan has quit IRC
802018-04-12T03:17:11 *** Krellan has joined #bitcoin-core-dev
812018-04-12T03:18:29 <mryandao> ok, i've rebased #12240 and it finally passed all the build jobs
822018-04-12T03:18:31 <gribble> https://github.com/bitcoin/bitcoin/issues/12240 | [rpc] Introduced a new `fees` structure that aggregates all sub-field fee types denominated in BTC by mryandao · Pull Request #12240 · bitcoin/bitcoin · GitHub
832018-04-12T03:27:25 *** fanquake has quit IRC
842018-04-12T03:29:57 *** dafunkiz_ has quit IRC
852018-04-12T03:35:57 <wumpus> dongcarl: funding is hardly ever the issue
862018-04-12T03:37:51 <mryandao> while most open source project struggle with funding, bitcoin-core has a funny situation where there simply enough human resources to spend funding? :/
872018-04-12T03:37:54 <wumpus> if you have a good plan for that, but the problem is servers to run it on, I'm sure something can be agreed on
882018-04-12T03:38:09 <wumpus> yes the problem is people
892018-04-12T03:46:04 <kallewoof> Does anyone have any objections to extending the WIF format with types, so that wallet software can know what kind of key it corresponds to (P2WPKH, P2WPKH-P2SH, etc)? BIP proposal here: https://github.com/kallewoof/bips/blob/bip-typed-wif/bip-extended-privkey.mediawiki
902018-04-12T03:46:28 <wumpus> kallewoof: sounds like a good idea to me
912018-04-12T03:47:31 <kallewoof> luke-jr: Would you mind assigning a BIP number? I've had this on the ML for awhile, and no one replied (= no one objected).
922018-04-12T03:51:28 <wumpus> kallewoof:I think non-compressed should not be suffix 0, but simply 'no suffix byte', that's better for backward compatibility
932018-04-12T03:51:48 <wumpus> (you mention that yourself in Compatibility so :-)
942018-04-12T03:52:44 <wumpus> looks good to me otherwise
952018-04-12T03:54:48 <kallewoof> wumpus: Hm. I thought 0x00 was the same as 'no suffix byte', compatibility wise...
962018-04-12T03:55:04 <wumpus> kallewoof: a lot of implementations just check the length
972018-04-12T03:55:05 <kallewoof> wumpus: I mean, 0x00 is the same as 'no suffix' which means uncompressed.
982018-04-12T03:55:09 <kallewoof> wumpus: Geh. Okay.
992018-04-12T03:56:42 <wumpus> well I don't know about 'a lot' but I've seen it done, and I don't think there's a good reason to introduce a new encoding for P2PKH_UNCOMPRESSED - the current one is unambigious!
1002018-04-12T03:57:15 <kallewoof> wumpus: Yeah, makes sense. So either have no suffix byte (=P2PKH_UNCOMPRESSED), or have one that is non-zero
1012018-04-12T03:57:16 <luke-jr> well, then it suddenly becomes a bug to interpret it as compressed/etc
1022018-04-12T03:57:21 <luke-jr> kallewoof: is there a PR?
1032018-04-12T03:57:39 <wumpus> "all types with a suffix byte are compressed"
1042018-04-12T03:57:58 <kallewoof> luke-jr: There's a branch, no PR yet. Can make one easily enough.
1052018-04-12T03:58:10 <kallewoof> luke-jr: Will fix wumpus feedback and then make PR
1062018-04-12T03:58:12 <luke-jr> kallewoof: PR for the BIP I mean
1072018-04-12T03:58:18 <kallewoof> luke-jr: Yes
1082018-04-12T03:58:29 <luke-jr> that goes before # assignment these days
1092018-04-12T04:01:05 <kallewoof> luke-jr: https://github.com/bitcoin/bips/pull/673
1102018-04-12T04:01:38 <kallewoof> wumpus: I did a first draft on switching to uncompressed = no suffix.
1112018-04-12T04:02:58 *** zautomata2 has joined #bitcoin-core-dev
1122018-04-12T04:03:02 <luke-jr> kallewoof: I suggest making type 0 always p2pk or p2pkh
1132018-04-12T04:03:33 <luke-jr> "Legacy public key format" should be "p2pkh"
1142018-04-12T04:04:27 <kallewoof> luke-jr: Isn't type 0 ambiguous with 'not compressed'? Or is 'not compressed' *always* a missing suffix byte?
1152018-04-12T04:05:05 *** jarthur has joined #bitcoin-core-dev
1162018-04-12T04:05:10 *** zautomata1 has quit IRC
1172018-04-12T04:05:12 <kallewoof> luke-jr: I forgot about P2PK though...
1182018-04-12T04:05:21 <luke-jr> might want to ask thomasv to co-author the BIP
1192018-04-12T04:05:33 <kallewoof> Yeah, good idea
1202018-04-12T04:06:08 <wumpus> yes, the important part is that other wallet authors agree
1212018-04-12T04:06:31 <wumpus> if they're not on one page, it's not much of a standard :)
1222018-04-12T04:08:04 <kallewoof> Yeah, I was sort of assuming they'd be on the ML and object if they found it offensive, but asking directly is definitely a good idea
1232018-04-12T04:09:04 <wumpus> that would be the ideal situation, but in practice most people are probably very busy and don't pay much attention to the mailing list day to day - a common practice would be to CC: people that should absolutely see it
1242018-04-12T04:10:10 <kallewoof> wumpus: I don't really know who to CC though, aside from thomasv, who is already in the thread. In fact, he's the author of it.
1252018-04-12T04:10:20 <wumpus> ok
1262018-04-12T04:10:38 <wumpus> (me neither, just have the same experience with ignored messages on MLs :-)
1272018-04-12T04:14:29 <wumpus> in open source projects you shouldn't be afraid to poke people, if necessarily repeatedly (after some time passed)
1282018-04-12T04:15:24 <kallewoof> wumpus: Haha, yeah I'm trying to get used to that idea.
1292018-04-12T04:20:05 *** zigen has quit IRC
1302018-04-12T04:20:37 *** zigen has joined #bitcoin-core-dev
1312018-04-12T04:23:21 <wumpus> kallewoof: uh oh, looking at python-bitcoinlib's WIF decoder: https://github.com/petertodd/python-bitcoinlib/blob/master/bitcoin/wallet.py#L253 they treat only keys with suffix byte AND suffix byte=1 as compressed and the rest as uncompressed
1322018-04-12T04:24:13 <kallewoof> wumpus: Wow... okay. Wonder why they chose that approach.
1332018-04-12T04:24:24 <wumpus> accidentally, I think
1342018-04-12T04:25:14 *** zigen has quit IRC
1352018-04-12T04:25:27 <wumpus> we can fix that at the same time as implementing your BIP - just a data point
1362018-04-12T04:26:17 <wumpus> though at some point it would be safer to create a completely new WIF format
1372018-04-12T04:26:45 <wumpus> especially if we find more examples of handling the suffix byte differently
1382018-04-12T04:26:47 <kallewoof> wumpus: I'm gonna look around at other implementations and see how they're doing it.
1392018-04-12T04:26:51 <kallewoof> wumpus: Yeah.
1402018-04-12T04:26:52 <wumpus> yes, good idea
1412018-04-12T04:32:05 <luke-jr> Could Bech32 it
1422018-04-12T04:32:50 <wumpus> luke-jr: I had that in my mind as well
1432018-04-12T04:34:31 <kallewoof> Yeah, that would be nice. I know sipa has talked about it in the past.
1442018-04-12T04:35:13 <kallewoof> btcd seems to do the "right" thing (ignoring the suffix byte, actually.. I think.. so they should be 100% compatible): https://github.com/btcsuite/btcutil/blob/501929d3d046174c3d39f0ea54ece471aa17238c/wif.go#L90-L102
1452018-04-12T04:35:41 <kallewoof> Oh wait, nevermind. They do check that it's 0x01 for compressed.
1462018-04-12T04:35:56 <luke-jr> a Bech32 format would be a clean break of compatibility
1472018-04-12T04:36:57 <wumpus> I've downgraded my ACK to Concept ACK for now
1482018-04-12T04:37:08 <kallewoof> luke-jr: I was hoping we could get a fix in for WIF soonish, as I don't believe sipa is done with the params for the private key bech32 variant.
1492018-04-12T04:37:46 <kallewoof> wumpus: I'll note the bech32 alternative on the BIP
1502018-04-12T04:38:10 <wumpus> I'm a bit afraid that this might result in funds loss in some edge cases
1512018-04-12T04:38:40 <wumpus> e.g. importing one of the new key types into an old wallet, there's no error, but as it is interpreted wrongly, nothing happens either
1522018-04-12T04:38:59 <kallewoof> That would be a display error, not a fund loss
1532018-04-12T04:39:08 <luke-jr> ^
1542018-04-12T04:39:23 <luke-jr> even if the user throws away the WIF, you could still export the key and fix it later
1552018-04-12T04:39:36 <wumpus> ok
1562018-04-12T04:40:08 <luke-jr> kallewoof: what's the need for an interim format? WIF is fine..
1572018-04-12T04:41:36 <kallewoof> luke-jr: It's fine, except you need to import every possible type of public key as you don't know what kind it is. See https://github.com/bitcoin/bitcoin/pull/12705#issuecomment-373973741
1582018-04-12T04:41:45 *** wolfspraul has quit IRC
1592018-04-12T04:42:15 <kallewoof> sipa said: "Relatedly, we don't have an encoding for "private key whose address is supposed to be P2SH-P2WPKH". My suggestion would be to add one (I believe Electrum has some sort of standard for this). importprivkey can't really use these, because it already has to assume it can be any type, but importmulti does not need to repeat this. It could assume just P2PKH for a legacy WIP encoding, and
1602018-04-12T04:42:18 <kallewoof> P2SH/P2WPKH when one of those novel encodings is used."
1612018-04-12T04:43:24 <wumpus> right, the problem is mostly one of inefficiency due to aspecificity
1622018-04-12T04:44:30 <kallewoof> *nods*
1632018-04-12T04:45:52 <luke-jr> kallewoof: minor enough I'd just prefer to wait for Bech32
1642018-04-12T04:46:12 <luke-jr> users shouldn't be touching private keys by hand anyway
1652018-04-12T04:51:21 <kallewoof> luke-jr: perhaps they shouldn't, but it's a pressing enough issue that wallets are making their own formats up for this, so it doesn't feel completely unwarranted. It depends of course on how far away we are from bech32-style format.
1662018-04-12T04:51:47 <luke-jr> I'd say let them make the BIP then ;)
1672018-04-12T04:53:37 <wumpus> I still think this is a good idea in itself
1682018-04-12T04:53:49 <kallewoof> That puts us back at square 1 on other projects, like importmulti.
1692018-04-12T04:54:18 <kallewoof> I agree with sipa that we should address the private key ambiguity before updating importmulti (#12705)
1702018-04-12T04:54:20 <gribble> https://github.com/bitcoin/bitcoin/issues/12705 | [WIP] Importmulti private key support by kallewoof · Pull Request #12705 · bitcoin/bitcoin · GitHub
1712018-04-12T04:55:08 <wumpus> right
1722018-04-12T04:55:39 <sipa> kallewoof, luke-jr, wumpus: i think we should see the existing WIF format as *just* a key with no information about associated addresses; it has to be clear from the context or irrelevant
1732018-04-12T04:56:08 <sipa> while the new format can be a combined key + implicit associated address
1742018-04-12T04:56:44 <sipa> kallewoof: i haven't worked on an extended bech32 in a while; i could pick it up again, but the design space is so big :)
1752018-04-12T04:56:47 <wumpus> yes
1762018-04-12T04:56:59 <kallewoof> sipa: Would it make sense to use bech32 as is for private keys?
1772018-04-12T04:57:22 <sipa> kallewoof: bech32 itself? it can only correct two errors
1782018-04-12T04:58:02 <kallewoof> Right. I know you were looking into optimizing that. I guess what I wonder is, does it make sense to do something without an optimized extended bech32 or should we just sit tight?
1792018-04-12T04:58:05 <sipa> i would expect that for private ieys you want to be able to correct more
1802018-04-12T04:59:25 <wumpus> you'd want to propose a completely new encoding for private keys?
1812018-04-12T04:59:43 <sipa> and things like extended pubkeys etc
1822018-04-12T04:59:54 <sipa> anything that's not specifically optimized to be short
1832018-04-12T05:00:03 <wumpus> right
1842018-04-12T05:01:12 <sipa> but again, i haven't worked on that in a while
1852018-04-12T05:02:02 <sipa> i believe with 13 checksum characters you can correct 4 errors easily
1862018-04-12T05:02:13 <wumpus> it seems a long-term thing, and there seems to be some demandfrom wallet authors for an intermediate format, I think that's what motivated the BIP
1872018-04-12T05:02:56 <sipa> yup
1882018-04-12T05:07:42 <wumpus> but yes having a robust, error correcting private key format would be very nice
1892018-04-12T05:10:17 <sipa> maybe i'll post a summary of the options on the ml
1902018-04-12T05:10:30 <kallewoof> sipa: That would be great
1912018-04-12T05:10:58 <kallewoof> sipa: I'd love to work on the extended bech32 format, but to be honest, I don't think I'd find an optimal solution on my own. :)
1922018-04-12T05:12:54 <sipa> i'll post a list of options
1932018-04-12T05:14:36 <sipa> i don't have the knowledge/computation to find an optimal solution either
1942018-04-12T05:14:48 <sipa> for bech32 it was doable due to limited search space
1952018-04-12T05:16:01 *** d9b4bef9 has quit IRC
1962018-04-12T05:17:08 *** d9b4bef9 has joined #bitcoin-core-dev
1972018-04-12T05:19:43 *** cryptojanitor has quit IRC
1982018-04-12T05:23:54 *** zigen has joined #bitcoin-core-dev
1992018-04-12T05:29:35 *** jtimon has quit IRC
2002018-04-12T05:31:09 *** dcousens has joined #bitcoin-core-dev
2012018-04-12T05:57:46 *** goatpig has joined #bitcoin-core-dev
2022018-04-12T06:01:16 *** dafunkiz_ has joined #bitcoin-core-dev
2032018-04-12T06:01:29 *** shesek has quit IRC
2042018-04-12T06:15:35 *** arubi has quit IRC
2052018-04-12T06:20:11 *** arubi has joined #bitcoin-core-dev
2062018-04-12T06:21:45 *** intcat has quit IRC
2072018-04-12T06:22:49 *** intcat has joined #bitcoin-core-dev
2082018-04-12T06:24:07 *** dafunkiz_ has quit IRC
2092018-04-12T06:30:55 <jonasschnelli> Currently, encodings that use more space may be more cumbersome for seed backups,... though it could be orthogonal (depening on the new concept)
2102018-04-12T06:30:58 <bitcoin-git> [bitcoin] practicalswift opened pull request #12963: Fix Clang Static Analyzer warnings (master...issue-12961) https://github.com/bitcoin/bitcoin/pull/12963
2112018-04-12T06:31:50 <jonasschnelli> Also, if length is not an issue, why not just use <privkey><privkey><chsm>?
2122018-04-12T06:32:14 <sipa> ?
2132018-04-12T06:32:42 <sipa> two privkeys?
2142018-04-12T06:35:58 <wumpus> could also encode to a passphrase in some dictionary and use the redundancy of e.g. english for error correction (not sure how that compares to other approaches :-)
2152018-04-12T06:36:16 <jonasschnelli> sipa: the same key twice
2162018-04-12T06:36:54 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/979f59850c72...e561cf4fa865
2172018-04-12T06:36:55 <bitcoin-git> bitcoin/master 3450a9b Ben Woosley: Extract consts for WITNESS_V0 hash sizes
2182018-04-12T06:36:55 <bitcoin-git> bitcoin/master e561cf4 Wladimir J. van der Laan: Merge #12939: Extract consts for WITNESS_V0 hash sizes...
2192018-04-12T06:38:01 <bitcoin-git> [bitcoin] laanwj closed pull request #12939: Extract consts for WITNESS_V0 hash sizes (master...hash-size-constants) https://github.com/bitcoin/bitcoin/pull/12939
2202018-04-12T06:38:46 <jonasschnelli> Maybe I got a wrong understanding of the use case.
2212018-04-12T06:39:48 <sipa> jonasschnelli: that's stupid :)
2222018-04-12T06:40:03 <sipa> you can get far better error correction with that length :)
2232018-04-12T06:40:19 <sipa> wumpus: you know gramtropy?
2242018-04-12T06:40:43 <jonasschnelli> Okay. Then I'm better be quite about encoding and error correction. :)
2252018-04-12T06:41:15 *** anome has joined #bitcoin-core-dev
2262018-04-12T06:41:21 <wumpus> sipa: I was just thinking of that, but couldn't find it, I suppose incorporating grammar would create even more redundancy
2272018-04-12T06:41:34 <jonasschnelli> https://github.com/sipa/gramtropy
2282018-04-12T06:42:53 <wumpus> though no, that's not as easy to correct for
2292018-04-12T06:46:06 <sipa> ha, no :)
2302018-04-12T06:48:54 *** moneyball has quit IRC
2312018-04-12T06:59:25 <jonasschnelli> sipa: where is your long-term-wallet concept gist/wiki?
2322018-04-12T06:59:58 <jonasschnelli> Is there a central place for bitcoin core implementation concepts?
2332018-04-12T07:03:27 *** Randolf has quit IRC
2342018-04-12T07:03:37 <kallewoof> jonasschnelli: Don't think so. We could make a page on the wiki and link to stuff as we see it maybe.
2352018-04-12T07:03:53 <jonasschnelli> Yes. Maybe a topic for today
2362018-04-12T07:03:58 *** nullptr| has quit IRC
2372018-04-12T07:04:12 *** nullptr| has joined #bitcoin-core-dev
2382018-04-12T07:07:27 <sipa> jonasschnelli: https://gist.github.com/sipa/125cfa1615946d0c3f3eec2ad7f250a2
2392018-04-12T07:07:31 <jonasschnelli> thx!
2402018-04-12T07:10:05 <bitcoin-git> [bitcoin] lutangar closed pull request #12736: [RPC][Refactoring] Meaningful error code when called with wrong number of arguments (master...error-code-for-param-number) https://github.com/bitcoin/bitcoin/pull/12736
2412018-04-12T07:12:58 *** zigen has quit IRC
2422018-04-12T07:13:35 *** zigen has joined #bitcoin-core-dev
2432018-04-12T07:18:11 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e561cf4fa865...39439e5ab419
2442018-04-12T07:18:12 <bitcoin-git> bitcoin/master 72ec5b7 Gregory Sanders: debug log number of unknown wallet records on load
2452018-04-12T07:18:12 <bitcoin-git> bitcoin/master 39439e5 Wladimir J. van der Laan: Merge #12888: debug log number of unknown wallet records on load...
2462018-04-12T07:18:22 *** zigen has quit IRC
2472018-04-12T07:18:35 *** anome has quit IRC
2482018-04-12T07:19:06 <bitcoin-git> [bitcoin] laanwj closed pull request #12888: debug log number of unknown wallet records on load (master...unknownrec) https://github.com/bitcoin/bitcoin/pull/12888
2492018-04-12T07:21:57 *** DMTcrypto has quit IRC
2502018-04-12T07:25:02 *** tripleslash has quit IRC
2512018-04-12T07:27:16 *** tripleslash has joined #bitcoin-core-dev
2522018-04-12T07:30:46 <kallewoof> So, I've now heard several people express positive things about "<type literal>:<WIF>" as a way to specify key types. So if you had a bech32 public key, you would express its private key as p2wpkh:<Base58WIF>. This is apparently what Electrum is/did switch(ing) to.
2532018-04-12T07:32:15 <kallewoof> My only concern is if people start manually prefixing previously dumped privkeys and getting the type wrong, but that should never cause a loss of funds as discussed earlier.
2542018-04-12T07:37:44 <sipa> well... humans shouldn't be dealing with private keys directly, in general
2552018-04-12T07:37:46 <stevenroose> sipa: about the coins cache, AddCoin only checks if a new entry doesn't overwrite a non-spent entry *in the cache*. what prevents overwriting a non-spent entry that is not cached?
2562018-04-12T07:38:00 <sipa> stevenroose: bip30
2572018-04-12T07:38:27 <sipa> and bip34
2582018-04-12T07:39:42 <sipa> stevenroose: the checks there are consistency checks (= they protect against bugs in the code), they're not what prevents actual blocks from performing such uodates
2592018-04-12T07:39:52 <sipa> those are dealt with in consensus code
2602018-04-12T07:41:13 <kallewoof> sipa: Sure, but this encourages that behavior by being human readable, as opposed to a binary byte value embedded in the format itself.
2612018-04-12T07:43:44 *** timothy has joined #bitcoin-core-dev
2622018-04-12T07:45:29 *** rls0 has quit IRC
2632018-04-12T07:46:12 *** Amuza has joined #bitcoin-core-dev
2642018-04-12T07:47:04 *** zarez has joined #bitcoin-core-dev
2652018-04-12T07:48:14 *** drizztbsd has joined #bitcoin-core-dev
2662018-04-12T07:48:17 <stevenroose> sipa: that makes sense
2672018-04-12T07:48:44 *** timothy has quit IRC
2682018-04-12T07:52:04 *** zigen has joined #bitcoin-core-dev
2692018-04-12T07:52:09 *** drizztbsd is now known as timothy
2702018-04-12T07:55:20 <sipa> kallewoof: fair point
2712018-04-12T07:55:24 *** Victorsueca has quit IRC
2722018-04-12T07:55:35 <sipa> kallewoof: but then again, why do we have a concise format anyway?
2732018-04-12T07:56:38 *** Victorsueca has joined #bitcoin-core-dev
2742018-04-12T07:59:35 *** tripleslash has quit IRC
2752018-04-12T07:59:51 <kallewoof> sipa: well, in my case I realized I had an old GUI wallet with bitcoin in it, and it allowed me to export the private keys. I just imported those into bitcoin core, rather than sending the amount (it was tiny). In the future, this will probably be done using the HD master key instead, but I don't know. Anyway, I may not always want to import the entire wallet, just a specific key...
2762018-04-12T08:03:27 *** Amuza has quit IRC
2772018-04-12T08:03:39 <jonasschnelli> kallewoof: IMO "transporting" private keys is non-ideal security practice
2782018-04-12T08:04:10 *** Varunram_ has quit IRC
2792018-04-12T08:04:10 *** Varunram_ has joined #bitcoin-core-dev
2802018-04-12T08:04:10 *** Varunram_ has joined #bitcoin-core-dev
2812018-04-12T08:05:44 <kallewoof> jonasschnelli: It may not be ideal, but I think people will be tempted to do it between their own wallets, esp if the amounts are smallish.
2822018-04-12T08:06:04 *** Varunram_ is now known as Varunram
2832018-04-12T08:11:09 *** Victorsueca has quit IRC
2842018-04-12T08:12:24 *** Victorsueca has joined #bitcoin-core-dev
2852018-04-12T08:15:23 *** anome has joined #bitcoin-core-dev
2862018-04-12T08:16:40 *** anome has quit IRC
2872018-04-12T08:17:28 *** anome has joined #bitcoin-core-dev
2882018-04-12T08:19:38 *** jarthur has quit IRC
2892018-04-12T08:19:54 *** Samdney has joined #bitcoin-core-dev
2902018-04-12T08:37:40 *** Amuza has joined #bitcoin-core-dev
2912018-04-12T08:46:16 <bitcoin-git> [bitcoin] jonasschnelli opened pull request #12965: Add RPC call setscriptthreadsenabled: allow to temp. throttle CPU usage (master...2018/04/svt) https://github.com/bitcoin/bitcoin/pull/12965
2922018-04-12T08:55:15 *** promag has joined #bitcoin-core-dev
2932018-04-12T08:58:26 *** tripleslash has joined #bitcoin-core-dev
2942018-04-12T09:02:45 *** zigen has quit IRC
2952018-04-12T09:19:14 *** laurentmt has joined #bitcoin-core-dev
2962018-04-12T09:29:09 <bitcoin-git> [bitcoin] kallewoof opened pull request #12966: [WIP] Mempool optimized feerate (master...mempool-optimized-feerate) https://github.com/bitcoin/bitcoin/pull/12966
2972018-04-12T09:42:07 *** jtimon has joined #bitcoin-core-dev
2982018-04-12T09:55:13 *** anome has quit IRC
2992018-04-12T09:55:38 *** anome has joined #bitcoin-core-dev
3002018-04-12T10:08:11 *** Victorsueca has quit IRC
3012018-04-12T10:09:22 *** Victorsueca has joined #bitcoin-core-dev
3022018-04-12T10:12:11 <bitcoin-git> [bitcoin] Empact closed pull request #12459: Assert compressed keys are strictly shorter than regular (master...assert-compressed-smaller) https://github.com/bitcoin/bitcoin/pull/12459
3032018-04-12T10:16:29 *** tryphe has quit IRC
3042018-04-12T10:19:50 *** fanquake has joined #bitcoin-core-dev
3052018-04-12T10:20:14 <fanquake> wumpus I opened #12955 for the weird travis failures. I'd like to know what's happening before we merge 12899..
3062018-04-12T10:20:15 <gribble> https://github.com/bitcoin/bitcoin/issues/12955 | travis: Windows build failing after -pie changes · Issue #12955 · bitcoin/bitcoin · GitHub
3072018-04-12T10:21:02 <wumpus> fanquake: I agree, certainly don't plan to merge it unless it passes travis
3082018-04-12T10:22:52 <fanquake> wumpus I'm also putting together a PR for most of the 0.16 backports. Any thoughts on a 0.16.1 release? Looks like there is 1 PR left which needs a rebase.
3092018-04-12T10:23:29 <wumpus> fanquake: is there a trigger for a 0.16.1 release?
3102018-04-12T10:23:33 <fanquake> *1 PR that should be merged before 0.16.1 that is
3112018-04-12T10:23:41 *** DMTcrypto has joined #bitcoin-core-dev
3122018-04-12T10:23:50 <wumpus> (apart from that it's a good idea to already backport some things, but just wondering)
3132018-04-12T10:24:31 <fanquake> wumpus no particular trigger at the moment
3142018-04-12T10:28:16 <bitcoin-git> [bitcoin] fanquake opened pull request #12967: backport: #12626, #12650, #12487 (0.16...backport-12626) https://github.com/bitcoin/bitcoin/pull/12967
3152018-04-12T10:28:27 *** DMTcrypto has quit IRC
3162018-04-12T10:36:03 <promag> someone knows why assert(CWallet::GetConflicts(txid).count(txid) == 0) can fail??
3172018-04-12T10:36:28 <promag> can a txid conflict with itself?
3182018-04-12T10:40:48 *** DMTcrypto has joined #bitcoin-core-dev
3192018-04-12T10:45:50 *** promag has quit IRC
3202018-04-12T10:54:06 *** ghost43 has quit IRC
3212018-04-12T10:54:21 *** ghost43 has joined #bitcoin-core-dev
3222018-04-12T11:02:48 *** Giszmo has joined #bitcoin-core-dev
3232018-04-12T11:02:52 *** Giszmo has quit IRC
3242018-04-12T11:08:01 *** d9b4bef9 has quit IRC
3252018-04-12T11:09:35 *** d9b4bef9 has joined #bitcoin-core-dev
3262018-04-12T11:12:12 *** Giszmo has joined #bitcoin-core-dev
3272018-04-12T11:12:16 *** Giszmo has quit IRC
3282018-04-12T11:14:33 *** Giszmo has joined #bitcoin-core-dev
3292018-04-12T11:28:19 *** shesek has joined #bitcoin-core-dev
3302018-04-12T11:28:20 *** shesek has quit IRC
3312018-04-12T11:28:20 *** shesek has joined #bitcoin-core-dev
3322018-04-12T11:31:11 *** promag has joined #bitcoin-core-dev
3332018-04-12T11:40:02 *** rls has joined #bitcoin-core-dev
3342018-04-12T11:41:21 *** Victorsueca has quit IRC
3352018-04-12T11:42:38 *** Victorsueca has joined #bitcoin-core-dev
3362018-04-12T11:48:17 <instagibbs> jonasschnelli, also writing down a key twice means correlated errors. sad!
3372018-04-12T11:48:35 <instagibbs> if im writing down a key, get a character wrong, super likely ill do it twice
3382018-04-12T12:12:03 *** fanquake has quit IRC
3392018-04-12T12:19:56 <wumpus> instagibbs: just munge the second time w/ some xor key *ducks*
3402018-04-12T12:23:32 *** fanquake has joined #bitcoin-core-dev
3412018-04-12T12:27:05 *** laurentmt has quit IRC
3422018-04-12T12:27:31 *** Samdney has quit IRC
3432018-04-12T12:29:16 *** cryptojanitor has joined #bitcoin-core-dev
3442018-04-12T12:32:57 *** zautomata2 has quit IRC
3452018-04-12T12:34:09 *** promag has quit IRC
3462018-04-12T12:34:57 *** promag has joined #bitcoin-core-dev
3472018-04-12T12:35:12 *** zautomata2 has joined #bitcoin-core-dev
3482018-04-12T12:38:55 *** Krellan has quit IRC
3492018-04-12T12:39:58 *** promag has quit IRC
3502018-04-12T12:40:19 *** Krellan has joined #bitcoin-core-dev
3512018-04-12T12:40:39 *** AaronvanW has joined #bitcoin-core-dev
3522018-04-12T12:41:38 *** SopaXorzTaker has joined #bitcoin-core-dev
3532018-04-12T12:42:23 *** Aaronvan_ has joined #bitcoin-core-dev
3542018-04-12T12:45:53 *** AaronvanW has quit IRC
3552018-04-12T12:47:00 *** harding_ is now known as harding
3562018-04-12T12:48:24 *** harding has quit IRC
3572018-04-12T12:48:37 *** harding has joined #bitcoin-core-dev
3582018-04-12T12:50:46 *** DMTcrypto has quit IRC
3592018-04-12T12:57:44 *** rls has quit IRC
3602018-04-12T12:58:31 *** promag has joined #bitcoin-core-dev
3612018-04-12T13:01:52 *** promag_ has joined #bitcoin-core-dev
3622018-04-12T13:03:36 *** Guyver2 has joined #bitcoin-core-dev
3632018-04-12T13:04:38 *** promag has quit IRC
3642018-04-12T13:07:27 *** propumpkin is now known as contrapumpkin
3652018-04-12T13:22:23 *** DMTcrypto has joined #bitcoin-core-dev
3662018-04-12T13:24:55 *** lnostdal has quit IRC
3672018-04-12T13:26:57 *** DMTcrypto has quit IRC
3682018-04-12T13:32:08 *** fanquake has quit IRC
3692018-04-12T13:34:35 *** rabidus has quit IRC
3702018-04-12T13:34:53 *** lnostdal has joined #bitcoin-core-dev
3712018-04-12T13:38:26 *** shesek has quit IRC
3722018-04-12T13:38:50 *** DMTcrypto has joined #bitcoin-core-dev
3732018-04-12T14:02:59 *** zarez has quit IRC
3742018-04-12T14:03:11 <jamesob> anyone have any good workarounds for the github-unicorn-of-death effect for prs with many comments? I'm basically unable to continue review on #11857 because the page won't load
3752018-04-12T14:03:16 <gribble> https://github.com/bitcoin/bitcoin/issues/11857 | Build tx index in parallel with validation by jimpo · Pull Request #11857 · bitcoin/bitcoin · GitHub
3762018-04-12T14:05:06 *** fanquake has joined #bitcoin-core-dev
3772018-04-12T14:05:21 <fanquake> jamesob Pretty sure that's just GitHub having a sad
3782018-04-12T14:05:30 *** musou has joined #bitcoin-core-dev
3792018-04-12T14:05:30 <fanquake> I'm also seeing unicorns
3802018-04-12T14:05:46 <jamesob> fanquake: yeah it's been pretty bad for the last 24 hours
3812018-04-12T14:05:53 <aj> huh, it's working fine here :-/
3822018-04-12T14:06:18 *** musou has quit IRC
3832018-04-12T14:06:19 <jamesob> of course their status page reports 100% uptime :)
3842018-04-12T14:07:03 *** zarez has joined #bitcoin-core-dev
3852018-04-12T14:24:29 <sipa> kallewoof: my goal here is to make sure there exists a compact description of your wallet that's human readable to the extent it has structure that matters (see my wallet design gist)... but it doesn't need to be a single string or collection thereof
3862018-04-12T14:36:14 *** wvr has joined #bitcoin-core-dev
3872018-04-12T14:36:58 *** DMTcrypto has quit IRC
3882018-04-12T14:39:06 <promag_> jnewbery: hi, did you understand my point?
3892018-04-12T14:40:23 *** fanquake has quit IRC
3902018-04-12T14:43:46 *** promag_ is now known as promag
3912018-04-12T14:44:21 <promag> jnewbery: saw your relpy in gh, ty
3922018-04-12T14:45:27 *** str4d has joined #bitcoin-core-dev
3932018-04-12T14:46:07 <jnewbery> promag: i don't think I fully understand! I've answered as best I can, but perhaps you can elaborate in the PR
3942018-04-12T14:46:47 <promag> jnewbery: I thought 0.18 won't have those dummy args
3952018-04-12T14:49:05 *** DMTcrypto has joined #bitcoin-core-dev
3962018-04-12T14:49:09 <jnewbery> It's possible to remove the dummy args in a future version, but not necessary. Removing dummy args is an API break.
3972018-04-12T14:49:27 *** str4d has quit IRC
3982018-04-12T14:50:01 <jnewbery> Other RPCs have had dummy args for many releases. See priorisetransaction and move for example.
3992018-04-12T14:54:05 *** promag has quit IRC
4002018-04-12T15:03:57 *** Amuza has quit IRC
4012018-04-12T15:24:04 *** Cheeseo has quit IRC
4022018-04-12T15:24:09 *** cheese_ has joined #bitcoin-core-dev
4032018-04-12T15:30:18 *** Emcy_ has quit IRC
4042018-04-12T15:32:40 *** CubicEarths has quit IRC
4052018-04-12T15:33:19 *** CubicEarths has joined #bitcoin-core-dev
4062018-04-12T15:34:24 <wumpus> how careful to be with RPC API breakage depends on how much the RPC is used (uncommon and debugging RPCs should just be changed, but e.g. not sendtoaddress), as well as the consequences when running old code and the dummy argument is provided anyway
4072018-04-12T15:36:39 *** lnostdal has quit IRC
4082018-04-12T15:41:17 *** NicolasDorier has quit IRC
4092018-04-12T15:41:29 *** NicolasDorier has joined #bitcoin-core-dev
4102018-04-12T15:50:34 *** dafunkiz_ has joined #bitcoin-core-dev
4112018-04-12T15:53:33 *** dermoth has quit IRC
4122018-04-12T15:53:56 *** dermoth has joined #bitcoin-core-dev
4132018-04-12T15:54:00 *** Aaronvan_ has quit IRC
4142018-04-12T15:54:19 *** CubicEar_ has joined #bitcoin-core-dev
4152018-04-12T15:57:45 *** CubicEarths has quit IRC
4162018-04-12T16:14:35 *** arubi has quit IRC
4172018-04-12T16:14:59 *** arubi has joined #bitcoin-core-dev
4182018-04-12T16:17:21 *** dafunkiz_ has quit IRC
4192018-04-12T16:24:30 *** rls has joined #bitcoin-core-dev
4202018-04-12T16:30:22 *** dafunkiz_ has joined #bitcoin-core-dev
4212018-04-12T16:31:37 *** Samdney has joined #bitcoin-core-dev
4222018-04-12T16:42:43 *** lnostdal has joined #bitcoin-core-dev
4232018-04-12T16:42:44 *** dafunkiz_ has quit IRC
4242018-04-12T16:44:08 *** dafunkiz_ has joined #bitcoin-core-dev
4252018-04-12T16:44:09 *** promag has joined #bitcoin-core-dev
4262018-04-12T16:45:12 *** timothy has quit IRC
4272018-04-12T16:52:25 *** Randolf has joined #bitcoin-core-dev
4282018-04-12T16:52:32 *** dafunkiz_ has quit IRC
4292018-04-12T16:53:44 *** Murch has joined #bitcoin-core-dev
4302018-04-12T16:57:59 *** Krellan has quit IRC
4312018-04-12T16:58:04 *** instagibbs has quit IRC
4322018-04-12T16:59:42 *** AaronvanW has joined #bitcoin-core-dev
4332018-04-12T17:00:01 *** so has quit IRC
4342018-04-12T17:04:05 *** anome has quit IRC
4352018-04-12T17:06:20 *** dafunkiz_ has joined #bitcoin-core-dev
4362018-04-12T17:10:26 *** belcher_ has joined #bitcoin-core-dev
4372018-04-12T17:11:32 *** rls0 has joined #bitcoin-core-dev
4382018-04-12T17:15:32 *** rls has quit IRC
4392018-04-12T17:20:49 *** moneyball has joined #bitcoin-core-dev
4402018-04-12T17:22:16 <promag> meeting at 20 utc?
4412018-04-12T17:22:43 <wumpus> 19 utc
4422018-04-12T17:22:48 <promag> ok ty
4432018-04-12T17:23:11 <wumpus> which should be 1 hour and ~38 minutes from now
4442018-04-12T17:23:45 <promag> :+1:
4452018-04-12T17:31:20 *** Emcy has joined #bitcoin-core-dev
4462018-04-12T17:31:53 *** dafunkiz_ has quit IRC
4472018-04-12T17:37:02 *** promag has quit IRC
4482018-04-12T17:37:21 *** jnewbery has quit IRC
4492018-04-12T17:38:21 <bitcoin-git> [bitcoin] laanwj opened pull request #12968: leveldb: Add ARMv8 CRC32C support (master...2018_04_armv8_crc32c) https://github.com/bitcoin/bitcoin/pull/12968
4502018-04-12T17:38:35 *** dafunkiz_ has joined #bitcoin-core-dev
4512018-04-12T17:46:13 *** dafunkiz_ has quit IRC
4522018-04-12T17:47:09 *** jnewbery has joined #bitcoin-core-dev
4532018-04-12T17:48:07 *** zarez has quit IRC
4542018-04-12T17:48:23 <jonasschnelli> wumpus: what ARM v8 machine do you use for testing/develpoing?
4552018-04-12T17:48:56 <wumpus> jonasschnelli: a server at mininodes that crashes all the time! I have a i.mx8 boards that I should set up though
4562018-04-12T17:49:04 *** cryptojanitor has quit IRC
4572018-04-12T17:50:13 <wumpus> (https://www.nxp.com/support/developer-resources/run-time-software/i.mx-developer-resources/evaluation-kit-for-the-i.mx-8m-applications-processor:MCIMX8M-EVK)
4582018-04-12T17:50:34 <jonasschnelli> The Cortex A53 is also v8 and should have the crc32 ext, right?
4592018-04-12T17:51:25 <jonasschnelli> (RPi3, Pine64, Ordoid-C2)
4602018-04-12T17:51:39 <wumpus> ah yes good idea, I have an odroid C2 here which has it
4612018-04-12T17:52:35 <jonasschnelli> My HC2/XU4 have an A15 (v7)... will report about performance soon
4622018-04-12T17:53:00 <jonasschnelli> wumpus: what tool do/did you use for performance measuring, gperf?
4632018-04-12T17:53:04 <wumpus> thanks!
4642018-04-12T17:53:48 <wumpus> I didn't measure performance of bitcoind at all yet, just crcbench independently: https://github.com/laanwj/crcbench
4652018-04-12T17:54:02 <jonasschnelli> ok
4662018-04-12T17:56:05 <wumpus> (which was impressive; about 6x faster on C2)
4672018-04-12T17:56:50 <cfields> wumpus: nice :)
4682018-04-12T18:02:27 *** dafunkiz_ has joined #bitcoin-core-dev
4692018-04-12T18:07:50 *** moneyball has quit IRC
4702018-04-12T18:07:58 *** drexl has joined #bitcoin-core-dev
4712018-04-12T18:10:27 *** moneyball has joined #bitcoin-core-dev
4722018-04-12T18:10:33 *** Victorsueca has quit IRC
4732018-04-12T18:11:09 *** SopaXorzTaker has quit IRC
4742018-04-12T18:11:42 <jonasschnelli> bitcoin_bench should have some verification benchmarks (simulate connectblock() or something with -par=0[auto])
4752018-04-12T18:11:54 *** Victorsueca has joined #bitcoin-core-dev
4762018-04-12T18:12:45 *** StopAndDecrypt has quit IRC
4772018-04-12T18:15:57 <wumpus> I think that's the only one out of the couple of benchmarks I proposed that never got implemented; it's difficult to do without setting up a lot of context
4782018-04-12T18:18:40 *** arbitrary_guy has joined #bitcoin-core-dev
4792018-04-12T18:25:42 *** moneyball has quit IRC
4802018-04-12T18:28:21 *** laurentmt has joined #bitcoin-core-dev
4812018-04-12T18:29:01 *** moneyball has joined #bitcoin-core-dev
4822018-04-12T18:33:17 *** dafunkiz_ has quit IRC
4832018-04-12T18:34:48 <drexl> is a compressed public key valid for a P2PK scriptPubKey?
4842018-04-12T18:35:30 <wumpus> yes
4852018-04-12T18:36:56 <drexl> cheers
4862018-04-12T18:37:37 *** StopAndDecrypt has joined #bitcoin-core-dev
4872018-04-12T18:37:47 *** StopAndDecrypt has quit IRC
4882018-04-12T18:37:47 *** StopAndDecrypt has joined #bitcoin-core-dev
4892018-04-12T18:38:12 <midnightmagic> wonder when it'll be time to pick up a sifive thingy..
4902018-04-12T18:40:03 <wumpus> the sifive unleashed board seems really nice
4912018-04-12T18:40:21 <midnightmagic> bunny crapped on it :-/
4922018-04-12T18:40:50 <wumpus> oh? just the closed bootloader thing or more?
4932018-04-12T18:40:54 <midnightmagic> dunno why, ultimately. Are you picking one up for porting?
4942018-04-12T18:41:09 <midnightmagic> wumpus: just the closed initial boot stuff, yes, so far.
4952018-04-12T18:41:27 <wumpus> well that's no worse than NXP then at least...
4962018-04-12T18:41:33 <wumpus> midnightmagic: yes :)
4972018-04-12T18:41:49 <midnightmagic> nice, I'm glad. that makes me want one now.
4982018-04-12T18:42:22 <wumpus> would be more worried if e.g. the performance was really bad, or worse it crashed randomly
4992018-04-12T18:43:32 *** ProfMac has quit IRC
5002018-04-12T18:43:57 <jonasschnelli> Our gitian -debug builds -O2 -g, right? They should be okay for performance profiling?
5012018-04-12T18:44:48 <wumpus> yes -O2 -g is fine for performance profiling, -g itself doesn't make your code slower, make sure the lock debugging and such is not enabled though
5022018-04-12T18:45:21 <jonasschnelli> I once remember reading something about -g3 for gcc... anyway, thanks wumpus
5032018-04-12T18:46:12 <jonasschnelli> cfields: do you know why the dependency download on OSX is timing out on gitian/master: https://bitcoin.jonasschnelli.ch/builds/564/build_osx.log
5042018-04-12T18:46:18 <jonasschnelli> +?
5052018-04-12T18:46:56 <wumpus> -g is additive, it adds metadata, -g2 -g3 (potentially, depending on the compiler) adds more metadata. But that's all separate from the .text segments afaik
5062018-04-12T18:47:28 <jonasschnelli> thanks
5072018-04-12T18:48:51 <cfields> jonasschnelli: looking
5082018-04-12T18:49:32 <cfields> jonasschnelli: curl: (28) Resolving timed out after 10542 milliseconds
5092018-04-12T18:49:41 <cfields> dns issues?
5102018-04-12T18:49:52 <jonasschnelli> let me check
5112018-04-12T18:50:24 <jonasschnelli> dig dig bitbucket.org works perfect...
5122018-04-12T18:51:04 <jonasschnelli> maybe an LXC container thing
5132018-04-12T18:51:08 <cfields> jonasschnelli: are you sure your gitian machine has dns/net access?
5142018-04-12T18:51:12 <cfields> right, that's what I was thinking
5152018-04-12T18:51:29 <jonasschnelli> the machine has,... not sure about LXC<-HOST->NET
5162018-04-12T18:51:52 <cfields> jonasschnelli: can you download sources as a prior step?
5172018-04-12T18:52:31 <jonasschnelli> cfields: Yes. But that is outside of the VM/LXC
5182018-04-12T18:52:45 <cfields> right
5192018-04-12T18:53:20 <jonasschnelli> need to check how I can get the LXC shell again...
5202018-04-12T18:54:08 *** promag has joined #bitcoin-core-dev
5212018-04-12T18:55:34 *** meshcollider has joined #bitcoin-core-dev
5222018-04-12T18:55:44 <cfields> jonasschnelli: if you've got the right candles burning and say the right incantation, "libexec/on-target" might work.
5232018-04-12T18:55:55 <jonasschnelli> heh
5242018-04-12T18:57:14 *** StopAndDecrypt has quit IRC
5252018-04-12T18:57:45 *** arbitrary_guy has quit IRC
5262018-04-12T19:00:43 <BlueMatt> mtg?
5272018-04-12T19:01:04 <sdaftuar> ack
5282018-04-12T19:01:16 <Randolf> Ack.
5292018-04-12T19:01:26 <BlueMatt> whereforartthou wumpus
5302018-04-12T19:01:49 <wumpus> #startmeeting
5312018-04-12T19:01:49 <lightningbot> Meeting started Thu Apr 12 19:01:49 2018 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
5322018-04-12T19:01:49 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
5332018-04-12T19:02:04 <wumpus> #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 jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator
5342018-04-12T19:02:09 <promag> hi
5352018-04-12T19:02:12 <Randolf> Hello.
5362018-04-12T19:02:13 <achow101> hi
5372018-04-12T19:02:15 <sipa> hi
5382018-04-12T19:02:16 <jonasschnelli> hi
5392018-04-12T19:02:27 <kanzure> hi.
5402018-04-12T19:02:36 <cfields> hi
5412018-04-12T19:02:39 <meshcollider> hi
5422018-04-12T19:02:40 <wumpus> any proposed topics?
5432018-04-12T19:02:42 <luke-jr> o hai
5442018-04-12T19:02:59 <sipa> #12874 What to do with IsMine of bare multisig?
5452018-04-12T19:03:01 <gribble> https://github.com/bitcoin/bitcoin/issues/12874 | Only accept bare multisig outputs after addmultisigaddress by sipa · Pull Request #12874 · bitcoin/bitcoin · GitHub
5462018-04-12T19:03:18 <wumpus> thanks
5472018-04-12T19:03:29 <jimpo> hi
5482018-04-12T19:03:29 <promag> dynamic wallet load/unload
5492018-04-12T19:03:37 <luke-jr> I don't know why we would *ever* accept bare multisig
5502018-04-12T19:03:41 <wumpus> let's start with "high priority for review" as usual
5512018-04-12T19:03:44 <wumpus> #topic high priority for review
5522018-04-12T19:03:55 <wumpus> https://github.com/bitcoin/bitcoin/projects/8
5532018-04-12T19:04:14 <jimpo> Waiting on BlueMatt to rereview #11857 after revision
5542018-04-12T19:04:17 <wumpus> #11857 #12560 #11775
5552018-04-12T19:04:17 <BlueMatt> #11775 should probably removed and replaced with the forthcoming split of it into multiple pr's
5562018-04-12T19:04:18 <gribble> https://github.com/bitcoin/bitcoin/issues/11857 | Build tx index in parallel with validation by jimpo · Pull Request #11857 · bitcoin/bitcoin · GitHub
5572018-04-12T19:04:23 <gribble> https://github.com/bitcoin/bitcoin/issues/11857 | Build tx index in parallel with validation by jimpo · Pull Request #11857 · bitcoin/bitcoin · GitHub
5582018-04-12T19:04:28 <gribble> https://github.com/bitcoin/bitcoin/issues/12560 | [wallet] Upgrade path for non-HD wallets to HD by achow101 · Pull Request #12560 · bitcoin/bitcoin · GitHub
5592018-04-12T19:04:29 <BlueMatt> though the first few commits could still use eyeballs
5602018-04-12T19:04:29 <gribble> https://github.com/bitcoin/bitcoin/issues/11775 | Move fee estimator into validationinterface/cscheduler thread by TheBlueMatt · Pull Request #11775 · bitcoin/bitcoin · GitHub
5612018-04-12T19:04:31 <gribble> https://github.com/bitcoin/bitcoin/issues/11775 | Move fee estimator into validationinterface/cscheduler thread by TheBlueMatt · Pull Request #11775 · bitcoin/bitcoin · GitHub
5622018-04-12T19:04:40 <sdaftuar> BlueMatt: i'll give you my comments after you split it :P
5632018-04-12T19:04:43 <BlueMatt> as for 11857, yes, thats my fault :/
5642018-04-12T19:05:17 <jtimon> hi
5652018-04-12T19:05:37 <jimpo> #12560 still has one unaddressed comment by me I think
5662018-04-12T19:05:39 <gribble> https://github.com/bitcoin/bitcoin/issues/12560 | [wallet] Upgrade path for non-HD wallets to HD by achow101 · Pull Request #12560 · bitcoin/bitcoin · GitHub
5672018-04-12T19:05:40 <wumpus> BlueMatt: ok
5682018-04-12T19:05:41 <BlueMatt> as for 12560...why no reivew? :/
5692018-04-12T19:06:09 <wumpus> dunno github gives me the unicorn now
5702018-04-12T19:06:14 *** dafunkiz_ has joined #bitcoin-core-dev
5712018-04-12T19:06:48 <Randolf> The "unicorn?"
5722018-04-12T19:06:48 <jtimon> I guess https://github.com/bitcoin/bitcoin/pull/10757 is not a priority, but review beg either way now that there's many people
5732018-04-12T19:06:59 <sipa> #10757
5742018-04-12T19:07:02 <gribble> https://github.com/bitcoin/bitcoin/issues/10757 | RPC: Introduce getblockstats to plot things by jtimon · Pull Request #10757 · bitcoin/bitcoin · GitHub
5752018-04-12T19:07:27 <wumpus> Randolf: the "This page is taking way too long to load." unicorn
5762018-04-12T19:07:43 <BlueMatt> lol, cancel meeting cause github broken?
5772018-04-12T19:07:54 <Randolf> wumpus: I haven't seen that one yet.
5782018-04-12T19:07:58 <Randolf> That's hilarious.
5792018-04-12T19:07:58 <wumpus> looks like the bot still can use the API
5802018-04-12T19:08:05 <jtimon> works for me just fine...
5812018-04-12T19:08:24 <jtimon> I got a unicorn the other day though, I reloaded and it worked
5822018-04-12T19:08:55 <wumpus> usually it takes a few minutes and then it works again
5832018-04-12T19:09:10 <promag> jtimon: I'll take a look
5842018-04-12T19:09:19 <jtimon> promag: awesome, thanks
5852018-04-12T19:09:28 <wumpus> I'll add 10757
5862018-04-12T19:09:59 * Randolf wonders if "Unicorns" is going to be listed as one of the topics in the log afterwards
5872018-04-12T19:10:18 <achow101> i believe i addressed all comments for 12560, but i could have missed one or two
5882018-04-12T19:10:30 <jtimon> great, I had it kind of abandoned for some time but aj helped me with the tests and I got "unstuck"
5892018-04-12T19:11:10 <promag> I can also look 12560, at least code wise
5902018-04-12T19:11:10 <jimpo> achow101: I requested that HaveKey be moved out of the RPC file and into keystore
5912018-04-12T19:11:15 <jimpo> not sure if others agree
5922018-04-12T19:12:27 <wumpus> might want to discuss that outside the meeting?
5932018-04-12T19:12:41 <achow101> oh, I missed that comment
5942018-04-12T19:12:54 *** plorark has joined #bitcoin-core-dev
5952018-04-12T19:12:58 <jnewbery> hi
5962018-04-12T19:13:04 <plorark> hey
5972018-04-12T19:13:05 <plorark> omg
5982018-04-12T19:13:10 <plorark> I've found people alive
5992018-04-12T19:13:12 <jimpo> yeah, we can discuss offline (well, still online, but yeah)
6002018-04-12T19:13:31 <plorark> watshapenin
6012018-04-12T19:13:32 <wumpus> #topic What to do with IsMine of bare multisig? (sipa)
6022018-04-12T19:13:46 <sipa> hi
6032018-04-12T19:13:48 <wumpus> plorark: after the meeting please
6042018-04-12T19:13:50 <Randolf> plorark: You've joined this channel during a meeting.
6052018-04-12T19:14:04 <plorark> omg sorry
6062018-04-12T19:14:05 <sipa> so currently (and since forever) we accept bare multisig outputs to us
6072018-04-12T19:14:08 *** instagibbs_ has joined #bitcoin-core-dev
6082018-04-12T19:14:25 <sipa> this is stupid, annoying, pointless, and hard to maintain
6092018-04-12T19:14:33 <achow101> are there any wallets that can even make bare multisig?
6102018-04-12T19:14:42 <sipa> BIP70, technically :)
6112018-04-12T19:14:48 <achow101> ew
6122018-04-12T19:14:52 <sipa> because it only works when you have all the public keys
6132018-04-12T19:15:00 <sipa> eh, all the private keys
6142018-04-12T19:15:12 <wumpus> sounds completely useless
6152018-04-12T19:15:12 <sipa> so generally i think this is a feature that nobody should ever want
6162018-04-12T19:15:19 <luke-jr> we don't act as BIP70 server ever though
6172018-04-12T19:15:26 <sipa> however, there may be existing outputs to it
6182018-04-12T19:15:33 <sipa> i don't know if this is the case or not
6192018-04-12T19:15:38 <jtimon> do people use bip70 ?
6202018-04-12T19:15:39 <sipa> but it sounds scary to just stop supporting it
6212018-04-12T19:15:47 <wumpus> so that needs some chain analysis I suppose
6222018-04-12T19:15:55 <echeveria> bitpay uses bip70 exclusively.
6232018-04-12T19:16:06 <BlueMatt> sipa: we'd not "stop supporting it", you'd still be able to sign for them in rawtransaction rpcs
6242018-04-12T19:16:14 <BlueMatt> so write up a five-sentence release not and stop supporting it :p
6252018-04-12T19:16:20 * luke-jr wonders how much overhead there'd be to supporting it up to a certain height
6262018-04-12T19:16:24 <achow101> sipa: is it possible to just prevent new bare multisig?
6272018-04-12T19:16:25 <jtimon> sipa: perhaps deperecate it on the next release ?
6282018-04-12T19:16:25 <sipa> BlueMatt: i have no intention to stop supporting signing for it
6292018-04-12T19:16:29 <jtimon> echeveria: thanks
6302018-04-12T19:16:34 <BlueMatt> sipa: yes, thats my point
6312018-04-12T19:16:36 <sipa> this is just about IsMine
6322018-04-12T19:16:46 <wumpus> just stop supporting it for receiving to our wallet
6332018-04-12T19:16:58 <sipa> yes, that's the easy part
6342018-04-12T19:17:07 <jtimon> BlueMatt: sounds fair enough
6352018-04-12T19:17:08 <sipa> but what if there are existing outputs in people's wallet
6362018-04-12T19:17:09 <BlueMatt> I mean step back a minute, if we're still talking about doing another hd split to move to a address model instead of a pubkey model in the wallet, why not do it then
6372018-04-12T19:17:19 <BlueMatt> and keep doing the default-add of the scripts from the original keys?
6382018-04-12T19:17:28 <BlueMatt> incl all the stuff we support today
6392018-04-12T19:17:37 <sipa> BlueMatt: ah, because it's impossible to remain compatible with it in an address model
6402018-04-12T19:17:46 <jonasschnelli> if one has already detected bar multisig txns, they will not disappear (unless rescan)?
6412018-04-12T19:17:47 <sipa> (you get a cubic explosion of combinations)
6422018-04-12T19:17:58 <BlueMatt> I though we only supported about 4 different script types?
6432018-04-12T19:18:02 <instagibbs_> sipa: sorry give an example?
6442018-04-12T19:18:07 <BlueMatt> raw multisig, p2ph, p2pubkey, and...?
6452018-04-12T19:18:15 <achow101> isn't the plan to move to a script model?
6462018-04-12T19:18:20 <sipa> BlueMatt: yes, but raw multisig up to 3-of-3
6472018-04-12T19:18:30 <BlueMatt> ouch
6482018-04-12T19:18:31 <sipa> which means N^3 combinations if you have N private keys
6492018-04-12T19:18:32 <plorark> ehh... I know I was not supposed to interrupt the meeting, but it's pointless for me to wait if this is not the channel i'm looking for. Is altcoins development discussions allowed here?
6502018-04-12T19:18:39 <Randolf> I thought Multisig could support more than 3 signatures.
6512018-04-12T19:18:39 <sipa> plorark: no
6522018-04-12T19:18:44 <sipa> Randolf: not standard
6532018-04-12T19:18:50 <instagibbs_> plorark: no
6542018-04-12T19:18:55 <plorark> oh, ok, sorry
6552018-04-12T19:18:56 <plorark> see ya
6562018-04-12T19:18:59 <Randolf> plorark: Join the ##altcoins channel.
6572018-04-12T19:19:01 <plorark> thx
6582018-04-12T19:19:10 <plorark> thx
6592018-04-12T19:19:10 <luke-jr> ##altcoin-dev *
6602018-04-12T19:19:12 <plorark> oops
6612018-04-12T19:19:19 <plorark> thx and bye
6622018-04-12T19:19:19 <BlueMatt> I mean, anyway, does it matter much? I'd default to "dont support with release notes indicating you can use signrawtransaction"
6632018-04-12T19:19:31 <sipa> so the #1 reason to fix this now is because I'd like to remain compatible with whatever the wallet already supports
6642018-04-12T19:19:34 <gribble> https://github.com/bitcoin/bitcoin/issues/1 | JSON-RPC support for mobile devices ("ultra-lightweight" clients) · Issue #1 · bitcoin/bitcoin · GitHub
6652018-04-12T19:19:35 <sipa> except for bare multisig
6662018-04-12T19:19:46 <BlueMatt> if we really care, add an option to include them when we move to address-based
6672018-04-12T19:19:51 <BlueMatt> with a note indicating it will eat all your memory
6682018-04-12T19:19:54 <Randolf> sipa: Maintaining compatibility seems like a very good justification.
6692018-04-12T19:20:09 <sipa> BlueMatt: by default our keypool is 2000 keys
6702018-04-12T19:20:14 <sipa> the cube of that is 8 billion
6712018-04-12T19:20:15 <BlueMatt> yes, I know
6722018-04-12T19:20:19 <sipa> that's just not feasible
6732018-04-12T19:20:24 <jimpo> Is there a way to register bare multisigs as some sort of key-thing?
6742018-04-12T19:20:31 <BlueMatt> meh, so dont support it at all without manual key-adds, then
6752018-04-12T19:20:46 <BlueMatt> jimpo: you could register the scripts as watch only
6762018-04-12T19:20:49 <instagibbs_> jimpo: manual import isn't out of question i assume
6772018-04-12T19:20:49 <sipa> BlueMatt: that's what #12874 does!
6782018-04-12T19:20:51 <gribble> https://github.com/bitcoin/bitcoin/issues/12874 | Only accept bare multisig outputs after addmultisigaddress by sipa · Pull Request #12874 · bitcoin/bitcoin · GitHub
6792018-04-12T19:20:52 <jimpo> So that IsMine is true only if you explicitly watch the script
6802018-04-12T19:21:05 <sipa> jimpo: yes, that is the PR i have open
6812018-04-12T19:21:07 <BlueMatt> sipa: I dont even think we need to match IsMine/accept them at that point
6822018-04-12T19:21:10 <jimpo> Oh, cool
6832018-04-12T19:21:13 <BlueMatt> sipa: would prefer we get rid of it completely
6842018-04-12T19:21:19 <BlueMatt> and just let people mark it watchonly
6852018-04-12T19:21:22 <sipa> i want to bring up is: is this overkill, and should we instead just remove it
6862018-04-12T19:21:22 <BlueMatt> then signrawtransaction it
6872018-04-12T19:21:31 <sipa> can you watchonly it?
6882018-04-12T19:21:40 <sipa> you can only watchonly addresses, not scripts, afaik
6892018-04-12T19:21:54 <sipa> ok i will investigate
6902018-04-12T19:21:55 <sdaftuar> importmulti lets you, i thought?
6912018-04-12T19:21:56 <instagibbs_> does it not sneak under redeemscript field or somesuch?
6922018-04-12T19:21:59 <jonasschnelli> just stop supporting it and mention it in the release notes... this seems safe and okay to me.
6932018-04-12T19:22:00 <instagibbs_> yeah check it out
6942018-04-12T19:22:45 <jimpo> sipa: Do you think there's a large burden to maintaining #12874?
6952018-04-12T19:22:46 <gribble> https://github.com/bitcoin/bitcoin/issues/12874 | Only accept bare multisig outputs after addmultisigaddress by sipa · Pull Request #12874 · bitcoin/bitcoin · GitHub
6962018-04-12T19:23:13 <sipa> jimpo: no, but it'd be better not to
6972018-04-12T19:23:21 <jonasschnelli> bar-multisig use-cases are data-services only IMO... we could analyze the utxos first to get a idea about how many potentail users would be affected...
6982018-04-12T19:23:29 <jonasschnelli> but right,.. existing bare multisig wtx would not disapear, right?
6992018-04-12T19:23:47 <sipa> they would
7002018-04-12T19:23:57 <jonasschnelli> ah.. isMine(), right
7012018-04-12T19:24:20 <jonasschnelli> but we could detect that and warn
7022018-04-12T19:24:43 <jimpo> If there's not a big downside to #12874, I'd prefer that approach, but don't care much if it's deprecated
7032018-04-12T19:24:45 <gribble> https://github.com/bitcoin/bitcoin/issues/12874 | Only accept bare multisig outputs after addmultisigaddress by sipa · Pull Request #12874 · bitcoin/bitcoin · GitHub
7042018-04-12T19:25:24 <sipa> BlueMatt: it seems we can indeed watch scripts
7052018-04-12T19:25:35 <sipa> i think that's my preferred approach then
7062018-04-12T19:25:55 <sipa> remove support entirely and note a workaround for the highly unlikely case in the release notes
7072018-04-12T19:26:07 <BlueMatt> yes
7082018-04-12T19:26:07 <jonasschnelli> ack
7092018-04-12T19:26:08 <wumpus> yes
7102018-04-12T19:26:09 <BlueMatt> agreed
7112018-04-12T19:26:12 <sipa> end topic
7122018-04-12T19:26:28 <wumpus> #topic dynamic wallet load/unload (promag)
7132018-04-12T19:26:34 <Randolf> Ack.
7142018-04-12T19:26:50 <promag> not sure what you guys think
7152018-04-12T19:26:56 <instagibbs_> what's the controversy in this topic :)
7162018-04-12T19:27:01 <jonasschnelli> #10740
7172018-04-12T19:27:02 <sipa> it should happen, duh
7182018-04-12T19:27:04 <gribble> https://github.com/bitcoin/bitcoin/issues/10740 | [WIP] [wallet] dynamic loading/unloading of wallets by jnewbery · Pull Request #10740 · bitcoin/bitcoin · GitHub
7192018-04-12T19:27:06 <wumpus> seems like something we want to have at some point...
7202018-04-12T19:27:07 <promag> but I think luke agrees that wallet management should be with shared pointers
7212018-04-12T19:27:08 <sipa> how and when is another :)
7222018-04-12T19:27:26 <luke-jr> indeed, using names just asks for chaos with runtime-changing wallets
7232018-04-12T19:28:19 <promag> please read #11402 for some reasons to switch
7242018-04-12T19:28:20 <gribble> https://github.com/bitcoin/bitcoin/issues/11402 | Use shared pointer for wallet instances by promag · Pull Request #11402 · bitcoin/bitcoin · GitHub
7252018-04-12T19:28:54 <jonasschnelli> IMO 10740 can't create wallets, IMO first step would be to add a createwallet RPC call
7262018-04-12T19:29:21 <jonasschnelli> the whole creation/configuration setup if flawed since multiwallet
7272018-04-12T19:29:29 <jonasschnelli> stuff like -keypool should be per wallet
7282018-04-12T19:29:35 *** isis is now known as isis_
7292018-04-12T19:29:40 <jnewbery> jonasschnelli: you think createwallet should go in *before* load/unload?
7302018-04-12T19:29:43 <jonasschnelli> and persisted in the wallet file (as configuration section)
7312018-04-12T19:29:55 <jonasschnelli> jnewbery: not sure,.. just thinking
7322018-04-12T19:30:05 <jnewbery> seems reasonable to me
7332018-04-12T19:30:25 <jonasschnelli> createwallet could also *not* load the wallet in the first step (not ideal, but maybe reduces complexity)
7342018-04-12T19:30:25 <sipa> that seems strange... you could create a new wallet at run time but not use it?
7352018-04-12T19:30:29 *** instagibbs_ has quit IRC
7362018-04-12T19:30:41 <jonasschnelli> sipa: createwallet could also directly load/use the wallet
7372018-04-12T19:30:46 <jnewbery> I think createwallet would also load the new wallet, no?
7382018-04-12T19:30:48 <promag> create implies loading
7392018-04-12T19:30:52 <luke-jr> sipa: iow, 0 to 1 only.
7402018-04-12T19:31:06 <sipa> jonasschnelli: well then you need to have loading functionality first!
7412018-04-12T19:31:14 <sipa> and if you have it, why not expose it
7422018-04-12T19:31:36 *** plorark has left #bitcoin-core-dev
7432018-04-12T19:31:53 <jonasschnelli> sipa: yes. That's a point.
7442018-04-12T19:31:54 <jnewbery> createwallet could also be done by bitcoin-wallet-tool
7452018-04-12T19:32:23 <jnewbery> (#8745)
7462018-04-12T19:32:25 <gribble> https://github.com/bitcoin/bitcoin/issues/8745 | [PoC] Add wallet inspection and modification tool "bitcoin-wallet-tool" by jonasschnelli · Pull Request #8745 · bitcoin/bitcoin · GitHub
7472018-04-12T19:32:35 <jonasschnelli> Yes. Would be possible...
7482018-04-12T19:32:55 <jonasschnelli> I just think the create-during-startup approach is not good
7492018-04-12T19:33:06 <promag> also related #10973
7502018-04-12T19:33:07 <jnewbery> jonasschnelli: I agree
7512018-04-12T19:33:09 <gribble> https://github.com/bitcoin/bitcoin/issues/10973 | Refactor: separate wallet from node by ryanofsky · Pull Request #10973 · bitcoin/bitcoin · GitHub
7522018-04-12T19:33:10 <sipa> jonasschnelli: agree
7532018-04-12T19:33:24 <jonasschnelli> And as a first step I though createwallet would make sense.. but not loading it seems after a strange use-case
7542018-04-12T19:33:29 <luke-jr> load -> create -> unload
7552018-04-12T19:33:33 <jonasschnelli> but a nice first code/impl. step
7562018-04-12T19:33:36 <luke-jr> unload is the complex part tbh
7572018-04-12T19:33:49 <jnewbery> luke-jr: agree
7582018-04-12T19:34:05 <jonasschnelli> Agree with luke-jr. Maybe split unload away from the existing PR jnewbery ?
7592018-04-12T19:34:11 *** Randolf has quit IRC
7602018-04-12T19:34:12 <jnewbery> yes
7612018-04-12T19:34:28 <jnewbery> I intend to pick up 10740 again soon, rebase and rework it
7622018-04-12T19:34:39 <promag> consider the use case: 1) rpc rescan wallet 2) in parallel unload wallet - should 2) wait for 1) ?
7632018-04-12T19:34:57 <luke-jr> probably
7642018-04-12T19:35:01 <jonasschnelli> Great. Dynamic loading/creating is a nice feature that we probably want for 0.17!
7652018-04-12T19:35:30 <promag> luke-jr: and if the unload is from the UI?
7662018-04-12T19:35:57 <jnewbery> promag: do you consider 11402 a prereq for load/unload? What about just load?
7672018-04-12T19:36:01 <jonasschnelli> the wallet-tool is IMO orthogonal to wallet creation
7682018-04-12T19:36:13 <jonasschnelli> *via RPC
7692018-04-12T19:36:28 *** anome has joined #bitcoin-core-dev
7702018-04-12T19:36:39 <luke-jr> promag: probably the same
7712018-04-12T19:36:43 <promag> jnewbery: IMHO for both
7722018-04-12T19:36:50 <jonasschnelli> RPC seems to be a must, wallet-tool can be a better place to create some sorts of wallets (or inspect it), .. like encrypted wallets
7732018-04-12T19:36:52 <luke-jr> promag: at least initially
7742018-04-12T19:37:40 <jnewbery> promag: want to rebase and put on high priority for review then, if you consider it a blocker?
7752018-04-12T19:37:50 <promag> luke-jr: my point is that it should not block, you request the unload and go on, when the wallet is not used anymore it gets unloaded
7762018-04-12T19:38:11 <jonasschnelli> #11402
7772018-04-12T19:38:13 <gribble> https://github.com/bitcoin/bitcoin/issues/11402 | Use shared pointer for wallet instances by promag · Pull Request #11402 · bitcoin/bitcoin · GitHub
7782018-04-12T19:38:15 <luke-jr> promag: you mean leave the wallet loaded, but invisible? that seems worst outcome IMO
7792018-04-12T19:38:26 <luke-jr> user may unload and just shut off the PC
7802018-04-12T19:38:44 <wumpus> the unload should probably be in two stages: after requesting it, RPC and the GUI lose access to it. Then it waits for current operations tofinish. Then the thing really gets delted.
7812018-04-12T19:38:50 <luke-jr> yes
7822018-04-12T19:38:53 <promag> luke-jr: then the application will wait for wallets to unload
7832018-04-12T19:38:54 <jnewbery> I don't think we need to worry about unload at this stage. First step is add load functionality, then createwallet functionality
7842018-04-12T19:38:57 <luke-jr> and make it visible to the user in the meantime
7852018-04-12T19:39:06 <luke-jr> jnewbery: +1
7862018-04-12T19:39:17 <promag> wumpus: right, hence shared pointers
7872018-04-12T19:40:13 <wumpus> ok
7882018-04-12T19:40:19 <wumpus> any other topics? we've had the proposed ones
7892018-04-12T19:41:04 *** dafunkiz_ has quit IRC
7902018-04-12T19:41:05 <luke-jr> gitian updates?
7912018-04-12T19:41:17 <luke-jr> seems we have at least a few things that need a newer VM
7922018-04-12T19:41:27 <luke-jr> not sure if there's anything to discuss tho
7932018-04-12T19:42:33 <wumpus> dunno if cfields is here, if not it makes little sense to discuss this I think
7942018-04-12T19:42:45 <cfields> sure
7952018-04-12T19:43:01 <wumpus> #topic gitian update
7962018-04-12T19:43:38 <wumpus> #12511 I guess
7972018-04-12T19:43:39 <gribble> https://github.com/bitcoin/bitcoin/issues/12511 | Switch to Ubuntu 18.04 for gitian building · Issue #12511 · bitcoin/bitcoin · GitHub
7982018-04-12T19:44:24 <wumpus> not sure what's there to discuss about it
7992018-04-12T19:44:53 <luke-jr> I guess we need a replacement for vmbuilder or something, since Canonical hasn't updated it to support anything recent :/
8002018-04-12T19:45:55 <cfields> ah, i didn't realize gitian couldn't handle it :(
8012018-04-12T19:46:02 <wumpus> debootstrap?
8022018-04-12T19:46:10 <luke-jr> debootstrap is a step in vmbuilder
8032018-04-12T19:46:47 <cfields> anyway, concept ack
8042018-04-12T19:47:36 <achow101> I'm considering adding docker support to gitian so we would use a default ubuntu docker image and then build from there
8052018-04-12T19:47:37 <wumpus> cool
8062018-04-12T19:48:20 <cfields> sgtm
8072018-04-12T19:48:25 <jcorgan> that would be nice
8082018-04-12T19:49:05 <wumpus> yes
8092018-04-12T19:49:18 <luke-jr> so KVM would no longer work?
8102018-04-12T19:49:45 <wumpus> heh if you make it work it will work
8112018-04-12T19:49:56 <luke-jr> Docker seems to just be a LXC wrapper
8122018-04-12T19:50:18 <achow101> Docker avoids all of the vm setup because someone else did that for us
8132018-04-12T19:50:21 <luke-jr> it's also x86-64 only
8142018-04-12T19:50:24 <wumpus> if vmbuilder or debootstrap does't work you could always manually install ubuntu to a base image I guess...
8152018-04-12T19:51:04 <jtimon> achow101: please, ping me for review if you do
8162018-04-12T19:51:07 <wumpus> but in my experience debootstrap works very well, though I've never used it for ubuntu on x86
8172018-04-12T19:51:19 <wumpus> I
8182018-04-12T19:52:12 <achow101> jtimon: sure
8192018-04-12T19:53:19 <wumpus> yes, I'm willing to test the docker stuff as well
8202018-04-12T19:53:39 <luke-jr> I suppose fixing vmbuilder might be not too unreasonable effort, maybe I will try that :/
8212018-04-12T19:53:49 <wumpus> though I agree iwht luke-jr it's not a long-term solution, can't be used from other platforms, though cfields is still working on his long-term solution I hope
8222018-04-12T19:54:28 <cfields> wumpus: yes, very much so.
8232018-04-12T19:54:55 <wumpus> great!
8242018-04-12T19:55:30 <wumpus> time to wrap up the meeting I think
8252018-04-12T19:55:39 <wumpus> unless someone has a quick topic
8262018-04-12T19:56:11 <wumpus> #endmeeting
8272018-04-12T19:56:11 <lightningbot> Meeting ended Thu Apr 12 19:56:11 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
8282018-04-12T19:56:11 <lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-04-12-19.01.html
8292018-04-12T19:56:11 <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-04-12-19.01.txt
8302018-04-12T19:56:11 <lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-04-12-19.01.log.html
8312018-04-12T19:57:08 <sipa> wumpus: would you like me to not use the lifetime extension of temporaries approach in https://github.com/bitcoin/bitcoin/pull/12803#discussion_r180788539 ?
8322018-04-12T19:57:45 <wumpus> sipa: it's fine, I just didn't know about that
8332018-04-12T19:58:08 <sipa> it's a feature i knew about for years, but always wondered about it usefulness
8342018-04-12T19:58:53 *** moneyball has quit IRC
8352018-04-12T19:58:58 <wumpus> well this seems a good reason!
8362018-04-12T19:59:40 <sipa> i guess the reasoning was "assigning a temporary to a reference never makes any sense! ok, let's give it another meaning that does make sense then..."
8372018-04-12T20:01:44 <promag> that was new to me too, but could drop the reference no?
8382018-04-12T20:02:03 <wumpus> I like the fact that this avoids having to export the type
8392018-04-12T20:03:16 *** dafunkiz_ has joined #bitcoin-core-dev
8402018-04-12T20:03:50 <sipa> promag: no
8412018-04-12T20:04:16 <promag> right, doesn't work with base = extended..
8422018-04-12T20:04:21 <promag> see https://github.com/bitcoin/bitcoin/blob/master/src/init.cpp#L90-L92
8432018-04-12T20:04:31 <promag> sipa: could use your approach there right?
8442018-04-12T20:04:50 <promag> and turn g_wallet_init_interface to a reference instead?
8452018-04-12T20:04:55 <sipa> if we write it as "const BaseSignatureCreator dummy_creator = DummySignatureCreator()", a DummySignatureCreator object is created, but then *assigned* (using operator=) to a BaseSignatureCreator object which is exported
8462018-04-12T20:05:17 <sipa> rather than exporting the DummySignatureCreator object itself (with a hidden type)
8472018-04-12T20:05:28 <sipa> hmm, perhaps
8482018-04-12T20:05:46 <wumpus> it will get sliced
8492018-04-12T20:06:42 <wumpus> if you don't make it a reference or pointer
8502018-04-12T20:06:52 <promag> I'll try the same with g_wallet_init_interface, don't think a pointer is good for such "central" instances
8512018-04-12T20:07:14 <wumpus> and a pointer would have the problem of needing a scoped ptr etc
8522018-04-12T20:07:23 <jonasschnelli> cfields: iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE was missing...
8532018-04-12T20:07:37 <cfields> jonasschnelli: aha :)
8542018-04-12T20:07:52 <promag> wumpus: not true, see https://github.com/bitcoin/bitcoin/blob/master/src/init.cpp#L90-L91 workaround
8552018-04-12T20:08:20 <wumpus> promag: why would that be any better though?
8562018-04-12T20:08:51 <wumpus> also the initialization/freeing order is less clear that way
8572018-04-12T20:08:52 <promag> I'm§ ~
8582018-04-12T20:08:52 <promag> \
8592018-04-12T20:08:59 <promag> ops, cat..
8602018-04-12T20:09:02 *** dafunkiz_ has quit IRC
8612018-04-12T20:09:49 <promag> wumpus: not saying it's better, I prefer sipa approach
8622018-04-12T20:10:13 *** jtimon has quit IRC
8632018-04-12T20:10:54 <wumpus> ok, sorry, I misunderstood you then
8642018-04-12T20:11:35 *** goatpig has quit IRC
8652018-04-12T20:22:29 *** laurentmt has quit IRC
8662018-04-12T20:29:29 *** promag has quit IRC
8672018-04-12T20:32:17 <cfields> sipa: fyi, since you were looking at it earlier... on my slow (mac) laptop, the coin_selection tests spend half of their time formatting the date/time string for the debug print in AddToWallet()
8682018-04-12T20:32:43 <cfields> wouldn't surprise me if that's even more painful via Wine
8692018-04-12T20:34:23 *** Randolf has joined #bitcoin-core-dev
8702018-04-12T20:34:47 <sipa> heh
8712018-04-12T20:36:19 <wumpus> whoops
8722018-04-12T20:36:44 *** instagibbs has joined #bitcoin-core-dev
8732018-04-12T20:41:13 *** jtimon has joined #bitcoin-core-dev
8742018-04-12T20:43:38 *** tryphe has joined #bitcoin-core-dev
8752018-04-12T20:46:43 *** Victorsueca has quit IRC
8762018-04-12T20:47:54 *** Victorsueca has joined #bitcoin-core-dev
8772018-04-12T20:48:53 <bitcoin-git> [bitcoin] Empact opened pull request #12969: Drop dead code CScript::Find (master...cscript-find) https://github.com/bitcoin/bitcoin/pull/12969
8782018-04-12T20:49:13 *** anome has quit IRC
8792018-04-12T20:50:14 *** Murch has quit IRC
8802018-04-12T20:50:44 *** Murch has joined #bitcoin-core-dev
8812018-04-12T20:51:58 *** Emcy has quit IRC
8822018-04-12T20:55:25 *** dafunkiz_ has joined #bitcoin-core-dev
8832018-04-12T20:56:38 <bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/39439e5ab419...8480d41e0f9d
8842018-04-12T20:56:39 <bitcoin-git> bitcoin/master 190b8d2 Pieter Wuille: Make BaseSignatureCreator a pure interface
8852018-04-12T20:56:40 <bitcoin-git> bitcoin/master be67831 Pieter Wuille: Make DummySignatureCreator a singleton
8862018-04-12T20:56:40 <bitcoin-git> bitcoin/master 8480d41 Wladimir J. van der Laan: Merge #12803: Make BaseSignatureCreator a pure interface...
8872018-04-12T20:57:53 <bitcoin-git> [bitcoin] laanwj closed pull request #12803: Make BaseSignatureCreator a pure interface (master...201803_puresignaturecreator) https://github.com/bitcoin/bitcoin/pull/12803
8882018-04-12T21:04:31 *** Emcy has joined #bitcoin-core-dev
8892018-04-12T21:07:06 <cfields> whoa
8902018-04-12T21:07:23 <cfields> Leaving test case "knapsack_solver_test"; testing time: 358694ms
8912018-04-12T21:07:36 <cfields> i386 + old wine ^^
8922018-04-12T21:07:48 <cfields> Leaving test case "knapsack_solver_test"; testing time: 6781ms
8932018-04-12T21:07:58 <cfields> ^^ same, but with the LogPrint commented out
8942018-04-12T21:08:19 *** DMTcrypto has quit IRC
8952018-04-12T21:08:59 <wumpus> now that's optimization
8962018-04-12T21:09:27 <wumpus> but I don't get it, it's the unit test, aren't all logging categories disabled?
8972018-04-12T21:09:41 <cfields> so, there's the recent huge slowdown. Probably also addressed in newer wine, hence the speedup in 12931
8982018-04-12T21:10:09 <cfields> wumpus: it's a LogPrintf :(
8992018-04-12T21:10:49 <wumpus> should it be in a debug category? sounds like an extremly high volume one
9002018-04-12T21:11:34 <cfields> wumpus: I think that test just hits it really hard
9012018-04-12T21:12:10 <cfields> it'd be nice to have an explicit no-logging option for these tests, though
9022018-04-12T21:13:03 <wumpus> if both log-to-file and log-to-console is disabled, it should probably bypass all logging
9032018-04-12T21:14:05 <wumpus> even without category
9042018-04-12T21:15:14 <jnewbery> I think #11862 is now in really good shape (and is well structured and easy to review). Perhaps concept ACKers (jonasschnelli, meshcollider, jtimon) could do some review?
9052018-04-12T21:15:17 <gribble> https://github.com/bitcoin/bitcoin/issues/11862 | Network specific conf sections by ajtowns · Pull Request #11862 · bitcoin/bitcoin · GitHub
9062018-04-12T21:16:59 <wumpus> so should that one be in high priority for review?
9072018-04-12T21:19:08 <jtimon> jnewbery: I think aj is right here https://github.com/bitcoin/bitcoin/pull/11862#issuecomment-379061898 and if not it should be solvable in the other pr after rebase, but I will try to upgrade the concept ack to an ut ack or tested ack
9082018-04-12T21:19:38 <jnewbery> it's not super important and doesn't block anything, so doesn't really fit high priority. But it has been around for a while and I think it's a well-structured easy review
9092018-04-12T21:20:24 <jnewbery> I'd like to make some progress on config model. There have been a bunch of PRs around for months
9102018-04-12T21:20:32 <jtimon> yeah, I had a glance with the concept ack, should have another look
9112018-04-12T21:21:27 <jnewbery> #10267 is another one, but I think that should rebase on 11862, since 11862 seems like it's closer to merge
9122018-04-12T21:21:30 <gribble> https://github.com/bitcoin/bitcoin/issues/10267 | New -includeconf argument for including external configuration files by kallewoof · Pull Request #10267 · bitcoin/bitcoin · GitHub
9132018-04-12T21:21:57 *** DMTcrypto has joined #bitcoin-core-dev
9142018-04-12T21:22:30 <jnewbery> jtimon: I don't think this interacts badly with your 8994, so it shouldn't be blocked
9152018-04-12T21:23:23 *** niftynei has joined #bitcoin-core-dev
9162018-04-12T21:23:45 *** niftynei has quit IRC
9172018-04-12T21:23:46 <jtimon> no, not at all, I think it interacts pretty well, and that's the part of the pr that I reviewed, just asked for confirmation from the author
9182018-04-12T21:24:16 <jtimon> and even if it implied a little bit more work on #8994 I don't think that's a blocking reason anyway
9192018-04-12T21:24:20 <gribble> https://github.com/bitcoin/bitcoin/issues/8994 | Testchains: Introduce custom chain whose constructor... by jtimon · Pull Request #8994 · bitcoin/bitcoin · GitHub
9202018-04-12T21:24:32 <jtimon> but I think it doesn't
9212018-04-12T21:25:28 <jnewbery> great!
9222018-04-12T21:25:29 <jtimon> btw, I'm not rebasing #8994 very often because I think there's a few open questions I left that haven't been answered
9232018-04-12T21:25:32 <gribble> https://github.com/bitcoin/bitcoin/issues/8994 | Testchains: Introduce custom chain whose constructor... by jtimon · Pull Request #8994 · bitcoin/bitcoin · GitHub
9242018-04-12T21:27:05 <bitcoin-git> [bitcoin] theuni opened pull request #12970: logging: bypass timestamp formatting when not logging (master...slow-tests) https://github.com/bitcoin/bitcoin/pull/12970
9252018-04-12T21:27:57 <jtimon> in particular, is it ok to change regtest's genesis block? if so, all those changes to the python tests that always require rebase wouldn't be needed or could be done later, perhaps while introducting new more intresting tests like making sure regtest and testest2 disconnect from each other and stuff like that
9262018-04-12T21:28:45 <jtimon> perhaps a topic for another meeting
9272018-04-12T21:31:45 *** niftynei has joined #bitcoin-core-dev
9282018-04-12T21:33:53 *** Guyver2 has quit IRC
9292018-04-12T21:34:00 <wumpus> preferably that'd be avoided, as it makes it impossible to have a regtest with two different versions of bitcoind
9302018-04-12T21:35:33 *** cheese_ has quit IRC
9312018-04-12T21:36:58 <jtimon> wumpus: ok, thanks but moving all the python tests to custom/regtest2 is fine, right?
9322018-04-12T21:37:11 <wumpus> why?
9332018-04-12T21:37:40 <jtimon> ok, I think there's 2 parts to this PR, perhaps I should separate them
9342018-04-12T21:38:04 <wumpus> but, no, I don't think it's problematic to move th tests to a different kind of chain, though I'm not sure I see why
9352018-04-12T21:38:05 <jtimon> one is having custom params, but that can be done in regtest without changing the genesis block
9362018-04-12T21:38:54 <wumpus> for the existing tests, the current params don't need to be changed?
9372018-04-12T21:39:05 *** Randolf has quit IRC
9382018-04-12T21:39:07 *** Murch has quit IRC
9392018-04-12T21:39:40 <jtimon> the sencond is introducing the -chain option, which allows you to create new regtests (well, custom chains) on demand which have different genesis blocks (well, you just need to use a different name on -chain=mycustomchain)
9402018-04-12T21:40:07 <jtimon> right, but this opens the door to new tests
9412018-04-12T21:40:37 *** Murch has joined #bitcoin-core-dev
9422018-04-12T21:41:09 <jtimon> to me, the second part is more interesting, but I now think that I should probably separate them (since many people seem confused about the purpose)
9432018-04-12T21:42:01 <jtimon> wumpus: does that make sense to you? (or at least one of the parts)
9442018-04-12T21:42:45 <wumpus> yes for new tests that make use of different parameters it'd make sense
9452018-04-12T21:43:06 <jtimon> another recurrent topic is whether the custom params should be loaded from conf and the regular gArgs or only from an independent file
9462018-04-12T21:44:56 <jtimon> well, I think one point of the custom params is to avoid things like https://github.com/bitcoin/bitcoin/blob/master/src/chainparams.cpp#L382 for testing perhaps I should start with that
9472018-04-12T21:45:04 <wumpus> I'd say regular args would add too many arguments
9482018-04-12T21:45:47 <wumpus> this is only meant for testing, after all, so by far most will have no business overriding chain parameters
9492018-04-12T21:47:07 <jtimon> similar things have been proposed multiple times for specific fields, and also an NonConstParams() with individual sets for everything, I think this is "the right way" for any such tests
9502018-04-12T21:47:22 *** Cogito_Ergo_Sum has joined #bitcoin-core-dev
9512018-04-12T21:47:22 *** Cogito_Ergo_Sum has joined #bitcoin-core-dev
9522018-04-12T21:47:50 <jtimon> this would only override params for regtest and/or customchain, of course
9532018-04-12T21:48:47 <jtimon> CMainParams should not have an UpdateFromArgs method
9542018-04-12T21:50:42 <jtimon> anyway, I'm fine with a separate file, I think that's what I implemented first, but I thought it was confusing people and left it for later
9552018-04-12T21:51:15 <jtimon> or someone preferred regular args and conf file, I don't remember
9562018-04-12T21:52:19 <jtimon> wumpus: thanks for the feedback, so what do you think about separating it in 2? which part you think makes the most sense?
9572018-04-12T21:52:42 <jtimon> or can be more useful for tests we lack
9582018-04-12T22:03:46 <wumpus> yes, I think that makes sense
9592018-04-12T22:04:09 *** arbitrary_guy has joined #bitcoin-core-dev
9602018-04-12T22:05:41 *** Tennis has joined #bitcoin-core-dev
9612018-04-12T22:12:57 <instagibbs> listtransactions should list all transactions the wallet is involved in, yes? Including self-sends?
9622018-04-12T22:13:15 <instagibbs> sorry if #bitcoin, just getting odd results and help isn't clear
9632018-04-12T22:13:51 <sipa> yes
9642018-04-12T22:15:51 *** Aaronvan_ has joined #bitcoin-core-dev
9652018-04-12T22:18:18 *** AaronvanW has quit IRC
9662018-04-12T22:24:11 <instagibbs> thanks
9672018-04-12T22:34:21 *** arbitrary_guy has joined #bitcoin-core-dev
9682018-04-12T22:34:53 *** rls has joined #bitcoin-core-dev
9692018-04-12T22:38:09 *** rls0 has quit IRC
9702018-04-12T22:41:50 *** Cogito_Ergo_Sum has quit IRC
9712018-04-12T22:44:06 *** cryptojanitor has joined #bitcoin-core-dev
9722018-04-12T22:45:05 *** Victorsueca has quit IRC
9732018-04-12T22:45:23 *** tryphe has quit IRC
9742018-04-12T22:45:56 *** tryphe has joined #bitcoin-core-dev
9752018-04-12T22:46:24 *** Victorsueca has joined #bitcoin-core-dev
9762018-04-12T22:46:53 *** tryphe has quit IRC
9772018-04-12T22:51:01 *** arbitrary_guy has quit IRC
9782018-04-12T22:58:51 *** tryphe has joined #bitcoin-core-dev
9792018-04-12T23:01:01 *** Randolf has joined #bitcoin-core-dev
9802018-04-12T23:04:33 *** AaronvanW has joined #bitcoin-core-dev
9812018-04-12T23:05:27 *** Randolf has quit IRC
9822018-04-12T23:06:09 *** Aaronvan_ has quit IRC
9832018-04-12T23:08:22 <drexl> why does a scriptcode start with a PUSH byte? is it supposed to be pushed on the stack?
9842018-04-12T23:09:04 *** AaronvanW has quit IRC
9852018-04-12T23:11:05 *** AaronvanW has joined #bitcoin-core-dev
9862018-04-12T23:11:44 *** StopAndDecrypt has joined #bitcoin-core-dev
9872018-04-12T23:22:08 *** lnostdal has quit IRC
9882018-04-12T23:22:44 *** lnostdal has joined #bitcoin-core-dev
9892018-04-12T23:24:03 *** lnostdal has joined #bitcoin-core-dev
9902018-04-12T23:33:20 *** Murch has quit IRC
9912018-04-12T23:34:47 *** vydjz88 has joined #bitcoin-core-dev
9922018-04-12T23:38:59 *** vydjz88 has quit IRC
9932018-04-12T23:39:04 *** isis_ is now known as isis
9942018-04-12T23:42:05 *** belcher_ has quit IRC
9952018-04-12T23:45:18 *** meshcollider has quit IRC
9962018-04-12T23:48:17 *** Tennis has quit IRC
9972018-04-12T23:55:46 *** yjednmgz has joined #bitcoin-core-dev
9982018-04-12T23:57:47 *** yjednmgz has quit IRC