1 2013-06-08 00:00:03 <Arnavion> You'd have to maintain the buffer yourself, got it
  2 2013-06-08 00:01:34 <Luke-Jr> I suppose if you reimplement the *whole* BSD sockets layer, you could emulate epoll on IOCP..
  3 2013-06-08 00:02:33 <matjeh> well, you can emulate IOCP/AIO with multiple blocking threads each with its read/write, and a bunch of semaphores. thats pretty much what the crappy POSIX AIO lib used to do
  4 2013-06-08 00:02:46 <matjeh> but noone wants that
  5 2013-06-08 00:03:01 <Luke-Jr> matjeh: I'd emulate it with epoll.
  6 2013-06-08 00:15:24 <drow-ubvm> anyone have a java implementation of gox socket with the callback function already made? ^^
  7 2013-06-08 00:17:18 <warren> Did the alt clients like bitcoinj previously implement the same v2 lock-in, or did it just rely on longest chain?
  8 2013-06-08 00:31:43 <shesek> Can I use bitcoind only for sending raw transactions, without having it download the blockchain?
  9 2013-06-08 01:06:32 <shesek> are "wallet import" formatted private keys always 51 characters long?
 10 2013-06-08 01:22:56 <Luke-Jr> shesek: no
 11 2013-06-08 01:23:16 <shesek> what's their length range?
 12 2013-06-08 01:23:44 <Luke-Jr> why do you assume a fixed length?
 13 2013-06-08 01:23:48 <shesek> I am validating the checksum, its for an earlier regex-based test
 14 2013-06-08 01:24:44 <shesek> I just need to distinguish between public key (in hex format) and private keys (in base58 format) with some minimal sanity checks
 15 2013-06-08 01:25:09 <shesek> The checksum is validated separately afterwards
 16 2013-06-08 01:27:32 <Luke-Jr> 51-52
 17 2013-06-08 01:27:44 <Luke-Jr> what are you doing with keys anyway?
 18 2013-06-08 01:29:07 <Luke-Jr> /^(?:5[\\dA-Za-z]{50}|[KL][\\dA-Za-z]{51})$/
 19 2013-06-08 01:29:46 <shesek> I'm working on some project that helps use escrow (m-of-n) transactions
 20 2013-06-08 01:30:12 <shesek> K and L is for compressed keys, right?
 21 2013-06-08 01:31:02 <Luke-Jr> IIRC
 22 2013-06-08 01:43:09 <Neozonz> Disc|http://www.reddit.com/r/litecoin/comments/1fwpgs/if_we_reach_200mhash_by_june_15th_1200am_we_will/
 23 2013-06-08 02:35:20 <Ry4an> mymutt
 24 2013-06-08 02:35:28 <Ry4an> (*sigh* sorry)
 25 2013-06-08 06:00:02 <dansmith_btc> Hello, I have this output script OP_HASH160 168d84b7bb0e0c36de927f83fda3c915fbe5a3f6 OP_EQUAL and an address to which this output was allegedly sent. How can I ascertain that this output was indeed sent to my address?
 26 2013-06-08 06:09:10 <Scrat> dansmith_btc: hm, base58check that hash? (skipping the first few steps)
 27 2013-06-08 06:11:47 <Scrat> https://en.bitcoin.it/wiki/Technical_background_of_Bitcoin_addresses
 28 2013-06-08 06:11:50 <Scrat> step 4 onwards
 29 2013-06-08 06:16:45 <Scrat> oh, b.i will tell you the 160 hash of an address
 30 2013-06-08 06:17:01 <Scrat> so you can compare
 31 2013-06-08 06:59:00 <tonikt> Should a node be announcing its own IP via "addr" messages, or it doesn't make a sense?
 32 2013-06-08 07:14:55 <ecoloco> Is it true that the Bitcoin had a low value all the time (less than 50$ / per Bitcoin)? That it is only in recent months that it have been worth 110$+ / per Bitcoin?
 33 2013-06-08 07:18:29 <SomeoneWeird> ecoloco, yes
 34 2013-06-08 07:18:37 <SomeoneWeird> it was once $0.00001 / btc
 35 2013-06-08 07:23:51 <duSn> the only problem is that there is no such thing as $0.00001 - the smallest us denomination is a mill - 1/10 of a penny
 36 2013-06-08 07:24:28 <ecoloco> Then I just have to wait until the value drops again (bubble bursts) and all my Bitcoin lose value by 50-100%
 37 2013-06-08 07:35:55 <matjeh> and then, buy buy buy!
 38 2013-06-08 07:52:41 <Luke-Jr> ecoloco: you're assuming it will :p
 39 2013-06-08 08:00:20 <ecoloco> Luke-Jr: assuming what?
 40 2013-06-08 08:41:28 <malexmedia> does anybody have any experience running a bitcoin node over a Tor circuit? i have 9 connections currently and i'm curious to know how long it might take to grow to a reasonable (30+?) connection count
 41 2013-06-08 08:42:40 <malexmedia> i have no problems opening a port on my firewall, etc. etc.. i am doing using -onlynet=Tor to academically experiment with routing all Bitcoin network over Tor
 42 2013-06-08 08:42:54 <malexmedia> just trying to see if the use of Tor will penalize a bitcoin user
 43 2013-06-08 08:43:37 <gmaxwell> malexmedia: you will never have more than ~8 unless you configure a hidden service (see Tor.txt in the docs directory)
 44 2013-06-08 08:46:27 <malexmedia> gmaxwell: thanks; i have 9 now due to following those instructions
 45 2013-06-08 08:46:57 <malexmedia> the reason for my question is because it seems that my connection count usually grows much faster when i'm connecting over the plain internet
 46 2013-06-08 08:47:53 <malexmedia> my ISP only provides IPv4 connectivity, but i have a working IPv6 tunnel set up at the router
 47 2013-06-08 08:50:05 <malexmedia> so academically, my question is, are Tor-restricted bitcoin users going to be penalized for using Tor by having a perpetually narrow "view" of the network?
 48 2013-06-08 08:50:29 <SomeoneWeird> well everything gets relayed
 49 2013-06-08 08:51:09 <malexmedia> yeah, although your latency will presumably be higher if you have fewer connections
 50 2013-06-08 08:52:10 <malexmedia> and if there aren't enough bitcoin nodes bridging the gap between Tor-only and Internet-only clients, that latency could be really high
 51 2013-06-08 08:52:49 <QQCrypt> https://bitcointalk.org/index.php?topic=228975.0  <-------??
 52 2013-06-08 08:53:02 <gmaxwell> malexmedia: the reason you aren't rapidly getting tons of conncetions is because there are generally enough.
 53 2013-06-08 08:53:52 <malexmedia> gmaxwell: is that why the minimum number of connections was reduced?
 54 2013-06-08 08:54:28 <gmaxwell> QQCrypt: I see nothing interesting in my immediate scroll back, and a quick grep turns up nothing.
 55 2013-06-08 08:54:38 <gmaxwell> QQCrypt: might just be some moron trying to manipulate the price.
 56 2013-06-08 08:54:40 <malexmedia> QQCrypt: 0_-
 57 2013-06-08 08:54:47 <QQCrypt> hrmm
 58 2013-06-08 08:54:53 <gmaxwell> malexmedia: the minimum number of connections?
 59 2013-06-08 08:55:40 <nsh> it's definitively not been discussed her in the last 24h (tampering with builds)
 60 2013-06-08 08:56:02 <nsh> *here
 61 2013-06-08 08:56:13 <malexmedia> gmaxwell: i recall it being 15 before
 62 2013-06-08 08:56:17 <malexmedia> now it's 8
 63 2013-06-08 08:56:23 <gmaxwell> malexmedia: You recall incorrectly.
 64 2013-06-08 08:56:27 <malexmedia> the number of connections before bitcoind stops trying to connect out
 65 2013-06-08 08:56:32 <malexmedia> oh ok
 66 2013-06-08 08:57:01 <malexmedia> btw, any idea why that number isn't configurable?
 67 2013-06-08 08:57:22 <gmaxwell> It is, you can reduce it by reducing your maximum connection count.
 68 2013-06-08 08:58:00 <gmaxwell> It can't be increased because 8 is almost certantly overkill already and people will ignorantly turn it up and unintentionally degrade the network for others if its just a totally free parameter.
 69 2013-06-08 08:58:01 <malexmedia> i mean why we can't configure the minimum number of connections before bitcoind stops trying to establish new outgoing connections
 70 2013-06-08 08:58:54 <malexmedia> i don't want to succumb to a naive "moar is bettar" mentality, but intuitively it seems that more connections should improve network strength
 71 2013-06-08 08:59:01 <malexmedia> up to a certain point
 72 2013-06-08 08:59:08 <malexmedia> i guess i just walked into your argument though
 73 2013-06-08 08:59:20 <nsh> intuitively, everything is a configuration options in gdb
 74 2013-06-08 08:59:24 <nsh> *option
 75 2013-06-08 08:59:48 <malexmedia> would you mind explaining why 8 connections is overkill?
 76 2013-06-08 09:00:03 <malexmedia> brb
 77 2013-06-08 09:00:19 <gmaxwell> malexmedia: because even four has an infinitesmal probablity of chance partitioning.
 78 2013-06-08 09:01:34 <gmaxwell> Basically the only sorts of attacks where larger numbers can help are ones where you'd need hundreds and the network can not support more than handfull of users running large numbers of connections.
 79 2013-06-08 09:01:46 <nsh> ("You are now leaving Intuition. Thank your for driving safely through our town.")
 80 2013-06-08 09:02:29 <nsh> gmaxwell, i think he meant in terms of the particular node's performance, not network integrity per se
 81 2013-06-08 09:03:26 <nsh> in any case, the optimum number of connections will depend on the distribution of link quality and various factors such as socket creation and teardown overhead, etc.
 82 2013-06-08 09:03:43 <gmaxwell> "performance"
 83 2013-06-08 09:04:00 <gmaxwell> Vague terminology detected.
 84 2013-06-08 09:04:28 <nsh> 
ACTION nods

 85 2013-06-08 09:04:53 <shesek> is it just me or blockchain.info's unspent api gives the wrong transaction hashes?
 86 2013-06-08 09:05:04 <shesek> see http://blockchain.info/address/1GxGURcpMjYiGoUNLAt6vArm4gGkjF3KGV and http://blockchain.info/unspent?active=1GxGURcpMjYiGoUNLAt6vArm4gGkjF3KGV
 87 2013-06-08 09:05:27 <gmaxwell> With perhaps the exception of mining, a second or two here or there??? what you might expect from suboptimal topology??? doesn't generally matter for bitcoin usage.
 88 2013-06-08 09:05:39 <shesek> each of them has different transactions
 89 2013-06-08 09:07:50 <shesek> oh, my bad. the bytes are just reversed
 90 2013-06-08 09:11:41 <skfax> Are there any good APIs which allow for client-side javascript to pull info on transactions sent to an address?
 91 2013-06-08 09:15:13 <malexmedia> back; thanks gmaxwell and nsh
 92 2013-06-08 09:15:14 <skfax> I guess the blockexplorer API is exactly what I want
 93 2013-06-08 09:17:54 <ne0futur> peerhaps you should look at bitping too
 94 2013-06-08 09:18:04 <ne0futur> https://github.com/MORA99/BitPing.Net
 95 2013-06-08 09:19:31 <skfax> ne0futur: cool. thank you
 96 2013-06-08 09:21:32 <skfax> sucks that the blockexplorer testnet has been down for a couple of weeks :/
 97 2013-06-08 09:26:19 <malexmedia> how many confirmations are required before getbalance shows a credit?
 98 2013-06-08 09:26:59 <SomeoneWeird> 6
 99 2013-06-08 09:27:07 <SomeoneWeird> 120 if it's immature
100 2013-06-08 09:28:45 <nsh> .t
101 2013-06-08 09:31:37 <wumpus> it will show the balance after 1 confirm, in case of normal transactions, in case of mined transactions indeed after 120
102 2013-06-08 09:34:33 <matjeh> is 120 derived empirically, or is it a number which is just 'large enough'?
103 2013-06-08 09:35:05 <matjeh> also, who the hell is is mining the testnet lol
104 2013-06-08 09:35:51 <duSn> 120 is (2^7)-8
105 2013-06-08 09:36:45 <matjeh> so my question then is, what is the significance of 2, 7, and 8?
106 2013-06-08 09:36:47 <matjeh> :D
107 2013-06-08 09:36:52 <malexmedia> matjeh: i've been mining on the testnet; only with about 250 ghash/sec though
108 2013-06-08 09:37:10 <malexmedia> i'm experimenting with all the various pieces of mining pool software
109 2013-06-08 09:37:49 <matjeh> malexmedia: not sure if serious or not
110 2013-06-08 09:39:36 <malexmedia> matjeh: ?
111 2013-06-08 09:40:06 <edcba> matjeh: it's magic, you can't explain it
112 2013-06-08 09:40:39 <edcba> ok now if you are talking about some numbers about confirmations there is the bitcoin paper for that
113 2013-06-08 09:40:39 <malexmedia> oh lol, i meant 250 mhash/sec
114 2013-06-08 09:40:51 <malexmedia> sheesh... i WISH
115 2013-06-08 09:41:37 <matjeh> that would be a good troll, point a few avalons at testnet
116 2013-06-08 09:41:41 <matjeh> no test coins for anyone
117 2013-06-08 09:41:47 <duSn> matjeh: just the secrets for you 2 is the third Fibonacci number, and the third and fifth Perrin numbers.   7 is the aliquot sum of one number, the cubic number 8 and is the base of the 7-aliquot tree.   8 is the first number to be the aliquot sum of two numbers other than itself; the discrete biprime 10, and the square number 49.
118 2013-06-08 09:47:19 <matjeh> main.h:static const int COINBASE_MATURITY = 100;
119 2013-06-08 09:47:25 <matjeh> and no explaination in the comment
120 2013-06-08 09:47:40 <matjeh> i love magic numbers
121 2013-06-08 09:48:04 <SomeoneWeird> so does satoshi & gavin
122 2013-06-08 09:48:16 <SomeoneWeird> they especially like it if you give them private keys
123 2013-06-08 09:49:21 <malexmedia> so, is #bitcoin always so heated?
124 2013-06-08 09:50:00 <malexmedia> it seems trolltastic
125 2013-06-08 09:50:06 <duSn> malexmedia: shidiots generate tons of heat
126 2013-06-08 09:50:22 <SomeoneWeird> yeaaaah i'm about to ban them
127 2013-06-08 09:50:42 <sipa> matjeh: 100 is the network rule, and it's probably overkill
128 2013-06-08 09:51:27 <sipa> matjeh: 120 as enforced by the client before spending is to prevent some edge cases around the boundary, but the 20 there is certainly overkill
129 2013-06-08 09:52:54 <matjeh> sipa: ok thanks
130 2013-06-08 09:53:35 <gmaxwell> 2 there would likely be more than enough. It basically avoids the case where you spend but your txn doesn't propagate well because the network hasn't caught up with the chain yet... but it hardly seems to matter.. 120 vs 102.. meh.
131 2013-06-08 11:23:52 <dansmith_btc> Is there somebody running (commercially or gratis) a bitcoind server with txindex=1 ,to which i could RPC and do getrawtransaction()?
132 2013-06-08 11:24:50 <sipa> is running it yourself that hard?
133 2013-06-08 11:26:05 <dansmith_btc> sipa, my app which users will run on blockchain-less machines needs getrawtx
134 2013-06-08 11:26:18 <sipa> what for?
135 2013-06-08 11:26:57 <dansmith_btc> to get raw information about a transaction - inputs, outputs, you know
136 2013-06-08 11:27:22 <sipa> that's a means and not a goal
137 2013-06-08 11:27:33 <sipa> what do you need the raw transaction data for?
138 2013-06-08 11:28:10 <dansmith_btc> sipa, to ascertain that a certain tx contains outputs as claimed by the counter-party
139 2013-06-08 11:28:54 <sipa> why can't the counterparty just show those transactions?
140 2013-06-08 11:28:56 <dansmith_btc> b.i, won't cut it because it has absolutely no respect for multisig addresses - b.i just mangles the multisig address
141 2013-06-08 11:28:59 <sipa> it must know them
142 2013-06-08 11:29:33 <CodeShark> I can think of plenty of reasons why b.i. won't cut it - but that's not one of them
143 2013-06-08 11:30:33 <tumak> dansmith_btc: electrum servers know all transactions if thats what you're asking
144 2013-06-08 11:30:36 <sipa> also, i'm very suspicious if you now are goig to rely on two centralized services to provide a solution that aima at reducing trust...
145 2013-06-08 11:31:05 <sipa> (not impossible, but there are certainly more weird cases to look at)
146 2013-06-08 11:31:38 <tumak> (and if this is about CC, then yes, using electrum-server is probably much better idea than just stock bitcoind)
147 2013-06-08 11:31:59 <CodeShark> CC?
148 2013-06-08 11:32:01 <dansmith_btc> party A send tx and before it gets included into a block party B has to have at least some assurance that tx has been send (doublespend is not an issue)
149 2013-06-08 11:32:33 <sipa> define 'sent' ?
150 2013-06-08 11:32:38 <tumak> CodeShark: various kinds of inchain property tracking via special txes
151 2013-06-08 11:32:58 <sipa> ah, colored coins
152 2013-06-08 11:33:11 <CodeShark> you could have just said colored coins :P
153 2013-06-08 11:33:11 <dansmith_btc> sipa, sent as sendrawtransaction and the tx is in a mempool
154 2013-06-08 11:33:17 <tumak> CC :)
155 2013-06-08 11:33:23 <sipa> dansmith_btc: whose mempool?
156 2013-06-08 11:33:57 <dansmith_btc> the server which hosts bitcoind, the server I asked about initially
157 2013-06-08 11:34:10 <tumak> dansmith_btc: relying on mempools is terrible idea :(
158 2013-06-08 11:34:25 <sipa> i'm still very confused about what you want to accomplish
159 2013-06-08 11:35:14 <tumak> probably reference txid of yet-to-be-included-in-block from yet another tx?
160 2013-06-08 11:35:36 <sipa> doing something like that requires proving that the transaction is valud too
161 2013-06-08 11:35:40 <tumak> (if thats the case, thats close to impossible to do in pure p2p fashion as thats why we have pow consensus in the first place)
162 2013-06-08 11:35:50 <sipa> which is borderline impossoble without running a full node yourself
163 2013-06-08 11:39:28 <dansmith_btc> well, thanks for the responses, I'll take that as a "No" to my initial question :)
164 2013-06-08 11:39:47 <CodeShark> I could set up a server that exposes getrawtransaction for you - but it'll cost you a bunch :)
165 2013-06-08 11:40:59 <CodeShark> I'd recommend you set one up yourself
166 2013-06-08 11:41:00 <dansmith_btc> CodeShark, sounds good. I'll get back to you later with a more concrete proposition.
167 2013-06-08 11:41:16 <CodeShark> ok :)
168 2013-06-08 11:41:38 <dansmith_btc> sure, I could do it myself, I just thought somebody is already doing it for a reasonable cost
169 2013-06-08 11:42:37 <CodeShark> for the right price I could even give you a full streaming API with queueing capabilities :)
170 2013-06-08 11:42:57 <CodeShark> and custom filters
171 2013-06-08 11:43:36 <dansmith_btc> my idea of the price is 1$ per 10000 getrawtx queries
172 2013-06-08 11:43:56 <CodeShark> how many queries do you expect to be running daily?
173 2013-06-08 11:44:07 <dansmith_btc> 10K a day
174 2013-06-08 11:44:52 <CodeShark> hmmm - find me a couple other people who also will be doing 10K a day for the same price and it's a deal :)
175 2013-06-08 11:44:57 <tumak> sipa: btw, wrt modular inverse for secp256k1, any idea why djb uses fermat's inv = x^(p-2) % p? i mean that thing must be horribly slow compared to bingcdext, yet it's there - https://github.com/agl/curve25519-donna/blob/master/curve25519-donna.c#L644
176 2013-06-08 11:45:16 <tumak> sipa: maybe the parallelized carry-less muls are super efficient on modern cpus?
177 2013-06-08 11:45:50 <sipa> tumak: i'm pretty sure it is horribly slow
178 2013-06-08 11:46:00 <tumak> sl k
179 2013-06-08 11:46:09 <tumak> so its just timing attacks paranoia, eh
180 2013-06-08 11:46:18 <sipa> tumak: but all curve25519 is constant-time, afaik, which is much harder to achieve with other algorithms than a precomputed ladder
181 2013-06-08 11:46:21 <CodeShark> inverse via exponentiation is constant time
182 2013-06-08 11:46:31 <CodeShark> that's the main benefit
183 2013-06-08 11:46:47 <CodeShark> it's simple and constant time
184 2013-06-08 11:46:56 <CodeShark> simple to implement, simple to verify
185 2013-06-08 11:47:07 <sipa> no edge cases
186 2013-06-08 11:47:18 <sipa> if it works once. it likely works for all input :)
187 2013-06-08 11:47:36 <CodeShark> right - no branching at all :)
188 2013-06-08 11:48:01 <sipa> tumak: and even if the parallellized carry-less muls are super efficient, they are super efficient for other algorithms than a fixed ladder too
189 2013-06-08 11:48:15 <sipa> (they like are)
190 2013-06-08 11:48:18 <sipa> (likely)
191 2013-06-08 11:48:29 <tumak> sipa: i tried porting your code carryless
192 2013-06-08 11:48:32 <tumak> ended up with radix 24
193 2013-06-08 11:48:33 <tumak> :(
194 2013-06-08 11:48:48 <sipa> haha
195 2013-06-08 11:49:03 <tumak> (also tried with floats)
196 2013-06-08 11:49:13 <tumak> btw, your radix 26 seems silly, you can do radix 30 for int64
197 2013-06-08 11:49:54 <sipa> hmm?
198 2013-06-08 11:50:35 <CodeShark> ya, wat?!
199 2013-06-08 11:50:52 <tumak> sipa: 9 words instead of 10
200 2013-06-08 11:51:01 <sipa> tumak: pull requests welcome
201 2013-06-08 11:51:35 <tumak> sipa: well, i'm asking if theres reason behind that, or its just residue from original implementation which used doubles
202 2013-06-08 11:51:51 <sipa> afaik i looked into using 9 words
203 2013-06-08 11:52:00 <sipa> and for some reason decided it wasn't possible
204 2013-06-08 11:52:10 <sipa> but i certainly spent much less time on the 32-bit version than on the 64-bit one
205 2013-06-08 11:52:33 <tumak> well, if you carry every mul, you can easily use just 63 bits, ie 5 words
206 2013-06-08 11:53:00 <CodeShark> not having to carry every mul is one of the main benefits of using this format
207 2013-06-08 11:53:00 <tumak> 30 bits make sense only if you do carry-less schoolbook multiplication (and handle carrys in following normalize)
208 2013-06-08 11:53:30 <sipa> you mean normalize before and after every multiplication?
209 2013-06-08 11:53:43 <sipa> so you are guaranteed to have no more than 30 bits in every limb
210 2013-06-08 11:53:52 <tumak> no, just carry is enough
211 2013-06-08 11:54:19 <sipa> right, i don't mean detect the >0xffffffff... case
212 2013-06-08 11:54:23 <tumak> sipa: i'll put up some prototypes later, i never got past the point of efficient reduction
213 2013-06-08 11:54:31 <tumak> as the magic must be rewritten from scratch for every different radix :/
214 2013-06-08 11:55:27 <sipa> tumak: i was still pondering another field implementation
215 2013-06-08 11:55:39 <tumak> incidentally, isnt there some sort of generator to quickly cough up formula for efficient reduction modulo generalized marsenne primes?
216 2013-06-08 11:55:59 <sipa> using 4x64 limbs (or 8x32), but with an overflow limb that is not used during multiplication
217 2013-06-08 11:56:17 <sipa> so you don't need a carry after every addition or multiplication with a constant
218 2013-06-08 11:56:22 <sipa> but do need one before multiplying
219 2013-06-08 11:57:14 <tumak> problem with overflows and carrys is that they suck horribly in sse code
220 2013-06-08 11:57:37 <tumak> ie there is no carry, and you cant parallelize it ... inevitably we'll have to use sse if we ever plan to beat gmp :)
221 2013-06-08 11:58:09 <sipa> and i suppose what you're suggesting is exactly that, but with 9x30 instead of 10x32
222 2013-06-08 11:58:13 <sipa> eh, 8x32
223 2013-06-08 11:58:57 <tumak> well, 9 words instead of 4-5 implies 75% more or so multiplications
224 2013-06-08 11:59:42 <tumak> (assuming karatsuba is not worth the trouble for 256 bits)
225 2013-06-08 11:59:51 <sipa> yeah
226 2013-06-08 12:00:13 <sipa> but if you have no native 64x64->128 multiplication, 4-5 limbs is just not an option
227 2013-06-08 12:02:58 <tumak> definitely need to write that modulo marsenne normalization generator
228 2013-06-08 12:03:08 <tumak> to try out different word sizes :)
229 2013-06-08 12:03:17 <nsh> 
ACTION orders the cliffnotes of this conversation

230 2013-06-08 12:03:22 <sipa> ?
231 2013-06-08 12:03:35 <sipa> anyway, i'm more interesting in 64-bit performance than 32-bit one
232 2013-06-08 12:03:52 <tumak> s/normalization/reduce/
233 2013-06-08 12:03:58 <nsh> (meaning i need to read more before half of it makes sense)
234 2013-06-08 12:04:31 <tumak> https://github.com/sipa/secp256k1/blob/master/src/impl/field_10x26.h#L47
235 2013-06-08 12:04:47 <tumak> sipa: this part, is written by hand for each different word size :/
236 2013-06-08 12:05:57 <sipa> well, originally just for 10x52 :)
237 2013-06-08 12:06:06 <sipa> grr, 5x52
238 2013-06-08 12:07:23 <tumak> sipa: btw, my ex-professor wrote nice paper about neat modinv http://users.fit.cvut.cz/~lorencz/clanky/1_New_Alg_Class_Inv.pdf
239 2013-06-08 12:07:43 <tumak> claims 30-50% faster than bgcdext, patented though :/
240 2013-06-08 12:07:50 <sipa> :(
241 2013-06-08 12:11:26 <nsh> 
ACTION tries to imagine being a mathematics professors and seriously entertaining the idea of patenting an arithmetic algorithm

242 2013-06-08 12:11:33 <CodeShark> 30-50% faster for what sized inputs?
243 2013-06-08 12:11:36 <nsh> *professor
244 2013-06-08 12:12:13 <nsh> maybe the hardware implementation is conscionably patentable
245 2013-06-08 12:13:28 <CodeShark> if it's 50% faster for inputs with millions of bits but slower for 256 bit inputs, it's useless for us
246 2013-06-08 12:13:39 <nsh> with the provision that royalties are automatically waved in developing countries and the authors are kicked once in the gonads for every half hour of lawyer-time
247 2013-06-08 12:14:23 <CodeShark> gmp uses this: http://gmplib.org/manual/Lehmer_0027s-Algorithm.html#Lehmer_0027s-Algorithm
248 2013-06-08 12:14:43 <CodeShark> which seems to work pretty nicely for the size of inputs we're using
249 2013-06-08 12:14:47 <tumak> CodeShark: the speed claims are for hardware implementation indeed
250 2013-06-08 12:15:00 <tumak> apparently lorencz is more pipeline friendly than lehmer
251 2013-06-08 12:18:20 <nsh> 
ACTION wonders why Lehmer's algorithm is described (on Wikipedia) in terms of high bases (?? = 1000 or ?? = 232)

252 2013-06-08 12:20:01 <CodeShark> nsh: 2^32 is a 32-bit workd
253 2013-06-08 12:20:07 <CodeShark> *word
254 2013-06-08 12:20:23 <CodeShark> i.e. the base of a 32-bit architecture
255 2013-06-08 12:20:29 <nsh> sure
256 2013-06-08 12:20:44 <nsh> oh, ok
257 2013-06-08 12:21:47 <nsh> CPU operations are dealing with operands of this size (or 64 bit)
258 2013-06-08 12:23:19 <nsh> 
ACTION looks to see if he still has copies of Knuth lying about

259 2013-06-08 12:23:55 <tumak> wrt base 30, btw http://pastebin.com/Xjftcwep
260 2013-06-08 12:25:31 <tumak> ( and ugly python code to try out different bases - https://gist.github.com/katuma/5735323 )
261 2013-06-08 12:36:49 <nsh> 
ACTION reads: http://www.imsc.res.in/~kapil/crypto/notes/node1.html

262 2013-06-08 12:50:47 <Tykling> given "walletnotify=/path/to/script.py %s" in .bitcoin/bitcoin.conf, what could cause bitcoind to not call the script when receiving a transaction ?
263 2013-06-08 12:52:48 <nsh> Tykling, the transaction does not affect the wallet?
264 2013-06-08 12:53:09 <Tykling> no, it does
265 2013-06-08 12:53:40 <Tykling> it just doesn't call the script, can't figure out why
266 2013-06-08 12:54:52 <Tykling> if I send a small btc amount to the wallet and do "bitcoind listtransactions" and get the txid from there, and call the script manually as the user running bitcoind, with the txid as parameter, it works as expected
267 2013-06-08 12:54:55 <sipa> Tykling: is it executable
268 2013-06-08 12:55:11 <sipa> ?
269 2013-06-08 12:55:19 <Tykling> yes it is
270 2013-06-08 12:55:28 <sipa> running as the same user?
271 2013-06-08 12:55:41 <Tykling> otherwise I wouldn't be able to run it manually, and yes, same user that runs bitcoind
272 2013-06-08 12:56:28 <Tykling> does bitcoind log anything to debug.log when trying to call the script ?
273 2013-06-08 12:56:35 <sipa> wi don't think so
274 2013-06-08 12:56:43 <sipa> may be a good idea to add that
275 2013-06-08 12:56:47 <Tykling> I am not sure if it is even trying to call it
276 2013-06-08 12:56:48 <nsh> +1
277 2013-06-08 12:56:52 <sipa> how do you obaerve the script doesn't run
278 2013-06-08 12:56:57 <sipa> *observe
279 2013-06-08 12:57:06 <Tykling> if I send a small btc amount to the wallet and do "bitcoind listtransactions" and get the txid from there, and call the script manually as the user running bitcoind, with the txid as parameter, it works as expected
280 2013-06-08 12:57:25 <Tykling> ..but not until I do it manually
281 2013-06-08 12:58:09 <nsh> Tykling, check if this happens:         printf("AddToWallet %s  %s%s\\n", wtxIn.GetHash().ToString().c_str(), (fInsertedNew ? "new" : ""), (fUpdated ? "update" : ""));
282 2013-06-08 12:58:38 <sipa> which bitcoind versiin?
283 2013-06-08 12:58:39 <nsh> if that happens, and the walletnotify argument is not empty, then the script should be called
284 2013-06-08 12:59:47 <Tykling> sipa: 0.8.1
285 2013-06-08 12:59:54 <Tykling> was it just added in 0.8.2 ?
286 2013-06-08 13:00:27 <Tykling> that would explain a lot
287 2013-06-08 13:00:47 <sipa> yes
288 2013-06-08 13:00:58 <sipa> 0.8.1 doea not have it yet afaik
289 2013-06-08 13:00:59 <nsh> heh :)
290 2013-06-08 13:01:15 <Tykling> hahah ok facepalm, thanks guys :)
291 2013-06-08 13:01:35 <Tykling> you dont want to know how long I have been troubleshooting this
292 2013-06-08 13:01:37 <Tykling> :)
293 2013-06-08 13:02:12 <nsh> just bill yourself for the time and use it as a tax writeoff
294 2013-06-08 13:02:29 <nsh> (disclaimer: i am not an accountant)
295 2013-06-08 13:02:33 <Tykling> haha :)
296 2013-06-08 13:03:39 <Tykling> if bitcoind warned about unrecognized config options I'd probably have noticed earlier
297 2013-06-08 13:07:13 <sipa> Tykling: yeah, we really need something like that
298 2013-06-08 14:01:20 <petertodd> Interesting: 8ff89472c457f97c30d5013382377107dd204bc734c1c6003cda9fceecd09842 and 510a0dc01a01ed7a8a9cfaca309669feea742fd419338ca1157454bd50340d69 Seems someone is using non-std tx's to commit to a set of parameters for a blub blub sum PRNG
299 2013-06-08 14:02:14 <petertodd> Has the text "tetazoo puntlist (sha3-512 of newline-separated hex hashes of seeds)" and "tetazoo puntlist (blum blum shub modulus, big endian)"
300 2013-06-08 14:02:49 <petertodd> Maybe an MIT thing? http://tetazoo.scripts.mit.edu/
301 2013-06-08 14:03:05 <nsh> what would you gain by memorializing a PRNG seed?
302 2013-06-08 14:03:46 <petertodd> Well, commiting to a PRNG seed in advance in a useful thing to do, actually putting the whole seed in though isn't.
303 2013-06-08 14:05:10 <petertodd> oh, this page on the site says something about a "puntlist": http://tetazoo.scripts.mit.edu/whoweare.php
304 2013-06-08 14:06:32 <nsh> 
ACTION wonders what a puntlist is and how it pertains to a floorplan

305 2013-06-08 14:07:37 <nsh> punt: skip class, avoid work, navigate waterways using long stick, impart momentum to an object using a limb, lay a wager, discard
306 2013-06-08 14:07:53 <petertodd> It's probably for some kind of random selection process; "punt: To lay a bet against the bank, as in roulette."
307 2013-06-08 14:08:14 <nsh> http://web.mit.edu/cmerrill/Public/tetazoo/punt/2010/puntListCode.py
308 2013-06-08 14:08:33 <nsh> yes, seems to be a selection process, i guess for tetazoo selecting people/rooms
309 2013-06-08 14:08:51 <nsh> to whatever nefarious nerddom activities are to be engaged
310 2013-06-08 14:08:58 <nsh> *for
311 2013-06-08 14:10:26 <petertodd> Interesting. They obviously understand just enough of the Bitcoin scripting system to be dangerous.
312 2013-06-08 14:10:46 <petertodd> Note the unneeded OP_DROP OP_TRUE at the end
313 2013-06-08 14:11:34 <nsh> maybe they're just future-proofing ;)
314 2013-06-08 14:12:37 <petertodd> Heh, we talk all the time about how we'd never make changes that turn spendable coins into unspendable ones, but actually the reverse is something we can't do either.
315 2013-06-08 14:13:01 <nsh> mmmm
316 2013-06-08 14:13:03 <petertodd> IE, even as a hard-fork, it would change the economic basis of the system.
317 2013-06-08 14:15:03 <nsh> 
ACTION nods

318 2013-06-08 14:16:41 <petertodd> Also, that's true even if the total quantity of coins remains the same if we're making what once was a genuine sacrifice of Bitcoins available again.
319 2013-06-08 14:17:53 <nsh> right, there are quite a few proposals predicated on unspentability
320 2013-06-08 14:18:57 <petertodd> Yup. I am after all apparently the worlds leading expert on sacrificing Bitcoins - a dubious honor. :P
321 2013-06-08 14:19:08 <nsh> hah :)
322 2013-06-08 14:19:39 <nsh> i don't recall the event (i wanted to say anecdote, but i suppose that might be belittling a not inconsiderate loss)
323 2013-06-08 14:19:49 <nsh> *inconsiderable
324 2013-06-08 14:20:18 <petertodd> Lol, nah, I'm referring to how I've come up with basically every good method for proof-of-sacrifice, although that's only because I'm the only person trying.
325 2013-06-08 14:20:39 <nsh> ah, right
326 2013-06-08 14:21:15 <nsh> i like the idea of sacrifices distributed to future mining, but i haven't grokked how that might work yet
327 2013-06-08 14:21:55 <petertodd> Making coins spendable by anyone after n blocks works fine.
328 2013-06-08 14:22:00 <nsh> (theoretically outright loss is partially distributed to future mining through deflation)
329 2013-06-08 14:23:47 <petertodd> What's interesting, is how big should n be? The smallest practical n should be say 100, to avoid problems in a re-organization, however, what about the other direction? Arguably a really large n, say 1 year in the future, is a better choice because it helps avoid the problem where a large pool can offer to do sacrifices at a discount.
330 2013-06-08 14:25:27 <ptote> What is a good way to programmatically generate qr codes of bitcoin addresses?
331 2013-06-08 14:25:44 <petertodd> You can do that with the scripting language by extending it with the ability to find the height of transaction, but what if there existed a way to create a delibrately weak pubkey, whose private key was provably unknown to you?
332 2013-06-08 14:27:01 <petertodd> If you then also lock the txout to some minimum depth, you've created a system for timelock encryption, basically because there's no economic reason to find the key to spend it much faster than the depth!
333 2013-06-08 14:27:09 <petertodd> A shitty system sure, but...
334 2013-06-08 14:27:10 <nsh> petertodd, the idea of being able to lock a paper wallet in a safe and still be able to spent 5 years later is pretty appealing
335 2013-06-08 14:27:15 <nsh> *spend it
336 2013-06-08 14:27:56 <petertodd> For sure. I've done it by spending to a key, then creating a nLockTime'd transaction spending that and deleting the intermediary key, but you can't do that in a way you can prove to someone else.
337 2013-06-08 14:28:45 <nsh> perhaps lodging post-dated transactions that move the coins periodically to new addresses based on a determinate scheme
338 2013-06-08 14:28:53 <nsh> and writing the seed on the paper you put in the safe
339 2013-06-08 14:29:21 <petertodd> That's not a math-based proof.
340 2013-06-08 14:29:37 <nsh> hmm, i'm missing something
341 2013-06-08 14:30:01 <nsh> what's the purpose of the proof?
342 2013-06-08 14:30:37 <nsh> 
ACTION rereads

343 2013-06-08 14:30:46 <petertodd> Maybe your a lawyer and want to prove you've honestly setup a trust for some kid, accessibly only on their 18th birthday?
344 2013-06-08 14:31:04 <nsh> oh, okay
345 2013-06-08 14:31:32 <petertodd> It's really no different from creating a sacrifice, except that here we only want one person to be able to spend the coins.
346 2013-06-08 14:33:13 <nsh> i think you should be able to lock coins in a chain of multisig transactions with one key that will only be generated at some point X in the future
347 2013-06-08 14:33:43 <petertodd> The problem of generating that key is the same problem of timelock encryption.
348 2013-06-08 14:34:21 <nsh> can you not prove time via the length of the blockchain? right, this then becomes scripting for transaction depth
349 2013-06-08 14:35:12 <petertodd> That's irrelevant. You posessed the secret keys required to spend the coins at every step of the way.
350 2013-06-08 14:36:07 <nsh> 
ACTION muses

351 2013-06-08 14:38:40 <nsh> gmaxwell's idea is typically incomprehensible to me: "An infinite sequence of nothing-up-my-sleeve numbers are taken as an infinte sequence of ECC public keys. Searching the pow involves finding distinguished points along a Pollard's rho DLP solution trying to crack the key. When the key is cracked the problem is advanced to the next key."
352 2013-06-08 14:38:43 <nsh> ( https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas )
353 2013-06-08 14:39:29 <petertodd> At what point does it become incomprehensible?
354 2013-06-08 14:39:44 <nsh> pollard's rho, but that's just an algorithm for discrete logarithm
355 2013-06-08 14:39:46 <nsh> so i guess i can parse it
356 2013-06-08 14:40:29 <petertodd> Pollards rho is basically a way to crack a key incrementally, so the proof-of-work becomes proving that you've done work trying to crack the key.
357 2013-06-08 14:40:52 <petertodd> These keys are made delibrately weak so cracking them is feasible.
358 2013-06-08 14:41:01 <nsh> ah, hmm
359 2013-06-08 14:41:39 <nsh> so you can demonstrate that your are incrementally closed to the solution of the DLP at each stage?
360 2013-06-08 14:41:41 <nsh> *closer
361 2013-06-08 14:41:56 <nsh> which corresponds to finding the privkey
362 2013-06-08 14:42:06 <petertodd> The reason why there is more than one key is both to allow the timelock to be used multiple times, but also so that we can adjust the rate at which they are being cracked by making work only valid if you do it on keys in a way that will lead them to being cracked at the right time.
363 2013-06-08 14:42:22 <petertodd> Incrementally closer is one way, but if it were a purely random thing that would be ok too.
364 2013-06-08 14:42:30 <nsh> ok
365 2013-06-08 14:42:49 <nsh> fascinating
366 2013-06-08 14:43:08 <nsh> 
ACTION will have to think about this while walking to the pub 

367 2013-06-08 14:43:11 <nsh> thanks for the discussion
368 2013-06-08 14:43:15 <petertodd> np
369 2013-06-08 14:53:29 <tumak> sipa: you were right, with 128bits mul & adds and 64bit words it could be made *really* efficient, https://gist.github.com/katuma/5735635
370 2013-06-08 14:56:49 <sipa> tumak: i'm implementing it right now
371 2013-06-08 15:04:52 <shesek> https://en.bitcoin.it/wiki/BIP_0011
372 2013-06-08 15:04:59 <shesek> "The current Satoshi bitcoin client does not relay or mine transactions with scriptSigs larger than 200 bytes; to accomodate 3-signature transactions, this will be increased to 500 bytes."
373 2013-06-08 15:05:03 <shesek> was that done?
374 2013-06-08 15:05:23 <petertodd> yes
375 2013-06-08 15:19:45 <TheUni> sipa: ping
376 2013-06-08 15:20:45 <sipa> yes?
377 2013-06-08 15:23:57 <TheUni> sipa: how do you think i can help to push the autotools PR along? I realize it hasn't been long at all, but i'm concerned that it will stall since there really aren't (m)any build-system devs around here. just want to be proactive
378 2013-06-08 15:28:49 <maaku> Good suggestion from the forum to put a warning on the output of dumpprivkey, since people are getting others to give their private keys away as part of a scam : https://bitcointalk.org/index.php?topic=228866.0
379 2013-06-08 15:34:24 <SomeoneWeird> https://github.com/goshakkk/nsa_panel
380 2013-06-08 15:34:26 <SomeoneWeird> this is win
381 2013-06-08 15:34:28 <SomeoneWeird> haha
382 2013-06-08 15:38:22 <sipa> TheUni: i'd say: follow up on the comments given, and make it ready for merging (i.e., include gitian changes, and remove the other makefiles)
383 2013-06-08 15:39:25 <TheUni> sipa: good idea, i'll pull gitian and get it working there
384 2013-06-08 15:40:28 <TheUni> sipa: if i change the gitian descriptors, the pull-request builder bot won't actually use them, will it?
385 2013-06-08 15:40:55 <TheUni> afaik it uses cached gitian descriptors rather than what's in git
386 2013-06-08 15:41:47 <sipa> TheUni: i don't expect the bot to keep working, but that's no problem
387 2013-06-08 15:42:09 <sipa> if the gitian builds work, and people can do local builds from the source files, it can be merged imho
388 2013-06-08 15:42:33 <sipa> we'll need to get the build bot updated too then, but that can happen later
389 2013-06-08 15:43:25 <TheUni> sipa: out of curiosity, why doesn't it just use the descriptors in git?
390 2013-06-08 15:45:06 <sipa> TheUni: no clue, ask BlueMatt
391 2013-06-08 15:45:14 <TheUni> ok
392 2013-06-08 15:45:20 <TheUni> grabbing virtualbox now. thanks for the suggestion
393 2013-06-08 16:06:03 <shesek> petertodd, thanks
394 2013-06-08 16:41:01 <bitnumus> hi all, how can i make -qt use as much CPU as possible when syncing ?
395 2013-06-08 16:41:44 <bitnumus> my total CPU usage is only about 10%
396 2013-06-08 16:41:53 <bitnumus> when i've synced before its been  300%
397 2013-06-08 16:43:45 <sipa> it always uses as muvh cpu as it can
398 2013-06-08 16:44:06 <sipa> if it's not using all, it's likely limited by disk or (more likely) network
399 2013-06-08 16:44:11 <sipa> *much
400 2013-06-08 16:44:42 <sipa> given the stupid sync algorithm, most likely you're just fetching from a slow peer
401 2013-06-08 16:45:05 <bitnumus> this is rubbish, there is nothing i can do to improve?
402 2013-06-08 16:45:18 <bitnumus> maybe it uses more CPU with the later blocks
403 2013-06-08 16:45:53 <bitnumus> and what do you mean network? i thought verifying transactions used alot of CPU and that was what the bottleneck was
404 2013-06-08 16:46:03 <bitnumus> i have a decent SSD
405 2013-06-08 16:46:33 <bitnumus> im sure previously all 8 cores were like 60%
406 2013-06-08 16:49:10 <sipa> use -connect=ip to directly connect to a fast peer if you know one
407 2013-06-08 16:49:40 <sipa> and before the last checkpoint, signature verification is disabled
408 2013-06-08 16:49:58 <sipa> cpu usage is typically quite low before that point
409 2013-06-08 16:51:37 <bitnumus> 163.680
410 2013-06-08 16:51:42 <bitnumus> blocks
411 2013-06-08 16:52:06 <bitnumus> when was last checkpoint ?
412 2013-06-08 16:55:34 <sipa> 235000 or so
413 2013-06-08 16:56:12 <bitnumus> its never been this slow
414 2013-06-08 16:56:16 <bitnumus> prior to this 0.8.2
415 2013-06-08 16:56:26 <sipa> sorry 225000
416 2013-06-08 16:56:32 <sipa> well then you just hit a slow peer
417 2013-06-08 16:56:38 <bitnumus> restart client ?
418 2013-06-08 16:56:53 <sipa> that may help yes
419 2013-06-08 16:57:07 <sipa> -connect= directly to a fast node helps more
420 2013-06-08 16:57:20 <bitnumus> i have no idea of a fast node, unless you want to point me to one :)
421 2013-06-08 16:57:34 <sipa> ok
422 2013-06-08 17:08:58 <bitnumus> look this isn't right
423 2013-06-08 17:08:59 <bitnumus> lol
424 2013-06-08 17:09:15 <bitnumus> i've downloaded the blockchain start to finish probably 30 times
425 2013-06-08 17:09:23 <bitnumus> and this is one of the worse going back years
426 2013-06-08 17:09:51 <bitnumus> 87 weeks behind, moving at a painfully slow rate
427 2013-06-08 17:18:50 <shesek> BIP 16 says that the spending transaction of a p2sh address is "...signatures... {serialized script}"
428 2013-06-08 17:19:27 <shesek> shouldn't it include the number of signatures somewhere?
429 2013-06-08 17:20:03 <shesek> I'm trying to spend money from an p2sh multisig address
430 2013-06-08 17:21:17 <shesek> what I have so far is OP_0 [signature] SIGHASH_ALL [multisig_script], but it doesn't work
431 2013-06-08 17:21:40 <shesek> any idea what I am doing wrong?
432 2013-06-08 17:24:30 <sipa> SIGHASH_ALL isn't an opcode
433 2013-06-08 17:25:36 <shesek> shouldn't it be added after the signature?
434 2013-06-08 17:25:52 <sipa> it's part of the signature, not a separate script element
435 2013-06-08 17:26:37 <sipa> and OP_CHECKMULTISIG has a bug, that it fetches one element too many from the stack
436 2013-06-08 17:27:02 <shesek> yeah, that's what the OP_0 is for, no?
437 2013-06-08 17:27:13 <sipa> ah, yes indeed
438 2013-06-08 17:27:23 <shesek> and yes, I did use it as part of the signature
439 2013-06-08 17:27:25 <shesek> http://pastie.org/8024064
440 2013-06-08 17:27:33 <shesek> (CoffeeScript, BitcoinJS)
441 2013-06-08 17:28:01 <shesek> anything else looks wrong?
442 2013-06-08 17:29:10 <shesek> bitcoind's decoderawtransaction is giving me "TX decode failed" for those transactions