1 2016-02-04 00:13:13 <jtimon> Luke-Jr: I still kind of disagree that "miners aren't users" since they implicitly need to sell their collected btc or sit on their btc and become holders/potential-spenders/speculators, I guess it is related to the fact that iirc you said buying or selling btc for other currencies somehow "doesn't count", having heard very inclusive definitions of "currency" and "service", some red lights were turned on in my brain when reading some
  2 2016-02-04 00:13:13 <jtimon> parts of your bips related to this as well, btw, where is https://github.com/luke-jr/bips/blob/bip-biprevised/bip-biprevised.mediawi ?
  3 2016-02-04 00:19:36 <jtimon> but in any case the overall concept of the bip, and specially the attempt on making how consensus-changing-BIP's states be determined in an objective way is a very good goal, it's much easier to objectively define with softforks than with hardforks, but should be also possible with hardforks, or at least for a reduced definition of uncontroversial/economic-majority/user-consensus/whatever hardforks. I think some of the clarifying
  4 2016-02-04 00:19:36 <jtimon> parts of this
  5 2016-02-04 00:25:53 <jtimon> BIP are many things (at least in intend) with the informational part of BIP99 [I keep wondering if I should have separated the informational from the code/hardfork-wish-list part], so I'll wait for your "economic consensus" definition to be more stable to link it and at worse reuse to define a new term if I feel that "consensus rules/code" vs "economic/adoption consensus" is not expressive enough for BIP99 (because I think a document
  6 2016-02-04 00:25:53 <jtimon> must clearly talk about the two concepts and some of their relantionships somewhere)
  7 2016-02-04 00:57:58 <Luke-Jr> jtimon: iirc you said buying or selling btc for other currencies somehow "doesn't count" <-- you recall wrongly
  8 2016-02-04 00:58:43 <Luke-Jr> jtimon: miners only become sellers/holders if they're mining within the economy's set rules
  9 2016-02-04 01:04:07 <jtimon> I may have said it doesn't count as "real economy", but I never claimed that thing I was talking about was objectively measurable, it seems that I may have conflated two different contexts when talking to you about "doesn't count"
 10 2016-02-04 01:05:23 <jtimon> Luke-Jr: agreed on the second point. I may had expressed the same thing in my own terminology as "miners are only part of the economy if they're mining the same currency"
 11 2016-02-04 01:05:56 <Luke-Jr> jtimon: this is why it isn't relevant for the case of hardforks
 12 2016-02-04 01:07:00 <jtimon> in my terminology, an ASIC-reset hardfork is "controversial" by defintion, because miners are users too (BIP99 actually recommends controversial hardforks for some extreme cases)
 13 2016-02-04 01:09:43 <Luke-Jr> jtimon: part of the Rationale does explicitly say miners may be relevant in their other capacities FWIW
 14 2016-02-04 01:11:09 <jtimon> of course, there's no way for the BIP process to objectively tell whether a given controversial hardfork proposal is "right", and bip99 should only talk about extreme cases where a controversial hardfork should be "obviously right" to anyone that wants to understand the examples
 15 2016-02-04 01:13:39 <Luke-Jr> well, it *could* but you'd probably end up the new most-controversial Bitcoin figure :P
 16 2016-02-04 01:13:57 <jtimon> Luke-Jr: yeah, I noticed that "other capacities" point and I think is basically what I was a missing piece in previous discussions with you, I like that, and I just want to make sure that is explicit enough. anyway, http://www.downforeveryoneorjustme.com/https://github.com/luke-jr/bips/blob/bip-biprevised/bip-biprevised.mediawi
 17 2016-02-04 01:14:19 <Luke-Jr> O.o?
 18 2016-02-04 01:15:52 <jtimon> is that the correct link?
 19 2016-02-04 01:16:00 <Luke-Jr> no
 20 2016-02-04 01:16:09 <Luke-Jr> you're missing "ki" at the end
 21 2016-02-04 01:19:37 <jtimon> would "de facto nearly-universal usage of the hard-fork in practice" be too strict?
 22 2016-02-04 01:22:03 <jtimon> "A soft-fork BIP strictly requires a clear miner majority expressed by blockchain voting" that seems to imply that an economic majority is not needed for an softfork to be considered deployed + uncontroversial, and uncontroversial should be a requirement for softfork final status just like it is for hardforks
 23 2016-02-04 01:23:57 <Luke-Jr> why?
 24 2016-02-04 01:24:56 <jtimon> suggestion: rewrite the "Why aren't <x></x> included in the economy?" section from "X are not included in the economy..." to "X are included in the economy only to the extend that they..."
 25 2016-02-04 01:25:08 <Luke-Jr> that sounds like a "should be" requirement
 26 2016-02-04 01:26:09 <Luke-Jr> jtimon: the first bullet point says that..
 27 2016-02-04 01:26:56 <jtimon> sure, it's just a suggestion for it to sound inclusive vs exclusive with the same objective meaning
 28 2016-02-04 01:27:58 <jtimon> to the should-be point: let's imagine that the "inflation softfork" (seriously, let anyone let me know how if it's technically possible) has been deployed by 96% of the hashing power but the "economic majority" (however we have defined it) disagrees with the change
 29 2016-02-04 01:28:16 <jtimon> should that BIP get to final after deployed?
 30 2016-02-04 01:28:27 <jtimon> I think we don't know yet
 31 2016-02-04 01:32:18 <jtimon> if all users move to an asic-reset hardfork, for example, maybe that controversial softfork should never get to final, but the hardfork (let's not discuss more about whether an asic-reset is intrinsically controversial or not for now) that overwrittes the "evil" softfork can be objectively considered final later
 32 2016-02-04 01:33:02 <jtimon> of course we should have #bitcoin-philosophy or something
 33 2016-02-04 01:38:49 <Luke-Jr> jtimon: unless the economic consensus has decided to hardfork out of it..
 34 2016-02-04 01:39:02 <jtimon> but seriously, one of the points of the characteristics and deployment recommendations where quite similar for "uncontroversial" changes regardless of them being softforks or hardforks, although a "minimum date before letting miners determine the exact date via bip9" was an additional requirement for uncontroversial hardforks (no miner coordination for controversial hardforks including asic-reset hardforks) and I still have to add
 35 2016-02-04 01:39:02 <jtimon> the "you should have the block after new hardfork activation have a negative block version for properly-implemented-hardfork-notification forward compatibility"
 36 2016-02-04 01:40:55 <jtimon> Luke-Jr: ?? specially if the economic consensus forks out of the offending softfork, it should never get to final, even if it has been objectively deployed by the "A soft-fork BIP strictly requires a clear miner majority expressed by blockchain voting" criterion
 37 2016-02-04 01:41:21 <Luke-Jr> jtimon: that is not the only criterion
 38 2016-02-04 01:41:39 <Luke-Jr> ", as well as not meeting the inverse criteria for a hard-fork BIP (that is, economic agreement to block the soft-fork with a hard-fork, may be cause to reject that soft-fork BIP despite miner adoption)."
 39 2016-02-04 01:42:09 <jtimon> ok, economic consensus is also required for uncontroversial softforks to get to the final state, right?
 40 2016-02-04 01:42:56 <Luke-Jr> no
 41 2016-02-04 01:43:02 <Luke-Jr> lack of economic consensus contrary to it
 42 2016-02-04 01:43:10 <Luke-Jr> since economic consensus would be required to hard-fork away
 43 2016-02-04 01:43:15 <jtimon> mhmm, I finally get what you mean by "economic majority is required to veto softforks"
 44 2016-02-04 01:43:55 <jtimon> I thought I did that yesterday, but I didn't
 45 2016-02-04 01:44:35 <gevs> and thanks for being so precise about it jtimon, helped me getting it, just now :)
 46 2016-02-04 01:45:41 <jtimon> mhmm, but assuming we can somehow objectively monitor that a softfork BIP didn't got economic consensus...
 47 2016-02-04 01:47:04 <jtimon> how long we should wait for it to be changed to final after deployment vs waiting for the dissenting hardfork to be deployed (perhaphs permantently in parallel)
 48 2016-02-04 01:47:54 <jtimon> gevs: thanks, but I think we're all still trying to get it :p
 49 2016-02-04 01:49:37 <gevs> your questioning is full of sense though
 50 2016-02-04 01:50:42 <gevs> im still lost in youtube videos of core devs and trying to get the most out of the 7 years that has passed on bitcoin dev :)
 51 2016-02-04 01:54:20 <jtimon> Luke-Jr: in other words, if there's any way to objectively determine "economic consensus" for a given hardfork BIP, it should be reusable to filter out softfork BIPs that don't meet that criterion not to reach the final (aka uncontroversial final) state, regardless of them being deployed by " a clear miner majority expressed by blockchain voting"  (btw, did I say that I'm not alone in hating the term "miner/blockchain voting" and
 52 2016-02-04 01:54:20 <jtimon> preferring "miner sginaling/upgrade-confirmation" instead?)
 53 2016-02-04 02:04:39 <jtimon> controversial hardforks" cannot be covered in your BIP besides ASIC-reset hardfork
 54 2016-02-04 02:04:39 <jtimon> I suspect that all my concerns can be somehow solved just by being a little bit more explicit here and there, I'm excited about the clarity that can be added to the bip process with this bip, moving bip99 to replaced by yours for the informative part (plus a new bip for the simple-clearly-uncontroversial-hardfork-cleanup-implemented-reviewed-and-rebased-wishlist) it's still an open possibility, although maybe " 'rightful'
 55 2016-02-04 02:09:17 <Luke-Jr> jtimon: well, this BIP doesn't aim to describe *how* to accomplish the hard-fork, so BIP 99 may still need that
 56 2016-02-04 02:09:26 <Luke-Jr> just how to determine that it is Final
 57 2016-02-04 02:54:53 <jtimon> yep, probably bip99 should not be deprecated, still, it would probably add clarity to "rebase" it on top of yours
 58 2016-02-04 12:09:03 <wumpus> Luke-Jr: so to be clear, you want travis to be activated on the bips repository? what would this accomplish?
 59 2016-02-04 12:09:33 <wumpus> (I don't see any testing scripts there)
 60 2016-02-04 12:37:02 <Sprntz> list
 61 2016-02-04 12:37:45 <Sprntz> hi
 62 2016-02-04 17:21:36 <kanzure> jl2012: "It is not possible for miners in one fork to attack or overtake the other fork without giving up the mining reward of their preferred fork."   but that was already the case, wasn't it?
 63 2016-02-04 17:22:02 <kanzure> e.g. in absence of your proposal, it is still true that miners have to mine on top of blocks in the fork that they are attacking, regardless of the hard-fork mechanisms, i think.
 64 2016-02-04 17:22:24 <jl2012> the old fork can attack to new fork
 65 2016-02-04 17:22:40 <jl2012> say BIP101
 66 2016-02-04 17:23:27 <jl2012> yes, that's only one way. I can clarify
 67 2016-02-04 17:29:01 <Tasoshi> they don't have to attack. The fact that they easily can just makes the chain fully insecure, and thus makes it have 0 value
 68 2016-02-04 17:38:40 <kanzure> Tasoshi: i suspect that such an adversarial environment would make any chain have zero value.
 69 2016-02-04 17:40:02 <Tasoshi> Not really, if you have one chain with say 1 miner or many cpu miners, vs 1 chain with computation worth in hundreds of millions or billions, it is only one chain which is fully insecure conceptually and therefore can have no value
 70 2016-02-04 17:57:16 <Luke-Jr> wumpus: When GitHub fixes the PR stuff, I have a travis branch in my clone to PR
 71 2016-02-04 19:00:37 <wumpus> meeting?
 72 2016-02-04 19:00:51 <phantomcircuit> is it that time?
 73 2016-02-04 19:00:52 <petertodd> wumpus: hol dit in -core-dev?
 74 2016-02-04 19:00:53 <sipa> OP_TRUE
 75 2016-02-04 19:01:02 <wumpus> #meetingstart
 76 2016-02-04 19:01:06 <lightningbot`> Meeting started Thu Feb  4 19:01:06 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
 77 2016-02-04 19:01:06 <lightningbot`> Useful Commands: #action #agreed #help #info #idea #link #topic.
 78 2016-02-04 19:01:06 <wumpus> #startmeeting
 79 2016-02-04 19:01:13 <wumpus> petertodd: should have been announced on the mailing list
 80 2016-02-04 19:01:19 <petertodd> wumpus: good point!
 81 2016-02-04 19:01:25 <wumpus> proposed topics?
 82 2016-02-04 19:01:29 <petertodd> sipa: I need to reply to you and think about your points raised
 83 2016-02-04 19:01:43 <sipa> petertodd: what where when?
 84 2016-02-04 19:01:53 <petertodd> sipa: mailing list, re: segwit upgrade procedures
 85 2016-02-04 19:01:54 <sipa> ah, the segwit proposed changes?
 86 2016-02-04 19:01:58 <petertodd> sipa: yup
 87 2016-02-04 19:02:00 <sipa> yeah, let's do that there
 88 2016-02-04 19:02:03 <petertodd> sipa: agreed
 89 2016-02-04 19:02:14 <jtimon> proposed topic move the meeting to -core-dev next time?
 90 2016-02-04 19:02:16 <wumpus> #topic segwit proposed changes
 91 2016-02-04 19:02:17 <petertodd> sipa: just wanted to be clear discussion was ongoing
 92 2016-02-04 19:02:52 <sipa> petertodd proposed a change that would make future consensus-data-adding softforks easier to deploy; discussion ongoing
 93 2016-02-04 19:03:09 <petertodd> so... I'm working on that prev-block-proof thing still, and I think I'll have that ready for review in a few more days
 94 2016-02-04 19:03:49 <jtimon> petertodd: can you give more details about the "prev-block-proof thing"?
 95 2016-02-04 19:04:01 <petertodd> as for the consensus-data-adding thing, I'm leaning towards saying it should be the last thing we make a decision about, with anything more complex than adding another field have the onus on me/whomever to have running code implementing it
 96 2016-02-04 19:04:35 <petertodd> jtimon: sure. So, I want to make sure miners must prove they, or a trusted third-party, had a copy of the previous block's data to be able to create a new block.
 97 2016-02-04 19:05:10 <petertodd> jtimon: issue being fixed is the fact that with segwit, it's possible to only transfer the data required to update the UTXO set, without the data showing that those changes were valid
 98 2016-02-04 19:05:39 <petertodd> jtimon: so to fix that, basically rehash the previous block with a nonce
 99 2016-02-04 19:06:00 <jtimon> did this affected SPV mining or that was another thing?
100 2016-02-04 19:06:25 <petertodd> jtimon: this *can* be used to stop SPV mining entirely, although whether we do this or not is an implementation detail
101 2016-02-04 19:06:33 <petertodd> jtimon: er, I should say, implementation decision
102 2016-02-04 19:06:48 <jtimon> ok, thanks
103 2016-02-04 19:06:56 <Tasoshi> wouldn't lack of SPV mining make mining fully inefficient?
104 2016-02-04 19:07:10 <petertodd> for instance, we could say validationless mining of empty blocks is allowed, but not blocks with transactions in them
105 2016-02-04 19:07:21 <Tasoshi> by delaying block propagation
106 2016-02-04 19:07:49 <petertodd> Tasoshi: validationless mining breaks the security assumptions of SPV wallets, so we have good reasons to either stop it fully, or restrict it to just empty blocks
107 2016-02-04 19:07:54 <wumpus> the whole point of miners is to validate
108 2016-02-04 19:08:20 <Tasoshi> yes, and they can spv mining in a way that ensures security is maintained
109 2016-02-04 19:08:25 <petertodd> wumpus: in the current design of bitcoin :) possibly miners could also be seen as proving publication of data, but that's *not* the way bitcoin is designed right now
110 2016-02-04 19:08:38 <jtimon> yeah, I don't see how having fast-propagating empty blocks helps in any way
111 2016-02-04 19:08:41 <sipa> Tasoshi: that sounds suspcisious to me
112 2016-02-04 19:08:43 <petertodd> Tasoshi: yes, e.g. the mining of empty blocks
113 2016-02-04 19:08:58 <petertodd> Tasoshi: mining blocks with transactions in them breaks the security assumptions in the current design
114 2016-02-04 19:09:15 <sipa> petertodd: just empty blocks is no solution; you can trivially add a single miner-generated transaction that's known to be valid
115 2016-02-04 19:09:24 <Tasoshi> https://bitslog.wordpress.com/2016/01/08/spv-mining-is-the-solution-not-the-problem/
116 2016-02-04 19:09:40 <phantomcircuit> Tasoshi, spv mining or spv clients, pick one
117 2016-02-04 19:09:54 <petertodd> sipa: oh, but I'm proposing potentially doing a version where you can enforce that the block must be empty to validationless mine
118 2016-02-04 19:10:12 <Tasoshi> segwit will provide fraud proofs which I should think will ensure spv wallets follow the longest chain
119 2016-02-04 19:10:16 <gmaxwell> or arbritary transactions, if you have some trusted aux data of whats already been mined.
120 2016-02-04 19:10:51 <Tasoshi> that is no reason to stop mining from being efficient in my view anyway
121 2016-02-04 19:10:52 <petertodd> Tasoshi: segwit is a long way from providing fraud proofs, and fraud proofs are *not* the current security model of bitcoin, and may not even work in general
122 2016-02-04 19:11:07 <sipa> Tasoshi: fraud proofs are not part of the current proposal; they just enable them
123 2016-02-04 19:11:29 <petertodd> Tasoshi: note that what I'm proposing does not preclude later redsigns that re-enable validationless mining
124 2016-02-04 19:11:42 <shea256> Hi everyone, just wanted to introduce myself. This is the first meeting I'm sitting in on.
125 2016-02-04 19:11:48 <sipa> shea256: hi there!
126 2016-02-04 19:11:51 <jtimon> petertodd: between completely removing SPV mining and allowing it for empty blocks...I can't really think of a reason for chosing the latter
127 2016-02-04 19:12:20 <petertodd> jtimon: my preference is the former too, but we'll have to see what's viable politically
128 2016-02-04 19:12:28 <sipa> i'm a bit skeptical about whether the segwit-enabled download-only-base-data model is one that is interesting
129 2016-02-04 19:12:37 <Tasoshi> because by stopping spv mining you are stopping block propagation which creates a fully inefficient system
130 2016-02-04 19:12:47 <wumpus> Tasoshi: you're repeating yourself, stop it
131 2016-02-04 19:12:51 <cfields> this discussion seems a bit out of scope for an irc meeting :)
132 2016-02-04 19:12:52 <Tasoshi> we could instead work on making spv mining fully safe and secure
133 2016-02-04 19:12:57 <petertodd> cfields: agrees
134 2016-02-04 19:13:01 <sipa> cfields: agree
135 2016-02-04 19:13:02 <petertodd> cfields: er, agreed
136 2016-02-04 19:13:26 <phantomcircuit> petertodd, have you written up the proposal for this?
137 2016-02-04 19:13:26 <sipa> we can discuss this after the meeting
138 2016-02-04 19:13:29 <petertodd> Tasoshi: sorry, but the above gets into very technical details about the nuance of what exactly bitcoin is and how it functions - probably not appropriate for a IRC meeting focusing on short-term development
139 2016-02-04 19:13:40 <jtimon> petertodd: I don't remember saying I had any preference here, but I still don't see how allowing it for empty blocks would make it more viable politically, what's the alleged advantage?
140 2016-02-04 19:13:42 <Tasoshi> sure
141 2016-02-04 19:13:56 <petertodd> jtimon: basically if miners really like their validationless mining setups :)
142 2016-02-04 19:14:07 <Tasoshi> just wanted to raise my objections...
143 2016-02-04 19:14:13 <petertodd> jtimon: personally, I'll explaing it in terms of leveling the playing field
144 2016-02-04 19:14:15 <phantomcircuit> jtimon, everybody doing validation-less mining is already creating empty blocks anyways
145 2016-02-04 19:14:18 <petertodd> Tasoshi: I'd suggest you raise them on list
146 2016-02-04 19:14:46 <sipa> other topic?
147 2016-02-04 19:14:56 <sipa> how is 0.12 doing?
148 2016-02-04 19:15:08 <wumpus> #topic 0.12.0
149 2016-02-04 19:15:13 <jtimon> petertodd: oh, to keep miners happy mining empty blocks with subsidy...but nobody is arguing that "fast" empty blocks are an advantage for anyone else, right?
150 2016-02-04 19:15:15 <btcdrak> We're at RC3
151 2016-02-04 19:15:16 <wumpus> we've just tagged rc3
152 2016-02-04 19:15:25 <wumpus> hopefully nothing critical comes up and this can be final
153 2016-02-04 19:15:48 <jtimon> did something critical came up in rc2?
154 2016-02-04 19:16:09 <wumpus> yes
155 2016-02-04 19:16:31 <cfields> gitian builders: we've requested a new windows signing cert so that we don't run into problems with win7+ and it's sha1 deprecation. Sigs should be pushed today barring any complications.
156 2016-02-04 19:16:35 <jtimon> ok, just wanted to confirm what was the criteria for creating a new rc
157 2016-02-04 19:16:37 <wumpus> e.g. the seeds update
158 2016-02-04 19:16:55 <wumpus> and #7438
159 2016-02-04 19:18:00 <wumpus> ok, next topic?
160 2016-02-04 19:18:23 <btcdrak> sequence locks
161 2016-02-04 19:18:33 <Tasoshi> is there an update on segwit?
162 2016-02-04 19:18:39 <wumpus> #topic sequence locks
163 2016-02-04 19:18:54 <wumpus> Tasoshi: we had segwit as first topic
164 2016-02-04 19:19:14 <btcdrak> OK so this is more information than anything, but #7184 (the BIP68 implementation) is done and gathering Tested ACKs, including from some of the Lightning guys.
165 2016-02-04 19:19:16 <Tasoshi> ah, sorry, sequence locks it is
166 2016-02-04 19:19:27 <btcdrak> It's really time to look at getting this stuff merged
167 2016-02-04 19:19:27 <petertodd> btw: re, sequence locks, something that maybe whasn't been widely pointed out is that BIP68 is useful by itself with segwit
168 2016-02-04 19:19:32 <btcdrak> same for #6564
169 2016-02-04 19:19:43 <wumpus> yes it's looking quite good
170 2016-02-04 19:19:49 <wumpus> is the BIP finalized and merged now?
171 2016-02-04 19:19:57 <btcdrak> so I'd like an action point if possible to review and test ACK #7184 and  #6564
172 2016-02-04 19:20:08 <btcdrak> wumpus: BIPs are all merged and final
173 2016-02-04 19:20:09 <wumpus> #action review and test ACK #7184 and  #6564
174 2016-02-04 19:20:15 <wumpus> btcdrak: awesome
175 2016-02-04 19:20:35 <btcdrak> one last point
176 2016-02-04 19:20:48 <jtimon> yes please, let's finally merge this
177 2016-02-04 19:20:54 <btcdrak> there are sme test scripts from aj  at https://github.com/ajtowns/op_csv-test
178 2016-02-04 19:21:15 <btcdrak> you need to merge both PRs together to use them ofc. I did so at https://github.com/btcdrak/bitcoin/tree/sequenceandcsv
179 2016-02-04 19:21:30 <btcdrak> that's it :)
180 2016-02-04 19:21:57 <jtimon> or just merge #7184 first and add those tests to #6564 ?
181 2016-02-04 19:23:22 <petertodd> jtimon: I think merging $7184 first is fine
182 2016-02-04 19:24:10 <petertodd> jtimon: previously I've been against separating the two, but I think I was wrong about that given that BIP68 is useful w/ segwit on it's own
183 2016-02-04 19:24:20 <btcdrak> jtimon: we dont have a framework to add those kinds of tests that I am aware of
184 2016-02-04 19:25:04 <jtimon> well I was never against doing both together, but maybe separating them could have accelerated the process (it clearly hasn)
185 2016-02-04 19:25:07 <wumpus> #link https://github.com/ajtowns/op_csv-test
186 2016-02-04 19:25:08 <btcdrak> petertodd: I'm especially pleased that downstream consumers have done extensive testing and found the code useful for their cases.
187 2016-02-04 19:25:09 <jtimon> t
188 2016-02-04 19:25:25 <petertodd> btcdrak: +1 - that's one of the most important steps!
189 2016-02-04 19:25:30 <wumpus> #link https://github.com/btcdrak/bitcoin/tree/sequenceandcsv
190 2016-02-04 19:26:22 <jtimon> btcdrak: oh, I thought you had added those tests to btcdrak/sequenceandcsv, never mind then
191 2016-02-04 19:26:35 <wumpus> what kind of tests are these?
192 2016-02-04 19:27:18 <wumpus> we have unit tests, and functinoal RPC tests + P2P tests, large chance they can be integrated somehow?
193 2016-02-04 19:28:08 <jtimon> I believe they are testing an specific smart contract protocol, like a payment channel or something, but I'm not really sure
194 2016-02-04 19:28:29 <wumpus> okay, well if there's something you need re : test integration let me know
195 2016-02-04 19:28:36 <btcdrak> wumpus: python smart contract tests, depends on petertodd's python-bitcoinlib
196 2016-02-04 19:29:06 <petertodd> note that I think we're still missing transaction-level unit tests, and I'd NACK an actual soft-fork on that basis
197 2016-02-04 19:29:12 <btcdrak> wumpus: I think they are good as documentation rather than automated tests
198 2016-02-04 19:29:38 <btcdrak> petertodd: well we're at mempool-only stage now. softforking PR is a new round :)
199 2016-02-04 19:29:41 <wumpus> petertodd: having the mempool-only pulls merged is good for testing, though
200 2016-02-04 19:29:49 <petertodd> btcdrak: yup, I am happy for this to be merged mempool only
201 2016-02-04 19:29:59 <wumpus> petertodd: I think NACKing ahead of ourselves is not constructive
202 2016-02-04 19:30:04 <petertodd> btcdrak: backing out a mempool-only opcoe isn't a big deal
203 2016-02-04 19:30:13 <wumpus> right, it's been done before
204 2016-02-04 19:30:15 <petertodd> wumpus: just wanted to be clear :)
205 2016-02-04 19:30:18 <btcdrak> wumpus: He's the Clief Naysayer, he must!
206 2016-02-04 19:30:26 <btcdrak> err Chief even
207 2016-02-04 19:30:33 <wumpus> though I prefer fixing over reverting :)
208 2016-02-04 19:30:35 <petertodd> btcdrak: I Naysay your speling :P
209 2016-02-04 19:31:32 <jtimon> other topic?
210 2016-02-04 19:31:38 <wumpus> ok, more topics?
211 2016-02-04 19:31:39 <btcdrak> well I'll get cracking the whip this week and maybe we can look at merge possibility next meeting
212 2016-02-04 19:32:32 <btcdrak> wumpus: I just want to point out I published the EOL policy on the website as we discussed a while back https://bitcoincore.org/en/lifecycle/
213 2016-02-04 19:32:32 <jtimon> or the meeting after the next meeting
214 2016-02-04 19:32:51 <wumpus> btcdrak: yes should be pretty close now
215 2016-02-04 19:33:02 <wumpus> #link  https://bitcoincore.org/en/lifecycle/
216 2016-02-04 19:33:25 <wumpus> ok, if there's no further topics
217 2016-02-04 19:33:33 <lightningbot`> Log:            http://www.erisian.com.au/meetbot/bitcoin-dev/2016/bitcoin-dev.2016-02-04-19.01.log.html
218 2016-02-04 19:33:33 <lightningbot`> Meeting ended Thu Feb  4 19:33:33 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
219 2016-02-04 19:33:33 <lightningbot`> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-dev/2016/bitcoin-dev.2016-02-04-19.01.html
220 2016-02-04 19:33:33 <lightningbot`> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-dev/2016/bitcoin-dev.2016-02-04-19.01.txt
221 2016-02-04 19:33:33 <wumpus> #endmeeting
222 2016-02-04 19:34:57 <sipa> btcdrak: is the information there correct? the 0.8 end of life seems very early!
223 2016-02-04 19:35:46 <petertodd> sipa: do we know of anyone using 0.8?
224 2016-02-04 19:36:15 <Tasoshi> not sure an 0.8 node can be called a real full node to be honest
225 2016-02-04 19:36:22 <sipa> you're all missing the point
226 2016-02-04 19:36:31 <sipa> that page claims 0.8 went EOL the day it was released
227 2016-02-04 19:36:32 <petertodd> sipa: how so?
228 2016-02-04 19:36:43 <petertodd> sipa: haha, indeed!
229 2016-02-04 19:36:50 <wumpus> last 0.8 tag I have is v0.8.7rc1, Feb 21 16:31:49 2014 +0100
230 2016-02-04 19:37:08 <btcdrak> sipa: copy pasta errr lemme fix that
231 2016-02-04 19:37:16 <btcdrak> but in any case it is EOL
232 2016-02-04 19:37:21 <sipa> yes, it is
233 2016-02-04 19:38:16 <midnightmagic> warning: updating from VirtualBox-5.0.10 to 5.0.14 on OSX can cause saved-state virtual machines to fail to resume. Correction is to revert to 5.0.10 by re-running the 5.0.10 installer.
234 2016-02-04 19:40:40 <Tasoshi> There are apparently some 100 nodes in all running 0.8 to 0.9 though according to this https://bitnodes.21.co/nodes/?q=/Satoshi:0.8.5/
235 2016-02-04 19:41:30 <petertodd> Tasoshi: note that some of those nodes may not even be real, as we know that network monitoring firms are creating a lot of fake ones, and they've been caught using old node versions in the past
236 2016-02-04 19:41:40 <Tasoshi> I suspect they are just backups in case things go wrong, but in that case, you can just bring up an old version node...
237 2016-02-04 19:41:49 <midnightmagic> error you will see might be VERR_SSM_LOADED_TOO_MUCH
238 2016-02-04 19:42:01 <wumpus> yes, the old versions can still connect to the network, EOL or not
239 2016-02-04 19:42:02 <instagibbs> Even their *fake* Core software is old. Kind of sad.
240 2016-02-04 19:42:12 <Tasoshi> ah, could be
241 2016-02-04 19:42:16 <shea256> that page shows there are 204 0.8 nodes
242 2016-02-04 19:42:25 <petertodd> Tasoshi: anyway, unmaintained installations aren't relevant, as those people aren't going to upgrade to a newer 0.8/0.9 backport anyway
243 2016-02-04 19:42:27 <midnightmagic> Additionally, I personally will deliberately bock 21.co from accessing anything under my control, which includes anyone hanging off the systems I admin, so..
244 2016-02-04 19:43:12 <btcdrak> sipa: updated
245 2016-02-04 19:43:12 <petertodd> IMO we should only maintain old versions based on actual demand - we have good reason to think that exists broadly for one major version back, but beyond that is more dubious from what I've seen
246 2016-02-04 19:43:52 <btcdrak> petertodd: so maintained is this plus previous version. But after that, there is a gap where we will patch for critical security issues
247 2016-02-04 19:44:03 <btcdrak> certainly that is the status quo
248 2016-02-04 19:44:08 <wumpus> petertodd: yes, demand versus amount of effort
249 2016-02-04 19:44:36 <Tasoshi> petertodd, I think some people, especially the bitcoin-assets guys, seem to be keen to maintain old nodes, even as old as 0.5. I think they probably perceive them as some sort of backup, but, I find it inefficient because 0.5 or 0.8 code is not that hard to find/compile...
250 2016-02-04 19:44:37 <wumpus> some very critical things may be backported a version further
251 2016-02-04 19:44:58 <petertodd> wumpus: also good to remind people that it's always possible to pay for that effort if a business really needs an old version for some reason
252 2016-02-04 19:47:45 <Tasoshi> so I agree, I think backporting to even 0.11 is prob too much, the other node maintainers probably have the skills to update their node version with whatever patch if they wish
253 2016-02-04 19:48:04 <wumpus> petertodd: sure, that's always possible
254 2016-02-04 20:42:13 <s4n1ty> Hey guys, is anyone aware of whether Bitcoin contracts were inspired by the concept of "Signed Subspace Keys" in Freenet?  The concept seems extremely similar to the original proposal for SSKs - http://goo.gl/Pfeb7o
255 2016-02-04 21:28:37 <Lauda> libsecp256k1 Does not affect validation time, right?
256 2016-02-04 21:31:43 <sipa> Lauda: in 0.12 validation is switched to libsecp256k1, and it makes validation much faster (especially on x86_64)
257 2016-02-04 21:31:57 <Lauda> sipa doesn't this solve the long validation time of 2 MB blocks?
258 2016-02-04 21:32:21 <sipa> if you're referring to the O(n^2) hashing problem, no
259 2016-02-04 21:32:52 <Lauda> That's one of the things that I've read about on the roadmap. Yes, that's it. Why not?
260 2016-02-04 21:33:23 <sipa> Because that's about the computation of the hashes that are being verified.
261 2016-02-04 21:33:58 <sipa> However, segwit softfork proposal does contain a solution for that (which only applies to transactions choosing to use it, but the other ones are limited to 1 MB)
262 2016-02-04 21:34:36 <Lauda> Those choosing to use it? You mean those choosing to use segwit?
263 2016-02-04 21:34:40 <sipa> yes
264 2016-02-04 21:35:07 <Lauda> BIP 143 or?
265 2016-02-04 21:35:32 <sipa> indeed
266 2016-02-04 21:35:50 <sipa> it has a different signature hashing algorithm that's worst case O(n) in the size of blocks
267 2016-02-04 21:36:48 <Lauda> So O(n)^2 becomes O(n) in the worst case scenario?
268 2016-02-04 21:37:02 <Lauda> Could BIP 143 be implemented without segwit?
269 2016-02-04 21:37:07 <zooko> s4n1ty: hi there. ☺ I don't recall Satoshi citing Freenet. I'm not equipped to judge if the similarities are more likely to indicate uncredited derivation, common ancestry (forth-like languages), o r parallel invention.
270 2016-02-04 21:37:40 <sipa> Lauda: yes, but it would still be optional, so not much of a solution
271 2016-02-04 21:37:52 <sipa> Lauda: or you have to break existing wallets
272 2016-02-04 21:38:16 <Lauda> Well it is definitely better than the workaround that Gavin proposed in his BIP?
273 2016-02-04 21:42:34 <s4n1ty> zooko: Hey, yes, Freenet isn't cited.  Given that we didn't even implement the original proposal it seems unlikely that anyone other than a very ardent follower of Freenet's mailing lists back then would be aware of it.
274 2016-02-04 21:43:58 <zooko> s4n1ty: I for one wasn't aware of it, and as you know I was a follower of Freenet. ☺
275 2016-02-04 22:28:21 <petertodd> zooko: I'm amused at how being involved in freenet back then now makes you look like you may be satoshi :)
276 2016-02-04 22:31:01 <gmaxwell> s4n1ty left, but _I_ was aware of the fancy SSK stuff, and never thought it has any particular resemblance to Bitcoin.
277 2016-02-04 22:31:27 <petertodd> gmaxwell: not bitcoin in general, just the scripting scheme
278 2016-02-04 22:36:22 <gmaxwell> I know thats what I meant.
279 2016-02-04 22:52:01 <Chris_Stewart_5> What does the OP_SIZE operator do exactly? The documentation is sort of confusing
280 2016-02-04 22:52:07 <Chris_Stewart_5> the docs say Pushes the string length of the top element of the stack (without popping it).
281 2016-02-04 22:52:26 <Chris_Stewart_5> what exactly is meant by 'string length' the hexadecimal representation of the number?
282 2016-02-04 22:52:43 <kadoban> Chris_Stewart_5: The size in bytes of the data item on the top of the stack
283 2016-02-04 22:52:47 <kadoban> Chris_Stewart_5: So … 1/2 that
284 2016-02-04 22:54:21 <Chris_Stewart_5> kadoban: I'm not sure if that is right, 128 -> 0x80 and OP_SIZE of that is 2
285 2016-02-04 22:54:34 <Chris_Stewart_5> while 127 -> 0x7f is OP_SIZE of 1
286 2016-02-04 22:54:55 <Chris_Stewart_5> is that twos complement?
287 2016-02-04 22:55:05 <kadoban> Chris_Stewart_5: 128 is actually 0x0080 or something like that I believe
288 2016-02-04 22:55:17 <kadoban> Chris_Stewart_5: 0x80 would be … negative something
289 2016-02-04 22:56:34 <Chris_Stewart_5> https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#safe=off&q=0x80+to+decimal
290 2016-02-04 22:57:22 <kadoban> Chris_Stewart_5: How bitcoin scripts interpret data items as numbers is the important part here. 0x80 as bytes, would be a negative number, how bitcoin scripts interpret them.
291 2016-02-04 22:58:50 <kadoban> Chris_Stewart_5: 0x80 is actually "negative zero". https://bittyscript.emptypath.com/?sig=0x80+OP_1&sigfmt=asm&pubkey=OP_ADD&pubfmt=asm , if that happens to help
292 2016-02-04 23:00:25 <Chris_Stewart_5> Yeah that does help. Thanks kadoban
293 2016-02-04 23:00:45 <kadoban> Sure
294 2016-02-04 23:01:07 <kadoban> (note that tool is a work-in-progress, it probably currently lies about a bunch of stuff)
295 2016-02-04 23:27:54 <kolifred> free bot for getting bitcoins http://bit.ly/BTC_BOT