1 2013-09-05 00:05:12 <numismatics> jgarzik: tyvm for the torrent bootstrap.dat torrent
2 2013-09-05 00:05:43 <Belxjander> numismatics: that bootstrap.dat torrent was not working for me
3 2013-09-05 00:06:02 <jgarzik> Belxjander, what was the problem you saw?
4 2013-09-05 00:06:04 <numismatics> I started it from the magnet link
5 2013-09-05 00:07:00 <numismatics> once its done I'll check the signature?
6 2013-09-05 00:07:17 <Belxjander> jgarzik: lack of connectivity from my torrent client to any peers
7 2013-09-05 00:07:43 <Belxjander> jgarzik: so nothing to do with your torrent... more likely some TTL distance issue with my network connection
8 2013-09-05 00:08:16 <gmaxwell> Belxjander: using rtorrent?
9 2013-09-05 00:08:28 <Belxjander> gmaxwell: ctorrent on AmigaOS
10 2013-09-05 00:08:47 <Belxjander> I'm willing to try again since I deleted the original and the large empty file it made
11 2013-09-05 00:09:06 <numismatics> why caution against --rescan?
12 2013-09-05 00:09:10 <gmaxwell> probably the same boat... librtorrent at least cannot bootstrap and can only use the DHT if you already have a torrent on a working tracker and do peer exchange or something daft like that.
13 2013-09-05 00:09:37 <gmaxwell> numismatics: I don't know what you're referring to, but rescan should never be needed.
14 2013-09-05 00:09:58 <gmaxwell> (unless you've gone and hexedited your wallet or done imports with rescan=false)
15 2013-09-05 00:10:08 <Belxjander> gmaxwell: so basically the client I have is "shot in the head" stupid with regards some updated bittorrent protocol semantics?
16 2013-09-05 00:10:16 <numismatics> i thought jgarzik's instructions were that the bootstrap.dat should only be used for fresh installs, and that while --rescan should work fine
17 2013-09-05 00:10:21 <numismatics> cautioned against it
18 2013-09-05 00:10:59 <gmaxwell> Belxjander: in general the bittorrent world is supprisingly uh.. lossy for small torrents.
19 2013-09-05 00:11:53 <gmaxwell> numismatics: the torrent does no good on an existing install. Can you quote what you're talking about though?
20 2013-09-05 00:11:57 <Belxjander> its a "small" torrent for the bootstrap.dat ?
21 2013-09-05 00:12:00 <gmaxwell> Someone is probably confusing rescan with reindex.
22 2013-09-05 00:12:04 <gmaxwell> Belxjander: small number of users.
23 2013-09-05 00:12:15 <Belxjander> ahhh
24 2013-09-05 00:12:42 <numismatics> http://sourceforge.net/projects/bitcoin/files/Bitcoin/blockchain/
25 2013-09-05 00:13:13 <numismatics> somehow my blockchain got corrupted; i thought downloading the torrent would be a faster way of reindexing the entire chain
26 2013-09-05 00:57:44 <maaku> numismatics: even if you downloaded the torrent you'd still have to reindex...
27 2013-09-05 00:58:07 <numismatics> bot not have to d/l the whole blockchain?
28 2013-09-05 01:05:01 <maaku> reindexing and downloading are completely unrelated
29 2013-09-05 01:09:17 <maaku> numismatics: reindexing is when you've already downloaded the block chain, and want to regenerate the index structures built from it
30 2013-09-05 01:09:35 <maaku> it's like 'downloading' the chain from your own hard disk
31 2013-09-05 01:09:55 <maaku> do you have the chain already, somewhere?
32 2013-09-05 01:09:59 <maaku> then run with -reindex
33 2013-09-05 01:10:44 <TheLordOfTime> and reindexing can take just as much time as it took to index as you download, depending on the circumstances/system specs
34 2013-09-05 01:10:53 <TheLordOfTime> (i tested that on the same system before because curious :P)
35 2013-09-05 01:13:53 <Belxjander> anyone else got the bootstrap.dat and doesn't mind my trying a "-S CTCS" option on my BT client?
36 2013-09-05 01:46:25 <Luke-Jr> ACTION updates http://luke.dashjr.org/programs/bitcoin/files/charts/security.html
37 2013-09-05 02:09:08 <freewil> nice
38 2013-09-05 02:11:38 <freewil> what would be a broken node
39 2013-09-05 02:27:37 <Luke-Jr> freewil: one that can't sync past the last hardfork
40 2013-09-05 02:27:52 <freewil> ah
41 2013-09-05 02:27:55 <Luke-Jr> freewil: so pre-0.8 that aren't on the latest backport branch
42 2013-09-05 03:36:33 <cfields> Luke-Jr: ping
43 2013-09-05 03:37:01 <Luke-Jr> cfields: pong
44 2013-09-05 03:38:09 <cfields> Luke-Jr: warren mentioned that you knew someone working on osx cross/deterministic builds. Do you have any more info on that?
45 2013-09-05 03:38:25 <cfields> I'm considering tackling at, but won't bother if someone's already working on it
46 2013-09-05 03:38:28 <Luke-Jr> besides warren's friend, just myself, and that was a while ago and obsolete
47 2013-09-05 03:38:43 <Luke-Jr> you can find my work on the Gitorious cross-osx project
48 2013-09-05 03:40:55 <cfields> ok. Is there a bounty put up for it somewhere?
49 2013-09-05 03:41:45 <Luke-Jr> I have some donations in my personal wallet I can forward on when something works
50 2013-09-05 03:43:19 <cfields> well I have it working (hacked in POC ofcourse) and I'd like to get it in officially, I just figured i'd try to meet any bounty requirements while I'm at it, if they're out there
51 2013-09-05 03:43:22 <cfields> got any specifics?
52 2013-09-05 03:44:41 <Luke-Jr> cfields: PM me your email and I'll send you some
53 2013-09-05 03:45:37 <Luke-Jr> sent
54 2013-09-05 03:48:46 <cfields> Luke-Jr: only possible issue i forsee is the "free-software-only" requirement + dmg creation
55 2013-09-05 03:49:17 <Luke-Jr> cfields: I can't imagine DMG is that hard to create
56 2013-09-05 03:49:32 <cfields> i'm able to create bitcoind/bitcoin-qt without issue, but info is pretty sparse on the dmg
57 2013-09-05 03:49:57 <cfields> creating a dmg? no, doable. creating one worty of official release may be a different story
58 2013-09-05 03:50:03 <cfields> *worthy
59 2013-09-05 03:50:11 <Belxjander> DMG files?
60 2013-09-05 03:50:18 <Belxjander> Mac OS X Disk Image files?
61 2013-09-05 03:50:25 <cfields> meaning: deterministic, compressed, pretty
62 2013-09-05 03:50:26 <cfields> yea
63 2013-09-05 03:54:53 <BCB> anyone see this http://blockchain.info/blocks/88.208.1.24
64 2013-09-05 03:55:01 <BlueMatt> ACTION can now claim two p2p-triggered crashes in bitcoind introduced that lasted several versions before anyone noticed...
65 2013-09-05 03:55:18 <BlueMatt> maybe someone should review my code before merging next time
66 2013-09-05 03:56:14 <lianj> :D
67 2013-09-05 03:57:05 <cfields> Luke-Jr: could you expand upon "some donations?" trying to decide what to prioritize
68 2013-09-05 04:09:09 <gavinandresen> cfields: working on the pull-tester for autotools⦠can you make a couple changes to pull-tester.sh ?
69 2013-09-05 04:10:04 <cfields> sure
70 2013-09-05 04:10:48 <gavinandresen> great. Change 1: I'd like to put all the pull-tester stuff in a qa/pull-tester folder, instead of contrib/test-scripts
71 2013-09-05 04:11:16 <cfields> ok
72 2013-09-05 04:11:27 <gavinandresen> And Change 2: I'd like to pass the path-to-root-directory as the first argument to pull-tester.sh
73 2013-09-05 04:11:52 <gavinandresen> (run it as pull-tester.sh /mnt/bitcoin /mnt/mingw-deps /path/to/.jar 6 )
74 2013-09-05 04:13:53 <cfields> ok. i had it that way originally, but ended up changing my mind since the only way the pull-tester and the scripts dir (qa/pull-tester) can be guaranteed in-sync is with the assumption that they're run from the same repo
75 2013-09-05 04:14:45 <cfields> i'd rather not give that up, but will do if that's your preference
76 2013-09-05 04:14:58 <gavinandresen> cfields: if you have some way I can ' cd /mnt/bitcoin && pull-tester.sh â¦etc' I'm happy not to change
77 2013-09-05 04:15:09 <gavinandresen> The master pull-tester script runs:
78 2013-09-05 04:15:17 <gavinandresen> chroot /mnt/chroot-tmp sudo -u matt -H timeout 3600 /mnt/bitcoin/contrib/test-scripts/pull-tester.sh /mnt/mingw /mnt/test-scripts/BitcoinjBitcoindComparisonTool.jar 6
79 2013-09-05 04:15:36 <gavinandresen> ⦠which fails because chroot sets CWD to /
80 2013-09-05 04:16:11 <gavinandresen> The chroot / sudo / timeout is kind of crazy, but we want all three.
81 2013-09-05 04:17:32 <cfields> cd /mnt/bitcoin && contrib/test-scripts/pull-tester.sh ...
82 2013-09-05 04:17:47 <cfields> does that not do what you want? i suspect i'm missing something
83 2013-09-05 04:18:12 <gavinandresen> chroot and sudo and timeout all take a single command to run
84 2013-09-05 04:18:20 <gavinandresen> ⦠not a "do this && that"
85 2013-09-05 04:18:38 <cfields> heh, that is indeed the thing i was missing :)
86 2013-09-05 04:19:49 <cfields> i'll change it as you described for now and think on it further
87 2013-09-05 04:20:56 <cfields> new folder at srcroot called qa, right?
88 2013-09-05 04:21:04 <gavinandresen> yes
89 2013-09-05 04:39:00 <cfields> gavinandresen: pushed
90 2013-09-05 04:39:16 <gavinandresen> cfields: awesome, I'll give it a whirl right now
91 2013-09-05 04:42:09 <gavinandresen> ./autogen.sh: 1: autoreconf: not found
92 2013-09-05 04:42:15 <gavinandresen> which package is that again?
93 2013-09-05 04:42:41 <cfields> grabbing automake/autoconf/libtool/pkgconfig should cover everything i think
94 2013-09-05 04:43:41 <cfields> gavinandresen: i've got to head out, will try to make it back in an hour or so
95 2013-09-05 04:43:46 <cfields> fingers crossed
96 2013-09-05 04:43:57 <gavinandresen> cfields: cool
97 2013-09-05 04:45:45 <phantomcircuit> BlueMatt, heh
98 2013-09-05 05:02:27 <gavinandresen> cfields: when you're back: configure is failing to find OpenSSL (Ubuntu 10.04, openssl package is installed, I see /usr/include/openssl and /usr/lib/libssl* )
99 2013-09-05 05:04:37 <gavinandresen> ⦠wait, might be missing pkg-config ....
100 2013-09-05 05:08:39 <gavinandresen> cfields: never mind, chroot environment was missing pkg-config
101 2013-09-05 05:14:34 <cfields> gavinandresen: back. i'll add a pkg-config check where needed. will hold off on pushing til you're ready for a test-push
102 2013-09-05 05:39:02 <gavinandresen> cfields: Getting an error running check-local in linux-build: usage: timeout [-signal] time command...
103 2013-09-05 05:39:58 <cfields> hmm, maybe params for timeout changed. checking
104 2013-09-05 05:42:39 <cfields> gavinandresen: can you do timeout --version or timeout --help? looks like it could be 1 of 2 progs actually called timeout
105 2013-09-05 05:43:22 <gavinandresen> timeout --version or --help just gives me usage
106 2013-09-05 05:43:52 <gavinandresen> cfields: it is the ubuntu 10.04 timeout from the timeout package
107 2013-09-05 05:49:00 <cfields> gavinandresen: mm.. the docs are a bit funny for lucid. is it somehow possible that you don't have coreutils installed in the chroot?
108 2013-09-05 05:49:33 <cfields> (i'll come up with a fix that does away with timeout to avoid the headache, just thinking of a quick fix for now)
109 2013-09-05 05:50:27 <gavinandresen> "coreutils is already the newest version." in the chroot
110 2013-09-05 05:53:32 <cfields> gavinandresen: ok, let's just find the param that makes it barf and i'll drop it for now...
111 2013-09-05 05:54:46 <cfields> gavinandresen: can you try: "timeout 5s ls" ?
112 2013-09-05 05:57:08 <gavinandresen> cfields: timeout 5s ls : works
113 2013-09-05 05:57:22 <gavinandresen> (do you need the "s" ?)
114 2013-09-05 05:57:56 <cfields> yea, that's 5 seconds as opposed to 5m
115 2013-09-05 05:58:36 <cfields> newer timeout has '-k 5s' which means "if SIGTERM didn't work, really kill it with a kill -9 after 5 more sec"
116 2013-09-05 05:58:42 <gavinandresen> mmm. man timeout on the jenkins machine says: time The elapsed time limit in seconds after which the command is terminated.
117 2013-09-05 05:59:24 <cfields> does the man page say what package it comes from?
118 2013-09-05 05:59:49 <gavinandresen> cfields: pretty sure I did an apt-get install timeout
119 2013-09-05 06:00:15 <gavinandresen> ⦠because I needed it for the kill-the-test-after-an-hour functionality (some pulls were hanging pull-tester)
120 2013-09-05 06:00:42 <gavinandresen> man page doesn't say what package it is from
121 2013-09-05 06:01:15 <cfields> gavinandresen: ah, i see
122 2013-09-05 06:01:18 <cfields> http://packages.ubuntu.com/lucid/timeout
123 2013-09-05 06:01:29 <cfields> Please note that recent coreutils (>= 7.5-1) provide a timeout binary as well so you probably won't need this package anymore nowadays.
124 2013-09-05 06:01:41 <cfields> fails to mention, though, that lucid coreutils is 7.4.x
125 2013-09-05 06:03:26 <cfields> gavinandresen: "timeout 3s ls -R /"
126 2013-09-05 06:03:38 <cfields> if that's killed after 3 sec, that's good enough for us and i'll make the change
127 2013-09-05 06:04:09 <gavinandresen> Timeout: aborting command ``ls'' with signal 9
128 2013-09-05 06:04:26 <gavinandresen> works. I'm guessing atoi just ignores the "s" in "3s"
129 2013-09-05 06:05:53 <cfields> ok, that's fine, should be universal that way then
130 2013-09-05 06:06:11 <cfields> actually one more: "timeout 10s ls ."
131 2013-09-05 06:06:25 <cfields> then "echo $?" to be sure the exit code is 0
132 2013-09-05 06:06:25 <jgarzik> ACTION lurks
133 2013-09-05 06:11:53 <gavinandresen> cfields: yup
134 2013-09-05 06:12:10 <cfields> ok. want me to push the fix?
135 2013-09-05 06:12:22 <gavinandresen> yes
136 2013-09-05 06:12:57 <gavinandresen> $? after a killed ls is 137, by the way...
137 2013-09-05 06:13:23 <cfields> ok. i suppose i should ask: i've been operating under the assumption that the git dir is pristine for each run. is that a reasonable assumption, i hope?
138 2013-09-05 06:14:40 <cfields> the git workdir, that is
139 2013-09-05 06:15:15 <gavinandresen> yes, the pull-tester reinitializes the chroot environment then does a fresh git clone / merge
140 2013-09-05 06:15:51 <cfields> ok
141 2013-09-05 06:17:42 <cfields> pushed
142 2013-09-05 06:22:31 <gavinandresen> different error this time!
143 2013-09-05 06:25:00 <cfields> ergh
144 2013-09-05 06:30:27 <Vinnie_win> I'm building a template based peer to peer network simulator for aiding unit testing
145 2013-09-05 06:31:09 <gmaxwell> ... how about buildint actual system tests instead of template wank that will be difficulty to maintain and not actually representative of anything? :P
146 2013-09-05 06:33:41 <Vinnie_win> heh
147 2013-09-05 06:33:45 <Vinnie_win> its for ripple, foolio
148 2013-09-05 06:34:04 <Vinnie_win> you provide the necessary adapters to make it work with whatever
149 2013-09-05 06:34:12 <jgarzik> does Ripple have a real scripting system yet? :)
150 2013-09-05 06:34:18 <Vinnie_win> not sure
151 2013-09-05 06:34:20 <Vinnie_win> don think so
152 2013-09-05 06:35:03 <gmaxwell> oh well, I suppose the maintainability for some centeralized non-OSS thing isn't much of concern for anyone but its authors. Be my guest.
153 2013-09-05 06:35:43 <Vinnie_win> you forget i do most of my develop in an external library and publish those changes regularly as open source
154 2013-09-05 06:36:03 <Vinnie_win> like all the asio multi-protocol handshaking is all in there and its ISC licensed
155 2013-09-05 06:37:58 <cfields> gavinandresen: any specific error? :)
156 2013-09-05 06:38:27 <gavinandresen> cfields: pull-tester should have sent you email with a link to the log
157 2013-09-05 06:38:41 <cfields> ah, didn't realize the new stuff was active
158 2013-09-05 06:38:42 <cfields> checking
159 2013-09-05 06:39:04 <gavinandresen> cfields: http://jenkins.bluematt.me/pull-tester/877bffddb4be4d236e5963f5506cb18b10ad969e/
160 2013-09-05 06:40:31 <cfields> gavinandresen: i suppose nothing's changed wrt dependencies on the build machine?
161 2013-09-05 06:41:02 <gavinandresen> cfields: nope. I'm successfully re-running an old pull-request now to make sure
162 2013-09-05 06:41:14 <cfields> ok, thanks. looking
163 2013-09-05 06:41:57 <cfields> it uses system qt, right? as opposed to a manual install
164 2013-09-05 06:42:32 <gavinandresen> pretty sure, yes
165 2013-09-05 06:42:49 <cfields> ok
166 2013-09-05 07:03:13 <gavinandresen> cfields: if it helps, successful pull-test of an old pull: http://jenkins.bluematt.me/pull-tester/8dc206a1e2715be83912e039465a049b708b94c1/test.log
167 2013-09-05 07:05:34 <gavinandresen> New pull-tester is running in a while true; test-pulls; sleep 1800; done loop
168 2013-09-05 08:09:11 <warren> The bug is not reproducible, so it is likely a hardware or OS problem.
169 2013-09-05 08:09:12 <warren> make: *** [obj/rpcrawtransaction.o] Error 1
170 2013-09-05 08:09:20 <warren> what?...
171 2013-09-05 09:19:33 <gmaxwell> sipa: so... two bits of news... with some fixes phantomcircuit has been working on, headers first first 100k blocks is down to <3 minutes.
172 2013-09-05 09:20:12 <gmaxwell> sipa: second is that I aborted a headers first node midsync and changed back to non-headers first code and it just sits there not attempting to pull blocks.
173 2013-09-05 09:20:43 <gmaxwell> nuking the blocks/chainstate fixes it.
174 2013-09-05 09:21:39 <warren> how many minutes was it with headers first only?
175 2013-09-05 09:22:24 <gmaxwell> warren: slow. ten minutes? dunno a long time.
176 2013-09-05 09:23:14 <gmaxwell> Headers first reduces the maximum batching size way down because it needs to to achieve loadbalancing.. but if you're pulling only from a single peer at least for the initial blocks at the front the message processing delays dominate.
177 2013-09-05 09:23:20 <cfields> gavinandresen: if you're around, can you give the builder a kick? i think that last fix should do it, it'd be nice to see if it works before i go
178 2013-09-05 09:23:26 <warren> I predict headers-first will be bottlenecked on our PoW. not much we can do to improve it.
179 2013-09-05 09:26:13 <gmaxwell> warren: yea, I dunno why the single instance was made so cpu intensive. it's not even just the memory hard part.
180 2013-09-05 09:29:09 <warren> gmaxwell: long before my time, and I'm neutral on this being good or bad. I'm leaning towards bad and can't be changed.
181 2013-09-05 09:30:00 <gmaxwell> warren: well, if you wanted to change it.. I'd suggest doing so now before any hardware is announced. :P
182 2013-09-05 09:30:54 <gmaxwell> might be possible, if a bunch of your miners are ex-bitcoin gpu miner refugees who don't want to be pushed out again. :P
183 2013-09-05 09:31:22 <warren> refugees
184 2013-09-05 09:32:27 <gmaxwell> "our new POW requires texture filtering"
185 2013-09-05 09:32:45 <warren> The mysterious sponsor was ... AMD.
186 2013-09-05 09:33:12 <gmaxwell> texture filtering and a bunch of integer bitops!
187 2013-09-05 09:33:58 <gavinandresen> cfields: it kicked itself, is testing d829ed6f535c9cede5a74841832c7e114d0a94aa now
188 2013-09-05 09:35:36 <cfields> thanks
189 2013-09-05 09:35:58 <warren> gmaxwell: wouldn't that make the PoW validation far worse?
190 2013-09-05 09:36:05 <cfields> gavinandresen: side-note, builds will use ccache if it's available. so you might consider installing it in the chroot to speed things up
191 2013-09-05 09:36:10 <warren> =)
192 2013-09-05 09:38:05 <Eliel> is there a way in a script to push the block headers for the block that contains the txout onto the stack?
193 2013-09-05 09:40:45 <Eliel> if there is, then it's possible to do a coinjoin transaction where it's left to chance which addresse's private keys are required to spend the transaction.
194 2013-09-05 09:41:16 <gmaxwell> Eliel: no, the system seems to have been pretty carefully constructed to decouple the chain and transactionsâ a little too much perhaps. :)
195 2013-09-05 09:41:33 <Eliel> (this might get people getting rid o their dust ;)
196 2013-09-05 09:42:32 <gmaxwell> Eliel: you can actually do 'gamble transactions' but, uh, they don't come out small, which is kinda contrary to your goal.
197 2013-09-05 09:43:10 <gmaxwell> Eliel: e.g. each party provides a hashed value, and to spend you provide both preimages, it hashes them and then uses that to select the pubkey.
198 2013-09-05 09:44:19 <gmaxwell> Eliel: something that did what you wanted would be kinda ugly because the vailidity of a dependant transaction would be non-determinstic until the transaction was mined.. which totally blows away the idea of having an unconfirmed transaction mempool.
199 2013-09-05 09:45:56 <Eliel> you could make the opcode that pushes the headers to stack to have the script fail unless the transaction has at least one confirmation.
200 2013-09-05 09:48:26 <cfields> ffs
201 2013-09-05 09:49:46 <Eliel> gmaxwell: basically, what I'm looking for is a random number generator that's usable in scripts. Provably fair deterministic random number generator, that is.
202 2013-09-05 09:51:32 <gmaxwell> Eliel: well I just gave you one.
203 2013-09-05 09:51:38 <cfields> gavinandresen: i'm not sure what the problem is, but the java test just timed out after 20min
204 2013-09-05 09:51:53 <cfields> i'll have to investigate later
205 2013-09-05 09:52:09 <gavinandresen> cfields: the blockchain tests might take longer than 20 minutes to run
206 2013-09-05 09:52:25 <gavinandresen> (the big re-orgs tests take a lot of time)
207 2013-09-05 09:53:03 <cfields> hmm, ok
208 2013-09-05 09:53:20 <cfields> i wasn't seeing anywhere near that locally, but something must be different
209 2013-09-05 09:53:36 <cfields> i'll bump it to 45 for now
210 2013-09-05 09:53:55 <gavinandresen> why set any timeout?
211 2013-09-05 09:54:05 <gavinandresen> The top-level pull-tester has a timeout set....
212 2013-09-05 09:54:09 <Eliel> gmaxwell: yes, you did. I'll see if I can modify that principle into something that works without bloat.
213 2013-09-05 09:54:59 <gavinandresen> cfields: Also: I installed ccache in the chroot environment
214 2013-09-05 09:55:27 <cfields> gavinandresen: i'd prefer not to make any assumptions (or as few as possible) about the environment, so that devs can be encouraged to run these tests locally and all get the same results
215 2013-09-05 09:56:07 <gavinandresen> ok. Devs will control-C if tests take too long....
216 2013-09-05 09:57:37 <cfields> fair enough
217 2013-09-05 09:59:08 <cfields> pushed. last one for me, time to head out
218 2013-09-05 09:59:11 <cfields> thanks for the patience
219 2013-09-05 10:04:26 <gavinandresen> I need some shed-painting advice...
220 2013-09-05 10:05:19 <gavinandresen> I'm working on smart client-side miner-fee-policy code, and an RPC method that returns the estimate
221 2013-09-05 10:06:37 <gavinandresen> First cut at the API is: https://github.com/gavinandresen/bitcoin-git/commit/2706e891c139b9d55a6ee1a5456c9736f9005925#L3R392
222 2013-09-05 10:07:18 <gavinandresen> Do y'all like the name 'estimateminerpolicy' ?
223 2013-09-05 10:09:33 <gmaxwell> how about "estimatefeepolicy" ? (suggesting removing miner since relaying is also indirectly implicated there) or even just "estimatefees"
224 2013-09-05 10:14:26 <gavinandresen> It is a little weird, because it estimates both fee-needed-to-get-into-a-block and priority-needed-if-zero-fee
225 2013-09-05 10:14:43 <gavinandresen> I'd be ok with estimatefees, though
226 2013-09-05 10:15:11 <gmaxwell> I saw that. "Priority is just another kind of fee." :)
227 2013-09-05 10:15:39 <warren> priority-needed-if-zero-fee is extra weird given it is unpredictable if your peers will relay your tx at all depending on what is already in their mempool.
228 2013-09-05 10:16:11 <warren> I kind of consider that to be a bug, but I hear it is an anti-DoS measure...
229 2013-09-05 10:16:12 <gavinandresen> relaying policy needs to change at the same time, I haven't tackled that yet
230 2013-09-05 10:17:52 <gavinandresen> (I've been looking at active queue management algorithms, and think something like CODEL could work nicely, with lowest fee and/or priority transactions dropped and not relayed)
231 2013-09-05 10:18:45 <gmaxwell> gavinandresen: wrt policy, I have a pull in that twiddles how the free transaction priority works to make transactions that consume many outputs no lower priority than a few.
232 2013-09-05 10:19:05 <warren> and the threshold of what is dropped is dynamic?
233 2013-09-05 10:19:09 <gavinandresen> gmaxwell: I saw that, seems reasonable
234 2013-09-05 10:19:47 <gavinandresen> warren: sure, there would be a queue, and if the queue gets backed up (not enough bandwidth) then transactions are dropped
235 2013-09-05 10:19:55 <sturles> Let me add a suggestion here: If priority >> estimated priority needed for no fee (e.g. 100 times larger), add smallest output < 0.05 BTC to inputs to swipe up some dust.
236 2013-09-05 10:20:27 <gmaxwell> sturles: yes, on the todo list. I have some older local patches for that, but I want the priority scheme adjusted to not disincentivize that anymore.
237 2013-09-05 10:21:01 <gmaxwell> sturles: mike hearn had suggested a pretty different strategy to coin selection in general that I think makes a lot of sense.
238 2013-09-05 10:21:39 <gavinandresen> sturles: yes, good idea, but separate from what I'm trying to do with the smartfee work
239 2013-09-05 10:21:53 <gmaxwell> (basically one which didn't shy at all away from gobbling up inputs if there is change: you're going to consume them eventually anyways)
240 2013-09-05 10:21:56 <warren> Would that have any deanonymizing effect?
241 2013-09-05 10:22:37 <gmaxwell> warren: it can be done in a way that doesn't.
242 2013-09-05 10:23:45 <gmaxwell> warren: select your inputs, then do sturles's refinement pass adding inputs but only considering ones which aren't privacy harming. Less effective than if you ignore privacy, but no tradeoff.
243 2013-09-05 10:23:52 <gmaxwell> Strictly superior to not trying to sweep.
244 2013-09-05 10:24:11 <warren> "ones which aren't privacy harming" means what?
245 2013-09-05 10:24:56 <gmaxwell> warren: inputs paid to the same addresses, for example. Inputs paid to addresses that you've already cojoined with the current addresses (e.g. what listaddressgroupings computes)
246 2013-09-05 10:32:19 <warren> gavinandresen: hmm, i guess with the estimate available to every user, they shouldn't be surprised if their low fee/priority tx is dropped. Currently they have no way to know that is likely to happen before they send it.
247 2013-09-05 10:32:26 <warren> gavinandresen: (in the case of zero fee)
248 2013-09-05 10:35:13 <gavinandresen> cfields: huzzah! Automatic sanity-testing: PASSED
249 2013-09-05 10:45:26 <wumpus> woohoo
250 2013-09-05 10:49:36 <warren> gavinandresen: interesting, estimate based only on mempool? I would have thought an estimate would be based on average delays of certain fee levels to get into recent blocks.
251 2013-09-05 10:53:49 <gmaxwell> "I don't have to outrun the bear, I have to outrun you."
252 2013-09-05 10:54:55 <gmaxwell> Whats actually in blocks is a so/so metric because a lot of weirdness goes into how miners actually pick (e.g. IIRC btcguild, and eligius both have side deals with big services to process selected transactions for them)
253 2013-09-05 10:55:30 <warren> hmm
254 2013-09-05 10:55:45 <warren> I guess my way would encourage collusion too.
255 2013-09-05 10:56:33 <sturles> gmaxwell: Perhaps the level of privacy, or agressiveness, when collecting dust could be a configurable option?
256 2013-09-05 10:58:08 <gmaxwell> sturles: "more stuff to test" personally I'd be happy with just getting something in that was privacy preserving (the conservative option) an enhancing it later.
257 2013-09-05 11:02:39 <sturles> Yes, it's clearly better than status quo.
258 2013-09-05 11:38:52 <cfields> gavinandresen: huzzah indeed. Proposed next steps?
259 2013-09-05 11:59:42 <sipa> gmaxwell: yeah, downgrading to pre-headersfirst... no idea how that would work
260 2013-09-05 11:59:45 <sipa> in fully synced state it should be fine
261 2013-09-05 13:24:31 <sturles> Another coin selection related suggestion: When someone has e.g. 3.8451003 BTC and try to send 3.8451, it fails. They will usually end up sending 3.844 BTC, leaving 0.0010003 BTC in their wallet and 0.0001 BTC as fee, while sending the whole balance (3.8451003) BTC would have worked. This increases dust. (I have examples which I can dig up if you want to see it for yourselves.)
262 2013-09-05 13:25:17 <sturles> Instead of refusing to send 3.8451 BTC in this case, it should just do it taking the entire 3.8451003 BTC as input, producing one output of 3.8451, and leave the rest as fees.
263 2013-09-05 13:26:05 <sturles> Worthless to a miner, but even more worthless to the owner.
264 2013-09-05 13:28:09 <sturles> Here is an example: https://blockchain.info/tx/f0b6a539331d1b6764625d4e3c3d5fad4c735df1d0c4fc9525ca948b21658262
265 2013-09-05 13:29:12 <sturles> I know he tried to send 1.957 BTC, which failed because it would leave a 0.00003 dust output. The resulting 0.00103 output will probably stay forever as uncollected dust.
266 2013-09-05 13:29:34 <sturles> s/1.957/1.958/
267 2013-09-05 14:00:36 <jouke> How many confirmations does a coinbase transaction normally need before it becomes spendable?
268 2013-09-05 14:00:53 <jouke> Mtgox just gave us a transaction that is based on a recent coinbase transaction.
269 2013-09-05 14:02:52 <_dr> 120
270 2013-09-05 14:03:45 <sipa> jouke: yes, apparently they've been doing that for a while
271 2013-09-05 14:03:48 <jouke> \o/
272 2013-09-05 14:04:09 <jouke> always something :,(
273 2013-09-05 14:08:35 <Subo1977_> kinlo: Hi, why i'm banned from #bitcoin?
274 2013-09-05 14:09:11 <jgarzik> sipa, MagicalTux is aware of the issue?
275 2013-09-05 14:09:24 <sipa> no clue
276 2013-09-05 14:11:59 <Subo1977_> some #bitcoin channel-OP here?
277 2013-09-05 14:13:03 <DiabloD3> http://www.mailpile.is/blog/2013-09-05_PayPal_Freezes_Campaign_Funds.html
278 2013-09-05 14:52:50 <plaprade> In HDW (Bip32), are account (depth=1) generated through public or private derivation?
279 2013-09-05 14:55:54 <sipa> plaprade: private
280 2013-09-05 14:56:06 <sipa> it's in the bip
281 2013-09-05 14:56:54 <plaprade> sipa, thanks. I was confused because the graphical image in the BIP seems to suggest public derivation
282 2013-09-05 15:06:02 <plaprade> In the "Use Case" section of bip32, the "Audits" case using M only can not really be implemented if the first layer of accounts is derived through private derivation. The extended key M can not compute M/i' as far as I understand. It could compute M/i however
283 2013-09-05 15:43:15 <Luke-Jr> CVE-2013-5700 assigned for remote bloom filter crash
284 2013-09-05 15:57:54 <maaku> sturles: the coin selection algorithm does exactly what you suggest
285 2013-09-05 15:57:55 <maaku> or rather, the transaction creation (it's not part of coin selection)
286 2013-09-05 15:58:40 <maaku> https://github.com/bitcoin/bitcoin/blob/master/src/wallet.cpp#L1268
287 2013-09-05 15:59:04 <TD> good day
288 2013-09-05 18:16:14 <phrog> anyone know if multibit has a way to addnode?
289 2013-09-05 18:16:56 <midnightmagic> out of curiosity, where are the release notes versioned?
290 2013-09-05 18:18:39 <TD> phrog: not in the gui
291 2013-09-05 18:18:51 <TD> (not as far as i know, anyway)
292 2013-09-05 18:18:55 <TD> phrog: there's a config file i think that supports it
293 2013-09-05 18:19:14 <phrog> oh, i will look into it
294 2013-09-05 18:19:16 <phrog> thanks
295 2013-09-05 18:26:58 <maaku> midnightmagic: contrib/debian/changelog
296 2013-09-05 18:27:35 <maaku> n/m those aren't up to date
297 2013-09-05 18:32:02 <midnightmagic> maaku: thanks anyway :)
298 2013-09-05 18:42:01 <gmaxwell> 07:09 < jgarzik> sipa, MagicalTux is aware of the issue?
299 2013-09-05 18:42:16 <gmaxwell> I attempted to report it, I'd only give the cances that he got it at 25%
300 2013-09-05 18:51:56 <phantomcircuit> gmaxwell, report what?
301 2013-09-05 18:54:47 <gmaxwell> phantomcircuit: that they are spending immature coins.
302 2013-09-05 18:55:02 <gmaxwell> Resulting in customers complaining that its taking them enos to get confirmation.
303 2013-09-05 18:55:13 <gmaxwell> (esp since the immature spends don't realy)
304 2013-09-05 18:55:23 <phantomcircuit> gmaxwell, spending immature coins as in spending coinbase coins without 120 confirms?
305 2013-09-05 18:55:25 <gmaxwell> phantomcircuit: Immature meaning freshly generated coins.
306 2013-09-05 18:55:27 <gmaxwell> Yes.
307 2013-09-05 18:55:40 <phantomcircuit> lol
308 2013-09-05 18:55:50 <gmaxwell> phantomcircuit: the network rule is 100, not 120. But yep.
309 2013-09-05 18:55:53 <phantomcircuit> i bet someones sending coinbase outputs directly to mtgox
310 2013-09-05 18:56:05 <phantomcircuit> where they're probably being accepted after 6 confirms
311 2013-09-05 18:56:08 <gmaxwell> sure lots of eligius miners do.
312 2013-09-05 18:57:50 <phantomcircuit> hmm so that's a nuisance but probably not a security issue
313 2013-09-05 18:58:01 <phantomcircuit> i'll make sure he gets the message though
314 2013-09-05 18:58:16 <gmaxwell> They've probably lost a small amount of coin that way, e.g. during the big fork.
315 2013-09-05 18:58:34 <gmaxwell> But yea, not generally a security issue.
316 2013-09-05 18:59:00 <phantomcircuit> it might be worth it to get all those miners business
317 2013-09-05 18:59:06 <gmaxwell> But certantly a usability issue... also, he's been blaming the network for the slow confirmations.. :(
318 2013-09-05 18:59:25 <phantomcircuit> at somepoint someone tried to do that with intersango and it correctly bared and told them to go away
319 2013-09-05 18:59:51 <phantomcircuit> barfed*
320 2013-09-05 19:25:15 <gmaxwell> phantomcircuit: if you look back in the #mtgox logs you can see me give an example txid.
321 2013-09-05 19:40:31 <phantomcircuit> gmaxwell, im sure he has it in his logs
322 2013-09-05 19:41:06 <phantomcircuit> bleh
323 2013-09-05 19:41:15 <phantomcircuit> using djanog is such a pain for anything complex
324 2013-09-05 19:43:48 <jgarzik> NY Times: N.S.A. Foils Much Internet Encryption http://www.nytimes.com/2013/09/06/us/nsa-foils-much-internet-encryption.html?partner=rss&emc=rss&utm_source=twitterfeed&utm_medium=twitter&_r=0
325 2013-09-05 19:48:37 <phantomcircuit> jgarzik, :/
326 2013-09-05 19:51:13 <phantomcircuit> jgarzik, that seems to be largely saying the same thing we've prety much known all along
327 2013-09-05 19:51:32 <phantomcircuit> that if your communications are in cleartext in the hands of anybody else they should be considered compromised
328 2013-09-05 19:53:21 <phantomcircuit> i wonder what it would take to build a javascript openpgp client
329 2013-09-05 19:53:26 <phantomcircuit> im guessing something horrendous
330 2013-09-05 19:55:13 <jgarzik> I would love to know the standard "adopted in 2006 by NIST" that was weaked by the NSA
331 2013-09-05 19:55:50 <jgarzik> ACTION recalls a couple somewhat-last-minute changes to magic numbers, in some standard algorithms, by NSA
332 2013-09-05 19:55:56 <jgarzik> including SHA256?
333 2013-09-05 19:55:58 <jgarzik> ACTION tries to recall
334 2013-09-05 19:56:16 <warren> didn't someone prove that one of those last minute changes made something stronger?
335 2013-09-05 19:57:42 <warren> although it was decades ago
336 2013-09-05 19:59:13 <Cusipzzz> that was DES
337 2013-09-05 20:01:07 <phantomcircuit> jgarzik, the SHA-2 competition wasn't even announced until 2007
338 2013-09-05 20:01:21 <phantomcircuit> a more likely candidate is AES
339 2013-09-05 20:01:32 <DiabloD3> phantomcircuit: er you mean 3?
340 2013-09-05 20:01:33 <phantomcircuit> actually no that was 2001
341 2013-09-05 20:01:37 <phantomcircuit> wow that was ages ago
342 2013-09-05 20:01:47 <jgarzik> well regardless of date, I am curious about all algorithms with magic numbers sourced from the NSA :)
343 2013-09-05 20:01:51 <DiabloD3> sha2 existed before 9/11 bro
344 2013-09-05 20:01:58 <phantomcircuit> DiabloD3, oh you're right
345 2013-09-05 20:02:05 <jgarzik> some algos specifically source magic numbers from a printed, dead tree book of magic numbers for this reason
346 2013-09-05 20:02:09 <jgarzik> *well known
347 2013-09-05 20:02:18 <phantomcircuit> DiabloD3, confusingly they dont number the competitions...
348 2013-09-05 20:02:21 <DiabloD3> hell, I remember asking people to use it when I was still in high school
349 2013-09-05 20:02:43 <DiabloD3> because md5 was unsafe and sha1 was becoming unsafe
350 2013-09-05 20:02:56 <jgarzik> it sounds like NSA has not broken strong crypto, when used correctly
351 2013-09-05 20:03:17 <phantomcircuit> jgarzik, yeah SHA-2 was 2001
352 2013-09-05 20:03:28 <jgarzik> however, it seems wise to mix algorithms, not just use multiple rounds of the same algo
353 2013-09-05 20:03:38 <DiabloD3> jgarzik: yes
354 2013-09-05 20:03:38 <jgarzik> i.e. ripemd160 + sha256, for example :)
355 2013-09-05 20:04:17 <phantomcircuit> jgarzik, http://csrc.nist.gov/publications/PubsFIPS.html
356 2013-09-05 20:04:23 <phantomcircuit> Personal Identity Verification (PIV) of Federal Employees and Contractors
357 2013-09-05 20:04:27 <phantomcircuit> Minimum Security Requirements for Federal Information and Information Systems
358 2013-09-05 20:04:55 <phantomcircuit> possibly there's a backdoor in the PIV system so the NSA can search federal records without a warrant?
359 2013-09-05 20:05:21 <phantomcircuit> which would explain how snowden has all this info and they cant figure out what it is he has or how he got it...
360 2013-09-05 20:08:57 <gmaxwell> jgarzik: thanks for that memory hard kdf paper, I believe I like theirs better than scrypt.
361 2013-09-05 20:23:58 <jgarzik> gmaxwell, it looked useful, though thank reddit/r/bitcoin not me
362 2013-09-05 20:24:03 <jgarzik> man
363 2013-09-05 20:24:15 <jgarzik> I really do think the NSA had some last-minute changes to SHA-2
364 2013-09-05 20:24:21 <jgarzik> but my google-fu is weak
365 2013-09-05 20:25:08 <gmaxwell> To SHA-2? hm? no, IIRC sha-2 appeared from mysterous sources fully formed. To DES, yes.
366 2013-09-05 20:25:53 <gmaxwell> (well not that mysterious, sha-2 is from the NSA.. it wasn't the result of a public design effort like sha3)
367 2013-09-05 20:26:16 <gmaxwell> (NSA also created SHA-1)
368 2013-09-05 20:29:42 <kjj> if the NSA knows a break in SHA, it isn't one that we can imagine. h and k are derived from primes (the cryptographic version of rolling up your sleeves)
369 2013-09-05 20:30:35 <gmaxwell> kjj: when you pick your own nothing up your sleeve numbers they're not really accomplishing that purpose.
370 2013-09-05 20:31:24 <gmaxwell> kjj: e.g. say the weakness worked for many constants but not all.. says 1 in 10.. so then have your mathematicians invent 20 different plausable nothing up my sleeve parameters and then pick the one that your technique works best on.
371 2013-09-05 20:32:11 <kjj> h comes from the square roots of the first 8 primes, and k comes from the cube roots of the first 64 primes
372 2013-09-05 20:32:51 <kjj> you could make the argument about picking the square and cube root operations, but it seems like a reach
373 2013-09-05 20:55:11 <maaku> jgarzik: i think you're thinking of SHA-1, which had a last minute NSA tweak
374 2013-09-05 20:55:34 <maaku> although it was later shown to increase resistance to an attack that wasn't public yet
375 2013-09-05 20:57:48 <gmaxwell> maaku: are you sure about that? what you're describing is also correct for DES (sbox construction replaced to increase resistance to differential cryptanalysis)
376 2013-09-05 20:59:47 <jgarzik> what SSL and other crypto standards need is the ability to specify chains of algorithms, and round counts for each
377 2013-09-05 20:59:52 <maaku> http://en.wikipedia.org/wiki/SHA-1#SHA-0
378 2013-09-05 20:59:55 <jgarzik> in the negotiation strings and such
379 2013-09-05 21:00:23 <gmaxwell> jgarzik: its surprisingly easy to create vulnerabilities through compositions though. :(
380 2013-09-05 21:01:20 <gmaxwell> jgarzik: I assume you've seen the latest schneier writeups? http://www.theguardian.com/commentisfree/2013/sep/05/government-betrayed-internet-nsa-spying
381 2013-09-05 21:01:27 <jgarzik> on G+, having some good discussions about deterministic builds
382 2013-09-05 21:01:34 <jgarzik> with the Linux/FOSS kernel hacker crowd
383 2013-09-05 21:01:51 <jgarzik> a "how bitcoin does it" blog post or whitepaper would be very timely
384 2013-09-05 21:01:58 <gmaxwell> esp the talk about weaknesses introduced through "bugs" rather than weak cryptographic objects.
385 2013-09-05 21:02:17 <jgarzik> in fact, I think this is so important to software, I shall do so
386 2013-09-05 21:02:31 <jgarzik> Linux distros need deterministic builds, pronto
387 2013-09-05 21:02:36 <gmaxwell> jgarzik: great, if you write I'll be available to review.
388 2013-09-05 21:03:34 <gmaxwell> There are weaknesses in what we doâ e.g. it rests on trusting a non-determinstic distro. :( really the whole thing should be built up from nothing but a VM, a kernel, and tinyc ... but thats a lot of computation which you'd prefer to not do just for one package.
389 2013-09-05 21:05:22 <maaku> gmaxwell: but making scripts for building a 'GitianOS' might be a good FOSS project, if this is something everyone is going to start doing
390 2013-09-05 21:06:51 <gmaxwell> maaku: luke apparently has some plan to make gentoo's build process deterministic (since gentoo is already pretty close to 'GitianOS')
391 2013-09-05 21:07:17 <cfields> gmaxwell: for osx cross, i'm working on a system that is deterministic down to the toolchain level
392 2013-09-05 21:07:32 <cfields> which is essentially the same as gitian, except without the reliance on a distro, the toolchain can be plugged in
393 2013-09-05 21:07:32 <gmaxwell> jgarzik: if people start fearmongering about backdoored gcc, link them to diverse double compilation.
394 2013-09-05 21:07:50 <cfields> that can be taken further if desired by bootstrapping/building the toolchain itself
395 2013-09-05 21:08:01 <maaku> cfields: assuming the apple xcode binaries as input?
396 2013-09-05 21:08:14 <cfields> maaku: no, built on linux
397 2013-09-05 21:08:27 <cfields> well.. assuming the xcode sdk
398 2013-09-05 21:08:30 <gmaxwell> cfields: a determinstic build is not determinstic without a determinstic toolchain. The use of a distro in gitian is just one way (one of the few ways) to get a deterministic toolchain.
399 2013-09-05 21:09:00 <cfields> gmaxwell: understood and agreed. my point is that gitian is tied to a distro rather than a toolchain, which i consider to be a significant caveat
400 2013-09-05 21:09:55 <gmaxwell> cfields: but there aren't other easy ways on foss systems to get a deterministic toolchain. For example, that toolchain must include libc and libstdc++ ... there are a _few_ people who do cross compiles who setup different libcs to compile against but its fairly uncommon.
401 2013-09-05 21:10:18 <jgarzik> my kernel colleague and professional root hole finder (man, that sounds dirty) Al Viro talked about backdoor'd gcc and turning remotely obtained C code into local exploits over 10 years ago :)
402 2013-09-05 21:10:53 <cfields> gmaxwell: ok, i suppose i misspoke. I'm working on a system that is deterministic, given any X toolchain
403 2013-09-05 21:10:53 <tgs3> jgarzik: talked, as in... joked?
404 2013-09-05 21:11:08 <jgarzik> he will tell wonderful stories about how all our Linux file utilities suck, and are full of exploitable races
405 2013-09-05 21:11:20 <cfields> from there, the next step would be to come up with an X toolchain that is deterministic for use
406 2013-09-05 21:11:56 <jgarzik> non-root users may therefore interfere with a root user's file tree walking, and trigger the root priv'd process to do unexpected things
407 2013-09-05 21:12:02 <jgarzik> race fun
408 2013-09-05 21:12:09 <gmaxwell> cfields: right. I understand what you're doing.
409 2013-09-05 21:12:40 <cfields> gmaxwell: and i understand your point as well. baby steps :)
410 2013-09-05 21:13:38 <jgarzik> hah! another fun theory: SecureRandom and other RNG fun was known/placed/encouraged/not reported by the NSA. And bitcoin thefts then helpfully exposed this weakness.
411 2013-09-05 21:13:43 <jgarzik> "helpfully"
412 2013-09-05 21:14:49 <tgs3> jgarzik: I know a software project that fixes this problems
413 2013-09-05 21:15:03 <tgs3> well, at least that is inside of their goals ;)
414 2013-09-05 21:15:38 <jgarzik> the kernel hacker that maintains the /dev/random subsystem is noting with self-satisfaction how he resisted the call to make cpu instruction RDRAND push directly into the entropy pool without any other mixing
415 2013-09-05 21:17:43 <gmaxwell> jgarzik: I think one useful thing we can do is spend some time thinking about how to create backdoors. .. it's fun anyways, and maybe we'll reinvent one that already exists.
416 2013-09-05 21:18:12 <gmaxwell> jgarzik: E.g. I've implemented two different "evil quill" â ecdsa signers that are maximally malicious and leak your private keys in somewhat subtle ways.
417 2013-09-05 21:18:47 <gmaxwell> I'm pretty sure that I could pass off the code of one of them to at least shallow public inspection too.
418 2013-09-05 21:18:49 <jgarzik> gmaxwell, Mental model comment: just like Google builds a reliable datasystem atop unreliable hardware, can we build reliable distributed cryptosystems atop untrusted hardware? :)
419 2013-09-05 21:19:37 <gmaxwell> jgarzik: Thats what we're already doing! (and the whole nodes verify everything model really helps that) But yea, how do we do more of that?
420 2013-09-05 21:23:46 <Cusipzzz> would really like to know what "specific facts" were removed from the articles
421 2013-09-05 21:30:41 <jgarzik> anyone see this bit?
422 2013-09-05 21:30:43 <jgarzik> from one of the articles: "Prefer conventional discrete-log-based systems over elliptic-curve systems; the latter have constants that the NSA influences when they can."
423 2013-09-05 21:31:00 <jgarzik> what's the source of our curve? :)
424 2013-09-05 21:31:56 <warren> jgarzik: Satoshi was NSA?
425 2013-09-05 21:32:02 <Cusipzzz> O_o
426 2013-09-05 21:33:18 <edcba> don't devaluate my btc with your crazy theories ! :)
427 2013-09-05 21:34:02 <helo> prematurely overvalue by assuming soundness?
428 2013-09-05 21:35:20 <Cusipzzz> tanking/forums drama imminent
429 2013-09-05 21:35:32 <edcba> jgarzik: we use some "well known" curves now we just have to see if NSA does know more than us about them :p
430 2013-09-05 21:36:04 <edcba> maybe there is a paper on how they got chosen
431 2013-09-05 21:37:42 <edcba> https://bitcointalk.org/index.php?topic=151120.0 old topic about choice of curves
432 2013-09-05 21:42:25 <gmaxwell> Our curve is not one of the ones the NSA normally pushes, but that doesn't mean it's not one that they influenced. OTOH, if NSA's parameter influence in things like P224 weakens them this means that the NSA has some powerful math not known to the public.
433 2013-09-05 21:43:26 <edcba> i still didn't find how those koblitz curves have been chosen
434 2013-09-05 21:44:28 <maaku> edcba: who choose the specific koblitz curve that was standardized?
435 2013-09-05 21:44:31 <maaku> that's the argument
436 2013-09-05 21:44:42 <edcba> nist it seems
437 2013-09-05 21:44:50 <edcba> it's not nsa we're safe ! :)
438 2013-09-05 21:44:51 <maaku> nist == nsa
439 2013-09-05 21:44:54 <maaku> for cryptography
440 2013-09-05 21:44:56 <Cusipzzz> seems legit
441 2013-09-05 21:45:36 <edcba> found a question about it : http://crypto.stackexchange.com/questions/9668/how-were-secpk1-elliptic-curve-generators-chosen
442 2013-09-05 21:46:10 <edcba> haha love the first sentence of answer
443 2013-09-05 21:46:30 <maaku> imho concern over this is tin foil paranoia, but yes, these nist crypto standards were written by the nsa, and yes they contain arbitrarily chosen values
444 2013-09-05 21:47:23 <gmaxwell> It's not especially interesting in the context of bitcoin, I agree. Though at some point we should probably add support for an alternative public key scheme, lamport being the obvious choice.
445 2013-09-05 21:48:20 <edcba> i missed some obvious step
446 2013-09-05 21:48:32 <gmaxwell> (because the security proof is very simple and intutive, and its strong against quantum computersâ so we get a pat answer to any fearmongering over that)
447 2013-09-05 21:49:15 <jgarzik> rofl "3d6. it may not be elliptic, but it's a curve."
448 2013-09-05 21:49:43 <edcba> so the security will remain in the secure prng and our OS guarantees a secure prng far away from the influence of NSA ! :)
449 2013-09-05 21:50:21 <Cusipzzz> *your OS may vary, void where prohibited
450 2013-09-05 21:50:29 <gmaxwell> edcba: what are you talking about there?
451 2013-09-05 21:50:54 <gmaxwell> There is no need to build cryptosystems that depend on the OS providing a secure PRNG.
452 2013-09-05 21:50:57 <edcba> just kidding the prng part is same for every crypto stuff
453 2013-09-05 21:51:46 <edcba> gmaxwell: nsa have "introduced" some secure prng in windows with dubious parameters
454 2013-09-05 21:51:58 <edcba> now it's normally not used by default
455 2013-09-05 21:52:17 <gmaxwell> edcba: yea sure, no one used EC_DUAL, I'm not sure why anyone would.
456 2013-09-05 21:52:40 <edcba> i guess nsa does it so it can watches what their staff is doing
457 2013-09-05 21:52:48 <edcba> or maybe they don't :)
458 2013-09-05 21:56:49 <wiretapped> in secp256k1 we trust
459 2013-09-05 21:57:42 <edcba> gmaxwell: it seems lamport stuff is heavier than ecc ?
460 2013-09-05 21:58:59 <Luke-Jr> much
461 2013-09-05 21:59:51 <gmaxwell> edcba: what do you mean by heavier?
462 2013-09-05 21:59:56 <gmaxwell> It's enormously faster to validate.
463 2013-09-05 22:00:01 <edcba> more bytes
464 2013-09-05 22:00:08 <gmaxwell> The signatures are indeed longer.
465 2013-09-05 22:00:19 <edcba> nasty heavy bytes
466 2013-09-05 22:01:09 <gmaxwell> With the best compression scheme I've come up with you're still taking about about 12kbyte signature+pubkey for 256 bit security.
467 2013-09-05 22:02:00 <gmaxwell> but it's all in the scriptsig, and could be structured so that the signature was prunable in the deep history... so I don't think it's non-viable, you might not want it for daily use.
468 2013-09-05 22:02:40 <edcba> i don't like pruning :/
469 2013-09-05 22:02:57 <gmaxwell> edcba: you're probably confused then.
470 2013-09-05 22:03:36 <gmaxwell> At least in the case of the existing bitcoin system pruning doesn't represent even the sightest reduction in the security model.
471 2013-09-05 22:03:45 <gmaxwell> (though what I described there would be)
472 2013-09-05 22:04:27 <edcba> yes it's just some maintanibility problem
473 2013-09-05 22:04:44 <gmaxwell> maintanibility problem?
474 2013-09-05 22:05:25 <edcba> if the network has not the data to validate you need to add it to codez
475 2013-09-05 22:05:28 <edcba> -z
476 2013-09-05 22:07:36 <gmaxwell> edcba: huh no! that would violate the security model. That isn't what pruning does.
477 2013-09-05 22:08:08 <gmaxwell> If you add the data to the code you remove transparency and then have to trust the developers of your software without being able to vaidate their work.
478 2013-09-05 22:08:39 <gmaxwell> edcba: with pruing the was satsoshi described it in his paper you still validate everything, you just don't need to store it.
479 2013-09-05 22:08:40 <maaku> edcba: if you prune, you keep *ALL* the data you need to validate future transactions. you *only* remove data that can be proven not to be required to validate new transactions
480 2013-09-05 22:09:15 <edcba> for your node only, no ?
481 2013-09-05 22:09:31 <maaku> what do you mean?
482 2013-09-05 22:09:41 <maaku> you have all the information necessary to validate any transaction
483 2013-09-05 22:09:45 <edcba> ie you know you validated some old tx so you discard the data you used to validate it
484 2013-09-05 22:10:04 <maaku> yes, but why do you need to validate a transaction you've already validated?
485 2013-09-05 22:10:20 <maaku> you put it aside in a box you label 'already validated transactions'
486 2013-09-05 22:10:34 <edcba> you don't but if every node does that a new comer won't be able to validate those old tx no ?
487 2013-09-05 22:10:52 <edcba> since nobody has the data anymore
488 2013-09-05 22:10:55 <maaku> ... which is why there will be plenty of people running full nodes
489 2013-09-05 22:11:19 <maaku> nobody is suggesting that every node prune
490 2013-09-05 22:11:21 <gmaxwell> maaku: please don't use the word full node there.
491 2013-09-05 22:11:26 <edcba> haha
492 2013-09-05 22:11:33 <gmaxwell> edcba: they'll just get it from a node that has the data.
493 2013-09-05 22:11:35 <maaku> gmaxwell: ?
494 2013-09-05 22:11:48 <gmaxwell> maaku: a pruned node is a full node.
495 2013-09-05 22:11:54 <maaku> i didn't claim that
496 2013-09-05 22:12:01 <maaku> i was talking about full nodes
497 2013-09-05 22:12:03 <edcba> ok i see i have it right i don't like pruning :)
498 2013-09-05 22:12:09 <gmaxwell> maaku: No, I'm stating a fact. A pruned node is a full node.
499 2013-09-05 22:12:18 <gmaxwell> maaku: You perhaps meant "archive node"
500 2013-09-05 22:12:46 <edcba> a more central node than the others :p
501 2013-09-05 22:12:47 <maaku> ok archive node
502 2013-09-05 22:12:57 <gmaxwell> edcba: in any case, any new node is _required_ to go get the data from a node that has itâ either an archive node that has all of it, or some pruned node that has a fraction of it.
503 2013-09-05 22:13:20 <edcba> yes but i prefer when all nodes have the data than 0 :)
504 2013-09-05 22:13:23 <gmaxwell> edcba: and every pruned node can just keep some fraction of the history.
505 2013-09-05 22:13:46 <edcba> random fractional pruning is better indeed
506 2013-09-05 22:13:46 <gmaxwell> edcba: pruned DOES NOT MEAN 0. If there is 0 then it becomes impossible to start a new node.
507 2013-09-05 22:13:46 <maaku> edcba: i also want a unicorn and a 2-day work week
508 2013-09-05 22:14:31 <edcba> gmaxwell: not impossible if you give a "starter pack" with the client
509 2013-09-05 22:14:51 <edcba> that's the maintenance thing i wouldn't like
510 2013-09-05 22:15:05 <gmaxwell> edcba: that would be insecure. You could also run a client that sends its private keys to me. Many things are possible.
511 2013-09-05 22:15:18 <gmaxwell> That doesn't make them wise or likely.
512 2013-09-05 22:15:31 <edcba> not really insecure since you already trust the client code
513 2013-09-05 22:15:46 <gmaxwell> edcba: and I realize thats the "maintenance" thing you dislike, and I'm pointing out that you are misunderstanding pruning in that you think it even remotely implies that.
514 2013-09-05 22:15:49 <edcba> just it has a bit more data than genesis
515 2013-09-05 22:16:07 <edcba> it theoritically implies that
516 2013-09-05 22:16:08 <gmaxwell> edcba: no, you don'tâ you only trust the client code because it is transparent and you (and anyone else) can audit it completely.
517 2013-09-05 22:16:18 <gmaxwell> No. It does not imply that.
518 2013-09-05 22:16:24 <gmaxwell> Which is what I'm trying to tell you.
519 2013-09-05 22:16:28 <edcba> if there is no archiving node
520 2013-09-05 22:16:57 <maaku> edcba: come up with a reason why there wouldn't be an achive node, or you're just trolling
521 2013-09-05 22:17:26 <edcba> i just don't like to add some external dependancy
522 2013-09-05 22:17:33 <edcba> especially if it's not code
523 2013-09-05 22:17:50 <edcba> i must trust someone running an archive node
524 2013-09-05 22:17:53 <maaku> then you must hate bitcoin as is, because it is exactly the same
525 2013-09-05 22:17:57 <edcba> no
526 2013-09-05 22:18:01 <maaku> no, there is no trust in the archive node. zero
527 2013-09-05 22:18:09 <gmaxwell> edcba: then you just get the data from other nodes, likewise if there is no bitcoin nodes today it doesn't work.
528 2013-09-05 22:18:17 <edcba> ok 'trust' is not the work
529 2013-09-05 22:18:18 <edcba> word
530 2013-09-05 22:18:41 <edcba> i have to rely on someone providing a service that a normal bitcoin client doesn't
531 2013-09-05 22:18:48 <edcba> that's SaaS model :)
532 2013-09-05 22:19:05 <gmaxwell> maaku: I don't think we should _assume_ that there will be archive nodesâ because, why would people run one if its very costly?â, but it can work without them.
533 2013-09-05 22:20:05 <maaku> gmaxwell: i'm saying that there are economic incentives for people who hold bitcoins or do business in bitcoins to make sure that an archiving apocolypse doesn't happen
534 2013-09-05 22:20:36 <gmaxwell> maaku: perhaps, or they could tell people to use a webwallet... in any case, it doesn't matter because we don't even need to assume they exist (though they are helpful)
535 2013-09-05 22:20:49 <edcba> ppl have economy incentives not to put all their data in cloud they still do it
536 2013-09-05 22:21:13 <maaku> gmaxwell: the people running the webwallet (assuming they have a revenue stream) would have incentive to run an archive node
537 2013-09-05 22:22:09 <edcba> ok see pruning may have some issues that's why i don't like it
538 2013-09-05 22:22:17 <gmaxwell> maaku: I don't know about that, I think they have an incentive to making running your own node as costly as possible. But I think we're arguing an irrelevant point.
539 2013-09-05 22:22:31 <gmaxwell> edcba: what are you talking about?
540 2013-09-05 22:23:02 <edcba> i thought i made the point pruning may at least be a theoritical problem
541 2013-09-05 22:23:11 <gmaxwell> edcba: no, you really didn't.
542 2013-09-05 22:23:23 <edcba> ok i give up then :)
543 2013-09-05 22:23:32 <gmaxwell> maaku: there doesn't need to exist a single complete copy anywhere, so long is there is a distributed copy. E.g. each pruned node will keep some configurable fraction of the history... so you can go gather the distributed data you need.
544 2013-09-05 22:24:06 <edcba> that just leads to more bandwidth used
545 2013-09-05 22:24:15 <gmaxwell> edcba: uh. wtf?
546 2013-09-05 22:24:26 <edcba> less memory = more bandwidth
547 2013-09-05 22:24:35 <edcba> used by network
548 2013-09-05 22:25:03 <gmaxwell> edcba: The bandwidth is the ~same. You need one copy of all the blocks to bootstrap, so you go fetch them. Upto some small overheads it doesn't matter if you fetch them from one peer or many.
549 2013-09-05 22:25:07 <edcba> globally
550 2013-09-05 22:25:12 <edcba> not for a given client
551 2013-09-05 22:25:20 <gmaxwell> edcba: right, globally.
552 2013-09-05 22:25:41 <edcba> you ought to think globally when you code a p2p client :/
553 2013-09-05 22:25:44 <gmaxwell> edcba: to introduce a new node the global bandwidth used is whatever is required to give them the history
554 2013-09-05 22:27:19 <gmaxwell> edcba: are you going to explain where your bandwidth argument is coming from?
555 2013-09-05 22:29:17 <theymos> How possible is it that secp256k1's parameters were chosen to be particularly weak? It is a non-random curve. I always thought that choosing a Koblitz curve was a smart move, but some of this NSA hubbub is making me not so sure. Perhaps an OP_NOP should be used to add new algorithms.
556 2013-09-05 22:29:59 <gmaxwell> theymos: the public doesn't know of a way in which these parameters could be weak.
557 2013-09-05 22:30:28 <gmaxwell> I agree that it was a smart move.
558 2013-09-05 22:31:03 <maaku> theymos: if you find a reason that the Koblitz curve could be weak, could I be co-author?
559 2013-09-05 22:31:19 <theymos> I do find it hard to believe that a government agency could be competent enough to figure out something that all of academia doesn't know and then manage to keep it secret for years.
560 2013-09-05 22:31:25 <gmaxwell> I also thinkâ and have for a long timeâ that we probably ought to add a secondary unrelated public key signature system, which would help remove any concerns.
561 2013-09-05 22:32:25 <gmaxwell> theymos: oh well, the "canonical" example is differential cryptanalysis in the DES sbox selection. ... but that was also a long time ago. The NSA is one of the largest employers of mathmaticians in the world, so ... things are possible, hard to say how likely.
562 2013-09-05 22:33:09 <maaku> gmaxwell: there's also the SHA-0 weakness, and "asymmetrical cryptography" (public-key) which we know the NSA had earlier
563 2013-09-05 22:33:36 <maaku> actually it was GCHQ that came up with public key crypto
564 2013-09-05 22:33:55 <gmaxwell> theymos: there are a couple of paths we could go for a CHECKSIG2 ... obviously we could fix a couple of silly nits and make the sighash flags more useful.
565 2013-09-05 22:34:40 <edcba> theymos: differential analysis ?
566 2013-09-05 22:34:58 <gmaxwell> theymos: one possibility would be implementing lamport signatures, which have the marking advantage of being strong against quantum computers. They're also insanely fast, and their security is simple and intutive. Downside is that they result is rather huge signatures.
567 2013-09-05 22:35:18 <maaku> gmaxwell: any thoughts on SIGHASH modes beyond Alan's WITHINPUTVALUE ?
568 2013-09-05 22:35:20 <theymos> Several very different algorithms could be supported by CHECKSIG2 so a need to fix a future weakness is less likely.
569 2013-09-05 22:35:31 <theymos> gmaxwell: How big are the signatures?
570 2013-09-05 22:36:02 <gmaxwell> theymos: with the best compression scheme I've been able to come up withâ about 12kb for a 256 bit signature+pubkey.
571 2013-09-05 22:36:09 <theymos> That's not so bad.
572 2013-09-05 22:36:27 <gmaxwell> It's viable at least. Especially as a secondary "just in case/high security" option.
573 2013-09-05 22:36:43 <gmaxwell> maaku: I have a more general vision.
574 2013-09-05 22:37:16 <maaku> i'd love to hear it, or point to it if you've already written it up
575 2013-09-05 22:37:21 <gmaxwell> maaku: I'd like to have a "signature stack" and then operations that push on the data you want covered under the signatures with tagged elements in the stack. So then you can just choose what is being added.
576 2013-09-05 22:38:37 <gmaxwell> maaku: so if you want to, say, sign that there is an output to pubkey X, if and only if the output is >3 BTC you could do that. Achieving alan's with input value would be as simple as having the operation that pushes the inputs on able to also push their values.
577 2013-09-05 22:39:02 <gmaxwell> maaku: and then you just sign the content of the signature stack.
578 2013-09-05 22:39:34 <theymos> Perhaps the existing alt stack could be used for that? No one uses it for anything else.
579 2013-09-05 22:39:37 <maaku> that makes sense, and then i assume you have a sighash opcode that pushes the signature hash on the stack
580 2013-09-05 22:39:56 <maaku> theymos: i can think of one case specific to Freimarkets where we'd use them both side-by-side
581 2013-09-05 22:41:06 <gmaxwell> theymos: It could just be effectively internal to the signature scheme. All the the push operations could be part of the signature if you want.
582 2013-09-05 22:43:01 <gmaxwell> In any case, having that would allow you to specify something like "I sign this 1BTC over to any transaction which pays at least 1 BTC to wikileaks".. or have things like SIGHASH_SINGLE that signe for N outputs (say a bounty and your change) instead of just one.
583 2013-09-05 22:43:08 <gmaxwell> but thats an aside wrt cryptosystem.
584 2013-09-05 22:45:09 <phantomcircuit> gmaxwell, ok he got the message
585 2013-09-05 22:45:21 <theymos> Is Ed25519(?) mature enough to include in Bitcoin?
586 2013-09-05 22:45:34 <gmaxwell> it is but I don't think its horribly desirable.
587 2013-09-05 22:45:41 <theymos> Why?
588 2013-09-05 22:45:58 <gmaxwell> It's hardly faster than what we have now (with sipa's code) so the only protection it provides is parameter paranoia.
589 2013-09-05 22:46:13 <phantomcircuit> gmaxwell, iirc it doesn't require entropy for signing
590 2013-09-05 22:46:20 <gmaxwell> phantomcircuit: nor does what we have now.
591 2013-09-05 22:46:39 <gmaxwell> It doesn't require it the same way ECDSA can optional not require it.
592 2013-09-05 22:46:41 <phantomcircuit> k doesn't have to be random?
593 2013-09-05 22:46:54 <gmaxwell> phantomcircuit: no, http://tools.ietf.org/html/rfc6979
594 2013-09-05 22:47:07 <theymos> Ah, OK. Is there anything more conservative than ECDSA w/ secp256k1 but smaller than lamport signatures?
595 2013-09-05 22:47:12 <gmaxwell> (which is what Ed25519 does)
596 2013-09-05 22:47:33 <phantomcircuit> Deterministic DSA and ECDSA
597 2013-09-05 22:47:35 <phantomcircuit> huh interesting
598 2013-09-05 22:48:42 <gmaxwell> theymos: Conservative against what is the question. E.g. larger ECDSA is more conservative than smaller... but if someone can break secp256k1 ... then perhaps they can break arbitrary EC-DLP? Or only smaller EC-DLP? if so how big? ECC gets slow if your values become large too...
599 2013-09-05 22:49:47 <gmaxwell> theymos: one possibility with lamport is that you could choose to construct the seralization so that the network could forget parts of the signature once the signature is burried in the chain. This would remove much of the storage costs... but it would be an interesting, if small, change to the security model.
600 2013-09-05 22:50:16 <phantomcircuit> gmaxwell, so this is more or less k = HASH(message)
601 2013-09-05 22:50:18 <phantomcircuit> interesting
602 2013-09-05 22:50:42 <gmaxwell> phantomcircuit: H(message) would be insecure: K can't be known to the attacker, it's effectively H(secret key || message).
603 2013-09-05 22:51:14 <gmaxwell> theymos: lamport signatures can be fractionally verified. so.. e.g. you use the block hash of the block confirming a transaction to decide which part of the lamport signature you keep once the txn isâ say 2016 blocks burried.
604 2013-09-05 22:51:32 <phantomcircuit> oh it's supplying the private key into the hash function also
605 2013-09-05 22:51:34 <phantomcircuit> that's uh
606 2013-09-05 22:51:36 <phantomcircuit> interesting
607 2013-09-05 22:51:39 <edcba> http://www.johannes-bauer.com/compsci/ecc/ "But I don't trust NIST/SECG. What alternatives do I have?"
608 2013-09-05 22:52:28 <gmaxwell> edcba: a problem with that thinking is that if they were even able to hide a back door then they have some powerful math that the public doesn't know about.
609 2013-09-05 22:52:37 <gmaxwell> edcba: once you're assuming that... what can you trust?
610 2013-09-05 22:53:06 <gmaxwell> If we were going to have another signing system I don't think having another set of parameters for ecc of the same size is really all that useful.
611 2013-09-05 22:54:06 <edcba> maybe that + another totally different cryptosystem then
612 2013-09-05 22:54:10 <gmaxwell> (0) still weak against QC (no anti-fud factor) (1) still potentially weak against super duper math (2) might be even weaker against the same super duper math that attacks the existing secp256k1 (3) a bunch of extra security and performance critical code.
613 2013-09-05 22:54:57 <gmaxwell> The reason I favor lamport is that it addresses all these concerns, the security risk of lamport is strictly less than a ECDSA system that uses the same hash function. .. and a fast implementation is trivial.
614 2013-09-05 22:55:33 <gmaxwell> Arguments for other alternatives: other ECC systems can offer additional properties which would be useful to us. Such as:
615 2013-09-05 22:55:54 <midnightmagic> That's Theodore T'So (the /dev/random guy) for those who might be curious, and this is the post where he's very happy about his past decisions re: /dev/random: https://plus.google.com/117091380454742934025/posts/SDcoemc9V3J Theodore is also describing reproducible builds using rPath in that post. rPath appears to be dead though. :( SAS bought it and the site is gone.
616 2013-09-05 22:56:51 <tgs3> midnightmagic: we are working on reproducible (for new most secure linux distribution + computer with preinstalled tor bitcoin etc) in #mempo (just started)
617 2013-09-05 22:57:06 <gmaxwell> Scalable multisignature: Want to have 501 of 1000 people sign something? There are cryptosystems that can do this. Lamport can scalable support 2 of 2 or 2 of 3 with some security reduction.. but not thousands.
618 2013-09-05 22:57:15 <tgs3> for debian faketime + using same build path length helps
619 2013-09-05 22:58:02 <gmaxwell> Ring signatures: Signed by one of {x,y,z}, but no one can tell who ... can be used for privacy improving constructions.. no way to do this with plain lamport.
620 2013-09-05 22:58:46 <gmaxwell> Blinded signatures: Signed by X but X can't later tell which signature of his is which. Can be used for privacy improving constructions. and again no way to do this with plain lamport.
621 2013-09-05 23:00:46 <theymos> I feel like fractional verification wouldn't be much better than relying on UTXO trees (which is pretty good, but not as good as a real full node). You still kind of have to trust miners for history that you didn't witness, even if subverting the signatures is very difficult.
622 2013-09-05 23:02:17 <gmaxwell> theymos: All our public signature systems only have computational hardness: at best 'subverting the signatures is very difficult'... so there is perhaps some room to ask how secure is our target.
623 2013-09-05 23:02:32 <gmaxwell> theymos: though I agree with you.. though there are questions about degree.
624 2013-09-05 23:03:28 <gmaxwell> theymos: I'm more than a little frustrated by the density of people in our community who don't think carefully about this stuff .. who think that we already depend on miners for verification, and even that doing so would be viable at all. Makes it kind of hard to have a sophicated discussion about possible tradeoffs.
625 2013-09-05 23:03:57 <theymos> I actually think that it's secure enough for pretty much everyone to use UTXO trees, perhaps with the "proof of rule-breaking" that you've mentioned before. So I'm not so worried about scriptsig size. It does suck that we wouldn't be able to do those cool crypto things with lamport signatures.
626 2013-09-05 23:04:38 <gmaxwell> well, as far as we know we can't do them with our current signatures eitherâ so no loss except perhaps the loss of a potential gain.
627 2013-09-05 23:05:01 <gmaxwell> Esp the scalable multisigning would be pretty useful. :(
628 2013-09-05 23:05:03 <gavinandresen> Good morning everybody! Good morning NSA eavesdroppers!
629 2013-09-05 23:05:25 <theymos> Yeah, Bitcoin is especially beautiful because it's *not* a majority rule of miners, but a consensus of individuals. It's a shame that so many people miss this.
630 2013-09-05 23:05:51 <gmaxwell> "Good morning sun" "Good morning cat" "Good morning inhuman surveillance apparatus"
631 2013-09-05 23:05:52 <phantomcircuit> gavinandresen, lol
632 2013-09-05 23:09:24 <phantomcircuit> lol poor david johnston
633 2013-09-05 23:09:39 <gmaxwell> theymos: regardless, I'd still prefer to structure the signatures to enable that kind of fractional storage, even if we never were to go that route.
634 2013-09-05 23:09:39 <phantomcircuit> if there really isn't a backdoor he must be super pissed
635 2013-09-05 23:11:55 <phantomcircuit> huh
636 2013-09-05 23:12:44 <phantomcircuit> gmaxwell, i wonder if a broadcast style network in which various peers where selected entirely at random (ie they're not running the software at all) could be used to hide the true destination of normal udp traffic
637 2013-09-05 23:13:03 <phantomcircuit> (combined of course with a mixing network)
638 2013-09-05 23:13:08 <gmaxwell> phantomcircuit: it could, but it would be very inefficient.
639 2013-09-05 23:13:14 <gmaxwell> and would tend to piss people off. :P
640 2013-09-05 23:13:21 <phantomcircuit> gmaxwell, it would also be very hard to filter
641 2013-09-05 23:13:28 <phantomcircuit> s/filter/analyze/
642 2013-09-05 23:13:40 <phantomcircuit> the sheer magnitude of possible conversations would be overwhelming
643 2013-09-05 23:14:07 <edcba> interesting
644 2013-09-05 23:14:29 <edcba> not overwhelming for a computer
645 2013-09-05 23:14:55 <edcba> but sending packets at random is still fun
646 2013-09-05 23:15:01 <phantomcircuit> edcba, actually i meant that the algorithms to try and determine who you are really trying to talk to likely would be overwhelmed by the number of possible conversations
647 2013-09-05 23:15:36 <edcba> only random packets sender will exchange
648 2013-09-05 23:15:51 <edcba> now you need another point to distribute
649 2013-09-05 23:15:53 <edcba> like irc
650 2013-09-05 23:15:55 <phantomcircuit> edcba, you could include a large swath of valid mixers
651 2013-09-05 23:16:06 <phantomcircuit> they'll get the message and in all likelyhood simply drop it
652 2013-09-05 23:16:08 <edcba> or tor
653 2013-09-05 23:16:25 <edcba> but the real problem is timing
654 2013-09-05 23:16:34 <phantomcircuit> but now you have a model where instead of needing timing data for 3 jurisdictions you need it for more or less all of them
655 2013-09-05 23:19:51 <theymos> GnuNet works kind of like that, though it doesn't talk to random IPs. Its security is built all on plausible deniability, with a lot of padding, dummy messages, etc. This is a nicely different strategy from Tor/I2P/Freenet. The software isn't great, though.
656 2013-09-05 23:20:35 <phantomcircuit> theymos, "isn't great"
657 2013-09-05 23:20:36 <phantomcircuit> :)
658 2013-09-05 23:21:37 <gmaxwell> bitcoin transaction transmission makes a great pratical argument for building a high latency private message relay network... except for the fact that there are so many privacy problems before you even get to that, using that to hide your transaction origin is currently somewhat pointless.
659 2013-09-05 23:23:04 <edcba> yeah identity hiding is not really the main selling point of bitcoin
660 2013-09-05 23:23:31 <edcba> or i mean it should not lol
661 2013-09-05 23:23:32 <upb> then what is, jews?
662 2013-09-05 23:23:44 <edcba> haha
663 2013-09-05 23:24:02 <gmaxwell> but bitcoin is unusual in that it produces very small messages which are pretty valuable.