1 2015-11-05 00:44:12 <dcousens> !
  2 2015-11-05 00:44:19 <dcousens> ignore
  3 2015-11-05 04:10:09 <dcousens> when I run with -txindex,  it still shows 'TxIndex disabled', unless I put it in my bitcoin.conf
  4 2015-11-05 04:10:23 <dcousens> But I'm pretty sure it *is* actually enabled
  5 2015-11-05 04:10:46 <dcousens> Is that just it printing what it loads from bitcoin.conf before it gets to the CLI options?
  6 2015-11-05 04:13:57 <dcousens> nvm, it only displays that on the first init, after that it shows as enabled
  7 2015-11-05 09:56:28 <wumpus> dcousens: misreporting it on first start is still a (low prio) bug
  8 2015-11-05 12:01:47 <andytoshi> can there be an option in core to stop representing decimals as json floats in rpc?
  9 2015-11-05 12:17:11 <benjyz1> hi. I have a simple problem. I want to find the outputs of a given address
 10 2015-11-05 12:17:20 <benjyz1> like so: blockchain.info/unspent?active=1KFHE7w8BhaENAswwryaoccDb6qcT6DbYY&format=html
 11 2015-11-05 12:17:39 <benjyz1> bitcoin api does not offer it. bitcoinJ does not offer it.. AFAIK
 12 2015-11-05 12:20:00 <jonasschnelli> andytoshi: Do you would prefer a string for monetary values? Or what is the issue your are facing? Scientific notation (like 1e-8, etc.)?
 13 2015-11-05 12:20:19 <jonasschnelli> benjyz1: bitcoind and bitcoinj do not provide an address index
 14 2015-11-05 12:20:40 <jonasschnelli> benjyz1: it's very expensive to allow querying every address.
 15 2015-11-05 12:20:59 <jonasschnelli> If you just wan't to focus serval addresses, use bitcoind's/bitcoin-qt's "importaddress" RPC call.
 16 2015-11-05 12:21:23 <andytoshi> jonasschnelli: the issue i'm facing is a json parser that reads numbers into a fixed-width floating type (which i'm aware is inconsistent with json's "agnostic about numbers" attitude but it is what it is)
 17 2015-11-05 12:21:25 <andytoshi> strings would be fine
 18 2015-11-05 12:21:37 <andytoshi> satoshis would be better
 19 2015-11-05 12:21:50 <jonasschnelli> this would be a heave API change
 20 2015-11-05 12:21:54 <jonasschnelli> heavy
 21 2015-11-05 12:22:51 <andytoshi> i'm aware .. but i could probably find complaints about the current format from 5 years ago
 22 2015-11-05 12:22:52 <jonasschnelli> andytoshi: i think the current float (actually, in json there is no float, its a "Number" which is specified as double)
 23 2015-11-05 12:23:00 <jonasschnelli> ... is okay for most cases
 24 2015-11-05 12:23:10 <wumpus> note that bitcoin core doesn't parse it as float either
 25 2015-11-05 12:23:28 <andytoshi> jonasschnelli: parsing as a float is definitely not right, i will definitely misread numbers
 26 2015-11-05 12:23:35 <jonasschnelli> but i agree satoshis would be better.
 27 2015-11-05 12:23:44 <andytoshi> as wumpus says, bitcoin core has its own json parser with a decimal type
 28 2015-11-05 12:25:43 <benjyz1> thx. so is there basically some kind of open explorer which integrates well with bitcoinJ e.g.?
 29 2015-11-05 12:25:57 <benjyz1> I'm using python-bitcoin
 30 2015-11-05 12:26:03 <wumpus> see the  function ParseFixedPoint - it's not rocket science, but also entirely triviial: https://github.com/bitcoin/bitcoin/blob/master/src/utilstrencodings.cpp#L573
 31 2015-11-05 12:26:16 <jtimon> cfields: I've been thinking about having a consensus module with what's currently in libconsensus separated from util, common, etc. Does that makes sense to you?
 32 2015-11-05 12:26:36 <wumpus> nah, I doubt we should change the API that much at this point, too much relies on the current state of things
 33 2015-11-05 12:26:49 <jonasschnelli> right,... agreed
 34 2015-11-05 12:26:54 <wumpus> I've tried to add an option to accept satoshis, even have a pull for it somewhere, but it got nowhere
 35 2015-11-05 12:27:02 <andytoshi> wumpus: it's not entirely trivial for me to fork a json parser and add a decimal type, which is what i'm having to do
 36 2015-11-05 12:27:02 <wumpus> no one cared deeply enough to change it, it's not worth persuing
 37 2015-11-05 12:27:05 <jonasschnelli> And it works... one might need to fiddle with the json parser
 38 2015-11-05 12:27:16 <andytoshi> ugh, i've been complaining about this for years
 39 2015-11-05 12:27:34 <jtimon> cfields: there are 2 .h that are used in libconsensus whose corresponding .cpp are not (amount.h and script_error.h due to CFeeRate and a toString respectively)
 40 2015-11-05 12:27:36 <jonasschnelli> andytoshi: you could change your personal bitcoin-core fork to support satoshis for the methods your using
 41 2015-11-05 12:28:06 <andytoshi> jonasschnelli: this is true, i suppose
 42 2015-11-05 12:28:10 <wumpus> andytoshi: it's easy enough to do btw: just change the functions ValueFromAmount and AmountFromValue in rpcserver.cpp, that's all
 43 2015-11-05 12:28:22 <andytoshi> yeah, i see, that's not too much work to maintain
 44 2015-11-05 12:28:23 <jonasschnelli> right,.. it's a 5min thing.
 45 2015-11-05 12:28:25 <wumpus> all conversion from JSON values to  satoshi amounts is centralized there
 46 2015-11-05 12:28:39 <wumpus> (and vice versa)
 47 2015-11-05 12:28:53 <jonasschnelli> you could even add a startup argument and it might allows so to sneak into master
 48 2015-11-05 12:29:02 <wumpus> that's what I tried
 49 2015-11-05 12:29:32 <jonasschnelli> wumpus: hah. Didn't knew that. Closes PR?
 50 2015-11-05 12:29:36 <jonasschnelli> Closed
 51 2015-11-05 12:29:40 <wumpus> after extensive shedpainting i even ended up with four settings: satoshis as number, satoshis as string, eecimal as number, decimal as string
 52 2015-11-05 12:29:49 <jtimon> cfields: that way the consensus package doesn't depend on the util package, for example, and if someone includes say util.h in script/script.cpp, the build would fail at linking time
 53 2015-11-05 12:29:58 <wumpus> believe me, its not worth persuing these kind of things, they're too ingrained
 54 2015-11-05 12:30:30 <wumpus> the interface is what it is and you'll have to design things around it (so many people already did, somewhat unfortunately)
 55 2015-11-05 12:31:31 <andytoshi> wumpus: ok, thanks for your experience
 56 2015-11-05 12:31:34 <andytoshi> i will avoid it :)
 57 2015-11-05 12:32:09 <moveonin> Hello guys, I currently operate about 40-50 full nodes at any given time with the number growing constantly. I ran into an issue recently though which will most likely lead to shutting down of most of them unless I figure it out
 58 2015-11-05 12:32:18 <jtimon> jonasschnelli: andytoshi: ack on amount_satoshis but is work and as wumpus says nobody seems interested in doing it
 59 2015-11-05 12:32:19 <jonasschnelli> andytoshi : heres the PR if you don't want to do the typing: https://github.com/bitcoin/bitcoin/pull/3759
 60 2015-11-05 12:32:19 <moveonin> I need to severely reduce the memory usage
 61 2015-11-05 12:32:55 <jonasschnelli> moveonin: what version are you running?
 62 2015-11-05 12:33:07 <andytoshi> thanks
 63 2015-11-05 12:33:20 <wumpus> andytoshi: jonasschnelli: mind that it's for a previous JSON implemetation and older string parsing functions, so nowadays it would be slightly different
 64 2015-11-05 12:33:26 <moveonin> 0.95 at this moment however I am also testing out a build with 0.11 and the issue seems to be present as well
 65 2015-11-05 12:33:41 <jonasschnelli> wumpus: good point, .. so andytoshi needs to do the typing. :)
 66 2015-11-05 12:33:49 <andytoshi> wumpus: well, json spec more-or-less says that it's my parser's fault
 67 2015-11-05 12:34:03 <andytoshi> but the people maintaining my parser are getting antsy at me about allocating for numbers
 68 2015-11-05 12:34:03 <moveonin> The memory just grows constantly at some point filling up the ram and jumping into swap while at the same time crashing my other apps due to excesive memory usage
 69 2015-11-05 12:34:09 <jonasschnelli> moveonin: the current master includes a mempool limiting patch... 0.12 should make things better (aim for a release in decemnber)
 70 2015-11-05 12:34:13 <moveonin> I have 4GB of ram
 71 2015-11-05 12:34:30 <jonasschnelli> OS?
 72 2015-11-05 12:34:32 <wumpus> moveonin: have you tried changing the minrelayfee?
 73 2015-11-05 12:35:07 <moveonin> Yes, that seems to have improved it a bit as well as dbcache maxconnections all the stuff in laawnj's gist. Any other ideas until the 0.12 release?
 74 2015-11-05 12:35:10 <wumpus> moveonin: see also this: https://gist.github.com/laanwj/efe29c7661ce9b6620a7
 75 2015-11-05 12:35:19 <moveonin> Already done all those
 76 2015-11-05 12:36:08 <wumpus> moveonin: you may be seeing this: https://github.com/bitcoin/bitcoin/issues/6876
 77 2015-11-05 12:36:11 <moveonin> Currently sitting at 1265M but still seems to be growing, I'll wait some more I guess to see if it ends up filling it all again
 78 2015-11-05 12:36:25 <wumpus> moveonin: including export  MALLOC_ARENA_MAX=1? that one is new
 79 2015-11-05 12:37:13 <nkuttler> so wrt to CLTV, should i do anything with my testnet faucet to ensure the recipients will be on the main chain?
 80 2015-11-05 12:38:04 <moveonin> Thanks wumpus I'll check that also
 81 2015-11-05 12:38:19 <moveonin> I was actually a bit reluctant for that one as I have other compiled programs on my system
 82 2015-11-05 12:38:32 <wumpus> only do it before you start bitcoind, e.g. in a script
 83 2015-11-05 12:38:39 <moveonin> scared of negatively affecting those but I guess I'll have to test it
 84 2015-11-05 12:38:46 <moveonin> Oh, it resets on system reboot?
 85 2015-11-05 12:38:56 <wumpus> no, it only affects the current shell/environment
 86 2015-11-05 12:39:24 <wumpus> just make a script bitcoin.sh that does tha texport line and calls bitcoind
 87 2015-11-05 12:39:32 <wumpus> won't affect any other programs
 88 2015-11-05 12:39:41 <moveonin> ok so I can actually modify my bitcoind start command to something more like export MALLOC_ARENA_MAX=1 && bitcoind?
 89 2015-11-05 12:40:02 <wumpus> 'MALLOC_ARENA_MAX=1 bitcoind' should already work
 90 2015-11-05 12:40:17 <moveonin> Thanks, I will give it a try
 91 2015-11-05 12:40:52 <wumpus> though it will reduce other program's memory use too, if they use threads
 92 2015-11-05 12:41:04 <wumpus> *if* you use it glboally (but I wouldn't recommend it either)
 93 2015-11-05 13:02:58 <jtimon> nkuttler: upgrade to support CLTV yourself ?
 94 2015-11-05 13:03:42 <jtimon> I mean, that won't ensure anything about your recipients, but it will ensure you are on the main chain
 95 2015-11-05 13:06:28 <nkuttler> jtimon: i guess that makes sense
 96 2015-11-05 17:26:40 <benjyz1> hello. I'm interested in payment channels and am studying bitcoinJ
 97 2015-11-05 17:27:17 <benjyz1> have channels been used in practise yet?
 98 2015-11-05 17:48:18 <zmanian_> benjyz: unidirectional payment channels are widely supported in Bitcoin ecosystem. See projects like Streamium for user experiences built on top of the technology
 99 2015-11-05 18:31:28 <instagibbs> I assume the purpose of mapMasterKeys is to somehow have multiple passphrases unlock the wallet? Anyone know the intention for it? https://github.com/bitcoin/bitcoin/blob/master/src/wallet/wallet.cpp#L524
100 2015-11-05 18:37:14 <gmaxwell> instagibbs: bluematt question mostly; but my belief is that the format would support e.g. the concatination of multiple encrypted wallets, that had different keys. From a UI perspective this isn't supported, however.  Also, bitcoin-core specific questions in #bitcoin-core-dev
101 2015-11-05 18:37:46 <instagibbs> gotcha. Found the commit in question
102 2015-11-05 18:47:49 <gmaxwell> davec: Your plans for a CLTV enabled release soon, do yo ualso have BIP113 / MedianTimePast -- it's a mempool only policy, no strict need for it, but I'd like to see it go out in the next wave of soft-forks so ideally it should be otherwise inhibited first.
103 2015-11-05 18:50:31 <BlueMatt> instagibbs: naa, you were right, it was to have multiple master keys
104 2015-11-05 18:50:51 <BlueMatt> instagibbs: that half was never implemented, obviously, however
105 2015-11-05 19:01:01 <sipa> meeting?
106 2015-11-05 19:01:40 <wumpus> #startmeeting
107 2015-11-05 19:01:41 <lightningbot> Meeting started Thu Nov  5 19:01:40 2015 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
108 2015-11-05 19:01:41 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
109 2015-11-05 19:01:58 <wumpus> any topics that need to be discussed?
110 2015-11-05 19:02:13 <jonasschnelli> Topics?
111 2015-11-05 19:02:33 <sipa> suggested topic: sigcache performance (i've been doing benchmarks)
112 2015-11-05 19:02:48 <sipa> suggested topic: softfork
113 2015-11-05 19:02:55 <wumpus> yes, makes sense
114 2015-11-05 19:03:00 <gmaxwell> suggested topic: 0.11.2 / 0.10.4 releases.
115 2015-11-05 19:03:15 <wumpus> ok, first sigcache performance
116 2015-11-05 19:03:23 <wumpus> #topic Sigcache performance
117 2015-11-05 19:03:29 <gmaxwell> "Ouch"
118 2015-11-05 19:03:51 <sipa> so, what i did was benchmark the hitrate of the sigcache for various sigcache sizes
119 2015-11-05 19:04:01 <wumpus> on a reindex?
120 2015-11-05 19:04:05 <sipa> no, live
121 2015-11-05 19:04:19 <gmaxwell> As in, when a block comes in, what is the sigcache hitrate for that block?
122 2015-11-05 19:04:26 <wumpus> somewhat offtopic: is there a good way to reproduce live usage deterministically?
123 2015-11-05 19:04:31 <sipa> obly counting the block ones, not mempool ones
124 2015-11-05 19:04:48 <sipa> wumpus: morcos and suhas have a simulator to replay recorded data iirc
125 2015-11-05 19:04:52 <wumpus> e.g. has anyone implemented storing P2P traffic, replay?
126 2015-11-05 19:04:57 <wumpus> ok
127 2015-11-05 19:05:18 <sipa> this is on master, with mempool limiting
128 2015-11-05 19:05:40 <sipa> and with the patch that deletes sigcache entries when they are seen in a block
129 2015-11-05 19:05:49 <gmaxwell> master + the sigcache efficiency improvement + the delete on hit, to be specific.
130 2015-11-05 19:06:05 <sipa> my sigcache was remarkably stable for days with a max of 68 MiB that way
131 2015-11-05 19:06:17 <sipa> resulting in a 15% miss rate
132 2015-11-05 19:06:26 <sipa> wait, 3%
133 2015-11-05 19:06:51 <wumpus> that's useful, so we can now compare the different pulls by perf numbers?
134 2015-11-05 19:07:17 <sipa> though some blocks have extremely high miss rates (over 60%)
135 2015-11-05 19:07:22 <sipa> while others have 0.0000%
136 2015-11-05 19:07:41 <sipa> which indicates that the miners are running different policies
137 2015-11-05 19:08:00 <jgarzik> meta - did the meeting get moved -1 hour ?
138 2015-11-05 19:08:12 <gmaxwell> jgarzik: your time did, US daylight savings time.
139 2015-11-05 19:08:19 <Luke-Jr> ^
140 2015-11-05 19:08:20 <wumpus> no, DST changed, meeting is in UTC
141 2015-11-05 19:08:25 <sipa> meeting is 7pm iceland time :)
142 2015-11-05 19:08:29 <wumpus> yep
143 2015-11-05 19:08:54 <sipa> so, then gmaxwell suggested *always* running script verification for mempool txn
144 2015-11-05 19:09:00 <sipa> even for policy rejected ones
145 2015-11-05 19:09:02 <jgarzik> ah UTC, good
146 2015-11-05 19:09:11 <wumpus> for the 60% miss rate blocks - any idea where the transactions come from? maybe the miners are taking them from their own pushtx interface and not from the network at all
147 2015-11-05 19:09:32 <sipa> which can be justified because fetching the inputs from utxo is already a significant portion of the work anyway
148 2015-11-05 19:09:36 <gmaxwell> The observation with the stable size is that the size was stable within a very small band, perhaps a few hundred K. There was a guess that most of that 68MB was cruft from before the mempool limiting kicked in that was never being cleared. Though that isn't confirmed. It seems likely.
149 2015-11-05 19:09:54 <sipa> the result is now that even a 300 MiB only gets down to 15% miss rate
150 2015-11-05 19:09:54 <wumpus> heh
151 2015-11-05 19:09:58 <gmaxwell> "significant portion of the work" especially with libsecp256k1.
152 2015-11-05 19:10:21 <sipa> so there is just too much crap being relayed to keep it in any reasonably sized cache
153 2015-11-05 19:10:38 <wumpus> that's my experience as well
154 2015-11-05 19:10:40 <gmaxwell> so clearly just verifying rejects and treating them the same is not a good call. :) I'd like to try changing the cache to be a map instead of a set to allow smarter expiration.
155 2015-11-05 19:11:13 <sipa> another observation is that (with libsecp) the time to not verify is equivalent to around a 25% miss rate
156 2015-11-05 19:11:39 <sipa> or in other words, 1/5th of the work is not script validation
157 2015-11-05 19:11:51 <gmaxwell> I have a specific concern here in that (1) there are some dos attacks if we do not verify rejected transactions, (2) not checking rejected transactions at all _increases_ your misrate if you set a policy which is more restrictive than the typical network, which might result in some race to the bottom.
158 2015-11-05 19:11:51 <morcos> sipa: over what time frame did you wait for the miss rate to stabilize
159 2015-11-05 19:12:01 <sipa> morcos: a day
160 2015-11-05 19:12:13 <morcos> obviously as the mempool is going from 0 -> 300MB you get tons of txs in there that might not be mined for a long time
161 2015-11-05 19:12:14 <gmaxwell> sipa: I assume its still running now two days later?
162 2015-11-05 19:12:19 <sipa> yes
163 2015-11-05 19:12:21 <morcos> over time though those should stay near the bottom
164 2015-11-05 19:12:29 <wumpus> topic for later: secp256k1 verification readyness
165 2015-11-05 19:12:31 <morcos> i bet it might do better over a longer period of time
166 2015-11-05 19:12:46 <morcos> i'd also like to discuss other connect block latency improvements
167 2015-11-05 19:12:54 <morcos> so we have some goal of what might be reasonable for 0.12
168 2015-11-05 19:13:24 <sipa> anyway, i need to try some other strategy
169 2015-11-05 19:13:35 <gmaxwell> morcos: right now a problem is that the eviction doesn't prefer to kick out old things that are never getting mined. So if crap is has a 'high' ratio to useful things, the cache must be huge to work well.
170 2015-11-05 19:14:03 <sipa> but it seems reasonable that priming the sigcache with transactions that we do not accept into mempool, but who were close, may be worth it
171 2015-11-05 19:14:23 <sipa> however, doing that fot every single transaction is the wrong approach
172 2015-11-05 19:14:49 <wumpus> I think we should be careful not to merge risky performance imporovements last-minute for 0.12 - we will regret those if there turns out to be bugs. May be better to merge them after the release branch, dec 1
173 2015-11-05 19:15:11 <morcos> wumpus: i think most of these things are not risky, and the performance improvements are HUGE
174 2015-11-05 19:15:12 <jgarzik> nod - prioritize getting 0.12 out the door and not blocking it
175 2015-11-05 19:15:15 <sipa> well i think the PR i have out for sigcache changes is a net win
176 2015-11-05 19:15:24 <jgarzik> 0.12 -already- has a lot of net win
177 2015-11-05 19:15:52 <gmaxwell> I think the existing PR is an obvious win. Also, without sigcache improvements I'm concerned that mempool limiting may have bad effects on the network.
178 2015-11-05 19:16:10 <wumpus> morcos: I'm really risk-averse before releases, master (as in git now) is pretty much stable and would make a good release, I really don't want to regret merging anything now
179 2015-11-05 19:16:20 <gmaxwell> Because right now hitting high miss rates is not very acceptable... but it's much less bad with libsecp256k1 at least.
180 2015-11-05 19:16:23 <morcos> i'd strongly like to include secp256k1, the changes to skip looking up your own txs id (BIP30 and modifyNewCoins, and the sigcache improvements
181 2015-11-05 19:16:32 <morcos> the hot cache stuff is still far from proven
182 2015-11-05 19:16:38 <sipa> morcos: agree
183 2015-11-05 19:16:59 <wumpus> yes I still like to include secp256k1 for 0.12 too (but that's not the topic now :-)
184 2015-11-05 19:17:04 <gmaxwell> with openssl it only takes a miss rate of a couple percent to totally dominate block verification time.
185 2015-11-05 19:17:05 <morcos> also the CreateNewBlock rewrite is only for miners, but it improves total time from about 3 seconds down to 150ms now on a 300MB mempool
186 2015-11-05 19:17:08 <morcos> we can't leave that out
187 2015-11-05 19:17:22 <morcos> well these things all go together
188 2015-11-05 19:17:33 <morcos> no reason putting in secondary performance gains if you're missing the bigone
189 2015-11-05 19:17:36 <morcos> :)
190 2015-11-05 19:17:43 <jgarzik> I love the CNB change but that seems lower priority than making 0.12 rock solid otherwise - miners can patch up
191 2015-11-05 19:17:53 <gmaxwell> in any case, I think we've covered sigcache for now.  Current work is a big improvement, but more work is needed.
192 2015-11-05 19:18:05 <sipa> jgarzik: miners won't patch up, and it is in everyone's interest that miner latency is low
193 2015-11-05 19:18:12 <sipa> not just their own
194 2015-11-05 19:18:18 <sipa> ok
195 2015-11-05 19:18:20 <sipa> next topic
196 2015-11-05 19:18:22 <sipa> ?
197 2015-11-05 19:18:27 <wumpus> #topic softfork releases
198 2015-11-05 19:18:30 <gmaxwell> jgarzik: I don't really agree there.  Our expirence in production has not been that.  Additionally, to the extent they do it creates inequality.. and this slowness has also contributed to verification free mining.
199 2015-11-05 19:18:51 <morcos> wumpus lets stay on performance goals for 0.12 for a second
200 2015-11-05 19:19:03 <morcos> since it ties closely with sigcache which we just covered
201 2015-11-05 19:19:12 <wumpus> I'd really advise against merging last-mintue performance improvements for 0.12
202 2015-11-05 19:19:34 <morcos> is it last minute if we merge it this month?
203 2015-11-05 19:19:39 <gmaxwell> ^
204 2015-11-05 19:19:41 <wumpus> sort of
205 2015-11-05 19:20:07 <gmaxwell> Put another way, if we'd already branched for 0.12 I'd be proposing backporting this work.
206 2015-11-05 19:20:07 <sipa> wumpus: ok, do you mind setting a deadline for performance improvements in master?
207 2015-11-05 19:20:12 <wumpus> but gmaxwell/sipa feel free to merge things if you're absolutely sure about them, I'm not the only one with commit rights
208 2015-11-05 19:20:28 <gmaxwell> OK
209 2015-11-05 19:20:44 <morcos> i'm leaving to go out of town in 2 weeks for a week
210 2015-11-05 19:20:52 <morcos> lets set the deadline for 2 weeks from tomorrow
211 2015-11-05 19:21:01 <wumpus> I'm really careful and would be pissed if we needed e.g. an urgent minor release to fix up 0.12 because something ill advices went in
212 2015-11-05 19:21:07 <morcos> if we don't all agree they're ready we wait
213 2015-11-05 19:21:14 <sipa> wumpus: fair enough
214 2015-11-05 19:21:16 <wumpus> but the deadline is dec 1
215 2015-11-05 19:21:27 <wumpus> that's the feature freeze - 0.12 branch
216 2015-11-05 19:21:31 <sipa> ok
217 2015-11-05 19:21:36 <gmaxwell> wumpus: I will send you flowers if we screw up. :P  We do have a pretty conservative release schedule, in my view. :)
218 2015-11-05 19:21:44 <morcos> ok, well guys, please help me reviewing those pulls then
219 2015-11-05 19:21:52 <sipa> morcos: will do!
220 2015-11-05 19:21:56 <gmaxwell> Great. Will do.
221 2015-11-05 19:21:56 <morcos> most importantly to make CreateNewBlock work properly
222 2015-11-05 19:22:02 <morcos> we have to make a decision about priority
223 2015-11-05 19:22:06 <wumpus> gmaxwell: agree, but better be slow than dead :)
224 2015-11-05 19:22:08 <sipa> yes, i believe CNB is important
225 2015-11-05 19:22:14 <morcos> it can't be fast to have priority, unless we fix it to be dynamic or change its definition
226 2015-11-05 19:22:27 <sipa> wumpus: when do you libsecp in at the latest?
227 2015-11-05 19:22:29 <morcos> i'm ambivalent on that choice
228 2015-11-05 19:22:40 <wumpus> sipa: same
229 2015-11-05 19:22:48 <sipa> jgarzik: agree
230 2015-11-05 19:22:53 <jgarzik> libsecp256k1 - asap!
231 2015-11-05 19:22:53 <wumpus> wel'll cetainly not delay the relaese on that
232 2015-11-05 19:22:54 <phantomcircuit> I don't see any reason for create new block to consider property
233 2015-11-05 19:22:55 <gmaxwell> Can we go to libsecp256k1 for a moment, this will be fast.
234 2015-11-05 19:23:09 <morcos> yes
235 2015-11-05 19:23:12 <jgarzik> libsecp256k1 yesterday :)
236 2015-11-05 19:23:13 <phantomcircuit> Priority
237 2015-11-05 19:23:17 <wumpus> #topic libsecp256k1 now
238 2015-11-05 19:23:24 <gmaxwell> I think we should merge support right now, like today.  We can update it incrementally, but we should get more than just our own nodes running this way.
239 2015-11-05 19:23:29 <wumpus> agree
240 2015-11-05 19:23:33 <sipa> agree
241 2015-11-05 19:23:36 <wumpus> everyone wants that basically
242 2015-11-05 19:23:38 <gmaxwell> Sipa has current patches for the update. PR them please.
243 2015-11-05 19:23:39 <jgarzik> yes
244 2015-11-05 19:23:47 <sipa> i realized it's unfair that i've been running them for months
245 2015-11-05 19:23:55 <Luke-Jr> sgtm
246 2015-11-05 19:24:00 <sipa> will PR
247 2015-11-05 19:24:09 <morcos> fantastic, most productive IRC meeting ever!
248 2015-11-05 19:24:14 <gmaxwell> Our goal on libsecp256k1 has been to have a release of the library ahead of 0.12 but that doesn't have anything to do with when we merge support for it.
249 2015-11-05 19:24:26 <gmaxwell> okay. good. tada.
250 2015-11-05 19:24:29 <Luke-Jr> suggested topic: hardfork
251 2015-11-05 19:24:31 <jgarzik> morcos, was a decision made on priority?
252 2015-11-05 19:24:34 <wumpus> good
253 2015-11-05 19:24:39 <morcos> jgarzik: not yet
254 2015-11-05 19:24:45 <wumpus> #topic transaction priority
255 2015-11-05 19:25:19 <sipa> i feel that we should get rid of the current priority+separate-processing, and replace it with a functioncthat modifies fee or size of transactions
256 2015-11-05 19:25:20 <gmaxwell> Morcos suggested a lossy way of calcualting priority. It's a bit lame but I think somewhat better than dropping it completely.
257 2015-11-05 19:25:25 <morcos> ok, i think the simplest answer here is people decide #6357 is efficient enough and safe
258 2015-11-05 19:25:37 <sipa> will check 6357 then
259 2015-11-05 19:25:41 <morcos> that doesn't change the definition, and so we avoid the political debate on a tight timeline
260 2015-11-05 19:25:41 <wumpus> #action check #6357 is efficient enough and safe
261 2015-11-05 19:25:47 <morcos> however i can't say i've tested it too much
262 2015-11-05 19:25:49 <sipa> sounds good
263 2015-11-05 19:26:03 <morcos> i think take a look, if its no good we revert to a different definion
264 2015-11-05 19:26:09 <morcos> but gmaxwell, the one i proposed is flawed
265 2015-11-05 19:26:14 <morcos> it fails in the event of a reorg
266 2015-11-05 19:26:27 <sipa> what failure mode?
267 2015-11-05 19:26:46 <morcos> my suggestion was to only consider the in-chain input value for any further aging of the tx's priority
268 2015-11-05 19:26:57 <morcos> but in a reorg, some in chain value might be no longer in chain
269 2015-11-05 19:27:01 <morcos> and you could be overstating its priority
270 2015-11-05 19:27:07 <sipa> "meh"
271 2015-11-05 19:27:09 <morcos> so maybe thats fine
272 2015-11-05 19:27:23 <jgarzik> meh
273 2015-11-05 19:27:28 <gmaxwell> I think thats probably okay. It does not need to be precise.
274 2015-11-05 19:27:38 <gmaxwell> (though it was nice to think it could only understate)
275 2015-11-05 19:27:39 <Luke-Jr> while it sounds fine for a default policy, the old policy should remain possible; hard-coding policy into mempool structures is a regression.
276 2015-11-05 19:27:44 <morcos> ok, well thats basically a subset of 6357 then
277 2015-11-05 19:27:46 <wumpus> as long as it's not easy to cheat
278 2015-11-05 19:27:55 <sipa> Luke-Jr: respectfully disagree
279 2015-11-05 19:27:59 <morcos> the scarier part of 6357 is properly updating that amount on block confirmations and reorgs
280 2015-11-05 19:28:00 <gmaxwell> Suggested topic: sigops flooding attack.
281 2015-11-05 19:28:01 <jgarzik> priority is secondary anyway, yes?
282 2015-11-05 19:28:02 <phantomcircuit> Priority changes mostly slowly why not just cache the value and re calculate in the background
283 2015-11-05 19:28:29 <sipa> next topic?
284 2015-11-05 19:28:34 <morcos> phantomcircuit: its important to make the recalculation not require looking up inputs again
285 2015-11-05 19:28:36 <wumpus> #topic sigops flooding attack
286 2015-11-05 19:29:07 <gmaxwell> So, there is an active attack on the network producing transactions with very high sigops counts and medium/high feerates causing miners to mine blocks with just a couple transactions.
287 2015-11-05 19:29:12 <phantomcircuit> Right
288 2015-11-05 19:29:57 <phantomcircuit> Sounds like they're not profit maximizing...
289 2015-11-05 19:30:02 <wumpus> what would be the proposed mitigation? a change to default mining policy?
290 2015-11-05 19:30:03 <morcos> gmaxwell: your proposal is to just change the mining code to be a bit smarter about that?
291 2015-11-05 19:30:15 <gmaxwell> I have (going back eons) suggested a simple hurestic where size for feerate is replaced with max(size, sigops*blocksizelimit/feeratelimit); for most transactions this does nothing, but for sigops boms it inflates their cost. It's simular to the post office charging for the largest dimension.
292 2015-11-05 19:31:00 <wumpus> sounds sensible
293 2015-11-05 19:31:04 <gmaxwell> it's a suggestion to scale sigops to it's share of the limit relative to the blocksize limit. e.g. a 10k sigops transaction is 500k of 'size'.
294 2015-11-05 19:31:05 <jgarzik> is there a simple relay filter that doesn't impact normal users?
295 2015-11-05 19:31:24 <sipa> gmaxwell: units mismatch
296 2015-11-05 19:31:26 <morcos> gmaxwell: this would affect everything , including min relay fee?
297 2015-11-05 19:31:34 <gmaxwell> jgarzik: style of the attack transactions has been different.
298 2015-11-05 19:31:53 <Luke-Jr> I also have a bytes-per-sigop limit that filters absolutely, which seems like a better solution for this case, since there is no legit use of such things past a certain ratio (perhaps both gmaxwell's and this make the most sense)
299 2015-11-05 19:32:09 <gmaxwell> er. max(size, sigops*blocksizelimit/sigopslimit)  (sorry reading and typing at once.
300 2015-11-05 19:32:36 <morcos> gmaxwell: i think it would be an easy change to make the mining code sort by that
301 2015-11-05 19:32:42 <wumpus> great
302 2015-11-05 19:32:52 <morcos> it would be somewhat more invasive to try to plug that into everything that looks at feerate
303 2015-11-05 19:32:54 <gmaxwell> Luke-Jr: I think such a threshold must be uselessly high due to inaccurate sigops accounting.
304 2015-11-05 19:33:18 <gmaxwell> morcos: doesn't the new mining code depend on the mempool sort?
305 2015-11-05 19:33:21 <Luke-Jr> gmaxwell: I don't understand what you mean by that.
306 2015-11-05 19:33:33 <morcos> its a mempool sort just for mining (another index)
307 2015-11-05 19:33:36 <sipa> gmaxwell: separate index
308 2015-11-05 19:33:37 <morcos> not the same that is used for eviction
309 2015-11-05 19:33:40 <gmaxwell> Luke-Jr: txouts checksigs (p2pkh) are counted as sigops.
310 2015-11-05 19:33:49 <sipa> so it can use different scoring
311 2015-11-05 19:34:14 <gmaxwell> OKAY, well I think using it for just mining is totally fine.
312 2015-11-05 19:34:19 <sipa> ok
313 2015-11-05 19:34:23 <sdaftuar> is this attack large enough that the mempool eviction feerate index needs to be reevaluated?
314 2015-11-05 19:34:27 <morcos> yeah, ok, at least for now
315 2015-11-05 19:34:28 <Luke-Jr> gmaxwell: ok? If that were an issue, this is just policy, and we could exclude them..
316 2015-11-05 19:34:29 <gmaxwell> as I said, for most transaction it will have little to no effect.
317 2015-11-05 19:34:29 <sdaftuar> ie can you fill up a mempool with this garbage?
318 2015-11-05 19:34:39 <phantomcircuit> Could also have a backfiring thread continuously spinning trying to build a block with more fees
319 2015-11-05 19:34:47 <phantomcircuit> Back ground*
320 2015-11-05 19:34:53 <gmaxwell> sdaftuar: the transactions are small in any case. but any time mining and mempool are misaligned then you do have backlog growth issues.
321 2015-11-05 19:35:13 <morcos> 72 hour eviction might be good enough to solve for that
322 2015-11-05 19:35:21 <morcos> oh, but hmm
323 2015-11-05 19:35:23 <gmaxwell> (also part of why I'd thought to just change it in all the places)
324 2015-11-05 19:35:34 <sdaftuar> well it'd be nice to know what fraction of the mempool is being taken up with this stuff
325 2015-11-05 19:36:18 <morcos> yeah worth thinking about attacks anyway, if their effective mining feerate is very low, but then there is no mempool limiting for them b/c their size only feerate is large, they can just fill up your mempool
326 2015-11-05 19:37:17 <wumpus> ~20 minutes to go for the meeting
327 2015-11-05 19:37:27 <gmaxwell> okay, perhaps some more analysis to be done here.
328 2015-11-05 19:37:31 <morcos> yep, agreed
329 2015-11-05 19:37:37 <morcos> topic suggestion chain limits
330 2015-11-05 19:37:42 <gmaxwell> I'm glad to hear that people are generally okay with this sort of direction.
331 2015-11-05 19:37:52 <wumpus> #topic chain limits
332 2015-11-05 19:38:00 <morcos> sdaftuar ran some analysis
333 2015-11-05 19:38:04 <sdaftuar> heh. i'm furiously trying to upload my data right now
334 2015-11-05 19:38:06 <morcos> lots of blocks have big chains
335 2015-11-05 19:38:24 <morcos> 40% of blocks have a chain > our proposed limits
336 2015-11-05 19:38:29 <sipa> do we have idea of what those chains are?
337 2015-11-05 19:38:43 <sipa> like, who creates them
338 2015-11-05 19:38:45 <jgarzik> what lengths are revealed in the data?
339 2015-11-05 19:38:48 <sipa> what kind of use case they look like
340 2015-11-05 19:38:57 <morcos> the one i looked at in detail seemed to be a service paying the fees on other txs
341 2015-11-05 19:39:17 <gmaxwell> really surprising to find this, since those transactions are highly malleability vulnerable.
342 2015-11-05 19:39:17 <morcos> it occurred to me that we might should contact some of the exchanges and wallet services
343 2015-11-05 19:39:21 <Luke-Jr> sipa: I think at least some iOS wallet gladly spends unconfirmed change
344 2015-11-05 19:39:30 <morcos> its possible that these long chains are delivered to miners out of band
345 2015-11-05 19:39:46 <morcos> if thats the case, they'd be unaffected by relay policy limits anyway
346 2015-11-05 19:39:52 <wumpus> right
347 2015-11-05 19:40:00 <gmaxwell> and by mallability (or less so at least)
348 2015-11-05 19:40:28 <morcos> the problem is we HAVE to do something
349 2015-11-05 19:40:35 <morcos> longer chains are a disaster waiting to happen
350 2015-11-05 19:40:50 <sipa> yes
351 2015-11-05 19:40:51 <morcos> one thing i noticed from sdaftuars data is that a small bump doesn't make the problem go away
352 2015-11-05 19:41:02 <morcos> at 50, 25% of blocks, at 100 15% of blocks
353 2015-11-05 19:41:11 <phantomcircuit> How long are the chains?
354 2015-11-05 19:41:11 <sipa> which indicates that it is a small percentage of *very* long chains
355 2015-11-05 19:41:21 <sipa> rather than an organic distribution of chain lengths
356 2015-11-05 19:41:27 <sipa> ?
357 2015-11-05 19:41:54 <morcos> about 4% of the txs in block would violate the limit
358 2015-11-05 19:42:09 <morcos> this makes sense given the 6% number for txs in the mempool i posted earlier
359 2015-11-05 19:42:32 <morcos> so yes, the vast majority of txs would not have an issue
360 2015-11-05 19:43:00 <morcos> when sdaftuar gets his data out there people can look at it and draw their own conclusion
361 2015-11-05 19:43:03 <morcos> s
362 2015-11-05 19:43:17 <morcos> should i or someone else reach out to some of the businesses directly and get their viewpoints
363 2015-11-05 19:43:23 <jouke> We create cpfp transactions when we reaceive bitcoins from an unspent chain.
364 2015-11-05 19:43:26 <jgarzik> At a higher level, trying to move forward, there is always going to be a small percentage outside the limit.  Communicate the limit that seems reasonable in a release note, push the change, gauge reaction.
365 2015-11-05 19:43:48 <morcos> i kind of like jgarzik's idea
366 2015-11-05 19:43:54 <morcos> merge now
367 2015-11-05 19:43:56 <wumpus> jouke: makes sense
368 2015-11-05 19:43:58 <gmaxwell> jouke: does this result in 40 deep unconfirmed chains.
369 2015-11-05 19:44:02 <morcos> and announce more clearly
370 2015-11-05 19:44:03 <jgarzik> perfection is unattainable
371 2015-11-05 19:44:07 <jouke> gmaxwell: no
372 2015-11-05 19:44:20 <morcos> but that sets the right tone, of look, this isn't just a preference, its something that really needs to be done
373 2015-11-05 19:44:22 <wumpus> merge - what pull?
374 2015-11-05 19:44:24 <jgarzik> "release early, release often" + "communicate early, communicate often"
375 2015-11-05 19:44:26 <gmaxwell> okay lets just see how that goes, announce and see what happens.
376 2015-11-05 19:44:29 <morcos> and if the sky falls in, we can rethink
377 2015-11-05 19:44:31 <sipa> i agreed
378 2015-11-05 19:44:39 <Luke-Jr> reminder: policy is not a developer decision; let miners deal with figuring out what is ideal
379 2015-11-05 19:44:47 <morcos> #6771
380 2015-11-05 19:44:53 <wumpus> #action merge #6771
381 2015-11-05 19:45:14 <jgarzik> Luke-Jr, absolutely - all the more reason to communicate early, let people reason through things on their own, based on their own situations
382 2015-11-05 19:45:26 <sipa> Luke-Jr: it's a command-line flag :)
383 2015-11-05 19:45:27 <gmaxwell> So we haven't talked about softfork releases / 0.11.2+0.10.4
384 2015-11-05 19:45:33 <morcos> should i email again the dev list then?
385 2015-11-05 19:45:43 <Luke-Jr> yeah, just saying, going overboard on defaults by contacting businesses etc is too much :P
386 2015-11-05 19:45:46 <wumpus> #topic softfork releases / 0.11.2+0.10.4
387 2015-11-05 19:45:51 <gmaxwell> Perhaps we merge and just announce the merge, if someone shows up with something convincing we can back it out.
388 2015-11-05 19:45:52 <jgarzik> morcos, can't hurt
389 2015-11-05 19:46:02 <jgarzik> gmaxwell, merge + list mail
390 2015-11-05 19:46:03 <morcos> ok, i will email post merge, next
391 2015-11-05 19:47:02 <gmaxwell> Okay, so are we waiting for any other commits for 0.11.2 to cut an RC there?
392 2015-11-05 19:47:03 <wumpus> imo: asap, #6948 is merged, will test #6948 on windows tomorrow to see if it gets rid of (most) corruption on crashes
393 2015-11-05 19:47:16 <gmaxwell> The things I was tracking was leveldb fixes, and MTP, and both are in.
394 2015-11-05 19:47:27 <Luke-Jr> gmaxwell: I have a PR with a bunch of fixes for 0.11.2
395 2015-11-05 19:47:32 <gmaxwell> If we RC we can get more windows testers, (almost universally they need binaries)
396 2015-11-05 19:47:37 <wumpus> eh one of them is the undo flush fix, don't know the number by head
397 2015-11-05 19:47:44 <phantomcircuit> gmaxwell, well... by back out do you mean massively increase the limit?
398 2015-11-05 19:47:48 <gmaxwell> ah undo flush isn't in okay.
399 2015-11-05 19:47:51 <wumpus> that one needs to go in too
400 2015-11-05 19:47:56 <wumpus> right.
401 2015-11-05 19:47:58 <Luke-Jr> https://github.com/bitcoin/bitcoin/pull/6825
402 2015-11-05 19:48:34 <wumpus> then roll out 0.11.2 and 0.10.4 tomorrow
403 2015-11-05 19:48:53 <Luke-Jr> wumpus: should I update this PR before then, or just merge what's there?
404 2015-11-05 19:49:10 <wumpus> Luke-Jr: sure
405 2015-11-05 19:49:14 <gmaxwell> We need to move fairly quickly on this, as there are miners on mainnet now running master who will begin CLTV voting (I haven't checked if any are in the chain, but there are public stratum servers returning v4 work).  Not _urgently_, mind you, as it still takes a lot of blocks to trigger, but we cannot delay much. :)
406 2015-11-05 19:49:30 <wumpus> hence ,tomorrow
407 2015-11-05 19:49:31 <gmaxwell> Tomrrow sounds good to me.
408 2015-11-05 19:49:36 <gmaxwell> (not just good, great).
409 2015-11-05 19:49:44 <Luke-Jr> sure = update first, or just merge what's there now?
410 2015-11-05 19:50:02 <wumpus> Luke-Jr: I'd suggest just leaving it at is, not make last minute changes, so people cna review it
411 2015-11-05 19:50:05 <Luke-Jr> k
412 2015-11-05 19:50:33 <gmaxwell> okay, sounds good, will review luke's patches.
413 2015-11-05 19:50:42 <Luke-Jr> ok, removed [WIP] tag from it to indicate final state
414 2015-11-05 19:50:51 <wumpus> #action review #6825 ASAP
415 2015-11-05 19:50:54 <gmaxwell> (oh also, testnet is CLTV locked already and constantly forking...)
416 2015-11-05 19:51:03 <Luke-Jr> I'll go do an equivalent branch for 0.10 with only the same commits
417 2015-11-05 19:52:08 <wumpus> ok, thanks
418 2015-11-05 19:52:21 <wumpus> I think that concludes this topic, anything else?
419 2015-11-05 19:52:53 <gmaxwell> Okay luke wanted to discuss 'hardfork', and I think this really meant scaling bitcoin things. The closing date for proposals for the workshop is the 9th, and several people have BIPs/proposals in flight (including myself). I dunno if there is anything more to discuss on that in this meeting.
420 2015-11-05 19:53:11 <wumpus> there's 10 minutes left - I don't think that's enough for 'hardfork' discussion
421 2015-11-05 19:53:23 <wumpus> *less than
422 2015-11-05 19:53:25 <morcos> i'd like cover briefly one thing regarding mempools and mining
423 2015-11-05 19:53:33 <wumpus> #topic mempools and mining
424 2015-11-05 19:53:35 <gmaxwell> Agreed.
425 2015-11-05 19:53:38 <jgarzik> +1 skip Scaling/hardfork discussion in this meeting
426 2015-11-05 19:53:42 <jgarzik> maybe after
427 2015-11-05 19:54:05 <morcos> when we did most of our analysis of limited mempools, we assumed a CPFP mining algo.  however that proved a bit ambitious for 0.12, and i opted fro just speeding up the existing algo
428 2015-11-05 19:54:26 <morcos> so that that means is we haven't really analyzed matt's pull (forget the number) in the context of the existing mining algorithm
429 2015-11-05 19:54:43 <morcos> its not clear that there isn't some abuse possible
430 2015-11-05 19:55:08 <gmaxwell> oh suggested topic: "Should we be working on getting the opt-in RBF for 0.12?"
431 2015-11-05 19:55:11 <morcos> i will try to spend some time thinking about this, but just wnated to flag it for other people as well.
432 2015-11-05 19:55:33 <wumpus> #action topic for next week: "Should we be working on getting the opt-in RBF for 0.12?"
433 2015-11-05 19:55:41 <gmaxwell> morcos: okay, important thing to determine is what form the abuse takes if so.. e.g. getting excess priority from it is probably not very concerning.
434 2015-11-05 19:56:23 <morcos> gmaxwell: yeah i think the concern is artificially boosting the relay, or DoS miners with computationaly complexity or free bandwidth relay
435 2015-11-05 19:56:33 <morcos> btw, +1 to RBF for 0.12
436 2015-11-05 19:57:02 <morcos> i know this is a lot of big stuff in the next month, but its just scratching the tip of the iceberg for all we have to do, so lets do it!
437 2015-11-05 19:57:37 <gmaxwell> That my view too, we can discuss more next week, but I'll take that as a tenitive as we should move towards that... see where things are next week.
438 2015-11-05 19:58:10 <btcdrak> +1 for RBF in 0.12
439 2015-11-05 19:58:19 <sdaftuar> for advancing the ball on RBF, is it time to get opinoins from people who were opposed to earlier versions?
440 2015-11-05 19:58:38 <btcdrak> sdaftuar: I think the optin already deal with that
441 2015-11-05 19:58:48 <jgarzik> I would be for full-bore RBF if we could rope in Coinbase and Bitpay
442 2015-11-05 19:58:48 <phantomcircuit> agreed
443 2015-11-05 19:58:56 <jgarzik> it's mainly a network-user-impact question, to me
444 2015-11-05 19:58:56 <jtimon> yep, ACK RBF (I didn't say anything but I would happily ack the removal of priority as well...)
445 2015-11-05 19:59:06 <wumpus> me too, I prefer full RBF, but any RBF would be a step forward
446 2015-11-05 19:59:12 <jgarzik> long term ACK RBF
447 2015-11-05 19:59:21 <gmaxwell> Opt-in had the "then don't use it" answer which I think is essential to make progress.
448 2015-11-05 19:59:21 <phantomcircuit> jgarzik, it's opt in only, doesn't effect anybody on the network today
449 2015-11-05 19:59:23 <morcos> is opt-in somehow worse than full
450 2015-11-05 19:59:28 <sdaftuar> morcos: no
451 2015-11-05 19:59:38 <wumpus> no, opt-in is not worse than full, some other proposals were
452 2015-11-05 19:59:42 <sdaftuar> i think we need to make clear what users who don't want to accept opt-in transactions need to do
453 2015-11-05 19:59:46 <btcdrak> gmaxwell: agreed. morcos: no
454 2015-11-05 19:59:51 <sdaftuar> so that no one is surprised/not ready
455 2015-11-05 19:59:55 <gmaxwell> We've been talking about this long term for years now but it's too easily politically attacked, where opt-in resolves that.
456 2015-11-05 19:59:55 <jgarzik> it is good to make progress towards RBF
457 2015-11-05 19:59:59 <gmaxwell> sdaftuar: sounds good.
458 2015-11-05 19:59:59 <jgarzik> poke users along
459 2015-11-05 20:00:01 <jgarzik> gently
460 2015-11-05 20:00:10 <wumpus> gmaxwell: agree
461 2015-11-05 20:00:13 <phantomcircuit> morcos, it simply means you have to opt into the transaction being replaceable (of course miners can replace whatever they want already but it makes the *default* be opt into replacement)
462 2015-11-05 20:00:17 <btcdrak> it's already apparent from the PR ACKs how much it is anticipated
463 2015-11-05 20:00:35 <morcos> yes, i understood, just trying to parse peoples support for Full RBF also means support for opt-in (full) RBF
464 2015-11-05 20:00:38 <jtimon> morcos: opt in is more complicated than full, just that
465 2015-11-05 20:00:55 <jgarzik> nod
466 2015-11-05 20:01:01 <wumpus> #meetingend
467 2015-11-05 20:01:03 <gmaxwell> morcos: yes, I think everyone who supports full rbf supports this; I believe I've never heard other wise (after some explination at least)
468 2015-11-05 20:01:05 <wumpus> #meetingstop
469 2015-11-05 20:01:07 <gmaxwell> Thanks all.
470 2015-11-05 20:01:14 <btcdrak> #exitmeeting
471 2015-11-05 20:01:22 <gmaxwell> #nomeetingnonono
472 2015-11-05 20:01:22 <mcelrath> Argh daylight savings time.
473 2015-11-05 20:01:25 <btcdrak> #meedingexit
474 2015-11-05 20:01:29 <wumpus> #endmeeting
475 2015-11-05 20:01:30 <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-dev/2015/bitcoin-dev.2015-11-05-19.01.log.html
476 2015-11-05 20:01:30 <lightningbot> Meeting ended Thu Nov  5 20:01:29 2015 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
477 2015-11-05 20:01:30 <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-dev/2015/bitcoin-dev.2015-11-05-19.01.html
478 2015-11-05 20:01:30 <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-dev/2015/bitcoin-dev.2015-11-05-19.01.txt
479 2015-11-05 20:01:34 <btcdrak> #rekt
480 2015-11-05 20:01:35 <wumpus> hah btcdrak
481 2015-11-05 20:01:36 <jonasschnelli> :9
482 2015-11-05 20:01:39 <sdaftuar> fyi i just posted a link to the data on in-block chains: https://www.dropbox.com/s/kkh0g4kl9qwt1cx/alldata2.gz?dl=0
483 2015-11-05 20:01:47 <sdaftuar> it's a big file
484 2015-11-05 20:01:58 <btcdrak> nice work sdaftuar
485 2015-11-05 20:02:12 <sdaftuar> but it lists for every tx in every block i looked at (roughly a year's worth) the number of in-block ancestors and descendants, and size with ancestors and size with decsendants
486 2015-11-05 20:02:52 <cfields> ...
487 2015-11-05 20:03:06 <cfields> i was finally on time for once, i guess dst screwed me?
488 2015-11-05 20:03:20 <btcdrak> cfield: me too, again
489 2015-11-05 20:03:25 <gmaxwell> cfields: don't feel bad, so matt was apparently sitting in front of me and I thought he was in the meeting, and he wasn't aware of it!
490 2015-11-05 20:03:36 <gmaxwell> (though he was the last one to speak in here before it started)
491 2015-11-05 20:03:50 <gmaxwell> cfields: yes, dst got you, US's turn this week, last week europe got the DST confusion.
492 2015-11-05 20:04:01 <cfields> heh
493 2015-11-05 20:04:11 <cfields> ok, will read backlog
494 2015-11-05 20:04:36 <morcos> cfields: improper use of google calendar
495 2015-11-05 20:05:12 <cfields> morcos: improper use of mental-reminder. calendar would be an upgrade.
496 2015-11-05 20:05:16 <cfields> in fact, doing that now
497 2015-11-05 20:05:18 <gmaxwell> phantomcircuit: with PT's patch, to get RBF behavior you must set nseq < max-1, which isn't a norm for wallets today.
498 2015-11-05 20:05:22 <sdaftuar> btw #6494 could use some reviewing love if we want to get headers announcements in for 0.12
499 2015-11-05 20:05:30 <gmaxwell> phantomcircuit: above you made it sound like it applies to all existing txn but that isn't so. :)
500 2015-11-05 20:05:55 <morcos> wumpus or other commit access people, could we get some 0.12 milestones?
501 2015-11-05 20:06:21 <gmaxwell> I'm adding some.
502 2015-11-05 20:06:57 <phantomcircuit> gmaxwell, didn't mean to imply that; thus "opt into"
503 2015-11-05 20:07:50 <sdaftuar> gmaxwell: if a wallet sets sequence number on an input in order to opt-in, are eg payment processors going to reject those txes without making changes to their systems?
504 2015-11-05 20:08:05 <sdaftuar> i assumed they'd need to make a change
505 2015-11-05 20:08:17 <sdaftuar> (though a simple one)
506 2015-11-05 20:08:52 <jgarzik> cfields, improper use of google calendar here too - just reset to UTC :)
507 2015-11-05 20:09:18 <gmaxwell> sdaftuar: depends on their existing standardness rules, some already would delay these (as they are "locktime transactions")
508 2015-11-05 20:09:27 <gmaxwell> jgarzik: there is no UTC in google calendar, no kidding.
509 2015-11-05 20:09:28 <sdaftuar> but if the locktime is in the past...
510 2015-11-05 20:09:49 <sdaftuar> for instance bitcoin core currently sets locktime to be height-10 or something right?
511 2015-11-05 20:09:51 <wumpus> gmaxwell: that's why it's planned in iceland time
512 2015-11-05 20:09:59 <jtimon> sdaftuar: miners (well, all nodes) implementing opt-in RBF policy will only replace conflicts when the replaced tx is marked with the opt-in seq
513 2015-11-05 20:10:09 <gmaxwell> sdaftuar: yes, but some have previously done this unconditionally.  I think it's mostly a communications question, as anyone doing zero conf risk assessment must be very aware of standardness rules and such.
514 2015-11-05 20:10:46 <sdaftuar> ok, agreed.
515 2015-11-05 20:11:20 <Luke-Jr> 0.10 backport branch is at https://github.com/bitcoin/bitcoin/pull/6953
516 2015-11-05 20:11:28 <gmaxwell> (so if you are not prepared to fairly quickly update your behavior, you've already lost in any case-- and here we'd be giving months notice in any case)
517 2015-11-05 20:12:13 <jgarzik> gmaxwell, I faked it with GMT+0
518 2015-11-05 20:12:37 <paulo_> what meeting bot do you use? home made?
519 2015-11-05 20:12:52 <wumpus> paulo_: http://meetbot.debian.net/Manual.html
520 2015-11-05 22:21:44 <esso> What are some people's thoughts on the fact that there is almost no one representing Bitcoin in the W3C Web Payments Interest Group? The Chairman of this group recently said this on reddit: https://www.reddit.com/r/Bitcoin/comments/3rl3f6/the_status_of_bitcoin_in_the_w3c_web_payments/