1 2014-03-16 00:00:31 <CheckDavid> The point of this would be to effectively have a brainwallet
2 2014-03-16 00:01:22 <copumpkin> well, just make sure you have a large enough search space :)
3 2014-03-16 00:02:14 <CheckDavid> copumpkin: is that to me?
4 2014-03-16 00:02:23 <copumpkin> yup
5 2014-03-16 00:02:29 <CheckDavid> Ohh
6 2014-03-16 00:02:35 <CheckDavid> I am not following
7 2014-03-16 00:02:46 <CheckDavid> What do you mean by search space @
8 2014-03-16 00:03:43 <copumpkin> if your key is an 8-character alphanumeric "password", I can trivially generate all of your keys and steal your stuff
9 2014-03-16 00:03:48 <shadders> Is there a library of invalid/valid but non-standard transactions anywhere? playing with a testing suite for tx verification but the blockchain isn't a good source of invalid txs.
10 2014-03-16 00:04:11 <copumpkin> if your key is 100 random characters long, that might be harder
11 2014-03-16 00:04:27 <copumpkin> if your key is a passage from a book, it's long but not as hard
12 2014-03-16 00:05:58 <sipa> jcorgan: yes, the second one overwrites the first one
13 2014-03-16 00:06:11 <jcorgan> thks
14 2014-03-16 00:06:17 <sipa> jcorgan: which is a problem if the first one wasn't entire spent, and the second gets reorganize away
15 2014-03-16 00:06:45 <jcorgan> it seems like a "don't do that" situation
16 2014-03-16 00:06:58 <jcorgan> but someone did :)
17 2014-03-16 00:07:51 <CheckDavid> copumpkin: so in one word is about entropy right?
18 2014-03-16 00:07:59 <copumpkin> yes
19 2014-03-16 00:08:27 <copumpkin> or some fundamental notion of complexity that entropy might not capture adequately
20 2014-03-16 00:08:28 <jcorgan> of course now it can't happen, right? (block height is part of the txid input)
21 2014-03-16 00:08:32 <CheckDavid> And it's also about knowing which hashing algorithms I am using
22 2014-03-16 00:08:43 <CheckDavid> Or even how i chain them
23 2014-03-16 00:09:30 <copumpkin> sure, it's just about a space to search. You can do all sorts of convoluted things that will make it hard for someone to guess, but I just wanted to point out that the scheme you described was trivial
24 2014-03-16 00:09:55 <jcorgan> wait, that can't be right (my last comment)
25 2014-03-16 00:10:03 <CheckDavid> Yes I know. It's very basic
26 2014-03-16 00:10:06 <copumpkin> you can also use a seeded random number generator and several other approaches
27 2014-03-16 00:10:13 <CheckDavid> But I gotta start somewhere
28 2014-03-16 00:10:33 <copumpkin> I just don't want you becoming the latest low-complexity brainwallet victim
29 2014-03-16 00:10:46 <CheckDavid> copumpkin: that's what sha256 is right?
30 2014-03-16 00:11:05 <CheckDavid> He he thanks
31 2014-03-16 00:11:17 <jcorgan> CheckDavid: private keys and passwords have two very different attack surfaces, don't confuse them
32 2014-03-16 00:11:27 <copumpkin> sha256 is what?
33 2014-03-16 00:11:54 <CheckDavid> jcorgan: how do you think I could be confusing them?
34 2014-03-16 00:12:04 <jcorgan> private keys should always be generated with a full 256 bits of entropy, like from os.urandom()
35 2014-03-16 00:12:22 <CheckDavid> copumpkin: seeded rng
36 2014-03-16 00:12:34 <copumpkin> CheckDavid: not really, although you could use it as one
37 2014-03-16 00:12:46 <CheckDavid> I see
38 2014-03-16 00:13:03 <copumpkin> anyway, I'm mostly with jcorgan here :)
39 2014-03-16 00:13:07 <jcorgan> because private keys sit out the block chain (after conversion to pubkey then address) where anyone can try to guess the private key
40 2014-03-16 00:13:10 <copumpkin> in case it wasn't obvious
41 2014-03-16 00:13:31 <jcorgan> at their leisure, with arbitrary amounts of compute power and time
42 2014-03-16 00:13:55 <jcorgan> if you want to have "passphrase" convenience, look at pbkdf2
43 2014-03-16 00:14:16 <copumpkin> but then the real key needs to live somewhere other than your brain, which is what CheckDavid wanted
44 2014-03-16 00:14:19 <CheckDavid> I am aware that one does not required the block chain for an attack of that sort
45 2014-03-16 00:14:53 <copumpkin> CheckDavid: I think a better approach to brainwallets than generating weak keys that someone can remember is to figure out clever mnemonics that allow humans to remember strong keys
46 2014-03-16 00:15:06 <copumpkin> if you absolutely must have a brainwallet :P
47 2014-03-16 00:15:47 <CheckDavid> copumpkin: wow... Someone told me exactly that on #bitcoin
48 2014-03-16 00:15:58 <CheckDavid> Do you have another nick?
49 2014-03-16 00:16:04 <copumpkin> no, I avoid that place like the plague
50 2014-03-16 00:16:06 <copumpkin> but it's not a new idea
51 2014-03-16 00:16:24 <copumpkin> "don't use weak keys" isn't controversial :)
52 2014-03-16 00:16:47 <CheckDavid> He worded it so similarly
53 2014-03-16 00:18:10 <CheckDavid> copumpkin: why do you assume they are weak keys?
54 2014-03-16 00:18:24 <copumpkin> you're giving them some structure
55 2014-03-16 00:18:38 <CheckDavid> True
56 2014-03-16 00:18:39 <copumpkin> chances are they'll be less random than 256 bits or you'd just memorize the original thing
57 2014-03-16 00:18:45 <jcorgan> the types of keys that humans can remember are precisely those that have structure that makes them less random
58 2014-03-16 00:19:04 <CheckDavid> But most probably would be the concatenation of several pieces of information
59 2014-03-16 00:19:45 <sipa> any key a human can come up with is massively weaker than a randomly generated one
60 2014-03-16 00:20:05 <sipa> just because humans are notoriously bad at guessing randomness
61 2014-03-16 00:20:53 <CheckDavid> sipa: the idea of generating my own entropy and keys is incredibly appealing to me
62 2014-03-16 00:21:06 <sipa> CheckDavid: then you probably shouldn't
63 2014-03-16 00:21:17 <CheckDavid> The fun thing about this, is how much of a coding noob I am
64 2014-03-16 00:21:20 <sipa> it's a very appealing idea, i know
65 2014-03-16 00:21:40 <jcorgan> CheckDavid: you may change your mind about that when you mysteriously find that your BTC has been spent
66 2014-03-16 00:21:49 <sipa> a computer-generated key and memorize that is fine
67 2014-03-16 00:22:06 <sipa> but generating yourself, except through a system like diceware
68 2014-03-16 00:22:11 <sipa> will massively limit the entro[y
69 2014-03-16 00:22:22 <CheckDavid> jcorgan: I can't possibly imagine any attack vector that would give any considerable chances of being stolen
70 2014-03-16 00:22:41 <jcorgan> guessing weak passphrases
71 2014-03-16 00:22:44 <sipa> note that you expose yourself the a perpetual global attack
72 2014-03-16 00:22:54 <sipa> as opposed to for example a login for a site
73 2014-03-16 00:23:00 <jcorgan> ^^
74 2014-03-16 00:23:05 <sipa> where the number of attempts per second that can be done is very low
75 2014-03-16 00:23:10 <CheckDavid> jcorgan: not just weak. They need to know my algorithms
76 2014-03-16 00:23:17 <sipa> CheckDavid: no they don't
77 2014-03-16 00:23:18 <jcorgan> assume they do
78 2014-03-16 00:23:43 <copumpkin> CheckDavid: your algorithms will be stored somewhere?
79 2014-03-16 00:23:47 <sipa> you essentially make your algoritm the private key
80 2014-03-16 00:24:11 <CheckDavid> sipa: what's the problem of a weak password. If they don't know my algorithms?
81 2014-03-16 00:24:19 <copumpkin> your algorithm is part of the key
82 2014-03-16 00:24:23 <sipa> CheckDavid: as i said, the algorihm becomes the key
83 2014-03-16 00:24:28 <copumpkin> either you store it somewhere, or you remember it
84 2014-03-16 00:24:33 <copumpkin> in which case it probably isn't very random
85 2014-03-16 00:24:39 <sipa> your security start to rely on become security through obscurity
86 2014-03-16 00:24:49 <sipa> their inability to not guess how your brain functions
87 2014-03-16 00:25:01 <sipa> let me tell you this: there aren't that many things humans come up with randomly
88 2014-03-16 00:25:04 <jcorgan> CheckDavid: there is a reason several people are all telling you the same thing
89 2014-03-16 00:25:16 <copumpkin> https://bitcointalk.org/index.php?topic=251037.0
90 2014-03-16 00:25:18 <CheckDavid> copumpkin: they may be public algorithms. And I may chain them in my own way
91 2014-03-16 00:25:29 <copumpkin> CheckDavid: your own chaining approach is part of the key, then
92 2014-03-16 00:25:31 <sipa> CheckDavid: and that chaining becomes your private key
93 2014-03-16 00:25:36 <CheckDavid> jcorgan: and there is a reason I am listening to you all :)
94 2014-03-16 00:25:54 <sipa> the problem is not that this mechanism is inherently bad for generating entropy
95 2014-03-16 00:26:00 <sipa> the problem is that you cannot measure it
96 2014-03-16 00:26:04 <copumpkin> CheckDavid: in theory, there are infinite ways to chain the algorithms and pick them, but in practice, you're a human and will pick simple ones that we can search
97 2014-03-16 00:26:17 <sipa> it is near impossible to guess how much mixing you need to add
98 2014-03-16 00:26:37 <sipa> and in the end, it is much easier to just have a computer generate 128 bits for you, turn it into a sentence, and memorize that
99 2014-03-16 00:26:41 <sipa> it's just a bunch of words
100 2014-03-16 00:26:57 <CheckDavid> Ah I see
101 2014-03-16 00:27:01 <sipa> and you have an entropy that is guaranteed to be as good as the cryptography further on provides
102 2014-03-16 00:27:10 <jcorgan> bip39 is a proposed standard for this
103 2014-03-16 00:27:25 <CheckDavid> But I can have phrases that are up to 100 characters
104 2014-03-16 00:27:35 <sipa> CheckDavid: so?
105 2014-03-16 00:27:41 <CheckDavid> Even though with some human structure
106 2014-03-16 00:28:02 <sipa> CheckDavid: i can say i can come up with sentences that are 1000 characters long, but all consist of repeating dictionary words
107 2014-03-16 00:28:06 <CheckDavid> It would have some computer generated entropy as part of it
108 2014-03-16 00:28:10 <sipa> the length doesn't matter
109 2014-03-16 00:28:15 <sipa> the way you generate it does
110 2014-03-16 00:28:16 <nsh> (the human brain is better at finding ways to remember unpredictable things than generating them)
111 2014-03-16 00:28:51 <CheckDavid> Interesting nsh
112 2014-03-16 00:29:03 <CheckDavid> But it's still bad at that
113 2014-03-16 00:29:05 <sipa> yeah, humans tend to see more patterns than there are
114 2014-03-16 00:29:27 <sipa> CheckDavid: if you're paranoid, let a computer generate a 128-bit entropy sentence, and add some stuff of your own
115 2014-03-16 00:30:16 <CheckDavid> So hard to memorize today :p
116 2014-03-16 00:30:20 <CheckDavid> *that
117 2014-03-16 00:30:26 <sipa> oh come on
118 2014-03-16 00:30:28 <jcorgan> you can encode 128-bits of entropy in 12 words chosen from a list of 2048 words.
119 2014-03-16 00:30:33 <sipa> people memorize entire plays
120 2014-03-16 00:30:49 <warren> [btc@perilous ~]$ bitcoind getdifficulty .... 1.00000000
121 2014-03-16 00:31:09 <warren> mining testnet for the past day at 200MH, mostly difficulty 1, zero blocks
122 2014-03-16 00:31:21 <CheckDavid> sipa: plays have lots of redundancy you can mess a bit
123 2014-03-16 00:31:24 <sipa> the number of digits of Pi that i know by heart is over 160 bits
124 2014-03-16 00:31:27 <cheetah2> how is it that the blockchain.info api is used?
125 2014-03-16 00:31:40 <cheetah2> it seems its a url
126 2014-03-16 00:31:49 <sipa> and that is in a very human-non-friendly format
127 2014-03-16 00:31:54 <cheetah2> how do i send it on php?
128 2014-03-16 00:31:55 <nsh> ACTION knows an infinite number of digits of pi -- they're just not consecutive
129 2014-03-16 00:32:09 <nsh> :)
130 2014-03-16 00:32:20 <CheckDavid> sipa: you are aware that even in a group of math nerds that is rare lil
131 2014-03-16 00:32:22 <jcorgan> if someone offered you $600 to memorize 12 words, would you take them up on that offer?
132 2014-03-16 00:32:52 <sipa> CheckDavid: yeah, i think humans shouldn't bother remembering keys at all, but use secure hardware for that
133 2014-03-16 00:33:04 <CheckDavid> jcorgan:maybe lol
134 2014-03-16 00:33:13 <sipa> CheckDavid: but if it appeals that much to you, i can only urge you to do it in a safe way (have at least 128 bits of entropy)
135 2014-03-16 00:33:31 <CheckDavid> Ok
136 2014-03-16 00:33:38 <jcorgan> CheckDavid: so, you agree then you could memorize 12 words
137 2014-03-16 00:33:40 <CheckDavid> I guess that's the way I will have to do it
138 2014-03-16 00:33:50 <CheckDavid> 128 bits of entropy
139 2014-03-16 00:33:54 <CheckDavid> So be it
140 2014-03-16 00:34:18 <sipa> (but please don't think that a list of 12 words that you choose will have 128 bits of entropy)
141 2014-03-16 00:34:32 <CheckDavid> Haha no sipa
142 2014-03-16 00:34:43 <sipa> :)
143 2014-03-16 00:34:54 <CheckDavid> But that is one I will have to think about
144 2014-03-16 00:35:48 <CheckDavid> What if I pick 12 random words out of a dict?
145 2014-03-16 00:35:52 <jcorgan> ;;google bip0039
146 2014-03-16 00:35:53 <gribble> BIP 0039 - Bitcoin: <https://en.bitcoin.it/wiki/BIP_0039>; Talk:BIP 0039 - Bitcoin: <https://en.bitcoin.it/wiki/Talk:BIP_0039>; SourceForge.net: Bitcoin:: <http://sourceforge.net/mailarchive/message.php?msg_id=31386959>
147 2014-03-16 00:36:09 <CheckDavid> I suppose it has more entropy than words from a 2048 words pool
148 2014-03-16 00:36:10 <sipa> CheckDavid: same thing
149 2014-03-16 00:36:16 <sipa> CheckDavid: you can't be the one who picks the words
150 2014-03-16 00:36:23 <cheetah2> how does one send a url on php?
151 2014-03-16 00:36:39 <CheckDavid> sipa: I pick (with a computer)
152 2014-03-16 00:37:26 <CheckDavid> :p
153 2014-03-16 00:37:36 <sipa> well, you pick, or the computer?
154 2014-03-16 00:37:37 <jcorgan> you have a list of 2048 words already chosen in advance. Then, generate 128 bits of random data with os.urandom(). Finally, encode those bits into 12 word list.
155 2014-03-16 00:41:47 <CheckDavid> sipa: I only operate the computer. The computer should do the picking
156 2014-03-16 00:42:05 <CheckDavid> jcorgan: yeah I got the idea
157 2014-03-16 00:42:09 <sipa> ok, then we're on the same page :)
158 2014-03-16 00:43:13 <CheckDavid> Such a dilemma this is :p
159 2014-03-16 00:44:34 <wbaw> if you pick 12 words from a dictionary randomly it should have 12^dict size combinations
160 2014-03-16 00:44:46 <wbaw> assuming the attacker knows the dictionary
161 2014-03-16 00:44:57 <CheckDavid> I ser
162 2014-03-16 00:45:14 <CheckDavid> I should use a Latin dictionary
163 2014-03-16 00:45:14 <CheckDavid> Lol
164 2014-03-16 00:45:15 <wbaw> so that could be quite a lot of bits of entropy
165 2014-03-16 00:45:46 <wbaw> you can assume the attacker knows the dictionary
166 2014-03-16 00:45:56 <CheckDavid> I see
167 2014-03-16 00:46:03 <wbaw> as it'd be hard to hide
168 2014-03-16 00:46:16 <dhill> fart into a microphone
169 2014-03-16 00:46:36 <CheckDavid> dhill: that is too predictable
170 2014-03-16 00:46:54 <CheckDavid> Some farts are too orderly
171 2014-03-16 00:46:54 <dhill> :P
172 2014-03-16 00:46:54 <jcorgan> as long as you stick to 128 bits of random data, the attacker can know the dictionary in advance, they still need to brute force all the combinations
173 2014-03-16 00:46:55 <wbaw> if you want to make it more memorable then you might need to apply some grammar rules, to get a random sentence
174 2014-03-16 00:47:15 <wbaw> that will cut down the number of combinations drastically though
175 2014-03-16 00:47:22 <jcorgan> wbaw then you'd need much more than 12 words
176 2014-03-16 00:47:26 <CheckDavid> wbaw: that's decreasing entropy
177 2014-03-16 00:47:31 <wbaw> to get 128bit?
178 2014-03-16 00:47:32 <berndj> in the end you still have to remember 128 bits
179 2014-03-16 00:47:56 <wbaw> there are a lot of words in english though
180 2014-03-16 00:47:59 <berndj> so either 12 random words, or a paragraph of not-so-random words
181 2014-03-16 00:48:40 <CheckDavid> I should write a rap song as s pass phrase
182 2014-03-16 00:48:41 <CheckDavid> Lol
183 2014-03-16 00:48:41 <jcorgan> you make it more memorable by choosing the most common nouns and adjectives in the language to form your group of 2048
184 2014-03-16 00:49:00 <wbaw> berndj, if your dictionary only has 11 words in it, that's true
185 2014-03-16 00:49:34 <jcorgan> the word list itself doesn't have to be "random" or unguessable
186 2014-03-16 00:49:43 <wbaw> just big
187 2014-03-16 00:50:12 <jcorgan> you just encode 11 bits by mapping it to one of 2048 words
188 2014-03-16 00:50:31 <berndj> small dict * many words, or large dict * few words both work, as long as size^N is large enough
189 2014-03-16 00:50:46 <jcorgan> correct. large dict though makes the memorization more difficult
190 2014-03-16 00:51:12 <wbaw> there's over 100,000 words in english
191 2014-03-16 00:51:23 <wbaw> in current use
192 2014-03-16 00:51:42 <CheckDavid> OK I will generate an address with a memorizable pass phrase
193 2014-03-16 00:51:54 <CheckDavid> Let's see of I can hack me :p
194 2014-03-16 00:51:57 <CheckDavid> Kidding
195 2014-03-16 00:52:10 <nsh> memorability will depend more on the size of an individual's usage vocabulary than the 'total' language corpus
196 2014-03-16 00:52:27 <jcorgan> ^^
197 2014-03-16 00:52:53 <berndj> which is probably a few thousand words, rather than anywhere near 100000
198 2014-03-16 00:52:57 <wbaw> http://news.bbc.co.uk/1/hi/magazine/8013859.stm
199 2014-03-16 00:53:02 <jcorgan> since the word list can be public, might as well choose from the most common words in the language
200 2014-03-16 00:53:23 <CheckDavid> Not sure if I am into that word memorization thing
201 2014-03-16 00:53:24 <wbaw> that says most normal uneducated english people know about 35,000 words
202 2014-03-16 00:53:47 <nsh> discussed a bit here: http://skeptics.stackexchange.com/questions/6010/are-there-20-000-english-words-in-the-average-adults-vocabulary
203 2014-03-16 00:53:53 <berndj> know != use regularly
204 2014-03-16 00:54:02 <jcorgan> and common words tend to be shorter too
205 2014-03-16 00:54:11 <nsh> there are methodological problems with assessing average vocab size due to dictionaries and colloquial usage being not-entirely-overlapping, etc.
206 2014-03-16 00:54:23 <wbaw> doesn't matter how long each word is
207 2014-03-16 00:54:37 <CheckDavid> Entropy is one unintuitive bitch
208 2014-03-16 00:54:49 <jcorgan> wbaw: i mean for storage purposes
209 2014-03-16 00:54:52 <jcorgan> not entropy
210 2014-03-16 00:55:04 <nsh> (well, it matters to the extent that the attacker can guess your dict contains smaller words with more confidence than longer words)
211 2014-03-16 00:55:15 <wbaw> storage would be in your brain, that's the idea of making it more memorable
212 2014-03-16 00:55:16 <jcorgan> nsh: the attacker is assumed to already know the dictionary
213 2014-03-16 00:55:19 <nsh> k
214 2014-03-16 00:56:44 <jcorgan> CheckDavid: human intuition and cryptography don't mix well
215 2014-03-16 00:57:04 <dhill> wait
216 2014-03-16 00:57:08 <dhill> oops
217 2014-03-16 00:57:53 <wbaw> i think it'd be possible, with software, to create sentences that are secure & easy to memorise
218 2014-03-16 00:57:56 <jrick> dhill: stay classy
219 2014-03-16 00:58:12 <jcorgan> wbaw: brain storage is good until you have a stroke; always good to record those 12 words somewhere :)
220 2014-03-16 00:58:21 <wbaw> maybe it'd need to be more than 12 words, but not much more with a large enough vocab
221 2014-03-16 00:59:01 <jcorgan> wbaw: so you'll be able to retrieve your bitcoin to pay for your stroke's medical care
222 2014-03-16 00:59:17 <CheckDavid> jcorgan: true
223 2014-03-16 00:59:24 <wbaw> that applies to any password though
224 2014-03-16 00:59:28 <jcorgan> it does
225 2014-03-16 01:00:24 <wbaw> smart cards or something like that might replace passwords in more places
226 2014-03-16 01:00:37 <wbaw> readers are cheap & easily available
227 2014-03-16 01:01:17 <CheckDavid> What if one stores his pass phrase in a public place?
228 2014-03-16 01:01:22 <CheckDavid> (Internet)
229 2014-03-16 01:01:40 <CheckDavid> Part of it
230 2014-03-16 01:02:32 <jcorgan> a smart card that would store an encrypted form of the HD wallet seed, encrypted with a key generated via PBKDF2, a data entry pad to bypass PC keyboard loggers, and the ability to sign transactions generated on a host PC, would be awesome
231 2014-03-16 01:03:04 <wbaw> passwords are a poor stop gap solution
232 2014-03-16 01:03:32 <wbaw> maybe biometrics will work one day
233 2014-03-16 01:03:48 <CheckDavid> jcorgan: wow
234 2014-03-16 01:03:58 <CheckDavid> Very paranoia
235 2014-03-16 01:04:03 <CheckDavid> Such crypto
236 2014-03-16 01:04:11 <CheckDavid> Many entropy
237 2014-03-16 01:04:15 <jcorgan> biometrics aren't revokable
238 2014-03-16 01:04:18 <CheckDavid> So security
239 2014-03-16 01:04:23 <wbaw> how do you bypass pc loggers then?
240 2014-03-16 01:04:27 <iwilcox> Have people been bitten heavily by rounding bugs in the past by representing Bitcoin amounts with their decimal points?
241 2014-03-16 01:04:50 <jcorgan> wbaw: you have a data entry pad directly on the smart card
242 2014-03-16 01:04:55 <berndj> jcorgan, yeah, whenever i see biometrics hailed as our saviour i wonder if i'm the only person alive who remembers the movie _Demolition Man_
243 2014-03-16 01:05:07 <jcorgan> lol
244 2014-03-16 01:05:31 <wbaw> it's still relying on a password then though
245 2014-03-16 01:05:33 <jcorgan> CheckDavid: let's take the rest of this conversation over to #bitcoin
246 2014-03-16 01:06:12 <wbaw> you would need to use multiple different biometrics & have them all be reliable for biometrics to work
247 2014-03-16 01:06:18 <wbaw> it's far from that now
248 2014-03-16 01:08:17 <wbaw> there are a lot of obvious problems still to be resolved with biometrics
249 2014-03-16 01:09:21 <wbaw> i'd be interested in a smartcard btc wallet if anybody wants to write an open source one
250 2014-03-16 01:12:28 <jcorgan> wbaw: such a set up would be relying on a passphrase for access and to keep the wallet seed secure in case it is lost, but would still produce key pairs with full entropy
251 2014-03-16 01:13:59 <wbaw> i wasn't suggesting using that word method for generating keypairs, just the password to encrypt the wallet with
252 2014-03-16 01:14:32 <warren> hmm, is the cpu minerd not a good choice for bitcoind testnet? (is it notified of new blocks?)
253 2014-03-16 01:14:36 <warren> mining for 24 hours and nothing
254 2014-03-16 01:16:49 <wbaw> it'd just be unnecessary overhead for generating a keypair & adding grammar rules to that would make it far too weak
255 2014-03-16 01:18:36 <wbaw> it could be useful to make wallet pass phrases more memorable & still secure though
256 2014-03-16 01:20:37 <jcorgan> wbaw: i think we're talking about different things at this point
257 2014-03-16 01:21:11 <jcorgan> anyway, i need to run, date night with wifey
258 2014-03-16 01:21:15 <wbaw> i think maybe i missed the start of the convo
259 2014-03-16 01:21:42 <wbaw> just wanted to clarify i wasn't suggesting using words for private keys, that'd be dumb
260 2014-03-16 01:23:29 <wbaw> so, yeah, i was probably talking about something slightly different when i joined in half way through
261 2014-03-16 01:57:46 <jerseykx> hi. is anyone here familiar with both bip32 and bip39 and would like to review my design for server-protected 2of2 wallet which can be trusted even in case of compromised server?
262 2014-03-16 01:58:38 <jerseykx> ('thin client' wallet)
263 2014-03-16 02:12:17 <airbreather> What's the heuristic that the mainline client uses for ignoring blocks on a fork that has no realistic chance of becoming the longest chain? Is it just the last hardcoded checkpoint, or is it "current minus n blocks"?
264 2014-03-16 02:12:41 <airbreather> Or some other fancy thing I didn't include in my guesses
265 2014-03-16 02:16:37 <sipa> airbreather: define 'ignoring'
266 2014-03-16 02:16:46 <DorothyIV> Is there an equivalent of a signing a blank cheque transaction?
267 2014-03-16 02:17:23 <sipa> DorothyIV: yes, but it is completely unsafe
268 2014-03-16 02:17:32 <sipa> as miners can rewrite where the money goes to
269 2014-03-16 02:17:43 <DorothyIV> Aka in the situation where I have a multi-sig address, I have 1 party sign that they don't care where the funds go, and the second party sign where they go
270 2014-03-16 02:18:00 <DorothyIV> sipa: well that's useless :P
271 2014-03-16 02:18:15 <sipa> if one of the signers signs the outputs it is safe
272 2014-03-16 02:18:50 <DorothyIV> sipa: but assume I don't have the outputs known when the 1st party signs
273 2014-03-16 02:19:18 <airbreather> sipa: I'm assuming that, for disk space purposes, the client doesn't store blocks whose prev-block-id is, for example, all the way back at the genesis block, since there's no chance that the creator is going to catch up
274 2014-03-16 02:20:29 <sipa> DorothyIV: i never realized this
275 2014-03-16 02:20:34 <sipa> DorothyIV: this is a very useful feature
276 2014-03-16 02:21:01 <airbreather> otherwise attackers could start broadcasting an effectively unlimited amount of time-traveling chains of diff-1 blocks
277 2014-03-16 02:21:41 <airbreather> which would be mostly invisible except a steadily increasing storage footprint
278 2014-03-16 02:21:58 <sipa> airbreather: once you pass a checkpoint, forks before it are not accepted anymore
279 2014-03-16 02:22:00 <DorothyIV> sipa: I'm asking if this is possible, not sure it is
280 2014-03-16 02:22:37 <sipa> DorothyIV: what's the purpose if the first party doesn't know the inputs and the outputs?
281 2014-03-16 02:23:13 <DorothyIV> sipa: to authorize the second party to have full control of the funds for the next transaction
282 2014-03-16 02:23:13 <sipa> you're better off not having them sign at all
283 2014-03-16 02:23:26 <DorothyIV> in the event of a multi-sig address situation
284 2014-03-16 02:23:26 <sipa> oh, that is possible
285 2014-03-16 02:23:27 <airbreather> there's SIGHASH_NONE for this, right?
286 2014-03-16 02:23:34 <sipa> sighash_node + anyonecansign
287 2014-03-16 02:24:24 <DorothyIV> I'll check it out, cheers
288 2014-03-16 02:25:06 <DorothyIV> I mean, alternatively I just sign it to send to an address that the second party owns
289 2014-03-16 02:29:08 <DorothyIV> thanks sipa
290 2014-03-16 02:32:44 <wbaw> what would be the advantage over just sending it to the second party?
291 2014-03-16 02:33:23 <Dcousens> wbaw: A good explanation can be found on the stackexchange: https://bitcoin.stackexchange.com/questions/4213/what-is-the-point-of-sighash-none
292 2014-03-16 02:35:23 <wbaw> ah, so a group of people could send to a co-ordinator
293 2014-03-16 02:36:12 <Dcousens> wbaw: well, send the raw transaction to a coordinator, who then signs it at the end with a SIGHASH_ALL
294 2014-03-16 02:36:12 <wbaw> and the transaction wouldn't go through unless all members of the group sent enough?
295 2014-03-16 02:36:33 <Dcousens> wbaw: that would be up to the coordinators discretion I assume
296 2014-03-16 02:36:51 <wbaw> makes more sense with multiple first parties involved
297 2014-03-16 02:37:55 <Dcousens> sipa: in this situation (as described in that stack exchange), do all the inputs need to be known? Or can you build up more and more inputs in this case as more people sign?
298 2014-03-16 02:38:09 <sipa> with anyonecansign, you don't need to know the inputs
299 2014-03-16 02:38:11 <airbreather> If I understand it correctly, inputs need to be known
300 2014-03-16 02:38:12 <airbreather> ?
301 2014-03-16 02:38:19 <sipa> with sighash_none, the outputs don't need to be known
302 2014-03-16 02:40:09 <Dcousens> sipa: true. The contracts wiki page seems to describe them quite well.
303 2014-03-16 02:41:33 <airbreather> interestingly, it seems that a transaction with all SIGHASH_NONE inputs is basically a blank check to the miner, but if any one of those inputs is SIGHASH_ALL, then the miner can't change anything without invalidating the whole transaction
304 2014-03-16 02:42:50 <airbreather> "to the miner" = it would wind up that way if this was actually happening frequently enough to justify special-casing
305 2014-03-16 02:44:22 <airbreather> yeah I should have read the stackexchange comment a bit more closely, because that's exactly what it says...
306 2014-03-16 02:49:11 <jgarzik> SIGHASH_ANYONECANPAY
307 2014-03-16 02:49:13 <jgarzik> love it :
308 2014-03-16 02:49:14 <jgarzik> :)
309 2014-03-16 03:03:13 <Luke-Jr> sipa: why does Google Chrome think Bitcoin is malware?
310 2014-03-16 03:04:05 <sipa> no clue
311 2014-03-16 03:13:55 <wbaw> are you sure it's chrome & not some av software?
312 2014-03-16 03:14:01 <Luke-Jr> yes
313 2014-03-16 03:14:07 <wbaw> is it the download or the website?
314 2014-03-16 03:14:10 <Luke-Jr> Google Webmaster Tools claims it too
315 2014-03-16 03:14:13 <Luke-Jr> wbaw: BFGMiner downloads
316 2014-03-16 03:16:52 <wbaw> it's either a false positive or a hacked/malicious website, know that's not very helpful
317 2014-03-16 03:18:25 <wbaw> some anti-virus software give false positives for mining software
318 2014-03-16 03:18:33 <Luke-Jr> wbaw: it's a false positive of course
319 2014-03-16 03:18:41 <Luke-Jr> because the people doing this stuff are incompetent
320 2014-03-16 03:19:10 <wbaw> and because people use mining software on hacked computers
321 2014-03-16 03:24:10 <wbaw> Luke-Jr, depending on the exact warning you got & where it could indicate a hacked website, but most likely a false positive due to incompetent av
322 2014-03-16 03:25:17 <Luke-Jr> wbaw: my website is where
323 2014-03-16 03:26:00 <wbaw> and the warning was when you tried to download the file, or on the download page?
324 2014-03-16 03:26:16 <Luke-Jr> I presume the file
325 2014-03-16 03:27:02 <wbaw> if it was a hacked site warning it'd most likely block whole pages, not just downloads
326 2014-03-16 03:28:09 <wbaw> was it somebody else who got this warning & reported it?
327 2014-03-16 03:28:47 <wbaw> they're probably running norton or something as bad
328 2014-03-16 03:29:27 <wbaw> actually, what does webmaster tools say?
329 2014-03-16 03:30:12 <wbaw> it's worth investigating if webmaster tools is warning you
330 2014-03-16 03:30:44 <wbaw> google isn't terrible for false positives
331 2014-03-16 03:32:14 <Luke-Jr> wbaw: they are now :/
332 2014-03-16 03:32:33 <wbaw> the only time i had a warning like that it was real
333 2014-03-16 03:33:09 <wbaw> although i don't host any coin mining software
334 2014-03-16 03:34:32 <wbaw> only needs one outdated script somewhere & before you know it your website is trying to silently infect visitors with malware
335 2014-03-16 03:38:11 <wbaw> google are usually pretty fast to detect it too
336 2014-03-16 03:39:22 <wbaw> was just a few hours for me
337 2014-03-16 03:41:29 <wbaw> wasnt actually my site, just one i was contracted to work on
338 2014-03-16 03:45:45 <venzen> Google is one of the heads of the Beast :)
339 2014-03-16 03:47:43 <venzen> Google Chrome is built on Chromium browser, but with all those personal info and web "services" added
340 2014-03-16 03:49:13 <venzen> so if anyone must do Chrome, try Chromium or you're going to smell the glove :D
341 2014-03-16 03:53:11 <antephialtic> anyone with experience running btcd?
342 2014-03-16 03:54:32 <dhill> me :)
343 2014-03-16 03:55:22 <jrick> yep
344 2014-03-16 03:55:27 <antephialtic> opinions?
345 2014-03-16 03:55:32 <dhill> we are biased
346 2014-03-16 03:57:17 <antephialtic> understandable. how do you test for compatibility with bitcoind?
347 2014-03-16 03:58:37 <wbaw> with all their spying they're pretty good at detecting malware though
348 2014-03-16 03:59:00 <dhill> antephialtic: unit testing and reading source code
349 2014-03-16 03:59:06 <wbaw> the massive amounts of data they collect is used for a few non-evil things, as well as the evil stuff
350 2014-03-16 04:00:04 <jrick> antephialtic: davec is the one to talk to wrt the really important stuff (consensus)
351 2014-03-16 04:14:11 <Dcousens> dhill: and pray tell how your experience with btcd was?
352 2014-03-16 04:15:14 <dhill> Dcousens: like I said, i am biased. it is the only full node software I run :)
353 2014-03-16 04:19:41 <Dcousens> dhill: I haven't read up much on it yet, how do you feel it compares to bitcoind (biased opinion or not)
354 2014-03-16 04:21:34 <dhill> well first, i can't run bitcoind on my system (openbsd), but that isn't bitcoind's fault. it is leveldb. the library assumes UBC kernel, which openbsd doesn't have, so the databases always corrupt. it would require patching leveldb.
355 2014-03-16 04:23:57 <dhill> but i believe it is on par with bitcoind. we have a few extra features. we currently have a few missing features.
356 2014-03-16 04:29:50 <Dcousens> dhill: how about memory requirements and performance compared to bitcoind?
357 2014-03-16 04:30:29 <dhill> btcd is currently using 172M on my machine
358 2014-03-16 04:32:06 <jrick> that testnet? my testnet btcd is at 172M as well
359 2014-03-16 04:32:13 <dhill> mainnet
360 2014-03-16 04:32:28 <Dcousens> dhill: that is imrpessive, considering I can never keep a bitcoind node under 700M haha
361 2014-03-16 04:32:51 <jrick> interesting, my mainnet (on windows) is at like 312M if task manager is to be believed
362 2014-03-16 04:33:14 <jrick> been running for a week or so
363 2014-03-16 04:33:33 <dhill> 16631 dhill -5 0 172M 158M sleep/1 biowait 15:01 7.37% btcd
364 2014-03-16 04:33:33 <dhill> 21730 dhill 28 0 43M 37M sleep/0 thrslee 0:09 0.00% btcd
365 2014-03-16 04:33:41 <jrick> dhill: is that btcd compiled with go 1.2 or tip?
366 2014-03-16 04:33:42 <dhill> top is mainnet, bottom is testnet
367 2014-03-16 04:33:45 <dhill> tip
368 2014-03-16 04:33:47 <jrick> ah ok
369 2014-03-16 04:33:50 <jrick> probably explains it
370 2014-03-16 04:34:09 <PRab> FYI, on my machine btcd = 346MB, bitcoin-qt = 210MB. Both mainnet
371 2014-03-16 04:34:52 <jcorgan> i have a bitcoind node with 100 connections, the resident set in RAM is about 400M
372 2014-03-16 05:05:54 <Dcousens> jcorgan: interesting, even if I run a leech node I can't get it that low in mem :P
373 2014-03-16 08:39:28 <melik> how do we determine transaction size?
374 2014-03-16 08:39:57 <michagogo> cloud|melik: by looking at how many bytes it is?
375 2014-03-16 08:40:14 <melik> michagogo|cloud, yes, but.
376 2014-03-16 08:41:13 <melik> actually, how do we do that? sorry.
377 2014-03-16 08:41:38 <michagogo> cloud|melik: uh, by taking the transaction and counting the bytes?
378 2014-03-16 08:41:41 <melik> getrawtransaction gives me an output of 517 bytes
379 2014-03-16 08:41:59 <melik> but blockchain.info and others claim tht its 252 bytes
380 2014-03-16 08:42:12 <michagogo> cloud|If you're looking at a transaction in hexadecimal, take the length and divide by 2
381 2014-03-16 08:42:16 <melik> for exmaple, txid: 6ec92d5a479609a0803678b41a71d9c4317730750a2abf3c9ff25ffeb5c28c2d
382 2014-03-16 08:42:20 <melik> ah divide by 2!
383 2014-03-16 08:42:24 <melik> that makes sense
384 2014-03-16 08:42:36 <melik> oh right it outputs in hex? so we have to divide by 2?
385 2014-03-16 08:42:40 <michagogo> cloud|Yes, 1 hex digit = 4 bits
386 2014-03-16 08:42:48 <melik> cool cool, merci!
387 2014-03-16 08:43:02 <melik> 517
388 2014-03-16 08:43:02 <melik> $ bitcoind getrawtransaction 6ec92d5a479609a0803678b41a71d9c4317730750a2abf3c9ff25ffeb5c28c2d | wc -c
389 2014-03-16 08:43:56 <michagogo> cloud|ACTION wonders where the extra 13 characters are coming from
390 2014-03-16 08:44:52 <gmaxwell> Something keeps spamming me with old blocks after there is a new one on the network: http://0bin.net/paste/juFEDommG-cRHnVw#N5MZbbdkqAMZJf23GnG37RVFo8dF4UAURqNfP49Q6Fo=
391 2014-03-16 08:45:04 <gmaxwell> BlueMatt: I'm connected to your relay thing, is it possible it's doing that?
392 2014-03-16 08:45:10 <melik> anyways, thanks michagogo|cloud; have a good day
393 2014-03-16 08:45:28 <michagogo> cloud|melik: np, you too
394 2014-03-16 08:46:49 <michagogo> cloud|Re: 5 hours ago
395 2014-03-16 08:47:42 <michagogo> cloud|I had Chrome warning me about the 0.9.0rc3 I built the other day because the file was "not commonly downloaded and could be dangerous"
396 2014-03-16 08:48:29 <michagogo> cloud|And then my security software went ahead and deleted it, detecting it as an "Insight.Reputation" or something
397 2014-03-16 08:48:52 <michagogo> cloud|...because nobody had ever seen it before...
398 2014-03-16 08:50:26 <michagogo> cloud|Luke-Jr: wait, did it think a *release* version of Bitcoin was malware, or a build of yours?
399 2014-03-16 08:51:37 <michagogo> cloud|4:41:40 <airbreather> interestingly, it seems that a transaction with all SIGHASH_NONE inputs is basically a blank check to the miner, but if any one of those inputs is SIGHASH_ALL, then the miner can't change anything without invalidating the whole transaction
400 2014-03-16 08:51:54 <michagogo> cloud|Except tbe miner can just remove the ALL-signed tx
401 2014-03-16 08:57:39 <michagogo> cloud|Er, ALL-signed input
402 2014-03-16 08:58:05 <michagogo> cloud|(And only if the other inputs are anyonecanpay, actually.)
403 2014-03-16 09:02:53 <michagogo> cloud|warren: re: testnet mining
404 2014-03-16 09:03:19 <michagogo> cloud|You said "mostly difficulty 1", but then pasted the output of getdifficulty
405 2014-03-16 09:03:51 <michagogo> cloud|Is your miner (if you're not just using the built-in one) also reporting diff 1?
406 2014-03-16 09:04:16 <michagogo> cloud|Guessing not, and getdifficulty returns the difficulty of the last block, not the current difficulty
407 2014-03-16 09:04:51 <michagogo> cloud|Meaning that on testnet, if it returns 1, you can't trust that because it may be the 20 minute rule
408 2014-03-16 09:05:26 <michagogo> cloud|(If a block is timestamped at least 20 minutes after the last one it can be diff 1)
409 2014-03-16 09:27:09 <michagogo> cloud|20:44:43 <jupiterfunk> Hello. In coinbase transaction, is total (combined) output value always total input value?
410 2014-03-16 09:27:12 <michagogo> cloud|Uh, what?
411 2014-03-16 09:27:24 <michagogo> cloud|By definition, a coinbase transaction has no inputs
412 2014-03-16 09:29:08 <wumpus> only virtual inputs based on the block reward and fees from transactions in the block, and a coinbase transaction can claim a lower reward than the block reward + fees (in which case the extra coins just disappear)
413 2014-03-16 10:12:04 <xdotcomm_> having issues with getrawtransaction and txindex ... after I did txindex = 1 ... I dont see senders address in "vout" addresses
414 2014-03-16 10:13:19 <Apocalyptic> this is not what txindex does, and there is no "sender" address
415 2014-03-16 10:14:19 <xdotcomm_> Apocalyptic: txindex provides info from spent/unspent transactions right?
416 2014-03-16 10:14:43 <xdotcomm_> Apocalyptic: by senders address I mean at least one of the addresses used to generate the transaction
417 2014-03-16 10:15:25 <Apocalyptic> txindex allows you to query for arbitraty txs with getrawtransaction, as opposed to txs related only to your wallet as it is without txindex
418 2014-03-16 10:15:51 <Apocalyptic> *arbitrary
419 2014-03-16 10:15:57 <xdotcomm_> Apocalyptic: in theory
420 2014-03-16 10:16:21 <xdotcomm_> Apocalyptic: because in practice I only used it when getrawtransaction did not work for one of my transactions
421 2014-03-16 10:16:33 <Apocalyptic> "addresses used to generate the transaction" I don't know what you mean by that
422 2014-03-16 10:16:34 <xdotcomm_> i was getting the -5 error
423 2014-03-16 10:16:58 <xdotcomm_> Apocalyptic: source addresses
424 2014-03-16 10:17:10 <Apocalyptic> there is no from address, source address or whatever you call it
425 2014-03-16 10:17:17 <Apocalyptic> see the topic
426 2014-03-16 10:17:56 <xdotcomm_> Apocalyptic: on block explorers you see which addressess the coins came from
427 2014-03-16 10:18:09 <Apocalyptic> sigh
428 2014-03-16 10:18:23 <nsh> transactions spent unspent outputs from previous transactions
429 2014-03-16 10:18:26 <nsh> *spend
430 2014-03-16 10:19:41 <xdotcomm_> Ok
431 2014-03-16 10:19:43 <xdotcomm_> http://dogechain.info/tx/aa2b44095694eee53e8e7f39490fce8d04d8b024e77ecaaa446e0beb601b7e1c
432 2014-03-16 10:19:59 <xdotcomm_> there is a FROM ADDRESS
433 2014-03-16 10:20:13 <xdotcomm_> Which are inputs
434 2014-03-16 10:20:43 <xdotcomm_> I want to extract those reliably from blockhain
435 2014-03-16 10:20:51 <jouke> a FROM ADDRESS ^_^
436 2014-03-16 10:20:54 <jouke> addresses are a lie
437 2014-03-16 10:20:58 <xdotcomm_> omg
438 2014-03-16 10:21:05 <Apocalyptic> seriously, referencing a dogecoin site in -dev
439 2014-03-16 10:21:10 <Apocalyptic> to prove a point
440 2014-03-16 10:21:17 <Apocalyptic> i think i've seen it all
441 2014-03-16 10:21:24 <jouke> xdotcomm_: learn about script
442 2014-03-16 10:21:24 <SomeoneWeird> altcoins are offtopic
443 2014-03-16 10:21:31 <nsh> please have this conversation somewhere else or not at all. it does not have to do with the development of bitcoin client source code.
444 2014-03-16 10:21:31 <xdotcomm_> I actually thought I was in dogecoin-dev
445 2014-03-16 10:21:37 <jouke> learn to understand how an address works
446 2014-03-16 10:21:40 <xdotcomm_> I apologize but its the same protocol
447 2014-03-16 10:21:57 <Apocalyptic> and again there is no FROM address, no matter what a random site tells/shows you
448 2014-03-16 10:22:33 <xdotcomm_> Blockchain sites are able to reliably extract originating addresses
449 2014-03-16 10:22:38 <xdotcomm_> thats what I want to do
450 2014-03-16 10:22:50 <jouke> >_<
451 2014-03-16 10:22:54 <jouke> learn to understand how an address works
452 2014-03-16 10:22:56 <jouke> xdotcomm_: learn about script
453 2014-03-16 10:23:10 <xdotcomm_> jouke: what script ?
454 2014-03-16 10:23:15 <xdotcomm_> PHP / javascript ...
455 2014-03-16 10:23:23 <jouke> https://en.bitcoin.it/wiki/Script
456 2014-03-16 10:23:36 <Apocalyptic> <xdotcomm_> thats what I want to do // just don't
457 2014-03-16 10:23:51 <Apocalyptic> it's just confusing everyone
458 2014-03-16 10:23:56 <xdotcomm_> Apocalyptic: yea ok
459 2014-03-16 10:24:03 <xdotcomm_> Its pretty simple
460 2014-03-16 10:24:08 <gmaxwell> xdotcomm_: transactions actually don't contain a from, what bc.i shows is a highly cooked view based on blockchain anylsis and it's sometimes misleading.
461 2014-03-16 10:24:28 <xdotcomm_> Transactions have inputs and outputs
462 2014-03-16 10:24:37 <xdotcomm_> inputs come from somewhere
463 2014-03-16 10:24:41 <gmaxwell> people trying to grok out 'from' addresses based on the history have been responsible for losing a fair amount of other people's money, thus the JUST DON'T responses.
464 2014-03-16 10:24:44 <xdotcomm_> they are not an illusion
465 2014-03-16 10:25:11 <jouke> they are not
466 2014-03-16 10:25:14 <jouke> but addresses are
467 2014-03-16 10:25:19 <gmaxwell> xdotcomm_: transactions spend specific coins. Those coins were previously sent to some specific scriptpubkey (which may not have an address), but that party may not be the From.
468 2014-03-16 10:25:41 <xdotcomm_> I get all that
469 2014-03-16 10:25:48 <Apocalyptic> you don't seem to really
470 2014-03-16 10:25:57 <xdotcomm_> I just want to log input addresses
471 2014-03-16 10:26:07 <xdotcomm_> I dont need a tour of reliability
472 2014-03-16 10:26:21 <gmaxwell> xdotcomm_: for example. If I buy a cake from amazon. Then leave it at your desk. And you had a magical wand of object origin that worked like the blockchain doesâ perhaps it would tell you that amazon sent you the cake, which isn't very useful if you want to know who to thank for it. :)
473 2014-03-16 10:26:22 <xdotcomm_> Its a straightforward question
474 2014-03-16 10:26:35 <gmaxwell> xdotcomm_: Sorry but we're not your paid support line.
475 2014-03-16 10:26:37 <xdotcomm_> blockchain sites do it reliably
476 2014-03-16 10:26:41 <Apocalyptic> they don't
477 2014-03-16 10:26:47 <Apocalyptic> that's just what you think
478 2014-03-16 10:26:47 <gmaxwell> It's actually _not_ reliable, and it's caused people to lose money.
479 2014-03-16 10:27:07 <xdotcomm_> gmaxwell: proof / links ?
480 2014-03-16 10:27:12 <venzen> xdotcomm_: jeez man, the corevs are telling you that the notion of 'from' addresses is mistaken, who will you belive?
481 2014-03-16 10:27:14 <jouke> xdotcomm_: please, learn how transactions work before viewing it to people
482 2014-03-16 10:28:04 <xdotcomm_> jouke: which part of script should I be looking at?
483 2014-03-16 10:28:22 <jouke> understand the notion of script and how transactions work
484 2014-03-16 10:28:50 <jouke> Than it is easy to do make a site like blockexplorer and blockchain.info
485 2014-03-16 10:29:25 <nsh> you could read this thread, and the threads linked from it: https://bitcointalk.org/index.php?topic=135379.0
486 2014-03-16 10:29:26 <gmaxwell> xdotcomm_: there are plenty of examples where using the prior to sent the funds to a no longer existing key or third party who wasn't the person making the payment, e.g. http://www.reddit.com/r/Bitcoin/comments/1pu8on/
487 2014-03-16 10:29:56 <xdotcomm_> gmaxwell: we are talking about blockchain info reliability
488 2014-03-16 10:30:12 <xdotcomm_> not sending funds to wrong person
489 2014-03-16 10:30:21 <xdotcomm_> I want info... I dont want to send anybody anything
490 2014-03-16 10:30:42 <xdotcomm_> point unproven
491 2014-03-16 10:30:55 <xdotcomm_> u gave me a coinbase link
492 2014-03-16 10:31:18 <xdotcomm_> Like I said I want to log them the same way blockchain does
493 2014-03-16 10:31:20 <gmaxwell> xdotcomm_: I'm pointing out that the data you extract there does not actually identify the sender of the funds, it's generic and not specific to bc.i.
494 2014-03-16 10:31:29 <xdotcomm_> I UNDERSTAND THAT
495 2014-03-16 10:31:39 <Apocalyptic> no caps
496 2014-03-16 10:31:52 <Apocalyptic> thanks
497 2014-03-16 10:31:55 <venzen> lol
498 2014-03-16 10:32:04 <gmaxwell> Sorry, no one should be treated like that. Thank you guys for trying to help him out.
499 2014-03-16 10:32:10 <nsh> ACTION nods
500 2014-03-16 10:32:24 <jouke> He has enough info to work it out himself by now.
501 2014-03-16 10:32:28 <gmaxwell> Hopefully he'll go cool off and either solve his own problems or realize that he doesn't get to yell at the volunteers here.
502 2014-03-16 10:32:35 <Apocalyptic> he seems to not be able to read
503 2014-03-16 10:32:35 <gmaxwell> Agreed.
504 2014-03-16 11:08:58 <xdotcomm_> getrawtransaction is not guaranteed to work on wallet transactions. It works on mempool transactions, and on blockchain transactions if txindex is enabled.
505 2014-03-16 11:53:02 <xdotcomm_> Topic says: No from address ... great then bitcoin is anonymous!
506 2014-03-16 11:54:03 <Apocalyptic> xdotcomm_, you're done trolling ?
507 2014-03-16 11:54:25 <xdotcomm_> I am ready to learn!
508 2014-03-16 11:56:25 <xdotcomm_> getrawtransaction -> vout -> scriptPubKey -> addresses used to have an "address" of interest in bitcoind 8.1
509 2014-03-16 11:56:48 <xdotcomm_> but then I ran areindex with txindex =1
510 2014-03-16 11:57:14 <xdotcomm_> and it vanished ... only showing 1 address which is the local address
511 2014-03-16 11:58:10 <gmaxwell> xdotcomm_: it never did, it can'tâ the transactions don't actually contain the data.
512 2014-03-16 11:58:49 <gmaxwell> the vouts have the data, but the vins don't.
513 2014-03-16 11:59:09 <gmaxwell> (also there isn't guarentted to be an addresses field for vouts either)
514 2014-03-16 12:00:05 <xdotcomm_> gmaxwell: what do you mean no guarantee ?
515 2014-03-16 12:00:20 <gmaxwell> e.g. getrawtransaction a60143eb3f8d3cd1f42cca874f35736186d67c488efd3c1b7214bbd74b310e0c 1
516 2014-03-16 12:00:44 <gmaxwell> no address field in the vout there. the transaction actually doesn't involve an address at all.
517 2014-03-16 12:00:51 <gmaxwell> (well on the output side)
518 2014-03-16 12:01:16 <xdotcomm_> is it because its a mined transaction or genises block?
519 2014-03-16 12:01:20 <gmaxwell> No.
520 2014-03-16 12:01:47 <xdotcomm_> its a fee transaction?
521 2014-03-16 12:02:00 <gmaxwell> there is no such thing as a "fee transaction"
522 2014-03-16 12:02:03 <gmaxwell> (and you can look at the spending side, 54fabd73f1d20c980a0686bf0035078e07f69c58437e4d586fb29aa0bee9814f ... what is the 'from address' there?)
523 2014-03-16 12:02:46 <gmaxwell> The bitcoin backend system really has no concept of address at all just script satisfaction. The scriptpubkey in that case is not representable as an address.
524 2014-03-16 12:03:55 <xdotcomm_> "Unable to decode input address"
525 2014-03-16 12:04:24 <gmaxwell> there isn't an 'input address' none is definable there.
526 2014-03-16 12:04:44 <xdotcomm_> dis is great
527 2014-03-16 12:04:54 <xdotcomm_> i can make anonymous bitcoin then?
528 2014-03-16 12:05:02 <gmaxwell> as I said before, bc.i doesn't relfect how bitcoin worksâ it presents a highly cooked (and offten useful) view of it based on detailed blockchain analysis and it can sometimes be misleading.
529 2014-03-16 12:06:01 <gmaxwell> you can still follow the flow of coins (although it's perfectly possible to obscure that too), addresses don't really come into anonymity limitations.
530 2014-03-16 12:07:18 <xdotcommer> sorry internet issue
531 2014-03-16 12:10:10 <xdotcommer> gmaxwell: I am fine with uncertainty the same way I am fine with fluctuating bitcoin prices ... I would still like to access additional transaction details when possible
532 2014-03-16 12:10:23 <tom78> hi anyone out there with the knowledge on identifying private key from hex cluster ?
533 2014-03-16 12:11:12 <tom78> hi anyone out there with the knowledge on identifying private key from hex cluster ?
534 2014-03-16 12:14:11 <tom78> hi anyone out there with the knowledge on identifying private key from hex cluster ?
535 2014-03-16 12:15:07 <gmaxwell> xdotcommer: then go fetch them, nothing has changed. The details you're looking for aren't actually in the transaction you're asking about, what bc.i is displaying is infered from inspecting the previous transactions whos outputs the transaction in question is spending.
536 2014-03-16 12:15:22 <gmaxwell> tom78: I don't know what you're asking but this is probably the wrong channel.
537 2014-03-16 12:16:17 <xdotcommer> gmaxwell: reason I am here is because there are public commits dealing with txindex / getrawtransaction and I wanted to understand how these work better
538 2014-03-16 12:18:37 <wumpus> tom78: there are some tools out there that can search disk images for private keys
539 2014-03-16 12:20:01 <tom78> wumps: i accidentally overwritten the wallet.dat and then preserved the hard drive and exploring it from another computer using hex editor to recover my lost wallet along coins. I found my overwritten keys in one sector. but unable to take further steps due to lack of information in how the private keys stored exactly.
540 2014-03-16 12:20:06 <xdotcommer> http://bitcoin.stackexchange.com/questions/3896/how-to-findout-the-sender-of-a-transaction
541 2014-03-16 12:20:09 <gmaxwell> He clarified the question to me in PM (I dunno how you were able to figure that out when I wasn't). I pointed him to https://bitcointalk.org/index.php?topic=25091.0
542 2014-03-16 12:21:17 <wumpus> gmaxwell: it was difficult to parse but I made a guess, some old words from the times of norton disk editor and put one and one together :)
543 2014-03-16 12:21:57 <gmaxwell> xdotcommer: except you already know the answer to that URL at leastâ you cannot. You 'find out' the sender of the transaction by knowing who you gave the address to. Nothing else measures the sender. (indeed you can measure other thingsâ like the previous to on the coins being spent, but these things are not always the sender)
544 2014-03-16 12:22:52 <wumpus> it's so long that I heard the word 'cluster' in any other context than 'clusterfuck'
545 2014-03-16 12:25:17 <gmaxwell> yea.. hah. whats next spinrite and
546 2014-03-16 12:26:37 <tom78> I am actually talking about hex editor. I have loaded my entire hard drive and found the data i need in one sector (in hexadecimal format) i found my overwritten public key and a pool of private keys. (in hexadecimal format) now i need to know how I can turn them into QT format
547 2014-03-16 12:26:44 <xdotcommer> gmaxwell: I am not trying to ascertain the real sender
548 2014-03-16 12:27:09 <xdotcommer> gmaxwell: I am trying to record addresses that were used in sending
549 2014-03-16 12:27:22 <tom78> https://en.bitcoin.it/wiki/Private_key
550 2014-03-16 12:28:12 <xdotcommer> gmaxwell: to the best result possible ...similar to blockchain websites
551 2014-03-16 12:29:43 <xdotcommer> problem with
552 2014-03-16 12:29:44 <xdotcommer> http://bitcoin.stackexchange.com/questions/2667/whats-the-best-way-for-a-website-to-detect-payments-from-green-addresses/5981#5981
553 2014-03-16 12:30:00 <xdotcommer> is that the pseudocode is completly wrong
554 2014-03-16 12:30:14 <xdotcommer> getrawtransaction does not accept txid
555 2014-03-16 12:30:32 <xdotcommer> sorry i mean decoderawtransaction does not accept txid
556 2014-03-16 12:38:16 <jouke> xdotcommer: use "getrawtransaction txid" and use that output with decoderawtransaction. Or even quicker "getrawtransaction txid 1".
557 2014-03-16 12:38:41 <gmaxwell> wumpus: if you go look at github issues that have had a lot of esp of the bikeshedy sort comments I think you'll find most are not wallet relatedâ perhaps just because there has been not much wallet activity. Not that I disagree with splitting it, as thats been a long term goal I think in everyone's mind.
558 2014-03-16 12:38:54 <jouke> You need a node with a full index. Yet, green addresses are stupid and nobody uses it.
559 2014-03-16 12:40:20 <xdotcommer> jouke: warren buffet said bitcoin is a mirrage :)
560 2014-03-16 12:42:11 <jouke> addresses are a mirage
561 2014-03-16 12:43:21 <xdotcommer> gotta think bigger for usage
562 2014-03-16 12:43:41 <xdotcommer> bitcoin is not a frige tech anylonger... its mainstream
563 2014-03-16 12:43:47 <xdotcommer> fringe*
564 2014-03-16 12:44:15 <xdotcommer> if only I can get a nice wallet on IOS
565 2014-03-16 13:04:21 <jouke> xdotcommer: I am thinking bigger, that is why we should move away from addresses. They are becomming obsolete anyway.
566 2014-03-16 13:04:57 <xdotcommer> jouke: I am intrigued can you help me understand
567 2014-03-16 13:05:26 <xdotcommer> is not it the whole point of public key cryptography
568 2014-03-16 13:07:26 <wumpus> gmaxwell: well most of the bikeshedding is wallet GUI related
569 2014-03-16 13:07:50 <olalonde> Hola
570 2014-03-16 13:09:31 <wumpus> gmaxwell: I really think seperating the wallet from the rest of the core project should be a priority, it would also allow for easier forking/experimentation of wallets
571 2014-03-16 13:09:40 <jouke> xdotcommer: have I allready told you about bitcoin script?
572 2014-03-16 13:09:52 <olalonde> wumpus: +1
573 2014-03-16 13:09:55 <xdotcommer> jouke: yea i perused
574 2014-03-16 13:11:30 <xdotcommer> jouke: ur thinking to use raw public key?
575 2014-03-16 13:11:33 <wumpus> gmaxwell: I agree with you that there is bikeshedding about core issues as well (like how many bytes of data to allow) but that kind of bikeshedding seems more relevant to me
576 2014-03-16 13:13:37 <gmaxwell> wumpus: I was thinking IsStandard rule stuff being a source of huge volumes of noise mostly.
577 2014-03-16 13:15:10 <wumpus> but we're stuck with that, it's part of the core functionality... it cannot be split off
578 2014-03-16 13:17:18 <jouke> xdotcommer: other ways to communicate scripts
579 2014-03-16 13:17:24 <jouke> Things like payment protocol
580 2014-03-16 13:21:57 <wumpus> gmaxwell: maybe introduce an embedded LUA interpreter for isStandard decisions :p
581 2014-03-16 13:22:18 <gmaxwell> ACTION cues luke
582 2014-03-16 13:22:23 <wumpus> and mining policy and such
583 2014-03-16 13:22:34 <gmaxwell> (who was recently saying things like "what if we embedded python for setting policy")
584 2014-03-16 13:22:41 <wumpus> ah yes it was his idea
585 2014-03-16 13:22:45 <wumpus> :D
586 2014-03-16 13:24:00 <HM2> too slow
587 2014-03-16 13:24:09 <HM2> you need to put a JIT in to the official client for Bitcoin script ;)
588 2014-03-16 13:24:17 <HM2> it'll be fine
589 2014-03-16 13:24:25 <wumpus> yes make it LLVM based
590 2014-03-16 13:25:16 <buZz> nice :)
591 2014-03-16 13:26:57 <HM2> wumpus, should make it secure though. best embed QEMU
592 2014-03-16 13:27:16 <olalonde> lawl
593 2014-03-16 13:27:40 <wumpus> it doesn't need to be secure, after all the operator would provide the code
594 2014-03-16 13:27:49 <olalonde> isn't it what ethereum is looking to accomplish?
595 2014-03-16 13:27:53 <gmaxwell> yea, lua would be fine and reasonable to embed.
596 2014-03-16 13:28:48 <wumpus> yep, at least lua has a JIT and is much smaller than python
597 2014-03-16 13:29:32 <gmaxwell> though the performace of createnewblock is already pretty bad without having interperted code in the loop. :(
598 2014-03-16 13:29:39 <HM2> i love lua on principle but also hate it for having 1 indexed arrays
599 2014-03-16 13:29:58 <HM2> which is hate on the intellectual level of pure racism
600 2014-03-16 13:31:00 <wumpus> HM2: it takes bikeshedding to a whole new level
601 2014-03-16 13:31:19 <wumpus> HM2: meta-bikeshedding
602 2014-03-16 13:31:28 <HM2> I know
603 2014-03-16 13:31:45 <gmaxwell> it could be intercal for all I care.
604 2014-03-16 13:31:55 <HM2> Also it kinda sucks that Lua 5.2 and LuaJIT are taking different roads
605 2014-03-16 13:35:22 <wumpus> HM2: always fun how you can do the same things in ever more different but pretty much equivalent ways, yay for progress :p
606 2014-03-16 13:52:37 <Luke-Jr> michagogo|cloud: a release version of BFGMiner, built by me.
607 2014-03-16 13:55:49 <gmaxwell> Great, electrum just posted a new release with "message encryption support" and the thing they linked to claimed to implement ECIES but doesn't, and instead implements something insecure.
608 2014-03-16 14:04:42 <HM2> wumpus, anything easy to do will be done and over again, anything difficult to do will be done once and people will complain about it forever
609 2014-03-16 14:12:50 <wumpus> HM2: yes, nice summary
610 2014-03-16 14:20:11 <michagogo> cloud|Luke-Jr: a new/very recent release?
611 2014-03-16 14:23:02 <michagogo> cloud|(In other words: a file that very few to no Chrome users would have already downloaded?)
612 2014-03-16 15:08:55 <AmThatsMe> Hi everyone ! I asked this question yesterday but i didn't fully got it yet. Why is RPC tests divided into python tests and cpp tests ?
613 2014-03-16 15:10:17 <wumpus> AmThatsMe: cpp tests are low level (unit tests), python tests are intermediate to high level (functionality tests)
614 2014-03-16 15:11:35 <AmThatsMe> wumpus: can the two be integrated ? is there any restrictions with writing everything in one language ?
615 2014-03-16 15:11:55 <wumpus> AmThatsMe: I wouldn't worry about that
616 2014-03-16 15:13:18 <wumpus> AmThatsMe: new tests are welcome in either python or c++, though if you need a test harness of some kind (for example to set up a blockchain and wallets) it makes no sense to do it in c++, and if you want to test a lot of isolated cases quickly it makes sense to use the internal c++ unit test framework
617 2014-03-16 15:14:09 <wumpus> the c++ tests are supposed to run quickly as they're run by the pulltester
618 2014-03-16 15:14:36 <sipa> the python tests are also ran by pulltester, i hope?
619 2014-03-16 15:14:58 <wumpus> I don't think all the qa tests are run by the pulltester
620 2014-03-16 15:15:09 <wumpus> not sure though
621 2014-03-16 15:15:10 <sipa> really?
622 2014-03-16 15:15:12 <wumpus> they take alot of time to run
623 2014-03-16 15:15:42 <sipa> just the comparison tools already takes minutes
624 2014-03-16 15:16:19 <sipa> but is run by pulltester
625 2014-03-16 15:16:59 <wumpus> I don't mind, I'm fine with adding everything to the pulltester, I'm just saying what I think is currently the case
626 2014-03-16 15:17:26 <sipa> sure
627 2014-03-16 15:17:56 <sipa> i'm just saying it would surprise me to not run some tests because of slowness, as the slowest test of all is already included
628 2014-03-16 15:19:13 <AmThatsMe> wumpus:thanks!
629 2014-03-16 15:19:23 <AmThatsMe> sipa:thanks also for your help yesterday !
630 2014-03-16 15:28:17 <hno> Anyone who knows some pool op contact of ghash.io? Our pools are fighting a bit too much on who has the current block.
631 2014-03-16 15:34:15 <sipa> ?
632 2014-03-16 15:34:31 <sipa> AmThatsMe: yw
633 2014-03-16 15:40:50 <paveljanik> hno: a bit too much?
634 2014-03-16 15:40:58 <paveljanik> can you be verbose?