< achow101> Is this possibly a concern for us: https://meltdownattack.com/?
< achow101> At least it's certainly another reason to stop using Intel CPUs...
< TD-Linux> I don't think there are any obvious mitigations that bitcoin core can do that it doesn't already (like keeping unencrypted keys in memory for short times)
< promag> macos not affected?
< achow101> promag: it's a hardware bug, all OSes affected
< promag> sorry, there is "os x" reference there
< TD-Linux> apple has been silent so far. but you can assume that it's affected and not patched.
< promag> right
< achow101> "There are patches against Meltdown for Linux ( KPTI (formerly KAISER)), Windows, and OS X."
< phantomcircuit> TD-Linux, only thing to do is detect the failure and exit
< phantomcircuit> but even that is basically useless
< TD-Linux> all of the large VM providers are already patched, so I don't think there is any useful action to take.
< echeveria> TD-Linux: EC2 has scheduled forced reboots on the 5th.
< TD-Linux> I haven't gotten a notification for mine yet.
< megan_> Hi i am new baby in bitcoin development Please let me know how to get started in initial development
< promag> consider this: generate(20) -> invalidateblock(#10) -> invalidateblock(#5) -> reconsiderblock(#5)
< gribble> https://github.com/bitcoin/bitcoin/issues/10 | Add address to listtransactions output by gavinandresen · Pull Request #10 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/5 | Make the version number the protocol version and not the client version · Issue #5 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/5 | Make the version number the protocol version and not the client version · Issue #5 · bitcoin/bitcoin · GitHub
< promag> err
< promag> then getblockcount == 20
< promag> is this fine?
< megan_> promag: Thank you for support
< megan_> How to connect bitcoin exchange in open source any idea
< promag> megan_: wrong channel
< achow101> I'm slightly confused by hdmasterkeyid
< achow101> when I calculate the id of the master key I keep getting a different id than the one reported by the wallet
< megan_> promag: Please let me know what type of channel i need to follow
< megan_> Promag: Thank you very much for support i will read get back
< bitcoin-git> [bitcoin] promag opened pull request #12083: Improve getchaintxstats test coverage (master...2018-01-getchaintxstats) https://github.com/bitcoin/bitcoin/pull/12083
< promag> and #12083 btw
< gribble> https://github.com/bitcoin/bitcoin/issues/12083 | Improve getchaintxstats test coverage by promag · Pull Request #12083 · bitcoin/bitcoin · GitHub
< Satoshi> When are you going to release a fork to lower transaction fees...it's becoming useless
< molz> Satoshi, forks are useless, and you're in the wrong channel
< Randolf> Satoshi: I suggest asking about that in the #bitcoin channel.
< Satoshi> Any updates on lightning network?
< Onmylevel25> Help
< Onmylevel25> -
< Onmylevel25> I
< bitcoin-git> [bitcoin] jonasschnelli pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c991b304dee3...a1136f0cb449
< bitcoin-git> bitcoin/master 6dda059 251: [qt] Simplifies boolean expression model && model->haveWatchOnly()...
< bitcoin-git> bitcoin/master a1136f0 Jonas Schnelli: Merge #12074: [qt] Optimizes boolean expression model && model->haveWatchOnly()...
< bitcoin-git> [bitcoin] jonasschnelli closed pull request #12074: [qt] Optimizes boolean expression model && model->haveWatchOnly() (master...patch/TransactionView-optimize-boolean-expression) https://github.com/bitcoin/bitcoin/pull/12074
< bitcoin-git> [bitcoin] jonasschnelli pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/a1136f0cb449...eeb6d5271de3
< bitcoin-git> bitcoin/master 275b2ee William Casarin: [qt] change µBTC to bits...
< bitcoin-git> bitcoin/master ebcee1d William Casarin: bips: add bip176 (Bits Denomination)...
< bitcoin-git> bitcoin/master eeb6d52 Jonas Schnelli: Merge #12035: [qt] change µBTC to bits...
< bitcoin-git> [bitcoin] jonasschnelli closed pull request #12035: [qt] change µBTC to bits (master...qt-bits) https://github.com/bitcoin/bitcoin/pull/12035
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/eeb6d5271de3...a9a49e6e7e8d
< bitcoin-git> bitcoin/master aad3090 Jeff Rade: [rpc] Adding ::minRelayTxFee amount to getmempoolinfo and updating mempoolminfee help description
< bitcoin-git> bitcoin/master a9a49e6 Wladimir J. van der Laan: Merge #12001: [RPC] Adding ::minRelayTxFee amount to getmempoolinfo and updating help...
< bitcoin-git> [bitcoin] laanwj closed pull request #12001: [RPC] Adding ::minRelayTxFee amount to getmempoolinfo and updating help (master...update_mempoolminfee_help_details) https://github.com/bitcoin/bitcoin/pull/12001
< wumpus> BlueMatt: luke-jr: making the tarball include all git files was discussed a few files already, I think everyone is okay with that in principle, it's just hard to unify with the 'make dist' makefile-isms
< wumpus> *I mean not include the git files, but all files from the repository
< aj> wumpus: thoughts on getting #11796 merged?
< gribble> https://github.com/bitcoin/bitcoin/issues/11796 | [tests] Functional test naming convention by ajtowns · Pull Request #11796 · bitcoin/bitcoin · GitHub
< wumpus> aj: at the moment I'm trying to save #11403 from having to be rebased again by not merging any all-over-the-place changes/renames
< gribble> https://github.com/bitcoin/bitcoin/issues/11403 | SegWit wallet support by sipa · Pull Request #11403 · bitcoin/bitcoin · GitHub
< wumpus> but after that, sure
< * zelest> feels like he annoys laanwj :o
< wumpus> zelest: seems we just disagree
< zelest> Not saying my changes are correct, just explaining why I made them. :)
< bitcoin-git> [bitcoin] bodapanxu opened pull request #12087: mycoin (master...master) https://github.com/bitcoin/bitcoin/pull/12087
< bitcoin-git> [bitcoin] laanwj closed pull request #12087: mycoin (master...master) https://github.com/bitcoin/bitcoin/pull/12087
< wumpus> ^^ those kind of spurious PRs are the only kind that really annoy me
< zelest> I just wish to remove as much clutter as possible when it comes to documentations. :)
< zelest> hehe
< wumpus> I agree, but I don't think it's clutter, just try to move it to a place it won't be in the way when just following the guide
< wumpus> we don't have the capacity to act as tech support so anything that pre-empts issues that people might have is a win
< zelest> Yeah, but the clang thing.. why does the user need to know what the compiler is capable of since what version of openbsd? :)
< wumpus> you could shorten it, the point is that people are bound to forget the CC=cc CXX=c++ thing
< wumpus> if they do, they end up in a situation where e.g. berkeleydb is built using gcc, and bitcoind using clang
< wumpus> then they'll have linker errors
< zelest> hmms, yeah, true
< wumpus> the underlying issue is that openbsd 6.2 still has the gcc compiler, if it didn't, this wouldn't be an issue at all. Maybe for the next release it'll really go away?
< wumpus> but for now, as long as gcc 4.2 is still installed, we need it
< zelest> it will probably be there for quite some time
< zelest> the whole ports tree and all the different architectures they build on
< wumpus> and automake/autoconf tends to choose gcc over cc if it can
< wumpus> which is terrible in this specific case
< * zelest> nods
< zelest> yeah, i should've based my changes on your pull request, like you initially said...
< zelest> oh well, at least I've learned a bit more how github works now :)
< bitcoin-git> [bitcoin] bodapanxu opened pull request #12088: mycoin/dash (master...master) https://github.com/bitcoin/bitcoin/pull/12088
< wdev01> HELP
< * zelest> points at #bitcoin
< bitcoin-git> [bitcoin] fanquake closed pull request #12088: mycoin/dash (master...master) https://github.com/bitcoin/bitcoin/pull/12088
< aj> wumpus: sounds sensible :)
< wumpus> because of the spurious PRs I've blocked bodapanxu from the bitcoin org for now, please let me know
< wumpus> if he comes up with a valid reason then I'll remove them from the list again
< fazec> hey peeps
< fazec> I was trying to hard fork the main bitcoin chain today with https://github.com/SegwitB2X/bitcoin2x/ that fork
< fazec> I learned about syncing and forking at a certain height
< fazec> I specified the params in src/chainparams.cpp
< fazec> but still it's giving me a lot of errors such as 2018-01-04 12:07:30 ERROR: AcceptBlockHeader: Consensus:│ :ContextualCheckBlockHeader: 0000000000000000008c8f2437d│ 13a70632eb9e5ece259f2f96d03cac3ae5c84, not-hardfork, inc│ orrect block version (code 16)
< fazec> Anyone?
< wumpus> forks are offtopic here, try #bitcoin-forks
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/a9a49e6e7e8d...36a5a4404836
< bitcoin-git> bitcoin/master c9439e7 Akira Takizawa: [Trivial] Update license year range to 2018
< bitcoin-git> bitcoin/master 36a5a44 MarcoFalke: Merge #12063: [Trivial] Update license year range to 2018...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #12063: [Trivial] Update license year range to 2018 (master...2018-license) https://github.com/bitcoin/bitcoin/pull/12063
< Varunram> wumpus: What is the possibility of a testnet seed connecting to a bitcoin abc seed?
< Varunram> Asking this because I happened to connect to Peter Todd's seed and got redirected to an abc seed
< wumpus> redirected?
< wumpus> DNS seeds shouldn't redirect at all
< Varunram> hm, bad language on my part I guess. So a related question would be what actually happens when I try to connect to a testnet seed? (you can answer at #bitcoin if its off-topic :) )
< wumpus> in principle the DNS seeders should avoid reporting nodes that are on forks, but in the current implementation this is based on service bits, they don't actually (Afaik) check what chain they're on
< Varunram> oh, alright. Weird thing was it didn't spawn an error (might be someone messing with the banner). Our fault I guess. Thanks!
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #12089: qa: Don't remember TestNodeCLI options between calls (master...Mf1801-qaCliOptions) https://github.com/bitcoin/bitcoin/pull/12089
< fanquake> wumpus With the amount of forks I'm surprised we don't see more of those prs
< Varunram> fanquake: The problem is, anybody can compare the diffs and PR..
< Varunram> i.e. they needn't fork the fork's repo
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/36a5a4404836...ddff3447f29b
< bitcoin-git> bitcoin/master c99a3c3 Anthony Towns: [tests] util_tests.cpp: actually check ignored args...
< bitcoin-git> bitcoin/master ddff344 MarcoFalke: Merge #11997: [tests] util_tests.cpp: actually check ignored args...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #11997: [tests] util_tests.cpp: actually check ignored args (master...parseparam-fix) https://github.com/bitcoin/bitcoin/pull/11997
< luke-jr> why did Bech32 completely omit P2SH^2 stuff? :/
< sdaftuar> luke-jr: not sure if my memory is failing me, but i believe p2wsh uses a single sha256 of the script, no?
< sdaftuar> (anyway this is the first i've heard of the p2sh^2 idea, so i can't comment on your question generally)
< sipa> i don't think relying on relay policy to prevent data storage is very realistic
< sipa> at best it will make miners create websites where you can submit things
< luke-jr> relay+miner policy; realistic or not, having it as an option is helpful
< luke-jr> it might not help much with our current problems, but in the future it could become valuable
< luke-jr> sdaftuar: elaborated more on my bitcoin-dev post; from the BIP, it doesn't seem to use single SHA256
< sipa> luke-jr: it's also fundamentally incompatible with one of bech32's design goal: being forward compatible with future witness versions that may use dofferent hashing schemes
< sipa> *different
< luke-jr> sipa: but not forward compatible with this scheme :x
< luke-jr> what if we define the first decoded data value being 17 or 18, to P2SH^2 modes?
< luke-jr> or something like that
< sipa> meh, that would be possible, but won't be extensible to newer witness versions (which i exoect will be proposed soon anyway)
< luke-jr> could do 17 to indicate "additionally SHA256 hash", 18 to indicate "additionally RIPEMD160 hash", and then have a byte following it be the witness version
< luke-jr> ugh, GitHub requires JS for opening PRs :<
< promag> sipa: do you think it makes sense to return the number of processed characters in base_blob::SexHex?
< provoostenator> luke-jr: you could probably use the Github API
< promag> meeting?
< achow101> meeting?
< provoostenator> meeting?
< meshcollider> meeting?
< jonasschnelli> meeting?
< Chris_Stewart_5> fake news?
< jonasschnelli> Maybe wumpus is still on vacation...
< cfields> iirc he said he wouldn't be around for 2 meetings
< jonasschnelli> Okay... then lets start
< jonasschnelli> #startmeeting
< lightningbot> Meeting started Thu Jan 4 19:02:13 2018 UTC. The chair is jonasschnelli. Information about MeetBot at http://wiki.debian.org/MeetBot.
< lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
< jonasschnelli> Meeting request: 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
< jonasschnelli> Any topics?
< kanzure> hi.
< instagibbs> hi
< cfields> yet another quick codesigning update
< jonasschnelli> #topic code signing
< cfields> I've got the csr patching worked out, and gmaxwell is currently working on documenting the keygen process
< jonasschnelli> nice!
< cfields> Ideally we'd get that worked out in the next few days
< jonasschnelli> Good. I think there is no need for rush things,... ideally, we would have the new cert for the 0.16 (or say 16.) release
< cfields> jonasschnelli: is apple's signing process automated and pretty quick, i hope?
< achow101> Do we have a new Apple cert? It expires in a few days
< cfields> jonasschnelli: well the current cert expires on the 11
< jonasschnelli> cfields: once we have the csr, ... it's a matter of seconds
< meshcollider> achow101: we don't need it until 0.16
< jonasschnelli> achow101: expiring only matter for new binaries
< cfields> it's not a huge issue as we're not ready to release yet, ofc
< cfields> right
< achow101> meshcollider: jonasschnelli right, duh
< cfields> I'd still like to avoid a lapse if possible, though
< cfields> note that we also have the actual signing process to deal with
< jonasschnelli> yes. In "emergency" cases, we can still create a single-person RSA cert...
< achow101> although sooner is better. otherwise it becomes a release blocker
< cfields> luckily I hacked up the mac codesigner last year, but it needs a bit of polish
< jonasschnelli> achow101: Yes. Though we have the fallback doing the same as we already did (single person RSA cert)
< jonasschnelli> How about Windows?
< cfields> the only snag is that it doesn't handle timestamping. So worst-case, we may do a non-timestamped 0.16. It could be followed up with a timestamped release once that's worked out
< jonasschnelli> Timestamping of what?
< cfields> imo we should go ahead and do Windows once we've gone though the process for osx and identified the kinks
< jonasschnelli> I have no insights how Windows code signing works... but probably the same RSA approach could be taken, right?
< cfields> windows uses a free/open-source signer though, so that's no concern
< cfields> yea, ideally we'd use the same procedure for both
< * jonasschnelli> curses apple closed source signing
< cfields> it's possible that it's just an hour's worth of work. I just haven't looked into apple's timestamping mechanism yet
< cfields> ok, that's it from me
< jonasschnelli> thanks for the update! Thanks for working on this cfields
< jonasschnelli> Any other topics?
< achow101> coin selection
< Murch> Hi :)
< jonasschnelli> #topic coin selection (murchs algo)
< meshcollider> Perfect timing Murch ;)
< jonasschnelli> heh
< Murch> Highlight on "coin selection" ;)
< achow101> I'm not quite sure how to interpret the results
< achow101> but it basically looks like it performs no worse than the current algo
< jonasschnelli> Maybe Murch can comment on your results?
< achow101> It looks like it usually does slightly better since BnB is hit a small percentage of the time
< Murch> achow101: If you're only simulating flat fees the only thing that you're counting is the number of transactions that don't create a change output.
< achow101> Murch: I've only simulated flat fee so far. Maybe I should try it with somehow using mainnet fee estimation?
< Murch> achow101: What would be really interesting is whether the different selection algorithm has an impact on the cost in varying fee levels, because it could cause BnB to select more unspents at a higher fee level and fewer at a lower level, which would only be visible in a scenario of varying fee levels.
< achow101> If people would like to run their own simulations, the code for it is available here: https://github.com/achow101/bitcoin/tree/bnb-simulate. More info in this commnet: https://github.com/bitcoin/bitcoin/pull/10637#issuecomment-353452113
< Murch> That's at least my main concern in regard to deploying BnB.
< achow101> Murch: I did run the simulation at different flat fee rates
< provoostenator> Vaguely related question: is it possible to refactor the coin selection algo into a pure function that takes whatever info it needs (coins, mempool stats, etc) as input and returns the coins? That might make it easier to try different algos.
< achow101> *simulations
< Murch> achow101: Yes, I see that. But the selection effect would only be visible in a scenario with changing fees.
< jonasschnelli> provoostenator: also in the past, there where discussions about having multiple coin selection
< jonasschnelli> *selections
< provoostenator> Right, that would be the idea. Easier to add more experimental selection mechanisms.
< achow101> Murch: ah, right
< instagibbs> provoostenator, standard coin selection right now is a loopy affair, kind of complicated :/
< Murch> provoostenator: achow101's implementation does a big step in that direction .
< jonasschnelli> other topics?
< Murch> @achow101: The table seems to show only the final UTXO count, right?
< Murch> Interesting would also be the final balance of the wallet, especially in regard to the scenario with varying fee levels.
< achow101> Murch: it shows all of the same things that your simulation framework outputs
< achow101> I think
< achow101> It's a big table, you'll have to scroll
< Murch> Perhaps we could put our heads together in the next few days.
< achow101> ok
< Murch> Great work there, though thank you!
< jonasschnelli> Yes. Thanks achow101!
< Chris_Stewart_5> provoostenator: So basically you pass in a higher order function to the actual 'read from wallet' function
< jonasschnelli> Other topics?
< promag> merge fest?
< provoostenator> Maybe after SegWit UI is merged?
< promag> I'm talking about that one :)
< provoostenator> (I mean SegWit wallet)
< jonasschnelli> Soon. :)
< jonasschnelli> #endmeeting
< lightningbot> Meeting ended Thu Jan 4 19:24:02 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< meshcollider> Soon™
< provoostenator> promag: Oh ok, I thought you wanted to have everyone go through every open PR and see if it's close to mergeable...
< provoostenator> Which might be nice close to a release.
< achow101> provoostenator: we should do that too
< provoostenator> With one or two weeks for their respective authors to address remaining nits.
< BlueMatt> ugh, totally forgot today is meeting :/
< promag> BlueMatt: since you're there, #11041
< gribble> https://github.com/bitcoin/bitcoin/issues/11041 | Add LookupBlockIndex by promag · Pull Request #11041 · bitcoin/bitcoin · GitHub
< BlueMatt> yea, its on my queue :p
< promag> +1
< cfields> kanzure: heh, looks like saurik added osx signing to ldid ~the same day we discussed in the meeting here last year
< cfields> so we can cross that off the todo list :)
< phantomcircuit> i was busy sleeping
< kanzure> cfields: chalk this one up to teamwork and call it a day :P
< cfields> kanzure: nah, i'm chalking it up to you pinging him about it. So, thanks :)
< cfields> (and also to Cunningham's law, as my quick hacks probably made his eyes bleed)
< sipa> oops, i was timezone confused and missed it
< luke-jr> I thought we weren't having meetings during Christmas? :p
< Murch> no wonder the meeting was so short and few ;)
< Chris_Stewart_5> Murch: rekt! ;)
< instagibbs> luke-jr, when does Christmas end for you
< sdaftuar> sipa: any further thoughts (concept ack/nack) on whether you think #11739 is worth doing?
< gribble> https://github.com/bitcoin/bitcoin/issues/11739 | RFC: Enforce SCRIPT_VERIFY_P2SH and SCRIPT_VERIFY_WITNESS from genesis by sdaftuar · Pull Request #11739 · bitcoin/bitcoin · GitHub
< sdaftuar> if so i feel like next step would be for me to email the dev list and figure out a way to document this (maybe update one of the existing bips?)
< luke-jr> instagibbs: Jan 6 I think
< maxzor> Hello, pls bear with some chitchat :) do you have an estimate of the average concurrent nodes working on a given transaction? Of the blocks that are discarded (are they stored in the extensive ledger?) ?
< sipa> #bitcoin or bitcoin.stackexchange.com please
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #12089: qa: TestNodeCLI Rework output parsing, Prevent options mixups, Make command optional (master...Mf1801-qaCliOptions) https://github.com/bitcoin/bitcoin/pull/12089
< bitcoin-git> [bitcoin] 251Labs opened pull request #12092: [qt] Replaces numbered place marker %2 with %1. (master...patch/12015/sendcoinsdialog-replaces-numbered-place-marker) https://github.com/bitcoin/bitcoin/pull/12092
< phantomcircuit> batch rpc seems broken in master
< phantomcircuit> hmm maybe just for very large batches
< bitcoin-git> [bitcoin] practicalswift opened pull request #12093: Fix incorrect Markdown link (master...fix-incorrect-markdown-link) https://github.com/bitcoin/bitcoin/pull/12093
< phantomcircuit> i guess 500k is too many for a single batch
< bitcoin-git> [bitcoin] jonasschnelli opened pull request #12094: Fix hdmaster-key / seed-key confusion (master...2018/01/hdseed) https://github.com/bitcoin/bitcoin/pull/12094
< bitcoin-git> [bitcoin] jonasschnelli pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/ddff3447f29b...56910285fa4a
< bitcoin-git> bitcoin/master 4aa6455 practicalswift: Fix incorrect Markdown link
< bitcoin-git> bitcoin/master 5691028 Jonas Schnelli: Merge #12093: Fix incorrect Markdown link...
< bitcoin-git> [bitcoin] jonasschnelli closed pull request #12093: Fix incorrect Markdown link (master...fix-incorrect-markdown-link) https://github.com/bitcoin/bitcoin/pull/12093