1 2016-03-10 03:55:55	0|GitHub50|[13bitcoin] 15jtimon opened pull request #7665: Contrib: Introduce script to tag compiled binaries for convenience (py) (06master...060.12.99-contrib-tag) 02https://github.com/bitcoin/bitcoin/pull/7665
  2 2016-03-10 10:05:03	0|GitHub191|[13bitcoin] 15MarcoFalke opened pull request #7666: [0.12.1] Fix doc and output for rpcauth (060.12...06Mf1603-012fixdocrpcauth) 02https://github.com/bitcoin/bitcoin/pull/7666
  3 2016-03-10 11:00:13	0|go1111111|ok, thanks.
  4 2016-03-10 14:05:35	0|wumpus|go1111111: should be no reason to make a new pull request  - rather not - if you need help with git just let me know
  5 2016-03-10 14:06:20	0|wumpus|I've listed the steps in various PRs scattered over the place, probably would make sense to add it to some developer faw
  6 2016-03-10 14:06:22	0|wumpus|faq
  7 2016-03-10 17:15:06	0|morcos|btcdrak: ok. i got sucked in.  i'm writing rpc/p2p tests for 68/112/113.
  8 2016-03-10 17:16:26	0|morcos|i'm basically taking one of your tests that tests the activation logic and modifying to try many variations of different txs before and after soft fork activates and make sure they are accepted/rejected appropriately
  9 2016-03-10 17:53:39	0|btcdrak|morcos: we can never have enough test :)
 10 2016-03-10 17:58:02	0|morcos|btcdrak: well i was letting you know in case someone else was working on them
 11 2016-03-10 17:58:19	0|morcos|but as far as i know we don't have any other than the unit tests so far right?
 12 2016-03-10 18:09:31	0|sipa|morcos: awesome, thanks
 13 2016-03-10 18:09:55	0|sipa|so what is the current state of the pull request against my bip9 pr?
 14 2016-03-10 18:10:52	0|sipa|i agree with you that it makes sense to have separate tests for "50% of the past N blocks have a version we don't know", and one for "an unknowm versionbits deployment is lockedin/activated"
 15 2016-03-10 18:11:52	0|morcos|sipa: hmm, i guess thats up to you
 16 2016-03-10 18:12:09	0|sipa|though the latter one should be permanent i think... if you happened to be offline during the window in which it activated, you won't ever know itherwise
 17 2016-03-10 18:12:25	0|morcos|what do you mean by permanent?
 18 2016-03-10 18:12:30	0|sipa|that was a downside we get from bit flags that expire: they are not visible forever
 19 2016-03-10 18:12:52	0|morcos|i guess its not clear to me how these alerts work
 20 2016-03-10 18:13:02	0|morcos|if you're not using QT, there is no permanent way is there?
 21 2016-03-10 18:13:04	0|sipa|if any vb deployment ever activated in your currently active blockchain, you get a warning
 22 2016-03-10 18:13:25	0|sipa|eh, no clue what qt does
 23 2016-03-10 18:13:33	0|morcos|so right now that strMiscWarning isn't displayed in the errors field
 24 2016-03-10 18:13:38	0|morcos|i don't think
 25 2016-03-10 18:13:48	0|sipa|hmm?
 26 2016-03-10 18:14:08	0|morcos|so the errors that are printed in getInfo won't include this
 27 2016-03-10 18:14:11	0|morcos|i think
 28 2016-03-10 18:14:14	0|morcos|even for ISM soft forks
 29 2016-03-10 18:14:25	0|morcos|the only way you see it is if you look at your debug log
 30 2016-03-10 18:14:33	0|morcos|or if you're using QT or the -alertnotify script
 31 2016-03-10 18:14:49	0|sipa|what?
 32 2016-03-10 18:14:52	0|sipa|really?
 33 2016-03-10 18:14:59	0|morcos|maybe?
 34 2016-03-10 18:15:08	0|sipa|well, i have no counterevidence
 35 2016-03-10 18:15:38	0|sipa|so i think that needs investigating
 36 2016-03-10 18:15:49	0|morcos|maybe i taket hat back
 37 2016-03-10 18:15:52	0|morcos|sorry, let me see
 38 2016-03-10 18:16:59	0|morcos|yeah i think thats right
 39 2016-03-10 18:17:09	0|morcos|look at GetWarnngs in main.cpp
 40 2016-03-10 18:17:23	0|morcos|strRPC isn't updated by strMiscWarning
 41 2016-03-10 18:17:35	0|sipa|heh
 42 2016-03-10 18:17:46	0|sipa|that variable name does not even look familiar to me
 43 2016-03-10 18:18:57	0|morcos|i also find it a bit disturbing that one warning can wipe out another
 44 2016-03-10 18:19:37	0|sipa|i doubt i have ever looked at that code
 45 2016-03-10 18:20:40	0|morcos|so for instance if PartitionCheck causes "abnormally high number of blocks" that wipes out your warning that a soft fork has activated
 46 2016-03-10 18:20:58	0|morcos|and even in the ISM code, that warning only happens once
 47 2016-03-10 18:24:09	0|morcos|so....  i'm going to quietly slink away and go back to my test writing...
 48 2016-03-10 18:26:20	0|sipa|we should probably concatenate all warnings...
 49 2016-03-10 18:26:27	0|sipa|and have a boolean for "serious" or so
 50 2016-03-10 18:26:59	0|sipa|that can make RPCs fail or the GUI show bigger animated themed warning boxes
 51 2016-03-10 18:27:08	0|morcos|yeah i think the quick and dirty way is to have separate variables though for each of the warnings
 52 2016-03-10 18:27:24	0|morcos|b/c some occur repeatedly or can get cleared out or whatever
 53 2016-03-10 18:27:39	0|morcos|and then the display mechanism can check each one and do the right thing?
 54 2016-03-10 18:27:58	0|sipa|yeah
 55 2016-03-10 18:28:55	0|morcos|i guess it wouldn't be that hard to just have a set of strings, and then you can clear them to
 56 2016-03-10 18:28:56	0|sipa|anyway, the point i was trying to make (and which is independent of the warning presentation problem) is that imho a versionbits deployment from anywhere in your past should remain visible (but probably should not be considered serious)
 57 2016-03-10 18:29:21	0|morcos|wait, an unknown one should not be considered serious?
 58 2016-03-10 18:30:30	0|gmaxwell|Meeting in half an hour, everyone should think back to all the great topics we ran out of time for last week and have them ready for the agenda this time.
 59 2016-03-10 18:31:42	0|morcos|sipa: i suppose what we could do is everytime you start the node we rescan for unknown deployments from the beginning (which would speak to using a real cache)..  b/c otherwise there is a risk that you shutdown your old node and when you restart it you've lost the warning, is that what you meant?
 60 2016-03-10 18:32:00	0|sipa|morcos: i think that the presence of an unknown softfork should not be treated as something serious
 61 2016-03-10 18:32:18	0|sipa|morcos: or just have a versionbits cache per bit for warnings
 62 2016-03-10 18:32:24	0|sipa|without special logic
 63 2016-03-10 18:32:39	0|morcos|sipa: yes thats what i meant by speaking to using a real cache
 64 2016-03-10 18:32:48	0|morcos|perhaps its worth the 300k extra memory
 65 2016-03-10 18:32:58	0|morcos|but why isn't it serious?
 66 2016-03-10 18:33:06	0|morcos|i think it should be considered quite serious
 67 2016-03-10 18:33:23	0|morcos|we have in the past, we told you your node was obsolete and you must upgrade
 68 2016-03-10 18:33:42	0|morcos|there is no way to know whether the soft fork was relatively benign or not
 69 2016-03-10 18:34:08	0|morcos|but if we give the information on the bit/activation height, then it should be easy for people to look up that soft fork, and decide for themselves whether they care
 70 2016-03-10 18:34:28	0|morcos|but to suhas's point, thats why its important to be able to warn on the same bit more than once?
 71 2016-03-10 18:35:51	0|sipa|hmm
 72 2016-03-10 18:35:59	0|sipa|maybe i misunderstood the code
 73 2016-03-10 18:36:15	0|sipa|it seemed to me that it would not catch historical deployments
 74 2016-03-10 18:37:33	0|morcos|my code will catch historical deployments but only once
 75 2016-03-10 18:37:47	0|morcos|i mean once per each deployment, will catch multiple on the same bit
 76 2016-03-10 18:52:24	0|morcos|so sipa, i think if it were me, i'd just change my PR to run on start up on the entire blockchain, instead of actually populating a cache that is mostly usless and whose only effect is to obscure multiple deployments on the same bit
 77 2016-03-10 18:55:49	0|sipa|ok
 78 2016-03-10 18:56:51	0|gmaxwell|sipa: morcos: sdaftuar: petertodd: btcdrak: wumpus: cfields_: jonasschnelli: phantomcircuit: BlueMatt: jtimon: CodeShark: NicolasDorier: paveljanik:  meetin in 4 minutes.
 79 2016-03-10 18:56:57	0|jonasschnelli|here!
 80 2016-03-10 18:56:58	0|BlueMatt|ahhhhhh
 81 2016-03-10 18:57:00	0|BlueMatt|taggggggg
 82 2016-03-10 18:57:05	0|btcdrak|present!
 83 2016-03-10 18:57:27	0|wumpus|yep
 84 2016-03-10 18:57:37	0|sipa|here
 85 2016-03-10 18:57:46	0|warren|here
 86 2016-03-10 18:57:48	0|morcos|sipa: so do you want me to make changes?
 87 2016-03-10 18:57:54	0|btcdrak|it's like being in school again :)
 88 2016-03-10 18:58:26	0|sipa|morcos: go ahead
 89 2016-03-10 18:58:33	0|jcorgan|not invited but still here :-)
 90 2016-03-10 18:58:34	0|gmaxwell|(sorry to ping, but we've had slow starts and time shortfalls recently)
 91 2016-03-10 18:59:59	0|lightningbot|Meeting started Thu Mar 10 18:59:59 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
 92 2016-03-10 18:59:59	0|lightningbot|Useful Commands: #action #agreed #help #info #idea #link #topic.
 93 2016-03-10 18:59:59	0|wumpus|#startmeeting
 94 2016-03-10 19:00:02	0|wumpus|topics?
 95 2016-03-10 19:00:23	0|evoskuil|here
 96 2016-03-10 19:01:05	0|morcos|we have a list of remaining segwit items that were written on whiteboard at MIT...  should we assign those?
 97 2016-03-10 19:01:16	0|wumpus|sure
 98 2016-03-10 19:01:43	0|wumpus|#topic remaining segwit items
 99 2016-03-10 19:01:56	0|jonasschnelli|I'm happy to help,... probably in the wallet section.
100 2016-03-10 19:02:05	0|morcos|seems to me it would nice to buckle down and prioritize  BIP 9,  BIPs 68,112,113  ,   segwit.   i mean i think we are all working on those things, but there is still more to do on all of them
101 2016-03-10 19:02:05	0|sipa|my plan was to rebase segwit on top of bip9, add the rewind logic to continie after post-softfork uograde, and do a new testnet
102 2016-03-10 19:02:10	0|sipa|eh, new segnet
103 2016-03-10 19:02:21	0|btcdrak|great
104 2016-03-10 19:02:33	0|CodeShark|when do you think to deploy the new testnet?
105 2016-03-10 19:02:40	0|sdaftuar|we also need to discuss standardness rules
106 2016-03-10 19:02:50	0|sdaftuar|(or rather, propose and discuss)
107 2016-03-10 19:02:55	0|warren|What was decided for safety on the edge of the rule change in case of reorg?
108 2016-03-10 19:03:45	0|morcos|I think my suggestion would be to push that problem to wallet users
109 2016-03-10 19:03:49	0|sdaftuar|warren: i believe we decided to advise wallet authors to wait some time after segwit activates before using
110 2016-03-10 19:03:51	0|sipa|one possibility is not enabling relay/mempool logic for segwit transactions until 2 period after activatation
111 2016-03-10 19:03:56	0|morcos|yes authors i meant
112 2016-03-10 19:04:04	0|gmaxwell|warren: I don't understand the context of your question.  Generall new soft fork rules should not be used immediately.
113 2016-03-10 19:04:14	0|sipa|another is to just be cautious and nit enable the functionality in wallets until a post segwit release
114 2016-03-10 19:04:15	0|sdaftuar|gmaxwell: this one is more dangerous than usual though
115 2016-03-10 19:04:24	0|gmaxwell|sdaftuar: it's just like p2sh.
116 2016-03-10 19:04:29	0|warren|OK, that seems adequate enough.
117 2016-03-10 19:04:42	0|CodeShark|I'm not that concerned about edge case reorg situations
118 2016-03-10 19:04:55	0|morcos|gmaxwell: its a bit riskier than p2sh...  don't need a preimage
119 2016-03-10 19:04:55	0|sipa|it's not situation*s*
120 2016-03-10 19:05:08	0|gmaxwell|in core I would recommend that we would switch to using segwit as default in a subsiquent release after the SF activates.
121 2016-03-10 19:05:40	0|jonasschnelli|so have it ready and auto-use it whiteout creating another release?
122 2016-03-10 19:05:59	0|morcos|so in any case, i think we just advise wallet authors to wait some minimum amount of time after activation to send segwit txs.. they are already going to have to put in some code to wait until it activates
123 2016-03-10 19:06:00	0|jonasschnelli|*without
124 2016-03-10 19:06:01	0|CodeShark|either wait until next release - or wait a few blocks after activation before enabling it in wallet
125 2016-03-10 19:06:11	0|sipa|ok
126 2016-03-10 19:06:43	0|jonasschnelli|auto-enable in in the wallet after 95%?
127 2016-03-10 19:06:47	0|gmaxwell|no.
128 2016-03-10 19:06:57	0|btcdrak|I think better to wait a release code afterwards
129 2016-03-10 19:06:58	0|sipa|not even at 100%
130 2016-03-10 19:07:19	0|jonasschnelli|Okay. Then do it over the release-cycle..
131 2016-03-10 19:07:31	0|gmaxwell|I recommend using a release. Automatic behavior is not needed here. Also-- it's a pretty big behavioral change to use it, e.g. you'd be issuing other address styles in response.
132 2016-03-10 19:07:43	0|jonasschnelli|Agree.
133 2016-03-10 19:07:48	0|morcos|also we haven't written that code yet anyway
134 2016-03-10 19:07:52	0|sipa|that is an open question
135 2016-03-10 19:07:53	0|jonasschnelli|I just think there is a hight incentive to use it (fees)
136 2016-03-10 19:07:54	0|CodeShark|this is something that can be decided once segwit has already been deployed and is awaiting activation
137 2016-03-10 19:07:56	0|gmaxwell|having that triggered by invisible-to-the-user network behavior isn't reat.
138 2016-03-10 19:08:16	0|gmaxwell|great*
139 2016-03-10 19:08:31	0|sipa|i wish we had an address style for segwit part of the standard :(
140 2016-03-10 19:09:10	0|gmaxwell|sipa: no you don't. Deploying a new address style takes forever. :P what you wish for is a magic wand.
141 2016-03-10 19:09:15	0|btcdrak|sipa I thought we did? BIP142?
142 2016-03-10 19:09:37	0|CodeShark|btcdrak: we haven't been pushing it because of concerns regarding scary "new addresses"
143 2016-03-10 19:09:41	0|jonasschnelli|P2WPKH?
144 2016-03-10 19:09:53	0|morcos|i think we should do that though, otherwise everyone is going to embed them in p2sh which is kind of silly
145 2016-03-10 19:09:53	0|sipa|i think we have more buy-in from wallet authors about segwit now, than p2sh had at the timr
146 2016-03-10 19:10:22	0|CodeShark|p2sh was almost entirely under the radar as far as the community at large
147 2016-03-10 19:10:24	0|gmaxwell|also, continued use of base58 is awful. I am going to refuse to discuss address encodings with anyone who hasn't read an address to me over the phone. :)
148 2016-03-10 19:10:47	0|btcdrak|CodeShark: I would suggest brining it back. There's no problem.
149 2016-03-10 19:10:57	0|gmaxwell|CodeShark: thats not the case; besides there is a material difference in the sheer mass of code that must be updated. Besides why is this being discussed there.
150 2016-03-10 19:11:02	0|CodeShark|btcdrak: there sort of is a problem still...
151 2016-03-10 19:11:05	0|gmaxwell|btcdrak: I oppose it in the strongest possible terms.
152 2016-03-10 19:11:08	0|CodeShark|both internal and external
153 2016-03-10 19:11:22	0|btcdrak|CodeShark: you can change you mind :)
154 2016-03-10 19:11:33	0|CodeShark|internally some people hate base58, externally some people are still grandstanding with the "segwit is too hard" crap
155 2016-03-10 19:11:56	0|BlueMatt|gmaxwell: there is certain value in user expectations of things that look like base58
156 2016-03-10 19:12:13	0|CodeShark|I think it's a battle not worth fighting right now
157 2016-03-10 19:12:18	0|jonasschnelli|+1
158 2016-03-10 19:12:22	0|btcdrak|+1
159 2016-03-10 19:12:24	0|morcos|gmaxwell: whats your number
160 2016-03-10 19:12:29	0|jonasschnelli|haha
161 2016-03-10 19:12:31	0|gmaxwell|BlueMatt: You are on subject-matter-ignore until you call me and successfully read me a base58 address.  :)
162 2016-03-10 19:13:04	0|sipa|i would really like to have some psegwit afdressddress as part of the "package"
163 2016-03-10 19:13:10	0|gmaxwell|morcos: PM :P
164 2016-03-10 19:13:40	0|BlueMatt|gmaxwell: I'm not suggesting I'm necessarily in support of base58 addresses, but my point is that it is not up to us here to figure out addressing for segwit...that is something WALLETS need to be involved in...people who actually have some ux experience, which does not exist here
165 2016-03-10 19:14:16	0|morcos|gmaxwell: BlueMatt says "..."
166 2016-03-10 19:14:17	0|gmaxwell|yes indeed. but thats also why taking on a new address type at the same time is not a good idea, it would get in the way of that kind of collaboration.
167 2016-03-10 19:14:22	0|gmaxwell|hahha
168 2016-03-10 19:14:30	0|BlueMatt|agreed
169 2016-03-10 19:14:30	0|sipa|do you think so?
170 2016-03-10 19:14:37	0|sipa|i think it's the opposite
171 2016-03-10 19:14:46	0|BlueMatt|I think the idea of pushing off address types for segwit for broader feedback is a good thing
172 2016-03-10 19:14:47	0|Luke-Jr|sipa: that was a lot of backspaces.
173 2016-03-10 19:15:07	0|CodeShark|good UI design wouldn't even burden users with having to deal with copy/pasting cryptographic keys
174 2016-03-10 19:15:20	0|CodeShark|but that's an entirely separate discussion
175 2016-03-10 19:15:28	0|Luke-Jr|FWIW, I've been thinking of implementing the payment protocol better in Core
176 2016-03-10 19:15:37	0|Luke-Jr|including the new BIP 75 stuff
177 2016-03-10 19:15:39	0|jonasschnelli|We are far away from designing the UX... this is a topic we can talk about in 2-3 years.
178 2016-03-10 19:16:33	0|sipa|:)
179 2016-03-10 19:16:42	0|jonasschnelli|But sipa: is the P2WPKH address type not okay?,.. addresses like "p2xtZoXeX5X8BP8JfFhQK2nD3emtjch7UeFm"?
180 2016-03-10 19:16:42	0|sipa|ok, let's postpone that address discussion
181 2016-03-10 19:16:53	0|sipa|jonasschnelli: you mean bip142?
182 2016-03-10 19:17:08	0|jonasschnelli|Yes. Easy to handle by existing wallets?
183 2016-03-10 19:17:17	0|BlueMatt|jonasschnelli: ACK
184 2016-03-10 19:17:23	0|gmaxwell|sipa was raising the concern that if something weren't done sooner we'd be left stuck with 80 bit security forever, I reminded him in PM that we have an upcoming checksig improvement to reduce transaction sizes by 30% which would be a nice time to do a new address type too. :)
185 2016-03-10 19:17:42	0|wumpus|would be good to have concrete proposals for address formats ,say as BIPs
186 2016-03-10 19:17:49	0|CodeShark|we'll have plenty of opportunities to introduce new stuff in the future
187 2016-03-10 19:17:59	0|CodeShark|right now we should focus on the path of least resistance
188 2016-03-10 19:18:14	0|sipa|the reason against incorporating bip142 is people yelling "see! sehwit needs new address types! everyone has to upgrade! not backward compatible!"
189 2016-03-10 19:18:17	0|gmaxwell|The amount going on right now is too great to be able to afford forced seralization.
190 2016-03-10 19:18:26	0|CodeShark|eventually my hope is we'll actually have a competent ecosystem that can actually do tech
191 2016-03-10 19:18:36	0|CodeShark|but for now we must deal with what we have
192 2016-03-10 19:18:39	0|morcos|Yeah I think it would make a lot of sense to release just the P2WPKH address
193 2016-03-10 19:18:44	0|Luke-Jr|sipa: we could add sending support, and discourage anyone from using it to receive for now
194 2016-03-10 19:18:45	0|jonasschnelli|sipa: You could still uses it over P2SH... but we don't live for the critics.
195 2016-03-10 19:18:56	0|morcos|sipa: don't you think everyone is going to say that even more if we don't have address types
196 2016-03-10 19:19:12	0|sipa|i don't know
197 2016-03-10 19:19:19	0|sipa|i'm an engineer, not a marketer
198 2016-03-10 19:19:31	0|jonasschnelli|+1 for P2WPKH bip142
199 2016-03-10 19:19:43	0|wumpus|shouldn't be expected from you to act as marketeer sipa
200 2016-03-10 19:19:47	0|wumpus|you have enough on your plate
201 2016-03-10 19:19:51	0|sipa|next topic?
202 2016-03-10 19:19:59	0|CodeShark|yes please
203 2016-03-10 19:20:07	0|wumpus|suggestions?
204 2016-03-10 19:20:23	0|Luke-Jr|(I don't see value in p2wpkh, but let's move on)
205 2016-03-10 19:21:13	0|wumpus|ok, if not, that was a quick meeting
206 2016-03-10 19:21:28	0|gmaxwell|there were many things last week that got cut off.
207 2016-03-10 19:21:29	0|wumpus|(I'm still too tired and jetlaggy to contribute much now)
208 2016-03-10 19:21:37	0|jonasschnelli|If no one has something important... what do you think about my approach of IBD with a pregenerated signed UTXOset?
209 2016-03-10 19:21:57	0|btcdrak|Can I ask people to review the backport PRs for BIP68 and 112? They were straight cherry-picks into 0.12 but they do need a couple eyes on them.
210 2016-03-10 19:22:10	0|morcos|jonasschnelli: i think thats a bad idea
211 2016-03-10 19:22:11	0|Luke-Jr|jonasschnelli: sounds like a waste of time at best, to be frank. :x
212 2016-03-10 19:22:23	0|wumpus|#action review backport PRs for BIP68 and 112
213 2016-03-10 19:22:33	0|morcos|jonasschnelli: core devs (or anybody for that matter) should not be authorizing the state of the ledger at any time
214 2016-03-10 19:22:40	0|wumpus|#topic IBD with a pregenerated signed UTXOse
215 2016-03-10 19:22:52	0|wumpus|it's risky, it brings trust into the system
216 2016-03-10 19:22:56	0|Luke-Jr|much prefer to see SPV mode until IBD completes
217 2016-03-10 19:23:15	0|jonasschnelli|Luke-Jr: Yes. Agree.
218 2016-03-10 19:23:19	0|wumpus|who would you trust to sign something like that?
219 2016-03-10 19:23:30	0|sipa|Bob.
220 2016-03-10 19:23:32	0|jonasschnelli|Just thought we might want to reduce the amount of block-serving even more.
221 2016-03-10 19:23:36	0|wumpus|yes, definitely Bob
222 2016-03-10 19:23:38	0|Luke-Jr|XD
223 2016-03-10 19:23:52	0|jonasschnelli|wumpus: could be signed by the same users/devs who are signing the gitian builds.
224 2016-03-10 19:24:00	0|sipa|jonasschnelli: that's not reducing block serving; it's changing the trust model instead
225 2016-03-10 19:24:22	0|jonasschnelli|I agree. It does change the trust model.
226 2016-03-10 19:24:24	0|wumpus|jonasschnelli: hmm don't put too much on their shoulders
227 2016-03-10 19:24:27	0|CodeShark|without TXO commitments it's unfixable
228 2016-03-10 19:24:31	0|CodeShark|:p
229 2016-03-10 19:24:35	0|morcos|if we go back to the backport question, we also need to backport all these SF's to 0.11 is that correct?
230 2016-03-10 19:24:55	0|jonasschnelli|Okay... so. Then let me not implement it. :)
231 2016-03-10 19:25:01	0|wumpus|yea, UTXO commitments would make this somewhat more realistic, although it'd still reduce the overall trust model to SPV
232 2016-03-10 19:25:21	0|wumpus|jonasschnelli: yes, better not for now I think
233 2016-03-10 19:25:27	0|wumpus|#topic backports to 0.11
234 2016-03-10 19:25:33	0|gmaxwell|morcos: I was thinking about this this morning. The normal release cadance would have us do so, I believe.
235 2016-03-10 19:25:42	0|jonasschnelli|SPV during IBD and a throttled(CPU) IBD is the better approach.
236 2016-03-10 19:26:03	0|wumpus|jonasschnelli: yes, definitely those would be good to have
237 2016-03-10 19:26:07	0|Luke-Jr|how practical is it to backport to 0.10?
238 2016-03-10 19:26:14	0|warren|why 0.10?
239 2016-03-10 19:26:20	0|sipa|0.10 and 0.11 are close
240 2016-03-10 19:26:20	0|wumpus|topic is backport to 0.11 Luke-Jr :p
241 2016-03-10 19:26:22	0|morcos|0.10?  i'd hoped you guys would be willing to skip 0.11
242 2016-03-10 19:26:29	0|sipa|but agree; just 0.11
243 2016-03-10 19:26:32	0|btcdrak|morcos: I would skip 0.11
244 2016-03-10 19:26:38	0|sipa|we have a published release schedule, no?
245 2016-03-10 19:26:51	0|Luke-Jr|sipa: of guaranteed support, not limited-to
246 2016-03-10 19:26:51	0|wumpus|I think backporting to 0.11 is fairly necessary, that's only one release back
247 2016-03-10 19:27:07	0|Luke-Jr|0.11 is necessary; 0.10 would be ideal
248 2016-03-10 19:27:09	0|morcos|wumpus: i suppose, i'm worried about how well tested these major changes will be
249 2016-03-10 19:27:20	0|Luke-Jr|but I'll deal with 0.10 later I guess
250 2016-03-10 19:27:20	0|sipa|master, 0.12, 0.11
251 2016-03-10 19:27:24	0|jonasschnelli|0.10 is not necessary... we once agree in supporting only two major versions.
252 2016-03-10 19:27:28	0|btcdrak|sipa: our lifecycle doc is at https://bitcoincore.org/en/lifecycle/
253 2016-03-10 19:28:00	0|Luke-Jr|jonasschnelli: it was never agreed to drop support for older ones, only to not promise support for them; but that's on me for 0.10 I think
254 2016-03-10 19:28:05	0|wumpus|morcos: it's a challenge, but I think you can't get around it, some people won't be ready yet to upgrade to 0.12
255 2016-03-10 19:28:06	0|btcdrak|the backports to 0.12 are trivial, but 0.11 will be a little more annoying, especially for BIP68 I believe
256 2016-03-10 19:29:03	0|morcos|btcdrak: we should just backport them kind of altogether right?
257 2016-03-10 19:29:10	0|btcdrak|btw the backports for BIP68,112 are #7543 and #7544, I forgot to mention the numbers earlier
258 2016-03-10 19:29:14	0|morcos|i suppose they don't overlap that much
259 2016-03-10 19:29:31	0|morcos|i think i can make sure BIP68 for 0.11 backports properly
260 2016-03-10 19:30:01	0|btcdrak|morcos: you'd be the best person to backport BIP68 to 0.11.
261 2016-03-10 19:30:10	0|morcos|i will take the approach of not keeping the mempool consistent and checking sequence values in the mining code, which will probably not make much of an effect on the already absurdly slow mining code
262 2016-03-10 19:30:30	0|morcos|thats why 7187 was separate, that won't be backported to 0.11
263 2016-03-10 19:30:41	0|btcdrak|morcos: plenty miners have upgraded to 0.12 fwiw
264 2016-03-10 19:30:51	0|btcdrak|well pools*
265 2016-03-10 19:31:26	0|morcos|ok. i'll work on that
266 2016-03-10 19:31:33	0|wumpus|the other path would be to wait for 0.13, then only backport to 0.12, but then you'll have to wait 6 months :p
267 2016-03-10 19:31:49	0|Luke-Jr|>_<
268 2016-03-10 19:31:55	0|btcdrak|wumpus: nice joke there :-P
269 2016-03-10 19:31:58	0|wumpus|well not exactly 6 anymore but ok...
270 2016-03-10 19:32:14	0|wumpus|I don't think it's realistic no
271 2016-03-10 19:32:39	0|sipa|i think we can do 9/68/112/113 soon
272 2016-03-10 19:32:49	0|wumpus|aim for 0.13 would be july
273 2016-03-10 19:33:04	0|morcos|sipa: agreed!
274 2016-03-10 19:33:14	0|wumpus|sipa: I hope so!
275 2016-03-10 19:33:16	0|btcdrak|sipa: I also believe so. 68/112/113 are done from my side, morcos wants to add more RPC tests which is fine.
276 2016-03-10 19:33:22	0|morcos|did you ever reply to my comment on block version = 4
277 2016-03-10 19:33:29	0|morcos|btcdrak: there are NONE!
278 2016-03-10 19:33:42	0|CodeShark|any plans to remove the default version crap out of primitives?
279 2016-03-10 19:33:50	0|btcdrak|morcos: yes there are. same standard as for BIP65
280 2016-03-10 19:33:54	0|sipa|CodeShark: yes, see bip9
281 2016-03-10 19:34:12	0|sipa|morcos: it was needed in combination with the warning logic
282 2016-03-10 19:34:18	0|btcdrak|morcos: see #7648
283 2016-03-10 19:34:20	0|sipa|it may not be needed anymore with imoroved logic
284 2016-03-10 19:34:36	0|morcos|btcdrak: i saw, and i agree, BIP65 made it out withotu adequate tests
285 2016-03-10 19:35:05	0|sdaftuar|sipa: right now #7575 will revert back to version 4 blocks after the first soft fork activates, if no other soft forks are in the queue
286 2016-03-10 19:35:06	0|jonasschnelli|bip65 had rpc tests from petertodd?!
287 2016-03-10 19:35:13	0|sdaftuar|i assume that is unintentional?
288 2016-03-10 19:35:18	0|btcdrak|morcos: I would disagree they were not adaquet, you can always have more sure.
289 2016-03-10 19:35:25	0|btcdrak|bip65 had RPC tests.
290 2016-03-10 19:35:29	0|sipa|sdaftuar: that seems correct to mr
291 2016-03-10 19:35:38	0|sdaftuar|oh, i didn't realize that!
292 2016-03-10 19:35:50	0|morcos|sipa: huh?  correct as in you wanted that?
293 2016-03-10 19:36:02	0|sipa|the old version is used to indicate "no versionbits"
294 2016-03-10 19:36:04	0|btcdrak|bip68/112/113 have the p2p RPC tests in #7648
295 2016-03-10 19:36:30	0|sipa|morcos: yes, otherwise the version is ambiguous based on what software miners use, ignoring deploymemts
296 2016-03-10 19:36:37	0|sipa|which the warning logic can't deal with
297 2016-03-10 19:36:55	0|sipa|it must be absolute "these deployments -> this nVersion"
298 2016-03-10 19:37:04	0|morcos|sipa: all prior soft forks required minors to upgrade
299 2016-03-10 19:37:13	0|sipa|miners :p
300 2016-03-10 19:37:19	0|btcdrak|lol
301 2016-03-10 19:37:24	0|CodeShark|minors can always get a fake ID
302 2016-03-10 19:37:27	0|morcos|sipa: what i would like to do is with this first soft fork, require nVersion > 4
303 2016-03-10 19:37:44	0|sipa|why?
304 2016-03-10 19:37:50	0|btcdrak|morcos: why?
305 2016-03-10 19:37:51	0|morcos|then we can warn on anything that is not 001...  unless it is <=4 which we know are invalid
306 2016-03-10 19:38:00	0|morcos|that seems consistent with how we've done other soft forks
307 2016-03-10 19:38:09	0|morcos|there is an expected version number, unknown differences are warned on
308 2016-03-10 19:38:24	0|gmaxwell|so old software versions warn.
309 2016-03-10 19:38:34	0|gmaxwell|and continue warning.
310 2016-03-10 19:38:50	0|morcos|gmaxwell: yes, old software versions are incapable of noticing transient changes
311 2016-03-10 19:39:06	0|morcos|thats why we need to rework alerts/warning to correctly identify them now
312 2016-03-10 19:39:25	0|morcos|in fact if you turned off a 0.12 node for a couple months
313 2016-03-10 19:39:34	0|morcos|and then turned it back on after all these SF's activated
314 2016-03-10 19:39:36	0|morcos|you would have no idea
315 2016-03-10 19:39:43	0|morcos|even if you looked at your debug logs
316 2016-03-10 19:39:49	0|morcos|b/c the warning logic doesn't run in IBD
317 2016-03-10 19:40:08	0|morcos|i feel like that makes it a requirement that we permanently increase the version number
318 2016-03-10 19:40:24	0|sdaftuar|agreed
319 2016-03-10 19:40:51	0|sipa|wth are you talking about?
320 2016-03-10 19:40:56	0|morcos|who?
321 2016-03-10 19:41:01	0|CodeShark|I don't follow
322 2016-03-10 19:41:03	0|morcos|me?  which part?
323 2016-03-10 19:41:09	0|sipa|versionbits is deterministic based on the chain histotu
324 2016-03-10 19:41:17	0|morcos|yes 0.12 doesn't have version bits
325 2016-03-10 19:41:20	0|morcos|0.12.0
326 2016-03-10 19:41:24	0|CodeShark|after versionbits deployment, all block versions would be > 4
327 2016-03-10 19:41:26	0|sipa|ah
328 2016-03-10 19:41:28	0|gmaxwell|sipa: he's talking about software which doesn't have versionbits.
329 2016-03-10 19:41:31	0|sipa|oh, now i get it
330 2016-03-10 19:41:37	0|sipa|sorry
331 2016-03-10 19:41:43	0|morcos|CodeShark: thats what i'm trying to say, thats not how its written
332 2016-03-10 19:42:17	0|sipa|so increase to 5 after the first vb deployment?
333 2016-03-10 19:42:22	0|morcos|no no no
334 2016-03-10 19:42:23	0|morcos|not 5
335 2016-03-10 19:42:23	0|sdaftuar|why not increase to 001...?
336 2016-03-10 19:42:32	0|sdaftuar|consensus rule is >= 5 i guess
337 2016-03-10 19:42:38	0|morcos|just > 4, but you expect to see 001
338 2016-03-10 19:43:03	0|sipa|consensus >=4, but by default set 001...000....?
339 2016-03-10 19:43:16	0|morcos|>4
340 2016-03-10 19:43:18	0|morcos|yes
341 2016-03-10 19:43:57	0|jonasschnelli|morcos: but you should see it in the debug log? https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L2464
342 2016-03-10 19:44:13	0|jonasschnelli|Agree that we should also warn in IDB (but low prio IMO).
343 2016-03-10 19:44:14	0|sdaftuar|jonasschnelli: that code doesn't run during initialblockdownload
344 2016-03-10 19:44:35	0|morcos|the assumption is if you see something that starts with 001 you think you know whats happening and you're unknown activation detector can alert you with specific information
345 2016-03-10 19:44:51	0|jonasschnelli|Then lets improve that and BP.
346 2016-03-10 19:44:55	0|morcos|and if you see soemthing that doesn't start with 001  such as a 5  or  a 110...
347 2016-03-10 19:45:06	0|morcos|jonasschnelli: thats what we're doing , but we can't retroactively change old code
348 2016-03-10 19:45:29	0|CodeShark|110... would be treated as negative, no? because for some reason signed types were used
349 2016-03-10 19:45:31	0|morcos|then you assume that someone is doing something you really don't understand
350 2016-03-10 19:45:38	0|jonasschnelli|Yes. Sure... we might not be capable of warning for the next SF.
351 2016-03-10 19:45:41	0|morcos|CodeShark: sure i mean 010
352 2016-03-10 19:45:53	0|btcdrak|morcos: there is already 011 on the network too
353 2016-03-10 19:46:24	0|morcos|btcdrak: exactly, and we should be warning about that (and we are now) b/c its changes our software doesn't understand
354 2016-03-10 19:46:35	0|btcdrak|right
355 2016-03-10 19:46:38	0|morcos|and if > 50/100 blocks then we turn that warning into an alert
356 2016-03-10 19:47:55	0|jonasschnelli|Agree. But that raises also the question how to deploy an alert... debug.log? Yes. No.
357 2016-03-10 19:48:08	0|morcos|jonasschnelli: see scroll back before meeting
358 2016-03-10 19:48:52	0|morcos|sipa: so agreed that we should increase version number?  should i make a new BIP for that?  and we'll just soft fork it in at same time, or add to existing BIP
359 2016-03-10 19:49:25	0|sipa|morcos: consensus or not?
360 2016-03-10 19:49:53	0|morcos|sipa: consensus rule that nVersion must be >= 5.
361 2016-03-10 19:50:25	0|sipa|morcos: why consensus?
362 2016-03-10 19:50:31	0|btcdrak|morcos: confused
363 2016-03-10 19:50:59	0|CodeShark|before or after versionbits activation?
364 2016-03-10 19:51:02	0|CodeShark|still don't follow
365 2016-03-10 19:51:03	0|morcos|sipa: well i suppose it doesn't have to be a consensus rule...
366 2016-03-10 19:51:11	0|morcos|CodeShark: with the first SF that activates
367 2016-03-10 19:51:30	0|morcos|sipa: but i think its more clear to me that it doesn't have problems if it is a consensus rule
368 2016-03-10 19:51:36	0|morcos|b/c thats how the other ones worked
369 2016-03-10 19:51:44	0|gmaxwell|making it consensus would cause gratitious orphaning, which we were generally trying to avoid in the design of segwit.
370 2016-03-10 19:51:54	0|morcos|gmaxwell: this will be before segwit
371 2016-03-10 19:52:04	0|sipa|i prefer not introducing new consensus logic, especially when the only argument for it is better guarantees for warnings
372 2016-03-10 19:52:32	0|morcos|sipa: yes thats the only difference i see.  is that now we somehow can't warn on version = 4 blocks
373 2016-03-10 19:52:58	0|sipa|and if it's not consnesus, we can say bip9 miners without active rollouts use 001000...
374 2016-03-10 19:53:38	0|gmaxwell|I like 001000 in that it would encourage visualization tools to parse the bitfield instead of just displaying an integer.
375 2016-03-10 19:53:43	0|btcdrak|yes
376 2016-03-10 19:53:50	0|morcos|sipa: if its not a consensus rule, you can't be SURE that old nodes will be warned that the rules have changed... perhaps thats not worth worrying about
377 2016-03-10 19:54:27	0|btcdrak|That was my initial understanding that the new version would be 00100..0 when no sfs are being deployed
378 2016-03-10 19:54:27	0|sipa|miners can already cause total network forks
379 2016-03-10 19:54:28	0|morcos|its just cleaner to me
380 2016-03-10 19:54:38	0|sipa|are we worried that they can bypass a warning mechanism?
381 2016-03-10 19:54:50	0|btcdrak|sipa: no
382 2016-03-10 19:56:50	0|morcos|sipa: ok i guess. i'm ok with not making it a consensus rule..  but just seems weird to me...  i feel like we're transitioning from an old system to a new system, and the transition should conform to the old system
383 2016-03-10 19:57:08	0|gmaxwell|Lets wrap the metting now and talk more about warning after. Unless there are any other subject to squeek in at the end?
384 2016-03-10 19:57:10	0|wumpus|meeting: 3 minutes to go
385 2016-03-10 19:57:16	0|morcos|but as long as we make the default 00100  then i think its just theoretical concerns
386 2016-03-10 19:57:21	0|sipa|yeah
387 2016-03-10 19:58:17	0|lightningbot|Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-03-10-18.59.log.html
388 2016-03-10 19:58:17	0|lightningbot|Meeting ended Thu Mar 10 19:58:17 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
389 2016-03-10 19:58:17	0|lightningbot|Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-03-10-18.59.html
390 2016-03-10 19:58:17	0|lightningbot|Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-03-10-18.59.txt
391 2016-03-10 19:58:17	0|wumpus|#endmeeting
392 2016-03-10 19:59:27	0|kanzure|#action review scrollback
393 2016-03-10 19:59:39	0|btcdrak|haha
394 2016-03-10 19:59:39	0|sipa|haha
395 2016-03-10 19:59:55	0|btcdrak|that was a really long meeting...
396 2016-03-10 19:59:55	0|gmaxwell|sipa: So a concern I raised on the PR is that I'd like nodes to stop mining (e.g. error on GBT results) after a SW upgrade happens. The issue I'm trying to address is say the network successfully upgrades, and then a couple huge pools reboot and end up on pre softfork code-- e.g. bootscripts start the wrong versions; things run happily for a while, but then someone mines an invalid transaction a
397 2016-03-10 20:00:01	0|gmaxwell|nd then a huge amount of hashpower begins a fork.  Nversion progression previously prevented this, but at the expense of creating gratitious orphans around the switchover time.
398 2016-03-10 20:00:33	0|morcos|gmaxwell: i was wondering about that, but do miners change their version number outside of bitcoind anyway?
399 2016-03-10 20:01:07	0|gmaxwell|morcos: in the past some mining hardware had hardcoded versions numbers, but I think the last couple softforks probably shook out a fair amount of that.
400 2016-03-10 20:01:33	0|sipa|we hope...
401 2016-03-10 20:01:35	0|morcos|gmaxwell: so this is another reason to make >= 5 a consensus rule
402 2016-03-10 20:01:42	0|Luke-Jr|morcos: they set it outside bitcoind generally
403 2016-03-10 20:01:43	0|morcos|if you don't you can't fix that problem for 0.12.0 miners
404 2016-03-10 20:01:56	0|sipa|how does that help?
405 2016-03-10 20:02:21	0|gmaxwell|sipa: the idea is that post SW miners would do the voluntarily shut off unless overridden.
406 2016-03-10 20:03:08	0|morcos|sipa: well i don't know.  i took gmaxwell's scenario at face value.. but maybe it doesn't make sense.  i guess the difference is whether you find out right away or not?
407 2016-03-10 20:03:34	0|gmaxwell|It's a difference in the size of the fork; and who takes the risks.
408 2016-03-10 20:03:37	0|morcos|gmaxwell: are you specficially talking about SW script upgrades?  or do you mean BIP 9 soft forks?
409 2016-03-10 20:03:52	0|gmaxwell|BIP9 softforks.
410 2016-03-10 20:04:25	0|morcos|gmaxwell: can you explain a bit why the fork size would be bigger?
411 2016-03-10 20:04:25	0|sipa|if the vereion number is set outside of bitcoim core, then logic there won't help
412 2016-03-10 20:04:47	0|sipa|you just need logic that stops GBT in case the vb warning logic triggered
413 2016-03-10 20:05:21	0|morcos|that seems a bit risky to me to automatically stop GBT
414 2016-03-10 20:05:34	0|gmaxwell|morcos: Because only an exceptional circumstance would begin such a fork, it might happen months or years after the change, with no one paying attention.
415 2016-03-10 20:05:40	0|morcos|i mean i guess it does take 95% of miners to cause a fake trigger
416 2016-03-10 20:06:20	0|gmaxwell|morcos: the existing warning stuff is stupid, boarderline broken-- which is why I was suggesting it only for BIP9 activation.
417 2016-03-10 20:07:05	0|jonasschnelli|Is https://github.com/sipa/bitcoin/tree/segwit still the most recent segnet working tree?
418 2016-03-10 20:07:30	0|jonasschnelli|BTW: how changes the https://github.com/bitcoin icon? Nice one!
419 2016-03-10 20:07:40	0|jonasschnelli|*who
420 2016-03-10 20:07:47	0|jonasschnelli|*changed (damit)
421 2016-03-10 20:07:57	0|gmaxwell|morcos: the idea that the network in bulk could silently regress rules (though detectable by the nodes themselves) concerns me; but I don't know how much of a pratical concern it should be.
422 2016-03-10 20:09:06	0|morcos|gmaxwell: the fact that nVersion is set outside bitcoind is disturbing, but imagine 1% of miners don't upgrade to versionbits and the 68/112/113 soft fork
423 2016-03-10 20:09:49	0|morcos|they will happily mine version 4 blocks for months until they accidentally mine an invalid BIP68 tx, and then all the SPV miners will just build off them
424 2016-03-10 20:10:00	0|morcos|as opposed to htat thing happening right away if the nVersion had to increase
425 2016-03-10 20:12:06	0|sipa|Luke-Jr: is it not enough to report nVersionm
426 2016-03-10 20:12:08	0|sipa|?
427 2016-03-10 20:12:15	0|gmaxwell|morcos: right, so two questions: avoiding that for this one change vs in the long term.
428 2016-03-10 20:12:21	0|Luke-Jr|sipa: no, because nVersion could mean different things
429 2016-03-10 20:12:46	0|morcos|gmaxwell: yes, i agree that perhaps your long term change makes sense
430 2016-03-10 20:13:09	0|sdaftuar|gmaxwell: morcos: seems to me like we should do both things you guys are suggesting
431 2016-03-10 20:13:11	0|morcos|i mean your change now to solve the longer term problem
432 2016-03-10 20:13:22	0|sipa|Luke-Jr: ?
433 2016-03-10 20:13:46	0|Luke-Jr|sipa: version=69632 could mean different softforks depending on context of the block
434 2016-03-10 20:13:57	0|sipa|so?
435 2016-03-10 20:14:10	0|gmaxwell|morcos: in the long term I think it's adequate to refuse to serve GBT requests after a BIP9 activiation triggers. (and perhaps mine only empty blocks during the quiet period for further visibility)
436 2016-03-10 20:14:22	0|gmaxwell|sipa: matters if you're adding additional txn to the gbt output.
437 2016-03-10 20:14:24	0|Luke-Jr|sipa: so the GBT client won't know which softforks to enable
438 2016-03-10 20:14:37	0|gmaxwell|morcos: for the current issue, I agree that an upgrade to >=5 may be needed.
439 2016-03-10 20:14:46	0|sipa|Luke-Jr: nobody is doing that, right?
440 2016-03-10 20:15:20	0|gmaxwell|Luke-Jr: I think you actually want to expose the mempool validation flags in GBT for that, not just softforks.
441 2016-03-10 20:15:26	0|Luke-Jr|sipa: adding transactions, not at the moment AFAIK, but GBT clients always must be aware of what the block rules are to some extent
442 2016-03-10 20:15:38	0|sdaftuar|note that the version bits do not indicate what the consensus rules are
443 2016-03-10 20:15:50	0|sipa|Luke-Jr: i guess those can be per-softfork extensions to GBT
444 2016-03-10 20:16:11	0|sipa|as their effects can be hard to generalize
445 2016-03-10 20:16:12	0|Luke-Jr|sipa: some way to indicate them is still needed, but yes
446 2016-03-10 20:16:51	0|Luke-Jr|ie, we don't want old GBT clients to think they can handle bit X, but interpret it differently
447 2016-03-10 20:17:10	0|morcos|Luke-Jr: any time you are setting bit X it by definition means that soft fork isn't even active yet
448 2016-03-10 20:17:21	0|morcos|or at least by implementation
449 2016-03-10 20:18:03	0|Luke-Jr|more likely the GBT client would be the side setting the bits it implements
450 2016-03-10 20:20:07	0|gmaxwell|Luke-Jr: trying to move network consensus logic into gbt clients seems inadvisible and should only be done where strictly needed.
451 2016-03-10 20:22:45	0|sipa|gmaxwell: +1
452 2016-03-10 20:25:15	0|BlueMatt|instead we should be pulling out as MUCH logic as possible from gbt clients/pool servers into bitcoind
453 2016-03-10 20:25:18	0|BlueMatt|and also kill getblocktemplate
454 2016-03-10 20:25:23	0|BlueMatt|because no one uses it and everyone hates it
455 2016-03-10 20:31:01	0|gmaxwell|BlueMatt: so mean. By "kill" you mean "optimize".
456 2016-03-10 20:31:22	0|BlueMatt|gmaxwell: I mean replace entirely
457 2016-03-10 20:31:22	0|sipa|making it observable what is being mined makes sense
458 2016-03-10 20:32:06	0|BlueMatt|gmaxwell: no one cares about the features provided by gbt, and every time I talk to /anyone/ using it (except eloipool) the response is "omg, just replace it with a binary something-or-other that has nearly opposite features of what gbt provides"
459 2016-03-10 20:32:14	0|sipa|but i don't think GBT's goal should be letting block construction outside of bitcoind
460 2016-03-10 20:32:20	0|BlueMatt|^that
461 2016-03-10 20:32:28	0|BlueMatt|is also what people want
462 2016-03-10 20:32:43	0|BlueMatt|most folks just want the minimal data they need to be able to twiddle extranonce
463 2016-03-10 20:32:46	0|gmaxwell|if the nonce in header fork were done we could go back to getwork. :)
464 2016-03-10 20:32:53	0|BlueMatt|and that
465 2016-03-10 20:37:48	0|btcdrak|BlueMatt: is there any more progress on HF contents?
466 2016-03-10 20:38:40	0|BlueMatt|btcdrak: I havent seen anything on bitcoin-dev?
467 2016-03-10 20:38:43	0|BlueMatt|btcdrak: also #bitcoin-dev
468 2016-03-10 20:39:02	0|Luke-Jr|sipa: so just give up on decentralised mining entirely?
469 2016-03-10 20:39:15	0|BlueMatt|Luke-Jr: that is a false dichotomy
470 2016-03-10 20:39:48	0|gmaxwell|there are other ways to do that, e.g. telling bitcoind what the requirements are for a block it creates and letting it create it.
471 2016-03-10 20:39:53	0|BlueMatt|Luke-Jr: the amount of data you need to twiddle the extranonce is almost the same as the amount of data you need to create a coinbase for gbt in the same way you want people to do decentralized mining
472 2016-03-10 20:39:55	0|gmaxwell|E.g. coinbase must pay to X.
473 2016-03-10 20:40:03	0|BlueMatt|gmaxwell: you can create the coinbase downstream of bitcoind
474 2016-03-10 20:40:24	0|gmaxwell|only by implementing consensus rules outside of bitcoind, however.
475 2016-03-10 20:40:39	0|BlueMatt|bitcoind should be able to tell you things like requirements for what scriptSig should look like
476 2016-03-10 20:40:49	0|gmaxwell|BlueMatt: you are reinventing GBT. :)
477 2016-03-10 20:40:55	0|Luke-Jr|gmaxwell: this is higher latency
478 2016-03-10 20:41:05	0|BlueMatt|gmaxwell: no, gbt gives you all kinds of shit like details for every transaction in the block
479 2016-03-10 20:41:12	0|BlueMatt|you should only be providing minimal merkle tree info
480 2016-03-10 20:41:28	0|gmaxwell|BlueMatt: which is actually needed if you're building your own coinbase, because you may need to drop out transactions to make room.
481 2016-03-10 20:41:32	0|BlueMatt|gmaxwell: also, phantomcircuit has a protocol designed for this
482 2016-03-10 20:41:34	0|BlueMatt|that is pretty minimal
483 2016-03-10 20:42:00	0|BlueMatt|gmaxwell: "meh", your coinbase shouldnt be /that/ large
484 2016-03-10 20:42:22	0|gmaxwell|go look at a p2pool coinbase txn.
485 2016-03-10 20:42:31	0|BlueMatt|I'm aware
486 2016-03-10 20:43:15	0|BlueMatt|ehh, whatever, fine, give bitcoind a coinbase output list
487 2016-03-10 20:43:54	0|BlueMatt|either way, push complexity into bitcoind :)
488 2016-03-10 20:43:56	0|morcos|i know nothing about mining, so hopefully im not wasting peoples time
489 2016-03-10 20:44:14	0|morcos|but it seems to me that it would be reasonable to require miners to run a bitcoind
490 2016-03-10 20:44:35	0|morcos|and we should provide an API by which they can submit a block to to a pool and say hey, is this acceptable
491 2016-03-10 20:44:41	0|morcos|and then they can work on that
492 2016-03-10 20:44:48	0|morcos|i know thats the idea behind GBT (sort of)
493 2016-03-10 20:44:56	0|morcos|but instead of building all the functionality into the API
494 2016-03-10 20:44:58	0|BlueMatt|Luke-Jr: to be fair, people also hate json, so need something outside the existing rpc
495 2016-03-10 20:45:07	0|Luke-Jr|BlueMatt: it wasn't via RPC ;)
496 2016-03-10 20:45:17	0|BlueMatt|hmm, fair enough
497 2016-03-10 20:45:21	0|morcos|just have a testBlock RPC call that the pool can say, yeah thats cool pays the right coinbase or whatever and is valid according to our consensus rules
498 2016-03-10 20:46:03	0|Luke-Jr|preferably there'd be a way to avoid sending the entire gen-tx around.
499 2016-03-10 20:46:49	0|BlueMatt|Luke-Jr: so revive it now :)
500 2016-03-10 20:46:55	0|Luke-Jr|BlueMatt: ?
501 2016-03-10 20:47:55	0|Luke-Jr|not sure the point
502 2016-03-10 20:53:02	0|jtimon|sipa morcos, what about always producing 0010... (even when no deployments are being checked) after the the starttime of the first deployment? (my own solution was to just do it right away for new miners, even before any start time, but sipa complained that old nodes would get warnings before start time [they're going to receive warnings before activation anyway, so I wasn't too concerned about that])
503 2016-03-10 20:53:38	0|morcos|jtimon: yeah i think its strictly better for the old nodes to get the warnings earlier
504 2016-03-10 20:54:25	0|jtimon|that was my point, the dicsussion is there in some outdated comment in #7575
505 2016-03-10 20:55:00	0|jtimon|and that solution doesn't require any additional consensus checks, which seems to be what people dislike more from your proposal
506 2016-03-10 20:59:36	0|e0_|The variables  pathCached and pathCachedNetSpecific in util.cpp appears to be unused (find doesn't return any results of them being set) but can cause interesting segfaults since depending on the order in which objects are created they can be uninitialized.  Are they actually unused
507 2016-03-10 20:59:41	0|e0_|[3:38]
508 2016-03-10 20:59:44	0|e0_|?
509 2016-03-10 20:59:47	0|e0_|https://github.com/bitcoin/bitcoin/blob/master/src/util.cpp#L485
510 2016-03-10 20:59:55	0|e0_|I have a pull request, but I don't want to waste peoples time in case I am missing something
511 2016-03-10 23:11:13	0|dgenr8|144*365