1 2011-11-02 00:06:45 <CIA-101> bitcoinjs/node-bitcoin-p2p: Stefan Thomas master * rb25e8c3 / (lib/scriptinterpreter.js test/script.js): Switched to asynchronous signature verification. Fixes #29. - http://git.io/EZq1lQ
  2 2011-11-02 00:11:23 <BlueMatt> sipa: means gavin isnt on and people are busy with life...
  3 2011-11-02 00:11:42 <BlueMatt> also, nice to see you here...been a while
  4 2011-11-02 00:11:46 <sipa> yeah
  5 2011-11-02 00:11:55 <sipa> been busy as well :)
  6 2011-11-02 00:12:09 <BlueMatt> I would say we all have
  7 2011-11-02 00:14:23 <sipa> time to try a gitian build :)
  8 2011-11-02 00:15:36 <batouzo> sipa: what are you bussy with
  9 2011-11-02 00:55:51 <CIA-101> libbitcoin: genjix * r6ede50ea1298 / (5 files in 4 dirs): Subscriber/relay loop should be immediate.
 10 2011-11-02 01:34:33 <Diablo-D3> man
 11 2011-11-02 01:34:34 <Diablo-D3> I forget
 12 2011-11-02 01:34:53 <Diablo-D3> nanotube: did you have something on gribble to list block numbers for the chains?
 13 2011-11-02 01:35:55 <CIA-101> libbitcoin: genjix * re7f6d7621c0e / (8 files in 4 dirs): Tightened the storage requirements in order to have a stronger API: block processing no longer lazily evaluated. must try to execute fully on calling.
 14 2011-11-02 01:38:13 <Diablo-D3> ;;ticker
 15 2011-11-02 01:38:14 <gribble> Best bid: 3.21072, Best ask: 3.21752, Bid-ask spread: 0.0068, Last trade: 3.21742, 24 hour volume: 36498, 24 hour low: 3.07001, 24 hour high: 3.33
 16 2011-11-02 01:38:47 <Diablo-D3> ;;calc (1.52+.67) * 3.21
 17 2011-11-02 01:38:48 <gribble> Google's calculator didn't come up with anything.
 18 2011-11-02 01:38:57 <Diablo-D3> ;;calc ((1.52+.67) * 3.21)
 19 2011-11-02 01:38:58 <gribble> Google's calculator didn't come up with anything.
 20 2011-11-02 01:39:03 <Diablo-D3> you know what, fuck you
 21 2011-11-02 01:39:17 <Diablo-D3> 7.0299
 22 2011-11-02 01:39:19 <Diablo-D3> /exec -o perl -le "print ((1.52+.67) * 3.21)"
 23 2011-11-02 02:21:28 <fabulousburrito> heh
 24 2011-11-02 04:23:13 <CIA-101> bitcoinjs/node-bitcoin-p2p: Stefan Thomas master * r24d8fa4 / (3 files in 2 dirs): Removed database access from Transaction.verify(). - http://git.io/2OoGqw
 25 2011-11-02 05:36:29 <fabulousburrito> ahem, peniskitten?
 26 2011-11-02 08:09:19 <nanotube> ;;later tell diablo-d3 well there's the block count for the bitcoin chain... bc,blocks
 27 2011-11-02 08:09:20 <gribble> The operation succeeded.
 28 2011-11-02 10:50:32 <gribble> (bc,stats <an alias, 0 arguments>) -- Alias for "echo Current Blocks: [bc,blocks] | Current Difficulty: [bc,diff] | Next Difficulty At Block: [bc,nexttarget] | Next Difficulty In: [math calc [bc,nexttarget] - [bc,blocks]] blocks | Next Difficulty In About: [bc,timetonext] | Next Difficulty Estimate: [bc,estimate] | Estimated Percent Change: [math calc 100*([bc,estimate]/[bc,diff] - (1 more message)
 29 2011-11-02 10:50:32 <UukGoblin> ;;help bc,stats
 30 2011-11-02 10:50:53 <gribble> (bc,estimate <an alias, 0 arguments>) -- Alias for "web fetch http://blockexplorer.com/q/estimate".
 31 2011-11-02 10:50:53 <UukGoblin> ;;help bc,estimate
 32 2011-11-02 11:02:28 <erus`> GTA5 trailer in 4 hours :D
 33 2011-11-02 12:01:20 <nameless> |I love it when I get notices about IRCing as root
 34 2011-11-02 12:01:58 <nameless> |That script better not have tried to kick me. If it did I'm angry
 35 2011-11-02 13:51:53 <phungus> heh, who irc's as root?
 36 2011-11-02 13:51:59 <phungus> besides MrTiggr?
 37 2011-11-02 13:52:00 <phungus> :-)
 38 2011-11-02 13:52:34 <phungus> Windows users used to IRC as administrator
 39 2011-11-02 13:52:42 <phungus> for the most part, before the UAC stuff
 40 2011-11-02 13:53:30 <lianj> maybe trolls ones too
 41 2011-11-02 13:54:58 <helo> maybe someone who has an "DMZ" vm they irc from?
 42 2011-11-02 14:03:03 <luke-jr> BlueMatt: ping
 43 2011-11-02 14:03:16 <BlueMatt> luke-jr: pong
 44 2011-11-02 14:03:24 <luke-jr> BlueMatt: 1. why did you add -Wno-strict-aliasing to bitcoin-qt.pro, but not makefile.unix ?
 45 2011-11-02 14:03:57 <BlueMatt> because it showed up in qt compile, but not in regular...I have no idea why
 46 2011-11-02 14:04:07 <luke-jr> O.o
 47 2011-11-02 14:04:32 <luke-jr> same for BOOST_THREAD_USE_LIB ?
 48 2011-11-02 14:04:54 <BlueMatt> iirc yes, though I dont remember
 49 2011-11-02 14:05:35 <BlueMatt> you can go do a gitian build and see if it shows up...
 50 2011-11-02 14:05:59 <luke-jr> no, gitian requires Ruby
 51 2011-11-02 14:06:10 <BlueMatt> ...and?
 52 2011-11-02 14:06:16 <luke-jr> and I won't touch Ruby
 53 2011-11-02 14:06:21 <BlueMatt> ...
 54 2011-11-02 14:06:27 <luke-jr> anyhow, best to put details like this in the commit msgs ;)
 55 2011-11-02 14:06:39 <kinlo> what's up with all those people swearing not to use a certain technology
 56 2011-11-02 14:06:48 <BlueMatt> kinlo: its mostly just luke...
 57 2011-11-02 14:07:19 <kinlo> BlueMatt: well, I must admit I have the same reaction to .net but still, that's easier to justify :)
 58 2011-11-02 14:07:30 <BlueMatt> well yea, no one likes .net
 59 2011-11-02 14:07:41 <luke-jr> kinlo: Ruby doesn't provide anything and has a high cost.
 60 2011-11-02 14:07:52 <BlueMatt> luke-jr: so use a vm
 61 2011-11-02 14:08:04 <luke-jr> BlueMatt: a VM has an even higher cost
 62 2011-11-02 14:08:15 <luke-jr> plus, I don't think my current kernel can do a VM inside a VM
 63 2011-11-02 14:08:20 <BlueMatt> oh, I thought you were complaining about installing new crap...
 64 2011-11-02 14:08:26 <BlueMatt> yea, you need 3.1 iirc
 65 2011-11-02 14:08:33 <BlueMatt> (and odd kvm options)
 66 2011-11-02 14:09:04 <luke-jr> well, 3.1 adds it for AMD
 67 2011-11-02 14:09:07 <luke-jr> not sure on status on Intel
 68 2011-11-02 14:11:11 <BlueMatt_> well, I dont remember, I thought I saw a mention of intel as well, but maybe that tech isnt even an option on intel...
 69 2011-11-02 14:15:52 <CIA-34> bitcoin: cjdelisle 0.4.x * r38a976d5bbfb bitcoind-stable/src/makefile.unix: Added a workaround for an Ubuntu bug which causes -fstack-protector-all to be disregarded.
 70 2011-11-02 14:15:53 <CIA-34> bitcoin: Matt Corallo 0.4.x * red176ba584ed bitcoind-stable/src/headers.h: Only define __STDC_LIMIT_MACROS if not already defined.
 71 2011-11-02 14:15:55 <CIA-34> bitcoin: Matt Corallo 0.4.x * ref4280e08b21 bitcoind-stable/src/ (keystore.h wallet.cpp): Add returns to avoid annoying compile-time warnings.
 72 2011-11-02 14:49:08 <devrandom> BlueMatt: linux kernel 3.1 supports multi-level vms?
 73 2011-11-02 14:52:55 <BlueMatt> devrandom: yes
 74 2011-11-02 14:55:04 <BlueMatt> devrandom: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=823e396558e509b7c3225cd76806f3d6643ff5f8
 75 2011-11-02 14:57:27 <ThomasV> which part of the code does the verification of transactions?
 76 2011-11-02 14:58:24 <BlueMatt> devrandom: also http://www.usenix.org/events/osdi10/tech/full_papers/Ben-Yehuda.pdf
 77 2011-11-02 14:58:50 <graingert> I'm a bit nervous about the fact that bitcoin seems centralized on github
 78 2011-11-02 14:59:01 <BlueMatt> luke-jr: actually it looks like it only works for intel, not amd
 79 2011-11-02 14:59:19 <BlueMatt> graingert: its not
 80 2011-11-02 14:59:20 <BlueMatt> if github tries to change something everyone will see
 81 2011-11-02 14:59:35 <BlueMatt> exactly
 82 2011-11-02 14:59:35 <graingert> well it's on everyone else's git
 83 2011-11-02 15:01:00 <graingert> thinking about an attack
 84 2011-11-02 15:01:55 <graingert> in which you pull from the main repo and you get different code
 85 2011-11-02 15:02:19 <graingert> I guess you'd see the commit
 86 2011-11-02 15:02:39 <graingert> there would probably have to be an exploit in git for anything to happen
 87 2011-11-02 15:04:15 <luke-jr> git uses SHA-1 which IIRC is broken
 88 2011-11-02 15:04:24 <luke-jr> github is still a problem though :
 89 2011-11-02 15:04:43 <graingert> International Integrated Reporting Committee, IIRC
 90 2011-11-02 15:04:46 <BlueMatt> since when is sha1 broken?
 91 2011-11-02 15:04:59 <BlueMatt> its weakened, but not actually realistically broken iirc
 92 2011-11-02 15:05:08 <graingert> it's broken
 93 2011-11-02 15:05:13 <graingert> but not compromised
 94 2011-11-02 15:05:22 <luke-jr> "weakened" is broken
 95 2011-11-02 15:05:25 <graingert> broken == weakened
 96 2011-11-02 15:05:35 <BlueMatt> still not "realistically broken"
 97 2011-11-02 15:06:02 <graingert> OMG
 98 2011-11-02 15:06:13 <graingert> broken != compromised
 99 2011-11-02 15:06:28 <graingert> broken == "realistically broken"
100 2011-11-02 15:06:44 <BlueMatt> whatever, we all know what is being discussed the terminology is whatever  you want
101 2011-11-02 15:07:17 <graingert> "It pretty much puts a bullet into SHA-1 as a hash function for digital signatures"
102 2011-11-02 15:07:27 <graingert> it depends where the bullet was places
103 2011-11-02 15:07:30 <graingert> placed*
104 2011-11-02 15:07:38 <graingert> was it in the arm or the head
105 2011-11-02 15:07:45 <BlueMatt> it means dont depend on it long-term, but for now breaking it is infeasible
106 2011-11-02 15:07:59 <BlueMatt> breaking a specific case*
107 2011-11-02 15:08:04 <graingert> hey can find collisions in SHA-1 in 269 calculations,
108 2011-11-02 15:08:10 <graingert> 2^69
109 2011-11-02 15:08:18 <BlueMatt> very different numbers...
110 2011-11-02 15:08:26 <graingert> lol
111 2011-11-02 15:08:29 <graingert> http://www.schneier.com/blog/archives/2005/02/cryptanalysis_o.html
112 2011-11-02 15:12:04 <BlueMatt> why is kernel 3.1 still not on kernel.org?
113 2011-11-02 15:12:30 <BlueMatt> linus tagged it 9 days ago
114 2011-11-02 15:13:54 <luke-jr> dunno, I'm upgrading at my next reboot
115 2011-11-02 15:19:08 <kinlo> I think kernel.org still hasn't recovered from their hack
116 2011-11-02 15:19:41 <kinlo> I don't really get it, I think the owner/team behind kernel.org is kinda fed-up with maintaining it and doesn't seem to care that much anymore
117 2011-11-02 15:19:57 <kinlo> at least that's the impression that they give
118 2011-11-02 15:20:22 <nameless> |phungus: I do apparently
119 2011-11-02 15:21:58 <ThomasV> ok, how do I output error messages that are returned with error() ?
120 2011-11-02 15:22:13 <da2ce7> TheRubberChick-1, how did you experment go?
121 2011-11-02 15:22:32 <TheRubberChick-1> 80% returned
122 2011-11-02 15:23:07 <TheRubberChicken> pretty impressed with that
123 2011-11-02 15:44:36 <phungus> oh you do?
124 2011-11-02 15:44:53 <phungus> :-)
125 2011-11-02 16:34:19 <Diablo-D3> nanotube: add ;;blocks that lists both bc and nmc and possibly others
126 2011-11-02 17:15:59 <CIA-34> libbitcoin: genjix * r729873c26165 /src/network/ (channel.cpp channel.hpp): Templated function for channel sends since channels are internal.
127 2011-11-02 17:16:00 <CIA-34> libbitcoin: genjix * r8d174bc8616f / (include/bitcoin/dialect.hpp src/dialect.cpp): No need to pass header when deserialising streams because checking is done inside channel
128 2011-11-02 17:16:01 <CIA-34> libbitcoin: genjix * r20f531a18dc5 / (5 files in 5 dirs): tx serialisation + unit test.
129 2011-11-02 17:45:48 <Diablo-D3> lol
130 2011-11-02 17:45:54 <Diablo-D3> bernake is lying right as I speak
131 2011-11-02 17:46:04 <cocktopus> bernaked?
132 2011-11-02 17:46:05 <Diablo-D3> hes claiming that inflation is stable
133 2011-11-02 17:46:17 <cocktopus> lol
134 2011-11-02 17:46:24 <Diablo-D3> of course it is!
135 2011-11-02 17:46:30 <Diablo-D3> AT AN UNGODLY HIGH RATE
136 2011-11-02 17:46:37 <cocktopus> 1000000000000000000000000000000000000%
137 2011-11-02 17:46:42 <Diablo-D3> no, 2%
138 2011-11-02 17:46:46 <Diablo-D3> which is over 9000
139 2011-11-02 17:47:20 <cocktopus> i am getting poorer by the day then
140 2011-11-02 17:47:22 <cocktopus> fml
141 2011-11-02 17:47:38 <Diablo-D3> inflation should reflect a balance of population growth, gdp growth, and asset value growth
142 2011-11-02 17:48:00 <Diablo-D3> nominally post-great depression, 2% my fat dick.
143 2011-11-02 17:48:04 <cocktopus> i have more e-penises than you copumpkin
144 2011-11-02 17:48:23 <cocktopus> 8 tbh
145 2011-11-02 17:48:31 <Diablo-D3> I had to make my e-penis four dimensional so I could fit it in my pants
146 2011-11-02 17:48:51 <cocktopus> i didn't say they were particularly large
147 2011-11-02 17:48:56 <cocktopus> just numerous
148 2011-11-02 18:12:11 <amiller> $25 if someone writes a game of 'battleship' using the bitcoin scripting language
149 2011-11-02 18:12:59 <amiller> or tictactoe whichever is easier i suppose https://en.bitcoin.it/wiki/Script
150 2011-11-02 18:13:02 <luke-jr> &
151 2011-11-02 18:13:13 <luke-jr> amiller: require they support merged mining
152 2011-11-02 18:13:23 <luke-jr> also, $25 ain't much
153 2011-11-02 18:13:24 <amiller> blah blah
154 2011-11-02 18:13:41 <gmaxwell> bemasc: /window 5
155 2011-11-02 18:13:44 <gmaxwell> oops
156 2011-11-02 18:13:44 <MartianW> amiller, it doesn't seem too hard.
157 2011-11-02 18:13:47 <amiller> like you said, it's not merged mining
158 2011-11-02 18:13:51 <luke-jr> it should be
159 2011-11-02 18:13:53 <MartianW> Isn't it just forth?
160 2011-11-02 18:13:55 <luke-jr> don't clutter the main chain
161 2011-11-02 18:14:09 <BlueMatt> do it on testnet
162 2011-11-02 18:16:33 <amiller> i'm really not sure how you'd go about it
163 2011-11-02 18:16:38 <amiller> since it would take multiple rounds
164 2011-11-02 18:17:00 <amiller> but it's clear that its possible
165 2011-11-02 18:17:41 <luke-jr> oh wait
166 2011-11-02 18:17:51 <luke-jr> you mean a Script where you need to win the game to redeem the coins?
167 2011-11-02 18:17:55 <luke-jr> hmmm :o
168 2011-11-02 18:18:09 <amiller> yeah i think that's the natural thing to do
169 2011-11-02 18:18:23 <luke-jr> I thought you meant play vs someone over Bitcoin
170 2011-11-02 18:18:44 <luke-jr> so long as the computer goes first, tic-tac-toe would be unredeemable ;)
171 2011-11-02 18:19:16 <amiller> hah no just assume there are two different players
172 2011-11-02 18:19:20 <amiller> their public keys are defined in the first message
173 2011-11-02 18:19:45 <luke-jr> &
174 2011-11-02 18:19:53 <luke-jr> so you DO mean playing against someone :P
175 2011-11-02 18:20:04 <amiller> yes
176 2011-11-02 18:20:06 <amiller> whoever wins gets the bitcoins
177 2011-11-02 18:20:37 <BlueMatt> you cant reference previous txes in scripts...
178 2011-11-02 18:20:57 <amiller> but you can bring state along with you to the next tx can't you
179 2011-11-02 18:21:45 <BlueMatt> no
180 2011-11-02 18:22:00 <luke-jr> you could have it so you need to play the game, and post the results
181 2011-11-02 18:22:10 <luke-jr> it would be huge for battleship
182 2011-11-02 18:22:17 <luke-jr> you'd need a hash for every spot on the board
183 2011-11-02 18:22:31 <amiller> no you just wouldn't store it like that
184 2011-11-02 18:22:37 <amiller> it would be compressed
185 2011-11-02 18:22:37 <luke-jr> you'd need to
186 2011-11-02 18:22:45 <luke-jr> you can't compress in scripts
187 2011-11-02 18:23:25 <gmaxwell> scripts have no recursion or looping.. so the complexity of the program is proportional to the script size.
188 2011-11-02 18:23:45 <gmaxwell> e.g. you can have a script serialize out every possible decision path, but the size of the script grows exponentially.
189 2011-11-02 18:24:17 <BlueMatt> gmaxwell: he said one player plays another, not you play the computer (which operates in a script)
190 2011-11-02 18:24:33 <luke-jr> basically, the redeeming script would need to provide: 1) for each player's board, the cleartext "how it looks" and a nonce to prevent bruteforcing it; 2) signed "moves" by each player
191 2011-11-02 18:24:49 <amiller> luke-jr, right
192 2011-11-02 18:25:02 <luke-jr> the scriptPk would need to verify the boards are correct, and that the moves are legal and which key won
193 2011-11-02 18:25:45 <luke-jr> and when all is said and done, this is missing a way to "force" your opponent to reveal his board when the game is over
194 2011-11-02 18:26:02 <luke-jr> maybe only the winner's board needs to be revealed
195 2011-11-02 18:26:06 <luke-jr> to ensure *he* didn't cheat
196 2011-11-02 18:26:11 <amiller> right
197 2011-11-02 18:26:19 <amiller> luke-jr, we are definitely missing a primtiive to support a secret board
198 2011-11-02 18:26:36 <BlueMatt> you guys do realize there is a limit on script size?
199 2011-11-02 18:26:41 <amiller> you can do it with noninteractive zero knowledge proofs
200 2011-11-02 18:26:42 <luke-jr> put hash(board data + nonce) for each player in the scriptPk
201 2011-11-02 18:26:49 <luke-jr> BlueMatt: nooooooooooooooooooooooooooooo
202 2011-11-02 18:27:09 <amiller> BlueMatt, nonsense!
203 2011-11-02 18:27:41 <amiller> BlueMatt, i don't necessarily care about fitting this into 'the' bitcoin
204 2011-11-02 18:28:12 <luke-jr> what'd really be cool, would be a way to calculate an encrypted(pubkey) where the person creating it doesn't know pubkey, and doesn't have the encryption privkey
205 2011-11-02 18:28:31 <luke-jr> err
206 2011-11-02 18:28:35 <luke-jr> s/pubkey/privkey/
207 2011-11-02 18:29:01 <amiller> luke-jr, suppose you could compute encrypted(a+b), given encrypt(a) and encrypted(b)
208 2011-11-02 18:29:12 <amiller> encrtyped(a)*
209 2011-11-02 18:30:44 <helo> wasn't there some IBM project that allowed operations on encrypted data without decrypting it?
210 2011-11-02 18:30:56 <amiller> homomorphic encryption
211 2011-11-02 18:31:02 <amiller> and non interactive zero knowledge proofs are related
212 2011-11-02 18:31:55 <amiller> this guy's thesis in 2009 was kind of the breaking point for this area  http://crypto.stanford.edu/craig/craig-thesis.pdf
213 2011-11-02 18:32:17 <gmaxwell> amiller: go build an actual system that allows you to do some kind of useful hash commitment znp so we can demonstrate it with bitcoin. It's possible, but AFAIK no actual implementations exist.
214 2011-11-02 18:32:22 <gmaxwell> :)
215 2011-11-02 18:32:34 <amiller> this paper on it is my favorite
216 2011-11-02 18:32:35 <amiller> http://www.daimi.au.dk/~jg/ShortNIZK.pdf
217 2011-11-02 18:32:57 <gmaxwell> A system that allows you to sell inverses to md5 hashes with bitcoin would be a really awesome demonstration.
218 2011-11-02 18:32:58 <amiller> this library 'pairing based cryptography' has some of the primitives http://crypto.stanford.edu/pbc/
219 2011-11-02 18:33:33 <amiller> the current state of the art for pairing based crypto is very slow, too :(
220 2011-11-02 18:34:34 <amiller> gmaxwell, i think i could do a commitment to an el gamal key...
221 2011-11-02 18:34:59 <amiller> anyway today i'm more interested in the somewhat simpler problem
222 2011-11-02 18:35:08 <amiller> leaving 'secrecy' alone for now, so tic tac toe rather than battleship
223 2011-11-02 18:35:59 <gmaxwell> amiller: its all super easy if you just commit to the code of an agent.
224 2011-11-02 18:36:11 <gmaxwell> well for some definition of super and easy.
225 2011-11-02 18:36:51 <amiller> well that's kind of the trick of the 2009 thesis
226 2011-11-02 18:36:59 <amiller> you can do that, but you get exponential commitment size with the depth of the agent's code
227 2011-11-02 18:37:07 <amiller> but you can break it into small chunks
228 2011-11-02 18:37:13 <amiller> and effectively 'reencrypt' it each step
229 2011-11-02 18:37:24 <amiller> bootstrapped homomorphic encryption
230 2011-11-02 18:37:42 <amiller> no i don't know exactly how to implement that :p
231 2011-11-02 18:38:08 <luke-jr> [15:32:57] <gmaxwell> A system that allows you to sell inverses to md5 hashes with bitcoin would be a really awesome demonstration. <-- or any data
232 2011-11-02 18:38:33 <luke-jr> in fact, I suspect such a function would obsolete bitcoin
233 2011-11-02 18:39:10 <gmaxwell> luke-jr: well, in _THEORY_ any data you can validate with a program you can make a trade conditional on.. but in practice it's super duper hard because you have to convert the validator program PLUS a block cipher into a zero knoweldge proof.
234 2011-11-02 18:39:28 <gmaxwell> And bitcoin already has the one thing it needs to play its part in this.
235 2011-11-02 18:39:43 <luke-jr> gmaxwell: you'd also need to verify it isn't a double-spend ;)
236 2011-11-02 18:39:45 <gmaxwell> (the ability to make txn which are hash+public key locked)
237 2011-11-02 18:40:46 <amiller> i think this would be useful for stuff outside bitcoin
238 2011-11-02 18:40:51 <amiller> it's not really part of the 'cash' problem
239 2011-11-02 18:40:54 <CIA-34> libbitcoin: genjix * r00e2e97aff74 /examples/subvertx/mktx.cpp: mktx - tool for making a transaction from one output to another.
240 2011-11-02 18:41:08 <amiller> but it is similar to bitcoin in that you're playing a game in secret, but it's verified by the public
241 2011-11-02 18:41:29 <gmaxwell> luke-jr: the way it works is out-of-band you and I do a zero knoweldge proof where I prove to you that I know: A solution to your question, which is encrypted with a key giving X, and the key is hashed giving Y. And then you make a txn that makes me publish something that hashes to Y to redeem.
242 2011-11-02 18:42:30 <gmaxwell> And it's been proven that you can convert any program into such a proof. But actually doing so for any program anyone would care to use to validate some data is nontrivial.
243 2011-11-02 18:43:26 <luke-jr> amiller: no, if there was a solution to this, bitcoin wouldn't be needed
244 2011-11-02 18:43:37 <amiller> gmaxwell, i'd say it's worth keeping in mind and checking up every so often
245 2011-11-02 18:43:39 <luke-jr> amiller: you could just maintain a history locally for your coins and send that to anyone
246 2011-11-02 18:44:42 <amiller> BlueMatt said there was no way for one tx to pass its state along to the next tx
247 2011-11-02 18:45:31 <amiller> i can't tell if that's true or not
248 2011-11-02 18:57:13 <amiller> some of the speculative examples in this wiki page use an 'IF' statement of some kind https://en.bitcoin.it/wiki/Contracts
249 2011-11-02 19:00:36 <Acciaio> Hi all, isn't usefull implement a messaging system in bitcoin client?
250 2011-11-02 19:01:43 <gmaxwell> Acciaio: There are many messaging systems.
251 2011-11-02 19:02:00 <gmaxwell> You don't need bitcoin for messaging.
252 2011-11-02 19:02:16 <gmaxwell> "Every program attempts to expand until it can read mail"
253 2011-11-02 19:05:35 <Acciaio> but I hope sometime is nice to send a short message with your bitcoin transaction
254 2011-11-02 19:08:05 <Eliel> gmaxwell: bitcoin has a somewhat unique position in that it's handling encryption keys that need to be well secured. Bitcoin account keys have therefore relatively good chance to becoming pretty standard way of identifying people. encrypted messaging included.
255 2011-11-02 19:11:02 <gmaxwell> Eliel: er, except bitcoin has really bad privacy properties if you don't use your addresses as ephemerially as possible.
256 2011-11-02 19:11:13 <gmaxwell> Though we do have signmessage now&
257 2011-11-02 19:11:42 <Eliel> gmaxwell: you only need one address for messaging :)
258 2011-11-02 19:12:15 <Eliel> and it doesn't have to be used to receive bitcoins.
259 2011-11-02 19:13:01 <amiller> gmaxwell, what's the best way to keep up with which features like that are implemented
260 2011-11-02 19:13:05 <Eliel> although, if you use it as an identity, it can be very useful if you wish to make entirely public transactions.
261 2011-11-02 19:13:08 <gmaxwell> amiller: git pull
262 2011-11-02 19:13:46 <gmaxwell> the bitcoin codebase is small, I don't have any difficulty reading almost all the commits. (well, the qt stuff was disruptive but otherwise it's pretty low volume)
263 2011-11-02 19:27:55 <luke-jr> [16:05:35] <Acciaio> but I hope sometime is nice to send a short message with your bitcoin transaction <-- use email
264 2011-11-02 19:28:52 <luke-jr> ok, I'm gonna reboot to upgrade Linux& bbiab
265 2011-11-02 19:37:33 <amiller> bitinventory.com is great
266 2011-11-02 19:37:53 <amiller> the only way it would be better is if the java applet had Lucre in it so it could do blinding, like blindbitcoin used to do with javascrit
267 2011-11-02 19:40:46 <Eliel> bitinventory.com doesn't exist.
268 2011-11-02 19:40:58 <Eliel> or a least doesn't resolve for me
269 2011-11-02 19:55:24 <Eliel> ah, it's bitventory.com
270 2011-11-02 20:03:47 <luke-jr> anyone know slush's email?
271 2011-11-02 20:33:14 <ByteCoin> ping gavinandresen
272 2011-11-02 20:42:31 <gjs278> ping: unknown host gavinandresen
273 2011-11-02 20:50:44 <CIA-34> libbitcoin: genjix * rc59dec123893 /examples/subvertx/priv.cpp: Add address command to priv help.
274 2011-11-02 20:50:46 <CIA-34> libbitcoin: genjix * rb011cafa0e4e /examples/subvertx/mktx.cpp: Use public key from private key to find previous output address.
275 2011-11-02 20:55:18 <ByteCoin> What's the best way to comment on or discuss a BIP?
276 2011-11-02 20:55:49 <luke-jr> the Talk page?
277 2011-11-02 20:56:04 <ByteCoin> Link plz?
278 2011-11-02 20:57:53 <ByteCoin> I'm looking at https://en.bitcoin.it/wiki/BIP_0012
279 2011-11-02 20:57:59 <ByteCoin> I don't see a "Talk" page
280 2011-11-02 21:11:00 <CIA-34> poolserverj: shadders * f763093afec2 r182 / (10 files in 6 dirs):
281 2011-11-02 21:11:01 <CIA-34> poolserverj: Update to generate merged mining auxPoW internally. This completely removes the dependency on bitcoind-mm version and allows us to use stock bitcoind which is nifty since it contains getmemorypool and we need that.
282 2011-11-02 21:21:18 <luke-jr> ByteCoin: you need to login ofc
283 2011-11-02 21:38:26 <coblee> 2|hey guys. i'm thinking of ideas to make litecoin more secure against 51% attack. and i'd like to see what people here think about it
284 2011-11-02 21:39:36 <coblee> 2|My idea is using auto block lockin to fight against 51% attacks. Basically each client will automatically lock in a block that already has 120 confirmations. If some node tries to send them a reorg that tries to reorg more than 120 blocks, it will be rejected.
285 2011-11-02 21:39:47 <luke-jr> &
286 2011-11-02 21:39:53 <luke-jr> that doesn't even *resist* 51%
287 2011-11-02 21:39:58 <coblee> 2|getinfo can show which block your client has locked and i can add an RPC call that you can make to unlock yourself in case something totally screwed up
288 2011-11-02 21:40:15 <gmaxwell> coblee|2: that just means that any nontrivial network partition converts you from one currency into two.
289 2011-11-02 21:40:42 <luke-jr> well, I guess it does resist a long 51%
290 2011-11-02 21:40:46 <gmaxwell> coblee|2: also leaves offline nodes up for fun attacks.
291 2011-11-02 21:40:47 <coblee> 2|you can 51% for a few blocks. but not more than 120. so any coins mined and with 120 confirmed is good
292 2011-11-02 21:41:02 <luke-jr> gmaxwell: it's a bigger problem without partitioning
293 2011-11-02 21:41:09 <coblee> 2|gmaxwell: has bitcoin experienced a nontrivial network partition?
294 2011-11-02 21:41:15 <luke-jr> any reorg over 100 blocks *should* lock the client probably
295 2011-11-02 21:41:19 <gmaxwell> coblee|2: Yes. In the past.
296 2011-11-02 21:41:37 <gmaxwell> luke-jr: but which side should lock and which side should continue?
297 2011-11-02 21:41:44 <luke-jr> gmaxwell: both should lock.
298 2011-11-02 21:41:48 <luke-jr> err
299 2011-11-02 21:41:51 <luke-jr> the smaller side
300 2011-11-02 21:42:10 <coblee> 2|maybe we need a case where if something like this happens, the user has to make a decision
301 2011-11-02 21:42:12 <gmaxwell> Refusal to reorg != locking.
302 2011-11-02 21:42:21 <luke-jr> it should lock.
303 2011-11-02 21:42:34 <gmaxwell> and when different users pick different choices?
304 2011-11-02 21:42:35 <luke-jr> at least if you depend on the generation being reorganized
305 2011-11-02 21:42:42 <luke-jr> &
306 2011-11-02 21:42:44 <coblee> 2|gmaxwell: then you split the coin into 2
307 2011-11-02 21:42:50 <BlueMatt> note that esp for smaller, less well-established currencies, the partitioning issue may be worse...
308 2011-11-02 21:42:51 <gmaxwell> what _you_ depend on doesn't matter. What the _network_ depends on matters.
309 2011-11-02 21:43:05 <coblee> 2|but you let people (pools and exchanges) vote on which one to accept
310 2011-11-02 21:43:12 <luke-jr> if the reorg would change your wallet, you should lock up until a human has vetted it
311 2011-11-02 21:43:45 <coblee> 2|luke-jr: any small reorg will change your wallet. that's what orphans are right?
312 2011-11-02 21:43:47 <luke-jr> ie, if you were paid with a coinbase that is no longer valid
313 2011-11-02 21:44:03 <luke-jr> coblee|2: no, usually not
314 2011-11-02 21:44:17 <luke-jr> coblee|2: worst case, they usually just reset your transaction to 0 confirmations
315 2011-11-02 21:44:20 <coblee> 2|well, the orphaned block would not have been confirmed.
316 2011-11-02 21:45:07 <luke-jr> "removing generation under 100 confirmations" wouldn't be considered a change, IMO
317 2011-11-02 21:46:21 <coblee> 2|luke-jr: even if a reorg changed your wallet, locking up your client until you have vetted won't do you any good, right?
318 2011-11-02 21:46:39 <coblee> 2|if all the other clients accepted the reorg, you would have to accept also
319 2011-11-02 21:47:27 <luke-jr> coblee|2: it can
320 2011-11-02 21:47:48 <luke-jr> you would need to accept it eventually *if* the world didn't decide the reorg was bad for some reason
321 2011-11-02 21:47:59 <luke-jr> but even still, your applications would stop automatically doing stuff
322 2011-11-02 21:49:00 <luke-jr> for example, an ewallet provider might accept a deposit of 500 BTC, which is reversed in the reorg; if his wallet doesn't lock up, someone might be able to withdraw that 500 BTC he no longer has
323 2011-11-02 21:49:45 <coblee> 2|luke-jr: yup, and i know doublec has added code in his client to detect these reorgs and lock up the client
324 2011-11-02 21:50:00 <luke-jr> if the wallet locks up, that withdrawl will fail until a human has vetted (and presumably adjusted the ewallet db) the reversal
325 2011-11-02 21:51:12 <coblee> 2|yup, it makes sense
326 2011-11-02 21:52:09 <coblee> 2|what i'm proposing is a bit different. i'm just proposing auto block lockin so that it will reject reorgs larger than 120 blocks
327 2011-11-02 21:52:30 <luke-jr> I'm not sure that's better.
328 2011-11-02 21:52:47 <luke-jr> also, it should be 100 :p
329 2011-11-02 21:54:17 <coblee> 2|in the case of an real 51% attack past the 120 blocks, all good clients will reject it and the attacker will have forked his own chain. and when i see such an attack. i can hardcode the block hash into the code so that new users will not be on the attackers fork
330 2011-11-02 21:55:09 <coblee> 2|in the case of a nontrivial network partition. people that happen to get stuck on a bad fork, they will eventually realize it when most of the pools and exchanges are on a different fork. they can then run a command to undo the block lockin and accept the reorg
331 2011-11-02 21:55:15 <coblee> 2|luke-jr: why 100?
332 2011-11-02 21:56:47 <gmaxwell> coblee|2: It worries me that you keep thinking of this as erasing the attackers chain, it could easily erase the other chain. The nodes can't tell.
333 2011-11-02 21:58:32 <gmaxwell> coblee|2: I can easily set it up so that my chain will be the one that wins by choosing when overtaking happens(right before the 120 mark), thus forking off the other side.
334 2011-11-02 22:00:59 <genjix> ;;seen cdecker
335 2011-11-02 22:00:59 <gribble> cdecker was last seen in #bitcoin-dev 15 weeks, 1 day, 3 hours, 43 minutes, and 51 seconds ago: <cdecker> Near field communication
336 2011-11-02 22:01:19 <gmaxwell> I can also do fun stuff like isolate you on the network, feed you 120 of my blocks. .. and then you'll forever be on the chain I control
337 2011-11-02 22:01:54 <gmaxwell> And by proxying transactions, you'll think things are working normally.
338 2011-11-02 22:02:52 <coblee> 2|hmm, you have a good point
339 2011-11-02 22:03:03 <luke-jr> coblee|2: because 100 is how many confirmations are required to spend generation
340 2011-11-02 22:03:07 <doublec> coblee|2: it doesn't help the exchange double spend situation either
341 2011-11-02 22:03:19 <doublec> coblee|2: since they only need to rewrite past your deposit confirmation limit
342 2011-11-02 22:03:24 <coblee> 2|luke-jr: i thought it was 120. or is that just what the client shows
343 2011-11-02 22:03:46 <luke-jr> coblee|2: that's a client thing
344 2011-11-02 22:03:52 <coblee> 2|doublec: for exchange double spend. you need to make sure that each user cannot withdraw coins exchanged for coins that are not mature yet
345 2011-11-02 22:04:04 <coblee> 2|so for 120 ltc confirmation, that's about 5 hours
346 2011-11-02 22:04:04 <gmaxwell> also any value which will be high enough that it won't often have failures naturally due to network partitions.. will probably be too high for waiting for security.
347 2011-11-02 22:04:28 <gmaxwell> coblee|2: major 5 hour intenet partitions happen every couple of years.
348 2011-11-02 22:04:34 <coblee> 2|so users can't deposit ltc, exchange for btc, and withdraw btc right away. they would need to wait about 5 hours for the deposited ltc to have cleared
349 2011-11-02 22:04:46 <doublec> coblee|2: the i0coin exchange had regular reorgs greater than 100
350 2011-11-02 22:05:05 <coblee> 2|doublec: due to attacks, right?
351 2011-11-02 22:05:12 <gmaxwell> coblee|2: so if you lock in at 5 hours regular internet burps may well kill you.
352 2011-11-02 22:05:29 <doublec> coblee|2: not all attacks, even after I closed the exchange and had it in withdraw mode only it was happenning
353 2011-11-02 22:05:32 <genjix> gmaxwell: you can't do it to me.
354 2011-11-02 22:05:36 <doublec> coblee|2: maybe they were attacking someone else, I don't know
355 2011-11-02 22:06:22 <coblee> 2|doublec: i'm pretty sure those were attacks, maybe not intentional. i0coin has like 5 ghash total network speed. I can attack that myself for the heck of it
356 2011-11-02 22:07:43 <coblee> 2|gmaxwell: these 5 hour internet partitions would already hurt people on the wrong side of the partition, right?
357 2011-11-02 22:07:59 <coblee> 2|all the blocks they are working on would be undone
358 2011-11-02 22:08:24 <gmaxwell> coblee|2: yes. but you wouldn't end up with two independant currencies. (Also, this is why the time to spend new generations is so high in bitcoin)
359 2011-11-02 22:08:50 <coblee> 2|it's about 17 hours, right?
360 2011-11-02 22:08:55 <luke-jr> the least-damaging option is to lock the client until a human has reviewed the reversed transactions
361 2011-11-02 22:08:56 <gmaxwell> except for actual double spends, almost all the could and would be restored automatically.
362 2011-11-02 22:09:13 <gmaxwell> luke-jr: no, thats not an improvement. sadly. Your choice doesn't matter.
363 2011-11-02 22:09:26 <luke-jr> gmaxwell: I already gave an example where it makes a big difference
364 2011-11-02 22:09:36 <gmaxwell> You can say "no! I refuse this reorg" but too bad when the rest of the network takes it.
365 2011-11-02 22:09:46 <luke-jr> gmaxwell: invisibly reversing stuff can easily confuse services
366 2011-11-02 22:09:59 <doublec> also the reversal happens after they've stolen funds
367 2011-11-02 22:10:00 <gmaxwell> okay, sure independantly, thats interesting.
368 2011-11-02 22:10:05 <luke-jr> gmaxwell: I'll deposit 500 BTC I just mined, then withdraw it after it's reversed by the reorg
369 2011-11-02 22:10:34 <luke-jr> gmaxwell: locking the client makes that withdrawl error
370 2011-11-02 22:10:38 <gmaxwell> luke-jr: you withdraw it before the reversal.
371 2011-11-02 22:10:44 <luke-jr> no, I withdraw it after
372 2011-11-02 22:11:12 <gmaxwell> The point I'm making is that the protection doesnt' buy you much. The attacker would _normally_ withdraw first.
373 2011-11-02 22:11:15 <luke-jr> nothing stops me, if the client doesn't lock
374 2011-11-02 22:11:30 <luke-jr> oh, I see what you mean
375 2011-11-02 22:11:55 <luke-jr> hmm
376 2011-11-02 22:12:19 <doublec> yes, they release their fork after they've withdrawn
377 2011-11-02 22:12:22 <gmaxwell> In any case good klaxons are a good thing, and we should have more for big reorgs, network health, etc.
378 2011-11-02 22:12:36 <luke-jr> I guess what is needed, then, is a way to detect a large split
379 2011-11-02 22:12:41 <doublec> I'd like a tool that examines the forks and shows what transations are missing
380 2011-11-02 22:12:48 <luke-jr> like say, over 50% of the hashrate dropping off at once
381 2011-11-02 22:13:07 <doublec> even part of the json api so exchanges can detect reorgs and adjust balanaces, etc
382 2011-11-02 22:13:11 <gmaxwell> right. it should detect partions and you should  be able to tell your client "if things look weird, I'd arther you just keep telling me txn are not confirmed"
383 2011-11-02 22:13:17 <luke-jr> and refuse to confirm transactions that arrive after that point, until it picks back up
384 2011-11-02 22:17:20 <genjix> i dont think reversed transactions are a worry
385 2011-11-02 22:17:25 <genjix> it's all about risk/reward
386 2011-11-02 22:17:40 <genjix> for large amounts, require more confirms.
387 2011-11-02 22:18:03 <genjix> for the rare occasion a tx is reversed, then pony up the money to cover the lost funds (and it is really rare)
388 2011-11-02 22:18:19 <coblee> 2|gmaxwell: back to your possible attack vectors. if you isolate someone and feed them 120 blocks. it will take you a long time to generate 120 blocks. (5 hours if you can match the network hashrate) is that attack even worthwhile?
389 2011-11-02 22:18:24 <genjix> your actual loss should probably always be 0
390 2011-11-02 22:18:45 <genjix> risk * loss would be a very very very small number
391 2011-11-02 22:27:03 <doublec> genjix: coblee|2 is working on a lower hash rate chain where reversals are more of a possibility
392 2011-11-02 22:27:29 <doublec> genjix: for example, the i0coin exchange had successfull reversals pulled off
393 2011-11-02 22:27:56 <doublec> genjix: more confirms don't help if the attacker has >50%
394 2011-11-02 22:31:14 <genjix> doublec: i see.
395 2011-11-02 22:34:20 <genjix> btw there is tons of illegal stuff on the wiki Trade page
396 2011-11-02 22:37:17 <gmaxwell> coblee|2: here is a take on it. Assume no checkpoints for the moment.  I mine 120 blocks starting at block 1 at minimal difficulty. cheap cheap cheap. Then I search for new nodes and stuff them with my 120 blocks as fast as I can, peeling off clients into bizarro universe
397 2011-11-02 22:38:03 <gmaxwell> Now you say, "but I'll add checkpoints",  but it's a losing battle: you'd have to constantly add new checkpoints in order to prevent attackers with far _less_ than 50% power from picking off nodes without knoweldge of the current chain.
398 2011-11-02 22:38:29 <gmaxwell> And if you really have a way of trustworthily adding checkpoints in a fast manner, you don't need all this distributed hashchain crap.
399 2011-11-02 22:40:17 <gmaxwell> as far as the isolation attack goes it's worthwhile if attacking is at all worthwhile.
400 2011-11-02 22:41:13 <gmaxwell> Keep in mind that if you actually have a majority of the hashpower then you're usually better of playing nice than debasing the service. Though this doesn't apply when you're able to exhcange out quickly.
401 2011-11-02 22:42:07 <gmaxwell> also, reorg resistance only stands in the way of one of the two main majority attack problems.
402 2011-11-02 22:42:22 <gmaxwell> (the other one is the ability to control block content)
403 2011-11-02 22:44:47 <coblee> 2|gmaxwell: in your case, you are attacking a new chain right? but for an existing chain like litecoin, where mining 120 blocks will take about 3500 cpu hours, it's not that easy
404 2011-11-02 22:45:15 <coblee> 2|oh wait, you are talking about attacking new users before they've downloaded the blocks
405 2011-11-02 22:45:19 <gmaxwell> Yes.
406 2011-11-02 22:45:30 <gmaxwell> or as they download blocks.
407 2011-11-02 22:45:37 <gmaxwell> I don't even have to partition them.
408 2011-11-02 22:46:25 <coblee> 2|i see but they won't be able to pass the checkpoint at block 2016. how does that benefit you other than creating trouble?
409 2011-11-02 22:47:54 <coblee> 2|gmaxwell: can you explain the problem with the ability to control block content?
410 2011-11-02 22:48:17 <gmaxwell> hold on, lets stay on the prior case for a minute.
411 2011-11-02 22:49:11 <gmaxwell> coblee|2: I can always do that attack at the highest checkpoint in use. And unless you update that checkpoint quite often, it will be possible to do that attack with an increasingly small fraction of the network hash power.
412 2011-11-02 22:49:52 <gmaxwell> And once I've done the attack against a bunch of nodes, who are _you_ to say that my chain isn't legit?
413 2011-11-02 22:50:17 <gmaxwell> If people can trust you to do that, and do it frequently, then we don't need a pow hash chain to confirm txn, we can just ask you to do so.
414 2011-11-02 22:50:23 <gmaxwell> :)
415 2011-11-02 22:51:43 <coblee> 2|gmaxwell: but your nodes won't be able to go past 2016 because there's a checkpoint there
416 2011-11-02 22:52:32 <gmaxwell> coblee|2: I could _start_ at 2016. It would take more hashing but much less than 120 blocks worth at the current height.
417 2011-11-02 22:52:38 <coblee> 2|the highest checkpoint is currently 23420 and diff is already very big. so finding 120 blocks from that point on is expensive
418 2011-11-02 22:52:38 <doublec> coblee|2: the attack will start from 2016
419 2011-11-02 22:52:47 <doublec> or whatever the checkpoint is
420 2011-11-02 22:53:12 <gmaxwell> coblee|2: at the moment, yes, but it won't seem so big in 6 months.
421 2011-11-02 22:53:26 <coblee> 2|finding 120 blocks from blck 23420 will take 3500 8-core cpu hours
422 2011-11-02 22:53:43 <coblee> 2|but, i do see your point
423 2011-11-02 22:53:56 <coblee> 2|there's no bullet proof solution to this problem
424 2011-11-02 22:54:04 <gmaxwell> Basically the anti split login means everyone depends on new trustworthy checkpoints to come frequently enough to make this an unattractive attack..
425 2011-11-02 22:54:20 <coblee> 2|then it becomes centralized
426 2011-11-02 22:54:22 <doublec> isn't adding regular checkpoints essentially centralizing
427 2011-11-02 22:54:24 <doublec> right
428 2011-11-02 22:54:28 <doublec> I'm too slow :)
429 2011-11-02 22:54:37 <genjix> doublec: im not so sure
430 2011-11-02 22:54:46 <gmaxwell> and as soon as I pull off that attack _once_ then some people will prefer my chain and be really mad if you introduce a new checkpoint.
431 2011-11-02 22:55:04 <gmaxwell> genjix: they aren't in bitcoin, but only because they're added far in the past.
432 2011-11-02 22:55:10 <genjix> yep
433 2011-11-02 22:55:16 <gmaxwell> when there is no viable chain that they could be rejecting.
434 2011-11-02 22:55:25 <gmaxwell> I guess I should publish what I wrote on that subject.
435 2011-11-02 22:55:26 <doublec> genjix: I'm meaning checkpoints every 1000 blocks for example
436 2011-11-02 22:55:38 <genjix> yeah you're right then
437 2011-11-02 22:55:41 <genjix> that is too early
438 2011-11-02 22:55:43 <doublec> or someone publishing a list of "these checkpoints are valid for my chain"
439 2011-11-02 22:55:50 <doublec> "the one true chain"
440 2011-11-02 22:56:21 <doublec> "if you want to use my exchange, you need to take my checkpoints"
441 2011-11-02 22:56:24 <genjix> i wrote a few paragraphs about the centralising influence of checkpoints
442 2011-11-02 22:56:41 <gmaxwell> http://people.xiph.org/~greg/bc_checkpoints.txt
443 2011-11-02 22:56:46 <imsaguy> speaking of, anyone wanna clear out some old ixcoin?
444 2011-11-02 22:56:56 <genjix> http://privatepaste.com/9a53562df0
445 2011-11-02 22:57:04 <batouzo> imsaguy: I can consider for ok price
446 2011-11-02 22:57:10 <gmaxwell> I wrote that in response to someone claiming that bitcoin wasn't decenteralized due to checkpoints.
447 2011-11-02 22:57:14 <genjix> interesting idea. a market place of checkpoints
448 2011-11-02 22:57:28 <genjix> gmaxwell: hah i wrote that above to ben laurie too
449 2011-11-02 22:57:40 <genjix> this one: http://privatepaste.com/9a53562df0
450 2011-11-02 22:57:47 <coblee> 2|doublec: it doesn't matter if your users take your checkpoints. if less than 50% of users are not taking your checkpoints, the attacker can still 51% you. you will just be stuck on the wrong chain. but then nobody can use your exchange, unless they get on your chain
451 2011-11-02 22:57:49 <genjix> woah but yours is longer
452 2011-11-02 22:58:22 <coblee> 2|so only works if everything is centralized around your exchange
453 2011-11-02 22:58:33 <doublec> coblee|2: my "take my checkpoints" idea was I'd be the true chain, and therefore could never be on the wrong one
454 2011-11-02 22:58:40 <doublec> coblee|2: ie. centralized to the max
455 2011-11-02 22:58:45 <coblee> 2|nice
456 2011-11-02 22:59:12 <doublec> coblee|2: but doesn't help if there's more than one exchange of course
457 2011-11-02 22:59:36 <coblee> 2|double, you should stop channeling RealSolid :)
458 2011-11-02 22:59:50 <doublec> coblee|2: hehe
459 2011-11-02 23:00:23 <coblee> 2|RealSolid: "download my new binary or else you won't be on the true chain"
460 2011-11-02 23:00:40 <gmaxwell> genjix: I have that problem.
461 2011-11-02 23:10:19 <coblee> 2|gmaxwell: so do you think auto lockin is a very bad idea?
462 2011-11-02 23:10:55 <graingert> auto locking?
463 2011-11-02 23:11:24 <graingert> coblee|2: you mean like locking the wallet?
464 2011-11-02 23:11:28 <graingert> or what
465 2011-11-02 23:11:49 <coblee> 2|no lock in a block hash for a block that has 100 confirmations
466 2011-11-02 23:11:56 <coblee> 2|so a reorg can't go past it
467 2011-11-02 23:12:30 <graingert> well it would just mean the network would split
468 2011-11-02 23:13:03 <graingert> and people with the locking will be stuck on a chain with no hashpower
469 2011-11-02 23:13:25 <coblee> 2|yes, when that happens, you can run a command to unlock your chain and accept the reorg