< promag> is #12194 something to go in the next version?
< gribble> https://github.com/bitcoin/bitcoin/issues/12194 | Add change type option to fundrawtransaction by promag · Pull Request #12194 · bitcoin/bitcoin · GitHub
< meshcollider> do we want #11708 in 0.16 as well for better P2SH-P2WSH support or no
< gribble> https://github.com/bitcoin/bitcoin/issues/11708 | Add P2SH-P2WSH support to signrawtransaction and listunspent RPC by MeshCollider · Pull Request #11708 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #12206: qa: Have wallet wait for TransactionAddedToMempool (master...Mf1801-qaWalletMempoolAsync) https://github.com/bitcoin/bitcoin/pull/12206
< meshcollider> poor travis is still having a rest
< bitcoin-git> [bitcoin] CryptAxe opened pull request #12207: Start renaming functional tests & update test runner (master...updateTests) https://github.com/bitcoin/bitcoin/pull/12207
< bitcoin-git> [bitcoin] CryptAxe closed pull request #12207: Start renaming functional tests & update test runner (master...updateTests) https://github.com/bitcoin/bitcoin/pull/12207
< bitcoin-git> [bitcoin] jonasschnelli pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/cad504bf4c30...062c8b69f4cc
< bitcoin-git> bitcoin/master 63ac890 Sjors Provoost: [qt] receive tab: bech32 address opt-in checkbox...
< bitcoin-git> bitcoin/master 062c8b6 Jonas Schnelli: Merge #11991: [qt] Receive: checkbox for bech32 address...
< bitcoin-git> [bitcoin] jonasschnelli closed pull request #11991: [qt] Receive: checkbox for bech32 address (master...segwit-qt-bech32-receive) https://github.com/bitcoin/bitcoin/pull/11991
< luke-jr> … that tooltip kinda sucks. people don't spend from addresses :/
< sipa> luke-jr: improve it!
< luke-jr> working on it ;)
< luke-jr> I wonder if there's a nicer name than "Bech32" to use here
< jonasschnelli> luke-jr: 11937 uses "Native SegWit (Bech32)"
< jonasschnelli> s/B/b
< luke-jr> sgtm
< jonasschnelli> sipa: since you have commented on #11281 (0.16 milestone), I'd like to see your ack there...
< gribble> https://github.com/bitcoin/bitcoin/issues/11281 | Avoid permanent cs_main/cs_wallet lock during RescanFromTime by jonasschnelli · Pull Request #11281 · bitcoin/bitcoin · GitHub
< sipa> jonasschnelli: about to pack and fly, but i'm fine with the split of the cs if it's documented
< jonasschnelli> sipa: Okay. No hurry... thanks
< bitcoin-git> [bitcoin] luke-jr opened pull request #12208: GUI: Rephrase Bech32 checkbox texts, and enable it with legacy address default (master...gui_legacy_bech32) https://github.com/bitcoin/bitcoin/pull/12208
< jonasschnelli> If someone wants Bech32, why override to OUTPUT_TYPE_P2SH_SEGWIT?
< sipa> meshcollider: can't do that right now (on phone)
< luke-jr> jonasschnelli: that's if the checkbox is unchecked
< luke-jr> if they have it set to Bech32, the checkbox is checked by default
< meshcollider> sipa: all good, sorry I posted that before I read your message about packing :)
< meshcollider> maybe jonasschnelli can then
< jonasschnelli> meshcollider: done
< luke-jr> should we bump libsecp256k1 for 0.16? not sure how big a deal the optimisations are
< sipa> i don't think there is anything very important
< jonasschnelli> luke-jr: I was just confuse that you called OUTPUT_TYPE_P2SH_SEGWIT legacy
< luke-jr> jonasschnelli: I did?
< jonasschnelli> <bitcoin-git>[bitcoin] luke-jr opened pull request #12208: GUI: Rephrase Bech32 checkbox texts, and enable it with legacy address default
< gribble> https://github.com/bitcoin/bitcoin/issues/12208 | GUI: Rephrase Bech32 checkbox texts, and enable it with legacy address default by luke-jr · Pull Request #12208 · bitcoin/bitcoin · GitHub
< luke-jr> jonasschnelli: that's referring to the ability to use Bech32, if your addresstype=legacy
< jonasschnelli> Ah.. now I see.
< luke-jr> jonasschnelli: squashed
< gmaxwell> sipa: https://github.com/bitcoin/bitcoin/pull/11991#issuecomment-357039103 < this QR encoded Bech32 address is apparently truncated in the QR code itself and it doesn't appear to be in allcaps.
< gmaxwell> oh, I see, it's regtest, that threw me.
< gmaxwell> but it still isn't allcaps and should be.
< gmaxwell> nevermind, I see there is a PR for that
< wumpus> only an issue
< gmaxwell> oh I see, issue. (ah, thats why I didn't previously see it on the PR list-- I was wondering how I missed it!)
< jonasschnelli> gmaxwell: The QRCode truncation should be fixed in master
< jonasschnelli> #12173
< gribble> https://github.com/bitcoin/bitcoin/issues/12173 | [Qt] Use flexible font size for QRCode image address by jonasschnelli · Pull Request #12173 · bitcoin/bitcoin · GitHub
< jonasschnelli> allcaps is a different thing
< gmaxwell> jonasschnelli: I was confused by the regtest prefix and thought the prefix was getting truncated.
< wumpus> probably want only the URL encoding to capitalize it, and not in other places like below the image
< gmaxwell> Personally I think allcaps monospace addresses usually look nicer, at least when presented in isolation. might want to look at it both ways before deciding.
< wumpus> but I think caps are wider so it'd have to use an even smaller font
< gmaxwell> they're the same size in monospace font.
< wumpus> yes
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/062c8b69f4cc...adce1de9a6ce
< bitcoin-git> bitcoin/master 49e5f3f Wladimir J. van der Laan: rpc: Add deprecation error for `getinfo`...
< bitcoin-git> bitcoin/master adce1de Wladimir J. van der Laan: Merge #12198: rpc: Add deprecation error for `getinfo`...
< bitcoin-git> [bitcoin] laanwj closed pull request #12198: rpc: Add deprecation error for `getinfo` (master...2018_01_getinfo_deprecation_message) https://github.com/bitcoin/bitcoin/pull/12198
< bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/adce1de9a6ce...c7978be89964
< bitcoin-git> bitcoin/master 0b63e3c Andrew Chow: Clamp walletpassphrase timeout to 2^(30) seconds and check its bounds...
< bitcoin-git> bitcoin/master 134cdc7 Andrew Chow: Test walletpassphrase timeout bounds and clamping
< bitcoin-git> bitcoin/master c7978be Wladimir J. van der Laan: Merge #12101: Clamp walletpassphrase timeout to 2^30 seconds and check its bounds...
< bitcoin-git> [bitcoin] laanwj closed pull request #12101: Clamp walletpassphrase timeout to 2^30 seconds and check its bounds (master...wallet-unlock-time-int32) https://github.com/bitcoin/bitcoin/pull/12101
< meshcollider> What actually needs to be done for #11048, since its in the 0.16 milestone
< gribble> https://github.com/bitcoin/bitcoin/issues/11048 | Weird gettransaction details on testnet with segwit · Issue #11048 · bitcoin/bitcoin · GitHub
< meshcollider> do the current PRs resolve that or does it still need work
< gmaxwell> I think thats a non-issue.
< gmaxwell> non-change send to selfs are not hidden.
< gmaxwell> otherwise a service with multiple users which sends funds on user commands would lose payments when one user sends to another user by address.
< luke-jr> I agree that looks as expected in RPC
< gmaxwell> (and 'custom change' to a non-change address is not treated as change)
< meshcollider> ok, wumpus or someone can remove it from the milestone then :)
< luke-jr> I really don't see the use case for 'custom change'.
< gmaxwell> I whined a bit about it when implemented. I could contrive up some for you, e.g. you're slowly migrating from one old wallet to a new one, and want all your change to go to the new one.
< gmaxwell> it's certantly an advanced feature.
< luke-jr> hmm, that's an interesting idea
< gmaxwell> I can't think of any other usecase.
< gmaxwell> oh sorry, I know another one but its bad.
< gmaxwell> E.g. user really insistant on keeping all their funds on a single address.
< gmaxwell> Which there can be justifications for, but they're still bad. :)
< wumpus> meshcollider: ok
< sipa> i can't ooen an issue now, but we should mark addwitnessaddress as deprecated
< gmaxwell> Does it do anything anymore?
< gmaxwell> meshcollider: I went and added some explination to that issue with the sends to self.
< meshcollider> gmaxwell: sounds good, thanks
< gmaxwell> meshcollider: thanks for bringing attention to it.
< sipa> gmaxwell: it probably at least resets the address label
< wumpus> something like #12210?
< gribble> https://github.com/bitcoin/bitcoin/issues/12210 | wallet: Deprecate addwitnessaddress by laanwj · Pull Request #12210 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] laanwj opened pull request #12210: wallet: Deprecate addwitnessaddress (master...2018_01_deprecate_addwitnessaddress) https://github.com/bitcoin/bitcoin/pull/12210
< meshcollider> ping kallewoof: are you going to reopen #11489 for 0.16?
< gribble> https://github.com/bitcoin/bitcoin/issues/11489 | [wallet] sendtoaddress style argument by kallewoof · Pull Request #11489 · bitcoin/bitcoin · GitHub
< meshcollider> to close #11134
< gribble> https://github.com/bitcoin/bitcoin/issues/11134 | Sendtoaddress flag for sending change to a segwit address? · Issue #11134 · bitcoin/bitcoin · GitHub
< meshcollider> wumpus: is that !IsDeprecatedRPCEnabled() stuff overkill for this case
< gmaxwell> probably, but uniformity is cheap.
< meshcollider> gmaxwell: I mean he hasn't currently used it, was wondering if that was a deliberate choice :)
< gmaxwell> ah!
< wumpus> meshcollider: how does that work?
< wumpus> FWIW I've added it to the release notes as well now
< meshcollider> wumpus: its the stuff which forces you to use -deprecatedrpc=addwitnessaddress argument to use it
< meshcollider> like estimatefee uses
< wumpus> oh I see, sure
< gmaxwell> might be premature to do that?
< gmaxwell> do we want it to immediately stop working without settings?
< gmaxwell> (I'm asking, no strong opinions)
< meshcollider> are we planning on removing it in 0.17?
< wumpus> I was assuming it would be removed in next major release, if not, should update the release notes :)
< meshcollider> It should be a trivial transition for most use cases I'd imagine, and it was always advertised as experimental so I'd say its fine how it is
< wumpus> waiting another release and going for 0.18 is fine with me too
< gmaxwell> yea, I suppose! if we're going to remove it in 0.17 then the disruptive choice is probably the right one.
< meshcollider> nah it shouldn't have gained enough use in this short timeframe to be necessary waiting another whole release
< meshcollider> i vote remove in 17
< gmaxwell> strangly I don't feel any cosmic force hurrying the removal of no-op RPCs. Perhaps one GOOD argument for going faster is this: people are going to keep following old "how to segwit" guides.
< wumpus> gmaxwell: which is another good reason to use the IsDeprecatedRPCEnabled() stuff, I guess, as otherwise it will seem to just keep working a s intended
< gmaxwell> yes, exactly, sorry "going faster" wasn't clear.
< meshcollider> yeah users tend to ignore help text even if it is in caps ;)
< gmaxwell> banner blindness.
< wumpus> well, more that they'll not look at the help if they 'help' is some online or wiki guide
< gmaxwell> right, which is why its important to fail. I would sort of like if in general we start breaking interfaces a little faster, at least until we cause complaints. we've gone to far in the never breaking things direction for too long. :) and IsDeprecatedRPCEnabled is a pretty nice middle ground.
< UnderDog_> good morning
< meshcollider> UnderDog_: maybe for some ;)
< UnderDog_> work got cancled today
< UnderDog_> bad freeze
< UnderDog_> i still woke up at 4am and so i decided to make a whiskey and do laundry
< UnderDog_> i haven't used IRC in almost 20 years
< meshcollider> UnderDog_: I think you might be in the wrong channel, maybe try #bitcoin for general discussion on it, this channel is just for bitcoin core development
< UnderDog_> well i'm not part of the development team but I did not see another IRC available and thought I might be likely to find similar persons of interest here.
< sipa> #bitcoin may be a better place
< UnderDog_> ok
< UnderDog_> only think I might be able to help with is thermodynamic's and heat extraction designs for your servers
< UnderDog_> no need ofr 's
< UnderDog_> for*
< waseem> /UNIGNORE a5m0
< Pritty_Kitty> Hello and thank you to all good Core developers for what you do.
< Pritty_Kitty> I'm trying to learn the system and use it but hope to get answer for a question:
< Pritty_Kitty> I have a 0.15.1 node with a "testnet=true" setting. getblocktemplate gives me a template where "txid" and "hash" field are identical for transaction.
< Pritty_Kitty> Should they not be different for SegWit is running on testnet?
< Pritty_Kitty> Will i use the "hash" field to create my witness hash tree and put a commit in my coinbase value? Do i put this commit value AFTER the BIP34 blockheight value?
< Pritty_Kitty> I am trying to make blocks.
< Pritty_Kitty> I want them SegWit compatible
< wxss> t
< Randolf> Pritty_Kitty: You seem to be asking a "how to use Bitcoin" type of question. You'll likely find that such questions are better suited for the #bitcoin channel as this one you're asking in now is specifically focused on Bitcoin core software development.
< Pritty_Kitty> No no i am a developer asking technical questions about bitcoin. I have built php code to deserialize transactions and build a merkle tree. Now i am working on the witness tree.
< Pritty_Kitty> But i could just mine regular blocks without SegWit. But I know you want SegWit so i hope for answers to my questions
< instagibbs> Pritty_Kitty, this isn't a question for Bitcoin Core development though. maybe #bitcoin-dev
< Pritty_Kitty> ok ty i will try there
< bitcoin-git> [bitcoin] ryanofsky opened pull request #12211: Avoid potential null dereference in ReceiveCoinsDialog constructor (master...pr/nullrecv) https://github.com/bitcoin/bitcoin/pull/12211
< jojeyh> Can anyboyd give me a brief explanation for "struct zero_after_free_allocator" ?
< jojeyh> What is the point of this object instead of a traditional std::allocator ?
< jojeyh> in file "bitcoin/src/support/allocators/zeroafterfree.h"
< luke-jr> jojeyh: std::allocator probably doesn't zero when freeing
< jojeyh> can you explain what this means?
< luke-jr> jojeyh: in other words, it leaves the data in memory
< luke-jr> which means when something else is allocated (hypothetically even in another program), it might have the data in its new memory
< jojeyh> luke-jr: ok, so basically if a std::allocator were used then even after the memory is freed the bits will still be nonzero ?
< luke-jr> right
< jojeyh> k thanks
< luke-jr> this is particularly bad if the memory might contain private key or passphrase info
< jojeyh> ah that makes sense
< bitcoin-git> [bitcoin] bitspill opened pull request #12212: fix spelling (master...patch-1) https://github.com/bitcoin/bitcoin/pull/12212
< mrannanay> #11227 seems to have both milestones covered. Needs rebase.
< gribble> https://github.com/bitcoin/bitcoin/issues/11227 | WIP: switch to libevent for node socket handling by theuni · Pull Request #11227 · bitcoin/bitcoin · GitHub
< promag> sipa: addmultisigaddress should have address_type option?
< bitcoin-git> [bitcoin] promag opened pull request #12213: 2018 01 addmultisigaddress address type (master...2018-01-addmultisigaddress-address-type) https://github.com/bitcoin/bitcoin/pull/12213