1 2017-04-06 00:28:52	0|achow101|are the codesigned binary sigs up yet?
  2 2017-04-06 02:27:55	0|Taek|I do not know that a proposal which invalidates hardware optimazation has much chance at success
  3 2017-04-06 02:29:16	0|Taek|Though there are clear reasons for wanting such optimizations disabled, Bitcoin resists contentious changes, and I think the miners would be able to put up enough of a fight to prevent the change
  4 2017-04-06 02:30:47	0|warren|I wouldn't make any assumptions of what is possible.  We are yet to see the extent of outrage from the non-boosted miners and user majority and what could happen.
  5 2017-04-06 04:15:55	0|gmaxwell|Taek: keep in mind that I have not proposed invalidating an 'optimization'-- it still works, just not in a covert manner.
  6 2017-04-06 04:16:15	0|gmaxwell|Taek: also; a strong optimization like this if it cannot be copied will _guarentee_ a mining monopoly eventually.
  7 2017-04-06 04:16:28	0|Taek|acknowledged
  8 2017-04-06 04:16:31	0|gmaxwell|because at equlibrium only the optimized miner will be turning a profit.
  9 2017-04-06 04:17:58	0|Taek|err, maybe I am confused. Does your proposal not reduce the effective hashrate of the hardware you found?
 10 2017-04-06 04:18:33	0|Taek|And, fully on board that there needs to be a level playing field.
 11 2017-04-06 04:18:43	0|sipa|Taek: not if they switch to nversion grinding
 12 2017-04-06 04:25:33	0|gmaxwell|Taek: no because the use of it is optional and just impacts the power consumption. (but I suppose it would likely change the hashrate of a _facility_)
 13 2017-04-06 04:25:46	0|gmaxwell|but the optimization could be still used via nversion grinding.
 14 2017-04-06 04:25:49	0|gmaxwell|as sipa says.
 15 2017-04-06 04:26:00	0|gmaxwell|which is better in every respect except it isn't secret.
 16 2017-04-06 04:26:08	0|Taek|and the hardware that exists today is capable of doing the nversion grinding?
 17 2017-04-06 04:26:11	0|gmaxwell|it's more power efficient, it doesn't screw up further enhancements.
 18 2017-04-06 04:26:45	0|gmaxwell|Yes. (also nversion grinding is basically a subset of root grinding, and the obvious constructions of hardware that can root grind can nversion grind)
 19 2017-04-06 04:27:02	0|gmaxwell|obviously someone might do something I didn't anticipate, ... they're free to comment on the proposal.
 20 2017-04-06 04:27:27	0|Taek|okay. Thanks for clearing that up. I think that preserving the hardware advantage is going to be critical to getting the proposal accepted
 21 2017-04-06 04:28:04	0|Taek|not just that, but segwit, etc.
 22 2017-04-06 04:29:21	0|gmaxwell|I'm not confident in that.
 23 2017-04-06 04:29:51	0|Taek|Not confident that preserving the hardware advantage would be greatly beneficial to moving forward segwit?
 24 2017-04-06 04:32:20	0|gmaxwell|I don't think it's relevant for that.
 25 2017-04-06 04:33:00	0|Taek|My understanding right now is that this asic optimization gave very powerful ulterior motives for Bitmain to be politically blocking segwit
 26 2017-04-06 04:33:26	0|Taek|and the rest of the dance has really just been about preserving their 30% advantage
 27 2017-04-06 04:33:35	0|gmaxwell|Yes. Perhaps I misunderstood you...
 28 2017-04-06 04:34:05	0|gmaxwell|I thought you were saying that it was important to block only the segwit incompatible form without blocking it completely. (which is what my proposal works to do because I think it's the right way to handle it)
 29 2017-04-06 04:34:27	0|gmaxwell|I think that blocking the optimization completely would be just as good in terms of permitting the protocol upgrades.
 30 2017-04-06 04:34:52	0|Taek|My worry is that blocking the optimization completely is going to be a long bloody uphill battle
 31 2017-04-06 04:35:04	0|Taek|and, one that I think you could argue is worthwhile
 32 2017-04-06 04:35:22	0|gmaxwell|Well I think that the technique will either be opened or eventually blocked.
 33 2017-04-06 04:35:44	0|gmaxwell|The third option is that bitcoin will fail due to it, which I don't think we'll accept as a community.  But eventually could be a fair while.
 34 2017-04-06 04:36:17	0|gmaxwell|I agree that it might take a while, which is part of why I think its best to seperate the concerns.
 35 2017-04-06 04:37:02	0|gmaxwell|Also, the impact of my proposal is negligible if the optimization isn't really in use so there is really no grounds to say "sure, we put it in our hardware but arn't using it, we promise, no need for this BIP"...
 36 2017-04-06 04:38:58	0|Taek|Miners not benefitting from this optimization certainly have strong motivations to activate the proposal
 37 2017-04-06 04:39:02	0|Taek|that much is going for it
 38 2017-04-06 04:40:27	0|gmaxwell|Yes, and I think users do too. And I think that would also apply to proposals to eliminate the optimization +/- people who are really confused about the economics of mining and don't realize an advantage like that sustained privately pretty much guarentees a mining monopoly.
 39 2017-04-06 04:42:28	0|Taek|Another thought. The community now has an obvious boogeyman. If you wanted to push for something difficult that required consensus, this is probably the best time to do it, leveraging the boogeyman.
 40 2017-04-06 04:42:56	0|Taek|At this point I am trying to figure out what all the options are.
 41 2017-04-06 04:47:21	0|sipa|start over?
 42 2017-04-06 04:47:39	0|Taek|bitcoin2?
 43 2017-04-06 04:54:00	0|midnightmagic|starting over would devolve to design-by-committee
 44 2017-04-06 04:54:49	0|sipa|i'm not being serious of course
 45 2017-04-06 04:55:29	0|sipa|but damn, how i woshed sometimes i'd be working on a system without all this drama and monetary interests
 46 2017-04-06 04:58:25	0|rabidus|:(
 47 2017-04-06 05:01:05	0|midnightmagic|:)
 48 2017-04-06 05:14:39	0|jeremyrubin|w.r.t. nversion grinding; practically speaking couldn't one just switch nonce and nversion and call it a day?
 49 2017-04-06 05:15:52	0|sipa|apart from being a hard fork, sure
 50 2017-04-06 05:16:04	0|jeremyrubin|Is it a hard fork though??
 51 2017-04-06 05:16:15	0|jeremyrubin|I think it's soft...
 52 2017-04-06 05:16:39	0|jeremyrubin|just don't use all the bits in nversion of course
 53 2017-04-06 05:16:39	0|sipa|well as long as you stick to the bip34 rules
 54 2017-04-06 05:18:37	0|jeremyrubin|how does it break bip34?
 55 2017-04-06 05:18:48	0|jeremyrubin|just limit your nonce > 2
 56 2017-04-06 05:18:54	0|jeremyrubin|still plenty of bits
 57 2017-04-06 05:23:51	0|gmaxwell|What do you mean by "switch nonce and nversion"  version griding asicboost requires that you have a couple different first compression runs and many different second compression runs, which are all mutually compatible.
 58 2017-04-06 06:34:17	0|cfields|an eternity later: gitian builders: v0.14.1rc1 detached sigs pushed
 59 2017-04-06 06:48:58	0|gmaxwell|Better nate than lever.
 60 2017-04-06 06:50:44	0|midnightmagic|oh, we're doing detached sigs for rc candidates now?
 61 2017-04-06 06:50:54	0|wumpus|cfields: thanks!
 62 2017-04-06 06:50:58	0|midnightmagic|okay I'll rebuild. thanks!
 63 2017-04-06 06:51:08	0|wumpus|midnightmagic: we've been doing so for a while
 64 2017-04-06 06:51:15	0|wumpus|to test that part of the process too
 65 2017-04-06 06:51:31	0|wumpus|the last step is very fast though
 66 2017-04-06 06:51:52	0|midnightmagic|I thought it was just on a "when cfields or whoever gets around to it, maybe, but for sure for actual releases" :-)
 67 2017-04-06 06:52:04	0|cfields|wumpus: sorry for delay. I'm out of town and had to use my laptop, which really really didn't want to cooperate
 68 2017-04-06 06:53:42	0|cfields|i think i've learned how to force a tag in the bitcoin repo, though. it seems to be a sure thing as soon as i leave for a few days :)
 69 2017-04-06 07:02:41	0|wumpus|cfields: it does seem to always happen in the most inconvenient times for you
 70 2017-04-06 07:33:01	0|bitcoin-git|[13bitcoin] 15mrwhythat opened pull request #10161: [WIP] Support for Tor's Single Onion Service (06master...06tor-single-onion-service) 02https://github.com/bitcoin/bitcoin/pull/10161
 71 2017-04-06 07:35:43	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10158: Add some more release notes for 0.14.1. (060.14...06relnote141) 02https://github.com/bitcoin/bitcoin/pull/10158
 72 2017-04-06 07:36:09	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10157: [0.14] Fix the mempool_packages.py test (060.14...06test-0.14.1rc1) 02https://github.com/bitcoin/bitcoin/pull/10157
 73 2017-04-06 07:36:21	0|gmaxwell|Does someone want to write memory advice release notes?
 74 2017-04-06 07:36:25	0|gmaxwell|we should have those.
 75 2017-04-06 07:37:57	0|sipa|i'll try
 76 2017-04-06 07:48:47	0|warren|gitian is taking forever, will proably have sigs in the morning.
 77 2017-04-06 14:43:11	0|bitcoin-git|[13bitcoin] 15jnewbery opened pull request #10162: [trivial] Log calls to getblocktemplate (06master...06loggetblocktemplatecalls) 02https://github.com/bitcoin/bitcoin/pull/10162
 78 2017-04-06 18:36:06	0|bitcoin-git|[13bitcoin] 15laanwj pushed 7 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/c7e73eafa139...8c28670e92b6
 79 2017-04-06 18:36:07	0|bitcoin-git|13bitcoin/06master 1419e36bb 15Wladimir J. van der Laan: Add fs.cpp/h
 80 2017-04-06 18:36:07	0|bitcoin-git|13bitcoin/06master 147d5172d 15Wladimir J. van der Laan: Replace includes of boost/filesystem.h with fs.h...
 81 2017-04-06 18:36:08	0|bitcoin-git|13bitcoin/06master 14bac5c9c 15Wladimir J. van der Laan: Replace uses of boost::filesystem with fs...
 82 2017-04-06 18:36:26	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9902: Lightweight abstraction of boost::filesystem (06master...062017_03_fs) 02https://github.com/bitcoin/bitcoin/pull/9902
 83 2017-04-06 18:58:30	0|jcorgan|dev meeting?
 84 2017-04-06 18:58:36	0|jonasschnelli|2mins
 85 2017-04-06 19:01:31	0|jonasschnelli|Dong!
 86 2017-04-06 19:01:47	0|jtimon|proposed topics?
 87 2017-04-06 19:02:48	0|jcorgan|mumble mumble something about a white elephant in the room mumble mumble
 88 2017-04-06 19:02:58	0|wumpus|#startmeeting
 89 2017-04-06 19:02:59	0|lightningbot|Meeting started Thu Apr  6 19:02:58 2017 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
 90 2017-04-06 19:02:59	0|lightningbot|Useful Commands: #action #agreed #help #info #idea #link #topic.
 91 2017-04-06 19:03:09	0|luke-jr|gribble: nicks
 92 2017-04-06 19:03:26	0|luke-jr|… or not :x
 93 2017-04-06 19:03:30	0|kanzure|hi.
 94 2017-04-06 19:03:41	0|wumpus|#bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 instagibbs
 95 2017-04-06 19:03:45	0|sipa|hi, half present
 96 2017-04-06 19:04:00	0|sdaftuar|hi
 97 2017-04-06 19:04:22	0|btcdrak|still breathing
 98 2017-04-06 19:04:24	0|wumpus|topics?
 99 2017-04-06 19:05:10	0|CodeShark|about 69% present but due to incompatibilities with litecoin that might decrease
100 2017-04-06 19:05:29	0|luke-jr|absent other suggestions: UASF and/or PoW change? maybe too premature to discuss in dev tho
101 2017-04-06 19:05:42	0|sipa|offtopic for here, i think
102 2017-04-06 19:05:56	0|jonasschnelli|Yes. Let's not go down this road.
103 2017-04-06 19:06:00	0|wumpus|yes I don't think they're good fits for this meeting
104 2017-04-06 19:06:03	0|CodeShark|thanks for staying above that crap, sipa :)
105 2017-04-06 19:06:30	0|warren|0.14.1 status?
106 2017-04-06 19:06:42	0|btcdrak|Maybe someone can dish out review homework?
107 2017-04-06 19:06:44	0|wumpus|0.14.1 status: rc1 was tagged, gitian builds in progress
108 2017-04-06 19:06:53	0|cfields|hi, here, but also not very present.
109 2017-04-06 19:07:18	0|kanzure|if none of us are actually here, what are we doing?
110 2017-04-06 19:07:24	0|jeremyrubin|here
111 2017-04-06 19:07:34	0|morcos|here
112 2017-04-06 19:07:40	0|wumpus|I'll upload binaries tomorrow morning (NL time)
113 2017-04-06 19:08:17	0|luke-jr|maybe if FC is distracting too many devs, and we have a shortage of topics, meeting should be postponed?
114 2017-04-06 19:08:23	0|btcdrak|maybe we should just order some pizzas and beers.
115 2017-04-06 19:08:27	0|CodeShark|right
116 2017-04-06 19:08:34	0|kanzure|is financial crypto over yet?
117 2017-04-06 19:08:44	0|wumpus|yes, might be better to skip this meeting then, doesn't seem people have much to discuss or are not present or half present
118 2017-04-06 19:08:52	0|jonasschnelli|ack
119 2017-04-06 19:08:55	0|sipa|btcdrak: <BlueMatt> same PRs for review this week
120 2017-04-06 19:08:56	0|btcdrak|shortest meeting eva
121 2017-04-06 19:08:57	0|sdaftuar|anyone want to give updates on what they're working on?
122 2017-04-06 19:09:02	0|jonasschnelli|https://github.com/bitcoin/bitcoin/projects/8
123 2017-04-06 19:09:06	0|jonasschnelli|^ PRs to review
124 2017-04-06 19:09:16	0|warren|For those who can't directly obtain the osx gitian build req, should we recommend that they do not participate in that part of the gitian process?
125 2017-04-06 19:09:21	0|jonasschnelli|sdaftuar: good idea. You start?
126 2017-04-06 19:09:28	0|luke-jr|I'm looking at adding a UTXO index by scriptPubKey for sweeping purposes
127 2017-04-06 19:09:28	0|sipa|kanzure: dinner after FC17 currently ongoing; BlueMatt, roasbeef, ... are here
128 2017-04-06 19:09:39	0|jonasschnelli|warren: It's just an SDK tar.gz?!
129 2017-04-06 19:09:48	0|sdaftuar|jonasschnelli: sure
130 2017-04-06 19:09:48	0|wumpus|luke-jr: there's a pull for that right?
131 2017-04-06 19:09:56	0|luke-jr|warren: I don't see why it should be hard nowadays.. but yes, if you don't want to, feel free to skip
132 2017-04-06 19:10:19	0|luke-jr|wumpus: the current PR iterates over the entire UTXO set
133 2017-04-06 19:10:22	0|wumpus|luke-jr: https://github.com/bitcoin/bitcoin/pull/9806
134 2017-04-06 19:10:49	0|luke-jr|what I'm working on uses a RIPEMD160 to index scripts -> txid
135 2017-04-06 19:10:58	0|warren|jonasschnelli: I think a lot of non-Mac users have been sharing that with others instead of going through steps of getting it themselves, which defeats the security goal, so it's misleading if multiple people go through the gitian process unless they obtain it themselves.
136 2017-04-06 19:11:28	0|jonasschnelli|warren: that's true
137 2017-04-06 19:11:32	0|wumpus|luke-jr: not sure how that one is diffrent, but I don't think we need multiple utxo indexes
138 2017-04-06 19:11:43	0|jonasschnelli|I'm working on BFD. roasbeef did inform me in Berlin about the progress they have made for the LND. I'd like to have BFD for the hybrid full block SPV mode.
139 2017-04-06 19:11:43	0|luke-jr|anyone who didn't make it themselves should delete and make it (or not do osx builds) IMO
140 2017-04-06 19:11:50	0|jeremyrubin|I'd like to discuss net_processing refactors. It seems like there is some plan for where that is going, but it's not been made available to me.
141 2017-04-06 19:11:59	0|luke-jr|wumpus: the only UTXO index right now is by txid
142 2017-04-06 19:12:15	0|wumpus|luke-jr: yes, but the pull I referenced adds an index by scriptPubKey
143 2017-04-06 19:12:19	0|sipa|luke-jr: #9806
144 2017-04-06 19:12:20	0|gribble|https://github.com/bitcoin/bitcoin/issues/9806 | txoutsbyaddress index (take 3) by droark · Pull Request #9806 · bitcoin/bitcoin · GitHub
145 2017-04-06 19:13:32	0|jtimon|althought it isn't mine, I think https://github.com/bitcoin/bitcoin/pull/7729 should be added to the list of things to review: that blocks the removal of accounts system
146 2017-04-06 19:13:38	0|wumpus|warren: yes, the only reason I had to copy it (from a person I trust very much) is because it makes it possible for me to actually upload the executables. I don't think it's generally useful to build using someone else's macosx sdk file
147 2017-04-06 19:14:42	0|wumpus|but with luke-jr's instructions to extract it on linux there's not really an excuse anymore
148 2017-04-06 19:15:07	0|sipa|i've been working on database/cache/flush/memory usage things
149 2017-04-06 19:15:18	0|wumpus|jtimon: I tend to agree. though please review the *API*, not the code, the code is extremely outdated on that now
150 2017-04-06 19:15:48	0|jtimon|wumpus: thank you, that helps
151 2017-04-06 19:15:51	0|wumpus|jtimon: however I still stand behind the label API as I wrote it down back then, and that's the important part
152 2017-04-06 19:16:07	0|morcos|i've been coding and recoding fee estimates for months now.. they'll maybe be a tiny smidge better but infinitely more complicated and will annoy the crap out of everyone to review.  have a nice day.
153 2017-04-06 19:16:25	0|sdaftuar|i've been working on CreateNewBlock, so that we have a way to skip recently added transactions if the block income from doing so is below some threshold (to model higher orphan risk)
154 2017-04-06 19:16:32	0|warren|wumpus: I'd like for us to be able to hash verify some part of the SDK and add that somewhere in the gitian process, I'm pretty sure this is possible
155 2017-04-06 19:16:54	0|wumpus|warren: if you'd tar it in a deterministic way (like we do in gitian build process itself) that'd be easily possible
156 2017-04-06 19:16:57	0|jcorgan|please correct me if i'm wrong, but #9806 uses hash of the full script as a key, not extracting the embedded push(es) for and addrindex type key, or am i confused
157 2017-04-06 19:16:58	0|gribble|https://github.com/bitcoin/bitcoin/issues/9806 | txoutsbyaddress index (take 3) by droark · Pull Request #9806 · bitcoin/bitcoin · GitHub
158 2017-04-06 19:17:04	0|wumpus|warren: we'd just need a a script for that
159 2017-04-06 19:17:08	0|wumpus|warren: "normalize mac sdk"
160 2017-04-06 19:17:26	0|luke-jr|jcorgan: problem?
161 2017-04-06 19:17:31	0|warren|wumpus: agreed
162 2017-04-06 19:17:52	0|jcorgan|not a problem, just making sure i have the correct understanding
163 2017-04-06 19:18:19	0|wumpus|the files and file names should definitely be the same for everyone, the differences will be in the metadata such as date/time/user and possibly file order
164 2017-04-06 19:19:14	0|jtimon|I put some more ideas on #7829, not sure what to do about it, a couple of people participated at first, but perhaps the proposed task is too boring, even for newbies, at least I found some functions to make static
165 2017-04-06 19:19:16	0|gribble|https://github.com/bitcoin/bitcoin/issues/7829 | Globals: TODO: Experiment: Kill "Params()" by jtimon · Pull Request #7829 · bitcoin/bitcoin · GitHub
166 2017-04-06 19:20:15	0|luke-jr|jcorgan: not sure, but I didn't see a need for it myself
167 2017-04-06 19:20:18	0|jcorgan|luke-jr: wondering if the name 'txoutsbyaddressindex' is misleading
168 2017-04-06 19:20:43	0|luke-jr|jcorgan: definitely, since it has nothing to do with addresses, but I already complained about that in a past PR it appears XD
169 2017-04-06 19:20:44	0|jcorgan|anyway, not sure what the current topic is, i'll take this to the PR comments
170 2017-04-06 19:20:45	0|jtimon|also worked on #9494 #10119 #10118 and more things to potentially do afterwards
171 2017-04-06 19:20:46	0|gribble|https://github.com/bitcoin/bitcoin/issues/9494 | Introduce an ArgsManager class encapsulating cs_args, mapArgs and mapMultiArgs by jtimon · Pull Request #9494 · bitcoin/bitcoin · GitHub
172 2017-04-06 19:20:48	0|gribble|https://github.com/bitcoin/bitcoin/issues/10118 | Util: Remove redundant calls to argsGlobal.IsArgSet() by jtimon · Pull Request #10118 · bitcoin/bitcoin · GitHub
173 2017-04-06 19:20:48	0|gribble|https://github.com/bitcoin/bitcoin/issues/10119 | Util: Remove ArgsManager wrappers: by jtimon · Pull Request #10119 · bitcoin/bitcoin · GitHub
174 2017-04-06 19:23:11	0|sipa|any other topics or updates?
175 2017-04-06 19:23:34	0|sdaftuar|quiet times!
176 2017-04-06 19:23:47	0|jcorgan|maybe here it is quiet :)
177 2017-04-06 19:24:21	0|warren|wumpus mentioned luke's script, for the record it is located here: https://github.com/bitcoin/bitcoin/blob/master/doc/README_osx.md
178 2017-04-06 19:24:23	0|wumpus|let's close the meeting early then
179 2017-04-06 19:24:30	0|jonasschnelli|Yes. /end
180 2017-04-06 19:24:37	0|wumpus|warren: yup
181 2017-04-06 19:24:43	0|warren|well, instructions at least
182 2017-04-06 19:24:47	0|wumpus|#link https://github.com/bitcoin/bitcoin/blob/master/doc/README_osx.md
183 2017-04-06 19:24:50	0|wumpus|#endmeeting
184 2017-04-06 19:24:51	0|lightningbot|Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-04-06-19.02.log.html
185 2017-04-06 19:24:51	0|lightningbot|Meeting ended Thu Apr  6 19:24:50 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
186 2017-04-06 19:24:51	0|lightningbot|Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-04-06-19.02.html
187 2017-04-06 19:24:51	0|lightningbot|Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-04-06-19.02.txt
188 2017-04-06 19:24:53	0|sipa|it seems we boosted the speed of the meeting significantly
189 2017-04-06 19:25:03	0|warren|overt boost even
190 2017-04-06 19:25:10	0|jonasschnelli|boost(ed),.. I can't read that word anymore
191 2017-04-06 19:25:25	0|gmaxwell|oops
192 2017-04-06 19:25:32	0|jeremyrubin|A [sic] efficiency gain
193 2017-04-06 19:25:50	0|jcorgan|ima go patent it
194 2017-04-06 19:25:51	0|wumpus|isn't meeting speed boost patented?
195 2017-04-06 19:26:04	0|jonasschnelli|Heh,... I'm sure there is one somewhere
196 2017-04-06 19:26:06	0|gmaxwell|Sorry, been caught up in responding to dramaz and missed the meeting entirely! :(
197 2017-04-06 19:26:15	0|jonasschnelli|Well... it was short
198 2017-04-06 19:26:19	0|warren|wumpus: yes, one of the claims is to remove chairs from the room
199 2017-04-06 19:26:33	0|jtimon|gmaxwell: I guess you can bring any topic if you want, we just finished
200 2017-04-06 19:26:48	0|jtimon|most people are probably still around
201 2017-04-06 19:26:49	0|wumpus|warren: hah indeed, to not let people get too comfortable
202 2017-04-06 19:27:35	0|gmaxwell|I didn't want anything.
203 2017-04-06 19:28:03	0|gmaxwell|I'm kind of overwhelmed by this bitmain response. It says a lot of agressive and untrue things, about the BIP proposal, about me personally, about our project.
204 2017-04-06 19:28:28	0|luke-jr|seemed clearly nonsense enough I wouldn't worry over it IMO
205 2017-04-06 19:28:31	0|jcorgan|no good deed goes unpunished
206 2017-04-06 19:28:33	0|gmaxwell|It does a weird mix of confirming and denying.
207 2017-04-06 19:28:45	0|wumpus|they're overwhelmed, and incapable of responding coherently
208 2017-04-06 19:28:54	0|CodeShark|gmaxwell: they will never back down at this point
209 2017-04-06 19:28:57	0|luke-jr|gmaxwell: if Bitmain was innocent, they'd be all supportive of your proposal to stop competition from abusing it
210 2017-04-06 19:29:06	0|achow101|what was Bitmain's response?
211 2017-04-06 19:29:33	0|wumpus|yes, any miners that are not (planning to) use the trick would be supportive, after all no one wants to be secretly screwed out of their reward
212 2017-04-06 19:29:40	0|gmaxwell|E.g. they helpfully confim their hardware implements asicboost, they loudly say they have the right to use it.  They claim that they haven't used it on mainnet 'for the good of bitcoin' (how that jives with their claims that they'll make all the empty blocks they want because the protocol allows it, I dunno)
213 2017-04-06 19:29:52	0|CodeShark|if you're expecting a mea culpa you will end up gravely disappointed
214 2017-04-06 19:30:22	0|jcorgan|^
215 2017-04-06 19:30:46	0|gmaxwell|Yes, the proposal is specifically designed to have minimal impact and only interfear with covert asicboost and only to the extent that it gums up protocol extensions (like segwit, utxo commitments, bloom filter commitments, etc.)  But in their response they claim that I am trying to harm bitcoin by blocking a valuable optimization. :-/
216 2017-04-06 19:30:57	0|gmaxwell|CodeShark: oh no, I expected them to just deny having used it flat out.
217 2017-04-06 19:30:57	0|wumpus|well denying that their hardware implements it would be pointless, so they fall back to denying they use it
218 2017-04-06 19:31:08	0|gmaxwell|I didn't expect the rant full of trivially falsifyable claims.
219 2017-04-06 19:31:29	0|wumpus|saying they don't use it 'for the sake of bitcoin' can't be jived with saying it's a valuable optimization though
220 2017-04-06 19:31:38	0|jcorgan|very few people to whom that rant was addressed will care to try to falsify them
221 2017-04-06 19:31:49	0|CodeShark|truth isn't the point
222 2017-04-06 19:31:49	0|wumpus|if it shouldn't be used for the good of bitcoin, your BIP is exactly what they should adopt too
223 2017-04-06 19:31:56	0|wumpus|truth is the point, for us
224 2017-04-06 19:32:00	0|gmaxwell|There is so much just simply untrue in it that I don't know where to respond.  Baiscally I was prepared for a "We don't use it!" to which my response would be "Great, then you'll support activating this fix so no one else does and gains an advantage on you, right?"
225 2017-04-06 19:32:05	0|CodeShark|yeah, but not for the intended audience
226 2017-04-06 19:32:09	0|wumpus|we're trying to do development here, not politics
227 2017-04-06 19:32:13	0|CodeShark|lol
228 2017-04-06 19:32:16	0|wumpus|the intended audience of this channel is core devs
229 2017-04-06 19:32:20	0|sipa|wumpus: +1
230 2017-04-06 19:32:27	0|CodeShark|yes, so this is not the best place for this discussion
231 2017-04-06 19:32:33	0|jcorgan|yeah, sorry
232 2017-04-06 19:32:47	0|wumpus|well it's fine to mention it. I'm sure we want the BIP implemented in bitcoin core?
233 2017-04-06 19:33:12	0|morcos|wumpus: i'd say we want if if we think there is community support
234 2017-04-06 19:33:24	0|morcos|that should be our stance on all consensus changes
235 2017-04-06 19:33:39	0|sipa|agree
236 2017-04-06 19:33:41	0|jonasschnelli|morcos: how do you measure "community support"?
237 2017-04-06 19:33:49	0|jonasschnelli|reddit?
238 2017-04-06 19:33:53	0|sipa|jonasschnelli: it's complicated
239 2017-04-06 19:33:57	0|morcos|its hard to measure obviously... but letting the dust settle a bit is a starting point
240 2017-04-06 19:34:14	0|jtimon|let's move the discussion to #bitcoin ?
241 2017-04-06 19:34:19	0|wumpus|ok, if we're not sure whether we want it, this is not the place to discuss it
242 2017-04-06 19:34:35	0|jtimon|I mean, I think as a technical proposal it belongs in here
243 2017-04-06 19:34:38	0|wumpus|otherwise the next question would have been how, and who is going to write the code
244 2017-04-06 19:34:40	0|jonasschnelli|And I guess there is great uncertainty in the community.
245 2017-04-06 19:35:20	0|wumpus|well there is quite certainly that the sneaky form of asicboost should be banished
246 2017-04-06 19:35:39	0|jonasschnelli|Yes. Indeed.
247 2017-04-06 19:36:04	0|jonasschnelli|Will it be a miner activated soft fork? :-)
248 2017-04-06 19:36:11	0|wumpus|whether that BIP is the best solution to that is indeed open, indeed makes sense for the dust to settle on that, though it may still make sense to have actual code
249 2017-04-06 19:36:32	0|morcos|i think in a clean room protocol design then, yes it shoudl be banished...  it people were using it, and keeping it quiet for competitive advantage, that seems a quasi-reasonable action to me.
250 2017-04-06 19:37:21	0|morcos|so if we want to ban the merkle-root form b/c it isn't good for the protocol (which i agree with), it's fair to give some time to not immediately obsolete hardware made with fair intention (hypothetically speaking)
251 2017-04-06 19:37:25	0|wumpus|if people were using it, it should be banished, if people were not using it, it should also be banished to prevent it from being used. No miner would rationally want another miner to get a sneaky advantage on them.
252 2017-04-06 19:37:38	0|morcos|yes, if no one is using it.. then we don't need to have delay
253 2017-04-06 19:37:39	0|jonasschnelli|It's a sneaky form of optimisation that leads to more centralisation of mining, .. and therefor does not follow the idea of Satoshi IMO.
254 2017-04-06 19:37:49	0|morcos|but in all cases, it seems to me its somethign the community should decide not core
255 2017-04-06 19:38:02	0|wumpus|the BIP doesn't break normal mining hardware does it?
256 2017-04-06 19:38:03	0|morcos|it can be our recommendation that it should be banished at some point, for sure
257 2017-04-06 19:38:05	0|wumpus|unlike a PoW change
258 2017-04-06 19:38:27	0|jonasschnelli|I guess the community will decide if they run Core or no.
259 2017-04-06 19:38:28	0|morcos|but there seems to be no reason to continue to use it (covertly) now that it has been made public
260 2017-04-06 19:38:41	0|morcos|so one question is how compatible existing hardware is with switching to overt
261 2017-04-06 19:38:52	0|jcorgan|hopefully nobody made covert-only hardware
262 2017-04-06 19:38:53	0|morcos|if compatible.. then again , no reason to delay
263 2017-04-06 19:39:01	0|morcos|jcorgan: ha, good poitn i suppose!
264 2017-04-06 19:39:13	0|wumpus|if they did they just screwed themselves
265 2017-04-06 19:39:22	0|jtimon|wumpus: personally I am sure that we want it, because logic tells me that only people that plan to use it would oppose it, but if all miners use it nobody gains anything
266 2017-04-06 19:39:24	0|wumpus|though I'm sure all hardware supports mining without tricks
267 2017-04-06 19:40:06	0|jeremyrubin|I think we need to be very careful with how we brand any changes happening. The reason we would like to ban it is *NOT* because it is covert. It is because it is incomaptible with Bitcoin's incentive systems (e.g., transaction selection to maximiuze fees) and it interferes with protocol development.
268 2017-04-06 19:40:06	0|wumpus|it needs special support to be able to receive multiple roots, and if it can accept multiple roots it can also accept one
269 2017-04-06 19:40:07	0|gmaxwell|you can construct hardware that can ONLY use asicbost (or lose 3/4 of its hashpower) but it would be really stupid to do that, and I have seen no evidence that anyone does.
270 2017-04-06 19:41:02	0|jeremyrubin|In the future, you don't want some regulator charging in requesting feature changes to disable a "covert" bitcoin feature
271 2017-04-06 19:41:03	0|gmaxwell|wumpus: yes, though if you unroll the logic and route it, the getting only one would lose 3/4 of the hashpower. But that is not how Bitmain's is implemented...
272 2017-04-06 19:41:11	0|gmaxwell|(at least not in the chips they sell to the public)
273 2017-04-06 19:41:11	0|wumpus|jeremyrubin: again, this is not about branding, this channel is about development
274 2017-04-06 19:41:51	0|wumpus|gmaxwell: yes I don't think that's anything realistic
275 2017-04-06 19:41:52	0|jeremyrubin|I'm just saying the name "Covert" is misleading and does not lead to good technical undertsanding
276 2017-04-06 19:42:09	0|wumpus|it's pointless to start discussing language here
277 2017-04-06 19:43:28	0|rgrant|morcos: core must protect the protocol.  if this subverts it, by creating meaning in bits that should have no meaning, then core should take a stand on that.
278 2017-04-06 19:47:23	0|rgrant|one principled way to proceed would be to say that optimizations that harm intended extensibility will not be respected.
279 2017-04-06 19:47:48	0|jcorgan|i like the restraint in the original proposal, to make the protocol enhancing blockage stuff not do that, and decouple that from the optimization vs. attack discussion
280 2017-04-06 19:48:09	0|rgrant|jcorgan: sme
281 2017-04-06 19:48:12	0|rgrant|same
282 2017-04-06 19:49:25	0|jtimon|so on the developer side, I think we can introduce a per-deployment optional field that makes a given deployment activate instead of expire according to bip9, I guess that deserves it's own bip even if it's a simple extension of bip9, but the code is also easy to add and not very disruptive, and it seems something reasonable to have
283 2017-04-06 19:49:37	0|gmaxwell|jcorgan: Thank you, that is very much intended. And so its frustrating to see bitmain misrepresent it so completely.
284 2017-04-06 19:53:13	0|jcorgan|so i'd recommend that if something is done short term, it be entirely focused on that, with pushback by the team on any enthusiam to address the "overt" asicboost activity
285 2017-04-06 19:53:43	0|btcdrak|morcos: covert boost is switchable so it can, and should be disabled post haste (community willing ofc).
286 2017-04-06 19:55:26	0|morcos|yes, well apparently no one is using either version... so thats probably the biggest argument that no delay is needed
287 2017-04-06 19:56:49	0|gmaxwell|Yes, if the argument is that no one is using it yet, great!
288 2017-04-06 20:57:34	0|Chris_Stewart_5|jcorgan: I agree whole heartedly with *only* focusing on the covert (protocol blocking stuff) right now. Table the other discussion like you said
289 2017-04-06 20:58:07	0|Chris_Stewart_5|Thats going to be a much more interesting debate and I'm not sure where I fall on that one
290 2017-04-06 20:59:52	0|wumpus|that's also the only thing that gmaxwell's BIP covers
291 2017-04-06 20:59:54	0|jcorgan|me neither
292 2017-04-06 21:00:32	0|Chris_Stewart_5|Just to be clear, gmaxwell's BIP can be withdrawn if segwit is activated right?
293 2017-04-06 21:00:59	0|Chris_Stewart_5|if we are focusing on covert usage
294 2017-04-06 21:01:09	0|BlueMatt|Chris_Stewart_5: kinda, segwit is very deliberately designed to allow miners to not mine segwit txn, but the problem is likely self-correcting then - you're losing out on fees for asicboost
295 2017-04-06 21:01:30	0|BlueMatt|(ie you can skip the witness commitment, but only if you dont mine segwit txn)
296 2017-04-06 21:08:47	0|gmaxwell|Chris_Stewart_5: segwit also satisifies my BIP.  The bip lets you either include the segwit commitment OR another segwit incompatible commitment.
297 2017-04-06 21:09:13	0|gmaxwell|I structured it this way so parties that already had segwit would need zero additional work, and parties that didn't want segwit could support this bip without supporting segwit in any way.
298 2017-04-06 21:10:01	0|gmaxwell|personally I do not believe these parties exist, but we shouldn't create a vulnerablity in the proposal where people could dishonestly argue against segwit to stop the proposal (which is the problem I think we've been having)
299 2017-04-06 21:23:16	0|jcorgan|perhaps it would be better to move away from overt/covert terminology and use something like 'forward compatible/incompatible'
300 2017-04-06 21:24:07	0|jcorgan|that focuses on the technical side without motivationally tinged wording
301 2017-04-06 21:26:23	0|rgrant|jcorgan:  "FairHeader" has gained a following already in #bitcoin.  "forward compatible" might stir up big blockers.
302 2017-04-06 21:26:43	0|jcorgan|ugh
303 2017-04-06 21:27:06	0|jcorgan|"fair" is a completely subjective and political term
304 2017-04-06 21:27:45	0|rgrant|so is "forward".  got anything more descriptive?
305 2017-04-06 21:27:48	0|jcorgan|but perhaps this particular thing should stay in #bitcoin, sorry guys
306 2017-04-06 21:29:07	0|Eagle[TM]|whether to make it a UASF (not specifically endorsed by core) or to include it in core code is something to consider
307 2017-04-06 21:36:25	0|bitcoinreminder_|could you release a binary for this covert asic boost bug?
308 2017-04-06 21:36:40	0|bitcoinreminder_|i think a lot of people are already waiting for it :D
309 2017-04-06 21:37:57	0|Eagle[TM]|i don't think it's even clear yet whether it's done as an UASF or a MASF
310 2017-04-06 21:39:49	0|bitcoinreminder_|hm ok.. :/
311 2017-04-06 21:42:34	0|abpa|UASF can be done by Core, just not without community support
312 2017-04-06 21:43:01	0|abpa|MASF for fixing AntBleed can't work
313 2017-04-06 21:43:18	0|abpa|Sorry I mean covert asicboost
314 2017-04-06 21:43:25	0|bitcoinreminder_|I also think we should really try UASF this time.. I also think the support is overwhelming
315 2017-04-06 21:43:36	0|abpa|It's really for #bitcoin discussion not #bitcoin-core-dev
316 2017-04-06 21:44:29	0|BlueMatt|lol, lots of new people here tonight
317 2017-04-06 21:44:36	0|sturles|An UASF would need support from a supermajority of exchanges and payment processors, and preferably as many merchants as possible dealing with bitcoin directly.
318 2017-04-06 21:44:50	0|sturles|And I don't think that will be a problem.
319 2017-04-06 21:45:18	0|sturles|Theese days you can buy beer with testnet coins, as long as you use LN..
320 2017-04-06 21:45:39	0|BlueMatt|sturles: nonononono, that was a one-night thing...if it turns into a regular thing we have to reset testnet :(
321 2017-04-06 21:46:17	0|BlueMatt|(and, before you ask, testnet doesnt get consensus-requirements...wumpus is the appointed holy leader and less-than-benevolent dictator for life of testnet :p)
322 2017-04-06 21:47:34	0|Eagle[TM]|BlueMatt: it's just when things are getting really interesting, 2nd tier style reddit doesn't do it anymore. people crawling out of the woodwork
323 2017-04-06 21:47:37	0|bitcoinreminder_|would someone be so nice to create an unofficial UASF implementation? you dont have to sign or compile it, just the code would be fine for me?
324 2017-04-06 21:47:52	0|BlueMatt|less-than-benevolent because he gets to maximize for zero value....
325 2017-04-06 21:48:18	0|BlueMatt|bitcoinreminder_: the proposal is far from done, needs constants, not now, no
326 2017-04-06 21:48:45	0|bitcoinreminder_|damn :D
327 2017-04-06 21:49:05	0|bitcoinreminder_|is there any suggestion already at least for a version string?
328 2017-04-06 21:50:05	0|bitcoinreminder_|sorry for my impatience :D
329 2017-04-06 21:50:34	0|jcorgan|patience is a virtue well-honed by participation in the bitcoin world :-)
330 2017-04-06 21:50:39	0|Eagle[TM]|bitcoinreminder_: give it time. even core devs need sleep from time to time.
331 2017-04-06 21:51:21	0|bitcoinreminder_|unfortunately :D No thanks guys, for your great work.. really :)
332 2017-04-06 22:04:05	0|BlueMatt|yea, at least the folks at fc went to bed an hour ago, and I'm off now
333 2017-04-06 22:05:15	0|bitcoinreminder_|good night you heros of the magic internet money :)