1 2013-06-14 02:47:27 <judah> preferred testNet these days?
2 2013-06-14 02:47:36 <lianj> ?
3 2013-06-14 02:47:36 <sipa> 3
4 2013-06-14 02:47:45 <judah> thx
5 2013-06-14 02:47:59 <sipa> that's the only one implented anymore
6 2013-06-14 02:48:14 <lianj> yea, testnet3 or testnet-in-a-box
7 2013-06-14 02:51:43 <Luke-Jr> I prefer testnet 4000
8 2013-06-14 03:11:33 <Lophie> Hey guys I was thinking if bigger transactions deserve higher fees because of its toll on the block chain. How about if a transaction that renders a large transaction prunable getting a discount on the fees?
9 2013-06-14 03:11:48 <Lophie> Any one have a thought about this?
10 2013-06-14 03:13:02 <gmaxwell> Miners don't have any explicit direct motivation to prefer such a transaction.
11 2013-06-14 03:13:24 <gmaxwell> Large transaction need higher fees because they consume more space which could otherwise be used by other transactions.
12 2013-06-14 03:14:59 <gmaxwell> Or, said differently, picking transactions in order by fees per byte maximized income for a miner. Ignoring dependencies, any other strategy makes less income.
13 2013-06-14 03:15:30 <gmaxwell> (though??? miners aren't maximally greedy??? and the priority algorithim used for free txn does generally reward transactions which consume more inputs)
14 2013-06-14 04:43:08 <Lophie> Sorry no signal on the road, so guyd did anyone discuss what I mentioned? Lowering fees for transactions that would render old very big transactions prunable?
15 2013-06-14 04:43:55 <Lophie> It will create insintive to help reduce the block chain load
16 2013-06-14 04:44:24 <Lophie> Eh guess the developers are hqnging around other places these days
17 2013-06-14 04:44:30 <Lophie> >_>
18 2013-06-14 04:53:28 <lophie2> Judah sorry bad connection on the road
19 2013-06-14 04:53:33 <lophie2> The last point actually suggest it. So a person would prefer to pay more fees to speed up a transaction and this algorithim would prioritiez such a transaction even with standard fees (standard at that time). So basically what I was talking about is already implemented through prioritize without extra fees. Nice
20 2013-06-14 04:54:27 <lophie2> Thanks bro
21 2013-06-14 05:03:29 <sipa> lophie2: sometimes they also sleep
22 2013-06-14 05:04:21 <lophie2> Sipa: lol, not sure if gmaxwell does, he always look weary :(
23 2013-06-14 05:04:36 <sipa> heh
24 2013-06-14 05:07:20 <nsh> sleep is counterrevolutionary
25 2013-06-14 06:26:39 <melvster> does anyone know if colored coins are being used in the wild, or are they strictly theoretical?
26 2013-06-14 06:27:33 <Animazing> I think the latter
27 2013-06-14 06:33:12 <melvster> Animazing: thanks ... do you know who's working with it, the armory folks?
28 2013-06-14 06:35:38 <Animazing> You should look on the forums for the topic about it
29 2013-06-14 06:35:48 <Animazing> there is a PoC implementation last I read
30 2013-06-14 06:35:49 <melvster> thanks!
31 2013-06-14 06:35:58 <melvster> PoC?
32 2013-06-14 06:36:09 <melvster> am just reading ... https://groups.google.com/forum/?fromgroups#!forum/bitcoinx
33 2013-06-14 06:37:55 <The_Fly> http://www.youtube.com/watch?v=d1IYvJs5GGw <-- btcd ... interesting
34 2013-06-14 06:37:59 <Animazing> Proof of Concept :)
35 2013-06-14 06:40:30 <The_Fly> he kind of smirks when he's comparing to the bitcoind source
36 2013-06-14 06:40:44 <melvster> lol thx
37 2013-06-14 06:40:55 <melvster> is killerstorm behind armory?
38 2013-06-14 06:43:10 <Animazing> nope
39 2013-06-14 06:43:27 <melvster> thx, got a bunch of info i need
40 2013-06-14 06:43:38 <The_Fly> this go implementation seems to have some memory footprint, concurrency, code quality/readability and reliability advantages... which is a shame as i do love c++
41 2013-06-14 06:44:42 <The_Fly> i do like that he encourages use of multiple clients
42 2013-06-14 06:45:30 <The_Fly> but yea... sqlite...
43 2013-06-14 06:45:39 <The_Fly> hmmmm
44 2013-06-14 06:50:55 <The_Fly> lol, he likes to comment on the 5000 line main.cpp "spaghetti code"
45 2013-06-14 06:51:18 <sipa> he should have seen the state of the code two years ago :p
46 2013-06-14 06:51:42 <sipa> but sure, it's a mess still
47 2013-06-14 06:52:11 <The_Fly> hehe
48 2013-06-14 06:53:01 <sipa> i mean... the wallet was part of main back then, and did direct calls to the gui...
49 2013-06-14 06:53:41 <The_Fly> yeah it's all gradual refactoring and growth in parallel
50 2013-06-14 06:54:01 <The_Fly> and this client has made it all happen (right?) so...
51 2013-06-14 06:54:52 <sipa> uhu, and there's a general conservatism about changes, as everything needs to be reviewed carefully, and security and some features take priority over cleanups
52 2013-06-14 06:55:23 <sipa> i wish that was different, but can't have everything
53 2013-06-14 06:55:33 <The_Fly> it's certainly not all about a tidy implementation, at least not first time round
54 2013-06-14 06:56:05 <sipa> yeah
55 2013-06-14 06:59:42 <The_Fly> so he can wipe that smirk off his face!
56 2013-06-14 06:59:59 <The_Fly> lol
57 2013-06-14 07:02:42 <The_Fly> ipv6 and tor support is a good step
58 2013-06-14 07:02:53 <sipa> i think there's also this weird bias, that badly modularized code mostly hurts development by people who are not yet contributing
59 2013-06-14 07:03:18 <The_Fly> ive not had any problem navigating the bitcoind source
60 2013-06-14 07:03:19 <sipa> those who know the code have therefor less need for changing it
61 2013-06-14 07:03:49 <sipa> well, it's still not particularly well structured
62 2013-06-14 07:04:10 <The_Fly> no, but it's all machine code at the end of the day
63 2013-06-14 07:04:15 <sipa> lol
64 2013-06-14 07:05:30 <The_Fly> time can also be wasted modularising, that's not "agile"
65 2013-06-14 07:08:24 <The_Fly> i do see a libbitcoin on github
66 2013-06-14 07:08:47 <sipa> that's amir's library
67 2013-06-14 07:09:02 <The_Fly> i haven't dug into the source yet
68 2013-06-14 07:09:20 <sipa> there's also libcoin which is a refactored version of bitcoind 0.5 or so
69 2013-06-14 07:09:32 <The_Fly> interesting
70 2013-06-14 07:10:09 <sipa> libbitcoin is from scratch, but no idea how complete it is
71 2013-06-14 07:10:29 <The_Fly> there aren't many files in src/
72 2013-06-14 07:10:45 <The_Fly> thats not much to go by but hm
73 2013-06-14 07:11:04 <sipa> and in general it is extremely hard to know whether full node implementations do not have subtle fork risks
74 2013-06-14 07:11:40 <The_Fly> (amir seems to be actively working on libbitcoin at the moment)
75 2013-06-14 07:13:23 <The_Fly> yes, the speaker justifies their effort towards the implementation in that it would identify which clients have the bug responsible for the fork
76 2013-06-14 07:14:18 <sipa> ?
77 2013-06-14 07:14:37 <The_Fly> i will quote
78 2013-06-14 07:17:06 <The_Fly> "bits of proof sailed right through the March fork no problem. say you have 10 implementations, miners ask all these implemenations, 9 say yes, 1 says no... so 10% affected, off on their own altchain"
79 2013-06-14 07:19:59 <The_Fly> well, thats just informing the audience about the obvious benefits of there being more choice of clients
80 2013-06-14 07:20:56 <sipa> it will make the inpact of forks smaller indeed
81 2013-06-14 07:21:07 <sipa> but it may make reasoning about them harder
82 2013-06-14 07:21:28 <sipa> as there are n^2 combinations of clients to cobsider
83 2013-06-14 07:24:23 <warren> vendors have ways to automate a "stop and inspect" condition
84 2013-06-14 07:39:23 <volante> im seeing some attacks on chinacoin. they seem to be effective. not sure if it would be of interest for bitcoin devs
85 2013-06-14 07:41:35 <The_Fly> why didn't we just call them "credits" and be done with it
86 2013-06-14 07:44:16 <volante> how come the debug logfile is not timestamped?
87 2013-06-14 07:44:55 <sipa> you need -logtimestamps if you want that
88 2013-06-14 07:45:28 <volante> i see, thanks
89 2013-06-14 07:46:23 <volante> in chinacoin, someone was able to connect to me and send me a really large new blockchain (main blockchain is ~50k blocks, they sent meonethat was ~300k blocks). my client then sat there trying to sync up with all these blocks until i restarted it. then it happened again
90 2013-06-14 07:46:46 <volante> my debug file is full of "disconnected misbehaving node". because im getting blocks with invalid proof of work or invalid txids
91 2013-06-14 07:47:13 <volante> just worried that this kind of attack could be used on bitcoin too
92 2013-06-14 07:48:59 <volante> also in the log it mentioned receiving 30,000 ip addresses of peers and trying to connect to them or something
93 2013-06-14 07:50:46 <volante> they appear to be succesfully taking out solo miners with this
94 2013-06-14 07:54:42 <TD> sipa: how do you mean, "everything depends on main"?
95 2013-06-14 07:54:51 <TD> sipa: it's only one C++ file, right? not the header
96 2013-06-14 07:55:27 <judah> where can I read up about testNet?
97 2013-06-14 07:55:41 <sipa> TD: still, it means you can't use CChainParams without having the code from main in your project
98 2013-06-14 07:57:43 <TD> surely it's up to the pull request that moves CBlock somewhere else to fix that?
99 2013-06-14 07:57:58 <TD> there isn't any way to do it today without undoing the move of the genesis block, which is inherently chain specific
100 2013-06-14 07:58:12 <duSn> ACTION passes judah a google url
101 2013-06-14 07:59:04 <TD> bitcoind code really isn't an API at the moment, definitely not in the scope of this refactoring to fix that, though it gets us a bit closer
102 2013-06-14 07:59:31 <sipa> TD: right, it would be possible to just put all genesis block parameters in cchainstate, and have it be actually just constructed at chain initialization, but i agree this is cleaner
103 2013-06-14 08:00:48 <sipa> and sure, it's far from a complete cleanup, but i try to not undo the efforts to modularize things
104 2013-06-14 08:01:14 <CodeShark> the alternative is a complete reimplementation
105 2013-06-14 08:01:23 <CodeShark> which is almost assuredly a no go
106 2013-06-14 08:02:04 <sipa> anyway, #2767 can fix that dependency again, if it's merged after #2632
107 2013-06-14 08:02:27 <sipa> CodeShark: you ok with that?
108 2013-06-14 08:02:47 <CodeShark> looking
109 2013-06-14 08:05:26 <CodeShark> yikes! #2767 modifies 157 files in a single commit!
110 2013-06-14 08:05:37 <CodeShark> and some of the file modifications are just white space
111 2013-06-14 08:06:10 <TD> urgh
112 2013-06-14 08:06:16 <TD> brilliant. don't really want to rebase on top of that ...
113 2013-06-14 08:06:20 <sipa> uh-oh
114 2013-06-14 08:06:38 <sipa> i didn't mean 2767
115 2013-06-14 08:06:46 <sipa> but 2758
116 2013-06-14 08:07:00 <CodeShark> ah, that one looks more familiar :)
117 2013-06-14 08:09:20 <CodeShark> doesn't seem that rebasing 2758 on top of 2632 will be too difficult - although of course I'd prefer them merged in the opposite order :p
118 2013-06-14 08:10:52 <sipa> TD, CodeShark: i'm very glad we suddenly see a ton of cleanup pullreqs, the problem is of course they tend to conflict easily with eachother...
119 2013-06-14 08:11:14 <CodeShark> a little top-down coordination might be in order
120 2013-06-14 08:13:11 <CodeShark> one of my hopes with these cleanups is precisely being able to allow different developers to clean up separate parts of the app without stepping on each other
121 2013-06-14 08:13:22 <sipa> yeah
122 2013-06-14 08:13:27 <sipa> long way to go :)
123 2013-06-14 08:20:46 <CodeShark> even pull reqs that have nothing to do with cleanup, if they touch files like main.h/main.cpp, it's usually a problem :)
124 2013-06-14 08:21:30 <CodeShark> I'd like to see validation.h/validation.cpp
125 2013-06-14 08:21:37 <sipa> same
126 2013-06-14 08:21:46 <sipa> some things i thought about:
127 2013-06-14 08:22:02 <sipa> CTxMempool should just be the data structure, and not do validation itself
128 2013-06-14 08:22:03 <warren> sounds like I'll need to rebase clean on bitcoin-0.9 to make our tree less of a mess
129 2013-06-14 08:22:16 <CodeShark> sipa: completely agree
130 2013-06-14 08:22:18 <sipa> changes to CTxMempool will be done through the validation code
131 2013-06-14 08:22:39 <sipa> second: the main datastructure in validation.h should be CValidationResult
132 2013-06-14 08:22:47 <sipa> which can become more of a CValidationState then
133 2013-06-14 08:23:15 <sipa> all functions/methods that take a CValidationResult, can become methods of it
134 2013-06-14 08:25:14 <CodeShark> it would be nice to be able to reuse the mempool structure in SPV nodes to enable better double-spend handling
135 2013-06-14 08:25:23 <sipa> yes
136 2013-06-14 08:25:31 <sipa> and maybe even inside wallet
137 2013-06-14 08:26:24 <sipa> but that's more complex
138 2013-06-14 08:26:42 <CodeShark> ideally I'd like to remove the wallet from bitcoind entirely :)
139 2013-06-14 08:26:58 <sipa> yeah
140 2013-06-14 08:27:49 <t7> and tx generation
141 2013-06-14 08:27:56 <CodeShark> I'm looking towards an architecture that clearly separates transaction proposal from transaction signing
142 2013-06-14 08:28:01 <CodeShark> and both of these are removed from validation/relay
143 2013-06-14 08:29:09 <CodeShark> and a set of mechanisms to pass around unsigned or partially signed transactions off the p2p network
144 2013-06-14 08:30:30 <CodeShark> rather than wallet-as-a-collection-of-private-keys, I see wallet-as-a-set-of-authorization-policies
145 2013-06-14 08:31:30 <CodeShark> with the capacity to rotate keys, reissue keys, etc...
146 2013-06-14 08:34:59 <sipa> Luke-Jr: mind updating #2541?
147 2013-06-14 08:57:45 <Bezzeb> Does anyone know if somebody is working on implementing OATH HOTP in a wallet client to provide OTP services for devices like the Yubikey? I've been searching. Would like to see wallets become immune to keyloggers via external USB disposable key generators...
148 2013-06-14 09:14:25 <TD> Bezzeb: see TREZOR/BitSafe
149 2013-06-14 09:32:10 <melvster> Bezzeb: trezor is awesome ... ive pre ordered 4
150 2013-06-14 11:55:51 <nateless> hello can someone help me with senrawtransaction, it fails with tx rejected, no data in logs :( outputs are lower than inputs. signed returned true.
151 2013-06-14 12:01:43 <michagogo> nateless: Can you pastebin the transaction?
152 2013-06-14 12:02:17 <nateless> michagogo, sure http://pastebin.com/u96AbRRk
153 2013-06-14 12:04:37 <nateless> the only thing in logs i see is ERROR: CTxMemPool::accept() : nonstandard transaction type right after ThreadRPCServer method=sendrawtransaction
154 2013-06-14 12:04:59 <michagogo> blockchain.info says the transaction already exists
155 2013-06-14 12:05:21 <michagogo> https://blockchain.info/tx/a501eace9c48c24f5ff746eeac337f631289da4ab5006269bf05e8d2e5e20307
156 2013-06-14 12:05:30 <michagogo> Though my node appears not to have seen it
157 2013-06-14 12:05:33 <nateless> i think someone sent it :)
158 2013-06-14 12:05:41 <nateless> as i posted on pastebin
159 2013-06-14 12:05:45 <michagogo> Ah, I see why it's nonstandard
160 2013-06-14 12:05:49 <michagogo> Too dustu
161 2013-06-14 12:05:51 <michagogo> dusty*
162 2013-06-14 12:05:58 <nateless> what does it mean?
163 2013-06-14 12:06:02 <michagogo> Just 500 satoshis
164 2013-06-14 12:06:06 <michagogo> on one of the outputs
165 2013-06-14 12:06:07 <nateless> and how i can broadcast it anyways?
166 2013-06-14 12:06:45 <michagogo> My node hasn't seen it, it looks like -- probably because it doesn't meet the rules for relay on 0.8.2
167 2013-06-14 12:07:01 <michagogo> The output to 1GSDYGuNULHFQHqxLQEYafnM6MLb4UN9B1 is too small
168 2013-06-14 12:07:22 <michagogo> You need at least 5430 satoshis (I think) per output under the new rules
169 2013-06-14 12:07:33 <nateless> hmm.. it there any flags i can pass to the bitcoind to process such transactions anyways?
170 2013-06-14 12:07:46 <michagogo> I think there might be one
171 2013-06-14 12:08:27 <nateless> or should i icnrease fees for such transactions?
172 2013-06-14 12:08:52 <michagogo> nateless: Fees aren't relevant here, AFAIK
173 2013-06-14 12:09:30 <nateless> okay thanks
174 2013-06-14 12:10:02 <michagogo> I thought there was an option for decreasing the minimum relay size, but I can't find it
175 2013-06-14 12:10:15 <michagogo> nateless: I'd suggest just sending those coins elsewhere
176 2013-06-14 12:10:31 <michagogo> And keeping outputs above 5430 or so satoshis
177 2013-06-14 12:10:49 <nateless> thank you michagogo
178 2013-06-14 12:11:17 <michagogo> np
179 2013-06-14 12:11:46 <nateless> btw how blockchain.info selects nodes it connects to?
180 2013-06-14 12:11:47 <Bezzeb> melvster and TD - sorry was afk. Thanks, and I have watched the video presentation with the guys showing off the Trezor a week or two ago and it does look awesome. But that takes the entire private key out of the wallet entirely doesn't it? Oh, I get it. :) That would supersede my initial fear of keyloggers if you can't sign a transaction without the Trezor... (lol)
181 2013-06-14 12:12:03 <TD> ACTION just did a trezor pre-order
182 2013-06-14 12:12:10 <TD> Bezzeb: exactly
183 2013-06-14 12:12:55 <Diablo-D3> td: treazor?
184 2013-06-14 12:13:03 <Diablo-D3> trezor?
185 2013-06-14 12:13:19 <Bezzeb> Well that's awesome, i'm gonna go do the same. But I thought they were fairly far from getting the mechanisms written for implementing in wallets. I'll go research further - I'm guessing a code base exists already. (grin)
186 2013-06-14 12:13:41 <TD> TREZOR
187 2013-06-14 12:13:52 <Diablo-D3> a hardware wallet? wtf
188 2013-06-14 12:13:53 <Diablo-D3> lame
189 2013-06-14 12:13:58 <TD> Bezzeb: they have command line tools that work with it, i think. it's not integrated with multibit or bitcoin-qt yet
190 2013-06-14 12:14:40 <TD> the plan is that this will come over the summer
191 2013-06-14 12:14:42 <TD> but we'll see ....
192 2013-06-14 12:14:47 <Bezzeb> Just one parting note - I see soft clients as persisting for business use long after customers have gone for hosted wallets or a trezor infrastructure. So if anyone is working on Sage / Quicken / GL accounting package type solutions - the OTP yubikey generators would be an important part of their security solution I should think.
193 2013-06-14 12:15:24 <Bezzeb> The intent from bitcoin-qt is to implement Trezor though? Oh, I see Gavin's mug shot on their website. (laugh)
194 2013-06-14 12:18:55 <TD> well, "intent". not sure. someone would have to contribute it.
195 2013-06-14 12:18:56 <TD> it's a big project
196 2013-06-14 12:19:02 <TD> jim wants to do it for multibit and has committed publicly to doing the work
197 2013-06-14 12:21:25 <TD> woo! apparently i was the first trezor pre-order
198 2013-06-14 12:23:43 <melvster> Bezzeb: yeah the key is on your device
199 2013-06-14 12:25:30 <melvster> TD: no way ... I ordered lots :)
200 2013-06-14 12:26:42 <melvster> TD: maybe you are the first "internet" pre order
201 2013-06-14 12:31:26 <The_Fly> looks nice
202 2013-06-14 12:37:07 <nateless> michagogo, hmm i made another tx, for almost 0.1, and it again failed :/ http://pastebin.com/B3BnVVsW
203 2013-06-14 12:59:30 <melvster> http://www.reddit.com/r/Bitcoin/comments/1gc5xh/trezor_presales_just_started/
204 2013-06-14 13:08:35 <michagogo> nateless: Still around?
205 2013-06-14 13:08:49 <nateless> michagogo yeap
206 2013-06-14 13:08:53 <michagogo> Looks like, according to https://blockchain.info/tx/90cf3e879867d741b9e753261bffc2d2aee038fb48660a7ad4df0ce0117c1806, that transaction has the same problem
207 2013-06-14 13:09:04 <michagogo> The second output is only 5000 satoshis
208 2013-06-14 13:09:24 <michagogo> You need each and every output to be 5430 satoshis or bigger for the transaction to be standard
209 2013-06-14 13:09:35 <michagogo> 0.00005430, in other words
210 2013-06-14 13:10:46 <nateless> michagogo, how this transaction is processed? https://blockchain.info/tx/d4b0188c73b5b2e54be3cb604a7fdbafc5eef7a95d73dae47c0f0f8351ae2abe
211 2013-06-14 13:11:23 <michagogo> nateless: All outputs are 0.00005430 or more
212 2013-06-14 13:11:58 <michagogo> 90cf3e879867d741b9e753261bffc2d2aee038fb48660a7ad4df0ce0117c1806 has a output of 0.00005000
213 2013-06-14 13:12:15 <nateless> michagogo, ok got it, thanks again
214 2013-06-14 13:19:24 <nateless> michagogo, found one tx with only 0.0005 - https://blockchain.info/tx/90cf3e879867d741b9e753261bffc2d2aee038fb48660a7ad4df0ce0117c1806
215 2013-06-14 13:19:56 <michagogo> nateless: That's 0.0005
216 2013-06-14 13:20:00 <michagogo> Not 0.00005
217 2013-06-14 13:20:33 <michagogo> Also, older versions of the software or custom configured ones will allow smaller transactions than 0.00005430
218 2013-06-14 13:20:35 <nateless> michagogo 0.005 is a fee, output is 0.00005
219 2013-06-14 13:21:07 <nateless> do you know any custom software?
220 2013-06-14 13:21:09 <michagogo> And any transaction that a miner mines into a block is valid, regardless of how small it is
221 2013-06-14 13:21:30 <michagogo> So if a miner got it and decided to put it in the block, it's in the chain.
222 2013-06-14 13:34:51 <helo> i'd guess there aren't enough older versions to get a dust output tx relayed to a miner, assuming there is a miner that would mine it
223 2013-06-14 13:35:35 <helo> can't recall the link to the network version distribution pie chart
224 2013-06-14 13:38:31 <michagogo> ;;google bitcoin network version chart
225 2013-06-14 13:38:32 <gribble> Bitcoin network graphs: <http://bitcoin.sipa.be/>; Bitcoin Charts - Blockchain.info: <http://blockchain.info/charts>; Bitcoin Charts / Bitcoin Network: <http://bitcoincharts.com/bitcoin/>
226 2013-06-14 13:39:23 <michagogo> ;;google bitcoin network software version chart
227 2013-06-14 13:39:24 <gribble> Software - Bitcoin: <https://bitcoin.it/wiki/Software>; Bitcoin - Wikipedia, the free encyclopedia: <http://en.wikipedia.org/wiki/Bitcoin>; Bitcoin Trading Software for MtGox - With Neural Networks ...: <https://bitcointalk.org/index.php?topic=154680.80>
228 2013-06-14 13:39:32 <gribble> Bitcoin - Wikipedia, the free encyclopedia: <http://en.wikipedia.org/wiki/Bitcoin>; Software - Bitcoin: <https://bitcoin.it/wiki/Software>; Bitcoin - Bitcoin: <https://bitcoin.it/wiki/Bitcoin>
229 2013-06-14 13:39:32 <michagogo> ;;google bitcoin network software version distribution chart
230 2013-06-14 13:40:28 <michagogo> idk
231 2013-06-14 13:42:54 <nateless> found pull req for dust: https://github.com/bitcoin/bitcoin/pull/2577
232 2013-06-14 14:27:33 <dangersalad> anyone know why I would get a sh: 1: <my cmd here> not found when using walletnotify in my conf file?
233 2013-06-14 15:14:47 <Steve132> Ha anyone written like, an assembler for bitcoin-script?
234 2013-06-14 15:14:57 <Steve132> or a disassembler?
235 2013-06-14 15:15:39 <Luke-Jr> builtin to bitcoind..
236 2013-06-14 15:17:48 <Steve132> Yep, has anyone ever written a seperate one?
237 2013-06-14 15:18:12 <Steve132> Also, how does one access the one built into bitcoind?
238 2013-06-14 15:18:49 <lupine> it's pretty trivial. I think I did a quarter of one once
239 2013-06-14 15:18:59 <lupine> not sure where that ended up
240 2013-06-14 15:20:45 <Steve132> Given that script is kind-of like an assembly language for a stack-based machine, has anyone ever written a frontend for it? Like, a high-level language designed to output bitcoin transactions?
241 2013-06-14 15:22:00 <gmaxwell> I suspect you're greatly overestimating the expressive power of script.
242 2013-06-14 15:22:03 <Luke-Jr> ot
243 2013-06-14 15:22:07 <Luke-Jr> it's not turing-complete
244 2013-06-14 15:23:03 <Luke-Jr> heck, half the opcodes documented on the wiki don't *really* exist
245 2013-06-14 15:25:08 <Steve132> > I suspect you're greatly overestimating the expressive power of script.
246 2013-06-14 15:25:33 <Steve132> No, I'm not, I'm not saying porting a turing-complete language to it...I'm saying someone design somethign thats easier to grok
247 2013-06-14 15:25:55 <Steve132> Not C or C++, something simpler and designed for it from the beginning
248 2013-06-14 15:26:08 <Luke-Jr> what exactly about Scrypt is hard? <.<
249 2013-06-14 15:26:45 <gmaxwell> Steve132: script was designed to be comprehensible from the beginning, in fact.
250 2013-06-14 15:26:59 <Steve132> Its not that hard,
251 2013-06-14 15:27:09 <Steve132> but you can use the same argument "What's so hard to understand about assembly?"
252 2013-06-14 15:27:21 <Steve132> "Assembly is human readable"
253 2013-06-14 15:27:27 <gmaxwell> Script is not x86/mips/arm assembly.
254 2013-06-14 15:27:38 <gmaxwell> It's like forth.
255 2013-06-14 15:27:52 <gmaxwell> And people do write forth directly, rather than compile to it.
256 2013-06-14 15:27:53 <Steve132> Basically, generally speaking, most programming languages don't explicitly require you to visualize the stack
257 2013-06-14 15:27:57 <Luke-Jr> Steve132: abstractions on top of assembly make sense because it *is* turing complete (and nonportable)
258 2013-06-14 15:29:29 <Steve132> gmaxwell: well, my question was whether people have done it not whether or not you personally think its useful
259 2013-06-14 15:29:48 <Steve132> people do write assembly directly as well, but that doesn't mean that higher-level languages are useless
260 2013-06-14 15:31:19 <Luke-Jr> nobody has done it. if you try to, you will surely see why it isn't useful.
261 2013-06-14 15:32:03 <Steve132> Luke-Jr: why don't you think it would be useful?
262 2013-06-14 15:32:26 <Luke-Jr> because there's nothing to simplify
263 2013-06-14 15:32:59 <Steve132> Well, I mean, in terms of readability, composability, and re-usability I think it could use some improvements
264 2013-06-14 15:33:25 <Steve132> But its all opinion really
265 2013-06-14 15:34:23 <gmaxwell> You might start by stating a concrete application.
266 2013-06-14 15:36:59 <Steve132> gmaxwell: mostly, I just think the idea of creating custom transactions is interesting, but...I can show you an example
267 2013-06-14 15:37:41 <Steve132> .well, for example, lets say that I wanted to actually use a fancy script to do something...all the script examples I've seen basically have arguments that are like <variableName>
268 2013-06-14 15:37:45 <Steve132> for example
269 2013-06-14 15:38:15 <Steve132> <sons pubkey> CHECKSIGVERIFY <oracle pubkey> CHECKSIGVERIFY <hash> OP_TRUE
270 2013-06-14 15:38:40 <petertodd> Steve132: First identify what your "fancy script" is even going to do - you're going to soon realize that because the data available to the scripting language is so limited, it basically can't doa nything useful.
271 2013-06-14 15:39:30 <Steve132> petertodd: I'm not arguing that having different syntax would expand the capabilities...thats dumb. I'm arguing that things that ARE within the capabilities aren't developer or user-friendly
272 2013-06-14 15:39:38 <Steve132> if I wanted to actually use that, I'd have to copy-paste it for one transaction, then by hand replace the <> variables with my own data
273 2013-06-14 15:40:30 <petertodd> Steve132: The capabilities are so limited that the existing system is good enough - there just isn't a usecase for doing much other than the standard scripts.
274 2013-06-14 15:41:00 <Steve132> whereas a higher-level language could actually treat those as like, macros, and when you try to execute the script (like, you download it from someone) it queries you for the variables or you could composably call that function programmatically
275 2013-06-14 15:41:07 <petertodd> Steve132: If you want to do something useful, hack on jgarzik's python-bitcoin library.
276 2013-06-14 15:43:51 <Steve132> *shrug*
277 2013-06-14 15:44:01 <Steve132> I guess you answered my primary question. Thanks
278 2013-06-14 15:46:10 <Steve132> I was thinking of something functional-ish that doesn't need the programmer to use op-codes, can be embedded directly into programs, and had composability...
279 2013-06-14 15:55:18 <Steve132> http://codepad.org/AgQyOmRH
280 2013-06-14 15:57:15 <kauzu_> i have a problem with this double spend https://blockchain.info/de/tx/79c6730ac0698886e2021a13f0099f183ce266a5f139922f0c52627477b569ac --- both are 6-7 days old but none of them becomes valid or removed from the network
281 2013-06-14 15:58:05 <gmaxwell> Steve132: pub_key(address)? A non-standard pubkey isn't necessarily mappable to any kind of address.
282 2013-06-14 15:58:21 <gmaxwell> Steve132: "You can also re-use a particular source code
283 2013-06-14 15:58:22 <gmaxwell> for multiple-transactions, unmodified, without having to manually form them from the input constant data"
284 2013-06-14 15:58:29 <gmaxwell> is true regardless of how you format things.
285 2013-06-14 15:59:29 <gmaxwell> Steve132: perhaps I'm still not seeing what you're trying to accomplish. Can you describe it using an example which isn't a trivial pay to pubkeyhash which doesn't need an explicit script expression at all?
286 2013-06-14 15:59:50 <gmaxwell> Perhaps using an example of composibility that you mentioned?
287 2013-06-14 16:00:17 <Steve132> yes, working on new examples
288 2013-06-14 16:00:48 <Steve132> Just basically going from examples on the wiki
289 2013-06-14 16:02:06 <gmaxwell> They may not be ideal, since sort of by definition they are clearly expressable with the existing system.
290 2013-06-14 16:03:13 <kauzu_> i have a problem with this double spend https://blockchain.info/de/tx/79c6730ac0698886e2021a13f0099f183ce266a5f139922f0c52627477b569ac --- both are 6-7 days old but none of them becomes valid or removed from the network
291 2013-06-14 16:07:12 <Steve132> gmaxwell: by definition it would be impossible to write a high-level language that represents more constructs than the low-level constructs
292 2013-06-14 16:07:22 <Steve132> the point is readability and development
293 2013-06-14 16:08:24 <gmaxwell> ... What part of 'clearly expressible' was ambiguous?
294 2013-06-14 16:09:25 <gmaxwell> I'm just telling you if you use the simple script examples then your translation of them into another syntax will likely be _less_ readable, as the examples given were intended to be simple and understanble already.
295 2013-06-14 16:16:13 <Steve132> gmaxwell: http://codepad.org/t5Zbh5fv
296 2013-06-14 16:17:27 <kauzu_> please help me guys
297 2013-06-14 16:17:28 <kauzu_> i have a problem with this double spend https://blockchain.info/de/tx/79c6730ac0698886e2021a13f0099f183ce266a5f139922f0c52627477b569ac --- both are 6-7 days old but none of them becomes valid or removed from the network
298 2013-06-14 16:17:48 <gmaxwell> kauzu_: you're spamming the channel
299 2013-06-14 16:18:19 <Steve132> Actually, caught a mistake: in 'transaction_puzzle" that should be "==" not "="
300 2013-06-14 16:19:21 <kauzu_> gmaxwell: sry but i just need help :/ do you think it could help if i send the coins to another adress with a higher fee?
301 2013-06-14 16:24:45 <Steve132> Someone (user,power-user, or developer) could keep a "library" of standard or custom transactions that they have installed or written
302 2013-06-14 16:25:56 <Steve132> and just invoke them with the required parameters in order to generate one...They could even have variables that would save common addresses or keys in a console...a custom transaction request would just be a console like "send_to_address_with_message(toms_address,
303 2013-06-14 16:35:53 <Steve132> Here's a fun one I just made up: I'm going to put a bounty on the first person to find a public key with the digits of phi...http://codepad.org/vCx20yqC
304 2013-06-14 16:36:29 <gmaxwell> Steve132: these examples you're giving don't actually work.
305 2013-06-14 16:36:36 <Steve132> Why not?
306 2013-06-14 16:36:50 <gmaxwell> You cannot do things like substr.
307 2013-06-14 16:36:54 <Steve132> I'm aware that only standard transactions are enabled in the network
308 2013-06-14 16:36:56 <Steve132> yeah, read the comment
309 2013-06-14 16:37:05 <gmaxwell> It can never be enabled.
310 2013-06-14 16:37:24 <gmaxwell> (an alternative could be provided though)
311 2013-06-14 16:38:24 <Steve132> I wasn't making a philisophical argument about whether or not that particular instruction is safe or not. I don't know and I don't care. I was just showing how, assuming it WAS enabled, the syntax proposed is easier to read, write and understand for a relatively complex example
312 2013-06-14 16:39:16 <gmaxwell> I don't think it's easier to read, but I thought it would be less of a waste of time if you actually provided concrete and viable examples.
313 2013-06-14 16:39:35 <gmaxwell> (likewise your compose example in the other pastebin wouldn't work either)
314 2013-06-14 16:39:53 <Steve132> I gave you a great number of other examples that do not use that instruction
315 2013-06-14 16:39:59 <Steve132> Why not?
316 2013-06-14 16:40:09 <gmaxwell> also, none of these allow your 'library' usage because none of this tells anyone how to go about constructing the redeeming transaction.
317 2013-06-14 16:42:15 <Steve132> gmaxwell: For the library code, simply looking at the transaction code could tell you, or the 'source' could tell you, or a verbal instruction could tell you, or you could write some syntax for the 'redeem' part
318 2013-06-14 16:42:29 <Steve132> But, what's wrong with the composability example?
319 2013-06-14 16:45:10 <Luke-Jr> I have to admit I'm slightly less certain now than I was when we started out
320 2013-06-14 16:45:18 <Luke-Jr> although your taste in code is ugly :P
321 2013-06-14 16:46:06 <Steve132> Luke-Jr: well, its a rough draft, I thought of it like an hour ago
322 2013-06-14 16:47:02 <Luke-Jr> IMO you'd end up with effectively a programmer-friendly-only altcoin using the BC blockchain
323 2013-06-14 16:47:24 <Luke-Jr> which maybe you might be interested in for fun, but not too useful except for fun IMO
324 2013-06-14 16:48:10 <Steve132> Well, the end goal isn't for only programmers to use it...the end goal is for stuff like contracts (or other non-standard transactions that people might come up with) to be easier to develop
325 2013-06-14 16:48:46 <pigeons> coiledcoin
326 2013-06-14 16:49:07 <Steve132> In general, cool platforms get cooler when there are good development tools
327 2013-06-14 16:50:35 <Steve132> I agree with gmaxwell that a way to communicate the expected sig inputs to redeem these transactions is important
328 2013-06-14 16:50:40 <Steve132> I don't really know how to do that
329 2013-06-14 16:51:25 <Steve132> but its not a totally insurmountable problem, and its kind of irrelevant anyway: script suffers from the same problem
330 2013-06-14 16:51:33 <kauzu_> could someone check if he has de57423304e2d9d349d3047d00ddf09c609d3a606b5b6f38f0bc16c1fdd59dce in his mempool?
331 2013-06-14 16:56:41 <petertodd> kauzu_: I don't see it
332 2013-06-14 16:58:34 <kauzu_> petertodd: could you add it manualy? one of the inputs has been spend for third time with this tx but the first two did not bekome valid and did not disapear from the network http://pastebin.com/AGmcHPu3 this one is with a higher fee i hope it becomes valid soon
333 2013-06-14 16:59:21 <kauzu_> i think this tx is not relayed often because some nodes have a double of it in mempool
334 2013-06-14 17:00:43 <petertodd> kauzu_: done
335 2013-06-14 17:01:16 <kauzu_> petertodd: thx... i hope this one becomes valid... the coins are dead now for a week
336 2013-06-14 17:01:25 <petertodd> Incedentally, replace-by-fee.bitcoin.petertodd.org resolves to some bitcoin nodes with my replace-by-fee patch, which will accept any tx that double-spends another provided the second pays higher fees
337 2013-06-14 17:01:48 <petertodd> kauzu_: I have no idea how much mining power is following that rule, but it's worth a try
338 2013-06-14 17:02:58 <kauzu_> petertodd: your link is down
339 2013-06-14 17:03:21 <kauzu_> or is this only a node and no webservice
340 2013-06-14 17:03:42 <kauzu_> but its a cool service
341 2013-06-14 17:03:48 <petertodd> yeah, it's a node
342 2013-06-14 17:04:14 <petertodd> it's not really a service, more a change to the way nodes relay transactions that I'm advocating
343 2013-06-14 17:06:08 <kauzu_> petertodd: that should be the behaviour of the "official" client... is there a kind of counter in your patch to avoid ddos? someone could make tons of double spends and add only one satoshi every time
344 2013-06-14 17:06:51 <petertodd> kauzu_: the second tx has to have higher fees than the first
345 2013-06-14 17:08:20 <kauzu_> petertodd: yes but what if you make a third .. 4... 5th and so on and add one satoshi with every tx... than there is a tx with a higher fee every second
346 2013-06-14 17:08:32 <petertodd> kauzu_: specifically, the rule needs to be that the second tx has higher fees than *all* tx's being replaced, but to keep the initial patch really simple I just implemented a version where the tx isn't replaced if it's been spent
347 2013-06-14 17:09:46 <petertodd> kauzu_: the fees have to be at least delta_size*MIN_FEE_PER_KB higher
348 2013-06-14 17:35:59 <jimmy2k> hello! I just saw this parser here: https://github.com/znort987/blockparser ! it claims to have an option "closure" to compute the list of addresses that provably belong to the same person. How is that possible, if every newer btc client switches the public key for an anount for every amount that is not completely spent?
349 2013-06-14 17:51:16 <vrs> RoboTedd_: fix your connection
350 2013-06-14 17:52:19 <vrs> jimmy2k: https://github.com/znort987/blockparser/blob/master/cb/closure.cpp#L125 this looks like the relevant part
351 2013-06-14 17:56:35 <bloke> I'm having trouble building bitcoind on Ubuntu 12.04. I can build it against Berkley DB version 5.1 (which will apparently "break binary wallet compatibility, and is not recommended") but can't get Berkley DB version 4.8 to install. Anyone have any advice?
352 2013-06-14 17:59:06 <bloke> My OS is ubuntu 12.04 (64 bit).
353 2013-06-14 18:04:16 <TheLordOfTime> bloke: there's a PPA for the bitcoin software
354 2013-06-14 18:04:21 <TheLordOfTime> i'd suggest using that
355 2013-06-14 18:04:28 <TheLordOfTime> i think BlueMatt keeps it up to date
356 2013-06-14 18:04:30 <TheLordOfTime> ACTION looks
357 2013-06-14 18:04:49 <bloke> ok thanks Timelord
358 2013-06-14 18:05:17 <TheLordOfTime> bloke: sudo add-apt-repository ppa:bitcoin/bitcoin
359 2013-06-14 18:05:20 <TheLordOfTime> then sudo apt-get update
360 2013-06-14 18:05:25 <TheLordOfTime> and then sudo apt-get install bitcoind
361 2013-06-14 18:05:33 <TheLordOfTime> should autoinstall the dependencies too
362 2013-06-14 18:05:36 <bloke> no way!
363 2013-06-14 18:05:40 <TheLordOfTime> BlueMatt: oh, when yo uwake up, ping
364 2013-06-14 18:05:48 <bloke> I have an experimental install, i will try it now
365 2013-06-14 18:06:25 <TheLordOfTime> bloke: the ppa installs the stable release, if you want to experiment with sometehing else, like a newer trunk version, that's a different method and you will need to solve the FTBFS (fail to build from source) issues.
366 2013-06-14 18:06:35 <bloke> nah, the stable release is exactly what I want
367 2013-06-14 18:07:02 <bloke> I have installed 64-bit OS. Have I made the right decision, or should I go back to 32-bit ?
368 2013-06-14 18:07:13 <bloke> I think that may be the source of my current build/dependency issues
369 2013-06-14 18:07:24 <TheLordOfTime> bloke: i've built bitcoind from source on a 64bit system
370 2013-06-14 18:07:33 <TheLordOfTime> bloke: more likely you don't have the build dependencies
371 2013-06-14 18:07:41 <TheLordOfTime> but idk the specifics, i say use the PPA XD
372 2013-06-14 18:07:47 <TheLordOfTime> note you might need to back up your wallet first
373 2013-06-14 18:07:50 <TheLordOfTime> on your existing client
374 2013-06-14 18:07:57 <TheLordOfTime> otherwise, well, possible E: Problems
375 2013-06-14 18:08:09 <bloke> thats cool, no wallet or anything on the machine in question
376 2013-06-14 18:09:38 <TheLordOfTime> bloke: then installing the ppa's version as i said should work fine with 12.04
377 2013-06-14 18:09:44 <TheLordOfTime> because that's what i'm on too :p
378 2013-06-14 18:09:56 <bloke> youre using 12.04 .. 64bit?
379 2013-06-14 18:23:10 <thelamest> window 22
380 2013-06-14 18:23:16 <BitAddict_> guys
381 2013-06-14 18:23:21 <BitAddict_> watch out for www.btc-outlet.com
382 2013-06-14 18:23:23 <thelamest> oops :P
383 2013-06-14 18:29:10 <BitAddict_> any developers want to help?
384 2013-06-14 18:32:14 <bloke> Thanks TheLordOfTime. The PPA worked.
385 2013-06-14 18:32:53 <BitAddict_> any developers want to make money?
386 2013-06-14 18:33:42 <TheLordOfTime> bloke: you're welcome, enjoy! don't forget to let the blockchain sync which takes a WHILE
387 2013-06-14 18:34:44 <warren> Does testnet-in-a-box also disable the PoW check?
388 2013-06-14 18:35:05 <bloke> yeh all good. testnet, shouldnt take long
389 2013-06-14 18:35:11 <Luke-Jr> warren: no
390 2013-06-14 19:28:13 <tlrobinson> can anyone tell me if this microtransaction idea a) would work, and b) has already been proposed (and if so where): https://gist.github.com/tlrobinson/5785394
391 2013-06-14 19:39:35 <Luke-Jr> tlrobinson: a) yes, b) probably, but I'm not aware of any implementation
392 2013-06-14 19:40:28 <PRab> tlrobinson: What is to stop Alice from becoming evil and spending the bitcoins (on the blockchain) that she signed for Bob?
393 2013-06-14 19:40:30 <Luke-Jr> tlrobinson: I'd suggest instead of Bob claiming funds when Alice runs out, Alice creates a new 2-of-2 transaction for additional funds, and they include BOTH of them as inputs to the continually-revised transaxtion
394 2013-06-14 19:40:42 <Luke-Jr> PRab: she would first send them to a 2-of-2 multisig
395 2013-06-14 19:40:58 <tlrobinson> PRab: she's not allowed to until the expiration
396 2013-06-14 19:41:03 <Luke-Jr> PRab: and Alice and Bob would both sign a "return funds to Alice" with a locktime in the future (expiration)
397 2013-06-14 19:43:24 <PRab> Ah, got it. First transaction (locktime) sets up essentially a credit account then the actual amount can fluctuate before the locktime runs out.
398 2013-06-14 19:48:30 <tlrobinson> PRab: yeah, but Alice's balance can only decrease because Bob can redeem the largest amount she's signed for, which guarantees irreversibility (as long as Bob is able to redeem it in time, so you'd want a pretty large buffer in case of downtime etc)
399 2013-06-14 19:48:55 <tlrobinson> you could of course have bob create a transaction as well, so their "balances" can go up and down
400 2013-06-14 19:49:09 <tlrobinson> but i imagine those would be separate transactions
401 2013-06-14 19:49:36 <tlrobinson> (or maybe not, I don't know enough about Script)
402 2013-06-14 20:07:01 <tlrobinson> oh, yeah, my idea sounds almost exactly like https://en.bitcoin.it/wiki/Contracts#Example_7:_Rapidly-adjusted_.28micro.29payments_to_a_pre-determined_party
403 2013-06-14 21:53:58 <TheLordOfTime> i have multiple addresses here in my wallet, how can i dump all the privkeys at once (in bitcoin-qt)
404 2013-06-14 21:56:40 <toffoo> i've gotten LevelDB corruption 6 times now with bitcoin-qt 0.8.2 Mac version ...
405 2013-06-14 21:56:59 <toffoo> pondering downgrading to 0.7.2 for the third time now
406 2013-06-14 21:57:33 <TheLordOfTime> by rumor only, i wouldn't downgrade to 0.7.2 because there'll be issues with processing the chain
407 2013-06-14 21:57:46 <toffoo> there's a workaround
408 2013-06-14 21:58:00 <toffoo> it still works fine if you do the workaround
409 2013-06-14 21:59:34 <gmaxwell> toffoo: Which issue is yours?
410 2013-06-14 22:00:03 <gmaxwell> petertodd: didn't someone (you?) timestamp all the pgp keys on one of the keyservers?
411 2013-06-14 22:00:27 <toffoo> gmaxwell "LevelDB read failure: Corruption: block checksum mismatch"
412 2013-06-14 22:00:54 <gmaxwell> petertodd: there was some discussion on hacker news about the potential trustworthyness of pgp keys claiming to belong to snowden. https://news.ycombinator.com/item?id=5883175
413 2013-06-14 22:01:06 <gmaxwell> toffoo: You haven't reported this in the issue tracker?
414 2013-06-14 22:01:26 <TheLordOfTime> is there a way to extract all the privkeys in a wallet.dat file assuming it's decrupted?
415 2013-06-14 22:01:30 <TheLordOfTime> decrypted*
416 2013-06-14 22:01:38 <gmaxwell> toffoo: in any case, that checksum mismatch means that the actual data written to disk is corrupted. It may be the case that you were also getting corruption with the old software but since there was no error checking it was undetected.
417 2013-06-14 22:01:47 <gmaxwell> TheLordOfTime: at once? no.
418 2013-06-14 22:02:01 <sipa> TheLordOfTime: there's a pullrequest to do so
419 2013-06-14 22:02:03 <TheLordOfTime> gmaxwell: bleh, the main issue is all these damn satoshi dice payouts that showed at random addresses >.<
420 2013-06-14 22:02:13 <TheLordOfTime> sipa: yeah, any ETA on that becoming available?
421 2013-06-14 22:02:20 <sipa> 0.9 maybe
422 2013-06-14 22:02:25 <sipa> ETA: when it's ready
423 2013-06-14 22:02:37 <TheLordOfTime> i've got my main keys but meh
424 2013-06-14 22:02:46 <sipa> if you can compile from source, it's easy
425 2013-06-14 22:02:52 <gmaxwell> TheLordOfTime: why not make a transaction consolidating your whole wallet into a new address?
426 2013-06-14 22:02:56 <TheLordOfTime> kinda hard on a windows system
427 2013-06-14 22:02:58 <TheLordOfTime> gmaxwell: E: Broken NIC
428 2013-06-14 22:03:04 <TheLordOfTime> no network connection
429 2013-06-14 22:03:05 <toffoo> gmaxwell I don't have a github accnt. I saw the issues were reported with 0.8.1 and supposedly fixed/closed in 0.8.2, and now it looks like 0.8.2 is listed with no known issues.
430 2013-06-14 22:03:34 <TheLordOfTime> sipa: is that pull request included in git trunk or something
431 2013-06-14 22:03:37 <gmaxwell> toffoo: creating a github account just takes typing in a username, it doesn't even email confirm.
432 2013-06-14 22:03:39 <TheLordOfTime> or PendingMerge
433 2013-06-14 22:03:40 <TheLordOfTime> ?
434 2013-06-14 22:03:54 <sipa> TheLordOfTime: no it's a pull request; if it was pulled, it wouldn't be a request anymore :)
435 2013-06-14 22:04:02 <TheLordOfTime> heh
436 2013-06-14 22:04:05 <TheLordOfTime> sipa: you never know ;)
437 2013-06-14 22:04:11 <TheLordOfTime> still.
438 2013-06-14 22:04:30 <gmaxwell> toffoo: in any case, I'm not aware of any current corruption issues. Unfortunately, people (like you!!) don't report them reliably, so I can't tell you with any confidence that none exist.
439 2013-06-14 22:04:37 <TheLordOfTime> i've got at least 0.005 btc in the damn dice transactions, so... *shrugs*
440 2013-06-14 22:04:43 <gmaxwell> I do know that its reliable on linux.
441 2013-06-14 22:05:07 <TheLordOfTime> sipa: another question. is it possible to store the blockchain as fully downloaded on one bitcoin-qt client, say on linux, and import it into a windows bitcoin-qt client of the same version?
442 2013-06-14 22:05:12 <TheLordOfTime> if so, what needs copying?
443 2013-06-14 22:05:16 <toffoo> gmaxwell I've never reported a bitcoin-qt problem because I never had one until I updated to 0.8
444 2013-06-14 22:05:20 <TheLordOfTime> (so that I don't have to download 10GB again)
445 2013-06-14 22:05:21 <gmaxwell> TheLordOfTime: technically you could make a transaction while offline, and then open the debug console, getrawtransaction on it, save the output to a file, and then carry that on a usb stick to the network.
446 2013-06-14 22:05:51 <TheLordOfTime> gmaxwell: i looked into that the total transaction fee for that would be more than the total sum of the funds availabe
447 2013-06-14 22:05:57 <sipa> TheLordOfTime: sure, copy the block files
448 2013-06-14 22:05:59 <TheLordOfTime> at least, according to -qt
449 2013-06-14 22:06:02 <gmaxwell> TheLordOfTime: but thats only an option if that system is aware of the txn.
450 2013-06-14 22:06:13 <sipa> TheLordOfTime: the blocks/ subdir
451 2013-06-14 22:06:14 <TheLordOfTime> sipa: location on a linux drive? ~/.bitcoin/[whatelse]
452 2013-06-14 22:06:21 <TheLordOfTime> ?
453 2013-06-14 22:06:21 <TheLordOfTime> sipa: ah, so ~/.bitcoin/blocks/*
454 2013-06-14 22:06:31 <sipa> even just ~/.bitcoin/blocks/blk*.dat
455 2013-06-14 22:06:35 <gmaxwell> TheLordOfTime: oh, well, if you have dust transactions it's not unusal for them to cost more to redeem than they're worth.... but there isn't much you can do about that. :( They'll still cost more to redeem than they're worth if you split them up.
456 2013-06-14 22:06:49 <TheLordOfTime> gmaxwell: true, because dust tx fees
457 2013-06-14 22:06:57 <TheLordOfTime> some of these are 0.02 coin each though *shrugs*
458 2013-06-14 22:06:58 <TheLordOfTime> ah well
459 2013-06-14 22:07:09 <TheLordOfTime> i'll take my main ones and deal with the remnamt 0.005 later
460 2013-06-14 22:07:21 <gmaxwell> TheLordOfTime: has nothing to do with "dust tx fees" ??? once your outputs are >0.01 thats a non-issue. It's just the space it takes to redeem them.
461 2013-06-14 22:07:31 <TheLordOfTime> gmaxwell: as i said, i'll deal with the remnants later
462 2013-06-14 22:07:46 <gmaxwell> seperating them makes it harder.
463 2013-06-14 22:07:48 <TheLordOfTime> my main concern is the 0.13 that is in the 5 main addresses :P
464 2013-06-14 22:07:59 <TheLordOfTime> and i pulled those privkeys already
465 2013-06-14 22:08:05 <gmaxwell> e.g. you'll _never_ be able to spend the "remnamts" alone.
466 2013-06-14 22:08:16 <gmaxwell> (well never is a long time, but certantly not anytime soon)
467 2013-06-14 22:08:38 <gmaxwell> you can like jointly spend some of the remnamt with your existing non-dust coins.
468 2013-06-14 22:13:08 <TheLordOfTime> gmaxwell: if i copy the chain from a 0.8.2 client to a 0.8.1 client will it still recognize the chain?
469 2013-06-14 22:13:57 <sipa> yes
470 2013-06-14 22:14:12 <toffoo> ok gmaxwell github accnt created, any tips for a first timer to make a good first issue report?
471 2013-06-14 22:14:18 <TheLordOfTime> awesome so i can see what bullcrap has happened to these wallets since the NIC died xD
472 2013-06-14 22:14:22 <TheLordOfTime> s/wallets/addresses/
473 2013-06-14 22:14:55 <TheLordOfTime> i know for a fact the 5 main addresses have just had their contents dumped into my other wallet, but... :P
474 2013-06-14 22:15:21 <gmaxwell> toffoo: give as many details about your system as you can, anything you know about the sequence of events before the problem.
475 2013-06-14 22:15:44 <toffoo> ok thanks here goes ...
476 2013-06-14 22:26:49 <warren> gmaxwell: fyi, TheUni added a workaround for the broken boost in Fedora 18
477 2013-06-14 22:32:49 <gmaxwell> warren: what is the workaround?
478 2013-06-14 22:33:49 <warren> gmaxwell: https://github.com/bitcoin/bitcoin/pull/2766