1 2014-05-05 00:56:57 <BlueMatt> it appears they reset their counters, so just ignore the 0 line, but https://blockchain.info/charts/n-orphaned-blocks
  2 2014-05-05 00:57:10 <BlueMatt> its a lower bound
  3 2014-05-05 02:38:52 <ganjafarmer> hey does anyone recall any of those new services that offer web services APIs for building bitcoin apps on top of?  pretty sure there were a couple of them around now, but i can't find them.
  4 2014-05-05 03:25:16 <jcorgan> no/cl
  5 2014-05-05 05:04:54 <justanotheruser> m not thinking too clearly. It would be a smaller amount of space (counting both the output script and input scriptsig) to act as an oracle by signing the number 0 or 1 (for event happened or didn't) than would to sign the transaction itself?
  6 2014-05-05 05:07:58 <gmaxwell> justanotheruser: better to do what relaity keys does and have the oralcle release either an Yes or No private key, since this lets you do the maximally small thing, _and_ it allows you to blind the oracle to your transaction.
  7 2014-05-05 05:09:08 <justanotheruser> gmaxwell: how does it blind the oracle more than signing 1 or 0?
  8 2014-05-05 05:09:40 <gmaxwell> because you sum the oracles public key with user public key(s).
  9 2014-05-05 05:10:27 <justanotheruser> gmaxwell: what do you mean summing them? Is that related to ECDSA or bitcoin scripting?
 10 2014-05-05 05:13:02 <gmaxwell> The former.
 11 2014-05-05 05:14:47 <justanotheruser> gmaxwell: how is the public key known if you haven't summed them yet (before the event has happens, but after the tx has been made)?
 12 2014-05-05 05:15:24 <gmaxwell> justanotheruser: the service tells you what the public keys will be.
 13 2014-05-05 05:15:56 <justanotheruser> gmaxwell: but isn't the key sum needed for the transaction?
 14 2014-05-05 05:16:04 <gmaxwell> Yes.
 15 2014-05-05 05:16:20 <justanotheruser> The service can only tell you their public key, not the keysum
 16 2014-05-05 05:18:11 <justanotheruser> On a different note, is it just (myPriv +theirPriv) mod maxkeyval?
 17 2014-05-05 05:18:26 <gmaxwell> I don't understand where your confusion is coming from... so I'm just going to explain the whole thing.   You ask the oracle, "Hey, help us out by telling us later if the bitcoin market price went up." the oracle responds, "Okay, if the price goes up, tomorrow I'll release the private key for pubkey A, otherwise I'll release the private key for pubkey B".
 18 2014-05-05 05:19:20 <gmaxwell> Then we can go off and form a transaction which pays to 1 of 2  mypub+A and yourpub+B.  The private keys combine like you expect (mod the order of the group).
 19 2014-05-05 05:19:55 <gmaxwell> The oracle cannot identify the transaction on the blockchain related to its decision, at least not without someone telling it mypub or yourpub.
 20 2014-05-05 05:19:55 <justanotheruser> gmaxwell: understood. The confusion is on how you construct a transaction which is pay2pubkeyhash without knowing the public key generated from the privatekeysum if the private key sum isn't known yet
 21 2014-05-05 05:20:15 <gmaxwell> You sum the _public keys_ to get the public key sum.
 22 2014-05-05 05:20:21 <gmaxwell> (it's point addition)
 23 2014-05-05 05:21:02 <justanotheruser> gmaxwell: will pubkeyA + pubkeyB be the same as the public key for privkeyA + privketB?
 24 2014-05-05 05:22:48 <justanotheruser> Never mind, that's a really.dumb questiln
 25 2014-05-05 05:23:01 <gmaxwell> Yes. (in the first case it's point addition, in the latter its addition of scalars mod the curve order), because A*G + B*G = (A+B)*G
 26 2014-05-05 05:23:51 <justanotheruser> gmaxwell: I guess it wasn't a dumb question and the root of my confusion was that I didn't understand that
 27 2014-05-05 05:24:59 <justanotheruser> gmaxwell: interesting. So I wouldn't need to communicate with the user for them to use me as an oracle would I?
 28 2014-05-05 05:26:24 <gmaxwell> You could just act as a broadcasting party.
 29 2014-05-05 05:27:17 <justanotheruser> Cool, thanks for your help. Interesting how ECDSA adds like that. Is it the same for RSA?
 30 2014-05-05 05:29:19 <gmaxwell> There are related homorphisms in RSA cryptosystem, the EC ones are nicer and generally more usable.
 31 2014-05-05 05:32:03 <michagogo> cloud|justanotheruser: it's the same mechanism that allows vanity address mining
 32 2014-05-05 05:32:38 <michagogo> cloud|(I think)
 33 2014-05-05 05:32:46 <justanotheruser> michagogo|cloud: oh, it isn't just brute forcing all signatures?
 34 2014-05-05 05:32:57 <michagogo> cloud|justanotheruser: hm?
 35 2014-05-05 05:33:11 <justanotheruser> *bruteforcing All keys
 36 2014-05-05 05:33:22 <michagogo> cloud|By "vanity address mining" I mean having someone else generate a vanity address for you
 37 2014-05-05 05:35:18 <GAit> i'd like to learn more about that
 38 2014-05-05 05:35:20 <michagogo> cloud|I generate a privkey, and give you the pubkey. You brute-force a certain pattern, but rather than generating privkeys and looking at their pubkeyhashes, you look at the hashes of that pubkey plus the pubkey I gave you.
 39 2014-05-05 05:35:43 <GAit> oh, got it
 40 2014-05-05 05:36:04 <michagogo> cloud|When you find one, you give me the privkey, and I combine that with my privkey, and I have a privkey, known only to me, with that vanity address
 41 2014-05-05 05:38:09 <justanotheruser> michagogo|cloud: oh, I thought you were talking about local mining. That's smart
 42 2014-05-05 05:39:28 <GAit> very interesting how this property can be used for privacy in 'oracle' applications.
 43 2014-05-05 05:40:53 <justanotheruser> Yeah, the oracle part seems ridiculously easy to implement
 44 2014-05-05 05:43:29 <gmaxwell> justanotheruser: kazam: https://www.realitykeys.com/
 45 2014-05-05 05:43:58 <michagogo> cloud|justanotheruser: I've seen the local, search-for-yourself version called "generation" and the search-for-someone-else version called "mining"
 46 2014-05-05 05:45:12 <justanotheruser> gmaxwell: aww, its already done
 47 2014-05-05 05:45:56 <gmaxwell> (even more fun than 1 of 2, use 1 of 3 with {userA+OracleA,userB+OracleB,userA+userB} so even if the oracle craps out, the users can cooperate to release without the oracle's help)
 48 2014-05-05 05:46:30 <justanotheruser> gmaxwell: why aren't all m of n tx compressed like this?
 49 2014-05-05 05:47:43 <gmaxwell> justanotheruser: AFAIK no one has done a useful interface for the key addition, so as far as I know, no one is using it that way currently!
 50 2014-05-05 05:48:09 <gmaxwell> justanotheruser: because you have to actually share a private key to do this, which is usually NOT what you want to do, since you lose all control of it if you do that.
 51 2014-05-05 05:48:35 <justanotheruser> gmaxwell: well the oracles could sign their one time private key
 52 2014-05-05 05:48:42 <justanotheruser> *public
 53 2014-05-05 05:48:59 <michagogo> cloud|8:46:21 <gmaxwell> (even more fun than 1 of 2, use 1 of 3 with {userA+OracleA,userB+OracleB,userA+userB} so even if the oracle craps out, the users can cooperate to release without the oracle's help) <-- the users need to trust each other, to do that
 54 2014-05-05 05:49:00 <gmaxwell> yes its fine for the oracle application, it's useless for virtually every other application.
 55 2014-05-05 05:49:38 <michagogo> cloud|Or use a trusted 3rd party
 56 2014-05-05 05:49:41 <justanotheruser> michagogo|cloud: trust each other to get the money back to a party, which is better than not getting it at all
 57 2014-05-05 05:49:42 <gmaxwell> michagogo|cloud: well not precisely. I mean, if userA won, userB would give him his private key.
 58 2014-05-05 05:49:53 <michagogo> cloud|Er, um.
 59 2014-05-05 05:49:54 <michagogo> cloud|Yeah.
 60 2014-05-05 05:49:59 <gmaxwell> UserB has absolutely no reason to demand the other direction except fraud.
 61 2014-05-05 05:49:59 <michagogo> cloud|I'll just go away now.
 62 2014-05-05 05:50:16 <gmaxwell> it's okay. :) this stuff is tricky.
 63 2014-05-05 05:50:16 <justanotheruser> Gmax
 64 2014-05-05 05:50:35 <justanotheruser> gmaxwell: how is it not useful for m of n?
 65 2014-05-05 05:51:20 <gmaxwell> justanotheruser: because one party has free control of the resulting transaction.
 66 2014-05-05 05:51:32 <gmaxwell> It's not a threshold signature, it's just people handing over private keys.
 67 2014-05-05 05:51:50 <justanotheruser> gmaxwell: ah, youre right
 68 2014-05-05 05:52:43 <gmaxwell> It works for a narrow set of usecases where you need a single, one time, binary control. Otherwise you need a multisignature or thresholdsignature.
 69 2014-05-05 06:53:55 <warren> can someone recommend the easiest way to synthetically put bitcoin into safe mode?
 70 2014-05-05 06:54:10 <wumpus> there's a commnd line option for that
 71 2014-05-05 06:59:28 <warren> sorry, where?
 72 2014-05-05 07:27:52 <wumpus> src/init.cpp:        strUsage += "  -testsafemode          " + _("Force safe mode (default: 0)") + "\n";
 73 2014-05-05 08:18:28 <damethos> Quick question: Do you need to send a getblocks request to bitcoind every 500 blocks or if you make one getblocks request and wait you will receive future blocks as well?
 74 2014-05-05 08:25:43 <olalonde> i think by default you only receive new blocks
 75 2014-05-05 08:26:10 <olalonde> after you received the 500 blocks you should probably make a new request until you are up to sync
 76 2014-05-05 08:26:25 <sipa> damethos: you will always see invs for new blocks
 77 2014-05-05 08:26:43 <sipa> but you need to use getblocks to get the invs as long as you're not synced
 78 2014-05-05 08:39:54 <damethos> thanks guys, makes sense now
 79 2014-05-05 09:56:04 <WhiteStar> who is Martin Thursby?
 80 2014-05-05 12:37:01 <elichai2> hey
 81 2014-05-05 12:37:37 <elichai2> how can i make bitcoin self compiled binary weigh less?
 82 2014-05-05 12:37:54 <sipa> strip it?
 83 2014-05-05 12:40:13 <elichai2> yeah
 84 2014-05-05 12:40:21 <elichai2> what command?
 85 2014-05-05 12:40:34 <null> strip(1)
 86 2014-05-05 12:41:10 <elichai2> null: what?
 87 2014-05-05 12:41:18 <survic> $ strip bitcoind
 88 2014-05-05 12:41:22 <sipa> to strip a binary, you use the 'strip' command
 89 2014-05-05 12:41:27 <elichai2> ohh ok
 90 2014-05-05 12:41:36 <sipa> null's notation means you're supposed to look up the man page for strip in section 1
 91 2014-05-05 12:41:59 <sipa> man 1 strip
 92 2014-05-05 12:45:23 <dexX7> is there any transaction type which is not pay-from-pubkey-hash which has a pubkey as second scriptsig parameter?
 93 2014-05-05 12:46:03 <sipa> an infinite number of them, but none standard
 94 2014-05-05 12:46:51 <dexX7> ty
 95 2014-05-05 13:22:19 <mantas322> Hi guys
 96 2014-05-05 13:22:45 <mantas322> I just watched the MIT videos..
 97 2014-05-05 13:23:09 <mantas322> Good Job Gavin!
 98 2014-05-05 13:25:10 <mantas322> excellent presentation.
 99 2014-05-05 14:13:52 <arjen-jonathan> I want to retrieve the output address from an arbitrary scrypt
100 2014-05-05 14:14:59 <michagogo> cloud|arjen-jonathan: do you mean a script?
101 2014-05-05 14:15:32 <michagogo> cloud|And does the script in question fit the form "OP_DUP OP_HASH160 <pubkeyhash> OP_EQUALVERIFY OP_CHECKSIG"?
102 2014-05-05 14:15:55 <arjen-jonathan> Ah yes I meant a script. And no.
103 2014-05-05 14:16:13 <michagogo> cloud|Well, can you explain what you're trying to do then?
104 2014-05-05 14:16:27 <wumpus> from what programming language?
105 2014-05-05 14:16:40 <arjen-jonathan> c++, original bitcoin implementation.
106 2014-05-05 14:17:01 <wumpus> what you need is a script matcher/recognizer
107 2014-05-05 14:17:06 <michagogo> cloud|What are you trying to do here?
108 2014-05-05 14:17:07 <arjen-jonathan> I do want to extract the pubkeyhash, but from arbitrary scripts.
109 2014-05-05 14:17:22 <sipa> well only pay-to-pubkeyhash scripts have a pubkeyhash...
110 2014-05-05 14:17:30 <michagogo> cloud|Zoom out a step, what are you trying to accomplish here?
111 2014-05-05 14:17:46 <sipa> we have a hack for extracting a pubkeyhash from a pay-to-pubkey as well, but i consider that an ugly historical artifact
112 2014-05-05 14:17:55 <arjen-jonathan> Hmm
113 2014-05-05 14:18:19 <sipa> addresses are shorthands for specific scripts
114 2014-05-05 14:18:39 <sipa> going back from the script to the address is just matching it against the standard template for that address type
115 2014-05-05 14:18:41 <michagogo> cloud|https://en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addresses
116 2014-05-05 14:19:18 <arjen-jonathan> Oke, stepping back: I want to know from where the coins that are spent in the tx that I'm looking at are coming from.
117 2014-05-05 14:19:25 <sipa> don't
118 2014-05-05 14:19:30 <michagogo> cloud|arjen-jonathan: you probably don't
119 2014-05-05 14:19:35 <michagogo> cloud|or, can't
120 2014-05-05 14:19:38 <sipa> you sould not care about that
121 2014-05-05 14:19:41 <arjen-jonathan> Why?
122 2014-05-05 14:19:49 <sipa> unless you sent them yourself, in which case you already know
123 2014-05-05 14:19:58 <michagogo> cloud|Why do you want to
124 2014-05-05 14:19:59 <michagogo> cloud|?
125 2014-05-05 14:20:02 <sipa> you cannot rely on what scripts some previous person used to maintain its coins
126 2014-05-05 14:20:19 <michagogo> cloud|If we know why you think you want to do this, we can better explain why you don't
127 2014-05-05 14:20:21 <sipa> and your code will break if people start using complex scripts, or coinjoin, ...
128 2014-05-05 14:20:39 <sipa> see topic: "there is no from address"
129 2014-05-05 14:20:50 <arjen-jonathan> *looking up that topic*
130 2014-05-05 14:21:04 <sipa> no, just the topic of this channel
131 2014-05-05 14:21:07 <michagogo> cloud|hm? he means, "as it says in the channel topic"
132 2014-05-05 14:21:34 <sipa> bitcoin transactions spend coins, and those coins may or may not have a recognizable address they were previously sent to
133 2014-05-05 14:21:55 <sipa> but this is not "where the coins come from", it cannot be used to reliably detect who sent it
134 2014-05-05 14:22:03 <sipa> and it cannot be used to reliably send coins back to them
135 2014-05-05 14:23:15 <mantas322> sipa, you were mentioned in gavin's talk.
136 2014-05-05 14:23:25 <sipa> cool; didn't watch it yet
137 2014-05-05 14:23:39 <mantas322> celebrity status.
138 2014-05-05 14:25:42 <arjen-jonathan> sipa: what do you mean with 'who sent it'? Is is impossible to find out from which wallet they are being moved?
139 2014-05-05 14:25:49 <sipa> arjen-jonathan: yes
140 2014-05-05 14:26:20 <arjen-jonathan> No let me rephrase that. Let's assume I see all blocks coming in. Could I detect transactions that move coins from a specific wallet?
141 2014-05-05 14:26:20 <sipa> arjen-jonathan: if you need to distinuish who sent it, or what it is for: use a different receive address for each payment
142 2014-05-05 14:26:26 <michagogo> cloud|You can tell which script an output was previously assigned to
143 2014-05-05 14:26:33 <michagogo> cloud|Yes, you could
144 2014-05-05 14:26:36 <sipa> you have no concept of what someone's wallet is
145 2014-05-05 14:26:48 <sipa> or how they manage the coins in it
146 2014-05-05 14:26:54 <sipa> and you shouldn't care
147 2014-05-05 14:26:56 <michagogo> cloud|But a wallet may not be what you think it is
148 2014-05-05 14:27:09 <sipa> a wallet is a client-level abstraction
149 2014-05-05 14:27:12 <arjen-jonathan> I'm only caring because I want to understand this.
150 2014-05-05 14:27:35 <sipa> arjen-jonathan: for example, if you have a shared wallet, where multiple users have a balance, but the coins are shared
151 2014-05-05 14:27:56 <arjen-jonathan> sipa: Yes I understand.
152 2014-05-05 14:27:56 <michagogo> cloud|If you know all the public keys in a wallet, you can monitor for transactions spending outputs sent to that wallet, yes
153 2014-05-05 14:27:56 <sipa> arjen-jonathan: sending coins back to the apparent "from address" may result in them being credited to the wrong user
154 2014-05-05 14:28:31 <arjen-jonathan> I'm not really interested in tying tx 'es to people.
155 2014-05-05 14:28:40 <sipa> then how do you define wallet?
156 2014-05-05 14:28:44 <arjen-jonathan> Oke, my nomen clature is a bit rusty.
157 2014-05-05 14:29:16 <sipa> if you can detect two payments as coming from the same wallet, that would be a serious privacy problem
158 2014-05-05 14:29:44 <sipa> (if people reuse the same address for multiple payments, they are voluntarily giving up privacy)
159 2014-05-05 14:29:55 <michagogo> cloud|(and not just their privacy, either)
160 2014-05-05 14:29:56 <arjen-jonathan> Let me rephrase it again: transations move coins from something and to something. In bitcoin those somethings have addresses in the end correct? (leaving out publicly spendable txes for now)
161 2014-05-05 14:30:18 <sipa> arjen-jonathan: they do not move them "from" somewhere
162 2014-05-05 14:30:22 <michagogo> cloud|No
163 2014-05-05 14:30:41 <sipa> arjen-jonathan: they consume coins, and produce new coins, and assign those coins a script which defines under which conditions it can be spent
164 2014-05-05 14:30:44 <michagogo> cloud|A transaction, say a coinbase transaction with no inputs, creates one or more outputs
165 2014-05-05 14:30:51 <sipa> that script is sometimes recognizable as an address
166 2014-05-05 14:30:59 <michagogo> cloud|It defines conditions under which that output may be spent
167 2014-05-05 14:31:09 <sipa> but "who needed to sign to spend a coin" is not "who sent the coin"
168 2014-05-05 14:31:52 <michagogo> cloud|To create new outputs outside of a coinbase transaction, you must spend other outputs
169 2014-05-05 14:32:16 <arjen-jonathan> Yes, so far I understand it.
170 2014-05-05 14:32:31 <sipa> do you know coinjoin?
171 2014-05-05 14:32:32 <michagogo> cloud|You do that by fulfilling the conditions on one or more existing outputs, with a value equal to or greater than the new outputs you're creating
172 2014-05-05 14:32:38 <arjen-jonathan> sipa: no.
173 2014-05-05 14:32:59 <sipa> arjen-jonathan: it means you jointly construct a transaction... with inputs coming from both people's wallets, and outputs going to both people's payees
174 2014-05-05 14:33:14 <arjen-jonathan> michagogo|cloud: yes. and in most cases that means your hash must match the "to" correct?
175 2014-05-05 14:33:16 <sipa> so such a transaction does not even have a single "sender"
176 2014-05-05 14:33:32 <sipa> and it's still not distinguishable from a "normal" transaction
177 2014-05-05 14:33:55 <sipa> arjen-jonathan: that makes no sense
178 2014-05-05 14:34:01 <sipa> what hash?
179 2014-05-05 14:34:19 <arjen-jonathan> sipa: yes, I understand, but I could still see that some address/identifier (not of a person obviously) is contributing then?
180 2014-05-05 14:34:29 <michagogo> cloud|arjen-jonathan: An address, such as 1MichakGVx5GeKMKw12aWg66CEuqTGrBB9, is shorthand for the set of conditions that is: a public key that hashes to this value must be presented, and the transaction must be signed by that key
181 2014-05-05 14:34:34 <sipa> arjen-jonathan: yes, but that's utterly meaningless
182 2014-05-05 14:34:50 <sipa> arjen-jonathan: what would you use that information for?
183 2014-05-05 14:34:56 <sipa> arjen-jonathan: plus it's confusing to people
184 2014-05-05 14:35:02 <arjen-jonathan> I see
185 2014-05-05 14:35:30 <michagogo> cloud|And in many cases, the script a coin was previously assigned to isn't able to be spent from by the originator of the transaction
186 2014-05-05 14:35:45 <michagogo> cloud|For example, if you use webwallets that use a shared wallet
187 2014-05-05 14:35:50 <michagogo> cloud|For example, coinbase.com
188 2014-05-05 14:36:38 <michagogo> cloud|When you tell coinbase,com that you want to spend bitcoins from your online wallet there, they won't send the same bitcoins that you deposited
189 2014-05-05 14:37:10 <sipa> they just maintain one pile of coins
190 2014-05-05 14:37:15 <michagogo> cloud|When you send them bitcoins, they just go into the massive pool, and your balance is incremented
191 2014-05-05 14:37:21 <sipa> and remember how much of each customer owns
192 2014-05-05 14:37:24 <sipa> not which coins they own
193 2014-05-05 14:37:39 <michagogo> cloud|When you tell them to send coins, they just send any coins from that pool
194 2014-05-05 14:38:23 <michagogo> cloud|And the address that the coins previously belonged to isn't yours
195 2014-05-05 14:38:51 <sipa> as luke likes to say: once a coin is in a wallet, it doesn't matter anymore to what address it was sent
196 2014-05-05 14:39:01 <sipa> only the knowledge on how to spend it
197 2014-05-05 14:39:23 <michagogo> cloud|So if some unwise merchant erroneously thinks that they can send you coins back to the address that they were previously sent to, they'll send your refund back to coinbase.com
198 2014-05-05 14:39:51 <michagogo> cloud|It may get credited to some random user, or it may just vanish into the void and become profit for them
199 2014-05-05 14:40:08 <arjen-jonathan> Yes, I see how that works
200 2014-05-05 14:41:59 <sipa> it's not that you can't define "which addresses contributed to this transaction", it's that it is useless information
201 2014-05-05 14:42:34 <survic> unless it's a blockchain.info wallet making the transactions, then that information is all revealing.
202 2014-05-05 14:43:09 <sipa> that means you're relying on particular properties of the software creating the transaction
203 2014-05-05 14:43:38 <sipa> which is unnecesarily restricting
204 2014-05-05 14:43:48 <arjen-jonathan> So basically: unless I have the PRIVATE key, there is no way to know from what entity money is coming from
205 2014-05-05 14:44:16 <lianj> michagogo|cloud: fyi, for coinbase.com sending back to that address works and will end up in your account again.
206 2014-05-05 14:44:24 <michagogo> cloud|Uh?
207 2014-05-05 14:44:48 <survic> sipa: blockchain.info wallets make up most of the transactions on the network I would think. not using change addresses is a huge giveaway.
208 2014-05-05 14:44:57 <michagogo> cloud|So they actually keep their users' wallets separated?
209 2014-05-05 14:45:00 <sipa> survic: yes
210 2014-05-05 14:45:01 <survic> they're also tagged as such.
211 2014-05-05 14:45:13 <michagogo> cloud|survic: huh?
212 2014-05-05 14:45:15 <survic> michagogo|cloud: no they're not. they use hot/cold wallets.
213 2014-05-05 14:45:16 <lianj> michagogo|cloud: yes
214 2014-05-05 14:45:18 <michagogo> cloud|No they're not
215 2014-05-05 14:45:30 <michagogo> cloud|Tagged how?
216 2014-05-05 14:45:52 <arjen-jonathan> Let me ask something stupid: what DOES a public key represent then?
217 2014-05-05 14:46:01 <michagogo> cloud|arjen-jonathan: a pubkey is a pubkey
218 2014-05-05 14:46:25 <arjen-jonathan> But is is tied to any coins in any way?
219 2014-05-05 14:46:26 <lianj> the relation between a user sending from that address doesn't break. if someone refunds to those address they end up back in your account.
220 2014-05-05 14:46:40 <accelerate> [10:43:51] <arjen-jonathan> So basically: unless I have the PRIVATE key, there is no way to know from what entity money is coming from
221 2014-05-05 14:46:43 <accelerate> This isn't true
222 2014-05-05 14:46:56 <sipa> you may have a watch-only wallet with just public keys
223 2014-05-05 14:47:03 <survic> michagogo|cloud: blockchain.info shows "sent by" IP addresses. for blockchain.info wallets that's localhost/loopback. all web wallet transactions have this, but not all transactions with loopback IP addresses are web wallet transactions. you can use other tells, like their signature encoding and use of change addresses as well.
224 2014-05-05 14:47:09 <sipa> but know that those keys are managed together by particular software in a particular way
225 2014-05-05 14:47:17 <michagogo> cloud|arjen-jonathan: if you want to know where a payment is coming from, you give them a unique address
226 2014-05-05 14:47:35 <michagogo> cloud|When a payment comes to that address, you know it's from whoever you gave the address to
227 2014-05-05 14:48:02 <accelerate> unless someone's spying on you, michagogo|cloud. ;)
228 2014-05-05 14:48:12 <sipa> it means you track what is being paid for
229 2014-05-05 14:48:15 <dgenr8> someday I hope to see a wallet called "keybag" that exposes the controlled UTXO's unapologetically and intuitively
230 2014-05-05 14:48:15 <sipa> not who is paying
231 2014-05-05 14:48:17 <michagogo> cloud|If you know all the pubkeys of a wallet, you can identify transactions in and out of that wallet
232 2014-05-05 14:48:24 <sipa> which is almost always what you actually care about
233 2014-05-05 14:48:53 <sipa> dgenr8: it would be a scriptbag, not a keybah
234 2014-05-05 14:49:03 <dgenr8> private key bag
235 2014-05-05 14:49:03 <sipa> dgenr8: you only need the keys to actually create transactions to spend them
236 2014-05-05 14:49:11 <dgenr8> bag of private keys
237 2014-05-05 14:49:18 <sipa> and that may be more complex than just tracking the balance of the bag
238 2014-05-05 14:49:20 <survic> a wallet?
239 2014-05-05 14:49:24 <dgenr8> UI challenge
240 2014-05-05 14:49:25 <survic> that's a bag of private keys.
241 2014-05-05 14:50:05 <tyrick> In the first Satoshi client, would the wallet allow you to easily spend an amount that wasn't some combination of previous received coins?
242 2014-05-05 14:50:22 <CoinHeavy> To store the blockchain on a separate drive from the binary, is best practice simply a symlink for ~/.bitcoin ?
243 2014-05-05 14:50:29 <survic> tyrick: of course.
244 2014-05-05 14:50:37 <survic> tyrick: that's described in the whitepaper.
245 2014-05-05 14:50:50 <tyrick> I should really reread that paper
246 2014-05-05 14:51:01 <CoinHeavy> http://nakamotoinstitute.org/bitcoin/
247 2014-05-05 14:51:04 <CoinHeavy> clean html version
248 2014-05-05 14:51:11 <tyrick> thx
249 2014-05-05 14:51:22 <sipa> dgenr8: in case of multisig or other complex scripts, it's more than just a bag of private keys
250 2014-05-05 14:51:31 <sipa> dgenr8: you also need to know how to interact with others
251 2014-05-05 14:51:43 <michagogo> cloud|CoinHeavy: erm, or just put the binary elsewhere
252 2014-05-05 14:51:47 <sipa> dgenr8: it's easier to see the watch-only part and the transaction construction part separately
253 2014-05-05 14:51:48 <michagogo> cloud|or use the -datadir option
254 2014-05-05 14:51:55 <sipa> dgenr8: so it's a bag of scripts to watch a wallet
255 2014-05-05 14:52:15 <sipa> dgenr8: and then some knowledge on how to construct transactions that are sent to those scripts (optionally)
256 2014-05-05 14:52:21 <CoinHeavy> michagogo: thanks, both good ideas
257 2014-05-05 14:52:34 <michagogo> cloud|(I think the symlink thing also works, though)
258 2014-05-05 14:53:19 <CoinHeavy> cool.  your alternatives feel more robust.  I’ll experiment
259 2014-05-05 14:53:36 <arjen-jonathan> sipa: I still don't quite understand: Say I have two people, A and B. Let's say that A has some money, previously sent to his pubkey. If B has A's pubkey, can A then spent this money without B finding out?
260 2014-05-05 14:53:47 <dgenr8> sipa: sure, you need software.  but also, salvagewallet works because the essence of wallet.dat is a bag of keys
261 2014-05-05 14:54:14 <arjen-jonathan> sipa: and if so: how?
262 2014-05-05 14:54:24 <michagogo> cloud|arjen-jonathan: no
263 2014-05-05 14:54:28 <michagogo> cloud|To spend, you need the privkey
264 2014-05-05 14:54:35 <michagogo> cloud|Oh, sorry
265 2014-05-05 14:54:41 <michagogo> cloud|I misread
266 2014-05-05 14:55:06 <michagogo> cloud|If B knows that a pubkey belongs to A, then if A spends the output B can see that
267 2014-05-05 14:55:17 <michagogo> cloud|B can't tell where it's going, though...
268 2014-05-05 14:56:05 <arjen-jonathan> Oke, so how would B reliably detect this?
269 2014-05-05 14:56:17 <sipa> arjen-jonathan: no
270 2014-05-05 14:56:32 <sipa> arjen-jonathan: the point is that you don't reveal how public keys relate to identities
271 2014-05-05 14:56:50 <michagogo> cloud|arjen-jonathan: ...by watching for transactions that are signed with the pubkey
272 2014-05-05 14:56:50 <sipa> dgenr8: salvagewallet does not work with multisig :)
273 2014-05-05 14:57:22 <michagogo> cloud|(that is, transactions spending coins sent to that pubkey or its hash)
274 2014-05-05 14:57:57 <dgenr8> sipa: mempool is not a good place for working on transactions-in-progress
275 2014-05-05 14:58:15 <michagogo> cloud|No, it's not
276 2014-05-05 14:58:17 <sipa> dgenr8: of course not
277 2014-05-05 14:58:25 <sipa> dgenr8: the mempool only contains valid transactions
278 2014-05-05 14:58:32 <arjen-jonathan> Oke, now we are at exactly the spot where I started out :P because this confirms how I thought it worked; sorry that I misphrased it!
279 2014-05-05 14:58:34 <michagogo> cloud|The mempool is valid transactions. A pool of transactions available to include in a block.
280 2014-05-05 14:59:41 <arjen-jonathan> michagogo|cloud: so now the question remains: how do I parse the "sent to" address from a script reliably?
281 2014-05-05 15:00:01 <michagogo> cloud|arjen-jonathan: not every script has a corresponding address
282 2014-05-05 15:00:05 <sipa> arjen-jonathan: is it for detecting transactions to yourself?
283 2014-05-05 15:00:27 <michagogo> cloud|sipa: he said it's not a DUP HASH160 <hash> EQUALVERIFY CHECKSIG
284 2014-05-05 15:00:34 <arjen-jonathan> no, to a pubkey that I know, but not necessarily mine.
285 2014-05-05 15:00:48 <sipa> arjen-jonathan: may i ask why you need that?
286 2014-05-05 15:00:57 <sipa> what are you trying to do?
287 2014-05-05 15:00:59 <dgenr8> sipa: software does more than watch balances and needs persistent data to support those other functions
288 2014-05-05 15:01:05 <arjen-jonathan> michagogo|cloud: yes, because I worried that there might be other scripts that do essentially the same, but are not identical.
289 2014-05-05 15:01:21 <dgenr8> sipa: my point is, just because situation is complex does not mean UI has to hide details
290 2014-05-05 15:01:27 <sipa> arjen-jonathan: the wallet owner defines transactions to which output he considers payments to him
291 2014-05-05 15:01:46 <dgenr8> I keep forgetting we have coin control now
292 2014-05-05 15:02:25 <sipa> arjen-jonathan: i still don't know what you're trying to achieve
293 2014-05-05 15:03:56 <arjen-jonathan> I have a pubkey associated with person A, assuming I see every tx in the network, I want to detect payments from that pubkey.
294 2014-05-05 15:04:21 <survic> why bother using BTC then?
295 2014-05-05 15:04:25 <survic> ugh, sorry.
296 2014-05-05 15:04:42 <sipa> arjen-jonathan: to accomplish what?
297 2014-05-05 15:04:55 <arjen-jonathan> And I want it to be reliable: i.e. A cannot circumvent detecting it.
298 2014-05-05 15:05:05 <arjen-jonathan> I just want to know if it's possible.
299 2014-05-05 15:05:09 <thrownull> dgenr8: coin control?
300 2014-05-05 15:05:19 <arjen-jonathan> I'm trying to grasp how anonymous bitcoin is.
301 2014-05-05 15:05:34 <thrownull> arjen-jonathan: mostly not anonymous
302 2014-05-05 15:05:37 <sipa> arjen-jonathan: bitcoin is not anonymous at all; it is pseudonymous
303 2014-05-05 15:05:48 <sipa> arjen-jonathan: privacy relies on it being hard to link ideitites to keys
304 2014-05-05 15:06:19 <thrownull> arjen-jonathan: it is easy to be connected to other ID (of you or your business partner), from there to another and another untill connection to you or someone who knows you is found
305 2014-05-05 15:06:23 <arjen-jonathan> Yes, but now I happen to know the pubkey. Is all anonimity lost?
306 2014-05-05 15:06:46 <sipa> arjen-jonathan: there is not "the" public key
307 2014-05-05 15:06:53 <dgenr8> thrownull: when creating transactions you can see controlled outputs and select which to use
308 2014-05-05 15:06:58 <sipa> arjen-jonathan: you're supposed to use a different key for every incoming transaction
309 2014-05-05 15:07:09 <sipa> arjen-jonathan: otherwise knowing one key reveals all your transactions
310 2014-05-05 15:07:16 <arjen-jonathan> sipa: but money associated with the known pubkey would ned to b moved to regain anonimity
311 2014-05-05 15:07:16 <thrownull> dgenr8: nice, in the qt gui? in released version? I didn't test for long time
312 2014-05-05 15:07:24 <arjen-jonathan> which would be detected
313 2014-05-05 15:07:29 <sipa> stop using the word anonymity
314 2014-05-05 15:07:31 <sipa> it does not exist
315 2014-05-05 15:07:39 <sipa> all transactions are public
316 2014-05-05 15:07:41 <dgenr8> thrownull: 0.9.0
317 2014-05-05 15:07:43 <arjen-jonathan> *regain pseudonimity
318 2014-05-05 15:07:47 <sipa> there is privacy though
319 2014-05-05 15:08:12 <thrownull> you could pay from 1foobar address and no one on ther internet knows you're a dog
320 2014-05-05 15:08:29 <sipa> arjen-jonathan: so if you paid entity E by sending coins to address A, you know that A belongs to E
321 2014-05-05 15:08:37 <thrownull> unless they recognized addresses who given you the money (or to which you paid) and ask them from where it come
322 2014-05-05 15:08:41 <sipa> arjen-jonathan: some time later, E will use those coins to move them elsewhere
323 2014-05-05 15:08:53 <sipa> arjen-jonathan: when that happens, ideally, you have no idea where they're going
324 2014-05-05 15:08:54 <thrownull> or unless you exchange to Doges like a Doge and the exchange has your ip/email/etc
325 2014-05-05 15:09:02 <dgenr8> Not for nothing, but satoshibones is being ruthlessly double-spent by one of those autonomous agents we keep hearing about
326 2014-05-05 15:09:47 <arjen-jonathan> sipa:but moving it cannot be done silently. He needs to use the same pubkey that was used to sent him the coins in the first place.
327 2014-05-05 15:10:05 <sipa> arjen-jonathan: so you know the coin is being moved
328 2014-05-05 15:10:06 <sipa> arjen-jonathan: so what?
329 2014-05-05 15:10:08 <thrownull> arjen-jonathan: to break this connections  1) use coinjoin  2) use zerocoin when it is out and working  3) use various exchange via many transactions in big delays and using various amounts of money (e.g. not moving 2.5815 btc to A then to B then to C then do D but spread it)
330 2014-05-05 15:10:25 <arjen-jonathan> Thanks, all I needed to know.
331 2014-05-05 15:10:32 <thrownull> over-the-counter transactions done on private internet (darknets) and/or using alt coins can help too, arjen-jonathan
332 2014-05-05 15:10:42 <sipa> arjen-jonathan: you don't know whether it is moving to a different address in the same owner's wallet, or being used for payment
333 2014-05-05 15:11:04 <arjen-jonathan> I don't care.
334 2014-05-05 15:11:04 <thrownull> arjen-jonathan: for darknet exchanges try #bitcoin and #anoncoin on irc2p (i2p2.de - it's like tor but better imo).  though be very, very patient
335 2014-05-05 15:11:36 <arjen-jonathan> I just wanted to know if A can move his money silently.
336 2014-05-05 15:11:40 <sipa> all it reveals is that someone has the private key associated to that public key
337 2014-05-05 15:11:41 <thrownull> freenode sucks for anonymity/pseudonimity and yet #bitcoin still is here primarly instead OFTC or irc2p.
338 2014-05-05 15:11:49 <sipa> arjen-jonathan: yes
339 2014-05-05 15:11:56 <sipa> arjen-jonathan: he can give the private key to someone else
340 2014-05-05 15:12:15 <sipa> (which has trust issues, but it is possible)
341 2014-05-05 15:12:38 <sipa> or if the key belongs to a shared wallet, balance can just be transferred without moving any coins
342 2014-05-05 15:12:47 <dgenr8> you know ... the agents that can pay for their own compute power.    a single node can only see glimpses of the crime though
343 2014-05-05 15:14:18 <justanotheruser> What is the best way to get a set of inputs adding to value X? Make a transaction and just copy the inputs And trash the output?
344 2014-05-05 15:14:43 <sipa> justanotheruser: run a coin selection algorithm?
345 2014-05-05 15:15:19 <justanotheruser> sipa: isn't that what bitcoind is doing when it constructs the transaction?
346 2014-05-05 15:15:23 <sipa> yes
347 2014-05-05 15:15:59 <justanotheruser> So wouldn't that method work best? Or is bitcoinds coin selection algorithm not optimal?
348 2014-05-05 15:16:07 <sipa> it's far from optimal
349 2014-05-05 15:16:12 <sipa> but it is decent, i think
350 2014-05-05 15:16:27 <sipa> but there's no reason why you need to use bitcoind's implementation
351 2014-05-05 15:16:40 <sipa> if you just want the selection, and not an actual transaction
352 2014-05-05 15:17:14 <survic> justanotheruser: gavin found a nice bug in it recently where adding an input increases the fees, so it adds another input to cover the fees, so it increases the fees, and so forth.
353 2014-05-05 15:17:42 <survic> https://github.com/bitcoin/bitcoin/issues/4082
354 2014-05-05 15:18:03 <justanotheruser> sipa: is there a reason I shouldn't do it? Its two RPC calls and another line of code to extract the inputs
355 2014-05-05 15:18:21 <sipa> justanotheruser: it would unnecessarily create a transaction, which costs fees...
356 2014-05-05 15:18:48 <justanotheruser> sipa: i wouldn't broadcast it though?
357 2014-05-05 15:18:55 <sipa> justanotheruser: yes it would
358 2014-05-05 15:19:16 <sipa> bitcoind has no raw transaction API for doing coin selection
359 2014-05-05 15:19:31 <justanotheruser> sipa: I could have sworn there was...
360 2014-05-05 15:19:34 <justanotheruser> Sipa
361 2014-05-05 15:19:45 <sipa> and if you use sendtoaddress & friends, they do output creation, coin selection, wallet commitment, validation and broadcasting
362 2014-05-05 15:19:52 <michagogo> cloud|survic: um? That should only happen if you have a ton of dust
363 2014-05-05 15:20:21 <justanotheruser> So the most efficient algorithm is to add up the largest outputs until I get above my desired amount?
364 2014-05-05 15:20:24 <survic> michagogo|cloud: of course, but it's still interesting that it exists.
365 2014-05-05 15:20:29 <michagogo> cloud|justanotheruser: not necessarily
366 2014-05-05 15:20:35 <sipa> justanotheruser: it's a bit more complex than that :)
367 2014-05-05 15:20:41 <michagogo> cloud|You need to decide what your goals are
368 2014-05-05 15:20:54 <GAit> privacy vs efficiency
369 2014-05-05 15:20:56 <michagogo> cloud|For example, you may want to minimize the change
370 2014-05-05 15:21:03 <sipa> justanotheruser: all depends on your priorities (byte size, fees, privacy, efficiency of selection, ...)
371 2014-05-05 15:21:08 <justanotheruser> Wouldn't that optimize for tx size though?
372 2014-05-05 15:21:25 <michagogo> cloud|Or maybe increase the change to be as close as possible to the real payment
373 2014-05-05 15:21:34 <michagogo> cloud|Or maybe have multiple change outputs?
374 2014-05-05 15:21:49 <michagogo> cloud|Perhaps you'd like to suck up dust, while you're making a transaction anyway?
375 2014-05-05 15:22:23 <GAit> i was talking with hearn about this, your wallet my learn what your most common purchases are and prepare for it with predefaults for privacy or minimal fee amount
376 2014-05-05 15:22:33 <GAit> s/my/may
377 2014-05-05 15:22:50 <michagogo> cloud|Yeah, there's another example
378 2014-05-05 15:23:22 <michagogo> cloud|Basically, if you're designing such an algorithm, there are dozens and dozens of factors you may want to consider
379 2014-05-05 15:23:47 <GAit> it would be good to collect somewhere the various strategies
380 2014-05-05 15:23:48 <justanotheruser> I see. Perhaps I should just copy bitcoinds algorithm
381 2014-05-05 15:24:32 <justanotheruser> I do trust bitcoind to be more stable than what I write after all
382 2014-05-05 15:24:45 <dgenr8> a random selection algorithm would have some benefits
383 2014-05-05 15:25:14 <CoinHeavy> it doesn’t look like the block reward is available from bitcoind getinfo.  Is there a best practice for calculating/polling this from bitcoind?  (getlastblockreward kind of thing)
384 2014-05-05 15:25:58 <justanotheruser> BTW, is there a list anywhere of the factors one would want to consider in input selection?
385 2014-05-05 15:27:22 <ajweiss> hey folks, has anyone had any luck reproducing the rpc close_wait bug (#3968)?
386 2014-05-05 15:28:46 <ajweiss> i wrote a regression test that spawns a ton of clients and makes them bang on bitcoind with random kills, but i don't seem to be able to reproduce the stuck sockets
387 2014-05-05 15:28:47 <tyrick> I just read the white paper and actually understood it.  The past 2 weeks of studying bitcoin has actually paid off.
388 2014-05-05 15:30:11 <michagogo> cloud|justanotheruser: you could always start by reading BC's code and then either going with that or tweaking it it whatever
389 2014-05-05 15:30:56 <wumpus> ajweiss: nope, never been able to reproduce it; that test sounds welcome, though!
390 2014-05-05 15:31:27 <justanotheruser> CoinHeavy:  you could calculate the block reward based on getblockcount
391 2014-05-05 15:31:43 <michagogo> cloud|CoinHeavy: yeah, that's the best way to do it
392 2014-05-05 15:31:49 <justanotheruser> Michq
393 2014-05-05 15:32:09 <justanotheruser> michagogo|cloud: yeah that's a good idea.
394 2014-05-05 15:32:31 <michagogo> cloud|I mean, you could in theory look at blocks and see what they have in the coinbase transaction, and figure it out based on that :-P
395 2014-05-05 15:33:00 <michagogo> cloud|But that's annoying, and can give you a wrong number if a miner doesn't claim all they're entitled to
396 2014-05-05 15:33:20 <michagogo> cloud|So it's easiest to just look at the block count
397 2014-05-05 15:33:23 <justanotheruser> michagogo|cloud: I was going to say that, but it stops working after a hundred some years and what you just said
398 2014-05-05 15:34:06 <tyrick> How are people, like Satoshi, putting messages in tx?
399 2014-05-05 15:34:37 <belcher> tyrick satoshi's message is in the coinbase transaction
400 2014-05-05 15:34:42 <belcher> since that isnt checked
401 2014-05-05 15:35:06 <justanotheruser> tyrick: also, users spam the network with opreturn
402 2014-05-05 15:35:24 <survic> belcher: part of the coinbase is now
403 2014-05-05 15:35:43 <belcher> well yeah it checks the subsidy isnt more than 50btc + fees and stuff like that
404 2014-05-05 15:36:17 <survic> belcher: BIP0034
405 2014-05-05 15:36:34 <belcher> ill read
406 2014-05-05 15:36:38 <survic> the block height is also in the coinbase, and is checked for validity.
407 2014-05-05 15:37:03 <tyrick> op_return?
408 2014-05-05 15:37:22 <survic> tyrick: returns false.
409 2014-05-05 15:37:53 <tyrick> I am looking at valentine's day messages.  Hm, I supposed that don't see how that would enable a coded message
410 2014-05-05 15:37:55 <survic> that is, it can never be spent. we can not bother storing it in the UXTO because it will never be spent.
411 2014-05-05 15:37:56 <justanotheruser> What did adding the block height to the coin base do? Is it for SPV?
412 2014-05-05 15:38:17 <survic> justanotheruser: makes them all unique for starters.
413 2014-05-05 15:38:28 <tyrick> I see.  But what piece of the tx is carrying the info?
414 2014-05-05 15:38:39 <tyrick> and why is it not hashed?
415 2014-05-05 15:38:51 <justanotheruser> survic: they already have the hash of the previous block which makes it unique?
416 2014-05-05 15:38:58 <survic> justanotheruser: also helps you if you get a block with no parent or child to link it to, you know roughly where it goes.
417 2014-05-05 15:39:08 <ajweiss> wumpus: ok cool, i think i've reproduced it in 0.9.0..  i'm gonna bisect to find the exact commit that fixes it, clean up the test, get it submitted and report it in the issue tracker
418 2014-05-05 15:39:33 <survic> justanotheruser: the coinbase transaction needs a unique TXID. some legacy ones are duplicate, which can't happen now.
419 2014-05-05 15:39:53 <justanotheruser> Ah
420 2014-05-05 15:40:20 <survic> I think the unique TXID coinbases are just invalid now, not sure if they can be spent or not.
421 2014-05-05 15:40:26 <survic> *non unique
422 2014-05-05 15:41:42 <wumpus> ajweiss: great!
423 2014-05-05 15:42:28 <tyrick> looks like 19 ASCII characters is the max length of the message you can embed?
424 2014-05-05 15:43:23 <survic> it's meant to be a hash, not a "message"
425 2014-05-05 15:43:53 <survic> the block chain isn't your private messaging system. OP_RETURN has a large impact for it's cost.
426 2014-05-05 15:45:13 <tyrick> private messaging system?
427 2014-05-05 15:45:36 <tyrick> the private keys?
428 2014-05-05 15:46:12 <survic> no, OP_RETURN. it's not made for storing text.
429 2014-05-05 15:46:56 <tyrick> Is that where messages are being stored?
430 2014-05-05 15:47:14 <sipa> which messages?
431 2014-05-05 15:47:32 <tyrick> http://bitcoinstrings.com/blk00115.txt
432 2014-05-05 15:47:38 <chill> howdy
433 2014-05-05 15:47:42 <survic> the block chain doesn't store messages. some people shove them in, but they're not meant to be there.
434 2014-05-05 15:47:56 <tyrick> I am reading all this from http://www.righto.com/2014/02/ascii-bernanke-wikileaks-photographs.html
435 2014-05-05 15:48:08 <tyrick> survic: I am not asking if they are meant to be in there or not
436 2014-05-05 15:48:21 <tyrick> survic: I am trying to understand how they got in there
437 2014-05-05 15:48:25 <sipa> there are various ways to do so
438 2014-05-05 15:48:26 <kinlo> survic: most of those are from coinbase, not from OP_RETURN
439 2014-05-05 15:48:38 <kinlo> most pools mark their blocks
440 2014-05-05 15:48:41 <survic> coinbase messages are fine, they're just used to advertise pools.
441 2014-05-05 15:48:50 <survic> or quote the bible.
442 2014-05-05 15:48:51 <sipa> most just use fake pubkey hashes
443 2014-05-05 15:48:58 <sipa> burning coins
444 2014-05-05 15:49:23 <tyrick> But wouldn't you need to 'dehash' the key to retrieve the original message?
445 2014-05-05 15:49:28 <sipa> no
446 2014-05-05 15:49:36 <survic> hex encoded ascii.
447 2014-05-05 15:49:45 <sipa> the point is that these are not actual hashes
448 2014-05-05 15:49:46 <tyrick> oh, wow. I see
449 2014-05-05 15:49:52 <sipa> they are messages
450 2014-05-05 15:49:53 <tyrick> so it isn't a real address at all
451 2014-05-05 15:49:57 <sipa> indeed
452 2014-05-05 15:50:00 <chill> Can anyone recommend some reading to learn about best practices for integrating bitcoin with a web application (nodejs)?
453 2014-05-05 15:50:06 <kinlo> depends on your definition of a real address :p
454 2014-05-05 15:50:08 <survic> nope. the funds can't be spent and just clog up the UXTO
455 2014-05-05 15:50:17 <tyrick> weird
456 2014-05-05 15:50:19 <sipa> most likely :)
457 2014-05-05 15:50:36 <kinlo> should you be able to find a private key that generates a public key that happens to hash to a value that is exactly those letters...
458 2014-05-05 15:50:51 <survic> then we have bigger problems than the UXTO set.
459 2014-05-05 15:51:00 <kinlo> so theoretically it is possible, but chances are much higher that I'd win the lottery every week from now on
460 2014-05-05 15:51:01 <archrs> lol!
461 2014-05-05 15:55:19 <chill> Has anyone had experience setting up a VPS with bitcoind? Is that what I should be doing if I want my web application to send/receive funds programmatically?
462 2014-05-05 15:56:13 <justanotheruser> chill: are you running a VPS service?
463 2014-05-05 15:56:20 <ajweiss> chill: look into bitcore
464 2014-05-05 15:56:21 <justanotheruser> Or paying for one
465 2014-05-05 15:56:47 <sipa> ajweiss: what does bitcore have to do with bitcoind?
466 2014-05-05 15:57:07 <justanotheruser> chill: bitcore or just good old fashioned RPC
467 2014-05-05 15:57:41 <chill> RPC to what?
468 2014-05-05 15:57:48 <ajweiss> he was asking questions about building webapps with bitcoin with node.js and all the rest...   it would make more sense to use something like bitcore than to run bitcoind  (other than to have a few running to support the network)
469 2014-05-05 15:57:49 <chill> a bitcoind instance that I set up on a server?
470 2014-05-05 15:58:09 <chill> ok, i'll check out bitcore
471 2014-05-05 15:58:10 <chill> thanks
472 2014-05-05 15:58:13 <justanotheruser> chill: ya
473 2014-05-05 15:58:50 <chill> i've been having a hard time finding non-sketchy looking information about best practices for integrating bitcoin with web apps
474 2014-05-05 15:59:39 <archrs> "best practices"
475 2014-05-05 16:00:22 <chill> right... that's just a jargony way of saying... what's the recommended way of doing this stuff
476 2014-05-05 16:00:40 <ajweiss> chill: ultimately what are you looking to do?
477 2014-05-05 16:00:45 <archrs> "Monitoring blocks and transactions. For this example you need a running bitcoind instance with RPC enabled."
478 2014-05-05 16:00:47 <archrs> says bitcore
479 2014-05-05 16:01:01 <archrs> still need bitcoind
480 2014-05-05 16:01:01 <chill> receive bitcoins as "withdrawals" to unique addresses per user
481 2014-05-05 16:01:08 <chill> errr "deposits"
482 2014-05-05 16:01:12 <chill> and then the opposite
483 2014-05-05 16:01:23 <archrs> you've seen django bitcoin, rite?  that's mostly serverside
484 2014-05-05 16:01:23 <chill> as securely / sanely as possible
485 2014-05-05 16:01:31 <chill> i use nodejs
486 2014-05-05 16:01:46 <chill> for this web app
487 2014-05-05 16:01:55 <chill> and have very limited experience with django/python
488 2014-05-05 16:02:09 <archrs> well
489 2014-05-05 16:02:13 <archrs> client side
490 2014-05-05 16:02:22 <archrs> you're going to have to open your bitcoin up if you try to use it like bitcore
491 2014-05-05 16:02:29 <archrs> and that's not desired, i'm guessing
492 2014-05-05 16:02:32 <chill> right
493 2014-05-05 16:02:39 <archrs> so an api that interfaces w/ rpc
494 2014-05-05 16:02:43 <chill> ideally it'd not be accessible remotely
495 2014-05-05 16:02:44 <archrs> seems the node way to go
496 2014-05-05 16:02:46 <chill> but via an SSH tunnel
497 2014-05-05 16:02:53 <archrs> well
498 2014-05-05 16:02:55 <archrs> ok
499 2014-05-05 16:02:55 <chill> from the web app server
500 2014-05-05 16:03:12 <chill> i don't need or want the client side to do anything with bitcoin directly
501 2014-05-05 16:03:18 <archrs> then
502 2014-05-05 16:03:19 <archrs> use an api
503 2014-05-05 16:03:32 <chill> what does that mean
504 2014-05-05 16:03:36 <chill> an API for what
505 2014-05-05 16:03:40 <archrs> make an api
506 2014-05-05 16:03:44 <chill> bitcoind, bitcore, something else?
507 2014-05-05 16:03:46 <archrs> and make ur api on the serverside use your vpn'd bitcoin rpcd
508 2014-05-05 16:03:52 <archrs> node.js api
509 2014-05-05 16:03:52 <chill> the web app is already done
510 2014-05-05 16:04:01 <chill> i am merely asking about the bitcoin integration itself
511 2014-05-05 16:04:28 <archrs> you dont want to code? >:)
512 2014-05-05 16:04:51 <chill> if necessary sure... but i'd imagine I'd screw something else if I tried to write wallet software
513 2014-05-05 16:05:00 <chill> this has to be a solved problem
514 2014-05-05 16:05:02 <survic> bitcoind isn't really suitable on it's own for integration.
515 2014-05-05 16:05:09 <archrs> you dont need to write wallet
516 2014-05-05 16:05:14 <archrs> you need to USE rpc to access the wallet
517 2014-05-05 16:05:37 <chill> right
518 2014-05-05 16:05:47 <survic> the built in wallet won't serve you for more than a couple of users. it doesn't scale.
519 2014-05-05 16:05:50 <chill> survic, if not bitcoind, then what should I use?
520 2014-05-05 16:05:56 <chill> ok
521 2014-05-05 16:06:02 <chill> what should I use then?
522 2014-05-05 16:06:06 <archrs> web browser > node js client > node js api > node js server > bitcoind RPC interface > bitcoind wallet
523 2014-05-05 16:06:11 <survic> there'a django-bitcoin, which is a wallet system on top of bitcoind.
524 2014-05-05 16:06:20 <survic> it's used and developed by localbitcoins.
525 2014-05-05 16:06:26 <chill> i see
526 2014-05-05 16:06:41 <chill> and I assume since it has django in the name , it is written in python?
527 2014-05-05 16:06:45 <survic> that way you're not slamming bitcoind with requests and having it lag out.
528 2014-05-05 16:06:48 <survic> that's corect
529 2014-05-05 16:07:05 <chill> I'll check it out
530 2014-05-05 16:07:07 <chill> thanks
531 2014-05-05 16:07:23 <survic> https://github.com/kangasbros/django-bitcoin
532 2014-05-05 16:07:28 <archrs> that's the one
533 2014-05-05 16:07:42 <chill> great, thanks
534 2014-05-05 16:07:46 <archrs> but
535 2014-05-05 16:07:49 <archrs> it's not a python wallet
536 2014-05-05 16:07:53 <archrs> it's another interface to bitcoin rpc
537 2014-05-05 16:08:04 <archrs> just fyi
538 2014-05-05 16:08:13 <chill> right, the interface itself is written as an abstraction / interface to bitcoind, right?
539 2014-05-05 16:08:19 <survic> I was given the impression that it was an external wallet
540 2014-05-05 16:08:35 <survic> I could very much have been mistaken
541 2014-05-05 16:08:38 <archrs> well ok survic
542 2014-05-05 16:08:52 <archrs> youre not mistaken
543 2014-05-05 16:09:01 <archrs> imo
544 2014-05-05 16:09:44 <chill> i also found https://github.com/freewil/node-bitcoin
545 2014-05-05 16:09:52 <chill> which is a node interface to bitcoind it looks like
546 2014-05-05 16:10:05 <chill> in either case it looks like I have to set up and manage a bitcoind instance
547 2014-05-05 16:10:26 <survic> indeed. using an external service like blockchain.info's API is risky.
548 2014-05-05 16:10:34 <chill> gotcha
549 2014-05-05 16:10:47 <chill> so I'll definitely want to / have to download the full blockchain with bitcoind?
550 2014-05-05 16:10:50 <maraoz> thoughts on this stealth address implementation via BIP32 idea? http://www.reddit.com/r/Bitcoin/comments/24s8hr/bitcoin_extended_addresses_merge_avoidance_and/cha4nqw
551 2014-05-05 16:10:58 <survic> it's down more often than not, and it doesn't seem to be very reliable in it's information even when it is up.
552 2014-05-05 16:11:26 <maaku> guys take this to #bitcoin -- keep the channel clear for developers
553 2014-05-05 16:11:46 <survic> chill: you'll want to download the bootstrap.dat file and the bitcoin daemon to get started quickly. 20GB of space for the blockchain, at least 1GB of memory, an extra 20GB for temp storage if you use the bootstrap.
554 2014-05-05 16:11:54 <survic> chill: lets take this to #bitcoin.
555 2014-05-05 16:12:35 <chill> survic: And I thought this channel was for talking about development relating to bitcoin apps too
556 2014-05-05 16:12:41 <chill> survic: *shrug*
557 2014-05-05 16:12:43 <survic> you thought wrong.
558 2014-05-05 16:13:38 <archrs> and your bitcoind w/ need to have transaction listing enabled
559 2014-05-05 16:14:01 <tyrick> In https://en.bitcoin.it/wiki/Script, it says that the sender must provide "a public key that, when hashed, yields destination address D embedded in the script"
560 2014-05-05 16:14:08 <tyrick> If so, it sounds more difficult than mining a block
561 2014-05-05 16:14:50 <survic> tyrick: very much so if they don't have the private key. significantly more difficult.
562 2014-05-05 16:17:43 <tyrick> How does the private key help?
563 2014-05-05 16:18:41 <survic> well, if you own the address coins were sent to, you can use your private key to make the public key, and sign for the output with the script asking for H(public).
564 2014-05-05 16:19:24 <survic> proving that you own it. if you don't own it you need to brute force the keys with a probability of 2^160 to one of getting it each time.
565 2014-05-05 16:20:15 <tyrick> Oh sure! but this says the SENDER must provide the public key?
566 2014-05-05 16:21:25 <survic> shouldn't do. the recipient must prove ownership, the sender has nothing to do with the output after it has been created. there's nothing they can do to recall it or modify it after that point (and it has confirmed).
567 2014-05-05 16:21:56 <tyrick> typo in doc?
568 2014-05-05 16:22:25 <survic> oh I misread
569 2014-05-05 16:22:44 <maraoz> tyrick: the sender must provide the public key hash (i.e. the address)
570 2014-05-05 16:22:48 <survic> to spend an output, you need to provide the public key that matches H(public), sure.
571 2014-05-05 16:23:14 <survic> the sender just needs to provide H(public), they usually don't even know the public key of the address they are sending to.
572 2014-05-05 16:23:14 <tyrick> Oh, I misread it too then
573 2014-05-05 16:23:35 <tyrick> I was wondering.  I never know it >.>
574 2014-05-05 16:23:43 <tyrick> That line could be cleaned up.  It is confusing
575 2014-05-05 16:24:09 <survic> the public key of a bitcoin address is only revealed when you spend (it's part of the transaction itself).
576 2014-05-05 16:25:08 <tyrick> Oh! I didn't know that.  I thought the network only cared about H(public)
577 2014-05-05 16:25:57 <survic> it only cares about it until it's time to spend. without the public key it would be impossible to verify the signature matches
578 2014-05-05 16:26:12 <tyrick> I see
579 2014-05-05 16:26:42 <survic> (there's actually ways around that, but we don't use them for anything except for signed messages. given a plaintext and a signature we can recover the public key in some cases)
580 2014-05-05 16:40:44 <mr_burdell> BIP0070 question: if I try to validate a certificate, am I only validating that it's signed, or validate that it matches the server domain?