1 2015-08-29 00:09:48 <baldur> i built from source not too long ago( a few weeks) on 14.04
  2 2015-08-29 00:12:48 <Luke-Jr> it occurs to me, something like BIP100 where 50% of miners can express what size over which they will softfork out, is only an improvement no matter what the hard maximum ends up being
  3 2015-08-29 00:15:12 <gmaxwell> Luke-Jr: I agree.
  4 2015-08-29 00:15:57 <gmaxwell> Luke-Jr: thats also true for the actual numbers in it, e.g. 20%
  5 2015-08-29 00:16:18 <gmaxwell> because 50% can still softfork out numbers they don't like, but there is then a coordination mechenism.
  6 2015-08-29 00:16:50 <gmaxwell> probably the only real downside within the limits of what it does is that it may legitimize abusive participation.
  7 2015-08-29 00:17:23 <gmaxwell> E.g. Say it is broadly considered an objective truth that a 12MB block is destroying the system.   "Too bad, my 'vote' if I want 12MB I can choose it"
  8 2015-08-29 00:17:35 <Luke-Jr> gmaxwell: I don't follow, how can 20% softfork a block size limit?
  9 2015-08-29 00:18:05 <Luke-Jr> I agree it shouldn't be perceived as a replacement for the hard limit, just a *new* auto-negotiated limit.
 10 2015-08-29 00:18:42 <gmaxwell> Luke-Jr: they can't-- rather 50% can do whatever it wants. So if your percentile is <50% it's still 50% if they're willing to take action.
 11 2015-08-29 00:19:53 <Luke-Jr> if <50% want to reduce the limit, they can't do it right now
 12 2015-08-29 00:27:03 <Diablo-D3> okay so
 13 2015-08-29 00:27:16 <Diablo-D3> bip100 is a systematic vote on blocksize?
 14 2015-08-29 00:30:50 <gmaxwell> Luke-Jr: yes, an in bip100 they can only do it if the majority permit them to.
 15 2015-08-29 00:38:47 <Diablo-D3> gmaxwell, Luke-Jr: so wait
 16 2015-08-29 00:38:50 <Diablo-D3> with this proposal
 17 2015-08-29 00:39:16 <Diablo-D3> can the majority vote to make blocks smaller?
 18 2015-08-29 00:39:26 <Luke-Jr> Diablo-D3: I see no reason why not.
 19 2015-08-29 00:39:39 <Diablo-D3> YISSSSSS
 20 2015-08-29 00:39:39 <Luke-Jr> Diablo-D3: the majority can already force blocks to be smaller by ignoring bigger ones
 21 2015-08-29 00:39:49 <Diablo-D3> please tell me, btw
 22 2015-08-29 00:39:56 <Diablo-D3> the number field for this is the n in 2**n
 23 2015-08-29 00:40:03 <Luke-Jr> the use case for encoding this in the protocol itself, is so full nodes can enforce it reliably
 24 2015-08-29 00:40:04 <Diablo-D3> no weird ass size fuckery
 25 2015-08-29 00:40:28 <Luke-Jr> Diablo-D3: last I checked, BIP100 used an exact byte count in ASCII, which I think is lame
 26 2015-08-29 00:40:34 <Diablo-D3> yeah, fuck that
 27 2015-08-29 00:40:42 <Diablo-D3> I dont support bip100 until that bug is fixed
 28 2015-08-29 00:41:06 <Diablo-D3> single unsigned char, exponent of power of two sie.
 29 2015-08-29 00:41:08 <Diablo-D3> *size
 30 2015-08-29 00:41:18 <Diablo-D3> other than that
 31 2015-08-29 00:41:22 <Diablo-D3> I want to see smaller blocks
 32 2015-08-29 00:41:30 <Diablo-D3> let the largest pools try to crowd out tx spam
 33 2015-08-29 00:41:43 <Diablo-D3> and slowly unrestrict it as valid blocks move up
 34 2015-08-29 00:42:57 <Diablo-D3> also that means the maximum size shouldnt be 32mb
 35 2015-08-29 00:43:04 <Diablo-D3> should be 24.
 36 2015-08-29 00:43:13 <Diablo-D3> and maybe a minimum size of 20 or 16
 37 2015-08-29 00:43:24 <Luke-Jr> …
 38 2015-08-29 00:43:27 <Diablo-D3> wait 20 is a meg
 39 2015-08-29 00:43:31 <Diablo-D3> 16 then
 40 2015-08-29 00:43:59 <Diablo-D3> Luke-Jr: 2**24, 2**20, 2**16
 41 2015-08-29 00:44:11 <Diablo-D3> 16 megs, 1 meg, 64k in that order
 42 2015-08-29 00:44:24 <Arnavion> Is the current 1MB actually 1MB or 1MiB ?
 43 2015-08-29 00:45:40 <Diablo-D3> when I say MB
 44 2015-08-29 00:45:42 <Diablo-D3> I mean MiB
 45 2015-08-29 00:45:50 <Diablo-D3> these fake MB will never be real
 46 2015-08-29 00:45:56 <Arnavion> Yes, but I meant the current limit
 47 2015-08-29 00:45:57 <Diablo-D3> power of two is the only valid answer
 48 2015-08-29 00:46:01 <Diablo-D3> oh, think its mib
 49 2015-08-29 00:46:06 <Arnavion> Okay
 50 2015-08-29 01:10:43 <Luke-Jr> Diablo-D3: not precise enough IMO. no way to get ~350 k or ~178 k
 51 2015-08-29 01:27:07 <Diablo-D3> Luke-Jr: I dont think that level of precision is good
 52 2015-08-29 08:13:09 <wumpus> goddamnit, hadn't expected anything else than #5677 to turn into a fight about which async library to use months after I open it
 53 2015-08-29 08:14:04 <jonasschnelli> wumpus: Ha. Yeah. Let's just stick with libevent. libuv is not much of a difference imo.
 54 2015-08-29 08:14:36 <wumpus> nerds will be nerds :p
 55 2015-08-29 08:15:13 <wumpus> jonasschnelli: I'm not even opposed to using something else, but the 'actually...' timing is extremely awkward :)
 56 2015-08-29 08:15:54 <jonasschnelli> Right... the chances where there to switch library... during PoC phase. But now i really think this should go forward with the current setup-
 57 2015-08-29 08:16:49 <jonasschnelli> wumpus: apache bench tells me: libevent bases RPC: Time taken for tests:   2.440 seconds
 58 2015-08-29 08:17:08 <jonasschnelli> current master: Time taken for tests:   0.414 seconds
 59 2015-08-29 08:17:15 <jonasschnelli> (1000 requests)
 60 2015-08-29 08:17:21 <wumpus> let's just agree that switching from half-assed boost::asio usage is a good thing
 61 2015-08-29 08:17:38 <wumpus> jonasschnelli: what kind of requests?
 62 2015-08-29 08:17:42 <jonasschnelli> generate
 63 2015-08-29 08:17:50 <jonasschnelli> no
 64 2015-08-29 08:17:53 <jonasschnelli> getinfo ... sry
 65 2015-08-29 08:18:16 <wumpus> that sounds bad
 66 2015-08-29 08:18:34 <jonasschnelli> let me test with a libevent server build over gitian...
 67 2015-08-29 08:18:42 <jonasschnelli> maybe it has to do with --enable-debug or something like this
 68 2015-08-29 08:18:50 <jonasschnelli> (or local version of libevent)
 69 2015-08-29 08:19:37 <wumpus> with the time spent in getinfo itself, the HTTP server used shouldn't make much of a difference, let alone make it 6 times slower. I did some measurements in the beginning and it came out much closer...
 70 2015-08-29 08:20:01 <wumpus> but maybe the rebase broke something
 71 2015-08-29 08:20:43 <jonasschnelli> hmm.... it had probably do with my local build setup...
 72 2015-08-29 08:20:45 <jonasschnelli> just took https://builds.jonasschnelli.ch/pulls/5677/
 73 2015-08-29 08:20:57 <jonasschnelli> apox. same performance as current master
 74 2015-08-29 08:21:06 <wumpus> right, great
 75 2015-08-29 08:22:16 <jonasschnelli> https://gist.github.com/jonasschnelli/2b511c62c1d9ed901a9b
 76 2015-08-29 08:23:02 <jonasschnelli> reformatted
 77 2015-08-29 08:25:53 <jonasschnelli> 10000 requests with -c10 seems much faster (2x) with your libevent version
 78 2015-08-29 08:26:14 <wumpus> are you verifying that all the requests are succesful though?
 79 2015-08-29 08:26:22 <jonasschnelli> Failed requests:        0
 80 2015-08-29 08:26:32 <wumpus> ok :) thanks.
 81 2015-08-29 08:26:34 <jonasschnelli> (it would also report non 2xx http response status codes)
 82 2015-08-29 08:27:19 <jonasschnelli> "old" server: Time per request:       2.580 [ms] (mean, across all concurrent requests)
 83 2015-08-29 08:27:28 <jonasschnelli> new server: Time per request:       1.853 [ms] (mean, across all concurrent requests)
 84 2015-08-29 08:27:45 <jonasschnelli> But somehow performance doesn't matter that much IMO... as long as it's not much slower.
 85 2015-08-29 08:27:55 <jonasschnelli> i'm also going to analyze mem behavior.
 86 2015-08-29 08:44:31 <wumpus> i agree. Can always be optimized in any case. libevent's http server is not super-excellent, e.g. it doesn't in itself support multi-theaded usage hence the passing of requests between the dispatcher thread to the worker threads and back.
 87 2015-08-29 08:44:42 <wumpus> but it's better than what we have now
 88 2015-08-29 08:48:36 <wumpus> most important is stability, the current RPC server has some issues there, where lots of requests have been known to put it out of order, so keep attacking it
 89 2015-08-29 08:55:03 <avis> check this out
 90 2015-08-29 08:55:39 <avis> give me 8391 6240 and i know the next 4 digits are 7210 but the united states government won't let me get a job legally !
 91 2015-08-29 08:57:35 <Diablo-D3> ... yes, the government doesn't hire people who spout random numbers
 92 2015-08-29 08:57:41 <Diablo-D3> unless you're russian
 93 2015-08-29 08:59:03 <gmaxwell> "receive version message: /BitCoinJ:0.12SNAPSHOT/Satoshi:0.11.0/:"    can't say I didn't call that.
 94 2015-08-29 09:01:44 <jonasschnelli> maybe somebody plays around with bitcoinj's full node support?
 95 2015-08-29 09:01:59 <jonasschnelli> IIRC it's still in the sources..
 96 2015-08-29 09:03:29 <Luke-Jr> jonasschnelli: not relevant. it shouldn't claim to be Satoshi even then.
 97 2015-08-29 09:03:37 <jonasschnelli> wumpus: did you once test the RPC JSON batch option with the new RPC srever?
 98 2015-08-29 09:04:08 <Luke-Jr> unless *perhaps* if it's using libconsensus - but IMO that's a stretch
 99 2015-08-29 09:04:14 <jonasschnelli> Luke-Jr: right... it's probably just a guy playing with bitcoinj sources and the version command.
100 2015-08-29 09:04:57 <wumpus> jonasschnelli: yes, I did, but not after the rebase
101 2015-08-29 09:05:11 <jonasschnelli> wumpus: i'll try to run linearize.py
102 2015-08-29 09:06:11 <gmaxwell> well the "called this" was opposition to even having the field I pointed out that it would just naturally get filled with gibberish and you'd have the equivlent of billion things claiming to be "Mozilla"... lowers user privacy for very little diagnostic gain-- and all that even before some ill-advised implementation starts changing behavior based on what gets sent. :) Certantly not the most important
103 2015-08-29 09:06:17 <gmaxwell> thing in the world.
104 2015-08-29 09:06:37 <jonasschnelli> wumpus: batches are working correct.
105 2015-08-29 15:25:05 <dgenr8> gmaxwell: peers with that version string spurred #6588 (but not because of the version string)
106 2015-08-29 15:57:25 <amaclin> how many nSigOps are in tx: 6766e75d6166a0a14bd814921d0f903285e15779e648d7ec52a4f7c0868ec07d ?
107 2015-08-29 16:01:10 <Alina-malina> how correct would sound, "bitcoin protocol uses Proof of Work concept" or "bitcoin ptorocol uses Proof of Stake concept"? which one is correct?
108 2015-08-29 16:03:34 <sturles> Bitcoin use proof of work, but it is the blockchain which is secured by proof of work, not the protocol.
109 2015-08-29 17:08:26 <zipmaster> Hey Everyone. I just submitted a research paper on Mining Advantages in Uncapped Block Size fee markets
110 2015-08-29 17:08:27 <zipmaster> https://www.reddit.com/r/Bitcoin/comments/3iuz3r/on_the_nature_of_miner_advantages_in_uncapped/
111 2015-08-29 17:08:37 <zipmaster> I look forward to comments
112 2015-08-29 17:11:04 <CohibAA> [removed]
113 2015-08-29 17:11:18 <CohibAA> ?
114 2015-08-29 17:11:42 <zipmaster> sorry
115 2015-08-29 17:11:48 <zipmaster> I guess urls get scrubbed
116 2015-08-29 17:12:10 <zipmaster> r/Bitcoin/comments/3iuz3r/on_the_nature_of_miner_advantages_in_uncapped/
117 2015-08-29 17:17:52 <teward> or more a case it was moderated, zipmaster
118 2015-08-29 17:17:53 <teward> and removed.
119 2015-08-29 17:18:12 <zipmaster> Did you guys get it the second time around?
120 2015-08-29 17:18:43 <teward> zipmaster: it says 'removed' on that page - meaning it was likely moderated away
121 2015-08-29 17:18:47 <teward> so no, it didn't work
122 2015-08-29 17:19:02 <zipmaster> As in... it got removed from Reddit?
123 2015-08-29 17:19:15 <zipmaster> scribd.com/doc/276849939/On-the-Nature-of-Miner-Advantages-in-Uncapped-Block-Size-Fee-Markets
124 2015-08-29 17:19:18 <zipmaster> ok
125 2015-08-29 17:19:22 <zipmaster> this must work then
126 2015-08-29 17:21:30 <zipmaster> yes/no?
127 2015-08-29 17:21:48 <CohibAA> yes
128 2015-08-29 17:22:26 <zipmaster> thanks!
129 2015-08-29 17:40:54 <Ahmed90> Hello devs!, am working on a new web project involving a BTC wallet connected with json rpc.. how can i secure that wallet ?? incase of breach for example ?
130 2015-08-29 17:41:28 <Ahmed90> can i restrect the rpc calls to get info only no auto transaction etc.. ?
131 2015-08-29 17:43:49 <Ahmed90> or should i just build a middleware to handel the wallet ?
132 2015-08-29 18:56:38 <drazisil> Ahmed90: that's almost too broad a question for this channel. you are saying the wallet will have an rpc interface to control it, or it will talk to the node/server using rpc?
133 2015-08-29 18:57:54 <jonasschnelli> Ahmed90: don't expose bitcoind rpc server to the public!
134 2015-08-29 19:17:18 <harding> Are there any plans (or half-formed intentions) to remove SSL support from the RPC interface?
135 2015-08-29 19:18:10 <Lightsword> harding, what would be the point of that?
136 2015-08-29 19:20:25 <jonasschnelli> harding: SSL will be removed very likely.
137 2015-08-29 19:20:48 <jonasschnelli> PR: https://github.com/bitcoin/bitcoin/pull/5677 has a good chance to get merged
138 2015-08-29 19:20:54 <jonasschnelli> and it would remove SSL.
139 2015-08-29 19:20:58 <jonasschnelli> Which is good IMO.
140 2015-08-29 19:21:20 <harding> jonasschnelli: I thought I had heard about that---thanks for the link!
141 2015-08-29 19:21:56 <jonasschnelli> bitcoind rpc server is not meant to expose to public.
142 2015-08-29 19:22:05 <jonasschnelli> It's not hardened enought.
143 2015-08-29 19:22:33 <jonasschnelli> If someone needs to extend it, one should consider creating a reverse proxy with apache, etc.
144 2015-08-29 19:22:40 <jonasschnelli> s/extend/expose
145 2015-08-29 19:23:41 <Lightsword> would it make sense to preserver to prevent ISP monitoring?
146 2015-08-29 19:23:44 <Lightsword> preserve*
147 2015-08-29 19:24:09 <Lightsword> since any internet link can’t be fully trusted
148 2015-08-29 19:24:36 <jonasschnelli> i don't understand that...
149 2015-08-29 19:24:54 <Lightsword> there was a BGP based attack on miners for instance
150 2015-08-29 19:25:40 <Lightsword> http://www.secureworks.com/cyber-threat-intelligence/threats/bgp-hijacking-for-cryptocurrency-profit/
151 2015-08-29 19:26:43 <jonasschnelli> Hmm... can't see the link to RPCs/SSL.
152 2015-08-29 19:27:08 <Lightsword> janasschnelli, so without ssl how would RPC authenticate?
153 2015-08-29 19:27:31 <Lightsword> the BGP attack shows that IP restrictions alone are not really enough
154 2015-08-29 19:27:48 <jonasschnelli> The RPC auth. is http base auth... so don't use it for the mass. :)
155 2015-08-29 19:28:03 <Lightsword> the mass?
156 2015-08-29 19:28:31 <jonasschnelli> You should write a proper frontend, create some auth, and from the same host (or trusted net) you connect to the bitcoind RPC server over 127.0.0.1 (or trusted IP)
157 2015-08-29 19:28:51 <jonasschnelli> The bitcoind rpc server should not be exposed to the internet in any form.
158 2015-08-29 19:29:00 <Lightsword> what I’m saying is that trusted IP’s are often not really as trusted as one may think
159 2015-08-29 19:29:32 <jonasschnelli> If you don't trust localhost, then you don't trust bitcoind.
160 2015-08-29 19:29:43 <jonasschnelli> If you don't trust a "trusted ip", then add a stunnel
161 2015-08-29 19:29:44 <Lightsword> localhost is about the only one you can trust or local network
162 2015-08-29 19:30:15 <Lightsword> I’m mainly talking about infrastructure with backend links across multiple datacenters
163 2015-08-29 19:30:44 <jonasschnelli> If you only trust localhost, install apache (or similar), implement a state of the art authentication, reverse proxy some calls to localhost/bitcoind-rpc
164 2015-08-29 19:31:19 <jonasschnelli> But the bitcoind's SSL feature for RPC drives people into the direction of exposing a non hardened http-server to the public
165 2015-08-29 19:31:38 <Lightsword> ah, ok so just doing a nginx reverse proxy in front of it should be enough?
166 2015-08-29 19:32:21 <Lightsword> to prevent a MITM attack
167 2015-08-29 19:32:56 <jouke> Lightsword: Or if you only want to use it internally you could use tunnels or vpns
168 2015-08-29 19:33:44 <Lightsword> ok, right now I’m able to just use localhost but I may have to eventually spit bitcoind off
169 2015-08-29 19:33:54 <Lightsword> on some of my servers
170 2015-08-29 19:35:06 <sss> hi
171 2015-08-29 19:35:37 <sss> hi
172 2015-08-29 19:39:42 <gmaxwell> harding: We'll recommend using stunnel (or other) as a front end. This has a nice advantage of getting the potentally vulnerable SSL stuff thats exposed to the internet into another process.
173 2015-08-29 19:40:05 <gmaxwell> harding: so, for example, the next "heartbleed" has no chance of leaking private key data.
174 2015-08-29 19:41:29 <gmaxwell> Lightsword: no one has suggested that the IP restrictions are a replacement, rather we've recommended people not expose the RPC to the outside world even with IP restrictions in the past; because there is a tremendous and underevaluated (and previously vulnerable) attack surface there.
175 2015-08-29 19:43:13 <Lightsword> gmaxwell, that makes sense, I’ve been to paranoid I guess to even open up RPC beyond localhost at all but I didn’t know the proper way to handle remote connections
176 2015-08-29 19:43:17 <Lightsword> too*
177 2015-08-29 21:56:06 <kanzure> why was a 60 MB blockchain taking hours to verify in 2010? https://bitcointalk.org/index.php?topic=1980.0
178 2015-08-29 21:57:42 <Diablo-D3> https://news.ycombinator.com/item?id=10140981
179 2015-08-29 21:57:46 <Diablo-D3> hit the front page, lol
180 2015-08-29 22:00:08 <kanzure> also, what's the name of the proposal regarding something like locktime but not locktime for "don't include the transaction before/after x number of blocks from y"? was this OP_CSV / checksequenceverify?
181 2015-08-29 22:12:17 <alpalp> kanzure: wasn't there not a lot of optimization for validation of blocks done then?
182 2015-08-29 22:25:05 <kanzure> alpalp: right, yes, but i'm presently blanking on which optimizations in particular :-)
183 2015-08-29 22:29:02 <harding> gmaxwell: thanks.
184 2015-08-29 22:38:12 <gmaxwell> kanzure: because pieter hadn't made it faster yet. there have been litterally hundreds of things _drastically_ improved.
185 2015-08-29 22:49:04 <phantomcircuit> Diablo-D3, yeah i predicted that a while ago
186 2015-08-29 22:49:24 <phantomcircuit> part of what has kept bitcoin functional and stable is that all of the competent people want it to succeed
187 2015-08-29 22:49:43 <phantomcircuit> when you split that group of people and then have them start fighting... well things can get nasty
188 2015-08-29 22:54:20 <midnightmagic> Diablo-D3: don't aggrandize the veiled threats, please.
189 2015-08-29 23:39:49 <btcdrak> kanzure:: BIP68 and BIP112 (chesequenceverify)
190 2015-08-29 23:48:53 <alpalp> phantomcircuit: what competent people are split? they all seem to be on one side :)
191 2015-08-29 23:50:38 <phantomcircuit> alpalp, jeff is competent when he's paying attention
192 2015-08-29 23:50:55 <phantomcircuit> he's not at all malicious though so this may be a very one sided fight...
193 2015-08-29 23:51:17 <alpalp> hes been straddling the fence though