1 2017-12-30 05:26:44	0|bitcoin-git|13bitcoin/06master 14a3ac767 15dongsamb: Fix string concatenation to os.path.join and add exception case
  2 2017-12-30 05:26:44	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/d9fdac130a5e...a332a7d5a152
  3 2017-12-30 05:26:45	0|bitcoin-git|13bitcoin/06master 14a332a7d 15MarcoFalke: Merge #11291: Fix string concatenation to os.path.join and add exception case...
  4 2017-12-30 05:27:06	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #11291: Fix string concatenation to os.path.join and add exception case (06master...06Fix-PEP8-warnings) 02https://github.com/bitcoin/bitcoin/pull/11291
  5 2017-12-30 09:37:08	0|bitcoin-git|13bitcoin/06master 146915f93 15Wladimir J. van der Laan: doc: Update OpenBSD build instructions for 6.2...
  6 2017-12-30 09:37:08	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/a332a7d5a152...efae3663a772
  7 2017-12-30 09:37:09	0|bitcoin-git|13bitcoin/06master 14efae366 15Wladimir J. van der Laan: Merge #11984: doc: Update OpenBSD build instructions for 6.2 (cont'd)...
  8 2017-12-30 09:37:39	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11984: doc: Update OpenBSD build instructions for 6.2 (cont'd) (06master...062017_12_openbsd_build_update) 02https://github.com/bitcoin/bitcoin/pull/11984
  9 2017-12-30 09:40:42	0|fanquake|wumpus Good idea. The other two were more gui based anyways.
 10 2017-12-30 09:51:05	0|wumpus|MarcoFalke: oh no you didn't just #12026
 11 2017-12-30 09:51:07	0|gribble|https://github.com/bitcoin/bitcoin/issues/12026 | Prepare version scheme for 17.0 release by MarcoFalke · Pull Request #12026 · bitcoin/bitcoin · GitHub
 12 2017-12-30 09:51:32	0|wumpus|as if there aren't enough virtually irrelevant issues to fight about yet
 13 2017-12-30 09:52:34	0|fanquake|I tried, and failed, to redirect traffic back to where the actual discussion has already happened.
 14 2017-12-30 09:52:48	0|wumpus|yes now all the armchair devs are coming out of the woodwork
 15 2017-12-30 09:53:04	0|wumpus|my versionining scheme is better than your versioining scheme!
 16 2017-12-30 09:53:22	0|luke-jr|seems pointless to have a PR for such a trivial thing without consensus to do it
 17 2017-12-30 09:53:25	0|fanquake|Red, white or blue paint?
 18 2017-12-30 09:53:34	0|wumpus|and people reading way too much in it
 19 2017-12-30 09:53:39	0|wumpus|OH SO BITCOIN ISN'T BETA ANYMORE?
 20 2017-12-30 09:53:41	0|wumpus|whieeeee
 21 2017-12-30 09:54:00	0|fanquake|I assume this is the point everyone has been waiting for so that can actually deploy to production...
 22 2017-12-30 09:54:13	0|wumpus|unleash the monster
 23 2017-12-30 09:54:20	0|sipa|i tried to clarify things on twitter a bit... but i may have made things worse :(
 24 2017-12-30 09:54:40	0|aj|that got linked on reddit even https://www.reddit.com/r/Bitcoin/comments/7mp7md/bitcoin_core_is_preparing_planning_the_version/
 25 2017-12-30 09:54:59	0|wumpus|yes he added a disclaimer "EDIT: Obviously, this does not mean Bitcoin Core is all of a sudden less experimental than before.". Of course, such people don't read disclaimers.
 26 2017-12-30 09:55:06	0|fanquake|"While these types of posts do not get the attention they deserve" . No, they get far more attention than they deserve.
 27 2017-12-30 09:55:16	0|wumpus|they get attention
 28 2017-12-30 09:55:21	0|wumpus|while we still don't have segwit wallet
 29 2017-12-30 09:55:29	0|sipa|https://twitter.com/pwuille/status/946689982034477056
 30 2017-12-30 09:55:44	0|fanquake|sipa clearly you
 31 2017-12-30 09:56:04	0|fanquake|'ve done something wrong, thats the first tweet of yours I've seen with < 1000 hearts..
 32 2017-12-30 09:56:18	0|sipa|fanquake: it's buried deep in a thread
 33 2017-12-30 09:56:27	0|gribble|https://github.com/bitcoin/bitcoin/issues/11304 | Вообще не понимаю как установить на linux kali · Issue #11304 · bitcoin/bitcoin · GitHub
 34 2017-12-30 09:56:27	0|sipa|but hey i got some nice in-person review from BlueMatt yesterday on #11304
 35 2017-12-30 09:56:32	0|sipa|no, not on that
 36 2017-12-30 09:56:36	0|luke-jr|hmm, I kinda like that comment suggesting we aim for 1.0 at the 10 year anniversary :p
 37 2017-12-30 09:56:40	0|wumpus|I mean all these people are clamoring for TRADE SIGNALS
 38 2017-12-30 09:56:44	0|wumpus|this has nothing to do with development
 39 2017-12-30 09:57:00	0|wumpus|this is more like with alts, where the devs make a big announcement and the price is pumped
 40 2017-12-30 09:57:08	0|sipa|but hey i got some nice in-person review from BlueMatt yesterday on #11403
 41 2017-12-30 09:57:13	0|gribble|https://github.com/bitcoin/bitcoin/issues/11403 | SegWit wallet support by sipa · Pull Request #11403 · bitcoin/bitcoin · GitHub
 42 2017-12-30 09:57:29	0|wumpus|that's why they want the version number to bump. THey won't even be running bitcoin core, most probably.
 43 2017-12-30 09:57:59	0|fanquake|Better send some anti signal
 44 2017-12-30 09:58:18	0|sipa|how about we change the versioning scheme to 0.0.17?
 45 2017-12-30 09:58:23	0|luke-jr|lol
 46 2017-12-30 09:58:35	0|aj|release 18.0 without telling anyone whether it's year based or not
 47 2017-12-30 09:58:41	0|sipa|i can make the same argument
 48 2017-12-30 09:59:02	0|sipa|"I support dropping the final 0 in 0.17.0.0, as it's clearly redundant"
 49 2017-12-30 09:59:16	0|fanquake|The only thing I don't want to see are named releases.
 50 2017-12-30 09:59:19	0|wumpus|it's just pointless to argue about, sucking up developer time in arguments
 51 2017-12-30 09:59:23	0|aj|sipa: any summary on the in-person review?
 52 2017-12-30 09:59:32	0|wumpus|fanquake: lol
 53 2017-12-30 09:59:52	0|fanquake|I thought everyone at that conference was too busy hitting that red button
 54 2017-12-30 09:59:54	0|wumpus|fanquake: nonono I think I"ve read at least one post proposing those, even
 55 2017-12-30 09:59:56	0|sipa|aj: i learned that some of BlueMatt's concerns were legitimate; BlueMatt learned that some of his concerns weren't :)
 56 2017-12-30 10:00:07	0|luke-jr|let's name the next release "fanquake"
 57 2017-12-30 10:00:14	0|fanquake|please no
 58 2017-12-30 10:00:18	0|luke-jr|:p
 59 2017-12-30 10:00:24	0|sipa|(all relating to import/downgrade/restore scenarios, and nothing that a rescan with a later version can't fix)
 60 2017-12-30 10:00:41	0|midnightmagic|"complaints to fanquake"
 61 2017-12-30 10:01:05	0|sipa|wumpus: i think we should just do it, or not. i don't care either way - but letting it linger won't help
 62 2017-12-30 10:01:17	0|midnightmagic|and then just replace the name with someone random in this channel each point release
 63 2017-12-30 10:01:31	0|wumpus|sipa: I won't touch it with a 10 foot pole
 64 2017-12-30 10:01:44	0|sipa|fair
 65 2017-12-30 10:02:05	0|wumpus|I'm not going to NACK it, but let me be clear I think it's ill-advised
 66 2017-12-30 10:02:08	0|aj|wumpus: btw, i've been poking at #11862 more. if we make it so 'port=1234' only affects mainnet and you have to say '[regtest]\nport=1234' to change the regtest port (or rpcport, etc) i thought it might make sense to allow you to just say 'regtest=1 \n port=1234' without having to have the [regtest] section header. but there's a whole bunch of corner cases there that make it seem not worthwhile (and
 67 2017-12-30 10:02:09	0|aj|possibly too hard to document accurately)
 68 2017-12-30 10:02:10	0|gribble|https://github.com/bitcoin/bitcoin/issues/11862 | [concept] Network specific conf sections by ajtowns · Pull Request #11862 · bitcoin/bitcoin · GitHub
 69 2017-12-30 10:02:22	0|fanquake|Then lets just close everything, and worry about segwit wallet
 70 2017-12-30 10:02:48	0|wumpus|aj: I don't think that's worth it, no
 71 2017-12-30 10:02:55	0|aj|sipa: that sounds positive!
 72 2017-12-30 10:03:13	0|wumpus|aj: I'd prefer to make the logic simple but flexible
 73 2017-12-30 10:03:26	0|wumpus|aj: adding [regtest] header is simple to understand and parse
 74 2017-12-30 10:03:31	0|sipa|aj: i'll comment on the PR when i adress the things
 75 2017-12-30 10:03:59	0|sipa|aj: wasn't there also support for regtest.port=1234 ?
 76 2017-12-30 10:04:16	0|aj|sipa: yes, [regtest] foo=bar and regtest.foo=bar are equivalent in boost config parsing
 77 2017-12-30 10:04:29	0|wumpus|aj: most people won't even be using the test network and regtest, adding corner cases here just adds corner cases for corner cases' sake
 78 2017-12-30 10:04:38	0|wumpus|aj: if it comes for free with boost, fair enough
 79 2017-12-30 10:05:58	0|fanquake|wumpus re boost #12027 is a pretty trivial merge that removes some confusion errors from the brew install log
 80 2017-12-30 10:06:00	0|gribble|https://github.com/bitcoin/bitcoin/issues/12027 | [Docs] Remove boost --c++ flag from osx build instructions by fernandezpablo85 · Pull Request #12027 · bitcoin/bitcoin · GitHub
 81 2017-12-30 10:06:11	0|fanquake|commit message just need ammending
 82 2017-12-30 10:06:22	0|aj|wumpus: the other issue that i'm hitting now is that regtest.datadir doesn't work -- datadir is decided before the chain is selected. would be a bit more invasive (but ultimately simplify things a bit) to change that
 83 2017-12-30 10:07:02	0|wumpus|aj: yes there are tons of edge cases around precedence and order of options, with regard to the -datadir and -conf and -regtest/-testnet options
 84 2017-12-30 10:07:12	0|wumpus|aj: let's try to keep the order there the same
 85 2017-12-30 10:07:50	0|wumpus|aj: at least don't add that to the scope of the PR
 86 2017-12-30 10:08:17	0|aj|wumpus: okay, less invasive it is
 87 2017-12-30 10:08:19	0|wumpus|the current order works pretty well, you can use -conf to select a configuration and set a datadir in there, as well as a netwerk
 88 2017-12-30 10:08:36	0|wumpus|you can use -datadir to select a datadir and use the bitcoin.conf inside, which can also set a network
 89 2017-12-30 10:08:43	0|wumpus|(this is used for the tests)
 90 2017-12-30 10:09:38	0|wumpus|less invasive is better certainly as long as we don't have full test coverage for these edge cases
 91 2017-12-30 10:10:07	0|wumpus|also it would mean all kinds of scenarios would need to be re-thought
 92 2017-12-30 10:10:49	0|aj|wumpus: oh, any idea which options to make network-specific? i've got -wallet and -addnode, and https://github.com/bitcoin/bitcoin/pull/11741#issuecomment-347458820 suggested -port -bind -rpcport and -rpcbind ?
 93 2017-12-30 10:11:01	0|wumpus|fanquake: hehe closing all PRs but segwit wallet (and related things) would make a point, at least
 94 2017-12-30 10:11:47	0|wumpus|aj: I think that's a good set to start with. THe general credo would be: all options that have different default based on network.
 95 2017-12-30 10:12:02	0|aj|oh good point
 96 2017-12-30 10:12:05	0|fanquake|If GitHub had better tools for managing project "workflow" we could actually make something like that happen.
 97 2017-12-30 10:21:27	0|luke-jr|wumpus: not a positive point, IMO
 98 2017-12-30 10:21:56	0|wumpus|luke-jr: hm?
 99 2017-12-30 10:23:03	0|luke-jr|wumpus: the only point I could see from closing all PRs besides a few, would be that some people are trying to force the priority for other people.
100 2017-12-30 10:23:32	0|aj|fanquake: it's got tools you can use to make tools to manage workflows at least? did you see https://gist.github.com/ajtowns/bdc91590471559b5c73682fdfa712b15 ?
101 2017-12-30 10:23:53	0|wumpus|luke-jr: I was just kidding
102 2017-12-30 10:25:01	0|fanquake|aj No, will read through it
103 2017-12-30 10:27:39	0|wumpus|luke-jr: I think it'd be an awful idea too
104 2017-12-30 10:44:35	0|midnightmagic|you could hire a temporary transition person whose primary job would be to close all PRs, then act as a strawman you could punch the crap out of while pretending to get rid of them..
105 2017-12-30 10:47:23	0|wumpus|at some point the project will outgrow the github PR way of working in any case
106 2017-12-30 10:47:41	0|wumpus|e.g. stuff like http://blog.ffwll.ch/2017/08/github-why-cant-host-the-kernel.html
107 2017-12-30 10:47:48	0|wumpus|but we're not there yet
108 2017-12-30 10:48:02	0|wumpus|I think
109 2017-12-30 10:51:39	0|bitcoin-git|[13bitcoin] 15vajdaz opened pull request #12054: Minimize to tray functionality only on Windows (06master...06win-only-tray) 02https://github.com/bitcoin/bitcoin/pull/12054
110 2017-12-30 10:57:05	0|MarcoFalke|wumpus: Yeah, sorry about that. Someone brought it to twitter, which lead to the fights. I assumed that step was uncontroversial. But meh, better close it.
111 2017-12-30 10:57:15	0|wumpus|MarcoFalke: no, let's merge it
112 2017-12-30 10:57:34	0|wumpus|MarcoFalke: just get it over with
113 2017-12-30 10:57:53	0|meshcollider|then people can stop arguing about it yeah
114 2017-12-30 10:58:03	0|wumpus|I'm sorry for contributing to the pain around it
115 2017-12-30 10:58:24	0|luke-jr|merge what?
116 2017-12-30 10:58:42	0|wumpus|#12026
117 2017-12-30 10:58:43	0|gribble|https://github.com/bitcoin/bitcoin/issues/12026 | Prepare version scheme for 17.0 release by MarcoFalke · Pull Request #12026 · bitcoin/bitcoin · GitHub
118 2017-12-30 10:58:47	0|luke-jr|no, that's stupid
119 2017-12-30 11:00:30	0|wumpus|I mean it's clear that no one likes the current versioning scheme, and people want to change it, we're never going to agree on what to change it to, so let's go with this simple change.
120 2017-12-30 11:00:57	0|luke-jr|the current one is fine, and certainly much better than that
121 2017-12-30 11:01:11	0|wumpus|sigh
122 2017-12-30 11:01:49	0|meshcollider|its really just a number, who cares, its not symbolic of any major change, its just to save the stupid 0 at the front all the time
123 2017-12-30 11:02:02	0|wumpus|yep
124 2017-12-30 11:02:30	0|bitcoin-git|13bitcoin/06master 14faa7ecf 15MarcoFalke: Prepare version scheme for 17.0 release
125 2017-12-30 11:02:30	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/efae3663a772...db7eba6169b6
126 2017-12-30 11:02:31	0|bitcoin-git|13bitcoin/06master 14db7eba6 15Wladimir J. van der Laan: Merge #12026: Prepare version scheme for 17.0 release...
127 2017-12-30 11:02:35	0|luke-jr|meshcollider: the 0 at the front indicates the current immaturity of the project
128 2017-12-30 11:02:50	0|luke-jr|when things get to a sensible state, it should become a 1.x.y.z
129 2017-12-30 11:02:58	0|meshcollider|btw luke-jr I liked your consensus versions page on the wiki
130 2017-12-30 11:02:58	0|wumpus|luke-jr: no one is making that decision
131 2017-12-30 11:03:05	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #12026: Prepare version scheme for 17.0 release (06master...06Mf1712-version17) 02https://github.com/bitcoin/bitcoin/pull/12026
132 2017-12-30 11:03:14	0|wumpus|luke-jr: no one will ever agree whether 'bitcoin is ready'
133 2017-12-30 11:03:20	0|wumpus|luke-jr: we already get too many fights about that
134 2017-12-30 11:03:21	0|luke-jr|wumpus: why not?
135 2017-12-30 11:03:44	0|wumpus|with some people calling it completely useless in current state and others saying it's done don't change it anymore
136 2017-12-30 11:03:50	0|wumpus|and a whole spectrum in between
137 2017-12-30 11:03:57	0|meshcollider|wumpus: shouldnt that have waited til after 0.16 branches off
138 2017-12-30 11:04:01	0|luke-jr|and even if it were true, that's certainly no reason to set it to a 16-past-readiness stage when it clearly isn't
139 2017-12-30 11:04:23	0|sipa|wumpus: that wasn't intended to be merged now...
140 2017-12-30 11:05:18	0|sipa|(the PR also changes the number from 15 to 16)
141 2017-12-30 11:05:20	0|wumpus|there is no readyness stage, there won't be no readyness stage
142 2017-12-30 11:05:29	0|fanquake|"trades intensify"
143 2017-12-30 11:05:48	0|wumpus|sipa: oh shit
144 2017-12-30 11:06:02	0|meshcollider|wumpus: heh but now master will build as 16.99 instead of 0.15.99
145 2017-12-30 11:06:21	0|meshcollider|we skipped 0.16 release, segwit wallet is now 0.17 ;)
146 2017-12-30 11:06:39	0|sipa|meshcollider: no, 17.0
147 2017-12-30 11:07:18	0|luke-jr|wumpus: the only reason to drop the 0 is for the same marketting/pumping nonsense you were denouncing earlier
148 2017-12-30 11:07:22	0|meshcollider|sipa: oops, yes lol
149 2017-12-30 11:07:50	0|wumpus|luke-jr: which no one agreed to at the time
150 2017-12-30 11:08:22	0|wumpus|going to force-push to previous master
151 2017-12-30 11:08:25	0|luke-jr|⁈
152 2017-12-30 11:09:11	0|MarcoFalke|s/16/15/ && git commit
153 2017-12-30 11:09:43	0|luke-jr|wumpus: so why merge pumping nonsense just because nobody explicitly agreed in the last 2 hours?
154 2017-12-30 11:10:15	0|sipa|it's just dropping a stupid zero that has no meaning
155 2017-12-30 11:10:59	0|bitcoin-git|[13bitcoin] 15laanwj 04force-pushed 06master from 14db7eba6 to 14efae366: 02https://github.com/bitcoin/bitcoin/commits/master
156 2017-12-30 11:10:59	0|sipa|yes, some people will misinterpreted as sign
157 2017-12-30 11:11:04	0|luke-jr|sipa: it has meaning
158 2017-12-30 11:11:12	0|sipa|the alternative is that we never get rid of the 0
159 2017-12-30 11:11:29	0|wumpus|MarcoFalke: sorry for the inconvenience, please open a new PR
160 2017-12-30 11:11:33	0|luke-jr|we get rid of the 0 when it's reasonable to bump to 1.0..
161 2017-12-30 11:11:48	0|MarcoFalke|wumpus: No rush. Can wait until next year
162 2017-12-30 11:11:51	0|luke-jr|like any other sane versioning
163 2017-12-30 11:11:56	0|sipa|luke-jr: the whole point is that there is no "reasonable" time for that
164 2017-12-30 11:11:58	0|meshcollider|luke-jr: there will be arguments whenever anyone suggests that though
165 2017-12-30 11:12:01	0|luke-jr|sipa: but there is
166 2017-12-30 11:12:01	0|wumpus|MarcoFalke: I think it has to be done now
167 2017-12-30 11:12:02	0|sipa|we have date based releades
168 2017-12-30 11:12:21	0|wumpus|MarcoFalke: either we do it, or we never do it, I think there's a good point to not let this linger
169 2017-12-30 11:12:30	0|meshcollider|MarcoFalke: next year is in less than 24 hours in NZ ;)
170 2017-12-30 11:12:39	0|sipa|i just had a twitter fight with someone who assumed that bitcoin core could not be "ready" until it integrated lightning
171 2017-12-30 11:12:49	0|luke-jr|even if there may be arguments when it's reasonable, it clearly ISN'T reasonable TODAY
172 2017-12-30 11:12:51	0|meshcollider|sipa: heh yep I saw that
173 2017-12-30 11:13:05	0|sipa|luke-jr: it's as reasonable today as it will ever b
174 2017-12-30 11:13:21	0|sipa|everyone has different requirements for ready, and no software is ever finished
175 2017-12-30 11:13:28	0|luke-jr|sipa: today it's often that users get transactions stuck and beyond simple recovery; that's not 1.0 quality
176 2017-12-30 11:13:39	0|luke-jr|today we have no way to restore wallet backups
177 2017-12-30 11:13:43	0|wumpus|luke-jr: that will not improve from one day to another
178 2017-12-30 11:13:50	0|luke-jr|today we have no simple way to automate safe backups
179 2017-12-30 11:13:51	0|wumpus|luke-jr: there is not one *point* at which that will all be true
180 2017-12-30 11:13:59	0|sipa|and then there will be another issue
181 2017-12-30 11:14:05	0|sipa|no software is ever perfect
182 2017-12-30 11:14:15	0|wumpus|and no one will decide on that, no one wil stake their reputation on 'bitcoin is 1.0 quality now'
183 2017-12-30 11:14:19	0|luke-jr|point is that today, Core is not usable by a normal person
184 2017-12-30 11:14:21	0|wumpus|sipa: indeed
185 2017-12-30 11:14:26	0|wumpus|define 'normal person'
186 2017-12-30 11:14:31	0|sipa|luke-jr: sure
187 2017-12-30 11:14:35	0|sipa|totally agree
188 2017-12-30 11:14:46	0|sipa|it's also not the right choice for many
189 2017-12-30 11:14:46	0|wumpus|will it ever be usable by everyone? I don't think so
190 2017-12-30 11:14:47	0|luke-jr|wumpus: pick a random person off the street
191 2017-12-30 11:14:52	0|wumpus|that's not a requirement
192 2017-12-30 11:15:25	0|wumpus|you're just making up things now. Can a random person from the street program the linux kernel directly?
193 2017-12-30 11:15:36	0|luke-jr|we're not talking about programming
194 2017-12-30 11:15:38	0|luke-jr|we're talking about usage
195 2017-12-30 11:15:39	0|wumpus|bitcoin core is just the infrastructre
196 2017-12-30 11:15:46	0|sipa|would you argue that FPFA designer software cannot be 1.0 before a random person on the street can use it?
197 2017-12-30 11:15:50	0|luke-jr|random person off the street can certainly boot and use a Linux LiveCD
198 2017-12-30 11:15:52	0|wumpus|there is tons of software aimed at providing better ui and whatnot
199 2017-12-30 11:15:59	0|wumpus|sipa: exactly.
200 2017-12-30 11:16:01	0|sipa|i think it's more than infrastructure
201 2017-12-30 11:16:12	0|luke-jr|Bitcoin Core is an end-user application, not a developer application
202 2017-12-30 11:16:17	0|sipa|but it's not for everyone
203 2017-12-30 11:16:20	0|wumpus|luke-jr: then what is RPC for?
204 2017-12-30 11:16:28	0|luke-jr|if nearly everyone doesn't use a full node, Bitcoin doesn't work
205 2017-12-30 11:16:33	0|luke-jr|wumpus: RPC isn't all of Core
206 2017-12-30 11:16:48	0|luke-jr|I'd have no problem with calling bitcoind >=1.0
207 2017-12-30 11:16:51	0|sipa|yes, so?
208 2017-12-30 11:16:51	0|wumpus|I'm really so  tired of this
209 2017-12-30 11:17:27	0|wumpus|sure, let's version bitcoind separately... that will make things easier
210 2017-12-30 11:18:01	0|luke-jr|there's always the "don't fix what isn't broken" option
211 2017-12-30 11:18:53	0|sipa|the 0 in front is redundant at best, and confusing at worst
212 2017-12-30 11:20:34	0|luke-jr|strongly disagree. it has a meaning and a purpose
213 2017-12-30 11:20:45	0|wumpus|no, it has no purpose
214 2017-12-30 11:21:06	0|wumpus|it will never be increased
215 2017-12-30 11:21:16	0|meshcollider|and the only ones who would really understand the "meaning and purpose" of a version number in general are other developers... no end user will read this deeply into it
216 2017-12-30 11:21:25	0|luke-jr|you're talking about increasing it NOW, so that argument makes no sense
217 2017-12-30 11:21:33	0|wumpus|we're just removing the initial 0
218 2017-12-30 11:21:37	0|wumpus|not *increasing* anything
219 2017-12-30 11:22:25	0|meshcollider|because we actually refer to the second number as the "major" version number, what is the 0 even called?
220 2017-12-30 11:22:38	0|meshcollider|the supermajor version number
221 2017-12-30 11:22:44	0|sipa|"the zero"
222 2017-12-30 11:23:09	0|wumpus|+1 for "the zero"
223 2017-12-30 11:23:18	0|luke-jr|who refers to the second as "major"? that'd be incorrect terminology
224 2017-12-30 11:23:24	0|sipa|everyone
225 2017-12-30 11:23:24	0|wumpus|we all do
226 2017-12-30 11:23:27	0|wumpus|except for you, maybe
227 2017-12-30 11:23:28	0|sipa|seriously.
228 2017-12-30 11:23:36	0|sipa|we have major releases every 6 months
229 2017-12-30 11:23:42	0|wumpus|yes
230 2017-12-30 11:23:45	0|sipa|minor releases for bigfixes and softforks
231 2017-12-30 11:24:12	0|sipa|i like bigfixes and i cannot lie
232 2017-12-30 11:24:22	0|meshcollider|e.g. quote from #11449 "Like for previous major releases I've added 6 months to the previous release schedule"
233 2017-12-30 11:24:23	0|gribble|https://github.com/bitcoin/bitcoin/issues/11449 | Release schedule for 0.16.0 · Issue #11449 · bitcoin/bitcoin · GitHub
234 2017-12-30 11:24:58	0|luke-jr|bugfixes aren't minor releases in normal versioning
235 2017-12-30 11:25:19	0|meshcollider|sipa: lol
236 2017-12-30 11:25:48	0|wumpus|we've always used that terminology
237 2017-12-30 11:26:04	0|sipa|luke-jr: yet that is how we've all been referring to it
238 2017-12-30 11:26:07	0|wumpus|so that matches better withremoving the 0
239 2017-12-30 11:27:18	0|meshcollider|we'll stick with the 6-monthly release schedule though won't we, rather than converting fully to semver?
240 2017-12-30 11:28:02	0|wumpus|what, you want to change the release schedule too now?
241 2017-12-30 11:28:19	0|meshcollider|heh no that's what I'm checking
242 2017-12-30 11:28:38	0|wumpus|oh right, sorry
243 2017-12-30 11:28:53	0|wumpus|yes, I think it makes sense to stick to that, it has worked pretty well
244 2017-12-30 11:29:52	0|wumpus|we don't need to change everything around just because a few people (most not even involved with the project) are screaming
245 2017-12-30 11:30:20	0|meshcollider|Agreed, it's just that semver has come up in discussion over these version numbers quite a lot, so people might expect us to stick to it more strongly now
246 2017-12-30 11:30:40	0|wumpus|what in 'semver' rules out a 6 month release schedule anyway?
247 2017-12-30 11:30:45	0|bitcoin-git|[13bitcoin] 15MarcoFalke opened pull request #12055: Prepare version scheme for upcoming release [take 2] (06master...06Mf1712-versionDropRedundantZero) 02https://github.com/bitcoin/bitcoin/pull/12055
248 2017-12-30 11:31:29	0|meshcollider|semver would only require a major release each time a breaking API change occurred, so you'd be limited to merging a breaking change once every 6 months ;)
249 2017-12-30 11:31:44	0|wumpus|don't most open source projects have a more or less tick-tock release schedule?
250 2017-12-30 11:32:07	0|wumpus|what is 'breaking' in this context?
251 2017-12-30 11:32:12	0|fanquake|I don't think we really gain much by trying to stick to some arbitrary requirements. It would seem like core isn't exactly like "other" projects.
252 2017-12-30 11:32:18	0|wumpus|changing RPC interface?
253 2017-12-30 11:32:26	0|wumpus|well, every major version wil qualify for that one :)
254 2017-12-30 11:32:27	0|meshcollider|wumpus: yes, external API
255 2017-12-30 11:32:48	0|wumpus|even if there are no P2P and consensus changes
256 2017-12-30 11:33:08	0|meshcollider|wumpus: internal changes do not matter for semver, they are patch releases. Minor changes are backwards compatible extensions of the API, and major are breaking changes to the API (no matter how small, technically)
257 2017-12-30 11:33:31	0|wumpus|ok...
258 2017-12-30 11:33:34	0|fanquake|To think about this a bit differently. What would the release schedule look like if core github had 2 or 3x the contributors for review and code that it currently has?
259 2017-12-30 11:33:55	0|wumpus|it might be possible to do more frequent releases
260 2017-12-30 11:34:03	0|wumpus|e.g. 3 month schedule instead of 6
261 2017-12-30 11:34:39	0|luke-jr|meshcollider: SemVer is not exclusively about interfaces.. any new functionality warrants a minor bump
262 2017-12-30 11:35:19	0|wumpus|but still I think the only sane way to do releases is to have them time based
263 2017-12-30 11:35:32	0|luke-jr|wumpus: I think everyone likes thaat
264 2017-12-30 11:36:02	0|fanquake|I agree, and I think that will become even more "likeable" over time
265 2017-12-30 11:36:03	0|luke-jr|wumpus: doing SemVer right would simply mean we'd go from 1.0 to 1.1 if we were backward compatible, and to 2.0 if breaking compatibility
266 2017-12-30 11:36:14	0|luke-jr|nothing to do with the schedule
267 2017-12-30 11:36:17	0|meshcollider|luke-jr: It *may* increase minor but not *must*
268 2017-12-30 11:36:31	0|luke-jr|meshcollider: patch-level increases must only be fixes, though\
269 2017-12-30 11:36:35	0|wumpus|luke-jr: but breaking *what* interface? we have many interfaces to contend with, for semver we'd have to define what interfaces count and which do not
270 2017-12-30 11:36:37	0|fanquake|Longer term releases only somethimes "suck" now because big new features can get delayed.
271 2017-12-30 11:37:01	0|luke-jr|wumpus: the root of this problem is that we haven't modularised yet (which is yet another reason to stick to 0.x)
272 2017-12-30 11:37:04	0|MarcoFalke|In the longer term, we need versions for RPC, wallet, gui, etc anyway
273 2017-12-30 11:37:08	0|meshcollider|yeah trying to version core as a whole is too unwieldy tbh
274 2017-12-30 11:37:12	0|MarcoFalke|That has nothing to do with Bitcoin Core version
275 2017-12-30 11:37:15	0|luke-jr|wumpus: once modularised, each component can have its own version, which makes things a lot more obvious
276 2017-12-30 11:37:20	0|wumpus|fanquake: yes, indeed, that's the drawback of the long duration between releases, on the other hand it makes sure things are pretty well tested on mater usually before they end up in a relesae
277 2017-12-30 11:37:21	0|meshcollider|indeed
278 2017-12-30 11:37:29	0|luke-jr|MarcoFalke: it's harder to go backward
279 2017-12-30 11:37:58	0|wumpus|we have a wallet version, and network protocol version, but yes no RPC api version. I agree those are separate from the software proejct version.
280 2017-12-30 11:38:09	0|aj|sipa: hmm. "i like bugfixes and i cannot lie: your other branches don't compile. 'cause when a patch comes in and claims it make it run fast and the travis checks pass, it gets merged"
281 2017-12-30 11:38:09	0|wumpus|this is also why I closed the PR adding the bitcoin core version to libconsensus pc
282 2017-12-30 11:38:32	0|wumpus|libconsensus should probably be versioned differently
283 2017-12-30 11:38:54	0|meshcollider|yes libconsensus should definitely follow semver because it is a library
284 2017-12-30 11:39:03	0|wumpus|yep
285 2017-12-30 11:39:08	0|wumpus|for libraries it makes perfect sense
286 2017-12-30 11:39:22	0|wumpus|for the rest it's just useless splitting hairs
287 2017-12-30 11:40:20	0|sipa|aj: haha
288 2017-12-30 11:45:07	0|luke-jr|at least the "drop the leading zero" approach enables me to just ignore it and keep using a leading zero. ;)
289 2017-12-30 11:46:33	0|meshcollider|Instead of dropping the zero, let's just rename _CLIENT_VERSION_MAJOR to _CLIENT_VERSION_THE_ZERO then ;)
290 2017-12-30 11:46:40	0|luke-jr|(and eventually the project can revert it when we're ready to get to a real 1.0)
291 2017-12-30 11:54:02	0|zelest|o/
292 2017-12-30 11:54:11	0|echeveria|at some point soon there'll be pretty good justification for dislodging the wallet from bitcoin core.
293 2017-12-30 11:54:29	0|echeveria|it's almost unusable as a wallet now, and I'm pretty tolerant of bad user experiences.
294 2017-12-30 11:54:41	0|sipa|how so?
295 2017-12-30 11:54:45	0|wumpus|it's pretty usable as a wallet IMO
296 2017-12-30 11:55:31	0|luke-jr|I find it very usable, but I'm admittedly not an ordinary user and don't use it like an ordinary user probably would want to
297 2017-12-30 11:55:34	0|wumpus|and as said, a full node without a wallet is pretty useless, unless you have other, better wallet to interface with it, which doesn't exist at the moment
298 2017-12-30 11:56:10	0|echeveria|it's by far the slowest, highest resource usage piece of software around. I can either suffer it destroying my battery life and bandwidth, or wait for it to catch up a week or two of blocks every time I want to use it.
299 2017-12-30 11:56:11	0|wumpus|there are certainly wallets with better UI, but the privacy/flexibility of bitcoin core's wallet is one of the best
300 2017-12-30 11:56:22	0|wumpus|that's because you're running a full node
301 2017-12-30 11:56:27	0|wumpus|that has nothing to do with the wallet
302 2017-12-30 11:56:28	0|luke-jr|wumpus: lots of other wallets exist
303 2017-12-30 11:56:32	0|echeveria|note that I said dislodge, not remove.
304 2017-12-30 11:56:35	0|wumpus|luke-jr: yes, but I don't think they're better
305 2017-12-30 11:56:36	0|sipa|echeveria: those are inherent to running a full node
306 2017-12-30 11:56:43	0|luke-jr|I agree
307 2017-12-30 11:56:43	0|wumpus|luke-jr: apart from UI-niceness
308 2017-12-30 11:56:46	0|sipa|echeveria: dislodging the wallet from the node won't change that
309 2017-12-30 11:56:54	0|luke-jr|I also think B-Qt's UI is the nicest ;P
310 2017-12-30 11:57:28	0|luke-jr|echeveria: that's what it means to use Bitcoin though
311 2017-12-30 11:57:54	0|wumpus|echeveria: so how would the user experience *concretely* become better with a 'dislodged' wallet?
312 2017-12-30 11:58:22	0|wumpus|echeveria: apart from the drawback of  having to install two programs to have a full node with wallet
313 2017-12-30 11:58:41	0|wumpus|echeveria: I like modularization but that doesn't really solve the problem of anything being slow or such things
314 2017-12-30 11:59:01	0|wumpus|echeveria: if you want to improve the UI, just improve the uI
315 2017-12-30 11:59:21	0|wumpus|that can be done without compounding the issue and extending the scope to reorganizaing the whole project
316 2017-12-30 11:59:37	0|wumpus|which will never happen in one go
317 2017-12-30 11:59:42	0|echeveria|there's a lot of scope for being able to remotely connect to a trusted node, without giving it any key responsibility.
318 2017-12-30 12:00:05	0|sipa|echeveria: fair point
319 2017-12-30 12:00:27	0|luke-jr|need BIPs 150 & 151 to do that reasonably safe
320 2017-12-30 12:00:27	0|wumpus|you could already do that though, by running a full node and connecting a SPV node to that
321 2017-12-30 12:00:36	0|luke-jr|or Tor
322 2017-12-30 12:00:38	0|wumpus|there are SPV wallets where you can specify a trusted node
323 2017-12-30 12:00:42	0|echeveria|damn, was chewing as missed my 'inb4 bip37'.
324 2017-12-30 12:01:06	0|wumpus|in any case, this has been discussed since 2012, patches welcome
325 2017-12-30 12:01:11	0|echeveria|it takes like, 45 minutes to sync over bip37 now and it shreds the node you're connected to.
326 2017-12-30 12:01:21	0|echeveria|wumpus: I'm not demanding anything of you, or anyone.
327 2017-12-30 12:01:24	0|wumpus|more arguing doesn't change anything
328 2017-12-30 12:01:26	0|wumpus|it never did
329 2017-12-30 12:02:05	0|wumpus|no one is writing software for you for free, if you want something you need to commit to writing it, or having someone write it, or at least to reviewing the end product (there's a few PRs open that move in that direction)
330 2017-12-30 12:02:59	0|echeveria|I never asked you to.
331 2017-12-30 12:03:25	0|echeveria|I was busy making sure bip37 was disabled on my nodes, that's all.
332 2017-12-30 12:04:31	0|sipa|in any casez i agree it would be a useful evolution to running a full node separately from the wallet
333 2017-12-30 12:04:52	0|wumpus|yes, exposing bip37 to random nodes was probably not the best idea
334 2017-12-30 12:05:01	0|wumpus|it's okay for your own whitelisted wallet
335 2017-12-30 12:05:03	0|sipa|though avoiding the bandwidth issue of syncing isn't magically solved by that
336 2017-12-30 12:05:10	0|sipa|neutrino is one possibility
337 2017-12-30 12:05:15	0|wumpus|certainly not....
338 2017-12-30 12:05:38	0|wumpus|it'd just split the load over two hosts, which could be useful in some cases for some people
339 2017-12-30 12:05:56	0|wumpus|which was my point that 'dislodging' the wallet is not a panacea
340 2017-12-30 12:06:15	0|sipa|right
341 2017-12-30 12:11:54	0|wumpus|for completelness: joinmarket's wallet uses a different approach, it imports its addresses as watch-only addresses into bitcoind
342 2017-12-30 12:13:52	0|wumpus|this avoids the bandwidth issue between the bitcoind and wallet by doing the scanning server-side
343 2017-12-30 12:15:26	0|wumpus|after all, if the node is trusted, it doesn't matter that you're leaking your public addresses to it
344 2017-12-30 12:15:44	0|wumpus|-public
345 2017-12-30 12:17:29	0|wumpus|that approach also works with a pruning node, without risk that blocks that the client wallet needs have been deleted
346 2017-12-30 12:19:13	0|wumpus|(which bip37-based, or even full block SPV approaches would suffer from)
347 2017-12-30 12:21:25	0|wumpus|SPV wallets of any kind only have to sync from their birthday, so I don't see why '45 minutes to sync over bip37' unless it's an old wallet that hasn't been synced for a long time
348 2017-12-30 12:21:59	0|wumpus|there is certainly no such requirement for new wallets
349 2017-12-30 12:22:23	0|echeveria|wumpus: some of them sync from zero, not the birthday.
350 2017-12-30 12:23:03	0|wumpus|that's unnecessary
351 2017-12-30 12:23:30	0|echeveria|of course.
352 2017-12-30 12:23:52	0|wumpus|haven't seen that for a long time anyhow, most of the wallets in active use don't have that problem
353 2017-12-30 12:25:23	0|wumpus|anyhow see #10794
354 2017-12-30 12:25:26	0|gribble|https://github.com/bitcoin/bitcoin/issues/10794 | Add simple light-client mode (RPC only) by jonasschnelli · Pull Request #10794 · bitcoin/bitcoin · GitHub
355 2017-12-30 12:25:41	0|wumpus|or #9483
356 2017-12-30 12:25:44	0|gribble|https://github.com/bitcoin/bitcoin/issues/9483 | Complete hybrid full block SPV mode by jonasschnelli · Pull Request #9483 · bitcoin/bitcoin · GitHub
357 2017-12-30 12:45:06	0|xiedeacc|can someone provide some information describe segwit in detail and clear?
358 2017-12-30 12:45:21	0|xiedeacc|website or book
359 2017-12-30 12:53:12	0|xiedeacc|sorry, computer crashed
360 2017-12-30 12:53:43	0|sipa|xiedeacc: bip141, bip143, bip144
361 2017-12-30 12:53:56	0|sipa|for questions, https://bitcoin.stackexchange.com
362 2017-12-30 12:54:46	0|xiedeacc|thanks~
363 2017-12-30 12:55:53	0|bitcoin-git|13bitcoin/06master 145ec3eae 15Pablo Fernandez: remove brew c++ flag...
364 2017-12-30 12:55:53	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/efae3663a772...63a4dc10876b
365 2017-12-30 12:55:54	0|bitcoin-git|13bitcoin/06master 1463a4dc1 15Wladimir J. van der Laan: Merge #12027: [Docs] Remove boost --c++ flag from osx build instructions...
366 2017-12-30 12:56:31	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #12027: [Docs] Remove boost --c++ flag from osx build instructions (06master...06patch-1) 02https://github.com/bitcoin/bitcoin/pull/12027
367 2017-12-30 13:09:26	0|echeveria|uh
368 2017-12-30 13:09:33	0|echeveria|9bf8853b3a823bbfa1e54017ae11a9e1f4d08a854dcce9f24e08114f2c921182
369 2017-12-30 13:09:45	0|echeveria|well someone just fucked up badly and mined a zero value block.
370 2017-12-30 13:11:10	0|wumpus|nice, not even the block reward
371 2017-12-30 13:12:27	0|sturles|Not seen by my node. :-/
372 2017-12-30 13:12:40	0|echeveria|uh.
373 2017-12-30 13:12:46	0|echeveria|so blockchain.info is stuck on it.
374 2017-12-30 13:13:00	0|echeveria|the block hash is 0000000000000000004b27f9ee7ba33d6f048f684aaeb0eea4befd80f1701126.
375 2017-12-30 13:13:25	0|sturles|Ah, yes.  I've got that one.
376 2017-12-30 13:13:56	0|sturles|Mined by AntPool.
377 2017-12-30 13:14:07	0|echeveria|why do you say that?
378 2017-12-30 13:14:22	0|echeveria|there's nothing identifying in the coinbase nonce, and no output address.
379 2017-12-30 13:14:33	0|sturles|According to https://tradeblock.com/bitcoin
380 2017-12-30 13:14:49	0|sturles|Could be wrong.  I have no idea where they get the information.
381 2017-12-30 13:14:59	0|sturles|Some pools publish the blocks they find.
382 2017-12-30 13:15:31	0|sturles|Claims to have found.
383 2017-12-30 13:15:52	0|echeveria|https://www.antpool.com/poolStats.htm < they're not claiming it
384 2017-12-30 13:18:48	0|wumpus|the vout script is weird, invalid "RSKBLOCK:\xdd\xbfQz\xdf\x8f\xfdK\xcawQP[9\xc9\x01:\r\x1f\xd4y\xfcN\x90\x1b9\xddW\xb3G\xc6$"
385 2017-12-30 13:19:07	0|sipa|rootstock?
386 2017-12-30 13:20:38	0|echeveria|https://github.com/rsksmart/rskj/blob/e03421af1e361114f9e63838b92b008c518c0638/rskj-core/src/main/java/co/rsk/validators/ProofOfWorkRule.java#L94
387 2017-12-30 13:20:50	0|wumpus|gah, would have been proper to put that in a OP_RETURN instead of just using an invalid script
388 2017-12-30 13:20:55	0|echeveria|yeah, looks like a rootstock commitment. that was an expensive mistake.
389 2017-12-30 13:24:10	0|echeveria|they vaporized about $240,000. who the hell writes custom software and doesn't check that they have the payout set to something sane?
390 2017-12-30 13:42:51	0|provoostenator|Our own little DAO :-)
391 2017-12-30 13:43:21	0|provoostenator|Wasn't the previous record of not claiming a coinbase reward 1 satoshi?
392 2017-12-30 13:44:01	0|echeveria|provoostenator: no. https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki
393 2017-12-30 13:45:57	0|provoostenator|echeveria: do you mean someone didn't implement that BIP in time and lost funds?
394 2017-12-30 13:46:33	0|echeveria|provoostenator: read the BIP, two duplicate block rewards (2x 50 BTC) don't exist.
395 2017-12-30 13:46:50	0|provoostenator|I thought they were grandfathered in?
396 2017-12-30 13:47:19	0|echeveria|they were clobbered. they have the same hash, so spending one spends "both".
397 2017-12-30 13:48:01	0|provoostenator|Ok, I see, so those blocks are valid, but their coinbases were already worthless. So the BIP prevents miners from wasting money this way (among the other benefits explictly mentioned).
398 2017-12-30 13:49:02	0|echeveria|BIP34 specifies a soft fork that makes them unique by adding a nonce to the coinbase.
399 2017-12-30 13:51:17	0|sipa|https://bitcoin.stackexchange.com/a/38998/208
400 2017-12-30 13:51:30	0|sipa|^ all known cases of known losses
401 2017-12-30 13:51:49	0|echeveria|needs updating for the latest 12.5 BTC loss.
402 2017-12-30 13:52:22	0|sipa|yeah.
403 2017-12-30 13:53:13	0|provoostenator|Ah yes, wonderful how block explorers have to deal with that special case: https://www.blocktrail.com/BTC/tx/d5d27987d2a3dfc724e359870c6644b40e497bdc0589a033220fe15429d88599
404 2017-12-30 13:57:27	0|provoostenator|sipa while you're at it, maybe link to an explanation for "the coins created in the genesis block cannot be spent"?
405 2017-12-30 13:59:53	0|sipa|provoostenator: they just can't
406 2017-12-30 14:00:56	0|sipa|every version of the bitcoin full node software would have considered a spend of the genesis output as invalid; hence, it is invalid
407 2017-12-30 14:01:26	0|sipa|it may have been intentional or an oversight, but that doesn't matter
408 2017-12-30 14:02:12	0|Varunram|sipa: so, satoshi didn't add the genesis block coins to the tx db?
409 2017-12-30 14:02:39	0|provoostenator|My understanding is that it was hardcoded into the client in some later version, though by that time it was too late, because even older versions would consider spending that a hardfork, so presumably new versions also don't allow it.
410 2017-12-30 14:03:22	0|provoostenator|And about the least important thing you could possibly want to change.
411 2017-12-30 14:03:26	0|Varunram|oh, ok
412 2017-12-30 14:04:07	0|sipa|provoostenator: in early versions it was because the genesis block was never processed, so its output was never added to the txdb (precursor of the utxo set)
413 2017-12-30 14:04:27	0|sipa|in recent versions it's an explicit special case
414 2017-12-30 14:04:54	0|sipa|(introduced to prevent creating a hardfork w.r.t. older versions)
415 2017-12-30 14:04:55	0|provoostenator|Do all altcoins based on this codebase have the same behavior?
416 2017-12-30 14:05:54	0|sipa|provoostenator: no idea
417 2017-12-30 17:27:52	0|achow101|provoostenator: no, some changed it to explicitly add the genesis block output to the txdb
418 2017-12-30 17:55:09	0|lvmbdv|hello, if P2PKH was the only mechanism of payment, would keeping witness data make more sense?
419 2017-12-30 17:55:38	0|sipa|?
420 2017-12-30 17:56:30	0|Randolf|lvmbdv:  You'd probably find that the #bitcoin channel is a really great place to ask that question.
421 2017-12-30 17:56:47	0|lvmbdv|sorry, i will
422 2017-12-30 17:57:25	0|Randolf|:)
423 2017-12-30 17:57:39	0|Sentineo|but it certainly needs rephrasing ;)
424 2017-12-30 17:59:58	0|midnightmagic|sipa: sorry about that.  I can put in an exception if you like
425 2017-12-30 18:01:15	0|sipa|midnightmagic: heh, no
426 2017-12-30 18:01:22	0|sipa|i should just identify
427 2017-12-30 18:20:53	0|midnightmagic|k
428 2017-12-30 22:00:05	0|sdupre|I having a C++ error making static builds.  Looking for some guidance.  Willing to pay.