1 2016-01-26 01:44:37 <Chris_Stewart_5> how exactly is this scriptSig and scriptPubKey evaluated?
  2 2016-01-26 01:44:39 <Chris_Stewart_5> ["1", "IF ELSE 0 ELSE 1 ENDIF", "P2SH,STRICTENC"]
  3 2016-01-26 01:44:52 <Chris_Stewart_5> multiple OP_ELSE clauses?
  4 2016-01-26 02:17:51 <kefkius> Chris_Stewart_5: It appears that every else statement executes if the one before it did not. This: "1 IF 0 ELSE 1 ELSE 2 ELSE 3 ENDIF" will result in the stack: "0 2"
  5 2016-01-26 02:18:17 <kefkius> Whereas this one: "0 IF 0 ELSE 1 ELSE 2 ELSE 3 ENDIF" will result in "1 3"
  6 2016-01-26 02:21:08 <kefkius> So in that script's case, the IF statement is entered, the first ELSE statement is skipped, and the second ELSE statement is executed because the first ELSE statement was not
  7 2016-01-26 02:34:46 <Chris_Stewart_5> kefkius: what about the other OP_ELSEs in the example you gave, are those executed?
  8 2016-01-26 02:36:19 <kefkius> Chris_Stewart_5: For this example: "1 IF 0 ELSE 1 ELSE 2 ELSE 3 ENDIF" - The first ELSE is skipped, the second is executed (so 2 is pushed to the stack), and the third is skipped
  9 2016-01-26 02:37:02 <kefkius> Each ELSE changes whether the next execution block will be executed
 10 2016-01-26 02:43:12 <kefkius> The interpreter uses this vector of bools, vfExec, to decide whether to execute https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp#L244
 11 2016-01-26 02:45:56 <kefkius> An OP_IF pushes the top stack item as a bool to that vector, so if the value is true, execution continues. This is what I gather, at least
 12 2016-01-26 02:56:34 <btcdrak> luke-jr: thanks. I fixed the name.
 13 2016-01-26 02:57:49 <Luke-Jr> btcdrak: and s/C++/C++11?
 14 2016-01-26 02:58:08 <Luke-Jr> can some ML mod whitelist the guy I'm replying to so it's not a one-sided conversation out of order?
 15 2016-01-26 02:59:46 <btcdrak> Luke-Jr: Fixed
 16 2016-01-26 05:41:51 <op_null2_> Ethereum now #2 on coinmarketcap.com -- should we consider writing a high-level scripting language for Bitcoin?  Looks like the market is rewarding Ethereum because of this -- http://ethereum.github.io/solidity/
 17 2016-01-26 05:42:26 <AdrianG> there is a lot more to it than that, op_null2_
 18 2016-01-26 05:42:59 <op_null2_> I'm concerned about massive investor exodus into Ethereum as this stupid Classic civil war debate rages on.  Might need to think about fast-tracking Rootstock and Sidechains
 19 2016-01-26 05:44:26 <AdrianG> op_null2_: anthony di iorio is now chief digital officer at toronto stock exchange.
 20 2016-01-26 05:48:26 <op_null2_> yeah, not sure how qualified he is for that job to be honest.
 21 2016-01-26 05:49:23 <AdrianG> op_null2_: he's a salesman.
 22 2016-01-26 05:49:24 <op_null2_> Whatever 'digital' is supposed to mean
 23 2016-01-26 05:52:30 <op_null2_> Anyway, we can learn something from Solidity -- Developers love it.  We need something like that for Bitcoin.   Food for thought.
 24 2016-01-26 05:56:26 <AdrianG> what is your source
 25 2016-01-26 06:17:04 <gmaxwell> op_null2_: show me what non-trivial thing has been developed with  it?  I always ask and get nothing but fairly trivial stuff.
 26 2016-01-26 06:17:15 <gmaxwell> all the academic work instead adds opcodes to the ethereum VM.
 27 2016-01-26 06:24:50 <op_null2_> gmaxwell: this is probably the most widely used gambling contract -- https://etherdice.io/#contract
 28 2016-01-26 06:25:44 <gmaxwell> op_null2_: thats ... really not interesting, I mean you can easily do lotteries and gambling in bitcoin script (and more efficiently with the disabled opcodes reenabled)
 29 2016-01-26 06:27:10 <op_null2_> there are tons of companies building DApps w/ Solidity + web3.js + IPFS now . Decentralized Uber, Airbnb, etc.  Lots of emphasis on reputation and identity. Using proxy contracts to do tx's on your behalf that can have revokable public keys if you lose your private key -- n-of-m trusted signers can update your pubkey for you in the proxy contract
 30 2016-01-26 06:27:37 <op_null2_> gmaxwell: yeah, you can, but -- well, hipster web developers can't write apps with opcodes
 31 2016-01-26 06:28:11 <op_null2_> and they rule the world -- theres a new javascript framework every month.
 32 2016-01-26 06:28:17 <jeremias> op_null2_: decentralized uber, airbnb, etc? you gotta be kidding me
 33 2016-01-26 06:28:24 <jeremias> these guys have no idea what they are doing
 34 2016-01-26 06:28:39 <gmaxwell> smart contracts aren't apps, there is an academic paper coming out soon that basically shows that virtually every ethereum contract people are writing (including many of the examples) are totally insecure due to common mistakes in contract authorship.
 35 2016-01-26 06:29:03 <AdrianG> gmaxwell: which paper?
 36 2016-01-26 06:29:09 <AdrianG> i'd like to read that.
 37 2016-01-26 06:29:10 <jeremias> the level of understanding how world actually works seems to be missing from these people... yeah, replace every line of business with DAPPs
 38 2016-01-26 06:29:12 <gmaxwell> oh geesh this is OT for here.
 39 2016-01-26 06:29:23 <gmaxwell> AdrianG: not published yet, I'll point you to when it is.
 40 2016-01-26 06:29:29 <jeremias> well no one else talking, so no harm done, I guess
 41 2016-01-26 06:29:30 <AdrianG> what time frame?
 42 2016-01-26 06:30:28 <AdrianG> gmaxwell: so where do people talk about competition to bitcoin then
 43 2016-01-26 06:30:58 <op_null2_> gmaxwell: that will be an interseting read.  They're working on Formal Verification of solidity contracts now. https://blog.slock.it/an-ethereum-contract-analyzer-93e9da92fecb#.8ms3j7fhl
 44 2016-01-26 06:31:34 <jeremias> AdrianG: https://www.reddit.com/r/altcoin for example
 45 2016-01-26 06:32:29 <op_null2_> AdrianG: probably #bitcoin-wizards .. But, maybe Solidity will be on-topic if Rootstock becomes a Sidechain and 100% of BTC move over to it?
 46 2016-01-26 06:32:57 <AdrianG> i dont know, but this attitude that nothing ever happens outside bitcoin, is just ....
 47 2016-01-26 06:33:00 <AdrianG> sad.
 48 2016-01-26 06:33:10 <AdrianG> i cant think of a better word.
 49 2016-01-26 06:34:10 <jeremias> AdrianG: probably lots of things are happening, but some of these dAPP people are just out of this world
 50 2016-01-26 06:34:23 <op_null2_> I think we should be smart and monitor competition to stay a step ahead of it
 51 2016-01-26 06:34:28 <AdrianG> who cares about dAPP. I personally dont think its whats driving this.
 52 2016-01-26 06:34:39 <AdrianG> bitcoin has certainly an image problem, and a mining centralization problem.
 53 2016-01-26 06:34:53 <jeremias> I don't think so...
 54 2016-01-26 06:34:58 <AdrianG> nobody wants to run a business on a chain thats subject to hijacking by chinese miners.
 55 2016-01-26 06:35:19 <jeremias> bitcoin has been working very robustly for very long time
 56 2016-01-26 06:35:21 <AdrianG> even if it's "just" a hard fork.
 57 2016-01-26 06:35:45 <AdrianG> jeremias: recent events show that current state is not very robust.
 58 2016-01-26 06:35:51 <jeremias> whatever man...
 59 2016-01-26 06:36:09 <op_null2_> AdrianG: Unfortunately Bitcoin has lots of baggage, and strange characters with oversized egos.
 60 2016-01-26 06:36:27 <jeremias> I think that no sane person will choose any altcoin over bitcoin, unless something special is really needed
 61 2016-01-26 06:36:48 <jeremias> eg. if the job is basic value transfer and you want to use cryptocurrencies for it, bitcoin is very obvious choice
 62 2016-01-26 06:37:01 <AdrianG> jeremias: i see you have a lot of trust in bitmain
 63 2016-01-26 06:37:10 <jeremias> I don't even know what that is
 64 2016-01-26 06:37:21 <AdrianG> really..?
 65 2016-01-26 06:37:25 <AdrianG> you must be joking.
 66 2016-01-26 06:37:43 <jeremias> I'm not
 67 2016-01-26 06:37:49 <jeremias> I have never cared about mining
 68 2016-01-26 06:37:54 <jeremias> bitcoin has always just worked for me
 69 2016-01-26 06:37:58 <jeremias> without caring about mining
 70 2016-01-26 06:38:08 <jeremias> ok, sometimes there is a slow block
 71 2016-01-26 06:38:28 <AdrianG> sounds very much like "usd always worked for me, without caring about bankers"
 72 2016-01-26 06:38:41 <jeremias> hmm
 73 2016-01-26 06:38:47 <jeremias> what about this bitmain?
 74 2016-01-26 06:38:58 <jeremias> to be honest sounds like some "chinese miner" conspiracy
 75 2016-01-26 06:39:01 <AdrianG> until the bankers decide to freeze your account and suddenly usd doesnt work
 76 2016-01-26 06:39:15 <jeremias> and miners can freeze my bitcoin cold wallet exactly how?
 77 2016-01-26 06:39:19 <jeremias> your comparison is stupid
 78 2016-01-26 06:39:24 <AdrianG> its not a conspiracy, just a fact they are enormous
 79 2016-01-26 06:39:36 <jeremias> ok, there are lots of big businesses in the world
 80 2016-01-26 06:39:41 <TD-Linux> this might be an interesting discussion but it would be better in #bitcoin
 81 2016-01-26 06:39:45 <p15> +1
 82 2016-01-26 06:40:51 <AdrianG> time to check out indeed.
 83 2016-01-26 06:42:27 <op_null2__> I can just say from experience on the Ethereum forms and slack groups that there are hundreds of devs building dApps with Solidity and web3.js  ; why wouldn't Bitcoin want that sort of momentum behind it?
 84 2016-01-26 06:43:31 <op_null2__> anyway, I'll be waiting for that paper gmaxwell cited.  In the meantime they're working on Formal Verifications of the contracts
 85 2016-01-26 06:44:35 <op_null2__> btw, feedback from the roundtable seems like chinese miners need to speak more closely with core devs.  would be good to open communication channels.  Classic has had their ears for too long and they haven't heard enough from core
 86 2016-01-26 06:45:10 <AdrianG> nobody cares, op_null2__ , bitcoin is the best forever.
 87 2016-01-26 06:46:18 <op_null2__> My gut says they don't understand segwit, the only other explanation for their behaviour is that they are playing games/bluffing with Classic to cause uncertainty, waiting for a price drop, buying back lower, and then saying "alright , we'll go with Core again"
 88 2016-01-26 06:46:34 <op_null2__> which is a seriously dangerous game to play
 89 2016-01-26 08:15:48 <Taek> does someone mind clearing up the BIP66 hardfork for me? Want to make sure I have the facts correct before I go spreading misinformation
 90 2016-01-26 08:16:06 <Taek> As I understand, an accidental hardfork was integrated into a release (0.8.0?)
 91 2016-01-26 08:16:13 <Taek> miners upgraded, and forked the chain.
 92 2016-01-26 08:16:30 <Taek> then, after some discussion, and like 18 blocks of depth, the miners agreed to downgrade and restore compatibility
 93 2016-01-26 08:17:03 <Taek> all the full nodes running 0.7.x saw some weird activity but after the reorgs settled it was as though no fork had happened
 94 2016-01-26 08:17:28 <Taek> and the full nodes who upgraded to the hardforking 0.8.0 initially followed the fork, saw a reorg, and then followed the main chain too
 95 2016-01-26 08:17:40 <Taek> meaning the only people who were forced to downgrade to preserve compatibility were the miners themselves
 96 2016-01-26 09:37:27 <Pirat> всем привет
 97 2016-01-26 09:38:24 <Pirat> есть кто?
 98 2016-01-26 09:38:45 <Pirat> Is anybody here?
 99 2016-01-26 12:17:02 <chiwawa_> i gotta ask.. rather than waffling explanations.. is this a rough idea of segwits 2 year plan for the main blockchain http://i.imgur.com/9ERFaDJ.jpg
100 2016-01-26 15:37:51 <maaku> Taek: that's BIP 50
101 2016-01-26 15:39:31 <maaku> chiwawa_: no one really knows how weak blocks will turn out in practice
102 2016-01-26 15:39:36 <Taek> oh. Got confused because people keep talking about the BIP66 hardfork. But, BIP66 (strict DER) was not a hardfork either
103 2016-01-26 15:39:44 <Taek> right/
104 2016-01-26 15:39:47 <Taek> *?
105 2016-01-26 15:39:48 <maaku> BIP66 prevented a hard fork
106 2016-01-26 15:40:06 <Taek> ok. Thanks for the clarification.
107 2016-01-26 15:40:29 <maaku> BIP66 prevented a differentiation between valid serializations on 32-bit vs 64-bit architectures
108 2016-01-26 15:40:57 <maaku> which thankfully was kept under wraps and no one used before deployment of the soft-fork that limited serialization format
109 2016-01-26 15:41:57 <maaku> Taek: and BIP 50 itself contains of post-mortum of the 2013 fork
110 2016-01-26 15:43:36 <Taek> https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki
111 2016-01-26 15:44:01 <Taek> and yet there's very ubiquitous dialog about the "hardfork in 2013 - proving that hardforks can be deployed quickly when there is pressure"
112 2016-01-26 15:44:02 <Taek> :(
113 2016-01-26 15:44:29 <maaku> bitcoin was a lot smaller in 2013...
114 2016-01-26 15:45:27 <chiwawa_> im still wrapping my head around the whole. 2mb is bad as everyone needs to change.. vs. if you want to be a full verifying node after segwit, everyone needs to change..
115 2016-01-26 15:45:37 <Taek> If I'm reading the post-mortem correctly, there was no hardfork that got deployed? The 'quick action' involved getting 2 miners to downgrade, not getting the entire ecosystem to upgrade3
116 2016-01-26 15:46:01 <Taek> even if the network was a comparible size, BIP50 and a block size increase are two totally different beasts
117 2016-01-26 15:46:30 <instagibbs> chiwawa_, it's subtle. I think the phrase "spv security" is a misnomer to a large degree the way softforks are rolled out
118 2016-01-26 15:46:41 <maaku> chiwawa_: https://petertodd.org/2016/soft-forks-are-safer-than-hard-forks
119 2016-01-26 15:46:48 <instagibbs> but only my opinion apparently
120 2016-01-26 15:46:51 <Taek> chiwawa_: segwit has a much more graceful upgrade process though.
121 2016-01-26 15:47:29 <maaku> Taek: from the perspective 0.7 nodes there was a probabalistic hard fork that got deployed a few months later
122 2016-01-26 15:48:10 <maaku> Taek: it was never guaranteed that a 0.7 would hard-fork (it depended on the vageries of the bdb database)
123 2016-01-26 15:48:26 <maaku> and if you got stuck, chances were you could just -reindex and it would continue
124 2016-01-26 15:48:27 <Taek> I do think that deployment timelines for soft forks should be longer than they have been historically. I think that when CLTV was deployed, only 30% of fullnodes were doing full validation. That potentially gives miners wiggle room to undo the soft-fork, as the 'economic majority' may not have upgraded  yet
125 2016-01-26 15:49:41 <maaku> Taek: why? soft forks don't have SPV failure modes (if properly deployed)
126 2016-01-26 15:49:42 <Taek> maaku: I did not realize that. The dialog that I'm familiar with states that all nodes 0.3.21 and older will follow the chain. Didn't know they would probabilistically get stuck
127 2016-01-26 15:50:36 <Taek> maaku: can you expand on "soft forks don't have SPV failure modes (if properly deployed)", I'm not sure what you mean
128 2016-01-26 15:51:27 <maaku> Taek: if you are running bitcoind as a full node, you are ALWAYS only validating a subset of the rules that govern block creation
129 2016-01-26 15:52:07 <Taek> ?
130 2016-01-26 15:53:22 <maaku> but to your question specifically there aren't failure modes related to soft-forks where you end up on a fork that is not "the one true bitcoin"
131 2016-01-26 15:53:44 <Taek> the attack I'm talking about in my deployment-paranoid post is one where the miners start enforcing a softfork with anyone-can-spend. Some nodes upgrade, and then make use of the new features. Then miners stop enforcing it, steal the funds in the anyone-can-spend, and then essentially hardfork all the recently upgraded nodes off the network
132 2016-01-26 15:53:57 <maaku> I think it is a misapplication of the words "SPV security" to say that an unupgraded node is only "SPV secure"
133 2016-01-26 15:53:57 <Taek> nodes that haven't upgraded yet won't know the difference
134 2016-01-26 15:53:59 <chiwawa_> the problem with softforks is the misconception that people who are running core. (full nodes) think they dont have to upgrade and they think they are still fullnodes after a softfork.. but if full nodes want to be full nodes they have to upgrade.. so they might aswell be for a bigger and more effective reason.. EG 2mb+segwit. (best of both worlds)
135 2016-01-26 15:54:33 <maaku> Taek: nodes that haven't upgraded wouldn't use or care about the new feature
136 2016-01-26 15:54:39 <maaku> note that it is the UPGRADED nodes who are vulnerable
137 2016-01-26 15:55:15 <maaku> chiwawa_: they are full nodes. they remain full nodes
138 2016-01-26 15:55:15 <Taek> in this attack, yes
139 2016-01-26 15:55:39 <maaku> chiwawa_: there is no weaking of security after the deployment of segwit, nor was there after the deployment of p2sh
140 2016-01-26 15:55:47 <chiwawa_> not if they cant verify everything.. they would be classed as lightnodes or 90% nodes lol
141 2016-01-26 15:56:17 <Taek> The fear about 'SPV' for unupgraded nodes is that they can't tell if an incoming transaction is at risk of being reorged. They don't know if the mining power is going to agree on the new block, if the mining power is split between to different softfork rulesets
142 2016-01-26 15:56:24 <Taek> I think
143 2016-01-26 15:56:28 <Taek> but that's a risk anyway
144 2016-01-26 15:56:31 <maaku> chiwawa_: that is a misunderstanding of bitcoin's security model
145 2016-01-26 15:57:14 <Taek> or rather, unupgraded nodes don't know if their balance will still be valid after they upgrade.
146 2016-01-26 15:57:27 <maaku> Taek: so they wait for confirmations. note: this is true regardless of soft forks!
147 2016-01-26 15:57:35 <Taek> yeah
148 2016-01-26 15:57:59 <maaku> Taek: unupgraded nodes will not be seeing new-style transactions
149 2016-01-26 15:58:02 <maaku> (in their wallet)
150 2016-01-26 15:58:11 <chiwawa_> letting in data you cant check is not "full" node.. thats wishy washy 90% check node.. so emphasising "full node" where people want to FULLY check every transaction. which is the definition of a FULL node. for someone to be a full node.. rather than just a "compatible" node.. they need to upgrade
151 2016-01-26 15:58:30 <Taek> maaku: does that mean that, if segwit gets deployed, wallets will not acknowledge income sent from segwit addresses?
152 2016-01-26 15:59:06 <maaku> Taek: sure they will. but it's not in your balance until its confirmed ... same as always
153 2016-01-26 15:59:15 <chiwawa_> being a compatible node. that just accepts data blindly. is different to a full nod doing full checks..
154 2016-01-26 15:59:24 <maaku> sipa did a good writeup of this recently on the mailing list
155 2016-01-26 16:01:51 <Taek> if you are never planning on upgrading, that's sufficient and is full security. If you are planning on upgrading, there is uncertainty that the output was legal. You have SPV security on that output, assuming you are planning on upgrading.
156 2016-01-26 16:02:08 <Taek> hmm
157 2016-01-26 16:02:18 <Taek> that doesn't sound right now that I've said it out loud
158 2016-01-26 16:05:09 <instagibbs> chiwawa_, don't be so worried about other people's money :)
159 2016-01-26 16:05:32 <proslogion> maaku: hi, i remember you wrote something somewhere about why not to limit txs by size or number of sigops, is that true?
160 2016-01-26 16:06:32 <maaku> proslogion: i do not have a general write-up, but that is something I feel strongly about yes
161 2016-01-26 16:06:46 <proslogion> a reddit comment or something iirc
162 2016-01-26 16:06:51 <maaku> there are many more advanced protocols that use bitcoin for arbitration, and those arbitration proofs might be very large
163 2016-01-26 16:07:08 <maaku> if you're worried about validation cost, limit by validation cost. address the problem not the symptoms
164 2016-01-26 16:07:49 <proslogion> maaku: right tks, what i remembered though was a theoretical objection, not sure how i got that idea
165 2016-01-26 16:08:01 <chiwawa_> well thats what makes me laugh.. people that want to be full nodes, by definition want to be part of the security and worry about the communities funds as a whole.. so those wanting to be full nodes instead of compatible nodes do need to know all the ramifications if a upgrade is needed to remain full node status rather than just compatible status of 90% checkability.. we might aswell make the upgrade worthy by doing more than
166 2016-01-26 16:08:20 <instagibbs> proslogion, I think it's also easier for miners/spenders to efficiently price transactions and pack blocks
167 2016-01-26 16:08:29 <instagibbs> without the "&&" constraints
168 2016-01-26 16:08:44 <maaku> no it's very much a practical concern
169 2016-01-26 16:08:56 <proslogion> maaku: instagibbs thanks
170 2016-01-26 16:09:07 <maaku> the SPV peg for example will require huge transactions for the reorg/fraud proofs
171 2016-01-26 16:10:38 <instagibbs> proslogion, otherwise you get fun attacks like this: https://bitcointalk.org/index.php?topic=1166928.0;all
172 2016-01-26 16:14:40 <Taek> maaku: do you think VCM should be a hardfork? Otherwise you have to preserve all existing limitations.
173 2016-01-26 16:15:09 <Taek> which I think brings up another point. From a perspective of deployment, a block size increase is much simpler than other types of hardforks, especially if you are considereing custom clients and modified forks of bitcoind
174 2016-01-26 16:15:45 <Taek> if the hardfork is not as simple as changing a constant, legacy systems running different code are going to need more deployment time and effort
175 2016-01-26 16:16:11 <Taek> sorry if this has been beaten to death, I have the best intentions
176 2016-01-26 16:20:24 <maaku> VCM?
177 2016-01-26 16:20:33 <Taek> validation cost metric
178 2016-01-26 16:20:45 <Taek> I thought that's the term that was being used
179 2016-01-26 16:21:03 <maaku> First I've seen the acronym
180 2016-01-26 16:21:21 <maaku> When there is a hard fork, those limitations should be dropped.
181 2016-01-26 16:21:29 <Taek> togami was using it previously, though he might have been the only one
182 2016-01-26 16:22:07 <Taek> " those limitations" -> which ones?
183 2016-01-26 16:27:21 <maaku> Sigops, mostly.
184 2016-01-26 18:06:11 <jonasschnelli> I have a stuck tx (stuck because of non strict DER [low s]) on mainnet. I dropped the related inputs private keys. Can I normalize the input signatures with just the rawtx (from the blockchain) and re-broadcast?
185 2016-01-26 18:06:27 <jonasschnelli> It's just a couple of bits. But I'm wondering if its possible.
186 2016-01-26 18:11:48 <paveljanik> jonasschnelli, you definitely should be able to. Remember there was an high-s attack on the network...
187 2016-01-26 18:11:58 <paveljanik> There is an example in BIP0062 to do it.
188 2016-01-26 18:12:35 <jonasschnelli> paveljanik: Okay. Yes. I think i just extract the DER sig, pass it though libsecp256k1's normalize function, pack it back into the tx and re-broadcast.
189 2016-01-26 18:12:54 <jonasschnelli> The stuck tx is older then 14 day... I think it should be okay to double spend it.
190 2016-01-26 18:24:31 <arubi> genuine question, couldn't you just grab s, do something like 'mod(-s,n)', stick it back in (change size of input if needed) and broadcast?
191 2016-01-26 18:29:14 <arubi> oh.. "secp256k1_scalar_negate.."  I guess so.
192 2016-01-26 19:17:01 <wallet42> does the release version has zmq support built in or do i need to compile myself?
193 2016-01-26 19:21:04 <Luke-Jr> wallet42: I think the Linux builds will (note Core 0.11 does not have ZMQ at all)
194 2016-01-26 19:22:08 <wallet42> Luke-Jr thx
195 2016-01-26 19:28:29 <jonasschnelli> wallet42: only the "official" windows build does not have it. You need 0.12 (linux/osx).
196 2016-01-26 20:47:14 <denisx> hmm, bitcoin still needs openssl but libconsensus does not. is that right?
197 2016-01-26 20:47:44 <joecool> that's how i understand it... you can use libressl in place of openssl now if you like
198 2016-01-26 20:48:08 <instagibbs> openssl isn't used for consensus stuff, correct. Still used for RNG in wallet and other places
199 2016-01-26 21:18:36 <denisx> I try to build bitcoin 0.12.0rc2 on freebsd and I get “make[2]: don't know how to make FORCE. Stop”
200 2016-01-26 21:18:38 <denisx> any ideas?
201 2016-01-26 21:19:45 <Luke-Jr> gmake?
202 2016-01-26 21:20:00 <denisx> good hint
203 2016-01-26 21:21:26 <denisx> Luke-Jr: if it is a question then no, freebsd make
204 2016-01-26 22:04:13 <xabbix> Is some sort of attack going on atm?
205 2016-01-26 22:06:14 <xabbix> I see a huge amount of transactions being broadcasted to my node
206 2016-01-26 22:07:40 <xabbix> almost all are orphan
207 2016-01-26 22:14:07 <denisx> Luke-Jr: using to gmake helped
208 2016-01-26 22:14:17 <denisx> aeh, switching to gmake helped
209 2016-01-26 23:39:01 <xabbix_> How do I define multiple debugging categories in bitcoin-core? -debug=alert,mempool?