--- Day changed Mon Jun 20 2016 00:02 -!- frankenmint [~frankenmi@67-5-211-132.ptld.qwest.net] has quit [Remote host closed the connection] 00:06 -!- frankenmint [~frankenmi@67-5-211-132.ptld.qwest.net] has joined #bitcoin-core-dev 00:12 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has quit [Ping timeout: 252 seconds] 00:18 -!- Cheeseo [~x@unaffiliated/cheeseo] has quit [Read error: Connection reset by peer] 00:18 -!- cheese_ [~x@unaffiliated/cheeseo] has quit [Read error: Connection reset by peer] 00:23 -!- [Author] [~Author]@2401:a400:3202:2000:bad:d09:15:90d] has quit [Ping timeout: 240 seconds] 00:28 -!- xiangfu [~xiangfu@58.135.95.132] has quit [Ping timeout: 260 seconds] 00:28 -!- [Author] [~Author]@2401:a400:3202:2000:bad:d09:15:90d] has joined #bitcoin-core-dev 00:30 -!- xiangfu [~xiangfu@58.135.95.132] has joined #bitcoin-core-dev 00:35 -!- frankenmint [~frankenmi@67-5-211-132.ptld.qwest.net] has quit [Remote host closed the connection] 00:45 -!- kanzure [~kanzure@unaffiliated/kanzure] has quit [Ping timeout: 244 seconds] --- Log closed Mon Jun 20 00:46:00 2016 --- Log opened Mon Jun 20 00:48:59 2016 00:48 -!- kanzure [~kanzure@unaffiliated/kanzure] has joined #bitcoin-core-dev 00:49 -!- Irssi: #bitcoin-core-dev: Total of 144 nicks [1 ops, 0 halfops, 0 voices, 143 normal] 01:00 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 01:02 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev --- Log closed Mon Jun 20 01:03:17 2016 --- Log opened Mon Jun 20 01:06:41 2016 01:06 -!- kanzure [~kanzure@unaffiliated/kanzure] has joined #bitcoin-core-dev 01:06 -!- Irssi: #bitcoin-core-dev: Total of 144 nicks [1 ops, 0 halfops, 0 voices, 143 normal] 01:16 -!- frankenmint [~frankenmi@67-5-211-132.ptld.qwest.net] has joined #bitcoin-core-dev 01:18 -!- xiangfu [~xiangfu@58.135.95.132] has quit [Ping timeout: 250 seconds] 01:18 -!- G1lius [stefangili@91.179.154.4] has joined #bitcoin-core-dev 01:18 < GitHub74> [bitcoin] laanwj opened pull request #8227: tests: Try re-enabling RPC tests for Windows (master...2016_05_win_reenable_rpc_tests) https://github.com/bitcoin/bitcoin/pull/8227 01:20 -!- xiangfu [~xiangfu@58.135.95.132] has joined #bitcoin-core-dev 01:25 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev 01:27 -!- xiangfu [~xiangfu@58.135.95.132] has quit [Ping timeout: 272 seconds] 01:32 -!- Irssi: Join to #bitcoin-core-dev was synced in 1753 secs 01:33 < GitHub38> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/a072d1a83787...223bf831cc81 01:33 < GitHub38> bitcoin/master 7734479 Will Binns: readme: Omit phrasing; 'new'... 01:33 < GitHub38> bitcoin/master 223bf83 Wladimir J. van der Laan: Merge #8224: readme: Omit phrasing; 'new'... 01:33 < GitHub45> [bitcoin] laanwj closed pull request #8224: readme: Omit phrasing; 'new' (master...binns-update-readme) https://github.com/bitcoin/bitcoin/pull/8224 01:34 <@wumpus> jonasschnelli: ok! 01:39 -!- ws2k3 [freenodeyc@bnc.freegamehosting.eu] has quit [Ping timeout: 252 seconds] 01:45 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has quit [] 01:45 -!- ws2k3 [freenodeyc@bnc.freegamehosting.eu] has joined #bitcoin-core-dev 01:49 < GitHub138> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/223bf831cc81...377d1310acc7 01:49 < GitHub138> bitcoin/master 9e3ec74 Nathaniel Mahieu: Clarify documentation for running a tor node... 01:49 < GitHub138> bitcoin/master 377d131 Wladimir J. van der Laan: Merge #8203: Clarify documentation for running a tor node... 01:49 < GitHub27> [bitcoin] laanwj closed pull request #8203: Clarify documentation for running a tor node (master...master) https://github.com/bitcoin/bitcoin/pull/8203 01:55 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 01:55 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has joined #bitcoin-core-dev 02:10 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has joined #bitcoin-core-dev 02:18 -!- xiangfu [~xiangfu@58.135.95.134] has joined #bitcoin-core-dev 02:18 -!- xiangfu [~xiangfu@58.135.95.134] has quit [Remote host closed the connection05:53 < GitHub79> [bitcoin] laanwj pushed 6 new commits to master: https://github.com/bitcoin/bitcoin/compare/f6598df76583...94ab58b5ccda 05:53 < GitHub79> bitcoin/master 1b0bcc5 Pieter Wuille: Track orphan by prev COutPoint rather than prev hash 05:53 < GitHub79> bitcoin/master db0ffe8 Gregory Maxwell: This eliminates the primary leak that causes the orphan map to... 05:53 < GitHub79> bitcoin/master 11cc143 Gregory Maxwell: Adds an expiration time for orphan tx.... 05:54 < GitHub70> [bitcoin] laanwj closed pull request #8179: Evict orphans which are included or precluded by accepted blocks. (master...reap_orphans) https://github.com/bitcoin/bitcoin/pull/8179 06:00 <@wumpus> what are we going to do for RBF in 0.13? 06:00 < btcdrak> wasnt jonasschnelli going to simplify his patch? 06:02 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 06:14 <@wumpus> but what about eg. https://github.com/bitcoin/bitcoin/pull/7817 06:19 <@wumpus> or the bumpfee command https://github.com/bitcoin/bitcoin/pull/7865 06:21 < GitHub43> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/94ab58b5ccda...1f86d64f6d87 06:21 < GitHub43> bitcoin/master ad0752e Pieter Wuille: Stop trimming when mapTx is empty 06:21 < GitHub43> bitcoin/master 1f86d64 Wladimir J. van der Laan: Merge #8220: Stop trimming when mapTx is empty... 06:21 < GitHub160> [bitcoin] laanwj closed pull request #8220: Stop trimming when mapTx is empty (master...notrimempty) https://github.com/bitcoin/bitcoin/pull/8220 06:30 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has quit [Read error: Connection reset by peer] 06:30 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-core-dev 06:38 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 252 seconds] 06:38 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev 06:46 <@wumpus> or what about importmulti: https://github.com/bitcoin/bitcoin/pull/7551 ? also still has the 0.13 milestone, and pedrobranco did a lot of work on it the last week 06:52 <@wumpus> nah probably just too late 06:52 <@wumpus> kind of unfortunate the things that almost made it into 0.13, on the other hand, at least 0.14 will have some useful featurs 06:53 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 06:56 -!- molly [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 07:14 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has joined #bitcoin-core-dev 07:23 < instagibbs> I assume there's a function to parse unsigned char array into hex string in Core? Can't think of it at the moment. 07:23 < sipa> yes, it's called ParseHex :) 07:23 < sipa> in utilstrencodings 07:24 < sipa> wumpus: agree, importmulti is late 07:24 < sipa> too bad :( 07:24 < instagibbs> ParseHex goes hex str to bytes 07:24 < instagibbs> I need the opposite :P 07:24 < instagibbs> ill look around there though 07:25 < Chris_Stewart_5> instagibbs: Possibly some where around here? https://github.com/bitcoin/bitcoin/blob/master/src/serialize.h#L510 07:25 -!- [Author] [~Author]@2401:a400:3202:2000:bad:d09:15:90d] has quit [Ping timeout: 250 seconds] 07:25 < instagibbs> HexStr maybe 07:26 < sipa> HexStr indeed 07:26 < instagibbs> thanks 07:26 < sipa> instagibbs: i wouldn't call that parsing, though :) 07:26 < sipa> but that's a semantics discussion 07:27 < instagibbs> eh true enough 07:29 -!- JackH [~Jack@79-73-186-51.dynamic.dsl.as9105.com] has quit [Quit: Leaving] 07:30 -!- [Author] [~Author]@2401:a400:3202:2000:bad:d09:15:90d] has joined #bitcoin-core-dev 07:32 < pedrobranco> wumpus: yes, unfortunately i was late in importmulti :( 07:33 < pedrobranco> will need some help in adding some features, and how importmulti should work in some situations 07:34 < pedrobranco> look forward to finish the importmulti :) 07:35 -!- raedah [~x@172.56.42.64] has quit [Remote host closed the connection] 07:36 -!- raedah [~x@172.56.42.64] has joined #bitcoin-core-dev 08:12 -!- JackH [~Jack@79-73-186-51.dynamic.dsl.as9105.com] has joined #bitcoin-core-dev 08:13 -!- JackH [~Jack@79-73-186-51.dynamic.dsl.as9105.com] has quit [Client Quit] 08:14 -!- JackH [~Jack@79-73-186-51.dynamic.dsl.as9105.com] has joined #bitcoin-core-dev 08:20 -!- Sosumi [~Leon@bl10-113-190.dsl.telepac.pt] has joined #bitcoin-core-dev 08:27 -!- Cheeseo [~x@c-174-54-219-36.hsd1.pa.comcast.net] has joined #bitcoin-core-dev 08:27 -!- Cheeseo [~x@c-174-54-219-36.hsd1.pa.comcast.net] has quit [Changing host] 08:27 -!- Cheeseo [~x@unaffiliated/cheeseo] has joined #bitcoin-core-dev 08:39 -!- G1lius [stefangili@91.179.154.4] has quit [] 08:49 < jonasschnelli> wumpus: btcdrak: I have plans to split the bumpfee PR into two parts (one to add opt-in feature to CreateTransaction() another for the bumpfee). 08:50 < jonasschnelli> Both parts needs review and are not ready for 0.13 08:50 < jonasschnelli> We could merge petertodds global RBF opt-in PR though 08:50 < jonasschnelli> But 0.13 will have no bump feature. 08:50 < jonasschnelli> (only over rawtx) 08:52 < Chris_Stewart_5> cfields_: If you could take a look at the question and give me some insight it would be much appreciated https://bitcoin.stackexchange.com/questions/46062/add-dependency-bitcoin-core 08:53 < jonasschnelli> Chris_Stewart_5: cfields_ is currently away (for multiple days) 08:53 < jonasschnelli> But I'm familiar with the dependencies build system... I'll have a look 08:55 < Chris_Stewart_5> jonasschnelli: It would be much appreciated :-) 08:55 < sipa> i assume that you'll need autoconf magic to find the library 08:57 < Chris_Stewart_5> Ooh, things happening 'auto-magically' 08:57 < jonasschnelli> Chris_Stewart_5: I'm not very familiar with cmake...but I guess sipa is right 08:57 < jonasschnelli> You need to find the library in configure.ac 08:57 < jonasschnelli> Otherwise you don't have the corresponding -I and -L CXXFLAG 08:58 < jonasschnelli> adding the library to the depends/ system alone is not sufficient. 08:58 < jonasschnelli> Chris_Stewart_5: you need something like https://github.com/Christewart/bitcoin/blob/master/configure.ac#L551 08:59 < sipa> it will first need to work when just building normally 08:59 < sipa> depends is to make it work deterministically 08:59 < Chris_Stewart_5> sipa: What is the difference? I'm not super familiar C++ build systems 09:00 < sipa> Chris_Stewart_5: forget depends 09:00 < Chris_Stewart_5> Ok, and just try and link the file from the command line or something? 09:00 < sipa> Chris_Stewart_5: no, i mean, first make things work the normal way (add source files to makefile.am, make configure.ac find the dependency, ...) 09:01 < jonasschnelli> Agree with sipa. 09:01 < sipa> so autogen & configure & make work 09:01 < sipa> depends is the step afterwards, you don't need depends when just building through makr 09:01 < sipa> *make 09:01 < Chris_Stewart_5> Ok, i'll start off in that direction then. Thanks 09:32 -!- laurentmt [~Thunderbi@213-245-86-6.rev.numericable.fr] has joined #bitcoin-core-dev 09:33 -!- laurentmt [~Thunderbi@213-245-86-6.rev.numericable.fr] has quit [Client Quit] 09:46 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 272 seconds] 09:48 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 09:55 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has left #bitcoin-core-dev [] 09:57 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 276 seconds] 10:08 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds] 10:21 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 10:25 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 246 seconds] 10:35 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Remote host closed the connection] 10:36 -!- aureianimus__ [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev 10:36 -!- aureianimus_ [~quassel@s55963df3.adsl.online.nl] has quit [Read error: Connection reset by peer] 10:38 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev 10:42 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Ping timeout: 244 seconds] 10:45 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 10:47 < GitHub130> [bitcoin] thelazier opened pull request #8230: Fix LogPrint to LogPrintf (0.12...patch-1) https://github.com/bitcoin/bitcoin/pull/8230 10:49 -!- frankenmint [~frankenmi@67-5-211-132.ptld.qwest.net] has joined #bitcoin-core-dev 10:50 < rubensayshi> sipa, wumpus recall the discussion about bare multisig 10:50 < rubensayshi> I have some1 with BTC in an actual bare multisig which is now essentially unspendable :( 10:51 < gmaxwell> How'd they even create the txouts? 10:51 < rubensayshi> from before v0.21.1 10:51 < rubensayshi> 12 10:52 < gmaxwell> rubensayshi: no version of bitcoin core will ever create bare multisig outputs. 10:52 < rubensayshi> yea, so it was created with counterwallet, which does bare multisig 10:53 < rubensayshi> didn't really expect people to use it, but they do xD 10:53 < btcdrak> rubensayshi: maybe create a signed tx spending it and ask a pool to mine it kindly. 10:53 < rubensayshi> there's probably other people outside of counterparty users with the same issue .. though I agree it's rare 10:54 < gmaxwell> large ones aren't even IsStandard to pay to. 10:54 < gmaxwell> Whats the txid:vout? 10:54 < rubensayshi> c6d964ea9a27e125c1b40188e9aee191aac03adc4c53ec811d9d2ce74c380768:2 10:55 < rubensayshi> there's a release scheduled with P2SH support for the counterparty backend, I guess I should double down on adding it to the wallet and making something to migrate 10:55 < gmaxwell> rubensayshi: that havs value 0.00635110 10:55 < rubensayshi> and poke around pools to find one that's willing to mine the TXs 10:56 < gmaxwell> and was created 16 days ago. 10:56 < rubensayshi> if there's 1 then there's others ... 10:57 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 10:57 < gmaxwell> rubensayshi: I misread your earlier text and thought you said "some 1 BTC". 10:58 < rubensayshi> nah, this case is just a fraction 10:58 < rubensayshi> though there's counterparty tokens bound to it 10:58 < rubensayshi> I can probably find a miner to fix this for counterparty 10:59 < rubensayshi> I'm just brining it up cause there's probably more, let me query the blocktrail DB to see how much value there's stuck in bare multisig 11:00 -!- molly [~molly@unaffiliated/molly] has quit [Ping timeout: 244 seconds] 11:00 -!- pedrobranco [~pedrobran@167.225.61.94.rev.vodafone.pt] has joined #bitcoin-core-dev 11:01 < gmaxwell> rubensayshi: probably your time would be better spent helping to get counterparty onto it's own network instead of trying to steganographically hide data in Bitcoin transactions. 11:02 < btcdrak> ^ 11:05 < gmaxwell> (Though I do wish we'd followed my suggestion of size=max(size, (sigops*MAX_BLOCK_SIZE+MAX_SIGOPS-1)//MAX_SIGOPS) ). 11:05 -!- pedrobranco [~pedrobran@167.225.61.94.rev.vodafone.pt] has quit [Ping timeout: 260 seconds] 11:05 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 264 seconds] 11:06 < rubensayshi> gmaxwell, wouldn't that result in non-full blocks again? 11:07 < rubensayshi> I thought the fix was about the blocks not being full, not about the fee per block earned? 11:08 < gmaxwell> I don't give a shit if the block is full or not, rational behavior for the miner is to maximize income, even if it doesn't fill the block. Ignorant people may howl about something not being full, but the only real issue in my mind was that the block would end up massively under full and not even making the expected income for the miner due to cheap attack transactions. 11:09 < gmaxwell> The attack was paying very low fees, and blocking out a whole block with it. What I suggested would end up making them have to pay roughly as much to fill the block with txdata or sigops, so why bother using sigops to fill it? 11:09 < gmaxwell> luke's argument was just that the transactions were clearly abusive and should be filtered even if they pay high fees. Which is a reasonable argument. 11:10 < gmaxwell> but not strictly needed to fix the problem. 11:11 < rubensayshi> hmm, your suggestion seems reasonable and not as complex as coding up a way to only add high sigops/byte txs if it doesn't push it over the limit 11:13 < gmaxwell> Seperately, bare multisig should become non-standard-- if for nothing else because it seriously burns up sigops space--, but that should happen on the creating it side first. 11:14 < rubensayshi> I agree 11:21 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 11:22 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 11:23 -!- molly [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 11:24 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 11:27 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 246 seconds] 11:33 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Quit: WeeChat 0.4.2] 11:33 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 11:34 < Chris_Stewart_5> What is the reasoning behind requiring standard transactions? Security? DOS prevention? 11:34 < Chris_Stewart_5> for relaying txs 11:37 < gmaxwell> Preserving forward compatiblity and reducing varrious abuse vectors. 11:45 -!- sanada [sanada@36-2-119-80.chiba.ap.gmo-isp.jp] has quit [Read error: Connection reset by peer] 11:48 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 264 seconds] 12:03 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 12:04 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 12:06 -!- molly [~molly@unaffiliated/molly] has quit [Ping timeout: 246 seconds] 12:09 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds] 12:24 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 12:44 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has quit [Ping timeout: 240 seconds] 12:53 -!- gavinandresen [~gavin@unaffiliated/gavinandresen] has quit [Ping timeout: 276 seconds] 13:02 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has joined #bitcoin-core-dev 13:09 -!- Sosumi [~Leon@bl10-113-190.dsl.telepac.pt] has quit [Quit: Bye] 13:09 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has quit [Read error: No route to host] 13:11 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 13:13 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has joined #bitcoin-core-dev 13:13 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 260 seconds] 13:16 -!- frankenmint [~frankenmi@67-5-211-132.ptld.qwest.net] has quit [Remote host closed the connection] 13:21 -!- Bootvis_ [bob@baltar.lan.endoria.net] has quit [Remote host closed the connection] 13:37 < midnightmagic> \o/ 13:46 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds] 13:47 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 13:54 < btcdrak> 25 blocks to go for CSV point of no return 14:09 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds] 14:11 < spudowiar> btcdrak: CSV? 14:11 < btcdrak> spudowiar: the current softfork bundle of BIP68,112,113. 14:12 < spudowiar> More confused but OK 14:12 < spudowiar> I'll check them BIPs out 14:12 < spudowiar> *dashes to GitHub* 14:12 < spudowiar> Anyway, I'm just dumb 14:13 -!- frankenmint [~frankenmi@67-5-211-132.ptld.qwest.net] has joined #bitcoin-core-dev 14:13 < spudowiar> Wow, that's cool 14:15 < spudowiar> btcdrak: is this the same as segwit? 14:15 < spudowiar> I'm dumb no need to answer if you don't want to 14:15 < spudowiar> I'm just curious :) 14:16 < btcdrak> no this is a different set of protocol changes. tldr allows for timelocking bitcoins relative to when they are first confirmed in a block 14:16 < spudowiar> I get that 14:16 < btcdrak> see BIP112 14:16 < spudowiar> But what's segwit then? 14:16 < btcdrak> BIP141 14:17 < spudowiar> Thanks :) 14:17 < spudowiar> Thanks for wasting your time with me :) 14:17 < btcdrak> (together with 143 and 144 also) 14:17 < spudowiar> I'm just an annoyance but a curious annoyance who's just trying to learb 14:17 < spudowiar> *learn 14:18 < btcdrak> spudowiar: :) 14:19 < spudowiar> I wish I was more mature and less annoying :/ 14:19 < spudowiar> Maybe when I'm an adult? :/ 14:19 < spudowiar> :( 14:23 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 14:27 * owowo thinks many ppl wonder if it's Comma Separated Value 14:58 < owowo> is it now 19 blocks left? I lost track... 14:59 < btcdrak> 18 15:01 < molz> btcdrak, how do you get that number? 15:01 < btcdrak> 1916-numberofcsvsignals 15:04 < molz> 1916-1898.. but where do you get 1916? 15:04 < molz> "sincePeriodStart": { 15:04 < molz> "total": 1968, 15:05 < btcdrak> BIP9 spec 15:05 -!- robs [uid165609@gateway/web/irccloud.com/x-yzdhbkjyimbzhhuh] has joined #bitcoin-core-dev 15:05 < btcdrak> prolly should be asking in #bitcoin or #bitcoin-dev 15:16 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Read error: Connection reset by peer] 15:17 -!- paveljanik [~paveljani@79-98-72-216.sys-data.com] has joined #bitcoin-core-dev 15:17 -!- paveljanik [~paveljani@79-98-72-216.sys-data.com] has quit [Changing host] 15:17 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev 15:41 -!- frankenmint [~frankenmi@67-5-211-132.ptld.qwest.net] has quit [Remote host closed the connection] 15:42 -!- xiangfu [~xiangfu@58.135.95.134] has joined #bitcoin-core-dev 15:43 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds] 15:43 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 15:55 -!- _anthony_ [~anthony@ec2-54-164-183-56.compute-1.amazonaws.com] has joined #bitcoin-core-dev 15:57 -!- molly [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 15:59 -!- frankenmint [~frankenmi@67-5-211-132.ptld.qwest.net] has joined #bitcoin-core-dev 16:01 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 260 seconds] 16:01 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)] 16:06 -!- _anthony_ [~anthony@ec2-54-164-183-56.compute-1.amazonaws.com] has quit [Quit: WeeChat 1.3] 16:07 -!- _anthony_ [~anthony@ec2-54-164-183-56.compute-1.amazonaws.com] has joined #bitcoin-core-dev 16:08 < _anthony_> what version number will the current version of core start using once CSV is activated? 16:09 < btcdrak> 0x20000000 16:10 < _anthony_> will any version number >=4 be valid? 16:10 < btcdrak> yes 16:10 < _anthony_> cool thanks 16:17 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 16:20 -!- molly [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 16:24 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-core-dev 16:54 -!- frankenmint [~frankenmi@67-5-211-132.ptld.qwest.net] has quit [Ping timeout: 244 seconds] 17:04 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds] 17:05 -!- alpalp [~allen@2605:6000:f4d6:d600:1cac:b3d4:4ce8:d0fe] has joined #bitcoin-core-dev 17:05 -!- alpalp [~allen@2605:6000:f4d6:d600:1cac:b3d4:4ce8:d0fe] has quit [Changing host] 17:05 -!- alpalp [~allen@unaffiliated/alpalp] has joined #bitcoin-core-dev 17:17 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 17:17 -!- alpalp [~allen@unaffiliated/alpalp] has quit [Ping timeout: 250 seconds] 17:26 -!- alpalp [~allen@2605:6000:f4d6:d600:1cac:b3d4:4ce8:d0fe] has joined #bitcoin-core-dev 17:26 -!- alpalp [~allen@2605:6000:f4d6:d600:1cac:b3d4:4ce8:d0fe] has quit [Changing host] 17:26 -!- alpalp [~allen@unaffiliated/alpalp] has joined #bitcoin-core-dev 17:41 -!- Guest77060 [~chatzilla@71-95-154-155.dhcp.mtpk.ca.charter.com] has joined #bitcoin-core-dev 17:43 -!- Guest77060 is now known as roidster 17:43 < _anthony_> the CSV fix is in :) 17:48 -!- jannes [~jannes@178.132.211.90] has quit [Quit: Leaving] 17:49 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 258 seconds] 17:58 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Ping timeout: 260 seconds] 18:01 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-fjebmjdlllscryxe] has quit [Quit: Connection closed for inactivity] 18:02 -!- afk11 [~afk11@109.255.154.81] has joined #bitcoin-core-dev 18:02 -!- afk11 [~afk11@109.255.154.81] has quit [Changing host] 18:02 -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-core-dev 18:05 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 18:13 -!- molly [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 18:17 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 18:29 -!- belcher [~user@unaffiliated/belcher] has quit [Quit: Leaving] 18:41 -!- fengling [~fengling@58.135.95.133] has joined #bitcoin-core-dev 18:59 -!- sanada [sanada@36-2-119-80.chiba.ap.gmo-isp.jp] has joined #bitcoin-core-dev 19:14 -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has quit [Ping timeout: 276 seconds] 19:28 -!- alpalp [~allen@unaffiliated/alpalp] has quit [Ping timeout: 249 seconds] 19:39 -!- pedrobranco [~pedrobran@167.225.61.94.rev.vodafone.pt] has joined #bitcoin-core-dev 19:41 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds] 19:43 -!- pedrobranco [~pedrobran@167.225.61.94.rev.vodafone.pt] has quit [Ping timeout: 240 seconds] 19:58 -!- adamg [~akg@50.242.93.33] has joined #bitcoin-core-dev 20:04 -!- fengling [~fengling@58.135.95.133] has quit [Read error: Connection reset by peer] 20:04 < luke-jr> cfields_: https://docs.travis-ci.com/user/ip-addresses/ 20:05 -!- zooko [~user@c-73-229-199-227.hsd1.co.comcast.net] has joined #bitcoin-core-dev 20:11 -!- fengling [~fengling@58.135.95.133] has joined #bitcoin-core-dev 20:21 -!- netsinn [~jiggalato@198.16.176.10] has joined #bitcoin-core-dev 20:21 -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has joined #bitcoin-core-dev 20:47 -!- _anthony_ [~anthony@ec2-54-164-183-56.compute-1.amazonaws.com] has quit [Quit: WeeChat 1.3] 20:52 -!- Sosumi [~Leon@bl10-113-190.dsl.telepac.pt] has joined #bitcoin-core-dev 21:00 -!- netsinn [~jiggalato@198.16.176.10] has quit [Remote host closed the connection] 21:27 -!- frankenmint [~frankenmi@67-5-211-132.ptld.qwest.net] has joined #bitcoin-core-dev 21:39 < jl2012> just want to confirm: during bip9 locked_in, blocks with any nVersion >=4 are valid? 21:45 < btcdrak> jl2012: what do you mean? once lockin is reached signalling is no longer required but recommended. 21:45 < jl2012> btcdrak: you have answered my question: no longer required 21:46 < jl2012> i think certains pools are setting their version manually 21:46 < jl2012> they have to turn it back to 0x20000000 at or before 419328 21:47 < jl2012> or that may trigger the unknown softfork warning 21:55 < jl2012> should we ask miners (who are manually setting the version) to change the version to 0x20000000 *at* or *before* 419328? 21:57 < jl2012> I think it'd be better if they change it before 419328. Otherwise, if they keep signalling 0x20000001 after 419328, Bitcoin Core clients will think there is an unknown softfork 22:00 -!- netsinn [~jiggalato@198.16.176.10] has joined #bitcoin-core-dev 22:01 -!- netsinn [~jiggalato@198.16.176.10] has quit [Remote host closed the connection] 22:01 -!- netsinn [~jiggalato@198.16.176.10] has joined #bitcoin-core-dev 22:17 < jl2012> "csv": { 22:17 < jl2012> "status": "locked_in", 22:17 < jl2012> "startTime": 1462060800, 22:17 < jl2012> "timeout": 1493596800 22:17 < jl2012> }, 22:18 < btcdrak> how many 0x20000001 blocks? 22:18 < jl2012> In the last difficulty round, CSV had 1946/2016 (96.53%) 22:19 < jl2012> 0x20000001 is 1916/2016 (95.04%) 22:20 < jl2012> so we could have a locked_in just with only standard Bitcoin Core 0.12.1 blocks 22:23 < gmaxwell> if the signaling goes away now we will panic 22:23 < gmaxwell> because it will suggest the network state will diverge if a CSV violation is mined. 22:25 < btcdrak> the spec says should but not must continue to signal during locked in state. 22:26 < gmaxwell> the purpose of the continued signaling is to let us humans see that the consensus state hasn't changed. it's not enforced by anything, thus not must. 22:26 < jl2012> after activation of CSV, how many blocks are needed to trigger the unknown softfork warning? 22:27 < gmaxwell> 50 out of 100. is the lower threshold. 22:28 -!- roidster [~chatzilla@71-95-154-155.dhcp.mtpk.ca.charter.com] has quit [Ping timeout: 240 seconds] 22:28 < jl2012> so they have to react in less than one day if we ask them to change it after it is active 22:28 < gmaxwell> Since we're now aware of miners manually setting version bits we should start work on a new deployment mechenism and depricate BIP9. :( 22:29 < gmaxwell> I think BIP9 is too unsafe to use with parties manually setting the bits. The issue is if they have old nodes that don't enforce the consensus rules and they're failing over to them and getting work from them it can split the network, and it would be completely silent. 22:29 < btcdrak> well it is just f2pool and antpool afaik 22:30 < gmaxwell> if it's most of the hashpower it means that BIP9 is a currently failed design. The initial switch to signal CSV was _Exactly_ at the starting time, so I felt confident that the version numbers weren't being faked. 22:30 < jl2012> gmaxwell: the same problem applies to ISM 22:31 < gmaxwell> I'm really crestfallen to find that it's being faked now. 22:31 < gmaxwell> jl2012: yes, and we had a failure with ISM, we hoped that the new mechenism which did not orphan non-conforming blocks would not be faked. 22:32 < gmaxwell> the fact that that failure involved empty blocks is the only thing that prevented there from being large doublespending losses. 22:33 < gmaxwell> jl2012: in any case, if we know now that they're turning the bit off, we can not freak out when it happens. 22:33 < gmaxwell> but we should urge them to check very carefully that _all_ of their infrastructure is upgraded and that there are no old nodes that might come back up, e.g. after a power cycle. 22:33 < btcdrak> i am sure we can solve the problem by talking with them. i think we should advice them to stop signalling before activation 22:34 < gmaxwell> the problem is likely that version is something exposed to front end mining equipment, and if they are doing 'fake' block generation then they need to have the block version succession logic in their own software, or configure it manually. 22:34 < btcdrak> the general public just need education 22:35 < gmaxwell> btcdrak: we can educate around risk people impose on themselves, for risk they impose on others we should strive towards designs that are hard to misconfigure. 22:35 < gmaxwell> I thought BIP9 got us there, but apparently I was mistaken. An intended feature of the design isn't working. 22:36 < btcdrak> the website faq advises miners to stop signalling before activation for those manually setting the bit 22:37 < gmaxwell> ... 22:38 < btcdrak> gmaxwell: i dont see how the issue is any different than ISM. it is better under VB since there is a two week period before enforcement. 22:38 < gmaxwell> This is seriously fucked up, miners signaling versions inconsistent with the consensus rules they were running already forked the network once and narrowly avoided an incident. BIP9's design was partially motivated in avoiding that. (with no "set version or get orphaned" the beliefe was there would be no reason to fake it. 22:38 < btcdrak> miners have been manually setting bloxk version long ago 22:38 < gmaxwell> yes, and it already caused one ~6 block deep chain fork! 22:40 < btcdrak> right. VB is better because of grace period. but maybe I am not explainimg well. when I talked to ant and fish they said they upgraded first and then changed the version number. 22:41 < btcdrak> so they are not putting anyone at risk by doing it in that order. 22:42 < gmaxwell> btcdrak: the grace period doesn't help this issue. The issue is that we don't get any strong, hard to screw up, indication that their upgrades were effective. This depends on their internal monitoring being effective, which it is not historically for many mining operations, and we shouldn't expect it to be because the risk is predominantly not held by them. 22:42 < gmaxwell> btcdrak: only if they made no errors. 22:42 < gmaxwell> and it's hard to tell, because the manual setting covers up the indicator. 22:43 < btcdrak> it is true. they do forget nodes... i dont see how you can get around this problem. miners need to change their habits. 22:44 < jl2012> Let's assume a miner is not setting manually, and some how fall back to 0.12.0 after activation. What will happen? 22:45 < gmaxwell> jl2012: won't be detected anymore, the tradeoff for getting the bit back is that you only learn about the status during the month of signaling and grace period. 22:45 < gmaxwell> But even that is meaningless if manually overridden. 22:45 < btcdrak> jl2012: they could mine an invalid block.. except their relay policy is unlikely to accept an invalid tx. 22:45 < gmaxwell> btcdrak: they'll extend an invalid chain when someone else mines an invalid block. 22:46 < btcdrak> truee 22:46 < btcdrak> well i dont see a solution other than education. it is why we wrote the FAQ 22:47 < btcdrak> https://bitcoincore.org/en/2016/06/08/version-bits-miners-faq/ 22:51 < gmaxwell> jl2012: in theory the mandatory version increase protected against downgrades, but in practice we found it did the opposite, since miners manually set the version to avoid being orphaned... so not only did it not protect against downgrades, it concealed a lack of true enforcement. 22:52 < gmaxwell> So the expectation with bip9 was that since it was no longer forced there would be no incentive to lie, and at least the measure of upgrade status would be faithful. 23:00 < jl2012> This could be corrected only with education 23:01 < btcdrak> jl2012: i agree 23:01 < gmaxwell> We could introduce signaling elsewhere in the block in locations that miners have not already built infrastructure around faking the values. 23:01 < jl2012> Some miners didn't really understand bip9 23:01 < gmaxwell> This would be systematically safe. 23:02 < jl2012> nlocktime, maybe 23:02 < gmaxwell> Expecting education to work is a losing fight... because we can educate but the parties will continue to rotate out. 23:02 < gmaxwell> nlocktime in coinbase txn perhaps, yes. 23:02 < gmaxwell> (which is where height should have gone, but oh well. :) ) 23:03 < gmaxwell> Not that I don't think that we should educate, of course. But its risky to count on that for safty. 23:04 < jl2012> But nlocktime is determined by stratum 23:04 < btcdrak> gmaxwell: in any case for csv miner have upgraded to 0.12.1. 23:04 < gmaxwell> Then can't use that either. 23:04 < jl2012> So they will fake it again 23:05 < gmaxwell> In any case there are many potential places to put it, not something that needs to be figured out now. Any solution would need to be carefully evaluated. 23:06 < gmaxwell> avoiding interaction with any customized infratructure is one reason why mark advocated the dummy transactions for additional commitments. 23:07 < btcdrak> yes was about to say use first tx. 23:08 < gmaxwell> Really the major loss with stratum is that we lost the clean domain of authority layering in the system. Now there isn't a nice boundary where complex consensus details are hidden behind, and where people who don't care about them don't have to worry about them. 23:08 -!- arubi [~ese168@unaffiliated/arubi] has quit [Ping timeout: 240 seconds] 23:08 < gmaxwell> With getwork nothing that was up for adjustment really mattered much except changes that would just make your block invalid even to SPV nodes. 23:10 < jl2012> btw, we also need to warn the miners who are using coinbase nSequence as mining nonce 23:11 < jl2012> they must keep the coinbase nVersion as 1 or the block might be orphaned 23:17 < sipa> or above 2^31 23:17 < jl2012> sipa, i.e. negative? 23:18 -!- arubi [~ese168@unaffiliated/arubi] has joined #bitcoin-core-dev 23:19 < sipa> right 23:27 < jl2012> we may need a email to miners to tell them what to double check in the coming 2 weeks 23:28 < jl2012> 1. make sure every nodes are upgraded to 0.12.1, and won't somehow fall back to an older version 23:28 < jl2012> 2. make sure they will stop signalling CSV at or before block 419328 23:29 < jl2012> (if they are doing that manually) 23:29 < jl2012> 3. make sure the coinbase tx compiles with BIP68 23:30 < jl2012> 4. make sure the coinbase tx compiles with BIP113 (in case someone use nLockTime for mining --> unlikely) 23:30 < jl2012> anymore? 23:31 < jl2012> s/compiles/complies/ 23:34 -!- fengling [~fengling@58.135.95.133] has quit [Ping timeout: 240 seconds] 23:35 < sipa> i don't think 68 applies to coinbase inputs 23:35 < jl2012> really? let me check the code 23:36 < sipa> oh, i mean 113 23:36 < jl2012> nlocktime of coinbase is not checked? 23:37 -!- netsinn [~jiggalato@198.16.176.10] has quit [Remote host closed the connection] 23:37 < sipa> it's not an input 23:37 < sipa> and not validated as one 23:37 < sipa> (i think) 23:37 -!- netsinn [~jiggalato@198.16.176.10] has joined #bitcoin-core-dev 23:38 < jl2012> 113 is the median-time-past, not OP_CSV 23:39 < sipa> yes, so 113 does not apply to coinbases 23:40 < jl2012> so i can put whatever value in the nLockTime of coinbase and it is still valid? 23:41 < sipa> i am only half awake and should shut up 23:41 < sipa> i may be confusing things 23:42 < jl2012> that's fine :) 23:57 -!- bustd_soket [~weechat@unaffiliated/loteriety] has quit [Read error: Connection reset by peer]