1 2017-09-27 01:54:55	0|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.
 2 2017-09-27 05:31:40	0|esotericnonsense|whee. https://github.com/esotericnonsense/bitcoind-ncurses2
 3 2017-09-27 05:31:51	0|esotericnonsense|doesn't really do much yet but should be less buggy than the old gevent based thing. :)
 4 2017-09-27 05:33:30	0|Sentineo|ah!
 5 2017-09-27 05:33:37	0|Sentineo|will try esotericnonsense
 6 2017-09-27 05:34:27	0|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
 7 2017-09-27 05:35:26	0|Sentineo|to be honest i did not try the other one
 8 2017-09-27 05:35:39	0|Sentineo|so wkll not be biased ;)
 9 2017-09-27 05:36:14	0|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 ;)
10 2017-09-27 06:46:32	0|fanquake|achow101 is #10579 the first time you
11 2017-09-27 06:46:47	0|fanquake|'ve seen the whitespace linter masking another error?
12 2017-09-27 06:46:50	0|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
13 2017-09-27 12:27:26	0|bitcoin-git|13bitcoin/06master 14603efe9 15Pierre Rochard: Fix parameter name typo in ErasePurpose walletdb method.
14 2017-09-27 12:27:26	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/2505c5c0a9f8...69c7ecef405d
15 2017-09-27 12:27:27	0|bitcoin-git|13bitcoin/06master 1469c7ece 15MarcoFalke: Merge #11408: Trivial: Fix parameter name typo in ErasePurpose walletdb method...
16 2017-09-27 12:28:11	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #11408: Trivial: Fix parameter name typo in ErasePurpose walletdb method (06master...06walletdb-typo) 02https://github.com/bitcoin/bitcoin/pull/11408
17 2017-09-27 12:42:12	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/69c7ecef405d...ef8340d25f7c
18 2017-09-27 12:42:13	0|bitcoin-git|13bitcoin/06master 14d4cdbd6 15John Newbery: [rpc] Deprecate estimatefee RPC...
19 2017-09-27 12:42:14	0|bitcoin-git|13bitcoin/06master 14048e0c3 15Cristian Mircea Messel: [rpc] [tests] Add deprecated RPC test
20 2017-09-27 12:42:14	0|bitcoin-git|13bitcoin/06master 14ef8340d 15MarcoFalke: Merge #11031: [rpc] deprecate estimatefee...
21 2017-09-27 12:42:36	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #11031: [rpc] deprecate estimatefee (06master...06deprecate_estimatefee) 02https://github.com/bitcoin/bitcoin/pull/11031
22 2017-09-27 15:49:41	0|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
23 2017-09-27 16:25:42	0|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
24 2017-09-27 16:25:42	0|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
25 2017-09-27 16:25:43	0|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 ?
26 2017-09-27 16:25:55	0|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
27 2017-09-27 17:15:35	0|jnewbery|boltzar: please ask at #bitcoin or https://bitcoin.stackexchange.com/ . This is a channel for discussing Bitcoin Core development
28 2017-09-27 20:11:52	0|kebman|Can anyone guide me to good resources on how to programmatically sign messages with a Bitcoin address?
29 2017-09-27 20:12:19	0|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/
30 2017-09-27 20:12:35	0|kebman|Not sure what I'm doing wrong :p
31 2017-09-27 20:12:42	0|Dizzle|Made sure paste didn't have newlines/whitespace?
32 2017-09-27 20:13:05	0|kebman|pretty sure
33 2017-09-27 20:13:08	0|Dizzle|Or HTML/rich text if pasting into the browser
34 2017-09-27 20:13:20	0|kebman|Nope just pure text
35 2017-09-27 20:15:36	0|kebman|Any technical documentation on how Bitcoin signs messages?
36 2017-09-27 20:25:32	0|Dizzle|kebman: electrum's is fairly readable: https://github.com/spesmilo/electrum/blob/master/lib/bitcoin.py#L709
37 2017-09-27 20:26:32	0|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
38 2017-09-27 20:27:46	0|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.
39 2017-09-27 20:33:56	0|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
40 2017-09-27 20:35:16	0|kebman|Ow nice! :D
41 2017-09-27 20:36:12	0|BlueMatt|11309 looks merge-able
42 2017-09-27 20:38:24	0|BlueMatt|morcos: wanna close 9447 (superceded by 10984, which I'm rebasing now)
43 2017-09-27 20:44:50	0|kebman|Dizzle, yeah those links helps a lot! Thank you!
44 2017-09-27 20:45:15	0|Dizzle|You're welcome :)
45 2017-09-27 21:17:14	0|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?
46 2017-09-27 21:18:45	0|sipa|what does that even mean?
47 2017-09-27 21:18:57	0|sipa|bitcoind supports multisig, and supports HD derivation
48 2017-09-27 21:19:06	0|sipa|(though you need to use raw transaction api)
49 2017-09-27 21:20:04	0|sipa|oh, you mean the ability to watch for addresses that correspond to multisig of HD chains?
50 2017-09-27 21:20:16	0|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).
51 2017-09-27 21:20:31	0|wraithm|And yes, I'd only be interested in making these watch-only.
52 2017-09-27 21:20:48	0|wraithm|No signing, but maybe raw transaction construction.
53 2017-09-27 21:21:14	0|wraithm|Signing done offline and merging the signatures later
54 2017-09-27 21:21:25	0|sipa|sounds very useful, however it's very nontrivial with how core currently determines whether outputs belong to the local wallet
55 2017-09-27 21:21:40	0|sipa|there is a plan to significantly overhaul that, as it's getting more and more complicated
56 2017-09-27 21:23:37	0|wraithm|I don't know about how core determines what outputs belong to the local wallet. What's complicated about it?
57 2017-09-27 21:23:55	0|sipa|it pretty much sees if it can sign
58 2017-09-27 21:23:59	0|wraithm|Oh
59 2017-09-27 21:24:06	0|sipa|with various hacks... there are watch-only imported addresses
60 2017-09-27 21:24:10	0|sipa|but also imported public keys
61 2017-09-27 21:24:21	0|sipa|and then imported redeemscripts that are not automatically watch-only
62 2017-09-27 21:25:10	0|wraithm|What's involved in the overhaul plan? Some sort of address cache?
63 2017-09-27 21:26:39	0|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
64 2017-09-27 21:27:11	0|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)
65 2017-09-27 21:27:26	0|sipa|while importing watch-only keys just go into the watch set
66 2017-09-27 21:28:18	0|wraithm|Is it possible to have a watch-only HD wallet today, or does it require the overhaul?
67 2017-09-27 21:29:17	0|sipa|no, that's not possible
68 2017-09-27 21:29:44	0|sipa|it's not technically necessary to overhaul things to support that, but i'm very scared about complicating the current code further
69 2017-09-27 21:30:13	0|wraithm|Makes complete sense. It doesn't sound simple. Is anybody working on this separated set of scriptPubKeys rework?
70 2017-09-27 21:30:24	0|sipa|no, we're focussed on 0.15.1 for now
71 2017-09-27 21:46:56	0|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
72 2017-09-27 22:53:24	0|bitcoin-git|[13bitcoin] 15mess110 opened pull request #11410: [rpc] [tests] Add minrelaytxfee to getmempoolinfo (06master...06add_minrelaytxfee_to_getmempoolinfo) 02https://github.com/bitcoin/bitcoin/pull/11410