1 2013-01-18 12:26:24 <ThomasV> is https://en.bitcoin.it/wiki/BIP_0013 accurate to describe what the current client does? it says 'draft'
2 2013-01-18 12:27:54 <Luke-Jr> ThomasV: afaik, but it's just the address format
3 2013-01-18 12:28:37 <ThomasV> sure, but the address format is kind of needed, if I want to implement p2sh
4 2013-01-18 12:29:12 <ThomasV> gavinandresen: https://en.bitcoin.it/wiki/BIP_0013 <-- no longer a draft?
5 2013-01-18 12:38:45 <gavinandresen> ThomasV: right, no longer a draft. I don't have permission to edit those pages, though.
6 2013-01-18 12:39:44 <ThomasV> gavinandresen: I'm implementing multisig in Electrum. any other useful resource?
7 2013-01-18 12:40:26 <ThomasV> bip 11 I guess
8 2013-01-18 12:40:56 <gavinandresen> ThomasV: I've got a few gists related to multisig??? lemme find them
9 2013-01-18 12:42:02 <gavinandresen> ThomasV: https://gist.github.com/4039433 https://gist.github.com/3161162
10 2013-01-18 12:42:32 <ThomasV> gavinandresen: OAuth failure
11 2013-01-18 12:43:12 <ThomasV> my nick on github is 'ecdsa'
12 2013-01-18 12:43:18 <gavinandresen> ThomasV: weird, they're both public gists
13 2013-01-18 12:43:56 <t7`> ThomasV, nice
14 2013-01-18 12:44:08 <t7`> well until quantum computers make it obsolete
15 2013-01-18 12:44:28 <ThomasV> t7`: it's just because ThomasV was taken by someone else
16 2013-01-18 12:44:39 <t7`> i have a repo called ecdsa
17 2013-01-18 12:44:55 <gavinandresen> ThomasV: dunno why you'd get an OAuth failure, maybe you need to refresh your github cookies
18 2013-01-18 12:46:01 <ThomasV> gavinandresen: it works now. ty
19 2013-01-18 12:47:11 <ThomasV> oh but that's not really what I'm looking for :)
20 2013-01-18 12:48:07 <ThomasV> well, I guess the scriptsig from bitcoind should be enough
21 2013-01-18 12:49:44 <gavinandresen> you're writing code to build a scriptPubkey given a BIP13 address? That should be pretty trivial....
22 2013-01-18 12:51:35 <ThomasV> it should be, but it would probably be easier if I could see an example :)
23 2013-01-18 12:52:25 <Luke-Jr> ThomasV: https://gitorious.org/bitcoin/libblkmaker/blobs/master/base58.c
24 2013-01-18 12:52:35 <Luke-Jr> gavinandresen: it's not as trivial as it seems in C :/
25 2013-01-18 12:54:02 <gavinandresen> Should be something like: decode the base58 like an old bitcoin address. Then take the 20-byte hash and surround it by HASH160 and EQUAL??? instead of DUP HASH160 and EQUALVERIFY CHECKSIG
26 2013-01-18 12:54:21 <Luke-Jr> yeah, decoding base58 is a pain
27 2013-01-18 12:54:39 <gavinandresen> I assume Electrum already has code to deal with that
28 2013-01-18 12:58:04 <ThomasV> gavinandresen: where is OP_CHECKMULTISIG involved?
29 2013-01-18 12:59:16 <gavinandresen> ThomasV: when the transaction is spent.
30 2013-01-18 13:02:26 <ThomasV> do you have the txid of a transaction redeeming a multisig address?
31 2013-01-18 13:02:44 <ThomasV> so I can see an example
32 2013-01-18 13:03:18 <gavinandresen> http://blockchain.info/address/3QJmV3qfvL9SuYo34YihAf3sRCW3qSinyC
33 2013-01-18 13:03:31 <kjj> https://gist.github.com/3966071
34 2013-01-18 13:03:34 <ThomasV> great thanks
35 2013-01-18 13:04:02 <gavinandresen> bah, but blockchain.info doesn't show the input scripts correctly???.
36 2013-01-18 13:05:06 <ThomasV> no, it says OP_FALSE :(
37 2013-01-18 13:05:14 <ThomasV> anyway, I'll find it
38 2013-01-18 13:05:52 <kjj> if you follow along in his gist, you can find the transactions that you need
39 2013-01-18 13:07:07 <Luke-Jr> https://coinbase.com/network/transactions/837dea37ddc8b1e3ce646f1a656e79bbd8cc7f558ac56a169626d649ebe2a3ba
40 2013-01-18 13:08:12 <kjj> 3c9018e8d5615c306d72397f8f5eef44308c98fb576a88e030c25456b4f3a7ac <-- transaction that sends TO p2sh
41 2013-01-18 13:08:32 <kjj> 837dea37ddc8b1e3ce646f1a656e79bbd8cc7f558ac56a169626d649ebe2a3ba <-- transaction that redeems it
42 2013-01-18 13:59:28 <nanotube> gavinandresen: bips unprotected at luke's request, fyi. so now you can go edit that bip you wanted to edit. :)
43 2013-01-18 14:00:51 <ThomasV> nanotube: why was the wiki protected?
44 2013-01-18 14:01:53 <nanotube> some bips were protected by genjix, possibly because he wanted to reduce spam or edit-warring
45 2013-01-18 14:02:04 <nanotube> but now that we are bitcoinpayment-protected, at least spam shouldn't be a concern.
46 2013-01-18 14:02:20 <nanotube> we can always take it on a case by case basis if there's future trouble
47 2013-01-18 14:04:27 <ThomasV> bitcoinpayment-protected? huh?
48 2013-01-18 14:05:20 <nanotube> ah, because there was a steady stream of spam coming into the wiki
49 2013-01-18 14:05:43 <nanotube> so now... you have to send a trivial bitcoin amount to enable editing
50 2013-01-18 14:05:51 <nanotube> which spammers won't do obv.
51 2013-01-18 14:06:13 <nanotube> https://en.bitcoin.it/wiki/BitcoinPayment
52 2013-01-18 14:07:00 <ThomasV> wtf? 0.05 btc ransom?
53 2013-01-18 14:07:18 <jeremias> ol
54 2013-01-18 14:07:21 <jeremias> +l
55 2013-01-18 14:07:26 <ThomasV> Electrum's localization project is hosted on the wiki...
56 2013-01-18 14:07:31 <jeremias> pretty cool idea
57 2013-01-18 14:07:42 <ThomasV> time to move away, or accept it?
58 2013-01-18 14:07:59 <jeremias> ThomasV: well, maybe you can move it somewhere else?
59 2013-01-18 14:08:08 <ThomasV> I guess some translators might be deterred*
60 2013-01-18 14:08:09 <jeremias> I guess the spammers are running those scam sites
61 2013-01-18 14:08:38 <jeremias> or only enable the plugin to specific sites
62 2013-01-18 14:09:38 <ThomasV> gavinandresen: ok, I successfully decoded the transaction you gave me :)
63 2013-01-18 14:12:37 <nanotube> ThomasV: you can always offer to pay 0.05 btc for those who are deterred.
64 2013-01-18 14:14:48 <ThomasV> nanotube: can you unprotect the Electrum/Translation page?
65 2013-01-18 14:15:18 <jgarzik> nanotube: neat idea!
66 2013-01-18 14:15:27 <jgarzik> I like it
67 2013-01-18 14:15:43 <nanotube> jgarzik: yep, we figured the /bitcoin wiki/ is uniquely amenable to bitcoin-hashcash like protection from spam. :)
68 2013-01-18 14:16:19 <nanotube> ThomasV: i can't unprotect individual pages from bitcoinpayment. i'm sure mtux hasn't coded that in.
69 2013-01-18 14:17:37 <nanotube> i'm sure translators will enjoy lack of spam on their translations also. :)
70 2013-01-18 14:18:06 <TD> nanotube: i made the following proposal on the tor-talk list
71 2013-01-18 14:18:19 <ThomasV> nanotube: https://en.bitcoin.it/wiki/Special:RecentChanges huh?
72 2013-01-18 14:18:28 <nanotube> ThomasV: and you can always post a message on the translation project main page that you're willing to pay for them. hell, i'll give you 1btc if you need, that should last for 20 people. :)
73 2013-01-18 14:18:32 <TD> make 10 transactions in a row (roughly) that spend some non-trivial amount of money to miner fees all together
74 2013-01-18 14:18:49 <ThomasV> nanotube: oh, got it. they were sysop protected
75 2013-01-18 14:18:54 <nanotube> ThomasV: ah, that's the 'usual wiki protection' preventing pages from being edited by non-administrators.
76 2013-01-18 14:18:57 <nanotube> yep
77 2013-01-18 14:19:01 <TD> the transactions and their merkle branches together, along with the pubkeys needed by the corresponding outputs, can be put into a protocol buffer. the hash of the protobuf is your new identity
78 2013-01-18 14:19:26 <TD> you can sign server-provided nonces with the keys needed to create the "sacrifice" to prove you own it. the data blob is like a certificate
79 2013-01-18 14:19:35 <TD> now you can create difficult-to-produce identities suitable for authentication
80 2013-01-18 14:19:53 <nanotube> TD: heh cool. similar to my old 'distributed dns using bitcoin transactions' idea. :)
81 2013-01-18 14:21:08 <nanotube> (which was frowned upon due to blockchain spam, since it was also storing extra data in the blockchain)
82 2013-01-18 14:22:45 <TD> well, i suspect anonymous identities are a lot less common than domain names
83 2013-01-18 14:23:20 <TD> but nowadays that we nearly have pruning, as long as various schemes have some obvious utility and don't bloat the UTXO set it's a bit easier to justify. most nodes don't have to pay the cost of your scheme. in this case, the outputs could get pruned away.
84 2013-01-18 14:23:27 <nanotube> yes - and also not requiring storing extra info in the transactions.
85 2013-01-18 14:23:30 <TD> right
86 2013-01-18 14:24:24 <nanotube> so how did the torpeople take it? :)
87 2013-01-18 14:24:30 <TD> seemed to like it
88 2013-01-18 14:24:33 <nanotube> col
89 2013-01-18 14:24:33 <TD> a few anyway
90 2013-01-18 14:24:35 <nanotube> o
91 2013-01-18 14:24:41 <TD> hard to say if anyone will implement it
92 2013-01-18 14:24:56 <nanotube> hehe true, it's a long way from liking to implementation ...
93 2013-01-18 14:26:24 <gavinandresen> TD: interesting discussions on tor-talk are bad for my productivity???.
94 2013-01-18 14:27:02 <nanotube> ACTION wonders if we should make a list of things that could be bitcoin-protected against the cheap-pseudonyms problem. lower the barrier to people coming up with them and implementing them. :)
95 2013-01-18 14:27:06 <TD> i never saw you post there though :)
96 2013-01-18 14:27:21 <TD> nanotube: i suggested starting with a MediaWiki extension, maybe Wordpress as they're already bitcoin friendly
97 2013-01-18 14:27:24 <TD> the actual thread was about gmail
98 2013-01-18 14:27:28 <gavinandresen> TD: I never did, I'm not a subscriber. I'm browsing the archives instead of doing what I should be doing
99 2013-01-18 14:27:29 <TD> so i was posting with my google security hat on
100 2013-01-18 14:27:31 <TD> ah
101 2013-01-18 14:27:46 <nanotube> heh
102 2013-01-18 14:28:12 <TD> i'm thinking we might want a minor change to the bloom filtering protocol
103 2013-01-18 14:28:26 <gavinandresen> already? I just pulled it yesterday!
104 2013-01-18 14:28:31 <TD> well
105 2013-01-18 14:28:31 <TD> will discuss with Matt when he's online.
106 2013-01-18 14:28:34 <TD> it's something we debated before
107 2013-01-18 14:28:47 <TD> and i discovered that there's an edge case in bitcoinj that's a bit of a pain to fix with the current way he did things. it's not a big change.
108 2013-01-18 14:28:58 <TD> basically right now, when you ask for a block, you get the transactions in it first, then a filtered block
109 2013-01-18 14:29:02 <TD> the change i'm thinking of is to reverse them
110 2013-01-18 14:29:10 <TD> filtered block first, then the transactions in it
111 2013-01-18 14:29:12 <sipa> TD: that makes sense
112 2013-01-18 14:29:20 <sipa> i expected it to be block first
113 2013-01-18 14:29:38 <stealth222> if you get the block why do you also need the transactions/
114 2013-01-18 14:29:50 <stealth222> ?
115 2013-01-18 14:29:52 <TD> i asked matt to do it that way originally but he seemed to think it was simpler to implement in bitcoinj the other way around. but looking at some of the issues, i'm not convinced it is. especially with recursive resolution of mempool transactions (eg to find timed txns)
116 2013-01-18 14:29:56 <TD> it's just a pain
117 2013-01-18 14:30:17 <TD> also it means apps see the tx as pending first and then in a block a moment afterwards, which can complicate UI notification logic, etc
118 2013-01-18 14:30:27 <TD> stealth222: filtered block messages don't include the actual transactions
119 2013-01-18 14:30:39 <sipa> stealth222: filtered blocks only contains txids, and not txn
120 2013-01-18 14:30:55 <stealth222> oh
121 2013-01-18 14:31:12 <stealth222> then why send the txs at all? if you have the txids, you could ask for the ones you want afterwards
122 2013-01-18 14:31:32 <sipa> the P2P protocol doesn't allow querying arbitrary transactions, only recently relayed ones
123 2013-01-18 14:31:48 <stealth222> oh, hmm
124 2013-01-18 14:31:53 <TD> yeah. it's kind of an odd construction.
125 2013-01-18 14:32:05 <sipa> one solution could be to make them guaranteed to be relayable for some time
126 2013-01-18 14:32:17 <TD> it works but when you start looking at the integration with gui apps and what APIs are natural and things, it's not really helpful to have them come first. you'd end up having to buffer them anyway.
127 2013-01-18 14:32:36 <sipa> but from a latency point of view, it makes sense to immediately send the transactions you think the receiver doesn't know about
128 2013-01-18 14:32:41 <sipa> ... actually
129 2013-01-18 14:32:46 <TD> right. it's done that way for latency reasons.
130 2013-01-18 14:32:51 <sipa> what if you're connected to 8 peers?
131 2013-01-18 14:33:01 <sipa> you'll get all new-in-block txn 8 times
132 2013-01-18 14:33:27 <TD> currently bcj only ever downloads from a single peer
133 2013-01-18 14:33:45 <sipa> sure, but that's not the only use case we intend, right?
134 2013-01-18 14:33:50 <TD> but yeah, a flag that lets you opt out of immediately receiving transactions might be useful for cases where you just want to compare blocks, eg, to spot a peer that's lying through omission.
135 2013-01-18 14:34:13 <TD> well, is there another use case for downloading the same blocks multiple times?
136 2013-01-18 14:34:22 <gavinandresen> wouldn't you just give different peers different bloom filters?
137 2013-01-18 14:34:32 <gavinandresen> (with some overlap)
138 2013-01-18 14:34:36 <sipa> TD: good point
139 2013-01-18 14:34:51 <sipa> the deduplication should happen at the point of the block invs
140 2013-01-18 14:34:56 <TD> ACTION -> tgif pre-preso, back later
141 2013-01-18 14:35:16 <gavinandresen> ACTION wonders what pre-preso means
142 2013-01-18 14:35:32 <stealth222> it's an espresso you have before you have an espresso
143 2013-01-18 14:36:03 <gavinandresen> that's about what I was thinking. Some coffee thing (I never learned to like the stuff)
144 2013-01-18 14:36:35 <sipa> pre-presentation
145 2013-01-18 14:36:57 <gavinandresen> sipa: I've lost track of the motivation for the switch to LevelDB1.7 / no-boost-Leveldb. There are problems on Windows with what is in git HEAD now?
146 2013-01-18 14:38:02 <sipa> gavinandresen: i did it because of reports of slowness / high memory usage on windows
147 2013-01-18 14:38:16 <sipa> but i'm not sure at all whether those have improved
148 2013-01-18 14:38:36 <gavinandresen> sipa: ah, ok.
149 2013-01-18 14:38:48 <sipa> though in general moving to leveldb 1.7 and a more modern build environment is useful i think
150 2013-01-18 14:39:39 <gavinandresen> sipa: I agree
151 2013-01-18 14:39:56 <sipa> the native windows env is the most risky part, imho
152 2013-01-18 14:40:13 <gavinandresen> native windows env?? what do you mean?
153 2013-01-18 14:40:23 <sipa> non-boost windows leveldb env
154 2013-01-18 14:41:08 <gavinandresen> do we know what Chrome on Windows is using?
155 2013-01-18 14:41:19 <sipa> they use chrome's own env
156 2013-01-18 14:41:23 <gavinandresen> bah
157 2013-01-18 14:41:51 <sipa> and iirc the leveldb maintainers don't want a boost-based env, but a native one (like this) may have a chance to be merged upstream
158 2013-01-18 14:42:30 <gavinandresen> makes sense. I was just hoping not to be the guinea pig for new code
159 2013-01-18 14:42:56 <sipa> yes, that's what i don't like
160 2013-01-18 14:43:47 <sipa> i think we should at least verify it for things like memory leaks over time
161 2013-01-18 14:44:18 <sipa> gavinandresen: any benchmark results for 32 vs 64 bit?
162 2013-01-18 14:45:08 <gavinandresen> yes, full-testnet-sync was 270 seconds 32-bit, 190 seconds 64-bit
163 2013-01-18 14:45:21 <gavinandresen> ??? which is about what I would expect
164 2013-01-18 14:45:42 <sipa> do you have the actual per-txin timing results?
165 2013-01-18 14:46:02 <gavinandresen> no, but I bet 32-bit is about half as fast.
166 2013-01-18 14:46:35 <sipa> so it would seem, indeed, but full sync does a lot more than just verification
167 2013-01-18 14:47:03 <Hasimir> gavinandresen, thanks for whatever change you made to 0.7.2 that stopped it crashing on Leopard :)
168 2013-01-18 14:47:39 <gavinandresen> Hasimir: you're welcome. By the way??? could you help test the code-signed 0.7.2 release?
169 2013-01-18 14:47:56 <Hasimir> probably
170 2013-01-18 14:48:03 <Hasimir> what needs to be done?
171 2013-01-18 14:48:35 <gavinandresen> Hasimir: turn on Gatekeeper, then download a version of 0.7.2 that is code-signed, and see if it lets you install/run it.
172 2013-01-18 14:48:51 <stealth222> I still can't seem to build for leopard - but I can build for snow leopard and up
173 2013-01-18 14:49:09 <gavinandresen> Hasimir: binary is exactly the same, I just code-signed the .app bundle: http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.7.2/bitcoin-0.7.2-macosx_signed.dmg/download
174 2013-01-18 14:49:49 <Hasimir> ok
175 2013-01-18 14:49:55 <Hasimir> and gatekeeper?
176 2013-01-18 14:50:29 <gavinandresen> Hasimir: errrp???. wait, you CAN'T test that, you're OSX 10.5???..
177 2013-01-18 14:50:51 <Hasimir> oh well
178 2013-01-18 14:51:02 <gavinandresen> Gatekeeper is new with 10.8. I think (was it in 10.7 but just off by default?)
179 2013-01-18 14:51:03 <stealth222> I can test it
180 2013-01-18 14:51:37 <gavinandresen> stealth222: cool, thanks. If it works, I'll switch the default mac and windows downloads to be the code-signed binaries.
181 2013-01-18 14:52:10 <stealth222> you better not be giving me any malware, gavin :p
182 2013-01-18 14:52:22 <stealth222> if my wallet's missing I'll know who to blame
183 2013-01-18 14:52:36 <Hasimir> you still want me to try the code signed version even without gatekeeper or does it not matter?
184 2013-01-18 14:52:37 <stealth222> j/k
185 2013-01-18 14:52:50 <gavinandresen> Hasimir: sure, can't hurt.
186 2013-01-18 14:53:12 <stealth222> should I disable unsigned installations, gavin?
187 2013-01-18 14:53:52 <gavinandresen> stealth222: yes, please
188 2013-01-18 14:55:26 <stealth222> gavinandresen: it worked
189 2013-01-18 14:55:33 <gavinandresen> sipa: RE: build environment: I think we should either move both linux and windows to Precise, or stay on Lucid for both. Just to keep the pull-tester environment sane
190 2013-01-18 14:55:42 <gavinandresen> stealth222: awesome, thanks
191 2013-01-18 14:56:03 <Hasimir> gavinandresen, well, it hasn't auto-crashed ... now let's give it a while to kick into gear
192 2013-01-18 14:56:11 <gavinandresen> sipa: ??? but if we move the Linux build to Precise, then that means dropping support for lucid binaries
193 2013-01-18 14:56:41 <sipa> gavinandresen: yes, but precise for windows is more useful too, as it means getting gcc 4.6 instead of 4.2
194 2013-01-18 14:57:00 <gavinandresen> sipa: ACK. I think the right thing to do is to build everything Precise.
195 2013-01-18 14:57:15 <sipa> you think it's fine to drop lucid support?
196 2013-01-18 14:57:22 <sipa> s/lucid/pre-precise/
197 2013-01-18 14:57:45 <gavinandresen> I think so, but I don't use the Linux binaries...
198 2013-01-18 14:59:33 <gavinandresen> "Canonical intends to provide support for Ubuntu 10.04 until April 2013 for the desktop version" <-- very close to end-of-life
199 2013-01-18 14:59:56 <etotheipi_> hey! I'm in lucid, why you guys hatin' so much?
200 2013-01-18 15:00:14 <Hasimir> hrm ... forgot to change the network settings to not use tor, oh well, worth testing that too I guess
201 2013-01-18 15:00:28 <gavinandresen> etotheipi_: we have a vendetta against anybody who DARES to COMPETE with the ULTIMATELY AWESOMENESSS of BITCOIN-QT!!!!!!!
202 2013-01-18 15:01:16 <stealth222> multiwallet-qt would be awesomer :)
203 2013-01-18 15:01:18 <etotheipi_> gavinandresen: to be fair, though, why can't lucid be supported?
204 2013-01-18 15:02:17 <etotheipi_> I mean, I compile and bundle on lucid, and it works with lucid+... the same doesn'tseem to be true for newer ubunut
205 2013-01-18 15:02:37 <gavinandresen> etotheipi_: well, we want to use Precise to build for Windows. So we want to use Precise for the pull-tester environment.
206 2013-01-18 15:03:00 <etotheipi_> oh, I forgot you guys were cross-compiling
207 2013-01-18 15:03:04 <gavinandresen> etotheipi_: ??? and I'd like the pull-tester environment to be as similar as possible to the gitian-build environment we use for releases
208 2013-01-18 15:03:23 <etotheipi_> yeah yeah, I get it
209 2013-01-18 15:03:29 <Hasimir> gavinandresen, it loaded, but I'm still waiting for it to go find the network
210 2013-01-18 15:03:44 <Hasimir> ah, it just did
211 2013-01-18 15:03:45 <gavinandresen> etotheipi_: if several somebodies wanted to get together and produce binaries for Lucid, that'd be awesome. But I think we're too busy to take that on.
212 2013-01-18 15:04:31 <stealth222> any good user of UNIX-like OSes should know how to compile it themselves :p
213 2013-01-18 15:04:38 <gavinandresen> that, too
214 2013-01-18 15:04:50 <sipa> well, i think we should try to keep makefile+source compatibility with lucid and others debianisms
215 2013-01-18 15:04:55 <Hasimir> what's wrong with the configure && make && make install dance?
216 2013-01-18 15:05:18 <sipa> even if we don't provide gitian binaries for pre-precise anymore
217 2013-01-18 15:06:19 <stealth222> agree, sipa
218 2013-01-18 15:07:41 <stealth222> it shouldn't be too hard to find at least one person to try to compile it on lucid to test the makefiles
219 2013-01-18 15:08:19 <Hasimir> stealth222, I volunteer etotheipi_ ;)
220 2013-01-18 15:08:23 <stealth222> :)
221 2013-01-18 15:08:31 <gavinandresen> I kind of like Hasimir's thought-- what if we did the minimal work so 'configure && make && make install' in the top-level directory Did the Right Things ?
222 2013-01-18 15:09:01 <Hasimir> that'd suit me for when I move back to Slackware too
223 2013-01-18 15:10:44 <Eliel> gavinandresen: that would definitely make life easier for a lot of people who just want to compile bitcoin.
224 2013-01-18 15:11:51 <gavinandresen> we got stuck in the past with people trying to do full-blown setuptools/whatever . A simple, just-works-on-windows-and-osx-and-ubuntu configure.sh might be good enough
225 2013-01-18 15:12:31 <gavinandresen> (I'd settle for just-works-on-osx-and-linux)
226 2013-01-18 15:12:46 <stealth222> windows users aren't going to compile it - lol
227 2013-01-18 15:12:47 <Hasimir> that would go a long way
228 2013-01-18 15:12:55 <stealth222> most mac users won't either
229 2013-01-18 15:13:00 <Hasimir> especially making it distribution agnostic
230 2013-01-18 15:13:09 <gavinandresen> Great. Who wants to take a crack at writing that?
231 2013-01-18 15:13:21 <Eliel> stealth222: yes, of course. That would mostly be for linux users.
232 2013-01-18 15:14:24 <gavinandresen> ACTION hears crickets
233 2013-01-18 15:15:23 <Hasimir> ACTION checks the configure file for a reasonably sized project (GPG) ...
234 2013-01-18 15:15:37 <Hasimir> gonna have to pass on that one, sorry
235 2013-01-18 15:15:41 <Eliel> Hasimir: most projects autogenerate them with autoconf
236 2013-01-18 15:17:05 <stealth222> I can take a whack at it, gavin - but I don't want to promise anything...got plenty of other stuff going on atm
237 2013-01-18 15:17:39 <Hasimir> ACTION checks autoconf man page and then configure.ac and still thinks someone who has read the bitcoin source code would do a better job ;)
238 2013-01-18 15:17:40 <gavinandresen> right, I'm saying a trivial configure.sh that just runs qmake with the right arguments could be good enough. Extra credit would be to check for missing dependencies
239 2013-01-18 15:18:21 <stealth222> isn't checking for missing dependencies an essential part of the configure script?
240 2013-01-18 15:18:56 <stealth222> I mean, chances are if you type qmake and have the dependencies installed, you'll get a working Makefile
241 2013-01-18 15:19:17 <stealth222> what special arguments are needed?
242 2013-01-18 15:19:29 <stealth222> UPNP and that stuff?
243 2013-01-18 15:19:36 <gavinandresen> yup
244 2013-01-18 15:20:18 <stealth222> so you're talking about a script that prompts the user for whether they want UPNP?
245 2013-01-18 15:21:17 <gavinandresen> that's the project-- figure out all that stuff. I'd suggest "compile with UPNP if the UPNP library is in the standard spot, otherwise don't"
246 2013-01-18 15:21:40 <stealth222> the less the user needs to be prompted the better
247 2013-01-18 15:21:44 <gavinandresen> agreed
248 2013-01-18 15:22:06 <gavinandresen> just Do The Right Thing. And if you can't, tell the user exactly what they need to do.
249 2013-01-18 15:22:35 <Eliel> Hasimir: you're most likely right about that :)
250 2013-01-18 15:22:42 <Hasimir> of course, then there's the fun of if "the standard spot" for library x differs between distros
251 2013-01-18 15:23:05 <Hasimir> Eliel, sometimes wisdom is knowing when to leave things to others
252 2013-01-18 15:23:08 <stealth222> the list can't be too extensive
253 2013-01-18 15:23:29 <stealth222> it's just a few more string literals and conditionals in the script :p
254 2013-01-18 15:23:43 <gavinandresen> start with debian, and "patches welcome" for supporting others.
255 2013-01-18 15:23:44 <Eliel> then again, most likely no-one will get it right on the first try :)
256 2013-01-18 15:23:49 <Hasimir> sounds right
257 2013-01-18 15:24:16 <Hasimir> but I'd say cover debian (and its children) and dead rat (and its children)
258 2013-01-18 15:24:40 <Eliel> ... dead rat?
259 2013-01-18 15:24:48 <Hasimir> dead rat = red hat
260 2013-01-18 15:24:51 <stealth222> lol
261 2013-01-18 15:30:40 <TD> gavinandresen: i have gatekeeper
262 2013-01-18 15:30:54 <gavinandresen> I am the KeyMaster!
263 2013-01-18 15:31:25 <TD> or should i say gatekeeper has me :(
264 2013-01-18 15:32:24 <Hasimir> "Ray has gone bye-bye, what've you got for me Egon?" "I'm sorry Peter, I've lost the capacity for rational thought."
265 2013-01-18 15:45:23 <stealth222> packaging software is not as fun as writing it :p
266 2013-01-18 16:01:11 <helo> need to write software packaging software to improve the experience
267 2013-01-18 16:01:34 <helo> waitno
268 2013-01-18 16:02:07 <stealth222> automake and autoconf? :p
269 2013-01-18 16:02:28 <stealth222> autohell? :p
270 2013-01-18 16:02:49 <stealth222> autononeroticasphyxiation
271 2013-01-18 16:33:03 <Pucilowski> Is there anywhere I can view a list of transactions that took very long to confirm?
272 2013-01-18 16:38:11 <stealth222> I have a database that might have some of that information
273 2013-01-18 16:38:20 <stealth222> never mined it for that statistic - but I could :)
274 2013-01-18 16:39:01 <stealth222> basically, the database timestamped transactions as it saw them and then also timestamped the time it saw blocks including them
275 2013-01-18 16:40:59 <stealth222> argh, timestamped the time...lol
276 2013-01-18 16:42:18 <stealth222> but I didn't have it running since the beginning of bitcoin
277 2013-01-18 16:42:28 <stealth222> furthest back it might go is july of 2012
278 2013-01-18 16:42:44 <stealth222> before that, it just has blocks - no live transactions
279 2013-01-18 16:43:13 <stealth222> also, it hasn't been running continuously - it's been running mostly continuously...so it might have missed a few spots
280 2013-01-18 16:43:53 <stealth222> what do you need this data for?
281 2013-01-18 17:02:43 <legitnick> I've got some tx's that still haven't confirmed after 15 days..
282 2013-01-18 17:30:54 <corbs132> hey, is anyone here?
283 2013-01-18 17:34:44 <corbs132> i'm trying to modify electrum-server to work on a different currency, does anyone know if this has been done before?
284 2013-01-18 19:31:31 <Pucilowski> What prevents a pool miner that finds a solution from claiming the reward for himself rather than submitting it to the operator for sharing?
285 2013-01-18 19:32:12 <corbs132> oh snap
286 2013-01-18 19:32:13 <Luke-Jr> Pucilowski: the pool checks shares by ensuring they claim the solution to approved output(s)
287 2013-01-18 19:32:15 <corbs132> that's a good question
288 2013-01-18 19:33:25 <Pucilowski> I don't really understand Luke-Jr
289 2013-01-18 19:33:51 <Luke-Jr> you won't until you look into how pooled mining works in more detail ;)
290 2013-01-18 19:34:49 <Pucilowski> Luke-Jr: any good resources explaining it?
291 2013-01-18 19:35:15 <Luke-Jr> Pucilowski: there's a number of wiki pages covering it
292 2013-01-18 19:53:57 <theorbtwo> Hm. Transactions that confim only very slowly coupled with transactions in-flight being non-cancelable seems like a pratical problem.
293 2013-01-18 19:54:59 <theorbtwo> Assume legitnick tried to pay for something with that 15-day transaction. It doesn't seem to go through, though. Does he have any recourse to paying for it again, but being unable to spend the coins he already sent?
294 2013-01-18 19:56:16 <legitnick> when I imported the priv key to bitcoin-qt it showed up in my balance
295 2013-01-18 19:57:29 <legitnick> are those coins gone forever?
296 2013-01-18 20:02:13 <phantomcircuit> legitnick, huh?
297 2013-01-18 20:02:36 <Luke-Jr> theorbtwo: that's why Bitcoin-Qt forces fees in some cases
298 2013-01-18 20:03:10 <Luke-Jr> legitnick: importing an untrusted key is a bad idea, huh?
299 2013-01-18 20:03:26 <legitnick> it was my key from blockchain.info
300 2013-01-18 20:03:53 <gavinandresen> Luke-Jr: is the Spesmilo project dead?
301 2013-01-18 20:04:18 <Luke-Jr> gavinandresen: seems to be
302 2013-01-18 20:04:35 <gavinandresen> mind if I edit the wiki page to say so?
303 2013-01-18 20:04:41 <Luke-Jr> gavinandresen: I stopped working on it when Bitcoin-Qt came along, at least; and I don't think genjix has touched it in forever
304 2013-01-18 20:04:43 <Luke-Jr> feel free
305 2013-01-18 20:06:26 <Luke-Jr> gavinandresen: I'm surprised to learn it no longer works, though - did we break compatibility at some point? :o
306 2013-01-18 20:06:42 <gavinandresen> dunno. I'm not motivated to find out, either....
307 2013-01-18 20:07:41 <legitnick> is there a way to get a list of unconfirmed tx's based on an address?
308 2013-01-18 20:08:31 <Pucilowski> legitnick: they never made it past your client
309 2013-01-18 20:09:07 <legitnick> I know
310 2013-01-18 20:09:12 <Pucilowski> where is qt's mempool stored?
311 2013-01-18 20:09:23 <Pucilowski> wouldnt removing that remove unconfirmed transactions?
312 2013-01-18 20:10:15 <gavinandresen> qt's mempool is stored in memory. But wallet transactions are stored in wallet.dat, and 0-confirmed wallet transactions are added to the memory pool and re-broadcast after startup
313 2013-01-18 20:11:00 <gavinandresen> if you hacked -qt to send a transactions that won't confirm, then you'll need to hack it to remove the transaction from wallet.dat
314 2013-01-18 20:14:50 <legitnick> I already tried deleting the tx's then reloading it
315 2013-01-18 21:02:13 <Akiraa> I am a little confused what the computational work of Bitcoin is, we are trying to find a hash of the form: 0000xxxx where xxxx is the current target and the difficulty is (1 - the number of leading zero bits)
316 2013-01-18 21:04:04 <sipa> not entire
317 2013-01-18 21:04:07 <sipa> * entirely
318 2013-01-18 21:04:17 <sipa> the hash is 256-bit number
319 2013-01-18 21:04:41 <sipa> this number is interpreted as a normal number
320 2013-01-18 21:04:54 <sipa> the target is also just a number, of similar length
321 2013-01-18 21:05:25 <sipa> the number 0x00000000FFFF0000.... (48 0's follow) is the highest possible target
322 2013-01-18 21:05:41 <sipa> the difficulty is the fraction of that number divided by the actual target
323 2013-01-18 21:06:20 <sipa> so, we're looking for hash(blockheader) < 0x0000FFFF0000.... / difficulty
324 2013-01-18 21:07:34 <Luke-Jr> (where hash(blockheader) is the hash encoded in big endian, then reinterpreted as little endian???)
325 2013-01-18 21:37:35 <Akiraa> sipa: 0x0000FFFF0000 / difficulty, that's integer division?
326 2013-01-18 21:37:55 <Akiraa> or perhaps modular inverse
327 2013-01-18 21:38:07 <sipa> just integer division
328 2013-01-18 21:38:11 <Akiraa> ok
329 2013-01-18 21:38:21 <sipa> in a modular group, "<" doesn't make sense, really
330 2013-01-18 21:38:35 <Akiraa> the blockheader is the hash of all previous blocks?
331 2013-01-18 21:38:46 <sipa> no, it's the header of a single block
332 2013-01-18 21:38:54 <sipa> however, it contains the hash of the header of the current block
333 2013-01-18 21:39:04 <Akiraa> and the current block being the hash of the transactions
334 2013-01-18 21:39:04 <sipa> eh
335 2013-01-18 21:39:18 <sipa> the current block header contains the hash of the previous block header
336 2013-01-18 21:39:28 <sipa> and the root hash of the transaction merkle tree of the current block
337 2013-01-18 21:39:53 <Akiraa> ok
338 2013-01-18 21:40:04 <sipa> and a few other things (version number, timestamp, nonce, difficulty)
339 2013-01-18 21:40:55 <sipa> Akiraa: https://en.bitcoin.it/wiki/Block_hashing_algorithm
340 2013-01-18 21:50:02 <Akiraa> since when are 10^-8 BTCs called 'satoshi' ?
341 2013-01-18 21:50:46 <sipa> when i first read about it, in november-december 2010, not yet
342 2013-01-18 21:50:57 <sipa> but not too long afterwards the term was "coined"
343 2013-01-18 21:51:22 <sipa> i do remember discussions on the forum about how it should be called
344 2013-01-18 21:57:37 <Akiraa> does bitcoin prove that you can't have a peer-to-peer electronic token without some sacrifice in anonymity?
345 2013-01-18 21:57:41 <Akiraa> i.e. pseudonymity
346 2013-01-18 21:58:09 <Akiraa> since you are not referring to a particular authority or physical backing to settle value
347 2013-01-18 21:58:36 <Akiraa> and so it relies on a public roster of transactions
348 2013-01-18 21:59:30 <sipa> i don't think it proves anything of that kind
349 2013-01-18 22:00:41 <Akiraa> so we may yet have a fully anonymous system (one that hides transactions)?
350 2013-01-18 22:05:00 <gavinandresen> Akiraa: I seem to remember somebody offering a proof that "fully anonymous" and "no third part" were mutually exclusive. But I can't remember what the proof was. And http://arxiv.org/abs/1212.3257 has a nice description of a very private payment scheme.
351 2013-01-18 22:40:24 <Akiraa> sipa: the number of hashes necessary to complete a block is then 2^difficulty?
352 2013-01-18 22:41:54 <sipa> Akiraa: no, 2^48*(difficulty/65535)
353 2013-01-18 22:42:07 <sipa> Akiraa: hash < max_target / difficulty
354 2013-01-18 22:42:38 <sipa> number_of_hashes is 2^256 / target
355 2013-01-18 22:42:57 <sipa> and max_target is 2^208 * 65535
356 2013-01-18 22:44:05 <sipa> Akiraa: difficulty being "the number of zeroes at the start of the hash" is a common myth
357 2013-01-18 22:44:17 <sipa> though it is certainly related
358 2013-01-18 22:44:40 <Akiraa> what happens to the remaining 32 bits of sha-256?
359 2013-01-18 22:44:55 <sipa> ?
360 2013-01-18 22:45:28 <Akiraa> oh, there are always 4 bytes of zero
361 2013-01-18 22:45:31 <sipa> yes
362 2013-01-18 22:46:08 <Akiraa> why hot have the max target just 2^255 ?
363 2013-01-18 22:46:21 <sipa> why not 2^256-1 ?
364 2013-01-18 22:46:26 <sipa> ask satoshi :p
365 2013-01-18 22:46:41 <Akiraa> ok, presuming that sha-256 does not have 256 bits of entropy, right
366 2013-01-18 22:46:58 <sipa> i assume he wanted a minimal non-trivial difficulty right from the start
367 2013-01-18 22:47:12 <Akiraa> which certainly it does not have :)
368 2013-01-18 22:47:44 <sipa> very close to it, though
369 2013-01-18 22:47:45 <Akiraa> we are at a point where it would be unlikely for ever to be a bitcoin 2.0, right?
370 2013-01-18 22:48:06 <Akiraa> there is a lot of value and momentum sunk in this yet-beta system
371 2013-01-18 22:48:52 <sipa> even if we want to do a non-controversial hard fork, it will have to be decided/implemented/tested/announced years in advance
372 2013-01-18 22:49:04 <gmaxwell> sipa: oh good, It's nice to see your checkblocks turned out to catch an intermittent rule violation, though a somewhat obscure one.
373 2013-01-18 22:49:49 <sipa> gmaxwell: yeah, i respect satoshi massively, but not enough to give him an instant-hardfork-switch :p
374 2013-01-18 22:51:42 <Akiraa> there is currently a central authority, namely the bitcoin foundation, which releases the source code
375 2013-01-18 22:51:56 <Akiraa> which has significant influence on peers, right?
376 2013-01-18 22:52:02 <gavinandresen> Akiraa: the bitcoin foundation doesn't release the source code
377 2013-01-18 22:52:11 <Akiraa> eh, the standard bitcoin client
378 2013-01-18 22:52:16 <sipa> not even
379 2013-01-18 22:52:25 <Akiraa> or the builds for it
380 2013-01-18 22:52:28 <gavinandresen> nope
381 2013-01-18 22:52:28 <sipa> not even
382 2013-01-18 22:52:54 <sipa> and even if it did, it can't introduce a change in the software that breakes a network rule
383 2013-01-18 22:52:56 <Luke-Jr> Akiraa: the Foundation just pays Gavin and various other bounties and such
384 2013-01-18 22:53:05 <Luke-Jr> Akiraa: it has no influence over what anyone does, in theory
385 2013-01-18 22:53:26 <Akiraa> wasn't there a change a while ago that defeated inflated messages attached to block chains?
386 2013-01-18 22:53:31 <muhoo> is the right repository nexus.bitcoinj.org? i'm getting 500s Could not transfer artifact com.google:bitcoinj:pom:0.6.1 from/to google (http://nexus.bitcoinj.org/content/repositories/releases): Failed to transfer file: http://nexus.bitcoinj.org/content/repositories/releases/com/google/bitcoinj/0.6.1/bitcoinj-0.6.1.pom. Return code is: 500, ReasonPhrase:Server Error.
387 2013-01-18 22:53:40 <gmaxwell> Akiraa: where did you get the idea that the foundation releases the source code? I'd like to go correct whatever is confusing or wrong on that.
388 2013-01-18 22:53:49 <Akiraa> i.e. some people figured out you could use the block chain as a kind of append-only database
389 2013-01-18 22:53:54 <Akiraa> and started pouring data into it
390 2013-01-18 22:54:00 <gavinandresen> Akiraa: peer pressure stopped that.
391 2013-01-18 22:54:32 <muhoo> yep, 500 http://nexus.bitcoinj.org/content/repositories/releases/com/google/bitcoinj/0.6.1/bitcoinj-0.6.1.pom . hmm. is there a mirror?
392 2013-01-18 22:54:49 <Akiraa> so what stops people now from piling prepared data into the block chain?
393 2013-01-18 22:55:06 <sipa> anti-DoS rules, enforced by most nodes in the network
394 2013-01-18 22:55:18 <gmaxwell> gavinandresen: more than that, transaction fees had made that uninteresting before anyone was talking about it.
395 2013-01-18 22:55:34 <Akiraa> authoritative, distributed, append-only database with timestamping may be a good unintended feature of bitcoin
396 2013-01-18 22:55:40 <sipa> Akiraa: and the common knowledge that screwing up the user experience now may have an adverse effect on the economics of the system later
397 2013-01-18 22:55:52 <gavinandresen> gmaxwell: blockchain.info had the append-a-message feature, but we convinced Ben it was a bad idea...
398 2013-01-18 22:55:53 <muhoo> Akiraa: sounds like git
399 2013-01-18 22:56:07 <sipa> Akiraa: the bitcoin block chain is a tremendously expensive beast to maintain
400 2013-01-18 22:56:18 <muhoo> or couchdb, actually.
401 2013-01-18 22:56:35 <Akiraa> of course, but the costs are distributed
402 2013-01-18 22:56:42 <sipa> Akiraa: this cost is hidden, as miners get paid from the monetary inflation, and many other nodes run it for not necessary economic reasons
403 2013-01-18 22:56:43 <muhoo> if you want a general-purpose, immutable append-only db, i'd recommend couchdb.
404 2013-01-18 22:56:49 <gmaxwell> Akiraa: _externalized_ but not really distributed.
405 2013-01-18 22:57:01 <Akiraa> (mind you, loading the block chain from a year ago till today took many hours on a top PC)
406 2013-01-18 22:57:25 <Akiraa> muhoo: that is not authoritative
407 2013-01-18 22:57:42 <muhoo> Akiraa: what is the authoritative maven source for bitconj jars?
408 2013-01-18 22:57:44 <Akiraa> in the sense, contracts may be signed with a reference made in the block chain
409 2013-01-18 22:57:56 <Akiraa> or a hash of it stored there
410 2013-01-18 22:57:59 <Prattler> hopefully ultraprune can one day get rid of all the junk :)
411 2013-01-18 22:58:09 <Akiraa> ultimate non-repudiability
412 2013-01-18 22:58:14 <muhoo> this page implies that it is authoritative: http://code.google.com/p/bitcoinj/wiki/UsingMaven
413 2013-01-18 22:58:15 <sipa> Akiraa: timestamping data via the block chain is possible without actually storing the data being timestamped
414 2013-01-18 22:58:33 <sipa> Akiraa: there is a system called chronobit that does this with O(1) storage requirements
415 2013-01-18 22:58:58 <Akiraa> muhoo: authoritative, but maintained by google
416 2013-01-18 22:59:00 <gmaxwell> Akiraa: current chain on current code from a local peer takes about an hour.
417 2013-01-18 22:59:08 <Akiraa> muhoo: bitcoin is something no government can force to be
418 2013-01-18 22:59:19 <muhoo> bitcoinj.org is google?
419 2013-01-18 22:59:32 <gmaxwell> Akiraa: Did you see my earlier question? 15:54 <@gmaxwell> Akiraa: where did you get the idea that the foundation releases the source code? I'd like to go correct whatever is confusing or wrong on that.
420 2013-01-18 22:59:53 <muhoo> bitcoinj.org is not google, it is :Mike Hearn
421 2013-01-18 22:59:58 <muhoo> according to whios
422 2013-01-18 22:59:59 <muhoo> whois
423 2013-01-18 23:00:11 <Akiraa> gmaxwell: who creates the builds on bitcoin.org?
424 2013-01-18 23:00:12 <sipa> mike hearn developed bitcoinj as a 20% at google
425 2013-01-18 23:00:38 <sipa> Akiraa: "we" do
426 2013-01-18 23:00:44 <muhoo> ah. ok, can i ask a simple, if perhaps stupid question then: what maven repository is authoritative for bitcoinj jar releases?
427 2013-01-18 23:00:47 <Akiraa> and if you have control of the official client, you may influence the way the network behaves
428 2013-01-18 23:00:47 <gmaxwell> Akiraa: they are built with a decenteralized determinstic build process that enables multiple people to get bit-identical results.
429 2013-01-18 23:00:55 <Akiraa> like say, you could ban 'tainted' coins
430 2013-01-18 23:00:56 <sipa> Akiraa: we use a deterministic build environment called gitian
431 2013-01-18 23:01:02 <gmaxwell> Akiraa: and multiple people build every build and one isn't posted unless they mathc.
432 2013-01-18 23:01:16 <gmaxwell> match*
433 2013-01-18 23:01:24 <sipa> Akiraa: you're able to do repeat that build (though it's a bit involved) and end up with a byte-for-byte identical binary
434 2013-01-18 23:01:25 <Luke-Jr> Akiraa: there is no "official" client; there is only popular client, which can change overnight if someone tried to do something stupid
435 2013-01-18 23:01:43 <gavinandresen> Akiraa: we've been working pretty hard the last year on several things to make it easier for alternative implementations, exactly to encourage decentralization
436 2013-01-18 23:02:14 <sipa> Akiraa: also note that on the clients page of bitcoin.org you'll find links to other clients
437 2013-01-18 23:02:25 <sipa> which are being developed independently
438 2013-01-18 23:02:27 <gmaxwell> Akiraa: But, I'm still not following how that made you think that the foundation was releasing things?
439 2013-01-18 23:02:48 <Akiraa> gmaxwell: sorry, it was just a confusion
440 2013-01-18 23:02:50 <Joric> if gavinandresen wouldn't codereview well enough )
441 2013-01-18 23:03:01 <muhoo> guys, i'm sorry, maybe i'm not smart enough to understand: where is there a maven repo i can rely on having the bitcoinj release library?
442 2013-01-18 23:03:13 <sipa> muhoo: BlueMatt or TD probably know
443 2013-01-18 23:03:19 <gmaxwell> Akiraa: yea, it's okay??? understandable even??? I just wondered if there was something specifically pointing at the foundation that I should have fixed. Sounds like no. OKAY
444 2013-01-18 23:04:04 <muhoo> sipa: thanks, hopefully can catch them online sometime
445 2013-01-18 23:12:55 <Akiraa> what happens if a potential bitcoin peer does not have control over her router (can't set ports that bitcoin uses)
446 2013-01-18 23:13:09 <Akiraa> she won't be able to get the latest blocks, right?
447 2013-01-18 23:13:49 <sipa> you don't need an incoming connection to connect to the network
448 2013-01-18 23:17:30 <Akiraa> if someone decides to spend bitcoins twice, say by posting different transactions to different peers (same source address, but different recepient)
449 2013-01-18 23:17:57 <Akiraa> would the network invalidate the transaction, or just take one at random
450 2013-01-18 23:18:15 <sipa> one part of the transaction would consider one version valid, and another the other
451 2013-01-18 23:18:27 <Akiraa> and then just go with that which has been validated by the most peers
452 2013-01-18 23:18:37 <sipa> this will be resolved by the time either manages to be mined into a block, as two conflicting ones cannot be in the same chain
453 2013-01-18 23:18:41 <gmaxwell> most peers has nothing to do with it.
454 2013-01-18 23:18:46 <Akiraa> sipa: you mean one part of the network would consider one valid
455 2013-01-18 23:18:57 <sipa> Akiraa: "unconfirmed valid"
456 2013-01-18 23:19:17 <gmaxwell> Akiraa: Sounds like you might benefit from this high level overview of how the system works: http://bitcoin.org/bitcoin.pdf
457 2013-01-18 23:19:43 <Akiraa> the convention is what, transactions made 6 blocks ago are valid and confirmed?
458 2013-01-18 23:20:02 <sipa> 1 confirmation is "confirmed", but not necessarily considered safe
459 2013-01-18 23:20:04 <gmaxwell> Things like 'most peers' would fail horribly as soon as some attacker decided to just start up lots of apparent peers. (a sybil attack)
460 2013-01-18 23:21:47 <Akiraa> so you must wait for a certain number of blocks to pass
461 2013-01-18 23:22:01 <sipa> that's the general advise, yes
462 2013-01-18 23:22:45 <sipa> *advice
463 2013-01-18 23:23:24 <Akiraa> any convention on that number?
464 2013-01-18 23:23:35 <sipa> 6, as established by satoshi's paper
465 2013-01-18 23:23:45 <sipa> as you said
466 2013-01-18 23:24:09 <Akiraa> the official client will show your balance after a certain number of confirmations, not how many blocks ago
467 2013-01-18 23:24:37 <Luke-Jr> Akiraa: confirmations = how many blocks ago
468 2013-01-18 23:24:52 <sipa> well, included in the last block = 1 confirmation
469 2013-01-18 23:24:53 <Akiraa> oh, ok
470 2013-01-18 23:25:00 <sipa> included in the last but one block = 2 confirmations
471 2013-01-18 23:25:14 <Akiraa> if nobody bothered to verify it?
472 2013-01-18 23:25:24 <Akiraa> it would get included in the next block if someone did?
473 2013-01-18 23:25:27 <gavinandresen> everybody verifies transactions
474 2013-01-18 23:25:38 <sipa> every full node verifies every transaction it sees
475 2013-01-18 23:25:40 <Akiraa> i.e. is there a risk of transactions not being picked up?
476 2013-01-18 23:25:55 <sipa> miners choose for themself which transactions to include in blocks
477 2013-01-18 23:26:02 <sipa> and yes, there is such a risk
478 2013-01-18 23:26:23 <gavinandresen> sure, transmit a big transaction with no fees and it will never get into a block. The reference implementation won't let you do that, though
479 2013-01-18 23:26:36 <gavinandresen> (big-in-kilobytes, not big-in-bitcoins)
480 2013-01-18 23:27:27 <Akiraa> so if Bob signs Alice's transaction but fails to relay the signature to his peers, Bob would have an outdated version of the block chain
481 2013-01-18 23:27:43 <Akiraa> and Alice's transaction not validated
482 2013-01-18 23:27:51 <Akiraa> assuming only Bob verified it
483 2013-01-18 23:28:11 <Luke-Jr> the only person signing the transaction is the person sending it
484 2013-01-18 23:28:56 <sipa> Akiraa: transactions are broadcasted on the network, but they are not authorative or part of the block chain, just broadcasting
485 2013-01-18 23:29:06 <sipa> Akiraa: it's the blocks that make up the block chain
486 2013-01-18 23:31:21 <gmaxwell> Akiraa: you ought to go read that pdf. It sounds like you think that bitcon works by random peers signing transactions and then taking some kind of sybil-vulnerable majority. That kind of stuff is not at all how bitcoin works, but it's a common misunderstanding.
487 2013-01-18 23:32:05 <muhoo> sipa: thank you, i'd never understood why transaction fees were necesary. now it makes sense.
488 2013-01-18 23:32:44 <randy-waterhouse> anybody have any data on how many multi-sig transactions are/have been taking place?
489 2013-01-18 23:34:21 <sipa> yw
490 2013-01-18 23:35:07 <Akiraa> gmaxwell: I was aware it was not "one name, one vote" but rather "one CPU, one vote" :)
491 2013-01-18 23:35:49 <muhoo> so how bi is "big" in terms of kb?
492 2013-01-18 23:36:00 <muhoo> heh, how big is big
493 2013-01-18 23:36:18 <gmaxwell> Akiraa: in a random ballot election, which isn't exactly what most people think about when they speak of voting.
494 2013-01-18 23:36:25 <gmaxwell> (http://en.wikipedia.org/wiki/Random_ballot)
495 2013-01-18 23:36:43 <muhoo> i'm pretty sure bitcoinj includes transaction fees by default, but i'm curious what's the minimum that's safe to not do so
496 2013-01-18 23:36:51 <Akiraa> yeah, in ballots, there is a natural scarcity of people
497 2013-01-18 23:37:03 <Akiraa> you can't sybyl people
498 2013-01-18 23:37:14 <Akiraa> well, that creates problems in a post-singularity society, doesn't it :)
499 2013-01-18 23:37:31 <Akiraa> (if anyone read Charlie Stross' Accelerando )
500 2013-01-18 23:49:46 <Akiraa> I don't quite understand why you need hash(hash(...)) instead of a single hash
501 2013-01-18 23:49:54 <Akiraa> other than doubling the difficulty perhaps
502 2013-01-18 23:49:55 <sipa> Nobody does.
503 2013-01-18 23:50:02 <Akiraa> but then, that's a kind of hardcoded way of doing it
504 2013-01-18 23:50:33 <sipa> Satoshi probably felt that was 'safer'
505 2013-01-18 23:53:42 <Luke-Jr> without hash(hash(???)), mining wouldn't even do one full hash round :P