1 2013-12-27 01:14:09 <deanclkclk> maaku: u working on a exchange?
2 2013-12-27 01:46:09 <maaku> deanclkclk: yes
3 2013-12-27 04:57:08 <mack25> hey folks, got a question. what is causing this error when trying to build bitcoin-qt.pro using QT Creator: Makefile:750: warning: overriding commands for target `build/moc_macnotificationhandler.cpp'
4 2013-12-27 05:00:34 <maaku> mack25: that's not an error. is there any other output?
5 2013-12-27 05:02:42 <mack25> one sec
6 2013-12-27 05:02:48 <mack25> letting it build again
7 2013-12-27 05:15:20 <mack25> ld: library not found for -lcrt0.o
8 2013-12-27 05:15:25 <mack25> looks like that's the issue now
9 2013-12-27 05:16:29 <mack25> was reading that you can just tell it not to use that
10 2013-12-27 05:23:07 <mack25> maaku know of anything I can do?
11 2013-12-27 05:23:15 <mack25> should i download a library?
12 2013-12-27 05:23:20 <mack25> or try to make it not recognize that one
13 2013-12-27 05:42:28 <deanclkclk> good luck with that maaku
14 2013-12-27 05:42:33 <deanclkclk> I'm working on one myself
15 2013-12-27 05:57:41 <wallet42> any experts in manual crafting and signing transactions?
16 2013-12-27 05:58:21 <wallet42> i want to redeem a multisig transaction that was paid to a script hash
17 2013-12-27 05:59:09 <wallet42> i can craft anything but i think i mess somewhere the signaturehash
18 2013-12-27 05:59:15 <wallet42> mess up
19 2013-12-27 05:59:58 <wallet42> my crafting is based on http://bitcoin.stackexchange.com/questions/3374/how-to-redeem-a-basic-tx
20 2013-12-27 06:01:00 <wallet42> if i use bitcoind signrawtransaction everything works fine, but my own python code doest seem to sign the right unsigned tx hash
21 2013-12-27 06:02:33 <wallet42> can i see somehow what is the correct unsigned tx id that is bitcoind signing?
22 2013-12-27 06:08:47 <andytoshi> wallet42: the signed tx is a copy of the original, but with every scriptsig except the current one removed (len = 0) ... to the best of my knowledge, there is no hook in the code to see the signed transaction, but it does exist prior to signing, so you should be able to output it
23 2013-12-27 06:09:16 <andytoshi> by just copying the print-serialization code from rpc getrawtransaction
24 2013-12-27 06:22:08 <joinjackbob> http://pastebin.com/B0m4kpRv - been trying to find some answers to this problem, though none so far. I crashed the daemon, and now I cannot get it going again. Could anyone point me in the right direction
25 2013-12-27 06:23:51 <maaku> mack25: sounds like a broken toolchain
26 2013-12-27 06:23:54 <joinjackbob> it's for dogecoin, though as far as I understand, all the coins are built from bitcoin
27 2013-12-27 06:24:04 <maaku> crt0 is the C run time library
28 2013-12-27 06:25:12 <maaku> joinjackbob: ask #dogecoin
29 2013-12-27 06:25:38 <joinjackbob> it's a zoo in there, hard to get a straight answer
30 2013-12-27 06:25:47 <rdn> joinjackbob, corrupt db
31 2013-12-27 06:26:04 <joinjackbob> I figure it's a matter of removing a file
32 2013-12-27 06:26:05 <warren> joinjackbob: what do you expect when you are relying on software that is supposed to be a joke?
33 2013-12-27 06:27:56 <joinjackbob> what I mean is, remove the corrupt database and restart it, rebuild a fresh one
34 2013-12-27 06:34:26 <joinjackbob> rdn: well that's a huge help, I'm at least on the right path now
35 2013-12-27 06:41:59 <rdn> warren, dogecoin is a bitcoin-qt skin, users have had this same error with bitcoin-qt and litecoin-qt
36 2013-12-27 06:42:39 <warren> rdn: dogecoin is based on an ancient version of bitcoin
37 2013-12-27 06:43:10 <warren> rdn: aside from that, people here just aren't interested in helping the thousands of scam copies
38 2013-12-27 06:49:00 <joinjackbob> rdn: thanks for the help, found what I was looking for
39 2013-12-27 06:50:18 <joinjackbob> warren: I see your point
40 2013-12-27 07:01:15 <joinjackbob> not sure if I'd call them scams though
41 2013-12-27 07:01:24 <joinjackbob> outright scams
42 2013-12-27 07:02:10 <joinjackbob> Anyway, all the best
43 2013-12-27 07:07:19 <sipa> wallet42: current git head has a wrapper CTransactionSignatureSerializer which can be used to get the modified version of a transaction, as is used for signing
44 2013-12-27 07:55:39 <odie5533> How can I monitor an address to see when it receives money? Do I need to add it to bitcoind?
45 2013-12-27 09:53:45 <CodeShark> pinging gmaxwell
46 2013-12-27 10:57:04 <arioBarzan> anyone has any opinion on this type of scriptPubKey?
47 2013-12-27 10:57:07 <arioBarzan> OP_DUP OP_HASH160 <pubKey1Hash> OP_EQUALVERIFY OP_2 OP_SWAP <pubKey2> OP_2 OP_CHECKMULTISIG
48 2013-12-27 10:57:43 <arioBarzan> scriptSig would be
49 2013-12-27 10:57:44 <arioBarzan> OP_0 <sig> <pubKey1>
50 2013-12-27 11:39:16 <CodeShark> arioBarzan: to be more precise, scriptSig is OP_0 <sig1> <sig2> <pubKey1>
51 2013-12-27 11:44:49 <arioBarzan> CodeShark: right
52 2013-12-27 11:45:40 <CodeShark> well, my opinion is that things would be a hell of a lot easier if everything were p2sh :)
53 2013-12-27 11:47:08 <CodeShark> as curious as this example might be, it really is up to the recipient to construct a script and give a payment output to the sender, IMO
54 2013-12-27 11:47:42 <arioBarzan> easier, but not necessarily more secure I guess. That scriptPubKey seams more secure to me though.
55 2013-12-27 11:47:42 <CodeShark> trying to think of a use case where this wouldn't be so
56 2013-12-27 11:48:35 <CodeShark> scriptPubKey does have more entropy, but finding a redeemable ripemd160 collision seems computationally infeasible
57 2013-12-27 11:51:05 <arioBarzan> is that scriptPubKey accepted by current rules of reference implementation?
58 2013-12-27 11:51:37 <CodeShark> the script would probably be considered valid if included in a block, but the reference implementation won't relay such a transaction unless it's in a block
59 2013-12-27 11:52:09 <CodeShark> to crack p2sh, you'd have to find a way to enumerate redeemable scripts (perhaps using a 1-of-2 multisig and using the second pubkey as a nonce)
60 2013-12-27 11:52:47 <CodeShark> we're still talking a preimage attack on ripemd160
61 2013-12-27 11:53:16 <CodeShark> essentially equivalent to finding a vanity address that matches exactly, all characters up to the checksum
62 2013-12-27 11:54:05 <arioBarzan> CodeShark: thanks
63 2013-12-27 11:58:13 <CodeShark> I've been pondering a bit the possibility of using a pow function that requires serial processing for finding a valid block but affords parallel processing for verification
64 2013-12-27 11:58:29 <CodeShark> for instance, chained encryption using a weak key
65 2013-12-27 11:59:52 <CodeShark> then difficulty could be set by not only increasing the key size but also the chain length
66 2013-12-27 12:01:22 <CodeShark> rising difficulty would increase the cost of verification, but not nearly as much as it would increase the cost of mining
67 2013-12-27 12:02:09 <CodeShark> specifically, mining would benefit little from massively parallel circuits
68 2013-12-27 12:04:20 <CodeShark> verification, on the other hand, could be distributed across the network somehow
69 2013-12-27 12:51:32 <abishek> is there a way to query all the transactions on the blockchain?
70 2013-12-27 13:01:06 <sipa> abishek: indexed by what?
71 2013-12-27 13:07:10 <abishek> sipa, i need to filter all the transactions that belong to a particular country. is it possible...
72 2013-12-27 13:08:00 <wumpus> no, that's not possible
73 2013-12-27 13:09:17 <abishek> ok. does a transaction contain information about which IP address did it originate from?
74 2013-12-27 13:09:22 <wumpus> no
75 2013-12-27 13:20:56 <SomeoneWeird> abishek, that's the whole "anonymous" part at work :)
76 2013-12-27 13:22:14 <abishek> we have had recent events in our country about making bitcoin transactions close to being illegal, so am trying to figure out how to help the govt. There are questions about using Bitcoins for money laundering and scamming
77 2013-12-27 13:23:17 <Belxjander> abishek: then focus on it as a money and try to have it covered by existing monetary law with the same problems appearing in both
78 2013-12-27 13:23:26 <Belxjander> bitcoin is easier to track since the blockchain is public
79 2013-12-27 13:23:43 <Belxjander> you just have to confirm an address from a specific private key really
80 2013-12-27 13:26:44 <abishek> being public is fine, how can one ensure that it is not being used for money laundering?
81 2013-12-27 13:27:45 <sipa> how do you guarantee cash is not used for money laundering? by having a good bookkeeping that explains where all money comes from
82 2013-12-27 13:27:49 <sipa> same thing
83 2013-12-27 14:58:32 <deanclkclk> folks question
84 2013-12-27 14:58:34 <deanclkclk> getaddressesbyaccount
85 2013-12-27 14:58:37 <deanclkclk> what is an account?
86 2013-12-27 14:58:50 <deanclkclk> I thought most things in bitcoind works with addresses
87 2013-12-27 15:01:00 <pigeons> deanclkclk: account is a local bucket of inputs the client software keeps track of, unrelated to the bitcoin network
88 2013-12-27 15:02:41 <sipa> deanclkclk: forget about accounts
89 2013-12-27 15:04:19 <deanclkclk> would it be the same as "label" whenever I'm creating my Bitcoin receiving address sipa ?
90 2013-12-27 15:04:32 <sipa> yes, an unfortunate design choice
91 2013-12-27 15:04:55 <sipa> when you receive money via an address that has label X, account X is credited with that amount
92 2013-12-27 15:05:09 <sipa> when sending money, it's always subtracted from the "" account, unless you use sendfrom
93 2013-12-27 15:05:17 <deanclkclk> cool
94 2013-12-27 15:05:20 <deanclkclk> thx sipa
95 2013-12-27 15:05:27 <sipa> note that this has _nothing_ to do with the actual coins assigned to an address
96 2013-12-27 15:05:50 <sipa> when sending money, all coins - receive any all addresses - are always used to construct the inputs
97 2013-12-27 15:06:08 <wumpus> yes, forget about accounts, the account implementation in bitcoind sucks
98 2013-12-27 15:06:55 <sipa> it's mostly unintuitive and interacts badly with backups
99 2013-12-27 15:07:06 <wumpus> if you want to do anything serious like run a multi-user site, roll your own
100 2013-12-27 15:07:10 <sipa> yeah
101 2013-12-27 15:09:07 <lianj> anyone at 30c3?
102 2013-12-27 15:11:04 <wallet42> sipa: can you help me with a signing issue? i d like to sign a redeem p2h transaction with multisig. i d like to construct the rawtx and do the signing w/o bitcoind (in python). here is the accomplished mission w/ bitcoind http://pastebin.com/t1e41WbA
103 2013-12-27 15:11:28 <wallet42> lianj: im in hall 2
104 2013-12-27 15:16:22 <sturles> lianj: Yes
105 2013-12-27 15:17:31 <wallet42> sipa: i construct a unsignedTx with the original p2h as vin scriptSig: http://pastebin.com/8s7RijsS
106 2013-12-27 15:17:38 <mack25> morning folks
107 2013-12-27 15:17:40 <sipa> wallet42: sorry, no time
108 2013-12-27 15:17:42 <mack25> how yall doin?
109 2013-12-27 15:50:13 <tdignan> How do I run bitcoind in the foreground?
110 2013-12-27 15:53:39 <tdignan> nm, I had daemon=1, needed to set it back to 0
111 2013-12-27 16:13:25 <lianj> sturles: nice, lets meet up at some point ;)
112 2013-12-27 16:26:54 <sturles> I'm going for a coffee after this talk. There are some coffee hackers at the top floor, iirc.
113 2013-12-27 16:40:50 <TD> good evening
114 2013-12-27 16:56:44 <TD> sipa: thanks for the doc update
115 2013-12-27 16:56:48 <TD> ACTION is working on a new fee estimator
116 2013-12-27 17:12:28 <sipa> TD: i'm working on bip37-based block propagation
117 2013-12-27 17:12:49 <TD> bip37 is ... bloom filtering
118 2013-12-27 17:12:51 <TD> ?
119 2013-12-27 17:13:07 <sipa> yes
120 2013-12-27 17:13:12 <TD> ACTION can never remember :)
121 2013-12-27 17:13:17 <TD> that's cool. though what happened to headers first?
122 2013-12-27 17:14:15 <edcba> i guess it's second to sipa
123 2013-12-27 17:14:31 <sipa> both depend on that recent pullreq, but bip37 blocks are easy
124 2013-12-27 17:14:57 <sipa> i still hope to have an up to date working headersfirst soon
125 2013-12-27 17:15:46 <TD> ok
126 2013-12-27 17:15:48 <TD> neat
127 2013-12-27 18:19:37 <rfish> anyone understand zerocoin here and is willing to explain it?
128 2013-12-27 18:27:53 <BlueMatt> sipa: bip37 doesnt really make sense for block download, no? why do you want the filtered merkle tree instead of just the hash list (since you know you want all txn anyway)
129 2013-12-27 18:29:25 <TD> BlueMatt: i think he means propagation using full match filters
130 2013-12-27 18:29:52 <BlueMatt> yea, but it seems like the filtered merkle tree doesnt make sense for full-match filters?
131 2013-12-27 18:30:08 <BlueMatt> you just have extra overhead to build the tree when you dont want it anyway...
132 2013-12-27 18:32:40 <TD> you're the one who added that optimisation :)
133 2013-12-27 18:32:56 <TD> it's just a way to re-use the same codepaths that is convenient (sending the missing txns and things)
134 2013-12-27 18:36:37 <BlueMatt> no, sipa did
135 2013-12-27 18:36:45 <BlueMatt> (but was right to, for spv nodes)
136 2013-12-27 18:36:50 <BlueMatt> yea
137 2013-12-27 18:37:06 <BlueMatt> its probably worth it, I think the overhead is minimal, its just strange
138 2013-12-27 18:37:06 <TD> spv nodes never do full match bloom filters. i thought that was you. well never mind
139 2013-12-27 18:37:09 <TD> not important
140 2013-12-27 18:37:24 <BlueMatt> oh, the full-match thing was me, yea
141 2013-12-27 18:37:41 <BlueMatt> I think I might be the one who suggested bip37 full-downloaded first
142 2013-12-27 18:38:06 <wallet42> anybody at 30C3?
143 2013-12-27 18:38:12 <TD> wallet42: goonie is, i think
144 2013-12-27 18:38:20 <BlueMatt> wallet42: read scrollback ;)
145 2013-12-27 18:38:20 <TD> wallet42: author of the android bitcoin wallet
146 2013-12-27 18:39:11 <lianj> TD: wallet42: yea, andreas is here
147 2013-12-27 18:39:37 <wallet42> how can i reach him easily?
148 2013-12-27 18:40:02 <lianj> privmsg goonie on irc?
149 2013-12-27 18:40:16 <TD> wallet42: not sure if he is online at the moment
150 2013-12-27 18:40:24 <wallet42> i guess i mail him
151 2013-12-27 18:40:29 <wallet42> thx
152 2013-12-27 18:40:36 <lianj> once you see him, he isn't easily overlooked
153 2013-12-27 18:40:48 <lianj> wallet42: where are you atm?
154 2013-12-27 18:45:37 <wallet42> yes
155 2013-12-27 18:45:49 <wallet42> greenwald is having the keynote right this moment
156 2013-12-27 18:47:42 <wallet42> http://streaming.media.ccc.de/saal1/native/lq/
157 2013-12-27 18:51:47 <lianj> wallet42: the tactical thing todo is find a nice free couch and watch the keynote stream from there while everyone is sitting ontop of eachothers in the keynote room ;)
158 2013-12-27 18:52:59 <phantomcircuit> lianj, haha
159 2013-12-27 18:56:35 <wallet42> lianj: youre here too?
160 2013-12-27 19:07:09 <lianj> wallet42 should really get an irc bouncer...
161 2013-12-27 19:14:12 <sugarpuff> any core devs here?
162 2013-12-27 19:14:44 <sugarpuff> (esp. sec related?)
163 2013-12-27 19:14:50 <darsie> How reliably does vanitygen produce correct addresses/private keys? I mean, it's quite trivial, so should be easy to get right, IMO.
164 2013-12-27 19:18:48 <gmaxwell> sugarpuff: yes? If you have something private you should potentially disclose it over gpg encrypted email anot not irc
165 2013-12-27 19:19:08 <TD> or cryptocat!
166 2013-12-27 19:19:16 <sugarpuff> gmaxwell: actually, just sent you a reply (via email)
167 2013-12-27 19:19:31 <sugarpuff> nice to see you here too :)
168 2013-12-27 19:23:13 <gmaxwell> sugarpuff: I recieved your email, but I don't see what you were sending that to bitcoin security. Although none of your ycombinator links work.
169 2013-12-27 19:23:27 <sugarpuff> wtf
170 2013-12-27 19:24:04 <sugarpuff> gmaxwell: what do you mean they don't work?
171 2013-12-27 19:25:07 <gmaxwell> ah, they were garbled by mime encoding, I've got them now.
172 2013-12-27 19:25:20 <sugarpuff> k
173 2013-12-27 19:28:13 <gmaxwell> There was nothing that you sent which hasn't been sent publically. You should post this to bitcoin development, not bitcoin-security, but you'll likely be point to the many threads where this subject has been discussed over and over again. Including that all "fixes" have serious, difficult to analyze side effects, which may be far worse than the symptoms.
174 2013-12-27 19:28:46 <gmaxwell> er likely be pointed.
175 2013-12-27 19:28:57 <AriseChikun> anyone had any success in installing gitian on ubuntu in vmware to compile wallets? having loads of errors here
176 2013-12-27 19:28:59 <sugarpuff> gmaxwell: sure, i'll send it there then. ignoring the problem doesn't seem to be the right answer though. do you think it is?
177 2013-12-27 19:29:44 <BlueMatt> sugarpuff: you should probably provide context here...
178 2013-12-27 19:29:52 <gmaxwell> hysteria about "selfish mining"
179 2013-12-27 19:29:56 <BlueMatt> ahhh
180 2013-12-27 19:30:07 <BlueMatt> should've guessed
181 2013-12-27 19:30:15 <sugarpuff> BlueMatt: https://news.ycombinator.com/item?id=6969486
182 2013-12-27 19:30:55 <sugarpuff> gmaxwell: please don't dismiss this problem with the word "hysteria" unless you've got a solid reason for doing so
183 2013-12-27 19:31:00 <gmaxwell> sugarpuff: It may well be, in fact. Any "selfish mining" is trivially detectable (causes large wads of orphan blocks), and it's not currently happening. The many of "fix it fast" solutions have had moderately severe side effects, some arguably far worse than the problem.
184 2013-12-27 19:31:11 <BlueMatt> sugarpuff: some initial work has been engaged to address some of the issue here, namely work to decrease block propagation times among miners so you cant gain an advantage (which is required to pull the attack off)
185 2013-12-27 19:31:23 <BlueMatt> significantly more work needs done, but it was an initial step to avoid the hysteria
186 2013-12-27 19:31:23 <gmaxwell> sugarpuff: I'm not dismissing any problem with hysteria. I'm dismissing your email as hysteria.
187 2013-12-27 19:31:52 <BlueMatt> to fix it long-term requires significant study and simulation
188 2013-12-27 19:31:56 <sugarpuff> gmaxwell: w/e, i read it as the same thing, since you haven't made much of a distinction. is your point that it doesn't need to be fixed fast?
189 2013-12-27 19:31:57 <gmaxwell> Sorry, don't send me vague private encrypted emails, wasting my time with "you must addresses this fast!!" crap. Thats hysteria.
190 2013-12-27 19:32:23 <TD> yes, it doesn't need to be fixed fast
191 2013-12-27 19:32:33 <TD> as evidenced by the fact that bitcoin is still here and this was being discussed months ago
192 2013-12-27 19:32:35 <sugarpuff> k, do the bitcoin devs have some sort of official timeline for fixing it then?
193 2013-12-27 19:33:01 <sugarpuff> the fact that bitcoin is still here could just mean that the malicious pool hasn't chosen yet to make itself known
194 2013-12-27 19:33:05 <Luke-Jr> sugarpuff: yes
195 2013-12-27 19:33:11 <gmaxwell> sugarpuff: It objectively doesn't need to be fixed fast, as no one is doing anything with it, and it's not even clear if its pratically exploitable at all in networks with latency and difficulty sybiling.
196 2013-12-27 19:33:19 <Luke-Jr> sugarpuff: no, it is clear that there is no such pool
197 2013-12-27 19:33:36 <Luke-Jr> gmaxwell: well, GBT fixes it more or less
198 2013-12-27 19:33:41 <sugarpuff> Luke-Jr: ok, where is the proof for this?
199 2013-12-27 19:34:01 <gmaxwell> sugarpuff: ther proof is that there are no longer than expected runs of orphans.
200 2013-12-27 19:34:05 <Luke-Jr> ^
201 2013-12-27 19:34:26 <sugarpuff> i'm curious, what software is being used to check this?
202 2013-12-27 19:34:33 <sugarpuff> is there a link somewhere?
203 2013-12-27 19:34:57 <gmaxwell> sugarpuff: bitcoind logs reorg events.
204 2013-12-27 19:35:21 <TD> https://blockchain.info/charts/n-orphaned-blocks
205 2013-12-27 19:35:33 <TD> observe the fact that orphan rate is low and stable
206 2013-12-27 19:35:59 <sugarpuff> except for march 30th
207 2013-12-27 19:36:12 <gmaxwell> sugarpuff: yes, and we know what happened there, it's unrelated.
208 2013-12-27 19:36:12 <sugarpuff> approx. march 30th
209 2013-12-27 19:36:13 <phantomcircuit> gmaxwell, the solution proposed by the original paper ironically made a sybil attack much easier to execute in practice
210 2013-12-27 19:36:14 <Luke-Jr> sugarpuff: it'd be pretty obvious to all the miners
211 2013-12-27 19:36:27 <Luke-Jr> sugarpuff: wouldn't you notice if you suddenly started losing money?
212 2013-12-27 19:36:32 <phantomcircuit> ie their solution took the problem from theoretical and made it possible
213 2013-12-27 19:36:39 <phantomcircuit> got a good laugh at that one
214 2013-12-27 19:36:48 <sugarpuff> i'm not support that solution
215 2013-12-27 19:36:51 <sugarpuff> *supporting
216 2013-12-27 19:37:05 <gmaxwell> would be nice if someone did a chart of 2-block-orphans which would nearly be zero at all times,â 2 and three deep ones is a much stronger signal for misbehavior.
217 2013-12-27 19:37:43 <TD> there's no simple "fix", but the fix is generally things like reducing latency, decreasing centralisations of miner power, etc
218 2013-12-27 19:37:52 <TD> so lots of hard work on optimising things
219 2013-12-27 19:38:16 <gmaxwell> If your concern is related to mining pools doing this without the support of hashers, then luke is correctâ gbt is a complete fix for that.
220 2013-12-27 19:38:23 <sugarpuff> TD: have a look at the discussion on HN and Stephen's suggestion: https://bitcointalk.org/index.php?topic=324413.msg3478147#msg3478147
221 2013-12-27 19:38:36 <phantomcircuit> certainly for pools the biggest step is having the mining clients detect malicious pool behavior and warn the owner of the hw
222 2013-12-27 19:38:54 <phantomcircuit> Luke-Jr, iirc bfgminer will warn the user if they're mining on old blocks right?
223 2013-12-27 19:39:04 <Luke-Jr> phantomcircuit: yes, and will submit found blocks to local bitcoind
224 2013-12-27 19:39:13 <phantomcircuit> right
225 2013-12-27 19:39:22 <phantomcircuit> that should prevent selfish mining almost entirely
226 2013-12-27 19:39:32 <phantomcircuit> now we just have to get people to actually do that :)
227 2013-12-27 19:39:58 <TD> someone needs to give the website a lot of love, make a miner section
228 2013-12-27 19:40:34 <TD> right now how to become a miner is not really documented, so no surprise people end up not following best practices
229 2013-12-27 19:40:53 <BlueMatt> someone needs to advertise the shit out of the relay network so that miners are all on even footing latency-wise and essentially cant possibly get any advantage
230 2013-12-27 19:41:24 <gmaxwell> a really substantial portion of the network's hashpower is now consoidated in cloud facilities where the 'owners' don't really have the freedom to engage in better practices. ::shrugs::
231 2013-12-27 19:41:25 <TD> "someone" needs to do lots of things
232 2013-12-27 19:41:43 <gmaxwell> I could create a mining section ... I never thought we wanted them.
233 2013-12-27 19:41:54 <TD> why not? the website should be much bigger
234 2013-12-27 19:42:01 <BlueMatt> gmaxwell: do core devs reach out to those guys to discuss their policies?
235 2013-12-27 19:42:16 <TD> i'd like to see sections for how to be a miner, how to be a merchant, etc
236 2013-12-27 19:42:22 <BlueMatt> ACTION did recently re: relay network, but still
237 2013-12-27 19:42:24 <sugarpuff> i'm unclear on the GBT comments, gmaxwell, can you link me to something about how it fixes the problem?
238 2013-12-27 19:42:47 <edcba> TD: bitcoin adventure ! choose your character !
239 2013-12-27 19:43:00 <TD> :)
240 2013-12-27 19:43:01 <sugarpuff> (or anyone else who knows what he's talking about)
241 2013-12-27 19:43:22 <edcba> buy/sell arms & drugs with bitcoin !
242 2013-12-27 19:43:24 <edcba> no wait...
243 2013-12-27 19:44:06 <gmaxwell> sugarpuff: You just run BFGminer like bfgminer [...put your real GBT-based pools first...] -o http://localhost:8332#allblocks -u username -p password
244 2013-12-27 19:44:13 <gmaxwell> and it will also submit any blocks it finds locally
245 2013-12-27 19:44:23 <gmaxwell> so a pool could not delay their announcement without your cooperation.
246 2013-12-27 19:45:06 <Luke-Jr> BlueMatt: I do pretty often, but they're a pain generally
247 2013-12-27 19:45:19 <Luke-Jr> BlueMatt: the number of miners who actually care to do their job on the network are a small %
248 2013-12-27 19:45:22 <sugarpuff> gmaxwell: still not clear: you wouldn't find real blocks all by yourself, isn't that the point of a pool?
249 2013-12-27 19:45:43 <Luke-Jr> sugarpuff: someone does
250 2013-12-27 19:46:27 <TD> Luke-Jr: because there's not much incentive for them to do so. if we started directing miners from bitcoin.org to particular "best" pools
251 2013-12-27 19:46:41 <Luke-Jr> TD: that would be fairly political :<
252 2013-12-27 19:46:45 <gmaxwell> sugarpuff: of course you do, thats how it works.
253 2013-12-27 19:47:03 <andytoshi> BlueMatt: i have personally witnessed gmaxwell talk to several miners on irc
254 2013-12-27 19:47:11 <andytoshi> istm they are beligerant and don't care about best practices
255 2013-12-27 19:47:31 <TD> Luke-Jr: we managed it for wallets
256 2013-12-27 19:47:36 <Luke-Jr> TD: I suppose we might be able to get away with "these pools actually assert some policies of their own" and avoid debating which policies are better
257 2013-12-27 19:47:49 <Luke-Jr> TD: we did? 99% of the wallets on bitcoin.org are still garbage
258 2013-12-27 19:47:55 <sugarpuff> gmaxwell: my understanding is that pooled mining solves easier problems, and finds blocks that aren't real solutions, but sometimes, one of the pooled miners will find a block that solves the easy and hard problem
259 2013-12-27 19:48:07 <gmaxwell> Luke-Jr: or perhaps make a template policy document, and list ones that fill it out and keep it updated.
260 2013-12-27 19:48:29 <Luke-Jr> gmaxwell: right, something like that may work
261 2013-12-27 19:48:39 <sugarpuff> if all the miners kept their easy-solutions to themselves, how could they be compensated for their work when someone else finds the real one?
262 2013-12-27 19:48:41 <BlueMatt> Luke-Jr: yes, but that doesnt mean they're not willing to do basic things, even if not complicated bitcoind modifications themselves
263 2013-12-27 19:48:43 <TD> Luke-Jr: lol, nice. we're pushing users towards SPV wallets at least.
264 2013-12-27 19:48:45 <Luke-Jr> .. as long as "we just trust the core devs" isn't an option
265 2013-12-27 19:48:47 <TD> Luke-Jr: and it makes a big difference.
266 2013-12-27 19:48:54 <TD> Luke-Jr: otherwise everyone would end up on b.i
267 2013-12-27 19:49:03 <Luke-Jr> TD: and every SPV wallet AFAIK has major problems causing user confusion
268 2013-12-27 19:49:11 <TD> s/SPV//
269 2013-12-27 19:49:26 <BlueMatt> andytoshi: set of people coming to irc to ask questions != set of people mining, I was asking about outreach, not just answering questions
270 2013-12-27 19:49:40 <sugarpuff> there needs to be a page somewhere that directly addresses the danger posed by selfish mining
271 2013-12-27 19:49:42 <Luke-Jr> TD: fair enough, though IMO Bitcoin-Qt is lightyears ahead
272 2013-12-27 19:49:46 <gmaxwell> sugarpuff: That isn't whats suggested. Whats suggested is that hashers just submit full solutions to the network independantly.
273 2013-12-27 19:49:58 <gmaxwell> sugarpuff: how long have you been using bitcoin?
274 2013-12-27 19:50:00 <Luke-Jr> sugarpuff: why? it's not even a vulnerability
275 2013-12-27 19:50:23 <Luke-Jr> sugarpuff: real problems get cataloged on http://en.bitcoin.it/wiki/CVEs
276 2013-12-27 19:50:30 <gmaxwell> sugarpuff: In my estimation selfish mining wouldn't make the top 10 list of existential risk concerns for bitcoin, not even if the list were limited to only technical ones.
277 2013-12-27 19:50:46 <TD> it's unusable because it's full mode only
278 2013-12-27 19:50:54 <sugarpuff> gmaxwell: ok, fine, but i haven't seen an "official response" to their paper
279 2013-12-27 19:50:55 <Luke-Jr> TD: I use it regularly.
280 2013-12-27 19:51:00 <gmaxwell> Particularly because its trivially detectable.
281 2013-12-27 19:51:03 <Luke-Jr> sugarpuff: because it doesn't deserve one?
282 2013-12-27 19:51:12 <sugarpuff> Luke-Jr: i think it does
283 2013-12-27 19:51:19 <Luke-Jr> sugarpuff: then write one.
284 2013-12-27 19:51:29 <Luke-Jr> sugarpuff: and note it wouldn't be official no matter who wrote it.
285 2013-12-27 19:51:33 <sugarpuff> heh, i'd love to, but the explanations given here so far are too slim on details
286 2013-12-27 19:51:35 <Luke-Jr> bitcoin has no 'official'
287 2013-12-27 19:51:51 <sugarpuff> "official" = in the code, or planned to be in the code
288 2013-12-27 19:51:53 <gmaxwell> sugarpuff: then do some research, this has been discussed _extensively_ elsewhere.
289 2013-12-27 19:52:01 <gmaxwell> Nothing is planned to be changed in the code.
290 2013-12-27 19:52:05 <gmaxwell> (wrt this)
291 2013-12-27 19:52:06 <sugarpuff> gmaxwell: i have been doing research on this for two days now
292 2013-12-27 19:52:16 <gmaxwell> sugarpuff: How long have you been using Bitcoin? Three days?
293 2013-12-27 19:52:24 <sugarpuff> gmaxwell: what do you mean by "using"?
294 2013-12-27 19:52:35 <Luke-Jr> sugarpuff: what code?
295 2013-12-27 19:52:43 <gmaxwell> sugarpuff: I'm suggesting that you're lacking a bit of perspective here and have fallen into a hype trap.
296 2013-12-27 19:52:54 <Luke-Jr> sugarpuff: there is no problem with the code
297 2013-12-27 19:52:54 <sugarpuff> gmaxwell: i read the first paper possibly the same year it was released, and have bitcoins from 2011
298 2013-12-27 19:53:19 <sugarpuff> gmaxwell: fine. but then show me the reason _why_ what you're saying is true.
299 2013-12-27 19:53:43 <sugarpuff> Luke-Jr: you can say that all you want
300 2013-12-27 19:54:03 <sugarpuff> Luke-Jr: but that doesn't mean anything. a proof is needed to show that.
301 2013-12-27 19:54:06 <gmaxwell> sugarpuff: What are you looking for? We pointed out how its trivial to detect and that you can detect it yourself.
302 2013-12-27 19:54:14 <Luke-Jr> sugarpuff: no, the onus of proof is on the one making an assertion.
303 2013-12-27 19:54:21 <sugarpuff> Luke-Jr: they did
304 2013-12-27 19:54:23 <Luke-Jr> sugarpuff: you assert there is a problem or code needs to be changed.
305 2013-12-27 19:54:30 <Luke-Jr> sugarpuff: no, their "proof" is nonsense
306 2013-12-27 19:54:52 <sugarpuff> Luke-Jr: i don't think it is, and at least they have one
307 2013-12-27 19:55:16 <Luke-Jr> sugarpuff: in any case, /ignore sugarpuff seems easiest now.
308 2013-12-27 19:56:32 <sugarpuff> gmaxwell: is the y-axis here the number of orphaned blocks across the entire network (i.e. the number increments even for the same block that was orphaned if another peer orphaned it too)? https://blockchain.info/charts/n-orphaned-blocks
309 2013-12-27 19:57:01 <sugarpuff> Luke-Jr: stick your head in the sand instead of having a discussion.
310 2013-12-27 19:57:41 <gmaxwell> sugarpuff: and in your research you must have seen that virtually every proposed improvement recieved reviews that pointed out how the "improvement" would actually introduce serious vulnerabilities. A panic deployment of complicated and difficult to analyize "fixes" for a problem which demonstrable doesn't exist today, and whichâ if it arose would not be immediately harmfulâ would be incredibly irresponsible.
311 2013-12-27 19:58:32 <sugarpuff> gmaxwell: ok, i agree on that point, if it's true that "if it arose would not be immediately harmful", and i might give that to you. i just want to know if this problem is being addressed, and if so, how.
312 2013-12-27 19:58:41 <gmaxwell> sugarpuff: it appears to be a pure count of orphaned blocks. Looking at your own logs is more prudent.
313 2013-12-27 20:00:00 <Luke-Jr> sugarpuff: the problem cannot exist with the newer GBT mining protocol
314 2013-12-27 20:00:05 <gmaxwell> sugarpuff: As far as I can determine there appear to be no proposed solutions which are less risky / compromise-free than simply worrying about it if it starts to happen.
315 2013-12-27 20:00:12 <gmaxwell> Luke-Jr: sure, it can, if the hashers cooperate.
316 2013-12-27 20:00:20 <Luke-Jr> well, then you have a deeper problem ;p
317 2013-12-27 20:00:48 <Luke-Jr> if miners want to kill bitcoin, we can't really do anything about that
318 2013-12-27 20:01:19 <sugarpuff> Luke-Jr: that's not true. again, read Stephen's advice: https://bitcointalk.org/index.php?topic=324413.msg3478147#msg3478147
319 2013-12-27 20:01:29 <gmaxwell> sure, thats part of the argument against the paper being interesting. Basically it makes a boiling the frog argument for miners becoming evil incrementally.
320 2013-12-27 20:02:13 <sugarpuff> knowing that someone is doing this doesn't get you very far. you need to know *who* is doing it, and then you need to be able to ban them from the network.
321 2013-12-27 20:02:21 <gmaxwell> sugarpuff: that proposed "fix" is flawed because it can create disagreements about the consensus state based on when a node was turned on, or what side of a short term partition it was on.
322 2013-12-27 20:02:40 <gmaxwell> sugarpuff: Are you being paid to waste our time? It sure seems like it.
323 2013-12-27 20:02:59 <sugarpuff> gmaxwell: god, why the hostility??
324 2013-12-27 20:03:17 <gmaxwell> Bitcoin mining is an anonymous process, it can't be decenteralized otherwise. The whole idea of banning someone from it is ill defined.
325 2013-12-27 20:03:48 <gmaxwell> sugarpuff: because you appear to be uninformed about the basic technology and yet you are _yelling_ in here with these high and mighty commandments about who needs to do what.
326 2013-12-27 20:03:52 <warren> sugarpuff: this has already been discussed at length. The allegation is very similar to something posted years ago. The conditions necessary for this attack to work are nearly impossible in reality.
327 2013-12-27 20:04:29 <sugarpuff> warren: then please link me to such a discussion. i have been reading those i could find and am not convinced yet.
328 2013-12-27 20:05:27 <warren> Trivially detectable, proposed solutions would make things worse, etc.
329 2013-12-27 20:05:59 <sugarpuff> warren: notice that what you just said is not a solution to the problem.
330 2013-12-27 20:06:22 <warren> the "problem"
331 2013-12-27 20:06:41 <sugarpuff> and notice that your statement is also contradicted by gmaxwell's comment: "Bitcoin mining is an anonymous process, it can't be decenteralized otherwise. The whole idea of banning someone from it is ill defined."
332 2013-12-27 20:07:04 <gmaxwell> No it isn't.
333 2013-12-27 20:07:14 <DiabloD3> dear god just ban him
334 2013-12-27 20:07:29 <sugarpuff> gmaxwell: "No it isn't." â¦. how?
335 2013-12-27 20:07:52 <DiabloD3> BlueMatt: thank you
336 2013-12-27 20:08:18 <gmaxwell> I feel kinda bad at that outcome, I'm sure its earnest care, if misplaced. It's good to have more people care.
337 2013-12-27 20:08:36 <DiabloD3> gmaxwell: they can care in other channels
338 2013-12-27 20:08:42 <gmaxwell> ... bad if their hyperactive care is indistinguishable from a shill trying to undermine bitcoin by driving people insane. :P
339 2013-12-27 20:08:47 <DiabloD3> #bitcoin is perfect for noob wrangling
340 2013-12-27 20:08:53 <BlueMatt> agreed, but there is a point where its not worth explaining further (has there been any statement in the past 20 minutes that wasnt just a repeat?)
341 2013-12-27 20:09:10 <DiabloD3> ACTION relurks
342 2013-12-27 20:09:31 <gmaxwell> yea, indeed, oh well, to live and learn. In the future I think instead of arguing at all I'll just drop a bunch of links and then ignore unless something interesting is said.
343 2013-12-27 20:09:36 <Luke-Jr> tomorrow's headline: "Bitcoin developers silence inquiry about status of fixing major vulnerability"
344 2013-12-27 20:09:37 <Luke-Jr> <.<
345 2013-12-27 20:10:02 <DiabloD3> what vuln?
346 2013-12-27 20:10:11 <DiabloD3> bitcoin isnt even a network protocol
347 2013-12-27 20:10:14 <BlueMatt> Luke-Jr: my favorite: https://encyclopediadramatica.es/Bitcoin#IRC
348 2013-12-27 20:10:20 <DiabloD3> its a communications protocol, but not a network one
349 2013-12-27 20:10:30 <gmaxwell> FWIW, the post I'd made previously about using local block submission https://bitcointalk.org/index.php?topic=325737.0
350 2013-12-27 20:10:32 <DiabloD3> I could import blocks by hand to an airgapped machine if I felt like coding that shit
351 2013-12-27 20:11:00 <DiabloD3> lol or qrcodes and webcams
352 2013-12-27 20:20:35 <TheButterZone> can somebody rip this latest web wallet operator a new asshole https://bitcointalk.org/index.php?topic=387106.0
353 2013-12-27 20:22:01 <gmaxwell> TheButterZone: "hacked" is the correct phrase, not hacked. "Hacked" expresses the very high probability that the hacking was an insider running off with the funds.
354 2013-12-27 20:22:25 <TheButterZone> see post #4
355 2013-12-27 20:23:17 <jcorgan> where does the forum "Trust: " value come from?
356 2013-12-27 20:23:49 <justanotheruser> TheButterZone: it looks like you already did
357 2013-12-27 20:24:18 <TheButterZone> i dont have the knowhow to deconstruct his defense
358 2013-12-27 20:24:29 <TheButterZone> all i can say is "you are not a perfect human being"
359 2013-12-27 20:24:40 <jcorgan> LOL: "also, i know all mistakes which other developers' can do when writing code, so i dont do them!"
360 2013-12-27 20:24:42 <kuzetsa> TheButterZone: the feedback they sent you really seems like they have a point --> https://bitcointalk.org/index.php?action=trust;u=157527
361 2013-12-27 20:25:11 <kuzetsa> you didn't audit their codebase, just jumped right in with FUD without even asking what their security model is, and only claimed / assumed it was poorly executed.
362 2013-12-27 20:25:16 <justanotheruser> TheButterZone: I wouldn't worry too much. You aren't responsible for those who are careless with their money.
363 2013-12-27 20:25:34 <TheButterZone> there is no security model that cant be "hacked"
364 2013-12-27 20:25:53 <kuzetsa> TheButterZone: yes there is, actually
365 2013-12-27 20:25:58 <kuzetsa> more than one
366 2013-12-27 20:26:42 <jcorgan> just ask him where transactions from the wallet are signed
367 2013-12-27 20:26:45 <kuzetsa> I've helped audit a few valid security models for this sort of thing, so I know firsthand there are ways to make it zero-trust and safe
368 2013-12-27 20:27:11 <BlueMatt> kuzetsa: so far I havent seen one
369 2013-12-27 20:27:24 <BlueMatt> no webwallets Ive seen have even remotely reasonable security
370 2013-12-27 20:27:39 <kuzetsa> yeah :/
371 2013-12-27 20:27:52 <kuzetsa> it's a shame I'm bound by non-discloure agreements
372 2013-12-27 20:27:55 <TheButterZone> youve audited security for web wallet that makes it absolutely impossible for the operator to access the site's own wallets?
373 2013-12-27 20:28:06 <BlueMatt> afaik, if its in chrome, there is no way to prevent auto-update, which means its not remotely recommendable for security
374 2013-12-27 20:28:44 <kuzetsa> TheButterZone: yes.
375 2013-12-27 20:29:13 <robonerd> anyone here run a bitcoin web site?
376 2013-12-27 20:29:17 <kuzetsa> it's not like I'm likely to go to jail or anything for discussing the details, but I don't want to get sued so I'm honoring my NDA
377 2013-12-27 20:29:43 <BlueMatt> which means, by definition, a webwallet without some non-web component is not secure in the sense that I would recommend it for holing large funds
378 2013-12-27 20:30:20 <devrandom> on an related topic, I'm trying to promote the use of p2sh - starting with blockchain.info: https://github.com/blockchain/My-Wallet/pull/59
379 2013-12-27 20:32:24 <kuzetsa> BlueMatt: the most I'm willing to hint is that the entropy sources used by the secure & zero trust model I'm talking about really does use more than 100 bits of entropy for key generation, and the private key is not accessable by the node (equiv. webwallet) operator
380 2013-12-27 20:33:15 <kuzetsa> BlueMatt: it's similar to the discussion from this thread, but not quite the same --> https://bitcointalk.org/index.php?topic=81677.msg1032856#msg1032856
381 2013-12-27 20:33:37 <BlueMatt> kuzetsa: if the signing is done in the browser, the browser has access to the keys necessary to sign, and auto-update is enabled, you're fucked
382 2013-12-27 20:33:46 <BlueMatt> there are many ways to build a webwallet that is awesome and secure
383 2013-12-27 20:33:50 <BlueMatt> but all of them involve non-web components
384 2013-12-27 20:34:03 <devrandom> P2SH FTW ;)
385 2013-12-27 20:34:08 <BlueMatt> yup
386 2013-12-27 20:34:58 <kuzetsa> BlueMatt: I'm not sure what you mean by "auto-update"
387 2013-12-27 20:35:32 <BlueMatt> update-without-user-interaction
388 2013-12-27 20:35:47 <BlueMatt> ie can push new javascript, can update the plugin, etc
389 2013-12-27 20:36:02 <BlueMatt> afaik there is no way to put code in chrome that you cant auto-update without user interaction
390 2013-12-27 20:36:22 <devrandom> I thought you could turn off auto-update on plugins
391 2013-12-27 20:36:32 <BlueMatt> I believe you can, but have you ever?
392 2013-12-27 20:36:51 <BlueMatt> hmm...no I'm not sure
393 2013-12-27 20:36:54 <BlueMatt> at least its not obvious how
394 2013-12-27 20:37:00 <devrandom> true
395 2013-12-27 20:37:06 <devrandom> need better trust models
396 2013-12-27 20:37:25 <devrandom> gitian-downloader in the browser
397 2013-12-27 20:37:42 <BlueMatt> yupyup
398 2013-12-27 20:37:56 <BlueMatt> devrandom: any news on how tor is getting along with gitian?
399 2013-12-27 20:38:10 <devrandom> I haven't heard anything
400 2013-12-27 20:38:16 <BlueMatt> appelbaum just mentioned the next tbb would have det. builds
401 2013-12-27 20:38:16 <TD> hmm. my fee estimator is estimating 20ksat per kb :(
402 2013-12-27 20:38:19 <devrandom> the dev hasn't actually contacted me about anything
403 2013-12-27 20:38:24 <TD> that's the median fee to get included in the next block
404 2013-12-27 20:38:36 <BlueMatt> TD: are you looking at blocks or mempool?
405 2013-12-27 20:38:40 <TD> devrandom: yeah the tor guys have been making firefox deterministic
406 2013-12-27 20:38:49 <devrandom> I saw that part
407 2013-12-27 20:38:57 <TD> BlueMatt: this is based on gavins framework. it's watching txns that show up in the mempool and recording how many blocks it takes before they confirm
408 2013-12-27 20:39:18 <TD> BlueMatt: then it tracks the median for each block interval across a bunch of samples
409 2013-12-27 20:39:39 <BlueMatt> TD: yea, reasonable framework
410 2013-12-27 20:39:45 <devrandom> BlueMatt: TBB3.0 was built with gitian a few months ago, but it's not prod yet
411 2013-12-27 20:39:57 <TD> BlueMatt: i guess the question is - if you can see transactions paying the min fee getting confirmed in the next block
412 2013-12-27 20:39:59 <TheButterZone> jcorgan he answered "Transaction's are signed on Wallify"
413 2013-12-27 20:40:04 <BlueMatt> devrandom: ahh, ok, I just wondered if they had succeeded on windows/osx
414 2013-12-27 20:40:13 <TD> BlueMatt: why would you want to pay higher than that? i'm checking the median, but i'm wondering why not just pick the lowest you've seen?
415 2013-12-27 20:40:21 <devrandom> oh, 3.5 is out
416 2013-12-27 20:40:21 <TD> or the 10th percentile or something
417 2013-12-27 20:41:17 <TD> i'll leave it and see if it converges on a lower value with more data
418 2013-12-27 20:41:38 <devrandom> https://trac.torproject.org/projects/tor/ticket/3688
419 2013-12-27 20:41:41 <devrandom> "fixed"
420 2013-12-27 20:41:48 <TD> but there sure are a surprising number of people paying more than the min fee, given that many blocks aren't full
421 2013-12-27 20:41:50 <AriseChikun> hi, anyone know of any linux or windows builds that have ming w or gitian already isntalled with deps?
422 2013-12-27 20:41:53 <TD> perhaps nodes that never upgraded past the fee drop
423 2013-12-27 20:42:13 <devrandom> BlueMatt: so I guess TBB with gitian is in production
424 2013-12-27 20:43:05 <BlueMatt> TD: yea, I think the original recommendation that was largely agreed upon (that gavin appears to have forgotten/ignored) was to look at the minimum fee getting accepted into blocks which you had seen in mempool (+ a few steps or so, eg 10th percentile)
425 2013-12-27 20:43:13 <BlueMatt> devrandom: awesome
426 2013-12-27 20:44:24 <BlueMatt> TD: oh, wait, no sorry
427 2013-12-27 20:44:33 <BlueMatt> TD: its max fee thats /not/ getting accepted and then add a bit
428 2013-12-27 20:44:42 <BlueMatt> TD: solves the miners-separate-contracts issue as well
429 2013-12-27 20:45:59 <TD> what do you define as "not getting accepted"
430 2013-12-27 20:46:15 <BlueMatt> ie its sitting in mempool and never getting into a block after being in mempool for X blocks
431 2013-12-27 20:47:43 <TD> how is that different to watching for the min that does?
432 2013-12-27 20:48:52 <BlueMatt> miners are free to (and some do) have deals with specific tx generators to add txn to blocks for separate fees
433 2013-12-27 20:49:20 <BlueMatt> and those txn are usually also in mempool, so you may see ones that have a fee that you dont entirely see
434 2013-12-27 20:52:31 <Luke-Jr> devrandom: cfields has gitian building mac bins now
435 2013-12-27 20:52:43 <devrandom> nice
436 2013-12-27 20:55:40 <TD> BlueMatt: mm. i thought most miner deals kept them out of the mempool. but at any rate, "go under and add a bit" feels a bit flakier than "take the nth percentile of what is working"
437 2013-12-27 20:56:24 <BlueMatt> TD: the other point brought up was that miners who want to increase the percentile can throw in a ton of few medium-fee txn at the top of the block
438 2013-12-27 20:56:42 <BlueMatt> TD: so you have to only look at the txn in the block that were in your mempool
439 2013-12-27 20:56:51 <TD> that's what gavin's framework already does
440 2013-12-27 20:56:57 <BlueMatt> ahh, ok, good
441 2013-12-27 20:56:58 <TD> for a tx to be considered, you have to broadcast it
442 2013-12-27 20:57:35 <BlueMatt> well, thats still pretty reasonable
443 2013-12-27 20:58:52 <devrandom> Luke-Jr: cross compiled? free of Apple's binary blobs?
444 2013-12-27 20:59:16 <Luke-Jr> devrandom: you can never eliminate all of Apple's blobs..
445 2013-12-27 20:59:20 <Luke-Jr> gotta link to their libs
446 2013-12-27 20:59:25 <Luke-Jr> but yes, cross-compiled