1 2014-04-21 00:00:42 <Emcy_> actually the floor staff probably got fucked over just as hard, so i shouldnt joke
2 2014-04-21 00:00:42 <jakov> and a great youtube video
3 2014-04-21 00:00:42 <jakov> yeah wrong chan, #bitcoin
4 2014-04-21 00:00:49 <Emcy_> that live btc txn world map in the ceiling was REALLY cool though
5 2014-04-21 00:01:03 <Emcy_> if theres one lesson that should be taken from all of this, its that
6 2014-04-21 00:01:15 <Emcy_> more nifty txn maps with blu leds
7 2014-04-21 00:01:19 <jakov> stop funding stupid ventures
8 2014-04-21 00:02:02 <gmaxwell> this is all offtopic here.
9 2014-04-21 03:47:59 <ProfMac> I apologize for my off topic post. It was intended for #bitcoin-otc.
10 2014-04-21 04:01:37 <ranger420> are there any good open source bitcoin market maker bots?
11 2014-04-21 04:01:50 <ranger420> I would like to help provide stability to the market
12 2014-04-21 04:02:08 <ranger420> PS. Happy 420 ^^
13 2014-04-21 04:02:41 <sipa> #bitcoin-pricetalk :)
14 2014-04-21 04:03:08 <ranger420> price talk is dead :P sorry to interrupt dev
15 2014-04-21 04:21:41 <Dizzle> ranger420: doubt there are any open source ones. If it's making dat money, why inspire competition?
16 2014-04-21 04:22:24 <ranger420> stabilizing bitcoin
17 2014-04-21 04:27:29 <Dizzle> Well, a noble cause I suppose, though it's really just stabilizing Bitcoin and USD if you're talking about market-making on an exchange. Looks like some people got started and gave up: https://github.com/search?q=bitcoin+market+maker&type=Repositories&ref=searchresults
18 2014-04-21 05:30:05 <btc123> hi
19 2014-04-21 05:30:51 <btc123> i'm trying to do some research on Proof-of-Stake, I was wondering if any of you can point me to a open-source implementation of a 100% PoS coin that was fully mined in the genesis block and then distributed
20 2014-04-21 05:31:28 <btc123> NXT isn'y fully open-sourced
21 2014-04-21 05:31:32 <btc123> *isn't
22 2014-04-21 05:41:39 <justanotheruser> btc123: blackcoin, but it has automatic checkpoints
23 2014-04-21 05:42:49 <sipa> btc123: 100% propf of state doea not work as a consensus algorithm
24 2014-04-21 05:43:21 <btc123> sipa: how is NXT functioning then?
25 2014-04-21 05:43:22 <sipa> *proof, *does
26 2014-04-21 05:43:37 <sipa> btc123: openssl also works, despite heartbleed
27 2014-04-21 05:43:58 <btc123> justanotheruser: blackcoin was PoW for early blocks, can i just take that to an extreme and be PoW for say the first 10 blocks?
28 2014-04-21 05:43:59 <sipa> but every 100% posmcoin suffers from the nothingf-at-stake problem
29 2014-04-21 05:44:14 <btc123> sipa: the argument is that the 'value of their coins' are at stake
30 2014-04-21 05:44:24 <btc123> so why would they 51% attack their own value
31 2014-04-21 05:44:46 <justanotheruser> btc123: 0.001 coins aren't very valuable, but trying to win based on that is easy
32 2014-04-21 05:44:47 <btc123> the incentive structure seems to make sense, unless i'm missing something
33 2014-04-21 05:44:47 <sipa> btc123: if you consider that a good argument, nobody would ever steal bitcoin either
34 2014-04-21 05:45:19 <btc123> sipa: a large holder of bitcoin wouldn't want the block chain to be attacked
35 2014-04-21 05:45:41 <sipa> unless it's sufficiently profitable or undetectable
36 2014-04-21 05:46:07 <btc123> sipa, so in your opinion NXT will have a critical failure at some point?
37 2014-04-21 05:46:13 <sipa> yes
38 2014-04-21 05:46:23 <sipa> i think it will die well before that point, though
39 2014-04-21 05:46:35 <btc123> thats too bad, your opinion carries a lot of weight ;)
40 2014-04-21 05:46:53 <btc123> are there any other core devs who would disagree with you?
41 2014-04-21 05:47:23 <sipa> but yes, if it becomes sufficiently profitable, i think people will start buiilding (reverse engineering if necessary) miners that build off multiple branches of a fork
42 2014-04-21 05:47:55 <sipa> which, if done by enough people will just cause the system to stop converging
43 2014-04-21 05:48:10 <justanotheruser> sipa: it will probably be pretty profitable as soon as you can short NXT, right?
44 2014-04-21 06:38:47 <splitting> anyone here work with the python rpc api?
45 2014-04-21 06:39:20 <Dizzle> Nope, though may be soon. Mind you, there are a couple of those out there.
46 2014-04-21 06:40:17 <Dizzle> This seems to be the one ppl are leaning towards: https://github.com/petertodd/python-bitcoinlib
47 2014-04-21 06:40:19 <splitting> yeah i'm using https://github.com/jgarzik/python-bitcoinrpc
48 2014-04-21 06:40:38 <Dizzle> k
49 2014-04-21 06:40:40 <splitting> mostly because my code isnt bitcoin specific
50 2014-04-21 07:51:10 <caronmb> banned from #bitcoin!
51 2014-04-21 07:51:10 <caronmb> haha
52 2014-04-21 07:53:20 <sipa> wumpus: ok to merge #4058? i want to rebase #3884 on top of it, and then push down some cs_main locks, so we don't stall everything while connecting orphans
53 2014-04-21 09:34:22 <jc__> Excuse me, can anyone tell me something about the transaction fee ?
54 2014-04-21 09:41:19 <melvster> jc__: https://en.bitcoin.it/wiki/Transaction_fees
55 2014-04-21 13:08:28 <ndak> bitcoin gonna die!
56 2014-04-21 13:11:16 <ndak> all because of BITCOINS Owner, who own blockchain.info and he doesnt give a fuck about bitcoin.. the blockchain.info are so lazy and laggig, and this is bussnis for several millions, but he doesnt give a shit. he could fix this for some pennys and buy some new servers. the blockchain are fuckt up and gonna make bitcoin die out
57 2014-04-21 13:11:36 <ndak> withou blockchain.info no BITCOINS
58 2014-04-21 13:13:12 <sipa> ndak: then don't use it
59 2014-04-21 13:14:30 <Luke-Jr> ndak: shut up, this is all off-topic here, and blockchain.info has little to do with Bitcoin (it doesn't even use/represent it correctly)
60 2014-04-21 13:14:39 <ndak> lol
61 2014-04-21 13:14:45 <ndak> they have nothing to do
62 2014-04-21 13:14:53 <ndak> Luke-Jr stfu
63 2014-04-21 13:15:21 <SomeoneWeird> too slow ;)
64 2014-04-21 13:15:23 <Luke-Jr> SomeoneWeird wins the race
65 2014-04-21 13:15:25 <Luke-Jr> :p
66 2014-04-21 13:15:34 <sipa> i take off my op for yoy, sir
67 2014-04-21 13:20:04 <sdak> Luke-Jr: I join this channel whenever i want JUST SO YOU KNOW. Understood?
68 2014-04-21 13:20:05 <sdak> :)
69 2014-04-21 15:29:55 <amaclin> Luke-Jr, can you answer a question https://bitcointalk.org/index.php?topic=571229.0 Is there a way to connect to Eligius pool with bitcoin ( :8333 ) protocol to send non-standard tx?
70 2014-04-21 15:39:10 <justanotheruser> amaclin: ,,(bc,wiki free relay policy)
71 2014-04-21 15:39:11 <gribble> https://en.bitcoin.it/wiki/Free_transaction_relay_policy | Nov 8, 2013 ... The original client currently refuses to relay transactions it considers " unacceptable". However, there may be miners that are willing to put these ...
72 2014-04-21 15:44:28 <amaclin> I use non-standard client "Satoshi:0.8.99/next-test:20130721" and I can create non-standard transactions, but I can not send it into the network because I do not have Eligius in my peer list
73 2014-04-21 15:44:55 <sipa> use -addnode=IP
74 2014-04-21 15:45:30 <amaclin> thanks, sipa, but what is Eligius IP? :)
75 2014-04-21 15:46:17 <kaptah> amaclin: this will not do?`http://eligius.st/~wizkid057/newstats/pushtxn.php
76 2014-04-21 15:52:20 <amaclin> kaptah, thank you. I know about this web-form. May be it is possible to send non-standard tx with it, but I want to redeem non-standard :) Please read the discussion here https://bitcointalk.org/index.php?topic=571229.0 and here https://bitcointalk.org/index.php?topic=527237
77 2014-04-21 16:09:40 <tyrick> What file does LogPrintf write out to?
78 2014-04-21 16:09:46 <tyrick> or fprintf even
79 2014-04-21 16:09:55 <tyrick> trying to find a log file to tail
80 2014-04-21 16:10:23 <chichov> in which class do I have to sniff around to create fresh, random keypairs?
81 2014-04-21 16:10:23 <sipa> debug.log
82 2014-04-21 16:10:30 <sipa> chichov: CKey
83 2014-04-21 16:10:42 <chichov> sipa: alright, I'll take a second look
84 2014-04-21 16:10:52 <sipa> tyrick: with -logtostderr it goes to stderr
85 2014-04-21 16:13:48 <chichov> sipa: CKey::MakeNewKey generates a private key. The public key is simply derived from the private key?
86 2014-04-21 16:14:14 <sipa> yes
87 2014-04-21 16:15:09 <tyrick> sipa: where is it
88 2014-04-21 16:15:14 <sipa> tyrick: ?
89 2014-04-21 16:15:24 <tyrick> find . -name *.log only returns config.log
90 2014-04-21 16:15:32 <chichov> In hindsight, it must be this way. All the curve parameters are set and the public key P is simply P=S*G, where G is the generator and S the secret key.
91 2014-04-21 16:15:35 <sipa> tyrick: it's in the data directory
92 2014-04-21 16:15:47 <sipa> tyrick: https://en.bitcoin.it/wiki/Data_directory
93 2014-04-21 16:16:19 <tyrick> gotcha
94 2014-04-21 16:16:23 <tyrick> I didn't even think to look there
95 2014-04-21 16:19:20 <chichov> sipa: what is meant with compression in the context of CKey?
96 2014-04-21 16:24:25 <tyrick> doesn't seem promising
97 2014-04-21 16:24:38 <tyrick> tail -f debug.log
98 2014-04-21 16:25:26 <tyrick> then in qt/bitcoin.cpp i placed LogPrintf("*************************", "INSIDE MAIN"); in the main() function
99 2014-04-21 16:25:43 <tyrick> rebuild project, ran ./bitcoin-qt
100 2014-04-21 16:25:49 <tyrick> nothing printed out
101 2014-04-21 16:28:30 <tyrick> well, for the moment, I take that all back
102 2014-04-21 16:28:36 <tyrick> I was having build failures I didn't see
103 2014-04-21 16:30:23 <tyrick> works great
104 2014-04-21 16:32:32 <chichov> any way to directly print out a CKey?
105 2014-04-21 16:37:16 <ahf> /w #roffe
106 2014-04-21 16:37:36 <ahf> close, but no cigar.
107 2014-04-21 16:43:39 <sipa> chichov: the 33-byte format for public keys is called the compressed format (as opposed to the 65 byte format)
108 2014-04-21 16:44:14 <sipa> chichov: you can use the base58 to convert it to a wip key
109 2014-04-21 16:44:24 <sipa> chichov: or use HexStr directly on CKey
110 2014-04-21 16:44:41 <chichov> HexStr seems like the way to go then
111 2014-04-21 16:44:47 <chichov> thanks
112 2014-04-21 17:03:05 <chichov> sipa: plugging CPrivKey into HexStr gives me a strange output
113 2014-04-21 17:03:31 <chichov> whereas CPubKey seems to look fine
114 2014-04-21 17:04:01 <chichov> 0x04 followed by 128 hex characters (2*32 byte each)
115 2014-04-21 17:04:10 <sipa> chichov: CPrivKey is an ssl-serialized private key
116 2014-04-21 17:04:15 <sipa> with tons of metadata
117 2014-04-21 17:04:22 <sipa> if you just want to private key, use CKey
118 2014-04-21 17:04:45 <chichov> alright then, I'll keep that in mind
119 2014-04-21 17:26:36 <kjj> so, did I miss the meeting where we decided to replicate the forums on the dev mailing list?
120 2014-04-21 18:21:15 <exfortuna> What can I do as a non-developer to contribute to the protocol?
121 2014-04-21 18:22:07 <sipa> exfortuna: you mean to the reference client?
122 2014-04-21 18:22:15 <sipa> the protocol very rarely changes
123 2014-04-21 18:23:36 <exfortuna> roger!
124 2014-04-21 18:24:33 <sipa> you can help test release candidates (or even pull requests)
125 2014-04-21 18:27:40 <exfortuna> I'll look into it, thanks!
126 2014-04-21 18:55:34 <Jacques__> hey all! Does anyone know what the += 27 in a compact signature is for? (ref https://github.com/bitcoin/bitcoin/blob/2aed2b30b112aaaf7d46df4fd947648ca8df4e67/src/key.cpp#L415)
127 2014-04-21 18:56:15 <sipa> Jacques__: for adding the number 27 :)
128 2014-04-21 18:56:40 <sipa> Jacques__: so that the first byte distinguishes it from public keys or addresses
129 2014-04-21 18:57:39 <Jacques__> Jacques__: not sure I follow, how would it ever be confused with them?
130 2014-04-21 18:58:24 <sipa> public keys are the same length (if uncompressed), and start with 0x04
131 2014-04-21 18:58:36 <sipa> we just picked some number
132 2014-04-21 18:59:32 <sipa> and addresses have data starting with 0x00 or 0x02, and private keys 0x80
133 2014-04-21 18:59:51 <sipa> those have a different length, though
134 2014-04-21 19:00:32 <Jacques__> lol
135 2014-04-21 19:00:40 <Jacques__> fair enough :)
136 2014-04-21 19:01:08 <Jacques__> if Bitcoin stands the test of time, in its exact current form... it will be a conspiracy I'm sure
137 2014-04-21 19:02:14 <sipa> it may well be that bitcoin stands the test of time, but message signatures don't
138 2014-04-21 19:02:19 <sipa> they're quite independent
139 2014-04-21 19:02:39 <Jacques__> Funny part was
140 2014-04-21 19:02:47 <Jacques__> 'Bitcoin Signed Message:\n' is 27 characters
141 2014-04-21 19:02:51 <Jacques__> I thought it was related
142 2014-04-21 19:02:57 <sipa> haha :D
143 2014-04-21 19:03:40 <Jacques__> Why that message prefix btw?
144 2014-04-21 19:04:05 <sipa> to prevent someone giving you a message to sign that happens to be a transaction
145 2014-04-21 19:04:19 <sipa> so you'd sign their transaction with your key
146 2014-04-21 19:04:23 <Jacques__> hahaah... wow, never would have thought that
147 2014-04-21 19:04:46 <gmaxwell> Nor would the users, which is why it must be protected against in the design. :)
148 2014-04-21 19:05:50 <Jacques__> THey'd have to sign the binary clump though right?
149 2014-04-21 19:06:08 <Jacques__> That mistake would only occur in an automation
150 2014-04-21 19:06:23 <Jacques__> (by binary clump, I mean the transaction hash)
151 2014-04-21 19:06:24 <sipa> indeed, it's unlikely, but still very easy to prevent
152 2014-04-21 19:06:40 <sipa> you never know what life technologies start living
153 2014-04-21 19:07:49 <Jacques__> tl;dr you basically salted it :S
154 2014-04-21 19:08:14 <Jacques__> but no, cool, interesting :)
155 2014-04-21 19:58:34 <maaku> can we start a #bitcoin-bikeshedding mailing list so we can move certain discussions there?
156 2014-04-21 20:02:08 <Luke-Jr> maaku: haha
157 2014-04-21 20:36:54 <bitnumus> Hi all, i'm receiving this warning, any cause for concern? > 2014-04-21 20:36:07 CheckForkWarningConditions: Warning: Large valid fork found
158 2014-04-21 20:37:19 <bitnumus> forking the chain at height 292839 (00000000000000004f34aacad7008a0affd076bc8b4e7433136ba4538f03e511)
159 2014-04-21 20:37:24 <bitnumus> lasting to height 295832 (000000000000000000d188728e375f977b99ee3f36b029c3bd3f5326028d9ce3).
160 2014-04-21 20:37:26 <bitnumus> Chain state database corruption likely
161 2014-04-21 20:37:35 <sipa> yes
162 2014-04-21 20:38:26 <bitnumus> sipa, may have been an unclean shutdown (i'm trying to import from bootstrap.dat)
163 2014-04-21 20:38:30 <bitnumus> how to rectify ?
164 2014-04-21 20:38:48 <sipa> run with -reindex
165 2014-04-21 20:39:12 <bitnumus> ok ta
166 2014-04-21 21:32:32 <theodon7473> i would also love to join the bitcoin development team. Could anyone suggest me from where i should start ?
167 2014-04-21 21:33:12 <maaku> theodon7473: there is no 'team'
168 2014-04-21 21:33:20 <maaku> there are issues on github, pick one
169 2014-04-21 21:34:27 <theodon7473> maaku: ok. i would check github for further details. thank you.
170 2014-04-21 21:35:00 <maaku> do you have a particular skillset?
171 2014-04-21 21:35:17 <maaku> one thing that is always helpful is writing unit tests, and is a good thing to do as you learn the code base
172 2014-04-21 21:37:05 <theodon7473> maaku: yes, i can do python, perl and C
173 2014-04-21 21:37:39 <daybyter> but no java...
174 2014-04-21 21:37:46 <theodon7473> but yes i am an amature not so professional. But i am quite confident i can.
175 2014-04-21 21:38:08 <theodon7473> daybyter: nop. i don't know java. Had tried javascript a long time back.
176 2014-04-21 22:24:11 <saizai> technical question: approx. how many bitcoin *addresses* can be generated per second?
177 2014-04-21 22:24:20 <saizai> (not block hashes, addresses)
178 2014-04-21 22:24:35 <saizai> supposing itâs done on a typical terraminer-grade machine
179 2014-04-21 22:25:10 <sipa> saizai: do you require their corresponding private keys too? :)
180 2014-04-21 22:25:14 <saizai> yes
181 2014-04-21 22:25:43 <saizai> so no, you donât get to just enumerate bigints :P
182 2014-04-21 22:25:48 <sipa> dang
183 2014-04-21 22:25:56 <saizai> give me some credit, mon ;)
184 2014-04-21 22:26:56 <gmaxwell> done on a typical terraminer-grade machine
185 2014-04-21 22:26:59 <gmaxwell> zero addresses per second
186 2014-04-21 22:27:00 <saizai> Iâm trying to estimate the difficulty of an address collision attack (both targeted and random)
187 2014-04-21 22:27:08 <gmaxwell> I like easy questions.
188 2014-04-21 22:27:15 <saizai> per hour then?
189 2014-04-21 22:27:31 <gmaxwell> zero per hour too. It can't generate any at all.
190 2014-04-21 22:27:34 <saizai> or are you cheating by saying it wouldnât have the code
191 2014-04-21 22:27:42 <gmaxwell> no, it doesn't have the capability.
192 2014-04-21 22:27:47 <saizai> yeah, I meant in terms of cpu/gpu power, not code
193 2014-04-21 22:27:58 <sipa> look up oclvanitygen
194 2014-04-21 22:28:16 <gmaxwell> I'm not talking about software
195 2014-04-21 22:28:20 <saizai> assume it was built to attack addresses rather than blocks :p
196 2014-04-21 22:28:33 <sipa> that's a very vague question
197 2014-04-21 22:28:38 <gmaxwell> High speed mining devices are not general circuits, they compute sha256, which is largely unrelated to generating addresses.
198 2014-04-21 22:28:39 <saizai> ohright, I forgot about vanity gen
199 2014-04-21 22:28:46 <saizai> thatâs a good analogy
200 2014-04-21 22:28:56 <saizai> gmaxwell: hence stipulating it was built to do this
201 2014-04-21 22:28:59 <sipa> specialized hardware is specalized, and can't do anything else
202 2014-04-21 22:29:03 <Happzz> are the criterias to determine an input's spending priority listed in specifics somewhere?
203 2014-04-21 22:29:18 <sipa> if you're looking for an equivalent... what do you mean? hardware with the same development costs?
204 2014-04-21 22:29:24 <sipa> the same chip area?
205 2014-04-21 22:29:27 <Happzz> at least the way bitcoin-qt does it
206 2014-04-21 22:29:29 <sipa> the same heat consumption?
207 2014-04-21 22:29:38 <saizai> sipa: letâs suppose total cost
208 2014-04-21 22:29:47 <saizai> itâs necessarily a rough guess
209 2014-04-21 22:29:58 <saizai> Iâm only looking for order of magnitude or so
210 2014-04-21 22:29:59 <gmaxwell> in any case, the space of private keys is 2^256, the space of addresses is 2^160 with the relevant work to required to find a second preimage out of some set. so you can figure out lower bound for work just assuming that you're incrementing a counter and nothing else.
211 2014-04-21 22:30:47 <saizai> m, with no ability to target an attack
212 2014-04-21 22:31:05 <saizai> (unless someoneâs broken the crypto)
213 2014-04-21 22:31:12 <sipa> extrapolating from gpu-based numbers, i'd say that an "equivalent" (in therms of chip area, silicon technology, ...) ASIC to a mining asic would be 10 times slower or so?
214 2014-04-21 22:31:14 <gmaxwell> and you end up with unfathomably large numbers even on a physical basis (assuming non-adiabatic computing)
215 2014-04-21 22:31:34 <sipa> so a 1 GH/s chip could do 100Maddr/s
216 2014-04-21 22:31:49 <sipa> may be off by an order of magnitude
217 2014-04-21 22:31:57 <saizai> https://en.bitcoin.it/wiki/Vanitygen guesstimates 20Mkey/s for a good gpu
218 2014-04-21 22:32:02 <saizai> albeit not ASIC
219 2014-04-21 22:32:15 <sipa> ;;nethash
220 2014-04-21 22:32:16 <gribble> 60780569.0432
221 2014-04-21 22:32:47 <sipa> so if all mining hardware were instead address mining hardware, we'd do some 6 Taddr/s
222 2014-04-21 22:33:24 <saizai> whichâd result in a random collision⦠/me calculates
223 2014-04-21 22:33:31 <sipa> or 2^67 addresses per year
224 2014-04-21 22:33:47 <gmaxwell> saizai: uh a "random collision" is completely useless.
225 2014-04-21 22:33:49 <sipa> you need 2^80 to have a reasonable chance for any collision
226 2014-04-21 22:33:53 <sipa> but collisions are useless
227 2014-04-21 22:34:00 <sipa> you need a preimage with an address that actually has coins
228 2014-04-21 22:34:08 <saizai> gmaxwell: not 100% useless, just mostly
229 2014-04-21 22:34:18 <saizai> itâd have two signing keys, which could be interesting
230 2014-04-21 22:34:23 <saizai> (it certainly would be for tor)
231 2014-04-21 22:34:30 <sipa> they wouldn't know it about eachother
232 2014-04-21 22:34:33 <saizai> but yes, preimage is better
233 2014-04-21 22:34:36 <sipa> and probably never would
234 2014-04-21 22:34:43 <gmaxwell> saizai: It would not be interesting in the context of bitcoin.
235 2014-04-21 22:34:45 <sipa> look at it this way
236 2014-04-21 22:34:59 <sipa> if all satoshi's were assigned to a different address each
237 2014-04-21 22:35:05 <gmaxwell> (also collission searches end up memory bandwidth bound, so thats a whole different anaylsis)
238 2014-04-21 22:35:19 <sipa> that's 2^51 UTXOs
239 2014-04-21 22:35:22 <saizai> (I know, hence my saying itâs totally ballpark)
240 2014-04-21 22:35:25 <sipa> you'd need to match one of those
241 2014-04-21 22:35:39 <saizai> ACTION nods
242 2014-04-21 22:35:41 <gmaxwell> you'd ge a hit in approximately 22053424868613687174649119 years assuming maximum address usage.
243 2014-04-21 22:35:47 <saizai> heh
244 2014-04-21 22:36:02 <gmaxwell> (and 6Ta/s)
245 2014-04-21 22:36:13 <saizai> ACTION checks what the word for that order of magnitude is
246 2014-04-21 22:36:24 <saizai> septillion
247 2014-04-21 22:36:52 <saizai> perfect, thatâs about what I needed
248 2014-04-21 22:36:54 <sipa> gmaxwell: how can you end up with *exactly* the same number as i do?
249 2014-04-21 22:37:09 <sipa> the next digits are .806266, right?
250 2014-04-21 22:37:23 <gmaxwell> .80626631966182370895149247875690951210002
251 2014-04-21 22:37:39 <saizai> (Iâm responding to an FEC comment saying that itâs âmathematically unlikelyâ to get an address collision by saying no actually itâs statistically impossible)
252 2014-04-21 22:37:39 <sipa> of course, we don't actually have a julian calendar anymore
253 2014-04-21 22:37:41 <gmaxwell> sipa: because we both mishandled leapyears in exactly the same ways.
254 2014-04-21 22:38:09 <saizai> (and anticipating a possible âjust how impossible do you meanâ type question from one of the commissioners)
255 2014-04-21 22:38:10 <gmaxwell> since years congruent to 1 mod 100 are not leapyears.
256 2014-04-21 22:38:41 <saizai> somehow I doubt that makes much difference at this scale :p
257 2014-04-21 22:38:55 <gmaxwell> saizai: any such thing would come either via a cryptosystem break or via broken hardware/sofware (bad rngs) not through a 'brute force' attack.
258 2014-04-21 22:38:59 <saizai> O(20 septillion)
259 2014-04-21 22:39:03 <saizai> ACTION nods
260 2014-04-21 22:39:18 <saizai> text I have now: âA targeted Bitcoin address collision is not merely "mathematically unlikely"; it's statistically impossible, short of a cryptographic attack on the Bitcoin algorithm sophisticated enough to completely break Bitcoin. â
261 2014-04-21 22:39:19 <sipa> 2.2 * 10^25
262 2014-04-21 22:39:58 <sipa> gmaxwell: better use the astronomical time of a year, which calendars approximate
263 2014-04-21 22:40:19 <gmaxwell> sipa: have to account for the tidal braking.
264 2014-04-21 22:40:22 <saizai> https://docs.google.com/document/d/1fROdNRFL8BEqVN-6rdZeNZyN8WD2vBMYCHP4P12pxKE/edit if you want to read it
265 2014-04-21 22:40:32 <saizai> wonât be posted until ~noon Eastern tomorrow
266 2014-04-21 22:40:48 <saizai> and itâs responding to http://saos.fec.gov/aodocs/1255510.pdf
267 2014-04-21 22:41:04 <edcba> as mathematically sure as statistically unlikely ?
268 2014-04-21 22:41:30 <sipa> i think that any practical break would go in steps
269 2014-04-21 22:41:39 <saizai> sipa: almost always does
270 2014-04-21 22:41:56 <sipa> where someone finds some attack on ECDSA, which reduces it some bit, but far from enough to be worrisome
271 2014-04-21 22:42:04 <saizai> keyspace reduction attacks are the usual, not total breakage, at least for anything non-naïve in the first place
272 2014-04-21 22:42:54 <edcba> anyway instead of counting how many keys you can generate by seconds you should try with enumerating bigints...
273 2014-04-21 22:44:48 <sipa> in other words: at maximum utxo distribution, 1s of the world's current total hash power (converted to equivalent address mining) would gain you .000000000000000000000000000086 BTC
274 2014-04-21 22:44:53 <sipa> on average
275 2014-04-21 22:45:31 <saizai> lol
276 2014-04-21 22:45:59 <edcba> but imagine if 1 BTC is worth $1T !!!
277 2014-04-21 22:46:01 <sipa> 10 minutes of it earns you 483300805995668954432435460 times less than the block subsidy you would have got with it
278 2014-04-21 22:46:07 <saizai> I like the âyou could do this in about 22 septillion yearsâ answer
279 2014-04-21 22:46:22 <saizai> itâs just in case I get asked about that line
280 2014-04-21 22:46:47 <saizai> I never know what kind of questions Iâll get; I try to be prepared for such quips
281 2014-04-21 22:47:59 <sipa> there are almost as many addresses as there as atoms on earth
282 2014-04-21 22:48:01 <edcba> http://www.reddit.com/r/Bitcoin/comments/1ohwvu/bitcoin_your_money_is_secured_by_the_laws_of_the/ccs83kx
283 2014-04-21 22:48:04 <edcba> damn we aren't safe !
284 2014-04-21 22:49:07 <saizai> right
285 2014-04-21 22:49:12 <saizai> just need to build a Dyson sphere first.
286 2014-04-21 22:49:15 <gmaxwell> edcba: I'm really not so keen on that poster people keep linking to, physics as we understand them do not preclude things like adabatic computing which only need energy to reject errors. We don't know how to build such things but physics appears to permit it.
287 2014-04-21 22:49:17 <saizai> no biggie
288 2014-04-21 22:49:52 <saizai> but anyway, a crack of that order would break pretty much all crypto everywhere anyway
289 2014-04-21 22:50:14 <sipa> of course, there could just be a bug in OpenSSL's EC implementation :p
290 2014-04-21 22:50:19 <edcba> bitcoin is still safer than credit cards...
291 2014-04-21 22:50:43 <edcba> millions of them being "cracked" a month
292 2014-04-21 22:51:01 <saizai> yeah
293 2014-04-21 22:51:17 <saizai> + stolen + you can just buy one in cash at your local no-camera convenience store
294 2014-04-21 22:51:45 <maaku> saizai: that's the bigger argument - just note how the same crypto secures pretty much every financial and governmental protocol in existence
295 2014-04-21 22:51:54 <saizai> ACTION nods
296 2014-04-21 22:52:02 <Luke-Jr> if bitcoin had as much use as credit cards, I bet you'd see stolen wallets all over
297 2014-04-21 22:52:23 <sipa> Luke-Jr: i'm glad we don't use this "handwritten signature" cryptosystem indeed
298 2014-04-21 22:52:43 <saizai> maaku: Iâm not sure which ones use ECDSA etc
299 2014-04-21 22:53:03 <sipa> saizai: 256 ECDSA is approximately equivalent to 3000 bit RSA
300 2014-04-21 22:53:05 <saizai> so itâs easier to just say âbreak Bitcoinâ than be more grandiose
301 2014-04-21 22:53:45 <sipa> i believe 512-bit RSA is still used?
302 2014-04-21 22:54:51 <sipa> hmm, could be cracked for $150, according to a stackexchange answer
303 2014-04-21 22:56:15 <gmaxwell> sipa: yes, I've cracked RSA512.
304 2014-04-21 22:56:45 <sipa> i will quote you on this
305 2014-04-21 22:56:51 <sipa> 00:56:12 < gmaxwell> sipa: yes, I've cracked RSA
306 2014-04-21 22:56:59 <saizai> http://blogs.wsj.com/moneybeat/2014/04/21/bitbeat-bitcoin-and-political-donations/?mod=wsj_streaming_stream just got posted
307 2014-04-21 22:56:59 <sipa> (some bits lost)
308 2014-04-21 22:57:00 <gmaxwell> You have a future in journalism I see.
309 2014-04-21 22:57:11 <saizai> :)
310 2014-04-21 22:57:33 <sipa> "Bitcoin Core developer admits attacking cryptography used by banks."
311 2014-04-21 22:57:43 <Luke-Jr> rofl
312 2014-04-21 22:58:51 <Luke-Jr> right now some journalist is reading this thinking "holy cow, bitcoin devs are discussing attacking banks"
313 2014-04-21 22:59:02 <gmaxwell> ACTION facepalm
314 2014-04-21 22:59:32 <sipa> ACTION napalm
315 2014-04-21 22:59:57 <saizai> Luke-Jr: You have a future in politics I see.
316 2014-04-21 23:01:00 <Luke-Jr> saizai: I sure hope not.
317 2014-04-21 23:01:05 <saizai> :P
318 2014-04-21 23:09:00 <owowo> ACTION loves the smell of napalm in the morning
319 2014-04-21 23:09:16 <saracen> ACTION hates the smell of facepalm in the morning
320 2014-04-21 23:10:54 <jcorgan> hmm github https authentication failure
321 2014-04-21 23:12:18 <edcba> credit cards are often used for ingestion of drugs whereas bitcoin never !
322 2014-04-21 23:12:44 <alt123> hey guys, i was wondering if there is a 'dev' channel for alt-coin related discussion?
323 2014-04-21 23:12:56 <alt123> i'm trying to generate a genesis block for a chain using X11
324 2014-04-21 23:13:34 <alt123> ^ X11 proof of work algo
325 2014-04-21 23:13:43 <edcba> X11 ? http://en.wikipedia.org/wiki/X_Window_System ?
326 2014-04-21 23:13:52 <jcorgan> alt123: not this one
327 2014-04-21 23:14:38 <sipa> (if only all those altcoin authors would realize that the genesis block isn't actually validated...)
328 2014-04-21 23:19:36 <jcorgan> anyone else able to get to github via https? getting HSTS certificate failure on authentication
329 2014-04-21 23:27:25 <jakov> sipa does that mean the nonce for a genesis block could be anything?
330 2014-04-21 23:33:53 <melvster> jakov: genesis block is not special it just has a previous block of 0 ... the nonce can be anything
331 2014-04-21 23:34:24 <sipa> jakov: yes
332 2014-04-21 23:36:38 <gmaxwell> jcorgan: passes here, sounds like you're getting MITMed by someone with a valid cert? :P can you grab the certificate you're seeing?
333 2014-04-21 23:48:22 <jcorgan> http://pastebin.com/cnMD6AUK is what is returned by openssl
334 2014-04-21 23:56:28 <jcorgan> works with Firefox. Maybe my MITM attacker just got my github credentials :)