1 2011-08-24 01:24:28 <whiteman> If I want to make a Bitcoin web service, what do I use for the back end? Is there a libary?
  2 2011-08-24 01:25:42 <Diablo-D3> whiteman: its normal jsonrpc
  3 2011-08-24 01:26:45 <whiteman> Is there a good example of a scripted client out there?
  4 2011-08-24 01:27:28 <Diablo-D3> no.
  5 2011-08-24 01:29:22 <johntobey253> There's libbitcoin under development and BitcoinJ in Java might help, but most everybody uses JSON-RPC.  See "bitcoind help"
  6 2011-08-24 01:30:24 <nanotube> see also the wiki docs
  7 2011-08-24 03:54:14 <osmosis> jgarzik, if  bitcoind getinfo  returned valuable diagnostic information, i could write some munin graphing plugins to track the data.
  8 2011-08-24 04:01:20 <nanotube> hey osmosis :)
  9 2011-08-24 04:01:40 <osmosis> nanotube, yo! good seeing you at the conf
 10 2011-08-24 04:01:50 <nanotube> indeed, same here :)
 11 2011-08-24 04:03:49 <osmosis> nanotube, definitely interested in more web interface stuff with web of trust. Will be on it as soon as i figure out how to manage my collapsing stack of worth while bitcoin projects.
 12 2011-08-24 04:04:41 <nanotube> hehe sounds great!
 13 2011-08-24 04:05:22 <nanotube> the web stuff and the distributed stuff can really be tackled independently, so let's see how it goes
 14 2011-08-24 04:06:00 <cjdelisle> also a complaint/response system would be awesome... will get there eventually if noone beats me to it.
 15 2011-08-24 04:06:30 <luke-jr> cjdelisle: not sure it's needed?
 16 2011-08-24 04:06:41 <luke-jr> the only problems I've seen are scammers downrating legit users
 17 2011-08-24 04:06:51 <luke-jr> and they aren't going to worry about complaint/response nonsense
 18 2011-08-24 04:07:21 <nanotube> well, ideally, the only ratings /you/ have to worry about is from people other people trust.
 19 2011-08-24 04:07:39 <osmosis> luke-jr, and scammers tricking new users into giving a rating of 10.
 20 2011-08-24 04:08:05 <nanotube> if $randomscammer downrates you, it doesn't do anything if nobody trusts him.
 21 2011-08-24 04:08:31 <nanotube> since it's not about cumulative ratings, but about trust paths between you and other 'real' users.
 22 2011-08-24 04:08:45 <cjdelisle> "they aren't going to worry about complaint/response nonsense" <-- that is part of the point. Also there are cases where nobody really meant to scam anyone and it's just a big misunderstanding.
 23 2011-08-24 04:09:04 <luke-jr> nanotube: in practice, I find there's too few connections to rely on that alone
 24 2011-08-24 04:09:30 <luke-jr> cjdelisle: I suspect those misunderstands self-resolve :p
 25 2011-08-24 04:09:31 <nanotube> luke-jr: yes well, that is the unfortunate reality when the network is still quite small...
 26 2011-08-24 04:09:48 <nanotube> cjdelisle: then users get together (possibly with an arbiter), talk it out, and adjust their ratings subsequently.
 27 2011-08-24 04:09:53 <nanotube> (ideally) heh
 28 2011-08-24 04:10:56 <cjdelisle> Yea, it makes a lot more sense with websites where one "entity" is doing business with a ton of people and people want to know if they are responsive.
 29 2011-08-24 04:11:46 <nanotube> well, i would expect in the future plenty of businesses would have nodes on the wot
 30 2011-08-24 04:12:38 <cjdelisle> Also with a business, a satisfied customer is unlikely to uprate them but an angry customer will make a ton of noise.
 31 2011-08-24 04:13:02 <cjdelisle> case in point: google $AnyHostingCompany scam
 32 2011-08-24 04:13:39 <nanotube> well, such is life. a business can encourage all customers to create wot accounts for a mutual rating
 33 2011-08-24 04:13:46 <nanotube> thus reducing this filter bias
 34 2011-08-24 04:15:01 <cjdelisle> I hope to solve the problem like the BBB but with less corruption, if you care about your reputation then you will answer complaints reasonably fast.
 35 2011-08-24 04:15:58 <nanotube> cjdelisle: what is the bbb corruption? and how are you thinking of solving it?
 36 2011-08-24 04:16:18 <noagendamarket> bbb gets paid for good ratings
 37 2011-08-24 04:17:34 <cjdelisle> There's no need for people to pay to be members and there's no need for an overall rating, people can read: "has 3 settled complaint and 1 open complaint"
 38 2011-08-24 04:19:50 <cjdelisle> I did some testing of the consept here: http://bitcoin.crimeunit.net/wiki/index.php/Complaints rammerhammer (Alex Nagelberg) had a problem with bitcoincashout.com so I took down the info and he is waiting on a response from them
 39 2011-08-24 05:23:55 <drona> cortex a8 timer0 any sample program link
 40 2011-08-24 05:45:11 <CIA-101> bitcoin: Con Kolivas * r9ab15a..666fcc cgminer/ (util.c miner.h uthash.h main.c): (5 commits)
 41 2011-08-24 08:15:10 <CIA-101> bitcoin: Con Kolivas * r6197ff20096f cgminer/main.c: Remove silly debugging output.
 42 2011-08-24 08:40:21 <CIA-101> bitcoin: Con Kolivas * r7407e887f607 cgminer/configure.ac: Update configure.ac for newer autoconf tools.
 43 2011-08-24 08:46:10 <Lopuz> EXCEPTION: 11DbException Db::put: Cannot allocate memory
 44 2011-08-24 08:50:18 <CIA-101> bitcoin: Con Kolivas * r0899ee86aeeb cgminer/main.c: Only consider pool slow to respond if we can't even roll work.
 45 2011-08-24 08:52:01 <vv01f> hello everyone
 46 2011-08-24 08:53:55 <vv01f> there was a question in the forums: is it possible to use different wallets with a single instance of bicoin-daemon - so to either switch between wallets or handle multiple ones? if not, any plans or other solutions to that?
 47 2011-08-24 08:55:13 <tcatm> vv01f: wallet export/import is the closest we'll have
 48 2011-08-24 08:56:33 <vv01f> any schedule or prio on that matter?
 49 2011-08-24 08:57:14 <vv01f> dunno if some wallet-service do contribute on those functions - but i assume they have some solution for those problems (offline wallet etc.)
 50 2011-08-24 08:57:34 <tcatm> https://github.com/bitcoin/bitcoin/pull/220
 51 2011-08-24 08:57:57 <vv01f> thank you very much :)
 52 2011-08-24 09:00:56 <epscy> ;;bc,stats
 53 2011-08-24 09:00:58 <gribble> Current Blocks: 142384 | Current Difficulty: 1805700.8361937 | Next Difficulty At Block: 143135 | Next Difficulty In: 751 blocks | Next Difficulty In About: 4 days, 22 hours, 16 minutes, and 57 seconds | Next Difficulty Estimate: 1873891.93679015
 54 2011-08-24 10:10:11 <CIA-101> bitcoin: Con Kolivas * rdbf0a1366d69 cgminer/ (main.c miner.h): Use the new hashes directly for counts instead of the fragile counters currently in use.
 55 2011-08-24 10:10:12 <CIA-101> bitcoin: Con Kolivas * r73c98e1e7949 cgminer/main.c: Check if there is more than one work item queued before complaining about a slow pool.
 56 2011-08-24 11:25:30 <CIA-101> bitcoin: Con Kolivas * r48f07d921933 cgminer/ (sha256_sse2_amd64.c x86_64/sha256_xmm_amd64.asm): Update to latest sse2 code from cpuminer-ng.
 57 2011-08-24 11:25:32 <CIA-101> bitcoin: Con Kolivas * rb643b56a9523 cgminer/main.c: Allow LP to reset block detect and block detect lp flags to know who really came first.
 58 2011-08-24 11:25:33 <CIA-101> bitcoin: Con Kolivas * r5a2cf5a6b123 cgminer/main.c: Get start times just before mining begins to not have very slow rise in average.
 59 2011-08-24 11:35:16 <CIA-101> bitcoin: Con Kolivas * rcea1cf6cc0c5 cgminer/main.c: Revert "Since we roll work all the time now, we end up staging a lot of work without queueing, so don't queue if we've already got staged work."
 60 2011-08-24 11:35:18 <CIA-101> bitcoin: Con Kolivas * rf2f0ba80242b cgminer/main.c: Revert "Revert "Since we roll work all the time now, we end up staging a lot of work without queueing, so don't queue if we've already got staged work.""
 61 2011-08-24 12:34:42 <ThomasV> gavinandresen: what was that pull request you showed me, for signing message with wallet private keys ?
 62 2011-08-24 12:35:34 <gavinandresen> https://github.com/bitcoin/bitcoin/pull/183
 63 2011-08-24 12:36:01 <ThomasV> ty
 64 2011-08-24 12:37:40 <CIA-101> bitcoin: Gavin Andresen master * r1224a14 / locale/cs/LC_MESSAGES/bitcoin.po :
 65 2011-08-24 13:35:30 <b4epoche> interesting email from Gavin
 66 2011-08-24 13:40:35 <nanotube> b4epoche: what email?
 67 2011-08-24 13:45:34 <b4epoche> on the email list
 68 2011-08-24 13:45:44 <b4epoche> nanotube:^
 69 2011-08-24 14:01:19 <nanotube> b4epoche: yea found it. not a big fan of a 'blockchain fork' at all. multisig tx ++, but blockchainfork --.
 70 2011-08-24 14:01:27 <nanotube> imo
 71 2011-08-24 14:02:02 <ThomasV> what are multisignature tx ?
 72 2011-08-24 14:03:10 <ThomasV> oh I see
 73 2011-08-24 14:09:43 <ThomasV> why does he call this a blockchain split ?
 74 2011-08-24 14:30:12 <luke-jr> nanotube: I'm only a fan if it gets some bigger issues fixed.
 75 2011-08-24 14:30:25 <nanotube> luke-jr: which are what?
 76 2011-08-24 14:30:28 <luke-jr> ThomasV: I think he wants to redo the whole address format? not sure on that part
 77 2011-08-24 14:30:39 <luke-jr> nanotube: see my email for a few
 78 2011-08-24 14:30:46 <ThomasV> yeah, I'm reading it
 79 2011-08-24 14:30:54 <jrmithdobbs> i'm confused on the necessity of the split as well
 80 2011-08-24 14:30:54 <nanotube> ThomasV: to get a 'short address' which is a hash of multiple pubkeys, we need new opcodes. that would fork the chain.
 81 2011-08-24 14:31:11 <justmoon> luke-jr, unrelated question: what's the status of your threaded_rpc patch/fork?
 82 2011-08-24 14:31:13 <jrmithdobbs> his email was kind of rambling
 83 2011-08-24 14:31:13 <nanotube> if you're ok with longer addresses (basically, concatenating a bunch of regular addresses), then no chainsplit and no new opcodes necessary.
 84 2011-08-24 14:31:20 <nanotube> jrmithdobbs: ^ see above
 85 2011-08-24 14:31:29 <nanotube> from his email, see also the link to that github gist.
 86 2011-08-24 14:31:36 <jrmithdobbs> ya i saw it
 87 2011-08-24 14:31:38 <nanotube> where i think he describes things in some more details
 88 2011-08-24 14:31:41 <luke-jr> justmoon: current version works great
 89 2011-08-24 14:31:41 <ThomasV> nanotube: it would "fork" it only in the sense that a few users would forget to upgrade
 90 2011-08-24 14:31:48 <justmoon> luke-jr, k, thx
 91 2011-08-24 14:32:05 <nanotube> ThomasV: well, it's a fork then. :) currently if you forget to upgrade, you're still ok.
 92 2011-08-24 14:32:09 <jrmithdobbs> nanotube: he was just sort of jumping all over the place in his email and didn't really make his points very well
 93 2011-08-24 14:32:25 <nanotube> indeed. i think he was assuming prior knowledge from earlier discussion :)
 94 2011-08-24 14:32:30 <jrmithdobbs> nanotube: he kept talking about people's wallets getting stolen but what he was actually addressing in content really hase little-to-zero to do with that
 95 2011-08-24 14:32:30 <nanotube> because a lot of discussion happened at tho con
 96 2011-08-24 14:32:52 <nanotube> well, multisig stuff would be great for multi-factor authentication for tx spending
 97 2011-08-24 14:33:01 <nanotube> that's what he was meaning about stolen wallets
 98 2011-08-24 14:33:16 <jrmithdobbs> it doesn't help that at all
 99 2011-08-24 14:33:17 <nanotube> (i.e., to spend a tx, you need more than one key, each key is stored on different device)
100 2011-08-24 14:33:42 <jrmithdobbs> if the multiple factors are coming from the same person and one set is compromised it's likely the other factors were stored similarly and will be just as easy to compromise
101 2011-08-24 14:33:55 <nanotube> it helps a lot, imo? if your desktop is compromised and wallet stolen, but it only contains 1 of 2/3 keys needed to redeem your tx
102 2011-08-24 14:34:12 <nanotube> jrmithdobbs: one of the keys can be escrowed with a third party, etc.
103 2011-08-24 14:34:21 <nanotube> or can be on a mobile device
104 2011-08-24 14:34:23 <jrmithdobbs> ya he left out all the context
105 2011-08-24 14:34:26 <nanotube> or on a smartcard, etc.
106 2011-08-24 14:34:32 <jrmithdobbs> there's a simpler solution tho
107 2011-08-24 14:34:42 <jrmithdobbs> multifactor auth on the wallet crypto.
108 2011-08-24 14:35:05 <jrmithdobbs> nanotube: i understand what he was saying now with that context. thanks ;p
109 2011-08-24 14:35:13 <ThomasV> nanotube: if your desktop is compromised the attacker can compromise your client and you'll get stolen next time you plug your 2nd key
110 2011-08-24 14:35:15 <luke-jr> nanotube: no. because people *won't* use bitcoin if they need 2 or 3 devices to spend
111 2011-08-24 14:35:22 <nanotube> not the same - as long as wallet is decrypted to memory to sign stuff... a compromised computer means you can be screwed just as well.
112 2011-08-24 14:35:26 <nanotube> luke-jr: it's /optional/
113 2011-08-24 14:35:32 <luke-jr> nanotube: and nobody will use it.
114 2011-08-24 14:35:32 <nanotube> jrmithdobbs: np :)
115 2011-08-24 14:35:36 <jrmithdobbs> nanotube: it means that period
116 2011-08-24 14:35:36 <luke-jr> nanotube: so it's useless :P
117 2011-08-24 14:35:42 <nanotube> ThomasV: you don't plug in the second key
118 2011-08-24 14:35:47 <nanotube> the tx gets passed on to your second device.
119 2011-08-24 14:35:50 <nanotube> and signed there
120 2011-08-24 14:36:09 <nanotube> luke-jr: clients and services can develop to support that in a user-friendly manner.
121 2011-08-24 14:36:12 <ThomasV> how so ?
122 2011-08-24 14:36:23 <jrmithdobbs> nanotube: in the "Real World" if one of your clients gets compromised there's a good chance the second will as well
123 2011-08-24 14:36:24 <ThomasV> you have 2 devices, with 2 displays ?
124 2011-08-24 14:36:30 <jrmithdobbs> because of how real users actually use devices
125 2011-08-24 14:36:34 <nanotube> ThomasV: yes, computer and phone, e.g.
126 2011-08-24 14:36:42 <ThomasV> it's too complicated
127 2011-08-24 14:36:57 <nanotube> or, computer and a "bitcoinsafe" which stores one of the privkeys for you
128 2011-08-24 14:37:13 <jrmithdobbs> either way
129 2011-08-24 14:37:13 <nanotube> ThomasV: it still is better than having to require a special-made hardware device. well, cheaper, not better :)
130 2011-08-24 14:37:20 <ThomasV> I can see that it would be useful for escrow services, but not for a single individual
131 2011-08-24 14:37:22 <jrmithdobbs> all that's necessary to make this work is outside of protocol level
132 2011-08-24 14:37:30 <luke-jr> nanotube: less practical than special-made hardware
133 2011-08-24 14:37:37 <jrmithdobbs> it just requires export of unsigned txns and import/broadcast of signed ones
134 2011-08-24 14:37:39 <luke-jr> nanotube: and there's no reason phones can't be that special-made hardware
135 2011-08-24 14:37:47 <luke-jr> they're certainly DRM'd up enough
136 2011-08-24 14:37:47 <ThomasV> nanotube: no, it's too unpractical
137 2011-08-24 14:37:57 <jrmithdobbs> luke-jr: not really
138 2011-08-24 14:38:03 <ThomasV> nanotube: if I am on the go, I need 2 telephones ?
139 2011-08-24 14:38:07 <jrmithdobbs> luke-jr: phones are an awful choice for this
140 2011-08-24 14:38:11 <nanotube> luke-jr: yes, but generally once you plug a phone by usb into a computer... its filesystem is your bitch.
141 2011-08-24 14:38:19 <jrmithdobbs> luke-jr: because none of the user-accessible portions get encrypted/drm'ed
142 2011-08-24 14:38:27 <nanotube> right
143 2011-08-24 14:38:37 <jrmithdobbs> luke-jr: piss off customs re-entering the country? guess what? they have your privkeys.
144 2011-08-24 14:38:59 <jrmithdobbs> because they will, and do, clone your phone
145 2011-08-24 14:39:10 <luke-jr> nanotube: what's wallet encryption for?
146 2011-08-24 14:39:35 <luke-jr> nevermind that it's currently based on AES which is broken
147 2011-08-24 14:39:36 <nanotube> well... it offers some very good possibilities. once the network allows rebroadcasting multisig tx, the way is open for a bunch of interesting stuff.
148 2011-08-24 14:39:48 <jrmithdobbs> luke-jr: aes isn't broken for pratical applications at this time
149 2011-08-24 14:39:53 <jrmithdobbs> luke-jr: it's only broken by 2bits
150 2011-08-24 14:40:06 <jrmithdobbs> and there is no better alternative
151 2011-08-24 14:40:44 <jrmithdobbs> nanotube: i don't think multisig solves this problem. I think it just makes a very annoying use case for multi-factor auth that will never actually be used
152 2011-08-24 14:41:14 <luke-jr> jrmithdobbs: for now
153 2011-08-24 14:41:19 <luke-jr> jrmithdobbs: PGP?
154 2011-08-24 14:41:38 <nanotube> jrmithdobbs: well, i can imagine systems built on this that actually work quite well.
155 2011-08-24 14:42:06 <jrmithdobbs> jrmithdobbs: pgp uses aes/dsa/rsa and/or serpent (which does not have enough cryptanalysis done to know if it's better or worse than rjindael)?
156 2011-08-24 14:42:32 <jrmithdobbs> jrmithdobbs: dsa/rsa are impractical for this application
157 2011-08-24 14:42:35 <jrmithdobbs> erm
158 2011-08-24 14:42:42 <jrmithdobbs> s/jrmithdobbs/luke-jr/ ^^
159 2011-08-24 14:42:45 <luke-jr> IDEA?
160 2011-08-24 14:42:49 <jrmithdobbs> patents
161 2011-08-24 14:42:55 <luke-jr> screw patents
162 2011-08-24 14:43:19 <luke-jr> it's an algorithm
163 2011-08-24 14:43:21 <luke-jr> the patent is invalid
164 2011-08-24 14:43:23 <jrmithdobbs> aes256 is still the best we have now
165 2011-08-24 14:43:30 <jrmithdobbs> that is legal to use
166 2011-08-24 14:43:57 <b4epoche> luke-jr is going to put up the money to fight over the patent!
167 2011-08-24 14:44:05 <jrmithdobbs> and he'll lose
168 2011-08-24 14:44:18 <b4epoche> yep
169 2011-08-24 14:44:21 <jrmithdobbs> because there's clear case history that contradicts his ideals which he refuses to accept.
170 2011-08-24 14:44:35 <jrmithdobbs> s/history/law/
171 2011-08-24 14:45:02 <luke-jr> no need
172 2011-08-24 14:46:05 <upb> yep because the courts report to god
173 2011-08-24 14:46:07 <jrmithdobbs> luke-jr: IDEA wont be free to use for another ~15 months
174 2011-08-24 14:46:13 <luke-jr> jrmithdobbs: that's pretty soon
175 2011-08-24 14:46:17 <imsaguy2> lol @ upb
176 2011-08-24 14:46:17 <jrmithdobbs> yes
177 2011-08-24 14:48:02 <luke-jr> http://en.wikipedia.org/wiki/Talk:International_Data_Encryption_Algorithm#Patent_expiration_date
178 2011-08-24 14:48:09 <luke-jr> looks like it expired already actually
179 2011-08-24 14:48:12 <jrmithdobbs> but even with aes' recent breaking aes256 still provides more security than idea
180 2011-08-24 14:48:20 <jrmithdobbs> depends on country
181 2011-08-24 14:48:27 <luke-jr> PGP FAQ: "This patent expires 25 May 2010 (USA) or 16 May 2011 (Europe and Japan)."
182 2011-08-24 14:48:37 <jrmithdobbs> there's one in 2012 as well
183 2011-08-24 14:48:39 <jrmithdobbs> i forget where
184 2011-08-24 14:49:35 <luke-jr> jrmithdobbs: the Talk page suggests the 2012 date is kept simply because there's no ruling and Wikipedia wants to err on the side of safety
185 2011-08-24 14:49:59 <Tuxavant> anyone here applied the sipa import/export patch? I'd like to give it a try and would like to know if someone here would be able to mentor me in how to get it done
186 2011-08-24 14:50:11 <jrmithdobbs> but ya, 2^254 > 2^128 so aes256 is still better for now even assuming the less scrutinized IDEA has no flaws outside of the known weak keys (pretty huge assumption)
187 2011-08-24 14:50:37 <jrmithdobbs> assuming proper use of xex/xts for large sets of data, of course
188 2011-08-24 14:51:18 <luke-jr> jrmithdobbs: you're considering that AES256 is less secure than AES128?
189 2011-08-24 14:51:36 <jrmithdobbs> only with crazy related key attacks that aren't relevant to the real world
190 2011-08-24 14:52:20 <jrmithdobbs> the only known, at this time, single-key attack on aes reduces it to 2^126 and 2^254 respectively
191 2011-08-24 14:52:46 <jrmithdobbs> (the one published a couple weeks ago)
192 2011-08-24 14:52:47 <Diablo-D3> in other words, not enough to matter yet.
193 2011-08-24 14:52:52 <jrmithdobbs> right
194 2011-08-24 14:53:29 <jrmithdobbs> it's enough that it's worth people starting to work on new ciphers, but they're going to be doing that anyways
195 2011-08-24 16:11:07 <Tuxavant> looking for someone with a few minutes to get me started in compiling the bitcoin client with the sipa import/export patch on linux. anyone?
196 2011-08-24 16:37:08 <jgarzik> gavinandresen: so, dumb question...  is this multisig stuff a breaking change, that makes blocks incompatible with older clients?
197 2011-08-24 16:37:49 <imsaguy2> They were talking about a db version change that would
198 2011-08-24 16:37:51 <gavinandresen> jgarzik: no, not my current proposal.  It uses only existing opcodes
199 2011-08-24 16:37:52 <imsaguy2> one way
200 2011-08-24 16:38:40 <gavinandresen> ... the db4.7-4.8 is a different issue
201 2011-08-24 16:39:28 <jgarzik> gavinandresen: That's about the only thing I would push back on, in a major way.  I really think breaking changes ("if (block > 200000) new_behavior()") should be avoided absent a catastrophic problem such as sha256 is broken.
202 2011-08-24 16:39:55 <jgarzik> gavinandresen: Adding new standard transactions is a good thing in general.  I like the testnet roll-out that people currently do
203 2011-08-24 16:40:24 <gavinandresen> jgarzik: yes, this doesn't feel like a good reason to schedule a block chain split.
204 2011-08-24 16:40:31 <jgarzik> gavinandresen: agreed
205 2011-08-24 16:40:42 <gavinandresen> (although it it is SO tempting to make it perfect.....)
206 2011-08-24 16:40:48 <jgarzik> gavinandresen: yes ;-) ;-)
207 2011-08-24 16:42:16 <jgarzik> gavinandresen: I have ideas about that, too...   IMNSHO people need an outlet for breaking changes.  It's tempting to either (a) work on a bitcoin2, which is current bitcoin + rational breaking changes like new hash algo or new protocol, or (b) someone maintain a list of "changes community would like to see, if and only if there is a planned block chain split"
208 2011-08-24 16:42:18 <gavinandresen> jgarzik: does Linux have something like the python PEP process for proposing new stuff?
209 2011-08-24 16:43:12 <jgarzik> gavinandresen: no, the kernel is all very informal, but in one way, we are highly similar to bitcoin v0.x:  the ABI is inviolable.  we simply _do not_, ever, make breaking changes to the ABI.  Binaries from the original Linux should still be able to run.
210 2011-08-24 16:43:24 <jgarzik> gavinandresen: python and other projects can and do schedule major, breaking changes
211 2011-08-24 16:43:43 <gavinandresen> yup, python3 is an interesting experiment.
212 2011-08-24 16:45:23 <noagendamarket> swap your btc for sc and do the upgrade :)-
213 2011-08-24 16:45:35 <nanotube> gavinandresen: jgarzik: fwiw, i'm also not a fan of a blockchain fork for this. if we can do it without a fork, even if it's not quite as pretty, it should not be forked.
214 2011-08-24 16:46:20 <nanotube> and also, gavinandresen it seems you need a bit more detail in your proposal - had to explain to people here why you thought multisig had anything to do with stolen wallets :)
215 2011-08-24 16:46:36 <gavinandresen> jgarzik: I was thinking about how to handle "when we DO decide to fork the blockchain" patches/changes, too...  didn't come up with any solution I really like.
216 2011-08-24 16:47:44 <jgarzik> gavinandresen: yeah...
217 2011-08-24 16:48:23 <gavinandresen> nanotube: I'll try to do better next time.
218 2011-08-24 16:48:57 <nanotube> gavinandresen: just fyi :) it was all quite clear to me, but i had more context :)
219 2011-08-24 16:49:40 <jgarzik> gavinandresen: from an existential and PR standpoint, I think major blockchain forks are tough no matter how high the technical justification, because, in theory, blockchhain forks are like US Constitutional Conventions:  _anything_ can be changed, in theory, including the basic rules like the 21M limit.  Blockchain forks are our equivalent of Federal Reserve policy changes.   It is the "nuclear option."
220 2011-08-24 16:50:35 <jgarzik> gavinandresen: Thus, I prefer extremely ugly hacks, or simply saying "no" (or "put it in btc2") than blockchain forks that are incompatible with older clients
221 2011-08-24 16:51:14 <jgarzik> blockchain forks that are compatible with older clients, I am OK with.  The sendmany was a good example of that...  clients wouldn't relay for a while, but older clients supported it just fine.
222 2011-08-24 16:51:50 <nanotube> right, imo a 'fork' is where an older client will reject the chain as invalid. anything else is an incremental improvement.
223 2011-08-24 16:51:57 <gavinandresen> yeah, when I say blockchain fork I mean a change that makes clients outright REJECT now-valid blocks.
224 2011-08-24 16:52:16 <gavinandresen> (not the soft-shun of "I just won't include them in blocks I create")
225 2011-08-24 16:54:39 <noagendamarket> cant you hash the existing bitcoins and prove you own old ones to be included in the new chain ?
226 2011-08-24 16:54:41 <coblee> 2|do we have a wiki page discussing blockchain forks and what kind of changes causes what? if not, it would be useful.
227 2011-08-24 16:56:10 <iddo> what is the difference between blockchain fork and starting a completely new blockchain ?
228 2011-08-24 16:56:32 <iddo> noagendamarket: you mean this? http://bitcointalk.org/?topic=191.msg1585#msg1585
229 2011-08-24 16:56:38 <noagendamarket> its not solid :)-
230 2011-08-24 16:56:59 <noagendamarket> iddo yes
231 2011-08-24 16:57:14 <noagendamarket> if you need to upgrade the hashing algo
232 2011-08-24 16:59:48 <iddo> what is the difference between blockchain fork and starting a completely new blockchain ? would people be able to transfer the bitcoins that they control to the forked chain ?
233 2011-08-24 17:00:41 <jgarzik> a blockchain fork does not invalidate older coins and transactions
234 2011-08-24 17:00:51 <jgarzik> it simply requires a new client to understand new transactions
235 2011-08-24 17:01:03 <jgarzik> and older clients cannot understand the new transactions
236 2011-08-24 17:01:12 <noagendamarket> yeah everyone would have to update the client
237 2011-08-24 17:01:59 <iddo> but the new clients still respect the old blocks ?
238 2011-08-24 17:02:06 <noagendamarket> yea
239 2011-08-24 17:02:34 <noagendamarket> as long as the majority of people upgraded
240 2011-08-24 17:02:48 <noagendamarket> then youd get a new fork
241 2011-08-24 17:03:50 <coblee> 2|thank satoshi for including opcode scripting in original client so that we can add things without doing blockchain forking.
242 2011-08-24 17:04:39 <iddo> so for example that switching from sha256 to sha3 is a blockchain fork ? because old clients don't use sha3 ?
243 2011-08-24 17:04:46 <noagendamarket> yes
244 2011-08-24 17:05:20 <noagendamarket> if you do that you may as well doa  lot of stuff at once
245 2011-08-24 17:08:01 <iddo> not sure i understand why save sha3 for all the old blocks, instead of just for the last block before the fork
246 2011-08-24 17:08:39 <Diablo-D3> you wouldnt
247 2011-08-24 17:08:46 <Diablo-D3> you'd only need it for the first psudeo-genesis block
248 2011-08-24 17:09:52 <iddo> Diablo-D3: i'm just quoting "The software could save the new hash of all the old blocks to make sure a different block with the same old hash can't be used."
249 2011-08-24 17:09:57 <jgarzik> noagendamarket: what is SC?
250 2011-08-24 17:10:22 <ThomasV> jgarzik:  solidcoin
251 2011-08-24 17:10:34 <iddo> maybe he simply meant by "all the old blocks" just the last block before the fork
252 2011-08-24 17:10:50 <noagendamarket> what ThomasV said
253 2011-08-24 17:11:52 <jgarzik> noagendamarket: hmmm, the manifesto at https://bitcointalk.org/index.php?topic=38453.0 contains a lot of exaggerations.  sounds a bit like ixcoin
254 2011-08-24 17:12:42 <noagendamarket> well it was  a response to it
255 2011-08-24 17:13:29 <Diablo-D3> iddo: thats impossible.
256 2011-08-24 17:13:54 <Diablo-D3> iddo: block header includes gen time.
257 2011-08-24 17:14:03 <Diablo-D3> iddo: also, how do you use an old header?
258 2011-08-24 17:14:04 <Diablo-D3> er
259 2011-08-24 17:14:05 <Diablo-D3> old block
260 2011-08-24 17:14:11 <Diablo-D3> same rules apply for block gen
261 2011-08-24 17:14:17 <Diablo-D3> number of binary zeros.
262 2011-08-24 17:14:32 <Diablo-D3> a sha2 with a high number of binary zeroes is NOT going to produce a sha3 with high number of binary zeros
263 2011-08-24 17:14:35 <Diablo-D3> theres nothing TO reuse.
264 2011-08-24 17:15:27 <iddo> you need to link somehow the new genesis block to the last forked block, no?
265 2011-08-24 17:17:02 <iddo> i dont think you need leading zeros or anything
266 2011-08-24 17:17:56 <iddo> just all the new clients have to agree what is the sha3 hash of the last block of the old blockchain
267 2011-08-24 17:18:11 <Diablo-D3> iddo: thats why I said psudeo genesis
268 2011-08-24 17:18:14 <Diablo-D3> and no
269 2011-08-24 17:18:21 <Diablo-D3> all the clients have to agree when the first sha3 is by count
270 2011-08-24 17:18:23 <Diablo-D3> not by last sha2
271 2011-08-24 17:18:30 <Diablo-D3> because you wont know what the last sha2 is ahead of time
272 2011-08-24 17:18:36 <Diablo-D3> you need to plan for sha3 a year or more ahead of time
273 2011-08-24 17:20:23 <iddo> ahh so you cannot use sha256 vulnerabilities to extend the old blocks, because you will get stuck when you reach the new pseudo genesis block
274 2011-08-24 17:20:59 <Diablo-D3> yes
275 2011-08-24 17:21:15 <Diablo-D3> all clients will say, say, the 250kth block will be the first sha3
276 2011-08-24 17:21:18 <Diablo-D3> and all afterwards are sha3
277 2011-08-24 17:21:31 <Diablo-D3> you cant do anything stupid because its nonsensical
278 2011-08-24 17:22:29 <cjdelisle> That wouldn't really work either because I could just offer old blocks from per-change with mercal tree schenanigans, swapping payout addresses etc.
279 2011-08-24 17:22:30 <iddo> so the forum post seems to be wrong?
280 2011-08-24 17:23:11 <iddo> what do you mean, offer old blocks ?
281 2011-08-24 17:23:16 <cjdelisle> yeap
282 2011-08-24 17:23:23 <iddo> ?
283 2011-08-24 17:23:34 <iddo> i dont understand
284 2011-08-24 17:23:57 <cjdelisle> If sha256 is (completely) broken, I'll just attack the transactions so they all pay me.
285 2011-08-24 17:24:35 <Diablo-D3> cjdelisle: not quite
286 2011-08-24 17:24:40 <mtrlt> and how do you do that >_>
287 2011-08-24 17:24:41 <Diablo-D3> half of the potential attacks dont apply
288 2011-08-24 17:24:48 <iddo> we assume majority of honest clients, so they will only respect the longest chain, with sha3 starting at some point
289 2011-08-24 17:24:50 <mtrlt> afaik you need to break ecdsa for that
290 2011-08-24 17:24:55 <Diablo-D3> the other half of potential attacks only effect future blocks
291 2011-08-24 17:25:27 <Diablo-D3> remember
292 2011-08-24 17:25:31 <Diablo-D3> any "useful" attack on sha256
293 2011-08-24 17:25:33 <iddo> cjdelisle: maybe you mean if sha256 becomes suddenly completely broken?
294 2011-08-24 17:25:35 <Diablo-D3> will be added to my miner.
295 2011-08-24 17:25:48 <Diablo-D3> so an attack on sha256 just increases difficulty
296 2011-08-24 17:25:59 <ThomasV> I do not feel comfortable with the idea of a blockchain split
297 2011-08-24 17:26:06 <Diablo-D3> ThomasV: there wouldnt be
298 2011-08-24 17:26:18 <cjdelisle> I could go through all the coinbase transactions and generate new ones which fit the mercal tree but pay out to me instead of the original miner then tell everyone that those are the real transactions.
299 2011-08-24 17:26:21 <Diablo-D3> there would be a very small minority of users wondering why their client is out of sync.
300 2011-08-24 17:26:24 <Diablo-D3> and they cant make new blocks
301 2011-08-24 17:26:31 <Diablo-D3> and new tx are being lost
302 2011-08-24 17:26:53 <Diablo-D3> you need a significant number of clients that didnt upgrade a year earlier to do that
303 2011-08-24 17:27:04 <ThomasV> Diablo-D3: that's not the problem. my problem is that I am not convinced if the proposeed changes are necessary
304 2011-08-24 17:27:05 <Diablo-D3> er, to fork the chain I mean
305 2011-08-24 17:27:12 <Diablo-D3> ThomasV: oh, they arent
306 2011-08-24 17:27:17 <ThomasV> lol
307 2011-08-24 17:27:21 <Diablo-D3> people keep talking about it and it doesnt matter
308 2011-08-24 17:27:27 <Diablo-D3> the sha256 is used as a proof of work
309 2011-08-24 17:27:35 <Diablo-D3> if it is significantly broken, difficulty just skyrockets.
310 2011-08-24 17:28:09 <Diablo-D3> coin ownership (ie, public/private keypairs) dont use sha256.
311 2011-08-24 17:28:22 <Diablo-D3> and like I said, half of potential attacks dont work
312 2011-08-24 17:28:46 <Diablo-D3> we have a 80 byte header which is always 80 byte headers which you have very little control over whats in it...
313 2011-08-24 17:28:49 <Diablo-D3> and we run sha256 twice.
314 2011-08-24 17:29:25 <cjdelisle> mercal tree attacks would work since you can add arbitrary data by just adding a bunch of tiny transactions with bunk public keys.
315 2011-08-24 17:30:24 <iddo> cjdelisle: huh? you need to extend the blockchain all the way to the current blocks, which are sha3 ?
316 2011-08-24 17:30:38 <cjdelisle> But the solution os not that difficult either, you just make a sha3 based chain which tracks the original chain but the sha3 based chain's difficulty is 0 and it just idles until it is needed, then everyone switches to the sha3 chain and the difficulty is increased.
317 2011-08-24 17:31:39 <cjdelisle> and at the time of the switch, obviously, the hash of the last 0 difficulty block is hardcoded into the source.
318 2011-08-24 17:33:55 <iddo> cjdelisle: what attack will work? we assume that majority of honest clients will respect some block at future as genesis sha3 block, i.e. they consider it as the block right after the last sha256 block even though they are not linked
319 2011-08-24 17:35:38 <iddo> if you couldnt attack until reaching the genesis sha3 block, what new attack do you have now?
320 2011-08-24 17:36:31 <cjdelisle> the transactions are hashed into the blocks, for starters I could forge coinbase transactions so it looks like I mined all of the coins before the switch.
321 2011-08-24 17:37:08 <Diablo-D3> cjdelisle: merkle tree attacks "work"
322 2011-08-24 17:37:12 <Diablo-D3> but for a completely different reason
323 2011-08-24 17:37:20 <Diablo-D3> I already said you have control over very little of the data.
324 2011-08-24 17:37:24 <Diablo-D3> thats very little of the data.
325 2011-08-24 17:37:30 <Diablo-D3> sha256 hashes the header, not the whole block.
326 2011-08-24 17:37:46 <Diablo-D3> and no, you dont start a new chain
327 2011-08-24 17:37:49 <Diablo-D3> because its not a new chain
328 2011-08-24 17:38:02 <Diablo-D3> it already contains transactions and coins in play.
329 2011-08-24 17:38:09 <Diablo-D3> you dont "track" the original chain.
330 2011-08-24 17:38:14 <Diablo-D3> and you dont set the diff to 0
331 2011-08-24 17:38:20 <Diablo-D3> the diff will manage itself.
332 2011-08-24 17:38:27 <iddo> but all the honest miners only agree to extend the longest chain that they see, so they will extend with the new sha3 genesis block, and if you couldnt attack it until that time, you cannot compete with the honest miners now either, no?
333 2011-08-24 17:38:34 <Diablo-D3> iddo: uh, no
334 2011-08-24 17:38:41 <Diablo-D3> its not about honest miners.
335 2011-08-24 17:38:54 <TuxBlackEdo> wut
336 2011-08-24 17:39:05 <Diablo-D3> miners cant extends their own chain without having more than 50% of the global hash power.
337 2011-08-24 17:39:06 <Diablo-D3> period.
338 2011-08-24 17:39:24 <Diablo-D3> and we are not starting a brand new sha3 chain
339 2011-08-24 17:39:26 <Diablo-D3> that is nonsensical.
340 2011-08-24 17:39:49 <cjdelisle> meh, at this point it's barroom discussion
341 2011-08-24 17:39:55 <Diablo-D3> honestly, people, use your fucking common sense.
342 2011-08-24 17:40:19 <Diablo-D3> not only that
343 2011-08-24 17:40:30 <Diablo-D3> what matters is how many cycles per bit a gpu implemention takes
344 2011-08-24 17:40:37 <iddo> Diablo-D3: i think the concern was that someone could extend the old chain in a different way, before the genesis sha3 block, because the new genesis block isnt linked to the last forked block... so i tried to explain why you cannot do it without 50% hash power
345 2011-08-24 17:40:53 <Diablo-D3> iddo: no, thats called "the only bitcoin attack"
346 2011-08-24 17:41:08 <TuxBlackEdo> or the government could shutdown bitcoins
347 2011-08-24 17:41:12 <Diablo-D3> AND the sha3 switch happens at a defined future block.
348 2011-08-24 17:41:23 <Diablo-D3> it doesnt matter if an attack happens or not
349 2011-08-24 17:41:31 <Diablo-D3> if it happens at block 250k, it happens at block 250k period.
350 2011-08-24 17:41:44 <gribble> 142423
351 2011-08-24 17:41:44 <TuxBlackEdo> ;;bc,blocks
352 2011-08-24 17:42:04 <Diablo-D3> the 249999 that becomes the new newest block is the parent of the first sha3 block, 250000.
353 2011-08-24 17:42:13 <Diablo-D3> anyhow, as I was saying
354 2011-08-24 17:42:14 <iddo> all i wanted to claim is that if sha256 was broken "enough" before the fork, then by deciding to do the fork you don't allow new attacks
355 2011-08-24 17:42:17 <Diablo-D3> [03:40:30] <Diablo-D3> what matters is how many cycles per bit a gpu implemention takes
356 2011-08-24 17:42:32 <Diablo-D3> sha3 will not use enough cycles per bit over sha2.
357 2011-08-24 17:42:51 <Diablo-D3> in other words, _it will be the same thing_
358 2011-08-24 17:42:54 <iddo> s/was/wasn't
359 2011-08-24 17:42:59 <Diablo-D3> difficultly will remain roughly unchanged.
360 2011-08-24 17:43:07 <Diablo-D3> sha256 is used as a proof of work
361 2011-08-24 17:43:14 <Diablo-D3> any usable attack just ups the difficulty.
362 2011-08-24 17:43:28 <Diablo-D3> we are not using it as a cryptographic signature, we are using it as a proof of work.
363 2011-08-24 17:44:17 <iddo> yes, the far-fetchecd concern is that sha256 would become broken like md4, so it needs to be replaced
364 2011-08-24 17:44:22 <jrmithdobbs> ya sha being collidable doesn't really change much. it'd have to be a pretty major flaw that was simple as shit to take advantage of
365 2011-08-24 17:44:32 <iddo> i.e. just increased difficulty is not enough to cope with it
366 2011-08-24 17:44:40 <Diablo-D3> iddo: yes
367 2011-08-24 17:44:43 <Diablo-D3> and when that happens
368 2011-08-24 17:44:44 <jrmithdobbs> and the pre-image is pretty sane so something like md4 is fairly unlikely
369 2011-08-24 17:44:45 <Diablo-D3> we switch.
370 2011-08-24 17:45:45 <cjdelisle> The max hash is a long way from zero so difficulty has a long way to go. INO it doesn't really even matter from that perspective.
371 2011-08-24 17:46:05 <Diablo-D3> and btw
372 2011-08-24 17:46:07 <Diablo-D3> if we switch
373 2011-08-24 17:46:11 <Diablo-D3> it wont be to 256 bits
374 2011-08-24 17:46:14 <Diablo-D3> it'll be to 512.
375 2011-08-24 17:46:23 <cjdelisle> that makes the most sense
376 2011-08-24 17:46:33 <iddo> ok all i was saying that i dont understand what cjdelisle attack is, and also satoshi's forum post about hashing old blocks with sha3
377 2011-08-24 17:46:43 <Diablo-D3> all the sha3 canidates have the same "difficulty" per bit as sha2
378 2011-08-24 17:46:59 <Diablo-D3> iddo: uh, why do you think hashing old blocks means anything?
379 2011-08-24 17:47:04 <Diablo-D3> sha3 is not related to sha2
380 2011-08-24 17:47:16 <Diablo-D3> a header that produces a target sha2 wont produce a sha3 that meets target
381 2011-08-24 17:47:23 <Diablo-D3> not only that, the header contains a time stamp
382 2011-08-24 17:47:32 <iddo> Diablo-D3: you convinced me that it doesn't.... i was just quoting http://bitcointalk.org/?topic=191.msg1585#msg1585
383 2011-08-24 17:47:50 <Diablo-D3> erm
384 2011-08-24 17:47:56 <Diablo-D3> except he didnt say reuse old blocks.
385 2011-08-24 17:48:00 <Diablo-D3> he said exactly what I said above.
386 2011-08-24 17:48:07 <Diablo-D3> we all agree on a future block to switch, we switch
387 2011-08-24 17:48:12 <Diablo-D3> it doesnt require any magic
388 2011-08-24 17:48:36 <iddo> maybe i don't understand what he said: "The software could save the new hash of all the old blocks to make sure a different block with the same old hash can't be used."
389 2011-08-24 17:48:56 <Diablo-D3> huh
390 2011-08-24 17:49:01 <Diablo-D3> I need to yell at satoshi
391 2011-08-24 17:49:07 <Diablo-D3> he already accounted for that flaw
392 2011-08-24 17:49:17 <Diablo-D3> -/+ 10 minute timestamps.
393 2011-08-24 17:49:20 <Diablo-D3> you cannot reuse old blocks.
394 2011-08-24 17:50:52 <iddo> i think it might even be possible to fork if ECDSA is broken?
395 2011-08-24 17:51:27 <cjdelisle> "pay to ip address" transactions don't use ECDSA
396 2011-08-24 17:51:38 <Diablo-D3> btw
397 2011-08-24 17:51:40 <Diablo-D3> as a side note
398 2011-08-24 17:51:40 <iddo> if ECDSA is broken in theory, each user could generate a more secure pk/sk pair, sign the new pk with his old sk (which no one else can do because it'd be a gradual process untill ECDSA is actually broken in practice), and by being the first who broadcasts the new keys signed by the old insecure sk, he retains control over his bitcoins?
399 2011-08-24 17:51:45 <Diablo-D3> if sha256 is broken, the world ends.
400 2011-08-24 17:51:55 <Diablo-D3> if ecdsa is broken, the world ended sometime last week.
401 2011-08-24 17:52:04 <cjdelisle> that is true
402 2011-08-24 17:52:29 <cjdelisle> or at least X509 ends -- /me would celebrate that :D
403 2011-08-24 17:52:50 <Diablo-D3> seriously, the military and banking sectors DEPEND on that shit running
404 2011-08-24 17:53:01 <Diablo-D3> and anything involving high end computer security
405 2011-08-24 17:54:04 <iddo> they depend on public key crypto (ssl) mostly to protect from evedropping? it's less important dependency compared to bitcoin, no?
406 2011-08-24 17:54:20 <cjdelisle> everything
407 2011-08-24 17:55:38 <cjdelisle> not just ssl, all signatures
408 2011-08-24 17:55:52 <cjdelisle> (all sigs which use sha256 which is basicly all)
409 2011-08-24 17:56:07 <iddo> banks use signatures for what?
410 2011-08-24 17:57:23 <cjdelisle> signed swift transfers, vpn connections, idk what else
411 2011-08-24 17:58:27 <iddo> ok
412 2011-08-24 17:59:07 <cjdelisle> without x509, https becomes http, online banking and ecommerce is gone, governments, contractors all of those people use smart card auth and guess what it's using... PKCS7... x509...
413 2011-08-24 17:59:30 <Diablo-D3> most password schemes are broken too
414 2011-08-24 17:59:31 <Diablo-D3> even complex ones
415 2011-08-24 17:59:32 <log0s> sorry, i missed most of the discussion and maybe this was covered, but if sha256 is broken to a significant degree, wouldn't an attacker be able to relatively easily create *fake* blockchain history (different blocks, but same block IDs) preceding the new sha3 branch, allowing them to effectively steal everyone's bitcoins that were received from mining?
416 2011-08-24 17:59:46 <Diablo-D3> log0s: no, if sha256 is broken badly, THE WORLD ENDS.
417 2011-08-24 17:59:59 <Diablo-D3> bitcoin is the least of your worries.
418 2011-08-24 18:00:13 <Diablo-D3> log0s: also, no, you cant impersonate anyone
419 2011-08-24 18:00:21 <Diablo-D3> sha256 is only used to provide proof of work.
420 2011-08-24 18:00:25 <cjdelisle> well, md5 was broken badly enough to forge a CA cert but that didn't end the world
421 2011-08-24 18:00:28 <log0s> Diablo-D3: perhaps bitcoin is the least of my worries then, but that doesn't answer my question
422 2011-08-24 18:00:41 <Diablo-D3> no, but that answered your question
423 2011-08-24 18:00:55 <Diablo-D3> user identities (ie, bitcoin addresses) are not protected by sha256.
424 2011-08-24 18:01:05 <Diablo-D3> sha256 is not used as a cryptographic signature in bitcoin.
425 2011-08-24 18:01:08 <Diablo-D3> its used as a proof of work.
426 2011-08-24 18:01:26 <Diablo-D3> its hard to create a target hash, its easy to validate it.
427 2011-08-24 18:01:32 <iddo> log0s: we assume that sha256 is broken gradually, so clients can update to sha3 at certain block in future before sha256 is completely broken in practice (until then, increased difficulty can deal with it)
428 2011-08-24 18:01:36 <cjdelisle> Yes, if sha256 is reduced to triviality, mercal trees can be forged so every transaction can be modified.
429 2011-08-24 18:01:47 <Diablo-D3> cjdelisle: no.
430 2011-08-24 18:02:08 <cjdelisle> Is sha256 not used to hash mercal trees?
431 2011-08-24 18:02:14 <log0s> Diablo-D3: why is cjdelisle wrong?
432 2011-08-24 18:02:15 <Diablo-D3> its merkle goddamnit
433 2011-08-24 18:02:34 <cjdelisle> oh, I thought you were disagreeing with my arguement.
434 2011-08-24 18:02:45 <Diablo-D3> I am
435 2011-08-24 18:02:47 <Diablo-D3> but its merkle.
436 2011-08-24 18:02:51 <Diablo-D3> its a guys name.
437 2011-08-24 18:03:15 <Diablo-D3> you cant CHANGE past transactions
438 2011-08-24 18:03:18 <Diablo-D3> they have to come out valid.
439 2011-08-24 18:03:18 <log0s> even when everyone switches to sha3, they still have to download the old blockchain history of blocks that were originally hashed with sha256...how do you know if they are forged or not?
440 2011-08-24 18:03:29 <Diablo-D3> log0s: because they have to make sense.
441 2011-08-24 18:03:38 <Diablo-D3> if I have 5 coins, and then I send 5 coins, and then I send 5 coins
442 2011-08-24 18:03:43 <Diablo-D3> thats nonsensical.
443 2011-08-24 18:03:54 <Diablo-D3> and the transactions themselves are signed with ECDSA
444 2011-08-24 18:04:01 <Diablo-D3> you cant forge transactions
445 2011-08-24 18:04:52 <cjdelisle> I can forge coinbase transactions pretty easy since they even have a place to put arbitraty data.
446 2011-08-24 18:05:09 <mtrlt> how do you change the address into which the coins are paid?
447 2011-08-24 18:05:21 <Diablo-D3> you cant, its signed with ECDSA.
448 2011-08-24 18:05:22 <TuxBlackEdo> is there any way of running a gui without a running thread that constantly checks if buttons were pressed?
449 2011-08-24 18:05:23 <log0s> Diablo-D3: why can't someone create a new branch from the genesis block on that has all of the coinbase transactions going to the attacker?
450 2011-08-24 18:05:28 <mtrlt> Diablo-D3: exactly
451 2011-08-24 18:05:29 <Diablo-D3> the address is the hash of the ecdsa public key.
452 2011-08-24 18:05:41 <Diablo-D3> log0s: how can he?
453 2011-08-24 18:05:55 <cjdelisle> what's signed with ECDSA? the sha256 hash?
454 2011-08-24 18:06:03 <Diablo-D3> the transaction is signed.
455 2011-08-24 18:06:05 <log0s> Diablo-D3: i'm talking about creating *new blocks*, that hash to the same hash the original block at that height hashed to
456 2011-08-24 18:06:15 <Diablo-D3> log0s: yes, and you cant do that.
457 2011-08-24 18:06:20 <cjdelisle> the first part of signing is hashing
458 2011-08-24 18:06:30 <Diablo-D3> you would require a very fucking bad collision attack
459 2011-08-24 18:06:37 <cjdelisle> Yeap
460 2011-08-24 18:06:42 <Diablo-D3> which doesnt exist
461 2011-08-24 18:06:44 <log0s> Diablo-D3: i thought that's what we were talking about...sha256 being broken!!!
462 2011-08-24 18:06:48 <cjdelisle> That's why I said "reduced to triviality"
463 2011-08-24 18:06:52 <Diablo-D3> log0s: no, sha256 being broken is vague
464 2011-08-24 18:07:20 <iddo> log0s: maybe you'll agree with my earlier comment: but all the honest miners only agree to extend the longest chain that they see, so they will extend with the new sha3 genesis block, and if you couldnt attack it until that time, you cannot compete with the honest miners now either
465 2011-08-24 18:07:28 <Diablo-D3> sha256 has been basically proven that I am more likely to win powerball than a collision attack of the magnitude you need to pule this off
466 2011-08-24 18:07:38 <Diablo-D3> and btw, dont call it a genesis block
467 2011-08-24 18:07:43 <Diablo-D3> its a psudeo genesis block
468 2011-08-24 18:07:44 <Diablo-D3> it has a parent.
469 2011-08-24 18:07:50 <Namegduf> Our blockchain can't repel a collision attack of that magnitude
470 2011-08-24 18:08:21 <log0s> Diablo-D3: i'm talking about the original genesis block, block 0, created by Satoshi...not some future block at height 250k or whatever
471 2011-08-24 18:08:48 <log0s> oh sorry, you were talking to iddo?
472 2011-08-24 18:08:59 <b4epoche> this conversation needs rebooted