12015-11-26T00:17:08  *** tulip has quit IRC
  22015-11-26T00:18:04  *** guest234234 has joined #bitcoin-core-dev
  32015-11-26T00:19:43  *** guest234234 has quit IRC
  42015-11-26T00:40:01  <gmaxwell> sipa: gonna address my comment on https://github.com/bitcoin/bitcoin/pull/6996 ?
  52015-11-26T00:40:37  <gmaxwell> sipa: do you have an opinions about jtimons's comment: https://github.com/bitcoin/bitcoin/pull/6508
  62015-11-26T00:44:23  *** jl2012 has quit IRC
  72015-11-26T00:44:33  *** jl2012 has joined #bitcoin-core-dev
  82015-11-26T00:46:28  <sipa> gmaxwell: yeah, will od
  92015-11-26T00:48:57  *** tulip has joined #bitcoin-core-dev
 102015-11-26T00:51:08  <cfields_> Luke-Jr: ping. Seems your dns seed doesn't support the 0x20 hack (that was fun to track down). What is it running?
 112015-11-26T00:51:33  <gmaxwell> Whats the 0x20 hack?
 122015-11-26T00:52:25  <cfields_> gmaxwell: reply with the same cAsE as the query
 132015-11-26T00:52:48  <sipa> cfields_: i think it's running github.com/sipa/bitcoin-seeder
 142015-11-26T00:53:28  <cfields_> sipa: assuming yours runs the same, i can't test against that now 'cause it's down :p
 152015-11-26T00:53:57  <sipa> mine is not down
 162015-11-26T00:54:19  <cfields_> mm, is for me
 172015-11-26T00:54:20  <sipa> at least, it's serving actual requests :)
 182015-11-26T00:54:24  <tulip> I can reach all of the DNS seeds at the moment.
 192015-11-26T00:54:58  <cfields_> gmaxwell: https://isc.sans.edu/diary/Use+of+Mixed+Case+DNS+Queries/12418
 202015-11-26T00:56:31  <Luke-Jr> what sipa said, but I don't see a use case to support this?
 212015-11-26T00:57:03  <cfields_> tulip: thanks. confirmed working on a vps as well. Looks like my default dns is borked atm
 222015-11-26T00:57:29  <tulip> ;; ANSWER SECTION:
 232015-11-26T00:57:29  <tulip> dnsseed.bitcoin.DASHjr.org
 242015-11-26T00:57:29  <gribble> Error: "ANSWER" is not a valid command.
 252015-11-26T00:57:35  <tulip> is that not correct?
 262015-11-26T00:59:38  <sipa> https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00
 272015-11-26T00:59:44  <cfields_> tulip: hmm, looks correct.
 282015-11-26T01:00:03  <tulip> maybe there's something between you and his DNS server which is mutating it?
 292015-11-26T01:00:10  <cfields_> (assuming that's how you queried it, ofc)
 302015-11-26T01:00:17  <tulip> yes.
 312015-11-26T01:01:47  <cfields_> hmm. libevent turns on a check by default, so resolves in my test app are failing. when i turn the option off they succeed. "dig" succeeds as well.
 322015-11-26T01:01:54  <cfields_> i'll keep poking around.
 332015-11-26T01:02:28  <cfields_> (matt/jonas seeds work fine)
 342015-11-26T01:08:51  <BlueMatt> wumpus: fyi, if you want me to see something on github, tag @BugTheBlueMatt not @TheBlueMatt (which just gets delivered just like any other notification email)
 352015-11-26T01:09:09  <BlueMatt> (and there doesnt seem to be a way to have github route to a different email address if you're tagged :/ )
 362015-11-26T01:09:26  <sipa> BlueMatt: disable all notification mails except tagging :)
 372015-11-26T01:09:38  <BlueMatt> sipa: but I dont want to do that :(
 382015-11-26T01:24:29  *** Ylbam has quit IRC
 392015-11-26T01:35:41  <BlueMatt> wumpus: also, wait, why does the gitian build env need network access?
 402015-11-26T01:36:03  <BlueMatt> it really shouldnt be allowed to have network access (we really want to support doing builds via gitian on airgapped machines)
 412015-11-26T01:36:29  <BlueMatt> oh, the pr is still open, i'll go comment there
 422015-11-26T01:40:49  *** Squidicc has joined #bitcoin-core-dev
 432015-11-26T01:41:21  *** dcousens has joined #bitcoin-core-dev
 442015-11-26T01:41:40  <dcousens> what happens if SIGHASH_SINGLE is used, but no corresponding output exists?
 452015-11-26T01:42:20  <tulip> the SIGHASH_SINGLE bug :P
 462015-11-26T01:42:34  <dcousens> haha, nvm, thats right
 472015-11-26T01:42:51  <sipa> dcousens: hash == 1 is signed
 482015-11-26T01:43:38  *** Squidicuz has quit IRC
 492015-11-26T01:43:39  *** jtimon has quit IRC
 502015-11-26T01:52:58  *** guest234234 has joined #bitcoin-core-dev
 512015-11-26T02:12:15  *** BashCo has quit IRC
 522015-11-26T02:12:21  *** BashCo_ has joined #bitcoin-core-dev
 532015-11-26T02:35:15  <midnightmagic> BlueMatt: it is possible to do it entirely offline unless something fundamental changed.
 542015-11-26T02:35:50  *** belcher has quit IRC
 552015-11-26T02:43:18  <gmaxwell> Fishing for concept acks dgenr8 pointed out that the sendbuffer size reduction a long time ago ended up turning the setInventoryKnown mruset down to 1000 entries!   I'd like to change that mruset to do per-peer salted key hashing and truncate to 64-bits, then increase its size to 100,000 entries.  With 64 bits the probablity that there has ever been a collission in the history of all transaction
 562015-11-26T02:43:24  <gmaxwell> s is only about 0.02% and even if there were one, it would just mean that you'd fail to INV a transaction to a single peer.
 572015-11-26T02:51:30  <tulip> height 385363 has 521 txns, 1142 sigs, 169 cache misses. not bad for a node with 10 minutes of uptime.
 582015-11-26T02:53:49  <gmaxwell> tulip: may be due to a peer spamming you with their mempool at connect.
 592015-11-26T02:55:44  <tulip> maybe.
 602015-11-26T02:55:58  <sipa> gmaxwell: or a rolling bloom filter?
 612015-11-26T02:57:16  <gmaxwell> I was trying to keep MRU behavior, but maybe we don't really need it.
 622015-11-26T02:57:28  <gmaxwell> would certantly be easier.
 632015-11-26T02:59:03  <gmaxwell> BlueMatt: on that subject, I still have this behavior where RNC seems broken; -- it's my only source of transactions on a testnode and I've never seen it get more than 1671 tx.
 642015-11-26T02:59:25  <gmaxwell> okay jinx, it's actually at 1783, but thats still small.
 652015-11-26T03:02:22  <sipa> gmaxwell: rolling bloom filter is effectively mru
 662015-11-26T03:04:32  <gmaxwell> RB is not per-use salted? weird. why.
 672015-11-26T03:07:25  <gmaxwell> what. I am boggle this code.
 682015-11-26T03:07:57  <gmaxwell> oh I see.
 692015-11-26T03:08:41  <gmaxwell> still, don't see why it's not salted.
 702015-11-26T03:10:24  <sipa> it is salted?
 712015-11-26T03:10:26  <sipa> no?
 722015-11-26T03:10:47  <gmaxwell> constructor has no salt argument and calls the underlying blooms with a tweak of 0.
 732015-11-26T03:13:34  <gmaxwell> looks like you have to call reset to randomize it.
 742015-11-26T03:13:38  <sipa> oh, right, we didn't want to call getrandbytes in a global constructor
 752015-11-26T03:13:45  <gmaxwell> ah duh.
 762015-11-26T03:14:09  <sipa> but it could actually automatically reset upon first use
 772015-11-26T03:14:43  <gmaxwell> just making ninsertions oversize would do that.  Is there a reason to just not reset it every time a table is changed?
 782015-11-26T03:15:03  <gmaxwell> e.g. with b1/b2 are cleared?
 792015-11-26T03:15:18  <sipa> yes, that's what i'm suggesting
 802015-11-26T03:15:33  <gmaxwell> No reason I can see why the two should have the same tweak.
 812015-11-26T03:15:46  <sipa> but only when an actual entry is written to it
 822015-11-26T03:15:53  <sipa> not on construction
 832015-11-26T03:16:11  <gmaxwell> yea, sure, I mean make the clear functions in insert do it when they clear.
 842015-11-26T03:16:35  <sipa> right
 852015-11-26T03:19:01  <gmaxwell> whats with the 2* in the rolling bloom filter?
 862015-11-26T03:19:15  <sipa> it's needed
 872015-11-26T03:19:19  <sipa> :)
 882015-11-26T03:20:22  <gmaxwell> whats an acceptable FP rate for the known filtering?
 892015-11-26T03:25:18  *** guest234234 has quit IRC
 902015-11-26T03:26:04  <sipa> you need around 4.8 bits per element per 1/10 FP rate
 912015-11-26T03:26:24  <sipa> so 6*4.8 bits per element for one in a million
 922015-11-26T03:27:59  <dcousens> "what. I am boggle this code." lol
 932015-11-26T03:30:21  <gmaxwell> sipa: as far as 'mru', well-- so it doesn't reinsert in the other filter when it hits. And doing it yourself isn't quite ideal since you'll increment the count.
 942015-11-26T03:30:52  <sipa> ?
 952015-11-26T03:30:53  <gmaxwell> so I think the contains code should check one filter, but insert in the other, not yet mature filter, in order to have the behavior you expected.
 962015-11-26T03:31:46  <gmaxwell> if I send you the same item non-stop, and you drop it when contains, it will fall out.
 972015-11-26T03:33:19  <sipa> right
 982015-11-26T03:33:35  <sipa> it is most recently added, not most recently used
 992015-11-26T03:50:27  *** Arnavion has quit IRC
1002015-11-26T03:50:43  *** Arnavion has joined #bitcoin-core-dev
1012015-11-26T04:32:39  *** guest234234 has joined #bitcoin-core-dev
1022015-11-26T04:40:02  <cfields_> Luke-Jr / sipa: nevermind the dns red herring earlier. It looks to be a combination of a libevent implementation detail and a dns resolver implementation detail. annoying.
1032015-11-26T04:41:36  <cfields_> we bump up against the 512 byte udp limit. Due to compression, messing with CaSe can grow the payload. Different resolvers/cachers react in different ways when hitting the 512 byte mark.
1042015-11-26T04:44:30  <cfields_> In this case, my local cache appends additional records. Apparently smart resolvers strip those off and just ignore the truncation. however, libevent marks a truncation as a failure.
1052015-11-26T05:41:33  *** tulip has quit IRC
1062015-11-26T05:48:27  <GitHub92> [bitcoin] gmaxwell opened pull request #7100: Replace setInventoryKnown with a rolling bloom filter. (master...known_bloom) https://github.com/bitcoin/bitcoin/pull/7100
1072015-11-26T06:21:47  *** PaulCapestany has quit IRC
1082015-11-26T06:23:41  *** PaulCapestany has joined #bitcoin-core-dev
1092015-11-26T06:29:46  *** PaulCapestany has quit IRC
1102015-11-26T06:31:08  *** PaulCapestany has joined #bitcoin-core-dev
1112015-11-26T06:36:59  *** PaulCapestany has quit IRC
1122015-11-26T06:41:49  *** PaulCapestany has joined #bitcoin-core-dev
1132015-11-26T07:10:49  *** Ylbam has joined #bitcoin-core-dev
1142015-11-26T07:25:32  *** moli has joined #bitcoin-core-dev
1152015-11-26T08:09:36  *** lightningbot has joined #bitcoin-core-dev
1162015-11-26T08:09:38  *** ParadoxSpiral has joined #bitcoin-core-dev
1172015-11-26T08:09:45  <wumpus> gmaxwell: well in many cases the tests just check current behavior, it's not always clear what the *correct* behavior should be
1182015-11-26T08:09:57  *** Arnavion has joined #bitcoin-core-dev
1192015-11-26T08:10:00  <jonasschnelli> Wait... sorry. wrong code line:
1202015-11-26T08:10:01  <jonasschnelli> the UI did play with a global var for a temporary state
1212015-11-26T08:10:05  <jonasschnelli> nFeeNeeded = payTxFee.GetFeePerK();
1222015-11-26T08:10:07  *** morcos has joined #bitcoin-core-dev
1232015-11-26T08:10:14  <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?
1242015-11-26T08:10:25  <wumpus> jonasschnelli: but this affect the non-UI as well right? I'm much more concerned with that
1252015-11-26T08:10:33  <jonasschnelli> right
1262015-11-26T08:10:40  <jonasschnelli> This is the problem: nFeeNeeded = payTxFee.GetFeePerK();
1272015-11-26T08:10:46  <jonasschnelli> We take a perKB fee rate as absolute fee.
1282015-11-26T08:10:54  <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
1292015-11-26T08:10:54  <jonasschnelli> But only when fPayAtLeastCustomFee = true
1302015-11-26T08:10:58  <jonasschnelli> (which is the default!)
1312015-11-26T08:10:58  <wumpus> but I'm not sure about RPC...
1322015-11-26T08:11:28  <jonasschnelli> IMO it's bad that the UI can change global state during "normal operation" (non-settings operations)
1332015-11-26T08:11:34  <wumpus> how are settxfee and smartfees *supposed* to interact?
1342015-11-26T08:11:43  <wumpus> jonasschnelli: I agree
1352015-11-26T08:12:10  *** Arnavion has quit IRC
1362015-11-26T08:12:15  <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.
1372015-11-26T08:12:33  <jonasschnelli> a) absolute fees should only be possible when enabling and using coincontrol
1382015-11-26T08:12:36  <wumpus> there should be nothing with absolute fees IMO
1392015-11-26T08:12:41  *** Arnavion has joined #bitcoin-core-dev
1402015-11-26T08:12:42  <jonasschnelli> b) UI set absolute fees should never change the global fee level!
1412015-11-26T08:12:44  <wumpus> fees should be relative througout bitcoind
1422015-11-26T08:13:14  <gmaxwell> coincointrol should still work with relative fees, but it knows the transaction size and so it can show the actual amounts.
1432015-11-26T08:13:16  <jonasschnelli> right.. the PR 7096 does minimize the possibilities of absolute fees.
1442015-11-26T08:13:22  <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.
1452015-11-26T08:13:44  <wumpus> but I'd like to know: how are settxfee and smartfees *supposed* to interact?
1462015-11-26T08:13:58  <gmaxwell> well no harm no foul at least.
1472015-11-26T08:14:10  <gmaxwell> If we don't have any wallet users at all there will be no bugs. :)
1482015-11-26T08:14:14  <jonasschnelli> simply spoken: settxfee has nothing to do with the "bug".
1492015-11-26T08:14:27  <jonasschnelli> The problem lays deeper in "CWallet::GetMinimumFee"
1502015-11-26T08:14:50  <wumpus> gmaxwell: right, no one reported this, but it may explain some 'my transaction never goes through'
1512015-11-26T08:15:16  <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
1522015-11-26T08:15:57  <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.
1532015-11-26T08:16:07  <jonasschnelli> There is no way to change this unsless you use the UI
1542015-11-26T08:16:16  <jonasschnelli> fPayAtLeastCustomFee is always true
1552015-11-26T08:16: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.
1562015-11-26T08:16:35  *** AtashiCon has joined #bitcoin-core-dev
1572015-11-26T08:16:35  <gmaxwell> and when you do there is a temptation to just change the fixed values; which moots the value of the test.
1582015-11-26T08:17:08  <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 :)
1592015-11-26T08:17:18  <wumpus> oh the tests break? change the tests
1602015-11-26T08:17:25  <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.
1612015-11-26T08:17:53  <wumpus> jonasschnelli: ok. Let's just remove anything to do with absolute fee setting.
1622015-11-26T08:18:13  <jonasschnelli> wumpus: PR 7096 does that "almost".
1632015-11-26T08:18:35  <jonasschnelli> It enables the option to set an "absolute fee" IF coin join is enabled and inputs are selected.
1642015-11-26T08:18:39  <jonasschnelli> I think that's okay.
1652015-11-26T08:18:41  <wumpus> gmaxwell: I'm sure better tests are always welcome though, and you're welcome to encourage people to add  better tests  :)
1662015-11-26T08:18:53  <jonasschnelli> The "absolute fee" option is even hidden if coinjoin is disabled.
1672015-11-26T08:19:09  <jonasschnelli> s/coinjoin/coincontrol
1682015-11-26T08:19:25  *** isis has joined #bitcoin-core-dev
1692015-11-26T08:19:25  <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
1702015-11-26T08:19:31  <gmaxwell> cases.
1712015-11-26T08:19:54  <gmaxwell> jonasschnelli: if so I think the UI should just be translating that to relative fees
1722015-11-26T08:19:58  <wumpus> also we have lots of randomized algorithms, and randomized tests
1732015-11-26T08:20:07  <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
1742015-11-26T08:20:08  <wumpus> this doesn't make either easier
1752015-11-26T08:21:07  <wumpus> e.g. the tests here hardcode the hash function used even https://github.com/bitcoin/bitcoin/pull/7078
1762015-11-26T08:21:19  <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?
1772015-11-26T08:21:29  <wumpus> it's pseudo-randomized using the hash function, but exact results are tested
1782015-11-26T08:22:10  <gmaxwell> jonasschnelli: AFAIK nothing about the bitcoin system uses absolute fees, and it would be irrational for miners to do so.
1792015-11-26T08:22:14  *** Thireus has quit IRC
1802015-11-26T08:22:16  <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
1812015-11-26T08:22:16  <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.
1822015-11-26T08:22:17  <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).
1832015-11-26T08:22:41  <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.
1842015-11-26T08:23:14  <jonasschnelli> but we could also remove the absolute fee entirely...
1852015-11-26T08:23:22  *** pkthebud has quit IRC
1862015-11-26T08:23:22  *** pkthebud has joined #bitcoin-core-dev
1872015-11-26T08:23:25  *** fkhan has quit IRC
1882015-11-26T08:23:25  *** fkhan has joined #bitcoin-core-dev
1892015-11-26T08:23:31  <gmaxwell> raedah: You actually cannot tell your contribution to the fees, it's unknowable to the wallet.
1902015-11-26T08:23:31  <wumpus> jonasschnelli: I still think that's best - if you know the size of the transaction, you can achieve the same using relative fee
1912015-11-26T08:23:37  <jonasschnelli> maybe 0.12 remove absolute fee, 0.11 backport not.
1922015-11-26T08:24:02  <wumpus> jonasschnelli: (and the only case in which absolute fees are useful are *when* you know the size of the transaction anyway)
1932015-11-26T08:24:07  *** btcdrak has quit IRC
1942015-11-26T08:24:08  *** btcdrak has joined #bitcoin-core-dev
1952015-11-26T08:24:20  <jonasschnelli> wumpus: or if you don't trust the fee estimator?
1962015-11-26T08:24:32  <wumpus> jonasschnelli: you can still provide a fee per kB right?
1972015-11-26T08:24:33  <gmaxwell> I think removing a feature in a backport can be less of a sin than running different code in master and the backport.
1982015-11-26T08:24:41  <jonasschnelli> wumpus: right...
1992015-11-26T08:24:42  <wumpus> jonasschnelli: no fee estimator involved
2002015-11-26T08:24:45  <gmaxwell> Simply because the backport will not be as extensively tested.
2012015-11-26T08:24:53  <wumpus> 'fee estimator' has to be selected (that's smart fee)
2022015-11-26T08:25:13  <wumpus> well the requirement for backport are: small code impact, easy to test
2032015-11-26T08:25:34  <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)
2042015-11-26T08:26:11  <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
2052015-11-26T08:26:18  <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.
2062015-11-26T08:26:25  <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.
2072015-11-26T08:26:39  <wumpus> jonasschnelli: right...
2082015-11-26T08:27:04  <wumpus> jonasschnelli: doesn't seem like a large diff anyway, probably applies cleanly right now?
2092015-11-26T08:27:15  <gmaxwell> yea, we could do the smallest fix that fixes settxfee, then later remove the absolute in the gui.
2102015-11-26T08:28:03  <jonasschnelli> I think https://github.com/bitcoin/bitcoin/pull/7096/files is minimal if you hide the RPC tests.
2112015-11-26T08:28:41  <jonasschnelli> and a backport should be easy because we didn't changes that part since then i guesx
2122015-11-26T08:28:55  <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.
2132015-11-26T08:29:35  <wumpus> gmaxwell: yes - nodes that reconnect at all are suspect. They're either your own or a spy node :)
2142015-11-26T08:30:09  <wumpus> so if you whitelist your own nodes, that leaves spies
2152015-11-26T08:30:53  <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.
2162015-11-26T08:31:23  *** guest234234 has quit IRC
2172015-11-26T08:31:35  *** AtashiCon has quit IRC
2182015-11-26T08:31:39  *** Arnavion3 has joined #bitcoin-core-dev
2192015-11-26T08:31:43  *** Arnavion3 is now known as AtashiCon
2202015-11-26T08:32:00  <wumpus> gmaxwell: sure...
2212015-11-26T08:32:48  <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
2222015-11-26T08:32:50  <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.
2232015-11-26T08:33:15  <jonasschnelli> Somehow it looks strange if the sum of all you row in the transaction-table != your balance.
2242015-11-26T08:33:23  <jonasschnelli> that's why i had this idea in mind.
2252015-11-26T08:33:28  <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.
2262015-11-26T08:33:28  <wumpus> jonasschnelli: I certainly agree with visually distinguishing coinjoin transactions, and warning that the fee is not really the fee
2272015-11-26T08:33:44  <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.
2282015-11-26T08:33:51  *** Arnavion has quit IRC
2292015-11-26T08:33:58  *** Arnavion has joined #bitcoin-core-dev
2302015-11-26T08:34:09  <jonasschnelli> wumpus: is displaying the fee (which is not known at this point) even required?
2312015-11-26T08:34:09  <wumpus> jonasschnelli: but personally I'm not a huge fan of the idea of adding more rows for them
2322015-11-26T08:34:36  <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.
2332015-11-26T08:35:05  <wumpus> jonasschnelli: consider this: what if every transaction you do is coinjoin
2342015-11-26T08:35:19  <wumpus> jonasschnelli: (I somewhat hope that is going to be the future)
2352015-11-26T08:35:19  <jonasschnelli> Or we could try to combine them in one row and add an extra "coinjoin" info in the tx-detail window? overkill?
2362015-11-26T08:35:29  <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.
2372015-11-26T08:35:45  <wumpus> jonasschnelli: there shouldn't be too much overhead in that case
2382015-11-26T08:35:57  <gmaxwell> Really robust handling requires extra metadata: you need to know which of the payments are yours.
2392015-11-26T08:36:13  <wumpus> yes
2402015-11-26T08:36:33  <jonasschnelli> okay... so what would be the way to go? :)
2412015-11-26T08:36:39  <gmaxwell> We should probably change the 'wallet equation'  from   myinputs - fee = outputs   to  myinputs + otherinputs - fees = outputs.
2422015-11-26T08:36:47  <wumpus> but we don't have that metadata right now, so we have to handle this without it
2432015-11-26T08:37:02  <gmaxwell> And to ever transaction in list transactions add an extra_inputs: field, and get the fees right.
2442015-11-26T08:37:25  <gmaxwell> but this requires adding information about utxo not currently in the wallet.
2452015-11-26T08:37:52  *** morcos has quit IRC
2462015-11-26T08:37:55  <gmaxwell> That would be a "level 1" handling,  "level 2" would extend that by learning from JM, etc. which outputs were ours.
2472015-11-26T08:38:18  *** morcos has joined #bitcoin-core-dev
2482015-11-26T08:38:18  <gmaxwell> and the others could be hidden like change is now.
2492015-11-26T08:40:11  <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.
2502015-11-26T08:41:05  <wumpus> right, the wallet needs additional information about inputs
2512015-11-26T08:41:46  <wumpus> so that even if the originating transactions are no longer known, it still knows the sizes involved
2522015-11-26T08:42:01  <raedah> gmaxwell, im not clear here. We do know what our input and outputs in the transaction are.
2532015-11-26T08:43:03  <wumpus> raedah: we don't know what our outputs are, I think?
2542015-11-26T08:43:27  <raedah> all inputs and outputs are loaded as watchaddresses
2552015-11-26T08:43:28  <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
2562015-11-26T08:43:37  <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'.
2572015-11-26T08:44:04  <gmaxwell> raedah: well thats busted.
2582015-11-26T08:44:27  <wumpus> where? why would you load outputs as watchaddress?
2592015-11-26T08:44:35  <gmaxwell> loading them all as watch addresses still doesn't tell you which are yours, it just make it look like they all are. :)
2602015-11-26T08:45:27  <raedah> not all the addresses in the transaction are watch addresses. Just the ones in your joinmarket wallet become watch addresses.
2612015-11-26T08:45:32  <wumpus> and loading the inputs as watch-only doesn't make sense either, they're still not your inputs or your balance
2622015-11-26T08:46:25  <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.
2632015-11-26T08:46:48  <gmaxwell> a JM maker is all paying themselves, true, but not a JM taker.
2642015-11-26T08:47:31  <wumpus> I'm not sure how watch-only helps here at all
2652015-11-26T08:48:01  <gmaxwell> wumpus: JM's 'market makers' have their own external wallet managed by JM, effectively.
2662015-11-26T08:48:23  <wumpus> ok - if there is an external wallet owned by you adding *those* as watchonly makes sense
2672015-11-26T08:49:17  <wumpus> because it's your balance. But adding other people's inputs/outputs would not be a good idea.
2682015-11-26T08:49:33  <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.
2692015-11-26T08:49:54  <raedah> wumpus, and joinmarket requires it to pull the data it needs on those addressses from the rpc.
2702015-11-26T08:49:59  <gmaxwell> The makers just deposit some coins into JM and it produces income (though not much because there is lots of competition!)
2712015-11-26T08:50:39  <wumpus> gmaxwell: makes sense
2722015-11-26T08:50:45  <gmaxwell> raedah: do you know specifically what it needs?
2732015-11-26T08:51:10  <gmaxwell> If it need to look up txouts, that can be done without wallet importing; we have an rpc for that.
2742015-11-26T08:51:47  <raedah> i think its looking for address balances, and maybe tx confirmations.
2752015-11-26T08:52:11  * gmaxwell ducks into #joinmarket
2762015-11-26T08:52:26  <wumpus> both can be determinied using just the utxo set
2772015-11-26T08:53:15  <wumpus> (as anything actively spendable, is, by definition, in there)
2782015-11-26T08:53:32  <wumpus> no need for any scan over transaction history
2792015-11-26T08:54:46  * wumpus tries to remember how the RPC call to query utxos was called...
2802015-11-26T08:54:46  <gmaxwell> They may not know about gettxout or gettxoutproof.
2812015-11-26T08:54:56  <wumpus> heh :-)
2822015-11-26T08:55:58  *** paveljanik has joined #bitcoin-core-dev
2832015-11-26T08:55:58  *** paveljanik has joined #bitcoin-core-dev
2842015-11-26T08:56:02  <gmaxwell> earlier on it used some third party API; which probably didn't provide an interface intended for scalablity. :)
2852015-11-26T08:56:10  <wumpus> https://bitcoin.org/en/developer-reference#gettxout
2862015-11-26T08:56:48  <wumpus> (gettxoutproof is also documented in the same place)
2872015-11-26T09:01:24  *** jgarzik has joined #bitcoin-core-dev
2882015-11-26T09:02:39  *** jgarzik__ has quit IRC
2892015-11-26T09:03:26  <wumpus> does that give enough functionality or do you really need to query the utxo set by address/output script?
2902015-11-26T09:04:51  <gmaxwell> It shouldn't!, but I'm asking.
2912015-11-26T09:05:33  <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.
2922015-11-26T09:05:48  <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)
2932015-11-26T09:05:49  <gmaxwell> (if so, then that can be fixed.. as the protocol is far from set in stone)
2942015-11-26T09:06:37  <wumpus> right
2952015-11-26T09:07:33  *** raedah has quit IRC
2962015-11-26T09:07:52  <gmaxwell> https://github.com/chris-belcher/joinmarket/blob/master/lib/blockchaininterface.py
2972015-11-26T09:08:13  <gmaxwell> yea, looks like it's trying to emulate the blockr interface instead of doing things sanely.
2982015-11-26T09:11:38  *** ParadoxSpiral has quit IRC
2992015-11-26T09:15:11  *** BashCo_ has quit IRC
3002015-11-26T09:16:31  *** JackH has joined #bitcoin-core-dev
3012015-11-26T09:27:44  *** phantomcircuit_ is now known as phantomcircuit
3022015-11-26T09:30:48  *** Madars has joined #bitcoin-core-dev
3032015-11-26T09:32:35  *** morcos has quit IRC
3042015-11-26T09:32:36  *** jcorgan_ has quit IRC
3052015-11-26T09:33:11  *** JackH has quit IRC
3062015-11-26T09:33:48  *** pmienk_ has quit IRC
3072015-11-26T09:33:48  *** go1111111 has quit IRC
3082015-11-26T09:33:48  *** nanotube has quit IRC
3092015-11-26T09:33:56  *** BashCo has joined #bitcoin-core-dev
3102015-11-26T09:34:08  <aj_> gmaxwell: mind checking https://gist.github.com/ajtowns/3fd596af4f81042ef6ac before i post to lightning-dev (summarising the reveal-P script)?
3112015-11-26T09:35:06  <gmaxwell> No dup
3122015-11-26T09:35:12  <gmaxwell> size does not consume its input.
3132015-11-26T09:35:17  <aj_> right
3142015-11-26T09:38:18  <gmaxwell> 57 is ~ 15 zeros.   Your ECC mult numbers are comically slow.
3152015-11-26T09:38:34  *** Thireus has joined #bitcoin-core-dev
3162015-11-26T09:39:46  <gmaxwell> https://www.blockstream.com/half-a-puzzle/  notice the ground nonces here.
3172015-11-26T09:40:26  <gmaxwell> 02000000000005689111130e588a12ecda87b2dc5585c6c6ba ffffffff077b7209dc866fbfa0d2bf67a0c696afffe57a822e deadbeef2f4a23b0f1954100b76bcb720f7b2ddc4a446dc06b
3182015-11-26T09:40:50  <aj_> yeah, that's 5 bytes of zeroes
3192015-11-26T09:41:01  <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)
3202015-11-26T09:41:16  <sipa_> i suppose the above few lines contain several hints?
3212015-11-26T09:41:21  *** sipa_ is now known as sipa
3222015-11-26T09:41:31  *** morcos has joined #bitcoin-core-dev
3232015-11-26T09:41:48  <aj_> sipa: yeah, gmaxwell stated the script already
3242015-11-26T09:41:59  <aj_> sipa: in -wizards anyway; oops, i guess this is the wrong channel
3252015-11-26T09:42:04  <gmaxwell> oops
3262015-11-26T09:42:45  *** jcorgan has joined #bitcoin-core-dev
3272015-11-26T09:42:45  *** jcorgan has joined #bitcoin-core-dev
3282015-11-26T09:43:52  *** nanotube has joined #bitcoin-core-dev
3292015-11-26T09:44:58  *** go1111111 has joined #bitcoin-core-dev
3302015-11-26T09:45:58  *** JackH has joined #bitcoin-core-dev
3312015-11-26T09:47:33  *** pmienk_ has joined #bitcoin-core-dev
3322015-11-26T09:48:32  *** aj_ is now known as aj
3332015-11-26T09:57:39  *** Thireus has quit IRC
3342015-11-26T09:59:43  *** Thireus has joined #bitcoin-core-dev
3352015-11-26T10:18:55  <GitHub56> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/be281d8a83ca...f8a8e27a6a19
3362015-11-26T10:18:56  <GitHub56> bitcoin/master fa472f3 MarcoFalke: [trivial] Fix -maxmempool InitError
3372015-11-26T10:18:56  <GitHub56> bitcoin/master f8a8e27 Wladimir J. van der Laan: Merge pull request #7069...
3382015-11-26T10:19:01  <GitHub188> [bitcoin] laanwj closed pull request #7069: [trivial] Fix -maxmempool InitError (master...MarcoFalke-2015-maxmempoolInitError) https://github.com/bitcoin/bitcoin/pull/7069
3392015-11-26T10:35:22  <jonasschnelli> When is code freeze for 0.12?
3402015-11-26T10:35:36  <jonasschnelli> (or feature freeze)
3412015-11-26T10:36:05  <jonasschnelli> Found it. 01.12.15
3422015-11-26T10:36:35  <gmaxwell> I was expecting the end of the monthish. Don't tell me I've got more weeks! :P
3432015-11-26T10:37:13  <btcdrak> haha, that's British notation gmaxwell ;)
3442015-11-26T10:37:23  <btcdrak> the right way!
3452015-11-26T10:37:54  <sipa> what's so british about it? :)
3462015-11-26T10:38:04  <gmaxwell> it's bass-ackwards?
3472015-11-26T10:38:12  <btcdrak> :D
3482015-11-26T10:38:13  <gmaxwell> ISO forever. 2015-12-01
3492015-11-26T10:38:20  <sipa> the only right date format is of course 2015-12-01, which is lexicographically sortable
3502015-11-26T10:38:20  <btcdrak> ^ Chinese
3512015-11-26T10:38:42  <jonasschnelli> d-m-y ... that's how the brain things. (at least mine. :P )
3522015-11-26T10:38:45  <wumpus> agree with sipa
3532015-11-26T10:38:48  <jonasschnelli> *thinks
3542015-11-26T10:38:54  <gmaxwell> okay, that was my expectation. whew.
3552015-11-26T10:39:32  <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
3562015-11-26T10:40:15  <wumpus> at least write out the month name if you'er doing that :)
3572015-11-26T10:40:34  <gmaxwell> or only work with days after the 12th.
3582015-11-26T10:42:29  <sipa> oh, it's 12/01/2015 in the us
3592015-11-26T10:42:39  <sipa> i just remember it's middle endian
3602015-11-26T10:44:01  <paveljanik> I like the term "middle endian" ;-)
3612015-11-26T10:44:26  <gmaxwell> it's a thing
3622015-11-26T10:44:32  <paveljanik> one friend is using "just enough endian"
3632015-11-26T10:45:03  <wumpus> it's a good example of where a compromise is the worst outcome possible :)
3642015-11-26T10:46:01  <gmaxwell> sipa: lets just use MJD ... 57356 is less typing than all that stuff.
3652015-11-26T10:47:24  <paveljanik> or XI.XXVI.MMXV
3662015-11-26T10:47:33  <wumpus> baa if we're going that way I'd prefer to just use megaseconds
3672015-11-26T10:47:34  * gmaxwell waits for luke-jr to tell us the tonal date
3682015-11-26T10:47:52  <sipa> gmaxwell: that's may 6th 735?
3692015-11-26T10:48:05  <wumpus> since the epoch of course
3702015-11-26T10:48:14  *** Thireus has quit IRC
3712015-11-26T10:48:28  <sipa> wumpus: megaseconds are not very accurate
3722015-11-26T10:48:32  <paveljanik> you mean from the genesis block?
3732015-11-26T10:48:51  <sipa> wumpus: how about deciforthnights?
3742015-11-26T10:48:55  <wumpus> sipa: right, well, just use fractions
3752015-11-26T10:48:56  <gmaxwell> sipa: no, 2015-12-01; there
3762015-11-26T10:49:10  <wumpus> (precision as necessary)
3772015-11-26T10:49:22  <sipa> gmaxwell: oh, i misread as MYD, and though you were just concatenating M Y and D
3782015-11-26T10:49:34  <sipa> gmaxwell: it's Msomething julian date?
3792015-11-26T10:49:45  <gmaxwell> Yes, http://tycho.usno.navy.mil/mjd.html
3802015-11-26T10:53:20  *** Thireus has joined #bitcoin-core-dev
3812015-11-26T11:05:06  *** guest234234 has joined #bitcoin-core-dev
3822015-11-26T11:07:23  *** d_t_ has quit IRC
3832015-11-26T11:23:15  *** randy-waterhouse has quit IRC
3842015-11-26T11:46:39  *** andytoshi has quit IRC
3852015-11-26T11:54:41  *** jtimon has joined #bitcoin-core-dev
3862015-11-26T12:07:03  <jonasschnelli> jgarzik: Did you had time to review https://github.com/jgarzik/univalue/pull/14 ?
3872015-11-26T12:13:55  <gmaxwell> When andytoshi's back online he should be pinged to differentially test against that.
3882015-11-26T12:14:27  <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.
3892015-11-26T12:27:04  <wumpus> doesn't rust already have libraries for json parsing/generation? or was that mostly an educational exercise?
3902015-11-26T12:33:39  *** MarcoFalke has joined #bitcoin-core-dev
3912015-11-26T12:45:43  <jonasschnelli> wumpus: do you think fixing the settxfee bug with a tiny risk of RPC/UI interfering is okay? IMO its okay.
3922015-11-26T12:45:56  <jonasschnelli> I don't expect people using RPC and UI at the same time.
3932015-11-26T12:46:03  <jonasschnelli> Maybe we should warn in the release notes at least.
3942015-11-26T12:46:57  *** paveljanik has quit IRC
3952015-11-26T12:47:03  <wumpus> jonasschnelli: well, we should try to rule out that risk as much as possible
3962015-11-26T12:48:07  <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
3972015-11-26T12:48:11  *** andytoshi has joined #bitcoin-core-dev
3982015-11-26T12:48:42  <wumpus> but 'using RPC with the UI randomly crashes or sends random amounts to random people' would not be :)
3992015-11-26T12:48:57  <jonasschnelli> Right... I don't expect people to blame us of not fixing the UI/RPC interfering bug over backports.
4002015-11-26T12:49:00  <MarcoFalke> About fees and release notes: I think a general write up about how fees work now should be planned
4012015-11-26T12:49:27  <wumpus> MarcoFalke: yes that would be welcome
4022015-11-26T12:49:54  <jonasschnelli> I think we do need to backport the rpc test as well? We don't want to have broken tests in 0.11?
4032015-11-26T12:50:07  <wumpus> although it's still kind of in flux, e.g. the final shape of mempool limiting isn't entirely clear yet
4042015-11-26T12:50:09  * jonasschnelli is working on the most simplest backport
4052015-11-26T12:50:16  <wumpus> jonasschnelli: yes, definitely
4062015-11-26T12:50:47  <wumpus> jonasschnelli: tests are the most important part, they prove that it's fixed :)
4072015-11-26T12:50:54  <jonasschnelli> ha. right!
4082015-11-26T12:52:08  <GitHub194> [bitcoin] MarcoFalke opened pull request #7103: [wallet, rpc tests] Fix settxfee, paytxfee (master...FixSettxfee) https://github.com/bitcoin/bitcoin/pull/7103
4092015-11-26T12:52:14  <MarcoFalke> Will do the backport soon
4102015-11-26T12:52:51  <wumpus> are you and jonasschnelli working together or duplicating work?
4112015-11-26T12:53:11  <MarcoFalke> jonas is doing the gui work
4122015-11-26T12:53:17  <MarcoFalke> I did the rpc tests
4132015-11-26T12:53:30  <MarcoFalke> we split up in two PRs
4142015-11-26T12:53:34  <wumpus> ok, great!
4152015-11-26T12:57:07  <jonasschnelli> Yeah. Fine for me. I appreciate every help.
4162015-11-26T12:58:42  <jonasschnelli> MarcoFalke: I agree with wumpus. I think to reduce the diff (mind backport) we should keep the 8 digits for Decimal('-0.00010000'))
4172015-11-26T12:59:07  <MarcoFalke> >>> Decimal("0.100") == Decimal(".1")
4182015-11-26T12:59:07  <MarcoFalke> True
4192015-11-26T12:59:14  <MarcoFalke> I will get rid of those,
4202015-11-26T12:59:19  <wumpus> I don't really have an opinion on the precision, but I didn't understand the change :)
4212015-11-26T13:01:05  <wumpus> changing one line in the code is a nicely minimal change though
4222015-11-26T13:01:54  <jonasschnelli> a true/false flip is probably the smallest change we can offer. :)
4232015-11-26T13:02:45  <wumpus> yes a one bitflip
4242015-11-26T13:07:50  <MarcoFalke> Whos responsible for travis?
4252015-11-26T13:07:56  <MarcoFalke> Need someone to ping :)
4262015-11-26T13:08:01  <sipa> MarcoFalke: what's the problem?
4272015-11-26T13:08:19  <MarcoFalke> Two workers are stuck since several days, I think
4282015-11-26T13:08:30  <jonasschnelli> i think it just requires some minutes until it starts
4292015-11-26T13:09:24  <wumpus> I can restart tasks and clear the caches,but I don't think I have direct control over the workers
4302015-11-26T13:09:28  <jonasschnelli> I think MarcoFalke is right: https://travis-ci.org/bitcoin/bitcoin/builds/92025728
4312015-11-26T13:09:34  <MarcoFalke> https://travis-ci.org/bitcoin/bitcoin/builds/92213684
4322015-11-26T13:10:41  <sipa> cancelled
4332015-11-26T13:11:31  <MarcoFalke> nice, 4/5
4342015-11-26T13:11:37  <MarcoFalke> Can you cancel https://travis-ci.org/bitcoin/bitcoin/builds/92213684 as well
4352015-11-26T13:12:14  <sipa> done
4362015-11-26T13:12:23  <sipa> restarted
4372015-11-26T13:12:35  <MarcoFalke> all running 5/5
4382015-11-26T13:15:47  *** BashCo_ has joined #bitcoin-core-dev
4392015-11-26T13:16:06  *** BashCo has quit IRC
4402015-11-26T14:03:37  *** wangchun has joined #bitcoin-core-dev
4412015-11-26T14:20:27  *** guest234234 has quit IRC
4422015-11-26T14:29:45  <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?
4432015-11-26T14:29:52  <jonasschnelli> would something speak against using the signal?
4442015-11-26T14:30:05  <jonasschnelli> the timer is still required for the bandwith graph...
4452015-11-26T14:30:15  <sipa> jonasschnelli: the signal may fire way too frequently sometimes, afaik
4462015-11-26T14:30:42  <sipa> up to the point that updating the GUI was slowing down synchronization
4472015-11-26T14:30:46  <jonasschnelli> the timer with the trylock fires every 250ms!
4482015-11-26T14:31:04  <sipa> during IBD the signal may fire every ms :)
4492015-11-26T14:31:58  <jonasschnelli> okay... the UI could measure the time delta (inexpansive uint64_t compare) and update the ui every 5 sec or so.
4502015-11-26T14:32:19  <jonasschnelli> it just looks like that the TRY_LOCK often can acquire the lock
4512015-11-26T14:32:23  <jonasschnelli> can't
4522015-11-26T14:34:33  <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?!
4532015-11-26T14:41:37  <sipa> jonasschnelli: that's correct, but signals still run synchronously
4542015-11-26T14:42:10  <jonasschnelli> sipa: right,.. but at least the could emit/pass a QT async signal to the GUI thread
4552015-11-26T14:42:12  <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
4562015-11-26T14:42:29  <sipa> jonasschnelli: i don't think you want to emit 1000 signals per second still :)
4572015-11-26T14:43:09  <jonasschnelli> sipa: hmm... let me benchmark it,.. maybe a min-time-delta is required to avoid over-updating the ui.
4582015-11-26T14:43:49  <jonasschnelli> and the signal only fires !fInitialDownload
4592015-11-26T14:44:26  <sipa> ah
4602015-11-26T15:05:15  *** Guyver2 has joined #bitcoin-core-dev
4612015-11-26T15:24:17  <jgarzik> RE univalue - I see one outstanding issue to address that wumpus ping'd on - everything else is fixed in upstream univalue tree.
4622015-11-26T15:27:01  *** arowser has quit IRC
4632015-11-26T15:27:25  *** arowser has joined #bitcoin-core-dev
4642015-11-26T15:34:58  <jonasschnelli> sipa: is "Tip Notification: 0.03ms" reasonable (standard core i7 laptop)? Currently I update the UI also during fInitialSync.... looks nice!
4652015-11-26T15:35:13  *** ParadoxSpiral has joined #bitcoin-core-dev
4662015-11-26T15:36:02  <sipa> that seems ok...
4672015-11-26T15:37:11  <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
4682015-11-26T16:00:37  *** BashCo_ has quit IRC
4692015-11-26T16:03:03  <sipa> jonasschnelli: going to try to implement another approach for 7067
4702015-11-26T16:03:25  <jonasschnelli> sipa: that was actually my intention... :)
4712015-11-26T16:13:16  <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
4722015-11-26T16:33:42  *** tripleslash_a has joined #bitcoin-core-dev
4732015-11-26T16:35:34  *** evoskuil has quit IRC
4742015-11-26T16:35:37  *** evoskuil has joined #bitcoin-core-dev
4752015-11-26T16:35:37  *** andytoshi has quit IRC
4762015-11-26T16:35:37  *** tripleslash has quit IRC
4772015-11-26T16:36:11  *** andytoshi has joined #bitcoin-core-dev
4782015-11-26T16:40:03  *** jl2012_ has joined #bitcoin-core-dev
4792015-11-26T16:40:31  *** jl2012 has quit IRC
4802015-11-26T17:15:00  *** Thireus has quit IRC
4812015-11-26T17:45:54  *** ParadoxSpiral_ has joined #bitcoin-core-dev
4822015-11-26T17:48:30  *** ParadoxSpiral has quit IRC
4832015-11-26T17:58:56  *** cocoBTC has joined #bitcoin-core-dev
4842015-11-26T17:59:31  *** d_t has joined #bitcoin-core-dev
4852015-11-26T18:20:12  *** raedah has joined #bitcoin-core-dev
4862015-11-26T18:24:11  *** JackH has quit IRC
4872015-11-26T18:28:15  *** paveljanik has joined #bitcoin-core-dev
4882015-11-26T18:40:23  *** Thireus has joined #bitcoin-core-dev
4892015-11-26T18:57:09  *** lecusemb1e has joined #bitcoin-core-dev
4902015-11-26T18:57:13  *** harding_ has joined #bitcoin-core-dev
4912015-11-26T18:58:31  *** AtashiCon has quit IRC
4922015-11-26T18:58:35  *** Arnavion3 has joined #bitcoin-core-dev
4932015-11-26T18:58:39  *** Arnavion3 is now known as AtashiCon
4942015-11-26T18:59:32  *** d_t_ has joined #bitcoin-core-dev
4952015-11-26T18:59:38  *** btcdrak_ has joined #bitcoin-core-dev
4962015-11-26T19:01:42  *** d_t has quit IRC
4972015-11-26T19:01:42  *** tripleslash_a has quit IRC
4982015-11-26T19:01:43  *** morcos has quit IRC
4992015-11-26T19:01:43  *** jgarzik has quit IRC
5002015-11-26T19:01:43  *** Guest1234 has quit IRC
5012015-11-26T19:01:43  *** btcdrak has quit IRC
5022015-11-26T19:01:43  *** warren has quit IRC
5032015-11-26T19:01:43  *** Anduck has quit IRC
5042015-11-26T19:01:44  *** Eliel has quit IRC
5052015-11-26T19:01:44  *** sdaftuar has quit IRC
5062015-11-26T19:01:44  *** lecusemble has quit IRC
5072015-11-26T19:01:44  *** gavinandresen has quit IRC
5082015-11-26T19:01:45  *** lclc has quit IRC
5092015-11-26T19:01:45  *** [b__b] has quit IRC
5102015-11-26T19:01:45  *** harding has quit IRC
5112015-11-26T19:01:45  *** instagibbs has quit IRC
5122015-11-26T19:01:45  *** BlueMatt_ has quit IRC
5132015-11-26T19:01:46  *** ParadoxSpiral_ has quit IRC
5142015-11-26T19:01:46  *** andytoshi has quit IRC
5152015-11-26T19:01:46  *** berndj has quit IRC
5162015-11-26T19:01:46  *** neha has quit IRC
5172015-11-26T19:01:47  *** mm_1 has quit IRC
5182015-11-26T19:01:47  *** aj has quit IRC
5192015-11-26T19:01:47  *** bsm1175322 has quit IRC
5202015-11-26T19:01:47  *** amiller_ has quit IRC
5212015-11-26T19:01:48  *** ghtdak has quit IRC
5222015-11-26T19:01:48  *** asoltys has quit IRC
5232015-11-26T19:01:49  *** go1111111 has quit IRC
5242015-11-26T19:01:49  *** jcorgan has quit IRC
5252015-11-26T19:01:49  *** michagogo has quit IRC
5262015-11-26T19:01:50  *** pkthebud has quit IRC
5272015-11-26T19:01:50  *** petertodd has quit IRC
5282015-11-26T19:01:50  *** wumpus has quit IRC
5292015-11-26T19:01:50  *** sipa has quit IRC
5302015-11-26T19:01:50  *** phantomcircuit has quit IRC
5312015-11-26T19:01:50  *** Ylbam has quit IRC
5322015-11-26T19:01:50  *** midnightmagic has quit IRC
5332015-11-26T19:01:50  *** blkdb has quit IRC
5342015-11-26T19:01:51  *** zmanian_ has quit IRC
5352015-11-26T19:01:51  *** s1w has quit IRC
5362015-11-26T19:01:52  *** raedah has quit IRC
5372015-11-26T19:01:52  *** paveljanik has quit IRC
5382015-11-26T19:01:52  *** Guyver2 has quit IRC
5392015-11-26T19:01:52  *** wangchun has quit IRC
5402015-11-26T19:01:53  *** Arnavion has quit IRC
5412015-11-26T19:01:53  *** isis has quit IRC
5422015-11-26T19:01:53  *** PaulCapestany has quit IRC
5432015-11-26T19:01:53  *** da2ce7_ has quit IRC
5442015-11-26T19:01:53  *** kanzure has quit IRC
5452015-11-26T19:01:53  *** gmaxwell has quit IRC
5462015-11-26T19:01:53  *** Amnez777 has quit IRC
5472015-11-26T19:01:53  *** arubi has quit IRC
5482015-11-26T19:01:54  *** gribble has quit IRC
5492015-11-26T19:01:54  *** alpalp has quit IRC
5502015-11-26T19:01:54  *** BananaLotus has quit IRC
5512015-11-26T19:02:37  *** BlueMatt_ has joined #bitcoin-core-dev
5522015-11-26T19:02:59  *** btcdrak_ is now known as btcdrak
5532015-11-26T19:03:21  *** sdaftuar has joined #bitcoin-core-dev
5542015-11-26T19:03:23  *** raedah has joined #bitcoin-core-dev
5552015-11-26T19:03:34  *** Anduck has joined #bitcoin-core-dev
5562015-11-26T19:03:45  *** morcos has joined #bitcoin-core-dev
5572015-11-26T19:04:05  *** Anduck is now known as Guest22577
5582015-11-26T19:05:21  *** btcdrak has quit IRC
5592015-11-26T19:05:28  *** lclc has joined #bitcoin-core-dev
5602015-11-26T19:08:06  *** gavinand1esen has joined #bitcoin-core-dev
5612015-11-26T19:08:06  *** JackH has joined #bitcoin-core-dev
5622015-11-26T19:08:06  *** jgarzik_ has joined #bitcoin-core-dev
5632015-11-26T19:08:06  *** ParadoxSpiral_ has joined #bitcoin-core-dev
5642015-11-26T19:08:06  *** andytoshi has joined #bitcoin-core-dev
5652015-11-26T19:08:06  *** berndj has joined #bitcoin-core-dev
5662015-11-26T19:08:06  *** neha has joined #bitcoin-core-dev
5672015-11-26T19:08:06  *** mm_1 has joined #bitcoin-core-dev
5682015-11-26T19:08:06  *** aj has joined #bitcoin-core-dev
5692015-11-26T19:08:06  *** bsm1175322 has joined #bitcoin-core-dev
5702015-11-26T19:08:06  *** asoltys has joined #bitcoin-core-dev
5712015-11-26T19:08:06  *** amiller_ has joined #bitcoin-core-dev
5722015-11-26T19:08:06  *** ghtdak has joined #bitcoin-core-dev
5732015-11-26T19:08:44  *** [b__b] has joined #bitcoin-core-dev
5742015-11-26T19:09:13  *** Arnavion has joined #bitcoin-core-dev
5752015-11-26T19:09:58  *** instagibbs has joined #bitcoin-core-dev
5762015-11-26T19:10:15  *** btcdrak has joined #bitcoin-core-dev
5772015-11-26T19:11:09  *** Guest1235 has joined #bitcoin-core-dev
5782015-11-26T19:11:09  *** warren has joined #bitcoin-core-dev
5792015-11-26T19:11:09  *** paveljanik has joined #bitcoin-core-dev
5802015-11-26T19:11:09  *** Guyver2 has joined #bitcoin-core-dev
5812015-11-26T19:11:09  *** wangchun has joined #bitcoin-core-dev
5822015-11-26T19:11:09  *** isis has joined #bitcoin-core-dev
5832015-11-26T19:11:09  *** PaulCapestany has joined #bitcoin-core-dev
5842015-11-26T19:11:09  *** da2ce7_ has joined #bitcoin-core-dev
5852015-11-26T19:11:09  *** kanzure has joined #bitcoin-core-dev
5862015-11-26T19:11:09  *** gmaxwell has joined #bitcoin-core-dev
5872015-11-26T19:11:09  *** arubi has joined #bitcoin-core-dev
5882015-11-26T19:11:09  *** alpalp has joined #bitcoin-core-dev
5892015-11-26T19:11:09  *** BananaLotus has joined #bitcoin-core-dev
5902015-11-26T19:11:32  *** tripleslash has joined #bitcoin-core-dev
5912015-11-26T19:13:08  *** Amnez777 has joined #bitcoin-core-dev
5922015-11-26T19:13:18  *** warren is now known as Guest26532
5932015-11-26T19:14:50  *** go1111111 has joined #bitcoin-core-dev
5942015-11-26T19:14:51  *** jcorgan has joined #bitcoin-core-dev
5952015-11-26T19:14:51  *** michagogo has joined #bitcoin-core-dev
5962015-11-26T19:14:51  *** pkthebud has joined #bitcoin-core-dev
5972015-11-26T19:14:51  *** petertodd has joined #bitcoin-core-dev
5982015-11-26T19:14:51  *** phantomcircuit has joined #bitcoin-core-dev
5992015-11-26T19:14:51  *** sipa has joined #bitcoin-core-dev
6002015-11-26T19:14:51  *** wumpus has joined #bitcoin-core-dev
6012015-11-26T19:14:51  *** Ylbam has joined #bitcoin-core-dev
6022015-11-26T19:14:51  *** midnightmagic has joined #bitcoin-core-dev
6032015-11-26T19:14:51  *** blkdb has joined #bitcoin-core-dev
6042015-11-26T19:14:51  *** zmanian_ has joined #bitcoin-core-dev
6052015-11-26T19:14:51  *** s1w has joined #bitcoin-core-dev
6062015-11-26T19:15:16  *** Amnez777 has quit IRC
6072015-11-26T19:15:16  *** Amnez777 has joined #bitcoin-core-dev
6082015-11-26T19:15:17  *** gribble has joined #bitcoin-core-dev
6092015-11-26T19:16:20  *** dermoth has joined #bitcoin-core-dev
6102015-11-26T19:20:15  *** morcos_ has joined #bitcoin-core-dev
6112015-11-26T19:20:48  *** d_t has joined #bitcoin-core-dev
6122015-11-26T19:26:52  *** Arnavion has quit IRC
6132015-11-26T19:26:54  *** d_t_ has quit IRC
6142015-11-26T19:26:54  *** AtashiCon has quit IRC
6152015-11-26T19:26:54  *** evoskuil has quit IRC
6162015-11-26T19:26:54  *** evoskuil has joined #bitcoin-core-dev
6172015-11-26T19:27:25  *** morcos has quit IRC
6182015-11-26T19:27:25  *** raedah has quit IRC
6192015-11-26T19:27:25  *** lecusemb1e has quit IRC
6202015-11-26T19:27:25  *** Thireus has quit IRC
6212015-11-26T19:27:40  *** Arnavion has joined #bitcoin-core-dev
6222015-11-26T19:27:40  *** lecusemble has joined #bitcoin-core-dev
6232015-11-26T19:28:26  *** Eliel has joined #bitcoin-core-dev
6242015-11-26T19:29:36  *** harding_ has quit IRC
6252015-11-26T19:29:36  *** MarcoFalke has quit IRC
6262015-11-26T19:30:12  *** cocoBTC has quit IRC
6272015-11-26T19:30:12  *** dermoth has quit IRC
6282015-11-26T19:30:13  *** arowser has quit IRC
6292015-11-26T19:30:30  *** tripleslash_b has joined #bitcoin-core-dev
6302015-11-26T19:30:31  *** raedah has joined #bitcoin-core-dev
6312015-11-26T19:33:47  *** [1]evoskuil has joined #bitcoin-core-dev
6322015-11-26T19:34:45  *** lclc_ has joined #bitcoin-core-dev
6332015-11-26T19:35:06  *** evoskuil has quit IRC
6342015-11-26T19:35:06  *** [1]evoskuil is now known as evoskuil
6352015-11-26T19:36:20  *** lecusemble has quit IRC
6362015-11-26T19:38:13  *** sdaftuar_ has joined #bitcoin-core-dev
6372015-11-26T19:39:01  *** tripleslash has quit IRC
6382015-11-26T19:39:01  *** [b__b] has quit IRC
6392015-11-26T19:39:01  *** lclc has quit IRC
6402015-11-26T19:39:01  *** sdaftuar has quit IRC
6412015-11-26T19:39:02  *** teward has quit IRC
6422015-11-26T19:39:02  *** cfields_ has quit IRC
6432015-11-26T19:39:02  *** bsm1175321 has quit IRC
6442015-11-26T19:39:16  *** cfields has joined #bitcoin-core-dev
6452015-11-26T19:42:37  *** teward has joined #bitcoin-core-dev
6462015-11-26T19:43:23  *** JackH has quit IRC
6472015-11-26T19:44:05  *** cocoBTC has joined #bitcoin-core-dev
6482015-11-26T19:47:08  *** harding has joined #bitcoin-core-dev
6492015-11-26T19:49:20  *** lecusemble has joined #bitcoin-core-dev
6502015-11-26T19:50:33  *** dermoth has joined #bitcoin-core-dev
6512015-11-26T19:50:38  *** tripleslash has joined #bitcoin-core-dev
6522015-11-26T19:51:52  *** davec has quit IRC
6532015-11-26T19:52:41  *** tripleslash_b has quit IRC
6542015-11-26T19:52:41  *** cfields has quit IRC
6552015-11-26T19:52:41  *** evoskuil has quit IRC
6562015-11-26T19:52:45  *** evoskuil has joined #bitcoin-core-dev
6572015-11-26T19:55:27  *** cfields has joined #bitcoin-core-dev
6582015-11-26T19:56:42  *** bsm117532 has joined #bitcoin-core-dev
6592015-11-26T19:57:52  *** BlueMatt_ has quit IRC
6602015-11-26T20:02:17  *** BlueMatt has joined #bitcoin-core-dev
6612015-11-26T20:04:49  *** davec has joined #bitcoin-core-dev
6622015-11-26T20:12:16  *** jonasschnelli has quit IRC
6632015-11-26T20:13:51  *** jonasschnelli has joined #bitcoin-core-dev
6642015-11-26T20:36:53  *** raedah has quit IRC
6652015-11-26T20:49:28  <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
6662015-11-26T20:53:09  *** instagibbs_ has joined #bitcoin-core-dev
6672015-11-26T20:57:15  *** dermoth has quit IRC
6682015-11-26T20:57:15  *** instagibbs has quit IRC
6692015-11-26T20:59:53  *** dermoth has joined #bitcoin-core-dev
6702015-11-26T21:00:18  *** Thireus has joined #bitcoin-core-dev
6712015-11-26T21:11:09  <GitHub77> [bitcoin] sipa opened pull request #7106: Fix and improve relay from whitelisted peers (master...realwhiterelay) https://github.com/bitcoin/bitcoin/pull/7106
6722015-11-26T21:36:17  *** randy-waterhouse has joined #bitcoin-core-dev
6732015-11-26T21:38:23  *** d_t has quit IRC
6742015-11-26T21:41:47  *** go1111111 has quit IRC
6752015-11-26T21:50:16  *** ParadoxSpiral_ has quit IRC
6762015-11-26T22:08:34  *** BashCo has joined #bitcoin-core-dev
6772015-11-26T22:09:10  *** go1111111 has joined #bitcoin-core-dev
6782015-11-26T22:11:48  *** JackH has joined #bitcoin-core-dev
6792015-11-26T22:13:46  *** go1111111 has quit IRC
6802015-11-26T22:19:00  <cocoBTC> Should QT commits be tagged [Qt], or is there any convention there?
6812015-11-26T22:20:45  *** Guyver2 has quit IRC
6822015-11-26T22:22:33  *** MarcoFalke has joined #bitcoin-core-dev
6832015-11-26T22:31:21  *** MarcoFalke has quit IRC
6842015-11-26T22:32:50  *** JackH has quit IRC
6852015-11-26T22:38:32  *** alpalp has quit IRC
6862015-11-26T22:43:34  <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
6872015-11-26T22:51:21  *** michagogo has quit IRC
6882015-11-26T22:51:29  *** d_t has joined #bitcoin-core-dev
6892015-11-26T22:54:42  *** Squidicuz has joined #bitcoin-core-dev
6902015-11-26T23:09:46  *** JackH has joined #bitcoin-core-dev
6912015-11-26T23:19:11  *** michagogo has joined #bitcoin-core-dev
6922015-11-26T23:27:24  *** lclc_ is now known as lclc
6932015-11-26T23:33:27  *** Guest22577 has quit IRC
6942015-11-26T23:33:42  *** Anduck has joined #bitcoin-core-dev
6952015-11-26T23:34:04  *** Anduck is now known as Guest39247
6962015-11-26T23:35:28  *** Guest39247 has quit IRC
6972015-11-26T23:36:05  *** Anduck_ has joined #bitcoin-core-dev
6982015-11-26T23:50:17  *** sipa has quit IRC
6992015-11-26T23:50:17  *** sipa has joined #bitcoin-core-dev
7002015-11-26T23:51:36  *** cfields_ has joined #bitcoin-core-dev
7012015-11-26T23:54:13  *** michagogo has quit IRC
7022015-11-26T23:54:14  *** cfields has quit IRC
7032015-11-26T23:54:14  *** evoskuil has quit IRC
7042015-11-26T23:56:27  *** btcdrak has quit IRC