1 2016-03-18 00:24:06 0|GitHub136|[13bitcoin] 15pstratem opened pull request #7708: De-neuter NODE_BLOOM (06master...062016-03-17-nodebloom) 02https://github.com/bitcoin/bitcoin/pull/7708
2 2016-03-18 00:25:39 0|GitHub192|[13bitcoin] 15sdaftuar opened pull request #7709: Tests: fix missing import in mempool_packages (06master...06fix-mempool-packages-2) 02https://github.com/bitcoin/bitcoin/pull/7709
3 2016-03-18 01:54:12 0|GitHub187|[13bitcoin] 15fanquake opened pull request #7710: [Depends] Bump miniupnpc (06master...06depends-02) 02https://github.com/bitcoin/bitcoin/pull/7710
4 2016-03-18 02:17:12 0|GitHub16|[13bitcoin] 15fanquake opened pull request #7711: [build-aux] Update Boost & check macros to latest serials (06master...06build-aux-change) 02https://github.com/bitcoin/bitcoin/pull/7711
5 2016-03-18 04:19:17 0|GitHub125|[13bitcoin] 15promag opened pull request #7712: Improve COutPoint less operator (06master...06enhancement/improve-coutpoint-less-operator) 02https://github.com/bitcoin/bitcoin/pull/7712
6 2016-03-18 07:16:12 0|GitHub18|[13bitcoin] 15jonasschnelli closed pull request #6641: De-neuter NODE_BLOOM (06master...06bloom-disable) 02https://github.com/bitcoin/bitcoin/pull/6641
7 2016-03-18 07:51:07 0|GitHub197|[13bitcoin] 15laanwj pushed 7 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/f034bced269c...73b7eb501e64
8 2016-03-18 07:51:08 0|GitHub197|13bitcoin/06master 146851107 15Pieter Wuille: BIP9 Implementation...
9 2016-03-18 07:51:08 0|GitHub197|13bitcoin/06master 14732e774 15Pieter Wuille: Versionbits tests
10 2016-03-18 07:51:09 0|GitHub197|13bitcoin/06master 14d23f6c6 15Pieter Wuille: Softfork status report in RPC
11 2016-03-18 07:51:14 0|GitHub90|[13bitcoin] 15laanwj closed pull request #7575: Minimal BIP9 implementation (06master...06bip9) 02https://github.com/bitcoin/bitcoin/pull/7575
12 2016-03-18 08:08:18 0|btcdrak|\o/
13 2016-03-18 08:57:19 0|devplop|Hi, do I have to download the entire blockchain if I want to use bitcoind on my server? thanks
14 2016-03-18 08:58:11 0|jonasschnelli|devplop: yes. But you can use -prune to remove "old blocks".
15 2016-03-18 08:58:41 0|jonasschnelli|devplop but you should discuss that in #bitcoin (this is the development channel)
16 2016-03-18 09:00:41 0|devplop|thanks jonasschnelli
17 2016-03-18 09:00:43 0|devplop|But it would be on a website for user to be able to create wallet etc. this is development right?
18 2016-03-18 09:01:22 0|jonasschnelli|devplop: hmm.. not sure what you mean with that
19 2016-03-18 09:01:26 0|devplop|approximately, what percentage it remove?
20 2016-03-18 09:02:18 0|jonasschnelli|you mean -prune? It's flexible.
21 2016-03-18 09:02:23 0|devplop|I'm developping a website wich use bitcoind, this is not development? or here we only talk about developement of bitcoin itself
22 2016-03-18 09:02:55 0|devplop|ok thanks, do you know a place I can find a documentation about this?
23 2016-03-18 09:03:06 0|jonasschnelli|This channel is for bitcoin-core development only. You can use #bitcoin-dev
24 2016-03-18 09:03:27 0|jonasschnelli|devplop: theres is a dev. documentation on bitcoin.org
25 2016-03-18 09:04:07 0|devplop|thanks again, I can't go to bitcoin-dev, where do I have to register?
26 2016-03-18 09:04:49 0|jonasschnelli|Just join the channel #bitcoin-dev ?
27 2016-03-18 09:05:17 0|devplop|#bitcoin-dev Cannot join channel (+r) - you need to be identified with services
28 2016-03-18 09:06:24 0|jonasschnelli|There are plenty user in this channel,.. you might face a local IRC issue.
29 2016-03-18 09:06:44 0|devplop|ok thanks
30 2016-03-18 09:17:10 0|btcdrak|devplop: you have to use /nickserv help
31 2016-03-18 10:04:23 0|wumpus|paveljanik: don't forget to create an issue for the Qt 5.8 support (what changed in qt 5.8, what error you now get, etc)
32 2016-03-18 10:09:34 0|GitHub57|13bitcoin/06master 14e38781d 15Suhas Daftuar: Tests: fix missing import in mempool_packages
33 2016-03-18 10:09:34 0|GitHub57|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/73b7eb501e64...efde86b4aae6
34 2016-03-18 10:09:35 0|GitHub57|13bitcoin/06master 14efde86b 15Wladimir J. van der Laan: Merge #7709: Tests: fix missing import in mempool_packages...
35 2016-03-18 10:09:44 0|GitHub113|[13bitcoin] 15laanwj closed pull request #7709: Tests: fix missing import in mempool_packages (06master...06fix-mempool-packages-2) 02https://github.com/bitcoin/bitcoin/pull/7709
36 2016-03-18 10:10:03 0|paveljanik|wumpus, I thought you do not want to see "reminder" issues ;-)
37 2016-03-18 10:10:07 0|paveljanik|ok, ok, will do.
38 2016-03-18 10:10:08 0|paveljanik|:-)
39 2016-03-18 10:10:27 0|wumpus|paveljanik: but right now I'm confused about what the problem is
40 2016-03-18 10:10:55 0|wumpus|a build failure with a new version of a dependency seems a good reason to open an issue, anyhow
41 2016-03-18 10:11:16 0|wumpus|so is this on every platform or just say, OS X?
42 2016-03-18 10:11:49 0|paveljanik|I'll collect everything and create an issue, in ~1 hour.
43 2016-03-18 10:11:54 0|wumpus|thanks!
44 2016-03-18 10:12:12 0|paveljanik|lunch now :-)
45 2016-03-18 10:19:32 0|GitHub11|[13bitcoin] 15petertodd opened pull request #7713: Fixes for verify-commits script (06master...062016-03-fix-verify-commits) 02https://github.com/bitcoin/bitcoin/pull/7713
46 2016-03-18 10:35:45 0|paveljanik|#7714: Build with Qt 5.6 not supported
47 2016-03-18 10:37:12 0|wumpus|paveljanik: ah, so this seems OS X-focused
48 2016-03-18 10:37:22 0|wumpus|upstream issue explicitly mentions "frameworks"
49 2016-03-18 10:37:59 0|paveljanik|maybe. But the similar problem was reported by kwin people. So I think it is generic.
50 2016-03-18 10:38:07 0|paveljanik|will download other OS binary to see.
51 2016-03-18 10:38:35 0|jonasschnelli|missing .pc file will probably break all platforms?!
52 2016-03-18 10:39:18 0|wumpus|well the .pc files were broken on MacOSX in some cases, maybe they've removed them because of that
53 2016-03-18 10:39:26 0|paveljanik|maybe they are missing on OS X only. Do not know. I'm checking Linux now.
54 2016-03-18 10:39:36 0|wumpus|I would be really surpised (and disappointed) if they removed them on unix/linux
55 2016-03-18 10:39:49 0|wumpus|there's not really a replacement for pkgconfig on linux
56 2016-03-18 10:40:16 0|paveljanik|they probably expect projects to use cmake and their files.
57 2016-03-18 10:40:19 0|wumpus|(well ok, manually specifying all the directories)
58 2016-03-18 10:40:30 0|wumpus|cmake uses pkgconfig too IIRCI
59 2016-03-18 10:40:54 0|wumpus|cmake is just an autoconf replacement, it doesn't replace pkg-config
60 2016-03-18 10:41:48 0|paveljanik|OMG 661MB...
61 2016-03-18 10:41:56 0|wumpus|pkg-config is not part of any specific make system, it is just linux's way of locating development headers and libraries, OS X has this 'framework' system instead
62 2016-03-18 10:43:25 0|wumpus|paveljanik: make sure you download qtbase not the full thing, it's crazy - it's said it contains three copies of webkit, and many other ballast: https://twitter.com/whitequark/status/700583315254829057
63 2016-03-18 10:43:50 0|paveljanik|nevermind, already downloaded 8)
64 2016-03-18 10:44:31 0|paveljanik|hmm: qt-opensource-linux-x64-5.6.0.run: ELF ;-)
65 2016-03-18 10:44:50 0|paveljanik|so it has to be run in the VM
66 2016-03-18 10:44:56 0|paveljanik|it will take longer
67 2016-03-18 10:50:40 0|paveljanik|it needs X to install or Linux build env which I do not have readily available from here now :-(
68 2016-03-18 11:01:25 0|paveljanik|later
69 2016-03-18 11:03:58 0|wumpus|paveljanik: someone else can do it
70 2016-03-18 11:04:20 0|wumpus|paveljanik: btw, are you able to build if you manually specify all the library and header paths using the appropriate configure settings?
71 2016-03-18 11:04:47 0|paveljanik|bash command line too long I guess ;-)
72 2016-03-18 11:04:59 0|paveljanik|https://codereview.qt-project.org/gitweb?p=qt/qtbase.git;a=commitdiff;h=6c5d227da1709eb81968823f38a133747c0e95b0
73 2016-03-18 11:04:59 0|paveljanik|The change in qt is:
74 2016-03-18 11:05:22 0|paveljanik|so I guess that on "unix"/mingw, it will be OK.
75 2016-03-18 11:05:39 0|paveljanik|have to leave now, sorry. Will be back later today.
76 2016-03-18 11:24:15 0|GitHub16|13bitcoin/06master 14fa4a522 15MarcoFalke: [qa] Add tests verifychain, lockunspent, getbalance, listsinceblock
77 2016-03-18 11:24:15 0|GitHub16|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/efde86b4aae6...29e1131c4642
78 2016-03-18 11:24:16 0|GitHub16|13bitcoin/06master 1429e1131 15Wladimir J. van der Laan: Merge #7702: [qa] Add tests verifychain, lockunspent, getbalance, listsinceblock...
79 2016-03-18 11:24:25 0|GitHub162|[13bitcoin] 15laanwj closed pull request #7702: [qa] Add tests verifychain, lockunspent, getbalance, listsinceblock (06master...06Mf1603-qaCleanup2) 02https://github.com/bitcoin/bitcoin/pull/7702
80 2016-03-18 11:52:22 0|qwebirc646325|does anyone know if its possible to fork bitcoin to createe a new coin with support for sending 1 satoshi
81 2016-03-18 12:03:35 0|qwebirc646325|or if a fork could elimnate transaction fees
82 2016-03-18 12:09:44 0|wumpus|qwebirc646325: altcoins can make whatever change they want
83 2016-03-18 12:10:39 0|wumpus|although both examples you meantion aren't even consensus rules. Any miner could accept transactions of one satoshi, or accept transactions without fee (some even do).
84 2016-03-18 12:10:42 0|qwebirc646325|great
85 2016-03-18 12:11:44 0|qwebirc646325|how much needs to be changed in the source to create an altcoin
86 2016-03-18 12:11:54 0|wumpus|this is not the place for altcoin questions
87 2016-03-18 12:12:05 0|btcdrak|##altcoin-dev
88 2016-03-18 12:19:02 0|JackH|come on guys, the altcoin might become the biggest thing ever!
89 2016-03-18 12:19:14 0|JackH|you dont know what you are missing out on
90 2016-03-18 12:25:42 0|wumpus|hah
91 2016-03-18 12:27:14 0|JackH|nice on BIP9 btw :)
92 2016-03-18 13:00:33 0|morcos|gmaxwell: wumpus: sipa: sorry for being a pest, but I would like some direction on this getbalance mess. does one of you want to talk it through with me?
93 2016-03-18 13:02:33 0|wumpus|morcos: at least ignore the accounts stuff
94 2016-03-18 13:02:42 0|wumpus|yes, balances can be off with accounts, we know that
95 2016-03-18 13:02:59 0|sipa|morcos: i've been thinking about it
96 2016-03-18 13:03:09 0|sipa|and i wonder how it was really ever intended to work
97 2016-03-18 13:03:18 0|morcos|wumpus: well. that would lead to us not actually solving the problem that Cocodude first brought to us
98 2016-03-18 13:03:28 0|sipa|wumpus: it's not that simple
99 2016-03-18 13:03:41 0|morcos|also i'm most concerned by the fact that the account balances are what is used for sendfrom and sendmany
100 2016-03-18 13:03:59 0|sipa|morcos: ??
101 2016-03-18 13:04:14 0|sipa|wumpus: the account balance calculation is very strongly related to the computation of transaction 'effects' (which is what listtransactions lists)
102 2016-03-18 13:04:15 0|morcos|those functions get the available balance by calling GetAccountBalance
103 2016-03-18 13:04:21 0|sipa|what?
104 2016-03-18 13:04:23 0|wumpus|I don't think so, the send functions allow balances to go negative
105 2016-03-18 13:04:31 0|wumpus|(account balances)
106 2016-03-18 13:05:19 0|sipa|morcos: ... you're right, i thought that was changed in... 0.3.x
107 2016-03-18 13:05:49 0|morcos|my proposal was to just special case check if the given account is "" and then not use GetAccountBalance
108 2016-03-18 13:05:54 0|wumpus|people are finally looking at the wallet code in detail, that's good to hear :)
109 2016-03-18 13:06:02 0|morcos|but this is getting to be an invasive change for a point release
110 2016-03-18 13:06:21 0|wumpus|yes, try to solve it for master at least
111 2016-03-18 13:06:26 0|sipa|any correct solution is going to result in the account balances being correct anyway
112 2016-03-18 13:06:36 0|morcos|sipa: or removing accounts?
113 2016-03-18 13:06:38 0|sipa|if you can't get account balances right, listtransactions will also be wrong
114 2016-03-18 13:06:50 0|sipa|because they use the same code
115 2016-03-18 13:06:56 0|wumpus|maybe it's just too much of a change for a point release, that's a fair conclusion
116 2016-03-18 13:07:00 0|morcos|what do you mean by listtransactions being wrong?
117 2016-03-18 13:07:44 0|morcos|wumpus: well the problem is we probably ought to do something. there is a problem in the released code now. its a matter of deciding what we should do for 0.12.1. then there is a second question of what we should do for master.
118 2016-03-18 13:08:13 0|morcos|are we at the point where we can remove accounts? if so, that is what we should do for master, b/c anything else is just a recipe for further problems down the road
119 2016-03-18 13:08:49 0|wumpus|yes, we should definitely remove account balances
120 2016-03-18 13:08:51 0|morcos|to be honest, i'm not really interested in taking the time to understand the accounting system well enough to try to make it work properly. (since i don't believe its something we want to long term support)
121 2016-03-18 13:09:06 0|wumpus|people use other account functionality (e.g. they use them as labels)
122 2016-03-18 13:09:25 0|wumpus|but the balance logic is incorrect and dangerous
123 2016-03-18 13:10:15 0|morcos|wumpus: so my suggestion is if you don't really intend to be using account balances but you just are b/c thats the only way to get the total sum balance, then we should instead make you not use account balances
124 2016-03-18 13:10:24 0|morcos|this exists in at least 3 places now
125 2016-03-18 13:10:24 0|sipa|morcos: there are two ways to look at the wallet; 1) as a set of utxos 2) as a sequence of balance updates
126 2016-03-18 13:11:13 0|morcos|1) getbalance (where you want to specify a confirm requirement you have to fill in an account argument), sendfrom, sendmany
127 2016-03-18 13:11:22 0|morcos|sorry, that was all 3
128 2016-03-18 13:11:47 0|sipa|morcos: effectively, you either iterate over the transactions to find which of its outputs are available
129 2016-03-18 13:12:05 0|sipa|morcos: or you iterate over transactions to see which utxos they add/remove
130 2016-03-18 13:12:18 0|sipa|the first is used by listunspent and getbalance "*"
131 2016-03-18 13:12:31 0|sipa|the second is used by listtransactions and getbalance acc
132 2016-03-18 13:12:41 0|morcos|sipa: yes, but i think thinking of it as a sequence of balance updates is fairly complicated when sometimes you want things to count for reducing your balance but not for adding to it. (in the case of unconfirmed txs)
133 2016-03-18 13:13:17 0|morcos|sipa: actually getbalance "*" is more similar (but a separate code path) to getbalance acc i think
134 2016-03-18 13:14:17 0|sipa|morcos: my point is that if you can't compute balance updates correctly, listtransactions will be wrong
135 2016-03-18 13:14:34 0|sipa|because listtransactions does not list transactions, but balance updates caused by transactioms
136 2016-03-18 13:15:26 0|sturles|At least some people use accounts. If you remove accounts in the segwit release, it may impact the upgrade speed negatively. E.g. I will have to code an entirely new solution for my system before I can use a version without accounts.
137 2016-03-18 13:15:48 0|morcos|sipa: i'm not sure i understand still. i think it'll list all the balance updates as you say. what it won't do is provide you an intelligent way to add them up to arrive at something meaningful
138 2016-03-18 13:16:04 0|morcos|but i think each individual one would make some kind of sense depending on how you look at it
139 2016-03-18 13:16:41 0|morcos|the question comes when you are trying to decide whether you want to count the balance update in your total or not, but with listtransactions, you don't have to make that choice
140 2016-03-18 13:16:46 0|wumpus|sturles: I'm talking about removing account balances, not remove all the account related RPCs
141 2016-03-18 13:17:06 0|sipa|sturles: those are independent; if we make any meaningful changes to the account system, it will be in a major release and not backported
142 2016-03-18 13:17:10 0|morcos|sturles: yes we wouldn't remove accounts for segwit release, that would be for a major version
143 2016-03-18 13:17:15 0|sipa|sturles: consensus changes like segwit are always backported
144 2016-03-18 13:17:16 0|wumpus|account balances are unreliable, the other parts are not.
145 2016-03-18 13:18:17 0|morcos|sipa: did that make sense what i just said? i'm not sure what you think will be "wrong" about listtransactions
146 2016-03-18 13:18:34 0|sipa|morcos: both use CWallet::GetAmounts
147 2016-03-18 13:19:15 0|morcos|yes, but i think the problem is in the filtering of whats returned from GetAmounts and listtransactions doens't filter it
148 2016-03-18 13:19:26 0|sipa|hmm
149 2016-03-18 13:19:28 0|sipa|ok
150 2016-03-18 13:19:46 0|sipa|but we have so many different states a transaction can be in
151 2016-03-18 13:19:46 0|sturles|Much of my system relies on account balances beeing correct. :-/
152 2016-03-18 13:20:07 0|sturles|Account balances have always been reliable for me.
153 2016-03-18 13:20:12 0|wumpus|that's very dangerous
154 2016-03-18 13:20:23 0|sipa|wumpus: i think account balances are perfectly well defined
155 2016-03-18 13:20:27 0|morcos|sturles: i think it had some broken behavior in 0.11 and it has some other broken behavior in 0.12
156 2016-03-18 13:20:34 0|wumpus|sipa: I've heard otherwise
157 2016-03-18 13:20:37 0|sturles|Oh?
158 2016-03-18 13:20:47 0|wumpus|sipa: I certainly wouldn't recommend anyone to rely on them
159 2016-03-18 13:20:49 0|sipa|they have unexpected behaviour wrt unconfirmed transactions
160 2016-03-18 13:20:50 0|sturles|Is there a bug report I can read?
161 2016-03-18 13:21:11 0|wumpus|the thing is, no one really understands it, it's just too messy
162 2016-03-18 13:21:16 0|midnightmagic|Before I retired it, I had a wallet where almost all the accounts had negative balances.
163 2016-03-18 13:21:19 0|morcos|wumpus: +1
164 2016-03-18 13:21:24 0|wumpus|did you read the convo between morcos and sipa above?
165 2016-03-18 13:21:51 0|wumpus|those are two long-term developers, who have worked on the code for a long time, and they're surprised about how some of the account things work - doesn't that say enough?
166 2016-03-18 13:22:19 0|sipa|i think we should go over the possible states a transaction can be in, and think about what their effect on listtransactions, listunspent, and getbalance should be (independent from accounts)
167 2016-03-18 13:22:52 0|wumpus|the problem is also that whatever broken behavior accounts have, people may be relying on it, even if it's unknown to us
168 2016-03-18 13:23:00 0|sipa|1) confirmed 2) unconfirmed but in mempool 3) unconfirmed not in mempool 4) unconfirmed not in mempool, abandoned 5) unconfirmed not in mempool, known to conflict
169 2016-03-18 13:23:02 0|morcos|sipa: ok. are you narrowing the discussion to differences in behavior between 0.11 and 0.12?
170 2016-03-18 13:23:30 0|sturles|I can't say I understand how the code works, but I do understand how accoutns work. Negative balances are not a problem. I use negative balances as well, in my accounting.
171 2016-03-18 13:23:37 0|wumpus|sturles: see also https://github.com/bitcoin/bitcoin/issues/3816
172 2016-03-18 13:24:04 0|sipa|morcos: no, i first want to know what we think the ideal behaviour should be
173 2016-03-18 13:24:05 0|morcos|sipa: and when you say getbalance, you have to refer to what arguments you are using. btw, there is also getunconfirmedbalance
174 2016-03-18 13:24:07 0|wumpus|and I'm sure there is previous discussion
175 2016-03-18 13:24:27 0|sipa|morcos: ok, so we should treat those separately
176 2016-03-18 13:24:31 0|sipa|also, there is immature
177 2016-03-18 13:24:39 0|morcos|sipa: well i'm just trying to avoid the rabbit hole of trying to fix accounts perfectly. i htink a better goal is to avoid regressions, and work towards removing accounts
178 2016-03-18 13:24:44 0|sipa|and non-final
179 2016-03-18 13:24:48 0|wumpus|morcos: +1
180 2016-03-18 13:24:51 0|sipa|morcos: i'm not trying to fix accounts
181 2016-03-18 13:25:05 0|midnightmagic|sturles: The wallet in my case had a total balance adding the accounts up, to a value different than the listunspent returned.
182 2016-03-18 13:25:09 0|sturles|wumpus: Yes, malleability issues messed with my accounting as well back in 2014, but I didn't have the problem during the last malleability attack where someone changed lots of transactions.
183 2016-03-18 13:25:29 0|sipa|morcos: i want to know what we think the correct behaviour should be for those different types of transactions, on listunspent, getbalance, getunconfirmedbalance, listtransactions
184 2016-03-18 13:25:34 0|sturles|midnightmagic: OK, I can't explain that.
185 2016-03-18 13:25:37 0|sipa|no account-related calls in that list
186 2016-03-18 13:25:46 0|wumpus|midnightmagic: yes that was quite common at a certain point
187 2016-03-18 13:25:48 0|morcos|ok, so if you don't want to worry about calling getbalance("", n) or getbalance("*", n) or what gets used in sendfrom, sendmany, then i don't think its that hard
188 2016-03-18 13:25:57 0|sturles|midnightmagic: Some transaction cleaned out (abandoned) perhaps?
189 2016-03-18 13:26:17 0|wumpus|the account system has pretty much been unmaintained from 2011-2012 or so
190 2016-03-18 13:26:55 0|morcos|the thing we discovered yesterday, was that tx type 5 in your list above is not necessarily distinguishable from tx type 3
191 2016-03-18 13:26:59 0|midnightmagic|gmax tried to help me debug it, but at some point I abandoned the code and that wallet and rebuilt everything and respent it. Still not more than 95% sure I swept it all up.
192 2016-03-18 13:28:06 0|sipa|morcos: yes, i know
193 2016-03-18 13:28:09 0|morcos|this is a crap ton of stuff to write up. i think i can do that reasonably well for 0.11, 0.12 and proposed fix
194 2016-03-18 13:28:20 0|sipa|morcos: so presumably we want to treat 3 and 5 the same, apart from reporting
195 2016-03-18 13:28:29 0|morcos|great. agreed with that
196 2016-03-18 13:28:34 0|wumpus|yes
197 2016-03-18 13:28:44 0|sipa|... which means that the introduction of 5 was maybe overkill
198 2016-03-18 13:29:07 0|sipa|though i guess it can be useful for example for the gui to be able to suggest abandoning
199 2016-03-18 13:29:12 0|morcos|oh wait, sorry
200 2016-03-18 13:29:22 0|morcos|i don't actually agree we treat them the same
201 2016-03-18 13:29:40 0|wumpus|sipa: in some cases you may also want to treat transactions that you sent yourself differently from received ones
202 2016-03-18 13:29:52 0|morcos|exactly
203 2016-03-18 13:30:16 0|morcos|if you are considering whether your inputs are spent. 3) considers them spent, 5) doesn't
204 2016-03-18 13:30:17 0|wumpus|(I miss that in the list, but maybe that's a cartesian product)
205 2016-03-18 13:30:35 0|morcos|sorry whether your available coins are spent
206 2016-03-18 13:30:55 0|morcos|if you are considering whether you have new available coins to spend 3) and 5) should both be no you don't
207 2016-03-18 13:31:02 0|wumpus|e.g. the wallet could create a transaction, but you have wallet broadcasting disabled
208 2016-03-18 13:31:26 0|wumpus|you'd still want it to subtract from your balance and hold the inputs, at least until abandoned
209 2016-03-18 13:31:39 0|morcos|yes
210 2016-03-18 13:32:56 0|morcos|let me write all that up in detail, i can do that. what i want to know is a proposed solution for getbalance("", n), sendfrom, sendmany ? in particular the problem reported to us was a result of getbalance("",0)
211 2016-03-18 13:33:13 0|wumpus|in any case, making all of this consistent is too much for a point release, this would be something for a major release (+mention in release notes)
212 2016-03-18 13:34:10 0|sipa|sturles, midnightmagic: since you guys use/used the account system, were you relying on sendfrom/sendmany failing when you send from an account with a too low balance?
213 2016-03-18 13:34:56 0|morcos|wumpus: actually the code changes are going to be small. probably just the first commit on 7706, plus potentially this question of skipping account accounting and using global balances when the account is "" in those 3 rpc calls
214 2016-03-18 13:35:48 0|sturles|sipa: I did at some point, but not now.
215 2016-03-18 13:36:31 0|sipa|that's the one thing that surprises me today, finding out that they do a balance check
216 2016-03-18 13:36:51 0|sipa|because there are several other ways in which account balances can ge negative without any protection
217 2016-03-18 13:37:29 0|sturles|Yep, especially the "" account.
218 2016-03-18 13:37:37 0|morcos|sipa: oh, that hadn't occurred to me, that it wasn't important
219 2016-03-18 13:37:40 0|sturles|Otherwise it is mostly due to fees.
220 2016-03-18 13:38:33 0|sipa|morcos: well, maybe it is, and i just don't know!
221 2016-03-18 13:38:50 0|morcos|well that makes things a lot easier, then i would suggest we don't change anything other than the first commit in 7706 and we can tell people that if they want total unconfirmed balance they should call getbalance() + getunconfirmedbalance() and not use getbalance("", 0)
222 2016-03-18 13:39:28 0|morcos|that would make me happy. minimal changes.
223 2016-03-18 13:40:11 0|sipa|morcos: it was an intentional change at some point very long ago (i believe in the 0.3.2x days), to not protect against account balances going negative, because it wasn't even possible
224 2016-03-18 13:40:31 0|morcos|its only through my stupidity in not knowing how getbalance("", 0) works that we even realized there is a problem in the wallet.cpp getunconfirmed balance code.
225 2016-03-18 13:40:58 0|midnightmagic|sipa: I've been using only the rawtx interface for too long to remember my use of accounts. gmax told me early on to stop using it. i was lazy and never cared if the send* failed or not for whatever reason. post-accounting aggregation has never been a concern for me. :-( Sorry man.
226 2016-03-18 13:41:25 0|sipa|morcos: for example, the move RPC has a 'minconf' argument that is ignored
227 2016-03-18 13:41:42 0|morcos|yeah i didn't even realize that RPC existed until yesterday
228 2016-03-18 13:41:56 0|sipa|morcos: it used to check whether there was enough balance in the account being moved from, at the given confirmation level
229 2016-03-18 13:42:21 0|midnightmagic|sturles: my accounts went into the thousands negative
230 2016-03-18 13:43:00 0|sipa|morcos: so if there is any change we make to this, i'd say we remove that check entirely...
231 2016-03-18 13:43:16 0|morcos|so i do think there was a regression in 0.12 in how bad account balances are as a result of this business with unconfirmed txs... but maybe we should just let that be, other than communicating it
232 2016-03-18 13:43:48 0|morcos|sipa: my concern was when you weren't trying to use it for accounts! isn't the only way to sendmany to do sendmany with the "" account
233 2016-03-18 13:44:24 0|sipa|right
234 2016-03-18 13:44:27 0|sturles|You cam make the numbers negative with move as well, of course. In the millions negative.
235 2016-03-18 13:44:53 0|sipa|sturles: yeah, that's exactly what i was saying above, move and sendtoaddress don't check balance
236 2016-03-18 13:45:01 0|sipa|so why would sendfrom/sendmany?
237 2016-03-18 13:45:20 0|sturles|I have used that trick a few times, to make enough funds available in the account I was sending from. :-)
238 2016-03-18 13:46:39 0|morcos|sipa: ah ok. now i see. i was worried that sendmany with a "" account would create transaction that spent too many funds. but it won't. CreateTransaction will stop it.
239 2016-03-18 13:46:50 0|sturles|I see no reason why sendmany or sendfrom should check the balance of an account, but make sure to make a strong note of it in the release notes..
240 2016-03-18 13:47:05 0|morcos|thats why i was concerned about it.
241 2016-03-18 13:47:53 0|sturles|Alternatively make it an option to check the balance.
242 2016-03-18 13:48:33 0|sipa|sturles: which is called getbalance :)
243 2016-03-18 13:48:43 0|morcos|I think we should just make minimal changes and announce a removal timeline for accounts. Seems a lot for 0.13, maybe 0.14
244 2016-03-18 13:49:30 0|morcos|I'll put it in a fresh PR, so its cleaner
245 2016-03-18 13:58:35 0|GitHub7|[13bitcoin] 15morcos opened pull request #7715: Fix calculation of balances and available coins. (06master...06fixconflicts_take2) 02https://github.com/bitcoin/bitcoin/pull/7715
246 2016-03-18 13:59:01 0|GitHub85|[13bitcoin] 15morcos closed pull request #7706: [WIP] Fix calculation of balances and available coins. (06master...06fixconflicts2) 02https://github.com/bitcoin/bitcoin/pull/7706
247 2016-03-18 14:39:33 0|morcos|sipa: wumpus: ok checkout #7715, i _think_ that chart is right.
248 2016-03-18 14:39:56 0|wumpus|nice work!
249 2016-03-18 14:40:16 0|morcos|probably needs someone to make sure its right though
250 2016-03-18 14:48:49 0|btcdrak|morcos: <3 that chart
251 2016-03-18 14:55:34 0|sipa|morcos: awesome!
252 2016-03-18 14:55:56 0|sipa|(i had no idea github had so many icons...)
253 2016-03-18 14:58:59 0|morcos|I perhaps did not make it clear enough that the red triangle can't lead to bad things. In other words you won't reduce your balance for coins spent if those were coins that weren't included in your balance.
254 2016-03-18 14:59:28 0|morcos|The fearful face can I think lead to bad things though.
255 2016-03-18 15:00:08 0|sipa|morcos: use :arrow_down: instead of the red triangle?
256 2016-03-18 15:00:28 0|sipa|and :warning: for the unhappy face?
257 2016-03-18 15:01:44 0|morcos|ah, good arrow down is better, but i like the fearful face. you should be fearful!
258 2016-03-18 15:01:57 0|sipa|ok!
259 2016-03-18 15:17:09 0|wumpus|sipa: it has a crazy number of them, see http://www.emoji-cheat-sheet.com/ :)
260 2016-03-18 15:17:49 0|wumpus|(I think they originally took them from campfire, which is owned by the same company, but I may be confused)
261 2016-03-18 15:19:33 0|wumpus|the idea of them actually being useful is new and surprising to me, though, nice idea morcos
262 2016-03-18 15:31:25 0|wumpus|yes, the fearful faces are scary, why would you ever want to 'trust' unconfirmed transactions received but not those sent by yourself
263 2016-03-18 15:31:46 0|wumpus|well ok 'trust' is overstated, it only affect the *unconfirmed* balance
264 2016-03-18 15:32:07 0|wumpus|but still it seems inconsistent, if it has any effect for receiving it should also for spending
265 2016-03-18 15:32:26 0|wumpus|(or neither)
266 2016-03-18 15:33:34 0|morcos|wumpus: sure, or you could just send yourself txs over and over again and increase your balance wily-nily (i think)
267 2016-03-18 15:36:30 0|wumpus|morcos: oh no, you found a bitcoin cheat code :D
268 2016-03-18 15:38:57 0|GitHub85|[13bitcoin] 15morcos opened pull request #7716: [0.12] Backport BIP9 and softfork for BIP's 68,112,113 (060.11...06backportBIP9SoftFork) 02https://github.com/bitcoin/bitcoin/pull/7716
269 2016-03-18 15:39:24 0|morcos|oops, that was for 0.11
270 2016-03-18 15:40:18 0|wumpus|morcos: btw, non-final received transactions will never reach the wallet
271 2016-03-18 15:40:46 0|morcos|wumpus: well, almost, they could in a reorg
272 2016-03-18 15:40:53 0|wumpus|I mean they're rejected by the mempool code
273 2016-03-18 15:41:04 0|wumpus|hm right
274 2016-03-18 17:33:33 0|GitHub157|[13bitcoin] 15btcdrak closed pull request #7693: [0.11] Backport BIP112 CHECKSEQUENCEVERIFY mempool-only (060.11...06bip112-backport-0.11) 02https://github.com/bitcoin/bitcoin/pull/7693
275 2016-03-18 18:02:04 0|jtimon|now that I have a good computer...can't the rpc tests be parallelized?
276 2016-03-18 18:02:28 0|jtimon|at least for people with zmq installed or something
277 2016-03-18 18:03:26 0|jtimon|just thinking out loud, don't take this too seriously yet
278 2016-03-18 18:06:05 0|sipa|i don't see how zmq is relevant for that
279 2016-03-18 18:06:32 0|sipa|you could run multiple tests in parallel though, just running different bitcoind's in different directories side by side
280 2016-03-18 18:07:46 0|jtimon|yeah, forget about that, just that I like to use zmq for concurrency in python, sorry for bringing that up
281 2016-03-18 18:09:07 0|jtimon|to your second comment, yes, that's what I was thinking, but with -j56 instead of having to think about it, it was just a wish in the open
282 2016-03-18 18:10:13 0|jtimon|to be perfectly clear, the goal is running ```python ./qa/pull-tester/rpc-tests.py -extended -j4``` or something like that
283 2016-03-18 18:10:35 0|jtimon|but as said is just a random thought
284 2016-03-18 18:11:16 0|sipa|that sounds totally reasonable and doable
285 2016-03-18 18:11:49 0|jtimon|zmq is just the way I would support that, so totally forget about if you don't like zmq/nanomsg
286 2016-03-18 18:13:10 0|jtimon|for me, messaging is the simplest way to levereage both threads and processes transparently
287 2016-03-18 18:13:55 0|sipa|there is nothing to communicate even
288 2016-03-18 18:14:20 0|sipa|just run multiple tests at the same time, and make sure they use separate directories/ports
289 2016-03-18 18:18:31 0|jtimon|yeah, if anybody has a script that does that, please share. If I ever write it myself (which would still be prefarable to me than your "this can be done relatively easily manually"), I would do it using python and zmq, but as said that's just an irrelevant side-note
290 2016-03-18 18:19:00 0|jtimon|in the meantime python ./qa/pull-tester/rpc-tests.py -extended is not all that bad
291 2016-03-18 18:21:03 0|jtimon|anyway, just wishful comments while I learn more about our wonderful testing setup
292 2016-03-18 18:21:34 0|jtimon|rpc python testing newbie here
293 2016-03-18 18:21:41 0|jtimon|still
294 2016-03-18 18:23:40 0|jtimon|but that is good, that means unittests alone captured most of my stupid thoughts previously
295 2016-03-18 18:25:45 0|jtimon|and I have a good computer to start testing other people's things more deeply, sorry for the distraction, shouldn't think out loud here
296 2016-03-18 18:27:19 0|sipa|jtimon: i really don't understand where zmq comes in
297 2016-03-18 18:27:46 0|sipa|i'd be in favor of implememting multithreaded testing in rpc-tests.py
298 2016-03-18 18:28:14 0|sipa|using a -j flag like you suggest
299 2016-03-18 18:28:23 0|jtimon|just for concurrency, seriously, just forget about that whole part, I shouldn't have mentioned it, there's 3000 other ways to do concurrency in python
300 2016-03-18 18:28:49 0|sipa|ok :)
301 2016-03-18 18:28:52 0|jtimon|yeah, the -j option is the whole point
302 2016-03-18 18:29:23 0|sipa|but zmq is for communicating between processes, what do you expect to communicate?
303 2016-03-18 18:29:30 0|sipa|anyway, nvm :)
304 2016-03-18 18:29:52 0|sipa|if you feel like implementing it, and feel like zmq is useful for that, please do :)
305 2016-03-18 18:30:20 0|jtimon|zmq hs many use cases than you think, I think, but I'm happy that we have decoupled the topics
306 2016-03-18 18:30:43 0|jtimon|s/many/more
307 2016-03-18 18:30:57 0|jtimon|but yeah, nvm
308 2016-03-18 18:34:26 0|jtimon|I mean, if I implement it (which will depend on how often I run ./qa/pull-tester/rpc-tests.py -extended from now on) I will use that, and if anybody else does before me, the script can be written in php for all I care
309 2016-03-18 18:42:32 0|jtimon|TLDR; catching up on testing, I can't remember last time I gave a full ACK instead of just an utACK for something that wasn't obviously correct to me, oh, wait...that should never have happened, I'm virgo that way :p
310 2016-03-18 18:43:03 0|sipa|haha
311 2016-03-18 19:04:16 0|GitHub17|[13bitcoin] 15morcos closed pull request #7695: [0.11] Backport BIP 68 mempool only (060.11...0668backport) 02https://github.com/bitcoin/bitcoin/pull/7695
312 2016-03-18 19:19:58 0|btcdrak|wumpus: 7716 should be tagged consensus
313 2016-03-18 19:20:31 0|btcdrak|morcos: BIP is merged, you can send that email
314 2016-03-18 19:21:24 0|btcdrak|wumpus: 7543 also needs to be tagged consensus now
315 2016-03-18 19:48:37 0|morcos|btcdrak: email sent
316 2016-03-18 20:06:33 0|wumpus|hm this is interesting, ubuntu 16.04 doesn't install python 2 by default anymore
317 2016-03-18 20:06:49 0|wumpus|no /usr/bin/python nor /usr/bin/python2
318 2016-03-18 20:06:54 0|wumpus|this breaks 'make check'
319 2016-03-18 20:07:34 0|wumpus|it is possible to install python 2.7 using 'apt-get install python2.7` but this will only give you a /usr/bin/python2.7, no /usr/bin/python nor /usr/bin/python2...
320 2016-03-18 20:08:03 0|wumpus|this is fucking annoying as it effectively makes it possible to refer to it as interpreter at the top of scripts
321 2016-03-18 20:11:01 0|wumpus|impossible*
322 2016-03-18 20:20:56 0|btcdrak|RIP python 2
323 2016-03-18 20:22:12 0|wumpus|yea
324 2016-03-18 20:30:21 0|btcdrak|wumpus: wait, do you have a time machine? It's only 16.03 last time I looked...
325 2016-03-18 20:31:07 0|wumpus|yes, I inherited satoshi's delorean
326 2016-03-18 20:32:32 0|wumpus|(you can find beta images for ubuntu 16.04)
327 2016-03-18 20:32:39 0|sipa|damn
328 2016-03-18 20:32:48 0|sipa|ubuntu 16
329 2016-03-18 20:33:00 0|sipa|what happens to the past decade?
330 2016-03-18 20:33:14 0|sipa|i think i started using ubuntu in 2006
331 2016-03-18 20:33:32 0|wumpus|heh, me too, around 2005-2006, where goes the time
332 2016-03-18 20:33:44 0|wumpus|before that I used gentoo and before that slackware
333 2016-03-18 20:35:14 0|sipa|debian, gentoo, ubuntu here
334 2016-03-18 20:40:39 0|paveljanik|slackware, red hat, suse, os x
335 2016-03-18 20:49:06 0|Luke-Jr|kinda our fault for still using Python2..
336 2016-03-18 20:53:07 0|cfields|wumpus: yea, that's really annoying. Is there no convention for a python2/python3 shebang, at least?
337 2016-03-18 20:54:34 0|ka|http://oortr.com/ZjllYz
338 2016-03-18 21:02:58 0|btcdrak|cfields: I think you can use #!/usr/bin/env python
339 2016-03-18 21:04:09 0|sipa|btcdrak: that requires a binary named python, no?
340 2016-03-18 21:04:20 0|cfields|btcdrak: yea, looks like the convention is to use env python2/env python3. but that breaks according to wumpus's findings above
341 2016-03-18 21:30:49 0|paveljanik|ok, I have hacked Qt5.6 build on OS X.
342 2016-03-18 21:35:30 0|sipa|hey ebfull
343 2016-03-18 21:36:23 0|ebfull|how's it going sipa
344 2016-03-18 21:36:53 0|ebfull|grats on the versionbits work
345 2016-03-18 21:37:57 0|ebfull|sipa: btw look at the dates: https://github.com/bitcoin/bitcoin/pull/5220 https://github.com/bitcoin/bitcoin/pull/6954
346 2016-03-18 21:37:59 0|ebfull|told ya :D
347 2016-03-18 21:39:45 0|instagibbs|now I feel smart for writing my python tests compatible for both python2 and 3 :)
348 2016-03-18 21:44:44 0|cfields|paveljanik: nice. what'd it take?
349 2016-03-18 21:45:03 0|paveljanik|I'm now entering a few hacks into the issue, mmnt.
350 2016-03-18 21:45:05 0|paveljanik|almost done
351 2016-03-18 21:45:51 0|paveljanik|cfields, you can probably help to clean it up ;-)
352 2016-03-18 21:48:02 0|paveljanik|cfields, comment added #7714
353 2016-03-18 21:49:42 0|paveljanik|remember #5728...
354 2016-03-18 21:51:06 0|cfields|paveljanik: ah, so it's just the osx frameworks that don't ship the .pc's ?
355 2016-03-18 21:51:47 0|paveljanik|I do not have a chance to test Linux downloads or source code distro.
356 2016-03-18 21:51:54 0|sipa|ebfull: remember remember the fifth of november
357 2016-03-18 21:56:33 0|cfields|paveljanik: hmm
358 2016-03-18 21:57:38 0|paveljanik|but we can home that brew/macports will fix both parts again... Or teach Qt to do that correctly.
359 2016-03-18 21:58:57 0|sipa|ebfull: it's not the commit date nor the merge date, though; just the date the PR was submitted
360 2016-03-18 22:01:50 0|cfields|paveljanik: it's annoying that they disable the .pc that helps us find the bins...
361 2016-03-18 22:01:59 0|cfields|i wonder if they could be talked out of that part
362 2016-03-18 22:04:22 0|cfields|paveljanik: mind pasting the contents of Qt5UiTools.pc ?
363 2016-03-18 22:09:44 0|cfields|paveljanik: heh: https://github.com/Homebrew/homebrew/commit/620baaf10c957875d9d2b958343456f0d35d15fc