--- Day changed Wed Sep 20 2017 00:05 -!- tknp [~tknp@unaffiliated/tknp] has quit [Quit: tknp] 00:07 < kallewoof> esotericnonsense: I don't think I saw that. Will look, thanks! 00:07 < esotericnonsense> :) right at the bottom 00:08 < kallewoof> Ahh, yeah, I missed that completely. Thanks 00:15 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 00:18 < bitcoin-git> [bitcoin] Reagent1981 opened pull request #11374: 0.15 (master...0.15) https://github.com/bitcoin/bitcoin/pull/11374 00:19 < bitcoin-git> [bitcoin] fanquake closed pull request #11374: 0.15 (master...0.15) https://github.com/bitcoin/bitcoin/pull/11374 00:24 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 00:25 -!- timothy [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev 00:27 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 00:27 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-lptdewidehgouqhh] has joined #bitcoin-core-dev 00:46 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 00:50 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Ping timeout: 255 seconds] 00:52 -!- RubenSomsen [~RubenSoms@1.217.138.142] has joined #bitcoin-core-dev 01:01 -!- laurentmt [~Thunderbi@92.154.68.134] has joined #bitcoin-core-dev 01:03 -!- JackH [~laptop@46.231.18.66] has joined #bitcoin-core-dev 01:07 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-lptkrzaftnmorsvv] has quit [Quit: Connection closed for inactivity] 01:08 -!- tErik_mc [~tErik@unaffiliated/terik] has quit [Ping timeout: 240 seconds] 01:21 -!- PaulCapestany [~PaulCapes@ip72-209-228-52.dc.dc.cox.net] has quit [Ping timeout: 252 seconds] 01:33 -!- PaulCapestany [~PaulCapes@ip72-209-228-52.dc.dc.cox.net] has joined #bitcoin-core-dev 01:35 -!- Geoffy [~Geo@178-119-187-213.access.telenet.be] has joined #bitcoin-core-dev 01:43 -!- Aaronva__ [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds] 01:44 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 01:49 < 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? 01:51 < kallewoof> Wait, no, it would become a softfork. *headscratch* 01:51 < 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. 01:51 < kallewoof> " 01:53 < kallewoof> Old nodes all accept, new nodes do more. It should be a softfork, no? 01:56 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-mfvhkvviltafzamz] has joined #bitcoin-core-dev 01:56 -!- PaulCapestany [~PaulCapes@ip72-209-228-52.dc.dc.cox.net] has quit [Ping timeout: 252 seconds] 01:59 -!- vicenteH [~user@195.235.96.150] has joined #bitcoin-core-dev 01:59 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 02:01 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has joined #bitcoin-core-dev 02:16 -!- drizztbsd [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev 02:16 -!- timothy [~tredaelli@redhat/timothy] has quit [Ping timeout: 246 seconds] 02:17 -!- drizztbsd is now known as timothy 02:17 -!- PaulCapestany [~PaulCapes@ip72-209-228-52.dc.dc.cox.net] has joined #bitcoin-core-dev 02:34 -!- PaulCapestany [~PaulCapes@ip72-209-228-52.dc.dc.cox.net] has quit [Ping timeout: 240 seconds] 02:43 -!- PaulCapestany [~PaulCapes@ip72-209-228-52.dc.dc.cox.net] has joined #bitcoin-core-dev 02:57 -!- wxxs [~chatzilla@185.38.150.115] has joined #bitcoin-core-dev 03:00 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev 03:03 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 248 seconds] 03:08 < luke-jr> kallewoof: he's talking about after some hypothetical signature aggregation scheme 03:08 < luke-jr> I'm not convinced it's a real blocker 03:09 < luke-jr> just an additional consideration that needs to be made when such aggregation is introduced 03:10 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 03:10 -!- Victor_sueca is now known as Victorsueca 03:28 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving] 03:35 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev 04:18 -!- alreadylate [~textual@37-247-1-221.customers.ownit.se] has joined #bitcoin-core-dev 04:19 -!- phoenix [d2d4d142@gateway/web/freenode/ip.210.212.209.66] has joined #bitcoin-core-dev 04:20 -!- phoenix is now known as Guest81071 04:21 < Guest81071> can i get any useful ideas to implement to develop bitcoin 04:24 < Guest81071> how can i develop or contribute to bitcoin 04:36 < StopAndDecrypt_> Guest81071 04:36 < StopAndDecrypt_> http://www.righto.com/2014/02/bitcoins-hard-way-using-raw-bitcoin.html 04:36 < StopAndDecrypt_> http://codesuppository.blogspot.com/2014/01/how-to-parse-bitcoin-blockchain.html 04:38 < StopAndDecrypt_> http://www.samlewis.me/2017/06/a-peek-under-bitcoins-hood/ 04:58 < 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? 04:59 -!- jtimon [~quassel@199.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 05:01 < Guest81071> what is the scope of devoloping the applications using bit coins 05:01 < Guest81071> what applications can be developed 05:07 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-mfvhkvviltafzamz] has quit [Quit: Connection closed for inactivity] 05:09 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has quit [Remote host closed the connection] 05:25 -!- ula [~kvirc@b2b-78-94-11-194.unitymedia.biz] has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/] 05:32 -!- ula [~kvirc@b2b-78-94-11-194.unitymedia.biz] has joined #bitcoin-core-dev 05:56 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-smlqqdhsniyjyxlx] has joined #bitcoin-core-dev 06:00 < meshcollider> Guest81071: try asking in #bitcoin - this chat is only for discussion on bitcoin core development not general development 06:03 < meshcollider> vicenteH: yeah I believe so, at least until proper segwit support in wallets is added in 0.15.1 06:07 -!- Guest81071 [d2d4d142@gateway/web/freenode/ip.210.212.209.66] has quit [Quit: Page closed] 06:08 < vicenteH> meshcollider: thank you 06:21 -!- SopaXorzTaker is now known as RoshHaShanaXT 06:40 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 255 seconds] 06:45 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 07:04 -!- RubenSomsen [~RubenSoms@1.217.138.142] has quit [Ping timeout: 240 seconds] 07:06 < promag> jnewbery: thanks for #11370, udpated 07:06 < gribble> https://github.com/bitcoin/bitcoin/issues/11370 | [test] Add getblockchaininfo functional test by promag · Pull Request #11370 · bitcoin/bitcoin · GitHub 07:07 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 07:29 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev 07:30 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 07:34 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-lptdewidehgouqhh] has quit [Quit: Connection closed for inactivity] 07:42 < promag> jnewbery: is 10740 ready for review? 07:42 < promag> #10740 07:42 < gribble> https://github.com/bitcoin/bitcoin/issues/10740 | [wallet] dynamic loading/unloading of wallets by jnewbery · Pull Request #10740 · bitcoin/bitcoin · GitHub 07:42 < esotericnonsense> #11366 updated 07:43 < gribble> https://github.com/bitcoin/bitcoin/issues/11366 | [rpc] Fix pruneheight help description in getblockchaininfo by esotericnonsense · Pull Request #11366 · bitcoin/bitcoin · GitHub 07:46 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 07:47 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 07:50 < 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 07:51 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-magcuiqaxtfrudgo] has joined #bitcoin-core-dev 07:51 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Ping timeout: 240 seconds] 07:56 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 08:01 -!- pbase [~pbase@unaffiliated/pbase] has quit [Quit: Leaving] 08:05 -!- JackH [~laptop@46.231.18.66] has quit [Ping timeout: 240 seconds] 08:06 < 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 08:06 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-smlqqdhsniyjyxlx] has quit [Quit: Connection closed for inactivity] 08:06 < esotericnonsense> (put the changes in #11367 as it's pretty small). 08:06 < 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 08:09 < esotericnonsense> sorry about the repeated pushes, should be done now, missed your style adjustment on while {} promag. 08:11 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 08:18 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 255 seconds] 08:18 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 08:19 -!- JackH [~laptop@2a02:a210:2e00:300:655a:7cbf:d627:81fb] has joined #bitcoin-core-dev 08:23 -!- Sentineo [~Undefined@unaffiliated/sentineo] has joined #bitcoin-core-dev 08:40 < 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) 08:42 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev 08:50 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 08:52 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 248 seconds] 08:55 -!- chartractegg [~chartract@ip68-98-5-113.ph.ph.cox.net] has joined #bitcoin-core-dev 08:56 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 08:57 -!- chartractegg [~chartract@ip68-98-5-113.ph.ph.cox.net] has quit [Client Quit] 09:00 < promag> jnewbery: do you think there should be a PR to replace start+stop with restart_node? or you see an incremental change instead? 09:01 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 248 seconds] 09:06 -!- chartractegg [~chartract@gateway/vpn/privateinternetaccess/chartractegg] has joined #bitcoin-core-dev 09:06 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection] 09:11 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 09:23 -!- chartractegg [~chartract@gateway/vpn/privateinternetaccess/chartractegg] has left #bitcoin-core-dev ["Textual IRC Client: www.textualapp.com"] 09:30 -!- PaulCapestany [~PaulCapes@ip72-209-228-52.dc.dc.cox.net] has quit [Ping timeout: 240 seconds] 09:32 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/4f7e37e26c5d...44313d82508b 09:32 < bitcoin-git> bitcoin/master e53fa4a Andrew Chow: Remove custom fee radio group... 09:32 < bitcoin-git> bitcoin/master 44313d8 Wladimir J. van der Laan: Merge #11334: qt: Remove custom fee radio group and remove nCustomFeeRadio setting... 09:32 < 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 09:33 -!- alreadylate [~textual@37-247-1-221.customers.ownit.se] has quit [] 09:34 -!- alreadylate [~textual@37-247-1-221.customers.ownit.se] has joined #bitcoin-core-dev 09:39 -!- PaulCapestany [~PaulCapes@ip72-209-228-52.dc.dc.cox.net] has joined #bitcoin-core-dev 09:40 -!- alreadylate [~textual@37-247-1-221.customers.ownit.se] has quit [] 09:47 < wumpus> BlueMatt: boost::filesystem::create_directory: Permission denied: "/home/user/.bitcoin" seems clear enough to me 09:48 < jnewbery> promag: I think it's fine for that to be included in your getblockchaininfo PR 09:50 -!- RubenSomsen [~RubenSoms@1.217.138.142] has joined #bitcoin-core-dev 09:51 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 09:52 < jnewbery> Also, #10740 passes travis after manual rebase fixed the test issue. Ready for initial review 09:52 < gribble> https://github.com/bitcoin/bitcoin/issues/10740 | [wallet] dynamic loading/unloading of wallets by jnewbery · Pull Request #10740 · bitcoin/bitcoin · GitHub 09:53 < bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/44313d82508b...28474802758a 09:53 < bitcoin-git> bitcoin/master fa2c3b6 MarcoFalke: doc: Bump manpages to 0.15.99 09:53 < bitcoin-git> bitcoin/master fa65dcd MarcoFalke: doc: Update release notes for 0.16.0 09:53 < bitcoin-git> bitcoin/master 2847480 Wladimir J. van der Laan: Merge #11305: [doc] Update release notes and manpages for 0.16... 09:53 < 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 09:57 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev 09:58 -!- geezas [uid253218@gateway/web/irccloud.com/x-jafliyelygyoqval] has joined #bitcoin-core-dev 10:08 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/28474802758a...551d7bf604fb 10:08 < bitcoin-git> bitcoin/master fdc3293 practicalswift: Document assumptions that are being made to avoid NULL pointer dereferences 10:08 < bitcoin-git> bitcoin/master 551d7bf Wladimir J. van der Laan: Merge #11132: Document assumptions that are being made to avoid NULL pointer dereferences... 10:08 < 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 10:10 -!- wxxs [~chatzilla@185.38.150.115] has quit [Ping timeout: 240 seconds] 10:10 -!- laurentmt [~Thunderbi@92.154.68.134] has quit [Quit: laurentmt] 10:12 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 10:17 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Ping timeout: 260 seconds] 10:18 -!- atroxes [~atroxes@unaffiliated/atroxes] has joined #bitcoin-core-dev 10:18 -!- abpa [~abpa@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 10:22 -!- PaulCapestany [~PaulCapes@ip72-209-228-52.dc.dc.cox.net] has quit [Ping timeout: 240 seconds] 10:23 -!- wxxs [~chatzilla@109.236.91.108] has joined #bitcoin-core-dev 10:24 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev 10:35 -!- ThomasV [~thomasv@unaffiliated/thomasv] has joined #bitcoin-core-dev 10:41 -!- PaulCapestany [~PaulCapes@ip72-209-228-52.dc.dc.cox.net] has joined #bitcoin-core-dev 10:42 < ThomasV> is it true that core will let users reuse the same private key in p2pkh, p2wpkh and p2wpkh-in-p2sh ? 10:42 < ThomasV> sipa: ^ 10:42 < chainhead> if they use addwitnessaddress 10:47 < jl2012> if it is compressed key, and with addwitnessaddress 10:49 -!- vicenteH [~user@195.235.96.150] has quit [Ping timeout: 255 seconds] 10:50 < sipa> ThomasV: for now, yes, we have no choice 10:50 < ThomasV> no choice?? 10:51 < sipa> that's how addwitnessafdress already works 10:51 < ThomasV> sipa: if you release that, you will have to keep supporting that forever 10:51 < sipa> ThomasV: addwitnessaddress has existed since 0.13.0 10:51 < ThomasV> because users will expect to see their coins when they import an address 10:52 < ThomasV> do you plan to do something about that? 10:52 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 10:52 < 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 10:53 < sipa> and perhaps deprecate importprivkey in favor of importmulti (which requires passing all relevant information) 10:53 -!- aashu [db5b99a8@gateway/web/freenode/ip.219.91.153.168] has joined #bitcoin-core-dev 10:53 < aashu> join 10:54 < 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 10:54 -!- aashu [db5b99a8@gateway/web/freenode/ip.219.91.153.168] has quit [Client Quit] 10:54 -!- duringo [~duringo@173.234.62.164] has joined #bitcoin-core-dev 10:54 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 248 seconds] 10:55 < 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) 10:56 < ThomasV> well, p2pk is a bit different, because you do not create a bitcoin address for it 10:57 < 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? 10:57 < ThomasV> ghost43: that's what I want to avoid 10:58 < ThomasV> that would encourage key reuse 10:58 < 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 10:58 < sipa> ThomasV: i understand 11:01 < 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 11:01 < sipa> but that's not how things work now 11:02 < ThomasV> sipa: a key is just a key, but the serialization of a key is not just a key 11:02 < ThomasV> it has a byte that disambiguates compressed/uncompressed 11:02 < ThomasV> and that's a good thing 11:02 < ThomasV> we really need to extend that 11:03 < sipa> i disagree 11:03 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 11:03 < goatpig> maybe it's time to agree on a set of identifiers for common script types 11:03 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit] 11:03 < sipa> if you want to import an address, give the address; if you want to spend from it, give its associated key 11:03 -!- tknp [~tknp@unaffiliated/tknp] has joined #bitcoin-core-dev 11:03 < sipa> i think it's unmaintainable to keep implying the address from just the key 11:04 < goatpig> not as a requirement, but just allow those wallets who want to to forward that information in a standardized fashion? 11:04 < sipa> give the address + privkey? 11:05 < sipa> importing addresses doesn't sound like something a normal user would do frequently 11:05 < goatpig> no they usually import the privkey 11:05 < ghost43> give the full scriptPubKey + the private key, haha 11:05 < goatpig> expect the software they using it with to know which scripts to look for on chain 11:05 < goatpig> cant tell if this is just pebkac and should be ignored, or if there is a need to cover this case 11:06 < goatpig> but it exists alright 11:06 < sipa> i expect the same issue does exist at least for importing hd chains, though 11:06 < goatpig> now it does 11:06 < goatpig> before, not necessarely 11:06 < ThomasV> sipa: that's interesting. why dont you post that in the ML? 11:06 < goatpig> if you stick to BIP44, p2pkh is basically implied 11:06 < sipa> ghost43: right 11:06 < sipa> ThomasV: i hate the ml 11:06 < ThomasV> goatpig: please no bip44 11:07 < goatpig> ThomasV: is that a voldermort moment? 11:07 < ThomasV> sipa: if you hate it, why did you answer to my post? 11:07 < sipa> i felt i had to 11:08 < ThomasV> yeah, but you kept the real annsyer until now 11:08 < sipa> hmm? 11:08 < sipa> you're asking my opinion 11:08 < ThomasV> I asked what core plans to do regarding key imports 11:08 < ThomasV> oh come on.. 11:08 < sipa> ah, right 11:08 < ThomasV> your opinion counts 11:09 < sipa> let me find the mail 11:10 < ghost43> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/015007.html 11:11 < ThomasV> goatpig: I guess you know what I think of bip44 11:11 < goatpig> oh i do 11:11 < goatpig> i agree with your position on the WIF thing 11:11 < goatpig> extending it would help 11:12 < goatpig> otherwise, id fall back on Lombrozo's BIP124 and flesh that out? 11:12 < ThomasV> goatpig: bip124 is not really specified 11:13 < goatpig> therefor it wont be as resistant to proposals 11:14 < ThomasV> goatpig: I am interested in it too 11:15 < goatpig> i mean the WIF is for single keys 11:15 < goatpig> but at least if we can agree on some stuff for entire chains 11:15 < ThomasV> well, if we had a decent bip124 we could use it for single keys too 11:18 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 11:20 < 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 11:21 < sipa> however, that doesn't mean there can't be a format that encapsulates both 11:21 < sipa> i'll respond on the list 11:21 < ThomasV> well, what is the point of having a serialization format, if it is not to encapsulate ? 11:22 -!- PaulCapestany [~PaulCapes@ip72-209-228-52.dc.dc.cox.net] has quit [Ping timeout: 240 seconds] 11:22 < sipa> ThomasV: well there can be separate formats, i guess 11:23 < 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 11:24 < sipa> right, sounds great 11:24 < ThomasV> so we can use hardware or software keystores in multisig wallets, with the same wallet class 11:25 < ThomasV> but I believe that what we export and show to users should be encapsulated 11:26 < sipa> right, but you also need a way to export/import a chain or address without revealing the key 11:26 < sipa> for an address that's easy, as it's just an address 11:27 < sipa> though i saw there was talk of including a birthtime too 11:27 < ThomasV> a wallet cannot import an address unless it is a special wallet type 11:27 < sipa> sure 11:27 < sipa> but i'm sure some software will exist that can import arbitrary individual addresses 11:29 < goatpig> and that's fine 11:29 < ThomasV> electrum can do it. my point is that wallet class does not have a keystore 11:29 < ThomasV> there is a wallet class that just means "a set of imported addresses" 11:29 < goatpig> the issue would be importing a private key and failing to find all funds that key can sign for 11:30 < sipa> goatpig: i think it's a terrible idea to treat every output you can sign for as your own 11:30 < ThomasV> there also is a keystore class for imported private keys, but it has nothing to do with imported addresses, and it assumes p2pkh 11:31 < 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) 11:31 < 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 11:32 < sipa> and i'm not opposed to such a convenience, but i don't have many opinions on it 11:32 < 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" 11:32 < ThomasV> sipa: current wallets allow to import private keys, and they assume p2pkh 11:33 < ThomasV> it is difficult to undo that 11:33 < sipa> ThomasV: we don't need to continue that practice 11:33 -!- duringo_ [~duringo@173.234.62.164] has joined #bitcoin-core-dev 11:33 < sipa> have a new private key format that does not have any implied address 11:34 < ThomasV> sipa: stop supporting privkey imports in core, and see how users will react :D 11:34 < sipa> ThomasV: i'm not saying we should stop supporting imports 11:34 < ThomasV> sipa: ok, I read you 11:35 < sipa> but the modern way of doing it is using importmulti, where you just give both the address and the private key 11:35 < sipa> (and the import checks that that private indeed can sign for that address) 11:35 < sipa> and if it's P2SH it also requires giving the relevant redeemscript 11:35 < goatpig> sipa: that could turn into a GUI nightmare, just saying 11:36 < sipa> goatpig: perhaps 11:36 < goatpig> well between expecting that much info from the user 11:36 -!- duringo [~duringo@173.234.62.164] has quit [Ping timeout: 240 seconds] 11:37 < goatpig> or agreeing to a header byte that refer to a table telling you how to derive the script hash 11:37 -!- PaulCapestany [~PaulCapes@ip72-209-228-52.dc.dc.cox.net] has joined #bitcoin-core-dev 11:37 < goatpig> obviously i'd pick the easy way out 11:37 < sipa> as said, i'm not opposed to a convenience method to encode all of it 11:37 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 248 seconds] 11:38 < ThomasV> sipa: what do you think of bip124? 11:38 < goatpig> i believe that's what we're hinting towards 11:38 < sipa> ThomasV: i haven't looked at it 11:38 < goatpig> it's a bit lean atm 11:39 < ThomasV> goatpig: all it needs is a way to extend script with variables 11:39 < sipa> so for example an issue i see is CLTV/CSV 11:39 < sipa> i expect people at some point will want a standard way of using these in scripts] 11:40 < sipa> an "address import" for one of those will need to include the locktime/sequence requirement number, or you can't derive the scriptPubKey 11:40 < ThomasV> right 11:40 < sipa> an approach that just requires you to pass the full scriptPubKey you're looking for is an elegant, but not perfectly convenient, method 11:41 < sipa> but as a 'raw' export/import function, i think that's totally acceptable 11:42 < goatpig> for cltv you could imply the position on the address chain is the cltv member 11:42 < goatpig> for csv idk if you can sneak around like that 11:43 < sipa> yuck. 11:43 < goatpig> aww 11:44 < sipa> cltv can have a locktime in seconds 11:44 < goatpig> i was thinking on the block count after confirmation variant only 11:44 < ThomasV> sipa: you mean the full script, not its hash? 11:45 < goatpig> sipa: you have to think of backups as well as imports in the case of cltv/csv 11:45 < sipa> ThomasV: yes, that's what importmulti requires 11:45 < goatpig> the least user inputed data, the better 11:46 < sipa> goatpig: well at least everything expect the private keys is much less sensitive 11:46 < sipa> but yes, you're right, that's an issue 11:46 < adiabat> it may also make sense to standardize on an importable utxo format, with optional privatekey field 11:47 < adiabat> I use this in my lightning software between wallet / lightning layer 11:47 -!- RoshHaShanaXT [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection] 11:47 < adiabat> could enable imports without rescanning or anything 11:48 < ThomasV> sipa: ok, so Iguess the issue is to find a good serialization for what importmulti needs 11:48 < sipa> ThomasV: for a subset, at least... 11:49 < sipa> unfortunately the checksum properties in bech32 degrade when there are more than 89 characters 11:49 < sipa> ThomasV: did you see my comment on your only-v0-witness commit? 11:49 < goatpig> use several lines, have a counter in each line 11:49 < ThomasV> sipa: yes I saw it 11:50 < sipa> goatpig: yuck :) 11:50 < goatpig> so mean! 11:50 < ThomasV> sipa: but soft forks are not so common, so I have time to think about it :) 11:50 < sipa> ThomasV: depends on how fast your users upgrafe 11:50 < ThomasV> yeah 11:50 < sipa> we saw with p2sh that it took years before every wallet was able to send to it 11:51 < sipa> i expect that for bip173 it will be less time, but i'd rather ot have that delay for every softfork 11:51 < ThomasV> I understand 11:51 < ThomasV> will do 11:51 < sipa> thanks! 12:00 < ThomasV> ok, dinner time 12:00 < sipa> ok, lunch time 12:05 -!- ThomasV [~thomasv@unaffiliated/thomasv] has quit [Ping timeout: 240 seconds] 12:08 < 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. 12:08 -!- alreadylate [~textual@c-250e71d5.153-1-64736c10.cust.bredbandsbolaget.se] has joined #bitcoin-core-dev 12:12 -!- wbobeirne [18677a34@gateway/web/freenode/ip.24.103.122.52] has joined #bitcoin-core-dev 12:15 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 12:15 -!- wbobeirne [18677a34@gateway/web/freenode/ip.24.103.122.52] has quit [Client Quit] 12:25 -!- Miezel [~Miezel@199.17.55.161] has joined #bitcoin-core-dev 12:35 -!- alreadylate [~textual@c-250e71d5.153-1-64736c10.cust.bredbandsbolaget.se] has quit [] 12:37 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 248 seconds] 12:41 -!- alreadylate [~textual@c-250e71d5.153-1-64736c10.cust.bredbandsbolaget.se] has joined #bitcoin-core-dev 12:42 -!- owowo [ovovo@gateway/vpn/mullvad/x-vombktikmwmrqlsl] has joined #bitcoin-core-dev 12:44 -!- wampy [~wampy@gateway/tor-sasl/wampy] has quit [Quit: leaving] 12:54 -!- vicenteH [~user@13.232.15.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 12:55 -!- PaulCapestany [~PaulCapes@ip72-209-228-52.dc.dc.cox.net] has quit [Ping timeout: 240 seconds] 12:57 -!- PaulCapestany [~PaulCapes@ip72-209-228-52.dc.dc.cox.net] has joined #bitcoin-core-dev 12:57 -!- timothy [~tredaelli@redhat/timothy] has quit [Remote host closed the connection] 12:58 < adiabat> gmaxwell: saw the post; looks interesting and not quite what I have, but something similar 12:58 < adiabat> github link in that doesn't seem to work though 12:58 < adiabat> (link from the mailing list post I mean) 12:59 -!- chjj [~chjj@unaffiliated/chjj] has quit [Quit: WeeChat 1.9] 13:02 -!- alreadylate [~textual@c-250e71d5.153-1-64736c10.cust.bredbandsbolaget.se] has quit [] 13:02 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 13:06 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Ping timeout: 248 seconds] 13:10 -!- Miezel_ [~Miezel@66-191-129-69.static.roch.mn.charter.com] has joined #bitcoin-core-dev 13:10 -!- Miezel [~Miezel@199.17.55.161] has quit [Ping timeout: 255 seconds] 13:12 < 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' 13:15 < sipa> no 13:15 < sipa> bitcoind doesn't have that information 13:16 -!- RubenSomsen [~RubenSoms@1.217.138.142] has quit [Ping timeout: 264 seconds] 13:17 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-mhptqbdplzujillq] has joined #bitcoin-core-dev 13:17 < 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 13:17 < goatpig> outpoint value? 13:19 < 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 13:19 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 13:19 < achow101> adiabat: which link? 13:20 < 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 13:20 < goatpig> yeah, you want the value of the outpoint the txin is pointing at 13:20 < goatpig> i dont think the RPC let's you request outpoints at all 13:21 < goatpig> well i guess the proper term is resolving the outpoint 13:22 < tknp> goatpid correct. was hoping to not have to make a secondary rpc call for each tx input with the proper vout value 13:22 < 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 13:23 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Ping timeout: 260 seconds] 13:23 < 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 13:24 < goatpig> im just guessing here 13:24 < goatpig> but i expect core has the dataset necessary to resolve arbitrary outpoints 13:24 < goatpig> or maybe not 13:24 < goatpig> that's just a guess on my part 13:24 < gmaxwell> Bitcoind doesn't have the information. 13:24 < goatpig> you need to resolve outpoints to verify incoming zero conf tx 13:24 < gmaxwell> Providing it would require an additional quite expensive index, or a sequential scan of the blockchain. 13:24 < sipa> it only has the information about unspent outputs 13:25 < gmaxwell> goatpig: yes but he is asking about getblock. 13:25 < goatpig> but you could do that by just maintaining the utxo set and checking outpoints in zc vs that 13:25 < sipa> which is sufficient for validating new blocks 13:25 < goatpig> well then he should use armory =D 13:25 < goatpig> cause it has a supernode teehee 13:25 < gmaxwell> and was unusably slow and will be again eventually. :P 13:26 < goatpig> =( so mean 13:26 < gmaxwell> haha 13:26 < goatpig> man it;s hard to keep up, i wrote the first supernode in 2013, blockchain is like 7 times as large now 13:26 < 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. 13:27 < goatpig> yes, just maintaining the dataset to resolve arbirtary tx hashes is expensive 13:27 < tknp> understood and thanks. i'll deal with making separate requests through other means 13:29 < achow101> gmaxwell: isn't txindex like that 13:29 < achow101> an index that can be used to grab arbitrary outpoints 13:30 < sipa> achow101: very inefficiently, yes 13:30 < gmaxwell> does it still even work? :( I stopped using it on all my hosts because its such a slowdown. 13:30 < sipa> (it read the entire block for each output you're looking up) 13:30 < achow101> gmaxwell: I use it on my node, seems to work 13:30 < achow101> but the index itself is 12 GB apparently 13:31 < 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 13:38 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev 13:39 -!- ThomasV [~thomasv@unaffiliated/thomasv] has joined #bitcoin-core-dev 13:41 < adiabat> I run txindex on mainnet and testnet3, it doesn't slow it down too much 13:41 < adiabat> then again I'm running on spinning disks so it's pretty slow no matter what :P 13:48 -!- owowo [ovovo@gateway/vpn/mullvad/x-vombktikmwmrqlsl] has quit [Ping timeout: 240 seconds] 14:13 -!- duringo [~Mutter@2605:a000:122c:400c:651f:d492:a072:88b0] has joined #bitcoin-core-dev 14:18 -!- duringo [~Mutter@2605:a000:122c:400c:651f:d492:a072:88b0] has quit [Remote host closed the connection] 14:18 -!- duringo [~Mutter@2605:a000:122c:400c:651f:d492:a072:88b0] has joined #bitcoin-core-dev 14:37 -!- ThomasV [~thomasv@unaffiliated/thomasv] has quit [Ping timeout: 240 seconds] 14:41 -!- wxxs [~chatzilla@109.236.91.108] has quit [Ping timeout: 260 seconds] 14:44 < Sentineo> I run txindex on an odroid xu4 14:44 < Sentineo> works fine too, usb stick has the blockchain 14:45 < Sentineo> syncing is a pain in the b, but otherwise kt is fine 14:55 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has quit [Remote host closed the connection] 15:10 -!- Cheeseo [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has joined #bitcoin-core-dev 15:11 -!- Miezel_ [~Miezel@66-191-129-69.static.roch.mn.charter.com] has quit [Quit: This computer has gone to sleep] 15:14 < 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 15:22 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Ping timeout: 248 seconds] 15:22 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev 15:26 -!- duringo [~Mutter@2605:a000:122c:400c:651f:d492:a072:88b0] has quit [Remote host closed the connection] 15:48 -!- Cory [~Cory@unaffiliated/cory] has quit [Ping timeout: 248 seconds] 15:49 -!- cheese_ [~Cheeseo@unaffiliated/cheeseo] has joined #bitcoin-core-dev 15:53 -!- Cory [~Cory@unaffiliated/cory] has joined #bitcoin-core-dev 15:54 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 15:55 -!- Aaronva__ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 15:57 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 255 seconds] 15:59 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds] 16:10 -!- owowo [ovovo@gateway/vpn/mullvad/x-yupmkteumiajvaxn] has joined #bitcoin-core-dev 16:13 -!- Geoffy [~Geo@178-119-187-213.access.telenet.be] has quit [] 16:35 -!- Aaronva__ is now known as AaronvanW 16:40 -!- rockhouse [~rockhouse@unaffiliated/rockhouse] has quit [Ping timeout: 260 seconds] 16:43 -!- cheese_ [~Cheeseo@unaffiliated/cheeseo] has quit [Ping timeout: 240 seconds] 16:46 -!- Cheeseo [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has quit [Ping timeout: 248 seconds] 16:47 < bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/551d7bf604fb...98212745c8ac 16:47 < bitcoin-git> bitcoin/master 05cae8a Marko Bencun: range-based loops and const qualifications in net.cpp... 16:47 < bitcoin-git> bitcoin/master 9821274 Pieter Wuille: Merge #10888: range-based loops and const qualifications in net.cpp... 16:47 < 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 16:53 -!- rockhouse [~rockhouse@unaffiliated/rockhouse] has joined #bitcoin-core-dev 16:54 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev 16:57 -!- chjj [~chjj@unaffiliated/chjj] has quit [Client Quit] 16:57 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.] 16:58 -!- abpa [~abpa@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Textual IRC Client: www.textualapp.com] 17:07 -!- duringo [~duringo@2605:a000:122c:400c:e17d:4734:9f10:270] has joined #bitcoin-core-dev 17:07 -!- duringo [~duringo@2605:a000:122c:400c:e17d:4734:9f10:270] has quit [Client Quit] 17:10 -!- duringo_ [~duringo@173.234.62.164] has quit [Ping timeout: 240 seconds] 17:21 < bitcoin-git> [bitcoin] TheBlueMatt opened pull request #11377: Disallow uncompressed pubkeys in bitcoin-tx [multisig] output adds (master...2017-09-bitcoin-tx-uncompressed-segwit) https://github.com/bitcoin/bitcoin/pull/11377 17:30 -!- goatpig [56f75683@gateway/web/freenode/ip.86.247.86.131] has quit [Quit: Page closed] 17:43 < phantomcircuit> gmaxwell, why wouldn't it work? 17:43 < phantomcircuit> it's just slowish 17:54 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-magcuiqaxtfrudgo] has quit [Quit: Connection closed for inactivity] 17:58 < bitcoin-git> [bitcoin] btc1-prevention opened pull request #11378: Update COPYING (master...patch-1) https://github.com/bitcoin/bitcoin/pull/11378 18:01 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has joined #bitcoin-core-dev 18:02 -!- JackH [~laptop@2a02:a210:2e00:300:655a:7cbf:d627:81fb] has quit [Ping timeout: 240 seconds] 18:15 < bitcoin-git> [bitcoin] fanquake closed pull request #11378: Update COPYING (master...patch-1) https://github.com/bitcoin/bitcoin/pull/11378 18:17 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 18:22 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Ping timeout: 240 seconds] 18:26 -!- StopAndDecrypty is now known as StopAndDecrypt 18:45 -!- Miezel [~Miezel@64-83-208-26.static.stcd.mn.charter.com] has joined #bitcoin-core-dev 18:51 -!- RubenSomsen [~RubenSoms@1.217.138.142] has joined #bitcoin-core-dev 18:56 -!- thrasher` [~thrasher@unaffiliated/thrasher/x-7291870] has quit [Ping timeout: 252 seconds] 18:58 -!- thrasher` [~thrasher@unaffiliated/thrasher/x-7291870] has joined #bitcoin-core-dev 18:59 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 264 seconds] 19:05 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 19:20 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 19:25 -!- rosenfs_ [~rosenfs@shairosenfeld.com] has quit [Ping timeout: 240 seconds] 19:25 -!- tknp [~tknp@unaffiliated/tknp] has quit [Quit: tknp] 19:45 -!- JackH [~laptop@ip-213-127-56-186.ip.prioritytelecom.net] has joined #bitcoin-core-dev 19:48 -!- Giszmo [~leo@pc-204-28-214-201.cm.vtr.net] has quit [Quit: Leaving.] 19:48 -!- harrymm [~harrymm@85.203.47.39] has quit [] 19:50 -!- harrymm [~harrymm@85.203.47.66] has joined #bitcoin-core-dev 19:51 -!- harrymm1 [~wayne@85.203.47.39] has quit [Ping timeout: 240 seconds] 19:52 -!- harrymm_ [~harrymm@85.203.47.66] has joined #bitcoin-core-dev 19:53 -!- harrymm_ [~harrymm@85.203.47.66] has left #bitcoin-core-dev [] 20:16 < meshcollider> Is anything in the share/certs/ directory actually relevant anymore? Seems pretty outdated 20:21 < achow101> meshcollider: yes, that's information about the codesigning certs 20:22 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection] 20:22 < achow101> the threat mitigation part is outdated I think because of the detached sigs thing. the codesigned binaries are now gitian built 20:23 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev 20:29 < kallewoof> Would it be worth it to add a replay protection mechanism in Bitcoin where a NOP is replaced with OP_CHECKBLOCKVERIFY which would fail if the hash of the block at the given height did not match ? (It would probably require that was less than - 100 to avoid nasty double spends at reorgs...) 20:31 < kallewoof> Actually, I don't think that would solve anything, since old UTXOs would still be replayed, just unspendable. Nevermind. 20:33 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 246 seconds] 20:36 < achow101> meshcollider: well I suppose the keys there are outdated as it looks like the codesigned stuff uses a more recent cert 20:36 < achow101> cfields: would you mind updating that? or do you think it should be removed entirely? 20:37 < meshcollider> achow101: yeah that's what I thought, this is stuff from 5 years ago 20:38 < achow101> meshcollider: the keys there are expired too 20:44 < cfields> achow101: yea, i think it can just be removed. The signing process is documented (and scripted) 20:44 < achow101> cfields: where is it documented? 20:44 < cfields> achow101: in the gitian build instructions 20:45 < achow101> oh I see. 20:45 < achow101> where is this script: detached-sig-create.sh? 20:45 < achow101> I only see one for osx 20:45 < bitcoin-git> [bitcoin] MeshCollider opened pull request #11380: Remove outdated share/certs/ directory (master...201709_remove_old_certs) https://github.com/bitcoin/bitcoin/pull/11380 20:45 < achow101> and not one for windows 20:45 < cfields> I've helped a few other projects (litecoin, for ex), build using our process. The last one (i forget who, now) was able to sign without my assistance. 20:45 -!- RubenSomsen [~RubenSoms@1.217.138.142] has quit [Ping timeout: 260 seconds] 20:46 < cfields> hmm, we have one for windows as of 0.15. surely i updated the instructions for it. Checking. 20:47 < cfields> (the script/cert are in contrib/windeploy ) 20:47 < achow101> ah, I see it now. 20:47 < achow101> missed that earlier 20:48 < achow101> no certs for osx? (I don't see any in macdeploy) 20:48 < cfields> well, there aren't instructions in that gitian doc like i thought there were. Will add. 20:49 < achow101> the gitian doc has instructions for running the scripts 20:49 < achow101> err the release process doc 20:49 < meshcollider> cfields: might be in the release process doc 20:50 < cfields> no, I got distracted from finishing the osx tool, so committed osx certs can't be used yet 20:50 < cfields> ah, maybe that's it 20:50 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 20:51 < cfields> anyway, gitian spits out "*unsigned.tar.gz", which the signer just untars and runs ./detached-sig-create.sh. Very straigtforward. 20:51 < cfields> but if it's not fully written up, I can do so 20:52 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection] 20:52 < achow101> it's written up here: https://github.com/bitcoin/bitcoin/blob/master/doc/release-process.md#next-steps 20:52 -!- RubenSomsen [~RubenSoms@1.217.138.142] has joined #bitcoin-core-dev 20:52 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev 20:52 < achow101> why are there 3 certs in win-codesign.cert? 20:52 < achow101> oh, 2 are comodo's and one is ours 20:52 < cfields> yea, there we go 20:52 < cfields> yea, it's the whole chain 20:53 < achow101> Is the osx one the same as the one in share/certs? 20:53 < achow101> it expires in 2018 20:55 < cfields> probably so 20:55 < meshcollider> so they should be moved instead of removed? 20:56 < achow101> meshcollider: the windows one should be removed 20:56 < achow101> don't know about the osx one, but it probably can't be used with the osx script provided in contrib/macdeploy 20:56 < achow101> (I don't have a mac to check if the signature matches that cert) 20:57 < cfields> the stuff in share/certs is informational only, it isn't used atm 20:57 < cfields> the windows certs in contrib/windeploy are actually used by the signing/re-attaching process 20:58 < cfields> the cert chain could be ripped out of an osx binary with some hacking (or maybe there's a tool for it?) 20:59 < achow101> cfields: is there some way to check the detached sigs? 21:00 < cfields> what do you mean by check? 21:00 < achow101> like extract the chain out of them 21:00 < achow101> or see if they verify to that cert 21:02 -!- RubenSomsen [~RubenSoms@1.217.138.142] has quit [Ping timeout: 240 seconds] 21:03 < cfields> checking 21:10 < cfields> the 0.15.0.1 binary contains the same localKeyID as the committed .pem 21:12 < achow101> ok, thanks 21:12 < achow101> I wonder if gavin made bitcoin xt or bitcoin classic releases signed with that key... 21:14 < cfields> not afaik 21:15 < cfields> fwiw: https://pastebin.com/raw/UZKRpdPc 21:15 < achow101> I assume that he isn't stupid enough to do that 21:15 < cfields> anyone on osx can reproduce ^^ 21:16 < achow101> is codesign some osx utility? 21:16 < cfields> yea 21:17 -!- tknp [~tknp@unaffiliated/tknp] has joined #bitcoin-core-dev 21:17 < cfields> i patched an ios tool to do osx signing a while ago. It's 99% ready, just never finished it/hooked it up 21:18 < cfields> https://github.com/theuni/osx-codesign 21:19 < achow101> why? 21:19 * luke-jr wonders how hard it would be to get iOS and Android builds of the GUI 21:19 -!- RubenSomsen [~RubenSoms@1.217.138.142] has joined #bitcoin-core-dev 21:19 < achow101> luke-jr: supposedly qt supports android in some way 21:19 < cfields> achow101: why what? 21:19 < luke-jr> achow101: yes, or I wouldn't even consider it a possibility :p 21:20 < luke-jr> (it also supports iOS) 21:20 < achow101> cfields: why did you make an osx signing tool if there already is one? 21:20 < achow101> (the one existing being whatever is used now) 21:20 < achow101> luke-jr: it does? 21:20 < luke-jr> achow101: yes 21:21 < luke-jr> http://doc.qt.io/qt-5/ios-support.html 21:21 < cfields> achow101: oh, sorry. portable tool. Works from Linux. 21:22 < achow101> cfields: ah. ok. I figured it was probably also that it is open source 21:22 < cfields> achow101: well most (all?) of osx userspace is open-source. It's just a tangled web. 21:23 < luke-jr> cfields: pretty sure the GUI stuff isn't? 21:24 < cfields> luke-jr: that would make sense 21:29 < meshcollider> luke-jr: that can't even be considered until SPV mode is added though right, no way android is going to run Qt with even a pruned blockchain and full UTXO set lol 21:31 < achow101> meshcollider: it can run bitcoind 21:31 < achow101> look up ABCore 21:32 < achow101> and android devices (smartphones in general) are getting more powerful and have more ram 21:32 < cfields> meshcollider: no reason why it should be less performant than gnu/linux on an arm machine 21:35 < meshcollider> hmm that's true, I've just never even considered trying to run a full node on a smartphone 21:35 < meshcollider> that's an interesting idea 22:00 -!- tknp [~tknp@unaffiliated/tknp] has quit [Quit: tknp] 22:23 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection] 22:23 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev 22:58 -!- PRab [~chatzilla@c-68-56-234-28.hsd1.mi.comcast.net] has quit [Ping timeout: 248 seconds] 23:05 -!- PRab [~chatzilla@c-68-56-234-28.hsd1.mi.comcast.net] has joined #bitcoin-core-dev 23:22 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has joined #bitcoin-core-dev 23:39 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 23:42 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 23:48 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]