< jnewbery> promag: I think one key is enough, but I'm happy to review follow-up PRs if you feel strongly that more coverage is required.
< esotericnonsense> doesn't really do much yet but should be less buggy than the old gevent based thing. :)
< Sentineo> ah!
< Sentineo> will try esotericnonsense
< esotericnonsense> Sentineo: it has like 15% of the features of the other one. i just got tired of trying to figure out how to maintain the mess with this global state and all sorts of nonsense like that. :P
< Sentineo> to be honest i did not try the other one
< Sentineo> so wkll not be biased ;)
< Sentineo> today is my dev day, so will work on mine, too. finishing the workqueue to not kill bitcoind jn the process of fetching fee ;)
< fanquake> achow101 is #10579 the first time you
< fanquake> 've seen the whitespace linter masking another error?
< gribble> https://github.com/bitcoin/bitcoin/issues/10579 | [RPC] Split signrawtransaction into wallet and non-wallet RPC command by achow101 · Pull Request #10579 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/2505c5c0a9f8...69c7ecef405d
< bitcoin-git> bitcoin/master 603efe9 Pierre Rochard: Fix parameter name typo in ErasePurpose walletdb method.
< bitcoin-git> bitcoin/master 69c7ece MarcoFalke: Merge #11408: Trivial: Fix parameter name typo in ErasePurpose walletdb method...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #11408: Trivial: Fix parameter name typo in ErasePurpose walletdb method (master...walletdb-typo) https://github.com/bitcoin/bitcoin/pull/11408
< bitcoin-git> [bitcoin] MarcoFalke pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/69c7ecef405d...ef8340d25f7c
< bitcoin-git> bitcoin/master d4cdbd6 John Newbery: [rpc] Deprecate estimatefee RPC...
< bitcoin-git> bitcoin/master 048e0c3 Cristian Mircea Messel: [rpc] [tests] Add deprecated RPC test
< bitcoin-git> bitcoin/master ef8340d MarcoFalke: Merge #11031: [rpc] deprecate estimatefee...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #11031: [rpc] deprecate estimatefee (master...deprecate_estimatefee) https://github.com/bitcoin/bitcoin/pull/11031
< jl2012> gmaxwell: "technically we could make mainnet activate segwit at the same time as p2sh" not easy since miners included witness commitment before segwit activation. Those blocks are invalid under BIP141
< boltzar> hello guys. i have a small issue. i own an exchange website and i usually use bitcoind to send the bitcoin to my clients. With these problems in the bitcoin network sometimes i have activated these options walletrejectlongchains=false , limitancestorcount=1000 , limitdescendantcount=1000 . If i didn't activate these my api would stop working on 25 unconfirmed transactions . The issue
< boltzar> is: on my bitcoind server after i make 25 unconfirmed transactions they stop showing on blockchain.info for example untill they confirm ( the payments are made because i can see the tx hashes ) . Now i use another bitcoin api from block.io . Using their api i can make the same a lot of unconfirmed transactions , but their transactions are showing on blockchain.info even if there are
< boltzar> over 25. for example look here : https://blockchain.info/address/39RwB8D6fg8mA1m7VGAGobKRtZM1vHV99F?filter=7# . Currently 48 unconfirmed transactions. What do i have to activate on my bitcoind server so i can see all the tx hashes like on their api ?
< boltzar> to make it short. on block.io api i can see the entire long chain of 50 unconfirmed transactions and on my bitcoind api i can see only the first 25 even if i have 50 unconfirmed transactions
< jnewbery> boltzar: please ask at #bitcoin or https://bitcoin.stackexchange.com/ . This is a channel for discussing Bitcoin Core development
< kebman> Can anyone guide me to good resources on how to programmatically sign messages with a Bitcoin address?
< kebman> Or rather, I've managed to sign a message and locally validate it - but it won't validate on places like http://www.coinig.com/
< kebman> Not sure what I'm doing wrong :p
< Dizzle> Made sure paste didn't have newlines/whitespace?
< kebman> pretty sure
< Dizzle> Or HTML/rich text if pasting into the browser
< kebman> Nope just pure text
< kebman> Any technical documentation on how Bitcoin signs messages?
< Dizzle> kebman: electrum's is fairly readable: https://github.com/spesmilo/electrum/blob/master/lib/bitcoin.py#L709
< Dizzle> Alternatively, the Core RPC server and Qt GUI have implementations that use CHashWriter - https://github.com/bitcoin/bitcoin/blob/791a0e6ddade27d1b69f4861a6640de60b9553cf/src/wallet/rpcwallet.cpp#L609
< Dizzle> The "magic" phrase is just a salt that makes it hard for someone to trick you into signing a transaction disguised as a message.
< Dizzle> Not especially documented as its not so much a protocol feature as it is a wallet/site/whatever implementation feature. MultiBit started adding ASCII-compatible metadata armor and a lot of people think that's neat: https://multibit.org/help/hd0.3/sign-message.html
< kebman> Ow nice! :D
< BlueMatt> 11309 looks merge-able
< BlueMatt> morcos: wanna close 9447 (superceded by 10984, which I'm rebasing now)
< kebman> Dizzle, yeah those links helps a lot! Thank you!
< Dizzle> You're welcome :)
< wraithm> Just out of curiosity, what do people think about HD multisig? Specifically, what would you think about adding HD multisig wallet support to bitcoind? Is it a bad idea?
< sipa> what does that even mean?
< sipa> bitcoind supports multisig, and supports HD derivation
< sipa> (though you need to use raw transaction api)
< sipa> oh, you mean the ability to watch for addresses that correspond to multisig of HD chains?
< wraithm> I mean at the same time. Specifically, imagine swaping a bunch of xpubs around, deriving the same paths, making multisig addresses for all of them (all with the same thresholds, storing the redeem scripts, etc).
< wraithm> And yes, I'd only be interested in making these watch-only.
< wraithm> No signing, but maybe raw transaction construction.
< wraithm> Signing done offline and merging the signatures later
< sipa> sounds very useful, however it's very nontrivial with how core currently determines whether outputs belong to the local wallet
< sipa> there is a plan to significantly overhaul that, as it's getting more and more complicated
< wraithm> I don't know about how core determines what outputs belong to the local wallet. What's complicated about it?
< sipa> it pretty much sees if it can sign
< wraithm> Oh
< sipa> with various hacks... there are watch-only imported addresses
< sipa> but also imported public keys
< sipa> and then imported redeemscripts that are not automatically watch-only
< wraithm> What's involved in the overhaul plan? Some sort of address cache?
< sipa> yes, have a separated set of scriptPubKeys to watch for (perhaps using a bloom filter), independent from what we know how to sign for
< sipa> and then known HD chains can feed both into what to watch for and what to sign for (if it's a private chain)
< sipa> while importing watch-only keys just go into the watch set
< wraithm> Is it possible to have a watch-only HD wallet today, or does it require the overhaul?
< sipa> no, that's not possible
< sipa> it's not technically necessary to overhaul things to support that, but i'm very scared about complicating the current code further
< wraithm> Makes complete sense. It doesn't sound simple. Is anybody working on this separated set of scriptPubKeys rework?
< sipa> no, we're focussed on 0.15.1 for now
< instagibbs> wraithm, https://github.com/bitcoin/bitcoin/pull/9728 does hd watchonly, but as sipa said, how it interacts with stuff is non-trivial. I think a lot of the corner-cases go away post-overhaul
< bitcoin-git> [bitcoin] mess110 opened pull request #11410: [rpc] [tests] Add minrelaytxfee to getmempoolinfo (master...add_minrelaytxfee_to_getmempoolinfo) https://github.com/bitcoin/bitcoin/pull/11410