1 2012-10-29 00:21:45 <SupaDupa> Looking For $100 PayPal Loan Paying $115 on or before November 2nd 2012
  2 2012-10-29 00:23:10 <jgarzik> SupaDupa: Not on this channel.  Try #bitcoin-otc
  3 2012-10-29 00:24:03 <SupaDupa> sorry :(
  4 2012-10-29 00:28:05 <SupaDupa> sorry :(
  5 2012-10-29 00:28:08 <SupaDupa> whoops
  6 2012-10-29 00:36:32 <BlueMatt> ok...our qt gitian scripts depend on qt 4.8.2, which was removed from qt repos...without bothering to dig further...let my just guess we need to upgrade
  7 2012-10-29 01:00:03 <SuckMyWub> [6:33pm] <SupaDupa> http://supa.fii.me/BitcoinLoansOLD.txt
  8 2012-10-29 01:00:04 <SuckMyWub> [6:33pm] <SupaDupa> http://supa.fii.me/BitcoinLoansNEW.txt
  9 2012-10-29 01:00:04 <SuckMyWub> [6:33pm] <SupaDupa> http://supa.fii.me/LitecoinLoans.txt
 10 2012-10-29 01:00:04 <SuckMyWub> [6:33pm] <SupaDupa> http://supa.fii.me/PayPalLoans.txt
 11 2012-10-29 01:00:06 <SuckMyWub> Suck my Wub...
 12 2012-10-29 01:07:02 <SuckMyWub> [6:33pm] <SupaDupa> http://supa.fii.me/BitcoinLoansNEW.txt
 13 2012-10-29 01:07:02 <SuckMyWub> [6:33pm] <SupaDupa> http://supa.fii.me/BitcoinLoansOLD.txt
 14 2012-10-29 01:07:02 <SuckMyWub> [6:33pm] <SupaDupa> http://supa.fii.me/LitecoinLoans.txt
 15 2012-10-29 01:07:03 <SuckMyWub> [6:34pm] <SupaDupa> video card I bought x1Salty http://dl.dropbox.com/u/75013537/thankssupa.jpg
 16 2012-10-29 01:07:09 <SuckMyWub> Fuck the Bitcoin Devs
 17 2012-10-29 01:10:01 <abrkn> csb
 18 2012-10-29 01:11:43 <SuckMyWub> ?
 19 2012-10-29 01:12:03 <Luke-Jr> BlueMatt: why'd you unban him?
 20 2012-10-29 01:12:54 <BlueMatt> Luke-Jr: because all he was doing at the time was part/join spamming?
 21 2012-10-29 01:13:21 <Luke-Jr> BlueMatt: he's been scamming people and threats etc for months now :P
 22 2012-10-29 01:13:36 <BlueMatt> well maybe I havent been paying attention to anywhere but -dev...
 23 2012-10-29 01:32:40 <BlueMatt> sipa: as to why it was working in gitian and not pull-tester/jenkins: the calls to ranlib which were in the qt build file (and was getting run first) were missing in the linux-mingw makefile (which was running first in jenkins) hence more issues :)
 24 2012-10-29 01:39:55 <jgarzik> ACTION ponders The Perfect Blockchain Database
 25 2012-10-29 01:40:11 <jrmithdobbs> hardlink tree!
 26 2012-10-29 01:40:12 <jrmithdobbs> ACTION hides
 27 2012-10-29 01:41:43 <jgarzik> a linear, fixed-record-size array sure is tempting, for an index
 28 2012-10-29 01:44:23 <jgarzik> it's just a lot of data to load, even if you're looking at a simple list of (hash, file offset)... that's 8MB given current block count
 29 2012-10-29 02:01:04 <jine> Flushed 11982 addresses to peers.dat  59ms
 30 2012-10-29 02:01:18 <jine> Does peers.dat contain bitcoin nodes ip-adresses?
 31 2012-10-29 02:01:36 <jine> ANd what format are it in?
 32 2012-10-29 02:02:16 <Luke-Jr> yes; custom
 33 2012-10-29 02:03:51 <jine> " This eliminates the need for the BDB-managed addr.dat, replacing it with "peers.dat" containing nothing but a flat file storing addrman data (and a header and checksum). "
 34 2012-10-29 02:03:55 <jine> I c. :
 35 2012-10-29 02:03:56 <jine> :)*
 36 2012-10-29 02:04:52 <jgarzik> OK, loading 8MB of data into hash table not as slow as I thought it might be
 37 2012-10-29 02:05:41 <jine> Are there any "public" tool for getting data out of peers.db or do i have to read the source of bitcoind and write my own?
 38 2012-10-29 02:07:03 <gmaxwell> jine: no. Watcha doing?
 39 2012-10-29 02:08:09 <jine> Correct me if I'm wrong, but that file contains all seen nodes on the network?
 40 2012-10-29 02:08:35 <BlueMatt> no, its bounded in size
 41 2012-10-29 02:08:47 <BlueMatt> (it throws out quite a few)
 42 2012-10-29 02:09:04 <jine> I c.
 43 2012-10-29 02:10:00 <jine> Well, the result i want in the end is to plot bitcoind nodes (as so much many have done before) on gmaps (which MagicalTux have previously done) combined with some other data i have.
 44 2012-10-29 02:10:46 <jine> I have a ipv4/6 dualstack bitcoind up and running, but I'm having issues to make it connect to enough nodes.
 45 2012-10-29 02:11:18 <jine> I can't get over a few hundred connections in total :/
 46 2012-10-29 02:12:15 <BlueMatt> bitcoind only opens 8 outgoing connections by default (on purpose, any more and you'd be effectively dos'ing the network)
 47 2012-10-29 02:13:17 <BlueMatt> (not effectively, but theres no point doing it)
 48 2012-10-29 02:13:30 <MagicalTux> if the whole network was doing that, it'd be killing itself
 49 2012-10-29 02:13:45 <BlueMatt> yep
 50 2012-10-29 02:14:03 <Luke-Jr> jine: is this useful? http://luke.dashjr.org/programs/bitcoin/files/charts/seeds.txt
 51 2012-10-29 02:15:25 <jgarzik> hmmm, valgrind across a fork will be... interesting
 52 2012-10-29 02:15:37 <jgarzik> gotta rebuild openssl w/ PURIFY too :/
 53 2012-10-29 02:16:11 <Luke-Jr> valgrind is so wonderful
 54 2012-10-29 02:16:22 <gmaxwell> jine: most nodes never have their addresses announced at all.
 55 2012-10-29 02:16:55 <gmaxwell> jine: just use sipa's seeds.txt, don't DOS the network by trying to spider it yourself.
 56 2012-10-29 02:18:12 <gmaxwell> (nodes which are not listening or have no routable addresses are never announced; and those are _most_ of the bitcoin nodes)
 57 2012-10-29 03:19:27 <jine> Luke-Jr: Yes, and no. I can maybe start with that, but i want a lot more data then that. Last seen/etc.
 58 2012-10-29 03:20:07 <Luke-Jr> jine: I suspect bitcoinseeder's data file might have that information
 59 2012-10-29 03:20:15 <jine> BlueMatt: I'm aware of that... I patchen my client manually to get over that limit, but it's still hard to get more connections then that.
 60 2012-10-29 03:20:35 <jine> BlueMatt: (Cause of the limit on other nodes)
 61 2012-10-29 03:22:17 <jine> gmaxwell: That was why i started thinking of the peers.dat, i don't want to cause any harm - but still get enough data on my own.
 62 2012-10-29 03:23:20 <jine> Another idea i just got was to crawl through the IRC-network channels and then write a few scripts to monitor them... But that won't cover nodes that aren't using IRC as discovery method.
 63 2012-10-29 03:24:28 <Luke-Jr> jine: note that since 0.6, nodes don't use IRC at all by default
 64 2012-10-29 03:24:48 <jine> ... which kinda kills that idea :)
 65 2012-10-29 03:26:53 <gmaxwell> jine: Often when people ask technical questions they come in the form of Asking how to attach rockets to a pig, when really they just needed to know how to use a frying pan.
 66 2012-10-29 03:27:23 <gmaxwell> So it's always good to ask why, ... I didn't ask because I thought you were up to anything bad. :P
 67 2012-10-29 03:28:18 <gmaxwell> And yea, IRC is no more. It's off by default and almost no one turns it on.  If you're trying to make a map of bitcoin nodes ultimately the answer is that you can't.
 68 2012-10-29 03:28:48 <jine> ... without abusing the network of course ;)
 69 2012-10-29 03:28:56 <jine> But yea, thanks for the answer. :)
 70 2012-10-29 03:30:04 <jine> It's far from hard to setup a few thousand EC2 nodes and get a "snapshot" of the current network, all using the same blockchain but the connections wouldn't be to the "same" nodes all the time (except those that are patched to act as hubs).
 71 2012-10-29 03:30:34 <gmaxwell> No, it's actually not possible at all.
 72 2012-10-29 03:31:53 <jine> I esentially would fill up slot after slot on the regular clients (unpatched), forcing connections to be made to one of my "many" nodes - which results in me getting the IP/time/etc? :
 73 2012-10-29 03:31:57 <jine> :)*
 74 2012-10-29 03:32:03 <jine> 05:28:48 < jine> ... without abusing the network of course ;)
 75 2012-10-29 03:32:09 <jine> But that's not somthing i had in plan...
 76 2012-10-29 03:32:49 <jine> 1000 EC2 nodes costs about $20 for an hour, so it wouldn't even be an expensive test to do
 77 2012-10-29 03:33:27 <gmaxwell> That still won't get all of them, because there are a considerable number of tor nodes. Although if you do something like that I'll gladly bankroll civil litigation against you. On EC2 it would be ineffective due to peer selection in any case.
 78 2012-10-29 03:37:50 <jine> gmaxwell: Of course not all of them, but a large part of the network... Keep in mind that I'm speeking hypothetical, and have no such intentions to do so. Regarding civil litigation, i'm not really sure that would work, as 1) Bitcoin is not a currency, 2) It's not owned by you or anyone, 3) It won't do any actual damage to the network, 4) I'm having a hard time seeing any attorney taking on that case.
 79 2012-10-29 03:39:44 <gmaxwell> jine: (1) has absolutely nothing to do with it, (2) it doesn't have to be, you cause harm to me or abuse _my_ computers then I have standing for civil litigation, (3) it'll use up resources on my systems,
 80 2012-10-29 03:40:12 <gmaxwell> (4) my partner is an attorney.
 81 2012-10-29 03:40:31 <gmaxwell> jine: So, just in case you actually were thinking of doing something like that; you are now forwarned.
 82 2012-10-29 03:41:10 <gmaxwell> jine: Bitcoin isn't a toy, it's a serious system used for business by a great many people, myself included.
 83 2012-10-29 03:41:23 <jine> gmaxwell: You have my word that i has no intenions of doing anything even close to that. I'm all for the good of bitcoin, both the network and as a community.
 84 2012-10-29 03:41:41 <gmaxwell> I have no doubt. Just being clear. :P
 85 2012-10-29 03:41:42 <jine> gmaxwell: Don't you know me better then that? :(
 86 2012-10-29 03:41:52 <jine> Good. :)
 87 2012-10-29 03:42:45 <gmaxwell> though now I'm busily trying to think of ways to make sure that wouldn't work, just to discourage people who I _can't_ scare out of trying it from trying it.
 88 2012-10-29 03:43:20 <gmaxwell> Sadly the best I've got is just getting more people onto tor.
 89 2012-10-29 03:43:39 <jine> But purly hopythetical, it would be doable, without causing distrubtions to the the network at all (or well, all transactions would go through my nodes, i can't really change them or anything on the way so, or could I?) - If that is the case, theres a serious security issue right there.
 90 2012-10-29 03:44:34 <gmaxwell> if most nodes slots were full nodes would take a long time to get connected.
 91 2012-10-29 03:44:34 <jine> With the latest patches to bitcoind, minimum transaction frees etc
 92 2012-10-29 03:44:43 <doublec> isn't that what blockchain.info basically does - monitor a whole bunch of nodes?
 93 2012-10-29 03:45:00 <jine> Will the client still forward that transaction, or not?
 94 2012-10-29 03:45:10 <gmaxwell> doublec: no, what jine was suggesting was DOS attacking all nodes not his so that everyone would connect to his nodes.
 95 2012-10-29 03:45:21 <gmaxwell> jine: forward what transaction? I lost you.
 96 2012-10-29 03:45:47 <doublec> oh
 97 2012-10-29 03:45:47 <gmaxwell> doublec: the motivation being that most nodes aren't listening, so if you want to map them you have to find a way to get them to connect to you.
 98 2012-10-29 03:45:51 <doublec> that sounds like a bad idea
 99 2012-10-29 03:46:00 <gmaxwell> it wasn't a serious suggestion.
100 2012-10-29 03:46:35 <gmaxwell> It was an answer to me saying you can't do that. :P knowing that jine isn't evil I'd mentally written off DOSing all the rest when making that comment! shows me right. :P
101 2012-10-29 03:49:36 <jine> gmaxwell: Nevermind, I've misread a few of the configuration options, it was blockminsize/blockmaxsiz i was thinking of.
102 2012-10-29 03:50:25 <jine> gmaxwell: I'm a bit tired, but i'll try to explain again: If the "attack" i described above would happen - could I (as a bad user) stop transactions along the way, i.e. changing the code to NOT forward transactions
103 2012-10-29 03:50:38 <jine> Effectivly delaying transactions and possible blocks?
104 2012-10-29 03:51:14 <jine> It wouldn't "break" anything, as some nodes (tor & non listing) still wouldn't be affected and would still forward the transaction to the rest of the network.
105 2012-10-29 03:51:54 <jine> But that would mean that it's possible to set up a large amount of non-mining, standard bitcoind, clients, on a huge amoung of hosts/ip's, and cause damange to the network (in form of delays primarily)
106 2012-10-29 03:52:25 <gmaxwell> Er, I was with you until you said non-mining standard bitcoind clients.
107 2012-10-29 03:52:54 <gmaxwell> Yes, if you saturate all connections on honest nodes, causing all new nodes connect to only you.. then you could block transaction and block realying.
108 2012-10-29 03:53:09 <gmaxwell> but that doesn't have anything to do with normal nodes!
109 2012-10-29 03:53:25 <jine> That was just to clarify i was not talking about the 51%-attack.. forget the "standard" in that sentence.
110 2012-10-29 03:53:32 <gmaxwell> ah!
111 2012-10-29 03:53:34 <gmaxwell> gotcha.
112 2012-10-29 03:53:53 <gmaxwell> So the limit of that attack would be that existing connections would stay.
113 2012-10-29 03:54:06 <gmaxwell> So it would only kill hosts as they lost connections.
114 2012-10-29 03:54:31 <jine> Yea
115 2012-10-29 03:54:38 <jine> 1) saturate all connections on all listening nodes, on a global level.
116 2012-10-29 03:54:48 <jine> 2) do not relay ANYTHING to anyone.
117 2012-10-29 03:54:49 <jine> 3) ??
118 2012-10-29 03:55:16 <gmaxwell> But we can make the attack much harder too. By not allowing 'too many' inbound connections per network group. So you'd need lots of networks to use up all the connections.
119 2012-10-29 03:55:22 <jine> 3) All previous connections between nodes are keept, so they won't be affected, unless your connection is lost
120 2012-10-29 03:55:26 <gmaxwell> well "much"
121 2012-10-29 03:55:38 <jine> gmaxwell: That's not an issue, use tor as a gateway or whatever.
122 2012-10-29 03:56:00 <gmaxwell> that only gets you a few thousand hosts.
123 2012-10-29 03:56:05 <jine> Dosn't have to be 1-255 in a row, from the same /22 or something
124 2012-10-29 03:56:35 <gmaxwell> we already do network group based biasing in our outbound selection.
125 2012-10-29 03:56:51 <jine> Oh, i didn't know that.
126 2012-10-29 03:57:14 <gmaxwell> And allowing a single /24 (or host!) to fill up all inbound is just obviously stupid.
127 2012-10-29 03:57:34 <jine> I'm just speaking hypothetically here, out of curiosity and cause of my security interest.
128 2012-10-29 03:58:06 <gmaxwell> sure sure.
129 2012-10-29 03:58:10 <gmaxwell> It's helpful.
130 2012-10-29 03:58:17 <jine> It's not hard to get your hands on multiple thousands of widespread ips (botnet?)
131 2012-10-29 03:58:32 <gmaxwell> Thats why I scare quoted "much" :P
132 2012-10-29 04:00:16 <gmaxwell> right now you could fill up all connections network wide with a single (misconfigured?) host. We can fix that.
133 2012-10-29 04:00:58 <jine> That could prob. be a good idea, yes.
134 2012-10-29 04:01:21 <jine> Oh well... 6 AM here, time for bed. :P
135 2012-10-29 04:01:48 <jine> Talk to you later, I'll try to be in here (or at least more active) more often :)
136 2012-10-29 04:16:14 <jgarzik> hmmm
137 2012-10-29 04:16:57 <jgarzik> need to find the code that stores and verifies a merkle branch (CMerkleTx presumably) matches a given block header
138 2012-10-29 04:21:11 <jgarzik> CBlock::CheckMerkleBranch(), it looks like
139 2012-10-29 04:31:45 <midnightmagic> he sounds almost like a smoother-talking version of phantomcircuit when he first joined ages ago.
140 2012-10-29 04:39:06 <phantomcircuit> midnightmagic, i actually wrote attack code for the fill the slots attack
141 2012-10-29 04:39:13 <phantomcircuit> tested it and it more or less works
142 2012-10-29 04:39:37 <phantomcircuit> not sure if it would still work with the dos code gavin wrote
143 2012-10-29 04:41:32 <midnightmagic> phantomcircuit: I remember some of that. You were pretty.. insistent I guess is a good euphemism, about it.
144 2012-10-29 04:42:45 <phantomcircuit> midnightmagic, im actually reasonably surprised nobody else has taken the (relatively small) amount of time to write a poc
145 2012-10-29 04:42:52 <phantomcircuit> ACTION shrugs
146 2012-10-29 04:58:29 <gmaxwell> phantomcircuit: what do you just do, connect and handshake and sit there?
147 2012-10-29 04:59:48 <gmaxwell> phantomcircuit: if you've actually got it handy, I have a patch to limit by host and by network group now. I've been trying to figure out what limits to use by default.
148 2012-10-29 05:00:58 <midnightmagic> heh heh
149 2012-10-29 05:03:40 <gmaxwell> The hard thing about that is you don't want to break people who e.g. have a bunch of local test stuff going on. Esp on nodes that aren't even internet facing
150 2012-10-29 05:35:12 <phantomcircuit> gmaxwell, that's what the original version did but im pretty sure gavins dos stuff would break it
151 2012-10-29 05:35:25 <phantomcircuit> iono im honestly sort of afriad to test it full scale
152 2012-10-29 06:01:41 <gmaxwell> amiller: I've got an argument for not making the normative utxo tree a prefix trie.  If all the txout data is at the leaf then lookups can be ~O(1).
153 2012-10-29 06:02:28 <gmaxwell> amiller: how is this possible you might say... because if the data structure is normative, other full node peers can give you the exact byte offset of it with insubstantial network cost.
154 2012-10-29 06:02:49 <gmaxwell> (and if they lie, you just ignore their hints or blacklist them; costless)
155 2012-10-29 06:03:21 <gmaxwell> but that doesn't work so well if the lookup key is scattered out across many locations. :(
156 2012-10-29 08:05:54 <thermoman> berkeleydb is still giving me headaches trying to migrate 0.3.24 to 0.7.1
157 2012-10-29 08:06:18 <thermoman> using 0.3.24 wallet.dat -> db.log: "unable to allocate memory for mutex; resize mutex region"
158 2012-10-29 08:07:23 <thermoman> db4.8_dump wallet.dat > wallet.dump ; mv wallet.dat wallet.dat.old ; db4.8_load wallet.dat < wallet.dump -> db.log: "unable to allocate memory for mutex; resize mutex region" and debug.log: "EXCEPTION: St13runtime_error CDB() : can't open database file wallet.dat, error 12 bitcoin in AppInit()"
159 2012-10-29 08:09:58 <sipa> BlueMatt: https://raw.github.com/gist/3972515/5662cffdf17abe8ca386c249439ea61630f2694a/varbuild.log
160 2012-10-29 08:12:07 <sipa> BlueMatt: my guess: it built leveldb as part of Bitcoin-Qt, and reused the .a files for bitcoind
161 2012-10-29 08:27:26 <sipa> BlueMatt: so, i guess makefile.mingw-linux also needs ranlib
162 2012-10-29 09:42:46 <jouke> When I restore a backup, does the client notice some keypool-keys are used and "remove" them from the pool? Or asked in an other way: will the client function totally normal when I restore an older backup?
163 2012-10-29 09:43:20 <jouke> And do I need to restart the client when I replace wallet.dat? (I am exploring ways to have a hot wallet backup)
164 2012-10-29 09:47:49 <cosurgi> ;;bc,halfreward
165 2012-10-29 09:47:50 <gribble> Estimated time of bitcoin block reward halving: Thu Nov 29 01:47:00 2012 | Time remaining: 4 weeks, 2 days, 23 hours, and 0 seconds
166 2012-10-29 10:21:06 <thermoman> it keeps getting better and better: bitcoind: /usr/include/boost/thread/pthread/recursive_mutex.hpp:62: boost::recursive_mutex::~recursive_mutex(): Assertion `!pthread_mutex_destroy(&m)' failed.
167 2012-10-29 10:21:20 <sipa> thermoman: is that at shutdown?
168 2012-10-29 10:24:21 <sipa> thermoman: try moving the database/ directory away
169 2012-10-29 10:24:33 <sipa> it may contain some remains of the old wallet
170 2012-10-29 10:31:09 <thermoman> sipa: yes, on shutdown
171 2012-10-29 12:40:30 <jgarzik> BIGNUM          hashBestChain;
172 2012-10-29 12:41:05 <jgarzik> picocoin now has a working block [header] database, that properly manages a chain
173 2012-10-29 12:45:09 <jgarzik> [jgarzik@bd picocoin]$ ls -l picocoin
174 2012-10-29 12:45:13 <jgarzik> size of stripped binary
175 2012-10-29 12:46:16 <epscy> what is picocoin
176 2012-10-29 12:55:29 <helo> spv client written in c
177 2012-10-29 12:56:31 <yellowhat> fyi: we did a mockup/partial implementation + demo of bitcoin multisig transaction at a payments hackathon organized by a local bank. 77 hackers took parts in 18 teams. links to our short presentations and the source at https://plus.google.com/107839384289577985803/posts/M8bJNXtgZJP
178 2012-10-29 12:59:59 <yellowhat> in 24 hours we invented a little out-of-band multisg format, a new uri schema - and showcased multisig transactions live. our 2 teams made places 5 and 8 in the voting - if we had more time to present people could have actually understood what we were doing but the presentation was only 4 minutes
179 2012-10-29 13:05:09 <kjj_> is your multisig format different from BIP 10?
180 2012-10-29 13:38:02 <BlueMatt> sipa: yea, I ended up running gitian myself and found that
181 2012-10-29 13:53:26 <BlueMatt> ;;later tell Diapolo so should we downgrade to 4.8.1 then?
182 2012-10-29 13:53:27 <gribble> The operation succeeded.
183 2012-10-29 14:09:42 <yellowhat> kjj_: yes we used a different one, http/physical transport based. the main problem we approached was even generating a multisig-address from pubkey of the customer, merchant and post office. the parcel transported by the postman did then carry the partially signed transaction "offline" :)  to the customer who signs his part and broadcasts the finalized tx. postman + merchant recieve money, end of story
184 2012-10-29 14:18:14 <helo> what advantage does that have over the customer paying before the goods are shipped?
185 2012-10-29 14:27:42 <yellowhat> if the package never arrives the post office and the customer can take back the money back from the merchant.
186 2012-10-29 14:30:59 <helo> so it's essentially escrow-through-postman?
187 2012-10-29 14:31:30 <helo> given that the postman is inevitably a trusted independent third party, that makes a lot of sense...
188 2012-10-29 14:32:59 <helo> although the postman would need to inspect all goods...
189 2012-10-29 14:42:31 <TD> good afternoon
190 2012-10-29 14:46:09 <TD> it seems Electrum is becoming an SPV client
191 2012-10-29 14:47:59 <erlinwa> why is it that the packages are being redownloaded each time i do a gitian build?
192 2012-10-29 14:56:08 <BlueMatt> TD: saw that, though is it on the p2p network yet?
193 2012-10-29 14:59:25 <TD> not sure
194 2012-10-29 14:59:47 <TD> it may be getting the blocks and headers from the electrum servers, or something. not sure
195 2012-10-29 15:00:47 <BlueMatt> thats the feeling I got... :(
196 2012-10-29 15:01:17 <BlueMatt> what is the advantage of an untrusted server like electrum after bloom filtering...?
197 2012-10-29 15:02:20 <TD> none, afaik. well, maybe it's faster/more reliable than picking random peers
198 2012-10-29 15:02:21 <sipa> BlueMatt: "the blcockchain is your wallet"
199 2012-10-29 15:02:45 <TD> load is more controlled, etc. of course you could also just run a regular bitcoind that doesn't announce itself and then hard-code your client to use it
200 2012-10-29 15:03:08 <TD> sipa: what does that even mean?
201 2012-10-29 15:03:56 <helo> it uses the blockchain to derive your balances?
202 2012-10-29 15:05:06 <helo> nevermind that a wallet is not just a ledger of balances
203 2012-10-29 15:05:38 <BlueMatt> TD: well, doing better peer picking should make up for it...but...yea
204 2012-10-29 15:05:41 <BlueMatt> sipa: oh...
205 2012-10-29 15:14:54 <nanotube> fyi, uploaded the 0.5.7 backport windows builds. let's see if anyone actually wants them ...
206 2012-10-29 15:17:53 <devrandom> erlinwa: it should go through apt-cacher-ng, so it's fast.  but if you want to skip the OS image initialization step, you can run gbuild with the -i flag
207 2012-10-29 17:05:38 <Diablo-D3> gmaxwell: is there any reason why an app is specifically asking for celt 0.5.1?
208 2012-10-29 17:06:51 <Diablo-D3> I have libcelt-dev installed, but the app's ./configure doesnt seem to want it
209 2012-10-29 17:20:45 <jgarzik> ACTION adds automated testing infrastructure to picocoin
210 2012-10-29 17:20:49 <jgarzik> autotools is good for something, at least
211 2012-10-29 17:24:48 <Diablo-D3> gmaxwell: nm, apparently debian just turns off celt support when building spice-client
212 2012-10-29 17:41:00 <gavinandresen> ACTION hums yo, ho, blow the man down....
213 2012-10-29 17:42:25 <erliwan> I am using "Gavin's notes on getting gitian builds up and running using KVM", "gitian.yml" works with no problem, but "boost-win32.yml" gives me an error "failed to run on-target setarch i386" -> http://pastebin.com/raw.php?i=7vBDt7xM
214 2012-10-29 17:45:10 <gavinandresen> erliwan: building on a fast machine?  I had to increase the ssh timeout of libexec/on-target to get my old gitian-building laptop to build.  And it is still somewhat flaky; I find I have to reboot sometimes to successfully build
215 2012-10-29 17:55:45 <sebicas> I have a questions about multi-signature transactions...
216 2012-10-29 17:56:16 <sebicas> When receiving a transaction now, is not enough to just wait for 6 confirmations
217 2012-10-29 17:56:39 <BlueMatt> ???
218 2012-10-29 17:56:49 <sebicas> I also should check that I have all the signatures to be able to spend it, correct?
219 2012-10-29 17:57:04 <BlueMatt> depends on what you are doing
220 2012-10-29 17:57:08 <BlueMatt> (and probably not)
221 2012-10-29 17:57:53 <sebicas> An script for a Shopping Cart for example..
222 2012-10-29 17:58:08 <sebicas> For I just check is I received a transaction
223 2012-10-29 17:58:13 <sebicas> Wait for 6 confirmations
224 2012-10-29 17:58:23 <sebicas> And clear the order for shipment
225 2012-10-29 17:58:33 <sebicas> Should I change something?
226 2012-10-29 17:58:44 <gavinandresen> sebicas: if you are using bitcoind/Bitcoin-Qt, only multisig transactions where you have all the private keys in your wallet will show up in listtransactions or part of your balance
227 2012-10-29 17:58:58 <kjj_> when you create the multisig address, you need to provide the public keys.  that should hopefully imply that you also have the private keys
228 2012-10-29 17:59:17 <gavinandresen> sebicas: it is implemented that way exactly so that old applications that assume single-signature transactions do not break
229 2012-10-29 17:59:19 <BlueMatt> you should give each order its own address and should clear the order when a payment of the right value to the given address is received and has N confirmations
230 2012-10-29 17:59:19 <sebicas> gavinandresen: Yes I use bitcoind on Linux
231 2012-10-29 17:59:34 <BlueMatt> so you should have no reason to deal with multisig txn
232 2012-10-29 18:00:01 <sebicas> kjj_: Not for creating, I am talking about receiving a transaction
233 2012-10-29 18:00:04 <gavinandresen> Yes, unless you give customers a multi-signature transaction address to pay you, you
234 2012-10-29 18:00:29 <sebicas> I give customers a regular address
235 2012-10-29 18:00:45 <kjj_> sebicas: then it isn't multisig, and you should already have the one and only key for it
236 2012-10-29 18:01:35 <BlueMatt> before you clear an order for payment you should be checking that the given payment was to the given standard single-sig address, that way you dont have to touch multisig in any way
237 2012-10-29 18:01:36 <sebicas> Ok??? so no change is necessary from my end ( Merchant )
238 2012-10-29 18:01:43 <BlueMatt> yes
239 2012-10-29 18:01:48 <sebicas> Ok, thanks.
240 2012-10-29 18:01:49 <BlueMatt> (as long as you did it right in the first place)
241 2012-10-29 18:03:26 <sebicas> I call bitcoind gettransaction <txid> 6 to make sure is confirmed
242 2012-10-29 18:05:11 <sebicas> Thank you!
243 2012-10-29 18:41:43 <gavinandresen> sipa: ping
244 2012-10-29 18:44:27 <BlueMatt> someone wanna pull #1966 now so that we can get jenkins working again?
245 2012-10-29 18:47:16 <D34TH> ^
246 2012-10-29 19:08:58 <jgarzik> ECB does a report on virtual currencies, bitcoin features prominently: http://docs.google.com/viewer?url=www.ecb.europa.eu%2Fpub%2Fpdf%2Fother%2Fvirtualcurrencyschemes201210en.pdf
247 2012-10-29 19:09:07 <jgarzik> (click the button to download original pdf)
248 2012-10-29 19:11:08 <BlueMatt> nice!
249 2012-10-29 19:12:26 <helo> i don't think there's an inaccuracy in it, amazingly
250 2012-10-29 19:19:24 <ThomasV> omg, that's amazing
251 2012-10-29 19:21:27 <jgarzik> yeah, a few minor quibbles in the initial summary, but that's just nitpicking
252 2012-10-29 19:21:31 <jgarzik> pretty good summary
253 2012-10-29 20:06:32 <sipa> gavinandresen: pang
254 2012-10-29 20:07:31 <gavinandresen> sipa: too much latency... I figured it out all by myself.
255 2012-10-29 20:09:05 <sipa> was this problem solved: https://bitcointalk.org/index.php?topic=105505.0 ?
256 2012-10-29 20:09:21 <gavinandresen> sipa: yes
257 2012-10-29 20:09:42 <sipa> ok, good
258 2012-10-29 20:10:08 <gavinandresen> I'm working on Makefiles now, trying to do the recursive leveldb make more cleanly
259 2012-10-29 20:10:42 <gavinandresen> why is running ranlib necessary in linux-mingw and not any other platform?
260 2012-10-29 20:10:53 <sipa> i have no clue
261 2012-10-29 20:11:07 <sipa> but it certainly is necessary there, and not necessary in .unix
262 2012-10-29 20:11:55 <gavinandresen> hmm... ideally leveldb/Makefile would be smart enough to know whether it needs to ranlib or not
263 2012-10-29 20:12:00 <sipa> yes
264 2012-10-29 20:12:45 <Luke-Jr> gavinandresen: ranlib always helps I think
265 2012-10-29 20:13:03 <Luke-Jr> even if not required, it's supposed to optimize linking
266 2012-10-29 20:13:12 <gavinandresen> then leveldb/Makefile could just always ranlib
267 2012-10-29 20:13:22 <sipa> but the hack bitcoin-qt.pro uses to determine what command implements ranlib is horrible
268 2012-10-29 20:13:50 <gavinandresen> I haven't looked at the .pro file yet
269 2012-10-29 20:14:07 <sipa> drink some whiskey first
270 2012-10-29 20:14:20 <Luke-Jr> lol
271 2012-10-29 20:14:22 <gavinandresen> heh...
272 2012-10-29 20:15:05 <sipa> ok, somewhat of an exaggeration, but still:
273 2012-10-29 20:15:09 <sipa> isEmpty(QMAKE_RANLIB) {
274 2012-10-29 20:15:57 <Luke-Jr> O.o;;
275 2012-10-29 20:16:48 <Adifex> hey everyone. I have a newb question about trade fees on Gox where automated trading is concerned. Can anyone speak to that?
276 2012-10-29 20:17:00 <Luke-Jr> Adifex: #mtgox IMO
277 2012-10-29 20:17:46 <sipa> gavinandresen: so it seems that the current gitian builds work, simply because of that ranlib hack in bitcoin-qt.pro, and bitcoin-qt being built before bitcoind
278 2012-10-29 20:18:19 <gavinandresen> sipa: oof....
279 2012-10-29 20:18:26 <Adifex> Luke-Jr: I would agree, but It's less a support question and more a practical one about software development
280 2012-10-29 20:18:51 <Luke-Jr> Adifex: well, you said about fees, which is economical/policy :P
281 2012-10-29 20:18:55 <Luke-Jr> anyhow, asking > asking to ask
282 2012-10-29 20:18:59 <gavinandresen> sipa:  https://github.com/gavinandresen/bitcoin-git/commit/917d9a1ec02360ba3b617b2eef34609102bc0750   <-- my work so far....
283 2012-10-29 20:19:50 <jgarzik> Luke-Jr: RE ranlib
284 2012-10-29 20:19:54 <jgarzik> "always helps" != "never hurts"
285 2012-10-29 20:19:57 <jgarzik> ranlib is the latter
286 2012-10-29 20:19:59 <gavinandresen> sipa: Not ready for a pull request yet, I need to test makefile.unix and makefile.linux-mingw
287 2012-10-29 20:20:35 <Luke-Jr> jgarzik: i c; noop on some platforms?
288 2012-10-29 20:20:42 <jgarzik> yes
289 2012-10-29 20:20:57 <sipa> gavinandresen: i doubt that will work on mingw (but it won't break things further...)
290 2012-10-29 20:21:24 <gavinandresen> does gnu make predefine $(RANLIB) ?
291 2012-10-29 20:21:43 <Adifex> Luke-Jr: ha true. Okay, so on Gox the trade fee is 0.6% to buy and sell. So where a trading bot is concerned, every buy/sell cycle will incur a fee of 1.2%. That's outrageously high for most algorithmic/highish frequency trading platforms, which usually operate on profits much lower than that. Does everyone here just have to deal with that?
292 2012-10-29 20:22:29 <Luke-Jr> gavinandresen: no
293 2012-10-29 20:23:42 <Luke-Jr> Adifex: that's definitely a #mtgox question IMO
294 2012-10-29 20:24:02 <Adifex> alright. thanks though
295 2012-10-29 20:27:20 <Adifex> #mtgox says I need to be "identified with services, cannot join channel." What services..?
296 2012-10-29 20:27:29 <sipa> ChanServ, NickServ, ...
297 2012-10-29 20:27:46 <jeremias> Adifex: and otherwise, nobody is forced to use mtgox, anybody can use any exchange they want, or start their own...
298 2012-10-29 20:27:56 <jeremias> there is even an open source exchange platform
299 2012-10-29 20:47:38 <Adifex> jeremias: do you know what other exchanges have good developer resources for automated trading?
300 2012-10-29 20:48:51 <jgarzik> whee.  successfully used src/test/data/base58_encode_decode.json in picocoin
301 2012-10-29 20:48:59 <jgarzik> go go data-driven tests
302 2012-10-29 20:55:11 <optimator> does anyone know if block explorer for testnet is stuck? The last block is dated oct 24
303 2012-10-29 20:55:28 <D34TH> picocoin?
304 2012-10-29 20:56:29 <helo> picocoin!
305 2012-10-29 20:56:45 <sipa> it's like 1/10000 of a satoshi!
306 2012-10-29 20:57:15 <Adifex> nice
307 2012-10-29 21:32:28 <jgarzik> ahhh
308 2012-10-29 21:32:35 <jgarzik> ultraprune goes so much faster on this machine
309 2012-10-29 21:34:11 <gmaxwell> optimator: there certantly have been blocks since them.
310 2012-10-29 21:34:31 <gmaxwell> optimator: early builds of ultraprune have a bug testnet triggers, making those nodes get stuck.
311 2012-10-29 21:35:23 <sipa> gmaxwell: 258*N bits storage for a partial merkle tree, with N <= num_transactions, and N <= log2(num_transactions)*matched_transactions
312 2012-10-29 21:35:33 <sipa> good enough?
313 2012-10-29 21:46:35 <gmaxwell> I was very confused for a bit because I thought you were saying 258 bits for the binary tree itself... and I couldn't imagine how you found that inefficient of an encoding! :)
314 2012-10-29 21:47:04 <gmaxwell> Inedeed that sounds good. But will the decoder implementation make TD argue? :P
315 2012-10-29 21:49:08 <jgarzik> sipa: is the high level ultraprune database layout documented anywhere?
316 2012-10-29 21:49:26 <jgarzik> sipa: I'm curious about the components of each key/value.  You told me on IRC weeks ago...
317 2012-10-29 21:49:37 <jgarzik> but -ENOMEM apparently :)
318 2012-10-29 21:49:52 <sipa> jgarzik: not really, but txdb.cpp will give you an idea
319 2012-10-29 21:50:15 <gmaxwell> jgarzik: it's more complicated than you might hope because it's agressively compressed.
320 2012-10-29 21:50:57 <sipa> the low-level compressed part is rather well documented; see class CCoins in main.h
321 2012-10-29 21:51:44 <sipa> coins/ contains a) txid -> coins, b) current active block hash
322 2012-10-29 21:51:58 <jgarzik> that's what I was looking for
323 2012-10-29 21:52:02 <jgarzik> txid -> {what?}
324 2012-10-29 21:52:05 <jgarzik> specifically
325 2012-10-29 21:52:12 <sipa> txid -> serialized CCoins
326 2012-10-29 21:52:13 <jgarzik> height, unspent txout bitmask, ...?
327 2012-10-29 21:52:28 <sipa> really, use the source
328 2012-10-29 21:52:34 <sipa> i spent hours to document that part
329 2012-10-29 21:53:45 <sipa> height, unspent outputs, version, coinbase or not
330 2012-10-29 23:07:12 <BlueMatt> sipa: awww, I was gonna do merkle tree encoding later this week :(
331 2012-10-29 23:09:00 <sipa> BlueMatt: sorry, unit tests just finished!
332 2012-10-29 23:10:07 <jgarzik> -rw-rw-r-- 1 jgarzik jgarzik 3674737802 Oct 29 20:00 blocks.dat
333 2012-10-29 23:10:18 <jgarzik> not bad
334 2012-10-29 23:10:37 <jgarzik> pynode's blocks.data, flat file MessageHeader + CBlock serialized format
335 2012-10-29 23:11:07 <sipa> jgarzik: so, same as blk000?.dat, but without the size headers?
336 2012-10-29 23:13:46 <Guest73974> Yippie, build fixed!
337 2012-10-29 23:13:47 <Guest73974> Project Bitcoin build #124: FIXED in 4 hr 23 min: http://jenkins.bluematt.me/job/Bitcoin/124/
338 2012-10-29 23:13:59 <BlueMatt> wtf?
339 2012-10-29 23:14:09 <BlueMatt> why did you get your nick f'd up BlueMattBot?
340 2012-10-29 23:14:44 <BlueMatt> sipa/jgarzik: can I change pull-tester to merge instead of testing pull HEAD now so I can start it again?
341 2012-10-29 23:14:51 <sipa> BlueMatt: go ahead
342 2012-10-29 23:17:05 <BlueMatt> pull-tester chugging away
343 2012-10-29 23:21:56 <jgarzik> sipa: same as blk000?.dat, except: minus size header, add P2P network message header
344 2012-10-29 23:22:04 <jgarzik> so slightly larger overhead
345 2012-10-29 23:22:11 <jgarzik> but can sendfile(2) directly from disk
346 2012-10-29 23:22:32 <jgarzik> BlueMatt: sure
347 2012-10-29 23:23:50 <sipa> BlueMatt: https://github.com/sipa/bitcoin/commit/3006e4e2d0774eee888f62caa44206050f5f3be9
348 2012-10-29 23:24:22 <jgarzik> 16 additional bytes per block
349 2012-10-29 23:24:58 <BlueMatt> sipa: Ill look at it tomorrow...busy atm
350 2012-10-29 23:25:07 <sipa> BlueMatt: ok
351 2012-10-29 23:25:23 <sipa> it's in my partalmerkle branch (note the typo... need sleep)
352 2012-10-29 23:25:47 <gmaxwell> Yea, the recursive decoder is simply enough for sure.
353 2012-10-29 23:31:54 <sipa> didn't implement any serializer yet...
354 2012-10-29 23:32:14 <sipa> you could take advantage of the fact that vBits.size() = vHash.size()*2-1
355 2012-10-29 23:33:55 <Luke-Jr> slush: any reason the Stratum proxy would be triggering scrypt, as far as you know?
356 2012-10-29 23:37:05 <sipa> how does a proxy trigger an algorithm?
357 2012-10-29 23:37:51 <Luke-Jr> sipa: in theory, the only way to do it is to send "algorithm": /scrypt/ in the JSON response to getwork
358 2012-10-29 23:39:07 <sipa> i simply don't see what a proxy has to do with an algorithm
359 2012-10-29 23:39:25 <sipa> do you mean a miner connected to that proxy, that suddenly uses scrypt to mine?
360 2012-10-29 23:40:04 <Luke-Jr> yes
361 2012-10-29 23:49:25 <Azelphur> Hi folks, I want to monitor transactions to an address in realtime, Is there any easy library to do this (preferably in python)?
362 2012-10-29 23:50:14 <Luke-Jr> Azelphur: probably pynode
363 2012-10-29 23:50:28 <Luke-Jr> jgarzik's Python implementation
364 2012-10-29 23:50:33 <Azelphur> cool, I'll take a look :)