1 2013-11-03 00:01:24 <sipa> what do you see in debug.log (with -debug enabled)
2 2013-11-03 00:01:59 <warren> ah, trying tat
3 2013-11-03 00:14:52 <HaltingState> sipa, int secp256k1_ecdsa_pubkey_create(unsigned char *pubkey, int *pubkeylen, const unsigned char *seckey, int compressed);
4 2013-11-03 00:14:58 <HaltingState> is that how i generate private/public keys?
5 2013-11-03 00:16:37 <sipa> HaltingState: you pass in a random 32-byte string as seckey
6 2013-11-03 00:17:01 <sipa> HaltingState: if it is valid, the corresponding pubkey is put in pubkey
7 2013-11-03 00:17:07 <sipa> and true is returned
8 2013-11-03 00:17:14 <sipa> otherwise, false is returned
9 2013-11-03 00:17:15 <HaltingState> what is a non-valid 32 byte string
10 2013-11-03 00:17:26 <sipa> all zeroes of example
11 2013-11-03 00:18:16 <sipa> around 1 in 2^128 32-byte strings are invalid, so the odds of even ever seeing one is extremely rare
12 2013-11-03 00:18:27 <sipa> but still, we need to deal with that possibility
13 2013-11-03 00:18:40 <HaltingState> most random 32 byte strings are points on the curve?
14 2013-11-03 00:18:50 <sipa> strings are not points
15 2013-11-03 00:19:01 <warren> Importing bootstrap.dat...
16 2013-11-03 00:19:06 <HaltingState> they get transformed into points somehow?
17 2013-11-03 00:19:06 <sipa> private keys are mathematically numbers
18 2013-11-03 00:19:13 <warren> then nothing except trying to connect to 0.0.0.0
19 2013-11-03 00:19:16 <warren> no indexing of blocks
20 2013-11-03 00:19:31 <sipa> each has a corresponding point on the curve as public key
21 2013-11-03 00:20:58 <sipa> a private key is just a number
22 2013-11-03 00:21:17 <sipa> a public key is a point with x/y coordinates
23 2013-11-03 00:22:02 <sipa> almost every 256-bit number is a valid private key (one with a point on the curve corresponding to it)
24 2013-11-03 00:22:37 <sipa> HaltingState: ok?
25 2013-11-03 00:22:41 <HaltingState> yes
26 2013-11-03 00:23:14 <HaltingState> i had an F in 750 level graduate group theory, remember that awful book ahahaha
27 2013-11-03 00:23:41 <sipa> 750?
28 2013-11-03 00:23:55 <HaltingState> i know there is a group operation in ECC and its not ring like integers (with addition/multiplication mod N) and that there is single operation
29 2013-11-03 00:24:07 <HaltingState> 100 level is freshman, 200 second year etc.. 750... is ....
30 2013-11-03 00:24:12 <sipa> ok
31 2013-11-03 00:24:37 <sipa> yes, there is an addition operation defined between points on the curve
32 2013-11-03 00:24:40 <HaltingState> it only started to make sense to me after reading a lot of this stuff
33 2013-11-03 00:25:12 <sipa> which always result in a new point on the curve (or the point at infinity)
34 2013-11-03 00:25:17 <HaltingState> actualyl, if you find a point that is not in ring/group, you can probably recover private key (at least for RSA); so i guess those points have to be rare
35 2013-11-03 00:25:19 <sipa> together, those form a group
36 2013-11-03 00:25:43 <sipa> more than half of random points are not on the curve
37 2013-11-03 00:25:54 <sipa> forgrt RSA
38 2013-11-03 00:26:06 <HaltingState> <sipa> almost every 256-bit number is a valid private key (one with a point on the curve corresponding to it)
39 2013-11-03 00:26:14 <sipa> eh
40 2013-11-03 00:26:16 <gmaxwell> private key.
41 2013-11-03 00:26:16 <HaltingState> but half of them are not on curve?
42 2013-11-03 00:26:26 <HaltingState> are private keys on the curve?
43 2013-11-03 00:26:26 <sipa> a private key is a NUMBER
44 2013-11-03 00:26:32 <sipa> a public key is a POINT
45 2013-11-03 00:26:36 <HaltingState> ahhhh
46 2013-11-03 00:26:41 <sipa> the curve comsists of points
47 2013-11-03 00:26:43 <gmaxwell> half the x,y values in the field are not on the curve, a private key is an integer.
48 2013-11-03 00:27:03 <gmaxwell> ACTION lets sipa handle it. oops. :P
49 2013-11-03 00:27:09 <sipa> and actually, it is less tha the square root, not less than half, sorry :)
50 2013-11-03 00:27:52 <sipa> there are approximately 2**256 points on the curve
51 2013-11-03 00:28:06 <HaltingState> ok, i have key generation in the golang secp256k1 working yay
52 2013-11-03 00:28:15 <sipa> while there are (obviously) 2**512 points with 2 256-bit numbers
53 2013-11-03 00:29:03 <gmaxwell> 115792089237316195423570985008687907852837564279074904382605163141518161494337 points for our curve.
54 2013-11-03 00:29:28 <sipa> if you include the point at infinity
55 2013-11-03 00:30:53 <sipa> (not that i checked the number, i just know it has to be odd if you coumt the entire group)
56 2013-11-03 00:32:45 <HaltingState> lol
57 2013-11-03 00:36:40 <warren> confirmed, it is grabbing all of the blocks from the peer after "Importing bootstrap.dat..."
58 2013-11-03 00:37:51 <sipa> what code version?
59 2013-11-03 00:39:14 <warren> this is litecoin-0.8.5.1, I can reproduce it on bitcoin-0.8.5 too
60 2013-11-03 00:39:36 <sipa> is bootstrap.dat renamed afterwards?
61 2013-11-03 00:39:51 <warren> yes
62 2013-11-03 00:40:19 <sipa> but you didn't get any ProcessBlock messages in debug.log before importing ended?
63 2013-11-03 00:41:49 <sipa> ACTION zZzZ
64 2013-11-03 00:43:03 <warren> sipa: no ProcessBlock messages at all until it begins getting blocks from the peer.
65 2013-11-03 00:45:01 <gmaxwell> warren: was this node already partially synced up before you did this?
66 2013-11-03 00:45:21 <warren> gmaxwell: nope
67 2013-11-03 00:47:01 <warren> I used linearize.py in bitcoin master from a bitcoin master node
68 2013-11-03 00:47:31 <phantomcircuit> warren, lol
69 2013-11-03 00:48:23 <gmaxwell> warren: how big is your bootstrap.dat?
70 2013-11-03 00:48:23 <phantomcircuit> warren, cat blocks/blk*dat > bootstrap.dat
71 2013-11-03 00:48:23 <warren> phantomcircuit: what?
72 2013-11-03 00:48:25 <phantomcircuit> magic
73 2013-11-03 00:48:49 <warren> gmaxwell: litecoin is 1.4GB, i'm redoing the bitcoin one now
74 2013-11-03 00:49:17 <warren> phantomcircuit: if you do that isn't it out of order? (not a probem I know)
75 2013-11-03 00:49:26 <warren> except if you want it reproducible
76 2013-11-03 00:49:28 <HaltingState> sipa, gmaxwell https://dl.dropboxusercontent.com/u/21517274/img/bitcoins_stolen.png
77 2013-11-03 00:49:31 <phantomcircuit> warren, no it just has orphaned blocks
78 2013-11-03 00:49:44 <HaltingState> i will add a secure random number generator and an entropy pool ahahaha; omg
79 2013-11-03 00:53:22 <warren> LogPrintf("Loaded %i blocks from external file in %"PRI64d"ms\n", nLoaded, GetTimeMillis() - nStart);
80 2013-11-03 00:53:26 <warren> not seeing this in debug.log at al
81 2013-11-03 00:59:47 <warren> I give up for now.
82 2013-11-03 01:02:31 <dobry-den> What's the checklist for verifying a block? I imagine 1) Calculate difficulty, 2) Verify PoF, if valid, then 3) verify txns.
83 2013-11-03 01:02:41 <dobry-den> I remember seeing a checklist of the wiki a while back but can't find it
84 2013-11-03 01:13:30 <warren> figured out hte problem. the linearize.py output just doesn't work.
85 2013-11-03 01:13:38 <warren> when I cat together the blocks files it works
86 2013-11-03 01:44:15 <jgarzik> warren, sounds like your python is broken
87 2013-11-03 01:47:04 <warren> jgarzik: fedora 19?
88 2013-11-03 02:08:58 <HaltingState> +
89 2013-11-03 02:22:00 <jgarzik> warren, dunno, still on Ubuntu here. That's linearize.py on Ubuntu 13 generated the current bootstrap.dat torrent, which has been widely validated.
90 2013-11-03 02:30:57 <warren> petertodd: did you get a BIP number assigned?
91 2013-11-03 03:30:38 <petertodd> warren: nope
92 2013-11-03 04:28:32 <Evilmax> ;;blocks
93 2013-11-03 04:28:37 <gribble> 267623
94 2013-11-03 04:28:39 <Evilmax> ;;blocks
95 2013-11-03 04:28:41 <gribble> 267623
96 2013-11-03 05:33:58 <Polyatomic> Bitcoin-QT Question: Is there a rule of thumb I can follow regarding how often I should back up my wallet.dat
97 2013-11-03 05:38:07 <weex> every 10 transactions
98 2013-11-03 05:38:21 <weex> the client generates 100 addresses in advance
99 2013-11-03 06:00:28 <michagogo> cloud|Polyatomic: at least every $keypool address generations
100 2013-11-03 06:00:57 <michagogo> cloud|An address generation happens either when you ask for it, or when you create a transaction involving change.
101 2013-11-03 06:01:21 <michagogo> cloud|The keypool, by default, is 100 addresses, but that's configurable.
102 2013-11-03 06:02:53 <michagogo> cloud|(Bitcoin generates a certain number of addresses ahead of time, and when the software needs a new address, it takes the oldest one from this pool and generates a new one to add to the end
103 2013-11-03 06:04:11 <michagogo> cloud|, which means that as long as your backup is recent enough to include all the addresses you've pulled out of the keypool, you're good)
104 2013-11-03 06:08:28 <Polyatomic> cheers michagogo|cloud :what happens after 100 change addresses are generated. When on default.
105 2013-11-03 06:08:57 <michagogo> cloud|Any addresses, not just change addresses
106 2013-11-03 06:09:16 <michagogo> cloud|And at that point, your backups will be incomplete
107 2013-11-03 06:09:34 <michagogo> cloud|Because you will have been using addresses that aren't in the backup
108 2013-11-03 06:10:09 <michagogo> cloud|I suspect you'll find a good explanation at the following link: ,,(bc,wiki keypool)
109 2013-11-03 06:10:10 <gribble> https://en.bitcoin.it/wiki/Key_pool | Dec 12, 2012 ... New public and private keys are pre-generated and stored in a queue before use . This pooling feature was added so backups of the wallet ...
110 2013-11-03 06:10:31 <Polyatomic> thanks michagogo|cloud
111 2013-11-03 06:11:02 <michagogo> cloud|Np
112 2013-11-03 07:53:35 <Evilmax> ;;blocks
113 2013-11-03 07:53:36 <gribble> 267657
114 2013-11-03 11:08:56 <HaltingState> sipa, heheh https://github.com/haltingstate/telehash
115 2013-11-03 11:09:39 <HaltingState> this guy is going to be pissed at me; he wants to use RSA and i am like "No" and wants to use r curve and i think i will have first working implementation of his things because they are screwing with rsa in javascript/node etc
116 2013-11-03 11:11:42 <melvster> HaltingState: IMHO, RSA in general is superior to ECC, though ECC is certainly more compact
117 2013-11-03 11:12:15 <HaltingState> i think it should support both, but i am designing it to be secure even if ECC is broken
118 2013-11-03 11:12:38 <melvster> HaltingState: +1 best of all worlds
119 2013-11-03 11:12:55 <HaltingState> they could break an AES key on a packet and they still have to do preimage attack on SHA256 if they want to encrypt more than just that single packet
120 2013-11-03 11:13:28 <Eliel> you mean decrypt?
121 2013-11-03 11:13:39 <HaltingState> this thing will allow you to created shared/distributed entropy pools where you have hundreds of nodes that each have shared secrets with each other and it sort of insane
122 2013-11-03 11:13:44 <HaltingState> ya, decrypt
123 2013-11-03 11:14:17 <melvster> HaltingState: By the way im working on something similar ... a complete abstraction of bitcoin to the web, including the addressing system and adding data to that (already working)
124 2013-11-03 11:15:12 <HaltingState> so A introduces B to C and gives sha256 of nonce of shared secrete between A and C to B and then you use that for shared secret between B and C and even if C's private key is public, the communication betwen B and C is secure as long as they dont know shared secret between A and C, AND they cant do preimage attack on sha256
125 2013-11-03 11:15:24 <HaltingState> melvster, o0o0o0 gimme more info
126 2013-11-03 11:15:58 <HaltingState> i want telehash to use bitcoin addresses because we will have trust stuff soon and it can be used for anti sybil attack etc
127 2013-11-03 11:17:24 <melvster> HaltingState: starting with the model ive translated it to the semantic web so that any web page could describe a block (Ive not yet done transactions but hopefully this week) ... I have a basic web miner, and a client which is quite manual right now ... I've replaced the P2P network with an abstraction of bitcoind that is agnostic to the transport mechanism, so can work over P2P as per satsoshi's client, or HTTP via the web ... I'm right now putti
128 2013-11-03 11:17:24 <melvster> ng together user interfaces
129 2013-11-03 11:17:27 <Eliel> HaltingState: this thing you're working on looks rather promising from a quick look :)
130 2013-11-03 11:18:09 <melvster> ive also modeled bitcoin addresses than can be added to any web page using the semantic web, and via the web (or offline) you can tie arbitrary key value pairs to it
131 2013-11-03 11:19:07 <melvster> HaltingState: Some rough example is here: http://testcoin.org/.well-known/ni/sha-256/AAAAAAAAAAX--HN-FN6076EaoWrmBS5rXPc3WGOUuYY
132 2013-11-03 11:19:50 <melvster> I'm working half from satoshi's original concept, half from what has been implemented to date
133 2013-11-03 11:24:20 <melvster> PS I like your use of the term "mesh protocol" :)
134 2013-11-03 11:25:13 <sipa> melvster: what is the end goal?
135 2013-11-03 11:26:30 <melvster> sipa: I dont really have a goal, but it seems to me that the web is a great system because it has a huge audience, and bitcoin is a great system because -- well we all know why ... so the intersection is interesting to me ... perhaps it can be to bitcoin what hotmail was to email ...
136 2013-11-03 11:26:56 <melvster> main goal is to increase bitcoin adoption
137 2013-11-03 11:26:56 <sipa> that seems very vague
138 2013-11-03 11:27:14 <melvster> web stuff is often vague
139 2013-11-03 11:27:14 <sipa> and the web in general isn't very compatible with bitcoin's philosophy
140 2013-11-03 11:27:32 <sipa> as the web is very service-client, not peer to peer
141 2013-11-03 11:27:50 <melvster> sipa: what do you mean by compatible ... yeah the reason it's client server was not how it was intended to be
142 2013-11-03 11:27:51 <sipa> i.e., you'll always be needing to trust the data on a page
143 2013-11-03 11:28:06 <melvster> this is true
144 2013-11-03 11:28:18 <melvster> but people do this every day already
145 2013-11-03 11:28:46 <sipa> well that's like saying that b.i is a good thing because people already visit websites
146 2013-11-03 11:28:57 <melvster> b.i?
147 2013-11-03 11:29:05 <sipa> blockchain.info
148 2013-11-03 11:29:43 <melvster> yes, exactly ... people are used to working with the web ... you can get millions of users with a good system
149 2013-11-03 11:29:56 <melvster> this is very common on the web
150 2013-11-03 11:30:07 <melvster> in the sense that it's been done 1000s of times
151 2013-11-03 11:30:39 <sipa> the point is that bitcoin doesn't require trust in anyone... if people choose a centralized approach because it is more convenient, then we shoukd try to understand what to improve that the decentralized approach matches it
152 2013-11-03 11:31:20 <sipa> not say "but in the end, people will use the centralized system anyway" and just give up
153 2013-11-03 11:31:25 <melvster> sipa: the way the web is today may look centralized, and is to a large extent, but it's *design* was to be decentralized ... I'm trying to stay in line with the original design of the web ...
154 2013-11-03 11:31:45 <sipa> decentralized is an overloaded term
155 2013-11-03 11:32:07 <melvster> sipa: see http://www.w3.org/DesignIssues/Principles.html
156 2013-11-03 11:32:07 <sipa> i know the web was designed so that anyone could access any information put there by anyone
157 2013-11-03 11:32:18 <melvster> see the section on decentralization
158 2013-11-03 11:32:33 <melvster> also taken from brian carpenter's principles of internet architecture
159 2013-11-03 11:33:05 <sipa> yes yes, no single point of failure
160 2013-11-03 11:33:15 <melvster> that's the aim!
161 2013-11-03 11:33:29 <sipa> but that is still not the same as "not needing to trust anyone"
162 2013-11-03 11:33:45 <skinnkavaj> http://arstechnica.com/security/2013/10/meet-badbios-the-mysterious-mac-and-pc-malware-that-jumps-airgaps/
163 2013-11-03 11:34:21 <melvster> sipa: you always have to trust someone, the best we can do is to distribute that trust out
164 2013-11-03 11:34:56 <sipa> i disagree
165 2013-11-03 11:35:43 <melvster> consider this: traditional banking is a single point of failure, ripple has consensus among a small number of nodes, bitcoin distributes trust across many members of the network ...
166 2013-11-03 11:35:58 <sipa> bitcoin does not distribute trust
167 2013-11-03 11:36:17 <sipa> a bitcoin node simply doesn't accept anything invalid
168 2013-11-03 11:36:29 <sipa> every node validates everything
169 2013-11-03 11:37:29 <sipa> it relies on mining to find a consensus for one thing, where this zero-trust doean't apply: agreeing on a single version of history when there are competing ones
170 2013-11-03 11:37:49 <melvster> yes
171 2013-11-03 11:37:55 <sipa> and there certainly is a distribution of trust there
172 2013-11-03 11:37:59 <melvster> and it's always impossible to know the longest chain
173 2013-11-03 11:38:13 <melvster> the longest chain is just the longest chain you know of
174 2013-11-03 11:38:30 <sipa> the longest _valid_ chain you know
175 2013-11-03 11:38:37 <melvster> sorry yes
176 2013-11-03 11:38:49 <sipa> that's the point i'm making
177 2013-11-03 11:39:11 <sipa> it is not letting the network decide for you what is valid
178 2013-11-03 11:39:29 <sipa> you only use it as a tiebreaking to decide on conflicts
179 2013-11-03 11:41:07 <melvster> which is important!
180 2013-11-03 11:41:22 <melvster> because the whole ledger depends on it
181 2013-11-03 11:43:27 <sipa> yes, but it is very different from "i'm going to some website to see the true history"
182 2013-11-03 11:43:39 <sipa> even if it a website by someone you'd want to trust
183 2013-11-03 11:43:48 <melvster> true
184 2013-11-03 11:43:56 <melvster> that's why my system can be replicated over 1000s of websites
185 2013-11-03 11:44:10 <melvster> or millions
186 2013-11-03 11:45:28 <melvster> actually the semantic web isnt even dependent on the web
187 2013-11-03 11:45:28 <melvster> you can replicate it in a database or personal storage space
188 2013-11-03 11:50:54 <melvster> the main trusted third party in the web is DNS
189 2013-11-03 11:51:04 <melvster> so in that sense bitcoin's P2P protocol is superior
190 2013-11-03 11:51:46 <melvster> that's the trade off for having a large ecosystem
191 2013-11-03 11:52:52 <melvster> but im just working at the data level so that it can be agnostic to the data transport mechanism
192 2013-11-03 11:53:46 <melvster> sipa: I agree with you that the way the web works today mostly is quite centralized ... but I'm hoping to make it less so ... note: Tim Berners-Lee's group at MIT (who I do some work with) is called the "Decentralized" Information Group (DIG)