1 2016-04-28 15:23:06	0|Chris_Stewart_5|"BIP 68 prevents a non-final transaction from being selected for inclusion in a block until the corresponding input has reached the specified age,"
  2 2016-04-28 15:23:14	0|Chris_Stewart_5|Shouldn't 'input' be changed to 'output'?
  3 2016-04-28 15:23:39	0|Chris_Stewart_5|this is in BIP112
  4 2016-04-28 15:46:16	0|kanzure|for syncing an external application against bitcoind block history, i think getblock and _batch requests of getblockhash are the only options when receiving a blocknotify event, right?
  5 2016-04-28 15:46:37	0|kanzure|i was thinking about implementing a getallblockhashes rpc command. i'm hesitant though because i'm not sure why it doesn't already exist.
  6 2016-04-28 15:50:25	0|kanzure|the only other way to check if you are missing gaps of block history is by recursively calling getblockhash and getblock (starting from your last known best block) and ignoring the blocknotify parameter value. however, this is problematic for developers because they would have to also implement a "reverse" mode because if you run "getblock" from your last known block in some database then you will also have to go back in history in ...
  7 2016-04-28 15:50:32	0|kanzure|... the event of a recent reorg (e.g. maybe you had a stale block at your tip). this seems like more work than just working with a list of all blockhashes and comparing against your list of known blockhashes. right?
  8 2016-04-28 15:52:32	0|kanzure|alternatively: how much overhead is _batch rpc stuff in comparison to a single rpc call like a hypothetical "getallblockhashes"?
  9 2016-04-28 15:55:14	0|wumpus|pretty much the same
 10 2016-04-28 15:56:03	0|wumpus|the RPC batching functionality is severly underused, an example is contrib/linearize
 11 2016-04-28 15:56:35	0|instagibbs|wumpus, so, how do I use it
 12 2016-04-28 15:56:37	0|wumpus|it requests all the block hashes, though not in a way that copes with reorgs
 13 2016-04-28 15:56:48	0|wumpus|(it's meant as one-shot)
 14 2016-04-28 15:57:01	0|kanzure|https://github.com/bitcoin/bitcoin/blob/7fc25c2e5d493f4ef46c9b5831d92886bcea17a8/contrib/linearize/linearize-hashes.py#L64
 15 2016-04-28 15:57:08	0|kanzure|oh this is using an interval
 16 2016-04-28 15:57:24	0|kanzure|alright well, my method copes with reorgs by grabbing all blockhashes
 17 2016-04-28 15:57:47	0|sipa|https://github.com/sipa/bitcoin-stats/blob/master/keepdump.pl
 18 2016-04-28 15:57:58	0|sipa|that maintains a list of all blocks in a text file
 19 2016-04-28 15:58:05	0|kanzure|_batch 500,000 rpc requests for getblockhash is taking me like >10 seconds. wouldn't a hypothetical "getallblockhashes" take less than this? do we have an index in leveldb of all the blockhashes?
 20 2016-04-28 15:58:08	0|sipa|it also doesn't deal with reorgs, as it just puts all blocks there
 21 2016-04-28 15:58:19	0|sipa|kanzure: nope, in memory
 22 2016-04-28 15:58:21	0|sipa|:p
 23 2016-04-28 15:58:35	0|kanzure|in memory sounds good, that should be fast to dump over rpc
 24 2016-04-28 15:58:41	0|kanzure|yeah we should do this
 25 2016-04-28 15:58:53	0|sipa|sounds like something for the REST interface
 26 2016-04-28 15:59:07	0|sipa|actually, doesn't it already have that?
 27 2016-04-28 15:59:11	0|sipa|fetching a range of block headers
 28 2016-04-28 15:59:25	0|kanzure|range is incompatible with reorgs
 29 2016-04-28 16:00:07	0|kanzure|you can do range + confirmationwaitdepth i guess (where confirmationwaitdepth is your risk threshold for accepting deposits or payments or whatever)
 30 2016-04-28 16:00:27	0|wumpus|kanzure: until http streaming is implemented we don't really want anything that returns that much data
 31 2016-04-28 16:00:57	0|kanzure|wumpus: well, that makes sense, but in the mean time i'm not sure what applications are using...? calling getblock a few hundred thousand times is dumb.
 32 2016-04-28 16:01:09	0|wumpus|in the meantime just use batching
 33 2016-04-28 16:01:21	0|kanzure|but... it's slow.
 34 2016-04-28 16:01:30	0|sipa|kanzure: you only need to call it a few 100000 times at first startup
 35 2016-04-28 16:01:37	0|wumpus|REST is much faster than using getblock
 36 2016-04-28 16:01:49	0|sipa|kanzure: after that you just look at the tip, and go backwards to update your best known state
 37 2016-04-28 16:01:51	0|wumpus|saves the encoding overhead as first hex then JSON
 38 2016-04-28 16:01:59	0|kanzure|getblock isn't the problem, i'm using _batch with getblockhash only
 39 2016-04-28 16:02:01	0|wumpus|and you can pipeline requests on the same TCP connection
 40 2016-04-28 16:02:31	0|wumpus|also how many times do you expect to do this? is ten seconds really a problem?
 41 2016-04-28 16:02:33	0|kanzure|sipa: "go backwards" using getblock? i am "going backwards" using _batch getblockhash because i don't want to call "getblock" a few thousand times.
 42 2016-04-28 16:02:48	0|kanzure|wumpus: well i am getting socket timeouts... so yes. usually it does not take that long. but it varies. sometimes i am getting socket timeouts.
 43 2016-04-28 16:02:58	0|sipa|kanzure: i don't understand why you need to see all hashes
 44 2016-04-28 16:03:02	0|wumpus|increase your socket timeout
 45 2016-04-28 16:03:09	0|wumpus|it's the client that timeouts, never the server
 46 2016-04-28 16:03:22	0|wumpus|server won't timeout while it's working and not waiting for client input
 47 2016-04-28 16:03:24	0|kanzure|sipa: i don't need to see all the hashes, i agreed with you that a range is OK (like in the linearize script) plus/minus the number of confirmations that you feel safe waiting for, e.g. so that you can be reorg-compatible.
 48 2016-04-28 16:04:34	0|wumpus|kanzure: the default timeout is set to 30 seconds or so, that's not a lot, esp if you're batching
 49 2016-04-28 16:05:01	0|wumpus|instagibbs: linearize provides an example, I should also have a very simple proof of concept somewhere but can't find it  right now
 50 2016-04-28 16:05:07	0|kanzure|sipa: i guess i could limit the getblockhash calls in my _batch request, to be (blockheight in database) minus (200 confirmations) or something.
 51 2016-04-28 16:05:56	0|wumpus|(it depends on what client library you use)
 52 2016-04-28 16:09:32	0|kanzure|wumpus: sipa: thank you.
 53 2016-04-28 16:26:16	0|instagibbs|cool thanks
 54 2016-04-28 18:26:16	0|instagibbs|cool thanks
 55 2016-04-28 19:07:50	0|GitHub114|[13bitcoin] 15laanwj opened pull request #7966: http: Do a pending c++11 simplification handling work items (06master...062016_04_httpserver_c++11) 02https://github.com/bitcoin/bitcoin/pull/7966
 56 2016-04-28 20:50:50	0|jonasschnelli|why does CFeeRate has not setter?
 57 2016-04-28 20:51:02	0|jonasschnelli|Or am I missing something?
 58 2016-04-28 20:57:26	0|wumpus|it's just a value, if you need to assign a new value just assign a new CFeeRate(...) object
 59 2016-04-28 20:57:57	0|jonasschnelli|Right. But overloading = op. with a CAmount would be something. Not?
 60 2016-04-28 20:57:57	0|wumpus|no need to be able to change it partially
 61 2016-04-28 20:58:13	0|wumpus|I don't think that's necessary
 62 2016-04-28 20:58:25	0|wumpus|(sounds slightly confusing to me)
 63 2016-04-28 20:58:27	0|jonasschnelli|But right. feeRate = CFeeRate(new) is fine.
 64 2016-04-28 20:58:36	0|wumpus|better to be explicit
 65 2016-04-28 20:59:28	0|gmaxwell|Meeting time soon.
 66 2016-04-28 20:59:49	0|jonasschnelli|jtimon: meeting now.
 67 2016-04-28 21:00:09	0|jtimon|thanks
 68 2016-04-28 21:00:11	0|lightningbot|Meeting started Thu Apr 28 19:00:11 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
 69 2016-04-28 21:00:11	0|wumpus|#startmeeting
 70 2016-04-28 21:00:12	0|gmaxwell|sipa: jonasschnelli wumpus morcos sdaftuar kanzure BlueMatt jtimon cfields luke-jr petertodd
 71 2016-04-28 21:00:12	0|lightningbot|Useful Commands: #action #agreed #help #info #idea #link #topic.
 72 2016-04-28 21:00:29	0|wumpus|proposed topics?
 73 2016-04-28 21:00:30	0|sipa|mildly present
 74 2016-04-28 21:00:48	0|kanzure|i propose follow-up from last week re: segwit code review, and new/upcoming tasks on that front
 75 2016-04-28 21:00:50	0|morcos|i'm here for 10 mins
 76 2016-04-28 21:01:02	0|kanzure|gmaxwell: thanks for the ping
 77 2016-04-28 21:01:03	0|jonasschnelli|I have two very small topic proposals: wording for RBF, a request for creating/storing CI material
 78 2016-04-28 21:01:05	0|gmaxwell|morcos: anything you want to talk about in 10 minutes.
 79 2016-04-28 21:01:10	0|cfields|thanks, here
 80 2016-04-28 21:01:31	0|morcos|just to encourage anyone who is going to review segwit to get on it!  :)
 81 2016-04-28 21:01:56	0|wumpus|action items of last time were a) more code review of segwit 2) kanzure: look at test coverage output 3) (Luke) update GBT segwit stuff 4) (jtimon) tutorial to enable travis on your own repo 5) (cfields) travis changes requiring some downtime 6) merge #7920 when cfields says so
 82 2016-04-28 21:01:57	0|kanzure|i have some segwit review notes but they are not precisely publicly consumable, can i get a volunteer to go through my notes? ideally not sipa :)
 83 2016-04-28 21:01:59	0|gmaxwell|What is the status of the segwit BIPs? are they all consistent with the implementation right now?
 84 2016-04-28 21:02:28	0|kanzure|wumpus: if i was supposed to look at test coverage output then i totally barfed on that, my bad-- i thought someone else took that.
 85 2016-04-28 21:02:29	0|wumpus|last two items are done at least, transition to trusty and c++11 was succesful
 86 2016-04-28 21:02:50	0|gmaxwell|\O/
 87 2016-04-28 21:02:52	0|wumpus|kanzure: yes the name is who suggested it, Idon't know the context
 88 2016-04-28 21:02:53	0|jtimon|wumpus: re 4 I thought cfields was going to write the tutorail, not me...I'm still on https://docs.travis-ci.com/user/getting-started/
 89 2016-04-28 21:02:58	0|sdaftuar|kanzure: i'd be happy to review your notes
 90 2016-04-28 21:03:07	0|kanzure|sdaftuar: cool, i will spam you with them
 91 2016-04-28 21:03:17	0|cfields|jtimon: sorry, i got lost in the transition stuff
 92 2016-04-28 21:03:24	0|wumpus|jtimon: oh maybe he's going to, but he had a lot on his hands
 93 2016-04-28 21:03:46	0|jtimon|no hurry, just saying that I'm not working on that
 94 2016-04-28 21:04:01	0|wumpus|okay :)
 95 2016-04-28 21:04:25	0|wumpus|how is the review of segwit going?
 96 2016-04-28 21:04:34	0|kanzure|sdaftuar: you have been spammed, thanks.
 97 2016-04-28 21:05:53	0|morcos|wumpus: i'm feeling pretty good, but it's hard to tell who all has done deep commit by commit reviews
 98 2016-04-28 21:05:55	0|kanzure|topic suggestion-- how to convince sipa to give more context about testing status of segwit
 99 2016-04-28 21:06:15	0|sdaftuar|wumpus: i'm slowly making my way through
100 2016-04-28 21:06:23	0|wumpus|morcos: good to hear that you're making your way through
101 2016-04-28 21:06:24	0|kanzure|morcos: perhaps we should all post about our review status?
102 2016-04-28 21:06:32	0|cfields|tangentially: I've finally started working with the mining pools (with Kang's help translating) to ensure that their real-world environments. Aim is to get at least one segnet block mined by each pool. Happy to report that last night, BTCC's patched pool mined a few blocks. I'll be working with the others in the coming days
103 2016-04-28 21:06:49	0|morcos|cfields: oh thats great!
104 2016-04-28 21:07:00	0|cfields|*segnet block with witness txs, ofc
105 2016-04-28 21:07:07	0|kanzure|i have done a preliminary read of all the diffs for segwit but not commit-by-commit.... i have a number of places that i am considering investigating the test situation more closely but it's all probably dead-ends ( sdaftuar to advise ).
106 2016-04-28 21:07:10	0|morcos|time for someone else to get some segnet coins, i have too many
107 2016-04-28 21:07:46	0|sipa|i could list a few areas where i think mildly tricky things are done that warrant review
108 2016-04-28 21:07:51	0|kanzure|yes please.
109 2016-04-28 21:08:50	0|wumpus|#action (sipa) list a few areas where i think mildly tricky things are done that warrant review
110 2016-04-28 21:08:56	0|morcos|sipa: in particular the areas that are new for me (such as the wallet/signing code) are harder to be confident about.  i'd feel better knowing others are reviewing it as well
111 2016-04-28 21:09:21	0|sipa|good to know
112 2016-04-28 21:09:32	0|kanzure|signaturehash changes were specified by bip and one (trivial) review task is "confirm it follows the bip spec"
113 2016-04-28 21:09:47	0|morcos|sipa: harder b/c of me, not b/c the code is tricky looking
114 2016-04-28 21:10:14	0|instagibbs|morcos, maybe have people express review coverage with amount of certainty based on familiarity with the code
115 2016-04-28 21:10:33	0|sipa|the wallet signing code adds a refactor to stop working directly on scriotsigs, but initially work on just the stacks being pushed, and only convert them at the last step
116 2016-04-28 21:10:52	0|instagibbs|for me, review of wallet code was much easier than parsing the tree commitment stuff
117 2016-04-28 21:11:02	0|cfields|kanzure: some input from other projects (NicolasDorier *poke*) may be helpful there.
118 2016-04-28 21:11:14	0|morcos|instagibbs: i like that idea. not sure how easy it is to break up
119 2016-04-28 21:11:37	0|instagibbs|that said, I read *every* commit, and attempted best-effort understanding
120 2016-04-28 21:11:37	0|sipa|cfields: i'd like some comments from you ob luke-jr's proposed bip9 gbt changes
121 2016-04-28 21:11:54	0|cfields|sipa: ah, right. ack.
122 2016-04-28 21:11:54	0|morcos|ok got to run.  overall, yay for c++11, yay for segwit!
123 2016-04-28 21:12:17	0|gmaxwell|I was talking to nickler about doing consensus harness tests for verifying consensus consistence, e.g. between 0.13 and 0.12.x or pre-segwit. Maybe there will be something to report there in a week or so.
124 2016-04-28 21:12:47	0|jtimon|yeah, for example, I'm less familiar with the p2p and wallet parts, unfortunately I don't think I will be able to give a full utACK to #7910, but that of course shouldn't not stop it from being merged
125 2016-04-28 21:13:22	0|instagibbs|jtimon, which brings me to my point, aside from sipa and a few others, I doubt anyone can full utACK #7910
126 2016-04-28 21:14:09	0|kanzure|one of the things i'd like to investigate more closely is the set of tests that were written versus the expected set of tests... but hard to find all the corner cases.
127 2016-04-28 21:15:00	0|jtimon|instagibbs: good point, the PR touches many parts. I think I will focus on the consensus and relay policy parts and only utACK that
128 2016-04-28 21:15:03	0|sipa|also in general: what do people think of the strategy i've been following to not rebase/squash, but only add small patches and a changing merge commit at the end?
129 2016-04-28 21:15:23	0|kanzure|sipa: i think that is a good idea. it gives us time to ACK various older commits.
130 2016-04-28 21:15:31	0|instagibbs|jtimon, seems wise, people have to self-select what they feel competent to review
131 2016-04-28 21:16:00	0|sipa|at some point i'll squash and rebase in such a way that the resulting tree id identical to the old broken down branch
132 2016-04-28 21:16:07	0|jtimon|sipa: no strong opinion but it seems to partly defeat the point of having the commits separated in related sections (btw, I would separate p2p from consensus)
133 2016-04-28 21:16:42	0|kanzure|tree id similarity is a nice approach....
134 2016-04-28 21:16:49	0|kanzure|(git ls-tree and such)
135 2016-04-28 21:17:19	0|sipa|jtimon: i'll keep the section
136 2016-04-28 21:17:26	0|sdaftuar|sipa: some kind of warning before you squash/rebase would be helpful for me at least
137 2016-04-28 21:17:45	0|sdaftuar|sipa: but i like how you've done it so far
138 2016-04-28 21:17:46	0|kanzure|it would also be good if you could keep the original commits around on your git repo
139 2016-04-28 21:17:52	0|sipa|kanzure: of course
140 2016-04-28 21:17:54	0|jtimon|sipa: I see, so your question is more about squashing only once at the end, fine with me
141 2016-04-28 21:17:59	0|sipa|it needs to be verifiable
142 2016-04-28 21:18:03	0|kanzure|good, thanks.
143 2016-04-28 21:18:25	0|cfields|sipa: you can just push to a spare branch before final squash, then we can diff the two
144 2016-04-28 21:18:42	0|jonasschnelli|only add commits, once we have enough ACKS, hash the diff, rebase, check the hash of the diff and merge?
145 2016-04-28 21:18:55	0|sipa|jonasschnelli: indeed
146 2016-04-28 21:20:06	0|wumpus|ok next topic?
147 2016-04-28 21:20:29	0|wumpus|#topic status of the segwit BIPs
148 2016-04-28 21:21:19	0|wumpus|(gmaxwell)
149 2016-04-28 21:21:30	0|achow101|bip 144 needs to include the service bit stuff
150 2016-04-28 21:22:23	0|wumpus|everyone agree?
151 2016-04-28 21:22:48	0|sipa|ugh, that was never uodated
152 2016-04-28 21:22:51	0|sipa|yes, agree
153 2016-04-28 21:23:15	0|wumpus|#action bip 144 needs to include the service bit stuff
154 2016-04-28 21:23:31	0|gmaxwell|I suppose we should try to extract some feedback e.g. from roastbeef to reimplemented, who might be aware of other limitations in the spec.
155 2016-04-28 21:23:50	0|instagibbs|roasbeef*
156 2016-04-28 21:24:00	0|petertodd|just noticed someone has a python-bitcoinlib segwit branch too
157 2016-04-28 21:24:07	0|achow101|armory does as well
158 2016-04-28 21:24:28	0|petertodd|(sorry, just got in)
159 2016-04-28 21:24:59	0|wumpus|petertodd: just in time for the python-bitcoinlib segwit branch!
160 2016-04-28 21:25:31	0|petertodd|wumpus: ha yeah - no credit to me though :)
161 2016-04-28 21:26:20	0|wumpus|#action (gmaxwell) try to extract some feedback e.g. from roasbeef to reimplemented, who might be aware of other limitations in the spec
162 2016-04-28 21:26:46	0|sipa|we have gotten some comments from a few people and making small clarifications frequently
163 2016-04-28 21:26:55	0|sipa|including from tadge
164 2016-04-28 21:27:29	0|sipa|i'm surprised nobody commented about the service bit
165 2016-04-28 21:27:52	0|achow101|sipa: I think I brought it up a couple of weeks ago but didn't follow up on it
166 2016-04-28 21:28:02	0|sipa|achow101: sorry then!
167 2016-04-28 21:29:22	0|instagibbs|I can verify 141 and 143 match up
168 2016-04-28 21:30:33	0|wumpus|great
169 2016-04-28 21:32:16	0|sipa|small update: the reviewer that btcdrak contacted about ctaes wrote a report
170 2016-04-28 21:32:33	0|jonasschnelli|sipa: the tor lead dev?
171 2016-04-28 21:32:51	0|sipa|jonasschnelli: no, someone mathhew green recommemded
172 2016-04-28 21:33:04	0|sipa|he formally proved that some parts were correct, and analyzed the condtant timeness
173 2016-04-28 21:33:07	0|jonasschnelli|Okay. Good. What was the result?
174 2016-04-28 21:33:09	0|sipa|i can share the reoort
175 2016-04-28 21:33:11	0|petertodd|sipa: +1
176 2016-04-28 21:33:16	0|sipa|a+ :)
177 2016-04-28 21:33:25	0|jonasschnelli|sipa: Can you add it on your ctaes repository?
178 2016-04-28 21:33:27	0|wumpus|awesome!
179 2016-04-28 21:33:49	0|cfields|sipa: nice!
180 2016-04-28 21:35:16	0|sipa|any more topics? i'll be off otherwise
181 2016-04-28 21:35:30	0|jonasschnelli|RBF naming: should we flag/attribute RBF transaction as "replaceable" or should we attribute "current" non RBF transaction as "non-replacable"?
182 2016-04-28 21:35:59	0|petertodd|jonasschnelli: I'd lean towards replacable, as non-replacable implies we're promising something...
183 2016-04-28 21:36:00	0|jl2012|bringing segwit testing to testnet?
184 2016-04-28 21:36:09	0|gmaxwell|the former, I think. It's incorrect to say non-RBF is non-replacable; they're just somewhat less replacable.
185 2016-04-28 21:36:55	0|wumpus|agree with gmaxwell
186 2016-04-28 21:37:13	0|jonasschnelli|Okay. I agree as well. Will continue with this term.
187 2016-04-28 21:37:16	0|instagibbs|'mempool-replaceable' ?
188 2016-04-28 21:37:26	0|petertodd|doublespends happen all the time, and only a small subset of them are opt-in RBF txs
189 2016-04-28 21:37:42	0|jl2012|sipa: are we ready to define the testnet BIP9 parameter for segwit?
190 2016-04-28 21:37:42	0|wumpus|but RBF transactions the user can easily replace themselves
191 2016-04-28 21:37:47	0|wumpus|that should be the focus imo
192 2016-04-28 21:38:06	0|wumpus|what the user can do with it
193 2016-04-28 21:38:10	0|jonasschnelli|instagibbs: I was also thinking about that. But does the normal bitcoin-qt user really knows what the mempool is?
194 2016-04-28 21:38:13	0|jtimon|"standard-policy-0.12-replaceable"?
195 2016-04-28 21:38:27	0|jonasschnelli|:}
196 2016-04-28 21:38:40	0|jonasschnelli|"standard-policy-0.12-BIP125-replaceable"
197 2016-04-28 21:38:40	0|petertodd|jtimon: all the user's node knowns is they think it's replacable, so the 0.12 is implicit :)
198 2016-04-28 21:39:13	0|wumpus|yes the 0.12 is implicit, the BIP125 part makes sense
199 2016-04-28 21:39:34	0|jtimon|yeah, 0.12 was kind of joking, the point is all tx are equally replaceable with a custom policy, the opt-in stuff is just about the standard policy
200 2016-04-28 21:39:36	0|petertodd|don't we already have a bip125-replacable or similar name used in the RPC anyway?
201 2016-04-28 21:39:54	0|jonasschnelli|petertodd: Yes. Listtransaction
202 2016-04-28 21:40:03	0|wumpus|yes entry.push_back(Pair("bip125-replaceable", rbfStatus));
203 2016-04-28 21:40:21	0|jtimon|ack bip125-replaceable
204 2016-04-28 21:40:27	0|jonasschnelli|Also I think someone should refactor the RBF BIP125 rules to the new rbf.cpp
205 2016-04-28 21:40:31	0|petertodd|jtimon: you can also replace txs by flooding mempools and getting them kicked out :)
206 2016-04-28 21:40:40	0|jonasschnelli|The bumpfee or feealter command could than re-check the validity
207 2016-04-28 21:40:52	0|jonasschnelli|s/re-check/pre-check
208 2016-04-28 21:41:37	0|jonasschnelli|In the GUI we should probably just use the term "replaceable".
209 2016-04-28 21:42:23	0|jtimon|then we have the same problem I think
210 2016-04-28 21:42:24	0|petertodd|jonasschnelli: "easily replacable"
211 2016-04-28 21:42:27	0|jtimon|opt-in-repleaceable ?
212 2016-04-28 21:42:39	0|petertodd|jonasschnelli: or heck, "trivially replacable"
213 2016-04-28 21:42:45	0|paveljanik|"updatable"?
214 2016-04-28 21:43:03	0|luke-jr|"replacement-requested"
215 2016-04-28 21:43:05	0|jonasschnelli|of "signs replicability"?
216 2016-04-28 21:43:21	0|petertodd|paveljanik: eh, changing the name to something other than replacable would invite trolling possibly
217 2016-04-28 21:43:39	0|paveljanik|replacability signalled ;-)
218 2016-04-28 21:43:48	0|jonasschnelli|replacability signalled: +1
219 2016-04-28 21:43:57	0|wumpus|yes I think whatever the name is it should contain 'replace', otherwise it's too confusing, introducing completely new terminology
220 2016-04-28 21:44:03	0|petertodd|wumpus: +1
221 2016-04-28 21:44:06	0|jonasschnelli|Indeed
222 2016-04-28 21:44:13	0|wumpus|replaceability signalled sounds good to me
223 2016-04-28 21:44:22	0|petertodd|sure, why not
224 2016-04-28 21:44:36	0|jonasschnelli|ack
225 2016-04-28 21:44:39	0|jtimon|"replace explicitly allowed"?
226 2016-04-28 21:44:41	0|sdaftuar|fee-replaceable ?
227 2016-04-28 21:44:57	0|jonasschnelli|sdaftuar: but it could also add a output
228 2016-04-28 21:44:57	0|jtimon|I mean, "replacability signalled" is good enough for me
229 2016-04-28 21:45:28	0|jonasschnelli|sdaftuar: but right. You mean replaceable by fee
230 2016-04-28 21:45:37	0|sdaftuar|yeah, you can replace it if you up the fee
231 2016-04-28 21:45:58	0|jonasschnelli|"fee-replacability signalled"?
232 2016-04-28 21:46:06	0|petertodd|jonasschnelli: which is tricky, because any low fee tx is in practice replacable by fee regardless of whether bip125 is used or not
233 2016-04-28 21:46:20	0|sdaftuar|but not by your wallet
234 2016-04-28 21:46:38	0|wumpus|I don't think the GUI term needs to be so specific - just make sure that the mouseover or other documentation explains it in more detail
235 2016-04-28 21:46:46	0|jonasschnelli|Sure. But the term would also be for attributing incoming payment.
236 2016-04-28 21:46:46	0|sdaftuar|+1
237 2016-04-28 21:46:47	0|petertodd|oh, key question: are we going to show this for all txs, or just txs sent by the user?
238 2016-04-28 21:46:54	0|paveljanik|sdaftuar, depends on the wallet IMO
239 2016-04-28 21:46:56	0|jtimon|petertodd: exactly, for all we know, miners could replace by hash alphabetic order rather than fees
240 2016-04-28 21:47:01	0|cfields|sdaftuar: i like that, but it describes the mechanics more than the intent.
241 2016-04-28 21:47:07	0|jonasschnelli|petertodd: incoming and outdoing.
242 2016-04-28 21:47:25	0|petertodd|jonasschnelli: see, if it was just outgoing, this conversation would be a lot simpler :)
243 2016-04-28 21:48:11	0|wumpus|replacability signalled is fine, let's move on
244 2016-04-28 21:48:15	0|jonasschnelli|incoming tx: "replacability signalled", create tx: "[ ] signall replacability"
245 2016-04-28 21:48:18	0|jonasschnelli|ack.
246 2016-04-28 21:48:21	0|jtimon|what was wrong about "Opted in to replacement" or something along those lines?
247 2016-04-28 21:48:23	0|wumpus|any other topics?
248 2016-04-28 21:48:45	0|jtimon|yeah, nv, "replacability signalled" does it
249 2016-04-28 21:48:59	0|jtimon|s/nv/never mind
250 2016-04-28 21:49:01	0|jonasschnelli|topic: another boring one, not sure if this is the right place: Someone contacted me that we should have a repository for Bitcoin Core logos and communication material.
251 2016-04-28 21:49:11	0|jonasschnelli|Somehow that made me think that Bitcoin Core has no clear logo/visual identity. Its not define what to use when, the font, the colors. Not sure if anyone from us cares about that though.
252 2016-04-28 21:49:26	0|paveljanik|press kit? ;-)
253 2016-04-28 21:49:31	0|petertodd|paveljanik: +1
254 2016-04-28 21:49:44	0|jonasschnelli|We probably don't care. But out userbase does a lot
255 2016-04-28 21:49:46	0|petertodd|paveljanik: or maybe call it "media kit" to shift focus to all media in general
256 2016-04-28 21:49:50	0|jonasschnelli|*our
257 2016-04-28 21:49:59	0|btcdrak|jonasschnelli: a press kit would be a good idea
258 2016-04-28 21:50:06	0|wumpus|we don't have that, but if anyone wants to make it and collect some things why not
259 2016-04-28 21:50:54	0|jonasschnelli|It would imply that we first need to create a identity, proper logo, font, etc. I'm not interested ATM, but happy if someone know someone who is.
260 2016-04-28 21:50:56	0|btcdrak|jonaschnelli: ideally we could store that in a "media kit" repository.
261 2016-04-28 21:51:16	0|jonasschnelli|I think it should be a subarea of the website
262 2016-04-28 21:51:37	0|petertodd|jonasschnelli: that makes sense
263 2016-04-28 21:51:46	0|wumpus|yes I think the question is more *who* than if, I don't think press kits are very usual for open source projects, but if someone wants to work on that I don't want to discourage
264 2016-04-28 21:52:21	0|jonasschnelli|Agree.
265 2016-04-28 21:52:26	0|sipa|wumpus: they're very common among altcoins though :p
266 2016-04-28 21:52:28	0|cfields|wumpus: for open-source, they almost always accompany a licensing policy
267 2016-04-28 21:52:41	0|cfields|(lived through that hell for a while in a past life)
268 2016-04-28 21:52:50	0|wumpus|cfields: yes, as for firefox
269 2016-04-28 21:52:54	0|cfields|right
270 2016-04-28 21:53:38	0|cfields|so for us, unless we wanted to police it, a press kit would be more of a collection of recommended images/text that we also use.
271 2016-04-28 21:54:08	0|cfields|i suppose that was the idea, though
272 2016-04-28 21:54:09	0|wumpus|right
273 2016-04-28 21:54:10	0|jonasschnelli|Yes. There is even no clear logo that Bitcoin Core uses/represents.
274 2016-04-28 21:54:15	0|warren|"\nExamples:\n"
275 2016-04-28 21:54:17	0|warren|+ HelpExampleCli("getnewaddress", "")
276 2016-04-28 21:54:21	0|warren|+ HelpExampleRpc("getnewaddress", "")
277 2016-04-28 21:54:23	0|warren|Any idea why this has both, and they're identical?
278 2016-04-28 21:54:25	0|jonasschnelli|warren: dumpprivatekey
279 2016-04-28 21:54:39	0|wumpus|warren: we're in the middle of a meeting
280 2016-04-28 21:54:45	0|warren|oops sorry!
281 2016-04-28 21:54:46	0|wumpus|well, at the end
282 2016-04-28 21:55:20	0|wumpus|I think we're done
283 2016-04-28 21:55:35	0|jonasschnelli|\ö/
284 2016-04-28 21:55:37	0|wumpus|#endmeeting
285 2016-04-28 21:55:38	0|lightningbot|Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-04-28-19.00.log.html
286 2016-04-28 21:55:38	0|lightningbot|Meeting ended Thu Apr 28 19:55:37 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
287 2016-04-28 21:55:38	0|lightningbot|Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-04-28-19.00.html
288 2016-04-28 21:55:38	0|lightningbot|Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-04-28-19.00.txt
289 2016-04-28 21:55:50	0|warren|jonasschnelli: ok, not understanding what you mean
290 2016-04-28 21:55:55	0|wumpus|warren: we have cli and rpc examples for all the help items
291 2016-04-28 21:56:06	0|warren|why are they both provided when identical?
292 2016-04-28 21:56:08	0|wumpus|warren: just do 'help getnewaddress' to see what the output is
293 2016-04-28 21:56:17	0|jonasschnelli|warren: nm. RPC does form a different help line then cli
294 2016-04-28 21:56:28	0|wumpus|they aren't identical
295 2016-04-28 21:56:46	0|wumpus|the result is different, they call different functions that have different output, just happens to be with the same arguments
296 2016-04-28 21:56:55	0|warren|oh ok, thanks
297 2016-04-28 21:57:25	0|wumpus|as said, just check 'bitcoin-cli help getnewaddress` and you'll see
298 2016-04-28 22:07:46	0|GitHub17|[13bitcoin] 15jonasschnelli opened pull request #7967: [RPC] add feerate option to fundrawtransaction (06master...062016/04/fund_fee) 02https://github.com/bitcoin/bitcoin/pull/7967
299 2016-04-28 22:53:05	0|guest78678|why are we keeping AcceptToMemoryPoolWorker in main?
300 2016-04-28 23:24:11	0|instagibbs|did someone volunteer to fix up bip144? missed the last part of meeting
301 2016-04-28 23:36:38	0|btcdrak|instagibbs: it was you iirc.
302 2016-04-28 23:39:17	0|achow101|instagibbs: I was going to do it in a few minutes if no one else did, but you can do it if you want
303 2016-04-28 23:40:03	0|btcdrak|achow101: I was teasing instagibbs. Go ahead.
304 2016-04-28 23:43:05	0|instagibbs|achow101, good, go for it
305 2016-04-28 23:43:11	0|instagibbs|wanted to make sure *someone* was doing it
306 2016-04-28 23:43:19	0|instagibbs|I can review after the fact
307 2016-04-28 23:43:34	0|achow101|which bit is it?
308 2016-04-28 23:44:16	0|instagibbs|not sure, I'd find out, but have family stuff to do
309 2016-04-28 23:44:24	0|instagibbs|I think the service hex is "d"
310 2016-04-28 23:44:38	0|instagibbs|bbl if you still havent figured it out
311 2016-04-28 23:46:03	0|achow101|found it
312 2016-04-28 23:53:47	0|achow101|done https://github.com/bitcoin/bips/pull/380