1 2014-03-02 01:29:19 <alex_fun> :)
2 2014-03-02 01:33:19 <alex_fun> hello, who here compiled bitcoin osx qt? :D
3 2014-03-02 01:33:40 <alex_fun> i compiled on 10.8 yet to make it work for 10.9 hehe
4 2014-03-02 01:34:27 <alex_fun> some dlyb looks for its dependencies outside app bundle :)
5 2014-03-02 01:41:52 <nezZario> btw, any word on when/if multisig will be implemented in the gui of btc?
6 2014-03-02 01:42:06 <nezZario> I mean, I'd be happy to donate to a fund
7 2014-03-02 01:42:18 <jakov> there are some GUIs, like that javascript website that does it
8 2014-03-02 01:42:51 <andytoshi> is CoinVault released yet?
9 2014-03-02 01:42:54 <andytoshi> CodeShark: ^
10 2014-03-02 01:43:53 <andytoshi> coinvault is a multisig wallet which uses keychains. you exchange public chains with your peers and that enables you to construct m-of-n txes with them
11 2014-03-02 02:10:04 <kanzure> i am running with -regtest and there's 6 blocks, but getunconfirmedbalance returns 0. why?
12 2014-03-02 02:14:12 <owowo> are you MT and have you "lost" the key?
13 2014-03-02 02:14:12 <sipa> kanzure: getunconfirmedbalance probably counts unconfirmed but not immature balance
14 2014-03-02 02:14:24 <sipa> please
15 2014-03-02 02:14:45 <owowo> ya, sorry. I could not resist. ;)
16 2014-03-02 02:15:14 <gmaxwell> sipa: perhaps it should count immature? I'm not sure about that. since it's not counted in the normal balance.. probably should.
17 2014-03-02 02:15:14 <kanzure> i'm gox and so is my wife
18 2014-03-02 02:15:45 <sipa> gmaxwell: perhaps, yes
19 2014-03-02 02:15:51 <kanzure> after calling "setgenerate true" a few hundred times, there's a height=162 but only 3000 BTC
20 2014-03-02 02:16:02 <kanzure> 3000 BTC is reported by "getbalance"
21 2014-03-02 02:16:09 <sipa> kanzure: sounds perfectly normal
22 2014-03-02 02:16:16 <sipa> it takes 101 blocks before coins mature
23 2014-03-02 02:16:44 <sipa> gmaxwell: from a user's point of view there is little difference between unconfirmed and immature balance (both are "if nothing goes wrong, you'll eventually have this")
24 2014-03-02 02:16:55 <gmaxwell> yea, agreed.
25 2014-03-02 02:17:18 <gmaxwell> in general making immature look more like unconfirmed would be helpful for making people handle corner cases right.
26 2014-03-02 02:17:20 <kanzure> i wouldn't mind a separate unconfirmed vs. immature rpc command as long as both are available
27 2014-03-02 02:17:41 <gmaxwell> kanzure: that makes it more likely people who only very infrequently have immature coins will handle them incorrectly.
28 2014-03-02 02:17:58 <gmaxwell> I _think_ its unconditionally safe to treat them as immature.
29 2014-03-02 02:18:02 <gmaxwell> er unconfirmed.
30 2014-03-02 02:18:22 <kanzure> but i believe the current behavior of getunconfirmedbalance does not include immature blocks?
31 2014-03-02 02:18:57 <kanzure> cool, yeah i'm sure that will help with testing edgecases on third-party services
32 2014-03-02 02:21:59 <gmaxwell> there are already a bunch of things that will just never credit the user if they pay with generated coin, if instead they just took a really long time to credit the user that would be an improvement. (and if they credited instantly that would be an anti-improvement)
33 2014-03-02 02:22:33 <kanzure> oh is this because the services never rescan?
34 2014-03-02 02:23:03 <kanzure> presumably a service should be able to replay their entire transaction history and come up with the same result as their internal db
35 2014-03-02 02:24:30 <kanzure> why is it called regtest?
36 2014-03-02 02:24:44 <gmaxwell> because its for regression testing
37 2014-03-02 02:27:28 <kanzure> is there a certain prefix for regtest addresses? or can i use testnet address prefixes?
38 2014-03-02 02:38:01 <gmaxwell> mainnet, which is prehaps a bit annoying.
39 2014-03-02 02:38:30 <gmaxwell> makes it a bit risky to use, a few times I've sent my mainnet bitcoind testnet sendtoaddresses.
40 2014-03-02 02:39:10 <gmaxwell> "hurrah I just gave a random person on IRC 10 BTC!" (fortunately in my case thats blocked by both wallet encryption and the different address version)
41 2014-03-02 03:10:43 <Tecan> is there somewhere i can buy a storefront for bitcoin ?
42 2014-03-02 04:00:35 <davec> gmaxwell: are you sure it's mainnet for regtest. I'm pretty sure it's testnet as class CRegTestParams : public CTestNetParams {
43 2014-03-02 04:02:31 <gmaxwell> hm. I thought it was mainnet but I see that its testnet here. It used to be mainnet with the patches.
44 2014-03-02 04:04:11 <davec> cool. I agree though that it would be better to have a unique prefix. I brought it up just a couple of days ago and it seemed like the people in here at the time were happy with it being testnet
45 2014-03-02 04:08:29 <olalonde> perhaps I am misunderstanding something but isn't "scriptPubKey" a misleading name?
46 2014-03-02 04:09:20 <olalonde> given that it isn't necessarily solved by a public key
47 2014-03-02 04:09:27 <andytoshi> olalonde: bitcoin's signature algorithm is script, not ecdsa
48 2014-03-02 04:10:34 <andytoshi> so the scriptPubkey is public, it's on the blockchain, but typical scripts have some secret input (which may include a valid ECDSA signature, but that's incidental), so that's the private half
49 2014-03-02 04:10:42 <andytoshi> perhaps scriptSig is a misleading name then :)
50 2014-03-02 04:11:02 <jcorgan> olalonde: indeed, 'scriptPubKey' is somewhat misleading, it is the name for the script that runs after a spending scriptSig to validate the stack and determine whether the spending scriptSig is valid
51 2014-03-02 04:11:13 <olalonde> right
52 2014-03-02 04:12:01 <jcorgan> the most common scriptPubkey is one that allows spending by proving you have the private key (and hence public key) that corresponds to an address
53 2014-03-02 04:12:07 <olalonde> I think I would have named those scriptSig->scriptSolution scriptPubKey->scriptChallenge
54 2014-03-02 04:12:13 <jcorgan> which is probably where it go its name
55 2014-03-02 04:12:19 <jcorgan> got
56 2014-03-02 04:12:21 <olalonde> right
57 2014-03-02 04:12:34 <jcorgan> agree, i'd have called it spendingScript and validationScript
58 2014-03-02 04:12:37 <olalonde> too late now :P
59 2014-03-02 04:12:43 <jcorgan> right :)
60 2014-03-02 04:14:05 <olalonde> maybe non standard transactions was an afterthought of satoshi
61 2014-03-02 04:14:28 <jcorgan> hard to say, i wasn't around and he's not answering :)
62 2014-03-02 04:14:34 <olalonde> haha
63 2014-03-02 04:14:47 <andytoshi> i think the existence of script suggests that he thought about some of this stuff
64 2014-03-02 04:15:14 <olalonde> if I recall correctly, scripts are not discussed in the original paper
65 2014-03-02 04:15:28 <andytoshi> no, but they were in the original implementation
66 2014-03-02 04:15:36 <andytoshi> the original paper is really really underspecified
67 2014-03-02 04:16:05 <olalonde> ok
68 2014-03-02 04:17:01 <olalonde> did he version control his progress until first public release?
69 2014-03-02 04:17:14 <andytoshi> there is a link to the mailing list announcement floating around, i can't find it :(
70 2014-03-02 04:17:32 <olalonde> ok no problem
71 2014-03-02 04:17:42 <andytoshi> i don't think so, i believe he was emailing .zips of code around >.>
72 2014-03-02 04:17:50 <olalonde> haha ok
73 2014-03-02 04:18:59 <olalonde> was the first release already cross platform?
74 2014-03-02 04:19:22 <gmaxwell> no. it was windows only. (though the code was reasonably portable)
75 2014-03-02 04:19:30 <andytoshi> http://download.wpsoftware.net/bitcoin/bitcoin-0.1.0.tgz
76 2014-03-02 04:19:36 <olalonde> ok thanks
77 2014-03-02 04:19:57 <gmaxwell> I don't think scriptPubKey is even the the slighest bit misleading, in fact its the opposite: it's enlightening.
78 2014-03-02 04:20:15 <Luke-Jr> was*
79 2014-03-02 04:20:20 <gmaxwell> The scriptPubkey _is_ a public key. It's a public key for the "bitcoin script hybrid signature system".
80 2014-03-02 04:21:15 <olalonde> right
81 2014-03-02 04:21:24 <jcorgan> hmm, hadn't thought of it that way, i see your point
82 2014-03-02 04:21:59 <olalonde> in that perspective, scriptSig makes sense as well
83 2014-03-02 04:23:14 <gmaxwell> it makes more sense once you start talking about more poweful zero knoweldge proof systems which are often called "zero knoweldge signature of knoweldge"â a system that lets you prove (via a signature) you know some fact, without revealing (all of the) details of the fact... but which has a mechnism to identify which fact you're proving (via the public key)
84 2014-03-02 04:23:55 <gmaxwell> the only part of bitcoin script which is zero knoweldge is the proof you know the discrete log of some ec pointâ none the less... :)
85 2014-03-02 04:25:40 <olalonde> it was a bit confusing to me because I thought the "PubKey" part referred to the public key of private keys who generated the public key hash in standard transactions
86 2014-03-02 04:26:22 <olalonde> so the "pubKey" in scriptPubKey refers to the public key of the "bitcoin script hybrid signature system", not the ECDSA public key
87 2014-03-02 04:29:17 <gmaxwell> yea. Correct. the scriptPubKey is the public key for "script".
88 2014-03-02 04:47:11 <olalonde> " Note that while transactions like this are fun, they are not secure, because they do not contain any signatures and thus any transaction attempting to spend them can be replaced with a different transaction sending the funds somewhere else." on https://en.bitcoin.it/wiki/Script . If I understand correctly, the warning here is that a malicious miner could use your scriptSig and modify the transaction
89 2014-03-02 04:50:52 <andytoshi> that's right, only OP_CHECKSIG is affected by the outputs, so if you don't have that anywhere you can simply replace them
90 2014-03-02 04:51:58 <olalonde> andytoshi: ok thanks
91 2014-03-02 05:11:01 <olalonde> http://blockexplorer.com/rawtx/d4950d1f2cdc908eebc472600bc5c8e3c990fd3fed7f7fa6b3cf85cf61c3c2f8
92 2014-03-02 05:11:13 <olalonde> what does the "v" in vin and vout stand for?
93 2014-03-02 05:11:32 <olalonde> I understand vin_sz is the number of inputs, but why not just name it in_sz?
94 2014-03-02 05:11:43 <olalonde> vector?
95 2014-03-02 05:25:50 <gmaxwell> vector, yea.
96 2014-03-02 05:44:03 <tinaivanova> http://coinsight.org/mtgox.html
97 2014-03-02 05:44:08 <tinaivanova> why is the number changing
98 2014-03-02 05:45:15 <tinaivanova> gmaxwell:
99 2014-03-02 05:50:48 <YabaDabaDoge> what is going on a Gox?
100 2014-03-02 05:51:49 <gmaxwell> This is offtopic for this channel, please take it elsewhere.
101 2014-03-02 05:52:05 <gmaxwell> (e.g. try ##mtgox-chat )
102 2014-03-02 05:53:49 <embicoin> Do you recommend to use something like redis for a little personal c# project or would you stick to sqlite or leveldb? (I am just starting with db's so I can go for anyone)
103 2014-03-02 05:54:15 <embicoin> The db will feed itself from the daemon
104 2014-03-02 07:25:50 <gmaxwell> Is there a reason why the " tighten multisig non-standard rules: do not relay pubkeys above 65 bytes" didn't just test for the size being exactly equal to 33 or 65 bytes?
105 2014-03-02 07:26:11 <gmaxwell> or even checking that the size and compression flag agree too?
106 2014-03-02 07:26:48 <Luke-Jr> gmaxwell: because spammers will just *add* data to make it pass?
107 2014-03-02 07:26:59 <Luke-Jr> *sigh*
108 2014-03-02 07:27:25 <gmaxwell> well the standard rules also do help people not footgun themsevles.
109 2014-03-02 07:27:40 <gmaxwell> e.g. without ... details.. mtgox wouldn't have been able to pay to \0 a couple years ago
110 2014-03-02 07:28:40 <gmaxwell> actually testing if the value is a valid point on the curve would be fun but its not cpu cheap, but at least a der encoding test is cheap.
111 2014-03-02 07:29:32 <Luke-Jr> gmaxwell: too bad we don't have a framework for low-priority checks
112 2014-03-02 07:29:41 <Luke-Jr> "only check this if the CPU is significantly idle"
113 2014-03-02 08:05:07 <Dickyb0b> was the bitcoin qt wallet coded in c++/winapi?
114 2014-03-02 09:54:24 <mn3monic> hi, need testnet bitcoins, anyone can help? thanks
115 2014-03-02 09:55:29 <gmaxwell> mn3monic: address, and will 10 do?
116 2014-03-02 09:56:59 <mn3monic> 2N6RaiLLDd22dLz2nmEtnKqR6mKJYj5jhxX
117 2014-03-02 09:57:03 <mn3monic> thanks
118 2014-03-02 09:57:43 <gmaxwell> k. there you go.
119 2014-03-02 09:57:53 <gmaxwell> dump it back in a faucet if you get bored with it
120 2014-03-02 10:00:03 <mn3monic> uh, didn't know there are testnet faucet availables. Just found one on appspot, i'll give them back :-)
121 2014-03-02 10:00:55 <gmaxwell> they don't always work or have coins. :)
122 2014-03-02 10:19:01 <mn3monic> I'm testing an online implemention of electrum client and looks nice. Any idea on how to be sure they don't store mnemonic passphrase, without looking at the source code ?
123 2014-03-02 10:19:13 <mn3monic> (if it's possible)
124 2014-03-02 10:22:08 <gmaxwell> online implementation? sounds dangerous, of course anything like that could have its code changed any any time...
125 2014-03-02 10:25:38 <mn3monic> gmaxwell: obv I agree and I wouldn't store my credentials there, as I wouldn't do with blockchain.info or similar, but it's very user friendly and I'm just trying to figure out if it can be a valid blockchain.info competitor. users loves online service, we have to deal with this :-)
126 2014-03-02 10:26:28 <gmaxwell> users also, apparently love leaving their funds in mtgox. :)
127 2014-03-02 10:27:24 <embicoin> Can anybody do a > strip -V and tell me the version or their strip executable please?
128 2014-03-02 10:28:33 <embicoin> Mine is 2.23.2 it does not seem to work in any form to reduce the size of my compiled binary
129 2014-03-02 10:36:56 <michagogo> cloud|mn3monic: run it offline?
130 2014-03-02 10:38:28 <mn3monic> michagogo|cloud, you mean something like: open the web page, then go offline, then put the mnemonic passphrase in it and try to login ?
131 2014-03-02 10:42:10 <michagogo> cloud|mn3monic: download it
132 2014-03-02 10:42:15 <michagogo> cloud|See if it works offline
133 2014-03-02 10:42:45 <michagogo> cloud|Note that that's not a guarantee that it doesn't store it and transmit later, you'd need to check the code
134 2014-03-02 10:42:58 <michagogo> cloud|(or, just only run it on an offline machine)
135 2014-03-02 10:44:25 <Tecan> 40 gb later and my blockchain is complete
136 2014-03-02 10:45:47 <mn3monic> whatever I do, it's clear that there is no warranty without the source code (and even then, there is no guarantee that online is implemented the same source code). I'll just pass on it... last time I thought that a service could be good (inputs.io) didn't end well however
137 2014-03-02 10:55:28 <TheSeven> BlueMatt: just a quick heads up, ubuntu trusty beta is around the corner (release end of april)
138 2014-03-02 10:55:50 <TheSeven> as that uses boost 1.54 one can't easily just install the saucy package
139 2014-03-02 10:56:18 <TheSeven> I've worked around it for now, but it would of course be nice if it works out of the box before the release :)
140 2014-03-02 10:56:57 <gmaxwell> hm? is it not statically linked in the package?
141 2014-03-02 11:06:50 <_syslog> salut, i coded a new (opensource ) faucet need testters.
142 2014-03-02 11:10:20 <Belxjander> _syslog: I'm willing to test
143 2014-03-02 11:10:26 <Belxjander> _syslog: please PM the address
144 2014-03-02 11:17:20 <TheSeven> gmaxwell: no idea, but the package has deps on packages that don't exist anymore in trusty
145 2014-03-02 11:42:19 <wallet42> multisig max is 16-of-16 right? cuz there is afaik no OP_17
146 2014-03-02 11:44:10 <gmaxwell> no, you can encode integers higher than 16... though there is a limit of 20 keys in the operation.
147 2014-03-02 11:45:22 <sipa> you can just push the byte array [0x11] if you need the number 17
148 2014-03-02 12:14:05 <michagogo> cloud|Okay, looks like my gbuild from DO is identical to the KVM builds
149 2014-03-02 12:16:35 <sipa> michagogo|cloud: the instructions in your PR mention -windows twice
150 2014-03-02 12:16:57 <michagogo> cloud|Hm?
151 2014-03-02 12:17:03 <michagogo> cloud|ACTION looks
152 2014-03-02 12:20:13 <michagogo> cloud|(it doesn't help that I have 2 VMs running atm...)
153 2014-03-02 12:35:19 <chichov> what's the correct term for a hash of zeros (see coinbase transaction)? null hash or zero hash maybe?
154 2014-03-02 12:52:34 <sipa> chichov: it's technically not a hash :)
155 2014-03-02 12:52:47 <sipa> chichov: just a zero 256-bit uint
156 2014-03-02 12:53:49 <shesek> wallet42, note that multisig outputs are technically limited to 3 total pubkeys
157 2014-03-02 12:54:07 <sipa> shesek: not true ijn p2sh
158 2014-03-02 12:54:09 <shesek> but with p2sh this isn't checked and you're limited by the size
159 2014-03-02 12:54:14 <sipa> right
160 2014-03-02 12:54:19 <shesek> which is something like 8 pubkeys I think?
161 2014-03-02 12:54:34 <sipa> with compressed pubkeys, up to 15
162 2014-03-02 12:59:34 <chichov> sipa: alright, thanks
163 2014-03-02 13:00:02 <chichov> are there any rules imposed on the transaction sequence number in coinbase transactions?
164 2014-03-02 13:01:22 <chichov> logically, it wouldn't make sense to create a transaction with a non-final sequence number
165 2014-03-02 13:01:29 <chichov> but I'm wondering about the technicalities
166 2014-03-02 13:04:54 <wallet42> sipa: so the limit is on the input.sigScript
167 2014-03-02 13:05:05 <wallet42> length or signing ops?
168 2014-03-02 13:05:29 <sipa> a data push is limited to 520 bytes
169 2014-03-02 13:05:43 <wallet42> datapush for the redeem script
170 2014-03-02 13:05:53 <sipa> as p2sh requires the redeem script to be pushes as a single item
171 2014-03-02 13:06:27 <_syslog> need testers for opensource faucet
172 2014-03-02 13:07:30 <wallet42> how come the subscript is executed at all?
173 2014-03-02 13:09:06 <wallet42> isnt the full script to unlock an output $inputScriptSig || $outputScriptPubKey ?
174 2014-03-02 13:09:50 <michagogo> cloud|sipa: gah
175 2014-03-02 13:10:04 <michagogo> cloud|I must have been tired or distracted or something when I did that
176 2014-03-02 13:10:09 <michagogo> cloud|The whole thing is a mess
177 2014-03-02 13:17:13 <warren> Luke-Jr: do you happen to know why the client historically (and now) subtracts 1000 bytes from the block priority size? arbitrary - 1000 is still arbitrary ...
178 2014-03-02 13:26:16 <sipa> wallet42: ???
179 2014-03-02 13:26:36 <sipa> wallet42: the subscript is what defimes the condition for spending
180 2014-03-02 13:26:47 <sipa> hioow could you not execute it
181 2014-03-02 13:27:11 <wallet42> no my question is why is it executed
182 2014-03-02 13:27:46 <sipa> i don't understand
183 2014-03-02 13:27:49 <wallet42> or maybe i still dont get this whole scripting
184 2014-03-02 13:27:57 <sipa> what good is a script if it is not executed
185 2014-03-02 13:28:08 <sipa> in a typica
186 2014-03-02 13:28:27 <wallet42> to unlock an output $inputScriptSig || $outputScriptPubKey is executed
187 2014-03-02 13:28:40 <wallet42> and if there is OP_TRUE on the stack left, it is unlocked
188 2014-03-02 13:28:44 <sipa> that was true 4 years ago
189 2014-03-02 13:28:46 <wallet42> right?
190 2014-03-02 13:28:48 <wallet42> okay
191 2014-03-02 13:29:08 <sipa> now, the scriptSig is executed separatrly
192 2014-03-02 13:29:08 <wallet42> sorry then i missed some docs ^^
193 2014-03-02 13:29:39 <sipa> and its resulting stack is used as initial stack for the scriptPubKey of the output being spent
194 2014-03-02 13:29:44 <wallet42> aaah
195 2014-03-02 13:30:11 <sipa> which is very much like executing scriptSig || scriptPubKey
196 2014-03-02 13:30:22 <sipa> but there are some weird edge cases
197 2014-03-02 13:31:09 <wallet42> so something like "OP_EVAL" is excpicit in p2sh case
198 2014-03-02 13:31:23 <sipa> there is no op eval
199 2014-03-02 13:31:27 <wallet42> i know
200 2014-03-02 13:31:33 <sipa> that was an earlier proposal for p2sh
201 2014-03-02 13:31:47 <sipa> but yes
202 2014-03-02 13:31:58 <wallet42> but latest stack item is the checkmultisig DATA push
203 2014-03-02 13:32:31 <sipa> the whole idea is moving the actual scriptPubKey from output to input, and only have a hash of the script in the Iutput
204 2014-03-02 13:32:37 <sipa> eh?
205 2014-03-02 13:32:38 <wallet42> so somehow this needs some +x flag so its not interpreded as data but as executable script
206 2014-03-02 13:32:44 <Burrito> The release notes for the latest release candidate mention a BIP 0061 (a P2P reject message?), but I can't find the text for this BIP in the repository (bitcoin/bips) or on the wiki...
207 2014-03-02 13:32:55 <wallet42> sipa: i get that
208 2014-03-02 13:33:05 <sipa> wallet42: oh, read bip16
209 2014-03-02 13:33:20 <wallet42> thx
210 2014-03-02 13:33:35 <sipa> just the structure of the script put in the output makes the last input element magiv
211 2014-03-02 13:33:57 <sipa> Burrito: there is a draft, that was discussed on the mailking list
212 2014-03-02 13:34:05 <Burrito> ah, okay
213 2014-03-02 13:34:10 <wallet42> yes, also the sighhash created uses the redeemscript as inputScript for generatig the hash for signing
214 2014-03-02 13:34:20 <sipa> yes
215 2014-03-02 13:34:31 <wallet42> which cost me some time to figure out, since else it is the prevOut script has
216 2014-03-02 13:34:32 <wallet42> h
217 2014-03-02 13:34:39 <wallet42> no not hash
218 2014-03-02 13:34:46 <wallet42> the prev out scriptPubKey
219 2014-03-02 13:35:04 <wallet42> which would be OP_HASH160 ⦠OP_EQUAL
220 2014-03-02 13:35:10 <wallet42> but its not
221 2014-03-02 13:36:08 <sipa> eh, it is?
222 2014-03-02 13:37:01 <dexX7> https://github.com/bitcoin/bitcoin/tree/master/contrib/gitian-downloader luke-jr's key has expired
223 2014-03-02 13:41:32 <bitanarchy> have there been any proposals for more advanced blockchain approaches?
224 2014-03-02 13:44:35 <sipa> can you be a bit more specific?
225 2014-03-02 13:44:57 <bitanarchy> like a merge protocol for forks
226 2014-03-02 13:45:10 <wallet42> there is no fork merging
227 2014-03-02 13:45:27 <wallet42> the longest fork simply wins
228 2014-03-02 13:45:38 <sipa> there is... compatible transactions in the reorganized chain move to the new one, if possible
229 2014-03-02 13:45:48 <bitanarchy> but what if you merge in another fork just like with git
230 2014-03-02 13:45:52 <wallet42> all transactions become free floating again if not conflikting
231 2014-03-02 13:46:26 <sipa> bitanarchy: in case there are no double spends, the old transactions just get mined in the new chain, done
232 2014-03-02 13:46:52 <bitanarchy> i am thinking about how to allow better competition between proof of works
233 2014-03-02 13:47:08 <sipa> competition between proof of works?
234 2014-03-02 13:47:16 <wallet42> im not convinced we need another POW
235 2014-03-02 13:47:47 <sipa> bitanarchy: what problem are you tryimg tok solve?
236 2014-03-02 13:48:17 <bitanarchy> proof of work needs to be resistant against miner cartelization
237 2014-03-02 13:48:46 <sipa> ok, go dream
238 2014-03-02 13:48:54 <wallet42> i dont think another pow can fix that one.
239 2014-03-02 13:49:16 <bitanarchy> sipa: are you saying that miner cartelization is bound to happen?
240 2014-03-02 13:49:27 <bitanarchy> :S ;)
241 2014-03-02 13:49:44 <gavinandresen> 0.9.0rc2 up at: https://bitcoin.org/bin/0.9.0/test/
242 2014-03-02 13:50:19 <wallet42> there is a better approach to mitigate centralization: ask you cloudhashing service to integrate proof of transaction inclusioin
243 2014-03-02 13:51:41 <wallet42> if every GH owner can let his own miner process decide on the merkle root he's working on
244 2014-03-02 13:53:07 <wallet42> awesome work everyone on 0.9!!
245 2014-03-02 13:53:14 <wallet42> thank you so much
246 2014-03-02 13:53:55 <bitanarchy> I am not worried about the pools in the first place, but more about mining becoming a centralized business that will be regulate by gov
247 2014-03-02 13:55:13 <wallet42> gavinandresen: osx crashing at startup
248 2014-03-02 13:55:51 <wallet42> mavericks 10.9.2
249 2014-03-02 13:56:14 <gavinandresen> wallet42: thanks, can you file an issue? some framework or library probably didn't make it into the .app bundle....
250 2014-03-02 13:56:16 <bitanarchy> are there any measures of where the mayority of the hashing power is located and how decentralized it is?
251 2014-03-02 13:56:39 <wallet42> gavinandresen: where can i get some debug.log to attach
252 2014-03-02 13:56:59 <bitanarchy> Mining is a specialized business with economy of scale
253 2014-03-02 13:57:03 <gavinandresen> wallet42: if it crashed at startup because of a missing dll, then there will be no debug.log
254 2014-03-02 13:57:25 <gavinandresen> wallet42: does the crash dialog give you a "more info" checkbox?
255 2014-03-02 13:57:53 <fanquake> Runs fine on osx 10.8.5
256 2014-03-02 13:58:27 <wallet42> sure i can use that one
257 2014-03-02 13:58:48 <gavinandresen> I tested on 10.8.5 and 10.6, but both those have XCode installed, which might provide some missing library
258 2014-03-02 13:59:37 <fanquake> wallet42 You might be able to find a crash log in Console
259 2014-03-02 14:02:02 <bitanarchy> I just want to make sure that we will not get a goxing for the btc mining network as a whole...
260 2014-03-02 14:11:09 <fanquake> gavinandresen Is that rc built with qt 5.1?
261 2014-03-02 14:13:01 <dexX7> 5.2
262 2014-03-02 14:13:17 <dexX7> at least here in win7
263 2014-03-02 14:14:05 <fanquake> hmm ok. Looks like the crash on startup issue is caused by 5.1 on mavericks
264 2014-03-02 14:14:32 <fanquake> Few different projects have all been having the exact same issue.
265 2014-03-02 14:20:54 <sipa> looks like infinite recusion inside qt
266 2014-03-02 14:24:07 <fanquake> sipa it's a font rendering issue. mavericks only https://bugreports.qt-project.org/browse/QTBUG-31803
267 2014-03-02 14:25:28 <fanquake> Fix seems to be using qt 5.1.1 or above
268 2014-03-02 14:43:38 <michagogo> cloud|gavinandresen: you have Cory Fields and theuni listed in your email to the ML
269 2014-03-02 14:44:44 <michagogo> cloud|(Also, I'm not at my computer to create a PR, but you can pull in my rc2 sigs from my fork if you want)
270 2014-03-02 15:09:06 <TinkerTom> os x crashes for me too, on 10.9 - I have stack traces - it's something to do with fonts
271 2014-03-02 15:11:12 <wumpus> michagogo|cloud: that list is generated automatically from git; so people that have submitted under different names/emails will be listed twice; feel free to clean the list up though it's in doc/release-notes.md
272 2014-03-02 15:11:17 <TinkerTom> nm, already reported
273 2014-03-02 15:16:19 <michagogo> cloud|wumpus: it was already cleaned up a few times -- early versions also had both Micha and Michagogo, for example
274 2014-03-02 15:17:52 <wumpus> michagogo|cloud: for the same reason I suppose
275 2014-03-02 15:18:03 <wumpus> people should really use consistent credentials for git
276 2014-03-02 16:53:01 <Michail1> of levelDB. In any case, I pulled the /blocks from a window machine, and ran with reindex. It finished yesterday (just under two weeks). As of this morning, I now have to pi's running as nodes.
277 2014-03-02 16:53:01 <Michail1> sipa - 2 weeks ago we briefly spoke about running bitcoind on raspberry pi's. I couldn't pull the directory from a centos machine (and thought it might have been an issue with the cent box not trimming the files when it moved on). It was really determined that my bootstap.dat file was corrupt (stopping each time at a specific block). Also, chainstate didn't work since pi used a variant
278 2014-03-02 16:54:06 <Burrito> two weeks, ouch.
279 2014-03-02 16:54:15 <Burrito> Better than nothing :)
280 2014-03-02 16:54:23 <CoinFinder> Hey, I'd like to discuss a useful feature for a transaction, but im not sure how much work would be involved in adding it
281 2014-03-02 16:55:01 <michagogo> cloud|CoinFinder: What feature would that be?
282 2014-03-02 16:55:13 <Michail1> :) Well, yup. But, for the costs (product and power), it's fun to have them going. Obviously not production use; however, helping to support the network very cheaply.
283 2014-03-02 16:55:45 <Burrito> Michail1, yes, but I suspect other miniature computers with similar cost will do much better
284 2014-03-02 16:55:54 <Burrito> but raspberry pis are abundant
285 2014-03-02 16:56:04 <CoinFinder> An option to tag a transaction with a "SEND_ALL" and the *address*, rather than having to put in the actual transaction input ids.
286 2014-03-02 16:56:25 <sipa> CoinFinder: you mean on the protocol level, or as a client feature?
287 2014-03-02 16:56:28 <michagogo> cloud|CoinFinder: If I'm understanding what you mean correctly, that's a hard fork
288 2014-03-02 16:56:35 <sipa> the former won't happen
289 2014-03-02 16:57:06 <Michail1> Burrito - agreed. Next project (since this is done), will be to do it with an MK809 (RK3188 proc). So, if anyone needs help with pi, I have quite the lot of failures already completed.
290 2014-03-02 16:57:11 <sipa> (makes tracking confirmations very hard, and doesn't protect against replay attacks)
291 2014-03-02 16:57:17 <CoinFinder> the reason i mention is because, it would allow the creation of transactions offline that do not need to know the balance of an address.
292 2014-03-02 16:57:38 <sipa> CoinFinder: you don't need to know the balance of an address, ever
293 2014-03-02 16:57:46 <sipa> CoinFinder: you need to know the value of the coin you're spending
294 2014-03-02 16:57:49 <CoinFinder> sipa: indeed, but you need to know the transactions
295 2014-03-02 16:57:49 <CoinFinder> yea
296 2014-03-02 16:57:59 <michagogo> cloud|CoinFinder: Address balances don't exist.
297 2014-03-02 16:58:13 <CoinFinder> inded, theyre just a side-effect of unspent inputs
298 2014-03-02 16:58:13 <sipa> CoinFinder: anyway, yeah, that's a useful feature
299 2014-03-02 16:58:19 <sipa> but it's very hard to fit in securely
300 2014-03-02 16:58:21 <michagogo> cloud|In the Bitcoin system, there are only txos
301 2014-03-02 16:58:25 <sipa> and it's indeed a hard fork
302 2014-03-02 16:58:30 <CoinFinder> basically it goes back to an idea of creating Transactions to use as interfaces, ie You make an address, create all transactions that you will need to perform in future. SHred private key
303 2014-03-02 16:58:40 <CoinFinder> then the Only way to use the address would be to call one of the transactions
304 2014-03-02 16:58:51 <CoinFinder> But that would make it impossible to add new coin to the address
305 2014-03-02 16:59:09 <CoinFinder> obviously, im using address as simpler way of explaining what i mean
306 2014-03-02 16:59:10 <sipa> furthermore, it means that validation nodes would need to track address balances (unnecessary)
307 2014-03-02 16:59:21 <CoinFinder> sipa: true, they would have to track that themselves.
308 2014-03-02 16:59:57 <CoinFinder> there has to be some way to do this. It would make wallets "hack-proof" in a sense, as the private keys would be lost.
309 2014-03-02 17:00:29 <CoinFinder> Obviously, single tx per address would work too. hmm
310 2014-03-02 17:00:47 <sipa> assuming a hypothetical world without address reuse (which we aim for), there is not much to gain from that
311 2014-03-02 17:01:07 <sipa> every key only ever gets one txout, and when it gets spent, the key is useless
312 2014-03-02 17:01:25 <CoinFinder> Well, for instance - a mining pool's coins would be secure against theft
313 2014-03-02 17:01:52 <michagogo> cloud|Hmm?
314 2014-03-02 17:01:54 <sipa> no they wouldn't
315 2014-03-02 17:02:23 <sipa> if the key is stolen before the coins are transferred
316 2014-03-02 17:02:38 <sipa> also, just not reusing addresses has the same effect with much lower costs to the network
317 2014-03-02 17:02:47 <CoinFinder> sipa: you mean if the key is stolen before it is removed
318 2014-03-02 17:03:21 <sipa> i suppose
319 2014-03-02 17:03:39 <CoinFinder> Say i receive 100 btc into an account. I create 10 transactions to 10 different addresses, of which i have 10 private keys in 10 different servers. Now, i know that the attacker would have to compromise the transactions first to find out where i plan to send, then all 10 of the locations if i knew that my first machine was compromised.
320 2014-03-02 17:04:30 <sipa> i'm not following
321 2014-03-02 17:05:11 <CoinFinder> ok, i have server 1. with my 100 btc in. So i create offline transactions to send this 100 btc to 10 different locations, but i dont relay any of these transactions. After doing this, i store them, and shred the wallet file/private key etc.
322 2014-03-02 17:05:28 <CoinFinder> I now have a way to transfer the coins to 1 of 10 locations (as doublespends wont work), but only those locations.
323 2014-03-02 17:05:57 <sipa> ok
324 2014-03-02 17:06:35 <sipa> you can do this with normal transactions just as well
325 2014-03-02 17:06:44 <CoinFinder> yes this can be done currently
326 2014-03-02 17:06:46 <sipa> except you have to wait to see the crediting transaction first
327 2014-03-02 17:06:53 <CoinFinder> exactly.
328 2014-03-02 17:07:28 <sipa> if you want extra security, you can use multisig instead
329 2014-03-02 17:07:29 <CoinFinder> If i could do a "send_all", i could make the empty address, create the transactions, dispose of the key before the wallet had any value. This could even be "chained" (so the other addresses also are done the same)
330 2014-03-02 17:08:32 <CoinFinder> back
331 2014-03-02 17:08:36 <sipa> how do you prevent replays
332 2014-03-02 17:09:04 <CoinFinder> this is a good question
333 2014-03-02 17:09:20 <CoinFinder> and ur point about the processing required also (so a possible ddos angle)
334 2014-03-02 17:09:35 <sipa> how do you count balances with a given number of confirmations, given the extra indirection?
335 2014-03-02 17:09:44 <sipa> and yeah, address-based indexing is not going to happen
336 2014-03-02 17:10:02 <CoinFinder> :) why not.. im sure facebook can give us their servers and we can distribute one to every miner :P
337 2014-03-02 17:10:10 <sipa> miners?
338 2014-03-02 17:10:12 <sipa> it's not about miners
339 2014-03-02 17:10:17 <sipa> miners are paid for their work
340 2014-03-02 17:10:27 <sipa> it's the rest of the network that has to validate them
341 2014-03-02 17:10:47 <CoinFinder> sorry :)
342 2014-03-02 17:11:11 <sipa> in any case, i understand the use case
343 2014-03-02 17:11:25 <sipa> but it's very hard to safely and cheaply integrate
344 2014-03-02 17:11:37 <CoinFinder> yes, it seems so.
345 2014-03-02 17:13:47 <CoinFinder> maybe then it would be easier to have a "payforward" list for transactions? (though again that would vastly increase the size of the transaction)
346 2014-03-02 17:14:01 <CoinFinder> and also make the addresses easily available to see
347 2014-03-02 17:21:11 <michagogo> cloud|sipa: Okay, I redid #3775
348 2014-03-02 17:21:22 <michagogo> cloud|Did I miss anything?
349 2014-03-02 17:33:00 <wallet42> can i use sendrawtransaction w/o actually sending it. so i just want to verify it would broadcast
350 2014-03-02 17:33:17 <michagogo> cloud|wallet42: no
351 2014-03-02 17:33:36 <michagogo> cloud|Well, you sort of can
352 2014-03-02 17:33:39 <wallet42> maybe with some firewall rules? :D
353 2014-03-02 17:33:52 <michagogo> cloud|If it's not relevant to your wallet, just make sure you have no connections
354 2014-03-02 17:34:07 <michagogo> cloud|And then restart the node immediately after you try, to clear the mempool
355 2014-03-02 17:34:16 <wallet42> thx michagogo
356 2014-03-02 17:34:27 <michagogo> cloud|If it is relevant to your wallet, you'll need to remove it from your wallet as well
357 2014-03-02 17:47:09 <dexX7> is it correct that the dust limit now changed to 564 instead of 5640 satoshi and "is this safe to use"?
358 2014-03-02 17:48:23 <sipa> the dust limit is "3 times the marginal cost for spending an extra output, according to a node's BTC/kb relay policy"
359 2014-03-02 17:48:40 <sipa> you can set that relay policy yourself
360 2014-03-02 17:49:18 <sipa> but in 0.9, the default will be 1000 satoshi per kB, resulting in some 500 satoshi as dust limit indeed
361 2014-03-02 17:50:32 <dexX7> ah thanks
362 2014-03-02 18:18:57 <michagogo> cloud|dexX7: you have the 6 and 4 transposed
363 2014-03-02 18:19:48 <dexX7> yea, right
364 2014-03-02 18:19:49 <dexX7> typo :)
365 2014-03-02 18:22:18 <dexX7> i guess it will take some time until the pools adapt (except eligius)
366 2014-03-02 18:36:39 <Luke-Jr> dexX7: you're assuming pools will accept this change
367 2014-03-02 18:37:59 <dexX7> is that assumption wrong?
368 2014-03-02 18:38:35 <Luke-Jr> dexX7: it's bad to assume anything like that
369 2014-03-02 18:38:43 <michagogo> cloud|Uh, wtf? http://sourceforge.net/p/bitcoin/mailman/message/32045987/
370 2014-03-02 18:39:03 <Luke-Jr> dexX7: whether miners change fee rules *should* be entirely independent from developer actions
371 2014-03-02 18:39:13 <Luke-Jr> michagogo|cloud: yeah, my thought too
372 2014-03-02 18:39:34 <michagogo> cloud|(I checked, 88.198.199.140 is indeed bitcoin.org)
373 2014-03-02 18:40:40 <Luke-Jr> also, why is bitcoin.org now being treated as the website for Bitcoin Core? it was supposed to be independent..
374 2014-03-02 18:41:30 <chmod755> Luke-Jr, is there another website for bitcoin core?
375 2014-03-02 18:41:53 <Luke-Jr> chmod755: there is a GitHub and SourceForge project
376 2014-03-02 18:42:01 <michagogo> cloud|Luke-Jr: Idk
377 2014-03-02 18:42:02 <sipa> we have bitcoincore.org as well
378 2014-03-02 18:42:04 <Luke-Jr> don't see why it needs more
379 2014-03-02 18:42:13 <_syslog> michagogo|cloud: ovh sometimes made stupid actions.
380 2014-03-02 18:42:16 <michagogo> cloud|I was surprised to see 0.8.6 downloads being hosted there
381 2014-03-02 18:42:17 <sipa> i think the reference client project shoukd move there
382 2014-03-02 18:42:22 <Luke-Jr> sipa: that looks more appropriate
383 2014-03-02 18:42:25 <chmod755> sipa, good idea
384 2014-03-02 18:42:40 <Luke-Jr> even has 0.8.1 bins already
385 2014-03-02 18:42:41 <Luke-Jr> XD
386 2014-03-02 18:43:08 <chmod755> people want something that looks like an official website....even when it's not really necessary
387 2014-03-02 18:44:24 <chmod755> i'm using v0.9.0rc1-92-g39fae6c-dirty-beta
388 2014-03-02 18:44:54 <chmod755> but it doesn't have any dirty pictures in it
389 2014-03-02 18:45:15 <michagogo> cloud|chmod755: you could upgrade to rc2
390 2014-03-02 18:45:26 <Luke-Jr> michagogo|cloud: that won't get him any dirty pictures either
391 2014-03-02 18:45:39 <michagogo> cloud|Luke-Jr: Didn't someone stuff those into the blockchain at some point?
392 2014-03-02 18:45:48 <chmod755> lmao
393 2014-03-02 18:45:55 <Luke-Jr> michagogo|cloud: not really; there is nowhere to store data in the blockchain
394 2014-03-02 18:46:08 <michagogo> cloud|Luke-Jr: Sure, but people have done it anyway :-P
395 2014-03-02 18:46:09 <chmod755> why is it named 'dirty-beta'?
396 2014-03-02 18:46:22 <Luke-Jr> michagogo|cloud: it's not data if it isn't data!
397 2014-03-02 18:46:26 <michagogo> cloud|(to be clear, I'm unhappy about it just as you are)
398 2014-03-02 18:46:45 <Luke-Jr> it's just an unclaimed public key
399 2014-03-02 18:46:50 <Luke-Jr> nothing more
400 2014-03-02 18:47:03 <michagogo> cloud|...
401 2014-03-02 18:47:45 <Luke-Jr> bytes are just bytes without a context to interpret them in
402 2014-03-02 18:47:59 <Luke-Jr> the only context on the bitcoin blockchain, is financial transaction
403 2014-03-02 18:48:07 <michagogo> cloud|...riiight.
404 2014-03-02 18:48:13 <Luke-Jr> so, interpreting them as an image is inherently wrong :p
405 2014-03-02 18:48:29 <michagogo> cloud|actions that can be easily extracted as images.
406 2014-03-02 18:48:29 <michagogo> cloud|Except that people have created false finanimages.
407 2014-03-02 18:48:32 <michagogo> cloud|bah
408 2014-03-02 18:48:46 <chmod755> https://xkcd.com/386/
409 2014-03-02 18:48:52 <sipa> chmod755: dirty is because you built from an unclean source directory
410 2014-03-02 18:48:53 <michagogo> cloud|I hate how sometimes the window loses focus and regains it
411 2014-03-02 18:49:06 <sipa> chmod755: beta because every bitcoin release is beta
412 2014-03-02 18:49:20 <michagogo> cloud|except that people have created false financial transactions that can be ~easily extracted as images.
413 2014-03-02 18:49:36 <chmod755> thanks sipa
414 2014-03-02 18:50:06 <Luke-Jr> bccore*
415 2014-03-02 18:50:28 <Luke-Jr> sipa: can we make the next version be 0.11 just to confuse people?
416 2014-03-02 18:50:53 <michagogo> cloud|chmod755: If you feel like upgrading to 0.9.0rc2 without building yourself, you can get the bins from somewhere on bitcoin.org
417 2014-03-02 18:50:58 <michagogo> cloud|or from michagogo.cadoth.net
418 2014-03-02 18:53:01 <chmod755> lol Luke-Jr
419 2014-03-02 18:53:22 <chmod755> Luke-Jr, why don't you make it tonal?
420 2014-03-02 18:55:56 <Luke-Jr> chmod755: shhhhh
421 2014-03-02 18:56:07 <chmod755> :X
422 2014-03-02 18:56:09 <Luke-Jr> sipa: s/0.11/0.î§
423 2014-03-02 18:56:11 <sipa> the next version is obvioudly 0.A
424 2014-03-02 18:56:17 <sipa> *obviously
425 2014-03-02 18:56:56 <waxwing> lol
426 2014-03-02 18:57:42 <Luke-Jr> sipa: okay
427 2014-03-02 18:57:43 <waxwing> 1.0 in 2140 I guess
428 2014-03-02 19:44:20 <speed-> noob question, i am building bitcoind on ubuntu and it's complaining about libdb, if i use --with-incompatible-bdb, will that have impact on anything about wallets?
429 2014-03-02 19:44:41 <michagogo> cloud|speed-: yes
430 2014-03-02 19:45:01 <speed-> michagogo|cloud, what kind of impact?
431 2014-03-02 19:45:21 <michagogo> cloud|Basically, a wallet that has been created or opened with a Bitcoin Core built with BDB 5.1 is incompatible with Bitcoin Core built with BDB 4.8
432 2014-03-02 19:45:35 <michagogo> cloud|4.8 is what is used for release binaries.
433 2014-03-02 19:46:42 <speed-> uhm ok then I will just use binary :)
434 2014-03-02 19:46:57 <speed-> I hope it will work with newer libdb on system
435 2014-03-02 19:47:01 <speed-> will see in few minutes :)
436 2014-03-02 19:47:20 <michagogo> cloud|speed-: the release binaries are statically linked
437 2014-03-02 19:47:27 <michagogo> cloud|Also, you can just get BDB 4.8
438 2014-03-02 19:47:37 <michagogo> cloud|IIRC there are packages for it in the ppa
439 2014-03-02 19:47:47 <michagogo> cloud|;;lucky bitcoin ppa
440 2014-03-02 19:47:48 <gribble> https://launchpad.net/~bitcoin/+archive/bitcoin
441 2014-03-02 19:47:53 <michagogo> cloud|^
442 2014-03-02 19:49:55 <michagogo> cloud|speed-: If you do want to build yourself, `sudo add-apt-repository ppa:bitcoin/bitcoin; sudo apt-get update; sudo apt-get install libdb4.8-dev libdb4.8++-dev
443 2014-03-02 19:49:56 <michagogo> cloud|`