< achow101> are we having a meeting tomorrow?
< echeveria> 2017-12-28 02:49:21.589437 Reindexing block file blk00854.dat...
< echeveria> 2017-12-28 02:49:23.455371 LoadExternalBlockFile: Deserialize or I/O error - Read attempted past buffer limit: unspecified iostream_category error
< echeveria> eh?
< phantomcircuit> echeveria, disk failure i believe
< echeveria> looking at the block binaries there's a bunch which fell short of being full. maybe that happens during an unclean shutdown?
< phantomcircuit> shouldn't
< phantomcircuit> but i guess a very unclean shutdown could do that
< phantomcircuit> the blockindex won't point to those but the block file itself would have the partial write
< echeveria> I'll chalk that up to random corruption.
< karanlearns> hi
< karanlearns> when i run make - where is the so file bitcoin-qt generated . is it the one in /usr/bin or the one in src folder
< karanlearns> arubi: on running make where is the bitcoin-qt so file made ? is it in /usr/bin or the one in src folder ?
< luke-jr> karanlearns: user questions in #bitcoin
< karanlearns> luke-jr: i cannot join bitcoin channel, i get switched to bitcoin-unregistered although i have registered. this question is in continuation of my discussion from yesterday do - please accomodate.
< karanlearns> Hi
< karanlearns> I tried cd depends , make , cd root , configure prefix = depends build dir , make , I got this error - https://pastebin.com/H1h0z4wY
< luke-jr> karanlearns: you're not presently identified with NickServ
< luke-jr> karanlearns: and just because you might not have access to a better place to ask questions, does not justify asking them here
< karanlearns> rafalcpp: https://pastebin.com/H1h0z4wY
< karanlearns> luke-jr: sorry. please forgive.
< karanlearns> arubi: hey . i got this https://pastebin.com/H1h0z4wY
< sipa> karanlearns: not here, please
< zelest> morning
< bitcoin-git> [bitcoin] lionello opened pull request #12040: fix: add support for CORS headers and pre-flight request (master...http-options-pre-flight) https://github.com/bitcoin/bitcoin/pull/12040
< bitcoin-git> [bitcoin] Zelest opened pull request #12041: doc: Rewrite the OpenBSD build instructions (master...openbsd-build-revamp) https://github.com/bitcoin/bitcoin/pull/12041
< * zelest> hides in shame
< provoostenator> sipa: regarding #3220, rather than using a wallet, would it make sense to create a new persistent wallet-ish datastructure that is specifically designed to track a set of outputs?
< gribble> https://github.com/bitcoin/bitcoin/issues/3220 | Getrawtransaction working partially without -txindex is confusing · Issue #3220 · bitcoin/bitcoin · GitHub
< sipa> provoostenator: perhaps!
< sipa> sorry if i'm sounding grumpy there, but all these use cases assuming access to the historical blockchain at all is available kind of annoy me
< sipa> it's using the easy totally unscalable approach out of laziness
< provoostenator> I don't mind grumpiness. Just trying to figure out what the right division of labor should be between the Core node and layer 2 stuff.
< provoostenator> Especially if there's still an opportunity to get a small but useful change into 0.16 while Lightning is also still in alpha.
< provoostenator> I'm also still trying to understand what exactly these lightning implementations need that an unindexed node can't provide.
< sipa> i don't mind helping out - but relying on everyone indexing everything and keeping it around just to being able to query 2 transactions from it later
< sipa> seems a bit silly
< provoostenator> Especially if you already know the outputs to keep track of.
< provoostenator> Which by definition you do if you know which tx ids you want to track.
< provoostenator> Maybe this new data structure can watch for either outputs or specific transactions (don't know if the latter makes things easier).
< provoostenator> I also wonder how c-lightning works and if it really doesn't need txindex=1 (there's no getrawtransaction in the codebase). I'll take it for a spin.
< jb55> provoostenator: you have to paste the raw tx via the cli
< provoostenator> jb55: that's just for funding the wallet right, not for opening a channel and monitoring for unilateral close by the other side?
< provoostenator> jb55 let's head over to #c-lightning for those details...
< meshcollider> Is there a meeting today?
< jonasschnelli> no sure
< jonasschnelli> Wlad said he's gone this week
< jonasschnelli> We can start one if there are enough people around
< provoostenator> Such decentralized...
< jonasschnelli> :-)
< cfields> hi
< 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
< kanzure> hi.
< jonasschnelli> Should we cancel this weeks meeting? Seems not much people are around?
< meshcollider> Doesn't look promising, yeah
< achow101> Oh, there's a meeting?
< provoostenator> Or just keep it short if anyone has a topic? I don't.
< jonasschnelli> #startmeeting
< lightningbot> Meeting started Thu Dec 28 19:03:17 2017 UTC. The chair is jonasschnelli. Information about MeetBot at http://wiki.debian.org/MeetBot.
< lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
< cfields> maybe a quick 15min meeting? I have one short topic, at least
< achow101> Merge segwit wallet
< meshcollider> Ok :)
< jonasschnelli> cfields: you have the stage
< sipa> i'm at 34C3 with MarkoFalke and BlueMatt
< cfields> just an update on the codesigning. I've got the csr just about figured out, we should get going on the key creation in parallel
< jonasschnelli> #topic code signing
< jonasschnelli> cfields: can you write a short gist/docu how to proceed?
< cfields> ^^ is mainly aimed at gmaxwell, i guess
< achow101> Who are going to hold the keys?
< jonasschnelli> achow101: It will be distributed amoung some devs
< jonasschnelli> though, at least for apple, who ever holds the login access, can revoke and re-do the cert
< sipa> one step at a time
< jonasschnelli> So partially a clown show in terms of user security,.. though we should still do it
< cfields> jonasschnelli: as far as i can tell, we'll just need to use *procedure* for the setup, grab the pubkey, shove it into the csr, and submit to apple
< jonasschnelli> cfields: okay. Someone needs to coordinate whos going to create (be a part) a key and who does create the csr
< jonasschnelli> I can submit the csr and get back with the provisioning file, etc.
< * jonasschnelli> has no clue how to do this for windows signing cert
< cfields> jonasschnelli: i'm working on a quick prog to generate the csr from the pubkey, just have to work out exactly which parts get hashed
< provoostenator> Is this a threshold thing or do you need _all_ particpants for everything you do in the future?
< cfields> fyi, our cert expires on Jan 11, so the apple key is the priority
< jonasschnelli> provoostenator: it's a one time thing
< cfields> provoostenator: threshold
< jonasschnelli> cfields: oh. Yes. The expiration!
< jonasschnelli> So thanks then for beeing behind it.
< provoostenator> Happy to help geneate the key regardless.
< jonasschnelli> I expect the already signed binaries do still validate after jan 11th?
< cfields> jonasschnelli: if it's possible to have more than one at a time, it might be wise to go ahead and request one in only your name
< jonasschnelli> cfields: I can do that...
< cfields> then we could revoke it assuming we got the other one going
< meshcollider> Just in case we don't get it done in time?
< cfields> but that would save us in case we get tripped up and don't have it ready in time
< cfields> yea
< jonasschnelli> I think already signed binaries are not affected,... it's just the new 0.16 release that needs the new cert
< cfields> jonasschnelli: yes, they're timestamped
< jonasschnelli> So we need a cert for the 0.16 release... making one where I hold the key is a 5min thing... that's always possible
< cfields> jonasschnelli: great, thanks
< cfields> ok, that's all from me
< meshcollider> We could just release 0.16 before the 11th :)
< jonasschnelli> Other topics?
< jonasschnelli> meshcollider: heh.. yeah... but I'm happy if "Bitcoin Foundation" is gone in 0.16.
< jonasschnelli> I mean gone from our OSX/Windows binaries
< bitcoin-git> [bitcoin] jeromer opened pull request #12042: Add hdenabled flag in getwalletinfo (master...getwalletinfo/hdenabledflag) https://github.com/bitcoin/bitcoin/pull/12042
< meshcollider> jonasschnelli: yep :) no other topics from me
< jonasschnelli> [09:03:27] <achow101>Merge segwit wallet?
< cfields> jonasschnelli: oh, remind me and I'll sign some message with the old key containing the new pubkey
< jonasschnelli> I think that needs to wait until we BlueMatt's points have been worked out?
< jonasschnelli> cfields: Good point!
< jonasschnelli> cfields: where would you pubish that?
< provoostenator> If there's still a lot of outstanding issues, are there parts of that PR than can get merged earlier?
< cfields> jonasschnelli: we can stick it in git next to the new pubkey
< meshcollider> provoostenator: I think sipa wanted to leave most of the points raised for a follow-up PR yeah
< jonasschnelli> provoostenator: I need to catch up there,... I think at some point, a merge can be done even when there are some minor points to fix later
< jonasschnelli> I guess the main trigger for a merge is when BlueMatt's points are done (maybe they are already) and sipa thinks it's ready
< jonasschnelli> But that will happen next year
< jonasschnelli> (IMO)
< provoostenator> It might be easier to review if all the stuff that BlueMatt is already happy with can get merged earlier?
< sipa> i'd like an avkby BlueMatt
< sipa> *ack by
< jonasschnelli> sipa: yes. Agree
< provoostenator> But maybe that's impractical to tease apart.
< sipa> it could be merged commit by commit
< jonasschnelli> provoostenator: Yes. Involves some risks,.. and may need aditional reviews...
< sipa> though the biggest part is really just one commit
< provoostenator> Alright, giant atomic change it is :-)
< sipa> it's not giant by any metric
< jonasschnelli> Yes. Let's try to get an ack from BlueMatt, merge it in a whole, and do fixups later...
< jonasschnelli> Other topics?
< jonasschnelli> #endmeeting
< lightningbot> Meeting ended Thu Dec 28 19:19:15 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< * zelest> looks from the corner of the room
< cfields> thanks for taking the lead, jonasschnelli :)
< jonasschnelli> np
< achow101> do we know how/have software that can do more than just 3 of 3?
< achow101> the think that gmaxwell pointed me to only works for 3 of 3.
< jo__> hi
< jo__> anyone here
< sipa> no
< Chris_Stewart_5> -brought to you by sipabot(TM)
< zelest> hehe
< zelest> might be insulting to ask, but i'll ask anyway.. when is 0.16 scheduled to be released? :)
< Randolf> zelest: It will be released when it's ready.
< zelest> ah, the perfect answer. thanks :)
< bob___> o_O
< sipa> O_o
< warren> To whom it may concern, somebody wrote this in a random channel: "ehm, dunno if im right here, i stumbled upon a severe translation error in bitcoincoreWallet..at the transaction window, " abandon transaction" has been translated with " transaktion einstellen" - well this means exactly the opposite in german, something like: enter transaction into database,ledger - the better translation imo would be: " transaktion senden einstellen"...