1 2014-03-20 00:00:04 <padawan123> did u got paid for sucking their dick?
2 2014-03-20 00:01:29 <padawan123> let see how much time he ll need to react
3 2014-03-20 00:06:00 <JimJones> can any one by pvt to upgrade to bitcoind 0.9 on ubuntu?
4 2014-03-20 00:06:11 <JimJones> i kinda want it to run on my 100mb server
5 2014-03-20 00:06:42 <olalonde> is there any way to know if bitcoind has finished downloading the blockchain?
6 2014-03-20 00:07:08 <Imbue> olalonde: getinfo?
7 2014-03-20 00:07:20 <Imbue> (there could be a better way)
8 2014-03-20 00:12:01 <venzen> olalonde: i usually tail .bitcoin/debug.log and check the date of the last block to arrive (could be a better way :)
9 2014-03-20 00:13:52 <olalonde> ok
10 2014-03-20 00:32:12 <Ghaleon> how do you keep wallet notify from firing when a change address gets credited?
11 2014-03-20 00:32:21 <Ghaleon> we have a major problem here building our wallet
12 2014-03-20 00:32:25 <deego> Hey, if I want to 'bootstrap' a new bitcoin wallet, what files should I copy from an existing wallet? blk* ?
13 2014-03-20 00:32:43 <deego> Also, the contents of blocks/ subdir? I have never seen that subdir. before.
14 2014-03-20 00:32:43 <Ghaleon> deago... it ain't so easy
15 2014-03-20 00:32:55 <Ghaleon> checkout coinpunk
16 2014-03-20 00:33:36 <sipa> deego: do you trust the location you're copying it from>?
17 2014-03-20 00:33:38 <Ghaleon> how does block chain.info choose the change address?? does it just pick a random address?
18 2014-03-20 00:34:07 <deego> sipa: yes I do, just trying to create a fresh, new 0-coin wallet, and trying to save the 3-day download.
19 2014-03-20 00:34:20 <sipa> deego: then copy blocks/ and chainstate/ and nothing else
20 2014-03-20 00:34:32 <deego> sipa: ah, ok, now even blk*.dat?
21 2014-03-20 00:34:43 <sipa> deego: the blk*.dat are in blocks, so yes
22 2014-03-20 00:34:51 <sipa> Ghaleon: the correct way to do it is to generate a new address for change
23 2014-03-20 00:34:57 <Luke-Jr> Ghaleon: change should always be ⦠what sipa said
24 2014-03-20 00:35:09 <sipa> and please don't just immitate b.i
25 2014-03-20 00:35:19 <deego> sipa: ahh, I have older blk*.dat outside of blocks/. Guess those must be from older clients. :)
26 2014-03-20 00:35:28 <sipa> deego: you can delete those
27 2014-03-20 00:35:40 <sipa> deego: since 0.8, only the ones inside blocks/ are used
28 2014-03-20 00:35:45 <Ghaleon> when you use wallet notify on bitcoind how does it select the chmage address??/ does it make a new one?
29 2014-03-20 00:35:58 <sipa> Ghaleon: that makes no sense
30 2014-03-20 00:36:07 <sipa> Ghaleon: change is created at send time
31 2014-03-20 00:36:08 <deego> sipa: thanks.
32 2014-03-20 00:36:14 <sipa> Ghaleon: it has nothing to do with wallet notify
33 2014-03-20 00:36:25 <sipa> which is to let your application know the wallet situation changed
34 2014-03-20 00:36:41 <Ghaleon> so bitcoind ALWAYS makes a new address when one of it;s addresses gets some btc?
35 2014-03-20 00:36:49 <sipa> ...
36 2014-03-20 00:37:00 <sipa> it's done at send time
37 2014-03-20 00:37:03 <sipa> not at receive time
38 2014-03-20 00:37:17 <sipa> please learn how bitcoin works before building a wallet solution
39 2014-03-20 00:37:19 <Ghaleon> the sender makes a New address for the change?
40 2014-03-20 00:37:34 <Ghaleon> that is what I here for, learnin
41 2014-03-20 00:37:44 <Ghaleon> i am just starting and this is my project
42 2014-03-20 00:37:44 <sipa> when sending through bitcoind using the send* RPCs, yes
43 2014-03-20 00:38:14 <Ghaleon> ok
44 2014-03-20 00:38:23 <Ghaleon> i am working on a bitcoind wallet project now
45 2014-03-20 00:38:42 <sipa> which will store other people's money?
46 2014-03-20 00:39:11 <Ghaleon> was using block chain.info and giving folks a receive address , but when people were sending to an address on it, another user would get credited their funds as it would pick a random address on our account to send the change too
47 2014-03-20 00:39:33 <Ghaleon> it would then fire a callback and our system would credit the random user with getting the change, which they should NOT be getting
48 2014-03-20 00:39:35 <Ghaleon> make sense
49 2014-03-20 00:39:45 <Ghaleon> this is for our internal use
50 2014-03-20 00:40:11 <sipa> always use a new receive address for every transaction
51 2014-03-20 00:40:31 <Ghaleon> this is for people sending us funds
52 2014-03-20 00:40:56 <sipa> well, there you should at least encourage using a new address for every transaction
53 2014-03-20 00:40:58 <deego> Is there a tutorial/howto on how to create your own paper wallet, without using any third party website?
54 2014-03-20 00:41:01 <sipa> you can't enforce that, of course
55 2014-03-20 00:41:17 <sipa> deego: use software that supports it, like armory
56 2014-03-20 00:41:42 <Luke-Jr> Armory ftw, for paper wallets
57 2014-03-20 00:42:38 <deego> Luke-Jr, sipa: thanks.
58 2014-03-20 00:46:13 <Ghaleon_> back
59 2014-03-20 00:46:49 <Ghaleon_> blockchain.info is sending callbacks when a random address in our wallet gets some change..... how does it pick a random change address ?
60 2014-03-20 00:47:11 <Ghaleon_> it is messing everything up because random users are getting credited the change from other peoples recieves
61 2014-03-20 00:47:17 <Ghaleon_> has anyone experienced this?
62 2014-03-20 00:47:37 <Luke-Jr> Ghaleon_: have you considered BitPay, or some other more reputable processor?
63 2014-03-20 00:48:01 <Ghaleon_> I am hoping bitcoind itself will NOT do this and it is just a bug with blockchain.info not being designed for multiple accounts in a single wallet
64 2014-03-20 00:48:23 <Ghaleon_> i got up bitcoind now and will be using wallet notify
65 2014-03-20 00:50:09 <sipa> Ghaleon_: to distinguish change from other outputs, you need to know the wallet
66 2014-03-20 00:50:20 <sipa> Ghaleon_: so you can recognize it as a send to self
67 2014-03-20 00:50:21 <Ghaleon_> know the wallet?
68 2014-03-20 00:50:29 <sipa> know all address in it
69 2014-03-20 00:50:37 <sipa> including change addresses
70 2014-03-20 00:50:57 <Ghaleon_> yes but how do we distinguish between a send from outside... and a send to itself?
71 2014-03-20 00:51:10 <Ghaleon_> blockchain.info does NOT include the FROM address
72 2014-03-20 00:51:52 <arubi> sipa, actually that's an interesting question (for me), transactions to change addresses do not require fees right?
73 2014-03-20 00:52:11 <sipa> arubi: of course they do
74 2014-03-20 00:52:18 <sipa> arubi: the network cannot distinguish them
75 2014-03-20 00:52:34 <Imbue> change addresses are a client-level construct
76 2014-03-20 00:52:45 <arubi> ah, I learned something new today
77 2014-03-20 00:52:45 <Ghaleon_> so how do we figure out it is a change address and disregard the callback ???
78 2014-03-20 00:53:35 <sipa> Ghaleon_: by knowing
79 2014-03-20 00:53:53 <sipa> Ghaleon_: the bitcoind wallet receiving the transaction will know it is change
80 2014-03-20 00:54:06 <Ghaleon_> ok
81 2014-03-20 00:54:07 <Ghaleon_> so
82 2014-03-20 00:54:21 <sipa> so listtransactions or listinceblock or whathever you are using to sync bitcoind's state with your applications, will just ignore it
83 2014-03-20 00:54:41 <Ghaleon_> basically it is impossible to runs multilevel wallet with blockchain.info ...api because it is impossible to know the difference between and external receive and a change
84 2014-03-20 00:55:04 <sipa> what are you using b.i for?
85 2014-03-20 00:55:18 <Ghaleon_> ou must setup your own bitcoind and use wallet notify.... when you lookup the txid what do you look for to figure out that it is change?
86 2014-03-20 00:55:48 <Ghaleon_> was using blockchcian.info to host wallets for our interal service using one wallet account. each of us gets an address
87 2014-03-20 00:56:07 <arubi> Ghaleon_, the wallet itself signs the tx that make it into the change address, so it knows before it's even broadcasted
88 2014-03-20 00:56:25 <arubi> sipa, i think he's making something like a "parental controlled" wallet
89 2014-03-20 00:56:32 <arubi> but I may be wrong
90 2014-03-20 00:56:43 <sipa> Ghaleon_: it's generally a bad idea to mix address-level abstraction with wallet-level abstraction
91 2014-03-20 00:57:05 <sipa> bitcoind gives you a wallet-level abstraction
92 2014-03-20 00:57:08 <Ghaleon_> something like that arubi... but it seems a single blockchain.info account cannot be used for each a function because it fires callbacks on internal sends
93 2014-03-20 00:57:13 <Ghaleon_> changes
94 2014-03-20 00:57:18 <sipa> so, filter them out?
95 2014-03-20 00:57:29 <sipa> you can look at the output scripts
96 2014-03-20 00:57:37 <sipa> if they're to a change adress, it's change
97 2014-03-20 00:57:42 <arubi> yep ^^, you should know the change address before the tx broadcasts
98 2014-03-20 00:57:44 <Ghaleon_> som when using bitcoind wallet notify it will not fire on change address right?
99 2014-03-20 00:58:33 <Ghaleon_> what if the btc is coming from the outside.... i am using wallet notify to send my script the txid... we then lookup the tx id and figure out which address in the wallet for the btc
100 2014-03-20 00:58:46 <Ghaleon_> that is the system I am building now
101 2014-03-20 00:58:53 <sipa> the "transactions" that bitcoind wallet reports are "balance of wallet changes"
102 2014-03-20 00:58:55 <Ghaleon_> will it do ?
103 2014-03-20 00:59:00 <sipa> they are not "bitcoin transactions"
104 2014-03-20 00:59:08 <sipa> transfers within the wallet are not balance changes
105 2014-03-20 00:59:31 <Ghaleon_> so wallet notify will only report btc coming in from the outside... not any internal change ?
106 2014-03-20 00:59:54 <sipa> that's an irrelevant question
107 2014-03-20 01:00:03 <sipa> walletnotify notifies when there is change
108 2014-03-20 01:00:13 <sipa> but change is always within a transaction that has non-change too
109 2014-03-20 01:00:36 <sipa> but the listtransaction or gettransaction or listsinceblock or whatever RPC you do following walletnotify will show balance changes
110 2014-03-20 01:01:40 <Ghaleon_> wallet notify fires when there is a CHANGE to an address inside your wallet...... but NOT when change is sent internally. right?
111 2014-03-20 01:02:22 <Imbue> 'change is sent internally' does not really make sense to me
112 2014-03-20 01:02:37 <arubi> there has to be a change of balance to create change
113 2014-03-20 01:02:55 <[\\\]> I don't know if this constitutes a bug, but I figure its an artefact of the build system
114 2014-03-20 01:03:11 <Ghaleon_> the whole thing is mess
115 2014-03-20 01:03:13 <[\\\]> all of the Windows .9 x64 files are timestamped may 31/2013
116 2014-03-20 01:04:47 <volante> does anyone know of a simple command line utility that can securely generate BIP32 wallets?
117 2014-03-20 01:05:04 <SoftwareMechanic> pycoin can do it
118 2014-03-20 01:05:10 <SoftwareMechanic> genwallet
119 2014-03-20 01:07:57 <volante> ok thanks ill check it out
120 2014-03-20 01:08:03 <venzen> so i compiled the master branch from Git and got a yellow banner 0.9.0rc2 - is that expected atm?
121 2014-03-20 01:08:18 <Imbue> venzen: yes; 0.9.0 is not master
122 2014-03-20 01:08:27 <Imbue> venzen: there is a 0.9.0 branch
123 2014-03-20 01:09:05 <Imbue> well. the yellow banner is normal. rc2 is a bit odd (i actually had the same issue, forgot to checkout)
124 2014-03-20 01:09:53 <venzen> so not master but 0.9.0 - ok thanks Imbue - back to grinding stone then...
125 2014-03-20 01:10:28 <sipa> Ghaleon_: walletnotify is about transactions, not about outputs
126 2014-03-20 01:10:34 <sipa> Ghaleon_: your question is irrelevant
127 2014-03-20 01:11:13 <sipa> Ghaleon_: but the typical bitcoind wallet RPCs will deal correctly with change
128 2014-03-20 01:15:15 <Ghaleon_> ok, Sipa
129 2014-03-20 01:15:18 <Ghaleon_> thank you
130 2014-03-20 01:15:37 <Ghaleon_> Walletnotify fires twice right? first on 0 confirms raw broadcast.. and then on 6 confirms?
131 2014-03-20 01:17:07 <sipa> no, once when it's first seen, and once when it's in a block
132 2014-03-20 01:17:12 <sipa> but you shouldn't count on that
133 2014-03-20 01:17:28 <sipa> just see walletnotify as a message "i should check whether this transaction's state changed"
134 2014-03-20 01:17:52 <Ghaleon_> so when it is in a block you can safely say that it is LEGIT right?
135 2014-03-20 01:18:17 <arubi> that's what we're all betting on Ghaleon_ :)
136 2014-03-20 01:18:28 <Ghaleon_> ok
137 2014-03-20 01:18:30 <jrick> legit at the time, maybe not legit later after reorg
138 2014-03-20 01:18:52 <sipa> Ghaleon_: depends
139 2014-03-20 01:19:04 <sipa> for selling a house, i would probably wait for 100 confirmations
140 2014-03-20 01:19:13 <sipa> for selling a coffe, i would probably not wait at all
141 2014-03-20 01:19:20 <Ghaleon_> so I want to setup the right protocol... for handling these walletotify alerts, one the first one i make a record and set confirmations to zero.... one the second one i get the transaction info and get the # of confirmations and update the record...
142 2014-03-20 01:19:35 <Ghaleon_> yes, sips good point
143 2014-03-20 01:19:41 <sipa> Ghaleon_: you _always_ get the transaction info and synchronize
144 2014-03-20 01:19:52 <Ghaleon_> so basically we MUST move our system off blockchain.info and onto our own bitcoind rig right now
145 2014-03-20 01:19:55 <Ghaleon_> i have it going
146 2014-03-20 01:28:36 <venzen> Imbue: i checked out 0.9.0 and git told me "Already up-to-date", so either the same thing happened as with the OSX issue earlier or 0.9.0 is actually 0.9.0rc2 in github
147 2014-03-20 01:29:02 <Imbue> venzen: did you checkout the commit tag?
148 2014-03-20 01:29:32 <venzen> you mean: git checkout 0.9.0 ?
149 2014-03-20 01:29:35 <Imbue> i.e. git checkout 92d25....etc
150 2014-03-20 01:29:43 <venzen> hmm the tag
151 2014-03-20 01:30:00 <sipa> you need to do checkout v0.9.0
152 2014-03-20 01:30:05 <sipa> 0.9.0 is a branch
153 2014-03-20 01:30:23 <Imbue> the branch is at the same commit so it's interesting that it didn't work for you.
154 2014-03-20 01:30:38 <sipa> checkout <branch> just switching to that branch. locally
155 2014-03-20 01:30:42 <sipa> it doesn't update anything
156 2014-03-20 01:30:52 <Imbue> ah
157 2014-03-20 01:31:00 <Imbue> <-- gitnoob :P
158 2014-03-20 01:33:56 <Ghaleon_> they banned me from bit coin, for posting a pic of a brazilian lady... her booty was too big for them. anti big booty racism
159 2014-03-20 01:34:13 <venzen> nice
160 2014-03-20 01:34:18 <Ghaleon_> no matter. I shall now upgrade to bit coin 0.9.0 hats off to the hardest working debs on the planet
161 2014-03-20 01:34:19 <venzen> i did it right:
162 2014-03-20 01:34:20 <venzen> git merge 0.9.0 92d25e4eebbc20c4b056faeab688b2cef5790bac
163 2014-03-20 01:34:52 <venzen> and a cowboy says: Already up-to-date. Yeeah!
164 2014-03-20 01:35:19 <kadoban> venzen: ...what are you merging? you should just git checkout v0.9.0, and if you don't have that tag, fetch it first
165 2014-03-20 01:37:37 <miseria> "estoy solo en mi balcon, el viento acaricia mi rostro pero se lleva mi alma a viajar con las hojas secas que pasan y pasan" bienvenidos: http://castroruben.com *temo_a_un_ser_sin_rival*
166 2014-03-20 01:50:14 <sipa> venzen: git pull should suffice :)
167 2014-03-20 01:51:38 <anton000> will stay on 8.6.0 for a bit.... linux gclib issues lol
168 2014-03-20 01:52:27 <Luke-Jr> lol 8.6.0
169 2014-03-20 01:52:35 <anton000> .8.6
170 2014-03-20 01:52:39 <Luke-Jr> you have that a bit backward. we don't even have 1.0 yet :P
171 2014-03-20 01:52:41 <anton000> 0.8.6
172 2014-03-20 01:53:02 <anton000> bastard luke... hahahah just woke up
173 2014-03-20 01:53:12 <justanotheruser> 8.6.0 deciversions
174 2014-03-20 01:53:13 <anton000> *i just woke up
175 2014-03-20 01:53:22 <anton000> ACTION slaps Luke-Jr around a bit with a large trout
176 2014-03-20 01:53:30 <Luke-Jr> justanotheruser: no :P
177 2014-03-20 01:53:45 <Luke-Jr> justanotheruser: that just furthers the confusion of people who think versions are decimal numbers
178 2014-03-20 01:53:58 <justanotheruser> Luke-Jr: true.
179 2014-03-20 01:54:16 <sipa> sooo... when we have 0.10.0, that'll be the same as 1.0.0 ?
180 2014-03-20 01:55:20 <jgarzik> sipa, split the wallet into a separate project, remove the beta label, call the pieces left on the floor "1.0"
181 2014-03-20 01:55:21 <jgarzik> ;p
182 2014-03-20 01:55:38 <sipa> and from there on have diverging version numbers
183 2014-03-20 01:55:45 <justanotheruser> What is the conversion from the getinfo version to the actual version? Replace even digits with dots?
184 2014-03-20 01:55:58 <justanotheruser> 80600 -> .8.6
185 2014-03-20 01:56:01 <Luke-Jr> â¦
186 2014-03-20 01:56:08 <Luke-Jr> insert if you don't want to break 0.10
187 2014-03-20 01:56:22 <sipa> justanotheruser: aabbccdd = aa.bb.cc.dd
188 2014-03-20 01:56:49 <sipa> so 12045608 would be 12.4.56.8
189 2014-03-20 01:56:52 <justanotheruser> sipa: 8.0.6.0?
190 2014-03-20 01:56:56 <sipa> yes
191 2014-03-20 01:56:59 <sipa> no
192 2014-03-20 01:57:08 <sipa> 0.8.6.0
193 2014-03-20 01:57:16 <jgarzik> starting to smell like Oracle version numbers
194 2014-03-20 01:57:24 <jgarzik> need a 5th
195 2014-03-20 01:57:25 <sipa> as long as it's not ldap oids
196 2014-03-20 01:57:37 <jgarzik> hehe
197 2014-03-20 01:57:37 <justanotheruser> sipa: how do you signify that the first digit isn't 0?
198 2014-03-20 01:57:44 <jgarzik> don't use a zero
199 2014-03-20 01:57:44 <sipa> justanotheruser: it is
200 2014-03-20 01:57:54 <justanotheruser> sipa: how do you signify that the first digit isn't 0 if it wasn't?
201 2014-03-20 01:58:03 <sipa> don't use 0 there?
202 2014-03-20 01:58:13 <sipa> sheesh
203 2014-03-20 01:58:15 <justanotheruser> sipa: It isn't used there in 80600
204 2014-03-20 01:58:31 <sipa> justanotheruser: give me a version and i'll tell you the corresponding number
205 2014-03-20 01:58:42 <justanotheruser> sipa: 1.8.6.0
206 2014-03-20 01:58:49 <sipa> 1080600
207 2014-03-20 01:59:04 <justanotheruser> So my original statement was close
208 2014-03-20 01:59:10 <sipa> no
209 2014-03-20 01:59:18 <sipa> dots aren't encoded at all
210 2014-03-20 01:59:24 <sipa> (just happens to be true in this case)
211 2014-03-20 01:59:37 <sipa> but 1.18.6.0 would be 1180600
212 2014-03-20 01:59:39 <Luke-Jr> wtf
213 2014-03-20 01:59:43 <Luke-Jr> how hard is this
214 2014-03-20 01:59:46 <sipa> yeah
215 2014-03-20 01:59:49 <sipa> #bitcoin please :)
216 2014-03-20 02:00:24 <Luke-Jr> justanotheruser: W.X.Y.Z; Z = N % 100; Y = (N / 100) % 100; X = (N / 10000) % 100; W = (N / 1000000) % 100
217 2014-03-20 02:00:25 <justanotheruser> Heh, I just didn't know how it was defined
218 2014-03-20 02:00:35 <sipa> 02:56:21 < sipa> justanotheruser: aabbccdd = aa.bb.cc.dd
219 2014-03-20 02:00:39 <sipa> = all you nee dto know
220 2014-03-20 02:01:09 <justanotheruser> sipa: oh, I didn't realize that there could only be 2 digits between dots, but I see how I should have understood that
221 2014-03-20 02:03:08 <anton000> lol... that escalated quickly
222 2014-03-20 02:05:04 <sipa> justanotheruser: so currently git master is 0.9.99 (aka pre-0.10.0) at 99900, 0.10.0 will be 100000
223 2014-03-20 02:06:23 <justanotheruser> sipa: I see. It is *really* simple when I understand that you can only have two digits per dot
224 2014-03-20 02:06:33 <justanotheruser> or between dots I mean
225 2014-03-20 02:07:21 <justanotheruser> sipa: Is there anywhere I can read the requirements for Bitcoin to be in 1.X.X? Or are they not defined?
226 2014-03-20 02:07:45 <sipa> justanotheruser: when Gavin thinks his grandmother should use it
227 2014-03-20 02:07:53 <anton000> lol
228 2014-03-20 02:07:56 <anton000> hahahaha
229 2014-03-20 02:08:02 <sipa> that's the only hard requirement i've ever heard
230 2014-03-20 02:08:57 <justanotheruser> sounds fair. I wonder what the community will think when we are at 0.10.X. I (and many others probably) assumed we were close to the first 1.X release.
231 2014-03-20 02:09:37 <sipa> i agree that 0.10 sounds much further from 1.0 than 0.9 does
232 2014-03-20 02:09:51 <sipa> but it's the logical successor
233 2014-03-20 02:10:41 <justanotheruser> yes. I think it is better to do 1.X when it is completely ready than force it though.
234 2014-03-20 02:25:36 <ystarnaud> running into an odd issue... whenever i run bitcoind i get "bitcoind: key.cpp:134: <unnamed>::CECKey::CECKey(): Assertion `pkey != __null' failed. Aborted (core dumped)". This happened after running out of space for the blockchain. I wiped everything and recompiled from scratch using 0.9.0 and still happens. Anybody has any idea what it could be?
235 2014-03-20 02:31:56 <venzen> ystarnaud: did you re-download the BC ?
236 2014-03-20 02:32:08 <ystarnaud> yeah i wiped the whole directory
237 2014-03-20 02:32:11 <ystarnaud> well
238 2014-03-20 02:32:13 <ystarnaud> it didnt get that far
239 2014-03-20 02:32:19 <ystarnaud> it core dumps right away
240 2014-03-20 02:33:28 <ystarnaud> db.log is empty... debug.log's last line is "2014-03-20 02:29:14 Performing wallet upgrade to 60000" on an empty wallet.dat btw
241 2014-03-20 02:33:46 <venzen> ystarnaud: trying to understand your sequence of actions... delete the .bitcoin data directory, recompile, start, and then a segfault?
242 2014-03-20 02:33:57 <ystarnaud> yep
243 2014-03-20 02:34:56 <venzen> well that is strange - do you have another machine to compile on?
244 2014-03-20 02:35:17 <ystarnaud> not currently no
245 2014-03-20 02:36:01 <venzen> someone here may have encountered this before and help us out, but it seems to me to be a hardware issue - either memory or disk
246 2014-03-20 02:36:29 <venzen> that is if you're 100% positive you deleted the data dir
247 2014-03-20 02:37:17 <ystarnaud> yeah i rm -rf /root/.bitcoin (after making a copy that is...)
248 2014-03-20 02:38:26 <venzen> maybe try compiling again as a regular user, and use that same user account to run bitcoind
249 2014-03-20 02:39:03 <venzen> also: make sure you've backed up your wallet :)
250 2014-03-20 03:25:13 <dexX7> what height and time are those fields referring to in a verbosed getrawmempool result?
251 2014-03-20 03:25:51 <sipa> i presume the height and time at which the transaction was received
252 2014-03-20 03:27:41 <dexX7> ty for the confirmation
253 2014-03-20 03:48:27 <ystarnaud> ok i finally found a solution... im running on centos 6.2 and because of some licensing bullcrap secp256k1 is not included on fedora/centos openssl
254 2014-03-20 03:49:32 <ystarnaud> not sure why it suddenly stopped working but i found a patch for key.cpp buried deep in forums that corrected the problem
255 2014-03-20 03:49:39 <Luke-Jr> ystarnaud: not exactly; because *redhat's lawyers* haven't *verified* there's no licensing crapâ¦
256 2014-03-20 03:50:11 <ystarnaud> well i dont know the exact details but yeah
257 2014-03-20 03:50:52 <ystarnaud> weird that it used to work fine though
258 2014-03-20 03:52:15 <Luke-Jr> ystarnaud: wait, are you using the official binary?
259 2014-03-20 03:52:23 <ystarnaud> of?
260 2014-03-20 03:53:33 <sipa> if he's talking about key.cpp, he's clearly building from source
261 2014-03-20 03:53:47 <ystarnaud> yeah i got bitcoin off github and compiled it myself
262 2014-03-20 03:53:50 <ystarnaud> always have
263 2014-03-20 03:54:03 <sipa> that never should have worked...
264 2014-03-20 03:54:16 <sipa> rh never had secp256k1 in their openssl afaik
265 2014-03-20 03:54:34 <sipa> so you were at least using a custom openssl too?
266 2014-03-20 03:54:42 <ystarnaud> yeah thats the weird part... it always ran fine until i ran out of space then it was an issue at runtime
267 2014-03-20 03:54:51 <venzen> ystarnaud: strange, and you're not even RHEL - and they come bother all the way over in Centos... tsk tsk... glad it's solved though - just be mindful of running things as root - you know the reasons...
268 2014-03-20 03:55:10 <sipa> how is that relevant?
269 2014-03-20 03:55:24 <venzen> Redhat...
270 2014-03-20 03:55:31 <venzen> ystarnaud: is in Centos
271 2014-03-20 03:55:38 <ystarnaud> i dont recall installing openssl myself but i might have a long time ago... i tried to update openssl from yum tonight trying to resolve the issue
272 2014-03-20 03:55:49 <sipa> won't help
273 2014-03-20 03:56:48 <ystarnaud> yeah it didnt help lol
274 2014-03-20 03:57:01 <venzen> why, sipa ? is it incompatible?
275 2014-03-20 03:57:18 <ystarnaud> i tried to compile openssl from scratch too and still didnt work until i patched the file
276 2014-03-20 03:58:27 <Luke-Jr> venzen: RedHat's OpenSSL is "special" (neutered)
277 2014-03-20 03:58:54 <venzen> hehe, ouch
278 2014-03-20 04:02:35 <sipa> there is some repository with an ec-enabled openssl
279 2014-03-20 04:02:44 <sipa> warren probably knows more
280 2014-03-20 04:05:46 <dizko> hrm...0.9.0 with wallet disabled has slightly smaller resident memory footprint, but it's allocated like 10-20% more virtual memory than 0.8.5
281 2014-03-20 04:06:23 <venzen> ystarnaud: sipa's suggestion is one way and you could run a different linux in a VM to compile and host Bitcoin Core?
282 2014-03-20 04:12:32 <warren> sipa: who needs it?
283 2014-03-20 04:13:06 <warren> sipa: might be easier for them to use https://bitcointalk.org/index.php?topic=364877.0
284 2014-03-20 04:13:15 <warren> sipa: I do have packages for Fedora 19 and 20 of openssl with ec
285 2014-03-20 04:13:31 <sipa> dizko: virtual memory? don't care much
286 2014-03-20 04:13:41 <sipa> dizko: resident memory is what matters
287 2014-03-20 04:14:43 <dizko> sipa: so long as you have swap ;)
288 2014-03-20 04:15:42 <sipa> dizko: not really
289 2014-03-20 04:15:53 <sipa> muvh virtual memory is unused stack space
290 2014-03-20 04:16:02 <sipa> which needs neither ram or swap
291 2014-03-20 04:17:58 <sipa> warren: ystarnaud
292 2014-03-20 04:18:16 <dizko> mmap(NULL, 25165824, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
293 2014-03-20 04:18:40 <sipa> well you can always run out of course
294 2014-03-20 04:19:00 <sipa> i just mean that it's not necessary to have ram or swap to back all virtual memory
295 2014-03-20 04:19:07 <dizko> its fine, i can have a swap file, was just glad to hear about the nowallet option memory saving as i run a number of very small public relays
296 2014-03-20 04:19:16 <sipa> cool
297 2014-03-20 04:28:18 <warren> ystarnaud: http://wtogami.blogspot.com/2013/05/openssl-with-ecdsa-for-fedora-18.html
298 2014-03-20 04:42:23 <felipelalli> Guys, here: https://github.com/bitcoin/bitcoin/blob/master/doc/files.md#only-used-in-pre-080
299 2014-03-20 04:42:34 <felipelalli> what is the difference between pre-0.8.0 and before 0.8.0 ?
300 2014-03-20 05:03:36 <JohnKenney> i noticed my new build of bitcoind uses much more ram too
301 2014-03-20 05:03:54 <JohnKenney> ~900mb resident
302 2014-03-20 05:04:25 <JohnKenney> self compiled on ubuntu 13.10
303 2014-03-20 05:05:56 <JohnKenney> i've been building from github, so some recent change caused it
304 2014-03-20 05:08:07 <JohnKenney> not sure exactly how much it was using before, but less than that
305 2014-03-20 05:15:25 <JohnKenney> i don't know which commit could possibly have caused it though, something since the 14th i think
306 2014-03-20 05:16:07 <JohnKenney> unless it's just me
307 2014-03-20 05:17:31 <dizko> once mine got connected up its got as much rss as before even with wallet disabled
308 2014-03-20 05:17:35 <dizko> about 420mb
309 2014-03-20 05:18:00 <felipelalli> Guys, here: https://github.com/bitcoin/bitcoin/blob/master/doc/files.md#only-used-in-pre-080 what is the difference between pre-0.8.0 and before 0.8.0 ?
310 2014-03-20 05:22:11 <sipa> felipelalli: it was only used in some pre-release version, but changed before 0.8 was done
311 2014-03-20 05:22:27 <felipelalli> thank you @sipa !
312 2014-03-20 05:23:06 <BlueMatt> why is sipa awake at this ungodly hour?
313 2014-03-20 05:23:21 <BlueMatt> hell, its not even a reasonable in cet....
314 2014-03-20 05:28:51 <venzen> kadoban sipa: can you believe that a person can achieve all i have done, and never had to do more than a "git clone ..." in the process? Fetched, compiled and running a GUI Coar and a barebones (minus wallet) version on a VPS... fantastic.
315 2014-03-20 05:49:48 <sipa> BlueMatt: still in pacific time :)
316 2014-03-20 05:50:18 <sipa> being awake at 11pm should be allowed, imho
317 2014-03-20 06:05:42 <rasmuzen> can many different private keys all be hashed to a single bitcoin address?
318 2014-03-20 06:06:02 <beachandbytes> no
319 2014-03-20 06:06:41 <beachandbytes> private keys are not hashed to create bitcoin addresses
320 2014-03-20 06:08:21 <rasmuzen> ...you sure?
321 2014-03-20 06:08:35 <kadoban> rasmuzen: Do you mean something like, are there theoretically several different keypairs that would all correspond to the same address? Then I think yes.
322 2014-03-20 06:09:44 <rasmuzen> does that mean that any private key that corresponds to the address will be able to sign a transaction?
323 2014-03-20 06:10:31 <beachandbytes> public keys are hasked to create the address not the private key
324 2014-03-20 06:11:08 <rasmuzen> beachandbytes: what's your point?
325 2014-03-20 06:11:09 <beachandbytes> https://en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addresses
326 2014-03-20 06:11:40 <beachandbytes> you asked if diff private keys can be hashed to create a single btc address
327 2014-03-20 06:11:47 <beachandbytes> that is a misunderstanding of how it works
328 2014-03-20 06:12:23 <kadoban> rasmuzen: I am 99% sure it's a yes to your previous question.
329 2014-03-20 06:13:22 <kadoban> rasmuzen: to spend, you need to provide a pubKey, so I think any pubKey that hashed the same would work
330 2014-03-20 06:13:53 <kadoban> in practice...good luck finding another one though
331 2014-03-20 06:17:09 <michagogo> cloud|Iirc I did the math and each address has octillions of privkeys
332 2014-03-20 06:18:36 <kadoban> nice
333 2014-03-20 06:18:53 <BlueMatt> sipa: ohh, yea...I suppose 23 is ok
334 2014-03-20 06:24:03 <gribble> 79228162514264337593543950336
335 2014-03-20 06:24:03 <sipa> ;;calc 2**96
336 2014-03-20 06:24:28 <sipa> ^ on averge, that many privkeys per address
337 2014-03-20 06:24:38 <sipa> howver:
338 2014-03-20 06:24:57 <gribble> 1461501637330902918203684832716283019655932542976
339 2014-03-20 06:24:57 <sipa> ;;calc 2**160
340 2014-03-20 06:25:18 <sipa> ^ only one in that many keys corresponds to a given address
341 2014-03-20 06:25:36 <Luke-Jr> wow, that number is smaller than I expected :P
342 2014-03-20 06:25:44 <kadoban> haha
343 2014-03-20 06:25:56 <sipa> Luke-Jr: i suggest increasing your font size
344 2014-03-20 06:26:14 <sipa> or decreasing your number base :p
345 2014-03-20 06:26:19 <Luke-Jr> btw, it's exactly 1,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000 in tonal
346 2014-03-20 06:26:54 <antephialtic> but what is it in base 17?
347 2014-03-20 06:27:17 <Luke-Jr> antephialtic: 189BF302G7G3F0EFCE3F9CDE76CD07FECBEE8CB1
348 2014-03-20 06:27:50 <sipa> antephialtic: in what base is that number 17?
349 2014-03-20 06:28:22 <Luke-Jr> ACTION ponders
350 2014-03-20 06:28:46 <sipa> to make things easyg for luke, we should interpret that 17 as if in base 9
351 2014-03-20 06:29:15 <Luke-Jr> <.<
352 2014-03-20 06:29:54 <Luke-Jr> 22111200212110210121112201221101020201211222202211202222010210002111111201101120221012122101022002021 looks longer.
353 2014-03-20 06:30:08 <Luke-Jr> of course, there's always 10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
354 2014-03-20 06:31:01 <Luke-Jr> or dozenal: 496653â°ï¿½ï¿½15â°95867701865716816â°05998��830â°ï¿½ï¿½59â°14
355 2014-03-20 06:31:03 <antephialtic> sipa: good question. let me be more specific. under the standard set theoretic construction of the natural numbers, {{}, {{}}, {{{}}}}, ..
356 2014-03-20 06:31:15 <Luke-Jr> ACTION wonders if he should take the time to add � to his font >.>
357 2014-03-20 06:31:34 <justanotheruser> In base 1 please
358 2014-03-20 06:32:02 <Luke-Jr> justanotheruser: that gets too long for IRC
359 2014-03-20 06:32:19 <antephialtic> base e ?
360 2014-03-20 06:32:28 <Luke-Jr> that's too complicated for my python module
361 2014-03-20 06:32:43 <justanotheruser> Is it even possible to use fractional bases?
362 2014-03-20 06:32:58 <justanotheruser> Or non-natural I should say
363 2014-03-20 06:33:14 <Luke-Jr> sure
364 2014-03-20 06:33:30 <justanotheruser> Is there a name for such bases? A wiki?
365 2014-03-20 06:33:31 <Luke-Jr> I have C code to do that somewhere, but not worth the time to dig it out
366 2014-03-20 06:33:38 <antephialtic> justanotheruser: http://en.wikipedia.org/wiki/Negative_base#Fractional_numbers
367 2014-03-20 06:33:54 <antephialtic> apparently you can do imaginary base as well.
368 2014-03-20 06:34:35 <Luke-Jr> http://en.wikipedia.org/wiki/Golden_ratio_base
369 2014-03-20 06:34:37 <cryptoc> hey everyone, I just compiled the latest from master and my bitcoind getinfo is reading version 99900 -- is this correct?
370 2014-03-20 06:35:04 <cryptoc> additionally, it seems external RPC calls are broken
371 2014-03-20 06:35:37 <michagogo> cloud|cryptoc: yes, it is
372 2014-03-20 06:35:44 <michagogo> cloud|That's version 0.9.99
373 2014-03-20 06:35:58 <cryptoc> micagogo|cloud thank you, but it also says: " "errors" : "This is a pre-release test build - use at your own risk - do not use for mining or merchant applications""
374 2014-03-20 06:36:25 <cryptoc> and it's not allowing incoming RPC requests, despite rpcallow etc everything enabled
375 2014-03-20 06:36:52 <justanotheruser> I see. So it requires decimals for pretty much every number
376 2014-03-20 06:38:11 <kadoban> cryptoc: were you expecting to get v0.9.0 ? then look for that tag, don't take from the head of master
377 2014-03-20 06:38:35 <cryptoc> kadoban, indeed, apologies
378 2014-03-20 06:38:39 <Luke-Jr> cryptoc: uh, if it didn't allow incoming RPC requests, you couldn't see "errors"
379 2014-03-20 06:38:57 <Luke-Jr> justanotheruser: no, it's not decimal..
380 2014-03-20 06:39:06 <cryptoc> Luke-Jr : I am not seeing errors from my client call, this is when I run bitcoind getinfo from terminal on the box
381 2014-03-20 06:39:25 <cryptoc> Luke-Jr: but the RPC is not accessible from external host despite settings not having changed since my ugprade
382 2014-03-20 06:39:28 <cryptoc> upgrade*
383 2014-03-20 06:39:30 <Luke-Jr> cryptoc: bitcoind getinfo is a RPC call
384 2014-03-20 06:39:43 <Luke-Jr> cryptoc: in general, accessing RPC from outside localhost is unsupported
385 2014-03-20 06:39:46 <justanotheruser> Luke-Jr: https://en.wikipedia.org/wiki/Golden_ratio_base#Representing_irrational_numbers_of_note_as_golden_ratio_base_numbers
386 2014-03-20 06:39:48 <Luke-Jr> and probably a bad idea
387 2014-03-20 06:39:53 <justanotheruser> Oh shit
388 2014-03-20 06:39:59 <justanotheruser> Haha, I see what you're saying
389 2014-03-20 06:40:16 <cryptoc> Luke-Jr: I can understand, but I thought that was the point of rpcallowip, rpcssl, etc
390 2014-03-20 06:40:34 <Luke-Jr> cryptoc: it was, but it still isn't a good idea
391 2014-03-20 06:40:37 <Luke-Jr> justanotheruser: âº
392 2014-03-20 06:41:01 <cryptoc> Luke-Jr: can you elaborate?
393 2014-03-20 06:41:03 <justanotheruser> I'm used to calling the fraction after the decimal point decimals :)
394 2014-03-20 06:45:00 <cryptoc> Luke-Jr: I can understand where it'd be more attractive from a security standpoint to call a script which fires up the RPC call natively, instead of using a remote call, but do you have any other thoughts?
395 2014-03-20 06:45:04 <Luke-Jr> cryptoc: it's not designed to be robust against attack
396 2014-03-20 06:45:28 <cryptoc> Luke-Jr: I see, thank you.
397 2014-03-20 06:51:27 <warren> there is a complaint on the forum that transifex is seeks behind in sync with master's source strings?
398 2014-03-20 06:51:33 <warren> weeks* behind
399 2014-03-20 06:56:07 <Luke-Jr> warren: I imagine it's tied to 0.9.0?
400 2014-03-20 06:56:17 <Luke-Jr> for now
401 2014-03-20 07:02:45 <wumpus> it's always people complaining isn't it...
402 2014-03-20 07:04:08 <wumpus> they can pull translations from transifex themselves you know
403 2014-03-20 07:05:45 <antephialtic> any reason that its been almost an hour since the last block?
404 2014-03-20 07:05:52 <wumpus> last transifex pull was *10 days ago* (both to master and 0.9.0) sheesh
405 2014-03-20 07:07:12 <warren> wumpus: then the complaint on the forum is false
406 2014-03-20 07:07:39 <wumpus> but of course, something could have always gone wrong
407 2014-03-20 07:08:03 <wumpus> it's always easier to complain on the forums than try to figure out what
408 2014-03-20 07:23:07 <Luke-Jr> wumpus: I interpreted warren's summary of the complaint to mean the *source data* in Transifex is stale
409 2014-03-20 07:25:54 <wumpus> the latest english translation update (from source code) was 3 weeks ago, since then there have been only some minor message changes
410 2014-03-20 07:27:41 <warren> I only recently learned how to use transifex for a different project. It is not without its problems, but I learned the upstream developers need to better feed the source strings for it to be useful.
411 2014-03-20 07:28:07 <wumpus> it has turned out to be quite useful
412 2014-03-20 07:33:56 <wumpus> though last time I did a sync from tx, the Korean translation had some invalid control characters in it causing lrelease to be unable to parse it
413 2014-03-20 07:34:54 <warren> not without its problems
414 2014-03-20 07:35:10 <warren> it is entirely open source though, unlike its competitors
415 2014-03-20 07:35:11 <wumpus> nothing is
416 2014-03-20 07:46:12 <warren> wumpus: may I recommend using a practice in other projects, a string freeze before intended release.
417 2014-03-20 07:46:38 <wumpus> warren: we had an effective string freeze for some time already
418 2014-03-20 07:48:04 <Luke-Jr> do we get a string thaw too?
419 2014-03-20 07:48:05 <wumpus> then again I'm sure something snuck through
420 2014-03-20 07:48:17 <wumpus> doesn't everything always go wrong
421 2014-03-20 07:48:36 <Luke-Jr> pulltester should complain if strings change in odd-numbered months.
422 2014-03-20 07:48:45 <Luke-Jr> then we can just do releases on the first day of even-numbered months
423 2014-03-20 07:48:47 <Luke-Jr> :P
424 2014-03-20 07:49:02 <wumpus> Luke-Jr: hah well now that final is out I suppose we can have our string thaw
425 2014-03-20 07:49:25 <Luke-Jr> yay, let's change ALL the strings!
426 2014-03-20 07:49:47 <wumpus> woohoo!
427 2014-03-20 07:49:56 <Luke-Jr> English +1 for allowing a string change no matter what the string
428 2014-03-20 07:52:37 <wumpus> let's see if it is possible to make gitian produce fully static executables without having to patch the build system
429 2014-03-20 08:01:09 <warren> wumpus: I just made gitian binaries that work on all the same distros as 0.8.6
430 2014-03-20 08:01:26 <wumpus> without having to downgrade the VM?
431 2014-03-20 08:01:29 <warren> wumpus: I'm sad I forgot to warn about this. I discovered this problem a few months ago.
432 2014-03-20 08:01:34 <warren> wumpus: no, downgraded the VM
433 2014-03-20 08:01:36 <Luke-Jr> â¦
434 2014-03-20 08:01:43 <uiop> ACTION hopes that includes {rhel,centos}6 :)
435 2014-03-20 08:01:48 <warren> yes
436 2014-03-20 08:01:56 <wumpus> I want a solution that works without downgrading the VM
437 2014-03-20 08:02:01 <Luke-Jr> [22:25:05] <Luke-Jr> can probably get autotools to do some trick like http://www.trevorpounds.com/blog/?p=103 with --with-libc-compat=x or such
438 2014-03-20 08:02:04 <uiop> warren: you are gentleman and a scholar
439 2014-03-20 08:02:19 <Luke-Jr> (or just static link glibc..)
440 2014-03-20 08:02:26 <uiop> no!
441 2014-03-20 08:02:36 <wumpus> we have a great influx of gitian builders now, don't want to make it more complex for them by adding more types
442 2014-03-20 08:02:52 <warren> uiop: I changed a few strings. gavin and wumpus already made it clear they won't accept this solution, so until we find a better way I will need to distribute this myself.
443 2014-03-20 08:02:57 <wumpus> Luke-Jr: with-libc-compat? I'll take a look at that
444 2014-03-20 08:03:07 <Luke-Jr> wumpus: that was my suggested implementation :P
445 2014-03-20 08:03:10 <warren> Luke-Jr: I looked into this last year and failed
446 2014-03-20 08:03:17 <wumpus> Luke-Jr: yes I'm currently just making a bitcoind.static that is fully static
447 2014-03-20 08:03:25 <wumpus> Luke-Jr: including glibc and libstdc++
448 2014-03-20 08:04:02 <warren> wumpus: how large is it?
449 2014-03-20 08:04:22 <warren> wumpus: that's less desirable for reasons other than size...
450 2014-03-20 08:04:23 <wumpus> warren: no clue, still building
451 2014-03-20 08:04:37 <wumpus> warren: I know *KNOW* that, have you seen my list of reasons in that issue?
452 2014-03-20 08:04:48 <wumpus> it's better than nothing though
453 2014-03-20 08:04:50 <warren> I agree this sucks.
454 2014-03-20 08:05:03 <warren> as much as it sucks, the downgraded VM is better
455 2014-03-20 08:05:15 <warren> unless someone figures out a better solution
456 2014-03-20 08:05:16 <wumpus> well good luck with that
457 2014-03-20 08:05:24 <warren> I'm distributing this if you won't.
458 2014-03-20 08:05:25 <warren> I'm sorry.
459 2014-03-20 08:05:34 <wumpus> you don't have to be sorry, distribute what you want
460 2014-03-20 08:05:43 <wumpus> it's a free world
461 2014-03-20 08:05:46 <wumpus> :P
462 2014-03-20 08:07:04 <uiop> ACTION unleashes ulrich drepper on you all
463 2014-03-20 08:07:10 <Luke-Jr> ACTION votes we stop trying to ship a Linux binary and just make packages for any distros we care about <.<
464 2014-03-20 08:07:21 <wumpus> Luke-Jr: one problem: determinism :-(
465 2014-03-20 08:07:28 <Luke-Jr> wumpus: so? <.<
466 2014-03-20 08:07:40 <Luke-Jr> yeah okay, I guess that's more complicated
467 2014-03-20 08:07:42 <Luke-Jr> sigh
468 2014-03-20 08:07:45 <warren> Luke-Jr: we can't do that
469 2014-03-20 08:07:45 <wumpus> Luke-Jr: it's a superior solution for the end-users, but can we build all those packages in a deterministic way without zillions of VMs?
470 2014-03-20 08:07:48 <warren> Luke-Jr: opensl
471 2014-03-20 08:07:54 <Luke-Jr> warren: what?
472 2014-03-20 08:08:01 <wumpus> warren: just link that statically
473 2014-03-20 08:08:15 <warren> Luke-Jr: the gitian binary has been the easiest to support for all red hat and fedora distros.
474 2014-03-20 08:08:36 <warren> Luke-Jr: I'd prefer to make a gitian binary and stuff that into an rpm.
475 2014-03-20 08:08:42 <wumpus> uiop: ulrich drepper? is that good or bad?
476 2014-03-20 08:09:15 <warren> wumpus: sounds like an ancient hex, but it's really a glibc/gcc developer.
477 2014-03-20 08:09:51 <uiop> wumpus: he was the glibc maintainer for a stretch, and he is famous for his humoursly-dialected rants against static libs (because the wrote a fair part of ld.so)
478 2014-03-20 08:10:04 <wumpus> warren: oh no, those are the worst, I was mugged by one last night
479 2014-03-20 08:10:21 <warren> uiop: gitian binary outputs are gigantic static binaries. as much as I hate static linking it's been a better solution for bitcoin.
480 2014-03-20 08:10:54 <uiop> http://www.akkadia.org/drepper/dsohowto.pdf
481 2014-03-20 08:10:56 <wumpus> $ ldd build/out/bin/32/bitcoind -> statically linked HAH that was easy
482 2014-03-20 08:10:59 <uiop> http://www.akkadia.org/drepper/symbol-versioning
483 2014-03-20 08:11:03 <uiop> http://www.akkadia.org/drepper/no_static_linking.html
484 2014-03-20 08:11:14 <uiop> is a cross section
485 2014-03-20 08:11:18 <uiop> the source: http://www.akkadia.org/drepper/
486 2014-03-20 08:11:28 <wumpus> it's only 9MB too
487 2014-03-20 08:12:34 <uiop> warren: but glibc?!? (i do appreciate that the tools don't exist to create a setup so that you can link against the glb of glibc symbol version available in all distros of interest, and this is unfortunate)
488 2014-03-20 08:12:53 <uiop> (glb := greatest lower bound)
489 2014-03-20 08:13:56 <Luke-Jr> "And no, it is not possible in general to generate PIEs with static linking."
490 2014-03-20 08:14:07 <uiop> wumpus, warren: with the caveats that you now need to track openssl, et al daily security bulletins..
491 2014-03-20 08:14:17 <wumpus> I know that Luke-Jr, also listed that in the issue
492 2014-03-20 08:14:26 <wumpus> uiop: we already link openssl statically both on linux and windows
493 2014-03-20 08:14:37 <uiop> wumpus: :o
494 2014-03-20 08:14:46 <wumpus> uiop: have been doing that since the beginning in gitian builds
495 2014-03-20 08:15:13 <Luke-Jr> it makes no sense to static link Windows :P
496 2014-03-20 08:15:23 <uiop> what's the link to this "issue" you're mentioning?
497 2014-03-20 08:15:27 <wumpus> Luke-Jr: joker
498 2014-03-20 08:15:36 <Luke-Jr> wumpus: not at all, just dump the DLLs in the program directory
499 2014-03-20 08:15:51 <uiop> windows is a total horrorshow
500 2014-03-20 08:16:03 <Luke-Jr> works as well as static linking, except users can opt to de-duplicate
501 2014-03-20 08:16:22 <wumpus> my 32-bit statically built bitcoind built on 12.04 doesn't work on 14.04 64 bit... how cure
502 2014-03-20 08:16:23 <wumpus> cute*
503 2014-03-20 08:16:31 <Luke-Jr> wumpus: lol?
504 2014-03-20 08:16:36 <Luke-Jr> now you're the joker
505 2014-03-20 08:16:37 <Luke-Jr> :P
506 2014-03-20 08:16:52 <Luke-Jr> oh, maybe becuase the localisation stuff
507 2014-03-20 08:16:56 <wumpus> and you know what error it gives? 'No such file or directory' HAH HAH HAH
508 2014-03-20 08:17:09 <Luke-Jr> wumpus: is 14.04 pure 64-bit?
509 2014-03-20 08:17:09 <warren> Luke-Jr: dll's aren't any better on windows in maintainability
510 2014-03-20 08:17:23 <wumpus> it can't find the ld.so .. which is indeed in a different place
511 2014-03-20 08:17:24 <Luke-Jr> warren: the point is Windows will use your local DLLs first
512 2014-03-20 08:17:27 <wumpus> Luke-Jr: no, mixed
513 2014-03-20 08:17:35 <warren> Luke-Jr: that doesn't help at all
514 2014-03-20 08:17:39 <warren> Luke-Jr: over the static build
515 2014-03-20 08:17:40 <Luke-Jr> wumpus: static binaries don't need ld.so :P
516 2014-03-20 08:17:53 <wumpus> why does a static executable look for ld.so while starting, I don't know, ldd says it's static but seemingly its not static enough
517 2014-03-20 08:17:55 <Luke-Jr> warren: it doesn't hurt, but it does help users who want to share common DLLs
518 2014-03-20 08:18:12 <wumpus> the 64-bit one works perfectly though (and is really static)
519 2014-03-20 08:18:39 <Luke-Jr> wumpus: what about the x32 one? or do we even build that yet?
520 2014-03-20 08:18:56 <wumpus> uiop: https://github.com/bitcoin/bitcoin/issues/3803
521 2014-03-20 08:19:19 <warren> Luke-Jr: good luck with that
522 2014-03-20 08:19:37 <Luke-Jr> warren: thanks, I'm sure I'll need it! :P
523 2014-03-20 08:20:11 <gmaxwell> Luke-Jr: you really don't want that, lack of ability to use the 64,64->128 multiply makes libsecp256k1 something like 2x slower. :)
524 2014-03-20 08:20:25 <Luke-Jr> gmaxwell: x32 can't use it?
525 2014-03-20 08:20:44 <wumpus> "Dynamic section at offset 0x8ab514 contains 24 entries" my 32-bit static binary has a dynamic section, but without any references to libraries, how funny
526 2014-03-20 08:20:53 <gmaxwell> the registers are 32 bits, so I don't think so.
527 2014-03-20 08:21:01 <Luke-Jr> gmaxwell: no, x32 registers are 64-bit
528 2014-03-20 08:21:06 <uiop> http://stackoverflow.com/questions/3430400/linux-static-linking-is-dead (re: glibc static link isn't *fully* static)
529 2014-03-20 08:21:28 <warren> ACTION facepalms hard.
530 2014-03-20 08:21:36 <wumpus> oh it's only a bit static
531 2014-03-20 08:22:09 <uiop> static-ish-y
532 2014-03-20 08:22:43 <wumpus> the 64-bit one is really, really static though, just the 32-bit one isn't
533 2014-03-20 08:22:54 <wumpus> let's just drop 32 bit support
534 2014-03-20 08:23:05 <uiop> heh
535 2014-03-20 08:23:21 <Luke-Jr> wumpus: maybe static non-glibc?
536 2014-03-20 08:23:44 <uiop> as in, another libc? (hairy)
537 2014-03-20 08:23:47 <wumpus> (I'm sick of all these permutations, we should have a centrally enforced 'computer' system with one set of hardware and software... oh,wait)
538 2014-03-20 08:24:56 <Luke-Jr> wumpus: let's just compile to .NET bytecode
539 2014-03-20 08:25:01 <Luke-Jr> ACTION hides in shame
540 2014-03-20 08:25:09 <uiop> compile to bitcoin script!
541 2014-03-20 08:25:18 <Luke-Jr> uiop wins
542 2014-03-20 08:25:28 <wumpus> :D
543 2014-03-20 08:25:36 <Luke-Jr> who does the GCC patch?
544 2014-03-20 08:26:02 <warren> software is hard. let's go back to fiat.
545 2014-03-20 08:26:03 <wumpus> it's too bad that java and .net and similar systems never did solve the issue of cross-platform variability, they just add a layer on top
546 2014-03-20 08:26:09 <warren> No problems with fiat, right?
547 2014-03-20 08:26:34 <wumpus> warren: there's software there too
548 2014-03-20 08:26:42 <warren> damn
549 2014-03-20 08:26:43 <Luke-Jr> warren: as long as it's tonal and ideally non-inflationary
550 2014-03-20 08:26:50 <Luke-Jr> no demurrage either, that just confuses me
551 2014-03-20 08:27:26 <Luke-Jr> always annoying when I start up Freicoin-Qt and have to watch the FRC balance drop :/
552 2014-03-20 08:29:02 <wumpus> doh, I'm still passing -pie, of course I get a static-ish executable
553 2014-03-20 08:29:57 <antephialtic> demurrage is a bitch, eh.
554 2014-03-20 08:30:45 <wumpus> antephialtic: it's hard to debug whether it's demurrage or your wallet just has a leak :p
555 2014-03-20 08:31:12 <warren> bitcoin wallets have no leaks.
556 2014-03-20 08:31:14 <warren> oh wait
557 2014-03-20 08:31:32 <antephialtic> bitcoin is perfect. all hail satoshi, the savior of us all.
558 2014-03-20 08:32:55 <wumpus> no leaks ever
559 2014-03-20 08:35:55 <warren> grr, setting up a gitian.sigs for this build
560 2014-03-20 08:48:28 <wumpus> There is no dynamic section in this file. woohoo
561 2014-03-20 08:48:45 <warren> how big is it?
562 2014-03-20 08:49:20 <wumpus> 8407524 for the 32-bit, 8632240 for the 64-bit
563 2014-03-20 08:49:37 <wumpus> so, peanuts
564 2014-03-20 08:52:12 <wumpus> (for comparison, the currently released ones are ~7.7MB)
565 2014-03-20 08:54:53 <uiop> wumpus: just saw the link (issues/###), thx
566 2014-03-20 09:03:42 <uiop> http://sprunge.us/LObP here's a .dot of the libc.so versions on {rhel,centos}6 (random datapoint, mostly just because i have a misc script to extract a pretty depgraph of versions from readelf -a :)
567 2014-03-20 09:03:52 <uiop> curl -s http://sprunge.us/LObP | dot -Tpng > __OUT.png
568 2014-03-20 09:05:57 <uiop> but yeah, rhel6 has latest symver GLIBC_2.12
569 2014-03-20 09:06:13 <warren> wumpus: the plan is to release that? I suppose that's good enough for most people
570 2014-03-20 09:06:30 <wumpus> warren: there is no plan, I'm just experimenting and throwing ideas out there
571 2014-03-20 09:07:00 <wumpus> just realized we need a static -cli as well
572 2014-03-20 09:15:38 <michagogo> cloud|How big is a static bitcoin-qt?
573 2014-03-20 09:16:02 <warren> michagogo|cloud: he did it for only bitcoind
574 2014-03-20 09:16:04 <warren> not -qt
575 2014-03-20 09:16:08 <michagogo> cloud|I know
576 2014-03-20 09:16:20 <michagogo> cloud|I mean, next question, how big would -Qt be?
577 2014-03-20 09:16:41 <warren> hmm
578 2014-03-20 09:16:49 <warren> losing ASLR really isn't good
579 2014-03-20 09:16:51 <wumpus> michagogo|cloud: big (the windows .exe should be a good guide)
580 2014-03-20 09:17:07 <michagogo> cloud|ACTION doesn't know how big that is
581 2014-03-20 09:17:07 <warren> I guess the windows .exe lacks it too.
582 2014-03-20 09:17:18 <wumpus> no, for windows it works
583 2014-03-20 09:18:29 <wumpus> it works differently for windows IIRC, the OS does the ASLR, not the dynamic linker
584 2014-03-20 09:19:12 <warren> ok
585 2014-03-20 09:21:31 <wumpus> (well to be pedantic, windows doesn't have a separate dynamic linker like linux, it's just part of executable-loading)
586 2014-03-20 09:21:44 <uiop> windows dyn linker runs in kernel space
587 2014-03-20 09:21:46 <uiop> yeah
588 2014-03-20 09:22:25 <uiop> (yikes)
589 2014-03-20 09:32:43 <fanquake> wumpus You can close #3563
590 2014-03-20 09:33:16 <wumpus> ok, so with newer -qt it did work?
591 2014-03-20 09:34:19 <fanquake> Just realised the latest release is using 4.8.5..
592 2014-03-20 09:34:21 <fanquake> I haven't been able to test again yet. can't compile master atm.
593 2014-03-20 09:34:43 <wumpus> compiling on macosx is great fun from what I've read
594 2014-03-20 09:34:58 <wumpus> gitian builds for macosx are coming though :)
595 2014-03-20 09:35:16 <fanquake> yea.. it's my favourite past time :|
596 2014-03-20 09:35:43 <fanquake> I've been trying to keep an eye on the new gitian stuff. Been meaning to get gitian builds running for myself.
597 2014-03-20 09:35:47 <michagogo> cloud|Uh... https://medium.com/p/681d3dea0093
598 2014-03-20 09:35:50 <michagogo> cloud|o_O
599 2014-03-20 09:36:36 <wumpus> lol
600 2014-03-20 09:36:40 <michagogo> cloud|fanquake: that'd be great -- more gbuilders is a very good thing
601 2014-03-20 09:37:35 <fanquake> Last time I was setting it up, I ran into some error. possibly Ruby related, and then I just got busy with other things.
602 2014-03-20 09:37:45 <fanquake> Will look at it again soon.
603 2014-03-20 09:37:57 <michagogo> cloud|fanquake: if you run into trouble, you can get assistance in here
604 2014-03-20 09:39:08 <oleganza> hi there. Congrats with 0.9.0 release
605 2014-03-20 09:39:24 <oleganza> i'm tinkering with my own bitcoin validation code and have problem with testnet GetNextWorkRequired
606 2014-03-20 09:39:30 <oleganza> which is really weird
607 2014-03-20 09:40:17 <oleganza> according to the code, GetNextWorkRequired returns target that must match exactly nBits in the current block, not return a target "greater or equal".
608 2014-03-20 09:41:30 <oleganza> http://test.webbtc.com/block/00000000ae0922c1de5eff0d7e5fa1009661d8a47ca1664ceea58069e15c4cc3
609 2014-03-20 09:41:30 <oleganza> on testnet3, block 385 has time 1202 seconds higher than the previous block. According to special rule for testnet, if time interval is above 1200 sec, block target is reset to max target
610 2014-03-20 09:42:32 <oleganza> so GetNextWorkRequired returns max target 487063544 while the block 385 has nBits = 486604799
611 2014-03-20 09:42:48 <oleganza> they don't match and I can't validate block 385
612 2014-03-20 09:43:18 <oleganza> i've double checked that i import exactly the same blocks with correct hashes, timestamps and nBits
613 2014-03-20 09:43:41 <oleganza> i wonder if anyone has a clue what could be wrong here
614 2014-03-20 09:51:00 <oleganza> niiiice https://gitorious.org/bitcoin/luke-jr-bitcoin/commit/edb563e8a5e6145cef6684e6e179b428a115ec62
615 2014-03-20 09:51:34 <oleganza> so this 1200 sec reset was introduced in Feb 15, 2012, but later was removed from the source because checkpoints are assumed to be always on
616 2014-03-20 09:52:06 <gmaxwell> huh?
617 2014-03-20 09:52:11 <gmaxwell> drug induced comment.
618 2014-03-20 09:52:51 <gmaxwell> oleganza: thats how testnet work, checkpoints have nothing to do with that and usually you'd be best if you erased the word checkpoints from your mind.
619 2014-03-20 09:53:12 <gmaxwell> er, s/work/works/
620 2014-03-20 09:53:25 <oleganza> I disabled checkpoints entirely, btw
621 2014-03-20 09:53:43 <oleganza> my problem is that block 385 does not follow the rules in bitcoind (or i miss something)
622 2014-03-20 09:53:54 <oleganza> but some time before there was a timestamp check
623 2014-03-20 09:53:58 <gmaxwell> Nope.
624 2014-03-20 09:53:58 <oleganza> (see the commit above)
625 2014-03-20 09:54:08 <gmaxwell> That was testnet2.
626 2014-03-20 09:54:30 <gmaxwell> the testnet3 chain has had the difficulty rule its whole life.
627 2014-03-20 09:54:53 <oleganza> but i'm importing testnet3 blocks from scratch
628 2014-03-20 09:55:14 <oleganza> with genesis: http://test.webbtc.com/block/000000000933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943
629 2014-03-20 09:56:34 <oleganza> ok, thanks for clarification: the timestamp check was removed because testnet3 started with that rule from the beginning. But I still don't get why the 1202 sec difference did not cause block 385 to have max target
630 2014-03-20 09:56:55 <gmaxwell> it does have the max target, as does 384
631 2014-03-20 09:57:34 <gmaxwell> (and 386 for that matter)
632 2014-03-20 09:57:38 <oleganza> 486604799 is max target?
633 2014-03-20 09:59:45 <oleganza> oh
634 2014-03-20 09:59:47 <oleganza> alright
635 2014-03-20 09:59:56 <oleganza> someone screwed up max_target in the network params
636 2014-03-20 10:00:01 <oleganza> gmaxwell: thanks a lot
637 2014-03-20 10:00:59 <gmaxwell> oleganza: max_target in the network params?
638 2014-03-20 10:01:29 <oleganza> not in bitcoind source
639 2014-03-20 10:01:48 <gmaxwell> K.
640 2014-03-20 10:02:32 <oleganza> gmaxwell: https://github.com/lian/bitcoin-ruby/commit/85d19aa80b05305fe9506de282055ebfb0a3e33e
641 2014-03-20 10:03:21 <gmaxwell> I was totally baffled to see you represent bits as an integer. :P
642 2014-03-20 10:03:27 <Ghaleon_> any detailed BitcoinD upgrade guide for ubuntu ? the 0.9.0 release just says to uninstall it..... does this mean delete the block chain files and my wallet.dat too ? is there anyway to upgrade it without having to rebuild thenblockchain files?
643 2014-03-20 10:03:48 <oleganza> gmaxwell: i keep some console to convert into bignum and compact hex when needed
644 2014-03-20 10:04:00 <oleganza> so the correct limit is 0x1d00ffff
645 2014-03-20 10:04:08 <oleganza> not 0x1d07fff8
646 2014-03-20 10:04:34 <gmaxwell> Ghaleon_: #bitcoin is a better channel for that kind of question, but uninstalling it won't remove those things (though you should always have a good backup of your wallet before and upgrade just in case)
647 2014-03-20 10:04:52 <Ghaleon_> i was banned from bit coin for posting a link... :(
648 2014-03-20 10:05:10 <wumpus> nonono, don't uninstall any data files, the uninstaller doesn't touch those
649 2014-03-20 10:05:25 <airbreather> don't delete wallet.dat
650 2014-03-20 10:05:40 <wumpus> would you expect word to also remove all your documents if you uninstall it?
651 2014-03-20 10:05:45 <Ghaleon_> i just wanna upgrade to 0.9.0 it looks awesome
652 2014-03-20 10:06:03 <Ghaleon_> good point rumpus. i am being extra cautious here
653 2014-03-20 10:06:12 <Ghaleon_> considering what is at risk
654 2014-03-20 10:06:21 <wumpus> do backup your wallet!
655 2014-03-20 10:06:39 <Ghaleon_> certainly
656 2014-03-20 10:07:54 <airbreather> BTW, sincere congratulations to the dev team for getting 0.9.0 out.
657 2014-03-20 10:07:55 <Ghaleon_> i installed it on ubuntu with aptitude install bit coin so i would imagine that aptitude uninstall bit coin will work ?
658 2014-03-20 10:08:28 <Ghaleon_> yes, us noobs r very thankful, can;t wait to try out the direct customer to merchant sends!!!
659 2014-03-20 10:11:53 <oleganza> gmaxwell: are you going to Amsterdam in May 15-17?
660 2014-03-20 10:31:33 <michagogo> cloud|Anyone know if BlueMatt pushed 0.9.0 yet?
661 2014-03-20 10:33:19 <epscy> michagogo|cloud: to the ubuntu ppa?, i checked about an hour ago and no
662 2014-03-20 10:33:31 <michagogo> cloud|epscy: thanks
663 2014-03-20 10:33:57 <Ghaleon_> not pap for ubunto 0.0.0 can anyone upload it please?
664 2014-03-20 10:34:00 <michagogo> cloud|Ghaleon_: what version of Bitcoin do you have at the moment?
665 2014-03-20 10:34:05 <michagogo> cloud|0.8.6?
666 2014-03-20 10:34:09 <Ghaleon_> yeah
667 2014-03-20 10:34:15 <Ghaleon_> just installed it last week
668 2014-03-20 10:34:24 <michagogo> cloud|If you want to upgrade from the ppa, you can't yet
669 2014-03-20 10:34:34 <Ghaleon_> really want 0.9.0 for ubuntu.. i am a noob tho and lost with apt
670 2014-03-20 10:34:38 <michagogo> cloud|BlueMatt needs to update the PPA first
671 2014-03-20 10:34:45 <Ghaleon_> yes.. i will have to compile it myself
672 2014-03-20 10:34:51 <Ghaleon_> not sure if gcc is on that box even
673 2014-03-20 10:35:09 <Ghaleon_> bluematt, bray. we need u
674 2014-03-20 10:35:18 <michagogo> cloud|Ghaleon_: you could do that, or you could just wait -- I'm sure he'll get around to it in the next couple of days
675 2014-03-20 10:35:20 <airbreather> I'd recommend just waiting
676 2014-03-20 10:35:26 <michagogo> cloud|(I hope)
677 2014-03-20 10:35:28 <epscy> +1 for waiting
678 2014-03-20 10:35:53 <Ghaleon_> we need the latest n great tho... like the iPhone kiddies
679 2014-03-20 10:36:32 <airbreather> no you don't -- you need something that is going to work
680 2014-03-20 10:37:39 <airbreather> if you really want to compile it yourself, I think "apt-get build-dep bitcoin" can get you most of the way towards where you need to be in order to compile the latest and greatest
681 2014-03-20 10:37:47 <michagogo> cloud|Ghaleon_: you're probably best off just waiting for Matt to push the update
682 2014-03-20 10:38:11 <michagogo> cloud|(Though it'd be nice to have more than one person with that ability...)
683 2014-03-20 10:38:19 <Ghaleon_> yeah u guys r right
684 2014-03-20 10:38:32 <Ghaleon_> wish i had the skills to do it myself and upload the latest ppa
685 2014-03-20 10:38:43 <Ghaleon_> we really need to distro out the workload
686 2014-03-20 10:39:01 <airbreather> isn't that just the way PPAs work, though? Or is there a way for the maintainer to authorize other individuals to upload things
687 2014-03-20 10:39:02 <Ghaleon_> got big plans to get bit coin mainstream
688 2014-03-20 10:39:13 <Ghaleon_> we need our own server so thus i am going uber geek
689 2014-03-20 10:39:14 <epscy> airbreather: hasn't the build system changed?, if so it might be more work than usual
690 2014-03-20 10:39:37 <Malstromm> Hi all
691 2014-03-20 10:39:56 <Malstromm> I'd like to get rid of all the malleated transactions I get on top of my transaction list on Bitcoin-QT
692 2014-03-20 10:39:56 <michagogo> cloud|airbreather: IIRC the ppa belongs to the team "bitcoin"
693 2014-03-20 10:40:05 <michagogo> cloud|Which currently consists only of Matt
694 2014-03-20 10:40:06 <Malstromm> should I use -zapwallettxes?
695 2014-03-20 10:40:18 <wumpus> Malstromm: yes, do make a backup of your wallet ofc
696 2014-03-20 10:40:20 <airbreather> epscy, probably. "not sure if gcc is on that box even" led me to believe that the build-dep step is helpful though
697 2014-03-20 10:40:32 <Malstromm> but wouldn't this mess up with the internal QT accounting? Will it maintain my tags, etc.?
698 2014-03-20 10:40:34 <epscy> airbreather: fair enough
699 2014-03-20 10:40:47 <wumpus> Malstromm: it will keep your labels
700 2014-03-20 10:40:49 <michagogo> cloud|Malstromm: zapwallettx will, yes
701 2014-03-20 10:40:53 <Malstromm> Great!
702 2014-03-20 10:41:08 <michagogo> cloud|Salvagewallet, which is what you would have had to do before 0.9, would lose them