1 2015-10-15 04:11:31 <shesek> does anyone know of an API that takes a date and returns the btc/usd exchange rate (24h average) at the time?
  2 2015-10-15 04:16:30 <shesek> n/m, found one: http://api.coindesk.com/v1/bpi/historical/close.json?start=2015-01-01&end=2015-01-01
  3 2015-10-15 04:36:19 <equil_> i just have to put the address in from bitcoin-cli -testnet getaccountaddress "" to a faucet to get some coins right? how long do they take to come through
  4 2015-10-15 04:53:50 <midnightmagic> equil_: This is not the place for such questions.
  5 2015-10-15 04:54:19 <equil_> is this not related to the bitcoin test network
  6 2015-10-15 04:55:35 <equil_> midnightmagic: where should I ask instead?
  7 2015-10-15 04:59:00 <midnightmagic> equil_: Nowhere in any channels that begin with #bitcoin. :)
  8 2015-10-15 04:59:33 <equil_> I don't get it
  9 2015-10-15 05:26:56 <moli> equil_: i guess you can google for the testnet faucets, i've seen a few, here's one:  https://accounts.blockcypher.com/testnet-faucet
 10 2015-10-15 05:27:34 <equil_> moli: thanks, I had already used one but I wasn't recieving any coins and couldn't figure out whether or not it was an issue on my end or something else
 11 2015-10-15 05:29:03 <midnightmagic> Please no faucet discussion in here. They are, often, scams or fraudulent in other ways.
 12 2015-10-15 05:29:16 <equil_> it is a faucet for the test network
 13 2015-10-15 05:34:41 <equil_> the coins are worthless and used in development
 14 2015-10-15 05:36:12 <moli> right, test coins have no value, nobody would buy them
 15 2015-10-15 05:36:32 <equil_> or scam them
 16 2015-10-15 05:38:23 <equil_> and actually referenced on bitcoin.org https://bitcoin.org/en/developer-examples#testnet
 17 2015-10-15 05:39:20 <midnightmagic> I did ask nicely.
 18 2015-10-15 05:39:40 <midnightmagic> That URL above is *not* referenced in bitcoin.org at the URL you posted.
 19 2015-10-15 05:39:52 <midnightmagic> *he posted.
 20 2015-10-15 05:40:11 <equil_> perhaps not, but the usage of faucets is
 21 2015-10-15 05:40:19 <equil_> which I thought was the whole issue to begin with
 22 2015-10-15 05:40:26 <equil_> not the specific faucet, but any faucet
 23 2015-10-15 05:45:12 <equil_> it's OK to admit you don't understand
 24 2015-10-15 09:06:42 <equil_> does anyone have any testnet coins they could send me please?
 25 2015-10-15 09:23:08 <Luke-Jr> equil_: address?
 26 2015-10-15 09:23:26 <equil_> Luke-Jr: I got one sent to me, thanks
 27 2015-10-15 09:23:32 <equil_> Luke-Jr: also it was my RAM
 28 2015-10-15 09:23:44 <Luke-Jr> bad RAM?
 29 2015-10-15 09:23:57 <equil_> it's been funny for a while
 30 2015-10-15 09:24:20 <equil_> http://www.amazon.com/Corsair-Vengeance-Desktop-Memory-CML8GX3M2A1600C9/dp/B00569K7LM
 31 2015-10-15 09:24:27 <equil_> but gets hardware errors running at 1600
 32 2015-10-15 09:25:46 <Luke-Jr> ah, we're in the wrong channel for this topic XD
 33 2015-10-15 09:26:38 <equil_> my bad
 34 2015-10-15 10:56:11 <warren> I've been crazy busy on something else, and I've seen chat or list posts of 2-3 different moderation plans now
 35 2015-10-15 11:06:12 <wumpus> I've been crazy busy this week too, really need some rest now that 0.11.1 is out of the door
 36 2015-10-15 14:17:42 <jonasschnelli> is OP_CODESEPARATOR standard?
 37 2015-10-15 14:50:42 <bsm1175321> jonasschnelli: in terms of IsStandard(), OP_CODESEPARATOR is not standard.
 38 2015-10-15 14:50:51 <bsm1175321> According to this, it's also useless: http://bitcoin.stackexchange.com/questions/34013/what-is-op-codeseparator-used-for
 39 2015-10-15 14:51:03 <jonasschnelli> bsm1175321: Thanks!
 40 2015-10-15 14:53:12 <bsm1175321> I like the idea behind it though...A use case came up for it for me yesterday...
 41 2015-10-15 16:40:16 <jtimon> in freimarkets we used it as op_delegation_separator
 42 2015-10-15 16:40:27 <jtimon> maybe #wizards
 43 2015-10-15 16:46:28 <maaku> jtimon: different semantics though
 44 2015-10-15 16:54:05 <maaku> morcos: objections to moving the SEQUENCE_LOCKTIME_SECONDS_FLAG to a different bit position, 1 << 22?
 45 2015-10-15 16:54:50 <morcos> maaku: one sec
 46 2015-10-15 16:56:25 <maaku> that is the highest it can go without making seconds-denominated relative lock-time a 4-byte push
 47 2015-10-15 16:57:29 <morcos> ok i was trying to figure out the logic here...   hadn't looked through the new code yet.  so you made the secuence number encoded in the the low order 2 bytes.
 48 2015-10-15 16:58:10 <maaku> correct, 16 bits for the relative time-lock, one bit for the unit flag (bit #17)
 49 2015-10-15 16:58:37 <maaku> i'm suggesting making that bit #23 instead, since that's the highest it can go without moving to 4-byte pushes
 50 2015-10-15 17:01:02 <maaku> it divides the unused bit portion in a sortof ugly way, but it allows up to 22 bits of relative lock time to be used on a sidechain with very clean compatability
 51 2015-10-15 17:02:19 <morcos> yeah i guess i'm not understanding the down side of pushing 4 bytes?
 52 2015-10-15 17:02:33 <maaku> e.g. on a Alpha or Liquid like federated sidechain you could have 8s blocks, 8s granularity and still support a year of relative lock-time, and existing code would still work
 53 2015-10-15 17:02:58 <maaku> morcos: it saves a byte in transaction size
 54 2015-10-15 17:03:09 <maaku> when using relative lock-time with CSV
 55 2015-10-15 17:03:48 <morcos> but you'd only need to push 4 bytes if you ended up deciding to soft fork below 8 sec resolution right
 56 2015-10-15 17:04:09 <maaku> no, because you need to set SEQUENCE_LOCKTIME_SECONDS_FLAG
 57 2015-10-15 17:04:26 <morcos> oh, i see
 58 2015-10-15 17:05:18 <maaku> 3 bytes = 24 bits, but pushes are signed so 23 bits, that leaves 1 bit for the flag, 22 bits for relative lock-time (only low 16bits enforced now)
 59 2015-10-15 17:06:28 <morcos> and you think you should encode the sequence in bits 1-16 instead of 7-22?
 60 2015-10-15 17:07:21 <morcos> but no i dont' think i have an objection
 61 2015-10-15 17:07:36 <maaku> morcos: yes, because then height-based lock times are 1- or 2-byte pushes
 62 2015-10-15 17:08:07 <maaku> and the code generation is easy. for height based just push the desired age
 63 2015-10-15 17:08:08 <morcos> ah, it just works because the number is less than 1<<22
 64 2015-10-15 17:08:16 <maaku> right
 65 2015-10-15 17:08:37 <maaku> for seconds, the push is 0x40 + <two-byte lock-time>
 66 2015-10-15 17:09:17 <morcos> so it'll get a bit wonky looking code to actually have finer granularity then huh
 67 2015-10-15 17:09:25 <maaku> so no bit shifting needed in implementations... unless we decide to make use of bits 17..22
 68 2015-10-15 17:10:01 <maaku> yeah, but I seriously don't think we'll ever have higher granularity on bitcoin blockchain
 69 2015-10-15 17:10:19 <maaku> on the other hand, a protocol written for bitcoin would work out of the box but faster on a faster network, e.g. Liquid
 70 2015-10-15 17:10:25 <morcos> yeah i'm wondering what is more likely , we use 17..22 for finer granularity or for some different meaning, and if its a different meaning, then maybe nicer to leave them to the left of the SECONDS_FLAG
 71 2015-10-15 17:10:30 <morcos> ah
 72 2015-10-15 17:11:13 <maaku> (because that network if it has 2x faster blocks, redefines its own granularity to be 256s instead of 512s)
 73 2015-10-15 17:11:13 <morcos> so how ugly is it if you leave it at 17 to have finer granularity
 74 2015-10-15 17:11:36 <maaku> morcos: it gets ugly if you want to keep 1 year of maximum lock time
 75 2015-10-15 17:11:44 <maaku> because the flag bit is in the way
 76 2015-10-15 17:12:16 <morcos> so it depends on if you're starting with the finer granularity, then sure i agree
 77 2015-10-15 17:12:29 <morcos> but i think if you're soft forking in finer granularity, then its going to be ugly either way right?
 78 2015-10-15 17:13:13 <morcos> bc the bits of your sequence number will be out of order if you soft fork down to 8s later, since you have to continue using 1-16 for the high order bits
 79 2015-10-15 17:17:39 <morcos> i don't have a strong opinion, it if was up to me bit 17 woudl be SECONDS_FLAG and bits 32-18 = 00.00 would indicate BIP 68.  then evolving to finer granularity of say 8 seconds would be a soft fork where bits 32-24 = 0 and bits 23-18 represent the low order bits, and 16-1 the high order bits
 80 2015-10-15 17:17:46 <morcos> but at this point its all nitpicking
 81 2015-10-15 17:18:00 <morcos> i think as long as you're saving the bits, we can hack in what we need later, so no objections
 82 2015-10-15 17:25:46 <maaku> morcos: interesting question -- do we want to bias in favor of height-based or time-based relative lock-time?
 83 2015-10-15 17:26:22 <maaku> or do we remove bias by putting the flag in bit 0
 84 2015-10-15 17:26:44 <morcos> the counting method we've been using doesn' thave a bit 0.  :)
 85 2015-10-15 17:26:54 <maaku> er, yeah bit 1
 86 2015-10-15 17:27:28 <morcos> i think there are 2 questions:
 87 2015-10-15 17:28:36 <morcos> 1) does whatever semantics you pick preclude things that other semantics wouldn't.   In this case, I think you're precluding haveing more than 31 bits available for non BIP 68 semantics, but I htink we all agree thats ok.  And as far as I can tell, nothing else is precluded, some things are just more hacky
 88 2015-10-15 17:29:18 <maaku> correct
 89 2015-10-15 17:30:18 <morcos> 2) which semantics allow for nicer code and i agree, things like smaller txs are a big win.  That questions should be asked primarily with regards to the 512 second granuarlity but should also be considered for whatever we expect the next use of the 14 bits to be
 90 2015-10-15 17:30:59 <morcos> i don't have a good feel for whether that is more likely to be finer granularity or some different soft fork.
 91 2015-10-15 17:31:09 <morcos> i'm not sure there is a RIGHT answer
 92 2015-10-15 17:32:45 <maaku> my own view: it's interesting to note that higher granularity can be soft-forked in, but I don't think this will ever happen on bitcoin block chain. I DO think that we should optimize for code reuse on sidechains and/or alts that have lower interblock times or different consensus models
 93 2015-10-15 17:33:51 <maaku> (And I have a conflict of interest here, although I assert this would be my view anyway and can probably find citations of me arguing for code reuse sensitivity pre-blockstream)
 94 2015-10-15 17:33:53 <morcos> so one thing to consider there is what do those alt chains do about the block height
 95 2015-10-15 17:34:50 <morcos> oh is that why you asked that above?  b/c now in order to still have a year of range, they need more high order bits.
 96 2015-10-15 17:34:57 <maaku> meaning? no system I have seen has a concept of fractional block height, although there are theoretical stuff discussed on wizards
 97 2015-10-15 17:35:03 <maaku> morcos: right
 98 2015-10-15 17:35:31 <morcos> so they can start with that i suppose, but they can't soft fork it in right?
 99 2015-10-15 17:36:50 <maaku> Best explained by example. Alpha has approximately 1min blocks. Let's round up to 64 sec.
100 2015-10-15 17:37:55 <maaku> What an Alpha-like chain can do is add 3 high order bits so bits 1..19 encode relative lock time.
101 2015-10-15 17:38:17 <maaku> And make the seconds granularity 64s instead of 512s
102 2015-10-15 17:39:11 <maaku> Now any protocol written for Bitcoin would just work out of the box on this hypothetical system, but with relative lock-time timeouts 1/8 as long
103 2015-10-15 17:39:54 <maaku> And that is safe as long as you remember to poll spend status 8x as frequently
104 2015-10-15 17:47:14 <Iriez> is 0.11.1 updated on github? I get this: Remote branch 0.11.1 not found in upstream origin
105 2015-10-15 17:47:22 <Iriez> when trying to upgrade
106 2015-10-15 17:49:08 <morcos> maaku: i don't think i have a strong opinion, i haven't thought enough about how this is used in practice.  so if you're hoping for my independent opinion, then best i can say is i can't make an argument that it would be worse.
107 2015-10-15 17:49:42 <maaku> ok thanks
108 2015-10-15 17:49:45 <morcos> sdaftuar was actually just convincing me that my preferred solution above is not obviously a good idea
109 2015-10-15 17:50:05 <maaku> yeah you have to mask out those bits, not mandate they are zoro
110 2015-10-15 17:50:12 <maaku> not sure if that is what sdaftuar is saying
111 2015-10-15 17:50:26 <morcos> so now i'd go so far as to say i have no idea what i'd pick if it was up to me, so i'd go with what you think is best and lets see if anything comes up in review
112 2015-10-15 17:50:32 <morcos> thanks for bringing it up though
113 2015-10-15 17:51:21 <morcos> no i was particularly meaning to set them all to 0.  so that if you then wanted another soft fork within BIP 68.  what you're actually doing is applying BIP 68 and NewSoftFork at the same time to some of the remaining bit space
114 2015-10-15 17:51:47 <morcos> but thats maybe a little less secure in that there are now 2 consensus rules that non updated code would not be evaluating
115 2015-10-15 17:52:09 <maaku> morcos: that would make those bits inaccessible to CSV, no?
116 2015-10-15 17:52:52 <maaku> CSV would have to fail if those bits are set, which means you could no longer soft-fork extend CSV; you'd have to use a new opcode
117 2015-10-15 17:53:02 <morcos> you mean if the additional soft fork was finer granularity... hmmm
118 2015-10-15 17:53:14 <morcos> yes i hadn't thought about that
119 2015-10-15 17:53:24 <morcos> oh yeah for anything
120 2015-10-15 17:55:38 <morcos> so i'm not sure i thought through fully how to soft fork in finer granularity with CSV in your proposal
121 2015-10-15 17:55:41 <morcos> but it can be done?
122 2015-10-15 17:56:41 <maaku> yes because in current implementation of #6312 bits without assigned meaning are simply masked out
123 2015-10-15 17:57:50 <maaku> so CSV and LockTime's view of nSequence is : 0xxxxxxxxxxxxxxULLLLLLLLLLLLLLLL
124 2015-10-15 17:58:08 <morcos> so CSV is also changed to mask out bits in the pushed number?
125 2015-10-15 17:58:21 <maaku> bit 32 must be 0, bit 17 determines units, bits 1..16 provide lock-time, bits 18..31 can take any value
126 2015-10-15 17:58:26 <maaku> yes
127 2015-10-15 17:58:48 <maaku> although I haven't pushed that because I have to rewrite all the unit tests (a task for today)
128 2015-10-15 17:59:28 <morcos> ok that makes sense
129 2015-10-15 18:00:16 <morcos> why don't you send an email to the ML proposing to move units bit to 23 and see if anybody has any objection
130 2015-10-15 18:00:21 <maaku> ok
131 2015-10-15 18:05:24 <GreenIsMyPepper> the idea being we've passed those bits already in time, right?
132 2015-10-15 18:06:13 <maaku> GreenIsMyPepper: you're the one I want to talk to. do you see height-based or time-based timeouts being used more frequently in lightning (or other applications)?
133 2015-10-15 18:06:17 <btcdrak> maaku: or we could just discuss the bits in the IRC meeting today
134 2015-10-15 18:06:29 <GreenIsMyPepper> i don't see time based timeouts used at all
135 2015-10-15 18:06:46 <GreenIsMyPepper> relative i mean
136 2015-10-15 18:06:47 <btcdrak> morcos: in general are you more happy to ACK BIP68?
137 2015-10-15 18:07:20 <GreenIsMyPepper> for absolute nLockTime/CLTV, yes I see the need for timestamps, and the block averaging timestamp thing makes a LOT of sense
138 2015-10-15 18:07:31 <maaku> GreenIsMyPepper: interesting. what about permissioned sidechains where interblock times may not be as reliable (e.g. blocks not mined unless transactions are available)?
139 2015-10-15 18:07:40 <GreenIsMyPepper> err the doesn't go backwards block time thing
140 2015-10-15 18:07:53 <GreenIsMyPepper> oh, you mean when you want to sync multiple chains?
141 2015-10-15 18:07:57 <GreenIsMyPepper> on a relative basis?
142 2015-10-15 18:08:25 <GreenIsMyPepper> ok, maybe for liquid, which is why i've never disputed the need to do so, as in I think there might be some kind of theoretical need for it
143 2015-10-15 18:08:30 <maaku> GreenIsMyPepper: maybe that's interesting, but no I just meant e.g. RCLTV on Alpha
144 2015-10-15 18:08:32 <GreenIsMyPepper> but for LN in particular, the timeouts for channels are asynchronous
145 2015-10-15 18:09:01 <maaku> we have a mode that BlueMatt turned on for his functionary node where he doesn't generate blocks if there aren't transactions to put in it
146 2015-10-15 18:10:01 <maaku> GreenIsMyPepper: ok but on the bitcoin block chain you definately prefer height over time? interesting
147 2015-10-15 18:10:59 <GreenIsMyPepper> so if you timeout on one chain at a particular time and timeout on another chain at another time it's no problem -- from a finance perspective, I suspect there is no real need for inter-chain *relative* locking if you presume the financial system is scriptable (you *absolutely* need timestamps for hard non-relative times though), but that may be too aggressive to say :P
148 2015-10-15 18:11:06 <maaku> I would have thought the opposite, because e.g. a client may need to poll periodically and the time-based locktime (with BIP 113) gives a calculable polling frequency
149 2015-10-15 18:12:24 <GreenIsMyPepper> i think time-based locks are very messy and am okay with that kind of breakage because I assume a certain level of outsourcability, do you think that perspective is too naive?
150 2015-10-15 18:13:50 <maaku> I've been deep in the weeds and not thinking about it to be honest.
151 2015-10-15 18:13:56 <GreenIsMyPepper> i'm preferring block-based to encourage future timestop things (irrespective of whether you think that particular idea is a good way to solve particular problems)
152 2015-10-15 18:14:15 <morcos> btcdrak: ha, no, its not even updated yet, for current changes let alone new proposals, but yes, concept ACK
153 2015-10-15 18:14:35 <GreenIsMyPepper> maaku: oh to be precise, i'm not AGAINST timestamps in nSequence
154 2015-10-15 18:15:01 <GreenIsMyPepper> i think it's better to include it rather than not because hard timelocks have it too, and it's better to be similar in functionality
155 2015-10-15 18:15:01 <morcos> GreenIsMyPepper: how important is solving the timestop problem, that seems difficult to me
156 2015-10-15 18:15:25 <maaku> The question comes up because the location and meaning of the units flag determines whether a CSV push must be 3 bytes vs possibly 1-byte or 2-byte
157 2015-10-15 18:16:10 <maaku> morcos: #6312 is updated, except perhaps the switch from bit #17 -> bit #23
158 2015-10-15 18:16:28 <GreenIsMyPepper> morcos: not sure. i think it's OK with micropayments and a moderately small unused reserve in every channel. if people don't use reserves or the predominant uses on a dollar value basis is inter-exchange arbitrage, the importance goes up.
159 2015-10-15 18:16:29 <morcos> maaku: yes, but he asked about BIP 68.
160 2015-10-15 18:16:38 <maaku> morcos: he meant the PR
161 2015-10-15 18:16:43 <btcdrak> morcos: I need a slap, i meant the PR.
162 2015-10-15 18:17:11 <morcos> in that case i haven't rereviewed it.  i'll wait until we decide on bit 17/23
163 2015-10-15 18:17:39 <maaku> GreenIsMyPepper: with current #6312, a height-based CSV <127 fits in 1 byte, otherwise usually 2 bytes. time-based CSV is always a 3-byte push
164 2015-10-15 18:17:52 <maaku> GreenIsMyPepper: that can be reversed (so time-based is shorter), hence my question
165 2015-10-15 18:18:36 <btcdrak> maaku: you want the maximum flexibility for use cases since you cannot predict all future use/need.
166 2015-10-15 18:18:39 <maaku> OR the flag bit could be put in bit 0, and then it's symmetrical (both can fit in 1- or 2-bytes) but 1-byte push is limited to 63 (blocks, or *512seconds)
167 2015-10-15 18:18:48 <GreenIsMyPepper> i will take a look and comment on that pull req now
168 2015-10-15 18:20:35 <GreenIsMyPepper> so clarification while i was thinking about nVersion. it's not used because it's hard to push that data into the script validation, correct?
169 2015-10-15 18:20:43 <GreenIsMyPepper> and would become messy?
170 2015-10-15 18:21:22 <nwilcox> Why doesn't doc/build-unix.md mention ./depends at all?
171 2015-10-15 18:21:47 <nwilcox> -or to put my question more clearly: why isn't building/linking against ./depends not the default instruction?
172 2015-10-15 18:22:44 <maaku> GreenIsMyPepper: can you clarify your question? I'm not understanding
173 2015-10-15 18:23:30 <GreenIsMyPepper> those bit flags aren't in nVersion, is it because pushing that data into the script validation parts is messy? as in OP_CSV wouldn't know how to behave?
174 2015-10-15 18:24:07 <GreenIsMyPepper> i realized that might be the case when reviewing it but just want to double check on why :P
175 2015-10-15 18:24:28 <maaku> ... why would those flags be in nVersion
176 2015-10-15 18:25:17 <maaku> aside from burning an nVersion bit, that would require all inputs to have the same units (seconds vs blocks) which is actually a significant loss
177 2015-10-15 18:25:28 <GreenIsMyPepper> you could put the the bits anywhere theoretically, right?
178 2015-10-15 18:25:50 <maaku> GreenIsMyPepper: BIP 68 is per-input. There's only one nVersion field
179 2015-10-15 18:25:58 <GreenIsMyPepper> i see, the purpose is to keep it per-input
180 2015-10-15 18:26:13 <GreenIsMyPepper> alright
181 2015-10-15 18:26:35 <GreenIsMyPepper> that is a very important property, you're right.
182 2015-10-15 18:45:55 <btcdrak> maaku: can you elaborate in the ML email what the change allows for in terms of blocktimes and maximum locktime.
183 2015-10-15 18:46:30 <maaku> btcdrak: neither are affected
184 2015-10-15 18:47:02 <btcdrak> maaku: so it's about 1 yr RCLTV as before
185 2015-10-15 18:47:24 <maaku> btcdrak: nothing changes, it's just where the bits are in the field
186 2015-10-15 18:49:54 <btcdrak> maaku: then I'm not sure what the disadvantage could be
187 2015-10-15 19:00:38 <sdaftuar> meeting starting now?
188 2015-10-15 19:00:38 <sipa> meeting time?
189 2015-10-15 19:00:44 <wumpus> yes
190 2015-10-15 19:00:47 <BlueMatt> morning all
191 2015-10-15 19:00:51 <jonasschnelli> hi
192 2015-10-15 19:00:53 <wumpus> I can't be there all the time though; anyone wants to chair today?
193 2015-10-15 19:00:54 <btcdrak> wumpus: will you be controlling meetbot?
194 2015-10-15 19:01:00 <wumpus> #startmeeting
195 2015-10-15 19:01:01 <lightningbot> Meeting started Thu Oct 15 19:01:00 2015 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
196 2015-10-15 19:01:01 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
197 2015-10-15 19:01:09 <sipa> evening all
198 2015-10-15 19:01:15 <btcdrak> evening all
199 2015-10-15 19:01:23 <GreenIsMyPepper> morning all
200 2015-10-15 19:01:27 <GreenIsMyPepper> afternoon
201 2015-10-15 19:01:27 <sipa> do we have topics?
202 2015-10-15 19:02:02 <wumpus> mempool limiting, as usual, I suppose
203 2015-10-15 19:02:10 <BlueMatt> not much to discuss there
204 2015-10-15 19:02:14 <BlueMatt> but, sure....
205 2015-10-15 19:02:14 <wumpus> ok
206 2015-10-15 19:02:19 <sipa> i'm benchmarking BlueMatt's current patch
207 2015-10-15 19:02:22 <sdaftuar> i'd like to get direction for the sendheaders BIP so i can move forward with the related pull
208 2015-10-15 19:02:34 <wumpus> #topic mempool limiting
209 2015-10-15 19:02:38 <btcdrak> maaku posted a question to the list about BIP68 which could be discussed, it's easy too
210 2015-10-15 19:02:39 <BlueMatt> #6722 is looking for review
211 2015-10-15 19:02:53 <morcos> BlueMatt: s/review/merge/ :)
212 2015-10-15 19:02:53 <wumpus> #action review #6722
213 2015-10-15 19:02:55 <sdaftuar> i'm close to ACKing :)  running some final tests
214 2015-10-15 19:02:56 <BlueMatt> those who had avoided it previously because it was still churning should go ahead and do that
215 2015-10-15 19:03:07 <sipa> i'm seeing transactions that take 200ms to accept into the mempool
216 2015-10-15 19:03:20 <BlueMatt> sipa: oh? I didnt see anything that bad when i was looking? :(
217 2015-10-15 19:03:20 <morcos> whoa
218 2015-10-15 19:03:20 <sipa> but it seems those may just be very large transactions
219 2015-10-15 19:03:37 <sipa> BlueMatt: i don't think it's because of your pull - i never benchmarked mempool acceptance before
220 2015-10-15 19:03:42 <sipa> but i'd like to know for sure
221 2015-10-15 19:03:46 <sdaftuar> hm. could it be the package code?
222 2015-10-15 19:03:47 <morcos> ok to be honest i never benchmarked 6722, but nothing in it should be slower than other things i benchmarked
223 2015-10-15 19:03:52 <btcdrak> sipa: dont see how it could be related to that pull
224 2015-10-15 19:03:57 <morcos> 2ms is appropriate amount of time to be accepted to mempool
225 2015-10-15 19:04:09 <BlueMatt> dunno, when i looked at it it was 100% sig checking
226 2015-10-15 19:04:12 <BlueMatt> well, 95
227 2015-10-15 19:04:48 <morcos> ok, i can do some performance testing of it.., sipa, you saw like a few outliers taking that long or what?  either way thats bad
228 2015-10-15 19:04:58 <gmaxwell> No gdoc today?
229 2015-10-15 19:05:06 <sipa> the average is around 4ms, but very strong outliers
230 2015-10-15 19:05:09 <btcdrak> gmaxwell: just meetbot
231 2015-10-15 19:05:23 <sipa> this is with libsecp validation merged
232 2015-10-15 19:05:41 <morcos> yeah me too
233 2015-10-15 19:05:49 <sipa> i'll benchmark more and comment on the pr
234 2015-10-15 19:05:58 <CodeShark> is there a list of the topics for discussion?
235 2015-10-15 19:06:15 <btcdrak> CodeShark: ad hoc today
236 2015-10-15 19:07:15 <btcdrak> my only comment/nit on 6722 was I wasnt sure why we should revert the minrelay in that particular PR.
237 2015-10-15 19:07:41 <jonasschnelli> If there are non *important* topics i would be interested to brainstorm additional services on the p2p network protected over ECDH. But only if it makes sense to discuss it off-mailing-list
238 2015-10-15 19:07:43 <sipa> i understand that it reverts it, because the raising of it was a temporary measure
239 2015-10-15 19:07:50 <BlueMatt> btcdrak: well 5000 no longer makes sense, and to avoid having a huge discussion on the proper value, I just picked the previous one
240 2015-10-15 19:08:21 <sipa> but i do think that the relayfee which influences dust should be floating as well, or the dust limit becomes ineffective
241 2015-10-15 19:09:01 <wumpus> CodeShark: if you have any suggestions, go ahead
242 2015-10-15 19:10:00 <CodeShark> regarding mempool limiting? or regarding topics?
243 2015-10-15 19:10:05 <btcdrak> Can we discuss this today: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011555.html (or hear any objections)
244 2015-10-15 19:10:09 <gmaxwell> jonasschnelli: could we talk about it after the meeting? I'd like to understand what you're thinking.
245 2015-10-15 19:10:12 <wumpus> #topic sdaftuar's sendheaders BIP
246 2015-10-15 19:10:50 <sdaftuar> so i don't feel strongly about how to move forward.  theuni proposed extending the version message; seems like that's not a popular idea though
247 2015-10-15 19:11:10 <sdaftuar> i think the "flags" message idea that gmaxwell suggested has the same synchronization problem as anything else
248 2015-10-15 19:11:11 <sipa> i am pretty strongly opposed to overloading the version message further
249 2015-10-15 19:11:11 <wumpus> I'd prefere not extending the version message
250 2015-10-15 19:11:21 <gmaxwell> I do not think extending the version message is good.
251 2015-10-15 19:11:25 <btcdrak> ditto
252 2015-10-15 19:11:27 <CodeShark> agreed
253 2015-10-15 19:11:28 <wumpus> what was wrong with using a special message to signal support for it?
254 2015-10-15 19:11:50 <sdaftuar> perhaps nothing?  i think the objection was having network messages that change state
255 2015-10-15 19:12:14 <sdaftuar> but as the state only changes once, and the way it's implemented, it only chnages right after the verack's are sent i think,
256 2015-10-15 19:12:16 <sipa> i don't understand that concern
257 2015-10-15 19:12:22 <gmaxwell> We could however add an "options" message that can send flags. I wouldn't be opposed to that. But I don't see a strong advantage over just having a message.
258 2015-10-15 19:12:23 <sipa> the protocol is already badly stateless
259 2015-10-15 19:12:26 <sipa> eh, statefull
260 2015-10-15 19:12:37 <wumpus> well you can require that it happens between version and any other messages
261 2015-10-15 19:12:44 <gmaxwell> Also, the message is advisory, so if its handled out of order thats okay.
262 2015-10-15 19:12:56 <sdaftuar> gmaxwell: yes, i agree
263 2015-10-15 19:13:00 <wumpus> to prevent it from becoming a 'change state' message
264 2015-10-15 19:13:01 <sipa> can we require the message be sent between version and verack?
265 2015-10-15 19:13:29 <sipa> or would this trip up older clients that expect nothing in between
266 2015-10-15 19:13:46 <davec> that would probably break older clients
267 2015-10-15 19:13:46 <sdaftuar> well we only send it if the recipient's version is high enough
268 2015-10-15 19:13:46 <wumpus> I think that will cause potential problems
269 2015-10-15 19:14:03 <wumpus> just require that it happens before getheaders
270 2015-10-15 19:14:05 <wumpus> problem solved.
271 2015-10-15 19:14:27 <sipa> is there a problem even with it being a state change?
272 2015-10-15 19:14:38 <sdaftuar> i don't think there is, from the perspective of the code change that implements it
273 2015-10-15 19:14:52 <sipa> receiving the message and understanding it sets a bit 'this peer supports X'. there is no way to unset it
274 2015-10-15 19:14:54 <wumpus> it's not nice to have it possible to change the state back and forth
275 2015-10-15 19:15:03 <sdaftuar> it can't go the other way
276 2015-10-15 19:15:08 <sdaftuar> ie you can enable it, but you can't disable it
277 2015-10-15 19:15:22 <sipa> exactly
278 2015-10-15 19:15:24 <wumpus> a connection should have well-defined propreties, ideally negotiated in the beginning
279 2015-10-15 19:15:25 <wumpus> ok
280 2015-10-15 19:15:29 <gmaxwell> sipa: I think as long as it's clear that it doesn't necessarily have immediate effect, then the concern there is moot. Though we might want to consider uniformity with future optional extensions.
281 2015-10-15 19:15:39 <sipa> gmaxwell: fair enough
282 2015-10-15 19:16:03 <wumpus> what do you mean with 'immediate effect'? I think it can be required that it applies to messages sent after it?
283 2015-10-15 19:16:11 <sipa> just say that 'optional feature negotiation' happens immediately after verack, and before any 'data' messages
284 2015-10-15 19:16:14 <sipa> ?
285 2015-10-15 19:16:23 <wumpus> what would be the point in having it, say, take effect 5 seconds later?
286 2015-10-15 19:16:31 <sdaftuar> wumpus: announcing via headers isn
287 2015-10-15 19:16:37 <davec> I'd rather have it one way as well.  Otherwise it adds a bunch of complexity for something that, in my opinion, wouldn't even be very useful
288 2015-10-15 19:16:47 <btcdrak> for the log, sendheaders link on the ML http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/011184.html
289 2015-10-15 19:16:49 <sdaftuar> 't guaranteed to happen.  there are situations where it falls back to inv (eg if you don't know where your peer is)
290 2015-10-15 19:16:52 <gmaxwell> wumpus: it doesn't matter if it takes effect 5 seconds later.
291 2015-10-15 19:17:01 <sipa> davec: well it would be optional!
292 2015-10-15 19:17:03 <wumpus> gmaxwell: ok
293 2015-10-15 19:17:26 <davec> I meant in regards to toggling it back off after it has been enabled
294 2015-10-15 19:17:29 <wumpus> yes, it would be optional, so if you don't think it is useful, don't implement it
295 2015-10-15 19:17:33 <gmaxwell> I think it should be one way.
296 2015-10-15 19:17:57 <sipa> davec: i don't think that should be supported at all; either just a message to enable it at any time, or even stricter and require that it happens during some early handshake
297 2015-10-15 19:18:07 <davec> we agree
298 2015-10-15 19:18:09 <sipa> but no disabling
299 2015-10-15 19:18:19 <sipa> #agree no unsetting sendheaders
300 2015-10-15 19:18:19 <wumpus> that's already what is in the BIP
301 2015-10-15 19:18:36 <gmaxwell> I think it might be polte to require it be up front, but take care that it doesn't interact poorly with other optional things like it.
302 2015-10-15 19:19:06 <sipa> sdaftuar: what do you think about requiring sendheaders be sent right after verack, and before anything else?
303 2015-10-15 19:19:09 <gmaxwell> e.g. if you expect it to be up front but in the future you get  ver/verak sendfrogs sendheaders ... you shouldn't reject the send headers because it came after the sendfrogs that you don't understand.
304 2015-10-15 19:19:11 <morcos> i think we're over constraining this
305 2015-10-15 19:19:30 <sipa> morcos: maybe
306 2015-10-15 19:19:38 <wumpus> sipa: how wil that interact with future messages?
307 2015-10-15 19:19:49 <morcos> its entirely possible some future optimization may say, i want to send sendheaders to these peers b/c they announce a lot of new stuff to me and not these others b/c they don't
308 2015-10-15 19:20:05 <wumpus> sipa: I don't think being toos trict there is a good idea, especially as it crosses between concerns
309 2015-10-15 19:20:16 <morcos> maybe you want to wait and send it later once you have some data
310 2015-10-15 19:20:17 <wumpus> sipa: e.g. who cares if it is sent before or after an 'alert' message
311 2015-10-15 19:20:29 <sipa> ok, so no problem with state changing, as long as it's unidirection, but we don't care when it happens?
312 2015-10-15 19:20:42 <sipa> fine by me
313 2015-10-15 19:21:00 <gmaxwell> Yea, it's unidirection and no proposes when it happens or if it happens at all.
314 2015-10-15 19:21:01 <morcos> ok, and to be clear why does it have to be unidirectional?
315 2015-10-15 19:21:14 <morcos> i mean i don't see any reason for bidirectionality now
316 2015-10-15 19:21:18 <morcos> but why impose it?
317 2015-10-15 19:21:19 <wumpus> unless there would be some clear negotiation phase in which *all* extra negotiation happens, but I don't think it's worth locking that down for this
318 2015-10-15 19:21:26 <CodeShark> you mean add another message donotsendheaders?
319 2015-10-15 19:21:29 <wumpus> I think this topic is done
320 2015-10-15 19:21:33 <sipa> ok
321 2015-10-15 19:21:42 <CodeShark> can we throw in versionbits as a topic?
322 2015-10-15 19:21:43 <morcos> ok sure
323 2015-10-15 19:21:44 <sdaftuar> it sounds like everyone is ok with the BIP as drafted then?
324 2015-10-15 19:21:57 <wumpus> yes
325 2015-10-15 19:21:59 <gmaxwell> I think so.
326 2015-10-15 19:22:03 <davec> yes
327 2015-10-15 19:22:08 <wumpus> it's uncontroversial and clear
328 2015-10-15 19:22:11 <sdaftuar> ok great
329 2015-10-15 19:22:12 <btcdrak> yes
330 2015-10-15 19:22:24 <gmaxwell> PR the BIP for number assignment.
331 2015-10-15 19:22:28 <sdaftuar> will do
332 2015-10-15 19:22:33 <sipa> well, the only person with concerns was cfields, who doesn't seem to be here :)
333 2015-10-15 19:22:44 <gmaxwell> sipa: he can raise concerns later too!
334 2015-10-15 19:22:46 <cfields> dammit!
335 2015-10-15 19:22:49 <wumpus> #topic versionbits
336 2015-10-15 19:22:53 <sipa> cfields: too late!
337 2015-10-15 19:22:54 <gmaxwell> ha
338 2015-10-15 19:23:07 <cfields> did i really miss my third one of these in a row?
339 2015-10-15 19:23:22 <btcdrak> CodeShark: you have the floor.
340 2015-10-15 19:23:24 <gmaxwell> I have not read the versionbits implementation yet.
341 2015-10-15 19:23:30 <gmaxwell> (sorry)
342 2015-10-15 19:23:35 <cfields> sorry all
343 2015-10-15 19:23:39 <wumpus> me neither
344 2015-10-15 19:23:46 <sipa> i have looked at it briefly, but i'd like to see how it integrates with the consensus code in main
345 2015-10-15 19:23:57 <wumpus> #action review versionbits implementation
346 2015-10-15 19:23:58 <sipa> though i'll review the code that is there
347 2015-10-15 19:24:06 <CodeShark> so right now it's just a unit that implements the versionbits logic but does not demonstrate its usage
348 2015-10-15 19:24:21 <CodeShark> I thought it would be better to actually integrate in a separate PR, but I can add a demonstration
349 2015-10-15 19:24:25 <btcdrak> versionbits PR is https://github.com/bitcoin/bitcoin/pull/6816
350 2015-10-15 19:24:53 <sipa> CodeShark: separate commit, same PR - i think we need something that's mergable as a whole, to be able to see whether the whole thing easily backports
351 2015-10-15 19:25:03 <btcdrak> sipa: agree
352 2015-10-15 19:25:19 <sipa> (is my preference, i don't feel very strongly)
353 2015-10-15 19:25:20 <warren> Proposed for last topic: dev/discuss list policy followup
354 2015-10-15 19:25:51 <wumpus> #topic dev/discuss list policy followup
355 2015-10-15 19:26:18 <CodeShark> well, the integration I was envisioning also depends on $5747
356 2015-10-15 19:26:19 <CodeShark> err
357 2015-10-15 19:26:23 <CodeShark> #6747
358 2015-10-15 19:27:08 <wumpus> what is the state there warren?
359 2015-10-15 19:27:19 <CodeShark> err, are we done with versionbits?
360 2015-10-15 19:27:21 <CodeShark> I still had more
361 2015-10-15 19:27:34 <CodeShark> sorry, crappy keyboard hard to type
362 2015-10-15 19:27:37 <wumpus> CodeShark: no one has apparanetly reviewed it yet, so I don't think there's much more to discuss
363 2015-10-15 19:27:49 <CodeShark> I just wanted to address sipa's concern
364 2015-10-15 19:27:52 <btcdrak> The new list was created bitcoin-discuss, warren was supposed to distribute the admin password to jgarzik and someone else.
365 2015-10-15 19:27:54 <warren> We had a sort of meeting Monday to discuss this, jgarzik couldn't make it, we came to some rough consensus on some points, but since then I've seen mention of 2+ other proposals and I've been too busy with other things to follow what is happening.  My fault.
366 2015-10-15 19:28:22 <warren> Was jgarzik's list post the result of some other discussion?
367 2015-10-15 19:28:35 <warren> There was also mention that rusty had a separate proposal, did that happen?
368 2015-10-15 19:28:51 <btcdrak> warren: I think we are at risk of bikeshedding the issue. We have discussed moderation a lot over the last weeks and jeff seemed pretty keen and willing to pick up the bat. We just need to see how it plays out from now imo.
369 2015-10-15 19:28:53 <maaku> rusty (who is in australia where it is early AM) had a separate proposal for moderation of bitcoin-dev
370 2015-10-15 19:29:10 <CodeShark> fwiw, we should probably NOT state policy in a message on the ML but post it on some site and just provide the link on the ML
371 2015-10-15 19:29:17 <maaku> jgarzik is not here either so it's hard to confirm, but I think these are separate proposals
372 2015-10-15 19:29:32 <btcdrak> my recollection of things was that we'll only set the moderate bit on someone who fails to comply with moderator wishes.
373 2015-10-15 19:29:55 <warren> Yes, a neutrally hosted website for list policy with github pull requests to update it will happen soon.  Asked LF to host it as a neutral entity.
374 2015-10-15 19:30:40 <warren> It may be prudent to see rusty and jgarzik's proposal and to collectively reconvene after all the options are on the table.
375 2015-10-15 19:31:03 <btcdrak> warren: have you distributed the administration passwords yet?
376 2015-10-15 19:31:12 <warren> btcdrak: when policy isn't decided on?
377 2015-10-15 19:31:21 <btcdrak> when are we going to accounce bitcoin-discuss@ ?
378 2015-10-15 19:31:25 <morcos> too much bureaucracy, lets let jeff do it, if he does a bad job, we'll fire him
379 2015-10-15 19:31:38 <warren> morcos: who decides? =)
380 2015-10-15 19:31:41 <btcdrak> warren: I'm really not keen on this bureaucracy.
381 2015-10-15 19:31:44 <wumpus> tend to agree morcos... see to be overthinking this
382 2015-10-15 19:32:07 <btcdrak> if jeff falls out of line, we're going to beat him with a stick, so let's just get going
383 2015-10-15 19:32:17 <BlueMatt> lets let jeff and rusty and anyone else who is talking about this discuss between themselves and let them decide
384 2015-10-15 19:32:23 <morcos> we are all deciding right now, jeff is the maintainer of list moderation policy and personnel
385 2015-10-15 19:32:26 <BlueMatt> since none of them are even there
386 2015-10-15 19:32:27 <btcdrak> BlueMatt: agreed
387 2015-10-15 19:32:27 <sipa> BlueMatt: sgtm
388 2015-10-15 19:32:36 <warren> If the devs decide in their meeting "just let jeff decide" then fine, that's simple.  You folks decide that now, or maybe wait and see what rusty's proposal is first?
389 2015-10-15 19:32:37 <BlueMatt> here*
390 2015-10-15 19:32:51 <morcos> yes, we'll tell jeff he should take into account rusty's proposal
391 2015-10-15 19:33:00 <warren> BlueMatt: +1
392 2015-10-15 19:33:17 <CodeShark> this policy thing mostly became such a huge issue this year because of certain specific events...and I think it is somewhat of a mistake to try to generalize from this specific experience
393 2015-10-15 19:33:19 <warren> Isn't BlueMatt's approach reasonable?
394 2015-10-15 19:33:20 <GreenIsMyPepper> yes, interested parties can discuss and results posted publicly, agreed
395 2015-10-15 19:33:33 <morcos> someone has to take responsibility or nothing happens
396 2015-10-15 19:33:37 <btcdrak> I vote we let jeff decide with rusty's input. They both have greater experience of lkm and stuff.
397 2015-10-15 19:33:41 <BlueMatt> morcos: I think multiple people are?
398 2015-10-15 19:33:53 <CodeShark> or at least, I think the real causes for the fundamental problems had little to do with the ML
399 2015-10-15 19:33:54 <BlueMatt> morcos: both jeff and rusty (and others?) are working on proposals and want to move forward
400 2015-10-15 19:33:56 <GreenIsMyPepper> also, it's assumed -dev policy should be discussed in -discuss, correct?
401 2015-10-15 19:33:57 <BlueMatt> no reason to cut that off now?
402 2015-10-15 19:33:58 <wumpus> BlueMatt: they're just not here
403 2015-10-15 19:34:09 <warren> GreenIsMyPepper: wha?
404 2015-10-15 19:34:19 <BlueMatt> wumpus: I dunno about jeff, but rusty cannot reasonably be awake at this hour
405 2015-10-15 19:34:22 <morcos> i find the ML unusable now
406 2015-10-15 19:34:32 <morcos> i don't feel like we should wait for action
407 2015-10-15 19:34:39 <morcos> nothing is undoable
408 2015-10-15 19:34:47 <btcdrak> morcos: I propose we vote on "let jeff decide" now
409 2015-10-15 19:35:07 <btcdrak> if that doesnt work in a few weeks we can revisit it.
410 2015-10-15 19:35:12 <BlueMatt> morcos: meh, will we really die if we wait a week?
411 2015-10-15 19:35:13 <GreenIsMyPepper> warren: it's a common behavior for metadiscussion to be on a different channel, i think metafilter was one of the earliest uses of this and it makes tending the garden far easier, i assume a sepearate ml is unnecessary. but i don't mind either way just wondering?
412 2015-10-15 19:35:23 <warren> rusty and jeff are both very reasonable people with a lot of experience, I'd like to see what they can come up with together.  If they can't agree quickly then we just decide shortly after.
413 2015-10-15 19:35:38 <morcos> ok, well i will unsubscribe in the meantime
414 2015-10-15 19:35:40 <morcos> moving on
415 2015-10-15 19:35:45 <warren> sigh
416 2015-10-15 19:35:58 <btcdrak> warren: if you think they are reasonable, let them get on with it. We dont need to have all this bureaucracy
417 2015-10-15 19:36:03 <wumpus> ok, any more topics? this seems not to be constructive with the people involved here
418 2015-10-15 19:36:08 <btcdrak> I'm also considering unsubscribing at this rate.
419 2015-10-15 19:36:22 <warren> btcdrak: if the decision today is "let the TWO of them decide" that's fine with me
420 2015-10-15 19:36:27 <wumpus> #action rusty and jgarzik should discuss this, who are not here
421 2015-10-15 19:36:43 <btcdrak> wumpus: I'd like to discuss http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011555.html
422 2015-10-15 19:37:07 <wumpus> #topic CHECKSEQUENCEVERIFY - We need more usecases to motivate the change
423 2015-10-15 19:37:46 <CodeShark> lol - I don't think that subject is accurate anymore
424 2015-10-15 19:37:51 <CodeShark> the usecases are not the issue
425 2015-10-15 19:37:55 <morcos> my opinion is we just need to settle on exact semantics, i think moving forwad is justified
426 2015-10-15 19:37:58 <CodeShark> it's the format of the nSequence field that's at issue
427 2015-10-15 19:38:12 <btcdrak> wumpus: lots of usecases were added to the CSV BIP https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki#Motivation
428 2015-10-15 19:38:42 <btcdrak> I think BIP68 is pretty much done (implementation). We changed things to account for concerns last week
429 2015-10-15 19:39:30 <btcdrak> maaku was suggesting moving one of the bits to allow for other implementations, like sidechains to have better granularity
430 2015-10-15 19:39:54 <btcdrak> there doesnt appear to be any downside that I can see, but he wanted to know if anyone had objections (see the ML post)
431 2015-10-15 19:40:24 <maaku> yeah it's just moving a bit around
432 2015-10-15 19:40:39 <btcdrak> implementation code is here: https://github.com/bitcoin/bitcoin/pull/6312/files
433 2015-10-15 19:40:44 <maaku> #6312 is done (modulo moving the bit)
434 2015-10-15 19:41:08 <sipa> maaku: did you see my comment?
435 2015-10-15 19:41:15 <sipa> about it breaking the wallet
436 2015-10-15 19:41:32 <CodeShark> can't sidechains use an entirely different mechanism designed from the start into the protocol? Why should sidechains limit themselves to the fields in the original satoshi protocol?
437 2015-10-15 19:41:44 <gmaxwell> I don't think anyone cares about the nsequence semantics in gretat details; except that it's preferable to use as few a bits as can be used without impact.
438 2015-10-15 19:41:50 <btcdrak> maaku: this was sipa's two comments: https://github.com/bitcoin/bitcoin/pull/6312/files#r41899674
439 2015-10-15 19:42:42 <btcdrak> gmaxwell: I agree. I think we've nailed using as few bits as possible and that should be enough. The semantics are less important
440 2015-10-15 19:42:49 <maaku> sipa: does the wallet filter out non-final transactions from display?
441 2015-10-15 19:42:50 <sipa> CodeShark: they shouldn't limit themselves to anything, but being able to reuse code (and having clients being able to reuse their code!) is useful
442 2015-10-15 19:42:58 <gmaxwell> CodeShark: because the bitcoin ecosystem stinks. The problem is that every application reimplements the protocol on its own, so every divergence or change is like walking on a bed of glass. I don't really think its a consideration here; but I do think that if its something we'd want to change in a sidechain thats a sign that its flexibility that might eventually be wanted in bitcoin.
443 2015-10-15 19:42:58 <GreenIsMyPepper> gmaxwell: +1
444 2015-10-15 19:42:58 <sipa> maaku: yes
445 2015-10-15 19:43:27 <maaku> sipa: interesting. ok then honestly I'd rather revert to the prior skip-not-found-inputs behavior
446 2015-10-15 19:43:41 <maaku> (the breakage was your suggestion btw ;) )
447 2015-10-15 19:43:46 <sipa> maaku: i would really really prefer a pass-heights-and-times in...
448 2015-10-15 19:44:02 <maaku> sipa: that's what the view is
449 2015-10-15 19:44:17 <maaku> but that's not backportable change anyway
450 2015-10-15 19:44:25 <maaku> so it's something work work on separately
451 2015-10-15 19:44:37 <gmaxwell> having non-confirmed tx not show up in the wallet right away isn't a big deal, I think.
452 2015-10-15 19:44:49 <maaku> gmaxwell: this is about confirmed tx with spent outputs
453 2015-10-15 19:44:53 <jonasschnelli> It's mainly that part that needs adaption: https://github.com/bitcoin/bitcoin/blob/b94ae81576c199c9a44453b8c9b17e8303f67b72/src/wallet/wallet.cpp#L1319
454 2015-10-15 19:45:52 <gmaxwell> Though seperately, I think CSV is not on target for the end of the month. The amount of activity and progress has been tremendous and positive; but also demonstrating that the semantics were not quite as mature as we'd hoped.
455 2015-10-15 19:46:34 <sipa> maaku: view currently isn't adequate, but you only need a few pieces of data from it... i think it's much simpler to just pass those in
456 2015-10-15 19:46:38 <morcos> gmaxwell: yes i think thats clear
457 2015-10-15 19:47:27 <wumpus> tend to agree
458 2015-10-15 19:47:34 <BlueMatt> yup, sadly :(
459 2015-10-15 19:48:10 <gmaxwell> Well its good news that we made this progress, not bad news.
460 2015-10-15 19:48:37 <maaku> what's the topic to be decided here?
461 2015-10-15 19:49:10 <btcdrak> maaku: whether anyone cares about you moving bits: the answer seems to be go for it
462 2015-10-15 19:49:12 <gmaxwell> maaku: dunno, btcdrak wanted to talk about it. I don't think there is any decision point on this right now.
463 2015-10-15 19:49:12 <maaku> I would appreciate reviews and explicit ACK/NACK of the code in #6312
464 2015-10-15 19:49:13 <wumpus> nothing to be decided AFAIK, people just wanted to discuss it
465 2015-10-15 19:49:52 <maaku> I will revert lack-of-utxo to be a pass-though again, to address sipa's nit
466 2015-10-15 19:49:58 <morcos> maaku: but can you tell us when you're done changing it
467 2015-10-15 19:49:59 <CodeShark> the short-term benefits of a relative time lock (regardless of semantics) outweighs the long-term concerns I have about eating up bits since I'm hoping eventually we'll have better upgrade mechanisms in the long run :)
468 2015-10-15 19:50:02 <CodeShark> but perhaps I'm too optimistic
469 2015-10-15 19:50:07 <gmaxwell> maaku: I can go post that I'm fine with the semantics changes you propose. I think I will be fine with _any_ minor changes to the semantics.
470 2015-10-15 19:50:10 <maaku> what is the decision point / deadline for BIPS 68, 112, 113?
471 2015-10-15 19:50:17 <btcdrak> maaku: i's say make the change you suggested on the ML, fix the bug from sipa and then let's review the code again.
472 2015-10-15 19:50:24 <morcos> for end of oct release, id say we're well past that
473 2015-10-15 19:50:34 <gmaxwell> So this might be modulated slightly by the recent emergency software updates.
474 2015-10-15 19:50:44 <btcdrak> gmaxwell: please do post that
475 2015-10-15 19:50:46 <morcos> maaku: I'm leaning towards sipa's suggested manner of fixing it
476 2015-10-15 19:51:12 <maaku> morcos: i strongly oppose but it's a moot point: that's not back portable
477 2015-10-15 19:51:17 <maaku> for the soft-fork it has to be a simple back port
478 2015-10-15 19:51:25 <maaku> we can fix the api for 0.13
479 2015-10-15 19:51:49 <gmaxwell> Basically, our prior tennative plan as I understood it was that we were going to look to do a CLTV soft fork prior to 0.12 with end of oct as a close date; with a hope of perhaps getting the other locktime changes in.
480 2015-10-15 19:51:55 <btcdrak> OT: if we are sure CSV wont make it for the Oct release, I'd say we should proceed with CLTV softfork.
481 2015-10-15 19:52:27 <sipa> maaku: i don't think it's specifically hard to back port - it would just add some functions
482 2015-10-15 19:52:43 <sipa> adding function is easy - changing many calls is hard
483 2015-10-15 19:52:46 <btcdrak> gmaxwell: it's unrealistic because we need to get backports to 0.11 and 0.10 and also review those, and we dont have any ACKs yet at all on BIP113's implementation sadyly
484 2015-10-15 19:52:52 <gmaxwell> I think that CSV/friends is almost certantly off for that right now;  but I also think that last weeks emergency update may have also modulated the plan slightly for CLTV.  (My concern is related to tolerance for revision cycling).
485 2015-10-15 19:52:53 <morcos> I think that it makes sense for the semantics and code to be finalized for at least a month before release for consensus code.  We still need fixes before we can review again.
486 2015-10-15 19:52:53 <wumpus> btcdrak: agree, but let's first wait a bit for 0.11.1 rollout
487 2015-10-15 19:53:23 <maaku> if we could at least get 113 in for CLTV that would be great
488 2015-10-15 19:53:29 <maaku> but no one has reviewed it
489 2015-10-15 19:53:30 <wumpus> gmaxwell: though the softfork was never meant as a 'normal' revision, it should be softfork only
490 2015-10-15 19:54:13 <morcos> maaku: that's a good point, has there been any objection at all to 113?
491 2015-10-15 19:54:14 <btcdrak> Would people be willing to review BIP113's implementation for this week? https://github.com/bitcoin/bitcoin/pull/6566 median-past locktime
492 2015-10-15 19:54:16 <wumpus> but yes, not right now immediately
493 2015-10-15 19:54:20 <gmaxwell> wumpus: I agree sure, but its still a software upgrade for miners.
494 2015-10-15 19:54:36 <gmaxwell> I think 113 is really great.
495 2015-10-15 19:54:56 <maaku> I can rebase #6566 to not depend on #6312
496 2015-10-15 19:54:59 <morcos> gmaxwell partied here
497 2015-10-15 19:55:00 <wumpus> #action review https://github.com/bitcoin/bitcoin/pull/6566 median-past locktime
498 2015-10-15 19:55:10 <BlueMatt> 5 minutes remaining?
499 2015-10-15 19:55:11 <sipa> maaku: of the 6 commits in 6566, only the last two are unique to bip113?
500 2015-10-15 19:55:12 <btcdrak> maaku: do it
501 2015-10-15 19:55:23 <gmaxwell> I hard stop on the hour, fwiw.
502 2015-10-15 19:55:28 <BlueMatt> same
503 2015-10-15 19:55:28 <maaku> morcos: to my knowledge noone except me has even looked at #6566
504 2015-10-15 19:55:50 <gmaxwell> (unfortunately the same day we set this meeting time another reoccuring meeting was booked for me immediately after it)
505 2015-10-15 19:55:58 <sipa> maaku: i wasn't aware it was independent; i'll look now
506 2015-10-15 19:55:59 <morcos> i reviewed it, but need to again, because i forgot how closely
507 2015-10-15 19:56:24 <btcdrak> maaku: please rebase it to be independent of 6312
508 2015-10-15 19:56:28 <maaku> ok
509 2015-10-15 19:56:58 <wumpus> gmaxwell: well the point is to keep the meeting within the hour so that should be no problem
510 2015-10-15 19:57:07 <wumpus> any last topic?
511 2015-10-15 19:57:47 <BlueMatt> i think we're out of time
512 2015-10-15 19:57:49 <BlueMatt> thanks all
513 2015-10-15 19:57:51 <wumpus> #meetingexit
514 2015-10-15 19:57:56 <wumpus> #exitmeeting
515 2015-10-15 19:57:59 <wumpus> eh
516 2015-10-15 19:58:13 <maaku> sipa: well BIP 113 is independent: "locktime checks have an endpoint of GetMedianTimePast() of the prior block"
517 2015-10-15 19:58:14 <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-dev/2015/bitcoin-dev.2015-10-15-19.01.log.html
518 2015-10-15 19:58:14 <lightningbot> Meeting ended Thu Oct 15 19:58:14 2015 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
519 2015-10-15 19:58:14 <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-dev/2015/bitcoin-dev.2015-10-15-19.01.html
520 2015-10-15 19:58:14 <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-dev/2015/bitcoin-dev.2015-10-15-19.01.txt
521 2015-10-15 19:58:14 <wumpus> #endmeeting
522 2015-10-15 19:58:54 <maaku> sipa: but that affects both absolute and relative lock-time, so #6566 is written on top of #6312 and does both changes
523 2015-10-15 19:59:05 <sipa> maaku: got it
524 2015-10-15 19:59:17 <maaku> I'll rebase to do only the nLockTime change
525 2015-10-15 20:00:35 <jonasschnelli> gmaxwell: I'd like to see what people think about an option to add flagged nodes (like whitebind). These nodes need to auth over nonce signing with a pre-shared pubkey and use a encrypted channel over ECDH aes key exchange and could therefore access additional services (like wallet related stuff), gain privileges and hide traffic to merkleblock, etc..
526 2015-10-15 20:00:46 <jonasschnelli> Maybe to far way from reality...
527 2015-10-15 20:01:17 <sipa> the encryption isn't as important and the authentication
528 2015-10-15 20:01:48 <sipa> so you know you're talking to your trusted full node, and being MitM'ed
529 2015-10-15 20:01:54 <jonasschnelli> sipa: for SPV it would be a nice addition (encryption)
530 2015-10-15 20:02:29 <sipa> it would add privacy from passive attackers, yes, and i think that opportunistic encryption is useful anyway
531 2015-10-15 20:02:53 <jonasschnelli> having an encrypted channel would a node allow to send additional data like access to txindex or addressindex
532 2015-10-15 20:02:59 <sipa> jonasschnelli: ???
533 2015-10-15 20:03:09 <sipa> what does encryption have to do with that
534 2015-10-15 20:03:22 <sipa> for things like that, you need a server that trusts the client
535 2015-10-15 20:03:30 <sipa> which is authentication the other way
536 2015-10-15 20:03:44 <gmaxwell> jonasschnelli: how would you propose configuring the authentication?  And why wouldn't that just use symmetric keying (a question; trying to understand the application)
537 2015-10-15 20:04:56 <jonasschnelli> gmaxwell: storing a symmetric key on the node would be a risk IMO. ECDH would kind-of replace the stunnel (etc.) option.
538 2015-10-15 20:05:37 <sipa> let's talk about encryption and authentication separately
539 2015-10-15 20:06:03 <jonasschnelli> sipa: right additional services authentication is more important. But i think it should be nice if i could encrypt traffic so my ISP can't listen to my bloomfilters, etc.
540 2015-10-15 20:06:17 <sipa> you want host authentication for spv clients that talk to a trusted server
541 2015-10-15 20:06:43 <sipa> you want client authentication for servers that provide potentially expensive indexing services
542 2015-10-15 20:06:57 <gmaxwell> jonasschnelli: I'm not clear about the risks you are thinking about. I agree it's preferable, but someone with access to the node necessarily has the power to impersonate it, and mitm it. If you have write access, you can update its access list. Asymetric crypto doesn't meaningfully help these things.
543 2015-10-15 20:07:09 <GreenIsMyPepper> increasing the cost of passive attackers is always nice, provided that it's not visually viewed as secure/encrypted in the UI
544 2015-10-15 20:07:26 <sipa> GreenIsMyPepper: indeed, that's opportunistic encryption
545 2015-10-15 20:09:52 <jonasschnelli> Okay. let me think about it more detailed... I just want to avoid detaching a wallet the requires p2p and RPC.
546 2015-10-15 20:10:02 <gmaxwell> jonasschnelli: wrt stunnel, this sounds like you're talking about replacing RPC?
547 2015-10-15 20:10:27 <sipa> jonasschnelli: the additional-services-over-p2p thing is somewhat a replacement for rpc
548 2015-10-15 20:10:41 <jonasschnelli> sipa: right.
549 2015-10-15 20:11:08 <CodeShark> I've anguished with this problem a lot - because until we have something like TXO commitments (or some mechanism for proving the validity of the query results not requiring full validation) the security model stinks :p
550 2015-10-15 20:11:28 <jonasschnelli> gmaxwell: No only but also for RPC. Unencrypted p2p taffic for a SPV->trusted-node connection is somehow bad and would require the avoid bloomfilter to ensure privacy..
551 2015-10-15 20:11:36 <gmaxwell> In any case, doing a crypto layer for p2p, and doing it well will be a really considerable effort... including not doing things that make nodes gratitiously fingerprintable (e.g. trackable as they change IPs)
552 2015-10-15 20:11:54 <sipa> my original thought a long time ago was just to introduce EC host keys, which are advertized in addr messages, and if enabled, used for ECDH to establish a session key for authentication and encryption
553 2015-10-15 20:12:00 <sipa> but that does make fingerprinting much easier
554 2015-10-15 20:12:20 <sipa> so you probably want the host keys only to be used when explicitly known to the client beforehand
555 2015-10-15 20:13:11 <jonasschnelli> sipa: Yes. I think it would make more sense to initially share them on a different channel.
556 2015-10-15 20:13:33 <CodeShark> I am strongly opposed to using the p2p messages for trusted communications
557 2015-10-15 20:14:04 <CodeShark> but encrypting just for the sake of passive eavesdroppers is ok
558 2015-10-15 20:14:31 <sipa> it's a pity that you can't even get TOFU security if you want to avoid fingerprinting :(
559 2015-10-15 20:14:32 <gmaxwell> There are protocols that avoid the fingerprinting; e.g. (the server protectng mode of) https://www.ietf.org/proceedings/54/I-D/draft-ietf-ipsec-jfk-04.txt
560 2015-10-15 21:01:30 <warren> Luke-Jr: I was thinking, perhaps similar to your -support list idea, #bitcoin-support might be worthwhile.  Could be less noisy than #bitcoin and thus a more productive space for volunteers who want to help.  Off-topic discussion can be moved away from it.
561 2015-10-15 21:02:02 <Luke-Jr> #bitcoin isn't usually that noisy IMO, but ok
562 2015-10-15 21:02:53 <warren> #bitcoin has no restriction aside from spamming, which makes it perhaps not great for volunteers to follow if they really do want to help.
563 2015-10-15 21:03:49 <gmaxwell> please do not divert support traffic out of #bitcoin.
564 2015-10-15 21:03:55 <gmaxwell> If you do that I will forcefully close the channel.
565 2015-10-15 21:04:21 <gmaxwell> right now the support traffic (that pretty reliably gets answered there) is some of the few things that prevent it from becoming a useless cesspool.
566 2015-10-15 21:04:59 <gmaxwell> warren: you're talking about a subject which you are not well informed, it is entirely untrie that the channel has no restriction aside from spamming.
567 2015-10-15 21:05:17 <gmaxwell> It is actively moderated; better than this channel often.
568 2015-10-15 21:05:56 <warren> gmaxwell: oh ok, closing channel
569 2015-10-15 21:21:56 <midnightmagic> fwiw, #bitcoin has *significant* and *strict* rules about discussion, spam, what's on-topic, and *regularly* boots out people who violate even just the civility rule.
570 2015-10-15 21:30:06 <btcdrak> gmaxwell: rememebr to post to the ML about sequence number please.