--- Day changed Thu Mar 17 2016
00:18 -!- Cheeseo [~x@unaffiliated/cheeseo] has quit [Read error: Connection reset by peer]
00:19 -!- Cheeseo [~x@unaffiliated/cheeseo] has joined #bitcoin-core-dev
00:26 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Quit: Leaving.]
00:30 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Quit: Leaving.]
00:34 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
00:40 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
00:41 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
00:44 -!- Don_John [~Don@ip72-211-182-139.tc.ph.cox.net] has quit [Read error: Connection reset by peer]
00:51 < wumpus> Luke-Jr: can you take a look at https://github.com/bitcoin/bitcoin/pull/7656 (base58 encoding speed up), seems relevant with your libbase58
00:54  * Luke-Jr looks
00:55 < GitHub87> [bitcoin] jonasschnelli closed pull request #6850: Improve AddToWallet performance when rescanning (master...master) https://github.com/bitcoin/bitcoin/pull/6850
01:06 < go1111111> is anyone working on the blockchain verification flag, as Greg describes at https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011853.html ? I have some interest in working on it (slowly, as it'd be my first non-test PR)
01:09 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Quit: Leaving.]
01:18 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-mykyndiwfdaevudk] has joined #bitcoin-core-dev
01:23 -!- mrkent [~textual@unaffiliated/mrkent] has joined #bitcoin-core-dev
01:33 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
01:37 -!- larrysalibra [~larry@202.83.241.113] has joined #bitcoin-core-dev
01:42 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Read error: Connection reset by peer]
01:43 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
01:44 -!- zooko [~user@c-50-131-214-60.hsd1.ca.comcast.net] has quit [Ping timeout: 240 seconds]
02:00 < paveljanik> Qt5.6 will be fun - no *.pc files there, no Qt5Core.pc etc.
02:03 -!- larrysalibra [~larry@202.83.241.113] has quit [Quit: Textual IRC Client: www.textualapp.com]
02:07 < jonasschnelli> paveljanik: but finally HiDPI support for Linux/Win
02:14 -!- B4ckJ4ck007 [~ipalyi@213.4.200.211] has joined #bitcoin-core-dev
02:14 < paveljanik> I'll try to workaround it somehow
02:15 -!- cjcj [82ebca3a@gateway/web/freenode/ip.130.235.202.58] has joined #bitcoin-core-dev
02:35 -!- mrkent [~textual@unaffiliated/mrkent] has quit []
02:44 < paveljanik> jonasschnelli, it will be fun 8) https://bugreports.qt.io/browse/QTBUG-50073
02:45 < jonasschnelli> Indeed!
02:57 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-core-dev
03:27 < GitHub73> [bitcoin] MarcoFalke opened pull request #7702: [qa] Add tests verifychain, lockunspent, getbalance, listsinceblock (master...Mf1603-qaCleanup2) https://github.com/bitcoin/bitcoin/pull/7702
03:32 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-nymjznuigsljaltp] has joined #bitcoin-core-dev
03:33 -!- MarcoFalke [8af6020a@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.10] has joined #bitcoin-core-dev
03:34 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
03:35 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Client Quit]
03:49 -!- gevs [~greg@unaffiliated/gevs] has quit [Remote host closed the connection]
04:13 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Quit: Leaving.]
04:15 -!- gevs [~greg@ip-62-235-151-130.dsl.scarlet.be] has joined #bitcoin-core-dev
04:15 -!- gevs [~greg@ip-62-235-151-130.dsl.scarlet.be] has quit [Changing host]
04:15 -!- gevs [~greg@unaffiliated/gevs] has joined #bitcoin-core-dev
04:41 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Read error: Connection reset by peer]
04:55 -!- testnet010 [4d599e6a@gateway/web/freenode/ip.77.89.158.106] has joined #bitcoin-core-dev
04:55 < GitHub167> [bitcoin] laanwj opened pull request #7703: tor: Change auth order to only use HASHEDPASSWORD if -torpassword (master...2016_03_auth_order) https://github.com/bitcoin/bitcoin/pull/7703
04:56 < testnet010> hello all I was hoping someone could help me
04:56 < testnet010> I am trying to mine bitcoins on testnet solo using cgminer
04:57 < testnet010> I am getting the following error:  Failed to resolve (?wrong URL) testnet.solo.ckpool.org:3333
05:08 < sipa> ask in #cgminer
05:34 < GitHub20> [bitcoin] laanwj pushed 7 new commits to master: https://github.com/bitcoin/bitcoin/compare/14d6324a248d...01f42676236b
05:34 < GitHub20> bitcoin/master 7659438 Suhas Daftuar: CTxMemPool::removeForBlock now uses RemoveStaged
05:34 < GitHub20> bitcoin/master 5de2baa Suhas Daftuar: Rename CTxMemPool::remove -> removeRecursive...
05:34 < GitHub20> bitcoin/master 76a7632 Suhas Daftuar: Remove work limit in UpdateForDescendants()...
05:34 < GitHub26> [bitcoin] laanwj closed pull request #7594: Mempool: Add tracking of ancestor packages (master...ancestor-tracking) https://github.com/bitcoin/bitcoin/pull/7594
05:37 < GitHub103> [bitcoin] jtimon closed pull request #7665: Contrib: Introduce script to tag compiled binaries for convenience (py) (master...0.12.99-contrib-tag) https://github.com/bitcoin/bitcoin/pull/7665
05:38 < GitHub60> [bitcoin] laanwj closed pull request #6816: BIP9: versionbits (master...versionbits) https://github.com/bitcoin/bitcoin/pull/6816
05:40 -!- jtimon [~quassel@35.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
05:57 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Quit: Leaving.]
06:06 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
06:46 -!- plopi [2edac112@gateway/web/freenode/ip.46.218.193.18] has joined #bitcoin-core-dev
06:48 < plopi> hi, can I use bitcoind in a nodejs server (for a game) without downloading the entire blockchain? thanks
07:05 < wumpus> you'll need to download the entire blockchain, you don't have to store it though if you use pruning
07:10 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds]
07:24 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
07:43 < Chris_Stewart_5> Is there any way to play with bitcoin core in an interpreter like environment?
07:43 < kanzure> if you mean testing, then use regtest mode and bitcoin-cli
07:44 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
07:45 < Chris_Stewart_5> No more like seeing how things are serialized, i.e. a python like interpreter. I don't want to spend 5 minutes waiting for bitcoind to compile just to see how certain things are serialized
07:46 < Chris_Stewart_5> but I'm guessing that is just a limitation of c++
07:48 < wumpus> python-bitcoinlib is your friend
08:03 -!- drumf [~fdrumf@50.248.81.65] has joined #bitcoin-core-dev
08:08 < morcos> wumpus: sipa: there may be two problems here with the new conflict / abandontransaction code.
08:09 < morcos> we haven't finished trackign it all down, but our guess is that when your wallet tx is conflicted via parents that were double spent, that there is no way rescans can identify that your wallet tx should now be conflicted
08:10 < morcos> that is, if the parents weren't wallet txs, and the parents are now gone, b/c they were double spent, the chain is broken and there is no way to trace the double spend down to your wallet tx
08:11 < instagibbs> Chris_Stewart_5, perhaps not as well-tested, but online: https://blockchainprogramming.azurewebsites.net/checkscript
08:11 < morcos> separately i believe that abandontransaction doesn't work for not counting new funds you've received, it only works for no longer counting spends.
08:12 < morcos> i need to look back and see why it was made that way, it sounds vaguely familiar to me that i might have known that
08:15 < wumpus> I think abandontransaction should work for any transaction that is not confirmed and not in the mempool
08:16 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has joined #bitcoin-core-dev
08:16 < wumpus> looks like there's a lot of edge cases otherwise, in the checks to see if it's actually a double spend or conflict
08:17 < morcos> wumpus: it's possible.  the purpose of it was so that you didn't keep tying up your inputs.  remember, many people didn't even want it for 0.12.  so i think you might be right, but it takes more careful thinking about the issue of what it means to abandon another transaction.  for instance you don't know if the guy who sent it to you is getting it mined another way.
08:18 < morcos> the fundamental problem is we've now got these txs that are severed from any connection to the blockchain by missing parents, so we can't detect them as conflicted.  surely the right answer isn't to manually abandon each one
08:19 < morcos> but honestly, i'm not sure how to fix it.  it seems a pretty big problem.
08:19 < wumpus> "for instance you don't know if the guy who sent it to you is getting it mined another way" right, you can be sure
08:19 < wumpus> can't*
08:20 < wumpus> but it may not be realistic to protect against that in the command
08:21 < wumpus> the user needs to be aware not to use it in such cases
08:22 < morcos> sdaftuar is suggesting that maybe the right answer is to never count in your balance unconfirmed txs that aren't in your mempool
08:22 < GitHub142> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/01f42676236b...f034bced269c
08:22 < GitHub142> bitcoin/master fa48bb3 MarcoFalke: [qt] Remove 0-fee from send dialog
08:22 < GitHub142> bitcoin/master fae8467 MarcoFalke: [qt] Remove unneeded "fSendFreeTransactions" check
08:22 < GitHub142> bitcoin/master f034bce Wladimir J. van der Laan: Merge #7686: [qt] Remove 0-fee from send dialog...
08:22 < sipa> ^ i was about to suggest that
08:22 < GitHub102> [bitcoin] laanwj closed pull request #7686: [qt] Remove 0-fee from send dialog (master...Mf1603-qt-0-fee) https://github.com/bitcoin/bitcoin/pull/7686
08:23 < morcos> so for outputs received, it works the same as it did before the change to conflicts.   for inputs spent, it works as it does in 0.12.  they are still spent unless you abandon them
08:23 < morcos> that seems relatively reasonable to me
08:23 < wumpus> I think that makes sense
08:26 -!- Aleph0 [~User@unaffiliated/amphetamine] has quit [Ping timeout: 276 seconds]
08:27 < morcos> wumpus: here was the list of unfinished business from abandontransaction
08:27 -!- Aleph0 [~User@unaffiliated/amphetamine] has joined #bitcoin-core-dev
08:27 < morcos> Return abandoned status in listtransactions
08:27 < morcos> Return abandoned status in GUI
08:27 < morcos> Fix any issues with how abandoned txs should sort
08:27 < morcos> Add a way to abandon transactions from GUI
08:28 < morcos> In fixing the conflict detection, should we go ahead and add the status in listtransactions?  (how many of these changes do you want to make for a point release)
08:28 < morcos> Also I was hoping to discuss schedule of the impending soft fork today, are we ok waiting until that to release this change... 
08:29 < morcos> And so I'm not going to make any other changes to the functionality abandontransaction, ie. it shouldnt' do anything other than it already does (no longer marking inputs as spent)
08:30 < wumpus> well for 0.13 we want all of them, I'd say backport the non-GUI ones to 0.12
08:30 < morcos> is the sorting a GUI only thing?
08:30 < morcos> i'm  not sure i'm the right guy to make those change
08:30 < morcos> s
08:30 < morcos> i mean i can hack around in the GUI if you want...
08:31 < wumpus> the bare minimum for 0.12.1 is that people such as Cocodude can troubleshoot their issue and get rid of those transactions succesfully
08:31 < morcos> sipa: are you going to do that?
08:31 < morcos> i can add the abandoned status to listtransactions
08:31 < wumpus> and a flag to be able to check whether a transactions was abandoned would be great, to be able to verify abandontransaction did its work
08:32 < sipa> morcos: i can, but i was hoping to get some work on segwit done 
08:32 < morcos> ha ha...   pulling out the trump card?
08:32 < sipa> ?
08:32 < morcos> i can't argue against that
08:33 < sipa> ah, i forgot that trump means something else than a politiciam
08:33 < sdaftuar> hah
08:33 -!- Guyver2_ [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
08:33 < morcos> ok i'll make the changes to not count as received money if its 0 confirms and not in mempool, and i'll add the abandon status to listtransactions
08:34 < sipa> great
08:35 < morcos> i'll also add this to the rpc test, that was a tricky one
08:35 -!- xabbix__ [~xabbix@bzq-79-177-6-185.red.bezeqint.net] has quit [Ping timeout: 248 seconds]
08:36 -!- xabbix__ [~xabbix@bzq-79-177-6-185.red.bezeqint.net] has joined #bitcoin-core-dev
08:37 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Ping timeout: 260 seconds]
08:37 -!- Guyver2_ is now known as Guyver2
08:49 < jonasschnelli> morcos: I can add the abandon function in the GUI
08:49 < jonasschnelli> A right-click-context menu to abandon should be relatively trivial I guess.
08:50 < jonasschnelli> The RBF stuff is way more complex. :)
08:50 < wumpus> awesome
08:50 < wumpus> I think we should open an issue to track the remaining abandontransaction work
08:50 < wumpus> I'll open it
08:51 < jonasschnelli> wumpus: okay. Thanks.
08:51 -!- BitcoinErrorLog [~bitcoiner@c-71-203-187-87.hsd1.fl.comcast.net] has joined #bitcoin-core-dev
08:51 < jonasschnelli> What else is left next to the GUI and the today identified bug?
08:52 < BitcoinErrorLog> what's up with this coinbase? http://blockr.io/block/info/403061
08:54 < wumpus> jonasschnelli: just copied the list from #7312 and added #7690 https://github.com/bitcoin/bitcoin/issues/7704
08:55 < jonasschnelli> wumpus: perfect!
08:55 < wumpus> BitcoinErrorLog: what's wrong with it?
08:55 < sipa> BitcoinErrorLog: what is weird about it?
08:58 < BitcoinErrorLog> ton of zeroes in the scriptsig, unusual sequence, i'm not sure, just getting others pointing it out
08:58 < BitcoinErrorLog> 25.59141121 BTC output
08:59 < morcos> wumpus: just to be clear, i'm not changing abandontransactoin for the last item in your list.
08:59 < wumpus> morcos: ok
09:00 < morcos> i'm changing the calculation of the available balance logic to treat depth==0 and !InMempool() coins as not available
09:00 < morcos> are teh only two places I need to do that AvailableCoins and GetAvailableCredit ?
09:00 < sipa> morcos: also for listunspent/coin selection?
09:00 < morcos> sipa: those use availablecoins right?
09:00 < sipa> seems so, if you change AvailableCoins
09:01 < wumpus> ok, makes sense, but in that case that leaves the transaction in the list and unabandon-able?
09:01 < wumpus> it just won't count for the balance, which is good of course
09:02 < paveljanik> BitcoinErrorLog, 25+fees.
09:02 < wumpus> or maybe in IsTrusted?
09:02 < morcos> wumpus: well for instance if you have a tx that has 1 input from you and 1 output to you
09:03 < morcos> if it is no longer in your mempool, then the output will automatically stop counting in your unconfirmed balance
09:03 < wumpus> IIRC in many places, like in the UI, IsTrusted is used for "counts towards balance"
09:03 < morcos> but you'd have to abandon transaction to get it to stop tying up the input
09:04 < morcos> wumpus: i don't think thats correct.  IsTrusted is for the spendable balance.
09:04 < jonasschnelli> Should we graphical "mark" abandoned transaction in the GUI? Orange icon or so?
09:04 < wumpus> oh,right
09:04 < wumpus> yes I'm confused, istrusted is about spendable, this isn't even spendable balance
09:04 < wumpus> jonasschnelli: SGTM
09:05 < BitcoinErrorLog> paveljanik: so nothing weird about the rest? that's what i get for reading anything kristov atlas says...
09:07 < GitHub199> [bitcoin] MarcoFalke opened pull request #7705: [amount] Add tests and make GetFee() monotonic (master...Mf1603-amountFix) https://github.com/bitcoin/bitcoin/pull/7705
09:07 < paveljanik> BitcoinErrorLog, do you have anything specific?
09:08 < BitcoinErrorLog> no, sry
09:08 < MarcoFalke> So is travis declared dead today?
09:10 < BitcoinErrorLog> paveljanik: atlas was raising an alarm about it, but has since deleted the tweet, i had shared the link with others who thought maybe something was weird, but think maybe just feedback loop of derp
09:10 < wumpus> MarcoFalke: is it stuck?
09:10 < MarcoFalke> Oh, travis is just missing some commit
09:10 < MarcoFalke> need to try twice
09:10 < MarcoFalke> and force push
09:11 < morcos> hmm, unfortunately the balance stuff is already broken in other ways
09:11 -!- BitcoinErrorLog [~bitcoiner@c-71-203-187-87.hsd1.fl.comcast.net] has quit []
09:11 < morcos> well, maybe not , i guess it depends on what you expect to happen with non-Final txs
09:13 < wumpus> sent non-final transactions should probably deduct from the balance, but received ones shouldn't count until they're final?
09:13 < wumpus> I think that's what I'd expect
09:13 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Quit: Leaving.]
09:13 -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
09:13 < paveljanik> hmm, its coinbare is shown as opt-in RBF at blocktrail 8)
09:14 < morcos> wumpus: ugh its broken.  i think the intention is for received non-final things to count in your unconfirmed balance
09:14 < sipa> paveljanik: haha
09:14 < morcos> ok that makes sense
09:14 < paveljanik> https://www.blocktrail.com/BTC/tx/f27c9c5d13b62674e367a52f931da9bfa3dc747ea7e51fecdf89f33debc11d89
09:14 < morcos> but if its non-final, it counts in your balance REGARDLESS of whether its conflicted or not
09:15 < morcos> i think i have to fix that too, so i'll just try to clean it up, but it'll take several of us thinking about whether it is now doing the right thing.  
09:16 < wumpus> one issue at a time morcos :)
09:16 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 276 seconds]
09:16 < morcos> wumpus: well but how can i fix it if its broken in a different way on the same line
09:17 < morcos> i mean i agree its going to be less trivial to review, but that line is just garbage as written and its the line i need to change.
09:17 < morcos> in GetUnconfirmedBalance
09:17 < wumpus> right, agreed, a lot of that balance code is a mess
09:18 < wumpus> paveljanik: hah
09:18 < morcos> anywya, got to run to meeting, will do a bit later
09:18 < wumpus> later
09:32 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Ping timeout: 260 seconds]
09:36 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
09:37 -!- B4ckJ4ck007 [~ipalyi@213.4.200.211] has quit [Quit: B4ckJ4ck007]
09:38 < jonasschnelli> morcos: what's the easiest way of creating a wtx that is not confirmed and not in the mempool (to allow abandoning)?
09:39 < jonasschnelli> a flush mempool command would be nice for regtest
09:40 -!- mol11111 is now known as moli
09:42 < jonasschnelli> -walletbroadcast=0 might be useful for a such test-case
09:42 < sdaftuar> jonasschnelli: i don't know about easiest, but one way that comes to mind for a regtest test would be to create a tx that sends funds to an anyone-can spend output
09:43 < sdaftuar> then create a transaction that spends that anyone-can-spend output and sends to one of your wallet addresses
09:43 < sdaftuar> then restart the node
09:43 < jonasschnelli> sdaftuar: Yes. Should work. -walletbroadcast=0 (create tx, abandon) works also fine.
09:43 < wumpus> doesn't one of the RPC tests create one?
09:43 < jonasschnelli> wumpus: Yes. But takes to long for some repetitive GUI debugging. :)
09:44 < sdaftuar> oh yeah, abandonconflict.py must do this
09:44 < sdaftuar> ah, in that test the node is just restarted with a higher min relay fee to prevent mempool acceptance
09:45 < sdaftuar> that is easier!
09:47 < sipa> does anyone know when the network alert sysyem was last used?
09:49 < wumpus> sipa: https://en.bitcoin.it/wiki/Alert_system has all alerts ever
09:49 < wumpus> April 11, 2014
09:56 < gmaxwell> no, it doesn't have the last one.
09:56 < gmaxwell> I sent one.
09:56 < gmaxwell> re the chain split around the strictder deployment.
09:56 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
09:57 < GitHub169> [bitcoin] morcos opened pull request #7706: [WIP] Fix calculation of balances and available coins. (master...fixconflicts2) https://github.com/bitcoin/bitcoin/pull/7706
09:57 < jonasschnelli> Should we have a "un-abandon" feature in the GUI? Like a toggle?
09:59 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 268 seconds]
10:03 -!- aknix [~aknix@65.78.54.2] has joined #bitcoin-core-dev
10:07 -!- MarcoFalke [8af6020a@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.10] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
10:16 < wumpus> I don't think we should have an un-abandon function
10:16 < wumpus> gmaxwell: please add it to the wiki then 
10:35 < gmaxwell> can't now.
10:36 -!- hybridsole [~hybridsol@c-67-177-114-112.hsd1.fl.comcast.net] has quit []
10:38 < wumpus> no problem, but please do add it at some point
10:39 < wumpus> people always assume that is the full list of alerts, for example I wasn't aware there was another one
10:44 -!- btcdrak [uid115429@gateway/web/irccloud.com/x-jdllgyhejoiplqrt] has quit [Excess Flood]
10:45 -!- plopi [2edac112@gateway/web/freenode/ip.46.218.193.18] has quit [Ping timeout: 252 seconds]
10:45 -!- btcdrak [uid115429@gateway/web/irccloud.com/x-lxexebqbrnrtpvjr] has joined #bitcoin-core-dev
10:46 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]
10:47 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
10:51 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
10:53 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-core-dev
10:54 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 252 seconds]
10:58 -!- MrHodl [~fuc@93.190.143.105] has joined #bitcoin-core-dev
10:58 -!- droark [~droark@c-24-22-36-12.hsd1.or.comcast.net] has joined #bitcoin-core-dev
10:59 -!- achow101 [~achow101@166.170.32.124] has joined #bitcoin-core-dev
10:59 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Quit: Leaving.]
11:03 -!- droark [~droark@c-24-22-36-12.hsd1.or.comcast.net] has quit [Client Quit]
11:04 -!- droark [~droark@c-24-22-36-12.hsd1.or.comcast.net] has joined #bitcoin-core-dev
11:04 < achow101> Meeting today??
11:05 -!- hsmiths [~hsmiths@cpe-76-174-26-91.socal.res.rr.com] has quit [Ping timeout: 248 seconds]
11:07 < btcdrak> achow101 in 50 mins
11:07 -!- hsmiths [~hsmiths@cpe-76-174-26-91.socal.res.rr.com] has joined #bitcoin-core-dev
11:07 < achow101> Oh, daylight savings time. Whoops
11:10 -!- skyraider [uid41097@gateway/web/irccloud.com/x-hqmuvwawhvrfvwma] has joined #bitcoin-core-dev
11:13 -!- mrkent [~textual@unaffiliated/mrkent] has joined #bitcoin-core-dev
11:20 < morcos> jonasschnelli: if i did it correctly there isn't much need for an unabandon feature.  if it makes it back into your mempool (or into a block) it won't be treated as abandoned any more
11:24 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
11:40 -!- achow101 [~achow101@166.170.32.124] has quit [Quit: Bye]
11:50 -!- treehug88 [~textual@static-108-30-103-59.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
11:52 -!- achow101 [~achow101@pool-96-227-114-115.phlapa.fios.verizon.net] has joined #bitcoin-core-dev
11:53 < paveljanik> I probably won't be able to join the beginning of the meeting again. Suggested topic: Qt 5.6 support. Bitcoin Core doesn't compile with it, because Qt 5.6 dropped almost all pkgconfig files, so configure fails.
11:53 < jonasschnelli> morcos: you said: "if it makes it back into your mempool". How would a abandoned transaction "makes it back into your mempool"?
11:54 < jonasschnelli> By re-create the identical transaction? By getting it "back" from a different peer?
11:54 -!- mrkent_ [~textual@unaffiliated/mrkent] has joined #bitcoin-core-dev
11:54 < morcos> jonasschnelli: most likely it would be relayed to you from somoene else.  or you could resubmit it
11:54 < wumpus> I don't think it makes much sense to discuss qt 5.6 support on the meeting - it's an obvious yes
11:54 < jonasschnelli> Okay. Got it.
11:54 < paveljanik> wumpus, sure, but maybe someone volunteers for it ;-)
11:55 < wumpus> what about you paveljanik? open source is mostly 'scratch your own itch'
11:55 -!- tubro [~tubro@ipb2189d84.dynamic.kabel-deutschland.de] has joined #bitcoin-core-dev
11:55 < jonasschnelli> paveljanik wumpus: Yes. The guy who did Qt5.5,.. maybe.
11:55 < paveljanik> I'll try, but maybe someone else does faster than me.
11:55 < paveljanik> Have to leave now...
11:55 < wumpus> ok, later
11:55 < jonasschnelli> cu
11:56 -!- mrkent [~textual@unaffiliated/mrkent] has quit [Ping timeout: 246 seconds]
11:58 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev
12:00 < morcos> suggested meeting topic: Scheduling the first BIP 9 sort fork for BIPs 68, 112, 113  (have to merge 7575 first, click the button wumpus)
12:00 < wumpus> meeting time?
12:00 < btcdrak> yes!
12:00 < wumpus> #startmeeting
12:00 < lightningbot> Meeting started Thu Mar 17 19:00:37 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:00 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
12:00 < sipa> ohai
12:01 < wumpus> ok, that will be first morcos, anyone else with topic suggestions?
12:01 -!- Core_ [48b04c35@gateway/web/freenode/ip.72.176.76.53] has joined #bitcoin-core-dev
12:02 < wumpus> we had an action item last time to review the backports for r BIP68 and 112 
12:02 < wumpus> #topic c: Scheduling the first BIP 9 sort fork for BIPs 68, 112, 113
12:02 < morcos> that wasn't the whole topic
12:02 < sdaftuar> i think merging is an action item, not a topic :)
12:03 < btcdrak> how happy is everyone with 7575?
12:03  * sipa happy
12:03 < sdaftuar> +1
12:03 < wumpus> well if you want to discuss 7575 that's fine with me too
12:03  * btcdrak happy
12:04 < morcos> wumpus: well its the blocker on the schedule
12:04 < wumpus> #action merge #7575
12:04 < morcos> i'm happy with it as well
12:04 < morcos> ok so then we just need to adequately review the backports, and we can discuss release?
12:04 < morcos> what is the start date?  is april 1st too soon?
12:05 < wumpus> I see it got a lot of new acks last day
12:05 < sipa> thanks to all of sdaftuar's tests :)
12:05 < morcos> i had suggested that the backports be put all together in 1 PR, but i'm not sure thats actually what you guys would prefer.  although i think thats the safest way to test them.
12:05 < morcos> (well 1 pr for 0.11 and 1 for 0.12)
12:05 < jonasschnelli> +1
12:05 < sipa> the moment miners uograde to a release with 7575 in it, the warning.logic will trigger on old nodes
12:06 < btcdrak> Assuming 7575 is merged, the softfork deployment code is in #7648. morcos and I have backported the mempool stuff
12:06 < wumpus> morcos: I think it makes sense - you can always separate out commits
12:06 < sipa> even if it only has softforks with a start time in the guture
12:06 < sipa> future
12:06 < sipa> so we shouldn't put it too far in the future
12:06 < morcos> btcdrak: so will you create a pull that backports it all together for 0.12 (including 7575) and i'll do for 0.11
12:06 < btcdrak> wumpus: the mempool backports are all done, they only need verification that the cherry-picks are correct
12:07 < wumpus> okay, good
12:07 < btcdrak> morcos: ok
12:07 < btcdrak> who has reviewed https://github.com/bitcoin/bitcoin/pull/7648?
12:08 < wumpus> no one yet, I think
12:08 < btcdrak> this is built on #7575 and has additional RPC tests that exercise the BIP9 softfork process and the BIP enforcements for 68,112 and 113
12:08 < morcos> i think we should announce the start date and bit number on the -dev list as soon as we've agreed on it, so that Classic and other implementations can implement it as well
12:08 < jonasschnelli> btcdrak: It probably better reviewable after 7575 is merged
12:08 < gmaxwell> +1
12:09 < wumpus> #action review #7648 after #7575 is merged
12:09 < sdaftuar> the final version of the versionbits BIP should similarly be announced i think?
12:09 < btcdrak> I'll rebase 7648 after 7575 is merged
12:10 < jonasschnelli> I think we don't need to announce the merge,.. but the release/deployment.
12:10 < morcos> back in 3 mins
12:11 < wumpus> yes the start date and bit number certainly needs to be announced 
12:11 < btcdrak> wumpus: and we need to plan the release date to be able to set the start date.
12:12 < btcdrak> wumpus: morcos and I will have the backport PRs ready to go for 0.12 and 0.11. We've done most of the work already.
12:12 < wumpus> great!
12:13 < wumpus> release date is not entirely predictable, we do want a RC cycle
12:13 < btcdrak> really, the only holdup is review of #7648. Once that's merged final, the backports are as good as done. They'd only need to be verified for correctness.
12:13 < sipa> maybe set the date to may 1st?
12:13 < morcos> I'd suggest moving the start date to April 15th
12:13 < morcos> oh
12:13 < morcos> ok
12:13 < wumpus> may 1st sounds good to me
12:14 < btcdrak> is that the start date for BIP9?
12:14 < wumpus> better to leave some time for issues, which will always arise
12:14 < morcos> so BIP 9 itself is up to date in the BIP repo, I guess that's what matters most for other implementations, not our code readiness
12:14 < sdaftuar> others may not be aware of that though
12:14 < sdaftuar> as it's been in flux until recently
12:15 < morcos> I'm happy to send the follow up to my original email with these announcements.  Perhaps we should update BIP's 68,112,113 with the soft fork info
12:15 < sipa> we want to announce out intention to go ahead with a deployment based on bip9, for 68/112/113, with a given start date
12:15 < btcdrak> morcos: BIP9 text is uptodate with the implementation
12:15 < sdaftuar> good point about updating BIP68/112/113
12:16 < wumpus> yes
12:16 < btcdrak> OK I'll do that
12:16 < btcdrak> so is the BIP9 start date May 1st?
12:16 < morcos> btcdrak: that language is confusing.  the date for the first BIP9 soft fork is May 1st
12:16 < sdaftuar> May 1st is the startdate for the CSV deployment
12:16 < morcos> yep
12:16 < sdaftuar> (or whatever we're calling it)
12:17 < sipa> once we have code running anywhere in production with a given start date, that date cannot be postponed anymore
12:17 < sipa> or there is a fork risk
12:17 < morcos> CSV deployment makes sense to me, it captures most of it, perhaps it would be helpful to add a comment next to the deployment, which BIPS it implements
12:17 < sipa> moving the start time back is possible
12:17 < btcdrak> yeah, it's already called CSV deployment in the code.
12:18 < wumpus> ok, so aim is may 1st
12:18 < btcdrak> ok so action point is update BIP68/112/113 deployment section
12:18 < wumpus> let's make sure to review everything necessary as soon as possible so that it can be merged as soon as possible and we can do the release as soon as possible
12:18 < morcos> I think it makes sense to include that we Bitcoin Core will have a release well in advance of the start date implementing the fork
12:19 -!- mrkent [~textual@unaffiliated/mrkent] has joined #bitcoin-core-dev
12:19 < btcdrak> regarding choosing the bit, I guess bit 0 makes sense.
12:19 < sdaftuar> just please don't choose bit 28
12:20 -!- mrkent_ [~textual@unaffiliated/mrkent] has quit [Ping timeout: 248 seconds]
12:20 < wumpus> or 13 :)
12:20 < btcdrak> The Chinese like 8
12:20 < btcdrak> ha
12:20 < wumpus> but yes it makes sense just to allocate 0
12:21 < wumpus> easier to keep track if they're simply dealt out in order
12:21 < morcos> what is the block number classic uses?
12:21 -!- testnet010 [4d599e6a@gateway/web/freenode/ip.77.89.158.106] has quit [Ping timeout: 252 seconds]
12:21 < btcdrak> BIP109 uses one of the top 3 ::sigh::
12:22 < jonasschnelli> https://github.com/bitcoinclassic/bitcoinclassic/blob/develop/src/primitives/block.h#L13
12:22 < btcdrak> top bit 010, so it's not actually part of the BIP9 spec
12:23 < morcos> btcdrak: huh, it looks like they use 001 and then use bit 28 to signal their hard fork
12:23 < btcdrak> yup
12:23 < sdaftuar> TESTDUMMY!
12:23 < sdaftuar> er
12:23 < jonasschnelli> ;-)
12:23 < sdaftuar> so that works out fine then?
12:23 < btcdrak> bwahahaha
12:23 < wumpus> hehehe
12:23 < btcdrak> yes
12:23 < morcos> sdaftuar: thats what i'm hoping you'll answer
12:24 < morcos> it should, i think
12:24 < sdaftuar> i think so too
12:25 < btcdrak> TESTDUMMY is a past deployment, in 2008 so no problem.
12:25 < wumpus> ok, let's try to be sure about that before committing to one
12:25 < morcos> jonasschnelli: so we'd like to get that listunspent abandon flag in for 0.12.1 too (but not the gui changes)... 
12:25 < btcdrak> wumpus: it's fine. TESTDUMMY timeout is December 31, 2008
12:25 < jonasschnelli> morcos: opening PR in 30secs.
12:25 < morcos> topic: anything else needed for 0.12.1 ?
12:26 < jonasschnelli> What about the GUI warning capabilities for 0.12.1?
12:26 < jonasschnelli> https://github.com/bitcoin/bitcoin/pull/7579
12:26 < wumpus> if it's going to be a softfork release, there shouldn't be much else in 0.12.1
12:26 < btcdrak> yeah let's keep it small
12:26 < jonasschnelli> I'm not entierly happy with 7579,... but could be a small step.
12:26 < btcdrak> postpone 7579
12:26 < wumpus> 2008? well, let's get into our deloreans
12:27 -!- hybridsole [~hybridsol@c-67-177-114-112.hsd1.fl.comcast.net] has joined #bitcoin-core-dev
12:27 < jtimon> sorry, late, reading, super happy with bip9
12:27 < morcos> jonasschnelli: oh, i'm glad you pointed me to that PR, i didn't know about it, and was separately going to rework warnings.   we should fix them for rpc and gui at the same time.  so yeah not for 0.12.1
12:27 < jonasschnelli> 7579 aims for a simple change that is BP compatibile.
12:28 < wumpus> let's leave that to 0.12.2
12:28 < jonasschnelli> It does not prevent the whole rework.
12:28 < wumpus> focus on the softfork
12:28 < jonasschnelli> +1
12:28 < btcdrak> wumpus: +1
12:28 < wumpus> anything that is also required will unpredictably affect the release date
12:28 < jonasschnelli> The internal warning system was always bad. So no hurry. :)
12:28 < wumpus> yea...
12:29 < wumpus> jonasschnelli: I do like 7579 btw
12:29 < morcos> wumpus: right, so lets review 7706 and jonasschnelli's pull that is now 2 mins overdue as well, b/c i think we need those
12:31 < wumpus> which one?
12:31 < morcos> (the flag for abandontransaction in listunspent)
12:31 < btcdrak> we probably need a new #topic, we've strayed off the original topic
12:31 < morcos> well its all related to getting 0.12.1 released
12:31 < wumpus> oh that makes sense, probably a few line change with no impoact outside listunspent
12:31 < jonasschnelli> https://github.com/bitcoin/bitcoin/pull/7707 (not 7706!)
12:31 < GitHub84> [bitcoin] jonasschnelli opened pull request #7707: [RPC][QT] UI support for abandoned transactions (master...2016/03/abandon_ui) https://github.com/bitcoin/bitcoin/pull/7707
12:32 < morcos> jonasschnelli: yeah, mine is 7706, we need both
12:32 < btcdrak> morcos: but the topic was "Scheduling the first BIP 9 sort fork for BIPs 68, 112, 113"
12:32 < sipa> i think we should get dgenr8's partition detection improvement reviewed for 0.12.1
12:32 < jonasschnelli> morcos: Ah. Right.
12:32 < wumpus> ok, now everyone wants their favorite thing in 0.12.1
12:32 < jonasschnelli> sipa: PR URL?
12:32 < morcos> sipa: oh, i like that idea.  thats the most effective way to fix the poor situation with the warnings
12:32 < wumpus> I was trying to avoid this
12:32 < wumpus> and focus on the softfork
12:33 < morcos> wumpus: well lets see if the list we come up wiht in the next 5 mins is reasonable
12:33 < morcos> we don't have to keep adding stuff for the next week
12:33 < btcdrak> improving the partition warnings would be a great help, because it's currently a _disaster_
12:34 < jonasschnelli> dgenr8 partition check PR: https://github.com/bitcoin/bitcoin/pull/7568/files
12:34 < wumpus> minimum risk would be to release 0.12.0 + only softfork backports
12:34 < wumpus> but I agree if there are critical bugfixes they should be in too
12:34 < jonasschnelli> I agree. 0.13 Release is 2016-07-01
12:35 < wumpus> yes
12:35 < morcos> wumpus: i think the conflict detection issue is potentially large. i'm kind of surprised we haven't seen more complaints about it.  i guess people might not rely on unconfirmed balance too much
12:35 < jonasschnelli> (so not so far away)
12:35 < sipa> if we don't fix the partition warnings, we should disable them. maintaining the system longer in the current state will just make people ignore them
12:35 < btcdrak> sipa: +1
12:35 < wumpus> I agree sipa and morcos
12:35 < morcos> sipa: have you reviewed the partition PR
12:35 < wumpus> so let's fix those
12:35 < wumpus> no more
12:36 < wumpus> but the softfork is still priority #1
12:37 -!- Core_ [48b04c35@gateway/web/freenode/ip.72.176.76.53] has quit [Quit: Page closed]
12:37 < sipa> ok
12:38 < wumpus> #action for 0.12.1, apart from softfork: fix partition warnings (review #7568), conflict detection issue (#7706)
12:39 < sipa> morcos: only the concept; i'll review the code too
12:39 < wumpus> jonasschnelli: we probably want a RPC-only #7707 for 0.12.1
12:40 < morcos> yep, its one line of code.  : )
12:40 < wumpus> heh
12:40 < jonasschnelli> wumpus: Agree. You could cherry pick or tell me if i should open a RPC-only PR against 0.12
12:40 < wumpus> jonasschnelli: oh it's one line, I'll manage :)
12:40 < jonasschnelli> +1
12:41 < jonasschnelli> Is a independent commit: 42e945d79fd54ab11ad48978910b42d10c1c7cf8
12:41 < morcos> i marked 7706 as WIP, but i just want to flesh out the tests.  but wouldn't mind somoene else to think about whether its doing the right thing
12:41 < wumpus> #action for 0.12.1, #7707 (: 42e945d79fd54ab11ad48978910b42d10c1c7cf8 only)
12:41 < jtimon> wumpus: ACK on just using bits in order
12:44 < wumpus> that concludes the topic, I think
12:44 < jonasschnelli> topic prop.: state of SW
12:44 < wumpus> #topic state of SW
12:45  * jonasschnelli thinks is rude to look at sipa now...
12:45 < sipa> i'm working on the post-fork upgrade problem in the current segnet code
12:45 < jtimon> morcos: the right bit to signal hardforks is the one that helps old nodes declare the first hardfork block invalid. see outdated https://github.com/bitcoin/bitcoin/pull/7566/commits/990dda87b258c1e8d4d35b1fcbae4106303664f0
12:45 < sipa> next thing after that is rebase on top of versionbitd and do a new segnet
12:45 < morcos> sipa: new segnet or testnet?
12:46 < jonasschnelli> samesame?
12:46 < sipa> new segnet
12:46 < sipa> though we can independently test on testnet too, of course
12:47 < jonasschnelli> Are we aiming SW for 0.13.1?
12:47 < sipa> i'm aiming for SW in 0.11.something, 0.12.something, 0
12:47 < sipa> 0.13
12:48 < sipa> it's a softfork, we'll need to backport
12:48 < morcos> btcdrak: btw, you should make the start date for CSV deployment earlier on testnet.  we didn't talk about that.  but any reason not to make the start date march 1st?
12:48 < jonasschnelli> sipa: Agree. Just on the "timeline".
12:48 < sipa> jonasschnelli: "soon"
12:48 < jonasschnelli> I love that "soon". :)
12:50 < jonasschnelli> I'm just asking because some Core Devs did agree a timeline for SW on a a miners/devs/etc. meeting.
12:50 < jonasschnelli> *agree on a timeline
12:50 < btcdrak> morcos: ok
12:51 < sipa> jonasschnelli: i don't care what some people think; a timeline is something you can't promise
12:51 < sipa> but we can do our best
12:51 < wumpus> good to watch that timeline but most important is that we don't deploy before it's ready, quality shouldn't suffer under time pressure
12:51 < jonasschnelli> sipa: fully agree.
12:51 < btcdrak> sipa: that's fine, so long as we communicate how things are going, that's good enough.
12:51 < wumpus> worst outcome would be to be scared into delivering something that breaks
12:51 < jonasschnelli> btcdrak: yes. We just need to communicate.
12:51 < sipa> yes
12:52 < jonasschnelli> Lets just say "soon". :)
12:52 < sipa> i'm glad bip9 seems final
12:52 < wumpus> me too
12:53 < jonasschnelli> Yes. Finally.
12:53 < btcdrak> sipa: party at your house. we'll bring the beers.
12:53 < wumpus> I think that concludes the meeting?
12:53 < jonasschnelli> btcdrak finally de-anonymizes at the party.
12:53 < wumpus> #endmeeting
12:53 < lightningbot> Meeting ended Thu Mar 17 19:53:48 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
12:53 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-03-17-19.00.html
12:53 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-03-17-19.00.txt
12:53 < lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-03-17-19.00.log.html
12:54 < btcdrak> haha
12:54 < sipa> jonasschnelli: that's why you bring a drink mixer
12:54 < jonasschnelli> hahaha...
12:54 < wumpus> hehehe
12:54 < sipa> ok, afk
12:54 < jonasschnelli> cu
12:54 < morcos> now that the meeting is over, can i just ask about these non-final txs again...  i just want to avoid a mistake like with paytxfee
12:54 < wumpus> later
12:54 < morcos> where we didn't realize how some poeple are using things might get messed up
12:55 < morcos> it seems hard to me to imagine many people have non-final txs in your wallet
12:55 < wumpus> safest is always to leave the behavior the same :) but if you change it, just document it properly ,and it's no problem
12:55 < wumpus> the criticism was that it waswn't mentioned in the release notes
12:55 < wumpus> not that it changed at all
12:55 < morcos> ok, but its ok with you if it changes in 0.12.1 then
12:55 < morcos> i just don't know of any other good way to fix this
12:55 < wumpus> eh, that certainly shouldn't change between minor releases
12:55 < wumpus> do that for 0.13
12:55 < morcos> but you can't fix the problem then
12:56 < wumpus> for 0.12.1 we want tofix the issue and nothing more
12:56 < wumpus> without affecting non-final txes
12:56 < morcos> how can you distinguish between a non-final tx that you want to include in your balance and one that you don't 
12:56 < morcos> if it's conflicted you dont
12:56 < wumpus> yeah... :/
12:56 < morcos> but you have no way of knowing whether its actually conflicted or not
12:57 < wumpus> anyhow I've had a long day, I'm going afk too, can't really concentrate well anymore
12:57 < btcdrak> morcos: do I need to mention testnet starttime/timeout in the BIPs?
12:57 < morcos> ok, well i'm going to change it for minor release then
12:57 < morcos> btcdrak: yes i would
12:57 < morcos> and bit
12:57 < morcos> isn't there a section for depolyment
12:57 < btcdrak> "This BIP is to be deployed by "versionbits" BIP9 using bit 0 with a '''starttime''' of midnight 1st May 2016 UTC (Unix timestamp 1462060800) and '''timeout''' of 1 year at midnight 1st May 2016 UTC (Unix timestamp 1483228800)."
12:57 < btcdrak> there is
12:58 < morcos> uh, well your second year shouldn't be 2016
12:58 < btcdrak> ha
12:58 < morcos> but also don't you want to make the time out longer?
12:58 < morcos> i thought we were typically doing 3 year time outs?
12:58 < btcdrak> a year is fine.
12:58 < btcdrak> no 
12:58 < btcdrak> the recommendation is 1 year
12:58 < morcos> in the BIP?
12:58 < btcdrak> yes
12:58 < sdaftuar> $ date --date='@1483228800'
12:58 < sdaftuar> Sat Dec 31 19:00:00 EST 2016
13:00 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 244 seconds]
13:00 < morcos> i'm surprised the recommendation is one year, but ok, that sounds fine to me
13:01 < btcdrak> sdaftuar: good catch, I made a typo
13:02 < btcdrak> morcos: so a similar text for testnet then.
13:02 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #bitcoin-core-dev
13:03 < morcos> yeah, no one else said anything about the mar 1st testnet, but that makes sense to me, not sure what the expiration should be, maybe may 1st ?
13:03 < morcos> of 2017
13:03 < morcos> in case there is some delay, seems a bit silly to be screwed on testnet b/c we put the date too early
13:08 < btcdrak> I'd be more tempted to say the testnet date should be 1st April to give a chance for review of  7648
13:16 < jtimon> good meeting, more re bip9. Again, I'm super-happy with #7575. And I'm glad that CodeShark rusty and sipa don't seem to hate me after my heterdox review method for bip9, and I'm sorry for being to open too open to offer resistance for potentially/probably/likely stupid things. I feel I've been a pain in the ass with this. I really needed to maintain a parallel branch to whatever was going to be merged for me to review , but next 
13:16 < jtimon> time I can try much harder to filter my nits before I send them. Also, thanks to morcos for re-bringing the "what's wrong with sending early wrong/preemtive warnings to old nodes" issue, looking back that's the only point where I surrender "easily". Sorry again to all 3
13:17  * btcdrak hands jtimon some BIP9 party beers
13:18 < morcos> btcdrak: i don't feel strongly, but it doesn't seem like there is any reason to delay on testnet at all.  does anyone else have an opinion?
13:18 < btcdrak> jtimon: https://i.imgur.com/NDBSWOL.jpg
13:19 < jtimon> morcos: for bip68/bip112/bip113 ? testnet should definitely have an earlier starttime
13:20 < jtimon> btcdrak: I only have amstel here, but cheers
13:20 < morcos> jtimon: yeah i think we just need to pick start and end times for test net.   i was proposing march 1st for start time and may 1st 2017 (to match mainnet) for end time
13:21 < btcdrak> morcos: this is what I came up with https://github.com/bitcoin/bips/compare/master...btcdrak:cvsdeploy
13:22 < jtimon> morcos: ack, but let's make sure we explain why not march 1st 2017 in the code comments, if you hadn't said "(to match mainnet)", I would have asked
13:22 < morcos> btcdrak: i'd take out the "on mainnet" part of "is to be deployed on mainnet by versionbits"
13:23 < morcos> btcdrak: i still sligthly vote for march 1st instead of april 1st, but its only a slight preference
13:25 < jtimon> btw, unrelated, morcos gmaxwell how stupid does https://github.com/jtimon/bitcoin/tree/0.12.99-feerate-test-bug look? would something like that qualify as a "test bug" in libsecp256k1 ?
13:25 < jtimon> it passed unittests and python ./qa/pull-tester/rpc-tests.py -extended
13:26 < morcos> jtimon: ha ha
13:26 < jtimon> wumpus: I'm kind of curious, can I open a PR just to see what travis thinks about it?
13:27 < jtimon> then close it, of course
13:27 < morcos> jtimon: i'm not really sure to tell you the truth, i mean even if you made it more egregious, it would probably only fail like an IsDust check or something.
13:27 < morcos> this is what i was sort of trying to say to wumpus the other day about FeeRates when he didn't want them to be doubles
13:27 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Quit: laurentmt]
13:28 < morcos> i don't think they matter too much for anything
13:28 < btcdrak> morcos: done https://github.com/bitcoin/bips/pull/359
13:29 < morcos> btcdrak: heh, part of me was secretly hoping you would keep april so if anyone complains about the date you would be on the hook at not me.
13:29 < btcdrak> ha, i realised april fool
13:33 < btcdrak> sdaftuar: is bit 28 forever in use on regtest then?
13:44 < jyap> btw, it's soon™
13:44 < morcos> btcdrak: yeah, but thats the case with any bit used in any soft fork, so we were eventually going to have to figure out what to do about that once we had 29 soft forks
13:44 < morcos> now we'll ahve to figure it out when we have 28
13:54 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit []
13:54 < btcdrak> morcos: we need to be able to tell regtest what time it is. then we can have multiple deployments on regtest.
13:55 < morcos> btcdrak: yeah it'll be fixable in some way or another, but in the meantime, you probably want to make it easy to quickly activate any and all soft forks on regtest
13:55 < morcos> so its best to leave their dates open
14:00 -!- Don_John [~Don@ip72-211-182-139.tc.ph.cox.net] has joined #bitcoin-core-dev
14:11 -!- tubro [~tubro@ipb2189d84.dynamic.kabel-deutschland.de] has quit [Ping timeout: 260 seconds]
14:12 -!- fengling [~fengling@111.198.29.53] has quit [Ping timeout: 240 seconds]
14:16 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]
14:17 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev
14:19 < jtimon> so, I was just playing around after our conversation yesterday, I wasn't talking about rational numbers for CFeeRate (that would be maaku if he still maintains that position), I just intuitively and irrationally hate CFeeRate for some reason, I'm not sure I can articulate it reasonably yet, but CFeeRate is kind of coupling "presentation precission" with "stored precission" in a way that I deeply dislike, and this sentiment has 
14:19 < jtimon> nothing to do CFeeRate::ToString(). As I was telling, I thought code would probably be faster if the first question after my first explanation was "are you suggesting to make CFeeRate a rational number?". I could have responded with "it is always already a rational number, it just happens that it's a constant" but I really thought that without me actually understanding why was the goal in changing CFeeRate, that wouldn't lead to 
14:19 < jtimon> any productive discussion unless I had some code to make more point more clear. So I rapidly created all the free disruption I could, to see if any of it could be potentially useful to explain my point about CFeeRate being currently ugly/dangerous interface-wise. Then I was negatevely surprised for my code drafts to pass unitests so easily. At some pint I swear that I passed unitests with s/KB/WEBSCALE=TB*1000, but I was creating
14:19 < jtimon>  too much unnecessary disruption to get to this result, so I had to reduce it to something more readable. After many apparently false positives (I knew the rpc tests couldn't possibly let pass some of the things I did), https://github.com/jtimon/bitcoin/tree/0.12.99-feerate-test-bug it's basically what I have, but I still won't push my not-to-be-merged point about CFeeRate having "bad aji" which I'm still not sure I'm right about
14:19 < jtimon> . seeing KB 3 times in the same line in my disruption commits also showed some potential for simplification, but not very promising. Sorry for the noise, I think I will convince myself there's nothing useful in jtimon/0.12.99-feerate soon.
14:22 -!- fengling [~fengling@111.198.29.53] has quit [Ping timeout: 240 seconds]
14:38 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-core-dev
14:39 -!- cjcj [82ebca3a@gateway/web/freenode/ip.130.235.202.58] has quit [Ping timeout: 252 seconds]
14:48 -!- treehug88 [~textual@static-108-30-103-59.nycmny.fios.verizon.net] has quit [Quit: Textual IRC Client: www.textualapp.com]
14:52 -!- fuc [fuc@ool-43571e2c.dyn.optonline.net] has joined #bitcoin-core-dev
14:52 -!- fuc [fuc@ool-43571e2c.dyn.optonline.net] has quit [Client Quit]
14:52 -!- MrHodl [~fuc@93.190.143.105] has quit [Ping timeout: 252 seconds]
15:10 < morcos> wumpus: sipa: gmaxwell: See my latest comments on https://github.com/bitcoin/bitcoin/pull/7706 .  It's a bit of a boondoggle. 
15:11 < morcos> Can we discuss tomorrow on IRC?  I really think we have to get something done for 0.12.1, so we just need to agree on what it is we want to do.
15:11 < morcos> I'm unavailable the rest of the evening, but will be online tomorrow.
15:48 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev
16:05 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
16:10 -!- skyraider [uid41097@gateway/web/irccloud.com/x-hqmuvwawhvrfvwma] has quit [Quit: Connection closed for inactivity]
16:12 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Read error: Connection reset by peer]
16:12 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev
16:22 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Quit: laurentmt]
16:27 -!- amiller [~socrates1@unaffiliated/socrates1024] has quit [Ping timeout: 240 seconds]
16:30 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds]
16:32 -!- Guest73422 [~socrates1@li175-104.members.linode.com] has joined #bitcoin-core-dev
16:41 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Ping timeout: 244 seconds]
16:45 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
16:52 -!- PRab [~chatzilla@c-68-34-102-231.hsd1.mi.comcast.net] has quit [Quit: ChatZilla 0.9.92 [Firefox 44.0.2/20160210153822]]
17:10 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-core-dev
17:24 < GitHub136> [bitcoin] pstratem opened pull request #7708: De-neuter NODE_BLOOM (master...2016-03-17-nodebloom) https://github.com/bitcoin/bitcoin/pull/7708
17:25 < GitHub192> [bitcoin] sdaftuar opened pull request #7709: Tests: fix missing import in mempool_packages (master...fix-mempool-packages-2) https://github.com/bitcoin/bitcoin/pull/7709
17:26 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev
17:35 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Quit: Leaving.]
17:44 -!- jtimon [~quassel@35.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 246 seconds]
17:51 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
17:53 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-core-dev
18:01 -!- mrkent_ [~textual@unaffiliated/mrkent] has joined #bitcoin-core-dev
18:01 -!- mrkent [~textual@unaffiliated/mrkent] has quit [Ping timeout: 260 seconds]
18:02 -!- fengling [~fengling@111.198.29.53] has quit [Ping timeout: 240 seconds]
18:04 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev
18:13 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Quit: Leaving.]
18:25 -!- rubensayshi [~ruben@c89225.upc-c.chello.nl] has quit [Ping timeout: 244 seconds]
18:25 -!- rubensayshi [~ruben@c89225.upc-c.chello.nl] has joined #bitcoin-core-dev
18:46 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Quit: Leaving.]
18:51 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-mykyndiwfdaevudk] has quit [Quit: Connection closed for inactivity]
18:54 < GitHub187> [bitcoin] fanquake opened pull request #7710: [Depends] Bump miniupnpc (master...depends-02) https://github.com/bitcoin/bitcoin/pull/7710
18:57 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-core-dev
19:17 < GitHub16> [bitcoin] fanquake opened pull request #7711: [build-aux] Update Boost & check macros to latest serials (master...build-aux-change) https://github.com/bitcoin/bitcoin/pull/7711
19:34 -!- mrkent_ [~textual@unaffiliated/mrkent] has quit []
19:35 -!- evoskuil [~evoskuil@c-73-225-134-208.hsd1.wa.comcast.net] has quit [Ping timeout: 260 seconds]
19:36 -!- evoskuil [~evoskuil@c-73-225-134-208.hsd1.wa.comcast.net] has joined #bitcoin-core-dev
19:42 -!- zooko [~user@c-73-202-109-21.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
19:42 -!- [1]evoskuil [~evoskuil@c-73-225-134-208.hsd1.wa.comcast.net] has joined #bitcoin-core-dev
19:42 -!- evoskuil [~evoskuil@c-73-225-134-208.hsd1.wa.comcast.net] has quit [Ping timeout: 260 seconds]
19:42 -!- [1]evoskuil is now known as evoskuil
19:47 -!- belcher [~user@unaffiliated/belcher] has quit [Quit: Leaving]
19:54 -!- [1]evoskuil [~evoskuil@c-73-225-134-208.hsd1.wa.comcast.net] has joined #bitcoin-core-dev
19:54 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Quit: Leaving.]
19:54 -!- achow101 [~achow101@pool-96-227-114-115.phlapa.fios.verizon.net] has quit [Read error: Connection reset by peer]
19:55 -!- evoskuil [~evoskuil@c-73-225-134-208.hsd1.wa.comcast.net] has quit [Ping timeout: 260 seconds]
19:55 -!- [1]evoskuil is now known as evoskuil
20:07 -!- justanot1eruser [~Justan@unaffiliated/justanotheruser] has quit [Read error: Connection reset by peer]
20:09 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
20:16 -!- PRab [~chatzilla@c-68-34-102-231.hsd1.mi.comcast.net] has joined #bitcoin-core-dev
20:22 -!- Don_John [~Don@ip72-211-182-139.tc.ph.cox.net] has quit [Ping timeout: 276 seconds]
20:22 -!- go1111111 [~go1111111@104.200.154.71] has quit [Ping timeout: 260 seconds]
20:37 -!- go1111111 [~go1111111@104.232.116.217] has joined #bitcoin-core-dev
20:37 -!- Don_John [~Don@ip72-211-182-139.tc.ph.cox.net] has joined #bitcoin-core-dev
20:49 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
20:50 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
21:16 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 276 seconds]
21:19 < GitHub125> [bitcoin] promag opened pull request #7712: Improve COutPoint less operator (master...enhancement/improve-coutpoint-less-operator) https://github.com/bitcoin/bitcoin/pull/7712
21:35 -!- AaronvanW [~ewout@D979E961.cm-3-2d.dynamic.ziggo.nl] has joined #bitcoin-core-dev
21:35 -!- AaronvanW [~ewout@D979E961.cm-3-2d.dynamic.ziggo.nl] has quit [Changing host]
21:35 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
21:55 -!- luke-jr_ [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
21:57 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 276 seconds]
21:58 -!- droark [~droark@c-24-22-36-12.hsd1.or.comcast.net] has quit [Max SendQ exceeded]
21:59 -!- xabbix__ [~xabbix@bzq-79-177-6-185.red.bezeqint.net] has quit [Ping timeout: 244 seconds]
22:03 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Ping timeout: 248 seconds]
22:03 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev
22:04 -!- zooko [~user@c-73-202-109-21.hsd1.ca.comcast.net] has quit [Remote host closed the connection]
22:05 -!- zooko [~user@c-73-202-109-21.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
22:08 -!- gmaxwell [greg@wikimedia/KatWalsh/x-0001] has quit [Ping timeout: 276 seconds]
22:08 -!- gmaxwell [greg@mf4-xiph.osuosl.org] has joined #bitcoin-core-dev
22:08 -!- gmaxwell is now known as Guest57413
22:18 -!- shesek [~shesek@bzq-84-110-32-239.cablep.bezeqint.net] has quit [Read error: Connection timed out]
22:19 -!- shesek [~shesek@bzq-84-110-32-239.red.bezeqint.net] has joined #bitcoin-core-dev
22:32 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
22:40 -!- gavinandresen [~gavin@unaffiliated/gavinandresen] has quit [Ping timeout: 276 seconds]
22:40 -!- gavinandresen [~gavin@unaffiliated/gavinandresen] has joined #bitcoin-core-dev
22:42 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
22:43 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
22:50 -!- luke-jr_ is now known as Luke-Jr
23:00 -!- dermoth [~thomas@175-79.162.dsl.aei.ca] has quit [Read error: Connection reset by peer]
23:00 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-core-dev
23:00 -!- dermoth [~thomas@175-79.162.dsl.aei.ca] has joined #bitcoin-core-dev
23:29 -!- ebfull [~sean@73.34.119.0] has quit [Remote host closed the connection]
23:39 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has quit []
23:49 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Quit: Leaving.]
23:49 -!- zooko [~user@c-73-202-109-21.hsd1.ca.comcast.net] has quit [Ping timeout: 276 seconds]
23:55 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-core-dev
23:55 -!- xabbix__ [~xabbix@bzq-79-177-6-185.red.bezeqint.net] has joined #bitcoin-core-dev