1 2015-10-08 00:08:52 <denisx> sounds like someone removed one line where an unused byte of the hash was written and then the compiler said “unused variable xy” and that was the starting snowball ;)
  2 2015-10-08 00:15:44 <xiando> Any thoughts on how bitcoind would handle a 3GB mempool?
  3 2015-10-08 00:15:59 <xiando> at this rate of growth  that is were we are in 24h
  4 2015-10-08 00:16:37 <phantomcircuit> xiando, assuming you have that much memory everything will be fine
  5 2015-10-08 00:16:39 <belcher> xiando use the option added in 0.11
  6 2015-10-08 00:16:49 <belcher> to drop the low fee spam txes
  7 2015-10-08 00:18:26 <xiando> That's another oddity belcher with minrelayfee=0.00016 (spammers use .00015) it's currently using 1.7GB mem, it was 2.2GB when I did that and it was using less a short while but it appers to grow (but not as much) rapidly anyway
  8 2015-10-08 00:19:00 <belcher> interesting
  9 2015-10-08 00:19:02 <xiando> phantomcircuit: Thank you, good to know, I guess those nodes with 16GB+ may be fine (unless they keep it up a week, but it's already cost them 10BTC in fees)
 10 2015-10-08 00:20:32 <phantomcircuit> shrug
 11 2015-10-08 00:20:53 <phantomcircuit> there's lots of work going on now to efficiently limit the memory pool
 12 2015-10-08 00:22:14 <xiando> if you guys somehow limit what they are doing with tx like 2ed476173dccf7a07ef4a0709229a8757b6dfcba318af77638e222744f1fde7e then great, there's been spam before but this time they made sure each tx is 14790B not 2-300B like most
 13 2015-10-08 00:29:49 <nanotube> xiando: minrelaytxfee=, not minrelayfee=, afaik
 14 2015-10-08 00:32:14 <denisx> setting these values live would be nice
 15 2015-10-08 00:44:40 <ProfMac> is there a code beautifier that supports whatever style the developers use?
 16 2015-10-08 00:44:58 <ProfMac> I have used uncrustify recently.
 17 2015-10-08 01:00:47 <BlueMatt> thoughts on running low-s mutation on the network?
 18 2015-10-08 01:01:05 <BlueMatt> ie trying to counter the all-s-mutation that people have been running by mutating everything to low-s
 19 2015-10-08 01:07:26 <phantomcircuit> BlueMatt, ACK
 20 2015-10-08 03:25:21 <seba_> hi
 21 2015-10-08 03:43:39 <zmanian> BlueMatt: The usability for software users who haven't upgraded / maintained their software will probably be harmed. But they probably need to be motivated to act.
 22 2015-10-08 04:28:52 <xiando> c
 23 2015-10-08 04:30:13 <pbase> Why doesn't bitcoin protocol reward users for contributing bandwidth and hosting the node data? Why does it assume it as a free service?
 24 2015-10-08 04:32:25 <justanotheruser> pbase: because it's impossible
 25 2015-10-08 04:34:16 <pbase> justanotheruser: how?
 26 2015-10-08 04:34:24 <justanotheruser> #bitcoin
 27 2015-10-08 05:57:42 <warren> btcdrak: jgarzik: I agree the noise is intolerable, I finally have the call scheduled for Thursday morning, this will be taken care of soon.
 28 2015-10-08 06:18:03 <BlueMatt> zmanian: yea, its a hard call to make...hence why i asked for opinions
 29 2015-10-08 06:18:18 <BlueMatt> zmanian: its also informed by the recent all-s-mutations that have been happening on the network
 30 2015-10-08 06:18:26 <BlueMatt> plus the upcoming non-standardness of high-s
 31 2015-10-08 06:18:34 <warren> upcoming?
 32 2015-10-08 06:18:48 <phantomcircuit> note: i am running this on mainnet right now
 33 2015-10-08 06:19:00 <phantomcircuit> warren, it's still IsStandard
 34 2015-10-08 06:19:12 <phantomcircuit> which needs to be changed
 35 2015-10-08 06:19:31 <warren> sorry I haven't been following that issue for a while, do we plan on it becoming a consensus rule instead?
 36 2015-10-08 06:19:47 <phantomcircuit> warren, yes it's part of BIP 66
 37 2015-10-08 06:19:49 <phantomcircuit> er
 38 2015-10-08 06:19:50 <phantomcircuit> 62?
 39 2015-10-08 06:20:03 <phantomcircuit> it's part of BIP 62
 40 2015-10-08 06:20:05 <warren> that's a planned soft fork?
 41 2015-10-08 06:20:09 <phantomcircuit> yes
 42 2015-10-08 06:20:12 <warren> awesome
 43 2015-10-08 06:20:23 <warren> are there other known vectors of malleability after that?
 44 2015-10-08 06:20:32 <phantomcircuit> historically we're made things !IsStandard long before a soft fork
 45 2015-10-08 06:20:48 <phantomcircuit> warren, that's the last known vector for standard P2PKH transactions
 46 2015-10-08 06:22:04 <BlueMatt> its long-term planned as a soft fork
 47 2015-10-08 06:22:11 <BlueMatt> but there are no immediate deployment plans
 48 2015-10-08 06:22:13 <warren> oh
 49 2015-10-08 06:22:21 <BlueMatt> however, its already non-standard on master
 50 2015-10-08 06:22:26 <warren> what are the desired 4 things for a near-term soft fork?
 51 2015-10-08 06:22:30 <BlueMatt> so next release (incl backports) it will be non-standard
 52 2015-10-08 06:22:54 <BlueMatt> warren: all the planned ones are related to locktime
 53 2015-10-08 06:23:08 <BlueMatt> malleability may be a good series of soft forks for versionbits, actually
 54 2015-10-08 06:23:27 <BlueMatt> just split bip62 into ten softforks and deploy them shotgun-style
 55 2015-10-08 06:23:35 <warren> but that later soft fork is only possible after the non-versionbits softfork locks in?
 56 2015-10-08 06:23:42 <BlueMatt> and, yes, I'm running the malleate-to-low-s patch on mainnet as well
 57 2015-10-08 06:23:42 <phantomcircuit> BlueMatt, bleh max ancestors should be like 2 not 25
 58 2015-10-08 06:23:55 <BlueMatt> phantomcircuit: more like 5
 59 2015-10-08 06:23:56 <BlueMatt> but, yeaaaa
 60 2015-10-08 06:24:09 <BlueMatt> warren: yea, but its only a few months
 61 2015-10-08 06:26:05 <CodeShark_> warren, it's possible to deploy IsSuperMajority softforks alongside versionbits softforks
 62 2015-10-08 06:26:21 <phantomcircuit> BlueMatt, serica/digitaltangibles == colored coins?
 63 2015-10-08 06:26:37 <BlueMatt> phantomcircuit: possible? I dont recall exactly
 64 2015-10-08 06:26:50 <BlueMatt> I think it may be, though
 65 2015-10-08 06:27:46 <phantomcircuit> k... then im going to be pushing back on that now...
 66 2015-10-08 06:28:12 <phantomcircuit> also it sounds like they're doing something hugely suboptimal as some sort of regulator dodge
 67 2015-10-08 06:30:46 <CodeShark_> +
 68 2015-10-08 06:40:33 <warren> did we decide what to do about the block version conflict thing?
 69 2015-10-08 07:17:35 <Luke-Jr> warren: you mean XT? I thought we were just going to ignore it since nobody is mining it
 70 2015-10-08 07:22:51 <phantomcircuit> warren, yeah id say just ignore it
 71 2015-10-08 07:22:57 <phantomcircuit> nobody is using or mining on xt
 72 2015-10-08 07:29:13 <BlueMatt> phantomcircuit: naa, theres a block or two now and again
 73 2015-10-08 07:29:16 <BlueMatt> but, yea, thats about it
 74 2015-10-08 07:30:07 <phantomcircuit> BlueMatt, shrug
 75 2015-10-08 07:30:10 <phantomcircuit> irrelevant
 76 2015-10-08 07:30:25 <Luke-Jr> BlueMatt: it's less than any pre-softfork block rate :P
 77 2015-10-08 07:30:53 <BlueMatt> heh, indeed
 78 2015-10-08 11:15:18 <dom__> help
 79 2015-10-08 15:57:30 <helpmeeee> helpppp anyone here uses bitpay insight-api ?
 80 2015-10-08 15:57:59 <helpmeeee> stuck with orphan block error.... need help with resync from prev block
 81 2015-10-08 15:58:04 <helpmeeee> if that's possible
 82 2015-10-08 15:58:11 <helpmeeee> tryed this "sudo INSIGHT_NETWORK="livenet" util/sync.js --start  00000000000000000f77c227f84b4e62f3672e29d3d1ed1fd8b61f28c3000f34"
 83 2015-10-08 15:58:42 <nwilcox> helpmeeee: I'm not familiar with that API, but I'm almost certain people consider this off topic. This channel is just for bitcoin-core dev.
 84 2015-10-08 15:59:10 <helpmeeee> is there a dev for bitpay? already tried on #bitcore no help
 85 2015-10-08 15:59:20 <helpmeeee> :( i reindexed bitcoind too
 86 2015-10-08 16:00:16 <helpmeeee> nwilcox: does a orphaned blocked cause bitcoind to break.. and one has to reindexing?
 87 2015-10-08 16:05:37 <paveljanik> nwilcox, this is generic Bitcoin development channel. Bitcoin Core has its own channel.
 88 2015-10-08 16:11:03 <nwilcox> paveljanik: Oh, I see.
 89 2015-10-08 16:11:36 <nwilcox> helpmeeee: If orphaned blocks caused bitcoind to break, bitcoin would not be possible (assuming most nodes are bitcoind).
 90 2015-10-08 16:18:28 <helpmeeee> nwilcox: yup... just wanted to know I wasted hours reindexing bitcoind instead of fixing insight :( thx
 91 2015-10-08 16:21:17 <Luke-Jr> paveljanik: nwilcox: that being said, *using* APIs is not development topic :p
 92 2015-10-08 16:23:26 <paveljanik> it is, but not bitcoin development.
 93 2015-10-08 16:23:46 <paveljanik> the Q is, if this channel will be about developing bitcoin or developing around bitcoin
 94 2015-10-08 16:24:43 <Belxjander> I always thought this channel was "bitcoin core development" and related materials...anything "around bitcoin" can have its own project channels elsewhere...am I wrong?
 95 2015-10-08 16:27:44 <Luke-Jr> Belxjander: yeah, not Core-specific
 96 2015-10-08 16:28:09 <Luke-Jr> Belxjander: eg, btcd, libbitcoin, Electrum, etc are fine
 97 2015-10-08 16:29:48 <Belxjander> so any "implementation" of a bitcoin client/server but not the APIs for using them ?
 98 2015-10-08 16:30:47 <btcdrak> helpmeeee: check your PM
 99 2015-10-08 16:31:18 <Luke-Jr> Belxjander: basically
100 2015-10-08 16:31:47 <Luke-Jr> Belxjander: the distinction is whether it's development of Bitcoin stuff, or development of unrelated stuff that happens to be *using* Bitcoin
101 2015-10-08 16:34:44 <Belxjander> bitcoin or use of bitcoin...
102 2015-10-08 16:34:48 <Belxjander> I get the distinction
103 2015-10-08 16:34:54 <Belxjander> it's a layercake thing
104 2015-10-08 16:35:22 <Belxjander> the bitcoin stack or the app on top :)
105 2015-10-08 16:40:02 <ProfMac> Is there a standard directory where people download their gits?  such as ~/projects or ~/SF or whatever?
106 2015-10-08 16:40:36 <Belxjander> ProfMac: entirely up to you as to where you store what you clone
107 2015-10-08 16:41:50 <Luke-Jr> ProfMac: Projects/Tonal/Bitcoin/
108 2015-10-08 16:41:59 <Luke-Jr> :P
109 2015-10-08 16:42:03 <coin_trader> any of you guys know how the 'estimatefee' cli/rpc command works in core? and what could cause certain values to fail and report back -1?
110 2015-10-08 16:42:23 <ProfMac> Luke-Jr: "Tonal" ?
111 2015-10-08 16:42:25 <Luke-Jr> coin_trader: insufficient balance?
112 2015-10-08 16:42:38 <Luke-Jr> ProfMac: yes, https://en.wikipedia.org/wiki/Tonal_system
113 2015-10-08 16:42:46 <coin_trader> Luke-Jr: it has nothing to do with balance
114 2015-10-08 16:42:59 <coin_trader> estimatefee is just a cli command
115 2015-10-08 16:43:03 <Luke-Jr> …
116 2015-10-08 16:43:20 <coin_trader> something to do with how many blocks the node has 'seen' .. but it is giving me wonky results
117 2015-10-08 16:43:35 <coin_trader> and i dont know if there's some cache file that got fucked and i need to flush it
118 2015-10-08 16:43:38 <paveljanik> help estimatefee: A negative value is returned if not enough transactions and blocks have been observed to make an estimate.
119 2015-10-08 16:43:52 <Luke-Jr> oh, that one
120 2015-10-08 16:43:53 <coin_trader> yea except it gives me -1 for one block estimate, and values up until 24 blocks
121 2015-10-08 16:44:03 <coin_trader> root@node:~# bitcoin-cli estimatefee 1   = -1.00000000
122 2015-10-08 16:44:03 <coin_trader> root@node:~# bitcoin-cli estimatefee 2  = 0.00019771
123 2015-10-08 16:44:20 <coin_trader> why would n=1 be broken?
124 2015-10-08 16:44:26 <coin_trader> but n=2....24 works
125 2015-10-08 16:44:32 <coin_trader> or at least reports back non -1
126 2015-10-08 16:44:47 <ProfMac> Luke-Jr: Ah.  I once made a postscript that printed a semilog chart with 16 division per cycle ...
127 2015-10-08 16:44:56 <coin_trader> but i have other nodes running which work fine and report different vlaues
128 2015-10-08 16:44:59 <coin_trader> so i'm very confused
129 2015-10-08 16:45:03 <coin_trader> (4 nodes total)
130 2015-10-08 16:45:06 <Luke-Jr> coin_trader: insufficient data != broken
131 2015-10-08 16:45:19 <Luke-Jr> coin_trader: has it been running 24/7 for long?
132 2015-10-08 16:45:21 <coin_trader> fair enough, but if i have data for ETA on 2 blocks, not 1?
133 2015-10-08 16:45:21 <paveljanik> coin_trader, maybe there was no transaction that got into the block almost immediattely
134 2015-10-08 16:45:37 <paveljanik> ... after your node seen it?
135 2015-10-08 16:45:40 <coin_trader> luke on 3 nodes i can start and stop and restart and it give values regardless because it's in sync
136 2015-10-08 16:46:00 <Luke-Jr> coin_trader: it needs to observe the network live; syncing after the fact won't help
137 2015-10-08 16:46:05 <coin_trader> the one in question that reports the errors has the most uptime strangely
138 2015-10-08 16:46:15 <coin_trader> t's been over 247 for awhile now
139 2015-10-08 16:46:32 <coin_trader> same issue, whereas the other core nodes seem to report back legit estimates
140 2015-10-08 16:47:24 <coin_trader> root@different-node:~# bitcoin-cli estimatefee 1  = 0.00038832
141 2015-10-08 16:47:24 <coin_trader> root@different-node:~# bitcoin-cli estimatefee 2 = 0.00016540
142 2015-10-08 16:47:32 <coin_trader> so like.. what gives?
143 2015-10-08 16:48:48 <coin_trader> i'm saying all nodes been interacting and sending transactions for many many hours
144 2015-10-08 16:48:58 <coin_trader> but one is not giving estimatefee results correct
145 2015-10-08 16:49:21 <coin_trader> there is a fee_estimates.dat file, what does that have to do with anything -- anyone know?
146 2015-10-08 17:14:41 <maaku> coin_trader: those estimates are entirely node-dependent
147 2015-10-08 17:15:20 <coin_trader> i'm aware - and if i notice that one node is showing me consistently for estimatefee = 1 it's incorrect -1, and other values work... can i copy the dat from one node to another?
148 2015-10-08 17:15:29 <coin_trader> can i delete the dat and have it regenerate?
149 2015-10-08 17:19:45 <maaku> sure
150 2015-10-08 17:19:51 <maaku> you won't gain much from it though
151 2015-10-08 17:19:59 <maaku> those estimates get better over time, not worse
152 2015-10-08 17:20:13 <coin_trader> any insight as to why estimatefee 1 would result in -1 and estimatefee 2 would result in valid numbers?
153 2015-10-08 17:20:31 <coin_trader> logic would imply if node can make estimate for 2 node inclusion, surely it can do 1
154 2015-10-08 17:20:43 <coin_trader> so if it's reporting back -1 .... for days...... then i dont know what to do to fix
155 2015-10-08 17:23:46 <paveljanik> coin_trader, what options are set in the config file?
156 2015-10-08 17:24:09 <coin_trader> specifically which are you asking for?
157 2015-10-08 17:24:10 <paveljanik> any fee/relay prios?
158 2015-10-08 17:24:21 <coin_trader> minrelay is set for 00002
159 2015-10-08 17:24:25 <coin_trader> htat is all
160 2015-10-08 17:24:38 <paveljanik> ie 2 BTC? per kb? ;-)
161 2015-10-08 17:25:26 <coin_trader> err no .00002 :)
162 2015-10-08 17:26:01 <coin_trader> i think default is .00001 so to mitigate the spam BS i doubled it -- but i did that on all nodes and no problems were on those estimatefee
163 2015-10-08 17:26:18 <coin_trader> again, i run 4 full nodes, and only 1 is reporting back the weird estimatefee results
164 2015-10-08 17:36:42 <btcdrak> well so much for XT's mempool limiter with their nodes dropping off at the same % as the rest of the network..
165 2015-10-08 18:28:15 <dstadulis> anyone know if wladimir setup meetbot for today's meeting?
166 2015-10-08 18:28:30 <dstadulis> He mentioned to me last week he was planning to set it up
167 2015-10-08 18:30:19 <dstadulis> as a backup, I have a 'Topics to be Discussed' section in meeting minutes here: https://docs.google.com/document/d/1hCDuOBNpqrZ0NLzvgrs2kDIF3g97sOv-FyneHjQellk/edit
168 2015-10-08 18:30:59 <wumpus> dstadulis: nope, no meetbot, we had one in #bitcoin-core-dev for a while but I don't think so anymore
169 2015-10-08 18:32:15 <dstadulis> wumpus any reason not to use meetbot?
170 2015-10-08 18:32:31 <wumpus> no particular reason, except that we have none
171 2015-10-08 18:33:22 <lightningbot`> Meeting started Thu Oct  8 18:33:22 2015 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
172 2015-10-08 18:33:22 <lightningbot`> Useful Commands: #action #agreed #help #info #idea #link #topic.
173 2015-10-08 18:33:22 <wumpus> #startmeeting
174 2015-10-08 18:33:26 <wumpus> oh, we do
175 2015-10-08 18:33:34 <dstadulis> :]
176 2015-10-08 18:33:49 <lightningbot`> Log:            http://www.erisian.com.au/meetbot/bitcoin-dev/2015/bitcoin-dev.2015-10-08-18.33.log.html
177 2015-10-08 18:33:49 <lightningbot`> Meeting ended Thu Oct  8 18:33:49 2015 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
178 2015-10-08 18:33:49 <lightningbot`> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-dev/2015/bitcoin-dev.2015-10-08-18.33.html
179 2015-10-08 18:33:49 <lightningbot`> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-dev/2015/bitcoin-dev.2015-10-08-18.33.txt
180 2015-10-08 18:33:49 <wumpus> #endmeeting
181 2015-10-08 18:34:07 <wumpus> thought it was not set up here
182 2015-10-08 18:48:53 <morcos> coin_trader: estimatefee is more likely to return -1 when you ask about 1 block because it is often the case that there is not enough data points to reliably tell you what fee you would need to put on a tx and have it confirmed in the next block
183 2015-10-08 18:49:15 <coin_trader> morcos: please expound upon that theory
184 2015-10-08 18:49:34 <morcos> it determines this by looking at the lowest fee rate over some historical window that has had 85% of txs of that fee rate or higher confirmed in the desired number of blocks
185 2015-10-08 18:49:36 <coin_trader> i do not quite follow how estimate 2 = valid and estimate 1 doesnt
186 2015-10-08 18:49:56 <morcos> it requires some minimum number of data points
187 2015-10-08 18:50:24 <morcos> so suppose by the time it has look at the 100 highest fee txs over the last 2 days, only 84 of them were confirmed in 1 block
188 2015-10-08 18:50:29 <morcos> then it can't give you an answer for 1
189 2015-10-08 18:50:52 <morcos> but would be very rare for of those same 100 txs, less than 85 of them have been confirmed in 2 blocks
190 2015-10-08 18:51:03 <morcos> 100 and 2 days are examples and not the actual values used
191 2015-10-08 18:51:36 <coin_trader> what i'm confused about is that if this requires X data points, it implies to me that the call would return -1 AFTER a certain number - not before and after a valid range?
192 2015-10-08 18:51:51 <coin_trader> i get -1 for estimatefee 1, and then 25 and above
193 2015-10-08 18:51:57 <coin_trader> from 2 .... 24 i get values....
194 2015-10-08 18:52:02 <coin_trader> i am confused at that discrepancy
195 2015-10-08 18:52:07 <morcos> 25 and above it doesn't track stats for
196 2015-10-08 18:52:11 <coin_trader> ohhhhhhhh
197 2015-10-08 18:52:16 <morcos> i suppose it could give the 24 answer for 25 and above
198 2015-10-08 18:52:20 <coin_trader> so it will ALWAYS go -1 for 25 and above?
199 2015-10-08 18:52:24 <morcos> but i didn't change that logic
200 2015-10-08 18:52:25 <morcos> correct
201 2015-10-08 18:52:32 <coin_trader> oh ho well then that'll explain that side
202 2015-10-08 18:52:48 <coin_trader> and now for the -1 you're saying (approx) i need to 'witness' how many tx...
203 2015-10-08 18:52:55 <coin_trader> you say a certain % of 'highest tx' ?
204 2015-10-08 18:52:59 <coin_trader> i dont follow what that means
205 2015-10-08 18:53:20 <coin_trader> also, does minrelayfee affect this estimate in any way?
206 2015-10-08 18:53:20 <morcos> i think its an average of 1 tx per block over approx the last 500 blocks
207 2015-10-08 18:53:43 <morcos> its an exponential moving average
208 2015-10-08 18:54:03 <morcos> but pretend it was a simple average over the last 500 blocks, it would need 500 txs to have a data pt
209 2015-10-08 18:54:39 <morcos> so it looks at all the txs with fee rate 10M+ and say their are 3, and then 9M-10M and there are 100 more, and then 8M-9M and so on until it has 500 txs.
210 2015-10-08 18:54:53 <coin_trader> i feel you on the EMA and how it requires a set of data for a single point that is the result of a function on the series. i'm just confused why it cant get me value for 1 but it can for 2
211 2015-10-08 18:55:20 <morcos> and if its at 4M sat /kb then suppose, it could return that answer if over 85% of them were confirmed in 1 block, and when it does then next 500 down, its less than 85%
212 2015-10-08 18:55:36 <morcos> no minrelay fee will not affect it other than none of your answers will ever be less than minrelay fee
213 2015-10-08 18:56:53 <morcos> its look at the same data points for both of them, but less than 85% of them were confirmed in 1 block, and more than 85% were confirmed in 2 blocks, so it keeps looking at lower and lower fee txs for the 2 block answer until it falls below 85% and then returns the lowest fee that was above 85%
214 2015-10-08 18:57:00 <morcos> i think the algo is spelled out in the code
215 2015-10-08 18:57:11 <morcos> i mean in the comments
216 2015-10-08 18:57:13 <morcos> :)
217 2015-10-08 18:57:49 <coin_trader> hmm i should probably look over it - do you know which file i can look into on the github and read it?
218 2015-10-08 18:58:27 <morcos> policy/fees.cpp or something approx like that
219 2015-10-08 18:58:36 <morcos> maybe .h for the comments
220 2015-10-08 18:59:18 <wumpus> time to start the meeting, I think
221 2015-10-08 18:59:38 <lightningbot`> Meeting started Thu Oct  8 18:59:38 2015 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
222 2015-10-08 18:59:38 <lightningbot`> Useful Commands: #action #agreed #help #info #idea #link #topic.
223 2015-10-08 18:59:38 <wumpus> #startmeeting
224 2015-10-08 19:00:23 <btcdrak> are we ready?
225 2015-10-08 19:00:26 <wumpus> let's start with the action items from last time
226 2015-10-08 19:00:37 <dstadulis> I have a 'Topics to be Discussed' section in meeting minutes here: https://docs.google.com/document/d/1hCDuOBNpqrZ0NLzvgrs2kDIF3g97sOv-FyneHjQellk/edit
227 2015-10-08 19:00:51 <dstadulis> and action items from last meeting are in that link too
228 2015-10-08 19:00:57 <wumpus> yes, thanks dstadulis
229 2015-10-08 19:01:19 <wumpus> #topic Mempool limiting
230 2015-10-08 19:01:42 <sipa> there seem to be some comments on the proposed reduction of chain limits
231 2015-10-08 19:02:07 <morcos> ok well i think we've pretty much concentrated on 6722 at this point.  matt's pull.  and it seems to be nice and simple.  i haven't reviewed his latest changes yet though, so i don't know that we're 100% there yet
232 2015-10-08 19:02:42 <sipa> my mempool is 2.5G... we better get some solution!
233 2015-10-08 19:02:49 <gmaxwell> We should at least mention the lowS change (and maybe small discussion on backport release schedule.)
234 2015-10-08 19:02:57 <sipa> gmaxwell: ack
235 2015-10-08 19:03:04 <petertodd> gmaxwell: ack
236 2015-10-08 19:03:08 <morcos> have others been reviewing it? i'd like to get it merged as soon as possible after its ready
237 2015-10-08 19:03:13 <morcos> perhaps before next weeks meeting
238 2015-10-08 19:03:23 <sipa> morcos: do we have any theoretical upper limits on the iteration counts given certain chain limits?
239 2015-10-08 19:03:31 <petertodd> morcos: I did some review of it, but not enough to say I'd ack it
240 2015-10-08 19:03:37 <morcos> you mean for runtime complexity sipa?
241 2015-10-08 19:03:41 <wumpus> gmaxwell: yes, that can come later
242 2015-10-08 19:03:43 <sipa> morcos: yes
243 2015-10-08 19:03:55 <morcos> the way it works now is it just boots the first package period
244 2015-10-08 19:03:56 <gmaxwell> wumpus: I just meant as a proposed agenda item.
245 2015-10-08 19:04:11 <sipa> morcos: because runtime performance is what drives the decision to reduce the chain limits?
246 2015-10-08 19:04:19 <morcos> sipa: no, not really
247 2015-10-08 19:04:30 <coin_trader> morcos: thanks on the source file tip - reading now
248 2015-10-08 19:04:46 <gmaxwell> sipa: also long chains bypass fees meaning anything because the tx at the end will never go in.
249 2015-10-08 19:04:49 <morcos> i think run time performance is probably ok with limits as high as 100/100
250 2015-10-08 19:05:26 <morcos> the concern is more that with higher limits you can create degenerate sets of txs that look like high fee rate for eviction and low fee rate for mining
251 2015-10-08 19:05:31 <morcos> so they neither get mined or evicted
252 2015-10-08 19:05:34 <sipa> got it
253 2015-10-08 19:05:57 <morcos> to be quite honest, i'm not sure if 25/25 is safe, but perhaps this isn't the place for that discussion
254 2015-10-08 19:06:01 <petertodd> gmaxwell: re "never go in" is that really true?
255 2015-10-08 19:06:16 <morcos> i think getting limits as small as we can reasonably get is important
256 2015-10-08 19:06:28 <gmaxwell> petertodd: with high probablity, at least.
257 2015-10-08 19:06:42 <sipa> petertodd: with the current tx selection they are unlikely to go in fast, which is what matters - i think - if they don't, there's no need for them to be in the mempool yet
258 2015-10-08 19:06:45 <morcos> petertodd: its also important to think about what will be mined using existing code and using code that would do CPFP.  CPFP would be way better, but may actually be worse at certain cases
259 2015-10-08 19:07:21 <petertodd> sipa: right, so this is because of the current mining node, not necessarily a fundemental problem
260 2015-10-08 19:07:25 <morcos> we did almost all of our attack analysis assuming CPFP mining.  we should probably do it again without, but i don't know what we'll be able to do about that
261 2015-10-08 19:07:36 <sipa> so, action item: review/test #6722?
262 2015-10-08 19:07:45 <morcos> yes!
263 2015-10-08 19:07:46 <gmaxwell> petertodd: e.g. (CPFP example is easiest) you have a chain with 10mb of low fee transactions, and a high fee at the end. The collection has high fee rate, but no miner cares, and the tx at the end may well get doublespent first; so they never pay their fee.
264 2015-10-08 19:08:01 <morcos> and help try to get as low chain limits as possible pushed through
265 2015-10-08 19:08:09 <sipa> gmaxwell: CPFP mining would fix that, though
266 2015-10-08 19:08:10 <petertodd> sipa: re: 'in the mempool' I'd expect most of the argument there being companies want to be "messaging" people they're sending funds too, so they see the tx immediately
267 2015-10-08 19:08:27 <bsm117532> Is the current malleability attack due to chains?  Or malleability?  (see http://motherboard.vice.com/read/i-broke-bitcoin) If the former, we should discuss bip62 as well.
268 2015-10-08 19:08:40 <bsm117532> *is the current mempool explosion due to malleability or chains...
269 2015-10-08 19:08:41 <sipa> bsm117532: yes, we will discuss that
270 2015-10-08 19:08:50 <sipa> gmaxwell: unless the package becomes so large that it doesn't fit in a block anymore
271 2015-10-08 19:08:57 <morcos> the current mempool explosion is due to a low relay rate and no mempool limiting
272 2015-10-08 19:09:00 <gmaxwell> sipa: thats what I just described, 10mb.
273 2015-10-08 19:09:09 <petertodd> gmaxwell: oh sure, but I mean, with lower limits - ie 100, 300 byte txs I'd expect to get mined reasonably fast so long as they had reasonable fees
274 2015-10-08 19:09:11 <sipa> gmaxwell: ugh, i need to learn to read
275 2015-10-08 19:09:14 <morcos> chain limited code still has very large mempools right now
276 2015-10-08 19:09:16 <sipa> anything else on mempool?
277 2015-10-08 19:09:34 <petertodd> gmaxwell: total size I think matters re: "will they get mined", not # of txs, which is just a performance issue
278 2015-10-08 19:10:11 <morcos> petertodd: yes total size is a bigger problem than just count of txs, and there doesn't seem to be any push back on that, except to make 100 -> 101
279 2015-10-08 19:10:12 <petertodd> bsm117532: bit62 is still fairly far off I think; low-s fixes most of the issue at least
280 2015-10-08 19:10:23 <wumpus> yes, lows will be next topic
281 2015-10-08 19:10:29 <sipa> petertodd, bsm117532: anything else on mempool?
282 2015-10-08 19:10:34 <morcos> but count of txs is a problem on its own
283 2015-10-08 19:10:36 <bsm117532> According to the above article, the current attack is due to malleating...
284 2015-10-08 19:10:44 <dstadulis> #action review/test PR #6722
285 2015-10-08 19:10:46 <sipa> bsm117532: please stick to topic
286 2015-10-08 19:10:47 <coin_trader> different attack bsm
287 2015-10-08 19:11:04 <petertodd> morcos: so I'd think a 101 size limit is fine, and then base the count of txs on measured performance with a reasonable margin (which I haven't done)
288 2015-10-08 19:11:10 <morcos> not just for performance reasons
289 2015-10-08 19:11:24 <wumpus> malleating has nothing to do with mempool limiting, let's not get off topic
290 2015-10-08 19:11:30 <dstadulis> +!
291 2015-10-08 19:11:36 <phantomcircuit> morcos, in general i would say that the assumption should be that miners are sorting on a strict feerate basis for transactions with no dependents
292 2015-10-08 19:11:44 <morcos> its for the ability of the tx to look different when viewed as an ancestor package or a descendant package.  the structure of the package can be more complex with more txs and thus more evil almost
293 2015-10-08 19:11:44 <petertodd> phantomcircuit: +1
294 2015-10-08 19:11:58 <sipa> phantomcircuit: how hard would that be to change?
295 2015-10-08 19:12:30 <phantomcircuit> sipa, pretty hard to change
296 2015-10-08 19:12:32 <morcos> sipa: i don't think its impossible to imagine we could have CPFP mining for 0.12, but its a stretch
297 2015-10-08 19:12:49 <morcos> at least as a patch not long after maybe
298 2015-10-08 19:12:51 <sipa> phantomcircuit: if getblocktemplate would return a CPFP-aware set, isn't that enough?
299 2015-10-08 19:12:58 <petertodd> morcos: RBF seems more likely, and it could help negate some of the cases where you want lots of txs in a row
300 2015-10-08 19:13:10 <phantomcircuit> sipa, you'd need to have multiple CreateBlock strategies and then decide which to use based on which has the highest total fees
301 2015-10-08 19:13:20 <phantomcircuit> sipa, it's significantly more effort than it initially seems
302 2015-10-08 19:13:21 <sipa> phantomcircuit: assume that's done
303 2015-10-08 19:13:24 <morcos> petertodd: it has nothing to do with RBF or using CPFP to get txs boosted in priority
304 2015-10-08 19:13:32 <morcos> it has to do with maximizing miners income
305 2015-10-08 19:13:32 <sipa> phantomcircuit: i wonder about anything outside of bitcoind
306 2015-10-08 19:13:46 <petertodd> morcos: I mean, it helps make the argument that a smaller limit to total txchain depth is OK
307 2015-10-08 19:13:55 <phantomcircuit> sipa, the CPFP set aware getblocktemplate is going to have higher latency than the naive strategy for sure
308 2015-10-08 19:14:31 <sipa> phantomcircuit: i'm not convinced about that - i think we can do significantly better than the current GBT implementation
309 2015-10-08 19:14:33 <gmaxwell> There is no reason gbt latency should have anything to do with the time CNB takes.
310 2015-10-08 19:14:42 <phantomcircuit> there's also the issue that mutated transaction in the chain will cause block validation and relay to take longer
311 2015-10-08 19:14:52 <gmaxwell> (because the result can be precomputed and it can return an empty template if thats the best precomputation it has right now.)
312 2015-10-08 19:14:54 <sipa> phantomcircuit: also, CPFP indexing would happen ahead of time, so GBT would only iterate and assemble
313 2015-10-08 19:14:56 <morcos> anyway, improving mining is a bit far off for now.  suffice it to say, i think we should consider whether there are crippling attacks with the existing mining code still possible once we have lower chain limits and 6722 merged
314 2015-10-08 19:15:05 <morcos> and if so, maybe we need some short term fix for them...
315 2015-10-08 19:15:05 <wumpus> how can we make progress with mempool limiting? as sipa said, it appears to be getting quite urgent, at some point we have to make a decision about strategies
316 2015-10-08 19:15:07 <sipa> morcos: agree
317 2015-10-08 19:15:12 <btcdrak> morcos: +1
318 2015-10-08 19:15:19 <petertodd> morcos: +1
319 2015-10-08 19:15:35 <sipa> what about those chain limits then?
320 2015-10-08 19:15:39 <phantomcircuit> morcos, yes
321 2015-10-08 19:16:23 <sipa> are there any known use cases where 25 is not enough?
322 2015-10-08 19:16:31 <morcos> lets work on trying to convince the people who are opposed to 25.  i'd feel a lot better about 25 than 100.  but can't give you a proof why its better
323 2015-10-08 19:16:54 <phantomcircuit> sipa, i dont believe there's any known use case for which 5 would not be enough
324 2015-10-08 19:17:07 <morcos> what do you think about the possiblity that some nodes have low limits and some have high
325 2015-10-08 19:17:22 <morcos> lets say you had a 50% chance of having 10/10 and a 50% chance of having 100/100
326 2015-10-08 19:17:22 <petertodd> sipa: so, an interesting argument re: them, is that senders need to take into account that a receiver might respend an output, blowing up the chian limit; in short they should be able to queue txs for broadcast ontheir own
327 2015-10-08 19:17:25 <btcdrak> yeah, I think the argument was not less than 5, but that 25 is plenty.
328 2015-10-08 19:17:27 <morcos> as a default
329 2015-10-08 19:17:42 <petertodd> sipa: (unless I'm completley misunderstanding this)
330 2015-10-08 19:17:43 <morcos> then attacks dont' cripple relay across the network if 10 nodes are immune
331 2015-10-08 19:17:44 <gmaxwell> morcos: inconsistency isn't great; you waste bandwidth forwardings things that get dropped.
332 2015-10-08 19:17:53 <morcos> and long chains can still be relayed across the 100 nodes
333 2015-10-08 19:18:13 <morcos> gmaxwell: yeah, but the long chains are relatively rare
334 2015-10-08 19:18:29 <sipa> well rare is not an argument for not protecting against
335 2015-10-08 19:18:36 <gmaxwell> ultimately you're setting yourself up for extreme vulerablity to malleability and double spend when you make long chains; so there are plenty of other factors that limit utility of long chains as well.
336 2015-10-08 19:18:42 <btcdrak> morcos: rare unless you're an attacker.
337 2015-10-08 19:18:51 <wumpus> +1 gmaxwell
338 2015-10-08 19:19:10 <bsm117532> A chain limit only impacts mempool, not relayed blocks, correct?  (otherwise it could cause a hard fork)
339 2015-10-08 19:19:10 <dstadulis> +1 gribble
340 2015-10-08 19:19:11 <btcdrak> gmaxwell: agreed
341 2015-10-08 19:19:15 <dstadulis> +1 gmaxwell
342 2015-10-08 19:19:16 <wumpus> so, all in all, 25 ought to be enough for everyone, for now
343 2015-10-08 19:19:19 <morcos> bsm117532: correct
344 2015-10-08 19:19:28 <btcdrak> wumpus: ack
345 2015-10-08 19:19:40 <petertodd> wumpus: alright, aack
346 2015-10-08 19:19:40 <sipa> morcos: if the driving reason for chain limits is to not make mempool selection and mining selection diverge too much... there is no real reason why the optimal value would differ between nodes
347 2015-10-08 19:19:45 <wumpus> bsm117532: yes, see the topic "mempool behavior"
348 2015-10-08 19:19:56 <morcos> wumpus: i agree for sure, but maybe we should have some more ACKs on the pull then, a decent number of comments are opposed
349 2015-10-08 19:20:07 <gmaxwell> If there is too much more debate on this, I'm going to begin advancing the view that we shouldn't relay transactions spending unconfirmed inputs at all.
350 2015-10-08 19:20:19 <morcos> sipa: diverge under attack
351 2015-10-08 19:20:27 <petertodd> gmaxwell: long run I have a lot of symapthy for that view
352 2015-10-08 19:20:29 <sipa> morcos: that's the only thing that matters :)
353 2015-10-08 19:20:36 <wumpus> morcos: do they mention an actual application?
354 2015-10-08 19:20:48 <morcos> i'm just saying its ok if we sacrifice half the nodes in an attack.. :)
355 2015-10-08 19:20:54 <gmaxwell> lets just all take homework to go look.
356 2015-10-08 19:20:58 <coin_trader> yea with regards to long chains of unconfirmed, i'm ok to pre-split large coin chunks into small.. i feel other service operators can also mod their systems to accommodate this requirement. Kinda sucks, but whatever. it's not too difficult to mitigate
357 2015-10-08 19:21:13 <sipa> ok, next topic?
358 2015-10-08 19:21:16 <morcos> wumpus: sort of, i didn't follow exactly
359 2015-10-08 19:21:19 <morcos> ack
360 2015-10-08 19:21:20 <wumpus> #topic LowS deployment
361 2015-10-08 19:21:23 <phantomcircuit> gmaxwell, I've yet to hear anybody articulate a strong reason for using unconfirmed inputs at all
362 2015-10-08 19:21:40 <coin_trader> phantomcircuit: it just makes using a default node "easier" for someone with high activity
363 2015-10-08 19:21:42 <warren> Who is tracking the current topic?
364 2015-10-08 19:21:44 <coin_trader> that is all i can tell from personal experience
365 2015-10-08 19:21:52 <gmaxwell> Minor OT notice: This issue https://github.com/feross/buffer/pull/81 has made most JS bitcoin software vulnerable to generating incorrect public keys.
366 2015-10-08 19:21:52 <wumpus> warren: lightningbot`
367 2015-10-08 19:21:57 <btcdrak> wumpus: is there anything stopping us rolling a release almost immediately?
368 2015-10-08 19:22:14 <wumpus> btcdrak: no, we could do a 0.10.3 and 0.11.1 now
369 2015-10-08 19:22:16 <dstadulis> Topics listed here: https://docs.google.com/document/d/1hCDuOBNpqrZ0NLzvgrs2kDIF3g97sOv-FyneHjQellk/edit
370 2015-10-08 19:22:28 <dstadulis> and lightningbot`
371 2015-10-08 19:22:31 <gmaxwell> LowS deployment. We've merged the change that makes lowS a standarness requirement. I believe this completely eliminates third party malleability annoyance attacks.
372 2015-10-08 19:22:34 <btcdrak> wumpus: then I think we should release it.
373 2015-10-08 19:22:38 <gmaxwell> (obviously miners can still malleate)
374 2015-10-08 19:22:52 <petertodd> wumpus: a release sounds fine to me
375 2015-10-08 19:23:00 <gmaxwell> Measurements show 95% of transactions already conforming; and thats before I went and got several more things to fix themselves (including electrum).
376 2015-10-08 19:23:14 <morcos> a release now and then another in a couple of weeks for soft-fork
377 2015-10-08 19:23:17 <morcos> ?
378 2015-10-08 19:23:20 <wumpus> right, this is about pull #6769
379 2015-10-08 19:23:22 <sipa> morcos: or for mempool limiting...
380 2015-10-08 19:23:23 <petertodd> morcos: that's fine by me
381 2015-10-08 19:23:24 <btcdrak> morcos: sure, why not
382 2015-10-08 19:23:26 <wumpus> (and its backports)
383 2015-10-08 19:23:32 <BlueMatt> several people are also running https://github.com/TheBlueMatt/bitcoin/tree/seed, which malleates to low-s on mainnet
384 2015-10-08 19:23:36 <sipa> i think both mempool limit and malleability are very short term concerns
385 2015-10-08 19:23:37 <BlueMatt> to counter the guy malleating everything
386 2015-10-08 19:23:56 <petertodd> BlueMatt: +1
387 2015-10-08 19:24:05 <morcos> sipa: mempool limiting is not easily backportable
388 2015-10-08 19:24:09 <btcdrak> BlueMatt: I'll get one spun up then
389 2015-10-08 19:24:22 <sipa> morcos: good point - and also much more likely to need fixes post merge
390 2015-10-08 19:24:28 <gmaxwell> Wumpus backported the change to older versions and we need to decide when to deploy.  If we release now we stop the attacks sooner which will make people happier.  Though it might be polite to slow roll somewhat due to giving the stragglers time to upgrade. At the same time upgrades take time and as matt just mentioned there is a compatiblity hack that prevents jamming.
391 2015-10-08 19:24:39 <coin_trader> BlueMatt: LOL that's hilarious :)
392 2015-10-08 19:25:11 <wumpus> yes, mempool limiting is riskier, whereas the LowS change is straightforward (it was already in the code, it just needed to be made standard), if we want a fast release, then we should postpone that for later
393 2015-10-08 19:25:28 <petertodd> and mempool limiting can be handled by just increasing the minimum relay fee too
394 2015-10-08 19:25:30 <BlueMatt> I'm not as concerned with low-s
395 2015-10-08 19:25:30 <morcos> i'm all for a release, but i think it should include CLTV
396 2015-10-08 19:25:45 <gmaxwell> So questions are: how comfortable are we with potentially causing blocking of up to 5% of transactions for a short window while people upgrade.
397 2015-10-08 19:25:46 <petertodd> I don we can handle a decent % of nodes dropping offline
398 2015-10-08 19:25:56 <btcdrak> morcos: still not enough reviewers on the backports for CLTV
399 2015-10-08 19:25:59 <petertodd> er, I don't see any reason why we can't handle a decent % of nodes dropping offline, at least temporarily
400 2015-10-08 19:26:01 <phantomcircuit> possibly the lows change should be backported and we do minor releases for backported versions but not a new major release?
401 2015-10-08 19:26:07 <gmaxwell> If we do a backport we could increment min relay fee.
402 2015-10-08 19:26:09 <BlueMatt> gmaxwell: I would be, if we had auto-malleating-to-standard nodes up all over the place
403 2015-10-08 19:26:10 <sipa> petertodd: wallets, not nodes...
404 2015-10-08 19:26:18 <gmaxwell> phantomcircuit: it's been backported, and right thats possible.
405 2015-10-08 19:26:22 <petertodd> sipa: I mean re: mempool limiting
406 2015-10-08 19:26:23 <morcos> gmaxwell: +1
407 2015-10-08 19:26:27 <wumpus> coupling with CLTV would be possible, although the deadline for that that was scheduled together with CSV for end of this month
408 2015-10-08 19:26:33 <petertodd> sipa: like, upping minrelay fee quicly stops the attack
409 2015-10-08 19:26:38 <BlueMatt> gmaxwell: I'm not a fan at all of rolling out low-s limits today
410 2015-10-08 19:26:45 <BlueMatt> we can get it on a miner or two
411 2015-10-08 19:26:48 <BlueMatt> to make the attack harder
412 2015-10-08 19:26:50 <btcdrak> BlueMatt: why?
413 2015-10-08 19:26:54 <BlueMatt> but rolling it out on the network....ehhhhh
414 2015-10-08 19:27:10 <wumpus> also not sure we want to couple it with softforks, to avoid confusion between mempool policy changes and softforks
415 2015-10-08 19:27:18 <btcdrak> BlueMatt: the attack is so bad it knocked out 1000 nodes
416 2015-10-08 19:27:19 <BlueMatt> wumpus: ack
417 2015-10-08 19:27:22 <gmaxwell> BlueMatt: Yes, another option is to just get some miners on it... has basically optimal behavior. esp as it will allow the l[Dto-ow-S malleators to do their thing.
418 2015-10-08 19:27:34 <BlueMatt> btcdrak: low-s didnt nock off nodes, mempool size did
419 2015-10-08 19:27:55 <btcdrak> fair
420 2015-10-08 19:28:01 <gmaxwell> btcdrak: people on reddit are totally confused and have mixed up the lowS stuff with the mempool flooding stuff. They're unrelated technically.
421 2015-10-08 19:28:02 <wumpus> again, let's not confuse mempool size with LowS/malleating
422 2015-10-08 19:28:03 <BlueMatt> gmaxwell: yea, maybe we should be convincing miners to do low-s malleating
423 2015-10-08 19:28:28 <morcos> btw, its not really fair to call this mempool stuffing an attack right?
424 2015-10-08 19:28:32 <gmaxwell> BlueMatt: lowS enforcement is very easy to use, as the code has been around forever and requires only a trivial patch to activate it.
425 2015-10-08 19:28:33 <morcos> aren't these all good txs
426 2015-10-08 19:28:43 <morcos> they seem to mostly reduce the utxo 100->1
427 2015-10-08 19:28:56 <BlueMatt> morcos: oh? lol
428 2015-10-08 19:29:10 <coin_trader> technically this new attack was all 'legit' transactions with over 1 satoshi per byte
429 2015-10-08 19:29:13 <gmaxwell> morcos: not sure in this case; I'd _assumed_ they were being created with the specific goal of knocking out nodes.
430 2015-10-08 19:29:17 <coin_trader> but there was just "so many" of them...
431 2015-10-08 19:29:36 <coin_trader> it's like ddos
432 2015-10-08 19:29:44 <phantomcircuit> morcos, it's clearly an attack, but yes it should shrink the utxo set
433 2015-10-08 19:29:56 <gmaxwell> But it's hard to sort out people cheering about the effects vs the intent. Doesn't really matter what it "is", all that matters is what it does. :)
434 2015-10-08 19:30:07 <wumpus> whether it's an attack or not, we need mempool limiting to protect against it (but that was last topic)
435 2015-10-08 19:30:12 <coin_trader> ^ +1
436 2015-10-08 19:30:16 <phantomcircuit> yup
437 2015-10-08 19:30:18 <gmaxwell> In any case, is there anything more to say about lowS ? I'll go get miners to run at least lowS enforcement.
438 2015-10-08 19:30:32 <wumpus> so, deploy new 0.10 and 0.11 release asap?
439 2015-10-08 19:30:34 <BlueMatt> gmaxwell: I'd prefer they do malleation
440 2015-10-08 19:30:42 <BlueMatt> wumpus: ehhhh, I'd prefer not
441 2015-10-08 19:30:44 <gmaxwell> And we'll not rush a release on that, but lowS enforcement will go out with whatever goes out next?
442 2015-10-08 19:30:50 <BlueMatt> yea
443 2015-10-08 19:31:02 <BlueMatt> gmaxwell: miners doing just lowS enforcement doesnt help
444 2015-10-08 19:31:04 <gmaxwell> BlueMatt: After you insisted to me that I don't need to review that code... ? :P
445 2015-10-08 19:31:05 <wumpus> 'whatever goes out next' will be CSV and CLTV softforks likely
446 2015-10-08 19:31:07 <sipa> of the wallet software that is presumed not to produce lows... does it deal well with malleation?
447 2015-10-08 19:31:09 <BlueMatt> if a tx is malleated, now they just dont mine it
448 2015-10-08 19:31:16 <gmaxwell> BlueMatt: it does, when coupled with other people doing lowS malleation.
449 2015-10-08 19:31:16 <wumpus> so that will couple it to softfork minor releases
450 2015-10-08 19:31:18 <BlueMatt> gmaxwell: well now I'm changing my tune since I think it may be a good solution
451 2015-10-08 19:31:29 <BlueMatt> gmaxwell: but only if they're direct peers
452 2015-10-08 19:31:31 <phantomcircuit> sipa, no that's the only reason there's a problem to start with
453 2015-10-08 19:32:04 <BlueMatt> sipa: there isnt much we can do there :(
454 2015-10-08 19:32:07 <sipa> well... what is worst to them? no confirmation, or malleated confrm?
455 2015-10-08 19:32:09 <wumpus> which is ok with me, but as I said above it may confuse people to combine softfork backports with high-porfile other (non forking) changes
456 2015-10-08 19:32:11 <gmaxwell> BlueMatt: Getting people to run unreleased code is a challenge, esp if its non-trivial.
457 2015-10-08 19:32:37 <BlueMatt> gmaxwell: I'm aware
458 2015-10-08 19:32:43 <BlueMatt> gmaxwell: they can run it on their border nodes, however
459 2015-10-08 19:32:47 <BlueMatt> no need to run it on your mining node
460 2015-10-08 19:32:58 <gmaxwell> wumpus: I think at least its similar in kind, in that its a standardness change.
461 2015-10-08 19:33:02 <wumpus> but ok - no one in favor of doing releases for lows enforcements, so that's off the map
462 2015-10-08 19:33:08 <BlueMatt> sipa: my point is, if miners are only enforcing lowS and not changing it themselves, it is malleated
463 2015-10-08 19:33:19 <sipa> BlueMatt: i don't understand?
464 2015-10-08 19:33:21 <BlueMatt> assuming someone is attacking everything, then it just means delayed + malleated confirms
465 2015-10-08 19:33:22 <wumpus> gmaxwell: consensus changes are IMO completely different from standardness changes
466 2015-10-08 19:33:41 <gmaxwell> wumpus: I think we can get 95% of the benefit of a short lowS release via a mix of asking a few miners to apply local fixes.
467 2015-10-08 19:34:05 <BlueMatt> sipa: if someone is attacking and malleates a tx to highS all over the network, miners who are enforcing will reject it and not hear about the lowS version
468 2015-10-08 19:34:08 <gmaxwell> BlueMatt: it means people running updated software (95% of transactions) become largely protected.
469 2015-10-08 19:34:09 <BlueMatt> others will take it and mine it
470 2015-10-08 19:34:26 <btcdrak> I agree with BlueMatt, miners should be fixing the transactions as well, it solves a lot of the disruption.
471 2015-10-08 19:34:27 <BlueMatt> gmaxwell: nope
472 2015-10-08 19:34:40 <gmaxwell> please stop. The code to go and rewrite transactions is not trivial.
473 2015-10-08 19:34:43 <BlueMatt> gmaxwell: only if the miners have a peer with someone who knows the lowS version
474 2015-10-08 19:35:15 <BlueMatt> that's true...ok, well at a minimum miners who are doing highS should have 1 border node that does rewriting
475 2015-10-08 19:35:19 <gmaxwell> BlueMatt: sure. I don't think this is a huge assumption. Esp assuming the existance of some small amount of lowS converter nodes.
476 2015-10-08 19:35:20 <BlueMatt> or should addnode my node that does it
477 2015-10-08 19:35:22 <BlueMatt> or something
478 2015-10-08 19:35:24 <sipa> i don't think that highs->lows would be hard to add as a patch to mempool acceptance
479 2015-10-08 19:35:27 <gmaxwell> Sure sure, I can suggest that.
480 2015-10-08 19:35:27 <morcos> gmaxwell: i have to admit i don't understand how a few miners running lowS enforcement solves the problem
481 2015-10-08 19:35:41 <morcos> what about the rest of the miners?
482 2015-10-08 19:35:58 <BlueMatt> morcos: it doesnt solve it, but means you're proportionally less likely to suffer it
483 2015-10-08 19:36:04 <morcos> yeah ok
484 2015-10-08 19:36:15 <gmaxwell> morcos: thats the 'largely'. A 'few miners' may mean 75% of the hashpower.
485 2015-10-08 19:36:27 <gmaxwell> the attack is also not so interesting when its much less effective.
486 2015-10-08 19:36:32 <bsm117532> A better solution is not to relay highS transactions, no?
487 2015-10-08 19:36:43 <gmaxwell> And even the remaining hashpower will often hear the lowS first.
488 2015-10-08 19:36:44 <BlueMatt> gmaxwell: bitcoin-seednode.bluematt.me has reasonable relay/maxconnections capacity and is running it
489 2015-10-08 19:36:53 <gmaxwell> bsm117532: Git master already does this.
490 2015-10-08 19:37:14 <phantomcircuit> gmaxwell, it would be just as or more effective to do minor releases of the backported lows change
491 2015-10-08 19:37:24 <wumpus> bsm117532: that is the code that is currently merged in 0.10, 0.11, and master (pull #6769)
492 2015-10-08 19:37:35 <wumpus> I was suggesting to do a release with that, but people haev other plans
493 2015-10-08 19:37:42 <gmaxwell> bsm117532: As to backports that will eventually become subsiquent releases. But that alone is not sufficient because it will still block ~5% of all transactions (at this moment), and because it is not in a release version.
494 2015-10-08 19:38:05 <phantomcircuit> i dont see any reason to try to target miners
495 2015-10-08 19:38:13 <btcdrak> wumpus: were there objections to releasing that as is?
496 2015-10-08 19:38:15 <gmaxwell> I think doing a release that just does that might be okay, but since nodes are actually going offline due to mempool stuff I feel like it's missing the forrest for the trees.
497 2015-10-08 19:38:20 <phantomcircuit> that's just going to confuse people when their transactions aren't mined
498 2015-10-08 19:38:22 <wumpus> btcdrak: yes, at least from BlueMatt and gmaxwell
499 2015-10-08 19:38:36 <phantomcircuit> if they're rejected by a node they relay to at least maybe they'll figure it out
500 2015-10-08 19:38:49 <wumpus> I prefer clarity too phantomcircuit
501 2015-10-08 19:39:11 <gmaxwell> wumpus: I am not opposed. I do not think it is essential right now. And I am somewhat concerned about update exhaustion with what might end up being three mandatory updates in short succession.
502 2015-10-08 19:39:22 <BlueMatt> phantomcircuit: yes, that is why I was saying it must be coupled with each miner who is doing it running a malleate-to-low-s node somewhere so that they dont just reject
503 2015-10-08 19:39:24 <BlueMatt> but also mine them
504 2015-10-08 19:39:30 <gmaxwell> phantomcircuit: in practice that isn't how much software works.
505 2015-10-08 19:39:30 <wumpus> gmaxwell: people can decide for themselves whether to update or not
506 2015-10-08 19:39:33 <sipa> how about we do backports in the stable branches, but don't release, and instead ask around and look whether the highS wallets on the network goes down?
507 2015-10-08 19:39:51 <gmaxwell> sipa: we can no longer measure it due to attacks.
508 2015-10-08 19:39:52 <sipa> oh... i guess with a ->highS malleation going on, that's harder to observe
509 2015-10-08 19:39:54 <sipa> right
510 2015-10-08 19:39:58 <wumpus> it is already backported to the stable branches
511 2015-10-08 19:40:11 <wumpus> the only thing that has to be done is stage a relase (or not)
512 2015-10-08 19:40:47 <btcdrak> gmaxwell: I dont think users are going to object to seeing more frequent security/maintenance releases. If anything it would be good PR
513 2015-10-08 19:40:56 <morcos> i'd vote for doing one release before 12, with lowS enforcement, increased min relay fee and CLTV soft fork
514 2015-10-08 19:41:03 <dstadulis> ### TIMECHECK 66% through the meeting
515 2015-10-08 19:41:03 <wumpus> any other topics?
516 2015-10-08 19:41:22 <gmaxwell> My preference is along the lines of what morcos suggests.
517 2015-10-08 19:41:31 <gmaxwell> (actually, exactly what he suggests)
518 2015-10-08 19:41:38 <BlueMatt> I dont disagree, just suggesting that we not rush into it
519 2015-10-08 19:41:43 <wumpus> ok - target for the releases on 0.10.x and 0.11.x is end of this month then
520 2015-10-08 19:41:46 <gmaxwell> and a little more delay does give more time for other things to updat.e
521 2015-10-08 19:41:55 <petertodd> along those lines, I just rebased all the CLTV branches
522 2015-10-08 19:42:01 <wumpus> then see whether CLTV and CSV make it in
523 2015-10-08 19:42:04 <dstadulis> wumpus: Next topics: CLTV backport reviews and CSV reviews
524 2015-10-08 19:42:06 <wumpus> as proposed last week
525 2015-10-08 19:42:18 <gmaxwell> Basically there are wallet vendors who totally missed the first generation attacks, and the bip62 discussion, and "hey you need to lowS" was news to them..
526 2015-10-08 19:42:45 <morcos> well i have to say i'm a NACK on CSV for release this month.  i just don't think they are settled and ready enough.
527 2015-10-08 19:42:59 <morcos> maaku, were you considering changing the semantics to save more bits?
528 2015-10-08 19:43:07 <wumpus> #topic CLTV backport reviews and CSV reviews
529 2015-10-08 19:43:11 <petertodd> morcos: I was just reviewing the code today, and it struck me that there isn't even clarity on what everything looks like when all three pull-reqs are merged
530 2015-10-08 19:43:39 <wumpus> I also think CSV is quite risky to deploy on such short notice
531 2015-10-08 19:43:47 <morcos> petertodd: yeah agreed with that too.  and the bug sdaftuar found was actually just an assumption of what would be a bug when the soft fork pulls were created, which don't exist yet
532 2015-10-08 19:43:57 <gmaxwell> I am concerned that the CLTV sequence restriction violations are currently not quite non-standard. (unless I've missed something)
533 2015-10-08 19:43:57 <sipa> we can do mempool-only CSV/sequence
534 2015-10-08 19:43:58 <btcdrak> morcos: there are loads of bits free, set the MSB and remaining 31 bits are free.
535 2015-10-08 19:44:07 <gmaxwell> er CSV!
536 2015-10-08 19:44:09 <gmaxwell> (not CLTV)
537 2015-10-08 19:44:19 <gmaxwell> (sorry, autopilot)
538 2015-10-08 19:44:36 <morcos> but there are not loads of bits free if you want to keep the CSV and nSequence meaning and yet use some more of the bits for another soft fork
539 2015-10-08 19:44:37 <wumpus> sipa: sure, but there's no reason to do that in an intermediate minor release
540 2015-10-08 19:44:41 <morcos> it uses more than it needs to
541 2015-10-08 19:44:52 <morcos> gmaxwell: it requires increased tx version
542 2015-10-08 19:44:53 <wumpus> sipa: I'm all for mempool only CSV in say, master, when it's ready to merge
543 2015-10-08 19:45:04 <petertodd> gmaxwell: sequence restriction violations?
544 2015-10-08 19:45:06 <morcos> i think the semantics should change
545 2015-10-08 19:45:07 <wumpus> we followed the same for CLTV
546 2015-10-08 19:45:09 <gmaxwell> morcos: oh derp! there we go, sorry.
547 2015-10-08 19:45:40 <gmaxwell> (I did know that... had just forgotten the implication)
548 2015-10-08 19:45:41 <GreenIsMyPepper> afaik it's worst-case half the bits available?
549 2015-10-08 19:45:41 <wumpus> ok - so CSV semantics are n't even finalized yet?
550 2015-10-08 19:45:42 <petertodd> gmaxwell: OP_CLTV is itself non-standard, so any tx using that behavior at all will immediately be dropped
551 2015-10-08 19:45:52 <petertodd> wumpus: I would say no, IMO
552 2015-10-08 19:45:56 <gmaxwell> petertodd: I know, I autotyped that. :P
553 2015-10-08 19:45:57 <morcos> no
554 2015-10-08 19:45:58 <btcdrak> indeed, softfork deploymment aside, we can get the mempool PRs for CSV merged.
555 2015-10-08 19:46:21 <morcos> last i talked to maaku i believe he wanted to change the semantics
556 2015-10-08 19:46:21 <sipa> wumpus: i think the current proposal is final by the author... things can change if there are concerns of course
557 2015-10-08 19:46:25 <sipa> morcos: ?
558 2015-10-08 19:46:32 <sipa> morcos: afaik that's long done
559 2015-10-08 19:46:44 <petertodd> btcdrak: well... I'm not sure that's a good thing, because it'd make changing those semantics later tricky - CLTV had the same issue, and the plan was we'd pick a new opcode if that happened
560 2015-10-08 19:46:50 <btcdrak> morcos: I'm not sure he did want to change, he was just taking on board what you were saying.
561 2015-10-08 19:47:05 <morcos> he and i discussed on IRC the other day, and he had thought it was a soft fork to change time resolution from 1s to 512s for instance and not the other way around
562 2015-10-08 19:47:08 <petertodd> sorry, I need to go :(
563 2015-10-08 19:47:16 <morcos> btcdrak: i agree it wasn't 100% clear
564 2015-10-08 19:47:25 <wumpus> meeting only has 15 minutes to go
565 2015-10-08 19:47:28 <gmaxwell> okay, so the takeaway is that this needs to get clarified.
566 2015-10-08 19:47:31 <GreenIsMyPepper> CSV can similarly use a different opcode, half the bits with nSequence?
567 2015-10-08 19:48:09 <sipa> CSV is a different opcode...
568 2015-10-08 19:48:10 <morcos> i think its really close to good, but it just seems a bit odd to me to use 25 bits for time, when we might want to save those for something else later.
569 2015-10-08 19:48:11 <btcdrak> GreenIsMyPepper: more complex than that, txver=2, msb not set, then the remaining bits are used according to bip68, otherwise all bits are free
570 2015-10-08 19:48:12 <gmaxwell> GreenIsMyPepper:  CSV has an additional constraint, becuase it is both the nlocktime and the checklocktime parts that we're discussing.
571 2015-10-08 19:48:26 <btcdrak> morcos: ok, let's get maaku to clarify this week
572 2015-10-08 19:48:34 <gmaxwell> We cannot simply 'use another optcode' to change the nSequence interpertation.
573 2015-10-08 19:48:36 <morcos> also we should all chime in on what we think
574 2015-10-08 19:48:40 <GreenIsMyPepper> yes, i mean the nSequence part is more restrained, but the impact w/r/t CSV is similar to CLTV
575 2015-10-08 19:48:55 <gmaxwell> GreenIsMyPepper: yes, other than the sequence part, the two are almost the same.
576 2015-10-08 19:49:11 <morcos> if we can save 14 bits of nSequence for further soft forks regardles of time/block sequence type, that seems great
577 2015-10-08 19:49:12 <GreenIsMyPepper> ok
578 2015-10-08 19:49:27 <btcdrak> I know a number of people are still making their way through the locktime PRs (3 of them), so we'll get more feedback this week.
579 2015-10-08 19:49:38 <gmaxwell> GreenIsMyPepper: More review efforts from you on CSV would be super helpful.
580 2015-10-08 19:49:48 <btcdrak> for reference the PRs are as follows
581 2015-10-08 19:49:52 <btcdrak> Mempool-only CHECKSEQUENCEVERIFY https://github.com/bitcoin/bitcoin/pull/6564
582 2015-10-08 19:49:52 <btcdrak> Mempool-only Median time-past as endpoint for lock-time calculations https://github.com/bitcoin/bitcoin/pull/6566
583 2015-10-08 19:49:52 <btcdrak> Mempool-only sequence number constraint verification https://github.com/bitcoin/bitcoin/pull/6312
584 2015-10-08 19:49:58 <GreenIsMyPepper> gmaxwell: ok i've been taking a look yesterday
585 2015-10-08 19:50:05 <GreenIsMyPepper> btcdrak: thanks
586 2015-10-08 19:50:08 <gmaxwell> GreenIsMyPepper: K.
587 2015-10-08 19:50:57 <gmaxwell> Can we put my "Minor OT notice" from earlier in the notes. This is an ecosystem threat with the potential to cause millions of dollars in losses that needs higher visibility; though it's not a bitcoin core / bitcoin network issue.
588 2015-10-08 19:51:04 <wumpus> ok, any other topics to discuss?
589 2015-10-08 19:51:09 <dstadulis> gmaxwell will do
590 2015-10-08 19:51:25 <wumpus> we can make it the topic gmaxwell
591 2015-10-08 19:51:35 <morcos> jgarzik isn't here i guess
592 2015-10-08 19:51:46 <morcos> i'd like to make it clear who exactly are the moderators for the mailing lists
593 2015-10-08 19:51:52 <morcos> and then i can hound them
594 2015-10-08 19:51:56 <wumpus> if there's more to discuss about it
595 2015-10-08 19:52:01 <btcdrak> ping warren:
596 2015-10-08 19:52:12 <morcos> b/c i know there is not another list yet, but there is some stuff that is inapproiate for any list happening
597 2015-10-08 19:52:27 <btcdrak> warren: has a meeting with LF today btw for the new list.
598 2015-10-08 19:52:29 <morcos> i'm this clsoe to unsubscribing myself
599 2015-10-08 19:52:43 <gmaxwell> wumpus: I think htere is nothing more to discuss. Common, critical, JS code is broken that may cause the generation of incorrect pubkeys (among other issues). Anyone who cares for a JS implementation should read that PR.
600 2015-10-08 19:52:47 <warren> Had a call with them this morning.  The plan is now:
601 2015-10-08 19:52:52 <warren> 1) create bitcoin-discuss list
602 2015-10-08 19:52:53 <btcdrak> morcos: warren assures we'll have the new list this week.
603 2015-10-08 19:53:02 <wumpus> morcos: +1
604 2015-10-08 19:53:04 <warren> 2) we need to decide who are moderators for that and bitcoin-dev list
605 2015-10-08 19:53:17 <wumpus> #topic bitcoin-discuss mailing list
606 2015-10-08 19:53:47 <wumpus> gmaxwell: ok, clear
607 2015-10-08 19:53:58 <warren> 3) They will also host a new domain name with a static web page simply listing all the lists, list policies and whatever other material we put there.  We maintain it in github somewhere with pull requests and they'll auto-publish whatever is signed with certain GPG sigs.
608 2015-10-08 19:54:57 <warren> Previously discussed moderators was jgarzik, elombrozo, johnathan, btcdrak, are we still good with this list?
609 2015-10-08 19:55:03 <wumpus> thanks for letting us know warren
610 2015-10-08 19:55:30 <warren> Mailman 2 has the drawback of a shared password for moderators, this will become better in ~6 months when they upgrade to Mailman 3 where each user has their own password.
611 2015-10-08 19:55:54 <wumpus> sounds good to me
612 2015-10-08 19:56:00 <warren> Should be OK to allow more moderators.  We probably should agree on a moderation policy where mod actions identify who did it, otherwise there's no transparency?
613 2015-10-08 19:56:08 <GreenIsMyPepper> has there been general guidelines on what will be ontopic on bitcoin-discuss? is economics-politics ontopic for instance?
614 2015-10-08 19:56:25 <warren> I nominate GreenIsMyPepper as another moderator.
615 2015-10-08 19:56:39 <btcdrak> warren: it's important moderators act with one voice. If mod A bans user B, then mod C should not undo that unilaterally
616 2015-10-08 19:56:56 <warren> how about we have a separate meeting to discuss the list and moderation policy
617 2015-10-08 19:57:02 <warren> don't need to spend time here
618 2015-10-08 19:57:13 <wumpus> this meeting is about to end
619 2015-10-08 19:57:18 <btcdrak> warren: agreed.
620 2015-10-08 19:57:30 <warren> who else should be moderator?
621 2015-10-08 19:57:50 <warren> this decision need not be made now
622 2015-10-08 19:57:53 <wumpus> but I think we discussed everything there was to do, so that's good
623 2015-10-08 19:58:24 <warren> Could a few of the devs agree to join the moderator meeting because it is about agreeing on list policy?
624 2015-10-08 19:58:29 <wumpus> I don't know much about moderating mailinglists, but isn't this enough moderators for now?
625 2015-10-08 19:58:45 <wumpus> too many will be like headless chickens
626 2015-10-08 19:58:46 <warren> Sure, I'm more concerned that a few devs join the policy setting meeting.
627 2015-10-08 19:59:03 <warren> Let the moderators implement the policy that is set and written down.
628 2015-10-08 19:59:17 <wumpus> I'm fine with attending, depending on when it is
629 2015-10-08 19:59:18 <morcos> you have several devs in your list
630 2015-10-08 19:59:35 <warren> what time is good tomorrow for a list policy discussion meeting?
631 2015-10-08 19:59:48 <btcdrak> I'll come whatever the time.
632 2015-10-08 20:00:26 <warren> I propose same time tomorrow for the list policy meeting.
633 2015-10-08 20:00:34 <morcos> oh i have one quick additional top
634 2015-10-08 20:00:34 <warren> Is that bad for anyone?
635 2015-10-08 20:00:43 <wumpus> hmm I don't like meetings on friday evenings
636 2015-10-08 20:00:53 <warren> would you rather do this Monday?
637 2015-10-08 20:01:16 <wumpus> yes, absolutely, but never mind me
638 2015-10-08 20:01:36 <morcos> oh hm, petertodd left already, but i saw hes talking about resurrecting RBF again and I wanted to know what the status of opt-in RBF was.  are there any objections to that method of moving forward?  isn't it strictly superior?
639 2015-10-08 20:01:38 <warren> ok Monday same time for list policy meeting, move on.
640 2015-10-08 20:01:42 <wumpus> #endmeeting
641 2015-10-08 20:01:43 <lightningbot`> Log:            http://www.erisian.com.au/meetbot/bitcoin-dev/2015/bitcoin-dev.2015-10-08-18.59.log.html
642 2015-10-08 20:01:43 <lightningbot`> Meeting ended Thu Oct  8 20:01:43 2015 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
643 2015-10-08 20:01:43 <lightningbot`> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-dev/2015/bitcoin-dev.2015-10-08-18.59.html
644 2015-10-08 20:01:43 <lightningbot`> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-dev/2015/bitcoin-dev.2015-10-08-18.59.txt
645 2015-10-08 20:03:49 <btcdrak> looks like we missed a few actionable items with meetbot, better luck next time
646 2015-10-08 20:04:58 <gmaxwell> morcos: I have the impression that opt in RBF solves problems that PT doesn't much care about, and some of us that care more may need to put some more gas behind it.
647 2015-10-08 20:05:58 <morcos> gmaxwell: ok, i mean i understand why he didn't love FSS-RBF, but i'm not sure i even know what the downside is of opt-in.  but i dont' remember the technical specifics, how do you specify opt-in
648 2015-10-08 20:06:51 <morcos> ha, an nSequence bit
649 2015-10-08 20:10:10 <nwilcox> Is this meeting every Thursday from 19:00-20:00 UTC ?
650 2015-10-08 20:12:32 <dstadulis> yes
651 2015-10-08 20:12:36 <dstadulis> nwilcox yes
652 2015-10-08 20:13:58 <morcos> hmm so i guess he was thinking everything non-maxint as opt'ing in to RBF.  so in particular you couldn't use the CSV and nSequence functionality and prevent RBF.  but you're likely doing some replacement anyway in that case, i guess that seems pretty reasonable to me
653 2015-10-08 20:14:09 <morcos> mabye that is what he's planning on doing now?
654 2015-10-08 20:14:35 <warren> I'm creating a meeting invite for Monday, PM me your address if you want the meeting invite.
655 2015-10-08 20:14:45 <warren> Otherwise just show up Monday at 19:00 UTC
656 2015-10-08 21:10:18 <maaku> morcos: as far as I'm aware the only downside is burning bits
657 2015-10-08 21:11:10 <CodeShark> I apologize for missing the weekly dev meeting
658 2015-10-08 21:11:25 <morcos> maaku: didn't mean to put any words in your mouth about BIP 68, but were you considering a change to the semantics?
659 2015-10-08 21:13:20 <morcos> it seems to me it would be easier to address critcisms like petertodds about whether or not its a good ides to use our nSequence bits for CSV, if we weren't using as many...
660 2015-10-08 21:13:38 <maaku> morcos: you convinced me that my reason for insisting on 1s granularity, as I did on the mailing list, was flawed
661 2015-10-08 21:14:14 <maaku> so that leaves me as indifferent. i kinds wanted to feel out other people's opinions on this before making the change, but it seems like that wasn't settled in the meeting
662 2015-10-08 21:14:32 <morcos> yeah i don't think other people seemed aware of our discussion, other than btcdrak
663 2015-10-08 21:15:05 <CodeShark> regarding RCLTV, isn't it possible to implement it by checking against the block height or block median time directly?
664 2015-10-08 21:15:34 <morcos> i think the other question is if we were to make a change, does it make sense to move the 17 bits used by BIP68 to be the low order 17 bits completely
665 2015-10-08 21:16:01 <morcos> i guess that would be kind of annoying if we wanted to go to finer time granularity, but certainly doable
666 2015-10-08 21:16:07 <maaku> CodeShark: that approach is extremely suboptimal because you need to do full script validation to know the validity conditions for the script
667 2015-10-08 21:16:34 <maaku> the BIP 68 approach you simply look at the transaction and know, same as with nLockTime
668 2015-10-08 21:17:47 <CodeShark> hmm...I see
669 2015-10-08 21:17:53 <maaku> It's an interesting property of bitcoin that aside from double-spend, a transaction can be fully validated without block chain context. it would be a shame to break that
670 2015-10-08 21:18:17 <morcos> maaku: but isn't that broken by needing the blockheights of the inputs?
671 2015-10-08 21:19:04 <maaku> morcos: in the same way that nLockTime is broken by needing the block height / time of the enclosing block
672 2015-10-08 21:19:30 <CodeShark> I think it's an interesting property...but not necessarily a good one
673 2015-10-08 21:19:41 <CodeShark> having access to more context makes scripts a lot more powerful
674 2015-10-08 21:19:50 <maaku> CodeShark: ? it has definate advantages
675 2015-10-08 21:19:50 <morcos> ok similar way i guess., but a bit more invasive
676 2015-10-08 21:19:57 <maaku> you only need run script validation -once-
677 2015-10-08 21:20:12 <maaku> even if the transaction is currently locked, it will finish script execution
678 2015-10-08 21:21:13 <morcos> yeah so thats the difference right
679 2015-10-08 21:21:29 <morcos> to verify locktime after script validation, you only need to look at one field
680 2015-10-08 21:21:30 <gmaxwell> CodeShark: it's possible but it makes script validity no longer a function of the transaction, which means that e.g. mempool state must be able to invalidate script validity.
681 2015-10-08 21:21:46 <morcos> well, i guess you still don't need to look at the scripts for BIP68
682 2015-10-08 21:22:43 <morcos> gmaxwell: do you have any opinion on the different ways bits could be used in BIP68
683 2015-10-08 21:24:03 <morcos> i apologize if i'm rehashing old discussions...  but it seems that the biggest outstanding objection to all the CSV related pulls is their use of nSequence bits, so why not make that as minimal as possible.
684 2015-10-08 21:24:24 <CodeShark> gmaxwell: the mempool issues could be resolved by considering the best known height and median time, no?
685 2015-10-08 21:26:09 <CodeShark> or the estimated height and median time when the transaction will confirm
686 2015-10-08 21:26:32 <CodeShark> the mempool-only BIP68 already does that, no?
687 2015-10-08 21:27:01 <gmaxwell> It's an architectural question. Script is a digital signature system, the signatures return true if the data under the signature is acceptable. The data being signed in the transaction.   The validity of a signature is a pure function. (and, e.g. can be cached).
688 2015-10-08 21:27:07 <maaku> I would appreciate someone chiming in about whether to use 1s or 512s granularity for BIP 68
689 2015-10-08 21:27:47 <gmaxwell> In the case of CLTV this allowed us to be very confident about the safty and correctness of the design... as absolutely no changes to mempool management was needed, because nothing changed there.. it's just nlocktime.
690 2015-10-08 21:28:20 <CodeShark> maaku: I think getting out the door with CSV is sufficiently important and urgent that I don't want to hold it up much longer. but I'm thinking that in the future we might find another mechanism that does not require the nSequence field at which time we can deprecate CSV and recover 31 bits
691 2015-10-08 21:29:24 <btcdrak> maaku, it's really not worth getting stuck on. I'd go for 512s given blocktimes are so long anyhow.
692 2015-10-08 21:29:29 <CodeShark> I understand the safety concerns regarding bigger changes to script validation
693 2015-10-08 21:29:51 <CodeShark> I'm just questioning whether the limitations we currently have are fundamental or just due to the way it's implemented
694 2015-10-08 21:30:06 <gmaxwell> CodeShark: I think it's a good design, even ignoring the software.
695 2015-10-08 21:30:18 <gmaxwell> As, e.g. it allows fully caching script results (though we do not today)
696 2015-10-08 21:30:43 <gmaxwell> and doing so in a way which is safeish.
697 2015-10-08 21:30:47 <maaku> CodeShark: FWIW morcos showed me that 512s granularity is the more permissive choice
698 2015-10-08 21:31:44 <CodeShark> our time resolution is horrible anyhow :p
699 2015-10-08 21:32:16 <CodeShark> and we can always increase precision, right?
700 2015-10-08 21:32:18 <CodeShark> but not decrease
701 2015-10-08 21:33:41 <CodeShark> gmaxwell: setting aside performance optimization issues for a moment, the most general approach to these issues seems to be op codes that push block header information into scripts
702 2015-10-08 21:33:58 <morcos> yes my vote is to set the highest 15 bits to 0 to indicate BIP 68 view of nSequence valididy.  16th highest bit distinguishes between block and time sequence type, and the 2 low order bytes encode the sequence number (as a multiple of 512 seconds for time)
703 2015-10-08 21:34:01 <CodeShark> we also need to worry about reorgs, but I think that could be handled
704 2015-10-08 21:34:33 <CodeShark> also, we can't strictly push onto the stack with a NO_OP
705 2015-10-08 21:34:35 <gmaxwell> CodeShark: _push_ information into scripts is really a very bad divergence from the computational model as "scripts are verification, a digital signature system, and not a programming language"
706 2015-10-08 21:35:00 <CodeShark> gmaxwell: the satoshi script sure looks like a programming language ;)
707 2015-10-08 21:35:20 <CodeShark> a low level one, but a language nonetheless
708 2015-10-08 21:35:30 <gmaxwell> CodeShark: it doesn't, in a lot of ways. It's just commonly misunderstood, that way by those less familar with other things.
709 2015-10-08 21:35:38 <gmaxwell> it's not that script isn't programming.
710 2015-10-08 21:35:57 <gmaxwell> It's that _script in the network_ isn't computation. It's verification. The signer did the computation, we're all just checking that they did it right.
711 2015-10-08 21:36:16 <CodeShark> yes understood - we're not trying to do what ethereum is trying to di
712 2015-10-08 21:36:17 <CodeShark> *do
713 2015-10-08 21:36:23 <gmaxwell> And without that model you can't really fit in things like MAST, (or SNARKS, for that model)
714 2015-10-08 21:37:01 <gmaxwell> and handing it the pure way is what does things like makes batch EC verification possible.
715 2015-10-08 21:38:35 <CodeShark> but CHECKSIG already does require greater context, no?
716 2015-10-08 21:38:54 <CodeShark> it must hash other parts of the transaction
717 2015-10-08 21:39:39 <CodeShark> it doesn't require block context
718 2015-10-08 21:39:47 <CodeShark> but it still requires data outside the script itself
719 2015-10-08 21:39:51 <gmaxwell> CodeShark: The limit of the context is the transaction. Nothing has access outside of that today.
720 2015-10-08 21:40:20 <morcos> maaku: i have to run for now.  i could respond to the mailing list with my thoughts, but i didn't want to start conversation on a whole different tangent if its not a popular direction to go.  do you have an opinion on making the high order bits the unused ones?
721 2015-10-08 21:40:22 <CodeShark> but also taking the block context into account doesn't seem like that big of a stretch (other than mempool issues)
722 2015-10-08 21:40:29 <gmaxwell> Also, if you ignore double spends, bitcoin works without blocks.
723 2015-10-08 21:40:34 <CodeShark> lol
724 2015-10-08 21:40:49 <gmaxwell> CodeShark: its a big streach in that it constantly changes, as blocks show up, and isn't controlled by the signer.
725 2015-10-08 21:41:04 <gmaxwell> CodeShark: don't laugh, that fact is also part of what makes lightning possible. :)
726 2015-10-08 21:42:10 <CodeShark> well, lightning still requires proving the anchors are not double-spends (or that the outputs even exist in the first place, for that matter)
727 2015-10-08 21:42:48 <nwilcox> Why isn't BIP 65 in the Accepted state?
728 2015-10-08 21:43:24 <gmaxwell> nwilcox: because its not widely deployed in the network.
729 2015-10-08 21:43:58 <gmaxwell> nwilcox: BIP acceptance means something is a defacto standard.
730 2015-10-08 21:45:21 <CodeShark> gmaxwell: I understand that adding more context to scripts can significantly complicate matters - I just wonder whether it might eventually be possible to overcome these obstacles somehow since it could potentially make scripts a lot more powerful. and yes, I understand we don't want to think of scripts as a general purpose programming language
731 2015-10-08 21:45:38 <gmaxwell> I think it makes them a lot less powerful, actually.
732 2015-10-08 21:46:43 <CodeShark> gmaxwell, consider hypothetically an OP CODE that pushes the current block height onto the stack
733 2015-10-08 21:47:00 <CodeShark> and ignore the reorg issues for a moment
734 2015-10-08 21:47:18 <gmaxwell> CodeShark: is of negative value compared to an op code that takes the height as an input and an opcode that verifies the agreement.
735 2015-10-08 21:47:34 <nwilcox> gmaxwell: In that case it's too bad the BIP format doesn't require a "deployment status".
736 2015-10-08 21:47:51 <nwilcox> What I want to know is "how likely is it that BIP 65 will become a well-adopted standard"?
737 2015-10-08 21:48:00 <CodeShark> hight
738 2015-10-08 21:48:08 <CodeShark> err
739 2015-10-08 21:48:12 <CodeShark> high likelihood
740 2015-10-08 21:48:17 <gmaxwell> nwilcox: the BIP can't tell you that regardless. :) (plus its authors are the wrong people to ask, most likely!)
741 2015-10-08 21:48:20 <nwilcox> And I guess well-adopted here means accepted by majority miners. ;-)
742 2015-10-08 21:49:17 <CodeShark> gmaxwell, an opcode that verifies the agreement can force the inequality to only work in one direction...so it can help address some of the reorg issues, I suppose
743 2015-10-08 21:49:51 <CodeShark> but in principle we could still support an inequality in the other direction and just require maturity of 100
744 2015-10-08 21:50:03 <CodeShark> to get around reorg issues
745 2015-10-08 21:50:17 <nwilcox> CodeShark: The BIP says "Upgrade / Testing Plan: TBD"...
746 2015-10-08 21:50:30 <CodeShark> nwilcox: it still has not been deployed
747 2015-10-08 21:50:43 <nwilcox> Is there a known soft-fork signaling mechanism for it, or is that blocked on softfork signaling improvements?
748 2015-10-08 21:50:59 <CodeShark> the trigger is practically in the code already...just a couple more lines of code and it's off
749 2015-10-08 21:51:35 <nwilcox> CodeShark: Ok, thanks.
750 2015-10-08 21:52:33 <nwilcox> So is there no place in the BIP format to mention that? (If not, what's the purpose of the Upgrade Plan section?)
751 2015-10-08 21:53:04 <gmaxwell> CodeShark: it's not even a question of directionality, it's a question of the script being verification of computation the signer performed vs random code execution.. and script validity being a pure, cachable, function on the transaction... that it be veriable in arbritary order etc.
752 2015-10-08 21:54:05 <gmaxwell> (I mean, reorg safty is good too.)
753 2015-10-08 21:55:07 <maaku> morcos: I prefer using the high order bits for relative lock-time because that lets the unused bits harmlessly pass through CSV for future verification
754 2015-10-08 21:55:39 <maaku> i see no benefit in terms of future extensibility by moving the unused bits to the high-order range
755 2015-10-08 21:57:32 <morcos> maaku: i suppose it may just be a preference thing.  the only real difference is whether we are using up half of the bit space or 1/32,000 but that seems relatively minor.
756 2015-10-08 21:57:48 <gmaxwell> CodeShark: I am in meetings, but I'll dedicate some time later to convince you of this. :P
757 2015-10-08 21:58:10 <gmaxwell> CodeShark: (or to let you convince me of otherwise!)
758 2015-10-08 21:58:11 <CodeShark> gmaxwell: there are two issues here - the directional issue is only regarding reorgs
759 2015-10-08 21:58:24 <CodeShark> the other issue is more serious, though :)
760 2015-10-08 21:58:36 <gmaxwell> right. Directionality can be very important; but aren't related to script being computation vs verification.
761 2015-10-08 21:59:17 <morcos> maaku: as we discussed we'll probably need masking to do the comparisons anyway right...  but i think both versions ought to give you full flexibility to do whatever you want with the unused 14 bits (inside of the CSV framework)
762 2015-10-08 21:59:49 <btcdrak> morcos: maaku: so do we have agreement now?
763 2015-10-08 21:59:54 <morcos> if they were high order bits you would just redefine CSV to be defined by high order 10 bits set to 0 and you look at low 17 if you wanted to add 5 bits for some other soft fork
764 2015-10-08 22:00:03 <maaku> morcos: eh, no the question is are we more likely to expand nSequence in a way that requires simultaneous support for relative lock-time or not?
765 2015-10-08 22:00:05 <morcos> btcdrak: i don't think any one else has chimed in
766 2015-10-08 22:00:20 <petertodd> morcos: my plan re: RBF was to take my opt-in full-RBF patch w/ FSS-RBF otherwise and rebase it for v0.12 once the other mempool stuff is merged; my guess is the work required to do this will be small, with the one exception that all my unit tests use python-bitcoinlib and are separate to the existing RPC framework (I don't have time to rewrite that)
767 2015-10-08 22:00:21 <morcos> maaku: yes, understood, thats doable in either case
768 2015-10-08 22:00:36 <btcdrak> morcos: I think we're splitting hairs.
769 2015-10-08 22:00:59 <morcos> ok i dont' care about which bits... i'm 99.9% convinced low order is fine
770 2015-10-08 22:01:06 <morcos> but i do care about how many
771 2015-10-08 22:01:40 <btcdrak> morcos: yes, so I think we agree 512s resolution is fine
772 2015-10-08 22:01:43 <morcos> petertodd: ah ok, so its opt-in, thats what i like...
773 2015-10-08 22:02:06 <btcdrak> petertodd: +1 for optin
774 2015-10-08 22:02:10 <petertodd> maaku: I'd kinda lean towards 512s resolution, in part because it sends the irght message about what's possible!
775 2015-10-08 22:02:20 <morcos> ok sorry i really have to go now
776 2015-10-08 22:02:26 <maaku> morcos: well if we change CSV to mask off bits not used for relative lock-time, then it would not matter, yes
777 2015-10-08 22:02:39 <maaku> that's not what the code does right now though, but it's a sane question to ask
778 2015-10-08 22:02:41 <btcdrak> maaku: good.
779 2015-10-08 22:04:06 <petertodd> morcos: well, I'll definitely propose a pull-req with a CLI flag to make it always full, but yeah, default to opt-in via nSequence (and specifically, nSequence <= maxint-2 so you can still use nLockTime)
780 2015-10-08 22:07:45 <maaku> morcos: so your proposal above makes it impossible to add another use of nSequence bits that is simultaneously combined with BIP 68 semantics
781 2015-10-08 22:10:08 <maaku> morcos: rather than requiring all high-order bits to be zero, what about requiring just a specific one to be zero and masking the rest?
782 2015-10-08 22:11:58 <BlueMatt> msg gavinandresen ping
783 2015-10-08 22:12:03 <BlueMatt> heh
784 2015-10-08 22:12:27 <maaku> so bits 0..15 are the relative locktime, bit 30 determines units (0: height, 1: time w/ 512s granularity), and bit 31 toggles BIP 68 (0: on, 1: off)
785 2015-10-08 22:12:41 <maaku> bits 16..29 are masked off and can take any value
786 2015-10-08 22:22:20 <btcdrak> maaku: +1
787 2015-10-08 22:24:58 <maaku> maybe the units bit could be bit 16 instead of 30. I'll think on that or see what comes naturally out of the code
788 2015-10-08 22:26:03 <CodeShark> lol - the nSequence field is going to look like an IC wiring diagram :p
789 2015-10-08 22:26:18 <CodeShark> a pinout
790 2015-10-08 22:27:01 <maaku> design by committee...
791 2015-10-08 22:28:33 <btcdrak> LOL
792 2015-10-08 22:29:09 <btcdrak> maybe we can do an FPGA prototype before fabbing our own ASICs
793 2015-10-08 22:59:05 <Luke-Jr> maaku: max maturity period is ~1.25 years?
794 2015-10-08 23:01:12 <maaku> approximately
795 2015-10-08 23:02:14 <maaku> a very conservative number actually, since I had trouble finding anyone with needs for >30days