< 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.
< 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
< bitcoin-git> [bitcoin] sparpana opened pull request #12957: Update README.md (master...master) https://github.com/bitcoin/bitcoin/pull/12957
< bitcoin-git> [bitcoin] fanquake closed pull request #12957: Update README.md (master...master) https://github.com/bitcoin/bitcoin/pull/12957
< * dongcarl> nods
< bitcoin-git> [bitcoin] Empact opened pull request #12959: Drop IsCompressedOrUncompressedPubKey and IsCompressedPubKey (master...is-compressed-or-uncompressed) https://github.com/bitcoin/bitcoin/pull/12959
< 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
< 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
< 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
< fanquake> Is there an easy way to comment on an issue like #12961 inline?
< gribble> https://github.com/bitcoin/bitcoin/issues/12961 | 979f598: Clang Static Analyzer Report · Issue #12961 · bitcoin/bitcoin · GitHub
< 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" ?
< kallewoof> fanquake: Maybe I should've made a PR with 'no-merge:'. That would let you inline comment.
< kallewoof> No/limited formatting though..
< 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.
< fanquake> kallewoof, I'll have a go at adding some comments to the issue first.
< kallewoof> OK
< mryandao> ok, i've rebased #12240 and it finally passed all the build jobs
< 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
< wumpus> dongcarl: funding is hardly ever the issue
< mryandao> while most open source project struggle with funding, bitcoin-core has a funny situation where there simply enough human resources to spend funding? :/
< 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
< wumpus> yes the problem is people
< 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
< wumpus> kallewoof: sounds like a good idea to me
< 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).
< wumpus> kallewoof:I think non-compressed should not be suffix 0, but simply 'no suffix byte', that's better for backward compatibility
< wumpus> (you mention that yourself in Compatibility so :-)
< wumpus> looks good to me otherwise
< kallewoof> wumpus: Hm. I thought 0x00 was the same as 'no suffix byte', compatibility wise...
< wumpus> kallewoof: a lot of implementations just check the length
< kallewoof> wumpus: I mean, 0x00 is the same as 'no suffix' which means uncompressed.
< kallewoof> wumpus: Geh. Okay.
< 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!
< kallewoof> wumpus: Yeah, makes sense. So either have no suffix byte (=P2PKH_UNCOMPRESSED), or have one that is non-zero
< luke-jr> well, then it suddenly becomes a bug to interpret it as compressed/etc
< luke-jr> kallewoof: is there a PR?
< wumpus> "all types with a suffix byte are compressed"
< kallewoof> luke-jr: There's a branch, no PR yet. Can make one easily enough.
< kallewoof> luke-jr: Will fix wumpus feedback and then make PR
< luke-jr> kallewoof: PR for the BIP I mean
< kallewoof> luke-jr: Yes
< luke-jr> that goes before # assignment these days
< kallewoof> wumpus: I did a first draft on switching to uncompressed = no suffix.
< luke-jr> kallewoof: I suggest making type 0 always p2pk or p2pkh
< luke-jr> "Legacy public key format" should be "p2pkh"
< kallewoof> luke-jr: Isn't type 0 ambiguous with 'not compressed'? Or is 'not compressed' *always* a missing suffix byte?
< kallewoof> luke-jr: I forgot about P2PK though...
< luke-jr> might want to ask thomasv to co-author the BIP
< kallewoof> Yeah, good idea
< wumpus> yes, the important part is that other wallet authors agree
< wumpus> if they're not on one page, it's not much of a standard :)
< 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
< 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
< 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.
< wumpus> ok
< wumpus> (me neither, just have the same experience with ignored messages on MLs :-)
< wumpus> in open source projects you shouldn't be afraid to poke people, if necessarily repeatedly (after some time passed)
< kallewoof> wumpus: Haha, yeah I'm trying to get used to that idea.
< 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
< kallewoof> wumpus: Wow... okay. Wonder why they chose that approach.
< wumpus> accidentally, I think
< wumpus> we can fix that at the same time as implementing your BIP - just a data point
< wumpus> though at some point it would be safer to create a completely new WIF format
< wumpus> especially if we find more examples of handling the suffix byte differently
< kallewoof> wumpus: I'm gonna look around at other implementations and see how they're doing it.
< kallewoof> wumpus: Yeah.
< wumpus> yes, good idea
< luke-jr> Could Bech32 it
< wumpus> luke-jr: I had that in my mind as well
< kallewoof> Yeah, that would be nice. I know sipa has talked about it in the past.
< 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
< kallewoof> Oh wait, nevermind. They do check that it's 0x01 for compressed.
< luke-jr> a Bech32 format would be a clean break of compatibility
< wumpus> I've downgraded my ACK to Concept ACK for now
< 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.
< kallewoof> wumpus: I'll note the bech32 alternative on the BIP
< wumpus> I'm a bit afraid that this might result in funds loss in some edge cases
< 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
< kallewoof> That would be a display error, not a fund loss
< luke-jr> ^
< luke-jr> even if the user throws away the WIF, you could still export the key and fix it later
< wumpus> ok
< luke-jr> kallewoof: what's the need for an interim format? WIF is fine..
< 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
< 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
< kallewoof> P2SH/P2WPKH when one of those novel encodings is used."
< wumpus> right, the problem is mostly one of inefficiency due to aspecificity
< kallewoof> *nods*
< luke-jr> kallewoof: minor enough I'd just prefer to wait for Bech32
< luke-jr> users shouldn't be touching private keys by hand anyway
< 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.
< luke-jr> I'd say let them make the BIP then ;)
< wumpus> I still think this is a good idea in itself
< kallewoof> That puts us back at square 1 on other projects, like importmulti.
< kallewoof> I agree with sipa that we should address the private key ambiguity before updating importmulti (#12705)
< gribble> https://github.com/bitcoin/bitcoin/issues/12705 | [WIP] Importmulti private key support by kallewoof · Pull Request #12705 · bitcoin/bitcoin · GitHub
< wumpus> right
< 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
< sipa> while the new format can be a combined key + implicit associated address
< 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 :)
< wumpus> yes
< kallewoof> sipa: Would it make sense to use bech32 as is for private keys?
< sipa> kallewoof: bech32 itself? it can only correct two errors
< 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?
< sipa> i would expect that for private ieys you want to be able to correct more
< wumpus> you'd want to propose a completely new encoding for private keys?
< sipa> and things like extended pubkeys etc
< sipa> anything that's not specifically optimized to be short
< wumpus> right
< sipa> but again, i haven't worked on that in a while
< sipa> i believe with 13 checksum characters you can correct 4 errors easily
< 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
< sipa> yup
< wumpus> but yes having a robust, error correcting private key format would be very nice
< sipa> maybe i'll post a summary of the options on the ml
< kallewoof> sipa: That would be great
< 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. :)
< sipa> i'll post a list of options
< sipa> i don't have the knowledge/computation to find an optimal solution either
< sipa> for bech32 it was doable due to limited search space
< jonasschnelli> Currently, encodings that use more space may be more cumbersome for seed backups,... though it could be orthogonal (depening on the new concept)
< bitcoin-git> [bitcoin] practicalswift opened pull request #12963: Fix Clang Static Analyzer warnings (master...issue-12961) https://github.com/bitcoin/bitcoin/pull/12963
< jonasschnelli> Also, if length is not an issue, why not just use <privkey><privkey><chsm>?
< sipa> ?
< sipa> two privkeys?
< 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 :-)
< jonasschnelli> sipa: the same key twice
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/979f59850c72...e561cf4fa865
< bitcoin-git> bitcoin/master 3450a9b Ben Woosley: Extract consts for WITNESS_V0 hash sizes
< bitcoin-git> bitcoin/master e561cf4 Wladimir J. van der Laan: Merge #12939: Extract consts for WITNESS_V0 hash sizes...
< 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
< jonasschnelli> Maybe I got a wrong understanding of the use case.
< sipa> jonasschnelli: that's stupid :)
< sipa> you can get far better error correction with that length :)
< sipa> wumpus: you know gramtropy?
< jonasschnelli> Okay. Then I'm better be quite about encoding and error correction. :)
< wumpus> sipa: I was just thinking of that, but couldn't find it, I suppose incorporating grammar would create even more redundancy
< wumpus> though no, that's not as easy to correct for
< sipa> ha, no :)
< jonasschnelli> sipa: where is your long-term-wallet concept gist/wiki?
< jonasschnelli> Is there a central place for bitcoin core implementation concepts?
< kallewoof> jonasschnelli: Don't think so. We could make a page on the wiki and link to stuff as we see it maybe.
< jonasschnelli> Yes. Maybe a topic for today
< jonasschnelli> thx!
< 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
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e561cf4fa865...39439e5ab419
< bitcoin-git> bitcoin/master 72ec5b7 Gregory Sanders: debug log number of unknown wallet records on load
< bitcoin-git> bitcoin/master 39439e5 Wladimir J. van der Laan: Merge #12888: debug log number of unknown wallet records on load...
< 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
< 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.
< 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.
< sipa> well... humans shouldn't be dealing with private keys directly, in general
< 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?
< sipa> stevenroose: bip30
< sipa> and bip34
< 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
< sipa> those are dealt with in consensus code
< kallewoof> sipa: Sure, but this encourages that behavior by being human readable, as opposed to a binary byte value embedded in the format itself.
< stevenroose> sipa: that makes sense
< sipa> kallewoof: fair point
< sipa> kallewoof: but then again, why do we have a concise format anyway?
< 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...
< jonasschnelli> kallewoof: IMO "transporting" private keys is non-ideal security practice
< 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.
< 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
< bitcoin-git> [bitcoin] kallewoof opened pull request #12966: [WIP] Mempool optimized feerate (master...mempool-optimized-feerate) https://github.com/bitcoin/bitcoin/pull/12966
< 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
< fanquake> wumpus I opened #12955 for the weird travis failures. I'd like to know what's happening before we merge 12899..
< gribble> https://github.com/bitcoin/bitcoin/issues/12955 | travis: Windows build failing after -pie changes · Issue #12955 · bitcoin/bitcoin · GitHub
< wumpus> fanquake: I agree, certainly don't plan to merge it unless it passes travis
< 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.
< wumpus> fanquake: is there a trigger for a 0.16.1 release?
< fanquake> *1 PR that should be merged before 0.16.1 that is
< wumpus> (apart from that it's a good idea to already backport some things, but just wondering)
< fanquake> wumpus no particular trigger at the moment
< bitcoin-git> [bitcoin] fanquake opened pull request #12967: backport: #12626, #12650, #12487 (0.16...backport-12626) https://github.com/bitcoin/bitcoin/pull/12967
< promag> someone knows why assert(CWallet::GetConflicts(txid).count(txid) == 0) can fail??
< promag> can a txid conflict with itself?
< instagibbs> jonasschnelli, also writing down a key twice means correlated errors. sad!
< instagibbs> if im writing down a key, get a character wrong, super likely ill do it twice
< wumpus> instagibbs: just munge the second time w/ some xor key *ducks*
< 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
< gribble> https://github.com/bitcoin/bitcoin/issues/11857 | Build tx index in parallel with validation by jimpo · Pull Request #11857 · bitcoin/bitcoin · GitHub
< fanquake> jamesob Pretty sure that's just GitHub having a sad
< fanquake> I'm also seeing unicorns
< jamesob> fanquake: yeah it's been pretty bad for the last 24 hours
< aj> huh, it's working fine here :-/
< jamesob> of course their status page reports 100% uptime :)
< 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
< promag_> jnewbery: hi, did you understand my point?
< promag> jnewbery: saw your relpy in gh, ty
< jnewbery> promag: i don't think I fully understand! I've answered as best I can, but perhaps you can elaborate in the PR
< promag> jnewbery: I thought 0.18 won't have those dummy args
< jnewbery> It's possible to remove the dummy args in a future version, but not necessary. Removing dummy args is an API break.
< jnewbery> Other RPCs have had dummy args for many releases. See priorisetransaction and move for example.
< 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
< promag> meeting at 20 utc?
< wumpus> 19 utc
< promag> ok ty
< wumpus> which should be 1 hour and ~38 minutes from now
< promag> :+1:
< 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
< jonasschnelli> wumpus: what ARM v8 machine do you use for testing/develpoing?
< wumpus> jonasschnelli: a server at mininodes that crashes all the time! I have a i.mx8 boards that I should set up though
< jonasschnelli> The Cortex A53 is also v8 and should have the crc32 ext, right?
< jonasschnelli> (RPi3, Pine64, Ordoid-C2)
< wumpus> ah yes good idea, I have an odroid C2 here which has it
< jonasschnelli> My HC2/XU4 have an A15 (v7)... will report about performance soon
< jonasschnelli> wumpus: what tool do/did you use for performance measuring, gperf?
< wumpus> thanks!
< wumpus> I didn't measure performance of bitcoind at all yet, just crcbench independently: https://github.com/laanwj/crcbench
< jonasschnelli> ok
< wumpus> (which was impressive; about 6x faster on C2)
< cfields> wumpus: nice :)
< jonasschnelli> bitcoin_bench should have some verification benchmarks (simulate connectblock() or something with -par=0[auto])
< 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
< drexl> is a compressed public key valid for a P2PK scriptPubKey?
< wumpus> yes
< drexl> cheers
< midnightmagic> wonder when it'll be time to pick up a sifive thingy..
< wumpus> the sifive unleashed board seems really nice
< midnightmagic> bunny crapped on it :-/
< wumpus> oh? just the closed bootloader thing or more?
< midnightmagic> dunno why, ultimately. Are you picking one up for porting?
< midnightmagic> wumpus: just the closed initial boot stuff, yes, so far.
< wumpus> well that's no worse than NXP then at least...
< wumpus> midnightmagic: yes :)
< midnightmagic> nice, I'm glad. that makes me want one now.
< wumpus> would be more worried if e.g. the performance was really bad, or worse it crashed randomly
< jonasschnelli> Our gitian -debug builds -O2 -g, right? They should be okay for performance profiling?
< 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
< jonasschnelli> I once remember reading something about -g3 for gcc... anyway, thanks wumpus
< 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
< jonasschnelli> +?
< 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
< jonasschnelli> thanks
< cfields> jonasschnelli: looking
< cfields> jonasschnelli: curl: (28) Resolving timed out after 10542 milliseconds
< cfields> dns issues?
< jonasschnelli> let me check
< jonasschnelli> dig dig bitbucket.org works perfect...
< jonasschnelli> maybe an LXC container thing
< cfields> jonasschnelli: are you sure your gitian machine has dns/net access?
< cfields> right, that's what I was thinking
< jonasschnelli> the machine has,... not sure about LXC<-HOST->NET
< cfields> jonasschnelli: can you download sources as a prior step?
< jonasschnelli> cfields: Yes. But that is outside of the VM/LXC
< cfields> right
< jonasschnelli> need to check how I can get the LXC shell again...
< cfields> jonasschnelli: if you've got the right candles burning and say the right incantation, "libexec/on-target" might work.
< jonasschnelli> heh
< BlueMatt> mtg?
< sdaftuar> ack
< Randolf> Ack.
< BlueMatt> whereforartthou wumpus
< wumpus> #startmeeting
< lightningbot> Meeting started Thu Apr 12 19:01:49 2018 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
< lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
< 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
< promag> hi
< Randolf> Hello.
< achow101> hi
< sipa> hi
< jonasschnelli> hi
< kanzure> hi.
< cfields> hi
< meshcollider> hi
< wumpus> any proposed topics?
< luke-jr> o hai
< sipa> #12874 What to do with IsMine of bare multisig?
< gribble> https://github.com/bitcoin/bitcoin/issues/12874 | Only accept bare multisig outputs after addmultisigaddress by sipa · Pull Request #12874 · bitcoin/bitcoin · GitHub
< wumpus> thanks
< jimpo> hi
< promag> dynamic wallet load/unload
< luke-jr> I don't know why we would *ever* accept bare multisig
< wumpus> let's start with "high priority for review" as usual
< wumpus> #topic high priority for review
< jimpo> Waiting on BlueMatt to rereview #11857 after revision
< wumpus> #11857 #12560 #11775
< BlueMatt> #11775 should probably removed and replaced with the forthcoming split of it into multiple pr's
< gribble> https://github.com/bitcoin/bitcoin/issues/11857 | Build tx index in parallel with validation by jimpo · Pull Request #11857 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/11857 | Build tx index in parallel with validation by jimpo · Pull Request #11857 · bitcoin/bitcoin · GitHub
< 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
< BlueMatt> though the first few commits could still use eyeballs
< gribble> https://github.com/bitcoin/bitcoin/issues/11775 | Move fee estimator into validationinterface/cscheduler thread by TheBlueMatt · Pull Request #11775 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/11775 | Move fee estimator into validationinterface/cscheduler thread by TheBlueMatt · Pull Request #11775 · bitcoin/bitcoin · GitHub
< sdaftuar> BlueMatt: i'll give you my comments after you split it :P
< BlueMatt> as for 11857, yes, thats my fault :/
< jtimon> hi
< jimpo> #12560 still has one unaddressed comment by me I think
< 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
< wumpus> BlueMatt: ok
< BlueMatt> as for 12560...why no reivew? :/
< wumpus> dunno github gives me the unicorn now
< 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
< Randolf> The "unicorn?"
< sipa> #10757
< gribble> https://github.com/bitcoin/bitcoin/issues/10757 | RPC: Introduce getblockstats to plot things by jtimon · Pull Request #10757 · bitcoin/bitcoin · GitHub
< wumpus> Randolf: the "This page is taking way too long to load." unicorn
< BlueMatt> lol, cancel meeting cause github broken?
< Randolf> wumpus: I haven't seen that one yet.
< Randolf> That's hilarious.
< wumpus> looks like the bot still can use the API
< jtimon> works for me just fine...
< jtimon> I got a unicorn the other day though, I reloaded and it worked
< wumpus> usually it takes a few minutes and then it works again
< promag> jtimon: I'll take a look
< jtimon> promag: awesome, thanks
< wumpus> I'll add 10757
< * Randolf> wonders if "Unicorns" is going to be listed as one of the topics in the log afterwards
< achow101> i believe i addressed all comments for 12560, but i could have missed one or two
< jtimon> great, I had it kind of abandoned for some time but aj helped me with the tests and I got "unstuck"
< promag> I can also look 12560, at least code wise
< jimpo> achow101: I requested that HaveKey be moved out of the RPC file and into keystore
< jimpo> not sure if others agree
< wumpus> might want to discuss that outside the meeting?
< achow101> oh, I missed that comment
< jnewbery> hi
< plorark> hey
< plorark> omg
< plorark> I've found people alive
< jimpo> yeah, we can discuss offline (well, still online, but yeah)
< plorark> watshapenin
< wumpus> #topic What to do with IsMine of bare multisig? (sipa)
< sipa> hi
< wumpus> plorark: after the meeting please
< Randolf> plorark: You've joined this channel during a meeting.
< plorark> omg sorry
< sipa> so currently (and since forever) we accept bare multisig outputs to us
< sipa> this is stupid, annoying, pointless, and hard to maintain
< achow101> are there any wallets that can even make bare multisig?
< sipa> BIP70, technically :)
< achow101> ew
< sipa> because it only works when you have all the public keys
< sipa> eh, all the private keys
< wumpus> sounds completely useless
< sipa> so generally i think this is a feature that nobody should ever want
< luke-jr> we don't act as BIP70 server ever though
< sipa> however, there may be existing outputs to it
< sipa> i don't know if this is the case or not
< jtimon> do people use bip70 ?
< sipa> but it sounds scary to just stop supporting it
< wumpus> so that needs some chain analysis I suppose
< echeveria> bitpay uses bip70 exclusively.
< BlueMatt> sipa: we'd not "stop supporting it", you'd still be able to sign for them in rawtransaction rpcs
< BlueMatt> so write up a five-sentence release not and stop supporting it :p
< * luke-jr> wonders how much overhead there'd be to supporting it up to a certain height
< achow101> sipa: is it possible to just prevent new bare multisig?
< jtimon> sipa: perhaps deperecate it on the next release ?
< sipa> BlueMatt: i have no intention to stop supporting signing for it
< jtimon> echeveria: thanks
< BlueMatt> sipa: yes, thats my point
< sipa> this is just about IsMine
< wumpus> just stop supporting it for receiving to our wallet
< sipa> yes, that's the easy part
< jtimon> BlueMatt: sounds fair enough
< sipa> but what if there are existing outputs in people's wallet
< 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
< BlueMatt> and keep doing the default-add of the scripts from the original keys?
< BlueMatt> incl all the stuff we support today
< sipa> BlueMatt: ah, because it's impossible to remain compatible with it in an address model
< jonasschnelli> if one has already detected bar multisig txns, they will not disappear (unless rescan)?
< sipa> (you get a cubic explosion of combinations)
< BlueMatt> I though we only supported about 4 different script types?
< instagibbs_> sipa: sorry give an example?
< BlueMatt> raw multisig, p2ph, p2pubkey, and...?
< achow101> isn't the plan to move to a script model?
< sipa> BlueMatt: yes, but raw multisig up to 3-of-3
< BlueMatt> ouch
< sipa> which means N^3 combinations if you have N private keys
< 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?
< Randolf> I thought Multisig could support more than 3 signatures.
< sipa> plorark: no
< sipa> Randolf: not standard
< instagibbs_> plorark: no
< plorark> oh, ok, sorry
< plorark> see ya
< Randolf> plorark: Join the ##altcoins channel.
< plorark> thx
< plorark> thx
< luke-jr> ##altcoin-dev *
< plorark> oops
< plorark> thx and bye
< BlueMatt> I mean, anyway, does it matter much? I'd default to "dont support with release notes indicating you can use signrawtransaction"
< sipa> so the #1 reason to fix this now is because I'd like to remain compatible with whatever the wallet already supports
< gribble> https://github.com/bitcoin/bitcoin/issues/1 | JSON-RPC support for mobile devices ("ultra-lightweight" clients) · Issue #1 · bitcoin/bitcoin · GitHub
< sipa> except for bare multisig
< BlueMatt> if we really care, add an option to include them when we move to address-based
< BlueMatt> with a note indicating it will eat all your memory
< Randolf> sipa: Maintaining compatibility seems like a very good justification.
< sipa> BlueMatt: by default our keypool is 2000 keys
< sipa> the cube of that is 8 billion
< BlueMatt> yes, I know
< sipa> that's just not feasible
< jimpo> Is there a way to register bare multisigs as some sort of key-thing?
< BlueMatt> meh, so dont support it at all without manual key-adds, then
< BlueMatt> jimpo: you could register the scripts as watch only
< instagibbs_> jimpo: manual import isn't out of question i assume
< sipa> BlueMatt: that's what #12874 does!
< gribble> https://github.com/bitcoin/bitcoin/issues/12874 | Only accept bare multisig outputs after addmultisigaddress by sipa · Pull Request #12874 · bitcoin/bitcoin · GitHub
< jimpo> So that IsMine is true only if you explicitly watch the script
< sipa> jimpo: yes, that is the PR i have open
< BlueMatt> sipa: I dont even think we need to match IsMine/accept them at that point
< jimpo> Oh, cool
< BlueMatt> sipa: would prefer we get rid of it completely
< BlueMatt> and just let people mark it watchonly
< sipa> i want to bring up is: is this overkill, and should we instead just remove it
< BlueMatt> then signrawtransaction it
< sipa> can you watchonly it?
< sipa> you can only watchonly addresses, not scripts, afaik
< sipa> ok i will investigate
< sdaftuar> importmulti lets you, i thought?
< instagibbs_> does it not sneak under redeemscript field or somesuch?
< jonasschnelli> just stop supporting it and mention it in the release notes... this seems safe and okay to me.
< instagibbs_> yeah check it out
< jimpo> sipa: Do you think there's a large burden to maintaining #12874?
< gribble> https://github.com/bitcoin/bitcoin/issues/12874 | Only accept bare multisig outputs after addmultisigaddress by sipa · Pull Request #12874 · bitcoin/bitcoin · GitHub
< sipa> jimpo: no, but it'd be better not to
< 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...
< jonasschnelli> but right,.. existing bare multisig wtx would not disapear, right?
< sipa> they would
< jonasschnelli> ah.. isMine(), right
< jonasschnelli> but we could detect that and warn
< jimpo> If there's not a big downside to #12874, I'd prefer that approach, but don't care much if it's deprecated
< gribble> https://github.com/bitcoin/bitcoin/issues/12874 | Only accept bare multisig outputs after addmultisigaddress by sipa · Pull Request #12874 · bitcoin/bitcoin · GitHub
< sipa> BlueMatt: it seems we can indeed watch scripts
< sipa> i think that's my preferred approach then
< sipa> remove support entirely and note a workaround for the highly unlikely case in the release notes
< BlueMatt> yes
< jonasschnelli> ack
< wumpus> yes
< BlueMatt> agreed
< sipa> end topic
< wumpus> #topic dynamic wallet load/unload (promag)
< Randolf> Ack.
< promag> not sure what you guys think
< instagibbs_> what's the controversy in this topic :)
< jonasschnelli> #10740
< sipa> it should happen, duh
< gribble> https://github.com/bitcoin/bitcoin/issues/10740 | [WIP] [wallet] dynamic loading/unloading of wallets by jnewbery · Pull Request #10740 · bitcoin/bitcoin · GitHub
< wumpus> seems like something we want to have at some point...
< promag> but I think luke agrees that wallet management should be with shared pointers
< sipa> how and when is another :)
< luke-jr> indeed, using names just asks for chaos with runtime-changing wallets
< promag> please read #11402 for some reasons to switch
< gribble> https://github.com/bitcoin/bitcoin/issues/11402 | Use shared pointer for wallet instances by promag · Pull Request #11402 · bitcoin/bitcoin · GitHub
< jonasschnelli> IMO 10740 can't create wallets, IMO first step would be to add a createwallet RPC call
< jonasschnelli> the whole creation/configuration setup if flawed since multiwallet
< jonasschnelli> stuff like -keypool should be per wallet
< jnewbery> jonasschnelli: you think createwallet should go in *before* load/unload?
< jonasschnelli> and persisted in the wallet file (as configuration section)
< jonasschnelli> jnewbery: not sure,.. just thinking
< jnewbery> seems reasonable to me
< jonasschnelli> createwallet could also *not* load the wallet in the first step (not ideal, but maybe reduces complexity)
< sipa> that seems strange... you could create a new wallet at run time but not use it?
< jonasschnelli> sipa: createwallet could also directly load/use the wallet
< jnewbery> I think createwallet would also load the new wallet, no?
< promag> create implies loading
< luke-jr> sipa: iow, 0 to 1 only.
< sipa> jonasschnelli: well then you need to have loading functionality first!
< sipa> and if you have it, why not expose it
< jonasschnelli> sipa: yes. That's a point.
< jnewbery> createwallet could also be done by bitcoin-wallet-tool
< jnewbery> (#8745)
< 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
< jonasschnelli> Yes. Would be possible...
< jonasschnelli> I just think the create-during-startup approach is not good
< promag> also related #10973
< jnewbery> jonasschnelli: I agree
< gribble> https://github.com/bitcoin/bitcoin/issues/10973 | Refactor: separate wallet from node by ryanofsky · Pull Request #10973 · bitcoin/bitcoin · GitHub
< sipa> jonasschnelli: agree
< jonasschnelli> And as a first step I though createwallet would make sense.. but not loading it seems after a strange use-case
< luke-jr> load -> create -> unload
< jonasschnelli> but a nice first code/impl. step
< luke-jr> unload is the complex part tbh
< jnewbery> luke-jr: agree
< jonasschnelli> Agree with luke-jr. Maybe split unload away from the existing PR jnewbery ?
< jnewbery> yes
< jnewbery> I intend to pick up 10740 again soon, rebase and rework it
< promag> consider the use case: 1) rpc rescan wallet 2) in parallel unload wallet - should 2) wait for 1) ?
< luke-jr> probably
< jonasschnelli> Great. Dynamic loading/creating is a nice feature that we probably want for 0.17!
< promag> luke-jr: and if the unload is from the UI?
< jnewbery> promag: do you consider 11402 a prereq for load/unload? What about just load?
< jonasschnelli> the wallet-tool is IMO orthogonal to wallet creation
< jonasschnelli> *via RPC
< luke-jr> promag: probably the same
< promag> jnewbery: IMHO for both
< 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
< luke-jr> promag: at least initially
< jnewbery> promag: want to rebase and put on high priority for review then, if you consider it a blocker?
< 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
< jonasschnelli> #11402
< gribble> https://github.com/bitcoin/bitcoin/issues/11402 | Use shared pointer for wallet instances by promag · Pull Request #11402 · bitcoin/bitcoin · GitHub
< luke-jr> promag: you mean leave the wallet loaded, but invisible? that seems worst outcome IMO
< luke-jr> user may unload and just shut off the PC
< 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.
< luke-jr> yes
< promag> luke-jr: then the application will wait for wallets to unload
< jnewbery> I don't think we need to worry about unload at this stage. First step is add load functionality, then createwallet functionality
< luke-jr> and make it visible to the user in the meantime
< luke-jr> jnewbery: +1
< promag> wumpus: right, hence shared pointers
< wumpus> ok
< wumpus> any other topics? we've had the proposed ones
< luke-jr> gitian updates?
< luke-jr> seems we have at least a few things that need a newer VM
< luke-jr> not sure if there's anything to discuss tho
< wumpus> dunno if cfields is here, if not it makes little sense to discuss this I think
< cfields> sure
< wumpus> #topic gitian update
< wumpus> #12511 I guess
< gribble> https://github.com/bitcoin/bitcoin/issues/12511 | Switch to Ubuntu 18.04 for gitian building · Issue #12511 · bitcoin/bitcoin · GitHub
< wumpus> not sure what's there to discuss about it
< luke-jr> I guess we need a replacement for vmbuilder or something, since Canonical hasn't updated it to support anything recent :/
< cfields> ah, i didn't realize gitian couldn't handle it :(
< wumpus> debootstrap?
< luke-jr> debootstrap is a step in vmbuilder
< cfields> anyway, concept ack
< achow101> I'm considering adding docker support to gitian so we would use a default ubuntu docker image and then build from there
< wumpus> cool
< cfields> sgtm
< jcorgan> that would be nice
< wumpus> yes
< luke-jr> so KVM would no longer work?
< wumpus> heh if you make it work it will work
< luke-jr> Docker seems to just be a LXC wrapper
< achow101> Docker avoids all of the vm setup because someone else did that for us
< luke-jr> it's also x86-64 only
< wumpus> if vmbuilder or debootstrap does't work you could always manually install ubuntu to a base image I guess...
< jtimon> achow101: please, ping me for review if you do
< wumpus> but in my experience debootstrap works very well, though I've never used it for ubuntu on x86
< wumpus> I
< achow101> jtimon: sure
< wumpus> yes, I'm willing to test the docker stuff as well
< luke-jr> I suppose fixing vmbuilder might be not too unreasonable effort, maybe I will try that :/
< 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
< cfields> wumpus: yes, very much so.
< wumpus> great!
< wumpus> time to wrap up the meeting I think
< wumpus> unless someone has a quick topic
< wumpus> #endmeeting
< lightningbot> Meeting ended Thu Apr 12 19:56:11 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< 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 ?
< wumpus> sipa: it's fine, I just didn't know about that
< sipa> it's a feature i knew about for years, but always wondered about it usefulness
< wumpus> well this seems a good reason!
< 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..."
< promag> that was new to me too, but could drop the reference no?
< wumpus> I like the fact that this avoids having to export the type
< sipa> promag: no
< promag> right, doesn't work with base = extended..
< promag> sipa: could use your approach there right?
< promag> and turn g_wallet_init_interface to a reference instead?
< 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
< sipa> rather than exporting the DummySignatureCreator object itself (with a hidden type)
< sipa> hmm, perhaps
< wumpus> it will get sliced
< wumpus> if you don't make it a reference or pointer
< promag> I'll try the same with g_wallet_init_interface, don't think a pointer is good for such "central" instances
< wumpus> and a pointer would have the problem of needing a scoped ptr etc
< jonasschnelli> cfields: iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE was missing...
< cfields> jonasschnelli: aha :)
< wumpus> promag: why would that be any better though?
< wumpus> also the initialization/freeing order is less clear that way
< promag> I'm§ ~
< promag> \
< promag> ops, cat..
< promag> wumpus: not saying it's better, I prefer sipa approach
< wumpus> ok, sorry, I misunderstood you then
< 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()
< cfields> wouldn't surprise me if that's even more painful via Wine
< sipa> heh
< wumpus> whoops
< bitcoin-git> [bitcoin] Empact opened pull request #12969: Drop dead code CScript::Find (master...cscript-find) https://github.com/bitcoin/bitcoin/pull/12969
< bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/39439e5ab419...8480d41e0f9d
< bitcoin-git> bitcoin/master 190b8d2 Pieter Wuille: Make BaseSignatureCreator a pure interface
< bitcoin-git> bitcoin/master be67831 Pieter Wuille: Make DummySignatureCreator a singleton
< bitcoin-git> bitcoin/master 8480d41 Wladimir J. van der Laan: Merge #12803: Make BaseSignatureCreator a pure interface...
< bitcoin-git> [bitcoin] laanwj closed pull request #12803: Make BaseSignatureCreator a pure interface (master...201803_puresignaturecreator) https://github.com/bitcoin/bitcoin/pull/12803
< cfields> whoa
< cfields> Leaving test case "knapsack_solver_test"; testing time: 358694ms
< cfields> i386 + old wine ^^
< cfields> Leaving test case "knapsack_solver_test"; testing time: 6781ms
< cfields> ^^ same, but with the LogPrint commented out
< wumpus> now that's optimization
< wumpus> but I don't get it, it's the unit test, aren't all logging categories disabled?
< cfields> so, there's the recent huge slowdown. Probably also addressed in newer wine, hence the speedup in 12931
< cfields> wumpus: it's a LogPrintf :(
< wumpus> should it be in a debug category? sounds like an extremly high volume one
< cfields> wumpus: I think that test just hits it really hard
< cfields> it'd be nice to have an explicit no-logging option for these tests, though
< wumpus> if both log-to-file and log-to-console is disabled, it should probably bypass all logging
< wumpus> even without category
< 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?
< gribble> https://github.com/bitcoin/bitcoin/issues/11862 | Network specific conf sections by ajtowns · Pull Request #11862 · bitcoin/bitcoin · GitHub
< wumpus> so should that one be in high priority for review?
< 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
< 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
< jnewbery> I'd like to make some progress on config model. There have been a bunch of PRs around for months
< jtimon> yeah, I had a glance with the concept ack, should have another look
< jnewbery> #10267 is another one, but I think that should rebase on 11862, since 11862 seems like it's closer to merge
< gribble> https://github.com/bitcoin/bitcoin/issues/10267 | New -includeconf argument for including external configuration files by kallewoof · Pull Request #10267 · bitcoin/bitcoin · GitHub
< jnewbery> jtimon: I don't think this interacts badly with your 8994, so it shouldn't be blocked
< 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
< jtimon> and even if it implied a little bit more work on #8994 I don't think that's a blocking reason anyway
< gribble> https://github.com/bitcoin/bitcoin/issues/8994 | Testchains: Introduce custom chain whose constructor... by jtimon · Pull Request #8994 · bitcoin/bitcoin · GitHub
< jtimon> but I think it doesn't
< jnewbery> great!
< 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
< gribble> https://github.com/bitcoin/bitcoin/issues/8994 | Testchains: Introduce custom chain whose constructor... by jtimon · Pull Request #8994 · bitcoin/bitcoin · GitHub
< 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
< 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
< jtimon> perhaps a topic for another meeting
< wumpus> preferably that'd be avoided, as it makes it impossible to have a regtest with two different versions of bitcoind
< jtimon> wumpus: ok, thanks but moving all the python tests to custom/regtest2 is fine, right?
< wumpus> why?
< jtimon> ok, I think there's 2 parts to this PR, perhaps I should separate them
< 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
< jtimon> one is having custom params, but that can be done in regtest without changing the genesis block
< wumpus> for the existing tests, the current params don't need to be changed?
< 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)
< jtimon> right, but this opens the door to new tests
< 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)
< jtimon> wumpus: does that make sense to you? (or at least one of the parts)
< wumpus> yes for new tests that make use of different parameters it'd make sense
< jtimon> another recurrent topic is whether the custom params should be loaded from conf and the regular gArgs or only from an independent file
< 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
< wumpus> I'd say regular args would add too many arguments
< wumpus> this is only meant for testing, after all, so by far most will have no business overriding chain parameters
< 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
< jtimon> this would only override params for regtest and/or customchain, of course
< jtimon> CMainParams should not have an UpdateFromArgs method
< 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
< jtimon> or someone preferred regular args and conf file, I don't remember
< jtimon> wumpus: thanks for the feedback, so what do you think about separating it in 2? which part you think makes the most sense?
< jtimon> or can be more useful for tests we lack
< wumpus> yes, I think that makes sense
< instagibbs> listtransactions should list all transactions the wallet is involved in, yes? Including self-sends?
< instagibbs> sorry if #bitcoin, just getting odd results and help isn't clear
< sipa> yes
< instagibbs> thanks
< drexl> why does a scriptcode start with a PUSH byte? is it supposed to be pushed on the stack?