< 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
< testnet010>
hello all I was hoping someone could help me
< testnet010>
I am trying to mine bitcoins on testnet solo using cgminer
< testnet010>
I am getting the following error: Failed to resolve (?wrong URL) testnet.solo.ckpool.org:3333
< plopi>
hi, can I use bitcoind in a nodejs server (for a game) without downloading the entire blockchain? thanks
< wumpus>
you'll need to download the entire blockchain, you don't have to store it though if you use pruning
< Chris_Stewart_5>
Is there any way to play with bitcoin core in an interpreter like environment?
< kanzure>
if you mean testing, then use regtest mode and bitcoin-cli
< 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
< Chris_Stewart_5>
but I'm guessing that is just a limitation of c++
< wumpus>
python-bitcoinlib is your friend
< morcos>
wumpus: sipa: there may be two problems here with the new conflict / abandontransaction code.
< 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
< 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
< 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.
< 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
< wumpus>
I think abandontransaction should work for any transaction that is not confirmed and not in the mempool
< 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
< 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.
< 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
< morcos>
but honestly, i'm not sure how to fix it. it seems a pretty big problem.
< 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
< wumpus>
can't*
< wumpus>
but it may not be realistic to protect against that in the command
< wumpus>
the user needs to be aware not to use it in such cases
< morcos>
sdaftuar is suggesting that maybe the right answer is to never count in your balance unconfirmed txs that aren't in your mempool
< 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
< morcos>
that seems relatively reasonable to me
< wumpus>
I think that makes sense
< morcos>
wumpus: here was the list of unfinished business from abandontransaction
< morcos>
Return abandoned status in listtransactions
< morcos>
Return abandoned status in GUI
< morcos>
Fix any issues with how abandoned txs should sort
< morcos>
Add a way to abandon transactions from GUI
< 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)
< morcos>
Also I was hoping to discuss schedule of the impending soft fork today, are we ok waiting until that to release this change...
< 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)
< wumpus>
well for 0.13 we want all of them, I'd say backport the non-GUI ones to 0.12
< morcos>
is the sorting a GUI only thing?
< morcos>
i'm not sure i'm the right guy to make those change
< morcos>
s
< morcos>
i mean i can hack around in the GUI if you want...
< 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
< morcos>
sipa: are you going to do that?
< morcos>
i can add the abandoned status to listtransactions
< 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
< sipa>
morcos: i can, but i was hoping to get some work on segwit done
< morcos>
ha ha... pulling out the trump card?
< sipa>
?
< morcos>
i can't argue against that
< sipa>
ah, i forgot that trump means something else than a politiciam
< sdaftuar>
hah
< 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
< sipa>
great
< morcos>
i'll also add this to the rpc test, that was a tricky one
< jonasschnelli>
morcos: I can add the abandon function in the GUI
< jonasschnelli>
A right-click-context menu to abandon should be relatively trivial I guess.
< jonasschnelli>
The RBF stuff is way more complex. :)
< wumpus>
awesome
< wumpus>
I think we should open an issue to track the remaining abandontransaction work
< wumpus>
I'll open it
< jonasschnelli>
wumpus: okay. Thanks.
< jonasschnelli>
What else is left next to the GUI and the today identified bug?
< BitcoinErrorLog>
ton of zeroes in the scriptsig, unusual sequence, i'm not sure, just getting others pointing it out
< BitcoinErrorLog>
25.59141121 BTC output
< morcos>
wumpus: just to be clear, i'm not changing abandontransactoin for the last item in your list.
< wumpus>
morcos: ok
< morcos>
i'm changing the calculation of the available balance logic to treat depth==0 and !InMempool() coins as not available
< morcos>
are teh only two places I need to do that AvailableCoins and GetAvailableCredit ?
< sipa>
morcos: also for listunspent/coin selection?
< morcos>
sipa: those use availablecoins right?
< sipa>
seems so, if you change AvailableCoins
< wumpus>
ok, makes sense, but in that case that leaves the transaction in the list and unabandon-able?
< wumpus>
it just won't count for the balance, which is good of course
< paveljanik>
BitcoinErrorLog, 25+fees.
< wumpus>
or maybe in IsTrusted?
< morcos>
wumpus: well for instance if you have a tx that has 1 input from you and 1 output to you
< morcos>
if it is no longer in your mempool, then the output will automatically stop counting in your unconfirmed balance
< wumpus>
IIRC in many places, like in the UI, IsTrusted is used for "counts towards balance"
< morcos>
but you'd have to abandon transaction to get it to stop tying up the input
< morcos>
wumpus: i don't think thats correct. IsTrusted is for the spendable balance.
< jonasschnelli>
Should we graphical "mark" abandoned transaction in the GUI? Orange icon or so?
< wumpus>
oh,right
< wumpus>
yes I'm confused, istrusted is about spendable, this isn't even spendable balance
< wumpus>
jonasschnelli: SGTM
< BitcoinErrorLog>
paveljanik: so nothing weird about the rest? that's what i get for reading anything kristov atlas says...
< GitHub199>
[bitcoin] MarcoFalke opened pull request #7705: [amount] Add tests and make GetFee() monotonic (master...Mf1603-amountFix) https://github.com/bitcoin/bitcoin/pull/7705
< paveljanik>
BitcoinErrorLog, do you have anything specific?
< BitcoinErrorLog>
no, sry
< MarcoFalke>
So is travis declared dead today?
< 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
< wumpus>
MarcoFalke: is it stuck?
< MarcoFalke>
Oh, travis is just missing some commit
< MarcoFalke>
need to try twice
< MarcoFalke>
and force push
< morcos>
hmm, unfortunately the balance stuff is already broken in other ways
< morcos>
well, maybe not , i guess it depends on what you expect to happen with non-Final txs
< wumpus>
sent non-final transactions should probably deduct from the balance, but received ones shouldn't count until they're final?
< wumpus>
I think that's what I'd expect
< paveljanik>
hmm, its coinbare is shown as opt-in RBF at blocktrail 8)
< morcos>
wumpus: ugh its broken. i think the intention is for received non-final things to count in your unconfirmed balance
< morcos>
but if its non-final, it counts in your balance REGARDLESS of whether its conflicted or not
< 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.
< wumpus>
one issue at a time morcos :)
< morcos>
wumpus: well but how can i fix it if its broken in a different way on the same line
< 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.
< morcos>
in GetUnconfirmedBalance
< wumpus>
right, agreed, a lot of that balance code is a mess
< wumpus>
paveljanik: hah
< morcos>
anywya, got to run to meeting, will do a bit later
< wumpus>
later
< jonasschnelli>
morcos: what's the easiest way of creating a wtx that is not confirmed and not in the mempool (to allow abandoning)?
< jonasschnelli>
a flush mempool command would be nice for regtest
< jonasschnelli>
-walletbroadcast=0 might be useful for a such test-case
< 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
< sdaftuar>
then create a transaction that spends that anyone-can-spend output and sends to one of your wallet addresses
< sdaftuar>
then restart the node
< jonasschnelli>
sdaftuar: Yes. Should work. -walletbroadcast=0 (create tx, abandon) works also fine.
< wumpus>
doesn't one of the RPC tests create one?
< jonasschnelli>
wumpus: Yes. But takes to long for some repetitive GUI debugging. :)
< sdaftuar>
oh yeah, abandonconflict.py must do this
< sdaftuar>
ah, in that test the node is just restarted with a higher min relay fee to prevent mempool acceptance
< sdaftuar>
that is easier!
< sipa>
does anyone know when the network alert sysyem was last used?
< gmaxwell>
re the chain split around the strictder deployment.
< GitHub169>
[bitcoin] morcos opened pull request #7706: [WIP] Fix calculation of balances and available coins. (master...fixconflicts2) https://github.com/bitcoin/bitcoin/pull/7706
< jonasschnelli>
Should we have a "un-abandon" feature in the GUI? Like a toggle?
< wumpus>
I don't think we should have an un-abandon function
< wumpus>
gmaxwell: please add it to the wiki then
< gmaxwell>
can't now.
< wumpus>
no problem, but please do add it at some point
< wumpus>
people always assume that is the full list of alerts, for example I wasn't aware there was another one
< achow101>
Meeting today??
< btcdrak>
achow101 in 50 mins
< achow101>
Oh, daylight savings time. Whoops
< 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
< 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.
< jonasschnelli>
morcos: you said: "if it makes it back into your mempool". How would a abandoned transaction "makes it back into your mempool"?
< jonasschnelli>
By re-create the identical transaction? By getting it "back" from a different peer?
< morcos>
jonasschnelli: most likely it would be relayed to you from somoene else. or you could resubmit it
< wumpus>
I don't think it makes much sense to discuss qt 5.6 support on the meeting - it's an obvious yes
< jonasschnelli>
Okay. Got it.
< paveljanik>
wumpus, sure, but maybe someone volunteers for it ;-)
< wumpus>
what about you paveljanik? open source is mostly 'scratch your own itch'
< jonasschnelli>
paveljanik wumpus: Yes. The guy who did Qt5.5,.. maybe.
< paveljanik>
I'll try, but maybe someone else does faster than me.
< paveljanik>
Have to leave now...
< wumpus>
ok, later
< jonasschnelli>
cu
< 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)
< wumpus>
meeting time?
< btcdrak>
yes!
< wumpus>
#startmeeting
< lightningbot>
Meeting started Thu Mar 17 19:00:37 2016 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
< wumpus>
ok, that will be first morcos, anyone else with topic suggestions?
< wumpus>
we had an action item last time to review the backports for r BIP68 and 112
< wumpus>
#topic c: Scheduling the first BIP 9 sort fork for BIPs 68, 112, 113
< morcos>
that wasn't the whole topic
< sdaftuar>
i think merging is an action item, not a topic :)
< btcdrak>
how happy is everyone with 7575?
< * sipa>
happy
< sdaftuar>
+1
< wumpus>
well if you want to discuss 7575 that's fine with me too
< * btcdrak>
happy
< morcos>
wumpus: well its the blocker on the schedule
< wumpus>
#action merge #7575
< morcos>
i'm happy with it as well
< morcos>
ok so then we just need to adequately review the backports, and we can discuss release?
< morcos>
what is the start date? is april 1st too soon?
< wumpus>
I see it got a lot of new acks last day
< sipa>
thanks to all of sdaftuar's tests :)
< 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.
< morcos>
(well 1 pr for 0.11 and 1 for 0.12)
< jonasschnelli>
+1
< sipa>
the moment miners uograde to a release with 7575 in it, the warning.logic will trigger on old nodes
< btcdrak>
Assuming 7575 is merged, the softfork deployment code is in #7648. morcos and I have backported the mempool stuff
< wumpus>
morcos: I think it makes sense - you can always separate out commits
< sipa>
even if it only has softforks with a start time in the guture
< sipa>
future
< sipa>
so we shouldn't put it too far in the future
< 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
< btcdrak>
wumpus: the mempool backports are all done, they only need verification that the cherry-picks are correct
< 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
< 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
< jonasschnelli>
btcdrak: It probably better reviewable after 7575 is merged
< gmaxwell>
+1
< wumpus>
#action review #7648 after #7575 is merged
< sdaftuar>
the final version of the versionbits BIP should similarly be announced i think?
< btcdrak>
I'll rebase 7648 after 7575 is merged
< jonasschnelli>
I think we don't need to announce the merge,.. but the release/deployment.
< morcos>
back in 3 mins
< wumpus>
yes the start date and bit number certainly needs to be announced
< btcdrak>
wumpus: and we need to plan the release date to be able to set the start date.
< 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.
< wumpus>
great!
< wumpus>
release date is not entirely predictable, we do want a RC cycle
< 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.
< sipa>
maybe set the date to may 1st?
< morcos>
I'd suggest moving the start date to April 15th
< morcos>
oh
< morcos>
ok
< wumpus>
may 1st sounds good to me
< btcdrak>
is that the start date for BIP9?
< wumpus>
better to leave some time for issues, which will always arise
< 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
< sdaftuar>
others may not be aware of that though
< sdaftuar>
as it's been in flux until recently
< 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
< 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
< btcdrak>
morcos: BIP9 text is uptodate with the implementation
< sdaftuar>
good point about updating BIP68/112/113
< wumpus>
yes
< btcdrak>
OK I'll do that
< btcdrak>
so is the BIP9 start date May 1st?
< morcos>
btcdrak: that language is confusing. the date for the first BIP9 soft fork is May 1st
< sdaftuar>
May 1st is the startdate for the CSV deployment
< morcos>
yep
< sdaftuar>
(or whatever we're calling it)
< sipa>
once we have code running anywhere in production with a given start date, that date cannot be postponed anymore
< sipa>
or there is a fork risk
< 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
< sipa>
moving the start time back is possible
< btcdrak>
yeah, it's already called CSV deployment in the code.
< wumpus>
ok, so aim is may 1st
< btcdrak>
ok so action point is update BIP68/112/113 deployment section
< 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
< 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
< btcdrak>
regarding choosing the bit, I guess bit 0 makes sense.
< sdaftuar>
just please don't choose bit 28
< wumpus>
or 13 :)
< btcdrak>
The Chinese like 8
< btcdrak>
ha
< wumpus>
but yes it makes sense just to allocate 0
< wumpus>
easier to keep track if they're simply dealt out in order
< wumpus>
if it's going to be a softfork release, there shouldn't be much else in 0.12.1
< btcdrak>
yeah let's keep it small
< jonasschnelli>
I'm not entierly happy with 7579,... but could be a small step.
< btcdrak>
postpone 7579
< wumpus>
2008? well, let's get into our deloreans
< jtimon>
sorry, late, reading, super happy with bip9
< 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
< jonasschnelli>
7579 aims for a simple change that is BP compatibile.
< wumpus>
let's leave that to 0.12.2
< jonasschnelli>
It does not prevent the whole rework.
< wumpus>
focus on the softfork
< jonasschnelli>
+1
< btcdrak>
wumpus: +1
< wumpus>
anything that is also required will unpredictably affect the release date
< jonasschnelli>
The internal warning system was always bad. So no hurry. :)
< wumpus>
yea...
< wumpus>
jonasschnelli: I do like 7579 btw
< 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
< wumpus>
which one?
< morcos>
(the flag for abandontransaction in listunspent)
< btcdrak>
we probably need a new #topic, we've strayed off the original topic
< morcos>
well its all related to getting 0.12.1 released
< wumpus>
oh that makes sense, probably a few line change with no impoact outside listunspent
< wumpus>
minimum risk would be to release 0.12.0 + only softfork backports
< wumpus>
but I agree if there are critical bugfixes they should be in too
< jonasschnelli>
I agree. 0.13 Release is 2016-07-01
< wumpus>
yes
< 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
< jonasschnelli>
(so not so far away)
< 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
< btcdrak>
sipa: +1
< wumpus>
I agree sipa and morcos
< morcos>
sipa: have you reviewed the partition PR
< wumpus>
so let's fix those
< wumpus>
no more
< wumpus>
but the softfork is still priority #1
< sipa>
ok
< wumpus>
#action for 0.12.1, apart from softfork: fix partition warnings (review #7568), conflict detection issue (#7706)
< sipa>
morcos: only the concept; i'll review the code too
< wumpus>
jonasschnelli: we probably want a RPC-only #7707 for 0.12.1
< morcos>
yep, its one line of code. : )
< wumpus>
heh
< jonasschnelli>
wumpus: Agree. You could cherry pick or tell me if i should open a RPC-only PR against 0.12
< wumpus>
jonasschnelli: oh it's one line, I'll manage :)
< jonasschnelli>
+1
< jonasschnelli>
Is a independent commit: 42e945d79fd54ab11ad48978910b42d10c1c7cf8
< 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
< wumpus>
#action for 0.12.1, #7707 (: 42e945d79fd54ab11ad48978910b42d10c1c7cf8 only)
< jtimon>
wumpus: ACK on just using bits in order
< wumpus>
that concludes the topic, I think
< jonasschnelli>
topic prop.: state of SW
< wumpus>
#topic state of SW
< * jonasschnelli>
thinks is rude to look at sipa now...
< sipa>
i'm working on the post-fork upgrade problem in the current segnet code
< sipa>
next thing after that is rebase on top of versionbitd and do a new segnet
< morcos>
sipa: new segnet or testnet?
< jonasschnelli>
samesame?
< sipa>
new segnet
< sipa>
though we can independently test on testnet too, of course
< jonasschnelli>
Are we aiming SW for 0.13.1?
< sipa>
i'm aiming for SW in 0.11.something, 0.12.something, 0
< sipa>
0.13
< sipa>
it's a softfork, we'll need to backport
< 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?
< jonasschnelli>
sipa: Agree. Just on the "timeline".
< sipa>
jonasschnelli: "soon"
< jonasschnelli>
I love that "soon". :)
< jonasschnelli>
I'm just asking because some Core Devs did agree a timeline for SW on a a miners/devs/etc. meeting.
< jonasschnelli>
*agree on a timeline
< btcdrak>
morcos: ok
< sipa>
jonasschnelli: i don't care what some people think; a timeline is something you can't promise
< sipa>
but we can do our best
< 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
< jonasschnelli>
sipa: fully agree.
< btcdrak>
sipa: that's fine, so long as we communicate how things are going, that's good enough.
< wumpus>
worst outcome would be to be scared into delivering something that breaks
< jonasschnelli>
btcdrak: yes. We just need to communicate.
< sipa>
yes
< jonasschnelli>
Lets just say "soon". :)
< sipa>
i'm glad bip9 seems final
< wumpus>
me too
< jonasschnelli>
Yes. Finally.
< btcdrak>
sipa: party at your house. we'll bring the beers.
< wumpus>
I think that concludes the meeting?
< jonasschnelli>
btcdrak finally de-anonymizes at the party.
< wumpus>
#endmeeting
< lightningbot>
Meeting ended Thu Mar 17 19:53:48 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< sipa>
jonasschnelli: that's why you bring a drink mixer
< jonasschnelli>
hahaha...
< wumpus>
hehehe
< sipa>
ok, afk
< jonasschnelli>
cu
< 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
< wumpus>
later
< morcos>
where we didn't realize how some poeple are using things might get messed up
< morcos>
it seems hard to me to imagine many people have non-final txs in your wallet
< wumpus>
safest is always to leave the behavior the same :) but if you change it, just document it properly ,and it's no problem
< wumpus>
the criticism was that it waswn't mentioned in the release notes
< wumpus>
not that it changed at all
< morcos>
ok, but its ok with you if it changes in 0.12.1 then
< morcos>
i just don't know of any other good way to fix this
< wumpus>
eh, that certainly shouldn't change between minor releases
< wumpus>
do that for 0.13
< morcos>
but you can't fix the problem then
< wumpus>
for 0.12.1 we want tofix the issue and nothing more
< wumpus>
without affecting non-final txes
< morcos>
how can you distinguish between a non-final tx that you want to include in your balance and one that you don't
< morcos>
if it's conflicted you dont
< wumpus>
yeah... :/
< morcos>
but you have no way of knowing whether its actually conflicted or not
< wumpus>
anyhow I've had a long day, I'm going afk too, can't really concentrate well anymore
< btcdrak>
morcos: do I need to mention testnet starttime/timeout in the BIPs?
< morcos>
ok, well i'm going to change it for minor release then
< morcos>
btcdrak: yes i would
< morcos>
and bit
< morcos>
isn't there a section for depolyment
< 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)."
< btcdrak>
there is
< morcos>
uh, well your second year shouldn't be 2016
< btcdrak>
ha
< morcos>
but also don't you want to make the time out longer?
< morcos>
i thought we were typically doing 3 year time outs?
< btcdrak>
a year is fine.
< btcdrak>
no
< btcdrak>
the recommendation is 1 year
< morcos>
in the BIP?
< btcdrak>
yes
< sdaftuar>
$ date --date='@1483228800'
< sdaftuar>
Sat Dec 31 19:00:00 EST 2016
< morcos>
i'm surprised the recommendation is one year, but ok, that sounds fine to me
< btcdrak>
sdaftuar: good catch, I made a typo
< btcdrak>
morcos: so a similar text for testnet then.
< 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 ?
< morcos>
of 2017
< morcos>
in case there is some delay, seems a bit silly to be screwed on testnet b/c we put the date too early
< btcdrak>
I'd be more tempted to say the testnet date should be 1st April to give a chance for review of 7648
< 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
< 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
< * btcdrak>
hands jtimon some BIP9 party beers
< 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?
< jtimon>
morcos: for bip68/bip112/bip113 ? testnet should definitely have an earlier starttime
< jtimon>
btcdrak: I only have amstel here, but cheers
< 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
< 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
< morcos>
btcdrak: i'd take out the "on mainnet" part of "is to be deployed on mainnet by versionbits"
< morcos>
btcdrak: i still sligthly vote for march 1st instead of april 1st, but its only a slight preference
< jtimon>
it passed unittests and python ./qa/pull-tester/rpc-tests.py -extended
< morcos>
jtimon: ha ha
< jtimon>
wumpus: I'm kind of curious, can I open a PR just to see what travis thinks about it?
< jtimon>
then close it, of course
< 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.
< 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
< morcos>
i don't think they matter too much for anything
< 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.
< btcdrak>
ha, i realised april fool
< btcdrak>
sdaftuar: is bit 28 forever in use on regtest then?
< jyap>
btw, it's soon™
< 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
< morcos>
now we'll ahve to figure it out when we have 28
< btcdrak>
morcos: we need to be able to tell regtest what time it is. then we can have multiple deployments on regtest.
< 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
< morcos>
so its best to leave their dates open
< 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
< 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
< 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
< 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
< 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.
< 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.
< morcos>
I'm unavailable the rest of the evening, but will be online tomorrow.