1 2014-05-21 01:32:06 <kostaz> hi guys
  2 2014-05-21 02:15:02 <legerde> ryan-c: Im new around here, so if my answer is wrong, I am sorry.   But in order to get latest transactions, I use jsonrpc from python to get transactions, like this:
  3 2014-05-21 02:15:15 <legerde> ryan-c: from jsonrpc import ServiceProxy ryan-c: access = ServiceProxy("http://<user>:<pass>@127.0.0.1:8332"); access.getinfo(); ryan-c: latest_block = access.getblockcount(); ryan-c: block = access.getblock(access.getblockhash(access.getblockcount())) ryan-c: transaction = access.getrawtransaction(block['tx'][0]) ryan-c: decoded = access.decoderawtransaction(transaction)
  4 2014-05-21 02:16:18 <legerde> ryan-c: I assume that style of access gives me verified transactions as they show up.   I watch for the blockcount to change and then parse the transactions in the new block
  5 2014-05-21 02:16:49 <legerde> I am hoping someone can nod that this is a good method for getting the latest "verified" transactions.
  6 2014-05-21 03:03:32 <ryan-c> legerde: I'm looking for something where i don't have to poll, and i wan unconfirmed transactions. i figured out how to do it with bitcore
  7 2014-05-21 03:05:11 <legerde> Ok.  Just attempting to be helpful. :)  Cheers.
  8 2014-05-21 03:25:04 <jcrubino> is nlock time reinstated into the standard client protocol?
  9 2014-05-21 04:23:06 <shadowbroker> so i want my server to generate some key pairs. as i understand it, i dont need to run bitcoind. i can just randomly generate a 51-character string that starts with a '5' and i'm golden... is this true?
 10 2014-05-21 04:25:45 <Belxjander> shadowbroker: totally crap afaik
 11 2014-05-21 04:25:53 <shadowbroker> explain?
 12 2014-05-21 04:26:07 <Belxjander> shadowbroker: you need to start from a crypto key pair and then the addresses are generated from the key afaik
 13 2014-05-21 04:26:47 <shadowbroker> but you should be able to generate the public key from the private key, no?
 14 2014-05-21 04:28:00 <[\\\]> shadowbroker, do you know how pub/priv key stuff works?
 15 2014-05-21 04:28:05 <shadowbroker> only a conceptual understanding
 16 2014-05-21 04:28:19 <[\\\]> shadowbroker, there are a few js libraries available that will generate what you're looking for without having to run anything bitcoind
 17 2014-05-21 04:28:40 <shadowbroker> any suggestions?
 18 2014-05-21 04:29:13 <[\\\]> shadowbroker, you can run a local instance of this: https://github.com/brainwallet/brainwallet.github.com
 19 2014-05-21 04:29:18 <[\\\]> strip off the web stuff
 20 2014-05-21 04:29:33 <shadowbroker> it seems like i could just ssh-keygen XD any reason this wouldnt work?
 21 2014-05-21 04:29:40 <[\\\]> yes
 22 2014-05-21 04:29:51 <[\\\]> you really need to do more reading
 23 2014-05-21 04:29:53 <jrick> shadowbroker: WIF private keys also have the network identifier (which must match mainnet or testnet) and a checksum
 24 2014-05-21 04:30:00 <jrick> so you can't have just random crap in there
 25 2014-05-21 04:31:37 <shadowbroker> im not talking about generating a WIF, im saying generate the private key on its own
 26 2014-05-21 04:31:53 <shadowbroker> a WIF should be 52 characters i believe
 27 2014-05-21 04:32:46 <jrick> a private key is just a 256-bit number
 28 2014-05-21 04:32:57 <shadowbroker> exactly
 29 2014-05-21 04:33:05 <shadowbroker> so i dont see the problem? :/
 30 2014-05-21 04:33:11 <jrick> that's not the 5... string
 31 2014-05-21 04:33:50 <shadowbroker> "For private keys associated with uncompressed public keys, they are 51 characters and always start with the number 5"
 32 2014-05-21 04:33:56 <shadowbroker> am i not understanding this correctly?
 33 2014-05-21 04:34:33 <jrick> that's referring to wif and the length is dependant on whether it's representing a public key serilzied compressed or not
 34 2014-05-21 04:34:42 <shadowbroker> hm
 35 2014-05-21 04:34:48 <[\\\]> https://en.bitcoin.it/wiki/Elliptic_Curve_Digital_Signature_Algorithm
 36 2014-05-21 04:40:03 <shadowbroker> i still dont get the problem though. what about this signing algorithm prevents me from generating private keys? :/
 37 2014-05-21 04:40:53 <jrick> shadowbroker: I don't have links to bitcoind code but if you can read go, here is what I've been working on in my free time (a better WIF api for btcutil, the old one is on github but isn't very pretty) http://sprunge.us/YiRZ
 38 2014-05-21 04:40:57 <Luke-Jr> shadowbroker: why would you be prevented from generating private keys?
 39 2014-05-21 04:41:30 <jrick> hoping that can be merged in tomorrow after some oks
 40 2014-05-21 04:41:39 <shadowbroker> no idea
 41 2014-05-21 04:42:43 <Luke-Jr> shadowbroker: maybe you're misunderstanding the WIF format?
 42 2014-05-21 04:42:54 <Luke-Jr> shadowbroker: private keys do *not* "start with a '5'"
 43 2014-05-21 04:43:06 <jrick> wif is just a string encoding that's used for easy import and export
 44 2014-05-21 04:43:06 <shadowbroker> ya, i misunderstood the article i was reading
 45 2014-05-21 04:43:12 <Luke-Jr> ok
 46 2014-05-21 04:43:12 <shadowbroker> so if we back up a second
 47 2014-05-21 04:43:16 <shadowbroker> i can generate a random 256 bit number
 48 2014-05-21 04:43:21 <shadowbroker> and bam, thats a new private key
 49 2014-05-21 04:43:24 <Luke-Jr> sure
 50 2014-05-21 04:43:32 <Luke-Jr> note, in practice it's not the ideal way to do it.
 51 2014-05-21 04:43:43 <shadowbroker> of course. its cryptographically insecure :P
 52 2014-05-21 04:44:01 <Luke-Jr> well, it's secure as long as you use a secure random and only use the keypair once
 53 2014-05-21 04:44:12 <Luke-Jr> but you have to do it for every transaction
 54 2014-05-21 04:44:13 <Luke-Jr> and maintain backups
 55 2014-05-21 04:44:14 <Luke-Jr> etc
 56 2014-05-21 04:44:21 <shadowbroker> aye i understand that
 57 2014-05-21 04:44:53 <shadowbroker> but what i dont understand is why everyone is advocating the use of libs when i could just set ssh-keygen to generate a keypair using ECDSA
 58 2014-05-21 04:45:27 <Luke-Jr> because like I said, that method isn't ideal
 59 2014-05-21 04:45:43 <Luke-Jr> what is better, is generating a random *seed* once, then making private keys deterministically from that
 60 2014-05-21 04:46:14 <Luke-Jr> then you can backup that seed once, and your bitcoins are safe no matter how many transactions you do
 61 2014-05-21 04:46:20 <Luke-Jr> (https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki for the standard spec)
 62 2014-05-21 04:47:13 <shadowbroker> and if your seed gets compromised? :/ that sounds less secure than generating each key pair individually
 63 2014-05-21 04:47:30 <Luke-Jr> well, obviously you don't want your seed to get compromised!
 64 2014-05-21 04:47:39 <[\\\]> if 1 seed is compromised, then most likely many are compromised
 65 2014-05-21 04:47:47 <[\\\]> at least with 1 seed, its much easier to backup
 66 2014-05-21 04:47:52 <shadowbroker> true
 67 2014-05-21 04:47:53 <[\\\]> you could even print it out for safe keeping.
 68 2014-05-21 04:47:54 <Luke-Jr> right, that's no more likely than all your random keypairs beign compromised
 69 2014-05-21 04:48:20 <Luke-Jr> shadowbroker: furthermore, you can generate a neutered copy of the seed which cannot sign
 70 2014-05-21 04:48:29 <Belxjander> What is stopping you from generating a seed, generating a block of keys from it...generating a 2nd seed, and generating a seperate set of keys
 71 2014-05-21 04:48:37 <[\\\]> nothing.
 72 2014-05-21 04:48:42 <Belxjander> and then making a multi-signature setup requiring both sets of keys ?
 73 2014-05-21 04:48:45 <Luke-Jr> shadowbroker: so, you can have your wallet online and readily visible, but keep your private seed completely offline
 74 2014-05-21 04:48:48 <[\\\]> each seed could be used for say 10k addresses.
 75 2014-05-21 04:48:58 <[\\\]> and by addresses, I mean pubkeys
 76 2014-05-21 04:48:58 <Luke-Jr> Belxjander: nothing, that's the idea
 77 2014-05-21 04:49:13 <shadowbroker> alright...
 78 2014-05-21 04:49:18 <shadowbroker> that sounds fine and dandy, but what's your point?
 79 2014-05-21 04:49:23 <[\\\]> lol
 80 2014-05-21 04:49:39 <Luke-Jr> shadowbroker: point is pure random ECDSA keys are lacking :P
 81 2014-05-21 04:50:26 <shadowbroker> lacking for use? maybe. im talking about implementation here >.>
 82 2014-05-21 04:50:48 <Luke-Jr> lacking in security.
 83 2014-05-21 04:50:58 <shadowbroker> alright
 84 2014-05-21 04:51:01 <Luke-Jr> or safety, if you prefer
 85 2014-05-21 04:51:20 <Luke-Jr> but you can do multisig tricks like Belxjander suggested for even higher security too
 86 2014-05-21 04:51:27 <shadowbroker> yes
 87 2014-05-21 04:52:28 <shadowbroker> can this deterministic function be just about anything i want, or are there crypto libs that will do this for me, given a seed?
 88 2014-05-21 04:53:38 <Luke-Jr> shadowbroker: the latter. BIP 32 specifies the algorithms to use
 89 2014-05-21 04:53:40 <shadowbroker> or is that the link you provided earlier?
 90 2014-05-21 04:55:43 <Luke-Jr> yes
 91 2014-05-21 05:52:26 <shadowbroker> it seems like someone would have bothered linking this: https://github.com/bitcoinjs/bitcoinjs-lib
 92 2014-05-21 05:52:35 <shadowbroker> just sayin'...
 93 2014-05-21 06:23:39 <Codder7> Would anyone know how to compile the mobile bitcoin wallet ?
 94 2014-05-21 07:01:20 <mus1cb0x> is all crypto currencies operate with a blockchain?
 95 2014-05-21 07:01:25 <mus1cb0x> s/is/do
 96 2014-05-21 07:01:58 <wumpus> all *decentralized* cryptocurrencies do
 97 2014-05-21 07:02:28 <mus1cb0x> so then is the variance between them their format and protocol of interaction?
 98 2014-05-21 07:02:46 <mus1cb0x> (assuming there is variance. i know a lot of alt coins are just bitcoin code ripoffs)
 99 2014-05-21 07:03:42 <wumpus> the variance is mostly minor parameter and UI tweaking and change of the PoW algorithm
100 2014-05-21 07:05:37 <mus1cb0x> ok. ty for clearing that up for me
101 2014-05-21 07:05:44 <mus1cb0x> i wasn't sure how commonplace blockchains were
102 2014-05-21 07:06:10 <wumpus> some have also modified the network code to run over other overlay networks like I2P, but that's hardly a difference to the coin itself and will probably make it into bitcoind as well at some point
103 2014-05-21 07:07:50 <Luke-Jr> mus1cb0x: Bitcoin is really the only decentralised cryptocurrency once you ignore forks and scams
104 2014-05-21 07:08:02 <wumpus> blockchains are the single invention that brought us decentralized cryptocurrencies
105 2014-05-21 07:08:40 <mus1cb0x> what about ethereum? (i'm not here advocating, but it genuinely seems different enough to not be shamware)
106 2014-05-21 07:08:49 <wumpus> how those blockchains are structured and which signing/crypto is used could be wildly different (although in practice it is not)
107 2014-05-21 07:09:46 <Luke-Jr> mus1cb0x: Ethereum isn't really all that different in theory; mostly it's just smoke and mirrors fundraising. Also, this stuff is kind off-topic here..
108 2014-05-21 07:10:31 <mus1cb0x> well ty again for clarifying
109 2014-05-21 07:10:45 <wumpus> ethereum also uses a blockchain, but has a different scripting language and POW
110 2014-05-21 07:11:09 <mus1cb0x> so with ppl trying to use the blockchain for 'app persistent state', message passing etc, are there any plans for how to handle blockchain growth/pruning?
111 2014-05-21 07:12:21 <wumpus> the scripting language is there to add programmability to the logic to determine whether a transaction is allowed to send funds on
112 2014-05-21 07:14:16 <wumpus> I think the most promising idea there is commit-to-UTXO (chain state), it would allow nodes to fetch and verify parts of the chain with SPV-level security
113 2014-05-21 07:14:26 <mus1cb0x> my question is more about the growth of the blockchain. if ppl start to use the bitcoin blockchain for much more than transaction ledger, its size could get onerous for nodes. any ideas in place for handling that?
114 2014-05-21 07:14:52 <wumpus> bitcoin will likely at some point also switch to a different scripting system, although time will have to tell what is really useful there, experiments like ethereum are useful there
115 2014-05-21 07:14:55 <mus1cb0x> ah so partial blockchain representation while preserving integrity?
116 2014-05-21 07:15:10 <Belxjander> mus1cb0x: indexing and storage considerations?
117 2014-05-21 07:15:15 <mus1cb0x> yea
118 2014-05-21 07:15:36 <mus1cb0x> let's say bitcoin takes off in every way, could we have a 100GB blockchain in a few years?
119 2014-05-21 07:15:44 <mus1cb0x> that could cut out a lot of nodes
120 2014-05-21 07:16:43 <Belxjander> price of storage vs bandwidth?
121 2014-05-21 07:18:11 <wumpus> in preactice it seems that bandwidth is a larger issue than storage
122 2014-05-21 07:18:14 <Belxjander> I see no problem with a 100GB blockchain if given  a means of RAID or other continuious block storage being available
123 2014-05-21 07:18:38 <wumpus> bandwidth is expensive in some part of the world
124 2014-05-21 07:18:41 <mus1cb0x> any idea how many GB of bw hosting a full blockchain node currently consumes per month?
125 2014-05-21 07:18:54 <warren> 
ACTION looks

126 2014-05-21 07:19:04 <wumpus> storage is cheap and easy to import/export between countries so much more homogeneous
127 2014-05-21 07:19:21 <warren> hmm
128 2014-05-21 07:21:05 <warren> wumpus: #4185 (after squash) and #4205 are ready.  I'm eager to get them into nightly builds soon.
129 2014-05-21 07:21:17 <wumpus> warren: yeah
130 2014-05-21 07:21:40 <coryfields> wumpus: i'm afraid we might've underestimated the complications due to signing
131 2014-05-21 07:22:13 <wumpus> coryfields: well it sounded very complicated to me already
132 2014-05-21 07:22:24 <coryfields> i think i can put together a POC in a day or two, but it's going to get nasty
133 2014-05-21 07:22:32 <wumpus> coryfields: are you going to merge #4205 into your pull?
134 2014-05-21 07:22:39 <warren> wumpus: he wanted it separate
135 2014-05-21 07:22:51 <warren> coryfields: signing what in particular?
136 2014-05-21 07:23:15 <coryfields> i just wanted the PRs separate so that one wouldn't block another
137 2014-05-21 07:23:40 <coryfields> (i didn't click, i assume it's the win32 bump)
138 2014-05-21 07:23:43 <warren> I've extensively tested both, no reason to delay merging
139 2014-05-21 07:23:56 <wumpus> coryfields: it's the macosx bump
140 2014-05-21 07:24:04 <wumpus> oh wait it's not
141 2014-05-21 07:24:11 <wumpus> ok I understand now why they're seperate, sorry
142 2014-05-21 07:24:52 <wumpus> I thought warren created a pull on top of yours to upgrade the macosx qt version :-)
143 2014-05-21 07:25:03 <warren> I closed it
144 2014-05-21 07:25:14 <coryfields> he did at one point, i pulled that change into my branch
145 2014-05-21 07:25:18 <wumpus> windows should definitely be separate
146 2014-05-21 07:26:31 <coryfields> wumpus: do you have a copy of the osx signing key as well?
147 2014-05-21 07:26:34 <coryfields> or just gavin?
148 2014-05-21 07:26:43 <wumpus> I don't
149 2014-05-21 07:26:56 <coryfields> ok
150 2014-05-21 07:27:13 <coryfields> i've got a few crazy ideas brewing, i'm gonna sleep on em
151 2014-05-21 07:27:20 <warren> signing the dmg from linux?
152 2014-05-21 07:27:32 <wumpus> so uhm... I'm going to merge #4185, anyone against?
153 2014-05-21 07:27:33 <coryfields> warren: will squash tomorrow if wumpus is ok with the current status
154 2014-05-21 07:27:49 <warren> wumpus: just needs squash
155 2014-05-21 07:27:55 <wumpus> ok
156 2014-05-21 07:28:10 <coryfields> warren: at this point, i'd be ok with any deterministic sig as a first step
157 2014-05-21 07:28:40 <warren> coryfields: eh?  surely this is outside of gitian right?  (others can't reproduce it)
158 2014-05-21 07:28:45 <coryfields> basically we need a way to sign with the private key, detach the payload, and inject it with gitian
159 2014-05-21 07:28:55 <warren> why within gitian?
160 2014-05-21 07:29:13 <wumpus> no need to do it within gitian, otherwise everyone needs a signing key right?
161 2014-05-21 07:29:26 <coryfields> wumpus: re-read the above
162 2014-05-21 07:30:10 <warren> Not sure what the "inject it with gitian" part means.
163 2014-05-21 07:30:21 <mus1cb0x> what do ppl think of chain.com?
164 2014-05-21 07:30:35 <wumpus> anyhow if there is a way to go back from the signed executable to the unsigned one that matches gitian, that'd be already great
165 2014-05-21 07:30:53 <warren> (especially in a cross-platform way)
166 2014-05-21 07:30:57 <coryfields> someone (gavin) would have to manually sign and detach. at that point, the private key is no longer needed and the result can be used
167 2014-05-21 07:31:23 <warren> coryfields: still not clear what exactly that means
168 2014-05-21 07:31:40 <wumpus> oh sure a cross-platform way would be nice, but let's get something working before diving into other complications
169 2014-05-21 07:31:47 <coryfields> wumpus: i've considered that as well. that would likely take the shape of a small script inside the dmg that would strip that stuff out and display the original hash, to be checked against a known value
170 2014-05-21 07:31:52 <wumpus> this is a deeep rabbit hole
171 2014-05-21 07:32:11 <warren> you need to execute something in the dmg in order to get a hash?  doesn't sound great
172 2014-05-21 07:32:41 <warren> coryfields: sounds like we're ok with merging #4185 now, if you're too tired to squash it's ok tomorrow
173 2014-05-21 07:32:50 <warren> I'd like to get the nightly build testers on it ASAP.
174 2014-05-21 07:32:59 <coryfields> warren: that's one out of a few options i've come up with so far. i'm very open to ideas, my brain is pretty melted atm
175 2014-05-21 07:33:11 <wumpus> yeah, a tool that's usable from outside the dmg would be better, but if something inside the dmg is more realistic at first go for that
176 2014-05-21 07:33:27 <warren> something inside the dmg is no better than what we have now
177 2014-05-21 07:33:34 <wumpus> anyhow --l et's get 4185 squashed and merged
178 2014-05-21 07:33:39 <warren> the thing you execute could just lie =)
179 2014-05-21 07:33:51 <wumpus> warren: .. LOL, true
180 2014-05-21 07:34:04 <wumpus> print "The hash is 2837abcd"
181 2014-05-21 07:34:17 <warren> the bitcoin-qt binary within the dmg is what is modified by native signing?
182 2014-05-21 07:34:20 <coryfields> heh, the "thing you execute" would spit out the original file
183 2014-05-21 07:34:52 <wumpus> coryfields: I can do the squashing as well if you want
184 2014-05-21 07:35:05 <coryfields> i suppose it'd be possible to sneak a few nasties into the padding, but, not the most likely attack :)
185 2014-05-21 07:35:28 <mus1cb0x> what do ppl think of chain.com?
186 2014-05-21 07:35:36 <wumpus> mus1cb0x: take it to #bitcoin please
187 2014-05-21 07:35:43 <mus1cb0x> oh sorry
188 2014-05-21 07:36:11 <coryfields> wumpus: go for it if you'd like, i've got my tools put away for the night
189 2014-05-21 07:36:18 <coryfields> otherwise i'm happy to do it first thing tomorrow
190 2014-05-21 07:36:23 <wumpus> coryfields: yes just get some sleep :)
191 2014-05-21 07:36:44 <wumpus> I'm going to go through the entire process one, then squash it and merge it
192 2014-05-21 07:36:57 <coryfields> i've been reading in circles on apple dev sites for the past few hours :\
193 2014-05-21 07:37:10 <coryfields> sounds good, thanks
194 2014-05-21 07:38:10 <coryfields> a trend i've noticed: if you google 'how to fix xyz busted part in my macbook', the most common answers tend to be: "it's a few years old anyway, just get a new one"
195 2014-05-21 07:38:29 <warren> how dare you question the ghost of Jobs?
196 2014-05-21 07:38:31 <coryfields> likewise, trying to do something non-standard with osx tools tends to result in: "well, don't do that then".
197 2014-05-21 07:39:20 <wumpus> coryfields: well that's what rich people with little knowledge of computers tend to do, and that's a big target audience for apple :)
198 2014-05-21 07:40:11 <wumpus> contrast it with the linux approach where we try to salvage anything that can still do computation and use it in some way hehe
199 2014-05-21 07:40:42 <coryfields> heh
200 2014-05-21 07:41:21 <coryfields> i think a tool to inject the signed payload won't be too bad, just a few days of hackery. We just need to settle on a compromise for 0.9.2.
201 2014-05-21 07:41:26 <wumpus> but yes I suppose the official sites will be of little help especially when trying to do things in cross-platform ways, or when you want to do something that is a slight bit outside what mainstream users do
202 2014-05-21 07:41:31 <coryfields> I'll try to have something to propose tomorrow
203 2014-05-21 07:42:40 <coryfields> well at this point i've pretty much ruled out cross-platform. at least for now. I just want determinism back.
204 2014-05-21 07:42:49 <wumpus> it's the same for microsoft really, the mingw part is what adds most complication, all the docs apply to their own compilers and tool chains
205 2014-05-21 07:43:32 <coryfields> yep, same thing
206 2014-05-21 07:43:44 <coryfields> most hacks revolve around xcode
207 2014-05-21 07:44:07 <coryfields> luckily, though, xcode basically just wraps the cli tools, which are open-source
208 2014-05-21 07:44:27 <wumpus> yes that's nice
209 2014-05-21 07:45:49 <coryfields> ok, nnite
210 2014-05-21 07:45:53 <wumpus> night!
211 2014-05-21 08:20:35 <warren> wumpus: so ... 7 day delay for rc was yesterday.  ready for rc tomorrow?
212 2014-05-21 08:23:54 <wumpus> warren: as I've told Cory, I want to do the rc this week, doesn't need to be tomorrow
213 2014-05-21 08:25:17 <wumpus> warren: which tag have people been building in #4185?
214 2014-05-21 08:25:49 <warren> wumpus: the latest commit in 4185
215 2014-05-21 08:25:55 <warren> wumpus: all of it should just be squashed into the first
216 2014-05-21 08:26:06 <warren> wumpus: please see my comments in #4205
217 2014-05-21 08:26:28 <warren> stick with 5.2.1 because it's well tested and matching OSX, unless you want to revalidate 5.3.0 on both OSX and Windows
218 2014-05-21 08:26:35 <wumpus> yes, but to test determinism we need to target some well-defined tag
219 2014-05-21 08:26:52 <wumpus> for example 0.9.1 release
220 2014-05-21 08:27:13 <warren> oh
221 2014-05-21 08:27:13 <wumpus> targeting a random commit is a recipe for confusion
222 2014-05-21 08:27:22 <warren> you mean the master commit that it's on top of?
223 2014-05-21 08:27:23 <wumpus> anyhow, I'll just pick something then
224 2014-05-21 08:27:33 <coryfields> heh
225 2014-05-21 08:27:41 <coryfields> wumpus: i've been through this once already :)
226 2014-05-21 08:29:29 <coryfields> plenty of head-scratching earlier trying to figure out what to build
227 2014-05-21 08:29:54 <wumpus> hehe
228 2014-05-21 08:30:24 <wumpus> sigh, I just threw away my built dependency instead of copying it, gbuild should be more forgiving :(
229 2014-05-21 08:31:17 <coryfields> i suppose adding an '-o /output/path' would make too much sense? :)
230 2014-05-21 08:31:19 <wumpus> maybe keep the last N build results instead of throwing them away immediately
231 2014-05-21 08:31:22 <coryfields> (i constantly do the same thing)
232 2014-05-21 08:31:27 <wumpus> yes, sounds god
233 2014-05-21 08:31:30 <wumpus> good*
234 2014-05-21 08:31:50 <warren> 
ACTION looks at gitian source

235 2014-05-21 08:32:04 <wumpus> better than my solution
236 2014-05-21 08:32:11 <warren> eh... I don't have time for this
237 2014-05-21 08:32:23 <warren> 
ACTION adds to the list of nice-to-haves.

238 2014-05-21 08:32:27 <wumpus> on the other hand, outputting directly to the inputs directory is also a recipe for confusion
239 2014-05-21 08:32:46 <warren> build/out  build/out.1 build/out.2 ?
240 2014-05-21 08:32:50 <coryfields> wumpus: ultimately, gitian really needs to learn how to chain inputs->outputs
241 2014-05-21 08:33:06 <warren> coryfields: perhaps with Makefile? =)
242 2014-05-21 08:33:10 <wumpus> the gitian source is very simple and straightforward from what I've seen (I've did a few small changes)
243 2014-05-21 08:33:21 <wumpus> please don't overdesign, the perfect is the enemy of the good here :p
244 2014-05-21 08:33:40 <warren> gitian could also learn to bomb out immediately if a named input is missing
245 2014-05-21 08:33:48 <wumpus> I think a -o option makes a lot of sense, you'd still do a copy step but at least youd wouldn't lose the result
246 2014-05-21 08:34:19 <wumpus> warren: yeah
247 2014-05-21 08:34:28 <coryfields> fair enough
248 2014-05-21 08:34:34 <warren> Perhaps we could also save the expected hash of an output in descriptors. It would error out if the output is not what is expected.
249 2014-05-21 08:34:55 <warren> well, still output, but non-zero return
250 2014-05-21 10:05:54 <warren> wumpus: hmm, I guess we skipped each other
251 2014-05-21 10:06:06 <warren> wumpus: well, windows isn't doing 5.2.1 at all if you want 5.3.0?
252 2014-05-21 10:11:26 <wumpus> I just don't see the point on going to 5.2.1 in windows if there is a 5.3.0 out, I mean, as far as I know there are no known issues with 5.2.0 so we can stay with that for 0.9.2, and for 0.10 we can go to 5.3.0
253 2014-05-21 10:12:00 <wumpus> building the qt dependencies takes a long time, it needs to be tested, new problems could be introduced, so it's just safer to stay with our current qt dependency for windows
254 2014-05-21 10:12:37 <wumpus> having multiple versions of qt in use is unavoidable anyway; for Linux we need to stick with 4.6
255 2014-05-21 10:12:49 <warren> OK, agreed, closing the windows qt upgrade
256 2014-05-21 10:13:48 <warren> michagogo: if you want something simple to do, please handle qt-5.3.0 for bitcoin-0.10 windows
257 2014-05-21 10:16:39 <warren> adding OSX to the nightly builder now
258 2014-05-21 10:17:54 <warren> wumpus: ah, I'm an idiot, i see what you mean now.
259 2014-05-21 10:19:55 <Luke-Jr> wumpus: if there weren't any known issues with 5.2.0, there would be no 5.2.1 release o.O
260 2014-05-21 10:21:02 <warren> Luke-Jr: we're using a tiny subset of it
261 2014-05-21 10:21:27 <wumpus> Luke-Jr: so - is there anything in the 5.2.1 changes, on the windows platform, that makes it worth the trouble to do this ?
262 2014-05-21 10:21:39 <Luke-Jr> probably more trouble to find out, than to do it :P
263 2014-05-21 10:21:45 <wumpus> Luke-Jr: it's a compromise, something could be said for both upgrading and not upgrading
264 2014-05-21 10:22:00 <wumpus> heh
265 2014-05-21 10:22:29 <warren> the reason I upgraded it to 5.2.1 was because coryfields had a note about upgrading both and I wanted to remove one giant tarball from inputs/
266 2014-05-21 10:35:50 <warren> nightly builder just got stuck in the perpetual configure loop ...
267 2014-05-21 10:36:09 <warren> perhaps I need to add "If it's taking too long kill and try again."
268 2014-05-21 10:42:43 <wumpus> according to Cory it's not perpetual and will finish eventually
269 2014-05-21 10:44:03 <warren> I let it go an hour once
270 2014-05-21 10:58:03 <wumpus> this is sort-of nice http://www.reddit.com/r/Bitcoin/comments/262vvi/contribute_back_to_the_bitcoin_network_by/
271 2014-05-21 10:59:13 <warren> there has to be a ton of nodes at Digitalocean already
272 2014-05-21 10:59:37 <wumpus> sure, but it allows people with just a bitcoin wallet to fund a full node, instead of having to set it up themselves
273 2014-05-21 11:00:25 <GAit> sipa: remember the signature i was talking about yesterday passed via protobuf extention as suggested by Gavin? we were discussing internally whtether the signature should be x509 or ecdsa, putting it all down in a document for general review
274 2014-05-21 11:01:06 <wumpus> I suppose it could be further automated/decentralized by using something like Mikehearn's lighthouse that uses anyone-can-pay transactions
275 2014-05-21 11:02:13 <sipa> wumpus: i'd say the ability to run a full node yourself is more important than whether or not one actually runs :)
276 2014-05-21 11:03:00 <warren> falling asleep.  I think this master branch run will succeed and upload.  adding 0.9.2 branch when I wake up.
277 2014-05-21 11:03:09 <wumpus> sipa: sure, it is, but there are many people that are on network connections that simply don't allow running a full node (they get clogged, or it gets too expensive, etc).. or that technically cannot do it
278 2014-05-21 11:03:16 <sipa> right
279 2014-05-21 11:04:02 <wumpus> for the second set of users it would be possible to sell simple ARM-based boxes that run a full node automatically, but if your network connection cannot run one then you're out of luck
280 2014-05-21 11:06:54 <GAit> do you guys think it matters much if we just keep going with x509 since we are already using the payment protocol or is it smarter to use ecdsa, or both?
281 2014-05-21 11:06:57 <wumpus> I've been testing it the last few weeks, having quite some success with cubox-i boxes with a USB stick for block chain storage
282 2014-05-21 11:07:16 <GAit> guys and girls, that is
283 2014-05-21 11:07:48 <wumpus> x509 can do ecdsa, right?
284 2014-05-21 11:08:07 <wumpus> it's meant to be crypto algo independent
285 2014-05-21 11:08:51 <sipa> ecdsa yes, but i doubt secp256k1 is sufficiently standard
286 2014-05-21 11:09:08 <GAit> i did't explain myself correctly, what i meant is either x509 certificates or plain ecdsa with no cert chain, no CA etc. This is for an additional signature passed via a protobuf extention to the payment protocol
287 2014-05-21 11:10:04 <GAit> the people that will receive the signature already have to know you and trust you, you could pass the plain ecdsa pkey offline or via x509
288 2014-05-21 11:10:46 <wumpus> well the point of CA chains is that someone otherwise unrelated to you can check your key, if you don't need that, you could roll something of your own
289 2014-05-21 11:11:05 <sipa> x509 brings a huge amount of complexity
290 2014-05-21 11:11:44 <wumpus> yes that may not be worth it, on the other hand, some complexity exists for a reason and if you end-up reinventing things you may do it badly
291 2014-05-21 11:11:56 <GAit> right, so maybe plain ecdsa, and the public key/certificate for that can be passed to parties offline or via x509 on a normal ssled page
292 2014-05-21 11:17:19 <GAit> thanks for your input sipa  and wumpus
293 2014-05-21 11:20:08 <chichov> where can I find the VarInt definition in the code?
294 2014-05-21 11:24:35 <chichov> wondering if the code enforces the smallest possible VarInt for a given data size
295 2014-05-21 11:24:41 <sipa> yes
296 2014-05-21 11:25:15 <sipa> it's called CompactSize in serialize.h
297 2014-05-21 11:25:29 <sipa> there's a CVarInt as well there, but that's not used in the protocol
298 2014-05-21 11:27:10 <chichov> and if a smaller chunk of data is encoded with a bigger VarInt than intended, then the "non-canonical ReadCompactSize()" error is thrown, right?
299 2014-05-21 11:28:03 <sipa> since recently, indeed
300 2014-05-21 11:28:16 <chichov> when were those changes made?
301 2014-05-21 11:28:20 <sipa> 0.9 maybe
302 2014-05-21 11:28:53 <chichov> either way, then the VarInt definition I have in my spec is out-of-date and has to be corrected
303 2014-05-21 11:29:15 <sipa> because it doesn't mention the requirement of minimum length encoding?
304 2014-05-21 11:29:58 <chichov> yes, it states that a 9-byte VarInt can encode anything that is smaller-equal than an uint64_t
305 2014-05-21 11:30:08 <sipa> right, that's indeed wrong
306 2014-05-21 11:30:29 <chichov> noted, will include it soon
307 2014-05-21 12:36:14 <netg_> whats cory fields bitcointalk.org account?
308 2014-05-21 12:42:23 <wumpus> cfields
309 2014-05-21 12:43:44 <kinlo> so isn't there a good definition on the bitcoin protocol now?
310 2014-05-21 12:44:49 <kinlo> there was this guy on the mailinglist, it made me smile, as gavin/jeff said there would be sattelites doing bitcoin in space long before there would be a formal spec of the protocol
311 2014-05-21 12:44:52 <wumpus> kinlo: http://bitcoindev.us.to/en/developer-documentation
312 2014-05-21 12:45:20 <wumpus> there are also various other documents, but it depends on what you want to know
313 2014-05-21 12:45:33 <kinlo> formal specs :p
314 2014-05-21 12:45:45 <wumpus> see the source code
315 2014-05-21 12:46:20 <kinlo> see, that's what that pdf on the mailinglist was supposed to solve, at least that is how I see it
316 2014-05-21 12:46:28 <kinlo> to not receive that answer anymore :)
317 2014-05-21 12:46:32 <wumpus> but what is the issue?
318 2014-05-21 12:46:39 <dexX7> kinlo: which one?
319 2014-05-21 12:46:43 <pigeons> also there is a satelite coming pretty soon
320 2014-05-21 12:47:05 <wumpus> anyhow, if you like better documentation, write it, that's how it works here :p
321 2014-05-21 12:47:13 <kinlo> wumpus: no real issue :)
322 2014-05-21 12:47:21 <dexX7> http://enetium.com/resources/Bitcoin.pdf ?
323 2014-05-21 12:47:27 <kinlo> it just made me smile when I saw it
324 2014-05-21 12:47:39 <kinlo> dexX7: that's the one
325 2014-05-21 12:48:04 <wumpus> Saivann and David can always use help with their developer documentation project
326 2014-05-21 12:48:09 <kinlo> altough I doubt it is complete
327 2014-05-21 12:49:03 <cbeams> kinlo: care to share what you're up to? there are various efforts underway, but their relevance depends on what you specifically need.
328 2014-05-21 12:49:39 <kinlo> cbeams: nothing, was just commenting on a conversation which is now offscreen
329 2014-05-21 12:50:00 <wumpus> also 'protocol' is very wide, it could be about the network protocol, or the blockchain, or the payment protocol, etc etc :p
330 2014-05-21 12:50:45 <wumpus> that pdf is interesting
331 2014-05-21 12:52:20 <wumpus> cbeams: we should really get those efforts linked on the bitcoin.org site
332 2014-05-21 12:52:35 <wumpus> there is actually a lot of documentation out there, but it's hard to find
333 2014-05-21 12:53:23 <cbeams> yeah, the root page of the new developer-guide aims to be a kind of portal to that effect: http://bitcoindev.us.to/en/developer-documentation
334 2014-05-21 12:53:44 <cbeams> you'll notice that some of those links are marked as external.
335 2014-05-21 12:53:47 <wumpus> I linked that too a few lines before
336 2014-05-21 12:54:06 <cbeams> ah, I missed that.
337 2014-05-21 12:54:32 <wumpus> but yes, it's getting there
338 2014-05-21 12:54:40 <cbeams> did you have something different in mind? or do you just mean that we ought to add (more) links to that doc as appropriate?
339 2014-05-21 12:55:30 <wumpus> well for example that PDF linked above is interesting, someone writes it, but almost no one knows about it
340 2014-05-21 12:56:02 <cbeams> yeah. just ends up buried in the forum at some point.
341 2014-05-21 12:56:43 <cbeams> could consider adding a section, perhaps below what you see now at /developer-documentation, that links to some of these more esoteric or in-development, yet valuable resources.
342 2014-05-21 12:57:12 <cbeams> "Additional Resources" or some such
343 2014-05-21 12:57:38 <wumpus> yes that sounds like a good plan
344 2014-05-21 12:57:43 <wumpus> so people know what is underway
345 2014-05-21 12:57:51 <cbeams> I'll mention to the Saivann & David.
346 2014-05-21 12:58:03 <cbeams> *to Saivann & David
347 2014-05-21 12:58:06 <netg_> wumpus: thank you
348 2014-05-21 12:58:14 <wumpus> and don't start writing their own but cooporate on current projects
349 2014-05-21 12:58:22 <wumpus> cbeams: thanks
350 2014-05-21 12:59:11 <wumpus> I intend to update the 'Satoshi client operation' series on the forums to the new codebase at some point
351 2014-05-21 13:10:29 <ThomasV> https://en.bitcoin.it/wiki/Script says that OP_RETURN marks transaction as invalid. why?
352 2014-05-21 13:12:53 <cbeams> wumpus, kinlo: https://github.com/saivann/bitcoin.org/issues/131
353 2014-05-21 13:13:54 <wumpus> ThomasV: that's what makes OP_RETURN outputs unspendable
354 2014-05-21 13:15:33 <michagogo> 13:14:08 <warren> michagogo: if you want something simple to do, please handle qt-5.3.0 for bitcoin-0.10 windows <-- "handle"?
355 2014-05-21 13:15:59 <ThomasV> wumpus: thanks
356 2014-05-21 13:18:32 <maaku> ThomasV: because of a bug where OP_RETURN was able to be used to claim any output
357 2014-05-21 13:18:49 <maaku> the heavy-handed approach was taken of just making its presence invalidate the transaction
358 2014-05-21 13:18:55 <maaku> *script
359 2014-05-21 13:19:02 <michagogo> Well
360 2014-05-21 13:19:22 <michagogo> OP_RETURN was originally "return true"
361 2014-05-21 13:19:27 <michagogo> It was changed to "return false"
362 2014-05-21 13:19:35 <maaku> no, it was return top of stack iirc
363 2014-05-21 13:19:41 <ThomasV> that must have been quite early
364 2014-05-21 13:19:49 <michagogo> Ah
365 2014-05-21 13:20:04 <michagogo> ThomasV: of course
366 2014-05-21 13:20:10 <michagogo> By definition, something like that had to have been early
367 2014-05-21 13:20:22 <michagogo> Because fixing it was a hardfork
368 2014-05-21 13:21:05 <michagogo> Erm, actually, maybe not
369 2014-05-21 13:21:25 <michagogo> Hmm
370 2014-05-21 13:24:10 <wumpus> that must have been really early indeed, I don't remember it either
371 2014-05-21 13:24:36 <wumpus> I always assumed it was on purpose this way
372 2014-05-21 13:24:56 <ThomasV> I'm thinking about a serialization format for unsigned or partially signed transactions, that would also include data needed for offline signing, such as bip32 derivations. Would it make sense to write that data in place of the input script?
373 2014-05-21 13:25:09 <anton000> other than polling getrawmempool , any other way to get notfied of new seen transactions?
374 2014-05-21 13:27:01 <maaku> early 2010 i think, and soft-fork change
375 2014-05-21 13:27:49 <maaku> ThomasV: etotheipi (alan reiner) has basically done this and deployed it for Armory
376 2014-05-21 13:28:00 <maaku> I asked him to document it as it is more generally useful..
377 2014-05-21 13:28:21 <maaku> anton000: watching the logs
378 2014-05-21 13:28:22 <ThomasV> maaku: do you know how he has done it?
379 2014-05-21 13:28:31 <maaku> no, hence my request ;)
380 2014-05-21 13:28:42 <maaku> armory is open source of course
381 2014-05-21 13:29:25 <GAit> we submitted the PR for the bip70 aka payment protocol protobuf extention, https://github.com/bitcoin/bips/pull/65, keen on feedback :)
382 2014-05-21 13:29:48 <anton000> lol was looking for something much more elegant like... blocknotify lol
383 2014-05-21 13:30:07 <maaku> he was demoing the user interface for it at the conference and I had to stop him --- "wait wait what are those strings you're copying around?"
384 2014-05-21 13:30:14 <maaku> that was more interesting than what he was demoing lol
385 2014-05-21 13:30:29 <ThomasV> maaku: I didn't meet him at the conf, but I met with other developers and we talked about a BIP for that
386 2014-05-21 13:30:58 <GAit> do you think i should submit the PR to the dev mailing list or is this sufficient?
387 2014-05-21 13:31:06 <ThomasV> I also have my own format for electrum
388 2014-05-21 13:32:08 <ThomasV> but I guess something universal would be good
389 2014-05-21 13:33:02 <maaku> yes and I have my own format for the coinjoin stuff i've been messing with
390 2014-05-21 13:33:15 <wumpus> GAit: I think it makes sense to point to it on the mailing list, at least for non-trivial stuff
391 2014-05-21 13:33:16 <maaku> and hearn has his own format for the lighthouse app he is working on
392 2014-05-21 13:33:27 <maaku> a universal format would be very good
393 2014-05-21 13:34:53 <GAit> wumpus: i guess if i do it's probably best if I prepare some background context
394 2014-05-21 13:36:01 <ThomasV> the need to copy strings around is precisely the reason why I would like to see if we could extend the transaction serialization format, instead of messing with extra json fields
395 2014-05-21 13:36:10 <wumpus> GAit: that's always good
396 2014-05-21 13:36:26 <GAit> uh uh my first bitcoin-dev mailing list post
397 2014-05-21 13:37:15 <hearn> maaku: the format I use is just BIP70 wrapping the partial transactions. it’s nothing special
398 2014-05-21 13:37:31 <hearn> i’m not sure we need a general format for “partial txns”. normally there would be some more app-specific logic on top, no?
399 2014-05-21 13:37:58 <dhill> anyone know what Dain is?
400 2014-05-21 13:38:42 <jcrubino> is nlock time reinstated into the standard client protocol?
401 2014-05-21 13:39:27 <ThomasV> hearn: the idea was (again) to provide inter-wallet compatibility, this time for tx cosigning
402 2014-05-21 13:40:07 <GAit> hearn: when you get a chance could let me know what do you think about the extention PR? I remember you saying yesterday you were going to use it too  https://github.com/bitcoin/bips/pull/65 so it would be good to hear your thoughts (i'll try to wrap it up and submit it to the dev mailing list for more general view as suggested by wumpus)
403 2014-05-21 13:42:35 <hearn> GAit: hmm I don’t see your mail?
404 2014-05-21 13:42:39 <hearn> oh ok
405 2014-05-21 13:43:24 <hearn> GAit: yeah i just looked now. I think we may need to work on the process for BIP70 extensions a bit. like, it should be a new BIP, but then we probably should have a “living document” that accumulates all the BIPs into one coherent proto definition. i’m not sure we should use the extends mechanism in protobufs, even though it’s tempting
406 2014-05-21 13:43:26 <maaku> hearn: you are currently not doing anything requiring a special format, but you could benefit (e.g. by having co-signed pledges)
407 2014-05-21 13:43:54 <GAit> hearn: that's what gavin suggested yesterday. I was going to originally use the memo field and overload it with some encoded data
408 2014-05-21 13:44:13 <hearn> GAit: extending the protocol with new fields is the right way to go! the only question is which files they go in :)
409 2014-05-21 13:44:20 <jcrubino> hearn:  nlock time...   I read a btc stack exchange post of yours from 2011 saying nlock time is not part of the standard protocol, any changes?
410 2014-05-21 13:44:47 <hearn> jcrubino: yes it works. the meaning changed somewhat but it still works
411 2014-05-21 13:45:09 <GAit> jcrubino: it works and it is used by some services
412 2014-05-21 13:45:12 <maaku> jcrubino: nlocktime has always worked
413 2014-05-21 13:45:29 <hearn> GAit: it seems under specified. e.g. this “domain -> key” mapping business. why not just reuse certs like elsewhere? otherwise if the instant-confirmation-provider wants to ever change their keys, they have to track down everyone using them. no change of this ever working!
414 2014-05-21 13:45:33 <jcrubino> thanks
415 2014-05-21 13:46:26 <hearn> GAit: Also I think it’s not correct to sign the Payment message. Just sign the tx bytes. Because otherwise the user has to provide you with the memo they’re submitting and any other detail, even though it’s only really the txins that you’re attesting to
416 2014-05-21 13:47:09 <GAit> hearn: using x509 complicates things, we actually discussed that a few hours ago in the chan. I was of the impression that cert revoking doesn't really work well anyway and that this maybe simpler to implement, afterall the people requesting it need to know you in advance and can find that over https or offline
417 2014-05-21 13:47:57 <GAit> hearn: i thought of that but i also felt it could be useful to sign the refund address
418 2014-05-21 13:48:09 <GAit> but originally i was going to sign the txid
419 2014-05-21 13:48:16 <hearn> GAit: so I think …. separate BIP that embeds the new fields into BIP70, gives a rationale for them, etc like a “real” BIP would and then we can create a new page that just has the unified proto definition. also i’d suggest just picking the next available tag numbers rather than starting from 1000
420 2014-05-21 13:48:33 <hearn> GAit: what does signing the refund address solve?
421 2014-05-21 13:49:33 <GAit> it doesn't solve anything perhaps, sounds like it should go
422 2014-05-21 13:55:30 <GAit> hearn: thanks for the feedback. Not sure about the starting point, the BIP cleaerly says extenstions should be in that page starting from 1000 althogh i understand it is still a draft. I'm happy to adopt any updated process. In the meantime I'll update the spec based on the feedback on what to sign as i think you are right
423 2014-05-21 14:15:46 <hearn> GAit: sorry, went for lunch :)
424 2014-05-21 14:15:56 <hearn> GAit: let’s discuss the proposal further on the mailing list
425 2014-05-21 14:16:42 <GAit> no worries, we submitted an update to it to fix some of the things you already mentioned
426 2014-05-21 14:17:30 <GAit> do you think the context on github is enough for the mailing list? i posted a reply to schildbach which explains it a bit
427 2014-05-21 14:18:51 <hearn> all context should be in the BIP so future readers can benefit
428 2014-05-21 14:20:20 <GAit> hearn: BIP70 states it should not be a separate BIP but it should be a PR to the ext page
429 2014-05-21 14:20:49 <GAit> or you mean a referenced BIP for the whole multisig greenaddress out of band ?
430 2014-05-21 14:21:07 <hearn> yeah. it’s probably wrong :) i think that process works OK for private extensions and the like but we could do better for real public extensions
431 2014-05-21 14:21:13 <hearn> the purpose of the page is just to stop people accidentally colliding
432 2014-05-21 14:21:37 <sipa> i dislike encouraging modifying BIPs
433 2014-05-21 14:21:45 <sipa> BIPs exist to assign a unique identifier to an idea
434 2014-05-21 14:22:06 <sipa> if we're going to continually update things, you'll need "BIP70 as of april 2014" or something
435 2014-05-21 14:22:21 <maaku> GAit: depends on what you are doing. For Freicoin I am adding a "reference height" field as a BIP 70 extension. I doubt the bitcoin community cares about that
436 2014-05-21 14:22:41 <maaku> But if it is something of general interest to bitcoin developerrs, write a bip
437 2014-05-21 14:22:56 <maaku> Actually, write a post to the mailing list, get feedback, then write a bip
438 2014-05-21 14:23:40 <GAit> i think the BIP is a much longer thing than this extention, which we are implementing for things like lamassu integration for btc to cash
439 2014-05-21 14:24:02 <GAit> that is not to say there shouldn't be a BIP about it
440 2014-05-21 14:25:17 <GAit> I'll prepare somehting and submit the general idea to the mailing list, in terms of process perhaps it can be updates to i don't go blind on this one
441 2014-05-21 14:25:29 <GAit> s/updates/updated
442 2014-05-21 14:25:43 <hearn> sure. i’m writing some feedback now
443 2014-05-21 15:55:37 <skinnkavaj> So gavin wants to increase block size
444 2014-05-21 15:55:43 <skinnkavaj> When is this going to happen?
445 2014-05-21 15:55:52 <skinnkavaj> Sooner the better I guess..
446 2014-05-21 15:56:54 <michagogo> skinnkavaj: not in the immediate future