1 2014-10-28 00:44:26 <Genitrust> gmaxwell: oh hey, i'll hit you up in this area instead... since this may be more of a dev chat :)
  2 2014-10-28 01:16:00 <michagogo> 11:43:45 <Luke-Jr> I would have thought it'd put them in the orphan pool
  3 2014-10-28 01:16:00 <michagogo> 11:43:54 <wumpus> no, orphans are network code only
  4 2014-10-28 01:16:00 <michagogo> 11:43:56 <sipa> Luke-Jr: and use 25 GB of ram?
  5 2014-10-28 01:16:17 <michagogo> Well, maybe could do something like the updated-for-headers-first linearize
  6 2014-10-28 01:16:47 <michagogo> If an orphan shows up while reindexing, keep its hash and position around in case it's referred to
  7 2014-10-28 01:23:30 <Luke-Jr> michagogo: not worth the effort probably
  8 2014-10-28 02:50:11 <sipa> michagogo: that's exactly what we do in master
  9 2014-10-28 02:50:24 <sipa> michagogo: the point is that 0.9 does not do this, so you can't downgrade your datadir, and then reindex
 10 2014-10-28 02:50:38 <sipa> Luke-Jr: ^
 11 2014-10-28 03:30:14 <Luke-Jr> sipa: I meant not worth the effort to do a backport of it to 0.9
 12 2014-10-28 03:30:44 <sipa> Luke-Jr: i assumed as much, but wasn't sure whether michagogo knew
 13 2014-10-28 03:52:40 <sipa> TIL: git diff -w
 14 2014-10-28 03:54:31 <Luke-Jr> yes, -w is useful :p
 15 2014-10-28 04:04:18 <joeykrug> why does bitcoin load the genesis block into memory and check it upon startup each time?  Is there any reason it couldn't just check blocks/index and check that the genesis hash is the key associated with the block at height 0?
 16 2014-10-28 04:05:15 <gmaxwell> Is there any reason it shouldn't? treating it more uniformly helpfully catches busted code / machines at start.
 17 2014-10-28 04:08:45 <joeykrug> I'm working on implementing Peter R's spinoff mechanism and it ends up using quite a bit of memory to load it each time.  I see no reason it shouldn't for reference bitcoin but was interested if there was any specific reason bitcoin-core loaded it that way each time.
 18 2014-10-28 04:09:49 <joeykrug> vs the way i described above, was wondering if there's some specific security reason that prohibits that from being a valid method
 19 2014-10-28 04:11:18 <gmaxwell> it's previously caught miscompilation/other issues and increases uniformity. Otherwise no.  Please don't ask any further altcoin questions in here.
 20 2014-10-28 04:12:09 <joeykrug> sorry, i didn't intend it as one, I framed my original question in the context as why bitcoin did it as I was genuinely curious, anyway thank you!
 21 2014-10-28 04:19:39 <kryo_> hey guys i have a serious question
 22 2014-10-28 04:20:08 <kryo_> we are aware of services like API keys to provide limited, revokable access to accounts
 23 2014-10-28 04:20:23 <kryo_> why don't we make API keys for your bitcoins?
 24 2014-10-28 04:21:14 <sipa> you can, if you have an API
 25 2014-10-28 04:21:37 <sipa> but if at the protocol level, that's not possible - it's not a service that protects you but access to cryptographic private keys
 26 2014-10-28 04:22:05 <sipa> which don't need trust in a service to enforce the correct access policy, but through a mechanism that the whole world can independently verify
 27 2014-10-28 04:24:04 <justanotheruser> I wonder if any clients can give you revokation tx that you can enter later
 28 2014-10-28 04:25:13 <SomeoneWeird> justanotheruser: wat
 29 2014-10-28 04:25:34 <joeykrug> why would you wanna do something like that anyway, what's a use case?
 30 2014-10-28 04:27:01 <sipa> if you'd revoke the key which has access to spend a particular coin... who would get the access instead? another key? that already exists: just the coins to that new key!
 31 2014-10-28 04:27:10 <sipa> *just send the coins
 32 2014-10-28 04:28:06 <kryo_> the original key has "master access" but can issue invoices etc.
 33 2014-10-28 04:28:26 <kryo_> which can then be invalidated.. etc
 34 2014-10-28 04:29:00 <sipa> i don't think you understand how bitcoin works
 35 2014-10-28 04:29:29 <justanotheruser> SomeoneWeird: wat
 36 2014-10-28 04:31:01 <justanotheruser> SomeoneWeird: you lose access to your keys, lost or stolen and you load up your paper wallet, scan a QR code and you revoke the keys and now your cold wallet key is the actual key
 37 2014-10-28 04:31:06 <justanotheruser> s/actual/used
 38 2014-10-28 04:31:31 <sipa> justanotheruser: yes, you can have a presigned transaction that sends your coins to a vault-protected-private-key address
 39 2014-10-28 04:31:44 <sipa> but you need to update the presigned transaction every time you touch your coins
 40 2014-10-28 04:31:56 <sipa> which makes it pretty impractical
 41 2014-10-28 04:32:00 <Luke-Jr> or use a 1-of-2 multisig maybe
 42 2014-10-28 04:32:20 <CodeShark> or just use 2-of-n to begin with :)
 43 2014-10-28 04:33:39 <justanotheruser> 1-of-2 means you have to dig up the 2nd key every time though
 44 2014-10-28 04:33:44 <CodeShark> no
 45 2014-10-28 04:33:48 <justanotheruser> wait
 46 2014-10-28 04:33:53 <joeykrug> the point is so you don't have to :)
 47 2014-10-28 04:33:54 <justanotheruser> I mean 2-of-2
 48 2014-10-28 04:34:25 <kryo_> what if i broadcasted to the network: "the string with the following hash can spend 3 of my bitcoins: <insert hash here>"
 49 2014-10-28 04:34:40 <justanotheruser> kyuupichan: what if you do?
 50 2014-10-28 04:34:46 <sipa> kryo_: #bitcoin please; you don't understand how the system works
 51 2014-10-28 04:34:54 <iwilcox> kryo_: Remind me what service you run?
 52 2014-10-28 04:35:32 <justanotheruser> 1-of-2 is almost certainly better because you make so many public key hashes
 53 2014-10-28 04:35:50 <justanotheruser> I was just thinking non-laterally and in the terms of an actual revokation key
 54 2014-10-28 04:35:52 <kryo_> if that message was taken as "official", i would be able to make "API keys" for my bitcoins
 55 2014-10-28 04:36:12 <justanotheruser> err wow
 56 2014-10-28 04:36:17 <justanotheruser> revokation address / message
 57 2014-10-28 04:36:19 <sipa> kryo_: that would be a ground-up redesign of bitcoin; please
 58 2014-10-28 04:36:26 <justanotheruser> err wow, I need to go to bed. s/address/tx
 59 2014-10-28 04:36:27 <kryo_> are you sure?
 60 2014-10-28 04:36:38 <joeykrug> kyro_ why not just send the bitcoin to a different address?
 61 2014-10-28 04:36:41 <sipa> please learn how such things would be technically possible first
 62 2014-10-28 04:36:43 <sipa> kryo_: yes
 63 2014-10-28 04:36:47 <joeykrug> then the new address could spend the bitcoin that were previously yours
 64 2014-10-28 04:36:55 <kryo_> because you can't revoke another address
 65 2014-10-28 04:37:06 <CodeShark> kryo_: the script you are suggesting sounds like a typical p2sh or p2ph transaction
 66 2014-10-28 04:37:08 <justanotheruser> kryo_: a revokation is a spending
 67 2014-10-28 04:37:17 <kryo_> you could then broadcast "the string with the hash <insert hash> can no longer spend any of my bitcoins"
 68 2014-10-28 04:37:19 <sipa> kryo_: because bitcoins are not stored at addresses; they're stored in coins
 69 2014-10-28 04:37:26 <Luke-Jr> kryo_: Bitcoin does not have accounts or addresses in the low-level; these are abstractions
 70 2014-10-28 04:37:33 <sipa> kryo_: addresses/scripts are just the access control mechanism on top
 71 2014-10-28 04:37:37 <kryo_> and if they're not already spent, they would be "revoked"
 72 2014-10-28 04:37:43 <sipa> kryo_: please take this elsewherew
 73 2014-10-28 04:38:14 <sipa> -w
 74 2014-10-28 04:38:19 <kryo_> ok i guess i need to learn the thing about addresses
 75 2014-10-28 04:38:38 <kryo_> but you can sign the message with your address...
 76 2014-10-28 04:38:55 <CodeShark> kryo_: the blockchain is like a huge array of locked glass cases - everyone can see what's inside each case - but you need a key to take anything out of any case. every bitcoin transaction simply opens some cases, removes the entirety of their contents, and sticks them into newly created cases
 77 2014-10-28 04:38:55 <justanotheruser> kryo_: that is wrong. #bitcoin
 78 2014-10-28 04:39:12 <CodeShark> that's ALL a bitcoin transaction can do
 79 2014-10-28 04:39:27 <CodeShark> (ignoring generation txs)
 80 2014-10-28 04:39:42 <justanotheruser> CodeShark: generation tx turn sand into glass
 81 2014-10-28 04:39:53 <justanotheruser> :P
 82 2014-10-28 04:40:05 <Luke-Jr> I think kryo_ wants to make a sidechain! <.< :P
 83 2014-10-28 04:40:06 <kryo_> i don't really see how that's relevant...
 84 2014-10-28 04:40:21 <justanotheruser> bitcoin real world analogies :D
 85 2014-10-28 04:40:23 <sipa> kryo_: it's incredibly relevant; addresses don't exist at the protocol level
 86 2014-10-28 04:41:03 <kryo_> well forget about the addresses
 87 2014-10-28 04:41:27 <CodeShark> an "address" is just a specific encoding for a standard script type that constitutes the lock on the glass case
 88 2014-10-28 04:41:37 <Luke-Jr> 
ACTION wonders if the "great ideas that are technically un-doable" fad will ever end

 89 2014-10-28 04:41:50 <kryo_> could you still not give access to some specific coins in your wallet?
 90 2014-10-28 04:41:57 <justanotheruser> Luke-Jr: It's been going on for a few centuries I assume
 91 2014-10-28 04:41:59 <Luke-Jr> CodeShark: meh, that's a stretch since unlocking the glass case has nothing to do with the address
 92 2014-10-28 04:42:01 <sipa> kryo_: yes, with a 1-of-2 multisig
 93 2014-10-28 04:42:11 <sipa> kryo_: but those coins change every time you use them
 94 2014-10-28 04:42:29 <CodeShark> Luke-Jr: I like to think in terms of challenge scripts and solution scripts
 95 2014-10-28 04:42:37 <CodeShark> an "address" is an encoding for a challenge script
 96 2014-10-28 04:42:46 <Luke-Jr> CodeShark: a scriptPubKey is a challenge script ;)
 97 2014-10-28 04:42:56 <CodeShark> yes :)
 98 2014-10-28 04:43:03 <CodeShark> but "challenge script" is a better name
 99 2014-10-28 04:43:13 <Luke-Jr> and the address is merely an abstraction for "a scriptPubKey within a transaction", which doesn't persist with the UTXO
100 2014-10-28 04:43:26 <CodeShark> scriptPubKey is a horrendously confusing and outdated name
101 2014-10-28 04:43:32 <Luke-Jr> "pubkey script" then
102 2014-10-28 04:43:38 <kryo_> perhaps these coins would need to remain unchanged
103 2014-10-28 04:43:51 <CodeShark> it needn't even have anything to do with a pubkey, in principle
104 2014-10-28 04:44:01 <kryo_> and you could issue a signed transaction to someone
105 2014-10-28 04:44:03 <sipa> CodeShark: why is it outdated?
106 2014-10-28 04:44:10 <justanotheruser> CodeShark: you are making the same assumption I made a few weeks ago.
107 2014-10-28 04:44:10 <kryo_> so they could spend the coins at any time...
108 2014-10-28 04:44:11 <sipa> CodeShark: it IS the public key of the Bitcoin Script cryptosystem
109 2014-10-28 04:44:19 <Luke-Jr> CodeShark: what sipa said
110 2014-10-28 04:44:22 <sipa> kryo_: you're again redesigning bitcoin from scratch
111 2014-10-28 04:44:29 <sipa> kryo_: please learn how the system works
112 2014-10-28 04:44:44 <iwilcox> Preferably before accepting anyone's money.
113 2014-10-28 04:45:03 <sipa> i'm sorry to yell at you; the idea is useful, and i'm sure you have good intentions, but it will take way too much time to explain things here
114 2014-10-28 04:45:08 <CodeShark> the public/private key thing is a way to construct a signature scheme - but it is not really what is fundamental about the scripts
115 2014-10-28 04:45:08 <kryo_> sipa i believe what i'm currently describing is entirely possible with the current system
116 2014-10-28 04:45:13 <justanotheruser> sipa: to me it sounds like he hasn't changed a thing at all. He is just rephrasing how the system currently works
117 2014-10-28 04:45:31 <kryo_> i'm just talking about having an un-broadcasted transaction
118 2014-10-28 04:45:31 <sipa> kryo_: well, i disagree
119 2014-10-28 04:45:37 <justanotheruser> except is a more abstract level
120 2014-10-28 04:45:43 <kryo_> exactly what you were saying like 5 minutes ago
121 2014-10-28 04:45:57 <sipa> CodeShark: bitcoin script is a digital signature system
122 2014-10-28 04:45:58 <Luke-Jr> justanotheruser: you can't code in abstract
123 2014-10-28 04:46:02 <kryo_> iwilcox: you don't need to understand bitcoin to run bitcoind :P
124 2014-10-28 04:46:03 <justanotheruser> Luke-Jr: I know
125 2014-10-28 04:46:22 <justanotheruser> Luke-Jr: but he is basically not proposing anything new, just a multisig timelock combination it sounds like
126 2014-10-28 04:46:24 <sipa> CodeShark: the wallet is the private key, the scriptPubKey is the public key, the scriptSig is the signature
127 2014-10-28 04:46:35 <sipa> (or rather, the keystore is the private key)
128 2014-10-28 04:47:01 <CodeShark> that doesn't really cover the general scripting case - where authorization could come from other factors besides providing a signature
129 2014-10-28 04:47:08 <CodeShark> not that bitcoin really supports anything too general
130 2014-10-28 04:47:14 <justanotheruser> "okay class, please provide the signature for the following public key: '1+1='"
131 2014-10-28 04:47:15 <CodeShark> but abstractly
132 2014-10-28 04:47:20 <kryo_> why isn't scriptPubKey just called "pub key"?
133 2014-10-28 04:47:41 <Luke-Jr> kryo_: because it's a variable of type "script" and we (were) using hungarian notation for variable names
134 2014-10-28 04:47:44 <CodeShark> the general scripting case is: "if condition X is met, allow Y"
135 2014-10-28 04:47:59 <Luke-Jr> CodeShark: the scriptSig *is* the signature
136 2014-10-28 04:48:00 <CodeShark> condition X could be "a valid signature is provided"
137 2014-10-28 04:48:01 <kryo_> oh god C
138 2014-10-28 04:48:05 <kryo_> 
ACTION shudders

139 2014-10-28 04:48:25 <Luke-Jr> CodeShark: "condition X" is the pub key
140 2014-10-28 04:48:34 <Luke-Jr> CodeShark: ignore ECDSA entirely
141 2014-10-28 04:48:36 <kryo_> just the convention of putting variable types in variable names...
142 2014-10-28 04:48:54 <CodeShark> ok, in abstract cryptographic terms you guys are right - but I don't think it's helpful to speak of it in these terms
143 2014-10-28 04:49:06 <CodeShark> for two reasons:
144 2014-10-28 04:49:12 <justanotheruser> If I hadn't asked the same question, DMMS wouldn't make any sense to me
145 2014-10-28 04:49:28 <CodeShark> 1) it's prone to be confused for lower-level signature schemes (i.e. ECDSA)
146 2014-10-28 04:49:35 <iwilcox> kryo_: Please take the whole line of enquiry to #litecoin or #litecoin-dev since this is about your litecoin site.
147 2014-10-28 04:49:43 <Luke-Jr> 
ACTION facepalms

148 2014-10-28 04:49:56 <CodeShark> 2) it's not the language in which most programmers think in
149 2014-10-28 04:50:14 <kryo_> it's not about my litecoin site iwilcox
150 2014-10-28 04:50:24 <kryo_> it's just something i thought of
151 2014-10-28 04:50:35 <Luke-Jr> CodeShark: I disagree with those reasons being sufficient to overcome the benefits
152 2014-10-28 04:50:40 <kryo_> plus #litecoin-dev has like 2 people in it
153 2014-10-28 04:50:41 <justanotheruser> CodeShark: programmers should be able to think in terms of why something works, not in terms of patterns in how words like "public key" have been defined before.
154 2014-10-28 04:50:55 <justanotheruser> s/defined/used
155 2014-10-28 04:51:33 <gmaxwell> CodeShark: failure to think of ScriptPubKey as _the_ pubkey being used (and such) has caused funds loss; it really is a signature cryptosystem all on its own (not too different from attribute based encryption)
156 2014-10-28 04:52:04 <CodeShark> how has it caused funds loss?
157 2014-10-28 04:52:53 <gmaxwell> CodeShark: e.g. people matching a hash160 in a scriptpubkey without observing the rest. :(
158 2014-10-28 04:53:01 <gmaxwell> (bc.i did this, among other things)
159 2014-10-28 04:53:19 <justanotheruser> the concept of DMMS' blew my mind. A PoW is actually a miners signature o_O
160 2014-10-28 04:54:03 <CodeShark> without observing the rest?
161 2014-10-28 04:54:39 <CodeShark> you mean you just searched for 20 consecutive bytes that match your hash160?
162 2014-10-28 04:54:52 <CodeShark> without checking what bytes came before or after?
163 2014-10-28 04:55:03 <gmaxwell> pretty much (at a particular position, without checking what came after)
164 2014-10-28 04:55:30 <CodeShark> I would argue that it is precisely *thinking of the scriptPubKey AS THE PUBKEY* is what caused your loss
165 2014-10-28 04:55:30 <iwilcox> Code is hard.  Let's just do it with grep, then go shopping.
166 2014-10-28 04:56:00 <gmaxwell> CodeShark: precisely not, no one sane would ever think you can go around matching some random bytes in the middle of a public key and do anything useful with it.
167 2014-10-28 04:56:53 <gmaxwell> in any case, it's really the design of the system... and script can (and likely, some day will) be used outside of bitcoin as a signature cryptosystem to great benefit.
168 2014-10-28 04:57:31 <CodeShark> the hash160 is NOT the pubkey, though - it's just a strange historical quirk that we decided to use this hash160 as a representative for an entire script…a move that only saves us a couple of bytes
169 2014-10-28 04:57:45 <CodeShark> rather than just using the script in its entirety
170 2014-10-28 04:58:00 <Luke-Jr> using the script in its entirety would be dangerous, at least with base58
171 2014-10-28 04:58:08 <CodeShark> why?
172 2014-10-28 04:58:19 <Luke-Jr> I'll just add a OP_TRUE at the end and it looks like the same address
173 2014-10-28 04:58:22 <gmaxwell> because you'd get VERY easy lookalikes that do something entirely different.
174 2014-10-28 04:58:52 <CodeShark> "addresses" aren't meant to be human-readable
175 2014-10-28 04:59:02 <Luke-Jr> …
176 2014-10-28 04:59:15 <CodeShark> you can also create lookalike SSH keys - but nobody ever complains about that because we never work with them in UIs
177 2014-10-28 04:59:19 <gmaxwell> They are, for better or worse. At least minimally so, and they're widely use that way in practice.
178 2014-10-28 04:59:24 <Luke-Jr> if you don't compare addresses at all, you will lose money :P
179 2014-10-28 04:59:38 <CodeShark> comparing addresses is something for my CPU to do, not me
180 2014-10-28 04:59:53 <Luke-Jr> CodeShark: so let's all use payment protocol, rather than addresses
181 2014-10-28 05:00:38 <joeykrug> i love the payment protocol, wish more mobile wallets supported it
182 2014-10-28 05:00:58 <Luke-Jr> I wish I could use it without jumping through hoops <.<
183 2014-10-28 05:01:40 <gmaxwell> CodeShark: its important to distinguish between ideal use, common use, and worst case use.  Ideal usage is great, but it's important that the worst case be as reasonably safe as possible... especially when the common use looks a lot like the worst case.
184 2014-10-28 05:02:15 <CodeShark> if you want to work around the "lookalike" issue, then we could explicitly encode the bytes before and after the hash160 in some manner other than base58 - and get rid of the version bytes while we're at it
185 2014-10-28 05:02:42 <Luke-Jr> …
186 2014-10-28 05:03:07 <justanotheruser> CodeShark: the beginning and end aren't the only place you can change the script
187 2014-10-28 05:03:24 <gmaxwell> Yea, better make sure whatever we've got is a suicide pact to never do anything differently or compatibly with a larger ecosystem. :)
188 2014-10-28 05:03:44 <gmaxwell> justanotheruser: sure, but doesn't matter, it could internally use a cryptographic permutation.
189 2014-10-28 05:03:55 <justanotheruser> that too
190 2014-10-28 05:04:56 <gmaxwell> CodeShark: in any case, for better or worse addresses are trying to be very small, at non-trivial expense.... if you abandon small there are much better things that can be done.
191 2014-10-28 05:05:11 <CodeShark> the "lookalike" thing sounds like a mitm…which the current scheme is not immune to anyhow (unless you use the payment protocol)
192 2014-10-28 05:06:50 <CodeShark> we've lost generality in our encoding for the sake of a couple of bytes and a (in my IMO) negligible reduction in mitm risk
193 2014-10-28 05:06:56 <justanotheruser> how is the system not vulnerable to MiTM? If someone is in the middle of you and a merchant (likely one that doesn't know to use ssl), they could serve you a wrong address
194 2014-10-28 05:07:17 <gmaxwell> CodeShark: kinda, but you get fun attacks like putting lookalines in places that list multiple addresses, or getting confused about which ones are in your copy buffers.
195 2014-10-28 05:07:18 <justanotheruser> you can pay someone you already have the pubkey of ofcourse
196 2014-10-28 05:07:48 <gmaxwell> CodeShark: the lookalike can be prevented without any compromises (perhaps beyond implementation complexity)
197 2014-10-28 05:08:20 <gmaxwell> and a couple bytes is material, if you don't care about size... payment protocol already explicitly can send seralized scriptPubKeys.
198 2014-10-28 05:09:01 <CodeShark> anyhow, my point earlier was that treating the hash160 AS the scriptPubKey is precisely the kind of confusion I was referring to
199 2014-10-28 05:09:07 <CodeShark> we're mixing two levels of abstracion
200 2014-10-28 05:09:15 <kryo_> hi friends, what's a hash160?
201 2014-10-28 05:09:27 <CodeShark> if the scriptPubKey is to be treated as a cryptographic pubkey, then we can only talk about it in this sense in its entirety
202 2014-10-28 05:09:50 <Luke-Jr> kryo_: this channel is for bitcoin development. participating in conversations therefore requires a bare minimum idea of how bitcoin works. you lack that, so please stick to #bitcoin for talking
203 2014-10-28 05:10:09 <kryo_> are you going to ban me?
204 2014-10-28 05:10:11 <kryo_> :(
205 2014-10-28 05:10:19 <justanotheruser> kryo_: I answered you
206 2014-10-28 05:10:31 <Luke-Jr> kryo_: if you're silent, probably you won't ever be banned here
207 2014-10-28 05:10:54 <kryo_> :P
208 2014-10-28 05:25:40 <kryo_> Luke-Jr: does having "a bare minimum idea of how bitcoin works" include memorizing every opcode in bitcoin Script?
209 2014-10-28 05:26:47 <kryo_> no offense but you guys seem very quick to judge my level of understanding
210 2014-10-28 05:27:48 <phantomcircuit> <kryo_> hi friends, what's a hash160?
211 2014-10-28 05:27:53 <phantomcircuit> uh huh
212 2014-10-28 05:29:02 <kryo_> that was a joke
213 2014-10-28 05:29:17 <kryo_> i'm refferring to earlier, specifically when i was talking to sipa
214 2014-10-28 05:29:45 <phantomcircuit> k
215 2014-10-28 05:29:51 <Luke-Jr> sarcasm does not translate well over IRC
216 2014-10-28 05:31:53 <justanotheruser> kryo_: if that was sarcasm you're trolling. You asked me what system HASH160 was for in #bitcoin
217 2014-10-28 05:34:30 <kryo_> like i said, it was a joke, but i was genuinely curious about what CodeShark was talking about
218 2014-10-28 05:35:22 <CodeShark> sarcasm only translates well if it's sufficiently sarcastic
219 2014-10-28 05:35:23 <CodeShark> :)
220 2014-10-28 05:35:37 <kryo_> i thought maybe if i called you guys my "friends" someone would get it
221 2014-10-28 05:35:38 <CodeShark> you should ask "what's a pubkey?"
222 2014-10-28 05:36:29 <phantomcircuit> your problem is, people actually ask questions like that all the time
223 2014-10-28 05:36:52 <kryo_> yeah it's a shame
224 2014-10-28 05:37:08 <iwilcox> No, it's fine.  On #bitcoin.
225 2014-10-28 05:38:00 <kryo_> interrupting discussion with a stupid question that could easily be answered with a google search is not fine on any channel
226 2014-10-28 05:38:12 <iwilcox> Really?  <kryo_>    hey guys what's the point of transaction fees?
227 2014-10-28 05:38:19 <kryo_> lol
228 2014-10-28 05:38:48 <kryo_> https://blockchain.info/block-index/485355/00000000000000000fa116bd0aeb52ccc2b7aa927e88999d37895490fc6a929c
229 2014-10-28 05:39:07 <kryo_> Block Reward: 25 BTC
230 2014-10-28 05:39:27 <kryo_> Fees: 0.00565652 BTC
231 2014-10-28 05:39:51 <kryo_> seems utterly pointless to me
232 2014-10-28 05:40:12 <phantomcircuit> kryo_, https://bitcoin.org/bitcoin.pdf
233 2014-10-28 05:40:18 <CodeShark> lol
234 2014-10-28 05:40:19 <kryo_> the block reward will halve
235 2014-10-28 05:40:24 <kryo_> which kinda makes up for it
236 2014-10-28 05:40:37 <phantomcircuit> either you haven't read that
237 2014-10-28 05:40:41 <phantomcircuit> or you need to read it again
238 2014-10-28 05:40:48 <kryo_> but 5 mBTC is not very much
239 2014-10-28 05:41:00 <kryo_> will the transaction fees ever be much more than 5 mBTC?
240 2014-10-28 05:41:20 <kryo_> no i haven't read the friggin bitcoin whitepaper
241 2014-10-28 05:41:20 <Luke-Jr> 
ACTION proposes we drop this conversation and let kryo_ save face by shutting up in here

242 2014-10-28 05:41:22 <kryo_> are you insane?
243 2014-10-28 05:41:36 <Luke-Jr> … too late I guess XD
244 2014-10-28 05:43:22 <phantomcircuit> kryo_, it's in basically plain english
245 2014-10-28 05:43:55 <kryo_> yeah tbh it doesn't look too bad
246 2014-10-28 05:43:59 <kryo_> maybe some day
247 2014-10-28 05:46:32 <CodeShark> consider doing so as a prerequisite for this channel
248 2014-10-28 05:47:18 <kryo_> #bitcoin-dev: Total of 475 nicks
249 2014-10-28 05:47:19 <kryo_> ok
250 2014-10-28 05:47:28 <kryo_> you got it m8
251 2014-10-28 05:49:27 <gmaxwell> s/for this channel/for talking in this channel/
252 2014-10-28 05:49:29 <Luke-Jr> 475 people *watching*
253 2014-10-28 05:49:47 <kryo_> lol...
254 2014-10-28 05:50:14 <kryo_> ok well from now on i will participate only in discussions which i feel i can contribute something to
255 2014-10-28 05:50:36 <kryo_> sorry you're all so offended by me
256 2014-10-28 05:52:00 <CodeShark> I don't think anyone is really offended. however, it is HIGHLY encouraged that you do as much of your own research as you can before coming into this channel and asking questions
257 2014-10-28 05:53:54 <CodeShark> it's fine to ask where you can find materials - but don't expect anyone here to give you a bitcoin 101 course
258 2014-10-28 05:57:34 <kryo_> i don't expect that
259 2014-10-28 05:57:35 <kryo_> at all
260 2014-10-28 05:59:31 <CodeShark> is wumpus here yet?
261 2014-10-28 06:33:29 <wumpus> CodeShark: yes
262 2014-10-28 06:33:37 <CodeShark> hey wumpus :)
263 2014-10-28 06:33:45 <CodeShark> I completely missed the rpcdump stuff - sorry :)
264 2014-10-28 06:34:03 <CodeShark> the function table doesn't break down the wallet functions by file
265 2014-10-28 06:34:54 <CodeShark> a strange thing happened, though - apparently PAIRTYPE was undefined in the no wallet build after I made these changes - which is strange considering I didn't change any of that
266 2014-10-28 06:35:07 <CodeShark> but the issue went away when I included utilstrencodings.h
267 2014-10-28 06:35:08 <wumpus> well I was positively surprised you had almost all of them correct :)
268 2014-10-28 06:36:36 <CodeShark> did something change in the travis ci build environment? or am I missing something?
269 2014-10-28 06:36:39 <wumpus> and indeed they're not sorted by file, on purpose - the distribution of the functions over files could be changed at some point to match the new groupings, this could also save an #ifdef wallet or two
270 2014-10-28 06:38:00 <wumpus> no, nothing changed in travis AFAIK
271 2014-10-28 06:38:58 <CodeShark> strange...
272 2014-10-28 06:39:08 <CodeShark> it builds now - but I had to add an extra include I didn't have before
273 2014-10-28 06:40:26 <CodeShark> I'd like to start working on the method registration mechanism
274 2014-10-28 06:41:26 <Luke-Jr> wumpus: should I get rid of the RPC error code response aliases entirely, commentify them, or leave them?
275 2014-10-28 06:42:59 <CodeShark> seems like the sensible approach is to turn CRPCCommand into a callable base class with a virtual () method and pull the mapCommands out of CRPCTable and make it a singleton
276 2014-10-28 06:43:00 <wumpus> Luke-Jr: I was fine with adding them
277 2014-10-28 06:43:34 <wumpus> Luke-Jr: people use that file as reference for what the codes are called, so if that suddenly changes, that may be strange, so do add at least a comment
278 2014-10-28 06:43:54 <wumpus> (people need to update their python, java, etc bindings)
279 2014-10-28 06:44:01 <CodeShark> or perhaps the CRPCTable class can take care of the lookup and throw exceptions if the method isn't found
280 2014-10-28 06:44:08 <Luke-Jr> wumpus: right now, they're renamed with an alias and a comment stating the aliases are "for backward compatibility"
281 2014-10-28 06:44:53 <wumpus> Luke-Jr: right, that's a way of documenting it, that's why i didn't comment on it, but I'll reply to the issue...
282 2014-10-28 06:45:06 <CodeShark> wumpus: I would also propose foregoing the typedef json_spirit::Value(*rpcfn_type)(const json_spirit::Array& params, bool fHelp); style in favor of either boost::function or std::function
283 2014-10-28 06:50:21 <CodeShark> I think I'll keep the CRPCCommand and CRPCTable classes but get rid of the hardcoded table and replace it with explicit method registration calls as a first step
284 2014-10-28 06:50:55 <Luke-Jr> why not have CRPCCommand::CRPCCommand add itself to the table?
285 2014-10-28 06:51:11 <wumpus> CodeShark: good idea
286 2014-10-28 06:52:30 <wumpus> Luke-Jr: that sounds too magical
287 2014-10-28 06:52:43 <CodeShark> Luke-Jr: registration is the responsibility of the RPC server class (which doesn't exist yet)
288 2014-10-28 06:52:51 <Luke-Jr> wumpus: I do that magic in C too :p
289 2014-10-28 06:53:06 <CodeShark> for now we have a defacto RPC server singleton object
290 2014-10-28 06:53:11 <wumpus> Luke-Jr: then, people look at the source and wonder *wtf how does this work in the first place* :)
291 2014-10-28 06:53:15 <CodeShark> heh
292 2014-10-28 06:53:27 <phantomcircuit> wumpus, bitcoin is magical though why not use magic?
293 2014-10-28 06:53:29 <Luke-Jr> wumpus: nah, registration is pretty obvious like that IMO
294 2014-10-28 06:53:30 <phantomcircuit> 
ACTION runs

295 2014-10-28 06:54:08 <CodeShark> the defacto RPC server singleton object has an interface enclosed in a namespace - but eventually the idea is to create an RPC server class, allowing an application to instantiate instances at will
296 2014-10-28 06:54:22 <CodeShark> instantiate instances - lol
297 2014-10-28 06:54:31 <Luke-Jr> it'd be nice to eliminate merge conflicts resulting from simply adding new methods
298 2014-10-28 06:55:31 <CodeShark> CRPCCommand instances should be subclasses that overload precall checking methods and operator()
299 2014-10-28 06:56:09 <CodeShark> but that will be the next stage
300 2014-10-28 08:32:28 <Luke-Jr> 5106 good to go now? :p
301 2014-10-28 08:54:09 <adlai> "Error: Cannot obtain a lock on data directory /home/adlai/.bitcoin. Bitcoin Core is probably already running." it actually had an unclean shutdown, what should I purge to get it running again?
302 2014-10-28 08:54:32 <phantomcircuit> adlai, are you *sure* it's not still running
303 2014-10-28 08:55:14 <adlai> well this is weird, tmux killed the pane but evidently the process lives on.
304 2014-10-28 08:55:31 <phantomcircuit> yup
305 2014-10-28 08:55:36 <adlai> thanks >_<
306 2014-10-28 08:58:27 <adlai> "Do you want to rebuild the block database now?" but then exits without waiting for any response, will a -reindex fix this?
307 2014-10-28 08:58:36 <sipa> yes
308 2014-10-28 09:02:31 <wumpus> well this is weird, tmux killed the pane but evidently the process lives on. <- yes, it tries to do a clean shutdown if it gets a SIGINT or SIGTERM so it lingers around for a while
309 2014-10-28 09:26:12 <CodeShark> wumpus: this is a start - https://github.com/CodeShark/bitcoin/tree/RPC_command_registration
310 2014-10-28 09:27:15 <CodeShark> more specifically: https://github.com/CodeShark/bitcoin/commit/4280cc42a6a55603422d58d18c85d1f91d79bc7d
311 2014-10-28 12:40:45 <michagogo> sipa, Luke-Jr: um, right, sorry. It was 3 AM at the time... :P
312 2014-10-28 12:45:41 <Luke-Jr> michagogo: what? you mean you're not most aware around 3 AM? :P
313 2014-10-28 12:52:39 <sipa> he's most awake around 3 AM EST
314 2014-10-28 12:52:44 <sipa> wait, that's now
315 2014-10-28 13:01:15 <Luke-Jr> sipa: no, it's 9 AM EDT now
316 2014-10-28 13:04:45 <fanquake> I thought it was 9PM..
317 2014-10-28 13:14:30 <ben_vulpes> what is CreateDataDir in this context: https://github.com/bitcoin/bitcoin/blob/master/qa/rpc-tests/conflictedbalance.sh#L40 ?
318 2014-10-28 13:17:16 <ben_vulpes> ah that's gotta be the python bitcoinrpc lib
319 2014-10-28 13:18:03 <ben_vulpes> maybe?
320 2014-10-28 13:18:05 <ben_vulpes> 
ACTION is confused

321 2014-10-28 13:36:39 <wumpus> ben_vulpes: that function comes from util.sh
322 2014-10-28 13:38:20 <ben_vulpes> wumpus: why so it does.
323 2014-10-28 13:38:46 <wumpus> ?
324 2014-10-28 13:38:55 <ben_vulpes> i'm just agreeing.
325 2014-10-28 13:39:09 <wumpus> ok! :)
326 2014-10-28 13:39:33 <ben_vulpes> how does conflictedbalance.sh know of that function in the other file, though?
327 2014-10-28 13:54:04 <elichai2>  /j #oneplus
328 2014-10-28 13:54:06 <elichai2> ops
329 2014-10-28 13:58:59 <wumpus> ben_vulpes: it includes the file
330 2014-10-28 14:13:37 <ben_vulpes> i cannot believe that i missed that. up too early, apparently.
331 2014-10-28 14:13:47 <ben_vulpes> thanks, wumpus.
332 2014-10-28 15:02:51 <elichai2> x
333 2014-10-28 15:04:19 <NikolaiToryzin> y
334 2014-10-28 15:08:18 <ben_vulpes> z
335 2014-10-28 15:28:51 <wumpus> w
336 2014-10-28 15:41:09 <sipa> s
337 2014-10-28 15:57:48 <gavinandresen> k (because eleven)
338 2014-10-28 15:58:19 <sipa> q (because 0x11)
339 2014-10-28 15:58:39 <gavinandresen> I only hex on halloween
340 2014-10-28 15:59:17 <sipa> you know that 'witch' in dutch is 'heks' (pronounced 'hex') ?
341 2014-10-28 15:59:19 <gavinandresen> sipa: re: https://github.com/bitcoin/bitcoin/issues/5138  headers first never gets going bug:
342 2014-10-28 15:59:25 <sipa> gavinandresen: yes, i know, will fix
343 2014-10-28 15:59:32 <gavinandresen> cool
344 2014-10-28 15:59:33 <sipa> gavinandresen: fighting jetlag atm
345 2014-10-28 15:59:53 <gavinandresen> no worries, I’d be happy to fix if you tell me what you’re thinking, I’ve got a good test case
346 2014-10-28 16:00:19 <sipa> gavinandresen: the "don't fetch from incoming peers" logic should be disabled if there are only incoming peers
347 2014-10-28 16:05:28 <gavinandresen> sipa: mmm, I looked at implementing that, it looked messy (e.g. main.cpp loops through vNodes after locking cs_vnodes? )
348 2014-10-28 16:06:13 <sipa> gavinandresen: main should just keep its own independent counter (incremented/decremented in InitializeNode/FinalizeNode
349 2014-10-28 16:06:43 <sipa> which can also correctly ignore non-NODE_SERVICE nodes etc
350 2014-10-28 16:07:13 <sipa> or fOneShot ones
351 2014-10-28 16:25:09 <sipa> gavinandresen: whipping up a patch
352 2014-10-28 16:25:45 <gavinandresen> sipa: spiffy keen, thanks
353 2014-10-28 16:34:47 <sipa> gavinandresen: #5157, untested
354 2014-10-28 16:35:34 <gavinandresen> sipa: I’ll exercise it after lunch
355 2014-10-28 16:44:07 <brocktice> Is there a dedicated trezor channel? I have a question about BIP-0032
356 2014-10-28 16:44:24 <sipa> i know nothing about trezors, but i wrote bip 32
357 2014-10-28 16:44:54 <brocktice> mytrezor.com generates a seed when you set up the device
358 2014-10-28 16:44:55 <brocktice> made of random words
359 2014-10-28 16:45:04 <sipa> that sounds like bip 39
360 2014-10-28 16:45:13 <brocktice> hm ok let me look
361 2014-10-28 16:46:34 <brocktice> ahhhh yes OK
362 2014-10-28 16:46:40 <brocktice> this is everything I need
363 2014-10-28 16:46:49 <brocktice> thanks!
364 2014-10-28 17:29:24 <rubensayshi> sipa, just to make sure, there's no way to get bitcoind to not use headers-first right?
365 2014-10-28 17:34:47 <Luke-Jr> rubensayshi: you mean like using 0.9?
366 2014-10-28 17:35:06 <rubensayshi> Luke-Jr, for now that does the trick yea :P
367 2014-10-28 17:35:45 <rubensayshi> but I'd like to upgrade when it's actually released
368 2014-10-28 17:38:43 <gmaxwell> rubensayshi: what are you trying to accomplish?
369 2014-10-28 17:39:37 <rubensayshi> gmaxwell, there are some projects that use the raw data files to index the blockchain (insight-api and couterpartyd that I know of)
370 2014-10-28 17:39:49 <rubensayshi> they break when the blocks aren't in order
371 2014-10-28 17:40:54 <rubensayshi> I just wanted to make sure there wasn't just a simple option to disable the headers-first sync before spending a lot of time fixing it
372 2014-10-28 17:41:40 <rubensayshi> which I completely if there isn't btw, a lot of hassle to support 2 methods, specially if one is obviously better :)
373 2014-10-28 17:43:25 <gmaxwell> Ah. well directly mucking with the data files is pretty inadvisable, we'll probably break it in future versions too.  No, no easy way to appease there; and you wouldn't want to turn it off since its often a 10x speedup for synchronization (and growing).
374 2014-10-28 17:43:31 <rubensayshi> I guess the fix isn't too hard, just parse the index instead of blindly parsing the blk files
375 2014-10-28 17:43:46 <rubensayshi> for now
376 2014-10-28 17:44:24 <rubensayshi> both those projects just use the parsing of the data files to speed up the initial import and then use the rpc once it is caught up
377 2014-10-28 17:44:50 <gmaxwell> it shouldn't parse the index, that would just increase the vulnerabily to breaking. Things should connect to the p2p port and fetch blocks, or the rpc. ... or maybe index them themselves (but as mentioned, we'll break this again almost certantly).
378 2014-10-28 17:44:53 <michagogo> rubensayshi: don't even need that
379 2014-10-28 17:45:05 <michagogo> You could look at how linearize does it
380 2014-10-28 17:45:16 <michagogo> Read the files, build a chain
381 2014-10-28 17:45:35 <michagogo> If you see an orphan, save its hash and position in the file somewhere
382 2014-10-28 17:45:48 <michagogo> And maybe its prevblock
383 2014-10-28 17:46:25 <rubensayshi> hmm, thanks for pointing that one out, I'll take a look
384 2014-10-28 17:47:22 <rubensayshi> gmaxwell, the default is using the rpc/p2p network, it's a dirty alternative to speed up the initial import
385 2014-10-28 17:48:31 <rubensayshi> so it's not a big disaster now and it won't be the next time changes are made, but it doesn't hurt to keep it going for as long as possible :D
386 2014-10-28 17:49:48 <gmaxwell> rubensayshi: just assume every major version will break it. Our files on disk aren't a 'supported api'. :)
387 2014-10-28 17:50:54 <rubensayshi> I do, and I don't intend to drop my database so I don't care that much, just wanted to fix it for new users :)
388 2014-10-28 20:20:00 <Diablo-D3> https://www.intelpentium4litigation.com
389 2014-10-28 21:50:30 <coryfields_> gmaxwell: ping
390 2014-10-28 21:50:49 <gmaxwell> pong
391 2014-10-28 21:51:30 <coryfields_> gmaxwell: a few days ago we briefly discussed how the script interpreter could return error numbers rather than logging directly
392 2014-10-28 21:51:54 <coryfields_> did you have any specifics in mind for that? or just was that just a general idea?
393 2014-10-28 21:52:09 <coryfields_> (that's now the only thing standing in the way of removing boost)
394 2014-10-28 21:55:28 <gmaxwell> It was just a general idea. I don't have too much specifics in mind other than it shouldn't overload the path where success/failure is returned.
395 2014-10-28 21:55:58 <gmaxwell> E.g. taking some errors object (could just be an integer pointer) and updating it if its set is probably fine.
396 2014-10-28 21:56:00 <coryfields_> reason i ask is that those values would become part of the consensus lib api, so i don't want to hastily create arbitrary return values
397 2014-10-28 21:57:57 <coryfields_> ok
398 2014-10-28 21:59:35 <coryfields_> would there be much value from the caller-side to have real return values? Would a pointer to a string that would be filled in with an error message suffice?
399 2014-10-28 22:01:12 <mrmadden> Is there a way to donate to bitcoin core dev without going through a 3rd party like BF or tip4commit?
400 2014-10-28 22:07:34 <michagogo> mrmadden: Sure, decide who you want to donate to and ask them for an address
401 2014-10-28 22:12:47 <gmaxwell> FWIW, I finally re-PRed the replacement for the fallback external IP discovery: https://github.com/bitcoin/bitcoin/pull/5161
402 2014-10-28 22:17:18 <chmod755> gmaxwell, that's great. i actually read that part today after a long time and was surprised that it's still hardcoded
403 2014-10-28 22:18:45 <gmaxwell> chmod755: please feel free to test. I think even if I screwed it up, its less bad than using the external service stuff... but always good to have more testing.