1 2016-01-14 00:05:54 <benjyz1> I understand if one wants to argue one way or another. technical here however simply means: remaining fully anonymous
  2 2016-01-14 00:09:14 <rael_wiki> hi, I am using python-bitcoinlib to perform rpc calls to a bitcon node. I deal with amounts in satoshis, so, when I send an amount to my node via rpc, I need to convert the amount to BTC. That means my amounts turn from integers to floats. To avoid rounding I wanted to use python's Decimals but doing so, when python-bitcoinlib's module receives my dictionary and tries to convert it to json, it is not able to convert decimals. Any help on how to send
  3 2016-01-14 00:09:42 <rael_wiki> Any help on how to send such requests without losing precision?
  4 2016-01-14 01:07:09 <alpalp> real_wiki: format as a string, padding with zeros
  5 2016-01-14 01:07:15 <alpalp> rael_wiki, see above
  6 2016-01-14 01:26:14 <alpalp> if you are using python-bitcoinlib you have enough precision with with floats.
  7 2016-01-14 01:32:05 <nwilcox> What's the roadmap for ./src/json? Is it being maintained/improved or replaced?
  8 2016-01-14 01:34:11 <rael_wiki> alpalp: thank you, I can't use a string padded with zeroes because the rpc protocol requires a json real number
  9 2016-01-14 01:34:38 <rael_wiki> alpalp: so can I be sure that python floats are never rounded before the 8th decimal?
 10 2016-01-14 01:36:01 <alpalp> no worse than JSON real's.
 11 2016-01-14 01:41:37 <alpalp> 64-bit floating point numbers give you about 15-17 significant digits.
 12 2016-01-14 01:43:02 <rael_wiki> alpalp: all right, thank you
 13 2016-01-14 01:45:14 <Luke-Jr> rael_wiki: have fun https://github.com/jgarzik/python-bitcoinrpc/pull/63
 14 2016-01-14 01:45:42 <Luke-Jr> alpalp: JSON does not have "real's"
 15 2016-01-14 01:45:57 <alpalp> the python lib does.
 16 2016-01-14 01:48:00 <rael_wiki> Luke-Jr: yeah, sorry, with JSON 'reals' I meant a numeric type (i.e. 2.75 instead of the string '2.75')
 17 2016-01-14 01:48:48 <Luke-Jr> rael_wiki: I think python-bitcoinlib is based on python-bitcoinrpc, so you can probably port the fix
 18 2016-01-14 01:49:08 <alpalp> should have just used satoshis :(
 19 2016-01-14 01:49:32 <rael_wiki> Luke-Jr: thanks a lot for your pull request
 20 2016-01-14 01:51:42 <Luke-Jr> alpalp: yes
 21 2016-01-14 01:53:45 <merlincorey> Luke-Jr: what is the fix?
 22 2016-01-14 01:53:57 <Luke-Jr> merlincorey: encoding the Decimal type correctly
 23 2016-01-14 01:54:54 <merlincorey> I use that library (python-bitcoinrpc) -- so I guess mine is already patched
 24 2016-01-14 01:55:07 <merlincorey> what is good about python-bitcoinlib over it?
 25 2016-01-14 01:55:16 <merlincorey> (general question)
 26 2016-01-14 01:55:26 <Luke-Jr> merlincorey: I just submitted the PR for the fix, so you wouldn't have it..
 27 2016-01-14 01:55:45 <rael_wiki> Luke-Jr: now that you mention it, I've recently had to change the code of that library for my personal use. In fact, when running ~10 processes which concurrently performed rpc requests to a single 0.11 bitcoin node, the node got stuck at random points. After investigating it a bit, I believe it was because those different processes often sent the same request id, which, I think in some way messed up with the node's management of requests.
 28 2016-01-14 01:55:47 <merlincorey> Luke-Jr: then I WILL have it :P
 29 2016-01-14 01:55:53 <merlincorey> Luke-Jr: but I don't use Decimal type anyway
 30 2016-01-14 01:56:12 <rael_wiki> Luke-Jr: I fixed it by changing the library so that concurrent processes always use different request ids. If you want some more details I can send you some more data and the code that apparently fixed the issue.
 31 2016-01-14 01:56:34 <Luke-Jr> rael_wiki: are you the same person who reported that a few hours ago?
 32 2016-01-14 01:56:45 <Luke-Jr> lorenzoasr
 33 2016-01-14 01:57:00 <rael_wiki> Luke-Jr: me and that user ( lorenzoasr ) are working together on this
 34 2016-01-14 01:58:42 <Luke-Jr> ok, so not independent confirmation :x
 35 2016-01-14 01:59:45 <rael_wiki> Luke-Jr: I just mentioned it to have some more opinions about it, if you have any idea about the reason why that happend or a better fix I would gladly hear it ;)
 36 2016-01-14 02:01:18 <Luke-Jr> rael_wiki: if you want to help track it down, it'd be nice to have a rpc test that can reproduce it (see qa/rpc-tests dir)
 37 2016-01-14 02:06:04 <rael_wiki> Luke-Jr: we'd gladly look into it, although not today, as it's 3AM at the moment where I'm writing from. In case, if we have any doubts about how to write those tests we will ask in this channel
 38 2016-01-14 02:06:50 <Luke-Jr> >_<
 39 2016-01-14 02:55:37 <petertodd> rael_wiki: python-bitcoinlib uses python integers internally; conversion to/from on the RPC layer is done at the last minute, so any conversion issues have to be fixed there
 40 2016-01-14 11:56:57 <halvors> Aborted (core dumped)"
 41 2016-01-14 11:56:57 <halvors> But when starting bitcoin i get the error: "bitcoind: chainparams.cpp:124: CMainParams::CMainParams(): Assertion `consensus.hashGenesisBlock == uint256S("0x00000000a26e561bb46c262b714ea6495fd7de8b83b70dba20a1e50bebcb6496")' failed.
 42 2016-01-14 11:56:57 <halvors> http://pastebin.com/bM0Fvw23
 43 2016-01-14 11:56:57 <halvors> I'm trying to create a new genesis block for my experiement.
 44 2016-01-14 11:56:57 <halvors> I've replaced the block hash, the timestamp, the time, the nonce and the merkle in the source code.
 45 2016-01-14 11:56:57 <halvors> That is my generated block
 46 2016-01-14 11:57:11 <halvors> Any ideas what i'm doing wrong here?
 47 2016-01-14 12:15:05 <paveljanik> halvors, here, the only thing you are doing wrong, is asking your questions. Different hash of genesis block -> altcoin -> off topic. You have to find the assert in the source code and change it... Look at src/chainparams.cpp#78. But please ask in #altcoins or elsewhere. Thank you.
 48 2016-01-14 13:11:02 <halvors> It's tecnically still bitcoin. Just want to experiement with the technology :)
 49 2016-01-14 14:11:06 <Chris_Stewart_5> Morning everyone!
 50 2016-01-14 14:59:21 <dhill> PSA, openssh users -> https://twitter.com/marver/status/687643518861471745
 51 2016-01-14 14:59:31 <dhill> UseRoaming no in your ssh_config
 52 2016-01-14 16:37:17 <Luke-Jr> http://www.mail-archive.com/misc@openbsd.org/msg144351.html
 53 2016-01-14 17:46:39 <bsm117532> I'm trying to understand this extension block/generalized soft fork discussion. Do I understand correctly that the 1MB standard bitcoin block must have an additional anyone-can-spend or an anyone-can-pay output in the coinbase, corresponding to netting out the extension block?
 54 2016-01-14 17:50:08 <maaku> bsm117532: there are many ways to implement extension blocks
 55 2016-01-14 17:50:38 <maaku> i'm not sure why that would be necessary
 56 2016-01-14 17:51:11 <gavinandresen> hey maaku, you busy?  I'm thinking about validation cost metrics today...  https://gist.github.com/gavinandresen/4135d03a56e0ecd146c7
 57 2016-01-14 17:51:14 <bsm117532> Ok then how to you net out the contents of the extension block?
 58 2016-01-14 17:51:46 <bsm117532> Depending on how it was implemented, it might look like coin creation to old clients (so be invalid).
 59 2016-01-14 17:52:18 <maaku> gavinandresen: jonas nick would be the one to talk to ... i actually don't know his nick if he is on here
 60 2016-01-14 17:52:43 <gavinandresen> maaku: thanks, I'll see if I have his email and if not ask you to connect us
 61 2016-01-14 17:52:45 <maaku> he has a solid metric that predicts validation cost with really good accuracy, it was presented at Scaling Bitcoin HK
 62 2016-01-14 17:53:03 <jonasschnelli> nickler is his nick i guess
 63 2016-01-14 17:53:15 <maaku> bsm117532: what do you mean "net out" and why do you need to do that?
 64 2016-01-14 17:53:44 <maaku> bsm117532: extension block is a sidechain. you use the two-way peg to move between them
 65 2016-01-14 17:53:49 <gavinandresen> to save me looking at the code... is the segwit soft fork going to use accurate sigop counting or the inaccurate old method?
 66 2016-01-14 17:53:57 <bsm117532> maaku: The sum of all transactions in the extension block have to go somewhere, as seen by old clients...
 67 2016-01-14 17:54:07 <maaku> bsm117532: nope, they don't
 68 2016-01-14 17:54:17 <bsm117532> Ok, why not?
 69 2016-01-14 17:54:34 <maaku> why would they? old clients don't see the extension block, they don't care at all what happens there
 70 2016-01-14 17:55:02 <bsm117532> So funds that got transferred in an extension block would always have to stay in the extension block?
 71 2016-01-14 17:56:10 <instagibbs> "nickler" is his irc nick but he aint on
 72 2016-01-14 17:56:19 <instagibbs> oh wait, yes he is
 73 2016-01-14 17:57:10 <maaku> bsm117532: same as a sidechain (which an extension block is) -- btc is parked in an output of a specific form when it moves into an extension block
 74 2016-01-14 17:57:15 <jonasschnelli> gavinandresen: https://github.com/sipa/bitcoin/commit/0f9efb009ac84298f57d51ee2283f2c6bdc9b451
 75 2016-01-14 17:57:30 <maaku> when you move funds out, you claim one or more of these parked outputs
 76 2016-01-14 17:57:41 <maaku> no need to involve coinbase or miners
 77 2016-01-14 17:58:59 <bsm117532> If the miners are not involved then this is a lot of new logic in the side of wallets, no?
 78 2016-01-14 17:59:09 <maaku> i don't follow
 79 2016-01-14 17:59:11 <bsm117532> OTOH couldn't miners "hide" some transactions in this manner?
 80 2016-01-14 17:59:24 <gavinandresen> jonasschnelli: thanks... that's using the kinda-sort-accurate p2sh counting method, not the absolutely-accurate method I implemented for BIP101 and would be used with a validation cost metric.
 81 2016-01-14 18:00:23 <bsm117532> maaku: Who is "you" in your above sentence?  It's either the miner or the user and his wallet, crafting this kind of tx.
 82 2016-01-14 18:00:31 <jonasschnelli> gavinandresen: open a PR on sipas segwith2 branch: https://github.com/sipa/bitcoin/pulls   :-)
 83 2016-01-14 18:00:38 <instagibbs> gavinandresen, nickler and I used your branch for the talk, with a bunch of stuff tacked on
 84 2016-01-14 18:01:47 <maaku> bsm117532: yes, using the extension block at all (not just moving funds) requires wallet upgrades
 85 2016-01-14 18:01:50 <gavinandresen> jonasschnelli: just thinking through whether or not it would matter in the future-- not worth the extra complexity if it won't
 86 2016-01-14 18:02:20 <maaku> bsm117532: i really don't understand what you are trying to do involving a miner, or really what miners have to do with anything here
 87 2016-01-14 18:02:22 <jonasschnelli> Agreed. To bad sipa is not here.
 88 2016-01-14 18:02:58 <gavinandresen> If a validation metric dynamic limit would have to be done as a hard fork, then I don't think it matters-- the counting rule can change willy-nilly.
 89 2016-01-14 18:03:01 <maaku> gavinandresen: It is my intention to propose replacing the cost accounting sipa wrote with nickler's cost metric
 90 2016-01-14 18:03:41 <maaku> i should have mentioned though that instagibbs knows quite a bit about this as well
 91 2016-01-14 18:03:44 <gavinandresen> maaku: before the segwit soft fork or after ?
 92 2016-01-14 18:03:52 <bsm117532> Not trying to "do" anything, just trying to understand how it would work. Miners are creating these new blocks so there must be some kind of rules as to their structure.
 93 2016-01-14 18:03:57 <instagibbs> https://github.com/instagibbs/bitcoin/tree/rt
 94 2016-01-14 18:04:00 <maaku> he and nickler organized the HK talk regarding this
 95 2016-01-14 18:04:13 <maaku> gavinandresen: before
 96 2016-01-14 18:04:38 <gavinandresen> maaku: awesome
 97 2016-01-14 18:04:58 <maaku> gavinandresen: no idea if I can get others to agree though :P
 98 2016-01-14 18:05:00 <bsm117532> What I'm actually noodling about is making the beads in a braid be actual bitcoin blocks, and soft-forking it in this way. The beads in the braid become "extension blocks" in exactly the same way.
 99 2016-01-14 18:05:02 <gavinandresen> I won't bother sipa about the vague statement in the segwit spec about sigop counting :)
100 2016-01-14 18:06:13 <maaku> bsm117532: it's easiest to understand extension blocks as sidechains -- read the sidechains whitepaper if you need to know how those work
101 2016-01-14 18:06:47 <bsm117532> I'll read it again. That's not the only way to do it though, right?
102 2016-01-14 18:06:47 <maaku> the extension block is a sidechain exactly like bitcoin in every way, and the sidechain peg between the two is consensus-enforced (full nodes watch both blocks)
103 2016-01-14 18:07:13 <maaku> bsm117532: sure there's an infinite number of ways to do it, but that's certainly the reference way
104 2016-01-14 18:07:55 <bsm117532> Ok.  At first I didn't like this idea at all but I'm coming around. It's certainly better than a hard fork.
105 2016-01-14 18:08:48 <BlueMatt> bsm117532: eww
106 2016-01-14 18:08:57 <BlueMatt> bsm117532: its listed under the "risks" section in the sidechains whitepaper for a reason
107 2016-01-14 18:09:27 <bsm117532> Do the wallet modifications have to diddle with whether their tx's appear in extension blocks, utxo's were in extension blocks, etc?  Or is as simple as wallets broadcasting a new tx version number?
108 2016-01-14 18:09:46 <BlueMatt> the first one
109 2016-01-14 18:09:55 <bsm117532> Ok, then yuck.
110 2016-01-14 18:10:06 <bsm117532> That's why I was thinking about miners doing it.
111 2016-01-14 18:10:08 <BlueMatt> and a bunch of logic for moving your coins out of the extension block to pay someone who hasnt "opted into this blocksize increase"
112 2016-01-14 18:10:12 <BlueMatt> it really is not a softfork
113 2016-01-14 18:10:26 <BlueMatt> i mean is, but the way it works it is really, really not
114 2016-01-14 18:10:54 <maaku> it really is gross
115 2016-01-14 18:11:10 <bsm117532> But if miners put things into extension blocks, without cooperation of wallets... it fucks up SPV, no?
116 2016-01-14 18:11:15 <maaku> also, it's a tiny tiny itsy bitsy step from there to evil fork
117 2016-01-14 18:11:48 <BlueMatt> bsm117532: if you do that you'll fuck up any number of things
118 2016-01-14 18:12:13 <BlueMatt> bsm117532: one other issue is that the decision about whether a transaction can be in the "other block" needs to be picked by the receiver
119 2016-01-14 18:12:15 <BlueMatt> not the sender
120 2016-01-14 18:12:34 <bsm117532> Well, old nodes have a divergent utxo set.
121 2016-01-14 18:12:38 <bsm117532> BlueMatt: ah I see...
122 2016-01-14 18:13:01 <maaku> bsm117532: you can't let the utxo set diverge
123 2016-01-14 18:13:11 <maaku> that's definately a failure mode
124 2016-01-14 18:13:23 <bsm117532> That's why I rejected the idea when I first heard it...
125 2016-01-14 18:13:41 <maaku> right ok, and that's the reason for the sidechain mechanism
126 2016-01-14 18:13:57 <maaku> the classic blocks and the extension blocks have different utxo sets
127 2016-01-14 18:14:12 <bsm117532> Ok I think I understand better, thanks.  Will look over the sidechain paper again. But I think I might just omit the topic from the braids paper.
128 2016-01-14 18:59:51 <wumpus> meeting?
129 2016-01-14 18:59:58 <btcdrak> wumpus ack
130 2016-01-14 19:00:04 <wumpus> #startmeeting
131 2016-01-14 19:00:05 <lightningbot`> Meeting started Thu Jan 14 19:00:05 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
132 2016-01-14 19:00:05 <lightningbot`> Useful Commands: #action #agreed #help #info #idea #link #topic.
133 2016-01-14 19:00:11 <kanzure> can we get some links to the segwit bips?
134 2016-01-14 19:00:22 <wumpus> where?
135 2016-01-14 19:00:57 <kanzure> ah okay, found them.
136 2016-01-14 19:01:00 <wumpus> any topics?
137 2016-01-14 19:01:13 <btcdrak> kanzure: https://github.com/bitcoin/bips/blob/master/README.mediawiki
138 2016-01-14 19:01:13 <kanzure> https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki https://github.com/bitcoin/bips/blob/master/bip-0142.mediawiki https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki
139 2016-01-14 19:01:41 <jtimon> I would like to talk about consensus code encapsulation if there's time
140 2016-01-14 19:01:55 <morcos> i would like to talk about versionbits
141 2016-01-14 19:02:09 <jtimon> +1 versionbits as topic
142 2016-01-14 19:02:12 <btcdrak> ack on versionbits
143 2016-01-14 19:02:13 <wumpus> ok, let's start with versionbits
144 2016-01-14 19:02:14 <cfields> second both of those
145 2016-01-14 19:02:15 <wumpus> #topic versionbits
146 2016-01-14 19:02:24 <btcdrak> #link https://github.com/bitcoin/bitcoin/pull/6816
147 2016-01-14 19:02:42 <morcos> ok, i'm volunteering to take over championing this as both rusty and CodeShark say they are busy on other things
148 2016-01-14 19:02:50 <wumpus> great!
149 2016-01-14 19:02:51 <btcdrak> CodeShark updates his implementation #6816 and rebased to current master
150 2016-01-14 19:03:01 <btcdrak> *updated
151 2016-01-14 19:03:04 <morcos> btcdrak: i don't know if i'm going to use his implementation or not
152 2016-01-14 19:03:14 <morcos> i'd like to spend some time reviewing what rusty did first and then decide
153 2016-01-14 19:03:15 <btcdrak> morcos: sure just a data point.
154 2016-01-14 19:03:26 <morcos> so lets not ask people to review yetg
155 2016-01-14 19:03:38 <btcdrak> #link https://github.com/rustyrussell/bitcoin/compare/bip-9-versionbits
156 2016-01-14 19:03:39 <morcos> but the general point i wanted to make
157 2016-01-14 19:03:53 <jtimon> I had some feedback for the "API" for both CodeShark's and rusty's implementation
158 2016-01-14 19:04:09 <morcos> is i feel fairly strongly about trying to implement segwit in a way that will be compatible with other implementations possibly trying to do something else at the same time
159 2016-01-14 19:04:23 <jtimon> IMO they we're both more complecated than needed while not flexible enough chainparams-wise
160 2016-01-14 19:04:42 <morcos> if the other implementations are not using nVersion for their signaling, then we have no problem doing whatever we want
161 2016-01-14 19:04:44 <btcdrak> morcos: I agree, versionbits BIP9 spec should have a final implementation.
162 2016-01-14 19:04:59 <morcos> however if they are, then not conflicting will be important so users of other versions can also support segwit
163 2016-01-14 19:05:06 <morcos> i'm bringing this all up
164 2016-01-14 19:05:06 <sipa> ack there
165 2016-01-14 19:05:30 <morcos> b/c if we agree with this approach, it may be necessary to front burner version bits to go along with segwit
166 2016-01-14 19:05:31 <jtimon> morcos if you are interested on early review of your "API" (the functions that are going to be called from outside) I'm happy to do so
167 2016-01-14 19:05:54 <morcos> jtimon: ok, well let me get started first
168 2016-01-14 19:06:24 <jtimon> morcos: sure, or maybe I can suggest an empty skeleton for you to consider?
169 2016-01-14 19:06:28 <morcos> anyway thats all i wanted to say, but i think its helpful to set expectations on priorities
170 2016-01-14 19:07:07 <morcos> jtimon: i'm probably going to start from rusty's code or codeshark's.  i think there may be time pressure to get this done quickly so i don't want to start from scratch.
171 2016-01-14 19:07:34 <Luke-Jr> (would like to see versionbits become less tied to Core's implementation if possible)
172 2016-01-14 19:07:51 <morcos> Luke-Jr: what do you mean?
173 2016-01-14 19:07:58 <jtimon> morcos: fine, I can repeat the same suggestions I had for them I guess
174 2016-01-14 19:07:59 <btcdrak> Luke-Jr: so long as it follows the BIP9 it shouldnt matter
175 2016-01-14 19:08:02 <morcos> like all that should matter is the spec?
176 2016-01-14 19:08:24 <morcos> i agree with that, but making sure we have it implemented will help make sure there aren't issues with the spec and that we also have it in time to use
177 2016-01-14 19:08:30 <Luke-Jr> morcos: well, right now it implies Core's intepreting the 4 initial bytes of the block header as a little-endian number
178 2016-01-14 19:08:39 <Luke-Jr> whereas it's proposed to deal with individual bits
179 2016-01-14 19:08:42 <morcos> i'm not going to take on the role of trying to handle how anyone else implements it
180 2016-01-14 19:08:48 <sipa> Luke-Jr: that's a detail
181 2016-01-14 19:08:50 <Luke-Jr> so it ought to just refer to the bits and bytes in order
182 2016-01-14 19:08:53 <jtimon> btcdrak: well, other things matter too (ie consensus code encapsulation)
183 2016-01-14 19:09:04 <wumpus> morcos: right, you shouldn't
184 2016-01-14 19:09:06 <Luke-Jr> sipa: yes, a minor one, but one I'd prefer to see cleaned up :p
185 2016-01-14 19:09:14 <sipa> i think this discussion is going into details that can be discussed on a PR
186 2016-01-14 19:09:21 <wumpus> morcos: don't let too many details and other people's minor concerns distract you
187 2016-01-14 19:09:30 <Luke-Jr> k, drop that topic for now
188 2016-01-14 19:09:43 <morcos> wumpus: ok.  yes. we can move on from the whole topic now i think.
189 2016-01-14 19:09:49 <btcdrak> topic suggestion, status report on segwit
190 2016-01-14 19:10:03 <wumpus> #topic status of segwit
191 2016-01-14 19:10:04 <btcdrak> topic suggestion, 0.12 status
192 2016-01-14 19:10:10 <sipa> segnet3 coming up soon
193 2016-01-14 19:10:21 <Luke-Jr> we've dropped trying to do merge-mining in the same softfork
194 2016-01-14 19:10:27 <sipa> indeed
195 2016-01-14 19:10:43 <sipa> sorry, i'm packing and about to travel, little time now
196 2016-01-14 19:11:18 <wumpus> ok, no problem, let's leave the topic for next week
197 2016-01-14 19:11:28 <btcdrak> let me link bips for the logs
198 2016-01-14 19:11:31 <btcdrak> #link https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki
199 2016-01-14 19:11:31 <Luke-Jr> also, I assigned the BIP drafts to 141-144 to make 14x a "anti-malleability" range
200 2016-01-14 19:11:38 <btcdrak> #link https://github.com/bitcoin/bips/blob/master/bip-0142.mediawiki
201 2016-01-14 19:11:43 <btcdrak> #link https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki
202 2016-01-14 19:11:48 <btcdrak> #link https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki
203 2016-01-14 19:12:13 <Luke-Jr> or maybe 14x will just become segwit if it goes active as expected
204 2016-01-14 19:12:31 <wumpus> good to know
205 2016-01-14 19:13:05 <jtimon> 0.12 status?
206 2016-01-14 19:13:06 <wumpus> #topic 0.12 status
207 2016-01-14 19:13:18 <wumpus> I've tagged 0.12.0rc1 yesterday
208 2016-01-14 19:13:23 <morcos> twice!
209 2016-01-14 19:13:31 <btcdrak> do it again :)
210 2016-01-14 19:13:31 <cfields> haha
211 2016-01-14 19:13:45 <Luke-Jr> https://github.com/bitcoin/bitcoin/pull/7149 needs reviews, but maybe too late for 0.12.0
212 2016-01-14 19:13:52 <wumpus> yes, twice, the first time it didn't build due to a last-minute merge, my fault
213 2016-01-14 19:13:59 <sdaftuar> that's ok, i blame morcos
214 2016-01-14 19:14:10 <Luke-Jr> https://github.com/bitcoin/bitcoin/pull/7339 and https://github.com/bitcoin/bitcoin/pull/7340 should have been in 0.12.0, but are extremely late and possibly impractical to get in
215 2016-01-14 19:14:33 <cfields> gitian builders: i pushed sigs, but there's a small issue with attaching the sigs. see #7342 for the fix.
216 2016-01-14 19:15:10 <wumpus> cfields: does this mean can we still build rc1, or need a new rc?
217 2016-01-14 19:15:14 <Luke-Jr> mostly minor backports in https://github.com/bitcoin/bitcoin/pull/7338
218 2016-01-14 19:15:20 <wumpus> preliminary release notes:
219 2016-01-14 19:15:23 <wumpus> #link https://github.com/bitcoin/bitcoin/blob/0.12/doc/release-notes.md
220 2016-01-14 19:15:36 <cfields> wumpus: rc1 is fine, just fix up the descriptor locally
221 2016-01-14 19:15:50 <jonasschnelli> 0.12 release nodes needs some overhaul
222 2016-01-14 19:15:55 <cfields> we can discuss in -core-dev after the meeting
223 2016-01-14 19:16:04 <MarcoFalke> jonas, there are two pulls
224 2016-01-14 19:16:14 <jonasschnelli> wumpus: nice work on the commit list...
225 2016-01-14 19:16:14 <Luke-Jr> #7340 also exposed a possible bug that may need to be fixed, but not yet determined if it affects the bundled univalue
226 2016-01-14 19:16:18 <wumpus> cfields: well it's good to tell here so that gitian builders that are reading know  what to do
227 2016-01-14 19:16:19 <btcdrak> is #7149 really a bug fix? We tagged RC, doesnt seem right to merge that
228 2016-01-14 19:16:34 <wumpus> cfields: but indeed, can just fix up the descriptor when attaching the signature - building itself is  unaffected
229 2016-01-14 19:16:36 <Luke-Jr> btcdrak: yes, it fixes bugs..
230 2016-01-14 19:16:45 <cfields> ok...
231 2016-01-14 19:17:05 <Luke-Jr> I mean, I could split the tests out if that's a concern, but IMO tests never hurt
232 2016-01-14 19:17:06 <wumpus> btcdrak: I agree we shouldn't merge too much between RCs, only if it is a critical bug fix
233 2016-01-14 19:17:35 <wumpus> and I don't think #7142 is mature enough to merge
234 2016-01-14 19:17:54 <wumpus> so let's leave it for 0.12.1
235 2016-01-14 19:18:03 <Luke-Jr> 7142? Travis stuff?
236 2016-01-14 19:18:12 <cfields> gitian builders: 0.12rc1's osx sig attach descriptor fails due to a missing package (that's not actually needed). Rather than using the in-tree descriptor, use the one from #7342. This is fixed for rc2.
237 2016-01-14 19:18:22 <wumpus> Luke-Jr: eh? I'm confused, sorry
238 2016-01-14 19:18:45 <morcos> wumpus: you said 7142 instead of 7149.  but leave for discussion in 0.12.1 to be clear.
239 2016-01-14 19:19:15 <MarcoFalke> 7142 can be closed
240 2016-01-14 19:19:29 <MarcoFalke> The nightly builds already cover it
241 2016-01-14 19:19:32 <wumpus> morcos: yes, #7149 I meant, thanks
242 2016-01-14 19:19:37 <wumpus> MarcoFalke: awesome
243 2016-01-14 19:19:45 <wumpus> #action close #7149
244 2016-01-14 19:19:53 <jonasschnelli> We should add "fundrawtransaction" and "setban" to the release notes.
245 2016-01-14 19:20:22 <wumpus> I agree those should be documented - though the release notes are really long already
246 2016-01-14 19:20:23 <jtimon> wumpus: close 7142, 7149 or both?
247 2016-01-14 19:20:23 <Luke-Jr> wumpus: close 7142, not 7149 >_<
248 2016-01-14 19:20:39 <wumpus> #action close #7142 not #7149
249 2016-01-14 19:21:06 <wumpus> at some point it makes more sense to document those commands somewhere else, e.g. in the bitcoin.org developer documentation
250 2016-01-14 19:21:10 <wumpus> then link to itin the release notes
251 2016-01-14 19:21:41 <jonasschnelli> wumpus: Yes. Agreed.
252 2016-01-14 19:21:41 <Luke-Jr> ACK delaying 7149 until 0.12.1, since it mostly fixes things broken in all prior releases anyway and miners can/should just use LJR instead of Core
253 2016-01-14 19:21:53 <jonasschnelli> :/
254 2016-01-14 19:21:53 <Luke-Jr> should we document the regressions in release-notes though? I can write something up.
255 2016-01-14 19:22:19 <btcdrak> wumpus: The release notes should mention notable features regardless imo
256 2016-01-14 19:22:37 <wumpus> btcdrak: they are mentioned in the list of pulls at least
257 2016-01-14 19:23:05 <wumpus> btcdrak: shortly mentioning them with a lnk to more documentation also makes sense, but I think the release notes have too much details, they're not meant as a substitute for documentation
258 2016-01-14 19:23:30 <Luke-Jr> #action #7149 delayed to 0.12.1 due to lack of reviews; document regressions it fixes for 0.12.0 in the meantime
259 2016-01-14 19:24:11 <morcos> wumpus: i realized maybe the release notes don't mention the mining code changes
260 2016-01-14 19:24:15 <wumpus> in any case, feel free to improve the release notes, just submit a pull, but make sure you do it on top of https://github.com/bitcoin/bitcoin/pull/7336
261 2016-01-14 19:24:24 <morcos> i'm not sure how much detail you want to go into
262 2016-01-14 19:24:48 <morcos> but it seems reasonable to me to mention the speed increase , lack of blowup on large mempools.
263 2016-01-14 19:24:59 <morcos> but it also might be important to document the new security assumption
264 2016-01-14 19:25:02 <btcdrak> morcos: it's a notable feature IMO
265 2016-01-14 19:25:08 <MarcoFalke> wumpus, you could just merge 7336
266 2016-01-14 19:25:09 <wumpus> just mention that it changed, what is the old behavior, what is the new behavior, but not too much technical details, it would be great to document those but not in the release notes :)
267 2016-01-14 19:25:12 <morcos> that mempool consistency is now used to construct blocks
268 2016-01-14 19:25:35 <morcos> so maybe that last part is too much detail?
269 2016-01-14 19:25:45 <wumpus> no, that sounds fine
270 2016-01-14 19:25:54 <wumpus> MarcoFalke: I'm going to
271 2016-01-14 19:26:31 <MarcoFalke> #action merge #7336
272 2016-01-14 19:27:22 <wumpus> ok, more topics?
273 2016-01-14 19:27:34 <wumpus> #topic consensus code encapsulation
274 2016-01-14 19:27:44 <wumpus> @jtimon
275 2016-01-14 19:27:58 <MarcoFalke> any discussion needed in regard to the website?
276 2016-01-14 19:28:13 <jtimon> ok, so right now I only 4 libconsensus related opened PRs #7091 #7287 #7311 and #7310
277 2016-01-14 19:28:48 <jtimon> I really think that any "big picture branch" will be highly unreadable without merging something like #7310 first
278 2016-01-14 19:29:01 <wumpus> do we have an idea for an API yet for the extended libconsensus?
279 2016-01-14 19:29:15 <btcdrak> jtimon: a big picture branch will let people see your overall vision.
280 2016-01-14 19:29:19 <jtimon> you mean libconsensus + storage ?
281 2016-01-14 19:29:34 <morcos> wumpus: i'm happy to help review an encapsulation type pull for correctness, but i'd prefer to see concept ACK from you/sipa first, b/c i don't trust my own judgement on what makes sense.
282 2016-01-14 19:30:01 <jtimon> I'm redoing things in https://github.com/jtimon/bitcoin/commits/libconsensus-f2 that's the longest "big picture" branch I have
283 2016-01-14 19:30:02 <wumpus> I'm not entirely sure what is the enxt step, but I think it's importnat to know what we want to offer in guiding in how to refactor things
284 2016-01-14 19:30:13 <Diablo-D3> ssh client bug: http://undeadly.org/cgi?action=article&sid=20160114142733
285 2016-01-14 19:30:26 <wumpus> Diablo-D3: offtopic?
286 2016-01-14 19:30:35 <jtimon> well, I'll create another one libconsensus-f3 on top of that with a candidate complete C API
287 2016-01-14 19:30:39 <jonasschnelli> jtimon: did you once thought about a bit-picture in a written form .MD, google doc?
288 2016-01-14 19:31:13 <jtimon> jonasschnelli: I still plan to do the "document with words and pictures" that I was asked to do
289 2016-01-14 19:31:27 <jtimon> but I want to link to code too
290 2016-01-14 19:31:37 <wumpus> yes, makes sense to have both
291 2016-01-14 19:31:54 <jonasschnelli> Agree. Big pic in word and image form, if one needs more, he can check the code.
292 2016-01-14 19:31:59 <btcdrak> The idea of a big picture branch is to let jtimon make the changes he would like ideally without having to think about doing it in stages. That will give everyone else an idea of the big picture implications
293 2016-01-14 19:32:22 <jtimon> and some of the open PRs would really make the document more readable (ie the pictures are basically before-an-after UML diagrams)
294 2016-01-14 19:32:47 <btcdrak> otherwise it seems like we get tons of small PRs and no-one can see the wider picture and thus it is more difficult for review
295 2016-01-14 19:33:08 <jtimon> what about these stages (what I plan to put in the doc)?
296 2016-01-14 19:34:24 <jtimon> 1) have something to call libconsensus: expose verifyScript. Done
297 2016-01-14 19:34:25 <jtimon> 2) put the rest of the consensus critical code, excluding storage in the same building package (see #7091 )
298 2016-01-14 19:34:30 <droark> jtimon: If you need any assistance with the doc, ping me. I may need a little assistance but I like to help with documentation.
299 2016-01-14 19:34:54 <jtimon> 3) discuss a complete C API for libconsensus
300 2016-01-14 19:34:54 <jtimon> 4) separate it into a sub-repository
301 2016-01-14 19:35:43 <jtimon> droark: thanks I'll note that, but usually I have the most problems getting review
302 2016-01-14 19:35:51 <wumpus> sounds good to me, although I like starting with 3 as soon as possible, I reallythink a (preliminary) API would be good to guide this
303 2016-01-14 19:36:27 <wumpus> in any case, it is mostly orthogonal to the moving and refactoring
304 2016-01-14 19:36:49 <droark> jtimon: Gotcha. I'll look at some of the PRs a little later today.
305 2016-01-14 19:36:50 <jtimon> wumpus: sure, that's why I'm not working on master, we can start discussing phase 3 as soon as we have a phase 2 "prototype" it doesn't need to be fully reviewed or "final"
306 2016-01-14 19:36:59 <wumpus> but it gives something more concrete to talk about than code moves
307 2016-01-14 19:37:31 <wumpus> jtimon: right
308 2016-01-14 19:38:04 <jtimon> well, it's not completely orthogonal, you can't build the full C API in the libconsensus package before you have eliminated the unwanted dependencies, etc. But yeah, as for discussion they are mostly orthogonal
309 2016-01-14 19:38:23 <wumpus> ok, suggestion for next topic?
310 2016-01-14 19:38:40 <jtimon> phase 4 (basically moving files to the consensus directory) is also orthogonal, can be done in parallel and practically by anyone
311 2016-01-14 19:38:54 <btcdrak> are we ready to talk about the locktime PRs again?
312 2016-01-14 19:38:54 <jtimon> action review #7091 #7287 #7311 and #7310 ?
313 2016-01-14 19:39:13 <wumpus> #topic locktime PRs
314 2016-01-14 19:39:15 <btcdrak> suggested topic bip68
315 2016-01-14 19:39:55 <wumpus> jtimon: yes I agree it's not completely orthogonal, but it's something that can be discussed seaprately, and we can involve people that are planning to use the interface
316 2016-01-14 19:40:49 <wumpus> btcdrak: anything specific to say about locktime PRs?
317 2016-01-14 19:40:56 <btcdrak> We need to make a choice between 6312 and 7184
318 2016-01-14 19:41:06 <jtimon> wumpus agree, and they usually won't care about the refactorings or the rest of bitcoin core, they usually will ask "what interface? what files?"
319 2016-01-14 19:41:19 <jtimon> wumpus: no action on #7091 #7287 #7311 and #7310 then?
320 2016-01-14 19:41:40 <btcdrak> CNB optimisations were not compatible with 6312 which is how 7184 resulted.
321 2016-01-14 19:41:48 <wumpus> jtimon: you requested people to review them, that's fiine
322 2016-01-14 19:42:13 <jtimon> ok, sorry for insisting, next topic
323 2016-01-14 19:42:16 <morcos> sipa was going to look at #7184 but he got busy on some side project he's working on.  in seriousness though, i think 7184 is a better design for BIP 68 than 6312
324 2016-01-14 19:42:20 <btcdrak> I'm leaning towards closing 6312 for 7184
325 2016-01-14 19:42:49 <morcos> i don't think we need code review of BIP 68 now because i think segwit and probably versionbits take precedence
326 2016-01-14 19:42:53 <btcdrak> "side project" being segwit :-)
327 2016-01-14 19:42:53 <wumpus> looks like there is some agreement to focuso n 7184 instead of 6312 then
328 2016-01-14 19:43:02 <morcos> but it would be nice to concentrate on one approach, and update the BIP to match it
329 2016-01-14 19:43:18 <jtimon> well bip68 is certainly more reviewed than versionbits I think
330 2016-01-14 19:43:40 <morcos> jtimon: yes for sure.  but in terms of priorities to get released.
331 2016-01-14 19:43:57 <btcdrak> morcos: bip68 spec is ewll reviewed, obviously we'd need to update the reference implementation in the BIP to 7184
332 2016-01-14 19:44:11 <morcos> its possible we'll have BIP 68 and 112/113 ready to go by soft fork
333 2016-01-14 19:44:26 <btcdrak> morcos: well until you have a versionbits proposal, we have time to look at 7184
334 2016-01-14 19:44:27 <morcos> but we shouldn't be holding up segwit for them
335 2016-01-14 19:44:52 <jtimon> my previous opposition against redoing many parts of 6312 in 7184 was that it was going to slow things down, so if focusing review on 7184 will make things faster, I'm fine with it
336 2016-01-14 19:45:04 <btcdrak> morcos: BIP113 should be deployed with the next softfork regardless.
337 2016-01-14 19:45:08 <wumpus> ok
338 2016-01-14 19:45:19 <morcos> ok, so lets close 6312 and move to 7184
339 2016-01-14 19:45:25 <wumpus> #action clsoe #6312 in favor of #7174
340 2016-01-14 19:45:26 <btcdrak> ack
341 2016-01-14 19:45:26 <morcos> if there is objection later , we can always reopen
342 2016-01-14 19:45:31 <wumpus> right
343 2016-01-14 19:45:37 <morcos> 7184 wumpus please
344 2016-01-14 19:45:49 <morcos> and don't merge any consensus code changes today
345 2016-01-14 19:45:51 <btcdrak> wumpus has shaky hands today
346 2016-01-14 19:45:55 <jtimon> but nack on "delaying bip68 further because there's higher priorities"
347 2016-01-14 19:46:29 <btcdrak> btw, rusty tested 7184 in combination with 6564 and tACKd both
348 2016-01-14 19:47:15 <btcdrak> aj also has some python demos that test HLTC scripts using CSV, we should pester him for those
349 2016-01-14 19:47:52 <btcdrak> *HTLC,
350 2016-01-14 19:47:54 <jtimon> I just slightly reviewed the diff with 6312 but didn't found anything functionally wrong
351 2016-01-14 19:49:58 <jtimon> so I don't see it as something far away, I think we could merge 7184 relatively soon (after all is based on 6312 which had plenty of testing and review)
352 2016-01-14 19:50:35 <btcdrak> jtimon: yes. actually the cumulative work in 7184 is impressive
353 2016-01-14 19:51:28 <morcos> great.  well when 7184 gets the acks it can be merged.  but we still need code to introduce the soft fork for it anyway
354 2016-01-14 19:51:36 <morcos> i'll fix up the open nits on 7184 pronto
355 2016-01-14 19:51:48 <btcdrak> morcos: the softforking code should be a separate PR.
356 2016-01-14 19:51:54 <sdaftuar> and we should update the BIP's reference implementation
357 2016-01-14 19:52:04 <btcdrak> ok I'll do that
358 2016-01-14 19:52:09 <morcos> btcdrak: yes thats fine.   do you want to update BIP.  perfect.
359 2016-01-14 19:52:22 <btcdrak> yup
360 2016-01-14 19:52:26 <Diablo-D3> wumpus: /amsg
361 2016-01-14 19:53:18 <wumpus> any last topic?
362 2016-01-14 19:53:37 <btcdrak> are we haveing a 0.12 release party?
363 2016-01-14 19:53:38 <jtimon> morcos: we will worry about the softfork later, the first step of merging it as relay policy is a huge step
364 2016-01-14 19:53:50 <wumpus> otherwise I'm going to close the meeting, I'm kind of tired
365 2016-01-14 19:53:56 <btcdrak> ack
366 2016-01-14 19:54:10 <btcdrak> wumpus: +!
367 2016-01-14 19:54:16 <wumpus> #meetingstop
368 2016-01-14 19:54:20 <btcdrak> haha
369 2016-01-14 19:54:20 <wumpus> #stopmeeting
370 2016-01-14 19:54:22 <MarcoFalke> #closemeeting
371 2016-01-14 19:54:25 <btcdrak> nopw
372 2016-01-14 19:54:26 <lightningbot`> Log:            http://www.erisian.com.au/meetbot/bitcoin-dev/2016/bitcoin-dev.2016-01-14-19.00.log.html
373 2016-01-14 19:54:26 <lightningbot`> Meeting ended Thu Jan 14 19:54:26 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
374 2016-01-14 19:54:26 <lightningbot`> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-dev/2016/bitcoin-dev.2016-01-14-19.00.html
375 2016-01-14 19:54:26 <lightningbot`> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-dev/2016/bitcoin-dev.2016-01-14-19.00.txt
376 2016-01-14 19:54:26 <wumpus> #endmeeting
377 2016-01-14 19:54:31 <btcdrak> \o/
378 2016-01-14 19:54:53 <wumpus> btcdrak: release party is for the final release, we're not there yet :p
379 2016-01-14 19:58:12 <Luke-Jr> 1.0?
380 2016-01-14 19:59:02 <jonasschnelli> heh
381 2016-01-14 20:08:34 <maaku> Luke-Jr: I intend to champion a patch to segwit that would include merged mining
382 2016-01-14 20:08:40 <maaku> (segwit supports it now, but could be better)
383 2016-01-14 20:10:06 <Luke-Jr> maaku: eh, I already intend to champion a MM thing.. :p
384 2016-01-14 20:10:49 <maaku> Luke-Jr: what did you want to get in?
385 2016-01-14 20:10:51 <sipa> maaku: the original version i wrote included MM support, but it would be a pain to deploy
386 2016-01-14 20:11:53 <sipa> and figuring out the best way to do would need too much bikeshedding imho
387 2016-01-14 20:12:15 <maaku> morcos: is 7184 back-ported? that's the sole reason 6312 was done the way it was
388 2016-01-14 20:12:34 <sipa> plus it seems there are actual benefits to separating bitcoin-consensus-critical commitments from external commitments
389 2016-01-14 20:12:56 <Luke-Jr> sipa: disagree on that
390 2016-01-14 20:13:08 <sipa> i know you disagree :)
391 2016-01-14 20:13:54 <morcos> maaku: i haven't looked into backporting it.  but i dont' see off the top of my head why it would be at all difficult.
392 2016-01-14 20:14:07 <morcos> what does it need to backport to?  just 0.11 ?
393 2016-01-14 20:14:13 <morcos> well and 0.12 obviously
394 2016-01-14 20:14:21 <sipa> anyway, if you are willing to propose and implement another way to do it, and show that common infrastructure canneasily support it, i'm all for it
395 2016-01-14 20:14:41 <maaku> "<sipa> plus it seems there are actual benefits to separating bitcoin-consensus-critical commitments from external commitments" <--- such as?
396 2016-01-14 20:14:50 <maaku> morcos: every supported version of bitcoind
397 2016-01-14 20:15:14 <morcos> maaku: what are the supported versions of bitcoind?  just 0.11 ?
398 2016-01-14 20:15:18 <morcos> well and 0.12 obviously
399 2016-01-14 20:15:29 <sipa> maaku: forcing more bitcoin consensus related logic into mining stacks
400 2016-01-14 20:15:55 <sipa> maaku: as it means they need to go build the witness tree, store the root, and store the branch to it in the right place
401 2016-01-14 20:15:56 <morcos> sipa: are you planning on backporting segwit to 0.11?
402 2016-01-14 20:16:22 <sipa> maaku: if you separate consensus commitments, those can just remain under control of bitcoind
403 2016-01-14 20:17:27 <sipa> there is also no efficiency benefit to combining the tree, as every consensus-enforcing full nkde needs all consensus commitments anyway; combining them into one tree would add unnecessary branches to data that will always be present anyway
404 2016-01-14 20:17:44 <sipa> morcos: if requested
405 2016-01-14 20:19:27 <sipa> deepbit runs 0.3.24 last i heard :p
406 2016-01-14 20:27:02 <Luke-Jr> sipa: oops
407 2016-01-14 21:16:13 <maaku> morcos: the release notes show that bip 66 was backported to 0.9
408 2016-01-14 21:16:53 <maaku> i would have expected 0.8
409 2016-01-14 21:16:55 <morcos> maaku: i think 0.11 and 0.12 should be sufficient.
410 2016-01-14 21:17:17 <maaku> morcos: we have a surprising fundamental disagreement there
411 2016-01-14 21:17:34 <maaku> it's been an ethos of bitcoin that consensus code changes are not tied to version
412 2016-01-14 21:17:59 <maaku> historically soft forks have been back ported to every release that could still sync the chain
413 2016-01-14 21:18:29 <morcos> maaku: but i dont think thats a feasible goal to maintain
414 2016-01-14 21:18:32 <maaku> maybe this explains a lot about bip 68 timeline -- #6312 was maintained the way it was explicitly because I was anticipating back-porting to 0.8
415 2016-01-14 21:18:48 <maaku> morcos: its not a goal, it's a requirement when we don't know what mining code exists out there in the wild
416 2016-01-14 21:18:57 <maaku> not everyone updates across major releases
417 2016-01-14 21:19:11 <Lightsword> AFAIK all miners are on 0.11.2
418 2016-01-14 21:19:18 <maaku> Lightsword: and you know this how?
419 2016-01-14 21:19:44 <morcos> maaku: 6312 i think would have been harder to backport than 7184
420 2016-01-14 21:19:51 <Lightsword> maaku, talked to most pool operators, I’d be really surprized if anyone was on something older than 0.11.2
421 2016-01-14 21:19:57 <morcos> certainly the easiest thing would have been to never change CheckFinalTx
422 2016-01-14 21:20:10 <morcos> but now thats changed so the backport must include that somehow
423 2016-01-14 21:20:31 <morcos> anyway, no point arguing, first goal master, second goal 0.12, then 0.11, then we can talk about further back
424 2016-01-14 21:20:40 <morcos> i'd love it if you want to help
425 2016-01-14 21:20:49 <maaku> Lightsword: we need stronger guarantees than that
426 2016-01-14 21:20:51 <morcos> but arguing with those of us still trying to work isn't super productive
427 2016-01-14 21:21:07 <phantomcircuit> maaku, 0.12.0 is so much faster the additional risk of running unreleased code isn't something they care about
428 2016-01-14 21:21:59 <maaku> morcos: "still trying to work"? morcos -- i gave up on BIP 68 because it became patently obvious that there was no way for it to get in until you had everyone one of your checkboxes ticked, so it's better for you to do that than to waste my time
429 2016-01-14 21:22:22 <Lightsword> maaku, most patch sets are fairly minor, I’ve heard of some pools temporarially being a version behind but they would always upgrade to latest for soft fork activation
430 2016-01-14 21:22:51 <Lightsword> stratum servers generally just use GBT which hasn’t really changed much
431 2016-01-14 21:24:08 <maaku> morcos: if you're no longer giving it priority then perhaps we can simply go with whichever impelementation has the most reviews, do a final round of acks and get it merged
432 2016-01-14 21:24:38 <maaku> implementation details can be fixed in future releases that don't have to be backported
433 2016-01-14 21:24:43 <morcos> maaku: that is really an unbelievable distortion of history, but not an argument the rest of the channel wants to hear.
434 2016-01-14 21:25:14 <Lightsword> IMO not neccesary to backport to more than one version at least for pools
435 2016-01-14 21:25:49 <Lightsword> other services may be running more extensive patch sets
436 2016-01-14 21:26:23 <Lightsword> pools on the other hand generally don’t like to mess with core code, f2pool I know does some patches to filter out spv clients and other clients that would never be miners
437 2016-01-14 21:27:10 <Lightsword> but they generally don’t mess with too much internal logic
438 2016-01-14 21:27:10 <maaku> Lightsword: you are completely missing the point. we support the entire ecosystem, not just miners (what are payment providers in Romania running hmm?), and even with miners we *should* be supporting small miners too, not just the largest pools
439 2016-01-14 21:29:44 <Lightsword> maaku, yeah for other services it could make sense to backport although for really old versions it may not be worth the effort
440 2016-01-14 21:30:18 <Lightsword> 2 major versions behind for backporting seems reasonable for soft forks IMO
441 2016-01-14 21:30:20 <maaku> Lightsword: anyone not running that patch set would be exploitable, potentially suffering monetary losses
442 2016-01-14 21:30:38 <maaku> that's why it makes sense to do soft-fork changes in such a way as to be most easily back portable
443 2016-01-14 21:30:49 <maaku> which is exactly what has been done for pretty much all changes to date
444 2016-01-14 21:31:18 <Lightsword> maaku, I thought they were only backported two major versions usually, ie BIP65 to major version 0.9
445 2016-01-14 23:36:00 <op_null> Mike's article today was rather unfortunate.  TL;DR; People disagreed with me, so Bitcoin failed.      I think with Hearn gone, there will be less Pitchfork mobs on forums/reddit.  It's been unfortunate seeing so many ad hominem attacks.   Hope you guys can continue to keep up all your good work, and do your best to keep Bitcoin decentralized.
446 2016-01-14 23:38:41 <JackH> mike's artile is pure garbage
447 2016-01-14 23:38:49 <JackH> attack on maxwell all the time, its all he can do
448 2016-01-14 23:39:07 <JackH> funny how the article forgot to mention 95% of all core dev's agree to the roadmap
449 2016-01-14 23:39:36 <Diablo-D3> wait, hearn left?
450 2016-01-14 23:39:47 <JackH> we are not that lucky
451 2016-01-14 23:39:52 <JackH> he just wrote he left
452 2016-01-14 23:39:55 <Diablo-D3> ahh
453 2016-01-14 23:40:04 <Diablo-D3> but yeah, what the fuck are we all arguin about now?
454 2016-01-14 23:40:09 <Diablo-D3> is it still the block size shit?
455 2016-01-14 23:40:15 <JackH> give it a week for the next article on medium.com bashing gmaxwell again
456 2016-01-14 23:40:20 <JackH> yeah I think so
457 2016-01-14 23:40:22 <Luke-Jr> can we take this to #bitcoin or something?
458 2016-01-14 23:40:25 <Diablo-D3> I dont even know why people bash gmaxwell
459 2016-01-14 23:40:26 <Luke-Jr> #bitcoinxt ideally
460 2016-01-14 23:40:28 <Diablo-D3> hes a great guy
461 2016-01-14 23:40:34 <JackH> lol luke
462 2016-01-14 23:40:36 <JackH> #bitcoin it is
463 2016-01-14 23:40:37 <justanotheruser> Diablo-D3: tinfoil hats
464 2016-01-14 23:40:51 <Diablo-D3> and he puts up with me making fun of his OTHER job at xiph ;)
465 2016-01-14 23:41:12 <op_null> https://medium.com/@octskyward/the-resolution-of-the-bitcoin-experiment-dabb30201f7#.69kuq1mbu
466 2016-01-14 23:43:02 <phantomcircuit> Diablo-D3, mike now works for R3 and is busy throwing FUD
467 2016-01-14 23:43:29 <Diablo-D3> oh, lame