1 2014-08-19 00:02:36 <phantomcircuit> gmaxwell, "the set of outbound connections uniquely identifies a client"
2 2014-08-19 00:02:38 <phantomcircuit> wat?
3 2014-08-19 00:03:23 <gmaxwell> phantomcircuit: the attack goes like this: they spam your IP all over the network in addr messages so that all the nodes stop forwarding it.
4 2014-08-19 00:03:45 <gmaxwell> The they reconnect, and nodes that advertise your IP are very likely directly connected to you.
5 2014-08-19 00:04:07 <gmaxwell> If those same 8 nodes also are the first to advertise a transaction, it's probably yours.
6 2014-08-19 00:04:24 <gmaxwell> I think rotation is not a good solution to this, but we should have rotation regardless.
7 2014-08-19 00:04:56 <gmaxwell> But we need rotation to not introduce new, easily and profitably exploited weaknesses.
8 2014-08-19 00:06:19 <phantomcircuit> gmaxwell, yeah i dont see how rotation helps there unless it's done at an unreasonable rate
9 2014-08-19 00:09:36 <gmaxwell> well address broadcasts are relatively infrequent so maybe that helps.
10 2014-08-19 00:09:36 <phantomcircuit> gmaxwell, the real issue there is that nodes are effectively leaking who they are connected to
11 2014-08-19 00:10:04 <phantomcircuit> gmaxwell, except you can trigger the addr broadcast with getaddr
12 2014-08-19 00:10:31 <phantomcircuit> so to prevent that you would need to be rotating peers faster than the adversary can connect
13 2014-08-19 00:10:35 <phantomcircuit> which would be ridiculous
14 2014-08-19 00:11:06 <gmaxwell> phantomcircuit: no because you can't trigger someone to send their address to someone else.
15 2014-08-19 00:12:50 <phantomcircuit> gmaxwell, hmm
16 2014-08-19 00:12:59 <gmaxwell> e.g. I can getaddr you to find out what peers you know about, but if I'm connected to you I don't send an updated addr message but per once a day, so you're just going to get the same info over and over again.
17 2014-08-19 00:16:21 <phantomcircuit> gmaxwell, no but i can push new addr messages to you which will rotate the vvNew values out
18 2014-08-19 00:17:13 <gmaxwell> Yes sure, but the victim still won't advertise himself but once per day.
19 2014-08-19 00:17:42 <gmaxwell> so what will happen is once a day you'll learn his peers, bit N minutes later he'll have differen ones.
20 2014-08-19 00:20:28 <phantomcircuit> gmaxwell, when you connect to a peer your address gets put into addrman and marked as Good
21 2014-08-19 00:21:12 <phantomcircuit> so it should be sufficient to simply rotate the other entries since the Good entries dont get rotated
22 2014-08-19 00:21:30 <phantomcircuit> and each getaddr returns a different random set of peers
23 2014-08-19 00:22:47 <phantomcircuit> oh i see
24 2014-08-19 00:22:50 <gmaxwell> phantomcircuit: It doesn't. You only ... right.
25 2014-08-19 00:22:53 <phantomcircuit> it's in the handling of the addr message
26 2014-08-19 00:24:54 <phantomcircuit> hmm
27 2014-08-19 00:28:20 <phantomcircuit> sigh
28 2014-08-19 00:28:22 <phantomcircuit> Storage server temporarily offline
29 2014-08-19 00:28:24 <phantomcircuit> damn it github
30 2014-08-19 01:14:11 <phantomcircuit> gmaxwell, the merged mining spec doesn't make a lot of sense to me
31 2014-08-19 01:14:26 <phantomcircuit> the auxpow block contains Coinbase transaction that is in the parent block, linking the AuxPOW block to its parent block
32 2014-08-19 01:14:43 <phantomcircuit> but the coinbase txn also contains the hash of the auxpow header
33 2014-08-19 01:14:49 <phantomcircuit> which would appear to be circular
34 2014-08-19 01:15:37 <Luke-Jr> phantomcircuit: um, no it doesn't.
35 2014-08-19 01:16:04 <phantomcircuit> Luke-Jr, to which one?
36 2014-08-19 01:16:23 <Luke-Jr> the coinbase only has a merkle root of secondary chain block headers
37 2014-08-19 01:27:32 <phantomcircuit> Luke-Jr, https://en.bitcoin.it/wiki/Merged_mining_specification#Merged_mining_coinbase
38 2014-08-19 01:27:38 <phantomcircuit> what's the block_hash ?
39 2014-08-19 01:30:54 <Luke-Jr> merkle root of block hashes
40 2014-08-19 01:45:59 <phantomcircuit> Luke-Jr, what's the merkle_nonce stuff about?
41 2014-08-19 01:46:11 <phantomcircuit> nvm i see
42 2014-08-19 02:07:02 <BlueMatt> has anyone started on rewriting the tester yet?
43 2014-08-19 02:07:25 <BlueMatt> sipa/cfields/etc: ?
44 2014-08-19 02:07:31 <BlueMatt> who else said they wanted to do it?
45 2014-08-19 02:07:46 <jgarzik> sipa, undertaking audit of all CDataStream uses, then hopefully ACK #4618 in an hour or so
46 2014-08-19 02:09:59 <phantomcircuit> Luke-Jr, trying to move away from rpc calls for merged mining... but i think im about ready to give up on that
47 2014-08-19 02:10:15 <Luke-Jr> :P
48 2014-08-19 02:10:39 <Luke-Jr> phantomcircuit: it's not like they have to be that often
49 2014-08-19 02:12:25 <phantomcircuit> Luke-Jr, check pm
50 2014-08-19 02:14:26 <sipa> BlueMatt: i have not
51 2014-08-19 02:14:37 <sipa> though i plan to
52 2014-08-19 02:14:54 <BlueMatt> what are you gonna write it in?
53 2014-08-19 02:15:06 <BlueMatt> I'm lazy and I think i can make the existing one work pretty easily-ish
54 2014-08-19 02:15:52 <BlueMatt> ie I dont want to lose all the existing tests and am too lazy to rewrite them
55 2014-08-19 02:16:19 <BlueMatt> sipa: how strong is your objection to java? (ie would you do it in java if you just had to write and let some server compile your changes and test?)
56 2014-08-19 02:18:47 <sipa> BlueMatt: if you rewrite it and it becomes cleanly separated and readable, i may contribute
57 2014-08-19 02:19:01 <sipa> BlueMatt: but i wouldn't use java myself
58 2014-08-19 02:19:57 <sipa> abd longer term i'd like to get rid of it entirely, so it can just live in the bitcoin core repo (and not require pulling in all of bitcoinj)
59 2014-08-19 02:21:59 <cfields> sipa: you see the paste above?
60 2014-08-19 02:23:40 <sipa> now i have, cool
61 2014-08-19 02:27:57 <jgarzik> sipa, agree. would prefer to see the tests in the bitcoin core repo && !java
62 2014-08-19 02:32:51 <jgarzik> petertodd, RE cloud hashing... cute
63 2014-08-19 02:34:39 <sipa> BlueMatt: tbh, i do think that any clean and readable solution will involve rewriting the tests...
64 2014-08-19 02:43:09 <sipa> BlueMatt: feel free to yell at me if my pulltester comments don't make sense; i should be asleep, haven't checked the code changes and am typing on a phone
65 2014-08-19 02:43:22 <sipa> stupid mosquito
66 2014-08-19 02:45:43 <jgarzik> ACTION is waiting for tech that permits code changes to be dictated via phone
67 2014-08-19 02:46:13 <jgarzik> There was a nice demo of coding-by-voice a year or so ago...
68 2014-08-19 02:46:46 <jgarzik> bitcoin-tx does not accept input via stdin? What a stupid utility.
69 2014-08-19 02:46:53 <jgarzik> ACTION updates
70 2014-08-19 02:47:07 <sipa> who reviewed that shit??
71 2014-08-19 02:47:27 <jgarzik> might have to remove my ACK from that PR posthumously
72 2014-08-19 02:47:54 <sipa> ACTION ponders creating a bitcoin-key utility
73 2014-08-19 02:48:29 <jgarzik> sipa, do it. that's part of the Master Plan.
74 2014-08-19 02:48:45 <jgarzik> sipa, bitcoin-key and bitcoin-script seem useful.
75 2014-08-19 02:49:04 <sipa> ACTION ponders creating a bitcoin-takes-over-the-world utility
76 2014-08-19 02:49:07 <jgarzik> sipa, bitcoin-key is where I wanted hdderive to live
77 2014-08-19 02:49:13 <sipa> yup
78 2014-08-19 02:49:25 <sipa> but it coulf also do sign/verify/...
79 2014-08-19 02:49:29 <sipa> *could
80 2014-08-19 02:49:41 <sipa> message signing, that is
81 2014-08-19 02:51:46 <jgarzik> sipa, yep
82 2014-08-19 02:51:58 <jgarzik> sipa, and keygen
83 2014-08-19 02:52:12 <petertodd> jgarzik: of course, you could rent the hashing power from someone else, but that makes the fraud quite a bit harder to pull off
84 2014-08-19 03:01:39 <phantomcircuit> petertodd, you cant rent any significant amount of hashing power for very long
85 2014-08-19 03:01:41 <phantomcircuit> er
86 2014-08-19 03:01:44 <phantomcircuit> for short period*
87 2014-08-19 03:01:59 <dsnrk> petertodd: people do love renting hashpower though, you can get 270TH/s from one place right now if you wanted to.
88 2014-08-19 03:06:10 <petertodd> phantomcircuit: I'd be very amused if my suggestion made that possible :P
89 2014-08-19 03:06:55 <petertodd> dsnrk: which one is that? I haven'
90 2014-08-19 03:07:04 <petertodd> I haven't looked at hash power renting places for awhile
91 2014-08-19 03:07:48 <dsnrk> petertodd: nicehash.com sells a stratum proxy. you pay to have whatever stupid PoW you want, and they pipe it to your endpoint. just now somebody is renting 270TH/s of sha256d, which is sort of impressive really.
92 2014-08-19 03:09:16 <petertodd> dsnrk: nice! that'd be an easy way to attack p2pool actually w/ block withholding
93 2014-08-19 03:10:48 <dsnrk> petertodd: yes, that had occurred to me. it's getting to the point where it's got enough hashpower behind it to do a real world attack. from what I've heard it's been used to attack altcoins in the past, their hashpower can overwhelm almost any network except for ours.
94 2014-08-19 03:11:49 <phantomcircuit> the funny thing is that 270Th/s could fit in a small room
95 2014-08-19 03:12:23 <phantomcircuit> 5-6 racks of equipment
96 2014-08-19 03:12:29 <dsnrk> petertodd: note that the "current speed" listed for anything but sha256 is misleading. if you pay enough, people's GPUs swap to that algorithm to participate.
97 2014-08-19 03:12:45 <petertodd> dsnrk: I saw that, pretty funny
98 2014-08-19 03:13:59 <dsnrk> curious where the 270TH/s is going, I imagine 605 people connecting to your stratum server isn't a walk in the park.
99 2014-08-19 03:14:01 <petertodd> phantomcircuit: you know, the interesting thing about my merkle sum thing is that it prevents operations like cloudhashing from earning even more money by selling to nicehash...
100 2014-08-19 03:14:34 <phantomcircuit> petertodd, you mean from double dipping?
101 2014-08-19 03:15:01 <petertodd> phantomcircuit: which leads to a potentially hilarious situation: the cloud hashing operations doing merkle sum will be the ponzi schemes, and the cloud hashing operations not doing it will be the ones with actual hashing power...
102 2014-08-19 03:15:13 <phantomcircuit> i understand that cloud miners could be ponzei schemes... but doing that would be incredibly risky
103 2014-08-19 03:15:29 <dsnrk> is there any information I can get from their stratum server about what the endpoint is?
104 2014-08-19 03:15:44 <petertodd> dsnrk: well, if you find a block you can figure out...
105 2014-08-19 03:16:00 <dsnrk> phantomcircuit: here's a ponzi for you, they've somehow made a brand new type of hardware better than an ASIC. http://gawminers.com/pages/hashlet
106 2014-08-19 03:17:22 <dsnrk> petertodd: well *that's* not going to happen with my 1TH/s. I was thinking more of comparing the latencies with public mining pools to see which one, but chances are it wouldn't be pointed to any of them.
107 2014-08-19 03:17:27 <phantomcircuit> dsnrk, it's a scheme
108 2014-08-19 03:17:31 <phantomcircuit> im not sure it's a scam
109 2014-08-19 03:17:53 <phantomcircuit> they're basically selling contracts which get cheaper as they add hw with lower opex
110 2014-08-19 03:18:01 <dsnrk> uh? well, we can both look at that and say it doesn't exist.
111 2014-08-19 03:18:06 <phantomcircuit> essentially they're gambling that there is even going to be such a thing
112 2014-08-19 03:18:30 <phantomcircuit> dsnrk, yeah that isn't real hardware
113 2014-08-19 03:18:42 <phantomcircuit> they're selling people contracts and pretending they're selling hosted hardware
114 2014-08-19 03:18:56 <phantomcircuit> which is shady but not necessarily a scam
115 2014-08-19 03:19:53 <dsnrk> it's a flat out lie. they're saying they made some new hardware that's not an ASIC, that can be reprogrammed to mine any algorithm, but somehow costs significantly less than an FPGA farm.
116 2014-08-19 03:21:30 <phantomcircuit> dsnrk, it's a bunch of marketing speak
117 2014-08-19 03:21:35 <petertodd> dsnrk: I'd recommend they get into the much more profitable business of making FPGA's if they're that good...
118 2014-08-19 03:22:13 <phantomcircuit> dsnrk, afaict it's marketing speak for something with zero specifications
119 2014-08-19 03:24:43 <phantomcircuit> dsnrk, notice that there is literally nothing about what you're actually buying except for things which must be lies
120 2014-08-19 03:26:15 <dsnrk> phantomcircuit: I get that. I would bet against them owning any hardware at all.
121 2014-08-19 03:27:39 <phantomcircuit> dsnrk, probably they dont
122 2014-08-19 03:27:52 <phantomcircuit> it takes actual expertise to deploy at reasonable cost
123 2014-08-19 03:29:35 <dsnrk> phantomcircuit: what do you make of KNCminer unloading a bumperload of their ASIC chips?
124 2014-08-19 03:30:24 <phantomcircuit> dsnrk, just the chips?
125 2014-08-19 03:30:33 <dsnrk> yeah. $27 USD.
126 2014-08-19 03:31:09 <phantomcircuit> dsnrk, "Designed to run at 0.9V core voltage"
127 2014-08-19 03:31:16 <phantomcircuit> that they fucked something up hilariously
128 2014-08-19 03:32:21 <dsnrk> the VRMs to power the thing cost significantly more than the chip. best I found was $18 USD and you need 8 of the annoying things to power it. bear in mind this is their 28nm chip, not the new 20nm one.
129 2014-08-19 03:32:30 <phantomcircuit> dsnrk, selling chips is basically free money for any hw company
130 2014-08-19 03:32:52 <dsnrk> "Due to yield rate the number of usable cores varies. Statistically at least 70% of our production at this level has contained chips with 100% usable cores, and up to 90% of all the chips have 187 or more usable cores, with the rest of the chips varying below that number." "This product is nonrefundable."
131 2014-08-19 03:33:03 <phantomcircuit> you place an order with the tsmc/global, a third party does verification, they get sent to your customer
132 2014-08-19 03:33:09 <phantomcircuit> you simply collect the money
133 2014-08-19 03:33:17 <dsnrk> they're shipping from stock though.
134 2014-08-19 03:33:54 <phantomcircuit> dsnrk, possibly they're selling the bad part of the lots
135 2014-08-19 03:34:45 <phantomcircuit> dsnrk, how much power is one of those using?
136 2014-08-19 03:35:49 <phantomcircuit> dsnrk, oh i see
137 2014-08-19 03:35:59 <phantomcircuit> they're selling their old 28nm chips since they have the 20nm chips
138 2014-08-19 03:36:04 <phantomcircuit> probably they just ordered too many of them
139 2014-08-19 03:36:12 <phantomcircuit> offer them like $1/chip
140 2014-08-19 03:36:17 <phantomcircuit> i bet they'd take it
141 2014-08-19 03:36:51 <dsnrk> for a good bin it looks like you pump 220W in and get 150GH out.
142 2014-08-19 03:39:39 <phantomcircuit> dsnrk, yeah they're just trying to offload their older chips
143 2014-08-19 03:40:28 <phantomcircuit> it's interesting that their chips require such a high voltage
144 2014-08-19 03:40:40 <phantomcircuit> everybody else on the same process is 100mV lower
145 2014-08-19 03:40:43 <phantomcircuit> (if not more)
146 2014-08-19 03:41:31 <dsnrk> I'm at a loss to explain who would buy them. you're looking at $200 to get one on a board with the right power supply.
147 2014-08-19 03:42:36 <petertodd> dsnrk: potentially someone with a clever idea for a cheaper power supply
148 2014-08-19 03:42:56 <phantomcircuit> dsnrk, there are interesting ways to save money on the power supplies
149 2014-08-19 03:43:09 <phantomcircuit> if you can get the chips cheap enough it's worth doing them
150 2014-08-19 03:43:17 <phantomcircuit> a few strings of them overheat and melt
151 2014-08-19 03:43:19 <phantomcircuit> who cares
152 2014-08-19 03:44:12 <phantomcircuit> there's something really weird about the knc 28nm chips though
153 2014-08-19 03:44:25 <dsnrk> sure, you can do interesting things, but you're against the clock in terms of difficulty. if you had boxes of those (I note there's no data sheets for them anywhere), you'd be wanting to get them running as soon as possible, not waiting for your rev38 PCB to be fabbed.
154 2014-08-19 03:44:41 <phantomcircuit> the voltage trimming algorithm almost always ends up with entire chips dead
155 2014-08-19 03:45:01 <phantomcircuit> it's like the coodination logic between the cores requires a higher voltage than the hashing cores themselves or something ridiculous
156 2014-08-19 03:45:34 <phantomcircuit> dsnrk, i dont think knc gives a crap anymore
157 2014-08-19 03:45:43 <phantomcircuit> they have made literally tens of millions of dollars
158 2014-08-19 03:46:03 <dsnrk> no, I don't think I would care either.
159 2014-08-19 03:46:36 <phantomcircuit> tbh i think they stopped caring in about september
160 2014-08-19 03:46:50 <phantomcircuit> delivered their first batch and were instantly rich
161 2014-08-19 03:47:17 <dsnrk> don't know why they bothered with the self-mining thing at all. they'd have been better with the shovels.
162 2014-08-19 03:47:36 <phantomcircuit> dsnrk, hubris
163 2014-08-19 03:47:42 <phantomcircuit> it seems like an easy thing to do
164 2014-08-19 03:47:45 <phantomcircuit> hint: it's not
165 2014-08-19 03:48:07 <dsnrk> ACTION had trouble keeping 4 antminers cool enough
166 2014-08-19 03:49:36 <phantomcircuit> dsnrk, it really just depends on what efficiency you're targetting
167 2014-08-19 03:49:49 <phantomcircuit> higher die temp means more power consumed
168 2014-08-19 03:49:56 <petertodd> dsnrk: send 'em to my parents place - they pay $800/month for heating
169 2014-08-19 03:50:03 <phantomcircuit> but you can run most chips with a die temp above 115
170 2014-08-19 03:50:10 <dsnrk> I undervolt and underclock my miners, and sold half of them
171 2014-08-19 03:50:29 <phantomcircuit> dsnrk, the easier thing to do is just to run them stupid hot
172 2014-08-19 03:50:42 <dsnrk> phantomcircuit: my power bill says otherwise.
173 2014-08-19 03:50:42 <petertodd> phantomcircuit: yeah, stupid hot and on a UPS so they don't get thermally cycled
174 2014-08-19 03:51:20 <phantomcircuit> dsnrk, are you using a normal ac system to cool them?
175 2014-08-19 03:51:21 <phantomcircuit> if so
176 2014-08-19 03:51:24 <phantomcircuit> lol yeah dont do that
177 2014-08-19 03:51:31 <dsnrk> huh? I'm not an idiot
178 2014-08-19 03:51:56 <petertodd> dsnrk: even if you are using a normal ac system, the hotter you run them the less the ac system costs per joule of heat generated
179 2014-08-19 03:52:00 <phantomcircuit> most equipment will work correctly if it's got enough airflow even at relatively high ambient temps
180 2014-08-19 03:52:07 <phantomcircuit> they just wont work well for very long
181 2014-08-19 03:52:48 <phantomcircuit> petertodd, so i've been staring at merged mining stuff all day kind of scratching my head
182 2014-08-19 03:52:57 <petertodd> phantomcircuit: yeah?
183 2014-08-19 03:53:00 <dsnrk> petertodd: I'm not using an AC. the "keeing them cool enough" was more a comment about me being able to live in the same space, more than worrying about the miners themselves. as long as they aren't on fire the miners will survive.
184 2014-08-19 03:53:07 <phantomcircuit> it seems more complicated than it needs to be
185 2014-08-19 03:53:22 <phantomcircuit> for example the chain id stuff seems unnessary
186 2014-08-19 03:53:31 <phantomcircuit> should be able to just include the merkle branch
187 2014-08-19 03:54:06 <petertodd> phantomcircuit: ah, yeah, that standard is utterly bonkers
188 2014-08-19 03:54:06 <phantomcircuit> dsnrk, i've seen lots of people running the antminers outside in fairly warm places
189 2014-08-19 03:55:00 <petertodd> phantomcircuit: I wrote up proposal for a sane one awhile back on the -dev email list based on binary radix trees, using the prevblockhash to randomly distribute collissions
190 2014-08-19 03:56:43 <phantomcircuit> petertodd, the only part that seems distinctly insane is the chain id stuff
191 2014-08-19 03:58:32 <petertodd> phantomcircuit: been awhile since I looked at it, but as I remember it fails to prevent collissions or something
192 2014-08-19 03:58:59 <phantomcircuit> petertodd, yeah it does
193 2014-08-19 04:00:03 <phantomcircuit> petertodd, and there's weird stuff like the merkle tree size has to be a power of two
194 2014-08-19 04:00:27 <petertodd> phantomcircuit: yup
195 2014-08-19 04:00:56 <petertodd> phantomcircuit: are you able to prove that a given chain ID is *not* in the tree compactly? I forget
196 2014-08-19 04:01:15 <phantomcircuit> petertodd, i have no idea
197 2014-08-19 04:01:44 <phantomcircuit> petertodd, yes you should be able to
198 2014-08-19 04:01:56 <phantomcircuit> chain_id gets convoluted into a slot_num
199 2014-08-19 04:02:21 <phantomcircuit> so with the merkle root and the branch you should be able to easily
200 2014-08-19 04:02:29 <petertodd> right, so you should be able to just show the path was from the right place
201 2014-08-19 04:02:40 <phantomcircuit> the entire chain id <->slotnum thing is broken though
202 2014-08-19 04:03:35 <phantomcircuit> petertodd, the algorithm for calculating slot num from chain id is just comically obviously broken
203 2014-08-19 04:03:55 <petertodd> yeah
204 2014-08-19 04:04:41 <phantomcircuit> i dont even understand the logic behind it
205 2014-08-19 04:04:53 <phantomcircuit> if two chains have the same chain id, they're obviously going to have the same slot number
206 2014-08-19 04:05:58 <petertodd> and the chain id thing is a small integer wasn't it?
207 2014-08-19 04:06:46 <phantomcircuit> petertodd, iirc it's arbitrary length really
208 2014-08-19 04:06:53 <phantomcircuit> since it's not actually included in the headers
209 2014-08-19 04:07:04 <phantomcircuit> basically
210 2014-08-19 04:07:22 <phantomcircuit> chain_id -> slot_num
211 2014-08-19 04:07:35 <phantomcircuit> then the slot_num is used to figure out which part of the merkle tree to use
212 2014-08-19 04:08:06 <phantomcircuit> except you also have blockchain_branch which already has that branch selected anyways
213 2014-08-19 04:08:49 <phantomcircuit> oh it's something about preventing submitting the same pow twice
214 2014-08-19 04:09:09 <phantomcircuit> yeah since you could put the hash for the merged coin into the tree at multiple places
215 2014-08-19 04:09:25 <petertodd> phantomcircuit: yup
216 2014-08-19 04:10:40 <phantomcircuit> and i guess you cant just reject blocks with duplicate pow since it would make it tirival to fork the merged network for a few blocks at a time
217 2014-08-19 04:10:48 <petertodd> yup
218 2014-08-19 04:10:55 <phantomcircuit> just include the hash like 10k times and give all 10k peers a unique solution
219 2014-08-19 04:11:27 <kdomanski> sipa: about that stream interface, there's another nice approach possible
220 2014-08-19 04:11:56 <kdomanski> boost variant can emulate an interface
221 2014-08-19 04:12:08 <kdomanski> a static visitor would resolve the actual class
222 2014-08-19 04:12:25 <kdomanski> with little overhead
223 2014-08-19 04:12:30 <phantomcircuit> petertodd, ok i understand the insanity a bit better
224 2014-08-19 04:12:33 <petertodd> phantomcircuit: also, if you don't enfore uniqueness of the top-level block hash, you could have 10k blocks all under the same pow
225 2014-08-19 04:12:50 <phantomcircuit> petertodd, yeah that's what i was saying
226 2014-08-19 04:12:53 <kdomanski> and in the end you get a single type, just like with virtual interface
227 2014-08-19 04:13:03 <phantomcircuit> er maybe not
228 2014-08-19 04:13:33 <petertodd> phantomcircuit: if you only enforced uniqueness, you need more confirms to be sure than if you do both
229 2014-08-19 04:13:55 <phantomcircuit> petertodd, top level block hash, you mean the merkle tree root?
230 2014-08-19 04:13:58 <phantomcircuit> que
231 2014-08-19 04:14:16 <petertodd> phantomcircuit: no, the hash of the bitcoin block header
232 2014-08-19 04:14:21 <phantomcircuit> ohh
233 2014-08-19 04:15:21 <phantomcircuit> wait that doesn't seem right
234 2014-08-19 04:16:18 <alexwaters> I'm trying (struggling) to read the IBLT whitepaper and came across a part that touches on quotienting. This tickled my curiosity about whether there are any space saving methods used as such: store two data points by diving one by the other, this resulting quotient requires some processing time to recover the likely dividends and divisors - but if they have specific properties it would reduce the in-air bandwidth requiremen
235 2014-08-19 04:16:18 <alexwaters> ts - offloading that to processing costs locally. Is there anything like this, or am I a total noob.
236 2014-08-19 04:16:19 <phantomcircuit> petertodd, is the previous pow included in the merkle tree stuff?
237 2014-08-19 04:17:06 <phantomcircuit> the merkle tree should be hashes of the block header including the hash of the previous block header including the previous blocks pow
238 2014-08-19 04:17:11 <phantomcircuit> which would make that impossible
239 2014-08-19 04:17:30 <sipa> kdomanski: i've trying to change the serialize interface to have a single templated method per data type, instead of the triple generated by implement_serialize
240 2014-08-19 04:18:26 <sipa> kdomanski: i have little problems with templating, but the macros are ugly...
241 2014-08-19 04:18:53 <phantomcircuit> petertodd, lol the hash does include the previous pow
242 2014-08-19 04:18:57 <phantomcircuit> that is just ridiculous
243 2014-08-19 04:19:37 <phantomcircuit> i really hope im reading this wrong
244 2014-08-19 04:19:45 <phantomcircuit> ima go double check the namecoin source
245 2014-08-19 04:20:57 <petertodd> phantomcircuit: I'm pretty sure namecoin did that right...
246 2014-08-19 04:21:10 <phantomcircuit> petertodd, no they did it wrong
247 2014-08-19 04:21:33 <sipa> kdomanski: if using boost variant makes things significantly more readable, sure, but i'm not sure it will
248 2014-08-19 04:21:34 <phantomcircuit> namecoin block header hashes are from nVersion to nNonce
249 2014-08-19 04:21:55 <petertodd> phantomcircuit: so the prevblockhash is the namecoin block hash? that's ok with the chain id thing though, *because* they collide
250 2014-08-19 04:21:57 <phantomcircuit> petertodd, which means they dont include the pow for the block in the header hash
251 2014-08-19 04:22:07 <kdomanski> sipa: I'll play around and see what I can do
252 2014-08-19 04:22:34 <petertodd> phantomcircuit: right, if not for the chain id construction they'd be screwed
253 2014-08-19 04:22:39 <phantomcircuit> yeah
254 2014-08-19 04:23:38 <phantomcircuit> it does make it significantly more difficult to implement in a compact form the merged mining stuff at the pool level though
255 2014-08-19 04:24:02 <phantomcircuit> some idiot comes along and claims a chain_id that someone else is using
256 2014-08-19 04:24:29 <phantomcircuit> you're basically guaranteed to be wasting a ton of slots
257 2014-08-19 04:27:07 <petertodd> phantomcircuit: yup, binary radix trees are simple, and the verification code for the merkle proof trivial
258 2014-08-19 04:28:57 <phantomcircuit> petertodd, the key being the previous block hash?
259 2014-08-19 04:29:07 <phantomcircuit> or the key being the hash of the block?
260 2014-08-19 04:29:23 <phantomcircuit> yeah that would prevent shenanigans
261 2014-08-19 04:29:43 <phantomcircuit> actually it would only partially prevent shenanigans
262 2014-08-19 04:29:57 <phantomcircuit> it would have to be the previous block hash
263 2014-08-19 04:30:08 <phantomcircuit> otherwise you could mutate transactions in odd ways
264 2014-08-19 04:30:17 <phantomcircuit> and give each peer a new valid block
265 2014-08-19 04:30:53 <petertodd> phantomcircuit: basically H(prevblockhash + chain_uuid)
266 2014-08-19 04:32:29 <phantomcircuit> petertodd, prev block hash alone is enough
267 2014-08-19 04:32:45 <petertodd> phantomcircuit: to actually create the radix tree from a set of (chain_uuid, chain_blockhash) tuples you can just use a recursive algorithm that takes a set and calls itself twice with half the set each until the set contains just one item
268 2014-08-19 04:32:57 <petertodd> phantomcircuit: I mean H(prevblockhash + chain_uuid) is the key used for the binary radix tree
269 2014-08-19 04:33:32 <phantomcircuit> petertodd, i know... but why
270 2014-08-19 04:34:30 <phantomcircuit> the previous block hash will be unique anyways
271 2014-08-19 04:35:20 <petertodd> phantomcircuit: it's to ensure that people can't cause trouble by picking chain_uuid's that nearly conflict with other chain_uuids
272 2014-08-19 04:35:44 <phantomcircuit> petertodd, what do you even need the chain uuid for though
273 2014-08-19 04:36:25 <phantomcircuit> just use the prev block hash as the key
274 2014-08-19 04:37:00 <phantomcircuit> in the radix tree you cant have two endpoints with the same key value on different branches
275 2014-08-19 04:37:06 <phantomcircuit> no need for the chain id idea at all
276 2014-08-19 04:37:19 <phantomcircuit> (i think)
277 2014-08-19 04:38:26 <petertodd> phantomcircuit: prev block hash of the MM chain you mean? if you do that then I can still play the "mine multiple blocks" trick, and I can't prove that a given chain *wasn't* mined in a block
278 2014-08-19 04:41:01 <phantomcircuit> petertodd, the only trick im seeing is that you include the info for the merged chain multiple times into the same tree
279 2014-08-19 04:41:18 <phantomcircuit> then you claim each of those branches as a separate pow
280 2014-08-19 04:41:46 <phantomcircuit> but if you use the previous block header hash in a radix tree... then you cant do that
281 2014-08-19 04:45:18 <phantomcircuit> petertodd, see what im saying?
282 2014-08-19 04:52:03 <phantomcircuit> leaves me hanging
283 2014-08-19 04:52:05 <petertodd> phantomcircuit: right, but if it's the MM chain header, then the prev hash is independent of the PoW hash, so you can pull off that trick
284 2014-08-19 04:52:34 <petertodd> phantomcircuit: if it's not independent, then you have a collission problem, which can be resolved by hashing that prevblockhash with, say, a chain_uuid... oh wait :)
285 2014-08-19 04:53:26 <phantomcircuit> petertodd, why do you have a collision problem? just have the hash be both the merged chain header AND the previous pow
286 2014-08-19 04:55:01 <phantomcircuit> petertodd, the merged chain header means you dont have collisions and the previous pow means you can pull off the multiple outputs trick
287 2014-08-19 04:56:22 <phantomcircuit> i think it works at least
288 2014-08-19 04:57:47 <petertodd> phantomcircuit: nope, I could separate the chain by mining two different valid tips in different blocks, then I'd have independent chains I can MM together
289 2014-08-19 04:58:57 <phantomcircuit> petertodd, so by mining block 100 and block 99 ?
290 2014-08-19 04:59:05 <phantomcircuit> im not sure i care about that
291 2014-08-19 04:59:23 <petertodd> you should, that enables some pretty ugly attacks
292 2014-08-19 04:59:36 <phantomcircuit> hmm yeah i guess it would be annoying
293 2014-08-19 04:59:38 <petertodd> much easier just to use the UUID :)
294 2014-08-19 04:59:40 <phantomcircuit> lots of spam
295 2014-08-19 04:59:52 <phantomcircuit> oh actually
296 2014-08-19 05:00:01 <phantomcircuit> the bigger issue is if there was a fork
297 2014-08-19 05:00:06 <phantomcircuit> i could mine each one an equal length
298 2014-08-19 05:00:10 <phantomcircuit> yeah that is a problem
299 2014-08-19 05:00:17 <petertodd> that's what I'm saying
300 2014-08-19 05:00:18 <phantomcircuit> nvm chain uuid it is
301 2014-08-19 05:00:29 <phantomcircuit> petertodd, yeah i wasn't getting it
302 2014-08-19 05:00:30 <phantomcircuit> now i get it
303 2014-08-19 05:00:43 <phantomcircuit> too many ambiguous words at play
304 2014-08-19 05:01:07 <petertodd> heh, we rally need more terms for this
305 2014-08-19 05:01:31 <phantomcircuit> so actually
306 2014-08-19 05:01:58 <phantomcircuit> no matter what you'd be able to mine block 99 and block 100 but not block 100a and block 100b
307 2014-08-19 05:02:17 <phantomcircuit> H(prevhash + chain_id) doesnt' prevent the first one
308 2014-08-19 05:02:35 <phantomcircuit> so you probably just want to do the chain_id itself
309 2014-08-19 05:02:41 <phantomcircuit> in the radix tree
310 2014-08-19 05:02:57 <phantomcircuit> basically it's the same construct as exists currently, except using the right data structure
311 2014-08-19 05:03:13 <petertodd> oh, to be clear, I mean H(masterprevhash + chain_id), not the prevhash for the MM chain
312 2014-08-19 05:03:20 <phantomcircuit> ah
313 2014-08-19 05:03:29 <phantomcircuit> yeah i think that works fine
314 2014-08-19 05:10:14 <dsnrk> odd that the RPC server lets you test how long the RPC password is
315 2014-08-19 05:10:36 <dsnrk> if it's < 20 characters you get confirmation due to it sleeping before dropping the connection
316 2014-08-19 05:12:38 <dsnrk> not that the sleep does anything to stop people from brute force attacking it, you can make a request with an invalid method (fastest response) and assume it's false if you don't get a reply back straight away.
317 2014-08-19 05:25:55 <phantomcircuit> petertodd, now i just have to figure out how to stuff a radix tree into the existing mm structure so we can continue to mine nmc while also doing this
318 2014-08-19 05:40:47 <petertodd> phantomcircuit: use p2pool's op_return commitment scheme for new MM things
319 2014-08-19 05:43:33 <phantomcircuit> petertodd, basically just using an op_return output for everythign right
320 2014-08-19 05:51:03 <petertodd> phantomcircuit: right, one at the end of the tx, which means with sha256 midstates you get small proofs
321 2014-08-19 06:11:45 <phantomcircuit> petertodd, oh right you just hash the rest of the coinbase tx and then midstate + op_return data
322 2014-08-19 06:11:47 <phantomcircuit> interesting
323 2014-08-19 06:38:21 <alexwate_> my understanding of IBLTs are such that QT nodes would get the blockchain, and blocks in it would have an IBLT ~80byte header in place of the ~1MB transaction field. If that's true (which I'm very unsure of), how do QT nodes find their wallet balance?
324 2014-08-19 06:38:41 <alexwate_> and if it's not true, how does IBLT squeeze more txs into a block without increasing block size limits
325 2014-08-19 06:40:57 <alexwate_> or does it only address block propagation time not being slowed by size of transaction field, and full QT nodes will still have to store every transaction that are in the IBLTs
326 2014-08-19 06:42:08 <wumpus> dsnrk: the sleeping does hold up a thread, of which only a very limited number is available by default, although having it conditional on the password size is weird
327 2014-08-19 06:45:13 <dsnrk> wumpus: right, was forgetting it wasn't apache or something.
328 2014-08-19 06:46:13 <wumpus> thinking about it, it makes it possible for someone who doesn't have the password to do an effective DoS
329 2014-08-19 06:47:18 <dsnrk> couldn't they just open a connection and then sleep forever and have the same result?
330 2014-08-19 06:47:23 <wumpus> then again, RPC security is based on binding/allowip, if an attacker is that far that they can try passwords it's good to have a warning...
331 2014-08-19 06:47:37 <wumpus> dsnrk: true in this case
332 2014-08-19 06:48:03 <wumpus> the sleep makes sense, but it should be done always, not based on password length
333 2014-08-19 06:49:10 <wumpus> alexwate_: as I understand it, IBLT doesn't squeeze more transactions into a block
334 2014-08-19 06:49:33 <wumpus> alexwate_: it just allows communicating new blocks faster by making use of transactions that have already been propagated
335 2014-08-19 06:50:17 <wumpus> so it affects communication - not storage
336 2014-08-19 06:50:49 <dsnrk> alexwate_: wallets also do not have balances.
337 2014-08-19 06:51:40 <dsnrk> at the block level (what we are talking about) there's only outputs.
338 2014-08-19 06:51:44 <wumpus> dsnrk: wallets do :p
339 2014-08-19 06:52:22 <wumpus> dsnrk: wallets are a collection of private keys, and associated 'coins'/outputs they can spend with it, so they have a spendable balance
340 2014-08-19 06:52:37 <wumpus> you're probably confused with addreses which indeed don't have a balance
341 2014-08-19 06:53:15 <dsnrk> wumpus: yes, but at the block level that's not the case. I was trying to get to the point that bitcoin-qt doesn't look in blocks for balances at all, they search for outputs which scripts they can satisfy.
342 2014-08-19 06:53:27 <wumpus> and yeah, wallets indeed don't exist at the block level, it's easy to confuse abstraction levels
343 2014-08-19 06:54:24 <wumpus> dsnrk: that's true, computing balances is more involved than just looking in blocks for them
344 2014-08-19 06:56:52 <alexwate_> a more modular network could have verifying nodes. my electrum wallet could get my spendable amount from a centralized server on initialization, but could do IBLT key-pair GETS to verify specific txs without relying on that central server, no?
345 2014-08-19 06:57:42 <alexwate_> and have self-verifiable txs, without have to download all the txs ever
346 2014-08-19 06:57:58 <dsnrk> read up about SPV clients
347 2014-08-19 06:58:47 <dsnrk> the contents of a block can already be verified using the merkle tree without having all of the transactions.
348 2014-08-19 06:59:16 <alexwate_> oh that's cool. sorry didn't know that
349 2014-08-19 06:59:20 <wumpus> IBLT is aimed at miners and verifying nodes that want all transactions, and that's what the compression makes use of
350 2014-08-19 07:00:01 <dsnrk> all it's doing is reducing transfer time for blocks by avoiding sending redundant data.
351 2014-08-19 07:00:17 <dsnrk> lower orphans, less bandwidth, lossless compression.
352 2014-08-19 07:00:27 <wumpus> SPV, setting bloom filters to receive only a subset of transactions, is a different way to reduce bandwidth for a different reason
353 2014-08-19 07:01:06 <petertodd> dsnrk: however IBLT only works if large miners are "honest"
354 2014-08-19 07:01:41 <alexwate_> i thought it also works if they're more profitable
355 2014-08-19 07:01:43 <dsnrk> p2pool seems to manage with a similar system, doesn't it?
356 2014-08-19 07:01:43 <petertodd> dsnrk: large miners still have an advantage over small ones that they can exploit
357 2014-08-19 07:02:04 <petertodd> dsnrk: p2pool can be exploited profitably by those with low-latency
358 2014-08-19 07:02:19 <petertodd> dsnrk: also, p2pool shares are much smaller than blocks
359 2014-08-19 07:04:12 <petertodd> alexwate_: the problem is that with regard to fees you have no incentive to distribute your blocks to >30% of the hashing power; similar to selfish mining incentives, but in a more fundemental way
360 2014-08-19 07:05:37 <petertodd> alexwate_: even with the subsidy given that mining is a zerosum game a valid long-term strategy is to mine blocks that contain transactions that haven't been widely distributed, defeating IBLT, so your competitors are orphaned
361 2014-08-19 07:05:38 <alexwate_> @petertodd would that be a new problem though, or newly compounded?
362 2014-08-19 07:05:53 <petertodd> alexwate_: it's compounded if you think IBLT means you can raise the blocksize basically
363 2014-08-19 07:06:16 <petertodd> alexwate_: tl;dr: IBLT is an optimization that only works if people are honest; it's not incentive compatible
364 2014-08-19 07:08:00 <alexwate_> damn humans, we should program robots to figure this all out then ;)
365 2014-08-19 07:08:51 <petertodd> alexwate_: heh
366 2014-08-19 07:09:53 <petertodd> alexwate_: something interesting that came out of the GHash.IO 50% attack meeting is that GHash.IO is knowingly operating their pool at a loss
367 2014-08-19 07:10:21 <petertodd> alexwate_: now, if you
368 2014-08-19 07:10:39 <dsnrk> petertodd: oh really?
369 2014-08-19 07:10:49 <petertodd> alexwate_: now, if you're willing to operate a pool at a loss to gain marketshare, sabotaging IBLT is just a logical thing to do
370 2014-08-19 07:11:19 <petertodd> dsnrk: yup, remember, they charge no fees; they didn't have a good explanation as to why they were willing to do that, just vague stuff about driving business to their exchange
371 2014-08-19 07:11:45 <alexwate_> IMHO, Bitcoin is a work by intelligent robots to distract #bitcoin-dev (especially Luke) from working on anti-robot weaponry... https://www.youtube.com/watch?v=7Pq-S557XQU
372 2014-08-19 07:11:47 <dsnrk> petertodd: I thought it was to smooth out their orphan rate (it was awful for a while)
373 2014-08-19 07:12:10 <alexwate_> satoshi 9000, cleverest robot in cryptography
374 2014-08-19 07:12:56 <alexwate_> and if they are willing to sabotage IBLT, wouldn't it be in the end-user's interest to prune them somehow?
375 2014-08-19 07:14:27 <petertodd> dsnrk: that was just bad misconfiguration
376 2014-08-19 07:14:59 <petertodd> alexwate_: prune them? what do you mean?
377 2014-08-19 07:15:18 <dsnrk> petertodd: I'm not worried about it myself. as Andreas says, if they do anything bad we'll ban them from the network :3
378 2014-08-19 07:15:39 <petertodd> dsnrk: yeah, good luck on that...
379 2014-08-19 07:15:49 <JohnKenney> it kills the decentralised thing
380 2014-08-19 07:15:59 <petertodd> JohnKenney: exactly
381 2014-08-19 07:16:08 <alexwate_> petertodd: change the PoW, move to a WoT-based largest chain system, I don't know - hire IG88 to take out their ASICs
382 2014-08-19 07:16:13 <dsnrk> petertodd: I know. I'm calling attention to him being a fool, as always.
383 2014-08-19 07:16:32 <dsnrk> petertodd: he got up in front of hundreds of people and said that.
384 2014-08-19 07:16:49 <petertodd> dsnrk: yup, kinda cringeworthy that...
385 2014-08-19 07:17:12 <dsnrk> and some shit about governments not being able to fab their on ASIC mining chips.
386 2014-08-19 07:18:14 <petertodd> dsnrk: which is strictly speaking true... but globalfoundries isn't exactly going to turn down a US government purchase order
387 2014-08-19 07:18:18 <dsnrk> https://www.youtube.com/watch?v=yWTQgmCuiCw
388 2014-08-19 07:18:33 <phantomcircuit> dsnrk, wat
389 2014-08-19 07:18:54 <alexwate_> petertodd: the US govt doesn't need a private sector foundry...lol
390 2014-08-19 07:19:08 <dsnrk> petertodd: it's not even approaching true. governments have budgets we can't even imagine.
391 2014-08-19 07:19:12 <phantomcircuit> alexwate_, actually they do
392 2014-08-19 07:19:17 <phantomcircuit> the best fab the feds have is 155nm
393 2014-08-19 07:19:24 <petertodd> alexwate_: no, they do, the US govt does *not* have the ability to make top of the line chips themselves
394 2014-08-19 07:19:52 <alexwate_> oh
395 2014-08-19 07:20:03 <dsnrk> does it matter? if you have enough money anything is possible.
396 2014-08-19 07:20:03 <phantomcircuit> they can probably get them at cost though
397 2014-08-19 07:20:10 <wumpus> why would they? they contract everything out these days
398 2014-08-19 07:20:12 <phantomcircuit> which would be about 10x cheaper than what 99% of people pay
399 2014-08-19 07:20:20 <wumpus> btw, off topic for #bitcoin-dev
400 2014-08-19 07:20:27 <dsnrk> sorry.
401 2014-08-19 08:19:13 <kdomanski> sipa: the one thing with single template I cannot wrap my head around is the fact that Serialize and GetSerializeSize should be constant functions, while Deserialize cannot
402 2014-08-19 08:19:32 <kdomanski> and a template cannot generate both
403 2014-08-19 08:28:27 <sipa> kdomanski: indeed, that's a pity
404 2014-08-19 08:58:34 <sipa> kdomanski: one way is to use a templated wrapper object around every object being serialized/deserialized, and use a different one for serialize/deserialize, and make the serialize one accept a const ref as argument
405 2014-08-19 09:04:41 <sipa> kdomanski: for getserializesize, a specialed serializer
406 2014-08-19 09:12:35 <kdomanski> sipa: for GetSerializeSize, one could simply serialize with SerReadWrite
407 2014-08-19 09:13:03 <kdomanski> I mean with CSizeComputer
408 2014-08-19 09:14:08 <sipa> yes, that was my intention
409 2014-08-19 09:14:36 <sipa> and you could specialize the serialize method for that writer if you wanted something more efficient
410 2014-08-19 09:14:53 <kdomanski> yup
411 2014-08-19 09:17:29 <kdomanski> as for more efficiency, is shaving off CPU cycles here really of much use? I thought we were mostly IO bound
412 2014-08-19 09:17:29 <sipa> and with much dbcache, io hardly matters
413 2014-08-19 09:17:29 <sipa> some data structures are serialozed/deserialized many times
414 2014-08-19 09:17:37 <kdomanski> sipa: has there any profiling been done?
415 2014-08-19 09:17:40 <sipa> but it's (i assume) much more than a few cpu cycles
416 2014-08-19 09:17:57 <sipa> some, but i'm mostly guessing
417 2014-08-19 09:18:02 <kdomanski> ok
418 2014-08-19 09:18:34 <sipa> it's not that the dynamic dispatching on itself is a problem i fear
419 2014-08-19 09:18:55 <sipa> it's that the code can't be inlined and pretty much oprimkzed away through it
420 2014-08-19 09:19:01 <sipa> *optimized
421 2014-08-19 09:19:34 <wumpus> yes, dynamic dispatching foils static analysis
422 2014-08-19 09:20:51 <kdomanski> ACTION googles dynamic dispatching
423 2014-08-19 09:20:57 <wumpus> which is a bad thing for the consensus code
424 2014-08-19 09:21:20 <sipa> kdomanski: vtable lookup
425 2014-08-19 09:21:35 <kdomanski> sipa: ah, thx
426 2014-08-19 09:21:46 <sipa> the code position jumped to is determined at runtime rather than at compile time
427 2014-08-19 09:55:40 <wumpus> Luke-Jr: I don't think https://github.com/bitcoin/bitcoin/pull/4726 mkes much sense
428 2014-08-19 09:56:56 <Luke-Jr> wumpus: I don't disagree. It was a good exercise though - I found a few bugs in libbase58 in the process :D
429 2014-08-19 09:57:06 <wumpus> the wrapper code is almost as long as our own implementation of b58
430 2014-08-19 09:57:08 <wumpus> ok :D
431 2014-08-19 09:57:53 <Luke-Jr> also learned more why people dislike automake :x
432 2014-08-19 09:58:11 <wumpus> it's extrememly high maintenance, hard to debug, hard to understand
433 2014-08-19 09:58:52 <Luke-Jr> well, I think about stupid things like the first build not having inter-file make dependencies, subprojects having to use the same configure arguments as the parent (worked around in that PR), etc
434 2014-08-19 09:59:04 <wumpus> still, lots better than our old build system
435 2014-08-19 09:59:16 <Luke-Jr> personally, I've found it pretty good for debugging and understanding *shrug*
436 2014-08-19 09:59:19 <Luke-Jr> definitely
437 2014-08-19 09:59:28 <Luke-Jr> and I'm not about to suggest any alternatives are better, sadly
438 2014-08-19 10:00:22 <wumpus> well for example see something as trivial as passing a source directory to a test wrapper, https://github.com/bitcoin/bitcoin/pull/4624
439 2014-08-19 10:00:55 <Luke-Jr> ok sure, the test stuff is a bit nasty. it works pretty nice, though :P
440 2014-08-19 11:02:58 <midnightmagic> the use of boost::filesystem::copy_file() in src/walletdb.cpp is causing ABI compatibility issues in a pkgsrc build environment linker which can't be solved by setting a define as suggested here: http://www.robertnitsch.de/notes/cpp/cpp11_boost_filesystem_undefined_reference_copy_file
441 2014-08-19 11:03:24 <midnightmagic> the easiest fix for now is a patch which converts the copy_file() to a plain copy() and remove the conditional entirely.
442 2014-08-19 11:03:40 <midnightmagic> apologies in advance if this is horrible for someone in the future who does a google search and finds these comments.
443 2014-08-19 11:29:28 <kdomanski> sipa: I managed to make IMPLEMENT_SERIALIZE 2x shorter and implement the statements in a template instead of through the macro
444 2014-08-19 11:29:41 <kdomanski> sipa: it's compiling, we'll see if it works
445 2014-08-19 11:30:01 <Luke-Jr> kdomanski: shorter is not necessarily better
446 2014-08-19 11:45:14 <sipa> Luke-Jr, kdomanski: shorter - all other things equal - is certainly preferable, but i really just want to get rid of mactos with code body
447 2014-08-19 11:47:23 <kdomanski> sipa: Yes, the code body is no longer in the macro. The macro just implements the three functions as wrappers over the template. Still compiling.
448 2014-08-19 11:53:30 <wumpus> midnightmagic: huh, is that a boost version issue?
449 2014-08-19 11:54:08 <wumpus> is copy_file deprecated? or newly introduced?
450 2014-08-19 11:55:18 <wumpus> I see the flag argument was added in boost 1.40 -- is that maybe wrong?
451 2014-08-19 11:57:40 <wumpus> wait: you shouldn't be compiling bitcoin with -std=c++0x at all
452 2014-08-19 12:08:11 <kdomanski> sipa: aaaaand, the test failed
453 2014-08-19 12:08:59 <sipa> :)
454 2014-08-19 12:22:34 <michagogo> 08:10:15 <dsnrk> odd that the RPC server lets you test how long the RPC password is
455 2014-08-19 12:22:34 <michagogo> 08:10:36 <dsnrk> if it's < 20 characters you get confirmation due to it sleeping before dropping the connection
456 2014-08-19 12:22:45 <michagogo> Eh? Wasn't there a CVE about that that got fixed?
457 2014-08-19 12:38:13 <wumpus> michagogo: AFAIK no, that was about the timing attack
458 2014-08-19 12:38:21 <wumpus> fixed by using a constant-time compare
459 2014-08-19 12:38:58 <michagogo> ah
460 2014-08-19 12:50:20 <wumpus> michagogo, dsnrk https://github.com/bitcoin/bitcoin/pull/4728
461 2014-08-19 13:07:15 <jgarzik> I always considered RPC password security patches a waste of time. We use basic freakin auth, and you should not be exposing it over WAN regardless of password length.
462 2014-08-19 13:07:24 <jgarzik> (even via ssl)
463 2014-08-19 13:09:22 <wumpus> still, it is pretty stupid to base a response on the password length, so I think that needs to be fixed
464 2014-08-19 13:10:53 <wumpus> but in general I agree
465 2014-08-19 13:23:26 <dsnrk> jgarzik: I agree, but people do expose it to the internet sadly.
466 2014-08-19 13:34:41 <lclc> sipa: If there would be a bigint implementation for the secp256k1, Bitcoin wouldn't need openssl anymore at all as dependency (expect for optional encryption of the wallet file) right? https://github.com/bitcoin/secp256k1/issues/30
467 2014-08-19 13:40:28 <sipa> lclc: you can use gmp
468 2014-08-19 13:40:43 <sipa> we still use openssl as PRNG though
469 2014-08-19 13:49:09 <wumpus> lclc: openssl is also used for rpc, but that will be made optional too once secp256k1 is integrated
470 2014-08-19 13:50:24 <sipa> lclc: also, the payment protocol requires an ssl implementation
471 2014-08-19 13:51:13 <wumpus> so in general for the wallet to be enabled it is a requirement
472 2014-08-19 13:52:40 <JohnKenney> it'd help with redhat based distros
473 2014-08-19 13:53:46 <wumpus> that's for sure, as the requirement for ecc in openssl would be gone
474 2014-08-19 13:54:06 <sipa> implementing a PRNG isn't hard though, as it can be based on already implemrnted primitives (hmac sha512 eg)
475 2014-08-19 13:54:40 <JohnKenney> why not use the system prng?
476 2014-08-19 13:54:46 <helo> ACTION shakes the crypto reimplementation stick at you
477 2014-08-19 13:55:12 <sipa> JohnKenney: you use the system prng to seed the internal one
478 2014-08-19 13:55:24 <sipa> but not all sources are available on all systems
479 2014-08-19 13:55:44 <JohnKenney> not sure how well the windows one works
480 2014-08-19 13:56:29 <edcba> depends on which backdoor is used
481 2014-08-19 13:56:44 <JohnKenney> if urandom is available it should be pretty good though
482 2014-08-19 13:57:15 <sipa> you don't want to drain the system entropy with every key generated
483 2014-08-19 13:57:17 <wumpus> openssl on windows is interesting, it collects entropy from various sources, like event timings, window contents
484 2014-08-19 13:57:35 <JohnKenney> urandom doesn't drain much entropy
485 2014-08-19 13:57:41 <sipa> reading 16-32 from various entropy sources and using that to seed your own pool is enough
486 2014-08-19 13:57:49 <sipa> JohnKenney: exactly as much as you read from it
487 2014-08-19 13:57:56 <sipa> 16-32 bytes
488 2014-08-19 13:58:01 <JohnKenney> urandom stretches it more
489 2014-08-19 13:58:07 <sipa> eh, no
490 2014-08-19 13:58:07 <wumpus> generating a key seems a good reason to drain entropy to me
491 2014-08-19 13:58:20 <JohnKenney> than dev/random
492 2014-08-19 13:58:24 <sipa> it just doesn't block when no entropy is available
493 2014-08-19 13:58:30 <sipa> and keeps giving
494 2014-08-19 14:24:39 <chmod755> random question: why is there no listing for windows phones on https://bitcoin.org/en/choose-your-wallet ?
495 2014-08-19 14:27:05 <Luke-Jr> chmod755: does any wallet exist for that? do people even use it? XD
496 2014-08-19 14:28:26 <wumpus> no idea? what is windows phone? :)
497 2014-08-19 14:28:49 <Luke-Jr> wumpus: something Microsoft made basically to kill off (real) Linux on phones
498 2014-08-19 14:29:21 <chmod755> i don't know if windows phone users actually exist
499 2014-08-19 14:30:14 <chmod755> just found a blockchain.info wallet, but it's unofficial
500 2014-08-19 14:30:27 <Squidicuz> ACTION wants a linux phone...
501 2014-08-19 14:46:11 <jgarzik> wumpus, sipa, cfields: re-ACK for python-ized bitcoin-tx tests? https://github.com/bitcoin/bitcoin/pull/4624
502 2014-08-19 14:49:41 <Emzy> chmod755: a friend of mine has a windows phone... so they exist...
503 2014-08-19 14:52:28 <helo> anecdotal, disregarding claim
504 2014-08-19 14:58:43 <chmod755> Emzy, if it's only one of your friends using it, it's probably not really worth making a nice wallet for it (unless .... his name is Bill Gates)
505 2014-08-19 15:00:00 <wumpus> jgarzik: yes, looks good to me, but you say that make distcheck doesn't work yet so that's why I held off my ACK
506 2014-08-19 15:00:48 <jgarzik> wumpus, make distcheck works
507 2014-08-19 15:01:04 <wumpus> oh, you didn't mention that, ACK in that case
508 2014-08-19 15:01:05 <jgarzik> wumpus, fixed yesterday, after cfields found the issue
509 2014-08-19 15:01:57 <Emzy> chmod755: HEHE
510 2014-08-19 15:11:52 <wumpus> accepting input on stdin for bitcoin-tx is useful too
511 2014-08-19 15:12:29 <wumpus> for example for private keys for signing, to avoid them leaking to either disk or the command line
512 2014-08-19 15:13:06 <dsnrk> what is bitcoin-tx? I keep seeing it mentioned but I've never seen it before
513 2014-08-19 15:14:46 <wumpus> it's a command-line utility for working with raw transactions
514 2014-08-19 15:15:10 <dsnrk> link?
515 2014-08-19 15:15:34 <wumpus> https://github.com/bitcoin/bitcoin
516 2014-08-19 15:15:51 <wumpus> it is built by default
517 2014-08-19 15:16:12 <dsnrk> oh, that's why I couldn't find it anywhere. sorry.
518 2014-08-19 15:16:31 <wumpus> yes it isn't in any releases yet
519 2014-08-19 15:16:56 <dsnrk> I build from master anyway, I just didn't realise it was a part of core at all
520 2014-08-19 16:27:14 <skinnkavaj> http://www.reddit.com/r/Bitcoin/comments/2dz8rz/introducing_blockio_the_zero_tx_fee_api_wallet/
521 2014-08-19 16:27:19 <skinnkavaj> How can they offer zero fees?
522 2014-08-19 16:29:24 <poutine> cooperative miner is one method
523 2014-08-19 16:29:35 <Dom__> Is there any literature on how much it costs a miner to include a transaction in block? Is there any incentive other than transaction fees for miners to include as many transactions as possible in a block?
524 2014-08-19 16:29:44 <helo> free like lunch
525 2014-08-19 16:29:47 <gmaxwell> skinnkavaj: offtopic for this channel, they're taking about fees _they_ apply, "non-network fees"
526 2014-08-19 16:29:52 <poutine> "Also, this is not a zero TX fee service, it just doesn't have any additional service fees."
527 2014-08-19 16:30:04 <Squidicuz> there is no free lunch.
528 2014-08-19 16:30:08 <skinnkavaj> Wow, p2pool at 4,6% amazing :)
529 2014-08-19 16:30:12 <Squidicuz> <3