1 2013-01-03 00:00:10 <sipa> and it's all you need to validate transactions and blocks
2 2013-01-03 00:00:36 <sipa> but it still downloads full blocks
3 2013-01-03 00:00:42 <jine> sipa: Will that improve the verification-speed of blocks?
4 2013-01-03 00:00:49 <sipa> jine: very significantly
5 2013-01-03 00:00:54 <jine> Cause afaik that's what takes most of the cpu/iops currently.
6 2013-01-03 00:01:29 <jine> Which seems to be the major limitation as of now. I'm on 250/100mbit with gbit against a few of my own nodes, on a fast SSD-disk - and it still takes ages to verify blocks :/
7 2013-01-03 00:01:54 <jine> sipa: Sounds good then :)
8 2013-01-03 00:02:16 <sipa> jine: i can reverify the entire chain (if i disable signature checking, which is 2 orders of magnitude slower than the rest, and the bottleneck after the last checkpoint) in 10 minutes or so on my laptop
9 2013-01-03 00:02:22 <Scrat> ok sipa. so how much does 0.8 fully synced up and started from clean slate weigh right now
10 2013-01-03 00:03:07 <jine> sipa: Ah, i c.
11 2013-01-03 00:03:08 <sipa> Scrat: 5.2 GB
12 2013-01-03 00:04:11 <jine> Scrat: about 600mb less then.
13 2013-01-03 00:04:52 <sipa> 5375800 KiB to be precise
14 2013-01-03 00:04:55 <Scrat> the mode where it just stores the balance would be awesome
15 2013-01-03 00:04:59 <Scrat> oh shit I said balance
16 2013-01-03 00:05:00 <jine> sipa: But that doesn't make sense, if we're going to replace blkindex with something that's ~150mb
17 2013-01-03 00:05:04 <Scrat> ACTION wears chain mail
18 2013-01-03 00:05:09 <sipa> jine: nice catch
19 2013-01-03 00:05:10 <jine> As blkindex currently is about 1.5GB.
20 2013-01-03 00:05:17 <sipa> jine: there's also something called 'undo data'
21 2013-01-03 00:05:30 <sipa> jine: which is necessary to disconnect blocks
22 2013-01-03 00:05:39 <jine> I seriously need to start reading the backlog in this channel + the mailing list :D
23 2013-01-03 00:05:39 <Scrat> "unspent coins" :p
24 2013-01-03 00:05:48 <sipa> as the database only stores the current state, and not the history
25 2013-01-03 00:05:49 <jine> sipa: Ah, i c.
26 2013-01-03 00:06:32 <sipa> undo data is around 8 times smaller than the actual blocks
27 2013-01-03 00:06:44 <sipa> and is really only needed for reorganisation
28 2013-01-03 00:07:33 <sipa> Scrat: having nodes that don't store history isn't a technical problem (it's hardly more than just deleting the block files, in the current code), but there could be repercussions on the network
29 2013-01-03 00:07:54 <sipa> Scrat: as it means new nodes would need a way to find peers that do have history, which won't be just any peer
30 2013-01-03 00:08:05 <Scrat> yeah indeed
31 2013-01-03 00:08:48 <jine> Which in the end would more or less centralize the entire network.
32 2013-01-03 00:09:09 <jine> A few super-nodes with history, and the rest being dummy-clients just trusting them.
33 2013-01-03 00:09:18 <jine> Not so great imo. :)
34 2013-01-03 00:09:19 <sipa> ah, there you're wrong
35 2013-01-03 00:09:21 <etotheipi_> I'm not sure it's exactly like that
36 2013-01-03 00:09:31 <sipa> they don't need to trust the archive nodes at all
37 2013-01-03 00:09:45 <Scrat> jine: well, when the blockchain approaches the TB mark. what then?
38 2013-01-03 00:09:49 <jine> They don't?
39 2013-01-03 00:09:59 <jine> Scrat: By then, lets hope we have cheaper storage? ;)
40 2013-01-03 00:10:01 <sipa> we're still talking about fully validating nodes
41 2013-01-03 00:10:10 <jine> sipa: Ah, my bad then, sorry.
42 2013-01-03 00:10:11 <sipa> they just don't remember history
43 2013-01-03 00:10:37 <sipa> there are other models of course
44 2013-01-03 00:10:38 <Scrat> it will be cheaper for sure. just not following "moore's law"
45 2013-01-03 00:10:59 <sipa> you have SPV nodes, even right now, which don't validate the block data, only block headers
46 2013-01-03 00:11:01 <Scrat> but it will be bigger than anything else you can install on your computer
47 2013-01-03 00:11:09 <etotheipi_> if Bitcoin is still around in 50 years, then nearly every node will be one of these "pruned" nodes
48 2013-01-03 00:11:17 <etotheipi_> they can still do complete validation
49 2013-01-03 00:11:24 <etotheipi_> gracefully forgetting the past as they go
50 2013-01-03 00:11:42 <etotheipi_> and there will be a few nodes that still archive it for various reasons
51 2013-01-03 00:11:50 <etotheipi_> (historians, probably)
52 2013-01-03 00:12:06 <Scrat> well yeah sipa I thought that ultraprune only referred to that (the node that doesn't store history). thanks for the explanation
53 2013-01-03 00:13:00 <Scrat> I mistakenly thought*
54 2013-01-03 00:14:00 <sipa> yeah, that's why i stopped using that name :)
55 2013-01-03 00:18:12 <aethero> Anyone looking for some bounties?
56 2013-01-03 00:19:41 <aethero> https://www.ziggap.com <--- Hack it. Get coins. https://bitcointalk.org/index.php?topic=134386
57 2013-01-03 00:20:00 <dparrish> please do
58 2013-01-03 00:20:02 <jine> aethero: Seems illegal.
59 2013-01-03 00:20:16 <dparrish> nah it's legit ;)
60 2013-01-03 00:20:18 <dparrish> even the frontpage says so
61 2013-01-03 00:20:21 <dparrish> cause i added that text to it
62 2013-01-03 00:20:34 <jine> S?? wait, 10 BTC for each "string"?
63 2013-01-03 00:20:40 <jine> so*
64 2013-01-03 00:20:42 <jine> Whatever that is.
65 2013-01-03 00:20:49 <jine> ACTION gets to work.
66 2013-01-03 00:21:00 <dparrish> yeah they're hidden in places like root's homedir on the servers and in the database
67 2013-01-03 00:21:10 <aethero> No hints parrish :)
68 2013-01-03 00:21:14 <dparrish> there was one that was just text on the ToS page, but that got found quickly
69 2013-01-03 00:21:26 <dparrish> no hints? boo!
70 2013-01-03 00:21:46 <dparrish> ok they're in totally different places to what i just said :p
71 2013-01-03 00:23:43 <jine> I haven't found anything except poor settings so far. :D
72 2013-01-03 00:24:02 <dparrish> poor settings?
73 2013-01-03 00:24:03 <dparrish> tell me omre
74 2013-01-03 00:24:05 <dparrish> more
75 2013-01-03 00:25:26 <lianj> whats the point about auditing if you know the wholes?
76 2013-01-03 00:25:37 <jine> For one, invest a few hours in setting up IDS, blocking external SSH, disabling nginx-version, adding HSTS-header and setup a firewall to block obvious portscans.
77 2013-01-03 00:26:06 <jine> That will fight off a lot of the skiddes.
78 2013-01-03 00:26:41 <jine> Disabling external SSH and similar is a good way to (start) protecting against 0-day sploits.
79 2013-01-03 00:27:20 <dparrish> yeah i will, but right now I *want* people to find vulnerabilities
80 2013-01-03 00:27:33 <dparrish> HSTS header is good one though, i'll do that
81 2013-01-03 00:27:39 <dparrish> and ngnix-version
82 2013-01-03 00:27:54 <jine> Well, if you want to *help* me find vulns, please PM me your root-pwd? ;P
83 2013-01-03 00:27:57 <dparrish> but at the moment, ssh is staying open cause if someone finds a vulnerability there, I want to know about it :)
84 2013-01-03 00:28:01 <dparrish> root pw? i've got no idea
85 2013-01-03 00:28:03 <dparrish> i don't use passwords
86 2013-01-03 00:28:16 <dparrish> key auth only
87 2013-01-03 00:28:29 <jine> Then turn off pwd-auth in sshd.
88 2013-01-03 00:28:30 <jine> :)
89 2013-01-03 00:28:40 <jine> sshd_config to be more precise.
90 2013-01-03 00:28:43 <dparrish> yeah ok :)
91 2013-01-03 00:28:58 <jine> I haven't found anything but poor configuration and settings so far, as i said :P
92 2013-01-03 00:29:11 <jine> I usualy get paid to search, not paid to find :(
93 2013-01-03 00:29:23 <dparrish> heh
94 2013-01-03 00:29:46 <lianj> m(
95 2013-01-03 00:30:02 <dparrish> I *think* we're going to get an external audit done of the code after this bounty phase
96 2013-01-03 00:30:09 <aethero> Yup.
97 2013-01-03 00:30:11 <aethero> We are.
98 2013-01-03 00:30:33 <dparrish> i gtg, back in a few hours
99 2013-01-03 00:31:18 <jine> dparrish: You should.
100 2013-01-03 00:34:59 <jine> Turn on 2-fact auth on your google account to :)
101 2013-01-03 00:37:16 <etotheipi_> sipa: I have no idea if this is persuasive to you, but it most certainly matters for my address-indexed UTXO trees
102 2013-01-03 00:37:18 <jine> Both the @ziggap.com account and the @gmail.com account used as an alt-address.
103 2013-01-03 00:37:55 <etotheipi_> sipa: I just realized that even if I wanted to redownload all the new authentication data for my wallet and redownload all the UTXOs (which is a small download, btw), that's a privacy issue
104 2013-01-03 00:38:43 <etotheipi_> however, if I only do it once, and then simply transition my states from new block data, then I only reveal my addresses the first time I download (which may have been a while ago)
105 2013-01-03 00:39:06 <sipa> etotheipi_: but you were just talking about address-indexed diffs!
106 2013-01-03 00:39:18 <sipa> so you'd have to ask for diffs for particular addresses
107 2013-01-03 00:39:33 <etotheipi_> sipa: yes, I was just talking about that
108 2013-01-03 00:39:42 <etotheipi_> and I'm taking a step back/compromise
109 2013-01-03 00:39:59 <sipa> i should learn to read
110 2013-01-03 00:40:10 <etotheipi_> if instead you just have a two node merkle tree: hash(forwarddata)||hash(backwarddata)
111 2013-01-03 00:40:26 <etotheipi_> then you don't need to do any merkle stuff for that
112 2013-01-03 00:40:28 <etotheipi_> it remains simple
113 2013-01-03 00:40:36 <etotheipi_> but you do enable bulk downloads of just the forward diff data
114 2013-01-03 00:40:50 <etotheipi_> so that lite nodes can update themselves with a fraction of the download, if they don't want to compromise privacy
115 2013-01-03 00:41:03 <sipa> i'm not following
116 2013-01-03 00:41:17 <etotheipi_> my point is that I'm using a lite node because I don't want to download a lot of data
117 2013-01-03 00:41:30 <etotheipi_> downloading 1 MB every 10 min is a lot of data
118 2013-01-03 00:41:45 <sipa> how can a lite node not compromise privacy if it needs to query an address-indexed datastructure remotely?
119 2013-01-03 00:42:02 <etotheipi_> sipa: it only needs to access that address-indexed structure once, a long time ago
120 2013-01-03 00:42:17 <sipa> ok, so you're talking about non-indexed forward diff data
121 2013-01-03 00:42:27 <etotheipi_> it can then "follow the blockchain" afterwards for a fraction of the full block data
122 2013-01-03 00:42:36 <etotheipi_> yes
123 2013-01-03 00:42:52 <etotheipi_> I can synchronize once every night at home
124 2013-01-03 00:43:04 <sipa> "a fraction" here means something like 1/6
125 2013-01-03 00:43:08 <etotheipi_> is it?
126 2013-01-03 00:43:25 <etotheipi_> for some reason I thought it would be more...
127 2013-01-03 00:43:28 <sipa> it means the entire block without txin scripts
128 2013-01-03 00:43:41 <sipa> you need prevouts, txouts, txids
129 2013-01-03 00:44:04 <etotheipi_> err... less
130 2013-01-03 00:44:14 <sipa> how so?
131 2013-01-03 00:44:21 <sipa> ah :D
132 2013-01-03 00:44:25 <etotheipi_> heh
133 2013-01-03 00:44:40 <sipa> i thought you were claiming you needed less
134 2013-01-03 00:45:17 <sipa> ACTION .sleep();
135 2013-01-03 00:45:36 <etotheipi_> sipa: well still think about it
136 2013-01-03 00:45:40 <etotheipi_> I think it 's worth it
137 2013-01-03 00:45:43 <etotheipi_> definitely worth considering
138 2013-01-03 00:46:25 <sipa> etotheipi_: i agree it may be worth considering, but certainly not for this use case
139 2013-01-03 00:47:15 <etotheipi_> sipa: but if you're going to go through the effort of adding blockchain validation rules (like requiring correct undo data digest in coinbase), then you might as well cover current and future usecases
140 2013-01-03 00:47:43 <gmaxwell> etotheipi_: thats not actually what he's talking about right now.
141 2013-01-03 00:47:58 <etotheipi_> gmaxwell: I thought that was the ultimate goal of it
142 2013-01-03 00:48:17 <gmaxwell> AFAIK sipa's current concern is the on disk format for the undo data, as he didn't want a format which precluded network transmission of it.
143 2013-01-03 00:48:19 <etotheipi_> sipa: go to sleep, I'll bug gmaxwell about it
144 2013-01-03 00:48:21 <etotheipi_> :)
145 2013-01-03 00:49:49 <sipa> etotheipi_: you're proposing several things (forward and backward data, indexed in a tree or not, merkleized or not), and several use cases that use several combinations
146 2013-01-03 00:50:45 <sipa> etotheipi_: if you're going to push for all combinations that may be useful at some point, it's going to cost more than just trying to cover the cases where it actually may give a significant advantage (sorry, a constant factor compressed on-the-wire is hardly worth it, imho)
147 2013-01-03 00:51:45 <etotheipi_> sipa: it's not all combinations... it's accommodating a use case that's clearly, feasibly useful
148 2013-01-03 00:52:03 <sipa> etotheipi_: if you only have a merkleized indexed forward diff (which is already duplication), and go for the use case you present here, they'll need to download the prevouts/txouts/txids data + address index + tree overhead + merkle data; i'm not even sure that will be smaller than the original block in the first place
149 2013-01-03 00:52:26 <sipa> so you do need a different version of the system for the use case you described now, w.r.t the one you described earlier
150 2013-01-03 00:52:38 <gmaxwell> I think the thinking that got us to this discussion: We need validation of the utxo database to prevent silent failure. One way to do that would be to undo and redo the last N blocks at start, if the db is broken we'll likely discover that for enough N. But for that we need to know if the undo data is reliable, it ought to have a checksum/hash. If it has one it would be good if that hash could be shared over the network and potentially commit
151 2013-01-03 00:52:54 <gmaxwell> Out of that very narrow use case, you're talking about boiling the oceans by comparison. :)
152 2013-01-03 00:53:49 <etotheipi_> sipa: I see your point about a constant factor of 1/6... but is that not useful nonetheless?
153 2013-01-03 00:53:54 <etotheipi_> the cost seems absolutely trivial
154 2013-01-03 00:54:09 <gmaxwell> on a related subject, my confidence in the viability of committed utxo sets is also starting to falter generally. :( My thinking previously was that they could be made close enough to free (other than software complexity) that they've be viable as enforced network rules and thus trustworthy.
155 2013-01-03 00:54:57 <etotheipi_> I'm not connecting to your previous comment... downloading an address-indexed DB is not part of this discussion -- whether you're operating with a full chain, lite chain, gray-node partial chain.... it's still 83% compression of data to transfer
156 2013-01-03 00:55:25 <etotheipi_> I mean, it's not specific to address-indexed DB... it could be any lite/pruned node
157 2013-01-03 00:55:48 <gmaxwell> But on further reflection I realized that the UTXO set can??? in theory??? by partitioned fixed size hash tables that have almost no overhead and O(1) lookup near O(1) updates. No merkelized structure can be anywhere near as cheap.
158 2013-01-03 00:56:40 <sipa> etotheipi_: someone who maintains a fully validating node, needs the full blocks anyway
159 2013-01-03 00:56:44 <etotheipi_> gmaxwell: I don't follow
160 2013-01-03 00:56:45 <gmaxwell> especially if you wanted things like address ordered structure _and_ txid ordered structure. I don't know that making full nodes much much more expensive to run fundimentally can be justified by making semifull nodes possible. :(
161 2013-01-03 00:58:11 <etotheipi_> gmaxwell: I agree it won't be free for the full-node to operate it
162 2013-01-03 00:58:21 <etotheipi_> but I think the benefit is epic, and shared by all nodes
163 2013-01-03 00:59:07 <sipa> etotheipi_: talking about an at-most-constant-factor benefit for some hypothetical mode of operation in some future, with unclear ideas about the priorities and problems at that point... no
164 2013-01-03 00:59:13 <etotheipi_> new users no longer have to compromise between security and convenience... you can now import a new wallet with 100 address for 250kB download
165 2013-01-03 00:59:33 <etotheipi_> sipa: I don't see why it's hypothetical
166 2013-01-03 00:59:38 <sipa> etotheipi_: inho, a new user shouldn't need to import a wallet in the first placwe
167 2013-01-03 00:59:40 <gmaxwell> Even a constant factor inefficiency isn't bad, but this isn't a constant factor cost. It turns things from O(1) ish time complexity into O(ln txouts)*(constant factor) time complexity.
168 2013-01-03 00:59:50 <sipa> he creates a new wallet, and perhaps sends some coins to it
169 2013-01-03 01:00:19 <sipa> etotheipi_: that's what i mean by hypothetical
170 2013-01-03 01:00:25 <etotheipi_> sipa: you no longer has to search the blockchain for your transactions
171 2013-01-03 01:00:40 <etotheipi_> you don't have to worry about missing things between booting (unless you consider my privacy issue and download diff data instead)
172 2013-01-03 01:00:56 <sipa> etotheipi_: yes, that's a measly benefit if nobody needs to search the blockchain in the first place
173 2013-01-03 01:01:03 <sipa> not saying it's one way or another
174 2013-01-03 01:01:06 <sipa> i don't know the future
175 2013-01-03 01:01:17 <sipa> i'm just saying that we don't know how things will be used in the future
176 2013-01-03 01:02:04 <gmaxwell> sipa: you should sleep.
177 2013-01-03 01:02:10 <sipa> yeah :p
178 2013-01-03 01:02:13 <etotheipi_> gmaxwell: technically, if you're using a trie-based structure, it's O(1)
179 2013-01-03 01:02:24 <grau> may i jump in guys ?
180 2013-01-03 01:02:27 <gmaxwell> etotheipi_: storage, not access latency.
181 2013-01-03 01:02:31 <etotheipi_> oh
182 2013-01-03 01:02:53 <etotheipi_> so it's O(NlogN) instead of O(N)
183 2013-01-03 01:03:57 <gmaxwell> For N operations, yea. well N log M (M being the txo set size) vs O(N) (plus constant factors)
184 2013-01-03 01:04:16 <etotheipi_> what's up, grau?
185 2013-01-03 01:04:42 <grau> i should also better sleep, but wake up with the question you might be able to answer
186 2013-01-03 01:04:49 <grau> should i continue?
187 2013-01-03 01:04:56 <gmaxwell> We'll be here later too.
188 2013-01-03 01:04:59 <grau> with what I did
189 2013-01-03 01:05:35 <grau> i spent most of my free time a bit of my health and a lot of my family on this for months
190 2013-01-03 01:05:49 <grau> i received lots of headwind and learned a lot
191 2013-01-03 01:06:04 <grau> now i am asking if is should continue...
192 2013-01-03 01:06:38 <gmaxwell> grau: people seem interested in your work??? that said, holy crap, don't let working on anything bitcoin adversely impact your health!
193 2013-01-03 01:06:48 <etotheipi_> grau, I can sympathize a bit
194 2013-01-03 01:06:59 <etotheipi_> but it's mostly just "family", not so much health
195 2013-01-03 01:07:37 <etotheipi_> I don't know exactly what you're discomforts are, but if it's rewarding for you, do it
196 2013-01-03 01:07:52 <etotheipi_> my own advice on it is this: I have spent tons of time on Armory
197 2013-01-03 01:08:07 <etotheipi_> and I'm constantly anxious to fix every bug and implement every feature directly in front of me
198 2013-01-03 01:08:17 <etotheipi_> and I neglect my (now-)fiance
199 2013-01-03 01:08:31 <etotheipi_> and don't visit my parents as much as I should
200 2013-01-03 01:08:52 <grau> thanks a lot
201 2013-01-03 01:08:55 <etotheipi_> two things changed that (1) Talking to them about it -- they know I'm an OCD kinda person and I'm doing something I like, we compromise
202 2013-01-03 01:09:24 <grau> bye
203 2013-01-03 01:09:26 <etotheipi_> (2) I realized that these things actually aren't critical... that feature I could change in 1 hour... it can wait a day or two and really no one will be affected
204 2013-01-03 01:09:51 <etotheipi_> ...okay
205 2013-01-03 01:10:49 <etotheipi_> did I say something wrong?
206 2013-01-03 01:11:01 <sipa> i think he just went to sleep :)
207 2013-01-03 01:11:16 <etotheipi_> or am I just a terrible at supporting stressed out people?
208 2013-01-03 01:11:27 <etotheipi_> sipa: what are you doing still here?
209 2013-01-03 01:11:36 <sipa> a good question
210 2013-01-03 01:11:39 <etotheipi_> :)
211 2013-01-03 01:12:10 <etotheipi_> meh, I guess I'm looking at Bitcoin with from the eyes of usability, and wondering how these "hypothetical" features *won't* be used
212 2013-01-03 01:12:13 <etotheipi_> this seems like the future to me
213 2013-01-03 01:13:02 <etotheipi_> and by future, I mean, Bitcoin's long-term future could depend on making almost-full-security lite nodes, and minimizing the data to sync
214 2013-01-03 01:15:42 <etotheipi_> there certainly won't be much bitcoin future (at least in the direct consumer market) with Bitcoin-Qt as-is
215 2013-01-03 01:16:17 <sipa> there's little doubt about that :)
216 2013-01-03 01:16:52 <etotheipi_> maybe reduced-security lite nodes are sufficient for the world to embrace it
217 2013-01-03 01:17:38 <sipa> people are fleeing to blockchain.info and electrum already... i wish they'd flee to SPV nodes instead
218 2013-01-03 01:18:18 <gmaxwell> electrum is at least closer to spv now.
219 2013-01-03 01:18:23 <sipa> true
220 2013-01-03 01:19:04 <etotheipi_> if we had started with this authenticated, address-indexed UTXO, I don't think we'd be having this discussion
221 2013-01-03 01:19:09 <gmaxwell> it needs more review and more strenghtening still, I'm sure... but at least thats better. My concern is is that I think webwallets are outpacing electrum substantially still.
222 2013-01-03 01:19:19 <etotheipi_> armory, eletrum and others would be using this
223 2013-01-03 01:19:24 <etotheipi_> and wouldn't have to centralize
224 2013-01-03 01:19:27 <gmaxwell> I'm absolutely sure that you're ont right there.
225 2013-01-03 01:19:38 <gmaxwell> 'cause otherwise it would just electrum vs spv.
226 2013-01-03 01:20:12 <etotheipi_> gmaxwell: what do you mean?
227 2013-01-03 01:20:22 <gmaxwell> And it's not... blockchain.info got like 40k additional wallet accounts last month or something crazy like that.
228 2013-01-03 01:21:01 <gmaxwell> etotheipi_: electrum already has all the usability advantages you're hoping for there (at lower bandwidth costs too), and its not the most popular option by far.
229 2013-01-03 01:21:05 <jine> dparrish: Talk wth aethero later, and ask me if you have any questions about what i found. :) (No, no security issues, just inconsistencies)
230 2013-01-03 01:22:39 <etotheipi_> gmaxwell: I don't thing that's a meaningful metric
231 2013-01-03 01:22:41 <jine> I just found that I'm missing a feature in firebug. I want to export something from the network-tab with http-requests. Is that really impossible? :(
232 2013-01-03 01:22:50 <jine> I hate when this happens :P
233 2013-01-03 01:23:17 <gmaxwell> etotheipi_: it's the "would we be having this discussion" metric, I think.
234 2013-01-03 01:23:29 <etotheipi_> gmaxwell: the point is that there would be "no need" for electrum
235 2013-01-03 01:23:38 <etotheipi_> not to say we don't need alt clients
236 2013-01-03 01:24:01 <etotheipi_> but the benefits that it touts would be available without having to centralize anything
237 2013-01-03 01:24:10 <gmaxwell> etotheipi_: I know, but that wouldn't address sipa's point. Electrum is less of a concern than sipa was crediting it for being in any case.
238 2013-01-03 01:25:13 <gmaxwell> etotheipi_: yes, and it doesn't matter, because people are choosing a fully centeralized solution over electrum which is almost decenteralized (it just trusts the servers to not DOS attack it by hiding transactions, and not to network isolate it from hearing the longest chain headers)
239 2013-01-03 01:26:02 <etotheipi_> gmaxwell: to make sure we're talking about the same thing... I thought electrum came with pre-hardcoded servers that were to be trusted
240 2013-01-03 01:27:16 <gmaxwell> etotheipi_: I raised hell, electrum was improved. Electrum is now a SPV client which has a list of servers that it uses because they can do fast by-address queries for it. (they also give it the headers)
241 2013-01-03 01:27:35 <gmaxwell> (previously they were fully trusted for everything except the private keys, and the communication was all cleartext too)
242 2013-01-03 01:28:15 <etotheipi_> okay... I still wouldn't call that decentralized
243 2013-01-03 01:28:43 <gmaxwell> I think the https is still unauthenticated, and it doesn't consult multiple sources to make sure its on the longest chain, etc.. still room to improve. And the index is subject to dos attack through false negative responses.
244 2013-01-03 01:29:26 <gmaxwell> But it won't take much to improve it greatly (E.g. consult multiple sources, blacklist ones that hid data). Not as good as what you want.. but not so bad.
245 2013-01-03 01:29:51 <gmaxwell> Meanwhile people choose webwallets over it on a massive scale.
246 2013-01-03 01:30:46 <gmaxwell> Users do not care about security because their metric for security is something like "have I heard of anyone getting ripped off this way yet". It's just no something most people use in picking an option.
247 2013-01-03 01:31:29 <etotheipi_> gmaxwell: some people
248 2013-01-03 01:32:28 <etotheipi_> gmaxwell: I'm thinking... and it's an interesting philosophical discussion
249 2013-01-03 01:32:35 <gmaxwell> evidence suggests most??? besides security is a lemon market. It's really costly to figure out this stuff when it's not totally secret (as it often is on centeralized things)
250 2013-01-03 01:32:38 <etotheipi_> I'll have to ponder this...
251 2013-01-03 01:33:18 <etotheipi_> I do agree that there is a large market for webwallets
252 2013-01-03 01:33:31 <etotheipi_> but to me, it feels like "linux"
253 2013-01-03 01:33:35 <gmaxwell> plus as you may have noticed, it's a lot easier to monetize a centeralized service than it is for distributed software??? better funding means more polish which is often a proxy for security.
254 2013-01-03 01:33:37 <etotheipi_> sure, you don't have Linux on the desktop
255 2013-01-03 01:33:46 <etotheipi_> but the world relies on it
256 2013-01-03 01:34:09 <etotheipi_> it still benefits us to improve the baseline kernel, even if yo udon't have a linux machine sitting at home
257 2013-01-03 01:34:26 <gmaxwell> Part of what inspired me to go beat on poor thomasv was that he made a merchant/daemon version of electrum and people started rapidly picking it up.
258 2013-01-03 01:35:08 <gmaxwell> Someone was telling at someone else in #bitcoin earlier that if you want to accept bitcoin on your website you're a fool not to use an API (meaning one of the centeralized services).
259 2013-01-03 01:35:19 <Scrat> :)
260 2013-01-03 01:35:24 <gmaxwell> But sure, I agree, good infrastructure is good even if regular users don't use it... but does bitcoin use its point?
261 2013-01-03 01:35:32 <gmaxwell> Yea, it was Scrat doing that! :P
262 2013-01-03 01:35:39 <gmaxwell> s/use/lose/
263 2013-01-03 01:36:04 <etotheipi_> gmaxwell: part of Bitcoin is "choice"
264 2013-01-03 01:36:14 <gmaxwell> 'cause it's going to be a bloodbath when some overzealous regulator shuts down blockchain.info because they don't like its integrated laundering service or whatever.
265 2013-01-03 01:36:27 <etotheipi_> it doesn't preclude people using third-parties, it is about the fact that people have another option than using third parties
266 2013-01-03 01:36:32 <gmaxwell> etotheipi_: note I don't suggest forbidding things (Even if it were possible)....
267 2013-01-03 01:36:32 <lianj> gmaxwell: if you dont want to care or handle and secure a bitcoin process just to accept bitcoins, youre a fool not to use an api
268 2013-01-03 01:36:59 <etotheipi_> and using a single data point in time "right now people are flocking to webwallets" is not sufficient for claiming that the world will only use them forever
269 2013-01-03 01:37:00 <gmaxwell> lianj: our community is 'fools' that we haven't made a foolproof decenteralized solution easy.
270 2013-01-03 01:37:37 <etotheipi_> it certainly wouldn't hurt to have a client option that has virtually no download requirement and gives them everything they need
271 2013-01-03 01:37:46 <gmaxwell> lianj: everyone using a small set of API's is an impending receipy for disaster. I'm not aware of a _single_ bitcoin bank like service which is independantly audited and insured for their business, not to mention the large regulatory oversight risk.
272 2013-01-03 01:38:23 <gmaxwell> etotheipi_: well thats why electrum's option was interesting, and why it worred me that it was needlessly insecure. Fortunately thats been improved.
273 2013-01-03 01:38:29 <Scrat> but this is easy to solve (relatively). just a few callbacks on bitcoind. this isn't a protocol rework that does your head in
274 2013-01-03 01:38:33 <lianj> if person x runs his webshop, god forbid even in php, and WE want him to also accept bitcoin, he will prolly not setup anything even if it if so easy
275 2013-01-03 01:38:55 <gmaxwell> etotheipi_: they won't use them forever, they'll use them until the next massive adverse event... and the question is after that how many of them will use bitcoin at all? :P
276 2013-01-03 01:39:00 <Scrat> php sucks so much dick for async stuff it ain't even funny
277 2013-01-03 01:39:39 <lianj> gmaxwell: would a insurance make you feel better? for a third party wallet service?
278 2013-01-03 01:39:50 <gmaxwell> lianj: having easy to deploy infrastructure (and well communicated standards and best practices) also means that there can be more diversity in centeralized api options, which also would reduce the systemic risk.
279 2013-01-03 01:40:24 <etotheipi_> gmaxwell: I just feel it's being treated as a black-and-white problem... because grandma won't download an app to her phone means it's not worth optimizing that case... and this isn't optimizing a case, this is optimizing the baseline interaction with the network
280 2013-01-03 01:40:26 <gmaxwell> lianj: I think independant auditing is more important than insurance, but insurance can be helpful too... but it's something the I think we're too immature to really have now.
281 2013-01-03 01:40:26 <lianj> true
282 2013-01-03 01:41:05 <gmaxwell> etotheipi_: part of what sipa was pointing out though was that your optimization was not free at all. It would create a lot of computational and storage redundancy for full nodes.
283 2013-01-03 01:41:23 <gmaxwell> So if the case it helps is rare and not helped much, and the cost it imposes is common it may be a net loss.
284 2013-01-03 01:41:56 <etotheipi_> gmaxwell: we both understand cost-to-benefit... we just disagree about the costs and benefits and the source of that disagreement
285 2013-01-03 01:42:04 <gmaxwell> Esp since you can still build non-committed electrum like servers to answer queries... so the benefit you need to compare to is the benefit over that.
286 2013-01-03 01:42:34 <etotheipi_> gmaxwell: thanks... this is all great food for thought
287 2013-01-03 01:42:38 <gmaxwell> (and the non-committed case at least has the benefit that no one is forced into running one just to make queries cheap for people who choose not to)
288 2013-01-03 01:42:42 <gmaxwell> yea, mee too.
289 2013-01-03 01:42:55 <etotheipi_> I will get back to Armory development
290 2013-01-03 01:43:08 <etotheipi_> and I'm sure I'll have revelations about this as I'm falling asleep 3 nights from now
291 2013-01-03 01:43:14 <gmaxwell> :P
292 2013-01-03 01:43:14 <Scrat> whats the gist?
293 2013-01-03 01:43:18 <Scrat> are light clients evil?
294 2013-01-03 01:43:58 <etotheipi_> Scrat: it's just a debate about cost of improving lite clients vs the benefit (which gmaxwell says is not much, because people just use third-parties, anyway)
295 2013-01-03 01:44:15 <etotheipi_> (it's not quite that simple, but it's the gist)
296 2013-01-03 01:45:49 <gmaxwell> well, over which of an infinite number of ways of improving lite clients best justfiy their costs.
297 2013-01-03 01:46:08 <gmaxwell> E.g. the electrum way improves lite clients but it does so with less security than a committed address index on every full node does.
298 2013-01-03 01:46:38 <gmaxwell> But OTOH, the latter imposes costs on every full node (debatable how much) while the former is purely opt in.
299 2013-01-03 03:04:44 <paybitcoin> hello
300 2013-01-03 03:04:50 <paybitcoin> does anyone have any testnet coins?
301 2013-01-03 03:05:07 <paybitcoin> that they could send me, maybe?
302 2013-01-03 03:08:00 <etotheipi_> paybitcoin: sure
303 2013-01-03 03:08:04 <etotheipi_> send me a testnet addr
304 2013-01-03 03:08:08 <paybitcoin> oooh yay
305 2013-01-03 03:08:17 <paybitcoin> mwPdgnjfq1WGPmTJwSSEcyukp5ZJ2oucFX
306 2013-01-03 03:08:35 <paybitcoin> just about to try to figure out how to turn on CPU mining :/
307 2013-01-03 03:08:56 <etotheipi_> been there, done that :)
308 2013-01-03 03:14:52 <paybitcoin> just got it, thanks!!!
309 2013-01-03 03:20:07 <jgarzik> 0.8-~3-weeks: 15695 jgarzik 39 19 1847m 823m 22m S 103.0 10.6 37255:27 bitcoind
310 2013-01-03 03:20:13 <jgarzik> 0.7.1-something: 1069 jgarzik 39 19 1523m 582m 2672 S 13.7 10.2 5517:50 bitcoind
311 2013-01-03 03:20:48 <jgarzik> 0.8.~3-weeks: 4437 jgarzik 39 19 3245m 1.7g 15m S 98.8 43.7 37538:18 bitcoind
312 2013-01-03 03:21:03 <jgarzik> latter surprisingly large
313 2013-01-03 03:21:38 <jgarzik> both 0.8* have ~100 connections
314 2013-01-03 03:56:29 <MobPhone> gmaxwell did you get the file
315 2013-01-03 03:56:41 <MobPhone> my chain is still going lol
316 2013-01-03 05:05:52 <jine> paybitcoin: Need more testnet coins, just tell me. :)
317 2013-01-03 06:11:29 <gladoscc> OK, I get the No information available about transaction error... when I call listtransactions(50).
318 2013-01-03 06:15:07 <gladoscc> More concerning is that I deleted wallet.dat to start afresh and it did not automatically generate a new wallet.dat ???
319 2013-01-03 06:16:14 <stealth222> what version are you using?
320 2013-01-03 06:18:49 <gladoscc> 0.7.2
321 2013-01-03 06:18:53 <gladoscc> not 0.8
322 2013-01-03 06:19:05 <stealth222> what does the debug.log say?
323 2013-01-03 06:19:53 <gladoscc> noting useful, a truckload of ACCEPTED
324 2013-01-03 06:19:58 <stealth222> before that
325 2013-01-03 06:20:02 <stealth222> when you first start it up
326 2013-01-03 06:20:36 <stealth222> it shouldn't even get to the network if it can't find or recover a wallet.dat
327 2013-01-03 06:20:50 <gladoscc> oh, I just realized I was checking in root's home folder
328 2013-01-03 06:20:53 <gladoscc> I still have a wallet.dat
329 2013-01-03 06:21:06 <gladoscc> but the problem is listtransactions returns an error..
330 2013-01-03 06:21:12 <stealth222> what's the error?
331 2013-01-03 06:21:20 <gladoscc> No information available about transaction
332 2013-01-03 06:21:36 <stealth222> what was the exact command you entered?
333 2013-01-03 06:23:25 <gladoscc> listtransactions "myaccount" "50"
334 2013-01-03 06:28:05 <stealth222> are you sure you're using listtransactions and not listrawtransaction?
335 2013-01-03 06:29:19 <gladoscc> yes
336 2013-01-03 06:29:59 <stealth222> listtransactions doesn't return that error. listrawtransaction does
337 2013-01-03 06:30:38 <gladoscc> but I *am* calling listtransactions
338 2013-01-03 06:30:55 <stealth222> what happens if you call listtransactions with a txid as a parameter?
339 2013-01-03 06:31:10 <gladoscc> Wait
340 2013-01-03 06:31:14 <gladoscc> Does getrawtransaction return this error?
341 2013-01-03 06:31:17 <stealth222> yes
342 2013-01-03 06:31:55 <gladoscc> Ok, then it is getrawtransaction then. I'm calling those via PHP so I guessed it was listtransactions based on when the Fatal error occurred, and uncommenting that stopp dthe error.
343 2013-01-03 06:32:08 <gladoscc> so, I'm calling getrawtransaction on a txid returned by listtransactions.
344 2013-01-03 06:32:40 <gladoscc> the txid exists.
345 2013-01-03 06:33:27 <stealth222> put some tracers in the code and display the txid on which it is giving you the error
346 2013-01-03 06:34:43 <gladoscc> I don't think the actual transaction is the problem, I can query it fine on blockchain.info
347 2013-01-03 06:34:53 <gladoscc> corrupted blockchain?
348 2013-01-03 06:35:26 <gladoscc> I have already deleted the blockchain so it redownloads, but I somehow have the balance BEFORE the blockchain is fully downloaded
349 2013-01-03 06:38:29 <gladoscc> deleted wallet.dat properly, seems to work now
350 2013-01-03 15:50:23 <gavinandresen> Dev team: I'm trying again to get more QA testing happening, feedback appreciated: http://tinyurl.com/a5nukqy
351 2013-01-03 16:10:32 <jgarzik> http://www.wired.com/threatlevel/2013/01/coder-charged-for-gambling-software/
352 2013-01-03 16:16:50 <Luke-Jr> wow
353 2013-01-03 16:19:09 <gmaxwell> lemme guess: new york, right
354 2013-01-03 16:19:10 <gmaxwell> ?
355 2013-01-03 16:19:46 <kinlo> americans are so stupid, that's the first reaction that I get from reading such articles
356 2013-01-03 16:19:47 <Luke-Jr> right ;)
357 2013-01-03 16:22:11 <Luke-Jr> "Stuart has tried to obtain a copy of the affidavit used to get the search warrant, but it's currently sealed." <-- wtf?
358 2013-01-03 16:22:12 <helo> oklahoma has similar laws
359 2013-01-03 16:22:30 <helo> but there aren't many programmers there
360 2013-01-03 16:22:36 <gavinandresen> wow, I think I'll have to put a google alert on"Robert Stuart" and keep track of what happens....
361 2013-01-03 16:23:09 <TD> who is this?
362 2013-01-03 16:23:32 <TD> http://www.dayonepatch.com/index.php?/topic/73898-write-gambling-software-go-to-prison/
363 2013-01-03 16:23:45 <Luke-Jr> [17:10:57] <jgarzik> http://www.wired.com/threatlevel/2013/01/coder-charged-for-gambling-software/
364 2013-01-03 16:24:11 <Luke-Jr> kinlo: there are stupider things going on elsewhere in the world too <.<
365 2013-01-03 16:24:40 <gmaxwell> Luke-Jr: go look at the ACLU appelbaum filings (the few that aren't themselves sealed)??? NY district courts have a problem with overly sealing stuff and even failing to docket the sealed documents. I expect they're eventually going to get beaten down by the US supreme court, but it'll probably be years before that happens.
366 2013-01-03 16:24:41 <kinlo> true, it's not to particularly pinpoint the americans :)
367 2013-01-03 16:24:51 <kinlo> but still, I get that feeling :p
368 2013-01-03 16:25:18 <TD> "He says the New York district attorney???s office tried to strong-arm him into a plea agreement that would have had him hacking into the systems of his software clients in order to obtain the usernames and passwords of gamblers "
369 2013-01-03 16:25:33 <TD> wtf
370 2013-01-03 16:25:42 <TD> the US is going downhill
371 2013-01-03 16:25:51 <Luke-Jr> TD: you just realized this? :P
372 2013-01-03 16:25:59 <TD> not at all. just bears repeating.
373 2013-01-03 16:26:01 <TD> each step along the way
374 2013-01-03 16:26:26 <gmaxwell> kinlo: I don't agree. For all the dumb things we have in america, we also get a lot of things deeply right. For example we actually regard freedom of speech as an actual right. This is distinct from many developed nations (e.g. the UK) and has profound policy and practice impacts.
375 2013-01-03 16:26:38 <andytoshi> TD: watch what happens when the US federal government's currency has real competition
376 2013-01-03 16:26:44 <andytoshi> i bet they get their act together real quick
377 2013-01-03 16:26:52 <andytoshi> (though new york is maybe a lost cause)
378 2013-01-03 16:27:03 <TD> hardly
379 2013-01-03 16:27:11 <andytoshi> there's no bitcoinistan to invade
380 2013-01-03 16:27:15 <TD> the USG wipes its ass with the constitution. what was ITAR and EAR about if not direct censorship of cryptographers
381 2013-01-03 16:27:30 <TD> when the courts struck down ITAR as unconstitutional, it was simply re-passed again under a new name
382 2013-01-03 16:27:35 <MC-Eeepc> greg is right
383 2013-01-03 16:27:37 <gmaxwell> TD: ITAR was quite comfortably dismantled by the courts for that reason.
384 2013-01-03 16:27:46 <rozani> greg is a freak
385 2013-01-03 16:28:07 <kinlo> gmaxwell: I'm not going to discuss things in depth here, but I feel there are plenty of examples where your freedom of speech really is not honored
386 2013-01-03 16:28:13 <TD> i don't think a process whereby the legislature routinely passes blatantly un-constitutional laws and then dares people to take them on is "deeply right". they know full well only 1% of supreme court cases get actually heard
387 2013-01-03 16:28:14 <MC-Eeepc> here the local university to me just formally issued a warning over posting drunken shenanigans on facebook, lest it affect your career or even get you arrested
388 2013-01-03 16:28:18 <gmaxwell> TD: and meanwhile but AU and NZ copied the ITAR restrictions word for word without copying the caselaw, and don't have the underling basis in right to overturn them on their own.
389 2013-01-03 16:28:24 <andytoshi> MC-Eeepc: greg is very right ... you should see the anti-speech travesties we have in canada
390 2013-01-03 16:28:45 <andytoshi> we have actual federal bodies called "human rights tribunals", which run their own kangaroo courts
391 2013-01-03 16:28:56 <andytoshi> to prosecute people who say bad things about islam
392 2013-01-03 16:29:15 <andytoshi> they have their own laws, appoint their own people, attack whoever they want
393 2013-01-03 16:29:26 <TD> sounds a lot like financial regulators :)
394 2013-01-03 16:29:35 <gmaxwell> TD: a lot of things (including ITAR) get fixed by district courts. And the supreme court not taking a case just as well upholds a lower court ruling. Everything above a trial court makes binding precedent. (thoug the scope of the binding increases as you go up)
395 2013-01-03 16:29:53 <andytoshi> TD: yes, my point :) the problems in the US seem to me to be caused (nearly) exclusively by cheap money
396 2013-01-03 16:29:55 <TD> well, i hope this case gets struck down by the courts
397 2013-01-03 16:30:06 <rozani> go hit up craigslist, greg, and you might find someone who will at least pretend to be human for you
398 2013-01-03 16:30:32 <gmaxwell> I'm certantly not arguing that it's all well and good, it's just important to also reconize that there are balances and many places are worse.
399 2013-01-03 16:30:36 <TD> sure
400 2013-01-03 16:30:40 <gavinandresen> TD: unfortunately, if it looks like he'll win they will most likely drop the case so there is no firm precedent
401 2013-01-03 16:31:03 <MC-Eeepc> charged with promoting gambling in New York because authorities say his software was used by others for illegal betting in that state.
402 2013-01-03 16:31:04 <TD> ah yes. that seems to be distressingly routine. i was pointed to the case "saleh vs the us treasury" the other day. it ended the same way.
403 2013-01-03 16:31:10 <MC-Eeepc> oh boy oh boy
404 2013-01-03 16:31:13 <MC-Eeepc> thats very interesting
405 2013-01-03 16:31:17 <gavinandresen> ... just the chilling effect of maybe the next guy having to hire lawyers and spend lots of money to defend himself
406 2013-01-03 16:31:17 <MC-Eeepc> very interesting indeed
407 2013-01-03 16:31:50 <TD> sometimes i wonder if the AML laws are building what is functionally equivalent to censorship of speech, just operating on a different level. if you look at how the AML infrastructure works it can be compared quite closely to the chinese firewalls. there are keyword stoplists applied to wire transfers, etc.
408 2013-01-03 16:32:04 <gmaxwell> MC-Eeepc: his life is made less fun there by the fact that his income there was fairly remarkable for just a software developer. No doubt the prosecutors believe him to be a business partner who was 'only a developer' only on paper.
409 2013-01-03 16:32:17 <TD> a bit like that scene from the matrix, "what use is free speech, if you cannot ???.. organize"
410 2013-01-03 16:32:39 <MC-Eeepc> TD thats why were here bro lol
411 2013-01-03 16:32:57 <gmaxwell> TD: yes. money really is speech too. I'm made sad about people bitching about citizen's united, not because it wasn't a crappy case but because they're making crappy arguments against it.
412 2013-01-03 16:33:18 <MC-Eeepc> also pertintent since money has been ruled to indeed be speech in the US
413 2013-01-03 16:33:19 <andytoshi> TD: we've won the encryption fight, thanks to the clinton adminstration. what we need to do now is popularize it
414 2013-01-03 16:33:36 <TD> yeah. i've debated citizens united with a guy i work with a few times. same thing. the outcome seems so suboptimal but the arguments against it are poor, so the solution must lie elsewhere (delegated voting, or whatever)
415 2013-01-03 16:34:13 <MC-Eeepc> what are the bad arguments?
416 2013-01-03 16:34:18 <gmaxwell> TD: I try to get people to read the ruling and the dissent, its quite thouhtful.
417 2013-01-03 16:34:19 <gavinandresen> I wonder if the left would like citizens united more if it was a group spending money on a Bush-bashing movie (instead of a Clinton-bashing movie)
418 2013-01-03 16:34:22 <TD> the NY DA really sounds out of control in this article. quite amazing.
419 2013-01-03 16:35:04 <gmaxwell> TD: yes, NY DA being out of control (and especially agressive wrt gambling) is well know, this is what made me surprised about the location of some bitcoin site owners???
420 2013-01-03 16:35:25 <gmaxwell> (specific bitcoin site owners, I'm not saying bitcoin in general of course)
421 2013-01-03 16:35:32 <gavinandresen> NY is the financial capital of the US.... for better or worse.
422 2013-01-03 16:35:33 <TD> indeed
423 2013-01-03 16:35:37 <TD> i was thinking the same thing
424 2013-01-03 16:35:48 <TD> fireduck is in the UK, i think, but not the owners
425 2013-01-03 16:36:07 <gmaxwell> (NY has a very long and complicated history with gambling)
426 2013-01-03 16:36:51 <gmaxwell> MC-Eeepc: the bad arguments are the strawmen ones where people make fun of the imposition that money is speech and that corporations are people as though they are insane and obviously false positions.
427 2013-01-03 16:37:24 <TD> MC-Eeepc: the basic issue is the one we just stated ?????? if you can "speak" but the finance you need to actually make that speech heard is illegal, then do you really have freedom of speech?
428 2013-01-03 16:37:33 <TD> MC-Eeepc: if a tree falls in the forest and nobody hears it, etc
429 2013-01-03 16:37:48 <gavinandresen> I think we'll see a shift in attitude in the US towards gambling over the next 10-20 years. Mostly because I know lots of old people who love to go to casinos, and as they get older I bet they'll want casinos closer to home.
430 2013-01-03 16:37:54 <gavinandresen> ... or in their homes....
431 2013-01-03 16:37:59 <gmaxwell> MC-Eeepc: but they aren't false positions??? there is a need for balancing, but if you take the position that money is never speech and corporations never have the rights of people, then you deny people the ability to organize and effectively communicate. "You have free speech, but we're going to make sure you're alone and broke so your speech is powerless"
432 2013-01-03 16:38:33 <MC-Eeepc> yeah ok
433 2013-01-03 16:38:37 <TD> MC-Eeepc: so the bad argument was something like, "lots of money in politics is distorting our democracy" (this may or may not be the case, but let's assume it's true) ???. "therefore we must regulate the use of money for political speech"
434 2013-01-03 16:38:49 <TD> MC-Eeepc: there's a genuine problem there, but the solution being proposed is not the correct one.
435 2013-01-03 16:38:56 <MC-Eeepc> but the reality is that the legislature is shot through with corporate money and works about as ell as youd expect
436 2013-01-03 16:39:16 <TD> in that sense, I guess I agree with gmaxwell that the USA came to the right conclusions in that case. the judicial system is one area where (outside of patent litigation), I still have some confidence
437 2013-01-03 16:39:20 <gavinandresen> TD: <gavin puts on an occupy tinfoil hat> Exactly! the solution is to get rid of money!
438 2013-01-03 16:39:23 <TD> haha
439 2013-01-03 16:39:28 <TD> like in star trek
440 2013-01-03 16:39:33 <MC-Eeepc> if money is speech and the answer to speech is more speech from elsewhere......
441 2013-01-03 16:39:36 <gmaxwell> But at the same time you shouldn't let the richest players saturate the media using all their money so that only they have a voice... so it makes sense to have some kind of balancing act. So that much is good, but you can't define a good balance if you're busy calling people evil for saying that free speech need free(dom) for money too.
442 2013-01-03 16:39:38 <TD> "how was the Enterprise funded? oh, we don't have money here in the future. we just decided to do it"
443 2013-01-03 16:40:10 <gmaxwell> TD: well, not totally crazy. Lots of software systems that have no marginal cost get created by people or companies "deciding to do it".
444 2013-01-03 16:40:11 <TD> MC-Eeepc: the issue then may be that the legislative branch needs serious reform. google [liquid democracy] for some ideas.
445 2013-01-03 16:40:12 <MC-Eeepc> gmaxwell the internet is that balance
446 2013-01-03 16:40:22 <MC-Eeepc> or it would be if they would just leave it the fuck alone
447 2013-01-03 16:40:39 <TD> an open source warp drive? i could get behind that :)
448 2013-01-03 16:40:57 <TD> still, judicial power seems to have its limits. witness the judges statement in the recent drone secrecy case
449 2013-01-03 16:41:03 <gmaxwell> MC-Eeepc: it's part of it, but a lot of the internet is for profit too. Should I be able to pay all the major sites to suppress your views that disagree with mine?
450 2013-01-03 16:41:08 <gavinandresen> the internet didn't take off until farsighted people who thought they could get filthy rich jumped in and started building companies
451 2013-01-03 16:41:15 <gavinandresen> turns out they were right, and they are filthy rich....
452 2013-01-03 16:42:03 <MC-Eeepc> i stil think you guys should get up on a constitutional amendment about campaign funding
453 2013-01-03 16:42:47 <gmaxwell> MC-Eeepc: it'll happen eventually, and then in 30 years get undone.. then in 30 more years get fixed again.. etc.
454 2013-01-03 16:43:00 <MC-Eeepc> i mean, after i saw chris dodd get on the telly and openly threaten obama about his "donations" after the sopa thing
455 2013-01-03 16:43:18 <andytoshi> MC-Eeepc: if there were any serious candidates, maybe you'd be right
456 2013-01-03 16:43:32 <TD> MC-Eeepc: the reason people spend money on campaigns isn't because congress can literally be bought. it's because the choices offered to voters are so often minimally distinguishable that it all boils down to a knifeedge decision driven as much by personalities as anything else.
457 2013-01-03 16:43:35 <andytoshi> in 2012 there were some serious media problems, that -weren't- caused by campaign funding
458 2013-01-03 16:43:44 <MC-Eeepc> what the hell have you got to do to get an amendment done anyway
459 2013-01-03 16:43:47 <TD> MC-Eeepc: the real solution to solving campaign funding may be to change how voting is done, so representatives are less important.
460 2013-01-03 16:43:49 <MC-Eeepc> seems herculean
461 2013-01-03 16:43:52 <TD> but i don't anticipate that happening anytime soon
462 2013-01-03 16:44:00 <TD> MC-Eeepc: 75%, i thought?
463 2013-01-03 16:44:23 <TD> by the way, in switzerland there is a ton of political advertising
464 2013-01-03 16:44:29 <gmaxwell> Well, some places use alternative voting systems which disenfranchize minority candidates less.
465 2013-01-03 16:44:39 <gmaxwell> (e.g. the aussies with the ranked ballots)
466 2013-01-03 16:44:42 <TD> literally all the time. but you don't see people here complaining about it because the political advertising and campaign money is being spent to argue issues, not people
467 2013-01-03 16:45:05 <MC-Eeepc> swizerland is the pimp daddy of the world
468 2013-01-03 16:45:26 <gmaxwell> TD: one of the things critical to citizens united is that you can't really seperate funding for issues vs people.
469 2013-01-03 16:45:37 <TD> they do here because there are so many referendums
470 2013-01-03 16:45:47 <MC-Eeepc> that article is crazy
471 2013-01-03 16:45:57 <MC-Eeepc> what is it with your public prosecutors
472 2013-01-03 16:46:02 <TD> i can name several referendums that happened in the past 6 years but couldn't name my local politicians for the life of me
473 2013-01-03 16:46:06 <gmaxwell> TD: ah, switzerland is big on referendums?
474 2013-01-03 16:46:06 <MC-Eeepc> carrer building or what
475 2013-01-03 16:46:07 <TD> (not that i can vote anyway :))
476 2013-01-03 16:46:09 <TD> very
477 2013-01-03 16:46:11 <TD> it's famous for it
478 2013-01-03 16:46:32 <gmaxwell> Some US states use them, but at most I think they're only about equal in attention to the politicians.
479 2013-01-03 16:46:45 <MC-Eeepc> i think a petition of 100,000 guarantees a referendum on anything
480 2013-01-03 16:46:47 <TD> switzerland is structured a little bit like the USA is (theoretically). there's a somewhat weak federal government and most power lies with the cantons, which are like mini states
481 2013-01-03 16:46:53 <TD> except more the size of counties than states
482 2013-01-03 16:47:17 <MC-Eeepc> they have the canton system
483 2013-01-03 16:47:25 <MC-Eeepc> its like 13 federated states
484 2013-01-03 16:47:46 <MC-Eeepc> a lot of them even geopraphically seperated by mountain ranges etc
485 2013-01-03 16:47:50 <MC-Eeepc> some say that why its so stable
486 2013-01-03 16:47:51 <TD> switzerland is a really inspiring country in many ways. i wish i could take part more.
487 2013-01-03 16:47:56 <MC-Eeepc> compartmentalised
488 2013-01-03 16:48:39 <gmaxwell> (as an american I'm pretty ignorant about a lot of things outside of the US, I've been to switzerland but didn't know anything about its system of government)
489 2013-01-03 16:48:45 <TD> gavinandresen: i wouldn't rely on older people for gambling law reform, given that the big problems seem to be around internet gambling
490 2013-01-03 16:49:00 <MC-Eeepc> ha loud american tourist :)
491 2013-01-03 16:49:09 <TD> gmaxwell: switzerland comes up a lot in US gun control debates because it marries very high levels of gun ownership with very low levels of homicide and mass shootings
492 2013-01-03 16:49:11 <gmaxwell> MC-Eeepc: I pretend to be canadian when travling abroad!
493 2013-01-03 16:49:14 <TD> amongst other things
494 2013-01-03 16:49:20 <MC-Eeepc> heh
495 2013-01-03 16:49:27 <TD> hah. i've done that too. in slovakia. it turned out they didn't like the brits much.
496 2013-01-03 16:49:45 <TD> my canadian accent sucks, but they couldn't really tell the difference :)
497 2013-01-03 16:49:55 <phantomcircuit> gmaxwell, coward
498 2013-01-03 16:50:05 <MC-Eeepc> yeah its the law for each houshold to have a service rifle isnt it?
499 2013-01-03 16:50:25 <TD> something like that
500 2013-01-03 16:50:42 <MC-Eeepc> such a beautiful, free country
501 2013-01-03 16:50:52 <MC-Eeepc> also tax haven of the world
502 2013-01-03 16:51:01 <TD> however there are restrictions on ammo
503 2013-01-03 16:51:10 <TD> it's not quite as simple as "everyone can have whatever guns they want" either, far from it
504 2013-01-03 16:51:38 <TD> the wikipedia article on it is useful. the laws changed recently as part of entering the schengen zone
505 2013-01-03 16:51:44 <MC-Eeepc> no one service rifle per household, gun safe all that etc
506 2013-01-03 16:53:06 <TD> one of the referendums i remember was about tightening gun controls (rejected). the adverts had a scary cartoon of a moustachioed gun-toting "badass guy" holding a gun with the line, "Weapon monopoly for criminals? Say NO" which is pretty typical for political advertising here
507 2013-01-03 16:53:14 <TD> there are adverts for individual candidates too of course.
508 2013-01-03 16:53:23 <TD> but the issue ads are way more memorable
509 2013-01-03 16:54:47 <aethero> https://bitcointalk.org/index.php?topic=134386.0
510 2013-01-03 16:54:59 <aethero> Hack it. Get coins. ZIGGAP.com is mine by the way.
511 2013-01-03 16:56:07 <phantomcircuit> aethero, 80.5 BTC isn't enough to seriously interest... anybody
512 2013-01-03 16:56:22 <aethero> You dont think so?
513 2013-01-03 16:56:29 <gmaxwell> aethero: I didn't even bother to load the webpage.
514 2013-01-03 16:56:49 <aethero> $1000 bucks?
515 2013-01-03 16:57:02 <gmaxwell> It will probably interest some people however, so I don't fully agree with phantomcircuit.
516 2013-01-03 16:57:06 <MC-Eeepc> nice to see political ads are peurile the world over
517 2013-01-03 16:57:45 <MC-Eeepc> we recently had a referendum on AV system, and the conservatives did ads that said "she needs a new hosptial not AV" with a surgeon holding a newborn baby
518 2013-01-03 16:57:54 <MC-Eeepc> AKA vote no to AV or the baby gets it!
519 2013-01-03 16:58:55 <MC-Eeepc> phantomcircuit doesnt get out of bed for less than 10 gees these days ;)
520 2013-01-03 17:10:39 <TD> MC-Eeepc: that was the UK, right
521 2013-01-03 17:10:48 <TD> MC-Eeepc: i think a lot of people took the piss out of that ad
522 2013-01-03 17:11:11 <MC-Eeepc> http://www.newstatesman.com/blogs/steven-baxter/2011/02/voting-system-baby-gets
523 2013-01-03 17:11:18 <MC-Eeepc> yep good old tories
524 2013-01-03 17:12:01 <MC-Eeepc> currently rather successfully shifting the blame for the shitty economy onto the disabled and other undesirables
525 2013-01-03 17:12:08 <phantomcircuit> MC-Eeepc, $1000 isn't a large enough prize for maybe finding something
526 2013-01-03 17:12:38 <phantomcircuit> i would calculate the expected hourly wage for that to be like maybe $5/hr
527 2013-01-03 17:16:07 <gmaxwell> phantomcircuit: I think its better than not doing something like that though.
528 2013-01-03 17:16:38 <phantomcircuit> sure
529 2013-01-03 17:16:43 <phantomcircuit> better than nothing i suppose
530 2013-01-03 17:22:35 <drdoolittle> I have a paypal tool which can be fully customized with good programming...pm if interested..
531 2013-01-03 17:22:47 <drdoolittle> ;;voiceme
532 2013-01-03 17:26:29 <Luke-Jr> ???
533 2013-01-03 17:29:06 <TD> gavinandresen: i was thinking we should make outputs of zero value with [OP_FALSE] standard, and teach the client to automatically remove them from the utxo set.
534 2013-01-03 17:29:15 <TD> gavinandresen: in case one day we want to fund mining through assurance contracts
535 2013-01-03 17:29:21 <TD> it seems like a relatively simple and uncontroversial change
536 2013-01-03 17:31:37 <TD> also (more controversially) [<data> OP_FALSE]
537 2013-01-03 17:31:45 <TD> so it goes into the block chain but not the utxo set
538 2013-01-03 17:31:57 <gmaxwell> I don't see why they'd need to be made standard.
539 2013-01-03 17:32:15 <gavinandresen> getting them relayed/mined would be the point
540 2013-01-03 17:32:29 <TD> because you want them to be available to all miners
541 2013-01-03 17:32:45 <gmaxwell> There is no application for them today, however.
542 2013-01-03 17:33:02 <gavinandresen> If we build it, the applications will come....
543 2013-01-03 17:33:10 <gmaxwell> Exactly. As it stands making them available would just enable using the p2p network for IM.
544 2013-01-03 17:33:13 <gmaxwell> :P
545 2013-01-03 17:33:24 <TD> well, focus just on the [OP_FALSE] case then
546 2013-01-03 17:33:32 <TD> that doesn't seem to have any cost or possible side effects
547 2013-01-03 17:33:47 <gmaxwell> Why OP_FALSE and not OP_RETURN?
548 2013-01-03 17:33:55 <jgarzik> I hate OP_IF </offtopic>
549 2013-01-03 17:33:56 <TD> OP_RETURN works, yes
550 2013-01-03 17:34:05 <gavinandresen> bleuch, OP_RETURN is disabled
551 2013-01-03 17:34:22 <gavinandresen> I think OP_FALSE is much clearer semantics: "this is never true"
552 2013-01-03 17:34:23 <TD> but i think if the outputs are immediately considered as spent, then their cost is much lower. so it gives people a way to embed hashes more cheaply than abusing other types of output
553 2013-01-03 17:34:52 <gmaxwell> But sure, I generally agree with the UTXO pruning of unspendable outputs... though I think care should be taken to figure out how this would interact with normative UTXO talk.
554 2013-01-03 17:34:59 <gavinandresen> I agree with TD.
555 2013-01-03 17:35:58 <gmaxwell> If you want to talk controversial, I think I also think we should autoprune zero value outputs.
556 2013-01-03 17:36:04 <gavinandresen> I think making <data> OP_FALSE standard if <data> is 32 bytes or less is the right thing to do.
557 2013-01-03 17:36:21 <gmaxwell> TD: enbedded data can be handled much more cheaply on the input side though.
558 2013-01-03 17:36:53 <gmaxwell> But both cases have the unfortunate problem of still needing the data to verify the block in the first place. (though at least size limits can mean it was pre-hash compressed if large)
559 2013-01-03 17:37:27 <TD> input data is only cheaper because it doesn't sit in the UTXO set. if an output never enters that set, they are equivalent
560 2013-01-03 17:37:41 <TD> gmaxwell: that's a forking change though because they are spendable today.
561 2013-01-03 17:37:51 <TD> and they may have uses, also. but we went round that before.
562 2013-01-03 17:37:56 <Luke-Jr> if the outputs are automatically spent, it's a softfork
563 2013-01-03 17:38:33 <gavinandresen> sure, but soft forks are a lot harder to roll out than changes to IsStandard
564 2013-01-03 17:38:58 <gmaxwell> gavinandresen: But IsStandard changes do not need deployment in advance of usage, whereas softforks do.
565 2013-01-03 17:39:10 <gavinandresen> gmaxwell: I thought that is what I just said :)
566 2013-01-03 17:39:20 <gmaxwell> Ah. :P
567 2013-01-03 17:39:49 <gmaxwell> I can have a pool accepting OP_FALSEs in 10 minutes, and people using them in 15... "addnode this IP."
568 2013-01-03 17:40:20 <TD> the point is not to whitelist certain pools. it's to incentivize all miners. and the most effective way to do that is to allow relaying. that means upgrading all nodes, which takes time
569 2013-01-03 17:40:31 <TD> and will take longer and longer times as the project goes on
570 2013-01-03 17:40:36 <gmaxwell> forrestv: since you're the resident crap output maker, :P do you have an opinions on what form an unspendable data packing output should take?
571 2013-01-03 17:41:38 <gmaxwell> TD: It's only a matter of time before we get some massive parasitic bitcoin p2p network child porn trading tool or whatever, I'd rather break fewer things by not enabling a lot of new message types without knowing how we'd flood control them in advance.
572 2013-01-03 17:42:16 <gmaxwell> (break fewer things when we're forced to turn off relaying of message types where we can't control the flood)
573 2013-01-03 17:44:26 <gavinandresen> transaction fees are our flood control mechanism. If they're broken, then that is what we should fix.
574 2013-01-03 17:44:40 <TD> storing files in the block chain will never make economic sense. so the only possibility is trolling. nodes run in jurisdictions where the police are easily trolled can enable pruning and the "bad data" just gets automatically deleted
575 2013-01-03 17:44:41 <jgarzik> ...thus my proposed in pullreq + forum ;)
576 2013-01-03 17:44:48 <jgarzik> *proposal
577 2013-01-03 17:44:51 <jgarzik> increasing dust fees
578 2013-01-03 17:45:10 <jgarzik> TD: not true
579 2013-01-03 17:45:20 <gmaxwell> TD: who said anything about the blockchain? Thats incidental. Right now someone could abuse the relay network for anonymous messaging.
580 2013-01-03 17:45:25 <jgarzik> TD: other possibilities exist, namely, it is technically possible and already exists
581 2013-01-03 17:45:35 <TD> anonymous messaging is pretty much the point of the p2p network :)
582 2013-01-03 17:45:41 <jgarzik> TD: bootstrapping cost is low, if you have an existing network
583 2013-01-03 17:45:48 <jgarzik> which we do
584 2013-01-03 17:45:57 <gmaxwell> No, the point of the p2p network is enabling the bitcoin currency to work.
585 2013-01-03 17:46:40 <phantomcircuit> gmaxwell, to be fair robust messaging is a prerequisite to that
586 2013-01-03 17:46:55 <phantomcircuit> although i would hardly call the current network anonymous
587 2013-01-03 17:47:02 <gmaxwell> someone using it as an IM or file trading network is at odds with that purpose, and if someone starts doing it at large scale we're going to have to filter out more of the relaying.
588 2013-01-03 17:47:35 <phantomcircuit> that would be a comically inefficient thing to do even today
589 2013-01-03 17:47:57 <gavinandresen> gmaxwell: I actually disagree-- I think leveraging the bitcoin p2p network as a messaging network could make it explode even faster.
590 2013-01-03 17:48:02 <gmaxwell> Inefficient for the bitcoin users who eat the externalized costs, not so much for the guy sending the messsages.
591 2013-01-03 17:48:06 <gavinandresen> gmaxwell: that doesn't mean that the messages get stored in the blockchain....
592 2013-01-03 17:48:38 <jgarzik> still burdens the network, making bitcoin-the-currency more difficult to use
593 2013-01-03 17:48:58 <gmaxwell> gavinandresen: if the messaging and the other stuff is seperable at least it can avoid burdening bitcoin the currency. But using transactions for that doesn't achieve that.
594 2013-01-03 17:49:07 <gavinandresen> well, maybe we can design it so it is opt-in, or opt-in-if-you-have-the-bandwidth
595 2013-01-03 17:49:46 <gmaxwell> gavinandresen: I do agree there. But ... this is such an enormous project. If you note: nothing like that exists at all, except .. Uh jgarzik whats that thing called?. And not for lack of demand.
596 2013-01-03 17:50:10 <gmaxwell> (that python/qt bitcoin inspired flooding based anonymous IM system)
597 2013-01-03 17:50:22 <TD> bitmessage
598 2013-01-03 17:50:26 <gmaxwell> Thanks.
599 2013-01-03 17:50:40 <gavinandresen> gmaxwell: I plan on getting back to https://gist.github.com/4073937 someday (but payment protocol first)
600 2013-01-03 17:50:40 <TD> i really doubt anyone is going to build an IM network where al you can do is floodfill 32 byte messages
601 2013-01-03 17:51:02 <gmaxwell> TD: you just send lots and lots of them, each 'spending' the unconfirmed output of the last.
602 2013-01-03 17:51:43 <TD> i didn't say it's impossible, just unlikely
603 2013-01-03 17:52:39 <gmaxwell> I think it's P=1, in fact. As I've run into people on IRC trying to do it and bouncing off the reference client's refusal to make zero value outputs with sendmany.
604 2013-01-03 17:53:18 <gmaxwell> Fortunately, I guess, so far the people trying were not sufficiently competent and motivated to actually compile their own copy of the software.
605 2013-01-03 17:53:51 <jgarzik> TD: SatoshiDICE already uses bitcoin blockchain for IM :(
606 2013-01-03 17:54:05 <TD> anyway, fine, let's restrict my proposal to just [OP_FALSE]
607 2013-01-03 17:54:13 <jgarzik> TD: and their behavior for losing bets is definitely a flood-fill
608 2013-01-03 17:54:46 <gavinandresen> TD: any reason to say OP_FALSE ...and... zero-valued output? If people want to burn bitcoins....
609 2013-01-03 17:54:46 <gmaxwell> And pays for the privileged! ... and yes, I agree with gavin that actually having some kind of IM might be productive simply because it would keep some of that out of the blockchain.
610 2013-01-03 17:55:06 <TD> gavinandresen: i don't think we want to encourage coin-burning?
611 2013-01-03 17:55:30 <gmaxwell> The non-standard rules have sometimes saved people from very expensive mistakes.
612 2013-01-03 17:55:31 <gavinandresen> TD: we shouldn't encourage it, but should we make the code a little more complex to try to discourage it?
613 2013-01-03 17:55:52 <gavinandresen> gmaxwell: good point on expensive mistakes....
614 2013-01-03 17:56:26 <gavinandresen> I suppose an extra check in the IsStandard() code is trivial enough to be worth it
615 2013-01-03 17:57:16 <gmaxwell> (when it works it doesn't leave evidence but we have an example where it failed: the big MTGOX coin burning that only worked because of their programatic interface to trigger eligius to mine any txid they wanted.)
616 2013-01-03 17:58:10 <jgarzik> at the same time: (1) increase fees on dust, (2) provide non-blockchain anonymous IM
617 2013-01-03 17:58:21 <jgarzik> carrot + stick
618 2013-01-03 17:58:46 <jgarzik> ACTION was surprised at the lack of negative reaction on the forum and mailing list, to the fee increase proposal
619 2013-01-03 17:58:55 <gavinandresen> jgarzik: you didn'
620 2013-01-03 17:59:05 <gavinandresen> jgarzik: you didn't ask the SD folks directly, did you?
621 2013-01-03 17:59:08 <gmaxwell> maybe we should put out a call for people to work on non-blockchain anonymous IM. We may gain some more developers who are interested specifically in that and who have expirence in relevant techniques.
622 2013-01-03 17:59:10 <jgarzik> gavinandresen: no
623 2013-01-03 17:59:46 <gavinandresen> gmaxwell: tying the messages to transactions, so fees control spam problems, is really important IMHO
624 2013-01-03 18:00:09 <jgarzik> gavinandresen: evorhees posted on reddit, quote, "it's not like "dust" or spam transactions are even occurring at all."
625 2013-01-03 18:00:19 <jgarzik> gavinandresen: if SD cannot even admit they are creating dust, what is the point?
626 2013-01-03 18:00:27 <gmaxwell> gavinandresen: mining POW can also be employed... and would help bootstrap people who don't yet have bitcoin into that ecosystem.
627 2013-01-03 18:01:02 <gavinandresen> gmaxwell: but mining POW and fees are equivalent on a meta-level. And it seems to me using fees is simpler.
628 2013-01-03 18:01:22 <gavinandresen> (and has the advantage of helping secure the network)
629 2013-01-03 18:01:47 <kjj> new message type, client only relays signed messages when the signing address has paid fees in the last N blocks?
630 2013-01-03 18:02:00 <gavinandresen> anyway, the messaging+transactions conversation isn't something I think we should think hard about right now
631 2013-01-03 18:02:04 <gmaxwell> gavinandresen: Both do. There is a small degree of non-equivilance in that to increase IM volume if fees are your only issue you must increase transaction volume??? potentially transactions purely for the purpose of paying for IMs.
632 2013-01-03 18:02:25 <gavinandresen> I would like to think hard about getting a 0.8 release out sometime this year....
633 2013-01-03 18:03:07 <gmaxwell> gavinandresen: I saw your testing message post. Thats critical. Sipa just mostly completed one of my 0.8 must-happen items (the self checking).
634 2013-01-03 18:03:35 <gavinandresen> Item next at the top of my TODO list: get code signing certificates for the OSX and Windows binaries. I'm working on that now.
635 2013-01-03 18:03:50 <gmaxwell> We probably need to talk some about 0.8 scoping. There are a number of inflight changes that I'm suspecting should be skipped for 0.8 but I don't want to discourage new contributors with long merge windows.
636 2013-01-03 18:03:59 <gavinandresen> Quick sanity check: nobody has objections to the certificates being officially owned by Bitcoin Foundation, Inc. ?
637 2013-01-03 18:04:11 <gmaxwell> sounds fine to me.
638 2013-01-03 18:04:14 <TD> it's an Inc?
639 2013-01-03 18:04:21 <gmaxwell> Better check with atlas (lol).
640 2013-01-03 18:04:35 <gavinandresen> yes, Foundation's official name is an Inc.
641 2013-01-03 18:04:47 <kjj> yeah, the troll brigade will whine. but who else is in a position to do it?
642 2013-01-03 18:04:57 <TD> i thought that was reserved for companies, rather than registered charities.
643 2013-01-03 18:05:16 <gavinandresen> Alternative is a certificate that belongs to Gavin Andresen (or Jeff Garzik or ... somebody...)
644 2013-01-03 18:05:20 <kjj> Inc. is for any incorporated (chartered and registered) entity
645 2013-01-03 18:05:25 <TD> ok
646 2013-01-03 18:05:29 <TD> sounds good to me
647 2013-01-03 18:05:46 <TD> so you got the DUNS number?
648 2013-01-03 18:05:48 <gavinandresen> yes, you are an Inc. and then you register for non-profit status (Foundation will be a 501(c)6 )
649 2013-01-03 18:06:01 <gavinandresen> and yes, DUNS number arrived yesterday
650 2013-01-03 18:06:17 <jgarzik> gavinandresen: ACK on B.F. holding certs
651 2013-01-03 18:06:20 <jgarzik> hah
652 2013-01-03 18:06:22 <gmaxwell> In particular, there are major wallet code changes and the bloom filtering pulls. I'm concerned that they're a distraction for 0.8, at the same time 0.8 needs mostly time and testing, and rewarding people who submit code with a short pipeline should also be a priority.
653 2013-01-03 18:06:30 <jgarzik> ACTION just got his DUNS number for Dunvegan Space Systems
654 2013-01-03 18:07:36 <TD> i'd like to see bloom filtering in 0.8 - it's low risk and we can do some more testing on it real soon. but in the worst case, if it ships in a broken state then sans exploits, it's as if it hadn't shipped at all
655 2013-01-03 18:07:47 <TD> as all it does is add new commands to the protocol
656 2013-01-03 18:07:50 <D34TH> jgarzik, bitcoins in space?
657 2013-01-03 18:08:58 <gavinandresen> Anybody have bandwidth to write a fuzz-tester for the bloom filtering code?
658 2013-01-03 18:09:03 <MC-Eeepc> whats a bloom filter
659 2013-01-03 18:09:18 <gavinandresen> judy bloom, famous teenager author....
660 2013-01-03 18:09:22 <gmaxwell> TD: yea, 'sans exploits' being key.
661 2013-01-03 18:09:31 <gavinandresen> ... also invented bloom filters. (little known fact)
662 2013-01-03 18:09:35 <gavinandresen> (that isn't actually true)
663 2013-01-03 18:09:40 <TD> it uses the same deserialization logic as all the other commands
664 2013-01-03 18:10:10 <gmaxwell> TD: I'm not arguing that its atypically risky.
665 2013-01-03 18:10:16 <gavinandresen> I'd like to see a fuzzer throw all sorts of almost-correct filters at it for 24 hours or so and see the code not crash.
666 2013-01-03 18:10:38 <D34TH> gavinandresen, how much bandwidth we talking
667 2013-01-03 18:10:41 <TD> a filter is just a few fields, one of which is a bitfield
668 2013-01-03 18:10:43 <D34TH> i have quite a bit
669 2013-01-03 18:10:45 <TD> there isn't much to fuzz
670 2013-01-03 18:11:00 <gavinandresen> D34TH: I mean programming-time bandwidth, not network bandwidth
671 2013-01-03 18:11:10 <D34TH> sadface
672 2013-01-03 18:11:15 <gmaxwell> I think a fuzzer is a requirement, regardless. In general we should probably adopt a postion that full coverage and fuzzing is required for any new network exposed feature.
673 2013-01-03 18:11:34 <gavinandresen> I think I still have the fuzzing branch I used to test the BIP16 code....
674 2013-01-03 18:11:39 <kjj> isn't every possible bitfield a valid request though?
675 2013-01-03 18:12:24 <gmaxwell> kjj: obviously we don't expect it to fail, it would be very surprising that it exists. You perform fuzz testing in order to catch the unexpected.
676 2013-01-03 18:14:32 <gavinandresen> gmaxwell: RE: wallet changes: I think the policy should be "we're testing constrained; get a good test plan written, then round up testers and get it tested and it'll get pulled."
677 2013-01-03 18:15:22 <kjj> sounds very reasonable
678 2013-01-03 18:16:11 <gavinandresen> and if a little bit of funding would help motivate people to help write a test plan or test, we should think about using some of our Foundation grant to chip in for that.
679 2013-01-03 18:16:12 <gmaxwell> Okay, thats consistent with what I'd already suggested to stealth222 (next work on adding tests).
680 2013-01-03 18:17:19 <gmaxwell> I've been somewhat surprised at how little interest people seem to have in simply trying out new things (testing is more than just trying out??? but if you're not willing to even try, you're not going to test either). I don't actually understand whats creating this situation.
681 2013-01-03 18:18:08 <kjj> I wouldn't read anything into low attendance/participation for at least another month
682 2013-01-03 18:18:16 <gmaxwell> (I mean, this is not consistent with the expirence I'm having in some non-bitcoin projects. Relative to the number of users I see more people interested in trying out prerelease stuff, e.g. for a lossy audio compressor)
683 2013-01-03 18:18:25 <jgarzik> on 0.8
684 2013-01-03 18:18:36 <jgarzik> I think getting the current code out to users is highest priority
685 2013-01-03 18:18:43 <jgarzik> higher priority than bloom filtering or wallet updates
686 2013-01-03 18:18:54 <jgarzik> 0.7 is really creaking
687 2013-01-03 18:19:03 <jgarzik> pushing users away from satoshicode
688 2013-01-03 18:19:39 <gmaxwell> We also have reported database corruption from windows users on 0.8 that we don't know the cause of. But we also have reported database corruption with 0.7 that we don't know the cause of. :-/
689 2013-01-03 18:19:43 <jgarzik> I'm concerned that 0.8 takes forever as it becomes an "everything I want it to be" release
690 2013-01-03 18:20:13 <jgarzik> if bloom filter is ready, let's pull it today
691 2013-01-03 18:20:20 <jgarzik> but let's not block 0.8 for bloom filtering
692 2013-01-03 18:20:28 <gavinandresen> I agree with jgarzik
693 2013-01-03 18:20:29 <TD> matt has done a lot of testing and written quite thorough unit tests
694 2013-01-03 18:20:34 <TD> i'm going to do some testing also soon
695 2013-01-03 18:20:55 <gavinandresen> we should be tieing up loose ends to get to a rc1 asap
696 2013-01-03 18:21:13 <TD> well, could we at least do a fast 0.9? bloom filtering is getting really important for spv clients
697 2013-01-03 18:21:27 <jgarzik> TD: have it ready soon, and it will get pulled soon ;p
698 2013-01-03 18:21:34 <TD> i was hoping we could say "upgrade to 0.8, it's important for network performance"
699 2013-01-03 18:21:42 <gavinandresen> I think we can have bloom filtering in 0.8rc1....
700 2013-01-03 18:21:47 <gmaxwell> gavinandresen: we should pull sipa's checking pull sooner rather than later, as it'll help increase confidence that 0.8 is correct.
701 2013-01-03 18:21:51 <TD> AFAIK it is ready, as in the code works on both sides. i'll do some local testing soon
702 2013-01-03 18:22:24 <gmaxwell> I think we can have bloomfiltering too. It may need some additional tests, but I actually haven't looked at what it has right now. Matt has done a lot of excellent testing automation work.
703 2013-01-03 18:23:15 <gavinandresen> speaking of matt's excellent testing automation work... I think he should get some of the 70 BTC that was donated to the Bitcoin Testing Project. Anybody object if I send him 20 ?
704 2013-01-03 18:23:16 <gmaxwell> The other gate on bloomfilter is really another implementation. :( But if no one is volunteering then perhaps we should look the other way and if it turns out to be flawed we can replace it.
705 2013-01-03 18:23:22 <jgarzik> gavinandresen: ACK
706 2013-01-03 18:23:25 <gmaxwell> gavinandresen: I strongly support that.
707 2013-01-03 18:23:55 <jgarzik> The important thing to get right with bloom filtering is the on-wire format. Implementation bugs can be dealt with during -rc etc.
708 2013-01-03 18:23:58 <Diapolo> for that pull tester alone he should get it ^^
709 2013-01-03 18:24:03 <gavinandresen> cool, I'll send them before he has a chance to say he doesn't want them
710 2013-01-03 18:24:09 <jgarzik> hehe
711 2013-01-03 18:24:11 <gmaxwell> (I dunno if paying people for testing will help, but I can tell you paying some people and not others for testing will hurt! :P)
712 2013-01-03 18:24:20 <gmaxwell> (even if they insist they don't want them)
713 2013-01-03 18:24:21 <TD> gmaxwell: it's implemented in bitcoinj
714 2013-01-03 18:24:33 <jgarzik> TD: and picocoin/libccoin
715 2013-01-03 18:24:50 <gmaxwell> TD: yes, but I consider bitcoin + bitcoinj 1.5 implementations.
716 2013-01-03 18:24:55 <gmaxwell> but I didn't know about picocoin.
717 2013-01-03 18:24:57 <gmaxwell> Concern removed.
718 2013-01-03 18:25:09 <TD> jgarzik: cool. i thought picocoin didn't have a wallet yet
719 2013-01-03 18:25:54 <jgarzik> TD, gmaxwell: it's mostly on the libccoin side, as it is intended to be used internally as well as externally: picocoin has fork-based process separation between wallet and network, and I plan to pass a bloom filter between the two
720 2013-01-03 18:26:14 <jgarzik> note future tense "plan to". the bloom filter is implemented w/ tests on libccoinc
721 2013-01-03 18:26:18 <jgarzik> picocoin, not so much
722 2013-01-03 18:27:12 <jgarzik> TD: picocoin has always had a wallet, from day one. not a very useful one... but picocoin is a SPV wallet client.
723 2013-01-03 18:27:20 <TD> ok
724 2013-01-03 18:28:02 <jgarzik> the underlying bitcoin lib, libccoin, is much more expansive. It supports picocoin as well as other apps (including the nascent block relay daemon "brd")
725 2013-01-03 18:28:20 <jgarzik> libccoin passes all the JSON tests shipped w/ bitcoin/bitcoin.git
726 2013-01-03 18:28:55 <jgarzik> picocoin is half-built, very much still under construction. it can receive payments to a wallet, but not send (or even enumerate very well)
727 2013-01-03 18:29:51 <jgarzik> still, for bitcoind, bloom filtering not should be a blocker for 0.8. it is on the "nice to have, if ready" list. and it sounds like it is ready.
728 2013-01-03 18:32:31 <kjj> is the reported database corruption in 0.8 better, worse, or the same as in the old BDB versions?
729 2013-01-03 18:32:52 <kjj> as in, wallet corruption, or not?
730 2013-01-03 18:34:40 <Diapolo> worse than BDB seems impossible? ^^
731 2013-01-03 18:35:03 <gmaxwell> kjj: no, never wallet.
732 2013-01-03 18:35:24 <gmaxwell> As far as we know the BDB corruption issues seems to be related to unclean shutdowns, and doesn't seem to create (much) forking risk.
733 2013-01-03 18:35:40 <gmaxwell> With 0.8 we have less information.
734 2013-01-03 18:36:01 <kjj> is a 0.8 DB corruption more or less annoying to recover from than in BDB? As in, is the usual remedy to delete the index and start over?
735 2013-01-03 18:36:41 <gmaxwell> the annoyance of the corruption isn't a consideration for me (though it's less), the concern is that it might come along with forking risk.
736 2013-01-03 18:37:07 <grau> Hi, Would you please clarify does 0.8 moves away from BDB or stores an index of BDB in LevelDB?
737 2013-01-03 18:37:22 <gmaxwell> an index of bdb??
738 2013-01-03 18:37:24 <kjj> as in, some nodes might get funny ideas about the top of the chain and think that the rest of the network is building on bogus hashes?
739 2013-01-03 18:37:32 <gmaxwell> In 0.8 BDB is only used for the wallet.
740 2013-01-03 18:37:54 <grau> exuse i never tried to parse the binary store
741 2013-01-03 18:38:07 <grau> its just a dump?
742 2013-01-03 18:38:14 <gmaxwell> kjj: that would be the less bad case. Worse is corruption that would permit building a bogus block.
743 2013-01-03 18:39:05 <gmaxwell> grau: the blocks themselves have never been stored with bdb. They're just seralized to disk just like they are on the wire, one after another.
744 2013-01-03 18:39:20 <kjj> gmaxwell: would the bogus chain be accepted by nodes other than the one with the funny corruption?
745 2013-01-03 18:39:44 <grau> ok, so it is a wire dump. Thanks I thought that weould also be indexed store
746 2013-01-03 18:39:47 <gmaxwell> kjj: if the cause is systemic e.g. a flaw in the software then potentially yes.
747 2013-01-03 18:39:55 <kjj> ahh
748 2013-01-03 18:40:18 <kjj> hmm.
749 2013-01-03 18:40:26 <gmaxwell> grau: BDB is used in <0.8 to index that data. 0.8 largely does not index that data (it indexes only the block locations).
750 2013-01-03 18:42:09 <gmaxwell> kjj: we've had and fixed bugs in git that could result in accepting an invalid chain, so it's not purely hypothetical. Though it would seem to me that the evidence we have now merely suggests some leveldb durability or atomiticiy problems on windows, though its a bit dangerous to assume.
751 2013-01-03 18:42:23 <grau> ok, thats different. I use leveldb both to store and index, btw using diffrent access paths e.g. by address and by hash
752 2013-01-03 18:42:32 <grau> you might want to take a look
753 2013-01-03 18:42:35 <gmaxwell> We do not index transactions anymore in 0.8.
754 2013-01-03 18:42:51 <aethero> gmaxwell are you alive?
755 2013-01-03 18:42:57 <aethero> obviously :)
756 2013-01-03 18:43:01 <aethero> May I PM?
757 2013-01-03 18:43:04 <gmaxwell> And for storing its quite hard to be more efficient than what we do, especially since we no longer access block data except to initilize peers.
758 2013-01-03 18:43:40 <kjj> well, my thought was that if 0.8 is being held up by serious issues, we should merge some smaller stuff in as the next 0.7.x release while we continue work (testing) on the leveldb
759 2013-01-03 18:44:00 <kjj> but the situation sorta splits my decision criteria down the middle.
760 2013-01-03 18:44:12 <gmaxwell> aethero: it's a free country. But in the past I've had a habbit of ignoring PM's from people who make a point of bragging in public that they want to have a private conversation with me.
761 2013-01-03 18:44:36 <aethero> That wasn't bragging. It's considered polite to ask..
762 2013-01-03 18:44:37 <gmaxwell> kjj: the things in 0.8 are the most important things happening for the software by far. If we can't get them out in a timely fashion the rest is pointless.
763 2013-01-03 18:44:44 <grau> its efficient for store, but is it efficient to look up utxo?
764 2013-01-03 18:45:03 <gmaxwell> grau: we don't use the blockchain data to look up transactions.
765 2013-01-03 18:45:22 <kjj> gmaxwell: I'm inclined to agree, but if it needs more testing, it needs more testing, and another 0.7.x release won't necessarily have a huge impact on that
766 2013-01-03 18:45:35 <grau> gmaxwell : you assume utxo in memory?
767 2013-01-03 18:47:28 <gmaxwell> grau: no, it's seperate from the blockchain, in a special highly compacted form that includes only the data needed for validation.
768 2013-01-03 18:48:25 <grau> gmaxwell : can it be more compact than the output part of transactions?
769 2013-01-03 18:48:30 <gmaxwell> Yes.
770 2013-01-03 18:49:09 <kjj> gmaxell: can you think of anything we could do to provide ourselves with reasonable assurance that the new code won't allow bogus blocks to fall in?
771 2013-01-03 18:49:58 <grau> i will look into thanks, hate reading c++ if than rather c.
772 2013-01-03 18:50:36 <kjj> the most obvious way is also the high risk way: release, see what happens. perhaps retagging it from pre-0.8 to 0.8rc1 will get it into enough hands to build confidence, while still limiting the potential damage
773 2013-01-03 18:52:08 <gmaxwell> kjj: releases don't actually increase confidence enormously for that partiuclar concern, because the type of bogosity could be so obscure that it wouldn't happen naturally.
774 2013-01-03 18:52:58 <helo> should the 0.8 previews be set to testnet only?
775 2013-01-03 18:53:03 <gmaxwell> The best work is the work that bluematt has already done, which in fact caught one of those issues, ??? the blocktester. Improving it further would be helpful. Though it's only likely to catch blockchain state determinstic failures.
776 2013-01-03 18:53:11 <gmaxwell> helo: no one will test them.
777 2013-01-03 18:53:15 <gmaxwell> (if thats done)
778 2013-01-03 19:05:38 <kjj> gmaxwell: ok, does improving on that work require time, or effort, or both?
779 2013-01-03 19:06:09 <grau> gmaxwell: where can I find that blockester please?
780 2013-01-03 19:08:29 <jgarzik> grau: raw block data ("block" messages) are stored in on-wire format in sequential access data files
781 2013-01-03 19:08:50 <jgarzik> grau: BDB (< 0.8) or leveldb (>= 0.8) stored indices into this data
782 2013-01-03 19:09:07 <jgarzik> grau: 0.8 also optimizes storage of the UTXO set
783 2013-01-03 19:10:11 <gmaxwell> jgarzik: well 0.8 indexes a _lot_ less of that data. It really only indexes the block IDs. Then it seperately keeps the utxo data.
784 2013-01-03 19:10:54 <grau> jgarzik : thanks. gmaxwell explained. I have to test the branching of the chain. gmaxwell recommends blocktester of bluematt, would you please point me to it?
785 2013-01-03 19:11:59 <gmaxwell> grau: The tool is here https://github.com/TheBlueMatt/test-scripts but I don't know if thats the best location for it.
786 2013-01-03 19:12:06 <gmaxwell> So I was looking in my logs to see if there was a better url.
787 2013-01-03 19:12:12 <grau> i store by hash in leveldb and also store hash by address since want to support query by that. this is certainly slowe but i think a string use case
788 2013-01-03 19:12:48 <jgarzik> grau: ping bluematt... don't know offhand
789 2013-01-03 19:13:07 <jgarzik> grau: yes, optional indices can add useful queries
790 2013-01-03 19:13:26 <jgarzik> grau: sipa has mentioned an optional bitcoind index, storing all (Hash) -> (transaction)
791 2013-01-03 19:13:36 <jgarzik> well really (hash)->(transaction offset)
792 2013-01-03 19:13:53 <jgarzik> that would permit queries on spent transactions, which many have requested
793 2013-01-03 19:14:15 <grau> jgarzik: I store hash->block, hash->tx and out address->tx
794 2013-01-03 19:14:52 <grau> where address is both sent and received
795 2013-01-03 19:16:08 <grau> i mean address->tx hash
796 2013-01-03 19:16:37 <jgarzik> grau: BTW it is nice that you are on IRC
797 2013-01-03 19:17:04 <jgarzik> grau: several protocol changes have been first discussed here. it is good to have alt-implementation developers listening.
798 2013-01-03 19:17:25 <grau> thanks, will listen :)
799 2013-01-03 19:18:49 <grau> bloom filter is not my interest the moment. but BIP32 is what I think needed by my "customer"
800 2013-01-03 19:20:11 <gmaxwell> If you will not implement bloom filters but you are implementing a full node, then that would be an argument against us adopting it. It would be helpful to know if you're opposed to it and why, or if it just isn't your current priority.
801 2013-01-03 19:21:05 <grau> do not read much about it. I just mean I do not see it important at the moment
802 2013-01-03 19:21:18 <gmaxwell> OK.
803 2013-01-03 19:23:04 <jgarzik> The general idea of bloom filters is making it easier to support thin clients (SPV clients). Full nodes will transmit fewer bytes to clients, using less bandwidth, if a client installs a bloom filter.
804 2013-01-03 19:23:28 <jgarzik> And for thin clients on mobile phones, that means less bandwidth used on a potentially poor mobile connection :)
805 2013-01-03 19:24:29 <grau> Yes, I got the concept and like it.
806 2013-01-03 19:27:26 <jgarzik> Fraudulent certs in the wild again, LWN reports: http://lwn.net/Articles/531346/rss
807 2013-01-03 19:28:19 <grau> Serving lots of SPVs is a particular role of a full node. I focus on uses of a full node that connect bitcoin with other systems.
808 2013-01-03 19:34:04 <gmaxwell> I wonder if we could also use bloom filters in the reference client for bandwidth limiting. E.g. if you have limited your bandwidth, send peers orthorgonal random bloom filters to reduce the number of INVs they send you. (but still send normal GETBLOCKs rather than MSG_FILTERED_BLOCK).
809 2013-01-03 19:38:52 <grau> gmaxwell: sounds risky if filter are orthogonal, you might miss a lot if one client is a zombie. Or you also ramdomly disconnect to reset filter.
810 2013-01-03 19:39:25 <ThomasV> gmaxwell: doesn't that increase the processing work for the peers who need to filter?
811 2013-01-03 19:39:31 <gmaxwell> grau: missing transaction messages isn't terribly risky though, as you'll find them when the transactions end up in a block... at least so long as only ratelimited nodes do it.
812 2013-01-03 19:40:06 <gmaxwell> ThomasV: the filter is really cheap, probably (hopefully?) cheaper than the sha256 operations required to send the inv messages that will get skipped.
813 2013-01-03 19:40:17 <grau> gmaxwell: ok until all transactions get a block
814 2013-01-03 19:43:01 <ThomasV> gmaxwell: ok, but a given node will receive different filters from its various peers. I guess that scales at least linearly
815 2013-01-03 19:44:01 <jgarzik> Can't do it for all peers, either. SPV clients will just ignore filter* messages.
816 2013-01-03 19:44:24 <gmaxwell> spv clients don't relay third party transactions.
817 2013-01-03 19:44:40 <gmaxwell> (and if they do, they're DOS multipliers)
818 2013-01-03 19:45:19 <grau> Do SPV clients identify themselves as such in version message ?
819 2013-01-03 19:45:36 <jgarzik> !NODE_NETWORK
820 2013-01-03 19:45:37 <gribble> Error: "NODE_NETWORK" is not a valid command.
821 2013-01-03 19:45:39 <jgarzik> !NODE_NETWORK
822 2013-01-03 19:47:02 <MC-Eeepc> spv dont contribute back to the network in any way then?
823 2013-01-03 19:47:50 <gmaxwell> wrt the broken node risk if they're orthorgonal, you could also make them only partially orthorgonal, e.g. every bit is sent to two peers, but not all peers...
824 2013-01-03 19:47:59 <gmaxwell> MC-Eeepc: they contribute to the network by being users of it.
825 2013-01-03 19:48:19 <gmaxwell> Ideally supporting a connection, esp a filtered one should be so cheap and scalable that its a non-issue.
826 2013-01-03 19:48:28 <gmaxwell> Though our current network code doesn't make that the case.
827 2013-01-03 19:49:55 <grau> you basically assume a random partitioning of the network. I wonder if some protocol could even gove hint to real partitioning, so one can recognize those nodes that add more to reach
828 2013-01-03 19:50:48 <gmaxwell> grau: yes/no, I'd only propose this for network leaf nodes which are resource constrained.. where their alternative would be to run a SPV node that doesn't validate or relay.
829 2013-01-03 19:52:43 <kjj> a SPV leaf node isn't likely to be asking for a full inventory anyway, will it?
830 2013-01-03 19:53:49 <kjj> so the nodes that are asking for inventory will be regular multi-connected nodes, so it shouldn't matter if any of those peers provides less than a full set, provided that it gets a full set from everywhere
831 2013-01-03 19:55:18 <kjj> so a node should be fine if it protects itself by advertising a masked filter, provided it does so somewhat randomly to reduce the chances of a peer getting a degenerate mask set
832 2013-01-03 20:03:32 <gmaxwell> I don't really know if its worth thinking about, INVs are very low volume.
833 2013-01-03 20:09:09 <xenland> Is there a default encoding enforced on the Sign message dialogue in the GUI? or does it default to Qt?
834 2013-01-03 20:09:10 <jgarzik> pretty much
835 2013-01-03 20:09:27 <xenland> (UTF-8)