1 2014-08-10 01:06:18 <BlueMatt> ;;seen gavinandresen
  2 2014-08-10 01:06:18 <gribble> gavinandresen was last seen in #bitcoin-dev 4 days, 9 hours, 48 minutes, and 50 seconds ago: <gavinandresen> Anyway, if you're really and truly paranoid you should be using a multisig wallet so even if you're copy of bitcoin core is unsafe your coins are still safe.
  3 2014-08-10 01:10:18 <Luke-Jr> BlueMatt: please do not ask miners to run unverifiable binaries on their mining nodes…
  4 2014-08-10 01:10:32 <BlueMatt> Luke-Jr: I hope to god no one runs that on their mining nodes
  5 2014-08-10 01:10:34 <BlueMatt> oh god
  6 2014-08-10 01:10:54 <BlueMatt> it is, however, ideal to run on a rpi right next to your node
  7 2014-08-10 01:11:11 <Luke-Jr> I hope nobody is relaying through a rpi - kinda defeats the optimisation's purpose <.<
  8 2014-08-10 01:11:31 <BlueMatt> its very lightweight, as long as your bitcoind isnt there it shouldnt be tan issue
  9 2014-08-10 01:11:35 <BlueMatt> it doesnt use disk
 10 2014-08-10 01:11:41 <Luke-Jr> oh
 11 2014-08-10 01:11:46 <Luke-Jr> so it doesn't need a node at all?
 12 2014-08-10 01:11:50 <BlueMatt> no
 13 2014-08-10 01:11:52 <BlueMatt> it relays to a node
 14 2014-08-10 01:12:04 <Luke-Jr> aha, ok
 15 2014-08-10 01:12:05 <BlueMatt> it does no verification, just keeps a set of recently seen transactions and fills in the gaps where possible
 16 2014-08-10 01:12:46 <Luke-Jr> might send off a second email explaining this. I can see some naive people just running it on the main mining node :x
 17 2014-08-10 01:13:00 <gmaxwell> well you can compile it yourself at least.
 18 2014-08-10 01:13:12 <Luke-Jr> gmaxwell: there was only a binary linked in the email
 19 2014-08-10 01:13:32 <gmaxwell> Which email?
 20 2014-08-10 01:18:44 <BlueMatt> gmaxwell: to poolowners-ml
 21 2014-08-10 01:20:36 <BlueMatt> Luke-Jr: sent
 22 2014-08-10 01:38:05 <Luke-Jr> BlueMatt: thanks
 23 2014-08-10 03:03:46 <Coinality_> We are working on a bitcoin-based freelancer platform (Coinality.io) with multi-sig escrow but came across an issue: since escrow payments are final and cannot be adjusted for current market rate at the time of payout, both parties must accept price volatility if they elect to use escrow. This is problematic for long-term projects.
 24 2014-08-10 03:03:58 <Coinality_> Two solutions are: 1) Provide a strictly BTC-based economy where Contractor hourly rates are specified in BTC with no reference to fiat conversion value, or; 2) Hourly rates sepcified in fiat but escrow payments are split into weekly payments w/exchange rate recalculated at the time of each weekly payment. Thoughts?
 25 2014-08-10 03:04:52 <shesek> I was wondering about the same thing with a project I'm working on, Bitrated
 26 2014-08-10 03:05:31 <Coinality_> We're leaning towards weekly payments w/exchange rate recalculation, but it's a very difficult decision.
 27 2014-08-10 03:05:39 <shesek> The things I thought of was what you mentioned as (1), and having the buyer pay some extra to cover for volatility, getting back any extra at the end of the transaction
 28 2014-08-10 03:06:00 <shesek> so for example, instead of paying 1 BTC he would pay 1.2 BTC, which would cover for up to 20% swing
 29 2014-08-10 03:06:17 <shesek> and get back whatever is left after calculating the price at the time of releasing the payment
 30 2014-08-10 03:06:33 <Coinality_> But what if there is a larger than 20% swing? They have to deposit additional funds with another 20% buffer?
 31 2014-08-10 03:07:01 <shesek> the downside being, of course, that you require the buyer to have more funds available and to give up on some liquidity during the time of the transaction
 32 2014-08-10 03:07:33 <shesek> you could have them deposit more funds over time, yes
 33 2014-08-10 03:07:54 <shesek> but as swings could go both ways, I think its fair to determine ahead of time that the payment is only covering up to an X% swing
 34 2014-08-10 03:25:43 <uiop> Coinality_: i only did a quick cursory once-over of what you said, but sounds like a futures contract. they're marked-to-market daily.
 35 2014-08-10 03:26:33 <uiop> which is the main diff betw them and and a forward
 36 2014-08-10 03:26:47 <Coinality_> Oh interesting... how might that be implemented?
 37 2014-08-10 03:28:45 <uiop> if you're looking to implement this wholly within some crypto scheme, i'm not sure. but that's a good question
 38 2014-08-10 03:40:13 <Luke-Jr> Coinality_: consider also that project costs are often unknown in advance, so people using escrow really need to escrow more than the final cost anyway
 39 2014-08-10 03:42:08 <Coinality_> Very good point; we'll be encouraging Users to take advantage of our "Consultation interface" before committing to any projects in order to get a more accurate time/cost estimate.
 40 2014-08-10 07:08:43 <ben_vulpes> forgive me for ultra stupidity this evening, but if i want to use {armory,bitcoinrpc,*anything*} to scan the blockchain for all transactions to an arbitrary address, what tools should i be looking at?
 41 2014-08-10 07:09:05 <wumpus> insight
 42 2014-08-10 07:09:31 <ben_vulpes> wumpus: https://github.com/bitpay/insight ?
 43 2014-08-10 07:09:35 <wumpus> yes
 44 2014-08-10 07:09:54 <ben_vulpes> or, https://github.com/bitpay/insight-api ?
 45 2014-08-10 07:09:59 <ben_vulpes> k, thanks.
 46 2014-08-10 07:16:14 <ben_vulpes> so insight needs a complete blockchain on disk to function correctly - how does that work with ongoing blockchain downloads?
 47 2014-08-10 07:59:11 <wumpus> AFAIK it communicates with bitcoind to stay up to date
 48 2014-08-10 15:33:03 <jiffe> so I see in various pieces of code after a signature if generated it goes through a further process 'convert ASN.1-serialized signature to bitcoin-qt format', any idea what the purpose of this is?
 49 2014-08-10 15:34:27 <jiffe> it seems to try to tack on up to four different nV values and then run the result through the verification process in an attempt to obtain the signing key's public address
 50 2014-08-10 15:34:45 <sipa> you're talking about message signing?
 51 2014-08-10 15:35:04 <sipa> yes, that relies on key recovery
 52 2014-08-10 15:35:29 <sipa> however, every (message, ecdsa signature) pair has up to 4 possible recovered keys
 53 2014-08-10 15:35:43 <sipa> so we add 1 byte metadata to identify which key it is
 54 2014-08-10 15:36:16 <sipa> normal transaction signatures don't use this
 55 2014-08-10 15:36:37 <jiffe> I see
 56 2014-08-10 15:37:32 <sipa> if you implement ecdsa yourself, it's trivial to know what that recovery value needs to be directly
 57 2014-08-10 15:37:51 <sipa> but openssl's doesn't expose that, so we have to iterate to find it afterwards
 58 2014-08-10 15:38:03 <aschildbach> petertodd: ping
 59 2014-08-10 15:45:52 <btcdrak> petertodd is mia
 60 2014-08-10 15:50:22 <aschildbach> saivann: Hi Saivann!
 61 2014-08-10 15:51:18 <aschildbach> btcdrak: What does mia mean?
 62 2014-08-10 15:52:19 <btcdrak> missing-in-action: army term.
 63 2014-08-10 15:52:19 <sipa> missing in action
 64 2014-08-10 15:52:59 <btcdrak> think he's spending time with family atm. might be better to email him directly if it's about the dns-seeds
 65 2014-08-10 16:13:12 <MistaG> Are there any websites with charts showing transactions for a specific day?
 66 2014-08-10 16:30:51 <jiffe> sipa: what would I be looking for when implementing ecdsa to find that Nv value?
 67 2014-08-10 16:33:20 <sipa> i would suggest not reimplementing cryptographic primitives yourself, but that would be a case of "do as i say, don't do as i do"
 68 2014-08-10 16:34:49 <sipa> https://github.com/bitcoin/secp256k1/blob/master/src/ecdsa_impl.h#L167
 69 2014-08-10 16:36:40 <sipa> jiffe: the 1 bit is the oddness of the omitted R.y coordinate, the 2 bit is whether R.x was >= than the order of the curve (which is exceedingly unlikely to happen)
 70 2014-08-10 16:37:08 <sipa> in bitcoin message signatures, the header byte is 27 + ricid + 4*compressed
 71 2014-08-10 16:37:15 <sipa> for compressed keys we use bit 4
 72 2014-08-10 16:37:26 <sipa> as you need a differently serialized public key
 73 2014-08-10 17:13:33 <Guest64482> How is this a valid chainstate leveldb key: 63001c443c40b4c4db6a6ea598c31c8a5a637fcb51cf85116970d92903124?
 74 2014-08-10 17:13:57 <Guest64482> Hex 63 ix 'c', the rest of it doesn't appear to be a TX hash?
 75 2014-08-10 17:14:30 <sipa> why not?
 76 2014-08-10 17:15:07 <sipa> it's possibly byteswapped
 77 2014-08-10 17:15:27 <Guest64482> look it up... doesn't exist, nor the hex reversed version: 2431029d970691185cf51bfc37a6a5c8318c9a56e6adbc4b4403c441c0063
 78 2014-08-10 17:15:40 <sipa> it's usually shown in big endian (as a hex number), but stored in little endian
 79 2014-08-10 17:16:01 <sipa> remove the 63 at the end
 80 2014-08-10 17:16:46 <Guest64482> non-existent: blockchain.info/tx/2431029d970691185cf51bfc37a6a5c8318c9a56e6adbc4b4403c441c00
 81 2014-08-10 17:21:27 <sipa> can you find any other entries?
 82 2014-08-10 17:21:31 <Guest64482> sipa, the stackoverflow comment you made has been very helpful, but i'm not getting passed this. all the keys i'm getting from chainstate appear invalid. i'm not reading it correctly obviously
 83 2014-08-10 17:21:51 <Guest64482> (or blockchain index) for that matter
 84 2014-08-10 17:24:24 <sipa> strange
 85 2014-08-10 17:30:33 <Guest64482> e.g. another entry: 2eba1152f531901f743dd16c155d2ff4f2c61c884787f41f54c6c7e4c0063
 86 2014-08-10 17:40:59 <sipa> you're sure you're not looking at a testnet chainstate or something?
 87 2014-08-10 17:41:05 <sipa> what's in the 'B' entry?
 88 2014-08-10 17:44:35 <Guest64482> not testnet for sure. For 'B' value: c758304b58df93857c4071f88059f632ddfc608cf643a93a00000000
 89 2014-08-10 18:05:22 <sipa> that's only 56 characters... it should be 64
 90 2014-08-10 18:06:00 <sipa> and your txid was 59?
 91 2014-08-10 18:06:05 <sipa> should be 64 as well
 92 2014-08-10 18:06:29 <Guest64482> preaching to the quire ;-)
 93 2014-08-10 18:06:30 <Guest64482> value_value = it->value().ToString();
 94 2014-08-10 18:06:39 <Guest64482> std::cout << string_to_hex(value_value);
 95 2014-08-10 18:07:09 <Guest64482> it is the chainstate leveldb::Iterator
 96 2014-08-10 18:07:28 <Guest64482> 'it'
 97 2014-08-10 18:10:50 <sipa> eh
 98 2014-08-10 18:10:57 <sipa> are you sure? that seems pretty broken
 99 2014-08-10 18:11:51 <sipa> it->value().size()... what does that give you?
100 2014-08-10 18:12:52 <Guest64482> 32
101 2014-08-10 18:12:55 <sipa> there must be something wrong with your to hex function
102 2014-08-10 18:13:03 <sipa> as the txid you gave me has an odd number of characters
103 2014-08-10 18:13:12 <sipa> which can't possibly be the result of hex conversion
104 2014-08-10 18:14:03 <Guest64482> let me take another look at the hex function
105 2014-08-10 18:14:04 <sipa> i know!
106 2014-08-10 18:14:37 <sipa> you convert byte values below 16 to a single hex character instead of prepending a 0
107 2014-08-10 18:32:39 <wumpus> hehe
108 2014-08-10 19:37:45 <spike1> hi guys, I'm trying to use testnet but bitcoind isn't connecting to any peer on testnet
109 2014-08-10 19:38:10 <spike1> I'm using a custom -conf and -data-dir to isolate from usual bitcoin dir
110 2014-08-10 19:38:26 <spike1> am I doing something wrong ?
111 2014-08-10 19:39:23 <spike1> I hope I'm not asking in the wrong channel
112 2014-08-10 19:41:21 <Guest64482> thanks sipa! the value conversion to hex string was messed up. looking good now
113 2014-08-10 19:41:23 <Guest64482> http://blockexplorer.com/block/00000000000000003aa943f68c60fcdd32f65980f871407c8593df584b3058c7
114 2014-08-10 19:45:49 <wumpus> spike1: connecting to peers or not doesn't have anything to do with the location of your data directory or configuration file
115 2014-08-10 19:46:03 <wumpus> spike1: have you perhaps configured a proxy that doesn't work?
116 2014-08-10 19:46:14 <wumpus> spike1: anything with regard to network failures in debug.log?
117 2014-08-10 19:47:00 <wumpus> perhaps the bootstrapping went wrong, in that case it may help to manuallly add some peers
118 2014-08-10 19:47:58 <wumpus> (I don't have any at hand right now, but someone in this channel may be able to help you with a working testnet node address)
119 2014-08-10 19:57:58 <andytoshi> i got "what needs to be hashed for a CHECKSIG on a standard pay-to-pubkeyhash" right on my second try :)
120 2014-08-10 20:00:50 <andytoshi> oh, no, third try -- the first time i forgot to add the sighash type entirely
121 2014-08-10 20:03:38 <michagogo> cfields: yes, for now
122 2014-08-10 20:09:07 <michagogo> 21:20:07 <andytoshi> ok, good to know. for now i'll just use secp256k1 :) <-- For now? WTF have you been using?
123 2014-08-10 20:18:02 <iwilcox> andytoshi: You mean that process depicted in https://en.bitcoin.it/wiki/File:Bitcoin_OpCheckSig_InDetail.png ?
124 2014-08-10 20:20:27 <andytoshi> michagogo: i had no ecdsa code at all
125 2014-08-10 20:20:36 <andytoshi> iwilcox: yup
126 2014-08-10 20:20:44 <michagogo> andytoshi: erm
127 2014-08-10 20:20:45 <michagogo> OH
128 2014-08-10 20:20:50 <michagogo> Do you mean libsecp256k1?
129 2014-08-10 20:20:55 <andytoshi> michagogo: lololol yes
130 2014-08-10 20:20:57 <michagogo> ahhh
131 2014-08-10 20:21:11 <michagogo> ...yeah, I misunderstood you
132 2014-08-10 20:21:33 <andytoshi> 
ACTION almost gave away his secret curve which matches secp256k1 on the points that have been used, but is much faster to compute with

133 2014-08-10 20:21:51 <michagogo> eh?
134 2014-08-10 20:22:23 <andytoshi> i'm kidding, i'm suggesting that there is another bitcoin-compatible curve out there that only i know about
135 2014-08-10 20:22:32 <iwilcox> insecp256k1 :)
136 2014-08-10 20:23:22 <iwilcox> Is someone profiling memory usage at the moment?  I've a dim memory of it coming up recently.  I ask because (admittedly from just two datapoints) I saw much lower peak and stable memory use with checkblocks=50 than =288, and I'm wondering whether it's worth doing a few runs and plotting /proc/.../status.
137 2014-08-10 20:24:09 <iwilcox> Seems to me checkblocks shouldn't have any effect on memory use once bitcoind has settled.
138 2014-08-10 20:51:55 <cfields> anddam: it's built with clang
139 2014-08-10 20:52:11 <cfields> wumpus: did you get your stuff built as you wanted?
140 2014-08-10 20:53:30 <michagogo> cfields: pong?
141 2014-08-10 20:54:59 <cfields> michagogo: my deps builder is ready for review, was wondering if you'd be interested in taking a look at the docs side of things before-hand rather than after-the-fact like usual :)
142 2014-08-10 20:55:47 <michagogo> cfields: maybe tomorrow -- not at my computer anymore tonight, omw to sleep
143 2014-08-10 20:55:58 <michagogo> But sure, sounds cool
144 2014-08-10 20:56:04 <cfields> sure
145 2014-08-10 20:56:07 <michagogo> PM me details?
146 2014-08-10 20:56:12 <cfields> will do
147 2014-08-10 20:56:19 <cfields> actually, #bitcoin-build
148 2014-08-10 20:56:37 <michagogo> Fine.
149 2014-08-10 20:56:58 <michagogo> (Just want it somewhere low-traffic for easy access later)
150 2014-08-10 20:57:08 <cfields> ok
151 2014-08-10 21:12:21 <ahmed_> anyone here know how to make ubuntu PPA's for bitcoin?
152 2014-08-10 21:14:52 <ahmed_> BlueMatt maybe?
153 2014-08-10 21:47:36 <dfsdf> i don't know if anyone is still maintaining it, it's was out of date last time i checked it
154 2014-08-10 21:48:40 <dfsdf> https://launchpad.net/~bitcoin/+archive/ubuntu/bitcoin
155 2014-08-10 21:49:26 <dfsdf> looks like it was recently updated
156 2014-08-10 21:49:30 <ahmed_> dfletcher: thats why I want to start making them
157 2014-08-10 22:49:18 <gmaxwell> TD-Linux: you had a libsecp256k1 question/comment? sipa may be around, though depending on what it is someone else might be able to answer
158 2014-08-10 22:52:28 <TD-Linux> well I ended up figuring it out. fyi I'm working on a port of libsecp256k1 to mini-gmp
159 2014-08-10 22:55:52 <gmaxwell> ah, thats probably a lot more useful than— say— just dumping out the prec table and then eliminating all the multiply code entirely (IIRC once you've got the prec table all you need is the gejge add), for embedded signing.
160 2014-08-10 22:56:41 <sipa> TD-Linux: cool!
161 2014-08-10 22:59:05 <sipa> does mini-gmp have all functions you need?
162 2014-08-10 23:13:15 <TD-Linux> sipa, it doesn't have the tdiv_qr and gcdext functions in mpn_ form, but does have them in mpz_ form.
163 2014-08-10 23:14:24 <TD-Linux> the easiest way to fix it would probably be to package the limbs into a mpz_t and then call the mpz functions
164 2014-08-10 23:14:37 <sipa> an earlier version of the gmp num implementation used mpz, but i changed it to an mpz one because it was slightly faster
165 2014-08-10 23:14:43 <sipa> maybe you can still find the old code
166 2014-08-10 23:15:01 <sipa> *to an mpn based one
167 2014-08-10 23:17:15 <TD-Linux> I also considered adding the mpn_ functions to mini-gmp. But I'm a bit wary of my understanding of the code
168 2014-08-10 23:42:08 <TD-Linux> ack. doing it this way means 8 heap allocations per division :/