1 2015-11-26 16:51:27 <dermoth> Hi there... I'm wondering why bitcoin devs aren't cross-signing their release keys
  2 2015-11-26 16:53:04 <dermoth> Bitcoin 11.2 is signed with yet another key... I trust the old keys release keys but they haven't signed the new key, so I cannot know if the new key can be trusted or not (and since it came form the same place as the release, there is no point in checking a signature as anyone replacing the binary could have replaced the key too)
  3 2015-11-26 16:53:25 <sipa> wumpus: ^
  4 2015-11-26 16:56:30 <jonasschnelli> dermoth: do you talk about https://bitcoin.org/bin/bitcoin-core-0.11.2/SHA256SUMS.asc?
  5 2015-11-26 16:56:44 <jonasschnelli> or do you mean the windows or osx code signature?
  6 2015-11-26 16:57:24 <jonasschnelli> a quick check told me that https://bitcoin.org/bin/bitcoin-core-0.11.2/ used the same key then https://bitcoin.org/bin/bitcoin-core-0.11.0
  7 2015-11-26 17:01:30 <dermoth> jonasschnelli, yes, and two other keys for previous releases...
  8 2015-11-26 17:01:46 <dermoth> I'm still running 10.2, and besides I might have verified it using Armory
  9 2015-11-26 17:02:33 <sipa> dermoth: you may be interested in the gitian signatures, which is generally a stronger mechanism
 10 2015-11-26 17:02:51 <sipa> dermoth: multiple developers there sign the hashes of the resulting binaries of a determinstic build process
 11 2015-11-26 17:02:57 <sipa> https://github.com/bitcoin/gitian.sigs
 12 2015-11-26 17:03:16 <sipa> so it doesn't so strongly rely on the developer who publishes the release
 13 2015-11-26 17:04:33 <dermoth> yeah i've read about it, pretty interesting idea, and also offer some mitigation against infected compilers (as long as not all devs are infected anyway....)
 14 2015-11-26 17:05:29 <sipa> well you can repeat the gitian process yourself, and verify the hashes
 15 2015-11-26 17:05:41 <sipa> though it's cumbersome admittedly
 16 2015-11-26 17:39:18 <jtimon> why server needs to be build before common?
 17 2015-11-26 17:42:55 <sipa> jonasschnelli: https://github.com/sipa/bitcoin/commits/realconflicts
 18 2015-11-26 17:43:08 <sipa> jonasschnelli: absolutely untested, but I believe you've already done some testing work for this?
 19 2015-11-26 17:44:23 <sipa> it may need a rescan though to detect historical conflicts :(
 20 2015-11-26 17:44:53 <jonasschnelli> sipa: wow. That was quick. Maybe take my rpc mempool evict test?
 21 2015-11-26 17:45:10 <jonasschnelli> (from the now superseded pr)
 22 2015-11-26 17:45:37 <sipa> well the code doesn't look at the mempool at all anymore, so that shouldn't matter
 23 2015-11-26 17:45:53 <sipa> sec
 24 2015-11-26 17:46:30 <jtimon> but wallet and wt can be built after server
 25 2015-11-26 17:46:38 <jtimon> s/wt/qt/
 26 2015-11-26 17:47:14 <sipa> jtimon: i would expect that the order in which libs are built is not relevant, as they don't depend on each other (only linking needs all libs)
 27 2015-11-26 17:47:53 <jtimon> sipa: I would expect the same, but https://github.com/jtimon/bitcoin/compare/consensus-build...jtimon:consensus-build-full
 28 2015-11-26 17:48:09 <sipa> jonasschnelli: so that commit i wrote changes the meaning of negative confirmations to mean "conflicts with a transaction that deep in the chain"
 29 2015-11-26 17:48:28 <jtimon> I mean, I will just reorder common and server first without doing anything else to confirm my suspicions
 30 2015-11-26 17:49:01 <jonasschnelli> (Phonetyping) I'll have a look at it soon. But IIRC we need a solution that does not mark evicted tx as conflicted.
 31 2015-11-26 17:49:37 <sipa> jonasschnelli: this doesn't; evicting doesn't do anything at all, as the confirmation count becomes completely independent of the mempool
 32 2015-11-26 17:50:33 <jonasschnelli> Okay. This is nice. Then it should pass the rpc test I wrote (don't mark evicted transactions as conflicted).
 33 2015-11-26 17:50:55 <jonasschnelli> (Need to look at the code, but sucks on the phone)
 34 2015-11-26 17:51:12 <sipa> ideally, we have a test to see whether a reorg + accept of conflicting tx also marks it as negative confirm
 35 2015-11-26 17:52:23 <sipa> jonasschnelli: i think i can incorporate some of your conflicting code to get an approximation for older conflicts
 36 2015-11-26 17:52:29 <jonasschnelli> I'll can do the testing. Submit a PR when you think it is ready... I can try to create a/some rpc test(s)
 37 2015-11-26 17:53:30 <jonasschnelli> IIRC your code only detects conflicts that where originally submitted over the SyncTransaction signal?
 38 2015-11-26 17:54:20 <sipa> yes
 39 2015-11-26 17:54:34 <sipa> or reindex
 40 2015-11-26 17:55:07 <sipa> oh, no
 41 2015-11-26 17:56:43 <sipa> jtimon: oh, sorry, the order inside LDADD? that absolutely does matter: they need to be in dependency order
 42 2015-11-26 17:57:09 <sipa> jtimon: things depended upon must go later
 43 2015-11-26 17:57:16 <jtimon> sipa: but it seems to be inverse?
 44 2015-11-26 17:57:21 <jtimon> why inverse?
 45 2015-11-26 17:57:23 <sipa> jtimon: i thought you were talking about build order
 46 2015-11-26 17:57:37 <sipa> jtimon: toplevel things go first, dependencies go last
 47 2015-11-26 17:57:50 <jtimon> yes, I'm talking about build order, the server package seems to need to be built first
 48 2015-11-26 17:58:18 <jtimon> sipa: that's very counter-intuitive to me, I'm used to the opposite
 49 2015-11-26 17:58:27 <sipa> jtimon: confused; on github you're talking about the order in LDADD, not build order
 50 2015-11-26 17:59:12 <jtimon> if you touch hash.cpp to break it, why should you build main.o before finding out?
 51 2015-11-26 17:59:23 <jtimon> what's the difference?
 52 2015-11-26 17:59:32 <sipa> the build order shouldn't matter; the order inside ldadd does
 53 2015-11-26 18:00:04 <jtimon> their order seem to be related
 54 2015-11-26 18:00:20 <sipa> how so?
 55 2015-11-26 18:00:29 <jtimon> things that appear first in LDADD seem to be built first
 56 2015-11-26 18:00:42 <sipa> oh, right, autotools puts them in that order
 57 2015-11-26 18:01:11 <sipa> we'll need cfields_ :)
 58 2015-11-26 18:01:39 <jtimon> so why does autotools hate me? (or why do I hate autotools, not sure yet)
 59 2015-11-26 18:01:58 <jtimon> yep, I asked him first, let's wait for his answer
 60 2015-11-26 18:02:47 <jtimon> in any case that was just building-order bike-shedding that was breaking #7091, fixed now
 61 2015-11-26 18:03:23 <sipa> jtimon: if out modularization was complete, this wouldn't be a problem, because you would only rarely touch the .h files that high-level code depends on, so changing some implementation detail in a low-level package wouldn't cause rebuilds
 62 2015-11-26 18:03:37 <sipa> jtimon: that unfortunately doesn't work with code that puts a lot in .h files
 63 2015-11-26 18:04:16 <sipa> but i see the problem now: you want it to build things in the opposite order as what you're passing to LDADD... not sure if autotools can do that
 64 2015-11-26 18:05:56 <jtimon> I repeat my expample: s/static/staticzzzzzzzzz/ in hash.cpp, wait for main.o to build to find out your typo
 65 2015-11-26 18:06:14 <jtimon> yep, exactly
 66 2015-11-26 18:06:26 <sipa> jtimon: use more cores :)
 67 2015-11-26 18:06:45 <sipa> just touching hash.cpp shouldn't cause a rebuild of main
 68 2015-11-26 18:06:51 <sipa> but touching hash.h would
 69 2015-11-26 18:08:30 <jtimon> so I guess the question for cfields_ really is "why autotools only allows building-order bike-shedding in the opposite direction jtimon is used to see?" I belive that stupid question may have a revealing answer
 70 2015-11-26 18:10:32 <sipa> jtimon: my guess is that it's just annoying interaction between tools: in autotools you just list the dependencies, and they go in the same order in the makefile as they go as arguments to ld (where the order is fixed)
 71 2015-11-26 18:10:46 <sipa> s/they go in/are emitted in the output/
 72 2015-11-26 18:11:12 <sipa> jtimon: how many threads do you build with?
 73 2015-11-26 18:11:27 <jtimon> sipa: good point on the more-cores, this laptop is great for travel but I should have bought a pc-computer to levearage my improved interwebs connection long ago, I'm just super-lazzy about looking for hardware pieces and stuff
 74 2015-11-26 18:12:03 <sipa> if you have enough ram you can go crank it up a bit... going higher than your cpu supports won't speed a full build up, but it will give you warning earliers
 75 2015-11-26 18:12:50 <jtimon> sipa: I'll be even able test my own PRs (and others) when I buy this many-core many-gpu-empy-slides machine...
 76 2015-11-26 18:13:33 <jtimon> I have 2 cores and I build with 4 threads
 77 2015-11-26 18:13:59 <sipa> i have 4 core and 8 hyperthreads, and usually build with -j10 or highe
 78 2015-11-26 18:14:02 <jtimon> that's...great for travel at this nenergy consumption, but when I'm home...
 79 2015-11-26 18:14:44 <jtimon> I guess I didn't tried 4, I did tried 8
 80 2015-11-26 18:14:52 <jtimon> s/4/5
 81 2015-11-26 18:17:51 <jtimon> I don't need a 20 core computer, but I always dreamt about having my own evolutionary neural network gpu farm at home anyway, sorry, increasingly offtopic...
 82 2015-11-26 18:18:19 <jtimon> s/always/since one day or something
 83 2015-11-26 18:31:17 <dermoth> sipa, jonasschnelli, actually I could verify the new key using the previous one using https://github.com/bitcoin-dot-org/bitcoin.org/pull/924
 84 2015-11-26 18:31:48 <dermoth> this is as good ad a key signature, nowever the latter can be exported to keyservers and synchronizxed automatically
 85 2015-11-26 18:31:58 <dermoth> *however the latter...
 86 2015-11-26 18:42:54 <dermoth> my bad, the keys were signed... I'm not used to the UI I'm using, I expected to see signatures below used id's :/
 87 2015-11-26 18:59:46 <Luke-Jr> are we still having a meeting today? (American holiday)
 88 2015-11-26 19:00:28 <jonasschnelli> I'm ready.
 89 2015-11-26 19:00:34 <jonasschnelli> Luke-Jr: Thanksgiving?
 90 2015-11-26 19:00:39 <Luke-Jr> yes
 91 2015-11-26 19:01:58 <jonasschnelli> ^^
 92 2015-11-26 19:05:33 <Luke-Jr> I'm going to be AFK for the next 20 mins
 93 2015-11-26 19:11:09 <btcdrak> what a time for a netsplit!
 94 2015-11-26 19:17:05 <btcdrak> wumpus: so no meeting today then?
 95 2015-11-26 19:17:49 <CodeShark> btcdrak: so no wumpus today then? :)
 96 2015-11-26 19:17:53 <petertodd> btcdrak: since when do you listen to authority? :P
 97 2015-11-26 19:18:14 <wumpus> don't let it depend on me, but there doesn't seem to be much activity no
 98 2015-11-26 19:18:47 <btcdrak> I just thought the meeting was cancelled or something. but then there was a huge netsplit so maybe that affected things. was just asking.
 99 2015-11-26 19:22:21 <CodeShark> is there a quorum? or can we meet anyhow? :)
100 2015-11-26 19:22:48 <petertodd> CodeShark: I'm in a mcdonalds right now, working on increasing my influence, as measured by mass...
101 2015-11-26 19:22:53 <petertodd> CodeShark: so yes
102 2015-11-26 19:23:26 <CodeShark> not sure everyone else appreciates the gravity of the situation...
103 2015-11-26 19:23:51 <petertodd> topic: CLTV... so it's plausible that we'll have CLTV activate within just a few weeks, as everyone but a few big players has aldopted it
104 2015-11-26 19:23:58 <btcdrak> I want to ask about #6312 and #6564 again.
105 2015-11-26 19:23:59 <petertodd> *adopted
106 2015-11-26 19:24:29 <btcdrak> ok let's start meeting bot then
107 2015-11-26 19:24:34 <btcdrak> #meetingstart
108 2015-11-26 19:24:37 <petertodd> btcdrak: cool
109 2015-11-26 19:24:40 <btcdrak> #startmeeting
110 2015-11-26 19:24:40 <lightningbot> Meeting started Thu Nov 26 19:24:40 2015 UTC.  The chair is btcdrak. Information about MeetBot at http://wiki.debian.org/MeetBot.
111 2015-11-26 19:24:40 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
112 2015-11-26 19:24:58 <btcdrak> #topic CLTV activation
113 2015-11-26 19:25:06 <btcdrak> petertodd: the floor is yours
114 2015-11-26 19:25:17 <petertodd> right, so it's plausible that we'll have CLTV activate within just a few weeks, as everyone but a few big players has adopted it
115 2015-11-26 19:26:03 <petertodd> we've got about 20% of nodes running CLTV-supporting bitcoin core versions... we should do another redit/twitter/etc. push reminding people that they should upgrade to v0.11.2 / v0.10.4
116 2015-11-26 19:26:44 <btcdrak> Yes, I was planning to do something today but got sidetracked and forgot. Best to do on Monday/Tuesday for best coverage.
117 2015-11-26 19:26:55 <petertodd> btcdrak: sounds like a plan
118 2015-11-26 19:27:56 <CodeShark> it will be fun doing an mSIGNA release that supports CLTV :)
119 2015-11-26 19:27:59 <Luke-Jr> petertodd: well, negative effect of not upgrading for non-miners is just degraded validation, right?
120 2015-11-26 19:28:15 <petertodd> Luke-Jr: yes, reduced to SPV
121 2015-11-26 19:28:31 <Luke-Jr> k
122 2015-11-26 19:28:38 <petertodd> Luke-Jr: we do not kick peers for sending us a now-invalid nVersion=3 blocks, so the network won't split or anything
123 2015-11-26 19:28:39 <btcdrak> #action Post reminder about CLTV deployment next week on social media
124 2015-11-26 19:29:48 <btcdrak> is this topic concluded?
125 2015-11-26 19:29:52 <petertodd> I think so
126 2015-11-26 19:30:05 <btcdrak> ok well I have one :)
127 2015-11-26 19:30:12 <petertodd> shoot
128 2015-11-26 19:30:21 <btcdrak> #topic BIP68/BIP112 implementation
129 2015-11-26 19:31:12 <CodeShark> in retrospect we should have kept the nSequence semantics but still called the opcode OP_RCHECKLOCKTIMEVERIFY and use the proper semantics for that ;)
130 2015-11-26 19:31:15 <btcdrak> So reporting from last week, the BIP68 and BIP112 texts have been updated to match the implementations
131 2015-11-26 19:31:28 <petertodd> I've done a bit of work on CSV demo's, but that's getting pushed behind scaling bitcoin conf prep: https://github.com/petertodd/csv-demos
132 2015-11-26 19:31:49 <petertodd> btcdrak: yeah, new texts look better
133 2015-11-26 19:31:56 <btcdrak> I would like to note the implementations are as agreed back in October. The BIP texts have has some peer review and received ACKs.
134 2015-11-26 19:32:00 <Luke-Jr> CodeShark: never too late to rename..
135 2015-11-26 19:32:13 <btcdrak> #link BIP68 text https://github.com/bitcoin/bips/pull/245
136 2015-11-26 19:32:27 <btcdrak> #link BIP112 text https://github.com/bitcoin/bips/pull/248
137 2015-11-26 19:32:30 <petertodd> I vote we let btcdrak pick a new bikeshed color^H^H^H new name
138 2015-11-26 19:32:48 <CodeShark> lol
139 2015-11-26 19:33:14 <btcdrak> Regarding the implementations PRs #6312 (BIP68) and #6564 (CSV opcode BIP112), these are up to date and ready. They have also received a number of ACKs
140 2015-11-26 19:33:48 <btcdrak> I posted to the list about renaming OP_CHECKSEQUENCEVERIFY
141 2015-11-26 19:33:50 <btcdrak> #link http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011801.html
142 2015-11-26 19:33:50 <petertodd> btcdrak: I'm definitely holding off an ACK until I've seen some worked out demos of CSV functionality
143 2015-11-26 19:34:41 <CodeShark> yeah, the only thing that is holding me back from ACKing is that I haven't actually tried constructing CSV transactions
144 2015-11-26 19:35:29 <btcdrak> I believe these PRs should be merged soon. For the avoidance of doubt, these are mempool-only implementations, with no softfork deployment code. That should be added later when we are ready to deploy
145 2015-11-26 19:35:37 <petertodd> it's worth noting that if it were easier to add fields to transactions, this whole review process would be much easier
146 2015-11-26 19:35:58 <sipa> petertodd: working on it!
147 2015-11-26 19:35:59 <CodeShark> :)
148 2015-11-26 19:35:59 <CodeShark> segwit might fix that, PT
149 2015-11-26 19:36:11 <Luke-Jr> sipa: hah, I was thinking just that
150 2015-11-26 19:36:14 <petertodd> sipa: yes, I was thinking about segwit when I said that :)
151 2015-11-26 19:36:41 <CodeShark> in the end it might turn out that we don't even need the nSequence field ;)
152 2015-11-26 19:36:46 <petertodd> sipa: though if I understood your code, you haven't yet made tx hashing be oer a tree yet
153 2015-11-26 19:36:56 <btcdrak> So we can never have enough review, I can never say the PRs are ready, but, since there has been a lot of ACKs and we're not merging a consensus change, I really want to ask for #6312 and #6564 to get merged
154 2015-11-26 19:36:59 <sipa> petertodd: i changed that
155 2015-11-26 19:37:13 <sipa> petertodd: though it's still broken
156 2015-11-26 19:37:29 <btcdrak> So that's my monologue done.
157 2015-11-26 19:37:41 <petertodd> btcdrak: so, I'd suggest you write out in the pull-req what exactly is your plan for handling a change to the rules after it's merged - in a dev branch I don't think that's a big deal, but if we release a mempool-only version that can be ugly
158 2015-11-26 19:38:21 <petertodd> btcdrak: merging after v0.12.0 is forked off would be safest
159 2015-11-26 19:38:40 <petertodd> btcdrak: IIRC that's supposed to happen in about a week or so
160 2015-11-26 19:39:08 <btcdrak> petertodd: OK. I'm pretty confident we're not changing the rules, BIP68 has been in the bike-shed long enough and pretty much everyone's requests have been incorporated.
161 2015-11-26 19:39:08 <petertodd> sipa: we should talk at scaling bitcoin about this; I've done a lot of thinking re: this stuff for my proofchains work
162 2015-11-26 19:39:30 <sipa> petertodd: sure
163 2015-11-26 19:39:48 <CodeShark> I actually am presenting on extensibility using segwit
164 2015-11-26 19:39:55 <btcdrak> I would be happy with it being merged right after 0.12 is branched off. But it really needs to get merged... I cant insist enough
165 2015-11-26 19:39:56 <CodeShark> although it is not in the program yett
166 2015-11-26 19:39:58 <petertodd> btcdrak: but I asked for the bikeshed to be painted the color of an eldritch horror!
167 2015-11-26 19:40:14 <petertodd> CodeShark: cool!
168 2015-11-26 19:40:29 <petertodd> CodeShark: send me what you have; may be relevant to my presentation
169 2015-11-26 19:40:36 <btcdrak> I certainly do want to change the name of the opcode, but that's an easy change
170 2015-11-26 19:41:02 <btcdrak> wumpus: sipa: gmaxwell: coments/thoughts?
171 2015-11-26 19:41:14 <sipa> btcdrak: i disagree with the need to be merged... at this point we have to wait anyway
172 2015-11-26 19:41:34 <CodeShark> PT: sure - as soon as I have something ;)
173 2015-11-26 19:41:37 <sipa> btcdrak: not saying that it shouldn't, and i understand that waiting and rebasing is annoying
174 2015-11-26 19:41:39 <petertodd> btcdrak: next rebase is on me :)
175 2015-11-26 19:41:42 <btcdrak> sipa: with all due respect it's almost 6 months. it's getting painful.
176 2015-11-26 19:42:15 <petertodd> btcdrak: hey, CLTV took a year, two if you count from the initial implementation
177 2015-11-26 19:42:15 <sipa> btcdrak: i completely understand that, but that is not a reason... i have a feeling people only recently started actually looking into it seriously
178 2015-11-26 19:42:24 <petertodd> sipa: agreed :(
179 2015-11-26 19:43:00 <petertodd> anyway the remarkable speed that CLTV is being adopted makes me worry less about getting CSV ready in time for things that might use it
180 2015-11-26 19:43:20 <btcdrak> sipa: fair enough. Can the BIP texts get merged. They are an accurate representation of the current implementations and it's already confused a couple of people who read the version in master not realising it was an old version.
181 2015-11-26 19:43:33 <petertodd> btcdrak: +1 on merging BIP texts
182 2015-11-26 19:43:44 <sipa> btcdrak: no reason why the bip texts can't be merged
183 2015-11-26 19:43:50 <Luke-Jr> btcdrak: BIP changes should be merged as soon as the author(s) ACK them
184 2015-11-26 19:44:03 <btcdrak> even if there are minor amendments to make to the BIP texts it's a heck of a lot better than the current status
185 2015-11-26 19:44:10 <Luke-Jr> remind me when I get home tonight if that's the case
186 2015-11-26 19:44:15 <btcdrak> Luke-Jr: I am the author of BIP112
187 2015-11-26 19:44:17 <petertodd> Luke-Jr: oh, all authors? we should make that clear in the instructions
188 2015-11-26 19:44:35 <Luke-Jr> petertodd: AFAIK just one
189 2015-11-26 19:44:44 <btcdrak> and really maaku has handed over the proposals to me so it is not reasonable to expect him to ACK BIP68
190 2015-11-26 19:44:51 <Luke-Jr> but clarifying it would be nice
191 2015-11-26 19:45:09 <CodeShark> btcdrak: can you rebase your BIP112 PR?
192 2015-11-26 19:45:57 <btcdrak> CodeShark: to what, they all show as mergeable
193 2015-11-26 19:46:22 <CodeShark> I guess it's mergeable - but we merged in something recently
194 2015-11-26 19:46:22 <petertodd> you know, a better procedure for draft BIP's might be to have a placeholder link in bitcoin/bips pointing to the authors' presonal repo...
195 2015-11-26 19:46:26 <btcdrak> #action Merge BIPs PRs #245 and #248
196 2015-11-26 19:47:00 <Luke-Jr> CodeShark: rebasing for no reason whatsoever is just annoying :/
197 2015-11-26 19:47:17 <CodeShark> ok, I see there are no conflicts
198 2015-11-26 19:47:35 <CodeShark> btcdrak: specifically, I changed a couple things in the Retroactive Invalidation section that got merged but it does not conflict with your PR
199 2015-11-26 19:48:03 <btcdrak> sipa: in your view, what remains for the implementations to get merged?
200 2015-11-26 19:49:46 <btcdrak> ### 10 minutes left. are there any other topic suggestions?
201 2015-11-26 19:50:01 <petertodd> btcdrak: rbf
202 2015-11-26 19:50:28 <btcdrak> ok then let's end this topic
203 2015-11-26 19:50:32 <btcdrak> #topic RBF
204 2015-11-26 19:50:57 <btcdrak> petertodd: please go ahead
205 2015-11-26 19:51:00 <petertodd> so, I've been running RBF nodes with the mempool limiter turned way down to stress test... and no issues reported
206 2015-11-26 19:51:04 <CodeShark> anyone have a topic that pays a higher fee? :)
207 2015-11-26 19:51:13 <petertodd> CodeShark: lol
208 2015-11-26 19:51:31 <Luke-Jr> this fee is too low, I'm leaving early!
209 2015-11-26 19:51:34 <Luke-Jr> :P
210 2015-11-26 19:51:50 <petertodd> Luke-Jr: here's a (non)-alcoholic beverage of your choice
211 2015-11-26 19:52:39 <Luke-Jr> petertodd: is the current PR easy to merge FSS and full-unconditional on top of as options?
212 2015-11-26 19:52:54 <petertodd> Luke-Jr: sure is, and I invite people to do exacty that
213 2015-11-26 19:53:29 <sipa> petertodd: sorry, haven't reviewed it... we have a bit of more urgent changes to make still
214 2015-11-26 19:53:30 <CodeShark> I haven't had a chance to review your stuff yet, petertodd, but strongly support the effort ;)
215 2015-11-26 19:53:59 <petertodd> cool, reviews so this can get into v0.12.0 much appreciated...
216 2015-11-26 19:54:02 <btcdrak> RBF is another PR which seems to have a ton of support and ACKs iirc.
217 2015-11-26 19:54:17 <petertodd> btcdrak: note, concept acks and utacks, not much full acks
218 2015-11-26 19:54:18 <jtimon> btcdrak: totally agree on bip68, if it's going to survive longer as unmerged we should condider separate releases ala eternal petertodd's RBF instead of just an eternal PR
219 2015-11-26 19:54:49 <petertodd> jtimon: rbf works as a separate release, bip68 doesn't
220 2015-11-26 19:55:33 <Luke-Jr> it would be nice if bitcoin.org and similar sites were designed to convey multiple Core-based branches/releases
221 2015-11-26 19:55:36 <btcdrak> iirc from the previous meetings RBF is scheduled for 0.12 anyhow.
222 2015-11-26 19:55:40 <btcdrak> any action points petertodd?
223 2015-11-26 19:55:56 <btcdrak> ### 5 minutes remaining
224 2015-11-26 19:55:57 <jtimon> petertodd: it could be implemented, I'm just pointing out how unfortunate would be to require that unnecesary additional work
225 2015-11-26 19:55:59 <petertodd> #action another one or two ACKS on opt-in RBF
226 2015-11-26 19:56:23 <btcdrak> what's the PR link again?
227 2015-11-26 19:56:30 <petertodd> btcdrak: https://github.com/bitcoin/bitcoin/pull/6871
228 2015-11-26 19:56:48 <jtimon> petertodd: I always celebrated all RBF releases, and at the same time lament them
229 2015-11-26 19:56:49 <btcdrak> #action test and ACK RBF https://github.com/bitcoin/bitcoin/pull/6871
230 2015-11-26 19:57:30 <petertodd> jtimon: separate RBF releases do help make the point that the Bitcoin Core devs do not have absolute control of Bitcoin
231 2015-11-26 19:58:05 <Luke-Jr> ^ moving away from a single master branch would make that point better
232 2015-11-26 19:58:26 <petertodd> Luke-Jr: we did that already, github.com/bitcoin and github.com/bitcoinxt :)
233 2015-11-26 19:58:27 <Luke-Jr> but that will take some changes to be practical long-term
234 2015-11-26 19:58:40 <Luke-Jr> petertodd: the latter isn't Bitcoin so not really
235 2015-11-26 19:58:59 <Luke-Jr> petertodd: LJR is a better example there, but suffers from the rebase-abuse issue ;P
236 2015-11-26 19:59:07 <petertodd> Luke-Jr: yeah, it's a pity that had to happen with a protocol change too, confuses the issue
237 2015-11-26 19:59:13 <btcdrak> inb4 everyone shills their own fork btcdrak addrindex fork for example...
238 2015-11-26 19:59:58 <jtimon> petertodd: absolutely, please help me document it as an example in bip99, even if it's just as an example of software fork vs consensus fork
239 2015-11-26 20:00:04 <btcdrak> time is up.
240 2015-11-26 20:00:14 <Luke-Jr> ttyl, going to join family
241 2015-11-26 20:00:20 <petertodd> Luke-Jr: have fun!
242 2015-11-26 20:00:24 <btcdrak> #endmeeting
243 2015-11-26 20:00:24 <btcdrak> #meetingend
244 2015-11-26 20:00:24 <btcdrak> oh ffs, not this problem again
245 2015-11-26 20:00:25 <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-dev/2015/bitcoin-dev.2015-11-26-19.24.log.html
246 2015-11-26 20:00:25 <lightningbot> Meeting ended Thu Nov 26 20:00:24 2015 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
247 2015-11-26 20:00:25 <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-dev/2015/bitcoin-dev.2015-11-26-19.24.html
248 2015-11-26 20:00:25 <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-dev/2015/bitcoin-dev.2015-11-26-19.24.txt
249 2015-11-26 20:00:46 <petertodd> jtimon: what do you need to do to document it?
250 2015-11-26 20:00:47 <btcdrak> cu Luke-Jr
251 2015-11-26 20:01:58 <btcdrak> jtimon: I agree. BIP68/BIP112 really got stuck. I think many people had difficultly in understanding it because both BIPs really need to be seen as one.
252 2015-11-26 20:02:11 <jtimon> petertodd: whatever you think would fit in bip99 I will happilly review nad ack/nit
253 2015-11-26 20:02:20 <jtimon> s/nadand
254 2015-11-26 20:02:28 <jtimon> s/nad/and
255 2015-11-26 20:02:59 <btcdrak> we're suffering from not enough engineers syndrome too because there is so much work, so much is important and a priority and on top we need to find time to review PRs.
256 2015-11-26 20:03:18 <petertodd> jtimon: alright, I'll have a think about it - probably consittutes a "controversial non-consensus change"
257 2015-11-26 20:03:46 <petertodd> btcdrak: and the priorities span multipel timescales too
258 2015-11-26 20:05:26 <sipa> btcdrak: well i'm fine with the code now, but i really don't feel confident that people have looked in detail at the bips (perhaps because i myself haven't). I don't know why that is, and I understand it's very frustrating, but I still very much don't like feeling like people find this "has to be merged"...
259 2015-11-26 20:05:43 <btcdrak> petertodd: understood. BIP65 got delayed because of BIP66 priority, and then the community blew itself up.
260 2015-11-26 20:06:15 <btcdrak> (referring to the XT cafuffle)
261 2015-11-26 20:06:18 <aj> sipa: anything in particular that would give more confidence?
262 2015-11-26 20:06:19 <sipa> and right now we have scaling bitcoin coming up, a softfork, a new release, and holidays
263 2015-11-26 20:06:21 <petertodd> btcdrak: yup
264 2015-11-26 20:06:26 <jtimon> btcdrak: I think everyone saw an opotunity to refactor things further, which doesn't say anything bad about the original PR, minimal as it was, I think I resisted very well the temptation, but, really, all those improvements would be closer to be merged if we had it merged  already (not to mention the people that even think about touching anywhere those lines until there's some "permantent" base)
265 2015-11-26 20:07:06 <petertodd> sipa: "this has to be merged" looks a lot better when there's code using the feature that people want to use in production
266 2015-11-26 20:07:12 <aj> btcdrak: ("kerfuffle" fwiw)
267 2015-11-26 20:07:12 <jtimon> btcdrak: I though implemeting things as policy only was a short-cut to getting in bitcoin core
268 2015-11-26 20:07:18 <petertodd> sipa: !@#$ annoying chicken and egg problem of course, but that's life :(
269 2015-11-26 20:07:49 <sipa> the only reason i wouldn't want merging is because i don't know whether nothing will be changed, and there is no benefit to having it in
270 2015-11-26 20:08:42 <btcdrak> sipa: CLTV was merged into master for the best part of a year...
271 2015-11-26 20:08:44 <CodeShark> there's a benefit for those who have to keep rebasing it if it doesn't get merged ;)
272 2015-11-26 20:08:49 <jtimon> petertodd: yep, a section on non-consensus controversial software fork would be awesome for bip99 I think
273 2015-11-26 20:08:51 <petertodd> note how the experience of CLTV w/ XT's use of nVersion showed that having multiple competing things using the same feature makes analysing what will happen very difficult
274 2015-11-26 20:09:30 <sipa> btcdrak: so? it also was not merged for a long time
275 2015-11-26 20:10:12 <btcdrak> sipa: but it did get merged and remained in master for a long time because the code was considered complete. I think you have to draw a line somewhere or it may never get done.
276 2015-11-26 20:10:19 <sipa> btcdrak: i would like to see people say they completely understand the semantics
277 2015-11-26 20:10:27 <CodeShark> sipa, could we somehow entice you to look at the bips in detail? :)
278 2015-11-26 20:10:40 <sipa> btcdrak: i don't, because i wasn't even aware the bip was not up to date
279 2015-11-26 20:10:43 <petertodd> sipa: and part of why it took awhile, was because I myself said we shouldn't merge it without some demos of it in actual use
280 2015-11-26 20:10:53 <sipa> CodeShark: i will, after scaling bitcoin and 0.12
281 2015-11-26 20:11:30 <jtimon> petertodd: and RBF is the perfect example, well documented, it would take you more time to correct my two paragraphs section than to write it yourself I think, but thankful of only the review if you don't have time for more
282 2015-11-26 20:11:33 <btcdrak> sipa: I am confident the specification has been honed. It's had 6 months, we bikeshedded the bit allocation. I think it's time to draw the line at further bikeshedding there (and actually no-one has had any complaints since maaku added the new flags)
283 2015-11-26 20:11:50 <sipa> btcdrak: two people were aware of that discussion, afaik
284 2015-11-26 20:13:25 <btcdrak> along.
285 2015-11-26 20:13:25 <btcdrak> sipa: here's what happens. We have ML discussions about it, stuff gets done, people then forget about it, we have IRC meetings about it have to remind then it gets forgotten again - all because there is such a long passage of time. This is not the case for all things but this is what has happened to BIP68/112. I'm simply trying to find out how to move this
286 2015-11-26 20:13:31 <petertodd> btcdrak: I'm increasingly skeptical of calling discussions like that "bikeshedding" - the fact that I realised CLTV could just be an equality comparison months into the process shows this stuff is subtle
287 2015-11-26 20:13:48 <tommygunner> this might be slightly off topic: is there a difference how quickly txs to multisig addresses are mined compared to standard txs?
288 2015-11-26 20:14:03 <petertodd> tommygunner: no
289 2015-11-26 20:15:09 <btcdrak> If there are specific criterion like, person a and b *must* review and ACK the code, then I'm fine with that. but so far there hasnt been any specific, "you still need to fulfil criterion x".
290 2015-11-26 20:15:14 <petertodd> one structural problem with this whole process is the skillset required to do changes like CLTV and CSV, and the skillset required to write applications that actually use those new featurres, seems to be quite different
291 2015-11-26 20:15:27 <petertodd> btcdrak: unknown unknowns :)
292 2015-11-26 20:15:46 <jtimon> petertodd: I mean, no hurry with bip99, at some point, hopefully, there will be an uncontroversial hardfork, but I only have timewarp fix ready for deployment for now
293 2015-11-26 20:16:25 <btcdrak> sipa: also please remember you may not be aware of some of the discussions around BIP68 because iirc you unsubscribed from the ML, something I really dont blame you for, but it's just an example of how communication lines got scuppered.
294 2015-11-26 20:16:28 <petertodd> btcdrak: anyway, like I said, my criteria for CSV that I think we're blocked on is demos of it actually in use, which I'm trying to finish
295 2015-11-26 20:16:46 <sipa> btcdrak: that's true
296 2015-11-26 20:17:03 <btcdrak> petertodd: cool. that's great and I agree that would really help allay worries.
297 2015-11-26 20:17:05 <petertodd> btcdrak: and yes, I think in hindsight more of that should have been done for CLTV as well
298 2015-11-26 20:18:02 <btcdrak> petertodd: I get it, this is actually quite scary stuff, because consensus changes have to be right, and if there are errors well we may have to live with silly bugs or worse forever.
299 2015-11-26 20:19:17 <btcdrak> well, all good :)
300 2015-11-26 20:19:47 <CodeShark> the worse consensus failure to date was the ML itself ;)
301 2015-11-26 20:20:28 <btcdrak> CodeShark: haha
302 2015-11-26 20:20:28 <btcdrak> CodeShark: speaking of another essential cog in the machine, what's happening with versiobits? I can see were going to be congested soon without it :)
303 2015-11-26 20:20:58 <btcdrak> although we could so another ISM with nVersion=5 as pointed out by petertodd
304 2015-11-26 20:21:28 <CodeShark> unfortunately I had hoped to have something finished by last month (and I did have an implementation) but this month I've had too much other stuff to do to be able to dedicate much time to it
305 2015-11-26 20:22:43 <petertodd> CodeShark: same, I haven't had a chance to look at it at all
306 2015-11-26 20:23:34 <btcdrak> we're gathering quite a laundry list of softforks :)
307 2015-11-26 20:23:40 <aj> petertodd: looking at your csv-demos repo; looks like you've just got CLTV (as NOP2) so far, no CSV?
308 2015-11-26 20:24:42 <petertodd> aj: ha, forgot to push!
309 2015-11-26 20:25:07 <petertodd> aj: it really is in an ugly half-finished state though
310 2015-11-26 20:25:19 <petertodd> aj: lots more to be done
311 2015-11-26 20:25:39 <aj> "class HodlWallet"
312 2015-11-26 20:25:44 <btcdrak> CSV demo: https://github.com/petertodd/csv-demos
313 2015-11-26 20:25:50 <btcdrak> <3
314 2015-11-26 20:25:56 <petertodd> aj: I'd be surprised if the code worked at all :)
315 2015-11-26 20:26:28 <btcdrak> aj: what's your preference for opcode name?
316 2015-11-26 20:26:34 <petertodd> aj: this one for CLTV does work though: https://github.com/petertodd/checklocktimeverify-demos/blob/master/hodl.py
317 2015-11-26 20:29:09 <aj> btcdrak: weak preference for CHECKMATURITYVERIFY since it's short despite keeping the CHECK*VERIFY pattern. RCHECKLOCKTIMEVERIFY is my least favourite, it's both long and kind of obscure
318 2015-11-26 20:29:56 <CodeShark> you think it's obscure?
319 2015-11-26 20:30:54 <aj> CodeShark: the "R" is pretty important for just 5% of the opcode name :)
320 2015-11-26 20:31:18 <CodeShark> yes, granted - but expanding that out makes it even more verbose
321 2015-11-26 20:31:32 <aj> CodeShark: yep
322 2015-11-26 20:31:36 <CodeShark> and we already have CHECKLOCKTIMEVERIFY
323 2015-11-26 20:31:57 <CodeShark> I'd just go with OP_CLTV and OP_RCLTV and make sure to document it well in the script documentation :)
324 2015-11-26 20:32:19 <btcdrak> yeah, people alreayd know it well as CLTV
325 2015-11-26 20:32:56 <aj> btcdrak: (oh, and CSV overlaps with checksigverify as well as .csv files)
326 2015-11-26 20:33:07 <btcdrak> yeah maybe OP_RCLTV
327 2015-11-26 20:33:24 <aj> (why RCLTV not CRLTV?)
328 2015-11-26 20:33:31 <btcdrak> aj: well there's another good reason not to use CSV
329 2015-11-26 20:33:38 <sipa> CRLF tv?
330 2015-11-26 20:33:50 <CodeShark> CRLTV looks too much like CTRL-V
331 2015-11-26 20:33:53 <CodeShark> :p
332 2015-11-26 20:34:01 <btcdrak> >.<
333 2015-11-26 20:34:02 <aj> sipa: ...i'd watch the pilot episode of that.
334 2015-11-26 20:35:30 <CodeShark> I prefer RCLTV to CRLTV because prefixes to an existing seme are easier to use
335 2015-11-26 20:35:54 <CodeShark> i.e are we using absolute or relative locktime?
336 2015-11-26 20:36:05 <CodeShark> not are we using lock absolute time or lock relative time
337 2015-11-26 20:37:47 <CodeShark> although the example isn't exact since your suggestion actually infixes between "check" and "lock", not between "lock" and "time"
338 2015-11-26 20:38:20 <CodeShark> but the point still holds :)
339 2015-11-26 20:38:36 <vangke> im using multibit for sending bitcoin but now the result is showing on Block Chain is transaction not found ! may i know how to do?
340 2015-11-26 20:38:43 <aj> CodeShark: in my head, locktime is relative or absolute
341 2015-11-26 20:38:51 <btcdrak> vangke: ask in #bitcoin please
342 2015-11-26 20:38:58 <vangke> ok
343 2015-11-26 20:39:05 <CodeShark> aj: ok,  I see your point
344 2015-11-26 20:39:31 <CodeShark> yeah, I guess the pattern is actually check <condition> verify
345 2015-11-26 20:39:39 <aj> CodeShark: (also, i don't actually care -- if i don't like the name, i'll just make an alias...)
346 2015-11-26 20:40:28 <aj> CodeShark: CLTV as an acronym is definitely easy to treat as a "seme" and prefix with an R though
347 2015-11-26 20:40:48 <CodeShark> right,  that's sort of how I was thinking about it
348 2015-11-26 20:41:10 <aj> CodeShark: i suppose CHECK_MATURITY_TIME_VERIFY  (CLTV vs CMTV)  would be dumb...
349 2015-11-26 20:41:16 <CodeShark> but strictly speaking, it breaks the opcode naming convention
350 2015-11-26 20:41:39 <CodeShark> RCLTV, that is
351 2015-11-26 20:43:58 <CodeShark> the problem I have with maturity is that even though the logic is equivalent to  the coinbase use case, from an app developer standpoint the two are actually quite different
352 2015-11-26 20:44:17 <sipa> and in the code they are also completely separate
353 2015-11-26 20:45:39 <CodeShark> maturity is a feature of the system to limit the disruptive impact of reorgs whereas locktime is a user-definable constraint on spending
354 2015-11-26 21:09:48 <frank1e> anyone here managed to get bitcoind running (without having to run the gui client in the background) on mac os x 10.11.1 ?
355 2015-11-26 21:10:17 <frank1e> or getting it to run in general? or even getting past the "make" step? :D
356 2015-11-26 21:13:42 <btcdrak> frankle: probably should be in #bitcoin not sure, but anyway, have you read https://github.com/bitcoin/bitcoin/blob/master/doc/build-osx.md ?
357 2015-11-26 21:16:54 <frank1e> btcdrak yes that's exactly the guide I followed
358 2015-11-26 21:17:24 <frank1e> but no luck, some weird errors appear, no luck with any kind of research yet (and I also don't understand them)
359 2015-11-26 21:17:28 <btcdrak> frankle: I cant be more helpful I am afraid because I dont run OSX
360 2015-11-26 21:17:49 <btcdrak> ask in #bitcoin
361 2015-11-26 21:18:11 <frank1e> yeah did, no response yet. wanted to try my luck here. maybe I'll just ask another day then :)
362 2015-11-26 21:18:18 <frank1e> (in #bitcoin)
363 2015-11-26 22:48:07 <aj> btcdrak: do you have a repo that has OP_RELATIVE_HODL enabled?
364 2015-11-26 22:49:26 <Traumzauberbaum> I want to run a bitcore-node but the bootstrapping is taking forever (est. a week) can it be accelerated? is it risky to download the blockchain from a third party? would that even help? what are the risks?
365 2015-11-26 22:50:15 <aj> btcdrak: https://github.com/btcdrak/bitcoin/commits/checksequenceverify maybe?