1 2015-11-26T00:17:08  *** tulip has quit IRC
  2 2015-11-26T00:18:04  *** guest234234 has joined #bitcoin-core-dev
  3 2015-11-26T00:19:43  *** guest234234 has quit IRC
  4 2015-11-26T00:40:01  <gmaxwell> sipa: gonna address my comment on https://github.com/bitcoin/bitcoin/pull/6996 ?
  5 2015-11-26T00:40:37  <gmaxwell> sipa: do you have an opinions about jtimons's comment: https://github.com/bitcoin/bitcoin/pull/6508
  6 2015-11-26T00:44:23  *** jl2012 has quit IRC
  7 2015-11-26T00:44:33  *** jl2012 has joined #bitcoin-core-dev
  8 2015-11-26T00:46:28  <sipa> gmaxwell: yeah, will od
  9 2015-11-26T00:48:57  *** tulip has joined #bitcoin-core-dev
 10 2015-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?
 11 2015-11-26T00:51:33  <gmaxwell> Whats the 0x20 hack?
 12 2015-11-26T00:52:25  <cfields_> gmaxwell: reply with the same cAsE as the query
 13 2015-11-26T00:52:48  <sipa> cfields_: i think it's running github.com/sipa/bitcoin-seeder
 14 2015-11-26T00:53:28  <cfields_> sipa: assuming yours runs the same, i can't test against that now 'cause it's down :p
 15 2015-11-26T00:53:57  <sipa> mine is not down
 16 2015-11-26T00:54:19  <cfields_> mm, is for me
 17 2015-11-26T00:54:20  <sipa> at least, it's serving actual requests :)
 18 2015-11-26T00:54:24  <tulip> I can reach all of the DNS seeds at the moment.
 19 2015-11-26T00:54:58  <cfields_> gmaxwell: https://isc.sans.edu/diary/Use+of+Mixed+Case+DNS+Queries/12418
 20 2015-11-26T00:56:31  <Luke-Jr> what sipa said, but I don't see a use case to support this?
 21 2015-11-26T00:57:03  <cfields_> tulip: thanks. confirmed working on a vps as well. Looks like my default dns is borked atm
 22 2015-11-26T00:57:29  <tulip> ;; ANSWER SECTION:
 23 2015-11-26T00:57:29  <tulip> dnsseed.bitcoin.DASHjr.org
 24 2015-11-26T00:57:29  <gribble> Error: "ANSWER" is not a valid command.
 25 2015-11-26T00:57:35  <tulip> is that not correct?
 26 2015-11-26T00:59:38  <sipa> https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00
 27 2015-11-26T00:59:44  <cfields_> tulip: hmm, looks correct.
 28 2015-11-26T01:00:03  <tulip> maybe there's something between you and his DNS server which is mutating it?
 29 2015-11-26T01:00:10  <cfields_> (assuming that's how you queried it, ofc)
 30 2015-11-26T01:00:17  <tulip> yes.
 31 2015-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.
 32 2015-11-26T01:01:54  <cfields_> i'll keep poking around.
 33 2015-11-26T01:02:28  <cfields_> (matt/jonas seeds work fine)
 34 2015-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)
 35 2015-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 :/ )
 36 2015-11-26T01:09:26  <sipa> BlueMatt: disable all notification mails except tagging :)
 37 2015-11-26T01:09:38  <BlueMatt> sipa: but I dont want to do that :(
 38 2015-11-26T01:24:29  *** Ylbam has quit IRC
 39 2015-11-26T01:35:41  <BlueMatt> wumpus: also, wait, why does the gitian build env need network access?
 40 2015-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)
 41 2015-11-26T01:36:29  <BlueMatt> oh, the pr is still open, i'll go comment there
 42 2015-11-26T01:40:49  *** Squidicc has joined #bitcoin-core-dev
 43 2015-11-26T01:41:21  *** dcousens has joined #bitcoin-core-dev
 44 2015-11-26T01:41:40  <dcousens> what happens if SIGHASH_SINGLE is used, but no corresponding output exists?
 45 2015-11-26T01:42:20  <tulip> the SIGHASH_SINGLE bug :P
 46 2015-11-26T01:42:34  <dcousens> haha, nvm, thats right
 47 2015-11-26T01:42:51  <sipa> dcousens: hash == 1 is signed
 48 2015-11-26T01:43:38  *** Squidicuz has quit IRC
 49 2015-11-26T01:43:39  *** jtimon has quit IRC
 50 2015-11-26T01:52:58  *** guest234234 has joined #bitcoin-core-dev
 51 2015-11-26T02:12:15  *** BashCo has quit IRC
 52 2015-11-26T02:12:21  *** BashCo_ has joined #bitcoin-core-dev
 53 2015-11-26T02:35:15  <midnightmagic> BlueMatt: it is possible to do it entirely offline unless something fundamental changed.
 54 2015-11-26T02:35:50  *** belcher has quit IRC
 55 2015-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
 56 2015-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.
 57 2015-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.
 58 2015-11-26T02:53:49  <gmaxwell> tulip: may be due to a peer spamming you with their mempool at connect.
 59 2015-11-26T02:55:44  <tulip> maybe.
 60 2015-11-26T02:55:58  <sipa> gmaxwell: or a rolling bloom filter?
 61 2015-11-26T02:57:16  <gmaxwell> I was trying to keep MRU behavior, but maybe we don't really need it.
 62 2015-11-26T02:57:28  <gmaxwell> would certantly be easier.
 63 2015-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.
 64 2015-11-26T02:59:25  <gmaxwell> okay jinx, it's actually at 1783, but thats still small.
 65 2015-11-26T03:02:22  <sipa> gmaxwell: rolling bloom filter is effectively mru
 66 2015-11-26T03:04:32  <gmaxwell> RB is not per-use salted? weird. why.
 67 2015-11-26T03:07:25  <gmaxwell> what. I am boggle this code.
 68 2015-11-26T03:07:57  <gmaxwell> oh I see.
 69 2015-11-26T03:08:41  <gmaxwell> still, don't see why it's not salted.
 70 2015-11-26T03:10:24  <sipa> it is salted?
 71 2015-11-26T03:10:26  <sipa> no?
 72 2015-11-26T03:10:47  <gmaxwell> constructor has no salt argument and calls the underlying blooms with a tweak of 0.
 73 2015-11-26T03:13:34  <gmaxwell> looks like you have to call reset to randomize it.
 74 2015-11-26T03:13:38  <sipa> oh, right, we didn't want to call getrandbytes in a global constructor
 75 2015-11-26T03:13:45  <gmaxwell> ah duh.
 76 2015-11-26T03:14:09  <sipa> but it could actually automatically reset upon first use
 77 2015-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?
 78 2015-11-26T03:15:03  <gmaxwell> e.g. with b1/b2 are cleared?
 79 2015-11-26T03:15:18  <sipa> yes, that's what i'm suggesting
 80 2015-11-26T03:15:33  <gmaxwell> No reason I can see why the two should have the same tweak.
 81 2015-11-26T03:15:46  <sipa> but only when an actual entry is written to it
 82 2015-11-26T03:15:53  <sipa> not on construction
 83 2015-11-26T03:16:11  <gmaxwell> yea, sure, I mean make the clear functions in insert do it when they clear.
 84 2015-11-26T03:16:35  <sipa> right
 85 2015-11-26T03:19:01  <gmaxwell> whats with the 2* in the rolling bloom filter?
 86 2015-11-26T03:19:15  <sipa> it's needed
 87 2015-11-26T03:19:19  <sipa> :)
 88 2015-11-26T03:20:22  <gmaxwell> whats an acceptable FP rate for the known filtering?
 89 2015-11-26T03:25:18  *** guest234234 has quit IRC
 90 2015-11-26T03:26:04  <sipa> you need around 4.8 bits per element per 1/10 FP rate
 91 2015-11-26T03:26:24  <sipa> so 6*4.8 bits per element for one in a million
 92 2015-11-26T03:27:59  <dcousens> "what. I am boggle this code." lol
 93 2015-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.
 94 2015-11-26T03:30:52  <sipa> ?
 95 2015-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.
 96 2015-11-26T03:31:46  <gmaxwell> if I send you the same item non-stop, and you drop it when contains, it will fall out.
 97 2015-11-26T03:33:19  <sipa> right
 98 2015-11-26T03:33:35  <sipa> it is most recently added, not most recently used
 99 2015-11-26T03:50:27  *** Arnavion has quit IRC
100 2015-11-26T03:50:43  *** Arnavion has joined #bitcoin-core-dev
101 2015-11-26T04:32:39  *** guest234234 has joined #bitcoin-core-dev
102 2015-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.
103 2015-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.
104 2015-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.
105 2015-11-26T05:41:33  *** tulip has quit IRC
106 2015-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
107 2015-11-26T06:21:47  *** PaulCapestany has quit IRC
108 2015-11-26T06:23:41  *** PaulCapestany has joined #bitcoin-core-dev
109 2015-11-26T06:29:46  *** PaulCapestany has quit IRC
110 2015-11-26T06:31:08  *** PaulCapestany has joined #bitcoin-core-dev
111 2015-11-26T06:36:59  *** PaulCapestany has quit IRC
112 2015-11-26T06:41:49  *** PaulCapestany has joined #bitcoin-core-dev
113 2015-11-26T07:10:49  *** Ylbam has joined #bitcoin-core-dev
114 2015-11-26T07:25:32  *** moli has joined #bitcoin-core-dev
115 2015-11-26T08:09:36  *** lightningbot has joined #bitcoin-core-dev
116 2015-11-26T08:09:38  *** ParadoxSpiral has joined #bitcoin-core-dev
117 2015-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
118 2015-11-26T08:09:57  *** Arnavion has joined #bitcoin-core-dev
119 2015-11-26T08:10:00  <jonasschnelli> Wait... sorry. wrong code line:
120 2015-11-26T08:10:01  <jonasschnelli> the UI did play with a global var for a temporary state
121 2015-11-26T08:10:05  <jonasschnelli> nFeeNeeded = payTxFee.GetFeePerK();
122 2015-11-26T08:10:07  *** morcos has joined #bitcoin-core-dev
123 2015-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?
124 2015-11-26T08:10:25  <wumpus> jonasschnelli: but this affect the non-UI as well right? I'm much more concerned with that
125 2015-11-26T08:10:33  <jonasschnelli> right
126 2015-11-26T08:10:40  <jonasschnelli> This is the problem: nFeeNeeded = payTxFee.GetFeePerK();
127 2015-11-26T08:10:46  <jonasschnelli> We take a perKB fee rate as absolute fee.
128 2015-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
129 2015-11-26T08:10:54  <jonasschnelli> But only when fPayAtLeastCustomFee = true
130 2015-11-26T08:10:58  <jonasschnelli> (which is the default!)
131 2015-11-26T08:10:58  <wumpus> but I'm not sure about RPC...
132 2015-11-26T08:11:28  <jonasschnelli> IMO it's bad that the UI can change global state during "normal operation" (non-settings operations)
133 2015-11-26T08:11:34  <wumpus> how are settxfee and smartfees *supposed* to interact?
134 2015-11-26T08:11:43  <wumpus> jonasschnelli: I agree
135 2015-11-26T08:12:10  *** Arnavion has quit IRC
136 2015-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.
137 2015-11-26T08:12:33  <jonasschnelli> a) absolute fees should only be possible when enabling and using coincontrol
138 2015-11-26T08:12:36  <wumpus> there should be nothing with absolute fees IMO
139 2015-11-26T08:12:41  *** Arnavion has joined #bitcoin-core-dev
140 2015-11-26T08:12:42  <jonasschnelli> b) UI set absolute fees should never change the global fee level!
141 2015-11-26T08:12:44  <wumpus> fees should be relative througout bitcoind
142 2015-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.
143 2015-11-26T08:13:16  <jonasschnelli> right.. the PR 7096 does minimize the possibilities of absolute fees.
144 2015-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.
145 2015-11-26T08:13:44  <wumpus> but I'd like to know: how are settxfee and smartfees *supposed* to interact?
146 2015-11-26T08:13:58  <gmaxwell> well no harm no foul at least.
147 2015-11-26T08:14:10  <gmaxwell> If we don't have any wallet users at all there will be no bugs. :)
148 2015-11-26T08:14:14  <jonasschnelli> simply spoken: settxfee has nothing to do with the "bug".
149 2015-11-26T08:14:27  <jonasschnelli> The problem lays deeper in "CWallet::GetMinimumFee"
150 2015-11-26T08:14:50  <wumpus> gmaxwell: right, no one reported this, but it may explain some 'my transaction never goes through'
151 2015-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
152 2015-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.
153 2015-11-26T08:16:07  <jonasschnelli> There is no way to change this unsless you use the UI
154 2015-11-26T08:16:16  <jonasschnelli> fPayAtLeastCustomFee is always true
155 2015-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.
156 2015-11-26T08:16:35  *** AtashiCon has joined #bitcoin-core-dev
157 2015-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.
158 2015-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 :)
159 2015-11-26T08:17:18  <wumpus> oh the tests break? change the tests
160 2015-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.
161 2015-11-26T08:17:53  <wumpus> jonasschnelli: ok. Let's just remove anything to do with absolute fee setting.
162 2015-11-26T08:18:13  <jonasschnelli> wumpus: PR 7096 does that "almost".
163 2015-11-26T08:18:35  <jonasschnelli> It enables the option to set an "absolute fee" IF coin join is enabled and inputs are selected.
164 2015-11-26T08:18:39  <jonasschnelli> I think that's okay.
165 2015-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  :)
166 2015-11-26T08:18:53  <jonasschnelli> The "absolute fee" option is even hidden if coinjoin is disabled.
167 2015-11-26T08:19:09  <jonasschnelli> s/coinjoin/coincontrol
168 2015-11-26T08:19:25  *** isis has joined #bitcoin-core-dev
169 2015-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
170 2015-11-26T08:19:31  <gmaxwell> cases.
171 2015-11-26T08:19:54  <gmaxwell> jonasschnelli: if so I think the UI should just be translating that to relative fees
172 2015-11-26T08:19:58  <wumpus> also we have lots of randomized algorithms, and randomized tests
173 2015-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
174 2015-11-26T08:20:08  <wumpus> this doesn't make either easier
175 2015-11-26T08:21:07  <wumpus> e.g. the tests here hardcode the hash function used even https://github.com/bitcoin/bitcoin/pull/7078
176 2015-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?
177 2015-11-26T08:21:29  <wumpus> it's pseudo-randomized using the hash function, but exact results are tested
178 2015-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.
179 2015-11-26T08:22:14  *** Thireus has quit IRC
180 2015-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
181 2015-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.
182 2015-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).
183 2015-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.
184 2015-11-26T08:23:14  <jonasschnelli> but we could also remove the absolute fee entirely...
185 2015-11-26T08:23:22  *** pkthebud has quit IRC
186 2015-11-26T08:23:22  *** pkthebud has joined #bitcoin-core-dev
187 2015-11-26T08:23:25  *** fkhan has quit IRC
188 2015-11-26T08:23:25  *** fkhan has joined #bitcoin-core-dev
189 2015-11-26T08:23:31  <gmaxwell> raedah: You actually cannot tell your contribution to the fees, it's unknowable to the wallet.
190 2015-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
191 2015-11-26T08:23:37  <jonasschnelli> maybe 0.12 remove absolute fee, 0.11 backport not.
192 2015-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)
193 2015-11-26T08:24:07  *** btcdrak has quit IRC
194 2015-11-26T08:24:08  *** btcdrak has joined #bitcoin-core-dev
195 2015-11-26T08:24:20  <jonasschnelli> wumpus: or if you don't trust the fee estimator?
196 2015-11-26T08:24:32  <wumpus> jonasschnelli: you can still provide a fee per kB right?
197 2015-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.
198 2015-11-26T08:24:41  <jonasschnelli> wumpus: right...
199 2015-11-26T08:24:42  <wumpus> jonasschnelli: no fee estimator involved
200 2015-11-26T08:24:45  <gmaxwell> Simply because the backport will not be as extensively tested.
201 2015-11-26T08:24:53  <wumpus> 'fee estimator' has to be selected (that's smart fee)
202 2015-11-26T08:25:13  <wumpus> well the requirement for backport are: small code impact, easy to test
203 2015-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)
204 2015-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
205 2015-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.
206 2015-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.
207 2015-11-26T08:26:39  <wumpus> jonasschnelli: right...
208 2015-11-26T08:27:04  <wumpus> jonasschnelli: doesn't seem like a large diff anyway, probably applies cleanly right now?
209 2015-11-26T08:27:15  <gmaxwell> yea, we could do the smallest fix that fixes settxfee, then later remove the absolute in the gui.
210 2015-11-26T08:28:03  <jonasschnelli> I think https://github.com/bitcoin/bitcoin/pull/7096/files is minimal if you hide the RPC tests.
211 2015-11-26T08:28:41  <jonasschnelli> and a backport should be easy because we didn't changes that part since then i guesx
212 2015-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.
213 2015-11-26T08:29:35  <wumpus> gmaxwell: yes - nodes that reconnect at all are suspect. They're either your own or a spy node :)
214 2015-11-26T08:30:09  <wumpus> so if you whitelist your own nodes, that leaves spies
215 2015-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.
216 2015-11-26T08:31:23  *** guest234234 has quit IRC
217 2015-11-26T08:31:35  *** AtashiCon has quit IRC
218 2015-11-26T08:31:39  *** Arnavion3 has joined #bitcoin-core-dev
219 2015-11-26T08:31:43  *** Arnavion3 is now known as AtashiCon
220 2015-11-26T08:32:00  <wumpus> gmaxwell: sure...
221 2015-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
222 2015-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.
223 2015-11-26T08:33:15  <jonasschnelli> Somehow it looks strange if the sum of all you row in the transaction-table != your balance.
224 2015-11-26T08:33:23  <jonasschnelli> that's why i had this idea in mind.
225 2015-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.
226 2015-11-26T08:33:28  <wumpus> jonasschnelli: I certainly agree with visually distinguishing coinjoin transactions, and warning that the fee is not really the fee
227 2015-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.
228 2015-11-26T08:33:51  *** Arnavion has quit IRC
229 2015-11-26T08:33:58  *** Arnavion has joined #bitcoin-core-dev
230 2015-11-26T08:34:09  <jonasschnelli> wumpus: is displaying the fee (which is not known at this point) even required?
231 2015-11-26T08:34:09  <wumpus> jonasschnelli: but personally I'm not a huge fan of the idea of adding more rows for them
232 2015-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.
233 2015-11-26T08:35:05  <wumpus> jonasschnelli: consider this: what if every transaction you do is coinjoin
234 2015-11-26T08:35:19  <wumpus> jonasschnelli: (I somewhat hope that is going to be the future)
235 2015-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?
236 2015-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.
237 2015-11-26T08:35:45  <wumpus> jonasschnelli: there shouldn't be too much overhead in that case
238 2015-11-26T08:35:57  <gmaxwell> Really robust handling requires extra metadata: you need to know which of the payments are yours.
239 2015-11-26T08:36:13  <wumpus> yes
240 2015-11-26T08:36:33  <jonasschnelli> okay... so what would be the way to go? :)
241 2015-11-26T08:36:39  <gmaxwell> We should probably change the 'wallet equation'  from   myinputs - fee = outputs   to  myinputs + otherinputs - fees = outputs.
242 2015-11-26T08:36:47  <wumpus> but we don't have that metadata right now, so we have to handle this without it
243 2015-11-26T08:37:02  <gmaxwell> And to ever transaction in list transactions add an extra_inputs: field, and get the fees right.
244 2015-11-26T08:37:25  <gmaxwell> but this requires adding information about utxo not currently in the wallet.
245 2015-11-26T08:37:52  *** morcos has quit IRC
246 2015-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.
247 2015-11-26T08:38:18  *** morcos has joined #bitcoin-core-dev
248 2015-11-26T08:38:18  <gmaxwell> and the others could be hidden like change is now.
249 2015-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.
250 2015-11-26T08:41:05  <wumpus> right, the wallet needs additional information about inputs
251 2015-11-26T08:41:46  <wumpus> so that even if the originating transactions are no longer known, it still knows the sizes involved
252 2015-11-26T08:42:01  <raedah> gmaxwell, im not clear here. We do know what our input and outputs in the transaction are.
253 2015-11-26T08:43:03  <wumpus> raedah: we don't know what our outputs are, I think?
254 2015-11-26T08:43:27  <raedah> all inputs and outputs are loaded as watchaddresses
255 2015-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
256 2015-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'.
257 2015-11-26T08:44:04  <gmaxwell> raedah: well thats busted.
258 2015-11-26T08:44:27  <wumpus> where? why would you load outputs as watchaddress?
259 2015-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. :)
260 2015-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.
261 2015-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
262 2015-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.
263 2015-11-26T08:46:48  <gmaxwell> a JM maker is all paying themselves, true, but not a JM taker.
264 2015-11-26T08:47:31  <wumpus> I'm not sure how watch-only helps here at all
265 2015-11-26T08:48:01  <gmaxwell> wumpus: JM's 'market makers' have their own external wallet managed by JM, effectively.
266 2015-11-26T08:48:23  <wumpus> ok - if there is an external wallet owned by you adding *those* as watchonly makes sense
267 2015-11-26T08:49:17  <wumpus> because it's your balance. But adding other people's inputs/outputs would not be a good idea.
268 2015-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.
269 2015-11-26T08:49:54  <raedah> wumpus, and joinmarket requires it to pull the data it needs on those addressses from the rpc.
270 2015-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!)
271 2015-11-26T08:50:39  <wumpus> gmaxwell: makes sense
272 2015-11-26T08:50:45  <gmaxwell> raedah: do you know specifically what it needs?
273 2015-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.
274 2015-11-26T08:51:47  <raedah> i think its looking for address balances, and maybe tx confirmations.
275 2015-11-26T08:52:11  * gmaxwell ducks into #joinmarket
276 2015-11-26T08:52:26  <wumpus> both can be determinied using just the utxo set
277 2015-11-26T08:53:15  <wumpus> (as anything actively spendable, is, by definition, in there)
278 2015-11-26T08:53:32  <wumpus> no need for any scan over transaction history
279 2015-11-26T08:54:46  * wumpus tries to remember how the RPC call to query utxos was called...
280 2015-11-26T08:54:46  <gmaxwell> They may not know about gettxout or gettxoutproof.
281 2015-11-26T08:54:56  <wumpus> heh :-)
282 2015-11-26T08:55:58  *** paveljanik has joined #bitcoin-core-dev
283 2015-11-26T08:55:58  *** paveljanik has joined #bitcoin-core-dev
284 2015-11-26T08:56:02  <gmaxwell> earlier on it used some third party API; which probably didn't provide an interface intended for scalablity. :)
285 2015-11-26T08:56:10  <wumpus> https://bitcoin.org/en/developer-reference#gettxout
286 2015-11-26T08:56:48  <wumpus> (gettxoutproof is also documented in the same place)
287 2015-11-26T09:01:24  *** jgarzik has joined #bitcoin-core-dev
288 2015-11-26T09:02:39  *** jgarzik__ has quit IRC
289 2015-11-26T09:03:26  <wumpus> does that give enough functionality or do you really need to query the utxo set by address/output script?
290 2015-11-26T09:04:51  <gmaxwell> It shouldn't!, but I'm asking.
291 2015-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.
292 2015-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)
293 2015-11-26T09:05:49  <gmaxwell> (if so, then that can be fixed.. as the protocol is far from set in stone)
294 2015-11-26T09:06:37  <wumpus> right
295 2015-11-26T09:07:33  *** raedah has quit IRC
296 2015-11-26T09:07:52  <gmaxwell> https://github.com/chris-belcher/joinmarket/blob/master/lib/blockchaininterface.py
297 2015-11-26T09:08:13  <gmaxwell> yea, looks like it's trying to emulate the blockr interface instead of doing things sanely.
298 2015-11-26T09:11:38  *** ParadoxSpiral has quit IRC
299 2015-11-26T09:15:11  *** BashCo_ has quit IRC
300 2015-11-26T09:16:31  *** JackH has joined #bitcoin-core-dev
301 2015-11-26T09:27:44  *** phantomcircuit_ is now known as phantomcircuit
302 2015-11-26T09:30:48  *** Madars has joined #bitcoin-core-dev
303 2015-11-26T09:32:35  *** morcos has quit IRC
304 2015-11-26T09:32:36  *** jcorgan_ has quit IRC
305 2015-11-26T09:33:11  *** JackH has quit IRC
306 2015-11-26T09:33:48  *** pmienk_ has quit IRC
307 2015-11-26T09:33:48  *** go1111111 has quit IRC
308 2015-11-26T09:33:48  *** nanotube has quit IRC
309 2015-11-26T09:33:56  *** BashCo has joined #bitcoin-core-dev
310 2015-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)?
311 2015-11-26T09:35:06  <gmaxwell> No dup
312 2015-11-26T09:35:12  <gmaxwell> size does not consume its input.
313 2015-11-26T09:35:17  <aj_> right
314 2015-11-26T09:38:18  <gmaxwell> 57 is ~ 15 zeros.   Your ECC mult numbers are comically slow.
315 2015-11-26T09:38:34  *** Thireus has joined #bitcoin-core-dev
316 2015-11-26T09:39:46  <gmaxwell> https://www.blockstream.com/half-a-puzzle/  notice the ground nonces here.
317 2015-11-26T09:40:26  <gmaxwell> 02000000000005689111130e588a12ecda87b2dc5585c6c6ba ffffffff077b7209dc866fbfa0d2bf67a0c696afffe57a822e deadbeef2f4a23b0f1954100b76bcb720f7b2ddc4a446dc06b
318 2015-11-26T09:40:50  <aj_> yeah, that's 5 bytes of zeroes
319 2015-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)
320 2015-11-26T09:41:16  <sipa_> i suppose the above few lines contain several hints?
321 2015-11-26T09:41:21  *** sipa_ is now known as sipa
322 2015-11-26T09:41:31  *** morcos has joined #bitcoin-core-dev
323 2015-11-26T09:41:48  <aj_> sipa: yeah, gmaxwell stated the script already
324 2015-11-26T09:41:59  <aj_> sipa: in -wizards anyway; oops, i guess this is the wrong channel
325 2015-11-26T09:42:04  <gmaxwell> oops
326 2015-11-26T09:42:45  *** jcorgan has joined #bitcoin-core-dev
327 2015-11-26T09:42:45  *** jcorgan has joined #bitcoin-core-dev
328 2015-11-26T09:43:52  *** nanotube has joined #bitcoin-core-dev
329 2015-11-26T09:44:58  *** go1111111 has joined #bitcoin-core-dev
330 2015-11-26T09:45:58  *** JackH has joined #bitcoin-core-dev
331 2015-11-26T09:47:33  *** pmienk_ has joined #bitcoin-core-dev
332 2015-11-26T09:48:32  *** aj_ is now known as aj
333 2015-11-26T09:57:39  *** Thireus has quit IRC
334 2015-11-26T09:59:43  *** Thireus has joined #bitcoin-core-dev
335 2015-11-26T10:18:55  <GitHub56> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/be281d8a83ca...f8a8e27a6a19
336 2015-11-26T10:18:56  <GitHub56> bitcoin/master fa472f3 MarcoFalke: [trivial] Fix -maxmempool InitError
337 2015-11-26T10:18:56  <GitHub56> bitcoin/master f8a8e27 Wladimir J. van der Laan: Merge pull request #7069...
338 2015-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
339 2015-11-26T10:35:22  <jonasschnelli> When is code freeze for 0.12?
340 2015-11-26T10:35:36  <jonasschnelli> (or feature freeze)
341 2015-11-26T10:36:05  <jonasschnelli> Found it. 01.12.15
342 2015-11-26T10:36:35  <gmaxwell> I was expecting the end of the monthish. Don't tell me I've got more weeks! :P
343 2015-11-26T10:37:13  <btcdrak> haha, that's British notation gmaxwell ;)
344 2015-11-26T10:37:23  <btcdrak> the right way!
345 2015-11-26T10:37:54  <sipa> what's so british about it? :)
346 2015-11-26T10:38:04  <gmaxwell> it's bass-ackwards?
347 2015-11-26T10:38:12  <btcdrak> :D
348 2015-11-26T10:38:13  <gmaxwell> ISO forever. 2015-12-01
349 2015-11-26T10:38:20  <sipa> the only right date format is of course 2015-12-01, which is lexicographically sortable
350 2015-11-26T10:38:20  <btcdrak> ^ Chinese
351 2015-11-26T10:38:42  <jonasschnelli> d-m-y ... that's how the brain things. (at least mine. :P )
352 2015-11-26T10:38:45  <wumpus> agree with sipa
353 2015-11-26T10:38:48  <jonasschnelli> *thinks
354 2015-11-26T10:38:54  <gmaxwell> okay, that was my expectation. whew.
355 2015-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
356 2015-11-26T10:40:15  <wumpus> at least write out the month name if you'er doing that :)
357 2015-11-26T10:40:34  <gmaxwell> or only work with days after the 12th.
358 2015-11-26T10:42:29  <sipa> oh, it's 12/01/2015 in the us
359 2015-11-26T10:42:39  <sipa> i just remember it's middle endian
360 2015-11-26T10:44:01  <paveljanik> I like the term "middle endian" ;-)
361 2015-11-26T10:44:26  <gmaxwell> it's a thing
362 2015-11-26T10:44:32  <paveljanik> one friend is using "just enough endian"
363 2015-11-26T10:45:03  <wumpus> it's a good example of where a compromise is the worst outcome possible :)
364 2015-11-26T10:46:01  <gmaxwell> sipa: lets just use MJD ... 57356 is less typing than all that stuff.
365 2015-11-26T10:47:24  <paveljanik> or XI.XXVI.MMXV
366 2015-11-26T10:47:33  <wumpus> baa if we're going that way I'd prefer to just use megaseconds
367 2015-11-26T10:47:34  * gmaxwell waits for luke-jr to tell us the tonal date
368 2015-11-26T10:47:52  <sipa> gmaxwell: that's may 6th 735?
369 2015-11-26T10:48:05  <wumpus> since the epoch of course
370 2015-11-26T10:48:14  *** Thireus has quit IRC
371 2015-11-26T10:48:28  <sipa> wumpus: megaseconds are not very accurate
372 2015-11-26T10:48:32  <paveljanik> you mean from the genesis block?
373 2015-11-26T10:48:51  <sipa> wumpus: how about deciforthnights?
374 2015-11-26T10:48:55  <wumpus> sipa: right, well, just use fractions
375 2015-11-26T10:48:56  <gmaxwell> sipa: no, 2015-12-01; there
376 2015-11-26T10:49:10  <wumpus> (precision as necessary)
377 2015-11-26T10:49:22  <sipa> gmaxwell: oh, i misread as MYD, and though you were just concatenating M Y and D
378 2015-11-26T10:49:34  <sipa> gmaxwell: it's Msomething julian date?
379 2015-11-26T10:49:45  <gmaxwell> Yes, http://tycho.usno.navy.mil/mjd.html
380 2015-11-26T10:53:20  *** Thireus has joined #bitcoin-core-dev
381 2015-11-26T11:05:06  *** guest234234 has joined #bitcoin-core-dev
382 2015-11-26T11:07:23  *** d_t_ has quit IRC
383 2015-11-26T11:23:15  *** randy-waterhouse has quit IRC
384 2015-11-26T11:46:39  *** andytoshi has quit IRC
385 2015-11-26T11:54:41  *** jtimon has joined #bitcoin-core-dev
386 2015-11-26T12:07:03  <jonasschnelli> jgarzik: Did you had time to review https://github.com/jgarzik/univalue/pull/14 ?
387 2015-11-26T12:13:55  <gmaxwell> When andytoshi's back online he should be pinged to differentially test against that.
388 2015-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.
389 2015-11-26T12:27:04  <wumpus> doesn't rust already have libraries for json parsing/generation? or was that mostly an educational exercise?
390 2015-11-26T12:33:39  *** MarcoFalke has joined #bitcoin-core-dev
391 2015-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.
392 2015-11-26T12:45:56  <jonasschnelli> I don't expect people using RPC and UI at the same time.
393 2015-11-26T12:46:03  <jonasschnelli> Maybe we should warn in the release notes at least.
394 2015-11-26T12:46:57  *** paveljanik has quit IRC
395 2015-11-26T12:47:03  <wumpus> jonasschnelli: well, we should try to rule out that risk as much as possible
396 2015-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
397 2015-11-26T12:48:11  *** andytoshi has joined #bitcoin-core-dev
398 2015-11-26T12:48:42  <wumpus> but 'using RPC with the UI randomly crashes or sends random amounts to random people' would not be :)
399 2015-11-26T12:48:57  <jonasschnelli> Right... I don't expect people to blame us of not fixing the UI/RPC interfering bug over backports.
400 2015-11-26T12:49:00  <MarcoFalke> About fees and release notes: I think a general write up about how fees work now should be planned
401 2015-11-26T12:49:27  <wumpus> MarcoFalke: yes that would be welcome
402 2015-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?
403 2015-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
404 2015-11-26T12:50:09  * jonasschnelli is working on the most simplest backport
405 2015-11-26T12:50:16  <wumpus> jonasschnelli: yes, definitely
406 2015-11-26T12:50:47  <wumpus> jonasschnelli: tests are the most important part, they prove that it's fixed :)
407 2015-11-26T12:50:54  <jonasschnelli> ha. right!
408 2015-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
409 2015-11-26T12:52:14  <MarcoFalke> Will do the backport soon
410 2015-11-26T12:52:51  <wumpus> are you and jonasschnelli working together or duplicating work?
411 2015-11-26T12:53:11  <MarcoFalke> jonas is doing the gui work
412 2015-11-26T12:53:17  <MarcoFalke> I did the rpc tests
413 2015-11-26T12:53:30  <MarcoFalke> we split up in two PRs
414 2015-11-26T12:53:34  <wumpus> ok, great!
415 2015-11-26T12:57:07  <jonasschnelli> Yeah. Fine for me. I appreciate every help.
416 2015-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'))
417 2015-11-26T12:59:07  <MarcoFalke> >>> Decimal("0.100") == Decimal(".1")
418 2015-11-26T12:59:07  <MarcoFalke> True
419 2015-11-26T12:59:14  <MarcoFalke> I will get rid of those,
420 2015-11-26T12:59:19  <wumpus> I don't really have an opinion on the precision, but I didn't understand the change :)
421 2015-11-26T13:01:05  <wumpus> changing one line in the code is a nicely minimal change though
422 2015-11-26T13:01:54  <jonasschnelli> a true/false flip is probably the smallest change we can offer. :)
423 2015-11-26T13:02:45  <wumpus> yes a one bitflip
424 2015-11-26T13:07:50  <MarcoFalke> Whos responsible for travis?
425 2015-11-26T13:07:56  <MarcoFalke> Need someone to ping :)
426 2015-11-26T13:08:01  <sipa> MarcoFalke: what's the problem?
427 2015-11-26T13:08:19  <MarcoFalke> Two workers are stuck since several days, I think
428 2015-11-26T13:08:30  <jonasschnelli> i think it just requires some minutes until it starts
429 2015-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
430 2015-11-26T13:09:28  <jonasschnelli> I think MarcoFalke is right: https://travis-ci.org/bitcoin/bitcoin/builds/92025728
431 2015-11-26T13:09:34  <MarcoFalke> https://travis-ci.org/bitcoin/bitcoin/builds/92213684
432 2015-11-26T13:10:41  <sipa> cancelled
433 2015-11-26T13:11:31  <MarcoFalke> nice, 4/5
434 2015-11-26T13:11:37  <MarcoFalke> Can you cancel https://travis-ci.org/bitcoin/bitcoin/builds/92213684 as well
435 2015-11-26T13:12:14  <sipa> done
436 2015-11-26T13:12:23  <sipa> restarted
437 2015-11-26T13:12:35  <MarcoFalke> all running 5/5
438 2015-11-26T13:15:47  *** BashCo_ has joined #bitcoin-core-dev
439 2015-11-26T13:16:06  *** BashCo has quit IRC
440 2015-11-26T14:03:37  *** wangchun has joined #bitcoin-core-dev
441 2015-11-26T14:20:27  *** guest234234 has quit IRC
442 2015-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?
443 2015-11-26T14:29:52  <jonasschnelli> would something speak against using the signal?
444 2015-11-26T14:30:05  <jonasschnelli> the timer is still required for the bandwith graph...
445 2015-11-26T14:30:15  <sipa> jonasschnelli: the signal may fire way too frequently sometimes, afaik
446 2015-11-26T14:30:42  <sipa> up to the point that updating the GUI was slowing down synchronization
447 2015-11-26T14:30:46  <jonasschnelli> the timer with the trylock fires every 250ms!
448 2015-11-26T14:31:04  <sipa> during IBD the signal may fire every ms :)
449 2015-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.
450 2015-11-26T14:32:19  <jonasschnelli> it just looks like that the TRY_LOCK often can acquire the lock
451 2015-11-26T14:32:23  <jonasschnelli> can't
452 2015-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?!
453 2015-11-26T14:41:37  <sipa> jonasschnelli: that's correct, but signals still run synchronously
454 2015-11-26T14:42:10  <jonasschnelli> sipa: right,.. but at least the could emit/pass a QT async signal to the GUI thread
455 2015-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
456 2015-11-26T14:42:29  <sipa> jonasschnelli: i don't think you want to emit 1000 signals per second still :)
457 2015-11-26T14:43:09  <jonasschnelli> sipa: hmm... let me benchmark it,.. maybe a min-time-delta is required to avoid over-updating the ui.
458 2015-11-26T14:43:49  <jonasschnelli> and the signal only fires !fInitialDownload
459 2015-11-26T14:44:26  <sipa> ah
460 2015-11-26T15:05:15  *** Guyver2 has joined #bitcoin-core-dev
461 2015-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.
462 2015-11-26T15:27:01  *** arowser has quit IRC
463 2015-11-26T15:27:25  *** arowser has joined #bitcoin-core-dev
464 2015-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!
465 2015-11-26T15:35:13  *** ParadoxSpiral has joined #bitcoin-core-dev
466 2015-11-26T15:36:02  <sipa> that seems ok...
467 2015-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
468 2015-11-26T16:00:37  *** BashCo_ has quit IRC
469 2015-11-26T16:03:03  <sipa> jonasschnelli: going to try to implement another approach for 7067
470 2015-11-26T16:03:25  <jonasschnelli> sipa: that was actually my intention... :)
471 2015-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
472 2015-11-26T16:33:42  *** tripleslash_a has joined #bitcoin-core-dev
473 2015-11-26T16:35:34  *** evoskuil has quit IRC
474 2015-11-26T16:35:37  *** evoskuil has joined #bitcoin-core-dev
475 2015-11-26T16:35:37  *** andytoshi has quit IRC
476 2015-11-26T16:35:37  *** tripleslash has quit IRC
477 2015-11-26T16:36:11  *** andytoshi has joined #bitcoin-core-dev
478 2015-11-26T16:40:03  *** jl2012_ has joined #bitcoin-core-dev
479 2015-11-26T16:40:31  *** jl2012 has quit IRC
480 2015-11-26T17:15:00  *** Thireus has quit IRC
481 2015-11-26T17:45:54  *** ParadoxSpiral_ has joined #bitcoin-core-dev
482 2015-11-26T17:48:30  *** ParadoxSpiral has quit IRC
483 2015-11-26T17:58:56  *** cocoBTC has joined #bitcoin-core-dev
484 2015-11-26T17:59:31  *** d_t has joined #bitcoin-core-dev
485 2015-11-26T18:20:12  *** raedah has joined #bitcoin-core-dev
486 2015-11-26T18:24:11  *** JackH has quit IRC
487 2015-11-26T18:28:15  *** paveljanik has joined #bitcoin-core-dev
488 2015-11-26T18:40:23  *** Thireus has joined #bitcoin-core-dev
489 2015-11-26T18:57:09  *** lecusemb1e has joined #bitcoin-core-dev
490 2015-11-26T18:57:13  *** harding_ has joined #bitcoin-core-dev
491 2015-11-26T18:58:31  *** AtashiCon has quit IRC
492 2015-11-26T18:58:35  *** Arnavion3 has joined #bitcoin-core-dev
493 2015-11-26T18:58:39  *** Arnavion3 is now known as AtashiCon
494 2015-11-26T18:59:32  *** d_t_ has joined #bitcoin-core-dev
495 2015-11-26T18:59:38  *** btcdrak_ has joined #bitcoin-core-dev
496 2015-11-26T19:01:42  *** d_t has quit IRC
497 2015-11-26T19:01:42  *** tripleslash_a has quit IRC
498 2015-11-26T19:01:43  *** morcos has quit IRC
499 2015-11-26T19:01:43  *** jgarzik has quit IRC
500 2015-11-26T19:01:43  *** Guest1234 has quit IRC
501 2015-11-26T19:01:43  *** btcdrak has quit IRC
502 2015-11-26T19:01:43  *** warren has quit IRC
503 2015-11-26T19:01:43  *** Anduck has quit IRC
504 2015-11-26T19:01:44  *** Eliel has quit IRC
505 2015-11-26T19:01:44  *** sdaftuar has quit IRC
506 2015-11-26T19:01:44  *** lecusemble has quit IRC
507 2015-11-26T19:01:44  *** gavinandresen has quit IRC
508 2015-11-26T19:01:45  *** lclc has quit IRC
509 2015-11-26T19:01:45  *** [b__b] has quit IRC
510 2015-11-26T19:01:45  *** harding has quit IRC
511 2015-11-26T19:01:45  *** instagibbs has quit IRC
512 2015-11-26T19:01:45  *** BlueMatt_ has quit IRC
513 2015-11-26T19:01:46  *** ParadoxSpiral_ has quit IRC
514 2015-11-26T19:01:46  *** andytoshi has quit IRC
515 2015-11-26T19:01:46  *** berndj has quit IRC
516 2015-11-26T19:01:46  *** neha has quit IRC
517 2015-11-26T19:01:47  *** mm_1 has quit IRC
518 2015-11-26T19:01:47  *** aj has quit IRC
519 2015-11-26T19:01:47  *** bsm1175322 has quit IRC
520 2015-11-26T19:01:47  *** amiller_ has quit IRC
521 2015-11-26T19:01:48  *** ghtdak has quit IRC
522 2015-11-26T19:01:48  *** asoltys has quit IRC
523 2015-11-26T19:01:49  *** go1111111 has quit IRC
524 2015-11-26T19:01:49  *** jcorgan has quit IRC
525 2015-11-26T19:01:49  *** michagogo has quit IRC
526 2015-11-26T19:01:50  *** pkthebud has quit IRC
527 2015-11-26T19:01:50  *** petertodd has quit IRC
528 2015-11-26T19:01:50  *** wumpus has quit IRC
529 2015-11-26T19:01:50  *** sipa has quit IRC
530 2015-11-26T19:01:50  *** phantomcircuit has quit IRC
531 2015-11-26T19:01:50  *** Ylbam has quit IRC
532 2015-11-26T19:01:50  *** midnightmagic has quit IRC
533 2015-11-26T19:01:50  *** blkdb has quit IRC
534 2015-11-26T19:01:51  *** zmanian_ has quit IRC
535 2015-11-26T19:01:51  *** s1w has quit IRC
536 2015-11-26T19:01:52  *** raedah has quit IRC
537 2015-11-26T19:01:52  *** paveljanik has quit IRC
538 2015-11-26T19:01:52  *** Guyver2 has quit IRC
539 2015-11-26T19:01:52  *** wangchun has quit IRC
540 2015-11-26T19:01:53  *** Arnavion has quit IRC
541 2015-11-26T19:01:53  *** isis has quit IRC
542 2015-11-26T19:01:53  *** PaulCapestany has quit IRC
543 2015-11-26T19:01:53  *** da2ce7_ has quit IRC
544 2015-11-26T19:01:53  *** kanzure has quit IRC
545 2015-11-26T19:01:53  *** gmaxwell has quit IRC
546 2015-11-26T19:01:53  *** Amnez777 has quit IRC
547 2015-11-26T19:01:53  *** arubi has quit IRC
548 2015-11-26T19:01:54  *** gribble has quit IRC
549 2015-11-26T19:01:54  *** alpalp has quit IRC
550 2015-11-26T19:01:54  *** BananaLotus has quit IRC
551 2015-11-26T19:02:37  *** BlueMatt_ has joined #bitcoin-core-dev
552 2015-11-26T19:02:59  *** btcdrak_ is now known as btcdrak
553 2015-11-26T19:03:21  *** sdaftuar has joined #bitcoin-core-dev
554 2015-11-26T19:03:23  *** raedah has joined #bitcoin-core-dev
555 2015-11-26T19:03:34  *** Anduck has joined #bitcoin-core-dev
556 2015-11-26T19:03:45  *** morcos has joined #bitcoin-core-dev
557 2015-11-26T19:04:05  *** Anduck is now known as Guest22577
558 2015-11-26T19:05:21  *** btcdrak has quit IRC
559 2015-11-26T19:05:28  *** lclc has joined #bitcoin-core-dev
560 2015-11-26T19:08:06  *** gavinand1esen has joined #bitcoin-core-dev
561 2015-11-26T19:08:06  *** JackH has joined #bitcoin-core-dev
562 2015-11-26T19:08:06  *** jgarzik_ has joined #bitcoin-core-dev
563 2015-11-26T19:08:06  *** ParadoxSpiral_ has joined #bitcoin-core-dev
564 2015-11-26T19:08:06  *** andytoshi has joined #bitcoin-core-dev
565 2015-11-26T19:08:06  *** berndj has joined #bitcoin-core-dev
566 2015-11-26T19:08:06  *** neha has joined #bitcoin-core-dev
567 2015-11-26T19:08:06  *** mm_1 has joined #bitcoin-core-dev
568 2015-11-26T19:08:06  *** aj has joined #bitcoin-core-dev
569 2015-11-26T19:08:06  *** bsm1175322 has joined #bitcoin-core-dev
570 2015-11-26T19:08:06  *** asoltys has joined #bitcoin-core-dev
571 2015-11-26T19:08:06  *** amiller_ has joined #bitcoin-core-dev
572 2015-11-26T19:08:06  *** ghtdak has joined #bitcoin-core-dev
573 2015-11-26T19:08:44  *** [b__b] has joined #bitcoin-core-dev
574 2015-11-26T19:09:13  *** Arnavion has joined #bitcoin-core-dev
575 2015-11-26T19:09:58  *** instagibbs has joined #bitcoin-core-dev
576 2015-11-26T19:10:15  *** btcdrak has joined #bitcoin-core-dev
577 2015-11-26T19:11:09  *** Guest1235 has joined #bitcoin-core-dev
578 2015-11-26T19:11:09  *** warren has joined #bitcoin-core-dev
579 2015-11-26T19:11:09  *** paveljanik has joined #bitcoin-core-dev
580 2015-11-26T19:11:09  *** Guyver2 has joined #bitcoin-core-dev
581 2015-11-26T19:11:09  *** wangchun has joined #bitcoin-core-dev
582 2015-11-26T19:11:09  *** isis has joined #bitcoin-core-dev
583 2015-11-26T19:11:09  *** PaulCapestany has joined #bitcoin-core-dev
584 2015-11-26T19:11:09  *** da2ce7_ has joined #bitcoin-core-dev
585 2015-11-26T19:11:09  *** kanzure has joined #bitcoin-core-dev
586 2015-11-26T19:11:09  *** gmaxwell has joined #bitcoin-core-dev
587 2015-11-26T19:11:09  *** arubi has joined #bitcoin-core-dev
588 2015-11-26T19:11:09  *** alpalp has joined #bitcoin-core-dev
589 2015-11-26T19:11:09  *** BananaLotus has joined #bitcoin-core-dev
590 2015-11-26T19:11:32  *** tripleslash has joined #bitcoin-core-dev
591 2015-11-26T19:13:08  *** Amnez777 has joined #bitcoin-core-dev
592 2015-11-26T19:13:18  *** warren is now known as Guest26532
593 2015-11-26T19:14:50  *** go1111111 has joined #bitcoin-core-dev
594 2015-11-26T19:14:51  *** jcorgan has joined #bitcoin-core-dev
595 2015-11-26T19:14:51  *** michagogo has joined #bitcoin-core-dev
596 2015-11-26T19:14:51  *** pkthebud has joined #bitcoin-core-dev
597 2015-11-26T19:14:51  *** petertodd has joined #bitcoin-core-dev
598 2015-11-26T19:14:51  *** phantomcircuit has joined #bitcoin-core-dev
599 2015-11-26T19:14:51  *** sipa has joined #bitcoin-core-dev
600 2015-11-26T19:14:51  *** wumpus has joined #bitcoin-core-dev
601 2015-11-26T19:14:51  *** Ylbam has joined #bitcoin-core-dev
602 2015-11-26T19:14:51  *** midnightmagic has joined #bitcoin-core-dev
603 2015-11-26T19:14:51  *** blkdb has joined #bitcoin-core-dev
604 2015-11-26T19:14:51  *** zmanian_ has joined #bitcoin-core-dev
605 2015-11-26T19:14:51  *** s1w has joined #bitcoin-core-dev
606 2015-11-26T19:15:16  *** Amnez777 has quit IRC
607 2015-11-26T19:15:16  *** Amnez777 has joined #bitcoin-core-dev
608 2015-11-26T19:15:17  *** gribble has joined #bitcoin-core-dev
609 2015-11-26T19:16:20  *** dermoth has joined #bitcoin-core-dev
610 2015-11-26T19:20:15  *** morcos_ has joined #bitcoin-core-dev
611 2015-11-26T19:20:48  *** d_t has joined #bitcoin-core-dev
612 2015-11-26T19:26:52  *** Arnavion has quit IRC
613 2015-11-26T19:26:54  *** d_t_ has quit IRC
614 2015-11-26T19:26:54  *** AtashiCon has quit IRC
615 2015-11-26T19:26:54  *** evoskuil has quit IRC
616 2015-11-26T19:26:54  *** evoskuil has joined #bitcoin-core-dev
617 2015-11-26T19:27:25  *** morcos has quit IRC
618 2015-11-26T19:27:25  *** raedah has quit IRC
619 2015-11-26T19:27:25  *** lecusemb1e has quit IRC
620 2015-11-26T19:27:25  *** Thireus has quit IRC
621 2015-11-26T19:27:40  *** Arnavion has joined #bitcoin-core-dev
622 2015-11-26T19:27:40  *** lecusemble has joined #bitcoin-core-dev
623 2015-11-26T19:28:26  *** Eliel has joined #bitcoin-core-dev
624 2015-11-26T19:29:36  *** harding_ has quit IRC
625 2015-11-26T19:29:36  *** MarcoFalke has quit IRC
626 2015-11-26T19:30:12  *** cocoBTC has quit IRC
627 2015-11-26T19:30:12  *** dermoth has quit IRC
628 2015-11-26T19:30:13  *** arowser has quit IRC
629 2015-11-26T19:30:30  *** tripleslash_b has joined #bitcoin-core-dev
630 2015-11-26T19:30:31  *** raedah has joined #bitcoin-core-dev
631 2015-11-26T19:33:47  *** [1]evoskuil has joined #bitcoin-core-dev
632 2015-11-26T19:34:45  *** lclc_ has joined #bitcoin-core-dev
633 2015-11-26T19:35:06  *** evoskuil has quit IRC
634 2015-11-26T19:35:06  *** [1]evoskuil is now known as evoskuil
635 2015-11-26T19:36:20  *** lecusemble has quit IRC
636 2015-11-26T19:38:13  *** sdaftuar_ has joined #bitcoin-core-dev
637 2015-11-26T19:39:01  *** tripleslash has quit IRC
638 2015-11-26T19:39:01  *** [b__b] has quit IRC
639 2015-11-26T19:39:01  *** lclc has quit IRC
640 2015-11-26T19:39:01  *** sdaftuar has quit IRC
641 2015-11-26T19:39:02  *** teward has quit IRC
642 2015-11-26T19:39:02  *** cfields_ has quit IRC
643 2015-11-26T19:39:02  *** bsm1175321 has quit IRC
644 2015-11-26T19:39:16  *** cfields has joined #bitcoin-core-dev
645 2015-11-26T19:42:37  *** teward has joined #bitcoin-core-dev
646 2015-11-26T19:43:23  *** JackH has quit IRC
647 2015-11-26T19:44:05  *** cocoBTC has joined #bitcoin-core-dev
648 2015-11-26T19:47:08  *** harding has joined #bitcoin-core-dev
649 2015-11-26T19:49:20  *** lecusemble has joined #bitcoin-core-dev
650 2015-11-26T19:50:33  *** dermoth has joined #bitcoin-core-dev
651 2015-11-26T19:50:38  *** tripleslash has joined #bitcoin-core-dev
652 2015-11-26T19:51:52  *** davec has quit IRC
653 2015-11-26T19:52:41  *** tripleslash_b has quit IRC
654 2015-11-26T19:52:41  *** cfields has quit IRC
655 2015-11-26T19:52:41  *** evoskuil has quit IRC
656 2015-11-26T19:52:45  *** evoskuil has joined #bitcoin-core-dev
657 2015-11-26T19:55:27  *** cfields has joined #bitcoin-core-dev
658 2015-11-26T19:56:42  *** bsm117532 has joined #bitcoin-core-dev
659 2015-11-26T19:57:52  *** BlueMatt_ has quit IRC
660 2015-11-26T20:02:17  *** BlueMatt has joined #bitcoin-core-dev
661 2015-11-26T20:04:49  *** davec has joined #bitcoin-core-dev
662 2015-11-26T20:12:16  *** jonasschnelli has quit IRC
663 2015-11-26T20:13:51  *** jonasschnelli has joined #bitcoin-core-dev
664 2015-11-26T20:36:53  *** raedah has quit IRC
665 2015-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
666 2015-11-26T20:53:09  *** instagibbs_ has joined #bitcoin-core-dev
667 2015-11-26T20:57:15  *** dermoth has quit IRC
668 2015-11-26T20:57:15  *** instagibbs has quit IRC
669 2015-11-26T20:59:53  *** dermoth has joined #bitcoin-core-dev
670 2015-11-26T21:00:18  *** Thireus has joined #bitcoin-core-dev
671 2015-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
672 2015-11-26T21:36:17  *** randy-waterhouse has joined #bitcoin-core-dev
673 2015-11-26T21:38:23  *** d_t has quit IRC
674 2015-11-26T21:41:47  *** go1111111 has quit IRC
675 2015-11-26T21:50:16  *** ParadoxSpiral_ has quit IRC
676 2015-11-26T22:08:34  *** BashCo has joined #bitcoin-core-dev
677 2015-11-26T22:09:10  *** go1111111 has joined #bitcoin-core-dev
678 2015-11-26T22:11:48  *** JackH has joined #bitcoin-core-dev
679 2015-11-26T22:13:46  *** go1111111 has quit IRC
680 2015-11-26T22:19:00  <cocoBTC> Should QT commits be tagged [Qt], or is there any convention there?
681 2015-11-26T22:20:45  *** Guyver2 has quit IRC
682 2015-11-26T22:22:33  *** MarcoFalke has joined #bitcoin-core-dev
683 2015-11-26T22:31:21  *** MarcoFalke has quit IRC
684 2015-11-26T22:32:50  *** JackH has quit IRC
685 2015-11-26T22:38:32  *** alpalp has quit IRC
686 2015-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
687 2015-11-26T22:51:21  *** michagogo has quit IRC
688 2015-11-26T22:51:29  *** d_t has joined #bitcoin-core-dev
689 2015-11-26T22:54:42  *** Squidicuz has joined #bitcoin-core-dev
690 2015-11-26T23:09:46  *** JackH has joined #bitcoin-core-dev
691 2015-11-26T23:19:11  *** michagogo has joined #bitcoin-core-dev
692 2015-11-26T23:27:24  *** lclc_ is now known as lclc
693 2015-11-26T23:33:27  *** Guest22577 has quit IRC
694 2015-11-26T23:33:42  *** Anduck has joined #bitcoin-core-dev
695 2015-11-26T23:34:04  *** Anduck is now known as Guest39247
696 2015-11-26T23:35:28  *** Guest39247 has quit IRC
697 2015-11-26T23:36:05  *** Anduck_ has joined #bitcoin-core-dev
698 2015-11-26T23:50:17  *** sipa has quit IRC
699 2015-11-26T23:50:17  *** sipa has joined #bitcoin-core-dev
700 2015-11-26T23:51:36  *** cfields_ has joined #bitcoin-core-dev
701 2015-11-26T23:54:13  *** michagogo has quit IRC
702 2015-11-26T23:54:14  *** cfields has quit IRC
703 2015-11-26T23:54:14  *** evoskuil has quit IRC
704 2015-11-26T23:56:27  *** btcdrak has quit IRC