1 2016-01-16 00:00:21 <Anduck> is the decentralization / (100% or very very close to 100% trust-less usage) how important after all
 2 2016-01-16 00:00:52 <Anduck> i mean, 100% trust-less usage VS very close to 100% trust-less usage (for example relying on 10 random full nodes via SPV) or such
 3 2016-01-16 00:05:24 <op_null2_> Anduck: then they can leave that out. Point is, Bitcoin took a major hit in the Financial world today, very bad PR. Needs to be countered to help short term momentum
 4 2016-01-16 00:05:39 <Anduck> just some things that people really want to know about, i think.
 5 2016-01-16 00:05:45 <Anduck> op_null2_: indeed
 6 2016-01-16 00:06:11 <op_null2_> Mainstream press readers think the leader of Bitcoin quit, and its 'failed'.  We know that's nonsense, but they don't.  NYT is a well respected newspaper.
 7 2016-01-16 00:07:05 <op_null2_> A "Bitcoin developers response to Mike Hearn" article would be very helpful.  Its times like this that a (trusted) Bitcoin Foundation could actually be useful
 8 2016-01-16 00:07:07 <Anduck> just some thoughts i think should be addressed at some point. i've been paying quite close attention to everything re: bitcoin but those are some open questions
 9 2016-01-16 00:07:24 <Anduck> op_null2_: indeed.
10 2016-01-16 00:08:18 <brg444> op_null2 the mainstream financial world was sold the premise that "Bitcoin is dead" about a hundred times
11 2016-01-16 00:08:26 <brg444> One more isn't going to change much
12 2016-01-16 00:08:37 <Anduck> this is the first time "bitcoin dev loses faith"
13 2016-01-16 00:15:20 <melvster> brg44:  88 times so far. https://99bitcoins.com/bitcoinobituaries/
14 2016-01-16 00:16:00 <melvster> apologies if that's off topic ... back to work ...
15 2016-01-16 00:30:29 <op_null2> BitFury going to mine w/ Classic.  Perhaps we need to consider a short term 2MB patch to Core, and then work toward autonomous blocksize adjustments based on previous N blocks
16 2016-01-16 00:31:08 <Anduck> op_null2: actually they said they support it. doesn't mean that they will run it without consensus?
17 2016-01-16 00:32:31 <op_null2> https://twitter.com/valeryvavilov/status/688054411650818048
18 2016-01-16 00:32:38 <op_null2> its quite clear they will be running classic
19 2016-01-16 00:34:06 <instagibbs> op_null2, you mean something like flexcap?
20 2016-01-16 00:35:00 <phantomcircuit> op_null2, they clearly want a cease fire, 2MB hard fork is a clear sign of that
21 2016-01-16 00:36:27 <op_null2> instagibbs: yes, flexcap.  ethereum has implemented it (via GAS limit)
22 2016-01-16 00:37:31 <instagibbs> I'd rather not have a miner voted one unless it actually costs, but ok
23 2016-01-16 00:38:00 <brg444> phantomcircuit what does that say for the future of Bitcoin though :/
24 2016-01-16 00:40:24 <brg444> I mean I understand 2MB might not be the end of Bitcoin but seems to me the way sound engineering process risks folding to peer pressure is worrisome to say least
25 2016-01-16 00:41:01 <op_null2> phantomcircuit:  We've been at 1MB blocks since 2010, one would imagine that 2MB should be fine in 2016.    At least its down from gavins original 20MB or the 8MB 'compromise'
26 2016-01-16 00:42:40 <op_null2> I'd rather see Core capitulate on this, do 2MB, and then address scalability over the next few years.  The alternative is that the Miners and economic majority switch to Classic, Gavin invites Mike back to be its benelovent dictator, and the rest of us give up and move to Ethereum
27 2016-01-16 00:44:18 <brg444> https://twitter.com/OneMorePeter/status/687946857260183552 It's pretty sad reading these tweets knowing the entire industry had deliberately chosen to ostracize Core from any decisional process
28 2016-01-16 00:44:56 <op_null2> Sadly , 95% of the economy, including CEO's of the $1 Billion in VC backed companies, don't understand the risks properly.  Without PR/education coming out of Core, it's not going change anytime soon.   The Bitcoin Foundation also could have played a positive role in this if they didn't screw up so massively
29 2016-01-16 00:46:12 <op_null2> Core should strongly consider  playing some politics here, in order to maintain long-run control of the codebase that the  economic majority is going to use
30 2016-01-16 00:47:10 <op_null2> I've been a strong Core supporter on reddit/forums/elsewhere, but todays Miners/company statements moving to classic don't look good.
31 2016-01-16 00:48:01 <op_null2> Blockchain.info just announced classic support also  -- https://twitter.com/OneMorePeter/status/688152192675516416
32 2016-01-16 00:49:15 <brg444> op_null2 see my post above. clearly the industry has been meeting and planning for this...
33 2016-01-16 00:50:04 <Anduck> i'd love to see a "final hard fork" for bitcoin to happen. no more politics about those things
34 2016-01-16 00:51:09 <op_null2> It would be stupid to hard fork just for the 2MB limit.  If its going to happen, we should integrate everything on this page at the same time: https://en.bitcoin.it/wiki/Hardfork_Wishlist
35 2016-01-16 00:51:35 <op_null2> We could turn some lemons into lemonade
36 2016-01-16 00:51:46 <op_null2> throw in Ethereum's VM while we're at it
37 2016-01-16 00:52:29 <Anduck> op_null2: indeed!
38 2016-01-16 00:53:18 <instagibbs> lol
39 2016-01-16 00:53:26 <phantomcircuit> <brg444> op_null2 see my post above. clearly the industry has been meeting and planning for this...
40 2016-01-16 00:53:31 <phantomcircuit> but there's no conspiracy right?
41 2016-01-16 00:54:02 <op_null2> Conspiracy == Politics.
42 2016-01-16 00:54:15 <op_null2> Core needs to be better at Marketing/PR/Politics. I'm happy to help.
43 2016-01-16 00:54:26 <Anduck> :)
44 2016-01-16 00:55:30 <op_null2> Its an education thing. The talking points from the large-block camp are very compelling to the uninformed.
45 2016-01-16 00:55:52 <Anduck> well, they've oversimplificated things to make them appealing
46 2016-01-16 00:56:18 <Anduck> doesn't need to have any bad intentions for that to happen, it just is so
47 2016-01-16 00:56:40 <op_null2> Of course, Core should to do the same to counter.  Simple and concise talking points
48 2016-01-16 00:57:02 <brg444> Problem is it's a bit late for that...
49 2016-01-16 00:57:27 <Ylbam> If ever an hard fork to Classic succeeds what the Core team plans to do?  Could they keep working on a  Bitcoin "Core" fork?
50 2016-01-16 00:57:59 <Anduck> brg444: nope, not late
51 2016-01-16 00:59:00 <Anduck> well, if the fork succeeds the 2mb won't be not-bitcoin IMO
52 2016-01-16 00:59:00 <Ylbam> Can we expect an official statement from the Core team about Classic in the coming days?
53 2016-01-16 00:59:25 <Anduck> Ylbam: i guess official statements are very hard and dangerous things for projects like bitcoin core
54 2016-01-16 00:59:27 <Ylbam> Anduck: so the Core team would switch working on Classic?
55 2016-01-16 00:59:31 <Anduck> i don't know.
56 2016-01-16 00:59:33 <brg444> Anduck it seems so to me, they have lobbying power on their side. The only thing they're missing really is a... devf
57 2016-01-16 00:59:35 <brg444> dev*
58 2016-01-16 01:00:27 <Ylbam> I'm afraid some of the core devs might defintely stop working on Bitcoin, that would be a great loss
59 2016-01-16 01:00:29 <Anduck> if i were a dev i'd work hard to make a solution which fixes the need to hard fork ever again
60 2016-01-16 01:00:41 <Anduck> Ylbam: indeed.
61 2016-01-16 01:01:09 <Anduck> would've happened definitely if XT went through. but it didn't and now it won't for sure.
62 2016-01-16 01:03:15 <owowo> <Anduck> if i were a dev i'd work hard to make a solution which fixes the need to hard fork ever again <-- exactly, why not a variable blocksize computed on network performance
63 2016-01-16 01:03:50 <Anduck> it's hard ot measure the important factors of network performance
64 2016-01-16 01:03:55 <Anduck> hashrate isn't really that related
65 2016-01-16 01:07:25 <owowo> not hashrate as parameter but block propagation time or something alike
66 2016-01-16 02:34:02 <zmanian_> I remember seeing something about Dockerfiles for Bitcoin core. Anyone know what I'm talking about?
67 2016-01-16 02:45:42 <frankenmint> maybe zmanian_, give me some more context
68 2016-01-16 02:48:43 <zmanian_> I'm looking for a Dockerfile that I can customize that will deploy a full node to a server.  I vaguely remember someone announcing having created some. A quick google search didn't yield any that matches my memory. Not that creating one is hard.
69 2016-01-16 02:51:02 <frankenmint> https://medium.com/@abrkn/running-the-bitcoin-core-daemon-as-a-docker-container-7d290affa56b#.r8qz3vg0o
70 2016-01-16 03:13:07 <thevjm> Bitcoin has stopped working and crashes on launch with a seg fault. I don't know what has caused this but I did recently upgrade my system. Can anyone help me out?
71 2016-01-16 04:57:58 <geosmin> .close
72 2016-01-16 05:32:32 <op_null2_> are there any bitcoinj / android devs here looking for contract work? msg me
73 2016-01-16 07:28:09 <Guest87980> can smeone help me building bitcoin classic on ubuntu
74 2016-01-16 07:31:38 <midnightmagic> Guest87980: you're in the wrong place for that
75 2016-01-16 08:59:42 <sami_> hello
76 2016-01-16 15:52:55 <frank1e> hi
77 2016-01-16 19:39:29 <brg444> "sergiodemianlerner 5:29 PM Regarding SegWit, I don't know if you have actually looked at the code but the amount of code changed, including consensus code, is huge. (maybe ~500 lines). I think such change has never been attempted in the history of Bitcoin. We cannot just say lightly that a couple of weeks after the 2mb hard-fork we're going to deploy segwit. That code needs months of review."
78 2016-01-16 19:39:34 <brg444> "Also I'm against the complexity of segwit as a soft-fork (probably requires 200 additional lines of code of consensus critical code). Segwit almost prevents consensus-compatible re-implementations of Bitcoin in other languages."
79 2016-01-16 19:39:36 <brg444> MEH
80 2016-01-16 19:39:38 <brg444> oops
81 2016-01-16 19:39:44 <brg444> so this is what we have to deal with heh
82 2016-01-16 20:24:52 <kang_> Why do we maintain last 288 blocks when pruning enabled? For reorg risks??
83 2016-01-16 22:52:48 <adnn> anyone looked at this yet? https://eprint.iacr.org/2016/024.pdf
84 2016-01-16 22:54:01 <kang_> "Marketplace  Trader attack  exploits  the  refund  policies  of  existing Payment Processors" not very interesting
85 2016-01-16 22:54:52 <kang_> "The Silkroad Trader attack relies on a vulnerability in the Payment Protocol as the customer can authenticate that messages originate from the merchant, but  not  vice-versa.  This  allows  a  customer  to  route  payments  to  an  illicit trader via a merchant and then plausibly deny their own involvement."
86 2016-01-16 22:55:18 <adnn> Yaa, not too interesting.
87 2016-01-16 23:36:04 <achow101> Where can I get osslsigncode-Backports-to-1.7.1.patch for gitian building? The link in release-process.md returns a 404