12017-09-20T00:02:18  *** jannes has quit IRC
  22017-09-20T00:03:15  *** StopAndDecrypty has joined #bitcoin-core-dev
  32017-09-20T00:03:32  *** StopAndDecrypt has quit IRC
  42017-09-20T00:03:47  *** StopAndDecrypty is now known as StopAndDecrypt
  52017-09-20T00:33:09  *** Murch has quit IRC
  62017-09-20T00:36:41  *** promag has quit IRC
  72017-09-20T00:46:26  *** promag has joined #bitcoin-core-dev
  82017-09-20T00:48:51  *** Ylbam has quit IRC
  92017-09-20T00:50:28  *** promag has quit IRC
 102017-09-20T01:06:02  *** dabura667 has joined #bitcoin-core-dev
 112017-09-20T01:14:23  <btcdrak> gmaxwell:  We can try again with the security@ email address. I have limited internet access today so cant do it.
 122017-09-20T01:15:04  *** chjj has joined #bitcoin-core-dev
 132017-09-20T01:16:26  <bitcoin-git> [bitcoin] sipa opened pull request #11372: Address encoding cleanup (master...201709_addr_cleanup) https://github.com/bitcoin/bitcoin/pull/11372
 142017-09-20T01:51:33  *** RubenSomsen has joined #bitcoin-core-dev
 152017-09-20T01:53:24  *** chjj has quit IRC
 162017-09-20T01:56:38  *** chjj has joined #bitcoin-core-dev
 172017-09-20T02:01:54  *** chjj has quit IRC
 182017-09-20T02:02:27  *** chjj has joined #bitcoin-core-dev
 192017-09-20T02:10:32  *** justanotheruser has joined #bitcoin-core-dev
 202017-09-20T02:13:50  *** chjj has quit IRC
 212017-09-20T02:16:11  *** nioc has left #bitcoin-core-dev
 222017-09-20T02:18:53  *** nickler has quit IRC
 232017-09-20T02:19:30  *** nickler has joined #bitcoin-core-dev
 242017-09-20T02:28:23  *** Murch has joined #bitcoin-core-dev
 252017-09-20T02:39:17  *** dabura667_ has joined #bitcoin-core-dev
 262017-09-20T02:42:58  *** dabura667 has quit IRC
 272017-09-20T02:43:52  *** dabura667_ has quit IRC
 282017-09-20T02:57:35  *** StopAndDecrypt has quit IRC
 292017-09-20T02:57:59  *** StopAndDecrypt has joined #bitcoin-core-dev
 302017-09-20T03:09:53  *** PRab has joined #bitcoin-core-dev
 312017-09-20T03:19:36  *** StopAndDecrypty has joined #bitcoin-core-dev
 322017-09-20T03:20:03  *** StopAndDecrypt has quit IRC
 332017-09-20T03:23:10  *** Giszmo has quit IRC
 342017-09-20T03:23:41  *** wxxs has quit IRC
 352017-09-20T03:46:31  *** promag has joined #bitcoin-core-dev
 362017-09-20T03:47:32  *** Giszmo has joined #bitcoin-core-dev
 372017-09-20T03:50:56  *** promag has quit IRC
 382017-09-20T04:34:05  *** jtimon has quit IRC
 392017-09-20T04:47:19  *** jtimon has joined #bitcoin-core-dev
 402017-09-20T04:48:16  *** dabura667 has joined #bitcoin-core-dev
 412017-09-20T04:54:58  *** RubenSomsen has quit IRC
 422017-09-20T04:59:18  *** harrymm1 has quit IRC
 432017-09-20T04:59:49  *** harrymm1 has joined #bitcoin-core-dev
 442017-09-20T05:00:05  *** harrymm has quit IRC
 452017-09-20T05:00:33  *** harrymm has joined #bitcoin-core-dev
 462017-09-20T05:45:16  *** pbase has joined #bitcoin-core-dev
 472017-09-20T05:58:08  *** jtimon has quit IRC
 482017-09-20T06:28:11  <kallewoof> achow101: the approach given in the doc I linked is outdated, then? I could write/update docs, but I'm honestly stumped on how to approach this. E.g. I am supposed to give a signer, but I don't want to shuffle private GPG keys around to let the VM sign using a key it doesn't hold (I am guessing wildly here).
 492017-09-20T06:32:46  <esotericnonsense> kallewoof: there's a section in gitian-building.md that references copying out the assert files?
 502017-09-20T06:35:40  <esotericnonsense> (missed most of the conversation, just guessing here)
 512017-09-20T06:46:43  *** BashCo has quit IRC
 522017-09-20T07:05:13  *** tknp has quit IRC
 532017-09-20T07:07:11  <kallewoof> esotericnonsense: I don't think I saw that. Will look, thanks!
 542017-09-20T07:07:34  <esotericnonsense> :) right at the bottom
 552017-09-20T07:08:13  <kallewoof> Ahh, yeah, I missed that completely. Thanks
 562017-09-20T07:15:34  *** BashCo has joined #bitcoin-core-dev
 572017-09-20T07:18:50  <bitcoin-git> [bitcoin] Reagent1981 opened pull request #11374: 0.15 (master...0.15) https://github.com/bitcoin/bitcoin/pull/11374
 582017-09-20T07:19:23  <bitcoin-git> [bitcoin] fanquake closed pull request #11374: 0.15 (master...0.15) https://github.com/bitcoin/bitcoin/pull/11374
 592017-09-20T07:24:01  *** promag has joined #bitcoin-core-dev
 602017-09-20T07:25:49  *** timothy has joined #bitcoin-core-dev
 612017-09-20T07:27:55  *** promag has quit IRC
 622017-09-20T07:27:59  *** Ylbam has joined #bitcoin-core-dev
 632017-09-20T07:46:11  *** promag has joined #bitcoin-core-dev
 642017-09-20T07:50:55  *** promag has quit IRC
 652017-09-20T07:52:31  *** RubenSomsen has joined #bitcoin-core-dev
 662017-09-20T08:01:17  *** laurentmt has joined #bitcoin-core-dev
 672017-09-20T08:03:58  *** JackH has joined #bitcoin-core-dev
 682017-09-20T08:07:35  *** meshcollider has quit IRC
 692017-09-20T08:08:35  *** tErik_mc has quit IRC
 702017-09-20T08:21:27  *** PaulCapestany has quit IRC
 712017-09-20T08:33:25  *** PaulCapestany has joined #bitcoin-core-dev
 722017-09-20T08:35:03  *** Geoffy has joined #bitcoin-core-dev
 732017-09-20T08:43:12  *** Aaronva__ has quit IRC
 742017-09-20T08:44:05  *** promag has joined #bitcoin-core-dev
 752017-09-20T08:49:45  <kallewoof> Reading the OP_RETURNTRUE discussion on bitcoin-dev it struck me that if we bump segwit script version at some point, old nodes will all accept the tx without looking, and new nodes will use the new script to verify. A miner running old version could mine txs with invalid scripts and old nodes would accept this block while new nodes would not. This would become a hardfork, no?
 762017-09-20T08:51:07  <kallewoof> Wait, no, it would become a softfork. *headscratch*
 772017-09-20T08:51:46  <kallewoof> I'm confused about Johnson Lau's statement "If we use a softfork to transform OP_RETURNTRUE into OP_17 (pushing the number 17 to the stack), new nodes will collect the (pubkey, message) pair and try to aggregate with other pairs. This becomes a hardfork.
 782017-09-20T08:51:51  <kallewoof> "
 792017-09-20T08:53:19  <kallewoof> Old nodes all accept, new nodes do more. It should be a softfork, no?
 802017-09-20T08:56:01  *** meshcollider has joined #bitcoin-core-dev
 812017-09-20T08:56:06  *** PaulCapestany has quit IRC
 822017-09-20T08:59:06  *** vicenteH has joined #bitcoin-core-dev
 832017-09-20T08:59:10  *** AaronvanW has joined #bitcoin-core-dev
 842017-09-20T09:01:25  *** Guyver2 has joined #bitcoin-core-dev
 852017-09-20T09:16:06  *** drizztbsd has joined #bitcoin-core-dev
 862017-09-20T09:16:12  *** timothy has quit IRC
 872017-09-20T09:17:31  *** drizztbsd is now known as timothy
 882017-09-20T09:17:48  *** PaulCapestany has joined #bitcoin-core-dev
 892017-09-20T09:34:28  *** PaulCapestany has quit IRC
 902017-09-20T09:43:31  *** PaulCapestany has joined #bitcoin-core-dev
 912017-09-20T09:57:18  *** wxxs has joined #bitcoin-core-dev
 922017-09-20T10:00:46  *** Victor_sueca has joined #bitcoin-core-dev
 932017-09-20T10:03:12  *** Victorsueca has quit IRC
 942017-09-20T10:08:19  <luke-jr> kallewoof: he's talking about after some hypothetical signature aggregation scheme
 952017-09-20T10:08:23  <luke-jr> I'm not convinced it's a real blocker
 962017-09-20T10:09:14  <luke-jr> just an additional consideration that needs to be made when such aggregation is introduced
 972017-09-20T10:10:21  *** promag has quit IRC
 982017-09-20T10:10:25  *** Victor_sueca is now known as Victorsueca
 992017-09-20T10:28:04  *** belcher has quit IRC
1002017-09-20T10:35:53  *** SopaXorzTaker has joined #bitcoin-core-dev
1012017-09-20T11:18:33  *** alreadylate has joined #bitcoin-core-dev
1022017-09-20T11:19:49  *** phoenix has joined #bitcoin-core-dev
1032017-09-20T11:20:13  *** phoenix is now known as Guest81071
1042017-09-20T11:21:53  <Guest81071> can i get any  useful ideas to implement to develop bitcoin
1052017-09-20T11:24:16  <Guest81071> how can i develop or contribute to bitcoin
1062017-09-20T11:36:05  <StopAndDecrypt_> Guest81071
1072017-09-20T11:36:14  <StopAndDecrypt_> http://www.righto.com/2014/02/bitcoins-hard-way-using-raw-bitcoin.html
1082017-09-20T11:36:22  <StopAndDecrypt_> http://codesuppository.blogspot.com/2014/01/how-to-parse-bitcoin-blockchain.html
1092017-09-20T11:38:50  <StopAndDecrypt_> http://www.samlewis.me/2017/06/a-peek-under-bitcoins-hood/
1102017-09-20T11:58:19  <vicenteH> I use addwitnessaddress command to generate a segwit address. To save/restore in cold storage that segwit address should I dump private key from original address, then import that private key, get the original address and execute addwitnessaddress again?
1112017-09-20T11:59:21  *** jtimon has joined #bitcoin-core-dev
1122017-09-20T12:01:24  <Guest81071> what is the scope of devoloping the applications using bit coins
1132017-09-20T12:01:54  <Guest81071> what applications can be developed
1142017-09-20T12:07:35  *** meshcollider has quit IRC
1152017-09-20T12:09:54  *** dabura667 has quit IRC
1162017-09-20T12:25:30  *** ula has quit IRC
1172017-09-20T12:32:00  *** ula has joined #bitcoin-core-dev
1182017-09-20T12:56:29  *** meshcollider has joined #bitcoin-core-dev
1192017-09-20T13:00:17  <meshcollider> Guest81071: try asking in #bitcoin - this chat is only for discussion on bitcoin core development not general development
1202017-09-20T13:03:00  <meshcollider> vicenteH: yeah I believe so, at least until proper segwit support in wallets is added in 0.15.1
1212017-09-20T13:07:52  *** Guest81071 has quit IRC
1222017-09-20T13:08:58  <vicenteH> meshcollider: thank you
1232017-09-20T13:21:30  *** SopaXorzTaker is now known as RoshHaShanaXT
1242017-09-20T13:40:29  *** justanotheruser has quit IRC
1252017-09-20T13:45:46  *** promag has joined #bitcoin-core-dev
1262017-09-20T14:04:28  *** RubenSomsen has quit IRC
1272017-09-20T14:06:42  <promag> jnewbery: thanks for #11370, udpated
1282017-09-20T14:06:44  <gribble> https://github.com/bitcoin/bitcoin/issues/11370 | [test] Add getblockchaininfo functional test by promag · Pull Request #11370 · bitcoin/bitcoin · GitHub
1292017-09-20T14:07:14  *** promag has quit IRC
1302017-09-20T14:29:03  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1312017-09-20T14:30:49  *** promag has joined #bitcoin-core-dev
1322017-09-20T14:34:37  *** Ylbam has quit IRC
1332017-09-20T14:42:03  <promag> jnewbery: is 10740 ready for review?
1342017-09-20T14:42:11  <promag> #10740
1352017-09-20T14:42:14  <gribble> https://github.com/bitcoin/bitcoin/issues/10740 | [wallet] dynamic loading/unloading of wallets by jnewbery · Pull Request #10740 · bitcoin/bitcoin · GitHub
1362017-09-20T14:42:59  <esotericnonsense> #11366 updated
1372017-09-20T14:43:00  <gribble> https://github.com/bitcoin/bitcoin/issues/11366 | [rpc] Fix pruneheight help description in getblockchaininfo by esotericnonsense · Pull Request #11366 · bitcoin/bitcoin · GitHub
1382017-09-20T14:46:40  *** promag has quit IRC
1392017-09-20T14:47:14  *** promag has joined #bitcoin-core-dev
1402017-09-20T14:50:20  <jnewbery> promag : just waiting for Travis to complete. There was a bad automatic rebase before. If Travis passes, then I'd definitely appreciate some review at this stage
1412017-09-20T14:51:05  *** Ylbam has joined #bitcoin-core-dev
1422017-09-20T14:51:21  *** promag has quit IRC
1432017-09-20T14:56:13  *** Murch has joined #bitcoin-core-dev
1442017-09-20T15:01:39  *** pbase has quit IRC
1452017-09-20T15:05:35  *** JackH has quit IRC
1462017-09-20T15:06:00  <bitcoin-git> [bitcoin] esotericnonsense closed pull request #11366: [rpc] Fix pruneheight help description in getblockchaininfo (master...2017-09-getblockchaininfo-docs) https://github.com/bitcoin/bitcoin/pull/11366
1472017-09-20T15:06:15  *** meshcollider has quit IRC
1482017-09-20T15:06:19  <esotericnonsense> (put the changes in #11367 as it's pretty small).
1492017-09-20T15:06:21  <gribble> https://github.com/bitcoin/bitcoin/issues/11367 | [rpc] getblockchaininfo: add size_on_disk, prune_target_size by esotericnonsense · Pull Request #11367 · bitcoin/bitcoin · GitHub
1502017-09-20T15:09:39  <esotericnonsense> sorry about the repeated pushes, should be done now, missed your style adjustment on while {} promag.
1512017-09-20T15:11:47  *** promag has joined #bitcoin-core-dev
1522017-09-20T15:18:13  *** Chris_Stewart_5 has quit IRC
1532017-09-20T15:18:30  *** promag has quit IRC
1542017-09-20T15:19:04  *** JackH has joined #bitcoin-core-dev
1552017-09-20T15:23:48  *** Sentineo has joined #bitcoin-core-dev
1562017-09-20T15:40:34  <BlueMatt> https://github.com/bitcoin/bitcoin/issues/11373 should just be closed with "Your filesystem permissions have been set to prevent bitcoind from accessing its datadir, which prevents it from starting" (unless someone wants to change it to a "we need a better error message for this bug" issue)
1572017-09-20T15:42:20  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1582017-09-20T15:50:19  *** Aaronvan_ has joined #bitcoin-core-dev
1592017-09-20T15:52:33  *** AaronvanW has quit IRC
1602017-09-20T15:55:54  *** chartractegg has joined #bitcoin-core-dev
1612017-09-20T15:56:08  *** promag has joined #bitcoin-core-dev
1622017-09-20T15:57:25  *** chartractegg has quit IRC
1632017-09-20T16:00:40  <promag> jnewbery: do you think there should be a PR to replace start+stop with restart_node? or you see an incremental change instead?
1642017-09-20T16:01:37  *** Chris_Stewart_5 has quit IRC
1652017-09-20T16:06:22  *** chartractegg has joined #bitcoin-core-dev
1662017-09-20T16:06:35  *** BashCo has quit IRC
1672017-09-20T16:11:46  *** promag has quit IRC
1682017-09-20T16:23:45  *** chartractegg has left #bitcoin-core-dev
1692017-09-20T16:30:35  *** PaulCapestany has quit IRC
1702017-09-20T16:32:17  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/4f7e37e26c5d...44313d82508b
1712017-09-20T16:32:17  <bitcoin-git> bitcoin/master e53fa4a Andrew Chow: Remove custom fee radio group...
1722017-09-20T16:32:18  <bitcoin-git> bitcoin/master 44313d8 Wladimir J. van der Laan: Merge #11334: qt: Remove custom fee radio group and remove nCustomFeeRadio setting...
1732017-09-20T16:32:57  <bitcoin-git> [bitcoin] laanwj closed pull request #11334: qt: Remove custom fee radio group and remove nCustomFeeRadio setting (master...rm-nCustomFeeRadio) https://github.com/bitcoin/bitcoin/pull/11334
1742017-09-20T16:33:34  *** alreadylate has quit IRC
1752017-09-20T16:34:25  *** alreadylate has joined #bitcoin-core-dev
1762017-09-20T16:39:00  *** PaulCapestany has joined #bitcoin-core-dev
1772017-09-20T16:40:37  *** alreadylate has quit IRC
1782017-09-20T16:47:28  <wumpus> BlueMatt: boost::filesystem::create_directory: Permission denied: "/home/user/.bitcoin"     seems clear enough to me
1792017-09-20T16:48:58  <jnewbery> promag: I think it's fine for that to be included in your getblockchaininfo PR
1802017-09-20T16:50:00  *** RubenSomsen has joined #bitcoin-core-dev
1812017-09-20T16:51:30  *** BashCo has joined #bitcoin-core-dev
1822017-09-20T16:52:16  <jnewbery> Also, #10740 passes travis after manual rebase fixed the test issue. Ready for initial review
1832017-09-20T16:52:17  <gribble> https://github.com/bitcoin/bitcoin/issues/10740 | [wallet] dynamic loading/unloading of wallets by jnewbery · Pull Request #10740 · bitcoin/bitcoin · GitHub
1842017-09-20T16:53:22  <bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/44313d82508b...28474802758a
1852017-09-20T16:53:23  <bitcoin-git> bitcoin/master fa2c3b6 MarcoFalke: doc: Bump manpages to 0.15.99
1862017-09-20T16:53:24  <bitcoin-git> bitcoin/master fa65dcd MarcoFalke: doc: Update release notes for 0.16.0
1872017-09-20T16:53:24  <bitcoin-git> bitcoin/master 2847480 Wladimir J. van der Laan: Merge #11305: [doc] Update release notes and manpages for 0.16...
1882017-09-20T16:53:56  <bitcoin-git> [bitcoin] laanwj closed pull request #11305: [doc] Update release notes and manpages for 0.16 (master...Mf1709-doc016) https://github.com/bitcoin/bitcoin/pull/11305
1892017-09-20T16:57:21  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1902017-09-20T16:58:57  *** geezas has joined #bitcoin-core-dev
1912017-09-20T17:08:10  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/28474802758a...551d7bf604fb
1922017-09-20T17:08:10  <bitcoin-git> bitcoin/master fdc3293 practicalswift: Document assumptions that are being made to avoid NULL pointer dereferences
1932017-09-20T17:08:11  <bitcoin-git> bitcoin/master 551d7bf Wladimir J. van der Laan: Merge #11132: Document assumptions that are being made to avoid NULL pointer dereferences...
1942017-09-20T17:08:40  <bitcoin-git> [bitcoin] laanwj closed pull request #11132: Document assumptions that are being made to avoid NULL pointer dereferences (master...document-non-nullptr-assumptions) https://github.com/bitcoin/bitcoin/pull/11132
1952017-09-20T17:10:08  *** wxxs has quit IRC
1962017-09-20T17:10:45  *** laurentmt has quit IRC
1972017-09-20T17:12:19  *** promag has joined #bitcoin-core-dev
1982017-09-20T17:17:07  *** promag has quit IRC
1992017-09-20T17:18:15  *** atroxes has joined #bitcoin-core-dev
2002017-09-20T17:18:27  *** abpa has joined #bitcoin-core-dev
2012017-09-20T17:22:05  *** PaulCapestany has quit IRC
2022017-09-20T17:23:12  *** wxxs has joined #bitcoin-core-dev
2032017-09-20T17:24:34  *** chjj has joined #bitcoin-core-dev
2042017-09-20T17:35:22  *** ThomasV has joined #bitcoin-core-dev
2052017-09-20T17:41:33  *** PaulCapestany has joined #bitcoin-core-dev
2062017-09-20T17:42:34  <ThomasV> is it true that core will let users reuse the same private key in p2pkh, p2wpkh and p2wpkh-in-p2sh ?
2072017-09-20T17:42:43  <ThomasV> sipa: ^
2082017-09-20T17:42:46  <chainhead> if they use addwitnessaddress
2092017-09-20T17:47:50  <jl2012> if it is compressed key, and with addwitnessaddress
2102017-09-20T17:49:20  *** vicenteH has quit IRC
2112017-09-20T17:50:45  <sipa> ThomasV: for now, yes, we have no choice
2122017-09-20T17:50:57  <ThomasV> no choice??
2132017-09-20T17:51:07  <sipa> that's how addwitnessafdress already works
2142017-09-20T17:51:26  <ThomasV> sipa: if you release that, you will have to keep supporting that forever
2152017-09-20T17:51:43  <sipa> ThomasV: addwitnessaddress has existed since 0.13.0
2162017-09-20T17:51:47  <ThomasV> because users will expect to see their coins when they import an address
2172017-09-20T17:52:30  <ThomasV> do you plan to do something about that?
2182017-09-20T17:52:31  *** AaronvanW has joined #bitcoin-core-dev
2192017-09-20T17:52:42  <sipa> in a future version we plan to redesign the logoc for determining which addresses are ours, and have split chain for each type of address
2202017-09-20T17:53:13  <sipa> and perhaps deprecate importprivkey in favor of importmulti (which requires passing all relevant information)
2212017-09-20T17:53:46  *** aashu has joined #bitcoin-core-dev
2222017-09-20T17:53:49  <aashu> join
2232017-09-20T17:54:25  <sipa> i agree it's a bad situation that we accept payments to addresses we didn't create, but it's a too invasive change to make in a minor release
2242017-09-20T17:54:34  *** aashu has quit IRC
2252017-09-20T17:54:34  *** duringo has joined #bitcoin-core-dev
2262017-09-20T17:54:41  *** Aaronvan_ has quit IRC
2272017-09-20T17:55:07  <sipa> it's an issue that has existed for a long time too (for example, core also accepts payments to pay to pubkeys for corresponding keys of addresses that were created)
2282017-09-20T17:56:53  <ThomasV> well, p2pk is a bit different, because you do not create a bitcoin address for it
2292017-09-20T17:57:23  <ghost43> so then if a user somehow exports a private key from Core, and tries to import that in another software, what should that other software do with it? try to convert that to all types of outputs?
2302017-09-20T17:57:48  <ThomasV> ghost43: that's what I want to avoid
2312017-09-20T17:58:07  <ThomasV> that would encourage key reuse
2322017-09-20T17:58:33  <sipa> internally, the ismine logic basically decides what is our based on the ability to sign... which is a mistake, but rewriting that code replacing it with something sane will take time
2332017-09-20T17:58:43  <sipa> ThomasV: i understand
2342017-09-20T18:01:09  <sipa> ghost43: i don't think you should associate any type of output with a key... a key is just a key and not an address
2352017-09-20T18:01:16  <sipa> but that's not how things work now
2362017-09-20T18:02:09  <ThomasV> sipa: a key is just a key, but the serialization of a key is not just a key
2372017-09-20T18:02:41  <ThomasV> it has a byte that disambiguates compressed/uncompressed
2382017-09-20T18:02:50  <ThomasV> and that's a good thing
2392017-09-20T18:02:59  <ThomasV> we really need to extend that
2402017-09-20T18:03:03  <sipa> i disagree
2412017-09-20T18:03:10  *** laurentmt has joined #bitcoin-core-dev
2422017-09-20T18:03:16  <goatpig> maybe it's time to agree on a set of identifiers for common script types
2432017-09-20T18:03:24  *** laurentmt has quit IRC
2442017-09-20T18:03:31  <sipa> if you want to import an address, give the address; if you want to spend from it, give its associated key
2452017-09-20T18:03:36  *** tknp has joined #bitcoin-core-dev
2462017-09-20T18:03:56  <sipa> i think it's unmaintainable to keep implying the address from just the key
2472017-09-20T18:04:40  <goatpig> not as a requirement, but just allow those wallets who want to to forward that information in a standardized fashion?
2482017-09-20T18:04:51  <sipa> give the address + privkey?
2492017-09-20T18:05:07  <sipa> importing addresses doesn't sound like something a normal user would do frequently
2502017-09-20T18:05:18  <goatpig> no they usually import the privkey
2512017-09-20T18:05:26  <ghost43> give the full scriptPubKey + the private key, haha
2522017-09-20T18:05:42  <goatpig> expect the software they using it with to know which scripts to look for on chain
2532017-09-20T18:05:59  <goatpig> cant tell if this is just pebkac and should be ignored, or if there is a need to cover this case
2542017-09-20T18:06:02  <goatpig> but it exists alright
2552017-09-20T18:06:19  <sipa> i expect the same issue does exist at least for importing hd chains, though
2562017-09-20T18:06:26  <goatpig> now it does
2572017-09-20T18:06:32  <goatpig> before, not necessarely
2582017-09-20T18:06:32  <ThomasV> sipa: that's interesting. why dont you post that in the ML?
2592017-09-20T18:06:39  <goatpig> if you stick to BIP44, p2pkh is basically implied
2602017-09-20T18:06:47  <sipa> ghost43: right
2612017-09-20T18:06:57  <sipa> ThomasV: i hate the ml
2622017-09-20T18:06:58  <ThomasV> goatpig: please no bip44
2632017-09-20T18:07:13  <goatpig> ThomasV: is that a voldermort moment?
2642017-09-20T18:07:26  <ThomasV> sipa: if you hate it, why did you answer to my post?
2652017-09-20T18:07:36  <sipa> i felt i had to
2662017-09-20T18:08:02  <ThomasV> yeah, but you kept the real annsyer until now
2672017-09-20T18:08:07  <sipa> hmm?
2682017-09-20T18:08:20  <sipa> you're asking my opinion
2692017-09-20T18:08:20  <ThomasV> I asked what core plans to do regarding key imports
2702017-09-20T18:08:29  <ThomasV> oh come on..
2712017-09-20T18:08:38  <sipa> ah, right
2722017-09-20T18:08:44  <ThomasV> your opinion counts
2732017-09-20T18:09:51  <sipa> let me find the mail
2742017-09-20T18:10:07  <ghost43> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/015007.html
2752017-09-20T18:11:01  <ThomasV> goatpig: I guess you know what I think of bip44
2762017-09-20T18:11:16  <goatpig> oh i do
2772017-09-20T18:11:25  <goatpig> i agree with your position on the WIF thing
2782017-09-20T18:11:28  <goatpig> extending it would help
2792017-09-20T18:12:12  <goatpig> otherwise, id fall back on Lombrozo's BIP124 and flesh that out?
2802017-09-20T18:12:37  <ThomasV> goatpig: bip124 is not really specified
2812017-09-20T18:13:12  <goatpig> therefor it wont be as resistant to proposals
2822017-09-20T18:14:32  <ThomasV> goatpig: I am interested in it too
2832017-09-20T18:15:06  <goatpig> i mean the WIF is for single keys
2842017-09-20T18:15:16  <goatpig> but at least if we can agree on some stuff for entire chains
2852017-09-20T18:15:46  <ThomasV> well, if we had a decent bip124 we could use it for single keys too
2862017-09-20T18:18:29  *** promag has joined #bitcoin-core-dev
2872017-09-20T18:20:52  <sipa> ThomasV: thanks for bringing it up. thinking more about it, i think my main issue is that we should start thinking about addresses and keys as orthogonal things (there are some things you consider yours - addresses, and then some things you know how to sign for - keys)... especially with things like hardware wallets, multisig
2882017-09-20T18:21:07  <sipa> however, that doesn't mean there can't be a format that encapsulates both
2892017-09-20T18:21:52  <sipa> i'll respond on the list
2902017-09-20T18:21:56  <ThomasV> well, what is the point of having a serialization format, if it is not to encapsulate ?
2912017-09-20T18:22:35  *** PaulCapestany has quit IRC
2922017-09-20T18:22:45  <sipa> ThomasV: well there can be separate formats, i guess
2932017-09-20T18:23:52  <ThomasV> sipa: electrum has orthogonal classes for wallets and keystores. a wallet is defined by the type of output script, regardless of how keys are stored
2942017-09-20T18:24:02  <sipa> right, sounds great
2952017-09-20T18:24:45  <ThomasV> so we can use hardware or software keystores in multisig wallets, with the same wallet class
2962017-09-20T18:25:38  <ThomasV> but I believe that what we export and show to users should be encapsulated
2972017-09-20T18:26:32  <sipa> right, but you also need a way to export/import a chain or address without revealing the key
2982017-09-20T18:26:49  <sipa> for an address that's easy, as it's just an address
2992017-09-20T18:27:13  <sipa> though i saw there was talk of including a birthtime too
3002017-09-20T18:27:13  <ThomasV> a wallet cannot import an address unless it is a special wallet type
3012017-09-20T18:27:31  <sipa> sure
3022017-09-20T18:27:57  <sipa> but i'm sure some software will exist that can import arbitrary individual addresses
3032017-09-20T18:29:03  <goatpig> and that's fine
3042017-09-20T18:29:12  <ThomasV> electrum can do it. my point is that wallet class does not have a keystore
3052017-09-20T18:29:44  <ThomasV> there is a wallet class that just means "a set of imported addresses"
3062017-09-20T18:29:47  <goatpig> the issue would be importing a private key and failing to find all funds that key can sign for
3072017-09-20T18:30:09  <sipa> goatpig: i think it's a terrible idea to treat every output you can sign for as your own
3082017-09-20T18:30:28  <ThomasV> there also is a keystore class for imported private keys, but it has nothing to do with imported addresses, and it assumes p2pkh
3092017-09-20T18:31:10  <andytoshi> goatpig: taken literally that leads to trivial attacks (e.g. you can sign for a 1-of-2 multisig with me, but that output isn't yours and if you have one you can't consider it as a final payment)
3102017-09-20T18:31:46  <sipa> ThomasV: my point is that we should really think about importing something as either an address/chain (something to look for) or as private key (something to sign with) - there can be a convenience method to encode both simultaneously
3112017-09-20T18:32:04  <sipa> and i'm not opposed to such a convenience, but i don't have many opinions on it
3122017-09-20T18:32:51  <goatpig> sipa: andytoshi: the idea is not for me to support all of these possible script variations, it's to able to tell my user: "my software does not support all of tehse variations, do not use to import from this key"
3132017-09-20T18:32:52  <ThomasV> sipa: current wallets allow to import private keys, and they assume p2pkh
3142017-09-20T18:33:06  <ThomasV> it is difficult to undo that
3152017-09-20T18:33:14  <sipa> ThomasV: we don't need to continue that practice
3162017-09-20T18:33:22  *** duringo_ has joined #bitcoin-core-dev
3172017-09-20T18:33:34  <sipa> have a new private key format that does not have any implied address
3182017-09-20T18:34:22  <ThomasV> sipa: stop supporting privkey imports in core, and see how users will react :D
3192017-09-20T18:34:48  <sipa> ThomasV: i'm not saying we should stop supporting imports
3202017-09-20T18:34:56  <ThomasV> sipa: ok, I read you
3212017-09-20T18:35:06  <sipa> but the modern way of doing it is using importmulti, where you just give both the address and the private key
3222017-09-20T18:35:15  <sipa> (and the import checks that that private indeed can sign for that address)
3232017-09-20T18:35:54  <sipa> and if it's P2SH it also requires giving the relevant redeemscript
3242017-09-20T18:35:57  <goatpig> sipa: that could turn into a GUI nightmare, just saying
3252017-09-20T18:36:33  <sipa> goatpig: perhaps
3262017-09-20T18:36:46  <goatpig> well between expecting that much info from the user
3272017-09-20T18:36:49  *** duringo has quit IRC
3282017-09-20T18:37:02  <goatpig> or agreeing to a header byte that refer to a table telling you how to derive the script hash
3292017-09-20T18:37:04  *** PaulCapestany has joined #bitcoin-core-dev
3302017-09-20T18:37:08  <goatpig> obviously i'd pick the easy way out
3312017-09-20T18:37:43  <sipa> as said, i'm not opposed to a convenience method to encode all of it
3322017-09-20T18:37:52  *** Chris_Stewart_5 has quit IRC
3332017-09-20T18:38:08  <ThomasV> sipa: what do you think of bip124?
3342017-09-20T18:38:09  <goatpig> i believe that's what we're hinting towards
3352017-09-20T18:38:14  <sipa> ThomasV: i haven't looked at it
3362017-09-20T18:38:23  <goatpig> it's a bit lean atm
3372017-09-20T18:39:12  <ThomasV> goatpig: all it needs is a way to extend script with variables
3382017-09-20T18:39:14  <sipa> so for example an issue i see is CLTV/CSV
3392017-09-20T18:39:36  <sipa> i expect people at some point will want a standard way of using these in scripts]
3402017-09-20T18:40:06  <sipa> an "address import" for one of those will need to include the locktime/sequence requirement number, or you can't derive the scriptPubKey
3412017-09-20T18:40:14  <ThomasV> right
3422017-09-20T18:40:34  <sipa> an approach that just requires you to pass the full scriptPubKey you're looking for is an elegant, but not perfectly convenient, method
3432017-09-20T18:41:05  <sipa> but as a 'raw' export/import function, i think that's totally acceptable
3442017-09-20T18:42:04  <goatpig> for cltv you could imply the position on the address chain is the cltv member
3452017-09-20T18:42:11  <goatpig> for csv idk if you can sneak around like that
3462017-09-20T18:43:42  <sipa> yuck.
3472017-09-20T18:43:47  <goatpig> aww
3482017-09-20T18:44:00  <sipa> cltv can have a locktime in seconds
3492017-09-20T18:44:17  <goatpig> i was thinking on the block count after confirmation variant only
3502017-09-20T18:44:51  <ThomasV> sipa: you mean the full script, not its hash?
3512017-09-20T18:45:41  <goatpig> sipa: you have to think of backups as well as imports in the case of cltv/csv
3522017-09-20T18:45:54  <sipa> ThomasV: yes, that's what importmulti requires
3532017-09-20T18:45:55  <goatpig> the least user inputed data, the better
3542017-09-20T18:46:19  <sipa> goatpig: well at least everything expect the private keys is much less sensitive
3552017-09-20T18:46:44  <sipa> but yes, you're right, that's an issue
3562017-09-20T18:46:54  <adiabat> it may also make sense to standardize on an importable utxo format, with optional privatekey field
3572017-09-20T18:47:12  <adiabat> I use this in my lightning software between wallet / lightning layer
3582017-09-20T18:47:42  *** RoshHaShanaXT has quit IRC
3592017-09-20T18:47:51  <adiabat> could enable imports without rescanning or anything
3602017-09-20T18:48:00  <ThomasV> sipa: ok, so Iguess the issue is to find a good serialization for what importmulti needs
3612017-09-20T18:48:21  <sipa> ThomasV: for a subset, at least...
3622017-09-20T18:49:10  <sipa> unfortunately the checksum properties in bech32 degrade when there are more than 89 characters
3632017-09-20T18:49:41  <sipa> ThomasV: did you see my comment on your only-v0-witness commit?
3642017-09-20T18:49:48  <goatpig> use several lines, have a counter in each line
3652017-09-20T18:49:51  <ThomasV> sipa: yes I saw it
3662017-09-20T18:50:18  <sipa> goatpig: yuck :)
3672017-09-20T18:50:27  <goatpig> so mean!
3682017-09-20T18:50:27  <ThomasV> sipa: but soft forks are not so common, so I have time to think about it :)
3692017-09-20T18:50:41  <sipa> ThomasV: depends on how fast your users upgrafe
3702017-09-20T18:50:54  <ThomasV> yeah
3712017-09-20T18:50:57  <sipa> we saw with p2sh that it took years before every wallet was able to send to it
3722017-09-20T18:51:26  <sipa> i expect that for bip173 it will be less time, but i'd rather  ot have that delay for every softfork
3732017-09-20T18:51:41  <ThomasV> I understand
3742017-09-20T18:51:54  <ThomasV> will do
3752017-09-20T18:51:58  <sipa> thanks!
3762017-09-20T19:00:10  <ThomasV> ok, dinner time
3772017-09-20T19:00:31  <sipa> ok, lunch time
3782017-09-20T19:05:08  *** ThomasV has quit IRC
3792017-09-20T19:08:02  <gmaxwell> adiabat: have you seen achow's psbt format?  not what you're suggesting but its relevant. It could perhaps incorporate what you're thinking by gaining extra fields to carry around the private key for an input.
3802017-09-20T19:08:23  *** alreadylate has joined #bitcoin-core-dev
3812017-09-20T19:12:25  *** wbobeirne has joined #bitcoin-core-dev
3822017-09-20T19:15:08  *** promag has quit IRC
3832017-09-20T19:15:50  *** wbobeirne has quit IRC
3842017-09-20T19:25:24  *** Miezel has joined #bitcoin-core-dev
3852017-09-20T19:35:28  *** alreadylate has quit IRC
3862017-09-20T19:37:04  *** owowo has quit IRC
3872017-09-20T19:41:23  *** alreadylate has joined #bitcoin-core-dev
3882017-09-20T19:42:14  *** owowo has joined #bitcoin-core-dev
3892017-09-20T19:44:50  *** wampy has quit IRC
3902017-09-20T19:54:17  *** vicenteH has joined #bitcoin-core-dev
3912017-09-20T19:55:35  *** PaulCapestany has quit IRC
3922017-09-20T19:57:49  *** PaulCapestany has joined #bitcoin-core-dev
3932017-09-20T19:57:51  *** timothy has quit IRC
3942017-09-20T19:58:16  <adiabat> gmaxwell: saw the post; looks interesting and not quite what I have, but something similar
3952017-09-20T19:58:29  <adiabat> github link in that doesn't seem to work though
3962017-09-20T19:58:41  <adiabat> (link from the mailing list post I mean)
3972017-09-20T19:59:55  *** chjj has quit IRC
3982017-09-20T20:02:13  *** alreadylate has quit IRC
3992017-09-20T20:02:36  *** promag has joined #bitcoin-core-dev
4002017-09-20T20:06:56  *** promag has quit IRC
4012017-09-20T20:10:39  *** Miezel_ has joined #bitcoin-core-dev
4022017-09-20T20:10:43  *** Miezel has quit IRC
4032017-09-20T20:12:29  <tknp> i might be missing something simple but is there a single rpc call to display the btc value of the items in a vin array using 'getblock'
4042017-09-20T20:15:37  <sipa> no
4052017-09-20T20:15:49  <sipa> bitcoind doesn't have that information
4062017-09-20T20:16:34  *** RubenSomsen has quit IRC
4072017-09-20T20:17:19  *** meshcollider has joined #bitcoin-core-dev
4082017-09-20T20:17:20  <tknp> ok thanks. i'll do some more reading. the value i'm after does look to be in the output of gettxout of the txid of the vin in question
4092017-09-20T20:17:33  <goatpig> outpoint value?
4102017-09-20T20:19:07  <tknp> oh sorry, i don't mean the monetary value of btc but the 'value' key that relates to the number of bitcoins paid for the output
4112017-09-20T20:19:24  *** promag has joined #bitcoin-core-dev
4122017-09-20T20:19:58  <achow101> adiabat: which link?
4132017-09-20T20:20:21  <meshcollider> adiabat: that's because it was given a BIP number 174 and moved filename, it's here now: https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki
4142017-09-20T20:20:22  <goatpig> yeah, you want the value of the outpoint the txin is pointing at
4152017-09-20T20:20:38  <goatpig> i dont think the RPC let's you request outpoints at all
4162017-09-20T20:21:05  <goatpig> well i guess the proper term is resolving the outpoint
4172017-09-20T20:22:05  <tknp> goatpid correct. was hoping to not have to make a secondary rpc call for each tx input with the proper vout value
4182017-09-20T20:22:49  <goatpig> that resolution is expensive, you cant expect a call to get a tx would just go ahead and resolve the outpoints on the off chance the caller might want it
4192017-09-20T20:23:47  *** promag has quit IRC
4202017-09-20T20:23:48  <tknp> yup, was hoping that there was a convenience method cooked in with the understanding that it was expensive to call. like a hidden valid value for the format param that would do the resolving
4212017-09-20T20:24:09  <goatpig> im just guessing here
4222017-09-20T20:24:20  <goatpig> but i expect core has the dataset necessary to resolve arbitrary outpoints
4232017-09-20T20:24:27  <goatpig> or maybe not
4242017-09-20T20:24:33  <goatpig> that's just a guess on my part
4252017-09-20T20:24:37  <gmaxwell> Bitcoind doesn't have the information.
4262017-09-20T20:24:44  <goatpig> you need to resolve outpoints to verify incoming zero conf tx
4272017-09-20T20:24:52  <gmaxwell> Providing it would require an additional quite expensive index, or a sequential scan of the blockchain.
4282017-09-20T20:24:56  <sipa> it only has the information about unspent outputs
4292017-09-20T20:25:03  <gmaxwell> goatpig: yes but he is asking about getblock.
4302017-09-20T20:25:04  <goatpig> but you could do that by just maintaining the utxo set and checking outpoints in zc vs that
4312017-09-20T20:25:08  <sipa> which is sufficient for validating new blocks
4322017-09-20T20:25:12  <goatpig> well then he should use armory =D
4332017-09-20T20:25:18  <goatpig> cause it has a supernode teehee
4342017-09-20T20:25:37  <gmaxwell> and was unusably slow and will be again eventually. :P
4352017-09-20T20:26:01  <goatpig> =( so mean
4362017-09-20T20:26:03  <gmaxwell> haha
4372017-09-20T20:26:27  <goatpig> man it;s hard to keep up, i wrote the first supernode in 2013, blockchain is like 7 times as large now
4382017-09-20T20:26:31  <gmaxwell> Sorry. Just the point there is that it's not provided not because bitcoind is lazy or something, but because it has a real non-trivial cost.
4392017-09-20T20:27:02  <goatpig> yes, just maintaining the dataset to resolve arbirtary tx hashes is expensive
4402017-09-20T20:27:12  <tknp> understood and thanks. i'll deal with making separate requests through other means
4412017-09-20T20:29:07  <achow101> gmaxwell: isn't txindex like that
4422017-09-20T20:29:26  <achow101> an index that can be used to grab arbitrary outpoints
4432017-09-20T20:30:00  <sipa> achow101: very inefficiently, yes
4442017-09-20T20:30:14  <gmaxwell> does it still even work? :( I stopped using it on all my hosts because its such a slowdown.
4452017-09-20T20:30:25  <sipa> (it read the entire block for each output you're looking up)
4462017-09-20T20:30:26  <achow101> gmaxwell: I use it on my node, seems to work
4472017-09-20T20:30:47  <achow101> but the index itself is 12 GB apparently
4482017-09-20T20:31:52  <achow101> syncing a new node with txindex is probably a massive slowdown, but I have had it enabled for several years now so when I synced it wasn't that bad
4492017-09-20T20:38:14  *** belcher has joined #bitcoin-core-dev
4502017-09-20T20:39:38  *** ThomasV has joined #bitcoin-core-dev
4512017-09-20T20:41:10  <adiabat> I run txindex on mainnet and testnet3, it doesn't slow it down too much
4522017-09-20T20:41:49  <adiabat> then again I'm running on spinning disks so it's pretty slow no matter what :P
4532017-09-20T20:48:49  *** owowo has quit IRC
4542017-09-20T21:13:23  *** duringo has joined #bitcoin-core-dev
4552017-09-20T21:18:18  *** duringo has quit IRC
4562017-09-20T21:18:31  *** duringo has joined #bitcoin-core-dev
4572017-09-20T21:37:05  *** ThomasV has quit IRC
4582017-09-20T21:41:22  *** wxxs has quit IRC
4592017-09-20T21:44:13  <Sentineo> I run txindex on an odroid xu4
4602017-09-20T21:44:27  <Sentineo> works fine too, usb stick has the blockchain
4612017-09-20T21:45:03  <Sentineo> syncing is a pain in the b, but otherwise kt is fine
4622017-09-20T21:55:41  *** Guyver2 has quit IRC
4632017-09-20T22:10:46  *** Cheeseo has joined #bitcoin-core-dev
4642017-09-20T22:11:54  *** Miezel_ has quit IRC
4652017-09-20T22:14:07  <bitcoin-git> [bitcoin] tomasvdw opened pull request #11376: Ensure backupwallet fails when attempting to backup to source file (master...core) https://github.com/bitcoin/bitcoin/pull/11376
4662017-09-20T22:22:04  *** ghost43 has quit IRC
4672017-09-20T22:22:18  *** ghost43 has joined #bitcoin-core-dev
4682017-09-20T22:26:19  *** duringo has quit IRC
4692017-09-20T22:48:32  *** Cory has quit IRC
4702017-09-20T22:49:14  *** cheese_ has joined #bitcoin-core-dev
4712017-09-20T22:53:10  *** Cory has joined #bitcoin-core-dev
4722017-09-20T22:54:57  *** Aaronvan_ has joined #bitcoin-core-dev
4732017-09-20T22:55:52  *** Aaronva__ has joined #bitcoin-core-dev
4742017-09-20T22:57:08  *** AaronvanW has quit IRC
4752017-09-20T22:59:32  *** Aaronvan_ has quit IRC
4762017-09-20T23:10:58  *** owowo has joined #bitcoin-core-dev
4772017-09-20T23:13:31  *** Geoffy has quit IRC
4782017-09-20T23:35:19  *** Aaronva__ is now known as AaronvanW
4792017-09-20T23:40:22  *** rockhouse has quit IRC
4802017-09-20T23:43:55  *** cheese_ has quit IRC
4812017-09-20T23:46:41  *** Cheeseo has quit IRC
4822017-09-20T23:47:22  <bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/551d7bf604fb...98212745c8ac
4832017-09-20T23:47:22  <bitcoin-git> bitcoin/master 05cae8a Marko Bencun: range-based loops and const qualifications in net.cpp...
4842017-09-20T23:47:23  <bitcoin-git> bitcoin/master 9821274 Pieter Wuille: Merge #10888: range-based loops and const qualifications in net.cpp...
4852017-09-20T23:47:52  <bitcoin-git> [bitcoin] sipa closed pull request #10888: range-based loops and const qualifications in net.cpp (master...netcpp_cosmetics2) https://github.com/bitcoin/bitcoin/pull/10888
4862017-09-20T23:53:53  *** rockhouse has joined #bitcoin-core-dev
4872017-09-20T23:54:24  *** chjj has joined #bitcoin-core-dev
4882017-09-20T23:57:12  *** chjj has quit IRC
4892017-09-20T23:57:22  *** Murch has quit IRC
4902017-09-20T23:58:22  *** abpa has quit IRC