1 2015-02-16 02:02:17 <bad_industry> hola
  2 2015-02-16 02:02:40 <bad_industry> como puedo hacer para conseguir bitcoin
  3 2015-02-16 02:03:08 <bad_industry> hello
  4 2015-02-16 02:03:21 <bad_industry> some body help me
  5 2015-02-16 02:48:54 <fanquake> ;;blocks
  6 2015-02-16 02:48:55 <gribble> 343664
  7 2015-02-16 07:47:53 <gribble> The bot responds when you start a line with the ! character. A good starting point for exploring the bot is the !facts command. You can also visit the bot's website for a list of help topics and documentation: http://gribble.sourceforge.net/
  8 2015-02-16 07:47:53 <IeuanG-> ;;help
  9 2015-02-16 07:48:02 <gribble> To see a nice sortable web view of all factoids, click here: http://gribble.dreamhosters.com/viewfactoids.php?db=%23bitcoin-dev || To see a list of the most popular factoids, run !rank || To search factoids, run !factoids search <yoursearchterm>
 10 2015-02-16 07:48:02 <IeuanG-> !facts
 11 2015-02-16 07:48:10 <IeuanG-> !rank
 12 2015-02-16 07:48:11 <gribble> #1 pool (88), #2 gribble (8), #3 faq (5), #4 wiki (4), #5 blockchainsnapshot (4), #6 website (2), #7 bbe (2), #8 googlegroup (1), #9 freebitcoins (1), #10 faucet (1), #11 trade (1)
 13 2015-02-16 07:48:26 <gribble> No keys matched that query.
 14 2015-02-16 07:48:26 <IeuanG-> !factoids search iguana
 15 2015-02-16 07:48:39 <gribble> No keys matched that query.
 16 2015-02-16 07:48:39 <IeuanG-> !factoids search DogeCoin
 17 2015-02-16 07:49:35 <gmaxwell> IeuanG-: please take your conversation with the robot into private message.
 18 2015-02-16 08:18:07 <rabidus> gmaxwell: it should tell that when asking for help.
 19 2015-02-16 08:20:11 <gmaxwell> Patches accepted.
 20 2015-02-16 08:29:15 <rabidus> :)
 21 2015-02-16 09:12:14 <jitenm> hiya folks. could someone point me to a decent starting point for bip32 paper wallets? to save me starting from scratch?
 22 2015-02-16 09:20:41 <Luke-Jr> uh, bip32 itself?
 23 2015-02-16 09:21:01 <Luke-Jr> not sure what you're looking for
 24 2015-02-16 09:23:40 <jitenm> id like to be able to generate keys offline on a dumb machine/offline livecd. i could use something like the bip32.org codebase but am worried about entropy
 25 2015-02-16 09:34:30 <Luke-Jr> jitenm: so as a user? #bitcoin for that; I believe pycoin may do what you want
 26 2015-02-16 10:17:33 <jitenm> Luke-Jr: thanks
 27 2015-02-16 10:47:32 <michagogo> We distribute over BitTorrent now? ö
 28 2015-02-16 11:22:34 <wumpus> michagogo: that's one of the methods, yes
 29 2015-02-16 11:22:58 <wumpus> takes load off bitcoin.org as well as makes it possible for users who can't reach bitcoin.org to download it
 30 2015-02-16 11:24:23 <wumpus> not meant to deprecate 'centralized' downloads, just as extra option, just like linux distros do
 31 2015-02-16 12:04:22 <jgarzik> wumpus, I bet a magnet link can be constructed that fits in a tweet
 32 2015-02-16 12:04:31 <jgarzik> doesn't seem hard, I'll take a look
 33 2015-02-16 12:05:10 <jgarzik> wumpus, I agree the torrent naming "0.10.0" could be improved.  most torrent-building CLI tools permit changing that pretty easily
 34 2015-02-16 12:08:58 <fanquake> jgarzik mgnet.me might be one option
 35 2015-02-16 12:19:58 <wumpus> jgarzik: would be nice, although I dont know much about torrent specifics: would that lose current seeders/downloaders? maybe plan that for 0.10.1 / 0.11.0 if so
 36 2015-02-16 12:26:49 <jgarzik> wumpus, no.  peers use the "info hash" -- unique torrent hash -- to find each other
 37 2015-02-16 12:27:19 <jgarzik> wumpus, as long as the data itself doesn't change, you are OK.  You can rename the torrent itself, but not files/directories inside the torrent.
 38 2015-02-16 12:27:37 <jgarzik> wumpus, if it's the internal dir name, may wait for 0.10.1
 39 2015-02-16 12:28:20 <wumpus> right, makes sense
 40 2015-02-16 12:29:04 <wumpus> I'm not sure if the '0.10.0' is internal or external
 41 2015-02-16 12:29:39 <wumpus> but a shorter magnet URI is probably unrelated to that
 42 2015-02-16 13:11:48 <fanquake> heh, forgot the merge script doesn’t actually build the merged changes..
 43 2015-02-16 13:22:08 <wumpus> it does what it says on the tin, it merges :) you can provide a command it should execute though, that could include a full build
 44 2015-02-16 13:25:05 <fanquake> wumpus You can close #5723, it’s been merged into trivial-next
 45 2015-02-16 13:28:46 <wumpus> thanks
 46 2015-02-16 13:30:59 <wumpus> done
 47 2015-02-16 16:05:06 <bedeho> when computing the sighash for a tx, is it correct that no part of any scriptSig is included, regardless of sighash_type flag?
 48 2015-02-16 16:21:39 <wumpus> bedeho: correct as far as the signature doesn't sign itself (or other signatures), of course with P2SH the script is indirectly included as its hash is included
 49 2015-02-16 16:49:17 <timothy> hi, why new version (0.10.0) SHA256SUM is signed by "Wladimir J. van der Laan"?
 50 2015-02-16 16:49:26 <timothy> and not by Gavin Anderson like the old one
 51 2015-02-16 16:53:31 <stonecoldpat> iirc, he took over from gavin for maintaining the software sometime last year
 52 2015-02-16 16:55:17 <gavinandresen> Yes, Wladimir is Lead Maintainer of the project now
 53 2015-02-16 17:11:31 <bedeho> wumpus: right, but the entire scriptSig is not omitted, only signature? reading about OP_CODESEPERATOR processing for OP_CHECKSIG has me a bit confused.
 54 2015-02-16 17:12:07 <bedeho> I always assumed all scriptSigs were entirely dropped from the sighash, but that seems to not be correct?
 55 2015-02-16 17:19:08 <gavinandresen> bedeho : https://en.bitcoin.it/w/images/en/7/70/Bitcoin_OpCheckSig_InDetail.png  might be helpful
 56 2015-02-16 17:20:24 <wallet42> a big thank you to everyone who contributed toward 0.10.0!
 57 2015-02-16 17:23:41 <bedeho> gavinandresen: thanks! is there a very clear problem with just dropping the scriptSigs that this more complex approach solves?
 58 2015-02-16 17:25:56 <gavinandresen> bedeho: you’d have to ask Satoshi. I think it could be much simpler and still be secure, but I haven’t thought deeply about it.
 59 2015-02-16 17:26:18 <bedeho> ok, thanks
 60 2015-02-16 18:17:35 <cfields> petertodd: I've been thinking on stealth-ish addresses lately and I just re-read your ML post from a while back. By dropping some of the requirements (assuming that the txin contains a valid pubkey), a hashed shared secret could be used directly to derive a new derived scriptPubKey, without the need to communicate a separate nonce keypair. I would think that would give the ability to give out "permanant" donation addresses and such, while giving
 61 2015-02-16 18:17:35 <cfields>  up some of the other privacy goals.
 62 2015-02-16 18:19:44 <cfields> I suppose I'm curious to know how much you've thought about using a direct shared secret to derive the target destination, as opposed to the addition of the nonced key
 63 2015-02-16 18:20:36 <cfields> i assume there's a dead-simple reason no to that's staring me in the face :)
 64 2015-02-16 18:31:48 <Eliel> cfields: a hashed shared secret ... why is that different from a private key used as a nonce?
 65 2015-02-16 18:33:24 <cfields> Eliel: because the receiver could derive the same hashed shared secret without the sender having to communicate the nonce separately
 66 2015-02-16 18:34:28 <Eliel> where would the receiver derive the shared secret from?
 67 2015-02-16 18:36:48 <cfields> ECDH - hash(recv privkey * sender pubkey)
 68 2015-02-16 18:37:05 <cfields> same way the sender would generate it (but reversed ofc)
 69 2015-02-16 18:38:31 <cfields> i've sent/received some transactions this way as a test.. works with no issues. I just assume there's a bigger-picture reason that I'm missing for not going down that path.
 70 2015-02-16 18:44:01 <cfields> sorry.. the "recv" privkey there is the privkey that goes with the "permanant" posted pubkey. Not the one that's used for the actual transaction, as that obviously wouldn't yet be known
 71 2015-02-16 18:44:15 <maaku> cfields: point of stealth addresses is communication without a shared secret...
 72 2015-02-16 18:44:54 <prolifik4life> Please  house, can anyone help me out with bitcoin application development
 73 2015-02-16 18:45:26 <cfields> maaku: the shared secret in this case is derived, it doesn't have to be pre-communicated
 74 2015-02-16 18:47:57 <cfields> (i assume that was the argument you were making?)
 75 2015-02-16 18:53:36 <prolifik4life> Please could someone point me to the right direction on how to start building a bitcoin transaction monitoring for double spending in the bitcoin network?
 76 2015-02-16 18:55:52 <rnicoll> prolifik4life, you realise double spending is extremely rare, so most of the time it would be doing nothing? You could watch generated blocks for a fork and see if coins were sent to different addresses in blocks on either side of the fork
 77 2015-02-16 18:56:22 <cfields> I suppose I'll throw my thoughts together on a ML thread. Just wanted to see if there was any _glaringly_ obvious reasoning against the idea first.
 78 2015-02-16 18:59:04 <IAmNotDoritos> prolifik4life, https://github.com/bitcoinxt/bitcoinxt might be a good place to look
 79 2015-02-16 19:00:10 <dgenr8> congrats on .10, hard working devs. it's impressive
 80 2015-02-16 19:00:48 <Happzz> prioritisetransaction
 81 2015-02-16 19:01:17 <Happzz> i think there's a typo with this, this way or another
 82 2015-02-16 19:01:42 <stonecoldpat> cfields: i think bitcoin-wizards may be more appropriate for that discussion, you need to be a bit more clear about what you mean, although i've had a similar thought (if your thinking what I have been) for awhile
 83 2015-02-16 19:02:04 <Happzz> prioritysettransaction or prioritiestransaction or prioritizetransaction
 84 2015-02-16 19:09:22 <gavinandresen> Happzz: https://uk.answers.yahoo.com/question/index?qid=20080414022325AAbNjap
 85 2015-02-16 19:13:24 <Happzz> aight
 86 2015-02-16 19:17:16 <prolifik4life> Thanks rnicoll and IAmNotDoritos, I am very new to BItcoin development. In fact I only heard of it in my graduate class and I am working on it for a graduate project. Has to do with double spending. I intend to build a monitoring tool, just for a creative lookout for double spending, I am fully aware that is is not that common yet.
 87 2015-02-16 19:18:31 <IAmNotDoritos> prolifik4life, hearn wrote the code i linked
 88 2015-02-16 19:23:29 <hearn> bedeho: OP_CODESEPARATOR is legacy from an early buggy version of bitcoin
 89 2015-02-16 19:24:07 <hearn> prolifik4life: blockchain.info monitors double spends
 90 2015-02-16 19:24:19 <hearn> IAmNotDoritos: actually i didn't. gavinandresen and dgenr8 did. i just rolled it up into a downloadable release
 91 2015-02-16 19:25:01 <IAmNotDoritos> ok my mistake
 92 2015-02-16 19:27:49 <prolifik4life> Thanks hearn and IAmNotDoritos
 93 2015-02-16 19:31:12 <prolifik4life> Hey Hearn, I am a .Net developer, and I have downloaded a blockchain.Info nuget in a project I created in VS, is it going to help ease my problem?
 94 2015-02-16 19:49:59 <maaku> cfields: i'm not sure how that differs at all from stealth addresses
 95 2015-02-16 19:50:28 <cfields> maaku: see the discussion in -wizards
 96 2015-02-16 19:51:56 <maaku> oh i see you're pulling the pubkey from the input. i had missed that
 97 2015-02-16 19:52:32 <maaku> otherwise you'd be sending a pubkey rather than a nonce, so i didn't see the difference
 98 2015-02-16 19:52:50 <cfields> maaku: yes. the purpose (just as a thought experiment) is trying to get rid of the out-of-band communication
 99 2015-02-16 19:53:10 <stonecoldpat> well you can put the nonce as an op_return, so you dont need out of band for stealths normally
100 2015-02-16 19:53:29 <stonecoldpat> its just a difference source (so it isnt any different from a normal transaction), where stealth addressed transactions normally are
101 2015-02-16 19:53:49 <cfields> out-of-band was the wrong choice, i suppose. "get rid of extra communication".
102 2015-02-16 19:54:05 <sipa> is this the scheme you discussed with me previously?
103 2015-02-16 19:54:10 <gmaxwell> It was discussed previously in -wizards, even before stealt addresses. The problem with using the pubkey from an input is that you get a hideous coupling between the kinds of scripts you're allowed to use if you want to send to particular people.  ... I'd suggested instead that you get to choose, PT was of the opinion that having two ways to do it was complex enough that it would block deployment.
104 2015-02-16 19:54:20 <cfields> sipa: no, that one was complete garbage :)
105 2015-02-16 19:54:33 <sipa> ok :)
106 2015-02-16 19:55:14 <gmaxwell> ("It was", I mean DH addressing where you reuse one of the signing pubkeys)
107 2015-02-16 19:55:35 <cfields> gmaxwell: nothing that couldn't be fixed, worst case, with an intermediate transaction, no?
108 2015-02-16 19:55:52 <gmaxwell> It's also not very SPV compatible, as you may need to go three tx back to have an authenticated pubkey.
109 2015-02-16 19:56:51 <gmaxwell> cfields: intermediate transaction isn't a cheap fix. (not in terms of software complexity- consider all the cases you must handle, what happens if the first of the two goes through but not the second, or overhead.)
110 2015-02-16 19:57:09 <stonecoldpat> gmaxwell: so it wasnt done that way previously, due to the restriction on the types of scripts that could be used? (in this case, only pay-to-pubkey(hash)) can be used
111 2015-02-16 19:57:32 <sipa> or the first one gets malleated
112 2015-02-16 19:58:50 <gmaxwell> in any case it could just be optional, ... but then you still have the SPV issues. :( where you now need to hand people the prev inputs in order for them to tell what the outputs of a txn are.
113 2015-02-16 19:59:17 <cfields> gmaxwell: thank you, i had not considered that at all
114 2015-02-16 20:00:08 <gmaxwell> I'm cheating, since this was already discussed in the past. I'd certantly prefer it, if not for annoyances like this.
115 2015-02-16 20:00:13 <cfields> the other issues do seem like reasonable things to put up with realistically.
116 2015-02-16 20:01:16 <gmaxwell> another less important one is address reuse begats address reuse in that scheme.
117 2015-02-16 20:02:45 <cfields> gmaxwell: i assumed there would be a reasonably easy incrementing scheme that could be taken advantage of here. Or you just mean in general, that people would begin to think "this is my address, everyone send here" ?
118 2015-02-16 20:03:34 <gmaxwell> I mean, if key a sends to key b it will always come up with the same ephemereal key.
119 2015-02-16 20:06:44 <cfields> gmaxwell: well i had assumed that the ephemeral key would be seeded with as much deterministic noise as possible first, but i suppose there'd be no way to avoid it completely
120 2015-02-16 20:26:19 <rgenito> anyone know where i can look up information on "deterministic signing" for bitcoin 0.1 ?
121 2015-02-16 20:27:46 <sipa> rgenito: the release notes give some inforation
122 2015-02-16 20:27:56 <sipa> i can point you to the code if that's what you're asking
123 2015-02-16 20:27:58 <rgenito> sipa i'm looking at the release notes
124 2015-02-16 20:28:11 <rgenito> sure actually, i could probably figure it out from the code :D
125 2015-02-16 20:28:24 <rgenito> i'm trying to figure out if that means deterministic wallet :D hehehe
126 2015-02-16 20:28:29 <sipa> no
127 2015-02-16 20:28:37 <sipa> keys are still generated randmly
128 2015-02-16 20:28:44 <sipa> it's just the signatures that are deterministic
129 2015-02-16 20:29:10 <rgenito> ah ... if you sign the same tx twice you get the exact same signature for both? (chatting with a friend on this)
130 2015-02-16 20:29:53 <sipa> yes
131 2015-02-16 20:30:01 <sipa> though this is just signer-side
132 2015-02-16 20:30:12 <sipa> it isn't (and cannot) be enforced by the network
133 2015-02-16 20:33:18 <Luke-Jr> does anyone even have 0.1 code? O.o
134 2015-02-16 20:33:54 <sipa> Luke-Jr: he clearly means 0.10
135 2015-02-16 20:34:06 <Luke-Jr> perhaps, but it stil made me wonder <.<
136 2015-02-16 20:34:20 <sipa> i believe it's available online somewhere
137 2015-02-16 20:57:23 <cfields> gmaxwell: thanks for putting my mind to rest. my head's been spinning for the past few days trying to figure out why this approach wasn't taken. now i can move on :)
138 2015-02-16 20:57:25 <Luke-Jr> petertodd: should I wait for your RBF patch?
139 2015-02-16 21:23:43 <samgranger> Hey guys - I'm wondering if/how I can accomplish the following:
140 2015-02-16 21:24:34 <samgranger> Multiple people create and add funds to 1 wallet
141 2015-02-16 21:25:47 <samgranger> in a gambling situation - and a winner gets chosen (or multiple winners with different amounts) - and receive the funds that was meant for them
142 2015-02-16 21:25:56 <samgranger> is this possible with contracts somehow?
143 2015-02-16 21:26:34 <samgranger> preferably without a central server somewhere - fully decentralized would have my preference
144 2015-02-16 21:27:44 <hasha> you are asking in the wrong place. try #bitcoin for advice.
145 2015-02-16 21:29:50 <samgranger> ok thanks :) sorry about that
146 2015-02-16 21:36:59 <stevedekorte> samgranger: maybe you could construct a multisig tx that bet on the timestamp on of some N number of blocks in the future (closest wins)
147 2015-02-16 21:41:05 <stevedekorte> samgranger: players could meet in a bitmessage channel and eliminate the need for a casino, a rake or any rent taking middle man
148 2015-02-16 21:52:25 <samgranger> stevedekorte: Let's say I'd want to have a poker game though
149 2015-02-16 21:52:35 <samgranger> using mental poker
150 2015-02-16 21:52:55 <samgranger> http://math.arizona.edu/~mleslie/files/mp.pdf
151 2015-02-16 21:54:11 <samgranger> (for example)
152 2015-02-16 21:57:40 <samgranger> Would I need an oracle of some kind? Just wondering how I can get the funds to the winner(s) without having to trust anyone
153 2015-02-16 21:57:46 <samgranger> not sure if that's fully possible
154 2015-02-16 22:29:34 <stevedekorte> samgranger: is your goal a truly decentralized game or one where you are the casino taking a rake?
155 2015-02-16 22:30:08 <samgranger> fully decentralized
156 2015-02-16 22:30:09 <samgranger> no rake
157 2015-02-16 22:31:36 <stevedekorte> samgranger: ok, what motivation do you have that is not fulfilled by the timestamp game? poker with anonymous players is just another statistical analysis game afaics
158 2015-02-16 22:32:33 <samgranger> Well, with poker, you can decide how far you go
159 2015-02-16 22:32:46 <samgranger> and you have the bluffing part too
160 2015-02-16 22:32:46 <stevedekorte> what does that mean?
161 2015-02-16 22:33:02 <stevedekorte> that's also statistics
162 2015-02-16 22:33:11 <samgranger> it is, yes
163 2015-02-16 22:33:53 <stevedekorte> if more than two players are involved, I don't think there is any way to construct it to avoid cheating
164 2015-02-16 22:34:04 <samgranger> bit you can see what chances you have in each round - decide to fold or continue - more of a game feeling
165 2015-02-16 22:34:09 <samgranger> but I get where you'ew coming from
166 2015-02-16 22:34:41 <stevedekorte> samgranger: ok, so the illusion of more agency is the goal?
167 2015-02-16 22:35:08 <samgranger> yeah indeed
168 2015-02-16 22:35:50 <stevedekorte> samgranger: slot machines achieve that with theatrics
169 2015-02-16 22:36:52 <samgranger> Haha I know - but it's less fun
170 2015-02-16 22:37:23 <stevedekorte> samgranger: a bit like human voting systems
171 2015-02-16 22:38:38 <samgranger> but I could do a timestamp betting game first - but my main "concern" is how I can make sure that everyone that participates in a certain game get the correct funds - in a way where nobody can cheat - fully decentralized
172 2015-02-16 22:39:52 <stevedekorte> you just put that in the multisig tx - construct it with the timestamp guesses and have closest match's pubkey be used to spend it
173 2015-02-16 22:40:07 <samgranger> no trust involved - how can I get the payout to work
174 2015-02-16 22:40:36 <stevedekorte> samgranger: I think I just described that
175 2015-02-16 22:41:08 <stevedekorte> the participants just need to sign the multisig tx with their inputs
176 2015-02-16 22:42:49 <stevedekorte> the winner will be able to spend them after the deciding block count - though I may be misremembering if that info is available to a script - I recall a proof of non-mining system that worked in a similar way
177 2015-02-16 22:47:18 <samgranger> hmm I'll have to look into that then - but with multisig tx's, what happens if "2 people (actually just 1 person)" and another person participate in 1 round - can't the person acting as 2 just steal the coins?
178 2015-02-16 22:48:12 <samgranger> I really need to read into bitcoin script
179 2015-02-16 22:49:48 <samgranger> (I still need to learn quite a bit - but learning so much every day!!)
180 2015-02-16 22:52:55 <stevedekorte> samgranger: as long as bets are proportional to odds, it doesn't matter. The nearest timestamp bet should be between two parties but it has problems too due to the order of signatures. Using the hash of agreed on future block as a random number to pick a winner might be best.
181 2015-02-16 22:55:36 <samgranger> ok cool - thanks steve!
182 2015-02-16 22:56:20 <samgranger> I'll have to look into this some more tomorrow - thanks for your pointers & advise!
183 2015-02-16 23:25:50 <petertodd> Luke-Jr: if you have time to rebase my patch for eligius, that'd be awesome and would be a good way to have a second set of eyes on it, otherwise I can do it
184 2015-02-16 23:28:17 <petertodd> cfields: didn't I write that up in the ML post? pretty well known you can derive the shared secret through what's in a scriptSig - communicating the keypair separately was IIRC specifically mentioned in my ML post as having bettter privacy and flexibility, e.g w/ coinjoin and wallets using new transaction types, as why that was the chosen implementation
185 2015-02-16 23:29:10 <petertodd> cfields: oh, yeah, what gmaxwell said, lol :)
186 2015-02-16 23:31:56 <cfields> petertodd: thanks, i guess i missed that in the mail. I assumed that it was well-known, I just wanted to understand why it wasn't chosen. Got it now.
187 2015-02-16 23:33:12 <petertodd> cfields: yeah, things like stealth addresses are gigantic messes of tradeoffs :)
188 2015-02-16 23:36:09 <cfields> heh, no kidding