1 2016-01-13 00:26:05 <StephenM347> Any expected release time for 0.12.0? Isn't 0.12.0 the first release using Pieter W's secp256k1 library with a big verification speed boost?
  2 2016-01-13 00:28:30 <morcos> StephenM347: yes, and hopefully not long now, early february?  Release Candidate 1 is expected any day
  3 2016-01-13 01:06:33 <StephenM347> morcos: cool, thanks for the info
  4 2016-01-13 01:30:09 <Luke-Jr> StephenM347: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/011182.html
  5 2016-01-13 03:47:52 <brg444> question: there was talk of building bridges between the chinese mining and dev community with western actors at ScalingBitcoin, anyone know if there was progress made toward this
  6 2016-01-13 03:50:06 <brg444> I'm was honestly dumbfounded to read wangchun , someone from the chinese community who was in the past postin the dev mailing list seemingly "discover" Core's roadmap just today! :/
  7 2016-01-13 03:50:12 <brg444> I
  8 2016-01-13 03:50:35 <AdrianG> link?
  9 2016-01-13 03:51:42 <brg444> somewhere in the logs
 10 2016-01-13 03:55:07 <jtoomim> i had an idea of building a translated/moderated email list, but haven't finished it yet
 11 2016-01-13 03:55:11 <jtoomim> brg444
 12 2016-01-13 03:55:33 <brg444> cool
 13 2016-01-13 03:55:43 <brg444> I really feel like this is sorely needed
 14 2016-01-13 03:55:57 <jtoomim> yeah, i agree
 15 2016-01-13 03:56:14 <jtoomim> in wangchun's case i don't think it would have helped too much, since his english is pretty good
 16 2016-01-13 03:56:26 <jtoomim> and since the roadmap FAQ has been translated into chinese
 17 2016-01-13 03:56:30 <brg444> it really is inconceivable that we stay so out of touch with such an important part of the economy
 18 2016-01-13 03:56:40 <brg444> right
 19 2016-01-13 03:56:44 <jtoomim> i also thought wangchun signed the document in support of the roadmap almost a month ago, which is weird
 20 2016-01-13 03:57:24 <brg444> but it brings me to question what information other miners have with regards to their plan and if their input has been considered and discussed
 21 2016-01-13 03:57:41 <brg444> I mean Core's plan
 22 2016-01-13 03:57:55 <jtoomim> yes, and also if they've had a chance to review the objections
 23 2016-01-13 03:58:21 <Luke-Jr> brg444: they (some?) Chinese miners wanted everyone to use some spyware chat thing that requires an Android device. someone got me in, but it keeps dying and I haven't bothered to rejoin it in a few days. It was virtually silent anyway, and the little that was said, was in Chinese.
 24 2016-01-13 03:58:31 <jtoomim> WeChat
 25 2016-01-13 03:58:38 <Luke-Jr> yeah
 26 2016-01-13 03:58:44 <jtoomim> yeah, i'm on that
 27 2016-01-13 03:58:48 <jtoomim> the chinese are nuts about wechat
 28 2016-01-13 03:58:56 <jtoomim> err, i'm going to have to go silent for a bit, sorry
 29 2016-01-13 03:59:10 <Luke-Jr> …
 30 2016-01-13 04:00:23 <brg444> Luke-Jr Is there anyone from Core that has attempted to communicate with them. Do you know if there's been any contact since the conferences?
 31 2016-01-13 04:00:51 <Luke-Jr> brg444: well, I was there for a few days at least; but there's no real communication
 32 2016-01-13 04:01:08 <Luke-Jr> I hear more from wangchun on IRC, than everyone on WeChat..
 33 2016-01-13 04:01:51 <brg444> Right. I'm just wondering out it is other people seemingly have no issue getting into their ears..
 34 2016-01-13 04:01:53 <brg444> Oh well
 35 2016-01-13 04:02:10 <brg444> why it is*
 36 2016-01-13 04:12:09 <zooko> Luke-Jr: did you see the WeChat translation feature?
 37 2016-01-13 04:12:18 <zooko> Is wangchun a miner?
 38 2016-01-13 04:12:40 <zooko> brg444: I think it is easy for people to underestimate just how difficult communication is.
 39 2016-01-13 04:12:59 <zooko> People just being completely unaware of major, critical stuff that is visible on the Web is quite common.
 40 2016-01-13 04:13:31 <zooko> There's always a social bubble effect, where everyone that you talk to (about this topic) has a lot of shared knowledge, and so you naturally assume that everyone else who also cares about that also has most of that knowledge.
 41 2016-01-13 04:13:33 <Luke-Jr> zooko: no, there is no such feature in the web version
 42 2016-01-13 04:13:44 <zooko> But, then sometimes you ping out right when I'm talknig to you, see? Communication.
 43 2016-01-13 04:13:51 <zooko> Luke-Jr: Ah.
 44 2016-01-13 09:16:55 <mnk> Here's the video of the Bitcoin Meetup in Berlin from yesterday. Topics include: Interledger by Ripple, The Global Chained Delivery Network by RWE and a bit on Ethereum  in Q&A https://www.youtube.com/watch?v=3pyH5BlXBtM
 45 2016-01-13 14:05:07 <cjcj> How can I initiate a reorg in regtest mode? Is there some rpc call that allows me to build new blocks on older blocks?
 46 2016-01-13 14:09:09 <lorenzoasr> cjcj, you could disconnect a node from your regtest network, then continue generating blocks in parallel
 47 2016-01-13 14:09:18 <lorenzoasr> and then link back
 48 2016-01-13 14:24:31 <Lightsword> Luke-Jr, “in fact, can't really do that accurately unless you kill the relay network for a day” well that wouldnt really make it accurate either since the Chinese pools mine on stratum headers
 49 2016-01-13 14:31:08 <rael_wiki> hello, I am trying to send a raw transaction but I keep failing for "insufficient priority". As far as I understood the priority of a tx is computed as the sum of satoshis*input_age for every input divided by the size of the tx in bytes. I can't come up with a way to tweak these parameters so that my tx has a high enough priority (one way would be to wait for the inputs to be old enough but that would slow down my entire system by a large amount of
 50 2016-01-13 14:32:21 <rael_wiki> time, another way would be to spend very large inputs but I can't be sure my inputs will always be large enough). I noticed that I can avoid the priority check altogether just by increasing the transaction's fee, but I am not sure how to balance it to make sure that every transaction will be sent. Any help?
 51 2016-01-13 15:18:52 <morcos> rael_wiki: sending a tx without sufficient fee is a pretty risky idea these days unless you really know what you are doing.  i would recommend making sure you have sufficient fee.
 52 2016-01-13 15:19:04 <morcos> this is more a question for #bitcoin though
 53 2016-01-13 15:20:21 <rael_wiki> thank you morcos, I see your point. The problem is that I am producing a tx with a fee of 2756 satoshis for 226 bytes, so I don't understand why the fee should be considered too lwo
 54 2016-01-13 15:20:45 <rael_wiki> as far as I know, one should use around 1000 satoshis per kb, right?
 55 2016-01-13 15:28:01 <aj> rael_wiki: 5000 satoshis per kB is minrelay, 10000 satoshi/kB is closer to normal
 56 2016-01-13 15:28:55 <rael_wiki> all right, aj, thanks a lot, I thought it were 1000 satoshis per kB
 57 2016-01-13 15:29:54 <aj> rael_wiki: http://www.cointape.com/ might be helpful for a sanity check
 58 2016-01-13 15:30:40 <aj> rael_wiki: (see "estimatefee" using a bitcoin full node also)
 59 2016-01-13 15:31:12 <rael_wiki> aj: thanks a lot for the pointers!
 60 2016-01-13 15:52:48 <deadalnix> why hosts do not serve the genesis block on getblocks requsts without locators ?
 61 2016-01-13 15:56:10 <deadalnix> is the only to checkout the genesis block is to explicitly ask for it ?
 62 2016-01-13 15:59:03 <gavinandresen> cjcj : you can use invalidateblock / reconsiderblock to create re-org scenarios in regtest mode.
 63 2016-01-13 15:59:25 <gavinandresen> cjcj : grep for those in qa/rpc-tests for examples
 64 2016-01-13 16:06:37 <cjcj> gavinandresen: Thanks!
 65 2016-01-13 16:08:40 <Chris_Stewart_5> When you call the getrawtransaction 0 is that the same serialized format that is used by nodes on the network?
 66 2016-01-13 16:20:02 <gavinandresen> Chris_Stewart_5: yes, but in hex not binary.
 67 2016-01-13 16:20:29 <gavinandresen> Chris_Stewart_5: ... and network messages have headers and checksums around the data, of course...
 68 2016-01-13 16:20:54 <Chris_Stewart_5> Thanks gavinandresen :-)
 69 2016-01-13 16:29:58 <murch> gavinandresen: You had stated somewhere (I think it was reddit) that a lot of the development going into 0.12 would have to be redone/reorganised. Could you elaborate?
 70 2016-01-13 16:31:41 <murch> (Or if you wrote more about that and could give me a link that would be marvelous)
 71 2016-01-13 17:13:46 <deadalnix> gavinandresen: +1 with murch requests, i'd like to know more
 72 2016-01-13 17:51:31 <bsm117532> What is bitcoin's p2p relay algorithm called?  I remember a word like whisper or rumor or chatter or something?
 73 2016-01-13 17:56:02 <bsm117532> e.g. what's the name of the algorithm which re-broadcasts messages that have not been seen by peers, the way bitcoin does?
 74 2016-01-13 17:56:57 <gavinandresen> bsm117532: it's a dumb gossip algorithm.
 75 2016-01-13 17:57:09 <bsm117532> gossip!!!  That's it!  Thanks!
 76 2016-01-13 17:57:31 <gavinandresen> murch: really?  I don't remember ever saying that.  Maybe you have me confused with mike hearn.
 77 2016-01-13 17:58:34 <gavinandresen> There's lots of great stuff in 0.12
 78 2016-01-13 18:04:58 <Luke-Jr> gavinandresen: while you're here, I just want to clarify to what extent you support "Classic" (I'm seeing a lot of claims I *know* is false about the project)
 79 2016-01-13 18:05:08 <Luke-Jr> s/support/are involved with/
 80 2016-01-13 18:05:13 <gavinandresen> Luke-Jr: I'm writing a blog post about that right now!
 81 2016-01-13 18:05:22 <Luke-Jr> gavinandresen: ah, great, I'll just wait and read that then
 82 2016-01-13 18:06:23 <lorenzoasr> i noticed that doing lot of concurrent requests from ~10 processes to a single 0.11 node in regtest through python-bitcoinlib causes the node to stop responding, until I stop all processes, then it aswers all the past requests. After some testing I noticed that often different processes used the same id for rpc requests. Modifying the library so that all processes always use different ids apparently fixes the problem. Does this make any sense ?
 83 2016-01-13 18:07:02 <Luke-Jr> lorenzoasr: interesting; the entire RPC server was redone for 0.12, but I hadn't heard that correlation before
 84 2016-01-13 18:10:02 <lorenzoasr> Luke-Jr, is there any locking policy which depends on request ids ? it seems like a deadlock problem to me
 85 2016-01-13 18:11:25 <Luke-Jr> lorenzoasr: I would be surprised if there was anything that used the id other than the reply serialiser
 86 2016-01-13 18:13:11 <lorenzoasr> Luke-Jr, me too, but then I can't see a reason for this problem. At the moment using redis as unique id generator seems to fix this problem, that's why I thought that could be the problem
 87 2016-01-13 18:25:00 <StephenM347> I just pulled and built bitcoind for the first time in a while (OS X). It seems to build fine but I get many many warnings for 'warning: unused typedef 'boost_static_assert_typedef_1256' [-Wunused-local-typedef]'. Is this normal/expected?
 88 2016-01-13 18:29:54 <NikolaTesla> Hi guys, is anyone here working on Bitcoin related Automatic Trading Algo ?
 89 2016-01-13 18:31:32 <phantomcircuit> NikolaTesla, off topic
 90 2016-01-13 18:40:53 <NikolaTesla> sorry ...
 91 2016-01-13 18:49:21 <Dizzle> You can try #bitcoin and ##bitcoin. If it's a good trader, they probably wouldn't be keen to share what they're working on though :)
 92 2016-01-13 19:12:11 <NikolaTesla> Thanks Dizzle, tryed on #R-Finance as I thought it was more in-topic there ... actually it seems it is
 93 2016-01-13 19:12:24 <Dizzle> groovy
 94 2016-01-13 20:57:26 <jtimon> tomorrow I'm going to ask people to review #7091 #7287 #7311 and #7310 if libconsensus encapsulation can be a topic within the meeting
 95 2016-01-13 22:22:50 <David______> Hi everyone
 96 2016-01-13 22:22:57 <David______> Need some help
 97 2016-01-13 22:34:50 <maaku> David______: ask, don't ask to ask
 98 2016-01-13 23:11:14 <nwilcox> Can anyone direct me to an explanation for "There is no from address" in the topic?
 99 2016-01-13 23:12:16 <Luke-Jr> http://en.bitcoin.it/wiki/From_address
100 2016-01-13 23:12:24 <nwilcox> Thanks.
101 2016-01-13 23:18:50 <benjyz1> Luke-Jr: you wrote about soft-forks /hard-forks in the recent bitcoin.org core post
102 2016-01-13 23:19:33 <Luke-Jr> benjyz1: ?
103 2016-01-13 23:19:37 <benjyz1> https://github.com/bitcoin-dot-org/bitcoin.org/pull/1194
104 2016-01-13 23:19:37 <Luke-Jr> what about it?
105 2016-01-13 23:20:08 <benjyz1> > On the contrary, softfork/hardfork are indeed very well-defined. A softfork is any change which adds new rules to the consensus protocol,
106 2016-01-13 23:20:17 <benjyz1> I'm wondering what you mean by rules...
107 2016-01-13 23:20:53 <Luke-Jr> benjyz1: a consensus system like Bitcoin works by every node enforcing a set of "consensus rules" on inputs (in this case, new blocks)
108 2016-01-13 23:21:25 <benjyz1> how do you distinguish between "rules" and the entire codebase?
109 2016-01-13 23:21:53 <benjyz1> what part of bitcoin-core could I change without invalidating those rules
110 2016-01-13 23:22:20 <benjyz1> that's not deterministic...
111 2016-01-13 23:25:01 <benjyz1> if I understand correctly lib-consensus aims at more or less this. separating out particular code as consensus code
112 2016-01-13 23:25:30 <Luke-Jr> benjyz1: you understand correctly.
113 2016-01-13 23:25:49 <Luke-Jr> benjyz1: basically, if a piece of code can cause a block to be rejected as invalid, it is a consensus rule
114 2016-01-13 23:26:03 <Luke-Jr> all nodes within the system must accept the same blocks and reject the same blocks
115 2016-01-13 23:26:20 <Luke-Jr> otherwise, they will disagree and fail to come to a consensus
116 2016-01-13 23:27:00 <benjyz1> thx for the info. trying to understand how could SegWit be a soft-fork
117 2016-01-13 23:27:47 <CodeShark> it would be possible to structure the consensus codebase such that each test either fails (upon which the entire check fails for the entire block) or succeeds and gets chained or nested
118 2016-01-13 23:28:03 <CodeShark> then it would be deterministic to check whether a change is a soft fork
119 2016-01-13 23:28:59 <CodeShark> the only requirement is that the tests be stateless/without side effects
120 2016-01-13 23:30:14 <Luke-Jr> benjyz1: if more than 50% of miners decide a block that was previously valid, is now invalid, the nodes which accept it will reject it as soon as those miners make a longer chain
121 2016-01-13 23:32:01 <benjyz1> can a node deduce what software produced the block? I guess no
122 2016-01-13 23:32:55 <nwilcox> benjyz1: You have a good intuition though because a lot of code may implicitly affect consensus even if no human maintainers realize it, such as https://bitcoin.org/en/alert/2013-03-11-chain-fork
123 2016-01-13 23:34:02 <Luke-Jr> benjyz1: not unless something like SNARKs are used, but that's bleeding edge stuff
124 2016-01-13 23:34:03 <nwilcox> The goal of libconsensus, as I understand it, is to help us humans reduce the chance that there is code affecting the consensus in unexpected ways.
125 2016-01-13 23:35:07 <CodeShark> oh, right - another requirement is that each test itself be deterministic
126 2016-01-13 23:36:18 <CodeShark> which is not a trivial problem :)
127 2016-01-13 23:37:17 <CodeShark> but yeah, we can break it down into small chunks which we can rigorously test
128 2016-01-13 23:37:26 <CodeShark> and review
129 2016-01-13 23:38:29 <benjyz1> Luke-Jr: I looked at Snark's and Zero-Knowledge and am skeptical of its use. some code might appear deterministic when it is not
130 2016-01-13 23:39:09 <benjyz1> some of the foundations of this cryptography seems pretty shaky to me. AFAIK these things are not widely used
131 2016-01-13 23:39:39 <Luke-Jr> benjyz1: yes, just answering the question ;)
132 2016-01-13 23:42:00 <benjyz1> yes, thanks. and the relationship between SegWit and consensus? BIP141 is titled "Segregated Witness (Consensus layer)"
133 2016-01-13 23:42:58 <CodeShark> there are multiple BIPs, benjyz1, as per BIP123's recommendations
134 2016-01-13 23:43:25 <CodeShark> segwit requires changes to at least three if not all four layers
135 2016-01-13 23:44:32 <Luke-Jr> so BIP 141 will define the new rules that blocks must pass before acceptance
136 2016-01-13 23:46:03 <benjyz1> does this increase ability to implement some kind of settlement layer?
137 2016-01-13 23:46:29 <CodeShark> yes - the fix to malleability allows more sophisticated off-chain protocols
138 2016-01-13 23:47:47 <benjyz1> Hal Finney had some interesting thoughts on scalability back in 2010 - https://bitcointalk.org/index.php?topic=2500.msg34211#msg34211
139 2016-01-13 23:48:12 <benjyz1> "Bitcoin backed banks will solve these problems."
140 2016-01-13 23:48:52 <Luke-Jr> benjyz1: Lightning may possibly make them unnecessary :p
141 2016-01-13 23:49:31 <benjyz1> it would have to be a kind of credit system in any case
142 2016-01-13 23:50:32 <Luke-Jr> yes and no; it's trustless
143 2016-01-13 23:51:16 <moa> "trustless credit"?
144 2016-01-13 23:51:23 <CodeShark> entry into the system might require creditors
145 2016-01-13 23:52:03 <CodeShark> you can't open channels without making a deposit
146 2016-01-13 23:52:27 <benjyz1> most likely hubs would have to follow KYC/AML procedures, like Bitcoin exchanges
147 2016-01-13 23:52:44 <CodeShark> only if they have custody of others' funds
148 2016-01-13 23:52:45 <moa> benjyz1: no
149 2016-01-13 23:53:28 <CodeShark> LN allows non-custodian hubs
150 2016-01-13 23:53:37 <benjyz1> there needs to be some kind of liquidity they provide
151 2016-01-13 23:53:52 <CodeShark> or custodial :p
152 2016-01-13 23:54:17 <moa> legal questions are outside technical dev. considerations anyway
153 2016-01-13 23:54:53 <benjyz1> moa: hard to discuss money and AML/KYC without law
154 2016-01-13 23:55:14 <moa> correct but you are on a technical dev IC channel
155 2016-01-13 23:55:19 <moa> s/IRC
156 2016-01-13 23:55:34 <benjyz1> this was about scalability
157 2016-01-13 23:56:52 <moa> so suggest you keep it about capacity increases and leave the wandering off into legal weeds for other forums
158 2016-01-13 23:57:00 <benjyz1> tbh, anyone in Bitcoin who wants to ban economic discussions is in the wrong place.
159 2016-01-13 23:57:28 <CodeShark> I think you were doing fine until the topic of KYC/AML :)
160 2016-01-13 23:57:46 <benjyz1> I'm doing quite fine in any case.
161 2016-01-13 23:57:46 <moa> it's simply about scope creep and remaining focussed to advance the discussion
162 2016-01-13 23:59:21 <benjyz1> almost all bitcoin flow through bitcoin company which have to deal with these things.