--- Day changed Thu Nov 26 2015 00:00 -!- Netsplit over, joins: tripleslash 00:00 -!- btcdrak_ is now known as btcdrak 00:02 -!- Netsplit over, joins: berndj 00:05 < jonasschnelli> CoinJoin: in case of a coin-join wtx. What if we show one table-row for the self-owned in/outs net, and table-rows for each "normal-output" (non self),.. 00:06 -!- Netsplit over, joins: michagogo 00:06 < wump> so re: https://github.com/bitcoin/bitcoin/pull/7096 was this change in RPC settxfee behavior ever planned, or noticed before? I think it's strange that this is in 0.11, but no one reported the change from per-kB to absolute fee? 00:06 < jonasschnelli> and because the debit-credit != 0, add another table row with the combined input sum of all foreign-inputs (something like "not-self-owned-funds")? 00:07 < gmaxwell> wump: ?? when was something changed to absolute fee? 00:07 -!- Netsplit over, joins: helo 00:07 < wump> jonasschnelli: this would break one table row = one output 00:07 < wump> gmaxwell: that was my surprise as well 00:07 < jonasschnelli> wump: settxfee: I think it went from "perKB" to "absolute" with the coin-control smart fee changes. 00:08 -!- wump is now known as wumpus 00:08 -!- Netsplit over, joins: Guest1234 00:08 < jonasschnelli> 5200 was the problematic PR that made settxfee work absolute instead of byKB 00:08 < jonasschnelli> Especially this line: https://github.com/bitcoin/bitcoin/pull/5200/files#diff-d7618bdc04db23aa74d6a5a4198c58fdR1635 00:08 < gmaxwell> also, I think we need to write some polite admonishment for test authors to please try to not just hardcode bugs into the tests. This has happened several times now, and I don't know that people have a good theory of testing that helps them not do that. 00:09 < jonasschnelli> nFeeNeeded = ::minRelayTxFee.GetFee(nTxBytes); 00:09 < jonasschnelli> which means, we take a perKB fee as absolute fee (nFeeNeeded is absolute) 00:09 < jonasschnelli> which makes sense for the way to UI was designed, ... but not for RPC 00:09 -!- Netsplit over, joins: lightningbot 00:09 -!- ParadoxSpiral [~ParadoxSp@p508B8799.dip0.t-ipconnect.de] has joined #bitcoin-core-dev 00:09 < wumpus> gmaxwell: well in many cases the tests just check current behavior, it's not always clear what the *correct* behavior should be 00:09 -!- Arnavion [~Arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev 00:10 < jonasschnelli> Wait... sorry. wrong code line: 00:10 < jonasschnelli> the UI did play with a global var for a temporary state 00:10 < jonasschnelli> nFeeNeeded = payTxFee.GetFeePerK(); 00:10 -!- morcos [~morcos@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev 00:10 < gmaxwell> as far as people not complaining, mixture of many txn being <1kb, and fee noise on the network.. and maybe smart fees making mysterious behavior expected? 00:10 < wumpus> jonasschnelli: but this affect the non-UI as well right? I'm much more concerned with that 00:10 < jonasschnelli> right 00:10 < jonasschnelli> This is the problem: nFeeNeeded = payTxFee.GetFeePerK(); 00:10 < jonasschnelli> We take a perKB fee rate as absolute fee. 00:10 < wumpus> I mean the UI has zillion options to configure the fee before sending, the default is just to use smartfees, and everyone almost uses that 00:10 < jonasschnelli> But only when fPayAtLeastCustomFee = true 00:10 < jonasschnelli> (which is the default!) 00:10 < wumpus> but I'm not sure about RPC... 00:11 < jonasschnelli> IMO it's bad that the UI can change global state during "normal operation" (non-settings operations) 00:11 < wumpus> how are settxfee and smartfees *supposed* to interact? 00:11 < wumpus> jonasschnelli: I agree 00:12 -!- Arnavion [~Arnavion@unaffiliated/arnavion] has quit [Client Quit] 00:12 < jonasschnelli> The 5200PR included changes that allowed UI users to set an absolute fee (which makes sense if you use coincontrol). Somehow this is unrelated to smartfees. 00:12 < jonasschnelli> a) absolute fees should only be possible when enabling and using coincontrol 00:12 < wumpus> there should be nothing with absolute fees IMO 00:12 -!- Arnavion [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev 00:12 < jonasschnelli> b) UI set absolute fees should never change the global fee level! 00:12 < wumpus> fees should be relative througout bitcoind 00:13 < gmaxwell> coincointrol should still work with relative fees, but it knows the transaction size and so it can show the actual amounts. 00:13 < jonasschnelli> right.. the PR 7096 does minimize the possibilities of absolute fees. 00:13 < wumpus> not sure how this sneaked in, but this is the kinds of things I've always been afraid of with wallet changes. They're hardly reviewed/tested. 00:13 < wumpus> but I'd like to know: how are settxfee and smartfees *supposed* to interact? 00:13 < gmaxwell> well no harm no foul at least. 00:14 < gmaxwell> If we don't have any wallet users at all there will be no bugs. :) 00:14 < jonasschnelli> simply spoken: settxfee has nothing to do with the "bug". 00:14 < jonasschnelli> The problem lays deeper in "CWallet::GetMinimumFee" 00:14 < wumpus> gmaxwell: right, no one reported this, but it may explain some 'my transaction never goes through' 00:15 < wumpus> jonasschnelli: right, maybe it has nothing to do with that, to be honest I don't understand the current tangle of rules determining the fees for RPC 00:15 < jonasschnelli> the problem is, you can set the tx fee over rpc, but because of https://github.com/bitcoin/bitcoin/pull/5200/files#diff-d7618bdc04db23aa74d6a5a4198c58fdR1637, it will always take the feePerKB value as absolute fee. 00:16 < jonasschnelli> There is no way to change this unsless you use the UI 00:16 < jonasschnelli> fPayAtLeastCustomFee is always true 00:16 < gmaxwell> wumpus: on tests, generally tests that are trying to sense if nothing changes at all should be seperated from ones checking important invarients. Many of our tests don't test invarients at all but only check exact values; and it makes it very hard to change anything. 00:16 -!- Netsplit over, joins: AtashiCon 00:16 < gmaxwell> and when you do there is a temptation to just change the fixed values; which moots the value of the test. 00:17 < wumpus> gmaxwell: I agree, but I don't really see a solution to that, that's been the case in every project I've been in that even had tests :) 00:17 < wumpus> oh the tests break? change the tests 00:17 < raedah> jonasschnelli, re coinjoin, "table-rows for each 'normal-output' (non self),.." that would be a lot of rows for a single big join. I can show the just self outputs easily, alongside a row for the Net. 00:17 < wumpus> jonasschnelli: ok. Let's just remove anything to do with absolute fee setting. 00:18 < jonasschnelli> wumpus: PR 7096 does that "almost". 00:18 < jonasschnelli> It enables the option to set an "absolute fee" IF coin join is enabled and inputs are selected. 00:18 < jonasschnelli> I think that's okay. 00:18 < wumpus> gmaxwell: I'm sure better tests are always welcome though, and you're welcome to encourage people to add better tests :) 00:18 < jonasschnelli> The "absolute fee" option is even hidden if coinjoin is disabled. 00:19 < jonasschnelli> s/coinjoin/coincontrol 00:19 -!- Netsplit over, joins: isis 00:19 < gmaxwell> wumpus: whenever someone creates a test there should be at least three test sets: An invarient test which any possibly correct code should pass. A known response test that might need to change if the code changes, and an extreme values test, which may or may not be implementation specific. Yadda yadda. Thinking this way usually makes it easier to write tests, since you can just work through the 00:19 < gmaxwell> cases. 00:19 < gmaxwell> jonasschnelli: if so I think the UI should just be translating that to relative fees 00:19 < wumpus> also we have lots of randomized algorithms, and randomized tests 00:20 < jonasschnelli> raedah: right. I just think we need to have a coinjoin solution where the sum = 0. SOmehow i think if you sum the balance of each row it should be equal to your balance 00:20 < wumpus> this doesn't make either easier 00:21 < wumpus> e.g. the tests here hardcode the hash function used even https://github.com/bitcoin/bitcoin/pull/7078 00:21 < jonasschnelli> gmaxwell: agree, translating to a perKB rate would be nice. Are there no use cases where manual transaction creation (with coincontol) could require a absulte fee? 00:21 < wumpus> it's pseudo-randomized using the hash function, but exact results are tested 00:22 < gmaxwell> jonasschnelli: AFAIK nothing about the bitcoin system uses absolute fees, and it would be irrational for miners to do so. 00:22 -!- Thireus [~Thireus@icy.thireus.fr] has quit [Quit: Leaving.] 00:22 < wumpus> so it's very attractive now to just use a hammer and make sure the function is the same on all platforms, but in principle this is a test problem 00:22 < raedah> jonasschnelli, i think thats impossible. You have an input tx and then two output txs that are all yours. The two outputs tx are worth slightly more (or less) then your input. To make matters worth, no where in the transaction does it say what your individual contribution to the miner fee was. 00:22 < jonasschnelli> gmaxwell: but right now, the goal should be to fix the behavior with a minimal impact while not removing current features (so we can backport). 00:22 < gmaxwell> wumpus: I think it's okay to have known response tests like that; but they should always come with invarient tests, so if only the known response test fails you can update it with more confidence. 00:23 < jonasschnelli> but we could also remove the absolute fee entirely... 00:23 -!- pkthebud [uid128839@gateway/web/irccloud.com/session] has quit [Changing host] 00:23 -!- pkthebud [uid128839@gateway/web/irccloud.com/x-vrhjkgtyphtdsadf] has joined #bitcoin-core-dev 00:23 -!- fkhan [weechat@unaffiliated/loteriety] has quit [Changing host] 00:23 -!- fkhan [weechat@gateway/vpn/mullvad/x-ifcceekdywreglre] has joined #bitcoin-core-dev 00:23 < gmaxwell> raedah: You actually cannot tell your contribution to the fees, it's unknowable to the wallet. 00:23 < wumpus> jonasschnelli: I still think that's best - if you know the size of the transaction, you can achieve the same using relative fee 00:23 < jonasschnelli> maybe 0.12 remove absolute fee, 0.11 backport not. 00:24 < wumpus> jonasschnelli: (and the only case in which absolute fees are useful are *when* you know the size of the transaction anyway) 00:24 -!- btcdrak [uid115429@gateway/web/irccloud.com/session] has quit [Changing host] 00:24 -!- btcdrak [uid115429@gateway/web/irccloud.com/x-qnkwjnusljnsyzpe] has joined #bitcoin-core-dev 00:24 < jonasschnelli> wumpus: or if you don't trust the fee estimator? 00:24 < wumpus> jonasschnelli: you can still provide a fee per kB right? 00:24 < gmaxwell> I think removing a feature in a backport can be less of a sin than running different code in master and the backport. 00:24 < jonasschnelli> wumpus: right... 00:24 < wumpus> jonasschnelli: no fee estimator involved 00:24 < gmaxwell> Simply because the backport will not be as extensively tested. 00:24 < wumpus> 'fee estimator' has to be selected (that's smart fee) 00:25 < wumpus> well the requirement for backport are: small code impact, easy to test 00:25 < jonasschnelli> we could try to get https://github.com/bitcoin/bitcoin/pull/7096 reviewed and merged, and backported.... then remove the absolute fee from master (which is trivial) 00:26 < wumpus> if there is one line of code that fixes 'settxfee' behavior in 0.11 without touching anything else I'd e.g. prefer that 00:26 < jonasschnelli> I could try to see if the code-change is less invasive if we remove the absolute fee. Guts tells me it could be a larger diff. 00:26 < gmaxwell> raedah: only if the wallet knew which outputs were yours (it can't because coinjoin), AND knew the values of the foreign inputs (it doesn't because of the wallet design) could it know your contribution to the fee. 00:26 < wumpus> jonasschnelli: right... 00:27 < wumpus> jonasschnelli: doesn't seem like a large diff anyway, probably applies cleanly right now? 00:27 < gmaxwell> yea, we could do the smallest fix that fixes settxfee, then later remove the absolute in the gui. 00:28 < jonasschnelli> I think https://github.com/bitcoin/bitcoin/pull/7096/files is minimal if you hide the RPC tests. 00:28 < jonasschnelli> and a backport should be easy because we didn't changes that part since then i guesx 00:28 < gmaxwell> wumpus: wrt reconnecting; in my nodes for what became the peer eviction logic one of the criteria I'd mused over was tracking how fast peers reconnect and prioritizing evicting fast reconnectors. 00:29 < wumpus> gmaxwell: yes - nodes that reconnect at all are suspect. They're either your own or a spy node :) 00:30 < wumpus> so if you whitelist your own nodes, that leaves spies 00:30 < gmaxwell> wumpus: yea, I didn't go much further there because I started thinking that spies are better handled by starvation: stop leaking data thats useful to spies. 00:31 -!- guest234234 [~guest2342@223.207.237.249] has quit [Ping timeout: 260 seconds] 00:31 -!- AtashiCon [arnavion@unaffiliated/arnavion] has quit [Disconnected by services] 00:31 -!- Arnavion3 [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev 00:31 -!- Arnavion3 is now known as AtashiCon 00:31 < wumpus> gmaxwell: sure... 00:32 < wumpus> as long as they don't do anything resource intensive, or there are that many of them that they block out signiicant numbers of legit nodes 00:32 < jonasschnelli> raedah gmaxwell: coinjoin: I had in mind to visually flag all coinjoin outputs in the table (different background, different icon, additional icon). And maybe a row that would represent the sum of non-self-controller inputs... but i agree with wumpus, would be a concept change. 00:33 < jonasschnelli> Somehow it looks strange if the sum of all you row in the transaction-table != your balance. 00:33 < jonasschnelli> that's why i had this idea in mind. 00:33 < raedah> gmaxwell, which outputs are mine are known because they are watch addresses, and from that I can deduce which ones are not mine, but the fee contribution happens when the transaction is being assembled and only the fee total ends up in the blockchain. Of course the fee record is in the joinmarket logs, but that doesnt help QT transaction details. 00:33 < wumpus> jonasschnelli: I certainly agree with visually distinguishing coinjoin transactions, and warning that the fee is not really the fee 00:33 < gmaxwell> wumpus: unfortunately it only takes a couple people trying to connect to everything that its intrusive; but my hope was that if they gained nothing they'd mostly stop. 00:33 -!- Arnavion [arnavion@unaffiliated/arnavion] has quit [Disconnected by services] 00:33 -!- Arnavion [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev 00:34 < jonasschnelli> wumpus: is displaying the fee (which is not known at this point) even required? 00:34 < wumpus> jonasschnelli: but personally I'm not a huge fan of the idea of adding more rows for them 00:34 < gmaxwell> raedah: by outputs I mean what the transaction is paying. It's certantly possible to use JM in a way where you are not paying yourself. 00:35 < wumpus> jonasschnelli: consider this: what if every transaction you do is coinjoin 00:35 < wumpus> jonasschnelli: (I somewhat hope that is going to be the future) 00:35 < jonasschnelli> Or we could try to combine them in one row and add an extra "coinjoin" info in the tx-detail window? overkill? 00:35 < gmaxwell> jonasschnelli: just remember that external inputs are not only made by coinjoins; we should probably handle transactions with unknown inputs in a uniform way. 00:35 < wumpus> jonasschnelli: there shouldn't be too much overhead in that case 00:35 < gmaxwell> Really robust handling requires extra metadata: you need to know which of the payments are yours. 00:36 < wumpus> yes 00:36 < jonasschnelli> okay... so what would be the way to go? :) 00:36 < gmaxwell> We should probably change the 'wallet equation' from myinputs - fee = outputs to myinputs + otherinputs - fees = outputs. 00:36 < wumpus> but we don't have that metadata right now, so we have to handle this without it 00:37 < gmaxwell> And to ever transaction in list transactions add an extra_inputs: field, and get the fees right. 00:37 < gmaxwell> but this requires adding information about utxo not currently in the wallet. 00:37 -!- morcos [~morcos@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Ping timeout: 240 seconds] 00:37 < gmaxwell> That would be a "level 1" handling, "level 2" would extend that by learning from JM, etc. which outputs were ours. 00:38 -!- morcos [~morcos@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev 00:38 < gmaxwell> and the others could be hidden like change is now. 00:40 < gmaxwell> Right now we have a pretty strong assumption that we have full transactions, which makes pruning the wallet hard. E.g. you can't forget old transactions without losing track of spendable utxo or making the non-forgotten transactions show crazy data. 00:41 < wumpus> right, the wallet needs additional information about inputs 00:41 < wumpus> so that even if the originating transactions are no longer known, it still knows the sizes involved 00:42 < raedah> gmaxwell, im not clear here. We do know what our input and outputs in the transaction are. 00:43 < wumpus> raedah: we don't know what our outputs are, I think? 00:43 < raedah> all inputs and outputs are loaded as watchaddresses 00:43 < wumpus> at least in the case of an outgoing coinjoin transaction we can't distinguish what we intended to send from what the others sent 00:43 < gmaxwell> raedah: we don't; we know some inputs came from our wallet, we see other inputs but do not know their values (it's knowable, but the wallet doesn't track it). Then there are outputs, and unless you are paying yourself, the wallet doesn't know which are 'yours'. 00:44 < gmaxwell> raedah: well thats busted. 00:44 < wumpus> where? why would you load outputs as watchaddress? 00:44 < gmaxwell> loading them all as watch addresses still doesn't tell you which are yours, it just make it look like they all are. :) 00:45 < raedah> not all the addresses in the transaction are watch addresses. Just the ones in your joinmarket wallet become watch addresses. 00:45 < wumpus> and loading the inputs as watch-only doesn't make sense either, they're still not your inputs or your balance 00:46 < gmaxwell> raedah: okay, then again the wallet doesn't know the values of coins from other users; and it doesn't know which payments are yours unless you are paying yourself. 00:46 < gmaxwell> a JM maker is all paying themselves, true, but not a JM taker. 00:47 < wumpus> I'm not sure how watch-only helps here at all 00:48 < gmaxwell> wumpus: JM's 'market makers' have their own external wallet managed by JM, effectively. 00:48 < wumpus> ok - if there is an external wallet owned by you adding *those* as watchonly makes sense 00:49 < wumpus> because it's your balance. But adding other people's inputs/outputs would not be a good idea. 00:49 < gmaxwell> Basically JM's coinjoin 'ecosystem' implements an asymetric design where there are people hanging around who put up coin for people to join with ('market makers'); and then users can show up and pick up join bids from one or more makers to construct a coinjoin payment. 00:49 < raedah> wumpus, and joinmarket requires it to pull the data it needs on those addressses from the rpc. 00:50 < gmaxwell> The makers just deposit some coins into JM and it produces income (though not much because there is lots of competition!) 00:50 < wumpus> gmaxwell: makes sense 00:50 < gmaxwell> raedah: do you know specifically what it needs? 00:51 < gmaxwell> If it need to look up txouts, that can be done without wallet importing; we have an rpc for that. 00:51 < raedah> i think its looking for address balances, and maybe tx confirmations. 00:52 * gmaxwell ducks into #joinmarket 00:52 < wumpus> both can be determinied using just the utxo set 00:53 < wumpus> (as anything actively spendable, is, by definition, in there) 00:53 < wumpus> no need for any scan over transaction history 00:54 * wumpus tries to remember how the RPC call to query utxos was called... 00:54 < gmaxwell> They may not know about gettxout or gettxoutproof. 00:54 < wumpus> heh :-) 00:55 -!- paveljanik [~paveljani@79-98-72-216.sys-data.com] has joined #bitcoin-core-dev 00:55 -!- paveljanik [~paveljani@79-98-72-216.sys-data.com] has quit [Changing host] 00:55 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev 00:56 < gmaxwell> earlier on it used some third party API; which probably didn't provide an interface intended for scalablity. :) 00:56 < wumpus> https://bitcoin.org/en/developer-reference#gettxout 00:56 < wumpus> (gettxoutproof is also documented in the same place) 01:01 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has joined #bitcoin-core-dev 01:02 -!- jgarzik__ [~jgarzik@104-178-201-106.lightspeed.tukrga.sbcglobal.net] has quit [Ping timeout: 260 seconds] 01:03 < wumpus> does that give enough functionality or do you really need to query the utxo set by address/output script? 01:04 < gmaxwell> It shouldn't!, but I'm asking. 01:05 < gmaxwell> after all, you're talking to all the participants, so they can identify their coins. But maybe they put some dumb expectation into the protocol based around using an API. 01:05 < wumpus> (adding an RPC for that was considered at some point, without index it'd be kind of slow, but OTOH much faster and more efficient than a rescan) 01:05 < gmaxwell> (if so, then that can be fixed.. as the protocol is far from set in stone) 01:06 < wumpus> right 01:07 -!- raedah [~raedah@172.56.39.224] has quit [Quit: Leaving] 01:07 < gmaxwell> https://github.com/chris-belcher/joinmarket/blob/master/lib/blockchaininterface.py 01:08 < gmaxwell> yea, looks like it's trying to emulate the blockr interface instead of doing things sanely. 01:11 -!- ParadoxSpiral [~ParadoxSp@p508B8799.dip0.t-ipconnect.de] has quit [Ping timeout: 260 seconds] 01:15 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection] 01:16 -!- JackH [~Jack@host-80-43-142-236.as13285.net] has joined #bitcoin-core-dev 01:27 -!- phantomcircuit_ is now known as phantomcircuit 01:30 -!- Madars [~null@unaffiliated/madars] has joined #bitcoin-core-dev 01:32 -!- morcos [~morcos@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Ping timeout: 264 seconds] 01:32 -!- jcorgan_ [~jcorgan@unaffiliated/jcorgan] has quit [Ping timeout: 264 seconds] 01:33 -!- JackH [~Jack@host-80-43-142-236.as13285.net] has quit [Ping timeout: 264 seconds] 01:33 -!- pmienk_ [~pmienk@c-71-227-177-179.hsd1.wa.comcast.net] has quit [Ping timeout: 264 seconds] 01:33 -!- go1111111 [~go1111111@104.200.154.31] has quit [Ping timeout: 264 seconds] 01:33 -!- nanotube [~nanotube@unaffiliated/nanotube] has quit [Ping timeout: 264 seconds] 01:33 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 01:34 < aj_> gmaxwell: mind checking https://gist.github.com/ajtowns/3fd596af4f81042ef6ac before i post to lightning-dev (summarising the reveal-P script)? 01:35 < gmaxwell> No dup 01:35 < gmaxwell> size does not consume its input. 01:35 < aj_> right 01:38 < gmaxwell> 57 is ~ 15 zeros. Your ECC mult numbers are comically slow. 01:38 -!- Thireus [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev 01:39 < gmaxwell> https://www.blockstream.com/half-a-puzzle/ notice the ground nonces here. 01:40 < gmaxwell> 02000000000005689111130e588a12ecda87b2dc5585c6c6ba ffffffff077b7209dc866fbfa0d2bf67a0c696afffe57a822e deadbeef2f4a23b0f1954100b76bcb720f7b2ddc4a446dc06b 01:40 < aj_> yeah, that's 5 bytes of zeroes 01:41 < gmaxwell> You don't need to do a full EC multiply (though if you did, libsecp256k1 does more like 100k/sec of them per core) 01:41 < sipa_> i suppose the above few lines contain several hints? 01:41 -!- sipa_ is now known as sipa 01:41 -!- morcos [~morcos@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev 01:41 < aj_> sipa: yeah, gmaxwell stated the script already 01:41 < aj_> sipa: in -wizards anyway; oops, i guess this is the wrong channel 01:42 < gmaxwell> oops 01:42 -!- jcorgan [~jcorgan@ec2-54-67-38-167.us-west-1.compute.amazonaws.com] has joined #bitcoin-core-dev 01:42 -!- jcorgan [~jcorgan@ec2-54-67-38-167.us-west-1.compute.amazonaws.com] has quit [Changing host] 01:42 -!- jcorgan [~jcorgan@unaffiliated/jcorgan] has joined #bitcoin-core-dev 01:43 -!- nanotube [~nanotube@unaffiliated/nanotube] has joined #bitcoin-core-dev 01:44 -!- go1111111 [~go1111111@104.200.154.31] has joined #bitcoin-core-dev 01:45 -!- JackH [~Jack@host-80-43-142-236.as13285.net] has joined #bitcoin-core-dev 01:47 -!- pmienk_ [~pmienk@c-71-227-177-179.hsd1.wa.comcast.net] has joined #bitcoin-core-dev 01:48 -!- aj_ is now known as aj 01:57 -!- Thireus [~Thireus@icy.thireus.fr] has quit [Quit: Leaving.] 01:59 -!- Thireus [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev 02:18 < GitHub56> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/be281d8a83ca...f8a8e27a6a19 02:18 < GitHub56> bitcoin/master fa472f3 MarcoFalke: [trivial] Fix -maxmempool InitError 02:18 < GitHub56> bitcoin/master f8a8e27 Wladimir J. van der Laan: Merge pull request #7069... 02:19 < GitHub188> [bitcoin] laanwj closed pull request #7069: [trivial] Fix -maxmempool InitError (master...MarcoFalke-2015-maxmempoolInitError) https://github.com/bitcoin/bitcoin/pull/7069 02:35 < jonasschnelli> When is code freeze for 0.12? 02:35 < jonasschnelli> (or feature freeze) 02:36 < jonasschnelli> Found it. 01.12.15 02:36 < gmaxwell> I was expecting the end of the monthish. Don't tell me I've got more weeks! :P 02:37 < btcdrak> haha, that's British notation gmaxwell ;) 02:37 < btcdrak> the right way! 02:37 < sipa> what's so british about it? :) 02:38 < gmaxwell> it's bass-ackwards? 02:38 < btcdrak> :D 02:38 < gmaxwell> ISO forever. 2015-12-01 02:38 < sipa> the only right date format is of course 2015-12-01, which is lexicographically sortable 02:38 < btcdrak> ^ Chinese 02:38 < jonasschnelli> d-m-y ... that's how the brain things. (at least mine. :P ) 02:38 < wumpus> agree with sipa 02:38 < jonasschnelli> *thinks 02:38 < gmaxwell> okay, that was my expectation. whew. 02:39 < sipa> 2015-01-12 is of course not really a date format at all, but an elaborate prank by americans on the rest of the world 02:40 < wumpus> at least write out the month name if you'er doing that :) 02:40 < gmaxwell> or only work with days after the 12th. 02:42 < sipa> oh, it's 12/01/2015 in the us 02:42 < sipa> i just remember it's middle endian 02:44 < paveljanik> I like the term "middle endian" ;-) 02:44 < gmaxwell> it's a thing 02:44 < paveljanik> one friend is using "just enough endian" 02:45 < wumpus> it's a good example of where a compromise is the worst outcome possible :) 02:46 < gmaxwell> sipa: lets just use MJD ... 57356 is less typing than all that stuff. 02:47 < paveljanik> or XI.XXVI.MMXV 02:47 < wumpus> baa if we're going that way I'd prefer to just use megaseconds 02:47 * gmaxwell waits for luke-jr to tell us the tonal date 02:47 < sipa> gmaxwell: that's may 6th 735? 02:48 < wumpus> since the epoch of course 02:48 -!- Thireus [~Thireus@icy.thireus.fr] has quit [Remote host closed the connection] 02:48 < sipa> wumpus: megaseconds are not very accurate 02:48 < paveljanik> you mean from the genesis block? 02:48 < sipa> wumpus: how about deciforthnights? 02:48 < wumpus> sipa: right, well, just use fractions 02:48 < gmaxwell> sipa: no, 2015-12-01; there 02:49 < wumpus> (precision as necessary) 02:49 < sipa> gmaxwell: oh, i misread as MYD, and though you were just concatenating M Y and D 02:49 < sipa> gmaxwell: it's Msomething julian date? 02:49 < gmaxwell> Yes, http://tycho.usno.navy.mil/mjd.html 02:53 -!- Thireus [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev 03:05 -!- guest234234 [~guest2342@223.207.237.249] has joined #bitcoin-core-dev 03:07 -!- d_t_ [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 03:23 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Quit: Leaving.] 03:46 -!- andytoshi [~andytoshi@wpsoftware.net] has quit [Ping timeout: 272 seconds] 03:54 -!- jtimon [~quassel@74.29.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 04:07 < jonasschnelli> jgarzik: Did you had time to review https://github.com/jgarzik/univalue/pull/14 ? 04:13 < gmaxwell> When andytoshi's back online he should be pinged to differentially test against that. 04:14 < gmaxwell> He reimplementd univale in rust and has a testharness that checks if it round trip reseralizes the same as univale; and that was one of the cases he has to filter out. 04:27 < wumpus> doesn't rust already have libraries for json parsing/generation? or was that mostly an educational exercise? 04:33 -!- MarcoFalke [c3523fc6@gateway/web/cgi-irc/kiwiirc.com/ip.195.82.63.198] has joined #bitcoin-core-dev 04:45 < jonasschnelli> wumpus: do you think fixing the settxfee bug with a tiny risk of RPC/UI interfering is okay? IMO its okay. 04:45 < jonasschnelli> I don't expect people using RPC and UI at the same time. 04:46 < jonasschnelli> Maybe we should warn in the release notes at least. 04:46 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving] 04:47 < wumpus> jonasschnelli: well, we should try to rule out that risk as much as possible 04:48 < wumpus> jonasschnelli: sure, as long as the conditions under which it happens are clear, and it's an unlikely scenario, warning about it in the release notes would be enough 04:48 -!- andytoshi [~andytoshi@wpsoftware.net] has joined #bitcoin-core-dev 04:48 < wumpus> but 'using RPC with the UI randomly crashes or sends random amounts to random people' would not be :) 04:48 < jonasschnelli> Right... I don't expect people to blame us of not fixing the UI/RPC interfering bug over backports. 04:49 < MarcoFalke> About fees and release notes: I think a general write up about how fees work now should be planned 04:49 < wumpus> MarcoFalke: yes that would be welcome 04:49 < jonasschnelli> I think we do need to backport the rpc test as well? We don't want to have broken tests in 0.11? 04:50 < wumpus> although it's still kind of in flux, e.g. the final shape of mempool limiting isn't entirely clear yet 04:50 * jonasschnelli is working on the most simplest backport 04:50 < wumpus> jonasschnelli: yes, definitely 04:50 < wumpus> jonasschnelli: tests are the most important part, they prove that it's fixed :) 04:50 < jonasschnelli> ha. right! 04:52 < GitHub194> [bitcoin] MarcoFalke opened pull request #7103: [wallet, rpc tests] Fix settxfee, paytxfee (master...FixSettxfee) https://github.com/bitcoin/bitcoin/pull/7103 04:52 < MarcoFalke> Will do the backport soon 04:52 < wumpus> are you and jonasschnelli working together or duplicating work? 04:53 < MarcoFalke> jonas is doing the gui work 04:53 < MarcoFalke> I did the rpc tests 04:53 < MarcoFalke> we split up in two PRs 04:53 < wumpus> ok, great! 04:57 < jonasschnelli> Yeah. Fine for me. I appreciate every help. 04:58 < jonasschnelli> MarcoFalke: I agree with wumpus. I think to reduce the diff (mind backport) we should keep the 8 digits for Decimal('-0.00010000')) 04:59 < MarcoFalke> >>> Decimal("0.100") == Decimal(".1") 04:59 < MarcoFalke> True 04:59 < MarcoFalke> I will get rid of those, 04:59 < wumpus> I don't really have an opinion on the precision, but I didn't understand the change :) 05:01 < wumpus> changing one line in the code is a nicely minimal change though 05:01 < jonasschnelli> a true/false flip is probably the smallest change we can offer. :) 05:02 < wumpus> yes a one bitflip 05:07 < MarcoFalke> Whos responsible for travis? 05:07 < MarcoFalke> Need someone to ping :) 05:08 < sipa> MarcoFalke: what's the problem? 05:08 < MarcoFalke> Two workers are stuck since several days, I think 05:08 < jonasschnelli> i think it just requires some minutes until it starts 05:09 < wumpus> I can restart tasks and clear the caches,but I don't think I have direct control over the workers 05:09 < jonasschnelli> I think MarcoFalke is right: https://travis-ci.org/bitcoin/bitcoin/builds/92025728 05:09 < MarcoFalke> https://travis-ci.org/bitcoin/bitcoin/builds/92213684 05:10 < sipa> cancelled 05:11 < MarcoFalke> nice, 4/5 05:11 < MarcoFalke> Can you cancel https://travis-ci.org/bitcoin/bitcoin/builds/92213684 as well 05:12 < sipa> done 05:12 < sipa> restarted 05:12 < MarcoFalke> all running 5/5 05:15 -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 05:16 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 240 seconds] 06:03 -!- wangchun [~wangchun@li414-193.members.linode.com] has joined #bitcoin-core-dev 06:20 -!- guest234234 [~guest2342@223.207.237.249] has quit [Ping timeout: 260 seconds] 06:29 < jonasschnelli> wumpus: need to bother you with a UI questions: why did you implement the UI block updates (num blocks, last block date) with a timer function with a TRY_LOCK? 06:29 < jonasschnelli> would something speak against using the signal? 06:30 < jonasschnelli> the timer is still required for the bandwith graph... 06:30 < sipa> jonasschnelli: the signal may fire way too frequently sometimes, afaik 06:30 < sipa> up to the point that updating the GUI was slowing down synchronization 06:30 < jonasschnelli> the timer with the trylock fires every 250ms! 06:31 < sipa> during IBD the signal may fire every ms :) 06:31 < jonasschnelli> okay... the UI could measure the time delta (inexpansive uint64_t compare) and update the ui every 5 sec or so. 06:32 < jonasschnelli> it just looks like that the TRY_LOCK often can acquire the lock 06:32 < jonasschnelli> can't 06:34 < jonasschnelli> sipa: if i recall that correctly, the signals `CBlockIndex *pindexNewTip` does not require a lock... so the UI update could be done on the UI tread?! 06:41 < sipa> jonasschnelli: that's correct, but signals still run synchronously 06:42 < jonasschnelli> sipa: right,.. but at least the could emit/pass a QT async signal to the GUI thread 06:42 < GitHub0> [bitcoin] pstratem opened pull request #7104: [Mining] Build empty block on when chainTip changes. (master...2015-11-26-gbt-latency) https://github.com/bitcoin/bitcoin/pull/7104 06:42 < sipa> jonasschnelli: i don't think you want to emit 1000 signals per second still :) 06:43 < jonasschnelli> sipa: hmm... let me benchmark it,.. maybe a min-time-delta is required to avoid over-updating the ui. 06:43 < jonasschnelli> and the signal only fires !fInitialDownload 06:44 < sipa> ah 07:05 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 07:24 < jgarzik> RE univalue - I see one outstanding issue to address that wumpus ping'd on - everything else is fixed in upstream univalue tree. 07:27 -!- arowser [~quassel@106.120.101.38] has quit [Quit: No Ping reply in 180 seconds.] 07:27 -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-core-dev 07:34 < jonasschnelli> sipa: is "Tip Notification: 0.03ms" reasonable (standard core i7 laptop)? Currently I update the UI also during fInitialSync.... looks nice! 07:35 -!- ParadoxSpiral [~ParadoxSp@p508B8799.dip0.t-ipconnect.de] has joined #bitcoin-core-dev 07:36 < sipa> that seems ok... 07:37 < jtimon> cfields_: I can't undesrtand why these commits break the build, it would be great if you could explain. why does the order matter in bitcoind_LDADD? why crypto/libbitcoin_crypto.a works but consensus/libbitcoin_consensus.a doesn't (inside of the consensus dir)? https://github.com/jtimon/bitcoin/compare/consensus-build...jtimon:consensus-build-full 08:00 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [] 08:03 < sipa> jonasschnelli: going to try to implement another approach for 7067 08:03 < jonasschnelli> sipa: that was actually my intention... :) 08:13 < jtimon> cfields_: I mean, the first commit in #7091 builds locally (xubuntu14) but travis says it already breaks the build for everything but mac, but maybe those errors I get locally and can't uncerstand are related 08:33 -!- tripleslash_a [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev 08:35 -!- evoskuil [~evoskuil@c-73-225-134-208.hsd1.wa.comcast.net] has quit [Read error: Connection reset by peer] 08:35 -!- evoskuil [~evoskuil@c-73-225-134-208.hsd1.wa.comcast.net] has joined #bitcoin-core-dev 08:35 -!- andytoshi [~andytoshi@wpsoftware.net] has quit [Ping timeout: 240 seconds] 08:35 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Ping timeout: 240 seconds] 08:36 -!- andytoshi [~andytoshi@wpsoftware.net] has joined #bitcoin-core-dev 08:40 -!- jl2012_ [~jl2012@pn-206-80.itsc.cuhk.edu.hk] has joined #bitcoin-core-dev 08:40 -!- jl2012 [~jl2012@unaffiliated/jl2012] has quit [Ping timeout: 272 seconds] 09:15 -!- Thireus [~Thireus@icy.thireus.fr] has quit [Quit: Leaving.] 09:45 -!- ParadoxSpiral_ [~ParadoxSp@p508B827F.dip0.t-ipconnect.de] has joined #bitcoin-core-dev 09:48 -!- ParadoxSpiral [~ParadoxSp@p508B8799.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds] 09:58 -!- cocoBTC [~cocoBTC__@c-233a71d5.136-1-64736c10.cust.bredbandsbolaget.se] has joined #bitcoin-core-dev 09:59 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 10:20 -!- raedah [~raedah@172.56.39.224] has joined #bitcoin-core-dev 10:24 -!- JackH [~Jack@host-80-43-142-236.as13285.net] has quit [Ping timeout: 250 seconds] 10:28 -!- paveljanik [~paveljani@79-98-72-216.sys-data.com] has joined #bitcoin-core-dev 10:28 -!- paveljanik [~paveljani@79-98-72-216.sys-data.com] has quit [Changing host] 10:28 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev 10:40 -!- Thireus [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev 10:53 -!- warren_2 [~warren@198.199.103.138] has joined #bitcoin-core-dev 11:02 -!- Guest1235 [~ubuntu@ec2-52-0-91-57.compute-1.amazonaws.com] has joined #bitcoin-core-dev 11:10 -!- Netsplit *.net <-> *.split quits: sdaftuar, ghtdak, guruvan, Madars, aj, lclc, Guest1234, d_t, helo, Ylbam, (+64 more, use /NETSPLIT to show all of them) 11:10 -!- warren_2 is now known as warren 11:10 -!- Amnez777 [~Amnez777@unaffiliated/amnez777] has quit [Excess Flood] 11:10 -!- Arnavion [arnavion@unaffiliated/arnavion] has quit [Remote host closed the connection] 11:10 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Read error: Connection reset by peer] 11:11 -!- btcdrak [uid115429@gateway/web/irccloud.com/x-rqjvrrwnviripsnr] has joined #bitcoin-core-dev 11:11 -!- Netsplit over, joins: instagibbs 11:11 -!- Arnavion [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev 11:11 -!- Netsplit over, joins: amiller_, berndj, andytoshi, asoltys, ghtdak, bsm1175322, aj, mm_1, neha, ParadoxSpiral_ (+1 more) 11:11 -!- jgarzik_ [~jgarzik@104-178-201-106.lightspeed.tukrga.sbcglobal.net] has joined #bitcoin-core-dev 11:11 -!- JackH [~Jack@host-80-43-142-236.as13285.net] has joined #bitcoin-core-dev 11:11 -!- gavinand1esen [~gavin@66.172.11.36] has joined #bitcoin-core-dev 11:11 -!- Netsplit over, joins: lclc, morcos 11:11 -!- Guest22577 [~anduck@aom.fi] has joined #bitcoin-core-dev 11:11 -!- Netsplit over, joins: sdaftuar, BlueMatt_, raedah 11:11 -!- d_t_ [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 11:11 -!- Netsplit over, joins: AtashiCon 11:11 -!- harding_ [~harding@mail.dtrt.org] has joined #bitcoin-core-dev 11:11 -!- lecusemb1e [~lecusembl@f9beb4d9.violates.me] has joined #bitcoin-core-dev 11:11 -!- Netsplit over, joins: jtimon, Madars, crescend1, bsm1175321, murr4y, cocoBTC, jl2012_, evoskuil, arowser, nanotube (+22 more) 11:12 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev 11:13 -!- Amnez777 [~Amnez777@37.157.216.168] has joined #bitcoin-core-dev 11:13 -!- warren is now known as Guest26532 11:15 -!- Netsplit over, joins: go1111111, phantomcircuit, wumpus, Ylbam, midnightmagic, zmanian_, jcorgan, petertodd, sipa, blkdb (+3 more) 11:15 -!- Amnez777 [~Amnez777@37.157.216.168] has quit [Changing host] 11:15 -!- Amnez777 [~Amnez777@unaffiliated/amnez777] has joined #bitcoin-core-dev 11:15 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #bitcoin-core-dev 11:16 -!- dermoth [~thomas@dsl-216-221-56-153.mtl.aei.ca] has joined #bitcoin-core-dev 11:20 -!- morcos_ [~morcos@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev 11:20 -!- Netsplit over, joins: d_t 11:26 -!- Arnavion [arnavion@unaffiliated/arnavion] has quit [Remote host closed the connection] 11:26 -!- d_t_ [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Ping timeout: 240 seconds] 11:26 -!- AtashiCon [arnavion@unaffiliated/arnavion] has quit [Ping timeout: 240 seconds] 11:26 -!- evoskuil [~evoskuil@c-73-225-134-208.hsd1.wa.comcast.net] has quit [Ping timeout: 240 seconds] 11:27 -!- evoskuil [~evoskuil@c-73-225-134-208.hsd1.wa.comcast.net] has joined #bitcoin-core-dev 11:27 -!- Netsplit *.net <-> *.split quits: raedah, morcos 11:27 -!- Netsplit *.net <-> *.split quits: Thireus, lecusemb1e 11:27 -!- Arnavion [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev 11:27 -!- Netsplit over, joins: lecusemble 11:28 -!- Netsplit over, joins: Eliel 11:29 -!- harding_ [~harding@mail.dtrt.org] has quit [Ping timeout: 264 seconds] 11:29 -!- MarcoFalke [c3523fc6@gateway/web/cgi-irc/kiwiirc.com/ip.195.82.63.198] has quit [Ping timeout: 264 seconds] 11:30 -!- cocoBTC [~cocoBTC__@c-233a71d5.136-1-64736c10.cust.bredbandsbolaget.se] has quit [Ping timeout: 264 seconds] 11:30 -!- dermoth [~thomas@dsl-216-221-56-153.mtl.aei.ca] has quit [Ping timeout: 264 seconds] 11:30 -!- arowser [~quassel@106.120.101.38] has quit [Ping timeout: 264 seconds] 11:30 -!- tripleslash_b [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev 11:30 -!- Netsplit over, joins: raedah 11:33 -!- [1]evoskuil [~evoskuil@c-73-225-134-208.hsd1.wa.comcast.net] has joined #bitcoin-core-dev 11:34 -!- lclc_ [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev 11:35 -!- evoskuil [~evoskuil@c-73-225-134-208.hsd1.wa.comcast.net] has quit [Ping timeout: 240 seconds] 11:35 -!- [1]evoskuil is now known as evoskuil 11:36 -!- lecusemble [~lecusembl@f9beb4d9.violates.me] has quit [Ping timeout: 260 seconds] 11:38 -!- sdaftuar_ [~sdaftuar@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev 11:39 -!- Netsplit *.net <-> *.split quits: [b__b], tripleslash, lclc, sdaftuar 11:39 -!- Netsplit *.net <-> *.split quits: teward, cfields_, bsm1175321 11:39 -!- cfields [~quassel@unaffiliated/cfields] has joined #bitcoin-core-dev 11:42 -!- Netsplit over, joins: teward 11:43 -!- JackH [~Jack@host-80-43-142-236.as13285.net] has quit [Ping timeout: 260 seconds] 11:44 -!- cocoBTC [~cocoBTC__@c-233a71d5.136-1-64736c10.cust.bredbandsbolaget.se] has joined #bitcoin-core-dev 11:47 -!- Netsplit over, joins: harding 11:49 -!- lecusemble [~lecusembl@f9beb4d9.violates.me] has joined #bitcoin-core-dev 11:50 -!- dermoth [~thomas@dsl-216-221-56-153.mtl.aei.ca] has joined #bitcoin-core-dev 11:50 -!- Netsplit over, joins: tripleslash 11:51 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Read error: Connection reset by peer] 11:52 -!- tripleslash_b [~triplesla@unaffiliated/imsaguy] has quit [Ping timeout: 240 seconds] 11:52 -!- cfields [~quassel@unaffiliated/cfields] has quit [Ping timeout: 240 seconds] 11:52 -!- evoskuil [~evoskuil@c-73-225-134-208.hsd1.wa.comcast.net] has quit [Ping timeout: 240 seconds] 11:52 -!- evoskuil [~evoskuil@c-73-225-134-208.hsd1.wa.comcast.net] has joined #bitcoin-core-dev 11:55 -!- cfields [~quassel@unaffiliated/cfields] has joined #bitcoin-core-dev 11:56 -!- bsm117532 [~mcelrath@38.121.165.30] has joined #bitcoin-core-dev 11:57 -!- Netsplit *.net <-> *.split quits: BlueMatt_ 12:02 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has joined #bitcoin-core-dev 12:04 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev 12:12 -!- jonasschnelli [~jonasschn@unaffiliated/jonasschnelli] has quit [Excess Flood] 12:13 -!- jonasschnelli [~jonasschn@unaffiliated/jonasschnelli] has joined #bitcoin-core-dev 12:36 -!- raedah [~raedah@172.56.39.224] has quit [Quit: Leaving] 12:49 < GitHub6> [bitcoin] sipa opened pull request #7105: Keep track of explicit wallet conflicts instead of using mempool (master...realconflicts) https://github.com/bitcoin/bitcoin/pull/7105 12:53 -!- instagibbs_ [~greg@pool-108-31-210-40.washdc.fios.verizon.net] has joined #bitcoin-core-dev 12:57 -!- dermoth [~thomas@dsl-216-221-56-153.mtl.aei.ca] has quit [Ping timeout: 246 seconds] 12:57 -!- instagibbs [~greg@pool-108-31-210-40.washdc.fios.verizon.net] has quit [Ping timeout: 246 seconds] 12:59 -!- dermoth [~thomas@dsl-216-221-56-153.mtl.aei.ca] has joined #bitcoin-core-dev 13:00 -!- Thireus [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev 13:11 < GitHub77> [bitcoin] sipa opened pull request #7106: Fix and improve relay from whitelisted peers (master...realwhiterelay) https://github.com/bitcoin/bitcoin/pull/7106 13:36 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev 13:38 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 13:41 -!- go1111111 [~go1111111@104.200.154.31] has quit [Ping timeout: 250 seconds] 13:50 -!- ParadoxSpiral_ [~ParadoxSp@p508B827F.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 14:08 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 14:09 -!- go1111111 [~go1111111@2604:4080:1128:0:cd7:de9b:2247:8188] has joined #bitcoin-core-dev 14:11 -!- JackH [~Jack@host-80-43-142-236.as13285.net] has joined #bitcoin-core-dev 14:13 -!- go1111111 [~go1111111@2604:4080:1128:0:cd7:de9b:2247:8188] has quit [Ping timeout: 240 seconds] 14:19 < cocoBTC> Should QT commits be tagged [Qt], or is there any convention there? 14:20 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)] 14:22 -!- MarcoFalke [c3523fc6@gateway/web/cgi-irc/kiwiirc.com/ip.195.82.63.198] has joined #bitcoin-core-dev 14:31 -!- MarcoFalke [c3523fc6@gateway/web/cgi-irc/kiwiirc.com/ip.195.82.63.198] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] 14:32 -!- JackH [~Jack@host-80-43-142-236.as13285.net] has quit [Ping timeout: 240 seconds] 14:38 -!- alpalp [~alp@104-54-235-28.lightspeed.austtx.sbcglobal.net] has quit [Remote host closed the connection] 14:43 < GitHub102> [bitcoin] Cocosoft opened pull request #7107: Qt: Add network port input box to GUI settings (master...qtnetworkport) https://github.com/bitcoin/bitcoin/pull/7107 14:51 -!- michagogo [uid14316@wikia/Michagogo] has quit [Remote host closed the connection] 14:51 -!- d_t [~textual@204.28.124.82] has joined #bitcoin-core-dev 14:54 -!- Squidicuz [~squid@pool-173-48-117-206.bstnma.fios.verizon.net] has joined #bitcoin-core-dev 15:09 -!- JackH [~Jack@host-80-43-142-236.as13285.net] has joined #bitcoin-core-dev 15:19 -!- michagogo [uid14316@wikia/Michagogo] has joined #bitcoin-core-dev 15:27 -!- lclc_ is now known as lclc 15:33 -!- Guest22577 [~anduck@aom.fi] has quit [Quit: Reconnecting] 15:33 -!- Anduck [~anduck@aom.fi] has joined #bitcoin-core-dev 15:34 -!- Anduck is now known as Guest39247 15:35 -!- Guest39247 [~anduck@aom.fi] has quit [Client Quit] 15:36 -!- Anduck_ [~anduck@unaffiliated/anduck] has joined #bitcoin-core-dev 15:50 -!- sipa [~pw@2a02:348:86:3011::1] has quit [Changing host] 15:50 -!- sipa [~pw@unaffiliated/sipa1024] has joined #bitcoin-core-dev 15:51 -!- cfields_ [~quassel@unaffiliated/cfields] has joined #bitcoin-core-dev 15:54 -!- Netsplit *.net <-> *.split quits: evoskuil, michagogo, cfields 15:56 -!- btcdrak [uid115429@gateway/web/irccloud.com/x-rqjvrrwnviripsnr] has quit [Quit: Connection closed for inactivity] 16:02 -!- cocoBTC [~cocoBTC__@c-233a71d5.136-1-64736c10.cust.bredbandsbolaget.se] has quit [Quit: Leaving] 16:04 -!- evoskuil [~evoskuil@c-73-225-134-208.hsd1.wa.comcast.net] has joined #bitcoin-core-dev 16:04 -!- michagogo [uid14316@wikia/Michagogo] has joined #bitcoin-core-dev 16:08 -!- d4de [~d4de@41.234.215.214] has quit [Ping timeout: 276 seconds] 16:33 -!- AtashiCon [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev 16:35 -!- guest234234 [~guest2342@223.207.237.249] has joined #bitcoin-core-dev 16:41 -!- jl2012 [~jl2012@unaffiliated/jl2012] has joined #bitcoin-core-dev 16:42 -!- jl2012_ [~jl2012@pn-206-80.itsc.cuhk.edu.hk] has quit [Ping timeout: 276 seconds] 17:04 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-vvndlqovnchvmuww] has quit [Quit: Connection closed for inactivity] 17:20 -!- guest234234 [~guest2342@223.207.237.249] has quit [Read error: Connection reset by peer] 17:27 -!- michagogo [uid14316@wikia/Michagogo] has quit [Quit: Connection closed for inactivity] 17:50 -!- guest234234 [~guest2342@223.207.237.249] has joined #bitcoin-core-dev 17:51 < BlueMatt> gmaxwell: yea, i havent had a chance to look into it 17:57 < BlueMatt> midnightmagic: hmm, yea, if thats still possible docs should be fixed to block internet access, not allow it 18:00 -!- dermoth [~thomas@dsl-216-221-56-153.mtl.aei.ca] has quit [Read error: Connection reset by peer] 18:00 -!- dermoth [~thomas@dsl-216-221-56-153.mtl.aei.ca] has joined #bitcoin-core-dev 18:07 -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-core-dev 18:41 -!- blkdb [~blkdb@2a01:4f8:212:1ea2::2] has quit [Remote host closed the connection] 18:42 -!- blkdb [~blkdb@2a01:4f8:212:1ea2::2] has joined #bitcoin-core-dev 18:46 -!- challisto [~challisto@unaffiliated/challisto] has joined #bitcoin-core-dev 18:53 -!- Anduck_ is now known as Anduck 20:55 -!- d_t [~textual@204.28.124.82] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 21:06 -!- btcdrak [uid115429@gateway/web/irccloud.com/x-kcdeayhggdiycgds] has joined #bitcoin-core-dev 21:11 -!- guest234234 [~guest2342@223.207.237.249] has quit [Ping timeout: 264 seconds] 21:40 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 22:20 -!- d_t_ [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 22:23 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Ping timeout: 264 seconds] 22:24 -!- challisto [~challisto@unaffiliated/challisto] has quit [Ping timeout: 265 seconds] 22:24 -!- arowser [~quassel@106.120.101.38] has quit [Ping timeout: 265 seconds] 22:24 -!- AtashiCon [arnavion@unaffiliated/arnavion] has quit [Ping timeout: 264 seconds] 22:24 -!- instagibbs_ [~greg@pool-108-31-210-40.washdc.fios.verizon.net] has quit [Ping timeout: 264 seconds] 22:24 -!- AtashiCon [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev 22:24 -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-core-dev 22:28 -!- instagibbs [~greg@pool-108-31-210-40.washdc.fios.verizon.net] has joined #bitcoin-core-dev 22:30 -!- Anduck_ [~anduck@unaffiliated/anduck] has joined #bitcoin-core-dev 22:33 -!- d4de [~d4de@41.234.207.115] has joined #bitcoin-core-dev 22:37 -!- challisto [~challisto@unaffiliated/challisto] has joined #bitcoin-core-dev 22:38 -!- Netsplit *.net <-> *.split quits: Anduck, Thireus 22:58 -!- Thireus [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev 23:00 -!- Guest26532 is now known as warren 23:01 -!- warren is now known as Guest26511 23:03 -!- Guest26511 [~warren@198.199.103.138] has quit [Quit: ZNC - http://znc.in] 23:04 -!- warren_2 [~warren@fedora/wombat/warren] has joined #bitcoin-core-dev 23:10 -!- guest234234 [~guest2342@223.207.237.249] has joined #bitcoin-core-dev 23:35 < dcousens> phantomcircuit: why would it not be suitable for latency? (not trying to be ignorant) 23:36 < dcousens> for low latency* 23:38 < phantomcircuit> dcousens, because of the exact mechanism ckpool uses 23:38 < phantomcircuit> if blocknotify fails their latency is 30 seconds 23:38 < phantomcircuit> idiots 23:39 < phantomcircuit> i refuse to give them anymore free advise though 23:39 < gmaxwell> 04:27 < wumpus> doesn't rust already have libraries for json parsing/generation? or was that mostly an educational exercise? 23:40 < gmaxwell> Needed it for the same reason we need univalue instead of jansson or the like... all other json libraries insist on interperting the values for you. 23:40 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Max SendQ exceeded] 23:46 < Luke-Jr> well, to be fair, interpreting the values is literally the only thing JSON parsers do.. :p 23:52 < phantomcircuit> Luke-Jr, no they also distinguish between value and object 23:52 < phantomcircuit> although i guess technically that's also "just" a type 23:56 -!- berndj [~berndj@azna.co.za] has quit [Excess Flood] 23:57 < Luke-Jr> if Rust's JSON lib supported accessing JSON Numbers as the Ratio type, I think that'd be fine 23:57 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-aekottcgcttrasda] has joined #bitcoin-core-dev