1 2017-11-15 02:19:44	0|Tatty|I think I found an outdated version User Agent on Bitcoin Core 64 bit for Windows v0.15.0.1.  I enabled 2 tor proxies, both making bidirectional connections. It happened one of the proxies contacted the other, and that's when I saw a wrong version: User Agent /Satoshi:0.14.0/
  2 2017-11-15 02:20:29	0|sipa|why is that wrong?
  3 2017-11-15 02:21:03	0|Tatty|I am sure because I recognize the Hidden Service, of the income connection, it is mine
  4 2017-11-15 02:21:27	0|gmaxwell|Tatty: what reason do you have to believe it wasn't some other node connecting to you.
  5 2017-11-15 02:21:28	0|sipa|you can't know where an hidden service connection is coming from
  6 2017-11-15 02:21:56	0|gmaxwell|0.15.0.1 gives a correct useragent, so either that connection wasn't from you or you're not running what you think you are. :)
  7 2017-11-15 02:22:57	0|Tatty|it says on top via and then my hidden service
  8 2017-11-15 02:26:07	0|Tatty|is it possible the user agent is only wrong one one of them when using 2 tor proxies?
  9 2017-11-15 02:26:35	0|Tatty|and I am sorry for insisting
 10 2017-11-15 02:26:39	0|sipa|what do you mean by 2 tor proxies?
 11 2017-11-15 02:26:45	0|sipa|you can only configure oe
 12 2017-11-15 02:26:47	0|sipa|one
 13 2017-11-15 02:27:43	0|Tatty|I run 2 different ptor proxies as allowed by Bitcoin Core 0.15.0.1
 14 2017-11-15 02:28:03	0|sipa|what's your configuration like?
 15 2017-11-15 02:28:44	0|Tatty|no, I have 2 configured, running and one connecting to the other as I can only set 1 externalip=
 16 2017-11-15 02:29:14	0|sipa|i have no idea what you mean by that
 17 2017-11-15 02:29:19	0|sipa|can you paste your config somewhere?
 18 2017-11-15 02:31:27	0|Tatty|I try
 19 2017-11-15 02:50:59	0|Tatty|https://ibb.co/dqtWyR https://ibb.co/kX50sm
 20 2017-11-15 02:51:11	0|Tatty|screenshots
 21 2017-11-15 02:51:44	0|sipa|that means some Tor peer connected to you via Tor
 22 2017-11-15 02:52:03	0|sipa|using that ou26n... address (which is *your* onion address, not theirs)
 23 2017-11-15 02:52:12	0|Tatty|YES!
 24 2017-11-15 02:52:24	0|sipa|and *they* have user agent 0.14.0
 25 2017-11-15 02:52:26	0|Tatty|it is my hidden service
 26 2017-11-15 02:52:30	0|sipa|i know
 27 2017-11-15 02:52:42	0|sipa|but that address is the onion address they are connecting TO
 28 2017-11-15 02:52:50	0|sipa|i.e., yours
 29 2017-11-15 02:53:19	0|Tatty|no, they are conecting to the seconf one, managed by bitcoin-qt
 30 2017-11-15 02:53:34	0|sipa|that's not what it says
 31 2017-11-15 02:54:05	0|sipa|all i can see is an external peer connecting to you
 32 2017-11-15 02:54:39	0|Tatty|right
 33 2017-11-15 02:55:03	0|Tatty|I know it connected to the 2nd tor proxy
 34 2017-11-15 02:55:23	0|Tatty|by those phictures you can't know
 35 2017-11-15 02:55:33	0|sipa|then i can't help you
 36 2017-11-15 02:55:54	0|sipa|everything you're showing me just says there is some external peer running 0.14 that is connecting to you over tor
 37 2017-11-15 02:56:33	0|Tatty|do you really want me to post unsafe tor logs?
 38 2017-11-15 02:56:39	0|sipa|no
 39 2017-11-15 02:56:50	0|sipa|i want you to explain me why you think my theory is wrong
 40 2017-11-15 02:57:58	0|Tatty|because I know the hidden service on that picture in unkown to tor proxy #2
 41 2017-11-15 02:58:02	0|gribble|https://github.com/bitcoin/bitcoin/issues/2 | Long-term, safe, store-of-value · Issue #2 · bitcoin/bitcoin · GitHub
 42 2017-11-15 02:58:58	0|Tatty|and you see  a incoming connection via that hidden service
 43 2017-11-15 02:59:53	0|sipa|what do you mean by tor proxy 2
 44 2017-11-15 03:00:16	0|Tatty|ok, someone might be having some fun announcing my hidden service as being theirs, but the simplest solution is that tor proxy 1 contacted tor proxy 2
 45 2017-11-15 03:00:36	0|sipa|what do you mean by tor proxy 1 and tor proxy 2
 46 2017-11-15 03:01:40	0|Tatty|check the second picture, the one set for port 9150 instead of 9050
 47 2017-11-15 03:02:29	0|sipa|are those screenshots from the same client?
 48 2017-11-15 03:02:38	0|Tatty|https://ibb.co/kX50sm proxy on top = proxy 1, the other is proxy 2
 49 2017-11-15 03:03:35	0|Tatty|yes they are Ionly have this one
 50 2017-11-15 03:03:48	0|sipa|those settings are irrelevant
 51 2017-11-15 03:03:50	0|Tatty|and I never used any version prior to this
 52 2017-11-15 03:03:56	0|sipa|they're about outgoing connections
 53 2017-11-15 03:04:08	0|sipa|the peer screenshot is about an incoming connection
 54 2017-11-15 03:04:31	0|Tatty|correct
 55 2017-11-15 03:04:47	0|sipa|so i don't understand what the problem is
 56 2017-11-15 03:05:19	0|sipa|a random other peer on the internet connected to you over tor
 57 2017-11-15 03:05:28	0|sipa|those two proxy settings are not relevant
 58 2017-11-15 03:05:42	0|Tatty|incomming to the hidden service created by Bitcoin Core on tor proxy 2
 59 2017-11-15 03:05:57	0|Tatty|ok, I give up.
 60 2017-11-15 03:06:01	0|sipa|ok?
 61 2017-11-15 03:06:12	0|Tatty|sorry for taking your time
 62 2017-11-15 03:06:20	0|sipa|why is that not possible?
 63 2017-11-15 03:07:22	0|sipa|your bitcoin client rumours its addresses to other peers, including onion addresses if it knows th
 64 2017-11-15 03:07:47	0|sipa|some peer saw yours, and connected to you
 65 2017-11-15 03:08:05	0|Tatty|sipa, I can't make you understand
 66 2017-11-15 03:08:33	0|Tatty|one of my peers conected to one of my peers with the wrong User Agent
 67 2017-11-15 03:08:45	0|Tatty|putting it simple that is what happens
 68 2017-11-15 03:08:46	0|sipa|i see no evidence of that
 69 2017-11-15 03:09:04	0|Tatty|you keep telling me this setting doesn't work, but it does work
 70 2017-11-15 03:09:16	0|sipa|no, i'm saying this setting is not relevant
 71 2017-11-15 03:09:31	0|Tatty|proxy 1 doesn't accept any incoming connection as it doesn't have any hidden service
 72 2017-11-15 03:09:51	0|Tatty|only the second does and it is Bitcoin Core who creates it
 73 2017-11-15 03:10:00	0|sipa|ok
 74 2017-11-15 03:10:03	0|Tatty|now you say that is not possible
 75 2017-11-15 03:10:16	0|sipa|no, i'm saying that you're seeing an incoming connection
 76 2017-11-15 03:10:29	0|sipa|the settings you're showing me only affect outgoing connections
 77 2017-11-15 03:11:23	0|Tatty|proxy=127.0.0.1:9050 listen=1 bind=127.0.0.1 proxyrandomize=1 externalip=ou26nyghcyiwrecx.onion
 78 2017-11-15 03:11:33	0|Tatty|is this what you needed?
 79 2017-11-15 03:11:54	0|sipa|so, you configured your external address as ou26...
 80 2017-11-15 03:12:04	0|sipa|your bitcoin node rumoured that address around
 81 2017-11-15 03:12:10	0|sipa|and someone is connecting to it
 82 2017-11-15 03:12:30	0|sipa|the proxy setting does not matter, it changes how outgoing connections are made
 83 2017-11-15 03:13:08	0|Tatty|I see yur point
 84 2017-11-15 03:13:45	0|Tatty|Iam advertising a hidden service on the wrong tor proxy
 85 2017-11-15 03:14:22	0|sipa|it is advertized to all your peers, regardless of connection type
 86 2017-11-15 03:14:22	0|Tatty|You helped me very much
 87 2017-11-15 03:14:27	0|Tatty|thank you!
 88 2017-11-15 03:14:42	0|sipa|ok!
 89 2017-11-15 03:46:36	0|kallewoof|luke-jr: any idea what the error is for this BIP PR? https://travis-ci.org/bitcoin/bips/builds/302293555?utm_source=github_status&utm_medium=notification
 90 2017-11-15 03:46:45	0|kallewoof|I don't even see the error in that log.
 91 2017-11-15 03:56:31	0|meshcollider|kallewoof its something to do with that table diff, it runs scripts/buildtable.pl before and after your commit and then runs `if [ -n "$newdiff" ]; then echo "$newdiff"; exit 1;`
 92 2017-11-15 03:57:48	0|meshcollider|Should you add an entry to README.mediawiki?
 93 2017-11-15 04:05:35	0|kallewoof|Ohh, that is probably it yeah. Thanks!
 94 2017-11-15 04:51:37	0|kallewoof|That was it, yep. Thanks again.
 95 2017-11-15 04:53:49	0|meshcollider|Sweet :)
 96 2017-11-15 05:11:25	0|meshcollider|wumpus: https://github.com/bitcoin-core/bitcoincore.org/commit/ba1b4d6e97efead5f1bd0e6239b42c7faed0a4aa
 97 2017-11-15 05:38:07	0|eck|if any of you use fedora, I just set up a bitcoin rpm repo based mostly on the existing spec file in the contrib/ directory, feel free to help me test it or give me feedback: https://copr.fedorainfracloud.org/coprs/eklitzke/bitcoin/
 98 2017-11-15 06:44:50	0|wumpus|meshcollider: nice!
 99 2017-11-15 07:29:29	0|bitcoin-git|13bitcoin/06master 145ff01c2 15James O'Beirne: [docs] Add instructions for lcov coverage report generation
100 2017-11-15 07:29:29	0|bitcoin-git|[13bitcoin] 15jonasschnelli pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/3bdf242fc68a...4db82b7aab4a
101 2017-11-15 07:29:30	0|bitcoin-git|13bitcoin/06master 144db82b7 15Jonas Schnelli: Merge #11680: [docs] Add instructions for lcov report generation...
102 2017-11-15 07:30:02	0|bitcoin-git|[13bitcoin] 15jonasschnelli closed pull request #11680: [docs] Add instructions for lcov report generation (06master...06lcov-docs) 02https://github.com/bitcoin/bitcoin/pull/11680
103 2017-11-15 07:39:48	0|kallewoof|Man, running a full node with datadir on an external USB drive is really slow. Like, handshakes are timing out kind of slow.
104 2017-11-15 07:46:31	0|jonasschnelli|kallewoof: you could do a PR that would allow to keep the block files on a different "datadir"...
105 2017-11-15 07:46:34	0|jonasschnelli|That would be handy IMO
106 2017-11-15 07:46:59	0|jonasschnelli|Maybe only blocks older then 144+...
107 2017-11-15 07:47:12	0|kallewoof|Can't you just ln -s the blocks folder? I was thinking of doing that
108 2017-11-15 07:47:13	0|jonasschnelli|You want the UTXO/chainstate internal and the blocks external
109 2017-11-15 07:47:22	0|jonasschnelli|kallewoof: you can...
110 2017-11-15 07:47:26	0|jonasschnelli|but meh
111 2017-11-15 07:47:56	0|kallewoof|I actually think this might be a problem on my end, but not sure. It's way too slow to be normal behavior. I can't even addnode another full node on the same network. It times out.
112 2017-11-15 08:09:40	0|kallewoof|After running for awhile, things got faster. I don't know what was going on but it seems to have been temporary.
113 2017-11-15 08:11:10	0|jonasschnelli|kallewoof: anyways,.. that datadir split PR is still welcome. :)
114 2017-11-15 08:12:54	0|bitcoin-git|[13bitcoin] 15eklitzke opened pull request #11690: [trivial] Fix the StartupWMClass for bitoin-qt, so gnome-shell can recognize it (06master...06desktop-file) 02https://github.com/bitcoin/bitcoin/pull/11690
115 2017-11-15 08:13:18	0|kallewoof|OK! I'll see what I can do. :) Related: I wanted to make a PR that lets you have a readonly "cache" of the blockchain in a separate folder. You can spin up more than one node very easily without having to copy entire chain if you have access to the filesystem of the first one. Would be helpful for testing things I think.
116 2017-11-15 08:25:28	0|meshcollider|You can already move conf file with -conf and #11466 splits walletdir out so soon there'll be nothing left in the datadir itself ;)
117 2017-11-15 08:25:31	0|gribble|https://github.com/bitcoin/bitcoin/issues/11466 | Specify custom wallet directory with -walletdir param by MeshCollider · Pull Request #11466 · bitcoin/bitcoin · GitHub
118 2017-11-15 08:38:51	0|kallewoof|Huh... 2017-11-15 08:37:57       - Connect 1802 transactions: 156296.66ms (86.735ms/tx, 25.606ms/txin) [270.35s]
119 2017-11-15 08:40:28	0|kallewoof|WOuld this benefit from having only blocks on external drive? I am not sure what part of the fs is used for the tx connect stuff. *checking*
120 2017-11-15 08:43:25	0|wumpus|where you put chainstate is going to have the most influence there
121 2017-11-15 08:43:57	0|jonasschnelli|Yeah.. I guess the lag comes from leveldb internals
122 2017-11-15 08:43:59	0|wumpus|the blocks directory has the block data and block index, which are relatively rarely accessed (unless -txindex)
123 2017-11-15 08:44:19	0|kallewoof|Okay, testing ln -s solution to see if it helps.
124 2017-11-15 08:44:51	0|wumpus|(and unless you're reindexing, at which point it has to go through all blocks twice, but stilll chainstate drive will be much, much more busy)
125 2017-11-15 08:45:41	0|kallewoof|I'm not
126 2017-11-15 08:48:04	0|kallewoof|Yay! 2017-11-15 08:47:24       - Connect 2033 transactions: 2525.99ms (1.242ms/tx, 0.515ms/txin) [9.74s]
127 2017-11-15 08:50:53	0|jonasschnelli|kallewoof: that's with chainstate on internal drive an ln -s of your blocks to your ext drive?
128 2017-11-15 08:51:58	0|kallewoof|Yeah
129 2017-11-15 08:52:22	0|kallewoof|4.7GB on internal and the rest on external
130 2017-11-15 08:53:04	0|wumpus|nice!
131 2017-11-15 09:31:10	0|bitcoin-git|[13bitcoin] 15practicalswift opened pull request #11691: rpc: Add missing lock in getblocktemplate(...). Work around Clang thread safety analysis quirks. (06master...06rpc-locking) 02https://github.com/bitcoin/bitcoin/pull/11691
132 2017-11-15 09:36:53	0|wumpus|gah, we sould create a separate issue for WFL issues
133 2017-11-15 09:51:22	0|Guest27291|hi
134 2017-11-15 09:52:08	0|Guest27291|can someone confirm segiwit2x is still execute?
135 2017-11-15 09:52:34	0|timothy|Guest27291: OT
136 2017-11-15 09:52:44	0|meshcollider|Guest27291: this is not the place, but segwit2x was called off https://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/2017-November/000685.html
137 2017-11-15 09:53:23	0|Guest27291|thanks.. but i still heard a lot of rumour about segwit2x which is make me confuse
138 2017-11-15 09:53:56	0|meshcollider|You should probably discuss it in #bitcoin not this channel
139 2017-11-15 09:55:02	0|Guest27291|sorry.. thanks anyway
140 2017-11-15 09:55:38	0|meshcollider|No problem :)
141 2017-11-15 10:11:36	0|bitcoin-git|[13bitcoin] 15practicalswift opened pull request #11692: Remove unused Boost include. Move Boost include. (06master...06remove-boost-includes) 02https://github.com/bitcoin/bitcoin/pull/11692
142 2017-11-15 10:39:17	0|promag|meshcollider: hi
143 2017-11-15 10:39:27	0|meshcollider|promag: Hey :)
144 2017-11-15 10:39:38	0|promag|I'm not familiar with the dumpwallet test
145 2017-11-15 10:39:44	0|promag|let me read it
146 2017-11-15 10:40:18	0|meshcollider|The dumpwallet test basically counts the number of keys present in the file and makes sure that is the number that were generated in the wallet
147 2017-11-15 10:40:53	0|meshcollider|For the scripts part which I added, it relies on the comment to find which scripts correspond to which P2SH address we generated
148 2017-11-15 10:41:10	0|meshcollider|and then reimports to make sure the script was valid
149 2017-11-15 10:42:05	0|meshcollider|I'm looking into the GetAllReserveKeys() comment you wrote now, I'm unsure on that as I didn't change that part of it
150 2017-11-15 10:42:53	0|promag|+1 on the test
151 2017-11-15 10:43:05	0|promag|dunno why there is no lock in the RPC
152 2017-11-15 10:43:16	0|meshcollider|there is a lock on cs_wallet
153 2017-11-15 10:43:22	0|meshcollider|I commented on the PR, its on line 630
154 2017-11-15 10:43:45	0|meshcollider|https://github.com/bitcoin/bitcoin/pull/11667/files#diff-522490d83dce5375d423b23886e4125eR630
155 2017-11-15 10:44:02	0|meshcollider|Unless I misunderstood what you're referring to
156 2017-11-15 10:44:16	0|promag|f*** sorry!
157 2017-11-15 10:44:46	0|meshcollider|Heh all good :)
158 2017-11-15 10:44:57	0|promag|Missed one expand in gh
159 2017-11-15 10:45:54	0|meshcollider|So do you suggest modifying GetAllReserveKeys or is it ok since it is locked?
160 2017-11-15 10:46:23	0|meshcollider|This is the only place in the entire codebase which that function is called iirc
161 2017-11-15 10:46:38	0|promag|yes, it is fine the way it is
162 2017-11-15 10:46:45	0|meshcollider|Sweet, thanks :)
163 2017-11-15 10:57:07	0|meshcollider|promag: lol I like your thumbs_up reaction to that random "O" comment
164 2017-11-15 10:57:19	0|promag|hehe
165 2017-11-15 10:57:35	0|promag|meshcollider: I think you can remove ::GetCScripts
166 2017-11-15 10:57:56	0|promag|why not return a const reference to mapScripts?
167 2017-11-15 10:58:28	0|promag|that way you avoid a bunch of copies, set sorts and map lookups?
168 2017-11-15 10:59:05	0|meshcollider|mmm yeah true, that function is basically a C+P of CBasicKeyStore::GetKeys()
169 2017-11-15 11:00:21	0|meshcollider|Is there any disadvantage to that?
170 2017-11-15 11:00:48	0|promag|meshcollider: the only one I can see is that `cs_KeyStore` must be locked
171 2017-11-15 11:01:06	0|promag|while using/iterating the mapScripts
172 2017-11-15 11:01:52	0|promag|I would wait for someone with deeper knowledge there
173 2017-11-15 11:02:53	0|promag|but the idea is the same as GetAllReserveKeys()
174 2017-11-15 11:03:34	0|promag|but that one is protected by cs_wallet I think
175 2017-11-15 11:03:43	0|meshcollider|Yeah
176 2017-11-15 11:05:39	0|meshcollider|Ok maybe just post the idea on the PR so others can weigh in on it when they see it 👍
177 2017-11-15 11:09:47	0|bitcoin-git|[13bitcoin] 15practicalswift closed pull request #11692: Remove unused Boost include. Move Boost include. (06master...06remove-boost-includes) 02https://github.com/bitcoin/bitcoin/pull/11692
178 2017-11-15 11:11:20	0|kgc|Hi! I have a question, sorry for interrupting, is it planned in the foreseeable future to change signrawtransaction rpc method to successfully sign an output that was sent to a P2SH-P2WSH address? I tried doing so resulted in failure.
179 2017-11-15 11:24:34	0|wumpus|kgc: hrm, I think that should just work?
180 2017-11-15 11:31:11	0|meshcollider|kgc wumpus: yep should just work, tested on 0.15.0.1
181 2017-11-15 11:32:50	0|wumpus|thanks for testing meshcollider
182 2017-11-15 11:33:03	0|wumpus|kgc: so you need to be a bit more specific about the steps you followed and the result you get
183 2017-11-15 11:39:10	0|kgc|ok, I'll give you a json request I made, give me a sec
184 2017-11-15 11:40:21	0|kgc|{     "jsonrpc": "1.0",     "id": "requestId",     "method": "signrawtransaction",     "params": [         "0200000001d6b67546a418331a5e3877d103e7c95b2e0c69a2e289ddca75383dcca53128120100000000ffffffff0198929800000000001976a914423ffad905158d1d472f5fcd5fbc6916c2fb031f88ac00000000",         [             {                 "txid": "122831a5cc3d3875cadd89e2a2690c2e5bc9e703d177385e1a3318a44675b6d6",                 "vout": 1,
185 2017-11-15 11:40:50	0|kgc|ok, not the best idea...
186 2017-11-15 11:41:55	0|kgc|https://pastebin.com/2apuckBk
187 2017-11-15 11:41:59	0|wumpus|better use a pastebi.. yea
188 2017-11-15 11:45:01	0|kgc|this is the response from that request
189 2017-11-15 11:45:02	0|kgc|https://pastebin.com/SsszYS2w
190 2017-11-15 11:47:03	0|kgc|are there some undocumented parameters I should be passing in?
191 2017-11-15 11:52:27	0|wumpus|no, there are no further parameters. Sounds like the transaction is missing the witness somehow?
192 2017-11-15 12:02:59	0|meshcollider|oh hrm
193 2017-11-15 12:03:41	0|kgc|well, it's slightly weird because if I create corresponding deposit address and import it inside bitcoin core wallet, I can send to and spend funds without anyproblems
194 2017-11-15 12:04:50	0|meshcollider|Yeah that's what I thought you were asking about initially
195 2017-11-15 12:05:13	0|wumpus|it looks like the witness was stripped from the transaction
196 2017-11-15 12:06:43	0|meshcollider|Does signtrawtransaction need a witness transaction with empty witness?
197 2017-11-15 12:06:49	0|meshcollider|Or will it add the witness itself
198 2017-11-15 12:07:52	0|kgc|Hmm, are you suggesting that createrawtransaction method somehow cut out the witness part?
199 2017-11-15 12:09:38	0|meshcollider|createrawtransaction would not create a witness transaction because it would not know it was a P2WSH address would it
200 2017-11-15 12:10:39	0|kgc|yeah, sounds legit, are there any workarounds for this except for realizing serialization myself (which I would much rather avoid)
201 2017-11-15 12:11:02	0|meshcollider|Well it shouldn't be hard to make it into a witness transaction right
202 2017-11-15 12:11:35	0|meshcollider|`02000000000101d6b67546a418331a5e3877d103e7c95b2e0c69a2e289ddca75383dcca5312812010000002322002016a91e58e02069f95ea6defba7436199658573c34d384c69779779f4500d7cacffffffff0198929800000000001976a914423ffad905158d1d472f5fcd5fbc6916c2fb031f88ac0000000000`
203 2017-11-15 12:11:57	0|meshcollider|just added marker, flag and empty witness
204 2017-11-15 12:12:27	0|wumpus|it's strange if that is needed though
205 2017-11-15 12:12:37	0|meshcollider|indeed
206 2017-11-15 12:12:41	0|wumpus|so I think we're missing something
207 2017-11-15 12:16:36	0|meshcollider|Ideally signrawtransaction should just convert the raw transaction to a witness transaction itself if the input is a witness input right
208 2017-11-15 12:17:40	0|kgc|that would be the desired behavior I guess
209 2017-11-15 12:17:46	0|wumpus|maybe reading the test code helps: https://github.com/bitcoin/bitcoin/blob/master/test/functional/segwit.py
210 2017-11-15 12:18:01	0|wumpus|send_to_witness and create_witness_tx
211 2017-11-15 12:19:17	0|meshcollider|I looked into that, but there are no tests for P2SH-P2WSH it seems
212 2017-11-15 12:19:23	0|meshcollider|using signrawtransaction
213 2017-11-15 12:20:37	0|meshcollider|because L251-L264 notice that encode_p2sh is False
214 2017-11-15 12:25:22	0|meshcollider|Hmm actually how does it know what the redeemscript is for the P2WSH part
215 2017-11-15 12:25:33	0|meshcollider|you only pass in the P2SH redeemscript aye
216 2017-11-15 12:28:05	0|kgc|these are the parameters I've available: https://pastebin.com/TE1LrR44 should I be passing in as a redeem script something other than: 002016a91e58e02069f95ea6defba7436199658573c34d384c69779779f4500d7cac
217 2017-11-15 12:30:13	0|meshcollider|Yeah see you give it `002016a91e58e02069f95ea6defba7436199658573c34d384c69779779f4500d7cac` which is the redeemScript for the P2SH wrapper, but then it must not know what the redeemscript for the internal `16a91e58e02069f95ea6defba7436199658573c34d384c69779779f4500d7cac` is
218 2017-11-15 12:30:23	0|meshcollider|which is what hex=...
219 2017-11-15 12:30:32	0|meshcollider|but I don't know how to pass that in, no :/
220 2017-11-15 12:32:10	0|kgc|I'm confused, then what is it expecting as the redeem script parameter
221 2017-11-15 12:34:51	0|meshcollider|I would think what you did was correct, maybe it really isn't supported without importing the script into the wallet... I would wait for someone more experienced than me to say for sure though
222 2017-11-15 12:37:03	0|kgc|well the very least I got the address generation part right :D hopefully someone can shed some light on it, because implementing tx serialization/deserialization/signing and maintaining it would be painful for me
223 2017-11-15 12:37:31	0|kgc|then I might as well start contributing to bitcoinj project on my spare time (which I don't have)
224 2017-11-15 12:38:19	0|aj|MarcoFalke: #11646 was merged, so it shouldn't be labelled up for grabs, should it?
225 2017-11-15 12:38:21	0|gribble|https://github.com/bitcoin/bitcoin/issues/11646 | Require a steady clock for bench with at least micro precision by TheBlueMatt · Pull Request #11646 · bitcoin/bitcoin · GitHub
226 2017-11-15 12:39:10	0|meshcollider|aj: might be related to the comment
227 2017-11-15 12:39:44	0|kgc|should I open an issue on the github so it doesn't get lost?
228 2017-11-15 12:39:59	0|meshcollider|kgc: someone like sipa will probably be able to clarify things when he is online :)
229 2017-11-15 12:40:17	0|meshcollider|Yes I think an issue is a good idea
230 2017-11-15 12:40:38	0|kgc|ok, will do that, thank you for helping out :)
231 2017-11-15 12:42:50	0|meshcollider|There should be a way to pass scripts in as well as private keys
232 2017-11-15 12:46:09	0|meshcollider|kgc: in the mean time, you could just import the witness redeem script into your wallet I think :)
233 2017-11-15 12:52:48	0|wumpus|aj: I see now, it's merged but there was a mistake in it
234 2017-11-15 12:56:03	0|bitcoin-git|13bitcoin/06master 1463c2d83 15practicalswift: Explicitly state assumption that state.m_chain_sync.m_work_header != nullptr in ConsiderEviction...
235 2017-11-15 12:56:03	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/4db82b7aab4a...aca77a4d58c6
236 2017-11-15 12:56:04	0|bitcoin-git|13bitcoin/06master 14aca77a4 15Wladimir J. van der Laan: Merge #11655: net: Assert state.m_chain_sync.m_work_header in ConsiderEviction...
237 2017-11-15 12:56:38	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11655: net: Assert state.m_chain_sync.m_work_header in ConsiderEviction (06master...06m_chain_sync.m_work_header) 02https://github.com/bitcoin/bitcoin/pull/11655
238 2017-11-15 12:57:16	0|JackH|how can I dump privkey on segwit addresses? I get an error when doing dumpprivkey
239 2017-11-15 12:59:28	0|JackH|from the one topic I read, since it is a p2sh script, there is no address, thus I cannot dump privkey? but how can I otherwise get the privkey for the inputs?
240 2017-11-15 12:59:31	0|wumpus|you probably added the witness address using addwitnessaddress?
241 2017-11-15 12:59:43	0|wumpus|that won't add a private key
242 2017-11-15 13:00:39	0|JackH|so how do I get access to the inputs? basically I am looking to do a child pays for parent for some stuck txs
243 2017-11-15 13:00:47	0|JackH|and I wanted to import the privkey into electrum
244 2017-11-15 13:00:53	0|JackH|or is there a better way?
245 2017-11-15 13:02:15	0|wumpus|I think you need the address you called addwitnessaddress with, and use dumpprivkey with that
246 2017-11-15 13:10:09	0|wumpus|that would give you a private key, though importing it in other software is not going to be easy I expect, e.g. just importing the key isn't going to make it recognize the transaction
247 2017-11-15 14:05:05	0|was|hello
248 2017-11-15 14:05:18	0|was|is someone can help me ?
249 2017-11-15 14:05:49	0|wumpus|just ask your question in the channel and if someone can help you they'll answer (or tell you where it's better to ask it)
250 2017-11-15 14:06:08	0|was|i have a wallet btc core
251 2017-11-15 14:06:13	0|was|i save wallet.dat
252 2017-11-15 14:06:19	0|was|for change another pc
253 2017-11-15 14:06:31	0|was|now how can getback ?
254 2017-11-15 14:06:40	0|was|i have wallet.dat and my password
255 2017-11-15 14:10:24	0|was|you know ?
256 2017-11-15 14:12:06	0|sipa|try #bitcoin
257 2017-11-15 14:41:48	0|promag|Are CBlockTreeDB/CDBWrapper member functions thread safe?
258 2017-11-15 14:42:20	0|wumpus|no
259 2017-11-15 14:46:29	0|wumpus|though leveldb itself is thread safe
260 2017-11-15 14:47:22	0|wumpus|we make use of that only in one place, for the Cursor in GetUTXOStats, to iterate over a snapshot of the database while the rest of the process continues
261 2017-11-15 14:52:09	0|wumpus|but none of the caching and buffering we do on top of leveldb is thread-safe
262 2017-11-15 14:52:29	0|bitcoin-git|[13bitcoin] 15practicalswift closed pull request #11691: rpc: Add missing lock in getblocktemplate(...). Work around Clang thread safety analysis quirks. (06master...06rpc-locking) 02https://github.com/bitcoin/bitcoin/pull/11691
263 2017-11-15 14:57:12	0|promag|wumpus: ty
264 2017-11-15 15:21:27	0|bitcoin-git|[13bitcoin] 15practicalswift opened pull request #11694: rpc: Add missing cs_main lock in getblocktemplate(...) (06master...06missing-lock-in-getblocktemplate) 02https://github.com/bitcoin/bitcoin/pull/11694
265 2017-11-15 15:26:17	0|bitcoin-git|[13bitcoin] 15laanwj pushed 13 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/aca77a4d58c6...927a1d7d088e
266 2017-11-15 15:26:18	0|bitcoin-git|13bitcoin/06master 140343676 15Matt Corallo: Call TransactionRemovedFromMempool in the CScheduler thread...
267 2017-11-15 15:26:18	0|bitcoin-git|13bitcoin/06master 14a7d3936 15Matt Corallo: Add a CValidationInterface::TransactionRemovedFromMempool...
268 2017-11-15 15:26:19	0|bitcoin-git|13bitcoin/06master 142b4b345 15Matt Corallo: Add ability to assert a lock is not held in DEBUG_LOCKORDER
269 2017-11-15 15:26:28	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10286: Call wallet notify callbacks in scheduler thread (without cs_main) (06master...062017-01-wallet-cache-inmempool-4) 02https://github.com/bitcoin/bitcoin/pull/10286
270 2017-11-15 15:30:54	0|promag|is practicalswift around?
271 2017-11-15 16:14:40	0|gustav|hello
272 2017-11-15 16:16:14	0|promag|guess not
273 2017-11-15 16:16:29	0|promag|luke-jr: friendly reminder https://github.com/bitcoin/bitcoin/pull/11660#discussion_r150875214
274 2017-11-15 16:20:10	0|gustav|addr = addwitnessaddress($addr); to "move into segwit addresses usage"? if so would users be able to send to my app segwit address, and will my existing code be able to send payments to user addresses (non segwit and segwit)? thank you very much for all the work. now fees are insane this is why im asking. if wrong irc please tell me where to ask.
275 2017-11-15 16:20:10	0|gustav|i have one app where users are given 1 bitcoin address A, they deposit btc on A and later on they withdraw on their address B. I'd like to use segwit addresses to cut down expenses on network fees (if im getting this right). now i use getnewaddress, sendmany and rawtransactions functions. would it be possible to use $addr = getnewaddress(); $segwit
276 2017-11-15 16:21:55	0|gustav|reading online on stackoverflow and similar leads me to believe it can be done but im not sure about compatibility (user sends from non-segwit to segwit, needs to receive from segwit to non-segwit) and if addwitnessaddress is all i need. again thanks and sorry for wall of texts
277 2017-11-15 16:22:47	0|gustav|oopsie, using bitcoin-core latest version on linux (rpc, with php)
278 2017-11-15 16:57:51	0|sturles|Yes, this will make an address into a segwit address (P2SH-P2WPKH).  There are multiple kinds of segwit addresses.  To get the highest nenefit, you can make a P2PKWH address like this: addwitnessaddress($addr,true)
279 2017-11-15 16:58:31	0|sturles|The P2PKWH address will begin with bc1... (Bech32 format), and the sending wallet must be segwit aware to use it.
280 2017-11-15 16:59:27	0|sturles|You can only convert your own addresses.  Do not attempt to convert addresses you get from other people.
281 2017-11-15 17:15:35	0|BlueMatt|note to anyone with open wallet-rpc PRs: ##10286 will likely cause a silent conflict - you will need to add calls to BlockUntilSyncedToCurrentChain!
282 2017-11-15 17:15:39	0|gribble|https://github.com/bitcoin/bitcoin/issues/10286 | Call wallet notify callbacks in scheduler thread (without cs_main) by TheBlueMatt · Pull Request #10286 · bitcoin/bitcoin · GitHub
283 2017-11-15 17:52:46	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 4 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/927a1d7d088e...4ed818060ecf
284 2017-11-15 17:52:47	0|bitcoin-git|13bitcoin/06master 1437bdcca 15Russell Yanofsky: [refactor] Make feebumper namespace...
285 2017-11-15 17:52:47	0|bitcoin-git|13bitcoin/06master 147c4f009 15Russell Yanofsky: [trivial] Rename feebumper variables according to project code style...
286 2017-11-15 17:52:48	0|bitcoin-git|13bitcoin/06master 14aed1d90 15Russell Yanofsky: [wallet] Change feebumper from class to functions...
287 2017-11-15 17:53:01	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #10600: Make feebumper class stateless (06master...06pr/ipc-bump) 02https://github.com/bitcoin/bitcoin/pull/10600
288 2017-11-15 18:54:12	0|jonasschnelli|Thanks BlueMatt for the info
289 2017-11-15 19:10:41	0|luke-jr|BlueMatt: I wonder if there's a good way to make builds fail if they're incompatible
290 2017-11-15 19:10:50	0|luke-jr|though I can't think of anything obvious
291 2017-11-15 19:12:00	0|BlueMatt|I mean its kinda a manual thing to figure out if a given RPC needs the block
292 2017-11-15 19:40:14	0|luke-jr|BlueMatt: right, but we could fail everything until some change is made to indicate one way or the other
293 2017-11-15 19:42:02	0|BlueMatt|that seems like overkill? I mean as long as people pay attention when merging wallet rpc changes in the same way that we will need to in the future
294 2017-11-15 19:42:14	0|luke-jr|dunno
295 2017-11-15 19:42:27	0|luke-jr|incompatible changes breaking stuff is generally a good idea to avoid bug
296 2017-11-15 19:42:48	0|BlueMatt|I mean if you want to write one I'd be happy to see it, but I dont think its a huge risk
297 2017-11-15 19:42:53	0|BlueMatt|just gotta educate =D
298 2017-11-15 20:02:23	0|jonasschnelli|BlueMatt: re: https://github.com/bitcoin/bitcoin/pull/10387/commits/005fafdaa99b900d4a3ed0320e73e0a4863abf87
299 2017-11-15 20:03:10	0|jonasschnelli|Do you recommend to keep MayHaveUsefulAddressDB() as it is and add the HasAllDesirableServiceFlags() at another place?
300 2017-11-15 20:03:48	0|jonasschnelli|IMO NODE_NETWORK_LIMITED  should conform to MayHaveUsefulAddressDB()... or why not?
301 2017-11-15 20:04:11	0|BlueMatt|hmm?
302 2017-11-15 20:04:17	0|BlueMatt|yes, no, I was not objecting to the code changes there
303 2017-11-15 20:04:18	0|BlueMatt|at all
304 2017-11-15 20:04:35	0|BlueMatt|my complaint was about the commit message and the confusion it implies
305 2017-11-15 20:04:45	0|BlueMatt|an easy fix for which would be to change net_processing's addr handling
306 2017-11-15 20:05:05	0|BlueMatt|to check MayHaveUsefulAddressDB(services) || HasAllDesirableServiceFlags(services)
307 2017-11-15 20:05:15	0|BlueMatt|as the condition for getting an address into *our* addr db
308 2017-11-15 20:05:35	0|BlueMatt|(which, as indicated in the comment, would also not be a change in behavior, but it'd make things much clearer)
309 2017-11-15 20:07:06	0|jonasschnelli|I see..
310 2017-11-15 20:07:14	0|jonasschnelli|BlueMatt: but we should also do feeler to NODE_NETWORK_LIMITED, right?
311 2017-11-15 20:07:22	0|jonasschnelli|That's why I have changed MayHaveUsefulAddressDB()
312 2017-11-15 20:07:26	0|BlueMatt|correct
313 2017-11-15 20:07:44	0|BlueMatt|again, I think the *code* in that commit is right, the changes I was talking about would change no behavior against what you already have
314 2017-11-15 20:07:47	0|jonasschnelli|Okay with just rewording the commit message to mention the feeler thing?
315 2017-11-15 20:07:59	0|BlueMatt|wait, huh?
316 2017-11-15 20:08:05	0|BlueMatt|ohoh, yes
317 2017-11-15 20:08:19	0|BlueMatt|so the function is named MayHaveUsefulAddressDB because its primary use is "should i do a feeler to this connection"
318 2017-11-15 20:08:36	0|jonasschnelli|Or do you think adding "HasAllDesirableServiceFlags(services)" in net_processing would make the code more readable (not an acctual change)
319 2017-11-15 20:08:39	0|BlueMatt|the fact that acceptance into our addr db relies on that function is purely because its a superset of HasAllDesirableServiceFlags
320 2017-11-15 20:08:50	0|BlueMatt|my request was that you do both
321 2017-11-15 20:09:06	0|jonasschnelli|okay... got it
322 2017-11-15 20:13:22	0|jonasschnelli|BlueMatt: wait,... but HasAllDesirableServiceFlags() changes over time. Should we not add NODE_NETWORK_LIMITED to our addr man even during IBD?
323 2017-11-15 20:14:26	0|jonasschnelli|A check in net_processing (MayHaveUsefulAddressDB(services) || HasAllDesirableServiceFlags(services)) would lead to not adding NODE_NETWORK_LIMITED during IBD, right? Is that desirable?
324 2017-11-15 20:35:54	0|BlueMatt|jonasschnelli: I mean MayHaveUsefulAddressDB will always return true for either NODE_NETWORK{,_LIMITED}
325 2017-11-15 20:35:59	0|BlueMatt|jonasschnelli: so it should be fine?
326 2017-11-15 20:36:37	0|jonasschnelli|Yes. Your right...
327 2017-11-15 20:40:27	0|rabidus|no, that's your left
328 2017-11-15 20:40:35	0|rabidus|sry.
329 2017-11-15 20:41:40	0|sipa|it's your right to be left on the left
330 2017-11-15 20:41:51	0|sipa|sry.
331 2017-11-15 20:42:44	0|jonasschnelli|lol
332 2017-11-15 20:54:04	0|jonasschnelli|Anyone willing to review https://github.com/bitcoin/bitcoin/pull/11281/files?w=1 ?
333 2017-11-15 20:54:09	0|jonasschnelli|#11281
334 2017-11-15 20:54:12	0|gribble|https://github.com/bitcoin/bitcoin/issues/11281 | Avoid pemanent cs_main/cs_wallet lock during RescanFromTime by jonasschnelli · Pull Request #11281 · bitcoin/bitcoin · GitHub
335 2017-11-15 20:54:14	0|jonasschnelli|(use ?w=1)
336 2017-11-15 21:16:12	0|bitcoin-git|[13bitcoin] 15jnewbery opened pull request #11697: [trivial] remove trailing whitespace in streams.h (06master...06streams_trailing_whitespace) 02https://github.com/bitcoin/bitcoin/pull/11697
337 2017-11-15 21:16:19	0|meshcollider|wumpus: #11651 is ready to merge I think
338 2017-11-15 21:16:21	0|gribble|https://github.com/bitcoin/bitcoin/issues/11651 | refactor: Make all #includes relative to project root (laanwj, MeshCollider, ryanofsky) by MeshCollider · Pull Request #11651 · bitcoin/bitcoin · GitHub
339 2017-11-15 21:41:21	0|bitcoin-git|13bitcoin/06master 14b077fe9 15Evan Klitzke: fix the StartupWMClass for bitoin-qt, so gnome-shell can recognize it
340 2017-11-15 21:41:21	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/4ed818060ecf...f0c1f8abb018
341 2017-11-15 21:41:22	0|bitcoin-git|13bitcoin/06master 14f0c1f8a 15MarcoFalke: Merge #11690: [trivial] Fix the StartupWMClass for bitoin-qt, so gnome-shell can recognize it...
342 2017-11-15 21:41:56	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #11690: [trivial] Fix the StartupWMClass for bitoin-qt, so gnome-shell can recognize it (06master...06desktop-file) 02https://github.com/bitcoin/bitcoin/pull/11690
343 2017-11-15 22:07:18	0|bitcoin-git|[13bitcoin] 15lmlsna opened pull request #11698: [Docs] [Qt] RPC-Console nested commands documentation  (06master...06doc-rpc-console) 02https://github.com/bitcoin/bitcoin/pull/11698
344 2017-11-15 22:23:26	0|go1111111|I'm experiencing a fairly painful UX issue with Core. I'm probably "using it wrong", but I wanted to describe my problem in case it influences development, and also see if there's a workaround:
345 2017-11-15 22:25:00	0|go1111111|I have several different wallet files, with different passwords. I rename them 'wallet.dat' as needed. I also recently started pruning my node. These two things don't work together well, as whenever the node is given a wallet with new addresses and it thinks it might be missing info, it wants to re-download the entire blockchain
346 2017-11-15 22:25:43	0|go1111111|so, i essentially have to redownload and revalidate the entire blockchain for every wallet (it is possible to be smarter about this by taking snapshots, but it's cumbersome). Is there a workaround to that?
347 2017-11-15 22:26:14	0|sipa|are you using multiwallet? you can load all wallets at once
348 2017-11-15 22:28:28	0|bitcoin-git|[13bitcoin] 15jnewbery opened pull request #11699: [travis-ci] Only run linters on Pull Requests (06master...06lint_only_prs) 02https://github.com/bitcoin/bitcoin/pull/11699
349 2017-11-15 22:28:41	0|bitcoin-git|[13bitcoin] 15jnewbery closed pull request #11697: [trivial] remove trailing whitespace in streams.h (06master...06streams_trailing_whitespace) 02https://github.com/bitcoin/bitcoin/pull/11697
350 2017-11-15 22:28:52	0|go1111111|Oh, wasn't aware of that. I'll look into it -- thanks!   My other problem: I'm about 40% of the way through validating the blockchain, but all the inputs I want to spend have already been seen by the node, so I'd like to be able to broadcast a tx even though the node itself doesn't know that inputs are unspent. Is there a better way to do this other than using createrawtransaction?
351 2017-11-15 22:29:18	0|go1111111|I'd like to take advantage of the transaction construction of the UI to avoid errors, but also don't want to wait another 6 hours..
352 2017-11-15 22:30:00	0|sipa|you can construct a transaction as soon as your node knows about the outputs
353 2017-11-15 22:30:26	0|sipa|however, if you would construct a transaction that spends inputs which happen to be already spent in the chain, the result will be invalid (and you'll need to use abandontransaction to fix things)
354 2017-11-15 22:34:46	0|go1111111|interesting. that's how I wanted it to work, but when I construct my tx in the UI and click 'send', the UI doesn't respond at all. I expect to be prompted for my pw. Now that I know this is unexpected i'll try some variations to see if I can get it to work. thanks
355 2017-11-15 22:35:50	0|sipa|i'm unfamiliar with the GUI, but that does sound like a bug
356 2017-11-15 22:36:10	0|sipa|or at least something that requires more accurate information
357 2017-11-15 22:41:03	0|go1111111|it seems to relate to coin-control. I get the expected behavior when I don't manually select the inputs
358 2017-11-15 22:43:14	0|go1111111|wait no, that's wrong.. I'll be back when/if I have a proper bug report. thanks for the help.
359 2017-11-15 22:43:18	0|bitcoin-git|13bitcoin/06master 14ea3f363 15Matt Corallo: Make ISSUE_TEMPLATE a bit shorter, mention hardware tests
360 2017-11-15 22:43:18	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/f0c1f8abb018...54aedc013744
361 2017-11-15 22:43:19	0|bitcoin-git|13bitcoin/06master 1454aedc0 15MarcoFalke: Merge #11686: Make ISSUE_TEMPLATE a bit shorter, mention hardware tests...
362 2017-11-15 22:43:49	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #11686: Make ISSUE_TEMPLATE a bit shorter, mention hardware tests (06master...062017-11-shorter-default-issue) 02https://github.com/bitcoin/bitcoin/pull/11686